--- 1/draft-ietf-roll-turnon-rfc8138-06.txt	2020-04-17 10:13:08.385721954 -0700
+++ 2/draft-ietf-roll-turnon-rfc8138-07.txt	2020-04-17 10:13:08.445723477 -0700
@@ -1,42 +1,43 @@
 
 ROLL                                                     P. Thubert, Ed.
 Internet-Draft                                                   L. Zhao
 Updates: 6550, 8138 (if approved)                          Cisco Systems
-Intended status: Standards Track                           15 April 2020
-Expires: 17 October 2020
+Intended status: Standards Track                           17 April 2020
+Expires: 19 October 2020
 
        A RPL Configuration Option for the 6LoWPAN Routing Header
-                   draft-ietf-roll-turnon-rfc8138-06
+                   draft-ietf-roll-turnon-rfc8138-07
 
 Abstract
 
-   This document complements RFC 8138 and dedicates a bit in the RPL
-   configuration option defined in RFC 6550 to indicate whether RFC 8138
-   compression is used within the RPL Instance.
+   This document updates RFC 8138 and RFC 6550 by defining a bit in the
+   RPL configuration option to indicate whether RFC 8138 compression is
+   used within the RPL Instance, and specify the behavior of RFC
+   8138-capable nodes when the bit is set and reset.
 
 Status of This Memo
 
    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.
 
    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at https://datatracker.ietf.org/drafts/current/.
 
    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
 
-   This Internet-Draft will expire on 17 October 2020.
+   This Internet-Draft will expire on 19 October 2020.
 
 Copyright Notice
 
    Copyright (c) 2020 IETF Trust and the persons identified as the
    document authors.  All rights reserved.
 
    This document is subject to BCP 78 and the IETF Trust's Legal
    Provisions Relating to IETF Documents (https://trustee.ietf.org/
    license-info) in effect on the date of publication of this document.
    Please review these documents carefully, as they describe your rights
@@ -51,25 +52,25 @@
    2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
      2.1.  References  . . . . . . . . . . . . . . . . . . . . . . .   3
      2.2.  Glossary  . . . . . . . . . . . . . . . . . . . . . . . .   3
      2.3.  BCP 14  . . . . . . . . . . . . . . . . . . . . . . . . .   4
    3.  Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . .   4
    4.  Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . .   4
    5.  Transition Scenarios  . . . . . . . . . . . . . . . . . . . .   5
      5.1.  Inconsistent State While Migrating  . . . . . . . . . . .   6
      5.2.  Single RPL Instance Scenario  . . . . . . . . . . . . . .   6
      5.3.  Double RPL Instances Scenario . . . . . . . . . . . . . .   7
-     5.4.  Rolling Back  . . . . . . . . . . . . . . . . . . . . . .   7
+     5.4.  Rolling Back  . . . . . . . . . . . . . . . . . . . . . .   8
    6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   8
    7.  Security Considerations . . . . . . . . . . . . . . . . . . .   8
-   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   8
-   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   8
+   8.  Acknowledgments . . . . . . . . . . . . . . . . . . . . . . .   9
+   9.  Normative References  . . . . . . . . . . . . . . . . . . . .   9
    10. Informative References  . . . . . . . . . . . . . . . . . . .   9
    Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  10
 
 1.  Introduction
 
    The transition of a RPL [RFC6550] network to activate the compression
    defined in [RFC8138] can only be done when all routers in the network
    support it.  Otherwise, a non-capable node acting as a router would
    drop the compressed packets and black-hole its subDAG.  In a mixed
    case with both RFC8138-capable and non-capable nodes, the compression
@@ -319,20 +320,28 @@
    the new RPL Instance for the traffic that they source.  By contrast,
    nodes that only support the uncompressed format would either not be
    configured for the new RPL Instance, or would be configured to join
    it as leaves only.
 
    This method eliminates the risks of nodes being stalled that are
    described in Section 5.2 but requires implementations to support at
    least two RPL Instances and demands management capabilities to
    introduce new RPL Instances and deprecate old ones.
 
+   The 2 instances MUST be operated with the same security guarantees,
+   e.g., both "unsecured" with a lower layer security of a same
+   strength, both "preinstalled" or both "authenticated" security mode
+   (see section 3.2.3 of [RFC6550] for more details on those modes).
+   The latter mode could be use to enforce the segregation of updated
+   and non-updated nodes, by providing the keys for joining as routers
+   to the updated nodes only.
+
 5.4.  Rolling Back
 
    After downgrading a network to turn the [RFC8138] compression off,
    the administrator SHOULD make sure that all nodes have converged to
    the "T" flag reset before allowing nodes that do not support the
    compression in the network (see caveats in Section 5.2).
 
    It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
    network where the compression is turned on.  A node that does not
    support [RFC8138] MUST only be used as a leaf.