/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(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf