不要再抱怨了，它真的很了不起。我之前探讨过了为什么大家应该以积极的态度，尽早为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的帮助下，新代码的提出及快速测试也变得更加便捷。
在添加上述内容时，我确实发现了一些其它潜在的错误，结果当然就是采取快速断路处理。而事实上，我在几轮快速更新的过程中发现了更多错误，用户们可能会观察到一些无伤大雅的小故障。但至少我现在手头已经有了成形的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部署方式。试点项目，早做总比晚做好：时刻准备着，而不要临时抱佛脚。
