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

1、IPv6過(guò)渡期的用戶接入認(rèn)證摘要：本文首先針對(duì)寬帶用戶接入認(rèn)證中涉及到的PPP、NDP/SLAAC、DHCP和Radius進(jìn)行論述，然后分析了在引入V6用戶后帶來(lái)的問(wèn)題，并提出了相關(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，過(guò)渡，接入認(rèn)證，授權(quán)計(jì)費(fèi)Keyword: IPv6, Transition, Access authentication, Authorization and accounting作者：胡捷，中國(guó)電信股份有限公司北京研究院，主任工程師王茜，中國(guó)電信股份有限公司北京研究院，全業(yè)務(wù)承載網(wǎng)研究室主任陳運(yùn)清，中國(guó)電信股份有限公司北京研究院，網(wǎng)絡(luò)技術(shù)研究部部長(zhǎng)趙慧玲，中國(guó)電信股份有限公司北京研究院，副院長(zhǎng)1V6連接型業(yè)務(wù)簡(jiǎn)介IPv6作為一種電信業(yè)務(wù)，在業(yè)務(wù)引入的初始階段與V4沒(méi)有本質(zhì)區(qū)別，都是以連接型業(yè)務(wù)為主，應(yīng)用型業(yè)

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

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

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

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

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

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

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

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

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

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

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

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

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

16、ks: draft-ietf-radext-ipv6-access-03.txt）；l 目前AAA在返回給BRAS的access accept報(bào)文中，沒(méi)有對(duì)用戶屬性的定義（V4-only, V6-only, dual-stack），如果用戶購(gòu)買(mǎi)的是V6-only業(yè)務(wù)，而用戶終端實(shí)際上是支持V4協(xié)議棧的，此時(shí)終端用戶如果發(fā)起V4地址的協(xié)商和請(qǐng)求報(bào)文，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的屬性中，沒(méi)有針對(duì)主機(jī)或者路由型家庭網(wǎng)關(guān)屬性的定義，BRAS在通過(guò)對(duì)主機(jī)或路由型家庭網(wǎng)關(guān)的認(rèn)證授權(quán)后，無(wú)法判斷用戶終端是主機(jī)還是RG，針對(duì)主機(jī)，只需給終端分配接口地址；針對(duì)RG，還需要分配內(nèi)網(wǎng)prefix；由于BRAS無(wú)法識(shí)別用戶屬性，當(dāng)惡意的主機(jī)發(fā)起access-request請(qǐng)求并獲得access-accept許可后，可以向BRAS發(fā)起delegated-prefix申請(qǐng)，占用ISP 地址資源-目前的解決方案也是通過(guò)usernamedomain的

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

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