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

Tue Apr 19 16:44:38 EDT 2011

Wes,

I did not vote to move this proposal forward. I agreed that I thought
that there was need, but I disagreed that this was the best and most
fair way to satisfy that need.

I felt that it was unfair to the community to come in at the last
moment after a more appropriate venue had opted not to slice out
addresses for this purpose and saddle the region with this
requirement. With regards to your sunset idea, we're effectively
creating private address space adjunct to RFC 1918 which will
permanently scorch this set of addresses whether it is formally part
of any private address RFC or not. It would've been "better" to have
provided it from the IANA pool to create a more even burden, but it is
what it is. Aside from the "proper" channel, I would have much
preferred that they obtained these addresses quietly and in a manner
that might have allowed us to save them later such as privately
acquiring them.

Using legacy addresses available for sale could have accomplished this
same fulfillment and been better for the overall community and
possibly addressed more of your concerns.  Even so, there's still no
guarantee that this is going to be fulfilled if it moves forward. Stay
tuned for consultations with the standards bodies on implementation.

So, YES on need, NO on methodology.

Best,

-M<

On Tue, Apr 19, 2011 at 4:14 PM, George, Wes E IV [NTK]
<Wesley.E.George at sprint.com> wrote:
> 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:
> https://www.arin.net/policy/proposals/
>
> The ARIN Policy Development Process is available at:
> https://www.arin.net/policy/pdp.html
>
> Regards,
>
> 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.
>
> Rationale:
>
> 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
>
>
>
>
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>
>
> _______________________________________________
> PPML
> 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:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
>