Skip to main content

The Case for the /127 Subnet - Part II

July 01, 2014

In the last post we talked about misplaced worry when it comes to wasting subnet addresses. Some of that worry stems from RFC memos on the topic.

Here’s some background: RFC 4291, Section 2.5.4, explicitly states that the IPv6 Interface-ID is /64 for all global unicast addresses. It doesn’t say “except if you’re worried that you’re being wasteful.”

And just to make things clearer for folks that were insisting on using /127s on point-to-point links, we had RFC 3627 that says, right in the title, “Use of /127 Prefix Length Between Routers Considered Harmful.”

Then along comes RFC 6164 that says the use of /127 prefixes on point-to-point links is just fine and dandy after all. In fact, RFC 6547 moves 3627 to historical (obsolete) status, superseded by 6164.

Confused yet? It’s really not that complicated.

RFC 3627 Is Obsolete for Good Reason

The main justification for the RFC 3627’s conclusion that /127 prefixes are harmful has to do with Subnet-Router Anycast addresses. These are addresses in which the prefix is intact, but the Interface-ID bits are all set to zero. So the address is scoped to a specific subnet by the prefix, but the identity portion of the address is unspecified. A device can send packets to the Subnet-Router Anycast address and they will be picked up by a router attached to the subnet. RFC 4291 requires that routers support the Subnet-Router Anycast address. The idea is that an application can use this address to communicate with “any one of the set of routers” on a subnet, although it isn’t made clear why an application would use this Anycast rather than the All-Routers multicast address.

Here’s the scenario that supposes /127 prefixes to be harmful:

  • You connect two routers, RA and RB, with a point-to-point link.
  • You configure RA’s interface with address 2001:db8:1:2:a:b:c:1/127. The router runs Duplicate Address Detection (DAD) on the link for this address, and the address passes.
  • RA, in compliance with RFC 4291, adds the Subnet-Router Anycast address 2001:db8:1:2:a:b:c:0/127. RFC 2462, Section 5.4, specifies that DAD is not run for Anycast addresses (which makes sense, because by definition an Anycast address can reside on more than one interface). So no DAD is run for this address.
  • Now you go to RB and configure the other address for that /127 prefix: 2001:db8:1:2:a:b:c:0/127. Does the router object that it cannot use that address as its unicast, because it’s the Subnet-Router Anycast address for that prefix? Does it accept the address and then add the same address as its required Subnet-Router Anycast? If it does, and performs a DAD, the address will fail because it already is on RA.

That sounds like a big problem, but there’s a couple of things to know:

  • Subnet-Router Anycast, as vague as its purpose appears, clearly is for use on a multi-access network. Why would it ever be used on a point-to-point link?
  • Even though RFC 4291 makes the address mandatory, the fact is that it isn’t very widely implemented. Even RFC 3627, after laying out the above scenario, acknowledges that it hasn’t been observed in the wild. I’ve configured many /127 addresses and have yet to have a problem with it.

DAD is useful for Address Autoconfiguration mechanisms and for Neighbor Discovery Protocol, both of which have limited utility on point-to-point links. An easy bit of insurance, if your router operating system supports it, is to disable DAD on your point-to-point links. Many point-to-point technologies such as SONET do not use NDP, but if you are using Ethernet for point-to-point links, you probably will need to manually disable NDP.

Read the next post in this series.

Note: This post originally appeared on Network World article titled “The Case for /127 Subnets.”

Related Blogs

October 20, 2015

Check Point Kernel Debugging, In-Depth

The following is a look into the features and inner-workings of debugging the Check Point firewall kernel. This information will prepare you to debug ...

See Details

June 01, 2015

Vulnerabilities in Bluecoat SSL Visibility Appliances

Last Friday, Bluecoat and CERT published security advisories for vulnerabilities in the administrative interface of the Bluecoat SSL Visibility Applia...

See Details

May 04, 2015

How Not To Prevent CSRF in a RESTful Service

Last Friday, Bluecoat and CERT published security advisories for vulnerabilities in the administrative interface of the Bluecoat SSL Visibility Applia...

See Details

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.


Privacy Policy

RELATED INSIGHTS

August 24, 2017

Enterprise Incident Management Brief

Learn how Optiv’s workshop helps security leaders evolve their technical incident response practices to broad scope enterprise incident management.

See Details

July 02, 2014

The Case for the /127 Subnet - Part III

When we left off in the previous post, we were discussing disabling NDP on Ethernet point-to-point links when using /127 prefixes. But there is anothe...

See Details

June 30, 2014

The Case for the /127 Subnet - Part I

In my previous post I wrote about all the positives we get from the almost incomprehensibly massive IPv6 address space, all there for our enjoyment if...

See Details

Stay in the Know

For all the latest cybersecurity and Optiv news, subscribe to our blog and connect with us on Social.

Subscribe

Join our Email List

We take your privacy seriously and promise never to share your email with anyone.

Stay Connected

Find cyber security Events in your area.