draft-ietf-roll-turnon-rfc8138-01.txt   draft-ietf-roll-turnon-rfc8138-02.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 December 12, 2019 Intended status: Standards Track 12 December 2019
Expires: June 14, 2020 Expires: 14 June 2020
Configuration option for RFC 8138 Configuration option for RFC 8138
draft-ietf-roll-turnon-rfc8138-01 draft-ietf-roll-turnon-rfc8138-02
Abstract Abstract
This document complements RFC 8138 and dedicates a bit in the RPL This document complements RFC 8138 and dedicates a bit in the RPL
configuration option defined in RFC 6550 to indicate whether RFC 8138 configuration option defined in RFC 6550 to indicate whether RFC 8138
compression is used within the RPL instance. compression is used within the RPL instance.
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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 June 14, 2020. This Internet-Draft will expire on 14 June 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2019 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 Provisions Relating to IETF Documents (https://trustee.ietf.org/
(https://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as provided without warranty as described in the Simplified BSD License.
described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. BCP 14 . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 2 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 2
4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 3 4. Updating RFC 8138 . . . . . . . . . . . . . . . . . . . . . . 3
5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 3 5. Transition Scenarios . . . . . . . . . . . . . . . . . . . . 3
5.1. Inconsistent State While Migrating . . . . . . . . . . . 4 5.1. Inconsistent State While Migrating . . . . . . . . . . . 4
5.2. Single Instance Scenario . . . . . . . . . . . . . . . . 5 5.2. Single Instance Scenario . . . . . . . . . . . . . . . . 5
5.3. Double Instance Scenario . . . . . . . . . . . . . . . . 5 5.3. Double Instance Scenario . . . . . . . . . . . . . . . . 6
5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6 5.4. Rolling Back . . . . . . . . . . . . . . . . . . . . . . 6
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9. Normative References . . . . . . . . . . . . . . . . . . . . 7
9.1. Normative References . . . . . . . . . . . . . . . . . . 7 10. Informative References . . . . . . . . . . . . . . . . . . . 7
9.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction 1. Introduction
The transition to [RFC8138] in a network can only be done when all The transition to [RFC8138] in a network can only be done when all
nodes support the specification. In a mixed case with both nodes support the specification. In a mixed case with both
RFC8138-capable and non-capable nodes, the compression should be RFC8138-capable and non-capable nodes, the compression should be
turned off. turned off.
This document complements RFC 8138 and dedicates a bit in the RPL This document complements RFC 8138 and dedicates a bit in the RPL
configuration option to indicate whether RFC 8138 compression should configuration option to indicate whether RFC 8138 compression should
skipping to change at page 2, line 51 skipping to change at page 2, line 50
"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. Updating RFC 6550
RPL defines a configuration option that is registered to IANA in RPL defines a configuration option that is registered to IANA in
section 20.14. of [RFC6550]. This specification defines a new flag section 20.14. of [RFC6550]. This specification defines a new flag
"Enable RFC8138 Compression" (T) that is encoded in one of the "Enable RFC8138 Compression" (T) that is encoded in one of the
reserved control bits in the option. The new flag is set to turn on reserved control bits in the option. The new flag is set to turn on
the use of the compression of RPL artifacts with RFC 8138. the use of the compression of RPL artifacts with RFC 8138. The bit
position of the "T" flag is indicated in Section 6.
Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP) Section 6.3.1. of [RFC6550] defines a 3-bit Mode of Operation (MOP)
in the DIO Base Object. The new "T" flag is defined only for MOP in the DIO Base Object. The new "T" flag is defined only for MOP
value between 0 to 6. For a MOP value of 7 or above, the flag MAY value between 0 to 6. For a MOP value of 7 or above, the flag MAY
indicate something different and MUST NOT be interpreted as "Enable indicate something different and MUST NOT be interpreted as "Enable
RFC8138 Compression" unless the specification of the MOP indicates to RFC8138 Compression" unless the specification of the MOP indicates to
do so. do so.
4. Updating RFC 8138 4. Updating RFC 8138
skipping to change at page 5, line 31 skipping to change at page 5, line 31
migrates to the new OCP. As a result, nodes that do not support RFC migrates to the new OCP. As a result, nodes that do not support RFC
8138 join as leaves and do not forward packets anymore. The leaves 8138 join as leaves and do not forward packets anymore. The leaves
generate packets without compression. The parents - which supports generate packets without compression. The parents - which supports
RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The RFC 8138 - may encapsulate the packets using RFC 8138 if needed. The
other way around, the root encapsulates packets to the leaves all the other way around, the root encapsulates packets to the leaves all the
way to the parent, which decapsulates and distribute the uncompresses way to the parent, which decapsulates and distribute the uncompresses
inner packet to the leaf. inner packet to the leaf.
This scenario presents a number of caveats: This scenario presents a number of caveats:
o The method consumes an extra OCP. It also requires a means to * The method consumes an extra OCP. It also requires a means to
signal the capabilities of the leaf, e.g., using "RPL Mode of signal the capabilities of the leaf, e.g., using "RPL Mode of
Operation extension" [I-D.rahul-roll-mop-ext]. Operation extension" [MOP-EXT].
o If an implementation does not move to a leaf mode when the OCP is * If an implementation does not move to a leaf mode when the OCP is
changed to an unknown one, then the node may be stalled. changed to an unknown one, then the node may be stalled.
o If the only possible parents of a node are nodes that do not * If the only possible parents of a node are nodes that do not
support RFC 8138, then that node will loose all its parent at the support RFC 8138, then that node will loose all its parent at the
time of the migration and it will be stalled until a parent is time of the migration and it will be stalled until a parent is
deployed with the new capability. deployed with the new capability.
o Nodes that only support RFC8138 for forwarding may not parse the * Nodes that only support RFC8138 for forwarding may not parse the
RPI in native form. If such nodes are present, the parent needs RPI in native form. If such nodes are present, the parent needs
to encapsulate with RFC8138. to encapsulate with RFC8138.
5.3. Double Instance Scenario 5.3. Double Instance Scenario
An alternate to the Single Instance Scenario is to deploy an An alternate to the Single Instance Scenario is to deploy an
additional Instance for the nodes that support [RFC8138]. The two additional Instance for the nodes that support [RFC8138]. The two
instances operate as ships-in-the-night as specified in [RFC6550]. instances operate as ships-in-the-night as specified in [RFC6550].
The preexisting Instance that does not use [RFC8138], whereas the new The preexisting Instance that does not use [RFC8138], whereas the new
Instance does. This is signaled by the "T" flag which is only set in Instance does. This is signaled by the "T" flag which is only set in
skipping to change at page 6, line 31 skipping to change at page 6, line 38
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.
6. IANA Considerations 6. IANA Considerations
This specification updates the "Registry for the DODAG Configuration This specification updates the Registry for the "DODAG Configuration
Option Flags" that was created for [RFC6550] as follows: Option Flags" that was created for [RFC6550] as follows:
+---------------+---------------------------------+-----------------+ +------------+---------------------------------+-----------+
| Bit Number | Meaning | Defining Spec | | Bit Number | Capability Description | Reference |
+---------------+---------------------------------+-----------------+ +============+=================================+===========+
| 2 (suggested) | Turn on RFC8138 Compression | This | | 2 | Turn on RFC8138 Compression (T) | THIS RFC |
| | (T) | | +------------+---------------------------------+-----------+
+---------------+---------------------------------+-----------------+
Table 1: New DODAG Configuration Option Flag Table 1: New DODAG Configuration Option Flag
7. Security Considerations 7. Security Considerations
No specific threat was identified with this specification. Turning the "T" flag on before some routers are upgraded may cause a
loss 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
if an attacker manages to inject a corrupted configuration.
Turning the "T" flag on and off may create inconsistencies in the
network but as long as all nodes are upgraded to RFC 8138 support
they will be able to forward both forms. The draft insists that the
source is responsible for selecting whether the packet is compressed
or not, and all routers must use the format that the source selected.
So the result of an inconsistency is merely that both forms will be
present in the network, at an additional cost of bandwidth for
packets in the uncompressed form.
8. Acknowledgments 8. Acknowledgments
9. References
9.1. 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>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J.,
Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur,
JP., and R. Alexander, "RPL: IPv6 Routing Protocol for JP., and R. Alexander, "RPL: IPv6 Routing Protocol for
Low-Power and Lossy Networks", RFC 6550, Low-Power and Lossy Networks", RFC 6550,
DOI 10.17487/RFC6550, March 2012, DOI 10.17487/RFC6550, March 2012,
<https://www.rfc-editor.org/info/rfc6550>. <https://www.rfc-editor.org/info/rfc6550>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 10. Informative References
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
9.2. Informative References
[I-D.rahul-roll-mop-ext]
Jadhav, R. and P. Thubert, "RPL Mode of Operation
extension", draft-rahul-roll-mop-ext-01 (work in
progress), June 2019.
[RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie, [RFC8138] Thubert, P., Ed., Bormann, C., Toutain, L., and R. Cragie,
"IPv6 over Low-Power Wireless Personal Area Network "IPv6 over Low-Power Wireless Personal Area Network
(6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138, (6LoWPAN) Routing Header", RFC 8138, DOI 10.17487/RFC8138,
April 2017, <https://www.rfc-editor.org/info/rfc8138>. April 2017, <https://www.rfc-editor.org/info/rfc8138>.
[MOP-EXT] Jadhav, R., Thubert, P., and M. Richardson, "Mode of
Operation extension and Capabilities", Work in Progress,
Internet-Draft, draft-ietf-roll-mopex-cap-01, 2 November
2019, <https://tools.ietf.org/html/draft-ietf-roll-mopex-
cap-01>.
Authors' Addresses Authors' Addresses
Pascal Thubert (editor) Pascal Thubert (editor)
Cisco Systems, Inc Cisco Systems, Inc
Building D Building D, 45 Allee des Ormes - BP1200
45 Allee des Ormes - BP1200 06254 MOUGINS - Sophia Antipolis
MOUGINS - Sophia Antipolis 06254 France
FRANCE
Phone: +33 497 23 26 34 Phone: +33 497 23 26 34
Email: pthubert@cisco.com Email: pthubert@cisco.com
Li Zhao Li Zhao
Cisco Systems, Inc Cisco Systems, Inc
Xinsi Building Xinsi Building, No. 926 Yi Shan Rd
No. 926 Yi Shan Rd SHANGHAI
SHANGHAI 200233 200233
CHINA China
Email: liz3@cisco.com Email: liz3@cisco.com
 End of changes. 23 change blocks. 
54 lines changed or deleted 64 lines changed or added

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