Addressing IPv6 Serial Links – /64 or /126?

What is the proper subnet to assign to an IPv6 serial links?

The standards say that every single network segment should get a full /64 regardless of how small or large the segment is in terms of the number of hosts requiring addresses.  This makes good sense, particularly because the /64 boundary was designed according to the specifications for Stateless Address Auto-Configuration (SLAAC).

In SLAAC, an interface can auto-configure its own IP address using its layer 2 MAC address.  MAC addresses more or less globally unique, at least on a single network segment.  Interfaces employing SLAAC take the 48-bit MAC address and insert FF FE hex characters in the middle between the 3^rd and 4^th bytes to create a 64-bit address.

This is known as the Extended Unique Identifier 64 (EUI-64) standard.  For example, take the following MAC address:

00-05-9a-3c-78-00

Insert the “ff fe” in the middle and it becomes…

00-05-9a-ff-fe-3c-78-00

Now switch to IPv6 notation using colons and it becomes…

0005:9aff:fe3c:7800

To complete the address it is necessary to flip the 7^th bit in the first octet (known as the U/L or “universal” bit), which when set to 1 means the address has been locally administered and is overriding the manufactured address.  In this example, this changes the first octet from 00 to 02 providing the following IPv6 address…

0205:9aff:fe3c:7800

The automatically configured IPv6 address can be used as a link-local address with the fe80::/64 prefix:

fe80::0205:9aff:fe3c:7800

The address can also be used as the interface’s unique local address (ULA) or global (public) address, with the ULA or global prefix provided by the host’s local router.

Aside from SLAAC, which is probably the most important reason for the /64 subnet size, there are also the additional benefit of simplifying a network’s configuration.

Consistency in the subnet size effectively eliminates variable length subnet masking (VLSM) and the issues that come with it.  IPv6 in general almost, but not quite, eliminates subnetting altogether.  Of course, VLSM is absolutely critical and necessary in IPv4 networking where we are concerned with address conservation and may need to address a network with a limited pool of addresses.  We have done VLSM for so long now that we take it for granted.  We are so used to VLSM now that we can see CIDR prefixes in our sleep and immediately calculate the number of hosts on the subnet and maybe even the inverse mask, but still, errors can and do occur at times.

Configuration errors that stem from VLSM can lead to:

• filtering traffic that should be permitted
• permitting traffic that should be filtered
• BGP accepting or rejecting routes incorrectly
• overlaps or gaps in network advertisements in routing protocol configurations
• traffic blackholes
• security holes
• network outages when any of the above occurs in a severe manner.

Adhering to the /64 standard almost completely eliminates thinking about subnets at all, and certainly eases network configuration which should lessen the chance of the risks detailed above.

IPv6 designers understood that the address space is so incredibly large and effectively infinite in its practical application to networks and devices.  (Just think about the many analogies you’ve heard about IPv6 address space, such as how many grains of sand or stars in the universe you could address).  The old rules and thinking do not apply.

But it may take some time for that to sink in with the majority of the networking community.  Most networkers familiar with IPv6 know about the /64 subnet recommendation.  Yet it may still be difficult for some to come to grips with assigning a subnet that is the size of the entire IPv4 Internet squared to every single network regardless of how small, even a serial link with two endpoint hosts.  A full /64 seems excessive and a waste of address space.

Although it seems like the debate is over and /64 is the accepted standard, I have read some discussions of assigning /126 subnets to serial links, not unlike how we (necessarily) assign /30 subnets to IPv4 serial links.  The only reason I can find that one would do this would be to conserve address space, something that is not really necessary in IPv6.  Perhaps someone who is assigned only a single /64 but has a need to subnet further would need to consider subnetting beyond the /64 boundary.

But I’ve also read arguments where all IPv6 serial links could be assigned a /126 subnet from the same /64, aggregating all serial links together.  While that may seem like a reasonable approach, it would seem to come with the following tradeoffs:

• Lumping all serial links into the same /64 subnet with the intent of summarizing them into a single block may only work in smaller, relatively flat networks.  Larger networks with regional aggregation governed by OSPF areas or BGP confederations would desire to have the addresses assigned to the region summarized.  By assigning all serial links into a single /64, you might end up carrying /126 serial link routes all over your network.  Although this wouldn’t be different from a routing table size than carrying all /64 serial link routes through the network, it would clutter your routing table and potentially lead to errors.
• By deviating from the /64 standard, you may be setting yourself up for the  configuration errors previously discussed and often seen in IPv4 network, particularly since it will be a long while for people to get used to the IPv6 hexadecimal – and sometimes truncated – addressing nomenclature.

In summary, it seems that the only benefit to providing a more specific prefix than /64 to serial links is the address space that it conserves.  But in the IPv6 world, address conservation is really a moot point.  Remember, that was basically why it was designed in the first place.

Note: This entire post can apply to loopback addresses as well, whether they should also be provided with the standard /64 or a /128, just as we configure a /32 single host subnet for IPv4 loopbacks.

It should be noted that this topic could apply to using /127 subnets on serial links, with the first address for one side of the link and the second for the other side.  However, RFC 3627 discusses issues that may occur when assigning /127 subnets to serial links with respect to Anycast and the negative affects that may occur.  It may not occur in every environment, but if there is even a slight risk in deploying a /127 it would be wise to not do so.  At a minimum, the fall back would be to a /126 with the 2nd and 3rd addresses used for either end of the link.  It would be hard to understand why someone would be so hardpressed on address space or any other reason to be forced to use a /127 instead of a /126.  RFC 3627 also briefly discusses the possiblity of assigning individual /128s on either end of the link, but that this would be a cumbersome process wrought with its own issues and also subject to the previous logic of just using a /126 or shorter prefix even if you can’t afford to use a /64.

Furthermore, RFC 3627 discusses issues that occur in Mobile IPv6 with prefixes longer than /64.  This is not limited to just /127s but applies to /126 subnets and other longer prefixes.  Again, given that there is even slight risk involved, it does not seem to make sense to use anything but /64 subnets even for simple two-host point-to-point links, unless there is a serious situaton where, for whatever reason, there is no other choice.  Given the large amount of IPv6 address space, it is hard to envision such a scenario occurring very often.

 

What are your thoughts on this?

Should network designers always stay with the /64 standard?

Are there any other benefits besides address conservation to using longer masks for serial links?

Is there any real reason to be cautious about the wasted space in a /64 when applied to a serial link, or is that just old fashioned IPv4-based thinking?

Can you provide an example where /126 subnetting was used effectively, without causing confusion or configuration errors and, better yet, was either the better solution than /64 or the only solution?

What about loopbacks?  Is there any merit to assigning loopbacks a /128 mask?

Advertisement