6MAN P. Thubert Internet-Draft E. Levy-Abegnoli Intended status: Standards Track Cisco Expires: April 18, 2014 October 17, 2013 Wireless Neighbor Discovery Stateful Address Identification and Location exchange draft-thubert-6man-wind-sail-00 Abstract This draft proposes an extension to IPv6 Neighbor Discovery to exchange Stateful Address Identification and Location between State Maintaining Entities located over a backbone link about attached nodes that are attached to the backbone via a Wireless Link, in order to maintain all the entities up-to-date and maintain reachability as the attached nodes move. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on April 18, 2014. Copyright Notice Copyright (c) 2013 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2 Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 1] Internet-Draft WiND-SAIL October 2013 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. General Context . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Efficient ND . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Proxying classical ND . . . . . . . . . . . . . . . . . . 10 4.3. Federating Large LLNs . . . . . . . . . . . . . . . . . . 11 5. New types and formats . . . . . . . . . . . . . . . . . . . . 12 6. Validation Interface Operations . . . . . . . . . . . . . . . 14 6.1. Child to Parent Operations . . . . . . . . . . . . . . . . 15 6.2. Parent to Child Operations . . . . . . . . . . . . . . . . 16 6.2.1. Address validation and registration . . . . . . . . . 16 6.2.2. Registration update . . . . . . . . . . . . . . . . . 17 6.3. Registration deletion . . . . . . . . . . . . . . . . . . 18 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 10.2. Informative References . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 1. Introduction "Neighbor Discovery for IP version 6" [RFC4861] (IPv6 ND) relies heavily on multicast signaling messages on the local Link. Conceptually, multicast is supposed to avoid broadcast messages, but, in most practical cases, its operation at the link level is that of a broadcast. This did not matter much at the time ND was originally designed, when an Ethernet network was more or less a single shared wire, but since then, large scale switched fabrics, low-power sleeping devices, mobile wireless devices and virtual machines have changed the landscape dramatically. The overhead of multicast in IPv6 ND has become significant and is now a major annoyance in multiple scenarios, in particular for wireless nodes. With WIFI, a multicast message will consume the wireless link on all Access Points around a switched fabric and will be transmitted at the lowest speed possible in order to ensure the maximum reception by all other wireless nodes. This means that in an environment where bandwidth is scarce, a single multicast packet may consume the bandwidth for hundreds of unicast packets. Sadly, IPv6 ND is a major source of multicast messages in wireless devices, since such messages are triggered each time a wireless device changes its point of attachment. A similar situation can be seen in a datacenter, where Virtual Machine (VM) mobility also triggers floods of multicast messages, Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 2] Internet-Draft WiND-SAIL October 2013 which become a major hassle as the number of VMs grows to the tens of thousands and above. At the IETF, a Working Group was created to discuss Address Resolution in Massive Datacenters (ARMD), but the work did not go to completion. The problem with IPv6 ND multicast is still present, only getting worse as the scale and degree of mobility augments with the massive introduction of new mobile devices such as virtualized appliances, IoT and BYOD. At the same time, the need to better control the ownership, utilization and location of IP addresses has become predominant in managed networks. The Source-Address Validation Improvements (SAVI) Working Group has proposed methods to locate, validate the ownership, and police the utilization of IPv6 addresses by snooping IPv6 ND and DHCP operations. But snooping requires being on the path of the protocols and is limited in particular in and for unicast responses. Mobile nodes such as BYOD may change their point of attachment in the network but an eventual renumbering can be disruptive to existing connections. Virtual devices - typically VMs in a datacenter - also move though in a different fashion, from a physical device to the next. In any case, the need to maintain a same IPv6 address across movements implies the creation of very large, eventually multi-link, subnets. In such a large subnet, it might be difficult with the existing protocols to differentiate duplication from a rapid sequence of movements. And if it is indeed a sequence of movements, then it might be difficult to select the freshest information, and additional signaling is required to obtain the actual location of an address in a deterministic fashion. In a modern managed switched fabric, a number of devices host IPv6 State Maintaining Entities (6SMEs) that hold Stateful Address Identification and Location (SAIL) information about the entity that owns an IPv6 address. A 6SME needs to reascertain periodically the state that it maintains and eliminate stale information. It is of common interest between all 6SMEs to share their information and help one another learn new state, update existing state and remove stale state rapidly. A Binding Table maintained by a secured registration protocol is certainly a more robust basis for 6SME activity than a classical IPv6 NDP [RFC4861] Neighbor Cache management coupled with protocol snooping as currently found with SAVI [RFC6620]. Mobile IPv6 [RFC6275] introduced such a registration protocol to maintain a tunnel and enable an IPv6 ND proxy operation over a Home Network. Applied to IPv6 Neighbor Discovery, the registration model balances the benefits of distributed StateLess Address AutoConfiguration (SLAAC) [RFC4862] for scalability and autonomic behaviours with the capability to reject or recuse an autoconfigured address on an exception basis - based for instance on administrative Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 3] Internet-Draft WiND-SAIL October 2013 policies -, which is a desired feature for managed networks that classically are operated with DHCPv6 [RFC3115]. In that sense, the ND registration allows a scalable hybrid of managed and non-managed networks while minimizing the total number of multicast messages between hosts, as well as between hosts and routers. An IPv6 ND registration mechanism was standardized as Neighbor Discovery Optimization for Low-power and Lossy Networks [RFC6775]. The host to SME router operation is generalized by wireless ND [I-D .chakrabarti-nordmark-6man-efficient-nd] for devices that are not necessarily attached to a LLN but may still benefit from registration. [RFC6775] also introduces a protocol between SMEs based on new ICMP messages. This draft extends that model in order to allow for a distributed, eventually hierarchical set of SMEs to share and maintain SAIL states. 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]. Readers are expected to be familiar with all the terms and concepts that are discussed in "Neighbor Discovery for IP version 6" [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals" [RFC4919], Neighbor Discovery Optimization for Low-power and Lossy Networks [RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf-ipv6 -multilink-subnets]. Readers may benefit from reading the "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate Address Detection" [RFC4429] prior to this specification for a clear understanding of the art in ND-proxying and binding. Additionally, this document uses terminology from [I-D.ietf-roll- terminology], and reuses or introduces the following terminology: 6LoWPAN Router (6LR): Please refer to [RFC6775]. 6LoWPAN Border Router (6LBR): Please refer to [RFC6775]. DAR and DAC messages: Please refer to [RFC6775]. Multi-link subnet: Please refer to [I-D.ietf-ipv6-multilink- subnets]. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 4] Internet-Draft WiND-SAIL October 2013 Backbone: A link that forms the core of a multi-link subnet. All ARs and legacy devices are connected to the Backbone and classical ND operation ensure connectivity over that link. attached link: An abstract link in a multi-link subnet other than the backbone. That link is classically not implemented as a fixed wire, and may only provide non-continuous connectivity, in particular with support for mobility. An attached link may be for instance a classical WiFi (IEEE802.11) link, a link in a wireless mesh network, or an overlay tunnel. attached node: A device in a multi-link subnet that is not directly connected to the Backbone but reachable via an attached link. Backbone Router (BBR): A BBR is an IPv6 router that connects attached links to a Backbone link and enables the connectivity of an attached node by proxying IPv6 NDP over the Backbone for that node, either with the node MAC address, or its own. The BBR is a 6SME that can obtain attachment states from attached nodes by different methods, for instance by snooping IPv6 NDP or DHCPv6, by learning host routes acting as a RPL root, by accepting ND registrations acting as an AR or an IR. Stateful Address Identification and Location (SAIL): As opposed to a cache entry, a SAIL state is Stateful in that it is obtained and maintained through a (secured) registration mechanism. A SAIL state may include for instance a secured identification of the owner of the address (e.g. a trusted token, a public key or a certificate), the position of the IPv6 address in the network (e.g. VLAN, Access Switch or Access Point), or the mapping of the IPv6 address with a MAC address. Some of this information may be stable, for instance a owner Identification, while other may be transient, for instance the Access Point identifier in a mobility scenario or the MAC address mapping in the case of NDP proxy operations. State Maintaining Entity (SME): An entity that hold SAIL information. SMEs are implemented in devices such as security appliances such as Network Access Controllers (NACs), SAVI switches that protect the ownership of an IPv6 address and control the ingress of the network, Wireless LAN Controllers (WLCs) that terminate a CAPWAP tunnel and must rapidly re- enable reachability for a mobile device both at layer 2 and layer 3, as well as overlay terminators such as used for network virtualization (NVO3). Overlay termination may operate both at layer 2 or layer 3, and may be found in data centers and enterprise networks to support mobility or extend the layer 2 fabric over a Layer 3 infrastructure, as well as in Service Provider networks to support IPv6 mobility. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 5] Internet-Draft WiND-SAIL October 2013 Binding: The association of an IPv6 address with some SAIL state. A registrar maintains a binding table to store and query such associations. Registering Node (RN): An IPv6 node that obtains and retains ownership of an IPv6 address through the process of IPv6 ND registration. Authoritative Registrar (AR): A 6SME that stores authoritative information about a registration. An AR is the reference for address and SAIL state binding within its domain of authority, e.g. a specific subset of addresses within a subnet. There can be multiple ARs in a subnet and domains may overlap for redundancy and balancing. Intermediate Registrar (IR): A 6SME that stores information about a registration as part of the registration flow. IRs form a directed acyclic graph (DAG) that is directed towards ARs. A registration from an RN will be addressed to an IR and will follow the IR DAG till it reaches a node that can grant the ownership, typically a AR. Registration Interface (RIF): The interface between an RN and an IR. The RIF is typically implemented using Wireless ND, but can also be implicitely implemented by snooping IPv6 ND, e.g. as suggested by SAVI. Validation Interface (VIF): The interface between a child IR and a parent IR or AR. The VIF is typically implemented using this specification which extends the DAR and DAC messages as defined in [RFC6775]. Determination Interface (DIF): The interface between ARs. It can be implemented using LISP, routing protocol extensions, or using IPv6 ND proxy extensions such as suggested by [I-D.thubert- 6lowpan-backbone-router] . 3. Overview The scope of this draft is a potentially large and potentially multi- link subnet [I-D.ietf-ipv6-multilink-subnets] formed by a high speed Backbone that federates additional links of heterogeneous MAC/PHY types, for instance an Ethernet switched fabric federating a Route- Over mesh that may interconnect thousands of LLN devices over multiple wireless hops. In order to avoid floods of multicast packets inherent to a reactive discovery, a node - referred to as a Registering Node (RN) - needs to claim its addresses proactively, binding them with its location in the network and a Lower Layer Address (LLA), over confirmed exchanges with a neighborhood Intermediate Registrar (IR). Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 6] Internet-Draft WiND-SAIL October 2013 +-----+ +-----+ | | AR | | AR | | | | ND proxy +-----+ +-----+ | | | Backbone Link | +--------------------+------------------+ | legacy + proxy | + registration | | mixed | ND operations | +-----+ +-----+ +-----+ | |IR | |IR | | IR + AR | |ND proxy | | | | ND proxy +-----+ +-----+ +-----+ | routing over attached links | | registration ND operations only | +-----+ +-----+ +-----+ | |IR | |IR | | IR | |--------------| |------------| | +-----+ +-----+ +-----+ The IR may confirm the claim with an Authoritative Registrar (AR), eventually over a graph of other IRs. If the ownership is granted, the RN may use the address for a lifetime that is associated with the grant, at which point it will need to reconfirm the address by registering again. In the case of a meshed 6LoWPAN [RFC6282] [RFC6775] LLN topology , the neighborhood IR is a 6LoWPAN Router (6LR) and the AR is a 6LoWPAN Border Router (6LBR). When the topology grows, the IPv6 ND registration model as described in [RFC6775], with a single AR (the 6LBR), may not scale. With this draft, all registrars maintain an abstract Binding Table of their registered addresses. The Binding Table operates as a distributed database of information related to addresses whether the address owner reside on the attached links or on the Backbone. ARs use extensions to the Neighbor Discovery Protocol to exchange that information across the Backbone either in the classical ND reactive fashion, or through a new pub/sub mechanism that is introduced by this specification. With this specification, multiple IRs and one AR can be deployed so as to scale the IPv6 ND registration model yet avoiding any broadcast beyond one Layer-2 hop; IRs cover the whole multi-link subnet in a fashion that any node in the network has at least one neighborhood IR one Layer-2 hop away so it may perform an NDP registration with that IR using link local addresses regardless of the link type, wired or wireless. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 7] Internet-Draft WiND-SAIL October 2013 +-----+ | | -----. | RN | RIF | +-----+ +-----+ +-----+ +-----+ .-> | | ----> | | ----> | | .-> | IR | VIF | IR | VIF | AR | +-----+ RIF | +-----+ +-----+ +-----+ | | -----. ^ | RN | DIF +-----+ v +-----+ +-----+ +-----+ ... | | VIF | | VIF | | +-----+ .-> | IR | ----> | IR | ----> | AR | | | RIF | +-----+ +-----+ +-----+ | RN | -----. +-----+ IRs and ARs form a DAG directed towards the AR(s); but how this DAG is set up is out of scope for this specification. If more than one AR is deployed, a strategy (e.g. a distributed hash table (DHT) or a DNS-like hierarchy) and a method to distribute and synchronize the individual domains of authority between ARs, must be put in place. Such method is out of scope for this document. In the case where an overlap of domain is acceptable, a protocol must be put in place between ARs so as to resolve conflicts, and clean up stale states. Such a protocol is out of scope for this document. 4. General Context 4.1. Efficient ND [I-D.chakrabarti-nordmark-6man-efficient-nd] updates the specification of the RIF interface between the RN and the IR, that was initially defined in [RFC6775] for 6LoWPAN devices. The draft details the operation of a IPv6 ND-efficiency-aware Router(NEAR), that is the neighborhood IR to which an RN, which is called a Efficiency-Aware Host (EAH), registers. A NEAR is also an AR as it has the exclusive authority on the bindings for its registered EAHs. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 8] Internet-Draft WiND-SAIL October 2013 +-----+ +-----+ |NEAR | IR |NEAR | IR | | AR | | AR <--. +-----+ +-----+ | | | new NDP | Backbone Link | registration +--------------------+------------------+ | | legacy + efficient | ND operations | | | | | +-------+ +-------+ +-------+ |legacy | |legacy | | EAH | RN | host | |router | | | +-------+ +-------+ +-------+ In the case of a WIFI connection, the NEAR is a BBR for the wireless device, and may be collocated with a standalone AP or a Wireless LAN Controller. +-----+ +-----+ |NEAR | IR |NEAR | IR | | AR |WLC | AR <--. +-----+ +-----+ ||| | | new NDP | Backbone Link | registration +--------------------+------------------+ ||| | | legacy + proxy | | ND operations ||| | | | | ||| o +-----+ o o +-----+ o o +-----+ o o | AP | o o | AP | o o | AP | o o +-----+ o o +-----+ o o +-----+ o o o o o o o wireless attached links EAH o RN This specification extends [I-D.chakrabarti-nordmark-6man-efficient- nd], by allowing the separation of IR and AR functions, which are collapsed inside the NEAR. This draft introduces the VIF interface between IRs, and between IRs and ARs, as well as the DIF interface between ARs with potentially overlapping domain, and other 6SMEs. For the purpose of the new NDP registration, [I-D.chakrabarti- nordmark-6man-efficient-nd] defines an extended ARO option that is advertised by an EAH. The new ARO option includes a sequence counter called TID that enables a short term freshness assertion between rapid re-registrations of a mobile device, and a unique ID that is used for the Duplicate Address Detection (DAD). Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 9] Internet-Draft WiND-SAIL October 2013 A 6SME may maintain a state for a longer time than covered by the ARO TID, so a coarse age information is be needed to compare old state information over the VIF and DIF interfaces. Additionally, the 6SME may qualify information with additional metadata to help resolve conflicts. For instance, in the case of a duplicated IPv6 address, additional meta information such as the protocol that was used to establish the state (SLAAC vs. DHCPv6), a device type (trusted server vs. unknown host), or a Secure ND cryptographic address ownership validation ([RFC3971], [RFC3972]) can help protect the address where it is assigned in a more trusted fashion even if a rogue managed to grab the address while the more trusted owner was not able to defend it. This specification proposes a new ND option that contains such information and complements the information in the ARO option for use on the VIF and DIF interfaces. 4.2. Proxying classical ND A 6SME such as an IR, a AR or a BBR may proxy classical IPv6 NDP [RFC4861] on behalf of a virtual, a wireless, or a low power device so as to offload the device, to dampen the network load such as induced by the multicast operations of the proxied protocol, or simply to attract over the backbone and then relay its traffic to the mobile or sleeping device even if the device is not reachable at that particular time. Backbone (Home) Link +--------------------+------------------+ | legacy + proxy | ND operations | | | | +-----+ +-----+ +-----+ |MIP/ |IR + |MIP/ |IR + |MIP/ |IR <-. |HA |AR |NEMO |AR |NEMO |AR | +-----+ +-----+ +-----+ Binding // | | \\ // | | \\ // | | \\ Update // | | \\ // | | MN MR MN \\ | MN MN \\ // MR MN --. MN MN tunnel-based attached links The 6SME may perform the proxy operation on behalf of an original device using the original device LLA, or may proxy the Layer-2 information with their own LLA and either rewrite it later in the packets, or route the packet again over an attached link, as examplified by a MIPv6 [RFC6275] or a NEMO [RFC3963] Home Agent (HA). Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 10] Internet-Draft WiND-SAIL October 2013 The HA is authoritative for any Mobile Node (MN) that successfully registers to it through a Binding Update/Ack flow and its domain of authority is the subnet(s) on the Home Link, potentially overlapping with other HAs. ND proxy operations are used over the Home Link to resolve collisions. The MN is thus an RN and the HA cumulates IR, AR and proxy functionalities. With NEMO [RFC3963], the model is conserved but the RN is now a Mobile Router that registers a prefix together with its own address, so the operation in the Backbone link is a mix of ND proxy and routing. Network Mobility Home Network Models [RFC3963] provides more information on that model. 4.3. Federating Large LLNs In the case of a large multi-link subnet, this specification expects that a Backbone link is deployed to interconnect all the ARs and legacy NDP devices. Each interconnected attached link, whether it is a WIFI access, a mesh network, a 6LoWPAN/RPL LLN or an overlaid tunnel, is anchored to the Backbone at a Backbone Router (BBR). The BBRs interconnect the multi-link subnet over the Backbone Link at layer 3, enabling connectivity within the subnet over IP. +-----+ +-----+ | | AR | | AR | | | | +-----+ +-----+ | | | Backbone Link | +--------------------+------------------+ | legacy + proxy | + registration | | mixed | ND operations | +-----+ +-----+ +-----+ | RPL | BBR | RPL | BBR | RPL | BBR |root | ND proxy |root | ND proxy |root | ND proxy +-----+ +-----+ +-----+ IR o o IR o o IR o o o IR o o o IR o o o IR o IR o o IR o IR o IR o IR o IR o o o o o o o o o o IR o o IR o IR o o o o LLN attached links If the LLN uses a Route-Over model based on RPL [RFC6550], the Backbone Router (BBR) that connects the LLN to the Backbone is the root for the RPL LLN. The BBR proxies the ND protocol over the backbone for the addresses that it has learnt through RPL as host routes, using its own LLA and location to attract traffic for the attached nodes and route it over the LLN. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 11] Internet-Draft WiND-SAIL October 2013 Over the Backbone, this setup implements the "simple scenario" in [I-D.ietf-ipv6-multilink-subnets] whereby the router acts "as an asymmetric Neighbor Discovery proxy"; over the RPL-based LLN mesh, the setup implements the more "complex scenario" whereby "an arbitrary topology exists, and routers within the subnet communicate using some means of exchanging host routes". [I-D.thubert-6lowpan-backbone-router] describes this mixed model, and how a Backbone Router perform ND proxy operation for their attached nodes over the The Backbone Link regardless of the mode of registration for the attached nodes. The operation described in the draft is compatible with that of a MIPv6 [RFC6275] Home Agent. This enables mobility support for wireless attached nodes that would move outside of the network delimited by the Backbone link and back. In any case, it is expected that the registration provides a sequence counter, a lifetime and a unique identifier of the attached nodes in such a fashion that they can be matched or compared across protocols. This specifications indicates how the new ND option can be used in conjunction with ND proxy techniques over the Backbone to implement the DIF interface. 5. New types and formats This section introduces message formats for all messages used in this specification. The specification expects that the protocol running on the LLN can provide a sequence number called Transaction ID (TID) that is associated to the registration. When a node registers to multiple registrars (IRs or ARs), it is expected that the same TID is used, to enable the registrar to correlate the registrations as being a single one, and differentiate that situation from a movement. Otherwise, the resolution makes it so that only the most recent registration was perceived from the highest TID is kept. The specification expects that the protocol running on the LLN can provide a unique ID for the owner of the address that is being registered. The Owner Unique ID enables to differentiate a duplicate registration from a double registration. In case of a duplicate, the last registration looses. The Owner Unique ID can be as simple as a EUI-64 burnin address, if the device manufacturor is convinced that there can not be a manuf error that would cause duplicate EUI64 Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 12] Internet-Draft WiND-SAIL October 2013 addresses. Alternatively, the unique ID can be a hash of supposedly unique information from multiple orthogonal sources, for instance: o Burn in address. o configured address, id, security keys... o (pseudo) Random number, radio link metrics ... In any fashion, it is recommended that the device stores the unique ID in persistent memory. Otherwise, it will be prevented to re- register after a reboot that would cause a loss of memory until the Backbone Router times out the registration. The unique ID and the sequence number are placed in a new ND option that is used by the Backbone Routers over the Backbone link to detect duplicates and movements. The option format is as follows: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length = 2 |R| rsv |origin | trust | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |T|N| rsv | TID | Registration age (10 sec) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + ALI + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Option Fields Type: 8-bit identifier of the type of option. Length: 2 R: One bit flag. Set if the sender is relaying the option received from a downstream node, whether a RN or an IR. origin : 4-bit unsigned integer. Indicates the origin of the entry. 0 - SLACC: Address was auto-configured on the RN [RF4862] 1 - DHCP: Address was assigned to the RN by DHCP 2 - LOCAL: Address was manually configured on the RN Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 13] Internet-Draft WiND-SAIL October 2013 3 - STATIC: Address was manually configured on the IR as a downstream address, i.e. an address assigned to a downstream node 4 - DATA: Address was gleaned on the first IR as the source of a data packet trust : 4-bit unsigned integer. Indicates the level of trust the attaching node place in the entry 0 - NO_TRUST: No particular trust associated with the entry 1 - L2L3_MATCH: The layer-2 source MAC and Link-layer-Address claimed in the registration match 2 - TRUSTED_BY_POLICY: The address is trusted by policy on the attaching node 3 - AUTHENTICATED The address has been authenticated by a cryptographic protocol (CGA, etc.)> T: One bit flag. Set if the next octet is a used as a TID following follow section 7 of RPL [RFC6550] for sequence counters. If the bit is not set, a unsigned char is expected. N: One bit flag. Set if the device moved. If not set, the router will refrain from sending gratuitous NA(O) over the backbone, for instance after the DAD operation upon entry creation. rsv: This field is unused. It MUST be initialized to zero by the sender and MUST be ignored by the receiver. TID: 1-byte integer; a transaction id that is maintained by the device and incremented with each transaction. it is recommended that the device maintains the TID in a persistent storage. The TID is incremented at each registration. Registration Age: 2-byte integer; the duration since the last update of TID in units of 10 seconds. Attaching Location Identifier: A locally unique identifier for the IR interface attaching the registering host. 6. Validation Interface Operations The Validation Interface (VIF) is the interface between a child Intermediate Registrar (IR) and a parent registrar, whether an Intermediate Registrar or Authoritative Registrar (AR). An IR parent or upstream chain is defined as the set of IRs along the DAG starting from this IR, directed to (and including) the AR. An IR child or downstream chain is defined as the set of IRs from this IR an entry was learnt from including the IR attaching to the RN. The goal of VIF is to perform one or several of the followings: Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 14] Internet-Draft WiND-SAIL October 2013 o Validate a new registration along the parent chain o Record a registration along the parent chain o Update a registration along the parent chain o Cancel a registration along the parent chain o Delete a record along the parent chain o Delete a record along the child chain 6.1. Child to Parent Operations The first IR in the chain (attached to the RN) initiates validation and registration of an address registered by the RN or snooped on the interface attaching the RN to the node, by building a DAR message, including a SLLA and a SAIL option where: o Source of the DAR is an IP address of the IR interface to the next IR in the chain. o Destination of the DAR is an IP address of the next IR. o R bit set to zero. If the IR acts as an RN, the the bit is set to 1 o Origin can take any of the values defined, based on how the address was assigned o If the registration was received from the RN (or gleaned) on an IR interface administratively trusted, the field "trust" is set to TRUSTED_BY_POLICY. Otherwise, if the registration carried CGA [RFC3971] credential that the IR successfully verified, the field "trust" is set to AUTHENTICATED. Otherwise, if the source mac of the registration message received by the IR is identical to the Link-Layer Address provided by the message in the SLLA option, the trust field is set to L2L3_MATCH. Otherwise, it is set to NO_TRUST. o An SLLA option MUST be included in the DAR message along with the SAIL option, that contains the Link-Layer address bound to the IP address bein registered. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 15] Internet-Draft WiND-SAIL October 2013 While waiting for a response, a TENTATIVE entry is created on the IR. Several attributes are stored next to the entry: the EUI64 provided by the RN, Link Layer Address provided in the SLLA option, the origin and trust values (computed by the IR, based on the registration, and local policies), the ALI the registration was received from, the lifetime. In the absence of a DAC response, DAR messages sent in the context of VIF fron the IR are retransmitted after 250ms [DAR_INTERVAL], up to 2 times [MAX_DAR_RETRANSMIT]. Upon receiving a negative response (duplicate address status) or when the maximum retransmit is exhausted, the entry is removed from the IR. The IR can also initiate update and delete operations. An update is no different from an address validation: the DAR will carry the same address and EUI-64 as the one provided in a previous validation, while any other attribute such as SLLA option, Lifetime, Origin, Trust or ALI will eventually be different from the value previously provided In order to cancel a registration, a DAR is sent, with a lifetime set to zero. It should carry a SAIL option to allow the receiving IR or AR to validate the delete. 6.2. Parent to Child Operations 6.2.1. Address validation and registration Upon receiving a DAR message with a SAIL option, an IR will lookup in the local table to verify whether the address already exist. If it does not exist, two cases arise. 1. The IR is not an AR. It creates the entry as "TENTATIVE", together with attributes such as EUI64, IR address it came from, origin and trust values. It then builds and sends a DAR message sourced with one address of its interface to the next IR, set destination address to the next IR address, sets the R bit to 1 and copies all other fields from the received DAR. It also starts a 250ms TENTATIVE_TIMER timer ot 250ms [DAR_INTERVAL]. Should this timer expire, the DAR is re-transmitted up to 2 times, then the entry is deleted. If a negative response (DAC with status 1) is received, a DAC with status 1 is sent to the downstream IR, and the TENTATIVE entry is deleted. If a positive response (DAC with status 0) is received, the timer TENTATIVE_TIMER is stopped, the entry state moved to REACHABLE and a DAC with status 0 is sent to downstream IR. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 16] Internet-Draft WiND-SAIL October 2013 2. The IR is also the AR: it queries other ARs over the DIF interface. While waiting for a response, it may create the entry in "TENTATIVE" state. Upon confirmation from another AR that the entry exist elsewhere, the entry in TENTATIVE is deleted, and a DAC message is sent back to the source of the DAR message (previous IR), with a status set to 1 (Duplicate address). Upon receiving this DAC, each downstream IR deletes its own TENTATIVE entry, and sends a DAC, status 1, to the next child IR until it reaches the IR attaching the RN, which builds an NA with ARO option, and status set to duplicate address. If the DIF interface returns no conflict on the address, the entry state is moved to REACHABLE, and a DAC with status 0 is sent to the downstream IRs which move their TENTATIVE entry to REACHABLE. When the DAC reaches the attaching IR, it send an NA with ARO option, status 0 to the RN. If the same address carried in the DAR exist on one of the IR or the AR, with a different EUI-64 interface identifier, the two entries attributes are compared. A trustlevel value is computed for each entry (as a function of the trust value, the origin and the R bit). The two trustlevel values are compared numerically as follows: 1. If the trustlevel of the existing entry is bigger or equal than the one carried by the DAR, the DAR is not propagated, and a DAC with status 1 (duplicate address) is sent back to downstream IR, up to the attaching IR which sends a NA with an ARO option, status 1 to the RN. 2. If the trustlevel of the existing entry is strictly smaller that the one carried by the DAR, it replaces it, and the DAR is propagated towards the upstream IR up to the AR. Again, DAR follow the rule of hop-by-hop retransmission and acknowledgment already described. 3. At the same time, if the entry being replaced was associated with a different IR than the one this DAR came from, another DAR, with the previous EUI64 value, and a lifetime set to zero is sent to downstream IR the previous registration came from. This message causes the downstream IR to remove the entry, provided that the EUI64 match, to build and send a DAR to the next IR, and to acknowledge the deletion with a DAC, status 0. If the EUI64 don't match, it means the entry has already been replaced, and the DAR need not to be propagated from this IR. DAR retransmission follow the same pattern already described. DAC are not propagated. Upon receiving the DAR with lifetime set to zero, the attaching IR sends an unsolicited NA to the RN with an ARO option, status 1 (duplicate address). 6.2.2. Registration update Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 17] Internet-Draft WiND-SAIL October 2013 An update message is a DAR that carries an address and EUI64 interface identifier matching an IR or AR table entry, and at least one of the following field different from the previously registered value: LifeTime, Origin, trust, ALI or IR child. Upon receiving an update, the IR or AR updates its entry and propagate to the upstream IR or AR. The AR will in return send a DAC message with a status of 0 to acknowledge the update. If the attribute being updated is the IR address the DAR is coming from (child IR), the host has moved to a different downstream IR chain, and the entry along the previous chain must be cleaned up. A DAR message, with a lifetime set to zero is sent (and retried if not acknowledged) to the old downstream IR. This message causes the downstream IR to remove the entry. The downstream IR should propagate the DAR to the next IR in chain, and acknowledge it with a DAC. 6.3. Registration deletion A registration deletion can come from the IR attaching to the RN, because the RN left the link, from any IR as the result of an administrative action, or from the AR because the lifetime has expired or again following an administrative action. In all cases, a DAR message with a lifetime set to zero is sent either upstream or downstream, retried and acknowledged at each hop along the chain, if necessary. When the deletion is initiated on the IR attaching to the RN, a SAIL option MUST be provided to enable any upstream registrar to verify that the deletion is coming from the location the RN was attached to. For deletion following the parent chain, the ALI value carried in the SAIL option is compared with the ALI value registered for this address, and entry is deleted is the two match. For deletion following the child chain, this check is not required. Upon deleting the entry, the IR builds and sends a DAC to acknowledge the deletion, then build and send a DAR to propagate the deletion, downstream or upstream. 7. Security Considerations This specification expects that the link layer is sufficiently protected, either by means of physical or IP security for the Backbone Link or MAC sublayer cryptography. In particular, it is expected that the LLN MAC provides secure unicast to/from the Backbone Router and secure BBRoadcast from the Backbone Router in a way that prevents tempering with or replaying the RA messages. The use of EUI-64 for forming the Interface ID in the link local address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and address privacy techniques. Considering the envisioned deployments and the MAC layer security applied, this is not considered an issue at this time. 8. IANA Considerations Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 18] Internet-Draft WiND-SAIL October 2013 A new type is requested for an ND option. 9. Acknowledgments TBD 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) for IPv6", RFC 4429, April 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. [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, September 2011. [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. Alexander, "RPL: IPv6 Routing Protocol for Low-Power and Lossy Networks", RFC 6550, March 2012. [RFC6620] Nordmark, E., Bagnulo, M. and E. Levy-Abegnoli, "FCFS SAVI: First-Come, First-Served Source Address Validation Improvement for Locally Assigned IPv6 Addresses", RFC 6620, May 2012. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 19] Internet-Draft WiND-SAIL October 2013 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, "Neighbor Discovery Optimization for IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs)", RFC 6775, November 2012. 10.2. Informative References [I-D.chakrabarti-nordmark-6man-efficient-nd] Chakrabarti, S., Nordmark, E. and M. Wasserman, "Efficiency aware IPv6 Neighbor Discovery Optimizations", Internet-Draft draft-chakrabarti-nordmark-6man-efficient- nd-01, November 2012. [I-D.ietf-ipv6-multilink-subnets] Thaler, D. and C. Huitema, "Multi-link Subnet Support in IPv6", Internet-Draft draft-ietf-ipv6-multilink- subnets-00, July 2002. [I-D.ietf-roll-terminology] Vasseur, J., "Terminology in Low power And Lossy Networks", Internet-Draft draft-ietf-roll-terminology-12, March 2013. [I-D.thubert-6lowpan-backbone-router] Thubert, P., "6LoWPAN Backbone Router", Internet-Draft draft-thubert-6lowpan-backbone-router-03, February 2013. [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- Specific Extensions", RFC 3115, April 2001. [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, January 2005. [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005. [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", RFC 3972, March 2005. [RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery Proxies (ND Proxy)", RFC 4389, April 2006. [RFC4887] Thubert, P., Wakikawa, R. and V. Devarapalli, "Network Mobility Home Network Models", RFC 4887, July 2007. [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 2007. [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. Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 20] Internet-Draft WiND-SAIL October 2013 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support in IPv6", RFC 6275, July 2011. Authors' Addresses Pascal Thubert Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis, 06410 FRANCE Phone: +33 4 97 23 26 34 Email: pthubert@cisco.com Eric Levy-Abegnoli Cisco Systems Village d'Entreprises Green Side 400, Avenue de Roumanille Batiment T3 Biot - Sophia Antipolis, 06410 FRANCE Phone: +33 4 97 23 26 34 Email: elevyabe@cisco.com Thubert & Levy-Abegnoli Expires April 18, 2014 [Page 21]