Network Working Group J. Iurman Internet-Draft University of Liege Updates: 8200 (if approved) 23 December 2025 Intended status: Standards Track Expires: 26 June 2026 Mitigating DoS attacks in IPv6 by clarifying the number of occurrences of Extension Headers draft-iurman-6man-eh-occurrences-00 Abstract This document updates RFC 8200 by specifying normative requirements on the number of occurrences of IPv6 Extension Headers. Operational experience has demonstrated that permitting multiple occurrences of the same Extension Header can create parsing ambiguity, increase attack surface, and complicate packet processing in general. This is especially true for both the Hop-by-Hop Options Header and the Destination Options Header, which can contain a number of options. This document restricts IPv6 packets to carry at most one instance of each Extension Header, with the exception of the Destination Options Header, which is permitted to appear twice as specified in RFC 8200. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 26 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Iurman Expires 26 June 2026 [Page 1] Internet-Draft DoS Mitigation: IPv6 Extension Headers December 2025 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Update to the number of occurrences of Extension Headers . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction Section 4.1 of [RFC8200] recommends, but does not normatively require, that each Extension Header appear at most once, with the exception of the Destination Options Header, which may appear at most twice, once before a Routing header and once before the upper-layer header. Operational experience has demonstrated that permitting multiple occurrences of the same Extension Header can create parsing ambiguity, increase attack surface, and complicate packet processing in general. This is especially true for both the Hop-by-Hop Options Header and the Destination Options Header, which can contain a number of options. This document updates [RFC8200], in particular Section 4.1, to enforce normative limits on the number of occurrences of Extension Headers and to remove any ambiguity in the text. This document addresses concerns related to DoS attacks on hosts as specified in [I-D.ietf-6man-eh-limits], although new limits on the number of Hop- by-Hop and Destination Options could be specified in [I-D.ietf-6man-rfc8504-bis] (i.e., smaller than 8). Iurman Expires 26 June 2026 [Page 2] Internet-Draft DoS Mitigation: IPv6 Extension Headers December 2025 2. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 3. Update to the number of occurrences of Extension Headers The following text replaces paragraph 2 of [RFC8200] Section 4.1. OLD (RFC 8200): | Each extension header should occur at most once, except for the | Destination Options header, which should occur at most twice (once | before a Routing header and once before the upper-layer header). NEW: | Each extension header SHOULD occur at most once, except for the | Destination Options header, which SHOULD occur at most twice (once | before a Routing header and once before the upper-layer header). [RFC Editor: please remove this note] An alternative would be to keep the above text as is, without normative language. The following text replaces paragraph 5 of [RFC8200] Section 4.1. OLD (RFC 8200): | IPv6 nodes must accept and attempt to process extension headers in | any order and occurring any number of times in the same packet, | except for the Hop-by-Hop Options header, which is restricted to | appear immediately after an IPv6 header only. Nonetheless, it is | strongly advised that sources of IPv6 packets adhere to the above | recommended order until and unless subsequent specifications | revise that recommendation. NEW: Iurman Expires 26 June 2026 [Page 3] Internet-Draft DoS Mitigation: IPv6 Extension Headers December 2025 | IPv6 nodes must accept and attempt to process extension headers in | any order in the same packet, except for the Hop-by-Hop Options | header, which is restricted to appear immediately after an IPv6 | header only. Nonetheless, it is strongly advised that sources of | IPv6 packets adhere to the above recommended order until and | unless subsequent specifications revise that recommendation. IPv6 | nodes MAY discard a packet exceeding the number of occurrences of | extension headers. [RFC Editor: please remove this note] "SHOULD" or even "MUST" would obviously be better, but "MAY" seems to be the only backward compatible solution. 4. Security Considerations This document does not introduce new security considerations. On the contrary, the change proposed in this document mitigates possible DoS attacks based on an abusive use of Extension Headers in IPv6 packets. 5. IANA Considerations This document does not require any action from IANA. 6. Acknowledgements TBD 7. References 7.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 7.2. Informative References Iurman Expires 26 June 2026 [Page 4] Internet-Draft DoS Mitigation: IPv6 Extension Headers December 2025 [I-D.ietf-6man-eh-limits] Herbert, T., "Limits on Sending and Processing IPv6 Extension Headers", Work in Progress, Internet-Draft, draft-ietf-6man-eh-limits-19, 27 February 2025, . [I-D.ietf-6man-rfc8504-bis] Chown, T., Loughney, J. A., and T. Winters, "IPv6 Node Requirements", Work in Progress, Internet-Draft, draft- ietf-6man-rfc8504-bis-02, 20 October 2025, . Author's Address Justin Iurman University of Liege 10, Allee de la decouverte (B28) 4000 Sart-Tilman Belgium Email: justin.iurman@uliege.be Iurman Expires 26 June 2026 [Page 5]