draft-ietf-roll-useofrplinfo-27.txt   draft-ietf-roll-useofrplinfo-28.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Aalto Internet-Draft Aalto
Updates: 6553, 6550, 8138 (if approved) M. Richardson Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: November 17, 2019 P. Thubert Expires: November 18, 2019 P. Thubert
Cisco Cisco
May 16, 2019 May 17, 2019
Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6 Using RPL Option Type, Routing Header for Source Routes and IPv6-in-IPv6
encapsulation in the RPL Data Plane encapsulation in the RPL Data Plane
draft-ietf-roll-useofrplinfo-27 draft-ietf-roll-useofrplinfo-28
Abstract Abstract
This document looks at different data flows through LLN (Low-Power This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554 enumerates the cases where RFC 6553 (RPL Option Type), RFC 6554
(Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is (Routing Header for Source Routes) and IPv6-in-IPv6 encapsulation is
required in data plane. This analysis provides the basis on which to required in data plane. This analysis provides the basis on which to
design efficient compression of these headers. This document updates design efficient compression of these headers. This document updates
skipping to change at page 1, line 44 skipping to change at page 1, line 44
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 17, 2019. This Internet-Draft will expire on November 18, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 15, line 15 skipping to change at page 15, line 15
storing) storing)
not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing) not-RPL-aware-leaf(~Raf) to not-RPL-aware-leaf(~Raf) (non-storing)
This document is consistent with the rule that a Header cannot be This document is consistent with the rule that a Header cannot be
inserted or removed on the fly inside an IPv6 packet that is being inserted or removed on the fly inside an IPv6 packet that is being
routed. This is a fundamental precept of the IPv6 architecture as routed. This is a fundamental precept of the IPv6 architecture as
outlined in [RFC8200]. Extensions headers may not be added or outlined in [RFC8200]. Extensions headers may not be added or
removed except by the sender or the receiver. removed except by the sender or the receiver.
However, unlike [RFC6553], the Hop-by-Hop Option Header used for the
RPI artifact has the first two bits set to '00'. This means that the
RPI artifact will be ignored when received by a host or router that
does not understand that option ( Section 4.2 [RFC8200]).
This means that when the no-drop RPI option code 0x23 is used, a
packet that leaves the RPL domain of an LLN (or that leaves the LLN
entirely) will not be discarded when it contains the [RFC6553] RPL
Hop-by-Hop option known as RPI. Thus, the RPI Hop-by-Hop option is
left in place even if the end host does not understand it.
NOTE: No clear attack has been described when the RPI information is
released to the Internet. At a minimum, it is clear that the RPI
option would waste some network bandwidth when it escapes. This is
traded off against the savings in the LLN by not having to
encapsulate the packet in order to remove the artifact. Please check
the Security Considerations sections Section 11 for further details.
As the rank information in the RPI artifact is changed at each hop, As the rank information in the RPI artifact is changed at each hop,
it will typically be zero when it arrives at the DODAG root. The it will typically be zero when it arrives at the DODAG root. The
DODAG root MUST force it to zero when passing the packet out to the DODAG root MUST force it to zero when passing the packet out to the
Internet. The Internet will therefore not see any SenderRank Internet. The Internet will therefore not see any SenderRank
information. information.
Despite being legal to leave the RPI artifact in place, an Despite being legal to leave the RPI artifact in place, an
intermediate router that needs to add an extension header (e.g. RH3 intermediate router that needs to add an extension header (e.g. RH3
or RPI Option) MUST still encapsulate the packet in an (additional) or RPI Option) MUST still encapsulate the packet in an (additional)
outer IP header. The new header is placed after this new outer IP outer IP header. The new header is placed after this new outer IP
skipping to change at page 16, line 28 skipping to change at page 16, line 10
challenges, yet costed significant code and testing complexity. The challenges, yet costed significant code and testing complexity. The
ability to compress the RPI down to three bytes or less removes much ability to compress the RPI down to three bytes or less removes much
of the pressure to optimize this any further of the pressure to optimize this any further
[I-D.ietf-anima-autonomic-control-plane]. [I-D.ietf-anima-autonomic-control-plane].
The earlier examples are more extensive to make sure that the process The earlier examples are more extensive to make sure that the process
is clear, while later examples are more concise. is clear, while later examples are more concise.
6. Storing mode 6. Storing mode
In storing mode (fully stateful), the sender can determine if the In storing mode (SM) (fully stateful), the sender can determine if
destination is inside the LLN by looking if the destination address the destination is inside the LLN by looking if the destination
is matched by the DIO's Prefix Information Option (PIO) option. address is matched by the DIO's Prefix Information Option (PIO)
option.
The following table (Figure 7) itemizes which headers are needed in The following table (Figure 7) itemizes which headers are needed in
each of the following scenarios. It indicates if the IPv6-in-IPv6 each of the following scenarios. It indicates if the IPv6-in-IPv6
header that is added, must be addressed to the final destination (the header that is added, must be addressed to the final destination (the
Raf node that is the target(tgt)), to the "root" or if a hop-by-hop Raf node that is the target(tgt)), to the "root" or if a hop-by-hop
header must be added (indicated by "hop"). header must be added (indicated by "hop").
In cases where no IPv6-in-IPv6 header is needed, the column states as In cases where no IPv6-in-IPv6 header is needed, the column states as
"No". If the IPv6-in-IPv6 header is needed is a "must". "No". If the IPv6-in-IPv6 header is needed is a "must".
skipping to change at page 41, line 5 skipping to change at page 41, line 5
Otherwise, there may be a RPI header buried inside the inner IP Otherwise, there may be a RPI header buried inside the inner IP
header, which should get ignored. header, which should get ignored.
Networks that use the RPL P2P extension [RFC6997] are essentially Networks that use the RPL P2P extension [RFC6997] are essentially
non-storing DODAGs and fall into this scenario or scenario non-storing DODAGs and fall into this scenario or scenario
Section 7.1.2, with the originating node acting as 6LBR. Section 7.1.2, with the originating node acting as 6LBR.
The Figure 19 shows the table that summarizes what headers are needed The Figure 19 shows the table that summarizes what headers are needed
for this use case. for this use case.
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
| Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN | | Header | 6LN | 6LR_ia | 6LBR | 6LR_id | 6LN |
| | src | | | | dst | | | src | | | | dst |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
| Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- | | Inserted|IPv6-in-IPv6| |IPv6-in-IPv6| -- | -- |
| headers | (RPI1) | |(RH3-> 6LN, | | | | headers | (RPI1) | |(RH3-> 6LN, | | |
| | | | RPI2) | | | | | | | RPI2) | | |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
| Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6| | Removed | -- | -- |IPv6-in-IPv6| -- |IPv6-in-IPv6|
| headers | | | (RPI1) | | (RH3, | | headers | | | (RPI1) | | (RH3, |
| | | | | | RPI2) | | | | | | | RPI2) |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
| Re-added| -- | -- | -- | -- | -- | | Re-added| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
| Modified| -- |IPv6-in-IPv | -- |IPv6-in-IPv6| -- | | Modified| -- |IP6-in-IP6| -- |IPv6-in-IPv6| -- |
| headers | | (RPI1) | | (RPI2) | | | headers | | (RPI1) | | (RPI2) | |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
|Untouched| -- | -- | -- | -- | -- | |Untouched| -- | -- | -- | -- | -- |
| headers | | | | | | | headers | | | | | |
+---------+------------+------------+------------+------------+------------+ +---------+------------+----------+------------+------------+------------+
Figure 19: Non Storing mode: Summary of the use of headers for RPL- Figure 19: Non Storing mode: Summary of the use of headers for RPL-
aware-leaf to RPL-aware-leaf aware-leaf to RPL-aware-leaf. IP6-in-IP6 refers to IPv6-in-IPv6.
7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware- 7.3.2. Non-SM: Example of Flow from RPL-aware-leaf to not-RPL-aware-
leaf leaf
In this case the flow comprises: In this case the flow comprises:
6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6) 6LN --> 6LR_ia --> root (6LBR) --> 6LR_id --> not-RPL-aware (IPv6)
For example, a communication flow could be: Node F --> Node D --> For example, a communication flow could be: Node F --> Node D -->
Node B --> Node A (root) --> Node B --> Node E --> Node G Node B --> Node A (root) --> Node B --> Node E --> Node G
 End of changes. 8 change blocks. 
47 lines changed or deleted 30 lines changed or added

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