idnits 2.17.1 draft-ietf-netlmm-mn-ar-if-02.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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 774. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 785. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 798. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust 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 (May 22, 2007) is 6182 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3041 (Obsoleted by RFC 4941) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-05 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-00 Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 7 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 Intended status: Informational S. Narayanan 5 Expires: November 23, 2007 Panasonic 6 May 22, 2007 8 Network-based Localized Mobility Management Interface between Mobile 9 Node and Mobility Access Gateway 10 draft-ietf-netlmm-mn-ar-if-02 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. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on November 23, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes an interface between mobile nodes (MN) and 44 mobility access gateway (MAG) of a network-based localized mobility 45 management (NETLMM) domain. The interface has two functions which 46 are invocated when a MN attaches and detaches from a MAG. The 47 attachment function let the MAG authenticate the MN identifier, does 48 address(es) and default router configuration for the MN, and inform 49 the MAG about the multicast listener state of the MN. During a 50 successful execution of the detachment function, the NETLMM protocol 51 is triggered between the MAG and the localized mobility anchor (LMA). 52 The detachment function let the MAG detect that the MN has left so 53 that it can deregister the MN at the LMA using the NETLMM protocol. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Operating Environment . . . . . . . . . . . . . . . . . . . . 7 60 4. Interactions of NETLMM Architecture with Subnet and Link 61 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 62 4.1. NETLMM Subnet Model . . . . . . . . . . . . . . . . . . . 10 63 4.2. NETLMM Link Model . . . . . . . . . . . . . . . . . . . . 11 64 5. Address Collision Considerations . . . . . . . . . . . . . . . 12 65 6. MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13 66 6.1. MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13 67 6.2. MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15 68 6.3. MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 15 69 6.4. MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 15 70 7. MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 73 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 74 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 75 11.1. Normative references . . . . . . . . . . . . . . . . . . . 21 76 11.2. Informative references . . . . . . . . . . . . . . . . . . 22 77 Appendix A. Version history . . . . . . . . . . . . . . . . . . . 23 78 A.1. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23 79 A.2. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 81 Intellectual Property and Copyright Statements . . . . . . . . . . 25 83 1. Introduction 85 It is suggested in [RFC4830] that it would be desirable to have a 86 localized mobility management protocol in which the host is not 87 involved. The requirements for such a protocol have been analyzed in 88 [RFC4831]. Accordingly, a protocol for network-based localized 89 mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM 90 working group [I-D.ietf-netlmm-proxymip6]. Because the NETLMM 91 protocol is network based, the mobile node (MN) is not required to 92 implement new mechanism in its IP stack, nor to change its IP address 93 when it attaches to a new mobility access gateway (MAG). 95 Because the IPv6 MN will use a vanilla IPv6 stack, the interface 96 between a MN and its MAG has to be preserved. This means that 97 standard IPv6 should work seamlessly with the network-based localized 98 mobility support. More specifically, we require the proposed 99 solution to be compatible with the mechanisms specified in: 101 o Neighbor Discovery for IP version 6 [RFC2461] 103 o IPv6 Stateless Address Autoconfiguration [RFC2462] 105 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 107 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 108 [RFC3041] 110 o Detecting Network Attachment in IPv6 Networks (DNAv6) 111 [I-D.ietf-dna-protocol] 113 o SEcure Neighbor Discovery [RFC3971] 115 o Cryptographically Generated Addresses [RFC3972] 117 This document describes an interface between mobile nodes (MN) and 118 mobility access gateway (MAG) of a network-based localized mobility 119 management (NETLMM) domain. The interface has two functions which 120 are invocated when a MN attaches and detaches from a MAG. The 121 attachment function let the MAG authenticate the MN identifier, does 122 address(es) and default router configuration for the MN, and inform 123 the MAG about the multicast listener state of the MN. During a 124 successful execution of the detachment function, the NETLMM protocol 125 is triggered between the MAG and the localized mobility anchor (LMA). 126 The detachment function let the MAG detect that the MN has left so 127 that it can deregister the MN at the LMA using the NETLMM protocol. 129 In the absence of link-layer specific mechanisms implementing these 130 functions, this document describe which IP protocols should be used 131 to provide the necessary interface between the MN and the MAG. 133 2. Terminology 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 The following terms are defined within the scope of this document: 141 Mobile Node (MN) 142 an IPv6 node moving in the NETLMM domain. 144 Mobility Access Gateway (MAG) 145 a default router that connects the MN to the NETLMM domain. 147 Localized Mobility Anchor (LMA) 148 a router located in the NETLMM domain that handles packet 149 exchanges with nodes in the domain. 151 Network-based Localized Mobility Management Domain (NETLMM domain) 152 an administrative domain spanning links served by a set of LMAs 153 (and their associated MAGs and MNs) that provision addresses from 154 the same IP subnet prefix(es). 156 Network-based Localized Mobility Management Protocol (NLMP) 157 The NETLMM Protocol used in the backhaul of the NETLMM domain 158 between MAGs and LMA. 160 The following abbreviations are used throughout this document: 162 NETLMM: Network-based Localized Mobility Management 164 ND: Neighbor Discovery. 166 NS: Neighbor Solicitation. 168 NA: Neighbor Advertizement. 170 RS: Router Solicitation. 172 RA: Router Advertisement. 174 NDP: Neighbor Discovery Protocol. 176 SLAAC: StateLess Address AutoConfiguration 178 DHCP: Dynamic Host Configuration Protocol 180 SEND: SEcure Neighbor Discovery. 182 DNA: Detecting Network Attachment. 184 CGA: Cryptographically Generated Address. 186 MNID: An authenticated MN identifier (e.g. NAI, a SEND public key 187 used by the MN for generating its CGAs,an IMSI or TMSI, etc.). 189 3. Operating Environment 191 The MN-MAG NETLMM interface is used between a MN and an MAG of a 192 NETLMM domain. It allows the MAG and/or MN to detect network 193 attachment and detachment, causing the MAG to use the NETLMM protocol 194 to update routing at the LMA so that the MN stays reachable when it 195 roams across the NETLMM domain. 197 /---------------------------\ 198 / Internet \ 199 \ / 200 \-------+---------+---------/ 201 | | 202 /--------+---------+--------\ ---- 203 / \ ^ 204 / +-----+ \ | 205 | | LMA |-+ | N 206 | +-----+ |-+ | E 207 | +-----+ | | T 208 | +-----+ | L 209 | Backhaul Network | M 210 | +------+ +------+ | M 211 |- - | MAG1 | ..... | MAG2 | - -| 212 | +------+ +------+ | d 213 | / \ Access / \ | o 214 | / \ Network / \ | m 215 | / \ / \ | a 216 | +----+ | i 217 | | MN | -------> | n 218 \ +----+ MAG change / | 219 \ / v 220 \---------------------------/ ---- 222 Figure 1: Reference Network Diagram 224 The deployment scenario is shown in Figure 1 above: Several MAGs are 225 attached to an IP routing domain connected to the outside Internet 226 via a LMA. The MNs, MAGs, LMAs, and in-between routing fabric 227 constitute the NETLMM domain. Packets arriving at the LMA and 228 destined to a MN are tunneled to the appropriate MAG. 230 In the absence of a link-layer specific mechanisms to implement the 231 MN-MAG interface, it is required to have a common interface defined 232 at the IP layer. Because no NETLMM specific software support is 233 assumed to be present on MNs, this interface has to rely only on 234 standard tracks IPv6 protocols such as ND, DHCP, SEND, and DNA. 235 Interactions of these components with NETLMM are represented in 236 Figure 2 below (note that hints received by DNA from other layers are 237 omitted for clarity): 239 MN|MAG 240 Interface 241 | 243 | +------------+ +----------+ 244 | | | | 245 | | +--------+ | NLMP | +------+ | 246 | | NETLMM |<-------->|NETLMM| | 247 | | +--------+ | | +------+ | 248 | ^ ^ | | ^ | 249 +----------+ | | | | | | | | 250 | | | v | | | | | 251 | +------+ | | | +-----+ | | | | | 252 | | DNA | | NDP/DHCP | | DNA | | | | | | 253 | | SEND |<------|------>|SEND | | | | | | 254 | | ND | | | | ND | | | | | | 255 | | DHCP | | | | |DHCP | | | | | | 256 | +------+ | | +-----+ | | | | | 257 | ^ | | | ^ | | | | | 258 | | | | | | | | | | 259 | v | | | v | | | v | 260 | +------+ | | +----+ | | | +------+ | 261 | | | | | | | |<-+ | | | | | 262 | | | | IPv6 | | | | IPv6 | | | | 263 | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | 264 | +------+ | | +----+ | | +------+ | 265 | | | | | | | 266 | MN | | MAG | | LMA | 267 +----------+ | +------------+ +----------+ 269 | 271 Figure 2: NETLMM Component Interactions 273 MN|MAG 274 Interface 275 MN | MAG LMA 276 | | | | 277 | / | \ | / \ | 278 | /| | |\ | /| |\ | 279 | / +---------------------+ \ | / +----------+ \ | 280 |/ MN_ATTACH \|/ NETLMM \| 281 |\ function /|\ protocol /| 282 | \ +---------------------+ / | \ +----------+ / | 283 | \| | |/ | \| |/ | 284 | \ | / | \ / | 285 | | | | 286 | / | \ | / \ | 287 | /| | |\ | /| |\ | 288 | / +---------------------+ \ | / +----------+ \ | 289 |/ data packet \|/ data packet \| 290 |\ traffic /|\ traffic /| 291 | \ +---------------------+ / | \ +----------+ / | 292 | \| | |/ | \| |/ | 293 | \ | / | \ / | 294 | | | | 295 | / | \ | / \ | 296 | /| | |\ | /| |\ | 297 | / +---------------------+ \ | / +----------+ \ | 298 |/ MN_DETACH \|/ NETLMM \| 299 |\ function /|\ protocol /| 300 | \ +---------------------+ / | \ +----------+ / | 301 | \| | |/ | \| |/ | 302 | \ | / | \ / | 303 | | | | 305 Figure 3: NETLMM MN-MAG Interface Usage Overview 307 4. Interactions of NETLMM Architecture with Subnet and Link Models 309 Within the Internet addressing model, the link and subnet terms, have 310 a tight relationship. Their generally admitted definitions are 311 [I-D.thaler-intarea-multilink-subnet-issues]: 313 Link: a topological area of an IP network delimited by routers. 315 Subnet: a topological area of an IP network that uses the same 316 unsubdivided address prefix. 318 There has recently been protocol proposals achieving multi-link 319 subnets, i.e. the ability for a subnet to span multiple links. 320 However, the consensus in the IETF has been, and remains, that one 321 subnet spans only one link 322 [I-D.thaler-intarea-multilink-subnet-issues]. 324 A straightforward approach to the design of NETLMM would have been to 325 lay a single subnet on the entire NETLMM domain. That would ensure 326 that the MN does not see layer 3 movements since the subnet would 327 never change. However, such an approach would constitute a multi- 328 link subnet, and is thus not deemed acceptable. 330 The following subsection will discuss what kind of subnet and link 331 models have been chosen for the NETLMM architecture. 333 4.1. NETLMM Subnet Model 335 Thus, the NETLMM addressing model is subject to the following two 336 constraints: 338 o The subnet of a MN does not change when the MN changes its 339 attachment point in the domain. 341 o The subnet of a MN does not span more than one link. 343 Because of the first constraint, the subnet of a MN must be valid 344 wherever in the domain the MN attaches to. However, because of the 345 second constraint, the subnet cannot be valid at more than one such 346 attachment points. Thus, the subnet of the MN has to follow the 347 movements of the MN. This addressing model is denoted "per-MN subnet 348 model", and satisfies constraints of both the Internet and NETLMM 349 architectures: 351 A unique prefix MUST be assigned by the NETLMM fabric to each of 352 the MN in the domain. The MAG MUST NOT configure a global unicast 353 address based on this prefix. 355 4.2. NETLMM Link Model 357 The choice of the per-MN addressing model is however conflicting with 358 the use of a shared link layer (e.g. Ethernet, 802.11) as a last hop 359 of the NETLMM domain. 361 In the per-MN subnet model, two MNs always have different subnets. 362 Hence, even though they might be attached to the same shared link 363 layer, they will never communicate directly with global addresses. 364 That happens since on-link determination will always conclude that 365 they are attached to different link because it is based on subnet 366 comparisons. 368 They will however be able to communicate directly with link-local 369 addresses. This is not problematic since link-local addresses are 370 confined to one link and therefore it does not introduce multi-link 371 subnet issues. 373 There is however one problem that arises due to the use of Solicited- 374 Node and All-Nodes multicast IPv6 addresses [RFC4291] as a 375 destination address for sending unsolicited Neighbor Advertisement 376 (NA) messages [RFC2461]. When one MN sends such message, it can be 377 received by other MNs on the same link which will, as a result, 378 create a neighbor cache entry for the sender of the NA. If the NA 379 contained as a target address one of the MN's global unicast address, 380 the receiver is then in a position to communicate directly with this 381 global unicast address, even though it does not share a common subnet 382 prefix (they are per-MN subnet prefixes). This is not a problem as 383 long as these two MNs remain attached on the same link. But if later 384 on one of the MN moves onto a different link, they will no longer be 385 able to communicate directly and this will result in a communication 386 failure, although they were using global addresses whose reachability 387 should be maintained. This is not acceptable. 389 Thus, the interface described in this document MUST only be used 390 in deployments where the link between the MN and the MAG is point- 391 to-point. The interface MUST NOT be used in deployments where the 392 link between the MN and the MAG is shared and/or multi-access. 393 Future specifications MAY define interfaces for use with shared 394 and/or multi-access links. 396 5. Address Collision Considerations 398 As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not 399 execute again Duplicate Address Detection (DAD)[RFC2462] after a 400 handoff in the domain. This is because the MN will always receive 401 the same subnet prefix in the RA and conclude that it did not changed 402 link. Hence there seems to be no need for executing DAD again. 403 However, in NETLMM the link did changed. Because the link is point- 404 to-point the only new entity on the link is the MAG, and it is 405 possible that a collision occurs between link local addresses of the 406 MN and the MAG (Note that no collision are possible with global 407 unicast address(es) since the subnet prefix has been uniquely 408 assigned to the MN). 410 One solution to this issue would be that in a given domain, each MAG 411 also defends link-local addresses of other MAGs in the domain. This 412 would ensure that when the MN first attaches to the NETLMM domain and 413 execute DAD it is able to pro-actively detect collision that may 414 happen with any MAG of the domain. Such a solution has however two 415 drawbacks: 417 o Each MAG needs to know link-local addresses of all other MAGs in 418 the domain. 420 o If SEND is used, each MAG also need to know private keys of all 421 other MAGs since SEND requires a Neighbor Advertisement (NA) 422 message defending an address to be signed with the SEND public key 423 generating the CGA link-local address. 425 A much simpler solution is: 427 All MAGs in a NETLMM domain MUST configure the same link-local 428 address. 430 When SEND is used, that means that all MAGs share a single SEND 431 public-private key pair, and hence a single link-local CGA. 433 Since all MAGs in a domain have the same link local address, if the 434 MN executes DAD at his first attachment and concludes that there is 435 no collision with the link-local address of the first MAG, a 436 collision with any other MAG in the domain is impossible. 438 6. MN_ATTACH Function 440 The MN_ATTACH function is invocated by the MN whenever it attaches to 441 a new MAG, and is constituted by the following sub-functions: 443 o MAG_GET_MN_ID: It provides the MAG with the identifier of the MN 444 (MNID). This identifier MUST be securely bound to the MN, and the 445 corresponding binding MUST be verifiable by the MAG. This 446 triggers the MAG to authenticate the MN as the owner of this MNID. 447 If authentication fails the MN_ATTACH function terminates with 448 failure status, otherwise it continues. 450 o MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing 451 configuration parameters, i.e. IPv6 subnet prefix(es) or global 452 address(es). The MAG will then register the MN IPv6 subnet 453 prefix(es) or address(es) with the LMA using the NETLMM protocol. 455 o MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6 456 address of its default router (e.g. the MAG). 458 o MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast 459 group(s) that the MN previously joined (while attached to a 460 previous MAG). This triggers the MAG to subscribe to the 461 multicast tree(s) corresponding to the group(s) joined by the MN. 463 The MN_ATTACH function will typically be implemented by multiple 464 protocols, some of them possibly non-IP protocols. The following 465 subsections will describe in more details the MAG_GET_MN_ID, 466 MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER, and MAG_GET_MN_MCAST_GROUPS 467 subfunctions, in particular what they achieve, and how. 469 6.1. MAG_GET_MN_ID Sub-function 471 The MAG_GET_MN_ID function provides the MAG with the identifier of 472 the MN (MNID). This identifier MUST be securely bound to the MN, and 473 the corresponding binding MUST be verifiable by the MAG [RFC4832]. 474 This triggers the MAG to authenticate the MN as the owner of this 475 MNID. If authentication fails the MN_ATTACH function terminates with 476 failure status, otherwise it continues. 478 When the MN_ATTACH functions includes a network access authentication 479 protocol, such as EAP [RFC3748], the MN identifier authenticated by 480 the network access authentication protocol is a valid MN ID it 481 satisfies above constraints (freshness of authentication, verifiable 482 by the MAG). 484 When the mix of protocols implementing the MN_ATTACH does not include 485 a network access authentication protocol, or the network access 486 authentication protocol does not provide a suitable MN identifier, or 487 does not guarantee fresh authentication of the MN, an alternative 488 authentication method based on the DNAv6 protocol 489 [I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used 490 to authenticate the MN, as described below: 492 MN MAG LMA 493 |------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN) 494 |<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG) 495 |------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN) 496 |<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG) 498 Figure 4: DNAv6/SEND based MNID authentication 500 o In step REQ1, after attachment occurs, and upon the occurrence of 501 a Layer 2 link-up event notification, the MN initiate self- 502 authentication to the MAG by sending a RS from its link local 503 address to the link-scope all-routers multicast address, as per 504 Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol]. 505 Since this RS is not sent from the unspecified address, it 506 contains the MN SEND public key (PK_MN) in a CGA option, as per 507 Section 5.1.1 of the SEND protocol [RFC3971]. This public key is 508 used as a MN ID by the MAG. 510 o In step REQ2, after the MAG received from the MN a RS containing 511 the MN ID (PK_MN) and the MN link local address, the MAG MUST 512 sollicit the link-local address of the MN by sending a NS to the 513 link-local address of the MN. This NS contains a fresh nonce 514 (Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971]. 516 o In step REP2, after the MN received from the MAG a NS containing a 517 fresh nonce, it replies to the MAG with a NA containing the same 518 fresh nonce as per Section 5.3.3 of the SEND protocol [RFC3971]. 519 This NA is signed with the MN public key (i.e. the MN ID) as per 520 Section 5.2.1 of the SEND protocol [RFC3971]. The MAG will verify 521 1) that the Nonce is fresh as per Section 5.3.4.1 of the SEND 522 protocol [RFC3971], and 2) that the signature is valid for this 523 public key as per Section 5.2.2 of the SEND protocol [RFC3971]. 524 If these verifications succeeds, the MAG has successfully 525 authenticated the MN as the owner of the MN ID. 527 o In step REP1, the MAG concludes the DNAv6 protocol 528 [I-D.ietf-dna-protocol] by sending to the MN a RA. This step is 529 not part of the authentication of the MN and is shown here for 530 completeness only. Note that step REP1 can happen before steps 531 REQ2 or REP2. 533 6.2. MN_GET_ADDR_PARMS Sub-function 535 The MN_GET_ADDR_PARMS function allows the MN to configure IP 536 addresses. This can be achieved via different means, including: 538 o Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the 539 MN to configure both link local and global unicast address(es). 541 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]: 542 Allows the MN to configure global unicast address(es). Typically 543 not used to configure link local unicast address(es). 545 o IP Version 6 over PPP [I-D.ietf-ipv6-over-ppp-v2]: Allows the MN 546 to configure link local unicast address(es). 548 Whenever the MN attaches to a new MAG which is the same domain as its 549 old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not change 550 the address(es) that were configured by the MN at the old MAG. 552 6.3. MN_GET_DEFAULT_ROUTER Sub-function 554 The MN_GET_DEFAULT_ROUTER function provides the MN with its default 555 router. This can be achieved via different means, including: 557 o Router Discovery as specified by the Neighbor Discovery Protocol 558 [RFC2461]. 560 o IP Version 6 over PPP (PPPv6) [I-D.ietf-ipv6-over-ppp-v2]. 562 Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 563 [RFC3315] does not provide a default router. Instead, Router 564 Discovery has to be used. 566 6.4. MAG_GET_MN_MCAST_GROUPS Sub-function 568 The MAG acts as a multicast router for the MN. The 569 MAG_GET_MN_MCAST_GROUPS provides the MAG with the Multicast Address 570 Listening state of the newly attached MN (this state might have been 571 established while attached to a previous MAG). This triggers the MAG 572 to subscribe to the multicast tree(s) corresponding to the source(s) 573 the MN is listening to. 575 In many system architectures, this can be achieved by having, upon 576 movement of the MN, the old MAG doing context transfer to the new MAG 577 of the Multicast Address Listening state learned via MLDv2 [RFC3810] 578 messages. 580 When the deployment does not offer such context transfer, upon each 581 new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query 582 to the link-scope all-nodes multicast address as per Section 5.1.15 583 and 7.1 of the MLDv2 protocol [RFC3810]. A newly attached MN will 584 then reports its Multicast Address Listening state as per Section 6.2 585 of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to 586 the appropriate multicast tree(s). 588 7. MN_DETACH Function 590 When a MN detaches from a MAG, the MAG has to deregister this MN with 591 the LMA. 593 When the underlying link layer provides a reliable indication of a MN 594 having detached from the MAG, the MAG MUST deregister the MN with the 595 LMA upon reception of such indication. 597 When the underlying link layer provides no reliable indication of a 598 MN having detached from the MAG, it is necessary to allow the MAG to 599 detect a MN which silently detaches, or crashes, so that it can 600 deregister the MN as a consequence. When such link layer are used, 601 the MAG MUST periodically execute Neighbor Unreachability Detection 602 as per Section 7.3 of the Neighbor Discovery Protocol [RFC2461] with 603 each of the attached MN, even though it has no traffic to deliver to 604 the MN. 606 When a MN detaches from a MAG, the MAG MUST conclude that multicast 607 address listening for the MN terminates for all the sources it was 608 listening to. 610 8. Security Considerations 612 The security considerations regarding the specified interface will be 613 evaluated in further revisions of this document. 615 9. IANA Considerations 617 There are no IANA considerations. 619 10. Acknowledgments 621 As usual in the IETF, this document is the result of a collaboration 622 between many people. The authors would like to thanks (in 623 alphabetical order) James Kempf, Alexandru Petrescu, Fred Templin and 624 Christian Vogt for discussion and/or comments that helped with first 625 versions of this document. 627 Ian Chakeres contributed the reference network diagram. 629 Julien Laganier is partly funded by Ambient Networks, a research 630 project supported by the European Commission under its Sixth 631 Framework Program. The views and conclusions contained herein are 632 those of the authors and should not be interpreted as necessarily 633 representing the official policies or endorsements, either expressed 634 or implied, of the Ambient Networks project or the European 635 Commission. 637 11. References 639 11.1. Normative references 641 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 642 Requirement Levels", BCP 14, RFC 2119, March 1997. 644 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 645 Discovery for IP Version 6 (IPv6)", RFC 2461, 646 December 1998. 648 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 649 Autoconfiguration", RFC 2462, December 1998. 651 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 652 Stateless Address Autoconfiguration in IPv6", RFC 3041, 653 January 2001. 655 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 656 and M. Carney, "Dynamic Host Configuration Protocol for 657 IPv6 (DHCPv6)", RFC 3315, July 2003. 659 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 660 Levkowetz, "Extensible Authentication Protocol (EAP)", 661 RFC 3748, June 2004. 663 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 664 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 666 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 667 Neighbor Discovery (SEND)", RFC 3971, March 2005. 669 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 670 RFC 3972, March 2005. 672 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 673 Architecture", RFC 4291, February 2006. 675 [I-D.ietf-dna-protocol] 676 Kempf, J., "Detecting Network Attachment in IPv6 Networks 677 (DNAv6)", draft-ietf-dna-protocol-05 (work in progress), 678 March 2007. 680 [I-D.ietf-netlmm-proxymip6] 681 Gundavelli, S., "Proxy Mobile IPv6", 682 draft-ietf-netlmm-proxymip6-00 (work in progress), 683 April 2007. 685 11.2. Informative references 687 [I-D.ietf-ipv6-over-ppp-v2] 688 Varada, S., "IP Version 6 over PPP", 689 draft-ietf-ipv6-over-ppp-v2-03 (work in progress), 690 May 2007. 692 [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized 693 Mobility Management (NETLMM)", RFC 4830, April 2007. 695 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 696 Management (NETLMM)", RFC 4831, April 2007. 698 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 699 Localized Mobility Management (NETLMM)", RFC 4832, 700 April 2007. 702 [I-D.thaler-intarea-multilink-subnet-issues] 703 Thaler, D., "Issues With Protocols Proposing Multilink 704 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 705 (work in progress), March 2006. 707 Appendix A. Version history 709 A.1. -01 to -02 711 o revamped document structure to make it agnostic to attachment 712 method (e.g. authentication, address-configuration, etc.). 714 o specified per-MN subnet prefix, and point-to-point link model. 716 o specified support for multicast. 718 o various editorial changes. 720 A.2. -00 to -01 722 o added DHCP access method including DHCP prefix delegation. 724 o added new network reference diagram. 726 o added definitions for NETLMM domain and NLMP. 728 o updated NA proxying method for colliding CGAs. 730 o added text on sending IP multicast messages to a Layer-2 unicast 731 address. 733 o added new Section 4.5 text on MNID/IP address binding. 735 o added new Section 5. on multilink subnet issues. 737 o various editorial changes. 739 Authors' Addresses 741 Julien Laganier 742 DoCoMo Communications Laboratories Europe GmbH 743 Landsberger Strasse 312 744 Munich 80687 745 Germany 747 Phone: +49 89 56824 231 748 Email: julien.ietf@laposte.net 749 URI: http://www.docomolab-euro.com/ 751 Sathya Narayanan 752 Panasonic Digital Networking Lab 753 Two Research Way, 3rd Floor 754 Princeton, NJ 08536 755 USA 757 Phone: +1 609 734 7599 758 Email: sathya@research.panasonic.com 760 Full Copyright Statement 762 Copyright (C) The IETF Trust (2007). 764 This document is subject to the rights, licenses and restrictions 765 contained in BCP 78, and except as set forth therein, the authors 766 retain all their rights. 768 This document and the information contained herein are provided on an 769 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 770 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 771 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 772 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 773 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 774 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 776 Intellectual Property 778 The IETF takes no position regarding the validity or scope of any 779 Intellectual Property Rights or other rights that might be claimed to 780 pertain to the implementation or use of the technology described in 781 this document or the extent to which any license under such rights 782 might or might not be available; nor does it represent that it has 783 made any independent effort to identify any such rights. Information 784 on the procedures with respect to rights in RFC documents can be 785 found in BCP 78 and BCP 79. 787 Copies of IPR disclosures made to the IETF Secretariat and any 788 assurances of licenses to be made available, or the result of an 789 attempt made to obtain a general license or permission for the use of 790 such proprietary rights by implementers or users of this 791 specification can be obtained from the IETF on-line IPR repository at 792 http://www.ietf.org/ipr. 794 The IETF invites any interested party to bring to its attention any 795 copyrights, patents or patent applications, or other proprietary 796 rights that may cover technology that may be required to implement 797 this standard. Please address the information to the IETF at 798 ietf-ipr@ietf.org. 800 Acknowledgment 802 Funding for the RFC Editor function is provided by the IETF 803 Administrative Support Activity (IASA).