[arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

George, Wes E IV [NTK] Wesley.E.George at sprint.com
Tue Apr 19 16:14:10 EDT 2011

This policy is not ready for adoption in its current form. 
I appear to be in the minority in my opposition to this policy, so my comments below are intended to improve the policy under the
assumption that it will most likely be adopted in some form. However, I strongly believe that it needs to be put back on the docket
for discussion in the next meeting, since my concerns would dictate some substantive and potentially controversial changes. 

First, the current text does not reflect the valid concerns raised in discussion in PR about a lack of enforcement.
Specifically, it does not include any guidance to ARIN staff eliminating the intended uses for this space (NAT inside pools aka IPv4
address extension) as valid justifications for standard address space allocations, meaning that there is no guarantee that SPs will
actually use it for its intended purpose until they are no longer able to obtain address space via normal means.
I am not advocating that we *require* SPs to use NATs + shared space and prevent them from justifying space in a Business as Usual
manner for their customer growth. However, I *am* advocating that staff explicitly asks if the space being requested is for use in
numbering inside NAT pools, or if part of the 80% utilization is allocated to the same, and if so, deny the request and refer them
to the shared space set aside for that use. If we're going to carve out shared space for a specific purpose, then it needs to not be
optional for that purpose.
Supporters have been quick to say that this space is being reserved for a narrow application and not a general application like an
extension of RFC1918, and so if this is the case, then we should be providing clear guidance to staff on this matter. 

Also, the text "until connected networks fully support IPv6" is unclear. Does this mean that this block is only reserved until such
time that the network using the space has completed its IPv6 deployment? How would that be determined? I think that's probably not
what the author intended, since even once IPv6 is available in a given SP network, that won't eliminate the need to continue
supporting IPv4-only devices and networks. If the intent is to have this be reserved indefinitely, then just say that, rather than
tying it to IPv6 deployment. Or alternatively, put a time-based sunset policy in place.

Lastly, while it didn't come up in PR, we had also discussed on PPML the idea of a different sort of sunset clause, where unless X
SPs came forward and notified ARIN that they were using the space, it would be returned to the free pool instead of being stranded
and unused. Because there are many of us that remain unconvinced that this will actually reduce the burn rate of IPv4 space, this
would be a show of good faith on the part of the beneficiaries of this policy that wouldn't fundamentally alter its intent. It
does't have to be public, but at least it would provide a way to ensure that we're not wasting space on this application. 

Wes George 

-----Original Message-----
From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On Behalf Of ARIN
Sent: Monday, April 18, 2011 3:07 PM
To: arin-ppml at arin.net
Subject: [arin-ppml] ARIN-2011-5: Shared Transition Space for IPv4 Address Extension - Last Call

The ARIN Advisory Council (AC) met on 13 April 2011 and decided to send the following draft policy to last call:

   ARIN-2011-5: Shared Transition Space for IPv4 Address Extension

Feedback is encouraged during the last call period. All comments should be provided to the Public Policy Mailing List. Last call for
2011-5 will expire on 2 May 2011. After last call the AC will conduct their last call review.

The draft policy text is below and available at:

The ARIN Policy Development Process is available at:


Communications and Member Services
American Registry for Internet Numbers (ARIN)

## * ##

Draft Policy ARIN-2011-5
Shared Transition Space for IPv4 Address Extension

Date: 20 January 2011

Policy statement:

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.


The Internet community is rapidly consuming the remaining supply of unallocated IPv4 addresses. During the transition period to
IPv6, it is imperative that Service Providers maintain IPv4 service for devices and networks that are currently incapable of
upgrading to IPv6.
Consumers must be able to reach the largely IPv4 Internet after exhaustion. Without a means to share addresses, people or
organizations who gain Internet access for the first time, or those who switch providers, or move to another area, will be unable to
reach the IPv4 Internet.

Further, many CPE router devices used to provide residential or small-medium business services have been optimized for IPv4
operation, and typically require replacement in order to fully support the transition to IPv6 (either natively or via one of many
transition technologies). In addition, various consumer devices including IP-enabled televisions, gaming consoles, medical and
family monitoring devices, etc. are IPv4-only, and cannot be upgraded. While these will eventually be replaced with dual-stack or
IPv6 capable devices, this transition will take many years. As these are typically consumer-owned devices, service providers do not
have control over the speed of their replacement cycle. However, consumers have an expectation that they will continue to receive
IPv4 service, and that such devices will continue to have IPv4 Internet connectivity after the IPv4 pool is exhausted, even if the
customer contracts for new service with a new provider.

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.

Service providers are currently presented with three options for obtaining sufficient IPv4 address space for NAT444/IPv4 extension
deployments: (1) Request allocations under the NRPM; (2) share address space with other providers (this proposal); or (3) use
address space allocated to another entity (i.e. 'squat'). Of the three options, option 2 (this proposal) is preferable, as it will
minimize the number of addresses used for IPv4 extension deployments while preserving the authority of IANA and RIRs.

Timetable for implementation: immediately

You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
Unsubscribe or manage your mailing list subscription at:
Please contact info at arin.net if you experience any issues.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6753 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110419/0d20df30/attachment-0001.p7s>

More information about the ARIN-PPML mailing list