draft-ietf-roll-unaware-leaves-29.txt   draft-ietf-roll-unaware-leaves-30.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 6775, 8505 (if approved) M. Richardson Updates: 6550, 6775, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 15 July 2021 11 January 2021 Expires: 26 July 2021 22 January 2021
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-29 draft-ietf-roll-unaware-leaves-30
Abstract Abstract
This specification updates RFC6550, RFC6775, and RFC8505. It This specification updates RFC6550, RFC6775, and RFC8505. It
provides a mechanism for a host that implements a routing-agnostic provides a mechanism for a host that implements a routing-agnostic
interface based on 6LoWPAN Neighbor Discovery to obtain reachability interface based on 6LoWPAN Neighbor Discovery to obtain reachability
services across a network that leverages RFC6550 for its routing services across a network that leverages RFC6550 for its routing
operations. operations.
Status of This Memo Status of This Memo
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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 15 July 2021. This Internet-Draft will expire on 26 July 2021.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2021 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 11, line 10 skipping to change at page 11, line 10
if the R flag is set to 1. if the R flag is set to 1.
Section 9.2 specifies additional operations when R flag is set to 1 Section 9.2 specifies additional operations when R flag is set to 1
in an EARO that is placed either in an NS or an NA message. in an EARO that is placed either in an NS or an NA message.
4.2.2. TID, "I" Field and Opaque Fields 4.2.2. TID, "I" Field and Opaque Fields
When the T Flag is set to 1, the EARO includes a sequence counter When the T Flag is set to 1, the EARO includes a sequence counter
called Transaction ID (TID), that is needed to fill the Path Sequence called Transaction ID (TID), that is needed to fill the Path Sequence
Field in the RPL Transit Option. This is the reason why the support Field in the RPL Transit Option. This is the reason why the support
of [RFC8505] by the RUL, as opposed to only [RFC6775] is a of [RFC8505] by the RUL, as opposed to only [RFC6775], is a
prerequisite for this specification)/; this requirement is fully prerequisite for this specification); this requirement is fully
explained in Section 5.1. The EARO also transports an Opaque field explained in Section 5.1. The EARO also transports an Opaque field
and an associated "I" field that describes what the Opaque field and an associated "I" field that describes what the Opaque field
transports and how to use it. transports and how to use it.
Section 9.2.1 specifies the use of the "I" field and the Opaque field Section 9.2.1 specifies the use of the "I" field and the Opaque field
by a RUL. by a RUL.
4.2.3. Route Ownership Verifier 4.2.3. Route Ownership Verifier
Section 5.3 of [RFC8505] introduces the Registration Ownership Section 5.3 of [RFC8505] introduces the Registration Ownership
skipping to change at page 35, line 29 skipping to change at page 35, line 29
At the time of this writing, RPL does not have a Route Ownership At the time of this writing, RPL does not have a Route Ownership
Validation model whereby it is possible to validate the origin of an Validation model whereby it is possible to validate the origin of an
address that is injected in a DAO. This specification makes a first address that is injected in a DAO. This specification makes a first
step in that direction by allowing the Root to challenge the RUL via step in that direction by allowing the Root to challenge the RUL via
the 6LR that serves it. the 6LR that serves it.
Section 6.1 indicates that when the length of the ROVR field is Section 6.1 indicates that when the length of the ROVR field is
unknown, the RPL Target Option must be passed on as received in RPL unknown, the RPL Target Option must be passed on as received in RPL
storing Mode. This creates a possible opening for using DAO messages storing Mode. This creates a possible opening for using DAO messages
as a covert channel. Note that DAO messages are rare and the as a covert channel. Note that DAO messages are rare and overusing
overusing that channel could be detected. An implementation SHOULD that channel could be detected. An implementation SHOULD notify the
notify the network management when a RPL Target Option is receives network management when a RPL Target Option is receives with an
with an unknown ROVR field size, to ensure that the situation is unknown ROVR field size, to ensure that the situation is known to the
known to the network administrator. network administrator.
[EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor [EFFICIENT-NPDAO] introduces the ability for a rogue common ancestor
node to invalidate a route on behalf of the target node. In this node to invalidate a route on behalf of the target node. In this
case, the RPL Status in the DCO has the 'A' flag set to 0, and a case, the RPL Status in the DCO has the 'A' flag set to 0, and a
NA(EARO) is returned to the 6LN with the R flag set to 0. This NA(EARO) is returned to the 6LN with the R flag set to 0. This
encourages the 6LN to try another 6LR. If a 6LR exists that does not encourages the 6LN to try another 6LR. If a 6LR exists that does not
use the rogue common ancestor, then the 6LN will eventually succeed use the rogue common ancestor, then the 6LN will eventually succeed
gaining reachability over the RPL network in spite of the rogue node. gaining reachability over the RPL network in spite of the rogue node.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 37, line 39 skipping to change at page 37, line 39
This specification creates a new Subregistry for the RPL Rejection This specification creates a new Subregistry for the RPL Rejection
Status values for use in the RPL DAO-ACK and DCO messages with the Status values for use in the RPL DAO-ACK and DCO messages with the
'A' flag set to 0, under the RPL registry. 'A' flag set to 0, under the RPL registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "IETF Review" [RFC8126]. * Registration procedure is "IETF Review" [RFC8126].
* Initial allocation is as indicated in Table 5: * Initial allocation is as indicated in Table 5:
+-------+-----------------------+-------------------+ +--------------------+-----------------------+-------------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+-------+-----------------------+-------------------+ +--------------------+-----------------------+-------------------+
| 0 | Unqualified rejection | THIS RFC | | 0 | Unqualified rejection | THIS RFC |
+-------+-----------------------+-------------------+ +--------------------+-----------------------+-------------------+
| 1 | No routing entry | [EFFICIENT-NPDAO] | | 1 (suggested in | No routing entry | [EFFICIENT-NPDAO] |
+-------+-----------------------+-------------------+ | [EFFICIENT-NPDAO]) | | |
| 2..63 | Unassigned | | +--------------------+-----------------------+-------------------+
+-------+-----------------------+-------------------+ | 2..63 | Unassigned | |
+--------------------+-----------------------+-------------------+
Table 5: Rejection values of the RPL Status Table 5: Rejection values of the RPL Status
13. Acknowledgments 13. Acknowledgments
The authors wish to thank Ines Robles, Georgios Papadopoulos and The authors wish to thank Ines Robles, Georgios Papadopoulos and
especially Rahul Jadhav and Alvaro Retana for their reviews and especially Rahul Jadhav and Alvaro Retana for their reviews and
contributions to this document. Also many thanks to Eric Vyncke, contributions to this document. Also many thanks to Eric Vyncke,
Erik Kline, Murray Kucherawy, Peter Van der Stok, Carl Wallace, Barry Erik Kline, Murray Kucherawy, Peter Van der Stok, Carl Wallace, Barry
Leiba, Julien Meuric, and especially Benjamin Kaduk and Elwyn Davies, Leiba, Julien Meuric, and especially Benjamin Kaduk and Elwyn Davies,
for their reviews and useful comments during the IETF Last Call and for their reviews and useful comments during the IETF Last Call and
the IESG review sessions. the IESG review sessions.
 End of changes. 7 change blocks. 
20 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/