In message
<22F6318E46E26B498ABC828879B08D4F16FF26(_at_)TK5EX14MBXW653(_dot_)wingroup(_dot_)wind
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(_at_)isc(_dot_)org
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf