馬 琳

（華為技術有限公司 北京100140）

1 前言

隨著互聯網IPv4公網地址資源的不斷消耗及IPv4地址資源的最終耗盡，解決IP地址問題成為全球都正在面臨的嚴峻問題，為應對IP地址危機，各個國家和地區(qū)都加大了對IPv6的部署力度。從2010年開始，包括中國在內的各國紛紛開始IPv6商用試點和技術的研究工作，推動IPv6快速走向商用，在IPv6發(fā)展過程中，業(yè)界也認識到IPv6的最終演進是一個漫長的過程，在IPv6過渡發(fā)展階段，也需要通過IPv6過渡技術研究解決IPv4地址不足問題的方案。

2012年3月29日，國家發(fā)展和改革委員會印發(fā)《下一代互聯網“十二五”發(fā)展建設的意見》通知，提出在“十二五”期間，互聯網普及率達到45%以上，推動實現三網融合，IPv6寬帶接入用戶數超過2 500萬人，實現IPv4和IPv6主流業(yè)務互通，IPv6地址獲取量充分滿足用戶需求。從目前狀況看，IPv4向IPv6的過渡是一項分階段、分規(guī)模的長期而復雜的系統(tǒng)工程，涉及技術、網絡、應用、用戶、終端以及政策環(huán)境、產業(yè)鏈等問題。

2 IPv6過渡技術的分類及部署

作為業(yè)界所形成的共識，下一代互聯網（IPv6）是解決IP地址緊缺的主要方式，但在具體部署時，IPv6雙棧雖可以解決IPv6演進問題，卻無法解決IPv4地址緊缺的現狀問題，因此在網絡進行IPv6雙棧改造的基礎上，需重點考慮IPv6過渡技術的部署和選擇。截至目前，業(yè)界主流的IPv6過渡技術有很多，包括：私網雙棧（雙棧+NAT）、DS-Lite和Smart6/NAT64等，技術分類如圖1所示。

圖1 IPv6過渡技術分類

IPv6過渡技術種類不同，對網絡、支撐系統(tǒng)和終端的要求也不同，具體見表1。以終端為例，雙棧+NAT444（私網雙棧）對終端沒有特殊要求，橋接型和路由器CPE都可以配合，考慮到對PC操作系統(tǒng)的屏蔽和IPv6用戶發(fā)展的要求，優(yōu)先選擇路由型CPE方式。而DS-Lite要求終端必須為路由型CPE，而且必須支持DS-Lite特性，由此可以看出IPv6過渡技術選擇需綜合考慮多維度因素，并可能根據網絡和終端變化發(fā)生變化。

表1 不同的過渡技術對網絡、支撐系統(tǒng)和終端的要求

圖2 IPv6過渡技術部署場景

對于IPv6過渡技術部署的選擇，需要根據網絡情況、終端情況和地址緊缺程度等多個綜合因素統(tǒng)籌考慮。根據網絡實際的發(fā)展情況，考慮IPv6雙棧演進中的地址問題，中國電信在IPv6過渡方案中選擇了私網雙棧和DS-Lite等技術，針對不同的IPv6過渡技術，現網部署中包括集中式和分布式等不同場景，如圖2所示。

IPv6過渡技術按照技術選擇的不同和部署位置的差別會出現不同的應用場景，在IPv6過渡技術實際部署過程中，需要統(tǒng)籌考慮對承載網、業(yè)務的影響，設備成本和運營成本的對比以及對網絡未來演進的影響等多個方面，如對于部分智能管道業(yè)務應用來說，需要對用戶屬性信息進行聯動和控制，集中式CGN部署將對業(yè)務開展產生較大影響，基于現網BRAS插卡支持的分布式CGN方案，在簡化網絡設計要求、減少對現有業(yè)務影響、降低故障節(jié)點數量和簡化定位難度等多個方面具備顯著優(yōu)勢，將成為運營商現網IPv6過渡技術部署的主要應用場景。

