The premiere source of truth powering network automation. Open and extensible, trusted by thousands.
NetBox is now available as a managed cloud solution! Stop worrying about your tooling and get back to building networks.
IPv6 /127 Prefixes
By stretch | Thursday, May 6, 2010 at 3:36 a.m. UTC
Historically, there has been some debate over the use of /127 prefixes for IPv6 interfaces. Section 3 of RFC 3627 explains how an interface addressed out of a /127 prefix can potentially interfere with IPv6's subnet-router anycast mechanism (as defined in RFC 4291 section 2.6.1):
Using /127 can be especially harmful on a point-to-point link when Subnet-router anycast address is implemented. Consider the following sequence of events:
Router A and Router B are connected by a point-to-point link.
Neither has anything configured or set up on this link.
3ffe:ffff::1/127 address is added to Router A; now it performs Duplicate Address Detection (DAD) [NDISC] for 3ffe:ffff::1. Router A also adds the Subnet-router anycast address 3ffe:ffff::0/127. (DAD is not performed for anycast addresses.)
Now Router B has been planned and configured to use 3ffe:ffff::0/127 as its unicast IPv6 address, but adding it will fail DAD, and Router B does not have any address.
Similar scenarios also happen during router reboots, crashes and such.
The RFC goes on to suggest several solutions to this predicament (foremost of which is to simply use /64 or at most /126 prefix lengths).
On the other side of this argument is a budding Internet draft which defends the use of /127 prefixes on inter-router links, primarily for security reasons (see section 5):
RFC 3627 discourages the use of 127-bit prefix lengths due to conflicts with the Subnet-Router anycast addresses. However, the RFC also states that the utility of Subnet-Router Anycast for point-to-point links is questionable.
RFC 5375 also says the usage of 127-bit prefix lengths is not valid and should be strongly discouraged, but the stated reason for doing this is to be in compliance with RFC 3627.
Given that Subnet-Router Anycast is not currently widely implemented, an alternative solution to this problem could have been to recommend that Subnet-Router Anycast be disabled on prefixes that are 127 bits long.
A quick test confirms that the subnet router anycast address is not implemented on recent IOSes, though attempting to assign the address within a /64 invokes a warning:
R1(config-if)# ipv6 address 2001:db8::/64 %FastEthernet0/0: Warning: 2001:DB8::/64 is a Subnet Router Anycast
Assigning such an address with a /127 mask, however, does not invoke the warning, indicating at least some level of logic with regard to /127 prefixes. This behavior is likely to differ among manufacturers, and possibly among software releases.
Posted in IPv6
Comments
May 6, 2010 at 7:53 a.m. UTC
Given that there are only 2 links available as in any P2P scenario, I would be suggesting that if its possible to implement in the technology, to use the Link-Local as the anycast address.
It would break conventions I guess, but when you only have two links anyway, I don't see that it could cause any problems, as the link-local has the same scope as the global unicast in this scenario, and the same scope as an anycast address too in this very small network (all 2 endpoints of it).
I guess this is similar to the /31 thing for IPv4, /30 wastes addresses but it doesn't break conventions, but /31's are now possible.
May 6, 2010 at 7:17 p.m. UTC
We use /126 for point-to-point links and assign ::1 and ::2 to our hosts.
To resolve the potential problems with ping-pong attacks, we utilize a route server to inject ::0/128 and ::3/128 routes into the table and capture any packets hitting those addresses in a central location.
This yields: (1) all the security of /127s, (2) relatively simple and centralized configuration, (3) ability to see how many IPv6 ping sweeps the network is subject to.
Obviously a large network with LOTS of links will not scale well with this system. Or at least the scope of the /128 routes will need to be limited to avoid unnecessary TCAM utilization.
Another potential solution is to configure /128 static routes on all of the larger aggregation routers. You'll still use memory but hopefully not as much.
One other mitigation technique is to use IP6 ACLs on aggregation routers for downstream links. Not a perfect scenario since it will likely require more time to manage.
May 13, 2010 at 9:43 a.m. UTC
I came to thank you for this amazing site !!
keep it up !
January 21, 2011 at 2:35 p.m. UTC
I suggest that you update this article. IETF currently has a draft in last-call (ready to be adopted as an RFC) that updates this thinking to recommend /127s in point to point links. http://tools.ietf.org/html/draft-kohno-ipv6-prefixlen-p2p-03
January 21, 2011 at 2:48 p.m. UTC
@Wes: Yep, that's a slightly modified revision of the draft already referenced in the article.
April 21, 2011 at 8:16 p.m. UTC
The RFC is out: http://tools.ietf.org/html/rfc6164 Using 127-Bit IPv6 Prefixes on Inter-Router Links
June 3, 2012 at 6:53 p.m. UTC
What about to use something like:
::3/127 and ::4/127 for point-to-point
The first address with all host-bits equal to 0 (::) is reserved for anycast and the "second" subnet block /127 is used to p2p links.
March 18, 2013 at 4:09 p.m. UTC
@Me: A little late but the answer is no for two reason.
Maybe you allready know why if you have tested it.
The first is: :3/127 and :4/127 are not on the same network.
The second is: in /127 the host bit is only the last bit and in :4 this bit is 0, so it could be the subnet router address like with :0.
And the last RFC say that this is not a problem so you don't have to find anoter way.