On 29-aug-2007, at 17:17, [EMAIL PROTECTED] wrote:
But what would be the point of doing that now?
Basically, the minimum prefix size * number of assignments * LIRs,
when projected over a timeframe of decades, while preserving a global
DFZ consisting of one PI block per LIR, has a problem fitting into the
number of bits per RIR.
(Please note the difference between the provider aggregatable (PA)
blocks that are _allocated_ to LIRs/ISPs and the provider independent
(PI) blocks that are _assigned_ to end-users (which may also be
considered "LIRs" under the definition "LIR = anyone who pays the RIR
fee".)
Simple problems have simple solutions: if your current block is not
big enough, get a second block.
Right now, RIRs are reserving only an additional 2 bits per LIR
assignment,
for "growth". Alternative allocation policies (bisection) don't
guarantee
the ability to assign arbitrarily large blocks indefinitely - while
that
is in fact the long-term requirement.
It's three bits: a /29 is reserved for each allocated /32. However,
the problem with this approach is that a quick look at the IPv4
routing table shows that the potential for aggregation created thusly
isn't fully realized in practice. Reserving address space in this
manner has two downsides:
- rapid fragmentation of relatively large amounts of address space
- increased potential for deaggregation because the maximum prefix
length is often longer than the actual prefix length
Because of this, it's my opinion that the current practices are
harmful and should be replaced by a new way of allocating, where all
prefixes from a certain block have the same length, so it's possible
to filter on this prefix length. The size of subsequent blocks is
increased by a certain factor (I'm thinking 4 - 16) until an upper
limit is reached beyond which the value of limiting the number of
prefixes becomes lower than the downside of the potential address
waste. For IPv4 this should probably be something like /12, for IPv6
I'm thinking /24.
What works best is, a best-fit approach, where any organization
gets way
more space than they need, sized according to their own best guess
as to
long-term growth *potential*.
It's a waste of time and address space if the people don't aggregate,
and IPv4 experience shows this doesn't happen as much as it should.
The fact that we have so many local bits in the IPv6 address is our
insurance policy against address policy screwups because a single /64
is enough to run a network of arbitrary size if you forego stateless
autoconfig.
The same would be true of /80, which is what MAC-48 would result
in, for
minimum prefix size for autoconf (and thus the standard end-user
assignment
size).
I guess 48 bits is enough for all private networks, too, yes.
However, if we make this move now we can't make it in the future
anymore, so we've wasted the additional 16 bits. If we keep things
the way they are now this has the obvious advantage of not taking
action over taking action, and it allows us to squeeze out 16 bits
and still have autoconfig based on 48 bit identifiers at some point
in the future. However...
The overall benefits to address space assignment, IMHO, outweigh
that cost,
I disagree. It would be pretty hard to go from 64-bit autoconfig to
48-bit autoconfig in a backward compatible way, because the global/
local bit that is very important here is in the upper 16 bits. It
also kills efforts like CGA and HBA, where the interface identifier
bits are used for crypto purposes. ~64 bits is already not very
strong, ~48 would be too weak. Yes, we already have legacy
considerations in IPv6.
especially when considering the long-term health of the DFZ and the
cost
to member organizations when having to do expensive upgrades to their
entire infrastructure to support bloat in the DFZ.
By adopting PI in IPv6, the community is saying that this isn't an
issue.
Apart from that, what we need to control the DFZ under the current
regime is the ability to make good prefix length filters. Currently,
RIPE has says the maximum prefix length for 3 /8s is /29. This means
that a filter that conforms to the RIPE policy will allow 6 million
prefixes under full deaggregation. RIPE also gives out very large
IPv6 blocks such as /19 and /20 from 2a01::/16 but also /32s. This
means a filter must allow /32s so the holders of that /19 can
fragment their block into 8192 /32s if they want. All the while, the
utility of using a /19 over, say, 32 (or 28, or 25...) /24 for
reasons of DFZ health is negilible because by the time 2000::/3 is
filled up it's almost certainly possible for routers to handle 2^
(24-3) = 2 million prefixes. Giving out such large blocks only
increases the potential for deaggregation while at the same time
potentially wasting an awfully big number of addresses because the
larger the block, the bigger the difference between the number of
available addresses and the number of addresses actually used.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