綜上所述，IPv6過渡技術的選擇和部署，需要立足現網、面向未來，根據場景不同存在不同選擇，而且從技術發(fā)展角度看，也存在新的技術發(fā)展方向，因此如何基于現網設備有效兼容各種IPv6過渡技術，并具備面向未來的平滑演進能力，成為運營商在IPv6及過渡技術部署及商用實施中需要重點關注的問題。

3 IPv6過渡技術平滑演進方案

對于IPv6過渡技術部署，現階段中國電信有兩種主要的技術選擇：雙棧+NAT444（私網雙棧）和DS-Lite，其代表的路線是向IPv6演進的兩條重要路線。從現網部署角度出發(fā)，對于不同的終端類型和需求場景，IPv6過渡技術的部署可能存在差異，但從保護設備投資及未來發(fā)展演進的角度，基于相同設備實現IPv6過渡技術的平滑演進顯得更為重要，使得網絡建設方案可以更好地適用于不同的IPv6過渡技術應用場景。

IPv6演進會經歷不同的發(fā)展階段，在這個過程中需要協調好網絡演進、投資與增長之間的關系。在過渡期間要解決IPv4地址緊缺帶來的發(fā)展瓶頸問題，但IPv6目前無法帶來新業(yè)務，因此也要控制投資規(guī)模。所以，新技術的引入和部署也必須遵循對網絡和業(yè)務影響的最小化原則。IPv6平滑演進方案優(yōu)先考慮實現平滑切換，而平滑即意味著流程自動化，用戶無感知。

3.1 應用場景

IPv6過渡技術平滑演進的應用和部署主要針對現網BRAS/MSE設備內置CGN板卡的情況，接入的家庭終端是路由型CPE，這樣在不更換硬件板卡和軟件的情況下，實現了從雙棧+NAT444到DS-Lite技術的平滑升級及切換。

考慮到設備內置IPv6 CGN單板的可擴展性、IPv6的日漸成熟以及網絡和周邊系統(tǒng)對IPv6滿意度的提升，需要在同一塊IPv6 CGN單板上實現多種技術的平滑演進和靈活切換。過渡技術平滑切換，即兩種或兩種以上過渡技術在同一塊CGN單板上共存或靈活切換，目前具體包含2個場景，見表2。

表2 過渡技術平滑切換的兩個場景描述

從表2可以看出，從發(fā)展演進角度存在的場景主要是從現階段私網雙棧平滑升級到DS-Lite模式，既可以使得現網設備部署具備面向未來演進的能力，同時也可以有效解決部分私網雙棧和DS-Lite混合接入的情況，如DS-Lite為主部署的區(qū)域，部分業(yè)務承載必須使用雙棧模式，此時需要考慮混合接入場景。對于場景二來說，主要考慮DS-Lite等IPv6過渡新技術出現故障時的快速回退方案，使得整個IPv6過渡技術系統(tǒng)設計更加穩(wěn)定、安全。

3.2 解決方案

IPv6過渡技術平滑演進解決方案重點解決的問題有：用戶終端的平滑升級、業(yè)務網關內置CGN板卡的平滑切換和IT支撐系統(tǒng)的統(tǒng)一配套等，根據接入用戶屬性的變化，通過IT支撐系統(tǒng)觸發(fā)各個系統(tǒng)實現平滑切換，實現用戶側無感知，網絡側變化小，并最終實現低成本、低風險的目標。解決方案架構如圖3所示。

IPv6過渡技術平滑演進需要終端、業(yè)務網關和支撐系統(tǒng)之間的相互協同配合，更重要的是需要運營商在網絡和配套系統(tǒng)規(guī)劃時，充分考慮未來IPv6過渡技術的平滑演進需求，以便為后期IPv6過渡技術平滑演進的實施奠定基礎。

由此可見，通過對網絡設備IPv6 CGN的預先規(guī)劃考慮，支持IPv6過渡技術的平滑演進，并能夠在不更換軟硬件的基礎上進行靈活切換，對于運營商的IPv6部署和平滑演進非常重要，因此IPv6過渡技術平滑演進能力必將成為向IPv6演進過程中的一種基礎能力。

對于雙棧+NAT444和DS-Lite的靈活切換，關鍵在于用戶屬性的改變，需要IT支撐系統(tǒng)的后臺進行一系列系統(tǒng)配套修改，包括CRM（客戶開戶管理）系統(tǒng)、BOSS開通、資源管理、認證計費系統(tǒng)、EOMS工單系統(tǒng)、運維網管系統(tǒng)等，同時需要將改動同步到AAA服務器。不同的IP城域網處理情況不盡相同，如某些局點不需要CRM同步到AAA服務器，用戶屬性和設備屬性的修改都在AAA服務器上進行，具體遷移過程也要適配現網。過渡技術平滑切換的具體流程如圖4所示。

IPv6過渡技術平滑演進時，為了實現后臺自動化，具備運營能力，在平滑切換中會涉及多個流程和系統(tǒng)的改造。這個過程分為4個部分。

圖3 IPv6過渡技術平滑演進解決方案架構

圖4 過渡技術平滑切換的具體流程

·OSS完成批量用戶類型變更申請，涉及CRM、業(yè)務開通和資源管理系統(tǒng)的改造。

·OSS重新下發(fā)配置模板給ONT。涉及業(yè)務開通系統(tǒng)、ITMS等系統(tǒng)的改造。如終端通過NMS管理，還包括自激活、NMS和相關設備。

·OSS通知AAA服務器進行用戶類型切換，涉及AAA系統(tǒng)的改造以及BRAS設備的支持能力。

·ONT重新上線觸發(fā)用戶域切換，需要終端同時支持DS-Lite和NAT444兩種過渡技術，且事先通過ITMS遠程下發(fā)用戶變更后的業(yè)務模板和配置參數。

通過設備和系統(tǒng)之間的配合，可以實現批量用戶的部署與切換以及個別用戶的遷移和回退工作，分別介紹如下。

（1）OSS完成批量用戶類型變更申請

OSS完成批量用戶類型變更申請的流程如圖5所示。

CRM通過修改用戶屬性，驅動支撐系統(tǒng)進行用戶平滑切換。業(yè)務開通系統(tǒng)獲得信息后向資源管理系統(tǒng)申請資源，資源管理系統(tǒng)確認網絡設備類型可以支持DS-Lite和NAT444，并返回資源配置結果。業(yè)務開通系統(tǒng)獲得回復后，根據結果選擇不同的配置模板通過ITMS下發(fā)給終端。

圖5 OSS完成批量用戶類型變更申請的流程

需要注意，在變更用戶類型時，OSS要查詢該區(qū)域用戶是否具備切換能力。

（2）OSS重新給ONT下發(fā)配置模板

OSS重新給ONT下發(fā)配置模板的流程如圖6所示。

業(yè)務開通系統(tǒng)從資源管理系統(tǒng)獲得資源配置結果后，向ITMS發(fā)出配置指令。ITMS可以配置兩套配置模板，接收到用戶類型切換的指令時，選擇不同的配置模板下發(fā)給終端，也可以采用通用模板，下發(fā)不同的參數以控制終端選擇私網雙?；蛘逥S-Lite。如果通過NMS管理終端，則需要通過自動激活系統(tǒng)和NMS給終端下發(fā)相關的配置。同樣可以下發(fā)模板或參數。

（3）OSS通 知AAA系 統(tǒng) 進 行 用戶類型切換

OSS通知AAA系統(tǒng)進行用戶類型切換的流程如圖7所示。

OSS除了通知終端修改配置外，還要通知AAA系統(tǒng)和網絡設備刷新用戶所對應的域名。在AAA系統(tǒng)中，域名是一個重要的屬性，是標識相同類型用戶的重要參數，在接收到業(yè)務開通系統(tǒng)的通知后，即刷新用戶到新的域中。而在ME60上，通過域的切換，可以靈活平滑實現用戶在不同域中的成員身份。

