diff options
| author | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
|---|---|---|
| committer | Thomas Voss <mail@thomasvoss.com> | 2024-11-27 20:54:24 +0100 |
| commit | 4bfd864f10b68b71482b35c818559068ef8d5797 (patch) | |
| tree | e3989f47a7994642eb325063d46e8f08ffa681dc /doc/rfc/rfc6775.txt | |
| parent | ea76e11061bda059ae9f9ad130a9895cc85607db (diff) | |
doc: Add RFC documents
Diffstat (limited to 'doc/rfc/rfc6775.txt')
| -rw-r--r-- | doc/rfc/rfc6775.txt | 3083 |
1 files changed, 3083 insertions, 0 deletions
diff --git a/doc/rfc/rfc6775.txt b/doc/rfc/rfc6775.txt new file mode 100644 index 0000000..19addef --- /dev/null +++ b/doc/rfc/rfc6775.txt @@ -0,0 +1,3083 @@ + + + + + + +Internet Engineering Task Force (IETF) Z. Shelby, Ed. +Request for Comments: 6775 Sensinode +Updates: 4944 S. Chakrabarti +Category: Standards Track Ericsson +ISSN: 2070-1721 E. Nordmark + Cisco Systems + C. Bormann + Universitaet Bremen TZI + November 2012 + + + Neighbor Discovery Optimization for IPv6 over Low-Power Wireless + Personal Area Networks (6LoWPANs) + +Abstract + + The IETF work in IPv6 over Low-power Wireless Personal Area Network + (6LoWPAN) defines 6LoWPANs such as IEEE 802.15.4. This and other + similar link technologies have limited or no usage of multicast + signaling due to energy conservation. In addition, the wireless + network may not strictly follow the traditional concept of IP subnets + and IP links. IPv6 Neighbor Discovery was not designed for non- + transitive wireless links, as its reliance on the traditional IPv6 + link concept and its heavy use of multicast make it inefficient and + sometimes impractical in a low-power and lossy network. This + document describes simple optimizations to IPv6 Neighbor Discovery, + its addressing mechanisms, and duplicate address detection for Low- + power Wireless Personal Area Networks and similar networks. The + document thus updates RFC 4944 to specify the use of the + optimizations defined here. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6775. + + + + + + + +Shelby, et al. Standards Track [Page 1] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +Copyright Notice + + Copyright (c) 2012 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 + 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. + +Table of Contents + + 1. Introduction ....................................................4 + 1.1. The Shortcomings of IPv6 Neighbor Discovery ................5 + 1.2. Applicability ..............................................6 + 1.3. Goals and Assumptions ......................................7 + 1.4. Substitutable Features .....................................8 + 2. Terminology .....................................................9 + 3. Protocol Overview ..............................................11 + 3.1. Extensions to RFC 4861 ....................................11 + 3.2. Address Assignment ........................................12 + 3.3. Host-to-Router Interaction ................................13 + 3.4. Router-to-Router Interaction ..............................14 + 3.5. Neighbor Cache Management .................................14 + 4. New Neighbor Discovery Options and Messages ....................15 + 4.1. Address Registration Option ...............................15 + 4.2. 6LoWPAN Context Option ....................................17 + 4.3. Authoritative Border Router Option ........................19 + 4.4. Duplicate Address Messages ................................20 + 5. Host Behavior ..................................................22 + 5.1. Forbidden Actions .........................................22 + 5.2. Interface Initialization ..................................22 + 5.3. Sending a Router Solicitation .............................23 + 5.4. Processing a Router Advertisement .........................23 + 5.4.1. Address Configuration ..............................23 + 5.4.2. Storing Contexts ...................................24 + 5.4.3. Maintaining Prefix and Context Information .........24 + 5.5. Registration and Neighbor Unreachability Detection ........25 + 5.5.1. Sending a Neighbor Solicitation ....................25 + 5.5.2. Processing a Neighbor Advertisement ................25 + 5.5.3. Recovering from Failures ...........................26 + 5.6. Next-Hop Determination ....................................26 + 5.7. Address Resolution ........................................27 + + + +Shelby, et al. Standards Track [Page 2] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 5.8. Sleeping ..................................................27 + 5.8.1. Picking an Appropriate Registration Lifetime .......27 + 5.8.2. Behavior on Wakeup .................................28 + 6. Router Behavior for 6LRs and 6LBRs .............................28 + 6.1. Forbidden Actions .........................................28 + 6.2. Interface Initialization ..................................29 + 6.3. Processing a Router Solicitation ..........................29 + 6.4. Periodic Router Advertisements ............................30 + 6.5. Processing a Neighbor Solicitation ........................30 + 6.5.1. Checking for Duplicates ............................30 + 6.5.2. Returning Address Registration Errors ..............31 + 6.5.3. Updating the Neighbor Cache ........................31 + 6.5.4. Next-Hop Determination .............................32 + 6.5.5. Address Resolution between Routers .................32 + 7. Border Router Behavior .........................................32 + 7.1. Prefix Determination ......................................33 + 7.2. Context Configuration and Management ......................33 + 8. Substitutable Feature Behavior .................................34 + 8.1. Multihop Prefix and Context Distribution ..................34 + 8.1.1. 6LBRs Sending Router Advertisements ................35 + 8.1.2. Routers Sending Router Solicitations ...............35 + 8.1.3. Routers Processing Router Advertisements ...........35 + 8.1.4. Storing the Information ............................36 + 8.1.5. Sending Router Advertisements ......................36 + 8.2. Multihop Duplicate Address Detection ......................37 + 8.2.1. Message Validation for DAR and DAC .................38 + 8.2.2. Conceptual Data Structures .........................39 + 8.2.3. 6LR Sending a Duplicate Address Request ............39 + 8.2.4. 6LBR Receiving a Duplicate Address Request .........39 + 8.2.5. Processing a Duplicate Address Confirmation ........40 + 8.2.6. Recovering from Failures ...........................40 + 9. Protocol Constants .............................................41 + 10. Examples ......................................................42 + 10.1. Message Examples .........................................42 + 10.2. Host Bootstrapping Example ...............................43 + 10.2.1. Host Bootstrapping Messages .......................45 + 10.3. Router Interaction Example ...............................46 + 10.3.1. Bootstrapping a Router ............................46 + 10.3.2. Updating the Neighbor Cache .......................47 + 11. Security Considerations .......................................47 + 12. IANA Considerations ...........................................48 + 13. Interaction with Other Neighbor Discovery Extensions ..........49 + 14. Guidelines for New Features ...................................49 + 15. Acknowledgments ...............................................52 + 16. References ....................................................52 + 16.1. Normative References .....................................52 + 16.2. Informative References ...................................53 + + + + +Shelby, et al. Standards Track [Page 3] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +1. Introduction + + The IPv6-over-IEEE 802.15.4 [RFC4944] document specifies how IPv6 is + carried over an IEEE 802.15.4 network with the help of an adaptation + layer that sits between the Media Access Control (MAC) layer and the + IP network layer. A link in a Low-power Wireless Personal Area + Network (LoWPAN) is characterized as lossy, low-power, low-bit-rate, + short-range; with many nodes saving energy with long sleep periods. + Multicast as used in IPv6 Neighbor Discovery (ND) [RFC4861] is not + desirable in such a wireless low-power and lossy network. Moreover, + LoWPAN links are asymmetric and non-transitive in nature. A LoWPAN + is potentially composed of a large number of overlapping radio + ranges. Although a given radio range has broadcast capabilities, the + aggregation of these is a complex Non-Broadcast Multiple Access + (NBMA) [RFC2491] structure with generally no LoWPAN-wide multicast + capabilities. Link-local scope is in reality defined by reachability + and radio strength. Thus, we can consider a LoWPAN to be made up of + links with undetermined connectivity properties as in [RFC5889], + along with the corresponding address model assumptions defined + therein. + + This specification introduces the following optimizations to IPv6 + Neighbor Discovery [RFC4861] specifically aimed at low-power and + lossy networks such as LoWPANs: + + o Host-initiated interactions to allow for sleeping hosts. + + o Elimination of multicast-based address resolution for hosts. + + o A host address registration feature using a new option in unicast + Neighbor Solicitation (NS) and Neighbor Advertisement (NA) + messages. + + o A new Neighbor Discovery option to distribute 6LoWPAN header + compression context to hosts. + + o Multihop distribution of prefix and 6LoWPAN header compression + context. + + o Multihop Duplicate Address Detection (DAD), which uses two new + ICMPv6 message types. + + The two multihop items can be substituted by a routing protocol + mechanism if that is desired; see Section 1.4. + + + + + + + +Shelby, et al. Standards Track [Page 4] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + The document defines three new ICMPv6 message options: the Address + Registration Option (ARO), the Authoritative Border Router Option + (ABRO), and the 6LoWPAN Context Option (6CO). It also defines two + new ICMPv6 message types: the Duplicate Address Request (DAR) and the + Duplicate Address Confirmation (DAC). + +1.1. The Shortcomings of IPv6 Neighbor Discovery + + IPv6 Neighbor Discovery [RFC4861] provides several important + mechanisms used for router discovery, address resolution, Duplicate + Address Detection, and Redirect messages, along with prefix and + parameter discovery. + + Following power-on and initialization of the network in IPv6 Ethernet + networks, a node joins the solicited-node multicast address on the + interface and then performs Duplicate Address Detection (DAD) for the + acquired link-local address by sending a solicited-node multicast + message to the link. After that, it sends multicast messages to the + all-routers multicast address to solicit Router Advertisements (RAs). + If the host receives a valid RA with the A (autonomous address + configuration) flag, it autoconfigures the IPv6 address with the + advertised prefix in the RA message. Besides this, the IPv6 routers + usually send RAs periodically on the network. RAs are sent to the + all-nodes multicast address. Nodes send Neighbor Solicitation/ + Neighbor Advertisement messages to resolve the IPv6 address of the + destination on the link. The Neighbor Solicitation messages used for + address resolution are multicast. The Duplicate Address Detection + procedure and the use of periodic Router Advertisement messages + assume that the nodes are powered on and reachable most of the time. + + In Neighbor Discovery, the routers find the hosts by assuming that a + subnet prefix maps to one broadcast domain, and then they multicast + Neighbor Solicitation messages to find the host and its link-layer + address. Furthermore, the DAD use of multicast assumes that all + hosts that autoconfigure IPv6 addresses from the same prefix can be + reached using link-local multicast messages. + + Note that the L (on-link) bit in the Prefix Information Option (PIO) + can be set to zero in Neighbor Discovery, which makes the host not + use multicast Neighbor Solicitation (NS) messages for address + resolution of other hosts, but routers still use multicast NS + messages to find the hosts. + + Due to the lossy nature of wireless communication and a changing + radio environment, the IPv6-link node-set may change due to external + physical factors. Thus, the link is often unstable, and the nodes + appear to be moving without necessarily moving physically. + + + + +Shelby, et al. Standards Track [Page 5] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + A LoWPAN can use two types of link-layer addresses: 16-bit short + addresses and 64-bit unique addresses as defined in [RFC4944]. + Moreover, the available link-layer payload size is on the order of + less than 100 bytes; thus, header compression is very useful. + + Considering the above characteristics in a LoWPAN, and the IPv6 + Neighbor Discovery [RFC4861] protocol design, some optimizations and + extensions to Neighbor Discovery are useful for the wide deployment + of IPv6 over low-power and lossy networks (example: 6LoWPAN and other + homogeneous low-power networks). + +1.2. Applicability + + In its Section 1, [RFC4861] foresees a document that covers operating + IP over a particular link type and defines an exception to the + otherwise general applicability of unmodified [RFC4861]. The present + specification improves the usage of IPv6 Neighbor Discovery for + LoWPANs in order to save energy and processing power of such nodes. + This document thus updates [RFC4944] to specify the use of the + optimizations defined here. + + The applicability of this specification is limited to LoWPANs where + all nodes on the subnet implement these optimizations in a + homogeneous way. Although it is noted that some of these + optimizations may be useful outside of 6LoWPANs, for example, in + general IPv6 low-power and lossy networks and possibly even in + combination with [RFC4861], the usage of such combinations is out of + scope of this document. + + In this document, we specify a set of behaviors between hosts and + routers in LoWPANs. An implementation that adheres to this document + MUST implement those behaviors. The document also specifies a set of + behaviors (multihop prefix or context dissemination and, separately, + multihop Duplicate Address Detection) that are needed in route-over + configurations. An implementation of this specification MUST support + those pieces, unless the implementation supports some alternative + ("substitute") from some other specification. + + The optimizations described in this document apply to different + topologies. They are most useful for route-over and mesh-under + configurations in Mesh topologies. However, Star topology + configurations will also benefit from the optimizations due to + reduced signaling, robust handling of the non-transitive link, and + header compression context information. + + + + + + + +Shelby, et al. Standards Track [Page 6] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +1.3. Goals and Assumptions + + The document has the following main goals and assumptions. + + Goals: + + o Optimize Neighbor Discovery with a mechanism that is minimal yet + sufficient for the operation in both mesh-under and route-over + configurations. + + o Minimize signaling by avoiding the use of multicast flooding and + reducing the use of link-scope multicast messages. + + o Optimize the interfaces between hosts and their default routers. + + o Provide support for sleeping hosts. + + o Disseminate context information to hosts as needed by 6LoWPAN + header compression [RFC6282]. + + o Disseminate context information and prefix information from the + border to all routers in a LoWPAN. + + o Provide a multihop Duplicate Address Detection mechanism suitable + for route-over LoWPANs. + + Assumptions: + + o 64-bit Extended Unique Identifier (EUI-64) [EUI64] addresses are + globally unique, and the LoWPAN is homogeneous. + + o All nodes in the network have an EUI-64 Interface ID in order to + do address autoconfiguration and detect duplicate addresses. + + o The link-layer technology is assumed to be low-power and lossy, + exhibiting undetermined connectivity, such as IEEE 802.15.4 + [RFC4944]. However, the address registration mechanism might be + useful for other link-layer technologies. + + o A 6LoWPAN is configured to share one or more global IPv6 address + prefixes to enable hosts to move between routers in the LoWPAN + without changing their IPv6 addresses. + + o When using the multihop DAD mechanism (Section 8.2), each 6LoWPAN + Router (6LR) registers with all the 6LoWPAN Border Routers (6LBRs) + available in the LoWPAN. + + + + + +Shelby, et al. Standards Track [Page 7] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + o If IEEE 802.15.4 16-bit short addresses are used, then some + technique is used to ensure the uniqueness of those link-layer + addresses. That could be done using DHCPv6, Address Registration + Option-based Duplicate Address Detection (specified in + Section 8.2), or other techniques outside of the scope of this + document. + + o In order to preserve the uniqueness of addresses (see Section 5.4 + of [RFC4862]) not derived from an EUI-64, they must be either + assigned or checked for duplicates in the same way throughout the + LoWPAN. This can be done using DHCPv6 for assignment and/or using + the Duplicate Address Detection mechanism specified in Section 8.2 + (or any other protocols developed for that purpose). + + o In order for 6LoWPAN header compression [RFC6282] to operate + correctly, the compression context must match for all the hosts, + 6LRs, and 6LBRs that can send, receive, or forward a given packet. + If Section 8.1 is used to distribute context information, this + implies that all the 6LBRs must coordinate the context information + they distribute within a single LoWPAN. + + o This specification describes the operation of ND within a single + LoWPAN. The participation of a node in multiple LoWPANs + simultaneously may be possible but is out of scope of this + document. + + o Since the LoWPAN shares its prefix(es) throughout the network, + mobility of nodes within the LoWPAN is transparent. Inter-LoWPAN + mobility is out of scope of this document. + +1.4. Substitutable Features + + This document defines the optimization of Neighbor Discovery messages + for the host-router interface and introduces two new mechanisms in a + route-over topology. + + Unless specified otherwise (in a document that defines a routing + protocol that is used in a 6LoWPAN), this document applies to + networks with any routing protocol. However, because the routing + protocol may provide good alternate mechanisms, this document defines + certain features as "substitutable", meaning they can be substituted + by a routing protocol specification that provides mechanisms + achieving the same overall effect. + + + + + + + + +Shelby, et al. Standards Track [Page 8] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + The features that are substitutable (individually or in a group): + + o Multihop distribution of prefix and 6LoWPAN header compression + context + + o Multihop Duplicate Address Detection + + Thus, multihop prefix distribution (the ABRO) and the 6LoWPAN Context + Option (6CO) for distributing header compression contexts go hand in + hand. If substitution is intended for one of them, then both of them + MUST be substituted. + + Guidelines for feature implementation and deployment are provided in + Section 14. + +2. Terminology + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + + This specification requires readers to be familiar with all the terms + and concepts that are discussed in "Neighbor Discovery for IP + version 6 (IPv6)" [RFC4861], "IPv6 Stateless Address + Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal + Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, + and Goals" [RFC4919], "Transmission of IPv6 Packets over IEEE + 802.15.4 Networks" [RFC4944], and "IP Addressing Model in Ad Hoc + Networks" [RFC5889]. + + This specification makes extensive use of the same terminology + defined in [RFC4861], unless otherwise defined below. + + 6LoWPAN link: + A wireless link determined by single IP hop reachability of + neighboring nodes. These are considered links with undetermined + connectivity properties as in [RFC5889]. + + 6LoWPAN Node (6LN): + A 6LoWPAN node is any host or router participating in a LoWPAN. + This term is used when referring to situations in which either a + host or router can play the role described. + + 6LoWPAN Router (6LR): + An intermediate router in the LoWPAN that is able to send and + receive Router Advertisements (RAs) and Router Solicitations (RSs) + as well as forward and route IPv6 packets. 6LoWPAN routers are + present only in route-over topologies. + + + +Shelby, et al. Standards Track [Page 9] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 6LoWPAN Border Router (6LBR): + A border router located at the junction of separate 6LoWPAN + networks or between a 6LoWPAN network and another IP network. + There may be one or more 6LBRs at the 6LoWPAN network boundary. A + 6LBR is the responsible authority for IPv6 prefix propagation for + the 6LoWPAN network it is serving. An isolated LoWPAN also + contains a 6LBR in the network, which provides the prefix(es) for + the isolated network. + + Router: + Either a 6LR or a 6LBR. Note that nothing in this document + precludes a node being a router on some interfaces and a host on + other interfaces as allowed by [RFC2460]. + + Mesh-under: + A topology where nodes are connected to a 6LBR through a mesh + using link-layer forwarding. Thus, in a mesh-under configuration, + all IPv6 hosts in a LoWPAN are only one IP hop away from the 6LBR. + This topology simulates the typical IP-subnet topology with one + router with multiple nodes in the same subnet. + + Route-over: + A topology where hosts are connected to the 6LBR through the use + of intermediate layer-3 (IP) routing. Here, hosts are typically + multiple IP hops away from a 6LBR. The route-over topology + typically consists of a 6LBR, a set of 6LRs, and hosts. + + Non-transitive link: + A link that exhibits asymmetric reachability as defined in + Section 2.2 of [RFC4861]. + + IP-over-foo document: + A specification that covers operating IP over a particular link + type, for example, [RFC4944] "Transmission of IPv6 Packets over + IEEE 802.15.4 Networks". + + Header compression context: + Address information shared across a LoWPAN and used by 6LoWPAN + header compression [RFC6282] to enable the elision of information + that would otherwise be sent repeatedly. In a "context", a + (potentially partial) address is associated with a Context + Identifier (CID), which is then used in header compression as a + shortcut for (parts of) a source or destination address. + + + + + + + + +Shelby, et al. Standards Track [Page 10] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Registration: + The process during which a LoWPAN node sends a Neighbor + Solicitation message with an Address Registration Option to a + router creating a Neighbor Cache Entry (NCE) for the LoWPAN node + with a specific timeout. Thus, for 6LoWPAN routers, the Neighbor + Cache doesn't behave like a cache. Instead, it behaves as a + registry of all the host addresses that are attached to the + router. + +3. Protocol Overview + + These Neighbor Discovery optimizations are applicable to both + mesh-under and route-over configurations. In a mesh-under + configuration, only 6LoWPAN Border Routers and hosts exist; there are + no 6LoWPAN routers in mesh-under topologies. + + The most important part of the optimizations is the evolved host-to- + router interaction that allows for sleeping nodes and avoids using + multicast Neighbor Discovery messages except for the case of a host + finding an initial set of default routers, and redoing such + determination when that set of routers have become unreachable. + + The protocol also provides for header compression [RFC6282] by + carrying header compression information in a new option in Router + Advertisement messages. + + In addition, there are separate mechanisms that can be used between + 6LRs and 6LBRs to perform multihop Duplicate Address Detection and + distribution of the prefix and compression context information from + the 6LBRs to all the 6LRs, which in turn use normal Neighbor + Discovery mechanisms to convey this information to the hosts. + + The protocol is designed so that the host-to-router interaction is + not affected by the configuration of the 6LoWPAN; the host-to-router + interaction is the same in a mesh-under and route-over configuration. + +3.1. Extensions to RFC 4861 + + This document specifies the following optimizations and extensions to + IPv6 Neighbor Discovery [RFC4861]: + + o Host-initiated refresh of Router Advertisement information. This + removes the need for periodic or unsolicited Router Advertisements + from routers to hosts. + + o No Duplicate Address Detection (DAD) is performed if EUI-64-based + IPv6 addresses are used (as these addresses are assumed to be + globally unique). + + + +Shelby, et al. Standards Track [Page 11] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + o DAD is optional if DHCPv6 is used to assign addresses. + + o A new address registration mechanism using a new Address + Registration Option between hosts and routers. This removes the + need for routers to use multicast Neighbor Solicitations to find + hosts and supports sleeping hosts. This also enables the same + IPv6 address prefix(es) to be used across a route-over 6LoWPAN. + It provides the host-to-router interface for Duplicate Address + Detection. + + o A new Router Advertisement option, the 6LoWPAN Context Option, for + context information used by 6LoWPAN header compression. + + o A new mechanism to perform Duplicate Address Detection across a + route-over 6LoWPAN using the new Duplicate Address Request and + Duplicate Address Confirmation messages. + + o New mechanisms to distribute prefixes and context information + across a route-over network that uses a new Authoritative Border + Router Option to control the flooding of configuration changes. + + o A few new default protocol constants are introduced, and some + existing Neighbor Discovery protocol constants are tuned. + +3.2. Address Assignment + + Hosts in a 6LoWPAN configure their IPv6 addresses as specified in + [RFC4861] and [RFC4862] based on the information received in Router + Advertisement messages. The use of the M (managed address + configuration) flag in this optimization is, however, more + restrictive than in [RFC4861]. When the M flag is set, a host is + assumed to use DHCPv6 to assign any non-EUI-64 addresses. When the M + flag is not set, the nodes in the LoWPAN support Duplicate Address + Detection; thus, a host can then safely use the address registration + mechanism to check non-EUI-64 addresses for uniqueness. + + 6LRs MAY use the same mechanisms to configure their IPv6 addresses. + + The 6LBRs are responsible for managing the prefix(es) assigned to the + 6LoWPAN, using manual configuration, DHCPv6 Prefix Delegation + [RFC3633], or other mechanisms. In an isolated LoWPAN, a Unique + Local Address (ULA) [RFC4193] prefix SHOULD be generated by the 6LBR. + + + + + + + + + +Shelby, et al. Standards Track [Page 12] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +3.3. Host-to-Router Interaction + + A host sends Router Solicitation messages at startup and also when + the Neighbor Unreachability Detection (NUD) of one of its default + routers fails. + + Hosts receive Router Advertisement messages typically containing the + Authoritative Border Router Option (ABRO) and may optionally contain + one or more 6LoWPAN Context Options (6COs) in addition to the + existing Prefix Information Options (PIOs) as described in [RFC4861]. + + When a host has configured a non-link-local IPv6 address, it + registers that address with one or more of its default routers using + the Address Registration Option (ARO) in an NS message. The host + chooses a lifetime of the registration and repeats the ARO + periodically (before the lifetime runs out) to maintain the + registration. The lifetime should be chosen in such a way as to + maintain the registration even while a host is sleeping. Likewise, + mobile nodes that often change their point of attachment should use a + suitably short lifetime. See Section 5.5 for registration details + and Section 9 for protocol constants. + + The registration fails when an ARO is returned to the host with a + non-zero Status. One reason may be that the router determines that + the IPv6 address is already used by another host, i.e., is used by a + host with a different EUI-64. This can be used to support + non-EUI-64-based addresses such as temporary IPv6 addresses [RFC4941] + or addresses based on an Interface ID that is an IEEE 802.15.4 16-bit + short address. Failure can also occur if the Neighbor Cache on that + router is full. + + The re-registration of an address can be combined with Neighbor + Unreachability Detection (NUD) of the router, since both use unicast + Neighbor Solicitation messages. This makes things efficient when a + host wakes up to send a packet and needs to both perform NUD to check + that the router is still reachable and refresh its registration with + the router. + + The response to an address registration might not be immediate, since + in route-over configurations the 6LR might perform Duplicate Address + Detection against the 6LBR. A host retransmits the Address + Registration Option until it is acknowledged by the receipt of an + Address Registration Option. + + As part of the optimizations, address resolution is not performed by + multicasting Neighbor Solicitation messages as in [RFC4861]. + Instead, the routers maintain Neighbor Cache Entries for all + registered IPv6 addresses. If the address is not in the Neighbor + + + +Shelby, et al. Standards Track [Page 13] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Cache in the router, then the address either doesn't exist, is + assigned to a host attached to some other router in the 6LoWPAN, or + is external to the 6LoWPAN. In a route-over configuration, the + routing protocol is used to route such packets toward the + destination. + +3.4. Router-to-Router Interaction + + The new router-to-router interaction is only for the route-over + configuration where 6LRs are present. See also Section 1.4. + + 6LRs MUST act like a host during system startup and prefix + configuration by sending Router Solicitation messages and + autoconfiguring their IPv6 addresses, unlike routers in [RFC4861]. + + When multihop prefix and context dissemination are used, then the + 6LRs store the ABRO, 6CO, and prefix information received (directly + or indirectly) from the 6LBRs and redistribute this information in + the Router Advertisement they send to other 6LRs or send to hosts in + response to a Router Solicitation. There is a Version Number field + in the ABRO (see Section 4.3), which is used to limit the flooding of + updated information between the 6LRs. + + A 6LR can perform Duplicate Address Detection against one or more + 6LBRs using the new Duplicate Address Request (DAR) and Duplicate + Address Confirmation (DAC) messages, which carry the information from + the Address Registration Option. The DAR and DAC messages will be + forwarded between the 6LR and 6LBRs; thus, the [RFC4861] rule for + checking hop limit=255 does not apply to the DAR and DAC messages. + Those multihop DAD messages MUST NOT modify any Neighbor Cache + Entries on the routers, since we do not have the security benefits + provided by the hop limit=255 check. + +3.5. Neighbor Cache Management + + The use of explicit registrations with lifetimes, plus the desire to + not multicast Neighbor Solicitation messages for hosts, imply that we + manage the Neighbor Cache Entries (NCEs) slightly differently than in + [RFC4861]. This results in three different types of NCEs, and the + types specify how those entries can be removed: + + Garbage-collectible: Entries that are subject to the normal rules in + [RFC4861] that allow for garbage collection + when low on memory. + + Registered: Entries that have an explicit registered + lifetime and are kept until this lifetime + expires or they are explicitly unregistered. + + + +Shelby, et al. Standards Track [Page 14] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Tentative: Entries that are temporary with a short + lifetime, which typically get converted to + Registered entries. + + Note that the type of the NCE is orthogonal to the states specified + in [RFC4861]. + + When a host interacts with a router by sending Router Solicitations, + this results in a Tentative NCE. Once a router has successfully had + a node register with it, the result is a Registered NCE. When + routers send RAs to hosts, and when routers receive RA messages or + receive multicast NS messages from other routers, the result is + Garbage-collectible NCEs. There can only be one kind of NCE for an + IP address at a time. + + Neighbor Cache Entries on routers can additionally be added or + deleted by a routing protocol used in the 6LoWPAN. This is useful if + the routing protocol carries the link-layer addresses of the + neighboring routers. Depending on the details of such routing + protocols, such NCEs could be either Registered or + Garbage-collectible. + +4. New Neighbor Discovery Options and Messages + + This section defines new Neighbor Discovery message options used by + this specification. The Address Registration Option is used by + hosts, whereas the Authoritative Border Router Option and 6LoWPAN + Context Option are used in the substitutable router-to-router + interaction. This section also defines the new router-to-router + Duplicate Address Request and Duplicate Address Confirmation + messages. + +4.1. Address Registration Option + + The routers need to know the set of host IP addresses that are + directly reachable and their corresponding link-layer addresses. + This needs to be maintained as the radio reachability changes. For + this purpose, an Address Registration Option (ARO) is introduced, + which can be included in unicast NS messages sent by hosts. Thus, it + can be included in the unicast NS messages that a host sends as part + of NUD to determine that it can still reach a default router. The + ARO is used by the receiving router to reliably maintain its Neighbor + Cache. The same option is included in corresponding NA messages with + a Status field indicating the success or failure of the registration. + This option is always host initiated. + + + + + + +Shelby, et al. Standards Track [Page 15] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + The information contained in the ARO is also included in the multihop + DAR and DAC messages used between 6LRs and 6LBRs, but the option + itself is not used in those messages. + + The ARO is required for reliability and power saving. The lifetime + field provides flexibility to the host to register an address that + should be usable (continue to be advertised by the 6LR in the routing + protocol, etc.) during its intended sleep schedule. + + The sender of the NS also includes the EUI-64 [EUI64] of the + interface from which it is registering an address. This is used as a + unique ID for the detection of duplicate addresses. It is used to + tell the difference between the same node re-registering its address + and a different node (with a different EUI-64) registering an address + that is already in use by someone else. The EUI-64 is also used to + deliver an NA carrying an error Status code to the EUI-64-based + link-local IPv6 address of the host (see Section 6.5.2). + + When the ARO is used by hosts, an SLLAO (Source Link-Layer Address + Option) [RFC4861] MUST be included, and the address that is to be + registered MUST be the IPv6 source address of the NS message. + + 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 = 2 | Status | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Registration Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + EUI-64 + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type: 33 + + Length: 8-bit unsigned integer. The length of the + option in units of 8 bytes. Always 2. + + Status: 8-bit unsigned integer. Indicates the status + of a registration in the NA response. MUST + be set to 0 in NS messages. See below. + + Reserved: This field is unused. It MUST be initialized + to zero by the sender and MUST be ignored by + the receiver. + + + +Shelby, et al. Standards Track [Page 16] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Registration Lifetime: 16-bit unsigned integer. The amount of time + in units of 60 seconds that the router should + retain the NCE for the sender of the NS that + includes this option. + + EUI-64: 64 bits. This field is used to uniquely + identify the interface of the Registered + Address by including the EUI-64 identifier + [EUI64] assigned to it unmodified. + + The Status values used in NAs are: + + +--------+--------------------------------------------+ + | Status | Description | + +--------+--------------------------------------------+ + | 0 | Success | + | 1 | Duplicate Address | + | 2 | Neighbor Cache Full | + | 3-255 | Allocated using Standards Action [RFC5226] | + +--------+--------------------------------------------+ + + Table 1 + +4.2. 6LoWPAN Context Option + + The 6LoWPAN Context Option (6CO) carries prefix information for + LoWPAN header compression and is similar to the PIO of [RFC4861]. + However, the prefixes can be remote as well as local to the LoWPAN, + since header compression potentially applies to all IPv6 addresses. + This option allows for the dissemination of multiple contexts + identified by a CID for use as specified in [RFC6282]. A context may + be a prefix of any length or an address (/128), and up to 16 6COs may + be carried in an RA message. + + 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 |Context Length | Res |C| CID | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + . . + . Context Prefix . + . . + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Figure 1: 6LoWPAN Context Option Format + + + + +Shelby, et al. Standards Track [Page 17] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Type: 34 + + Length: 8-bit unsigned integer. The length of the option + (including the Type and Length fields) in units of + 8 bytes. May be 2 or 3, depending on the length of + the Context Prefix field. + + Context Length: 8-bit unsigned integer. The number of leading bits + in the Context Prefix field that are valid. The + value ranges from 0 to 128. If it is more than 64, + then the Length MUST be 3. + + C: 1-bit context Compression flag. This flag indicates + if the context is valid for use in compression. A + context that is not valid MUST NOT be used for + compression but SHOULD be used in decompression in + case another compressor has not yet received the + updated context information. This flag is used to + manage the context life cycle based on the + recommendations in Section 7.2. + + CID: 4-bit Context Identifier for this prefix + information. The CID is used by context-based + header compression as specified in [RFC6282]. The + list of CIDs for a LoWPAN is configured on the 6LBR + that originates the context information for the + 6LoWPAN. + + Res, Reserved: This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Valid Lifetime: 16-bit unsigned integer. The length of time in + units of 60 seconds (relative to the time the packet + is received) that the context is valid for the + purpose of header compression or decompression. A + value of all zero bits (0x0) indicates that this + context entry MUST be removed immediately. + + Context Prefix: The IPv6 prefix or address corresponding to the CID + field. The valid length of this field is included + in the Context Length field. This field is padded + with zeros in order to make the option a multiple of + 8 bytes. + + + + + + + +Shelby, et al. Standards Track [Page 18] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +4.3. Authoritative Border Router Option + + The Authoritative Border Router Option (ABRO) is needed when RA + messages are used to disseminate prefixes and context information + across a route-over topology. In this case, 6LRs receive PIOs from + other 6LRs. This implies that a 6LR can't just let the most recently + received RA win. In order to be able to reliably add and remove + prefixes from the 6LoWPAN, we need to carry information from the + authoritative 6LBR. This is done by introducing a version number + that the 6LBR sets and that 6LRs propagate as they propagate the + prefix and context information with this ABRO. When there are + multiple 6LBRs, they would have separate version number spaces. + Thus, this option needs to carry the IP address of the 6LBR that + originated that set of information. + + The ABRO MUST be included in all RA messages in the case when RAs are + used to propagate information between routers (as described in + Section 8.2). + + 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 = 3 | Version Low | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Version High | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + 6LBR Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type: 35 + + Length: 8-bit unsigned integer. The length of + the option in units of 8 bytes. + Always 3. + + Version Low, Version High: Together, Version Low and Version High + constitute the Version Number field, a + 32-bit unsigned integer where Version Low + is the least significant 16 bits and + Version High is the most significant + + + +Shelby, et al. Standards Track [Page 19] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 16 bits. The version number + corresponding to this set of information + contained in the RA message. The + authoritative 6LBR originating the prefix + increases this version number each time + its set of prefix or context information + changes. + + Valid Lifetime: 16-bit unsigned integer. The length of + time in units of 60 seconds (relative to + the time the packet is received) that + this set of border router information is + valid. A value of all zero bits (0x0) + assumes a default value of 10,000 + (~one week). + + Reserved: This field is unused. It MUST be + initialized to zero by the sender and + MUST be ignored by the receiver. + + 6LBR Address: IPv6 address of the 6LBR that is the + origin of the included version number. + +4.4. Duplicate Address Messages + + For the multihop DAD exchanges between a 6LR and 6LBR as specified in + Section 8.2, there are two new ICMPv6 message types called the + Duplicate Address Request (DAR) and the Duplicate Address + Confirmation (DAC). We avoid reusing the NS and NA messages for this + purpose, since these messages are not subject to the hop limit=255 + check as they are forwarded by intermediate 6LRs. The information + contained in the messages is otherwise the same as would be in an NS + carrying an ARO, with the message format inlining the fields that are + in the ARO. + + The DAR and DAC use the same message format with different ICMPv6 + type values, and the Status field is only meaningful in the DAC + message. + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 20] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 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 | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Status | Reserved | Registration Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + EUI-64 + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Registered Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + IP fields: + + IPv6 Source: A non-link-local address of the sending + router. + + IPv6 Destination: In a DAR, a non-link-local address of a 6LBR. + In a DAC, this is just the source from the + DAR. + + Hop Limit: Set to MULTIHOP_HOPLIMIT on transmit. MUST + be ignored on receipt. + + ICMP Fields: + + Type: 157 for the DAR and 158 for the DAC. + + Code: Set to zero on transmit. MUST be ignored on + receipt. + + Checksum: The ICMP checksum. See [RFC4443]. + + Status: 8-bit unsigned integer. Indicates the status + of a registration in the DAC. MUST be set to + 0 in the DAR. See Table 1. + + Reserved: This field is unused. It MUST be initialized + to zero by the sender and MUST be ignored by + the receiver. + + + +Shelby, et al. Standards Track [Page 21] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Registration Lifetime: 16-bit unsigned integer. The amount of time + in units of 60 seconds that the 6LBR should + retain the DAD table entry (Section 8.2.2) + for the Registered Address. A value of 0 + indicates in a DAR that the DAD table entry + should be removed. + + EUI-64: 64 bits. This field is used to uniquely + identify the interface of the Registered + Address by including the EUI-64 identifier + [EUI64] assigned to it unmodified. + + Registered Address: 128-bit field. Carries the host address that + was contained in the IPv6 Source field in the + NS that contained the ARO sent by the host. + +5. Host Behavior + + Hosts in a LoWPAN use the ARO in the NS messages they send as a way + to maintain the Neighbor Cache in the routers, thereby removing the + need for multicast NSs to do address resolution. Unlike in + [RFC4861], the hosts initiate updating the information they receive + in RAs by sending RSs before the information expires. Finally, when + NUD indicates that one or all default routers have become + unreachable, then the host uses RSs to find a new set of default + routers. + +5.1. Forbidden Actions + + A host MUST NOT multicast an NS message. + +5.2. Interface Initialization + + When the interface on a host is initialized, it follows the + specification in [RFC4861]. A link-local address is formed based on + the EUI-64 identifier [EUI64] assigned to the interface as per + [RFC4944] or the appropriate IP-over-foo document for the link, and + then the host sends RS messages as described in [RFC4861] + Section 6.3.7. + + There is no need to join the solicited-node multicast address, since + nobody multicasts NSs in this type of network. A host MUST join the + all-nodes multicast address. + + + + + + + + +Shelby, et al. Standards Track [Page 22] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +5.3. Sending a Router Solicitation + + The RS is formatted as specified in [RFC4861] and sent to the IPv6 + all-routers multicast address (see [RFC4861] Section 6.3.7 for + details). An SLLAO MUST be included to enable unicast RAs in + response. An unspecified source address MUST NOT be used in RS + messages. + + If the link layer supports a way to send packets to some kind of + all-routers anycast link-layer address, then that MAY be used to + convey these packets to a router. + + Since hosts do not depend on multicast RAs to discover routers, the + hosts need to intelligently retransmit RSs whenever the default + router list is empty, one of its default routers becomes unreachable, + or the lifetime of the prefixes and contexts in the previous RA is + about to expire. The RECOMMENDED rate of retransmissions is to + initially send up to 3 (MAX_RTR_SOLICITATIONS) RS messages separated + by at least 10 seconds (RTR_SOLICITATION_INTERVAL) as specified in + [RFC4861], and then switch to slower retransmissions. After the + initial retransmissions, the host SHOULD do truncated binary + exponential backoff [ETHERNET] of the retransmission timer for each + subsequent retransmission, truncating the increase of the + retransmission timer at 60 seconds (MAX_RTR_SOLICITATION_INTERVAL). + In all cases, the RS retransmissions are terminated when an RA is + received. See Section 9 for protocol constants. + +5.4. Processing a Router Advertisement + + The processing of RAs is as in [RFC4861], with the addition of + handling the 6CO and triggering address registration when a new + address has been configured. Furthermore, the SLLAO MUST be included + in the RA. Unlike in [RFC4861], the maximum value of the RA Router + Lifetime field MAY be up to 0xFFFF (approximately 18 hours). + + Should the host erroneously receive a PIO with the L (on-link) flag + set, then that PIO MUST be ignored. + +5.4.1. Address Configuration + + Address configuration follows [RFC4862]. For an address not derived + from an EUI-64, the M flag of the RA determines how the address can + be configured. If the M flag is set in the RA, then DHCPv6 MUST be + used to assign the address. If the M flag is not set, then the + address can be configured by any other means (and duplicate detection + is performed as part of the registration process). + + + + + +Shelby, et al. Standards Track [Page 23] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Once an address has been configured, it will be registered by + unicasting an NS with an ARO to one or more routers. + +5.4.2. Storing Contexts + + The host maintains a conceptual data structure for the context + information it receives from the routers. This structure is called + the context table. It includes the CID, the prefix (from the Context + Prefix field in the 6CO), the Compression bit, and the Valid + Lifetime. A context table entry that has the Compression bit clear + is used for decompression when receiving packets but MUST NOT be used + for compression when sending packets. + + When a 6CO is received in an RA, it is used to add or update the + information in the context table. If the CID field in the 6CO + matches an existing context table entry, then that entry is updated + with the information in the 6CO. If the Valid Lifetime field in the + 6CO is zero, then the entry is immediately deleted. + + If there is no matching entry in the context table, and the Valid + Lifetime field is non-zero, then a new context is added to the + context table. The 6CO is used to update the created entry. + + When the 6LBR changes the context information, a host might not + immediately notice. And in the worst case, a host might have stale + context information. For this reason, 6LBRs use the recommendations + in Section 7.2 for carefully managing the context life cycle. Nodes + should be careful about using header compression in RA messages that + include 6COs. + +5.4.3. Maintaining Prefix and Context Information + + The prefix information is timed out as specified in [RFC4861]. When + the Valid Lifetime for a context table entry expires, the entry is + placed in a receive-only mode, which is the equivalent of receiving a + 6CO for that context with C=0. The entry is held in receive-only + mode for a period of twice the default Router Lifetime, after which + the entry is removed. + + A host should inspect the various lifetimes to determine when it + should next initiate sending an RS to ask for any updates to the + information. The lifetimes that matter are the default Router + Lifetime, the Valid Lifetime in the PIOs, and the Valid Lifetime in + the 6CO. The host SHOULD unicast one or more RSs to the router well + before the shortest of those lifetimes (across all the prefixes and + all the contexts) expires and then switch to multicast RS messages if + there is no response to the unicasts. The retransmission behavior + for the RSs is specified in Section 5.3. + + + +Shelby, et al. Standards Track [Page 24] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +5.5. Registration and Neighbor Unreachability Detection + + Hosts send unicast NS messages to register their IPv6 addresses, and + also to do NUD to verify that their default routers are still + reachable. The registration is performed by the host including an + ARO in the NS it sends. Even if the host doesn't have data to send, + but is expecting others to try to send packets to the host, the host + needs to maintain its NCEs in the routers. This is done by sending + NS messages with an ARO to the router well in advance of the + Registration Lifetime expiring. NS messages are retransmitted up to + MAX_UNICAST_SOLICIT times using a minimum timeout of RETRANS_TIMER + until the host receives an NA message with an ARO. + + Hosts that receive RA messages from multiple default routers SHOULD + attempt to register with more than one of them in order to increase + the robustness of the network. + + Note that NUD probes can be suppressed by reachability confirmations + from transport protocols or applications as specified in [RFC4861]. + + When a host knows it will no longer use a router it is registered to, + it SHOULD de-register with the router by sending an NS with an ARO + containing a lifetime of 0. To handle the case when a host loses + connectivity with the default router involuntarily, the host SHOULD + use a suitably low Registration Lifetime. + +5.5.1. Sending a Neighbor Solicitation + + The host triggers sending NS messages containing an ARO when a new + address is configured, when it discovers a new default router, or + well before the Registration Lifetime expires. Such an NS MUST + include an SLLAO, since the router needs to record the link-layer + address of the host. An unspecified source address MUST NOT be used + in NS messages. + +5.5.2. Processing a Neighbor Advertisement + + A host handles NA messages as specified in [RFC4861], with added + logic described in this section for handling the ARO. + + In addition to the normal validation of an NA and its options, the + ARO (if present) is verified as follows. If the Length field is not + two, the option is silently ignored. If the EUI-64 field does not + match the EUI-64 of the interface, the option is silently ignored. + + + + + + + +Shelby, et al. Standards Track [Page 25] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + If the Status field is zero, then the address registration was + successful. The host saves the Registration Lifetime from the ARO + for use to trigger a new NS well before the lifetime expires. If the + Status field is not equal to zero, the address registration has + failed. + +5.5.3. Recovering from Failures + + The procedure for maintaining reachability information about a + neighbor is the same as in [RFC4861] Section 7.3, with the exception + that address resolution is not performed. + + The address registration procedure may fail for two reasons: no + response to NSs is received (NUD failure), or an ARO with a failure + Status (Status > 0) is received. In the case of NUD failure, the + entry for that router will be removed; thus, address registration is + no longer of importance. When an ARO with a non-zero Status field is + received, this indicates that registration for that address has + failed. A failure Status of one indicates that a duplicate address + was detected, and the procedure described in [RFC4862] Section 5.4.5 + is followed. The host MUST NOT use the address it tried to register. + If the host has valid registrations with other routers, these MUST be + removed by registering with each using a zero ARO lifetime. + + A Status code of two indicates that the Neighbor Cache of that router + is full. In this case, the host SHOULD remove this router from its + default router list and attempt to register with another router. If + the host's default router list is empty, it needs to revert to + sending RSs as specified in Section 5.3. + + Other failure codes may be defined in future documents. + +5.6. Next-Hop Determination + + The IP address of the next hop for a destination is determined as + follows. Destinations to the link-local prefix (fe80::) are always + sent on the link to that destination. It is assumed that link-local + addresses are formed as specified in Section 5.2 from the EUI-64, and + address resolution is not performed. Packets are sent to link-local + destinations by reversing the procedure in Appendix A of [RFC4291]. + + Multicast addresses are considered to be on-link and are resolved as + specified in [RFC4944] or the appropriate IP-over-foo document. Note + that [RFC4944] only defines how to represent a multicast destination + address in the LoWPAN header. Support for multicast scopes larger + than link-local needs an appropriate multicast routing algorithm. + + + + + +Shelby, et al. Standards Track [Page 26] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + All other prefixes are assumed to be off-link [RFC5889]. Anycast + addresses are always considered to be off-link. They are therefore + sent to one of the routers in the default router list. + + A LoWPAN node is not required to maintain a minimum of one buffer per + neighbor as specified in [RFC4861], since packets are never queued + while waiting for address resolution. + +5.7. Address Resolution + + The address registration mechanism and the SLLAO in RA messages + provide sufficient a priori state in routers and hosts to resolve an + IPv6 address to its associated link-layer address. As all prefixes + except the link-local prefix and multicast addresses are always + assumed to be off-link, multicast-based address resolution between + neighbors is not needed. + + Link-layer addresses for neighbors are stored in NCEs [RFC4861]. In + order to achieve LoWPAN compression, most global addresses are formed + using a link-layer address. Thus, a host can reduce memory usage by + optimizing for this case and only storing link-layer address + information if it differs from the link-layer address corresponding + to the Interface ID of the IPv6 address (i.e., differs in more than + the on-link/global bit being inverted). + +5.8. Sleeping + + It is often advantageous for battery-powered hosts in LoWPANs to keep + a low duty cycle. The optimizations described in this document + enable hosts to sleep, as further described in this section. Routers + may want to cache traffic destined to a host that is sleeping, but + such functionality is out of the scope of this document. + +5.8.1. Picking an Appropriate Registration Lifetime + + As all ND messages are initiated by the hosts, this allows a host to + sleep or otherwise be unreachable between NS/NA message exchanges. + The ARO attached to NS messages indicates to a router to keep the NCE + for that address valid for the period in the Registration Lifetime + field. A host should choose a sleep time appropriate for its energy + characteristics and set a Registration Lifetime larger than the sleep + time to ensure that the registration is renewed successfully + (considering, for example, clock drift and additional time for + potential retransmissions of the re-registration). External + configuration of a host should also consider the stability of the + network (how quickly the topology changes) when choosing its sleep + + + + + +Shelby, et al. Standards Track [Page 27] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + time (and thus Registration Lifetime). A dynamic network requires a + shorter sleep time so that routers don't keep invalid NCEs for nodes + longer than necessary. + +5.8.2. Behavior on Wakeup + + When a host wakes up from a sleep period, it SHOULD refresh its + current address registrations that will time out before the next + wakeup. This is done by sending NS messages with an ARO as described + in Section 5.5.1. The host may also need to refresh its prefix and + context information by sending a new unicast RS (the maximum Router + Lifetime is about 18 hours, whereas the maximum Registration Lifetime + is about 45.5 days). If after wakeup the host (using NUD) determines + that some or all previous default routers have become unreachable, + then the host will send multicast RSs to discover new default + router(s) and restart the address registration process. + +6. Router Behavior for 6LRs and 6LBRs + + Both 6LRs and 6LBRs maintain the Neighbor Cache [RFC4861] based on + the AROs they receive in NA messages from hosts, ND packets from + other nodes, and, potentially, a routing protocol used in the 6LoWPAN + as outlined in Section 3.5. + + The routers SHOULD NOT garbage-collect Registered NCEs (see + Section 3.4), since they need to retain them until the Registration + Lifetime expires. Similarly, if NUD on the router determines that + the host is UNREACHABLE (based on the logic in [RFC4861]), the NCE + SHOULD NOT be deleted but rather retained until the Registration + Lifetime expires. A renewed ARO should mark the cache entry as + STALE. Thus, for 6LoWPAN routers, the Neighbor Cache doesn't behave + like a cache. Instead, it behaves as a registry of all the host + addresses that are attached to the router. + + Routers MAY implement the Default Router Preference (Prf) extension + [RFC4191] and use that to indicate to the host whether the router is + a 6LBR or a 6LR. If this is implemented, then 6LRs with no route to + a border router MUST set Prf to (11) for low preference, other 6LRs + MUST set Prf to (00) for normal preference, and 6LBRs MUST set Prf to + (01) for high preference. + +6.1. Forbidden Actions + + Even if a router in a route-over topology can reach both a host and + another target, because of radio propagation it generally cannot know + whether the host can directly reach the other target. Therefore, it + cannot assume that Redirect will actually work from one host to + another. Therefore, it SHOULD NOT send Redirect messages. The only + + + +Shelby, et al. Standards Track [Page 28] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + potential exception to this "SHOULD NOT" is when the deployment/ + implementation has a way to know how the host can reach the intended + target. Hence, it is RECOMMENDED that the implementation by default + does not send Redirect messages but can be configurable when the + deployment calls for this. In contrast, for mesh-under topologies, + the same considerations about Redirects apply as in [RFC4861]. + + A router MUST NOT set the L (on-link) flag in the PIOs, since that + might trigger hosts to send multicast NSs. + +6.2. Interface Initialization + + The 6LBR router interface initialization behavior is the same as in + [RFC4861]. However, in a dynamic configuration scenario (see + Section 8.1), a 6LR comes up as a non-router and waits to receive the + advertisement for configuring its own interface address first, before + setting its interfaces to be advertising interfaces and turning into + a router. + +6.3. Processing a Router Solicitation + + A router processes RS messages as specified in [RFC4861]. The + differences relate to the inclusion of ABROs in the RA messages and + the exclusive use of unicast RAs. If a 6LR has received an ABRO from + a 6LBR, then it will include that option unmodified in the RA + messages it sends. And, if the 6LR has received RAs -- whether with + the same prefixes and context information or different -- from a + different 6LBR, then it will need to keep those prefixes and that + context information separately so that the RAs the 6LR sends will + maintain the association between the ABRO and the prefixes and + context information. The router can tell which 6LBR originated the + prefixes and context information from the 6LBR Address field in the + ABRO. When a router has information tied to multiple ABROs, a single + RS will result in multiple RAs each containing a different ABRO. + + When the ABRO Valid Lifetime associated with a 6LBR times out, all + information related to that 6LBR MUST be removed. As an + implementation note, it is recommended that RAs are sent sufficiently + more frequently than the ABRO Valid Lifetime so that missing an RA + does not result in removing all information related to a 6LBR. + + An RS might be received from a host that has not yet registered its + address with the router. Thus, the router MUST NOT modify an + existing NCE based on the SLLAO from the RS. However, a router MAY + create a Tentative NCE based on the SLLAO. Such a Tentative NCE + SHOULD be timed out in TENTATIVE_NCE_LIFETIME seconds, unless a + registration converts it into a Registered NCE. + + + + +Shelby, et al. Standards Track [Page 29] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + A 6LR or 6LBR MUST include an SLLAO in the RAs it sends; this is + required so that the hosts will know the link-layer address of the + router. Unlike in [RFC4861], the maximum value of the RA Router + Lifetime field MAY be up to 0xFFFF (approximately 18 hours). + + Unlike [RFC4861], which suggests multicast RAs, this specification + improves the exchange by always unicasting RAs in response to RSs. + This is possible, since the RS always includes an SLLAO, which is + used by the router to unicast the RA. + +6.4. Periodic Router Advertisements + + A router does not need to send any periodic RA messages, since the + hosts will solicit updated information by sending RSs before the + lifetimes expire. + + However, if the routers use RAs to distribute prefix and/or context + information across a route-over topology, that might require periodic + RA messages. Such RAs are sent using the configurable + MinRtrAdvInterval and MaxRtrAdvInterval as per [RFC4861]. + +6.5. Processing a Neighbor Solicitation + + A router handles NS messages as specified in [RFC4861], with added + logic described in this section for handling the ARO. + + In addition to the normal validation of an NS and its options, the + ARO is verified as follows (if present). If the Length field is not + two, or if the Status field is not zero, then the NS is silently + ignored. + + If the source address of the NS is the unspecified address, or if no + SLLAO is included, then any included ARO is ignored, that is, the NS + is processed as if it did not contain an ARO. + +6.5.1. Checking for Duplicates + + If the NS contains a valid ARO, then the router inspects its Neighbor + Cache on the arriving interface to see if it is a duplicate. It + isn't a duplicate if (1) there is no NCE for the IPv6 source address + of the NS or (2) there is such an NCE and the EUI-64 is the same. + Otherwise, it is a duplicate address. Note that if multihop DAD + (Section 8.2) is used, then the checks are slightly different, to + take into account Tentative NCEs. In the case where it is a + duplicate address, then the router responds with a unicast NA message + with the ARO Status field set to one (to indicate that the address is + a duplicate) as described in Section 6.5.2. In this case, there is + no modification to the Neighbor Cache. + + + +Shelby, et al. Standards Track [Page 30] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +6.5.2. Returning Address Registration Errors + + Address registration errors are not sent back to the source address + of the NS due to a possible risk of L2 address collision. Instead, + the NA is sent to the link-local IPv6 address with the Interface ID + part derived from the EUI-64 field of the ARO as per [RFC4944]. In + particular, this means that the universal/local bit needs to be + inverted. The NA is formatted with a copy of the ARO from the NS, + but with the Status field set to indicate the appropriate error. + + The error is sent to the link-local address with the Interface ID + derived from the EUI-64. Thus, if the ARO was from and for a short + address, the L2 destination address for the NA with the ARO error + will be the 64-bit unique address. + +6.5.3. Updating the Neighbor Cache + + If the ARO did not result in a duplicate address being detected as + above, then if the Registration Lifetime is non-zero the router + creates (if it didn't exist) or updates (otherwise) an NCE for the + IPv6 source address of the NS. If the Neighbor Cache is full and a + new entry needs to be created, then the router responds with a + unicast NA with the ARO Status field set to two (to indicate that the + router's Neighbor Cache is full) as described in Section 6.5.2. + + The Registration Lifetime and the EUI-64 are recorded in the NCE. A + unicast NA is then sent in response to the NS. This NA SHOULD + include a copy of the ARO, with the Status field set to zero. A + TLLAO (Target Link-Layer Address Option) [RFC4861] is not required in + the NA, since the host already knows the router's link-layer address + from RAs. + + If the ARO contains a zero Registration Lifetime, then any existing + NCE for the IPv6 source address of the NS MUST be deleted and an NA + sent as above. + + Should the Registration Lifetime in an NCE expire, then the router + MUST delete the cache entry. + + The addition and removal of Registered NCEs would result in notifying + the routing protocol. + + Note: If the substitutable multihop DAD (Section 8.2) is used, then + the updating of the Neighbor Cache is slightly different due to + Tentative NCEs. + + + + + + +Shelby, et al. Standards Track [Page 31] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +6.5.4. Next-Hop Determination + + In order to deliver a packet destined for a 6LN registered with a + router, next-hop determination is slightly different for routers than + for hosts (see Section 5.6). The routing table is checked to + determine the next-hop IP address. A Registered NCE determines if + the next-hop IP address is on-link. It is the responsibility of the + routing protocol of the router to maintain on-link information about + its registered neighbors. Tentative NCEs MUST NOT be used to + determine on-link status of the registered nodes. + +6.5.5. Address Resolution between Routers + + There needs to be a mechanism somewhere for the routers to discover + each other's link-layer addresses. If the routing protocol used + between the routers provides this, then there is no need for the + routers to use the ARO between each other. Otherwise, the routers + SHOULD use the ARO. When routers use the ARO to register with each + other and multihop DAD (Section 8.2) is in use, then care must be + taken to ensure that there isn't a flood of ARO-carrying messages + sent to the 6LBR as each router hears an ARO from their neighboring + routers. The details for this scenario are out of scope of this + document. + + Routers MAY also use multicast NSs as in [RFC4861] to resolve each + others link-layer addresses. Thus, routers MAY multicast NSs for + other routers, for example, as a result of receiving some routing + protocol update. Routers MUST respond to multicast NSs. This + implies that routers MUST join the solicited-node multicast addresses + as specified in [RFC4861]. + +7. Border Router Behavior + + A 6LBR handles the sending of RAs and processing of NSs from hosts as + specified above in Section 6. A 6LBR SHOULD always include an ABRO + in the RAs it sends, listing itself as the 6LBR address. This + requires that the 6LBR maintain the version number in stable storage + and increase the version number when some information in its RAs + changes. The information whose change affects the version is in the + PIOs (the prefixes or their lifetimes) and in the 6CO (the prefixes, + CIDs, or lifetimes). + + In addition, a 6LBR is somehow configured with the prefix or prefixes + that are assigned to the LoWPAN and advertises those in RAs as in + [RFC4861]. In the case of route-over, those prefixes can be + disseminated to all the 6LRs using the technique discussed in + + + + + +Shelby, et al. Standards Track [Page 32] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Section 8.1. However, there might be mechanisms outside of the scope + of this document that can be used as a substitute for prefix + dissemination in the route-over topology (see Section 1.4). + + If the 6LoWPAN uses header compression [RFC6282] with context, then + the 6LBR needs to manage the CIDs and advertise those in RAs by + including 6COs in its RAs so that directly attached hosts are + informed about the CIDs. Below, we specify things to consider when + the 6LBR needs to add, remove, or change the context information. In + the case of route-over, the context information is disseminated to + all the 6LRs using the technique discussed in Section 8, unless a + different specification provides a substitute for this multihop + distribution. + +7.1. Prefix Determination + + The prefix or prefixes used in a LoWPAN can be manually configured or + can be acquired using DHCPv6 Prefix Delegation [RFC3633]. For a + LoWPAN that is isolated from the network either permanently or + occasionally, the 6LBR can assign a ULA prefix using [RFC4193]. The + ULA prefix should be stored in stable storage so that the same prefix + is used after a failure of the 6LBR. If the LoWPAN has multiple + 6LBRs, then they should be configured with the same set of prefixes. + The set of prefixes is included in the RA messages as specified in + [RFC4861]. + +7.2. Context Configuration and Management + + If the LoWPAN uses header compression [RFC6282] with context, then + the 6LBR must be configured with context information and related + CIDs. If the LoWPAN has multiple 6LBRs, then they MUST be configured + with the same context information and CIDs. As noted in [RFC6282], + maintaining consistency of context information is crucial for + ensuring that packets will be decompressed correctly. + + The context information carried in RA messages originates at 6LBRs + and must be disseminated to all the routers and hosts within the + LoWPAN. RAs include one 6CO for each context. + + For the dissemination of context information using the 6CO, a strict + life cycle SHOULD be used in order to ensure that the context + information stays synchronized throughout the LoWPAN. New context + information SHOULD be introduced into the LoWPAN with C=0, to ensure + that it is known by all nodes that may have to perform header + decompression based on this context information. Only when it is + reasonable to assume that this information was successfully + disseminated SHOULD an option with C=1 be sent, enabling the actual + use of the context information for compression. + + + +Shelby, et al. Standards Track [Page 33] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Conversely, to avoid the situation where nodes send packets that make + use of previous values of contexts -- which would result in ambiguity + when receiving a packet that uses a recently changed context -- old + values of a context SHOULD be taken out of use for a while before new + values are assigned to this specific context. That is, in + preparation for a change of context information, its dissemination + SHOULD continue for at least MIN_CONTEXT_CHANGE_DELAY with C=0. Only + when it is reasonable to assume that the fact that the context is now + invalid was successfully disseminated should the CID be taken out of + dissemination or reused with a different Context Prefix field. In + the latter case, dissemination of the new value again SHOULD start + with C=0, as above. + +8. Substitutable Feature Behavior + + Normally, in a 6LoWPAN multihop network, the RA messages are used to + disseminate prefixes and context information to all the 6LRs in a + route-over topology. If all routers are configured to use a + substitute mechanism for such information distribution, any remaining + use of the 6LoWPAN-ND mechanisms is governed by the substitute + specification. + + There is also the option for a 6LR to perform multihop DAD (for IPv6 + addresses not derived from an EUI-64) against a 6LBR in a route-over + topology by using the DAR and DAC messages. This is substitutable + because there might be other ways to either allocate a unique + address, such as DHCPv6 [RFC3315], or use other future mechanisms for + multihop DAD. Again, in this case, any remaining use of the + 6LoWPAN-ND mechanisms is governed by the substitute specification. + + To be clear: Implementations MUST support the features described in + Sections 8.1 and 8.2, unless the implementation supports some + alternative ("substitute") from some other specification. + +8.1. Multihop Prefix and Context Distribution + + The multihop distribution relies on RS messages and RA messages sent + between routers, and using the ABRO version number to control the + propagation of the information (prefixes and context information) + that is being sent in the RAs. + + This multihop distribution mechanism can handle arbitrary information + from an arbitrary number of 6LBRs. However, the semantics of the + context information requires that all the 6LNs use the same + information whether they send, forward, or receive compressed + packets. Thus, the manager of the 6LBRs needs to somehow ensure that + the context information is in synchrony across the 6LBRs. This can + be handled in different ways. One possible way to ensure it is to + + + +Shelby, et al. Standards Track [Page 34] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + treat the context and prefix information as originating from some + logical or virtual source, which in essence means that it looks like + the information is distributed from a single source. + + If a set of 6LBRs behave as a single one (using mechanisms out of + scope of this document) so that the prefixes and contexts and the + ABRO version number will be the same from all the 6LBRs, then those + 6LBRs can pick a single IP address to use in the ABRO. + +8.1.1. 6LBRs Sending Router Advertisements + + 6LBRs supporting multihop prefix and context distribution MUST + include an ABRO in each of their RAs. The ABRO Version Number field + is used to keep prefix and context information consistent throughout + the LoWPAN, along with the guidelines in Section 7.2. Each time any + information in the set of PIOs or 6COs changes, the ABRO version is + increased by one. + + This requires that the 6LBR maintain the PIO, 6CO, and ABRO Version + Number in stable storage, since an old version number will be + silently ignored by the 6LRs. + +8.1.2. Routers Sending Router Solicitations + + In a 6LoWPAN, unless substituted, multihop distribution is done using + RA messages. Thus, on interface initialization, a router (6LR) MUST + send RS messages following the rules specified for hosts in + [RFC4861]. This in turn will cause the routers to respond with RA + messages that can then be used to initially seed the prefix and + context information. + +8.1.3. Routers Processing Router Advertisements + + If multihop distribution is not done using RA messages, then the + routers follow [RFC4861], which states that they merely do some + consistency checks; in this case, nothing in Section 8.1 applies. + Otherwise, the routers will check and record the prefix and context + information from the received RAs, and use that information as + follows. + + If a received RA does not contain an ABRO, then the RA MUST be + silently ignored. + + The router uses the 6LBR Address field in the ABRO to check if it has + previously received information from the 6LBR. If it finds no such + information, then it just records the 6LBR address, Version, Valid + Lifetime, and the associated prefixes and context information. If + the 6LBR is previously known, then the Version Number field MUST be + + + +Shelby, et al. Standards Track [Page 35] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + compared against the recorded version number for that 6LBR. If the + version number received in the packet is less than the stored version + number, then the information in the RA is silently ignored. + Otherwise, the recorded information and version number are updated. + +8.1.4. Storing the Information + + The router keeps state for each 6LBR that it sees with an ABRO. This + includes the version number, the Valid Lifetime, and the complete set + of PIOs and 6COs. The prefixes are timed out based on the Valid + Lifetime in the PIO. The Context Prefix is timed out based on the + Valid Lifetime in the 6CO. + + While the prefixes and context information are stored in the router, + their valid and preferred lifetimes are decremented as time passes. + This ensures that when the router is in turn later advertising that + information in the RAs it sends, the 'expiry time' doesn't + accidentally move further into the future. For example, if a 6CO + with a Valid Lifetime of 10 minutes is received at time T, and the + router includes this in an RA it sends at time T+5 minutes, the Valid + Lifetime in the 6CO it sends will be only 5 minutes. + +8.1.5. Sending Router Advertisements + + When multihop distribution is performed using RA messages, the + routers MUST ensure that the ABRO always stays together with the + prefixes and context information received with that ABRO. Thus, if + the router has received prefix P1 with an ABRO saying it is from one + 6LBR, and prefix P2 from another 6LBR, then the router MUST NOT + include the two prefixes in the same RA message. Prefix P1 MUST be + in an RA that includes an ABRO from the first 6LBR, etc. Note that + multiple 6LBRs might advertise the same prefix and context + information, but they still need to be associated with the 6LBRs that + advertised them. + + The routers periodically send RAs as in [RFC4861]. This is for the + benefit of the other routers receiving the prefixes and context + information. The routers also respond to RSs by unicasting RA + messages. In both cases, the above constraint of keeping the ABRO + together with 'its' prefixes and context information applies. + + When a router receives new information from a 6LBR, that is, either + it hears from a new 6LBR (a new 6LBR address in the ABRO) or the ABRO + version number of an existing 6LBR has increased, then it is useful + to send out a few triggered updates. The recommendation is to behave + the same as when an interface has become an advertising interface as + described in [RFC4861], that is, send up to three RA messages. This + ensures rapid propagation of new information to all the 6LRs. + + + +Shelby, et al. Standards Track [Page 36] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +8.2. Multihop Duplicate Address Detection + + The ARO can be used, in addition to registering an address in a 6LR, + to have the 6LR verify that the address isn't used by some other host + known to the 6LR. However, that isn't sufficient in a route-over + topology (or in a LoWPAN with multiple 6LBRs), since some host + attached to another 6LR could be using the same address. There might + be different ways for the 6LRs to coordinate such duplicate address + detection in the future, or addresses could be assigned using a + DHCPv6 server that verifies uniqueness as part of the assignment. + + This specification offers a substitutable simple technique for 6LRs + and 6LBRs to perform DAD that reuses the information from the ARO in + the DAR and DAC messages. This technique is not needed when the + Interface ID in the address is based on an EUI-64, since those are + assumed to be globally unique. The technique assumes that either the + 6LRs register with all the 6LBRs or the network uses some out-of- + scope mechanism to keep the DAD tables in the 6LBRs synchronized. + + The multihop DAD mechanism is used synchronously the first time an + address is registered with a particular 6LR. That is, the ARO is not + returned to the host until multihop DAD has been completed against + the 6LBRs. For existing registrations in the 6LR, multihop DAD needs + to be repeated against the 6LBRs to ensure that the entry for the + address in the 6LBRs does not time out, but that can be done + asynchronously with the response to the hosts. One method to achieve + this is to track how much is left of the lifetime the 6LR registered + with the 6LBRs and to re-register with the 6LBR when this lifetime is + about to run out. + + For synchronous multihop DAD, the 6LR performs some additional checks + to ensure that it has an NCE it can use to respond to the host when + it receives a response from a 6LBR. This consists of checking for an + already existing (Tentative or Registered) NCE for the Registered + Address with a different EUI-64. If such a Registered NCE exists, + then the 6LR SHOULD respond that the address is a duplicate. If such + a Tentative NCE exists, then the 6LR SHOULD silently ignore the ARO, + thereby relying on the host retransmitting the ARO. This is needed + to handle the case when multiple hosts try to register the same IPv6 + address at the same time. If no NCE exists, then the 6LR MUST create + a Tentative NCE with the EUI-64 and the SLLAO. This entry will be + used to send the response to the host when the 6LBR responds + positively. + + When a 6LR receives an NS containing an ARO with a non-zero + Registration Lifetime and it has no existing Registered NCE, then + with this mechanism the 6LR will invoke synchronous multihop DAD. + + + + +Shelby, et al. Standards Track [Page 37] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + The 6LR will unicast a DAR message to one or more 6LBRs, where the + DAR contains the host's address in the Registered Address field. The + DAR will be forwarded by 6LRs until it reaches the 6LBR; hence, its + IPv6 Hop Limit field will not be 255 when received by the 6LBR. The + 6LBR will respond with a DAC message, which will have a hop limit + less than 255 when it reaches the 6LR. + + When the 6LR receives the DAC from the 6LBR, it will look for a + matching (same IP address and EUI-64) (Tentative or Registered) NCE. + If no such entry is found, then the DAC is silently ignored. If an + entry is found and the DAC had Status=0, then the 6LR will mark the + Tentative NCE as Registered. In all cases, when an entry is found, + then the 6LR will respond to the host with an NA, copying the Status + and EUI-64 fields from the DAC to an ARO in the NA. In case the + status is an error, then the destination IP address of the NA is + derived from the EUI-64 field of the DAC. + + A Tentative NCE SHOULD be timed out TENTATIVE_NCE_LIFETIME seconds + after it was created in order to allow for another host to attempt to + register the IPv6 address. + +8.2.1. Message Validation for DAR and DAC + + A node MUST silently discard any received DAR and DAC messages for + which at least one of the following validity checks is not satisfied: + + o If the message includes an IP Authentication Header, the message + authenticates correctly. + + o ICMP Checksum is valid. + + o ICMP Code is 0. + + o ICMP Length (derived from the IP length) is 32 or more bytes. + + o The Registered Address is not a multicast address. + + o All included options have a length that is greater than zero. + + o The IP source address is not the unspecified address, nor is it a + multicast address. + + The contents of the Reserved field and of any unrecognized options + MUST be ignored. Future backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + + + + +Shelby, et al. Standards Track [Page 38] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Note that due to the forwarding of the DAR and DAC messages between + the 6LR and 6LBR, there is no hop-limit check on receipt for these + ICMPv6 message types. + +8.2.2. Conceptual Data Structures + + A 6LBR implementing multihop DAD needs to maintain some state + separate from the Neighbor Cache. We call this conceptual data + structure the DAD table. It is indexed by the IPv6 address -- the + Registered Address in the DAR -- and contains the EUI-64 and the + Registration Lifetime of the host that is using that address. + +8.2.3. 6LR Sending a Duplicate Address Request + + When a 6LR that implements multihop DAD receives an NS from a host, + and subject to the above checks, the 6LR forms and sends a DAR to at + least one 6LBR. The DAR contains the following information: + + o In the IPv6 source address, a global address of the 6LR. + + o In the IPv6 destination address, the address of the 6LBR. + + o In the IPv6 hop limit, MULTIHOP_HOPLIMIT. + + o The Status field MUST be set to zero. + + o The EUI-64 and Registration Lifetime are copied from the ARO + received from the host. + + o The Registered Address set to the IPv6 address of the host, that + is, the sender of the triggering NS. + + When a 6LR receives an NS from a host with a zero Registration + Lifetime, then, in addition to removing the NCE for the host as + specified in Section 6, a DAR is sent to the 6LBRs as above. + + A router MUST NOT modify the Neighbor Cache as a result of receiving + a DAR. + +8.2.4. 6LBR Receiving a Duplicate Address Request + + When a 6LBR that implements the substitutable multihop DAD receives a + DAR from a 6LR, it performs the message validation specified in + Section 8.2.1. If the DAR is valid, the 6LBR proceeds to look for + the Registration Address in the DAD table. If an entry is found and + the recorded EUI-64 is different than the EUI-64 in the DAR, then it + + + + + +Shelby, et al. Standards Track [Page 39] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + returns a DAC NA with the Status set to 1 ('Duplicate Address'). + Otherwise, it returns a DAC with Status set to zero and updates the + lifetime. + + If no entry is found in the DAD table and the Registration Lifetime + is non-zero, then an entry is created and the EUI-64 and Registered + Address from the DAR are stored in that entry. + + If an entry is found in the DAD table, the EUI-64 matches, and the + Registration Lifetime is zero, then the entry is deleted from the + table. + + In both of the above cases, the 6LBR forms a DAC with the information + copied from the DAR and the Status field is set to zero. The DAC is + sent back to the 6LR, i.e., back to the source of the DAR. The IPv6 + hop limit is set to MULTIHOP_HOPLIMIT. + +8.2.5. Processing a Duplicate Address Confirmation + + When a 6LR implementing multihop DAD receives a DAC message, then it + first validates the message per Section 8.2.1. For a valid DAC, if + there is no Tentative NCE matching the Registered Address and EUI-64, + then the DAC is silently ignored. Otherwise, the information in the + DAC and in the Tentative NCE is used to form an NA to send to the + host. The Status code is copied from the DAC to the ARO that is sent + to the host. In the case where the DAC indicates an error (the + Status is non-zero), the NA is returned to the host as described in + Section 6.5.2, and the Tentative NCE for the Registered Address is + removed. Otherwise, it is made into a Registered NCE. + + A router MUST NOT modify the Neighbor Cache as a result of receiving + a DAC, unless there is a Tentative NCE matching the IPv6 address and + EUI-64. + +8.2.6. Recovering from Failures + + If there is no response from a 6LBR after RETRANS_TIMER [RFC4861], + then the 6LR would retransmit the DAR to the 6LBR up to + MAX_UNICAST_SOLICIT [RFC4861] times. After this, the 6LR SHOULD + respond to the host with an ARO Status of zero. + + + + + + + + + + + +Shelby, et al. Standards Track [Page 40] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +9. Protocol Constants + + This section defines the relevant protocol constants used in this + document based on a subset of [RFC4861] constants. "*" indicates + constants modified from [RFC4861], and "+" indicates new constants. + + Additional protocol constants are defined in Section 4. + + 6LBR Constants: + + MIN_CONTEXT_CHANGE_DELAY+ 300 seconds + + 6LR Constants: + + MAX_RTR_ADVERTISEMENTS 3 transmissions + + MIN_DELAY_BETWEEN_RAS* 10 seconds + + MAX_RA_DELAY_TIME* 2 seconds + + TENTATIVE_NCE_LIFETIME+ 20 seconds + + Router Constants: + + MULTIHOP_HOPLIMIT+ 64 + + Host Constants: + + RTR_SOLICITATION_INTERVAL* 10 seconds + + MAX_RTR_SOLICITATIONS 3 transmissions + + MAX_RTR_SOLICITATION_INTERVAL+ 60 seconds + + + + + + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 41] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +10. Examples + +10.1. Message Examples + + STEP + + 6LN 6LR + + | | + + 1. | ---------- Router Solicitation --------> | + + | [SLLAO] | + + | | + + 2. | <-------- Router Advertisement --------- | + + | [PIO + 6CO + ABRO + SLLAO] | + + + Figure 2: Basic Router Solicitation/Router Advertisement Exchange + between a Node and a 6LR or 6LBR + + + 6LN 6LR + + | | + + 1. | ------- NS with Address Registration ------> | + + | [ARO + SLLAO] | + + | | + + 2. | <----- NA with Address Registration -------- | + + | [ARO with Status] | + + + Figure 3: Neighbor Discovery Address Registration + + + + + + + + + + +Shelby, et al. Standards Track [Page 42] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 6LN 6LR 6LBR + + | | | + + 1. | --- NS with Address Reg --> | | + + | [ARO + SLLAO] | | + + | | | + + 2. | | ----------- DAR ----------> | + + | | | + + 3. | | <---------- DAC ----------- | + + | | | + + 4. | <-- NA with Address Reg --- | | + + | [ARO with Status] | + + + Figure 4: Neighbor Discovery Address Registration with Multihop DAD + +10.2. Host Bootstrapping Example + + The following example describes the address bootstrapping scenarios + using the improved ND mechanisms specified in this document. It is + assumed that the 6LN first performs a sequence of operations in order + to get secure access at the link layer of the LoWPAN and obtain a key + for link-layer security. The methods of how to establish link-layer + security are out of scope of this document. In this example, an IEEE + 802.15.4 6LN forms a 16-bit short IPv6 address without using DHCPv6 + (i.e., the M flag is not set in the RAs). + + 1. After obtaining link-layer security, a 6LN assigns a link-local + IPv6 address to itself. A link-local IPv6 address is configured + based on the 6LN's EUI-64 link-layer address formed as per + [RFC4944]. + + 2. Next, the 6LN determines one or more default routers in the + network by sending an RS to the all-routers multicast address + with the SLLAO set to its EUI-64 link-local address. If the 6LN + was able to obtain the link-layer address of a router through its + link-layer operations, then the 6LN may form a link-local + destination IPv6 address for the router and send it a unicast RS. + + + + +Shelby, et al. Standards Track [Page 43] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + The 6LR responds with a unicast RA to the IP source address using + the SLLAO from the RS (it may have created a Tentative NCE). See + Figure 2. + + 3. In order to communicate more than one IP hop away, the 6LN + configures a global IPv6 address. In order to save overhead, + this 6LN wishes to configure its IPv6 address based on a 16-bit + short address as per [RFC4944]. As the network is unmanaged + (M flag not set in the RA), the 6LN randomly chooses a 16-bit + link-layer address and forms a Tentative IPv6 address from it. + + 4. Next, the 6LN registers that address with one or more of its + default routers by sending a unicast NS message with an ARO + containing its Tentative global IPv6 address to register, the + Registration Lifetime, and its EUI-64. An SLLAO is also included + with the link-layer address corresponding to the address being + registered. If a successful (Status 0) NA message is received, + the address can then be used, and the 6LN assumes that it has + been successfully checked for duplicates. If a duplicate address + (Status 1) NA message is received, the 6LN then removes the + temporary IPv6 address and 16-bit link-layer address and goes + back to step 3. If a Neighbor Cache Full (Status 2) message is + received, the 6LN attempts to register with another default + router or, if none, goes back to step 2. See Figure 3. Note + that an NA message returning an error would be sent back to the + link-local EUI-64-based IPv6 address of the 6LN instead of the + 16-bit (duplicate) address. + + 5. The 6LN now performs maintenance by sending a new NS address + registration before the lifetime expires. + + If multihop DAD and multihop prefix and context distribution are + used, the effect of the 6LRs and hosts following the above + bootstrapping process is a "wavefront" of 6LRs and hosts being + configured, spreading outward from the 6LBRs: First, the hosts and + 6LRs that can directly reach a 6LBR would receive one or more RAs and + then configure and register their IPv6 addresses. Once that is done, + they would enable the routing protocol and start sending out RAs. + That would result in a new set of 6LRs and hosts to receive responses + to their RSs, form and register their addresses, etc. That repeats + until all of the 6LRs and hosts have been configured. + + + + + + + + + + +Shelby, et al. Standards Track [Page 44] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +10.2.1. Host Bootstrapping Messages + + This section provides specific message examples related to the + bootstrapping process described above. When discussing messages, the + following notation is used: + + LL64: Link-local address based on the EUI-64, which is also the + 802.15.4 long address. + + GP16: Global address based on the 802.15.4 short address. This + address may not be unique. + + GP64: Global addresses derived from the EUI-64 address as specified + in [RFC4944]. + + MAC64: EUI-64 address used as the link-layer address. + + MAC16: IEEE 802.15.4 16-bit short address. + + Note that some implementations may use LL64 and GP16 style addresses + instead of LL64 and GP64. In the following, we will show an example + message flow as to how a node uses LL64 to register a GP16 address + for multihop DAD verification. + + 6LN-----RS-------->6LR + Src= LL64 (6LN) + Dst= all-router-link-scope-multicast + SLLAO= MAC64 (6LN) + + 6LR------RA--------->6LN + Src= LL64 (6LR) + Dst= LL64 (6LN) + + Note: Source address of RA must be a link-local + address (Section 4.2 of RFC 4861). + + 6LN-------NS Reg------>6LR + Src= GP16 (6LN) + Dst= LL64 (6LR) + ARO + SLLAO= MAC16 (6LN) + + 6LR---------DAR----->6LBR + Src= GP64 or GP16 (6LR) + Dst= GP64 or GP16 (6LBR) + Registered Address= GP16 (6LN) and EUI-64 (6LN) + + + + + +Shelby, et al. Standards Track [Page 45] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + 6LBR-------DAC--------->6LR + Src= GP64 or GP16 (6LBR) + Dst= GP64 or GP16 (6LR) + Copy of information from DAR + + If Status is a success: + + 6LR ---------NA-Reg------->6LN + Src= LL64 (6LR) + Dst= GP16 (6LN) + ARO with Status = 0 + + If Status is not a success: + + 6LR ---------NA-Reg-------->6LN + Src= LL64 (6LR) + Dst= LL64 (6LN) --> Derived from the EUI-64 of ARO + ARO with Status > 0 + + + Figure 5: Detailed Message Address Examples + +10.3. Router Interaction Example + + In the route-over topology, when a routing protocol is run across + 6LRs, the bootstrapping and Neighbor Cache management are handled a + little differently. The description in this paragraph provides only + a guideline for an implementation. + + At the initialization of a 6LR, it may choose to bootstrap as a host + with the help of a parent 6LR if the substitutable multihop DAD is + performed with the 6LBR. The Neighbor Cache management of a router + and address resolution among the neighboring routers are described in + Sections 6.5.3 and 6.5.5, respectively. In this example, we assume + that the neighboring 6LoWPAN link is secure. + +10.3.1. Bootstrapping a Router + + In this scenario, the bootstrapping 6LR, 'R1', is multiple hops away + from the 6LBR and surrounded by other 6LR neighbors. Initially, R1 + behaves as a host. It sends a multicast RS and receives an RA from + one or more neighboring 6LRs. R1 picks one 6LR as its temporary + default router and performs address resolution via this default + router. Note that if multihop DAD is not required (e.g., in a + managed network or using EUI-64-based addresses), then it does not + need to pick a temporary default router; however, it may still want + to send the initial RS message if it wants to autoconfigure its + address with the global prefix disseminated by the 6LBR. + + + +Shelby, et al. Standards Track [Page 46] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + Based on the information received in the RAs, R1 updates its cache + with entries for all the neighboring 6LRs. Upon completion of the + address registration, the bootstrapping router deletes the temporary + entry of the default router, and the routing protocol is started. + + Also note that R1 may refresh its multihop DAD registration directly + with the 6LBR (using the next-hop neighboring 6LR determined by the + routing protocol for reaching the 6LBR). + +10.3.2. Updating the Neighbor Cache + + In this example, there are three 6LRs: R1, R2, and R3. Initially, + when R2 boots, it sees only R1, and accordingly R2 creates an NCE for + R1. Now assume that R2 receives a valid routing update from router + R3. R2 does not have any NCE for R3. If the implementation of R2 + supports detecting link-layer addresses from the routing information + packets, then it directly updates its Neighbor Cache using that + link-layer information. If this is not possible, then R2 should + perform multicast NS with the source set with its link-local or + global address, depending on the scope of the source IP address + received in the routing update packet. The target address of the NS + message is the source IPv6 address of the received routing update + packet. The format of the NS message is as described in Section 4.3 + of [RFC4861]. + + More generally, any 6LR that receives a valid route update from a + neighboring router for which it does not have any NCE is required to + update its Neighbor Cache as described above. + + The router (6LR and 6LBR) IP addresses learned via ND are not + redistributed to the routing protocol. + +11. Security Considerations + + The security considerations of IPv6 ND [RFC4861] and address + autoconfiguration [RFC4862] apply. Additional considerations can be + found in [RFC3756]. + + There is a slight modification to those considerations, due to the + fact that in this specification the M flag in the RAs disables the + use of stateless address autoconfiguration for addresses not derived + from EUI-64. Thus, a rogue router on the link can force the use of + only DHCP for short addresses, whereas in [RFC4861] and [RFC4862] the + rogue router could only cause the addition of DHCP and not disable + stateless address autoconfiguration for short addresses. + + + + + + +Shelby, et al. Standards Track [Page 47] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + This specification assumes that the link layer is sufficiently + protected -- for instance, by using MAC-sublayer cryptography. Thus, + its threat model is no different from that of IPv6 ND [RFC4861]. The + first trust model listed in Section 3 of [RFC3756] applies here. + However, any future 6LoWPAN security protocol that applies to ND for + the 6LoWPAN protocol is out of scope of this document. + + The multihop DAD mechanisms rely on DAR and DAC messages that are + forwarded by 6LRs, and as a result the hop_limit=255 check on the + receiver does not apply to those messages. This implies that any + node on the Internet could successfully send such messages. We avoid + any additional security issues due to this by requiring that the + routers never modify the NCE due to such messages, and that they + discard them unless they are received on an interface that has been + explicitly configured to use these optimizations. + + In some future deployments, one might want to use SEcure Neighbor + Discovery (SEND) [RFC3971] [RFC3972]. This is possible with the ARO + as sent between hosts and routers, since the address that is being + registered is the IPv6 source address of the NS and SEND verifies the + IPv6 source address of the packet. Applying SEND to the router-to- + router communication in this document is out of scope. + +12. IANA Considerations + + This document registers three new ND option types under the + subregistry "IPv6 Neighbor Discovery Option Formats": + + o Address Registration Option (33) + o 6LoWPAN Context Option (34) + o Authoritative Border Router Option (35) + + The document registers two new ICMPv6 "type" numbers under the + subregistry "ICMPv6 "type" Numbers": + + o Duplicate Address Request (157) + o Duplicate Address Confirmation (158) + + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 48] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + IANA has also created a new subregistry for the Status values of the + Address Registration Option, under the ICMPv6 parameters registry. + + Address Registration Option Status Values registry: + + o Possible values are 8-bit unsigned integers (0..255). + o Registration procedure is "Standards Action" [RFC5226]. + o Initial allocation is as indicated in Table 2: + + +--------+--------------------------------------------+ + | Status | Description | + +--------+--------------------------------------------+ + | 0 | Success | + | 1 | Duplicate Address | + | 2 | Neighbor Cache Full | + | 3-255 | Allocated using Standards Action [RFC5226] | + +--------+--------------------------------------------+ + + Table 2 + +13. Interaction with Other Neighbor Discovery Extensions + + There are two classes of ND extensions that interact with this + specification in different ways. + + One class encompasses extensions to the DAD mechanisms in [RFC4861] + and [RFC4862]. An example of this is Optimistic DAD [RFC4429]. Such + extensions do not apply when this specification is being used, since + it uses ARO for DAD (which is neither optimistic nor pessimistic -- + always one round trip to the router to check DAD). + + All other (non-DAD) ND extensions, be they path selection types like + default router preferences [RFC4191], configuration types like DNS + configuration [RFC6106], or other types like Detecting Network + Attachment [RFC6059], are completely orthogonal to this specification + and will work as is. + +14. Guidelines for New Features + + This section discusses guidelines of new protocol features defined in + this document. It also sets some expectations for implementation and + deployment of these features. This section is informative in nature: + it does not override the detailed specifications of the previous + sections but summarizes them and presents them in a compact form, to + be used as checklists. The checklists act as guidelines to indicate + the possible importance of a feature in terms of a deployment as per + information available as of the writing of the document. Note that + in some cases the deployment is 'SHOULD' where the implementation is + + + +Shelby, et al. Standards Track [Page 49] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + a 'MUST'. This is due to the presence of substitutable features; the + deployment may use alternative methods for those. Therefore, + implementing a configuration knob is recommended for the + substitutable features. The lists emphasize conciseness over + completeness. + + +----------+-----------------------------------+--------+-----------+ + | Section | Description | Deploy | Implement | + +----------+-----------------------------------+--------+-----------+ + | 3.1 | Host-initiated RA | MUST | MUST | + | 3.2 | EUI-64-based IPv6 address | MUST | MUST | + | | 16-bit MAC-based address | MAY | SHOULD | + | | Other non-unique addresses | MAY | MAY | + | 3.3 | Host-initiated RS | MUST | MUST | + | | ABRO processing | SHOULD | MUST | + | 4.1 | Registration with ARO | MUST | MUST | + | 4.2, 5.4 | 6CO | SHOULD | SHOULD | + | 5.2 | Joining solicited-node multicast | N/A | N/A | + | | Joining all-nodes multicast | MUST | MUST | + | | Using link-layer indication for | MAY | MAY | + | | NUD | | | + | 5.5 | 6LoWPAN-ND NUD | MUST | MUST | + | 5.8.2 | Behavior on wakeup | SHOULD | SHOULD | + +----------+-----------------------------------+--------+-----------+ + + Table 3: Guideline for 6LoWPAN-ND Features for Hosts + + + + + + + + + + + + + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 50] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + +---------------+-------------------------+------------+------------+ + | Section | Description | Deploy | Implement | + +---------------+-------------------------+------------+------------+ + | 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT | + | 3.2 | Address assignment | SHOULD | MUST | + | | during startup | | | + | 3.3 | Supporting EUI-64-based | MUST | MUST | + | | MAC hosts | | | + | | Supporting 16-bit MAC | MAY | SHOULD | + | | hosts | | | + | 3.4, 4.3, | ABRO processing/sending | SHOULD | MUST | + | 8.1.3, 8.1.4 | | | | + | 8.1 | Multihop prefix storing | SHOULD | MUST | + | | and redistribution | | | + | 3.5 | Tentative NCE | MUST | MUST | + | 8.2 | Multihop DAD | SHOULD | MUST | + | 4.1, 6.5, | ARO support | MUST | MUST | + | 6.5.1 - 6.5.5 | | | | + | 4.2 | 6CO | SHOULD | SHOULD | + | 6.3 | Process RS/ABRO | MUST | MUST | + +---------------+-------------------------+------------+------------+ + + Table 4: Guideline for 6LR Features in 6LoWPAN-ND + + +--------------+--------------------------+------------+------------+ + | Section | Description | Deploy | Implement | + +--------------+--------------------------+------------+------------+ + | 3.1 | Periodic RA | SHOULD NOT | SHOULD NOT | + | 3.2 | Address autoconf on | MUST NOT | MUST NOT | + | | router interface | | | + | 3.3 | EUI-64 MAC support on | MUST | MUST | + | | 6LoWPAN interface | | | + | 8.1 - 8.1.1, | Multihop prefix | SHOULD | MUST | + | 8.1.5 | distribution | | | + | 8.2 | Multihop DAD | SHOULD | MUST | + +--------------+--------------------------+------------+------------+ + + Table 5: Guideline for 6LBR Features in 6LoWPAN-ND + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 51] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +15. Acknowledgments + + The authors thank Pascal Thubert, Jonathan Hui, Richard Kelsey, Geoff + Mulligan, Julien Abeille, Alexandru Petrescu, Peter Siklosi, Pieter + De Mil, Fred Baker, Anthony Schoofs, Phil Roberts, Daniel Gavelle, + Joseph Reddy, Robert Cragie, Mathilde Durvy, Colin O'Flynn, Dario + Tedeschi, Esko Dijk, and Joakim Eriksson for useful discussions and + comments that have helped shape and improve this document. + + Additionally, the authors would like to recognize Pascal Thubert for + contributing the original registration idea and for extensive + contributions to earlier versions of the document, Jonathan Hui for + original ideas on prefix/context distribution and extensive + contributions to earlier versions of the document, Colin O'Flynn for + useful "Error-to" suggestions (Section 6.5.2) and for contributions + to the Examples section, Geoff Mulligan for suggesting the use of + address registration as part of existing IPv6 ND messages, and + Mathilde Durvy for helping to clarify router interaction. + +16. References + +16.1. Normative References + + [ETHERNET] + "IEEE Standard for Information technology - + Telecommunications and information exchange between + systems - Local and metropolitan area networks - Specific + requirements - Part 3: Carrier Sense Multiple Access with + Collision Detection (CSMA/CD) Access Method and Physical + Layer Specifications", IEEE Std 802.3-2008, December 2008, + <http://standards.ieee.org/getieee802/download/ + 802.3-2008_section1.pdf>. + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [RFC2491] Armitage, G., Schulter, P., Jork, M., and G. Harter, "IPv6 + over Non-Broadcast Multiple Access (NBMA) networks", + RFC 2491, January 1999. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, November 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + + +Shelby, et al. Standards Track [Page 52] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control + Message Protocol (ICMPv6) for the Internet Protocol + Version 6 (IPv6) Specification", RFC 4443, March 2006. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + + [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J., and D. Culler, + "Transmission of IPv6 Packets over IEEE 802.15.4 + Networks", RFC 4944, September 2007. + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + May 2008. + + [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 + Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, + September 2011. + +16.2. Informative References + + [EUI64] IEEE, "Guidelines for 64-bit Global Identifier + (EUI-64(TM)) Registration Authority", <http:// + standards.ieee.org/regauth/oui/tutorials/EUI64.html>. + + [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., + and M. Carney, "Dynamic Host Configuration Protocol for + IPv6 (DHCPv6)", RFC 3315, July 2003. + + [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic + Host Configuration Protocol (DHCP) version 6", RFC 3633, + December 2003. + + [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor + Discovery (ND) Trust Models and Threats", RFC 3756, + May 2004. + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + + + + +Shelby, et al. Standards Track [Page 53] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) + for IPv6", RFC 4429, 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, August 2007. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, September 2007. + + [RFC5889] Baccelli, E. and M. Townsley, "IP Addressing Model in Ad + Hoc Networks", RFC 5889, September 2010. + + [RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for + Detecting Network Attachment in IPv6", RFC 6059, + November 2010. + + [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, + "IPv6 Router Advertisement Options for DNS Configuration", + RFC 6106, November 2010. + + + + + + + + + + + + + + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 54] + +RFC 6775 ND Optimization for 6LoWPANs November 2012 + + +Authors' Addresses + + Zach Shelby (editor) + Sensinode + Konekuja 2 + Oulu 90620 + Finland + + Phone: +358407796297 + EMail: zach@sensinode.com + + + Samita Chakrabarti + Ericsson + + EMail: samita.chakrabarti@ericsson.com + + + Erik Nordmark + Cisco Systems + + EMail: nordmark@cisco.com + + + Carsten Bormann + Universitaet Bremen TZI + Postfach 330440 + Bremen D-28359 + Germany + + Phone: +49-421-218-63921 + EMail: cabo@tzi.org + + + + + + + + + + + + + + + + + + + +Shelby, et al. Standards Track [Page 55] + |