How about ipv6?

[ccaapton]

Recently, the wall deployed similar on-path tcp disruption tech on ipv6 connection. More specifically, 6in4/6to4 ssl/tls connections to google/youtube/facebook now get reset, but unlike ipv4 routing blackhole, these ipv6 addresses are ping-able. Will INTANG able to be extended to cover this case?

[gkso]

It's interesting that google/youtube/facebook are not ip blocked on ipv6. I think it's not too hard to support ipv6. Maybe just replace the ipv4 socket with ipv6 socket. The upper layers are the same. We'll take a look into that later. Thanks.

[LGA1150]

Both 6in4/6to4 use IPv4 Protocol 41, which encapsulates IPv6 packets right after IPv4 header. Thus the encapsulation overhead is simply the size of the IPv4 header of 20 bytes.

To track IPv6-in-IPv4 connections, simply remove IPV4 and IPv6 headers (60 bytes in total), then the transport layer data is completely exposed.

[ccaapton]

@LGA1150 Linux will rip off ipv4 wrapper header before passing the packet to the tunnel interface, so INTANG could treat 6in4 as the same native ipv6.

@gkso Google/YouTube in 6in4 is unlikely to be ip-blocked even native ipv6 got so, as the routing from user to the tunnel broker is ipv4. ISP routers can not apply both ipv4 and v6 rules on the same packet.

[gkso]

@ccaapton I see. so you are saying the GFW can correctly parsing/processing 6in4 packets. Since the underlying protocol is still IPv4, I think things would be much easier. just adding some packet parsing logic should work. However, I'm currently busy with something else, have to find someone else to fix this. :(

[LGA1150]

I think with IPv6 6in4 Tunnel, one can simply set IPv6 insertion packets' hop limit to small number such as 2 or 3.
When IPv6 packet is encapsulated into IPv4 packet and sent through the IPv4 Internet, routers will keep the inner IPv6 packet's hop limit value untouched. Once it reaches the Tunnel Server, IPv4 encap is removed so it's likely to be dropped because of hop limit exceeded. Thus the 6in4 packet is able to reach GFW, but will be eventually dropped before it reaches server.

[gkso]

@LGA1150 Actually I think that's a clever idea. If the GFW can parse 6in4 packets, then it may terminate its TCB on seeing a 6in4 RST packet. In this case, we don't need to calculate TTL or use other discrepancies. I'll try to implement this and see it works.

[LGA1150]

Any progress on this?

[gkso]

Yes, I've tried. I was able to set up a 6in4 tunnel on my router but had some problem setting up one on my machine behind NAT. Because most of the users should be behind NAT, so I suppose this is the common setting. And I couldn't remember the exact reason why it failed. But I will try again when I have time, currently too busy :(