How does IPv6 subnetting work and how does it differ from IPv4 subnetting?

The first thing that should be mentioned about IPv6 subnetting is that a different mode of thought is called for. In IPv4 you usually think about how many addresses you have available and how you can allocate enough of them to each end user. In IPv6 you usually think about how many /64-subnets you have available and how you can allocate them to end users. You almost never worry about how many IP addresses will be used in a given subnet. Except for some special cases like point to point links, each subnet just simply has far more addresses available than it will ever require, so instead you worry only about allocating subnets, not hosts inside them.

IPv6 subnets are usually /64 because that is required in order for SLAAC (stateless address auto-configuration) to work. Even where SLAAC is not in use, there may be other reasons to use /64. For example, there might be some end user devices out there that just assume /64, or else routing subnets narrower than /64 might be inefficient on some routers because the router implementer has optimized the case of /64 or wider routes in order to save routing table memory.

Why is it recommended to use /127 for point to point links?

For the specific case of point-to-point links, /127 is recommended instead of /64 in order to avoid a vulnerability where packets addressed to any one of the quadrillions of unused addresses on the subnet cause unwanted neighbour solicitation requests and table entries that could drown a router. Such misaddressed packets may be malicious or accidental. But even if you actually configure a point-to-point link as /127, some people advocate assigning a whole /64 anyway just to be consistent.

Why would virtual machines be provisioned with subnets narrower than /64?

I don't know specifically why virtual machines would be provisioned with subnets narrower than /64. Perhaps because a hosting provider assumed that a server was like an end-user and required only a single /64 subnet, not anticipating that the server would actually be a collection of VMs requiring an internal routing topology? It could be done also simply as a matter of making the addressing plan easier to memorize: the host gets PREFIX::/64, then each VM gets PREFIX:0:NNNN::/96 where NNNN is unique to the VM and the VM can allocate PREFIX:0:NNNN:XXXX:YYYY as it pleases.

Can I map directly from IPv4 subnets to IPv6 subnets? For instance, does an IPv4 /24 correspond directly to an IPv6 /56 or /120?

From a low-level perspective of how addressing and routing works, the prefix length has the same meaning in IPv6 and IPv4. On that level, you can make an analogy such as "an IPv4 /16 uses half the bits for the network address and half the bits for the host address, that's like a /64 in IPv6". But this comparison is not really apt. Strong conventions have emerged in IPv6 which make the divisions of network sizes look somewhat more like the old world of classful networks in IPv4. To be sure, IPv6 didn't reintroduce classful addressing in which the most significant few bits of the address force a particular netmask, but what IPv6 does have is certain [de facto/conventional] standard network sizes:

• /64: the basic size of a single subnet: LAN, WAN, block of addresses for web virtual hosts, etc... "Normal" subnets are never expected to be any narrower (longer prefix) than /64. No subnets are ever expected to be wider (shorter prefix) than /64 since a /64's worth of host addresses is much more than we can imagine needing.
• /56: a block of 256 basic subnets. Even though current policies permit ISPs to hand out blocks as large as /48 to every end user and still consider their address utilisation well justified, some ISPs may (and already do) choose to allocate a /56 to consumer-grade customers as a compromise between allocation lots of subnets for them and address economy.
• /48: a block of 65536 basic subnets and the recommended size of block that every ISP customer end site should receive.
• /32: the default size of block that most ISPs will receive each time they request more addresses from a regional address registry.

Inside service provider and enterprise networks, many more prefix lengths than these 4 can be seen. When looking at the routing tables of routers inside these networks, IPv4 and IPv6 have much in common including most of the way routing works: routes for longer prefixes override covering routes for shorter prefixes, so it is possible to aggregate (make shorter) and drill down (make longer) routes. Like in IPv4, routes can be aggregated or summarized to larger blocks with shorter prefixes in order to minimize the size of routing tables.

A different question of mapping between IPv4 and IPv6 would be how to harmonize IPv4 and IPv6 assignments on dual-stack machines so that addressing plans can be readily understood. Far that, there are certainly conventions in common use to do this: embed the IPv4 "subnet number" into a portion of the IPv6 prefix, either with BCD (e.g. 10.0.234.0/24 becomes 2001:db8:abcd:234::/64) or binary (10.0.234.0/24 becomes 2001:db8:abcd:ea::/64).

