draft-ietf-roll-turnon-rfc8138-15.txt   draft-ietf-roll-turnon-rfc8138-16.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: 8138 (if approved) Cisco Systems
Intended status: Standards Track 18 September 2020 Intended status: Standards Track 24 September 2020
Expires: 22 March 2021 Expires: 28 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-15 draft-ietf-roll-turnon-rfc8138-16
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 unset. when the bit is set and unset.
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 22 March 2021. This Internet-Draft will expire on 28 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 12 skipping to change at page 2, line 12
as described in Section 4.e of the Trust Legal Provisions and are as described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Simplified BSD License. provided without warranty as described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. References . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4 2.3. Requirements Language . . . . . . . . . . . . . . . . . . 4
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 3. Extending RFC 6550 . . . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 8 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8 9. Normative References . . . . . . . . . . . . . . . . . . . . 8
10. Informative References . . . . . . . . . . . . . . . . . . . 9 10. Informative References . . . . . . . . . . . . . . . . . . . 9
skipping to change at page 4, line 13 skipping to change at page 4, line 13
SRH: Source Routing Header SRH: Source Routing Header
2.3. Requirements Language 2.3. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all 14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
3. Updating RFC 6550 3. Extending RFC 6550
The DODAG Configuration Option is defined in Section 6.7.6 of The DODAG Configuration Option is defined in Section 6.7.6 of
[RFC6550]. Its purpose is extended to distribute configuration [RFC6550]. Its purpose is extended to distribute configuration
information affecting the construction and maintenance of the DODAG, information affecting the construction and maintenance of the DODAG,
as well as operational parameters for RPL on the DODAG, through the as well as operational parameters for RPL on the DODAG, through the
DODAG. As shown in Figure 1, the Option was originally designed with DODAG. As shown in Figure 1, the Option was originally designed with
4 bit positions reserved for future use as Flags. 4 bit positions reserved for future use as Flags.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
skipping to change at page 4, line 37 skipping to change at page 4, line 37
Figure 1: DODAG Configuration Option (Partial View) Figure 1: DODAG Configuration Option (Partial View)
This specification defines a new flag "Enable RFC8138 Compression" This specification defines a new flag "Enable RFC8138 Compression"
(T). The "T" flag is set to turn-on the use of [RFC8138] within the (T). The "T" flag is set to turn-on the use of [RFC8138] within the
DODAG. The "T" flag is encoded in position 2 of the reserved Flags DODAG. The "T" flag is encoded in position 2 of the reserved Flags
in the DODAG Configuration Option (counting from bit 0 as the most in the DODAG Configuration Option (counting from bit 0 as the most
significant bit) and set to 0 in legacy implementations as specified significant bit) and set to 0 in legacy implementations as specified
respectively in Sections 20.14 and 6.7.6 of [RFC6550]. respectively in Sections 20.14 and 6.7.6 of [RFC6550].
Section 4.3 of [USEofRPLinfo] updates [RFC6550] to indicate that the
definition of the Flags applies to Mode of Operation (MOP) values
zero (0) to six (6) only, leaving the flags reserved for MOP value
seven (7). For a MOP value of 7, the bit in position 2 is considered
unallocated and [RFC8138] MUST be used on Links where 6LoWPAN Header
Compression [RFC6282] applies and MUST NOT be used otherwise.
The RPL DODAG Configuration Option is typically placed in a DODAG The RPL DODAG Configuration Option is typically placed in a DODAG
Information Object (DIO) message. The DIO message propagates down Information Object (DIO) message. The DIO message propagates down
the DODAG to form and then maintain its structure. The DODAG the DODAG to form and then maintain its structure. The DODAG
Configuration Option is copied unmodified from parents to children. Configuration Option is copied unmodified from parents to children.
Section 6.3.1 of [RFC6550] defines a 3-bit Mode of Operation (MOP) in
the DIO Base Object. This specification applies to MOP values 0 to
6. For a MOP value of 7, the bit in position 2 is considered
unallocated and [RFC8138] MUST be used by default.
[RFC6550] states that "Nodes other than the DODAG Root MUST NOT [RFC6550] states that "Nodes other than the DODAG Root MUST NOT
modify this information when propagating the DODAG Configuration modify this information when propagating the DODAG Configuration
option". Therefore, a legacy parent propagates the "T" flag as set option". Therefore, a legacy parent propagates the "T" flag as set
by the Root whether it supports this specification or not. So when by the Root, and when the "T" flag is set, it is transparently
the "T" flag is set, it is transparently flooded to all the nodes in flooded to all the nodes in the DODAG.
the DODAG.
4. Updating RFC 8138 4. Updating RFC 8138
A node SHOULD generate packets in the compressed form using [RFC8138] A node SHOULD generate packets in the compressed form using [RFC8138]
if and only if the "T" flag is set. This behavior can be overridden if and only if the "T" flag is set. This behavior can be overridden
by configuration or network management. Overriding may be needed by configuration or network management. Overriding may be needed
e.g., to turn on the compression in a network where all nodes support e.g., to turn on the compression in a network where all nodes support
[RFC8138] but the Root does not support this specification and cannot [RFC8138] but the Root does not support this specification and cannot
set the "T" flag, or to disable it locally in case of a problem. set the "T" flag, or to disable it locally in case of a problem.
skipping to change at page 9, line 13 skipping to change at page 9, line 13
<https://www.rfc-editor.org/info/rfc8505>. <https://www.rfc-editor.org/info/rfc8505>.
[UNAWARE-LEAVES] [UNAWARE-LEAVES]
Thubert, P. and M. Richardson, "Routing for RPL Leaves", Thubert, P. and M. Richardson, "Routing for RPL Leaves",
Work in Progress, Internet-Draft, draft-ietf-roll-unaware- Work in Progress, Internet-Draft, draft-ietf-roll-unaware-
leaves-18, 12 June 2020, <https://tools.ietf.org/html/ leaves-18, 12 June 2020, <https://tools.ietf.org/html/
draft-ietf-roll-unaware-leaves-18>. draft-ietf-roll-unaware-leaves-18>.
10. Informative References 10. Informative References
[RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6
Datagrams over IEEE 802.15.4-Based Networks", RFC 6282,
DOI 10.17487/RFC6282, September 2011,
<https://www.rfc-editor.org/info/rfc6282>.
[RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low- [RFC6553] Hui, J. and JP. Vasseur, "The Routing Protocol for Low-
Power and Lossy Networks (RPL) Option for Carrying RPL Power and Lossy Networks (RPL) Option for Carrying RPL
Information in Data-Plane Datagrams", RFC 6553, Information in Data-Plane Datagrams", RFC 6553,
DOI 10.17487/RFC6553, March 2012, DOI 10.17487/RFC6553, March 2012,
<https://www.rfc-editor.org/info/rfc6553>. <https://www.rfc-editor.org/info/rfc6553>.
[RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for
Constrained-Node Networks", RFC 7228, Constrained-Node Networks", RFC 7228,
DOI 10.17487/RFC7228, May 2014, DOI 10.17487/RFC7228, May 2014,
<https://www.rfc-editor.org/info/rfc7228>. <https://www.rfc-editor.org/info/rfc7228>.
 End of changes. 9 change blocks. 
16 lines changed or deleted 21 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/