[ppml] Revising Centrally Assigned ULA draft

[Jeroen Massar]

David Conrad wrote:
> Owen,
> 
> On Jun 16, 2007, at 10:18 AM, Owen DeLong wrote:
>> Therefore, the right thing to do is let ARIN manage
>> address space and let people who run routers manage the routing
>> table.  This artificial management of routing table space through RIR
>> policy simply doesn't work in a v6 world.
> 
> Just to be clear I understand, to summarize what I think you (and  
> others) are saying:
> 
> a) RIR policies shouldn't be used to attempt to constrain (IPv6)  
> routing system growth

This will be solved in time, when needed, with a Loc/Id split. When and
if ever the routing tables really become to large to manage this will be
forced upon people and nobody will suddenly have a problem with it. Work
on this is underway and will be more than done before there are more
than 100k IPv6 routes or a million or two of them, especially as we are
still on <800 of them.

> b) IPv6 PI space should be available to everyone who requests it

Indeed, though with one teeny weeny important addition: Address space is
available on request based on justification of need.

Thus when you say "Hi I want a /48 for my office", the the RIR says
"cool sign up, pay the fees, presto". But when a end-user goes to a RIR
and says "I need a /32 for my office", then they should definitely
request justification for this need of address space. Some of the "IPv6
PI" proposals to date have tried to avoid that justification clause,
which is a waste of address space.

The 'fees' portion is just as an incentive to make sure that somebody
doesn't request a million of them and never uses them, that is the
justification: use your address space. Things people have to pay for
will be used (unless somebody is throwing with cash of course ;)

As current yearly 'fee' for ARIN is only a $100 US for a /48 I really
can't imagine any serious organization who really needs address space
not being able to cough that up, especially when compared to costs for
hardware and paying the actual upstreams or having to renumber when
changing ISP's or having NAT-hell with RFC1918.

Greets,
 Jeroen

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 311 bytes
Desc: OpenPGP digital signature
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070616/8b53e552/attachment.sig>