My interfaces have several IPv6 addresses. Must the subnet be the same for all of them?

Absolutely not! IPv6 hosts are expected to be able to be multihomed by having several IP addresses simultaneously that come from different subnets, just like IPv4. If they are autoconfigured with SLAAC then the different subnets might have come from router advertisements from different routers.

Why do I sometimes see a % rather than a / in an IPv6 address and what does it mean?

You would not see one instead of the other. They have different meanings. A slash denotes a prefix (subnet), meaning a block of addresses that all start with the same n bits. An address without a slash is a host address. You may think of such an address as having an implied /128 at the end, meaning all 128 bits are specified.

The percent sign accompanies a link-local address. In IPv6, every interface has a link-local address in addition to any other IP addresses it might have. But the thing is, link-local addresses are always, without exception, in the fe80::/10 block. But if we attempt to talk to a peer using a link local address and the local host has multiple interfaces, how are we to know which interface to use to talk to this peer? Normally the routing table tells us which interface to use for a particular prefix, but here it will tell us than fe80::/10 is reachable via every interface.

The answer is that we must tell it which interface to use using the syntax address%interface. For example, fe80::1234:5678:8765:4321%eth0.

Am I wasting too many subnets? Aren't we just going to run out again?

Nobody knows. Who can tell the future?

But consider this. In IPv6 the number of available subnets is the square of the number of available individual addresses in IPv4. That's really quite a lot. No, I mean really quite a lot!

But still: we are automatically handing out a /32 to any ISP who requests one, we are handing out a /48 to every single ISP customer. Perhaps we're exaggerating and we will squander IPv6 after all. But there is a provision for this: Only one eighth of the IPv6 space has been made available for use so far: 2000::/3. The idea is that if we make a horrible mess of the first eighth and we have to drastically revise the liberal allocation policies, we get to try 7 more times before we're in trouble.

And finally: IPv6 doesn't have to last forever. Perhaps it will have a longer lifetime than IPv4 (an impressive lifetime already and it's not over) but like every technology it will someday stop mattering. We only need to make it until then.

IPv6 is 128 bits, so why is /64 the smallest recommended subnet for hosts?

First of all, a little ASCII art from the RFCs to establish terminology:

|         n bits         |   m bits  |       128-n-m bits         |
+------------------------+-----------+----------------------------+
| global routing prefix  | subnet ID |       interface ID         |
+------------------------+-----------+----------------------------+

The global routing prefix typically identifies the overall network that the address belongs to. It's typically 48 bits. The Interface ID identifies a given network interface. It's typically 64-bits. The remaining 16 bits is your subnet ID.

OK, on with the explanation:

According to RFC 4291 -- IP Version 6 Addressing Architecture:

All Global Unicast addresses other than those that start with binary 000 have a 64-bit interface ID field.

And RFC 5375 -- IPv6 Unicast Address Assignment Considerations:

An important part of an IPv4 addressing plan is deciding the length of each subnet prefix. Unlike in IPv4, the IPv6 addressing architecture [RFC4291] specifies that all subnets using Globally Unique Addresses and ULAs always have the same prefix length of 64 bits.

So ignoring the 000-prefix exception, the Interface ID is always 64-bits exactly. This is another way of saying that all local broadcast networks are always 64-bits. If you have an IPv6 address, its netmask is always 64 bits. Never more, never less. If you were assigned an address space larger than that (shorter netmask than 64-bits), then it's assumed that you will be partitioning that address space into 64-bit networks and handling the routing yourself. If you were given a network smaller than that (longer netmask), then someone screwed up.

So, why 64 bits exactly?

As a rule, IPv6 addresses are automatically-configured rather than assigned. The router will advertise which network prefix is available (routing prefix + subnet ID: first 64-bits), and your computer will fill in the last 64-bits using its own unique identifier. How does your computer come up with a unique identifier? There's a few possibilities, the most common is to use your interface's MAC address. You split the MAC in half (vendor half / serial half), flip the universal-local bit on the vendor side, and join them back together with FF:FE in the middle. So 00:30:48:01:23:45 becomes 0230:48ff:fe01:2345. Now put the advertised 64-bit network prefix on the left-hand-side of that, and you have your IP address.

The important point here is that if you follow this scheme, IP address collisions won't happen. Since every device on a given broadcast network NEEDS a unique MAC address to work, tying the interface ID to the MAC address means that as long as broadcast traffic doesn't collide, then neither will IPv6 addresses. Using 64-bits (instead of just the 48 dedicated to MAC addresses) gives a bit of wiggle-room beyond just the addresses provided by this scheme (there are several others).

Are there other situations in which I would use a subnet smaller than /64?

Nope. Not unless you're broken. Well, you may have a justification based on local requirements for setting up manual routing with your existing network. But bear in mind that by doing so, you're probably making a mess:

From RFC 5375 -- IPv6 Unicast Address Assignment Considerations:

Using a subnet prefix length other than a /64 will break many features of IPv6, including Neighbor Discovery (ND), Secure Neighbor Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], Protocol Independent Multicast - Sparse Mode (PIM-SM) with Embedded-RP [RFC3956], and Site Multihoming by IPv6 Intermediation (SHIM6) [SHIM6], among others. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.

....

However, some network administrators have used prefixes longer than /64 for links connecting routers, usually just two routers on a point-to-point link. On links where all the addresses are assigned by manual configuration, and all nodes on the link are routers (not end hosts) that are known by the network, administrators do not need any of the IPv6 features that rely on /64 subnet prefixes, this can work. Using subnet prefixes longer than /64 is not recommended for general use, and using them for links containing end hosts would be an especially bad idea, as it is difficult to predict what IPv6 features the hosts will use in the future.

Why is it recommended to use /127 for point to point links between routers, and why was it recommended against in the past?

You may want to gloss over RFC 3627 -- Use of /127 Prefix Length Between Routers Considered Harmful. Then have a look at the subsequent RFC 6164 -- Using 127-Bit IPv6 Prefixes on Inter-Router Links.

The objection to using prefixes longer than /64 on routers has to do with router auto-configuration potentially failing under rare circumstances. The objection to using prefixes shorter than /127 (2-hosts-only) has to do with a number of potential denial-of-service issues relating to packets being sent to the unrouted addresses. Since real-world denial-of-service issues are worse than theoretical auto-configuration failures, /127 is the new favorite.

Should I change existing router links to use /127?

If you control an IPv6 router, I'd recommend reading the two RFCs (they're short!) and deciding for yourself.

Can I map directly from IPv4 subnets to IPv6 subnets?

For instance, does an IPv4 /24 correspond directly to an IPv6 /56 or /120?

Actually... yes. Remember that 000-prefix we intentionally ignored earlier? Well, here's a use for it:

On dual-stack systems (ones with both IPv4 and IPv6 stacks active), you can represent IPv4 using IPv6 addresses. It's called "IPv4-mapped IPv6 addresses". The pattern is all-zeroes, followed by FFFF, followed by the 32-bit IPv4 address.

So, 192.168.100.21 becomes ::FFFF:C0A8:6415 -- or more simply: ::FFFF:192.168.100.21. Since that right-hand bit represents an IPv4 address, it's traditionally written out using dotted-decimal form.

As this is an actual IPv4 address, it still uses IPv4 headers etc., which means that an IPv4 stack must be present, IPv4 routes must be set, and all that. The advantage is that you can represent both IPv4 and IPv6 addresses using a single address structure, which can simplify application development. It doesn't make a lick of difference as far as the network is concerned.

1. IPv6 is 128 bits, so why is /64 the smallest recommended subnet for hosts?

   This prefix size was originally recommended in an older RFC - there has since been a revison to this policy where the issue of Neighbour Discovery Attacks is considered and using a /126 is a valid mitigation - nonetheless, if you are setting up PtP links with the sole purpose of routing traffic, an alternative option is simply to stick with a /64 and firewall that subnet. Better yet, allocate yourself a pool from which you will draw /64 subnets, and have that entire pool as a blacklisted destination at your edge (and anywhere else that hostility could come from)

