RFC 6164

Using 127-Bit IPv6 Prefixes on Inter-Router Links

📅 published April 2011, from ietf

okay bestie, this one is about 127-bit IPv6 prefixes on inter-router point-to-point links 🦋 It's written by M. Kohno (Juniper Networks and Keio University), B. Nitzan (Juniper Networks), R. Bush, Y. Matsuzaki (both Internet Initiative Japan), L. Colitti (Google), and T. Narten (IBM Corporation). It's a Standards Track document, it's from the ISSN 2070-1721 series, and the date is April 2011. The title block doesn't list anything it obsoletes or updates, so it's standing on its own 💅

Here's the full table of contents, as the original has it:

1. Introduction ....................................................2
2. Scope of This Memo ..............................................3
3. Conventions Used in This Document ...............................3
4. Problems Identified with 127-Bit Prefix Lengths in the Past .....3
5. Reasons for Using Longer Prefixes ...............................4
   5.1. Ping-Pong Issue ............................................4
   5.2. Neighbor Cache Exhaustion Issue ............................4
   5.3. Other Reasons ..............................................5
6. Recommendations .................................................5
7. Security Considerations .........................................6
8. Contributors ....................................................6
9. Acknowledgments .................................................6
10. References .....................................................6
   10.1. Normative References ......................................6
   10.2. Informative References ....................................7

Abstract ✨

okay so on inter-router point-to-point links (two routers, one wire, zero hosts, just vibes between them 🫶), it's actually really useful to use 127-bit IPv6 prefixes, for security and other reasons. It's the same energy as using 31-bit prefixes in IPv4 💜 This doc lays out why you'd do it and how the 127-bit IPv6 prefix lengths get used on those links.

Status of This Memo 📋

This is an Internet Standards Track document.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 5741.

You can find out the current status of this document, any errata, and how to send feedback on it at http://www.rfc-editor.org/info/rfc6164.

Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they stand on the date this document was published. Please read these carefully, because they spell out your rights and restrictions when it comes to this document. Code components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License.

1. Introduction 💖

[RFC4291] says that interface IDs for all unicast addresses are required to be 64 bits long and built in Modified EUI-64 format, except for the ones that start with the binary value 000. It also defines the Subnet-Router anycast address, which is meant for situations where a node needs to talk to any one of the routers on a link 🧚

Some operators have been running 127-bit prefixes anyway, even though it's been discouraged because of conflicts with Subnet-Router anycast [RFC3627]. But 64-bit prefixes cause security issues that are especially annoying on inter-router links, and there are other good reasons to go longer than 64 bits, especially /127 (see Section 5) 😤

This document explains why 127-bit prefix lengths make sense, takes another look at why they were called harmful, and spells out how /127 prefixes can be used on inter-router links that are set up as point-to-point links 🌸

2. Scope of This Memo 🦋

This document applies to cases where operators give specific addresses to inter-router point-to-point links and don't rely on link-local addresses. A lot of operators assign specific addresses for network monitoring, reverse DNS lookups for traceroute and other management tools, External Border Gateway Protocol (EBGP) [RFC4271] peering sessions, and so on 🍓

For this document, an inter-router point-to-point link is a link with only two routers attached and no hosts. This can include Ethernet links that are configured to be point-to-point. Links between a router and a host, or links where both routers and hosts are attached, are out of scope here 🙅‍♀️

The recommendations in this document don't apply to the link-local address scope.

3. Conventions Used in This Document 📖

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

4. Problems Identified with 127-Bit Prefix Lengths in the Past 🕰️

[RFC3627] discourages using 127-bit prefix lengths because they conflict with the Subnet-Router anycast addresses. It also says that the usefulness of Subnet-Router anycast for point-to-point links is questionable 🤔

[RFC5375] also says that using 127-bit prefix lengths is not valid and should be strongly discouraged. The only reason it gives is to comply with [RFC3627] 🙄

The analyses in those RFCs are correct, but operational experience with IPv6 has shown that /127 prefixes can be used successfully 💅

5. Reasons for Using Longer Prefixes 👑

Network operators have real reasons to use IPv6 prefix lengths greater than 64, especially 127, for inter-router point-to-point links.

5.1. Ping-Pong Issue 🏓

A forwarding loop can happen on a point-to-point link with a prefix length shorter than 127. This doesn't affect interfaces that do Neighbor Discovery. But some point-to-point links, which use a medium like the Synchronous Optical Network (SONET), don't do Neighbor Discovery. So configuring any prefix length shorter than 127 bits on these links can create an attack vector in the network 😭

The ping-pong issue happens with IPv4 too. But IPv4 address space is scarce, so the current practice is to assign long prefix lengths like /30 or /31 [RFC3021] on point-to-point links. That's why the problem never really came to the fore 🙈

