draft-chown-v6ops-call-to-arms-02

http://tools.ietf.org/html/draft-chown-v6ops-call-to-arms-02

World IPv6 Day Call to Arms . draft-chown-v6ops-call-to-arms-02

世界IPv6日的呼籲

原作者:T. Chown

翻譯者:TingYun Chi (louk)　[我都亂翻譯，後面時間不夠都沒有全部翻譯，建議看原文]

簡介: 網際網路協會(ISOC)公告了2011/6/8為世界IPv6日，在那一天某些主要的組織將他們的內容服務開啟對IPv6連線的支援(IPv4/IPv6雙協定)。藉由Google、Facebook在他們的商業服務啟動IPv6支援，我們可以預期看到超越過去的IPv6網路流量產生。由於這個理由，現在似乎應該呼籲系統和網路管理者重新檢視他們的IPv6連線能力，以減輕IPv6日當天可能發生的連線問題。同時在當天產生的流量也是一個機會檢視觀察IPv6流量的行為和效能，因此這需要適合的網路量測工具。我們將從網路和應用服務角度來討論可能適合的工具。

內容:

1. 簡介


2. 網路連線議題(Connectivity Issues)


3. 
   
   
   
   1. 沒有接受管理的隧道連線(Unmanaged Tunnels)
   
   
   2. 隧道代理者連線的第一跳延遲(Tunnel Broker first-hop delays )
   
   
   3. 連線逾時(Connection Timeouts)
   
   
   4. 路徑最大傳輸單元協調(PMTU Discovery)
   
   
   5. 流氓路由器廣播(Rogue Router Advertisements)
   
   
   6. 隧道連線效能(Tunnel performance )
   
   
   7. 具有AAAA(IPv6)域名紀錄，但服務並未啟動(AAAA record advertised but service not enabled )
   
   
   8. 監控訊息(Instrumentation )
   
   
   
   


4. IPv6流量(IPv6 traffic levels)


5. 
   
   
   
   1. 網路流量紀錄(Network flow records )
   
   
   2. 終端使用者成功存取網頁服務的比例(Client Web Access Success Rate)
   
   
   3. 用來分析IPv6連線失敗的工具(Tools to measure IPv6 brokenness)
   
   
   4. IPv4效能比較(IPv4 Performance Comparison)
   
   
   5. 使用者(User Tickets)
   
   
   6. 安全監控(Security monitoring)
   
   
   7. 純IPv6測試(IPv6-only testing)
   
   
   
   


6. 結論(Conclusions)
   
   

01 簡介:

儘管IPv4位址即將枯竭，IPv6的佈署仍然相當受限。為了要鼓勵相關單位進行測試應用服務產品的佈署，國際網路協會(ISOC)宣布2011/6/8為世界IPv6日。相關組織被鼓勵在這一天測試他們的產品啟動IPv6，不管是啟動終端使用者的網路或是啟動IPv6之應用服務。以現在的時間點來說，這一般是指啟動雙協定網路與內容服務。然而純IPv6網路也是不可避免的，部分網站也許交會利用這天測試一些IPv6佈署解決方案或形式。本文件主要有兩個目的，第一個目的是討論六月八號當天可能發生的一般性連線問題，相關討論是基於IPv4/IPv6雙協定網路環境的前提下(大部分的網站似乎都將採取雙協定進行服務)(翻譯註:我想大概也不會有人有勇氣只推IPv6把額外的99%網路流量推於門外)。大部分文中的討論集中於網站或企業網路啟動IPv6可能會有的影響，但也可以作為其他情況的參考。挑出這些議題，將有助於增加這些問題的了解並緩和問題的發生。另外一個目的是鼓勵企業思考在那一天如何觀察他們的網路情況與服務，利用這一天佈署相關的監控工具將長期有效的提供網路環境監控資訊，即使在六月八日之後。

對於大部分的網路內容提供網站，六月八日將是一個將IPv6啟動測試的機會(將www.example.com啟動IPv6連線，而非www.ipv6.example.com的測試形式)。對於任何佈署IPv6的組織，啟動對外的網路服務(網站)之IPv6是合理的第一步。部分企業或許會選擇啟動使用者所在的子網路IPv6連線能力，然而只在世界IPv6日啟動一天將無法調整網路至最佳狀態，建議最好將使用者網路環境提前於那天之前就啟動並調整。對於某些網路啟動IPv6是相當合適的，對於歐洲學術無線網路環境啟動IPv6與底層的802.1x管制技術不會有影響。這裡應該強調世界IPv6日是一個"實驗"或"對IPv6之挑戰測試"，組織必須要認真的思考，如果想要佈署並持續啟動IPv6。(翻譯註:建議大家網站測試一天，蒐集相關發生的疑難雜症，之後嘗試解決一下問題再推出正式的服務)。同樣地，透過量測資訊持續的改進IPv6網路網穩定度，例如改善ICMPv6過濾條件，這些作為將對於網路長期帶來正面的幫助。測試當天所帶來的一些"影響"不應該被視為問題，如果能獲取改善這些問題的資訊，投入世界IPv6日所花的人力物力將十分值得。當天應該會有問題發生，不過能夠了解當天發生的問題並嘗試解決。

