I am quite startled by this thread, both in its emotion and in the apparent oversight of multiple approaches to the issue of having LOTS of connected user devices at a house/site/office when an IPv6 /64 prefix has been provided by one's upstream network provider. First, giving each end user a /64 means that the user can have up to 2^^64 devices at their site/home/office. That is a whole lot of devices -- more than any one house/site/office is going to have. Just as an example, all the IEEE 802 MAC addresses that ever will be issued (now or future) only would amount to 2^^48 (much smaller than the 2^^64 limit) since IEEE 802 uses 48-bit MAC addresses -- and a number of those MAC addresses are reserved for special purposes (e.g. link multicast MACs, local-scope MACs). Second, Ethernet bridging is a well understood technology and it works just fine even with very large numbers of devices. Some years back I was at a research lab (~2500 people on site) where virtually everyone had at least one IP connected computing system (some had more than one). About 1/4 of that site was connected via a big yellow Ethernet cable running classic CSMA/CD Ethernet at 10 Mbps (half-duplex). We weren't alone in having very large bridged networks. A typical house works fine just with very-low-cost Ethernet switches or hubs internally and perhaps a very-low-cost IP router between the house/site/office and the uplink device (e.g. cable modem, DSL modem, FIOS ONT). Most wireless access points are not merely radio repeaters, but also include bridge capability, so that traffic not needing to go over there air won't. One nice thing about using bridging is that it doesn't really care whether the upper layer protocol is IPv4, IPv6, IPX, or (gasp) CLNP. "Ethernet just works." (TM) Third, DHCP is a well understood technology that is deployed at millions of sites world-wide and generally works quite well. Those very-low-cost Ethernet routers one can purchase generally include both DHCP Client (for the uplink interface) and DHCP Server capabilities (for user devices). These are normally configurable. So one ought to be able to use DHCP to provision IPv6 addresses (out of that overall block of ~2^^64 IPv6 addresses mentioned above) using say 16 bits (bits 64-79) for IPv6 subnetting and the remaining 48 bits for naming IPv6 interfaces. [NB: While I personally remain a fan of the 8+8 architecture, so far the IETF has declined to formally adopt that, so that ought not be an issue for this kind of deployment today.] Fourth, lots of folks (me included) happen to find it convenient to use NAT between my site/house/office and my upstream provider. I'm a bit sceptical of the extravagent security claims sometimes made for NAT, but I do find it convenient. Mind, with the other options above, no one *needs* to use NAT with IPv6 even if their site/office/house gets a /64 routing prefix. Now I do think that folks here have overlooked one lurking issue. So far, few of the very-low-cost Ethernet switch/IP router boxen, or the very-low-cost wireless bridges/router boxen, or the very-low-cost security-gateway boxen, support IPv6 at all yet. One imagines that this is because the vendors of such devices don't perceive a current large market demand for IPv6 capability. So the IPv6 advocates might want to go work on making such very-low-cost boxen available. If IPv6 really takes off, there will be money to be made in that market segment. In turn, the paragraph just above means that most home users (a price sensitive lot if ever I've seen one) today will be using some sort of old home-brew BSD/Linux PC-hardware as their router/bridge. This means that one has even MORE flexibility than using the very-low-cost widgets, since shipping BSD/Linux has a pretty full set of IPv6 capabilities, IPv4 capabilities, and not a bad set of Ethernet bridging capabilities. Mind, such boxes are not easy for novice users to setup and deploy. So folks, not to worry, there are a number of off-the-shelf network deployment approaches that are practical and affordable today to enable significantly sized IPv6 networks to be built using a single /64, including options that support IPv6 routing and sub-netting. :-) Cheers, Ran Atkinson rja@xxxxxxxxxxxxxxxxxxx _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf