[arin-ppml] IPv6 Transition Policy (aka Soft Landing)

[George, Wes E IV [NTK]]

As we discussed at the meeting, I like the idea of treating IPv4-only deployment as inefficient use of the space, because it puts teeth into what ARIN has been saying for years now, but I think that the execution of this one could get us into a lot of trouble if not done carefully, especially if done as an emergency action.

Might I suggest an alternative method of creating an incentive to deploy IPv6?
Instead of flatly denying new IPv4 resources if you don't already have IPv6 deployed, why not give requestors a choice?
That is, you can either demonstrate that you have deployed IPv6 (and that any customers to whom you delegate that space are also deploying IPv6), or you can pay an increased registration fee for your new IPv4 space. 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. Yes, 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 that people could plan for. 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.

If people are worried about this looking like a money-making exercise for ARIN, perhaps we could redirect those extra fees into funding assistance and education for IPv6 deployment?
The idea here is to remove the argument that the costs of making your network IPv6-capable is higher than doing nothing (until the absolute last possible minute), without creating the net effect of simply moving the IPv4 exhaustion brick wall forward by 200 feet in the name of a "soft landing."

We all know that there are 900 ways to sink this proposal because it materially impacts someone's ability to do business pre-runout, and there may be things beyond their control in terms of timing, which is why I'm hesitant to support a straight denial without some way of managing the impact of suddenly changing the timeline. However, loopholes/cutouts/exceptions are a quagmire, because everyone will have a reasonable argument for why their chosen line of business should get one, and if we enact them all, the rule has no teeth, and if we don't enact them all, there's a question of fairness that likely leads to legal troubles.

Really, there are 2 categories of folks that would be negatively affected by policy like this -
1) those who have started deployment (for some definition of those two words) but have limiting factors that won't be resolved before their need for additional IPv4 space
2) those who have not started deployment for <reason>

It's difficult to make the case to punish #1 for not going fast enough for our tastes, especially if they've been using the current projections for exhaustion as their rough timeline for when they have to have IPv6 ready. As it is, they'll likely get a punishment of sorts when the projections are wrong and they can't get addresses they were expecting to be able to get.
You might argue that #2 may have a legitimate reason(s), but if they're asking for more space, that argument is shaky to say the least.

Wes George

> -----Original Message-----
> From: arin-ppml-bounces at arin.net [mailto:arin-ppml-bounces at arin.net] On
> Behalf Of Chris Grundemann
> Sent: Friday, October 08, 2010 12:01 PM
> To: arin-ppml at arin.net
> Cc: Jason Schiller
> Subject: [arin-ppml] IPv6 Transition Policy (aka Soft Landing)
>
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
>
> Objectives:
> -1- Encourage IPv6 deployment prior to depletion
> -2- Enable growth of IPv4 where IPv6 is being deployed
> -3- Improve the utilization of IP addresses
>
> High-Level Requirements:
> -1- ARIN will only make allocations and assignments for networks that
> have already deployed production IPv6
> -2- Any IPv4 addresses received under this policy, must be deployed
> along side of IPv6
> -3- This policy will encourage deployment of IPv6 in existing IPv4-only
> networks
>
> Rough Policy Text:
> ~ Requester defines classes in their network - only classes where IPv6
> is in production qualify for IPv6
> ~ New addresses must be deployed on dual-stacked interfaces plus one
> additional existing IPv4-only interface must be dual stacked, up to
> 80% of all interfaces.
> ~ The service that the address is used to provide must be fully IPv6
> accessible (if you deploy an A record, you must also have a AAAA and
> both must answer)
> ~ All end-sites must dual-stack all Internet facing services before
> getting this space
> ~ 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.
>
>
> This is an emergency, let's get something together ASAP. All feedback
> is extremely welcome and greatly appreciated; this problem is all of
> ours. If you are still here in Atlanta come find me, Marty Hannigan
> and/or Jason Schiller to discuss.
>
> Thanks!
> ~Chris
>
>
>
> --
> @ChrisGrundemann
> weblog.chrisgrundemann.com
> www.burningwiththebush.com
> www.coisoc.org
> _______________________________________________
> 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.


This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.