【51CTO 11月9日外電頭條】不要再抱怨了，它真的很了不起。我之前探討過了為什么大家應該以積極的態度，盡早為IPv6做準備；而本篇文章則是我在實際部署過程中所收集到的個人經驗。

更重要的是，我所使用的不是所謂不廢不立、一步到位的方法。我壓根沒打算馬上讓與IPv6相關的一切細節完美進行，只要各項輔助措施足以保障自己安全地探索這片美麗的全新天地即可，至于最終結果不妨以后再說。

本地主機——我期待著你的謝幕

首先，讓我們處理這樣一個問題。將你的臉埋在手掌中：我在前面的文章中曾經提到，在開發過程中，我一般更樂于在進行測試時使用本地主機，而非在自己的URL中使用127.0.0.1，因為后者會帶來一大堆亂七八糟的Java堆棧地址，導致工作無法進行--本地主機擴展至IPv6的地址為::1。

因此，在拋開這一問題并處理類似的其它情況時，我使用了相近的Java InetAddress，但實際上是用其替代IPv4；并伴之少量單元測試以確保上述錯誤不會發生，結果基本令人滿意。

我花了大約一到兩個小時嘗試解決主要錯誤，但當天余下的時間基本上都被用在分類并等待諸如通過IP地址進行用戶地理位置定位這樣成效不明顯的處理結果上；而且甚至一些簡單的前端反拒絕服務攻擊代碼都被認定為潛在的麻煩制造者，而依據正是其IP地址前綴。

在IPv4協議中，網絡前綴的長度是可變的，但簡單地對其最后（也是作用最不明顯）的八到十位加以屏蔽，確實能夠有效阻止個人（特指那些圖謀不軌的）用戶甚至是公司/團體通過精心設計的代理手段進行跨躍式外部地址訪問。而且這種方式能夠最大程度地減少其它負面影響。

而在IPv6協議中，網絡部分是固定由前64位（盡管我們很可能仍然出于某種目的而希望從末端去除其中的部分內容）表述的，這使得事情更加趨于簡化，但我還是必須為此將查找鍵由32整數字節增加到64字節。在處理地理定位問題時也存在類似的情況，不過我在IPv6中對其暫時加以禁用、并在IPv4中重新將其激活的做法相信會讓大家更加容易接受。

需要額外說明的是，上述實例中的實際代碼片段無法在IPv6中順利工作（盡管整個結構比較清晰明確），盡管此方法中的簽名誤導性地允許接受任何IP地址。

IPv6在主機上的優良表現

接下來，我要讓IPv6工作在自己有點過時的Solaris 10與Bogons協同定位設備上。經過討論，我們決定將主機移動到新的地址段中，不過后來我犯了點二，一不留神又使用了舊地址，這也引發了些許麻煩。看來再先進的科技也挽救不了愚蠢的頭腦啊。

回到正題，我們所要做的是為自己想要的靜態地址創建一個文件：

/etc/hostname6.bge0 

(bge0 是網絡接口設備的名稱) 然后為其加入‘神奇的咒語’：

addif WWWW:XXXX:YYYY:ZZZZ::2/64 up  
where WWWW:XXXX:YYYY:ZZZZ is my 64-bit network prefix.  

接下來重新啟動。

現在ping進與ping出（例如ipv6.google.com）都工作正常：來吧，整個世界都擺在我們面前了！

即便是從靜態服務器地址來看，這也要大大好于IPv4所做的工作；尤其是我們無需設定什么默認路由，因為IPv6完全可以自動發現。

在這一階段，我還為自己的Tomcat服務器（incof/server.xml）添加了一個新的連接定義，以便像處理現有IPv4那樣綁定并接受IPv6；另外在新IPv6地址遠程登錄端口80的幫助下，新代碼的提出及快速測試也變得更加便捷。

<!-- Existing IPv4 connector. --> <Connector executor="tomcatThreadPool" port="80" address="8.8.8.8" protocol="HTTP/1.1" enableLookups="false" /> 
<!-- New IPv6 connector. --> <Connector executor="tomcatThreadPool" port="80" address="WWWW:XXXX:YYYY:ZZZZ::2" protocol="HTTP/1.1" enableLookups="false" /> 

