draft-ietf-roll-unaware-leaves-06.txt   draft-ietf-roll-unaware-leaves-07.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: 5 May 2020 2 November 2019 Expires: 20 May 2020 17 November 2019
Routing for RPL Leaves Routing for RPL Leaves
draft-ietf-roll-unaware-leaves-06 draft-ietf-roll-unaware-leaves-07
Abstract Abstract
This specification extends RFC6550 and RFC8505 to provide unicast and This specification extends RFC6550 and RFC8505 to provide unicast and
multicast routing services in a RPL domain to 6LNs that are plain multicast routing services in a RPL domain to 6LNs that are plain
hosts and do not participate to RPL. hosts and do not participate to RPL.
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 5 May 2020. This Internet-Draft will expire on 20 May 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 (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 21 skipping to change at page 2, line 21
2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5 2.3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . 5
3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6 3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . . 6
3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7 3.1. RFC 6775 . . . . . . . . . . . . . . . . . . . . . . . . 7
3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7 3.2. RFC 8505 Extended ARO . . . . . . . . . . . . . . . . . . 7
3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.1. R Flag . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8 3.2.2. TID, I Field and Opaque Fields . . . . . . . . . . . 8
3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2.3. ROVR . . . . . . . . . . . . . . . . . . . . . . . . 8
3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9 3.3. RFC 8505 Extended DAR/DAC . . . . . . . . . . . . . . . . 9
4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9 4. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 9
5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 10 5. Updating RFC 8505 . . . . . . . . . . . . . . . . . . . . . . 10
6. 6LN Requirements to be a RPL-Unware Leaf . . . . . . . . . . 10 6. Requirements on the RPL-Unware Leaf . . . . . . . . . . . . . 10
6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 10 6.1. Support of 6LoWPAN ND . . . . . . . . . . . . . . . . . . 10
6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 11 6.2. External Routes and RPL Artifacts . . . . . . . . . . . . 11
6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 12 6.2.1. Support of the HbH Header . . . . . . . . . . . . . . 11
6.2.2. Support of the Routing Header . . . . . . . . . . . . 12 6.2.2. Support of the Routing Header . . . . . . . . . . . . 12
6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 12 6.2.3. Support of IPv6 Encapsulation . . . . . . . . . . . . 12
7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 12 7. Updated RPL Status . . . . . . . . . . . . . . . . . . . . . 12
8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 13 8. Updated RPL Target option . . . . . . . . . . . . . . . . . . 13
9. Protocol Operations for Unicast Addresses . . . . . . . . . . 14 9. Protocol Operations for Unicast Addresses . . . . . . . . . . 14
9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 14 9.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 14
9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 15 9.1.1. In RPL Non-Storing-Mode . . . . . . . . . . . . . . . 15
9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 18 9.1.2. In RPL Storing-Mode . . . . . . . . . . . . . . . . . 18
9.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 18 9.2. Operation . . . . . . . . . . . . . . . . . . . . . . . . 18
9.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 19 9.2.1. By the 6LN . . . . . . . . . . . . . . . . . . . . . 19
9.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 20 9.2.2. By the 6LR . . . . . . . . . . . . . . . . . . . . . 20
9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 22 9.2.3. By the RPL Root . . . . . . . . . . . . . . . . . . . 22
9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 23 9.2.4. By the 6LBR . . . . . . . . . . . . . . . . . . . . . 23
10. Protocol Operations for Multicast Addresses . . . . . . . . . 23 10. Protocol Operations for Multicast Addresses . . . . . . . . . 23
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 25 11. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
12. Security Considerations . . . . . . . . . . . . . . . . . . . 25 12. Security Considerations . . . . . . . . . . . . . . . . . . . 25
13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26
13.1. RPL Target Option Flags . . . . . . . . . . . . . . . . 26 13.1. RPL Target Option Flags . . . . . . . . . . . . . . . . 26
13.2. New Subsubregistry for the RPL Non-Rejection Status 13.2. New Subregistry for the RPL Non-Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.3. New Subsubregistry for the RPL Rejection Status
values . . . . . . . . . . . . . . . . . . . . . . . . . 26 values . . . . . . . . . . . . . . . . . . . . . . . . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26 13.3. New Subregistry for the RPL Rejection Status values . . 26
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 27
15. Normative References . . . . . . . . . . . . . . . . . . . . 27 15. Normative References . . . . . . . . . . . . . . . . . . . . 27
16. Informative References . . . . . . . . . . . . . . . . . . . 29 16. Informative References . . . . . . . . . . . . . . . . . . . 29
Appendix A. Example Compression . . . . . . . . . . . . . . . . 30 Appendix A. Example Compression . . . . . . . . . . . . . . . . 30
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31
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 26 skipping to change at page 10, line 26
of the existing state in a 6LBR. of the existing state in a 6LBR.
Upon the renewal of a 6LoWPAN ND registration, this specification Upon the renewal of a 6LoWPAN ND registration, this specification
changes the behavior of a RPL router acting as 6LR for the changes the behavior of a RPL router acting as 6LR for the
registration as follows. If the Root indicates the capability to registration as follows. If the Root indicates the capability to
proxy the EDAR/EDAC exchange to the 6LBR then the 6LR refrains from proxy the EDAR/EDAC exchange to the 6LBR then the 6LR refrains from
sending an EDAR message; if the Root is separated from the 6LBR, the sending an EDAR message; if the Root is separated from the 6LBR, the
Root regenerates the EDAR message to the 6LBR upon a DAO message that Root regenerates the EDAR message to the 6LBR upon a DAO message that
signals the liveliness of the Address. signals the liveliness of the Address.
6. 6LN Requirements to be a RPL-Unware Leaf 6. Requirements on the RPL-Unware Leaf
This document provides RPL routing for a RUL, that is a 6LN acting as This document provides RPL routing for a RUL, that is a 6LN acting as
a plain host and not aware of RPL. Still, a minimal RPL-independent an IPv6 host and not aware of RPL. Still, a minimal RPL-independent
functionality is expected from the 6LN in order to obtain routing functionality is required from the RUL in order to obtain routing
services from the 6LR. services from the 6LR.
6.1. Support of 6LoWPAN ND 6.1. Support of 6LoWPAN ND
A RUL MUST implement [RFC8505] and set the R flag in the EARO option. In order to obtain routing services from a RPL 6LR, a RUL MUST
A 6LN is considered to be a RUL if and only if it sets the R flag in implement [RFC8505] and set the R flag in the EARO option.
the EARO.
A RUL MUST register to all the 6LRs from which it expects to get The RUL MUST register to all the 6LRs from which it expects to get
routing services. The registrations SHOULD be performed in a rapid routing services. The registrations SHOULD be performed in a rapid
sequence, using the exact same EARO for a same Address. Gaps between sequence, using the exact same EARO for a same Address. Gaps between
the registrations will invalidate some of the routes till the the registrations will invalidate some of the routes till the
registration finally shows on those routes as well. registration finally shows on those routes as well.
[RFC8505] introduces error Status values in the NA(EARO) which can be [RFC8505] introduces error Status values in the NA(EARO) which can be
received synchronously upon an NS(EARO) or asynchronously. The RUL received synchronously upon an NS(EARO) or asynchronously. The RUL
MUST support both cases and refrain from using the Registered Address MUST support both cases and refrain from using the Registered Address
as specified by [RFC8505] depending on the Status value. as specified by [RFC8505] depending on the Status value.
skipping to change at page 14, line 25 skipping to change at page 14, line 25
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | | |
... Registration Ownership Verifier (ROVR) ... ... Registration Ownership Verifier (ROVR) ...
| | | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Updated Target Option Figure 3: Updated Target Option
New fields: New fields:
RVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4, ROVRsz: Indicates the Size of the ROVR. It MAY be 1, 2, 3, or 4,
denoting a ROVR size of 64, 128, 192, or 256 bits, respectively. denoting a ROVR size of 64, 128, 192, or 256 bits, respectively.
Registration Ownership Verifier (ROVR): This is the same field as in Registration Ownership Verifier (ROVR): This is the same field as in
the EARO, see [RFC8505] the EARO, see [RFC8505]
9. Protocol Operations for Unicast Addresses 9. Protocol Operations for Unicast Addresses
9.1. General Flow 9.1. General Flow
This specification enables to save the exchange of Extended Duplicate This specification enables to save the exchange of Extended Duplicate
skipping to change at page 21, line 19 skipping to change at page 21, line 19
operation. Note that if the lifetime is 0, then the 6LR generates operation. Note that if the lifetime is 0, then the 6LR generates
a No-Path DAO message that cleans up the routes down to the a No-Path DAO message that cleans up the routes down to the
Address of the 6LN; Address of the 6LN;
* the Path Sequence in the TIO is set to the TID value found in the * the Path Sequence in the TIO is set to the TID value found in the
EARO option; EARO option;
* Additionally, in Non-Storing Mode the 6LR indicates one of its * Additionally, in Non-Storing Mode the 6LR indicates one of its
global IPv6 unicast addresses as the Parent Address in the TIO. global IPv6 unicast addresses as the Parent Address in the TIO.
If a DAO-ACK is not requested, or has a Status that is less than 128, If a DAO-ACK is not requested, or has a Status that is not a
indicating the DAO was accepted, respectively by a parent in Storing rejection, indicating the DAO was accepted respectively by a parent
Mode or by the Root in non-Storing Mode,, the 6LR replies with a in Storing Mode or by the Root in non-Storing Mode, the 6LR replies
NA(EARO) to the RUL with a status of 0 (Success). with a NA(EARO) to the RUL with a status of 0 (Success).
In case of a DAO-ACK or a DCO with a status of 132 (Validation In case of a DAO-ACK or a DCO indicating a rejection and transporting
Requested) the 6LR challenges the 6LN for ownership of the address, an EARO Status Value of 5 (Validation Requested) the 6LR challenges
as described in section 6.1 of [RFC8505]. If the challenge succeeds the 6LN for ownership of the address, as described in section 6.1 of
then the operations continue as normal. In particular a DAO message [RFC8505]. If the challenge succeeds then the operations continue as
is generated upon the NS(EARO) that proves the ownership of the normal. In particular a DAO message is generated upon the NS(EARO)
address. If the challenge failed the 6LR MUST refrain from injecting that proves the ownership of the address. If the challenge failed
the address in RPL and may take actions to protect itself against DoS the 6LR MUST refrain from injecting the address in RPL and may take
attacks by a rogue 6LN, see Section 12 actions to protect itself against DoS attacks by a rogue 6LN, see
Section 12
Other status values above 128 indicate that the 6LR failed to inject The other rejection codes indicate that the 6LR failed to inject the
the address into the RPL network. In that case the the 6LR MUST send address into the RPL network. If an EARO Status is transported, the
a NA(EARO) to the RUL with the copied Status value. If for any other 6LR MUST send a NA(EARO) to the RUL with that Status value. If for
reason the 6LR fails to inject the address into the RPL network, the any other reason the 6LR fails to inject the address into the RPL
6LR SHOULD send a NA(EARO) to the RUL with a status of 2 (Out of network, the 6LR SHOULD send a NA(EARO) to the RUL with a status of 2
Storage) which indicates a possibility to retry later. (Out of Storage) which indicates a possibility to retry later.
If a 6LR receives a valid NS(EARO) message with the R flag reset and If a 6LR receives a valid NS(EARO) message with the R flag reset and
the 6LR was redistributing the Registered Address due to previous the 6LR was redistributing the Registered Address due to previous
NS(EARO) messages with the flag set, then it MUST stop injecting the NS(EARO) messages with the flag set, then it MUST stop injecting the
address. It is up to the Registering Node to maintain the address. It is up to the Registering Node to maintain the
corresponding route from then on, either keeping it active by sending corresponding route from then on, either keeping it active by sending
further DAO messages, or destroying it using a No-Path DAO. further DAO messages, or destroying it using a No-Path DAO.
Upon a DCO message indicating that the address of a RUL should be Upon a DCO message indicating that the address of a RUL should be
removed from the routing table, the 6LR issues an asynchronous removed from the routing table, the 6LR issues an asynchronous
skipping to change at page 26, line 16 skipping to change at page 26, line 16
13. IANA Considerations 13. IANA Considerations
13.1. RPL Target Option Flags 13.1. 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.
13.2. New Subsubregistry for the RPL Non-Rejection Status values 13.2. New Subregistry for the RPL Non-Rejection Status values
This specification creates a new subsubregistry for the RPL Non- This specification creates a new Subregistry for the RPL Non-
Rejection Status values for use in RPL DAO-ACK and RCO Messages, Rejection Status values for use in RPL DAO-ACK and RCO Messages,
under the ICMPv6 parameters registry. 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 2: * Initial allocation is as indicated in Table 2:
+-------+------------------------+---------------+ +-------+------------------------+-----------+
| Value | Meaning | Defining Spec | | Value | Meaning | Reference |
+=======+========================+===============+ +=======+========================+===========+
| 0 | Unqualified acceptance | RFC 6550 | | 0 | Unqualified acceptance | RFC 6550 |
+-------+------------------------+---------------+ +-------+------------------------+-----------+
Table 2: Status values of the RPL DAO-ACK Message Table 2: Acceptance values of the RPL Status
13.3. New Subsubregistry for the RPL Rejection Status values 13.3. New Subregistry for the RPL Rejection Status values
This specification creates a new subsubregistry for the RPL Non- This specification creates a new Subregistry for the RPL Rejection
Rejection Status values for use in RPL DAO-ACK and RCO Messages, Status values for use in RPL DAO-ACK and RCO Messages, under the
under the ICMPv6 parameters registry. 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].
* There is no initial allocation * Initial allocation is as indicated in Table 3:
+-------+-----------------------+---------------+
| Value | Meaning | Reference |
+=======+=======================+===============+
| 0 | Unqualified rejection | This document |
+-------+-----------------------+---------------+
Table 3: Rejection values of the RPL Status
14. Acknowledgments 14. Acknowledgments
The authors wish to thank Georgios Papadopoulos for their early The authors wish to thank Georgios Papadopoulos for their early
reviews of and contributions to this document reviews of and contributions to this document
15. Normative References 15. 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,
 End of changes. 23 change blocks. 
49 lines changed or deleted 56 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/