ROLL                                                              J. Hui
Internet-Draft                                                     Cisco
Intended status: Standards Track                               R. Kelsey
Expires: January 14, April 22, 2013                                     Silicon Labs
                                                           July 13,
                                                        October 19, 2012

       Multicast Forwarding Using Trickle
                    draft-ietf-roll-trickle-mcast-01 Protocol for Low power and Lossy Networks (MPL)
                    draft-ietf-roll-trickle-mcast-02

Abstract

   This document specifies the Multicast Protocol for Low power and
   Lossy Networks (LLNs) are typically composed of
   resource constrained nodes communicating over links (MPL) that have dynamic
   characteristics.  Memory constraints coupled with temporal variations
   in link connectivity makes the use of topology maintenance to support provides IPv6 multicast challenging.  This document describes forwarding in
   constrained networks.  MPL avoids the use of
   Trickle need to efficiently forward construct or maintain
   any multicast forwarding topology, disseminating messages without to all MPL
   forwarders in an MPL domain.  MPL uses the need Trickle algorithm to drive
   packet transmissions for topology maintenance. both control and data-plane packets.
   Specific Trickle parameter configurations allow MPL to trade between
   dissemination latency and transmission efficiency.

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 January 14, April 22, 2013.

Copyright Notice

   Copyright (c) 2012 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
   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
     1.1.  Requirements Language
   2.  Terminology  . . . . . . . . . . . . . . . . . . . .  3
   2.  Terminology . . . . .  4
   3.  Overview . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Overview . . . . .  5
   4.  Message Formats  . . . . . . . . . . . . . . . . . . . . . .  5
   4.  Trickle Multicast Parameters .  7
     4.1.  MPL Option . . . . . . . . . . . . . . . . . . . . . . . .  7
   5.
     4.2.  ICMPv6 MPL Message Formats . . . . . . . . . . . . . . . . . . . .  8
       4.2.1.  MPL Window . . . . .  9
     5.1.  Trickle Multicast Option . . . . . . . . . . . . . . . . .  9
     5.2.  Trickle ICMPv6 Message
   5.  MPL Forwarder Behavior . . . . . . . . . . . . . . . . . . 10
       5.2.1.  Sequence List . . 11
     5.1.  Multicast Packet Dissemination . . . . . . . . . . . . . . 11
       5.1.1.  Trickle Parameters and Variables . . . . . . . . 11
   6.  Trickle Multicast Forwarder Behavior . . . 12
       5.1.2.  Proactive Propagation  . . . . . . . . . . . . . . . . 12
     6.1.  Managing
       5.1.3.  Reactive Propagation . . . . . . . . . . . . . . . . . 13
     5.2.  Sliding Windows  . . . . . . . . . . . . . . . . . 12
     6.2.  Trickle Timers . . . . 13
     5.3.  Transmission of MPL Multicast Packets  . . . . . . . . . . 15
     5.4.  Reception of MPL Multicast Packets . . . . . . . . . 12
     6.3.  Trickle Multicast Option Processing . . . 16
     5.5.  Transmission of ICMPv6 MPL Messages  . . . . . . . . . 13
     6.4.  Trickle ICMP Processing . . 16
     5.6.  Reception of ICMPv6 MPL Messages . . . . . . . . . . . . . 17
   6.  MPL Parameters . . 13 . . . . . . . . . . . . . . . . . . . . . . 19
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 20
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16 21
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 17 22
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 23
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 18 23
     10.2. Informative References . . . . . . . . . . . . . . . . . . 18 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 24

1.  Introduction

   The resource constraints of

   Low power and Lossy Networks (LLNs) typically operate with strict resource
   constraints in communication, computation, memory, and energy.  Such
   resource constraints may preclude the use of existing IPv6 multicast
   topology and forwarding mechanisms.
   Such networks are typically constrained in resources (limited channel
   capacity, processing power, energy capacity, memory).  In particular
   memory constraints may limit nodes to maintaining state for only a
   small subset of neighbors.  Limited channel and energy capacity
   require protocols to remain efficient and robust even in dense
   topologies.  Traditional IP multicast
   forwarding typically relies on topology maintenance mechanisms to efficiently
   forward multicast messages to
   the intended destinations.  In some cases, topology maintenance
   involves maintaining multicast trees to reach all subscribers of a multicast group.  Maintaining
   However, maintaining such topologies in LLNs is difficult especially
   when memory costly and may not be
   feasible given the available resources.

   Memory constraints are such that nodes can only may limit devices to maintaining links/routes to
   one or a few neighbors.  For this reason, the Routing Protocol for
   LLNs (RPL) specifies both storing and non-storing modes [RFC6550].
   The latter allows RPL routers to maintain only one or a few default route.  Dynamic
   routes towards a LLN Border Router (LBR) and use source routing to
   forward packets away from the LBR.  For the same reasons, a LLN
   device may not be able to maintain a multicast forwarding topology
   when operating with limited memory.

   Furthermore, the dynamic properties of wireless networks can make
   control traffic the
   cost of maintaining a multicast forwarding topology prohibitively
   expensive.  In wireless environments, topology maintenance may
   involve selecting a connected dominating set used to forward
   multicast messages to all nodes in an administrative domain.
   However, existing mechanisms often require two-hop topology
   information, which is more state than a LLN node may be able to
   handle.
   information and the cost of maintaining such information grows
   polynomially with network density.

   This document describes specifies the use of Trickle Multicast Protocol for Low power and
   Lossy Networks (MPL), which provides IPv6 multicast forwarding in LLNs.  Trickle provides a mechanism for controlled,
   density-aware flooding without
   constrained networks.  MPL avoids the need to construct or maintain a
   any multicast forwarding
   topology [RFC6206].

1.1.  Requirements Language topology, disseminating multicast messages
   to all MPL forwarders in an MPL domain.  By using the Trickle
   algorithm [RFC6206], MPL requires only small, constant state for each
   MPL device that initiates disseminations.  The Trickle algorithm also
   allows MPL to be density-aware, allowing the communication rate to
   scale logarithmically with density.

2.  Terminology

   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 RFC 2119 [RFC2119].

2.  Terminology

   Trickle Multicast Message  A IPv6 multicast datagram that includes a
                       Trickle Multicast option in the IPv6 Hop-by-Hop
                       Options header.

   Trickle Multicast Forwarder  A

   The following terms are used throughout this document:

   MPL forwarder       An IPv6 router that can process a Trickle
                       Multicast option and follows subscribes to the forwarding rules
                       specified MPL
                       multicast group and participates in this document.

   Trickle Multicast Domain  An administrative domain disseminating
                       MPL multicast packets.

   MPL multicast scope The multicast scope that defines MPL uses when forwarding
                       MPL multicast packets.  In other words, the
                       multicast scope of Trickle dissemination.  All routers
                       within a Trickle Multicast Domain participate in the same dissemination process.

   Seed IPv6 Destination Address
                       of an MPL multicast packet.

   MPL domain          A connected set of MPL forwarders that define the
                       extent of the MPL dissemination process.  As a
                       form of flood, all MPL forwarders in an MPL
                       domain will receive MPL multicast packets.  The router
                       MPL domain MUST be composed of at least one MPL
                       multicast scope and MAY be composed of multiple
                       MPL multicast scopes.

   MPL seed            A MPL forwarder that starts begins the dissemination
                       process for a Trickle an MPL multicast message. packet.  The Seed MPL
                       seed may be different than the node identified by the IPv6
                       Source address source of the
                       original multicast message.

3.  Overview

   Trickle packet.

   MPL seed identifier An identifier that uniquely identifies an MPL
                       forwarder within its MPL domain.

   original multicast forwarding implements a controlled, density-aware
   flood to disseminate a packet  An IPv6 multicast message to all nodes within a
   Trickle Multicast Domain.  The basic process packet that is similar to
   traditional flooding - nodes forward newly received multicast
   messages
                       disseminated using link-layer broadcasts.  Nodes maintain state of
   recently received MPL.

   MPL multicast messages to detect duplicates and ensure packet  An IPv6 multicast packet that each node receives at most one copy of each contains an MPL
                       Hop-by-Hop Option.  When either source or
                       destinations are beyond the MPL multicast message.

   Each Trickle scope,
                       the MPL multicast message carries a Trickle Multicast option packet is an IPv6-in-IPv6
                       packet that includes a SeedID contains an MPL Hop-by-Hop Option in
                       the outer IPv6 header and Sequence value.  The SeedID uniquely
   identifies encapsulates an
                       original multicast packet.  When both source and
                       destinations are within the Seed that initiated MPL multicast scope,
                       the message's dissemination
   process MPL Hop-by-Hop Option may be included
                       directly within the Trickle Multicast Domain.  Note that the Seed does
   not have original multicast packet.

