In message <22F6318E46E26B498ABC828879B08D4F16FF26@xxxxxxxxxxxxxxxxxxxxxxxxxxxx eploy.ntdev.microsoft.com>, Christian Huitema writes: > >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 tes= > t through the tentative 6to4 relay, towards some well-known IPv6 host. Or a= > n 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 f= > irewalls and other obstructions. If the path is not clear, pick another 6to= > 4 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. But happy-eyeballs does mostly solve that problem. If the path is congested and dropping packets then the IPv6 connect will likely not succeed before the IPv4 connect succeeds. happy-eyeballs also deals with relay routers that are topologically bad for the destination machines which are dual stack. > 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" p= > roblem is easily solved by IPv6 ISP deploying their own 6to4 routers, and t= > hus avoiding dependencies on a "generic" path to 2002::/16. > > -- Christian Huitema -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: marka@xxxxxxx _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf