白晨鵬，關(guān) 煒

（中國電信股份有限公司陜西分公司 西安 710004）

1 概述

為盡快實(shí)現(xiàn)國內(nèi)互聯(lián)網(wǎng)由IPv4向IPv6的過渡，緩解IPv4地址枯竭及新興技術(shù)對(duì)IP地址的海量需求，國家發(fā)展和改革委員會(huì)于2012年3月29日下發(fā)了《關(guān)于印發(fā)下一代互聯(lián)網(wǎng)“十二五”發(fā)展建設(shè)的意見》的指導(dǎo)性文件，明確了我國下一代互聯(lián)網(wǎng)的發(fā)展目標(biāo)、路線圖和時(shí)間表。同時(shí)要求三大電信運(yùn)營商結(jié)合地址短缺情況，分別選擇部分試點(diǎn)城市，選擇合適的技術(shù)路線，改造IP城域網(wǎng)絡(luò)，解決IPv4地址短缺，實(shí)現(xiàn)IPv6規(guī)模商用部署。中國電信股份有限公司陜西分公司（以下簡(jiǎn)稱陜西電信）作為規(guī)模商用部署試點(diǎn)省之一，積極參與了運(yùn)營商IPv6規(guī)模商用的前期論證、業(yè)務(wù)測(cè)試驗(yàn)證及規(guī)模商用的工作，通過近兩年的調(diào)研、規(guī)劃及網(wǎng)絡(luò)和IT/IP支撐系統(tǒng)改造等工作，已具備了開通IPv6用戶接入的能力。

2 規(guī)模商用技術(shù)路線

2.1 過渡技術(shù)

電信運(yùn)營商網(wǎng)絡(luò)由IPv4向IPv6過渡過程可分為3個(gè)階段。網(wǎng)絡(luò)過渡初期，在當(dāng)前純IPv4網(wǎng)絡(luò)中逐漸引入IPv6，形成雙協(xié)議棧網(wǎng)絡(luò)，用戶可通過IPv6接入互聯(lián)網(wǎng)，但網(wǎng)絡(luò)應(yīng)用與承載仍然以IPv4技術(shù)為主；在第二個(gè)階段，隨著IPv6在網(wǎng)絡(luò)中應(yīng)用范圍的擴(kuò)大和IPv6用戶數(shù)量的增加，IPv4與IPv6將在網(wǎng)絡(luò)中長期并存；遠(yuǎn)期隨著應(yīng)用和用戶逐漸向IPv6技術(shù)的遷移，將逐步演進(jìn)到以IPv6技術(shù)為主或者純IPv6網(wǎng)絡(luò)。

在演進(jìn)過程中，各類標(biāo)準(zhǔn)化組織、運(yùn)營商及研究機(jī)構(gòu)提出了多種網(wǎng)絡(luò)過渡技術(shù)及方案。這些方案總體可分為雙協(xié)議棧、隧道、地址/協(xié)議轉(zhuǎn)換3類技術(shù)，其中針對(duì)電信運(yùn)營商互聯(lián)網(wǎng)寬帶接入用戶的平滑演進(jìn)，NAT444和DS-Lite兩種技術(shù)的標(biāo)準(zhǔn)化程度及應(yīng)用成熟度相對(duì)較高，且可以在短期內(nèi)有效緩解IPv4地址耗盡對(duì)電信運(yùn)營商業(yè)務(wù)發(fā)展帶來的制約。根據(jù)對(duì)這兩種技術(shù)的不同選擇，電信運(yùn)營商的網(wǎng)絡(luò)過渡技術(shù)路線如圖1所示。

圖1 IPv6遷移路線

路線一在過渡階段采用NAT444技術(shù)，運(yùn)營商網(wǎng)絡(luò)引入IPv6后，通過在網(wǎng)絡(luò)中部署運(yùn)營商級(jí)地址轉(zhuǎn)換（carrier grade NAT，CGN）設(shè)備，寬帶接入用戶同時(shí)獲得運(yùn)營商分配的保留IPv4地址與合法IPv6地址，用戶發(fā)起IPv4公網(wǎng)訪問時(shí)，使用保留IPv4地址并在網(wǎng)絡(luò)側(cè)CGN設(shè)備轉(zhuǎn)換為合法IPv4地址；用戶發(fā)起IPv6訪問時(shí)，直接使用合法IPv6地址，有效緩解寬帶接入用戶對(duì)合法IPv4地址的占用。

路線二在過渡階段采用DS-Lite技術(shù)，運(yùn)營商網(wǎng)絡(luò)引入IPv6協(xié)議后，通過在網(wǎng)絡(luò)中部署地址轉(zhuǎn)換設(shè)備AFTR（address family transition router），寬帶接入用戶獲得運(yùn)營商分配的合法IPv6地址，同時(shí)生成DS-Lite標(biāo)準(zhǔn)規(guī)定的保留IPv4地址，用戶發(fā)起IPv4公網(wǎng)訪問時(shí)，使用標(biāo)準(zhǔn)規(guī)定的保留IPv4地址，并通過IPv6隧道將數(shù)據(jù)分組轉(zhuǎn)發(fā)到地址轉(zhuǎn)換設(shè)備AFTR，將保留IPv4地址轉(zhuǎn)換為合法IPv4地址；用戶發(fā)起IPv6訪問時(shí)，直接使用合法IPv6地址。

2.2 NAT444技術(shù)及部署

NAT444技術(shù)最初由日本運(yùn)營商N(yùn)TT提出，運(yùn)用NAT444技術(shù)的網(wǎng)絡(luò)結(jié)構(gòu)模型如圖2所示。

圖2 NAT444網(wǎng)絡(luò)結(jié)構(gòu)模型

NAT444的基本思想是在網(wǎng)絡(luò)中部署運(yùn)營商級(jí)地址轉(zhuǎn)換設(shè)備，與用戶側(cè)設(shè)備（CPE）中的NAT功能共同組成兩級(jí)地址轉(zhuǎn)換，在3類IPv4地址塊之間進(jìn)行IPv4地址轉(zhuǎn)換。

第1類地址塊是用戶駐地網(wǎng)絡(luò)中使用的保留IPv4地址塊，一般由CPE管理，使用RFC1918中定義的保留IPv4地址段，與運(yùn)營商無關(guān)；第2類地址塊是CPE與運(yùn)營商CGN設(shè)備之間使用的保留IPv4地址，使用RFC6598中定義的共享地址空間100.64.0.0/10或RFC1918中定義的保留IPv4地址段，由運(yùn)營商進(jìn)行管理；第3類地址塊是在公眾互聯(lián)網(wǎng)中使用的合法IPv4地址。

用戶側(cè)設(shè)備（CPE）中的NAT功能在上述第1類和第2類地址塊之間進(jìn)行IPv4地址轉(zhuǎn)換，運(yùn)營商CGN設(shè)備在上述第2類和第3類地址塊之間進(jìn)行IPv4地址轉(zhuǎn)換。通過兩次地址轉(zhuǎn)換，用戶終端可使用駐地網(wǎng)中的保留IPv4地址正常訪問公眾互聯(lián)網(wǎng)中使用的合法IPv4地址的服務(wù)器及應(yīng)用。

2.3 DS-Lite技術(shù)及部署

DS-Lite技術(shù)由美國運(yùn)營商Comcast在2008年提出，該技術(shù)通過在用戶駐地網(wǎng)或用戶終端范圍內(nèi)引入使用私有IPv4地址的輕量級(jí)雙協(xié)議棧，解決IPv6用戶通過純IPv6網(wǎng)絡(luò)接入，訪問IPv4應(yīng)用的問題。DS-Lite技術(shù)于2011年8月在IETF完成標(biāo)準(zhǔn)化。DS-Lite網(wǎng)絡(luò)結(jié)構(gòu)模型如圖3所示。

圖3 DS-Lite網(wǎng)絡(luò)結(jié)構(gòu)模型

