1. WAN接口是DOCSIS，DSL或是用于客戶邊緣路由設備的以太網網絡。

　　2. 思科網絡注冊員(CNR)既是DHCP-Server1也是DNS-Server。

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

　　可觀察到的結果

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

　　1. Router Advertisement中的M和O標記。

　　2. 路徑指定前綴。

　　3. 沒有路由可用。

　　4. 沒有地址可用。

　　5. 支持6RD。

　　不過這里面有些問題已經得到解決，且在解決后又進行了重新測試。

　　Router Advertisement中的M 和O標記

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

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

　　路徑指定前綴

　　DHCP前綴授權是用來從指定路由到請求路由委派長期前綴的機制。這樣互聯(lián)網服務供應商就可以為客戶邊緣路由器指定前綴。在前期測試中，從大于/64的指定池中為LAN指定前綴似乎在部署中會出現問題。盡管如此，在最近的測試中，測試宣稱可以從/60和/52指定池中為LAN網絡指定一個/64前綴。另一個重要的組件就是恰當地對指定的和非指定前綴進行路徑選擇。如果前綴的路由出錯會導致轉發(fā)循環(huán)以及網絡流量超載。

　　為了測試指定前綴的路徑而創(chuàng)設了以下條件。一個DHCP服務器通過DHCP前綴授權為客戶邊緣路由器指定了一個/60前綴?？蛻暨吘壜酚善麟S后從/60指定前綴池中為LAN接口指定了一個/64前綴，并宣告前綴位于Router Advertisement中。一個IPv6 Host，常見拓撲結構中的TAR-Host1，被附加到LAN網絡發(fā)送要發(fā)往/60指定前綴池的IPv6地址。地址的節(jié)點識別符并不重要，因為沒有指定前綴。

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

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

　　無路由可用

　　當WAN接口上的客戶邊緣路由無有效路由使用時，路由器必須將一個路由周期為零的Router Advertisement發(fā)送給LAN接口，這個接口會告訴主機不要把這個設備作為默認路由器使用。測試中的三個路由器發(fā)送了三個默認路由周期大于零的Router Advertisement而不是一個路由周期為零的Router Advertisement。這樣即會告訴LAN網絡中的IPv6主機有路由可用，而事實卻是沒有有效路由，由此可能導致網絡中的不當路徑選擇。

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

　　無地址可用

　　在測試中有一個重要的情境無法進行測試，因為DHCP服務器和客戶邊緣路由支持無地址情況的處理。當客戶邊緣路由被授權一個無效前綴時會出現這種情況，不過服務器上沒有DHCP客戶端單點播放地址可用。在試圖使用無狀態(tài)全球地址的網絡中這種情況會加劇，因為網絡沒有要求提供有狀態(tài)的DHCP地址。不過，仍然需要DHCP前綴授權。下面詳細解釋了初始RFC和更新后RFC。

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

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

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

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

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

　　支持6RD

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

　　結論

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

　　而且，他們也打算盡快解決測試中出現的問題。部署者非常有必要進行全面測試，盡量減少問題以確保IPv6的部署。而且也有必要了解其他詳細解釋轉發(fā)機制與本地IPv6互作的標準。

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

yangkun