[address-policy-wg] Re: IPv6 addresses really are scarce after all

[CCing this to ARIN PPML and RIPE address-policy, but Reply-To:  
ietf at ietf.org, when replying, please pick just one list. Also, please  
read Thomas' entire original message at http://www1.ietf.org/mail- 
archive/web/ietf/current/msg47431.html ]

[You may want to skip ahead to my point about the HD ratio at the end.]

On 24-aug-2007, at 23:34, Thomas Narten wrote:

> The fact is, the /48 boundary is _NOT_ architectural,

True. However, this doesn't mean that /48 is completely arbitrary,  
either. /64 for subnets is based on the availability of 64-bit unique  
numbers in the form of MAC addresses that make it possible to have  
stateless autoconfiguration where a system always has the same  
address without the need for explicit coordination or configuration.

People often attribute the fact that IPv4 addresses didn't run out in  
2005 as predicted in the early 1990s to NAT, but there is another  
technique that is even more popular than NAT that also played in  
important rule: ethernet switching. Back when IPv6 was designed, it  
was common to have a substantial number of different subnets for  
different purposes to avoid having unnecessary large "collision  
domains". These days, you can easily throw hundreds, if not thousands  
of systems in a single subnet without performance penalties so most  
networks don't need all that many subnets. So the original goal of  
providing something a number of subnets that is large enough for  
99.9% of all IPv6 users arguably required a /48 (65536 subnets). With  
2000::/3 given out for global unicast purposes, that allows 2^45 / 
48s, which should be more than enough to give all inhabitants of the  
planet their own /48 with a few to spare.

So a /48 is both big enough for pretty much everyone, and small  
enough that we can give one to pretty much everyone. Last but not  
least, it's very useful to have a standard size, because then, if you  
go from one ISP to another, you're never in the situation where you  
need to renumber into a smaller block of address space, which is  
much, much harder than just replacing the first X bits of the address  
(where X is presumably 48). This was especially true in the presence  
of DNAME and bitlabels in the DNS. For those of you that don't know  
about this, it's rather complex and now obsolete, but around the turn  
of the century, this was a hot new mechanism to support easy  
renumbering in the DNS. (Read about it here http://www.apress.com/ 
book/supplementDownload.html?bID=10026&sID=3120 but don't say I  
didn't warn you.)

So /48 was certainly "a good idea at the time". If we were doing all  
of this today, we could probably go a bit lower than 65536 subnets,  
such as 4096, but not THAT much lower. For instance, 256 subnets (/ 
56) is still a very large number, so it assumes that people will be  
subnetting, but I'm not confident that it's enough for 99.9% of all  
future IPv6 users.

Another issue is what we give to people who aren't going to build a  
network with subnets. The old recommendation was a /64 (= 1 subnet)  
for users who don't need to subnet. But unlike with IPv4, where end- 
users often get a single IP address and turn that into a subnet with  
NAT, with IPv6 you pretty much always need TWO subnets, although one  
of them can be shared. For instance, if I want to connect a bunch of  
computers in my home to my DSL line with IPv6, I need a /64 on my  
wifi network at home, but it's not really possible to use addresses  
from that same /64 between my ADSL modem and the DSL concentrator at  
the central office. As an ISP, I could set up one /64 to talk to all  
the DSL modems connected to a central office and then delegate a /64  
to each user, but this is problematic for technical reasons  
(broadcasts/mulsticast vs NBMA) and control issues (which user does  
traffic from an address in that shared /64 come from).

So if I were designing an ISP network, I would want to give at least  
two /64s or a /63 to every customer. In practice, it's much easier to  
go up a few bits and make it a /60, where I use one /64 for the SIP- 
customer link and the customer gets to use the other 15 subnets  
however they want. This way, I avoid getting support calls from  
people who want to have an extra DMZ subnet or different subnets for  
their wired and wireless networks.

Again, as an ISP, I wouldn't want to think about how many subnets  
customers are going to use when they need more than that /60. Much  
easier to simply sell them a business account and give them a /48.  
Remember, every time a simple residential customer calls the support  
number, that costs an ISP the entire profit for that customer for a  
year. Avoiding support calls is one of the highest priorities for ISPs.

> What the appropriate size of an assignment for an end site should be
> is really more of an operational issue than architectural one. If a
> site gets too little, and needs to get more later (maybe at the cost
> of renumbering) that is an operational issue. And the idea that we can
> give out "enough" address space to a site so that it doesn't have to
> renumber (ever) is pretty silly.

That doesn't mean it's impossible to pick sizes that are worse than  
others. And even though we have reverted back to simple use of the  
DNS with IPv6 where having the same address block size when going  
from ISP to ISP is less important, it's still beneficial to have as  
few block sizes as possible to that people don't have to go from big  
to small.

> The RIRs adopted the "/48 to everyone" in its initial stab at IPv6
> policy back in 2002. Even at that time, there was much screaming and
> gnashing of teeth from the operator community saying "wasteful",
> "excessive", "really stupid", etc.

The wastefulness occurred when the IPv6 address size was set to 128  
bits. This means that every IPv6 packet has to carry 32 bytes of  
address information. Now that we've eaten that cost, there is little  
use in trying to _use_ fewer of those bits that we're paying for with  
every packet.

I can see how "/48 for everyone" could be considered too much  
(although 35184 billion of those aren't going to be used up any time  
soon) but can we at least retain "/48 for everyone who asks for one"?

>       If I assign 4M /48's of IPv6 (one to each cable modem on my
>       network), according to the HD-ratio I am justified to obtain
>       something around a /20 of IPv6 addresses.  In other words, I am
>       justified in getting 268M /48's even though I am only using  
> 4M of
>       them.  That would be enough for me to assign at least two for
>       every household in the US (not just the 19M on my network).

Yes, this is a problem that the current policies, including the  
unofficial ones (for instance that ARIN reserves a /29 when an ISP  
gets a /32) don't address.

Suppose a large ISP that operates across the US or Europe gets that / 
20. So how are they going to announce that, as a single /20? I don't  
think so. They're going to deaggregate. And they can easily do that,  
because their block is much larger than the minimum /32 block that  
people are presumably going to be filtering on.

In the degenerative case, which we can already see in IPv4, ISPs  
simply announce whatever they have as the smallest possible  
announcement. So that ISP that needs 4 million /48s = 64 /32s but  
gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs  
thought they would need to aggregate, while if the RIRs assumed that  
they wouldn't aggregate, they would have gotten the space in the form  
of a number of much smaller blocks and they would only have been able  
to announce 100 or so /32s.

A much more appropriate policy would be to start with a certain  
minimum allocation, and then whenever someone comes back for more,  
give them a new block that is 2, 4 or 8 times as big as the previous  
block until a certain maximum block size is reached. For aggregation  
purposes, there is no benefit in having blocks larger than a /24,  
because by the time that a significant portion of the the IPv6 space  
ends up in the routing tables, having 2^24 routes won't be a problem.

> The
> community feedback was that LIRs were smart enough to make reasonable
> assignments based on actual customer need.

The trouble is that even more so than at the IETF, the RIR community  
as seen from the policy development process is whoever happens to  
show up. This means only a small part of all stakeholders provide input.

> Surely, everyone will agree that
> giving a /56 to home sites is more than enough space for the foresable
> future!

If /48 is too much for home sites then /56 is too much as well.