在添加上述內容時，我確實發現了一些其它潛在的錯誤，結果當然就是采取快速斷路處理。而事實上，我在幾輪快速更新的過程中發現了更多錯誤，用戶們可能會觀察到一些無傷大雅的小故障。但至少我現在手頭已經有了成形的IPv4及IPv6網站且都處于運行狀態，而且IPv6就只有我一個人了解其存在，這已經非常令人滿意了。

IPv6隧道

現在我打算在自己的開發機之外獲得同等的IPv6使用空間，以進行更多測試。感謝Jobsian觸摸版，事實上我的臺式機已經具備了靜態公開路由的IPv4地址，這使得由"6到4"的轉換可以工作于Mac OS X 10.7的網絡設定（與VPN之類作用相同）當中（當然，在第二次嘗試時出現了奇怪的連接線路斷開錯誤，當時我正嘗試在3G無線連接中使用轉譯后的IP地址）。

但在此之后，我可以順利地從自己的計算機處ping通網上的IPv6地址，并訪問像谷歌ipv6.google.com這樣的IPv6型頁面。此外，最重要的是，利用文字形式的IPv6地址對自己的協同IPv6站點進行測試。

http://[WWWW:XXXX:YYYY:ZZZZ::2]/

站點中還包含了一個用于顯示瀏覽器IP地址的頁面，而且它順利顯示出了我的Mac機的IPv6地址，這樣一來基本上算是大功告成了。

AAAA名稱到底是什么？

對128位名稱要做的最后一項工作是為那些啟用了IPv6的服務器設置DNS記錄。我不打算在一開始就糾結于反向查找記錄，這些事情最后再處理吧。

因此我所要做的是從我的example.com名稱向IPv6原始地址做正向解析。對于IPv4地址而言，它在DNS術語中被記錄為"A"。而對于IPv6地址來說，則用四個"A"來表示，即"AAAA"記錄。大家對這一點肯定不會陌生。

那么新的記錄形式將如下所示：

ipv6.example.com. IN AAAA WWWW:XXXX:YYYY:ZZZZ::2 

我的一切DNS信息都是由腳本創建得出的，該腳本也負責根據主機文件建立BIND9配置文件；由于我尚未對其加以調整，所以腳本還無法識別IPv6地址，我的做法是暫時將IPv6地址偽裝成電子郵件記錄并加以忽略。就先湊合著用吧，以后再進行修繕。

總而言之，由于AAAA記錄的公布及傳播，如今我已經可以將…

http://ipv6.example.com/

…這一地址輸入我MacBook中瀏覽器的地址欄中，并且正確進行訪問。

在反復測試直到獲得滿意結果之后，我還將AAAA記錄添加到了已經具備A記錄的example.com中，這樣任何啟用了IPv6的使用者--只要沒有對其進行配置變更，并且使用同一款搜索引擎或者URL--都會直接以IPv6的方式訪問該站點。

事實上，經過了一天左右的時間，DNS記錄已經完成了其傳播過程；我的example.com站點已經有大約0.2%的訪問量來自IPv6線路。我從日志文件中觀察到整個瀏覽模式都相當正常。哈哈，站點的升級簡直稱得上天衣無縫！

技術偵察工作總結

正如前方所說，要讓整體工作保障有力，還有很多問題要處理，例如反射查找（從IPv6地址到名稱）PTR記錄、地理位置定位之類，甚至還需要考慮DNS中的IPv6粘貼記錄以確保只支持IPv6的客戶端能夠通過同樣的URL訪問到新服務器。

除此之外，還有不少其它細微復雜的任務要應對，例如如何處理那些不分配IPv4地址或者只支持IPv4 URL的客戶端對IPv6站點的訪問，他們沒有使用雙棧協議；盡管這類情況如今已經非常罕見，但卻的確存在。

但是，歸根結底，我們要承認整個升級過程相當輕松，并且很容易確保更多的訪問流量--例如來自移動設備的訪問--通過IPv6承載。

希望大家也能親自動手，嘗試這種隱性的IPv6部署方式。試點項目，早做總比晚做好：時刻準備著，而不要臨時抱佛腳。

原文鏈接：http://www.theregister.co.uk/2011/11/07/ipv6_transport_of_delight_part_2/

 【51CTO.com譯文，轉載請注明原文作譯者和出處。】