draft-ietf-roll-unaware-leaves-14.txt   draft-ietf-roll-unaware-leaves-15.txt 
ROLL P. Thubert, Ed. ROLL P. Thubert, Ed.
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Updates: 6550, 8505 (if approved) M. Richardson Updates: 6550, 8505 (if approved) M. Richardson
Intended status: Standards Track Sandelman Intended status: Standards Track Sandelman
Expires: 13 October 2020 11 April 2020 Expires: 17 October 2020 15 April 2020
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-14 draft-ietf-roll-unaware-leaves-15
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide routing This specification extends RFC6550 and RFC8505 to provide routing
services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND services to Hosts called RPL Unaware Leaves that implement 6LoWPAN ND
but do not participate to RPL. This specification also enables the but do not participate to RPL. This specification also enables the
RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG. RPL Root to proxy the 6LoWPAN keep-alive flows in its DODAG.
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 13 October 2020. This Internet-Draft will expire on 17 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 40 skipping to change at page 2, line 40
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 15
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 15
9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16 9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 16
9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 19 9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 19
9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21 9.2. Detailed Operation . . . . . . . . . . . . . . . . . . . 21
9.2.1. By the RUL Acting as 6LN . . . . . . . . . . . . . . 21 9.2.1. By the RUL Acting as 6LN . . . . . . . . . . . . . . 21
9.2.2. By the RPL Border Router Acting as 6LR . . . . . . . 22 9.2.2. By the RPL Border Router Acting as 6LR . . . . . . . 22
9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 24 9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 24
9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 25 9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 25
10. Protocol Operations for Multicast Addresses . . . . . . . . . 26 10. Protocol Operations for Multicast Addresses . . . . . . . . . 26
11. Security Considerations . . . . . . . . . . . . . . . . . . . 27 11. Security Considerations . . . . . . . . . . . . . . . . . . . 28
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28
12.1. Resizing the ARO Status values . . . . . . . . . . . . . 28 12.1. Resizing the ARO Status values . . . . . . . . . . . . . 29
12.2. New DODAG Configuration Option Flag . . . . . . . . . . 28 12.2. New DODAG Configuration Option Flag . . . . . . . . . . 29
12.3. RPL Target Option Flags . . . . . . . . . . . . . . . . 29 12.3. RPL Target Option Flags . . . . . . . . . . . . . . . . 29
12.4. New Subregistry for the RPL Non-Rejection Status 12.4. New Subregistry for the RPL Non-Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 29 values . . . . . . . . . . . . . . . . . . . . . . . . . 29
12.5. New Subregistry for the RPL Rejection Status values . . 29 12.5. New Subregistry for the RPL Rejection Status values . . 30
13. acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 13. acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30
14. Normative References . . . . . . . . . . . . . . . . . . . . 30 14. Normative References . . . . . . . . . . . . . . . . . . . . 30
15. Informative References . . . . . . . . . . . . . . . . . . . 32 15. Informative References . . . . . . . . . . . . . . . . . . . 32
Appendix A. Example Compression . . . . . . . . . . . . . . . . 33 Appendix A. Example Compression . . . . . . . . . . . . . . . . 34
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 35
1. Introduction 1. Introduction
The design of Low Power and Lossy Networks (LLNs) is generally The design of Low Power and Lossy Networks (LLNs) is generally
focused on saving energy, which is the most constrained resource of focused on saving energy, which is the most constrained resource of
all. Other design constraints, such as a limited memory capacity, all. Other design constraints, such as a limited memory capacity,
duty cycling of the LLN devices and low-power lossy transmissions, duty cycling of the LLN devices and low-power lossy transmissions,
derive from that primary concern. derive from that primary concern.
The IETF produced the "Routing Protocol for Low Power and Lossy The IETF produced the "Routing Protocol for Low Power and Lossy
skipping to change at page 10, line 31 skipping to change at page 10, line 31
and the 6LBR. A same value of lifetime is used for both, and a and the 6LBR. A same value of lifetime is used for both, and a
single keep-alive message, the RPL DAO, traverses the RPL network. A single keep-alive message, the RPL DAO, traverses the RPL network. A
new behavior is introduced whereby the RPL Root proxies the EDAR new behavior is introduced whereby the RPL Root proxies the EDAR
message to the 6LBR on behalf of the 6LR (more in Section 5), for any message to the 6LBR on behalf of the 6LR (more in Section 5), for any
6LN, RUL or RAN. 6LN, RUL or RAN.
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
"Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved "Root Proxies EDAR/EDAC" (P) that is encoded in one of the reserved
control bits in the option. The new flag is set to indicate that the control bits in the option. The new flag is set to indicate that the
Root performs the proxy operation and that all nodes in the network Root performs the proxy operation and that all nodes in the RPL
must refrain from renewing the 6LBR state directly. The bit position network must refrain from renewing the 6LBR state directly. The bit
of the "P" flag is indicated in Section 12.2. position of the "P" flag is indicated in Section 12.2.
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 "P" flag is defined only for MOP in the DIO Base Object. The new "P" 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 "Root indicate something different and MUST NOT be interpreted as "Root
Proxies EDAR/EDAC" unless the specification of the MOP indicates to Proxies EDAR/EDAC" unless the specification of the MOP indicates to
do so. do so.
The RPL Status defined in section 6.5.1. of [RFC6550] for use in the The RPL Status defined in section 6.5.1. of [RFC6550] for use in the
DAO-Ack message is extended to be used in the DCO messages DAO-Ack message is extended to be used in the DCO messages
skipping to change at page 16, line 5 skipping to change at page 16, line 5
a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange a 6LN to the 6LBR across a RPL mesh. Instead, the EDAR/EDAC exchange
with the 6LBR is proxied by the RPL Root upon a DAO message that with the 6LBR is proxied by the RPL Root upon a DAO message that
refreshes the RPL routing state. Any combination of the logical refreshes the RPL routing state. Any combination of the logical
functions of 6LR, Root and 6LBR might be collapsed in a single node. functions of 6LR, Root and 6LBR might be collapsed in a single node.
To achieve this, the lifetimes and sequence counters in 6LoWPAN ND To achieve this, the lifetimes and sequence counters in 6LoWPAN ND
and RPL are aligned. In other words, the Path Sequence and the Path and RPL are aligned. In other words, the Path Sequence and the Path
Lifetime in the DAO message are taken from the Transaction ID and the Lifetime in the DAO message are taken from the Transaction ID and the
Address Registration lifetime in the NS(EARO) message from the 6LN. Address Registration lifetime in the NS(EARO) message from the 6LN.
The proxy operation applies to both RULs and RANs. In a RPL network In a RPL network where the function is enabled, refreshing the state
where the function is enabled, refreshing the state in the 6LBR is in the 6LBR is the responsibility of the Root. Consequently, only
the responsibility of the Root. Consequently, only addresses that addresses that are injected in RPL will be kept alive by the RPL
are injected in RPL will be kept alive by the RPL Root. In a same Root. In a same fashion, if an additional routing protocol is
fashion, if an additional routing protocol is deployed on a same deployed on a same network, that additional routing protocol may need
network, that additional routing protocol may need to handle the keep to handle the keep alive procedure for the addresses that it serves.
alive procedure for the addresses that it serves.
On the first Address Registration, illustrated in Figure 5 for RPL On the first Address Registration, illustrated in Figure 5 for RPL
Non-Storing Mode, the Extended Duplicate Address exchange takes place Non-Storing Mode, the Extended Duplicate Address exchange takes place
as prescribed by [RFC8505]. If the exchange fails, the 6LR returns as prescribed by [RFC8505]. If the exchange fails, the 6LR returns
an NA message with a negative status to the 6LN, the NCE is not an NA message with a negative status to the 6LN, the NCE is not
created and the address is not injected in RPL. If it is successful, created and the address is not injected in RPL. If it is successful,
the 6LR creates an NCE and injects the Registered Address in RPL the 6LR creates an NCE and injects the Registered Address in RPL
using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root. using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root.
The 6LN signals the termination of a registration with a 6LR using an The 6LN signals the termination of a registration with a 6LR using an
NS(EARO) with a Registration Lifetime set to 0. If the 6LR does not NS(EARO) with a Registration Lifetime set to 0. Upon this, the 6LR
use the ROVR in the RPL Target Option then it MUST perform an EDAR/ MUST perform an EDAR/EDAC exchange to clean up the state at the 6LBR,
EDAC exchange to cleanup the state at the 6LBR, as illustrated in as illustrated in Figure 8, unless it uses the ROVR in the RPL Target
Option and, in Storing Mode, it is propagated to the Root.
9.1.1. In RPL Non-Storing-Mode 9.1.1. In RPL Non-Storing-Mode
In Non-Storing Mode, the DAO message flow can be nested within the In Non-Storing Mode, the DAO message flow can be nested within the
Address Registration flow as illustrated in Figure 5. Address Registration flow as illustrated in Figure 5.
6LN/RUL 6LR Root 6LBR 6LN/RUL 6LR Root 6LBR
| | | | | | | |
| NS(EARO) | | | | NS(EARO) | | |
|--------------->| | |--------------->| |
skipping to change at page 19, line 33 skipping to change at page 19, line 33
| |------------------------------------------------->| | |------------------------------------------------->|
| | | | | |
| | Extended DAC | | | Extended DAC |
| |<-------------------------------------------------| | |<-------------------------------------------------|
| NA(EARO) | | | | | NA(EARO) | | | |
|<--------------| | | | |<--------------| | | |
| | DAO | | | | | DAO | | |
| |-------------->| | | | |-------------->| | |
| | DAO-ACK | | | | | DAO-ACK | | |
| |<--------------| | | | |<--------------| | |
| | | DAO | |
| | |-------------->| |
| | | DAO-ACK | |
| | |<--------------| |
| | | | (anonymous) EDAR |
| | | |----------------->|
| | | | EDAC(ROVR) |
| | | |<-----------------|
| | | | |
Figure 9: First Registration Flow in Storing Mode Figure 9: First Registration Flow in Storing Mode
The Storing Mode of RPL does not provide and end-to-end confirmation The Storing Mode of RPL does not provide and end-to-end confirmation
that a DAO reached the root. When the 6LR has just joined, and later that a DAO reached the root. When the 6LR has just joined, and later
if DAO messages are lost before reaching the Root, the 6LR might not if DAO messages are lost before reaching the Root, the 6LR might not
be reachable back from the Root. Performing an EDAR/EDAC exchange on be reachable back from the Root. Performing an EDAR/EDAC exchange on
behalf of a RUL provides that confirmation. On the other hand, if behalf of a RUL provides that confirmation. On the other hand, if
the 6LR retries an EDAR and never gets and EDAC back, it SHOULD the 6LR retries an EDAR and never gets and EDAC back, it SHOULD
resend a DAO to become reachable again, before it tries another resend a DAO to become reachable again, before it tries another
skipping to change at page 22, line 30 skipping to change at page 22, line 30
new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange new IPv6 Address by a 6LN. If the initial EDAR/EDAC exchange
succeeds, then the 6LR installs an NCE for the Registration Lifetime. succeeds, then the 6LR installs an NCE for the Registration Lifetime.
For the refreshes of the registration, if the RPL Root has indicated For the refreshes of the registration, if the RPL Root has indicated
that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see that it proxies the keep-alive EDAR/EDAC exchange with the 6LBR (see
Section 4), the 6LR MUST refrain from sending the keep-alive EDAR Section 4), the 6LR MUST refrain from sending the keep-alive EDAR
itself. itself.
If the "R" flag is set in the NS(EARO), the 6LR SHOULD attempt to If the "R" flag is set in the NS(EARO), the 6LR SHOULD attempt to
inject the host route in RPL, unless this is barred for other inject the host route in RPL, unless this is barred for other
reasons, like a saturation of the network or if its RPL parent. The reasons, like a saturation of the network or if its RPL parent. The
"R" flag MUST set in the NA(EARO) back if 6LR successfully injected 6LR MUST set "R" flag in the NA(EARO) back if and only if it
the Registered Address in RPL and MUST be reset otherwise. successfully injected the Registered Address in RPL.
The 6LR may at any time send a unicast asynchronous NA(EARO) with the
"R" flag reset to signal that it stops providing routing services,
and/or with the EARO Status 2 "Neighbor Cache full" to signal that it
removes the NCE. It may also send a final RA, unicast or multicast,
with a Router Lifetime field of zero, to signal that it stops serving
as router, as specified in section 6.2.5 of [RFC4861].
The Opaque field in the EARO hints the 6LR on the RPL Instance that The Opaque field in the EARO hints the 6LR on the RPL Instance that
SHOULD be used for the DAO advertisements, and for the forwarding of SHOULD be used for the DAO advertisements, and for the forwarding of
packets sourced at the registered address when there is no RPI in the packets sourced at the registered address when there is no RPI in the
packet, in which case the 6LR MUST encapsulate the packet to the Root packet, in which case the 6LR MUST encapsulate the packet to the Root
adding an RPI in the outer header. If the Opaque field is zero, the adding an RPI in the outer header. If the Opaque field is zero, the
6LR is free to use the default RPL Instance (zero) for the registered 6LR is free to use the default RPL Instance (zero) for the registered
address or to select an Instance of its choice. address or to select an Instance of its choice.
if the "I" field is not zero, then the 6LR MUST consider that the if the "I" field is not zero, then the 6LR MUST consider that the
skipping to change at page 29, line 23 skipping to change at page 29, line 33
12.3. RPL Target Option Flags 12.3. RPL Target Option Flags
Section 20.15 of [RFC6550] creates a registry for the 8-bit RPL Section 20.15 of [RFC6550] creates a registry for the 8-bit RPL
Target Option Flags field. This specification reduces the field to 4 Target Option Flags field. This specification reduces the field to 4
bits. The IANA is requested to reduce the size of the registry bits. The IANA is requested to reduce the size of the registry
accordingly. accordingly.
12.4. New Subregistry for the RPL Non-Rejection Status values 12.4. New Subregistry for the RPL Non-Rejection Status values
This specification creates a new Subregistry for the RPL Non- This specification creates a new Subregistry for the RPL Non-
Rejection Status values for use in RPL DAO-ACK and DCO messages, Rejection Status values for use in RPL DAO-ACK and DCO messages with
under the ICMPv6 parameters registry. the 'A' flag reset, under the ICMPv6 parameters registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 3: * Initial allocation is as indicated in Table 3:
+-------+------------------------+-----------+ +-------+------------------------+-----------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+========================+===========+ +=======+========================+===========+
| 0 | Unqualified acceptance | RFC 6550 | | 0 | Unqualified acceptance | RFC 6550 |
+-------+------------------------+-----------+ +-------+------------------------+-----------+
Table 3: Acceptance values of the RPL Status Table 3: Acceptance values of the RPL Status
12.5. New Subregistry for the RPL Rejection Status values 12.5. New Subregistry for the RPL Rejection Status values
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 RPL DAO-ACK and RCO messages, under the Status values for use in RPL DAO-ACK and RCO messages with the 'A'
ICMPv6 parameters registry. flag reset, under the ICMPv6 parameters registry.
* Possible values are 6-bit unsigned integers (0..63). * Possible values are 6-bit unsigned integers (0..63).
* Registration procedure is "Standards Action" [RFC8126]. * Registration procedure is "Standards Action" [RFC8126].
* Initial allocation is as indicated in Table 4: * Initial allocation is as indicated in Table 4:
+-------+-----------------------+---------------+ +-------+-----------------------+---------------+
| Value | Meaning | Reference | | Value | Meaning | Reference |
+=======+=======================+===============+ +=======+=======================+===============+
 End of changes. 14 change blocks. 
28 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/