Inserting, Processing And Deleting
IPv6 Extension Headers
Juniper Networks
2251 Corporate Park Drive
Herndon
20171
Virginia
USA
rbonica@juniper.net
INT Area
6man
Extension Header
This document provides guidance regarding the processing, insertion
and deletion of IPv6 extension headers. It updates RFC 8200.
In IPv6 optional internet-layer
information is encoded in extension headers. As specified by , "extension headers (except for the Hop-by-Hop
Options header) are not processed, inserted, or deleted by any node
along a packet's delivery path, until the packet reaches the node (or
each of the set of nodes, in the case of multicast) identified in the
Destination Address field of the IPv6 header".
The statement quoted above identifies nodes upon which extension
headers are not processed, inserted or deleted. It does not imply that
extension headers can be processed, inserted or deleted on any other
node along a packet's delivery path.
This document provides guidance regarding the processing, insertion
and deletion of IPv6 extension headers. It clarifies the statement
quoted above and updates .
The following terms are used in this document:
Source node - An IPv6 source node accepts data from an
upper-layer protocol, encapsulates it in an IPv6 header, and sends
the resulting IPv6 packet to a destination node.
Destination node - An IPv6 destination node receives an IPv6
packet and delivers its payload to an upper-layer protocol.
Delivery path - A packet's delivery path is a series of nodes
that a packet traverses on route to its destination. The delivery
path includes the destination node.
Segment - A segment is a series of links and nodes in a packet's
delivery path. The IPv6 Routing header steers packets from segment
to segment along the delivery path. If a packet contains a Routing
header, its delivery path can contain multiple segments. If a packet
does not contain a Routing header, its delivery path contains only
one segment.
Segment egress node - A segment egress node terminates a segment.
When a packet arrives at a segment egress node, its IPv6 Destination
Address identifies a resource that belongs to the node. All
destination nodes are also segment egress nodes.
The terms defined in of this document
should be added to Section 2 of .
of this document quotes text from . That text should be replaced with the text contained
by of this document.
"Extension headers (except for the Hop-by-Hop Options header) are
not processed, inserted, or deleted by any node along a packet's
delivery path, until the packet reaches the node (or each of the set
of nodes, in the case of multicast) identified in the Destination
Address field of the IPv6 header.
The Hop-by-Hop Options header is not inserted or deleted, but may
be examined or processed by any node along a packet's delivery path,
until the packet reaches the node (or each of the set of nodes, in the
case of multicast) identified in the Destination Address field of the
IPv6 header. The Hop-by-Hop Options header, when present, must
immediately follow the IPv6 header. Its presence is indicated by the
value zero in the Next Header field of the IPv6 header."
Source nodes can send packets that include extension headers.
Extension headers are not inserted by subsequent nodes along a
packet's delivery path.
The Hop-by-Hop Options header can be processed by any node in a
packet’s delivery path. The following headers can be processed
by any segment egress node, including the destination node:
Destination Options header.
Routing header.
The following headers can be processed by the destination node
only:
The Fragment header.
The Authentication header.
The Encapsulating Security Payload header.
Except for the following fields, extension headers are not modified
by nodes along a packet's delivery path:
The Segments Left field in the Routing header.
Type-specific data in the Routing header.
Option Data in the Destination Options header.
Extension headers are not deleted by any node along a packet's
delivery path, until the packet reaches the destination node (or each
of the set of destination nodes, in the case of multicast).
The following are reasons why extension headers are not inserted by
nodes along a packet's delivery path:
MTU black holing - Many IPv6 nodes dynamically discover Path MTU (PMTU). Having discovered the PMTU,
they send packets whose size approaches, but does not exceed the
PMTU. Adding an extension header to such a packet can cause MTU
black holing.
Incompatibility with the IPv6
Authentication Header - IPv6 Authentication header processing
relies on the immutability of the Payload Length field in the IPv6
header. When a node along a packet's delivery path inserts an
extension header, it updates the Payload Length field in the IPv6
header. This causes Authentication header processing to fail.
Semantic corruption - Insertion of an extension header can change
the meaning of a packet.
The following are reasons why extension headers are not deleted by
any node along a packet's delivery path, until the packet reaches the
destination node:
Incompatibility with the IPv6 Authentication Header - IPv6
Authentication header processing relies on the immutability of the
Payload Length field in the IPv6 header. When a node along a
packet's delivery path deletes an extension header, it updates the
Payload Length field in the IPv6 header. This causes Authentication
header processing to fail.
Semantic corruption - Deletion of an extension header can change
the meaning of a packet.
This document does not introduce any new security considerations.
This document does not request any IANA actions.
Thanks to Bob Hinden, Brian Carpenter, Tom Herbert, and Jinmei Tatuya
for their comments and review.