RE: one data point regarding native IPv6 support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



>From Noel analysis, it seems that a lot of the issues could be mitigated by a simple connectivity test. Have the 6to4 router perform a simple ping test through the tentative 6to4 relay, towards some well-known IPv6 host. Or an HTTP test, if we fear that ICMPv6 might be somehow tampered with.  If the test succeed, then it shows that the path to that 6to4 relay is clear of firewalls and other obstructions. If the path is not clear, pick another 6to4 relay, or do not enable 6to4.

Of course, this does not solve the problem of intermittent failures on the IPv4 path to the relay, e.g. due to congestion. 

It also does not solve the problem of routers advertising an IPv6 route to 2002::/16 and then failing to deliver the IPv4 packets. But this "return" problem is easily solved by IPv6 ISP deploying their own 6to4 routers, and thus avoiding dependencies on a "generic" path to 2002::/16.

-- Christian Huitema



_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]