draft-ietf-roll-turnon-rfc8138-13.txt   draft-ietf-roll-turnon-rfc8138-14.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 September 7, 2020 Intended status: Standards Track September 8, 2020
Expires: March 11, 2021 Expires: March 12, 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-13 draft-ietf-roll-turnon-rfc8138-14
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 March 11, 2021. This Internet-Draft will expire on March 12, 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 5, line 49 skipping to change at page 5, line 49
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
without a turn-on signaling method requires a "flag day"; by which without a turn-on signaling method requires a "flag day"; by which
time all nodes must be upgraded, and at which point the network can time all nodes must be upgraded, and at which point the network can
be rebooted with the [RFC8138] compression turned on. 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, the network operator SHOULD ensure
[RFC8138] after a roll back may be problematic if the roll back did that the roll back operation is completed before adding nodes that do
not fully complete. not support [RFC8138].
5.1. Coexistence 5.1. Coexistence
A node that supports this specification can operate in a network with A node that supports this specification can operate in a network with
the [RFC8138] compression turned on or off with the "T" flag set the [RFC8138] compression turned on or off with the "T" flag set
accordingly and in a network in transition from off to on or on to accordingly and in a network in transition from off to on or on to
off (see Section 5.2). off (see Section 5.2).
A node that does not support [RFC8138] can interoperate with nodes A node that does not support [RFC8138] can interoperate with nodes
that do in a network with [RFC8138] compression turned off. If the that do in a network with [RFC8138] compression turned off. If the
skipping to change at page 8, line 9 skipping to change at page 8, line 9
structure, the attacker would be in position to drop the packets from structure, the attacker would be in position to drop the packets from
and to the attacked nodes. So the attacks above would be more and to the attacked nodes. So the attacks above would be more
complex and more visible than simply dropping selected packets. The complex and more visible than simply dropping selected packets. The
downstream node may have other parents and see both settings, which downstream node may have other parents and see both settings, which
could raise attention. could raise attention.
8. Acknowledgments 8. Acknowledgments
The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry The authors wish to thank Murray Kucherawy, Meral Shirazipour, Barry
Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant, Leiba, Tirumaleswar Reddy, Nagendra Kumar Nainar, Stewart Bryant,
Carles Gomez, and especially Alvaro Retana, Dominique Barthel and Carles Gomez, Eric Vyncke, and especially 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. 5 change blocks. 
9 lines changed or deleted 10 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/