draft-ietf-roll-useofrplinfo-28.txt   draft-ietf-roll-useofrplinfo-29.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Aalto Internet-Draft Aalto
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: November 18, 2019 P. Thubert Expires: November 21, 2019 P. Thubert
Cisco Cisco
May 17, 2019 May 20, 2019
Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-28 draft-ietf-roll-useofrplinfo-29
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 (RPL Option Type), RFC 6554 enumerates the cases where RFC6553 (RPL Option Type), RFC6554
(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
required in data plane. This analysis provides the basis on which to required in data plane. This analysis provides the basis on which to
design efficient compression of these headers. This document updates design efficient compression of these headers. This document updates
RFC 6553 adding a change to the RPL Option Type. Additionally, this RFC6553 adding a change to the RPL Option Type. Additionally, this
document updates RFC 6550 defining a flag in the DIO Configuration document updates RFC6550 defining a flag in the DIO Configuration
Option to indicate about this change and updates RFC8138 as well to Option to indicate about this change and updates RFC8138 as well to
consider the new Option Type when the RPL Option is decompressed. consider the new Option Type when the RPL Option is decompressed.
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 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 November 18, 2019. This Internet-Draft will expire on November 21, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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
skipping to change at page 3, line 47 skipping to change at page 3, line 47
11. Security Considerations . . . . . . . . . . . . . . . . . . . 47 11. Security Considerations . . . . . . . . . . . . . . . . . . . 47
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 50
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 50
13.1. Normative References . . . . . . . . . . . . . . . . . . 50 13.1. Normative References . . . . . . . . . . . . . . . . . . 50
13.2. Informative References . . . . . . . . . . . . . . . . . 51 13.2. Informative References . . . . . . . . . . . . . . . . . 51
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 54
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. RFC6553
[RFC6553] defines the "RPL option" (RPL Packet Information or RPI), [RFC6553] defines the "RPL option" (RPL Packet Information or RPI),
carried within the IPv6 Hop-by-Hop header to quickly identify carried within the IPv6 Hop-by-Hop header to quickly identify
inconsistencies (loops) in the routing topology. RFC 6554 [RFC6554] inconsistencies (loops) in the routing topology. RFC6554 [RFC6554]
defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header defines the "RPL Source Route Header" (RH3), an IPv6 Extension Header
to deliver datagrams within a RPL routing domain, particularly in to deliver datagrams within a RPL routing domain, particularly in
non-storing mode. non-storing mode.
These various items are referred to as RPL artifacts, and they are These various items are referred to as RPL artifacts, and they are
seen on all of the data-plane traffic that occurs in RPL routed seen on all of the data-plane traffic that occurs in RPL routed
networks; they do not in general appear on the RPL control plane networks; they do not in general appear on the RPL control plane
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).
skipping to change at page 5, line 12 skipping to change at page 5, line 12
considerations of supporting not-RPL-aware-leaves. Section 9 depicts considerations of supporting not-RPL-aware-leaves. Section 9 depicts
operational considerations for the proposed change on RPL Option operational considerations for the proposed change on RPL Option
type, section 10 the IANA considerations and then section 11 type, section 10 the IANA considerations and then section 11
describes the security aspects. describes the security aspects.
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",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119], [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
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: A device which implements RPL, thus the device is RPL- RPL-node: A device which implements RPL, thus the device is RPL-
aware. Please note that the device can be found inside the LLN or aware. Please note that the device can be found inside the LLN or
outside LLN. In this document a RPL-node which is a leaf of a outside LLN. In this document a RPL-node which is a leaf of a
(Destination Oriented Directed Acyclic Graph) DODAG is called RPL- (Destination Oriented Directed Acyclic Graph) DODAG is called RPL-
aware-leaf (Raf). aware-leaf (Raf).
skipping to change at page 7, line 13 skipping to change at page 7, line 13
encapsulation. encapsulation.
[RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in [RFC6553] (Section 6, Page 7) states as shown in Figure 2, that in
the Option Type field of the RPL Option header, the two high order the Option Type field of the RPL Option header, the two high order
bits must be set to '01' and the third bit is equal to '1'. The bits must be set to '01' and the third bit is equal to '1'. The
first two bits indicate that the IPv6 node must discard the packet if first two bits indicate that the IPv6 node must discard the packet if
it doesn't recognize the option type, and the third bit indicates it doesn't recognize the option type, and the third bit indicates
that the Option Data may change in route. The remaining bits serve that the Option Data may change in route. The remaining bits serve
as the option type. as the option type.
Hex Value Binary Value +-------+-------------------+----------------+-----------+
act chg rest Description Reference | Hex | Binary Value | Description | Reference |
--------- --- --- ------- ----------------- ---------- + Value +-------------------+ + +
0x63 01 1 00011 RPL Option [RFC6553] | | act | chg | rest | | |
+-------+-----+-----+-------+----------------+-----------+
| 0x63 | 01 | 1 | 00011 | RPL Option | [RFC6553] |
+-------+-----+-----+-------+----------------+-----------+
Figure 2: Option Type in RPL Option. Figure 2: Option Type in RPL Option.
This document illustrates that is is not always possible to know for This document illustrates that is is not always possible to know for
sure at the source that a packet will only travel within the RPL sure at the source that a packet will only travel within the RPL
domain or may leave it. domain or may leave it.
At the time [RFC6553] was published, leaking a Hop-by-Hop header in At the time [RFC6553] was published, leaking a Hop-by-Hop header in
the outer IPv6 header chain could potentially impact core routers in the outer IPv6 header chain could potentially impact core routers in
the internet. So at that time, it was decided to encapsulate any the internet. So at that time, it was decided to encapsulate any
skipping to change at page 8, line 36 skipping to change at page 8, line 36
With the new Option Type, if an IPv6 (intermediate) node (RPL-not- With the new Option Type, if an IPv6 (intermediate) node (RPL-not-
capable) receives a packet with an RPL Option, it should ignore the capable) receives a packet with an RPL Option, it should ignore the
Hop-by-Hop RPL option (skip over this option and continue processing Hop-by-Hop RPL option (skip over this option and continue processing
the header). This is relevant, as it was mentioned previously, in the header). This is relevant, as it was mentioned previously, in
the case that there is a flow from RPL-aware-leaf to Internet (see the case that there is a flow from RPL-aware-leaf to Internet (see
Section 6.2.1). Section 6.2.1).
This is a significant update to [RFC6553]. This is a significant update to [RFC6553].
Hex Value Binary Value +-------+-------------------+-------------+------------+
act chg rest Description Reference | Hex | Binary Value | Description | Reference |
--------- --- --- ------- ----------------- ---------- + Value +-------------------+ + +
0x23 00 1 00011 RPL Option [RFCXXXX] | | act | chg | rest | | |
+-------+-----+-----+-------+-------------+------------+
| 0x23 | 00 | 1 | 00011 | RPL Option |[RFCXXXX](*)|
+-------+-----+-----+-------+-------------+------------+
Figure 3: Revised Option Type in RPL Option. Figure 3: Revised Option Type in RPL Option. (*)represents this
document
Without the signaling described below, this change would otherwise Without the signaling described below, this change would otherwise
create a flag day for existing networks which are currently using create a flag day for existing networks which are currently using
0x63 as the RPI value. A move to 0x23 will not be understood by 0x63 as the RPI value. A move to 0x23 will not be understood by
those networks. It is suggested that implementations accept both those networks. It is suggested that implementations accept both
0x63 and 0x23 when processing. 0x63 and 0x23 when processing.
When forwarding packets, implementations SHOULD use the same value as When forwarding packets, implementations SHOULD use the same value as
it was received (This is required because, RPI type code can not be it was received (This is required because, RPI type code can not be
changed by [RFC8200]). It allows to the network to be incrementally changed by [RFC8200]). It allows to the network to be incrementally
skipping to change at page 10, line 15 skipping to change at page 10, line 15
3.2. Updates to RFC6550: Indicating the new RPI in the DODAG 3.2. Updates to RFC6550: 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, this section defines a flag new RPI (0x23) and old RPI (0x63) nodes, this section defines a flag
in the DIO Configuration Option, to indicate when then new RPI value in the DIO Configuration Option, to indicate when then new RPI value
can be safely used. This means, the flag is going to indicate the can be safely used. This means, the flag is going to indicate the
type of RPI that the network is using. Thus, when a node join to a type of RPI that the network is using. Thus, when a node join to a
network will know which value to use. With this, RPL-capable nodes network will know which value to use. With this, RPL-capable nodes
know if it is safe to use 0x23 when creating a new RPI. A node that know if it is safe to use 0x23 when creating a new RPI. A node that
forwards a packet with an RPI MUST not modify the option type of the forwards a packet with an RPI MUST NOT modify the option type of the
RPI. RPI.
This is done via a DODAG Configuration Option flag which will This is done via a DODAG Configuration Option flag which will
propagate through the network. If the flag is received with a value propagate through the network. If the flag is received with a value
zero (which is the default), then new nodes will remain in RFC6553 zero (which is the default), then new nodes will remain in RFC6553
Compatible Mode; originating traffic with the old-RPI (0x63) value. Compatible Mode; originating 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
skipping to change at page 21, line 5 skipping to change at page 21, line 5
When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E), When the packet arrives from IPv6 node (Node G) to 6LR_1 (Node E),
the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6 the 6LR_1 will insert a RPI header, encapsulated in a IPv6-in-IPv6
header. The IPv6-in-IPv6 header can be addressed to the next hop header. The IPv6-in-IPv6 header can be addressed to the next hop
(Node B), or to the root (Node A). The root removes the header and (Node B), or to the root (Node A). The root removes the header and
processes the packet. processes the packet.
The Figure 8 shows the table that summarizes what headers are needed The Figure 8 shows the table that summarizes what headers are needed
for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | | Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst |
| | src | | | | | | src | | | |
| | node | | | | | | node | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- | | Inserted | -- | IP6-IP6(RPI) | IP6-IP6(RPI)[1] | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Removed | -- | -- | -- | IP6-IP6(RPI)[1][2] | | Removed | -- | -- | -- |IP6-IP6(RPI)[1][2]|
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Re-added | -- | -- | IP6-IP6(RPI)[1] | -- | | Re-added | -- | -- | IP6-IP6(RPI)[1] | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Modified | -- | -- | IP6-IP6(RPI)[2] | -- | | Modified | -- | -- | IP6-IP6(RPI)[2] | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+------+--------------+-----------------+--------------------+ +-----------+------+--------------+-----------------+------------------+
Figure 8: Storing mode: Summary of the use of headers from not-RPL- Figure 8: Storing mode: Summary of the use of headers from not-RPL-
aware-leaf to root. [[1] Case where the IPv6-in-IPv6 header is aware-leaf to root. [1] Case where the IPv6-in-IPv6 header is
addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6 addressed to the next hop (Node B). [2] Case where the IPv6-in-IPv6
header is addressed to the root (Node A). header is addressed to the root (Node A).
6.2. Storing Mode: Interaction between Leaf and Internet. 6.2. Storing Mode: Interaction between Leaf and Internet.
In this section is described the communication flow in storing mode In this section is described the communication flow in storing mode
(SM) between, (SM) between,
RPL-aware-leaf to Internet RPL-aware-leaf to Internet
skipping to change at page 23, line 5 skipping to change at page 23, line 5
When the packet arrives from Internet to 6LBR the RPI header is added When the packet arrives from Internet to 6LBR the RPI header is added
in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination in a outer IPv6-in-IPv6 header (with the IPv6-in-IPv6 destination
address set to the 6LR) and sent to 6LR, which modifies the rank in address set to the 6LR) and sent to 6LR, which modifies the rank in
the RPI. When the packet arrives at 6LN the RPI header is removed the RPI. When the packet arrives at 6LN the RPI header is removed
and the packet processed. and the packet processed.
The Figure 9 shows the table that summarizes what headers are needed The Figure 9 shows the table that summarizes what headers are needed
for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Header | Internet | 6LBR | 6LR_i | 6LN dst | | Header | Internet | 6LBR | 6LR_i | 6LN dst |
| | src | | | | | | src | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Inserted | -- | IP6-IP6(RPI) | -- | -- | | Inserted | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Removed | -- | -- | -- | IP6-IP6(RPI) | | Removed | -- | -- | -- | IP6-IP6(RPI) |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Re-added | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Modified | -- | -- | IP6-IP6(RPI) | -- | | Modified | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
| Untouched | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+-----------+----------+--------------+--------------+------------------+ +-----------+----------+--------------+--------------+--------------+
Figure 9: Storing mode: Summary of the use of headers from Internet Figure 9: Storing mode: Summary of the use of headers from Internet
to RPL-aware-leaf. to RPL-aware-leaf.
6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet 6.2.3. SM: Example of Flow from not-RPL-aware-leaf to Internet
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
skipping to change at page 28, line 25 skipping to change at page 28, line 25
from the common parent (6LR_x) to destination 6LN. from the common parent (6LR_x) to destination 6LN.
The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node The 6LR_ia (ia=1) (Node E) receives the packet from the the IPv6 node
(Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6 (Node G) and inserts and the RPI header encapsulated in IPv6-in-IPv6
header. The IPv6-in-IPv6 header is addressed to the destination 6LN header. The IPv6-in-IPv6 header is addressed to the destination 6LN
(Node F). (Node F).
The Figure 12 shows the table that summarizes what headers are needed The Figure 12 shows the table that summarizes what headers are needed
for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN | | Header |IPv6 | 6LR_ia | Common | 6LR_id | 6LN |
| |src | | Parent | | dst | | |src | | Parent | | dst |
| |node | | (6LRx) | | | | |node | | (6LRx) | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | | Inserted| -- |IP6-IP6(RPI)| -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Removed | -- | -- | -- | -- |IP6-IP6(RPI)| | Removed | -- | -- | -- | -- |IP6-IP6(RPI)|
| headers | | | | | | | headers | | | | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Re-added | -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
| Modified | -- | -- | IP6-IP6(RPI) | IP6-IP6(RPI) | -- | | Modified| -- | -- |IP6-IP6(RPI) |IP6-IP6(RPI) | -- |
| headers | | | | | | | headers | | | | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
|Untouched | -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+----------+-----+--------------+--------------+--------------+------------+ +---------+-----+------------+-------------+-------------+------------+
Figure 12: Storing mode: Summary of the use of headers from not-RPL- Figure 12: Storing mode: Summary of the use of headers from not-RPL-
aware-leaf to RPL-aware-leaf. aware-leaf to RPL-aware-leaf.
6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 6.3.4. SM: Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
leaf leaf
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id not-RPL-aware 6LN (IPv6 src)--> 6LR_1--> 6LR_ia --> 6LBR --> 6LR_id
skipping to change at page 35, line 5 skipping to change at page 35, line 5
6LR_1 (i=1) is the router that receives the packets from the IPv6 6LR_1 (i=1) is the router that receives the packets from the IPv6
node. node.
In this case the RPI is added by the first 6LR (6LR1) (Node E), In this case the RPI is added by the first 6LR (6LR1) (Node E),
encapsulated in an IPv6-in-IPv6 header, and is modified in the encapsulated in an IPv6-in-IPv6 header, and is modified in the
following 6LRs. The RPI and entire packet is consumed by the root. following 6LRs. The RPI and entire packet is consumed by the root.
The Figure 16 shows the table that summarizes what headers are needed The Figure 16 shows the table that summarizes what headers are needed
for this use case. for this use case.
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR dst | | Header |IPv6| 6LR_1 | 6LR_i | 6LBR dst |
| | src | | | | | |src | | | |
| | node | | | | | |node| | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Inserted | -- | IPv6-in-IPv6(RPI) | -- | -- | | Inserted| -- |IPv6-in-IPv6(RPI)| -- | -- |
| headers | | | | | | headers | | | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Removed | -- | -- | -- |IPv6-in-IPv6(RPI)| | Removed | -- | -- | -- |IPv6-in-IPv6(RPI)|
| headers | | | | | | headers | | | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Re-added | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
| Modified | -- | -- | IPv6-in-IPv6(RPI)| -- | | Modified| -- | -- |IPv6-in-IPv6(RPI)| -- |
| headers | | | | | | headers | | | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
|Untouched | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
+----------+------+-------------------+------------------+-----------------+ +---------+----+-----------------+-----------------+-----------------+
Figure 16: Non Storing mode: Summary of the use of headers from not- Figure 16: Non Storing mode: Summary of the use of headers from not-
RPL-aware-leaf to root RPL-aware-leaf to root
7.2. Non-Storing Mode: Interaction between Leaf and Internet 7.2. Non-Storing Mode: Interaction between Leaf and Internet
This section will describe the communication flow in Non Storing Mode This section will describe the communication flow in Non Storing Mode
(Non-SM) between: (Non-SM) between:
RPL-aware-leaf to Internet RPL-aware-leaf to Internet
skipping to change at page 38, line 5 skipping to change at page 38, line 5
In this case the flow label is recommended to be zero in the IPv6 In this case the flow label is recommended to be zero in the IPv6
node. As RPL headers are added in the IPv6 node packet, the first node. As RPL headers are added in the IPv6 node packet, the first
6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header. 6LR (6LR_1) will add a RPI header inside a new IPv6-in-IPv6 header.
The IPv6-in-IPv6 header will be addressed to the root. This case is The IPv6-in-IPv6 header will be addressed to the root. This case is
identical to the storing-mode case (see Section 6.2.3). identical to the storing-mode case (see Section 6.2.3).
The Figure 17 shows the table that summarizes what headers are needed The Figure 17 shows the table that summarizes what headers are needed
for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6. for this use case. In the figure, IP6-IP6 refers to IPv6-in-IPv6.
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Header | IPv6 | 6LR_1 | 6LR_i | 6LBR | Internet | | Header |IPv6| 6LR_1 | 6LR_i | 6LBR |Internet|
| | src | | [i=2,..,n] | | dst | | |src | | [i=2,..,n] | | dst |
| | node | | | | | | |node| | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Inserted | -- | IP6-IP6(RPI) | -- | -- | -- | | Inserted| -- |IP6-IP6(RPI) | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Removed | -- | -- | -- | IP6-IP6(RPI) | -- | | Removed | -- | -- | -- | IP6-IP6(RPI) | -- |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Re-added | -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Modified | -- | -- | IP6-IP6(RPI) | -- | -- | | Modified| -- | -- | IP6-IP6(RPI) | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
| Untouched | -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+------+--------------+--------------+--------------+----------+ +---------+----+-------------+--------------+--------------+--------+
Figure 17: Non Storing mode: Summary of the use of headers from not- Figure 17: Non Storing mode: Summary of the use of headers from not-
RPL-aware-leaf to Internet RPL-aware-leaf to Internet
7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf 7.2.4. Non-SM: Example of Flow from Internet to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6) Internet --> root (6LBR) --> 6LR_i --> not-RPL-aware-leaf (IPv6)
skipping to change at page 39, line 5 skipping to change at page 39, line 5
The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The The 6LBR must add an RH3 header inside an IPv6-in-IPv6 header. The
6LBR will know the path, and will recognize that the final node is 6LBR will know the path, and will recognize that the final node is
not an RPL capable node as it will have received the connectivity DAO not an RPL capable node as it will have received the connectivity DAO
from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6 from the nearest 6LR. The 6LBR can therefore make the IPv6-in-IPv6
header destination be the last 6LR. The 6LBR will set to zero the header destination be the last 6LR. The 6LBR will set to zero the
flow label upon entry in order to aid compression. flow label upon entry in order to aid compression.
The Figure 18 shows the table that summarizes what headers are needed The Figure 18 shows the table that summarizes what headers are needed
for this use case. for this use case.
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Header |Internet| 6LBR | 6LR_1 | 6lR_i | IPv6 | | Header |Internet| 6LBR | 6LR_1 | 6lR_i |IPv6 |
| | src | | | (i=2,...,n) | dst | | | src | | | (i=2,...,n) |dst |
| | | | | | node | | | | | | |node |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Inserted | -- | IPv6-in-IPv6 | -- | -- | -- | | Inserted| -- | IPv6-in-IPv6| -- | -- | -- |
| headers | | (RH3,RPI) | | | | | headers | | (RH3,RPI) | | | |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Removed | -- | -- | -- | IPv6-in-IPv6 | -- | | Removed | -- | -- | -- | IPv6-in-IPv6 | -- |
| headers | | | | (RH3,RPI)[1] | | | headers | | | | (RH3,RPI)[1] | |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Re-added | -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Modified | -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- | | Modified| -- | -- | IPv6-in-IPv6 | IPv6-in-IPv6 | -- |
| headers | | | (RH3,RPI) | (RH3,RPI) | | | headers | | | (RH3,RPI) | (RH3,RPI) | |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
| Untouched | -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-----------+--------+--------------+--------------+--------------+------+ +---------+--------+-------------+--------------+--------------+-----+
Figure 18: Non-Storing mode: Summary of the use of headers from Figure 18: Non-Storing mode: Summary of the use of headers from
Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node. Internet to not-RPL-aware-leaf [1] The last 6LR before the IPv6 node.
7.3. Non-Storing Mode: Interaction between Leafs 7.3. Non-Storing Mode: Interaction between Leafs
In this section is described the communication flow in Non Storing In this section is described the communication flow in Non Storing
Mode (Non-SM) between, Mode (Non-SM) between,
RPL-aware-leaf to RPL-aware-leaf RPL-aware-leaf to RPL-aware-leaf
skipping to change at page 41, line 5 skipping to change at page 41, line 5
Otherwise, there may be a RPI header buried inside the inner IP Otherwise, there may be a RPI header buried inside the inner IP
header, which should get ignored. header, which should get ignored.
Networks that use the RPL P2P extension [RFC6997] are essentially Networks that use the RPL P2P extension [RFC6997] are essentially
non-storing DODAGs and fall into this scenario or scenario non-storing DODAGs and fall into this scenario or scenario
Section 7.1.2, with the originating node acting as 6LBR. Section 7.1.2, with the originating node acting as 6LBR.
The Figure 19 shows the table that summarizes what headers are needed The Figure 19 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN |
| | src | | | | dst | | | src | | | | dst |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
| Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- |
| headers | (RPI1) | |(RH3-> 6LN, | | | | headers | (RPI1) | |(RH3-> 6LN, | | |
| | | | RPI2) | | | | | | | RPI2) | | |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
| Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6|
| headers | | | (RPI1) | | (RH3, | | headers | | | (RPI1) | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
| Modified| -- |IP6-in-IP6| -- |IPv6-in-IPv6| -- | | Modified| -- |IP6-in-IP6| -- |IP6-in-IP6| -- |
| headers | | (RPI1) | | (RPI2) | | | headers | | (RPI1) | | (RPI2) | |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+------------+----------+------------+------------+------------+ +---------+------------+----------+------------+----------+------------+
Figure 19: Non Storing mode: Summary of the use of headers for RPL- Figure 19: Non Storing mode: Summary of the use of headers for RPL-
aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6. aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6.
7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-
leaf leaf
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)
skipping to change at page 46, line 33 skipping to change at page 46, line 33
new RPI in the DODAG Configuration Option Flag is a way to avoid the new RPI in the DODAG Configuration Option Flag is a way to avoid the
flag day in a network. It is recommended that a network process both flag day in a network. It is recommended that a network process both
options to enable interoperability. options to enable interoperability.
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 as shown in Options and Hop-by-Hop Options registry from 0x63 to 0x23 as shown in
Figure 23. Figure 23.
[RFCXXXX] represents this document. +-------+-------------------+------------------------+---------- -+
| Hex | Binary Value | Description | Reference |
Hex Value Binary Value + Value +-------------------+ + +
act chg rest Description Reference | | act | chg | rest | | |
--------- --- --- ------- ----------------- ---------- +-------+-----+-----+-------+------------------------+------------+
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 23: Option Type in RPL Option. Figure 23: Option Type in RPL Option.(*)represents this document
DODAG Configuration option is updated as follows (Figure 24): DODAG Configuration option is updated as follows (Figure 24):
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| Bit number | Description | Reference | | Bit number | Description | Reference |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
| 3 | RPI 0x23 enable | This document | | 3 | RPI 0x23 enable | This document |
+------------+-----------------+---------------+ +------------+-----------------+---------------+
Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag- Figure 24: DODAG Configuration Option Flag to indicate the RPI-flag-
 End of changes. 23 change blocks. 
169 lines changed or deleted 179 lines changed or added

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