< draft-ietf-roll-useofrplinfo-19.txt   draft-ietf-roll-useofrplinfo-20.txt >
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 6553, 6550, 8138 (if approved) M. Richardson Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: May 3, 2018 P. Thubert Expires: August 2, 2018 P. Thubert
Cisco Cisco
October 30, 2017 January 29, 2018
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-19 draft-ietf-roll-useofrplinfo-20
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
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 https://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 May 3, 2018. This Internet-Draft will expire on August 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2018 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
(https://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
skipping to change at page 2, line 20 skipping to change at page 2, line 20
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, RFC6550 and RFC 8138 . . . . . . . . . . 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 8138 . . . . . . . . . . . . . . . . . . . 6 3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6
3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
Configuration Option Flag. . . . . . . . . . . . . . . . 6 Configuration Option Flag. . . . . . . . . . . . . . . . 7
4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Storing Mode: Interaction between Leaf and Root . . . . . 13 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14
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 . . . 15
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 . . . 16
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 . 16
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 . 17
6.2. Storing Mode: Interaction between Leaf and Internet . . . 17 6.2. Storing Mode: Interaction between Leaf and Internet . . . 18
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 . 18
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 . . . . . . . . . . . . . . . . . . . . . . 24 7. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 25
7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 25 7.1. Non-Storing Mode: Interaction between Leaf and Root . . . 26
7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 26 7.1.1. Non-SM: Example of Flow from RPL-aware-leaf to root . 27
7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf . 26 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf . 27
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 . . . . . . . . . . . . . . . . . . . . . . . . 27 leaf . . . . . . . . . . . . . . . . . . . . . . . . 28
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 . . . . . . . . . . . . . . . . . . . . . . . . 28 root . . . . . . . . . . . . . . . . . . . . . . . . 29
7.2. Non-Storing Mode: Interaction between Leaf and Internet . 29 7.2. Non-Storing Mode: Interaction between Leaf and Internet . 30
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 . . . . . . . . . . . . . . . . . . . . . . 29 Internet . . . . . . . . . . . . . . . . . . . . . . 30
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 . . . . . . . . . . . . . . . . . . . . . . . . 30 leaf . . . . . . . . . . . . . . . . . . . . . . . . 31
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 . . . . . . . . . . . . . . . . . . . . . . 31 Internet . . . . . . . . . . . . . . . . . . . . . . 32
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 . . . . . . . . . . . . . . . . . . . . . 32
7.3. Non-Storing Mode: Interaction between Leafs . . . . . . . 33
7.3.1. Non-SM: Example of Flow from RPL-aware-leaf to RPL-
aware-leaf . . . . . . . . . . . . . . . . . . . . . 33 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
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 . . . . . . . . . . . . . . . . . . . 35
7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 36 RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 36
7.3.3. Non-SM: Example of Flow from not-RPL-aware-leaf to
RPL-aware-leaf . . . . . . . . . . . . . . . . . . . 37
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 . . . . . . . . . . . . . . . . . 37 not-RPL-aware-leaf . . . . . . . . . . . . . . . . . 38
8. Observations about the cases . . . . . . . . . . . . . . . . 37 8. Observations about the cases . . . . . . . . . . . . . . . . 38
8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 37 8.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 38
8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 38 8.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 39
9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 38 9. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 39
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 40
11. Security Considerations . . . . . . . . . . . . . . . . . . . 39 11. Security Considerations . . . . . . . . . . . . . . . . . . . 40
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 43
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . 43 13.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 46
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 6, line 22 skipping to change at page 6, line 22
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]
Figure 2: Revised Option Type in RPL Option. Figure 2: Revised 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 0x23 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 0x23 when processing. When forwarding packets, accept both 0x63 and 0x23 when processing.
implementations SHOULD use the same value as it was received. When
originating new packets, implementations SHOULD have an option to When forwarding packets, implementations SHOULD use the same value as
determine which value to originate with, this option is controlled by it was received (This is required because, RPI type code can not be
the DIO option described below. changed by [RFC8200]). It allows to the network to be incrementally
upgraded, and for the DODAG root to know which parts of the network
are upgraded.
When originating new packets, implementations SHOULD have an option
to determine which value to originate with, this option is controlled
by 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 [RFC8138] will experience a flag day mechanism to those described in [RFC8138] will experience a flag day
in the data compression anyway, and if possible this change can be in the data compression anyway, and if possible this change can be
deployed at the same time. deployed at the same time.
3.2. Updates to RFC 8138 3.2. Updates to RFC 8138
RPI-6LoRH header provides a compressed form for the RPL RPI RPI-6LoRH header provides a compressed form for the RPL RPI
[RFC8138]. It should be considered when the Option Type in RPL [RFC8138]. It should be considered when the Option Type in RPL
Option is decompressed, should take the value of 0x23 instead of Option is decompressed, should take the value of 0x23 instead of
0x63. 0x63.
3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
Configuration Option Flag. 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, when there is a mix of new new RPI (0x23) and old RPI (0x63) nodes, when there is a mix of new
nodes and old nodes, the new nodes may be put into a compatibilit nodes and old nodes, the new nodes may be put into a compatibility
mode until all of the old nodes are replaced or upgraded. mode until all of the old nodes are replaced or upgraded.
This can be done via a DODAG Configuration Option flag which will This can be done via a DODAG Configuration Option flag which will
propogate through the network. Failure to receive this information propogate through the network. Failure to receive this information
will cause new nodes to remain in compatibility mode, and originate will cause new nodes to remain in compatibility mode, and originate
traffic with the old-RPI (0x63) value. traffic with the old-RPI (0x63) value.
As stated in [RFC6550] the DODAG Configuration option is present in As stated in [RFC6550] the DODAG Configuration option is present in
DIO messages. The DODAG Configuration option distributes DIO messages. The DODAG Configuration option distributes
configuration information. It is generally static, and does not configuration information. It is generally static, and does not
change within the DODAG. This information is configured at the DODAG change within the DODAG. This information is configured at the DODAG
root and distributed throughout the DODAG with the DODAG root and distributed throughout the DODAG with the DODAG
Configuration option. Nodes other than the DODAG root do not modify Configuration option. Nodes other than the DODAG root do not modify
this information when propagating the DODAG Configuration option. this information when propagating the DODAG Configuration option.
The DODAG Configuration Option is as follows. The Flag field is the The DODAG Configuration Option has a Flags field which is modified by
interesting field. The remaining fields states as defined in this document. Currently, the DODAG Configuration Option in
[RFC6550]. [RFC6550] is as follows. .
Flags: The 4-bits remaining unused in the Flags field are reserved 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 for flags. The field MUST be initialized to zero by the sender and
MUST be ignored by the receiver. MUST be ignored by the receiver.
0 1 2 3 0 1 2 3
+-----------------+---------------------------------------------------+ +-----------------+---------------------------------------------------+
| Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. | | Type = 0x04 | Opt Length = 14| Flags | A | PCS| DIOIntDoubl. |
+---------------------------------------------------------------------+ +---------------------------------------------------------------------+
| DIOIntMin. | DIORedund. | MaxRankIncrease | | DIOIntMin. | DIORedund. | MaxRankIncrease |
skipping to change at page 8, line 5 skipping to change at page 8, line 14
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document | | 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag- Figure 4: DODAG Configuration Option Flag to indicate the RPI-flag-
day. day.
In case of rebooting, the DIO is sent with flag indicating the new In case of rebooting, the node does not remember the flag. Thus, the
RPI value. 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
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 5.
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; in non-storing (RPL-NSM), it is fully source it is fully stateful; in non-storing (RPL-NSM), it is fully source
routed. A RPL Instance is either fully storing or fully non-storing, routed. A RPL Instance is either fully storing or fully non-storing,
i.e. a RPL Instance with a combination of storing and non-storing i.e. a RPL Instance with a combination of storing and non-storing
nodes is not supported with the current specifications at the time of nodes is not supported with the current specifications at the time of
writing this document. writing this document.
+--------------+ +--------------+
| Upper Layers | | Upper Layers |
skipping to change at page 12, line 51 skipping to change at page 14, line 4
inserted on a hop-by-hop basis, or when it can target the destination inserted on a hop-by-hop basis, or when it can target the destination
node directly. There are these possible situations: hop-by-hop node directly. There are these possible situations: hop-by-hop
necessary (indicated by "hop"), or destination address possible necessary (indicated by "hop"), or destination address possible
(indicated by "dst"). In all cases hop by hop MAY be used. (indicated by "dst"). In all cases hop by hop MAY 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.
In all cases the RPI headers are needed, since it identifies In all cases the RPI headers are needed, since it identifies
inconsistencies (loops) in the routing topology. In all cases the inconsistencies (loops) in the routing topology. In all cases the
RH3 is not need because we do not indicate the route in storing mode. RH3 is not needed because we do not indicate the route in storing
mode.
In each case, 6LR_i are the intermediate routers from source to In each case, 6LR_i are the intermediate routers from source to
destination. "1 <= i >= n", n is the number of routers (6LR) that destination. "1 <= i >= n", n is the number of routers (6LR) that
the packet go through from source (6LN) to destination. the packet go through from source (6LN) to destination.
The leaf can be a router 6LR or a host, both indicated as 6LN (see The leaf can be a router 6LR or a host, both indicated as 6LN (see
Figure 6). Figure 6).
+---------------------+--------------+----------+--------------+ +---------------------+--------------+----------+--------------+
| Interaction between | Use Case | IP-in-IP | IP-in-IP dst | | Interaction between | Use Case | IP-in-IP | IP-in-IP dst |
skipping to change at page 18, line 44 skipping to change at page 19, line 44
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) --> not-RPL-aware-leaf (IPv6) --> 6LR_1 --> 6LR_i -->root (6LBR) -->
Internet Internet
For example, a communication flow could be: Node G --> Node E --> For example, a communication flow could be: Node G --> Node E -->
Node B --> Node A root(6LBR) --> Internet Node B --> Node A root(6LBR) --> Internet
The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed The 6LR_1 (i=1) node will add an IP-in-IP(RPI) header addressed
either to the root, or hop-by-hop such that the root can remove the either to the root, or hop-by-hop such that the root can remove the
RPI header before passing upwards. (EDNOTE: we SHOULD recommend one RPI header before passing upwards. The IP-in-IP addressed to the
or the other) root cause less processing overhead. On the other hand, with hop-by-
hop the intermediate routers can check the routing tables for a
better routing path, thus it could be more efficient and faster.
Implementation should decide wich approach to take.
The originating node will ideally leave the IPv6 flow label as zero The originating node will ideally leave the IPv6 flow label as zero
so that the packet can be better compressed through the LLN. The so that the packet can be better compressed through the LLN. The
6LBR will set the flow label of the packet to a non-zero value when 6LBR will set the flow label of the packet to a non-zero value when
sending to the Internet. sending to the Internet.
+---------+-----+-------------+-------------+-------------+---------+ +---------+-----+-------------+-------------+-------------+---------+
| Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne | | Header | IPv | 6LR_1 | 6LR_i | 6LBR | Interne |
| | 6 | | [i=2,..,n]_ | | t | | | 6 | | [i=2,..,n]_ | | t |
+---------+-----+-------------+-------------+-------------+---------+ +---------+-----+-------------+-------------+-------------+---------+
skipping to change at page 26, line 42 skipping to change at page 27, line 42
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI | | Removed headers | -- | -- | RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+-----+-------+------+ +-------------------+-----+-------+------+
Non Storing: Summary of the use of headers from RPL-aware-leaf to Non Storing: Summary of the use of headers from RPL-aware-leaf to
root root
7.1.2. on-SM: Example of Flow from root to RPL-aware-leaf 7.1.2. Non-SM: Example of Flow from root to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN) root (6LBR) --> 6LR_i --> RPL-aware-leaf (6LN)
For example, a communication flow could be: Node A (root) --> Node B For example, a communication flow could be: Node A (root) --> Node B
--> Node D --> Node F --> Node D --> Node F
6LR_i are the intermediate routers from source to destination. In 6LR_i are the intermediate routers from source to destination. In
this case, "1 <= i >= n", n is the number of routers (6LR) that the this case, "1 <= i >= n", n is the number of routers (6LR) that the
packet go through from source (6LBR) to destination (6LN). packet go through from source (6LBR) to destination (6LN).
skipping to change at page 43, line 48 skipping to change at page 44, line 48
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-04 (work in progress), July 2017. backbone-router-05 (work in progress), January 2018.
[I-D.ietf-6man-rfc6434-bis] [I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-02 (work in Requirements", draft-ietf-6man-rfc6434-bis-02 (work in
progress), October 2017. progress), October 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-12 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-13 (work
in progress), August 2017. in progress), November 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 Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-12 (work in progress), October 2017. plane-13 (work in progress), December 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-08 (work in progress), October 2017. keyinfra-09 (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-02 (work in state in RPL", draft-ietf-roll-dao-projection-02 (work in
progress), September 2017. progress), September 2017.
[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,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
 End of changes. 36 change blocks. 
72 lines changed or deleted 82 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/