[arin-ppml] Discussion Petition of ARIN-prop-125 Efficient Utilization of IPv4 Requires Dual-Stack

Wed Dec 22 16:21:56 EST 2010

I support this petition.

Best,

-M<

On 12/22/10 3:29 PM, "ARIN" <info at arin.net> wrote:

> The message below started a petition regarding the ARIN Advisory
> Council's decision to abandon "ARIN-prop-125 Efficient Utilization of
> IPv4 Requires Dual-Stack". The AC's decision was posted by ARIN staff to
> PPML on 21 December 2010.
> 
> If successful, this petition will change ARIN-prop-125 into a Draft
> Policy which will be published for adoption discussion on the PPML and
> at the Public Policy Meeting in April. If the petition fails, the
> proposal will be closed.
> 
> For this petition to be successful, the petition needs statements of
> support from at least 10 different people from 10 different
> organizations. If you wish to support this petition, post a statement of
> support to PPML on this thread.
> 
> The duration of the petition is until five business days after the AC's
> draft meeting minutes are published. ARIN staff will post the result of
> the petition to PPML.
> 
> For more information on starting and participating in petitions, see PDP
> Petitions at:
> https://www.arin.net/policy/pdp_petitions.html
> 
> The proposal text is below and 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
> 
> Regards,
> 
> Communications and Member Services
> American Registry for Internet Numbers (ARIN)
> 
> 
> #####
> 
> 
>> -----Original Message-----
>> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
>> Behalf Of Chris Grundemann
>> Sent: Wednesday, December 22, 2010 3:11 PM
>> To: arin-ppml at arin.net
>> Subject: [arin-ppml] Discussion Petition of ARIN-prop-125 Efficient
>> Utilization of IPv4 Requires Dual-Stack
>> 
>> The AC should not have abandoned ARIN-prop-125 Efficient Utilization
>> of IPv4 Requires Dual-Stack. I petition to move the following text
>> forward for discussion on the list and at the next Public Policy
>> Meeting. Please support moving this proposal forward now by posting
>> statements in support of the petition to this list.
>> 
>> ###
>> 
>> 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.
>> 
>> ###
>> 
>> Chris Grundemann
>> www.theIPv6experts.net
>> chris at theIPv6experts.net
>> _______________________________________________
>> 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.