< draft-ietf-roll-turnon-rfc8138-06.txt   draft-ietf-roll-turnon-rfc8138-07.txt >
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft L. Zhao Internet-Draft L. Zhao
Updates: 6550, 8138 (if approved) Cisco Systems Updates: 6550, 8138 (if approved) Cisco Systems
Intended status: Standards Track 15 April 2020 Intended status: Standards Track 17 April 2020
Expires: 17 October 2020 Expires: 19 October 2020
A RPL Configuration Option for the 6LoWPAN Routing Header A RPL Configuration Option for the 6LoWPAN Routing Header
draft-ietf-roll-turnon-rfc8138-06 draft-ietf-roll-turnon-rfc8138-07
Abstract Abstract
This document complements RFC 8138 and dedicates a bit in the RPL This document updates RFC 8138 and RFC 6550 by defining a bit in the
configuration option defined in RFC 6550 to indicate whether RFC 8138 RPL configuration option to indicate whether RFC 8138 compression is
compression is used within the RPL Instance. 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 Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 17 October 2020. This Internet-Draft will expire on 19 October 2020.
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 18 skipping to change at page 2, line 18
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4
4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 4 4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 4
5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5 5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 5
5.1. Inconsistent State While Migrating . . . . . . . . . . . 6 5.1. Inconsistent State While Migrating . . . . . . . . . . . 6
5.2. Single RPL Instance Scenario . . . . . . . . . . . . . . 6 5.2. Single RPL Instance Scenario . . . . . . . . . . . . . . 6
5.3. Double RPL Instances Scenario . . . . . . . . . . . . . . 7 5.3. Double RPL Instances Scenario . . . . . . . . . . . . . . 7
5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 7 5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 8
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
7. Security Considerations . . . . . . . . . . . . . . . . . . . 8 7. Security Considerations . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 9
10. Informative References . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The transition of a RPL [RFC6550] network to activate the compression The transition of a RPL [RFC6550] network to activate the compression
defined in [RFC8138] can only be done when all routers in the network 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 support it. Otherwise, a non-capable node acting as a router would
drop the compressed packets and black-hole its subDAG. In a mixed drop the compressed packets and black-hole its subDAG. In a mixed
case with both RFC8138-capable and non-capable nodes, the compression case with both RFC8138-capable and non-capable nodes, the compression
skipping to change at page 7, line 43 skipping to change at page 7, line 43
the new RPL Instance for the traffic that they source. By contrast, the new RPL Instance for the traffic that they source. By contrast,
nodes that only support the uncompressed format would either not be nodes that only support the uncompressed format would either not be
configured for the new RPL Instance, or would be configured to join configured for the new RPL Instance, or would be configured to join
it as leaves only. it as leaves only.
This method eliminates the risks of nodes being stalled that are This method eliminates the risks of nodes being stalled that are
described in Section 5.2 but requires implementations to support at described in Section 5.2 but requires implementations to support at
least two RPL Instances and demands management capabilities to least two RPL Instances and demands management capabilities to
introduce new RPL Instances and deprecate old ones. 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 5.4. Rolling Back
After downgrading a network to turn the [RFC8138] compression off, After downgrading a network to turn the [RFC8138] compression off,
the administrator SHOULD make sure that all nodes have converged to the administrator SHOULD make sure that all nodes have converged to
the "T" flag reset before allowing nodes that do not support the the "T" flag reset before allowing nodes that do not support the
compression in the network (see caveats in Section 5.2). compression in the network (see caveats in Section 5.2).
It is RECOMMENDED to only deploy nodes that support [RFC8138] in a It is RECOMMENDED to only deploy nodes that support [RFC8138] in a
network where the compression is turned on. A node that does not network where the compression is turned on. A node that does not
support [RFC8138] MUST only be used as a leaf. support [RFC8138] MUST only be used as a leaf.
 End of changes. 7 change blocks. 
10 lines changed or deleted 19 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/