[ipv6-wg at ripe.net] HD ratio issues and revisiting /48

Consider this my input for tomorrow's discussion. I'm far away but  
I'll be with you guys in spirit. (And watching!)

Ok, this message is becoming rather long. Skip to the end for the  
practical stuff if necessary.

I believe Geoff's point with the presentation yesterday was "with  
only 45 bits to play with and considering the HD ratio IPv6 address  
space isn't as unlimited as it once seemed".

The whole idea behind the HD ratio is that the more you have, the  
more you waste. And "more" isn't just more in absolute terms, but  
also in relative terms. Essentially an HD ratio of X percent says  
you'll waste X percent of your address bits. To some degree, this  
makes sense. If you have a flat numbering plan you need N numbers  
plus some wiggle room. But if you introduce a strictly hierarchical  
addressing plan, you need more wiggle room. For instance phone  
numbers we have in most European countries have area codes for cities  
and then subscriber numbers within each city. When phone numbers in  
Amsterdam run out, they can't borrow numbers from The Hague. So not  
only do we need wiggle room for both aggregation levels (national and  
city), but in phone numbers we also lose some serious number capacity  
because the boundary isn't very flexible. In the Netherlands even the  
smallest area codes hold 6 digit subscriber numbers. This eats up  
more numbers than when you can give the smallest area codes 5 digit  
numbers, or better yet, use 4.5 - 7 digit as needed.

Now the interesting thing is that the HD ratio RFC (RFC 3194) is for  
a large part based on experiences with French phone numbers. It's  
easy to see that even though Alain Durand and Christian Huitema are  
obviously on to something, there must be a problem somewhere, as they  
write that the practical maximum (= HD ratio of 87%) utilization for  
IPv4 is 240 million addresses. (Actually that would be 211 million,  
they didn't compensate for class D and E and other unusable address  
space.) However, according to the most recent ISC host count were now  
at 317 million (= hosts present in the reverse DNS) while only 2.5  
billion out of 3.7 billion usable IPv4 addresses have been allocated  
by IANA. So the current HD ratio for usable non-reserved IPv4 space  
is 90.5%, and this includes legacy space, so if we were to look at  
RIR space only, this would certainly be even higher. If we apply the  
same HD ratio to the remaining 1.2 billion addresses, we should be  
able to grow to 480 million IPv4 addresses in use without even taking  
legacy space issues into account.

The HD ratio also doesn't account for the nature of the number  
hierarchy. In phone numbers or classful IPv4, you can't move the  
aggregation boundaries around. But with CIDR and VLSM (variable  
length subnet masks, at one point a great innovation), this is not a  
problem. So if you have 8 locations that need 100 - 800 addresses  
respectively, you don't need 8 x 1024 = 8192 addresses, but 128 + 256  
+ 3 x 512 + 3 x 1024 = 4992 addresses, or even 1, 2, 3, 4, 4, 5, 6, 7  
* 128 = 4096 addresses. This will of course push some of the pain up  
the next aggregation level, as rather than a single route there will  
be 8 to 32 individual routes. When we cross over to inter-domain  
routing, this is clearly harmful since we are currently unable to  
aggregate in the interdomain routing space unless aggregation was  
already done (or at least possible) at the source AS. But for  
interior routing, this really isn't much of a problem.

Even when routing a billion (2^30) /48s, that would boil down to:

2 levels, strict hierarchy: 2 * 2^15 routes
3 levels, strict hierarchy: 3 * 2^10 routes

This is all very doable with today's hardware. Even if we assume a  
size difference of a factor 64 between the largest and the smallest  
entities in a loose hierarchy (ie. if Mexico City is your largest  
entity, the smallest would be a city with less than half a million  
people) that's 2^15 + 2^21 with two levels and 2^10 + 2^16 with three  
levels.

Conclusion: you don't _have_ to lose one bit out of five as the  
allocated address space gets bigger.

This also applies to interdomain routing. If you want to number 4  
billion end-sites, Geoff's presentation lists a /8 as the prefix  
length of choice. But 4 billion also happens to be 256 * 16 million,  
and for 16 million we only need a /18. So 256 of those would be a / 
10. We just saved 2 bits but now we have 256 /18s in the global  
routing table rather than one /8. But even someone who gets as much  
flack for not trusting the router vendors to come up with bigger  
boxes as me can appreciate that routing a larger number of /18s isn't  
going to kill BGP (there can only be 32 - 256 thousand /18 routes  
anyway).

(With apologies for the thousand = 2^10 and million = 2^20.)

!-!-!-!

So where does this land us in the "create more wiggle room" debate?

I think it's pretty clear that there is no immediate danger if we  
don't. On the other hand, if we can save some bits without real pain,  
why not do it? Going from /48 to /56 as a general recommendation  
would be one way to do that. Another way would be to keep the /48 for  
people who want it, but move the /64 to /60. It's practically  
impossible to utilize /128s in IPv6 (it can be done but it's just too  
painful and awkward). So:

Now:      /64 or /48
/56 idea: /64 or /56
/60 idea: /60 or /48

Giving everyone who needs address space a /60 rather than a /64 has  
the advantage that there is always room for a router. If my cell  
phone gets a /64, that's nice, but it means the phone has to bridge  
or proxy ND or some such. With a /60 I can have a subnet of my own  
for the bluetooth link, and another for the GPRS/UMTS link.

Obviously this will increase the address consumption for people who  
would otherwise have gotten a /64, but even if there are many of  
those, that doesn't add up too badly. However, 95% of the people who  
would have gotten a /48 and 99% of the people who would have taken a / 
56 would also be happy with a /60, and this would save a lot of  
address space.

I also believe /60 vs /48 will make ISPs happier, as they're used to  
making SOHO/BigCu$tomer distinctions today and /60 vs /48 would  
pretty naturally fall into this.

However, I stronly believe that EVERYONE who wants one and has an ISP  
who is reasonable should get a /48 no questions asked for the exact  
reasons that we have the "let them eat /48s" rule today.

I would also suggest that all individual /48s would be registered in  
RIR databases.