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

Matthew Kaufman matthew at matthew.at
Thu Jan 20 11:59:50 EST 2011


On 1/20/2011 8:36 AM, Jack Bates wrote:
> Oppose prop 127

Also Oppose.

>
> On 1/20/2011 10:26 AM, ARIN wrote:
>> Updates 4.10 of the NRPM:
>> A second contiguous /10 IPv4 block will be reserved to facilitate IPv4
>> address extension. This block will not be allocated or assigned to any
>> single organization, but is to be shared by Service Providers for
>> internal use for IPv4 address extension deployments until connected
>> networks fully support IPv6. Examples of such needs include: IPv4
>> addresses between home gateways and NAT444 translators.
>>
>
> For the use proposed, /10 is not enough space. It is also a use which 
> is not region specific, and wasteful for each region to specify their 
> own space for such purposes.

/10 may or may not be enough. Agree that use is not region-specific.
>
>> Until such customers replace their Home Gateways and all IPv4-only
>> devices with IPv6-capable devices, Service Providers will be required to
>> continue to offer IPv4 services through the use of an IPv4 address
>> sharing technology such as NAT444. A recent study showed that there is
>> no part of RFC1918 space which would not overlap with some IPv4
>> gateways, and therefore to prevent address conflicts, new address space
>> is needed.
>
> Overlap with home gateway addressing is not a concern of ARIN. RFC1918 
> could be utilized and home gateways reconfigured if necessary. It is 
> wasteful to allow a small percentage of possible conflicts to warrant 
> additional space. The larger conflict of RFC1918 space is cpe 
> management addressing which used RFC1918, in which case, a very large 
> cable company just ran out and had to request addressing to support 
> this case. A /10 wouldn't come close to supporting that many subscribers.

Either RFC1918 space can be used or IETF can direct IANA to allocate 
additional space for private addressing via the RFC process, extending 
the existing RFC1918 space. This is a region-independent solution.

Note that this is also a case where some providers might be able, due to 
the characteristics of their devices, to use class E space, some of 
which could also be set aside for this purpose.

Matthew Kaufman




More information about the ARIN-PPML mailing list