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

Versions: (draft-herbert-ipv6-update-dest-ops) 00 01

INTERNET-DRAFT                                               Tom Herbert
Intended Status: Standard                                     Quantonium
Expires: September 2, 2019

                                                           March 1, 2019


                Updates to Requirements for IPv6 Options
                   draft-herbert-ipv6-update-opts-01

Abstract

   This document updates requirements for IPv6 Destination and Hop-by-
   Hop Options. The requirements that option type and option length
   cannot change en route, as well as the requirements that options
   cannot be added or removed, are made explicit. The meaning and
   requirements of a Destination Option marked as changeable are
   clarified. Finally, the requirement that all destinations listed in a
   Routing header must process options in a Destination Options header
   preceding the Routing header is relaxed.

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.

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

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/1id-abstracts.html

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html


Copyright and License Notice

   Copyright (c) 2019 IETF Trust and the persons identified as the
   document authors. All rights reserved.




Herbert                 Expires September, 2019                 [Page 1]


INTERNET DRAFT     draft-herbert-ipv6-update-opts-01       March 1, 2019


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://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.


Table of Contents

   1  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2  Requirements for adding, removing, or changing options  . . . .  4
   3  Requirements for changeable Destination Options . . . . . . . .  4
   4  Requirements for processing Destination Options . . . . . . . .  5
   5  Detecting that Destination Options precede a Routing header . .  5
   6  Security Considerations . . . . . . . . . . . . . . . . . . . .  6
   7  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  6
   8  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     8.1  Normative References  . . . . . . . . . . . . . . . . . . .  6
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  6




























Herbert                 Expires September, 2019                 [Page 2]


INTERNET DRAFT     draft-herbert-ipv6-update-opts-01       March 1, 2019


1  Introduction

   [RFC8200] specifies Hop-by-Hop and Destination Options. This document
   clarifies requirements for changing, adding, or removing options in a
   packet en route to its final destination. It also relaxes the
   requirement that Destination Options preceding a Routing header must
   be processed by all destinations listed in the Routing header.

   [RFC8200] states that "The third-highest-order bit of the Option Type
   specifies whether or not the Option Data of that option can change en
   route to the packet's final destination." It is implicit in this
   requirement that neither the Option Type nor Option Data Length can
   change en route to the packet's destination. It also follows that
   options cannot be added or removed while a packet is en route. This
   document makes these requirements explicit.

   Per [RFC8200], a Destination Option is marked as changeable en route
   when the third-highest-order bit of the Option Type for the
   Destination Option is set. [RFC8200] also states that with the
   exception of Hop-by-Hop options, extension headers are not examined
   or processed by any intermediate nodes in the path. It follows that
   the only possible case that a Destination Option may be modified en
   route is by a node that is one of destinations to be visited in a
   Routing header. This document clarifies this requirement.

   Per [RFC8200], if a Destination Options header precedes a Routing
   header, then all of the destinations listed in the Routing header
   must process the Destination Options. This document proposes to relax
   that requirement by allowing nodes listed in the Routing header to
   ignore Destination Options that precede the Routing header. The
   motivation for this is similar to that of relaxing the requirement
   that all intermediate nodes process Hop-by-Hop options in [RFC8200].
   Intermediate destination nodes may be closer in taxonomy to switches
   and routers than end hosts, so it follows that they may have similar
   processing constraints in efficiently processing extension headers
   and TLVs. Those constraints could lead to similar ad hoc behaviors
   for processing packets with options-- some implementations have
   dropped packets with options, others have relegated them to slow path
   processing. In any case, such behaviors, even at a few nodes, can
   essentially render options unusable. Allowing nodes to ignore options
   retains the primary value and usability of Destination Options
   preceding a Routing header. Nodes that are not interested in them can
   ignore them, nodes that fully support them can process them.








Herbert                 Expires September, 2019                 [Page 3]


INTERNET DRAFT     draft-herbert-ipv6-update-opts-01       March 1, 2019


