draft-ietf-roll-turnon-rfc8138-09.txt   draft-ietf-roll-turnon-rfc8138-10.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft L. Zhao Internet-Draft L. Zhao
Updates: 8138 (if approved) Cisco Systems Updates: 8138 (if approved) Cisco Systems
Intended status: Standards Track 27 July 2020 Intended status: Standards Track 5 August 2020
Expires: 28 January 2021 Expires: 6 February 2021
A RPL DODAG Configuration Option for the 6LoWPAN Routing Header A RPL DODAG Configuration Option for the 6LoWPAN Routing Header
draft-ietf-roll-turnon-rfc8138-09 draft-ietf-roll-turnon-rfc8138-10
Abstract Abstract
This document updates RFC 8138 by defining a bit in the RPL DODAG This document updates RFC 8138 by defining a bit in the RPL DODAG
Configuration Option to indicate whether compression is used within Configuration Option to indicate whether compression is used within
the RPL Instance, and specify the behavior of RFC 8138-capable nodes the RPL Instance, and specify the behavior of RFC 8138-capable nodes
when the bit is set and reset. when the bit is set and reset.
Status of This Memo Status of This Memo
skipping to change at page 1, line 34 skipping to change at page 1, line 34
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 28 January 2021. This Internet-Draft will expire on 6 February 2021.
Copyright Notice Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the Copyright (c) 2020 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 (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 20 skipping to change at page 2, line 20
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. The RPL DODAG Configuration Option . . . . . . . . . . . . . 4 3. The RPL DODAG Configuration Option . . . . . . . . . . . . . 4
4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 5 4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 5
5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5 5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5
5.1. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 6 5.1. Coexistence . . . . . . . . . . . . . . . . . . . . . . . 6
5.2. Inconsistent State While Migrating . . . . . . . . . . . 6 5.2. Inconsistent State While Migrating . . . . . . . . . . . 6
5.3. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6 5.3. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7
7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 8 10. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
The packet compression technique defined in [RFC8138] can only be The packet compression technique defined in [RFC8138] can only be
activated in a RPL [RFC6550] network when all the nodes support it. activated in a RPL [RFC6550] network when all the nodes support it.
Otherwise, a non-capable node acting as leaf-only would fail to Otherwise, a non-capable node acting as leaf-only would fail to
communicate, and acting as a router it would drop the compressed communicate, and acting as a router it would drop the compressed
packets and black-hole a portion of the network. packets and black-hole a portion of the network.
skipping to change at page 3, line 9 skipping to change at page 3, line 9
The idea is to use the flag to maintain the compression inactive The idea is to use the flag to maintain the compression inactive
during the migration phase. When the migration is complete (e.g., as during the migration phase. When the migration is complete (e.g., as
known by network management and/or inventory), the flag is set and known by network management and/or inventory), the flag is set and
the compression is globally activated in the whole DODAG. the compression is globally activated in the whole DODAG.
2. Terminology 2. Terminology
2.1. References 2.1. References
The Terminology used in this document is consistent with and The terminology used in this document is consistent with and
incorporates that described in "Terms Used in Routing for Low-Power incorporates that described in "Terms Used in Routing for Low-Power
and Lossy Networks (LLNs)" [RFC7102]. Other terms in use in LLNs are and Lossy Networks (LLNs)" [RFC7102]. Other terms in use in LLNs are
found in "Terminology for Constrained-Node Networks" [RFC7228]. found in "Terminology for Constrained-Node Networks" [RFC7228].
"RPL", the "RPL Packet Information" (RPI), "RPL Instance" (indexed by "RPL", the "RPL Packet Information" (RPI), and "RPL Instance"
a RPLInstanceID) are defined in "RPL: IPv6 Routing Protocol for (indexed by a RPLInstanceID) are defined in "RPL: IPv6 Routing
Low-Power and Lossy Networks" [RFC6550]. The RPI is the abstract Protocol for Low-Power and Lossy Networks" [RFC6550]. The RPI is the
information that RPL defines to be placed in data packets, e.g., as abstract information that RPL defines to be placed in data packets,
the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header. By e.g., as the RPL Option [RFC6553] within the IPv6 Hop-By-Hop Header.
extension the term "RPI" is often used to refer to the RPL Option By extension the term "RPI" is often used to refer to the RPL Option
itself. The DODAG Information Solicitation (DIS), Destination itself. The DODAG Information Solicitation (DIS), Destination
Advertisement Object (DAO) and DODAG Information Object (DIO) Advertisement Object (DAO) and DODAG Information Object (DIO)
messages are also specified in [RFC6550]. messages are also specified in [RFC6550].
This document uses the terms RPL-Unaware Leaf (RUL) and RPL Aware This document uses the terms RPL-Unaware Leaf (RUL) and RPL-Aware
Leaf (RAL) consistently with "Using RPI Option Type, Routing Header Leaf (RAL) consistently with "Using RPI Option Type, Routing Header
for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data for Source Routes and IPv6-in-IPv6 encapsulation in the RPL Data
Plane" [USEofRPLinfo]. The term RPL-Aware Node (RAN) refers to a Plane" [USEofRPLinfo]. The term RPL-Aware Node (RAN) refers to a
node that is either a RAL or a RPL Router. A RAN manages the node that is either a RAL or a RPL Router. A RAN manages the
reachability of its addresses and prefixes by injecting them in RPL reachability of its addresses and prefixes by injecting them in RPL
by itself. In contrast, a RUL leverages "Registration Extensions for by itself. In contrast, a RUL leverages "Registration Extensions for
IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor IPv6 over Low-Power Wireless Personal Area Network (6LoWPAN) Neighbor
Discovery" [RFC8505] to obtain reachability services from its parent Discovery" [RFC8505] to obtain reachability services from its parent
router(s) as specified in "Routing for RPL Leaves" [UNAWARE-LEAVES]. router(s) as specified in "Routing for RPL Leaves" [UNAWARE-LEAVES].
skipping to change at page 4, line 49 skipping to change at page 4, line 49
The suggested bit position of the "T" flag is indicated in Section 6. The suggested bit position of the "T" flag is indicated in Section 6.
[RFC6550] states, when referring to the DODAG Configuration Option, [RFC6550] states, when referring to the DODAG Configuration Option,
that "Nodes other than the DODAG Root MUST NOT modify this that "Nodes other than the DODAG Root MUST NOT modify this
information when propagating the DODAG Configuration option". information when propagating the DODAG Configuration option".
Therefore, a legacy parent propagates the "T" flag as set by the Root Therefore, a legacy parent propagates the "T" flag as set by the Root
whether it supports this specification or not. So when the "T" flag whether it supports this specification or not. So when the "T" flag
is set, it is transparently flooded to all the nodes in the DODAG. is set, it is transparently flooded to all the nodes in the DODAG.
Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
the DIO Base Object. For MOP values 0 to 6, the use of compression the DIO Base Object. This specification applies to MOP values 0 to
depends on the "T" flag as specified in this document. A MOP value 6. For a MOP value of 7, the compression MUST be used by default
of 7 and above MUST use compression by default and ignore the setting regardless of the setting of the "T" flag.
of the "T" flag.
4. Updating RFC 8138 4. Updating RFC 8138
A node SHOULD source packets in the compressed form using [RFC8138] A node SHOULD source packets in the compressed form using [RFC8138]
if and only if the "T" flag is set. This behaviour can be overridden if and only if the "T" flag is set. This behaviour can be overridden
by e.g., configuration or network management. Overriding may be by e.g., configuration or network management. Overriding may be
needed e.g., to cope with a legacy implementations of the Root that needed e.g., to cope with a legacy implementation of the Root that
supports [RFC8138] but not this specification and cannot set the "T" supports [RFC8138] but not this specification and cannot set the "T"
flag. flag.
The decision of using [RFC8138] is made by the originator of the The decision of using [RFC8138] is made by the originator of the
packet depending on its capabilities and its knowledge of the state packet depending on its capabilities and its knowledge of the state
of the "T" flag. A router that encapsulates a packet is the of the "T" flag. A router that encapsulates a packet is the
originator of the resulting packet and is responsible to compress the originator of the resulting packet and is responsible to compress the
outer headers with [RFC8138], but it MUST leave the encapsulated outer headers with [RFC8138], but it MUST leave the encapsulated
packet as is. packet as is.
An external target [USEofRPLinfo] is not expected to support An external target [USEofRPLinfo] is not expected to support
[RFC8138]. In most cases, packets from/to an external target are [RFC8138]. In most cases, packets from and to an external target are
tunneled back and forth between the RPL border router and the Root tunneled back and forth between the border router (referred to as
regardless of the MOP used in the RPL DODAG. The inner packet is 6LR) that serves the external target and the Root, regardless of the
typically not compressed with [RFC8138] so the 6LR just needs to MOP used in the RPL DODAG. The inner packet is typically not
decapsulate the (compressed) outer header and forward the compressed with [RFC8138], so for outgoing packets, the border router
(uncompressed) inner packet towards the external target. just needs to decapsulate the (compressed) outer header and forward
the (uncompressed) inner packet towards the external target.
A router MUST uncompress a packet that is to be forwarded to an A router MUST uncompress a packet that is to be forwarded to an
external target. Otherwise, the router MUST forward the packet in external target. Otherwise, the router MUST forward the packet in
the form that the source used, either compressed or uncompressed. the form that the source used, either compressed or uncompressed.
A RUL [UNAWARE-LEAVES] is both a leaf and an external target . A RUL A RUL [UNAWARE-LEAVES] is both a leaf and an external target. A RUL
does not participate in RPL and depends on the parent router to does not participate in RPL and depends on the parent router to
obtain connectivity. In the case of a RUL, forwarding towards an obtain connectivity. In the case of a RUL, forwarding towards an
external target actually means delivering the packet. external target actually means delivering the packet.
5. Transition Scenarios 5. Transition Scenarios
A node that supports [RFC8138] but not this specification can only be A node that supports [RFC8138] but not this specification can only be
used in an homogeneous network. Enabling the [RFC8138] compression used in an homogeneous network. Enabling the [RFC8138] compression
requires a "flag day"; all nodes must be upgraded, and then the without a turn-on signaling requires a "flag day"; all nodes must be
network can be rebooted with the [RFC8138] compression turned on. upgraded, and then the network can be rebooted with the [RFC8138]
compression turned on.
The intent for this specification is to perform a migration once and The intent for this specification is to perform a migration once and
for all without the need for a flag day. In particular it is not the for all without the need for a flag day. In particular it is not the
intention to undo the setting of the "T" flag. Though it is possible intention to undo the setting of the "T" flag. Though it is possible
to roll back (see Section 5.3), adding nodes that do not support to roll back (see Section 5.3), adding nodes that do not support
[RFC8138] after a roll back may be problematic if the roll back did [RFC8138] after a roll back may be problematic if the roll back did
not fully complete. not fully complete.
5.1. Coexistence 5.1. Coexistence
skipping to change at page 7, line 44 skipping to change at page 7, line 44
Setting and resetting the "T" flag may create inconsistencies in the Setting and resetting the "T" flag may create inconsistencies in the
network but as long as all nodes are upgraded to [RFC8138] support network but as long as all nodes are upgraded to [RFC8138] support
they will be able to forward both forms. The source is responsible they will be able to forward both forms. The source is responsible
for selecting whether the packet is compressed or not, and all for selecting whether the packet is compressed or not, and all
routers must use the format that the source selected. So the result routers must use the format that the source selected. So the result
of an inconsistency is merely that both forms will be present in the of an inconsistency is merely that both forms will be present in the
network, at an additional cost of bandwidth for packets in the network, at an additional cost of bandwidth for packets in the
uncompressed form. uncompressed form.
An attacker in the middle of the network may reset the "T" flag to
cause extra energy spending in its subDAG. Conversely it may set the
"T" flag, so that nodes located downstream would compress when that
it is not desired, potentially resulting in the loss of packets. In
a tree structure, the attacker would be in position to drop the
packets from and to the attacked nodes. So the attacks above would
be more complex and more visible than simply dropping selected
packets. The downstream node may have other parents and see both
settings, which could raise attention.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Alvaro Retana, Dominique Barthel and Rahul The authors wish to thank Carles Gomez, Alvaro Retana, Dominique
Jadhav for their in-depth reviews and constructive suggestions. Barthel and Rahul Jadhav for their in-depth reviews and constructive
suggestions.
Also many thanks to Michael Richardson for being always helpful and Also many thanks to Michael Richardson for being always helpful and
responsive when need comes. responsive when need comes.
9. Normative References 9. 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>.
 End of changes. 14 change blocks. 
31 lines changed or deleted 43 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/