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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf