RFC 9098

Operational Implications of IPv6 Packets with Extension Headers

📅 published September 2021, from ietf

Part 1 of 4: Operational Implications of IPv6 Packets with Extension Headers ✨

Okay bestie, this is RFC 9098 💖 It's an IETF document (Request for Comments: 9098) titled Operational Implications of IPv6 Packets with Extension Headers, published in September 2021. It's Informational, which means it's published for information and is not an Internet Standards Track spec. The ISSN is 2070-1721.

Six people wrote it: F. Gont from SI6 Networks, N. Hilliard from INEX, G. Doering from SpaceNet AG, W. Kumari from Google, G. Huston from APNIC, and W. Liu from Huawei Technologies. The title block doesn't list anything it obsoletes or updates, so there's nothing to chase there 🌸

Abstract

This doc sums up the operational implications of IPv6 extension headers, which are defined in the IPv6 protocol spec (RFC 8200). It also tries to figure out why packets with IPv6 extension headers keep getting dropped on the public Internet 👀

Status of This Memo

This document is not an Internet Standards Track specification. It's published for informational purposes 🎀

It's a product of the IETF, and it represents consensus across the IETF community. It went through public review and was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is a candidate for any level of Internet Standard, so check Section 2 of RFC 7841 if you want the details 🧐

For the current status, any errata, and a way to send feedback, go to https://www.rfc-editor.org/info/rfc9098.

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

This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents, at https://trustee.ietf.org/license-info, as they stand on the publication date. Please read those carefully, because they spell out your rights and restrictions for this document. Code components pulled out of this doc must include the Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as the Simplified BSD License describes 📜

Table of Contents

  • 1. Introduction
  • 2. Terminology
  • 3. Disclaimer
  • 4. Background Information
  • 5. Previous Work on IPv6 Extension Headers
  • 6. Packet-Forwarding Engine Constraints
    • 6.1. Recirculation
  • 7. Requirement to Process Layer 3 / Layer 4 Information in Intermediate Systems
    • 7.1. ECMP and Hash-Based Load Sharing
    • 7.2. Enforcing Infrastructure ACLs
    • 7.3. DDoS Management and Customer Requests for Filtering
    • 7.4. Network Intrusion Detection and Prevention
    • 7.5. Firewalling
  • 8. Operational and Security Implications
    • 8.1. Inability to Find Layer 4 Information
    • 8.2. Route-Processor Protection
    • 8.3. Inability to Perform Fine-Grained Filtering
    • 8.4. Security Concerns Associated with IPv6 Extension Headers
  • 9. IANA Considerations
  • 10. Security Considerations
  • 11. References
    • 11.1. Normative References
    • 11.2. Informative References
  • Acknowledgements
  • Authors' Addresses

1. Introduction ✨

IPv6 extension headers (EHs) let the IPv6 protocol be extended, and they support core stuff like IPv6 fragmentation 🧚 But common implementation limits make EHs a headache for IPv6 routing gear and middleboxes. There's also evidence that IPv6 packets with EHs get intentionally dropped on the public Internet in some situations 😭

This doc has three goals:

  • Raise awareness of the operational and security implications of the IPv6 extension headers specified in [RFC8200], and explain why some networks resort to intentionally dropping packets that contain them 📣
  • Highlight areas where current IPv6 support in networking devices may be suboptimal, so that support can get better 🔧
  • Highlight operational issues with IPv6 extension headers, so those issues get considered in IETF standardization work 🫶

Section 4 gives background on the IPv6 packet structure and what it implies. Section 5 covers previous work on IPv6 extension headers. Section 6 talks about packet-forwarding engine constraints in modern routers. Section 7 explains why intermediate systems might need Layer 4 information to make a forwarding decision. Finally, Section 8 goes through the operational implications of IPv6 EHs 💅

2. Terminology 🌈

This doc uses the term "intermediate system" for both routers and middleboxes, whenever there's no need to tell them apart and the key point is that the device forwards packets 🦋

3. Disclaimer 🙈

This doc analyzes the operational challenges posed by packets that use IPv6 extension headers, and documents some of the operational reasons these packets get dropped on the public Internet. It is not a recommendation to drop such packets. It's an analysis of why they're currently being dropped 💅

