INTERNET-DRAFT                                               Tom Herbert
Intended Status: Informational                                Quantonium
Expires: February 18, 2019

                                                         August 17, 2018


               Updates to Destination Options Processing
                 draft-herbert-ipv6-update-dest-ops-00

Abstract

   This document updates the requirements for processing Destination
   Options in IPv6 in two ways. First, the requirement that all
   intermediate destinations in a Routing header must process options in
   a Destination header appearing before the Routing header is relaxed.
   Secondly, the processing of a Destination Option marked as changeable
   is clarified.

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) 2018 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



Herbert                  Expires February, 2019                 [Page 1]


INTERNET DRAFT   draft-herbert-ipv6-update-dest-ops-00   August 17, 2018


   (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  Processing Requirements of Destination Options  . . . . . . . .  3
   3  Changeable Destination Options  . . . . . . . . . . . . . . . .  4
   4  Security Considerations . . . . . . . . . . . . . . . . . . . .  4
   5  IANA Considerations . . . . . . . . . . . . . . . . . . . . . .  4
   6  References  . . . . . . . . . . . . . . . . . . . . . . . . . .  4
     6.1  Normative References  . . . . . . . . . . . . . . . . . . .  4
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . .  5
































Herbert                  Expires February, 2019                 [Page 2]


INTERNET DRAFT   draft-herbert-ipv6-update-dest-ops-00   August 17, 2018


1  Introduction

   [RFC8200] specifies the Destination Options header and processing
   requirements. Two requirements for processing Destination Options are
   described based on their association with a Routing header. A
   Destination Options header that is in a packet with no Routing
   header, or follows a Routing header, is processed only by the final
   destination node (if no routing header is present that is simply the
   destination of the packet). A Destination Options header that comes
   before a Routing header must be processed by each intermediate
   destination listed in a Routing header. In the first case,
   Destination Options are only processed by one node, but in the latter
   they may need to be processed by many intermediate nodes. This
   distinction motivates a couple of clarifications to the requirements.

   In that case of Destination Options that come before a Routing
   header, this document proposes that intermediate destination nodes
   may ignore the options. This change has a similar justification for
   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 implementation behaviors for processing
   packets with options. Some implementations have dropped packets with
   options, others have relegated them to slow path processing; in
   either case, these behaviors at even a few nodes can essentially
   render options unusable. Allowing intermediate nodes to ignore
   options retains the primary value and usability of Destination
   Options. Intermediate nodes that are not interested in them can
   ignore them, nodes that fully support them can process them.

   Destination Options may be marked as changeable (the third-highest-
   order bit of the Option Type for the Destination Option is set). Per
   [RFC8200], for such a marked option its Option Data may be changed en
   route. [RFC8200] also states that with the exception of Hop-by-Hop
   options, extension headers are not processed except by a destination.
   It follows that the only possible case that a Destination Option may
   be modified en route is when an intermediate destination in a Routing
   header modifies it. This document clarifies that.

2  Processing Requirements of Destination Options

   Options in a Destination Options header that is after a Routing
   header, or are in a packet with no Routing header present, MUST be
   examined and processed by the destination node.

   The options in a Destination Options header that appears before a



Herbert                  Expires February, 2019                 [Page 3]


INTERNET DRAFT   draft-herbert-ipv6-update-dest-ops-00   August 17, 2018


   Routing header MAY be examined or processed by intermediate nodes
   listed in the routing header, including the original destination as
   well as the ultimate destination provided in the routing header. If
   an intermediate node does not process the options in a Destination
   Option header appearing before a Routing header, then it MUST skip
   over the Destination Options header and continue to process the next
   header which should be a Routing header.

3  Changeable Destination Options

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

   If a Destination Option is marked to be changeable (the third-highest
   order bit of the option type is set) 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
   that the entire Option Data field must be treated as zero-valued
   octets when computing or verifying the packet's authenticating value
   is still applicable.

4  Security Considerations

   Relaxing the requirement that Destination Options can be ignored by
   intermediate 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 security option.

5  IANA Considerations

   There are no IANA considerations in this specification.

6  References

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



Herbert                  Expires February, 2019                 [Page 4]


INTERNET DRAFT   draft-herbert-ipv6-update-dest-ops-00   August 17, 2018


Author's Address

   Tom Herbert
   Quantonium
   Santa Clara, CA
   USA

   Email: tom@quantonium.net











































Herbert                  Expires February, 2019                 [Page 5]