draft-ietf-roll-efficient-npdao-15.txt   draft-ietf-roll-efficient-npdao-16.txt 
ROLL R. Jadhav, Ed. ROLL R. Jadhav, Ed.
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track P. Thubert Intended status: Standards Track P. Thubert
Expires: January 9, 2020 Cisco Expires: March 8, 2020 Cisco
R. Sahoo R. Sahoo
Z. Cao Z. Cao
Huawei Huawei
July 8, 2019 September 5, 2019
Efficient Route Invalidation Efficient Route Invalidation
draft-ietf-roll-efficient-npdao-15 draft-ietf-roll-efficient-npdao-16
Abstract Abstract
This document explains the problems associated with the current use This document explains the problems associated with the current use
of NPDAO messaging and also discusses the requirements for an of NPDAO messaging and also discusses the requirements for an
optimized route invalidation messaging scheme. Further a new optimized route invalidation messaging scheme. Further a new
proactive route invalidation message called as "Destination Cleanup proactive route invalidation message called as "Destination Cleanup
Object" (DCO) is specified which fulfills requirements of an Object" (DCO) is specified which fulfills requirements of an
optimized route invalidation messaging. optimized route invalidation messaging.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
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 January 9, 2020. This Internet-Draft will expire on March 8, 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/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 33 skipping to change at page 2, line 33
previous parent . . . . . . . . . . . . . . . . . . . . . 6 previous parent . . . . . . . . . . . . . . . . . . . . . 6
3.2. Req#2: Dependent nodes route invalidation on parent 3.2. Req#2: Dependent nodes route invalidation on parent
switching . . . . . . . . . . . . . . . . . . . . . . . . 7 switching . . . . . . . . . . . . . . . . . . . . . . . . 7
3.3. Req#3: Route invalidation should not impact data traffic 7 3.3. Req#3: Route invalidation should not impact data traffic 7
4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7 4. Changes to RPL signaling . . . . . . . . . . . . . . . . . . 7
4.1. Change in RPL route invalidation semantics . . . . . . . 7 4.1. Change in RPL route invalidation semantics . . . . . . . 7
4.2. Transit Information Option changes . . . . . . . . . . . 8 4.2. Transit Information Option changes . . . . . . . . . . . 8
4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9 4.3. Destination Cleanup Object (DCO) . . . . . . . . . . . . 9
4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10 4.3.1. Secure DCO . . . . . . . . . . . . . . . . . . . . . 10
4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10 4.3.2. DCO Options . . . . . . . . . . . . . . . . . . . . . 10
4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 10 4.3.3. Path Sequence number in the DCO . . . . . . . . . . . 11
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) . 11
4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12 4.3.5. Secure DCO-ACK . . . . . . . . . . . . . . . . . . . 12
4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12 4.4. DCO Base Rules . . . . . . . . . . . . . . . . . . . . . 12
4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 12 4.5. Unsolicited DCO . . . . . . . . . . . . . . . . . . . . . 13
4.6. Other considerations . . . . . . . . . . . . . . . . . . 13 4.6. Other considerations . . . . . . . . . . . . . . . . . . 13
4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13 4.6.1. Dependent Nodes invalidation . . . . . . . . . . . . 13
4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 13 4.6.2. NPDAO and DCO in the same network . . . . . . . . . . 14
4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14 4.6.3. Considerations for DCO retry . . . . . . . . . . . . 14
4.6.4. DCO with multiple preferred parents . . . . . . . . . 15 4.6.4. DCO with multiple preferred parents . . . . . . . . . 15
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
6.1. New Registry for the Destination Cleanup Object (DCO) 6.1. New Registry for the Destination Cleanup Object (DCO)
Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Flags . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.2. New Registry for the Destination Cleanup Object 6.2. New Registry for the Destination Cleanup Object
Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17 Acknowledgment (DCO-ACK) Status field . . . . . . . . . . 17
6.3. New Registry for the Destination Cleanup Object (DCO) 6.3. New Registry for the Destination Cleanup Object (DCO)
Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17 Acknowledgment Flags . . . . . . . . . . . . . . . . . . 17
7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18
8. Normative References . . . . . . . . . . . . . . . . . . . . 19 8. Normative References . . . . . . . . . . . . . . . . . . . . 19
Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 19 Appendix A. Example Messaging . . . . . . . . . . . . . . . . . 20
A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20 A.1. Example DCO Messaging . . . . . . . . . . . . . . . . . . 20
A.2. Example DCO Messaging with multiple preferred parents . . 21 A.2. Example DCO Messaging with multiple preferred parents . . 21
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
RPL [RFC6550] (Routing Protocol for Low power and lossy networks) RPL [RFC6550] (Routing Protocol for Low power and lossy networks)
specifies a proactive distance-vector based routing scheme. RPL has specifies a proactive distance-vector based routing scheme. RPL has
optional messaging in the form of DAO (Destination Advertisement optional messaging in the form of DAO (Destination Advertisement
Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo Object) messages, which the 6LBR (6Lo Border Router) and 6LR (6Lo
skipping to change at page 8, line 20 skipping to change at page 8, line 20
Every RPL message is divided into base message fields and additional Every RPL message is divided into base message fields and additional
Options as described in Section 6 of [RFC6550]. The base fields Options as described in Section 6 of [RFC6550]. The base fields
apply to the message as a whole and options are appended to add apply to the message as a whole and options are appended to add
message/use-case specific attributes. As an example, a DAO message message/use-case specific attributes. As an example, a DAO message
may be attributed by one or more "RPL Target" options which specify may be attributed by one or more "RPL Target" options which specify
the reachability information for the given targets. Similarly, a the reachability information for the given targets. Similarly, a
Transit Information option may be associated with a set of RPL Target Transit Information option may be associated with a set of RPL Target
options. options.
This document specifies a change in the Transit Information Option to This document specifies a change in the Transit Information Option to
contain the "Invalidate previous route" (I) flag. This I-flag contain the "Invalidate previous route" (I) flag. This 'I' flag
signals the common ancestor node to generate a DCO on behalf of the signals the common ancestor node to generate a DCO on behalf of the
target node. The I-flag is carried in the Transit Information Option target node with a RPL Status of 130 indicating that the address has
moved. The 'I' flag is carried in the Transit Information Option
which augments the reachability information for a given set of RPL which augments the reachability information for a given set of RPL
Target(s). Transit Information Option with I-flag set should be Target(s). Transit Information Option with 'I' flag set should be
carried in the DAO message when route invalidation is sought for the carried in the DAO message when route invalidation is sought for the
corresponding target(s). corresponding target(s).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type = 0x06 | Option Length |E|I| Flags | Path Control | | Type = 0x06 | Option Length |E|I| Flags | Path Control |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Path Sequence | Path Lifetime | | Path Sequence | Path Lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 8, line 48 skipping to change at page 8, line 49
I (Invalidate previous route) flag: The 'I' flag is set by the target I (Invalidate previous route) flag: The 'I' flag is set by the target
node to indicate to the common ancestor node that it wishes to node to indicate to the common ancestor node that it wishes to
invalidate any previous route between the two paths. invalidate any previous route between the two paths.
[RFC6550] allows the parent address to be sent in the Transit [RFC6550] allows the parent address to be sent in the Transit
Information Option depending on the mode of operation. In case of Information Option depending on the mode of operation. In case of
storing mode of operation the field is usually not needed. In case storing mode of operation the field is usually not needed. In case
of DCO, the parent address field MUST NOT be included. of DCO, the parent address field MUST NOT be included.
The common ancestor node SHOULD generate a DCO message in response to The common ancestor node SHOULD generate a DCO message in response to
this I-flag when it sees that the routing adjacencies have changed this 'I' flag when it sees that the routing adjacencies have changed
for the target. The I-flag is intended to give the target node for the target. The 'I' flag is intended to give the target node
control over its own route invalidation, serving as a signal to control over its own route invalidation, serving as a signal to
request DCO generation. request DCO generation.
4.3. Destination Cleanup Object (DCO) 4.3. Destination Cleanup Object (DCO)
A new ICMPv6 RPL control message code is defined by this A new ICMPv6 RPL control message code is defined by this
specification and is referred to as "Destination Cleanup Object" specification and is referred to as "Destination Cleanup Object"
(DCO), which is used for proactive cleanup of state and routing (DCO), which is used for proactive cleanup of state and routing
information held on behalf of the target node by 6LRs. The DCO information held on behalf of the target node by 6LRs. The DCO
message always traverses downstream and cleans up route information message always traverses downstream and cleans up route information
and other state information associated with the given target. and other state information associated with the given target.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |K|D| Flags | Reserved | DCOSequence | | RPLInstanceID |K|D| Flags | RPL Status | DCOSequence |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID(optional) + + DODAGID(optional) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option(s)... | Option(s)...
skipping to change at page 10, line 9 skipping to change at page 10, line 9
sender does not set the 'K' flag it is an indication that the sender sender does not set the 'K' flag it is an indication that the sender
does not expect a response, and the sender SHOULD NOT retry the DCO. does not expect a response, and the sender SHOULD NOT retry the DCO.
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Flags: The 6 bits remaining unused in the Flags field are reserved Flags: The 6 bits remaining unused in the Flags field are reserved
for future use. These bits MUST be initialized to zero by the sender for future use. These bits MUST be initialized to zero by the sender
and MUST be ignored by the receiver. and MUST be ignored by the receiver.
Reserved: 8-bit unused field. The field MUST be initialized to zero RPL Status: The RPL Status as defined in section 6.5.1 of [RFC6550].
by the sender and MUST be ignored by the receiver. Indicative of the reason why the DCO happened, the RPL Status MUST
NOT be changed as the DCO is propagated down the route being
invalidated. This value is informative and does not affect the
behavior of the receiver. In particular, unknown values are ignored
by the receiver. Only Rejection Codes (values of 128 and above) are
expected in a DCO.
DCOSequence: 8-bit field incremented at each unique DCO message from DCOSequence: 8-bit field incremented at each unique DCO message from
a node and echoed in the DCO-ACK message. The initial DCOSequence a node and echoed in the DCO-ACK message. The initial DCOSequence
can be chosen randomly by the node. Section 4.4 explains the can be chosen randomly by the node. Section 4.4 explains the
handling of the DCOSequence. handling of the DCOSequence.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field MUST be present when the 'D' uniquely identifies a DODAG. This field MUST be present when the 'D'
flag is set and MUST NOT be present if 'D' flag is not set. DODAGID flag is set and MUST NOT be present if 'D' flag is not set. DODAGID
is used when a local RPLInstanceID is in use, in order to identify is used when a local RPLInstanceID is in use, in order to identify
skipping to change at page 11, line 19 skipping to change at page 11, line 27
4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK) 4.3.4. Destination Cleanup Option Acknowledgment (DCO-ACK)
The DCO-ACK message SHOULD be sent as a unicast packet by a DCO The DCO-ACK message SHOULD be sent as a unicast packet by a DCO
recipient in response to a unicast DCO message with 'K' flag set. If recipient in response to a unicast DCO message with 'K' flag set. If
'K' flag is not set then the receiver of the DCO message MAY send a 'K' flag is not set then the receiver of the DCO message MAY send a
DCO-ACK, especially to report an error condition. DCO-ACK, especially to report an error condition.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RPLInstanceID |D| Flags | DCOSequence | Status | | RPLInstanceID |D| Flags | DCOSequence | DCO-ACK Status|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
+ + + +
| | | |
+ DODAGID(optional) + + DODAGID(optional) +
| | | |
+ + + +
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 11, line 44 skipping to change at page 12, line 5
D: The 'D' flag indicates that the DODAGID field is present. This D: The 'D' flag indicates that the DODAGID field is present. This
flag MUST be set when a local RPLInstanceID is used. flag MUST be set when a local RPLInstanceID is used.
Flags: 7-bit unused field. The field MUST be initialized to zero by Flags: 7-bit unused field. The field MUST be initialized to zero by
the sender and MUST be ignored by the receiver. the sender and MUST be ignored by the receiver.
DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from DCOSequence: 8-bit field. The DCOSequence in DCO-ACK is copied from
the DCOSequence received in the DCO message. the DCOSequence received in the DCO message.
Status: Indicates the completion. Status 0 is defined as unqualified DCO-ACK Status: Indicates the completion. A value of 0 is defined as
acceptance in this specification. Status 1 is defined as "No unqualified acceptance in this specification. A value of 1 is
routing-entry for the Target found". The remaining status values are defined as "No routing-entry for the Target found". The remaining
reserved as rejection codes. status values are reserved as rejection codes.
DODAGID (optional): 128-bit unsigned integer set by a DODAG root that DODAGID (optional): 128-bit unsigned integer set by a DODAG root that
uniquely identifies a DODAG. This field MUST be present when the 'D' uniquely identifies a DODAG. This field MUST be present when the 'D'
flag is set and MUST NOT be present when 'D' flag is not set. flag is set and MUST NOT be present when 'D' flag is not set.
DODAGID is used when a local RPLInstanceID is in use, in order to DODAGID is used when a local RPLInstanceID is in use, in order to
identify the DODAGID that is associated with the RPLInstanceID. identify the DODAGID that is associated with the RPLInstanceID.
4.3.5. Secure DCO-ACK 4.3.5. Secure DCO-ACK
A Secure DCO-ACK message follows the format in [RFC6550] Figure 7, A Secure DCO-ACK message follows the format in [RFC6550] Figure 7,
where the base message format is the DCO-ACK message shown in where the base message format is the DCO-ACK message shown in
Figure 4. Figure 4.
4.4. DCO Base Rules 4.4. DCO Base Rules
skipping to change at page 13, line 29 skipping to change at page 13, line 38
4.6. Other considerations 4.6. Other considerations
4.6.1. Dependent Nodes invalidation 4.6.1. Dependent Nodes invalidation
Current RPL [RFC6550] does not provide a mechanism for route Current RPL [RFC6550] does not provide a mechanism for route
invalidation for dependent nodes. This document allows the dependent invalidation for dependent nodes. This document allows the dependent
nodes invalidation. Dependent nodes will generate their respective nodes invalidation. Dependent nodes will generate their respective
DAOs to update their paths, and the previous route invalidation for DAOs to update their paths, and the previous route invalidation for
those nodes should work in the similar manner described for switching those nodes should work in the similar manner described for switching
node. The dependent node may set the I-flag in the Transit node. The dependent node may set the 'I' flag in the Transit
Information Option as part of regular DAO so as to request Information Option as part of regular DAO so as to request
invalidation of previous route from the common ancestor node. invalidation of previous route from the common ancestor node.
Dependent nodes do not have any indication regarding if any of their Dependent nodes do not have any indication regarding if any of their
parents in turn have decided to switch their parent. Thus for route parents in turn have decided to switch their parent. Thus for route
invalidation the dependent nodes may choose to always set the 'I' invalidation the dependent nodes may choose to always set the 'I'
flag in all its DAO message's Transit Information Option. Note that flag in all its DAO message's Transit Information Option. Note that
setting the I-flag is not counterproductive even if there is no setting the 'I' flag is not counterproductive even if there is no
previous route to be invalidated. previous route to be invalidated.
4.6.2. NPDAO and DCO in the same network 4.6.2. NPDAO and DCO in the same network
The current NPDAO mechanism in [RFC6550] can still be used in the The current NPDAO mechanism in [RFC6550] can still be used in the
same network where DCO is used. The NPDAO messaging can be used, for same network where DCO is used. The NPDAO messaging can be used, for
example, on route lifetime expiry of the target or when the node example, on route lifetime expiry of the target or when the node
simply decides to gracefully terminate the RPL session on graceful simply decides to gracefully terminate the RPL session on graceful
node shutdown. Moreover, a deployment can have a mix of nodes node shutdown. Moreover, a deployment can have a mix of nodes
supporting the DCO and the existing NPDAO mechanism. It is also supporting the DCO and the existing NPDAO mechanism. It is also
skipping to change at page 16, line 31 skipping to change at page 16, line 38
| | | document | | | | document |
| TBD2 | Destination Cleanup Object Acknowledgment | This | | TBD2 | Destination Cleanup Object Acknowledgment | This |
| | | document | | | | document |
| TBD3 | Secure Destination Cleanup Object | This | | TBD3 | Secure Destination Cleanup Object | This |
| | | document | | | | document |
| TBD4 | Secure Destination Cleanup Object | This | | TBD4 | Secure Destination Cleanup Object | This |
| | Acknowledgment | document | | | Acknowledgment | document |
+------+---------------------------------------------+--------------+ +------+---------------------------------------------+--------------+
IANA is requested to allocate bit 1 from the Transit Information IANA is requested to allocate bit 1 from the Transit Information
Option Flags registry for the I-flag (Section 4.2) Option Flags registry for the 'I' flag (Section 4.2)
6.1. New Registry for the Destination Cleanup Object (DCO) Flags 6.1. New Registry for the Destination Cleanup Object (DCO) Flags
IANA is requested to create a registry for the 8-bit Destination IANA is requested to create a registry for the 8-bit Destination
Cleanup Object (DCO) Flags field. This registry should be located in Cleanup Object (DCO) Flags field. This registry should be located in
existing category of "Routing Protocol for Low Power and Lossy existing category of "Routing Protocol for Low Power and Lossy
Networks (RPL)". Networks (RPL)".
New bit numbers may be allocated only by an IETF Review. Each bit is New bit numbers may be allocated only by an IETF Review. Each bit is
tracked with the following qualities: tracked with the following qualities:
skipping to change at page 18, line 23 skipping to change at page 18, line 28
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
| 0 | DODAGID field is present (D) | This document | | 0 | DODAGID field is present (D) | This document |
+------------+------------------------------+---------------+ +------------+------------------------------+---------------+
DCO-ACK Base Flags DCO-ACK Base Flags
7. Security Considerations 7. Security Considerations
This document introduces the ability for a common ancestor node to This document introduces the ability for a common ancestor node to
invalidate a route on behalf of the target node. The common ancestor invalidate a route on behalf of the target node. The common ancestor
node could be directed to do so by the target node using the I-flag node could be directed to do so by the target node using the 'I' flag
in DCO's Transit Information Option. However, the common ancestor in DCO's Transit Information Option. However, the common ancestor
node is in a position to unilaterally initiate the route invalidation node is in a position to unilaterally initiate the route invalidation
since it possesses all the required state information, namely, the since it possesses all the required state information, namely, the
Target address and the corresponding Path Sequence. Thus a rogue Target address and the corresponding Path Sequence. Thus a rogue
common ancestor node could initiate such an invalidation and impact common ancestor node could initiate such an invalidation and impact
the traffic to the target node. the traffic to the target node.
This document also introduces an I-flag which is set by the target The DCO carries a RPL Status value, which is informative. New Status
values may be created over time and a node will ignore an unknown
Status value. This enables RPL Status field to be used as a cover
channel. But the channel only works once since the message destroys
its own medium, that is the existing route that it is removing.
This document also introduces an 'I' flag which is set by the target
node and used by the ancestor node to initiate a DCO if the ancestor node and used by the ancestor node to initiate a DCO if the ancestor
sees an update in the route adjacency. However, this flag could be sees an update in the route adjacency. However, this flag could be
spoofed by a malicious 6LR in the path and can cause invalidation of spoofed by a malicious 6LR in the path and can cause invalidation of
an existing active path. Note that invalidation will happen only if an existing active path. Note that invalidation will happen only if
the other conditions such as Path Sequence condition is also met. the other conditions such as Path Sequence condition is also met.
Having said that, such a malicious 6LR may spoof a DAO on behalf of Having said that, such a malicious 6LR may spoof a DAO on behalf of
the (sub) child with the I-flag set and can cause route invalidation the (sub) child with the 'I' flag set and can cause route
on behalf of the (sub) child node. Note that, using existing invalidation on behalf of the (sub) child node. Note that, using
mechanisms offered by [RFC6550], a malicious 6LR might also spoof a existing mechanisms offered by [RFC6550], a malicious 6LR might also
DAO with lifetime of zero or otherwise cause denial of service by spoof a DAO with lifetime of zero or otherwise cause denial of
dropping traffic entirely, so the new mechanism described in this service by dropping traffic entirely, so the new mechanism described
document does not present a substantially increased risk of in this document does not present a substantially increased risk of
disruption. disruption.
This document assumes that the security mechanisms as defined in This document assumes that the security mechanisms as defined in
[RFC6550] are followed, which means that the common ancestor node and [RFC6550] are followed, which means that the common ancestor node and
all the 6LRs are part of the RPL network because they have the all the 6LRs are part of the RPL network because they have the
required credentials. A non-secure RPL network needs to take into required credentials. A non-secure RPL network needs to take into
consideration the risks highlighted in this section as well as those consideration the risks highlighted in this section as well as those
highlighted in [RFC6550]. highlighted in [RFC6550].
All RPL messages support a secure version of messages which allows All RPL messages support a secure version of messages which allows
 End of changes. 23 change blocks. 
33 lines changed or deleted 44 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/