draft-ietf-6man-rpl-option-06.txt   rfc6553.txt 
6MAN J. Hui Internet Engineering Task Force (IETF) J. Hui
Internet-Draft JP. Vasseur Request for Comments: 6553 JP. Vasseur
Intended status: Standards Track Cisco Systems, Inc Category: Standards Track Cisco Systems
Expires: June 16, 2012 December 14, 2011 ISSN: 2070-1721 March 2012
RPL Option for Carrying RPL Information in Data-Plane Datagrams The Routing Protocol for Low-Power and Lossy Networks (RPL) Option
draft-ietf-6man-rpl-option-06 for Carrying RPL Information in Data-Plane Datagrams
Abstract Abstract
The RPL protocol includes routing information in data-plane datagrams The Routing Protocol for Low-Power and Lossy Networks (RPL) includes
to quickly identify inconsistencies in the routing topology. This routing information in data-plane datagrams to quickly identify
document describes the RPL Option for use among RPL routers to inconsistencies in the routing topology. This document describes the
include such routing information. RPL Option for use among RPL routers to include such routing
information.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on June 16, 2012. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6553.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction ....................................................2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language ......................................3
2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Overview ........................................................3
3. Format of the RPL Option . . . . . . . . . . . . . . . . . . . 5 3. Format of the RPL Option ........................................3
4. RPL Router Behavior . . . . . . . . . . . . . . . . . . . . . 7 4. RPL Router Behavior .............................................5
5. Security Considerations . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations .........................................6
5.1. DAG Inconsistency Attacks . . . . . . . . . . . . . . . . 9 5.1. DAG Inconsistency Attacks ..................................6
5.2. DAO Inconsistency Attacks . . . . . . . . . . . . . . . . 9 5.2. Destination Advertisement Object (DAO)
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 Inconsistency Attacks ......................................7
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations .............................................7
8. Changes . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Acknowledgements ................................................8
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. References ......................................................8
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 8.1. Normative References .......................................8
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 8.2. Informative References .....................................8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
RPL is a distance vector IPv6 routing protocol designed for Low power RPL is a distance vector IPv6 routing protocol designed for Low-Power
and Lossy Networks (LLNs) [I-D.ietf-roll-rpl]. Such networks are and Lossy Networks (LLNs) [RFC6550]. Such networks are typically
typically constrained in energy and/or channel capacity. To conserve constrained in energy and/or channel capacity. To conserve precious
precious resources, a routing protocol must generate control traffic resources, a routing protocol must generate control traffic
sparingly. However, this is at odds with the need to quickly sparingly. However, this is at odds with the need to quickly
propagate any new routing information to resolve routing propagate any new routing information to resolve routing
inconsistencies quickly. inconsistencies quickly.
To help minimize resource consumption, RPL uses a slow proactive To help minimize resource consumption, RPL uses a slow proactive
process to construct and maintain a routing topology but a reactive process to construct and maintain a routing topology but a reactive
and dynamic process to resolving routing inconsistencies. In the and dynamic process to resolving routing inconsistencies. In the
steady state, RPL maintains the routing topology using a low-rate steady state, RPL maintains the routing topology using a low-rate
beaconing process. However, when RPL detects inconsistencies that beaconing process. However, when RPL detects inconsistencies that
may prevent proper datagram delivery, RPL temporarily increases the may prevent proper datagram delivery, RPL temporarily increases the
beacon rate to quickly resolve those inconsistencies. This dynamic beacon rate to quickly resolve those inconsistencies. This dynamic
rate control operation is governed by the use of dynamic timers also rate control operation is governed by the use of dynamic timers also
referred to as "Trickle" timers and defined in [RFC6206]. In referred to as "Trickle" timers and defined in [RFC6206]. In
contrast to other routing protocols (e.g OSPF [RFC2328]), RPL detects contrast to other routing protocols (e.g., OSPF [RFC2328]), RPL
routing inconsistencies using data-path verification, by including detects routing inconsistencies using data-path verification, by
routing information within the datagram itself. In doing so, repair including routing information within the datagram itself. In doing
mechanisms operate only as needed, allowing the control and data so, repair mechanisms operate only as needed, allowing the control
planes to operate on similar time scales. The main motivation for and data planes to operate on similar time scales. The main
data path verification in LLNs is that control plane traffic should motivation for data-path verification in LLNs is that control-plane
be carefully bounded with respect to the data traffic. Intuitively, traffic should be carefully bounded with respect to the data traffic.
there is no need to solve routing issues (which may be temporary) in Intuitively, there is no need to solve routing issues (which may be
the absence of data traffic. temporary) in the absence of data traffic.
The RPL protocol constructs a Directed Acyclic Graph (DAG) that RPL constructs a Directed Acyclic Graph (DAG) that attempts to
attempts to minimize path costs to the DAG root according to a set of minimize path costs to the DAG root according to a set of metrics and
metric and objective functions. There are circumstances where loops Objective Functions. There are circumstances where loops may occur,
may occur, and RPL is designed to use a data-path loop detection and RPL is designed to use a data-path loop detection method. This
method. This is one of the known requirements of RPL and other data- is one of the known requirements of RPL, and other data-path usage
path usage might be defined in the future. might be defined in the future.
To that end, this document defines a new IPv6 option, called the RPL To that end, this document defines a new IPv6 option, called the RPL
Option, to be carried within the IPv6 Hop-by-Hop header. 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 Option is only for use between RPL routers participating in the same
RPL Instance. RPL Instance.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
skipping to change at page 4, line 15 skipping to change at page 3, line 33
2. Overview 2. Overview
The RPL Option provides a mechanism to include routing information The RPL Option provides a mechanism to include routing information
with each datagram that a router forwards. When receiving datagrams with each datagram that a router forwards. When receiving datagrams
that include routing information, RPL routers process the routing that include routing information, RPL routers process the routing
information to help maintain the routing topology. information to help maintain the routing topology.
Every RPL router along a packet's delivery path processes and updates Every RPL router along a packet's delivery path processes and updates
the RPL Option. If the received packet does not already contain a the RPL Option. If the received packet does not already contain a
RPL Option, the RPL router must insert a RPL Option before forwarding RPL Option, the RPL router must insert a RPL Option before forwarding
it to another RPL router. This draft also specifies the use of IPv6- it to another RPL router. This document also specifies the use of
in-IPv6 tunneling [RFC2473] when attaching a RPL option to a packet. IPv6-in-IPv6 tunneling [RFC2473] when attaching a RPL option to a
Use of tunneling ensures that the original packet remains unmodified packet. Use of tunneling ensures that the original packet remains
and that ICMP errors return to the RPL Option source rather than the unmodified and that ICMP errors return to the RPL Option source
source of the original packet. rather than the source of the original packet.
3. Format of the RPL Option 3. Format of the RPL Option
The RPL Option is carried in an IPv6 Hop-by-Hop Options header, The RPL Option is carried in an IPv6 Hop-by-Hop Options header,
immediately following the IPv6 header. This option has an alignment immediately following the IPv6 header. This option has an alignment
requirement of 2n. The option has the following format: requirement of 2n. The option has the following format:
0 1 2 3 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 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 | | Option Type | Opt Data Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank | |O|R|F|0|0|0|0|0| RPLInstanceID | SenderRank |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| (sub-TLVs) | | (sub-TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: RPL Option Figure 1: RPL Option
Option Type: TBD by IANA. Option Type: 0x63
Opt Data Len: 8-bit field indicating the length of the option, in Opt Data Len: 8-bit field indicating the length of the option, in
octets, excluding the Option Type and Opt Data Len fields. octets, excluding the Option Type and Opt Data Len fields.
Down 'O': 1-bit flag as defined in Section 11.2 of Down 'O': 1-bit flag as defined in Section 11.2 of [RFC6550]. The
[I-D.ietf-roll-rpl]. The processing SHALL follow the rules processing SHALL follow the rules described in Section 11.2 of
described in Section 11.2 of [I-D.ietf-roll-rpl]. [RFC6550].
Rank-Error 'R': 1-bit flag as defined in Section 11.2 of Rank-Error 'R': 1-bit flag as defined in Section 11.2 of [RFC6550].
[I-D.ietf-roll-rpl]. The processing SHALL follow the rules The processing SHALL follow the rules described in Section 11.2
described in Section 11.2 of [I-D.ietf-roll-rpl]. of [RFC6550].
Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of Forwarding-Error 'F': 1-bit flag as defined in Section 11.2 of
[I-D.ietf-roll-rpl]. The processing SHALL follow the rules [RFC6550]. The processing SHALL follow the rules described in
described in Section 11.2 of [I-D.ietf-roll-rpl]. Section 11.2 of [RFC6550].
RPLInstanceID: 8-bit field as defined in Section 11.2 of RPLInstanceID: 8-bit field as defined in Section 11.2 of [RFC6550].
[I-D.ietf-roll-rpl]. The processing SHALL follow the rules The processing SHALL follow the rules described in Section 11.2
described in Section 11.2 of [I-D.ietf-roll-rpl]. of [RFC6550].
SenderRank: 16-bit field as defined in Section 11.2 of SenderRank: 16-bit field as defined in Section 11.2 of [RFC6550].
[I-D.ietf-roll-rpl]. The processing SHALL follow the rules The processing SHALL follow the rules described in Section 11.2
described in Section 11.2 of [I-D.ietf-roll-rpl]. of [RFC6550].
The two high order bits of the Option Type MUST be set to '01' and The two high order bits of the Option Type MUST be set to '01' and
the third bit is equal to '1'. With these bits, according to the third bit is equal to '1'. With these bits, according to
[RFC2460], nodes that do not understand this option on a received [RFC2460], nodes that do not understand this option on a received
packet MUST discard the packet. Also, according to [RFC2460], the packet MUST discard the packet. Also, according to [RFC2460], the
values within the RPL Option are expected to change en-route. The values within the RPL Option are expected to change en route. The
RPL Option Data Length is variable. RPL Option Data Length is variable.
The action taken by using the RPL Option and the potential set of 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 sub-TLVs carried within the RPL Option MUST be specified by the RFC
of the protocol that use that option. No sub-TLVs are defined in of the protocol that uses that option. No sub-TLVs are defined in
this document. A RPL device MUST skip over any unrecognized sub-TLVs this document. A RPL device MUST skip over any unrecognized sub-TLVs
and attempt to process any additional sub-TLVs that may appear after. and attempt to process any additional sub-TLVs that may appear after.
4. RPL Router Behavior 4. RPL Router Behavior
Datagrams sent between RPL routers MUST include a RPL Option or RPL Datagrams sent between RPL routers MUST include a RPL Option or RPL
Source Route Header ([I-D.ietf-6man-rpl-routing-header]) and MAY Source Route Header ([RFC6554]) and MAY include both. A datagram
include both. A datagram including a SRH does not need to include a including a Source Routing Header (SRH) does not need to include a
RPL Option since both the source and intermediate routers ensure that RPL Option since both the source and intermediate routers ensure that
the SRH does not contain loops. the SRH does not contain loops.
When the router is the source of the original packet and the When the router is the source of the original packet and the
destination is known to be within the same RPL Instance, the router destination is known to be within the same RPL Instance, the router
SHOULD include the RPL Option directly within the original packet. SHOULD include the RPL Option directly within the original packet.
Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and Otherwise, routers MUST use IPv6-in-IPv6 tunneling [RFC2473] and
place the RPL Option in the tunnel header. Using IPv6-in-IPv6 place the RPL Option in the tunnel header. Using IPv6-in-IPv6
tunneling ensures that the delivered datagram remains unmodified and tunneling ensures that the delivered datagram remains unmodified and
that ICMPv6 errors generated by a RPL Option are sent back to the that ICMPv6 errors generated by a RPL Option are sent back to the
router that generated the RPL Option. router that generated the RPL Option.
A RPL router chooses the next RPL router that should process the A RPL router chooses the next RPL router that should process the
original packet as the tunnel exit-point. In some cases, the tunnel 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 exit-point will be the final RPL router along a path towards the
original packet's destination and the original packet will only original packet's destination, and the original packet will only
traverse a single tunnel. One example is when the final destination traverse a single tunnel. One example is when the final destination
or the destination's attachment router is known to be within the same or the destination's attachment router is known to be within the same
RPL Instance. RPL Instance.
In other cases, the tunnel exit-point will not be the final RPL In other cases, the tunnel exit-point will not be the final RPL
router along a path and the original packet may traverse multiple router along a path and the original packet may traverse multiple
tunnels to reach the destination. One example is when a RPL router 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 is simply forwarding a packet to one of its Destination-Oriented DAG
case, the RPL router sets the tunnel exit-point to a DODAG Parent. (DODAG) parents. In this case, the RPL router sets the tunnel exit-
When forwarding the original packet hop-by-hop, the RPL router only point to a DODAG parent. When forwarding the original packet hop-by-
makes a determination on the next hop towards the destination. 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 A RPL router receiving an IPv6-in-IPv6 packet destined to it
processes the tunnel packet as described in Section 3 of [RFC2473]. processes the tunnel packet as described in Section 3 of [RFC2473].
Before IPv6 decapsulation, the RPL router MUST process the RPL Option Before IPv6 decapsulation, the RPL router MUST process the RPL
if one exists. After IPv6 decapsulation, if the router determines Option, if one exists. After IPv6 decapsulation, if the router
that it should forward the original packet to another RPL router it determines that it should forward the original packet to another RPL
MUST encapsulate the packet again using IPv6-in-IPv6 tunneling to router, it MUST encapsulate the packet again using IPv6-in-IPv6
include the RPL Option. Fields within the RPL Option that do not tunneling to include the RPL Option. Fields within the RPL Option
change hop-by-hop MUST remain the same as those received from the that do not change hop-by-hop MUST remain the same as those received
prior tunnel. from the prior tunnel.
RPL routers are responsible for ensuring that a RPL Option is only RPL routers are responsible for ensuring that a RPL Option is only
used between RPL routers: used between RPL routers:
1. For datagrams destined to a RPL router, the router processes the 1. For datagrams destined to a RPL router, the router processes the
packet in the usual way. For instance, if the RPL Option was packet in the usual way. For instance, if the RPL Option was
included using tunneled mode and the RPL router serves as the included using tunneled mode and the RPL router serves as the
tunnel endpoint, the router removes the outer IPv6 header, at the tunnel endpoint, the router removes the outer IPv6 header, at the
same time removing the RPL Option as well. same time removing the RPL Option as well.
2. Datagrams destined elsewhere within the same RPL Instance are 2. Datagrams destined elsewhere within the same RPL Instance are
forwarded to the correct interface. forwarded to the correct interface.
3. Datagrams destined to nodes outside the RPL Instance are dropped 3. Datagrams destined to nodes outside the RPL Instance are dropped
if the outer-most IPv6 header contains a RPL Option not generated if the outermost IPv6 header contains a RPL Option not generated
by the RPL router forwarding the datagram. by the RPL router forwarding the datagram.
To avoid fragmentation, it is desirable to employ MTU sizes that To avoid fragmentation, it is desirable to employ MTU sizes that
allow for the header expansion (i.e. at least 1280 + 40 (outer IP 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 header) + RPL_OPTION_MAX_SIZE), where RPL_OPTION_MAX_SIZE is the
maximum RPL Option header size for a given RPL network. To take maximum RPL Option header size for a given RPL network. To take
advantage of this, however, the communicating endpoints need to be advantage of this, however, the communicating endpoints need to be
aware of the MTU along the path (i.e. through Path MTU Discovery). 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 Unfortunately, the larger MTU size may not be available on all links
(e.g. 1280 octets on 6LoWPAN links). However, it is expected that (e.g., 1280 octets on IPv6 Low-Power Wireless Personal Area Network
much of the traffic on these types of networks consists of much (6LoWPAN) links). However, it is expected that much of the traffic
smaller messages than the MTU, so performance degradation through on these types of networks consists of much smaller messages than the
fragmentation would be limited. MTU, so performance degradation through fragmentation would be
limited.
5. Security Considerations 5. Security Considerations
The RPL Option assists RPL routers in detecting routing The RPL Option assists RPL routers in detecting routing
inconsistencies. The RPL message security mechanisms defined in inconsistencies. The RPL message security mechanisms defined in
[I-D.ietf-roll-rpl] do not apply to the RPL Option. [RFC6550] do not apply to the RPL Option.
5.1. DAG Inconsistency Attacks 5.1. DAG Inconsistency Attacks
Using the Down 'O' flag and SenderRank field, an attacker can cause Using the Down 'O' flag and SenderRank field, an attacker can cause
RPL routers to believe that a DAG inconsistency exists within the RPL RPL routers to believe that a DAG inconsistency exists within the RPL
instance identified by the RPLInstanceID field. This attack would Instance identified by the RPLInstanceID field. This attack would
cause a RPL router to reset its DIO Trickle timer and begin cause a RPL router to reset its DODAG Information Object (DIO)
transmitting DIO messages more frequently. Trickle timer and begin transmitting DIO messages more frequently.
In order to avoid any unacceptable impact on network operations, an In order to avoid any unacceptable impact on network operations, an
implementation MAY limit the number of triggers caused by receiving a implementation MAY limit the rate of Trickle timer resets caused by
RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS per hour. A receiving a RPL Option to no greater than MAX_RPL_OPTION_RANK_ERRORS
RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20. per hour. A RECOMMENDED value for MAX_RPL_OPTION_RANK_ERRORS is 20.
5.2. DAO Inconsistency Attacks 5.2. Destination Advertisement Object (DAO) Inconsistency Attacks
In storing mode, RPL routers maintain downward routing state. Under In Storing mode, RPL routers maintain Downward routing state. Under
normal operation, the RPL Option assists RPL routers in cleaning up normal operation, the RPL Option assists RPL routers in cleaning up
stale downward routing state by using the Forwarding-Error 'F' flag stale Downward routing state by using the Forwarding-Error 'F' flag
to indicate that a datagram could not be delivered by a child and is to indicate that a datagram could not be delivered by a child and is
being sent back to try a different child. Using this flag, an being sent back to try a different child. Using this flag, an
attacker can cause a RPL router to discard downward routing state. attacker can cause a RPL router to discard Downward routing state.
In order to avoid any unacceptable impact on network operations, an In order to avoid any unacceptable impact on network operations, an
implementation MAY limit the number of triggers caused by receiving a implementation MAY limit the rate of discarding Downward routing
RPL Option to no greater than MAX_RPL_OPTION_FORWARD_ERRORS per hour. state caused by receiving a RPL Option to no greater than
A RECOMMENDED value for MAX_RPL_OPTION_FORWARD_ERRORS is 20. MAX_RPL_OPTION_FORWARD_ERRORS per hour. A RECOMMENDED value for
MAX_RPL_OPTION_FORWARD_ERRORS is 20.
In non-storing mode, only the LBR maintains downward routing state. In Non-Storing mode, only the Low-Power and Lossy Network Border
Because RPL routers do not maintain downward routing state, the RPL Router (LBR) maintains Downward routing state. Because RPL routers
Option cannot be used to mount such attacks. do not maintain Downward routing state, the RPL Option cannot be used
to mount such attacks.
6. IANA Considerations 6. IANA Considerations
IANA is requested to reserve a new value in the Destination Options IANA has assigned a new value in the Destination Options and Hop-by-
and Hop-by-Hop Options registry. The proposed value to be confirmed Hop Options registry. The value is as follows:
by IANA is:
Hex Value Binary Value Hex Value Binary Value
act chg rest Description Reference act chg rest Description Reference
--------- --- --- ------- ----------------- ---------- --------- --- --- ------- ----------------- ----------
TBD 01 1 TBD RPL Option [RFCthis] 0x63 01 1 00011 RPL Option [RFC6553]
As specified in [RFC2460], the first two bits indicate that the IPv6 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, 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. 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. The remaining bits serve as the option type.
IANA is requested to create a registry called RPL-option-TLV, for the IANA has created a registry called RPL-option-TLV, for the sub-TLVs
sub-TLVs carried in the RPL Option header. New codes may be carried in the RPL Option header. New codes may be allocated only by
allocated only by IETF Review [RFC5226]. The type field is an 8-bit IETF Review [RFC5226]. The type field is an 8-bit field whose value
field whose value be between 0 and 255, inclusive. be between 0 and 255, inclusive.
7. Acknowledgements 7. Acknowledgements
The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen The authors thank Jari Arkko, Ralph Droms, Adrian Farrel, Stephen
Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik Farrell, Richard Kelsey, Suresh Krishnan, Vishwas Manral, Erik
Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their Nordmark, Pascal Thubert, Sean Turner, and Tim Winter, for their
comments and suggestions that helped shape this document. comments and suggestions that helped shape this document.
8. Changes 8. References
(This section to be removed by the RFC editor.)
Draft 06:
- Address IESG comments.
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.
9. References
9.1. Normative References
[I-D.ietf-roll-rpl] 8.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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226, IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008. May 2008.
[RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko, [RFC6206] Levis, P., Clausen, T., Hui, J., Gnawali, O., and J. Ko,
"The Trickle Algorithm", RFC 6206, March 2011. "The Trickle Algorithm", RFC 6206, March 2011.
9.2. Informative References [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, March 2012.
[I-D.ietf-6man-rpl-routing-header] 8.2. Informative References
Hui, J., Vasseur, J., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with RPL", [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
draft-ietf-6man-rpl-routing-header-05 (work in progress), Routing Header for Source Routes with the Routing Protocol
November 2011. for Low-Power and Lossy Networks (RPL)", RFC 6554,
March 2012.
Authors' Addresses Authors' Addresses
Jonathan W. Hui Jonathan W. Hui
Cisco Systems, Inc Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, California 95134 San Jose, California 95134
USA USA
Phone: +408 424 1547 Phone: +408 424 1547
Email: jonhui@cisco.com EMail: jonhui@cisco.com
JP Vasseur JP. Vasseur
Cisco Systems, Inc Cisco Systems
11, Rue Camille Desmoulins 11, Rue Camille Desmoulins
Issy Les Moulineaux, 92782 Issy Les Moulineaux 92782
France France
Email: jpv@cisco.com EMail: jpv@cisco.com
 End of changes. 51 change blocks. 
179 lines changed or deleted 145 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/