[arin-ppml] ARIN-prop-127: Shared Transition Space for IPv4 Address Extension

[Owen DeLong]

On Jan 24, 2011, at 1:05 PM, George, Wes E [NTK] wrote:

> 
>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Monday, January 24, 2011 2:54 PM
>> To: George, Wes E [NTK]
>> Cc: Joel Jaeggli; arin-ppml at arin.net
>> Subject: Re: [arin-ppml] ARIN-prop-127: Shared Transition Space for
>> IPv4 Address Extension
>> 
>> That's a pretty good argument for having a defined block that people
>> can
>> adjust the 6to4 routers to know about. 
> Arguably, anycast 6to4 is
>> moderately
>> broken in a wide variety of circumstances anyway. I don't think it's
>> quite
>> as bad as Lorenzo would have us all believe, but, there are definite
>> problems.
>> 
> 
> [WES] sigh. We've gone round the circle again. If we could update those
> boxes to understand that this block isn't a valid external address to use
> for 6to4, we could also update them to do real IPv6, or to use class E
> space, or 6RD, or DSLite, etc, etc.

Sigh... Perhaps, but, I think the closure on your circle is broken...


The boxes that can do 6to4 can probably do real IPv6.

However, there are many many many more home gateways that don't
do either one and wouldn't be broken by the example you are citing.

Sure, the boxes that break for 6to4 could be an issue with this. However...
They aren't the majority of residential gateways.

Class E or real IPv6 requires updating all those OTHER gateways, not
just the ones that break in this scenario.

> The only thing that I can think of that makes this less broken would be if
> the CGN box is smart enough to serve as an ALG for 6to4 packets (not just a
> 6to4 relay) and locally terminate them so that it can send real IPv6 packets
> between itself and the destination, or otherwise rewrite the 6to4 packet
> headers and track the state so that 6to4 actually works properly with the
> external address. But I haven't heard of any vendors peddling that
> particular hack yet, nor are any of the usual suspects generating a draft in
> IETF for it (that I know of).
> 
There's no reason it couldn't be this way, but, even that isn't necessary.
All that is actually necessary is for the ISP to provide routing to a 6to4
gateway within the NAT444 intermediary zone such that 6to4 anycast
packets reach that 6to4 gateway and have that gateway provide
the ALG functionality needed to avoid the intermediary address
being embedded in the IPV6_SRC field.

> The idea here is that regardless of what anyone thinks about it, to quote
> Brian Carpenter, "the toothpaste is out of the tube now." That is, we're
> stuck with 6to4, and we're better off trying to make it work better for
> those who are using it than to continue treating it as a completely
> second-class citizen, because ultimately it is still a means to increase
> IPv6 deployment in places where it otherwise wouldn't exist. Most of the

Maybe yes, maybe no. In reality, if NAT444 breaks 6to4 further and people
are forced to chose one over the other, my money would not be on 6to4
no matter how much I would prefer it.

> brokenness is because there aren't enough properly run 6to4 relays close
> enough to the sources and sinks of traffic. Only a small percentage is due
> to broken implementations that try to do 6to4 with 1918 addresses or the
> like. Last I heard, Brian was working on a draft to make some
> recommendations about how to make 6to4 suck less, but if Comcast's
> experiences with 6to4 are any indication, simply saying "eh, 6to4 is broken
> anyway" is a cop-out.
> 

As you point out, the 6to4 issues are fairly easy to overcome. They are
a small percentage of the affected userbase in any case. As such,
you're still making pretty good arguments in favor of the proposal
while continuing to oppose it.

Owen