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

Versions: (draft-hui-6man-rpl-option) 00 01 02 03 04 05 06 RFC 6553

6MAN                                                              J. Hui
Internet-Draft                                     Arch Rock Corporation
Intended status: Standards Track                             JP. Vasseur
Expires: April 14, 2012                               Cisco Systems, Inc
                                                        October 12, 2011


    RPL Option for Carrying RPL Information in Data-Plane Datagrams
                     draft-ietf-6man-rpl-option-04

Abstract

   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 within a
   RPL domain.

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 April 14, 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 April 14, 2012                 [Page 1]

Internet-Draft                 RPL Option                   October 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 . . . . . . . . . . . . . . . . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   9.  Changes  . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 13
     10.2. Informative References . . . . . . . . . . . . . . . . . . 13
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14



































Hui & Vasseur            Expires April 14, 2012                 [Page 2]

Internet-Draft                 RPL Option                   October 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
   [I-D.ietf-roll-trickle].  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 within a RPL domain.

1.1.  Requirements Language

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






Hui & Vasseur            Expires April 14, 2012                 [Page 3]

Internet-Draft                 RPL Option                   October 2011


2.  Overview

   Datagrams sent between nodes within a RPL domain MUST include a RPL
   Option or RPL Source Route Header (SRH) and MAY include both.  When a
   RPL Border Router inserts a RPL Option, it MUST do so by using IPv6-
   in-IPv6 tunneling, as specified in [RFC2473].  Use of tunneling
   ensures that the datagram is delivered unmodified and that ICMP
   errors return to the RPL Option source rather than the source of the
   original datagram.










































Hui & Vasseur            Expires April 14, 2012                 [Page 4]

Internet-Draft                 RPL Option                   October 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 April 14, 2012                 [Page 5]

Internet-Draft                 RPL Option                   October 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 April 14, 2012                 [Page 6]

Internet-Draft                 RPL Option                   October 2011


4.  RPL Router Behavior

   To deliver an IPv6 datagram to its destination, a router may need to
   insert a new RPL Option.  Routers MUST use IPv6-in-IPv6 tunneling, as
   specified in [RFC2473] to include a new RPL Option in datagrams that
   are sourced by other nodes.  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.

   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
   smaller messages than the MTU, so performance degradation through
   fragmentation would be limited.






























Hui & Vasseur            Expires April 14, 2012                 [Page 7]

Internet-Draft                 RPL Option                   October 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 within a RPL domain.

   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 domain are forwarded
   to the correct interface.

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


































Hui & Vasseur            Expires April 14, 2012                 [Page 8]

Internet-Draft                 RPL Option                   October 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
   RECOMMENDED value for MAX_RPL_OPTION_TRIGGERS is 20.








































Hui & Vasseur            Expires April 14, 2012                 [Page 9]

Internet-Draft                 RPL Option                   October 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 April 14, 2012                [Page 10]

Internet-Draft                 RPL Option                   October 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 April 14, 2012                [Page 11]

Internet-Draft                 RPL Option                   October 2011


9.  Changes

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

   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 April 14, 2012                [Page 12]

Internet-Draft                 RPL Option                   October 2011


10.  References

10.1.  Normative References

   [I-D.ietf-roll-rpl]
              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.

   [I-D.ietf-roll-trickle]
              Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
              "The Trickle Algorithm", draft-ietf-roll-trickle-08 (work
              in progress), January 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.

10.2.  Informative References

   [I-D.hui-6man-rpl-headers]
              Hui, J., Thubert, P., and J. Vasseur, "Using RPL Headers
              Without IP-in-IP", draft-hui-6man-rpl-headers-00 (work in
              progress), July 2010.

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









Hui & Vasseur            Expires April 14, 2012                [Page 13]

Internet-Draft                 RPL Option                   October 2011


Authors' Addresses

   Jonathan W. Hui
   Arch Rock Corporation
   501 2nd St. Ste. 410
   San Francisco, California  94107
   USA

   Phone: +415 692 0828
   Email: jhui@archrock.com


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

   Email: jpv@cisco.com
































Hui & Vasseur            Expires April 14, 2012                [Page 14]


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