Why Allocating a /64 is Not Wasteful and Necessary

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 296 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 A Series On The Same Topic

  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)
  • http://standalone-sysadmin.com MATT SIMMONS

    I think that the reason people are freaking out is mostly psychological. The human mind didn’t evolve to deal with numbers like this. We evolved from animals that really only had to deal with things a little smaller than an ant, and about as large as a mountain. Anything much beyond that is past our “natural” scale, and we have to start using analogies that we can relate to, like grains of sand.

  • http://cagnazzo.name Carlos Martinez

    I still believe a /64 per LAN is just too much. In fact, if we were using 48 bit host addresses (a /80 per LAN) it would, for all practical purposes, be as secure and as abundant as a /64, and would allow more room for efficient allocation within regions, countries and organizations.

    In fact, making the host boundary match L2 address length hast IMO a nice appeal :-)

  • Josh

    How about using private /64 addresses for router P2P links (where possible obviously). Wouldn’t this sufficiently solve the complexity issue while avoiding the “waste” of using public /64 subnets for P2P links?

    • Rodrigo

      Using private address space on Internet P2P links – this has been a bad practice in IPv4 and is not going to change with IPv6 – still a very bad idea IMO.

      Actually I don’t even see the need for using private address space in a production network/environment, even if your company network doesn’t have and will never (never say never) have a connection to the Internet. IMO companies should all be able to request their own public space.

      Speaking of waste I wish IPv6 headers had no Flow Label (I doubt it will have any real practical usage) and instead a 2 byte Traffic Class field and leave the rest of the bits ‘reserved for future use’, but no… somehow developers will always bring nostalgia into the equation (remember the initial purpose of TOS bits?)

      • http://etherealmind.com Greg Ferro

        Hi Rodrigo

        Yeah I can see your point about IPv6 headers, but remember that an IPv6 packet can have multiple headers and they can be chained, therefore it you can have additional cost fields in a secondary header. While this seems wasteful today as bandwidth increase over the next 10 to 30 years I think it’ll be a different matter and it won’t be so much of a problem.

        The purpose of the fixed IP V6 header is to improve silicon switching performance in the router core of the future. At least until someone thinks, is hoping that the header structure is flexible enough to meet whatever we want in the future.

  • Matthew

    Weren’t similar thoughts had about the IPv4 address space and original allocation rules?

    • http://etherealmind.com Greg Ferro

      No, the IPv4 address allocation was because there was no concept of address masking in 1980-ish. The use of subnet masks (or Classless Inter Domain Routing) didn’t appear until much later. You could make the point that IP was only successful in the early days because it was kept simple, and the complexity came later when it was needed.

      I think the current view is that /64 addressing is an acceptable trade off for easier adoption today. Ultimately, the IPv6 Space is so large that we will be sacrificing less than 1% for a few years to make the transition smoother and easier. And I think that matters from a business point of view, we need to make the transition as practical as possibleñand that means cheaper, simpler, realistic where we can.

  • Dave

    I don’t necessarily agree with the “people are too dumb” reasoning for /64 subnets…  I, like many others, think that it’s offly short sighted to automatically cut off half of the space.  This is also neglecting what the real reasons for not moving to v6, and that is simply money…there is no business case for 90% (at least) of companies to move to v6. 

    It’s not even fully supported by vendors yet, so why would we think that enterprises would move to it?  You can’t even implement a single stack v6 enterprise network right now (using Cisco equipment)…trust me I’m working on it.  We are having to look at other vendors products, which increases the time and cost of implementing something that doesn’t actually *need* to be done.

  • http://lippard.blogspot.com/ Jim Lippard

    I’ve been experimenting with IPv6 on a home network with multiple routed networks, and it barely works at all with prefix lengths greater than 64.  Stateless auto-configuration doesn’t work (no room for the EUI-64 to fit), and while assigning static addresses allows hosts to successfully connect with each other and the IPv6 Internet, neighbor discovery and router advertisement fails for the external IP addresses (sometimes in odd ways), and so neighbors don’t recognize that they’re on the same LAN and send all their traffic through the router.  If you’re using a firewall, that means for that traffic to get through you have to allow things you’d really want to block with antispoofing rules on the LAN interface.