[arin-ppml] Draft Policy 2011-5: Shared Transition Space for IPv4 Address Extension - IAB comment

[Owen DeLong]

On Jun 28, 2011, at 7:50 AM, Joel Jaeggli wrote:

> 
> On Jun 28, 2011, at 5:50 AM, Jimmy Hess wrote:
> 
>> On Tue, Jun 28, 2011 at 1:43 AM, Joel Jaeggli <joelja at bogus.com> wrote:
>>> On Jun 27, 2011, at 11:24 PM, Benson Schliesser wrote:
>>>> On Jun 28, 2011, at 0:25, David Kessens <david.kessens at nsn.com> wrote:
>>> It's new private scope v4 address space carved out of ipv4 unicast space. by definition it breaks assumptions that existing hosts and applications make about non-rfc-1918 space.
>>> 
>> [snip]
>> 
>> What assumptions would those be?
> 
> That a port mapped to a the outside of a cpe which does not have an rfc 1918 address will in fact be reachable (example by upnp or nat pmp)
> 
That assumption is going to break under LSN no matter what. Providers aren't going to use 1918 space for this, so, it's fail regardless. The question with this policy isn't this space or RFC-1918, it's whether we set aside one block of space for this purpose or force each provider to use their own block of GUA for this purpose.

IMNSHO, it's much more efficient for multiple providers to share a single block than it is for each provider to get their own block.

> That an ipv4 unicast address can be used as source or destination for an auto-tunneling mechanism. 
> 

That assumption will also fail under LSN for the reasons mentioned above.

> Aa specific example of the later with an rfc-1918 address assignment an existing implmentation of 6to4 will simply fail, which is the desired behavior, in the case of a private scope address carved out of a new range it will assign itself a /64 and proceed to fire ipv6 traffic into a blackhole. existing 6to4 cpe cause enough breakage as it is without compounding it.
> 

This is going to suck in the LSN world. There's no way around that. At least if we have a specific block set aside for it, it MIGHT get added to CPE firmware updates.
If we force ISPs to each use their own block, not only do we waste vastly more addresses, but, we also make it impossible for firmware updates to address these issues.

>> The word 'private scope'  doesn't appear anywhere in the proposal.
> 
> If you can't advertise it into the dfz what other scope does it have?
> 
There are multiple possible administrative boundaries between private and global. The fact that IETF doesn't recognize this reality does not prevent the reality from existing.

> you can see all this of course in the minutes when the proposal was discussed in v6ops.
> 
> http://www.ietf.org/proceedings/79/minutes/v6ops.txt
> 

Why was an IPv4 address space proposal given to v6ops?

Owen