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

Versions: 00 01 02 draft-ietf-6man-rpl-routing-header

6MAN                                                              J. Hui
Internet-Draft                                     Arch Rock Corporation
Intended status: Standards Track                             JP. Vasseur
Expires: November 27, 2010                            Cisco Systems, Inc
                                                               D. Culler
                                                             UC Berkeley
                                                            May 26, 2010


                    A Source Routing Header for RPL
                  draft-hui-6man-rpl-routing-header-00

Abstract

   In Low power and Lossy Networks (LLNs), memory constraints on routers
   may limit them to maintaining at most a few routes.  In some
   configurations, it is necessary to use these memory constrained
   routers to deliver datagrams to nodes within the LLN.  The Routing
   for Low Power and Lossy Networks (RPL) protocol can be used in some
   deployments to store most, if not all, routes on one (e.g. the
   Directed Acyclic Graph (DAG) root) or few routers and forward the
   IPv6 datagram using a source routing technique to avoid large routing
   tables on memory constrained routers.  This document specifies a new
   IPv6 Routing header type for delivering datagrams 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 November 27, 2010.

Copyright Notice

   Copyright (c) 2010 IETF Trust and the persons identified as the
   document authors.  All rights reserved.




Hui, et al.             Expires November 27, 2010               [Page 1]


Internet-Draft             RPL Routing Header                   May 2010


   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  . . . . . . . . . . . . . . . . . .  3
   2.  Format of the RPL Routing Header . . . . . . . . . . . . . . .  4
   3.  RPL Router Behavior  . . . . . . . . . . . . . . . . . . . . .  6
   4.  RPL Border Router Behavior . . . . . . . . . . . . . . . . . .  8
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  9
     5.1.  Source Routing Attacks . . . . . . . . . . . . . . . . . .  9
     5.2.  ICMPv6 Attacks . . . . . . . . . . . . . . . . . . . . . .  9
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 10
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 12
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 12
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
























Hui, et al.             Expires November 27, 2010               [Page 2]


Internet-Draft             RPL Routing Header                   May 2010


1.  Introduction

   Routing for Low Power and Lossy Networks (RPL) is a distance vector
   IPv6 routing protocol designed for Low Power and Lossy networks (LLN)
   [I-D.ietf-roll-rpl].  Such networks are typically constrained in
   resources (limited communication data rate, processing power, energy
   capacity, memory).  In particular, some LLN configurations may
   utilize LLN routers where memory constraints limit nodes to
   maintaining only a small number of default routes and no other
   destinations.  However, it may be necessary to utilize such memory-
   constrained routers to forward datagrams and maintain reachability to
   destinations within the LLN.

   To utilize paths that include memory-constrained routers, RPL relies
   on source routing from more capable RPL routers.  RPL provides the
   necessary mechanisms to collect routing information at more capable
   RPL routers and form paths from those routers to arbitrary
   destinations within the RPL domain.  However, a a source routing
   mechanism supported by IPv6 is needed to deliver datagrams.

   This document specifies the Type 4 Routing header (RH4) (to be
   confirmed by IANA) for use strictly within a RPL domain.  The basic
   format of RH4 draws from that of the Type 0 Routing header (RH0)
   [RFC2460].  However, RH4 introduces mechanisms to compact the source
   route entries when all entries share the same prefix with the IPv6
   Destination Address of the encapsulating header, a typical scenario
   in LLNs using source routing.  The compaction mechanism reduces
   consumption of scarce resources such as bandwidth.

   RH4 also differs from RH0 in the processing rules to alleviate
   security concerns that lead to the deprecation of RH0 [RFC5095].
   Unlike RH0, routers processing RH4 must implement a strict source
   route policy where each and every IPv6 hop is specified within the
   datagram itself.  Furthermore, a RH4 header must only be used within
   a RPL domain.  RPL Border Routers, responsible for connecting RPL
   domains and IP domains that use other routing protocols, may insert a
   RH4 header into datagrams entering the RPL domain but must not allow
   datagrams already carrying a RH4 header to enter or exit the 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 [RFC2119].






Hui, et al.             Expires November 27, 2010               [Page 3]


Internet-Draft             RPL Routing Header                   May 2010


