[ppml] Revising Centrally Assigned ULA draft

John Santos JOHN at egh.com
Mon Jun 18 04:06:47 EDT 2007

It's easy to shoot down a proposal if you just assume it says something
it doesn't.

1)  Nothing prevents ISPs from continuing to get large chunks of PA
space and assigning suitable small chunks of that to their customers.
IE aggregation just as it exists to day.

This would probably serve the needs of 99% of their customers.

2) There is no guarantee of routability given.  If you want your
/48 routed, you will have to find someone willing to route it.
Presumably, they would charge you for it.  Presumably, they would
charge you much less to route a /48 (or whatever) they assigned
to you out of their PA space.

ARIN is in the number administration business.  It is *not* in the
routing business.  It doesn't route anything for anybody (except
maybe itself.)

Maybe the problem here is people are expecting ARIN policy to enforce
their business policy so they don't have to give the customer the
bad news that they are going to charge them an arm and a leg to
route their small subnet.  Instead, they just try to keep ARIN's
policy such that their customers can't get small subnets in the
first place.

John Santos
Evans Griffiths & Hart, Inc.
781-861-0670 ext 539
-------------- next part --------------
In a message written on Sat, Jun 16, 2007 at 08:26:46PM -0700, David Conrad wrote:
> Further, the rationale for a /32 for ISPs no longer appears to make  
> sense.  If everybody can get a /48, why would ISPs need 16 (or more)  
> additional bits of address space than everybody else?  Since their  
> customers would be bringing their own address space with them, why  
> wouldn't they be like every body else and get a /48 and, if  
> necessary, get more /48s (at $100/year) for their internal  
> infrastructure as they need it?

So, let me repeat what I got out of your message to make sure I'm
understanding your question:

RIR's would give out one /48 to any organization that requests one
and charge them a fee of $100.  There would be no other requirements
to get space.

Here's the simple problem, you give up all aggregation day one.
This is rather significant.  I'm going to (probably mis)quote Jason
Shiller here that (roughly) "Verizon Business has as many internal
routes as there are routes in the default free zone".  Now, not all
will be customers, some will be internal links, loopbacks and the
like.  However, were all those customers to have non-aggregateable
allocations from ARIN then Verizon Business would have no way to
summarize any of those routes, and would dump (in order of magnitude)
roughly as many prefixes into the DFZ as are there now.

Lather, rince, repeat for other ISP's.

I believe were a plan as you describe implemented the number of
routes in the default free zone would jump by at least one order
of magnitude overnight, perhaps closer to two orders of magnitude.

Can routers be built to handle that?  I'm sure they can, but the
market really hates a step function, and virtually none of the
existing hardware could support it.  So even if we could get there
and thought it was a good thing, it would be a very painful transition.

I do believe though, that you are correct that if we did give
everyone a /48, there would be no reason for most ISP's to get more
than a /48 themselves, save perhaps those with large amounts of
single IP dynamic customers (e.g. Cable Companies) that might
actually exceed the 65536 subnets available...

       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/20070618/ac63b6eb/attachment-0001.sig>
-------------- next part --------------
This message sent to you through the ARIN Public Policy Mailing List
(PPML at arin.net).
Manage your mailing list subscription at:

More information about the ARIN-PPML mailing list