[ppml] 2005-1 status

Owen DeLong owen at delong.com
Tue Jan 24 02:52:21 EST 2006

We should at least learn some lessons from previous routing scalability
problems.  Personally, I do not believe the routing table growth problem
will ever be solved until we separate the routing identifier from the  
system identifier.  However, until that is done, we have to look at IPv6
as it stands.

What seems to be lost on a lot of the people who keep declaring that
the sky will fall in if we open up IPv6 allocations is that when CIDR
was first implemented, the following promises were essentially
made to the internet community by the IETF and the ISPs in order
to gain compliance and cooperation in implementing CIDR:

	1.	NAT where you can, please.  This is a temporary hack
		to get us by until IPv6 solves these problems.

	2.	IPv6 renumbering will be quick, simple, painless, and,
		therefore PI space will be unnecessary.

	3.	Please use PA space wherever possible for now.  We
		understand that it reduces the usefulness of internet
		routing for your business, but, crashing the core routers
		because they run out of table memory will reduce it
		a whole lot more.

	4.	IPv6 will make PA space as useful as PI space is today
		in IPv4, so, this is a temporary problem.

Of these, the only one that has really been kept is number 1.
Since number 2 was not delivered, and, number 3 is really
just the same fear campaign (which was quite legitimate
at the time, don't get me wrong), number 4 really isn't
true either.

Result:  A large constituency of internet users is no longer willing
to accept the tradeoffs of PA.  Migration to IPv6 will not proceed
beyond early adopter until such time as these issues are addressed
by some method.

Router vendors like the idea of a PA only internet because it is one
less problem they have to solve going forward.

ISPs like the idea of a PA only internet because it simplifies their
topology and provides a barrier to churn.

Customers like PI space because it removes the barrier to churn and
allows for better and more reliable multihoming in the current
environment.  SHIM6 is complicated and has substantial multilateral
dependencies, if it ever reaches fruition.

(Customers is basically the combination of Enterprise, Business, and
sophisticated Home constituencies).

Given these competing interests, combined with the relative  
of hardware vendors and ISPs both on the list and at most ARIN meetings,
I'm not sure how we can make progress on this issue or what the best
ARIN policy could be.

When I started on this process, I did so primarily with the intent of  
the debate out in the public view.  I'd like to see good policy come out
of it in the end, but, I don't know whether that will be possible.


On Jan 23, 2006, at 1:18 PM, Daniel Golding wrote:

> That is proof by assertion. The routing table has grown relatively  
> slowly,
> and there is NO reason to think it will grow faster under IPv6. The  
> argument
> seems to be that IPv6 will have a much longer lifetime than IPv4,  
> so we have
> to plan for 20 or 50 years from now.
> Trying to plan past 10 or so years in technology seems foolish. We  
> can't
> imagine what technology will be like in 50 years. We may be  
> approaching a
> technological singularity, making such projections useless  
> (Kurzweil, et
> al), or the Internet may look completely different by then.
> I understand where the hardware vendors are coming from. Given  
> that, I think
> we need to take it with a grain of salt.
> - Dan
> On 1/23/06 4:10 PM, "Lea Roberts" <lea.roberts at stanford.edu> wrote:
>> because, as I'm sure you remember, Bill, the routing table won't  
>> scale
>> over the lifetime of v6
>> On Mon, 23 Jan 2006, Bill Darte wrote:
>>> OK, I'll start....
>>> Why should the criteria for PI in v6 be ANY different than with v4?
>>> What was large under v4 is somehow not large under v6 apparently?
>>> Turn in you v4 PI block for a v6 PI block.
>>> That's probably a sufficiently high level argument to begin the  
>>> discussion.
>>> Bill Darte
>>>> -----Original Message-----
>>>> From: ppml-bounces at arin.net [mailto:ppml-bounces at arin.net] On
>>>> Behalf Of Lea Roberts
>>>> Sent: Monday, January 23, 2006 3:01 PM
>>>> To: Owen DeLong
>>>> Cc: ppml at arin.net
>>>> Subject: Re: [ppml] 2005-1 status
>>>> well, seems like maybe we should talk it out here (again...
>>>> :-) for a while.  this sounds more like a "PI for everyone"
>>>> policy.  while I'm sure there's a large number of people who
>>>> would like that, I still think it's unlikely it can reach  
>>>> consensus...
>>>> As I said at the meeting in L.A., I still think it is
>>>> possible to reach consensus for PI assignments for large
>>>> organizations and I thought that's where we were still headed
>>>> after the last meeting., i.e. trying to find criteria that
>>>> the latest round of objectors could live with.
>>>> let the discussion begin!    /Lea
>>>> On Mon, 23 Jan 2006, Owen DeLong wrote:
>>>>> Kevin,
>>>>> Why don't you, Lea, and I take this off line and decide
>>>>> what to present back to the group.  I apologize for not having
>>>>> followed up in a more timely manner after the last meeting.
>>>>> Owen
>>>>> On Jan 23, 2006, at 7:54 AM, Kevin Loch wrote:
>>>>>> Marshall Eubanks wrote:
>>>>>>> Hello;
>>>>>>> When last I saw it, 2005-1 was to be reformatted to
>>>> something more
>>>>>>> like its original version.
>>>>>> These were my suggestions using feedback from the last meeting:
>>>>>> To qualify for a minimum end site assignment of /44 you
>>>> must either:
>>>>>>    - have an allocation or assignment directly from ARIN
>>>> (and not a
>>>>>>      legacy allocation or assignment)
>>>>>>    OR
>>>>>>    - meet the qualifications for an IPv4 assignment from
>>>> ARIN without
>>>>>>      actually requesting one.
>>>>>>    OR
>>>>>>    - be currently connected to two or more IPv6 providers with at
>>>>>> least
>>>>>>    one /48 assigned to you by an upstream visible in whois/ 
>>>>>> rwhois.
>>>>>> Assignment prefixes shorter than the minimum would be
>>>> based on some
>>>>>> metric and definition of "sites".
>>>>>> One practical way to look at sites is by number of connections to
>>>>>> separate upstream provider POPs.
>>>>>> +--------------------------+
>>>>>> | Connections | Assignment |
>>>>>> +-------------+------------+
>>>>>> |         <12 |     /44    |
>>>>>> |       <=192 |     /40    |
>>>>>> |      <=3072 |     /36    |
>>>>>> |       >3072 |     /32    |
>>>>>> +-------------+------------+
>>>>>> (C=0.75 * 2^(48-A))
>>>>>> Or if /56 becomes the new default PA assignment shift the
>>>> assignment
>>>>>> sizes right 4 bits.
>>>>>>> Can someone tell me what the status of 2005-1 is currently ?
>>>>>> As far as I know it hasn't changed since the last meeting.
>>>>>> Obviously it should be updated one way or another.  I
>>>> would gladly
>>>>>> write up a formal revision or new proposal if requested.
>>>>>> - Kevin
>>>>>> _______________________________________________
>>>>>> PPML mailing list
>>>>>> PPML at arin.net
>>>>>> http://lists.arin.net/mailman/listinfo/ppml
>>>>> _______________________________________________
>>>>> PPML mailing list
>>>>> PPML at arin.net
>>>>> http://lists.arin.net/mailman/listinfo/ppml
>>>> _______________________________________________
>>>> PPML mailing list
>>>> PPML at arin.net
>>>> http://lists.arin.net/mailman/listinfo/ppml
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
> _______________________________________________
> PPML mailing list
> PPML at arin.net
> http://lists.arin.net/mailman/listinfo/ppml

More information about the ARIN-PPML mailing list