Wasting address space (was: Re: Last Call: 'Considerations on the IPv6 Host density Metric' to Informational RFC (draft-huston-hd-metric))

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf

[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]