[ipv6-wg at ripe.net] What is a site?

On 6-mei-2005, at 10:44, @UUNET SE Ip wrote:

> Following the discussion about /48 boundaries I'd like a better  
> definition of what a site is.

This has been discussed in the IETF many times but there was never a  
clear answer...

> My definition of an end-user site is the office where we (MCI/ 
> UUNET) install a circuit. This could be a large office or a small  
> bransch office or anything in between.
> Each office is handled separately and they request IPv4 addresses  
> per office. Adopting this to IPv6 it would mean that each office  
> would get a /48. This is too much for many of them.
> Approx. 80-90% of our sites request 32 IP-addresses or less and  
> most likely only subnet it 2 or 4 times if they ever subnet it.

Right.

> What I want is a clear definition of what a site is by having more  
> catagories. but I don't want a floating boundary as catagories do  
> simplyfies things.

> I also include my suggestions based on where I'm coming from :-)
> /60 for home networks (16 networks)
> /56 for enterprises (small/medium) (256 networks)
> /48 for large enterprises (65000 networks)
> /47 or more for "very large subscribers"
> /64 for mobile phones (w/ bluetooth or 802.11b)
> /128 for dialup PC

So that's 6 possible choices. If we assume that really big  
assignments will always be possible using non-standard procedures, we  
can ignore the > /48 case so that's 5 choices.

The /128 for a dial-up system doesn't work in practice. In IPv4, you  
can get an IP address during PPP negotiations. In IPv6, this isn't  
possible. So you either need to run DHCPv6 or stateless  
autoconfiguration over the PPP link. Both require a subnet of some  
sort. So assuming we don't want to mess around with < /64 subnets / 
128s are out and we're at 4 choices:

/64
/60
/56
/48

The /64 fulfills an obvious need: instances where only a single  
subnet is needed. However, I'm not sure this happens as often as  
people think. The idea behind a subnet is that you can have more than  
one device in it. The way dial-up works today, you get a single IPv4  
address. If we turn this into a subnet for IPv6, this doesn't make it  
possible to add more devices, as the subnet is used between the ISP  
router and the system connected to the ISP link. You really need an  
address for the ISP link and _then_ a subnet for ethernet/wifi/ 
bluetooth so more devices can share the link.

(Jordi seems to want to give out subnets to (more or less) individual  
systems. I think that's a mistake. The trend the past decade has been  
to move away from different physical subnets. Having different  
logical subnets means management, and most networks are going to be  
unmanaged so that won't work. I also don't see the benefit.)

The /48 also fulfills a need: large networks such as universities,  
hospitals, enterprises with different locations that are  
interconnected over private networks and so on.

Now the question is: what are the users for a /56 or /60?

My opinion:

The /60 is very suitable for simple SOHO networks with a single  
router and no requirement for long-term stable addresses. With DHCPv6  
prefix delegation such a router can obtain such a prefix from an ISP  
dynamically, so there wouldn't be any reason for manual setup on the  
customer side. (When implemented right renumbering can be completely  
transparent here.) A /60 is more than enough for a handful of  
subnets, such as the situation where there are different networks for  
wifi/ethernet or private/dmz or ethernet/ieee1394 (Windows XP seems  
to be able to bridge between the two, though) or a combination.

There are obviously some limitations. While a /60 allows for some  
subnetting, you really can't do dynamic prefix delegation with a high  
success rate as soon as a second router enters the picture. So this  
setup isn't suitable for serious subnetting. However, note that  
today, SOHO users DO NOT subnet. Most SOHO gateways can't even act as  
real routers! There is no evidence that the majority of all SOHO  
users needs more than two to four subnets within the forseeable future.

I assert that anyone who needs more than 10 subnets has a good chance  
of needing more than 256 at some point as well, and barring the  
creation of new technology, managing these subnets must be done  
manually so having to renumber because the number of subnets is too  
small will be rather painful. So giving people 256 subnets will give  
them the opportunity to shoot themselves in the foot by using up 250  
of them and then having to renumber.

(Since all we're doing here is come up with delegation guidelines  
that aren't set into stone or even code, we don't have to be careful  
about allowing for future developments either: when technologies that  
require more subnets become available, we can simply revisit these  
guidelines.)

So:

- forget /128 as it can't be done in practice
- try to move away from /64 as it isn't very useful
- give out a /60 to SOHO users with a single router and no special  
requirements, these prefixes may be (semi-)dynamic if required or  
desired
- give out a /48 to anyone who asks for it, these prefixes should be  
static if at all possible

Giving everyone who "needs" a /64 a /60 doesn't lead to significant  
address depletion. Even if we assume that all 10 billion Earthlings  
(this will be the peak at around 2050 as per current population  
projections) use 10 "large" and 100 "small" networks, this means:

100 billion large ~= 37 bits * .8 HD = 46 bits
1 trillion small ~= 40 bits * .8 HD = 50 bits

So even with a /60 the "small" networks only use up a /10 while the  
"large" networks would use up a /2 for /48.

Also, we should definately not skimp on giving /48s to people who  
want them, even if we think that they don't have a good reason for  
wanting them: even without any action we can (just about) accommodate  
10 of those each for 10 billion people. Not giving them to people who  
_don't_ ask for them should give us more than enough breathing room.

Final note: please let's leave the 64 interface identifier alone. Not  
only is this very hard to change even with today's limited  
deployment, but also this is our insurance for when things get really  
tough. Slicing and dicing /64 is also best done per-site, as it isn't  
visible globally.