6MAN                                                              J. Hui
Internet-Draft                                               JP. Vasseur
Intended status: Standards Track                      Cisco Systems, Inc
Expires: May 18, 2012                                  November 15, 2011

    RPL Option for Carrying RPL Information in Data-Plane Datagrams


   The RPL protocol requires data-plane datagrams to carry RPL routing
   information that is processed by RPL routers when forwarding those
   datagrams.  This document describes the RPL Option for use among RPL

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 May 18, 2012.

Copyright Notice

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

Hui & Vasseur             Expires May 18, 2012                  [Page 1]

Internet-Draft                 RPL Option                  November 2011

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  3
   2.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Format of the RPL Option . . . . . . . . . . . . . . . . . . .  5
   4.  RPL Router Behavior  . . . . . . . . . . . . . . . . . . . . .  7
   5.  RPL Border Router Behavior . . . . . . . . . . . . . . . . . .  9
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
   9.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
     10.2. Informative References . . . . . . . . . . . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Hui & Vasseur             Expires May 18, 2012                  [Page 2]

Internet-Draft                 RPL Option                  November 2011

1.  Introduction

   RPL is a distance vector IPv6 routing protocol designed for Low power
   and Lossy Networks (LLNs) [I-D.ietf-roll-rpl].  Such networks are
   typically constrained in energy and/or channel capacity.  To conserve
   precious resources, a routing protocol must generate control traffic
   sparingly.  However, this is at odds with the need to quickly
   propagate any new routing information to resolve routing
   inconsistencies quickly.

   To help minimize resource consumption, RPL uses a slow proactive
   process to construct and maintain a routing topology but a reactive
   and dynamic process to resolving routing inconsistencies.  In the
   steady state, RPL maintains the routing topology using a low-rate
   beaconing process.  However, when RPL detects inconsistencies that
   may prevent proper datagram delivery, RPL temporarily increases the
   beacon rate to quickly resolve those inconsistencies.  This dynamic
   rate control operation is governed by the use of dynamic timers also
   referred to as "Trickle" timers and defined in [RFC6206].  In
   contrast to other routing protocols (e.g OSPF [RFC2328]), RPL detects
   routing inconsistencies using data-path verification, by including
   routing information within the datagram itself.  In doing so, repair
   mechanisms operate only as needed, allowing the control and data
   planes to operate on similar time scales.  The main motivation for
   data path verification in LLNs is that control plane traffic should
   be carefully bounded with respect to the data traffic.  Intuitively,
   there is no need to solve routing issues (which may be temporary) in
   the absence of data traffic.

   The RPL protocol constructs a Directed Acyclic Graph (DAG) that
   attempts to minimize path costs to the DAG root according to a set of
   metric and objective functions.  There are circumstances where loops
   may occur, and RPL is designed to use a data-path loop detection
   method.  This is one of the known requirements of RPL and other data-
   path usage might be defined in the future.

   To that end, this document proposes a new IPv6 option, called the RPL
   Option, to be carried within the IPv6 Hop-by-Hop header.  The RPL
   Option is only for use between RPL routers participating in the same
   RPL Instance.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC 2119 [RFC2119].

Hui & Vasseur             Expires May 18, 2012                  [Page 3]

Internet-Draft                 RPL Option                  November 2011

2.  Overview

   RPL requires a router to include routing information with each
   datagram it forwards to another RPL router.  When receiving datagrams
   that include routing information, RPL routers process the routing
   information to help maintain the routing topology.  The RPL Option
   provides a mechanism to include routing information with each
   datagram that a router forwards.

   Every RPL router along a packet's delivery path processes and updates
   the RPL Option.  If the received packet does not already contain a
   RPL Option, the RPL router must insert a RPL Option before forwarding
   it to another RPL router.  This draft specifies the use of IPv6-in-
   IPv6 tunneling [RFC2473] when attaching a RPL option to a packet.
   Use of tunneling ensures that the original packet remains unmodified
   and that ICMP errors return to the RPL Option source rather than the
   source of the original packet.

Hui & Vasseur             Expires May 18, 2012                  [Page 4]

Internet-Draft                 RPL Option                  November 2011

3.  Format of the RPL Option

   The RPL Option is carried in an IPv6 Hop-by-Hop Options header,
   immediately following the IPv6 header.  This option has an alignment
   requirement of 2n.  The option 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 |
     |O|R|F|0|0|0|0|0| RPLInstanceID |          SenderRank           |
     |                         (sub-TLVs)                            |

                           Figure 1: RPL Option

   Option Type:  TBD by IANA.

   Opt Data Len:  8-bit field indicating the length of the option, in
         octets, excluding the Option Type and Opt Data Len fields.

   Down 'O':  1-bit flag as defined in Section 11.2 of
         [I-D.ietf-roll-rpl].  The processing shall follow the rules
         described in Section 11.2 of [I-D.ietf-roll-rpl].

   Rank-Error 'R':  1-bit flag as defined in Section 11.2 of
         [I-D.ietf-roll-rpl].  The processing shall follow the rules
         described in Section 11.2 of [I-D.ietf-roll-rpl].

   Forwarding-Error 'F':  1-bit flag as defined in Section 11.2 of
         [I-D.ietf-roll-rpl].  The processing shall follow the rules
         described in Section 11.2 of [I-D.ietf-roll-rpl].

   RPLInstanceID:  8-bit field as defined in Section 11.2 of
         [I-D.ietf-roll-rpl].  The processing shall follow the rules
         described in Section 11.2 of [I-D.ietf-roll-rpl].

   SenderRank:  16-bit field as defined in Section 11.2 of
         [I-D.ietf-roll-rpl].  The processing shall follow the rules
         described in Section 11.2 of [I-D.ietf-roll-rpl].

   Values within the RPL Option are expected to change en-route.  Nodes
   that do not understand the RPL Option MUST discard the packet.  Thus,
   according to [RFC2460] the two high order bits of the Option Type
   must be equal set to '01' and the third bit is equal to '1'.  The RPL
   Option Data Length is variable.

Hui & Vasseur             Expires May 18, 2012                  [Page 5]

Internet-Draft                 RPL Option                  November 2011

   The action taken by using the RPL Option and the potential set of
   sub-TLVs carried within the RPL Option MUST be specified by the RFC
   of the protocol that use that option.  No TLVs are defined in this
   document.  A RPL device MUST skip over any unrecognized sub-TLVs and
   attempt to process any additional sub-TLVs that may appear after.

Hui & Vasseur             Expires May 18, 2012                  [Page 6]

Internet-Draft                 RPL Option                  November 2011

4.  RPL Router Behavior

   Datagrams sent between RPL routers MUST include a RPL Option or RPL
   Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY
   include both.  When the router is the source of the original packet
   and the destination is known to be within the same RPL Instance, the
   router SHOULD include the RPL Option directly within the original
   packet.  Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473]
   and place the RPL Option in the tunnel header.  Using IPv6-in-IPv6
   tunneling ensures that the delivered datagram remains unmodified and
   that ICMPv6 errors generated by inserting the RPL Option are sent
   back to the router that generated the routing header.

   A RPL router chooses the next RPL router that should process the
   original packet as the tunnel exit-point.  In some cases, the tunnel
   exit-point will be the final RPL router along a path towards the
   original packet's destination and the original packet will only
   traverse a single tunnel.  One example is when the final destination
   or the destination's attachment router is known to be within the same
   RPL Instance.

   In other cases, the tunnel exit-point will not be the final RPL
   router along a path and the original packet may traverse multiple
   tunnels to reach the destination.  One example is when a RPL router
   is simply forwarding a packet to one of its DODAG Parents.  In this
   case, the RPL router sets the tunnel exit-point to a DODAG Parent.
   When forwarding the original packet hop-by-hop, the RPL router only
   makes a determination on the next hop towards the destination.

   A RPL router receiving an IPv6-in-IPv6 packet destined to it
   processes the tunnel packet as described in Section 3 of [RFC2473].
   Before IPv6 decapsulation, the RPL router MUST process the RPL Option
   if one exists.  After IPv6 decapsulation, if the router determines
   that it should forward the original packet to another RPL router it
   MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to
   include the RPL Option.  Fields within the RPL Option that do not
   change hop-by-hop MUST remain the same as those received from the
   prior tunnel.

   To avoid fragmentation, it is desirable to employ MTU sizes that
   allow for the header expansion (i.e. at least 1280 + 40 (outer IP
   header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the
   maximum RPL Option header size for a given RPL network.  To take
   advantage of this, however, the communicating endpoints need to be
   aware of the MTU along the path (i.e. through Path MTU Discovery).
   Unfortunately, the larger MTU size may not be available on all links
   (e.g. 1280 octets on 6LoWPAN links).  However, it is expected that
   much of the traffic on these types of networks consists of much

Hui & Vasseur             Expires May 18, 2012                  [Page 7]

Internet-Draft                 RPL Option                  November 2011

   smaller messages than the MTU, so performance degradation through
   fragmentation would be limited.

Hui & Vasseur             Expires May 18, 2012                  [Page 8]

Internet-Draft                 RPL Option                  November 2011

5.  RPL Border Router Behavior

   RPL Border Routers (referred to as LBRs in
   [I-D.ietf-roll-terminology]) are responsible for ensuring that a RPL
   Option is only used between RPL routers.

   For datagrams destined to the RPL Border Router, the router processes
   the packet in the usual way.  For instance, if the RPL Option was
   included using tunneled mode and the RPL Border Router serves as the
   tunnel endpoint, the router removes the outer IPv6 header, at the
   same time removing the RPL Option as well.

   Datagrams destined elsewhere within the same RPL Instance are
   forwarded to the correct interface.

   Datagrams destined to nodes outside the RPL Instance are dropped if
   the outer-most IPv6 header contains a RPL Option.

Hui & Vasseur             Expires May 18, 2012                  [Page 9]

Internet-Draft                 RPL Option                  November 2011

6.  Security Considerations

   This option may be used to mount several potential attacks since
   routers may be flooded by bogus datagrams containing the RPL Option.
   In particular, an inconsistent Rank value can cause a RPL router to
   reset its DIO Trickle timer.

   In order to avoid any unacceptable impact on network operations, an
   implementation MAY limit the number of triggers caused by receiving a
   RPL Option to no greater than MAX_RPL_OPTION_TRIGGERS per hour.  A

Hui & Vasseur             Expires May 18, 2012                 [Page 10]

Internet-Draft                 RPL Option                  November 2011

7.  IANA Considerations

   IANA is requested to reserve a new value in the Destination Options
   and Hop-by-Hop Options registry.  The proposed value to be confirmed
   by IANA is:

   Hex Value     Binary Value
                 act  chg  rest     Description        Reference
   ---------     ---  ---  -------  -----------------  ----------
     TBD          01    1  TBD      RPL Option         [RFCthis]

   As specified in [RFC2460], the first two bits indicate that the IPv6
   node MUST discard the packet if it doesn't recognize the option type,
   and the third bit indicates that the Option Data may change en-route.
   The remaining bits serve as the option type and are TBD by IANA.

   IANA is requested to create a registry called RPL-option-TLV, for the
   TLVs carried in the RPL Option header.  New codes may be allocated
   only by IETF Review [RFC5226].  The type field is an 8-bit field
   whose value be between 0 and 255, inclusive.

Hui & Vasseur             Expires May 18, 2012                 [Page 11]

Internet-Draft                 RPL Option                  November 2011

8.  Acknowledgements

   The authors thank Jari Arkko, Richard Kelsey, Suresh Krishnan,
   Vishwas Manral, Erik Nordmark, Pascal Thubert, and Tim Winter, for
   their comments and suggestions that helped shape this document.

Hui & Vasseur             Expires May 18, 2012                 [Page 12]

Internet-Draft                 RPL Option                  November 2011

9.  Changes

   (This section to be removed by the RFC editor.)

   Draft 05:

      - Address LC comments.

   Draft 04:

      - Clarify when the RPL Option is used.

      - Updated text on recommendations for avoiding fragmentation.

      - Specify skip-over-and-continue policy for unrecognized sub-TLVs.

      - Change use of IPv6-in-IPv6 tunneling from SHOULD to MUST.

      - Specify RPL Border Router operations in terms of forwarding
      decision outcomes.

      - Expand security section.

   Draft 03:

      - Removed any presumed values that are TBD by IANA.

Hui & Vasseur             Expires May 18, 2012                 [Page 13]

Internet-Draft                 RPL Option                  November 2011

10.  References

10.1.  Normative References

              Winter, T., Thubert, P., Brandt, A., Clausen, T., Hui, J.,
              Kelsey, R., Levis, P., Pister, K., Struik, R., and J.
              Vasseur, "RPL: IPv6 Routing Protocol for Low power and
              Lossy Networks", draft-ietf-roll-rpl-19 (work in
              progress), March 2011.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

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

10.2.  Informative References

              Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
              Routing Header for Source Routes with RPL",
              draft-ietf-6man-rpl-routing-header-04 (work in progress),
              October 2011.

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

Hui & Vasseur             Expires May 18, 2012                 [Page 14]

Internet-Draft                 RPL Option                  November 2011

Authors' Addresses

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

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

   JP Vasseur
   Cisco Systems, Inc
   11, Rue Camille Desmoulins
   Issy Les Moulineaux,   92782

   Email: jpv@cisco.com

Hui & Vasseur             Expires May 18, 2012                 [Page 15]