[arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4Requires Dual-Stack

[Bill Darte]

I've always been reluctant to support policy that dictates configuration
or business practice associated with address allocation.
After all, we have been very reluctant to even speak about routing
policy related to allocation policy.  This seems similar to me.

I also did not believe that this would stand up to legal
challenge...but, I believe that, given the unusual circumstances of
runout, that ARIN believes that more stringent and collateral
requirements may be fovorably argued. 

That said, I am concerned for the length and multifaceted nature of this
proposal which begs for many separate opportunities for the community to
disagree and therefore not achieve overall consensus.

Bill Darte

> -----Original Message-----
> From: arin-ppml-bounces at arin.net 
> [mailto:arin-ppml-bounces at arin.net] On Behalf Of Scott Leibrand
> Sent: Friday, December 03, 2010 9:43 AM
> To: ARIN
> Cc: arin-ppml at arin.net
> Subject: Re: [arin-ppml] Policy Proposal 125: Efficient 
> Utilization of IPv4Requires Dual-Stack
> 
> What do people feel would be the likely impact of requiring 
> IPv6 deployment in order to receive address transfers under 
> NRPM section 8? It seems likely to me that such a requirement 
> would simply result in many such transfers being pushed 
> outside the RIR system...
> 
> I think requiring dual-stack deployment to receive addresses 
> directly from ARIN would be a good idea, bit I'm skeptical on 
> requiring them for transfers. 
> 
> Scott
> 
> On Dec 3, 2010, at 7:28 AM, ARIN <info at arin.net> 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)
> > 
> > 
> > ## * ##
> > 
> > 
> > Policy Proposal 125: Efficient Utilization of IPv4 Requires 
> Dual-Stack
> > 
> > Proposal Originator: Chris Grundemann, Martin Hannigan, 
> Jason Schiller
> > 
> > Proposal Version: 1
> > 
> > Date: 3 December 2010
> > 
> > Proposal type: modify
> > 
> > Policy term: permanent
> > 
> > Policy Statement:
> > 
> > * Add the following sections to section 4.1:
> > 
> > 4.1.2. Efficient Utilization
> > 
> > IPv4 addresses are a finite resource and as such are required to be 
> > efficiently utilized by resource holders in order to maximize their 
> > benefit to the community.
> > 
> > 4.1.3. Dual-Stack
> > 
> > Dual-stack refers to configuring both an IPv4 and an IPv6 
> address or 
> > network together on the same network infrastructure.
> > 
> > All new IPv4 addresses assigned, allocated or transfered to an 
> > organization must be deployed on dual-stacked interfaces along with
> > IPv6 addresses.
> > 
> > 4.1.4. IPv6 Deployment
> > 
> > When addresses are used to provide an Internet facing service, the 
> > service must be fully IPv6 accessible (if you deploy an A 
> record, you 
> > must also have a AAAA record, and both must answer).
> > 
> > * Add the following sentance to the end of sections 4.2.1.6, 
> > 4.2.2.1.2, 4.2.2.2.1, 4.2.3.1. and 4.3.4:
> > 
> > In accordance with section 4.1.3 and 4.1.4, all new 
> addresses must be 
> > deployed on dual-stacked interfaces and all Internet facing 
> services 
> > provided by new addresses must be fully IPv6 accessible.
> > 
> > * Re-write section 4.2.3.4.1. to:
> > 
> > Reassignment information for prior allocations must show that each 
> > customer meets the 80% utilization criteria, the dual-stack 
> criteria 
> > and must be available via SWIP / RWhois prior to your issuing them 
> > additional space.
> > 
> > * Add the following section to section 4.2.4:
> > 
> > 4.2.4.5. IPv6 Deployment
> > 
> > In order to receive additional space ISPs must provide detailed 
> > documentation demonstrating that:
> > - for every IPv4 address requested, at least one pre-existing 
> > interface is dual stacked, up to 80% of all interfaces and
> > - for every down stream customer site where the new 
> addresses will be 
> > deployed, at least one pre-existing down stream customer 
> site is IPv6 
> > enabled, up to 80% of the total customer base.
> > 
> > * Add the following to section 4.3.6:
> > 
> > 4.3.6.3. IPv6 Deployment
> > 
> > In order to receive additional space end-users must provide 
> detailed 
> > documentation demonstrating that at least 80% of their 
> existing IPv4 
> > addresses are deployed on dual-stacked interfaces in 
> accordance with 
> > section 4.1.3.
> > 
> > Rational:
> > 
> > In this period of available IPv4 address scarcity and transition to 
> > IPv6, IPv4 addresses that are not deployed along with IPv6 
> are simply 
> > not being efficiently utilized. Although we have likely failed to 
> > deploy dual-stack in a meaningful way in time to avoid transition 
> > problems, we can still choose the correct path for future 
> assignments, 
> > allocations and transfers.
> > 
> > This proposal has three objectives:
> > -1- Encourage IPv6 deployment prior to and post depletion
> > -2- Enable growth of IPv4 to accelerate IPv6 transition 
> #[only change 
> > was to this line]#
> > -3- Improve the utilization of IP addresses
> > 
> > It accomplishes these goals by enforcing three basic ideals:
> > -1- ARIN will only make allocations and assignments for 
> networks that 
> > have already deployed production IPv6
> > -2- Any new IPv4 addresses received, must be deployed along side of
> > IPv6 (dual-stacked)
> > -3- Firmly encourages deployment of IPv6 in existing IPv4-only 
> > networks
> > 
> > The specific requirements to be enforced can be summed up 
> in this way:
> > ~ New addresses must be deployed on dual-stacked interfaces 
> plus one 
> > additional pre-existing IPv4-only interface must be 
> dual-stacked per 
> > new address, up to 80% of all interfaces.
> > ~ For each down stream customer site where these addresses are 
> > deployed, another pre-existing IPv4 only down stream site 
> must also be
> > IPv6 enabled, up to 80% of the total customer base.
> > ~ All end-sites must dual-stack before getting new space.
> > ~ Internet facing services that new IPv4 addresses are used 
> to provide 
> > must be fully IPv6 accessible.
> > 
> > 
> > 
> > _______________________________________________
> > 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.
>