Inserting, Processing And Deleting IPv6 Extension Headers
draft-bonica-6man-ext-hdr-update-03
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Authors | Ron Bonica , Tatuya Jinmei | ||
| Last updated | 2020-03-16 | ||
| Stream | (None) | ||
| Formats | plain text xml htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-bonica-6man-ext-hdr-update-03
6man R. Bonica
Internet-Draft Juniper Networks
Updates: RFC 8200 (if approved) T. Jinmei
Intended status: Standards Track Infoblox
Expires: September 17, 2020 March 16, 2020
Inserting, Processing And Deleting IPv6 Extension Headers
draft-bonica-6man-ext-hdr-update-03
Abstract
This document provides guidance regarding the processing, insertion
and deletion of IPv6 extension headers. It updates 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 September 17, 2020.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
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 Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Bonica & Jinmei Expires September 17, 2020 [Page 1]
Internet-Draft IPv6 Extension Headers March 2020
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Updates To RFC 8200 . . . . . . . . . . . . . . . . . . . . . 3
3.1. Original Text . . . . . . . . . . . . . . . . . . . . . . 3
3.2. Updated Text . . . . . . . . . . . . . . . . . . . . . . 4
4. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . 4
5. Security Considerations . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5
8. Normative References . . . . . . . . . . . . . . . . . . . . 5
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 6
1. Introduction
In IPv6 [RFC8200] optional internet-layer information is encoded in
extension headers. As specified by [RFC8200], "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 [RFC8200].
2. Terminology
The following terms are used in this document:
o Source node - An IPv6 source node accepts data from an upper-layer
protocol, prepends an IPv6 header, and sends the resulting IPv6
packet to a destination node.
o Final destination node - An IPv6 final destination node receives
an IPv6 packet and delivers its payload to an upper-layer
protocol. If a packet contains a Routing header, its destination
address may represent an interface that belongs to a node other
than the final destination node.
Bonica & Jinmei Expires September 17, 2020 [Page 2]
Internet-Draft IPv6 Extension Headers March 2020
o Delivery path - A packet's delivery path is a series of nodes that
a packet traverses on route to its final destination. The
delivery path includes the final destination node.
o Segment - A segment is a series of links and nodes in a packet's
delivery path. An 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.
o Segment egress node - A segment egress node terminates a segment.
When a packet arrives at a segment egress node, its IPv6
Destination Address identifies an interface that belongs to the
node. All final destination nodes are also segment egress nodes.
o Extension header processing - Each IPv6 extension header is
associated with a procedure. For example, the Fragment header is
associated with fragmentation and reassembly procedures.
Extension header processing is the reception of an extension
header and the execution of its associated procedure.
3. Updates To RFC 8200
The terms defined in Section 2 of this document should be added to
Section 2 of [RFC8200].
Section 3.1 of this document quotes text from [RFC8200]. That text
should be replaced with the text contained by Section 3.2 of this
document.
3.1. Original Text
"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."
Bonica & Jinmei Expires September 17, 2020 [Page 3]
Internet-Draft IPv6 Extension Headers March 2020
3.2. Updated Text
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, 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.
The Hop-by-Hop Options header can be processed by any node in a
packet's delivery path. All remaining extension headers can be
processed at segment endpoints only. While some extension headers
can be processed at any segment endpoint node, others (e.g., the
Fragment header) can only be processed at the final destination node.
The following extension header fields, if present, are not modified
by nodes along a packet's delivery path:
o Next Header.
o Hdr Ext Len.
Extension headers are not deleted by any node along a packet's
delivery path, until the packet reaches the final destination node
(or each of the set of final destination nodes, in the case of
multicast).
Extension headers can be inspected for various purposes (e.g.,
firewall filtering) by any node along a packet's delivery path.
4. Motivation
The following are reasons why extension headers are not inserted by
nodes along a packet's delivery path:
o Nodes that execute Path MTU Discovery (PMTUD) [RFC8201] procedures
can send packets that are nearly as large as the Path MTU. Adding
an extension header to such a packet can cause MTU black holing.
o IPv6 Authentication Header [RFC4302] 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 must also update the Payload Length field in the IPv6 header.
Therefore, it causes IPv6 Authentication Header processing to fail
on the final destination node.
Bonica & Jinmei Expires September 17, 2020 [Page 4]
Internet-Draft IPv6 Extension Headers March 2020
o When a source node sends a packet to a final destination node, and
a node along the packet's delivery path inserts an extension
header, the final destination node will mistakenly attribute the
extension header to the source node. Attackers can leverage this
mistaken attribution.
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:
o 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 must also
update the Payload Length field in the IPv6 header. Therefore, it
causes IPv6 Authentication Header processing to fail on the final
destination node.
o When a source node sends a packet to a final destination node, and
a node along the packet's delivery path removes an extension
header, the resulting packet may not elicit the behavior intended
by the source node. For example, if a Destination Options header
is removed, none of the options that it contains will be delivered
to the final destination node.
5. Security Considerations
This document does not introduce any new security considerations.
6. IANA Considerations
This document does not request any IANA actions.
7. Acknowledgements
Thanks to Bob Hinden, Brian Carpenter, Tom Herbert and Fernando Gont
for their comments and review.
8. Normative References
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[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>.
Bonica & Jinmei Expires September 17, 2020 [Page 5]
Internet-Draft IPv6 Extension Headers March 2020
[RFC8201] McCann, J., Deering, S., Mogul, J., and R. Hinden, Ed.,
"Path MTU Discovery for IP version 6", STD 87, RFC 8201,
DOI 10.17487/RFC8201, July 2017,
<https://www.rfc-editor.org/info/rfc8201>.
Authors' Addresses
Ron Bonica
Juniper Networks
2251 Corporate Park Drive
Herndon, Virginia 20171
USA
Email: rbonica@juniper.net
Tatuya Jinmei
Infoblox
Email: jinmei@wide.ad.jp
Bonica & Jinmei Expires September 17, 2020 [Page 6]