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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf