Enforcement of IPv6 Extension Headers Ordering and Occurrence at Destination Nodes
draft-iurman-6man-eh-occurrences-02
| Document | Type |
Replaced Internet-Draft
(6man WG)
Expired & archived
|
|
|---|---|---|---|
| Authors | Justin Iurman , Tom Herbert | ||
| Last updated | 2026-05-28 (Latest revision 2026-04-14) | ||
| Replaced by | draft-ietf-6man-eh-occurrences | ||
| RFC stream | Internet Engineering Task Force (IETF) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Additional resources | Mailing list discussion | ||
| Stream | WG state | Adopted by a WG | |
| Document shepherd | (None) | ||
| IESG | IESG state | Replaced by draft-ietf-6man-eh-occurrences | |
| Consensus boilerplate | Unknown | ||
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Operational experience has demonstrated that permitting multiple occurrences of the same IPv6 Extension Header can create parsing ambiguity, complicate packet processing, and increase potential security risks. Although RFC 8200 recommends that senders follow a specific order of appearance and limit the occurrences of Extension Headers, receivers cannot assume that these recommendations have been followed. This document updates RFC 8200 by allowing an IPv6 destination node, namely a host (i.e., the final destination of an IPv6 packet) or an intermediate destination node addressed by an entry in a Routing header list other than the final one, to enforce strict ordering and limits on the occurrence of Extension Headers.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)