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

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