[arin-ppml] IPv6 Transition Policy (aka Soft Landing)
cgrundemann at gmail.com
Sat Oct 9 15:34:02 EDT 2010
Let me offer a general response to all of the great feedback:
The basic idea here is to redefine efficient utilization. The fact is
that at this point (and for quite some time now) IPv4 addresses that
are not deployed along with IPv6 addresses are simply not being
efficiently utilized. Just like assigning a v4/24 to a PTP link is
wasteful, deploying IPv4 only is wasteful.
Many folks have made comments that effectively say "this is hard" and
that in some cases, IPv6 deployment is still impossible. What do you
think is going to happen next year when there is no more IPv4? This
policy effectively places a new wall in front of the no-more-v4-at-all
wall. The effect is to apply real pressure now, so that we have less
Every crazy scenario that you can think of with regard to IPv4
depletion is going to happen - all of it. The real question is not how
bad it will be (bad) or when it will happen (soon) but rather how long
will it last? The answer depends on whether this community decides to
step up and provide real leadership or not.
The only true soft-landing strategy that will allow the transition to
happen without pain is to dual-stack everything and simply let traffic
shift over from v4 to v6. That ship has sailed. So now we have two
1) Change nothing and run into the wall. This idea has merit in that
we stick to our guns, and provide some predictability by not changing
2) Require IPv6 deployment now. This idea has merit because it allows
IPv4 to keep growing while also softening the blow when new IPv4 runs
The way to implement option #1 is pretty obvious. The method to affect
option #2 is probably a bit less clear. What Jason, Marty and I have
come up with here is a start at defining that method. Due to the
applause at open mike, the in-person feedback in Atlanta and the
responses here on the list - I am going to assume that this is
valuable and that there are a lot of folks in the community who think
that option #2 (action) is preferred to option #1 (inaction).
So - where do we go from here?
I would like to propose that we start with a high level discussion of
whether or not this basic idea is what the community wants and then
(if we do want this) dive quickly into the details of how exactly to
With that in mind, I set up a quick poll on doodle:
I will post the poll to ppml separately as well to grab the widest
audience - please forgive the double post. Feel free to share the poll
with all other interested members of the Internet community.
"Those who do not create the future they want must endure the future they get."
~Draper L. Kaufman, Jr.
On Fri, Oct 8, 2010 at 10:00, Chris Grundemann <cgrundemann at gmail.com> wrote:
> Problem Statement:
> We have failed to deploy dual-stack in a meaningful way in time to
> avoid transition problems
> -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.
More information about the ARIN-PPML