idnits 2.17.1 draft-thubert-6man-wind-sail-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 756 has weird spacing: '... fields fro...' == Line 848 has weird spacing: '...n, then build...' -- The document date (October 17, 2013) is 3837 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RF4862' is mentioned on line 617, but not defined == Unused Reference: 'RFC2460' is defined on line 880, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 883, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC4944' is defined on line 900, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-roll-terminology' is defined on line 936, but no explicit reference was found in the text == Unused Reference: 'RFC4887' is defined on line 961, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-07) exists of draft-chakrabarti-nordmark-6man-efficient-nd-01 == Outdated reference: A later version (-13) exists of draft-ietf-roll-terminology-12 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6MAN P. Thubert 3 Internet-Draft E. Levy-Abegnoli 4 Intended status: Standards Track Cisco 5 Expires: April 18, 2014 October 17, 2013 7 Wireless Neighbor Discovery Stateful Address Identification and Location 8 exchange 9 draft-thubert-6man-wind-sail-00 11 Abstract 13 This draft proposes an extension to IPv6 Neighbor Discovery to 14 exchange Stateful Address Identification and Location between State 15 Maintaining Entities located over a backbone link about attached 16 nodes that are attached to the backbone via a Wireless Link, in order 17 to maintain all the entities up-to-date and maintain reachability as 18 the attached nodes move. 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on April 18, 2014. 37 Copyright Notice 39 Copyright (c) 2013 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Simplified BSD License text 48 as described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 56 4. General Context . . . . . . . . . . . . . . . . . . . . . . . 8 57 4.1. Efficient ND . . . . . . . . . . . . . . . . . . . . . . . 8 58 4.2. Proxying classical ND . . . . . . . . . . . . . . . . . . 10 59 4.3. Federating Large LLNs . . . . . . . . . . . . . . . . . . 11 60 5. New types and formats . . . . . . . . . . . . . . . . . . . . 12 61 6. Validation Interface Operations . . . . . . . . . . . . . . . 14 62 6.1. Child to Parent Operations . . . . . . . . . . . . . . . . 15 63 6.2. Parent to Child Operations . . . . . . . . . . . . . . . . 16 64 6.2.1. Address validation and registration . . . . . . . . . 16 65 6.2.2. Registration update . . . . . . . . . . . . . . . . . 17 66 6.3. Registration deletion . . . . . . . . . . . . . . . . . . 18 67 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 68 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 69 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 70 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 71 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 72 10.2. Informative References . . . . . . . . . . . . . . . . . 20 73 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 75 1. Introduction 77 "Neighbor Discovery for IP version 6" [RFC4861] (IPv6 ND) relies 78 heavily on multicast signaling messages on the local Link. 79 Conceptually, multicast is supposed to avoid broadcast messages, but, 80 in most practical cases, its operation at the link level is that of a 81 broadcast. This did not matter much at the time ND was originally 82 designed, when an Ethernet network was more or less a single shared 83 wire, but since then, large scale switched fabrics, low-power 84 sleeping devices, mobile wireless devices and virtual machines have 85 changed the landscape dramatically. 87 The overhead of multicast in IPv6 ND has become significant and is 88 now a major annoyance in multiple scenarios, in particular for 89 wireless nodes. With WIFI, a multicast message will consume the 90 wireless link on all Access Points around a switched fabric and will 91 be transmitted at the lowest speed possible in order to ensure the 92 maximum reception by all other wireless nodes. This means that in an 93 environment where bandwidth is scarce, a single multicast packet may 94 consume the bandwidth for hundreds of unicast packets. Sadly, IPv6 95 ND is a major source of multicast messages in wireless devices, since 96 such messages are triggered each time a wireless device changes its 97 point of attachment. 99 A similar situation can be seen in a datacenter, where Virtual 100 Machine (VM) mobility also triggers floods of multicast messages, 101 which become a major hassle as the number of VMs grows to the tens of 102 thousands and above. At the IETF, a Working Group was created to 103 discuss Address Resolution in Massive Datacenters (ARMD), but the 104 work did not go to completion. The problem with IPv6 ND multicast is 105 still present, only getting worse as the scale and degree of mobility 106 augments with the massive introduction of new mobile devices such as 107 virtualized appliances, IoT and BYOD. 109 At the same time, the need to better control the ownership, 110 utilization and location of IP addresses has become predominant in 111 managed networks. The Source-Address Validation Improvements (SAVI) 112 Working Group has proposed methods to locate, validate the ownership, 113 and police the utilization of IPv6 addresses by snooping IPv6 ND and 114 DHCP operations. But snooping requires being on the path of the 115 protocols and is limited in particular in and for unicast responses. 117 Mobile nodes such as BYOD may change their point of attachment in the 118 network but an eventual renumbering can be disruptive to existing 119 connections. Virtual devices - typically VMs in a datacenter - also 120 move though in a different fashion, from a physical device to the 121 next. In any case, the need to maintain a same IPv6 address across 122 movements implies the creation of very large, eventually multi-link, 123 subnets. In such a large subnet, it might be difficult with the 124 existing protocols to differentiate duplication from a rapid sequence 125 of movements. And if it is indeed a sequence of movements, then it 126 might be difficult to select the freshest information, and additional 127 signaling is required to obtain the actual location of an address in 128 a deterministic fashion. 130 In a modern managed switched fabric, a number of devices host IPv6 131 State Maintaining Entities (6SMEs) that hold Stateful Address 132 Identification and Location (SAIL) information about the entity that 133 owns an IPv6 address. A 6SME needs to reascertain periodically the 134 state that it maintains and eliminate stale information. It is of 135 common interest between all 6SMEs to share their information and help 136 one another learn new state, update existing state and remove stale 137 state rapidly. A Binding Table maintained by a secured registration 138 protocol is certainly a more robust basis for 6SME activity than a 139 classical IPv6 NDP [RFC4861] Neighbor Cache management coupled 140 with protocol snooping as currently found with SAVI [RFC6620]. 142 Mobile IPv6 [RFC6275] introduced such a registration protocol to 143 maintain a tunnel and enable an IPv6 ND proxy operation over a Home 144 Network. Applied to IPv6 Neighbor Discovery, the registration model 145 balances the benefits of distributed StateLess Address 146 AutoConfiguration (SLAAC) [RFC4862] for scalability and autonomic 147 behaviours with the capability to reject or recuse an autoconfigured 148 address on an exception basis - based for instance on administrative 149 policies -, which is a desired feature for managed networks that 150 classically are operated with DHCPv6 [RFC3115]. In that sense, the 151 ND registration allows a scalable hybrid of managed and non-managed 152 networks while minimizing the total number of multicast messages 153 between hosts, as well as between hosts and routers. 155 An IPv6 ND registration mechanism was standardized as Neighbor 156 Discovery Optimization for Low-power and Lossy Networks [RFC6775]. 157 The host to SME router operation is generalized by wireless ND [I-D 158 .chakrabarti-nordmark-6man-efficient-nd] for devices that are not 159 necessarily attached to a LLN but may still benefit from 160 registration. [RFC6775] also introduces a protocol between SMEs 161 based on new ICMP messages. This draft extends that model in order 162 to allow for a distributed, eventually hierarchical set of SMEs to 163 share and maintain SAIL states. 165 2. Terminology 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [RFC2119]. 171 Readers are expected to be familiar with all the terms and concepts 172 that are discussed in "Neighbor Discovery for IP version 6" 173 [RFC4861], "IPv6 Stateless Address Autoconfiguration" [RFC4862], 174 "IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): 175 Overview, Assumptions, Problem Statement, and Goals" [RFC4919], 176 Neighbor Discovery Optimization for Low-power and Lossy Networks 177 [RFC6775] and "Multi-link Subnet Support in IPv6" [I-D.ietf-ipv6 178 -multilink-subnets]. 180 Readers may benefit from reading the "RPL: IPv6 Routing Protocol for 181 Low-Power and Lossy Networks" [RFC6550] specification; "Multi-Link 182 Subnet Issues" [RFC4903]; "Mobility Support in IPv6" [RFC6275]; 183 "Neighbor Discovery Proxies (ND Proxy)" [RFC4389]; "FCFS SAVI: 184 First-Come, First-Served Source Address Validation Improvement for 185 Locally Assigned IPv6 Addresses" [RFC6620]; and "Optimistic Duplicate 186 Address Detection" [RFC4429] prior to this specification for a clear 187 understanding of the art in ND-proxying and binding. 189 Additionally, this document uses terminology from [I-D.ietf-roll- 190 terminology], and reuses or introduces the following terminology: 192 6LoWPAN Router (6LR): Please refer to [RFC6775]. 194 6LoWPAN Border Router (6LBR): Please refer to [RFC6775]. 196 DAR and DAC messages: Please refer to [RFC6775]. 198 Multi-link subnet: Please refer to [I-D.ietf-ipv6-multilink- 199 subnets]. 201 Backbone: A link that forms the core of a multi-link subnet. All ARs 202 and legacy devices are connected to the Backbone and classical 203 ND operation ensure connectivity over that link. 205 attached link: An abstract link in a multi-link subnet other than the 206 backbone. That link is classically not implemented as a fixed 207 wire, and may only provide non-continuous connectivity, in 208 particular with support for mobility. An attached link may be 209 for instance a classical WiFi (IEEE802.11) link, a link in a 210 wireless mesh network, or an overlay tunnel. 212 attached node: A device in a multi-link subnet that is not directly 213 connected to the Backbone but reachable via an attached link. 215 Backbone Router (BBR): A BBR is an IPv6 router that connects attached 216 links to a Backbone link and enables the connectivity of an 217 attached node by proxying IPv6 NDP over the Backbone for that 218 node, either with the node MAC address, or its own. The BBR is 219 a 6SME that can obtain attachment states from attached nodes by 220 different methods, for instance by snooping IPv6 NDP or DHCPv6, 221 by learning host routes acting as a RPL root, by accepting ND 222 registrations acting as an AR or an IR. 224 Stateful Address Identification and Location (SAIL): As opposed to a 225 cache entry, a SAIL state is Stateful in that it is obtained 226 and maintained through a (secured) registration mechanism. A 227 SAIL state may include for instance a secured identification of 228 the owner of the address (e.g. a trusted token, a public key 229 or a certificate), the position of the IPv6 address in the 230 network (e.g. VLAN, Access Switch or Access Point), or the 231 mapping of the IPv6 address with a MAC address. Some of this 232 information may be stable, for instance a owner Identification, 233 while other may be transient, for instance the Access Point 234 identifier in a mobility scenario or the MAC address mapping in 235 the case of NDP proxy operations. 237 State Maintaining Entity (SME): An entity that hold SAIL 238 information. SMEs are implemented in devices such as security 239 appliances such as Network Access Controllers (NACs), SAVI 240 switches that protect the ownership of an IPv6 address and 241 control the ingress of the network, Wireless LAN Controllers 242 (WLCs) that terminate a CAPWAP tunnel and must rapidly re- 243 enable reachability for a mobile device both at layer 2 and 244 layer 3, as well as overlay terminators such as used for 245 network virtualization (NVO3). Overlay termination may operate 246 both at layer 2 or layer 3, and may be found in data centers 247 and enterprise networks to support mobility or extend the layer 248 2 fabric over a Layer 3 infrastructure, as well as in Service 249 Provider networks to support IPv6 mobility. 251 Binding: The association of an IPv6 address with some SAIL state. A 252 registrar maintains a binding table to store and query such 253 associations. 255 Registering Node (RN): An IPv6 node that obtains and retains 256 ownership of an IPv6 address through the process of IPv6 ND 257 registration. 259 Authoritative Registrar (AR): A 6SME that stores authoritative 260 information about a registration. An AR is the reference for 261 address and SAIL state binding within its domain of authority, 262 e.g. a specific subset of addresses within a subnet. There 263 can be multiple ARs in a subnet and domains may overlap for 264 redundancy and balancing. 266 Intermediate Registrar (IR): A 6SME that stores information about a 267 registration as part of the registration flow. IRs form a 268 directed acyclic graph (DAG) that is directed towards ARs. A 269 registration from an RN will be addressed to an IR and will 270 follow the IR DAG till it reaches a node that can grant the 271 ownership, typically a AR. 273 Registration Interface (RIF): The interface between an RN and an IR. 274 The RIF is typically implemented using Wireless ND, but can 275 also be implicitely implemented by snooping IPv6 ND, e.g. as 276 suggested by SAVI. 278 Validation Interface (VIF): The interface between a child IR and a 279 parent IR or AR. The VIF is typically implemented using this 280 specification which extends the DAR and DAC messages as defined 281 in [RFC6775]. 283 Determination Interface (DIF): The interface between ARs. It can be 284 implemented using LISP, routing protocol extensions, or using 285 IPv6 ND proxy extensions such as suggested by [I-D.thubert- 286 6lowpan-backbone-router] . 288 3. Overview 290 The scope of this draft is a potentially large and potentially multi- 291 link subnet [I-D.ietf-ipv6-multilink-subnets] formed by a high speed 292 Backbone that federates additional links of heterogeneous MAC/PHY 293 types, for instance an Ethernet switched fabric federating a Route- 294 Over mesh that may interconnect thousands of LLN devices over 295 multiple wireless hops. 297 In order to avoid floods of multicast packets inherent to a reactive 298 discovery, a node - referred to as a Registering Node (RN) - needs to 299 claim its addresses proactively, binding them with its location in 300 the network and a Lower Layer Address (LLA), over confirmed exchanges 301 with a neighborhood Intermediate Registrar (IR). 303 +-----+ +-----+ 304 | | AR | | AR 305 | | | | ND proxy 306 +-----+ +-----+ 307 | | 308 | Backbone Link | 309 +--------------------+------------------+ 310 | legacy + proxy | + registration | 311 | mixed | ND operations | 312 +-----+ +-----+ +-----+ 313 | |IR | |IR | | IR + AR 314 | |ND proxy | | | | ND proxy 315 +-----+ +-----+ +-----+ 316 | routing over attached links | 317 | registration ND operations only | 318 +-----+ +-----+ +-----+ 319 | |IR | |IR | | IR 320 | |--------------| |------------| | 321 +-----+ +-----+ +-----+ 323 The IR may confirm the claim with an Authoritative Registrar (AR), 324 eventually over a graph of other IRs. If the ownership is granted, 325 the RN may use the address for a lifetime that is associated with the 326 grant, at which point it will need to reconfirm the address by 327 registering again. 329 In the case of a meshed 6LoWPAN [RFC6282] [RFC6775] LLN topology , 330 the neighborhood IR is a 6LoWPAN Router (6LR) and the AR is a 6LoWPAN 331 Border Router (6LBR). When the topology grows, the IPv6 ND 332 registration model as described in [RFC6775], with a single AR (the 333 6LBR), may not scale. 335 With this draft, all registrars maintain an abstract Binding Table of 336 their registered addresses. The Binding Table operates as a 337 distributed database of information related to addresses whether the 338 address owner reside on the attached links or on the Backbone. ARs 339 use extensions to the Neighbor Discovery Protocol to exchange that 340 information across the Backbone either in the classical ND reactive 341 fashion, or through a new pub/sub mechanism that is introduced by 342 this specification. 344 With this specification, multiple IRs and one AR can be deployed so 345 as to scale the IPv6 ND registration model yet avoiding any broadcast 346 beyond one Layer-2 hop; IRs cover the whole multi-link subnet in a 347 fashion that any node in the network has at least one neighborhood IR 348 one Layer-2 hop away so it may perform an NDP registration with that 349 IR using link local addresses regardless of the link type, wired or 350 wireless. 352 +-----+ 353 | | -----. 354 | RN | RIF | +-----+ +-----+ +-----+ 355 +-----+ .-> | | ----> | | ----> | | 356 .-> | IR | VIF | IR | VIF | AR | 357 +-----+ RIF | +-----+ +-----+ +-----+ 358 | | -----. ^ 359 | RN | DIF 360 +-----+ v 361 +-----+ +-----+ +-----+ 362 ... | | VIF | | VIF | | 363 +-----+ .-> | IR | ----> | IR | ----> | AR | 364 | | RIF | +-----+ +-----+ +-----+ 365 | RN | -----. 366 +-----+ 368 IRs and ARs form a DAG directed towards the AR(s); but how this DAG 369 is set up is out of scope for this specification. 371 If more than one AR is deployed, a strategy (e.g. a distributed hash 372 table (DHT) or a DNS-like hierarchy) and a method to distribute and 373 synchronize the individual domains of authority between ARs, must be 374 put in place. Such method is out of scope for this document. In the 375 case where an overlap of domain is acceptable, a protocol must be put 376 in place between ARs so as to resolve conflicts, and clean up stale 377 states. Such a protocol is out of scope for this document. 379 4. General Context 381 4.1. Efficient ND 383 [I-D.chakrabarti-nordmark-6man-efficient-nd] updates the 384 specification of the RIF interface between the RN and the IR, that 385 was initially defined in [RFC6775] for 6LoWPAN devices. The draft 386 details the operation of a IPv6 ND-efficiency-aware Router(NEAR), 387 that is the neighborhood IR to which an RN, which is called a 388 Efficiency-Aware Host (EAH), registers. A NEAR is also an AR as it 389 has the exclusive authority on the bindings for its registered EAHs. 391 +-----+ +-----+ 392 |NEAR | IR |NEAR | IR 393 | | AR | | AR <--. 394 +-----+ +-----+ | 395 | | new NDP 396 | Backbone Link | registration 397 +--------------------+------------------+ | 398 | legacy + efficient | ND operations | | 399 | | | 400 +-------+ +-------+ +-------+ 401 |legacy | |legacy | | EAH | RN 402 | host | |router | | | 403 +-------+ +-------+ +-------+ 405 In the case of a WIFI connection, the NEAR is a BBR for the wireless 406 device, and may be collocated with a standalone AP or a Wireless LAN 407 Controller. 409 +-----+ +-----+ 410 |NEAR | IR |NEAR | IR 411 | | AR |WLC | AR <--. 412 +-----+ +-----+ ||| 413 | | new NDP 414 | Backbone Link | registration 415 +--------------------+------------------+ ||| 416 | | legacy + proxy | | ND operations ||| 417 | | | | ||| 418 o +-----+ o o +-----+ o o +-----+ o 419 o | AP | o o | AP | o o | AP | o 420 o +-----+ o o +-----+ o o +-----+ o 421 o o o o o o 422 wireless attached links EAH o RN 424 This specification extends [I-D.chakrabarti-nordmark-6man-efficient- 425 nd], by allowing the separation of IR and AR functions, which are 426 collapsed inside the NEAR. This draft introduces the VIF interface 427 between IRs, and between IRs and ARs, as well as the DIF interface 428 between ARs with potentially overlapping domain, and other 6SMEs. 430 For the purpose of the new NDP registration, [I-D.chakrabarti- 431 nordmark-6man-efficient-nd] defines an extended ARO option that is 432 advertised by an EAH. The new ARO option includes a sequence counter 433 called TID that enables a short term freshness assertion between 434 rapid re-registrations of a mobile device, and a unique ID that is 435 used for the Duplicate Address Detection (DAD). 437 A 6SME may maintain a state for a longer time than covered by the ARO 438 TID, so a coarse age information is be needed to compare old state 439 information over the VIF and DIF interfaces. Additionally, the 6SME 440 may qualify information with additional metadata to help resolve 441 conflicts. For instance, in the case of a duplicated IPv6 address, 442 additional meta information such as the protocol that was used to 443 establish the state (SLAAC vs. DHCPv6), a device type (trusted 444 server vs. unknown host), or a Secure ND cryptographic address 445 ownership validation ([RFC3971], [RFC3972]) can help protect the 446 address where it is assigned in a more trusted fashion even if a 447 rogue managed to grab the address while the more trusted owner was 448 not able to defend it. 450 This specification proposes a new ND option that contains such 451 information and complements the information in the ARO option for use 452 on the VIF and DIF interfaces. 454 4.2. Proxying classical ND 456 A 6SME such as an IR, a AR or a BBR may proxy classical IPv6 NDP 457 [RFC4861] on behalf of a virtual, a wireless, or a low power device 458 so as to offload the device, to dampen the network load such as 459 induced by the multicast operations of the proxied protocol, or 460 simply to attract over the backbone and then relay its traffic to the 461 mobile or sleeping device even if the device is not reachable at that 462 particular time. 464 Backbone (Home) Link 465 +--------------------+------------------+ 466 | legacy + proxy | ND operations | 467 | | | 468 +-----+ +-----+ +-----+ 469 |MIP/ |IR + |MIP/ |IR + |MIP/ |IR <-. 470 |HA |AR |NEMO |AR |NEMO |AR | 471 +-----+ +-----+ +-----+ Binding 472 // | | \\ // | | \\ // | | \\ Update 473 // | | \\ // | | MN MR MN \\ | 474 MN MN \\ // MR MN --. 475 MN MN tunnel-based attached links 477 The 6SME may perform the proxy operation on behalf of an original 478 device using the original device LLA, or may proxy the Layer-2 479 information with their own LLA and either rewrite it later in the 480 packets, or route the packet again over an attached link, as 481 examplified by a MIPv6 [RFC6275] or a NEMO [RFC3963] Home Agent 482 (HA). 484 The HA is authoritative for any Mobile Node (MN) that successfully 485 registers to it through a Binding Update/Ack flow and its domain of 486 authority is the subnet(s) on the Home Link, potentially overlapping 487 with other HAs. ND proxy operations are used over the Home Link to 488 resolve collisions. 490 The MN is thus an RN and the HA cumulates IR, AR and proxy 491 functionalities. With NEMO [RFC3963], the model is conserved but 492 the RN is now a Mobile Router that registers a prefix together with 493 its own address, so the operation in the Backbone link is a mix of ND 494 proxy and routing. Network Mobility Home Network Models [RFC3963] 495 provides more information on that model. 497 4.3. Federating Large LLNs 499 In the case of a large multi-link subnet, this specification expects 500 that a Backbone link is deployed to interconnect all the ARs and 501 legacy NDP devices. Each interconnected attached link, whether it is 502 a WIFI access, a mesh network, a 6LoWPAN/RPL LLN or an overlaid 503 tunnel, is anchored to the Backbone at a Backbone Router (BBR). The 504 BBRs interconnect the multi-link subnet over the Backbone Link at 505 layer 3, enabling connectivity within the subnet over IP. 507 +-----+ +-----+ 508 | | AR | | AR 509 | | | | 510 +-----+ +-----+ 511 | | 512 | Backbone Link | 513 +--------------------+------------------+ 514 | legacy + proxy | + registration | 515 | mixed | ND operations | 516 +-----+ +-----+ +-----+ 517 | RPL | BBR | RPL | BBR | RPL | BBR 518 |root | ND proxy |root | ND proxy |root | ND proxy 519 +-----+ +-----+ +-----+ 520 IR o o IR o o IR o o o IR o 521 o o IR o o o IR o IR o o IR o IR 522 o IR o IR o IR o o o o o o o o o 523 o IR o o IR o IR 524 o o o o LLN attached links 526 If the LLN uses a Route-Over model based on RPL [RFC6550], the 527 Backbone Router (BBR) that connects the LLN to the Backbone is the 528 root for the RPL LLN. The BBR proxies the ND protocol over the 529 backbone for the addresses that it has learnt through RPL as host 530 routes, using its own LLA and location to attract traffic for the 531 attached nodes and route it over the LLN. 533 Over the Backbone, this setup implements the "simple scenario" in 534 [I-D.ietf-ipv6-multilink-subnets] whereby the router acts "as an 535 asymmetric Neighbor Discovery proxy"; over the RPL-based LLN mesh, 536 the setup implements the more "complex scenario" whereby "an 537 arbitrary topology exists, and routers within the subnet communicate 538 using some means of exchanging host routes". 540 [I-D.thubert-6lowpan-backbone-router] describes this mixed model, and 541 how a Backbone Router perform ND proxy operation for their attached 542 nodes over the The Backbone Link regardless of the mode of 543 registration for the attached nodes. The operation described in the 544 draft is compatible with that of a MIPv6 [RFC6275] Home Agent. This 545 enables mobility support for wireless attached nodes that would move 546 outside of the network delimited by the Backbone link and back. In 547 any case, it is expected that the registration provides a sequence 548 counter, a lifetime and a unique identifier of the attached nodes in 549 such a fashion that they can be matched or compared across protocols. 551 This specifications indicates how the new ND option can be used in 552 conjunction with ND proxy techniques over the Backbone to implement 553 the DIF interface. 555 5. New types and formats 557 This section introduces message formats for all messages used in this 558 specification. 560 The specification expects that the protocol running on the LLN can 561 provide a sequence number called Transaction ID (TID) that is 562 associated to the registration. When a node registers to multiple 563 registrars (IRs or ARs), it is expected that the same TID is used, to 564 enable the registrar to correlate the registrations as being a single 565 one, and differentiate that situation from a movement. Otherwise, 566 the resolution makes it so that only the most recent registration was 567 perceived from the highest TID is kept. 569 The specification expects that the protocol running on the LLN can 570 provide a unique ID for the owner of the address that is being 571 registered. The Owner Unique ID enables to differentiate a duplicate 572 registration from a double registration. In case of a duplicate, the 573 last registration looses. The Owner Unique ID can be as simple as a 574 EUI-64 burnin address, if the device manufacturor is convinced that 575 there can not be a manuf error that would cause duplicate EUI64 576 addresses. Alternatively, the unique ID can be a hash of supposedly 577 unique information from multiple orthogonal sources, for instance: 579 o Burn in address. 581 o configured address, id, security keys... 583 o (pseudo) Random number, radio link metrics ... 585 In any fashion, it is recommended that the device stores the unique 586 ID in persistent memory. Otherwise, it will be prevented to re- 587 register after a reboot that would cause a loss of memory until the 588 Backbone Router times out the registration. 590 The unique ID and the sequence number are placed in a new ND option 591 that is used by the Backbone Routers over the Backbone link to detect 592 duplicates and movements. The option format is as follows: 594 0 1 2 3 595 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 596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 597 | Type | Length = 2 |R| rsv |origin | trust | 598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 599 |T|N| rsv | TID | Registration age (10 sec) | 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | | 602 + ALI + 603 | | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 606 Option Fields 608 Type: 8-bit identifier of the type of option. 610 Length: 2 612 R: One bit flag. Set if the sender is relaying the option received 613 from a downstream node, whether a RN or an IR. 615 origin : 4-bit unsigned integer. Indicates the origin of the entry. 617 0 - SLACC: Address was auto-configured on the RN [RF4862] 619 1 - DHCP: Address was assigned to the RN by DHCP 621 2 - LOCAL: Address was manually configured on the RN 622 3 - STATIC: Address was manually configured on the IR as a 623 downstream address, i.e. an address assigned to a downstream 624 node 626 4 - DATA: Address was gleaned on the first IR as the source of a 627 data packet 629 trust : 4-bit unsigned integer. Indicates the level of trust the 630 attaching node place in the entry 632 0 - NO_TRUST: No particular trust associated with the entry 634 1 - L2L3_MATCH: The layer-2 source MAC and Link-layer-Address 635 claimed in the registration match 637 2 - TRUSTED_BY_POLICY: The address is trusted by policy on the 638 attaching node 640 3 - AUTHENTICATED The address has been authenticated by a 641 cryptographic protocol (CGA, etc.)> 643 T: One bit flag. Set if the next octet is a used as a TID following 644 follow section 7 of RPL [RFC6550] for sequence counters. If the 645 bit is not set, a unsigned char is expected. 647 N: One bit flag. Set if the device moved. If not set, the router 648 will refrain from sending gratuitous NA(O) over the backbone, for 649 instance after the DAD operation upon entry creation. 651 rsv: This field is unused. It MUST be initialized to zero by the 652 sender and MUST be ignored by the receiver. 654 TID: 1-byte integer; a transaction id that is maintained by the 655 device and incremented with each transaction. it is recommended 656 that the device maintains the TID in a persistent storage. The 657 TID is incremented at each registration. 659 Registration Age: 2-byte integer; the duration since the last update 660 of TID in units of 10 seconds. 662 Attaching Location Identifier: A locally unique identifier for the IR 663 interface attaching the registering host. 665 6. Validation Interface Operations 667 The Validation Interface (VIF) is the interface between a child 668 Intermediate Registrar (IR) and a parent registrar, whether an 669 Intermediate Registrar or Authoritative Registrar (AR). An IR parent 670 or upstream chain is defined as the set of IRs along the DAG starting 671 from this IR, directed to (and including) the AR. An IR child or 672 downstream chain is defined as the set of IRs from this IR an entry 673 was learnt from including the IR attaching to the RN. The goal of VIF 674 is to perform one or several of the followings: 676 o Validate a new registration along the parent chain 678 o Record a registration along the parent chain 680 o Update a registration along the parent chain 682 o Cancel a registration along the parent chain 684 o Delete a record along the parent chain 686 o Delete a record along the child chain 688 6.1. Child to Parent Operations 690 The first IR in the chain (attached to the RN) initiates validation 691 and registration of an address registered by the RN or snooped on the 692 interface attaching the RN to the node, by building a DAR message, 693 including a SLLA and a SAIL option where: 695 o Source of the DAR is an IP address of the IR interface to the next 696 IR in the chain. 698 o Destination of the DAR is an IP address of the next IR. 700 o R bit set to zero. If the IR acts as an RN, the the bit is set to 701 1 703 o Origin can take any of the values defined, based on how the 704 address was assigned 706 o If the registration was received from the RN (or gleaned) on an IR 707 interface administratively trusted, the field "trust" is set to 708 TRUSTED_BY_POLICY. Otherwise, if the registration carried CGA 709 [RFC3971] credential that the IR successfully verified, the field 710 "trust" is set to AUTHENTICATED. Otherwise, if the source mac of 711 the registration message received by the IR is identical to the 712 Link-Layer Address provided by the message in the SLLA option, the 713 trust field is set to L2L3_MATCH. Otherwise, it is set to 714 NO_TRUST. 716 o An SLLA option MUST be included in the DAR message along with the 717 SAIL option, that contains the Link-Layer address bound to the IP 718 address bein registered. 720 While waiting for a response, a TENTATIVE entry is created on the IR. 721 Several attributes are stored next to the entry: the EUI64 provided 722 by the RN, Link Layer Address provided in the SLLA option, the origin 723 and trust values (computed by the IR, based on the registration, and 724 local policies), the ALI the registration was received from, the 725 lifetime. In the absence of a DAC response, DAR messages sent in the 726 context of VIF fron the IR are retransmitted after 250ms 727 [DAR_INTERVAL], up to 2 times [MAX_DAR_RETRANSMIT]. Upon receiving a 728 negative response (duplicate address status) or when the maximum 729 retransmit is exhausted, the entry is removed from the IR. 731 The IR can also initiate update and delete operations. An update is 732 no different from an address validation: the DAR will carry the same 733 address and EUI-64 as the one provided in a previous validation, 734 while any other attribute such as SLLA option, Lifetime, Origin, 735 Trust or ALI will eventually be different from the value previously 736 provided 738 In order to cancel a registration, a DAR is sent, with a lifetime set 739 to zero. It should carry a SAIL option to allow the receiving IR or 740 AR to validate the delete. 742 6.2. Parent to Child Operations 744 6.2.1. Address validation and registration 746 Upon receiving a DAR message with a SAIL option, an IR will lookup in 747 the local table to verify whether the address already exist. 749 If it does not exist, two cases arise. 751 1. The IR is not an AR. It creates the entry as "TENTATIVE", 752 together with attributes such as EUI64, IR address it came from, 753 origin and trust values. It then builds and sends a DAR message 754 sourced with one address of its interface to the next IR, set 755 destination address to the next IR address, sets the R bit to 1 756 and copies all other fields from the received DAR. It also 757 starts a 250ms TENTATIVE_TIMER timer ot 250ms [DAR_INTERVAL]. 758 Should this timer expire, the DAR is re-transmitted up to 2 759 times, then the entry is deleted. If a negative response (DAC 760 with status 1) is received, a DAC with status 1 is sent to the 761 downstream IR, and the TENTATIVE entry is deleted. If a positive 762 response (DAC with status 0) is received, the timer 763 TENTATIVE_TIMER is stopped, the entry state moved to REACHABLE 764 and a DAC with status 0 is sent to downstream IR. 766 2. The IR is also the AR: it queries other ARs over the DIF 767 interface. While waiting for a response, it may create the entry 768 in "TENTATIVE" state. Upon confirmation from another AR that the 769 entry exist elsewhere, the entry in TENTATIVE is deleted, and a 770 DAC message is sent back to the source of the DAR message 771 (previous IR), with a status set to 1 (Duplicate address). Upon 772 receiving this DAC, each downstream IR deletes its own TENTATIVE 773 entry, and sends a DAC, status 1, to the next child IR until it 774 reaches the IR attaching the RN, which builds an NA with ARO 775 option, and status set to duplicate address. If the DIF 776 interface returns no conflict on the address, the entry state is 777 moved to REACHABLE, and a DAC with status 0 is sent to the 778 downstream IRs which move their TENTATIVE entry to REACHABLE. 779 When the DAC reaches the attaching IR, it send an NA with ARO 780 option, status 0 to the RN. 782 If the same address carried in the DAR exist on one of the IR or the 783 AR, with a different EUI-64 interface identifier, the two entries 784 attributes are compared. A trustlevel value is computed for each 785 entry (as a function of the trust value, the origin and the R bit). 786 The two trustlevel values are compared numerically as follows: 788 1. If the trustlevel of the existing entry is bigger or equal than 789 the one carried by the DAR, the DAR is not propagated, and a DAC 790 with status 1 (duplicate address) is sent back to downstream IR, 791 up to the attaching IR which sends a NA with an ARO option, 792 status 1 to the RN. 794 2. If the trustlevel of the existing entry is strictly smaller that 795 the one carried by the DAR, it replaces it, and the DAR is 796 propagated towards the upstream IR up to the AR. Again, DAR 797 follow the rule of hop-by-hop retransmission and acknowledgment 798 already described. 800 3. At the same time, if the entry being replaced was associated with 801 a different IR than the one this DAR came from, another DAR, with 802 the previous EUI64 value, and a lifetime set to zero is sent to 803 downstream IR the previous registration came from. This message 804 causes the downstream IR to remove the entry, provided that the 805 EUI64 match, to build and send a DAR to the next IR, and to 806 acknowledge the deletion with a DAC, status 0. If the EUI64 don't 807 match, it means the entry has already been replaced, and the DAR 808 need not to be propagated from this IR. DAR retransmission 809 follow the same pattern already described. DAC are not 810 propagated. Upon receiving the DAR with lifetime set to zero, 811 the attaching IR sends an unsolicited NA to the RN with an ARO 812 option, status 1 (duplicate address). 814 6.2.2. Registration update 815 An update message is a DAR that carries an address and EUI64 816 interface identifier matching an IR or AR table entry, and at least 817 one of the following field different from the previously registered 818 value: LifeTime, Origin, trust, ALI or IR child. Upon receiving an 819 update, the IR or AR updates its entry and propagate to the upstream 820 IR or AR. The AR will in return send a DAC message with a status of 0 821 to acknowledge the update. 823 If the attribute being updated is the IR address the DAR is coming 824 from (child IR), the host has moved to a different downstream IR 825 chain, and the entry along the previous chain must be cleaned up. A 826 DAR message, with a lifetime set to zero is sent (and retried if not 827 acknowledged) to the old downstream IR. This message causes the 828 downstream IR to remove the entry. The downstream IR should 829 propagate the DAR to the next IR in chain, and acknowledge it with a 830 DAC. 832 6.3. Registration deletion 834 A registration deletion can come from the IR attaching to the RN, 835 because the RN left the link, from any IR as the result of an 836 administrative action, or from the AR because the lifetime has 837 expired or again following an administrative action. In all cases, a 838 DAR message with a lifetime set to zero is sent either upstream or 839 downstream, retried and acknowledged at each hop along the chain, if 840 necessary. When the deletion is initiated on the IR attaching to the 841 RN, a SAIL option MUST be provided to enable any upstream registrar 842 to verify that the deletion is coming from the location the RN was 843 attached to. For deletion following the parent chain, the ALI value 844 carried in the SAIL option is compared with the ALI value registered 845 for this address, and entry is deleted is the two match. For 846 deletion following the child chain, this check is not required. Upon 847 deleting the entry, the IR builds and sends a DAC to acknowledge the 848 deletion, then build and send a DAR to propagate the deletion, 849 downstream or upstream. 851 7. Security Considerations 853 This specification expects that the link layer is sufficiently 854 protected, either by means of physical or IP security for the 855 Backbone Link or MAC sublayer cryptography. In particular, it is 856 expected that the LLN MAC provides secure unicast to/from the 857 Backbone Router and secure BBRoadcast from the Backbone Router in a 858 way that prevents tempering with or replaying the RA messages. 860 The use of EUI-64 for forming the Interface ID in the link local 861 address prevents the usage of Secure ND ([RFC3971] and [RFC3972]) and 862 address privacy techniques. Considering the envisioned deployments 863 and the MAC layer security applied, this is not considered an issue 864 at this time. 866 8. IANA Considerations 867 A new type is requested for an ND option. 869 9. Acknowledgments 871 TBD 873 10. References 875 10.1. Normative References 877 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 878 Requirement Levels", BCP 14, RFC 2119, March 1997. 880 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 881 6 (IPv6) Specification", RFC 2460, December 1998. 883 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 884 Architecture", RFC 4291, February 2006. 886 [RFC4429] Moore, N., "Optimistic Duplicate Address Detection (DAD) 887 for IPv6", RFC 4429, April 2006. 889 [RFC4443] Conta, A., Deering, S. and M. Gupta, "Internet Control 890 Message Protocol (ICMPv6) for the Internet Protocol 891 Version 6 (IPv6) Specification", RFC 4443, March 2006. 893 [RFC4861] Narten, T., Nordmark, E., Simpson, W. and H. Soliman, 894 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 895 September 2007. 897 [RFC4862] Thomson, S., Narten, T. and T. Jinmei, "IPv6 Stateless 898 Address Autoconfiguration", RFC 4862, September 2007. 900 [RFC4944] Montenegro, G., Kushalnagar, N., Hui, J. and D. Culler, 901 "Transmission of IPv6 Packets over IEEE 802.15.4 902 Networks", RFC 4944, September 2007. 904 [RFC6282] Hui, J. and P. Thubert, "Compression Format for IPv6 905 Datagrams over IEEE 802.15.4-Based Networks", RFC 6282, 906 September 2011. 908 [RFC6550] Winter, T., Thubert, P., Brandt, A., Hui, J., Kelsey, R., 909 Levis, P., Pister, K., Struik, R., Vasseur, JP. and R. 910 Alexander, "RPL: IPv6 Routing Protocol for Low-Power and 911 Lossy Networks", RFC 6550, March 2012. 913 [RFC6620] Nordmark, E., Bagnulo, M. and E. Levy-Abegnoli, "FCFS 914 SAVI: First-Come, First-Served Source Address Validation 915 Improvement for Locally Assigned IPv6 Addresses", RFC 916 6620, May 2012. 918 [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E. and C. Bormann, 919 "Neighbor Discovery Optimization for IPv6 over Low-Power 920 Wireless Personal Area Networks (6LoWPANs)", RFC 6775, 921 November 2012. 923 10.2. Informative References 925 [I-D.chakrabarti-nordmark-6man-efficient-nd] 926 Chakrabarti, S., Nordmark, E. and M. Wasserman, 927 "Efficiency aware IPv6 Neighbor Discovery Optimizations", 928 Internet-Draft draft-chakrabarti-nordmark-6man-efficient- 929 nd-01, November 2012. 931 [I-D.ietf-ipv6-multilink-subnets] 932 Thaler, D. and C. Huitema, "Multi-link Subnet Support in 933 IPv6", Internet-Draft draft-ietf-ipv6-multilink- 934 subnets-00, July 2002. 936 [I-D.ietf-roll-terminology] 937 Vasseur, J., "Terminology in Low power And Lossy 938 Networks", Internet-Draft draft-ietf-roll-terminology-12, 939 March 2013. 941 [I-D.thubert-6lowpan-backbone-router] 942 Thubert, P., "6LoWPAN Backbone Router", Internet-Draft 943 draft-thubert-6lowpan-backbone-router-03, February 2013. 945 [RFC3115] Dommety, G. and K. Leung, "Mobile IP Vendor/Organization- 946 Specific Extensions", RFC 3115, April 2001. 948 [RFC3963] Devarapalli, V., Wakikawa, R., Petrescu, A. and P. 949 Thubert, "Network Mobility (NEMO) Basic Support Protocol", 950 RFC 3963, January 2005. 952 [RFC3971] Arkko, J., Kempf, J., Zill, B. and P. Nikander, "SEcure 953 Neighbor Discovery (SEND)", RFC 3971, March 2005. 955 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 956 RFC 3972, March 2005. 958 [RFC4389] Thaler, D., Talwar, M. and C. Patel, "Neighbor Discovery 959 Proxies (ND Proxy)", RFC 4389, April 2006. 961 [RFC4887] Thubert, P., Wakikawa, R. and V. Devarapalli, "Network 962 Mobility Home Network Models", RFC 4887, July 2007. 964 [RFC4903] Thaler, D., "Multi-Link Subnet Issues", RFC 4903, June 965 2007. 967 [RFC4919] Kushalnagar, N., Montenegro, G. and C. Schumacher, "IPv6 968 over Low-Power Wireless Personal Area Networks (6LoWPANs): 969 Overview, Assumptions, Problem Statement, and Goals", RFC 970 4919, August 2007. 972 [RFC6275] Perkins, C., Johnson, D. and J. Arkko, "Mobility Support 973 in IPv6", RFC 6275, July 2011. 975 Authors' Addresses 977 Pascal Thubert 978 Cisco Systems 979 Village d'Entreprises Green Side 980 400, Avenue de Roumanille 981 Batiment T3 982 Biot - Sophia Antipolis, 06410 983 FRANCE 985 Phone: +33 4 97 23 26 34 986 Email: pthubert@cisco.com 988 Eric Levy-Abegnoli 989 Cisco Systems 990 Village d'Entreprises Green Side 991 400, Avenue de Roumanille 992 Batiment T3 993 Biot - Sophia Antipolis, 06410 994 FRANCE 996 Phone: +33 4 97 23 26 34 997 Email: elevyabe@cisco.com