3.  Overview

   MPL delivers IPv6 multicast packets by disseminating them to be all MPL
   forwarders within an MPL domain.  MPL dissemination is a form of
   flood.  An MPL forwarder may broadcast/multicast an MPL multicast
   packet out of the same node as the message's source.  It is possible physical interface on which it was received.
   Using link-layer broadcast/multicast allows MPL to tunnel a forward multicast message
   packets without explicitly identifying next-hop destinations.  An MPL
   forwarder may also broadcast/multicast MPL multicast packets out
   other interfaces to a Seed node and start disseminate the
   dissemination process from a message across different node within the Trickle
   Multicast Domain.

   The Sequence value establishes links.
   MPL does not build or maintain a total ordering of multicast messages
   disseminated by SeedID.  Nodes maintain a sliding window of recently
   received forwarding topology to
   forward multicast messages packets.

   Any MPL forwarder may initiate the dissemination process by serving
   as an MPL seed for each SeedID. an original multicast packet.  The sliding window
   establishes what messages can MPL seed may or
   may not be received and ensure at most one copy the same device as the source of each the original multicast message
   packet.  When the original multicast packet's source is received.  Messages outside the
   LLN, the MPL seed may be the ingress router.  Even if an original
   multicast packet source is within the LLN, the source may first
   forward the multicast packet to the MPL seed using IPv6-in-IPv6
   tunneling.  Because MPL state requirements grows with sequence values
   lower than the lower bound number of
   active MPL seeds, limiting the window MUST be ignored.  Messages number of MPL seeds reduces the amount
   of state that MPL forwarders must maintain.

   Because MPL typically broadcasts/multicasts MPL packets out of the
   same interface on which they were received, MPL forwarders are likely
   to receive an MPL multicast packet more than once.  The MPL seed tags
   each original multicast packet with an MPL seed identifier and a
   sequence values stored within number.  The sequence number provides a total ordering of
   MPL multicast packets disseminated by the sliding window MUST be
   ignored.  All other messages MUST MPL seed.

   MPL defines a new IPv6 Hop-by-Hop Option, the MPL Option, to include
   MPL-specific information along with the original multicast packet.
   Each IPv6 multicast packet that MPL disseminates includes the MPL
   Option.  Because the original multicast packet's source and the MPL
   seed may not be received, advancing the sliding
   window if necessary.  Larger sequence values always take precedence.
   The sliding window can same device, the MPL Option may be of variable size, trading memory
   requirements added to the
   original multicast packet en-route.  To allow Path MTU discovery to
   work properly, MPL encapsulates the original multicast packet in
   another IPv6 header that includes the MPL Option.

   Upon receiving a new MPL multicast packet for reliability forwarding, the MPL
   forwarder may proactively transmit the MPL multicast packet packet a
   limited number of disseminating multiple messages
   simultaneously.

   Trickle's density-aware properties come from its suppression
   mechanism.  When suppression is enabled, nodes periodically advertise times and then falls back into an optional reactive
   mode.  In maintenance mode, an MPL forwarder buffers recently
   received MPL multicast packets and advertises a summary of recently
   received MPL multicast messages.  These
   advertisements allow nodes packets from time to time, allowing
   neighboring MPL forwarders to determine if they have any additional
   multicasts new
   multicast packets to offer to neighboring nodes.  A multicast message is
   only retransmitted upon receiving positive indication that a neighbor
   has not yet received that multicast message.

   Nodes suppress advertisement transmissions or receive.

   MPL forwarders schedule their packet (control and multicast
   retransmissions after recently receiving "consistent" advertisements.
   A node determines that a neighbor's advertisement is "consistent" data) transmissions
   using the Trickle algorithm [RFC6206].  Trickle's adaptive
   transmission interval allows MPL to quickly disseminate messages when neither node has
   there are new MPL multicast messages to offer to the other.
   The suppression packets, but reduces transmission
   overhead as the number of redundant transmissions dissemination process completes.  Trickle's
   suppression mechanism and is
   what allows Trickle transmission time selection allow MPL's
   communication rate to maintain low channel utilization scale logarithmically with density.

4.  Message Formats

4.1.  MPL Option

   The MPL Option is carried in dense
   environments.  However, suppression trades low control overhead for
   longer propagation times.  When using suppression, Trickle's
   propagation times often have a long-tail distribution.

   Trickle provides an adaptive timer, called IPv6 Hop-by-Hop Options header,
   immediately following the Trickle timer.  When
   receiving an "inconsistent" advertisement, nodes reset IPv6 header.  The MPL Option has the Trickle
   timer period
   following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                                     |  Option Type  |  Opt Data Len |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | S |M|   rsv   |   sequence    |      seed-id (optional)       |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option Type         XX (to be confirmed by IANA).

   Opt Data Len        Length of the Option Data field in octets.  MUST
                       be set to a small period so that dissemination happens quickly.
   The Trickle timer period doubles when either 2 or 4.

   S                   2-bit unsigned integer.  Identifies the period expires and no
   "inconsistent" advertisements have been received, reducing control
   overhead when length of
                       seed-id. 0 indicates that the network seed-id is 0 and
                       not included in a consistent state.

   This document does allow configurations the MPL Option. 1 indicates that disable
                       the suppression
   mechanism, reducing Trickle Multicast Forwarding to simple flooding.
   This can be done by setting seed-id is a 16-bit unsigned integer. 2
                       indicates that the suppression threshold for seed-id is a 64-bit unsigned
                       integer. 3 indicates that the seed-id is a 128-
                       bit unsigned integer.

   M                   1-bit flag. 0 indicates that the value in
                       sequence is not the greatest sequence number that
                       was received
   "consistent" advertisements from the MPL seed.

   rsv                 5-bit reserved field.  MUST be set to infinity.  In this mode, Trickle
   advertisements are not sent since consistency checks are not
   performed.  Instead, nodes simply retransmit zero and
                       incoming MPL multicast messages packets in which they are trying to forward.

4.  Trickle Multicast Parameters

   All Trickle multicast forwarders within a Trickle multicast domain
                       not zero MUST be configured with two sets dropped.

   sequence            8-bit unsigned integer.  Identifies relative
                       ordering of configurations (one for each
   value MPL multicast packets from the source
                       identified by seed-id.

   seed-id             Uniquely identifies the MPL seed that initiated
                       dissemination of the M flag).  Each configuration has five parameters:

   Imin MPL multicast packet.  The minimum Trickle timer interval as defined in
                       [RFC6206].

   Imax
                       size of seed-id is indicated by the S field.

   The maximum Option Data of the Trickle timer interval as defined in
                       [RFC6206].

   k                   The redundancy constant Multicast option MUST NOT change as defined in [RFC6206].

   Tactive             The duration that a multicast forwarder can
                       attempt to forward a
   the MPL multicast message.
                       Specified in units of Imax.

   Tdwell              The duration packet is forwarded.  Nodes that a multicast forwarder must
                       maintain sliding window state for SeedID after
                       receiving do not understand
   the last multicast message from SeedID.
                       Specified in units of Imax.

   Tactive specifies Trickle Multicast option MUST discard the time duration that a node may retransmit a
   multicast message in attempt to forward it packet.  Thus,
   according to neighboring nodes.
   Larger values of Tactive increases [RFC2460] the number three high order bits of retransmissions and
   overall dissemination reliability.

   Tdwell specifies the time duration for maintaining sliding window
   state Option Type
   must be set to ensure that a multicast message from SeedID '010'.  The Option Data length is received at
   most once.  Larger values of Tdwell decreases variable.

   The seed-id uniquely identifies an MPL seed within the MPL domain.
   When seed-id is 128 bits (S=3), the likelihood MPL seed MAY use an IPv6 address
   assigned to one of its interfaces that a
   node will receive a multicast message more than once.

   The specific values are left out of is unique within the MPL
   domain.  Managing MPL seed identifiers is not within scope of this document as they
   are dependent on link-specific properties.  How those parameters are
   configured are also left out of scope.
   document.

   The Trickle multicast parameters allow both aggressive and
   conservative multicast forwarding strategies.  For example, an
   aggressive strategy may specify each multicast forwarder to
   retransmit any newly received message 3 times on a short fixed period
   and maintain state for 12 retransmission periods to avoid receiving
   duplicate messages.  This aggressive policy can be specified using sequence field establishes a
   Trickle parameter set total ordering of Imin = Imax = 100ms, k = infinity, Tactive =
   3, and Tdwell = 12.  Setting k to infinity disables MPL multicast
   packets from the Trickle
   suppression mechanism.

   A conservative same MPL seed.  The MPL seed MUST increment the
   sequence field's value on each new MPL multicast forwarding strategy utilizes Trickle
   suppression and packet that it
   disseminates.  Implementations MUST follow the Serial Number
   Arithmetic as defined in [RFC1982] when incrementing a larger Imax sequence value
   or comparing two sequence values.

   Future updates to minimize redundant
   transmissions.  One such conservative policy is a Trickle parameter
   set of Imin = 100ms, Imax = 30min, k = 1, Tactive = 3, and Tdwell =
   12.

5.  Message Formats

5.1.  Trickle Multicast Option

   The Trickle Multicast option is carried in an IPv6 Hop-by-Hop Options
   header, immediately this specification may define additional fields
   following the IPv6 header. seed-id field.

4.2.  ICMPv6 MPL Message

   The Trickle Multicast
   option MPL forwarder uses ICMPv6 MPL messages to advertise information
   about recently received MPL multicast packets.  The ICMPv6 MPL
   message has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
                                     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Option     Type      |  Opt Data Len     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |       SeedID (optional)       |M|          Sequence                                                               |
     .                       MPL Window[1..n]                        .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Option

   IP Fields:

   Source Address      A link-local address assigned to the sending
                       interface.

   Destination Address The link-local all-nodes MPL forwarders multicast
                       address (FF02::TBD).

   Hop Limit           255

   ICMPv6 Fields:

   Type                XX (to be confirmed by IANA).

   Opt Data Len        Length

   Code                0

   Checksum            The ICMP checksum.  See [RFC4443].

   MPL Window[1..n]    List of the Option Data field one or more MPL Windows (defined in octets.  MUST
                       be set
                       Section 4.2.1).

   An MPL forwarder transmits an ICMPv6 MPL message to either 2 or 4.

   SeedID              Uniquely identifies a Trickle advertise
   information about buffered MPL multicast seed packets.  More explicitly,
   the ICMPv6 MPL message encodes the sliding window state (described in
   Section 5.2) that
                       initiated the dissemination process. MPL forwarder maintains for each MPL seed.  The SeedID
                       field is optional and only appears when Opt Data
                       Len is set
   advertisement serves to 4.  When Opt Data Len is set indicate to 2, neighboring MPL forwarders
   regarding newer messages that it may send or the SeedID is equivalent neighboring MPL
   forwarders have yet to receive.

4.2.1.  MPL Window

   An MPL Window encodes the IPv6 Source
                       address.

   M                   Mode flag.  Identifies one of two Trickle
                       parameters sliding window state (described in
   Section 5.2 that the MPL forwarder maintains for an MPL seed.  Each
   MPL Window has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     w-min     |   w-len   | S |  seed-id (0, 2 or 16 octets)  |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .              buffered-mpl-packets (0 to use when forwarding this multicast
                       message.

   Sequence            Identifies relative ordering 8 octets)             .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   w-min               8-bit unsigned integer.  Indicates the first
                       sequence number associated with the first bit in
                       buffered-mpl-packets.

   w-len               6-bit unsigned integer.  Indicates the size of multicast
                       messages from
                       the source identified by SeedID. sliding window and the number of valid bits
                       in buffered-mpl-packets.  The Option Data sliding window's
                       upper bound is the sum of w-min and w-len.

   S                   2-bit unsigned integer.  Identifies the Trickle Multicast option MUST NOT change en-
   route.  Nodes length of
                       seed-id. 0 indicates that do not understand the Trickle Multicast option
   MUST skip over this option seed-id value is 0
                       and continue processing the header.  Thus,
   according to [RFC2460] not included in the three high order bits of MPL Option. 1 indicates
                       that the Option Type
   must be equal set to zero.  The Option Data length seed-id value is variable.

   The SeedID uniquely identifies a Trickle multicast seed within 16-bit unsigned
                       integer. 2 indicates that the
   Trickle multicast domain.  The SeedID field may either be an IPv6
   address assigned to the seed node or seed-id value is a managed 16-bit value.  In
   either case,
                       128-bit unsigned integer. 3 is reserved.

   seed-id             Indicates the SeedID MUST be unique within MPL seed associated with this
                       sliding window.

   buffered-mpl-packets  Variable-length bit vector.  Identifies the Trickle
                       sequence numbers of MPL multicast
   domain.  Managing packets that
                       the SeedID namespace MPL forwarder has buffered.  The sequence
                       number is left out of scope. determined by w-min + i, where i is the
                       offset within buffered-mpl-packets.

   The M flag identifies one of two Trickle parameters MPL Window does not have any octet alignment requirement.

5.  MPL Forwarder Behavior

   An MPL forwarder implementation needs to use when
   forwarding the message.  This capability manage sliding windows for
   each active MPL seed.  The sliding window allows a Trickle the MPL forwarder to
   determine what multicast packets to accept and what multicast packets
   are buffered.  An MPL forwarder must also manage MPL packet
   transmissions.

5.1.  Multicast
   Domain Packet Dissemination

   MPL uses the Trickle algorithm to support control packet transmissions when
   disseminating MPL multicast packets [RFC6206].  MPL provides two different
   propagation mechanisms for disseminating MPL multicast packets.

   1.  With proactive propagation, an MPL forwarder transmits buffered
       MPL multicast packets using the Trickle parameter sets that make
   different algorithm.  This method
       is called proactive propagation time vs. control overhead trade-offs.

   Sequence establishes a relative ordering of since an MPL forwarder actively
       transmits MPL multicast packets without discovering that a
       neighboring MPL forwarder has yet to receive the message.

   2.  With reactive propagation, an MPL forwarder transmits ICMPv6 MPL
       messages from using the same SeedID.  The source MUST increment Trickle algorithm.  An MPL forwarder only
       transmits buffered MPL multicast packets upon discovering that
       neighboring devices have not yet to receive the Sequence value when
   sourcing corresponding MPL
       multicast packets.

   When receiving a new Trickle multicast message.  Implementations MUST
   follow the Serial Number Arithmetic as defined in [RFC1982].

5.2.  Trickle ICMPv6 Message

   The Trickle ICMP message is used packet, an MPL forwarder first
   utilizes proactive propagation to advertise metadata forward the MPL multicast packet.
   Proactive propagation reduces dissemination latency since it does not
   require discovering that neighboring devices have not yet received
   the MPL multicast packet.  MPL forwarders utilize proactive
   propagation for recently newly received Trickle MPL multicast messages.  The Trickle ICMP message has
   the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |     Type      |     Code      |          Checksum             |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                       Sequence List[1..n]                     .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   IP Fields:

   Source Address      A link-local address assigned packets since they can
   assume that some neighboring MPL forwarders have yet to receive the sending
                       interface.

   Destination Address The link-local all-nodes (FF02::1) or link-local
                       all-routers (FF02::2)
   MPL multicast address.

   Hop Limit           255

   ICMP Fields:

   Type                XX (to packet.  After a limited number of MPL multicast packet
   transmissions, the MPL forwarder may terminate proactive propagation
   for the MPL multicast packet.

   An MPL forwarder may optionally use reactive propagation to continue
   the dissemination process with lower communication overhead.  With
   reactive propagation, neighboring MPL forwarders use ICMPv6 MPL
   messages to discover new MPL multicast messages that have not yet
   been received.  When discovering that a neighboring MPL forwarder has
   not yet received a new MPL multicast packet, the MPL forwarder
   enables proactive propagation again.

5.1.1.  Trickle Parameters and Variables

   As specified in RFC 6206 [RFC6206], a Trickle timer runs for a
   defined interval and has three configuration parameters: the minimum
   interval size Imin, the maximum interval size Imax, and a redundancy
   constant k.

   MPL defines a fourth configuration parameter, TimerExpirations, which
   indicates the number of Trickle timer expiration events that occur
   before terminating the Trickle algorithm.

   Each MPL forwarder maintains a separate Trickle parameter set for the
   proactive and reactive propagation methods.  TimerExpirations MUST be confirmed by IANA).

   Code
   greater than 0

   Checksum            The ICMP checksum.  See [RFC4443].

   Sequence List[1..n] List of zero, one, or more Sequence Lists
                       (defined for proactive propagation.  TimerExpirations MAY be
   set to 0 for reactive propagation, which effectively disables
   reactive propagation.

   As specified in Section 5.2.1).

   The RFC 6206 [RFC6206], a Trickle ICMP message advertises sliding windows maintained by timer has three
   variables: the current interval size I, a time within the current
   interval t, and a counter c.

   MPL defines a fourth variable, e, which counts the number of Trickle
   timer expiration events since the Trickle timer was last reset.

5.1.2.  Proactive Propagation

   With proactive propagation, the MPL forwarder transmits buffered MPL
   multicast packets using the Trickle algorithm.  Each buffered MPL
   multicast forwarder.  The advertisement serves packet that is proactively being disseminated with
   proactive propagation has an associated Trickle timer.  Adhering to notify neighbors
   Section 5 of
   newer messages RFC 6206 [RFC6206], this document defines the following:

   o  This document defines a "consistent" transmission for proactive
      propagation as receiving an MPL multicast packet that it can propagate or has yet to receive.  Only
   entries the same
      MPL seed identifier and sequence number as a buffered MPL packet.

   o  This document defines an "inconsistent" transmission for messages where Tactive proactive
      propagation as receiving an MPL multicast packet that has the same
      MPL seed identifier, the M flag set, and has a sequence number
      less than the buffered MPL multicast packet's sequence number.

   o  This document does not expired define any external "events".

   o  This document defines both MPL multicast packets and ICMPv6 MPL
      multicast packets as Trickle messages.  These messages are included defined
      in the ICMP message. sections below.

   o  The actions outside the Trickle algorithm that the protocol takes
      involve managing sliding windows are encoded using a Sequence
   List, defined window state, and is specified in
      Section 5.2.1.

5.2.1.  Sequence List 5.2.

5.1.3.  Reactive Propagation

   With reactive propagation, the MPL forwarder transmits ICMPv6 MPL
   messages using the Trickle algorithm.  A Sequence List contains MPL forwarder maintains a list of Sequence values
   single Trickle timer for a SeedID.
   Each Sequence List has the following format:

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |S|M|    rsv    |    SeqLen     |    SeedID (2 or 16 octets)    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                       Sequence[1..SeqLen]                     .
     .                                                               .
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   S                   Indicates length of SeedID.  When set to 0,
                       SeedID is 16 octets. reactive propagation with each MPL domain.
   When set to 1, SeedID REACTIVE_TIMER_EXPIRATIONS is 2
                       octets.

   M                   Indicates one of two 0, the MPL forwarder does not
   execute the Trickle parameter sets used algorithm for disseminating multicast messages.

   SeqLen              Number reactive propagation and reactive
   propagation is disabled.  Adhering to Section 5 of 2-octet Sequence entries.

   SeedID              Copied from RFC 6206
   [RFC6206], this document defines the following:

   o  This document defines a recently received Trickle Multicast
                       option.

   Sequence[1..SeqLen] List of recently received Sequence values from
                       SeedID.  Note "consistent" transmission for reactive
      propagation as receiving an ICMPv6 MPL message that indicates
      neither the Sequence value is only 15
                       bits and the highest order bit MUST be set receiving nor transmitting node has new MPL multicast
      packets to 0.

6.  Trickle Multicast Forwarder Behavior

   A Trickle Multicast Forwarder implementation needs offer.

   o  This document defines an "inconsistent" transmission for reactive
      propagation as receiving an ICMPv6 MPL message that indicates
      either the receiving or transmitting node has at least one new MPL
      multicast packet to manage offer.

   o  This document defines an "event" for reactive propagation as
      updating any sliding
   windows window (i.e. changing the value of WindowMin,
      WindowMax, or the set of buffered MPL multicast packets) in
      response to receiving an MPL multicast packet.

   o  This document defines both MPL multicast packets and ICMPv6 MPL
      multicast packets as Trickle timers. messages.  These mechanisms are used to determine
   when received messages should be accepted, when ICMP messages are
   transmitted, defined
      in the sections below.

   o  The actions outside the Trickle algorithm that the protocol takes
      involve managing sliding window state, and when multicast messages are retransmitted.

6.1.  Managing is specified in
      Section 5.2.

5.2.  Sliding Windows

   Every Trickle multicast MPL forwarder MUST maintain a sliding window of
   Sequence values sequence
   numbers for each SeedID that generated MPL seed of recently received MPL packets.  The
   sliding window performs two functions:

   1.  Indicate what MPL multicast messages. packets the MPL forwarder should
       accept.

   2.  Indicate what MPL multicast packets are buffered and may be
       transmitted to neighboring MPL forwarders.

   Each sliding window logically consists of:

   1.  A lower-bound sequence number, WindowMin, that represents the
       sequence number of the oldest MPL multicast packet the MPL
       forwarder is willing to receive or has buffered.  An MPL
       forwarder MUST ignore any MPL multicast packet that has sequence
       value less than than WindowMin.

   2.  An upper-bound sequence value, WindowMax, that represents the
       sequence number of the next MPL multicast packet that the MPL
       forwarder expects to receive.  An MPL forwarder MUST accept any
       MPL multicast packet that has sequence number greater than or
       equal to WindowMax.

   3.  A list of MPL multicast packets, BufferedPackets, buffered by the
       MPL forwarder.  Each entry in BufferedPackets MUST have a
       sequence number in the range [WindowMin, WindowMax).

   4.  A timer, HoldTimer, that indicates the minimum lifetime of the
       sliding window.  The MPL forwarder MUST NOT free a sliding window
       before HoldTimer expires.

   When receiving a Trickle an MPL multicast message, packet, if no existing sliding window
   exists for the SeedID, MPL seed, the MPL forwarder MUST create a new sliding
   window MUST be created before accepting the message.  If MPL multicast packet.  The MPL forwarder
   may reclaim memory constraints are such that resources by freeing a
   new sliding window for another
   MPL seed if its HoldTimer has expired.  If, for any reason, the MPL
   forwarder cannot be created, then create a new sliding window, it MUST discard the message must be
   ignored.
   packet.

   If a sliding window exists for the SeedID, MPL seed, the message must be
   ignored MPL forwarder MUST
   ignore the MPL multicast packet if the message's Sequence value falls below packet's sequence number is
   less than WindowMin or appears in BufferedPackets.  Otherwise, the
   MPL forwarder MUST accept the packet and determine whether or not to
   forward the lower bound
   of packet and/or pass the window or appears in packet to the list of stored Sequence values within next higher layer.

   When accepting an MPL multicast packet, the window.  All other messages MPL forwarder MUST be received.

   When receiving a message, update
   the sliding window MUST be updated with based on the
   message's Sequence value. packet's sequence number.  If the Sequence value
   sequence number is larger not less than WindowMax, the
   upper bound of MPL forwarder MUST
   set WindowMax to 1 greater than the window, packet's sequence number.  If
   WindowMax - WindowMin > MPL_MAX_WINDOW_SIZE, the new message establishes MPL forwarder MUST
   increment WindowMin such that WindowMax - WindowMin <=
   MPL_MAX_WINDOW_SIZE.  At the new upper
   bound.

   Memory constraints may limit same time, the total number of Sequence values MPL forwarder MUST free
   any entries in BufferedPackets that
   can be stored.  An entry may be reclaimed before have a sequence number less than
   WindowMin.

   If the dwell time
   expires if MPL forwarder has available memory resources, it serves as MUST buffer
   the lower bound of MPL multicast packet for proactive propagation.  If not enough
   memory resources are available to buffer the window and packet, the window
   has more MPL
   forwarder MUST increment WindowMin and free entries in
   BufferedPackets that have a sequence number less than one entry.  Note WindowMin until
   enough memory resources are available.  Incrementing WindowMin will
   ensure that entries can be reclaimed the MPL forwarder does not accept previously received
   packets.

   An MPL forwarder MAY reclaim memory resources from sliding windows
   for other SeedIDs.

   When only MPL seeds.  If a sliding window for another MPL seed is
   actively disseminating messages and has more than one entry in its
   BufferedPackets, the MPL forwarder may free entries for that MPL seed
   by incrementing WindowMin as described above.

   If the MPL forwarder cannot free enough memory resources to buffer
   the MPL multicast packet, the MPL forwarder MUST set WindowMin to 1
   greater than the packet's sequence number.

   When memory resources are available, an MPL forwarder SHOULD buffer a
   MPL multicast packet until the proactive propagation completes (i.e.
   the Trickle algorithm stops execution) and MAY buffer for longer.
   After proactive propagation completes, the MPL forwarder may advance
   WindowMin to the packet's sequence number to reclaim memory
   resources.  When the MPL forwarder no longer buffers any packets, it
   MAY set WindowMin equal to WindowMax.  When setting WindowMin equal
   to WindowMax, the MPL forwarder MUST initialize HoldTimer to
   WINDOW_HOLD_TIME and start HoldTimer.  After HoldTimer expires, the
   MPL forwarder MAY free the sliding window remains, that entry to reclaim memory
   resources.

5.3.  Transmission of MPL Multicast Packets

   The MPL forwarder manages buffered MPL multicast packet transmissions
   using the Trickle algorithm.  When adding a packet to
   BufferedPackets, the MPL forwarder MUST NOT
   be reclaimed until its dwell create a Trickle timer expires.  Maintaining for
   the packet and start execution of the largest
   sequence value received from a SeedID ensures that earlier messages
   are received at most once.

6.2. Trickle Timers

   A algorithm.

   After PROACTIVE_TIMER_EXPIRATIONS Trickle multicast timer events, the MPL
   forwarder maintains two Trickle timers
   parameterized on MUST stop executing the S flag.  The Trickle timer is maintained as
   described in [RFC6206]. algorithm.  When suppression is enabled (i.e. k is finite), a Trickle
   transmission event consists of transmitting a Trickle ICMP message.

   If buffered
   MPL multicast packet does not have an "inconsistent" advertisement was received during active Trickle timer, the MPL
   forwarder MAY free the buffered packet by advancing WindowMin to 1
   greater than the packet's sequence number.

   Each interface that period, supports MPL is configured with exactly one MPL
   multicast messages scope.  The MPL multicast scope MUST be site-local or
   smaller and defaults to link-local.  A scope larger than link-local
   MAY be used only when that caused scope corresponds exactly to the inconsistency are also
   retransmitted.

   When suppression is disabled (i.e. k is infinite), a Trickle
   transmission event consists MPL
   domain.

   An MPL domain may therefore be composed of transmitting one or more MPL multicast messages that
   have been received within
   scopes.  For example, the Tactive time window.

   This document defines receiving MPL domain may be composed of a "consistent" transmission as
   receiving single MPL
   multicast scope when using a Trickle ICMP message that indicates neither site-local scope.  Alternatively, the receiving
   nor transmitting node has new
   MPL domain may be composed of multiple MPL multicast messages scopes when
   using a link-local scope.

   IPv6-in-IPv6 encapsulation MUST be used when using MPL to offer.

   This document defines receiving forward an "inconsistent" transmission as
   receiving a Trickle ICMP message that indicates either receiving
   original multicast packet whose source or
   transmitting node has destination address is
   outside the MPL multicast scope.  IPv6-in-IPv6 encapsulation is
   necessary to support Path MTU discovery when the MPL forwarder is not
   the source of the original multicast packet.  IPv6-in-IPv6
   encapsulation also allows an MPL forwarder to remove the MPL Option
   when forwarding the original multicast packet over a new link that does
   not support MPL.  The destination address scope for the outer IPv6
   header MUST be the MPL multicast scope.

   When an MPL domain is composed of multiple MPL multicast message to offer.  An
   "inconsistent" transmission also includes receiving a new scopes (e.g.
   when the MPL multicast
   message.

6.3.  Trickle Multicast Option Processing

   All IPv6 datagrams containing a Trickle Multicast option scope is link-local), an MPL forwarder MUST have a
   decapsulate and encapsulate the original multicast packet when
   crossing between different MPL multicast scopes.  In doing so, the
   MPL forwarder MUST duplicate the MPL Option, unmodified, in the new
   outer IPv6 Destination address.  If header.

   The IPv6 destination address of the MPL multicast packet is the all-
   MPL-forwarders multicast address (TBD).  The scope of the IPv6 Destination
   destination address is not a set to the MPL multicast scope.

5.4.  Reception of MPL Multicast Packets

   Upon receiving an MPL multicast address, packet, the MPL forwarder first
   determines whether or not to accept and buffer the MPL multicast
   packet based on its MPL seed and sequence value, as specified in
   Section 5.2.

   If the MPL forwarder MUST drop accepts the datagram.

   A MPL multicast packet, the MPL
   forwarder MUST drop determines whether or not to deliver the original multicast message
   packet to the next higher layer.  For example, if it cannot
   ensure that the MPL multicast
   packet uses IPv6-in-IPv6 encapsulation, the MPL forwarder removes the
   outer IPv6 header, which also removes MPL Option.

5.5.  Transmission of ICMPv6 MPL Messages

   The MPL forwarder generates and transmits a new ICMPv6 MPL message has never been received before.  This occurs
   when
   whenever Trickle requests a transmission.  The MPL forwarder includes
   an encoding of each sliding window in the Sequence value ICMPv6 MPL message.

   Each sliding window is encoded using an MPL Window entry, defined in
   Section 5.2.  The MPL forwarder sets the MPL Window fields as
   follows:

   S  If the MPL seed identifier is 0, set S to 0.  If the MPL seed
      identifier is below within the range [1, 65535], set S to 2.  Otherwise,
      set S to 3.

   w-min  Set to the lower bound of the sliding window for SeedID or when an entry already exists for (i.e.
      WindowMin).

   w-len  Set to the length of the Sequence
   value.

   If no sliding window state for SeedID exists, (i.e.  WindowMax - WindowMin).

   seed-id  If S is non-zero, set to the MPL seed identifier.

   buffered-mpl-packets  Set each bit that represents a sequence number
      of a packet in BufferedPackets to 1.  Set all other bits to 0.
      The i'th bit in buffered-mpl-packets represents a sequence number
      of w-min + i.

5.6.  Reception of ICMPv6 MPL Messages

   An MPL forwarder processes each ICMPv6 MPL message that it receives
   to determine if it has any new MPL multicast packets to receive or
   offer.

   An MPL forwarder
   MUST allocate determines if a new sliding window for the SeedID before accepting MPL multicast packet has not
   been received from a neighboring node if any of the message.  If following
   conditions hold true:

   1.  The ICMPv6 MPL message includes an MPL Window for an MPL seed
       that does not have a corresponding sliding window cannot be allocated, the forwarder
   MUST drop the message.

   Upon accepting the message, the forwarder MUST enter entry on the
       MPL forwarder.

   2.  The neighbor has a packet in its BufferedPackets that has
       sequence value greater than or equal to WindowMax (i.e. w-min +
       w-len >= WindowMax).

   3.  The neighbor has a packet in its BufferedPackets that has
       sequence number within range of the sliding window and decrement the IPv6 Hop Limit.  If but is not
       included in BufferedPackets (i.e. the
   IPv6 Hop Limit i'th bit in buffered-mpl-
       packets is non-zero, set to 1, where the sequence number is w-min + i).

   When an MPL forwarder MUST buffer the message for
   retransmission for the duration specified determines that it has not yet received a new
   MPL multicast packet buffered by Tactive.

6.4.  Trickle ICMP Processing

   Processing a neighboring device, the MPL
   forwarder resets the Trickle ICMP message involves determining timer associated with reactive
   propagation.

   An MPL forwarder determines if either the
   receiver or transmitter has new multicast messages to offer.

   The transmitter an entry in BufferedPackets has new multicast messages to offer not
   been received by a neighboring MPL forwarder if any (SeedID,
   Sequence) pair falls within an existing sliding window for SeedID but of the following
   conditions hold true:

   1.  The ICMPv6 MPL message does not have include an associated entry. MPL Window for the
       packet's MPL seed.

   2.  The transmitter has new multicast messages packet's sequence number is greater than or equal to offer if the (SeedID,
   Sequence) pair
       neighbor's WindowMax value (i.e. the packet's sequence number is great
       greater than or equal to w-min + w-len).

   3.  The packet's sequence number is within the upper bound range of an existing the
       neighbor's sliding window for SeedID.

   The receiver has new multicast messages [WindowMin, WindowMax), but not
       included in the neighbor's BufferedPacket (i.e. the packet's
       sequence number is greater than or equal to w-min, strictly less
       than w-min + w-len, and the corresponding bit in buffered-mpl-
       packets is set to offer if any 0.

   When an MPL forwarder determines that it has at least one buffered
   messages are
   MPL multicast packet that has not listed in yet been received by a neighbor,
   the Trickle ICMP message and MPL forwarder resets the Trickle
   ICMP message contains a (SeedID, Sequence) pair timer associated with reactive
   propagation.  Additionally, for a prior multicast
   message.

   The receiver has a new multicast message to offer if any each buffered
   messages does not have an associated SeedID entry in MPL multicast packet
   that should be transferred, the MPL forwarder MUST reset the Trickle ICMP
   message.
   timer and reset e to 0 for proactive propagation.  If neither receiver nor transmitter the Trickle
   timer for proactive propagation has new multicast messages to
   offer, already stopped execution, the multicast
   MPL forwarder logs MUST initialize a consistent event by
   incrementing c, as described in [RFC6206].

   If either receiver or transmitter has new multicast messages to
   offer, Trickle timer and start execution
   of the multicast Trickle algorithm.

6.  MPL Parameters

   An MPL forwarder logs an inconsistent event by
   resetting maintains two sets of Trickle parameters for the
   proactive and reactive methods.  The Trickle parameters are listed
   below:

   PROACTIVE_IMIN  The minimum Trickle timer T[M], interval, as described defined in [RFC6206].  All new
   messages
      [RFC6206] for proactive propagation.

   PROACTIVE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206] for proactive propagation.

   PROACTIVE_K  The redundancy constant, as defined in [RFC6206] for
      proactive propagation.

   PROACTIVE_TIMER_EXPIRATIONS  The number of Trickle timer expirations
      that occur before terminating the receiver can offer Trickle algorithm.  MUST be scheduled set
      to a value greater than 0.

   REACTIVE_IMIN  The minimum Trickle timer interval, as defined in
      [RFC6206] for
   transmission at the next transmission event.  Note reactive propagation.

   REACTIVE_IMAX  The maximum Trickle timer interval, as defined in
      [RFC6206] for reactive propagation.

   REACTIVE_K  The redundancy constant, as defined in [RFC6206] for
      reactive propagation.

   REACTIVE_TIMER_EXPIRATIONS  The number of Trickle timer expirations
      that these
   transmissions may be suppressed if occur before terminating the transmission event is
   suppressed. Trickle algorithm.  MAY be set
      to 0, which disables reactive propagation.

   WINDOW_HOLD_TIME  The minimum lifetime for sliding window state.

