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

Thu Jan 20 19:48:06 EST 2011

The one amendment I would make to your suggestion, David would be that rather than specify legacy vs. Virgin, I would specify the dirtiest block(s) in the IPv4 free pool that total a /10.

After all, it seems to me that there is no critical need for this space to be a single aggregate.

One option that occurs to me would be to trade a /10 of more usable space such as 45.192.0.0/10 to APNIC and use a /10 from 1.0.0.0/8. I don't know if that's still possible, but, it seems to me that the high background radiation space makes the most sense for this.

Owen

Sent from my iPad

On Jan 20, 2011, at 4:00 PM, David Farmer <farmer at umn.edu> wrote:

> 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
> ===============================================
> _______________________________________________
> 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.