2. Why is it recommended to use /127 for point to point links between routers, and why was it recommended against in the past? Should I change existing router links to use /127?

   /127 is not recommended between routers and never was - the all-routers Anycast address is the all-zeros address of the subnet; this means that /127 is technically only valid between two machines where one of them is NOT acting as a router. /126 is of course fine.

   In any case however, I would not advise switching existing /64 links unless your equipment is vulnerable to a Neighbour Discovery cache flood attack - and even in this case, first determine if you're going to actually be using that /64 for internet connectivity, if the answer is no, just firewall it.

3. Why would virtual machines be provisioned with subnets smaller than /64?

   This breaks SLAAC and RAs, unless you really, really know what you're doing, it's unlikely that you have any good reason for doing this - perhaps your upstream only gave you a single /64 but if that's the case, you need to go back to them and ask for more, if they want to charge you for it, start looking for a new provider and also perhaps send them some snarky e-mails linking to the relevant RFCs.

4. Are there other situations in which I would use a subnet smaller than /64?

   Honestly? probably not. If I think of a legitimate reason where a smaller subnet is preferable for purposes other than preventing NDP attacks, I'll edit this section.

   Conversely, there are situations where you would NOT want to use subnets smaller than /64 - particularly anywhere that you run an environment with hardware forwarding equipment (think name-brand routers and L3 switches) - some will be unable to do hardware routing of prefixes longer than /64, others have to split up the operation into multiple comparisons, thus, you should at the very least do your best to ensure that /64 is the longest prefix in your (OSPF/ISIS/EIGRP/etc.) backbone.

5. Can I map directly from IPv4 subnets to IPv6 subnets? For instance, does an IPv4 /24 correspond directly to an IPv6 /56 or /120?

   Officially, ::ffff:x.x.x.x is the format for an IPv6-mapped IPv4 address - there are of course also a number of transition mechanisms, namely 6to4 and its relative, 6rd, which map an IPv4 address into a global IPv6 one for the purposes of providing IPv6 access over IPv4 by creating an IPv6 prefix that is derived from the IPv4 address it's carried over.

6. My interfaces have several IPv6 addresses. Must the subnet be the same for all of them?

   No, using varying addresses and subnet sizes across the same interface should not be an issue. If it is, the implementation is buggy. Of course, a better question is why would you be doing this?

7. Why do I sometimes see a % rather than a / in an IPv6 address and what does it mean?

   This is a delimiter, generally applied to link-local addresses (fe80::/12) - since the same link-local address can legitimately exist on multiple interfaces, the % delimiter is used to permit specifying which interface is meant. Linux generally makes specifying the interface mandatory when doing operations involving a link-local. Windows Vista/2008 and beyond are a bit smarter and won't complain unless a link-local is non-unique.

8. Am I wasting too many subnets? Aren't we just going to run out again?

   No. This is a dead horse that's been flogged WAAAAAAAAAY too many times - the current Global IPv6 internet is 2000::/3 - there are several more prefixes that IANA could start using if, somehow, every RIR on the planet managed to deplete their address stocks. So no, we will not run out of space, and even if we do, it requires a flick of a pen to turn up a new prefix, not a technical change. The only thing this question really highlights is the inability of the human mind to fully comprehend how ridiculously vast the address space is.

9. In what other major ways is IPv6 subnetting different from IPv4 subnetting?

   Other than not caring about how much space you're using, remember that there is no broadcast address and that the "subnet-zero" address is now the all-routers anycast address (which is basically an address that exists implicitly on all nodes configured to forward IPv6 packets) - this has a useful side-effect of allowing you to use that all zeroes address as your default route in a network (no, it will not cause packet duplication, it's ANYcast, not MULTIcast) - do bear in mind though that the host may flip between routers every few seconds, so this isn't appropriate for a stateful firewalling setup if connection tracking isn't synced between them.

   Aside from this, the other major difference is that IPv6 cares about duplicate addresses and dead neighbours (NUD) - thus, unlike IPv4, a host will refuse to use an address if it can determine that another node on the link is already using to it. NUD on the other hand is useful if you're configuring static routes - you can actually define multiple separate routes to a prefix with varying metrics and they will actually work, unlike in IPv4 where the lowest metric route will be used regardless of whether the next-hop is dead or alive (although this may not be true for some IPv4 implementations that use ARP to validate routes like Cisco and other major router vendors)

   TLDR; IPv6 detects duplicate addresses & unreachable neighbours. The all-zero address is all-routers anycast and there's no such thing as broadcast, all-ones is a regular address.

For those wondering where in the specifications the /64 requirement for SLAAC comes from, here are some extra references:

From IPv6 Stateless Address Autoconfiguration (RFC 4862):

If the sum of the prefix length and interface identifier length does not equal 128 bits, the Prefix Information option MUST be ignored. [...]

It is the responsibility of the system administrator to ensure that the lengths of prefixes contained in Router Advertisements are consistent with the length of interface identifiers for that link type.

And from IP Version 6 Addressing Architecture (RFC 4291):

For all unicast addresses, except those that start with the binary value 000, Interface IDs are required to be 64 bits long and to be constructed in Modified EUI-64 format.

Therefore, because the Interface ID must be 64 bits long and the sum of the prefix length and the interface ID length must be 128, the only possible length of the prefix when using SLAAC is 64 bits.

IPv6 is 128 bits, so why is /64 the smallest recommended subnet for hosts?

Because the IPv6 proponents liked the idea of stateless auto configuration.

If you go for any other subnet size then stateless auto configuration will break. Some other minor things may break too, take a read of rfc7421 for more details.

Personally I think stateless autoconfiguration is a dumb idea anyway. It leads to unreadable addresses and gives you no basically no control over addressing beyond assinging the block to the subnet.

Of course the thing with conventions is if you follow them and things go wrong you can point at the convention, if you refuse to follow them and things go wrong it's going to be your fault.

Why is it recommended to use /127 for point to point links between routers,

Using subnets with small numbers of available addresses avoids neighbour discovery exhaustion attacks.

Of course this reasoning doesn't just apply to point to point links. I guess it was politically possible to make this reccomendation for point to point router links but not politically possible to make it for other links.

Why would virtual machines be provisioned with less than a /64 worth of addresses?

We need to make a distinction here. There are two ways a hosting provider can assign addresses to a machine (whether physical or virtual).

They can assign them "on-link" addresses where the machine is expected to reply to neighbour discovery requests. Some hosting providers chose to give each machine a /64 which has advantages in address mobility, others give each VLAN a /64 and then give the individual machines sub-blocks of that which uses less addresses and may mean that local traffic stays local rather than passing up to a router.

Or they can treat the machine as a router and assign it a routed block. In this case it would need enough addresses to address all it's internal subnets. If you follow the "all subnets must be /64" convention that would mean allocating it at least a /64 and possiblly more. This makes sense for machines that have "networks inside the machine", for example a container host.

Can I map directly from IPv4 subnets to IPv6 subnets? For instance, does an IPv4 /24 correspond directly to an IPv6 /56 or /120?

Any such mapping is a matter for local policy.

My interfaces have several IPv6 addresses. Must the subnet be the same for all of them?

No

Why do I sometimes see a % rather than a / in an IPv6 address and what does it mean?

% is an interface identifier. It is used in conjunction with link-local addresses. It is needed as a machine may have multiple interfaces and the networks connected to those interfaces may have overlapping link-local addresses.

Am I wasting too many subnets? Aren't we just going to run out again?

I wouldn't worry about it too much.

Even with the strange decision of the IPv6 designers to use a 128 bit address space and then throw away nearly half of it on stateless auto configuration IPv6 still has massively more space than IPv4.

And if there was a crunch it would take little more than a stroke of a pen to revert that strange decision.

A far bigger concern with IPv6 scalability is routing table size. IPv6 NAT is strongly discouraged. Running a large network on provider-allocated addresses leads to a significant risk of provider lock-in.

So I believe that as IPv6 penetration into corporate networks ramps up we will see an explosion in requests for provider-independent IPv6 space.