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

[George, Wes E [NTK]]

I like the idea, but I'm not in support of this policy as written, because I
don't agree with the execution.

Specifically, I think that enforcement/implementation is going to be a major
problem due to the potential for abuse, justifiable loopholes, and the
timeline to reach consensus and implement something that is both complex and
polarizing. By the time this works its way through the process, we're going
to be past IANA exhaust and likely well on our way to ARIN exhaust, so the
challenge is to make this palatable before it's too late for it to be
helpful. I don't want us to implement something that it has no teeth, but I
also don't want us to make it impossible for businesses to execute on
existing plans because they didn't do it fast enough for our tastes.
Exhaustion will be enough of a problem without us making it harder to make
the transition by changing the rules at the last minute.

I suggest two alternatives to outright denying new IPv4 allocations that
would still accomplish what I think is the spirit of the policy (to apply
the cluebrick that IPv6 is not optional and the status quo is not going to
be acceptable).
1) Change in fee schedule - if you are a current ARIN resource holder and
you request new IPv4 space without an IPv6 allocation and a deployment plan,
you will pay an additional fee until you show that you have deployed IPv6.
Either it can be a non-trivially increased flat rate (say, 3x existing
fees), or it can be tied to the amount of address space that ARIN has
remaining, indexed monthly. I realize that the second option would create
significant variability in the fees that would be hard to plan for, so we'd
probably need a published maximum fee. Either way, I would recommend that it
be tied to the current fees the requestor is paying, so that it's not
regressive - that is, if you're a size Small, you pay less than an X-large.
Then, as soon as you get IPv6 deployed, you go back to the normal fee
schedule. That would create an incentive to rapidly deploy IPv6, and would
complement the existing waiver of IPv6 fees nicely - perhaps even allowing
us to extend it!

n.b. I originally suggested this here:
http://lists.arin.net/pipermail/arin-ppml/2010-October/018385.html if you
want to read for details. I don't know why it requires so much side
scrolling, sorry about that. 

2) Similar to the executive certification that the records are accurate
which is required when you request new space, ARIN could require executive
certification that the company is in the process of deploying IPv6, with
some specific data to justify this, timelines, address plan, an allocation,
etc.

Some specific comments on the text: 
The policy authors need to revise this to clarify if they want this to apply
to just new allocations or just transfers, or both. It has limited teeth if
it's just for new allocations, but that can't be left open for
interpretation.
Regarding validation:
As others have said, not everyone does DNS for their deployments, which
removes that as a definitive validation point. 
An alternative method of validation might be to verify that IPv6 is being
routed and that at least some of the addresses are reachable. However, this
creates a problem for networks that have no intention of making their IPv6
hosts publicly reachable, and it can also be pretty toothless - I can add
one line of config to make my V6 block visible in the table even if I'm not
actually using it for much yet. 

I like the idea of documentation better, but it also only works in certain
cases, and the language regarding justification is pretty unclear. Most
average ISPs have little or no control over the take rate for IPv6 for their
customers - even less if the customer owns the CPE. So how would they
justify new IPv4 space? 
Is it ok if they simply allocate an address knowing that it's not getting
used by the end customer?
Sounds good, but how do you verify that the requestor has actually done
that, not just on paper? 
If it's just about documentation, wouldn't simply showing an IPv6 addressing
plan be enough?
If so, why not just require that they *get* an IPv6 allocation? As has been
said before when we talked about pre-emptive allocations, not all of the
ASNs in the table even have an IPv6 allocation yet...

If you're going to require a hard and fast percentage of the network to be
dual-stacked, it's not realistic to request that it be 1:1 to the amount of
IPv4 addresses being requested up to 80% of hosts. IP requests are based on
projection of use over a year's time period, and it may not be possible to
meet that test depending on where you are in your IPv6 deployment. 50% is
probably more realistic, but still a challenge in some cases.
It's also not realistic to require 80% of current interfaces be
dual-stacked. In many cases, there is a very serious installed-base problem
that completely precludes dual-stacking existing stuff, and cap and grow is
the only way to deploy IPv6. Additional public IPv4 addresses may be
necessary even if the SP is deploying something like NAT444 in order to
extend the density of their IPv4 usage.

Thanks, 
Wes George 

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of ARIN
> Sent: Friday, December 03, 2010 10:28 AM
> To: arin-ppml at arin.net
> Subject: [arin-ppml] Policy Proposal 125: Efficient Utilization of IPv4
> Requires Dual-Stack
> 
> 
> 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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 6793 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101207/b11127d7/attachment.bin>