RFC 5095

Deprecation of Type 0 Routing Headers in IPv6 🎀

okay bestie, this is RFC 5095 💅 It's a Standards Track doc from December 2007, and it's basically the IETF going "we're officially killing this feature." It was written by Joe Abley (Afilias), Pekka Savola (CSC/FUNET), and George Neville-Neil (Neville-Neil Consulting). It updates [RFC2460] (the IPv6 spec) and [RFC4294] (IPv6 Node Requirements) 🌸 It doesn't say it obsoletes anything, so there's no Obsoletes line in the header.

Status of This Memo ✨

this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 🫶 for the official standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1). distribution of this memo is unlimited, so share the tea 🍓

Abstract 🦋

okay so IPv6's Type 0 Routing Header can be abused to amplify traffic across a remote path, which means it can be used to make denial-of-service traffic 😭 because of that security concern, this document updates the IPv6 spec to deprecate Type 0 Routing Headers. it's giving "this feature is retired" 💀

Table of Contents 📋

1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.  Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.  Deprecation of RH0  . . . . . . . . . . . . . . . . . . . . . . 3
4.  Operations  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
  4.1.  Ingress Filtering . . . . . . . . . . . . . . . . . . . . . 3
  4.2.  Firewall Policy . . . . . . . . . . . . . . . . . . . . . . 3
5.  Security Considerations . . . . . . . . . . . . . . . . . . . . 4
6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . 4
8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 5
  8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 5
  8.2.  Informative References  . . . . . . . . . . . . . . . . . . 5

1. Introduction 🌈

okay so [RFC2460] defines an IPv6 extension header called "Routing Header", and its Next Header value is 43 in the header right before it 🧚 there's a specific subtype called "Type 0" too. in this doc we call Type 0 Routing Headers "RH0" for short, bestie 💖

here's the drama: a single RH0 can hold multiple intermediate node addresses, and the same address can show up more than once in one RH0 🙈 so an attacker can build a packet that bounces between two RH0-processing hosts or routers over and over. that means a stream of attacker packets gets amplified along the path between two remote routers, which can cause congestion along arbitrary remote paths. that's a denial-of-service move 💀 an 88-fold amplification was demonstrated with this technique [CanSecWest07], which is absolutely unhinged ✨

this one is extra serious bc it hits the whole path between the two exploited nodes, not just the nodes themselves or their local networks 😭 the IPv4 source route option has a similar vibe, but RH0 is worse because you can specify way more intermediate node addresses in each packet 🔥

the threat is serious enough to justify deprecating RH0 entirely 💅 the side effect is that benign RH0 use cases get wiped out too. future Routing Header specs might make those things possible again 🦋

potential RH0 problems were identified in 2001 [Security] 🌸 in 2002 someone proposed restricting Routing Header processing in hosts [Hosts]. those efforts led to Mobile IPv6 using the Type 2 Routing Header instead of RH0 [RFC3775] 🎀 then in 2006, Vishwas Manral flagged various RH0 risks including the amplification attack, and several of these vulnerabilities (plus other issues) were later written up in [RFC4942] 📚

Philippe Biondi and Arnaud Ebalard gave a talk on the operational security side of RH0 at the CanSecWest conference in Vancouver in 2007 [CanSecWest07] ⭐ that presentation got RH0 risks tons of publicity 😭

this document updates [RFC2460] and [RFC4294] 💜

2. Definitions 🎀

RH0 in this document means the IPv6 Extension Header type 43 ("Routing Header") variant 0 ("Type 0 Routing Header"), as defined in [RFC2460] 💅

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 [RFC2119] 🫶

3. Deprecation of RH0 🚫

okay this is the main rule ✨ an IPv6 node that gets a packet addressed to itself, and that packet has an RH0 extension header, MUST NOT run the algorithm from the latter part of Section 4.4 of [RFC2460] for RH0. instead, the packet MUST be handled the way Section 4.4 of [RFC2460] handles a datagram with an unrecognized Routing Type value 🦋 the original rules say:

If Segments Left is zero, the node must ignore the Routing header and proceed to process the next header in the packet, whose type is identified by the Next Header field in the Routing header. If Segments Left is non-zero, the node must discard the packet and send an ICMP Parameter Problem, Code 0, message to the packet's Source Address, pointing to the unrecognized Routing Type.

IPv6 implementations are no longer required to implement RH0 in any way 🎉 so basically RH0 is officially off the menu 💀

I'll keep the convo going next time bestie 🫶 there's more in the operations and security parts, so stay tuned 💖

Intellectual Property 💅

okay so, the IETF is not saying whether any patents or other IP rights apply to the tech in this doc, or whether anyone can actually get a license for them 🙈 they also didn't go hunting for any of that stuff themselves. if you want the rules on rights in RFC docs, check out BCP 78 and BCP 79 📚

if you're an implementer or user and you want to see disclosures that were filed with the IETF Secretariat, the license assurances people promised, or what happened when someone tried to get a general license or permission for the proprietary rights, the place to look is the IETF online IPR repository at http://www.ietf.org/ipr 🔍

and if you know about any copyrights, patents, patent applications, or other proprietary rights that might cover tech you'd need to implement this standard, please tell the IETF about it at ietf-ipr@ietf.org 📬 the IETF really wants to hear from you, bestie 🫶✨