< draft-ietf-roll-useofrplinfo-07.txt   draft-ietf-roll-useofrplinfo-08.txt >
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Informational M. Richardson Intended status: Informational M. Richardson
Expires: January 21, 2017 SSW Expires: March 17, 2017 SSW
P. Thubert P. Thubert
Cisco Cisco
July 20, 2016 September 13, 2016
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-07 draft-ietf-roll-useofrplinfo-08
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.
skipping to change at page 1, line 38 skipping to change at page 1, line 38
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 January 21, 2017. This Internet-Draft will expire on March 17, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . 3 2. Terminology and Requirements Language . . . . . . . . . . . . 3
2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 4
3. Sample/reference topology . . . . . . . . . . . . . . . . . . 4 3. Sample/reference topology . . . . . . . . . . . . . . . . . . 4
4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 4. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 9
5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 9 5.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 9
5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 10 5.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 10
5.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 11 5.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 11
5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 11 5.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 11
5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 12 5.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 12
5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 12 5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 12
5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 13 5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 13
5.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 14 5.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 14
5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 14 5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 15
5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 15 5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 16
5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 15 5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 17
5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 16 leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 18
6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 16 6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 19
6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 17 6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 20
6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 17 6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 20
6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 18 6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 21
6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 19 6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 22
6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 19 6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 23
6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 20 6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 23
6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 21 6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 24
6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 21 6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 25
6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 22 6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 26
6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 23 6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 27
6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 24 6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 28
6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware- 6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-
leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 24 leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 29
7. Observations about the problem . . . . . . . . . . . . . . . 25 7. Observations about the cases . . . . . . . . . . . . . . . . 30
7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 25 7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 30
7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 26 7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 31
8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 26 8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 31
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31
10. Security Considerations . . . . . . . . . . . . . . . . . . . 27 10. Security Considerations . . . . . . . . . . . . . . . . . . . 32
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 32
12.1. Normative References . . . . . . . . . . . . . . . . . . 27 12.1. Normative References . . . . . . . . . . . . . . . . . . 32
12.2. Informative References . . . . . . . . . . . . . . . . . 28 12.2. Informative References . . . . . . . . . . . . . . . . . 33
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
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 4, line 5 skipping to change at page 3, line 49
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", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Terminology defined in [RFC7102] applies to this document: LBR, LLN, Terminology defined in [RFC7102] applies to this document: LBR, LLN,
RPL, RPL Domain and ROLL. RPL, RPL Domain and ROLL.
RPL-node: It is device which implements RPL, thus we can say that the
device is RPL-capable or RPL-aware. Please note that the device can
be found inside the LLN or outside LLN. In this document a RPL-node
which is a leaf is called RPL-aware-leaf.
RPL-not-capable: It is device which do not implement RPL, thus we can
say that the device is not-RPL-aware. Please note that the device
can be found inside the LLN. In this document a not-RPL-node which
is a leaf is called not-RPL-aware-leaf.
2.1. hop-by-hop IPv6-in-IPv6 headers 2.1. hop-by-hop IPv6-in-IPv6 headers
The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header The term "hop-by-hop IPv6-in-IPv6" header refers to: adding a header
that originates from a node to an adjacent node, using the addresses that originates from a node to an adjacent node, using the addresses
(usually the GUA or ULA, but could use the link-local addresses) of (usually the GUA or ULA, but could use the link-local addresses) of
each node. If the packet must traverse multiple hops, then it must each node. If the packet must traverse multiple hops, then it must
be decapsulated at each hop, and then re-encapsulated again in a be decapsulated at each hop, and then re-encapsulated again in a
similar fashion. similar fashion.
3. Sample/reference topology 3. Sample/reference topology
skipping to change at page 6, line 36 skipping to change at page 6, line 36
+-+---+ +-+---+ +--+--+ +- --+ +---+-+ +-+---+ +-+---+ +--+--+ +- --+ +---+-+
|Leaf | | | | | |Leaf| |Leaf | |Leaf | | | | | |Leaf| |Leaf |
| 6LN | | | | | | 6LN| | 6LN | | 6LN | | | | | | 6LN| | 6LN |
+-----+ +-----+ +-----+ +----+ +-----+ +-----+ +-----+ +-----+ +----+ +-----+
Figure 2: A reference RPL Topology. Figure 2: A reference RPL Topology.
In Figure 2 is showed the reference RPL Topology for this document. In Figure 2 is showed the reference RPL Topology for this document.
The numbers in or above the nodes are there so that they may be The numbers in or above the nodes are there so that they may be
referenced in subsequent sections. In the figure, a 6LN can be a referenced in subsequent sections. In the figure, a 6LN can be a
router or a host. The 6LN leafs marked as (21) and (25) are routers. router or a host. The 6LN leafs marked as (21) is a RPL host that
The leaf marked 6LN (24) is a device which does not speak RPL at all does not have forwarding capability and (25) is a RPL router. The
leaf marked 6LN (24) is a device which does not speak RPL at all
(not-RPL-aware), but uses Router-Advertisements, 6LowPAN DAR/DAC and (not-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 this leaf (24) is often named IPv6 node. The 6LBR in the document this leaf (24) is often named IPv6 node. The 6LBR in the
figure is the root of the Global DODAG. figure is the root of the Global DODAG.
This document is in part motivated by the work that is ongoing at the This document is in part motivated by the work that is ongoing at the
6TiSCH working group. The 6TiSCH architecture 6TiSCH working group. The 6TiSCH architecture
[I-D.ietf-6tisch-architecture] draft explains the network [I-D.ietf-6tisch-architecture] draft explains the network
architecture of a 6TiSCH network. architecture of a 6TiSCH network.
4. Use cases 4. Use cases
In data plane context a combination of RFC6553, RFC6554 and IPv6-in- In data plane context a combination of RFC6553, RFC6554 and IPv6-in-
IPv6 encapsulation is going to be analyzed for the following traffic IPv6 encapsulation is going to be analyzed for the following traffic
flows. flows.
This version of the document assumes the changes in This version of the document assumes the changes in
[I-D.ietf-6man-rfc2460bis] are passed. [I-D.ietf-6man-rfc2460bis] are passed (at the time to write this
specification, the draft is on version 05).
RPL-aware-leaf to root RPL-aware-leaf to root
root to RPL-aware-leaf root to RPL-aware-leaf
not-RPL-aware-leaf to root not-RPL-aware-leaf to root
root to not-RPL-aware-leaf root to not-RPL-aware-leaf
RPL-aware-leaf to Internet RPL-aware-leaf to Internet
skipping to change at page 7, line 41 skipping to change at page 7, line 42
RPL-aware-leaf to not-RPL-aware-leaf (non-storing) RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
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] is that Extensions may not be added or removed except by [RFC2460]. Extensions may not be added or removed except by the
the sender or the receiver. (A revision to RFC2460 considered sender or the receiver.
changing this rule, but has kept it)
But, options in the Hop-by-Hop option which are marked with option But, options in the Hop-by-Hop option which are marked with option
type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD
be ignored when received by a host or router which does not be ignored when received by a host or router which does not
understand that option. understand that option.
This means that in general, any packet that leaves the RPL domain of This means that in general, any packet that leaves the RPL domain of
an LLN (or leaves the LLN entirely) will NOT be discarded, even if it 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] has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]
SRH3 Extension Header (S)RH3. SRH3 Extension Header (S)RH3.
With abolition of one of these rules it means that the RPI Hop-by-Hop The recent change to the second of these rules it means that the RPI
option MAY be left in place even if the end host does host understand Hop-by-Hop option MAY be left in place even if the end host does not
it. This collapses many of the cases above (where it says "or") understand it.
NOTE: There is some possible security risk when the RPI information
is released to the Internet. At this point this is a theoretical
situation. It is clear that the RPI option would waste some network
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 where the new header can be placed. header. The new header can be placed is placed after this new outer
IP header.
This also means that a Header can only be removed by an intermediate A corollory is that an SHR3 or RPI Option can only be removed by an
router if it is placed in an encapsulating IPv6 Header, and in that intermediate router if it is placed in an encapsulating IPv6 Header,
case, the whole encapsulating header must be removed - a replacement which is addressed to the intermediate router. When it does so, the
may be added. Further, an intermediate router can only remove such whole encapsulating header must be removed. (A replacement may be
an outer header if that outer header has the router as the added). This sometimes can result in outer IP headers being
destination! addressed to the next hop router using link-local addresses.
Both RPI and RH3 headers may be modified by routers on the path of Both RPI and RH3 headers may be modified in very specific ways by
the packet without the need to add to remove an encapsulating header. routers on the path of the packet without the need to add to remove
Both headers were designed with this modification in mind, and both an encapsulating header. Both headers were designed with this
the RPL RH and the RPL option are marked mutable but recoverable, so modification in mind, and both the RPL RH and the RPL option are
an IPsec AH security header can be applied across these headers, but marked mutable but recoverable: so an IPsec AH security header can be
it may not secure all the values in those headers. applied across these headers, but it can not secure the values which
mutate.
RPI should be present in every single RPL data packet. There is one RPI should be present in every single RPL data packet. There is one
exception in non-storing mode: when a packet is going down from the exception in non-storing mode: when a packet is going down from the
root. In a downward non-storing mode, the entire route is written, root. In a downward non-storing mode, the entire route is written,
so there can be no loops by construction, nor any confusion about so there can be no loops by construction, nor any confusion about
which forwarding table to use. There may be cases (such as in which forwarding table to use (as the root has already made all
6tisch) where the instanceID may still be needed to pick an routing decisions). There still may be cases (such as in 6tisch)
appropriate priority or channel at each hop. where the instanceID portion of the RPI header may still be needed to
pick an appropriate priority or channel at each hop.
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 consise. is clear, while later examples are more consise.
5. Storing mode 5. Storing mode
skipping to change at page 9, line 23 skipping to change at page 9, line 31
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.
The leaf can be a router 6LR or a host, both indicated as 6LN. The leaf can be a router 6LR or a host, both indicated as 6LN.
+--------------+-------+-------+-----------+---------------+ +--------------+-------+-------+-----------+---------------+
| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst | | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |
+--------------+-------+-------+-----------+---------------+ +--------------+-------+-------+-----------+---------------+
| Raf to root | Yes | No | No | -- | | Raf to root | Yes | No | No | -- |
| root to Raf | Yes | No | No | -- | | root to Raf | Yes | No | No | -- |
| root to ~Raf | Yes | No | Yes | hop | | root to ~Raf | Yes | No | No | -- |
| ~Raf to root | Yes | No | Yes | root | | ~Raf to root | Yes | No | Yes | root |
| Raf to Int | Yes | No | Yes | root | | Raf to Int | Yes | No | No | -- |
| Int to Raf | Yes | No | Yes | raf | | Int to Raf | Yes | No | Yes | raf |
| ~Raf to Int | Yes | No | Yes | root | | ~Raf to Int | Yes | No | Yes | root |
| Int to ~Raf | Yes | No | Yes | hop | | Int to ~Raf | Yes | No | Yes | hop |
| Raf to Raf | Yes | No | No | -- | | Raf to Raf | Yes | No | No | -- |
| Raf to ~Raf | Yes | No | Yes | hop | | Raf to ~Raf | Yes | No | No | -- |
| ~Raf to Raf | Yes | No | Yes | dst | | ~Raf to Raf | Yes | No | Yes | dst |
| ~Raf to ~Raf | Yes | No | Yes | hop | | ~Raf to ~Raf | Yes | No | Yes | hop |
+--------------+-------+-------+-----------+---------------+ +--------------+-------+-------+-----------+---------------+
Table 1: Headers needed in Storing mode: RPI, RH3, IP-in-IP Table 1: Headers needed in Storing mode: RPI, RH3, IP-in-IP
encapsulation encapsulation
5.1. Example of Flow from RPL-aware-leaf to root 5.1. Example of Flow from RPL-aware-leaf to root
In storing mode, RFC 6553 (RPI) is used to send RPL Information In storing mode, RFC 6553 (RPI) is used to send RPL Information
instanceID and rank information. instanceID and rank information.
As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does As stated in Section 16.2 of [RFC6550] a RPL-aware-leaf node does
not generally issue DIO messages; a leaf node accepts DIO messages not generally issue DIO messages; a leaf node accepts DIO messages
from upstream. (When the inconsistency in routing occurs, a leaf from upstream. (When the inconsistency in routing occurs, a leaf
node will generate a DIO with an infinite rank, to fix it). It may node will generate a DIO with an infinite rank, to fix it). It may
issue DAO and DIS messages though it generally ignores DAO and DIS issue DAO and DIS messages though it generally ignores DAO and DIS
messages. messages.
In storing mode, RFC 6553 (RPI) is used to send RPL Information
instanceID and rank information.
In this case the flow comprises: In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR --> 6LR,... --> root (6LBR) RPL-aware-leaf (6LN) --> 6LR1,... --> 6LRN --> root (6LBR)
As it was mentioned In this document 6LRs, 6LBR are always full- As it was mentioned In this document 6LRs, 6LBR are always full-
fledge RPL routers. fledge RPL routers.
The 6LN inserts the RPI header, and sends the packet to 6LR which The 6LN inserts the RPI header, and sends the packet to 6LR which
decrements the rank in RPI and sends the packet up. When the packet decrements the rank in RPI and sends the packet up. When the packet
arrives at 6LBR, the RPI is removed and the packet is processed. arrives at 6LBR, the RPI is removed and the packet is processed.
No IP-in-IP header is required. No IP-in-IP header is required.
skipping to change at page 10, line 40 skipping to change at page 10, line 44
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+-----+------+------+ +-------------------+-----+------+------+
Storing: Summary of the use of headers from RPL-aware-leaf to root Storing: Summary of the use of headers from RPL-aware-leaf to root
5.2. Example of Flow from root to RPL-aware-leaf 5.2. Example of Flow from root to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
root (6LBR)--> 6LR --> RPL-aware-leaf (6LN) root (6LBR) --> 6LR1,... --> 6LRN --> RPL-aware-leaf (6LN)
In this case the 6LBR inserts RPI header and sends the packet down, In this case the 6LBR inserts RPI header and sends the packet down,
the 6LR is going to increment the rank in RPI (examines instanceID the 6LR is going to increment the rank in RPI (examines instanceID
for multiple tables), the packet is processed in 6LN and RPI removed. for multiple tables), the packet is processed in 6LN and RPI removed.
No IP-in-IP header is required. No IP-in-IP header is required.
+-------------------+------+-------+------+ +-------------------+------+-------+------+
| Header | 6LBR | 6LR | 6LN | | Header | 6LBR | 6LR | 6LN |
+-------------------+------+-------+------+ +-------------------+------+-------+------+
skipping to change at page 11, line 21 skipping to change at page 11, line 21
| Modified headers | -- | RPI | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+------+-------+------+ +-------------------+------+-------+------+
Storing: Summary of the use of headers from root to RPL-aware-leaf Storing: Summary of the use of headers from root to RPL-aware-leaf
5.3. Example of Flow from root to not-RPL-aware-leaf 5.3. Example of Flow from root to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
root (6LBR)--> 6LR --> not-RPL-aware-leaf (6LN) root (6LBR) --> 6LR1,... --> 6LRN --> not-RPL-aware-leaf (IPv6)
As the RPI extension can be ignored by the not-RPL-aware leaf, this As the RPI extension can be ignored by the not-RPL-aware leaf, this
situation is identical to the previous scenario. situation is identical to the previous scenario.
+-------------------+------+-----+------+ +-------------------+------+-----------+----------------+
| Header | 6LBR | 6LR | IPv6 | | Header | 6LBR | 6LR(1..N) | 6LN |
+-------------------+------+-----+------+ +-------------------+------+-----------+----------------+
| Inserted headers | -- | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | -- | | Removed headers | -- | -- | -- |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | -- | -- | | Modified headers | -- | RPI | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | RPI (Ignored) |
+-------------------+------+-----+------+ +-------------------+------+-----------+----------------+
Storing: Summary of the use of headers from root to not-RPL-aware- Storing: Summary of the use of headers from root to not-RPL-aware-
leaf leaf
5.4. Example of Flow from not-RPL-aware-leaf to root 5.4. Example of Flow from not-RPL-aware-leaf to root
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) not-RPL-aware-leaf (IPv6) --> 6LR1,... --> 6LRN --> root (6LBR)
When the packet arrives from IPv6 node to 6LR, the 6LR will insert an When the packet arrives from IPv6 node to 6LR, the 6LR1 will insert
RPI header, encapsuladed in a IPv6-in-IPv6 header. The IPv6-in-IPv6 an RPI header, encapsuladed in a IPv6-in-IPv6 header. The IPv6-in-
header can be addressed to the next hop, or to the root. The root IPv6 header can be addressed to the next hop, or to the root. The
removes the header and processes the packet. root removes the header and processes the packet.
+-------------------+------+----------------+---------------+ +------------+------+---------------+---------------+---------------+
| Header | IPv6 | 6LR | 6LBR | | Header | IPv6 | 6LR1 | 6LRN | 6LBR |
+-------------------+------+----------------+---------------+ +------------+------+---------------+---------------+---------------+
| Inserted headers | -- | IP-in-IP(RPI) | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| Removed headers | -- | -- | IP-in-IP(RPI) | | headers | | | | |
| Re-added headers | -- | -- | -- | | Removed | -- | -- | -- | IP-in-IP(RPI) |
| Modified headers | -- | -- | -- | | headers | | | | |
| Untouched headers | -- | -- | -- | | Re-added | -- | -- | -- | -- |
+-------------------+------+----------------+---------------+ | headers | | | | |
| Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+------------+------+---------------+---------------+---------------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to Storing: Summary of the use of headers from not-RPL-aware-leaf to
root root
5.5. Example of Flow from RPL-aware-leaf to Internet 5.5. Example of Flow from RPL-aware-leaf to Internet
RPL information from RFC 6553 MAY go out to Internet as it will be RPL information from RFC 6553 MAY go out to Internet as it will be
ignored by nodes which have not been configured to be RPI aware. ignored by nodes which have not been configured to be RPI aware.
In this case the flow comprises: In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet RPL-aware-leaf (6LN) --> 6LR1,... --> 6LRN --> root (6LBR) -->
Internet
No IP-in-IP header is required. No IP-in-IP header is required.
+-------------------+------+------+------+----------+ +-------------------+------+-----------+------+----------------+
| Header | 6LN | 6LR | 6LBR | Internet | | Header | 6LN | 6LR(1..N) | 6LBR | Internet |
+-------------------+------+------+------+----------+ +-------------------+------+-----------+------+----------------+
| Inserted headers | RPI | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| Removed headers | -- | -- | -- | -- | | Removed headers | -- | -- | -- | -- |
| Re-added headers | -- | -- | -- | -- | | Re-added headers | -- | -- | -- | -- |
| Modified headers | -- | RPI | -- | -- | | Modified headers | -- | RPI | -- | -- |
| Untouched headers | -- | -- | -- | -- | | Untouched headers | -- | -- | -- | RPI (Ignored) |
+-------------------+------+------+------+----------+ +-------------------+------+-----------+------+----------------+
Storing: Summary of the use of headers from RPL-aware-leaf to Storing: Summary of the use of headers from RPL-aware-leaf to
Internet Internet
5.6. Example of Flow from Internet to RPL-aware-leaf 5.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR --> RPL-aware-leaf (6LN) Internet --> root (6LBR) --> 6LR1,... --> 6LRN --> RPL-aware-leaf
(6LN)
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 and sent to 6LR, which modifies the in a outer IPv6-in-IPv6 header and sent to 6LR, which modifies the
rank in the RPI. When the packet arrives at 6LN the RPI header is rank in the RPI. When the packet arrives at 6LN the RPI header is
removed and the packet processed. removed and the packet processed.
+-----------------+----------+---------------+------+---------------+ +----------+---------+--------------+---------------+---------------+
| Header | Internet | 6LBR | 6LR | 6LN | | Header | Interne | 6LBR | 6LR(1...N) | 6LN |
+-----------------+----------+---------------+------+---------------+ | | t | | | |
| Inserted | -- | IP-in-IP(RPI) | -- | -- | +----------+---------+--------------+---------------+---------------+
| headers | | | | | | Inserted | -- | IP-in- | -- | -- |
| Removed headers | -- | -- | -- | IP-in-IP(RPI) | | headers | | IP(RPI) | | |
| Re-added | -- | -- | -- | -- | | Removed | -- | -- | -- | IP-in-IP(RPI) |
| headers | | | | | | headers | | | | |
| Modified | -- | -- | RPI | -- | | Re-added | -- | -- | -- | -- |
| headers | | | | | | headers | | | | |
| Untouched | -- | -- | -- | -- | | Modified | -- | -- | IP-in-IP(RPI) | -- |
| headers | | | | | | headers | | | | |
+-----------------+----------+---------------+------+---------------+ | Untouche | -- | -- | -- | -- |
| d | | | | |
| headers | | | | |
+----------+---------+--------------+---------------+---------------+
Storing: Summary of the use of headers from Internet to RPL-aware- Storing: Summary of the use of headers from Internet to RPL-aware-
leaf leaf
5.7. Example of Flow from not-RPL-aware-leaf to Internet 5.7. 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 (6LN) --> 6LR --> root (6LBR) --> Internet not-RPL-aware-leaf (IPv6) --> 6LR1,... --> 6LRN --> root (6LBR) -->
Internet
The 6LR node will add an IP-in-IP(RPI) header addressed either to the The 6LR1 node will add an IP-in-IP(RPI) header addressed either to
root, or hop-by-hop such that the root can remove the RPI header the root, or hop-by-hop such that the root can remove the RPI header
before passing upwards. before passing upwards.
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 it can be better compressed through the LLN, and the 6LBR so that it can be better compressed through the LLN, and the 6LBR
will set the flow label to a non-zero value when sending to the will set the flow label to a non-zero value when sending to the
Internet. Internet.
+-----------------+------+---------------+---------------+----------+ +---------+-----+-------------+-------------+-------------+---------+
| Header | 6LN | 6LR | 6LBR | Internet | | Header | IPv | 6LR1 | 6LBN | 6LBR | Interne |
+-----------------+------+---------------+---------------+----------+ | | 6 | | | | t |
| Inserted | -- | IP-in-IP(RPI) | -- | -- | +---------+-----+-------------+-------------+-------------+---------+
| headers | | | | | | Inserte | -- | IP-in- | -- | -- | -- |
| Removed headers | -- | -- | IP-in-IP(RPI) | -- | | d | | IP(RPI) | | | |
| Re-added | -- | -- | -- | -- | | headers | | | | | |
| headers | | | | | | Removed | -- | -- | -- | IP-in- | -- |
| Modified | -- | -- | -- | -- | | headers | | | | IP(RPI) | |
| headers | | | | | | Re- | -- | -- | -- | -- | -- |
| Untouched | -- | -- | -- | -- | | added | | | | | |
| headers | | | | | | headers | | | | | |
+-----------------+------+---------------+---------------+----------+ | Modifie | -- | -- | IP-in- | -- | -- |
| d | | | IP(RPI) | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+-------------+-------------+-------------+---------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to Storing: Summary of the use of headers from not-RPL-aware-leaf to
Internet Internet
5.8. Example of Flow from Internet to non-RPL-aware-leaf 5.8. Example of Flow from Internet to non-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR --> not-RPL-aware-leaf (6LN) Internet --> root (6LBR) --> 6LR1,... --> 6LRN --> not-RPL-aware-leaf
(IPv6)
The 6LBR will have to add an RPI header within an IP-in-IP header. The 6LBR will have to add an RPI header within an IP-in-IP header.
The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
RPI inside. RPI inside.
The 6LBR MAY set the flow label on the inner IP-in-IP header to zero The 6LBR MAY set the flow label on the inner IP-in-IP header to zero
in order to aid in compression, as the packet will not emerge again in order to aid in compression, as the packet will not emerge again
from the LLN. from the LLN.
+-----------------+----------+---------------+---------------+------+ +-----------+----------+---------------+---------------+------------+
| Header | Internet | 6LBR | 6LR | IPv6 | | Header | Internet | 6LBR | 6LR(1...N) | IPv6 |
+-----------------+----------+---------------+---------------+------+ +-----------+----------+---------------+---------------+------------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
| Removed headers | -- | -- | IP-in-IP(RPI) | -- | | Removed | -- | -- | IP-in-IP(RPI) | -- |
| Re-added | -- | -- | -- | -- | | headers | | | | |
| headers | | | | | | Re-added | -- | -- | -- | -- |
| Modified | -- | -- | -- | -- | | headers | | | | |
| headers | | | | | | Modified | -- | -- | IP-in-IP(RPI) | -- |
| Untouched | -- | -- | -- | -- | | headers | | | | |
| headers | | | | | | Untouched | -- | -- | -- | RPI |
+-----------------+----------+---------------+---------------+------+ | headers | | | | (Ignored) |
+-----------+----------+---------------+---------------+------------+
Storing: Summary of the use of headers from Internet to non-RPL- Storing: Summary of the use of headers from Internet to non-RPL-
aware-leaf aware-leaf
5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf 5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
In [RFC6550] RPL allows a simple one-hop optimization for both In [RFC6550] RPL allows a simple one-hop optimization for both
storing and non-storing networks. A node may send a packet destined storing and non-storing networks. A node may send a packet destined
to a one-hop neighbor directly to that node. Section 9 in [RFC6550]. to a one-hop neighbor directly to that node. Section 9 in [RFC6550].
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN 6LN --> 6LR1 --> common parent (6LRx) --> 6LRN --> 6LN
This case is assumed in the same RPL Domain. In the common parent, This case is assumed in the same RPL Domain. In the common parent,
the direction of RPI is changed (from increasing to decreasing the the direction of RPI is changed (from increasing to decreasing the
rank). rank).
While the 6LR nodes will update the RPI, no node needs to add or While the 6LR nodes will update the RPI, no node needs to add or
remove the RPI, so no IP-in-IP headers are necessary. This may be remove the RPI, so no IP-in-IP headers are necessary. This may be
done regardless of where the destination is, as the included RPI will done regardless of where the destination is, as the included RPI will
be ignored by the receiver. be ignored by the receiver.
+-------------+-------+---------------+---------------+-----+-------+ +------------+-------+---------------+---------------+------+-------+
| Header | 6LN | 6LR | 6LR (common | 6LR | 6LN | | Header | 6LN | 6LR1 | 6LRx (common | 6LRN | 6LN |
| | src | | parent) | | dst | | | src | | parent) | | dst |
+-------------+-------+---------------+---------------+-----+-------+ +------------+-------+---------------+---------------+------+-------+
| Inserted | RPI | -- | -- | -- | -- | | Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Removed | -- | -- | -- | -- | RPI | | Removed | -- | -- | -- | -- | RPI |
| headers | | | | | | | headers | | | | | |
| Re-added | -- | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Modified | -- | RPI | RPI | -- | -- | | Modified | -- | RPI | RPI | -- | -- |
| headers | | (decreasing | (increasing | | | | headers | | (decreasing | (increasing | | |
| | | rank) | rank) | | | | | | rank) | rank) | | |
| Untouched | -- | -- | -- | -- | -- | | Untouched | -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+-------------+-------+---------------+---------------+-----+-------+ +------------+-------+---------------+---------------+------+-------+
Storing: Summary of the use of headers for RPL-aware-leaf to RPL- Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf aware-leaf
5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR --> common parent (6LR) --> 6LR --> not-RPL-aware 6LN 6LN --> 6LR1 --> common parent (6LRx) --> 6LRN --> not-RPL-aware 6LN
(IPv6)
This situation is identical to the situation Section 5.9 This situation is identical to the previous situation Section 5.9
+-----------+-----+-------------+-------------+------+--------------+
| Header | 6LN | 6LR1 | 6LRx | 6LRN | IPv6 |
| | src | | (common | | |
| | | | parent) | | |
+-----------+-----+-------------+-------------+------+--------------+
| Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | |
| Removed | -- | -- | -- | -- | RPI |
| headers | | | | | |
| Re-added | -- | -- | -- | -- | -- |
| headers | | | | | |
| Modified | -- | RPI | RPI | -- | -- |
| headers | | (decreasing | (increasing | | |
| | | rank) | rank) | | |
| Untouched | -- | -- | -- | -- | RPI(Ignored) |
| headers | | | | | |
+-----------+-----+-------------+-------------+------+--------------+
Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf
5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN not-RPL-aware 6LN (IPv6) --> 6LR1 --> common parent (6LRx) --> 6LRN
--> 6LN
The 6LR receives the packet from the the IPv6 node and inserts and The 6LR1 receives the packet from the the IPv6 node and inserts and
the RPI header encapsulated in IPv6-in-IPv6 header. The IP-in-IP the RPI header encapsulated in IPv6-in-IPv6 header. The IP-in-IP
header is addressed to the destinion 6LN. header is addressed to the destination 6LN.
+--------+------+------------+------------+------------+------------+ +--------+------+------------+------------+------------+------------+
| Header | IPv6 | 6LR | common | 6LR | 6LN | | Header | IPv6 | 6LR1 | common | 6LRn | 6LN |
| | | | parent | | | | | | | parent | | |
| | | | (6LR) | | | | | | | (6LRx) | | |
+--------+------+------------+------------+------------+------------+ +--------+------+------------+------------+------------+------------+
| Insert | -- | IP-in- | -- | -- | -- | | Insert | -- | IP-in- | -- | -- | -- |
| ed hea | | IP(RPI) | | | | | ed hea | | IP(RPI) | | | |
| ders | | | | | | | ders | | | | | |
| Remove | -- | -- | -- | -- | IP-in- | | Remove | -- | -- | -- | -- | IP-in- |
| d head | | | | | IP(RPI) | | d head | | | | | IP(RPI) |
| ers | | | | | | | ers | | | | | |
| Re- | -- | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| added | | | | | | | added | | | | | |
| header | | | | | | | header | | | | | |
skipping to change at page 16, line 35 skipping to change at page 18, line 35
| aders | | | | | | | aders | | | | | |
+--------+------+------------+------------+------------+------------+ +--------+------+------------+------------+------------+------------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to Storing: Summary of the use of headers from not-RPL-aware-leaf to
RPL-aware-leaf RPL-aware-leaf
5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf 5.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN (IPv6 node)--> 6LR --> root (6LBR) --> 6LR --> not- not-RPL-aware 6LN (IPv6 src)--> 6LR1 --> 6LR2 --> root (6LBR) -->
RPL-aware 6LN (IPv6 node) 6LRn --> not-RPL-aware 6LN (IPv6 dst)
This flow is identical to Section 5.11 This flow is identical to Section 5.11
The 6LR receives the packet from the the IPv6 node and inserts the
RPI header (RPIa) encapsulated in IPv6-in-IPv6 header. The IPv6-in-
IPv6 header is addressed to the 6LBR. The 6LBR remove the IPv6-in-
IPv6 header and insert another one (RPIb) with destination to 6LRn
node.
+-------+-----+-----------+-----------+-----------+-----------+-----+
| Heade | IPv | 6LR1 | 6LR2 | 6LBR | 6LRn | IPv |
| r | 6 | | | | | 6 |
| | src | | | | | dst |
+-------+-----+-----------+-----------+-----------+-----------+-----+
| Inser | -- | IP-in- | -- | IP-in- | -- | -- |
| ted h | | IP(RPIa) | | IP(RPIb) | | |
| eader | | | | | | |
| s | | | | | | |
| Remov | -- | -- | -- | -- | -- | -- |
| ed he | | | | | | |
| aders | | | | | | |
| Re- | -- | -- | -- | -- | IP-in- | -- |
| added | | | | | IP(RPIb) | |
| heade | | | | | | |
| rs | | | | | | |
| Modif | -- | -- | IP-in- | -- | IP-in- | -- |
| ied h | | | IP(RPIa) | | IP(RPIb) | |
| eader | | | | | | |
| s | | | | | | |
| Untou | -- | -- | -- | -- | -- | -- |
| ched | | | | | | |
| heade | | | | | | |
| rs | | | | | | |
+-------+-----+-----------+-----------+-----------+-----------+-----+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
non-RPL-aware-leaf
6. Non Storing mode 6. Non Storing mode
+--------------+------+------+-----------+---------------+ +--------------+------+------+-----------+---------------+
| Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst | | Use Case | RPI | RH3 | IP-in-IP | IP-in-IP dst |
+--------------+------+------+-----------+---------------+ +--------------+------+------+-----------+---------------+
| Raf to root | Yes | No | No | -- | | Raf to root | Yes | No | No | -- |
| root to Raf | Yes | Yes | No | -- | | root to Raf | Opt | Yes | No | -- |
| root to ~Raf | No | Yes | Yes | 6LR | | root to ~Raf | No | Yes | Yes | 6LR |
| ~Raf to root | Yes | No | Yes | root | | ~Raf to root | Yes | No | Yes | root |
| Raf to Int | Yes | No | Yes | root | | Raf to Int | Yes | No | Yes | root |
| Int to Raf | opt | Yes | Yes | dst | | Int to Raf | Opt | Yes | Yes | dst |
| ~Raf to Int | Yes | No | Yes | root | | ~Raf to Int | Yes | No | Yes | root |
| Int to ~Raf | opt | Yes | Yes | 6LR | | Int to ~Raf | Opt | Yes | Yes | 6LR |
| 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 |
| ~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 |
+--------------+------+------+-----------+---------------+ +--------------+------+------+-----------+---------------+
Table 2: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP Table 2: Headers needed in Non-Storing mode: RPI, RH3, IP-in-IP
encapsulation encapsulation
6.1. Example of Flow from RPL-aware-leaf to root 6.1. Example of Flow from RPL-aware-leaf to root
skipping to change at page 17, line 39 skipping to change at page 20, line 39
RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) RPL-aware-leaf (6LN) --> 6LR --> root (6LBR)
This situation is the same case as storing mode. This situation is the same case as storing mode.
+-------------------+-----+------+------+ +-------------------+-----+------+------+
| Header | 6LN | 6LR | 6LBR | | Header | 6LN | 6LR | 6LBR |
+-------------------+-----+------+------+ +-------------------+-----+------+------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
| Removed headers | -- | -- | RPI | | Removed headers | -- | -- | RPI |
| Re-added headers | -- | RPI | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | -- | -- | | 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
6.2. Example of Flow from root to RPL-aware-leaf 6.2. Example of Flow from root to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
root (6LBR)--> 6LR --> RPL-aware-leaf (6LN) root (6LBR)--> 6LR --> RPL-aware-leaf (6LN)
The 6LBR will insert an RH3, and may optionally insert an RPI header. The 6LBR will insert an RH3, and may optionally insert an RPI header.
No IP-in-IP header is necessary as the traffic originates with an RPL No IP-in-IP header is necessary as the traffic originates with an RPL
aware node, the 6LBR. The destination is known to 6LBR because, the aware node, the 6LBR. The destination is known to RPL-aware because,
root knows the whole topology in non-storing mode. the root knows the whole topology in non-storing mode.
+-------------------+-----------------+------+----------+ +-------------------+-----------------+------+----------+
| Header | 6LBR | 6LR | 6LN | | Header | 6LBR | 6LR | 6LN |
+-------------------+-----------------+------+----------+ +-------------------+-----------------+------+----------+
| Inserted headers | (opt: RPI), RH3 | -- | -- | | Inserted headers | (opt: RPI), RH3 | -- | -- |
| Removed headers | -- | -- | RH3,RPI | | Removed headers | -- | -- | RH3,RPI |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | RH3 | -- | | Modified headers | -- | RH3 | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+-----------------+------+----------+ +-------------------+-----------------+------+----------+
Non Storing: Summary of the use of headers from root to RPL-aware- Non Storing: Summary of the use of headers from root to RPL-aware-
leaf leaf
6.3. Example of Flow from root to not-RPL-aware-leaf 6.3. Example of Flow from root to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
root (6LBR)--> 6LR --> not-RPL-aware-leaf (IPv6 node) root (6LBR)--> 6LR1...-->6LRn --> not-RPL-aware-leaf (IPv6)
In 6LBR the RH3 is added, modified in each intermediate 6LR and it is
fully consumed in the last 6LR, but left there. If the RPI is left
present, the IPv6 node which does not understand it will drop it,
therefore the RPI should be removed before reaching the IPv6-only
node. To permit removal, an IP-in-IP header (hop-by-hop) or
addressed to the last 6LR is necessary. Due the complete knowledge
of the topology at the root, the 6LBR is able to address the IP-in-IP
header to the last 6LR.
Omitting the RPI entirely is therefore a better solution, as no IP- In 6LBR the RH3 is added, modified in each intermediate 6LR (6LR1 and
in-IP header is necessary. so on) and it is fully consumed in the last 6LR (6LRn), but left
there. If RPI is left present, the IPv6 node which does not
understand it will ignore it (following 2460bis), thus encapsulation
is not necesary. Due the complete knowledge of the topology at the
root, the 6LBR is able to address the IP-in-IP header to the last
6LR.
+-------------------+------+-----+------+ +----------------+--------------+--------------+-------------+------+
| Header | 6LBR | 6LR | IPv6 | | Header | 6LBR | 6LR1 | 6LRn | IPv6 |
+-------------------+------+-----+------+ +----------------+--------------+--------------+-------------+------+
| Inserted headers | RH3 | -- | -- | | Inserted | (opt: RPI), | -- | -- | -- |
| Removed headers | -- | -- | -- | | headers | RH3 | | | |
| Re-added headers | -- | -- | -- | | Removed | -- | RH3 | -- | -- |
| Modified headers | -- | RH3 | -- | | headers | | | | |
| Untouched headers | -- | -- | -- | | Re-added | -- | -- | -- | -- |
+-------------------+------+-----+------+ | headers | | | | |
| Modified | -- | (opt: RPI), | (opt: RPI), | -- |
| headers | | RH3 | RH3 | |
| Untouched | -- | -- | -- | RPI |
| headers | | | | |
+----------------+--------------+--------------+-------------+------+
Non Storing: Summary of the use of headers from root to not-RPL- Non Storing: Summary of the use of headers from root to not-RPL-
aware-leaf aware-leaf
6.4. Example of Flow from not-RPL-aware-leaf to root 6.4. Example of Flow from not-RPL-aware-leaf to root
In this case the flow comprises: In this case the flow comprises:
IPv6-node --> 6LR1 --> 6LR2 --> root (6LBR) IPv6-node --> 6LR1 ...--> 6LRn --> root (6LBR)
In this case the RPI is added by the first 6LR, encapsulated in an In this case the RPI is added by the first 6LR (6LR1), encapsulated
IP-in-IP header, and is not modified in the followings 6LRs. The RPI in an IP-in-IP header, and is modified in the followings 6LRs. The
and entire packet is consumed by the root. RPI and entire packet is consumed by the root.
+-------------------+------+----------------+------+----------------+ +------------+------+---------------+---------------+---------------+
| Header | IPv6 | 6LR1 | 6LR2 | 6LBR | | Header | IPv6 | 6LR1 | 6LR2 | 6LBR |
+-------------------+------+----------------+------+----------------+ +------------+------+---------------+---------------+---------------+
| Inserted headers | -- | IP-in-IP(RPI) | -- | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| Removed headers | -- | -- | -- | IP-in-IP(RPI) | | headers | | | | |
| Re-added headers | -- | -- | -- | -- | | Removed | -- | -- | -- | IP-in-IP(RPI) |
| Modified headers | -- | -- | -- | -- | | headers | | | | |
| Untouched headers | -- | IP-in-IP(RPI) | -- | -- | | Re-added | -- | -- | -- | -- |
+-------------------+------+----------------+------+----------------+ | headers | | | | |
| Modified | -- | IP-in-IP(RPI) | IP-in-IP(RPI) | -- |
| headers | | | | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+------------+------+---------------+---------------+---------------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
root root
6.5. Example of Flow from RPL-aware-leaf to Internet 6.5. Example of Flow from RPL-aware-leaf to Internet
In this case the flow comprises: In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet RPL-aware-leaf (6LN) --> 6LR1 ...--> 6LRn --> root (6LBR) -->
Internet
This case requires that the RPI be added, but removed by the 6LBR. This case is identical to storing-mode case.
The 6LN must therefore add the RPI inside an IP-in-IP header,
addressed to the root. This case is identical to storing-mode case.
The IPv6 flow label should be set to zero to aid in compression, and The IPv6 flow label should be set to zero to aid in compression, and
the 6LBR will set it to a non-zero value when sending towards the the 6LBR will set it to a non-zero value when sending towards the
Internet. Internet.
+-----------------+---------------+------+---------------+----------+ +-------------------+------+-----------+------+----------------+
| Header | 6LN | 6LR | 6LBR | Internet | | Header | 6LN | 6LR(1..N) | 6LBR | Internet |
+-----------------+---------------+------+---------------+----------+ +-------------------+------+-----------+------+----------------+
| Inserted | IP-in-IP(RPI) | -- | -- | -- | | Inserted headers | RPI | -- | -- | -- |
| headers | | | | | | Removed headers | -- | -- | -- | -- |
| Removed headers | -- | -- | IP-in-IP(RPI) | -- | | Re-added headers | -- | -- | -- | -- |
| Re-added | -- | -- | -- | -- | | Modified headers | -- | RPI | -- | -- |
| headers | | | | | | Untouched headers | -- | -- | -- | RPI (Ignored) |
| Modified | -- | -- | -- | -- | +-------------------+------+-----------+------+----------------+
| headers | | | | |
| Untouched | -- | RPI | -- | -- |
| 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
Internet Internet
6.6. Example of Flow from Internet to RPL-aware-leaf 6.6. Example of Flow from Internet to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR --> RPL-aware-leaf (6LN) Internet --> root (6LBR) --> 6LR1...--> 6LRn --> RPL-aware-leaf (6LN)
The 6LBR must add an RH3 header. As the 6LBR will know the path and The 6LBR must add an RH3 header. As the 6LBR will know the path and
address of the target not, it can address the IP-in-IP header to that address of the target node, it can address the IP-in-IP header to
node. The 6LBR will zero the flow label upon entry in order to aid that node. The 6LBR will zero the flow label upon entry in order to
compression. aid compression.
The RPI may be added or not. The RPI may be added or not, it is optional.
+----------+----------+-----------------------+---------------+-----+ +--------+-------+----------------+----------------+----------------+
| Header | Internet | 6LBR | 6LR | 6LN | | Header | Inter | 6LBR | 6LR | 6LN |
+----------+----------+-----------------------+---------------+-----+ | | net | | | |
| Inserted | -- | IP-in-IP(RH3,opt:RPI) | -- | -- | +--------+-------+----------------+----------------+----------------+
| headers | | | | | | Insert | -- | IP-in-IP(RH3,o | -- | -- |
| Removed | -- | -- | IP-in-IP(RH3) | -- | | ed hea | | pt:RPI) | | |
| headers | | | | | | ders | | | | |
| Re-added | -- | -- | -- | -- | | Remove | -- | -- | -- | IP-in-IP(RH3,o |
| headers | | | | | | d head | | | | pt:RPI) |
| Modified | -- | -- | IP-in-IP(RH3) | -- | | ers | | | | |
| headers | | | | | | Re- | -- | -- | -- | -- |
| Untouche | -- | -- | -- | -- | | added | | | | |
| d | | | | | | header | | | | |
| headers | | | | | | s | | | | |
+----------+----------+-----------------------+---------------+-----+ | Modifi | -- | -- | IP-in-IP(RH3,o | -- |
| ed hea | | | pt:RPI) | |
| ders | | | | |
| Untouc | -- | -- | -- | -- |
| hed he | | | | |
| aders | | | | |
+--------+-------+----------------+----------------+----------------+
Non Storing: Summary of the use of headers from Internet to RPL- Non Storing: Summary of the use of headers from Internet to RPL-
aware-leaf aware-leaf
6.7. Example of Flow from not-RPL-aware-leaf to Internet 6.7. 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 (6LN) --> 6LR --> root (6LBR) --> Internet not-RPL-aware-leaf (IPv6) --> 6LR1..--> 6LRn --> root (6LBR) -->
Internet
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, the first 6LN will node. As RPL headers are added in the IPv6 node, the first 6LN will
add an RPI header inside a new IP-in-IP header. The IP-in-IP header add an RPI header inside a new IP-in-IP header. The IP-in-IP header
will be addressed to the root. This case is identical to the will be addressed to the root. This case is identical to the
storing-mode case (Section 5.7). storing-mode case (Section 5.7).
+-----------------+------+---------------+---------------+----------+ +---------+-----+-------------+-------------+-------------+---------+
| Header | IPv6 | 6LR | 6LBR | Internet | | Header | IPv | 6LR1 | 6LRn | 6LBR | Interne |
+-----------------+------+---------------+---------------+----------+ | | 6 | | | | t |
| Inserted | -- | IP-in-IP(RPI) | -- | -- | +---------+-----+-------------+-------------+-------------+---------+
| headers | | | | | | Inserte | -- | IP-in- | -- | -- | -- |
| Removed headers | -- | -- | IP-in-IP(RPI) | -- | | d | | IP(RPI) | | | |
| Re-added | -- | -- | -- | -- | | headers | | | | | |
| headers | | | | | | Removed | -- | -- | -- | IP-in- | -- |
| Modified | -- | -- | -- | -- | | headers | | | | IP(RPI) | |
| headers | | | | | | Re- | -- | -- | -- | -- | -- |
| Untouched | -- | -- | -- | -- | | added | | | | | |
| headers | | | | | | headers | | | | | |
+-----------------+------+---------------+---------------+----------+ | Modifie | -- | -- | IP-in- | -- | -- |
| d | | | IP(RPI) | | |
| headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+-------------+-------------+-------------+---------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
Internet Internet
6.8. Example of Flow from Internet to non-RPL-aware-leaf 6.8. Example of Flow from Internet to non-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
Internet --> root (6LBR) --> 6LR --> not-RPL-aware-leaf (IPv6 node) Internet --> root (6LBR) --> 6LR1...--> 6LRn --> not-RPL-aware-leaf
(IPv6)
The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR The 6LBR must add an RH3 header inside an IP-in-IP header. The 6LBR
will know the path, and will recognize that the final node is not an 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 from RPL capable node as it will have received the connectivity DAO from
the nearest 6LR. The 6LBR can therefore make the IP-in-IP header the nearest 6LR. The 6LBR can therefore make the IP-in-IP header
destination be the last 6LR. The 6LBR will set to zero the flow destination be the last 6LR. The 6LBR will set to zero the flow
label upon entry in order to aid compression. label upon entry in order to aid compression.
+----------+---------+-----------------------+---------------+------+ +--------+-------+-----------------+------------+------------+------+
| Header | Interne | 6LBR | 6LR | IPv6 | | Header | Inter | 6LBR | 6LR1 | 6LRn | IPv6 |
| | t | | | | | | net | | | | |
+----------+---------+-----------------------+---------------+------+ +--------+-------+-----------------+------------+------------+------+
| Inserted | -- | IP-in-IP(RH3,opt:RPI) | -- | -- | | Insert | -- | IP-in- | -- | -- | -- |
| headers | | | | | | ed hea | | IP(RH3,opt:RPI) | | | |
| Removed | -- | -- | IP-in-IP(RH3, | -- | | ders | | | | | |
| headers | | | RPI) | | | Remove | -- | -- | -- | IP-in- | -- |
| Re-added | -- | -- | -- | -- | | d head | | | | IP(RH3, | |
| headers | | | | | | ers | | | | RPI) | |
| Modified | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| headers | | | | | | added | | | | | |
| Untouche | -- | -- | -- | -- | | header | | | | | |
| d | | | | | | s | | | | | |
| headers | | | | | | Modifi | -- | -- | IP-in- | IP-in- | -- |
+----------+---------+-----------------------+---------------+------+ | ed hea | | | IP(RH3, | IP(RH3, | |
| ders | | | RPI) | RPI) | |
| Untouc | -- | -- | -- | -- | RPI |
| hed he | | | | | |
| aders | | | | | |
+--------+-------+-----------------+------------+------------+------+
NonStoring: Summary of the use of headers from Internet to non-RPL- NonStoring: Summary of the use of headers from Internet to non-RPL-
aware-leaf aware-leaf
6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf 6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR --> root (6LBR) --> 6LR --> 6LN 6LN --> 6LR1 --> root (6LBR) --> 6LRN --> 6LN
This case involves only nodes in same RPL Domain. The originating This case involves only nodes in same RPL Domain. The originating
node will add an RPI header to the original packet, and send the node will add an RPI header to the original packet, and send the
packet upwards. packet upwards.
The originating node could put the RPI into an IP-in-IP header The originating node SHOULD put the RPI into an IP-in-IP header
addressed to the root, so that the 6LBR can remove that header. addressed to the root, so that the 6LBR can remove that header. If
it does not, then additional resources are wasted on the way down to
carry the useless RPI option.
The 6LBR will need to insert an RH3 header, which requires that it The 6LBR will need to insert an RH3 header, which requires that it
add an IP-in-IP header. It may be able to remove the RPI if it was add an IP-in-IP header. It SHOULD be able to remove the RPI, as it
contained in an IP-in-IP header addressed to it. Otherwise, there was contained in an IP-in-IP header addressed to it. Otherwise,
may be an RPI header buried inside the inner IP header, which should there MAY be an RPI header buried inside the inner IP header, which
get ignored. 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. non-storing DODAGs and fall into this scenario or scenario
Section 6.2, with the originating node acting as 6LBR.
+----------+---------------+--------------+-----+-------------------+ +---------+-------------+------+--------------+------+--------------+
| Header | 6LN src | 6LBR | 6LR | 6LN dst | | Header | 6LN src | 6LR1 | 6LBR | 6LRN | 6LN dst |
+----------+---------------+--------------+-----+-------------------+ +---------+-------------+------+--------------+------+--------------+
| Inserted | IP-in-IP(RPI) | IP-in-IP(RH3 | -- | -- | | Inserte | IP-in- | -- | IP-in-IP(RH3 | -- | -- |
| headers | | to 6LN,RPI) | | | | d | IP(RPI1) | | to 6LN, opt | | |
| Removed | -- | -- | -- | IP-in-IP(RH3,RPI) | | headers | | | RPI2) | | |
| headers | | | | | | Removed | -- | -- | IP-in- | -- | IP-in- |
| Re-added | -- | -- | -- | -- | | headers | | | IP(RPI1) | | IP(RH3, opt |
| headers | | | | | | | | | | | RPI2) |
| Modified | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| headers | | | | | | added | | | | | |
| Untouche | -- | -- | -- | -- | | headers | | | | | |
| d | | | | | | Modifie | -- | -- | -- | -- | -- |
| headers | | | | | | d | | | | | |
+----------+---------------+--------------+-----+-------------------+ | headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-------------+------+--------------+------+--------------+
Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL- Non Storing: Summary of the use of headers for RPL-aware-leaf to RPL-
aware-leaf aware-leaf
6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR --> root (6LBR) --> 6LR --> not-RPL-aware (IPv6 node) 6LN --> 6LR1 --> root (6LBR) --> 6LRn --> not-RPL-aware (IPv6)
As in the previous case, the 6LN will insert an RPI header which MUST As in the previous case, the 6LN will insert an RPI (RPI1) header
be in an IP-in-IP header addressed to the root so that the 6LBR can which MUST be in an IP-in-IP header addressed to the root so that the
remove this RPI. The 6LBR will then insert an RH3 inside a new IP- 6LBR can remove this RPI. The 6LBR will then insert an RH3 inside a
in-IP header addressed to the 6LN above the destination node. new IP-in-IP header addressed to the 6LN destination node. The RPI
is optional from 6LBR to 6LRn (RPI2).
+-----------+---------------+---------------+----------------+------+ +--------+------------+------------+------------+------------+------+
| Header | 6LN | 6LBR | 6LR | IPv6 | | Header | 6LN | 6LR1 | 6LBR | 6LRn | IPv6 |
+-----------+---------------+---------------+----------------+------+ +--------+------------+------------+------------+------------+------+
| Inserted | IP-in-IP(RPI) | IP-in-IP(RH3, | -- | -- | | Insert | IP-in- | -- | IP-in- | -- | -- |
| headers | | opt RPI) | | | | ed hea | IP(RPI1) | | IP(RH3, | | |
| Removed | -- | IP-in-IP(RPI) | IP-in-IP(RH3, | -- | | ders | | | opt RPI2) | | |
| headers | | | opt RPI) | | | Remove | -- | -- | IP-in- | IP-in- | -- |
| Re-added | -- | -- | -- | -- | | d head | | | IP(RPI1) | IP(RH3, | |
| headers | | | | | | ers | | | | opt RPI2) | |
| Modified | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| headers | | | | | | added | | | | | |
| Untouched | -- | -- | -- | -- | | header | | | | | |
| headers | | | | | | s | | | | | |
+-----------+---------------+---------------+----------------+------+ | Modifi | -- | IP-in- | -- | IP-in- | -- |
| ed hea | | IP(RPI1) | | IP(RH3, | |
| ders | | | | opt RPI2) | |
| Untouc | -- | -- | -- | -- | opt |
| hed he | | | | | RPI2 |
| aders | | | | | |
+--------+------------+------------+------------+------------+------+
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
not-RPL-aware-leaf not-RPL-aware-leaf
6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN --> 6LR --> root (6LBR) --> 6LR --> 6LN not-RPL-aware 6LN (IPv6) --> 6LR1 --> root (6LBR) --> 6LRn --> 6LN
This scenario is mostly identical to the previous one. The RPI is This scenario is mostly identical to the previous one. The RPI is
added by the first 6LR inside an IP-in-IP header addressed to the added by the first 6LR (6LR1) inside an IP-in-IP header addressed to
root. The 6LBR will remove this RPI, and add it's own IP-in-IP the root. The 6LBR will remove this RPI, and add it's own IP-in-IP
header containing an RH3 header. header containing an RH3 header and optional RPI (RPI2).
+------------+------+---------------+---------------+---------------+ +--------+-----+------------+-------------+------------+------------+
| Header | IPv6 | 6LR | 6LBR | 6LN | | Header | IPv | 6LR1 | 6LBR | 6LRn | 6LN |
+------------+------+---------------+---------------+---------------+ | | 6 | | | | |
| Inserted | -- | IP-in-IP(RPI) | IP-in-IP(RH3) | -- | +--------+-----+------------+-------------+------------+------------+
| headers | | | | | | Insert | -- | IP-in- | IP-in- | -- | -- |
| Removed | -- | IP-in-IP(RPI) | -- | IP-in-IP(RH3) | | ed hea | | IP(RPI1) | IP(RH3, opt | | |
| headers | | | | | | ders | | | RPI2) | | |
| Re-added | -- | -- | -- | -- | | Remove | -- | -- | IP-in- | -- | IP-in- |
| headers | | | | | | d head | | | IP(RPI1) | | IP(RH3, |
| Modified | -- | -- | -- | -- | | ers | | | | | opt RPI2) |
| headers | | | | | | Re- | -- | -- | -- | -- | -- |
| Untouched | -- | -- | -- | -- | | added | | | | | |
| headers | | | | | | header | | | | | |
+------------+------+---------------+---------------+---------------+ | s | | | | | |
| Modifi | -- | -- | -- | IP-in- | -- |
| ed hea | | | | IP(RH3, | |
| ders | | | | opt RPI2) | |
| Untouc | -- | -- | -- | -- | -- |
| hed he | | | | | |
| aders | | | | | |
+--------+-----+------------+-------------+------------+------------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
RPL-aware-leaf RPL-aware-leaf
6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf 6.12. Example of Flow from not-RPL-aware-leaf to not-RPL-aware-leaf
In this case the flow comprises: In this case the flow comprises:
not-RPL-aware 6LN --> 6LR --> root (6LBR) --> 6LR --> not-RPL-aware not-RPL-aware 6LN (IPv6 src)--> 6LR1 --> root (6LBR) --> 6LRn -->
(IPv6 node) not-RPL-aware (IPv6 dst)
This scenario is the combination of the previous two cases. This scenario is the combination of the previous two cases.
+----------+-----+-------------+--------------+--------------+------+ +---------+-----+--------------+--------------+--------------+------+
| Header | IPv | 6LR | 6LBR | 6LR | IPv6 | | Header | IPv | 6LR1 | 6LBR | 6LRn | IPv6 |
| | 6 | | | | | | | 6 | | | | dst |
+----------+-----+-------------+--------------+--------------+------+ | | src | | | | |
| Inserted | -- | IP-in- | IP-in- | -- | -- | +---------+-----+--------------+--------------+--------------+------+
| headers | | IP(RPI) | IP(RH3) | | | | Inserte | -- | IP-in- | IP-in- | -- | -- |
| Removed | -- | -- | IP-in- | IP-in- | -- | | d | | IP(RPI1) | IP(RH3) | | |
| headers | | | IP(RPI) | IP(RH3, opt | | | headers | | | | | |
| | | | | RPI) | | | Removed | -- | -- | IP-in- | IP-in- | -- |
| Re-added | -- | -- | -- | -- | -- | | headers | | | IP(RPI1) | IP(RH3, opt | |
| headers | | | | | | | | | | | RPI2) | |
| Modified | -- | -- | -- | -- | -- | | Re- | -- | -- | -- | -- | -- |
| headers | | | | | | | added | | | | | |
| Untouche | -- | -- | -- | -- | -- | | headers | | | | | |
| d | | | | | | | Modifie | -- | -- | -- | -- | -- |
| headers | | | | | | | d | | | | | |
+----------+-----+-------------+--------------+--------------+------+ | headers | | | | | |
| Untouch | -- | -- | -- | -- | -- |
| ed | | | | | |
| headers | | | | | |
+---------+-----+--------------+--------------+--------------+------+
Non Storing: Summary of the use of headers from not-RPL-aware-leaf to Non Storing: Summary of the use of headers from not-RPL-aware-leaf to
not-RPL-aware-leaf not-RPL-aware-leaf
7. Observations about the problem 7. Observations about the cases
7.1. Storing mode 7.1. Storing mode
In the completely general storing case, which includes not-RPL aware [I-D.ietf-roll-routing-dispatch] shows that this hop-by-hop IP-in-IP
leaf nodes, it is not possible for a sending node to know if the header can be compressed down to {TBD} bytes.
destination is RPL aware, and therefore it must always use hop-by-hop
IP-in-IP encapsulation, and it can never omit the IP-in-IP
encapsulation. See table Table 1
The simplest fully general approach for storing mode is to always put
in hop-by-hop IP-in-IP headers. [I-D.ietf-roll-routing-dispatch]
shows that this hop-by-hop IP-in-IP header can be compressed down to
{TBD} bytes.
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.
If all RPL aware nodes can be told/configured that there are no non- Thanks to the relaxation of the RFC2406 rule about discarding unknown
RPL aware leaf nodes, then the only case where an IP-in-IP header is Hop-by-Hop options, there is no longer any uncertainty about when to
needed is when communicating outside the LLN. The 6LBR knows well use an IPIP header in the storing mode case. The RPI header SHOULD
when the communication is from the outside, and the 6LN can tell by always be added when 6LRs originate packets (without IPIP headers),
comparing the destination address to the prefix provided in the PIO. and IPIP headers should always be added (addressed to the root when
If it is known that there are no communications outside the RPL on the way up, to the end-host when on the way down) when a 6LR finds
domain (noting that the RPL domain may well extend to outside the it needs to insert an RPI header. (XXX - this is a problem for
LLN), then RPI headers can be included in all packets, and IP-in-IP storing mode optimization)
headers are *never* needed. This may be significantly advantageous
in relatively closed systems such as in building or industrial
automation. Again, there are advantages to having a single code
path.
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.
7.2. Non-Storing mode 7.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
root node. root node.
The 6LBR can recognize non-RPL aware leaf nodes because it will The 6LBR can recognize non-RPL aware leaf nodes because it will
receive a DAO about that node from the 6LN immediately above that receive a DAO about that node from the 6LN immediately above that
node. This means that the non-storing mode case can avoid ever using node. This means that the non-storing mode case can avoid ever using
hop-by-hop IP-in-IP headers. hop-by-hop IP-in-IP headers.
It is unclear what it would mean for an RH3 header to be present in a
hop-by-hop IP-in-IP header. The receiving node ought to consume the
IP-in-IP header, and therefore consume the RH3 as well, and then
attempt to send the packet again. But intermediate 6LN nodes would
not know how to forward the packet (because they do not save the
sate), so the RH3 would need to be retained. This is a new kind of
IPv6 packet processing. Therefore it may be that on the outbound leg
of non-storing RPL networks, that hop-by-hop IP-in-IP header can NOT
be used.
[I-D.ietf-roll-routing-dispatch] shows how the destination=root, and [I-D.ietf-roll-routing-dispatch] shows how the destination=root, and
destination=6LN IP-in-IP header can be compressed down to {TBD} destination=6LN IP-in-IP header can be compressed down to {TBD}
bytes. bytes.
Unlike in the storing mode case, there is no need for all nodes to Unlike in the storing mode case, there is no need for all nodes to
know about the existence of non-RPL aware nodes. Only the 6LBR needs know about the existence of non-RPL aware nodes. Only the 6LBR needs
to change when there are non-RPL aware nodes. Further, in the non- to change when there are non-RPL aware nodes. Further, in the non-
storing case, the 6LBR is informed by the DAOs when there are non-RPL storing case, the 6LBR is informed by the DAOs when there are non-RPL
aware nodes. aware nodes.
skipping to change at page 27, line 36 skipping to change at page 32, line 24
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van comments of Robert Cragie, Simon Duquennoy, Cenk Guendogan, Peter van
der Stok, Xavier Vilajosana and Thomas Watteyne. der Stok, Xavier Vilajosana and Thomas Watteyne.
12. References 12. References
12.1. Normative References 12.1. Normative References
[I-D.ietf-6man-rfc2460bis] [I-D.ietf-6man-rfc2460bis]
Deering, D. and R. Hinden, "Internet Protocol, Version 6 Hinden, R., "Internet Protocol, Version 6 (IPv6)
(IPv6) Specification", draft-ietf-6man-rfc2460bis-05 (work Specification", draft-ietf-6man-rfc2460bis-06 (work in
in progress), June 2016. progress), September 2016.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>. <http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
skipping to change at page 29, line 30 skipping to change at page 34, line 22
Email: maria.ines.robles@ericsson.com Email: maria.ines.robles@ericsson.com
Michael C. Richardson Michael C. Richardson
Sandelman Software Works Sandelman Software Works
470 Dawson Avenue 470 Dawson Avenue
Ottawa, ON K1Z 5V7 Ottawa, ON K1Z 5V7
CA CA
Email: mcr+ietf@sandelman.ca Email: mcr+ietf@sandelman.ca
URI: http://www.sandelman.ca/ URI: http://www.sandelman.ca/mcr/
Pascal Thubert Pascal Thubert
Cisco Systems, Inc Cisco Systems, Inc
Village d'Entreprises Green Side 400, Avenue de Roumanille Village d'Entreprises Green Side 400, Avenue de Roumanille
Batiment T3, Biot - Sophia Antipolis 06410 Batiment T3, Biot - Sophia Antipolis 06410
France France
Email: pthubert@cisco.com Email: pthubert@cisco.com
 End of changes. 90 change blocks. 
396 lines changed or deleted 511 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/