[ipv6-wg@ripe.net] What is a site?
Hi. Following the discussion about /48 boundaries I'd like a better definition of what a site is. 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. Furthermore we never get a complete network design for all branch offices if the customer is transnational or even national so we can't really assign a /48 to the customer for him to subnet among his offices. We can of course change our procedures to accomomodate thisbut this will make things a lot more difficult for us as a LIR and also the customer. We can't decide how many addresses to assign to a customer based on size or revenue. 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 Please note that I'm not a routing expert nor am I a experienced in the complete IPv6 concept with mobil users and consumers goods etc. My main area is IP-address administration. I administrate IP-networks for MCI/UUNET in almost all of Europe except DE, AT and CH. I haven't read the RFC's related to this so my mind is wide open ;-) Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley@se.mci.com <mailto:patrick.arkley@se.mci.com> Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-initial-call@se.mci.com <mailto:emea-ip-vpn-initial-call@se.mci.com> Registry: +46 (0)8 5661 7454 or registry@se.uu.net <mailto:registry@se.uu.net> <mailto:registry@se.uu.net> IP-team: +46 (0)8 5661 7629 or ip@se.uu.net <mailto:ip@se.uu.net>
[please don't post in HTML] On Fri, 2005-05-06 at 09:44 +0100, @UUNET SE Ip wrote:
Hi.
Following the discussion about /48 boundaries I'd like a better definition of what a site is.
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.
This is the best way to target the 'what is a site'. Another way to approach it is saying that a site is a different site when it crosses an administrative border, aka the persons(s) operating that network is not equal to the other persons.
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.
At the moment that would indeed be way too much, but maybe in the future when every lightbulb gets an IP address and not forgetting that all the coffee and beertaps get one too ("Dear <beerprovider>, I ran out of beer, resupply me"), then it will become easier to fill it up. Then again, a /48 is 65535 /64's. This thus means that a /48 has 65535 separate L2 networks in that site. Currently not thinkable indeed, but it does also size a small site to a very large one and accomodates all.
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.
The question to ask here is, are they using those 32 IP's for servers and NAT the rest or do they use a firewall and give every box a public IP. If they are doing the latter it is not a hard guess how small these sites are :)
Furthermore we never get a complete network design for all branch offices if the customer is transnational or even national so we can't really assign a /48 to the customer for him to subnet among his offices. We can of course change our procedures to accomomodate thisbut this will make things a lot more difficult for us as a LIR and also the customer.
They are an endsite, you can easily guess they have most likely more than one network, thus you as a LIR give them a /48. No further thinking about it. Greets, Jeroen
In your previous mail you wrote: I also include my suggestions based on where I'm coming from :-) /60 for home networks (16 networks) => there are two reasons to use subnetting: - organization: this is in fact easy because stable/predictable and always handled by the manager - uncompatible links (like 802.11 and 1394): this will happen for home networking which should be handled automatically. With a hierarchical topology, the hD ratio should be good (~.8), with a mesh topology, random allocation of SLAs give a .5 value (cf birthday proble) for the HD ratio. Today we don't know how many links we'll get at the average but IMHO it should be 10~20 so /60 is clearly too small. BTW the DHCPv6 Prefix Delegation will be very nice because it can negociate the really needed prefix length. I believe it'll save us for the home network case, which will be as I explained an hour ago the critical one because of its very large number. Regards Francis.Dupont@enst-bretagne.fr
Hi, I¹ve not been able to attend RIPE this time, neither follow the streaming, so may be I missed something (if so, please point me to any relevant document) but my point of view is that we need to be much more flexible here about what we assign to each site. I don¹t really think we need to define what is a site. We have attempted that so many times, that is clear that everyone can have their own view, and be right. The reasons why it was decided /48 had been explained several times in several foras, so I will not repeat that. Instead I want to make clear that I completely disagree with the /60 choice, and will much prefer to keep the /48 as today in RFC3177 (see also http://www.ipv6tf.org/news/newsroom.php?id=604). This provides a good balance for the existing IPv6 addressing space for so many years, in my opinion that we will not need to worry about IP and instead may be we will have a totally different protocol by then. At the same time provides a broad enough perspective for deployment of Ambient Intelligence (Ubiquitous computing or whatever you like to call it), smarthomes, etc. I think choices such as being able to have a separate subnet (/64) for every service provider in a home is very important in terms of security and privacy. Note that I call here service provider not to the ISP (access provider), but for example the freezer manufacturer or maintenance service. I want to be able to have in different VLANs, for example, the manufacturer of the freezer and the washing machine. But also want to be able to provide a separate VLAN (again is just an example of a possible way to provide a service separation) for the supermarket that provides the fish, another for the one for the meat, milk, etc. Not allocating a /48 will increase the risk for renumbering when more and more services are being deployed. This is then creating an artificial barrier, and actually is not good for the ISPs, because they can¹t easily increase and support the number of services which can be easily created with no addressing space restrictions, and that can bring NEW business to them, as they become service aggregators without increasing their management cost (but *increasing* revenues !). Of course this is also bad for the users. I really think considering this, 16 or 256 subnets is really extremely short and limiting. Regards, Jordi De: "@UUNET SE Ip" <ip@se.uu.net> Responder a: "ipv6-wg-admin@ripe.net" <ipv6-wg-admin@ripe.net> Fecha: Fri, 6 May 2005 09:44:00 +0100 Para: "'ipv6-wg@ripe.net'" <ipv6-wg@ripe.net> Asunto: [ipv6-wg@ripe.net] What is a site? Hi. Following the discussion about /48 boundaries I'd like a better definition of what a site is. 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. Furthermore we never get a complete network design for all branch offices if the customer is transnational or even national so we can't really assign a /48 to the customer for him to subnet among his offices. We can of course change our procedures to accomomodate thisbut this will make things a lot more difficult for us as a LIR and also the customer. We can't decide how many addresses to assign to a customer based on size or revenue. 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 Please note that I'm not a routing expert nor am I a experienced in the complete IPv6 concept with mobil users and consumers goods etc. My main area is IP-address administration. I administrate IP-networks for MCI/UUNET in almost all of Europe except DE, AT and CH. I haven't read the RFC's related to this so my mind is wide open ;-) Best regards Patrick Arkley Supervisor IP/DNS-team SKSC/SKRC MCI - Powered by UUNET Armégatan 38 S-171 04 Solna, Sweden Web: www.se.mci.com <http://www.se.mci.com/> Phone direct: +46 (0)8 5661 7075 Fax: +46 (0)8 5661 7236 Mobile: +46 (0)733 11 20 75 VNET: 915-7075 E-mail: patrick.arkley@se.mci.com Initial Call team [VPN]: +46 (0)8 5661 7899 or emea-ip-vpn-initial-call@se.mci.com Registry: +46 (0)8 5661 7454 or registry@se.uu.net <mailto:registry@se.uu.net> IP-team: +46 (0)8 5661 7629 or ip@se.uu.net ************************************ 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.
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.
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@muada.com> Responder a: "ipv6-wg-admin@ripe.net" <ipv6-wg-admin@ripe.net> Fecha: Fri, 6 May 2005 14:05:58 +0200 Para: "@UUNET SE Ip" <ip@se.uu.net> CC: "'ipv6-wg@ripe.net'" <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg@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.
On 6-mei-2005, at 14:41, JORDI PALET MARTINEZ wrote:
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.
Why?? What is the advantage of having the washing machine and the freezer in different subnets? You didn't have to quote my entire message, btw. I still remember what it said...
Just one more possibility of increasing privacy and security. Depending on who is the service provider, is up to the user to decide if they want to allow other service providers to access that information or not, and we should technically facilitate it, right ? If we start increasing the difficulties of making new things possible, we will end up repeating the IPv4 mistakes. The mistake here is limiting address space and subneting possibilities to be easily managed.
From both, the ISP and customer perspective, is much easier managing a flat network were everyone has /48 instead of having different "classes" of customers, because the goal is not to charge because you have or use /60 or /48, but because you use this or that bandwidth and/or this number of services, just like cable or satellite TV. You have a base service which doesn't limit you how many channels you have (technical limitations apart, of course), and you can in addition contract a set of services for your kids, sports, films, etc. But up-front, the base service doesn't limit what else you can buy !
Regards, Jordi
De: Iljitsch van Beijnum <iljitsch@muada.com> Responder a: "ipv6-wg-admin@ripe.net" <ipv6-wg-admin@ripe.net> Fecha: Fri, 6 May 2005 14:49:48 +0200 Para: <jordi.palet@consulintel.es> CC: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg@ripe.net] What is a site?
On 6-mei-2005, at 14:41, JORDI PALET MARTINEZ wrote:
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.
Why??
What is the advantage of having the washing machine and the freezer in different subnets?
You didn't have to quote my entire message, btw. I still remember what it said...
************************************ 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.
On 6-mei-2005, at 15:01, JORDI PALET MARTINEZ wrote:
Just one more possibility of increasing privacy and security.
You don't need separate subnets for that. There are security features in switches that make all traffic between hosts in the same IP subnet flow through the switch. And as I said before, this isn't going to work anyway, as having separate physical subnets for so many devices is too much to ask and logical subnets are either hard to set up or easy to get around, or both. One subnet for non-trusted stuff and a subnet for your own stuff would be better, IMO. Protecting the washer from sniffing by the fridge seems peculiar to say the least, and is better done with TLS/ IPsec anyway.
Depending on who is the service provider, is up to the user to decide if they want to allow other service providers to access that information or not, and we should technically facilitate it, right ? If we start increasing the difficulties of making new things possible, we will end up repeating the IPv4 mistakes.
If we throw away most of our address bits on stuff that doesn't need it we'll be repeating IPv4 mistakes too. :-)
The mistake here is limiting address space and subneting possibilities to be easily managed.
I think doing /60 now and changing this when it becomes necessary makes sense. We're not closing any doors by giving out /60s.
From both, the ISP and customer perspective, is much easier managing a flat network were everyone has /48 instead of having different "classes" of customers,
Yes, that's why we need to have as few classes as possible. I think saving 12 bits for 95% of al users is worth having two classes rather than 1, though.
because the goal is not to charge because you have or use /60 or /48, but because you use this or that bandwidth and/or this number of services, just like cable or satellite TV.
That's what you think, but you don't run an ISP... This is a tough business where you take the nickles where you can get them. Paying for bandwidth isn't very popular, and the whole point of the internet is that you can get your services from anywhere. And really, you don't have to quote my entire previous message, I still know what I wrote.
On Fri, 6 May 2005, JORDI PALET MARTINEZ wrote:
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).
<snip> I've been on almost all levels when it comes to use of IPv6 in practice, end-user, tunnelbroker, LAN/site provider, ISP, transit provider and I've done two mistakes since I started to use IPv6 in 99 or was it 2000... 1.) I used /127, even some /128, that was really stupid and have caused me lots of pain, /64 are the easiest way. Or even /126 for some point-to-point links. 2.) I used /64 for end-users, not even for a singel LAN did this work out, I always had to give out extra /64 for someone/something running there. So I changed to using /60 and it worked out flawless for all the typical situation, mostly end-users or LAN. not sure there is any need for defining what a site is. What I see as a more important issue are an "agreement" about other sizes than /64 and /48. I most cases are /64 too small (see above) and a /48 total waste of space. A /60 make sense now and in the next few years but I do see a need for something bigger, /56 seems to be a good choice. If you get any bigger a /48 are probably better to use anyway. -- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
Let me try to make most of my point somewhat more concisely: In programming, there are only three values: zero, one and many. What we need to do is come up with a good prefix size for networks that: - have no router - have one router - have multiple routers
Hi, | In programming, there are only three values: zero, one and many. Good point. | What we need to do is come up with a good prefix size for networks that: | | - have no router /64 | - have one router /48 | - have multiple routers /48 I am quite happy with the current practice. groet, Pim -- ---------- - - - - -+- - - - - ---------- Pim van Pelt Email: pim@ipng.nl http://www.ipng.nl/ IPv6 Deployment -----------------------------------------------
On 7-mei-2005, at 9:50, Pim van Pelt wrote:
| In programming, there are only three values: zero, one and many.
Good point.
:-)
| What we need to do is come up with a good prefix size for networks that:
| - have no router /64 | - have one router /48 | - have multiple routers /48
I am quite happy with the current practice.
Hm, I see the current situation more as /128 - /64 - /48. I agree that the last one should remain a /48. The /128 isn't workable in practice because we don't have mechanisms that can assign individual /128s like PPP IPCP in IPv4. Having /64s for networks with a router doesn't work that well because routers always have two links. Having a /48 for a very small network with one router also isn't the greatest idea ever as we may burn IPv6 addresses uncomfortably fast. See Geoff's presentation this week at the RIPE meeting: http://www.ripe.net/ripe/meetings/ripe-50/ presentations/uploads/Wednesday/huston-ipv6_roundtable_report.pdf The video may be online in an archive but I don't know where. I think the best way to solve this is move the /64 recommendation to / 60. This will use up more address space for people who would have used a /64, but it will save a lot on people who only have a single router and no subnets or just a handful, who would get a /48 in the current situation.
and the other view: On Sat, 7 May 2005, Pim van Pelt wrote:
Hi,
| In programming, there are only three values: zero, one and many. Good point.
| What we need to do is come up with a good prefix size for networks that: | | - have no router /64 /60 -> /52
| - have one router /48
see above
| - have multiple routers /48
-- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On 9-mei-2005, at 9:17, Roger Jorgensen wrote:
and the other view:
/60 -> /52
(for networks with no router and networks with one router) Giving a /52 to networks that don't have a router has the potential to burn v6 space rather quickly. (Today those networks would get a /64.) And why would a SOHO (small office, home office) or residential network with just a single router need 4096 subnets (/52) rather than 256 (/56) or 16 (/60)? If they really need that many subnets it's probably better to stick at the current /48 recommendation. Iljitsch -- Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: May 6, 22:39:15)
I think it's important we give networks fixed size prefixes to lessen the need for restructuring and renumbering when changing provider. So I would say /64, /48, /48. The ISP's who have got the /20-ish space already have planned this, I suspect. It's the ones trying to run an ISP off a /32 that haven't? On Mon, May 09, 2005 at 11:37:53AM +0200, Iljitsch van Beijnum wrote:
On 9-mei-2005, at 9:17, Roger Jorgensen wrote:
and the other view:
/60 -> /52
(for networks with no router and networks with one router)
Giving a /52 to networks that don't have a router has the potential to burn v6 space rather quickly. (Today those networks would get a /64.)
And why would a SOHO (small office, home office) or residential network with just a single router need 4096 subnets (/52) rather than 256 (/56) or 16 (/60)?
If they really need that many subnets it's probably better to stick at the current /48 recommendation.
Iljitsch
-- Iljitsch van Beijnum - http://www.bgpexpert.com/ (updated: May 6, 22:39:15)
-- Tim/::1
On Mon, May 09, 2005 at 11:11:30AM +0100, Tim Chown wrote:
I think it's important we give networks fixed size prefixes to lessen the need for restructuring and renumbering when changing provider.
Agreed. And this prefix size should really be on nibble boundaries (but I guess noone disagrees with that).
So I would say /64, /48, /48.
The ISP's who have got the /20-ish space already have planned this, I suspect. It's the ones trying to run an ISP off a /32 that haven't?
Even with /32 you can nicely run a typical access ISP with. You need more if you have any serious mass subscriber base, like residential DSL, 3G/GPRS etc. The large-size allocation to which I was involved with designing the addressing plan definately plans to give every customer a /48, even if no routed infrastructure is in place at the customer yet. Assign /48 and route first /64 out of it initially. If customer wants more, route the rest of the /48 to the customer. This works for hosting customers as well as any leased line access customer. Also for "dialup" like PPPoE/A DSL (RADIUS). I ponder wether it would make sense to write up an example addressing plan for a /32 standard allocation which people can use as a template... Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, On Mon, May 09, 2005 at 12:23:40PM +0200, Daniel Roesen wrote:
I ponder wether it would make sense to write up an example addressing plan for a /32 standard allocation which people can use as a template...
It would definitely be a nice thing to have. Maybe even as an official RIPE BCP document? (Which means that you don't have to host it, if you don't want, and you can get editorial support from the NCC people - which is a big plus for us non-native speakers :-) ). Gert Doering -- AP WG co-chair -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 9-mei-2005, at 12:46, Gert Doering wrote:
I ponder wether it would make sense to write up an example addressing plan for a /32 standard allocation which people can use as a template...
It would definitely be a nice thing to have.
This is what I came up with for two customers who are beginning IPv6 deployment. It works both for DSL and colocation. - assign each customer a 16-bit number (starting at 20 or so) - for each customer, use a dedicated /64 for between your/their stuff, like 2001:db8:a:<cust-id>::/64 - use the ...1 address on your end, such as 2001:db8:a:<cust-id>::1 - route a /48 to the ...2 address, such as 2001:db8:<cust-id>::/48 to 2001:db8:a:<cust-id>::2 - send router advertisements so hosts in the /64 can autoconfigure Customers can now either use just the /64 with autoconfiguration or the /48 but then they need to set up an IPv6 router. This is not as transparent as I'd like it to be, and it's also kind of wasteful because it uses up a /48 for every customer even if they're not going to use it. But I think simplicity is key here, at least at this point in time when the stuff isn't as automatic as it could be. Having a / 64 per customer is useful because that way you know which address goes with which customer. If you set up a shared /64 on a shared subnet you don't know which customer has which address.
On Mon, May 09, 2005 at 12:23:40PM +0200, Daniel Roesen wrote:
I ponder wether it would make sense to write up an example addressing plan for a /32 standard allocation which people can use as a template...
Would be a nice RIPE doc, or an informational RFC. -- Tim/::1
Hi, On Mon, May 09, 2005 at 11:11:30AM +0100, Tim Chown wrote:
I think it's important we give networks fixed size prefixes to lessen the need for restructuring and renumbering when changing provider.
So I would say /64, /48, /48.
The ISP's who have got the /20-ish space already have planned this, I suspect. It's the ones trying to run an ISP off a /32 that haven't?
The base for this discussion isn't "an ISP that has badly planned their /32", it's Geoff Houstons estimations about how long the IPv6 address space will last, given current boundary conditions (HD ratio of 0.8, and /48-per-site). People that haven't looked at the presentation: please do so, *before* entering a heated argument without all relevant background information as for *why* we are having this discussion. Geoff's slides are here: http://www.ripe.net/ripe/meetings/ripe-50/plenary-program-wednesday.html -> "A report from the ARIN XV IPv6 round table" -> http://www.ripe.net/ripe/meetings/ripe-50/presentations/ripe50-plenary-wed-i... Personally, I opt for a /128+/64+/56+/48 model, with a suffiently relaxed policy that permits /48 assignments to anything that risks being limited by 256 subnets. So typical large-scale DSL rollouts can be provisioned on an automated base with /56s, providing enough space for 99.99% of all customers ("pick another arbitrary number"). As for the /128s: I think that providing a /64 for a dialup router, negotiating unique host-IDs with incoming PPP clients and then sending RAs for the "shared" /64 down the PPP links will work fine for /128 (auto-)assignment. I'm not sure, though, whether that's fully backed by all relevant specs. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 9-mei-2005, at 12:40, Gert Doering wrote:
As for the /128s: I think that providing a /64 for a dialup router, negotiating unique host-IDs with incoming PPP clients and then sending RAs for the "shared" /64 down the PPP links will work fine for /128 (auto-)assignment. I'm not sure, though, whether that's fully backed by all relevant specs.
I don't understand what you mean here... Suppose: host1 host2 +---------------+ +--------------------+ | / |ISP dial-up box+-ppp-+customer dial-up box+---customer subnet +---------------+ +--------------------+ | \ host4 host3 So the ISP and customer boxes negotiate interface identifiers. So far so good. But if the ISP box now starts sending out RAs, how do hosts 1 - 4 know this? For this to work the customer box must be a bridge and not a router, but this negates the whole idea behind the two boxes on opposite ends of the PPP link negotiating interface identifiers... What you need is a subnet for the PPP link and _another_ subnet for the customer's other stuff. This can be done with DHCPv6 prefix delegation, I think, but not with regular RAs.
Hi, On Mon, May 09, 2005 at 12:53:52PM +0200, Iljitsch van Beijnum wrote:
On 9-mei-2005, at 12:40, Gert Doering wrote:
As for the /128s: I think that providing a /64 for a dialup router, negotiating unique host-IDs with incoming PPP clients and then sending RAs for the "shared" /64 down the PPP links will work fine for /128 (auto-)assignment. I'm not sure, though, whether that's fully backed by all relevant specs.
I don't understand what you mean here... Suppose:
host1 host2 +---------------+ +--------------------+ | / |ISP dial-up box+-ppp-+customer dial-up box+---customer subnet +---------------+ +--------------------+ | \ host4 host3
This is not the scenario where /128 would be used for. +---------------+ +---------------------+ |ISP dial-up box+-ppp-+customer dial-up HOST+ +---------------+ +---------------------+ is. For a LAN connection, using a /64 or larger is pretty much a no-brainer. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On 9-mei-2005, at 13:05, Gert Doering wrote:
host1 host2 +---------------+ +--------------------+ | / |ISP dial-up box+-ppp-+customer dial-up box+---customer subnet +---------------+ +--------------------+ | \ host4 host3
This is not the scenario where /128 would be used for.
Right, I got the /64 and /128 problems mixed up. The above shows that a /64 is problematic. :-) But how would a /128 work?
+---------------+ +---------------------+ |ISP dial-up box+-ppp-+customer dial-up HOST+ +---------------+ +---------------------+
Stateless autoconfiguration only works on /64s because it needs a 64 bit interface identifier. DHCPv6 would probably not work either, because the router and the local address need to share a subnet.
Hi, On Mon, May 09, 2005 at 01:16:48PM +0200, Iljitsch van Beijnum wrote:
This is not the scenario where /128 would be used for.
Right, I got the /64 and /128 problems mixed up.
The above shows that a /64 is problematic. :-)
Only if you assume numbered PPP links. Which is no way mandatory (nor useful towards single-LAN customers).
But how would a /128 work?
+---------------+ +---------------------+ |ISP dial-up box+-ppp-+customer dial-up HOST+ +---------------+ +---------------------+
Stateless autoconfiguration only works on /64s because it needs a 64 bit interface identifier.
So? Please re-read what I wrote. IPv6CP negotiates a host-ID - if the "ISP dial-up box" makes sure that all customer host IDs connecting to it are unique, you have unique interface identifiers. Then send the same (!) /64 RA on all links. Each host will assign itself a unique IP address, and send packets for all other addresses in the /64 towards the ISP (remember: this is a point-to-point link, there is no other way to send it to). The ISP router needs a bit more brains, but not very much so. (This is conceptually not overly different from the way IPv4 DHCP works on DSL lines in some bridged-mode deployments today - all DSL lines share a "virtual" bridged /24 or similar, so you don't need a /30 per DSL customer) Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Mon, May 09, 2005 at 01:30:46PM +0200, Gert Doering wrote:
The above shows that a /64 is problematic. :-)
Only if you assume numbered PPP links. Which is no way mandatory (nor useful towards single-LAN customers).
Actually, it is very useful as you can monitor IP reachability of the CPE (WAN line) without having to care wether the LAN port is up&running (customer responsibility). I've seen both setups side-by side in 24/7 NOC operation and I can assure you that unnumbered LAN links suck hard if you have customers who switch off their office switch/hub every night. You never know wether there is an actual outage or just customer playing with his LAN. And you cannot even log into the CPE as the only IP address the CPE has is the LAN interface... which might be down and thus unreachable (at least in the Cisco CPE case). So overall: bad idea to run customer links unnumbered. IMHO. YMMV.
(This is conceptually not overly different from the way IPv4 DHCP works on DSL lines in some bridged-mode deployments today - all DSL lines share a "virtual" bridged /24 or similar, so you don't need a /30 per DSL customer)
Yes, and that sucks from security point of view. Technology has advanced. Why repeat the same mistakes the cable folks did? Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
In your previous mail you wrote: What you need is a subnet for the PPP link and _another_ subnet for the customer's other stuff. This can be done with DHCPv6 prefix delegation, I think, but not with regular RAs. => yes, this is exactly what is described in the Cisco white paper about DHCPv6 PD. Regards Francis.Dupont@enst-bretagne.fr
On Mon, May 09, 2005 at 12:40:37PM +0200, Gert Doering wrote:
Personally, I opt for a /128+/64+/56+/48 model, with a suffiently relaxed policy that permits /48 assignments to anything that risks being limited by 256 subnets.
So typical large-scale DSL rollouts can be provisioned on an automated base with /56s, providing enough space for 99.99% of all customers ("pick another arbitrary number").
I do agree that /56s will be enough for almost all customers. But then you will see scenarious that people outgrow the /56 and need a new /48 and renumber AND restructure their network into this new space. THIS is what "/48 for everone" is trying to prevent as much as possible. Reserving a /48 space but only assigning /56 makes no sense either. A /56 is 256 subnets only if ignoring ANY hierarchy. If you accept 2-3 levels of hierachy into the customer network, your efficiency goes down, and 8bits of subnetting starts to smell v4ish again. I could probably agree to /56 for residential access though. But definately not for non-residential access like non-miniature companies, universities etc. Do we really gain enough by going down to /56 that is worth the hassle? IMHO, changing the HD-Ratio is a better idea, with no downside I can currently see (can anyone?). Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
Hi, On Mon, May 09, 2005 at 02:10:08PM +0200, Daniel Roesen wrote:
I could probably agree to /56 for residential access though. But definately not for non-residential access like non-miniature companies, universities etc.
That's the aim.
Do we really gain enough by going down to /56 that is worth the hassle?
I'd say so. Assuming "everybody is always-on at home" (with "few" subnets there), this will be the LARGE majority of subscribers - and being able to increase that number by 256 sounds like "significant gain" to me.
IMHO, changing the HD-Ratio is a better idea, with no downside I can currently see (can anyone?).
It would be quite useful to see the efficiency of large-block-holders' network plans, to base judgment on the target HD ratio on the reasonably achievable efficiency in real-world network plans. Making the HD ratio overly tight ("0.99") would mean "destroying potential internal aggregation", and that's a bad thing to do. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Fully agree with this view. I think if we really want to go into this direction, the HD ratio modification seems a better idea. I actually have already thought long time ago that we can't compare in terms of efficiency IPv4 with IPv6, so no reason for keeping the same ratio. Regards, Jordi
De: Daniel Roesen <dr@cluenet.de> Responder a: "ipv6-wg-admin@ripe.net" <ipv6-wg-admin@ripe.net> Fecha: Mon, 9 May 2005 14:10:08 +0200 Para: <ipv6-wg@ripe.net> Asunto: [ipv6-wg@ripe.net] Re: What is a site?
On Mon, May 09, 2005 at 12:40:37PM +0200, Gert Doering wrote:
Personally, I opt for a /128+/64+/56+/48 model, with a suffiently relaxed policy that permits /48 assignments to anything that risks being limited by 256 subnets.
So typical large-scale DSL rollouts can be provisioned on an automated base with /56s, providing enough space for 99.99% of all customers ("pick another arbitrary number").
I do agree that /56s will be enough for almost all customers. But then you will see scenarious that people outgrow the /56 and need a new /48 and renumber AND restructure their network into this new space. THIS is what "/48 for everone" is trying to prevent as much as possible. Reserving a /48 space but only assigning /56 makes no sense either. A /56 is 256 subnets only if ignoring ANY hierarchy. If you accept 2-3 levels of hierachy into the customer network, your efficiency goes down, and 8bits of subnetting starts to smell v4ish again.
I could probably agree to /56 for residential access though. But definately not for non-residential access like non-miniature companies, universities etc.
Do we really gain enough by going down to /56 that is worth the hassle?
IMHO, changing the HD-Ratio is a better idea, with no downside I can currently see (can anyone?).
Best regards, Daniel
-- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
************************************ 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.
Hi, On Mon, May 09, 2005 at 02:50:11PM +0200, JORDI PALET MARTINEZ wrote:
Fully agree with this view.
I think if we really want to go into this direction, the HD ratio modification seems a better idea. I actually have already thought long time ago that we can't compare in terms of efficiency IPv4 with IPv6, so no reason for keeping the same ratio.
Why do you assume that the achievable efficiency isn't comparable? IPv6 has some bonuses ("all end-customer networks have the same size") and some drawbacks ("you need to achieve a much higher aggregation level if your internal routing system is ever going to cope with the sheer number of customer networks"), so overall efficiency "should" be similar. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi Gert, Quick though: Better aggregation, less fragmentation, bigger address blocks. I think this improves the efficiency. Moving the HD-ration seems to me more useful in terms of managing the way LIRs get their prefix, while changing the end-user prefix, is the easier way, but the most hurting one in terms of facilitating the grow of home networks (which in turn means innovation and more business for ISPs). Just look for the big allocations (/19, /20). They are fair with the today HD-ratio, but are they realistic ? I'm not asking to replace those, on the contrary, I'm happy that some people show clear deployment steps at a big scale, but what I don't think we should do now is a restriction, again, to the end users. If so, then let's go directly to NAT with IPv6 :-( On the other hand, do we really believe is a problem to have a protocol that might last for "only" 60-100 years? I don't really think so, as it will be probably replaced in 40-50 years already, because many more additional reasons (may be will not be IP at all). Regards, Jordi
De: Gert Doering <gert@space.net> Responder a: "ipv6-wg-admin@ripe.net" <ipv6-wg-admin@ripe.net> Fecha: Mon, 9 May 2005 14:55:35 +0200 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <ipv6-wg@ripe.net> Asunto: Re: [ipv6-wg@ripe.net] Re: What is a site?
Hi,
On Mon, May 09, 2005 at 02:50:11PM +0200, JORDI PALET MARTINEZ wrote:
Fully agree with this view.
I think if we really want to go into this direction, the HD ratio modification seems a better idea. I actually have already thought long time ago that we can't compare in terms of efficiency IPv4 with IPv6, so no reason for keeping the same ratio.
Why do you assume that the achievable efficiency isn't comparable?
IPv6 has some bonuses ("all end-customer networks have the same size") and some drawbacks ("you need to achieve a much higher aggregation level if your internal routing system is ever going to cope with the sheer number of customer networks"), so overall efficiency "should" be similar.
Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629)
SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
************************************ 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.
Hi, On Mon, May 09, 2005 at 07:30:48PM +0200, JORDI PALET MARTINEZ wrote:
Quick though: Better aggregation, less fragmentation, bigger address blocks. I think this improves the efficiency.
"better aggregation" is actually harmful to efficiency. How do you get 80% usage out of something that is only 55% filled, but that you need to get aggregated into a single block?
Moving the HD-ration seems to me more useful in terms of managing the way LIRs get their prefix, while changing the end-user prefix, is the easier way, but the most hurting one in terms of facilitating the grow of home networks (which in turn means innovation and more business for ISPs).
Is anybody envisioning home networks with more than 100 subnets? What are people doing there?
Just look for the big allocations (/19, /20). They are fair with the today HD-ratio, but are they realistic ? I'm not asking to replace those, on the contrary, I'm happy that some people show clear deployment steps at a big scale, but what I don't think we should do now is a restriction, again, to the end users. If so, then let's go directly to NAT with IPv6 :-(
Please be somewhat more specific why a /56 would be a "severe restriction" to an end user. Vague handwaving doesn't help us find consensus here.
On the other hand, do we really believe is a problem to have a protocol that might last for "only" 60-100 years? I don't really think so, as it will be probably replaced in 40-50 years already, because many more additional reasons (may be will not be IP at all).
People never assumed IPv4 would last for 30 years... so the chance that IPv6 will stick around for a VERY long time is quite large (if it happens at all). Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Tue, 10 May 2005, Gert Doering wrote:
Moving the HD-ration seems to me more useful in terms of managing the way LIRs get their prefix, while changing the end-user prefix, is the easier way, but the most hurting one in terms of facilitating the grow of home networks (which in turn means innovation and more business for ISPs).
Is anybody envisioning home networks with more than 100 subnets? What are people doing there?
It is very obvious to me... every household has a network engineer that likes (and needs) to play with routing... ;-)))
Just look for the big allocations (/19, /20). They are fair with the today HD-ratio, but are they realistic ? I'm not asking to replace those, on the contrary, I'm happy that some people show clear deployment steps at a big scale, but what I don't think we should do now is a restriction, again, to the end users. If so, then let's go directly to NAT with IPv6 :-(
Please be somewhat more specific why a /56 would be a "severe restriction" to an end user. Vague handwaving doesn't help us find consensus here.
I've already expressed that the current /48 is a restriction -- i would be more in favour of allowing LIRs to assing /56s, BUT allowing end-users to grow upto /48s without any questions asked. :-)
On the other hand, do we really believe is a problem to have a protocol that might last for "only" 60-100 years? I don't really think so, as it will be probably replaced in 40-50 years already, because many more additional reasons (may be will not be IP at all).
People never assumed IPv4 would last for 30 years... so the chance that IPv6 will stick around for a VERY long time is quite large (if it happens at all).
IPv6 is already deployed in a very small subset of the public IPv4 Internet's nodes. Really, i'm a bit more concerned now about seeing that subset grow... But if IPv6's time span starts to be limited, i would rather work on IPv-whatever-next deployment :-) (my 2 cents and a swedish-half-crown...) Regards, ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (150665/657), naming (millions) and... people!"
Hi, On Tue, May 10, 2005 at 01:07:11PM +0100, Carlos Friacas wrote:
Is anybody envisioning home networks with more than 100 subnets? What are people doing there?
It is very obvious to me... every household has a network engineer that likes (and needs) to play with routing... ;-)))
Are you the *typical* end customer...? Neither you nor me are (and I do well with about 4-5 network segments at home right now). But as I can see so far, nobody is aiming for a "no more /48s!!" policy, we're just discussiong potentially smaller assignments for the SOHO market. [..]
I've already expressed that the current /48 is a restriction -- i would be more in favour of allowing LIRs to assing /56s, BUT allowing end-users to grow upto /48s without any questions asked. :-)
I agree with that. Getting a /48 instead of "the default size" should be fairly easy. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
On Tue, 10 May 2005, Gert Doering wrote:
Hi,
On Tue, May 10, 2005 at 01:07:11PM +0100, Carlos Friacas wrote:
Is anybody envisioning home networks with more than 100 subnets? What are people doing there?
It is very obvious to me... every household has a network engineer that likes (and needs) to play with routing... ;-)))
Are you the *typical* end customer...? Neither you nor me are (and I do well with about 4-5 network segments at home right now).
But as I can see so far, nobody is aiming for a "no more /48s!!" policy, we're just discussiong potentially smaller assignments for the SOHO market.
Yes, i know, i was just being ironnical. :-) And that was precisely my point... Almost-unmanaged network are hard to foresee using more than a handfull of subnets...
[..]
I've already expressed that the current /48 is a restriction -- i would be more in favour of allowing LIRs to assing /56s, BUT allowing end-users to grow upto /48s without any questions asked. :-)
I agree with that. Getting a /48 instead of "the default size" should be fairly easy.
Yep. But should we read the RFC3177 "recommendation" as policy, and just stick with the /48 assignments only? I also didnt get the renumbering issue... renumbering from a /56 to a /48 should be painless... and the "BUT" above should prevent that someone has to renumber from a /48 to a /56... ;-) Regards, ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (150665/657), naming (millions) and... people!"
Hi, On Tue, May 10, 2005 at 01:21:52PM +0100, Carlos Friacas wrote:
I agree with that. Getting a /48 instead of "the default size" should be fairly easy.
Yep. But should we read the RFC3177 "recommendation" as policy, and just stick with the /48 assignments only?
That's what this discussion is about: do we want to change RFC3177 (and thus, the RIPE IPv6 assignment guidelines) to recommend something else?
I also didnt get the renumbering issue... renumbering from a /56 to a /48 should be painless... and the "BUT" above should prevent that someone has to renumber from a /48 to a /56... ;-)
Yep. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 71007 (66629) SpaceNet AG Mail: netmaster@Space.Net Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234
Hi, On 10 May, Gert Doering wrote: | Hi, | | On Tue, May 10, 2005 at 01:21:52PM +0100, Carlos Friacas wrote: | > >I agree with that. Getting a /48 instead of "the default size" should be | > >fairly easy. | > | > Yep. But should we read the RFC3177 "recommendation" as policy, and | > just stick with the /48 assignments only? | | That's what this discussion is about: do we want to change RFC3177 (and | thus, the RIPE IPv6 assignment guidelines) to recommend something else? ==> Here is my humble contribution to this debate. I guess that the goal should not be to replace RFC3177 by something completely different but rather by something with fewer constraints. We can indeed play on 3 rules : - adjust the HD ratio to 0.94 (I don't have the impression there's any objection to that among folks who have already expressed their opinion) - adjust the default prefix size for environment containing more that one router. The /48 default size should be reviewd but it should keep being applied to corporate networks because the number of links may potentially grow beyond 256. Conversely, there's nothing _REAL_ today that indicates that the default common soho/home network would consume more than 100 links. So respective to DHCPv6 Prefix delegation success rate, a /56 should be more than enough for the _DEFAULT CASE_. In case, a soho/home network administrator knows that they may hit that limit, the policy should allow them to get a /48 withought any bureaucratic procedures/delays. As for the problem of renumbering from a /56 to /48 for an unmanaged home network (for instance), I don't think it is really a too complex process. I hope that by the time such a problem may occurr, technical solutions for smooth renumbering will be already in place. Although, I can hear Jordi's arguments about the numerous potential uses of IPv6 in a home network, I don't believe it would apply for a significant portion of the average IPv6 users within the coming 10 years (don't ask me why 10 years and not 5 or 20 years ;-)). Thus going with a default /56 for the _DEFAULT_ case should save quite a large address space while IPv6 deployment tries to find a cruse speed... Apart from that, a /60 for a network containig only one router seems to be quite comfortable. I'm temptd to say that in that case, a reservation up to a /56 MAY be done by the ISP in order to expect the customer's network growth and ease renumebering and routing. We have been working with RFC3177 guidelines for a few years so we can afford give a try to slightly different alternative. Regards, Mohsen. | | > I also didnt get the renumbering issue... renumbering from a /56 to a /48 | > should be painless... and the "BUT" above should prevent that someone has | > to renumber from a /48 to a /56... ;-) | | Yep. | | Gert Doering | -- NetMaster | -- | Total number of prefixes smaller than registry allocations: 71007 (66629) | | SpaceNet AG Mail: netmaster@Space.Net | Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 | D- 80807 Muenchen Fax : +49-89-32356-234
On Tue, May 10, 2005 at 01:21:52PM +0100, Carlos Friacas wrote:
I also didnt get the renumbering issue... renumbering from a /56 to a /48 should be painless...
It isn't. Making smaller default assingments like /56 makes only sense if you do NOT keep a whole /48 to grow the /56 to. So essetially you'll face networks with exceed 256 subnets which then need to renumber ALL of them. There isn't supposed to be _additional_ space, only larger replacement. And a network addressing plan designed to /56 and now approaching limits _does_ look different to a /48 plan, so people _will_ have to redesign their addressing plan while renumbering the whole network from the old /56 to the new /48. This is all the hassle (even more!) of IPv4... The whole point of /48 is to _avoid_ that as much as possible. But indeed, I don't see SOHO/home networks outgrow a /56 in the foreseeable future. If technologies come up which do mandate/foster high amounts of subnetting even in the SOHO/home space, the default SOHO/home assignment size can be raised again - which will introduce some pain, but not that much. Giving /56s to corporate networks is IMHO just plain wrong and "IPv6 not understood". And don't forget, upgrading your assignment from /56 to /48 WILL have a price tag attached to it. ISPs _still_ try to squeeze out revenue from artificial address space scarcity. As Tony pointed out, the business agenda of "product differentiation" is a/the big driver of this move. Providing better service than the competition is just too oldschool it seems. :-) Best regards, Daniel -- CLUE-RIPE -- Jabber: dr@cluenet.de -- dr@IRCnet -- PGP: 0xA85C8AA0
On Tue, May 10, 2005 at 04:24:47PM +0200, Daniel Roesen wrote:
And don't forget, upgrading your assignment from /56 to /48 WILL have a price tag attached to it. ISPs _still_ try to squeeze out revenue from artificial address space scarcity. As Tony pointed out, the business agenda of "product differentiation" is a/the big driver of this move.
Indeed.
Providing better service than the competition is just too oldschool it seems. :-)
;) -- Tim/::1
As I see it, this is probably the cleanest sumary of the entire discussion so far. And the one that make most sense to. On Tue, 10 May 2005, Daniel Roesen wrote:
On Tue, May 10, 2005 at 01:21:52PM +0100, Carlos Friacas wrote:
I also didnt get the renumbering issue... renumbering from a /56 to a /48 should be painless...
It isn't. Making smaller default assingments like /56 makes only sense if you do NOT keep a whole /48 to grow the /56 to. So essetially you'll face networks with exceed 256 subnets which then need to renumber ALL of them. There isn't supposed to be _additional_ space, only larger replacement.
And a network addressing plan designed to /56 and now approaching limits _does_ look different to a /48 plan, so people _will_ have to redesign their addressing plan while renumbering the whole network from the old /56 to the new /48. This is all the hassle (even more!) of IPv4... The whole point of /48 is to _avoid_ that as much as possible.
But indeed, I don't see SOHO/home networks outgrow a /56 in the foreseeable future. If technologies come up which do mandate/foster high amounts of subnetting even in the SOHO/home space, the default SOHO/home assignment size can be raised again - which will introduce some pain, but not that much.
Giving /56s to corporate networks is IMHO just plain wrong and "IPv6 not understood".
And don't forget, upgrading your assignment from /56 to /48 WILL have a price tag attached to it. ISPs _still_ try to squeeze out revenue from artificial address space scarcity. As Tony pointed out, the business agenda of "product differentiation" is a/the big driver of this move.
Providing better service than the competition is just too oldschool it seems. :-)
Best regards, Daniel
-- ------------------------------ Roger Jorgensen | rogerj@stud.cs.uit.no | - IPv6 is The Key! http://www.jorgensen.no | roger@jorgensen.no -------------------------------------------------------
On 10-mei-2005, at 14:21, Carlos Friacas wrote:
And that was precisely my point... Almost-unmanaged network are hard to foresee using more than a handfull of subnets...
Right. So there is currently no need to have more than a /60 for those networks.
I agree with that. Getting a /48 instead of "the default size" should be fairly easy.
Not just "fairly" but "very", even.
Yep. But should we read the RFC3177 "recommendation" as policy, and just stick with the /48 assignments only?
Obviously if "we" (and I'm not just talking about the RIPE community here) decide that something different is in order, there will be a replacement for RFC 3177.
I also didnt get the renumbering issue... renumbering from a /56 to a /48 should be painless... and the "BUT" above should prevent that someone has to renumber from a /48 to a /56... ;-)
The trouble is that when you start running out of a /56 so you need to move to a /48, you already have a significant amount of configuration going. It would be nice if we could renumber routers automatically, but as far as I know, that's not really possible now, and not likely to be possible in the forseeable future. So moving from a /56 to a /48 would be a lot of work. This means that giving out /56s is a poor choice, as it's not enough for some networks, but too much (if having too much address space is possible) for many. It's much easier to have to make the decision "tiny" or "not tiny" rather than "tiny to medium sized" or "bigger than medium sized / bigger than medium sized in the future".
Hi all, On Mon, 9 May 2005, JORDI PALET MARTINEZ wrote:
Hi Gert,
Quick though: Better aggregation, less fragmentation, bigger address blocks. I think this improves the efficiency.
Moving the HD-ration seems to me more useful in terms of managing the way LIRs get their prefix, while changing the end-user prefix, is the easier way, but the most hurting one in terms of facilitating the grow of home networks (which in turn means innovation and more business for ISPs).
Just look for the big allocations (/19, /20). They are fair with the today HD-ratio, but are they realistic ? I'm not asking to replace those, on the contrary, I'm happy that some people show clear deployment steps at a big scale, but what I don't think we should do now is a restriction,
the RFC3177 restriction (today) says my LIR "shouldn't" assign a /60 or a /56 to a small-but-not-a-single-subnet customer... from my view, there is a strong restriction here...
again, to the end users. If so, then let's go directly to NAT with IPv6 :-(
nooooooo, please :-)
On the other hand, do we really believe is a problem to have a protocol that might last for "only" 60-100 years?
yes. if we envision its replacement there would be no point in trying to deploy it realistically...
I don't really think so, as it will be probably replaced in 40-50 years already, because many more additional reasons (may be will not be IP at all).
would like to know which reasons... Regards, ./Carlos -------------- http://www.ip6.fccn.pt/nativeRCTS2.html Wide Area Network (WAN) Workgroup, CMF8-RIPE, CF596-ARIN FCCN - Fundacao para a Computacao Cientifica Nacional http://www.fccn.pt "Internet is just routes (150665/657), naming (millions) and... people!"
On Mon, 9 May 2005, Daniel Roesen wrote:
I do agree that /56s will be enough for almost all customers. But then you will see scenarious that people outgrow the /56 and need a new /48 and renumber AND restructure their network into this new space. THIS is what "/48 for everone" is trying to prevent as much as possible. Reserving a /48 space but only assigning /56 makes no sense either. A /56 is 256 subnets only if ignoring ANY hierarchy. If you accept 2-3 levels of hierachy into the customer network, your efficiency goes down, and 8bits of subnetting starts to smell v4ish again.
I could probably agree to /56 for residential access though. But definately not for non-residential access like non-miniature companies, universities etc.
Do we really gain enough by going down to /56 that is worth the hassle?
IMHO, changing the HD-Ratio is a better idea, with no downside I can currently see (can anyone?).
I agree with Daniel here (wow..:), though I'd prefer to keep our finger out of /48 boundary even for residential use. I guess most people failed to register the statements in the presentation like: "This is a highly speculative exercise." "__If__ this is looking slightly uncomfortable..." etc. If the goal was to allow the more (broadband) ISPs to use the default allocation sizes, using something like /56 might be worth considering. But this doesn't seem to be the goal. It seems to me that beyond a certain point, 1) HD ratio needs to tightened (that is, if you have 10M customers, you shouldn't really need 1000M /48's.), and/or 2) The more is requested, the more the ISPs have to show evidence of their current usage base, i.e., a startup ISP in China couldn't claim 100M customer base in 2 years. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
In your previous mail you wrote: Let me try to make most of my point somewhat more concisely: In programming, there are only three values: zero, one and many. What we need to do is come up with a good prefix size for networks that: - have no router => /64 for the connection link itself. - have one router => it depends on the number of links behind but it seems that /60 is right. - have multiple routers => if the topology is complex (HD ratio ~ 0.5) and the number of links ~ 10 then a /56 is right. IMHO the best is to authorize a /56 in all cases (i.e., move from /48 to /56 for common home networks) and leave DHCPv6 PD negociates the right value, "up to" /56. Regards Francis.Dupont@enst-bretagne.fr
participants (13)
-
＠UUNET SE Ip -
Carlos Friacas -
Daniel Roesen -
Francis Dupont -
Gert Doering -
Iljitsch van Beijnum -
Jeroen Massar -
JORDI PALET MARTINEZ -
Mohsen Souissi -
Pekka Savola -
Pim van Pelt -
Roger Jorgensen -
Tim Chown