I did not say deploy you own relay ... that is braindead and doesn't even
come close to understanding how the technology works. A 6to4 router at the
content end is not a relay because it is strictly dealing with 2002:: on
both sides. The only time a relay is required is to transit between the
2002:: prefix and the RIR prefixes. There is no reason to go there, but
people insist because their IPv4-think myopia refuses to allow them to
realize that their content server can simultaneously have an RIR prefix and
a 2002:: prefix.
Tony
From: Joel Jaeggli [mailto:joelja(_at_)bogus(_dot_)com]
Sent: Tuesday, June 14, 2011 11:53 AM
To: Keith Moore
Cc: Tony Hain; 'Ole Troan'; 'Michel Py'; 'IETF-Discussion'
Subject: Re: one data point regarding native IPv6 support
On Jun 14, 2011, at 11:46 AM, Keith Moore wrote:
On Jun 14, 2011, at 2:36 PM, Joel Jaeggli wrote:
On Jun 14, 2011, at 11:16 AM, Tony Hain 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.
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.
The IPv4 network is supposed to make a best effort to convey traffic from
source to destination, regardless of protocol type, without altering it
other than the TTL field. If ISPs break 6to4 traffic by filtering protocol
41, that's clearly their fault. Likewise, if ISPs break 6to4 traffic by
imposing NAT on their customers, that's also quite clearly their fault.
It's not like we haven't known FOR TWENTY YEARS NOW (remember Kobe?) that
the Internet was running out of addresses and had a standardized replacement
in place FOR OVER FIFTEEN YEARS.
If an ISP that has aggressively deployed IPv6 wants to whine about 6to4
support issues, I guess they have a legitimate gripe.
Keith
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf