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

Owen DeLong owen at delong.com
Wed Jun 29 19:00:52 EDT 2011

On Jun 29, 2011, at 3:06 PM, Alain Durand wrote:

> On Jun 29, 2011, at 4:52 PM, Owen DeLong wrote:
>>> This is why going with RFC1918 is the safest choice. Dealing with inside/outside address range conflict is,  IMHO, much easier than dealing with the brokeness induced here.
>> Your opinion is not shared by the majority of network operators. I would regard the choice as more of a business decision than one that ARIN or the IETF should inflict upon them.
> My concern is that the technical breakage caused by extending RFC1918 have been seriously underestimated by the proponents of 2011-5.
> An ISP making the business decision to use an overlapping part of its address space is one thing, ARIN augmenting RFC1918 in another.
>    - Alain.

It wouldn't be an overlapping part of their address space, but, it would cause all the same issues for all the same customers, so the only differences I see between the ISP doing so and ARIN doing so are:

	1.	Firmware/software updates cannot be created to address the breakage since it will be a random assortment
		of GUA instead of a consistent well known /10 that can be added to the exception list.

	2.	It will consume more GUA for each ISP to have their own pool.

	3.	As a result of the increased GUA consumption, more customers will be afflicted with LSN (NAT444).

Seems to me that each of those makes a consistent well known /10 the preferable alternative for reducing the likely amount of breakage, mitigating that breakage more easily, and reducing the unnecessary GUA consumption. If ARIN/IETF make the pool available, then, providers that will do this anyway can at least use a consistent pool. Those who believe that 1918 conflicts will generate less support costs than GUA-based breakage can still use 1918. If we don't allocate the space, then, the providers that do not want to use 1918 will likely use disparate GUA spaces leading to all of the problems described above.


More information about the ARIN-PPML mailing list