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

[David Farmer]

I've been watching this on the IETF mailing lists for over two months 
now, kind of wondering if/when it would make it to PPML and the ARIN 
policy process.  The discussion on the IETF mailing lists has been more 
or less a rehash of the arguments raised regarding this issues from a 
number of occasions spanning as much as two years, I believe. Many 
people I respect have come down on one side or the other of this issue.

There was a presentation for the previous version of this that wanted to 
allocate a whole /8 for this purpose at the Atlanta meeting in the Joint 
NANOG/ARIN session on Wednesday morning.

http://nanog.org/meetings/nanog50/presentations/Wednesday/NANOG50.Talk41.Weil.draft-shared_ARIN.pdf

Personally, I dislike the idea on a number of levels, but unfortunately 
I believe it is probably a necessary evil, and a /10 is at least 
palatable.  I wish there was a better answer, but I'm not hearing one.

I believe the proper place for this should have been for the IETF to 
direct IANA to do this, but that didn't happen and its been proposed in 
the ARIN process now and we need to deal with it one way or another.

So I've been thinking about this and if ARIN does this (a VERY BIG IF), 
I believe the most appropriate way would be to allocate 45.192.0.0/10 or 
some other block of returned Legacy address space.

Why?  This close to run-out I find it very hard to justify allocating 4 
million virgin IPv4 addresses from a fresh IANA allocation to ARIN for 
this purpose.   However, recycling graciously returned IPv4 address for 
this purpose would be a little less distasteful in my opinion. 
Furthermore, ARIN has been and probably will be the only RIR that will 
see any sizable returned of Legacy address space; This fact provides a 
uniquely justified nexus for ARIN to consider this proposal instead of 
the other RIRs and even though the IETF failed to come to a consensus on 
the issue.

Additionally, since this block wouldn't be exclusively used within the 
ARIN region, one could argue there is a benefit to using returned Legacy 
resource instead of resource allocated directly to ARIN by IANA.

Therefore, I would like to see a recommendation to use 45.192.0.0/10 or 
another returned Legacy block added to the rationale of this proposal.

Additionally, I would be interested in if/how those modeling IPv4 
run-out accounted/adjusted for the return of most of 45.0.0.0/8.  If 
ARIN made an allocation from this block for this purpose would it have 
any effect on your IPv4 run-out models?

Also, for those directly interested in using this allocation is there 
any downside to using 45.192.0.0/10 or a different returned Legacy 
block?  I'm not seeing any, but I don't have a direct need to use this 
and really haven't considered all the possible issues.

Finally, if we are going to consider this proposal at the San Juan 
meeting, which I believe it has to be, if we are going to bother to 
consider it at all; The AC needs to fast track this proposal to get it 
ready for San Juan.  I don't believe it is reasonable for this proposal 
to wait until the fall meeting, allocating a /10 for this purpose after 
the fall meeting would not be advisable, even if one were available at 
that point.

So, do you believe this proposal should be discuss in San Juan?  Is it 
worth our time?

Thanks

On 1/20/11 10:26 CST, ARIN wrote:
> ARIN received the following policy proposal and is posting it to the
> Public Policy Mailing List (PPML) in accordance with the Policy
> Development Process.
>
> The ARIN Advisory Council (AC) will review the proposal at their next
> regularly scheduled meeting (if the period before the next regularly
> scheduled meeting is less than 10 days, then the period may be extended
> to the subsequent regularly scheduled meeting). The AC will decide how
> to utilize the proposal and announce the decision to the PPML.
>
> The AC invites everyone to comment on the proposal on the PPML,
> particularly their support or non-support and the reasoning
> behind their opinion. Such participation contributes to a thorough
> vetting and provides important guidance to the AC in their deliberations.
>
> Draft Policies and Proposals under discussion can be found at:
> https://www.arin.net/policy/proposals/index.html
>
> The ARIN Policy Development Process can be found at:
> https://www.arin.net/policy/pdp.html
>
> Mailing list subscription information can be found
> at: https://www.arin.net/mailing_lists/
>
> Regards,
>
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
>
>
> ## * ##
>
>
> ARIN-prop-127: Shared Transition Space for IPv4 Address Extension
>
> Proposal Originator: Chris Donley, CableLabs
>
> Proposal Version: 1
>
> Date: 20 January 2011
>
> Proposal type: modify
>
> Policy term: permanent
>
> 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.


-- 
===============================================
David Farmer               Email:farmer at umn.edu
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota	
2218 University Ave SE	    Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================