OVH gives you a /128 block by default. But in fact you can use the whole /64. You can simply add a /64 address to eth0.
But if you activate IPv6 in docker and try to allocate an address in bridge network, you will find the address is not ping-able. The problem here is we should send a NDP notification to OVH router.
配置OVH的獨服在docker中使用IPv6
OVH的機器默認給的是/128，但是其實整個/64都是可以用的，如果添加到網卡上是可以雙向ping通的。
但是如果docker的bridge網絡分配了一個IPv6，卻無法ping通。喝了一瓶果汁之後我發現是因為沒有向（OVH的）路由器發鄰居發現協議包（NDP）。
GFW6使用心得 一
最近一直在使用gfw6，感覺不錯。
試着做如下黑箱分析：
- 阻斷ipv6反向代理地址的工作方式：阻斷地址通過計算獲得：RFC 6147中指出，dns64反向代理服務器返回的ip由服務器決定，“一般情況下，返回一個帶ipv6固定前綴的地址”；現在看來大部分dns64服務器都是按照“一般情況”，GFW6隻要將所有ipv6請求目標地址和源地址某兩個塊（一般為最後兩個塊）倒推成ipv4地址，即可選擇性地發送RST包。如此土豪的方式，果然是一坨曙光計算機撐腰的大項目啊（笑）。
- 阻斷固定ipv6地址的工作方式：和以前ipv4的時候是一樣的，RST攻擊。
- 開始污染DNS64解析感覺這個沒啥作用
- 有兩點值得注意：對反向代理，似乎只對請求方發送RST包；https連接沒有被RST。
GFW6 beta 今天再次公測
靜等斯巴達
ipv6出國通路今天已選擇性被封，普通方式翻牆已基本被堵死。27日傍晚已恢復正常
不得不說，國內的大部分互聯網大公司都收到了來自SERN的指示。
比如昨天在群里發了新浪博客的鏡像文章地址，後來就被“管理員刪除”了。
不可能有人會專門監視哪個群，只是騰訊過濾出了其中的關鍵字還有網址，然後重點審核罷了。
一絲涼意湧上心頭
喂不要告訴我ipv6就是因為這被封的？！！
我果然是廚二病啊哈哈哈哈哈！！！
最後貼張圖，紀念斯巴達倒數十一天。
斯巴達大事記錄：
- 2012-10-27 11:50:48 ～2012-10-27 15:54:26 CERNET IPV6出國線路被拔線（從監控日誌來看是這樣，實際上存在地區差異）
- 2012-11-7 GFW6 試運行，對除google基礎服務（除去youtube和webcache）外的出境地址全部進行了DNS污染；對部分請求的RST也開始運作
- 2012-11-8-？GFW6對ipv6出國報文間歇性導向黑洞路由（？）
