draft-ietf-roll-useofrplinfo-21.txt   draft-ietf-roll-useofrplinfo-22.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: August 14, 2018 P. Thubert Expires: September 2, 2018 P. Thubert
Cisco Cisco
February 10, 2018 March 1, 2018
When to use RFC 6553, 6554 and IPv6-in-IPv6 When to use RFC 6553, 6554 and IPv6-in-IPv6
draft-ietf-roll-useofrplinfo-21 draft-ietf-roll-useofrplinfo-22
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. This document to design efficient compression of these headers. This document
updates RFC 6553 adding a change to the RPL Option Type. updates RFC 6553 adding a change to the RPL Option Type.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 August 14, 2018. This Internet-Draft will expire on September 2, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 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 2, line 22 skipping to change at page 2, line 22
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 . . . . . . . . . . . . 4 2. Terminology and Requirements Language . . . . . . . . . . . . 4
2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5 2.1. hop-by-hop IPv6-in-IPv6 headers . . . . . . . . . . . . . 5
3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5 3. Updates to RFC6553, RFC6550 and RFC 8138 . . . . . . . . . . 5
3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5 3.1. Updates to RFC 6553 . . . . . . . . . . . . . . . . . . . 5
3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 6 3.2. Updates to RFC 8138 . . . . . . . . . . . . . . . . . . . 7
3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG 3.3. Updates to RFC 6550: Indicating the new RPI in the DODAG
Configuration Option Flag. . . . . . . . . . . . . . . . 7 Configuration Option Flag. . . . . . . . . . . . . . . . 7
4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8 4. Sample/reference topology . . . . . . . . . . . . . . . . . . 8
5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11 5. Use cases . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13 6. Storing mode . . . . . . . . . . . . . . . . . . . . . . . . 13
6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14 6.1. Storing Mode: Interaction between Leaf and Root . . . . . 14
6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 15 6.1.1. SM: Example of Flow from RPL-aware-leaf to root . . . 15
6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 16 6.1.2. SM: Example of Flow from root to RPL-aware-leaf . . . 16
6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 16 6.1.3. SM: Example of Flow from root to not-RPL-aware-leaf . 16
6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 17 6.1.4. SM: Example of Flow from not-RPL-aware-leaf to root . 17
skipping to change at page 5, line 18 skipping to change at page 5, line 18
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. Updates to RFC6553, RFC6550 and RFC 8138 3. Updates to RFC6553, RFC6550 and RFC 8138
3.1. Updates to RFC 6553 3.1. Updates to RFC 6553
This modification is required to be able to send, for example, IPv6
packets from a RPL-aware-leaf to a not-RPL-aware node through
Internet (see Section 6.2.1), without requiring IP-in-IP
encapsulation.
[RFC6553] states as showed below, that in the Option Type field of [RFC6553] states as showed below, that in the Option Type field of
the RPL Option header, the two high order bits MUST be set to '01' the RPL Option header, the two high order bits MUST be set to '01'
and the third bit is equal to '1'. The first two bits indicate that and the third bit is equal to '1'. The first two bits indicate that
the IPv6 node MUST discard the packet if it doesn't recognize the the IPv6 node MUST discard the packet if it doesn't recognize the
option type, and the third bit indicates that the Option Data may option type, and the third bit indicates that the Option Data may
change en route. The remaining bits serve as the option type. change en route. The remaining bits serve as the option type.
Hex Value Binary Value Hex Value Binary Value
act chg rest Description Reference act chg rest Description Reference
--------- --- --- ------- ----------------- ---------- --------- --- --- ------- ----------------- ----------
skipping to change at page 5, line 46 skipping to change at page 6, line 5
intermediate nodes) is now optional, but if they are configured to intermediate nodes) is now optional, but if they are configured to
process the header, and if such nodes encounter an option with the process the header, and if such nodes encounter an option with the
first two bits set to 01, they will drop the packet (if they conform first two bits set to 01, they will drop the packet (if they conform
to [RFC8200]). Host systems should do the same, irrespective of the to [RFC8200]). Host systems should do the same, irrespective of the
configuration. configuration.
Based on That, if an IPv6 (intermediate) node (RPL-not-capable) Based on That, if an IPv6 (intermediate) node (RPL-not-capable)
receives a packet with an RPL Option, it should ignore the HBH RPL receives a packet with an RPL Option, it should ignore the HBH RPL
option (skip over this option and continue processing the header). option (skip over this option and continue processing the header).
This is relevant, as we mentioned previously, in the case that we
have a flow from RPL-aware-leaf to Internet (see Section 6.2.1).
Thus, this document updates the Option Type field to: the two high Thus, this document updates the Option Type field to: the two high
order bits MUST be set to '00' and the third bit is equal to '1'. order bits MUST be set to '00' and the third bit is equal to '1'.
The first two bits indicate that the IPv6 node MUST skip over this The first two bits indicate that the IPv6 node MUST skip over this
option and continue processing the header ([RFC8200] Section 4.2) if option and continue processing the header ([RFC8200] Section 4.2) if
it doesn't recognize the option type, and the third bit continues to it doesn't recognize the option type, and the third bit continues to
be set to indicate that the Option Data may change en route. The be set to indicate that the Option Data may change en route. The
remaining bits serve as the option type and remain as 0x3. This remaining bits serve as the option type and remain as 0x3. This
ensures that a packet that leaves the RPL domain of an LLN (or that ensures that a packet that leaves the RPL domain of an LLN (or that
leaves the LLN entirely) will not be discarded when it contains the leaves the LLN entirely) will not be discarded when it contains the
[RFC6553] RPL Hop-by-Hop option known as RPI. [RFC6553] RPL Hop-by-Hop option known as RPI.
skipping to change at page 43, line 19 skipping to change at page 43, line 19
[RFC7416] deals with many other threats to LLNs not directly related [RFC7416] deals with many other threats to LLNs not directly related
to the use of IPIP headers, and this document does not change that to the use of IPIP headers, and this document does not change that
analysis. analysis.
12. Acknowledgments 12. Acknowledgments
This work is partially funded by the FP7 Marie Curie Initial Training This work is partially funded by the FP7 Marie Curie Initial Training
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 A special BIG thanks to C. M. Heard for the help with the
comments of (alphabetical order): Robert Cragie, Simon Duquennoy, Section 3. Much of the redaction in that section is based on his
Ralph Droms, Cenk Guendogan, C. M. Heard, Rahul Jadhav, Matthias comments.
Additionally, the authors would like to acknowledge the review,
feedback, and comments of (alphabetical order): Robert Cragie, Simon
Duquennoy, Ralph Droms, Cenk Guendogan, Rahul Jadhav, Matthias
Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne. Kovatsch, Peter van der Stok, Xavier Vilajosana and Thomas Watteyne.
13. References 13. References
13.1. Normative References 13.1. Normative References
[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,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
skipping to change at page 44, line 42 skipping to change at page 44, line 49
13.2. Informative References 13.2. Informative References
[DDOS-KREBS] [DDOS-KREBS]
Goodin, D., "Record-breaking DDoS reportedly delivered by Goodin, D., "Record-breaking DDoS reportedly delivered by
>145k hacked cameras", September 2016, >145k hacked cameras", September 2016,
<http://arstechnica.com/security/2016/09/botnet-of-145k- <http://arstechnica.com/security/2016/09/botnet-of-145k-
cameras-reportedly-deliver-internets-biggest-ddos-ever/>. cameras-reportedly-deliver-internets-biggest-ddos-ever/>.
[I-D.ietf-6lo-backbone-router] [I-D.ietf-6lo-backbone-router]
Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo- Thubert, P., "IPv6 Backbone Router", draft-ietf-6lo-
backbone-router-05 (work in progress), January 2018. backbone-router-06 (work in progress), February 2018.
[I-D.ietf-6man-rfc6434-bis] [I-D.ietf-6man-rfc6434-bis]
Chown, T., Loughney, J., and T. Winters, "IPv6 Node Chown, T., Loughney, J., and T. Winters, "IPv6 Node
Requirements", draft-ietf-6man-rfc6434-bis-03 (work in Requirements", draft-ietf-6man-rfc6434-bis-05 (work in
progress), February 2018. progress), February 2018.
[I-D.ietf-6tisch-dtsecurity-secure-join] [I-D.ietf-6tisch-dtsecurity-secure-join]
Richardson, M., "6tisch Secure Join protocol", draft-ietf- Richardson, M., "6tisch Secure Join protocol", draft-ietf-
6tisch-dtsecurity-secure-join-01 (work in progress), 6tisch-dtsecurity-secure-join-01 (work in progress),
February 2017. February 2017.
[I-D.ietf-anima-autonomic-control-plane] [I-D.ietf-anima-autonomic-control-plane]
Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic Eckert, T., Behringer, M., and S. Bjarnason, "An Autonomic
Control Plane (ACP)", draft-ietf-anima-autonomic-control- Control Plane (ACP)", draft-ietf-anima-autonomic-control-
plane-13 (work in progress), December 2017. plane-13 (work in progress), December 2017.
[I-D.ietf-anima-bootstrapping-keyinfra] [I-D.ietf-anima-bootstrapping-keyinfra]
Pritikin, M., Richardson, M., Behringer, M., Bjarnason, Pritikin, M., Richardson, M., Behringer, M., Bjarnason,
S., and K. Watsen, "Bootstrapping Remote Secure Key S., and K. Watsen, "Bootstrapping Remote Secure Key
Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping- Infrastructures (BRSKI)", draft-ietf-anima-bootstrapping-
keyinfra-09 (work in progress), October 2017. keyinfra-11 (work in progress), February 2018.
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for [RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192, Renumbering an IPv6 Network without a Flag Day", RFC 4192,
DOI 10.17487/RFC4192, September 2005, DOI 10.17487/RFC4192, September 2005,
<https://www.rfc-editor.org/info/rfc4192>. <https://www.rfc-editor.org/info/rfc4192>.
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet [RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet
Control Message Protocol (ICMPv6) for the Internet Control Message Protocol (ICMPv6) for the Internet
Protocol Version 6 (IPv6) Specification", STD 89, Protocol Version 6 (IPv6) Specification", STD 89,
RFC 4443, DOI 10.17487/RFC4443, March 2006, RFC 4443, DOI 10.17487/RFC4443, March 2006,
 End of changes. 11 change blocks. 
11 lines changed or deleted 23 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/