Realistic number of hosts for a /64 subnet?

Tim Chown Tim.Chown at
Fri May 10 09:22:29 CEST 2019

> On 10 May 2019, at 07:43, Mikael Abrahamsson <swmike at> wrote:
> On Thu, 9 May 2019, Doug Barton wrote:
>> It's been a while since I was configuring subnets, and last time I did the guidance was always no more than 1,000 hosts per subnet/vlan. A lot of that was IPv4 thinking regarding broadcast domains, but generally speaking we kept to it for dual stacked networks, equating an IPv4 /22 with an IPv6 /64. (This was commonly in office environments where we used a subnet per floor to accommodate all of the desktops, printers, phones, tablets, etc.)
>> Is this still how people roll nowadays? Have switches and/or other network gear advanced to the point where subnets larger than 1k hosts are workable? In IPv4 or IPv6? I've done quite a bit of web searching, and can't find anything newer than 2014 that has any kind of intelligent discussion of this topic.
> It's a good topic to bring up. There has been some work on this in the IETF, for instance
> This means there is single broadcast domain and single /64 per customer, which if properly implemented helps with a lot of the problem space people like to solve in this area. It however includes moving away from quite a lot of what you call "IPv4 thinking".
> I however do not operate wifi networks so I have no idea how widely this is implemented in gear available today. If someone else knows, I would appreciate if they would share.

My former campus WiFi network used VLAN pooling, so where we had many thousands of devices on the same SSID (eduroam) they were put into one of a set of several dual-stack VLANs on associating, and potentially while moving around campus.  This reduced potential broadcast/multicast issues, but then meant (for example) that devices physically next to each other were often not in the same VLAN and thus by default not able to discover services each other were running.  That was part of my interest in the dnssd work.


More information about the ipv6-ops mailing list