最近一直在使用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望の声有时竟然是可以上去的。

有用的资料：