2.  Format of the RPL Routing Header

   The Type 4 Routing header 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
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |  Next Header  |  Hdr Ext Len  | Routing Type=4| Segments Left |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     | Compr |  Pad  |                   Reserved                    |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     |                                                               |
     .                                                               .
     .                        Addresses[1..n]                        .
     .                                                               .
     |                                                               |
     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Next Header         8-bit selector.  Identifies the type of header
                       immediately following the Routing header.  Uses
                       the same values as the IPv4 Protocol field
                       [RFC3232].

   Hdr Ext Len         8-bit unsigned integer.  Length of the Routing
                       header in 8-octet units, not including the first
                       8 octets.  Note that when Addresses[1..n] are
                       compressed (i.e. value of Compr is not 0), Hdr
                       Ext Len does not equal twice the number of
                       Addresses.

   Routing Type        8-bit selector.  Set to 4 (to be confirmed by
                       IANA).

   Segments Left       8-bit unsigned integer.  Number of route segments
                       remaining, i.e., number of explicitly listed
                       intermediate nodes still to be visited before
                       reaching the final destination.  Value MUST be
                       between 0 and Segments, inclusive.

   Compr               4-bit unsigned integer.  Number of prefix octets
                       from each segment that is elided.  For example, a
                       Type 4 Routing header carrying full IPv6
                       addresses sets Compr to 0.






Hui, et al.             Expires November 27, 2010               [Page 4]


Internet-Draft             RPL Routing Header                   May 2010


   Pad                 4-bit unsigned integer.  Number of octets that
                       are used to for padding after Address[n] and the
                       end of the Type 4 Routing header.

   Address[1..n]       Vector of addresses, numbered 1 to n.  Each
                       vector element has size (16 - Compr).

   The Type 4 Routing header shares the same basic format as the Type 0
   Routing header [RFC2460].  When carrying full IPv6 addresses, the
   Compr and Pad fields are set to 0 and the only difference between the
   Type 4 and Type 0 encodings is the value of the Routing Type field.

   A common network configuration for a RPL domain is that all nodes
   within a LLN share a common prefix.  Type 4 Routing header introduces
   the Compr and Pad fields to allow compaction of the Address[1..n]
   vector when all entries share the same prefix as the IPv6 Destination
   Address field of the encapsulating packet.  The Compr field indicates
   the number of prefix octets that are shared with the IPv6 Destination
   Address of the encapsulating header.  The shared prefix octets are
   not carried within the Routing header and each entry in Address[1..n]
   has size (16 - Compr) octets.  When Compr is non-zero, there may
   exists unused octets between the last entry, Address[n], and the end
   of the Routing header.  The Pad field indicates the number of unused
   octets that are used for padding.  Note that when Compr is 0, Pad
   MUST be null and carry a value of 0.

   IPv6 Addresses MUST NOT appear more than once in a Type 4 Routing
   header.  The IPv6 Destination Address of the encapsulating packet
   MUST NOT appear in a Type 4 Routing header.

   Multicast addresses MUST NOT appear in a Type 4 Routing header, or in
   the IPv6 Destination Address field of a packet carrying a Type 4
   Routing header.


















Hui, et al.             Expires November 27, 2010               [Page 5]


Internet-Draft             RPL Routing Header                   May 2010


3.  RPL Router Behavior

   A RPL Router MAY insert a Type 4 Routing header if one does not
   already exist.  The conditions for inserting a Type 4 Routing header
   are out of scope of this document.

   As specified in [RFC2460], a routing header is not examined or
   processed until it reaches the node identified in the Destination
   Address field of the IPv6 header.  In that node, dispatching on the
   Next Header field of the immediately preceding header causes the
   Routing header module to be invoked.

   The function of Type 4 Routing header is intended to be very similar
   to IPv4's Strict Source and Record Route option [RFC0791].  When
   processing the Type 4 Routing header, a router MUST drop the packet
   if the next entry is not a neighboring node and SHOULD send an ICMP
   Destination Unreachable (ICMPv6 Type 1) message with ICMPv6 Code set
   to 7 (to be confirmed by IANA) to the packet's Source Address.  An
   ICMPv6 Code of 7 indicates that the router does not have the next
   Address entry as a neighbor and cannot satisfy the strict source
   route.  When generating ICMPv6 error messages, the rules in Section
   2.4 of [RFC4443] must be observed.

   The following describes the algorithm performed when processing a
   Type 4 Routing header:


























Hui, et al.             Expires November 27, 2010               [Page 6]


