ROLL P. Thubert, Ed. Internet-Draft Cisco Updates: 6550, 6775 (if approved) February 21, 2018 Intended status: Standards Track Expires: August 25, 2018 Routing for RPL Leaves draft-thubert-roll-unaware-leaves-02 Abstract This specification updates RFC 6550 and RFC 6775 unicast routing service in a RPL domain to 6LoWPAN ND nodes that do not participate to the routing protocol. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 25, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Thubert Expires August 25, 2018 [Page 1] Internet-Draft Routing for RPL Leaves February Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Updating RFC 6550 . . . . . . . . . . . . . . . . . . . . . . 4 4. Updating RFC 6775 Update . . . . . . . . . . . . . . . . . . 4 5. Updated EARO . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Protocol Operations . . . . . . . . . . . . . . . . . . . . . 6 6.1. General Flow . . . . . . . . . . . . . . . . . . . . . . 6 6.2. 6LN Operation . . . . . . . . . . . . . . . . . . . . . . 8 6.3. 6LR Operation . . . . . . . . . . . . . . . . . . . . . . 8 6.4. RPL Root Operation . . . . . . . . . . . . . . . . . . . 9 6.5. 6LBR Operation . . . . . . . . . . . . . . . . . . . . . 9 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 10 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 11.1. Normative References . . . . . . . . . . . . . . . . . . 10 11.2. Informative References . . . . . . . . . . . . . . . . . 11 Appendix A. Subset of a 6LoWPAN Glossary . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 1. Introduction The design of Low Power and Lossy Networks (LLNs) is generally focused on saving energy, which is the most constrained resource of all. Other design constraints, such as a limited memory capacity, duty cycling of the LLN devices and low-power lossy transmissions, derive from that primary concern. The IETF produced the "Routing Protocol for Low Power and Lossy Networks" [RFC6550] (RPL) to provide routing services within such constraints. RPL is a Distance-Vector protocol, which, compared to link-state protocols, limits the amount of topological knowledge that needs to be installed and maintained in each node. RPL also leverages Routing Stretch to reduce further the amount of control traffic and routing state that is required to operate the protocol. Finally, broken routes may be fixed lazily and on-demand, based on dataplane inconsistency discovery, which avoids wasting energy in the proactive repair of unused paths. In order to cope with lossy transmissions, RPL forms Direction- Oriented Directed Acyclic Graphs (DODAGs) using DODAG Information Solicitation (DIS) and DODAG Information Object (DIO) messages. For most of the nodes, though not all, a DODAG provides multiple forwarding solutions towards the Root of the topology via so-called parents. Because it is designed to adapt to fuzzy connectivity with Thubert Expires August 25, 2018 [Page 2] Internet-Draft Routing for RPL Leaves February lazy control, RPL can only provide a best effort routability, connecting most of the LLN nodes, most of the time. RPL provides unicast and multicast routing services back to RPL-Aware nodes. A RPL-Aware Node will inject routes to self using Destination Advertisement Object (DAO) messages sent to either their parents in Storing Mode or to the Root indicating their parent in Non-Storing mode. This process effectively forms a DODAG back to the device that is a subset of the DODAG to the Root with all links reversed. The IPv6 [RFC8200] Neighbor Discovery (IPv6 ND) Protocol (NDP) suite [RFC4861] [RFC4862] defined for fast media such a Ethernet, relies heavily on multicast operations for address discovery and duplicate address detection (DAD). "Neighbor Discovery Optimizations for 6LoWPAN networks" [RFC6775] (6LoWPAN ND) adapts IPv6 ND for operations over energy-constrained LLNs. In particular, 6LoWPAN ND introduces a unicast host address registration mechanism that contributes to reduce the use of multicast messages that are present in the classical IPv6 ND protocol. 6LoWPAN ND defines a new Address Registration Option (ARO) that is carried in the unicast Neighbor Solicitation (NS) and Neighbor Advertisement (NA) messages between the 6LoWPAN Node (6LN) and the 6LoWPAN Router (6LR). 6LoWPAN ND also defines the Duplicate Address Request (DAR) and Duplicate Address Confirmation (DAC) messages between the 6LR and the 6LoWPAN Border Router (6LBR). In an LLN, the 6LBR is the central repository of all the registered addresses in its domain. An Update to 6LoWPAN ND [I-D.ietf-6lo-rfc6775-update] defines an Extended Address Registration Option (EARO) to include a sequence counter called Transaction ID (TID), which maps to the Path Sequence Field found in Transit Options in RPL DAO messages. It is a prerequisite for this specification. The DAR and DAC messages are also extended as EDAR and EDAC messages respectively. When a routing protocol such as RPL is used to maintain reachability within a Non-Broadcast Multi-Access (NBMA) subnet, Some nodes may act as routers and participate to the routing operations whereas others may be plain hosts. In 6LoWPAN ND terms, this means that 6LN that may also be a 6LR and manage its own routing. Alternatively, the 6LN may rely on its 6LR to perform routing and forwarding on its behalf. In the context of RPL, such a 6LN is called a leaf. The packet forwarding operation by the 6LR serving a leaf 6LN is described in "When to use RFC 6553, 6554 and IPv6-in- IPv6" [I-D.ietf-roll-useofrplinfo]. This document adds the capability by a 6LR to advertise the IPv6 address(es) of the 6LN in the RPL protocol. Thubert Expires August 25, 2018 [Page 3] Internet-Draft Routing for RPL Leaves February With this specification, a 6LN may declare itself as a router in the 6LoWPAN ND exchange in order to declare that it will manage it own routing. By default, the 6LN is considered as a plain host, and the 6LR that accepts the registration will inject routing information on behalf of the 6LN in the RPL domain. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. The Terminology used in this document is consistent with and incorporates that described in Terms Used in Routing for Low-Power and Lossy Networks (LLNs). [RFC7102]. Other terms in use in LLNs are found in Terminology for Constrained- Node Networks [RFC7228]. A glossary of classical 6LoWPAN acronyms is given in Appendix A. The term "byte" is used in its now customary sense as a synonym for "octet". "RPL", "RPL Packet Information" (RPI) and "RPL Instance", DIO, DAO and DIS messages are defined in the "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] specification. 3. Updating RFC 6550 This document specifies a new behavior whereby a 6LR injects DAO messages for unicast addresses registered through the updated 6LoWPAN ND [I-D.ietf-6lo-rfc6775-update] on behalf of 6LN nodes that are not RPL-aware. Upon the renewal of a registration, this specification changes the behavior or the 6LR. If a DAO is sent for the registered address, then the 6LR refrains from sending a DAR message. Upon reception of the DAO message initiated at the 6LR, the DAR/DAC exchange happens between the RPL Root and the 6LBR, the Root acting as a proxy Root on behalf of the 6LR to maintain an existing state in the 6LBR. 4. Updating RFC 6775 Update This document specifies a new flag in the EARO option, the 'R' flag, used by the registering node to indicate that the 6LN that performs the registration is a router and that it handles its reachability. Thubert Expires August 25, 2018 [Page 4] Internet-Draft Routing for RPL Leaves February Setting the 'R' flag effectively suppresses the behavior defined in this specification whereby the 6LR that processes the registration advertises the registered address in DAO messages and bypasses the DAR/DAC process for the renewal of a registration. This document also specifies a keep-alive EDAR message that the RPL Root may use to maintain an existing state in the 6LBR upon receiving DAO messages. The EDAR message may only act as a refresher and can only update the Lifetime and the TID of the state in the 6LBR. 5. Updated EARO This document introduces a new 'R' flag in the EARO option, as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Status | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |R|C|T| TID | Registration Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Owner Unique ID (EUI-64 or Crypto-ID) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Enhanced Address Registration Option Type: 33 Length: 8-bit unsigned integer. The length of the option (including the type and length fields) in units of 8 bytes. Status: Defined in [RFC6775] and updated in [I-D.ietf-6lo-ap-nd]. Reserved: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. R: When set, this flag indicates that the registering node is a router that handles it reachability. If the 'R' flag is not set, the registering node expects that the 6LR ensures reachability for the registered address. In the context of this specification, this means that the 6LR will advertise the registered address in the RPL domain. C: --> Defined in [I-D.ietf-6lo-ap-nd]. T and TID: Defined in [I-D.ietf-6lo-rfc6775-update]. Thubert Expires August 25, 2018 [Page 5] Internet-Draft Routing for RPL Leaves February Owner Unique ID: Defined in [RFC6775] and updated in [I-D.ietf-6lo-ap-nd]. 6. Protocol Operations 6.1. General Flow This specification enables to save the exchange of Extended Duplicate Address messages, EDAR and EDAC, from a 6LN all the way to the 6LBR across a RPL mesh, for the sole purpose of refreshing an existing state in the 6LBR. Instead, the EDAR/EDAC exchange is proxied by the RPL Root upon a DAO message that refreshes the RPL routing state. To achieve this, the lifetimes and sequence counters in 6LoWPAN ND and RPL are aligned, which means that the Path Sequence and the Path Lifetime in the DAO message are derived from the Transaction ID and the registration lifetime in the NS(EARO) message from the 6LN. From the perspective of the 6LN, the registration flow happens transparently; it is not delayed by the proxy RPL operation, so the device does not need to wait more whether RPL proxy operation happens or not. The flows below are RPL Non-Storing Mode examples. In Storing Mode, the DAO ACK may not be present, and the DAO messages cascade from child to parent all the way to the DODAG Root. On the first registration, illustrated in Figure 2, from the perspective of the 6LR, the Extended Duplicate Address message takes place as prescribed by [I-D.ietf-6lo-rfc6775-update]. When successful, the flow creates a Neighbor Cache Entry (NCE) in the 6LR, and the 6LR injects the registered address in RPL using DAO/DAO-ACK exchanges all the way to the RPL DODAG Root. The protocol does not carry a specific information that the Extended Duplicate Address messages were already exchanged, so the Root proxies them anyway. Thubert Expires August 25, 2018 [Page 6] Internet-Draft Routing for RPL Leaves February 6LN 6LR Root 6LBR | | | | | NS(EARO) | | | |--------------->| | | | | Extended DAR | | |------------------------------->| | | | | | Extended DAC | | |<-------------------------------| | NA(EARO) | | |<---------------| | | | | DAO | | | |-------------->| | | | DAO ACK | | | |<--------------| | | | | keep-alive DAR | | | |--------------->| | | | keep-alive DAC | | | |<---------------| | | | | Figure 2: First Registration Flow A re-registration is performed by the 6LN to maintain the NCE in the 6LR alive before lifetime expires. Upon a re-registration, as illustrated in Figure 2, the 6LR redistributes the NS(EARO) in RPL. This causes the RPL DODAG Root to refresh the state in the 6LBR with a keep-alive EDAR message. 6LN 6LR Root 6LBR | | | | | NS(EARO) | | | |--------------->| | | | NA(EARO) | | | |<---------------| | | | | DAO | | | |-------------->| | | | DAO ACK | | | |<--------------| | | | | proxy DAR | | | |--------------->| | | | proxy DAC | | | |<---------------| | | | | Figure 3: Next Registration Flow Thubert Expires August 25, 2018 [Page 7] Internet-Draft Routing for RPL Leaves February 6.2. 6LN Operation This specification does not alter the operation of a 6LowpAN ND- compliant 6LN, which is expected to operate as follows: o The 6LN obtains an IPv6 global address, for instance using autoconfiguration [RFC4862] based on a Prefix Information Option (PIO) [RFC4861] found in a Router Advertisement message or by some other means such as DHCPv6 [RFC3315]. o Once it has formed an address, the 6LN (re)registers its address periodically, within the Lifetime of the previous registration, as prescribed by [I-D.ietf-6lo-rfc6775-update]. o Upon each consecutive registration, the 6LN increases the TID field. o The 6LN MAY register to more than one 6LR at the same time. In that case, a same value of TID is used for each registration. o The 6LN MAY use any of the 6LRs to which it register to forward its packets. 6.3. 6LR Operation Also as prescribed by [I-D.ietf-6lo-rfc6775-update], the 6LR generates a DAR/DAC message upon reception of a valid NS(EARO) message for a new registration. If the exchange succeeds, then the 6LR installs a Neighbor Cache Entry (NCE). At this stage, and upon each NS(EARO) received afterwards that maintain the NCE in the 6LR; if the 'R' flag was set in a NS(EARO) message, the 6LR refrains from injecting the registered address into RPL; else the 6LR SHOULD redistribute the registered address into RPL by sending a DAO message on behalf of the 6LN. The DAO message advertising the registered address MUST be constructed as follows: o The registered address is placed in a RPL Target Option in the DAO message as the Target Prefix, and the Prefix Length is set to 128 o the External 'E' flag in the Transit Information Option (TIO) associated to the Target Option is set to indicate that the 6LR redistributes an external target into the RPL network o the Path Lifetime in the TIO is computed from the Lifetime in the EARO Option to adapt it to the Lifetime Units used in the RPL operation. o the Path Sequence in the TIO is set to the TID value found in the EARO option. o Additionally, in Non-Storing Mode the 6LR indicates one of its global IPv6 unicast addresses as the Parent Address in the TIO. Thubert Expires August 25, 2018 [Page 8] Internet-Draft Routing for RPL Leaves February If a 6LR receives a valid NS(EARO) message with the 'R' flag set and the 6LR was redistributing the registered address due to previous NS(EARO) messages with the flag not set, then it MUST stop redistributing the address. It is up to the registering node to maintain the corresponding route from then on, either keeping it active by sending further DAO messages, or destroying it using a No- Path DAO. 6.4. RPL Root Operation Upon reception of a DAO message that creates or updates an existing RPL state, the Root notifies the 6LR using an internal API if they are collocated, or a proxied DAR/DAC exchange on behalf of the registering node if they are separated. In the latter case, the DAR message MUST be constructed as follows: o The registered address from in the Target Option is placed in the Registered Address field o the Owner Unique ID field is set to all ones to indicate that it is not provided o the Registration Lifetime in the DAR message is adapted from the Path Lifetime in the TIO. o the TID value is set to the Path Sequence in the TIO. Upon a status in a DAC message that is not "Success", the Root MAY destroy the formed paths using a No-Path DAO downwards as specified in [I-D.ietf-roll-efficient-npdao]. In Non-Storing Mode, the outer IPv6 header that is used by the Root to transport the source routing information in data packets down the DODAG has the 6LR that serves the 6LN as final destination. This way, when the final 6LR decapsulates the outer header, it also removes all the RPL artifacts from the packet. 6.5. 6LBR Operation Upon reception of a DAR message with the Owner Unique ID field is set to all ones, the 6LBR checks whether and entry exists for the and computes whether the TID in the DAR message is fresher than that in the entry as prescribed in [I-D.ietf-6lo-rfc6775-update]. If the entry does not exist, the 6LBR does not create the entry, and answers with a Status "Removed" in the DAC message. If the entry exists but is not fresher, the 6LBR does not update the entry, and answers with a Status "Success" in the DAC message. Thubert Expires August 25, 2018 [Page 9] Internet-Draft Routing for RPL Leaves February If te entry exists and the TID in the DAR message is fresher, the 6LBR updates the TID in the entry, and if the lifetime of the entry is extended by the Registration Lifetime in the DAR message, it also updates the lifetime of the entry. In that case, the 6LBR replies with a Status "Success" in the DAC message. 7. Implementation Status 8. Security Considerations The LLN nodes depend on the 6LBR and the RPL participants for their operation. A trust model must be put in place to ensure that the right devices are acting in these roles, so as to avoid threats such as black-holing, or bombing attack whereby an impersonated 6LBR would destroy state in the network by using the "Removed" Status code. This trust model could be at a minimum based on a Layer-2 access control, or could provide role validation as well. This is a generic 6LoWPAN requirement, see Req5.1 in Appendix of [I-D.ietf-6lo-rfc6775-update]. The keep-alive EDAR message does not carry a valid Registration Unique ID [I-D.ietf-6lo-rfc6775-update] and it cannot be used to create a binding state in the 6LBR. The 6LBR MUST NOT create an entry based on a keep-alive EDAR that does not match an existing entry. All it can do is refresh the lifetime and the TID of an existing entry. 9. IANA Considerations This specification has no requirement on IANA. 10. Acknowledgments 11. References 11.1. Normative References [I-D.ietf-6lo-rfc6775-update] Thubert, P., Nordmark, E., Chakrabarti, S., and C. Perkins, "An Update to 6LoWPAN ND", draft-ietf-6lo- rfc6775-update-11 (work in progress), December 2017. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . Thubert Expires August 25, 2018 [Page 10] Internet-Draft Routing for RPL Leaves February [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, . [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, . [RFC6550] Winter, T., Ed., Thubert, P., Ed., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP., and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, DOI 10.17487/RFC6550, March 2012, . [RFC6775] Shelby, Z., Ed., Chakrabarti, S., Nordmark, E., and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, DOI 10.17487/RFC6775, November 2012, . [RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017, . 11.2. Informative References [I-D.ietf-6lo-ap-nd] Thubert, P., Sarikaya, B., and M. Sethi, "Address Protected Neighbor Discovery for Low-power and Lossy Networks", draft-ietf-6lo-ap-nd-05 (work in progress), January 2018. [I-D.ietf-roll-efficient-npdao] Jadhav, R., Sahoo, R., and Z. Cao, "No-Path DAO modifications", draft-ietf-roll-efficient-npdao-01 (work in progress), October 2017. [I-D.ietf-roll-useofrplinfo] Robles, I., Richardson, M., and P. Thubert, "When to use RFC 6553, 6554 and IPv6-in-IPv6", draft-ietf-roll- useofrplinfo-21 (work in progress), February 2018. Thubert Expires August 25, 2018 [Page 11] Internet-Draft Routing for RPL Leaves February [IEEEstd802154] IEEE standard for Information Technology, "IEEE Standard for Local and metropolitan area networks-- Part 15.4: Low- Rate Wireless Personal Area Networks (LR-WPANs)". [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, . [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, . [RFC7228] Bormann, C., Ersue, M., and A. Keranen, "Terminology for Constrained-Node Networks", RFC 7228, DOI 10.17487/RFC7228, May 2014, . Appendix A. Subset of a 6LoWPAN Glossary This document often uses the followng acronyms: 6BBR: 6LoWPAN Backbone Router (proxy for the registration) 6LBR: 6LoWPAN Border Router (authoritative on DAD) 6LN: 6LoWPAN Node 6LR: 6LoWPAN Router (relay to the registration process) 6CIO: Capability Indication Option (E)ARO: (Extended) Address Registration Option DAD: Duplicate Address Detection LLN: Low Power Lossy Network (a typical IoT network) NCE: Neighbor Cache Entry RUID: Registration Unique ID TID: Transaction ID (a sequence counter in the EARO) Author's Address Pascal Thubert (editor) Cisco Systems, Inc Building D 45 Allee des Ormes - BP1200 MOUGINS - Sophia Antipolis 06254 FRANCE Phone: +33 497 23 26 34 Email: pthubert@cisco.com Thubert Expires August 25, 2018 [Page 12]