The latest ICMPv6 specification [RFC4443] fixes this by saying that a router which gets a packet on a point-to-point link, where the packet is destined for an address within a subnet assigned to that same link (other than one of the receiving router's own addresses), MUST NOT forward the packet back on that link. Instead, it SHOULD generate an ICMPv6 Destination Unreachable message (code 3) in response. This check sits on the forwarding processing path, so it may have a performance impact ⚡

5.2. Neighbor Cache Exhaustion Issue 🧊

As described in Section 4.3.2 of [RFC3756], using a 64-bit prefix length on an inter-router link that uses Neighbor Discovery (e.g., Ethernet) can allow denial-of-service attacks on the routers on that link. Yikes 😬

Picture an Ethernet link between two routers, A and B, with a /64 subnet assigned to it. A packet sent to any address on that /64 (except the addresses of A and B) will make the router trying to forward it create a new cache entry in INCOMPLETE state, send a Neighbor Solicitation message on the link, start a retransmit timer, and so on [RFC4861].

Now imagine an attacker sends a continuous stream of packets to a bunch of the 2^64 - 3 unassigned addresses on the link (one for each router and one for Subnet-Router anycast). That creates a huge pile of neighbor cache entries and makes one of the routers send a ton of Neighbor Solicitation packets that never get replies. Memory and processing resources get eaten up fast 💀 Sending packets to one of the 2^24 addresses on the link that shares the same Solicited-Node multicast address as one of the routers also makes the victim burn a lot of processing time throwing away useless Neighbor Solicitation messages.

Careful implementation and rate-limiting can limit the damage from this attack, but they're unlikely to stop it completely. Rate-limiting Neighbor Solicitation messages will reduce CPU usage, and following the garbage-collection recommendations in [RFC4861] will keep reachability going. But if the link goes down and the neighbor cache entries expire while the attack is still happening, legitimate traffic (for example, BGP sessions) over the link might never come back up, because the routers can't resolve each other's IPv6 addresses to link-layer addresses 😵

This attack isn't specific to point-to-point links, but it's especially harmful on point-to-point backbone links, which may carry large amounts of traffic to many destinations over long distances 🌍

There are a number of ways to mitigate this kind of issue, but assigning /127 subnets eliminates it completely 🫶✨

8. Contributors 🫶

Shoutout to these four legends who helped build this doc:

  • Chris Morrow, morrowc@google.com 💖
  • Pekka Savola, pekkas@netcore.fi 🌸
  • Remi Despres, remi.despres@free.fr 🦋
  • Seiichi Kawamura, kawamucho@mesh.ad.jp ✨

9. Acknowledgments 💜

The authors want to thank Ron Bonica, Pramod Srinivasan, Olivier Vautrin, Tomoya Yoshida, Warren Kumari, and Tatsuya Jinmei for their helpful inputs. Literally the whole squad showed up for this one 👑🥹

10. References 📚

10.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC4291]  Hinden, R. and S. Deering, "IP Version 6 Addressing
           Architecture", RFC 4291, February 2006.

[RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
           "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
           September 2007.

10.2. Informative References

[RFC2526]  Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast
           Addresses", RFC 2526, March 1999.

[RFC3021]  Retana, A., White, R., Fuller, V., and D. McPherson,
           "Using 31-Bit Prefixes on IPv4 Point-to-Point Links",
           RFC 3021, December 2000.

[RFC3627]  Savola, P., "Use of /127 Prefix Length Between Routers
           Considered Harmful", RFC 3627, September 2003.

[RFC3756]  Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6
           Neighbor Discovery (ND) Trust Models and Threats",
           RFC 3756, May 2004.

[RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
           Border Gateway Protocol 4 (BGP-4)", RFC 4271,
           January 2006.

[RFC4443]  Conta, A., Deering, S., and M. Gupta, Ed., "Internet
           Control Message Protocol (ICMPv6) for the Internet
           Protocol Version 6 (IPv6) Specification", RFC 4443,
           March 2006.

[RFC5375]  Van de Velde, G., Popoviciu, C., Chown, T., Bonness, O.,
           and C. Hahn, "IPv6 Unicast Address Assignment
           Considerations", RFC 5375, December 2008.

Authors' Addresses 🏠

Miya Kohno
Juniper Networks, Keio University
Shinjuku Park Tower, 3-7-1 Nishishinjuku
Shinjuku-ku, Tokyo  163-1035
Japan

EMail: mkohno@juniper.net


Becca Nitzan
Juniper Networks
1194 North Mathilda Avenue
Sunnyvale, CA  94089
USA

EMail: nitzan@juniper.net


Randy Bush
Internet Initiative Japan
5147 Crystal Springs
Bainbridge Island, WA  98110
USA

EMail: randy@psg.com


Yoshinobu Matsuzaki
Internet Initiative Japan
Jinbocho Mitsui Building
1-105 Kanda Jinbo-cho, Tokyo  101-0051
Japan

EMail: maz@iij.ad.jp


Lorenzo Colitti
Google
1600 Amphitheatre Parkway
Mountain View, CA  94043
USA

EMail: lorenzo@google.com


Thomas Narten
IBM Corporation
3039 Cornwallis Ave.
PO Box 12195
Research Triangle Park, NC  27709-2195
USA

EMail: narten@us.ibm.com
📦 where this page comes from