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