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

Versions: 00 01 02

6man                                                             F. Gont
Internet-Draft                                    UTN-FRH / SI6 Networks
Updates: 2460 (if approved)                                       W. Liu
Intended status: Best Current Practice               Huawei Technologies
Expires: February 22, 2016                                     R. Bonica
                                                        Juniper Networks
                                                         August 21, 2015


              Transmission and Processing of IPv6 Options
                draft-gont-6man-ipv6-opt-transmit-02.txt

Abstract

   Various IPv6 options have been standardized since the core IPv6
   standard was first published.  This document updates RFC 2460 to
   clarify how nodes should deal with such IPv6 options and with any
   options that are defined in the future.  It complements [RFC7045],
   which offers a similar clarification regarding IPv6 Extension
   Headers.

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 http://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 February 22, 2016.

Copyright Notice

   Copyright (c) 2015 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
   (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



Gont, et al.            Expires February 22, 2016               [Page 1]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   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 and Problem Statement  . . . . . . . . . . . . .   2
   2.  Terminology and Conventions Used in This Document . . . . . .   3
     2.1.  Terminology . . . . . . . . . . . . . . . . . . . . . . .   3
     2.2.  Conventions . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  Considerations for All IPv6 Options . . . . . . . . . . . . .   4
   4.  Processing of currently-defined IPv6 Options  . . . . . . . .   5
     4.1.  Hop-by-Hop Options Header . . . . . . . . . . . . . . . .   5
     4.2.  Destination Options Header  . . . . . . . . . . . . . . .   7
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   7
   6.  Security Considerations . . . . . . . . . . . . . . . . . . .   9
   7.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .  10
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  10
     8.1.  Normative References  . . . . . . . . . . . . . . . . . .  10
     8.2.  Informative References  . . . . . . . . . . . . . . . . .  13
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

1.  Introduction and Problem Statement

   Various IPv6 options have been standardized since the core IPv6
   standard [RFC2460] was first published.  Except for the padding
   options (Pad1 and PadN), all the options that have so far been
   specified are meant to be employed with specific IPv6 Extension
   Header (EH) types.  Additionally, some options have specific
   requirements such as, for example, only allowing a single instance of
   the option in the corresponding IPv6 extension header.  This
   establishes some criteria for validating packets that employ IPv6
   options.

   [RFC2460] specifies that IPv6 extension headers (with the exception
   of the Hop-by-Hop Options extension header) are not 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.  However, in practice this is not really the case: some
   routers, and a variety of middleboxes such as firewalls, load
   balancers, or packet classifiers, might inspect other parts of each
   packet [RFC7045].  Hence both end-nodes an intermediate nodes may end
   up inspecting the contents of extension headers and discard packets
   based on the presence of specific IPv6 options.





Gont, et al.            Expires February 22, 2016               [Page 2]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   This document clarifies the default processing of IPv6 options.  In
   those cases in which the specifications add additional constraints/
   requirements regarding IPv6 options, such additional constraints/
   requirements are also taken into account.

2.  Terminology and Conventions Used in This Document

2.1.  Terminology

   In the remainder of this document, the term "forwarding node" refers
   to any router, firewall, load balancer, prefix translator, or any
   other device or middlebox that forwards IPv6 packets with or without
   examining the packet in any way.

   In this document, "standard" IPv6 options are those specified in
   detail by IETF Standards Actions [RFC5226].  "Experimental" options
   include those defined by any Experimental RFC and the option types
   0x1E, 0x3E, 0x5E, 0x7E, 0x9E, 0xBE, 0xDE, and 0xFE, defined by
   [RFC3692] and [RFC4727] when used as experimental options.  "Defined"
   options are the "standard" options plus the "experimental" ones.

   The terms "permit" (allow the traffic), "drop" (drop with no
   notification to sender), and "reject" (drop with appropriate
   notification to sender) are employed as defined in [RFC3871].
   Throughout this document we also employ the term "discard" as a
   generic term to indicate the act of discarding a packet, irrespective
   of whether the sender is notified of such packet drops.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

2.2.  Conventions

   This document clarifies some basic validation of IPv6 options, and
   specifies the default processing of them.  We recommend that a
   configuration option is made available to govern the processing of
   each IPv6 option type, on a per-EH-type granularity.  Such
   configuration options may include the following possible settings:

   o  Permit this IPv6 Option type

   o  Drop (and log) packets containing this IPv6 option type

   o  Reject (and log) packets containing this IPv6 option type (where
      the packet drop is signaled with an ICMPv6 error message)





Gont, et al.            Expires February 22, 2016               [Page 3]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   o  Rate-limit the processing of packets containing this IPv6 option
      type

   o  Ignore this IPv6 option type (forwarding packets that contain
      them)

   We note that special care needs to be taken when devices log packet
   drops/rejects.  Devices should count the number of packets dropped/
   rejected, but the logging of drop/reject events should be limited so
   as to not overburden device resources.

   Finally, we note that when discarding packets, it is generally
   desirable that the sender be signaled of the packet drop, since this
   is of use for trouble-shooting purposes.  However, throughout this
   document (when recommending that packets be discarded) we generically
   refer to the action as "discard" without specifying whether the
   sender is signaled of the packet drop.

3.  Considerations for All IPv6 Options

   Forwarding nodes that discard packets (by default) based on the
   presence of IPv6 options are known to cause connectivity failures and
   deployment problems.  Any forwarding node along an IPv6 packet's
   path, which forwards the packet for any reason, SHOULD do so
   regardless of any IPv6 Destination Options that are present, as
   required by [RFC2460].  Exceptionally, if a forwarding node is
   designed to examine IPv6 Destination Options for any reason, such as
   firewalling, it MUST recognise and deal appropriately with all
   standard IPv6 options types and SHOULD recognise and deal
   appropriately with all experimental IPv6 options.  The list of
   standard and experimental option types is maintained by IANA (see
   [IANA-IPV6-PARAM]), and implementors are advised to check this list
   regularly for updates.

   In the case of some options meant to be included in IPv6 extension
   headers other than Hop-by-Hop Options, [RFC2460] requires destination
   hosts to discard the corresponding packet if the option is
   unrecognised.  However, intermediate forwarding nodes SHOULD NOT do
   this, since doing so might cause them to inadvertently discard
   traffic using a recently standardised IPv6 option not yet recognised
   by the intermediate node.  The exceptions to this rule are discussed
   next.

   If a forwarding node discards a packet containing a standard IPv6
   option, it MUST be the result of a configurable policy and not just
   the result of a failure to recognise such an option.  This means that
   the discard policy for each standard type of IPv6 option MUST be




Gont, et al.            Expires February 22, 2016               [Page 4]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   individually configurable.  The default configuration SHOULD allow
   all standard IPv6 options.

   Experimental IPv6 options SHOULD be treated in the same way as
   standard IPv6 options, including an individually configurable discard
   policy.

   A node that processes the contents of an extension header MUST
   discard the corresponding packet if it contains any defined options
   that are not meant for the extension header being processed.  This
   document requests IANA to add a new column to [IANA-IPV6-PARAM] to
   clearly mark the IPv6 Extension Header type(s) for which each option
   (defined by IETF Standards Action or IESG Approval) is valid.

   A node that processes the contents of an IPv6 extension header MAY
   discard the corresponding packet if it contains any options that have
   become deprecated.  Whether or not such packets are dropped SHOULD be
   configurable, and the default setting MUST be to not drop such
   packets.

   A node that processes the contents of an extension header and
   encounters an undefined (unrecognised) IPv6 option MUST react to such
   option according to the highest-order two bits of the option type, as
   specified by Section 4.2 of [RFC2460].

   A node that processes an IPv6 extension header MAY discard a packet
   containing any experimental IPv6 options.

4.  Processing of currently-defined IPv6 Options

   The following subsections provide advice on how to process the IPv6
   options that have been defined at the time of this writing, according
   to the rules specified in the previous sections.

4.1.  Hop-by-Hop Options Header

   A node that processes the Hop-by-Hop Options extension header MUST
   discard the corresponding packet if it contains any options that are
   not valid for the Hop-by-Hop Options extension header
   [IANA-IPV6-PARAM].

   A node that processes the Hop-by-Hop Options extension header MUST
   discard a packet containing multiple instances (i.e., more than one)
   of this option in the Hop-by-Hop Options extension header:

   o  Type 0x05: Router Alert [RFC2711]





Gont, et al.            Expires February 22, 2016               [Page 5]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


      NOTE: The rationale for discarding the packet is that [RFC2711]
      forbids multiple instances of this option.

   A node that processes the Hop-by-Hop Options extension header MUST
   discard a packet that carries a Fragment Header and also contains
   this option in the Hop-by-Hop Options extension header:

   o  Type 0xC2: Jumbo Payload [RFC2675]

      NOTE: The rationale for discarding the packet is that [RFC2675]
      forbids the use of the Jumbo Payload Option in packets that carry
      a Fragment Header.

   A node that processes the Hop-by-Hop Options extension header MAY
   discard a packet containing any of the following options in that
   header:

   o  Type=0x4D: Deprecated

      NOTE: The rationale for discarding the packet is that the
      aforementioned option has been deprecated.

   A node that processes the Hop-by-Hop Options extension header MAY
   discard a packet containing any of the following options in that
   header:

   o  Type 0x1E: RFC3692-style Experiment [RFC4727]

   o  Type 0x3E: RFC3692-style Experiment [RFC4727]

   o  Type 0x5E: RFC3692-style Experiment [RFC4727]

   o  Type 0x7E: RFC3692-style Experiment [RFC4727]

   o  Type 0x9E: RFC3692-style Experiment [RFC4727]

   o  Type 0xBE: RFC3692-style Experiment [RFC4727]

   o  Type 0xDE: RFC3692-style Experiment [RFC4727]

   o  Type 0xFE: RFC3692-style Experiment [RFC4727]

      NOTE: This is in line with the corresponding specification in
      [RFC7045] for experimental extension headers.







Gont, et al.            Expires February 22, 2016               [Page 6]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


4.2.  Destination Options Header

   A node that processes the Destination Options header MUST discard a
   packet containing any options that are not valid for the Destination
   Options header [IANA-IPV6-PARAM].

   A node that processes the Destination Options extension header MAY
   discard a packet containing any of the following options in that
   header:

   o  Type 0x8A: Endpoint Identification [nimrod-eid] [NIMROD-DOC]

   o  Type 0x4D: Deprecated

      NOTE: The rationale for discarding the packet is that the
      aforementioned options have been deprecated.

   A node that processes the Destination Options extension header MAY
   discard a packet containing any of the following options in that
   header:

   o  Type 0x1E: RFC3692-style Experiment [RFC4727]

   o  Type 0x3E: RFC3692-style Experiment [RFC4727]

   o  Type 0x5E: RFC3692-style Experiment [RFC4727]

   o  Type 0x7E: RFC3692-style Experiment [RFC4727]

   o  Type 0x9E: RFC3692-style Experiment [RFC4727]

   o  Type 0xBE: RFC3692-style Experiment [RFC4727]

   o  Type 0xDE: RFC3692-style Experiment [RFC4727]

   o  Type 0xFE: RFC3692-style Experiment [RFC4727]

      NOTE: This is in line with the corresponding specification in
      [RFC7045] for experimental extension headers.

5.  IANA Considerations

   IANA is requested to add an extra column entitled "Extension Header
   Types" to the "Destination Options and Hop-by-Hop Options" registry
   [IANA-IPV6-PARAM], to clearly mark the IPv6 Extension Header types
   for which each option (defined by IETF Standards Action or IESG
   Approval) is valid (see the list below).  This also applies to
   Destination Options and Hop-by-Hop Options defined in the future.



Gont, et al.            Expires February 22, 2016               [Page 7]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   What follows is the initial list of IPv6 options and the
   corresponding marks that indicate which Extension Header type(s)
   these IPv6 options are valid for:

   +------+---------------------+------------------------------+-------+
   | Hex  |     Description     |          Reference           |   EH  |
   | Valu |                     |                              | Types |
   |  e   |                     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x00 |         Pad1        |          [RFC2460]           |   DH  |
   +------+---------------------+------------------------------+-------+
   | 0x01 |         PadN        |          [RFC2460]           |   DH  |
   +------+---------------------+------------------------------+-------+
   | 0xC2 |    Jumbo Payload    |          [RFC2675]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x63 |      RPL Option     |          [RFC6553]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x04 |        Tunnel       |          [RFC2473]           |   D   |
   |      | Encapsulation Limit |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x05 |     Router Alert    |          [RFC2711]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x26 |     Quick-Start     |          [RFC4782]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x07 |       CALIPSO       |          [RFC5570]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x08 |       SMF_DPD       |          [RFC6621]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0xC9 |     Home Address    |          [RFC6275]           |   D   |
   +------+---------------------+------------------------------+-------+
   | 0x8A |       Endpoint      |   [nimrod-eid][NIMROD-DOC]   |   D   |
   |      |    Identification   |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x8B |      ILNP Nonce     |          [RFC6744]           |   D   |
   +------+---------------------+------------------------------+-------+
   | 0x8C | Line-Identification |          [RFC6788]           |   D   |
   |      |        Option       |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x4D |      Deprecated     |                              |   U   |
   +------+---------------------+------------------------------+-------+
   | 0x6D |      MPL Option     |   [I-D.ietf-roll-trickle-    |   H   |
   |      |                     |            mcast]            |       |
   +------+---------------------+------------------------------+-------+
   | 0xEE |   IPv6 DFF Header   |          [RFC6971]           |   H   |
   +------+---------------------+------------------------------+-------+
   | 0x1E |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+



Gont, et al.            Expires February 22, 2016               [Page 8]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   | 0x3E |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x5E |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x7E |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0x9E |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0xBE |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0xDE |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+
   | 0xFE |    RFC3692-style    |          [RFC4727]           |   DH  |
   |      |      Experiment     |                              |       |
   +------+---------------------+------------------------------+-------+

   Additionally, the following legend should be added to the registry:

   D: Destination Options Header
   H: Hop-by-Hop Options Header
   U: Unknown

6.  Security Considerations

   Forwarding nodes that operate as firewalls MUST conform to the
   requirements in this document.  In particular, packets containing
   standard IPv6 options are only to be discarded as a result of an
   intentionally configured policy.

   These requirements do not affect a firewall's ability to filter out
   traffic containing unwanted or suspect IPv6 options, if configured to
   do so.  However, the changes do require firewalls to be capable of
   permitting any or all IPv6 options, if configured to do so.  The
   default configurations are intended to allow normal use of any
   standard IPv6 option, avoiding the interoperability issues described
   in Section 1 and Section 3.

   As noted above, the default configuration might discard packets
   containing experimental IPv6 options.






Gont, et al.            Expires February 22, 2016               [Page 9]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


7.  Acknowledgements

   This document is heavily based on [RFC7045], authored by Brian
   Carpenter and Sheng Jiang.

   The authors of this document would like to thank (in alphabetical
   order) Brian Carpenter, Mike Heard, and Jen Linkova, for providing
   valuable comments on earlier versions of this document.

8.  References

8.1.  Normative References

   [RFC1034]  Mockapetris, P., "Domain names - concepts and facilities",
              STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
              <http://www.rfc-editor.org/info/rfc1034>.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <http://www.rfc-editor.org/info/rfc2119>.

   [RFC2205]  Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S.
              Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
              Functional Specification", RFC 2205, DOI 10.17487/RFC2205,
              September 1997, <http://www.rfc-editor.org/info/rfc2205>.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
              December 1998, <http://www.rfc-editor.org/info/rfc2460>.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
              December 1998, <http://www.rfc-editor.org/info/rfc2473>.

   [RFC2675]  Borman, D., Deering, S., and R. Hinden, "IPv6 Jumbograms",
              RFC 2675, DOI 10.17487/RFC2675, August 1999,
              <http://www.rfc-editor.org/info/rfc2675>.

   [RFC2710]  Deering, S., Fenner, W., and B. Haberman, "Multicast
              Listener Discovery (MLD) for IPv6", RFC 2710,
              DOI 10.17487/RFC2710, October 1999,
              <http://www.rfc-editor.org/info/rfc2710>.

   [RFC2711]  Partridge, C. and A. Jackson, "IPv6 Router Alert Option",
              RFC 2711, DOI 10.17487/RFC2711, October 1999,
              <http://www.rfc-editor.org/info/rfc2711>.




Gont, et al.            Expires February 22, 2016              [Page 10]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   [RFC3692]  Narten, T., "Assigning Experimental and Testing Numbers
              Considered Useful", BCP 82, RFC 3692,
              DOI 10.17487/RFC3692, January 2004,
              <http://www.rfc-editor.org/info/rfc3692>.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              DOI 10.17487/RFC4302, December 2005,
              <http://www.rfc-editor.org/info/rfc4302>.

   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, DOI 10.17487/RFC4303, December 2005,
              <http://www.rfc-editor.org/info/rfc4303>.

   [RFC4304]  Kent, S., "Extended Sequence Number (ESN) Addendum to
              IPsec Domain of Interpretation (DOI) for Internet Security
              Association and Key Management Protocol (ISAKMP)",
              RFC 4304, DOI 10.17487/RFC4304, December 2005,
              <http://www.rfc-editor.org/info/rfc4304>.

   [RFC4727]  Fenner, B., "Experimental Values In IPv4, IPv6, ICMPv4,
              ICMPv6, UDP, and TCP Headers", RFC 4727,
              DOI 10.17487/RFC4727, November 2006,
              <http://www.rfc-editor.org/info/rfc4727>.

   [RFC4782]  Floyd, S., Allman, M., Jain, A., and P. Sarolahti, "Quick-
              Start for TCP and IP", RFC 4782, DOI 10.17487/RFC4782,
              January 2007, <http://www.rfc-editor.org/info/rfc4782>.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              DOI 10.17487/RFC5095, December 2007,
              <http://www.rfc-editor.org/info/rfc5095>.

   [RFC5201]  Moskowitz, R., Nikander, P., Jokela, P., Ed., and T.
              Henderson, "Host Identity Protocol", RFC 5201,
              DOI 10.17487/RFC5201, April 2008,
              <http://www.rfc-editor.org/info/rfc5201>.

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              DOI 10.17487/RFC5226, May 2008,
              <http://www.rfc-editor.org/info/rfc5226>.

   [RFC5533]  Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", RFC 5533, DOI 10.17487/RFC5533,
              June 2009, <http://www.rfc-editor.org/info/rfc5533>.





Gont, et al.            Expires February 22, 2016              [Page 11]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   [RFC5570]  StJohns, M., Atkinson, R., and G. Thomas, "Common
              Architecture Label IPv6 Security Option (CALIPSO)",
              RFC 5570, DOI 10.17487/RFC5570, July 2009,
              <http://www.rfc-editor.org/info/rfc5570>.

   [RFC6275]  Perkins, C., Ed., Johnson, D., and J. Arkko, "Mobility
              Support in IPv6", RFC 6275, DOI 10.17487/RFC6275, July
              2011, <http://www.rfc-editor.org/info/rfc6275>.

   [RFC6398]  Le Faucheur, F., Ed., "IP Router Alert Considerations and
              Usage", BCP 168, RFC 6398, DOI 10.17487/RFC6398, October
              2011, <http://www.rfc-editor.org/info/rfc6398>.

   [RFC6550]  Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
              JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
              Low-Power and Lossy Networks", RFC 6550,
              DOI 10.17487/RFC6550, March 2012,
              <http://www.rfc-editor.org/info/rfc6550>.

   [RFC6553]  Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
              Power and Lossy Networks (RPL) Option for Carrying RPL
              Information in Data-Plane Datagrams", RFC 6553,
              DOI 10.17487/RFC6553, March 2012,
              <http://www.rfc-editor.org/info/rfc6553>.

   [RFC6554]  Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with the Routing Protocol
              for Low-Power and Lossy Networks (RPL)", RFC 6554,
              DOI 10.17487/RFC6554, March 2012,
              <http://www.rfc-editor.org/info/rfc6554>.

   [RFC6621]  Macker, J., Ed., "Simplified Multicast Forwarding",
              RFC 6621, DOI 10.17487/RFC6621, May 2012,
              <http://www.rfc-editor.org/info/rfc6621>.

   [RFC6740]  Atkinson, RJ. and SN. Bhatti, "Identifier-Locator Network
              Protocol (ILNP) Architectural Description", RFC 6740,
              DOI 10.17487/RFC6740, November 2012,
              <http://www.rfc-editor.org/info/rfc6740>.

   [RFC6744]  Atkinson, RJ. and SN. Bhatti, "IPv6 Nonce Destination
              Option for the Identifier-Locator Network Protocol for
              IPv6 (ILNPv6)", RFC 6744, DOI 10.17487/RFC6744, November
              2012, <http://www.rfc-editor.org/info/rfc6744>.






Gont, et al.            Expires February 22, 2016              [Page 12]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   [RFC6788]  Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E.
              Nordmark, "The Line-Identification Option", RFC 6788,
              DOI 10.17487/RFC6788, November 2012,
              <http://www.rfc-editor.org/info/rfc6788>.

   [RFC6971]  Herberg, U., Ed., Cardenas, A., Iwao, T., Dow, M., and S.
              Cespedes, "Depth-First Forwarding (DFF) in Unreliable
              Networks", RFC 6971, DOI 10.17487/RFC6971, June 2013,
              <http://www.rfc-editor.org/info/rfc6971>.

   [RFC7045]  Carpenter, B. and S. Jiang, "Transmission and Processing
              of IPv6 Extension Headers", RFC 7045,
              DOI 10.17487/RFC7045, December 2013,
              <http://www.rfc-editor.org/info/rfc7045>.

   [RFC7112]  Gont, F., Manral, V., and R. Bonica, "Implications of
              Oversized IPv6 Header Chains", RFC 7112,
              DOI 10.17487/RFC7112, January 2014,
              <http://www.rfc-editor.org/info/rfc7112>.

8.2.  Informative References

   [Biondi2007]
              Biondi, P. and A. Ebalard, "IPv6 Routing Header Security",
              CanSecWest 2007 Security Conference, 2007,
              <http://www.secdev.org/conf/IPv6_RH_security-csw07.pdf>.

   [I-D.ietf-roll-trickle-mcast]
              Hui, J. and R. Kelsey, "Multicast Protocol for Low power
              and Lossy Networks (MPL)", draft-ietf-roll-trickle-
              mcast-12 (work in progress), June 2015.

   [I-D.ietf-v6ops-ipv6-ehs-in-real-world]
              Gont, F., Linkova, J., Chown, T., and S. LIU,
              "Observations on IPv6 EH Filtering in the Real World",
              draft-ietf-v6ops-ipv6-ehs-in-real-world-00 (work in
              progress), April 2015.

   [IANA-IPV6-PARAM]
              Internet Assigned Numbers Authority, "Internet Protocol
              Version 6 (IPv6) Parameters", December 2013,
              <http://www.iana.org/assignments/ipv6-parameters/
              ipv6-parameters.xhtml>.

   [NIMROD-DOC]
              Nimrod Documentation Page, ,
              "http://ana-3.lcs.mit.edu/~jnc/nimrod/".




Gont, et al.            Expires February 22, 2016              [Page 13]


Internet-Draft      Transm. and Proc. of IPv6 Options        August 2015


   [nimrod-eid]
              Lynn, C., "Endpoint Identifier Destination Option",  IETF
              Internet Draft, draft-ietf-nimrod-eid-00.txt, November
              1995.

   [RFC3871]  Jones, G., Ed., "Operational Security Requirements for
              Large Internet Service Provider (ISP) IP Network
              Infrastructure", RFC 3871, DOI 10.17487/RFC3871, September
              2004, <http://www.rfc-editor.org/info/rfc3871>.

   [RFC7126]  Gont, F., Atkinson, R., and C. Pignataro, "Recommendations
              on Filtering of IPv4 Packets Containing IPv4 Options",
              BCP 186, RFC 7126, DOI 10.17487/RFC7126, February 2014,
              <http://www.rfc-editor.org/info/rfc7126>.

Authors' Addresses

   Fernando Gont
   UTN-FRH / SI6 Networks
   Evaristo Carriego 2644
   Haedo, Provincia de Buenos Aires  1706
   Argentina

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com


   Will(Shucheng) Liu
   Huawei Technologies
   Bantian, Longgang District
   Shenzhen  518129
   P.R. China

   Email: liushucheng@huawei.com


   Ronald P. Bonica
   Juniper Networks
   2251 Corporate Park Drive
   Herndon, VA  20171
   US

   Phone: 571 250 5819
   Email: rbonica@juniper.net






Gont, et al.            Expires February 22, 2016              [Page 14]


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