draft-ietf-roll-useofrplinfo-18.txt   draft-ietf-roll-useofrplinfo-19.txt 
ROLL Working Group M. Robles ROLL Working Group M. Robles
Internet-Draft Ericsson Internet-Draft Ericsson
Updates: 6553, 6550, 8138 (if approved) M. Richardson Updates: 6553, 6550, 8138 (if approved) M. Richardson
Intended status: Standards Track SSW Intended status: Standards Track SSW
Expires: May 2, 2018 P. Thubert Expires: May 3, 2018 P. Thubert
Cisco Cisco
October 29, 2017 October 30, 2017
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-18 draft-ietf-roll-useofrplinfo-19
Abstract Abstract
This document looks at different data flows through LLN (Low-Power This document looks at different data flows through LLN (Low-Power
and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power and Lossy Networks) where RPL (IPv6 Routing Protocol for Low-Power
and Lossy Networks) is used to establish routing. The document and Lossy Networks) is used to establish routing. The document
enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6 enumerates the cases where RFC 6553, RFC 6554 and IPv6-in-IPv6
encapsulation is required. This analysis provides the basis on which encapsulation is required. This analysis provides the basis on which
to design efficient compression of these headers. Additionally, this to design efficient compression of these headers. Additionally, this
document updates the RFC 6553 adding a change to the RPL Option Type document updates the RFC 6553 adding a change to the RPL Option Type
skipping to change at page 1, line 40 skipping to change at page 1, line 40
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 2, 2018. This Internet-Draft will expire on May 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 IETF Trust and the persons identified as the Copyright (c) 2017 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 6, line 29 skipping to change at page 6, line 29
This change creates a flag day for existing networks which are This change creates a flag day for existing networks which are
currently using 0x63 as the RPI value. A move to 0x23 will not be currently using 0x63 as the RPI value. A move to 0x23 will not be
understood by those networks. It is suggested that implementations understood by those networks. It is suggested that implementations
accept both 0x63 and 0x23 when processing. When forwarding packets, accept both 0x63 and 0x23 when processing. When forwarding packets,
implementations SHOULD use the same value as it was received. When implementations SHOULD use the same value as it was received. When
originating new packets, implementations SHOULD have an option to originating new packets, implementations SHOULD have an option to
determine which value to originate with, this option is controlled by determine which value to originate with, this option is controlled by
the DIO option described below. the DIO option described below.
A network which is switching from straight 6lowpan compression A network which is switching from straight 6lowpan compression
mechanism to those described in [RFC8183] will experience a flag day mechanism to those described in [RFC8138] will experience a flag day
in the data compression anyway, and if possible this change can be in the data compression anyway, and if possible this change can be
deployed at the same time. deployed at the same time.
3.2. Updates to RFC 8138 3.2. Updates to RFC 8138
RPI-6LoRH header provides a compressed form for the RPL RPI RPI-6LoRH header provides a compressed form for the RPL RPI
[RFC8138]. It should be considered when the Option Type in RPL [RFC8138]. It should be considered when the Option Type in RPL
Option is decompressed, should take the value of 0x23 instead of Option is decompressed, should take the value of 0x23 instead of
0x63. 0x63.
skipping to change at page 37, line 49 skipping to change at page 37, line 49
| headers | | | | | | | 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
8. Observations about the cases 8. Observations about the cases
8.1. Storing mode 8.1. Storing mode
[RFC8183] shows that the hop-by-hop IP-in-IP header can be compressed [RFC8138] shows that the hop-by-hop IP-in-IP header can be compressed
using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header as described in using IP-in-IP 6LoRH (IP-in-IP-6LoRH) header as described in
Section 7 of the document. Section 7 of the document.
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.
Thanks to the change of the RPI option type from 0x63 to 0x23, there Thanks to the change of the RPI option type from 0x63 to 0x23, there
is no longer any uncertainty about when to use an IP-in-IP header in is no longer any uncertainty about when to use an IP-in-IP header in
the storing mode. A Hop-by-Hop Options Header containing the RPI the storing mode. A Hop-by-Hop Options Header containing the RPI
option SHOULD always be added when 6LRs originate packets (without option SHOULD always be added when 6LRs originate packets (without
skipping to change at page 38, line 36 skipping to change at page 38, line 36
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 for traffic originating from the root to hop-by-hop IP-in-IP headers for traffic originating from the root to
leafs. leafs.
The non-storing mode case does not require the type change from 0x63 The non-storing mode case does not require the type change from 0x63
to 0x23, as the root can always create the right packet. The type to 0x23, as the root can always create the right packet. The type
change does not adversely affect the non-storing case. change does not adversely affect the non-storing case.
9. 6LoRH Compression cases 9. 6LoRH Compression cases
The [RFC8183] proposes a compression method for RPI, RH3 and IPv6-in- The [RFC8138] proposes a compression method for RPI, RH3 and IPv6-in-
IPv6. IPv6.
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 |
+--+-----+---+--------------+-----------+-------------+-------------+ +--+-----+---+--------------+-----------+-------------+-------------+
skipping to change at page 41, line 22 skipping to change at page 41, line 22
would be cheaper should RPL be run in an environment where hostile would be cheaper should RPL be run in an environment where hostile
nodes are likely to be a part of the LLN. nodes are likely to be a part of the LLN.
The RH3 header usage described here can be abused in equivalent ways The RH3 header usage described here can be abused in equivalent ways
with an IPIP header to add the needed RH3 header. As such, the with an IPIP header to add the needed RH3 header. As such, the
attacker's RH3 header will not be seen by the network until it attacker's RH3 header will not be seen by the network until it
reaches the end host, which will decapsulate it. An end-host SHOULD reaches the end host, which will decapsulate it. An end-host SHOULD
be suspicious about a RH3 header which has additional hops which have be suspicious about a RH3 header which has additional hops which have
not yet been processed, and SHOULD ignore such a second RH3 header. not yet been processed, and SHOULD ignore such a second RH3 header.
In addition, the LLN will likely use [RFC8183] to compress the IPIP In addition, the LLN will likely use [RFC8138] to compress the IPIP
and RH3 headers. As such, the compressor at the RPL-root will see and RH3 headers. As such, the compressor at the RPL-root will see
the second RH3 header and MAY choose to discard the packet if the RH3 the second RH3 header and MAY choose to discard the packet if the RH3
header has not been completely consumed. A consumed (inert) RH3 header has not been completely consumed. A consumed (inert) RH3
header could be present in a packet that flows from one LLN, crosses header could be present in a packet that flows from one LLN, crosses
the Internet, and enters another LLN. As per the discussion in this the Internet, and enters another LLN. As per the discussion in this
document, such headers do not need to be removed. However, there is document, such headers do not need to be removed. However, there is
no case described in this document where an RH3 is inserted in a non- no case described in this document where an RH3 is inserted in a non-
storing network on traffic that is leaving the LLN, but this document storing network on traffic that is leaving the LLN, but this document
SHOULD NOT preclude such a future innovation. It should just be SHOULD NOT preclude such a future innovation. It should just be
noted that an incoming RH3 must be fully consumed, or very carefully noted that an incoming RH3 must be fully consumed, or very carefully
skipping to change at page 45, line 15 skipping to change at page 45, line 15
[RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and [RFC6997] Goyal, M., Ed., Baccelli, E., Philipp, M., Brandt, A., and
J. Martocci, "Reactive Discovery of Point-to-Point Routes J. Martocci, "Reactive Discovery of Point-to-Point Routes
in Low-Power and Lossy Networks", RFC 6997, in Low-Power and Lossy Networks", RFC 6997,
DOI 10.17487/RFC6997, August 2013, DOI 10.17487/RFC6997, August 2013,
<https://www.rfc-editor.org/info/rfc6997>. <https://www.rfc-editor.org/info/rfc6997>.
[RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and
Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January
2014, <https://www.rfc-editor.org/info/rfc7102>. 2014, <https://www.rfc-editor.org/info/rfc7102>.
[RFC8183] Austein, R., "An Out-of-Band Setup Protocol for Resource
Public Key Infrastructure (RPKI) Production Services",
RFC 8183, DOI 10.17487/RFC8183, July 2017,
<https://www.rfc-editor.org/info/rfc8183>.
[Second6TischPlugtest] [Second6TischPlugtest]
"2nd 6Tisch Plugtest", <http://www.ietf.org/mail- "2nd 6Tisch Plugtest", <http://www.ietf.org/mail-
archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>. archive/web/6tisch/current/pdfgDMQcdCkRz.pdf>.
Authors' Addresses Authors' Addresses
Maria Ines Robles Maria Ines Robles
Ericsson Ericsson
Hirsalantie 11 Hirsalantie 11
Jorvas 02420 Jorvas 02420
 End of changes. 9 change blocks. 
13 lines changed or deleted 8 lines changed or added

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