On Jun 14, 2011, at 2:52 PM, Joel Jaeggli wrote:
Keith is correct, and the further issue is that the *-only-* reason the
'poorly managed' relays are in the path is that the content providers are
refusing to deploy the matching 6to4 router that would take a direct
connection from the customer.
6to4 direct between the content and consumer is still an 'unmanaged' tunnel
which takes exactly the same path as IPv4 would, so the 'badness' is not
due
to managed vs. not.
And the breakage still exists even if you do that.
do "what"?
deploy your own relay, as observed by geoff and others that does not
rehabilitate (by which I mean make it usable for those customers) 6to4.
Ah yes. This reduces but does not eliminate the potential for breakage.
Native IPv4 will still work better, and should generally be preferred over
6to4, for the cases where both endpoints have v4 addresses and the application
can tolerate any NATs in the signal path.
As I understand it, the breakage mostly happens when the traffic doesn't
take exactly the same path as IPv4 would, but rather when the traffic moves
between the IPv4 world and the IPv6 world (or vice versa) via a relay router
that's advertising a route to a network that it can't actually get traffic
to.
Though of course there are other sources of breakage: ISPs that filter
protocol 41 (thus violating the "best effort" model); and NATs, including
LSNs. Neither of these is 6to4's fault.
it results in a failure from the vantage point of the customer. you're
splitting hairs pretty fine if you not willing to ascribe that to 6to4.
Admittedly, to the customer's point-of-view the problems are associated with
6to4, or (more likely) IPv6 in general. But the problems can't be fixed by
looking only at the vantage point of the customer.
When network operators are the major cause of the problems, and they want to
blame 6to4 for it... well, there's a word for that. Bottom line, that kind of
attitude is not going to get the problem fixed either for 6to4 specifically or
IPv6 in general.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf