IPv6過渡期的用戶接入認(rèn)證

1、IPv6過渡期的用戶接入認(rèn)證摘要：本文首先針對寬帶用戶接入認(rèn)證中涉及到的PPP、NDP/SLAAC、DHCP和Radius進(jìn)行論述，然后分析了在引入V6用戶后帶來的問題，并提出了相關(guān)的解決方案建議。Abstract: Firstly, we discussed some Internet access related protocols, such as PPP, NDP / SLAAC, DHCP and Radius, then analyzed some new issues when V6 service is introduced to ISP, and also give some

2、 solutions to solve the problems. 關(guān)鍵詞：IPv6，過渡，接入認(rèn)證，授權(quán)計費Keyword: IPv6, Transition, Access authentication, Authorization and accounting作者：胡捷，中國電信股份有限公司北京研究院，主任工程師王茜，中國電信股份有限公司北京研究院，全業(yè)務(wù)承載網(wǎng)研究室主任陳運清，中國電信股份有限公司北京研究院，網(wǎng)絡(luò)技術(shù)研究部部長趙慧玲，中國電信股份有限公司北京研究院，副院長1V6連接型業(yè)務(wù)簡介IPv6作為一種電信業(yè)務(wù)，在業(yè)務(wù)引入的初始階段與V4沒有本質(zhì)區(qū)別，都是以連接型業(yè)務(wù)為主，應(yīng)用型業(yè)

3、務(wù)可以視作增值服務(wù)，是在網(wǎng)絡(luò)連接基礎(chǔ)上提供的高層業(yè)務(wù)。運營商提供給用戶基于IPv6協(xié)議的網(wǎng)絡(luò)接入，以固網(wǎng)寬帶為例，接入方式主要沿襲V4時期的xDSL、PON、LAN等方式。未來的趨勢還將有WIFI和WiMAX等。連接型業(yè)務(wù)，最關(guān)鍵的在于用戶接入認(rèn)證和計費方式的采用。在V4時代，已經(jīng)探索出非常完善的解決方案，即在用戶接入認(rèn)證方式上，采用PPP、DHCP+Web等，在認(rèn)證計費方式上，主要采用Radius協(xié)議。V6引入后，變化不大，在接入認(rèn)證上，多了一個SLAAC無狀態(tài)地址自動配置協(xié)議，即基于NDP鄰居發(fā)現(xiàn)協(xié)議實現(xiàn)的一種地址分配方式，目前來看，Radius依然是V6時代的主要認(rèn)證計費協(xié)議，IETF于

4、2003年9月推出的Diameter，截止到目前，并沒有得到大范圍應(yīng)用。V6的SLAAC基于IETF RFC 4862，重點解決的是在V6環(huán)境下地址自動分配的一種機(jī)制，其目的是簡化V6終端的協(xié)議棧，采用無狀態(tài)地址自動配置。所謂無狀態(tài)，可以和有狀態(tài)的DHCPv6進(jìn)行對比說明：無狀態(tài)方式網(wǎng)絡(luò)中沒有一臺特定用于地址分配的服務(wù)器，所有主機(jī)的地址都是在通過RA報文發(fā)送的/64 Prefix中結(jié)合某種算法自行創(chuàng)建的；有狀態(tài)方式則是在網(wǎng)絡(luò)中設(shè)置一臺DHCPv6服務(wù)器，負(fù)責(zé)為終端直接分配/128長度的地址，并且在DHCPv6服務(wù)器中有相關(guān)的狀態(tài)記錄，即終端的MAC地址、上線時間、地址分配后的有效期限等信息。通

5、過對SLAAC和DHCPv6協(xié)議的分析，在協(xié)議交互過程中，終端主機(jī)沒有發(fā)送用戶名和密碼的機(jī)制，嚴(yán)格來說不能算作是一種接入認(rèn)證技術(shù)，更多地是一種終端配置實現(xiàn)，包括地址、DNS地址、缺省網(wǎng)關(guān)、時效等參數(shù)；這類技術(shù)比較適合公司局域網(wǎng)，因為公司員工將電腦連入公司網(wǎng)絡(luò)是無需采用用戶名和密碼進(jìn)行驗證的，而且在公司員工接入網(wǎng)絡(luò)中，也無需對用戶離線、上線進(jìn)行時間和流量上的統(tǒng)計，默認(rèn)所有用戶安全；對于運營商來說，此種接入方式和地址分配策略無法滿足以提供網(wǎng)絡(luò)連接為收入來源的策略。運營商必須有一種機(jī)制實現(xiàn)對用戶接入網(wǎng)絡(luò)的控制，包括對用戶合法性判斷（認(rèn)證）、對用戶上網(wǎng)級別的規(guī)定（授權(quán)）、對用戶流量和時長的統(tǒng)計（計費）

6、等各種手段。2V6連接型業(yè)務(wù)在認(rèn)證、授權(quán)和計費方面的問題和解決方案在V4時代，絕大多數(shù)運營商都是采用PPP協(xié)議結(jié)合Radius協(xié)議來滿足上述要求。PPP協(xié)議早期用于通過PSTN窄帶撥號上網(wǎng)的環(huán)境下，實現(xiàn)用戶賬號的認(rèn)證，授權(quán)，這兩個功能通過PPP的LCP協(xié)議實現(xiàn)。后來又開發(fā)了NCP協(xié)議，使得在LCP鑒權(quán)通過后，可以通過NCP實現(xiàn)上網(wǎng)參數(shù)配置，從而避免了用戶主機(jī)鑒權(quán)通過后還要發(fā)起DHCP請求的繁瑣過程。運營商除通過PPP提供用戶上網(wǎng)接入認(rèn)證之外，還帶來如下額外好處：l 每個用戶一個PPP session，流量可以通過PPP封裝進(jìn)行隔離，起到類似VLAN隔離的效果，一定程度上保障安全；l BRAS設(shè)

7、備可以針對每個PPP session進(jìn)行Inbound/Outbound流量控制，實現(xiàn)一定程度的服務(wù)質(zhì)量；l BRAS設(shè)備可以針對每個PPP session進(jìn)行上下線時長和流量統(tǒng)計，實現(xiàn)靈活精確的計費策略；l 一個用戶可以同時發(fā)起多個PPP session，每個session對應(yīng)一種業(yè)務(wù)，從而實現(xiàn)業(yè)務(wù)之間的隔離，BRAS可以為不同業(yè)務(wù)對應(yīng)的PPP session配置不同的Profile，提供不同的QoS。V6時代，上述的四種優(yōu)點依然具備，目前來看，與V4環(huán)境下PPP最大的不同在于，NCP不再參與終端上網(wǎng)參數(shù)的協(xié)商，而是在LCP進(jìn)行用戶名、密碼認(rèn)證后，終端依次啟用NDP、DHCPv6來獲得接口地

8、址、家庭網(wǎng)絡(luò)前綴、DNS等參數(shù)。由于運營商有豐富的V4運營經(jīng)驗和PPP使用習(xí)慣，V6的PPP+NDP/SLAAC+DHCP顯得繁瑣，目前來看，PPPv6及相關(guān)協(xié)議解決方案的問題在于：l RFC5072規(guī)定的PPPv6只通過IPv6CP協(xié)商Interface-ID，但是協(xié)議中又建議此ID僅作為Link-local地址的ID，終端接口地址或者路由型家庭網(wǎng)關(guān) WAN口地址依然需要通過NDP/SLAAC或者DHCPv6獲得，現(xiàn)在看來RFC5072提供的協(xié)商功能非常有限；l 各種協(xié)議之間的運行順序需要精確控制，一種協(xié)議狀態(tài)Up后，才能進(jìn)入下一種協(xié)議交互，協(xié)議之間的協(xié)同工作復(fù)雜，導(dǎo)致客戶端和服務(wù)器端狀態(tài)機(jī)

9、需要協(xié)調(diào)，程序開發(fā)復(fù)雜，各進(jìn)程間容易導(dǎo)致沖突；l 各種協(xié)議的先后執(zhí)行，引起額外的時延，用戶認(rèn)證授權(quán)時間延長；l V4依然采用NCP，V6采用NDP/SLAAC和DHCP，V4-reday和V6-reday有時差，導(dǎo)致BRAS發(fā)送Accounting-request報文時不能將V4和V6業(yè)務(wù)進(jìn)行同步計費，運營支撐系統(tǒng)需要改造以便支持或容忍此現(xiàn)象；l 各種協(xié)議提供的部分功能是重復(fù)的，例如PPP session的連接狀態(tài)即可代表用戶在線，而此時的DHCP release 時長則完全沒有必要采用；在PPP協(xié)議的點到點環(huán)境下沒有必要采用DAD地址重復(fù)檢測；此外SLAAC、DHCPv6都可以提供接口地址和

10、DNS地址協(xié)商，功能重復(fù)；導(dǎo)致以上局面有一定歷史原因，目前中國電信已經(jīng)向IETF提交了關(guān)于在開展V6寬帶接入業(yè)務(wù)中采用PPPv6遇到的問題陳述（PPPv6 Problem statement and requirements: Draft-hu-pppext-IPv6CP-requirements-01），并且在試驗網(wǎng)實踐中總結(jié)經(jīng)驗，提出了自己的解決方案(PPP IPv6 Control Protocol Extensions: draft-hu-pppext-ipv6cp-extensions-01)，建議沿用V4時代PPP的功能，同時提供接口地址、DNS地址、家庭網(wǎng)絡(luò)前綴、DS-Lite

11、AFTR地址、NTP地址等信息。這個草案提交后得到業(yè)界關(guān)注，英國一家專注研發(fā)CPE和L2TP LNS設(shè)備的廠商（http:/www.firebrick.co.uk/）已經(jīng)采納了草案中建議的Option號碼，計劃在產(chǎn)品中實現(xiàn)上述功能。中國電信計劃在2011年與中興通訊合作開發(fā)PPPv6擴(kuò)展協(xié)議，在中興BRAS和中興CPE之間采用基于這個草案的PPPv6擴(kuò)展實現(xiàn)參數(shù)協(xié)商，回避引入NDP/SLAAC和DHCPv6帶來的復(fù)雜性。從終端用戶到BRAS采用PPP后，只是完成了用戶接入認(rèn)證的一個環(huán)節(jié)。在這個環(huán)節(jié)中終端相當(dāng)于PPP Client，BRAS相當(dāng)于PPP Server；一個完整的認(rèn)證、授權(quán)、計費鏈

12、條，還需要AAA服務(wù)器和計費服務(wù)器的參與。具體實現(xiàn)就是BRAS同時作為Radius Client，通過UDP報文封裝radius消息通過IP可達(dá)送到AAA服務(wù)器，AAA收到用戶賬號信息提供用戶認(rèn)證、授權(quán)，返回Access-accept消息給BRAS。V4環(huán)境下，BRAS得到授權(quán)后即通過PPP的NCP給終端分配上網(wǎng)所需要的參數(shù)，V6環(huán)境下則需要進(jìn)一步調(diào)用NDP/SLAAC和DHCP進(jìn)程。V4環(huán)境下一切進(jìn)展順利，協(xié)議開發(fā)和應(yīng)用都已經(jīng)成熟，接近完美。V6引入后則帶來新的問題，本質(zhì)原因是因為Radius協(xié)議在制定之初只考慮了V4協(xié)議單一環(huán)境。這些問題例舉如下：l RFC2866中，只有對流量的統(tǒng)計屬性

13、（packages or octets），但是不能區(qū)分是V4還是V6流量，無法滿足ISP針對V4和V6流量分別計費的能力；目前已經(jīng)有人提出了相關(guān)建議（RADIUS Accounting Extensions for IPv6: draft-maglione-radext-ipv6-acct-extensions-01）；l 現(xiàn)有的Rdius協(xié)議針對IPv6擴(kuò)展的屬性有Framed-Interface-Id,Framed-IPv6-Prefix,Framed-IPv6-Route,Framed-IPv6-Pool(RFC3162),和Delegated-IPv6-Prefix（RFC4818）,

14、但是沒有framed-ipv6-address，即/128的IPV6 address屬性。當(dāng)主機(jī)或路由型家庭網(wǎng)關(guān)通過DHCPv6方式從BRAS獲得接口地址（或路由型家庭網(wǎng)關(guān)的WAN口地址）時，采用stateful dhcp直接獲得/128的地址，但是此時BRAS無法將/128的地址通過radius的accounting-request報文送到AAA服務(wù)器，影響對用戶的計費和溯源；這個問題的進(jìn)一步闡述如下：目前BRAS在accounting-request報文中只能上送/32的V4地址和/64的V6 Prefix和/或64位interface ID，無法上送/128的V6地址，如果用戶采用SLA

15、AC方式自行創(chuàng)建的/128地址，由于是無狀態(tài)的，BRAS不掌握終端的具體地址信息，無法通過Radius告訴AAA具體的終端地址是什么-針對此問題建議采用如下的方法解決：對于主機(jī)上網(wǎng)用戶，為每臺主機(jī)的PPP session分配不同的/64 prefix，由于Radius V6擴(kuò)展已經(jīng)具備上送/64前綴的功能，可以通過每用戶唯一的前綴實現(xiàn)溯源；如果采用有狀態(tài)的DHCP直接分配/128地址，BRAS掌握了終端用戶地址信息，目前的Radius關(guān)于V6的擴(kuò)展暫時欠缺這個功能，好在已經(jīng)有人在IETF提交了草案提供解決方案建議（RADIUS attributes for IPv6 Access Networ

16、ks: draft-ietf-radext-ipv6-access-03.txt）；l 目前AAA在返回給BRAS的access accept報文中，沒有對用戶屬性的定義（V4-only, V6-only, dual-stack），如果用戶購買的是V6-only業(yè)務(wù)，而用戶終端實際上是支持V4協(xié)議棧的，此時終端用戶如果發(fā)起V4地址的協(xié)商和請求報文，BRAS是可以給V6-only用戶分配V4地址和其他參數(shù)的，導(dǎo)致V6-only用戶可以連接V4 Internet-現(xiàn)有的解決方案是關(guān)閉用戶側(cè)PPP協(xié)議配置中的V4協(xié)議棧，或者用戶采用usernamedomain方式，BRAS為不同domain后綴的用

17、戶配置不同的Profile，分別為不同類型用戶提供不同類型地址，從而避免了V6-only用戶接入V4 Internet；l 目前AAA返回給NSA的屬性中，沒有針對主機(jī)或者路由型家庭網(wǎng)關(guān)屬性的定義，BRAS在通過對主機(jī)或路由型家庭網(wǎng)關(guān)的認(rèn)證授權(quán)后，無法判斷用戶終端是主機(jī)還是RG，針對主機(jī)，只需給終端分配接口地址；針對RG，還需要分配內(nèi)網(wǎng)prefix；由于BRAS無法識別用戶屬性，當(dāng)惡意的主機(jī)發(fā)起access-request請求并獲得access-accept許可后，可以向BRAS發(fā)起delegated-prefix申請，占用ISP 地址資源-目前的解決方案也是通過usernamedomain的

18、方式為不同用戶分配不同的Profile，從而避免主機(jī)用戶獲得地址前綴；后兩個問題，中國電信在V6實驗網(wǎng)部署中總結(jié)了經(jīng)驗，已經(jīng)在IETF提交了問題陳述（RADIUS issues in IPv6 deployments: draft-hu-v6ops-radius-issues-ipv6-00）；完善的解決方案正在醞釀，初步設(shè)想就是擴(kuò)展Radius V6的支持屬性，中國電信將于近期在IETF提交草案，具體建議如下：l 增加用戶的用戶屬性：主機(jī)用戶，或者家庭網(wǎng)絡(luò)用戶。AAA對用戶類型在認(rèn)證時進(jìn)行判斷，認(rèn)證通過后下發(fā)用戶類型信息給BRAS，BRAS就知道用戶是主機(jī)用戶還是網(wǎng)絡(luò)用戶了，從而針對不同用戶

19、屬性采取不同的地址分配策略；l 增加用戶的業(yè)務(wù)屬性：v4-only,v6-only,dual-stack，認(rèn)證后反饋給BRAS，BRAS收到相關(guān)屬性的字段，調(diào)用不同的Profile，實現(xiàn)v4用戶只有V4地址，V6用戶只有V6地址，雙棧用戶可同時獲得V4，V6地址。3總結(jié)綜上所述，V6全面推廣還需要在某些細(xì)節(jié)上加以完善，例如在運營商最關(guān)心的接入、認(rèn)證、授權(quán)、計費方面，在商業(yè)模式方面，以及配套的IT、IP運營支撐系統(tǒng)方面都需要進(jìn)行相關(guān)的改造。這些問題只有在實踐中才能發(fā)現(xiàn)，并促使人們尋求解決途徑。雖然有些問題可以采用臨時的、變通的方法解決或者規(guī)避，但是完善的解決方案仍然需要通過在IETF提交草案進(jìn)行討論，獲得業(yè)界一致意見后成為標(biāo)準(zhǔn)，才能成為商業(yè)運營的前提，才可被運營商普遍接受和推廣。參考文獻(xiàn)1 RFC2866 Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.2 RFC3162 B. Aboba, G. Zorn, D. Mitton. “RADIUS and IPv6.” RFC