[arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)

[Alexander, Daniel]

Owen,

Can you expand on your thought below? Why do you think giving a customer a /56 is harmful to innovation on the Internet?

-Dan

________________________________
From: arin-ppml-bounces at arin.net [arin-ppml-bounces at arin.net] on behalf of Owen DeLong [owen at delong.com]
Sent: Wednesday, November 17, 2010 5:16 PM
To: Ted Mittelstaedt
Cc: arin-ppml at arin.net
Subject: Re: [arin-ppml] Sensible IPv6 Allocation Policies - Rev 0.8 (PP 121)


On Nov 17, 2010, at 2:10 PM, Ted Mittelstaedt wrote:

On 11/17/2010 1:30 PM, Owen DeLong wrote:
Ignoring the personal attacks, I've answered Ted at length in private email.


Owen has indeed responded to the DFZ issue to me via private e-mail.  It is a logical, concrete response that really has nothing at all with the items listed here.  I wish that he would have included it in his response here.

Ted



I consider it pretty well related, but, at Ted's request, I will saddle
you all with that piece of my response to him:

By increasing the maximum amount of space allowed (possibly dramatically),
if anything, this should reduce the impact on the DFZ.


And the logical reason for this is....

Because it will reduce the number of organizations that come, get a /32, discover
that isn't enough, come back, get a /31, fill that up, come back, get a /30... Which
is one of two possible outcomes of current policy. The other possible outcome
is that LIRs will be assigning end sites blocks smaller than /48 in order to have
the ability to support more than ~60,000 customers which, while not harmful
to the DFZ is harmful to innovation on the internet in general.

We have already seen this harmful behavior in Europe (Free.fr<http://Free.fr/> is giving
customers /60s), Asia (many ISPs are squeezing their customers into
prefixes of /56 and /64 in order to squeeze their entire networks into
a /32), and North America (several IPv6 trials have involved prefix sizes
ranging from /52 to /60).


Owen

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20101118/29596165/attachment.htm>