DS-Lite網(wǎng)絡(luò)結(jié)構(gòu)中包括3個(gè)組件模塊：CPE中內(nèi)置的B4模塊，網(wǎng)絡(luò)側(cè)的AFTR模塊，B4模塊與AFTR模塊之間的4in6 softwire隧道。其中CPE在駐地網(wǎng)中為用戶終端分配客戶側(cè)使用的保留IPv4地址，用戶終端使用保留IPv4地址發(fā)起對(duì)合法IPv4地址服務(wù)器的訪問，當(dāng)報(bào)文到達(dá)CPE后，由CPE中的B4模塊將報(bào)文封裝到4in6 softwire隧道中，封裝后外層數(shù)據(jù)分組為IPv6數(shù)據(jù)分組，通過IPv6路由將報(bào)文轉(zhuǎn)發(fā)到AFTR設(shè)備，由AFTR設(shè)備解封裝后，提取內(nèi)層IPv4報(bào)文，并將IPv4報(bào)文中使用保留IPv4地址的源地址轉(zhuǎn)換為合法IPv4地址。經(jīng)過AFTR設(shè)備的地址轉(zhuǎn)換，用戶終端可正常訪問公眾互聯(lián)網(wǎng)中使用合法IPv4地址的服務(wù)器及應(yīng)用。

從IPv4地址轉(zhuǎn)換的角度，NAT444技術(shù)與DS-Lite技術(shù)本質(zhì)上均為NAT44技術(shù)，均通過TCP/UDP端口復(fù)用的方式提高合法IPv4地址的利用率，因此具有相同的合法IPv4地址使用效率，同時(shí)也都具有NAT44技術(shù)對(duì)應(yīng)用不完全透明的局限性。兩類技術(shù)的主要區(qū)別如下：

·NAT444技術(shù)可以獨(dú)立于IPv6技術(shù)在純IPv4環(huán)境中部署，DS-Lite技術(shù)要求網(wǎng)絡(luò)中必須部署IPv6協(xié)議棧；

·NAT444技術(shù)要求運(yùn)營商在城域網(wǎng)范圍或BRAS范圍內(nèi)統(tǒng)一規(guī)劃保留IPv4地址，DS-Lite技術(shù)不需要運(yùn)營商進(jìn)行保留IPv4地址的規(guī)劃；

·NAT444技術(shù)不加載IPv6技術(shù)時(shí)，運(yùn)營商不需要改

造CPE，就可以實(shí)現(xiàn)對(duì)NAT444技術(shù)的支持，DS-Lite技術(shù)需要對(duì)CPE進(jìn)行改造，在CPE中增加B4模塊。

3 技術(shù)選擇及改造

陜西電信選擇了西安、寶雞、渭南3個(gè)城域網(wǎng)進(jìn)行IPv6技術(shù)試商用部署。經(jīng)過分析，對(duì)IPv6技術(shù)需求較強(qiáng)烈的客戶主要包括高校、科研院所及大型企業(yè)，這類客戶大部分集中在西安，因此西安電信城域網(wǎng)開放IPv6業(yè)務(wù)的需求較迫切。為了避免在城域范圍內(nèi)進(jìn)行保留IPv4地址的規(guī)劃，西安城域網(wǎng)選擇DS-Lite過渡技術(shù)，由于DS-Lite技術(shù)要求家庭網(wǎng)關(guān)支持B4功能，而現(xiàn)網(wǎng)存量用戶家庭網(wǎng)關(guān)均不支持該功能，因此西安電信優(yōu)先對(duì)新增用戶開展DS-Lite業(yè)務(wù)部署，存量用戶通過綜合終端管理系統(tǒng)（integrated terminalmanagement system，ITMS）的優(yōu)化改進(jìn)，對(duì)硬件支持DS-Lite功能的家庭網(wǎng)關(guān)通過遠(yuǎn)程升級(jí)改造方式，有序推進(jìn)存量用戶的DS-Lite業(yè)務(wù)部署。

由于DS-Lite技術(shù)部署過程中，對(duì)存量用戶家庭網(wǎng)關(guān)改造過程持續(xù)時(shí)間長、難度大，短期內(nèi)無法有效釋放存量用戶占用的公有IPv4地址，而NAT444技術(shù)在不加載IPv6時(shí)不需要對(duì)家庭網(wǎng)關(guān)進(jìn)行改造，可以快速釋放存量用戶占用的合法IPv4地址，因此在寶雞和渭南兩大城域網(wǎng)中部署了NAT444技術(shù)，直接將普通公眾用戶的公有IPv4地址一次性修改為私有地址，釋放出對(duì)應(yīng)的公有IPv4地址供其他未部署IPv6的地址發(fā)展業(yè)務(wù)使用。

