<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
<title></title>
</head>
<body bgcolor="#ffffff" text="#000000">
<br>
1. If you are going to try and push people on to IPv6, it makes sense
to start at the top. ISPs, carriers, and hosting providers with the
largest allocations will likely have more customers dependent on them,
more of their business at stake, and will also have more in house
expertise. They need IPv4 to do new business, so make their business
dependent on IPv6 and they will have a motivation, as well as the means
to do it. End users should receive IPv6 addresses bundled with new
IPv4 allocations, but end users can't even begin to drive demand unless
there's an IPv6 backbone and some services out there.<br>
<br>
2. That may be the point. While there are IPv4 addresses still around,
there's leverage. The last available IPv4 address will have the most
leverage, but once it's gone, there's no more leverage. I think there's
a very big assumption that IPv4 address exhaustion is the end of the
world and that IPv6 is guaranteed to replace it in a reasonable time
what that event does happen. Maybe there will be a huge Y2K like sense
of urgency and effort to replace and upgrade everything, but maybe
there'll just be more demand to tweak and fiddle with IPv4 to keep it
running just a bit longer. And end users don't need routable IP
addresses do they? We can NAT them all or just charge more. Why give
end users routable and valuable IPv4 addresses when they will just use
them for peer-to-peer copyright violations and/or trying to avoid
censorship? <br>
<br>
So I think there's two approaches - either do nothing, and hope it all
works out - IPv6 should win out, but I think there's a chance that IPv4
could be around forever - there's enough invested in it and enough
motivation to keep what's good enough working a while longer. <br>
<br>
If ARIN is going to do something to replace IPv4 with IPv6, then there
has to be a fixed criteria, but preferably a fixed date. With a fixed
date, people can scramble Y2K like to make the cutoff. If ARIN isn't
going to do anything, then that would still be useful to spell out in
policy - i.e. we're handing out addresses as needed, until the last
IPv4 address is gone, then it's on to IPv6 - let the market sort out
the transition. Or the policy might be at least be to reserve the last
/8 and suspend all existing IPv4 allocation policies at that point - ie
require case by case, committee approval. <br>
<br>
Rich Emmings wrote:
<blockquote cite="mid:Pine.GSO.4.63.0705140933140.29987@troy"
type="cite">
<pre wrap="">Opposed as written.
It a poorly conceived idea when it was "2007-12 IPv4 Countdown Policy Proposal", and the changes do not address the weaknesses in 2007-12.
Comments:
1) Based on conversations, I get the impression that most folks proposing
implementation IPv6, _probably_ have not tried to implement IPv6 on any
large scale. ping6 -I eth0 fe80::xxxxxxxxxxxxxxxx doesn't count. (I will
grant I could be wrong on this, hence "probably".)
2) Artifically making a commodity rare, will cause a run on it before it's rare and push up the dates.
In order to provide something constructive, I think these policy proposals
attempt to bite off too much. Break it down into 3 separate ones.
First, define events on the use curve. (BTW, it's logistic, not exponential)
Not only when we think we need to change policy, but why? Maybe we only
define one point in time for now, and just stay focused on what we need to
do to not get there.
Next, define different policies that ARIN can use with regard to space
assignment. Whether you have a /16 or a IPv6 network might be the factors
that come up here, or whether it's a time based allocation -- you get a /16
for 2 years then have to return it, or some other agreed-to space, if
you're asking for some swing space while you do something else.
Last, tie the first event to policies. Once we approach that event in time,
we have a track record, and can discuss the next best policy to proceed
with.
Discussing actions seperately from events, allows them to be fully discussed
with the ramifications, without getting into the side issues of when
things turn bad. Discussing the events allows a cleaner discussion of
growth, live data, models and expectations. Bringing it together last,
allows a discussion of what-when.
If things are that rotten, then it may be that assignment policies change
now, even before the next event.
On Fri, 11 May 2007, Member Services wrote:
</pre>
<blockquote type="cite">
<pre wrap="">ARIN received the following policy proposal. In accordance with the ARIN
Internet Resource Policy Evaluation Process, the proposal is being
posted to the ARIN Public Policy Mailing List (PPML) and being placed on
ARIN's website.
Policy Proposal Name: IPv4 Soft Landing
Author: David Conrad
Proposal Version: 1.0
Submission Date: 2007-05-02
Proposal type: New
Policy term: Permanent
</pre>
</blockquote>
<pre wrap=""><!---->_______________________________________________
This message sent to you through the ARIN Public Policy Mailing List
(<a class="moz-txt-link-abbreviated" href="mailto:PPML@arin.net">PPML@arin.net</a>).
Manage your mailing list subscription at:
<a class="moz-txt-link-freetext" href="http://lists.arin.net/mailman/listinfo/ppml">http://lists.arin.net/mailman/listinfo/ppml</a>
</pre>
</blockquote>
<br>
</body>
</html>