On 3-jun-2006, at 5:33, Steven Blake wrote:
I am concerned about the conclusion reached in this document (that HD
ratios > 0.8 and closer to 0.94 should be considered when making
address
allocations to larger providers). I believe that:
(1) this would not solve a real problem,
A little foresight never hurt anyone. If IPv4 space had been given
out using today's policies from the start, that would have given us a
decade or so more time with IPv4.
(2) it is risky to infer too much from existing network design
practice when considering future provider networks that may
be much larger, and
I agree.
(3) there is a better solution to the alleged problem.
1. To begin, the following number of /48 site prefixes can be
allocated
out of 2000::/3, for various values of the HD ratio:
You assume that all address space given out will actually be used to
address customers. That's unlikely, especially as address blocks get
larger: when the blocks get larger, both the likelihood of it all
being used (for your favorite defintion of "all") decreases, along
with the likelihood of enough of it being used so that it can't be
reclaimed.
I think we're going to see this with IPv4 too. Today, some 10% of all
allocations/assignments account for some 90% of the address space
used, with block sizes in the million range. For instance, France
Telecom got a /9 earlier this year. If they somehow fail to connect
millions of customers in the forseeable future, a very big chunk of
those 8 million+ addresses are going to be left sitting on a shelf
where they can't be used by anyone else.
[...]
Of all the challenges that will have to be solved to realize such a
large internet, IPv6 address exhaustion should be the least of our
worries.
I agree that we shouldn't impose stricter policies than necesssary,
but allowing people to waste one address bit out of every five
between their prefix length and /48 is completely unnecessary. You
lose a maximum of one digit (bit in our universe) per aggregation
level so 80% = lose 20% of your address bits means assuming a level
of aggregation for every four address bits. In other words, creating
an aggregate that covers 16 routes. That's fairly ridiculous. An
aggregate per 1024 or _maybe_ 256 routes makes sense. That would be
91% or 86%.
But I see no reason why people requesting a prefix shorter than, say,
a /28, wouldn't be able to provide insight into their _actual_
internal address aggregation.
And yes, we should limit the maximum block sizes people can get. The
risks increase as blocks get larger while the benefit of having a
single large block rather than several small ones decrease. At some
point, it's not worth it anymore.
Note that the
number of possible providers cannot grow by more than an order of
magnitude from today's number, for a variety of economic and
logistical
reasons (and some would argue that the number has already peaked).
That's economics which is much, much harder to predict than
technology, which we have a hard enough time with anyway.
In a
world with tens or hundreds of billions of subscriber sites, the
largest
providers may have more than a billion subscribers.
Under one prefix? Yeah right.
3. /48 site allocations are massive overkill for residences and SOHOs.
Assume 10e9 organizations (~1 per-person) needing four /48 allocations
each (for multi-homing). Assume that the remaining hundreds of
billions
of residence/SOHO sites can function with /56 site allocations.
2000::/3 can accommodate these 40e9 /48s plus an additional
2.89e12 /56s
with HD = 0.80 (with no tricks, such as the max /16 assignments
suggested above).
A /56 allocation is more or less equivalent to an IPv4 /16 allocation
(256 Class C subnets). I will be delighted if my residential provider
ever offers me a /60 IPv6 allocation.
/56 is a very bad prefix size, as it's still way too large for SOHO
use, and for people needing more it's both small enough to grow out
of after some time, but big enough to be really inconvenient to
reengineer into a /48. (Which is more than simply renumber.)
Having to choose between /60 and /48 would be much better than having
to choose between /64 and bigger in general, as it removes the "will
I ever need a second subnet" consideration, the average allocation
size goes down and moving to a /48 after having grown out of a /60
isn't too painful.
Being unnecessarily conservative with address allocations to providers
will only increase the chance that they will be unnecessarily
conservative with address allocations to subscribers.
It's also really helpful if all ISPs use the same subnet sizes. For
instance, I can set up my routes as DHCPv6 prefix delegation clients,
so they can be reconfigured with new address prefixes automatically
when changing ISPs, but I still need to put the subnet bits (and
therefore the subnet size) in the configuration by hand, so having to
change that defeats the purpose of the exercise.
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf