Realistically the first 64 bits are going to be very ugly, so I disagree that a v6 will ever be much easier to remember than a v4 address. Especially with the 0 compression being back-ported to v4 stacks, running on the 10. network - You can ping 10.1 as 10.0.0.1 on many stacks now.

If they had requested a boring /48 IPv6 allocation (that anybody can have just by asking) - they would have had 2^16 /64 networks, and each network could have had basically an infinite number of hosts.

But, this is the IPv6 world, so I would have expected MIT to claim they were a LIR (Local Internet Registry - equivalent of a small ISP or larger) - and asked for a /32 - which would have given them 2^32 networks - or 4 Billion networks to work with. They probably would have assigned the networks by segmenting them on a per site basis - so each site would have had a /48 assigned, so they could have up to 65K sites, each site having 65K networks, each network having (effectively) infinite number of hosts. That is, a /32 would have been far, far, far larger than their /8 was. Easier to manage as well (no VLSM - nothing ever smaller than a /64) And, keep in mind, with a single, no contest request, they could have gotten the /32 adjacent to theirs (another 4 Billion networks, or 65K /48s) so they could aggregate on a /31.

Instead, they've asked for a /24. And I'm just darn intrigued as to why they think they can make use of such an address space. If they weren't constrained with their /8, then a /32 would have been far more than they ever required. (And odds are a /48 would have been sufficient with even modest address management).

I mean, I work with really large mesh networks, millions of nodes, some of our subnets have 20K nodes each on them - we roll out /48s like they are nothing, and even after deploying a couple hundred customers over 10 years, and 25 million nodes, I think we've used up maybe 1500 /48s.

BTW - this doesn't even take into account that they can use RFC 4193 up the wazoo for all sorts of interesting non-globally routable experimental internal networks.

I"m just hoping someone from MIT is reading HN and will clue us in.

Maybe we should (be able to) get rid of the broadcast address in this situation too. Cf. RFC 3021 (adding a special case for /31).

(If the hosting provider literally only intends to give you a single address, and insists on giving you a subnet, it should probably give you a /31 instead of a /30, because of the RFC 3021 behavior. Then it's not throwing away addresses for no reason.)

I was primarily thinking of residential ISPs; business ISPs tend to be a little bit better. That said, datacenters (or rather server/VPS providers) are absolutely terrible. Most of them give you no v6 allocation of your own at all. If you're lucky they let you use as many addresses as you like on your WAN segment, but good luck if you wanted to do a VPN or routed VM subnet.

Since /56 seems to become the "easily available standard size" for allocations, using a /64 doesn't seem like to much of an issue, especially since larger orgs should easily get /48s? (But are /64 really accepted as routes? I would have imagined that to be also limited to /56 or /60 or so)

You can also make compromises with NAT, like handing out 40-bit addresses that are auto-translated to/from 32-bit with 8 bits going into the port.

Because then you don't really have enough bits to do some nice things:

1. It would be nice for your upstream network provider (and you) if they can delegate some network prefix and thus don't need to concern themselves with the address plan inside your subnet. That means, if there is an address collision on your prefix it's not their problem.

2. Assuming you have been delegated a network prefix, having at least 48 bits for within-subnet addressing greatly simplifies self-assigned addresses:

2.1 You can use the data link layer's address (the 48 bit MAC address for ethernet) which often has weak guarantees of uniqueness (though this isn't really advised today)

2.2 You can also randomly generate addresses or generate them by hashing things, and be reasonably confident of not colliding with another station.

2.2.1 Of course, you want to check that no other station is using the same address, but there's always the hidden node problem: How does station C cope with stations A and B both claiming address XYZ?

2.3 You can (if you want) still use DHCP to assign addresses if you want. But you don't have to.

3. It would be nice if each station was not limited to a single address.

3.1 Among other things, having multiple addresses vastly simplifies building a multi-homed network. For example, you can (today) sign up for two (or more!) ISPs that support IPv6 Prefix Delegation and have your router(s) issue Router Advertisements (RAs) for each prefix.

If a link goes down, your router(s) don't need to do anything or share any state... it just works (yes, really, I've tried it!). Each of your routers, of course, only routes packets for the prefix it was delegated by its upstream.

(BTW, IPv6 also has some neat RFCs for letting foreign hosts know about a prefix change, so you can even transfer existing open connections initiated from an address on prefix A through a different router with connectivity on prefix B)

3.2 For privacy, wouldn't it be nice if you could generate a new address for every external server you connect to? You can do that with the 64 bit subnet address space--remember, your ISP has no say about the address plan within your network.

4. With 128 bit addresses, IPv6 allows you to delegate a /64 to yourself from the ULA block (the IPv6 equivalent of 192.168.. or 10...). You can just randomly pick a 57 bit suffix to append to fc00::/7, and you can be pretty darn confident that nobody else will pick the same one. And you get all the same advantages of self-assigned addresses (mentioned above) within that prefix.

4.1 Having a unique* local prefix maybe doesn't sound like such a big deal until you've tried to merge two enterprise networks that both have hosts on 10..., and clients hard-coded to connect to those hosts.

Finally, think about how a 64 bit global address space would be split up:

We're running out of IPv4 addresses, even with* NAT (and "CGNAT", which is just regular NAT with a fancy name). Most of those endpoints are users, not servers--you need at least 30 bits to give one prefix to each household with a current internet connection. Between the expected growth of internet users and all current enterprise networks, you need well in excess of 40 bits for the prefix.

So you'd realistically get no more than /48 prefix at home (16 subnet bits). That's not enough to do the cool autoconfig and privacy things I mentioned. More likely, you'd get a /56 because 256 hosts "ought to be enough for anybody" and you can't do the cool stuff anyway.

A /48 for a site allows a decent number of subdivisions along the easily human-readable nibble (16 bit) boundaries. Four characters each can be 0 through f.

A very small portion of addresses have been allocated so far. "According to the IPv6 Global Unicast Address Assignments list from IANA (last updated in Nov 2019), there have been 33 allocations made to the five Regional Internet Registries in total so far. This is equivalent to about 7,396,864 IPv6 /32 subnets which is approximately 0.172% of the total available IPv6 space." https://www.cidr.eu/en/ipv6

As a hack, it's quite possible someone will try allocating these and ask everyone to patch their systems over the next half a year to a year as things get more critical and the RIRs begin to run out of /24s. (The RIRs all still have enough /24s to last us for months after the IANA pool gets exhausted.)

We shall see. At the moment, there is no plans to use these. We could also arguably try to steal back the multicast ranges since it's so underused. :\

I thought the RIR could be assigned a /32 subnet at most (by the IANA), and that the RIR would hand /48 out to ISPs. The book I read on IPv6 is from before RFC6177, perhaps that's where the confusion came from.

In IPv6 most ISPs (except very large ones) are assigned one /32, which they can then subdivide how it fits their network. Every LAN gets it's own /64 (now one could debate if that should be smaller or not) and one doesn't really have to think hard how many hosts one expects in that broadcast domain.. do I want a /26 or is a /28 enough?

In addition in the IPv6 case you can get away with a single route in the routing table to reach all the networks of this ISP. Compare this to the IPv4 case where each ISP will have hundreds of /24s. Of course if one starts with multiple sites and traffic engineering that benefit goes away a bit, but still.. for most cases it does help with routing table fragmentation.

This is why 192.168.0.0/16 is often used for services like libvirtd, kubernetes and docker. And the use of the range by those services makes it even more unwieldy to try and put some other LAN in there.

You can work around these considerations if you want, but many people won't. When you're the network engineer responsible for designing a company's networks, you'll be wanting to keep things simple and robust. When you're called in at 3am on a Sunday because the network is down, you better hope your ability to recover doesn't require making a bunch of subnet calculations because you decided to try and use the pool of available IP addresses efficiently.

More recently (2011) RFC6177 took a more pragmatic / softened approach, but it does say:

      - it should be easy for an end site to obtain address space to
        number multiple subnets (i.e., a block larger than a single /64)
        and to support reasonable growth projections over long time
        periods (e.g., a decade or more).