這份文件同時有一個小章節討論了一些可能用在IPv6測試的工具。

(註:這份文件還非常的原始，我們歡迎任何的建議，正式版本預定於六月發表)

02 網路連線議題(Connectivity Issues)

在這個章節，我們將檢視常見的IPv6連線議題。目標是降低或減輕可能的影響。有些議題，例如交換(transit)並沒有被討論到，目前主要強調在末端網路使用者在IPv6當天可能遭遇的問題，同時列出來順序並不代表哪個問題比較嚴重(翻譯註:其實都蠻嚴重的)

2.1 沒有接受管理的隧道連線(Unmanaged Tunnels)

其中一個可能會造成連線問題就是使用非經管理的隧道連線，特別不是ISP所提供的自動隧道連線機制。例如6to4(RFC3056)、6to4 Relay(RFC3068)中提到的，一個純IPv6使用者要與6to4使用者通訊，必須要經過6to4中繼伺服器(Relay)，這個伺服器過去與回來可能同一個或不同一個中繼伺服器。如果純IPv6的使用者無法建立與6to4 relay連線之能力，將無法與6to4(2002::/16)使用者通訊。相似的，6to4路由器如果沒有辦法透過IPv4 Anycast位址連接到6to4中繼伺服器，也會造成連線無法建立。此外部分防火牆會阻止協定41(6to4)封包，也會造成問題。在Geoff Huston於IETF80會議中提出的簡報，將近15%的6to4連線是失敗的，同時6to4帶來約1.2秒的連線延遲。其中一個解決的方式是鼓勵網路管理者或網路提供商(ISP)提供6to4 relay。(翻譯註:日本於國際出口安裝6to4 relay伺服器服務，部分ISP也採用6to4的進階6rd進行IPv6連線佈署)。在[I-D.carpenter-v6ops-6to4-teredo-advisory].討論到如何佈署6to4能夠提供較穩定的服務，但是[I-D.troan-v6ops-6to4-to-historic].也討論到並得出建議- 6to4不是佈署IPv6連線的預設選項。現在有些CPE裝置預設開啟了6to4連線以提供IPv6服務，在IPv6日當天可能會遭遇到問題。同樣的 Teredo protocol [RFC4380]也被認為是一個大問題，將近有35%的連線失敗，伴隨著1-3秒的延遲。連線失敗主要來自於Teredo 依賴UDP打洞的機制連線，但這可能會被防火牆所阻擋。

2.2 隧道代理者連線的第一跳延遲(Tunnel Broker first-hop delays )

IPv6隧道代理者服務，SixXs與Hurricane Electric提供相對於6to4較為穩定的連線。如果你的ISP在IPv6日中無法提供IPv6連線服務，或許你該考慮註冊並使用這個連線參與測試。除了在IPv6日測試之外，你也可以考慮在測試日之後持續使用，直到你的ISP提供IPv6連線服務。當使用Tunnel Broker連線時，最重要的是選擇Round trip time最小的服務商，SixXs與HE在許多國家都有TtunnelBroker伺服器提供服務，如果選擇非所在國家的伺服器可能會有150ms的額外延遲。

2.3 連線逾時(Connection Timeouts)

當雙協定作業系統、或是跑在上面支援雙協定軟體能夠選擇使用IPv4或IPv6進行連線，預設將以IPv6進行連線，此時可能會遭遇到連線逾時的問題。這個問題形成的原因在IPv6連線無法取得服務，舉例來說網頁伺服器可能註冊了IPv4(A)與IPv6(AAAA)紀錄，但使用者與伺服器之間的IPv6連線發生問題，在作業系統或應用服務判斷無法連線並改用IPv4連線將會造成服務的延遲。(翻譯註:IPv6發展如同IPv4發展初期，部分ISP之間的連線可能會發生問題。當問題發生時，以微軟的作業系統將會延遲30秒切換到IPv4，蘋果的約要兩分鐘) 。這個原因形成的原因是因為IPv6預設為優先的通訊協定，接下來是IPv4，最後才是IPv6 tunnel連線。[偷懶少翻譯一段opera上會有這個問題..因為其實幾乎大部分的瀏覽器都會有這個問題]。作者做了一些測試，在以不同的瀏覽器與作業系統交互測試後，在Linux/Firefox上，當網站連線延遲超過20秒，或是收到unreachables訊息，將會立即切換到IPv4連線。在WindowsVista/IE上要等20秒，就算先收到unreachables訊息。如果大家有興趣，可以參考IETF80上[Savolainen2011]簡報內容。雖然這些測試僅僅是樣本測試，但卻指出這個問題是一個跨平台的問題，就算還程Win7/IE也是一樣。當世界IPv6日測試當天，使用者將會遭遇到相當嚴重的連線延遲問題。或許是因為這個原因，所以Google針對IPv6 AAAA紀錄僅允許特定IP來源的測試使用者存取，如果想以www.google.com 而不是 www.ipv6.google.com存取 Google的服務，必須要先證明自己所在的網路具有良好的IPv6連線。相關的資訊可以在[I-D.ietf-v6ops-v6-aaaa-whitelisting-implications]找到相關資訊，但是可預期在世界IPv6日測試當天，這個限制將會被解除- 代表這是正式測試服務IPv6產品化的一天。

