idnits 2.17.1 draft-ietf-netlmm-proxymip6-12.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 3580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3598. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3604. 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 (April 24, 2008) is 5843 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'RFC-1661' is defined on line 3418, but no explicit reference was found in the text == Unused Reference: 'RFC-3971' is defined on line 3428, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-02 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-07 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG S. Gundavelli (Editor) 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: October 26, 2008 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 April 24, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-12.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on October 26, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 Network-based mobility management enables IP mobility for a host 48 without requiring its participation in any mobility related 49 signaling. The Network is responsible for managing IP mobility on 50 behalf of the host. The mobility entities in the network are 51 responsible for tracking the movements of the host and initiating the 52 required mobility signaling on its behalf. This specification 53 describes a network-based mobility management protocol and is 54 referred to as Proxy Mobile IPv6. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 60 2.1. Conventions used in this document . . . . . . . . . . . . 5 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 9 63 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 15 64 4.1. Peer Authorization Database (PAD) Example Entries . . . . 16 65 4.2. Security Policy Database (SPD) Example Entries . . . . . . 16 66 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 17 67 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 17 68 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 19 69 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 19 70 5.3.1. Processing Binding Registrations . . . . . . . . . . . 19 71 5.3.2. Initial Binding Registration (New Mobility Session) . 22 72 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23 73 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 23 74 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 24 75 5.3.6. Constructing the Proxy Binding Acknowledgement 76 Message . . . . . . . . . . . . . . . . . . . . . . . 24 77 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 27 78 5.4.1. Binding Cache entry lookup considerations . . . . . . 27 79 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 33 80 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36 82 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 36 83 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 37 84 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 38 85 5.9. Route Optimizations Considerations . . . . . . . . . . . . 38 86 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 38 87 6.1. Extensions to Binding Update List Entry Data Structure . . 39 88 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 40 89 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 41 90 6.4. Supported Address Configuration Modes . . . . . . . . . . 41 91 6.5. Access Authentication & Mobile Node Identification . . . . 42 92 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 42 93 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 43 94 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 43 95 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 44 96 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 44 97 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 52 98 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 53 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 53 100 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 54 101 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 54 102 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 55 103 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 56 104 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 56 105 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 56 106 6.11. Supporting DHCPv6 based Address Configuration on the 107 Access Link . . . . . . . . . . . . . . . . . . . . . . . 58 108 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 59 109 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 59 110 6.14. Allowing network access to other IPv6 nodes . . . . . . . 60 111 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 60 112 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 61 113 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 62 114 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 62 115 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 62 116 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 64 117 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 65 118 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 66 119 8.5. Access Technology Type Option . . . . . . . . . . . . . . 67 120 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 69 121 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 70 122 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 71 123 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 71 124 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 73 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 74 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 75 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 76 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 77 129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 77 130 13.2. Informative References . . . . . . . . . . . . . . . . . . 78 131 Appendix A. Proxy Mobile IPv6 interactions with AAA 132 Infrastructure . . . . . . . . . . . . . . . . . . . 79 133 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 79 134 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 80 135 Intellectual Property and Copyright Statements . . . . . . . . . . 82 137 1. Introduction 139 IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. 140 Mobile IPv6 requires client functionality in the IPv6 stack of a 141 mobile node. Exchange of signaling messages between the mobile node 142 and home agent enables the creation and maintenance of a binding 143 between the mobile node's home address and its care-of-address. 144 Mobility as specified in [RFC-3775] requires the IP host to send IP 145 mobility management signaling messages to the home agent, which is 146 located in the network. 148 Network-based mobility is another approach to solving the IP mobility 149 challenge. It is possible to support mobility for IPv6 nodes without 150 host involvement by extending Mobile IPv6 [RFC-3775] signaling 151 messages between a network node and a home agent. This approach to 152 supporting mobility does not require the mobile node to be involved 153 in the exchange of signaling messages between itself and the home 154 agent. A proxy mobility agent in the network performs the signaling 155 with the home agent and does the mobility management on behalf of the 156 mobile node attached to the network. Because of the use and 157 extension of Mobile IPv6 signaling and home agent functionality, this 158 protocol is referred to as Proxy Mobile IPv6 (PMIPv6). 160 Network deployments which are designed to support mobility would be 161 agnostic to the capability in the IPv6 stack of the nodes which it 162 serves. IP mobility for nodes which have mobile IP client 163 functionality in the IPv6 stack as well as those nodes which do not, 164 would be supported by enabling Proxy Mobile IPv6 protocol 165 functionality in the network. The advantages of developing a network 166 based mobility protocol based on Mobile IPv6 are: 168 o Reuse of home agent functionality and the messages/format used in 169 mobility signaling. Mobile IPv6 is a mature protocol with several 170 implementations that have undergone interoperability testing. 172 o A common home agent would serve as the mobility agent for all 173 types of IPv6 nodes. 175 The problem statement and the need for a network based mobility 176 protocol solution has been documented in [RFC-4830]. Proxy Mobile 177 IPv6 is a solution that addresses these issues and requirements. 179 2. Conventions & Terminology 180 2.1. Conventions used in this document 182 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 183 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 184 document are to be interpreted as described in RFC 2119 [RFC-2119]. 186 2.2. Terminology 188 All the general mobility related terms used in this document are to 189 be interpreted as defined in the Mobile IPv6 base specification [RFC- 190 3775]. 192 This document adopts the terms, Local Mobility Anchor (LMA) and 193 Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- 194 4831]. This document also provides the following context specific 195 explanation to the following terms used in this document. 197 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 199 Proxy Mobile IPv6 domain refers to the network where the mobility 200 management of a mobile node is handled using the Proxy Mobile IPv6 201 protocol as defined in this specification. The Proxy Mobile IPv6 202 domain includes local mobility anchors and mobile access gateways 203 between which security associations can be set up and 204 authorization for sending Proxy Binding Updates on behalf of the 205 mobile nodes can be ensured. 207 Local Mobility Anchor (LMA) 209 Local Mobility Anchor is the home agent for the mobile node in the 210 Proxy Mobile IPv6 domain. It is the topological anchor point for 211 the mobile node's home network prefix and is the entity that 212 manages the mobile node's binding state. The local mobility 213 anchor has the functional capabilities of a home agent as defined 214 in Mobile IPv6 base specification [RFC-3775] with the additional 215 capabilities required for supporting Proxy Mobile IPv6 protocol as 216 defined in this specification. 218 Mobile Access Gateway (MAG) 220 Mobile Access Gateway is a function that manages the mobility 221 related signaling for a mobile node that is attached to its access 222 link. It is responsible for tracking the mobile node's movements 223 to and from the access link and for signaling the mobile node's 224 local mobility anchor. 226 Mobile Node (MN) 228 Throughout this document, the term mobile node is used to refer to 229 an IP host or router whose mobility is managed by the network. 230 The mobile node may be an IPv4-only node, IPv6-only node or a 231 dual-stack node and is not required to participate in any IP 232 mobility related signaling for achieving mobility for an IP 233 address that is obtained in that Proxy Mobile IPv6 domain. 235 LMA Address (LMAA) 237 The global address that is configured on the interface of the 238 local mobility anchor and is the transport endpoint of the bi- 239 directional tunnel established between the local mobility anchor 240 and the mobile access gateway. This is the address to where the 241 mobile access gateway sends the Proxy Binding Update messages. 242 When supporting IPv4 traversal, i.e., when the network between the 243 local mobility anchor and the mobile access gateway is an IPv4 244 network, this address will be an IPv4 address and will be referred 245 to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. 247 Proxy Care-of Address (Proxy-CoA) 249 Proxy-CoA is the global address configured on the interface of the 250 mobile access gateway and is the transport endpoint of the tunnel 251 between the local mobility anchor and the mobile access gateway. 252 The local mobility anchor views this address as the Care-of 253 Address of the mobile node and registers it in the Binding Cache 254 entry for that mobile node. When the transport network between 255 the mobile access gateway and the local mobility anchor is an IPv4 256 network and if the care-of address that is registered at the local 257 mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is 258 used, as specified in [ID-IPV4-PMIP6]. 260 Mobile Node's Home Network Prefix (MN-HNP) 262 This is the on-link IPv6 prefix that is always present in the 263 Router Advertisements that the mobile node receives when it is 264 attached to any of the access links in that Proxy Mobile IPv6 265 domain. This home network prefix is topologically anchored at the 266 mobile node's local mobility anchor. The mobile node configures 267 its interface with an address from this prefix. If the mobile 268 node connects to the Proxy Mobile IPv6 domain through multiple 269 interfaces, simultaneously, each of the connected interfaces will 270 be assigned a unique home network prefix and under a different 271 mobility session. 273 Mobile Node's Home Address (MN-HoA) 275 MN-HoA is an address from a mobile node's home network prefix 276 in a Proxy Mobile IPv6 domain. The mobile node will be able to 277 use this address as long as it is attached to the access 278 network that is in the scope of that Proxy Mobile IPv6 domain. 279 Unlike in Mobile IPv6 where the home agent is aware of the home 280 address of the mobile node, in Proxy Mobile IPv6, the mobility 281 entities are only aware of the mobile node's home network 282 prefix and are not always aware of the exact address(es) that 283 the mobile node configured on its interface from that prefix. 284 However, in some configurations and based on the enabled 285 address configuration modes on the access link, the mobility 286 entities in the network can be certain about the exact address 287 configured by the mobile node. 289 Mobile Node's Home Link 291 This is the point-to-point link on which the mobile node obtained 292 its Layer-3 address configuration for the attached interface after 293 it moved into that Proxy Mobile IPv6 domain. This is the link 294 that conceptually follows the mobile node. The network will 295 ensure the mobile node always sees this link with respect to the 296 layer-3 network configuration, on any access link that it attaches 297 to in that Proxy Mobile IPv6 domain. 299 Multihomed Mobile Node 301 A mobile node that connects to the same Proxy Mobile IPv6 domain 302 through more than one interface and uses these interfaces 303 simultaneously is referred to as a multihomed mobile node. 305 Mobile Node Identifier (MN-Identifier) 307 The identity of a mobile node in the Proxy Mobile IPv6 domain. 308 This is the stable identifier of a mobile node that the mobility 309 entities in a Proxy Mobile IPv6 domain can always acquire and use 310 it for predictably identifying a mobile node. This is typically 311 an identifier such as Network Access Identifier (NAI) [RFC-4282] 312 or other identifier such as a Media Access Control (MAC) address. 314 Mobile Node Link-layer Identifier (MN-LL-Identifier) 316 An identifier that identifies the attached interface of a mobile 317 node. For those interfaces that have a link-layer identifier, 318 this identifier can be based on that. The link-layer identifier 319 in some cases is generated by the mobile node and conveyed to the 320 mobile access gateway. This identifier of the attached interface 321 must be stable as seen by any of the mobile access gateways in a 322 given Proxy Mobile IPv6 domain. In some other cases, there might 323 not be any link-layer identifier associated with the mobile node's 324 interface. 326 Policy Profile 328 Policy Profile is an abstract term for referring to a set of 329 configuration parameters that are configured for a given mobile 330 node. The mobility entities in the Proxy Mobile IPv6 domain 331 require access to these parameters for providing the mobility 332 management to a given mobile node. The specific details on how 333 the network entities obtain this policy profile is outside the 334 scope of this document. 336 Proxy Binding Update (PBU) 338 A binding registration request message sent by a mobile access 339 gateway to a mobile node's local mobility anchor for establishing 340 a binding between the mobile node's MN-HNP and the Proxy-CoA. 342 Proxy Binding Acknowledgement (PBA) 344 A binding registration reply message sent by a local mobility 345 anchor in response to a Proxy Binding Update request message that 346 it received from a mobile access gateway. 348 Per-MN-Prefix & Shared-Prefix Models 350 The term, Per-MN-Prefix model, is used to refer to an addressing 351 model where there is an unique network prefix assigned for each 352 node. The term, Shared-Prefix model, is used to refer to an 353 addressing model where the prefix is shared by more than one node. 354 This specification supports the Per-MN-Prefix model and does not 355 support the Shared-Prefix model. 357 ALL_ZERO & NON_ZERO 359 Protocol message fields initialized with value 0 in each byte of 360 the field. Ex: An 8-byte link-layer identifier field with the 361 value set to 0 in each of the 8 bytes, or an IPv6 address with the 362 value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is 363 used to refer to any value other than an ALL_ZERO value. 365 3. Proxy Mobile IPv6 Protocol Overview 367 This specification describes a network-based mobility management 368 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 369 [RFC-3775]. 371 Proxy Mobile IPv6 protocol is intended for providing network-based IP 372 mobility management support to a mobile node, without requiring the 373 participation of the mobile node in any IP mobility related 374 signaling. The mobility entities in the network will track the 375 mobile node's movements and will initiate the mobility signaling and 376 set up the required routing state. 378 The core functional entities in the NETLMM infrastructure are the 379 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 380 local mobility anchor is responsible for maintaining the mobile 381 node's reachability state and is the topological anchor point for the 382 mobile node's home network prefix. The mobile access gateway is the 383 entity that performs the mobility management on behalf of a mobile 384 node and it resides on the access link where the mobile node is 385 anchored. The mobile access gateway is responsible for detecting the 386 mobile node's movements to and from the access link and for 387 initiating binding registrations to the mobile node's local mobility 388 anchor. The architecture of a Proxy Mobile IPv6 domain is shown in 389 Figure 1. 391 +----+ +----+ 392 |LMA1| |LMA2| 393 +----+ +----+ 394 LMAA1 -> | | <-- LMAA2 395 | | 396 \\ //\\ 397 \\ // \\ 398 \\ // \\ 399 +---\\------------- //------\\----+ 400 ( \\ IPv4/IPv6 // \\ ) 401 ( \\ Network // \\ ) 402 +------\\--------//------------\\-+ 403 \\ // \\ 404 \\ // \\ 405 \\ // \\ 406 Proxy-CoA1--> | | <-- Proxy-CoA2 407 +----+ +----+ 408 |MAG1|-----{MN2} |MAG2| 409 +----+ | +----+ 410 | | | 411 MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3 412 {MN1} {MN3} 414 Figure 1: Proxy Mobile IPv6 Domain 416 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 417 an access link, the mobile access gateway on that access link, after 418 identifying the mobile node and acquiring its identity, will 419 determine if the mobile node is authorized for the network-based 420 mobility management service. 422 If the network determines that the network-based mobility management 423 service needs to be offered to that mobile node, the network will 424 ensure that the mobile node using any of the address configuration 425 mechanisms permitted by the network will be able to obtain the 426 address configuration on the connected interface and move anywhere in 427 that Proxy Mobile IPv6 domain. The obtained address configuration 428 includes the address(es) from its home network prefix, the default- 429 router address on the link and other related configuration 430 parameters. From the perspective of the mobile node, the entire 431 Proxy Mobile IPv6 domain appears as a single link, the network 432 ensures that the mobile node believes it is always on the same link 433 where it obtained its initial address configuration, even after 434 changing its point of attachment in that network. 436 The mobile node may be an IPv4-only node, IPv6-only node or a dual 437 IPv4/IPv6 node. Based on what is enabled in the network for that 438 mobile node, the mobile node will be able to obtain an IPv4, IPv6 or 439 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 440 domain. However, the specific details related to the IPv4 addressing 441 or IPv4 transport support are specified in the companion document 442 [ID-IPV4-PMIP6]. 444 If the mobile node connects to the Proxy Mobile IPv6 domain through 445 multiple interfaces and over multiple access networks, the network 446 will allocate a unique home network prefix for each of the connected 447 interfaces. The mobile node will be able to configure an address(es) 448 on those interfaces from the respective home network prefixes. 449 However, if the mobile node performs an inter-interface handoff by 450 moving its address configuration from one interface to the other and 451 if the local mobility anchor receives a handoff hint from the serving 452 mobile access gateway about the same, the local mobility anchor will 453 assign the same home network prefix that it assigned to the 454 previously attached interface. 456 +-----+ +-----+ +-----+ 457 | MN | | MAG | | LMA | 458 +-----+ +-----+ +-----+ 459 | | | 460 MN Attached | | 461 | | | 462 | MN Attached Event from MN/Network | 463 | (Acquire MN-Id and Profile) | 464 | | | 465 |--- Rtr Sol --------->| | 466 | | | 467 | |--- PBU ------------->| 468 | | | 469 | | Accept PBU 470 | | (Allocate MN-HNP, Setup BCE and Tunnel) 471 | | | 472 | |<------------- PBA ---| 473 | | | 474 | Accept PBA | 475 | (Setup Tunnel and Routing) | 476 | | | 477 | |==== Bi-Dir Tunnel ===| 478 | | | 479 |<--------- Rtr Adv ---| | 480 | | | 481 IP Address | | 482 Configuration | | 483 | | | 485 Figure 2: Mobile Node Attachment - Signaling Call Flow 487 Figure 2 shows the signaling call flow when the mobile node enters 488 the Proxy Mobile IPv6 domain. 490 For updating the local mobility anchor about the current location of 491 the mobile node, the mobile access gateway sends a Proxy Binding 492 Update message to the mobile node's local mobility anchor. Upon 493 accepting this Proxy Binding Update message, the local mobility 494 anchor sends a Proxy Binding Acknowledgement message including the 495 mobile node's home network prefix. It also creates the Binding Cache 496 entry and sets up its endpoint of the bi-directional tunnel to the 497 mobile access gateway. 499 The mobile access gateway on receiving the Proxy Binding 500 Acknowledgement message sets up its endpoint of the bi-directional 501 tunnel to the local mobility anchor and also sets up the data path 502 for the mobile node's traffic. At this point the mobile access 503 gateway will have all the required information for emulating the 504 mobile node's home link. It sends Router Advertisement messages to 505 the mobile node on the access link advertising the mobile node's home 506 network prefix as the hosted on-link-prefix. 508 The mobile node on receiving these Router Advertisement messages on 509 the access link will attempt to configure its interface either using 510 stateful or stateless address configuration modes, based on the modes 511 that are permitted on that access link. At the end of a successful 512 address configuration procedure, the mobile node will end up with an 513 address from its home network prefix. 515 Once the address configuration is complete, the mobile node has a 516 valid address from its home network prefix at the current point of 517 attachment. The serving mobile access gateway and the local mobility 518 anchor also have proper routing states for handling the traffic sent 519 to and from the mobile node using an address from its home network 520 prefix. 522 The local mobility anchor, being the topological anchor point for the 523 mobile node's home network prefix, receives any packets that are sent 524 to the mobile node by any node in the network. The local mobility 525 anchor forwards these received packets to the mobile access gateway 526 through the bi-directional tunnel. The mobile access gateway on 527 other end of the tunnel, after receiving the packet, removes the 528 outer header and forwards the packet on the access link to the mobile 529 node. However, in some cases the traffic sent from a correspondent 530 node that is locally connected to the mobile access gateway may not 531 be received by the local mobility anchor and may be routed locally by 532 the mobile access gateway. 534 The mobile access gateway acts as the default router on the access 535 link. Any packet that the mobile node sends to any correspondent 536 node will be received by the mobile access gateway and will be sent 537 to its local mobility anchor through the bi-directional tunnel. The 538 local mobility anchor on the other end of the tunnel, after receiving 539 the packet, removes the outer header and routes the packet to the 540 destination. However in some cases the traffic sent to a 541 correspondent node that is locally connected to the mobile access 542 gateway may be locally routed by the mobile access gateway. 544 +-----+ +-----+ +-----+ +-----+ 545 | MN | |p-MAG| | LMA | |n-MAG| 546 +-----+ +-----+ +-----+ +-----+ 547 | | | | 548 | |==Bi-Dir Tunnel=| | 549 MN Detached | | | 550 | MN Detached Event | | 551 | | | | 552 | |-- DeReg PBU -->| | 553 | | | | 554 | | Accept PBU | 555 | | (Start MinDelayBeforeBCEDelete Timer) 556 | | | | 557 | |<-------- PBA --| | 558 | | | | 559 MN Attached | | | 560 | | | MN Attached event received 561 | | | from MN or from network 562 | | | (Acquire MN-Id and Profile) 563 | | | | 564 |--- Rtr Sol ------------------------------------->| 565 .... 566 Registration steps as in fig 2. 567 .... 568 | | |==Bi-Dir Tunnel=| 569 | | | | 570 |<------------------------------------ Rtr Adv ----| 571 | | | | 572 MN retains HoA/HNP 573 | | | | 575 Figure 3: Mobile Node Handoff - Signaling Call Flow 577 Figure 3 shows the signaling call flow for the mobile node's handoff 578 from previously attached mobile access gateway (p-MAG) to the newly 579 attached mobile access gateway (n-MAG). This call flow reflects only 580 a specific message ordering, it is possible the registration message 581 from the n-MAG may arrive before the de-registration message from the 582 p-MAG arrives. 584 After obtaining the initial address configuration in the Proxy Mobile 585 IPv6 domain, if the mobile node changes its point of attachment, the 586 mobile access gateway on the previous link will detect the mobile 587 node's detachment from the link and will signal the local mobility 588 anchor and will remove the binding and routing state for that mobile 589 node. The local mobility anchor upon receiving this request will 590 identify the corresponding mobility session for which the binding 591 update request was received and once it accepts the request will wait 592 for certain amount of time for allowing the mobile access gateway on 593 the new link to update the binding. However, if it does not receive 594 any binding update request within that given amount of time, it will 595 delete the binding cache entry. 597 The mobile access gateway on the new access link upon detecting the 598 mobile node on its access link will signal the local mobility anchor 599 for updating the binding state. Once that signaling is complete, the 600 mobile node will continue to receive the Router Advertisements 601 containing its home network prefix, making it believe it is still on 602 the same link and it will use the same address configuration on the 603 new access link. 605 4. Proxy Mobile IPv6 Protocol Security 607 The signaling messages, Proxy Binding Update and Proxy Binding 608 Acknowledgement, exchanged between the mobile access gateway and the 609 local mobility anchor MUST be protected using end-to-end security 610 association(s) offering integrity and data origin authentication. 612 The mobile access gateway and the local mobility anchor MUST 613 implement IPsec for protecting the Proxy Mobile IPv6 signaling 614 messages [RFC-4301]. That is, IPsec is a mandatory to implement 615 security mechanism. However, additional documents may specify 616 alternative mechanisms. As in Mobile IPv6 [RFC-3775], the use of 617 IPsec for protecting mobile node's data traffic is optional. 619 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 620 protection SHOULD be used for protecting the signaling messages. 621 Confidentiality protection of these messages is not required. 623 IKEv2 [RFC-4306] SHOULD be used to set up security associations 624 between the mobile access gateway and the local mobility anchor to 625 protect the Proxy Binding Update and Proxy Binding Acknowledgement 626 messages. The mobile access gateway and the local mobility anchor 627 can use any of the authentication mechanisms, as specified in [RFC- 628 4306], for mutual authentication. 630 The Mobile IPv6 specification [RFC-3775] requires the home agent to 631 prevent a mobile node from creating security associations or creating 632 binding cache entries for another mobile node's home address. In the 633 protocol described in this document, the mobile node is not involved 634 in creating security associations for protecting the signaling 635 messages or sending binding updates. Therefore, the local mobility 636 anchor MUST restrict the creation and manipulation of proxy bindings 637 to specifically authorized mobile access gateways and prefixes. The 638 local mobility anchor MUST be locally configurable to authorize such 639 specific combinations. Additional mechanisms such as a policy store 640 or AAA may be employed, but these are outside the scope of this 641 specification. 643 Unlike in Mobile IPv6 [RFC-3775], these signaling messages do not 644 carry either the Home Address destination option or the Type 2 645 Routing header and hence the policy entries and security association 646 selectors stay the same. 648 4.1. Peer Authorization Database (PAD) Example Entries 650 This section describes PAD entries [RFC-4301] on the mobile access 651 gateway and the local mobility anchor. The PAD entries are only 652 example configurations. Note that the PAD is a logical concept and a 653 particular mobile access gateway or a local mobility anchor 654 implementation can implement the PAD in any implementation specific 655 manner. The PAD state may also be distributed across various 656 databases in a specific implementation. 658 mobile access gateway PAD: 659 - IF remote_identity = lma_identity_1 660 Then authenticate (shared secret/certificate/EAP) 661 and authorize CHILD_SA for remote address lma_address_1 663 local mobility anchor PAD: 664 - IF remote_identity = mag_identity_1 665 Then authenticate (shared secret/certificate/EAP) 666 and authorize CHILD_SAs for remote address mag_address_1 668 Figure 4: PAD Entries 670 The list of authentication mechanisms in the above examples is not 671 exhaustive. There could be other credentials used for authentication 672 stored in the PAD. 674 4.2. Security Policy Database (SPD) Example Entries 676 This section describes the security policy entries [RFC-4301] on the 677 mobile access gateway and the local mobility anchor required to 678 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 679 are only example configurations. A particular mobile access gateway 680 or a local mobility anchor implementation could configure different 681 SPD entries as long as they provide the required security. 683 In the examples shown below, the identity of the mobile access 684 gateway is assumed to be mag_1, the address of the mobile access 685 gateway is assumed to be mag_address_1, and the address of the local 686 mobility anchor is assumed to be lma_address_1. 688 mobile access gateway SPD-S: 689 - IF local_address = mag_address_1 & 690 remote_address = lma_address_1 & 691 proto = MH & local_mh_type = BU & remote_mh_type = BA 692 Then use SA ESP transport mode 693 Initiate using IDi = mag_1 to address lma_address_1 695 local mobility anchor SPD-S: 696 - IF local_address = lma_address_1 & 697 remote_address = mag_address_1 & 698 proto = MH & local_mh_type = BA & remote_mh_type = BU 699 Then use SA ESP transport mode 701 Figure 5: SPD Entries 703 5. Local Mobility Anchor Operation 705 The local mobility anchor MUST support the home agent function as 706 defined in [RFC-3775] and additionally the extensions defined in this 707 specification. A home agent with these modifications and enhanced 708 capabilities for supporting the Proxy Mobile IPv6 protocol is 709 referred to as a local mobility anchor. 711 This section describes the operational details of the local mobility 712 anchor. 714 5.1. Extensions to Binding Cache Entry Data Structure 716 Every local mobility anchor MUST maintain a Binding Cache entry for 717 each currently registered mobile node. Binding Cache entry is a 718 conceptual data structure, described in Section 9.1 of [RFC-3775]. 720 For supporting this specification, the Binding Cache Entry data 721 structure needs to be extended with the following additional fields. 723 o A flag indicating whether or not this Binding Cache entry is 724 created due to a proxy registration. This flag is set to value 1 725 for Binding Cache entries that are proxy registrations and is set 726 to value 0 for all other entries. 728 o The identifier of the registered mobile node, MN-Identifier. This 729 identifier is obtained from the Mobile Node Identifier Option 730 [RFC-4283] present in the received Proxy Binding Update request. 732 o The link-layer identifier of the mobile node's connected interface 733 on the access link. This identifier can be acquired from the 734 Mobile Node Link-layer Identifier option, present in the received 735 Proxy Binding Update request. If the option was not present in 736 the request, the value MUST be set to ALL_ZERO. 738 o The Link-local address of the mobile access gateway on the point- 739 to-point link shared with the mobile node. This is generated by 740 the local mobility anchor after accepting the initial Proxy 741 Binding Update request. 743 o The IPv6 home network prefix that is assigned to the mobile node's 744 connected interface. The home network prefix of the mobile node 745 may have been statically configured in the mobile node's policy 746 profile, or, it may have been dynamically allocated by the local 747 mobility anchor. The IPv6 home network prefix also includes the 748 corresponding prefix length. 750 o The tunnel interface identifier (If-Id) of the bi-directional 751 tunnel between the local mobility anchor and the mobile access 752 gateway where the mobile node is currently anchored. This is 753 internal to the local mobility anchor. The tunnel interface 754 identifier is acquired during the tunnel creation. 756 o The access technology type, using which the mobile node is 757 currently attached. This is obtained from the Access Technology 758 Type option, present in the Proxy Binding Update request. 760 o The 64-bit timestamp value of the most recently accepted Proxy 761 Binding Update request sent for this mobile node. This is the 762 time-of-day on the local mobility anchor, when the message was 763 received. If the Timestamp option is not present in the Proxy 764 Binding Update request (i.e., when the sequence number based 765 scheme is in use), the value MUST be set to ALL_ZERO. 767 Typically, the mobile node's home network prefix is the key for 768 locating a Binding Cache entry in all cases except when there has 769 been an handoff of the mobile node's session to a new mobile access 770 gateway and that mobile access gateway is unaware of the home network 771 prefix that was assigned to the handed of session. In such handoff 772 cases, the Binding Cache entry can be located under the 773 considerations specified in Section 5.4.1. 775 5.2. Supported Home Network Prefix Models 777 This specification supports the Per-MN-Prefix model and does not 778 support the Shared-Prefix model. As per the Per-MN-Prefix model, 779 there will be a unique home network prefix assigned to each mobile 780 node and no other node shares an address (other than the Subnet- 781 Router anycast address [RFC-4291] which is used by the mobile access 782 gateway hosting the prefix on that link). The assigned prefix is 783 unique to a mobile node and also unique to a given interface of the 784 mobile node. If the mobile node attaches to the Proxy Mobile IPv6 785 domain through multiple interfaces and simultaneously, each of those 786 connected interfaces will be assigned a different prefix. 788 The mobile node's home network prefix is always hosted on the access 789 link where the mobile node is anchored. Conceptually, the entire 790 home network prefix follows the mobile node as it moves within the 791 Proxy Mobile IPv6 domain. The local mobility anchor is not required 792 to perform any proxy ND operations [RFC-4861] for defending the 793 mobile node's home address on the home link. However, from the 794 routing perspective, the home network prefix is topologically 795 anchored on the local mobility anchor. 797 5.3. Signaling Considerations 799 This section provides the rules for processing the signaling 800 messages. The processing rules specified in this section and other 801 related sections are chained and are in a specific order. When 802 applying these considerations for processing the signaling messages, 803 the specified order MUST be maintained. 805 5.3.1. Processing Binding Registrations 807 1. The received Proxy Binding Update message (a Binding Update 808 message with the 'P' flag set to value of 1, format specified in 809 Section 8.1) MUST be authenticated as described in Section 4. 810 When IPsec is used for message authentication, the SPI in the 811 IPsec header [RFC-4306] of the received packet is needed for 812 locating the security association, for authenticating the Proxy 813 Binding Update message. 815 2. The local mobility anchor MUST observe the rules described in 816 Section 9.2 of [RFC-3775] when processing Mobility Header in the 817 received Proxy Binding Update request. 819 3. The local mobility anchor MUST ignore the check, specified in 820 Section 10.3.1 of [RFC-3775], related to the presence of Home 821 Address destination option in the Proxy Binding Update request. 823 4. The local mobility anchor MUST identify the mobile node from the 824 identifier present in the Mobile Node Identifier option [RFC- 825 4283] of the Proxy Binding Update request. If the Mobile Node 826 Identifier option is not present in the Proxy Binding Update 827 request, the local mobility anchor MUST reject the request and 828 send a Proxy Binding Acknowledgement message with Status field 829 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 830 identifier option) and the identifier in the Mobile Node 831 Identifier Option carried in the message MUST be set to a zero 832 length identifier. 834 5. The local mobility anchor MUST apply the required policy checks, 835 as explained in Section 4, to verify the sender is a trusted 836 mobile access gateway, authorized to send Proxy Binding Update 837 requests on behalf of this mobile node. 839 6. If the local mobility anchor determines that the requesting node 840 is not authorized to send Proxy Binding Update requests for the 841 identified mobile node, it MUST reject the request and send a 842 Proxy Binding Acknowledgement message with Status field set to 843 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 844 binding registrations). 846 7. If the local mobility anchor cannot identify the mobile node 847 based on the identifier present in the Mobile Node Identifier 848 option [RFC-4283] of Proxy Binding Update request, it MUST 849 reject the request and send a Proxy Binding Acknowledgement 850 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 851 (Not local mobility anchor for this mobile node). 853 8. If the local mobility anchor determines that the mobile node is 854 not authorized for the network-based mobility management 855 service, it MUST reject the request and send a Proxy Binding 856 Acknowledgement message with Status field set to 857 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 859 9. The local mobility anchor MUST apply the considerations 860 specified in Section 5.5, for processing the Sequence Number 861 field and the Timestamp option (if present), in the Proxy 862 Binding Update request. 864 10. If the Home Network Prefix option (containing either ALL_ZERO or 865 some prefix value) is not present in the Proxy Binding Update 866 request, the local mobility anchor MUST reject the request and 867 send a Proxy Binding Acknowledgement message with Status field 868 set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network 869 prefix option). 871 11. If the Handoff Indicator option is not present in the Proxy 872 Binding Update request, the local mobility anchor MUST reject 873 the request and send a Proxy Binding Acknowledgement message 874 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 875 (Missing handoff indicator option). 877 12. If the Access Technology Type option is not present in the Proxy 878 Binding Update request, the local mobility anchor MUST reject 879 the request and send a Proxy Binding Acknowledgement message 880 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 881 (Missing access technology type option). 883 13. Considerations specified in Section 5.4.1 MUST be applied for 884 performing the Binding Cache entry existence test. If those 885 checks specified in Section 5.4.1, result in associating the 886 received Proxy Binding Update request to a new mobility session 887 creation request, considerations from Section 5.3.2 (Initial 888 Binding Registration - New Mobility Session), MUST be applied. 889 If those checks result in associating the request to an existing 890 mobility session, the following checks determine the next set of 891 processing rules that needs to be applied. 893 * If the Handoff Indicator field in the Handoff Indicator 894 option present in the request is set to a value of 5 (Handoff 895 state not changed), considerations from Section 5.3.3 896 (Binding Lifetime Extension- No handoff) MUST be applied. 898 * If the received Proxy Binding Update request has the lifetime 899 value of zero, considerations from Section 5.3.5 (Binding De- 900 Registration) MUST be applied. 902 * For all other cases, considerations from Section 5.3.4 903 (Binding Lifetime Extension - After handoff) MUST be applied. 905 14. When sending the Proxy Binding Acknowledgement message with any 906 Status field value, the message MUST be constructed as specified 907 in Section 5.3.6. 909 5.3.2. Initial Binding Registration (New Mobility Session) 911 1. If the Home Network Prefix option present in the Proxy Binding 912 Update request has the value set to ALL_ZERO, the local mobility 913 anchor MUST allocate a prefix and assign it to a new mobility 914 session created for the mobile node. The local mobility anchor 915 MUST ensure the allocated prefix is not in use by any other node 916 or mobility session. 918 2. If the local mobility anchor is unable to allocate any home 919 network prefix for the mobile node, it MUST reject the request 920 and send a Proxy Binding Acknowledgement message with Status 921 field set to 130 (Insufficient resources). 923 3. If the Home Network Prefix option present in the request has a 924 specific prefix value, the local mobility anchor before accepting 925 that request, MUST ensure the prefix is owned by the local 926 mobility anchor and further the mobile node is authorized to use 927 that prefix. If the mobile node is not authorized to use that 928 prefix, the local mobility anchor MUST reject the request and 929 send a Proxy Binding Acknowledgement message with Status field 930 set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not 931 authorized to use that prefix). 933 4. Upon accepting the request, the local mobility anchor MUST create 934 a Binding Cache entry for the mobile node. It must set the 935 fields in the Binding Cache entry to the accepted values for that 936 registration. 938 5. If there is no existing bi-directional tunnel to the mobile 939 access gateway that sent the request, the local mobility anchor 940 MUST establish a bi-directional tunnel to that mobile access 941 gateway. Considerations from Section 5.6.1 MUST be applied for 942 managing the dynamically created bi-directional tunnel. 944 6. The local mobility anchor MUST create a prefix route over the 945 tunnel to the mobile access gateway for forwarding any traffic 946 received for the mobile node's home network prefix. The created 947 tunnel and routing state MUST result in the forwarding behavior 948 on the local mobility anchor as specified in Section 5.6.2. 950 7. The local mobility anchor MUST send the Proxy Binding 951 Acknowledgement message with the Status field set to 0 (Proxy 952 Binding Update Accepted). The message MUST be constructed as 953 specified in Section 5.3.6. 955 5.3.3. Binding Lifetime Extension (No handoff) 957 1. Upon accepting the Proxy Binding Update request for extending the 958 binding lifetime, received from the same mobile access gateway 959 (if the Proxy-CoA address in the Binding Cache entry is the same 960 as the Proxy-CoA address in the request) that last updated the 961 binding, the local mobility anchor MUST update the Binding Cache 962 entry with the accepted registration values. 964 2. The local mobility anchor MUST send the Proxy Binding 965 Acknowledgement message with the Status field set to 0 (Proxy 966 Binding Update Accepted). The message MUST be constructed as 967 specified in Section 5.3.6. 969 5.3.4. Binding Lifetime Extension (After handoff) 971 1. Upon accepting the Proxy Binding Update request for extending the 972 binding lifetime, received from a new mobile access gateway (if 973 the Proxy-CoA address in the Binding Cache entry does not match 974 the Proxy-CoA address in the request) where the mobile node's 975 session is handed off, the local mobility anchor MUST update the 976 Binding Cache entry with the accepted registration values. 978 2. The local mobility anchor MUST remove the previously created 979 route for the mobile node's home network prefix. Additionally, 980 if there are no other mobile node sessions sharing the 981 dynamically created bi-directional tunnel to the previous mobile 982 access gateway, the tunnel MUST be deleted applying 983 considerations from section 5.6.1 (if the tunnel is a dynamically 984 created tunnel and not a fixed pre-established tunnel). 986 3. If there is no existing bi-directional tunnel to the mobile 987 access gateway that sent the request, the local mobility anchor 988 MUST establish a bi-directional tunnel to that mobile access 989 gateway. Considerations from Section 5.6.1 MUST be applied for 990 managing the dynamically created bi-directional tunnel. 992 4. The local mobility anchor MUST create a prefix route over the 993 tunnel to the mobile access gateway for forwarding any traffic 994 received for the mobile node's home network prefix. The created 995 tunnel and routing state MUST result in the forwarding behavior 996 on the local mobility anchor as specified in Section 5.6.2. 998 5. The local mobility anchor MUST send the Proxy Binding 999 Acknowledgement message with the Status field set to 0 (Proxy 1000 Binding Update Accepted). The message MUST be constructed as 1001 specified in Section 5.3.6. 1003 5.3.5. Binding De-Registration 1005 1. If the received Proxy Binding Update request with the lifetime 1006 value of zero, has a Source Address in the IPv6 header (or the 1007 address in the Alternate Care-of Address option, if the option is 1008 present) different from what is present in the Proxy-CoA address 1009 field in the Binding Cache entry, the local mobility anchor MUST 1010 ignore the request. 1012 2. Upon accepting the Proxy Binding Update request with the lifetime 1013 value of zero, the local mobility anchor MUST wait for 1014 MinDelayBeforeBCEDelete amount of time, before it deletes the 1015 Binding Cache entry. However, it MUST send the Proxy Binding 1016 Acknowledgement message with the Status field set to 0 (Proxy 1017 Binding Update Accepted). The message MUST be constructed as 1018 specified in Section 5.3.6. 1020 * During this wait period, the local mobility anchor SHOULD drop 1021 the mobile node's data traffic. 1023 * During this wait period, if the local mobility anchor receives 1024 a valid Proxy Binding Update request for the same mobility 1025 session with the lifetime value of greater than zero, and if 1026 that request is accepted, then the Binding Cache entry MUST 1027 NOT be deleted, but must be updated with the newly accepted 1028 registration values and additionally the wait period should be 1029 ended. 1031 * By the end of this wait period, if the local mobility anchor 1032 did not receive any valid Proxy Binding Update request for 1033 this mobility session, then it MUST delete the Binding Cache 1034 entry and remove the routing state created for that mobility 1035 session. 1037 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1039 o The local mobility anchor when sending the Proxy Binding 1040 Acknowledgement message to the mobile access gateway MUST 1041 construct the message as specified below. 1043 IPv6 header (src=LMAA, dst=Proxy-CoA) 1044 Mobility header 1045 - BA /* P flag must be set to value of 1 */ 1046 Mobility Options 1047 - Mobile Node Identifier Option (mandatory) 1048 - Home Network Prefix option (mandatory) 1049 - Handoff Indicator option (mandatory) 1050 - Access Technology Type option (mandatory) 1051 - Timestamp Option (optional) 1052 - Mobile Node Link-layer Identifier option (optional) 1053 - Link-local Address option (optional) 1055 Figure 6: Proxy Binding Acknowledgement message format 1057 o The Source Address field in the IPv6 header of the message MUST be 1058 set to the destination address of the received Proxy Binding 1059 Update request. 1061 o The Destination Address field in the IPv6 header of the message 1062 MUST be set to the source address of the received Proxy Binding 1063 Update request. When there is no Alternate Care-of Address option 1064 present in the request, the destination address is the same as the 1065 Proxy-CoA address, otherwise, the address may not be the same as 1066 the Proxy-CoA. 1068 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1069 identifier field in the option MUST be copied from the Mobile Node 1070 Identifier option in the received Proxy Binding Update request. 1071 If the option was not present in the request, the identifier in 1072 the option MUST be set to a zero length identifier. 1074 o The Home Network Prefix option MUST be present. 1076 * If the Status field is set to a value greater than or equal to 1077 128, i.e., if the binding request is rejected, then the prefix 1078 value in the Home Network Prefix option MUST be set to the 1079 prefix value in the Home Network Prefix option of the received 1080 Proxy Binding Update request. But, if the option was not 1081 present in the request, the value in the option MUST be set to 1082 ALL_ZERO. 1084 * For all other cases, the prefix value in the option MUST be set 1085 to the allocated prefix value for that mobility session. 1087 o The Handoff Indicator option MUST be present. The handoff 1088 indicator field in the option MUST be copied from the Handoff 1089 Indicator option in the received Proxy Binding Update request. If 1090 the option was not present in the request, the value in the option 1091 MUST be set to zero. 1093 o The Access Technology Type option MUST be present. The access 1094 technology type field in the option MUST be copied from the Access 1095 Technology Type option in the received Proxy Binding Update 1096 request. If the option was not present in the request, the value 1097 in the option MUST be set to zero. 1099 o The Timestamp option MUST be present, if the same option was 1100 present in the received Proxy Binding Update request. 1101 Considerations from Section 5.5 must be applied for constructing 1102 the Timestamp option. 1104 o The Mobile Node Link-layer Identifier option MUST be present, if 1105 the same option was present in the received Proxy Binding Update 1106 request. The link-layer identifier value MUST be copied from the 1107 Mobile Node Link-layer Identifier option present in the received 1108 Proxy Binding Update request. 1110 o The Link-local Address option MUST be present, if the same option 1111 was present in the received Proxy Binding Update request. 1113 * If the received Proxy Binding Update request has the Link-local 1114 Address option with any value other than ALL_ZERO, the same 1115 value MUST be copied to the Link-local Address field of the 1116 Binding Cache entry and it must also be copied to the Link- 1117 local Address option in the reply. 1119 * If there is no existing Binding Cache entry (i.e., if this is a 1120 request for a new mobility session), then the local mobility 1121 anchor MUST generate the link-local address that the mobile 1122 access gateway can use on the point-to-point link shared with 1123 the mobile node and the same must be copied to the Link-local 1124 Address field of the Binding Cache entry and it must also be 1125 copied to the Link-local Address option in the reply. 1127 * For all other cases, the link-local address in the option MUST 1128 be copied from the Link-local Address field of the Binding 1129 Cache entry. 1131 o If IPsec is used for protecting the signaling messages, the 1132 message MUST be protected, using the security association existing 1133 between the local mobility anchor and the mobile access gateway. 1135 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1136 NOT be present in the IPv6 header of the packet. 1138 5.4. Multihoming Support 1140 This specification allows mobile nodes to connect to a Proxy Mobile 1141 IPv6 domain through multiple interfaces for simultaneous access. 1142 Following are the key aspects of this multihoming support. 1144 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1145 multiple interfaces for simultaneous access, the local mobility 1146 anchor MUST allocate a unique home network prefix for each of the 1147 connected interfaces. 1149 o The local mobility anchor MUST manage each of the allocated home 1150 network prefixes as part of a separate mobility session, each 1151 under a separate Binding Cache entry and with its own lifetime. 1153 o The local mobility anchor MUST allow for an handoff between two 1154 different interfaces of the mobile node. In such a scenario, the 1155 home network prefix that is associated with a specific link-layer 1156 identifier of the mobile node will be updated with the new link- 1157 layer identifier. The decision on when to create a new mobility 1158 session and when to update an existing mobility session MUST be 1159 based on the Handover hint present in the Proxy Binding Update 1160 message and under the considerations specified in this section. 1162 5.4.1. Binding Cache entry lookup considerations 1164 There can be multiple Binding Cache entries for a given mobile node. 1165 When doing a lookup for a mobile node's Binding Cache entry for 1166 processing a received Proxy Binding Update request message, the local 1167 mobility anchor MUST apply the following multihoming considerations 1168 (in the below specified order). These rules are chained with the 1169 processing rules specified in Section 5.3. 1171 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1172 request 1174 +=====================================================================+ 1175 | Registration/De-Registration Message | 1176 +=====================================================================+ 1177 | HNP (NON_ZERO Value) | 1178 +=====================================================================+ 1179 | ATT | 1180 +=====================================================================+ 1181 | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | 1182 +=====================================================================+ 1183 | HI | 1184 +==================================+==================================+ 1185 | BCE Lookup Key: (Home Network Prefix) | 1186 +=====================================================================+ 1188 Figure 7: BCE lookup using home network prefix 1190 1. The local mobility anchor MUST verify if there is an existing 1191 Binding Cache entry with the home network prefix value matching 1192 the prefix value in the Home Network Prefix option of the 1193 received Proxy Binding Update request. [BCE(HNP) equals 1194 PBU(HNP)] 1196 2. If there does not exist a Binding Cache entry (matching the MN- 1197 HNP), the request MUST be considered as a request for creating a 1198 new mobility session. 1200 3. If there exists a Binding Cache entry (matching MN-HNP), and if 1201 the mobile node identifier in the entry does not match the mobile 1202 node identifier in the Mobile Node Identifier option of the 1203 received Proxy Binding Update request, the local mobility anchor 1204 MUST reject the request with the Status field value set to 1205 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1206 authorized for the requesting home network prefix). [BCE(MN- 1207 Identifier) not equals PBU(MN-Identifier)] 1209 4. If there exists a Binding Cache entry (matching MN-Identifier and 1210 MN-HNP) and if any one or more of these below stated conditions 1211 match, the request MUST be considered as a request for updating 1212 that Binding Cache entry. [BCE(MN-Identifier) equals PBU(MN- 1213 Identifier)] 1214 * If there is a Mobile Node Link-layer Identifier option present 1215 in the request, and if the link-layer identifier value in that 1216 option matches the link-layer identifier value in the Binding 1217 Cache entry and the access technology type field in the Access 1218 Technology Type option present in the request matches the 1219 access technology type in the Binding Cache entry. [BCE(ATT, 1220 MN-LL-Identifier) equals PBU(ATT, MN-LL-Identifier)] 1222 * If the Handoff Indicator field in the Handoff Indicator option 1223 present in the request is set to a value of 2 (Handoff between 1224 two different interfaces of the mobile node). [PBU(HI) equals 1225 2] 1227 * If there is no Mobile Node Link-layer Identifier option 1228 present in the request, the link-layer identifier value in the 1229 Binding Cache entry is set to ALL_ZERO, the access technology 1230 type field in the Access Technology Type option present in the 1231 request matches the access technology type in the Binding 1232 Cache entry and if the Handoff Indicator field in the Handoff 1233 Indicator option present in the request is set to a value of 3 1234 (Handoff between mobile access gateways for the same 1235 interface). 1237 * If the Proxy-CoA address in the Binding Cache entry matches 1238 the source address of the request (or the address in the 1239 alternate Care-of Address option, if the option is present) 1240 and if the access technology type field in the Access 1241 Technology Type option present in the request matches the 1242 access technology type in the Binding Cache entry. 1243 [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)]. 1245 5. For all other cases, the message MUST be considered as a request 1246 for creating a new mobility session. 1248 5.4.1.2. Mobile Node Link-layer Identifier Option present in the 1249 request 1251 +=====================================================================+ 1252 | Registration/De-Registration Message | 1253 +=====================================================================+ 1254 | HNP (ALL_ZERO Value) | 1255 +=====================================================================+ 1256 | ATT | 1257 +=====================================================================+ 1258 | MN-LL-Identifier Option Present (NON_ZERO Value) | 1259 +=====================================================================+ 1260 | HI | 1261 +==================================+==================================+ 1262 | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | 1263 +=====================================================================+ 1265 Figure 8: BCE Lookup using Link-layer Identifier 1267 1. The local mobility anchor MUST verify if there is an existing 1268 Binding Cache entry, with the mobile node identifier matching the 1269 identifier in the received Mobile Node Identifier option, access 1270 technology type matching the value in the received Access 1271 Technology Type option and the link-layer identifier value 1272 matching the identifier in the received Mobile Node Link-layer 1273 Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier) 1274 equals PBU(MN-Identifier, ATT, MN-LL-Identifier)] 1276 2. If there exists a Binding Cache entry (matching MN-Identifier, 1277 ATT and MN-LL-Identifier), the request MUST be considered as a 1278 request for updating that Binding Cache entry. 1280 3. If there does not exist a Binding Cache entry (matching MN- 1281 Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator 1282 field in the Handoff Indicator option present in the request is 1283 set to a value of 2 (Handoff between two different interfaces of 1284 the mobile node). The local mobility anchor MUST apply the 1285 following additional considerations. [PBU(HI) equals 2] 1287 * The local mobility anchor MUST verify if there exists one and 1288 only one Binding Cache entry with the mobile node identifier 1289 matching the identifier in the Mobile Node Identifier option 1290 present in the request and for any link-layer identifier 1291 value. If there exists only one such entry (matching the MN- 1292 Identifier), the request MUST be considered as a request for 1293 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1294 PBU(MN-Identifier)] 1296 4. If there does not exist a Binding Cache entry (matching MN- 1297 Identifier, ATT and MN-LL-Identifier) and if the Handoff 1298 Indicator field in the Handoff Indicator option present in the 1299 request is set to a value of 4 (Handoff state unknown), the local 1300 mobility anchor MUST apply the following additional 1301 considerations. 1303 * The local mobility anchor MUST verify if there exists one and 1304 only one Binding Cache entry with the mobile node identifier 1305 matching the identifier in the Mobile Node Identifier option 1306 present in the request and for any link-layer identifier 1307 value. If there exists only one such entry (matching the MN- 1308 Identifier), the local mobility anchor SHOULD wait till the 1309 existing Binding Cache entry is de-registered by the 1310 previously serving mobile access gateway, before the request 1311 can be considered as a request for updating that Binding Cache 1312 entry. However, if there is no de-registration message that 1313 is received within MaxDelayBeforeNewBCEAssign amount of time, 1314 the local mobility anchor upon accepting the request MUST 1315 consider the request as a request for creating a new mobility 1316 session. The local mobility anchor MAY also choose to create 1317 a new mobility session and without waiting for a de- 1318 registration message and this should be configurable on the 1319 local mobility anchor. 1321 5. For all other cases, the message MUST be considered as a request 1322 for creating a new mobility session. 1324 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 1325 request 1327 +=====================================================================+ 1328 | Registration/De-Registration Message | 1329 +=====================================================================+ 1330 | HNP (ALL_ZERO Value) | 1331 +=====================================================================+ 1332 | ATT | 1333 +=====================================================================+ 1334 | MN-LL-Identifier Option Not Present | 1335 +=====================================================================+ 1336 | HI | 1337 +==================================+==================================+ 1338 | BCE Lookup Key: (MN-Identifier) | 1339 +=====================================================================+ 1341 Figure 9: BCE Lookup using Mobile Node Identifier 1343 1. The local mobility anchor MUST verify if there exists one and 1344 only one Binding Cache entry with the mobile node identifier 1345 matching the identifier in the Mobile Node Identifier option 1346 present in the request. 1348 2. If there exists only one such entry (matching the MN-Identifier) 1349 and the Handoff Indicator field in the Handoff Indicator option 1350 present in the request is set to a value of 2 (Handoff between 1351 two different interfaces of the mobile node), the request MUST be 1352 considered as a request for updating that Binding Cache entry. 1353 [PBU(HI) equals 2] 1355 3. If there exists only one such entry (matching the MN-Identifier) 1356 and the Handoff Indicator field in the Handoff Indicator option 1357 present in the request is set to a value of 4 (Handoff state 1358 unknown), the local mobility anchor SHOULD wait till the existing 1359 Binding Cache entry is de-registered by the previously serving 1360 mobile access gateway, before the request can be considered as a 1361 request for updating that Binding Cache entry. However, if there 1362 is no de-registration message that is received within 1363 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1364 anchor upon accepting the request MUST consider the request as a 1365 request for creating a new mobility session. The local mobility 1366 anchor MAY also choose to create a new mobility session and 1367 without waiting for a de-registration message and this should be 1368 configurable on the local mobility anchor. 1370 4. For all other cases, the message MUST be considered as a request 1371 for creating a new mobility session. 1373 5.5. Timestamp Option for Message Ordering 1375 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1376 registration messages as a way for the home agent to process the 1377 binding updates in the order they were sent by a mobile node. The 1378 home agent and the mobile node are required to manage this counter 1379 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1380 the mobile node moves from one mobile access gateway to another and 1381 in the absence of mechanisms such as context transfer between the 1382 mobile access gateways, the serving mobile access gateway will be 1383 unable to determine the sequence number that it needs to use in the 1384 signaling messages. Hence, the sequence number scheme, as specified 1385 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1387 If the local mobility anchor cannot determine the sending order of 1388 the received binding registration messages, it may potentially 1389 process an older message sent by a mobile access gateway where the 1390 mobile node was previously anchored, resulting in an incorrect 1391 Binding Cache entry. 1393 For solving this problem, this specification adopts two alternative 1394 solutions. One is based on timestamps and the other based on 1395 sequence numbers, as defined in [RFC-3775]. 1397 The basic principle behind the use of timestamps in binding 1398 registration messages is that the node generating the message inserts 1399 the current time-of-day, and the node receiving the message checks 1400 that this timestamp is greater than all previously accepted 1401 timestamps. The timestamp based solution may be used when the 1402 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1403 have the ability to obtain the last sequence number that was sent in 1404 a binding registration message for updating a given mobile node's 1405 binding. 1407 As an alternative to the Timestamp based approach, the specification 1408 also allows the use of Sequence Number based scheme, as specified in 1409 [RFC-3775]. However, for this scheme to work, the serving mobile 1410 access gateways in a Proxy Mobile IPv6 domain MUST have the ability 1411 to obtain the last sequence number that was sent in a binding 1412 registration message for updating a given mobile node's binding. The 1413 sequence number MUST be maintained on a per mobile node basis and 1414 MUST be synchronized between the serving mobile access gateways. 1416 This may be achieved by using context transfer schemes or by 1417 maintaining the sequence number in a policy store. However, the 1418 specific details on how the mobile node's sequence number is 1419 synchronized between different mobile access gateways is outside the 1420 scope of this document. 1422 Using the Timestamps based approach: 1424 1. A local mobility anchor implementation MUST support the Timestamp 1425 option. If the Timestamp option is present in the received Proxy 1426 Binding Update request message, then the local mobility anchor 1427 MUST include a valid Timestamp option in the Proxy Binding 1428 Acknowledgement message that it sends to the mobile access 1429 gateway. 1431 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1432 exchanging binding registration messages using the Timestamp 1433 option MUST have adequately synchronized time-of-day clocks. 1434 This is the essential requirement for this solution to work. If 1435 this requirement is not met, the solution will not predictably 1436 work in all cases. 1438 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1439 synchronize their clocks to a common time source. For 1440 synchronizing the clocks, the nodes MAY use the Network Time 1441 Protocol [RFC-4330]. Deployments MAY also adopt other approaches 1442 suitable for that specific deployment. Alternatively, if there 1443 is mobile node generated timestamp that is increasing at every 1444 attachment to the access link and if that timestamp is available 1445 to the mobile access gateway (Ex: The timestamp option in the 1446 SEND messages that the mobile node sends), the mobile access 1447 gateway can use this timestamp or sequence number in the Proxy 1448 Binding Update messages and does not have to depend on any 1449 external clock source. However, the specific details on how this 1450 is achieved is outside the scope of this document. 1452 4. When generating the timestamp value for building the Timestamp 1453 option, the mobility entities MUST ensure that the generated 1454 timestamp is the elapsed time past the same reference epoch, as 1455 specified in the format for the Timestamp option (Section 8.8). 1457 5. If the Timestamp option is present in the received Proxy Binding 1458 Update message, the local mobility anchor MUST ignore the 1459 sequence number field in the message. However, it MUST copy the 1460 sequence number from the received Proxy Binding Update message to 1461 the Proxy Binding Acknowledgement message. 1463 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1464 option, the local mobility anchor MUST check the timestamp field 1465 for validity. In order for it to be considered valid, the 1466 timestamp value contained in the Timestamp option MUST be close 1467 enough (within TimestampValidityWindow amount of time difference) 1468 to the local mobility anchor's time-of-day clock and the 1469 timestamp MUST be greater than all previously accepted timestamps 1470 in the Proxy Binding Update messages sent for that mobile node. 1472 7. If the timestamp value in the received Proxy Binding Update is 1473 valid (validity as specified in the above considerations), the 1474 local mobility anchor MUST return the same timestamp value in the 1475 Timestamp option included in the Proxy Binding Acknowledgement 1476 message that it sends to the mobile access gateway. 1478 8. If the timestamp value in the received Proxy Binding Update is 1479 lower than the previously accepted timestamp in the Proxy Binding 1480 Update messages sent for that mobility binding, the local 1481 mobility anchor MUST reject the Proxy Binding Update request and 1482 send a Proxy Binding Acknowledgement message with Status field 1483 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1484 previously accepted timestamp). The message MUST also include 1485 the Timestamp option with the value set to the current time-of- 1486 day on the local mobility anchor. 1488 9. If the timestamp value in the received Proxy Binding Update is 1489 not valid (validity as specified in the above considerations), 1490 the local mobility anchor MUST reject the Proxy Binding Update 1491 and send a Proxy Binding Acknowledgement message with Status 1492 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1493 message MUST also include the Timestamp option with the value set 1494 to the current time-of-day on the local mobility anchor. 1496 Using the Sequence Number based approach: 1498 1. If the Timestamp option is not present in the received Proxy 1499 Binding Update request, the local mobility anchor MUST fall back 1500 to the Sequence Number based scheme. It MUST process the 1501 sequence number field as specified in [RFC-3775]. Also, it MUST 1502 NOT include the Timestamp option in the Proxy Binding 1503 Acknowledgement messages that it sends to the mobile access 1504 gateway. 1506 2. An implementation MUST support the Sequence Number based scheme, 1507 as specified in [RFC-3775]. 1509 3. The Sequence Number based approach can be used only when there is 1510 some mechanism (such as context transfer procedure between mobile 1511 access gateways) that allows the serving mobile access gateway to 1512 obtain the last sequence number that was sent in a binding 1513 registration message for updating a given mobile node's binding. 1515 5.6. Routing Considerations 1517 5.6.1. Bi-Directional Tunnel Management 1519 The bi-directional tunnel MUST be used for routing the mobile node's 1520 data traffic between the mobile access gateway and the local mobility 1521 anchor. A tunnel hides the topology and enables a mobile node to use 1522 an address from its home network prefix from any access link in that 1523 Proxy Mobile IPv6 domain. A tunnel may be created dynamically when 1524 needed and removed when not needed. However, implementations MAY 1525 choose to use static pre-established tunnels instead of dynamically 1526 creating and tearing them down on a need basis. The following 1527 considerations MUST be applied when using dynamic tunnels. 1529 o A bi-directional tunnel MUST be established between the local 1530 mobility anchor and the mobile access gateway with IP-in-IP 1531 encapsulation, as described in [RFC-2473]. The tunnel end points 1532 are the Proxy-CoA and LMAA. When using IPv4 transport, the end 1533 points of the tunnel are the IPv4-LMAA and IPv4-Proxy-CoA, as 1534 specified in [ID-IPV4-PMIP6]. 1536 o Implementations can use a software timer for managing the tunnel 1537 lifetime and a counter for keeping a count of all the mobile nodes 1538 that are sharing the tunnel. The timer value can be set to the 1539 accepted binding lifetime and can be updated after each periodic 1540 re-registration for extending the lifetime. If the tunnel is 1541 shared for multiple mobile nodes, the tunnel lifetime must be set 1542 to the highest binding lifetime that is granted to any one of 1543 those mobile nodes sharing that tunnel. 1545 o The tunnel MUST be deleted when either the tunnel lifetime expires 1546 or when there are no mobile nodes sharing the tunnel. 1548 5.6.2. Forwarding Considerations 1550 Intercepting Packets Sent to the Mobile Node's Home Network: 1552 o When the local mobility anchor is serving a mobile node, it MUST 1553 be able to receive packets that are sent to the mobile node's home 1554 network. In order for it to receive those packets, it MUST 1555 advertise a connected route in to the Routing Infrastructure for 1556 the mobile node's home network prefix or for an aggregated prefix 1557 with a larger scope. This essentially enables IPv6 routers in 1558 that network to detect the local mobility anchor as the last-hop 1559 router for that prefix. 1561 Forwarding Packets to the Mobile Node: 1563 o On receiving a packet from a correspondent node with the 1564 destination address matching a mobile node's home network prefix, 1565 the local mobility anchor MUST forward the packet through the bi- 1566 directional tunnel set up for that mobile node. The format of the 1567 tunneled packet is shown below. Considerations from [RFC-2473] 1568 MUST be applied for IPv6 encapsulation. However, when using IPv4 1569 transport, the format of the packet is as described in [ID-IPV4- 1570 PMIP6]. 1572 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1573 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1574 Upper layer protocols /* Packet Content*/ 1576 Figure 10: Tunneled Packets from LMA to MAG 1578 Forwarding Packets Sent by the Mobile Node: 1580 o All the reverse tunneled packets that the local mobility anchor 1581 received from the mobile access gateway, after removing the tunnel 1582 header MUST be routed to the destination specified in the inner 1583 packet header. These routed packets will have the source address 1584 field set to the mobile node's home address. Considerations from 1585 [RFC-2473] MUST be applied for IPv6 decapsulation. 1587 5.7. Local Mobility Anchor Address Discovery 1589 Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 1590 10.5 of [RFC-3775], allows a mobile node to discover all the home 1591 agents on its home link by sending an ICMP Home Agent Address 1592 Discovery Request message to the Mobile IPv6 Home-Agents anycast 1593 address, derived from its home network prefix. 1595 The DHAAD message in the current form cannot be used in Proxy Mobile 1596 IPv6 for discovering the address of the mobile node's local mobility 1597 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1598 able to receive any messages sent to the Mobile IPv6 Home-Agents 1599 anycast address corresponding to the mobile node's home network 1600 prefix, as the prefix is not hosted on any of its interfaces. 1601 Further, the mobile access gateway will not predictably be able to 1602 locate the serving local mobility anchor that has the mobile node's 1603 binding cache entry. Hence, this specification does not support 1604 Dynamic Home Agent Address Discovery protocol. 1606 In Proxy Mobile IPv6, the address of the local mobility anchor 1607 configured to serve a mobile node can be discovered by the mobility 1608 entities in other ways. This may be a configured entry in the mobile 1609 node's policy profile, or it may be obtained through mechanisms 1610 outside the scope of this document. 1612 5.8. Mobile Prefix Discovery Considerations 1614 This specification does not support mobile prefix discovery. The 1615 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1616 applicable to Proxy Mobile IPv6. 1618 5.9. Route Optimizations Considerations 1620 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1621 enables a mobile node to communicate with a correspondent node 1622 directly using its care-of address and further the Return Routability 1623 procedure enables the correspondent node to have reasonable trust 1624 that the mobile node is reachable at both its home address and 1625 care-of address. 1627 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1628 mobility related signaling. The mobile node uses only its home 1629 address for all its communication and the Care-of address (Proxy-CoA) 1630 is not visible to the mobile node. Hence, the Return Routability 1631 procedure as defined in Mobile IPv6 [RFC-3775] cannot be used in 1632 Proxy Mobile IPv6. 1634 6. Mobile Access Gateway Operation 1636 The Proxy Mobile IPv6 protocol described in this document introduces 1637 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1638 access gateway is the entity that is responsible for detecting the 1639 mobile node's movements to and from the access link and sending the 1640 binding registration requests to the local mobility anchor. In 1641 essence, the mobile access gateway performs mobility management on 1642 behalf of a mobile node. 1644 The mobile access gateway is a function that typically runs on an 1645 access router. However, implementations MAY choose to split this 1646 function and run it across multiple systems. The specifics on how 1647 that is achieved or the signaling interactions between those 1648 functional entities are beyond the scope of this document. 1650 The mobile access gateway has the following key functional roles: 1652 o It is responsible for detecting the mobile node's movements on the 1653 access link and for initiating the mobility signaling with the 1654 mobile node's local mobility anchor. 1656 o Emulation of the mobile node's home link on the access link by 1657 sending Router Advertisements with the mobile node's home network 1658 prefix information. 1660 o Responsible for setting up the data path for enabling the mobile 1661 node to configure an address from its home network prefix and use 1662 it from its access link. 1664 6.1. Extensions to Binding Update List Entry Data Structure 1666 Every mobile access gateway MUST maintain a Binding Update List. 1667 Each entry in the Binding Update List represents a mobile node's 1668 mobility binding with its local mobility anchor. The Binding Update 1669 List is a conceptual data structure, described in Section 11.1 of 1670 [RFC-3775]. 1672 For supporting this specification, the conceptual Binding Update List 1673 entry data structure needs be extended with the following additional 1674 fields. 1676 o The Identifier of the attached mobile node, MN-Identifier. This 1677 identifier is acquired during the mobile node's attachment to the 1678 access link through mechanisms outside the scope of this document. 1680 o The link-layer identifier of the mobile node's connected 1681 interface. This can be acquired from the received Router 1682 Solicitation messages from the mobile node or during the mobile 1683 node's attachment to the access network. This is typically a 1684 Link-layer identifier conveyed by the mobile node; however, the 1685 specific details on how that is conveyed is out of scope for this 1686 specification. If this identifier is not available, the value 1687 MUST be set to ALL_ZERO. 1689 o The IPv6 home network prefix of the attached mobile node. The 1690 home network prefix of the mobile node is acquired from the mobile 1691 node's local mobility anchor through the received Proxy Binding 1692 Acknowledgement messages. The IPv6 home network prefix also 1693 includes the corresponding prefix length. 1695 o The Link-local address of the mobile node on the interface 1696 attached to the access link. 1698 o The IPv6 address of the local mobility anchor serving the attached 1699 mobile node. This address is acquired from the mobile node's 1700 policy profile or from other means. 1702 o The interface identifier (If-Id) of the point-to-point link 1703 between the mobile node and the mobile access gateway. This is 1704 internal to the mobile access gateway and is used to associate the 1705 Proxy Mobile IPv6 tunnel to the access link where the mobile node 1706 is attached. 1708 o The tunnel interface identifier (If-Id) of the bi-directional 1709 tunnel between the mobile node's local mobility anchor and the 1710 mobile access gateway. This is internal to the mobile access 1711 gateway. The tunnel interface identifier is acquired during the 1712 tunnel creation. 1714 6.2. Mobile Node's Policy Profile 1716 A mobile node's policy profile contains the essential operational 1717 parameters that are required by the network entities for managing the 1718 mobile node's mobility service. These policy profiles are stored in 1719 a local or a remote policy store. The mobile access gateway and the 1720 local mobility anchor MUST be able to obtain a mobile node's policy 1721 profile. The policy profile MAY also be handed over to a serving 1722 mobile access gateway as part of a context transfer procedure during 1723 a handoff or the serving mobile access gateway MAY be able to 1724 dynamically generate this profile. The exact details on how this 1725 achieved is outside the scope of this document. However, this 1726 specification requires that a mobile access gateway serving a mobile 1727 node MUST have access to its policy profile. 1729 The following are the mandatory fields of the policy profile: 1731 o The mobile node's identifier (MN-Identifier) 1733 o The IPv6 address of the local mobility anchor (LMAA) 1735 The following are the optional fields of the policy profile: 1737 o The mobile node's IPv6 home network prefix (MN-HNP) 1738 o The mobile node's IPv6 home network Prefix lifetime 1740 o Supported address configuration procedures (Stateful, Stateless or 1741 both) for the mobile node in the Proxy Mobile IPv6 domain 1743 6.3. Supported Access Link Types 1745 This specification supports only point-to-point access link types and 1746 thus it assumes that the mobile node and the mobile access gateway 1747 are the only two nodes on the access link. The link is assumed to 1748 have multicast capability. This protocol may also be used on other 1749 link types, as long as the link is configured in such a way that it 1750 guarantees a point-to-point delivery between the mobile node and the 1751 mobile access gateway for all the protocol traffic. 1753 6.4. Supported Address Configuration Modes 1755 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1756 more global IPv6 addresses on its interface using Stateless, Stateful 1757 or manual address autoconfiguration procedures. The Router 1758 Advertisement messages sent on the access link specify the address 1759 configuration methods permitted on that access link for that mobile 1760 node. However, the advertised flags with respect to the address 1761 configuration will be consistent for a mobile node, on any of the 1762 access links in that Proxy Mobile IPv6 domain. Typically, these 1763 configuration settings will be based on the domain wide policy or 1764 based on a policy specific to each mobile node. 1766 When stateless address autoconfiguration is supported on the access 1767 link, the mobile node can generate one or more IPv6 addresses by 1768 standard IPv6 mechanisms such as Stateless Autoconfiguration [RFC- 1769 4862] or Privacy extensions [RFC-4941]. 1771 When stateful address autoconfiguration is supported on the link, the 1772 mobile node can obtain the address configuration from the DHCPv6 1773 server located in the Proxy Mobile IPv6 domain, by standard DHCPv6 1774 mechanisms, as specified in [RFC-3315]. The obtained address will be 1775 from its respective home network prefix. Section 6.11 specifies the 1776 details on how this configuration can be achieved. 1778 Additionally, other address configuration mechanisms specific to the 1779 access link between the mobile node and the mobile access gateway may 1780 also be used for pushing the address configuration to the mobile 1781 node. This specification does not change the behavior of address 1782 configuration mechanisms in any way. 1784 6.5. Access Authentication & Mobile Node Identification 1786 When a mobile node attaches to an access link connected to the mobile 1787 access gateway, the deployed access security protocols on that link 1788 SHOULD ensure that the network-based mobility management service is 1789 offered only after authenticating and authorizing the mobile node for 1790 that service. The exact specifics on how this is achieved or the 1791 interactions between the mobile access gateway and the access 1792 security service is outside the scope of this document. This 1793 specification goes with the stated assumption of having an 1794 established trust between the mobile node and the mobile access 1795 gateway, before the protocol operation begins. 1797 6.6. Acquiring Mobile Node's Identifier 1799 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1800 to identify a mobile node, using its MN-Identifier. This identifier 1801 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 1802 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 1803 this identifier in the signaling messages and unambiguously identify 1804 a given mobile node. Following are some of the considerations 1805 related to this MN-Identifier. 1807 o The MN-Identifier is typically obtained as part of the access 1808 authentication or from a notified network attachment event. In 1809 cases where the user identifier authenticated during access 1810 authentication uniquely identifies a mobile node, the MN- 1811 Identifier MAY be the same as the user identifier. However, the 1812 user identifier MUST NOT be used if it identifies a user account 1813 that can be used from more than one mobile node operating in the 1814 same Proxy Mobile IPv6 domain. 1816 o In some cases, the obtained identifier as part of the access 1817 authentication can be a temporary identifier and further that 1818 temporary identifier may be different at each re-authentication. 1819 However, the mobile access gateway MUST be able to use this 1820 temporary identifier and obtain the mobile node's stable 1821 identifier from the policy store. For instance, in AAA-based 1822 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1823 4372] may be used, as long as it uniquely identifies a mobile 1824 node, and not a user account that can be used with multiple mobile 1825 nodes. 1827 o In some cases and for privacy reasons, the MN-Identifier that the 1828 policy store delivers to the mobile access gateway may not be the 1829 true identifier of the mobile node. However, the mobility access 1830 gateway MUST be able to use this identifier in the signaling 1831 messages exchanged with the local mobility anchor. 1833 o The mobile access gateway MUST be able to identify the mobile node 1834 by its MN-Identifier and it MUST be able to associate this 1835 identity to the point-to-point link shared with the mobile node. 1837 6.7. Home Network Emulation 1839 One of the key functions of a mobile access gateway is to emulate the 1840 mobile node's home network on the access link. It must ensure, the 1841 mobile node believes it is still connected to its home link or on the 1842 link where it obtained its initial address configuration after it 1843 moved into that Proxy Mobile IPv6 domain. 1845 For emulating the mobile node's home link on the access link, the 1846 mobile access gateway must be able to send Router Advertisements 1847 advertising the mobile node's home network prefix and other address 1848 configuration parameters consistent with its home link properties. 1849 Typically, these configuration settings will be based on the domain 1850 wide policy or based on a policy specific to each mobile node. 1852 Typically, the mobile access gateway learns the mobile node's home 1853 network prefix information from the received Proxy Binding 1854 Acknowledgement message or it may be obtained from the mobile node's 1855 policy profile. However, the mobile access gateway SHOULD send the 1856 Router Advertisements advertising the mobile node's home network 1857 prefix only after successfully completing the binding registration 1858 with the mobile node's local mobility anchor. 1860 When advertising the home network prefix in the Router Advertisement 1861 messages, the mobile access gateway MAY set the prefix lifetime value 1862 for the advertised prefix to any chosen value at its own discretion. 1863 An implementation MAY choose to tie the prefix lifetime to the mobile 1864 node's binding lifetime. The prefix lifetime can also be an optional 1865 configuration parameter in the mobile node's policy profile. 1867 6.8. Link-Local and Global Address Uniqueness 1869 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1870 mobile access gateway to the other, will continue to detect its home 1871 network and thus believe it is still on the same link. Every time 1872 the mobile node attaches to a new link, the event related to the 1873 interface state change will trigger the mobile node to perform DAD 1874 operation on the link-local and global addresses. However, if the 1875 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 1876 detect the link change due to DNAv6 optimizations and may not trigger 1877 the duplicate address detection (DAD) procedure for its existing 1878 addresses, which may potentially lead to address collisions after the 1879 mobile node's handoff to a new link. 1881 The issue of address collision is not relevant to the mobile node's 1882 global address(es). Since there is a unique home network prefix 1883 assigned for each mobile node, no other node shares an address (other 1884 than Subnet-Router anycast address which is configured by the mobile 1885 access gateway) from that prefix and so the uniqueness for the mobile 1886 node's global address is assured on the access link. 1888 The issue of address collision is however relevant to the mobile 1889 node's link-local addresses since the mobile access gateway and the 1890 mobile node will have link-local addresses configured from the same 1891 link-local prefix (FE80::/64). This leaves a room for link-local 1892 address collision between the two neighbors (i.e., the mobile node 1893 and the mobile access gateway) on that access link. For solving this 1894 problem, this specification requires that the link-local address that 1895 the mobile access gateway configures on the point-to-point link 1896 shared with a given mobile node be generated by the local mobility 1897 anchor and be stored in the mobile node's Binding Cache entry. This 1898 address will not change for the duration of that mobile node's 1899 session and can be provided to the serving mobile access gateway at 1900 every mobile node's handoff, as part of the Proxy Mobile IPv6 1901 signaling messages. The specific method by which the local mobility 1902 anchor generates the link-local addresses is out of scope for this 1903 specification. 1905 Optionally, implementations MAY choose to configure a fixed link- 1906 local address across all the access links in a Proxy Mobile IPv6 1907 domain and without a need for carrying this address from the local 1908 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 1909 signaling messages. 1911 6.9. Signaling Considerations 1913 6.9.1. Binding Registrations 1915 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 1917 1. After detecting a new mobile node on its access link, the mobile 1918 access gateway MUST identify the mobile node and acquire its MN- 1919 Identifier. If it determines that the network-based mobility 1920 management service needs to be offered to the mobile node, it 1921 MUST send a Proxy Binding Update message to the local mobility 1922 anchor. 1924 2. The Proxy Binding Update message MUST include the Mobile Node 1925 Identifier option [RFC-4283], carrying the MN-Identifier for 1926 identifying the mobile node. 1928 3. The Home Network Prefix option MUST be present in the Proxy 1929 Binding Update message. If the mobile access gateway learns the 1930 mobile node's home network prefix either from its policy store 1931 or from other means, the mobile access gateway MAY choose to 1932 specify the same in the Home Network Prefix option for 1933 requesting the local mobility anchor to allocate that prefix, 1934 otherwise it MUST specify a value of ALL_ZERO. If the specified 1935 value is ALL_ZERO, then the local mobility anchor will do the 1936 prefix assignment. 1938 4. The Handoff Indicator option MUST be present in the Proxy 1939 Binding Update message. The Handoff Indicator field in the 1940 Handoff Indicator option MUST be set to a value indicating the 1941 handoff hint. 1943 * The Handoff Indicator field MUST be set to value 1 1944 (Attachment over a new interface), if the mobile access 1945 gateway determines (under the Handoff Indicator 1946 considerations specified in this section) that the mobile 1947 node's current attachment to the network over this interface 1948 is not as a result of a handoff of an existing mobility 1949 session (over the same interface or through a different 1950 interface), but as a result of an attachment over a new 1951 interface. This essentially serves as a request to the local 1952 mobility anchor to create a new mobility session and not 1953 update any existing Binding Cache entry created for the same 1954 mobile node connected to the Proxy Mobile IPv6 domain through 1955 a different interface. 1957 * The Handoff Indicator field MUST be set to value 2 (Handoff 1958 between two different interfaces of the mobile node), if the 1959 mobile access gateway definitively knows the mobile node's 1960 current attachment is due to a handoff of an existing 1961 mobility session, between two different interfaces of the 1962 mobile node. 1964 * The Handoff Indicator field MUST be set to value 3 (Handoff 1965 between mobile access gateways for the same interface), if 1966 the mobile access gateway definitively knows the mobile 1967 node's current attachment is due to a handoff of an existing 1968 mobility session between two mobile access gateways and for 1969 the same interface of the mobile node. 1971 * The Handoff Indicator field MUST be set to value 4 (Handoff 1972 state unknown), if the mobile access gateway cannot determine 1973 if the mobile node's current attachment is due to a handoff 1974 of an existing mobility session. 1976 5. The mobile access gateway MUST apply the below considerations 1977 when choosing the value for the Handoff Indicator field. 1979 * The mobile access gateway can choose to use the value 2 1980 (Handoff between two different interfaces of the mobile 1981 node), only when it knows that the mobile node has on purpose 1982 switched from one interface to another, and the previous 1983 interface is going to be disabled. It may know this due to a 1984 number of factors. For instance, most cellular networks have 1985 controlled handovers where the network knows that the host is 1986 moving from one attachment to another. In this situation the 1987 link layer mechanism can inform the mobility functions that 1988 this is indeed a movement, not a new attachment. 1990 * Some link layers have link-layer identifiers that can be used 1991 to distinguish (a) the movement of a particular interface to 1992 a new attachment from (b) the attachment of a new interface 1993 from the same host. Option value 3 (Handoff between mobile 1994 access gateways for the same interface)is appropriate in case 1995 a and value of 1 (Attachment over a new interface) in case b. 1997 * The mobile access gateway MUST NOT set the option value to 2 1998 (Handoff between two different interfaces of the mobile node) 1999 or 3 (Handoff between mobile access gateways for the same 2000 interface) if it can not be determined that the mobile node 2001 can move the address between the interfaces involved in the 2002 handover or that it is the same interface that has moved. 2003 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2004 physical interfaces to the same domain may suffer unexpected 2005 failures. 2007 * Where no support from the link layer exists, the host and the 2008 network would need to inform each other about the intended 2009 movement. The Proxy Mobile IPv6 protocol does not specify 2010 this and simply requires that knowledge about movements can 2011 be derived either from the link-layer or from somewhere else. 2012 The method by which this is accomplished is outside the scope 2013 of this specification. 2015 6. Either the Timestamp option or a valid sequence number 2016 maintained on a per mobile node basis (if the Sequence Number 2017 based scheme is in use) MUST be present. When Timestamp option 2018 is added to the message, the mobile access gateway SHOULD also 2019 set the Sequence Number field to a value of a monotonically 2020 increasing counter (not to be confused with the per mobile node 2021 sequence number specified in [RFC-3775]). The local mobility 2022 anchor will ignore this field when there is a Timestamp option 2023 present in the request, but will return the same value in the 2024 Proxy Binding Acknowledgement message. This will be useful for 2025 matching the reply to the request message. 2027 7. The Mobile Node Link-layer Identifier option carrying the link- 2028 layer identifier of the currently attached interface MUST be 2029 present in the Proxy Binding Update message, if the mobile 2030 access gateway is aware of the same. If the link-layer 2031 identifier of the currently attached interface is not known or 2032 if the identifier value is ALL_ZERO, this option MUST NOT be 2033 present. 2035 8. The Access Technology Type option MUST be present in the Proxy 2036 Binding Update message. The access technology type field in the 2037 option SHOULD be set to the type of access technology using 2038 which the mobile node is currently attached to the mobile access 2039 gateway. 2041 9. The Link-local Address option MAY be present in the Proxy 2042 Binding Update message. Considerations from Section 6.8 MUST be 2043 applied when using the link-local address option. 2045 * When querying the local mobility anchor for the link-local 2046 address that it should use on the point-to-point link shared 2047 with the mobile node, this option MUST be set to ALL_ZERO. 2048 This essentially serves as a request to the local mobility 2049 anchor to return the link-local address of the mobile access 2050 gateway stored in the binding cache entry associated with 2051 this mobility session. 2053 * When uploading the link-local address to the local mobility 2054 anchor, the value in the option MUST be set to the link-local 2055 address that is configured on the point-to-point link shared 2056 with the mobile node. This is allowed only during an initial 2057 mobile node's attachment. 2059 10. The Proxy Binding Update message MUST be constructed as 2060 specified in Section 6.9.1.5. 2062 11. If there is no existing Binding Update List entry for that 2063 mobile node, the mobile access gateway MUST create a Binding 2064 Update List entry for the mobile node upon sending the Proxy 2065 Binding Update request. 2067 6.9.1.2. Receiving Binding Registration Reply 2069 On receiving a Proxy Binding Acknowledgement message (format 2070 specified in Section 8.2) from the local mobility anchor, the mobile 2071 access gateway MUST process the message as specified below. 2073 1. The received Proxy Binding Acknowledgement message (a Binding 2074 Acknowledgement message with the 'P' flag set to value of 1) 2075 MUST be authenticated as described in Section 4. When IPsec is 2076 used for message authentication, the SPI in the IPsec header 2077 [RFC-4306] of the received packet is needed for locating the 2078 security association, for authenticating the Proxy Binding 2079 Acknowledgement message. 2081 2. The mobile access gateway MUST observe the rules described in 2082 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2083 the received Proxy Binding Acknowledgement message. 2085 3. The mobile access gateway MUST apply the considerations 2086 specified in Section 5.5 for processing the Sequence Number 2087 field and the Timestamp option (if present), in the message. 2089 4. The mobile access gateway MUST ignore any checks, specified in 2090 [RFC-3775] related to the presence of a Type 2 Routing header in 2091 the Proxy Binding Acknowledgement message. 2093 5. The mobile access gateway MAY use the mobile node identifier 2094 present in the Mobile Node Identifier option for matching the 2095 response to the request messages that it sent recently. 2096 However, if there is more than one request message in its 2097 request queue for the same mobile node, the sequence number 2098 field can be used for identifying the exact message from those 2099 messages. There are other ways to achieve this and 2100 implementations are free to adopt the best approach that suits 2101 their implementation. Additionally, if the received Proxy 2102 Binding Acknowledgement message does not match any of the Proxy 2103 Binding Update messages that it sent recently, the message MUST 2104 be ignored. 2106 6. If the received Proxy Binding Acknowledgement message has any 2107 one or more of the following options, Handoff Indicator option, 2108 Access Technology Type option, Mobile Node Link-layer Identifier 2109 option, Mobile Node Identifier option, carrying option values 2110 that are different from the option values present in the 2111 corresponding request (Proxy Binding Update) message, the 2112 message MUST be ignored as the local mobility anchor is expected 2113 to echo back all these listed options and with the same option 2114 values in the reply message. Further, the mobile access gateway 2115 MUST NOT retransmit the Proxy Binding Update message till an 2116 administrative action is taken. 2118 7. If the received Proxy Binding Acknowledgement message has the 2119 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2120 registration not enabled for the mobile node), the mobile access 2121 gateway SHOULD NOT send binding registration requests again for 2122 that mobile node. It MUST deny the mobility service to that 2123 mobile node. 2125 8. If the received Proxy Binding Acknowledgement message has the 2126 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2127 (Timestamp value lower than previously accepted value), the 2128 mobile access gateway SHOULD try to register again to reassert 2129 the mobile node's presence on its access link. The mobile 2130 access gateway is not specifically required to synchronize its 2131 clock upon receiving this error code. 2133 9. If the received Proxy Binding Acknowledgement message has the 2134 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2135 value), the mobile access gateway SHOULD try to register again 2136 only after it has synchronized its clock to a common time source 2137 that is used by all the mobility entities in that domain for 2138 their clock synchronization. The mobile access gateway SHOULD 2139 NOT synchronize its clock to the local mobility anchor's system 2140 clock, based on the timestamp present in the received message. 2142 10. If the received Proxy Binding Acknowledgement message has the 2143 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2144 (mobile node is not authorized for the requesting home network 2145 prefix), the mobile access gateway SHOULD NOT request for the 2146 same prefix again, but can request the local mobility anchor to 2147 dynamically assign a prefix, by specifying a ALL_ZERO value in 2148 the Home Network Prefix option carried in the subsequent Proxy 2149 Binding Update message. 2151 11. If the received Proxy Binding Acknowledgement message has the 2152 Status field value set to any value greater than or equal to 128 2153 (i.e., if the binding is rejected), the mobile access gateway 2154 MUST NOT advertise the mobile node's home network prefix in the 2155 Router Advertisements sent on that access link and MUST deny the 2156 mobility service to the mobile node by not forwarding any 2157 packets using the source address from that home network prefix 2158 and originating from that point-to-point link. 2160 12. If the received Proxy Binding Acknowledgement message has the 2161 Status field value set to 0 (Proxy Binding Update accepted), the 2162 mobile access gateway MUST update the routing state, as 2163 explained in section 6.10, and MUST also update the Binding 2164 Update List entry for reflecting the accepted binding 2165 registration status. 2167 13. If the received Proxy Binding Acknowledgement message has the 2168 address in the Link-local Address option set to a NON_ZERO 2169 value, the mobile access gateway MUST configure that link-local 2170 address on that point-to-point link and MUST NOT configure any 2171 other link-local address on that point-to-point link. This will 2172 avoid any link-local address collisions on that access link. 2174 6.9.1.3. Extending Binding Lifetime 2176 1. For extending the lifetime of a currently registered mobile node 2177 (i.e., after a successful initial binding registration from the 2178 same mobile access gateway), the mobile access gateway can send a 2179 Proxy Binding Update message to the local mobility anchor with a 2180 new lifetime value. This re-registration message MUST be 2181 constructed with the same set of options as the initial binding 2182 registration message, under the considerations specified in 2183 Section 6.9.1.1. However the following exceptions apply. 2185 2. The prefix value in the Home Network Prefix option MUST be set to 2186 the currently assigned home network prefix. 2188 3. The Handoff Indicator field in the Handoff Indicator option MUST 2189 be set to a value of 5 (Handoff state not changed - Re- 2190 Registration). 2192 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2194 1. If at any point the mobile access gateway detects that the mobile 2195 node has moved away from its access link, or if it decides to 2196 terminate the mobile node's mobility session, it SHOULD send a 2197 Proxy Binding Update message to the local mobility anchor with 2198 the lifetime value set to zero. This de-registration message 2199 MUST be constructed with the same set of options as the initial 2200 binding registration message, under the considerations specified 2201 in Section 6.9.1.1. However, the following exceptions apply. 2203 2. The prefix value in the Home Network Prefix option MUST be set to 2204 the currently assigned home network prefix. 2206 3. The Handoff Indicator field in the Handoff Indicator option MUST 2207 be set to a value of 4 (Handoff state unknown). 2209 Either upon receipt of a Proxy Binding Acknowledgement message from 2210 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2211 timeout waiting for the reply, the mobile access gateway MUST do the 2212 following: 2214 1. It MUST remove the Binding Update List entry for the mobile node 2215 from its Binding Update List. 2217 2. It MUST remove the created routing state for tunneling the mobile 2218 node's traffic. 2220 3. If there is a dynamically created tunnel to the mobile node's 2221 local mobility anchor and if there are not other mobile nodes for 2222 which the tunnel is being used, then the tunnel MUST be deleted. 2224 4. It MUST tear down the point-to-point link shared with the mobile 2225 node. This action will force the mobile node to remove any IPv6 2226 address configuration on the interface connected to this point- 2227 to-point link. 2229 6.9.1.5. Constructing the Proxy Binding Update Message 2231 o The mobile access gateway when sending the Proxy Binding Update 2232 request to the local mobility anchor MUST construct the message as 2233 specified below. 2235 IPv6 header (src=Proxy-CoA, dst=LMAA) 2236 Mobility header 2237 - BU /* P & A flags MUST be set to value 1 */ 2238 Mobility Options 2239 - Mobile Node Identifier option (mandatory) 2240 - Home Network Prefix option (mandatory) 2241 - Handoff Indicator option (mandatory) 2242 - Access Technology Type option (mandatory) 2243 - Timestamp option (optional) 2244 - Mobile Node Link-layer Identifier option (optional) 2245 - Link-local Address option (optional) 2247 Figure 11: Proxy Binding Update message format 2249 o The Source Address field in the IPv6 header of the message MUST be 2250 set to the global address configured on the egress interface of 2251 the mobile access gateway. When there is no Alternate Care-of 2252 Address option present in the request, this address will be 2253 considered as the Proxy-CoA address for this binding registration 2254 request. However, when there is Alternate Care-of Address option 2255 present in the request, this address will be not be considered as 2256 the Proxy-CoA address, but the address in the alternate Care-of 2257 Address option will be considered as the Proxy-CoA address. 2259 o The Destination Address field in the IPv6 header of the message 2260 MUST be set to the local mobility anchor address. 2262 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2264 o The Home Network Prefix option MUST be present. 2266 o The Handoff Indicator option MUST be present. 2268 o The Access Technology Type option MUST be present. 2270 o The Timestamp option MAY be present. 2272 o The Mobile Node Link-layer Identifier option MAY be present. 2274 o The Link-local Address option MAY be present. 2276 o If IPsec is used for protecting the signaling messages, the 2277 message MUST be protected, using the security association existing 2278 between the local mobility anchor and the mobile access gateway. 2280 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2281 3775] MUST NOT be present in the IPv6 Destination Options 2282 extension header of the Proxy Binding Update message. 2284 6.9.2. Router Solicitation Messages 2286 A mobile node may send a Router Solicitation message on the access 2287 link shared with the mobile access gateway. The Router Solicitation 2288 message that the mobile node sends is as specified in [RFC-4861]. 2289 The mobile access gateway on receiving the Router Solicitation 2290 message or before sending a Router Advertisement message MUST apply 2291 the following considerations. 2293 1. The mobile access gateway on receiving the Router Solicitation 2294 message SHOULD send a Router Advertisement containing the mobile 2295 node's home network prefix as the on-link prefix. However, 2296 before sending the Router Advertisement message containing the 2297 mobile node's home network prefix, it SHOULD complete the binding 2298 registration process with the mobile node's local mobility 2299 anchor. 2301 2. If the local mobility anchor rejects the binding registration 2302 request, or, if the mobile access gateway failed to complete the 2303 binding registration process for whatever reason, the mobile 2304 access gateway MUST NOT advertise the mobile node's home network 2305 prefix in the Router Advertisement messages that it sends on the 2306 access link. However, it MAY choose to advertise a local visited 2307 network prefix to enable the mobile node for regular IPv6 access. 2309 3. The mobile access gateway SHOULD add the MTU option, as specified 2310 in [RFC-4861], to the Router Advertisement messages that it sends 2311 on the access link. This will ensure the mobile node on the link 2312 uses the advertised MTU value. The MTU value MUST reflect the 2313 tunnel MTU for the bi-directional tunnel between the mobile 2314 access gateway and the local mobility anchor. 2316 6.9.3. Default-Router 2318 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2319 router for the mobile node on the access link, as it is the entity 2320 that sends the Router Advertisements on the access link. However, as 2321 the mobile node moves from one access link to another, the serving 2322 mobile access gateway on those respective links will send the Router 2323 Advertisements. If these Router Advertisements are sent using a 2324 different link-local address or a different link-layer address, the 2325 mobile node will always detect a new default-router after every 2326 handoff. For solving this problem, this specification requires all 2327 the mobile access gateways in the Proxy Mobile IPv6 domain to use the 2328 same link-local and link-layer address on any of the access links 2329 where ever the mobile node attaches. The link-layer address can be a 2330 fixed address across that all the mobile access gateways can use on 2331 any of the point-to-point links. However, the link-local address can 2332 be an address provided by the local mobility anchor, or a fixed 2333 address. 2335 6.9.4. Retransmissions and Rate Limiting 2337 The mobile access gateway is responsible for retransmissions and rate 2338 limiting the binding registration requests that it sends to the local 2339 mobility anchor. The Retransmission and the Rate Limiting rules are 2340 as specified in [RFC-3775]. However, the following considerations 2341 MUST be applied. 2343 1. When the mobile access gateway sends a Proxy Binding Update 2344 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2345 [RFC-3775], for configuring the retransmission timer, as 2346 specified in Section 11.8 [RFC-3775]. However, the mobile access 2347 gateway is not required to use a longer retransmission interval 2348 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2349 the initial binding registration request. 2351 2. If the mobile access gateway fails to receive a valid matching 2352 response for a registration or re-registration message within the 2353 retransmission interval, it SHOULD retransmit the message until a 2354 response is received. However, the mobile access gateway MUST 2355 ensure the mobile node is still attached to the connected link 2356 before retransmitting the message. 2358 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2359 gateway MUST use an exponential back-off process in which the 2360 timeout period is doubled upon each retransmission, until either 2361 the node receives a response or the timeout period reaches the 2362 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2363 MAY continue to send these messages at this slower rate 2364 indefinitely. 2366 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2367 Binding Update messages MUST use the latest timestamp. If the 2368 Sequence number scheme is in use, the retransmitted Proxy Binding 2369 Update messages MUST use a Sequence Number value greater than 2370 that used for the previous transmission of this Proxy Binding 2371 Update message, just as specified in [RFC-3775]. 2373 6.10. Routing Considerations 2375 This section describes how the mobile access gateway handles the 2376 traffic to/from the mobile node that is attached to one of its access 2377 interfaces. 2379 Proxy-CoA LMAA 2380 | | 2381 +--+ +---+ +---+ +--+ 2382 |MN|----------|MAG|======================|LMA|----------|CN| 2383 +--+ +---+ +---+ +--+ 2384 IPv6 Tunnel 2386 Figure 12: Proxy Mobile IPv6 Tunnel 2388 6.10.1. Transport Network 2390 As per this specification, the transport network between the local 2391 mobility anchor and the mobile access gateway is an IPv6 network. 2392 The companion document [ID-IPV4-PMIP6] specifies the required 2393 extensions for negotiating IPv4 transport and the corresponding 2394 encapsulation mode. 2396 6.10.2. Tunneling & Encapsulation Modes 2398 Each IPv6 address that a mobile node uses from its home network 2399 prefix is topologically anchored at the local mobility anchor. For a 2400 mobile node to use this address from an access network attached to a 2401 mobile access gateway, proper tunneling techniques have to be in 2402 place. Tunneling hides the network topology and allows the mobile 2403 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2404 packet and to be routed between the local mobility anchor and the 2405 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2406 defines the use of IPv6-over-IPv6 tunneling, between the home agent 2407 and the mobile node and this specification extends the use of the 2408 same tunneling mechanism between the local mobility anchor and the 2409 mobile access gateway. 2411 On most operating systems, a tunnel is implemented as a virtual 2412 point-to-point interface. The source and the destination address of 2413 the two end points of this virtual interface along with the 2414 encapsulation mode are specified for this virtual interface. Any 2415 packet that is routed over this interface gets encapsulated with the 2416 outer header and the addresses as specified for that point to point 2417 tunnel interface. For creating a point to point tunnel to any local 2418 mobility anchor, the mobile access gateway may implement a tunnel 2419 interface with the source address field set to its Proxy-CoA address 2420 and the destination address field set to the LMA address. 2422 The following is the supported packet encapsulation mode that can be 2423 used by the mobile access gateway and the local mobility anchor for 2424 routing mobile node's IPv6 datagrams. 2426 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2427 2473]. 2429 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2430 modes for supporting IPv4 transport. 2432 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2433 details on how this mode is negotiated is specified in [ID-IPV4- 2434 PMIP6]. 2436 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2437 packet. This mode is specified in [ID-IPV4-PMIP6]. 2439 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2440 packet with a TLV header. This mode is specified in [ID-IPV4- 2441 PMIP6]. 2443 6.10.3. Local Routing 2445 If there is data traffic between a visiting mobile node and a 2446 correspondent node that is locally attached to an access link 2447 connected to the mobile access gateway, the mobile access gateway MAY 2448 optimize on the delivery efforts by locally routing the packets and 2449 by not reverse tunneling them to the mobile node's local mobility 2450 anchor. The configuration variable, EnableMAGLocalRouting MAY be 2451 used for controlling this aspect. However, in some systems, this may 2452 have an implication on the mobile node's accounting and policy 2453 enforcement as the local mobility anchor is not in the path for that 2454 traffic and it will not be able to apply any traffic policies or do 2455 any accounting for those flows. 2457 This decision of path optimization SHOULD be based on the policy 2458 configured on the mobile access gateway, but enforced by the mobile 2459 node's local mobility anchor. The specific details on how this is 2460 achieved are beyond of the scope of this document. 2462 6.10.4. Tunnel Management 2464 All the considerations mentioned in Section 5.6.1 for the tunnel 2465 management on the local mobility anchor apply for the mobile access 2466 gateway as well. 2468 6.10.5. Forwarding Rules 2470 Forwarding Packets sent to the Mobile Node's Home Network: 2472 o On receiving a packet from the bi-directional tunnel established 2473 with the mobile node's local mobility anchor, the mobile access 2474 gateway MUST use the destination address of the inner packet for 2475 forwarding it on the interface where the destination network 2476 prefix is hosted. The mobile access gateway MUST remove the outer 2477 header before forwarding the packet. Considerations from [RFC- 2478 2473] MUST be applied for IPv6 decapsulation. If the mobile 2479 access gateway cannot find the connected interface for that 2480 destination address, it MUST silently drop the packet. For 2481 reporting an error in such a scenario, in the form of ICMP control 2482 message, the considerations from [RFC-2473] must be applied. 2484 o On receiving a packet from a correspondent node that is locally 2485 connected and which is destined to a mobile node that is on 2486 another locally connected access link, the mobile access gateway 2487 MUST check the configuration variable, EnableMAGLocalRouting, to 2488 ensure the mobile access gateway is allowed to route the packet 2489 directly to the mobile node. If the mobile access gateway is not 2490 allowed to route the packet directly, it MUST route the packet 2491 through the bi-directional tunnel established between itself and 2492 the mobile node's local mobility anchor. Otherwise, it can route 2493 the packet directly to the mobile node. 2495 Forwarding Packets Sent by the Mobile Node: 2497 o On receiving a packet from a mobile node connected to its access 2498 link, the mobile access gateway MUST ensure that there is an 2499 established binding for that mobile node with its local mobility 2500 anchor before forwarding the packet directly to the destination or 2501 before tunneling the packet to the mobile node's local mobility 2502 anchor. 2504 o On receiving a packet from a mobile node connected to its access 2505 link to a destination that is locally connected, the mobile access 2506 gateway MUST check the configuration variable, 2507 EnableMAGLocalRouting, to ensure the mobile access gateway is 2508 allowed to route the packet directly to the destination. If the 2509 mobile access gateway is not allowed to route the packet directly, 2510 it MUST route the packet through the bi-directional tunnel 2511 established between itself and the mobile node's local mobility 2512 anchor. Otherwise, it can route the packet directly to the 2513 destination. 2515 o On receiving a packet from the mobile node connected to its access 2516 link, to a destination that is not directly connected, the packet 2517 MUST be forwarded to the local mobility anchor through the bi- 2518 directional tunnel established between itself and the mobile 2519 node's local mobility anchor. However, the packets that are sent 2520 with the link-local source address MUST NOT be forwarded. 2522 o The format of the tunneled packet is shown below. Considerations 2523 from [RFC-2473] MUST be applied for IPv6 encapsulation. 2524 Additionally, when using IPv4 transport, the format of the 2525 tunneled packet is as described in [ID-IPV4-PMIP6]. 2527 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2528 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2529 Upper layer protocols /* Packet Content*/ 2531 Figure 13: Tunneled Packets from MAG to LMA 2533 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2535 This section explains how Stateful Address Configuration using DHCPv6 2536 can be enabled on the point-to-point link between the mobile node and 2537 the mobile access gateway and how a mobile node attached to that link 2538 can obtain an address from its home network prefix and using DHCPv6. 2540 o For supporting Stateful Address Configuration using DHCPv6, the 2541 DHCPv6 relay agent [RFC-3315] service MUST be configured on each 2542 of the mobile access gateways in the Proxy Mobile IPv6 domain. 2543 Further, as specified in Section 20 of [RFC-3315], the DHCPv6 2544 relay agent should be configured to use a list of destination 2545 addresses, which MAY include unicast addresses, the 2546 All_DHCP_Servers multicast address, or other addresses selected by 2547 the network administrator. 2549 o A DHCPv6 server in the Proxy Mobile IPv6 domain can be configured 2550 with a set of prefixes (P1, P2, ..., Pn). Each one of these 2551 prefixes in this prefix list is a home network prefix that the 2552 local mobility anchor(s) can assign to any mobile node. However, 2553 the DHCPv6 server will not know the relation between a given 2554 prefix and a mobile node to which the corresponding prefix is 2555 allocated. It just views these prefixes as hosted prefixes on 2556 different links in that domain and assigns individual addresses 2557 from the respective prefixes based on the prefix value present in 2558 the link-address option of the received DHCPv6 request. 2560 o When a mobile node sends a DHCPv6 request message, the DHCPv6 2561 relay agent function on the mobile access gateway will set the 2562 link-address field in the DHCPv6 message to an address in the 2563 mobile node's home network prefix. The address is generated as 2564 per [RFC-4862] by combining the mobile node's home network prefix 2565 (assigned by the local mobility anchor for this mobility session) 2566 and its own interface identifier on the access link shared with 2567 the mobile node, so as to provide a prefix hint to the DHCPv6 2568 Server for the prefix selection. The DHCPv6 server on receiving 2569 the request from the mobile node, will allocate an address from 2570 the prefix pointed to by the link-address field of the request. 2572 o Once the mobile node obtains an address and moves to a different 2573 link and sends a DHCPv6 request (at any time) for extending the 2574 DHCP lease, the DHCPv6 relay agent on the new link will set the 2575 prefix hint in the DHCPv6 message to the mobile node's home 2576 network prefix (assigned by the local mobility anchor for this 2577 mobility session). The DHCPv6 server will identify the client 2578 from the Client-DUID option present in the request and will 2579 allocate the same address as before. 2581 o The DHCPv6 based address configuration is not recommended for 2582 deployments where the local mobility anchor and the mobile access 2583 gateways are located in different administrative domains. For 2584 this configuration to work, all the mobile access gateways in the 2585 Proxy Mobile IPv6 domain should be able to ensure that the DHCPv6 2586 request messages from a given mobile node anchored on any of the 2587 access links in that domain, will always be handled by the same 2588 DHCPv6 server or by a server from the same group of coordinated 2589 DHCPv6 servers serving that domain. 2591 o The DHCPv6 server should be configured to offer low address lease 2592 times. A lease time that is too large prevents the DHCPv6 server 2593 from reclaiming the address even after the local mobility anchor 2594 deletes the mobile node's binding cache entry. It is recommended 2595 that the configured lease time be lower than the accepted binding 2596 lifetime for any mobility binding. 2598 6.12. Home Network Prefix Renumbering 2600 If the mobile node's home network prefix gets renumbered or becomes 2601 invalid during the middle of a mobility session, the mobile access 2602 gateway MUST withdraw the prefix by sending a Router Advertisement on 2603 the access link with zero prefix lifetime for the mobile node's home 2604 network prefix. Also, the local mobility anchor and the mobile 2605 access gateway MUST delete the routing state for that prefix. 2606 However, the specific details on how the local mobility anchor 2607 notifies the mobile access gateway about the mobile node's home 2608 network prefix renumbering are outside the scope of this document. 2610 6.13. Mobile Node Detachment Detection and Resource Cleanup 2612 Before sending a Proxy Binding Update message to the local mobility 2613 anchor for extending the lifetime of a currently existing binding of 2614 a mobile node, the mobile access gateway MUST make sure the mobile 2615 node is still attached to the connected link by using some reliable 2616 method. If the mobile access gateway cannot predictably detect the 2617 presence of the mobile node on the connected link, it MUST NOT 2618 attempt to extend the registration lifetime of the mobile node. 2619 Further, in such a scenario, the mobile access gateway SHOULD 2620 terminate the binding of the mobile node by sending a Proxy Binding 2621 Update message to the mobile node's local mobility anchor with 2622 lifetime value set to 0. It MUST also remove any local state such as 2623 the Binding Update List entry created for that mobile node. 2625 The specific detection mechanism of the loss of a visiting mobile 2626 node on the connected link is specific to the access link between the 2627 mobile node and the mobile access gateway and is outside the scope of 2628 this document. Typically, there are various link-layer specific 2629 events specific to each access technology that the mobile access 2630 gateway can depend on for detecting the node loss. In general, the 2631 mobile access gateway can depend on one or more of the following 2632 methods for the detection presence of the mobile node on the 2633 connected link: 2635 o Link-layer event specific to the access technology 2637 o PPP Session termination event on point-to-point link types 2639 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2641 o Notification event from the local mobility anchor 2643 6.14. Allowing network access to other IPv6 nodes 2645 In some Proxy Mobile IPv6 deployments, network operators may want to 2646 provision the mobile access gateway to offer network-based mobility 2647 management service only to some visiting mobile nodes and enable just 2648 regular IP access to some other nodes. This requires the network to 2649 have control on when to enable network-based mobility management 2650 service to a mobile node and when to enable regular IPv6 access. 2651 This specification does not disallow such configuration. 2653 Upon detecting a mobile node on its access link and after policy 2654 considerations, the mobile access gateway MUST determine if network- 2655 based mobility management service should be offered to that mobile 2656 node. If the mobile node is entitled for network-based mobility 2657 management service, then the mobile access gateway must ensure the 2658 mobile node believes it is on its home link, as explained in various 2659 sections of this specification. 2661 If the mobile node is not entitled for the network-based mobility 2662 management service, as determined from the policy considerations, the 2663 mobile access gateway MAY choose to offer regular IPv6 access to the 2664 mobile node and in such a scenario the normal IPv6 considerations 2665 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2666 obtain an IPv6 address using normal IPv6 address configuration 2667 procedures. The obtained address must be from a local visitor 2668 network prefix. This essentially ensures that the mobile access 2669 gateway functions as a normal access router to a mobile node attached 2670 to its access link and without impacting its host-based mobility 2671 protocol operation. 2673 7. Mobile Node Operation 2675 This non-normative section explains the mobile node's operation in a 2676 Proxy Mobile IPv6 domain. 2678 7.1. Moving into a Proxy Mobile IPv6 Domain 2680 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2681 an access network, the mobile access gateway on the access link 2682 detects the attachment of the mobile node and completes the binding 2683 registration with the mobile node's local mobility anchor. If the 2684 binding update operation is successfully performed, the mobile access 2685 gateway will create the required state and set up the data path for 2686 the mobile node's data traffic. 2688 If the mobile node is IPv6 enabled, on attaching to the access link, 2689 it will typically send a Router Solicitation message [RFC-4861]. The 2690 mobile access gateway on the access link will respond to the Router 2691 Solicitation message with a Router Advertisement. The Router 2692 Advertisement will have the mobile node's home network prefix, 2693 default-router address and other address configuration parameters. 2695 If the mobile access gateway on the access link receives a Router 2696 Solicitation message from the mobile node, before it completes the 2697 signaling with the mobile node's local mobility anchor, the mobile 2698 access gateway may not know the mobile node's home network prefix and 2699 may not be able to emulate the mobile node's home link on the access 2700 link. In such a scenario, the mobile node may notice a slight delay 2701 before it receives a Router Advertisement message. 2703 If the received Router Advertisement has the Managed Address 2704 Configuration flag set, the mobile node, as it would normally do, 2705 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2706 enabled on that access link will ensure the mobile node will obtain 2707 its IPv6 address as a lease from its home network prefix. 2709 If the received Router Advertisement does not have the Managed 2710 Address Configuration flag set and if the mobile node is allowed to 2711 use an autoconfigured address, the mobile node will be able to obtain 2712 an IPv6 address using any of the standard IPv6 address configuration 2713 mechanisms permitted for that mode. 2715 If the mobile node is IPv4 enabled and if the network permits, it 2716 will be able to obtain the IPv4 address configuration as specified in 2717 the companion document [ID-IPV4-PMIP6]. 2719 Once the address configuration is complete, the mobile node can 2720 continue to use this address configuration as long as it is attached 2721 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2723 7.2. Roaming in the Proxy Mobile IPv6 Domain 2725 After obtaining the address configuration in the Proxy Mobile IPv6 2726 domain, as the mobile node moves and changes its point of attachment 2727 from one mobile access gateway to the other, it can still continue to 2728 use the same address configuration. As long as the attached access 2729 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 2730 node will always detect the same default-router advertising the 2731 mobile node's home network prefix on each connected link. If the 2732 mobile node performs DHCP operation, it will always obtain the same 2733 address as before. 2735 8. Message Formats 2737 This section defines extensions to the Mobile IPv6 [RFC-3775] 2738 protocol messages. 2740 8.1. Proxy Binding Update Message 2742 0 1 2 3 2743 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Sequence # | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 |A|H|L|K|M|R|P| Reserved | Lifetime | 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 | | 2750 . . 2751 . Mobility options . 2752 . . 2754 | | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2757 A Binding Update message that is sent by a mobile access gateway to a 2758 local mobility anchor is referred to as the "Proxy Binding Update" 2759 message. A new flag (P) is included in the Binding Update message. 2760 The rest of the Binding Update message format remains the same as 2761 defined in [RFC-3775] and with the additional (R) and (M) flags as 2762 specified in [RFC-3963] and [RFC-4140] respectively. 2764 Proxy Registration Flag (P) 2766 A new flag (P) is included in the Binding Update message to 2767 indicate to the local mobility anchor that the Binding Update 2768 message is a proxy registration. The flag MUST be set to the 2769 value of 1 for proxy registrations and MUST be set to 0 for direct 2770 registrations sent by a mobile node. 2772 Mobility Options 2774 Variable-length field of such length that the complete Mobility 2775 Header is an integer multiple of 8 octets long. This field 2776 contains zero or more TLV-encoded mobility options. The encoding 2777 and format of defined options are described in Section 6.2 of 2778 [RFC-3775]. The local mobility anchor MUST ignore and skip any 2779 options which it does not understand. 2781 As per this specification, the following mobility options are 2782 valid in a Proxy Binding Update message. There can be only one 2783 instance of each of these options present in the message and in 2784 any order. 2786 Mobile Node Identifier option 2788 Home Network Prefix option 2790 Handoff Indicator option 2792 Access Technology Type option 2794 Timestamp option 2796 Mobile Node Link-layer Identifier option 2798 Link-local Address option 2800 For descriptions of other fields present in this message, refer to 2801 section 6.1.7 of [RFC-3775]. 2803 8.2. Proxy Binding Acknowledgement Message 2805 0 1 2 3 2806 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2808 | Status |K|R|P|Reserved | 2809 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2810 | Sequence # | Lifetime | 2811 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2812 | | 2813 . . 2814 . Mobility options . 2815 . . 2816 | | 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2819 A Binding Acknowledgement message that is sent by a local mobility 2820 anchor to a mobile access gateway is referred to as the "Proxy 2821 Binding Acknowledgement" message. A new flag (P) is included in the 2822 Binding Acknowledgement message. The rest of the Binding 2823 Acknowledgement message format remains the same as defined in [RFC- 2824 3775] and with the additional (R) flag as specified in [RFC-3963]. 2826 Proxy Registration Flag (P) 2828 A new flag (P) is included in the Binding Acknowledgement message 2829 to indicate that the local mobility anchor that processed the 2830 corresponding Proxy Binding Update message supports proxy 2831 registrations. The flag is set to value of 1 only if the 2832 corresponding Proxy Binding Update had the Proxy Registration Flag 2833 (P) set to value of 1. 2835 Mobility Options 2837 Variable-length field of such length that the complete Mobility 2838 Header is an integer multiple of 8 octets long. This field 2839 contains zero or more TLV-encoded mobility options. The encoding 2840 and format of defined options are described in Section 6.2 of 2841 [RFC-3775]. The mobile access gateway MUST ignore and skip any 2842 options which it does not understand. 2844 As per this specification, the following mobility options are 2845 valid in a Proxy Binding Acknowledgement message. There can be 2846 only one instance of each of these options present in the message 2847 and in any order. 2849 Mobile Node Identifier option 2851 Home Network Prefix option 2853 Handoff Indicator option 2855 Access Technology Type option 2857 Timestamp option 2859 Mobile Node Link-layer Identifier option 2861 Link-local Address option 2863 Status 2865 8-bit unsigned integer indicating the disposition of the Proxy 2866 Binding Update. Values of the Status field less than 128 indicate 2867 that the Proxy Binding Update was accepted by the local mobility 2868 anchor. Values greater than or equal to 128 indicate that the 2869 binding registration was rejected by the local mobility anchor. 2870 Section 8.9 defines the Status values that can used in Proxy 2871 Binding Acknowledgement message. 2873 For descriptions of other fields present in this message, refer to 2874 the section 6.1.8 of [RFC-3775]. 2876 8.3. Home Network Prefix Option 2878 A new option, Home Network Prefix Option is defined for using it in 2879 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2880 exchanged between a local mobility anchor and a mobile access 2881 gateway. This option is used for exchanging the mobile node's home 2882 network prefix information. 2884 The Home Network Prefix Option has an alignment requirement of 8n+4. 2885 Its format is as follows: 2887 0 1 2 3 2888 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2889 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2890 | Type | Length | Reserved | Prefix Length | 2891 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2892 | | 2893 + + 2894 | | 2895 + Home Network Prefix + 2896 | | 2897 + + 2898 | | 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 Type 2902 2904 Length 2906 8-bit unsigned integer indicating the length of the option 2907 in octets, excluding the type and length fields. This field 2908 MUST be set to 18. 2910 Reserved (R) 2912 This 8-bit field is unused for now. The value MUST be 2913 initialized to 0 by the sender and MUST be ignored by the 2914 receiver. 2916 Prefix Length 2918 8-bit unsigned integer indicating the prefix length of the 2919 IPv6 prefix contained in the option. 2921 Home Network Prefix 2923 A sixteen-byte field containing the mobile node's IPv6 Home 2924 Network Prefix. 2926 8.4. Handoff Indicator Option 2928 A new option, Handoff Indicator Option is defined for using it in the 2929 Proxy Binding Update and Proxy Binding Acknowledgement messages 2930 exchanged between a local mobility anchor and a mobile access 2931 gateway. This option is used for exchanging the mobile node's 2932 handoff related hints. 2934 The Handoff Indicator Option has no alignment requirement. Its 2935 format is as follows: 2937 0 1 2 3 2938 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2939 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2940 | Type | Length | Reserved (R) | HI | 2941 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2943 Type 2944 2946 Length 2948 8-bit unsigned integer indicating the length of the option 2949 in octets, excluding the type and length fields. This field 2950 MUST be set to 2. 2952 Reserved (R) 2954 This 8-bit field is unused for now. The value MUST be 2955 initialized to 0 by the sender and MUST be ignored by the 2956 receiver. 2958 Handoff Indicator (HI) 2960 A 8-bit field that specifies the type of handoff. The values 2961 (0 - 255) will be allocated and managed by IANA. The following 2962 values are currently defined. 2964 0: Reserved 2965 1: Attachment over a new interface 2966 2: Handoff between two different interfaces of the mobile node 2967 3: Handoff between mobile access gateways for the same interface 2968 4: Handoff state unknown 2969 5: Handoff state not changed (Re-registration) 2971 8.5. Access Technology Type Option 2973 A new option, Access Technology Type Option is defined for using it 2974 in the Proxy Binding Update and Proxy Binding Acknowledgement 2975 messages exchanged between a local mobility anchor and a mobile 2976 access gateway. This option is used for exchanging the type of the 2977 access technology using which the mobile node is currently attached 2978 to the mobile access gateway. 2980 The Access Technology Type Option has no alignment requirement. Its 2981 format is as follows: 2983 0 1 2 3 2984 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2986 | Type | Length | Reserved (R) | ATT | 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2989 Type 2990 2992 Length 2994 8-bit unsigned integer indicating the length of the option 2995 in octets, excluding the type and length fields. This field 2996 MUST be set to 2. 2998 Reserved (R) 3000 This 8-bit field is unused for now. The value MUST be 3001 initialized to 0 by the sender and MUST be ignored by the 3002 receiver. 3004 Access Technology Type (ATT) 3006 A 8-bit field that specifies the access technology through 3007 which the mobile node is connected to the access link on the 3008 mobile access gateway. 3010 The values (0 - 255) will be allocated and managed by IANA. The 3011 following values are currently reserved for the below specified 3012 access technology types. 3014 0: Reserved 3015 1: Virtual 3016 2: PPP 3017 3: 802.3 (Ethernet) 3018 4: 802.11a/b/g 3019 5: 802.16e 3021 8.6. Mobile Node Link-layer Identifier Option 3023 A new option, Mobile Node Link-layer Identifier Option is defined for 3024 using it in the Proxy Binding Update and Proxy Binding 3025 Acknowledgement messages exchanged between a local mobility anchor 3026 and a mobile access gateway. This option is used for exchanging the 3027 mobile node's link-layer identifier. 3029 The format of the Link-layer Identifier option is shown below. Based 3030 on the size of the identifier, the option MUST be aligned 3031 appropriately, as per mobility option alignment requirements 3032 specified in [RFC-3775]. 3034 0 1 2 3 3035 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3037 | Type | Length | Reserved | 3038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3039 | | 3040 + Link-layer Identifier + 3041 . ... . 3042 | | 3043 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3045 Type 3046 3048 Length 3049 8-bit unsigned integer indicating the length of the option 3050 in octets, excluding the type and length fields. 3052 Reserved 3054 This field is unused for now. The value MUST be initialized to 3055 0 by the sender and MUST be ignored by the receiver. 3057 Link-layer Identifier 3059 A variable length field containing the mobile node's link-layer 3060 identifier. 3062 The content and format of this field (including byte and bit 3063 ordering) is as specified in Section 4.6 of [RFC-4861] for 3064 carrying Link-Layer Address. On certain access links, where 3065 the link-layer address is not used or cannot be determined, 3066 this option cannot be used. 3068 8.7. Link-local Address Option 3070 A new option, Link-local Address Option is defined for using it in 3071 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3072 exchanged between a local mobility anchor and a mobile access 3073 gateway. This option is used for exchanging the link-local address 3074 of the mobile access gateway. 3076 The Link-local Address option has an alignment requirement of 8n+6. 3077 Its format is as follows: 3079 0 1 2 3 3080 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | Type | Length | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | | 3085 + + 3086 | | 3087 + Link-local Address + 3088 | | 3089 + + 3090 | | 3091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3093 Type 3094 3096 Length 3098 8-bit unsigned integer indicating the length of the option 3099 in octets, excluding the type and length fields. This field 3100 MUST be set to 16. 3102 Link-local Address 3104 A sixteen-byte field containing the mobile node's link-local 3105 address. 3107 8.8. Timestamp Option 3109 A new option, Timestamp Option is defined for use in the Proxy 3110 Binding Update and Proxy Binding Acknowledgement messages. 3112 The Timestamp option has an alignment requirement of 8n+2. Its 3113 format is as follows: 3115 0 1 2 3 3116 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3117 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3118 | Type | Length | 3119 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3120 | | 3121 + Timestamp + 3122 | | 3123 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3125 Type 3126 3128 Length 3130 8-bit unsigned integer indicating the length in octets of 3131 the option, excluding the type and length fields. The value 3132 for this field MUST be set to 8. 3134 Timestamp 3136 A 64-bit unsigned integer field containing a timestamp. The value 3137 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3138 by using a fixed point format. In this format, the integer number 3139 of seconds is contained in the first 48 bits of the field, and the 3140 remaining 16 bits indicate the number of 1/65536 fractions of a 3141 second. 3143 8.9. Status Values 3145 This document defines the following new Status values for use in 3146 Proxy Binding Acknowledgement message. These values are to be 3147 allocated from the same number space, as defined in Section 6.1.8 of 3148 [RFC-3775]. 3150 Status values less than 128 indicate that the Proxy Binding Update 3151 request was accepted by the local mobility anchor. Status values 3152 greater than 128 indicate that the Proxy Binding Update was rejected 3153 by the local mobility anchor. 3155 PROXY_REG_NOT_ENABLED: IANA 3157 Proxy registration not enabled for the mobile node 3159 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3161 Not local mobility anchor for this mobile node 3163 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3165 The mobile access gateway is not authorized to send proxy binding 3166 registrations 3168 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3170 The mobile node is not authorized for the requesting home network 3171 prefix 3173 TIMESTAMP_MISMATCH: IANA 3175 Invalid timestamp value (the clocks are out of sync) 3177 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3179 The timestamp value is lower than the previously accepted value 3181 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3183 Missing home network prefix option 3185 MISSING_MN_IDENTIFIER_OPTION: IANA 3187 Missing mobile node identifier option 3189 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3190 Missing handoff indicator option 3192 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3194 Missing access technology type option 3196 Additionally, the following Status values defined in [RFC-3775] can 3197 also be used in Proxy Binding Acknowledgement message. 3199 0 Proxy Binding Update accepted 3201 128 Reason unspecified 3203 129 Administratively prohibited 3205 130 Insufficient resources 3207 9. Protocol Configuration Variables 3209 The local mobility anchor MUST allow the following variables to be 3210 configured by the system management. The configured values for these 3211 protocol variables MUST survive server reboots and service restarts. 3213 MinDelayBeforeBCEDelete 3215 This variable specifies the amount of time in milliseconds the 3216 local mobility anchor MUST wait before it deletes a Binding Cache 3217 entry of a mobile node, upon receiving a Proxy Binding Update 3218 message from a mobile access gateway with a lifetime value of 0. 3219 During this wait time, if the local mobility anchor receives a 3220 Proxy Binding Update for the same mobility binding, with lifetime 3221 value greater than 0, then it must update the binding cache entry 3222 with the accepted binding values. By the end of this wait-time, 3223 if the local mobility anchor did not receive any valid Proxy 3224 Binding Update message for that mobility binding, it MUST delete 3225 the Binding Cache entry. This delay essentially ensures a mobile 3226 node's Binding Cache entry is not deleted too quickly and allows 3227 some time for the new mobile access gateway to complete the 3228 signaling for the mobile node. 3230 The default value for this variable is 10000 milliseconds. 3232 MaxDelayBeforeNewBCEAssign 3233 This variable specifies the amount of time in milliseconds the 3234 local mobility anchor MUST wait for the de-registration message 3235 for an existing mobility session before it decides to create a new 3236 mobility session. 3238 The default value for this variable is 500 milliseconds. 3240 TimestampValidityWindow 3242 This variable specifies the maximum amount of time difference in 3243 milliseconds between the timestamp in the received Proxy Binding 3244 Update message and the current time-of-day on the local mobility 3245 anchor, that is allowed by the local mobility anchor for the 3246 received message to be considered valid. 3248 The default value for this variable is 300 milliseconds. This 3249 variable must be adjusted to suit the deployments. 3251 The mobile access gateway MUST allow the following variables to be 3252 configured by the system management. The configured values for these 3253 protocol variables MUST survive server reboots and service restarts. 3255 EnableMAGLocalRouting 3257 This flag indicates whether or not the mobile access gateway is 3258 allowed to enable local routing of the traffic exchanged between a 3259 visiting mobile node and a correspondent node that is locally 3260 connected to one of the interfaces of the mobile access gateway. 3261 The correspondent node can be another visiting mobile node as 3262 well, or a local fixed node. 3264 The default value for this flag is set to value of 0, indicating 3265 that the mobile access gateway MUST reverse tunnel all the traffic 3266 to the mobile node's local mobility anchor. 3268 When the value of this flag is set to value of 1, the mobile 3269 access gateway MUST route the traffic locally. 3271 This aspect of local routing MAY be defined as policy on a per 3272 mobile basis and when present will take precedence over this flag. 3274 10. IANA Considerations 3276 This document defines six new Mobility Header options, the Home 3277 Network Prefix option, Handoff Indicator option, Access Technology 3278 Type option, Mobile Node Link-layer Identifier option, Link-local 3279 Address option and Timestamp option. These options are described in 3280 Section 8. The Type value for these options needs to be assigned 3281 from the same numbering space as allocated for the other mobility 3282 options, as defined in [RFC-3775]. 3284 The Handoff Indicator option defined in Section 8.4 of this document 3285 introduces a new Handoff Indicator (HI) numbering space, where the 3286 values from 0 to 5 have been reserved by this document. Approval of 3287 new Handoff Indicator type values are to be made through IANA Expert 3288 Review. 3290 The Access Technology Type option defined in Section 8.5 of this 3291 document introduces a new Access Technology type (ATT) numbering 3292 space, where the values from 0 to 5 have been reserved by this 3293 document. Approval of new Access Technology type values are to be 3294 made through IANA Expert Review. 3296 This document also defines new Binding Acknowledgement status values 3297 as described in Section 8.9. The status values MUST be assigned from 3298 the same number space used for Binding Acknowledgement status values, 3299 as defined in [RFC-3775]. The allocated values for each of these 3300 status values must be greater than 128. 3302 11. Security Considerations 3304 The potential security threats against any network-based mobility 3305 management protocol are described in [RFC-4832]. This section 3306 explains how Proxy Mobile IPv6 protocol defends itself against those 3307 threats. 3309 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3310 Binding Update and Proxy Binding Acknowledgement, exchanged between 3311 the mobile access gateway and the local mobility anchor to be 3312 protected using IPsec, using the established security association 3313 between them. This essentially eliminates the threats related to the 3314 impersonation of the mobile access gateway or the local mobility 3315 anchor. 3317 This specification allows a mobile access gateway to send binding 3318 registration messages on behalf of a mobile node. If proper 3319 authorization checks are not in place, a malicious node may be able 3320 to hijack a mobile node's session or may carry out a denial-of- 3321 service attack. To prevent this attack, this specification requires 3322 the local mobility anchor to allow only authorized mobile access 3323 gateways that are part of that Proxy Mobile IPv6 domain to send 3324 binding registration messages on behalf of a mobile node. 3326 To eliminate the threats on the interface between the mobile access 3327 gateway and the mobile node, this specification requires an 3328 established trust between the mobile access gateway and the mobile 3329 node and to authenticate and authorize the mobile node before it is 3330 allowed to access the network. Further, the established 3331 authentication mechanisms enabled on that access link will ensure 3332 that there is a secure binding between the mobile node's identity and 3333 its link-layer address. The mobile access gateway will definitively 3334 identify the mobile node from the packets that it receives on that 3335 access link. 3337 To address the threat related to a compromised mobile access gateway, 3338 the local mobility anchor, before accepting a Proxy Binding Update 3339 message for a given mobile node, may ensure that the mobile node is 3340 definitively attached to the mobile access gateway that sent the 3341 proxy binding registration request. This may be accomplished by 3342 contacting a trusted entity which is able to track the mobile node's 3343 current point of attachment. However, the specific details of the 3344 actual mechanisms for achieving this is outside the scope of this 3345 document. 3347 12. Acknowledgements 3349 The authors would like to specially thank Julien Laganier, Christian 3350 Vogt, Dave Thaler, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock 3351 Choi, Jari Arkko and Elwyn Davies for their thorough review of this 3352 document. 3354 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3355 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3356 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3357 Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- 3358 Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3359 Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil 3360 Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri 3361 Blumenthal, Ved Kafle, Vidya Narayanan, Youn-Hee Han and many others 3362 for their passionate discussions in the working group mailing list on 3363 the topic of localized mobility management solutions. These 3364 discussions stimulated much of the thinking and shaped the draft to 3365 the current form and we acknowledge that ! 3367 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3368 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 3369 Tim Stammers for their input on this document. 3371 13. References 3373 13.1. Normative References 3375 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3376 Requirement Levels", BCP 14, RFC 2119, March 1997. 3378 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3379 IPv6 Specification", RFC 2473, December 1998. 3381 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3382 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3383 RFC 3315, July 2003. 3385 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3386 IPv6", RFC 3775, June 2004. 3388 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3389 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3390 January 2005. 3392 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3393 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3394 4140, August 2005. 3396 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3397 Network Access Identifier", RFC 4282, December 2005. 3399 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3400 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3401 November 2005. 3403 [RFC-4291] Hinden, R., Deering, S., "IP Version 6 Addressing 3404 Architecture", RFC 4291, February 2006. 3406 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3407 Internet Protocol", RFC 4301, December 2005. 3409 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3410 4303, December 2005. 3412 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3413 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3414 2007. 3416 13.2. Informative References 3418 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 3419 51, RFC 1661, July 1994. 3421 [RFC-2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3422 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 3423 2000. 3425 [RFC-3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3426 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3428 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3429 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3430 2005. 3432 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3433 Protocol", RFC 4306, December 2005. 3435 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3436 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3438 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3439 "Chargeable User Identity", RFC 4372, January 2006. 3441 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3442 G., Liebsch, M., "Problem Statement for Network-based Localized 3443 Mobility Management", September 2006. 3445 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3446 G., Liebsch, M., "Goals for Network-based Localized Mobility 3447 Management", October 2006. 3449 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3450 Localized Mobility Management", September 2006. 3452 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3453 Address Autoconfiguration", RFC 4862, September 2007. 3455 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3456 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3457 2007. 3459 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3460 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3461 November 2007. 3463 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 3464 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. 3466 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3468 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3469 typically be identified by an identifier, MN-Identifier, and that 3470 identifier will have an associated policy profile that identifies the 3471 mobile node's home network prefix, permitted address configuration 3472 modes, roaming policy and other parameters that are essential for 3473 providing network-based mobility service. This information is 3474 typically configured in AAA. It is possible the home network prefix 3475 is dynamically allocated for the mobile node when it boots up for the 3476 first time in the network, or it could be a statically configured 3477 value on per mobile node basis. However, for all practical purposes, 3478 the network entities in the proxy Mobile IPv6 domain, while serving a 3479 mobile node will have access to this profile and these entities can 3480 query this information using RADIUS [RFC-2865] or DIAMETER [RFC-3588] 3481 protocols. 3483 Appendix B. Routing State 3485 The following section explains the routing state for a mobile node on 3486 the mobile access gateway. This routing state reflects only one 3487 specific way of implementation and one MAY choose to implement it in 3488 other ways. The policy based route defined below acts as a traffic 3489 selection rule for routing a mobile node's traffic through a specific 3490 tunnel created between the mobile access gateway and that mobile 3491 node's local mobility anchor and with the specific encapsulation 3492 mode, as negotiated. 3494 The below example identifies the routing state for two visiting 3495 mobile nodes, MN1 and MN2 with their respective local mobility 3496 anchors LMA1 and LMA2. 3498 For all traffic from the mobile node, identified by the mobile node's 3499 MAC address, ingress interface or source prefix (MN-HNP) to 3500 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3502 +==================================================================+ 3503 | Packet Source | Destination Address | Destination Interface | 3504 +==================================================================+ 3505 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3506 | (IPv6 Prefix or |----------------------------------------------| 3507 | Input Interface) | Locally Connected | Tunnel0 | 3508 +------------------------------------------------------------------+ 3509 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3510 + (IPv6 Prefix or -----------------------------------------------| 3511 | Input Interface | Locally Connected | direct | 3512 +------------------------------------------------------------------+ 3514 Figure 22: Example - Policy based Route Table 3516 +==================================================================+ 3517 | Interface | Source Address | Destination Address | Encapsulation | 3518 +==================================================================+ 3519 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3520 +------------------------------------------------------------------+ 3521 | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | 3522 +------------------------------------------------------------------+ 3524 Figure 23: Example - Tunnel Interface Table 3526 Authors' Addresses 3528 Sri Gundavelli 3529 Cisco 3530 170 West Tasman Drive 3531 San Jose, CA 95134 3532 USA 3534 Email: sgundave@cisco.com 3536 Kent Leung 3537 Cisco 3538 170 West Tasman Drive 3539 San Jose, CA 95134 3540 USA 3542 Email: kleung@cisco.com 3543 Vijay Devarapalli 3544 Azaire Networks 3545 4800 Great America Pkwy 3546 Santa Clara, CA 95054 3547 USA 3549 Email: vijay.devarapalli@azairenet.com 3551 Kuntal Chowdhury 3552 Starent Networks 3553 30 International Place 3554 Tewksbury, MA 3556 Email: kchowdhury@starentnetworks.com 3558 Basavaraj Patil 3559 Nokia Siemens Networks 3560 6000 Connection Drive 3561 Irving, TX 75039 3562 USA 3564 Email: basavaraj.patil@nsn.com 3566 Full Copyright Statement 3568 Copyright (C) The IETF Trust (2008). 3570 This document is subject to the rights, licenses and restrictions 3571 contained in BCP 78, and except as set forth therein, the authors 3572 retain all their rights. 3574 This document and the information contained herein are provided on an 3575 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3576 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3577 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3578 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3579 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3580 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3582 Intellectual Property 3584 The IETF takes no position regarding the validity or scope of any 3585 Intellectual Property Rights or other rights that might be claimed to 3586 pertain to the implementation or use of the technology described in 3587 this document or the extent to which any license under such rights 3588 might or might not be available; nor does it represent that it has 3589 made any independent effort to identify any such rights. Information 3590 on the procedures with respect to rights in RFC documents can be 3591 found in BCP 78 and BCP 79. 3593 Copies of IPR disclosures made to the IETF Secretariat and any 3594 assurances of licenses to be made available, or the result of an 3595 attempt made to obtain a general license or permission for the use of 3596 such proprietary rights by implementers or users of this 3597 specification can be obtained from the IETF on-line IPR repository at 3598 http://www.ietf.org/ipr. 3600 The IETF invites any interested party to bring to its attention any 3601 copyrights, patents or patent applications, or other proprietary 3602 rights that may cover technology that may be required to implement 3603 this standard. Please address the information to the IETF at 3604 ietf-ipr@ietf.org. 3606 Acknowledgment 3608 Funding for the RFC Editor function is provided by the IETF 3609 Administrative Support Activity (IASA).