It's actually a pretty small prefix in the IPv6 world. The recommendation for an IPv6 network is to be at least a /64, because features like SLAAC, which mostly replaces DHCP, need a /64 prefix to work properly. If you have multiple networks, it's standard to use a separate /64 prefix per network. My ISP for instance gives every home user a /56 prefix, some ISPs even give out /48 prefixes.

It says right there in the description:

    “You could use the feature to run 281 trillion containers with their own IPs (which I assume is what AWS intended for the feature), but I wanted to find a more fun use.”

It's a odd size but more for being too stingy - normally in these kinds of setups you get something like a /48 or /56 for routing which lets you still have some bits for routing and then you can hang normal /64 subnets at the end of your routes.

Operating systems don't support non-64 prefixes very well and v6 wasn't designed to work like that.

> Operating systems don’t support non-64 prefixes

Then how do routers work? Docker containers? VMs running on a machine with some part of a /64?

It's more "why not." The mindset that addresses are something that need to be conserved and carefully parceled out simply does not jive with V6. It takes a while for that to really sink in particularly if one is used to having to care a lot.

Who cares if they need 100 or 200 or 500,000. Give them a /64 or /80 and let them use it for whatever they come up with. As to why specifically /64 and /80 it probably makes the internal net magic easier versus something that isn't 4-byte aligned.

/64 is the standardized value for the host part of an IPv6 address. Specifically, it's half the address.

And to me, this is part of the problem with IPV6. This HUGE amount of space that results in "why not" numbering, also means long hexadecimal IP addresses that no one can ever remember. The ship has sailed, but adding an octet to IPV4 and not planning to assign 28912479812 IP addresses to a toaster would have been so much easier.

You're not supposed to be remembering addresses, that's what DNS and LLNMR et al are for. IPv4 let people depend on bad habits and hard-coded fixups, V6 makes that slightly less practical.

Although frankly the functional part of most V6 addresses isn't that much more. Using ULA, of which there are enough of that organizations need not fear constant overlap like 10/8, the network side of our private internet space is only 6 characters and fixed host addresses are often 2. eg, fde3af::1.

We get cute with 6to4 mappings and some routing games and so they may look more like fde3:af00:12:34::1 but the local subnet is handed out via prefix delegation so end users rarely, if ever, need to care.

> Using ULA … the network side of our private internet space is only 6 characters

How do you fit the fixed 8-bit ULA prefix (fd00::/8) plus the 40 random bits you're supposed to use for the Global ID (per RFC 4193) into six hex characters? It should be at least 12, e.g. fdXX:XXXX:XXXX::/48.

As for remembering addresses, yes, just use (m)DNS. You can even set up an mDNS Discovery Proxy[0][1] so that devices which don't support mDNS themselves can resolve the names via regular unicast DNS.

[0] https://www.rfc-editor.org/rfc/rfc8766.html

[1] https://github.com/mkuron/mdns-discovery-proxy

What few private organizations I've seen working with ULA ... are not using really random global IDs. I'm sure larger scale organizations are following RFC4193 more honestly, but getting V6 going at all versus ever more horrifying NAT contraptions in industrial networks is usually enough of a victory for me.

Remembering ip addresses is like remembering passwords.

Why would you do that, when there are so many good tools you can use to do it for you way better than your feeble grey meat sack can?

I mean sure, I remember 127.0.0.1 and 8.8.8.8 and 9.9.9.9, but decent passwords these days are no more memorable than ipv6 addresses.

Yeah I don't really have a problem with the use of large spaces, was just curious about the prefix selection.

> As to why specifically /64 and /80 it probably makes the internal net magic easier versus something that isn't 4-byte aligned.

Thanks for the insight!

Nibble aligned is usually the norm

That individual instance might host hundreds of LAMP vhosts, each could have its own IP now

That individual instance can host 300 trillion vhosts with individual IPs with a /80 block. It has more publicly adressable IP addresses than the entire ipv4 address space.

That is exactly my question, is there a technical / practical reason for this? Or is it simply an arbitrary prefix?

IPv6 networks, by specification, are (almost) always /64 - that is, your subnetwork can have 2^64 nodes on it - which means that any EUI-64 device (A device with a 64 Bit MAC address - Ethernet Devices with 48 bits commonly extend to 64 bits by stuffing 16 bits (FF:FE) in the middle) can automatically determine its own IPv6 address by just concatenating the Network + MAC address. No Stateful DHCP server required.

I'm more curious as to why the /80. This is the very first time I've seen anything less than a /64. Without digging into the details, I'm guessing(?) that the network is a /64 (almost certainly), and on that network there can be /16 nodes (65536), each of which can have /48 (300 Trillion) vhosts.

And I thought I had left CIDR behind with IPv4... Sigh.