> From: Christian Huitema <huitema@xxxxxxxxxxxxx>
> From Noel analysis
A belated (sorry) note to clarify the record: all I did was repeat stuff
from other people's studies (principally the one by Geoff Huston); they
should get all the credit.
And while I'm here anyway...
> it seems that a lot of the issues could be mitigated by simple
> connectivity test.
Well, IPv6 Neighbour Discovery is just the thing. I gather it's turned off
on 6to4 links, which in retrospect was probably a mistake. I would
recommend that it be turned on, but apparently the WG decided against
making that recommendation in the '6to4 fixes' document?
Other work with similar 'automatic' (i.e. not manually configured) overlay
networks has shown that conditions in the Internet these days are such
that one simply cannot assume that just because one's next-hop packet
switch appears to have a routing table entry for some destination, that
that means that any traffic sent to it will get there. You simply _have_
to do liveness testing (and not just on the other node, but also on the
paths in both directions).
On overlay networks with large fanouts, this can present a rather tricky
problem - O(N) overhead - but there are a variety of tricks (e.g.
piggybacking liveness mechanisms on user traffic) one can use. That
shouldn't be a problem in this case, which is why I think just turning on
ND on 6to4 is the way to go.
> It also does not solve the problem of routers advertising an IPv6
> route to 2002::/16 and then failing to deliver the IPv4 packets.
Well, RFC-3068 does say:
"Any 6to4 relay router corresponding to this specification must
include a monitoring function, to check that the 6to4 relay function
is operational. The router must stop injecting the route leading to
the 6to4 anycast prefix immediately if it detects that the relay
function is not operational."
So boxes that do what you mention (advertising 2002::/16 and then failing
to deliver the packets to the matching IPv4 address) are _already_
violating the spec...
NOel
_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf