RE: one data point regarding native IPv6 support

["Tony Hain" <alh-ietf@xxxxxxxx>]

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