一個相當有趣的建議[[I-D.ietf-v6ops-happy-eyeballs]與[I-D.chen-mif-happy-eyeballs-extension] 想處理這個問題，基本上使用者一開始會同時使用IPv4/IPv6進行連線，第一個連線成功的通訊協定將被採用，同時記錄下這個結果，下次連線就以這個紀錄進行連線。然而有人擔心這會增加額外的連線負擔(伺服器或網站)，並且只是把該解決的基礎連線問題隱藏起來(翻譯註:畢竟如果不想遇到問題，當天不要用IPv6就好了)。

2.4 路徑最大傳輸單元協調(PMTU Discovery)

在IPv6中，切割網路封包大小應該由傳送者決定，決定的機制採用PMTU Discovery [RFC1981]。在RFC4890中可以找到該如何於防火牆上設定相關的條件。如果沒有正確的設定，或許在連線上就會遭遇到問題-當管理者設定一律丟棄所有的ICMPv6訊息。IPv6最小的MTU是1280位元組，如果PMTUD沒有被執行，應該就要以minMTU進行傳送。TunnelBroker服務商中的SixXS與HE預設MTU為1280，這應該是避免多變的網路環境造成的不確定因素。但是在讀者管理的網路，應該要正確的參考RFC4890進行防火牆設定，並啟動PMTUD動態協商MTU，以最佳化網路傳輸的效率。

2.5 流氓路由器廣播(Rogue Router Advertisements)

在一個網路中，節點可能使用IPv6非狀態自動設定機制( IPv6 Stateless Address Autoconfiguration (SLAAC) [RFC4862])，然而此時可能有意外（或故意）的流氓路由器廣播訊息造成連線性問題，相關的描述可以在RFC6104中看到。通常這個問題發生在微軟視窗作業系統的網路分享(ICS)功能會自動的在無線網路介面上發送6to4路由器廣播資訊，節點將會建立兩個全域IPv6位址，並被導向連接到不能連線的路由器。其中一個出問題的例子，當收到一個流氓6to4路由器廣播資訊，使用者或許可以正常的透過6to4連接外部的IPv6網站，但是對於內部的IPv6網站反而無法連線。這是因為由外對內的IPv6連線可能會被防火牆所阻止，造成公司內的使用者連不上公司內的IPv6伺服器。在許多情況下，利用default address selection [RFC3484] (和 [I-D.ietf-6man-rfc3484-revise])可以解決這類的問題，或是可以設定為純IPv6連線的優先權高於6to4連線方式，然而不是所有的作業系統都根據RFC3484實做，特別是MacOS X，當遇到流氓路由器廣播干擾正常連線，連線延遲的問題就會出現。 在switch上對沒有路由器存在的網路孔封鎖ICMPv6 Type 134封包，將可以有效的降低流氓路由器廣播的問題。更完整的解決方案可以利用RA Guard [RFC6105] 和SEcure Neighbour Discovery (SEND) [RFC3971].，但這兩個協定並沒有廣泛的被實做。這裡有一個工具稱為"RAmond"，可以由http://ramond.sourceforge.net取得，這軟體是基於Rafixd並可以被設定來偵測對抗流氓路由器廣播(偵測到之後，馬上發送訊息讓這個路由廣播的有效時間變為0)。

2.6 隧道連線效能(Tunnel performance )

當網路透過手動連線的隧道傳輸(Tunnel)以取得IPv6連線能力，通常封包封裝是由路由器的CPU來執行。當超乎預期的高流量產生時，也許會造成問題。在IPv6日，使用者可能會使用需要大量頻寬的服務，例如youtube之類。建議預先測試這些軟體應用，並測試隧道連線解決方案是否能處理這些流量。

2.7 具有AAAA(IPv6)域名紀錄，但服務並未啟動(AAAA record advertised but service not enabled )

當啟動IPv6日的服務，要小心可能會有其他現存的服務跑在同一個系統上。如果一台伺服器跑了許多服務，所有的服務都應該在設定AAAA網址資訊之前確認支援IPv6連線。同時也要注意防火牆的設定，不要只是丟棄沒有服務的IPv6封包。舉例來說，當新增一個AAAA紀錄給網頁伺服器。而網頁伺服器上同時跑著FTP伺服器，但FTP伺服器預定只有IPv4 only。這個時候防火牆需要把port 21打開，或是代替伺服器回傳　TCP RST訊息，以確保終端使用者不會產生連線逾時的問題。

03 監控訊息(Instrumentation )

在這段中，我們將討論潛在世界IPv6日之前，有哪些潛在可能的設定監控可以被設定，同時這些工作可以持續在IPv6日後發揮作用。這些機制對於你的網路啟動網站的AAAA紀錄並希望取得了解系統運作的如何，以及使用者的體驗經驗。這些量測可由特定網路中的使用者體驗報告得到資訊，並確保組織內的網路管理者知道這是＂風險測試＂的一天，同時在這一天預期將會遭遇到一些問題。同時也應該讓每個網路中的一般的使用者知道這個測試。

3.1 IPv6流量(IPv6 traffic levels)

在給予適合的MIBs情況下，交換器與路由器應該能夠分別的偵測到雙協定的網路資料流，網路內應該確認相關工具可以正確的偵測IPv4/IPv6的流量。應用層的監控也是必須的，當應用服務取得AAAA與A紀錄，選擇了哪個協定進行連線。根據IPv6 Privacy Extensions [RFC4941] 需要注意隨著時間的推移，IPv6使用者的來源位址會發生變化。

3.2 網路流量(Network flow)紀錄(Network flow records )

有機會網路端應該嘗試佈署網路資料留紀錄，以便取得最大的機會在活動後分析網路行為或是回報發生的問題。目前Netflow第九版支援IPv6，支援Netflow IPv6的開放自由免費軟體也已經存在，例如nfsen http://nfsen.sourceforge.net。

3.3 終端使用者成功存取網頁服務的比例(Client Web Access Success Rate)

已經有些研究在分析網頁終端使用者透過IPv4或IPv6存取擁有IPv4/IPv6網址紀錄的雙協定網頁服務，在RIPE-61會議中的[Anderson10]做了一個好的示範，講者設定了一些網路服務(網頁伺服器-挪威的新聞網頁)進行測試。講者於網頁中增加了一個預設隱藏的IFRAME頁框，並在其中包含了一個兩個隨機檔名的1x1的影像，其中一個是IPv4 only另外一個是雙協定(對於每個使用者來說，連上來看到的IPv4/雙協定測試圖片是獨立組，每次都不相同)。藉由分析兩者被存取的差異，就可以分析出可能的IPv6連線失敗率。在2009第四季的研究中指出，大約有0.2-0.3%連線失敗，而最近由google發表的資料，這個數據已經下降到0.1%左右。

3.4 用來分析IPv6連線失敗的工具(Tools to measure IPv6 brokenness)

網路端同時應該要擁有量測IPv6連線中斷的機制，不可以完全依賴第三方的研究報告，目前有一些類似Tore Anderson 發表的公開解決方案。在APNIC實驗室的測試工具是利用google analytics與javascript來量測不同的使用者連線中斷[http://labs.apnic.net/]。Eric Vyncke發展的工具［Vyncke］以類似埋藏頁框的方式，提供網站主了解使用者連線過來的機制［http://test4.vyncke.org/testv6/］，APNIC也即將開放類似的監測工具與分析報告。

3.5 IPv4效能比較(IPv4 Performance Comparison)

當一個雙協定服務被佈署，應該對效能進行量測。主要可以量測傳輸率與延遲，但也可以監測服務正常在線時間與可用率。網路管理單位也許會選擇其他的分析比較方式，例如使用頻寬和流量測試工具。

3.6 使用者認證(User Tickets)

有可能會較平常出現多一些使用者認證，把這些問題紀錄下來事後分析。

It is possible a higher than usual user ticket rate for connectivity　issues may be experienced. being able to categorise these cases for subsequent analysis is desirable.

3.7安全監控(Security monitoring)

利用RAmod等工具監測並防制流氓路由器廣播，此外還有一個有效的工具- NDPmon可自 http://ndpmon.sourceforge.net取得，這可以用來監看網路中許多種的IPv6濫用錯誤。使用以上工具來了解網路中是否有一些錯誤的訊息對於世界IPv6日測試是有幫助的。

4.純IPv6測試

可以參考NAT64/ IVI等資訊

Some experience of NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] has been described in [I-D.tan-v6ops-nat64-experiences], though this appears to have used only NAT-PT so far. An implementation of NAT64 is available at http://ecdysis.viagenie.ca. Operational experience of IVI is also desirable. An implementation of IVI is available at http://www.ivi2.org/IVI.