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
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
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.
::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.