--- 1/draft-ietf-6lo-rfc6775-update-03.txt 2017-05-02 00:13:31.280488290 -0700 +++ 2/draft-ietf-6lo-rfc6775-update-04.txt 2017-05-02 00:13:31.344489800 -0700 @@ -1,20 +1,20 @@ 6lo P. Thubert, Ed. Internet-Draft cisco Updates: 6775 (if approved) E. Nordmark Intended status: Standards Track -Expires: October 29, 2017 S. Chakrabarti - April 27, 2017 +Expires: November 2, 2017 S. Chakrabarti + May 1, 2017 An Update to 6LoWPAN ND - draft-ietf-6lo-rfc6775-update-03 + draft-ietf-6lo-rfc6775-update-04 Abstract This specification updates RFC 6775 - 6LoWPAN Neighbor Discovery, to clarify the role of the protocol as a registration technique, simplify the registration operation in 6LoWPAN routers, and provide enhancements to the registration capabilities, in particular for the registration to a Backbone Router for proxy ND operations. Status of This Memo @@ -25,21 +25,21 @@ 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 http://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 October 29, 2017. + This Internet-Draft will expire on November 2, 2017. Copyright Notice Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -59,60 +59,60 @@ 5.1. Extended Address Registration Option . . . . . . . . . . 6 5.2. Transaction ID . . . . . . . . . . . . . . . . . . . . . 6 5.3. Owner Unique ID . . . . . . . . . . . . . . . . . . . . . 7 5.4. Registering the Target Address . . . . . . . . . . . . . 8 5.5. Link-Local Addresses and Registration . . . . . . . . . . 8 5.6. Maintaining the Registration States . . . . . . . . . . . 10 6. Updated ND Options . . . . . . . . . . . . . . . . . . . . . 11 6.1. New 6LoWPAN capability Bits in the Capability Indication Option . . . . . . . . . . . . . . . . . . . . . . . . . 11 6.2. The Enhanced Address Registration Option (EARO) . . . . . 12 - 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 15 - 7.1. Discovering the capabilities of an ND peer . . . . . . . 15 - 7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 15 + 7. Backward Compatibility . . . . . . . . . . . . . . . . . . . 14 + 7.1. Discovering the capabilities of an ND peer . . . . . . . 14 + 7.1.1. Using the E Flag in the CIO . . . . . . . . . . . . . 14 7.1.2. Using the T Flag in the EARO . . . . . . . . . . . . 15 - 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 16 + 7.2. Legacy 6LoWPAN Node . . . . . . . . . . . . . . . . . . . 15 7.3. Legacy 6LoWPAN Router . . . . . . . . . . . . . . . . . . 16 7.4. Legacy 6LoWPAN Border Router . . . . . . . . . . . . . . 16 - 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 + 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 - 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 + 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 11.1. Normative References . . . . . . . . . . . . . . . . . . 20 11.2. Informative References . . . . . . . . . . . . . . . . . 21 - 11.3. External Informative References . . . . . . . . . . . . 24 + 11.3. External Informative References . . . . . . . . . . . . 23 Appendix A. Applicability and Requirements Served . . . . . . . 24 - Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 25 + Appendix B. Requirements . . . . . . . . . . . . . . . . . . . . 24 B.1. Requirements Related to Mobility . . . . . . . . . . . . 25 - B.2. Requirements Related to Routing Protocols . . . . . . . . 26 + B.2. Requirements Related to Routing Protocols . . . . . . . . 25 B.3. Requirements Related to the Variety of Low-Power Link - types . . . . . . . . . . . . . . . . . . . . . . . . . . 27 + types . . . . . . . . . . . . . . . . . . . . . . . . . . 26 B.4. Requirements Related to Proxy Operations . . . . . . . . 27 - B.5. Requirements Related to Security . . . . . . . . . . . . 28 - B.6. Requirements Related to Scalability . . . . . . . . . . . 29 + B.5. Requirements Related to Security . . . . . . . . . . . . 27 + B.6. Requirements Related to Scalability . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 1. Introduction RFC 6775, the "Neighbor Discovery Optimization for IPv6 over Low- Power Wireless Personal Area Networks (6LoWPANs)" [RFC6775] introduced a proactive registration mechanism to IPv6 Neighbor Discovery (ND) services that is well suited to nodes belonging to a Low Power Lossy Network (LLN). The scope of this draft is an IPv6 LLN, which can be a simple star or a more complex mesh topology. The LLN may be anchored at an IPv6 Backbone Router (6BBR) [I-D.ietf-6lo-backbone-router]. The 6BBRs interconnect the LLNs over a Backbone Link and emulate that the LLN nodes are present on the Backbone using proxy-ND operations. - This specification modifies and extends the behaviour and protocol + This specification modifies and extends the behavior and protocol elements of RFC 6775 [RFC6775] to enable additional capabilities, in particular the registration to a 6BBR for proxy ND operations. 2. Considerations On Registration Rejection The purpose of the Address Registration Option (ARO) RFC 6775 [RFC6775] and of the Extended ARO (EARO) that is introduced in this document is to facilitate duplicate address detection (DAD) for hosts and pre-populate Neighbor Cache Entries (NCE) [RFC4861] in the routers to reduce the need for sending multicast neighbor @@ -321,21 +321,21 @@ Networks" [I-D.ietf-6lo-ap-nd]. In any fashion, it is recommended that the node stores the unique Id or the keys used to generate that ID in persistent memory. Otherwise, it will be prevented to re-register after a reboot that would cause a loss of memory until the Backbone Router times out the registration. 5.4. Registering the Target Address - This specification changes the behaviour of the 6LN and the 6LR so + This specification changes the behavior of the 6LN and the 6LR so that the Registered Address is found in the Target Address field of the NS and NA messages as opposed to the Source Address. The reason for this change is to enable proxy-registrations on behalf of other nodes in Route-Over meshes, for instance to enable that a RPL root registers addresses on behalf LLN nodes that are deeper in a 6TiSCH mesh, as discussed in Appendix B.4. In that case, the Registering Node MUST indicate its own address as source of the ND message and its MAC address in the Source Link-Layer Address Option (SLLAO), since it still expects to get the packets and route them @@ -398,21 +398,21 @@ It is desired that a 6LR does not need to modify its state associated to the Source Address of an NS(EARO) message. For that reason, when possible, it is RECOMMENDED to use an address that is already registered with a 6LR When registering to a 6LR that conforms this specification, a node MUST use a Link-Local address as the source address of the registration, whatever the type of IPv6 address that is being registered. That Link-Local Address MUST be either already - registrered, or the address that is being registered. + registered, or the address that is being registered. When a Registering Node does not have an already-registered address, it MUST register a Link-Local address, using it as both the Source and the Target Address of an NS(EARO) message. In that case, it is RECOMMENDED to use a Link-Local address that is (expected to be) globally unique, e.g. derived from a burn-in MAC address. An EARO option in the response NA indicates that the 6LR supports this specification. Since there is no DAR/DAC exchange for Link-Local addresses, the 6LR @@ -486,46 +486,44 @@ DAC message bearing a Status of 0 "Success". If it is not the freshest, then a Status 2 "Moved" is returned instead, and the existing entry is conserved. The 6LBR SHOULD conserve the address in a DELAY state for a configurable period of time, so as to protect a mobile node that deregistered from one 6LR and did not register yet to a new one. 6. Updated ND Options This specification does not introduce new options, but it modifies - existing ones and updates the associated behaviours as follow: + existing ones and updates the associated behaviors as follow: 6.1. New 6LoWPAN capability Bits in the Capability Indication Option This specification defines a number of capability bits in the CIO that was introduced by RFC 7400 [RFC7400]. Support for this specification is indicated by setting the "E" flag in a CIO option. Routers that are capable of acting as 6LR, 6LBR and 6BBR SHOULD set the L, B andP flags, respectively. Those flags are not mutually exclusive and if a router is capable of multiple roles, it SHOULD set all the related flags. 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 = 1 |_____________________|L|B|P|E|G| - +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ - |_______________________________________________________________| + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |_______________________________________________________________| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: New capability Bits L, B, P, E in the CIO Option Fields - Type: 36 L: Node is a 6LR, it can take registrations. B: Node is a 6LBR. P: Node is a 6BBR, proxying for nodes on this link. E: This specification is supported and applied. @@ -616,21 +614,21 @@ | | rejection of a proxy registration to a Backbone Router | | | | | 5 | Proof requested: The registering node is challenged for | | | owning the registered address or for being an acceptable | | | proxy for the registration. This Status is expected in | | | asynchronous messages from a registrar (6LR, 6LBR, 6BBR) | | | to indicate that the registration state is removed, for | | | instance due to time out of a lifetime, or a movement. It | | | is used for instance by a 6BBR in a NA(ARO) message to | | | indicate that the ownership of the proxy state on the | - | | backbone was transfered to another 6BBR, which is | + | | backbone was transferred to another 6BBR, which is | | | indicative of a movement of the device. The receiver of | | | the NA is the device that has performed a registration | | | that is now stale and it should clean up its state. | | | | | 6 | Duplicate Source Address: The address used as source of | | | the NS(ARO) conflicts with an existing registration. | | | | | 7 | Invalid Source Address: The address used as source of the | | | NS(ARO) is not a Link-Local address as prescribed by this | | | document. | @@ -721,32 +719,32 @@ the 6LN was a legacy node. An updated 6LN will always use an EARO option in the registration NS message, whereas a legacy 6LN will always areply with an ARO option in the NA message. So from that first registration, the updated 6LN can figure whether the 6LR supports this specification or not. When facing a legacy 6LR, an updated 6LN may attempt to find an alternate 6LR that is updated. In order to be backward compatible, based on the discovery that a 6LR is legacy, the 6LN needs to - fallback to legacy behaviour and source the packet with the - registrered address. + fallback to legacy behavior and source the packet with the registered + address. The main difference is that the updated 6LN SHOULD use an EARO in the request regardless of the type of 6LN, legacy or updated 7.4. Legacy 6LoWPAN Border Router With this specification, the DAR/DAC transports an EARO option as opposed to an ARO option. As described for the NS/NA exchange, devices that support this specification always use an EARO option and - all the associated behaviour. + all the associated behavior. 8. Security Considerations This specification extends RFC 6775 [RFC6775], and the security section of that draft also applies to this as well. In particular, it is expected that the link layer is sufficiently protected to prevent a rogue access, either by means of physical or IP security on the Backbone Link and link layer cryptography on the LLN. This specification also expects that the LLN MAC provides secure unicast to/from the Backbone Router and secure Broadcast from the Backbone @@ -899,72 +897,51 @@ [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . - [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) - for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, - . - [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, . - [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy - Extensions for Stateless Address Autoconfiguration in - IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, - . - [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, . [RFC6282] Hui, J., Ed. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, DOI 10.17487/RFC6282, September 2011, . - [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, . [RFC7400] Bormann, C., "6LoWPAN-GHC: Generic Header Compression for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 7400, DOI 10.17487/RFC7400, November 2014, . - [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, - "Host Address Availability Recommendations", BCP 204, - RFC 7934, DOI 10.17487/RFC7934, July 2016, - . - 11.2. Informative References [I-D.chakrabarti-nordmark-6man-efficient-nd] Chakrabarti, S., Nordmark, E., Thubert, P., and M. Wasserman, "IPv6 Neighbor Discovery Optimizations for Wired and Wireless Networks", draft-chakrabarti-nordmark- 6man-efficient-nd-07 (work in progress), February 2015. [I-D.delcarpio-6lo-wlanah] Vega, L., Robles, I., and R. Morabito, "IPv6 over @@ -1033,46 +1010,67 @@ [RFC3971] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, DOI 10.17487/RFC3971, March 2005, . [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, DOI 10.17487/RFC3972, March 2005, . + [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) + for IPv6", RFC 4429, DOI 10.17487/RFC4429, April 2006, + . + [RFC4919] Kushalnagar, N., Montenegro, G., and C. Schumacher, "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals", RFC 4919, DOI 10.17487/RFC4919, August 2007, . + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, DOI 10.17487/RFC4941, 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, + . + [RFC7102] Vasseur, JP., "Terms Used in Routing for Low-Power and Lossy Networks", RFC 7102, DOI 10.17487/RFC7102, January 2014, . [RFC7217] Gont, F., "A Method for Generating Semantically Opaque Interface Identifiers with IPv6 Stateless Address Autoconfiguration (SLAAC)", RFC 7217, DOI 10.17487/RFC7217, April 2014, . [RFC7428] Brandt, A. and J. Buron, "Transmission of IPv6 Packets over ITU-T G.9959 Networks", RFC 7428, DOI 10.17487/RFC7428, February 2015, . [RFC7668] Nieminen, J., Savolainen, T., Isomaki, M., Patil, B., Shelby, Z., and C. Gomez, "IPv6 over BLUETOOTH(R) Low Energy", RFC 7668, DOI 10.17487/RFC7668, October 2015, . + [RFC7934] Colitti, L., Cerf, V., Cheshire, S., and D. Schinazi, + "Host Address Availability Recommendations", BCP 204, + RFC 7934, DOI 10.17487/RFC7934, July 2016, + . + 11.3. External Informative References [IEEEstd802154] IEEE, "IEEE Standard for Low-Rate Wireless Networks", IEEE Standard 802.15.4, DOI 10.1109/IEEESTD.2016.7460875, . Appendix A. Applicability and Requirements Served This specification extends 6LoWPAN ND to sequence the registration @@ -1086,21 +1084,21 @@ [I-D.ietf-6tisch-architecture] introduces how a 6LoWPAN ND host could connect to the Internet via a RPL mesh Network, but this requires additions to the 6LOWPAN ND protocol to support mobility and reachability in a secured and manageable environment. This specification details the new operations that are required to implement the 6TiSCH architecture and serves the requirements listed in Appendix B.2. The term LLN is used loosely in this specification to cover multiple types of WLANs and WPANs, including Low-Power Wi-Fi, BLUETOOTH(R) Low - Energy, IEEE std 802.11AH and IEEE std 802.15.4 wireless meshes, so + Energy, IEEE Std.802.11AH and IEEE Std.802.15.4 wireless meshes, so as to address the requirements discussed in Appendix B.3 This specification can be used by any wireless node to associate at Layer-3 with a 6BBR and register its IPv6 addresses to obtain routing services including proxy-ND operations over the backbone, effectively providing a solution to the requirements expressed in Appendix B.4. "Efficiency aware IPv6 Neighbor Discovery Optimizations" [I-D.chakrabarti-nordmark-6man-efficient-nd] suggests that 6LoWPAN ND [RFC6775] can be extended to other types of links beyond IEEE Std. @@ -1184,36 +1182,36 @@ option, a RPLInstanceID. Req2.3: Multicast operations SHOULD be supported and optimized, for instance using BIER or MPL. Whether ND is appropriate for the registration to the 6BBR is to be defined, considering the additional burden of supporting the Multicast Listener Discovery Version 2 [RFC3810] (MLDv2) for IPv6. B.3. Requirements Related to the Variety of Low-Power Link types - 6LoWPAN ND [RFC6775] was defined with a focus on IEEE std 802.15.4 + 6LoWPAN ND [RFC6775] was defined with a focus on IEEE Std.802.15.4 and in particular the capability to derive a unique Identifier from a globally unique MAC-64 address. At this point, the 6lo Working Group is extending the 6LoWPAN Header Compression (HC) [RFC6282] technique to other link types ITU-T G.9959 [RFC7428], Master-Slave/Token- Passing [I-D.ietf-6lo-6lobac], DECT Ultra Low Energy [I-D.ietf-6lo-dect-ule], Near Field Communication [I-D.ietf-6lo-nfc], - IEEE std 802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 + IEEE Std.802.11ah [I-D.delcarpio-6lo-wlanah], as well as IEEE1901.2 Narrowband Powerline Communication Networks [I-D.popa-6lo-6loplc-ipv6-over-ieee19012-networks] and BLUETOOTH(R) Low Energy [RFC7668]. Related requirements are: Req3.1: The support of the registration mechanism SHOULD be extended - to more LLN links than IEEE std 802.15.4, matching at least the LLN + to more LLN links than IEEE Std.802.15.4, matching at least the LLN links for which an "IPv6 over foo" specification exists, as well as Low-Power Wi-Fi. Req3.2: As part of this extension, a mechanism to compute a unique Identifier should be provided, with the capability to form a Link- Local Address that SHOULD be unique at least within the LLN connected to a 6LBR discovered by ND in each node within the LLN. Req3.3: The Address Registration Option used in the ND registration SHOULD be extended to carry the relevant forms of unique Identifier. @@ -1273,21 +1271,21 @@ their respective roles, as well as with the 6LoWPAN Node for the role of 6LR. Req5.2: 6LoWPAN ND security mechanisms SHOULD provide a mechanism for the 6LR and the 6LBR to validate new registration of authorized nodes. Joining of unauthorized nodes MUST be impossible. Req5.3: 6LoWPAN ND security mechanisms SHOULD lead to small packet sizes. In particular, the NS, NA, DAR and DAC messages for a re- registration flow SHOULD NOT exceed 80 octets so as to fit in a - secured IEEE std 802.15.4 [IEEEstd802154] frame. + secured IEEE Std.802.15.4 [IEEEstd802154] frame. Req5.4: Recurrent 6LoWPAN ND security operations MUST NOT be computationally intensive on the LoWPAN Node CPU. When a Key hash calculation is employed, a mechanism lighter than SHA-1 SHOULD be preferred. Req5.5: The number of Keys that the 6LoWPAN Node needs to manipulate SHOULD be minimized. Req5.6: The 6LoWPAN ND security mechanisms SHOULD enable the