idnits 2.17.1 draft-ietf-netlmm-mn-ar-if-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1221. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1198. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1205. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1211. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 26, 2006) is 6512 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) == Unused Reference: 'RFC2434' is defined on line 1028, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 1032, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 1035, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-netlmm-threats' is defined on line 1123, but no explicit reference was found in the text == Unused Reference: 'I-D.thaler-intarea-multilink-subnet-issues' is defined on line 1129, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-11) exists of draft-ietf-ipv6-2461bis-07 ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) == Outdated reference: A later version (-05) exists of draft-ietf-ipv6-privacy-addrs-v2-04 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dna-hosts' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dna-routers' -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dna-cpl' -- Possible downref: Normative reference to a draft: ref. 'I-D.pentland-dna-protocol' -- Possible downref: Normative reference to a draft: ref. 'I-D.wood-netlmm-emp-base' -- No information found for draft-ietf-ipv6-2462bis - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-ipv6-2462bis' -- Obsolete informational reference (is this intentional?): RFC 3316 (Obsoleted by RFC 7066) == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-ps-04 == Outdated reference: A later version (-05) exists of draft-ietf-netlmm-nohost-req-01 == Outdated reference: A later version (-04) exists of draft-ietf-netlmm-threats-00 Summary: 9 errors (**), 0 flaws (~~), 13 warnings (==), 15 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Laganier 3 Internet-Draft DoCoMo Euro-Labs 4 Expires: December 28, 2006 S. Narayanan 5 Panasonic 6 F. Templin 7 Boeing Phantom Works 8 June 26, 2006 10 Network-based Localized Mobility Management Interface between Mobile 11 Node and Access Router 12 draft-ietf-netlmm-mn-ar-if-01 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 This document may not be modified, and derivative works of it may not 21 be created, except to publish it as an RFC and to translate it into 22 languages other than English. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on December 28, 2006. 42 Copyright Notice 44 Copyright (C) The Internet Society (2006). 46 Abstract 48 This document specifies an IP layer interface between mobile nodes 49 (MN) and access routers (AR) of a network-based localized mobility 50 management (NetLMM) domain. Such an interface is subject to a 51 certain number of threats, amongst which are attacks on the mapping 52 between the MN Identifier and IPv6 address set. A binding 53 enforcement mechanism between those two is hence required to prevent 54 malicious nodes to carry on various attacks like service theft or 55 denial-of-service attacks. In the absence of link-layer specific 56 mechanisms enforcing this binding, it is required to implement such 57 mechanism at the IP layer MN-AR interface. Moreover, it is required 58 that no NetLMM specific software support is present on MNs. The IP 59 layer MN-AR interface described in this document fulfills these two 60 requirements by using the SEND public key as the MN identifier, while 61 being solely based on standard track IPv6 protocols (DNA and SEND.) 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 68 1.3. Operating Environment . . . . . . . . . . . . . . . . . . 6 69 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 70 2.1. MN powers on in a NetLMM domain . . . . . . . . . . . . . 9 71 2.1.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 9 72 2.1.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 10 73 2.2. First attachment of MN moving into a new NetLMM domain . . 11 74 2.2.1. SLAAC Method . . . . . . . . . . . . . . . . . . . . . 11 75 2.2.2. DHCP Method . . . . . . . . . . . . . . . . . . . . . 13 76 2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 13 77 2.3.1. MN using SLAAC getting handover hint . . . . . . . . . 13 78 2.3.2. MN using DHCP getting handover hint . . . . . . . . . 14 79 2.3.3. AR getting handover hint . . . . . . . . . . . . . . . 15 80 2.4. MN configuring additional CGAs/prefixes . . . . . . . . . 16 81 2.5. MN configuring CGA that is in use by another MN in the 82 NetLMM domain . . . . . . . . . . . . . . . . . . . . . . 16 83 2.5.1. MN using SLAAC configuring colliding CGA . . . . . . . 16 84 2.5.2. MN using DHCP configuring colliding global CGA . . . . 17 85 2.6. MN unconfigures CGAs, powers off, crashes or leaves 86 the domain . . . . . . . . . . . . . . . . . . . . . . . . 17 87 3. MN Specification . . . . . . . . . . . . . . . . . . . . . . . 20 88 4. AR Specification . . . . . . . . . . . . . . . . . . . . . . . 22 89 4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 22 90 4.2. Receiving ND Messages from MN . . . . . . . . . . . . . . 23 91 4.2.1. Receiving DAD NSs . . . . . . . . . . . . . . . . . . 23 92 4.2.2. Receiving All Others ND Messages . . . . . . . . . . . 23 93 4.3. Sending ND Messages to MN . . . . . . . . . . . . . . . . 23 94 4.3.1. Sending NSs . . . . . . . . . . . . . . . . . . . . . 23 95 4.3.2. Sending Proxy NAs . . . . . . . . . . . . . . . . . . 24 96 4.3.3. Sending RAs . . . . . . . . . . . . . . . . . . . . . 24 97 4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 24 98 4.4. Receiving All Other IPv6 Packets from MN . . . . . . . . . 24 99 4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 24 100 4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 24 101 4.4.3. Forwarding Packets . . . . . . . . . . . . . . . . . . 25 102 4.5. MN Identifier and IP addresses . . . . . . . . . . . . . . 25 103 5. Multilink Subnet Considerations . . . . . . . . . . . . . . . 26 104 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 105 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 106 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 107 8.1. Normative references . . . . . . . . . . . . . . . . . . . 29 108 8.2. Informative references . . . . . . . . . . . . . . . . . . 30 109 Appendix A. Version history . . . . . . . . . . . . . . . . . . . 32 110 A.1. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 32 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 33 112 Intellectual Property and Copyright Statements . . . . . . . . . . 34 114 1. Introduction 116 It is suggested in [I-D.ietf-netlmm-nohost-ps] that it would be 117 desirable to have a localized mobility management protocol in which 118 the host is not involved. The requirements for such a protocol have 119 been analyzed in [I-D.ietf-netlmm-nohost-req]. Accordingly, a 120 protocol for network-based localized mobility management (NetLMM) of 121 IPv6 nodes will be specified by the NetLMM working group; until this 122 occurs, this document assumes [I-D.wood-netlmm-emp-base] as a 123 strawman NetLMM protocol in use in a NetLMM domain. Further 124 revisions of this document will need to be adapted to the NetLMM 125 protocol proposal chosen by the working group. Because the NetLMM 126 protocol is network based, the mobile node (MN) is not required to 127 implement new mechanism in its IP stack, nor to change its IP address 128 when it attaches to a new access router (AR.) 130 Because the IPv6 MN will use a vanilla IPv6 stack, the interface 131 between a MN and its AR has to be preserved. This means that 132 standard IPv6 should work seamlessly with the network-based localized 133 mobility support. More specifically, we require the proposed 134 solution to be compatible with the mechanisms specified in: 136 o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] 138 o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] 140 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 142 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 143 [I-D.ietf-ipv6-privacy-addrs-v2] 145 o Detecting Network Attachment in IPv6 - Best Current Practices for 146 Hosts [I-D.ietf-dna-hosts] 148 o Detecting Network Attachment in IPv6 - Best Current Practices for 149 Routers [I-D.ietf-dna-routers] 151 o Detecting Network Attachment with Unmodified Routers: A Prefix 152 List based approach [I-D.ietf-dna-cpl] 154 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 155 protocol] 157 o SEcure Neighbor Discovery [RFC3971] 159 o Cryptographically Generated Addresses [RFC3972] 161 This document specifies an IP layer interface between MNs and ARs of 162 a NetLMM domain. Such an interface is subject to a certain number of 163 threats, amongst which are attacks on the mapping between the MN 164 Identifier and IPv6 address set. A binding enforcement mechanism 165 between those two is hence required to prevent malicious nodes to 166 carry on various attacks like service theft or denial-of-service 167 attacks. In the absence of link-layer specific mechanisms enforcing 168 this binding, it is required to implement such mechanism at the IP 169 layer MN-AR interface. Moreover, it is required that no NetLMM 170 specific software support is present on MNs. The IP layer MN-AR 171 interface described in this document fulfills these two requirements 172 by using the SEND public key as the MN identifier, while being solely 173 based on standard track IPv6 protocols (DNA and SEND.) 175 1.1. Terminology 177 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 178 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 179 document are to be interpreted as described in [RFC2119]. 181 The following terms are defined within the scope of this document: 183 Mobile Node (MN) 184 an IPv6 node moving in the NetLMM domain. 186 Access Router (AR) 187 a default router that connects the MN to the NetLMM domain. 189 access interface 190 a network interface of an AR attached to the link used by the MN. 192 Mobility Anchor Point (MAP) 193 a router located in the NetLMM domain that handles packet 194 exchanges with nodes in the domain. 196 Network-based Localized Mobility Management Domain (NetLMM domain) 197 an administrative domain spanning links served by a set of MAPs 198 (and their associated ARs and MNs) that provision addresses from 199 the same IP subnet prefix(es). 201 Network-based Localized Mobility Management Protocol (NLMP) 202 The NetLMM Protocol used in the backhaul of the NetLMM domain 203 between ARs and MAP. 205 1.2. Abbreviations 207 The following abbreviations are used throughout this document: 209 NetLMM: Network-based Localized Mobility Management 210 ND: Neighbor Discovery. 212 NS: Neighbor Solicitation. 214 NA: Neighbor Advertizement. 216 RS: Router Solicitation. 218 RA: Router Advertisement. 220 NDP: Neighbor Discovery Protocol. 222 SLAAC: StateLess Address AutoConfiguration 224 DHCP: Dynamic Host Configuration Protocol 226 SEND: SEcure Neighbor Discovery. 228 DNA: Detecting Network Attachment. 230 CGA: Cryptographically Generated Address. 232 CGA_LL: The link-local unicast CGA generated by the MN with its 233 public key (It is assumed that the MN is using a single public key to 234 configure all of its link-local unicast and global unicast CGAs.) 236 CGA_1: One of the Global Unicast CGA generated by the MN with its 237 public key. 239 CGA_2: Another one of the Global Unicast CGA generated by the MN with 240 its public key (e.g. with a different subnet prefix.) 242 CGA_*: Any Unicast CGA generated by the MN with its public key (i.e. 243 link-local or global.) 245 MNID: MN identifier set to the public key used by the MN for 246 generating its CGAs. 248 1.3. Operating Environment 250 The MN-AR NetLMM interface is used between a MN and an AR of a NetLMM 251 domain. In the absence of link-layer specific mechanism, it allows 252 the AR and/or MN to detect network attachment, causing the AR to use 253 NLMP to update routing at the MAP so that the MN stays reachable when 254 it roams across the NetLMM domain. 256 /-------------------------\ 257 / Internet \ 258 \ / 259 \-------+---------+-------/ 260 | | 261 /-------+---------+-------\ ---- 262 / \ ^ 263 / +-----+ \ | 264 | | MAP |-+ | N 265 | +-----+ |-+ | E 266 | +-----+ | | T 267 | +-----+ | L 268 | Backhaul Network | M 269 | +-----+ +-----+ | M 270 |- - | AR1 | ..... | ARn | - -| 271 | +-----+ +-----+ | d 272 | / \ Access / \ | o 273 | / \ Network / \ | m 274 | / \ / \ | a 275 | +----+ | i 276 | | MN | -------> | n 277 \ +----+ AR change / | 278 \ / v 279 \-------------------------/ ---- 281 Figure 1: Reference Network Diagram 283 The deployment scenario is shown in Figure 1 above: Several ARs are 284 attached to an IP routing domain connected to the outside Internet 285 via a MAP. The MNs, ARs, MAPs, and in-between routing fabric 286 constitute the NetLMM domain. Each AR announces on its access 287 interface a common set of prefix(es) which are routed to the MAP from 288 the outside Internet. Packets arriving at the MAP and destined to a 289 MN are tunneled to the appropriate AR. 291 In the absence of a link-layer specific MN-AR interface, it is 292 required to have a common interface defined at the IP layer. Because 293 no NetLMM specific software support is assumed to be present on MNs, 294 this interface has to rely only on standard tracks IPv6 protocols 295 such as ND, DHCP, SEND, and DNA. Interactions of these components 296 with NetLMM are represented in Figure 2 below (note that hints 297 received by DNA from other layers are omitted for clarity): 299 MN|AR 300 Interface 301 | 303 | +------------+ +----------+ 304 | | | | 305 | | +--------+ | NLMP | +------+ | 306 | | NetLMM |<-------->|NetLMM| | 307 | | +--------+ | | +------+ | 308 | ^ ^ | | ^ | 309 +----------+ | | | | | | | | 310 | | | v | | | | | 311 | +------+ | | | +-----+ | | | | | 312 | | DNA | | NDP/DHCP | | DNA | | | | | | 313 | | SEND |<------|------>|SEND | | | | | | 314 | | ND | | | | ND | | | | | | 315 | | DHCP | | | | |DHCP | | | | | | 316 | +------+ | | +-----+ | | | | | 317 | ^ | | | ^ | | | | | 318 | | | | | | | | | | 319 | v | | | v | | | v | 320 | +------+ | | +----+ | | | +------+ | 321 | | | | | | | |<-+ | | | | | 322 | | | | IPv6 | | | | IPv6 | | | | 323 | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | 324 | +------+ | | +----+ | | +------+ | 325 | | | | | | | 326 | MN | | AR | | MAP | 327 +----------+ | +------------+ +----------+ 329 | 331 Figure 2: NetLMM Component Interactions 333 2. Protocol Overview 335 The following subsections present the different situations in which 336 an IP-based MN-AR interface is used to trigger the NetLMM protocol. 338 In the following figures it is assumed that the MN and AR clocks are 339 synchronized enough to allow verification of ND messages via SEND 340 timestamps. If that would not be the case, in order to verify 341 freshness of ND signaling sent by the MN, the AR would be required to 342 solicit the MN by sending to it an NS with a fresh nonce, to which 343 the MN would reply with an NA containing the same fresh nonce. 345 2.1. MN powers on in a NetLMM domain 347 2.1.1. SLAAC Method 349 MN AR MAP 350 | | | 351 | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | 352 |----------------------->|---------------------->| bind(CGA_LL,MNID) 353 | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) 354 | |<----------------------| 355 |RS(CGA_LL->All_routers) | | 356 |----------------------->| | 357 | RA(AR->{MN,All_nodes}) | | 358 |<-----------------------| | 359 | | | 360 | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | 361 |----------------------->|---------------------->| bind(CGA_1,MNID) 362 | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) 363 | |<----------------------| 364 | | | 365 | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | 366 |----------------------->|---------------------->| bind(CGA_2,MNID) 367 | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR) 368 | |<----------------------| 369 | | | 371 Figure 3: MN powers on and configures a Link-Local and two Global 372 Unicast CGAs using SLAAC 374 As shown in Figure 3 above, when a MN using SLAAC powers on for the 375 first time, it will generate a link local address based on its public 376 key (CGA_LL) as per [RFC3972], and perform DAD on the address as per 377 [RFC2462]. The NS(DAD) message generated will contain the public key 378 in the CGA option as defined by SEND [RFC3971]. Upon reception of 379 this NS message, the AR MUST generate an UPDATE to the MAP with the 380 public key as the MNID along with CGA_LL. The MAP MUST bind the 381 CGA_LL to the MNID and establish a route binding for the CGA_LL to 382 the AR. The MAP acknowledges the receipt of the UPDATE message. 384 While waiting for the completion of DAD, the MN may generate an RS 385 message as per [RFC2461] with the unspecified address as the source 386 address. Such a message will not contain a CGA option. The AR will 387 respond with a multicast RA as per [RFC2461]. Alternatively, the MN 388 will wait for completion of DAD and generate an RS message with its 389 CGA-LL as the source address. With the prefix information received 390 in the RA message, the MN can cryptographically generate one or more 391 global addresses (CGA_*). For each of these addresses, the MN will 392 perform DAD as the IID is likely to be different for each of these 393 cryptographically generated addresses. For every NS(DAD) received 394 from the MN, the AR will generate an UPDATE message to the MAP 395 establishing binding in the MAP. 397 The use of multicast RAs may however not be acceptable in all NetLMM 398 domains, e.g., when multiple MAPs and/or prefixes are used. In that 399 case, the network has to somehow force the MN to source RSs from its 400 CGA-LL, so that the AR can send to that CGA-LL a unicast RA 401 containing the appropriate prefix information. This can be achieved 402 by having the AR simply discard any RS sourced from the unspecified 403 address, so that eventually the MN will complete DAD for its CGA-LL 404 and start to use it as a source address while retransmitting RSs. 406 2.1.2. DHCP Method 408 MN AR MAP 409 | | | 410 | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | 411 |----------------------->|---------------------->| bind(CGA_LL,MNID) 412 | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) 413 | |<----------------------| 414 |RS(CGA_LL->All_routers) | | 415 |----------------------->| | 416 | RA(AR->{MN,All_nodes}) | | 417 |<-----------------------| | 418 | | | 419 | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | 420 |----------------------->|---------------------->| bind(CGA_1,MNID) 421 | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR) 422 |<-----------------------|<----------------------| route(CGA_2->AR) 423 | | | 425 Figure 4: MN powers on and configures a Link-Local and two Global 426 Unicast CGAs using DHCP with two-message exchange 427 As shown in Figure 4 above, when a MN using DHCP powers on for the 428 first time it will cryptographically generate a CGA_LL and perform an 429 RS/RA exchange as specified for the SLAAC method in Section 2.1.1. 431 The MN will then use its public key to generate a DHCP Unique 432 Identifier (DUID) and Identity Association (IA) per ([RFC3315], 433 Sections 9 and 10). If prefix information is included in the RA 434 message, the MN can next cryptographically generate one or more 435 global addresses (CGA_*). (The MN can additionally request 436 delegation of prefixes per [RFC3633].) The MN will then issue a DHCP 437 SOLICIT message including the DUID, IA and IA Address options that 438 encode any CGA_*s as options. (Alternatively, the MN can omit IA 439 Address options and allow the network to delegate non-CGA addresses.) 440 If a two-message exchange is preferred, the MN will also include a 441 Rapid Commit option in the DHCP SOLICIT per ([RFC3315], Section 442 17.1.2). 444 When the AR receives the DHCP SOLICIT (using two-message exchange) or 445 DHCP REQUEST (using four-message exchange), it performs the same 446 UPDATE/REPLY procedure as specified in Section 2.1.1, and returns a 447 DHCP REPLY message with an appropriate status code to the MN. 449 The issues involved with the use of multicast RAs as described in 450 Section 2.1.1 might be valid when DHCP is used for address 451 configuration. 453 2.2. First attachment of MN moving into a new NetLMM domain 455 2.2.1. SLAAC Method 456 MN AR MAP 457 | | | 458 | RS | UPDATE(MNID,CGA_LL) | 459 |---------------------->|---------------------->| bind(CGA_LL,MNID) 460 | RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR) 461 |<----------------------|<----------------------| 462 | NS(DAD:CGA_LL) | | 463 |---------------------->| | 464 | | | 465 | | | 466 | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | 467 |---------------------->|---------------------->| bind(CGA_1,MNID) 468 | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) 469 | |<----------------------| 470 | | | 471 | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | 472 |---------------------->|---------------------->| bind(CGA_2,MNID) 473 | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR) 474 | |<----------------------| 475 | | | 477 Figure 5: MN moves into a NetLMM domain and configures a Link-Local 478 and two Global Unicast CGAs using SLAAC 480 As shown in Figure 5 above, when a MN using SLAAC moves into a NetLMM 481 domain for the first time, it will initiate link change detection as 482 specified in [I-D.pentland-dna-protocol] by multicast transmission of 483 an RS message. When the MN receives an RA message in response, it 484 will figure out that it has changed to a link in a new NetLMM domain 485 as defined by the DNA specification [I-D.pentland-dna-protocol]. 486 Once the MN realizes it has changed to a new NetLMM domain, it will 487 discard its current IP addresses and will execute DAD for its link- 488 local address and new global addresses based on the prefix 489 information in the received RA messages. 491 The global address configuration procedures of the MN, AR and MAP are 492 the same as specified in Section 2.1.1. 494 2.2.2. DHCP Method 496 MN AR MAP 497 | | | 498 |RS(CGA_LL->All_routers)| UPDATE(MNID,CGA_LL) | 499 |---------------------->|---------------------->| bind(CGA_LL,MNID) 500 | RA |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2) 501 |<----------------------|<----------------------| 502 | NS(DAD:CGA_LL) | | 503 |---------------------->| | 504 | | | 505 | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | 506 |---------------------->|---------------------->| bind(CGA_1,MNID) 507 | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR) 508 |<----------------------|<----------------------| route(CGA_2->AR) 509 | | | 511 Figure 6: MN moves into a NetLMM domain and configures a Link-Local 512 and two Global Unicast CGAs using DHCP 514 As shown in Figure 6 above, when a MN using DHCP moves into a NetLMM 515 domain for the first time, it will initiate link change detection as 516 specified in [I-D.pentland-dna-protocol] by multicast transmission of 517 an RS message. When the MN receives an RA message in response, it 518 will figure out that it has changed to a link in a new NetLMM domain 519 as defined by the DNA specification [I-D.pentland-dna-protocol] 520 and/or by sending a DHCP CONFIRM message as specified in 521 Section 2.3.2. Once the MN realizes it has changed to a new NetLMM 522 domain, it will discard its current IP addresses and will execute DAD 523 for its link-local address and configure new global addresses/ 524 prefixes using DHCP. 526 The global address configuration procedures of the MN, AR and MAP are 527 the same as specified in Section 2.1.2. 529 2.3. MN handovers in a NetLMM-domain 531 2.3.1. MN using SLAAC getting handover hint 532 MN AR MAP 533 | | | 534 |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | 535 |----------------------->|---------------------->| route(CGA_LL->AR) 536 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) 537 | RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR) 538 |<-----------------------|<----------------------| 539 | | | 541 Figure 7: MN using SLAAC getting handover hint and receives a unicast 542 RA 544 As shown in Figure 7, when MN using SLAAC moves within the NetLMM 545 domain, it will send an RS message with the source address as its 546 link-local address as specified by [I-D.pentland-dna-protocol]. The 547 AR again can use the public key in the CGA option to infer the MNID 548 and send UPDATEs to the MAP. If the AR chooses to respond with a 549 unicast RA, all required steps are done. 551 MN AR MAP 552 | | | 553 |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | 554 |----------------------->|---------------------->| route(CGA_LL->AR) 555 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) 556 | RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR) 557 |<-----------------------|<----------------------| 558 | NS(CGA_LL->AR) | | 559 |----------------------->| | 560 | NA(AR->CGA_LL) | | 561 |<-----------------------| | 562 | | | 564 Figure 8: MN using SLAAC getting handover hint and receives a 565 multicast RA 567 In a similar scenario, as shown in Figure 8, if the AR chooses to 568 respond with a multicast RA, the MN will send an NS to learn about 569 the AR and confirm reachability. 571 2.3.2. MN using DHCP getting handover hint 573 When a MN using the DHCP access method moves within the NetLMM 574 domain, it receives the same handover hints as specified in 575 Section 2.3.1. 577 MN AR MAP 578 | | | 579 | DHCP CONFIRM(CGA_*) | UPDATE(MNID,CGA_*) | 580 |----------------------->|---------------------->| route(CGA_LL->AR) 581 | DHCP REPLY(STATUS) | REPLY[OK](MNID,CGA_*) | route(CGA_1->AR) 582 |<-----------------------|<----------------------| route(CGA_2->AR) 583 | | | 585 Figure 9: DHCP CONFIRM message exchange 587 As shown in Figure 9, when the MN figures out that it has changed 588 link, it sends a DHCP CONFIRM message containing its IA and all of 589 the CGAs/prefixes it has previously registered per ([RFC3315], 590 Section 18.1.2). The AR will generate an UPDATE message to the MAP 591 and will send a DHCP REPLY message to the MN with appropriate status 592 codes. 594 2.3.3. AR getting handover hint 596 MN AR MAP 597 | | | 598 | NS(AR->CGA_*) | | 599 |<-----------------------| | 600 | NA(CGA_*->AR) | UPDATE(MNID,CGA_*) | 601 |----------------------->|---------------------->| route(CGA_LL->AR) 602 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) 603 | | CGA_1,CGA_2) | route(CGA_2->AR) 604 | |<----------------------| 605 | | | 607 Figure 10: AR getting handover hint of MN whose IP address is known 609 As shown in Figure 10, instead of the MN receiving the hint in 610 scenarios where the AR receives the hint with the IP address of the 611 handing over MN, the AR can send an NS to that IP address. The NA 612 message received in response will contain the public key of the MN 613 with which the AR can send an UPDATE message to the MAP. 615 MN AR MAP 616 | | | 617 | RA(AR->All_nodes) | | 618 |<-----------------------| | 619 | NS(CGA_*->AR) | UPDATE(MNID,CGA_*) | 620 |----------------------->|---------------------->| route(CGA_LL->AR) 621 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR) 622 | NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR) 623 |<-----------------------|<----------------------| 624 | | | 626 Figure 11: AR getting handover hint of MN whose IP address is unknown 628 As shown in Figure 11, if the AR does not receive the IP address 629 information of the handing over MN along with the hint, the AR can 630 schedule a multicast RA. The MN will try to fill its neighbor cache 631 information with the AR and confirm its reachability by initiating an 632 NS message to the AR. The AR can then send an UPDATE message to the 633 MAP based on the public key in the NS message. 635 2.4. MN configuring additional CGAs/prefixes 637 If the MN chooses to configure new global addresses/prefixes at any 638 point in time, it will contact the AR to configure the new addresses/ 639 prefixes as specified in Section 2.1. 641 2.5. MN configuring CGA that is in use by another MN in the NetLMM 642 domain 644 2.5.1. MN using SLAAC configuring colliding CGA 646 MN1 AR1 MAP AR2 MN2 647 | | | | | 648 | NS(DAD) |UPDATE(MNID,CGA,NS)| | | 649 |-------->|------------------>| collision(MNID) | | 650 | | | | | 651 | | | QUERY[DAD](NS) | NS(DAD) | 652 | | |---------------->|-------->| 653 | | | REPLY[DAD](NA) | NA | 654 | | |<----------------|<--------| 655 | NA |REPLY[COLLIDE](NA) | 656 |<--------|<------------------| 657 | | | 659 Figure 12: MN using SLAAC configuring a colliding CGA 660 As shown in Figure 12, AR1 learns about new global addresses 661 configured by an MN MN1 from the NS(DAD) message sent by MN1. When 662 AR1 sends an UPDATE to the MAP based on this NS(DAD), it also 663 includes the entire NS in the message, and waits for a positive 664 acknowledgment from the MAP. If the MAP has an entry for the same 665 CGA with a different MNID, it will proxy this NS(DAD) up to the AR 666 where the duplicate occurs (AR2). AR2 will then proxy the NS(DAD) by 667 sending it to the solicited-node multicast address of the colliding 668 MN MN2, and will receive back a signed NA from MN2. AR2 will then 669 forward this signed NA to AR1 via the MAP. At that point, AR1 can 670 securely defend the duplicate address on behalf of MN2 by sending to 671 MN1 the signed NA. 673 2.5.2. MN using DHCP configuring colliding global CGA 675 MN AR MAP 676 | | | 677 | DHCP SOLICIT(CGA_*) | UPDATE(MNID,CGA_*) | 678 |----------------------->|---------------------->| collision(CGA_*) 679 | DHCP REPLY(status) | REPLY[COLLIDE](CGA_*) | 680 |<-----------------------|<----------------------| 681 | | | 683 Figure 13: MN using DHCP configuring a colliding global CGA 685 As shown in Figure 13, when a MN using DHCP configures one or more 686 global CGAs, the MAP sends a REPLY to the AR with an indication for 687 each global CGA that collided. The AR then sends a DHCP REPLY 688 message to the MN with the appropriate status code for each colliding 689 CGA. 691 2.6. MN unconfigures CGAs, powers off, crashes or leaves the domain 693 The AR SHOULD do periodic reachability testing with the MN using 694 Neighbor Unreachability Detection (NUD) to learn about addresses 695 being unconfigured or the MN being powered off or crashing. The 696 trigger for this test could be neighbor cache entry timeout or a 697 MLDv2 [RFC3810] unsubscribe for the solicited-node multicast address 698 matching the MN's CGA. 700 MN AR MAP 701 | | | 702 | NS(AR->CGA_LL) | | 703 |<-----------------------| | 704 | NA(CGA_LL->AR) | | 705 |----------------------->| | 706 | NS(AR->CGA_1) | | 707 | X <------------------| | 708 | NS(AR->CGA_2) | | 709 |<-----------------------| | 710 | NA(CGA_2->AR) | | 711 |----------------------->| | 712 | NS(AR->CGA_3) | | 713 |<-----------------------| | 714 | NA(CGA_3->AR) | | 715 |----------------------->| | 716 | |UPDATE[DEL](MNID,CGA_1)| 717 | |---------------------->| del_route(CGA_1) 718 | | REPLY[OK](MNID) | 719 | |<----------------------| 720 | | | 722 Figure 14: MN unconfigures a CGA 724 As shown in Figure 14, the MN stops using the address CGA_1 and when 725 the AR tries NUD for each of these addresses, it doesn't receive a 726 response for CGA_1, resulting in an UPDATE message to the MAP to 727 remove the mapping between MNID and CGA_1. 729 MN AR MAP 730 | | | 731 | NS(AR->CGA_LL) | | 732 | X <------------------| | 733 | NS(AR->CGA_1) | | 734 | X <------------------| | 735 | NS(AR->CGA_2) | | 736 | X <------------------| | 737 | NS(AR->CGA_3) | | 738 | X <------------------| | 739 | | UPDATE[DEL](MNID) | 740 | |---------------------->| del_route(CGA_LL) 741 | | REPLY[OK](MNID) | del_route(CGA_1) 742 | |<----------------------| del_route(CGA_2) 743 | | | del_route(CGA_3) 744 | | | del_bind(MNID) 746 Figure 15: MN crashes, powers off or leaves the domain 747 As shown in Figure 15, if the MN crashes, powers off or leaves the 748 domain, the NUD will fail for all the associated addresses. In this 749 case, the AR can remove the entry for the MN from the MAP by 750 initiating an UPDATE message. 752 3. MN Specification 754 NetLMM place few specific requirements on an MN in a NetLMM domain. 755 However, for the smooth operation of the NetLMM MN-AR interface, the 756 MN MUST behave as specified in the following documents: 758 o Neighbor Discovery for IP version 6 [RFC2461] (MUST) and 759 [I-D.ietf-ipv6-2461bis] (SHOULD) 761 o IPv6 Stateless Address Autoconfiguration [RFC2462] (MUST) and 762 [I-D.ietf-ipv6-2462bis] (SHOULD) 764 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 765 [I-D.ietf-ipv6-privacy-addrs-v2] 767 o Detecting Network Attachment in IPv6 - Best Current Practices for 768 Hosts [I-D.ietf-dna-hosts] 770 o Detecting Network Attachment in IPv6 - Best Current Practices for 771 Routers [I-D.ietf-dna-routers] 773 o Detecting Network Attachment with Unmodified Routers: A Prefix 774 List based approach [I-D.ietf-dna-cpl] 776 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 777 protocol] 779 o SEcure Neighbor Discovery [RFC3971] 781 o Cryptographically Generated Addresses [RFC3972] 783 Also, for MNs attached to networks that use DHCP, the MN MUST support 784 the DHCP client message exchanges specified in: 786 o Dynamic Host Configuration Protocol for IPv6 [RFC3315] 788 The MN MUST use a single public key to generate all of its CGAs. 789 This requirement is necessary to make it possible for the AR and MAP 790 to bind together different addresses of the MN. That way, when a MN 791 attaches to a new AR, the MAP will correctly update routing for all 792 MN CGAs even if the MN is currently using only one of those (e.g. its 793 link-local CGA) to send an RS. 795 With respect to the MUST support [RFC2461] and [RFC2462], and SHOULD 796 support [I-D.ietf-ipv6-2461bis] and [I-D.ietf-ipv6-2462bis], the 797 reason is that SEND avoids complication with the "DAD once per IID" 798 optimization of [RFC2462]. This is because IIDs of CGAs with 799 different subnet prefixes are different (subnet prefix is used as an 800 input parameter to the CGA generation algorithm.) 802 For NBMA links, links over which multicast is not well supported or 803 for selection of specific neighbors, MNs and ARs can send packets 804 addressed to the pre-defined multicast addresses specified in 805 ([RFC4291], Section 2.7.1) to the Layer-2 unicast address(es) of one 806 or more neighbors. 808 4. AR Specification 810 A NetLMM AR MUST behave as specified in the following documents: 812 o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] 814 o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] 816 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 817 [I-D.ietf-ipv6-privacy-addrs-v2] 819 o Detecting Network Attachment in IPv6 - Best Current Practices for 820 Hosts [I-D.ietf-dna-hosts] 822 o Detecting Network Attachment in IPv6 - Best Current Practices for 823 Routers [I-D.ietf-dna-routers] 825 o Detecting Network Attachment with Unmodified Routers: A Prefix 826 List based approach [I-D.ietf-dna-cpl] 828 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 829 protocol] 831 o SEcure Neighbor Discovery [RFC3971] 833 o Cryptographically Generated Addresses [RFC3972] 835 Also, ARs MUST respond to DHCP client messages in a manner that is 836 consistent with the DHCP relay/server messaging specified in: 838 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 840 In addition, the AR MUST conform to the supplementary NetLMM specific 841 requirements which follow in this section. 843 4.1. Promiscuous and all-multicast modes 845 The AR SHOULD put its access interface (the one exposed to MNs) in 846 snooping/promiscuous mode so that it can receive most of the packets 847 exchanged on the link it is serving. If a layer 2 switch is present 848 between the AR and MNs, the port to which the AR is connected SHOULD 849 be put in snooping/promiscuous mode. At the minimum, the AR MUST put 850 its interface into a "receive all-multicast traffic" mode, and 851 registers with MLDv2 [RFC3810] to all link-local solicited node 852 multicast addresses to which a MN registers to with MLDv2. This 853 insures that the AR can receive NSs so that it can proxy solicited 854 NAs when the target MN is off-link. 856 4.2. Receiving ND Messages from MN 858 The NetLMM specific processing of received ND Messages depends on 859 whether a packet is an NS part of the DAD procedure, or any other ND 860 message. Section 4.2.1 defines the processing rules for NSs sent as 861 part of the DAD procedure. Section 4.2.2 defines the processing 862 rules for all others ND messages. 864 4.2.1. Receiving DAD NSs 866 If the AR receives a DAD NS which is secure according to [RFC3971], 867 it MUST try to register the target address with the MAP. If the 868 registration fails because this address is used by a different MN, 869 the AR MUST defend the target address by sending a proxy NA as 870 described in Section 4.3.2. 872 4.2.2. Receiving All Others ND Messages 874 If the AR receives any other ND message than those enumerated above, 875 the message is secure according to [RFC3971], and the source address 876 of the packet is not the unspecified address, it MUST try to register 877 its source address with the MAP. 879 4.3. Sending ND Messages to MN 881 4.3.1. Sending NSs 883 An AR sends an NS to a MN in the following cases: 885 o The AR receives from the MN a SEND-protected ND message which does 886 not allow the AR to verify the MN CGA ownership. This can occur 887 if the MN includes a Nonce parameter which does not correspond to 888 the Nonce sent by the AR to the MN, or if the MN includes a 889 Timestamp parameter which fails because the MN and AR clocks are 890 desynchronized. 892 o The AR receives from the MN an IP packet which is not a ND or DHCP 893 Message before the MN registers the IP packet's source address. 895 o The AR is performing the periodic reachability test of a MN it has 896 precedently registered with the MAP. If the MN is unreachable, 897 the AR MUST deregister this MN with the MAP. 899 In all the cases described above, the AR MUST verify MN CGA ownership 900 by sending to the MN CGA an NS message including the MN CGA as a 901 target address and a fresh Nonce. 903 4.3.2. Sending Proxy NAs 905 An AR SHOULD send a proxy NA to a MN performing DAD for an IP address 906 which belongs to a MN which is known to be off-link by the AR in 907 order to defend that address, as specified in Section 5.4. of 908 [I-D.ietf-ipv6-2462bis]. 910 To allow SEND MNs to accept proxy NS sent by the AR, the AR should 911 follow the procedure described in Figure 12. 913 4.3.3. Sending RAs 915 All Prefix Information options included in RAs sent by an AR SHOULD 916 have the "on-link" flag (L) set to 0 (zero.) This ensures that all 917 packets sent by a MN are sent via the AR. 919 When the RAs contain no Prefix Information options, or when the MN 920 wishes to procure additional prefixes, the MN can use DHCP prefix 921 delegation mechanisms per [RFC3633]. 923 4.3.4. Sending Redirects 925 An AR SHOULD NOT send a redirect message ([I-D.ietf-ipv6-2461bis], 926 Section 8.2) unless it can determine that the sending node and better 927 first-hop node reside on the same link and will remain on the same 928 link. 930 4.4. Receiving All Other IPv6 Packets from MN 932 If the AR receives any other IPv6 packet than those enumerated above 933 from a MN, and the source IP address is not registered yet with the 934 AR, the AR MUST initiate a reachability test with the MN as specified 935 in Section 4.3.1 to verify the MN CGA ownership. 937 4.4.1. Authenticated Packets 939 If the AR receives any other IPv6 packet than those enumerated above, 940 and the MN origin of this packet is authenticated (by another 941 security mechanism such as 802.11i or IPsec) and tied by any means to 942 the public key used to generate the source CGA of that packet, then 943 the AR MAY update the MAP based on reception of such packets. 945 4.4.2. Unauthenticated Packets 947 Unauthenticated IPv6 packets MUST NOT trigger any action in the 948 NetLMM Domain. 950 4.4.3. Forwarding Packets 952 [RFC4291] states that: 954 ARs MUST NOT forward any packets with Link-Local source or 955 destination addresses to other links. 957 Link-Local multicast scope spans the same topological region as 958 the corresponding unicast scope. 960 This specification does not modify that behavior, i.e. an AR MUST NOT 961 forward packets sent by a MN from or to a link-local address (unicast 962 or multicast). 964 4.5. MN Identifier and IP addresses 966 All NLMP messages generated by an AR upon reception of triggers 967 described in this document SHOULD use the SEND public key in the MNID 968 field of NLMP messages. An alternative would be to use a truncated 969 (say 128 bits) secure hash of the public key to reduce message size 970 while keeping an equivalent security level. This public key MNID is 971 hence securely bound to the set of IP addresses used by the MN, 972 therefore preventing different redirection attacks. 974 In some deployments where MNs do not use ND and SEND (e.g. some 975 cellular systems [RFC3316]), ARs and MAPs in the NetLMM domain SHOULD 976 enforce the binding between an authenticated MN identity and the set 977 of IP addresses used by the MN. In other words the network keeps 978 track of IP addresses allocated to a specific MN identity. In the 979 case of DHCP address allocation, DHCP requests and replies should be 980 protected by a link-layer security context indexed by the 981 authenticated MN identity. 983 5. Multilink Subnet Considerations 985 Multilink subnet issues are analyzed in [I-D.thaler-intarea- 986 multilink-subnet-issues]. 988 When each MN assigns addresses from separate IP prefixes, (e.g., per 989 [I-D.thaler-autoconf-multisubnet-manets]) there are no multilink 990 subnet issues. 992 When multiple MNs assign addresses from a shared IP prefix, multilink 993 subnet issues can be avoided if ARs and MAPs act as neighbor 994 discovery proxies as described in Figure 12, and ARs do not advertize 995 subnet prefixes as "on-link" as described in Section 4.3.3. 997 6. IANA Considerations 999 There are no IANA considerations. 1001 7. Acknowledgments 1003 As usual in the IETF, this document is the result of a collaboration 1004 between many people. The authors would like to thanks (in 1005 alphabetical order) James Kempf, Alexandru Petrescu and Christian 1006 Vogt for discussion and/or comments that helped with first version of 1007 this document. 1009 Ian Chakeres contributed the reference network diagram. Portions of 1010 this work were supported by the Boeing IRAD program and Boeing 1011 colleagues. 1013 Julien Laganier is partly funded by Ambient Networks, a research 1014 project supported by the European Commission under its Sixth 1015 Framework Program. The views and conclusions contained herein are 1016 those of the authors and should not be interpreted as necessarily 1017 representing the official policies or endorsements, either expressed 1018 or implied, of the Ambient Networks project or the European 1019 Commission. 1021 8. References 1023 8.1. Normative references 1025 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1026 Requirement Levels", BCP 14, RFC 2119, March 1997. 1028 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1029 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 1030 October 1998. 1032 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 1033 October 1996. 1035 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 1036 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 1037 March 2000. 1039 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1040 Discovery for IP Version 6 (IPv6)", RFC 2461, 1041 December 1998. 1043 [I-D.ietf-ipv6-2461bis] 1044 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 1045 draft-ietf-ipv6-2461bis-07 (work in progress), May 2006. 1047 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1048 Autoconfiguration", RFC 2462, December 1998. 1050 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 1051 and M. Carney, "Dynamic Host Configuration Protocol for 1052 IPv6 (DHCPv6)", RFC 3315, July 2003. 1054 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 1055 Host Configuration Protocol (DHCP) version 6", RFC 3633, 1056 December 2003. 1058 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 1059 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 1061 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1062 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1064 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 1065 RFC 3972, March 2005. 1067 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1068 Architecture", RFC 4291, February 2006. 1070 [I-D.ietf-ipv6-privacy-addrs-v2] 1071 Narten, T., "Privacy Extensions for Stateless Address 1072 Autoconfiguration in IPv6", 1073 draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), 1074 December 2005. 1076 [I-D.ietf-dna-hosts] 1077 Narayanan, S., "Detecting Network Attachment in IPv6 - 1078 Best Current Practices for hosts.", 1079 draft-ietf-dna-hosts-03 (work in progress), May 2006. 1081 [I-D.ietf-dna-routers] 1082 Narayanan, S., "Detecting Network Attachment in IPv6 - 1083 Best Current Practices for Routers", 1084 draft-ietf-dna-routers-02 (work in progress), March 2006. 1086 [I-D.ietf-dna-cpl] 1087 Nordmark, E. and J. Choi, "DNA with unmodified routers: 1088 Prefix list based approach", draft-ietf-dna-cpl-02 (work 1089 in progress), January 2006. 1091 [I-D.pentland-dna-protocol] 1092 Narayanan, S., "Detecting Network Attachment in IPv6 1093 Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in 1094 progress), July 2005. 1096 [I-D.wood-netlmm-emp-base] 1097 Wood, J. and K. Nishida, "Edge Mobility Protocol (EMP)", 1098 draft-wood-netlmm-emp-base-00 (work in progress), 1099 October 2005. 1101 [I-D.ietf-ipv6-2462bis] 1102 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 1103 Address Autoconfiguration", draft-ietf-ipv6-2462bis-08 1104 (work in progress), May 2005. 1106 8.2. Informative references 1108 [RFC3316] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and J. 1109 Wiljakka, "Internet Protocol Version 6 (IPv6) for Some 1110 Second and Third Generation Cellular Hosts", RFC 3316, 1111 April 2003. 1113 [I-D.ietf-netlmm-nohost-ps] 1114 Kempf, J., "Problem Statement for Network-based Localized 1115 Mobility Management", draft-ietf-netlmm-nohost-ps-04 (work 1116 in progress), June 2006. 1118 [I-D.ietf-netlmm-nohost-req] 1119 Kempf, J., "Goals for Network-based Localized Mobility 1120 Management (NETLMM)", draft-ietf-netlmm-nohost-req-01 1121 (work in progress), April 2006. 1123 [I-D.ietf-netlmm-threats] 1124 Kempf, J. and C. Vogt, "Security Threats to Network-based 1125 Localized Mobility Management", 1126 draft-ietf-netlmm-threats-00 (work in progress), 1127 April 2006. 1129 [I-D.thaler-intarea-multilink-subnet-issues] 1130 Thaler, D., "Issues With Protocols Proposing Multilink 1131 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 1132 (work in progress), March 2006. 1134 [I-D.thaler-autoconf-multisubnet-manets] 1135 Thaler, D., "Multi-Subnet MANETs", 1136 draft-thaler-autoconf-multisubnet-manets-00 (work in 1137 progress), February 2006. 1139 Appendix A. Version history 1141 A.1. -00 to -01 1143 o added DHCP access method including DHCP prefix delegation. 1145 o added new network reference diagram. 1147 o added definitions for NetLMM domain and NLMP. 1149 o updated NA proxying method for colliding CGAs. 1151 o added text on sending IP multicast messages to a Layer-2 unicast 1152 address. 1154 o added new Section 4.5 text on MNID/IP address binding. 1156 o added new Section 5. on multilink subnet issues. 1158 o various editorial changes." 1160 Authors' Addresses 1162 Julien Laganier 1163 DoCoMo Communications Laboratories Europe GmbH 1164 Landsberger Strasse 312 1165 Munich 80687 1166 Germany 1168 Phone: +49 89 56824 231 1169 Email: julien.ietf@laposte.net 1170 URI: http://www.docomolab-euro.com/ 1172 Sathya Narayanan 1173 Panasonic Digital Networking Lab 1174 Two Research Way, 3rd Floor 1175 Princeton, NJ 08536 1176 USA 1178 Phone: +1 609 734 7599 1179 Email: sathya@research.panasonic.com 1181 Fred L. Templin 1182 Boeing Phantom Works 1183 P.O. Box 3707 MC 7L-49 1184 Seattle, WA 98124 1185 USA 1187 Email: fred.l.templin@boeing.com 1189 Intellectual Property Statement 1191 The IETF takes no position regarding the validity or scope of any 1192 Intellectual Property Rights or other rights that might be claimed to 1193 pertain to the implementation or use of the technology described in 1194 this document or the extent to which any license under such rights 1195 might or might not be available; nor does it represent that it has 1196 made any independent effort to identify any such rights. Information 1197 on the procedures with respect to rights in RFC documents can be 1198 found in BCP 78 and BCP 79. 1200 Copies of IPR disclosures made to the IETF Secretariat and any 1201 assurances of licenses to be made available, or the result of an 1202 attempt made to obtain a general license or permission for the use of 1203 such proprietary rights by implementers or users of this 1204 specification can be obtained from the IETF on-line IPR repository at 1205 http://www.ietf.org/ipr. 1207 The IETF invites any interested party to bring to its attention any 1208 copyrights, patents or patent applications, or other proprietary 1209 rights that may cover technology that may be required to implement 1210 this standard. Please address the information to the IETF at 1211 ietf-ipr@ietf.org. 1213 Disclaimer of Validity 1215 This document and the information contained herein are provided on an 1216 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1217 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1218 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1219 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1220 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1221 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1223 Copyright Statement 1225 Copyright (C) The Internet Society (2006). This document is subject 1226 to the rights, licenses and restrictions contained in BCP 78, and 1227 except as set forth therein, the authors retain all their rights. 1229 Acknowledgment 1231 Funding for the RFC Editor function is currently provided by the 1232 Internet Society.