draft-ietf-roll-useofrplinfo-16.txt   draft-ietf-roll-useofrplinfo-17.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 6553, 6550 (if approved) M. Richardson Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: January 4, 2018 P. Thubert Expires: April 30, 2018 P. Thubert
Cisco Cisco
July 3, 2017 October 27, 2017
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-16 draft-ietf-roll-useofrplinfo-17
Abstract Abstract
This document looks at different data flows through LLN (Low-Power This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
encapsulation is required. This analysis provides the basis on which encapsulation is required. This analysis provides the basis on which
to design efficient compression of these headers. Additionally, this to design efficient compression of these headers. Additionally, this
document updates the RFC 6553 adding a change to the RPL Option Type document updates the RFC 6553 adding a change to the RPL Option Type
and the RFC 6550 to indicate about this change. and the RFC 6550 to indicate about this change.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on January 4, 2018. This Internet-Draft will expire on April 30, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Language . . . . . . . . . . . . 4 2. Terminology and Requirements Language . . . . . . . . . . . . 4
2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5
3. Updates to RFC6553 and RFC 6550 . . . . . . . . . . . . . . . 5 3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5
3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5
3.2. Updates to RFC 6550 . . . . . . . . . . . . . . . . . . . 6 3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6
4. Sample/reference topology . . . . . . . . . . . . . . . . . . 7 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
Configuration Option Flag. . . . . . . . . . . . . . . . 6
4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13
6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 14 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 14
6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 15 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 15
6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 15 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 15
6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16
6.2. Storing Mode: Interaction between Leaf and Internet . . . 17 6.2. Storing Mode: Interaction between Leaf and Internet . . . 17
6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 17 6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 17
6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18
skipping to change at page 3, line 27 skipping to change at page 3, line 29
7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 38
7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 7.3.4. Non-SM: Example of Flow from not-RPL-aware-leaf to
not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39
8. Observations about the cases . . . . . . . . . . . . . . . . 40 8. Observations about the cases . . . . . . . . . . . . . . . . 40
8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41
9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 45
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 45 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 46 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction 1. Introduction
RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks)
[RFC6550] is a routing protocol for constrained networks. RFC 6553 [RFC6550] is a routing protocol for constrained networks. RFC 6553
[RFC6553] defines the "RPL option" (RPI), carried within the IPv6 [RFC6553] defines the "RPL option" (RPI), carried within the IPv6
skipping to change at page 4, line 9 skipping to change at page 4, line 12
traffic at all which is mostly hop-by-hop traffic (one exception traffic at all which is mostly hop-by-hop traffic (one exception
being DAO messages in non-storing mode). being DAO messages in non-storing mode).
It has become clear from attempts to do multi-vendor It has become clear from attempts to do multi-vendor
interoperability, and from a desire to compress as many of the above interoperability, and from a desire to compress as many of the above
artifacts as possible that not all implementors agree when artifacts artifacts as possible that not all implementors agree when artifacts
are necessary, or when they can be safely omitted, or removed. are necessary, or when they can be safely omitted, or removed.
An interim meeting went through the 24 cases defined here to discover An interim meeting went through the 24 cases defined here to discover
if there were any shortcuts, and this document is the result of that if there were any shortcuts, and this document is the result of that
discussion. This document clarify what is correct and incorrect discussion. This document clarifies what is the correct and the
behaviour. incorrect behaviour.
The related document A Routing Header Dispatch for 6LoWPAN (6LoRH) The related document A Routing Header Dispatch for 6LoWPAN (6LoRH)
[I-D.ietf-roll-routing-dispatch] defines a method to compress RPL [I-D.ietf-roll-routing-dispatch] defines a method to compress RPL
Option information and Routing Header type 3 [RFC6554], an efficient Option information and Routing Header type 3 [RFC6554], an efficient
IP-in-IP technique, and use cases proposed for the IP-in-IP technique, and use cases proposed for the
[Second6TischPlugtest] involving 6loRH. [Second6TischPlugtest] involving 6loRH.
2. Terminology and Requirements Language 2. Terminology and Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
skipping to change at page 4, line 32 skipping to change at page 4, line 35
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Terminology defined in [RFC7102] applies to this document: LBR, LLN, Terminology defined in [RFC7102] applies to this document: LBR, LLN,
RPL, RPL Domain and ROLL. RPL, RPL Domain and ROLL.
RPL-node: It is device which implements RPL, thus we can say that the RPL-node: It is device which implements RPL, thus we can say that the
device is RPL-capable or RPL-aware. Please note that the device can device is RPL-capable or RPL-aware. Please note that the device can
be found inside the LLN or outside LLN. In this document a RPL-node be found inside the LLN or outside LLN. In this document a RPL-node
which is a leaf of a DODAG is called RPL-aware-leaf. which is a leaf of a DODAG is called RPL-aware-leaf.
RPL-not-capable: It is device which do not implement RPL, thus we can RPL-not-capable: It is device which does not implement RPL, thus we
say that the device is not-RPL-aware. Please note that the device can say that the device is not-RPL-aware. Please note that the
can be found inside the LLN. In this document a not-RPL-aware node device can be found inside the LLN. In this document a not-RPL-aware
which is a leaf of a DODAG is called not-RPL-aware-leaf. node which is a leaf of a DODAG is called not-RPL-aware-leaf.
pledge: a new device which seeks admission to a network. (from pledge: a new device which seeks admission to a network. (from
[I-D.ietf-anima-bootstrapping-keyinfra]) [I-D.ietf-anima-bootstrapping-keyinfra])
Join Registrar and Coordinator (JRC): a device which brings new nodes Join Registrar and Coordinator (JRC): a device which brings new nodes
(pledges) into a network. (from (pledges) into a network. (from
[I-D.ietf-anima-bootstrapping-keyinfra]) [I-D.ietf-anima-bootstrapping-keyinfra])
Flag day: A "flag day" is a procedure in which the network, or a part Flag day: A "flag day" is a procedure in which the network, or a part
of it, is changed during a planned outage, or suddenly, causing an of it, is changed during a planned outage, or suddenly, causing an
skipping to change at page 5, line 14 skipping to change at page 5, line 14
2.1. hop-by-hop IPv6-in-IPv6 headers 2.1. hop-by-hop IPv6-in-IPv6 headers
The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
that originates from a node to an adjacent node, using the addresses that originates from a node to an adjacent node, using the addresses
(usually the GUA or ULA, but could use the link-local addresses) of (usually the GUA or ULA, but could use the link-local addresses) of
each node. If the packet must traverse multiple hops, then it must each node. If the packet must traverse multiple hops, then it must
be decapsulated at each hop, and then re-encapsulated again in a be decapsulated at each hop, and then re-encapsulated again in a
similar fashion. similar fashion.
3. Updates to RFC6553 and RFC 6550 3. Updates to RFC6553, RFC6550 and RFC 8138
3.1. Updates to RFC 6553 3.1. Updates to RFC 6553
[RFC6553] states as showed below, that in the Option Type field of [RFC6553] states as showed below, that in the Option Type field of
the RPL Option header, the two high order bits MUST be set to '01' the RPL Option header, the two high order bits MUST be set to '01'
and the third bit is equal to '1'. The first two bits indicate that and the third bit is equal to '1'. The first two bits indicate that
the IPv6 node MUST discard the packet if it doesn't recognize the 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 option type, and the third bit indicates that the Option Data may
change en route. The remaining bits serve as the option type. change en route. The remaining bits serve as the option type.
skipping to change at page 6, line 32 skipping to change at page 6, line 32
implementations SHOULD use the same value as it was received. When implementations SHOULD use the same value as it was received. When
originating new packets, implementations SHOULD have an option to originating new packets, implementations SHOULD have an option to
determine which value to originate with, this option is controlled by determine which value to originate with, this option is controlled by
the DIO option described below. the DIO option described below.
A network which is switching from straight 6lowpan compression A network which is switching from straight 6lowpan compression
mechanism to those described in [I-D.ietf-roll-routing-dispatch] will mechanism to those described in [I-D.ietf-roll-routing-dispatch] will
experience a flag day in the data compression anyway, and if possible experience a flag day in the data compression anyway, and if possible
this change can be deployed at the same time. this change can be deployed at the same time.
3.2. Updates to RFC 6550 3.2. Updates to RFC 8138
RPI-6LoRH header provides a compressed form for the RPL RPI
[RFC8138]. It should be considered when the Option Type in RPL
Option is decompressed, should take the value of 0x23 instead of
0x63.
3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
Configuration Option Flag.
In order to avoid a flag day caused by lack of interoperation between In order to avoid a flag day caused by lack of interoperation between
new RPI (0x23) and old RPI (0x63) nodes, the new nodes need to be new RPI (0x23) and old RPI (0x63) nodes, the new nodes need to be
told that there are old RPI nodes present. This can be done via a told that there are old RPI nodes present. This can be done via the
new DIO Option which will propogate through the network. Failure to DODAG Configuration Option flag which will propogate through the
receive this flag will cause dual mode nodes to originate traffic network. Failure to receive this information will cause dual mode
with the old-RPI (0x63) value. nodes to originate traffic with the old-RPI (0x63) value.
DIO Option: 0x05 RPI 0x23 enable MCRXXX As states in [RFC6550] the DODAG Configuration option is present in
DIO messages. the DODAG Configuration option distribute
configuration information which is generally static and unchanging
within the DODAG. This information is configured at the DODAG root
and distributed throughout the DODAG with the DODAG Configuration
option. Nodes other than the DODAG root must not modify this
information when propagating the DODAG Configuration option.
Flags: 8-bit unused field reserved for flags. The field MUST be The DODAG Configuration Option is as follow. We are interested in
initialized to zero by the sender and MUST be ignored by the the Flag field. The remaining fields states as defined in [RFC6550].
receiver.
We propose to use a bit flag as follows: Flags: The 4-bits remaining unused in the Flags field are reserved
for flags. The field MUST be initialized to zero by the sender and
MUST be ignored by the receiver.
+----+----+----+----+----+----+----+----+ 0 1 2 3
| | | | | | | | | +-----------------+---------------------------------------------------+
| | | | | | | | FR | | Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. |
| | | | | | | | | +---------------------------------------------------------------------+
+----+----+----+----+----+----+----+----+ | DIOIntMin. | DIORedund. | MaxRankIncrease |
+-----------------+---------------------------------------------------+
| MinHopRankIncrease | OCP |
+-----------------+---------------------------------------------------+
|Reserved | Def. Lifetime | Lifetime Unit |
+-----------------+-----------------+---------------------------------+
Figure 3: A DIO Flag to indicate the RPI-flag-day. Figure 3: DODAG Configuration Option.
FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option We propose to use the flag in the DODAG Configuration option as
field is set to "00", values of 0 indicates that RPL Option field is follows:
set to "01"
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag-
day.
In case of rebooting, the DIO is sent with flag indicating the new
RPI value.
4. Sample/reference topology 4. Sample/reference topology
A RPL network in general is composed of a 6LBR (6LoWPAN Border A RPL network in general is composed of a 6LBR (6LoWPAN Border
Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
(6LoWPAN Node) as leaf logically organized in a DODAG structure. (6LoWPAN Node) as leaf logically organized in a DODAG structure.
(Destination Oriented Directed Acyclic Graph). (Destination Oriented Directed Acyclic Graph).
RPL defines the RPL Control messages (control plane), a new ICMPv6 RPL defines the RPL Control messages (control plane), a new ICMPv6
[RFC4443] message with Type 155. DIS (DODAG Information [RFC4443] message with Type 155. DIS (DODAG Information
skipping to change at page 8, line 25 skipping to change at page 8, line 45
| IPv6 | | IPv6 |
| | | |
+--------------+ +--------------+
| 6LoWPAN | | 6LoWPAN |
| | | |
+--------------+ +--------------+
| PHY-MAC | | PHY-MAC |
| | | |
+--------------+ +--------------+
Figure 4: RPL Stack. Figure 5: RPL Stack.
+------------+ +------------+
| INTERNET ----------+ | INTERNET ----------+
| | | | | |
+------------+ | +------------+ |
| |
| |
| |
A | A |
+-------+ +-------+
skipping to change at page 9, line 46 skipping to change at page 9, line 46
| | +--+ | | | | +--+ | |
| | | | | | | | | |
| | | | | | | | | |
| | | I | J | | | | I | J |
F | | G | H | | F | | G | H | |
+-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+ +-----+-+ +-|-----+ +---|--+ +---|---+ +---|---+
| Raf | | ~Raf | | Raf | | Raf | | ~Raf | | Raf | | ~Raf | | Raf | | Raf | | ~Raf |
| 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN | | 6LN |
+-------+ +-------+ +------+ +-------+ +-------+ +-------+ +-------+ +------+ +-------+ +-------+
Figure 5: A reference RPL Topology. Figure 6: A reference RPL Topology.
Figure 2 shows the reference RPL Topology for this document. The Figure 2 shows the reference RPL Topology for this document. The
letters above the nodes are there so that they may be referenced in letters above the nodes are there so that they may be referenced in
subsequent sections. In the figure, a 6LR is a router. A 6LN can be subsequent sections. In the figure, a 6LR is a router. A 6LN can be
a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked a router or a host. The 6LN leaves (Raf - "RPL aware leaf"-) marked
as (F and I) are RPL hosts that does not have forwarding capability. as (F and I) are RPL hosts that does not have forwarding capability.
The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL The 6LN leaf (H) is a RPL router. The leafs marked as ~Raf "not-RPL
aware leaf" (G and J) are devices which do not speak RPL at all (not- aware leaf" (G and J) are devices which do not speak RPL at all (not-
RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and
efficient-ND only to participate in the network [RFC6775]. In the efficient-ND only to participate in the network [RFC6775]. In the
skipping to change at page 13, line 33 skipping to change at page 13, line 33
+---------------------+--------------+----------+--------------+ +---------------------+--------------+----------+--------------+
| | Raf to Raf | No | -- | | | Raf to Raf | No | -- |
+ +--------------+----------+--------------+ + +--------------+----------+--------------+
| | Raf to ~Raf | No | -- | | | Raf to ~Raf | No | -- |
+ Leaf - Leaf +--------------+----------+--------------+ + Leaf - Leaf +--------------+----------+--------------+
| | ~Raf to Raf | Yes | dst | | | ~Raf to Raf | Yes | dst |
+ +--------------+----------+--------------+ + +--------------+----------+--------------+
| | ~Raf to ~Raf | Yes | hop | | | ~Raf to ~Raf | Yes | hop |
+---------------------+--------------+----------+--------------+ +---------------------+--------------+----------+--------------+
Figure 6: IP-in-IP encapsulation in Storing mode. Figure 7: IP-in-IP encapsulation in Storing mode.
6.1. Storing Mode: Interaction between Leaf and Root 6.1. Storing Mode: Interaction between Leaf and Root
In this section we are going to describe the communication flow in In this section we are going to describe the communication flow in
storing mode (SM) between, storing mode (SM) between,
RPL-aware-leaf to root RPL-aware-leaf to root
root to RPL-aware-leaf root to RPL-aware-leaf
skipping to change at page 27, line 34 skipping to change at page 27, line 34
+-----------------+--------------+-----+-----+----------+----------+ +-----------------+--------------+-----+-----+----------+----------+
| | Raf to Raf | Yes | Yes | Yes | root/dst | | | Raf to Raf | Yes | Yes | Yes | root/dst |
+ +--------------+-----+-----+----------+----------+ + +--------------+-----+-----+----------+----------+
| | Raf to ~Raf | Yes | Yes | Yes | root/6LR | | | Raf to ~Raf | Yes | Yes | Yes | root/6LR |
+ Leaf - Leaf +--------------+-----+-----+----------+----------+ + Leaf - Leaf +--------------+-----+-----+----------+----------+
| | ~Raf to Raf | Yes | Yes | Yes | root/6LN | | | ~Raf to Raf | Yes | Yes | Yes | root/6LN |
+ +--------------+-----+-----+----------+----------+ + +--------------+-----+-----+----------+----------+
| | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR | | | ~Raf to ~Raf | Yes | Yes | Yes | root/6LR |
+-----------------+--------------+-----+-----+----------+----------+ +-----------------+--------------+-----+-----+----------+----------+
Figure 7: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP Figure 8: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
encapsulation. encapsulation.
7.1. Non-Storing Mode: Interaction between Leaf and Root 7.1. Non-Storing Mode: Interaction between Leaf and Root
In this section we are going to describe the communication flow in In this section we are going to describe the communication flow in
Non Storing Mode (Non-SM) between, Non Storing Mode (Non-SM) between,
RPL-aware-leaf to root RPL-aware-leaf to root
root to RPL-aware-leaf root to RPL-aware-leaf
skipping to change at page 41, line 37 skipping to change at page 41, line 37
In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
an IP-in-IP and RPI compression headers. The type of this case is an IP-in-IP and RPI compression headers. The type of this case is
critical since IP-in-IP is encapsulating a RPI header. critical since IP-in-IP is encapsulating a RPI header.
+--+-----+---+--------------+-----------+-------------+-------------+ +--+-----+---+--------------+-----------+-------------+-------------+
|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
+--+-----+---+--------------+-----------+-------------+-------------+ +--+-----+---+--------------+-----------+-------------+-------------+
Figure 8: Critical IP-in-IP (RPI). Figure 9: Critical IP-in-IP (RPI).
10. IANA Considerations 10. IANA Considerations
This document updates the registration made in [RFC6553] Destination This document updates the registration made in [RFC6553] Destination
Options and Hop-by-Hop Options registry from 0x63 to 0x23. Options and Hop-by-Hop Options registry from 0x63 to 0x23.
Hex Value Binary Value Hex Value Binary Value
act chg rest Description Reference act chg rest Description Reference
--------- --- --- ------- ----------------- ---------- --------- --- --- ------- ----------------- ----------
0x23 00 1 00011 RPL Option [RFCXXXX] 0x23 00 1 00011 RPL Option [RFCXXXX]
0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX] 0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX]
Figure 9: Option Type in RPL Option. Figure 10: Option Type in RPL Option.
Todo: Add the Updates to RFC 6550. We propose to use DODAG Configuration Option Flags in the DODAG
Configuration option as follows:
+------------+-----------------+---------------+
| Bit number | Description | Reference |
+------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+
Figure 11: DODAG Configuration Option Flag to indicate the RPI-flag-
day.
11. Security Considerations 11. Security Considerations
The security considerations covering of [RFC6553] and [RFC6554] apply The security considerations covering of [RFC6553] and [RFC6554] apply
when the packets get into RPL Domain. when the packets get into RPL Domain.
The IPIP mechanism described in this document is much more limited The IPIP mechanism described in this document is much more limited
than the general mechanism described in [RFC2473]. The willingness than the general mechanism described in [RFC2473]. The willingness
of each node in the LLN to decapsulate packets and forward them could of each node in the LLN to decapsulate packets and forward them could
be exploited by nodes to disguise the origin of an attack. be exploited by nodes to disguise the origin of an attack.
skipping to change at page 44, line 48 skipping to change at page 45, line 12
to the use of IPIP headers, and this document does not change that to the use of IPIP headers, and this document does not change that
analysis. analysis.
12. Acknowledgments 12. Acknowledgments
This work is partially funded by the FP7 Marie Curie Initial Training This work is partially funded by the FP7 Marie Curie Initial Training
Network (ITN) METRICS project (grant agreement No. 607728). Network (ITN) METRICS project (grant agreement No. 607728).
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments of (alphabetical order): Robert Cragie, Simon Duquennoy, comments of (alphabetical order): Robert Cragie, Simon Duquennoy,
Cenk Guendogan, C. M. Heard, Rahul Jadhav, Peter van der Stok, Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias
Xavier Vilajosana and Thomas Watteyne. Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne.
13. References 13. References
13.1. Normative References 13.1. Normative References
[I-D.ietf-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
Deering, S. and R. Hinden, "Internet Protocol, Version 6 Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work (IPv6) Specification", draft-ietf-6man-rfc2460bis-13 (work
in progress), May 2017. in progress), May 2017.
[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, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460,
December 1998, <http://www.rfc-editor.org/info/rfc2460>. December 1998, <https://www.rfc-editor.org/info/rfc2460>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <http://www.rfc-editor.org/info/rfc2473>. December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering:
Defeating Denial of Service Attacks which employ IP Source Defeating Denial of Service Attacks which employ IP Source
Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827,
May 2000, <http://www.rfc-editor.org/info/rfc2827>. May 2000, <https://www.rfc-editor.org/info/rfc2827>.
[RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec [RFC5406] Bellovin, S., "Guidelines for Specifying the Use of IPsec
Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406, Version 2", BCP 146, RFC 5406, DOI 10.17487/RFC5406,
February 2009, <http://www.rfc-editor.org/info/rfc5406>. February 2009, <https://www.rfc-editor.org/info/rfc5406>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<http://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<http://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>. <https://www.rfc-editor.org/info/rfc6554>.
[RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing [RFC7045] Carpenter, B. and S. Jiang, "Transmission and Processing
of IPv6 Extension Headers", RFC 7045, of IPv6 Extension Headers", RFC 7045,
DOI 10.17487/RFC7045, December 2013, DOI 10.17487/RFC7045, December 2013,
<http://www.rfc-editor.org/info/rfc7045>. <https://www.rfc-editor.org/info/rfc7045>.
[RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A., [RFC7416] Tsao, T., Alexander, R., Dohler, M., Daza, V., Lozano, A.,
and M. Richardson, Ed., "A Security Threat Analysis for and M. Richardson, Ed., "A Security Threat Analysis for
the Routing Protocol for Low-Power and Lossy Networks the Routing Protocol for Low-Power and Lossy Networks
(RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015, (RPLs)", RFC 7416, DOI 10.17487/RFC7416, January 2015,
<http://www.rfc-editor.org/info/rfc7416>. <https://www.rfc-editor.org/info/rfc7416>.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>.
13.2. Informative References 13.2. Informative References
[DDOS-KREBS] [DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016, >145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k- <http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>. cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-03 (work in progress), January 2017. backbone-router-04 (work in progress), July 2017.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-11 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-12 (work
in progress), January 2017. in progress), August 2017.
[I-D.ietf-6tisch-dtsecurity-secure-join] [I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf- Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress), 6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017. February 2017.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic Behringer, M., Eckert, T., and S. Bjarnason, "An Autonomic
Control Plane", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-06 (work in progress), March 2017. plane-12 (work in progress), October 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-06 (work in progress), May 2017. keyinfra-08 (work in progress), October 2017.
[I-D.ietf-roll-dao-projection] [I-D.ietf-roll-dao-projection]
Thubert, P. and J. Pylakutty, "Root initiated routing Thubert, P. and J. Pylakutty, "Root initiated routing
state in RPL", draft-ietf-roll-dao-projection-01 (work in state in RPL", draft-ietf-roll-dao-projection-02 (work in
progress), March 2017. progress), September 2017.
[I-D.ietf-roll-routing-dispatch] [I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie, Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing- "6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-05 (work in progress), October 2016. dispatch-05 (work in progress), October 2016.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<http://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", RFC 4443, Protocol Version 6 (IPv6) Specification", STD 89,
DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
<http://www.rfc-editor.org/info/rfc4443>. <https://www.rfc-editor.org/info/rfc4443>.
[RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C.
Bormann, "Neighbor Discovery Optimization for IPv6 over Bormann, "Neighbor Discovery Optimization for IPv6 over
Low-Power Wireless Personal Area Networks (6LoWPANs)", Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, DOI 10.17487/RFC6775, November 2012, RFC 6775, DOI 10.17487/RFC6775, November 2012,
<http://www.rfc-editor.org/info/rfc6775>. <https://www.rfc-editor.org/info/rfc6775>.
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<http://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <http://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[Second6TischPlugtest] [Second6TischPlugtest]
"2nd 6Tisch Plugtest", <http://www.ietf.org/mail- "2nd 6Tisch Plugtest", <http://www.ietf.org/mail-
archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>. archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>.
Authors' Addresses Authors' Addresses
Maria Ines Robles Maria Ines Robles
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
 End of changes. 49 change blocks. 
71 lines changed or deleted 119 lines changed or added

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