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

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

本地主機(jī)——我期待著你的謝幕

首先，讓我們處理這樣一個(gè)問題。將你的臉埋在手掌中：我在前面的文章中曾經(jīng)提到，在開發(fā)過程中，我一般更樂于在進(jìn)行測(cè)試時(shí)使用本地主機(jī)，而非在自己的URL中使用127.0.0.1，因?yàn)楹笳邥?huì)帶來一大堆亂七八糟的Java堆棧地址，導(dǎo)致工作無法進(jìn)行--本地主機(jī)擴(kuò)展至IPv6的地址為::1。

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

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

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

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

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

IPv6在主機(jī)上的優(yōu)良表現(xiàn)

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

回到正題，我們所要做的是為自己想要的靜態(tài)地址創(chuàng)建一個(gè)文件：

/etc/hostname6.bge0 

(bge0 是網(wǎng)絡(luò)接口設(shè)備的名稱) 然后為其加入‘神奇的咒語’：

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

接下來重新啟動(dòng)。

現(xiàn)在ping進(jìn)與ping出（例如ipv6.google.com）都工作正常：來吧，整個(gè)世界都擺在我們面前了！

即便是從靜態(tài)服務(wù)器地址來看，這也要大大好于IPv4所做的工作；尤其是我們無需設(shè)定什么默認(rèn)路由，因?yàn)镮Pv6完全可以自動(dòng)發(fā)現(xiàn)。

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

<!-- 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" /> 

在添加上述內(nèi)容時(shí)，我確實(shí)發(fā)現(xiàn)了一些其它潛在的錯(cuò)誤，結(jié)果當(dāng)然就是采取快速斷路處理。而事實(shí)上，我在幾輪快速更新的過程中發(fā)現(xiàn)了更多錯(cuò)誤，用戶們可能會(huì)觀察到一些無傷大雅的小故障。但至少我現(xiàn)在手頭已經(jīng)有了成形的IPv4及IPv6網(wǎng)站且都處于運(yùn)行狀態(tài)，而且IPv6就只有我一個(gè)人了解其存在，這已經(jīng)非常令人滿意了。

IPv6隧道

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

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

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

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

AAAA名稱到底是什么？

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

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

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

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

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

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

http://ipv6.example.com/

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

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

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

技術(shù)偵察工作總結(jié)

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

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

但是，歸根結(jié)底，我們要承認(rèn)整個(gè)升級(jí)過程相當(dāng)輕松，并且很容易確保更多的訪問流量--例如來自移動(dòng)設(shè)備的訪問--通過IPv6承載。

希望大家也能親自動(dòng)手，嘗試這種隱性的IPv6部署方式。試點(diǎn)項(xiàng)目，早做總比晚做好：時(shí)刻準(zhǔn)備著，而不要臨時(shí)抱佛腳。

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

 【51CTO.com譯文，轉(zhuǎn)載請(qǐng)注明原文作譯者和出處?！?/p>