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

Wed Apr 20 10:44:47 EDT 2011

I too oppose this proposal.  Let's be really clear here.  The more
appropriate venue is/was the IETF and the IETF turned it down.  It was also
brought up in the APNIC region and that region also turned it down.

----Cathy
ps. here is the link to the proposal in the APNIC region
http://mailman.apnic.net/mailing-lists/sig-policy/archive/2008/01/msg00055.html

On Tue, Apr 19, 2011 at 2:44 PM, Martin Hannigan <hannigan at gmail.com> wrote:

> 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.
> >
> _______________________________________________
> 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.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20110420/c361cf69/attachment.htm>