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