最近一直在使用gfw6，感覺不錯。

試著做如下黑箱分析：

  1. 阻斷ipv6反向代理地址的工作方式：阻斷地址通過計算獲得：RFC 6147中指出，dns64反向代理伺服器返回的ip由伺服器決定，「一般情況下，返回一個帶ipv6固定前綴的地址」；現在看來大部分dns64伺服器都是按照「一般情況」，GFW6隻要將所有ipv6請求目標地址和源地址某兩個塊（一般為最後兩個塊）倒推成ipv4地址，即可選擇性地發送RST包。如此土豪的方式，果然是一坨曙光計算機撐腰的大項目啊（笑）。
  2. 阻斷固定ipv6地址的工作方式：和以前ipv4的時候是一樣的，RST攻擊。
  3. 開始污染DNS64解析感覺這個沒啥作用
  4. 有兩點值得注意：對反向代理，似乎只對請求方發送RST包；https連接沒有被RST。

實驗（與上文對應）：

  1. 選定任意一個DNS64地址，用nslookup得到返回值，增加hosts條目；本例測試X望の聲（牆外）和度娘（牆內）。wireshark抓包結果發現，X望の聲的第一個返回包被reset，導致連接失敗；度娘連接正常。
  2. 略
  3. 略
  4. 略

解決方案：

  1. 如果能找到一個「非典型」DNS64伺服器，那GFW6的TCP阻斷就痿了。假設某個DNS64伺服器的演算法為，最後兩個地址塊為 FFFF:FFFF-ipv4轉換地址，那麼GFW6無法確定阻斷地址，要阻斷，只能把block list中的地址一一詢問該DNS64伺服器；如果演算法變一下，比如之前的計算結果再和一個常數異或一下，或者再每兩天（正好和本地DNS cache的TTL重合）換一個常數，那麼GFW6將會非常苦逼。RFC6147似乎沒有明確指出「optional parameter」的含義，從5.2節來看，似乎奇葩的演算法也是可以的。
  2. 西廂代理v6？括弧笑
  3. 這個好辦，反正被牆的網站只是少數，nslookup一個沒被牆的DNS64地址，按演算法寫到hosts里就好了嘛
  4. 可能是一個突破口，關注中。DNS64時X望の聲有時竟然是可以上去的。

有用的資料：