摘要：對IETF的組織機構和工作流程進行了介紹，梳理了與IPv6相關的RFC和Internet-Draft，介紹了業界對現有標準的支持程度和運營商基于這些標準采取的演進方式。
1 引言
互聯網已經成為事實上的電信網絡載體，IPv6作為下一代互聯網協議棧將逐步取代IPv4已經成為共識。在電信領域目前的ITU-T，BBF，IEEE及IETF等幾大國際標準組織中，IETF對IPv6標準化進展起到的推動作用最大。IETF雖然不是互聯網的惟一標準化組織，但卻是互聯網基礎技術和底層協議的最初創建者和維護者。本文將圍繞IETF相關標準進展進行論述。
2 IETF組織結構及工作流程
IETF的正式文件為RFC，但RFC1796已經明確說明：不是所有RFC都是標準。而且所有的標準在提出之前都需要經過Internet-Draft階段。很多人并不是很清楚這一點，即使是數據網絡行業的從業者。為了對IETF就IPv6相關的標準和建議有個全面了解，有必要首先對IETF的工作流程和機構進行概要介紹。
首先，IETF（The Internet Engineering Task Force）是一個松散的、自律的、志愿的民間學術組織，由為互聯網技術工程及發展做出貢獻的專家自發參與和管理的國際民間機構。它匯集了與互聯網架構演化和互聯網穩定運作等業務相關的網絡設計者、運營者和研究人員，并向所有對該行業感興趣的人士開放，任何人都可以注冊參加IETF的會議。IETF年會是一群熱愛互聯網技術的人的論壇，每年輪流在世界各地召開3次會議，討論與網絡運行操作、網絡設備開發及軟件實現相關的解決方案，以及相互探討未來會普及的協議、標準和產品。除了每年3次、每次為期5天的面對面討論外，IETF工作組的許多工作是通過郵件列表（Mailing List）進行的。
IETF的標準工作分為8個重要的研究領域，分別是應用領域、通用領域、互聯網領域、操作與管理領域、實時應用和基礎設施領域、路由領域、安全領域和傳送領域，每個研究領域均有1~3名領域主管（Area Directors），負責本領域的日常運轉。每個領域又由多個工作組（Work Group）組成，每個工作組有1~2名工作組主席主持本組的日常工作。目前，針對IPv6協議、規范、過渡和演進比較活躍的工作組主要有互聯網領域的PPPext，SAVI，Softwire工作組；操作與管理領域的v6ops工作組；傳送領域的Behave工作組等。
與互聯網技術相關的任何想法和方案，理論上都有可能成為RFC，提交RFC需要經過如下幾個步驟：
（1）首先作者本人明確自己研究的技術屬于IETF哪個技術領域（Area），以及在這個領域中屬于哪個工作組（Work Group），然后有針對性地編寫、提交Internet-Draft文檔。
（2）參加IETF會議，并通過郵件列表參與廣泛討論，收集、歸納大家的評論和反饋。
（3）基于反饋意見對草案進行修改和完善。
（4）重復步驟1~3若干次。
（5）如果屬于個人草案，向所在領域的主管提出申請以便提交草案到IESG（互聯網工程組指導組）進行審核，如果為工作組草案，則由工作組主席向領域主管提交申請。
（6）所提交的草案會得到IETF成員更廣泛的審核，包括其他領域的專家，以便確保最終成為RFC的文檔具備較高的質量。
（7）在IESG的要求下進行必要修改和完善（包括根據要求放棄成為標準）。
（8）等待由RFC編輯最終發布文檔成為RFC。
3 RFC與Internet-Draft
RFC標準產生的過程是一種自下而上的過程，而不是自上而下，也就是說不是一個由主席或者由工作組負責人的一個指令，而是由下自發提出，然后在工作組里討論，討論了以后再交給工程指導委員會進行審查。如果想成為RFC，必須先提交Internet-Draft，這是一個必經的過程。互聯網草案還可以分為工作組文檔或個人文檔兩類，工作組文檔的命名規則是“draft-ietf-”后面緊跟工作組的名稱；如果是個人文檔，名稱為“draft-”后面緊跟作者的名字；版本都是以“nn.txt”為結尾，“00”代表第一版。
通常來說，IETF對Internet-Draft有一個定性的描述：Internet-Draft并不是IETF正式發布的技術規范，Internet-Draft沒有正式的狀態（都是意向狀態），并且可能隨時修改甚至因過期而廢止，如果在6個月之內沒有更新，草案自動廢止。所以在任何情況下都不建議將Internet-Draft作為論文、報告、應標文件（Request-for-Proposal）的參考依據，廠商也不應聲明他們的解決方案遵循某個Internet-Draft。
即使草案最終成為RFC，也需要清楚不是所有RFC都是標準這一原則。RFC文檔分為幾類，在IETF中采用狀態（Status）來表示：標準軌跡（Standard-Track），最佳實踐（Best Current Practices），信息參考（Informational），試驗性（Experimental）和歷史的（Historic）。根據IETF最初的想法，只有標準軌跡類型的RFC才能成為各廠家在實現相關技術時所必須遵循的標準。其中，Standard-Track又分為建議標準（Proposed Standard），草案標準（Draft Standard）和互聯網標準（Internet Standard）3個階段。截止到目前，共有123個涉及IPv6的RFC成為Proposed Standard，其中26個已經被廢止，需要說明的是，廢止它們的新的RFC未必是Proposed Standard，有可能是RFC的任何狀態。現在仍然有效的97個Proposed Standard RFC涵蓋的領域非常廣泛，主要涉及移動IPv6，IPv6路由，6PE（RFC4798），IPv6組播，DHCPv6，IPv6編址及架構，IPv6 MIB，IPv6Sec，Teredo（RFC4380），6 to 4（RFC3056），ICMPv6以及IPv6在L2協議上的封裝等方面。
無論是Draft Standard還是Proposed Standard，廠家根據設備在網絡中的定位和角色提供對標準有取舍的支持，例如核心設備不一定要支持6 to 4和Teredo隧道，固網設備不一定要支持移動IPv6的屬性，終端只需支持NDP，DHCP，ICMP等基本協議，而無需支持路由，6PE等。
如果算上BCP，Informational，Experimental等狀態的RFC，截至2010年5月31日，IETF已發布了與IPv6相關的RFC 268個 ，除去已廢止的49個，共有219個RFC。從圖1可見，目前研究熱點已經從IPv6基本路由協議，轉向IPv6過渡技術，IPv6用戶端設備（CPE）標準，IPv6接入認證（DHCPv6）等領域。
圖1 IPv6相關RFC類別和數量
IPv6過渡技術主要指針對協議轉換、地址翻譯、隧道封裝等技術方案的RFC，相關標準包括：
（1）IPv4向IPv6過渡框架、場景定義。
（2）IPv4/v6協議翻譯技術。
（3）IPv4/v6隧道相關技術。
（4）IPv6過渡地址格式定義。
（5）IPv6 DHCP相關標準定義。
（6）IPv6 DNS及DNS-ALG相關標準定義。
CPE方面主要指PPP認證，DHCP-PD更多考慮到路由型家庭網關應用環境；接入認證方面主要指終端地址分配方式從NDP向DHCPv6發展。
值得注意的是，有許多我們曾經非常熟悉的技術，例如NAT-PT（RFC2766-historic），NAT64（draft-ietf-behave-v6v4-xlate-stateful-11），Socks64（RFC3089-informational）等轉換技術，以及Tunnel Broker（RFC3053-informational），ISATAP（RFC5214-informational），IPv6 Tunnel Broker with the Tunnel Setup Protocol （TSP）（RFC5572-experimental），IPv6 over L2TP（draft-kuwabara-softwire-ipv6-via-l2tpv2-00）等隧道技術，甚至包括現在非常熱門的NAT444（draft-shirasaki-nat444-01），DS-Lite（draft-ietf-softwire-dual-stack-lite-04），6RD（RFC5569-informational），DNS-ALG（draft-durand-v6ops-natpt-dns-alg-issues-00），DNS64（draft-ietf-behave-dns64-09），DNS46（draft-xli-behave-dns46-for-stateless-02），IVI（draft-xli-behave-ivi-07）/DIVI（draft-xli-behave-xlate-partial-state-01），A+P（draft-ymbk-aplusp-05），PNAT（draft-huang-behave-pnat-01），SAVI（draft-ietf-savi-dhcp-03），絕大部分都不是RFC的Standard Track，很多是Informational狀態（其中NAT-PT為Historic，TB with TSP為Experimental），還有更多的目前仍然處于Internet Draft階段（其中DNS-ALG和L2TP已經過期），且這些Internet Draft的意向狀態也大多為Informational（DNS64的意向狀態是Standard Track）。如果嚴格按照IETF對Internet Draft以及非Standard Track RFC的定性，這些文檔是不能成為“標準”來指導設備開發的。但實際情況并非如此，設備廠商出于商業競爭和樹立行業領先地位等因素，紛紛對非Standard Track RFC甚至Internet Draft提供支持，許多草案階段的概念已經在現有設備上實現了，例如Juniper，Gogo6已經支持DS-Lite，Juniper，華為支持IPv6 over L2TP的LNS和LAC，Gogo6已經支持TB with TSP，Veno已經支持Socks64，思科即將支持IVI和6RD，華為計劃支持PNAT，NAT64和DS-Lite，國內很多中、低端交換機廠商已經支持SAVI，清華正在開發DIVI原型等。所以從以上分析，IETF RFC以及草案，無論是何種狀態或意向狀態，其本身都具有“標準”的內在特性和指導作用，設備廠商可以根據這些草案或RFC制定的交互協議字段細節進行源代碼編寫以實現文檔所描述的功能。從這方面來說，很多廠商忽略了狀態為Informational的RFC甚至Internet Draft不能作為標準依據的定性，仍然積極響應文檔中的建議并在設備中加以實現，這也是互聯網行業目前的真實現狀。
4 運營商基于現有標準采取的演進方式
作為電信運營商，在IPv4向IPv6演進過程中，會結合當前IPv6標準進展和技術成熟度選擇適合自己的過渡方式。目前，有3種主流的演進路線，分別是雙棧IPv4+IPv6，4over6隧道+IPv6和IPv4+6over4隧道。在實際部署中各種過渡方案可能會重疊和交錯。
雙棧方案用于尚有一定IPv4地址可用的運營商，便于其實現IPv4業務和IPv6業務的協同發展，平滑升級。這是最經濟、最穩妥的方案，實施風險較低，能夠留給IPv6充足的成熟時間。針對地址緊缺的運營商，也可能采用NAT444+IPv6的雙棧方案，此時需要重點解決NAT444帶來的私有地址運維，LSN設備性能，LSN在城域網中的部署方式（集中或分部），對ALG支持等問題上。解決這些問題的技術非常多，在IETF相關領域和工作組中的討論異常活躍，但由于沒有涉及IPv6，本文不做論述。總之，雙棧方案基本屬于被動等待演進—網絡運行平穩，但需要考慮IPv4私網地址規模使用存在風險。據了解，NTT是最早實現全網雙棧的運營商。
4over6隧道+IPv6的典型方案是DS-Lite隧道。法國電信、意大利電信、美國Comcast和西班牙電信已經在網絡中部署了DS-Lite，此方案適合于IPv4地址非常緊缺的運營商，以發展IPv6業務為主，尤其是IPv6接入業務，同時兼容IPv4業務。該方案直接對用戶分配IPv6地址，便于用戶統一管理，能夠簡化運維，緩解IPv4地址緊缺的壓力。當前DS-Lite面臨的最大問題是客戶端設備不成熟，已經部署的運營商采用的是定制的CPE（如法國電信采用自己制定企業規范，委托第三方代工生產的方式），沒有批量生產的商業化產品，此外DS-Lite沒有認證鑒權機制，這些不足會在一定程度上制約DS-Lite方案的推廣。采用純IPv6接入可以看作主動推進演進—過渡策略，但是隧道技術是否成熟存在風險。
IPv4+6over4隧道的代表技術是6RD。美國的AT&T以及Comcast部署了6RD。與6RD類似的解決方案為IPv6 over L2TP，有部分運營商采用了L2TP隧道來提供IPv6用戶遠程覆蓋。6RD和L2TP方案適用于IPv6業務發展的早期，運營商以IPv4業務為主，擁有少量的IPv6用戶。其優勢在于，有助于保護運營商的初期投資，減少對現網業務的影響。從IPv4過渡到IPv6一定是個漸近過程，用戶需要在不中斷IPv4業務的前提下逐漸培養用戶使用IPv6業務的習慣。此方案的問題在于不能大規模部署用戶，對IPv6的推廣力度較DS-Lite方式弱。
5 結束語
IPv6協議棧的標準還在不斷發展和完善，各種新思路、新方案層出不窮，基礎的標準已經成熟和穩定，例如IPv6協議規范、路由尋址、地址體系等。但是，在地址分配方式（NDP，DHCPv6，PPPv6），6~4或4~6轉換（含ALG），移動IP，6over4或4over6隧道，IPv6網絡管理等領域還有大量工作要做。此外，由于互聯網采用Client Server模型，最重要的參與者就是用戶終端和內容平臺之間的交互，軟件操作系統對IPv6的支持也日益迫切。從IPv6產業鏈角度看，運營商采購設備負責搭建IPv6骨干網絡和接入網絡，相對來說易于實現，而產業鏈的兩端——用戶和ICP，才是確保IPv6具有網絡生命力的根基。體現在IPv6標準方面，則需要進一步完善IPv6協議集，操作系統底層實現對IPv6的充分支持。另外，應用軟件要全面基于IPv6 Socket編程，提供包括P2P，網絡游戲，Web瀏覽等全面的IPv6應用，才是下一代互聯網真正得以普及的前提。