2  Requirements for adding, removing, or changing options

   This section clarifies requirements of [RFC8200] for adding,
   removing, or changing Destination Options or Hop-by-Hop Options.

   The Option Type of an option MUST NOT be changed en route to a
   packet's final destination. Note that this precludes changing the
   high order bits of an Option Type which indicate a changeable option
   or the action to take for an unknown option.

   The Option Data Length of an option MUST NOT be changed en route to a
   packet's final destination. If the third-highest-order bit of the
   Option Type is set indicating that the Option Data can change en
   route, then any changes MUST be to the existing Option Data and the
   Option Length MUST be preserved. Note, if the Option Data Length is
   zero then the option cannot be modified in any way.

   Options MUST NOT be added to or removed from a packet en route to its
   final destination. This requirement precludes adding or removing
   options within an existing extension header, as well as adding or
   removing Destination or Hop-by-Hop extension headers in a packet.

   Note that in the case that a routing header is present, the "final
   destination" refers to the final destination listed to visit in the
   routing header. At intermediate destinations of a routing header, the
   packet is considered en route to its final destination, so that
   requirements about changing Destination Options en route are
   applicable.

3  Requirements for changeable Destination Options

   If a Destination Option in a Destination Options header that precedes
   a Routing header is marked as changeable, that is the third-highest
   order bit of the Option Type is set, then the Option Data may be
   changed by any intermediate destination node en route to the final
   destination. Specifically, the node for the initial destination
   address as well as any nodes to visit as listed in the Routing header
   may change the Option Data.

   If a Destination Option is marked as changeable and is in a
   Destination Options header that follows a Routing header, or there is
   no Routing header present, then the Option Data cannot be changed en
   route. There are no nodes in the path that are permitted to change
   the Option Data. Note that the requirement when an Authentication
   header is present the entire Option Data field of a changeable option
   must be treated as zero-valued octets when computing or verifying the
   packet's authenticating value is still applicable.




Herbert                 Expires September, 2019                 [Page 4]


INTERNET DRAFT     draft-herbert-ipv6-update-opts-01       March 1, 2019


4  Requirements for processing Destination Options

   This section clarifies requirements of processing Destination Options
   with respect to its relationship to a Routing header.

   Options in a Destination Options header that follow a Routing header,
   or are in a packet having no Routing header, MUST be processed by the
   destination node. In the case that a Routing header is present, the
   Destination Options that follow the Routing header MUST be processed
   by the final destination listed in the Routing header.

   Options in a Destination Options header that precede a Routing header
   MAY be examined or processed by the original destination node and
   nodes listed to visit in the Routing header. If a node does not
   process the options in a Destination Option header, then it MUST skip
   over the Destination Options header and continue to process the next
   header which is likely the Routing header. The final destination of a
   packet, which is the last node listed in the Routing header, MUST
   process a Destination Options header that appears before the routing
   header. Any intermediate nodes that are not explicitly listed as
   intermediate destinations in the Routing header MUST NOT examine or
   process a Destination Options header preceding a Routing header.

5  Detecting that Destination Options precede a Routing header

   As specified in requirements of this document, an implementation
   might process Destination Options differently depending on whether
   they precede a Routing header. Procedures are therefore needed to
   detect if a Destination Options header precedes a Routing header.

   An implementation MAY determine that Destination Options precede a
   Routing header by inspecting the Next Header field of the Destination
   Options header. If the Next Header field indicates a Routing header,
   then the implementation can conclude that Destination Options precede
   a Routing Header. Note that this employs a heuristic based on the
   recommended ordering of extension headers of [RFC8200] in which the
   Routing header should immediately follow Destination Options header
   before a Routing header.

   An implementation MAY scan the packet to determine if a Routing
   header is present that follows a Destination Options header. If such
   a scan is performed, an implementation MUST NOT process any scanned
   extension headers beyond inspecting their Next Header and Header Ext
   Length fields. This requirement is necessary ensure that extension
   headers are strictly processed order as manadated by [RFC8200].

   If a node is unable to determine that Destination Options precede a
   Routing header, the Destinations Options MUST be processed as though



Herbert                 Expires September, 2019                 [Page 5]


INTERNET DRAFT     draft-herbert-ipv6-update-opts-01       March 1, 2019


   they do not precede a Routing header. In this case, a destination
   node, regardless whether it is an intermediate or final destination,
   MUST process the Destination Options and MUST NOT change any
   Destination Options even if they are marked as changeable.

6  Security Considerations

   Relaxing the requirement that Destination Options preceding a Routing
   header can be ignored by intermediate destination nodes should not
   pose any new security risk. It should be noted that any security
   mechanism specified in a Destination Option should take into account
   that not all intermediate destinations would necessarily process the
   option in a Destination Options header that precedes a Routing
   header.

7  IANA Considerations

   There are no IANA considerations in this specification.

8  References

8.1  Normative References

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

Author's Address

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA

   Email: tom@quantonium.net















Herbert                 Expires September, 2019                 [Page 6]


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