ULA and RIR cost-recovery

Mon Nov 29 20:53:50 UTC 2004


--On Monday, November 29, 2004 21:35 +0200 Pekka Savola <pekkas at netcore.fi> 
wrote:

>
> On Mon, 29 Nov 2004, Leo Bicknell wrote:
>> # 1 Set aside a block for "local" use a-la RFC1918.  This set aside
>>   should make no recommendations about how the space is subdivided
>>   for used for these local purposes.
>
> FWIW, site-locals were dropped (among others) due to concerns about
> sufficient guarantee of uniqueness.  ULA started by having only a local
> generation mechanism, no central allocation at all.  Would that allay
> your concerns?
>
No.  In that case, it makes things even worse because it creates the
promise and illusion of uniqueness without actually delivering uniqueness.
Worst of both worlds... Bigger address-waste (not that it really matters),
non-uniqueness, and the expectation of uniqueness.  To some small extent, 
this
might (_MIGHT_) reduce the pressure on ISPs to route these prefixes, but, 
that
is the only improvement over a central registry.


>> # 3 Drop the absolutely stupid notion that there should be no PI space.
>>   There will be PI space, either by people using ULA for that purposes,
>>   or by the RIR's changing this stupidity after they get ahold of it.
>
> I think we all know there's going to be _some_ form of PI space. Whether
> that's realized by making the policies weaker, by end-sites lying in
> their address applications, or end-sites providing interesting
> interpretation for "other organizations", or a number of different
> mechanisms, the fact is that some form of PI addressing is going to be
> there.  The question just is, what kind, how much of it, and to whom it's
> available.
>
Ideally, I'd like to see us address this up front in a clear and open manner
instead of using nudge-nudge and wink-wink encouragement to make creative
applications for space.  The former can be done fairly.  The latter insures
that the only organizations that have any sort of advantage are the ones
willing to lie to get it.  This tends to happen by accident often enough.
Creating the situation deliberately is, IMHO, absurd.

>> # 5 Stay out of the allocation details.  The RIR's have been allocating
>>   addresses for years.  The RIR's have people, from small to large
>>   ISP's and everything inbetween solving real world allocation
>>   problems every day.  The history tells us is the policy will
>>   change over time.  History also tells us being too liberal early on
>>   can never be "fixed".  The RIR's will change policy as time goes
>>   on to fit the changing IPv6 world.  Let them deal with the policy
>>   on a going forward basis.
>
> The history also tells us that being too stingy when there is no need to
> be stingy will result in useless fragmentation of the addressing, and
> therefore results in the fragmentation of routing advertisements.
>
Actually, that fragmentation was primarily the result of being 
insufficiently
stingy early on.

Owen


-- 
If this message was not signed with gpg key 0FE2AA3D, it's probably
a forgery.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20041129/516929ea/attachment.sig>