idnits 2.17.1 draft-ietf-netlmm-mn-ar-if-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 867. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 878. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 885. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 891. 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 (February 13, 2008) is 5916 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-06 == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-proxymip6-10 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: August 16, 2008 iTCD/CSUMB 6 P. McCann 7 Motorola 8 February 13, 2008 10 Interface between a Proxy MIPv6 Mobility Access Gateway and a Mobile 11 Node 12 draft-ietf-netlmm-mn-ar-if-03 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. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on August 16, 2008. 39 Copyright Notice 41 Copyright (C) The IETF Trust (2008). 43 Abstract 45 This document describes an interface between mobile nodes (MNs) and a 46 mobility access gateway (MAG) of a network-based localized mobility 47 management (NETLMM) domain. The interface has two functions which 48 are invoked when a MN attaches and detaches from a MAG. The 49 attachment function lets the MAG authenticate the MN identifier, does 50 address(es) and default router configuration for the MN, and informs 51 the MAG about the multicast listener state of the MN. During the 52 attachment function the NETLMM protocol is triggered between the MAG 53 and Localized Mobility Anchor (LMA) to register the MN in the local 54 domain. The detachment function lets the MAG detect that the MN has 55 left so that it can deregister the MN at the LMA using the NETLMM 56 protocol. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Operating Environment . . . . . . . . . . . . . . . . . . . . 7 63 4. Interactions of NETLMM Architecture with Subnet and Link 64 Models . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 4.1. NETLMM Subnet Model . . . . . . . . . . . . . . . . . . . 10 66 4.2. NETLMM Link Model . . . . . . . . . . . . . . . . . . . . 11 67 5. Address Collision Considerations . . . . . . . . . . . . . . . 12 68 6. MN_ATTACH Function . . . . . . . . . . . . . . . . . . . . . . 13 69 6.1. MAG_GET_MN_ID Sub-function . . . . . . . . . . . . . . . . 13 70 6.2. MAG_GET_HI Sub-function . . . . . . . . . . . . . . . . . 15 71 6.3. MN_GET_ADDR_PARMS Sub-function . . . . . . . . . . . . . . 15 72 6.4. MN_GET_DEFAULT_ROUTER Sub-function . . . . . . . . . . . . 16 73 6.5. MAG_GET_MN_MCAST_GROUPS Sub-function . . . . . . . . . . . 16 74 7. MN_DETACH Function . . . . . . . . . . . . . . . . . . . . . . 17 75 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 76 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 77 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 78 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 79 11.1. Normative references . . . . . . . . . . . . . . . . . . . 21 80 11.2. Informative references . . . . . . . . . . . . . . . . . . 22 81 Appendix A. Version history . . . . . . . . . . . . . . . . . . . 23 82 A.1. -02 to -04 . . . . . . . . . . . . . . . . . . . . . . . . 23 83 A.2. -01 to -02 . . . . . . . . . . . . . . . . . . . . . . . . 23 84 A.3. -00 to -01 . . . . . . . . . . . . . . . . . . . . . . . . 23 85 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 86 Intellectual Property and Copyright Statements . . . . . . . . . . 25 88 1. Introduction 90 It is suggested in [RFC4830] that it would be desirable to have a 91 localized mobility management protocol in which the host is not 92 involved. The requirements for such a protocol have been analyzed in 93 [RFC4831]. Accordingly, a protocol for network-based localized 94 mobility management (NETLMM) of IPv6 nodes is specified by the NETLMM 95 working group [I-D.ietf-netlmm-proxymip6]. Because the NETLMM 96 protocol is network based, the mobile node (MN) is not required to 97 implement a new mechanism in its IP stack, nor to change its IP 98 address when it attaches to a new mobility access gateway (MAG). 100 Because the IPv6 MN will use a vanilla IPv6 stack, the interface 101 between an MN and its MAG has to be preserved. This means that 102 standard IPv6 should work seamlessly with the network-based localized 103 mobility support. More specifically, we require the proposed 104 solution to be compatible with the mechanisms specified in: 106 o Neighbor Discovery for IP version 6 [RFC2461] 108 o IPv6 Stateless Address Autoconfiguration [RFC2462] 110 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315] 112 o Privacy Extensions for Stateless Address Autoconfiguration in IPv6 113 [RFC3041] 115 o Detecting Network Attachment in IPv6 Networks (DNAv6) 116 [I-D.ietf-dna-protocol] 118 o SEcure Neighbor Discovery (SEND) [RFC3971] 120 o Cryptographically Generated Addresses (CGAs) [RFC3972] 122 This document describes an interface between mobile nodes (MNs) and a 123 mobility access gateway (MAG) of a network-based localized mobility 124 management (NETLMM) domain. The interface has two functions which 125 are invoked when a MN attaches and detaches from a MAG. The 126 attachment function lets the MAG authenticate the MN identifier, does 127 address(es) and default router configuration for the MN, and informs 128 the MAG about the multicast listener state of the MN. During the 129 attachment function the NETLMM protocol is triggered between the MAG 130 and Localized Mobility Anchor (LMA) to register the MN in the local 131 domain. The detachment function lets the MAG detect that the MN has 132 left so that it can deregister the MN at the LMA using the NETLMM 133 protocol. 135 In the absence of link-layer specific mechanisms implementing these 136 functions, this document describes which IP protocols should be used 137 to provide the necessary interface between the MN and the MAG. 139 2. Terminology 141 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 142 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 143 document are to be interpreted as described in [RFC2119]. 145 The following terms are defined within the scope of this document: 147 Mobile Node (MN) 148 an IPv6 node moving in the NETLMM domain. 150 Mobility Access Gateway (MAG) 151 a default router that connects the MN to the NETLMM domain. 153 Localized Mobility Anchor (LMA) 154 a router located in the NETLMM domain that handles packet 155 exchanges with nodes in the domain. 157 Network-based Localized Mobility Management Domain (NETLMM domain) 158 an administrative domain spanning links served by a set of LMAs 159 (and their associated MAGs and MNs) that provision addresses from 160 the same IP subnet prefix(es). 162 Network-based Localized Mobility Management Protocol (NLMP) 163 The NETLMM Protocol used in the backhaul of the NETLMM domain 164 between MAGs and LMA. 166 The following abbreviations are used throughout this document: 168 NETLMM: Network-based Localized Mobility Management 170 ND: Neighbor Discovery. 172 NS: Neighbor Solicitation. 174 NA: Neighbor Advertizement. 176 RS: Router Solicitation. 178 RA: Router Advertisement. 180 NDP: Neighbor Discovery Protocol. 182 SLAAC: StateLess Address AutoConfiguration 184 DHCP: Dynamic Host Configuration Protocol 186 SEND: SEcure Neighbor Discovery. 188 DNA: Detecting Network Attachment. 190 CGA: Cryptographically Generated Address. 192 MNID: An authenticated MN identifier (e.g. NAI, a SEND public key 193 used by the MN for generating its CGAs,an IMSI or TMSI, etc.). 195 3. Operating Environment 197 The MN-MAG NETLMM interface is used between an MN and a MAG of a 198 NETLMM domain. It allows the MAG and/or MN to detect network 199 attachment and detachment, causing the MAG to use the NETLMM protocol 200 to update routing at the LMA so that the MN stays reachable when it 201 roams across the NETLMM domain. 203 /---------------------------\ 204 / Internet \ 205 \ / 206 \-------+---------+---------/ 207 | | 208 /--------+---------+--------\ ---- 209 / \ ^ 210 / +-----+ \ | 211 | | LMA |-+ | N 212 | +-----+ |-+ | E 213 | +-----+ | | T 214 | +-----+ | L 215 | Backhaul Network | M 216 | +------+ +------+ | M 217 |- - | MAG1 | ..... | MAG2 | - -| 218 | +------+ +------+ | d 219 | / \ Access / \ | o 220 | / \ Network / \ | m 221 | / \ / \ | a 222 | +----+ | i 223 | | MN | -------> | n 224 \ +----+ MAG change / | 225 \ / v 226 \---------------------------/ ---- 228 Figure 1: Reference Network Diagram 230 The deployment scenario is shown in Figure 1 above: several MAGs are 231 attached to an IP routing domain connected to the outside Internet 232 via an LMA. The MNs, MAGs, LMAs, and in-between routing fabric 233 constitute the NETLMM domain. Packets arriving at the LMA and 234 destined to a MN are tunneled to the appropriate MAG. Packets from 235 the MN are received by the MAG and tunneled to the LMA and then 236 decapsulated and sent on to the Internet. 238 In the absence of a link-layer specific mechanisms to implement the 239 MN-MAG interface, it is required to have a common interface defined 240 at the IP layer. Because no NETLMM specific software support is 241 assumed to be present on MNs, this interface has to rely only on 242 standards track IPv6 protocols such as ND, DHCP, SEND, and DNA. 244 Interactions of these components with NETLMM are represented in 245 Figure 2 below (note that hints received by DNA from other layers are 246 omitted for clarity): 248 MN|MAG 249 Interface 250 | 252 | +------------+ +----------+ 253 | | | | 254 | | +--------+ | NLMP | +------+ | 255 | | NETLMM |<-------->|NETLMM| | 256 | | +--------+ | | +------+ | 257 | ^ ^ | | ^ | 258 +----------+ | | | | | | | | 259 | | | v | | | | | 260 | +------+ | | | +-----+ | | | | | 261 | | DNA | | NDP/DHCP | | DNA | | | | | | 262 | | SEND |<------|------>|SEND | | | | | | 263 | | ND | | | | ND | | | | | | 264 | | DHCP | | | | |DHCP | | | | | | 265 | +------+ | | +-----+ | | | | | 266 | ^ | | | ^ | | | | | 267 | | | | | | | | | | 268 | v | | | v | | | v | 269 | +------+ | | +----+ | | | +------+ | 270 | | | | | | | |<-+ | | | | | 271 | | | | IPv6 | | | | IPv6 | | | | 272 | | IPv6 |<------|------>|IPv6|<------------>| IPv6 | | 273 | +------+ | | +----+ | | +------+ | 274 | | | | | | | 275 | MN | | MAG | | LMA | 276 +----------+ | +------------+ +----------+ 278 | 280 Figure 2: NETLMM Component Interactions 282 An overview of the interactions between the MN-MAG interface and the 283 NETLMM protocol is shown in Figure 3. 285 MN|MAG 286 Interface 287 MN | MAG LMA 288 | | | | 289 | / | \ | / \ | 290 | /| | |\ | /| |\ | 291 | / +---------------------+ \ | / +----------+ \ | 292 |/ MN_ATTACH \|/ NETLMM \| 293 |\ function /|\ protocol /| 294 | \ +---------------------+ / | \ +----------+ / | 295 | \| | |/ | \| |/ | 296 | \ | / | \ / | 297 | | | | 298 | / | \ | / \ | 299 | /| | |\ | /| |\ | 300 | / +---------------------+ \ | / +----------+ \ | 301 |/ data packet \|/ data packet \| 302 |\ traffic /|\ traffic /| 303 | \ +---------------------+ / | \ +----------+ / | 304 | \| | |/ | \| |/ | 305 | \ | / | \ / | 306 | | | | 307 | / | \ | / \ | 308 | /| | |\ | /| |\ | 309 | / +---------------------+ \ | / +----------+ \ | 310 |/ MN_DETACH \|/ NETLMM \| 311 |\ function /|\ protocol /| 312 | \ +---------------------+ / | \ +----------+ / | 313 | \| | |/ | \| |/ | 314 | \ | / | \ / | 315 | | | | 317 Figure 3: NETLMM MN-MAG Interface Usage Overview 319 4. Interactions of NETLMM Architecture with Subnet and Link Models 321 Within the Internet addressing model, the terms link and subnet have 322 a tight relationship. Their generally admitted definitions are 323 [I-D.thaler-intarea-multilink-subnet-issues]: 325 Link: a topological area of an IP network delimited by routers. 327 Subnet: a topological area of an IP network that uses the same 328 unsubdivided address prefix. 330 There has recently been protocol proposals achieving multi-link 331 subnets, i.e. the ability for a subnet to span multiple links. 332 However, the consensus in the IETF has been, and remains, that one 333 subnet spans only one link 334 [I-D.thaler-intarea-multilink-subnet-issues]. 336 A straightforward approach to the design of NETLMM would have been to 337 lay a single subnet on the entire NETLMM domain. That would ensure 338 that the MN does not see layer 3 movements since the subnet would 339 never change. However, such an approach would constitute a multi- 340 link subnet, and is thus not deemed acceptable. 342 The following subsection will discuss what kind of subnet and link 343 models have been chosen for the NETLMM architecture. 345 4.1. NETLMM Subnet Model 347 Thus, the NETLMM addressing model is subject to the following two 348 constraints: 350 o The subnet of a MN does not change when the MN changes its 351 attachment point in the domain. 353 o The subnet of a MN does not span more than one link. 355 Because of the first constraint, the subnet of a MN must be valid 356 wherever in the domain the MN attaches to. However, because of the 357 second constraint, the subnet cannot be valid at more than one such 358 attachment point. Thus, the subnet of the MN has to follow the 359 movements of the MN. This addressing model is denoted "per-MN subnet 360 model", and satisfies constraints of both the Internet and NETLMM 361 architectures: 363 A unique prefix MUST be assigned by the NETLMM fabric to each of 364 the MNs in the domain. The MAG MUST NOT configure a global 365 unicast address based on this prefix. 367 4.2. NETLMM Link Model 369 The choice of the per-MN addressing model is however conflicting with 370 the use of a shared link layer (e.g. Ethernet, 802.11) as a last hop 371 of the NETLMM domain. 373 In the per-MN subnet model, two MNs always have different subnets. 374 Hence, even though they might be attached to the same shared link 375 layer, they will never communicate directly with global addresses. 376 That happens since on-link determination will always conclude that 377 they are attached to different link because it is based on subnet 378 comparisons. 380 They will however be able to communicate directly with link-local 381 addresses. This is not problematic since link-local addresses are 382 confined to one link and therefore it does not introduce multi-link 383 subnet issues. 385 There is however one problem that arises due to the use of Solicited- 386 Node and All-Nodes multicast IPv6 addresses [RFC4291] as a 387 destination address for sending unsolicited Neighbor Advertisement 388 (NA) messages [RFC2461]. When one MN sends such message, it can be 389 received by other MNs on the same link which will, as a result, 390 create a neighbor cache entry for the sender of the NA. If the NA 391 contained as a target address one of the MN's global unicast address, 392 the receiver is then in a position to communicate directly with this 393 global unicast address, even though it does not share a common subnet 394 prefix (they are per-MN subnet prefixes). This is not a problem as 395 long as these two MNs remain attached on the same link. But if later 396 on one of the MN moves onto a different link, they will no longer be 397 able to communicate directly and this will result in a communication 398 failure, although they were using global addresses whose reachability 399 should be maintained. This is not acceptable. 401 Thus, the interface described in this document MUST only be used 402 in deployments where the link between the MN and the MAG is point- 403 to-point. The interface MUST NOT be used in deployments where the 404 link between the MN and the MAG is shared and/or multi-access. 405 Future specifications MAY define interfaces for use with shared 406 and/or multi-access links. 408 5. Address Collision Considerations 410 As per the DNAv6 protocol [I-D.ietf-dna-protocol], the MN will not 411 execute Duplicate Address Detection (DAD)[RFC2462] after a handoff 412 within the same domain. This is because the MN will always receive 413 the same subnet prefix in the RA and conclude that it did not change 414 link. Hence there seems to be no need for executing DAD again. 415 However, in NETLMM the link did changed. Because the link is point- 416 to-point the only new entity on the link is the MAG, and it is 417 possible that a collision occurs between link local addresses of the 418 MN and the MAG (Note that no collisions are possible with global 419 unicast address(es) since the subnet prefix has been uniquely 420 assigned to the MN). 422 One solution to this issue would be that in a given domain, each MAG 423 also defends link-local addresses of other MAGs in the domain. This 424 would ensure that when the MN first attaches to the NETLMM domain and 425 executes DAD it is able to pro-actively detect collisions that may 426 happen with any MAG of the domain. Such a solution has however two 427 drawbacks: 429 o Each MAG needs to know link-local addresses of all other MAGs in 430 the domain. 432 o If SEND is used, each MAG also need to know private keys of all 433 other MAGs since SEND requires a Neighbor Advertisement (NA) 434 message defending an address to be signed with the SEND public key 435 generating the CGA link-local address. 437 A much simpler solution is: 439 All MAGs in a NETLMM domain MUST configure the same link-local 440 address. 442 When SEND is used, that means that all MAGs share a single SEND 443 public-private key pair, and hence a single link-local CGA. 445 Since all MAGs in a domain have the same link local address, if the 446 MN executes DAD at his first attachment and concludes that there is 447 no collision with the link-local address of the first MAG, a 448 collision with any other MAG in the domain is impossible. 450 6. MN_ATTACH Function 452 The MN_ATTACH function is invoked by the MN whenever it attaches to a 453 new MAG, and consists of the following sub-functions: 455 o MAG_GET_MN_ID: It provides the MAG with the identifier of the MN 456 (MNID). This identifier MUST be securely bound to the MN, and the 457 corresponding binding MUST be verifiable by the MAG. This 458 triggers the MAG to authenticate the MN as the owner of this MNID. 459 If authentication fails the MN_ATTACH function terminates with 460 failure status, otherwise it continues. 462 o MAG_GET_HI: It provides the MAG with information to put in the 463 Access Technology Type, Mobile Node Interface Identifier, and 464 Handoff Indication fields. 466 o MN_GET_ADDR_PARMS: It provides the MN with IPv6 addressing 467 configuration parameters, i.e. IPv6 subnet prefix(es) or global 468 address(es). The MAG will then register the MN IPv6 subnet 469 prefix(es) or address(es) with the LMA using the NETLMM protocol. 471 o MN_GET_DEFAULT_ROUTER: It provides the MN with the link local IPv6 472 address of its default router (e.g. the MAG). 474 o MAG_GET_MN_MCAST_GROUPS: It provides the MAG with the multicast 475 group(s) that the MN previously joined (while attached to a 476 previous MAG). This triggers the MAG to subscribe to the 477 multicast tree(s) corresponding to the group(s) joined by the MN. 479 The MN_ATTACH function will typically be implemented by multiple 480 protocols, some of them possibly non-IP protocols. The following 481 subsections will describe in more details the MAG_GET_MN_ID, 482 MAG_GET_HI, MN_GET_ADDR_PARMS, MN_GET_DEFAULT_ROUTER, and 483 MAG_GET_MN_MCAST_GROUPS subfunctions, in particular what they 484 achieve, and how. 486 6.1. MAG_GET_MN_ID Sub-function 488 The MAG_GET_MN_ID function provides the MAG with the identifier of 489 the MN (MNID). This identifier MUST be securely bound to the MN, and 490 the corresponding binding MUST be verifiable by the MAG [RFC4832]. 491 This triggers the MAG to authenticate the MN as the owner of this 492 MNID. If authentication fails the MN_ATTACH function terminates with 493 failure status, otherwise it continues. 495 When the MN_ATTACH function includes a network access authentication 496 protocol, such as EAP [RFC3748], the Network Access Identifier (NAI) 497 authenticated by the network access authentication protocol is a 498 valid MN ID if it satisfies above constraints (freshness of 499 authentication, verifiable by the MAG). 501 When the mix of protocols implementing the MN_ATTACH does not include 502 a network access authentication protocol, or the network access 503 authentication protocol does not provide a suitable MN identifier, or 504 does not guarantee fresh authentication of the MN, an alternative 505 authentication method based on the DNAv6 protocol 506 [I-D.ietf-dna-protocol] and the SEND protocol [RFC3971] MUST be used 507 to authenticate the MN, as described below: 509 MN MAG LMA 510 |------>| | REQ1. RS(Nonce_MN,PK_MN,Signature_MN) 511 |<------| | REQ2. NS(Nonce_MAG,PK_MAG,Signature_MAG) 512 |------>| | REP2. NA(Nonce_MAG,PK_MN,Signature_MN) 513 |<------| | REP1. RA(Nonce_MN,PK_MAG,Signature_MAG) 515 Figure 4: DNAv6/SEND based MNID authentication 517 o In step REQ1, after attachment occurs, and upon the occurrence of 518 a Layer 2 link-up event notification, the MN initiates self- 519 authentication to the MAG by sending an RS from its link local 520 address to the link-scope all-routers multicast address, as per 521 Section 5.2.5 of the DNAv6 protocol [I-D.ietf-dna-protocol]. 522 Since this RS is not sent from the unspecified address, it 523 contains the MN SEND public key (PK_MN) in a CGA option, as per 524 Section 5.1.1 of the SEND protocol [RFC3971]. This public key is 525 used as an MN ID by the MAG. 527 o In step REQ2, after the MAG received from the MN an RS containing 528 the MN ID (PK_MN) and the MN link local address, the MAG MUST 529 solicit the link-local address of the MN by sending an NS to the 530 link-local address of the MN. This NS contains a fresh nonce 531 (Nonce_MN) as per Section 5.3.3. of the SEND protocol [RFC3971]. 533 o In step REP2, after the MN received from the MAG a NS containing a 534 fresh nonce, it replies to the MAG with an NA containing the same 535 fresh nonce as per Section 5.3.3 of the SEND protocol [RFC3971]. 536 This NA is signed with the MN public key (i.e. the MN ID) as per 537 Section 5.2.1 of the SEND protocol [RFC3971]. The MAG will verify 538 1) that the Nonce is fresh as per Section 5.3.4.1 of the SEND 539 protocol [RFC3971], and 2) that the signature is valid for this 540 public key as per Section 5.2.2 of the SEND protocol [RFC3971]. 541 If these verifications succeed, the MAG has successfully 542 authenticated the MN as the owner of the MN ID. 544 o In step REP1, the MAG concludes the DNAv6 protocol 545 [I-D.ietf-dna-protocol] by sending to the MN an RA. This step is 546 not part of the authentication of the MN and is shown here for 547 completeness only. Note that a NETLMM exchange between the MAG 548 and LMA MUST occur between REP2 and REP1 so that the MAG can 549 obtain the proper Home Network Prefix to advertise toward the MN 550 in REP1 (the Router Advertisement). 552 6.2. MAG_GET_HI Sub-function 554 During the MAG_GET_HI function the MAG MUST be given an indication of 555 the link technology in use and MUST populate the Access Technology 556 Type (ATT) appropriately. Usually the MAG will also obtain a link- 557 layer address through link establishment or from the Router 558 Solicitation message in step REQ1. For example, the IPv6CP 559 Interface-Identifier option [RFC5072] may be negotiated during PPP 560 establishment. The MAG SHOULD place the link-layer address in the 561 Mobile Node Interface Identifier (MNIID) option of the Proxy BU. The 562 MAG MUST set the Handoff Indicator option to an appropriate value 563 depending on the information it has from link establishment or 564 context transfer signaling. If the MAG knows that there was a 565 previous session for this MN using a different ATT and MNIID, then it 566 SHOULD set the HI field to 1 (Attachment over a new interface). If 567 the MAG knows that there was a previous session using a different ATT 568 but the same MNIID, the MAG SHOULD set the HI field to 2 (Handoff 569 between two different interfaces of the mobile node). If the MAG 570 knows that there was a previous session using the same ATT and the 571 same MNIID, the MAG SHOULD set the HI field to 3 (Handoff between 572 mobile access gateways for the same interface). If the MAG has no 573 information about previous sessions the MAG SHOULD set the HI field 574 to 4 (Handoff state unknown). On subsequent Proxy BUs (sent to 575 refresh the lifetime) the MAG SHOULD always set the HI field to 5 576 (Handoff state not changed (Re-registration)). 578 6.3. MN_GET_ADDR_PARMS Sub-function 580 The MN_GET_ADDR_PARMS function allows the MN to configure IP 581 addresses. This can be achieved via different means, including: 583 o Stateless Address Autoconfiguration (SLAAC) [RFC2462]: Allows the 584 MN to configure both link local and global unicast address(es). 586 o Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [RFC3315]: 587 Allows the MN to configure global unicast address(es). Typically 588 not used to configure link local unicast address(es). 590 o IP Version 6 over PPP [RFC5072]: Allows the MN to configure link 591 local unicast address(es). 593 Whenever the MN attaches to a new MAG which is in the same domain as 594 its old MAG, the MN_GET_ADDR_PARMS at the new MAG MUST must not 595 change the address(es) that were configured by the MN at the old MAG. 597 6.4. MN_GET_DEFAULT_ROUTER Sub-function 599 The MN_GET_DEFAULT_ROUTER function provides the MN with its default 600 router. This can be achieved via different means, including: 602 o Router Discovery as specified by the Neighbor Discovery Protocol 603 [RFC2461]. 605 o IP Version 6 over PPP (PPPv6) [RFC5072]. 607 Note that Dynamic Host Configuration Protocol for IPv6 (DHCPv6) 608 [RFC3315] does not provide a default router. Instead, Router 609 Discovery has to be used. 611 6.5. MAG_GET_MN_MCAST_GROUPS Sub-function 613 The MAG acts as a multicast router for the MN. The 614 MAG_GET_MN_MCAST_GROUPS provides the MAG with the Multicast Address 615 Listening state of the newly attached MN (this state might have been 616 established while attached to a previous MAG). This triggers the MAG 617 to subscribe to the multicast tree(s) corresponding to the source(s) 618 the MN is listening to. 620 In many system architectures, this can be achieved by having, upon 621 movement of the MN, the old MAG doing context transfer to the new MAG 622 of the Multicast Address Listening state learned via MLDv2 [RFC3810] 623 messages. 625 When the deployment does not offer such context transfer, upon each 626 new MN attachment the MAG MUST send a MLDv2 [RFC3810] General Query 627 to the link-scope all-nodes multicast address as per Section 5.1.15 628 and 7.1 of the MLDv2 protocol [RFC3810]. A newly attached MN will 629 then report its Multicast Address Listening state as per Section 6.2 630 of the MLDv2 protocol [RFC3810], thus allowing the MAG to register to 631 the appropriate multicast tree(s). 633 7. MN_DETACH Function 635 When an MN detaches from a MAG, the MAG has to deregister this MN 636 with the LMA. 638 When the underlying link layer provides a reliable indication of an 639 MN having detached from the MAG, the MAG MUST deregister the MN with 640 the LMA upon reception of such indication. 642 When the underlying link layer provides no reliable indication of an 643 MN having detached from the MAG, it is necessary to allow the MAG to 644 detect an MN which silently detaches, or crashes, so that it can 645 deregister the MN as a consequence. When such a link layer is used, 646 the MAG MUST periodically execute Neighbor Unreachability Detection 647 as per Section 7.3 of the Neighbor Discovery Protocol [RFC2461] with 648 each of the attached MNs, even though it has no traffic to deliver to 649 the MN. 651 When an MN detaches from a MAG, the MAG MUST conclude that multicast 652 address listening for the MN terminates for all the sources it was 653 listening to. 655 8. Security Considerations 657 The security threats to the MN-AR protocol include: 659 o Eavesdropping on the MN-AR exchange, where an attacker may learn 660 information such as the MNID that might be confidential. 662 o Malicious redirection of packets to a location other than that of 663 the MN, where traffic can be observed more easily by an attacker. 665 o Causing denial-of-service by de-registering the MN prematurely. 667 When the link layer incorporates strong authentication with a secure 668 binding to the MN's link address, these threats are mitigated. A 669 protocol such as EAP can be used in a mode where the NAI is obscured, 670 obviating threat 1. EAP can also generate keys that get securely 671 bound to native link encryption and authentication mechanisms. As 672 long as all MAGs in a domain faithfully authenticate each MN then 673 threats 2 and 3 are also mitigated. 675 In the absence of strong layer-2 security, the default protocol based 676 on DNAv6 and SEND has somewhat weaker security properties. The MN_PK 677 will be visible to anyone that can eavesdrop on the link. The 678 protocol is vulnerable to a man-in-the-middle attack where the 679 messages are relayed by an attacker to an MN that believes it is 680 attached to a legitimate MAG. This could allow an attacker to 681 redirect traffic. Finally, if the layer-2 protocol is left 682 vulnerable to spoofing an attacker may be able to generate a link- 683 down event which would cause the MAG to deregister the MN. 685 9. IANA Considerations 687 There are no IANA considerations. 689 10. Acknowledgments 691 As usual in the IETF, this document is the result of a collaboration 692 between many people. The authors would like to thanks (in 693 alphabetical order) James Kempf, Alexandru Petrescu, Fred Templin and 694 Christian Vogt for discussion and/or comments that helped with first 695 versions of this document. 697 Ian Chakeres contributed the reference network diagram. 699 Julien Laganier is partly funded by Ambient Networks, a research 700 project supported by the European Commission under its Sixth 701 Framework Program. The views and conclusions contained herein are 702 those of the authors and should not be interpreted as necessarily 703 representing the official policies or endorsements, either expressed 704 or implied, of the Ambient Networks project or the European 705 Commission. 707 11. References 709 11.1. Normative references 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 715 Discovery for IP Version 6 (IPv6)", RFC 2461, 716 December 1998. 718 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 719 Autoconfiguration", RFC 2462, December 1998. 721 [RFC3041] Narten, T. and R. Draves, "Privacy Extensions for 722 Stateless Address Autoconfiguration in IPv6", RFC 3041, 723 January 2001. 725 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 726 and M. Carney, "Dynamic Host Configuration Protocol for 727 IPv6 (DHCPv6)", RFC 3315, July 2003. 729 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 730 Levkowetz, "Extensible Authentication Protocol (EAP)", 731 RFC 3748, June 2004. 733 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 734 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 736 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 737 Neighbor Discovery (SEND)", RFC 3971, March 2005. 739 [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", 740 RFC 3972, March 2005. 742 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 743 Architecture", RFC 4291, February 2006. 745 [I-D.ietf-dna-protocol] 746 Kempf, J., "Detecting Network Attachment in IPv6 Networks 747 (DNAv6)", draft-ietf-dna-protocol-06 (work in progress), 748 June 2007. 750 [I-D.ietf-netlmm-proxymip6] 751 Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 752 and B. Patil, "Proxy Mobile IPv6", 753 draft-ietf-netlmm-proxymip6-10 (work in progress), 754 February 2008. 756 11.2. Informative references 758 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 759 PPP", RFC 5072, September 2007. 761 [RFC4830] Kempf, J., "Problem Statement for Network-Based Localized 762 Mobility Management (NETLMM)", RFC 4830, April 2007. 764 [RFC4831] Kempf, J., "Goals for Network-Based Localized Mobility 765 Management (NETLMM)", RFC 4831, April 2007. 767 [RFC4832] Vogt, C. and J. Kempf, "Security Threats to Network-Based 768 Localized Mobility Management (NETLMM)", RFC 4832, 769 April 2007. 771 [I-D.thaler-intarea-multilink-subnet-issues] 772 Thaler, D., "Issues With Protocols Proposing Multilink 773 Subnets", draft-thaler-intarea-multilink-subnet-issues-00 774 (work in progress), March 2006. 776 Appendix A. Version history 778 A.1. -02 to -04 780 o -03 was a tombstone 782 o Pete McCann added as editor 784 o Various editorial fixes 786 o Modified description of REP1 to indicate that Proxy BU/BA must 787 complete before 789 o Added description of how to set ATT, MNIID, and HI 791 A.2. -01 to -02 793 o revamped document structure to make it agnostic to attachment 794 method (e.g. authentication, address-configuration, etc.). 796 o specified per-MN subnet prefix, and point-to-point link model. 798 o specified support for multicast. 800 o various editorial changes. 802 A.3. -00 to -01 804 o added DHCP access method including DHCP prefix delegation. 806 o added new network reference diagram. 808 o added definitions for NETLMM domain and NLMP. 810 o updated NA proxying method for colliding CGAs. 812 o added text on sending IP multicast messages to a Layer-2 unicast 813 address. 815 o added new Section 4.5 text on MNID/IP address binding. 817 o added new Section 5. on multilink subnet issues. 819 o various editorial changes. 821 Authors' Addresses 823 Julien Laganier 824 DoCoMo Communications Laboratories Europe GmbH 825 Landsberger Strasse 312 826 Munich D-80687 827 Germany 829 Phone: +49 89 56824 231 830 Email: julien.ietf@laposte.net 831 URI: http://www.docomolab-euro.com/ 833 Sathya Narayanan 834 School of Information Technology and Communications Design 835 California State University, Monterey Bay 836 3110, Inter-Garrison Road, Building 18, Room 150 837 Seaside, CA 93955 838 USA 840 Phone: +1 831 582 3621 841 Email: sathya@njit.edu 843 Pete McCann 844 Motorola 845 MD 2240 846 1301 E. Algonquin Rd 847 Schaumburg, IL 60196 848 USA 850 Phone: +1 847 576 3440 851 Email: pete.mccann@motorola.com 853 Full Copyright Statement 855 Copyright (C) The IETF Trust (2008). 857 This document is subject to the rights, licenses and restrictions 858 contained in BCP 78, and except as set forth therein, the authors 859 retain all their rights. 861 This document and the information contained herein are provided on an 862 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 863 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 864 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 865 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 866 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 867 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 869 Intellectual Property 871 The IETF takes no position regarding the validity or scope of any 872 Intellectual Property Rights or other rights that might be claimed to 873 pertain to the implementation or use of the technology described in 874 this document or the extent to which any license under such rights 875 might or might not be available; nor does it represent that it has 876 made any independent effort to identify any such rights. Information 877 on the procedures with respect to rights in RFC documents can be 878 found in BCP 78 and BCP 79. 880 Copies of IPR disclosures made to the IETF Secretariat and any 881 assurances of licenses to be made available, or the result of an 882 attempt made to obtain a general license or permission for the use of 883 such proprietary rights by implementers or users of this 884 specification can be obtained from the IETF on-line IPR repository at 885 http://www.ietf.org/ipr. 887 The IETF invites any interested party to bring to its attention any 888 copyrights, patents or patent applications, or other proprietary 889 rights that may cover technology that may be required to implement 890 this standard. Please address the information to the IETF at 891 ietf-ipr@ietf.org. 893 Acknowledgment 895 Funding for the RFC Editor function is provided by the IETF 896 Administrative Support Activity (IASA).