西安、寶雞、渭南3個(gè)城域網(wǎng)進(jìn)行IPv6過渡技術(shù)改造的方案如圖4所示。

3個(gè)地市的城域網(wǎng)網(wǎng)絡(luò)結(jié)構(gòu)均采用扁平化結(jié)構(gòu)，網(wǎng)絡(luò)總體分為城域網(wǎng)出口路由器（核心層）、業(yè)務(wù)控制層和接入層3個(gè)層次。城域網(wǎng)出口路由器采用大容量級(jí)聯(lián)設(shè)備，通過10 Gbit/s/40 Gbit/s電路上聯(lián)163骨干網(wǎng)。業(yè)務(wù)控制層BAS/MSE設(shè)備均采用雙上行連接方式，以等帶寬電路同時(shí)連接到兩臺(tái)城域網(wǎng)核心設(shè)備，使用10 Gbit/s上行鏈路，每臺(tái)BAS在城域范圍內(nèi)覆蓋若干二層接入片區(qū)。接入層以PON技術(shù)為主，通過FTTx技術(shù)實(shí)現(xiàn)寬帶個(gè)人用戶及各類大客戶的接入。

圖4 西安/寶雞/渭南城域網(wǎng)結(jié)構(gòu)

在各城域網(wǎng)網(wǎng)絡(luò)改造中，DS-Lite/NAT444技術(shù)分別需要在網(wǎng)絡(luò)中增加AFTR/CGN模塊。從模塊的形態(tài)看，存在設(shè)備插卡與獨(dú)立設(shè)備兩種形態(tài)，由于獨(dú)立設(shè)備形態(tài)的模塊需要通過網(wǎng)絡(luò)鏈路與現(xiàn)網(wǎng)設(shè)備互聯(lián)，不僅成本高，而且增加了較多故障點(diǎn)，因此陜西電信采用了設(shè)備插卡形態(tài)的AFTR/CGN模塊。從模塊在城域網(wǎng)中的部署位置及所在層次考慮，AFTR/CGN模塊可以集中部署在CR設(shè)備或分散部署在業(yè)務(wù)控制層各個(gè)BAS設(shè)備，但集中部署的可靠性較差，AFTR/CGN故障狀態(tài)下影響范圍較大，因此陜西電信選擇分散式部署方式。具體部署方式如圖4所示，在西安城域網(wǎng)，業(yè)務(wù)控制層所有BAS設(shè)備均增加板卡形態(tài)的AFTR設(shè)備，為各自片區(qū)寬帶用戶提供DS-Lite隧道終結(jié)及地址轉(zhuǎn)換功能；在寶雞、渭南城域網(wǎng)，業(yè)務(wù)控制層所有BAS設(shè)備均增加板卡形態(tài)的CGN設(shè)備，為各自片區(qū)的寬帶用戶提供地址轉(zhuǎn)換功能。

為了全面支撐IPv6業(yè)務(wù)的開展，并滿足日常網(wǎng)絡(luò)運(yùn)維需要，陜西電信同步了AAA系統(tǒng)、DNS、網(wǎng)管系統(tǒng)、ITMS等4個(gè)IP支撐系統(tǒng)，對(duì)CRM、話單采集、計(jì)費(fèi)、服務(wù)開通、資源管理、自動(dòng)激活、施工調(diào)度、服務(wù)保障、ODS/EDW等9個(gè)IT支撐系統(tǒng)進(jìn)行IPv6相關(guān)功能升級(jí)和改造，對(duì)業(yè)務(wù)受理、開通、裝機(jī)、移機(jī)等過程中的資源管理、業(yè)務(wù)開通、網(wǎng)元激活、計(jì)費(fèi)出賬、數(shù)據(jù)分析等處理功能進(jìn)行相應(yīng)改造，實(shí)現(xiàn)對(duì)IPv6相關(guān)業(yè)務(wù)全流程的支持，保障業(yè)務(wù)的正常發(fā)展和網(wǎng)絡(luò)的日常維護(hù)。

