On a recent post, IPv6 – /48 allocation in /64 chunks – that’s a lot of addresses a couple of people commented that a /64 is wasteful. That’s a lot of address space to allocate to just two devices – IPv6 addresses are 128 bits long, compared to 32 bits long for IPv4. In other words, IPv6 addresses are 2^96 times more numerous than IPv4 addresses.

Let me attempt a counter argument by making some points:

Simplicity

The single greatest problem to IPv6 adoption is perceived complexity. Therefore, to help people migrate to IPv6 it’s important to make it as simple as possible. This includes first line support at a Service Provider, and the home user, the guy in desktops who doesn’t want to learn anything. Therefore, the make the migration simpler, the a consistent mask makes adoption easier.

Route Summarisation

The ability of network devices to hold an IPv6 routing table may be limited. For example, although some routers proclaim support for IPv6 they may do so in software only, and for limited numbers of routes. An IPv6 route consume four times more memory than IPv4 routes & it may not be desirable to update routers immediately. Therefore a /64 plan makes for better, more comprehensible route summarisation during the early phase of adoption by virtue of using a single netmask and easier to deploy summarisation. This argument is doubly true for systems using TCAM memory for hardware forwarding.

Breaking IPv6

Simply put, the use of less than /64 breaks many features of IPv6 and will require manual workarounds to resolve, the most inconvenient of which is Neighbour Discovery and would require manual neighbour (think Inverse ARP from IPv4)† configuration unless the network device has features to otherwise compensate.

The following is taken from RFC 5375 –
IPv6 Unicast Address Assignment Considerations

Using a subnet prefix length other than a /64 will break many features of IPv6, amongst other things Neighbor Discovery (ND), Secure Neighborship Discovery (SEND) [RFC3971], privacy extensions [RFC4941], parts of Mobile IPv6 [RFC4866], PIM-SM with Embedded-RP [RFC3956], and SHIM6 [SHIM6]. A number of other features currently in development, or being proposed, also rely on /64 subnet prefixes.

Nevertheless, many IPv6 implementations do not prevent the administrator from configuring a subnet prefix length shorter or longer than 64 bits. Using subnet prefixes shorter than /64 would rarely be useful; see Appendix B.1 for discussion.

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

And appendix B1 states:

B.1. Considerations for Subnet Prefixes Shorter than /64

An allocation of a prefix shorter then 64 bits to a node or interface is considered bad practice. One exception to this statement is when using 6to4 technology where a /16 prefix is utilized for the pseudo-interface [RFC3056]. The shortest subnet prefix that could theoretically be assigned to an interface or node is limited by the size of the network prefix allocated to the organization.

A possible reason for choosing the subnet prefix for an interface shorter than /64 is that it would allow more nodes to be attached to that interface compared to a prescribed length of 64 bits. The prescribed /64 does include 2 functional bits, the ‘g’ bit and the inverted ‘u’ (universal/local) bit and these can not be chosen at will. However, a larger address space then a /64 is unnecessary for most networks, considering that 2^62 provides plenty of node addresses.

The Argument Rages

The debate around the policy of address allocation continues to go on and as this Cisco Chalk Talk from October 2008 points out:

While in certain circumstances a /64 assignment per link might be easier to accept, the address space conservationists become outraged when it comes to assigning a /64 to point-to-point links or device loopback interfaces. Typically one finds many point-to-point links throughout the infrastructure, for example, in data centers or between routers. The number of point-to-point links can add up quickly, leading to significant use of address space.

Using /64s everywhere provides the benefit of consistency and makes prefix allocation and aggregation easier and cleaner. Using shorter prefix lengths does not make sense since a /64 provides more IIDs than might be healthy for any layer two broadcast domain. Longer /64 prefixes are; however, considered a fair, if not responsible, choice by many and so, in real deployments, people purposefully ignore the requirement of RFC 4291. A good example is using /126 for point-to-point links and /128 for loopback addresses.

Addressing schemes that go for per link prefix lengths different than /64 do need to be mindful of any possible conflicts with the existing standards and challenges with stack implementations. Such conflicts are discussed in draft-ietf-v6ops-addcon.

There are other practical considerations for the resistance to the requirement to use /64 prefixes per link, such as security concerns for point-to-point links. In general; however, it comes down to a debate between simplification of addressing and conservation of resources. This debate is ongoing, so it is important to monitor its evolution in IETF.

Conventions Exist

Conventions and recommendations exist for a reason. And while it always good to challenge the status quo, I agree with the current recommendation based on my reading and research which I’ve attempted to summarise here. In the longer term, I can see that it may change but during the first few years the /64 address allocation makes good sense. Hopefully, I’ve outlined at least some of the reasons why using /64 is good practice and outweighs the possibly wasteful practice /64 allocation.

In terms of the wastefulness, while I agree we may regret the decision in the long term this seems highly unlikely and a lesser concern that adoption and migration today. I would balance this against the success of IPv4 over the last forty years and the fact that IPv6 is likely to last for 100 years or more. I can ‘fix’ IPv6 in the years ahead, but I can’t fix IPv4 today. Not happy about it, but I can live with a balanced decision that manages my immediate priorities.

I look forward to hearing other peoples opinions.

Other Posts in This Series

1. Why Allocating a /64 is Not Wasteful and Necessary (23rd January 2011)
2. IPv6 - /48 allocation in /64 chunks - that's a lot of addresses (21st January 2011)
3. IPocalypse: What's next for the 'End of the Internet' ? (20th January 2011)
4. The IPocalyse is Nigh - Forced Allocation of IPv4 to RIRs next week ? (19th January 2011)
5. IETF IPv6 address allocation policy being updated. (12th January 2011)
6. Scheduling the IPocalypse (25th November 2010)