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

[Owen DeLong]

On Jan 24, 2011, at 10:43 AM, George, Wes E [NTK] wrote:

>> -----Original Message-----
>> From: Owen DeLong [mailto:owen at delong.com]
>> Sent: Monday, January 24, 2011 12:11 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
>> 
>>> Read
>>> 
> https://datatracker.ietf.org/doc/draft-ietf-intarea-shared-addressing-issues
>>> / for more discussion on the matter.
>> 
>> In which case, this address space only presents an issue for those
>> using
>> it in a manner other than intended.
>> 
>> Owen
>> 
> [WES] That's an oversimplification. This block will break 6to4 even if it's
> used for its intended purpose as long as the block is not part of RFC1918
> space, it just might break at a slightly different place in the path. A CPE
> router doing 6to4 for its network using the non-1918 IP it gets from the
> broadband provider will break just as much as an end host who gets a
> public-looking but non-unique/routable address. But whether ARIN/IANA
> reserves a block, the ISPs cooperate and use a block amongst themselves, or
> they use some of the space that was previously allocated to them by an RIR
> on an individual basis, the same problem exists. So it's not a surprise, but
> that's part of why I'm so adamant about using 1918 space for this if at all
> possible.
> 
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.

> Not to speak for Joel, but I think that the point he's making is that if
> this block isn't codified as an update/addition to RFC1918 space, it'll be
> treated incorrectly by applications which care about global uniqueness in
> addressing, regardless of where they live. Even if it is codified in that
> manner, it'll take the applications (host stack and otherwise) a while to
> catch up. 
> 
In which case, we're better off with this than with random provider-specific
assignments which is the most likely alternative scenario.

Owen