其中IP支撐系統(tǒng)的改造具體包括下列內(nèi)容：AAA系統(tǒng)在RADIUS認(rèn)證、計(jì)費(fèi)報(bào)文中增加對(duì)IPv6屬性的支持；DNS增加對(duì)AAAA記錄的支持，實(shí)現(xiàn)IPv6域名的解析；網(wǎng)管系統(tǒng)通過軟件升級(jí)實(shí)現(xiàn)對(duì)IPv6 MIB變量的讀寫、IPv6拓?fù)浒l(fā)現(xiàn)功能和IPv6網(wǎng)絡(luò)的故障管理等功能；ITMS對(duì)業(yè)務(wù)下發(fā)和終端管理能力進(jìn)行優(yōu)化增強(qiáng)。

IT支撐系統(tǒng)改造內(nèi)容如圖5所示，具體內(nèi)容包括：CRM系統(tǒng)增加IPv6屬性記錄及展示能力；資源系統(tǒng)提供在端口級(jí)標(biāo)識(shí)IPv6能力；開通激活及保障系統(tǒng)增加IPv6屬性傳遞和工單打印功能；計(jì)費(fèi)系統(tǒng)提供IPv6話單采集及IPv6流量計(jì)費(fèi)功能；各系統(tǒng)接口對(duì)IPv6屬性的傳遞。

4 結(jié)束語

綜上所述，從IPv4地址轉(zhuǎn)換的角度看，兩種過渡技術(shù)本質(zhì)均為NAT44技術(shù)，都具有NAT44技術(shù)的局限性。NAT444獨(dú)立于IPv6技術(shù)部署時(shí)為私網(wǎng)單棧，與IPv6共同部署時(shí)為私網(wǎng)雙棧，私網(wǎng)單棧無需改動(dòng)CPE，工作量相對(duì)較小，可較快緩解IPv4地址耗盡的問題，因此適合在短期內(nèi)需要大量釋放存量合法IPv4地址的場(chǎng)景，但不利于推動(dòng)IPv6技術(shù)的部署。DS-Lite技術(shù)需要網(wǎng)絡(luò)中部署IPv6技術(shù)，技術(shù)相對(duì)復(fù)雜，工作量較大，部署周期較長，但有利于推動(dòng)IPv6技術(shù)部署。

圖5 IT支撐系統(tǒng)改造點(diǎn)

在進(jìn)行網(wǎng)絡(luò)層面IPv6技術(shù)部署時(shí)，為保障業(yè)務(wù)的正常開展和網(wǎng)絡(luò)的日常運(yùn)維，必須需同步IP、IT支撐系統(tǒng)進(jìn)行全面的IPv6改造。

運(yùn)營商一旦決定部署過渡技術(shù)，一般來說都需要1～2年的時(shí)間進(jìn)行系統(tǒng)改造、技術(shù)方案驗(yàn)證、持續(xù)推進(jìn)部署等，需要投入大量的人力物力。因此，運(yùn)營商需要結(jié)合IPv4地址消耗情況、業(yè)務(wù)場(chǎng)景和演進(jìn)策略等綜合因素選擇合適的方案。

1 Yamagata I,Shirasaki Y,Nakagawa A,et al.NAT444 Draft-Shirasaki-NAT444-06.IETF Internet-Draft,July 2012

2 Durand A,Droms R,Woodyatt J,et al.Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion.RFC6333,August 2011

3 Yamagata I,Miyakawa S,Nakagawa A,et al.Common Requirements for Carrier-Grade NATs(CGNs).RFC6888,April 2013

4 Rekhter Y,Moskowitz B,Karrenberg D,et al.Address Allocation for Private Internets.RFC1918,February 1996

5 Weil J,Kuarsingh V,Donley C,et al.IANA-Reserved IPv4 Prefix for Shared Address Space.RFC6598,April 2012

6 Srisuresh P,Holdrege M.IP Network Address Translator(NAT)Terminology and Considerations.RFC2663,August 1999

7 Storer B,Dos Santos M,Toutain L,et al.Softwire Hub and Spoke Deployment Framework with Layer Two Tunneling Protocol Version 2(L2TPv2).RFC5571,June 2009