/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