4. Background Information 💜

It's useful to compare the basic structure of IPv6 packets with IPv4 packets, and to analyze what the two different structures imply 👀

IPv4 packets have a variable-length header, which allows for IPv4 "options". Those are optional bits of info that may be useful to nodes processing IPv4 packets. The IPv4 header length is in the "Internet Header Length" (IHL) field of the mandatory IPv4 header, and it must be in the range of 20 octets (the minimum IPv4 header size) to 60 octets. That allows at most 40 octets of options. The upper-layer protocol type is in the "Protocol" field of the mandatory IPv4 header 🍓

                  Protocol, IHL
                       +--------+
                       |        |
                       |        v
                  +------//-----+------------------------+
                  |             |                        |
                  |    IPv4     |       Upper-Layer      |
                  |    Header   |       Protocol         |
                  |             |                        |
                  +-----//------+------------------------+

                  variable length
                  <------------->

                      Figure 1: IPv4 Packet Structure

IPv6 went a different way. Instead of a variable-length header like IPv4, IPv6 uses a structure similar to a linked list. A mandatory fixed-length IPv6 header is followed by any number of optional extension headers, and the upper-layer header is always the last one in the IPv6 header chain. Each extension header typically says how long it is (unless the length is implicit from the extension header type), along with the "next header" (NH) type that comes next in the chain 🔗

          NH          NH, EH-length      NH, EH-length
           +-------+      +------+            +-------+
           |       |      |      |            |       |
           |       v      |      v            |       v
     +-------------+-------------+-//-+---------------+--------------+
     |             |             |    |               |              |
     |    IPv6     |    Ext.     |    |     Ext.      |  Upper-Layer |
     |    header   |    Header   |    |     Header    |  Protocol    |
     |             |             |    |               |              |
     +-------------+-------------+-//-+---------------+--------------+

      fixed length    variable number of EHs & length
     <------------> <-------------------------------->

                      Figure 2: IPv6 Packet Structure

This packet structure has a few implications:

  • [RFC8200] requires the entire IPv6 header chain to be contained in the first fragment of a packet, so the IPv6 header chain is capped at the size of the path MTU 📏
  • Apart from the path MTU constraint, there's no other limit on how many IPv6 EHs a packet can carry. So there's no upper limit on how deep into the packet the upper-layer protocol header can be 🌊
  • The only way for a node to learn the upper-layer protocol type, or to find the upper-layer protocol header, is to parse and process the whole IPv6 header chain in sequence, starting at the mandatory IPv6 header and continuing until it reaches the last header in the chain 🧩
Heads up: that last point is the reason EHs are such a pain for busy routers. Finding the Layer 4 header means walking the entire chain, so keep that in mind for the next few sections 👑

More parts are coming, so stay tuned 💖

5. Previous Work on IPv6 Extension Headers ✨

Okay so, people have already been talking about the operational and security drama of IPv6 extension headers in the IETF, and it's a lot 💀 Here's the tea:

  • [OPERATORS] explains why some operators drop IPv6 fragments. 🙈
  • [HEADERS] looks at possible issues with "long" IPv6 header chains.
  • [PARSING] shows how different implementations can parse IPv6 packets with extension headers in inconsistent ways, and how that can lead to evasion of security controls. It also gives guidelines for parsing IPv6 extension headers, so that implementations have a common and consistent parsing method. 🫶
  • [IPV6-EH] analyzes the security implications of IPv6 EHs, plus the operational implications of dropping packets that use IPv6 EHs and their options. 🔥
  • [RFC7113] shows that some popular Router Advertisement Guard (RA-Guard) implementations can be evaded using IPv6 extension headers. 😭
  • [RFC8900] analyzes the fragility that IP fragmentation introduces. 💅

