draft-ietf-roll-useofrplinfo-06.txt   draft-ietf-roll-useofrplinfo-07.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 19, 2017 SSW Expires: January 21, 2017 SSW
P. Thubert P. Thubert
Cisco Cisco
July 18, 2016 July 20, 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-06 draft-ietf-roll-useofrplinfo-07
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 19, 2017. This Internet-Draft will expire on January 21, 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 20 skipping to change at page 2, line 20
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 . . . . . . . . . . . . . . . . . . . . . . . . 8
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 . . . . . 12 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 . . . . . 13 5.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 12
5.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 14 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 . . 15 5.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 14
5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 16 5.10. Example of Flow from RPL-aware-leaf to non-RPL-aware-leaf 15
5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 18 5.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 15
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 20 6. Non Storing mode . . . . . . . . . . . . . . . . . . . . . . 16
6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 20 6.1. Example of Flow from RPL-aware-leaf to root . . . . . . . 17
6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 21 6.2. Example of Flow from root to RPL-aware-leaf . . . . . . . 17
6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 21 6.3. Example of Flow from root to not-RPL-aware-leaf . . . . . 18
6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 22 6.4. Example of Flow from not-RPL-aware-leaf to root . . . . . 19
6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 23 6.5. Example of Flow from RPL-aware-leaf to Internet . . . . . 19
6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 23 6.6. Example of Flow from Internet to RPL-aware-leaf . . . . . 20
6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 24 6.7. Example of Flow from not-RPL-aware-leaf to Internet . . . 21
6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 25 6.8. Example of Flow from Internet to non-RPL-aware-leaf . . . 21
6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 25 6.9. Example of Flow from RPL-aware-leaf to RPL-aware-leaf . . 22
6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 26 6.10. Example of Flow from RPL-aware-leaf to not-RPL-aware-leaf 23
6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 27 6.11. Example of Flow from not-RPL-aware-leaf to RPL-aware-leaf 24
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 . . . . . . . . . . . . . . . . . . . . . . . . . . 28 leaf . . . . . . . . . . . . . . . . . . . . . . . . . . 24
7. Observations about the problem . . . . . . . . . . . . . . . 28 7. Observations about the problem . . . . . . . . . . . . . . . 25
7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 28 7.1. Storing mode . . . . . . . . . . . . . . . . . . . . . . 25
7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 29 7.2. Non-Storing mode . . . . . . . . . . . . . . . . . . . . 26
8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 30 8. 6LoRH Compression cases . . . . . . . . . . . . . . . . . . . 26
9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27
10. Security Considerations . . . . . . . . . . . . . . . . . . . 30 10. Security Considerations . . . . . . . . . . . . . . . . . . . 27
11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 30 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 27
12.1. Normative References . . . . . . . . . . . . . . . . . . 30 12.1. Normative References . . . . . . . . . . . . . . . . . . 27
12.2. Informative References . . . . . . . . . . . . . . . . . 31 12.2. Informative References . . . . . . . . . . . . . . . . . 28
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 32 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29
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 7, line 9 skipping to change at page 7, line 9
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
[I-D.ietf-6man-rfc2460bis] are passed.
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
Internet to RPL-aware-leaf Internet to RPL-aware-leaf
not-RPL-aware-leaf to Internet not-RPL-aware-leaf to Internet
Internet to not-RPL-aware-leaf Internet to not-RPL-aware-leaf
RPL-aware-leaf to RPL-aware-leaf RPL-aware-leaf to RPL-aware-leaf (storing and non-storing)
RPL-aware-leaf to not-RPL-aware-leaf RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
not-RPL-aware-leaf to RPL-aware-leaf not-RPL-aware-leaf to RPL-aware-leaf (storing and non-storing)
not-RPL-aware-leaf to not-RPL-aware-leaf not-RPL-aware-leaf to not-RPL-aware-leaf (non-storing)
This document assumes a 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. A removed on the fly inside an IPv6 packet that is being routed. This
fundamental precept of the IPv6 architecture as outlined in [RFC2460] is a fundamental precept of the IPv6 architecture as outlined in
is that Extensions may not be added or removed except by the sender [RFC2460] is that Extensions may not be added or removed except by
or the receiver. the sender or the receiver. (A revision to RFC2460 considered
changing this rule, but has kept it)
Note: current discussions on [I-D.ietf-6man-rfc2460bis] related to But, options in the Hop-by-Hop option which are marked with option
extensions headers may affect some cases in this document (Ticket type 01 ([RFC2460] section 4.2 and [I-D.ietf-6man-rfc2460bis]) SHOULD
nro. 9) in 6man. [TO DO]. be ignored when received by a host or router which does not
understand that option.
A second important thing is that packets with a Hop-by-Hop option This means that in general, any packet that leaves the RPL domain of
which are marked with option type 01 ([RFC2460] section 4.2) must be an LLN (or leaves the LLN entirely) will NOT be discarded, even if it
discarded if received by a host or router which does not understand has the [RFC6553] RPL Option Header known as the RPI or [RFC6554]
that option. This means that in general, any packet that leaves the SRH3 Extension Header (S)RH3.
RPL domain of an LLN (or leaves the LLN entirely) is likely to be
discarded if it still contains an [RFC6553] RPL Option Header known
as the RPI.
The combination of these two rules means that the arrangement of With abolition of one of these rules it means that the RPI Hop-by-Hop
headers must be done so that traffic intended to exit the RPL domain option MAY be left in place even if the end host does host understand
can have the RPI option removed prior to leaving the RPL domain. it. This collapses many of the cases above (where it says "or")
An intermediate router that needs to add a header must encapsulate An intermediate router that needs to add an extension header (SHR3 or
the packet in an (additional) outer IP header where the new header RPI Option) must encapsulate the packet in an (additional) outer IP
can be placed. header where the new header can be placed.
This also means that a Header can only be removed by an intermediate This also means that a Header can only be removed by an intermediate
router if it is placed in an encapsulating IPv6 Header, and in that router if it is placed in an encapsulating IPv6 Header, and in that
case, the whole encapsulating header must be removed - a replacement case, the whole encapsulating header must be removed - a replacement
may be added. Further, an intermediate router can only remove such may be added. Further, an intermediate router can only remove such
an outer header if that outer header has the router as the an outer header if that outer header has the router as the
destination! destination!
Both RPI and RH3 headers may be modified by routers on the path of Both RPI and RH3 headers may be modified by routers on the path of
the packet without the need to add or remove an encapsulating header. the packet without the need to add to remove an encapsulating header.
Both headers were designed with this modification in mind, and both Both headers were designed with this modification in mind, and both
the RPL RH and the RPL option are marked mutable but recoverable, so the RPL RH and the RPL option are marked mutable but recoverable, so
an IPsec AH security header can be applied across these headers, but an IPsec AH security header can be applied across these headers, but
it may not secure all the values in those headers. it may not secure all the values in those headers.
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. There may be cases (such as in
6tisch) where the instanceID may still be needed to pick an 6tisch) where the instanceID may still be needed to pick an
appropriate priority or channel at each hop. appropriate priority or channel at each hop.
The applicability for storing (RPL-SM) and non-Storing (RPL-NSM)
modes for the previous cases is showed as follows:
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
In storing mode (fully stateful), the sender cannot determine whether In storing mode (fully stateful), the sender cannot determine whether
skipping to change at page 10, line 16 skipping to change at page 10, line 16
RPL-aware-leaf (6LN) --> 6LR --> 6LR,... --> root (6LBR) RPL-aware-leaf (6LN) --> 6LR --> 6LR,... --> 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.
The RPI header can be removed by the 6LBR because the packet is The RPI header can be removed by the 6LBR because the packet is
addressed to the 6LBR. The 6LN must know that it is communicating addressed to the 6LBR. The 6LN must know that it is communicating
with the 6LBR to make use of this scenario. The 6LN can know the with the 6LBR to make use of this scenario. The 6LN can know the
address of the 6LBR because it knows the address of the root via the address of the 6LBR because it knows the address of the root via the
DODAGID in the DIO messages. DODAGID in the DIO messages.
+-------------------+-----+------+------+ +-------------------+-----+------+------+
| Header | 6LN | 6LR | 6LBR | | Header | 6LN | 6LR | 6LBR |
+-------------------+-----+------+------+ +-------------------+-----+------+------+
| Inserted headers | RPI | -- | -- | | Inserted headers | RPI | -- | -- |
skipping to change at page 11, line 23 skipping to change at page 11, line 23
+-------------------+------+-------+------+ +-------------------+------+-------+------+
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)--> 6LR --> not-RPL-aware-leaf (6LN)
The question in this scenario is how the root knows how to address As the RPI extension can be ignored by the not-RPL-aware leaf, this
the IPv6-in-IPv6 header. It can not know that the destination isn't situation is identical to the previous scenario.
RPL aware, so it must insert an IPv6 header that can be removed on
the last RPL aware node. Since the root can not know in a storing
network where the last RPL aware node is, the IPv6-in-IPv6 header
must be added hop-by-hop along the path from root to leaf.
The root (6LBR) uses IPv6-in-IPv6 encapsulation to transmit
information not related with the RPL domain. In the 6LBR the RPI
header is inserted into an IPv6-in-IPv6 header addressed to the last
6LR, which removes the header before it passes the packet to the IPv6
node (6LN).
An alternative option is to add an attribute in the RPL Target Option
to indicate that the target is not RPL aware: future work may explore
this possibility.
+-------------------+---------------+---------------+------+ +-------------------+------+-----+------+
| Header | 6LBR | 6LR | IPv6 | | Header | 6LBR | 6LR | IPv6 |
+-------------------+---------------+---------------+------+ +-------------------+------+-----+------+
| Inserted headers | IP-in-IP(RPI) | -- | -- | | Inserted headers | -- | -- | -- |
| Removed headers | -- | IP-in-IP(RPI) | -- | | Removed headers | -- | -- | -- |
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | -- | -- | | Modified headers | -- | -- | -- |
| Untouched headers | -- | -- | -- | | Untouched headers | -- | -- | -- |
+-------------------+---------------+---------------+------+ +-------------------+------+-----+------+
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 (6LN) --> 6LR --> root (6LBR)
skipping to change at page 12, line 31 skipping to change at page 12, line 20
| Re-added headers | -- | -- | -- | | Re-added headers | -- | -- | -- |
| Modified headers | -- | -- | -- | | Modified headers | -- | -- | -- |
| Untouched 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 should not go out to Internet as it RPL information from RFC 6553 MAY go out to Internet as it will be
will cause the packet to be discarded at the first non-RPI aware ignored by nodes which have not been configured to be RPI aware.
router. The 6LBR must be able to take this information out before
sending the packet upwards to the Internet. This requires the RPI
header be placed in an IP-in-IP header that the root can remove.
In this case the flow comprises: In this case the flow comprises:
RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet RPL-aware-leaf (6LN) --> 6LR --> root (6LBR) --> Internet
The 6LN will insert the RPI in a IPv6-in-IPv6 in a outer header, No IP-in-IP header is required.
which may be addressed to the 6LBR (root), or alternatively, it could
be addressed hop-by-hop.
+-----------------+---------------+------+---------------+----------+ +-------------------+------+------+------+----------+
| Header | 6LN | 6LR | 6LBR | Internet | | Header | 6LN | 6LR | 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 | -- | -- | -- | -- |
| Modified | -- | RPI | -- | -- | +-------------------+------+------+------+----------+
| headers | | | | |
| Untouched | -- | -- | -- | -- |
| headers | | | | |
+-----------------+---------------+------+---------------+----------+
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) --> 6LR --> RPL-aware-leaf (6LN)
skipping to change at page 14, line 44 skipping to change at page 14, line 12
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) --> 6LR --> not-RPL-aware-leaf (6LN)
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 will need to be addressed hop-by-hop along the path as The IP-in-IP can be addressed to the not-RPL-aware-leaf, leaving the
in storing mode, the 6LBR has no idea if the 6LN is RPL aware or not, RPI inside.
nor what the closest attached 6LR node is.
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 | IPv6 |
+-----------------+----------+---------------+---------------+------+ +-----------------+----------+---------------+---------------+------+
| Inserted | -- | IP-in-IP(RPI) | -- | -- | | Inserted | -- | IP-in-IP(RPI) | -- | -- |
| headers | | | | | | headers | | | | |
skipping to change at page 15, line 37 skipping to change at page 14, line 51
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR --> common parent (6LR) --> 6LR --> 6LN 6LN --> 6LR --> common parent (6LR) --> 6LR --> 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. The ability to remove the RPI, so no IP-in-IP headers are necessary. This may be
do this depends upon the sending the 6LN to know that the destination done regardless of where the destination is, as the included RPI will
is: a) inside the LLN, and b) RPL capable. be ignored by the receiver.
The sender can determine if the destination is inside the LLN by
looking if the destination address is matched by the DIO's PIO
option. This check may be modified by the use of backbone routers,
but in this case it is assumed that the backbone routers are RPL
capable and so can process the RPI header correctly.
The other check, that the destination is RPL capable is not currently
discernible by the sender. This information is necessary to
distinguish this test case from Section 5.10.
+-------------+-------+---------------+---------------+-----+-------+ +-------------+-------+---------------+---------------+-----+-------+
| Header | 6LN | 6LR | 6LR (common | 6LR | 6LN | | Header | 6LN | 6LR | 6LR (common | 6LR | 6LN |
| | src | | parent) | | dst | | | src | | parent) | | dst |
+-------------+-------+---------------+---------------+-----+-------+ +-------------+-------+---------------+---------------+-----+-------+
| Inserted | RPI | -- | -- | -- | -- | | Inserted | RPI | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
| Removed | -- | -- | -- | -- | RPI | | Removed | -- | -- | -- | -- | RPI |
| headers | | | | | | | headers | | | | | |
| Re-added | -- | -- | -- | -- | -- | | Re-added | -- | -- | -- | -- | -- |
skipping to change at page 16, line 31 skipping to change at page 15, line 33
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 --> 6LR --> common parent (6LR) --> 6LR --> not-RPL-aware 6LN
The sender, being aware out of band, that the receiver is not RPL This situation is identical to the situation Section 5.9
aware, adds an RPI header inside an IP-in-IP header. The IP-in-IP
header needs to be addressed on a hop-by-hop basis so that the last
6LR can remove the RPI header.
,---.
/ \
( 6LR2 ) IP3,RPI,IP,ULP
,-" .
,-" `---' `.
,' `.
,---. ,-" `,---.
/ +" / \
( 6LR1 ) Remove the IP3,RPI( 6LR3 )
\ / \ /
/---' `---'|
/ IP2,RPI,IP,ULP \
/ |
/ \
,---+-. |
/ \ +--+----+
( 6LN ) | |
\ / | IPv6 | IP,ULP
`-----' | |
IP1,RPI,IP,ULP +-------+
Figure 3: Solution IPv6-in-IPv6 in each hop
As we mentioned previously, packets with a Hop-by-Hop option which
are marked with option type 01 ([RFC2460] section 4.2) must be
discarded if received by a host or router which does not understand
that option. This means that in general, any packet that leaves the
RPL domain of an LLN (or leaves the LLN entirely) is likely to be
discarded if it still contains an [RFC6553] RPL Option Header known
as the RPI. For this case, if the definition of the Option Type
field of RPL Option '01' were changed so that it isn't a "discard if
not recognized", then no IP-in-IP header would be necessary. This
change is an incompatible on-the-wire change and would require some
kind of flag day, possibly a change that is done simultaenously with
an updated 6LoRH compress.
+--------+------------+------------+------------+------------+------+
| Header | 6LN | 6LR | 6LR | 6LR | IPv6 |
| | | | (common | | |
| | | | parent) | | |
+--------+------------+------------+------------+------------+------+
| Insert | IP-in- | -- | -- | -- | -- |
| ed hea | IP(RPI) | | | | |
| ders | | | | | |
| Remove | -- | -- | -- | IP-in- | -- |
| d head | | | | IP(RPI) | |
| ers | | | | | |
| Re- | -- | -- | -- | -- | -- |
| added | | | | | |
| header | | | | | |
| s | | | | | |
| Modifi | -- | IP-in- | IP-in- | -- | -- |
| ed hea | | IP(RPI) | IP(RPI) | | |
| ders | | | | | |
| Untouc | -- | -- | -- | -- | -- |
| hed he | | | | | |
| aders | | | | | |
+--------+------------+------------+------------+------------+------+
Storing: Summary of the use of headers from RPL-aware-leaf to not-
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 --> 6LR --> common parent (6LR) --> 6LR --> 6LN
The 6LR receives the packet from the the IPv6 node and inserts and The 6LR 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 could be addressed to the 6LN if the destination is known to header is addressed to the destinion 6LN.
the RPL aware, otherwise it must send the packet using a hop-by-hop
IP-in-IP header. Similar considerations apply from section
Section 5.10.
+--------+------+------------+------------+------------+------------+ +--------+------+------------+------------+------------+------------+
| Header | IPv6 | 6LR | common | 6LR | 6LN | | Header | IPv6 | 6LR | common | 6LR | 6LN |
| | | | parent | | | | | | | parent | | |
| | | | (6LR) | | | | | | | (6LR) | | |
+--------+------+------------+------------+------------+------------+ +--------+------+------------+------------+------------+------------+
| Insert | -- | IP-in- | -- | -- | -- | | Insert | -- | IP-in- | -- | -- | -- |
| ed hea | | IP(RPI) | | | | | ed hea | | IP(RPI) | | | |
| ders | | | | | | | ders | | | | | |
| Remove | -- | -- | -- | -- | IP-in- | | Remove | -- | -- | -- | -- | IP-in- |
skipping to change at page 19, line 38 skipping to change at page 16, line 38
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 node)--> 6LR --> root (6LBR) --> 6LR --> not-
RPL-aware 6LN (IPv6 node) RPL-aware 6LN (IPv6 node)
This flow combines the problems of the two previous sections. There This flow is identical to Section 5.11
is no choice at the first 6LR: it must insert an RPI, and to do that
it must add an IP-in-IP header. That IP-in-IP header must be
addressed on a hop-by-hop basis.
+----------+-----+-------------+--------------+--------------+------+
| Header | IPv | 6LR | 6LR (common | 6LR | IPv6 |
| | 6 | | parent) | | dst |
| | src | | | | |
+----------+-----+-------------+--------------+--------------+------+
| Inserted | -- | IP-in- | -- | -- | -- |
| headers | | IP(RPI) | | | |
| Removed | -- | -- | -- | IP-in- | -- |
| headers | | | | IP(RPI) | |
| Re-added | -- | IP-in- | IP-in- | IP-in- | -- |
| headers | | IP(RPI) | IP(RPI) | IP(RPI) | |
| Modified | -- | -- | -- | -- | -- |
| headers | | | | | |
| Untouche | -- | -- | -- | -- | -- |
| d | | | | | |
| headers | | | | | |
+----------+-----+-------------+--------------+--------------+------+
Storing: Summary of the use of headers from not-RPL-aware-leaf to
not-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 | Yes | 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 |
skipping to change at page 30, line 19 skipping to change at page 27, line 11
In Storing Mode, for the examples of Flow from RPL-aware-leaf to non- In Storing Mode, for the examples of Flow from RPL-aware-leaf to non-
RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise RPL-aware-leaf and non-RPL-aware-leaf to non-RPL-aware-leaf comprise
an IP-in-IP and RPI compression headers. The type of this case is an IP-in-IP and RPI compression headers. The type of this case is
critical since IP-in-IP is encapsulating a RPI header. critical since IP-in-IP is encapsulating a RPI header.
+--+-----+---+--------------+-----------+-------------+-------------+ +--+-----+---+--------------+-----------+-------------+-------------+
|1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC | |1 | 0|0 |TSE| 6LoRH Type 6 | Hop Limit | RPI - 6LoRH | LOWPAN IPHC |
+--+-----+---+--------------+-----------+-------------+-------------+ +--+-----+---+--------------+-----------+-------------+-------------+
Figure 4: Critical IP-in-IP (RPI). Figure 3: Critical IP-in-IP (RPI).
9. IANA Considerations 9. IANA Considerations
There are no IANA considerations related to this document. There are no IANA considerations related to this document.
10. Security Considerations 10. Security Considerations
The security considerations covering of [RFC6553] and [RFC6554] apply The security considerations covering of [RFC6553] and [RFC6554] apply
when the packets get into RPL Domain. when the packets get into RPL Domain.
skipping to change at page 30, line 43 skipping to change at page 27, line 35
Network (ITN) METRICS project (grant agreement No. 607728). Network (ITN) METRICS project (grant agreement No. 607728).
The authors would like to acknowledge the review, feedback, and The authors would like to acknowledge the review, feedback, and
comments of 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]
Deering, D. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-05 (work
in progress), June 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.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
skipping to change at page 31, line 26 skipping to change at page 28, line 26
<http://www.rfc-editor.org/info/rfc6553>. <http://www.rfc-editor.org/info/rfc6553>.
[RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6 [RFC6554] Hui, J., Vasseur, JP., Culler, D., and V. Manral, "An IPv6
Routing Header for Source Routes with the Routing Protocol Routing Header for Source Routes with the Routing Protocol
for Low-Power and Lossy Networks (RPL)", RFC 6554, for Low-Power and Lossy Networks (RPL)", RFC 6554,
DOI 10.17487/RFC6554, March 2012, DOI 10.17487/RFC6554, March 2012,
<http://www.rfc-editor.org/info/rfc6554>. <http://www.rfc-editor.org/info/rfc6554>.
12.2. Informative References 12.2. Informative References
[I-D.ietf-6man-rfc2460bis]
Deering, D. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", draft-ietf-6man-rfc2460bis-05 (work
in progress), June 2016.
[I-D.ietf-6tisch-architecture] [I-D.ietf-6tisch-architecture]
Thubert, P., "An Architecture for IPv6 over the TSCH mode Thubert, P., "An Architecture for IPv6 over the TSCH mode
of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work of IEEE 802.15.4", draft-ietf-6tisch-architecture-10 (work
in progress), June 2016. in progress), June 2016.
[I-D.ietf-roll-routing-dispatch] [I-D.ietf-roll-routing-dispatch]
Thubert, P., Bormann, C., Toutain, L., and R. Cragie, Thubert, P., Bormann, C., Toutain, L., and R. Cragie,
"6LoWPAN Routing Header", draft-ietf-roll-routing- "6LoWPAN Routing Header", draft-ietf-roll-routing-
dispatch-00 (work in progress), March 2016. dispatch-00 (work in progress), March 2016.
 End of changes. 36 change blocks. 
229 lines changed or deleted 103 lines changed or added

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