< draft-ietf-roll-useofrplinfo-15.txt   draft-ietf-roll-useofrplinfo-16.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 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: December 31, 2017 P. Thubert Expires: January 4, 2018 P. Thubert
Cisco Cisco
June 29, 2017 July 3, 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-15 draft-ietf-roll-useofrplinfo-16
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. to design efficient compression of these headers. Additionally, this
document updates the RFC 6553 adding a change to the RPL Option Type
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 http://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 December 31, 2017. This Internet-Draft will expire on January 4, 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 (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 . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology and Requirements Language . . . . . . . . . . . . 4 2. Terminology and Requirements Language . . . . . . . . . . . . 4
2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5
3. Updates to RFC6553 and RFC 6550 . . . . . . . . . . . . . . . 5 3. Updates to RFC6553 and RFC 6550 . . . . . . . . . . . . . . . 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 6550 . . . . . . . . . . . . . . . . . . . 6
4. Sample/reference topology . . . . . . . . . . . . . . . . . . 6 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 7
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 11 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Storing Mode: Interaction between Leaf and Root . . . . . 12 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13
6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 13 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 . . . 14 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 . 14 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 . 15 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 16
6.2. Storing Mode: Interaction between Leaf and Internet . . . 16 6.2. Storing Mode: Interaction between Leaf and Internet . . . 17
6.2.1. SM: Example of Flow from RPL-aware-leaf to Internet . 16 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 . 17 6.2.2. SM: Example of Flow from Internet to RPL-aware-leaf . 18
6.2.3. SM: Example of Flow from not-RPL-aware-leaf to 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to
Internet . . . . . . . . . . . . . . . . . . . . . . 18 Internet . . . . . . . . . . . . . . . . . . . . . . 19
6.2.4. SM: Example of Flow from Internet to non-RPL-aware- 6.2.4. SM: Example of Flow from Internet to non-RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . 19
6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 20
6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . 20 leaf . . . . . . . . . . . . . . . . . . . . . . . . 20
6.3. Storing Mode: Interaction between Leaf and Leaf . . . . . 21
6.3.1. SM: Example of Flow from RPL-aware-leaf to RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . 21
6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL- 6.3.2. SM: Example of Flow from RPL-aware-leaf to non-RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 21
6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 22 aware-leaf . . . . . . . . . . . . . . . . . . . . . 22
6.3.3. SM: Example of Flow from not-RPL-aware-leaf to RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 23
6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not- 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 23 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 24
7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 25 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 26
7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 26 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 27
7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 27 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 28
7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 27 7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 28
7.1.3. Non-SM: Example of Flow from root to not-RPL-aware- 7.1.3. Non-SM: Example of Flow from root to not-RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . 28 leaf . . . . . . . . . . . . . . . . . . . . . . . . 29
7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to 7.1.4. Non-SM: Example of Flow from not-RPL-aware-leaf to
root . . . . . . . . . . . . . . . . . . . . . . . . 29 root . . . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Non-Storing Mode: Interaction between Leaf and Internet . 30 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 31
7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to 7.2.1. Non-SM: Example of Flow from RPL-aware-leaf to
Internet . . . . . . . . . . . . . . . . . . . . . . 30 Internet . . . . . . . . . . . . . . . . . . . . . . 31
7.2.2. Non-SM: Example of Flow from Internet to RPL-aware- 7.2.2. Non-SM: Example of Flow from Internet to RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . 31 leaf . . . . . . . . . . . . . . . . . . . . . . . . 32
7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to 7.2.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
Internet . . . . . . . . . . . . . . . . . . . . . . 32 Internet . . . . . . . . . . . . . . . . . . . . . . 33
7.2.4. Non-SM: Example of Flow from Internet to not-RPL- 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 33
7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 34
7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 34 aware-leaf . . . . . . . . . . . . . . . . . . . . . 34
7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 35
7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 35
7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not- 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 36
7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37
7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
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 . . . . . . . . . . . . . . . . . 38 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 39
8. Observations about the cases . . . . . . . . . . . . . . . . 39 8. Observations about the cases . . . . . . . . . . . . . . . . 40
8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 39 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 40
8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 40 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 41
9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 40 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 41
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41
11. Security Considerations . . . . . . . . . . . . . . . . . . . 40 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
13.1. Normative References . . . . . . . . . . . . . . . . . . 43 13.1. Normative References . . . . . . . . . . . . . . . . . . 45
13.2. Informative References . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . 46
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46 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
Hop-by-Hop header to quickly identify inconsistencies (loops) in the Hop-by-Hop header to quickly identify inconsistencies (loops) in the
routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route routing topology. RFC 6554 [RFC6554] defines the "RPL Source Route
Header" (RH3), an IPv6 Extension Header to deliver datagrams within a Header" (RH3), an IPv6 Extension Header to deliver datagrams within a
RPL routing domain, particularly in non-storing mode. RPL routing domain, particularly in non-storing mode.
skipping to change at page 5, line 11 skipping to change at page 5, line 18
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 and RFC 6550
3.1. Updates to RFC 6553 3.1. Updates to RFC 6553
[RFC6553] states that in the Option Type field of the RPL Option [RFC6553] states as showed below, that in the Option Type field of
header, the two high order bits MUST be set to '01' and the third bit the RPL Option header, the two high order bits MUST be set to '01'
is equal to '1'. The first two bits indicate that the IPv6 node MUST and the third bit is equal to '1'. The first two bits indicate that
discard the packet if it doesn't recognize the option type, and the the IPv6 node MUST discard the packet if it doesn't recognize the
third bit indicates that the Option Data may change en route. The option type, and the third bit indicates that the Option Data may
remaining bits serve as the option type. change en route. The remaining bits serve as the option type.
Hex Value Binary Value
act chg rest Description Reference
--------- --- --- ------- ----------------- ----------
0x63 01 1 00011 RPL Option [RFC6553]
Figure 1: Option Type in RPL Option.
Recent changes in [I-D.ietf-6man-rfc2460bis], state: "it is now Recent changes in [I-D.ietf-6man-rfc2460bis], state: "it is now
expected that nodes along a packet's delivery path only examine and expected that nodes along a packet's delivery path only examine and
process the Hop-by-Hop Options header if explicitly configured to do process the Hop-by-Hop Options header if explicitly configured to do
so". That means that nodes that do not understand a particular Hop- so". Processing of the Hop-by-Hop Options header (by IPv6
by-Hop Option in a received packet are unlikely to be configured to intermediate nodes) is now optional, but if they are configured to
process it. process the header, and if such nodes encounter an option with the
first two bits set to 01, they will drop the packet (if they conform
[I-D.ietf-6man-rfc2460bis]). The hosts should do the same,
irrespective of the configuration.
Thus, if an IPv6 node (RPL-not-capable) receives a packet with an RPL Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
Option, it should ignore the HBH option. To further solidify the receives a packet with an RPL Option, it should ignore the HBH RPL
desire for the RPL options to be ignored, this document updates the option (skip over this option and continue processing the header).
Option Type field to: the two high order bits MUST be set to '00' and
the third bit is equal to '1'.
These two high order bits indicate that the IPv6 node MUST skip over Thus, this document updates the Option Type field to: the two high
this option and continue processing the header if it doesn't order bits MUST be set to '00' and the third bit is equal to '1'.
recognize the option type. The first two bits indicate that the IPv6 node MUST skip over this
option and continue processing the header
(Section 4.2.[I-D.ietf-6man-rfc2460bis] ) if it doesn't recognize the
option type, and the third bit continues to be set to indicate that
the Option Data may change en route. The remaining bits serve as the
option type and remain as 0x3. This ensures that a packet that
leaves the RPL domain of an LLN (or that leaves the LLN entirely)
will not be discarded when it contains the [RFC6553] RPL Hop-by-Hop
option known as RPI. This is an update to [RFC6553].
The third bit continues to be set to indicate that the Option Data Hex Value Binary Value
may change en route. The remaining bits serve as the option type and act chg rest Description Reference
remain as 0x3. This an update to [RFC6553]. --------- --- --- ------- ----------------- ----------
0x23 00 1 00011 RPL Option [RFCXXXX]
Figure 2: Proposed change to the Option Type in RPL Option.
This change creates a flag day for existing networks which are This change creates a flag day for existing networks which are
currently using 0x63 as the RPI value. A move to 0x43 will not be currently using 0x63 as the RPI value. A move to 0x23 will not be
understood by those networks. It is suggested that implementations understood by those networks. It is suggested that implementations
accept both 0x63 and 0x43 when processing. When forwarding packets, accept both 0x63 and 0x23 when processing. When forwarding packets,
implementations SHOULD use the same value as we 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 DAO 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.
In general, any packet that leaves the RPL domain of an LLN (or
leaves the LLN entirely) will NOT be discarded, when it has the
[RFC6553] RPL Option Header known as the RPI or [RFC6554] SRH3
Extension Header (S)RH3. Because of [I-D.ietf-6man-rfc2460bis] the
RPI Hop-by-Hop option MAY be left in place even if the end host does
not understand it.
3.2. Updates to RFC 6550 3.2. Updates to RFC 6550
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 (0x43) 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 a
new DIO Option which will propogate through the network. Failure to new DIO Option which will propogate through the network. Failure to
receive this flag will cause dual mode nodes to originate traffic receive this flag will cause dual mode nodes to originate traffic
with the old-RPI (0x63) value. with the old-RPI (0x63) value.
DIO Option: 0x05 RPI 0x43 enable MCRXXX DIO Option: 0x05 RPI 0x23 enable MCRXXX
Flags: 8-bit unused field reserved for flags. The field MUST be Flags: 8-bit unused field reserved for flags. The field MUST be
initialized to zero by the sender and MUST be ignored by the initialized to zero by the sender and MUST be ignored by the
receiver. receiver.
We propose to use a bit flag as follows: We propose to use a bit flag as follows:
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
| | | | | | | | | | | | | | | | | |
| | | | | | | | FR | | | | | | | | | FR |
| | | | | | | | | | | | | | | | | |
+----+----+----+----+----+----+----+----+ +----+----+----+----+----+----+----+----+
Figure 1: A DIO Flag to indicate the RPI-flag-day. Figure 3: A DIO Flag to indicate the RPI-flag-day.
FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option FR(RPI-flag-day): the flag with values of 1 indicates that RPL Option
field is set to "00", values of 0 indicates that RPL Option field is field is set to "00", values of 0 indicates that RPL Option field is
set to "01" set to "01"
4. Sample/reference topology 4. Sample/reference topology
A RPL network is composed of a 6LBR (6LoWPAN Border Router), Backbone A RPL network in general is composed of a 6LBR (6LoWPAN Border
Router (6BBR), 6LR (6LoWPAN Router) and 6LN (6LoWPAN Node) as leaf Router), Backbone Router (6BBR), 6LR (6LoWPAN Router) and 6LN
logically organized in a DODAG structure. (Destination Oriented (6LoWPAN Node) as leaf logically organized in a DODAG structure.
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
Solicitation), DIO (DODAG Information Object) and DAO (Destination Solicitation), DIO (DODAG Information Object) and DAO (Destination
Advertisement Object) messages are all RPL Control messages but with Advertisement Object) messages are all RPL Control messages but with
different Code values. A RPL Stack is showed in Figure 1. different Code values. A RPL Stack is showed in Figure 1.
RPL supports two modes of Downward traffic: in storing mode (RPL-SM), RPL supports two modes of Downward traffic: in storing mode (RPL-SM),
it is fully stateful or an in non-storing (RPL-NSM), it is fully it is fully stateful or an in non-storing (RPL-NSM), it is fully
source routed. A RPL Instance is either fully storing or fully non- source routed. A RPL Instance is either fully storing or fully non-
skipping to change at page 7, line 38 skipping to change at page 8, line 25
| IPv6 | | IPv6 |
| | | |
+--------------+ +--------------+
| 6LoWPAN | | 6LoWPAN |
| | | |
+--------------+ +--------------+
| PHY-MAC | | PHY-MAC |
| | | |
+--------------+ +--------------+
Figure 2: RPL Stack. Figure 4: RPL Stack.
+------------+ +------------+
| INTERNET ----------+ | INTERNET ----------+
| | | | | |
+------------+ | +------------+ |
| |
| |
| |
A | A |
+-------+ +-------+
skipping to change at page 8, 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 3: A reference RPL Topology. Figure 5: 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
document these leafs (G and J) are often named IPv6 node. The 6LBR document these leafs (G and J) are often named IPv6 node. The 6LBR
in the figure is the root of the Global DODAG. in the figure is the root of the Global DODAG.
5. Use cases 5. Use cases
In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6 In the data plane a combination of RFC6553, RFC6554 and IPv6-in-IPv6
encapsulation is going to be analyzed for a number of representative encapsulation is going to be analyzed for a number of representative
traffic flows. traffic flows.
While this document assumes the HbH changes in This document assumes that the LLN is using the no-drop RPI option
[I-D.ietf-6man-rfc2460bis] proceed, and/or that the LLN is using the (0x23).
no-drop RPI option (0x43).
The uses cases describe the communication between RPL-aware-nodes, The uses cases describe the communication between RPL-aware-nodes,
with the root (6LBR), and with Internet. This document also describe with the root (6LBR), and with Internet. This document also describe
the communication between nodes acting as leaf that does not the communication between nodes acting as leaf that does not
understand RPL and they are part of hte LLN. We name these nodes as understand RPL and they are part of hte LLN. We name these nodes as
not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to not-RPL-aware-leaf.(e.g. section 5.4- Flow from not-RPL-aware-leaf to
root) We describe also how is the communication inside of the LLN root) We describe also how is the communication inside of the LLN
when it has the final destination addressed outside of the LLN e.g. when it has the final destination addressed outside of the LLN e.g.
with destination to Internet. (e.g. section 5.7- Flow from not-RPL- with destination to Internet. (e.g. section 5.7- Flow from not-RPL-
aware-leaf to Internet) aware-leaf to Internet)
skipping to change at page 10, line 22 skipping to change at page 11, line 22
not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing) not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing)
not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing) not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
This document assumes the rule that a Header cannot be inserted or This document assumes the rule that a Header cannot be inserted or
removed on the fly inside an IPv6 packet that is being routed. This removed on the fly inside an IPv6 packet that is being routed. This
is a fundamental precept of the IPv6 architecture as outlined in is a fundamental precept of the IPv6 architecture as outlined in
[RFC2460]. Extensions may not be added or removed except by the [RFC2460]. Extensions may not be added or removed except by the
sender or the receiver. sender or the receiver.
But, options in the Hop-by-Hop option which are marked with option But, options in the Hop-by-Hop Option Header whose option type has
type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD the first two bits set to '00' MUST ignored when received by a host
be ignored when received by a host or router which does not or router that does not understand that option ( Section 4.2
understand that option. [I-D.ietf-6man-rfc2460bis]).
This means that in general, any packet that leaves the RPL domain of
an LLN (or leaves the LLN entirely) will NOT be discarded, when it
has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]
SRH3 Extension Header (S)RH3.
The recent change to the second of these rules means that the RPI This means that when the no-drop RPI option code 0x23 is used, a
Hop-by-Hop option MAY be left in place even if the end host does not packet that leaves the RPL domain of an LLN (or that leaves the LLN
understand it. entirely) will not be discarded when it contains the [RFC6553] RPL
Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option MAY
be left in place even if the end host does not understand it.
NOTE: There is some possible security risk when the RPI information NOTE: There is some possible security risk when the RPI information
is released to the Internet. At this point this is a theoretical is released to the Internet. At this point this is a theoretical
situation. It is clear that the RPI option would waste some network situation. It is clear that the RPI option would waste some network
bandwidth when it escapes. bandwidth when it escapes.
An intermediate router that needs to add an extension header (SHR3 or An intermediate router that needs to add an extension header (SHR3 or
RPI Option) must encapsulate the packet in an (additional) outer IP RPI Option) must encapsulate the packet in an (additional) outer IP
header. The new header can be placed is placed after this new outer header. The new header can be placed is placed after this new outer
IP header. IP header.
skipping to change at page 11, line 31 skipping to change at page 12, line 28
In the tables present in this document, the term "RPL aware leaf" is In the tables present in this document, the term "RPL aware leaf" is
has been shortened to "Raf", and "not-RPL aware leaf" has been has been shortened to "Raf", and "not-RPL aware leaf" has been
shortened to "~Raf" to make the table fit in available space. shortened to "~Raf" to make the table fit in available space.
The earlier examples are more extensive to make sure that the process The earlier examples are more extensive to make sure that the process
is clear, while later examples are more concise. is clear, while later examples are more concise.
6. Storing mode 6. Storing mode
In storing mode (fully stateful), the sender cannot determine whether In storing mode (fully stateful), the sender can determine if the
the destination is RPL-capable and thus would need an IP-in-IP destination is inside the LLN by looking if the destination address
header. The IP-in-IP header needs to be addressed on a hop-by-hop is matched by the DIO's PIO option.
basis so that the last 6LR can remove the RPI header. Additionally,
The sender can determine if the destination is inside the LLN by
looking if the destination address is matched by the DIO's PIO
option.
The following table summarizes what headers are needed in the The following table summarizes what headers are needed in the
following scenarios, and indicates when the IP-in-IP header must be following scenarios, and indicates when the IP-in-IP header must be
inserted on a hop-by-hop basis, and when it can target the inserted on a hop-by-hop basis, and when it can target the
destination node directly. There are these possible situations: hop- destination node directly. There are these possible situations: hop-
by-hop necessary (indicated by "hop"), or destination address by-hop necessary (indicated by "hop"), or destination address
possible (indicated by "dst"). In all cases hop by hop can be used. possible (indicated by "dst"). In all cases hop by hop can be used.
In cases where no IP-in-IP header is needed, the column is left In cases where no IP-in-IP header is needed, the column is left
blank. blank.
skipping to change at page 12, line 36 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 4: IP-in-IP encapsulation in Storing mode. Figure 6: 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 26, 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 5: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP Figure 7: 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 39, line 41 skipping to change at page 40, line 41
8.1. Storing mode 8.1. Storing mode
[I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP [I-D.ietf-roll-routing-dispatch] shows that the hop-by-hop IP-in-IP
header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header header can be compressed using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header
as described in Section 7 of the document. as described in Section 7 of the document.
There are potential significant advantages to having a single code There are potential significant advantages to having a single code
path that always processes IP-in-IP headers with no options. path that always processes IP-in-IP headers with no options.
Thanks to the relaxation of the RFC2460 rule about discarding unknown Thanks to the change of the RPI option type from 0x63 to 0x23, there
Hop-by-Hop options, there is no longer any uncertainty about when to is no longer any uncertainty about when to use an IP-in-IP header in
use an IPIP header in the storing mode case. The RPI header SHOULD the storing mode. A Hop-by-Hop Options Header containing the RPI
always be added when 6LRs originate packets (without IPIP headers), option SHOULD always be added when 6LRs originate packets (without
and IPIP headers should always be added (addressed to the root when IP-in-IP headers), and IP-in-IP headers should always be added
on the way up, to the end-host when on the way down) when a 6LR finds (addressed to the root when on the way up, to the end-host when on
it needs to insert an RPI header. the way down) when a 6LR find that it needs to insert a Hop-by-Hop
Options Header containing the RPI option.
In order to support the above two cases with full generality, the In order to support the above two cases with full generality, the
different situations (always do IP-in-IP vs never use IP-in-IP) different situations (always do IP-in-IP vs never use IP-in-IP)
should be signaled in the RPL protocol itself. should be signaled in the RPL protocol itself.
8.2. Non-Storing mode 8.2. Non-Storing mode
In the non-storing case, dealing with non-RPL aware leaf nodes is In the non-storing case, dealing with non-RPL aware leaf nodes is
much easier as the 6LBR (DODAG root) has complete knowledge about the much easier as the 6LBR (DODAG root) has complete knowledge about the
connectivity of all DODAG nodes, and all traffic flows through the connectivity of all DODAG nodes, and all traffic flows through the
skipping to change at page 40, 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 6: Critical IP-in-IP (RPI). Figure 8: Critical IP-in-IP (RPI).
10. IANA Considerations 10. IANA Considerations
This document updates the registration made in [RFC6553] to the IPv6 This document updates the registration made in [RFC6553] Destination
Hop-by-Hop Registry from 0x43 to 0x63. Options and Hop-by-Hop Options registry from 0x63 to 0x23.
Hex Value Binary Value
act chg rest Description Reference
--------- --- --- ------- ----------------- ----------
0x23 00 1 00011 RPL Option [RFCXXXX]
0x63 01 1 00011 RPL Option(DEPRECATED) [RFC6553][RFCXXXX]
Figure 9: Option Type in RPL Option.
Todo: Add the Updates to RFC 6550.
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.
 End of changes. 47 change blocks. 
126 lines changed or deleted 142 lines changed or added

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