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

Hi,

Just one clarification. I was only trying to make an example, probably not
the best one. The idea is that a subnet is not used for a single device, of
course, but for a single set of them which are related, for example in terms
of who is accessing that network. So the clarified example will be: If the
same service provider (probably the manufacturer but it may be also a third
party company, even the ISP itself) is responsible for keeping the
maintenance of the freezer and the washing machine and the dish washing
machine, they could be allocated in a single subnet, but a different one
that the supermarket that will refill my beverage in the freezer, and a
different one that will refill the fish.

Regarding your view of allowing a /60, I think if we want to go into that
direction is better to seek for a /56 or even better, a /52. But I'm still
convinced that we should stay with /48. Today SOHOs doesn't subnet because
the need has not come thanks, unfortunately to NAT, which avoided the
creation of innovation around Internet (those new services and applications
that will come with IPv6 and end-to-end restoration).

Regards,
Jordi




> De: Iljitsch van Beijnum <iljitsch at muada.com>
> Responder a: "ipv6-wg-admin at ripe.net" <ipv6-wg-admin at ripe.net>
> Fecha: Fri, 6 May 2005 14:05:58 +0200
> Para: "@UUNET SE Ip" <ip at se.uu.net>
> CC: "'ipv6-wg at ripe.net'" <ipv6-wg at ripe.net>
> Asunto: Re: [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.
> 




************************************
Barcelona 2005 Global IPv6 Summit
Registration open. Information available at:
http://www.ipv6-es.com

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.