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

[Chris Grundemann]

I find it very interesting the tone and attitude that a couple of
folks have taken wrt prop-125. Those folks seem to want us to believe
that this policy somehow forces everyone (or anyone for that matter)
to adopt IPv6.

Statements such those immediatly below seem to illustrate the
propegation of this misconception:
 "Top down enforcement from an external entity (ARIN) will tend toward
poor implementations."
 "...dictating should be reserved only for those situations in which
it is truly justified."
 "...tying them up,tossing them in the back of a truck and unloading
them into the single pub of your choosing."

While this proposal does reward those who have deployed IPv6, the
simple fact is that even if we (the community) wanted it (I don't
think we do), ARIN could never force anyone to adopt IPv6.

As stated in the rational, this proposal has three objectives:
To encourage IPv6 deployment prior to and post depletion,
to enable growth of IPv4 to accelerate IPv6 transition and
to improve the utilization of IP addresses.

It appears to me that a few folks are focusing on (and exaggerating)
the first without due consideration for the other two objectives.

The reality of our situation is that the (vast) majority of ARIN
resource registrants have already received their last free/normal
allocation or assignment from ARIN. The IANA will hand out the
remaining free pool v4/8s within weeks, if not sooner. ARIN will hand
out it's remaining reserves in less than a year. All of this means
that most organizations will never receive more IPv4 addresses
directly from ARIN ever again and there is nothing we can do to change
that (without fairly disastrous side effects).

This leaves us in a situation where a relatively small number of
organizations will be queuing up for an even smaller number of IPv4
addresses. Questions must be raised in situations like this, questions
regarding need, efficient utilization and stewardship. Some of these
questions are already being answered by ARIN staff. As we dive deeper
into free pool exhaustion, resource reviews are getting stricter, it
is becoming harder to justify new IPv4 addresses, audits are more
common, etc. All of this is guided by community built policy and
therefor I believe that we should ask ourselves some of these
questions as well, rather than leaving it all on the shoulders of ARIN
staff.

We have tried to answer many of these questions with prop-125:
We as a community and ARIN as an organization have been beating the
IPv6 drum for years, why not reward the folks who answered our call
and actually deployed IPv6?
Why not ensure that the remaining IPv4 addresses are used to build
truly sustainable infrastructure?
Why allow scarce and valuable IPv4 addresses to be wasted on legacy
equipment, in legacy networks?

I think that too many people look at address policy (and many other
things for that matter) very selfishly. Lots of folks are trying to
find ways to meet their own needs and make their own lives easier.
Many more only look at policy from their own singular perspective and
thus only see trees. This policy attempts to zoom out, look at the
forest and from this holistic perspective make decisions regarding
what is best for the entire community and all of the industries and
economies represented within it.

When looking at the big picture it becomes clear that at this stage,
IPv4 addresses that are not deployed alongside of IPv6 are being
wasted. The only question that remains is if we can step up, look past
our own personal difficulties and do the right thing for the Internet.

Please make your voice heard and speak up in support of this policy!

$0.02
~Chris

PS - There has been another argument, that not everyone
will/should/can dual stack and that someone who deploys a parallel
IPv6 network should not be left out of the rewards of deploying
production IPv6. I completely agree. I am more than willing to help
revise the text of this proposal to include that scenario once the
petition succeeds, if not sooner. I think that these mechanical
details will all be fairly trivial to work out once the petition
succeeds.



On Wed, Dec 22, 2010 at 13:29, 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.
>

-- 
@ChrisGrundemann
weblog.chrisgrundemann.com
www.burningwiththebush.com
www.theIPv6experts.com
www.coisoc.org