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

Versions: 00

6MAN                                                              J. Hui
Internet-Draft                                     Arch Rock Corporation
Intended status: Standards Track                              P. Thubert
Expires: January 29, 2011                                    JP. Vasseur
                                                      Cisco Systems, Inc
                                                           July 28, 2010


                   Using RPL Headers Without IP-in-IP
                     draft-hui-6man-rpl-headers-00

Abstract

   Routing for Low Power and Lossy Networks (RPL) is a routing protocol
   designed for Low power and Lossy Networks (LLNs).  RPL includes
   routing information in IPv6 data plane datagrams to help maintain the
   routing topology.  When forwarding a datagram into a RPL domain, a
   RPL router may need to expand the datagram to include routing
   information in IPv6 Extension headers.  A generic solution has been
   defined that uses IP-in-IP tunneling to include RPL routing
   information.  This document describes an alternative to inserting and
   removing RPL information in datagrams without the use of IP-in-IP
   tunneling.

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 29, 2011.

Copyright Notice

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



Hui, et al.             Expires January 29, 2011                [Page 1]


Internet-Draft                 RPL Headers                     July 2010


   (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  . . . . . . . . . . . . . . . . . .  4
   2.  Inserting Headers  . . . . . . . . . . . . . . . . . . . . . .  5
   3.  Removing Headers . . . . . . . . . . . . . . . . . . . . . . .  6
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     6.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     6.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10






























Hui, et al.             Expires January 29, 2011                [Page 2]


Internet-Draft                 RPL Headers                     July 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
   (LLNs) [I-D.ietf-roll-rpl].  Such networks are typically constrained
   in resources (limited communication data rate, processing power,
   energy capacity, memory).  When forwarding datagrams within a RPL
   domain, RPL requires those datagrams to carry routing information.
   RPL routing information may be included using a RPL Option within an
   IPv6 Hop-by-Hop Option header to perform routing loop detection and
   repair [I-D.ietf-6man-rpl-option].  RPL may also use a strict source
   route specified in an IPv6 Routing Header
   [I-D.ietf-6man-rpl-routing-header].  RPL uses source routing in LLNs
   composed of resource-constrained nodes that can maintain no more than
   a few routing entries.

   Because the RPL routing information is only useful within a RPL
   domain, RPL Border Routers (referred to as LBRs in
   [I-D.ietf-roll-terminology]) are responsible for inserting and
   removing RPL information when forwarding datagrams into or out of a
   RPL domain.  However, to nodes outside the RPL domain, there must not
   be any visible side effects of inserting RPL information.  Unwanted
   side effects include:

   1.  Mutations to the IPv6 packet headers being processed hop-by-hop
       are not undone before exiting the RPL domain.  Doing so affects
       how non-RPL routers process the datagram.

   2.  Mutations to the datagram are not undone before being sent back
       either partially or in whole to the source (e.g. in an ICMP
       error).  Doing so affects how the source handles the returned
       datagram, such as examining the payload of an ICMP error.

   3.  Changing any values included in computing a security signature,
       such as the IPv6 Payload Length and Next Header values for the
       Integrity Check Value of the IP Authentication Header [RFC4302].

   4.  Generating ICMP Packet Too Big errors that do not correctly
       reflect the path MTU in the RPL domain due to inclusion of the
       RPL information.

   5.  Not being capable of generating the correct path MTU because its
       value is less than 1280 octets due to the size of RPL routing
       information.

   The default mechanism for inserting and removing RPL information is
   by using IP-in-IP tunneling, encapsulating the existing packet with a
   new IPv6 header and including the RPL Option and/or routing header in



Hui, et al.             Expires January 29, 2011                [Page 3]


Internet-Draft                 RPL Headers                     July 2010


   the outer IPv6 header.  By tunneling the datagram, the original
   datagram is left unmodified.  Furthermore, any ICMP errors return to
   the RPL router that inserted RPL information into the datagram.  IP-
   in-IP tunneling avoids path MTU issues because the ICMP Packet Too
   Big error will return to the RPL router that inserted the headers,
   allowing it to perform IP fragmentation and requires no additional
   action by nodes outside the RPL domain.

   However, where LLNs are severely constrained in resources, IP-in-IP
   tunneling may not be the most favorable solution.  Use of IP-in-IP
   requires datagrams to carry two IPv6 headers, increasing header
   overhead and associated communication and memory requirements.
   Expanding existing header compression techniques to efficiently
   support IP-in-IP necessarily adds complexity.  LLN nodes must also
   implement packet processing code that supports IP-in-IP, further
   increasing code complexity.

   This document describes how to insert and remove RPL routing
   information without IP-in-IP tunneling such that no side effects are
   visible to nodes outside the RPL domain.  This mode of forwarding
   without IP-in-IP tunneling is defined as transport mode.  Note that
   transport mode is only provided as an option when IP-in-IP tunneling
   is not possible.

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 January 29, 2011                [Page 4]


Internet-Draft                 RPL Headers                     July 2010


2.  Inserting Headers

   This section specifies how a RPL router inserts RPL routing
   information into an existing IPv6 datagram.  We define rpl_info_size
   as the number of octets required to carry RPL information in a
   particular datagram and can vary between datagrams (e.g. due to
   different lengths in source route).

   1.  If the source node is within the RPL domain, it MUST compute any
       security integrity checks as if no RPL information was inserted
       into the datagram.  For example, the IPv6 Payload Length used for
       computing the integrity check should not include the octets
       required for carrying RPL information.

   2.  The RPL router SHOULD respect the IPv6 Extension header ordering
       recommended in [RFC2460].

   3.  If the datagram size after inserting RPL information exceeds the
       MTU of the directly attached link used to reach the next hop, the
       RPL router MUST send either an ICMP Packet Too Big error to the
       source.  The RPL router MUST subtract rpl_info_size from the MTU
       value of the error-causing link and report that as the MTU value.
       If the resulting MTU value is less than 1280 octets, the RPL
       router MUST suppress the ICMP Packet Too Big error and send an
       ICMP Destination Unreachable error back to the source instead.


























Hui, et al.             Expires January 29, 2011                [Page 5]


Internet-Draft                 RPL Headers                     July 2010


3.  Removing Headers

   All RPL routing information MUST be removed in the following cases:

   1.  When forwarding datagrams outside the RPL domain.

   2.  Before computing any integrity check values for verification.
       For example, the IPv6 Payload Length used for computing the
       integrity check should not include the octets required for
       carrying RPL information.

   The remainder of this section specifies how a RPL router removes RPL
   routing information in an existing IPv6 datagram.

   1.  Any RPL-specific IPv6 Extension headers MUST be removed from the
       datagram, if any exist.  The IPv6 Payload Length and
       corresponding Next Header fields MUST be updated to reflect their
       removal.

   2.  The RPL Option MUST be removed from the IPv6 Hop-by-Hop Options
       header of the datagram, if one exists.

   3.  If the RPL router is generating an ICMP error, the RPL router
       MUST remove any RPL information from the datagram in error before
       including it in the ICMP error's payload.

   4.  If the RPL router is generating an ICMP Packet Too Big error, the
       RPL router MUST subtract rpl_info_size from the MTU value of the
       error-causing link and report that as the MTU value in the
       message.  If the resulting MTU value is less than 1280 octets,
       the RPL router MUST suppress the ICMP Packet Too Big error and
       send an ICMP Destination Unreachable error back to the source
       instead.


















Hui, et al.             Expires January 29, 2011                [Page 6]


Internet-Draft                 RPL Headers                     July 2010


4.  Security Considerations

   The generation of ICMPv6 error messages may be used to attempt
   denial-of-service attacks by sending a large number of packets that
   exceed the MTU of the RPL domain.  It is RECOMMENDED that an
   implementation correctly follows Section 2.4 of [RFC4443] to rate
   limit the generation of ICMPv6 messages.












































Hui, et al.             Expires January 29, 2011                [Page 7]


Internet-Draft                 RPL Headers                     July 2010


5.  IANA Considerations

   This document does not require any action from IANA.
















































Hui, et al.             Expires January 29, 2011                [Page 8]


Internet-Draft                 RPL Headers                     July 2010


6.  References

6.1.  Normative References

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

6.2.  Informative References

   [I-D.ietf-6man-rpl-option]
              Hui, J. and J. Vasseur, "RPL Option for Carrying RPL
              Information in Data-Plane Datagrams",
              draft-ietf-6man-rpl-option-00 (work in progress),
              July 2010.

   [I-D.ietf-6man-rpl-routing-header]
              Hui, J., Vasseur, J., and D. Culler, "An IPv6 Routing
              Header for Source Routes with RPL",
              draft-ietf-6man-rpl-routing-header-00 (work in progress),
              July 2010.

   [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-10 (work in progress), June 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.

   [RFC4302]  Kent, S., "IP Authentication Header", RFC 4302,
              December 2005.











Hui, et al.             Expires January 29, 2011                [Page 9]


Internet-Draft                 RPL Headers                     July 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


   Pascal Thubert
   Cisco Systems, Inc
   Village d'Entreprises Green Side
   400, Avenue de Roumanille
   Batiment T3
   Biot - Sophia Antipolis  06410
   FRANCE

   Phone: +33 4 97 23 26 34
   Email: pthubert@cisco.com


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

   Email: jpv@cisco.com




















Hui, et al.             Expires January 29, 2011               [Page 10]


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