1. WAN接口是DOCSIS，DSL或是用于客戶邊緣路由設(shè)備的以太網(wǎng)網(wǎng)絡(luò)。

　　2. 思科網(wǎng)絡(luò)注冊(cè)員(CNR)既是DHCP-Server1也是DNS-Server。

　　3. TAR-Host1，REF-Host1和REF-Host2由當(dāng)前很普遍的操作系統(tǒng)組成，包括微軟Windows 7，Linux和蘋(píng)果Mac OS X Lion。

　　可觀察到的結(jié)果

　　這次測(cè)試對(duì)于去年慎重部署客戶邊緣路由有著至關(guān)重要的作用。一些必要的要求在這次測(cè)試中得到闡述，包括從大于/64的前綴池委派前綴，阻止轉(zhuǎn)發(fā)循環(huán)以及復(fù)制地址檢測(cè)。盡管這些部署已經(jīng)相比較以前的IPv6客戶邊緣事件而言具有更多改進(jìn)，但仍存在如下問(wèn)題：

　　1. Router Advertisement中的M和O標(biāo)記。

　　2. 路徑指定前綴。

　　3. 沒(méi)有路由可用。

　　4. 沒(méi)有地址可用。

　　5. 支持6RD。

　　不過(guò)這里面有些問(wèn)題已經(jīng)得到解決，且在解決后又進(jìn)行了重新測(cè)試。

　　Router Advertisement中的M 和O標(biāo)記

　　最近關(guān)于IETF的討論，熱議的話題是可否用Router Advertisement中的M和O標(biāo)記控制客戶邊緣路由的DHCP客戶端。下面的表格記錄了M和O標(biāo)記對(duì)啟動(dòng)DHCP客戶端和DHCP前綴代表的客戶邊緣路由有何影響。

　　如上面表格顯示的，部署會(huì)根據(jù)M和O標(biāo)記的配置發(fā)生變化。有些部署把O標(biāo)記當(dāng)做打開(kāi)前綴代表的指示器。不過(guò)，這種行為不符合RFC 6204，因?yàn)樗鼤?huì)指明應(yīng)該完成前綴代表而不看M和O標(biāo)記的狀態(tài)。其他部署會(huì)忽視標(biāo)記且經(jīng)常獲取DHCP IA_NA和IA_PD。對(duì)于目前的RFC 6204來(lái)說(shuō)這是可以接受的。多變且不一致的客戶編譯路由設(shè)備表明IETF需要進(jìn)一步說(shuō)明M和O標(biāo)記與客戶編譯路由設(shè)備中DHCP之間的關(guān)系。由此可見(jiàn)，目前的要求導(dǎo)致我們要根據(jù)M和O標(biāo)記的配置進(jìn)行部署。這樣就會(huì)導(dǎo)致管理員和運(yùn)營(yíng)商對(duì)DHCP客戶端的運(yùn)行出現(xiàn)不理解和誤配置。

　　路徑指定前綴

　　DHCP前綴授權(quán)是用來(lái)從指定路由到請(qǐng)求路由委派長(zhǎng)期前綴的機(jī)制。這樣互聯(lián)網(wǎng)服務(wù)供應(yīng)商就可以為客戶邊緣路由器指定前綴。在前期測(cè)試中，從大于/64的指定池中為L(zhǎng)AN指定前綴似乎在部署中會(huì)出現(xiàn)問(wèn)題。盡管如此，在最近的測(cè)試中，測(cè)試宣稱可以從/60和/52指定池中為L(zhǎng)AN網(wǎng)絡(luò)指定一個(gè)/64前綴。另一個(gè)重要的組件就是恰當(dāng)?shù)貙?duì)指定的和非指定前綴進(jìn)行路徑選擇。如果前綴的路由出錯(cuò)會(huì)導(dǎo)致轉(zhuǎn)發(fā)循環(huán)以及網(wǎng)絡(luò)流量超載。

　　為了測(cè)試指定前綴的路徑而創(chuàng)設(shè)了以下條件。一個(gè)DHCP服務(wù)器通過(guò)DHCP前綴授權(quán)為客戶邊緣路由器指定了一個(gè)/60前綴?？蛻暨吘壜酚善麟S后從/60指定前綴池中為L(zhǎng)AN接口指定了一個(gè)/64前綴，并宣告前綴位于Router Advertisement中。一個(gè)IPv6 Host，常見(jiàn)拓?fù)浣Y(jié)構(gòu)中的TAR-Host1，被附加到LAN網(wǎng)絡(luò)發(fā)送要發(fā)往/60指定前綴池的IPv6地址。地址的節(jié)點(diǎn)識(shí)別符并不重要，因?yàn)闆](méi)有指定前綴。

　　有些客戶邊緣路由部署為從非指定前綴發(fā)往TAR-Router1的數(shù)據(jù)包尋找路由，這是默認(rèn)的路由而非無(wú)效目的地。TAR-Router1將客戶邊緣路由作為指定前綴的下一次跳轉(zhuǎn)，并且為數(shù)據(jù)包尋找回到客戶邊緣路由的路徑。這種操作會(huì)導(dǎo)致循環(huán)轉(zhuǎn)發(fā)以及網(wǎng)絡(luò)流量超載。

　　在所述情況下此前未觀察到的操作是為了響應(yīng)數(shù)據(jù)包(假定被授權(quán)但未指定的前綴)對(duì)ICMPv6 Redirect信息進(jìn)行轉(zhuǎn)發(fā)。這些信息類型表明客戶邊緣路由為整個(gè)授權(quán)前綴池指定了一個(gè)通向LAN接口的路徑，而不僅僅是分配的/64前綴。這種操作會(huì)出現(xiàn)問(wèn)題，因?yàn)镮Pv6主機(jī)會(huì)嘗試為連接中的數(shù)據(jù)選擇路由，這會(huì)再次導(dǎo)致網(wǎng)絡(luò)流量超載以及應(yīng)用故障。大多數(shù)部署都會(huì)解決這類操作并在最后在測(cè)試后期進(jìn)行糾正。

　　無(wú)路由可用

　　當(dāng)WAN接口上的客戶邊緣路由無(wú)有效路由使用時(shí)，路由器必須將一個(gè)路由周期為零的Router Advertisement發(fā)送給LAN接口，這個(gè)接口會(huì)告訴主機(jī)不要把這個(gè)設(shè)備作為默認(rèn)路由器使用。測(cè)試中的三個(gè)路由器發(fā)送了三個(gè)默認(rèn)路由周期大于零的Router Advertisement而不是一個(gè)路由周期為零的Router Advertisement。這樣即會(huì)告訴LAN網(wǎng)絡(luò)中的IPv6主機(jī)有路由可用，而事實(shí)卻是沒(méi)有有效路由，由此可能導(dǎo)致網(wǎng)絡(luò)中的不當(dāng)路徑選擇。

　　另有一個(gè)路由器發(fā)送的LAN上Router Advertisement默認(rèn)路由周期優(yōu)先于WAN接口的Router Advertisement。一旦默認(rèn)路由周期為零的Router Advertisement被WAN接口接收，那么客戶邊緣路由就會(huì)發(fā)送LAN接口上默認(rèn)路由周期為零的Router Advertisement。雖然這種操作并未被IETF標(biāo)準(zhǔn)禁止，但是如果第二個(gè)路由周期為零的Router Advertisement丟失，IPv6主機(jī)就會(huì)出現(xiàn)延時(shí)。

　　無(wú)地址可用

　　在測(cè)試中有一個(gè)重要的情境無(wú)法進(jìn)行測(cè)試，因?yàn)镈HCP服務(wù)器和客戶邊緣路由支持無(wú)地址情況的處理。當(dāng)客戶邊緣路由被授權(quán)一個(gè)無(wú)效前綴時(shí)會(huì)出現(xiàn)這種情況，不過(guò)服務(wù)器上沒(méi)有DHCP客戶端單點(diǎn)播放地址可用。在試圖使用無(wú)狀態(tài)全球地址的網(wǎng)絡(luò)中這種情況會(huì)加劇，因?yàn)榫W(wǎng)絡(luò)沒(méi)有要求提供有狀態(tài)的DHCP地址。不過(guò)，仍然需要DHCP前綴授權(quán)。下面詳細(xì)解釋了初始RFC和更新后RFC。

　　客戶邊緣路由器會(huì)在DHCP Solicit中請(qǐng)求IA_NA和IA_PD，不過(guò)會(huì)接收到一個(gè)有NoAddrsAvail狀態(tài)代碼選項(xiàng)的DHCP Advertise，它指明了無(wú)有效地址。在DHCP Advertise中接收NoaddrsAvail選項(xiàng)的客戶邊緣路由不會(huì)處理余下選項(xiàng)。

　　據(jù)RFC 3315的要求，一個(gè)DHCP服務(wù)器必須進(jìn)行如下操作：“如果服務(wù)器不能為客戶端連續(xù)請(qǐng)求的IA指定任何地址，那么服務(wù)器必須發(fā)送Advertise信息給客戶端，這一信息中要包含一個(gè)有NoAddrsAvail代碼的狀態(tài)代碼選項(xiàng)以及一條給用戶的狀態(tài)信息，一個(gè)帶有服務(wù)器DUID的服務(wù)器識(shí)別符選項(xiàng)以及一個(gè)帶有客戶端DUID的客戶端識(shí)別符選項(xiàng)。”同樣，客戶端必須根據(jù)RFC 3315的規(guī)定進(jìn)行相對(duì)應(yīng)的操作：“客戶端必須忽略任何包括狀態(tài)代碼選項(xiàng)(內(nèi)含NoAddrsAvail)的Advertise 信息，除非客戶端可以向用戶顯示相關(guān)狀態(tài)信息。”

　　IETF在2010年發(fā)布的正誤表更改了RFC 3315中的描述。RFC現(xiàn)在這樣規(guī)定：“如果服務(wù)器不能為客戶端發(fā)出的連續(xù)請(qǐng)求中的IA指定地址，那么服務(wù)器必須為客戶端發(fā)送一條Advertise信息，其中包括含有NoAddrsAvail狀態(tài)代碼的選項(xiàng)，給用戶的狀態(tài)信息，帶有服務(wù)器DUID的服務(wù)器識(shí)別符選項(xiàng)以及帶有客戶端DUID的客戶端識(shí)別符選項(xiàng)。” 服務(wù)器應(yīng)該包含其他有狀態(tài)的IA選項(xiàng)(如IA_PD)以及Advertise 信息中的其他配置選項(xiàng)。

　　同樣DHCP客戶端的規(guī)則也進(jìn)行了更新：“客戶端必須忽略任何Advertise信息，包括含有NoAddrsAvail的狀態(tài)代碼項(xiàng)，除非客戶端可以向用戶顯示相關(guān)狀態(tài)信息。”

　　因此，對(duì)于未來(lái)的測(cè)試，UNH-IOL會(huì)使用更新后支持發(fā)送NoAddrsAvail狀態(tài)代碼項(xiàng)的DHCP服務(wù)器。當(dāng)帶有NoAddrsAvail的狀態(tài)代碼項(xiàng)被發(fā)送到IA外時(shí)，發(fā)送DHCP Solicit的部署只有IA_PD獲取了前綴。

　　支持6RD

　　在12個(gè)邊緣路由部署中的有8個(gè)支持6RD。6RD是一種允許網(wǎng)絡(luò)運(yùn)營(yíng)商在現(xiàn)有IPv4網(wǎng)絡(luò)基礎(chǔ)上推出IPv6的機(jī)制。所有的部署都可以使用6RD DHCPv4選項(xiàng)來(lái)請(qǐng)求6RD參數(shù)。除了一個(gè)邊緣路由之外，其他都要被配置為使用6RD;另一個(gè)則是在接收到6RD DHCPv4選項(xiàng)時(shí)開(kāi)始使用6RD。應(yīng)注意到，在同時(shí)可用的情況下，邊緣路由傾向于把Ipv6流量導(dǎo)入所創(chuàng)建的6RD隧道而不是本地IPv6接口。

　　結(jié)論

　　IPv6是互聯(lián)網(wǎng)訪問(wèn)的首選，因?yàn)镮Pv4地址殆盡。把IPv6部署到客戶邊緣設(shè)備中是很重要的事情，這樣運(yùn)營(yíng)商就可以使用IPv6。此次測(cè)試的參與者也認(rèn)為IPv6在客戶邊緣路由器中的部署也逐漸成為現(xiàn)實(shí)。

　　而且，他們也打算盡快解決測(cè)試中出現(xiàn)的問(wèn)題。部署者非常有必要進(jìn)行全面測(cè)試，盡量減少問(wèn)題以確保IPv6的部署。而且也有必要了解其他詳細(xì)解釋轉(zhuǎn)發(fā)機(jī)制與本地IPv6互作的標(biāo)準(zhǔn)。

　　另外，UNH-IOL還將與IPv6論壇合作，創(chuàng)建一個(gè)IPv6 Ready CPE Logo項(xiàng)目，幫助運(yùn)營(yíng)商和設(shè)備制造了解他們需要為全球IPv6部署提供怎樣的性能支持。在基本要求得到滿足后，一些新領(lǐng)域，如轉(zhuǎn)換機(jī)制，路徑選擇協(xié)議等還需要進(jìn)行新的測(cè)試。

yangkun