7.  Acknowledgements

   TODO.

   The authors would like to acknowledge the helpful comments of Robert
   Cragie, Esko Dijk, Ralph Droms, Paul Duffy, Owen Kirby, Joseph Reddy,
   Dario Tedeschi, and Peter van der Stok, which greatly improved the
   document.

8.  IANA Considerations

   The Trickle Multicast option requires an IPv6 Option Number.

   HEX         act  chg  rest
   ---         ---  ---  -----
     C          00          01    0  01100  TBD

   The first two bits indicate that the IPv6 node may skip over this
   option and continue processing MUST discard the header
   packet if it doesn't recognize the option type, and the third bit
   indicates that the Option Data MUST NOT change en-route.

9.  Security Considerations

   TODO.

10.  References

10.1.  Normative References

   [RFC1982]  Elz, R. and R. Bush, "Serial Number Arithmetic", RFC 1982,
              August 1996.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2328]  Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, December 1998.

   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
              IPv6 Specification", RFC 2473, December 1998.

   [RFC4443]  Conta, A., Deering, S., and M. Gupta, "Internet Control
              Message Protocol (ICMPv6) for the Internet Protocol
              Version 6 (IPv6) Specification", RFC 4443, March 2006.

   [RFC6206]  Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", RFC 6206, March 2011.

   [RFC6550]  Winter, T., Thubert, P., 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, March 2012.

10.2.  Informative References

   [I-D.ietf-roll-terminology]
              Vasseur, J., "Terminology in Low power And Lossy
              Networks", draft-ietf-roll-terminology-06 (work in
              progress), September 2011.

Authors' Addresses

   Jonathan W. Hui
   Cisco
   170 West Tasman Drive
   San Jose, California  95134
   USA

   Phone: +408 424 1547
   Email: jonhui@cisco.com

   Richard Kelsey
   Silicon Labs
   25 Thomson Place
   Boston, Massachusetts  02210
   USA

   Phone: +617 951 1225
   Email: richard.kelsey@silabs.com