Re: IPv6 addresses really are scarce after all
[CCing this to ARIN PPML and RIPE address-policy, but Reply-To: ietf@ietf.org, when replying, please pick just one list. Also, please read Thomas' entire original message at http://www1.ietf.org/mail- archive/web/ietf/current/msg47431.html ] [You may want to skip ahead to my point about the HD ratio at the end.] On 24-aug-2007, at 23:34, Thomas Narten wrote:
The fact is, the /48 boundary is _NOT_ architectural,
True. However, this doesn't mean that /48 is completely arbitrary, either. /64 for subnets is based on the availability of 64-bit unique numbers in the form of MAC addresses that make it possible to have stateless autoconfiguration where a system always has the same address without the need for explicit coordination or configuration. People often attribute the fact that IPv4 addresses didn't run out in 2005 as predicted in the early 1990s to NAT, but there is another technique that is even more popular than NAT that also played in important rule: ethernet switching. Back when IPv6 was designed, it was common to have a substantial number of different subnets for different purposes to avoid having unnecessary large "collision domains". These days, you can easily throw hundreds, if not thousands of systems in a single subnet without performance penalties so most networks don't need all that many subnets. So the original goal of providing something a number of subnets that is large enough for 99.9% of all IPv6 users arguably required a /48 (65536 subnets). With 2000::/3 given out for global unicast purposes, that allows 2^45 / 48s, which should be more than enough to give all inhabitants of the planet their own /48 with a few to spare. So a /48 is both big enough for pretty much everyone, and small enough that we can give one to pretty much everyone. Last but not least, it's very useful to have a standard size, because then, if you go from one ISP to another, you're never in the situation where you need to renumber into a smaller block of address space, which is much, much harder than just replacing the first X bits of the address (where X is presumably 48). This was especially true in the presence of DNAME and bitlabels in the DNS. For those of you that don't know about this, it's rather complex and now obsolete, but around the turn of the century, this was a hot new mechanism to support easy renumbering in the DNS. (Read about it here http://www.apress.com/ book/supplementDownload.html?bID=10026&sID=3120 but don't say I didn't warn you.) So /48 was certainly "a good idea at the time". If we were doing all of this today, we could probably go a bit lower than 65536 subnets, such as 4096, but not THAT much lower. For instance, 256 subnets (/ 56) is still a very large number, so it assumes that people will be subnetting, but I'm not confident that it's enough for 99.9% of all future IPv6 users. Another issue is what we give to people who aren't going to build a network with subnets. The old recommendation was a /64 (= 1 subnet) for users who don't need to subnet. But unlike with IPv4, where end- users often get a single IP address and turn that into a subnet with NAT, with IPv6 you pretty much always need TWO subnets, although one of them can be shared. For instance, if I want to connect a bunch of computers in my home to my DSL line with IPv6, I need a /64 on my wifi network at home, but it's not really possible to use addresses from that same /64 between my ADSL modem and the DSL concentrator at the central office. As an ISP, I could set up one /64 to talk to all the DSL modems connected to a central office and then delegate a /64 to each user, but this is problematic for technical reasons (broadcasts/mulsticast vs NBMA) and control issues (which user does traffic from an address in that shared /64 come from). So if I were designing an ISP network, I would want to give at least two /64s or a /63 to every customer. In practice, it's much easier to go up a few bits and make it a /60, where I use one /64 for the SIP- customer link and the customer gets to use the other 15 subnets however they want. This way, I avoid getting support calls from people who want to have an extra DMZ subnet or different subnets for their wired and wireless networks. Again, as an ISP, I wouldn't want to think about how many subnets customers are going to use when they need more than that /60. Much easier to simply sell them a business account and give them a /48. Remember, every time a simple residential customer calls the support number, that costs an ISP the entire profit for that customer for a year. Avoiding support calls is one of the highest priorities for ISPs.
What the appropriate size of an assignment for an end site should be is really more of an operational issue than architectural one. If a site gets too little, and needs to get more later (maybe at the cost of renumbering) that is an operational issue. And the idea that we can give out "enough" address space to a site so that it doesn't have to renumber (ever) is pretty silly.
That doesn't mean it's impossible to pick sizes that are worse than others. And even though we have reverted back to simple use of the DNS with IPv6 where having the same address block size when going from ISP to ISP is less important, it's still beneficial to have as few block sizes as possible to that people don't have to go from big to small.
The RIRs adopted the "/48 to everyone" in its initial stab at IPv6 policy back in 2002. Even at that time, there was much screaming and gnashing of teeth from the operator community saying "wasteful", "excessive", "really stupid", etc.
The wastefulness occurred when the IPv6 address size was set to 128 bits. This means that every IPv6 packet has to carry 32 bytes of address information. Now that we've eaten that cost, there is little use in trying to _use_ fewer of those bits that we're paying for with every packet. I can see how "/48 for everyone" could be considered too much (although 35184 billion of those aren't going to be used up any time soon) but can we at least retain "/48 for everyone who asks for one"?
If I assign 4M /48's of IPv6 (one to each cable modem on my network), according to the HD-ratio I am justified to obtain something around a /20 of IPv6 addresses. In other words, I am justified in getting 268M /48's even though I am only using 4M of them. That would be enough for me to assign at least two for every household in the US (not just the 19M on my network).
Yes, this is a problem that the current policies, including the unofficial ones (for instance that ARIN reserves a /29 when an ISP gets a /32) don't address. Suppose a large ISP that operates across the US or Europe gets that / 20. So how are they going to announce that, as a single /20? I don't think so. They're going to deaggregate. And they can easily do that, because their block is much larger than the minimum /32 block that people are presumably going to be filtering on. In the degenerative case, which we can already see in IPv4, ISPs simply announce whatever they have as the smallest possible announcement. So that ISP that needs 4 million /48s = 64 /32s but gets a /20 = 4096 /32s COULD advertise 4096 prefixes because the RIRs thought they would need to aggregate, while if the RIRs assumed that they wouldn't aggregate, they would have gotten the space in the form of a number of much smaller blocks and they would only have been able to announce 100 or so /32s. A much more appropriate policy would be to start with a certain minimum allocation, and then whenever someone comes back for more, give them a new block that is 2, 4 or 8 times as big as the previous block until a certain maximum block size is reached. For aggregation purposes, there is no benefit in having blocks larger than a /24, because by the time that a significant portion of the the IPv6 space ends up in the routing tables, having 2^24 routes won't be a problem.
The community feedback was that LIRs were smart enough to make reasonable assignments based on actual customer need.
The trouble is that even more so than at the IETF, the RIR community as seen from the policy development process is whoever happens to show up. This means only a small part of all stakeholders provide input.
Surely, everyone will agree that giving a /56 to home sites is more than enough space for the foresable future!
If /48 is too much for home sites then /56 is too much as well.
From an architecture point of view, I believe there are only two interesting "delegation" lengths, /48 and /64. My rationale is that there really are two kinds of networks: big and small.
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet. There are multiple trends pushing for the simple subnet. Most home networking technologies have a deeply engrained "single subnet" assumption, and will simply refuse to establish connections out of the subnet. Wireless technology is evolving towards "mesh", in which the wireless segments are bridged on demand following the vagaries of radio propagation and the movements of devices. Mesh pretty much assumes that the IP address remains unaffected by low level topology changes, which means a host will not change subnet because it just switched to a different radio. Users will keep finding it easier to deploy self forming layer 2 networks than manage the additional complexity of subnets. Of course, the technology has limit today. Subnet sizes are limited by the efficiency of the spanning tree algorithm, or by the quadratic scaling effect of multicast operation. But these limits can be pushed. The spanning tree algorithm can be replaced by something more efficient, and indeed will be as the "mesh" technology evolves. Multicast overhead can be reduced with appropriate filters. It can also be reduced if applications switch from simplistic multicast schemes to more elaborate technologies, e.g. distributed hash tables. These evolutions will be naturally driven by market demand, as homes get equipped with more and more devices, all the way to the "IPv6 light bulb". The single subnet is well served by a /64 prefix. Devices can be built in factory with unique /64 numbers. When there are privacy issues, hosts can pick random 64 bit numbers and not be really worried about collisions, at least not until there are billions of hosts in the subnet. Of course, the home may well get several /64 prefixes, for example because it is multi-homed. But there is no particular need to aggregate these prefixes. Indeed, if the goal is multi-homing, the different prefixes will come through entirely different delegation chains. If the granular level is /64, then what should the next level be? Well, as far for now, /48 makes a lot of sense. It is enough for most enterprises, allowing them to delegate /64 to each interesting subnet. I would assert that the smaller value, /56, is too small. It is not sufficient in most cases, and it also unduly increase the registration load in the registries. -- Christian Huitema
/64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume that this will be the case and overly constrain home users. In addition, part of the popularity of NAT has resulted from its allowing a consumer to simply "plug in" a new network to an existing network. But the popularity of NAT in IPv4 has also greatly limited the ability of the IPv4 network to support new applications, and increased the expense required to support others. A lot of the value add in IPv6 results from its having enough address bits that NAT is no longer necessary. But if we constrain home users to the point that they see a benefit from NATting, we will have destroyed much of the additional value of IPv6. The /48 boundary was selected to balance several competing interests - e.g. those of ISPs and registries vs. those of end-users and equipment manufacturers. There's a tremendous advantage in having nearly everyone get the same allocation size. This is not a decision that should be revisited lightly, or by a group representing only a narrow segment of those interests.
From an architecture point of view, I believe there are only two interesting "delegation" lengths, /48 and /64. My rationale is that there really are two kinds of networks: big and small.
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet.
There are multiple trends pushing for the simple subnet. Most home networking technologies have a deeply engrained "single subnet" assumption, and will simply refuse to establish connections out of the subnet. Wireless technology is evolving towards "mesh", in which the wireless segments are bridged on demand following the vagaries of radio propagation and the movements of devices. Mesh pretty much assumes that the IP address remains unaffected by low level topology changes, which means a host will not change subnet because it just switched to a different radio. Users will keep finding it easier to deploy self forming layer 2 networks than manage the additional complexity of subnets.
Of course, the technology has limit today. Subnet sizes are limited by the efficiency of the spanning tree algorithm, or by the quadratic scaling effect of multicast operation. But these limits can be pushed. The spanning tree algorithm can be replaced by something more efficient, and indeed will be as the "mesh" technology evolves. Multicast overhead can be reduced with appropriate filters. It can also be reduced if applications switch from simplistic multicast schemes to more elaborate technologies, e.g. distributed hash tables. These evolutions will be naturally driven by market demand, as homes get equipped with more and more devices, all the way to the "IPv6 light bulb".
The single subnet is well served by a /64 prefix. Devices can be built in factory with unique /64 numbers. When there are privacy issues, hosts can pick random 64 bit numbers and not be really worried about collisions, at least not until there are billions of hosts in the subnet. Of course, the home may well get several /64 prefixes, for example because it is multi-homed. But there is no particular need to aggregate these prefixes. Indeed, if the goal is multi-homing, the different prefixes will come through entirely different delegation chains.
If the granular level is /64, then what should the next level be? Well, as far for now, /48 makes a lot of sense. It is enough for most enterprises, allowing them to delegate /64 to each interesting subnet. I would assert that the smaller value, /56, is too small. It is not sufficient in most cases, and it also unduly increase the registration load in the registries.
-- Christian Huitema
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore <moore@cs.utk.edu> wrote:
/64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume that this will be the case and overly constrain home users. In addition, part of the popularity of NAT has resulted from its allowing a consumer to simply "plug in" a new network to an existing network. But the popularity of NAT in IPv4 has also greatly limited the ability of the IPv4 network to support new applications, and increased the expense required to support others. A lot of the value add in IPv6 results from its having enough address bits that NAT is no longer necessary. But if we constrain home users to the point that they see a benefit from NATting, we will have destroyed much of the additional value of IPv6.
Keith, Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses. Now that number goes down significantly --and I would agree with your assertion-- if we were still assuming the use of hardware-assigned MAC addresses to populate that space. But we largely are not. The use of NAT to expand address space in residential use of IPv4 has been largely to expand one or two addresses into around 2**16. Even those of us who run several subnets with different security policies don't often use that much space up. While we clearly could in the future, and I don't like NATs much more than you do, a /64 gives 48 bits of headroom -- over a dozen decimal orders of magnitude if my mental arithmetic is correct -- above any regularly-demonstrated current need. That is a lot of headroom, enough that the assertions above are not obviously true, at least without a lot more rationale. That doesn't mean I'm convinced that shifting the boundary is either necessary or desirable. But I don't think hyperbole helps the discussion. john
John C Klensin wrote:
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore <moore@cs.utk.edu> wrote:
/64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume that this will be the case and overly constrain home users. In addition, part of the popularity of NAT has resulted from its allowing a consumer to simply "plug in" a new network to an existing network. But the popularity of NAT in IPv4 has also greatly limited the ability of the IPv4 network to support new applications, and increased the expense required to support others. A lot of the value add in IPv6 results from its having enough address bits that NAT is no longer necessary. But if we constrain home users to the point that they see a benefit from NATting, we will have destroyed much of the additional value of IPv6.
Keith,
Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses. And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But the sheer number of addresses in a subnet or prefixes available to be assigned doesn't seem to be the limiting factor in either address block assignment or subnetting of leaf networks. Every level of delegation seems to eat a couple of address bits.
What bothers me about a /64 is not the scarcity of addresses, but the inability to subnet it. (and that, IMHO, was a poor design choice in IPv6, but I think it's rather late to revisit that choice, just like I think it's late to revisit /48.)
Now that number goes down significantly --and I would agree with your assertion-- if we were still assuming the use of hardware-assigned MAC addresses to populate that space. But we largely are not. If we changed IPv6 so that users can have subnet prefixes longer than /64, I must have missed it.
The use of NAT to expand address space in residential use of IPv4 has been largely to expand one or two addresses into around 2**16. I guess I'm of the opinion that "residential" use is highly varied, and will become more varied in the future. I don't want Internet protocol design choices to constrain what people might reasonably do in a future home or home office. I also don't think it should be assumed that "residential" prefixes will exclusively be used in residences.
Keith
--On Saturday, 25 August, 2007 13:08 -0400 Keith Moore <moore@cs.utk.edu> wrote:
John C Klensin wrote:
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore <moore@cs.utk.edu> wrote:
/64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume ... Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses.
And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But the sheer number of addresses in a subnet or prefixes available to be assigned doesn't seem to be the limiting factor in either address block assignment or subnetting of leaf networks. Every level of delegation seems to eat a couple of address bits.
Yes. Of course. Again, I'm not convinced that this is a good idea, just trying to keep the discussion focused and real.
What bothers me about a /64 is not the scarcity of addresses, but the inability to subnet it. (and that, IMHO, was a poor design choice in IPv6, but I think it's rather late to revisit that choice, just like I think it's late to revisit /48.)
This gets to one of the issues I _am_ concerned about. While I didn't call it out explicitly in my response to Thomas, I believe that, if the RIRs start saying "give out /64s unless someone can prove to your satisfaction that they need a lot of subnets" to ISPs, we have ample evidence that some, perhaps many, ISPs serving the residential market will construe "prove to our satisfaction" as "pay us a lot of extra money". If that happens, our experience with IPv4 and NATs suggests to me that it will be a _very_ short period of time before devices hit the consumer market that either do subnetting on longer-than-/64 prefixes, are set up to handle some other model of address pools, or NAT (I'd predict all three and would find the middle one interesting) along with patches to stacks that support them as needed. Since we probably won't revisit the /64 subnetting choice, those patches will be made independent of any standard or IETF advice which suggests that there may be interoperability problems if there is any opportunity for them. And _that_ is bad news. It is also news that reinforces my response to Thomas: there really are architectural issues in this sort of decision and no one I know of has chartered the RIRs to make those types of architectural decisions. john
John, It seems like we are on the same page. I'm very concerned about the potential of this change to snowball in to lots of other changes that would be undesirable, or at least highly disruptive. The /48 choice is only one of several interlocking choices that were carefully-crafted compromises, and if we change /48 then we risk revisiting all of those other choices in order to maintain that sense of balance - or worse, losing that balance. Keith
--On Saturday, 25 August, 2007 13:08 -0400 Keith Moore <moore@cs.utk.edu> wrote:
John C Klensin wrote:
--On Saturday, 25 August, 2007 12:28 -0400 Keith Moore <moore@cs.utk.edu> wrote:
/64 is too small for a home network. It might indeed turn out that it's possible to bridge several different kinds of media on a single subnet, but it's bad planning to assume
...
Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses.
And 2**45 prefixes under 2000:/3 is a _lot_ of prefixes. But the sheer number of addresses in a subnet or prefixes available to be assigned doesn't seem to be the limiting factor in either address block assignment or subnetting of leaf networks. Every level of delegation seems to eat a couple of address bits.
Yes. Of course. Again, I'm not convinced that this is a good idea, just trying to keep the discussion focused and real.
What bothers me about a /64 is not the scarcity of addresses, but the inability to subnet it. (and that, IMHO, was a poor design choice in IPv6, but I think it's rather late to revisit that choice, just like I think it's late to revisit /48.)
This gets to one of the issues I _am_ concerned about. While I didn't call it out explicitly in my response to Thomas, I believe that, if the RIRs start saying "give out /64s unless someone can prove to your satisfaction that they need a lot of subnets" to ISPs, we have ample evidence that some, perhaps many, ISPs serving the residential market will construe "prove to our satisfaction" as "pay us a lot of extra money". If that happens, our experience with IPv4 and NATs suggests to me that it will be a _very_ short period of time before devices hit the consumer market that either do subnetting on longer-than-/64 prefixes, are set up to handle some other model of address pools, or NAT (I'd predict all three and would find the middle one interesting) along with patches to stacks that support them as needed.
Since we probably won't revisit the /64 subnetting choice, those patches will be made independent of any standard or IETF advice which suggests that there may be interoperability problems if there is any opportunity for them.
And _that_ is bad news. It is also news that reinforces my response to Thomas: there really are architectural issues in this sort of decision and no one I know of has chartered the RIRs to make those types of architectural decisions.
john
Will all due respect, even if you assume a "home" with ten occupants, a few hundred subnets based on functions, and enough sensor-type devices to estimate several thousand of them per occupant and a few thousand more per room, 2**64 is still a _lot_ of addresses.
This is hyperbole. All IPv6 subnets have the same minimum number of addresses (2**64) regardless of where they are used.
But I don't think hyperbole helps the discussion.
I agree. In any case, it doesn't make sense to discuss IPv6 in terms of hostcounts. It makes more sense to discuss numbers of subnets or numbers of aggregation levels. If a private home with two occupants and one PC, builds out an in-law suite for one mother-in-law with one PC, then it still makes sense to have at least two subnets in that private home, i.e. at least one level of aggregation. Hostcount is irrelevant. Note that if both mother-in-law and homeowner install 4 or five home media devices, the subnetted architecture will work better than a /64 per home scenario. Now that we have shown subnetting is useful in a private home, it is clear that a /64 per home is not enough. It still leaves open the question of whether a /48 is too much, i.e. too many subnets and/or too many levels of aggregation. If a /48 is not too much, then the IETF should issue guidance that states that. If some prefix length between /48 and /64 is OK under certain circumstances then the IETF should issue guidance which states that. I still have not seen any clear indication that there is a negative technical impact of assigning a /56 per home. To date, the only clear technical issue I have seen mentioned for subnet prefixes longer than /48 is that if they are not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more complex. --Michael Dillon
On 31-aug-2007, at 17:31, <michael.dillon@bt.com> <michael.dillon@bt.com> wrote:
I still have not seen any clear indication that there is a negative technical impact of assigning a /56 per home.
Then you haven't been paying attention, I've been saying /56 is the wrong size for some time now.
To date, the only clear technical issue I have seen mentioned for subnet prefixes longer than /48 is that if they are not on a 4-bit hex nibble boundary, it makes IPv6 PTR delegation more complex.
Then you have to delegate 2, 4 or 8 zones rather than 1, big deal.
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet.
You are remarkably trusting. You do all your homebanking on the same subnet as your teenage children who are studying Hacking 101 in the privacy of their bedroom? And when guests come over for dinner, you have no objection to them taking their laptop to the bathroom in order to surf for child porn over your wireless network. The fact is that a lot of people will WANT subnets in the home. They will want a router/firewall that will isolate each of the children's bedrooms so that they cannot mess with your bank account or with their brother's/sister's romantic chat sessions. Many people will want all wireless access to go through a router. Many will have an in-law suite, and want to seamlessly integrate their relative's existing network via a simple router connection. And the family jewels, that Raid 5 server cluster that holds all the family photos and videos, will be behind another router/firewall. When the kids host a LAN party, the gamers will connect to the family network via a router/firewall with limited Internet access for only the necessary protocols. Subnets multiply for architectural and security reasons. Multiple subnets per home is *NOT* a waste of anything. It is an invitation to dreamers and inventors to make better network things for the home market. It is an enabler of business activity, an enabler of competition. --Michael Dillon
--On Sunday, 26 August, 2007 12:41 +0100 michael.dillon@bt.com wrote:
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different ... You are remarkably trusting. You do all your homebanking on the same subnet as your teenage children who are studying Hacking 101 in the privacy of their bedroom? And when guests come over for dinner, you have no objection to them taking their laptop to the bathroom in order to surf for child porn over your wireless network.
The fact is that a lot of people will WANT subnets in the home. They will want a router/firewall that will isolate each of the children's bedrooms so that they cannot mess with your bank account or with their brother's/sister's romantic chat sessions. Many people will want all wireless access to go through a router. Many will have an in-law suite, and want to seamlessly integrate their relative's existing network via a simple router connection. And the family jewels, that Raid 5 server cluster that holds all the family photos and videos, will be behind another router/firewall. When the kids host a LAN party, the gamers will connect to the family network via a router/firewall with limited Internet access for only the necessary protocols. Subnets multiply for architectural and security reasons. ...
Michael, Assume we agree on the needed functionality. It is hard to disagree and many of us have seen the need to isolate some people and apparatus from others, and to assign different capability to them, for many years. That still leaves room to ask several questions. I believe those questions need to be asked, and the relevant technical work done. And I think one needs to do that work and then adjust address policy to match, not change address policy without making corresponding technical/ protocol changes. Examples: (1) Unless it was changed when I wasn't looking, there is a rule in the IPv6 architecture that says that one cannot subnet on a prefix longer than a /64. That rule appears to be someone hostile to efficient use of address space at the "small network with subnets" side of things. Has that rule outlived its usefulness? If so, how do we go about changing it before IPv6 is sufficiently widely deployed to make it even more difficult and disruptive to do so? (2) The many examples you give seem to be to be associated with different domains of authorization and privilege for different groups of people and functions within the home. My impression of the experience and literature in the field is that almost every time someone tries to create such a typology, they conclude that these are much better modeled as sometimes-overlapping domains rather than as discrete partitions. The subnet-based model you posit requires that people or devices switch addresses when they change functions or activities. Up to a point, one can do it that way (and many of us have, even with IPv4). But I suggest that trying to use subnetting as the primary and only tool to accomplish those functions is architecturally just wrong, _especially_ for the types of authorization-limitation cases you list. Wouldn't you rather have mechanisms within your home network, possibly bound to your switches, that could associate authorization property lists with each user or device and then enforce those properties? Kerberos (a very old protocol by now) took the first steps in that direction by associating access to server-type functions with authorization properties rather than physical connectivity. Perhaps it is time to extend a model of that sort to access to network resources --such as routing to other addresses both inside and outside of the home network-- and to think through how it could be scaled to effective and cost-efficient operation in a home-sized network. (3) It may be worth remembering that subnetting was introduced into the IPv4 architecture partially to deal with routing isolation and efficiency for LANs based on 10Base10 and 10Base2 Ethernet --backbone-style networks at the LAN, or groups of LANs, level. While some lazy few of us still have some 10Base2 in our LANs, the move toward LAN segments based on twisted-pair cabling and fanout switch arrangements creates opportunities we didn't have when "segment" was a physical property rather than a logical one. Is it time to review and update the network architecture to reflect new opportunities in the physical one, rather than assuming that authorization is necessarily reflected in subnets? (4) Which IETF WG is working on these things? :-( john
Assume we agree on the needed functionality. It is hard to disagree and many of us have seen the need to isolate some people and apparatus from others, and to assign different capability to them, for many years.
People want security, and the threats that Michael mention are real: children spying on the parent's traffic, guests abusing the access to do something illegal on the Internet. But subnets are not a particularly efficient way of solving these threats. Take the issue of guests abusing the privilege and engaging in illegal action. The concrete risk is that men in black will knock at your door and ask about said actions. Picture yourself arguing that "it obviously wasn't me, because the packets come from the network that I provide to my guests". The men in black will not be impressed, since you obviously have access to all the networks in your house. Your only defense will be to rat a specific guest, supposing of course that you are so enclined. Subnet or no subnet will no help you do that. Access control and logs will help, but these are not tied to subnets. Consider then the attacks between computers on the same network. Michael mentioned traffic snooping. But modern Wi-Fi network are protected against that already. They negotiate different per-session keys. Even in promiscuous mode, the Wi-Fi card does not see the unicast traffic of the other stations in the network. In home networks, the key is derived from an initial 4-ways handshake, secured by a pass-phrase. Most deployments use a single pass-phrase today, so teenagers could indeed develop tools to crack the exchange. But nothing prevents using different pass-phrases for different group of users. The other risk are the active attacks between connected computers. However, as John pointed out, there is lot of demand for connectivity between computers in the home. Many people have tried to engineer network topologies that follow organization or authorization boundaries, but the mostly that makes your network expensive to run without really solving the issues. Also, ultimately, all forms of topology based control rely on the security of the home router. Do you really believe that a teenager who is clever enough to hack into Wi-Fi access protections will not also be able to hack into the home router? If we want actual protection, it is probably much easier to use end to end security. And in your own house, you might consider forms of social control, as in "OK, you hacked my computer, give me the keys of your car..." Frankly, I don't see users managing subnets any time soon. -- Christian Huitema
subnets have proven to a useful tool in the past, and may prove so again in the future, even if the reasons for future use are different than those for past and present use. I don't see why we should constrain the network architecture to deny use of this tool to ordinary users. Keith
Assume we agree on the needed functionality. It is hard to disagree and many of us have seen the need to isolate some people and apparatus from others, and to assign different capability to them, for many years.
People want security, and the threats that Michael mention are real: children spying on the parent's traffic, guests abusing the access to do something illegal on the Internet. But subnets are not a particularly efficient way of solving these threats.
Take the issue of guests abusing the privilege and engaging in illegal action. The concrete risk is that men in black will knock at your door and ask about said actions. Picture yourself arguing that "it obviously wasn't me, because the packets come from the network that I provide to my guests". The men in black will not be impressed, since you obviously have access to all the networks in your house. Your only defense will be to rat a specific guest, supposing of course that you are so enclined. Subnet or no subnet will no help you do that. Access control and logs will help, but these are not tied to subnets.
Consider then the attacks between computers on the same network. Michael mentioned traffic snooping. But modern Wi-Fi network are protected against that already. They negotiate different per-session keys. Even in promiscuous mode, the Wi-Fi card does not see the unicast traffic of the other stations in the network. In home networks, the key is derived from an initial 4-ways handshake, secured by a pass-phrase. Most deployments use a single pass-phrase today, so teenagers could indeed develop tools to crack the exchange. But nothing prevents using different pass-phrases for different group of users.
The other risk are the active attacks between connected computers. However, as John pointed out, there is lot of demand for connectivity between computers in the home. Many people have tried to engineer network topologies that follow organization or authorization boundaries, but the mostly that makes your network expensive to run without really solving the issues.
Also, ultimately, all forms of topology based control rely on the security of the home router. Do you really believe that a teenager who is clever enough to hack into Wi-Fi access protections will not also be able to hack into the home router?
If we want actual protection, it is probably much easier to use end to end security. And in your own house, you might consider forms of social control, as in "OK, you hacked my computer, give me the keys of your car..."
Frankly, I don't see users managing subnets any time soon.
-- Christian Huitema
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
From: John C Klensin [mailto:john-ietf@jck.com] Examples:
(1) Unless it was changed when I wasn't looking, there is a rule in the IPv6 architecture that says that one cannot subnet on a prefix longer than a /64. That rule appears to be someone hostile to efficient use of address space at the "small network with subnets" side of things. Has that rule outlived its usefulness? If so, how do we go about changing it before IPv6 is sufficiently widely deployed to make it even more difficult and disruptive to do so?
Perhaps you could define the term subnet? I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose. The situation we have is similar to that which Octavian found himself in the aftermath of the assasination of Ceasar, he had authority but not power. It is not a hopeless position, I have often found authority to provide more real influence than formal decision making power. But understanding the difference is critical if there is to be effective influence.
But I suggest that trying to use subnetting as the primary and only tool to accomplish those functions is architecturally just wrong, _especially_ for the types of authorization-limitation cases you list. Wouldn't you rather have mechanisms within your home network, possibly bound to your switches, that could associate authorization property lists with each user or device and then enforce those properties?
I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network of services.
(3) It may be worth remembering that subnetting was introduced into the IPv4 architecture partially to deal with routing isolation and efficiency for LANs based on 10Base10 and 10Base2 Ethernet --backbone-style networks at the LAN, or groups of LANs, level. While some lazy few of us still have some 10Base2 in our LANs, the move toward LAN segments based on twisted-pair cabling and fanout switch arrangements creates opportunities we didn't have when "segment" was a physical property rather than a logical one. Is it time to review and update the network architecture to reflect new opportunities in the physical one, rather than assuming that authorization is necessarily reflected in subnets?
Again, I agree, hence my request for a definition of subnet. It is a term that has been thrown around with much abandon but looks very likely to mean different things to different people at this point.
(1) Unless it was changed when I wasn't looking, there is a rule in the IPv6 architecture that says that one cannot subnet on a prefix longer than a /64. That rule appears to be someone hostile to efficient use of address space at the "small network with subnets" side of things. Has that rule outlived its usefulness? If so, how do we go about changing it before IPv6 is sufficiently widely deployed to make it even more difficult and disruptive to do so?
Perhaps you could define the term subnet?
I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.
Perhaps not, but such an ISP might incur significant support costs. For instance, an ISP that assigned a /128 might get a complaint every time a customer tried to change his computer or network card. That, and several IPv6 protocols were designed with the assumption that /64 was the maximum length of a prefix to be assigned to a net. There aren't any more bits in those protocols to support a longer subnet mask. Realistically if an ISP wanted to restrict its customers to a maximum of one IPv6 host there are probably less disruptive (therefore cheaper) ways to do this than to try to make the customer's network prefix be a /128. And then the customers would just NAT, and the ISP's effort would be wasted. So there's little benefit to the ISP in doing this, particularly if they can get enough addresses from their upstream providers or registries. More broadly, IETF can't prevent an ISP from offering a service that claims to be Internet but doesn't follow the specified protocols. But since those protocols are the agreements by which interoperability is obtained, an ISP that violates those protocols risks alienating its customers when their applications do not work. In practice, ISPs do this routinely (e.g. ISPs that provide DNS servers that lie about the RRs for a given zone), and they also get pushback for doing so. Customers are slow to learn but some of them do change ISPs when they find out that they're being screwed. As you point out, we have very little power to prevent ISPs (or equipment vendors, or OS vendors, or users) from doing harm. But that doesn't mean we should say that it's okay for them to do things that we have every reason to believe will do harm.
I agree, encoding authorization data into the network address is not a good strategy, another structural oddity is that we continue to view the Internet as a network of hosts rather than a network of services.
Well, at one level, it is a network of hosts. The network of services is built on top of the network of hosts. It's just that the boundary between the two is fuzzy. Keith
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.
Not directly, but there's the indirect route: a) IETF designs IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes that support autoconfiguration. c) ISP hand out /128s. d) Autoconfiguration doesn't work well. e) Customers call ISP support. f) ISP loses $$$. g) ISP starts issuing /48s instead. I don't know the first thing about how IPv6 autoconfiguration works. It worked very well in my previous office. Will it work better when the router has a /48 at hand than a /64 or /128? Arnt
Arnt Gulbrandsen wrote:
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.
Not directly, but there's the indirect route: a) IETF designs IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes that support autoconfiguration. c) ISP hand out /128s. d) Autoconfiguration doesn't work well. e) Customers call ISP support. f) ISP loses $$$. g) ISP starts issuing /48s instead.
I don't know the first thing about how IPv6 autoconfiguration works. It worked very well in my previous office. Will it work better when the router has a /48 at hand than a /64 or /128?
Arnt
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
I remember working with my own little lan: three Site Local and one tunnel networks. radvd or SuSE 7.1 and SuSE 8.2 did expect /64 The tunnel would either give me a /64 without local router or a /48 if I had a local router. Today Site Local is given up. So I changed to 192.168... addresses with 6to4 addressing. RFC 2462 says we normally have EUI-64 addressing that is either a funtion of the MAC address or a random number. With EUI-64 (64 bits) the prefix must be /64 for an autoconfigured network segment. The tunnel used to be a /124 network segment overlapping my /64 with ..0 the net, ..1 the other end of the tunnel, ..2 me and ..3 broadcast. Theoretically ..2 would have been a router for anything in my /64, but that never worked. So practically I ended up with a /128 If you have a LAN with servers you need predictable addresses for your servers. Renumbering is not an option. Site Local does not exist any longer. 182.168.. with 6to4 addressing is the only way I see. But that means - no autoconfiguration. Without autoconfiguration /124 and NAT is good enough for me. But how about my aunt with her laptop? Kind regards Peter and Karin -- Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: peter@peter-dambier.de mail: peter@echnaton.arl.pirates http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Looks to me like people are trying to use technology to effect their political goals. I don't think that is a good idea, particularly since the process does not allow the goals to be stated or debated directly. So even if we agree on the end goals we are unlikely to end up with a mechanism that achieves them. We went through all that with the crypto-wars. We ended up with a set of cryptography protocols that almost nobody uses. I see no political reason to insist on a /48 as the minimum allocation. A /96 gives me more addresses than the old IPv4 space had. If we attempt to insist on a /x as the minimum allocation by introducing technical limitations that make it impossible to use less than a /x all we do is to make an allocation that could have been sufficient insufficient.
-----Original Message----- From: Arnt Gulbrandsen [mailto:arnt@gulbrandsen.priv.no] Sent: Monday, August 27, 2007 5:11 AM To: ietf@ietf.org Cc: michael.dillon@bt.com; John C Klensin; Hallam-Baker, Phillip; ppml@arin.net; address-policy-wg@ripe.net Subject: Re: IPv6 addresses really are scarce after all
Hallam-Baker, Phillip writes:
I don't see how such an architectural limitation can be enforced. There is no way that the IETF can prevent an ISP issuing IPv6 customers a /128 if they choose.
Not directly, but there's the indirect route: a) IETF designs IPv6 autoconfiguration. b) Linksys, D-Link, Netgear and friends make boxes that support autoconfiguration. c) ISP hand out /128s. d) Autoconfiguration doesn't work well. e) Customers call ISP support. f) ISP loses $$$. g) ISP starts issuing /48s instead.
I don't know the first thing about how IPv6 autoconfiguration works. It worked very well in my previous office. Will it work better when the router has a /48 at hand than a /64 or /128?
Arnt
Hallam-Baker, Phillip writes:
Looks to me like people are trying to use technology to effect their political goals.
Guilty as charged, and proud of it. My political goal is to make computers help people in their daily life, and I believe that eliminating the class of users without the ability to subnet, leaving only one type of internet user, helps towards that goal. If there's only one type of network to autoconfigure, testing and deploying autoconfiguring devices is simpler, and autoconfiguration will do the right thing in a larger percentage of cases, leaving more people happy and making fewer people call support. Arnt
(2) The many examples you give seem to be to be associated with different domains of authorization and privilege for different groups of people and functions within the home. My impression of the experience and literature in the field is that almost every time someone tries to create such a typology, they conclude that these are much better modeled as sometimes-overlapping domains rather than as discrete partitions. The subnet-based model you posit requires that people or devices switch addresses when they change functions or activities. Up to a point, one can do it that way (and many of us have, even with IPv4).
The subtext here is Ethernet. People are talking about home networks based on Ethernet and whether or not they should be segmented by routers. In my experience Ethernet bridges and switches are not designed with security as a goal. When they fail to transmit all incoming frames on all interfaces, it is to prevent segment overload or broadcast storms. There are many cases where people have found ways, sometimes quite simple ways, to receive Ethernet frames that are not addressed to them. Given this backdrop, I am suggesting that a homeowner may have several reasons for inserting routers (and router/firewalls) into their home network, thus requiring the ability to have multiple /64 IPv6 subnets. Architecture aside, this is a pragmatic response to an information security issue.
But I suggest that trying to use subnetting as the primary and only tool to accomplish those functions is architecturally just wrong, _especially_ for the types of authorization-limitation cases you list. Wouldn't you rather have mechanisms within your home network, possibly bound to your switches, that could associate authorization property lists with each user or device and then enforce those properties?
This would be nice, but I believe this needs more work and not just in the IETF. Also, I believe that the IETF should tackle the basic requirements for a home and/or business IPv6 Internet gateway first, and then go on to the more advanced security issues.
(4) Which IETF WG is working on these things? :-(
Or failing that, which area does it belong in? --Michael Dillon
Thus spake <michael.dillon@bt.com>
In my experience Ethernet bridges and switches are not designed with security as a goal. When they fail to transmit all incoming frames on all interfaces, it is to prevent segment overload or broadcast storms. There are many cases where people have found ways, sometimes quite simple ways, to receive Ethernet frames that are not addressed to them. Given this backdrop, I am suggesting that a homeowner may have several reasons for inserting routers (and router / firewalls) into their home network, thus requiring the ability to have multiple /64 IPv6 subnets. Architecture aside, this is a pragmatic response to an information security issue.
Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO? Sorry, but that's the wrong response to the wrong problem. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
On Mon, 27 Aug 2007, Stephen Sprunk wrote:
Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO?
It has nothing to do with IPsec or SSL. Your view of what people do at home is kind of narrow. Some people run businesses out of their house, and some have quite complicated home networks, with wifi for guests and and other parts they don't want guests to get into. If you have the space, give it out. (that was the point of a 16 byte IP address) The notion that a home user's subnetting makes any difference to the DFZ is just plain nonsense. Those sub-blocks are aggregated by their provider. The home user doesn't need or take a full view, either. They have just their subnets and a default route. At the other end, the notion that geographic aggregation reduces the DFZ is likewise nonsense. It just eases the job of the RIR and running multiple RIRs. But every block delegated by the RIR will probably make it into the DFZ, unless it is used for some kind of non-public routing, in which case perhaps it makes it into some DFZ's, but not others. There usually isn't any aggregation of blocks delegated by the RIR. --Dean
Sorry, but that's the wrong response to the wrong problem.
S
Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info@arin.net if you experience any issues.
-- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
I agree with Dean entirely. On 8/27/07 4:02 PM, "Dean Anderson" <dean@av8.com> wrote:
On Mon, 27 Aug 2007, Stephen Sprunk wrote:
Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO?
It has nothing to do with IPsec or SSL. Your view of what people do at home is kind of narrow. Some people run businesses out of their house, and some have quite complicated home networks, with wifi for guests and and other parts they don't want guests to get into.
If you have the space, give it out. (that was the point of a 16 byte IP address) The notion that a home user's subnetting makes any difference to the DFZ is just plain nonsense. Those sub-blocks are aggregated by their provider. The home user doesn't need or take a full view, either. They have just their subnets and a default route.
At the other end, the notion that geographic aggregation reduces the DFZ is likewise nonsense. It just eases the job of the RIR and running multiple RIRs. But every block delegated by the RIR will probably make it into the DFZ, unless it is used for some kind of non-public routing, in which case perhaps it makes it into some DFZ's, but not others. There usually isn't any aggregation of blocks delegated by the RIR.
--Dean
Sorry, but that's the wrong response to the wrong problem.
S
Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSS dice at every possible opportunity." --Stephen Hawking
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info@arin.net if you experience any issues.
-- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000
_______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info@arin.net if you experience any issues.
On Tuesday 28 August 2007 01:02, Dean Anderson wrote:
On Mon, 27 Aug 2007, Stephen Sprunk wrote:
Basically, because some people are too dense to use IPsec or SSL for traffic they don't want observed, you want to greatly complicate the average home network's design? That they should be more scared of, say, their spouse sniffing their credit card numbers at home than the NSA and FBI tapping their email and web browsing at the CO?
It has nothing to do with IPsec or SSL. Your view of what people do at home is kind of narrow. Some people run businesses out of their house, and some have quite complicated home networks, with wifi for guests and and other parts they don't want guests to get into.
I agree, not all home users have a small flat LAN. I'm personally running a VPN between 2 locations (privately) that are 85km seperated. Concequently I have 3 subnets (location A, WAN and location B). Besides that I have a VPN access when I'm on the road into those as well (currently IPv4 but as soon as I have the time v6). So I guess I'm actually using 4 subnets. I'm currently running my WLAN closed and not open to my guests but if I would open it (which I consider when I have some time to set up a captive portal log-in facility). Then I'd have 6 subnets (the 4 already mentioned + guest WLAN at both locations). I know I'm not the average user and probably more a geek but... And like Dean suggests already, I use crypto for completely different purposes, I don't need to subnet for that. Regards, Marc -- -- This mail is personal -- All statements in this mail are made from my own personal perspective and do not necessarily reflect my employer's opinions or policies.
Michael Agree. And don't forget that your: - power company - communication/entertainment provider/s - alarm/monitoring company - local government - EMS All have at least discussions in progress that would give each home/apartment a subnet (albeit possibly/probably on different networks) for there use as a home service provider. Take care Terry
-----Original Message----- From: michael.dillon@bt.com [mailto:michael.dillon@bt.com] Sent: Sunday, August 26, 2007 4:42 AM To: ppml@arin.net; address-policy-wg@ripe.net; ietf@ietf.org Subject: Re: [ppml] IPv6 addresses really are scarce after all
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet.
You are remarkably trusting. You do all your homebanking on the same subnet as your teenage children who are studying Hacking 101 in the privacy of their bedroom? And when guests come over for dinner, you have no objection to them taking their laptop to the bathroom in order to surf for child porn over your wireless network.
The fact is that a lot of people will WANT subnets in the home. They will want a router/firewall that will isolate each of the children's bedrooms so that they cannot mess with your bank account or with their brother's/sister's romantic chat sessions. Many people will want all wireless access to go through a router. Many will have an in-law suite, and want to seamlessly integrate their relative's existing network via a simple router connection. And the family jewels, that Raid 5 server cluster that holds all the family photos and videos, will be behind another router/firewall. When the kids host a LAN party, the gamers will connect to the family network via a router/firewall with limited Internet access for only the necessary protocols. Subnets multiply for architectural and security reasons.
Multiple subnets per home is *NOT* a waste of anything. It is an invitation to dreamers and inventors to make better network things for the home market. It is an enabler of business activity, an enabler of competition.
--Michael Dillon _______________________________________________ PPML You are receiving this message because you are subscribed to the ARIN Public Policy Mailing List (PPML@arin.net). Unsubscribe or manage your mailing list subscription at: http://lists.arin.net/mailman/listinfo/ppml Please contact the ARIN Member Services Help Desk at info@arin.net if you experience any issues.
Christian Huitema writes:
The definition of a small network is pretty much "single subnet". Yes, I understand very well that the average home of the future will have a mixed wiring. Of course, my own home does have Ethernet and Wi-Fi. In the not so distant future, it will have several Wi-Fi networks operating on different frequencies, some form of power-line networking, and some rooms may have their own high speed wireless wiring using UWB or some similar technology. But I am pretty much convinced that all of these will be organized as a single subnet.
You mean that the faster actual subnets will not be subnets in the IETF sense, right? If a number of devices have some extremely fast special network, and a bridge or router to connect them to the rest of the world, presumably they need the extra bandwidth: If their traffic were to leak onto the slower net, it would be more or less unusable. But there are several ways in which the fast devices can leak traffic, often involving broastcast or multicast. (I have some neat audio boxes that multicast to group "all-devices-from-manufacturer-x", very nice, but I'm glad my backbone isn't 802.11.) Either the IETF subnet has to be usable to describe these actual subnets (ie. people get more than a /64 automatically so it's the common case and random consumerboxes are built for it) or there'll eventually be some new subber-than-subnet concept so devices can broadcast or multicast traffic onto their fast subber-than-subnet without overwhelming the slow parts of the subnet. Arnt
participants (13)
-
Arnt Gulbrandsen -
Christian Huitema -
Davis, Terry L -
Dean Anderson -
Hallam-Baker, Phillip -
Iljitsch van Beijnum -
John C Klensin -
Keith Moore -
Marc van Selm -
michael.dillon＠bt.com -
Peter Dambier -
Stephen Sprunk -
Tommy Perniciaro