Genuinely curious what you might need more for (for a single server).
Genuinely curious what you might need more for (for a single server).
Think of it in IPv4 terms, it's like having the range 192.168.0.0 to 192.168.0.255 (192.168.0.0/24) assigned to your host. 256 addresses should be plenty of addresses, but you can't cleanly segment them into multiple ranges, like you could with 192.168.0.0/16: because you can have 192.168.0.0/24, 192.168.1.0/24, 192.168.2.0/24.
By having multiple, complete blocks of /24, you can easily assign them to different classes of IP interfaces on your host.
There has been some hardware that takes a bit of a performance hit when doing route lookups that are longer than /64 in the past, but if you're doing this all in software on an end host, that's not an issue.
Go ahead and divide up that /64 to smaller blocks for your classification purposes, you'll still have plenty.
The client obtains the network prefix from the RA, and then the client tries to generate unique host address.
"" The IPv6 stateless autoconfiguration mechanism requires no manual configuration of hosts, minimal (if any) configuration of routers, and no additional servers. The stateless mechanism allows a host to generate its own addresses using a combination of locally available information and information advertised by routers. Routers advertise prefixes that identify the subnet(s) associated with a link, while hosts generate an "interface identifier" that uniquely identifies an interface on a subnet. An address is formed by combining the two. In the absence of routers, a host can only generate link-local addresses. However, link-local addresses are sufficient for allowing communication among nodes attached to the same link. ""
https://datatracker.ietf.org/doc/html/rfc7421 is helpful in understanding this.
Basically it explains that SLAAC RFC itself does not define the /64 limitation, but other RFCs that are relevant to network operation do.
""" The addressing architecture [RFC4291] [RFC7136] sets the IID length at 64 bits for all unicast addresses and therefore for all media supporting SLAAC. An immediate effect of fixing the IID length at 64 bits is, of course, that it fixes the subnet prefix length also at 64 bits, regardless of the aggregate prefix assigned to the site concerned, which in accordance with [RFC6177] should be /56 or shorter. """
but as you mentioned, there are a few roadblocks that say: you shouldn't