North American Network Operators Group
Date Prev | Date Next |
Date Index |
Thread Index |
Author Index |
Historical
Re: ULA and RIR cost-recovery
- From: Pekka Savola
- Date: Tue Nov 30 01:05:25 2004
On Mon, 29 Nov 2004, Owen DeLong 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.
OK, I understand with this sentiment. It's easier for the ISPs to
fend off ("there's no uniqueness, we can't route this stuff!").
# 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.
Sure, I invite discussion on this in the open. The best place would
probably be the global-v6 list at:
http://www.apnic.net/mailing-lists/global-v6/
# 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.
There are many kinds of fragmentation. When you only get (e.g.,) a
v4 /24 for a start, and when you need more, you'll have to get a new
non-adjacent /24, there's going to be fragmentation.
For v6, you can just look at below to see what is the result of
unnecessary stinginess causing fragmentation of allocations (though
luckily not advertisements):
http://www.iana.org/assignments/ipv6-tla-assignments
We _don't_ want to get to a point where each IPv6 ISP or end-site will
have to have dozens of IPv6 prefixes, just because they outgrew the
previous ones. There are enough bits to play around.
It's not as we are carving out v4 /8's (1/256 of space) for early
adopters. Or even /16's. More like the equivalent space of a host
address. That's hardly too much. In fact, it's way too little for
those ISPs which have home customers like DSL, and it's going to be a
a pain because they either must get a new prefix or give their
customers a /64 instead of /48.
--
Pekka Savola "You each name yourselves king, yet the
Netcore Oy kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
|
