[ppml] [address-policy-wg] Those pesky ULAs again

[Leo Bicknell]

In a message written on Tue, May 29, 2007 at 05:05:56PM -0700, Tony Hain wrote:
> > Even if ULA central is useful, I don't think it is something the RIRs
> > need to be involved in.
> 
> To avoid the perpetual arguments about ULA-C vs. PI, it would be best if
> both were handled by the same organization to avoid the additional nonsense
> about an end run around the process. There is also the case that only
> organizations that really care would even be asking for ULA-C, and if they
> care enough they would be willing to become RIR members if need be.
> Additional recurring revenue for what is essentially a one-time effort
> should be enough of a reason for the RIR's to be involved.

I'm not sure I've seen the argument made this way before, but to
me it's a new, a good argument.  Specifically "RIR's should administer
ULA-C so they can help direct people to ULA-C or PI as appropriate."
I think that's an accurate morph of your statement.  While I'm still
not sure about ULA-C, thinking about it that way makes me think
that if it is implemented, the RIR's are the right place.

> Now we find the routing world arguing about 'waste' because they are just a
> greedy bunch that really don't want others to have something that they think
> they control, even if the can't use them. To prove the point, line this up
> with the FUD about not being able to route /48's as PI space because there
> are just too many of them. If there are too many /48's, what in the world
> would the routing system do with more bits? This occurs in the /48-/56

This is distorting a near-term problem.

If in 1993 I told you that your AGS+ with 8M of ram would need to
route 200,000 prefixes from 200 different BGP sessions you would
have laughed me out of the room.

Today we think of a 5,000,000 prefix Internet as an impossibility.
No hardware could ever do that.  However, 20 years on I'm not sure
a 5 million route Internet will be surprising to anyone.

The fact that we might not be able to route a /48 for everyone who
wants PI with today's hardware, or even in 5 years time does not
mean we should flush the possibility down the drain by giving those
who are worth of of space today so much space there will be none
left tomorrow.

At the time of the AGS+, giving HP a /8 and DEC a /8 "made sense".
Today having one company that doesn't even provide any Internet
services directly having a /7 (15/8 and 16/8) seems absolutely
absurd.  At the time having them consume a single route in your AGS
seemed like a great idea.  Today having them consume 4 /19's (as
an example) might seem like a better tradeoff, 4 routing slots in
exchange for using 10 bits less of address space.

The thing of it is, as we're seeing with IPv4, taking space back
is really hard.  Now, some people think that a 25 year lifespan for
IPv6 is "doing good".  I think if by allocating addresses more
prudently we could make it 50 years, that's billions of future
dollars and effort saved, and more important to me, perhaps avoiding
the next version of this transition in my lifetime!

I believe the problem when we get into these arguments though is
that it seems like there two options for the pendulum, the far left
and the far right.  I would hope as a community we could do a better
job to find the middle, but no one on either side of the argument
seems interested in understanding where the middle might actually
be located.

"You're a big company, and you have to use Class C subnets, so you
should have 65536 of them, here's a Class A."

"You're a big company, you have to give out /48 subnets, so you
should have 65536 of them, here's a /32."

Seems like we could have at least been creative this time around
and picked a different number.  Why do big companies need 65536
subnets?  The number must be magical.

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070529/14fb82cf/attachment.sig>