A bunch of newer RFCs have also dealt with IPv6 extension header issues and updated [RFC2460] (the earlier version of the IPv6 standard) 🌸. Most of those updates have now been folded into the current IPv6 core standard [RFC8200] or the IPv6 node requirements [RFC8504]. The highlights are:

  • [RFC5095] covers the security implications of Routing Header Type 0 (RHT0) and deprecates it. 💀
  • [RFC5722] analyzes the security implications of overlapping fragments and gives recommendations for them. 👑
  • [RFC7045] clarifies how intermediate nodes should handle IPv6 extension headers. 🧚
  • [RFC7112] looks at a specific fragmentation case where the IPv6 header chain gets split across two or more fragments, and formally forbids that. 🚫
  • [RFC6946] calls out a flawed (but very common) way of processing so-called IPv6 "atomic fragments" and specifies better processing for those packets. 🦋
  • [RFC8021] deprecates generating IPv6 atomic fragments. 🍓
  • [RFC8504] clarifies processing rules for packets with extension headers, and lets hosts limit how many options go in IPv6 EHs. 💜
  • [RFC7739] talks about the security risks of predictable fragment Identification values and gives recommendations for generating them. 🔥
  • [RFC6980] analyzes the security implications of using IPv6 fragmentation with Neighbor Discovery for IPv6, and formally recommends against that combo. 🙅‍♀️

Also, [RFC8200] relaxed the requirement from [RFC2460] that "all nodes must examine and process the Hop-by-Hop Options header". Now only nodes that have been explicitly configured to process the Hop-by-Hop Options header are required to do so. ✨

People have also measured how often packets with IPv6 extension headers get dropped on the public Internet:

  • [PMTUD-Blackholes] and [Linkova-Gont-IEPG90] share some early measurements of how often packets with IPv6 EHs get dropped on the public Internet. 📊
  • [RFC7872] has more comprehensive results and documents the methodology it used to get them. 🤓
  • [Huston-2017] and [Huston-2020] measure packet drops caused by IPv6 fragmentation when talking to DNS servers. 🌈

6. Packet-Forwarding Engine Constraints 🎀

Most modern carrier-grade routers use dedicated hardware, like Application-Specific Integrated Circuits (ASICs) or Network Processing Units (NPUs), to decide how to forward packets across their internal fabrics (see [IEPG94-Scudder] and [APNIC-Scudder] for the details). 🧠 A common way to do next-hop lookups is to send a small piece of the ingress packet to a lookup engine with specialized hardware, such as ternary content-addressable memory (TCAM) or reduced latency dynamic random-access memory (RLDRAM), so it can figure out the packet's next hop. 💖

Here's the catch: there's a trade-off between how much data gets sent to the lookup engine and the overall packet-forwarding rate of that engine. Send more data and the lookup engine can see deeper into the packet, but the system's forwarding rate drops. Send less data and the router's forwarding rate goes up, but the lookup engine might not be able to see far enough into the packet to decide what to do with it. 😬

Some contemporary high-end routers are known to inspect up to 192 bytes, while others are known to parse up to 384 bytes of header.

Wait, here's the NOTE box in its original cute ASCII form 👇

  |  NOTE:
  |
  |     For example, some contemporary high-end routers are known to
  |     inspect up to 192 bytes, while others are known to parse up
  |     to 384 bytes of header.

If a hardware-forwarding engine on a modern router can't make a forwarding decision about a packet because the critical info never got sent to the lookup engine, the router will normally drop the packet. 🗑️ [Section 7](#7-requirement-to-process-layer-3--layer-4-information-in-intermediate-systems) talks about some of the reasons a modern router might need to look at Layer 4 information to make a forwarding decision. 👀

Historically, some packet-forwarding engines punted packets like this up to the control plane for a deeper look. This isn't doable on most modern router architectures, though, because of the huge gap between the hardware forwarding capacity and the control plane's processing capacity, plus the size of the management link connecting the control plane to the forwarding plane. 🚧 Some platforms have a separate software-based forwarding plane that's different from both the hardware-based forwarding plane and the control plane. But the limited CPU resources of that software forwarding plane, along with the limited bandwidth of its link, cause similar throughput constraints. 😤

If an IPv6 header chain is long enough to go past the packet lookup capacity of the router, the router might not be able to figure out how to handle the packet, so it could end up dropping it. 💔

6.1. Recirculation 🔁

Type-length-value (TLV) chains are friendly to iterative processing on architectures with lookup engines that can inspect deeply. But some packet-forwarding engines handle IPv6 header chains using recirculation. 🌀 This approach processes extension headers one at a time: once processing on one extension header is done, the packet loops back through the processing engine again. This keeps going until there are no extension headers left to process. 🫠

Recirculation is typically used on packet-forwarding engines with limited lookup capability, since it lets arbitrarily long header chains get processed without the complexity and cost of engines with deep lookup capabilities. 🧩 The catch is that recirculation can hurt the forwarding capacity of the hardware, because each packet goes through the processing engine multiple times. Depending on the configuration, the type of packets being processed, and the hardware capabilities of the packet-forwarding engine, the router's data-plane throughput might take a hit. 📉

7. Requirement to Process Layer 3 / Layer 4 Information in Intermediate Systems 💅

The following subsections cover some of the reasons intermediate systems may need to process Layer 3 / Layer 4 information to make a forwarding decision. 🌟

7.1. ECMP and Hash-Based Load Sharing 🪞

With Equal Cost Multipath (ECMP) load sharing, the intermediate system has to decide which of its interfaces to use to forward a given packet. Round-robin use of the links is usually avoided to prevent packet reordering, so forwarding engines need a mechanism that consistently sends the same data streams down the same forwarding paths. 🛤️ Most forwarding engines do this by computing a simple hash over an n-tuple pulled from a mix of Layer 2 through Layer 4 protocol header information. That n-tuple typically uses the src/dst Media Access Control (MAC) addresses, the src/dst IP addresses, and, when possible, the Layer 4 src/dst port information too. 🔑

In the IPv6 world, flows are expected to be identified using the IPv6 "Flow Label" [RFC6437]. So ECMP and hash-based load sharing should be possible without needing to process the entire IPv6 header chain to get upper-layer information for identifying flows. ✨ [RFC7098] talks about how the IPv6 Flow Label can be used to improve Layer 3/4 load distribution and balancing for large server farms. 🏗️

Historically, lots of IPv6 implementations didn't set the Flow Label, and hash-based ECMP/load-sharing devices didn't use it for their job either. Support for [RFC6437] is now widespread in current versions of all the popular host implementations, but the IPv6 Flow Label still sees only marginal use for ECMP and load balancing [Almeida-2020]. One contributing factor could be the issues found in host implementations and middleboxes [Jaeggli-2018]. 🤔

Clearly, if [RFC6437] had widespread support, intermediate systems wouldn't have to process the entire IPv6 header chain, which would make Flow Label-based ECMP and load sharing [RFC6438] feasible. 🥹

If an intermediate system can't determine consistent n-tuples for calculating flow hashes, data streams are more likely to get spread unequally across ECMP and load-shared links. That can lead to packet drops or reduced performance. 📉

7.2. Enforcing Infrastructure ACLs 🛡️

Infrastructure Access Control Lists (iACLs) drop unwanted packets destined for a network's infrastructure. iACLs are usually deployed because direct external access to a network's infrastructure addresses isn't operationally necessary, and it can be used for different sorts of attacks against router control planes. 🚨 To pull this off, traffic usually has to be differentiated based on Layer 3 or Layer 4 criteria, so there's a useful balance of protection and functionality. 💪 For example, an infrastructure might be configured with the following policy:

  • Permit some amount of ICMP echo (ping) traffic towards a router's addresses for troubleshooting. 🏓
  • Permit BGP sessions on the shared network of an exchange point (potentially differentiating between the amount of packets/second permitted for established sessions and for connection establishment), but do not permit other traffic from the same peer IP addresses. 🤝

If a forwarding router can't determine consistent n-tuples for calculating flow hashes, data streams are more likely to get spread unequally across ECMP and load-shared links. That can lead to packet drops or reduced performance. 😩

If a network can't deploy infrastructure ACLs, its security may be compromised because of the increased attack surface. 🚩

7.3. DDoS Management and Customer Requests for Filtering ✨

okay so customer DDoS protection and edge-to-core customer protection filters are lowkey the same vibe as iACL protection 🛡️💖 Like, Layer 4 ACLs generally need to live as close to the edge of the network as possible, even tho the goal is usually to protect the customer edge rather than the provider core 🏰 Applying Layer 4 DDoS protection at the network edge is often automated using BGP Flowspec [RFC8955] [RFC8956] 🎀

picture this: a website that normally only handles traffic on TCP ports 80 and 443 gets hit by a volumetric DDoS attack using NTP and DNS packets with randomized source IP addresses 😭 which makes source-based remote triggered black hole [RFC5635] mechanisms totally useless 💀 In this situation, ACLs that provide DDoS protection could be configured to block all UDP traffic at the network edge without impairing the web server functionality in any way 🙌 So being able to block arbitrary protocols at the network edge can avoid DDoS-related problems both in the provider network and on the customer edge link 👑🌈

7.4. Network Intrusion Detection and Prevention 🕵️‍♀️

okay Network Intrusion Detection Systems (NIDS) examine network traffic and try to spot traffic patterns that can be correlated to network-based attacks 👀 They generally attempt to inspect application-layer traffic (if possible) but, at the bare minimum, inspect Layer 4 flows 💅 When attack activity is inferred, the operator gets notified of the potential intrusion attempt 🔔

Network Intrusion Prevention Systems (IPS) operate similarly to NIDSs, but they can also prevent intrusions by reacting to detected attack attempts by e.g., triggering packet filtering policies at firewalls and other devices 🛑 iconic behavior ngl ✨

Use of extension headers can be problematic for NIDS/IPS, since:

  • Extension headers increase the complexity of resulting traffic and the associated work and system requirements to process it 🧩
  • Use of unknown extension headers can prevent a NIDS or IPS from processing Layer 4 information 😵
  • Use of IPv6 fragmentation requires a stateful fragment-reassembly operation, even for decoy traffic employing forged source addresses (see, e.g., [nmap]) 🫠

so as a result, to increase the efficiency or effectiveness of these systems, packets employing IPv6 extension headers are often dropped at the network ingress point(s) of networks that deploy these systems 🚫💜

7.5. Firewalling 🧱

Firewalls enforce security policies by means of packet filtering 🔐 They usually inspect Layer 3 and Layer 4 traffic but can often also examine application-layer traffic flows 👩‍💻

As with a NIDS or IPS (Section 7.4), use of IPv6 extension headers can be a real challenge for network firewalls, since:

  • Extension headers increase the complexity of resulting traffic and the associated work and system requirements to process it, as outlined in [Zack-FW-Benchmark] 📊
  • Use of unknown extension headers can prevent firewalls from processing Layer 4 information 🙃
  • Use of IPv6 fragmentation requires a stateful fragment-reassembly operation, even for decoy traffic employing forged source addresses (see, e.g., [nmap]) 🌀

also, a super common firewall filtering policy is the so-called "default deny", where all traffic is blocked (by default), and only expected traffic is added to an "allow/accept list" 🙅‍♀️✅

so as a result, packets employing IPv6 extension headers are often dropped by network firewalls, either because of the challenges represented by extension headers or because the use of IPv6 extension headers has not been explicitly allowed 🥲

Note that although the data presented in [Zack-FW-Benchmark] was several years old at the time of publication of this document, many contemporary firewalls use comparable hardware and software architectures 🏗️ consequently, the conclusions of this benchmark are still relevant, despite its age 🕰️💖

8. Operational and Security Implications 💅

8.1. Inability to Find Layer 4 Information 🔍

As discussed in Section 7, intermediate systems that need to find the Layer 4 header must process the entire IPv6 header chain 🔗 When such devices are unable to obtain the required information, the forwarding device has the option to drop the packet unconditionally, forward the packet unconditionally, or process the packet outside the normal forwarding path 🤔 Forwarding packets unconditionally will usually allow for the circumvention of security controls (see, e.g., Section 7.5), while processing packets outside of the normal forwarding path will usually open the door to Denial-of-Service (DoS) attacks (see, e.g., Section 6) 🚪💥 Thus, in these scenarios, devices often simply resort to dropping such packets unconditionally 🫡

8.2. Route-Processor Protection 🛡️

Most contemporary carrier-grade routers have a fast hardware-assisted forwarding plane and a loosely coupled control plane, connected together with a link that has much less capacity than the forwarding plane could handle 🏎️ Traffic differentiation cannot be performed by the control plane because this would overload the internal link connecting the forwarding plane to the control plane 😩

The Hop-by-Hop Options header has been particularly challenging since, in most circumstances, the corresponding packet is punted to the control plane for processing 🙈 As a result, many operators drop IPv6 packets containing this extension header [RFC7872] 🚫 [RFC6192] provides advice regarding protection of a router's control plane 📖🌸

8.3. Inability to Perform Fine-Grained Filtering 🔬

Some intermediate systems do not have support for fine-grained filtering of IPv6 extension headers 🥺 For example, an operator that wishes to drop packets containing RHT0 may only be able to filter on the extension header type (Routing Header) 🙃 This could result in an operator enforcing a coarser filtering policy (e.g., "drop all packets containing a Routing Header" vs. "only drop packets that contain a Routing Header Type 0") 🧶

8.4. Security Concerns Associated with IPv6 Extension Headers 🚨

The security implications of IPv6 extension headers generally fall into one or more of these categories:

  • Evasion of security controls 🫥
  • DoS due to processing requirements 🌊
  • DoS due to implementation errors 🐛
  • Issues specific to the extension header type 🎯

Unlike IPv4 packets where the upper-layer protocol can be trivially found by means of the IHL field of the IPv4 header, the structure of IPv6 packets is more flexible and complex 🌀 This can be a challenge for devices that need to find this information, since locating upper-layer protocol information requires that all IPv6 extension headers be examined 🔎 In turn, this presents implementation difficulties, since some packet-filtering mechanisms that require upper-layer information (even if just the upper-layer protocol type) can be trivially circumvented by inserting IPv6 extension headers between the main IPv6 header and the upper-layer protocol header 😤 [RFC7113] describes this issue for the RA-Guard case, but the same techniques could be employed to circumvent other IPv6 firewall and packet-filtering mechanisms 🫣 Additionally, implementation inconsistencies in packet-forwarding engines can result in evasion of security controls [PARSING] [Atlasis2014] [BH-EU-2014] 🥷

Sometimes, packets with IPv6 extension headers can impact throughput performance on intermediate systems 📉 Unless appropriate mitigations are put in place (e.g., packet dropping and/or rate limiting), an attacker could simply send a large amount of IPv6 traffic employing IPv6 extension headers with the purpose of performing a DoS attack (see Sections 6.1 and 8 for further details) 🚨 The extent to which performance is affected on these devices is implementation dependent 🤷‍♀️

NOTE: In the most trivial case, a packet that includes a Hop-by-Hop Options header might go through the slow forwarding path, to be processed by the router's CPU 🐢 Alternatively, a router configured to enforce an ACL based on upper-layer information (e.g., upper-layer protocol type or TCP Destination Port) may need to process the entire IPv6 header chain in order to find the required information, thereby causing the packet to be processed in the slow path [Cisco-EH-Cons] 😬 We note that, for obvious reasons, the aforementioned performance issues can affect devices such as firewalls, NIDSs, etc. [Zack-FW-Benchmark] 💅

IPv6 implementations, like all other software, tend to mature with time and wide-scale deployment 🌱 While the IPv6 protocol itself has existed for over 20 years, serious bugs related to IPv6 extension header processing continue to be discovered (see, e.g., [Cisco-Frag], [Microsoft-SA], and [FreeBSD-SA]) 🐞 Because there is currently little operational reliance on IPv6 extension headers, the corresponding code paths are rarely exercised, and there is the potential for bugs that still remain to be discovered in some implementations 🕵️

The IPv6 Fragment Header is employed for the fragmentation and reassembly of IPv6 packets 🧩 While many of the security implications of the fragmentation/reassembly mechanism are known from the IPv4 world, several related issues have crept into IPv6 implementations 😬 These range from DoS attacks to information leakages, as discussed in [RFC7739], [Bonica-NANOG58], and [Atlasis2012] 💀🫠

9. IANA Considerations 📋

This document has no IANA actions 🙌