（4）ONT重 新 上 線 觸 發(fā) 用 戶 域切換

ONT重新上線觸發(fā)用戶域切換的流程如圖8所示。

在ONT收到ITMS下發(fā)的指令后，重新加載了新的配置模板，此時終端會重新發(fā)起撥號認證。與此同時，AAA服務器在接到業(yè)務開通系統(tǒng)的用戶所在域變更請求后，也刷新了用戶的賬戶信息。

此時基于ME60具備同時支持NAT444和DS-Lite部署運行的功能，具備了相應的能力，可以根據終端用戶撥號后AAA服務器返回的域結果，進行靈活的地址和資源分配，從而實現了過渡技術的平滑切換。

圖6 OSS重新給ONT下發(fā)配置模板的流程

圖7 OSS通知AAA系統(tǒng)進行用戶類型切換的流程

圖8 ONT重新上線觸發(fā)用戶域切換的流程

3.3 價值

IPv6過渡技術平滑演進方案使得運營商在IPv6過渡技術的選擇和部署方面更加靈活，同時解決了運營商后續(xù)演進的“后顧之憂”，運營商可以預先做好網絡和支撐系統(tǒng)的規(guī)劃，本著“邊發(fā)展、邊升級、邊演進”的原則，在不同階段和場景下引入不同的IPv6過渡技術場景，而又不必擔心設備投資浪費和大的網絡改動，真正實現對現網網絡投資的保護，同時實現了系統(tǒng)化考慮整個平滑演進過程中的各個流程，最大程度地降低人為干預和運維壓力，為運營商現網實施提供良好的條件和基礎。

2011年，中國電信股份有限公司江蘇分公司（以下簡稱江蘇電信）作為集團試點，進行多種IPv6過渡技術的現網驗證測試，分析對于不同終端和區(qū)域環(huán)境，存在多種IPv6過渡技術共存的情況，如果能夠實現IPv6過渡技術的平滑切換，則可以有效避免投資浪費問題。通過與華為技術公司的緊密合作驗證和測試，最終有效實現了基于路由型CPE通過ITMS更改配置，現網CGN設備無需更改軟硬件即可完成從私網雙棧到DS-Lite的平滑切換，保障用戶無感知、網絡無感知、設備無感知，真正實現“零改動”平滑切換，從而保障現有網絡IPv6 CGN設備的投資不被浪費，最大程度地降低了技術選擇和網絡投資的風險，也使得整個IPv6網絡系統(tǒng)具備更強的未來演進能力。

4 結束語

隨著全球IPv4地址枯竭危機的加劇，IPv6網絡改造和商用部署的腳步逐漸加快，但不可否認的是，端到端IPv6流程和產業(yè)鏈打通還需要時間，最終形成從IPv4過渡到全部IPv6的網絡環(huán)境還需要一個很長的過程，因此IPv6過渡技術的部署在現階段是至關重要的。而業(yè)界IPv6過渡技術的研究和選擇又由于場景和業(yè)務需求的不同而存在差異化，因此在實際網絡部署中，應充分考慮各種IPv6過渡技術的平滑演進，降低技術選擇風險成為IPv6過渡技術實際部署的重點。

華為技術公司作為全球下一代互聯網的最佳踐行者，從2009年開始，與中國電信在IPv6商用試點項目中緊密合作，歷經3年，先后形成“低成本、可復制”的長沙模式、“兼容并蓄、平滑演進”的無錫模式等成果；2012年，與江蘇電信成功合作IPv6過渡技術平滑切換的現網驗證，充分實現了“從現網問題出發(fā)，最終服務現網業(yè)務”的技術特點，在技術創(chuàng)新的同時充分考慮部署中面臨的問題，為IPv6最終成功走向商用奠定了堅實的基礎。

1 RFC 6333.Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion,2010

2 RFC 6146.Stateful NAT64:Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers,2011

3 RFC 6264.An Incremental Carrier-Grade NAT(CGN)for IPv6 Transition,2009