idnits 2.17.1 draft-ietf-netlmm-mn-ar-if-00.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 20. -- Found old boilerplate from RFC 3978, Section 5.5 on line 954. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 931. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 938. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 944. ** 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. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. 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 == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Unauthenticated IPv6 packets MUST not trigger any action in the NetLMM Domain. [ XXX TBD. ] -- 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 (April 10, 2006) is 6584 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 814, but no explicit reference was found in the text == Unused Reference: 'RFC2003' is defined on line 818, but no explicit reference was found in the text == Unused Reference: 'RFC2784' is defined on line 821, but no explicit reference was found in the text == Unused Reference: 'I-D.kempf-netlmm-threats' is defined on line 895, 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-05 ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) -- 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' == Outdated reference: A later version (-05) exists of draft-ietf-ipv6-privacy-addrs-v2-04 == Outdated reference: A later version (-03) exists of draft-ietf-dna-hosts-02 -- Possible downref: Normative reference to a draft: ref. 'I-D.ietf-dna-hosts' == Outdated reference: A later version (-02) exists of draft-ietf-dna-routers-01 -- 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' Summary: 7 errors (**), 0 flaws (~~), 13 warnings (==), 14 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: October 12, 2006 S. Narayanan 5 Panasonic 6 April 10, 2006 8 Network-based Localized Mobility Management Interface between Mobile 9 Node and Access Router 10 draft-ietf-netlmm-mn-ar-if-00 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 This document may not be modified, and derivative works of it may not 19 be created, except to publish it as an RFC and to translate it into 20 languages other than English. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on October 12, 2006. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 44 Abstract 46 This document specify an IP layer interface between mobile nodes (MN) 47 and access routers (AR) of a network-based localized mobility 48 management (NetLMM) domain. Such an interface is subject to a 49 certain number of threats, amongst which are attacks on the mapping 50 between the MN Identifier and IPv6 address set. A binding 51 enforcement mechanism between those two is hence required to prevent 52 malicious nodes to carry on various attacks like service theft or 53 denial-of-service attacks. In the absence of link-layer specific 54 mechanisms enforcing this binding, it is required to implement such 55 mechanism at the IP layer MN-AR interface. Moreover, it is required 56 that no NetLMM specific software support is present on MNs. The IP 57 layer MN-AR interface described in this document fulfills these two 58 requirements by using the SEND public key as the MN identifier, while 59 being solely based on standard track IPv6 protocols (DNA and SEND) 60 implemented by non-NetLMM MNs. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 66 1.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 67 1.3. Operating Environment . . . . . . . . . . . . . . . . . . 6 68 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 69 2.1. MN powers on in a NetLMM domain . . . . . . . . . . . . . 9 70 2.2. First attachment of MN moving into a NetLMM domain . . . . 10 71 2.3. MN handovers in a NetLMM-domain . . . . . . . . . . . . . 11 72 2.4. MN configuring additional CGAs . . . . . . . . . . . . . . 13 73 2.5. MN configuring CGA that is in use by another MN in the 74 NETLMM domain . . . . . . . . . . . . . . . . . . . . . . 13 75 2.6. MN unconfigures CGAs, powers off, crash or leave the 76 domain . . . . . . . . . . . . . . . . . . . . . . . . . . 13 77 3. Mobile Node Specification . . . . . . . . . . . . . . . . . . 16 78 4. Access Router Specification . . . . . . . . . . . . . . . . . 18 79 4.1. Promiscuous and all-multicast modes . . . . . . . . . . . 18 80 4.2. Receiving Neighbor Discovery Messages from MN . . . . . . 18 81 4.2.1. Receiving DAD Neighbor Solicitations . . . . . . . . . 19 82 4.2.2. Receiving Solicited Neighbor Advertisements . . . . . 19 83 4.2.3. Receiving All Others Neighbor Discovery Messages . . . 19 84 4.3. Sending Neighbor Discovery Messages to MN . . . . . . . . 19 85 4.3.1. Sending Neighbor Solicitations . . . . . . . . . . . . 19 86 4.3.2. Sending Proxy Neighbor Advertisements . . . . . . . . 20 87 4.3.3. Sending Router Advertisements . . . . . . . . . . . . 20 88 4.3.4. Sending Redirects . . . . . . . . . . . . . . . . . . 20 89 4.4. Receiving All Others IPv6 Packets from MN . . . . . . . . 20 90 4.4.1. Authenticated Packets . . . . . . . . . . . . . . . . 20 91 4.4.2. Unauthenticated Packets . . . . . . . . . . . . . . . 21 92 4.5. Mobile Node Identifier used by AR . . . . . . . . . . . . 21 93 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 23 95 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 96 7.1. Normative references . . . . . . . . . . . . . . . . . . . 24 97 7.2. Informative references . . . . . . . . . . . . . . . . . . 25 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 99 Intellectual Property and Copyright Statements . . . . . . . . . . 27 101 1. Introduction 103 It is suggested in [I-D.kempf-netlmm-nohost-ps] that it would be 104 desirable to have a localized mobility management protocol in which 105 the host is not involved. The requirements for such a protocol have 106 been analyzed in [I-D.kempf-netlmm-nohost-req]. Accordingly, a 107 protocol for network-based localized mobility management (NetLMM) of 108 IPv6 nodes will be specified by the NetLMM working group; until this 109 occurs, this document assumes [I-D.wood-netlmm-emp-base] as a 110 strawman NetLMM protocol in use in a NetLMM domain. Further 111 revisions of this document will be adapted to the NetLMM protocol 112 proposal chosen by the working group. Because the NetLMM protocol is 113 network based, the mobile node is not required to implement new 114 mechanism in its IP stack, nor to change its IP address when it 115 attaches to a new access router. 117 Because the IPv6 mobile node will use a vanilla IPv6 stack, the 118 interface between a mobile node and its access router has to be 119 preserved. This means that standard IPv6 should work seamlessly with 120 the network-based localized mobility support. More specifically, we 121 require the proposed solution to be compatible with the mechanisms 122 specified in: 124 o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] 126 o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] 128 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 129 [I-D.ietf-ipv6-privacy-addrs-v2] 131 o Detecting Network Attachment in IPv6 - Best Current Practices for 132 Hosts [I-D.ietf-dna-hosts] 134 o Detecting Network Attachment in IPv6 - Best Current Practices for 135 Routers [I-D.ietf-dna-routers] 137 o Detecting Network Attachment with Unmodified Routers: A Prefix 138 List based approach [I-D.ietf-dna-cpl] 140 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 141 protocol] 143 o SEcure Neighbor Discovery [RFC3971] 145 o Cryptographically Generated Addresses [RFC3972] 147 This document specify an IP layer interface between mobile nodes (MN) 148 and access routers (AR) of a network-based localized mobility 149 management (NetLMM) domain. Such an interface is subject to a 150 certain number of threats, amongst which are attacks on the mapping 151 between the MN Identifier and IPv6 address set. A binding 152 enforcement mechanism between those two is hence required to prevent 153 malicious nodes to carry on various attacks like service theft or 154 denial-of-service attacks. In the absence of link-layer specific 155 mechanisms enforcing this binding, it is required to implement such 156 mechanism at the IP layer MN-AR interface. Moreover, it is required 157 that no NetLMM specific software support is present on MNs. The IP 158 layer MN-AR interface described in this document fulfills these two 159 requirements by by using the SEND public key as the MN identifier, 160 while being solely based on standard track IPv6 protocols (DNA and 161 SEND) implemented by non-NetLMM MNs. 163 1.1. Terminology 165 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 166 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 167 document are to be interpreted as described in [RFC2119]. 169 In addition, new terms are defined below: 171 Network-based Localized Mobility Management Domain (NETLMM domain) : 172 An administrative domain spanning geographically contiguous link 173 layer networks served by access routers. 175 Mobile Node (MN): The MN is an IPv6 node moving in the domain. 177 Access Router (AR): The AR is the Mobile Node's default router. 179 External interface : A network interface of an AR attached to the 180 link used by MN. 182 Mobility Anchor Point (MAP): A Mobility Anchor Point is a router 183 located in the network-based localized mobility domain handling 184 exchanged between that domain and the Internet. 186 1.2. Abbreviations 188 Throughout this document, figures make use of the following 189 abbreviations: 191 ND: Neighbor Discovery. 193 NDP: Neighbor Discovery Protocol. 195 SEND: SEcure Neighbor Discovery. 197 DNA: Detecting Network Attachment. 199 LNMP: NetLMM Protocol used in the backhaul of the NetLMM domain 200 (between ARs and MAP.) 202 CGA: Cryptographically Generated Address. 204 CGA_LL: The link-local unicast CGA generated by the MN with its 205 public key (It is assumed that the MN is using a single public key to 206 configure all of its link-local unicast and global unicast CGAs.) 208 CGA_1: One of the Global Unicast CGA generated by the MN with its 209 public key. 211 CGA_2: Another one of the Global Unicast CGA generated by the MN with 212 its public key (e.g. with a different subnet prefix.) 214 CGA_*: Any Unicast CGA generated by the MN with its public key (i.e. 215 link-local or global.) 217 MNID: Mobile node identifier set to the public key used by the MN for 218 generating its CGAs. 220 1.3. Operating Environment 222 The MN-AR NetLMM interface is used between a mobile node and an 223 access router of a NetLMM domain. In the absence of link-layer 224 specific mechanism, it allows the AR to detect the network attachment 225 of a MN and update routing at the MAP so that the MN stays reachable 226 when it roams across the NetLMM domain. 228 /-----------\ 229 / Internet \ 230 \ / 231 \-----+-----/ 232 | 233 +-------+ 234 | MAP | 235 +---+---+ 236 | 237 /------------+------------\ 238 / NetLMM \ 239 \ domain / 240 / \-------------------------/ \ 241 | | | 242 +--+--+ +--+--+ +--+--+ 243 | AR1 | | AR2 | | AR3 | 244 +-----+ +-----+ +-----+ 245 / \ / \ / \ 246 / \ / \ / \ 247 / \ / \ / \ MN-AR 248 - -/- - - -\- - - -/- - - -\- - -/- - - -\- - - - - - 249 / \ / \ / \ Interface 250 / +-----+ \ / \ 251 / | MN | -------> X \ 252 / +-----+ movement / \ \ 254 The deployment scenario is shown in the figure above: Several ARs are 255 attached to an IP routing domain connected to the outside Internet 256 via a MAP. The ARs, MAP, and in-between routing fabric constitute 257 the NetLMM domain. Each AR announce on its external interface a 258 common set of prefix(es) which are routed to the MAP from the outside 259 Internet. Packets incoming at the MAP and directed at the MN are 260 tunneled to the appropriate AR based on the information provided by 261 ARs. 263 In the absence of a link-layer specific MN-AR interface, it is 264 required to have a common interface defined at the IP layer. Because 265 no NetLMM specific software support is assumed to be present on MNs, 266 this interface has to rely only on standard tracks IPv6 protocols 267 such as Neighbor Discovery (ND), SEND (Secure ND) and Detecting 268 Network Attachment (DNA). Interactions of these three components 269 with NetLMM are represented below (note that hints received by DNA 270 from other layers are omitted for clarity): 272 MN|AR 273 Interface 274 | 276 | +------------+ +----------+ 277 | | | | 278 | | +--------+ | NLMP | +------+ | 279 | | NetLMM |<-------->|NetLMM| | 280 | | +--------+ | | +------+ | 281 | ^ ^ | | ^ | 282 +----------+ | | | | | | | | 283 | | | v | | | | | 284 | +------+ | | | +-----+ | | | | | 285 | | DNA | | NDP | | DNA | | | | | | 286 | | SEND |<------|------>|SEND | | | | | | 287 | | ND | | | | ND | | | | | | 288 | +------+ | | | +-----+ | | | | | 289 | ^ | | ^ | | | | | 290 | | | | | | | | | | | 291 | v | | v | | | v | 292 | +------+ | | | +----+ | | | +------+ | 293 | | | | | | |<-+ | | | | | 294 | | | | IPv6 | | | | IPv6 | | | | 295 | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | 296 | +------+ | | +----+ | | +------+ | 297 | | | | | | | 298 | MN | | AR | | MAP | 299 +----------+ | +------------+ +----------+ 301 | 303 2. Protocol Overview 305 The following subsections present the different situations in which 306 the MN-AR interface is used to trigger the NetLMM protocol. 308 2.1. MN powers on in a NetLMM domain 310 +-------------------------------------------------------------------+ 311 |Caption :In following figures it is assumed that the MN and AR | 312 | clocks are synchronized enough to allow verification of ND| 313 | messages via SEND timestamps. If that would not be the | 314 | case, in order to verify freshness of ND signaling sent | 315 | by the MN, the AR would be required to solicit the MN by | 316 | sending to it a NS with a fresh nonce, to which the MN | 317 | would reply with a NA containing the same fresh nonce. | 318 +-------------------------------------------------------------------+ 320 MN AR1 MAP 321 | | | 322 | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | 323 |----------------------->|---------------------->| bind(CGA_LL,MNID) 324 | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR1) 325 | |<----------------------| 326 | RS | | 327 |----------------------->| | 328 | RA | | 329 |<-----------------------| | 330 | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | 331 |----------------------->|---------------------->| bind(CGA_1,MNID) 332 | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR1) 333 | |<----------------------| 334 | | | 335 | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | 336 |----------------------->|---------------------->| bind(CGA_2,MNID) 337 | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR1) 338 | |<----------------------| 339 | | | 341 Figure 1: MN powers on and configures a Link-Local and two Global 342 Unicast CGAs 344 When a MN powers on for the first time, it will generate a link local 345 address based on its public key (CGA_LL) as per [RFC3972], and 346 perform DAD on the address as per [RFC2462]. The DAD-NS message 347 generated will contain the public key in the CGA option as defined by 348 SEND [RFC3971]. Upon reception of this NS message, the access router 349 (AR1) SHOULD generate a UPDATE to the MAP with the public key as the 350 MNID along with CGA_LL. The MAP SHOULD bind the CGA_LL to the MNID 351 and establish a route binding for the CGA_LL to the access router 352 AR1. The MAP acknowledges the receipt of the UPDATE message. 354 While waiting for the completion of DAD, the MN may generate RS 355 message as per [RFC2461] with the unspecified address as the source 356 address. Such an RS message will not contain a CGA option. The 357 access router will respond with a multicast RA as per [RFC2461]. 358 With the prefix information received in the RA message, the MN will 359 cryptographically generate one or more global addresses (CGA_*). For 360 each of these addresses, the MN will perform DAD as the IID is likely 361 to be different for each of these cryptographically generated 362 addresses. For every DAD-NS received from the MN,the access router 363 AR1 will generate a UPDATE message to the MAP establishing binding in 364 the MAP. 366 2.2. First attachment of MN moving into a NetLMM domain 368 MN AR2 MAP 369 | | | 370 | RS | | 371 |---------------------->| | 372 | RA | | 373 |<----------------------| | 374 | NS(DAD:CGA_LL) | UPDATE(MNID,CGA_LL) | 375 |---------------------->|---------------------->| bind(CGA_LL,MNID) 376 | |REPLY[OK](MNID,CGA_LL) | route(CGA_LL->AR2) 377 | |<----------------------| 378 | NS(DAD:CGA_1) | UPDATE(MNID,CGA_1) | 379 |---------------------->|---------------------->| bind(CGA_1,MNID) 380 | | REPLY[OK](MNID,CGA_1) | route(CGA_1->AR2) 381 | |<----------------------| 382 | | | 383 | NS(DAD:CGA_2) | UPDATE(MNID,CGA_2) | 384 |---------------------->|---------------------->| bind(CGA_2,MNID) 385 | | REPLY[OK](MNID,CGA_2) | route(CGA_2->AR2) 386 | |<----------------------| 387 | | | 389 Figure 2: MN moves into a NetLMM domain and configures a Link-Local 390 and two Global Unicast CGAs 392 When a MN moves into a NETLMM domain for the first time, it will 393 initiate link change detection as specified in [I-D.pentland-dna- 394 protocol] by multicast transmission of a RS message. When the MN 395 receives a RA message in response, it will figure out that it has 396 changed link as defined by the DNA specification [I-D.pentland-dna- 397 protocol]. Once the MN realizes it has changed link, it will discard 398 its current IP addresses and will execute DAD for its link-local 399 address and new global addresses based on the prefix information in 400 the received RA messages. 402 The behavior of the access router AR2 in response to the DAD messages 403 is similar to that of AR1 specific in Section 2.1. 405 2.3. MN handovers in a NetLMM-domain 407 MN AR3 MAP 408 | | | 409 |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | 410 |----------------------->|---------------------->| route(CGA_LL->AR3) 411 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR3) 412 | RA(AR->CGA_LL) | CGA_1,CGA_2) | route(CGA_2->AR3) 413 |<-----------------------|<----------------------| 414 | | | 416 Figure 3: MN getting handover hint and receives a unicast RA 418 When the MN moves within the NETLMM domain, it will send a RS message 419 with the source address as its link-local address as specified by 420 [I-D.pentland-dna-protocol]. The access router again can use the 421 public key in CGA option to infer the MNID and send updates to the 422 MAP. If the access router chooses to respond with a unicast RA, all 423 required steps are done. 425 MN AR4 MAP 426 | | | 427 |RS(CGA_LL->All_routers) | UPDATE(MNID,CGA_*) | 428 |----------------------->|---------------------->| route(CGA_LL->AR4) 429 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR4) 430 | RA(AR->All_nodes) | CGA_1,CGA_2) | route(CGA_2->AR4) 431 |<-----------------------|<----------------------| 432 | NS | | 433 |----------------------->| | 434 | NA | | 435 |<-----------------------| | 436 | | | 438 Figure 4: MN getting handover hint and receives a multicast RA 439 In a similar scenario, if the access router chooses to respond with a 440 multicast RA, the MN will send a NS to learn about the access router 441 and confirm reachability. 443 MN AR5 MAP 444 | | | 445 | NS(AR->CGA_*) | | 446 |<-----------------------| | 447 | NA(CGA_*->AR) | UPDATE(MNID,CGA_*) | 448 |----------------------->|---------------------->| route(CGA_LL->AR5) 449 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR5) 450 | | CGA_1,CGA_2) | route(CGA_2->AR5) 451 | |<----------------------| 452 | | | 454 Figure 5: AR getting handover hint of MN whose IP address is known 456 Instead of the MN receiving the hint, in scenarios were the access 457 router receives the hint with the IP address of the handing over MN, 458 the AR can send a NS to that IP address. The NA message received in 459 response will contain the public key of the MN with which the AR can 460 send update message to the MAP. 462 MN AR6 MAP 463 | | | 464 | RA(AR->All_nodes) | | 465 |<-----------------------| | 466 | NS(CGA_*->AR) | UPDATE(MNID,CGA_*) | 467 |----------------------->|---------------------->| route(CGA_LL->AR6) 468 | |REPLY[OK](MNID,CGA_LL, | route(CGA_1->AR6) 469 | NA(AR->CGA_*) | CGA_1,CGA_2) | route(CGA_2->AR6) 470 |<-----------------------|<----------------------| 471 | | | 473 Figure 6: AR getting handover hint of MN whose IP address is unknown 475 If the access router does not receive the IP address information of 476 the handing over MN along with the hint, the AR can schedule a 477 multicast RA. The MN will try to fill its neighbor cache information 478 with the new router and confirm its reachability by initiating a NS 479 message to the AR. The AR can then send update message to the MAP 480 based on the public key in the NS message. 482 2.4. MN configuring additional CGAs 484 If the MN choose to configure new global addresses at any point in 485 time, it will contact DAD on the new address by sending a DAD-NS 486 message. The access router can learn the new address from the NS 487 message and map to the corresponding public key in the CGA option. 489 MN AR MAP 490 | | | 491 | NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) | 492 |----------------------->|---------------------->| bind(CGA_3,MNID) 493 | | REPLY[OK](MNID,CGA_3) | route(CGA_3->AR) 494 | |<----------------------| 495 | | | 497 Figure 7: MN configuring later on additional CGAs 499 2.5. MN configuring CGA that is in use by another MN in the NETLMM 500 domain 502 The access router learns about new global addresses configured by the 503 MN from the NS-DAD message sent by MN. When the AR sends an UPDATE 504 to the MAP based on this DAD-NS, it waits for a positive 505 acknowledgment from the MAP. If the MAP has an entry for the save 506 CGA with a different MNID, it will respond back with a message 507 indicating collision and the AR must proxy for the other MN by 508 responding to the DAD-NS. 510 MN AR MAP 511 | | | 512 | NS(DAD:CGA_3) | UPDATE(MNID,CGA_3) | 513 |----------------------->|---------------------->| collision(MNID) 514 | NA(CGA_3->MN) |REPLY[COLLISION](CGA_3)| 515 |<-----------------------|<----------------------| 516 | | | 518 Figure 8: MN configuring later on a colliding CGA 520 2.6. MN unconfigures CGAs, powers off, crash or leave the domain 522 It is recommended that the access router do periodic reachability 523 testing with MN, Neighbor Unreachability Detection (NUD), to learn 524 about addresses being unconfigured or the MN being powered off or 525 crashing. The trigger for this test could be neighbor cache entry 526 timeout or a MLDv2 [RFC3810] unsubscribe for the solicited-node 527 multicast address matching the MN's CGA. [XXX figure TBD.] 529 In the Figure 9, the MN stops using the address CGA_1 and when the 530 access router tries NUD for each of these addresses, it doesn't 531 receive a response for CGA_1, resulting in a UPDATE message to the 532 MAP to remove the mapping between MNID and CGA_1. 534 MN AR MAP 535 | | | 536 | NS(AR->CGA_LL) | | 537 |<-----------------------| | 538 | NA(CGA_LL->AR) | | 539 |----------------------->| | 540 | NS(AR->CGA_1) | | 541 | X <------------------| | 542 | NS(AR->CGA_2) | | 543 |<-----------------------| | 544 | NA(CGA_2->AR) | | 545 |----------------------->| | 546 | NS(AR->CGA_3) | | 547 |<-----------------------| | 548 | NA(CGA_3->AR) | | 549 |----------------------->| | 550 | |UPDATE[DEL](MNID,CGA_1)| 551 | |---------------------->| del_route(CGA_1) 552 | | REPLY[OK](MNID) | 553 | |<----------------------| 554 | | | 556 Figure 9: MN unconfigures a CGA 558 MN AR MAP 559 | | | 560 | NS(AR->CGA_LL) | | 561 | X <------------------| | 562 | NS(AR->CGA_1) | | 563 | X <------------------| | 564 | NS(AR->CGA_2) | | 565 | X <------------------| | 566 | NS(AR->CGA_3) | | 567 | X <------------------| | 568 | | UPDATE[DEL](MNID) | 569 | |---------------------->| del_route(CGA_LL) 570 | | REPLY[OK](MNID) | del_route(CGA_1) 571 | |<----------------------| del_route(CGA_2) 572 | | | del_route(CGA_3) 573 | | | del_bind(MNID) 574 Figure 10: MN crashes, powers off or leaves the domain 576 As shown in Figure 10, if the MN crashes, powers off or leaves the 577 domain, the NUD will fail for all the associated addresses. In this 578 case, the access router can remove the entry for the mobile node from 579 the MAP by initiating a UPDATE message. 581 3. Mobile Node Specification 583 There is no few NetLMM specific requirements place on a Mobile Node 584 in a NetLMM domain. However, for the smooth operation of the NetLMM 585 MN-AR interface, the MN MUST behave as specified in the following 586 documents: 588 o Neighbor Discovery for IP version 6 [RFC2461] (MUST) and 589 [I-D.ietf-ipv6-2461bis] (SHOULD) 591 o IPv6 Stateless Address Autoconfiguration [RFC2462] (MUST) and 592 [I-D.ietf-ipv6-2462bis] (SHOULD) 594 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 595 [I-D.ietf-ipv6-privacy-addrs-v2] 597 o Detecting Network Attachment in IPv6 - Best Current Practices for 598 Hosts [I-D.ietf-dna-hosts] 600 o Detecting Network Attachment in IPv6 - Best Current Practices for 601 Routers [I-D.ietf-dna-routers] 603 o Detecting Network Attachment with Unmodified Routers: A Prefix 604 List based approach [I-D.ietf-dna-cpl] 606 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 607 protocol] 609 o SEcure Neighbor Discovery [RFC3971] 611 o Cryptographically Generated Addresses [RFC3972] 613 and MUST use a single public key to generate all of their CGAs. This 614 requirement is necessary to make it possible for the AR and MAP to 615 bind together different addresses of the MN. That way, when a MN 616 attaches to a new AR, the MAP will correctly updating routing for all 617 MN CGAs even if the MN is currently using only one of those (e.g. its 618 link-local CGA to send a router solicitation.) 620 With respect to the MUST support [RFC2461] and [RFC2462], and SHOULD 621 support [I-D.ietf-ipv6-2461bis] and [I-D.ietf-ipv6-2462bis], the 622 reason is that the SEND requirements avoid complication with the "DAD 623 once per IID" optimization of [RFC2462]. Although it might have been 624 problematic for the AR to detect the configuration of a global 625 address for which the MN does not perform DAD because the IID of the 626 global address is the same than the one of a DADed link-local 627 address, the fact that SEND is used causes IIDs from CGAs with 628 different subnet prefixes to be different because the subnet prefixes 629 is used as an input parameter to the CGA generation algorithm. 630 Therefore, even per [RFC2461] and [RFC2462] the MN cannot do any 631 optimization and MUST perform DAD for all of its configured CGAs, 632 which allows the AR to correctly detect any address configured on the 633 MN. 635 4. Access Router Specification 637 A NetLMM AR MUST behave as specified in the following documents: 639 o Neighbor Discovery for IP version 6 [I-D.ietf-ipv6-2461bis] 641 o IPv6 Stateless Address Autoconfiguration [I-D.ietf-ipv6-2462bis] 643 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 644 [I-D.ietf-ipv6-privacy-addrs-v2] 646 o Detecting Network Attachment in IPv6 - Best Current Practices for 647 Hosts [I-D.ietf-dna-hosts] 649 o Detecting Network Attachment in IPv6 - Best Current Practices for 650 Routers [I-D.ietf-dna-routers] 652 o Detecting Network Attachment with Unmodified Routers: A Prefix 653 List based approach [I-D.ietf-dna-cpl] 655 o Detecting Network Attachment in IPv6 Networks [I-D.pentland-dna- 656 protocol] 658 o SEcure Neighbor Discovery [RFC3971] 660 o Cryptographically Generated Addresses [RFC3972] 662 In addition, the AR MUST conforms to the supplementary NetLMM 663 specific requirements which follows in this section. 665 4.1. Promiscuous and all-multicast modes 667 The AR SHOULD put its external interface (the one exposed to MNs) in 668 snooping/promiscuous mode so that it can receive most of the packets 669 exchanged on the link it is serving. If a layer 2 switch is present 670 between the AR and MNs, the port to which the AR is connected SHOULD 671 be put in snooping/promiscuous mode. At the minimum, the AR MUST put 672 its interface into a "receive all-multicast traffic" mode, and 673 registers with MLDv2 [RFC3810] to all link-local solicited node 674 multicast addresses to which a MN registers to with MLDv2. This 675 insure that the AR can receive neighbor solicitations so that it can 676 proxy solicited neighbor advertisements when the target MN is off- 677 link. 679 4.2. Receiving Neighbor Discovery Messages from MN 681 The NetLMM specific processing of received Neighbor Discovery 682 Messages depends on whether a packet is a neighbor solicitation part 683 of the DAD procedure, a solicited neighbor advertisement, or any 684 other neighbor discovery message. Section 4.2.1 defines the 685 processing rules for neighbor solicitations sent as part of the DAD 686 procedure. Section 4.2.2 defines the processing rules for solicited 687 neighbor advertisements. Section 4.2.3 defines the processing rules 688 for all others ND messages. 690 4.2.1. Receiving DAD Neighbor Solicitations 692 If the AR receives a DAD neighbor solicitation, and the solicitation 693 is secure according to [RFC3971], it MUST tries to register the 694 target address with the MAP. If the registration fails because this 695 address is used by a different MN, the AR MUST defend the target 696 address by sending a proxy neighbor advertisement as described in 697 Section 4.3.2. 699 4.2.2. Receiving Solicited Neighbor Advertisements 701 If the AR receives a Solicited Neighbor Advertisement for a target 702 address which does not belong to it, and the advertisement contains 703 both a valid CGA option as specified in Section 5.1.2. of [RFC3971], 704 a valid RSA Signature option as specified in Section 5.2.2. of 705 [RFC3971], and a valid Timestamp option as specified in Section 706 5.3.4.2. of [RFC3971], then it MUST register the target address with 707 the MAP. 709 4.2.3. Receiving All Others Neighbor Discovery Messages 711 If the AR receives any other neighbor discovery message than those 712 enumerated above, the solicitation is secure according to [RFC3971], 713 and the source address of the packet is not the unspecified IP 714 address, it MUST tries to register its source address with the MAP. [ 715 XXX do we need to defend the address if registration fails? That 716 should not happen except in case of public key collisions... ] 718 4.3. Sending Neighbor Discovery Messages to MN 720 4.3.1. Sending Neighbor Solicitations 722 o The AR receives from the MN a SEND-protected Neighbor Discovery 723 message which does not allows the AR to verify the MN CGA 724 ownership. This can occurs if the MN includes a Nonce parameter 725 which is does not correspond to the Nonce sent by the AR to the 726 MN, or if the MN includes a Timestamp parameters which fail 727 because MN and AR clocks are desynchronized. 729 o The AR receives from the MN sends an IP packet which is not a 730 Neighbor Discovery Message before it sends a SEND-protected 731 Neighbor Discovery message which allows the AR to verify MN CGA 732 ownership. 734 o The AR is performing the periodic reachability test of a MN it has 735 precedently registered with the MAP. If the MN is unreachable, 736 the AR MUST deregister this MN with the MAP. 738 4.3.2. Sending Proxy Neighbor Advertisements 740 An AR SHOULD send a proxy neighbor advertisement to a MN performing 741 DAD for an IP address which belongs to a MN which is known to be off- 742 link by the AR in order to defend that address, as specified in 743 Section 5.4. of [I-D.ietf-ipv6-2462bis]. 745 An AR SHOULD send a proxy neighbor advertisement to a MN attempting 746 to communicate directly with a MN (because it think its correspondent 747 is on-link) which is known to be off-link by the AR. The "override" 748 flag (O) should be set to 1 (one) so that an existing neighbor cache 749 entry is replaced, as specified in Section 4.4. of [I-D.ietf-ipv6- 750 2461bis]. 752 4.3.3. Sending Router Advertisements 754 All Prefix Information options included in router advertisements sent 755 by an AR SHOULD have the "on-link" flag (L) set to 0 (zero.) This 756 ensure that all packets sent by a MN are sent via the router. This 757 is necessary to insure that a MN trying to communicate with another 758 MN in the NetLMM domain but attached to a different AR is delivered 759 to the AR. 761 4.3.4. Sending Redirects 763 An AR SHOULD send a redirect to a MN attempting to communicate with a 764 MN which is known to be on-link by the AR, as specified in Section 765 4.5. of [I-D.ietf-ipv6-2461bis]. 767 4.4. Receiving All Others IPv6 Packets from MN 769 If the AR receives any other IPv6 packet than those enumerated above 770 from a MN, and the source IP address is not registered yet with the 771 AR, the AR MUST initiate a reachability test with the MN as specified 772 in Section 4.3.1 to verify the MN CGA ownership. 774 4.4.1. Authenticated Packets 776 If the AR receives any other IPv6 packet than those enumerated above, 777 and the MN origin of this packet is authenticated (by another 778 security mechanism such as 802.11i or IPsec) and tied by any means to 779 the public key used to generate the source CGA of that packet, then 780 the AR MAY update the MAP based on reception of such packets. [ XXX 781 TBD. ] 783 4.4.2. Unauthenticated Packets 785 Unauthenticated IPv6 packets MUST not trigger any action in the 786 NetLMM Domain. [ XXX TBD. ] 788 4.5. Mobile Node Identifier used by AR 790 All NetLMM messages generated by an AR upon reception of triggers 791 described in this document SHOULD use the SEND public key in the MNID 792 field of NetLMM messages. An alternative would be to use a truncated 793 (say 128 bits) secure hash of the public key to reduce message size 794 while keeping an equivalent security level. 796 5. IANA Considerations 798 There is no IANA considerations. 800 6. Acknowledgments 802 As usual in the IETF, this document is the result of a collaboration 803 between many people. The authors would like to thanks James Kempf 804 and Christian Vogt for discussion and/or comments that helped with 805 first version of this document. 807 7. References 809 7.1. Normative references 811 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", BCP 14, RFC 2119, March 1997. 814 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 815 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 816 October 1998. 818 [RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, 819 October 1996. 821 [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. 822 Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, 823 March 2000. 825 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 826 Discovery for IP Version 6 (IPv6)", RFC 2461, 827 December 1998. 829 [I-D.ietf-ipv6-2461bis] 830 Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", 831 draft-ietf-ipv6-2461bis-05 (work in progress), 832 October 2005. 834 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 835 Autoconfiguration", RFC 2462, December 1998. 837 [I-D.ietf-ipv6-2462bis] 838 Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 839 Address Autoconfiguration", draft-ietf-ipv6-2462bis-08 840 (work in progress), May 2005. 842 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 843 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 845 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 846 Neighbor Discovery (SEND)", RFC 3971, March 2005. 848 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 849 RFC 3972, March 2005. 851 [I-D.ietf-ipv6-privacy-addrs-v2] 852 Narten, T., "Privacy Extensions for Stateless Address 853 Autoconfiguration in IPv6", 854 draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress), 855 December 2005. 857 [I-D.ietf-dna-hosts] 858 Narayanan, S., "Detecting Network Attachment in IPv6 - 859 Best Current Practices for hosts.", 860 draft-ietf-dna-hosts-02 (work in progress), October 2005. 862 [I-D.ietf-dna-routers] 863 Narayanan, S., "Detecting Network Attachment in IPv6 - 864 Best Current Practices for Routers", 865 draft-ietf-dna-routers-01 (work in progress), 866 October 2005. 868 [I-D.ietf-dna-cpl] 869 Nordmark, E. and J. Choi, "DNA with unmodified routers: 870 Prefix list based approach", draft-ietf-dna-cpl-02 (work 871 in progress), January 2006. 873 [I-D.pentland-dna-protocol] 874 Narayanan, S., "Detecting Network Attachment in IPv6 875 Networks (DNAv6)", draft-pentland-dna-protocol-01 (work in 876 progress), July 2005. 878 [I-D.wood-netlmm-emp-base] 879 Wood, J. and K. Nishida, "Edge Mobility Protocol (EMP)", 880 draft-wood-netlmm-emp-base-00 (work in progress), 881 October 2005. 883 7.2. Informative references 885 [I-D.kempf-netlmm-nohost-ps] 886 Kempf, J., "Problem Statement for IP Local Mobility", 887 draft-kempf-netlmm-nohost-ps-01 (work in progress), 888 January 2006. 890 [I-D.kempf-netlmm-nohost-req] 891 Kempf, J., "Requirements and Gap Analysis for IP Local 892 Mobility", draft-kempf-netlmm-nohost-req-00 (work in 893 progress), July 2005. 895 [I-D.kempf-netlmm-threats] 896 Kempf, J. and C. Vogt, "Security Threats to Network-based 897 Localized Mobility Management", 898 draft-kempf-netlmm-threats-00 (work in progress), 899 February 2006. 901 Authors' Addresses 903 Julien Laganier 904 DoCoMo Communications Laboratories Europe GmbH 905 Landsberger Strasse 312 906 Munich 80687 907 Germany 909 Phone: +49 89 56824 231 910 Email: julien.ietf@laposte.net 911 URI: http://www.docomolab-euro.com/ 913 Sathya Narayanan 914 Panasonic Digital Networking Lab 915 Two Research Way, 3rd Floor 916 Princeton, NJ 08536 917 USA 919 Phone: +1 609 734 7599 920 Email: sathya@research.panasonic.com 922 Intellectual Property Statement 924 The IETF takes no position regarding the validity or scope of any 925 Intellectual Property Rights or other rights that might be claimed to 926 pertain to the implementation or use of the technology described in 927 this document or the extent to which any license under such rights 928 might or might not be available; nor does it represent that it has 929 made any independent effort to identify any such rights. Information 930 on the procedures with respect to rights in RFC documents can be 931 found in BCP 78 and BCP 79. 933 Copies of IPR disclosures made to the IETF Secretariat and any 934 assurances of licenses to be made available, or the result of an 935 attempt made to obtain a general license or permission for the use of 936 such proprietary rights by implementers or users of this 937 specification can be obtained from the IETF on-line IPR repository at 938 http://www.ietf.org/ipr. 940 The IETF invites any interested party to bring to its attention any 941 copyrights, patents or patent applications, or other proprietary 942 rights that may cover technology that may be required to implement 943 this standard. Please address the information to the IETF at 944 ietf-ipr@ietf.org. 946 Disclaimer of Validity 948 This document and the information contained herein are provided on an 949 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 950 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 951 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 952 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 953 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 954 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 956 Copyright Statement 958 Copyright (C) The Internet Society (2006). This document is subject 959 to the rights, licenses and restrictions contained in BCP 78, and 960 except as set forth therein, the authors retain all their rights. 962 Acknowledgment 964 Funding for the RFC Editor function is currently provided by the 965 Internet Society.