10. Security Considerations 🔐

The security implications of IPv6 extension headers are discussed in Section 8.4 👀 This document does not introduce any new security issues 💖

11. References 📚

11.1. Normative References 🎀

[RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
           of Type 0 Routing Headers in IPv6", RFC 5095,
           DOI 10.17487/RFC5095, December 2007,
           <https://www.rfc-editor.org/info/rfc5095>.

[RFC5722]  Krishnan, S., "Handling of Overlapping IPv6 Fragments",
           RFC 5722, DOI 10.17487/RFC5722, December 2009,
           <https://www.rfc-editor.org/info/rfc5722>.

[RFC6946]  Gont, F., "Processing of IPv6 "Atomic" Fragments",
           RFC 6946, DOI 10.17487/RFC6946, May 2013,
           <https://www.rfc-editor.org/info/rfc6946>.

[RFC6980]  Gont, F., "Security Implications of IPv6 Fragmentation
           with IPv6 Neighbor Discovery", RFC 6980,
           DOI 10.17487/RFC6980, August 2013,
           <https://www.rfc-editor.org/info/rfc6980>.

[RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
           Oversized IPv6 Header Chains", RFC 7112,
           DOI 10.17487/RFC7112, January 2014,
           <https://www.rfc-editor.org/info/rfc7112>.

[RFC8021]  Gont, F., Liu, W., and T. Anderson, "Generation of IPv6
           Atomic Fragments Considered Harmful", RFC 8021,
           DOI 10.17487/RFC8021, January 2017,
           <https://www.rfc-editor.org/info/rfc8021>.

[RFC8200]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
           (IPv6) Specification", STD 86, RFC 8200,
           DOI 10.17487/RFC8200, July 2017,
           <https://www.rfc-editor.org/info/rfc8200>.

[RFC8504]  Chown, T., Loughney, J., and T. Winters, "IPv6 Node
           Requirements", BCP 220, RFC 8504, DOI 10.17487/RFC8504,
           January 2019, <https://www.rfc-editor.org/info/rfc8504>.

11.2. Informative References 📚✨

Okay bestie, these are the "go read this if you want the deep lore" sources 🤓📖. Each one is listed with its key in inline code, and every detail is kept exactly as written.

Acknowledgements 🫶

The authors would like to thank (in alphabetical order) Mikael Abrahamsson, Fred Baker, Dale W. Carder, Brian Carpenter, Tim Chown, Owen DeLong, Gorry Fairhurst, Guillermo Gont, Tom Herbert, Lee Howard, Tom Petch, Sander Steffann, Eduard Vasilenko, Éric Vyncke, Rob Wilton, Jingrong Xie, and Andrew Yourtchenko for providing valuable comments on earlier draft versions of this document. 💜

Fernando Gont would like to thank Jan Zorz / Go6 Lab <https://go6lab.si/>, Jared Mauch, and Sander Steffann <https://steffann.nl/> for providing access to systems and networks that were employed to perform experiments and measurements involving packets with IPv6 extension headers. 🌸

Authors' Addresses 🎀

   Fernando Gont
   SI6 Networks
   Segurola y Habana 4310, 7mo Piso
   Villa Devoto
   Ciudad Autonoma de Buenos Aires
   Argentina

   Email: fgont@si6networks.com
   URI:   https://www.si6networks.com


   Nick Hilliard
   INEX
   4027 Kingswood Road
   Dublin
   24
   Ireland

   Email: nick@inex.ie


   Gert Doering
   SpaceNet AG
   Joseph-Dollinger-Bogen 14
   D-80807 Muenchen
   Germany

   Email: gert@space.net


   Warren Kumari
   Google
   1600 Amphitheatre Parkway
   Mountain View, CA 94043
   United States of America

   Email: warren@kumari.net


   Geoff Huston

   Email: gih@apnic.net
   URI:   https://www.apnic.net


   Will (Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen
   518129
   China

   Email: liushucheng@huawei.com

And that's a wrap on RFC 9098! 🦋👑 You made it, bestie. The whole thing is a serious, important document, and you just read all of it. We are so proud of us 💅🌈

📦 where this page comes from