Internet-Draft             RPL Routing Header                   May 2010


     if Segments Left = 0 {
        proceed to process the next header in the packet, whose type is
        identified by the Next Header field in the Routing header
     }
     else {
        compute n, the number of addresses in the Routing header, by
        n = ((Hdr Ext Len * 8) - Pad) / (16 - Comp)

        if Segments Left is greater than n {
           send an ICMP Parameter Problem, Code 0, message to the Source
           Address, pointing to the Segments Left field, and discard the
           packet
        }
        else {
           decrement Segments Left by 1;
           compute i, the index of the next address to be visited in
           the address vector, by subtracting Segments Left from n

           if Address[i] or the IPv6 Destination Address is multicast {
              discard the packet
           }
           else if Address[i] is not an neighboring node {
              send an ICMP Destination Unreachable, Code 3, message to
              the Source Address and discard the packet
           }
           else {
              swap the IPv6 Destination Address and Address[i]

              if the IPv6 Hop Limit is less than or equal to 1 {
                 send an ICMP Time Exceeded -- Hop Limit Exceeded in
                 Transit message to the Source Address and discard the
                 packet
              }
              else {
                 decrement the Hop Limit by 1

                 resubmit the packet to the IPv6 module for transmission
                 to the new destination
              }
           }
        }
     }









Hui, et al.             Expires November 27, 2010               [Page 7]


Internet-Draft             RPL Routing Header                   May 2010


4.  RPL Border Router Behavior

   RPL Border Routers (referred to as LBRs in
   [I-D.ietf-roll-terminology] are responsible for ensuring that a Type
   4 Routing header is only used within the RPL domain it was created.
   RPL Border Routers MUST drop datagrams entering or exiting the RPL
   domain that contain a Type 4 Routing header in the IPv6 Extension
   headers.











































Hui, et al.             Expires November 27, 2010               [Page 8]


Internet-Draft             RPL Routing Header                   May 2010


5.  Security Considerations

5.1.  Source Routing Attacks

   [RFC5095] deprecates the Type 0 Routing header due to a number of
   significant attacks that are referenced in that document.  Such
   attacks include network discovery, bypassing filtering devices,
   denial-of-service, and defeating anycast.

   Because this document specifies that Type 4 Routing headers are only
   for use within a RPL domain, such attacks cannot be mounted from
   outside the RPL domain.  As described in Section 4, RPL Border
   Routers MUST drop datagrams entering or exiting the RPL domain that
   contain a Type 4 Routing header in the IPv6 Extension headers.

5.2.  ICMPv6 Attacks

   The generation of ICMPv6 error messages may be used to attempt
   denial-of-service attacks by sending error-causing Type 4 Routing
   headers in back-to-back datagrams.  An implementation that correctly
   follows Section 2.4 of [RFC4443] would be protected by the ICMPv6
   rate limiting mechanism.





























Hui, et al.             Expires November 27, 2010               [Page 9]


Internet-Draft             RPL Routing Header                   May 2010


6.  IANA Considerations

   This document defines a new IPv6 Routing Type of 4 (to be confirmed).

   This document defines a new ICMPv6 Destination Unreachable Code of 7
   to indicate that the router does not have the next Address element as
   a neighbor and could not satisfy the strict source route.












































Hui, et al.             Expires November 27, 2010              [Page 10]


Internet-Draft             RPL Routing Header                   May 2010


7.  Acknowledgements

   TODO.
















































Hui, et al.             Expires November 27, 2010              [Page 11]


Internet-Draft             RPL Routing Header                   May 2010


8.  References

8.1.  Normative References

   [RFC0791]  Postel, J., "Internet Protocol", STD 5, RFC 791,
              September 1981.

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

   [RFC2460]  Deering, S. and R. Hinden, "Internet Protocol, Version 6
              (IPv6) Specification", RFC 2460, 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.

   [RFC5095]  Abley, J., Savola, P., and G. Neville-Neil, "Deprecation
              of Type 0 Routing Headers in IPv6", RFC 5095,
              December 2007.

8.2.  Informative References

   [I-D.ietf-roll-rpl]
              Winter, T., Thubert, P., and R. Team, "RPL: IPv6 Routing
              Protocol for Low power and Lossy Networks",
              draft-ietf-roll-rpl-07 (work in progress), March 2010.

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

   [RFC3232]  Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
              an On-line Database", RFC 3232, January 2002.
















Hui, et al.             Expires November 27, 2010              [Page 12]


Internet-Draft             RPL Routing Header                   May 2010


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


   David E. Culler
   UC Berkeley
   465 Soda Hall
   Berkeley, California  94720
   USA

   Phone: +510 643 7572
   Email: culler@cs.berkeley.edu






















Hui, et al.             Expires November 27, 2010              [Page 13]


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