[Docs] [txt|pdf|xml|html] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03

6man                                                           R. Bonica
Internet-Draft                                          Juniper Networks
Updates: RFC 8200 (if approved)                            March 6, 2020
Intended status: Standards Track
Expires: September 7, 2020


       Inserting, Processing And Deleting IPv6 Extension Headers
                  draft-bonica-6man-ext-hdr-update-01

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 7, 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                  Expires September 7, 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  . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Discussion  . . . . . . . . . . . . . . . . . . . . . . . . .   4
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   5
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   5
   8.  Normative References  . . . . . . . . . . . . . . . . . . . .   5
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . .   5

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, encapsulates it in an IPv6 header, and sends the
      resulting IPv6 packet to a destination node.

   o  Destination node - An IPv6 destination node receives an IPv6
      packet and delivers its payload to an upper-layer protocol.

   o  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.




Bonica                  Expires September 7, 2020               [Page 2]


Internet-Draft           IPv6 Extension Headers               March 2020


   o  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.

   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 a resource that belongs to the
      node.  All destination nodes are also segment egress nodes.

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."

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 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:

   o  Destination Options header.



Bonica                  Expires September 7, 2020               [Page 3]


Internet-Draft           IPv6 Extension Headers               March 2020


   o  Routing header.

   The following headers can be processed by the destination node only:

   o  The Fragment header.

   o  The Authentication header.

   o  The Encapsulating Security Payload header.

   Except for the following fields, extension headers are not modified
   by nodes along a packet's delivery path:

   o  The Segments Left field in the Routing header.

   o  Type-specific data in the Routing header.

   o  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).

4.  Discussion

   The following are reasons why extension headers are not inserted by
   nodes along a packet's delivery path:

   o  MTU black holing - Many IPv6 nodes dynamically discover Path MTU
      (PMTU) [RFC8201].  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.

   o  Incompatibility with the IPv6 Authentication Header [RFC4302] -
      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.

   o  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:





Bonica                  Expires September 7, 2020               [Page 4]


Internet-Draft           IPv6 Extension Headers               March 2020


   o  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.

   o  Semantic corruption - Deletion of an extension header can change
      the meaning of a packet.

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 Jinmei Tatuya
   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>.

   [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>.

Author's Address

   Ron Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, Virginia  20171
   USA

   Email: rbonica@juniper.net



Bonica                  Expires September 7, 2020               [Page 5]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/