draft-ietf-roll-turnon-rfc8138-11.txt   draft-ietf-roll-turnon-rfc8138-12.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 August 2020 Intended status: Standards Track 2 September 2020
Expires: 28 February 2021 Expires: 6 March 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-11 draft-ietf-roll-turnon-rfc8138-12
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 February 2021. This Internet-Draft will expire on 6 March 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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 9 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 design of Low Power and Lossy Networks (LLNs) is generally
activated in a RPL [RFC6550] network when all the nodes support it. focused on saving energy, which is the most constrained resource of
Otherwise, if acting as a leaf, a node that does not support the all. The routing optimizations in the "Routing Protocol for Low
compression would fail to communicate; if acting as a router it would Power and Lossy Networks" [RFC6550] (RPL) such as routing along a
drop the compressed packets and black-hole a portion of the network. Destination-Oriented Directed Acyclic Graph (DODAG) to a Root Node
and the associated packet compression technique [RFC8138] derive from
that primary concern.
The original idea was to use a flag day but that proved impractical Enabling [RFC8138] requires a Flag Day where the network is upgraded
in a number of situations such as a large metering network that is and rebooted. Otherwise, if acting as a Leaf, a node that does not
used in production and incurs financial losses when interrupted. support the compression would fail to communicate; if acting as a
router it would drop the compressed packets and black-hole a portion
of the network. This specification enables a hot upgrade where a
live network is migrated. During the migration, the compression
remains inactive, until all nodes are upgraded.
This specification is designed for the scenario where a live network
is upgraded to support [RFC8138]. During the migration, the
compression should remain inactive, until all nodes are upgraded.
This document complements [RFC8138] and dedicates a flag in the RPL This document complements [RFC8138] and dedicates a flag in the RPL
DODAG Configuration Option to indicate whether the [RFC8138] DODAG Configuration Option to indicate whether the [RFC8138]
compression should be used within the RPL DODAG. compression should be used within the RPL DODAG. The setting of this
new flag is controlled by the Root and propagates as is in the whole
The setting of this new flag is controlled by the Root and propagates network as part of the normal RPL signaling.
as is in the whole network as part of the normal RPL signaling.
The flag is cleared to maintain the compression inactive during the The flag is cleared to maintain the compression inactive during the
migration phase. When the migration is complete (e.g., as known by migration phase. When the migration is complete (e.g., as known by
network management and/or inventory), the flag is set and the network management and/or inventory), the flag is set and the
compression is globally activated in the whole DODAG. compression is globally activated in the whole DODAG.
2. Terminology 2. Terminology
2.1. References 2.1. References
skipping to change at page 6, line 50 skipping to change at page 6, line 50
are upgraded to support this specification. are upgraded to support this specification.
5.3. Rolling Back 5.3. Rolling Back
When turning [RFC8138] compression off in the network, the Network When turning [RFC8138] compression off in the network, the Network
Administrator MUST wait until all nodes have converged to the "T" Administrator MUST wait until all nodes have converged to the "T"
flag reset before allowing nodes that do not support the compression flag reset before allowing nodes that do not support the compression
in the network. To that effect, whether the compression is active in in the network. To that effect, whether the compression is active in
a node SHOULD be exposed the node's management interface. a node SHOULD be exposed the node's management interface.
It is RECOMMENDED to only deploy nodes that support [RFC8138] in a Nodes that do not support [RFC8138] SHOULD NOT be deployed in a
network where the compression is turned on. A node that does not network where the compression is turned on. If that is done, the
support [RFC8138] MUST only be used as a RUL. node can only operate as a RUL.
6. IANA Considerations 6. IANA Considerations
IANA is requested to assign a new option flag from the Registry for IANA is requested to assign a new option flag from the Registry for
the "DODAG Configuration Option Flags" that was created for [RFC6550] the "DODAG Configuration Option Flags" that was created for [RFC6550]
as follows: as follows:
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
| Bit Number | Capability Description | Reference | | Bit Number | Capability Description | Reference |
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
| 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC | | 2 (suggested) | Turn on RFC8138 Compression (T) | THIS RFC |
+---------------+---------------------------------+-----------+ +---------------+---------------------------------+-----------+
Table 1: New DODAG Configuration Option Flag Table 1: New DODAG Configuration Option Flag
7. Security Considerations 7. Security Considerations
First of all, it is worth noting that with [RFC6550], every node in It is worth noting that with RPL [RFC6550], every node in the LLN
the LLN that is RPL-aware can inject any RPL-based attack in the that is RPL-aware can inject any RPL-based attack in the network.
network. A trust model is REQUIRED in an effort to exclude rogue This document applies typically to an existing deployment and does
nodes from participating to the RPL and the 6LoWPAN signaling, as not change its security requirements and operations. It is assumed
well as from the data packet exchange. This trust model could at a that the security mechanisms as defined for RPL are followed.
minimum be based on a Layer-2 Secure joining and the Link-Layer
security. This is a generic RPL and 6LoWPAN requirement, see Req5.1
in Appendix of [RFC8505].
Setting the "T" flag before all routers are upgraded may cause a loss Setting the "T" flag before all routers are upgraded may cause a loss
of packets. The new bit is protected as the rest of the of packets. The new bit is protected as the rest of the
configuration so this is just one of the many attacks that can happen configuration so this is just one of the many attacks that can happen
if an attacker manages to inject a corrupted configuration. if an attacker manages to inject a corrupted configuration.
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
skipping to change at page 8, line 7 skipping to change at page 8, line 7
"T" flag, so that nodes located downstream would compress when that "T" flag, so that nodes located downstream would compress when that
it is not desired, potentially resulting in the loss of packets. In it is not desired, potentially resulting in the loss of packets. In
a tree structure, the attacker would be in position to drop the a tree structure, the attacker would be in position to drop the
packets from and to the attacked nodes. So the attacks above would packets from and to the attacked nodes. So the attacks above would
be more complex and more visible than simply dropping selected be more complex and more visible than simply dropping selected
packets. The downstream node may have other parents and see both packets. The downstream node may have other parents and see both
settings, which could raise attention. settings, which could raise attention.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Meral Shirazipour, Nagendra Kumar Nainar, The authors wish to thank Meral Shirazipour, Barry Leiba, Nagendra
Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique Barthel and Kumar Nainar, Stewart Bryant, Carles Gomez, Alvaro Retana, Dominique
Rahul 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. 10 change blocks. 
33 lines changed or deleted 33 lines changed or added

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