idnits 2.17.1 draft-ietf-netlmm-proxymip6-11.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 3562. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3573. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3580. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3586. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 25, 2008) is 5904 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) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) -- 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-06 Summary: 3 errors (**), 0 flaws (~~), 3 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: August 28, 2008 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 February 25, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-11.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 August 28, 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 . . . . . . . . . . . . . 8 63 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 14 64 4.1. Peer Authorization Database (PAD) Entries . . . . . . . . 15 65 4.2. Security Policy Database (SPD) Entries . . . . . . . . . . 15 66 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 16 67 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 16 68 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 18 69 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 18 70 5.3.1. Processing Binding Registrations . . . . . . . . . . . 18 71 5.3.2. Initial Binding Registration (New Mobility Session) . 20 72 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 21 73 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 22 74 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 22 75 5.3.6. Constructing the Proxy Binding Acknowledgement 76 Message . . . . . . . . . . . . . . . . . . . . . . . 23 77 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 25 78 5.4.1. Binding Cache entry lookup considerations . . . . . . 26 79 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 31 80 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 34 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 34 82 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 34 83 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 35 84 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 36 85 5.9. Route Optimizations Considerations . . . . . . . . . . . . 36 86 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 36 87 6.1. Extensions to Binding Update List Entry Data Structure . . 37 88 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 38 89 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 38 90 6.4. Supported Address Configuration Modes . . . . . . . . . . 39 91 6.5. Access Authentication & Mobile Node Identification . . . . 39 92 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 40 93 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 40 94 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 41 95 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 42 96 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 42 97 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 50 98 6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 51 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51 100 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 52 101 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 53 102 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 53 103 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 54 104 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 54 105 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 54 106 6.11. Supporting DHCPv6 based Address Configuration on the 107 Access Link . . . . . . . . . . . . . . . . . . . . . . . 56 108 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 57 109 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 57 110 6.14. Allowing network access to other IPv6 nodes . . . . . . . 58 111 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 58 112 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 58 113 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 59 114 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 60 115 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 60 116 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 62 117 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 63 118 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 64 119 8.5. Access Technology Type Option . . . . . . . . . . . . . . 65 120 8.6. Mobile Node Interface Identifier Option . . . . . . . . . 67 121 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 68 122 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 68 123 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 69 124 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 71 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 72 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 73 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 74 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 74 129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 74 130 13.2. Informative References . . . . . . . . . . . . . . . . . . 75 131 Appendix A. Proxy Mobile IPv6 interactions with AAA 132 Infrastructure . . . . . . . . . . . . . . . . . . . 76 133 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 77 134 Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 77 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 78 136 Intellectual Property and Copyright Statements . . . . . . . . . . 80 138 1. Introduction 140 IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. 141 Mobile IPv6 requires client functionality in the IPv6 stack of a 142 mobile node. Exchange of signaling messages between the mobile node 143 and home agent enables the creation and maintenance of a binding 144 between the mobile node's home address and its care-of-address. 145 Mobility as specified in [RFC-3775] requires the IP host to send IP 146 mobility management signaling messages to the home agent, which is 147 located in the network. 149 Network-based mobility is another approach to solving the IP mobility 150 challenge. It is possible to support mobility for IPv6 nodes without 151 host involvement by extending Mobile IPv6 [RFC-3775] signaling 152 messages between a network node and a home agent. This approach to 153 supporting mobility does not require the mobile node to be involved 154 in the exchange of signaling messages between itself and the home 155 agent. A proxy mobility agent in the network performs the signaling 156 with the home agent and does the mobility management on behalf of the 157 mobile node attached to the network. Because of the use and 158 extension of Mobile IPv6 signaling and home agent functionality, this 159 protocol is referred to as Proxy Mobile IPv6 (PMIPv6). 161 Network deployments which are designed to support mobility would be 162 agnostic to the capability in the IPv6 stack of the nodes which it 163 serves. IP mobility for nodes which have mobile IP client 164 functionality in the IPv6 stack as well as those nodes which do not, 165 would be supported by enabling Proxy Mobile IPv6 protocol 166 functionality in the network. The advantages of developing a network 167 based mobility protocol based on Mobile IPv6 are: 169 o Reuse of home agent functionality and the messages/format used in 170 mobility signaling. Mobile IPv6 is a mature protocol with several 171 implementations that have undergone interoperability testing. 173 o A common home agent would serve as the mobility agent for all 174 types of IPv6 nodes. 176 The problem statement and the need for a network based mobility 177 protocol solution has been documented in [RFC-4830]. Proxy Mobile 178 IPv6 is a solution that addresses these issues and requirements. 180 2. Conventions & Terminology 181 2.1. Conventions used in this document 183 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 184 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 185 document are to be interpreted as described in RFC 2119 [RFC-2119]. 187 2.2. Terminology 189 All the general mobility related terms used in this document are to 190 be interpreted as defined in the Mobile IPv6 base specification [RFC- 191 3775]. 193 This document adopts the terms, Local Mobility Anchor (LMA) and 194 Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- 195 4831]. This document also provides the following context specific 196 explanation to the following terms used in this document. 198 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 200 Proxy Mobile IPv6 domain refers to the network where the mobility 201 management of a mobile node is handled using the Proxy Mobile IPv6 202 protocol as defined in this specification. The Proxy Mobile IPv6 203 domain includes local mobility anchors and mobile access gateways 204 between which security associations can be setup and authorization 205 for sending Proxy Binding Updates on behalf of the mobile nodes 206 can be ensured. 208 Local Mobility Anchor (LMA) 210 Local Mobility Anchor is the home agent for the mobile node in the 211 Proxy Mobile IPv6 domain. It is the topological anchor point for 212 the mobile node's home network prefix and is the entity that 213 manages the mobile node's binding state. The local mobility 214 anchor has the functional capabilities of a home agent as defined 215 in Mobile IPv6 base specification [RFC-3775] with the additional 216 capabilities required for supporting Proxy Mobile IPv6 protocol as 217 defined in this specification. 219 Mobile Access Gateway (MAG) 221 Mobile Access Gateway is a function that manages the mobility 222 related signaling for a mobile node that is attached to its access 223 link. It is responsible for tracking the mobile node's movements 224 to and from the access link and for signaling the mobile node's 225 local mobility anchor. 227 Mobile Node (MN) 229 Throughout this document, the term mobile node is used to refer to 230 an IP host or router whose mobility is managed by the network. 231 The mobile node may be operating in IPv6 mode, IPv4 mode or in 232 IPv4/IPv6 dual mode. The mobile node is not required to 233 participate in any IP mobility related signaling for achieving 234 mobility for an IP address that is obtained in that Proxy Mobile 235 IPv6 domain. 237 LMA Address (LMAA) 239 The address that is configured on the interface of the local 240 mobility anchor and is the transport endpoint of the bi- 241 directional tunnel established between the local mobility anchor 242 and the mobile access gateway. This is the address to where the 243 mobile access gateway sends the Proxy Binding Update messages. 244 When supporting IPv4 traversal, i.e., when the network between the 245 local mobility anchor and the mobile access gateway is an IPv4 246 network, this address will be an IPv4 address and will be referred 247 to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. 249 Proxy Care-of Address (Proxy-CoA) 251 Proxy-CoA is the address configured on the interface of the mobile 252 access gateway and is the transport endpoint of the tunnel between 253 the local mobility anchor and the mobile access gateway. The 254 local mobility anchor views this address as the Care-of Address of 255 the mobile node and registers it in the Binding Cache entry for 256 that mobile node. When the transport network between the mobile 257 access gateway and the local mobility anchor is an IPv4 network 258 and if the care-of address that is registered at the local 259 mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is 260 used, as specified in [ID-IPV4-PMIP6]. 262 Mobile Node's Home Address (MN-HoA) 264 MN-HoA is an address from a mobile node's home network prefix in a 265 Proxy Mobile IPv6 domain. The mobile node will be able to use 266 this address as long as it is attached to the access network that 267 is in the scope of that Proxy Mobile IPv6 domain. Unlike in 268 Mobile IPv6 where the home agent is aware of the home address of 269 the mobile node, in Proxy Mobile IPv6, the mobility entities are 270 only aware of the mobile node's home network prefix and are not 271 always aware of the exact address(es) that the mobile node 272 configured on its interface from that prefix. However, in some 273 configurations and based on the enabled address configuration 274 modes on the access link, the mobility entities in the network can 275 be certain about the exact address configured by the mobile node. 277 Mobile Node's Home Network Prefix (MN-HNP) 279 This is the on-link IPv6 prefix that is always present in the 280 Router Advertisements that the mobile node receives when it is 281 attached to any of the access links in that Proxy Mobile IPv6 282 domain. This home network prefix is topologically anchored at the 283 mobile node's local mobility anchor. The mobile node configures 284 its interface with an address from this prefix. If the mobile 285 node connects to the Proxy Mobile IPv6 domain through multiple 286 interfaces, simultaneously, each of the connected interface will 287 be assigned a unique home network prefix and under a different 288 mobility session. 290 Mobile Node's Home Link 292 This is the link on which the mobile node obtained its Layer-3 293 address configuration for the attached interface after it moved 294 into that Proxy Mobile IPv6 domain. This is the link that 295 conceptually follows the mobile node. The network will ensure the 296 mobile node always sees this link with respect to the layer-3 297 network configuration, on any access link that it attaches to in 298 that Proxy Mobile IPv6 domain. 300 Multihomed Mobile Node 302 A mobile node that connects to the Proxy Mobile IPv6 domain 303 through more than one interface and uses these interfaces 304 simultaneously is referred to as a multihomed mobile node. 306 Mobile Node Identifier (MN-Identifier) 308 The identity of a mobile node in the Proxy Mobile IPv6 domain. 309 This is the stable identifier of a mobile node that the mobility 310 entities in a Proxy Mobile IPv6 domain can always acquire and use 311 it for predictably identifying a mobile node. This is typically 312 an identifier such as Network Access Identifier (NAI) or other 313 identifier such as a Media Access Control (MAC) address. 315 Mobile Node Interface Identifier (MN-Interface-Identifier) 317 The interface identifier that identifies a given interface of a 318 mobile node. For those interfaces that have a layer-2 identifier, 319 the interface identifier can be based on that layer-2 identifier. 320 The interface identifier in some cases is generated by the mobile 321 node and conveyed to the access router or the mobile access 322 gateway. In some cases, there might not be any interface 323 identifier associated with the mobile node's interface. 325 Policy Profile 327 Policy Profile is an abstract term for referring to a set of 328 configuration parameters that are configured for a given mobile 329 node. The mobility entities in the Proxy Mobile IPv6 domain 330 require access to these parameters for providing the mobility 331 management to a given mobile node. The specific details on how 332 the network entities obtain this policy profile is outside the 333 scope of this document. 335 Proxy Binding Update (PBU) 337 A binding registration request message sent by a mobile access 338 gateway to a mobile node's local mobility anchor for establishing 339 a binding between the mobile node's MN-HNP and the Proxy-CoA. 341 Proxy Binding Acknowledgement (PBA) 343 A binding registration reply message sent by a local mobility 344 anchor in response to a Proxy Binding Update request message that 345 it received from a mobile access gateway. 347 Per-MN-Prefix & Shared-Prefix Models 349 The term, Per-MN-Prefix model, is used to refer to an addressing 350 model where there is an unique network prefix assigned for each 351 node. The term, Shared-Prefix model, is used to refer to an 352 addressing model where the prefix is shared by more than one node. 354 ALL_ZERO & NON_ZERO 356 Protocol message fields initialized with value 0 in each byte of 357 the field. Ex: An 8-byte interface identifier field with the 358 value set to 0 in each of the 8 bytes, or an IPv6 address with the 359 value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is 360 used to refer to any value other than an ALL_ZERO value. 362 3. Proxy Mobile IPv6 Protocol Overview 364 This specification describes a network-based mobility management 365 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 366 [RFC-3775]. 368 Proxy Mobile IPv6 protocol is intended for providing network-based IP 369 mobility management support to a mobile node, without requiring the 370 participation of the mobile node in any IP mobility related 371 signaling. The mobility entities in the network will track the 372 mobile node's movements and will initiate the mobility signaling and 373 setup the required routing state. 375 The core functional entities in the NETLMM infrastructure are the 376 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 377 local mobility anchor is responsible for maintaining the mobile 378 node's reachability state and is the topological anchor point for the 379 mobile node's home network prefix. The mobile access gateway is the 380 entity that performs the mobility management on behalf of a mobile 381 node and it resides on the access link where the mobile node is 382 anchored. The mobile access gateway is responsible for detecting the 383 mobile node's movements to and from the access link and for 384 initiating binding registrations to the mobile node's local mobility 385 anchor. The architecture of a Proxy Mobile IPv6 domain is shown in 386 Figure 1. 388 +----+ +----+ 389 |LMA1| |LMA2| 390 +----+ +----+ 391 LMAA1 -> | | <-- LMAA2 392 | | 393 \\ //\\ 394 \\ // \\ 395 \\ // \\ 396 +---\\------------- //------\\----+ 397 ( \\ IPv4/IPv6 // \\ ) 398 ( \\ Network // \\ ) 399 +------\\--------//------------\\-+ 400 \\ // \\ 401 \\ // \\ 402 \\ // \\ 403 Proxy-CoA1--> | | <-- Proxy-CoA2 404 +----+ +----+ 405 |MAG1|-----{MN2} |MAG2| 406 +----+ | +----+ 407 | | | 408 MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3 409 {MN1} {MN3} 411 Figure 1: Proxy Mobile IPv6 Domain 413 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 414 an access link, the mobile access gateway on that access link, after 415 identifying the mobile node and acquiring its identity, will 416 determine if the mobile node is authorized for the network-based 417 mobility management service. 419 If the network determines that the network-based mobility management 420 service needs to be offered to that mobile node, the network will 421 ensure that the mobile node using any of the address configuration 422 mechanisms permitted by the network will be able to obtain the 423 address configuration on the connected interface and move anywhere in 424 that Proxy Mobile IPv6 domain. The obtained address configuration 425 includes the address(es) from its home network prefix, the default- 426 router address on the link and other related configuration 427 parameters. From the perspective of the mobile node, the entire 428 Proxy Mobile IPv6 domain appears as a single link, the network 429 ensures that the mobile node believes it is always on the same link 430 where it obtained its initial address configuration, even after 431 changing its point of attachment in that network. 433 The mobile node may be operating in an IPv4-only mode, IPv6-only mode 434 or in dual IPv4/IPv6 mode. Based on what is enabled in the network 435 for that mobile node, the mobile node will be able to obtain an IPv4, 436 IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy 437 Mobile IPv6 domain. However, the specific details related to the 438 IPv4 addressing or IPv4 transport support are specified in the 439 companion document [ID-IPV4-PMIP6]. 441 If the mobile node connects to the Proxy Mobile IPv6 domain, through 442 multiple interfaces and over multiple access networks, the network 443 will allocate a unique home network prefix for each of the connected 444 interfaces and the mobile node will be able to configure an 445 address(es) on those interfaces from the respective home network 446 prefixes. However, if the mobile node performs an handoff from one 447 interface to another and if the local mobility anchor receives an 448 handoff hint from the serving mobile access gateway about the same, 449 the local mobility anchor will assign the same prefix to the new 450 interface. 452 +-----+ +-----+ +-----+ 453 | MN | | MAG | | LMA | 454 +-----+ +-----+ +-----+ 455 | | | 456 MN Attached | | 457 | | | 458 | MN Attached Event | 459 | (Acquire MN-Id and Profile) | 460 | | | 461 | |----- PBU ----------->| 462 | | | 463 | | Accept PBU 464 | | (Allocate MN-HNP, Setup BCE and Tunnel) 465 | | | 466 | |<--------- PBA -------| 467 | | | 468 | Accept PBA | 469 | (Setup Tunnel and Routing) | 470 | | | 471 | |==== Bi-Dir Tunnel ===| 472 | | | 473 |--- Rtr Sol --------->| | 474 | | | 475 |<------- Rtr Adv -----| | 476 | | | 477 IP Address | | 478 Configuration | | 479 | | | 481 Figure 2: Mobile Node Attachment - Signaling Call Flow 483 Figure 2 shows the signaling call flow when the mobile node enters 484 the Proxy Mobile IPv6 domain. 486 For updating the local mobility anchor about the current location of 487 the mobile node, the mobile access gateway sends a Proxy Binding 488 Update message to the mobile node's local mobility anchor. Upon 489 accepting this Proxy Binding Update message, the local mobility 490 anchor sends a Proxy Binding Acknowledgement message including the 491 mobile node's home network prefix. It also creates the Binding Cache 492 entry and sets up its endpoint of the bi-directional tunnel to the 493 mobile access gateway. 495 The mobile access gateway on receiving the Proxy Binding 496 Acknowledgement message sets up its endpoint of the bi-directional 497 tunnel to the local mobility anchor and also sets up the data path 498 for the mobile node's traffic. At this point the mobile access 499 gateway will have all the required information for emulating the 500 mobile node's home link. It sends Router Advertisement messages to 501 the mobile node on the access link advertising the mobile node's home 502 network prefix as the hosted on-link-prefix. 504 The mobile node on receiving these Router Advertisement messages on 505 the access link will attempt to configure its interface either using 506 stateful or stateless address configuration modes, based on the modes 507 that are permitted on that access link. At the end of a successful 508 address configuration procedure, the mobile node will end up with an 509 address from its home network prefix. 511 Once the address configuration is complete, the mobile node has a 512 valid address from its home network prefix at the current point of 513 attachment. The serving mobile access gateway and the local mobility 514 anchor also have proper routing states for handling the traffic sent 515 to and from the mobile node using an address from its home network 516 prefix. 518 The local mobility anchor, being the topological anchor point for the 519 mobile node's home network prefix, receives any packets that are sent 520 to the mobile node by any node in the network. The local mobility 521 anchor forwards these received packets to the mobile access gateway 522 through the bi-directional tunnel. The mobile access gateway on 523 other end of the tunnel, after receiving the packet, removes the 524 outer header and forwards the packet on the access link to the mobile 525 node. 527 The mobile access gateway typically acts as a default router on the 528 access link. Any packet that the mobile node sends to any 529 correspondent node will be received by the mobile access gateway and 530 will be sent to its local mobility anchor through the bi-directional 531 tunnel. The local mobility anchor on the other end of the tunnel, 532 after receiving the packet, removes the outer header and routes the 533 packet to the destination. 535 +-----+ +-----+ +-----+ +-----+ 536 | MN | |p-MAG| | LMA | |n-MAG| 537 +-----+ +-----+ +-----+ +-----+ 538 | | | | 539 | |==Bi-Dir Tunnel=| | 540 MN Detached | | | 541 | MN Detached Event | | 542 | | | | 543 | |-- DeReg PBU -->| | 544 | | | | 545 | | Accept PBU | 546 | | (Start MinDelayBeforeBCEDelete Timer) 547 | | | | 548 | |<-------- PBA --| | 549 | | | | 550 MN Attached | | | 551 | | | MN Attached Event 552 | | | (Acquire MN-Id and Profile) 553 .... 554 Registration steps as in fig 2. 555 .... 556 | | |==Bi-Dir Tunnel=| 557 |--- Rtr Sol ------------------------------------->| 558 | | | | 559 |<------------------------------------ Rtr Adv ----| 560 | | | | 561 MN retains HoA/HNP 562 | | | | 564 Figure 3: Mobile Node Handoff - Signaling Call Flow 566 Figure 3 shows the signaling call flow for the mobile node's handoff 567 from previously attached mobile access gateway (p-MAG) to the newly 568 attached mobile access gateway (n-MAG). This call flow reflects only 569 a specific message ordering, it is possible the registration message 570 from the n-MAG may arrive before the de-registration message from the 571 p-MAG arrives. 573 After obtaining the initial address configuration in the Proxy Mobile 574 IPv6 domain, if the mobile node changes its point of attachment, the 575 mobile access gateway on the previous link will detect the mobile 576 node's detachment from the link and will signal the local mobility 577 anchor and will remove the binding and routing state for that mobile 578 node. The local mobility anchor upon receiving this request will 579 identify the corresponding mobility session for which the binding 580 update request was received and once it accepts the request will wait 581 for certain amount of time for allowing the mobile access gateway on 582 the new link to update the binding. However, if it does not receive 583 any binding update request within that given amount of time, it will 584 delete the binding cache entry. 586 The mobile access gateway on the new access link upon detecting the 587 mobile node on its access link will signal the local mobility anchor 588 for updating the binding state. Once that signaling is complete, the 589 mobile node will continue to receive the Router Advertisements 590 containing its home network prefix, making it believe it is still on 591 the same link and it will use the same address configuration on the 592 new access link. 594 4. Proxy Mobile IPv6 Protocol Security 596 The signaling messages, Proxy Binding Update and Proxy Binding 597 Acknowledgement, exchanged between the mobile access gateway and the 598 local mobility anchor MUST be protected using end-to-end security 599 association(s) offering integrity and data origin authentication. 601 The mobile access gateway and the local mobility anchor MUST 602 implement IPsec for protecting the Proxy Mobile IPv6 signaling 603 messages [RFC-4301]. That is, IPsec is mandatory to implement 604 security mechanism. However, additional documents may specify 605 alternative mechanisms. 607 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 608 protection SHOULD be used for protecting the signaling messages. 609 Confidentiality protection of these messages is not required. 611 IKEv2 [RFC-4306] SHOULD be used to setup security associations 612 between the mobile access gateway and the local mobility anchor to 613 protect the Proxy Binding Update and Proxy Binding Acknowledgement 614 messages. The mobile access gateway and the local mobility anchor 615 can use any of the authentication mechanisms, as specified in IKEv2, 616 for mutual authentication. 618 The Mobile IPv6 specification [RFC-3775] requires the home agent to 619 prevent a mobile node from creating security associations or creating 620 binding cache entries for another mobile node's home address. In the 621 protocol described in this document, the mobile node is not involved 622 in creating security associations for protecting the signaling 623 messages or sending binding updates. Therefore, the local mobility 624 anchor MUST restrict the creation and manipulation of proxy bindings 625 to specifically authorized mobile access gateways and prefixes. The 626 local mobility anchor MUST be locally configurable to authorize such 627 specific combinations. Additional mechanisms such as a policy store 628 or AAA may be employed, but these are outside the scope of this 629 specification. 631 4.1. Peer Authorization Database (PAD) Entries 633 This section describes PAD entries [RFC-4301] on the mobile access 634 gateway and the local mobility anchor. The PAD entries are only 635 example configurations. Note that the PAD is a logical concept and a 636 particular mobile access gateway or a local mobility anchor 637 implementation can implement the PAD in any implementation specific 638 manner. The PAD state may also be distributed across various 639 databases in a specific implementation. 641 mobile access gateway PAD: 642 - IF remote_identity = lma_identity_1 643 Then authenticate (shared secret/certificate/EAP) 644 and authorize CHILD_SA for remote address lma_addres_1 646 local mobility anchor PAD: 647 - IF remote_identity = mag_identity_1 648 Then authenticate (shared secret/certificate/EAP) 649 and authorize CHILD_SAs for remote address mag_address_1 651 Figure 4: PAD Entries 653 The list of authentication mechanisms in the above examples is not 654 exhaustive. There could be other credentials used for authentication 655 stored in the PAD. 657 4.2. Security Policy Database (SPD) Entries 659 This section describes the security policy entries [RFC-4301] on the 660 mobile access gateway and the local mobility anchor required to 661 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 662 are only example configurations. A particular mobile access gateway 663 or a local mobility anchor implementation could configure different 664 SPD entries as long as they provide the required security. 666 In the examples shown below, the identity of the mobile access 667 gateway is assumed to be mag_1, the address of the mobile access 668 gateway is assumed to be mag_address_1, and the address of the local 669 mobility anchor is assumed to be lma_address_1. 671 mobile access gateway SPD-S: 672 - IF local_address = mag_address_1 & 673 remote_address = lma_address_1 & 674 proto = MH & local_mh_type = BU & remote_mh_type = BA 675 Then use SA ESP transport mode 676 Initiate using IDi = mag_1 to address lma_address_1 678 local mobility anchor SPD-S: 679 - IF local_address = lma_address_1 & 680 remote_address = mag_address_1 & 681 proto = MH & local_mh_type = BA & remote_mh_type = BU 682 Then use SA ESP transport mode 684 Figure 5: SPD Entries 686 5. Local Mobility Anchor Operation 688 The local mobility anchor MUST support the home agent function as 689 defined in [RFC-3775] and additionally the extensions defined in this 690 specification. A home agent with these modifications and enhanced 691 capabilities for supporting Proxy Mobile IPv6 protocol is referred to 692 as the local mobility anchor. 694 This section describes the operational details of the local mobility 695 anchor. 697 5.1. Extensions to Binding Cache Entry Data Structure 699 Every local mobility anchor MUST maintain a Binding Cache entry for 700 each currently registered mobile node. Binding Cache entry is a 701 conceptual data structure, described in Section 9.1 [RFC-3775]. 703 For supporting this specification, the Binding Cache Entry data 704 structure needs to be extended with the following additional fields. 706 o A flag indicating whether or not this Binding Cache entry is 707 created due to a proxy registration. This flag is set to value 1 708 for Binding Cache entries that are proxy registrations and is set 709 to value 0 for all other entries. 711 o The identifier of the registered mobile node, MN-Identifier. This 712 identifier is obtained from the Mobile Node Identifier Option 713 [RFC-4283] present in the received Proxy Binding Update request. 715 o The interface identifier of the mobile node's connected interface 716 on the access link. This identifier can be acquired from the 717 Mobile Node Interface Identifier option, present in the received 718 Proxy Binding Update request. If the option was not present in 719 the request, the value MUST be set to ALL_ZERO. 721 o The Link-local address of the mobile node on the interface 722 attached to the access link. This is obtained from the Link-local 723 Address option, present in the Proxy Binding Update request. If 724 the option was not present in the request, the value MUST be set 725 to ALL_ZERO. 727 o The IPv6 home network prefix that is assigned to the mobile node's 728 connected interface. The home network prefix of the mobile node 729 may have been statically configured in the mobile node's policy 730 profile, or, it may have been dynamically allocated by the local 731 mobility anchor. The IPv6 home network prefix also includes the 732 corresponding prefix length. 734 o The interface identifier (If-Id) of the bi-directional tunnel 735 between the local mobility anchor and the mobile access gateway 736 where the mobile node is currently anchored. This is internal to 737 the local mobility anchor. The tunnel interface identifier is 738 acquired during the tunnel creation. 740 o The access technology type, using which the mobile node is 741 currently attached. This is obtained from the Access Technology 742 Type option, present in the Proxy Binding Update request. 744 o The 64-bit timestamp value of the most recently accepted Proxy 745 Binding Update request sent for this mobile node. This is the 746 time-of-day on the local mobility anchor, when the message was 747 received. If the Timestamp option is not present in the Proxy 748 Binding Update request (i.e., when sequence number based scheme is 749 in use), the value MUST be set to ALL_ZERO. 751 Typically, the mobile node's home network prefix is the key for 752 locating a Binding Cache entry in all cases except when there has 753 been an handoff of the mobile node's session to a new mobile access 754 gateway and that mobile access gateway is unaware of the home network 755 prefix that was assigned to the handed of session. In such handoff 756 cases, the Binding Cache entry can be located under the 757 considerations specified in Section 5.4.1. 759 5.2. Supported Home Network Prefix Models 761 This specification supports Per-MN-Prefix model and does not support 762 Shared-Prefix model. As per the Per-MN-Prefix model, there will be a 763 unique home network prefix assigned to each mobile node and no other 764 node shares an address from that prefix. The assigned prefix is 765 unique to a mobile node and also unique to a given interface of the 766 mobile node. If the mobile node attaches to the Proxy Mobile IPv6 767 domain through multiple interfaces and simultaneously, each of those 768 connected interfaces will be assigned a different prefix. 770 The mobile node's home network prefix is always hosted on the access 771 link where the mobile node is anchored. Conceptually, the entire 772 home network prefix follows the mobile node as it moves within the 773 Proxy Mobile IPv6 domain. The local mobility anchor is not required 774 to perform any proxy ND operations [RFC-4861] for defending the 775 mobile node's home address on the home link. However, from the 776 routing perspective, the home network prefix is topologically 777 anchored on the local mobility anchor. 779 5.3. Signaling Considerations 781 This section provides the rules for processing the signaling 782 messages. The processing rules specified in this section and other 783 related sections are chained and are in a specific order. When 784 applying these considerations for processing the signaling messages, 785 the specified order MUST be maintained. 787 5.3.1. Processing Binding Registrations 789 1. The received Proxy Binding Update message (a Binding Update 790 message with the 'P' flag set to value of 1, format specified in 791 Section 8.1) MUST be authenticated as described in Section 4. 792 When IPsec is used for message authentication, the SPI in the 793 IPsec header [RFC-4306] of the received packet is needed for 794 locating the security association, for authenticating the Proxy 795 Binding Update message. 797 2. The local mobility anchor MUST observe the rules described in 798 Section 9.2 [RFC-3775] when processing Mobility Header in the 799 received Proxy Binding Update request. 801 3. The local mobility anchor MUST ignore the check, specified in 802 Section 10.3.1 [RFC-3775], related to the presence of Home 803 Address destination option in the Proxy Binding Update request. 805 4. The local mobility anchor MUST identify the mobile node from the 806 identifier present in the Mobile Node Identifier option [RFC- 807 4283] of the Proxy Binding Update request. If the Mobile Node 808 Identifier option is not present in the Proxy Binding Update 809 request, the local mobility anchor MUST reject the request and 810 send a Proxy Binding Acknowledgement message with Status field 811 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 812 identifier option) and the identifier in the Mobile Node 813 Identifier Option carried in the message MUST be set to a zero 814 length identifier. 816 5. The local mobility anchor MUST apply the required policy checks, 817 as explained in Section 4, to verify the sender is a trusted 818 mobile access gateway, authorized to send Proxy Binding Update 819 requests on behalf of this mobile node. 821 6. If the local mobility anchor determines that the requesting node 822 is not authorized to send Proxy Binding Update requests for the 823 identified mobile node, it MUST reject the request and send a 824 Proxy Binding Acknowledgement message with Status field set to 825 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 826 binding registrations). 828 7. If the local mobility anchor cannot identify the mobile node 829 based on the identifier present in the Mobile Node Identifier 830 option [RFC-4283] of Proxy Binding Update request, it MUST 831 reject the request and send a Proxy Binding Acknowledgement 832 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 833 (Not local mobility anchor for this mobile node). 835 8. If the local mobility anchor determines that the mobile node is 836 not authorized for the network-based mobility management 837 service, it MUST reject the request and send a Proxy Binding 838 Acknowledgement message with Status field set to 839 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 841 9. The local mobility anchor MUST apply the considerations 842 specified in Section 5.5, for processing the Sequence Number 843 field and the Timestamp option (if present), in the Proxy 844 Binding Update request. 846 10. If the Home Network Prefix option (containing either ALL_ZERO or 847 some prefix value) is not present in the Proxy Binding Update 848 request, the local mobility anchor MUST reject the request and 849 send a Proxy Binding Acknowledgement message with Status field 850 set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network 851 prefix option). 853 11. If the Handoff Indicator option is not present in the Proxy 854 Binding Update request, the local mobility anchor MUST reject 855 the request and send a Proxy Binding Acknowledgement message 856 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 857 (Missing handoff indicator option). 859 12. If the Access Technology Type option is not present in the Proxy 860 Binding Update request, the local mobility anchor MUST reject 861 the request and send a Proxy Binding Acknowledgement message 862 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 863 (Missing access technology type option). 865 13. Considerations specified in Section 5.4.1 MUST be applied for 866 performing the Binding Cache entry existence test. If those 867 checks specified in Section 5.4.1, result in associating the 868 received Proxy Binding Update request to a new mobility session 869 creation request, considerations from Section 5.3.2 (Initial 870 Binding Registration - New Mobility Session), MUST be applied. 871 If those checks result in associating the request to an existing 872 mobility session, the following checks determine the next set of 873 processing rules that needs to be applied. 875 * If the Handoff Indicator field in the Handoff Indicator 876 option present in the request is set to a value of 5 (Handoff 877 state not changed), considerations from Section 5.3.3 878 (Binding Lifetime Extension- No handoff) MUST be applied. 880 * If the received Proxy Binding Update request has the lifetime 881 value of zero, considerations from Section 5.3.5 (Binding De- 882 Registration) MUST be applied. 884 * For all other cases, considerations from Section 5.3.4 885 (Binding Lifetime Extension - After handoff) MUST be applied. 887 14. When sending the Proxy Binding Acknowledgement message with any 888 Status field value, the message MUST be constructed as specified 889 in Section 5.3.6. 891 5.3.2. Initial Binding Registration (New Mobility Session) 893 1. If the Home Network Prefix option present in the Proxy Binding 894 Update request has the value set to ALL_ZERO, the local mobility 895 anchor MUST allocate a prefix and assign it to a new mobility 896 session created for the mobile node. The local mobility anchor 897 MUST ensure the allocated prefix is not in use by any other node 898 or mobility session. 900 2. If the local mobility anchor is unable to allocate any home 901 network prefix for the mobile node, it MUST reject the request 902 and send a Proxy Binding Acknowledgement message with Status 903 field set to 130 (Insufficient resources). 905 3. If the Home Network Prefix option present in the request has a 906 specific prefix hint, the local mobility anchor before accepting 907 that request, MUST ensure the prefix is owned by the local 908 mobility anchor and further the mobile node is authorized to use 909 that prefix. If the mobile node is not authorized to use that 910 prefix, the local mobility anchor MUST reject the request and 911 send a Proxy Binding Acknowledgement message with Status field 912 set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not 913 authorized to use that prefix). 915 4. Upon accepting the request, the local mobility anchor MUST create 916 a Binding Cache entry for the mobile node. It must set the 917 fields in the Binding Cache entry to the accepted values for that 918 registration. 920 5. The local mobility anchor MUST establish a bi-directional tunnel 921 to the mobile access gateway (if there does not exist one) that 922 sent the request and setup the routing state. Considerations 923 from Section 5.6 MUST be applied for creating the routing state. 925 6. The local mobility anchor MUST send the Proxy Binding 926 Acknowledgement message with the Status field set to 0 (Proxy 927 Binding Update Accepted). The message MUST be constructed as 928 specified in Section 5.3.6. 930 5.3.3. Binding Lifetime Extension (No handoff) 932 1. Upon accepting the Proxy Binding Update request for extending the 933 binding lifetime, received from the same mobile access gateway 934 that last updated the binding (i.e., when there is no handoff), 935 the local mobility anchor MUST update the Binding Cache entry 936 with the accepted registration values. However, if the link- 937 local address value in the Link-local address option is ALL_ZERO 938 value, the link-local address field in the Binding Cache entry 939 MUST NOT be updated. 941 2. The local mobility anchor MUST send the Proxy Binding 942 Acknowledgement message with the Status field set to 0 (Proxy 943 Binding Update Accepted). The message MUST be constructed as 944 specified in Section 5.3.6. 946 5.3.4. Binding Lifetime Extension (After handoff) 948 1. Upon accepting the Proxy Binding Update request for extending the 949 binding lifetime, received from a new mobile access gateway where 950 the mobile node's session is handed off, the local mobility 951 anchor MUST update the Binding Cache entry with the accepted 952 registration values. However, if the link-local address value in 953 the Link-local address option is ALL_ZERO value, the link-local 954 address field in the Binding Cache entry MUST NOT be updated. 956 2. The local mobility anchor MUST remove the previously created 957 route for the mobile node's home network prefix. Additionally, 958 if there are no other mobile node's sessions sharing the tunnel 959 to the previous mobile access gateway, the tunnel MUST also be 960 deleted applying considerations from section 5.6.1 (if the tunnel 961 is a dynamically created tunnel and not a fixed pre-established 962 tunnel). 964 3. The local mobility anchor MUST establish a bi-directional tunnel 965 to the mobile access gateway that sent the request. 966 Considerations from Section 5.6 MUST be applied for creating the 967 routing state. 969 4. The local mobility anchor MUST send the Proxy Binding 970 Acknowledgement message with the Status field set to 0 (Proxy 971 Binding Update Accepted). The message MUST be constructed as 972 specified in Section 5.3.6. 974 5.3.5. Binding De-Registration 976 1. If the received Proxy Binding Update request with the lifetime 977 value of zero, has a Source Address in the IPv6 header (or the 978 address in the Alternate Care-of Address option, if the option is 979 present) different from what is present in the Proxy-CoA address 980 field in the Binding Cache entry, the local mobility anchor MUST 981 ignore the request. 983 2. Upon accepting the Proxy Binding Update request with the lifetime 984 value of zero, the local mobility anchor MUST wait for 985 MinDelayBeforeBCEDelete amount of time, before it deletes the 986 Binding Cache entry. However, it MUST send the Proxy Binding 987 Acknowledgement message with the Status field set to 0 (Proxy 988 Binding Update Accepted). The message MUST be constructed as 989 specified in Section 5.3.6. 991 * During this wait period, the local mobility anchor SHOULD drop 992 the mobile node's data traffic. 994 * During this wait period, if the local mobility anchor receives 995 a valid Proxy Binding Update request for the same mobility 996 session with the lifetime value of greater than zero, and if 997 that request is accepted, then the Binding Cache entry MUST 998 NOT be deleted, but must be updated with the newly accepted 999 registration values and additionally the wait period should be 1000 ended. 1002 * By the end of this wait period, if the local mobility anchor 1003 did not receive any valid Proxy Binding Update request for 1004 this mobility session, then it MUST delete the Binding Cache 1005 entry and remove the routing state created for that mobility 1006 session. 1008 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1010 o The local mobility anchor when sending the Proxy Binding 1011 Acknowledgement message to the mobile access gateway MUST 1012 construct the message as specified below. 1014 IPv6 header (src=LMAA, dst=Proxy-CoA) 1015 Mobility header 1016 - BA /* P flag must be set to value of 1 */ 1017 Mobility Options 1018 - Mobile Node Identifier Option (mandatory) 1019 - Home Network Prefix option (mandatory) 1020 - Handoff Indicator option (mandatory) 1021 - Access Technology Type option (mandatory) 1022 - Timestamp Option (optional) 1023 - Mobile Node Interface Identifier option (optional) 1024 - Link-local Address option (optional) 1026 Figure 6: Proxy Binding Acknowledgement message format 1028 o The Source Address field in the IPv6 header of the message MUST be 1029 set to the destination address of the received Proxy Binding 1030 Update request. 1032 o The Destination Address field in the IPv6 header of the message 1033 MUST be set to the source address of the received Proxy Binding 1034 Update request. When there is no Alternate Care-of Address option 1035 present in the request, the destination address is the same as the 1036 Proxy-CoA address, otherwise, the address may not be the same as 1037 the Proxy-CoA. 1039 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1040 identifier field in the option MUST be copied from the Mobile Node 1041 Identifier option in the received Proxy Binding Update request. 1042 If the option was not present in the request, the identifier in 1043 the option MUST be set to a zero length identifier. 1045 o The Home Network Prefix option MUST be present. 1047 * If the Status field is set to a value greater than or equal to 1048 128, i.e., if the binding request is rejected, then the prefix 1049 value in the Home Network Prefix option MUST be set to the 1050 prefix value in the Home Network Prefix option of the received 1051 Proxy Binding Update request. But, if the option was not 1052 present in the request, the value in the option MUST be set to 1053 ALL_ZERO. 1055 * For all other cases, the prefix value in the option MUST be set 1056 to the allocated prefix value for that mobility session. 1058 o The Handoff Indicator option MUST be present. The handoff 1059 indicator field in the option MUST be copied from the Handoff 1060 Indicator option in the received Proxy Binding Update request. If 1061 the option was not present in the request, the value in the option 1062 MUST be set to zero. 1064 o The Access Technology Type option MUST be present. The access 1065 technology type field in the option MUST be copied from the Access 1066 Technology Type option in the received Proxy Binding Update 1067 request. If the option was not present in the request, the value 1068 in the option MUST be set to zero. 1070 o The Timestamp option MUST be present, if the same option was 1071 present in the received Proxy Binding Update request. 1072 Considerations from Section 5.5 must be applied for constructing 1073 the Timestamp option. 1075 o The Mobile Node Interface Identifier option MUST be present, if 1076 the same option was present in the received Proxy Binding Update 1077 request. The interface identifier value MUST be copied from the 1078 Mobile Node Interface Indicator option present in the received 1079 Proxy Binding Update request. 1081 o The Link-local Address option MUST be present, if the same option 1082 was present in the received Proxy Binding Update request. 1084 * If the received Proxy Binding Update request has the Link-local 1085 Address option with any value other than ALL_ZERO, the same 1086 value MUST be copied to the Link-local Address option in the 1087 reply. 1089 * If there is no existing Binding Cache entry (i.e., if this is a 1090 request for a new mobility session), or if there is an existing 1091 Binding Cache entry with the link-local address value set to 1092 ALL_ZERO, then the link-local address in the option MUST be 1093 copied from the Link-local Address option present in the 1094 received Proxy Binding Update request. 1096 * For all other cases, the link-local address in the option MUST 1097 be copied from the Link-local Address field of the Binding 1098 Cache entry. 1100 o If IPsec is used for protecting the signaling messages, the 1101 message MUST be protected, using the security association existing 1102 between the local mobility anchor and the mobile access gateway. 1104 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1105 NOT be present in the IPv6 header of the packet. 1107 5.4. Multihoming Support 1109 This specification allows mobile nodes to connect to a Proxy Mobile 1110 IPv6 domain through multiple interfaces and for simultaneous access. 1111 Following are the key aspects of this multihoming support. 1113 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1114 multiple interfaces and for simultaneous access, the local 1115 mobility anchor MUST allocate a unique home network prefix for 1116 each of the connected interfaces. 1118 o The local mobility anchor MUST manage each of the allocated home 1119 network prefixes as part of a separate mobility session, each 1120 under a separate Binding Cache entry and with its own lifetime. 1122 o The local mobility anchor MUST allow for an handoff between two 1123 different interfaces of the mobile node. In such a case, the home 1124 network prefix that is associated with a specific interface 1125 identifier of a mobile node will be updated with the new interface 1126 identifier. The decision on when to create a new mobility session 1127 and when to update an existing mobility session MUST be based on 1128 the Handover hint present in the Proxy Binding Update message and 1129 under the considerations specified in this section. 1131 5.4.1. Binding Cache entry lookup considerations 1133 There can be multiple Binding Cache entries for a given mobile node. 1134 When doing a lookup for a mobile node's Binding Cache entry for 1135 processing a received Proxy Binding Update request message, the local 1136 mobility anchor MUST apply the following multihoming considerations 1137 (in the below specified order). These rules are chained with the 1138 processing rules specified in Section 5.3. 1140 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1141 request 1143 +=====================================================================+ 1144 | Registration/De-Registration Message | 1145 +=====================================================================+ 1146 | HNP (NON_ZERO Value) | 1147 +=====================================================================+ 1148 | ATT | 1149 +=====================================================================+ 1150 | IID Option Present | IID Option Not present | 1151 +=====================================================================+ 1152 | HI | 1153 +==================================+==================================+ 1154 | BCE Lookup Key: (Home Network Prefix) | 1155 +=====================================================================+ 1157 Figure 7: BCE lookup using home network prefix 1159 1. The local mobility anchor MUST verify if there is an existing 1160 Binding Cache entry with the home network prefix value matching 1161 the prefix value in the Home Network Prefix option of the 1162 received Proxy Binding Update request. [BCE(HNP) equals 1163 PBU(HNP)] 1165 2. If there does not exist a Binding Cache entry (matching the MN- 1166 HNP), the request MUST be considered as a request for creating a 1167 new mobility session. 1169 3. If there exists a Binding Cache entry (matching MN-HNP), and if 1170 the mobile node identifier in the entry does not match the mobile 1171 node identifier in the Mobile Node Identifier option of the 1172 received Proxy Binding Update request, the local mobility anchor 1173 MUST reject the request with the Status field value set to 1174 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1175 authorized for the requesting home network prefix). [BCE(MN- 1176 Identifier) not equals PBU(MN-Identifier)] 1178 4. If there exists a Binding Cache entry (matching MN-Identifier and 1179 MN-HNP) and if any one or more of these below stated conditions 1180 match, the request MUST be considered as a request for updating 1181 that Binding Cache entry. [BCE(MN-Identifier) equals PBU(MN- 1182 Identifier)] 1184 * If there is a Mobile Node Interface Identifier option present 1185 in the request, and if the interface identifier value in that 1186 option matches the interface identifier value in the Binding 1187 Cache entry and the access technology type field in the Access 1188 Technology Type option present in the request matches the 1189 access technology type in the Binding Cache entry . [BCE(ATT, 1190 MN-Interface-Identifier) equals PBU(ATT, MN-Interface- 1191 Identifier)] 1193 * If the Handoff Indicator field in the Handoff Indicator option 1194 present in the request is set to a value of 2 (Handoff between 1195 two different interfaces of the mobile node). [PBU(HI) equals 1196 2] 1198 * If there is no Mobile Node Interface Identifier option present 1199 in the request, the interface identifier value in the Binding 1200 Cache entry is set to ALL_ZERO, the access technology type 1201 field in the Access Technology Type option present in the 1202 request matches the access technology type in the Binding 1203 Cache entry and if the Handoff Indicator field in the Handoff 1204 Indicator option present in the request is set to a value of 3 1205 (Handoff between mobile access gateways for the same 1206 interface). 1208 * If the Proxy-CoA address in the Binding Cache entry matches 1209 the source address of the request (or the address in the 1210 alternate Care-of Address option, if the option is present) 1211 and if the access technology type field in the Access 1212 Technology Type option present in the request matches the 1213 access technology type in the Binding Cache entry. 1214 [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)]. 1216 5. For all other cases, the message MUST be considered as a request 1217 for creating a new mobility session. 1219 5.4.1.2. Mobile Node Interface Identifier Option present in the request 1221 +=====================================================================+ 1222 | Registration/De-Registration Message | 1223 +=====================================================================+ 1224 | HNP (ALL_ZERO Value) | 1225 +=====================================================================+ 1226 | ATT | 1227 +=====================================================================+ 1228 | IID Option Present (NON_ZERO Value) | 1229 +=====================================================================+ 1230 | HI | 1231 +==================================+==================================+ 1232 | BCE Lookup Keys: (MN-Identifier + Access Technology Type + | 1233 | MN-Interface-Identifier) | 1234 +=====================================================================+ 1236 Figure 8: BCE Lookup using Interface Identifier 1238 1. The local mobility anchor MUST verify if there is an existing 1239 Binding Cache entry, with the mobile node identifier matching the 1240 identifier in the received Mobile Node Identifier option, access 1241 technology type matching the value in the received Access 1242 Technology Type option and the interface identifier value 1243 matching the identifier in the received Mobile Node Interface 1244 Identifier option. [BCE(MN-Identifier, ATT, MN-Interface- 1245 Identifier) equals PBU(MN-Identifier, ATT, MN-Interface- 1246 Identifier)] 1248 2. If there exists a Binding Cache entry (matching MN-Identifier, 1249 ATT and MN-Interface-Identifier), the request MUST be considered 1250 as a request for updating that Binding Cache entry. 1252 3. If there does not exist a Binding Cache entry (matching MN- 1253 Identifier, ATT and MN-Interface-Identifier) and the Handoff 1254 Indicator field in the Handoff Indicator option present in the 1255 request is set to a value of 2 (Handoff between two different 1256 interfaces of the mobile node). The local mobility anchor MUST 1257 apply the following additional considerations. [PBU(HI) equals 1258 2] 1260 * The local mobility anchor MUST verify if there exists one and 1261 only one Binding Cache entry with the mobile node identifier 1262 matching the identifier in the Mobile Node Identifier option 1263 present in the request and for any interface identifier value. 1264 If there exists only one such entry (matching the MN- 1265 Identifier), the request MUST be considered as a request for 1266 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1267 PBU(MN-Identifier)] 1269 4. If there does not exist a Binding Cache entry (matching MN- 1270 Identifier, ATT and MN-Interface-Identifier) and if the Handoff 1271 Indicator field in the Handoff Indicator option present in the 1272 request is set to a value of 4 (Handoff state unknown), the local 1273 mobility anchor MUST apply the following additional 1274 considerations. 1276 * The local mobility anchor MUST verify if there exists one and 1277 only one Binding Cache entry with the mobile node identifier 1278 matching the identifier in the Mobile Node Identifier option 1279 present in the request and for any interface identifier value. 1280 If there exists only one such entry (matching the MN- 1281 Identifier), the local mobility anchor SHOULD wait till the 1282 existing Binding Cache entry is de-registered by the 1283 previously serving mobile access gateway, before the request 1284 can be considered as a request for updating that Binding Cache 1285 entry. However, if there is no de-registration message that 1286 is received within MaxDelayBeforeNewBCEAssign amount of time, 1287 the local mobility anchor upon accepting the request MUST 1288 consider the request as a request for creating a new mobility 1289 session. The local mobility anchor MAY also choose to create 1290 a new mobility session and without waiting for a de- 1291 registration message and this should be configurable on the 1292 local mobility anchor. 1294 5. For all other cases, the message MUST be considered as a request 1295 for creating a new mobility session. 1297 5.4.1.3. Mobile Node Interface Identifier Option not present in the 1298 request 1300 +=====================================================================+ 1301 | Registration/De-Registration Message | 1302 +=====================================================================+ 1303 | HNP (ALL_ZERO Value) | 1304 +=====================================================================+ 1305 | ATT | 1306 +=====================================================================+ 1307 | IID Option Not Present | 1308 +=====================================================================+ 1309 | HI | 1310 +==================================+==================================+ 1311 | BCE Lookup Key: (MN-Identifier) | 1312 +=====================================================================+ 1314 Figure 9: BCE Lookup using Mobile Node Identifier 1316 1. The local mobility anchor MUST verify if there exists one and 1317 only one Binding Cache entry with the mobile node identifier 1318 matching the identifier in the Mobile Node Identifier option 1319 present in the request. 1321 2. If there exists only one such entry (matching the MN-Identifier) 1322 and the Handoff Indicator field in the Handoff Indicator option 1323 present in the request is set to a value of 2 (Handoff between 1324 two different interfaces of the mobile node), the request MUST be 1325 considered as a request for updating that Binding Cache entry. 1326 [PBU(HI) equals 2] 1328 3. If there exists only one such entry (matching the MN-Identifier) 1329 and the Handoff Indicator field in the Handoff Indicator option 1330 present in the request is set to a value of 4 (Handoff state 1331 unknown), the local mobility anchor SHOULD wait till the existing 1332 Binding Cache entry is de-registered by the previously serving 1333 mobile access gateway, before the request can be considered as a 1334 request for updating that Binding Cache entry. However, if there 1335 is no de-registration message that is received within 1336 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1337 anchor upon accepting the request MUST consider the request as a 1338 request for creating a new mobility session. The local mobility 1339 anchor MAY also choose to create a new mobility session and 1340 without waiting for a de-registration message and this should be 1341 configurable on the local mobility anchor. 1343 4. For all other cases, the message MUST be considered as a request 1344 for creating a new mobility session. 1346 5.5. Timestamp Option for Message Ordering 1348 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1349 registration messages as a way for the home agent to process the 1350 binding updates in the order they were sent by a mobile node. The 1351 home agent and the mobile node are required to manage this counter 1352 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1353 the mobile node moves from one mobile access gateway to another and 1354 in the absence of mechanisms such as context transfer between the 1355 mobile access gateways, the serving mobile access gateway will be 1356 unable to determine the sequence number that it needs to use in the 1357 signaling messages. Hence, the sequence number scheme, as specified 1358 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1360 If the local mobility anchor cannot determine the sending order of 1361 the received binding registration messages, it may potentially 1362 process an older message sent by a mobile access gateway where the 1363 mobile node was previously anchored, resulting in an incorrect 1364 Binding Cache entry. 1366 For solving this problem, this specification adopts two alternative 1367 solutions. One is based on timestamps and the other based on 1368 sequence numbers, as defined in [RFC-3775]. 1370 The basic principle behind the use of timestamps in binding 1371 registration messages is that the node generating the message inserts 1372 the current time-of-day, and the node receiving the message checks 1373 that this timestamp is greater than all previously accepted 1374 timestamps. The timestamp based solution may be used, when the 1375 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1376 have the ability to obtain the last sequence number that was sent in 1377 a binding registration message for updating a given mobile node's 1378 binding. 1380 As an alternative to the Timestamp based approach, the specification 1381 also allows the use of Sequence Number based scheme, as per [RFC- 1382 3775]. However, for this scheme to work, the serving mobile access 1383 gateways in a Proxy Mobile IPv6 domain MUST have the ability to 1384 obtain the last sequence number that was sent in a binding 1385 registration message for updating a given mobile node's binding. The 1386 sequence number MUST be maintained on a per mobile node basis and 1387 MUST be synchronized between the serving mobile access gateways. 1389 This may be achieved by using context transfer schemes or by 1390 maintaining the sequence number in a policy store. However, the 1391 specific details on how the mobile node's sequence number is 1392 synchronized between different mobile access gateways is outside the 1393 scope of this document. 1395 Using Timestamps based approach: 1397 1. A local mobility anchor implementation MUST support Timestamp 1398 option. If the Timestamp option is present in the received Proxy 1399 Binding Update request message, then the local mobility anchor 1400 MUST include a valid Timestamp option in the Proxy Binding 1401 Acknowledgement message that it sends to the mobile access 1402 gateway. 1404 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1405 exchanging binding registration messages using the Timestamp 1406 option must have adequately synchronized time-of-day clocks. 1407 This is the essential requirement for this solution to work. If 1408 this requirement is not met, the solution will not predictably 1409 work in all cases. 1411 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1412 synchronize their clocks to a common time source. For 1413 synchronizing the clocks, the nodes may use Network Time Protocol 1414 [RFC-4330]. Deployments may also adopt other approaches suitable 1415 for that specific deployment. Alternatively, if there is mobile 1416 node generated timestamp that is increasing at every attachment 1417 to the access link and if that timestamp is available to the 1418 mobile access gateway (Ex: The timestamp option in the SEND 1419 messages that the mobile node sends), the mobile access gateway 1420 can use this timestamp or sequence number in the Proxy Binding 1421 Update messages and does not have to depend on any external clock 1422 source. However, the specific details on how this is achieved is 1423 outside the scope of this document. 1425 4. When generating the timestamp value for building the Timestamp 1426 option, the mobility entities MUST ensure that the generated 1427 timestamp is the elapsed time past the same reference epoch, as 1428 specified in the format for the Timestamp option [Section 8.8]. 1430 5. If the Timestamp option is present in the received Proxy Binding 1431 Update message, the local mobility anchor MUST ignore the 1432 sequence number field in the message. However, it MUST copy the 1433 sequence number from the received Proxy Binding Update message to 1434 the Proxy Binding Acknowledgement message. 1436 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1437 option, the local mobility anchor MUST check the timestamp field 1438 for validity. In order for it to be considered valid, the 1439 timestamp value contained in the Timestamp option MUST be close 1440 enough (within TimestampValidityWindow amount of time difference) 1441 to the local mobility anchor's time-of-day clock and the 1442 timestamp MUST be greater than all previously accepted timestamps 1443 in the Proxy Binding Update messages sent for that mobile node. 1445 7. If the timestamp value in the received Proxy Binding Update is 1446 valid (validity as specified in the above considerations), the 1447 local mobility anchor MUST return the same timestamp value in the 1448 Timestamp option included in the Proxy Binding Acknowledgement 1449 message that it sends to the mobile access gateway. 1451 8. If the timestamp value in the received Proxy Binding Update is 1452 lower than the previously accepted timestamp in the Proxy Binding 1453 Update messages sent for that mobility binding, the local 1454 mobility anchor MUST reject the Proxy Binding Update request and 1455 send a Proxy Binding Acknowledgement message with Status field 1456 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1457 previously accepted timestamp). The message MUST also include 1458 the Timestamp option with the value set to the current time-of- 1459 day on the local mobility anchor. 1461 9. If the timestamp value in the received Proxy Binding Update is 1462 not valid (validity as specified in the above considerations), 1463 the local mobility anchor MUST reject the Proxy Binding Update 1464 and send a Proxy Binding Acknowledgement message with Status 1465 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1466 message MUST also include the Timestamp option with the value set 1467 to the current time-of-day on the local mobility anchor. 1469 Using Sequence Number based approach: 1471 1. If the Timestamp option is not present in the received Proxy 1472 Binding Update request, the local mobility anchor MUST fallback 1473 to the Sequence Number based scheme. It MUST process the 1474 sequence number field as specified in [RFC-3775]. Also, it MUST 1475 NOT include the Timestamp option in the Proxy Binding 1476 Acknowledgement messages that it sends to the mobile access 1477 gateway. 1479 2. An implementation MUST support Sequence Number based scheme, as 1480 per [RFC-3775]. 1482 5.6. Routing Considerations 1484 5.6.1. Bi-Directional Tunnel Management 1486 o A bi-directional tunnel MUST be established between the local 1487 mobility anchor and the mobile access gateway with IP-in-IP 1488 encapsulation, as described in [RFC-2473]. The tunnel end points 1489 are the Proxy-CoA and LMAA. When using IPv4 transport with a 1490 specific encapsulation mode, the end points of the tunnel are the 1491 IPv4-LMAA and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. 1493 o The bi-directional tunnel MUST be used for routing the mobile 1494 node's data traffic between the mobile access gateway and the 1495 local mobility anchor. The tunnel hides the topology and enables 1496 a mobile node to use an address from its home network prefix from 1497 any access link attached to the mobile access gateway. 1499 o The bi-directional tunnel is established after accepting the Proxy 1500 Binding Update request message. The created tunnel may be shared 1501 with other mobile nodes attached to the same mobile access gateway 1502 and with the local mobility anchor having a Binding Cache entry 1503 for those mobile nodes. Implementations MAY choose to use static 1504 tunnels instead of dynamically creating and tearing them down on a 1505 need basis. 1507 o Implementations MAY use a software timer for managing the tunnel 1508 lifetime and a counter for keeping a count of all the mobile nodes 1509 that are sharing the tunnel. The timer value MUST be set to the 1510 accepted binding lifetime and will be updated after each periodic 1511 re-registration for extending the lifetime. If the tunnel is 1512 shared for multiple mobile nodes, the tunnel lifetime MUST be set 1513 to the highest binding lifetime that is granted to any one of 1514 those mobile nodes sharing that tunnel. 1516 5.6.2. Forwarding Considerations 1518 Intercepting Packets Sent to the Mobile Node's Home Network: 1520 o When the local mobility anchor is serving a mobile node, it MUST 1521 be able to receive packets that are sent to the mobile node's home 1522 network. In order for it to receive those packets, it MUST 1523 advertise a connected route in to the Routing Infrastructure for 1524 the mobile node's home network prefix or for an aggregated prefix 1525 with a larger scope. This essentially enables IPv6 routers in 1526 that network to detect the local mobility anchor as the last-hop 1527 router for that prefix. 1529 Forwarding Packets to the Mobile Node: 1531 o On receiving a packet from a correspondent node with the 1532 destination address matching a mobile node's home network prefix, 1533 the local mobility anchor MUST forward the packet through the bi- 1534 directional tunnel setup for that mobile node. The format of the 1535 tunneled packet is shown below. However, when using IPv4 1536 transport, the format of the packet is as described in [ID-IPV4- 1537 PMIP6]. 1539 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1540 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1541 Upper layer protocols /* Packet Content*/ 1543 Figure 10: Tunneled Packets from LMA to MAG 1545 Forwarding Packets Sent by the Mobile Node: 1547 o All the reverse tunneled packets that the local mobility anchor 1548 receives from the mobile access gateway, after removing the tunnel 1549 header MUST be routed to the destination specified in the inner 1550 packet header. These routed packets will have the source address 1551 field set to the mobile node's home address. 1553 5.7. Local Mobility Anchor Address Discovery 1555 Dynamic Home Agent Address Discovery, as explained in Section 10.5 1556 [RFC-3775], allows a mobile node to discover all the home agents on 1557 its home link by sending an ICMP Home Agent Address Discovery Request 1558 message to the Mobile IPv6 Home-Agents anycast address, derived from 1559 its home network prefix. 1561 The DHAAD message in the current form cannot be used in Proxy Mobile 1562 IPv6 for discovering the address of the mobile node's local mobility 1563 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1564 able to receive any messages sent to the Mobile IPv6 Home-Agents 1565 anycast address corresponding to the mobile node's home network 1566 prefix, as the prefix is not hosted on any of its interfaces. 1567 Further, the mobile access gateway will not predictably be able to 1568 locate the serving local mobility anchor that has the mobile node's 1569 binding cache entry. Hence, this specification does not support 1570 Dynamic Home Agent Address Discovery protocol. 1572 In Proxy Mobile IPv6, the address of the local mobility anchor 1573 configured to serve a mobile node can be discovered by the mobility 1574 entities in other ways. This may be a configured entry in the mobile 1575 node's policy profile, or it may be obtained through mechanisms 1576 outside the scope of this document. 1578 5.8. Mobile Prefix Discovery Considerations 1580 This specification does not support mobile prefix discovery. The 1581 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1582 applicable to Proxy Mobile IPv6. 1584 5.9. Route Optimizations Considerations 1586 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1587 enables a mobile node to communicate with a correspondent node 1588 directly using its care-of address and further the Return Routability 1589 procedure enables the correspondent node to have reasonable trust 1590 that the mobile node is reachable at both its home address and 1591 care-of address. 1593 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1594 mobility related signaling. The mobile node uses only its home 1595 address for all its communication and the Care-of address (Proxy-CoA) 1596 is not visible to the mobile node. Hence, the Return Routability 1597 procedure as defined in Mobile IPv6 [RFC-3775] cannot be used in 1598 Proxy Mobile IPv6. 1600 6. Mobile Access Gateway Operation 1602 The Proxy Mobile IPv6 protocol described in this document introduces 1603 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1604 access gateway is the entity that is responsible for detecting the 1605 mobile node's movements to and from the access link and sending the 1606 binding registration requests to the local mobility anchor. In 1607 essence, the mobile access gateway performs mobility management on 1608 behalf of a mobile node. 1610 The mobile access gateway is a function that typically runs on an 1611 access router. However, implementations MAY choose to split this 1612 function and run it across multiple systems. The specifics on how 1613 that is achieved or the signaling interactions between those 1614 functional entities are beyond the scope of this document. 1616 The mobile access gateway has the following key functional roles: 1618 o It is responsible for detecting the mobile node's movements on the 1619 access link and for initiating the mobility signaling with the 1620 mobile node's local mobility anchor. 1622 o Emulation of the mobile node's home link on the access link by 1623 sending Router Advertisements with the mobile node's home network 1624 prefix information. 1626 o Responsible for setting up the data path for enabling the mobile 1627 node to configure an address from its home network prefix and use 1628 it from its access link. 1630 6.1. Extensions to Binding Update List Entry Data Structure 1632 Every mobile access gateway MUST maintain a Binding Update List. 1633 Each entry in the Binding Update List represents a mobile node's 1634 mobility binding with its local mobility anchor. The Binding Update 1635 List is a conceptual data structure, described in Section 11.1 [RFC- 1636 3775]. 1638 For supporting this specification, the conceptual Binding Update List 1639 entry data structure needs be extended with the following additional 1640 fields. 1642 o The Identifier of the attached mobile node, MN-Identifier. This 1643 identifier is acquired during the mobile node's attachment to the 1644 access link through mechanisms outside the scope of this document. 1646 o The interface identifier of the mobile node's connected interface. 1647 This address can be acquired from the received Router Solicitation 1648 messages from the mobile node or during the mobile node's 1649 attachment to the access network. This is typically a Layer-2 1650 identifier conveyed by the mobile node; however, the specific 1651 details on how that is conveyed is out of scope for this 1652 specification. If this identifier is not available, the value 1653 MUST be set to ALL_ZERO. 1655 o The IPv6 home network prefix of the attached mobile node. The 1656 home network prefix of the mobile node is acquired from the mobile 1657 node's local mobility anchor through the received Proxy Binding 1658 Acknowledgement messages. The IPv6 home network prefix also 1659 includes the corresponding prefix length. 1661 o The Link-local address of the mobile node on the interface 1662 attached to the access link. 1664 o The IPv6 address of the local mobility anchor serving the attached 1665 mobile node. This address is acquired from the mobile node's 1666 policy profile or from other means. 1668 o The interface identifier (If-Id) of the access link where the 1669 mobile node is currently attached. This is internal to the mobile 1670 access gateway and is used to associate the Proxy Mobile IPv6 1671 tunnel to the access link where the mobile node is attached. 1673 o The interface identifier (If-Id) of the bi-directional tunnel 1674 between the mobile node's local mobility anchor and the mobile 1675 access gateway. This is internal to the mobile access gateway. 1676 The tunnel interface identifier is acquired during the tunnel 1677 creation. 1679 6.2. Mobile Node's Policy Profile 1681 A mobile node's policy profile contains the essential operational 1682 parameters that are required by the network entities for managing the 1683 mobile node's mobility service. These policy profiles are stored in 1684 a local or a remote policy store. The mobile access gateway and the 1685 local mobility anchor MUST be able to obtain a mobile node's policy 1686 profile. The policy profile MAY also be handed over to a serving 1687 mobile access gateway as part of a context transfer procedure during 1688 a handoff or the serving mobile access gateway MAY be able to 1689 dynamically generate this profile. The exact details on how this 1690 achieved is outside the scope of this document. However, this 1691 specification requires that a mobile access gateway serving a mobile 1692 node MUST have access to its policy profile. 1694 The following are the mandatory fields of the policy profile: 1696 o The mobile node's identifier (MN-Identifier) 1698 o The IPv6 address of the local mobility anchor (LMAA) 1700 The following are the optional fields of the policy profile: 1702 o The mobile node's IPv6 home network prefix (MN-HNP) 1704 o The mobile node's IPv6 home network Prefix lifetime 1706 o Supported address configuration procedures (Stateful, Stateless or 1707 both) for the mobile node in the Proxy Mobile IPv6 domain 1709 6.3. Supported Access Link Types 1711 This specification supports only point-to-point access link types and 1712 thus it assumes that the mobile node and the mobile access gateway 1713 are the only two nodes on the access link. The link is assumed to 1714 have multicast capability. This protocol may also be used on other 1715 link types, as long as the link is configured in such a way that it 1716 guarantees a point-to-point delivery between the mobile node and the 1717 mobile access gateway for all the protocol traffic. 1719 6.4. Supported Address Configuration Modes 1721 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1722 more IPv6 addresses on its interface using Stateless or Stateful 1723 address autoconfiguration procedures. The Router Advertisement 1724 messages sent on the access link specify the address configuration 1725 methods permitted on that access link for that mobile node. However, 1726 the advertised flags with respect to the address configuration will 1727 be consistent for a mobile node, on any of the access links in that 1728 Proxy Mobile IPv6 domain. Typically, these configuration settings 1729 will be based on the domain wide policy or based on a policy specific 1730 to each mobile node. 1732 When stateless address autoconfiguration is supported on the access 1733 link, the mobile node can generate one or more IPv6 addresses by 1734 standard IPv6 mechanisms such as Stateless Autoconfiguration 1735 specification [RFC-4862] or Privacy extension specification [RFC- 1736 4941]. 1738 When stateful address autoconfiguration is supported on the link, the 1739 mobile node can obtain the address configuration from the DHCPv6 1740 server located in the Proxy Mobile IPv6 domain, by standard DHCPv6 1741 mechanisms, as specified in DHCPv6 specification [RFC-3315]. The 1742 obtained address will be from its respective home network prefix. 1743 Section 6.11 specifies the details on how this configuration can be 1744 achieved. 1746 Additionally, other address configuration mechanisms specific to the 1747 access link between the mobile node and the mobile access gateway may 1748 also be used for pushing the address configuration to the mobile 1749 node. This specification does not change the behavior of address 1750 configuration mechanisms in any way. 1752 6.5. Access Authentication & Mobile Node Identification 1754 When a mobile node attaches to an access link connected to the mobile 1755 access gateway, the deployed access security protocols on that link 1756 SHOULD ensure that the network-based mobility management service is 1757 offered only after authenticating and authorizing the mobile node for 1758 that service. The exact specifics on how this is achieved or the 1759 interactions between the mobile access gateway and the access 1760 security service is outside the scope of this document. This 1761 specification goes with the stated assumption of having an 1762 established trust between the mobile node and the mobile access 1763 gateway, before the protocol operation begins. 1765 6.6. Acquiring Mobile Node's Identifier 1767 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1768 to identify a mobile node, using its MN-Identifier. This identifier 1769 MUST be stable across the Proxy Mobile IPv6 domain and the entities 1770 must be able to use this identifier in the signaling messages. 1771 Typically, this identifier is obtained as part of the access 1772 authentication or through other means as specified below. 1774 o The identifier of the mobile node that the mobile access gateway 1775 obtains typically as part of the access authentication or from the 1776 notified network attachment event, can be a temporary identifier 1777 and further that temporary identifier may be different at each re- 1778 authentication. The mobile access gateway MUST be able to use 1779 this temporary identifier and obtain the mobile node's stable 1780 identifier from the policy store. For instance, in AAA-based 1781 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1782 4372] may be used. 1784 o The MN-Identifier that the policy store delivers to the mobile 1785 access gateway may not be the true identifier of the mobile node. 1786 However, the mobility access gateway MUST be able to use this 1787 identifier in the signaling messages exchanged with the local 1788 mobility anchor. 1790 o The mobile access gateway MUST be able to identify the mobile node 1791 by its MN-Identifier and it MUST be able to associate this 1792 identity to the point-to-point link shared with the mobile node. 1794 6.7. Home Network Emulation 1796 One of the key functions of a mobile access gateway is to emulate the 1797 mobile node's home network on the access link. It must ensure, the 1798 mobile node believes it is still connected to its home link or on the 1799 link where it obtained its initial address configuration after it 1800 moved into that Proxy Mobile IPv6 domain. 1802 For emulating the mobile node's home link on the access link, the 1803 mobile access gateway must be able to send Router Advertisements 1804 advertising the mobile node's home network prefix and other address 1805 configuration parameters consistent with its home link properties. 1806 Typically, these configuration settings will be based on the domain 1807 wide policy or based on a policy specific to each mobile node. 1809 Typically, the mobile access gateway learns the mobile node's home 1810 network prefix information from the received Proxy Binding 1811 Acknowledgement message or it may be obtained from the mobile node's 1812 policy profile. However, the mobile access gateway SHOULD send the 1813 Router Advertisements advertising the mobile node's home network 1814 prefix only after successfully completing the binding registration 1815 with the mobile node's local mobility anchor. 1817 When advertising the home network prefix in the Router Advertisement 1818 messages, the mobile access gateway MAY set the prefix lifetime value 1819 for the advertised prefix to any chosen value at its own discretion. 1820 An implementation MAY choose to tie the prefix lifetime to the mobile 1821 node's binding lifetime. The prefix lifetime can also be an optional 1822 configuration parameter in the mobile node's policy profile. 1824 6.8. Link-Local and Global Address Uniqueness 1826 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1827 mobile access gateway to the other, will continue to detect its home 1828 network and thus making it believe it is still on the same link. 1829 Every time the mobile node attaches to a new link, the event related 1830 to the interface state change will trigger the mobile node to perform 1831 DAD operation on the link-local and global addresses. However, if 1832 the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may 1833 not detect the link change due to DNAv6 optimizations and may not 1834 trigger the duplicate address detection (DAD) procedure for 1835 establishing the link-local address uniqueness on that new link. 1836 This leaves a room for link-local address collision between the two 1837 neighbors on that access link. 1839 For solving this problem, this specification allows the mobile access 1840 gateway to upload the mobile node's link-local address to the local 1841 mobility anchor using the Link-local Address option, exchanged in the 1842 binding registration messages. The mobile access gateway can learn 1843 the mobile node's link-local address, by snooping the DAD messages 1844 sent by the mobile node for establishing the link-local address 1845 uniqueness on the access link. Subsequently, at each handoff, the 1846 mobile access gateway can obtain this address from the local mobility 1847 anchor to ensure link-local address uniqueness and change its own 1848 link-local address, if it detects a collision. 1850 Alternatively, one of the workarounds for this issue is to set the 1851 DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 1852 will force the mobile node to redo DAD operation on the global and 1853 link-local addresses every time the interface detects an handoff, 1854 even when DNAv6 does not detect a link change. 1856 However, this issue may not impact point-to-point links based on PPP. 1857 Each time the mobile node moves and attaches to a new mobile access 1858 gateway, the PPP session [RFC-1661] can be re-established, or if 1859 there are context transfer procedures in place, the entire PPP 1860 session can be moved to the new link and the link-local addresses of 1861 both the peers will continue to remain the same. In either of these 1862 approaches, the link-local address uniqueness on the link is assured. 1863 The specific details of how the PPP session is re-established without 1864 impacting any layer-3 sessions or how the PPP session can be moved 1865 between the mobile access gateways is outside the scope of this 1866 document. 1868 The issue of address collision is not relevant to the mobile node's 1869 global address. Since there is a unique home network prefix assigned 1870 for each mobile node, the uniqueness for the mobile node's global 1871 address is assured on the access link. 1873 6.9. Signaling Considerations 1875 6.9.1. Binding Registrations 1877 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 1879 1. After detecting a new mobile node on its access link, the mobile 1880 access gateway MUST identify the mobile node and acquire its MN- 1881 Identifier. If it determines that the network-based mobility 1882 management service needs to be offered to the mobile node, it 1883 MUST send a Proxy Binding Update message to the local mobility 1884 anchor. 1886 2. The Proxy Binding Update message MUST include the Mobile Node 1887 Identifier option [RFC-4283], carrying the MN-Identifier for 1888 identifying the mobile node. 1890 3. The Home Network Prefix option MUST be present in the Proxy 1891 Binding Update message. If the mobile access gateway learns the 1892 mobile node's home network prefix either from its policy store 1893 or from other means, the mobile access gateway MAY choose to 1894 specify the same in the Home Network Prefix option for 1895 requesting the local mobility anchor to allocate that prefix, 1896 otherwise it MUST specify a value of ALL_ZERO. If the specified 1897 value is ALL_ZERO, then the local mobility anchor will do the 1898 prefix assignment. 1900 4. The Handoff Indicator option MUST be present in the Proxy 1901 Binding Update message. The Handoff Indicator field in the 1902 Handoff Indicator option MUST be set to a value indicating the 1903 handoff hint. 1905 * The Handoff Indicator field MUST be set to value 1 1906 (Attachment over a new interface), if the mobile access 1907 gateway determines (under the Handoff Indicator 1908 considerations specified in this section) that the mobile 1909 node's current attachment to the network over this interface 1910 is not as a result of an handoff of an existing mobility 1911 session (over the same interface or through a different 1912 interface), but as a result of an attachment over a new 1913 interface. This essentially serves as a request to the local 1914 mobility anchor to create a new mobility session and not 1915 update any existing Binding Cache entry created for the same 1916 mobile node connected to the Proxy Mobile IPv6 domain through 1917 a different interface. 1919 * The Handoff Indicator field MUST be set to value 2 (Handoff 1920 between two different interfaces of the mobile node), if the 1921 mobile access gateway definitively knows the mobile node's 1922 current attachment is due to an handoff of an existing 1923 mobility session, between two different interfaces of the 1924 mobile node. 1926 * The Handoff Indicator field MUST be set to value 3 (Handoff 1927 between mobile access gateways for the same interface), if 1928 the mobile access gateway definitively knows the mobile 1929 node's current attachment is due to an handoff of an existing 1930 mobility session between two mobile access gateways and for 1931 the same interface of the mobile node. 1933 * The Handoff Indicator field MUST be set to value 4 (Handoff 1934 state unknown), if the mobile access gateway cannot determine 1935 if the mobile node's current attachment is due to an handoff 1936 of an existing mobility session. 1938 5. The mobile access gateway MUST apply the below considerations 1939 when choosing the value for the Handoff Indicator field. 1941 * The mobile access gateway can choose to use the value 2 1942 (Handoff between two different interfaces of the mobile 1943 node), only when it knows that the mobile node has on purpose 1944 switched from one interface to another, and the previous 1945 interface is going to be disabled. It may know this due to a 1946 number of factors. For instance, most cellular networks have 1947 controlled handovers where the network knows that the host is 1948 moving from one attachment to another. In this situation the 1949 link layer mechanism can inform the mobility functions that 1950 this is indeed a movement, not a new attachment. 1952 * Some link layers have interface identifiers that can be used 1953 to distinguish (a) the movement of a particular interface to 1954 a new attachment from (b) the attachment of new interface 1955 from the same host. Option value 3 (Handoff between mobile 1956 access gateways for the same interface)is appropriate in case 1957 a and value of 1 (Attachment over a new interface) in case b. 1959 * The mobile access gateway MUST NOT set the option value to 2 1960 (Handoff between two different interfaces of the mobile node) 1961 or 3 (Handoff between mobile access gateways for the same 1962 interface) if it can not be determined that the mobile node 1963 can move the address between the interfaces involved in the 1964 handover or that it is the same interface that has moved. 1965 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 1966 physical interfaces to the same domain may suffer unexpected 1967 failures. 1969 * Where no support from link-layer exists, the host and the 1970 network would need to inform each other about the intended 1971 movement. Proxy Mobile IPv6 protocol does not specify this 1972 and simply requires that knowledge about movements can be 1973 derived either from the link-layer or from somewhere else. 1974 The method by which this is accomplished is outside the scope 1975 of this specification. 1977 6. Either the Timestamp option or a valid sequence number 1978 maintained on a per mobile node basis (if Sequence Number based 1979 scheme is in use) MUST be present. When Timestamp option is 1980 added to the message, the mobile access gateway SHOULD also set 1981 the Sequence Number field to a value of a monotonically 1982 increasing counter (not to be confused with the per mobile node 1983 sequence number specified [RFC-3775]). The local mobility 1984 anchor will ignore this field when there is a Timestamp option 1985 present in the request, but will return the same value in the 1986 Proxy Binding Acknowledgement message. This will be useful for 1987 matching the reply to the request message. 1989 7. The Mobile Node Interface Identifier option carrying the 1990 interface identifier of the currently attached interface MUST be 1991 present in the Proxy Binding Update message, if the mobile 1992 access gateway knows the interface identifier of the mobile 1993 node's currently attached interface. If the interface 1994 identifier is not known or if the identifier value is ALL_ZERO, 1995 this option MUST NOT be present. 1997 8. The Access Technology Type option MUST be present in the Proxy 1998 Binding Update message. The access technology type field in the 1999 option SHOULD be set to the type of access technology using 2000 which the mobile node is currently attached to the mobile access 2001 gateway. 2003 9. The Link-local Address option MAY be present in the Proxy 2004 Binding Update message. Considerations from Section 6.8 MUST be 2005 applied when using the link-local address option. 2007 * When uploading the link-local address to the local mobility 2008 anchor, the value in the option MUST be set to the link-local 2009 address that is configured on the currently attached 2010 interface of the mobile node. 2012 * When querying the local mobility anchor for the mobile node's 2013 link-local address, the option MUST be set to ALL_ZERO value. 2014 This essentially serves as a request to the local mobility 2015 anchor to return the link-local address of the mobile node 2016 from the binding cache entry corresponding to this mobility 2017 session. 2019 10. The Proxy Binding Update message MUST be constructed as 2020 specified in Section 6.9.1.5. 2022 11. If there is no existing Binding Update List entry for that 2023 mobile node, the mobile access gateway MUST create a Binding 2024 Update List entry for the mobile node upon sending the Proxy 2025 Binding Update request. 2027 6.9.1.2. Receiving Binding Registration Reply 2029 On receiving a Proxy Binding Acknowledgement message (format 2030 specified in Section 8.2) from the local mobility anchor, the mobile 2031 access gateway MUST process the message as specified below. 2033 1. The received Proxy Binding Acknowledgement message (a Binding 2034 Acknowledgement message with the 'P' flag set to value of 1) 2035 MUST be authenticated as described in Section 4. When IPsec is 2036 used for message authentication, the SPI in the IPsec header 2037 [RFC-4306] of the received packet is needed for locating the 2038 security association, for authenticating the Proxy Binding 2039 Acknowledgement message . 2041 2. The mobile access gateway MUST observe the rules described in 2042 Section 9.2 [RFC-3775] when processing Mobility Headers in the 2043 received Proxy Binding Acknowledgement message. 2045 3. The mobile access gateway MUST apply the considerations 2046 specified in Section 5.5 for processing the Sequence Number 2047 field and the Timestamp option (if present), in the message. 2049 4. The mobile access gateway MUST ignore any checks, specified in 2050 [RFC-3775] related to the presence of Type 2 Routing header in 2051 the Proxy Binding Acknowledgement message. 2053 5. The mobile access gateway MAY use the mobile node identifier 2054 present in the Mobile Node Identifier option for matching the 2055 response to the request messages that it sent recently . 2056 However, if there are more than one request message in its 2057 request queue for the same mobile node, the sequence number 2058 field can be used for identifying the exact message from those 2059 messages. There are other ways to achieve this and 2060 implementations are free to adopt the best approach that suits 2061 their implementation. Additionally, if the received Proxy 2062 Binding Acknowledgement message does not match any of the Proxy 2063 Binding Update messages that it sent recently, the message MUST 2064 be ignored. 2066 6. If the received Proxy Binding Acknowledgement message has any 2067 one or more of the following options, Handoff Indicator option, 2068 Access Technology Type option, Mobile Node Interface Identifier 2069 option, Mobile Node Identifier option, carrying option values 2070 that are different from the option values present in the 2071 corresponding request (Proxy Binding Update) message, the 2072 message MUST be ignored as the local mobility anchor is expected 2073 to echo back all these listed options and with the same option 2074 values in the reply message. Further, the mobile access gateway 2075 MUST NOT retransmit the Proxy Binding Update message till an 2076 administrative action is taken. 2078 7. If the received Proxy Binding Acknowledgement message has the 2079 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2080 registration not enabled for the mobile node), the mobile access 2081 gateway SHOULD NOT send binding registration requests again for 2082 that mobile node. It MUST deny the mobility service to that 2083 mobile node. 2085 8. If the received Proxy Binding Acknowledgement message has the 2086 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2087 (Timestamp value lower than previously accepted value), the 2088 mobile access gateway SHOULD try to register again to reassert 2089 the mobile node's presence on its access link. The mobile 2090 access gateway is not specifically required to synchronize its 2091 clock upon receiving this error code. 2093 9. If the received Proxy Binding Acknowledgement message has the 2094 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2095 value), the mobile access gateway SHOULD try to register again 2096 only after it has synchronized its clock to a common time source 2097 that is used by all the mobility entities in that domain for 2098 their clock synchronization. The mobile access gateway SHOULD 2099 NOT synchronize its clock to the local mobility anchor's system 2100 clock, based on the timestamp present in the received message. 2102 10. If the received Proxy Binding Acknowledgement message has the 2103 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2104 (mobile node is not authorized for the requesting home network 2105 prefix), the mobile access gateway SHOULD NOT request for the 2106 same prefix again, but can request the local mobility anchor to 2107 dynamically assign a prefix, by specifying a ALL_ZERO value in 2108 the Home Network Prefix option carried in the subsequent Proxy 2109 Binding Update message. 2111 11. If the received Proxy Binding Acknowledgement message has the 2112 Status field value set to any value greater than or equal to 128 2113 (i.e., if the binding is rejected), the mobile access gateway 2114 MUST NOT advertise the mobile node's home network prefix in the 2115 Router Advertisements sent on that access link and there by 2116 denying mobility service to the mobile node. 2118 12. If the received Proxy Binding Acknowledgement message has the 2119 Status field value set to 0 (Proxy Binding Update accepted), the 2120 mobile access gateway MUST update the routing state, as 2121 explained in section 6.10, and MUST also update the Binding 2122 Update List entry for reflecting the accepted binding 2123 registration status. 2125 13. If the received Proxy Binding Acknowledgement message has the 2126 address in the Link-local Address option set to a value that 2127 matches its own link-local address on that access interface 2128 where the mobile node is anchored, the mobile access gateway 2129 MUST change its link-local address on that interface, to avoid 2130 link-local address collision on that access link. 2132 6.9.1.3. Extending Binding Lifetime 2134 1. For extending the lifetime of a currently registered mobile node 2135 (i.e., after a successful initial binding registration from the 2136 same mobile access gateway), the mobile access gateway can send a 2137 Proxy Binding Update message to the local mobility anchor with a 2138 new lifetime value. This re-registration message MUST be 2139 constructed with the same set of options as the initial binding 2140 registration message, under the considerations specified in 2141 Section 6.9.1.1. However the following exceptions apply. 2143 2. The prefix value in the Home Network Prefix option MUST be set to 2144 the currently assigned home network prefix. 2146 3. The Handoff Indicator field in the Handoff Indicator option MUST 2147 be set to a value of 5 (Handoff state not changed - Re- 2148 Registration). 2150 4. The value in the Link-local Address option (if the option was 2151 present in the initial registration message) MUST be set to the 2152 link-local address of the mobile node's attached interface. 2154 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2156 1. At any point, the mobile access gateway detects that the mobile 2157 node has moved away from its access link, or if it decides to 2158 terminate the mobile node's mobility session, it SHOULD send a 2159 Proxy Binding Update message to the local mobility anchor with 2160 the lifetime value set to zero. This de-registration message 2161 MUST be constructed with the same set of options as the initial 2162 binding registration message, under the considerations specified 2163 in Section 6.9.1.1. However, the following exceptions apply. 2165 2. The prefix value in the Home Network Prefix option MUST be set to 2166 the currently assigned home network prefix. 2168 3. The Handoff Indicator field in the Handoff Indicator option MUST 2169 be set to a value of 4 (Handoff state unknown). 2171 4. The value in the Link-local Address option (if the option was 2172 present in the initial registration message) MUST be set to the 2173 link-local address of the mobile node's attached interface. 2175 Either upon receipt of a Proxy Binding Acknowledgement message from 2176 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2177 timeout waiting for the reply, the mobile access gateway MUST do the 2178 following: 2180 1. It MUST remove the Binding Update List entry for the mobile node 2181 from its Binding Update List. 2183 2. It MUST withdraw the mobile node's home network prefix as the 2184 hosted on-link prefix, by sending a Router Advertisement message 2185 with the prefix lifetime value set to zero. 2187 3. It MUST remove the created routing state for tunneling the mobile 2188 node's traffic. 2190 4. It SHOULD teardown the point-to-point link shared with the mobile 2191 node. This action will force the mobile node to remove any IPv6 2192 address configuration on the interface connected to this point- 2193 to-point link. 2195 6.9.1.5. Constructing the Proxy Binding Update Message 2197 o The mobile access gateway when sending the Proxy Binding Update 2198 request to the local mobility anchor MUST construct the message as 2199 specified below. 2201 IPv6 header (src=Proxy-CoA, dst=LMAA) 2202 Mobility header 2203 - BU /* P & A flags MUST be set to value 1 */ 2204 Mobility Options 2205 - Mobile Node Identifier option (mandatory) 2206 - Home Network Prefix option (mandatory) 2207 - Handoff Indicator option (mandatory) 2208 - Access Technology Type option (mandatory) 2209 - Timestamp option (optional) 2210 - Mobile Node Interface Identifier option (optional) 2211 - Link-local Address option (optional) 2213 Figure 11: Proxy Binding Update message format 2215 o The Source Address field in the IPv6 header of the message MUST be 2216 set to the address configured on the interface of the mobile 2217 access gateway. When there is no Alternate Care-of Address option 2218 present in the request, this address will be considered as the 2219 Proxy-CoA address for this binding registration request. However, 2220 when there is Alternate Care-of Address option present in the 2221 request, this address will be not be considered as the Proxy-CoA 2222 address, but the address in the alternate Care-of Address option 2223 will be considered as the Proxy-CoA address. 2225 o The Destination Address field in the IPv6 header of the message 2226 MUST be set to the local mobility anchor address. 2228 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2230 o The Home Network Prefix option MUST be present. 2232 o The Handoff Indicator option MUST be present. 2234 o The Access Technology Type option MUST be present. 2236 o The Timestamp option MAY be present. 2238 o The Mobile Node Interface Identifier option MAY be present. 2240 o The Link-local Address option MAY be present. 2242 o If IPsec is used for protecting the signaling messages, the 2243 message MUST be protected, using the security association existing 2244 between the local mobility anchor and the mobile access gateway. 2246 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2247 3775] MUST NOT be present in the IPv6 Destination Options 2248 extension header of the Proxy Binding Update message. 2250 6.9.2. Router Solicitation Messages 2252 The mobile node may send a Router Solicitation message on the access 2253 link whenever the link-layer detects a media change. The Source 2254 Address in the IPv6 header of the Router Solicitation message may 2255 either be the link-local address of the mobile node or an unspecified 2256 address (::). The Router Solicitation message that the mobile node 2257 sends is as specified in [RFC-4861]. 2259 1. The mobile access gateway on receiving the Router Solicitation 2260 message SHOULD send a Router Advertisement containing the mobile 2261 node's home network prefix as the on-link prefix. However, 2262 before sending the Router Advertisement message containing the 2263 mobile node's home network prefix, it SHOULD complete the binding 2264 registration process with the mobile node's local mobility 2265 anchor. 2267 2. If the local mobility anchor rejects the binding registration 2268 request, or, if the mobile access gateway failed to complete the 2269 binding registration process for whatever reasons, the mobile 2270 access gateway MUST NOT advertise the mobile node's home network 2271 prefix in the Router Advertisement messages that it sends on the 2272 access link. However, it MAY choose to advertise a local visited 2273 network prefix to enable the mobile node for regular IPv6 access. 2275 6.9.3. Default-Router Lifetime 2277 In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6 2278 default-router for the mobile node on the access link, as it is the 2279 entity that sends the Router Advertisements on the access link. 2280 However, as the mobile node moves from one access link to another, 2281 the serving mobile access gateway on those respective links will send 2282 the Router Advertisements and using their own link-local address. 2283 The mobile node on each of the attached links will receive Router 2284 Advertisement messages with a different source address and this makes 2285 the mobile node believe that there is a new default-router on that 2286 access link. 2288 The mobile node will certainly detect the previous default-router 2289 loss by performing the Neighbor Unreachability Detection procedure 2290 per the standard IPv6 ND mechanisms, but it is important that the 2291 mobile access gateway enables the mobile node to withdraw the 2292 previous default-router entry at the earliest. This action will help 2293 in minimizing packet losses during a hand off switch. Following are 2294 some considerations that implementations can apply. 2296 The Router Lifetime field in the Router Advertisement messages that 2297 the mobile access gateway sends on the access link SHOULD be kept to 2298 low. 2300 In access networks where SEND [RFC-3971] is not deployed, the mobile 2301 access gateway can withdraw the previous default-router entry, by 2302 sending a Router Advertisement using the link-local address that of 2303 the previous mobile access gateway and with the Router Lifetime field 2304 set to value zero, then this will force the flush of the previous 2305 default-router entry from the mobile node's cache, as specified in 2306 Section 6.3.5 [RFC-4861]. However, this approach requires the 2307 serving mobile access gateway to learn the link-local address of the 2308 previous mobile access gateway where the mobile node was handed off. 2310 There are other solutions possible for this problem, including the 2311 assignment of a fixed link-local address for all the mobility 2312 entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is 2313 not deployed. In such scenario, the mobile node is not required to 2314 update the default-router entry. However, this is an implementation 2315 choice and has no bearing on the protocol interoperability. 2316 Implementations are free to adopt the best approach that suits their 2317 target deployments. 2319 6.9.4. Retransmissions and Rate Limiting 2321 The mobile access gateway is responsible for retransmissions and rate 2322 limiting the binding registration requests that it sends to the local 2323 mobility anchor. The Retransmission and the Rate Limiting rules are 2324 as specified in [RFC-3775]. However, the following considerations 2325 MUST be applied. 2327 1. When the mobile access gateway sends a Proxy Binding Update 2328 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2329 [RFC-3775], for configuring the retransmission timer, as 2330 specified in Section 11.8 [RFC-3775]. However, the mobile access 2331 gateway is not required to use a longer retransmission interval 2332 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2333 the initial binding registration request. 2335 2. If the mobile access gateway fails to receive a valid matching 2336 response for a registration or re-registration message within the 2337 retransmission interval, it SHOULD retransmit the message until a 2338 response is received. However, the mobile access gateway MUST 2339 ensure the mobile node is still attached to the connected link 2340 before retransmitting the message. 2342 3. As specified in Section 11.8 [RFC-3775], the mobile access 2343 gateway MUST use an exponential back-off process in which the 2344 timeout period is doubled upon each retransmission, until either 2345 the node receives a response or the timeout period reaches the 2346 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2347 MAY continue to send these messages at this slower rate 2348 indefinitely. 2350 4. If Timestamp based scheme is in use, the retransmitted Proxy 2351 Binding Update messages MUST use the latest timestamp. If 2352 Sequence number scheme is in use, the retransmitted Proxy Binding 2353 Update messages MUST use a Sequence Number value greater than 2354 that used for the previous transmission of this Proxy Binding 2355 Update message, just as specified in [RFC-3775]. 2357 6.10. Routing Considerations 2359 This section describes how the mobile access gateway handles the 2360 traffic to/from the mobile node that is attached to one of its access 2361 interface. 2363 Proxy-CoA LMAA 2364 | | 2365 +--+ +---+ +---+ +--+ 2366 |MN|----------|MAG|======================|LMA|----------|CN| 2367 +--+ +---+ +---+ +--+ 2368 IPv6 Tunnel 2370 Figure 12: Proxy Mobile IPv6 Tunnel 2372 6.10.1. Transport Network 2374 The transport network between the local mobility anchor and the 2375 mobile access gateway can be either an IPv6 or IPv4 network. 2376 However, this specification only deals with the IPv6 transport and 2377 the companion document [ID-IPV4-PMIP6] specifies the required 2378 extensions for negotiating IPv4 transport and the corresponding 2379 encapsulation mode for supporting this protocol operation. 2381 6.10.2. Tunneling & Encapsulation Modes 2383 The IPv6 address that a mobile node uses from its home network prefix 2384 is topologically anchored at the local mobility anchor. For a mobile 2385 node to use this address from an access network attached to a mobile 2386 access gateway, proper tunneling techniques have to be in place. 2387 Tunneling hides the network topology and allows the mobile node's 2388 IPv6 datagram to be encapsulated as a payload of another IPv6 packet 2389 and to be routed between the local mobility anchor and the mobile 2390 access gateway. The Mobile IPv6 base specification [RFC-3775] 2391 defines the use of IPv6-over-IPv6 tunneling, between the home agent 2392 and the mobile node and this specification extends the use of the 2393 same tunneling mechanism between the local mobility anchor and the 2394 mobile access gateway. 2396 On most operating systems, tunnels are implemented as a virtual 2397 point-to-point interface. The source and the destination address of 2398 the two end points of this virtual interface along with the 2399 encapsulation mode are specified for this virtual interface. Any 2400 packet that is routed over this interface gets encapsulated with the 2401 outer header and the addresses as specified for that point to point 2402 tunnel interface. For creating a point to point tunnel to any local 2403 mobility anchor, the mobile access gateway may implement a tunnel 2404 interface with the source address field set to its Proxy-CoA address 2405 and the destination address field set to the LMA address. 2407 The following are the supported packet encapsulation modes that can 2408 be used by the mobile access gateway and the local mobility anchor 2409 for routing mobile node's IPv6 datagrams. 2411 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2412 2473]. 2414 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2415 details on how this mode is negotiated is specified in [ID-IPV4- 2416 PMIP6]. 2418 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2419 packet. This mode is specified in [ID-IPV4-PMIP6]. 2421 6.10.3. Local Routing 2423 If there is data traffic between a visiting mobile node and a 2424 correspondent node that is locally attached to an access link 2425 connected to the mobile access gateway, the mobile access gateway MAY 2426 optimize on the delivery efforts by locally routing the packets and 2427 by not reverse tunneling them to the mobile node's local mobility 2428 anchor. The configuration variable, EnableMAGLocalRouting MAY be 2429 used for controlling this aspect. However, in some systems, this may 2430 have an implication on the mobile node's accounting and policy 2431 enforcement as the local mobility anchor is not in the path for that 2432 traffic and it will not be able to apply any traffic policies or do 2433 any accounting for those flows. 2435 This decision of path optimization SHOULD be based on the policy 2436 configured on the mobile access gateway, but enforced by the mobile 2437 node's local mobility anchor. The specific details on how this is 2438 achieved are beyond of the scope of this document. 2440 6.10.4. Tunnel Management 2442 All the considerations mentioned in Section 5.6.1 for the tunnel 2443 management on the local mobility anchor apply for the mobile access 2444 gateway as well. 2446 6.10.5. Forwarding Rules 2448 Forwarding Packets sent to the Mobile Node's Home Network: 2450 o On receiving a packet from the bi-directional tunnel established 2451 with the mobile node's local mobility anchor, the mobile access 2452 gateway MUST use the destination address of the inner packet for 2453 forwarding it on the interface where the destination network 2454 prefix is hosted. The mobile access gateway MUST remove the outer 2455 header before forwarding the packet. If the mobile access gateway 2456 cannot find the connected interface for that destination address, 2457 it MUST silently drop the packet. For reporting an error in such 2458 a scenario, in the form of ICMP control message, the 2459 considerations from Generic Packet Tunneling specification [RFC- 2460 2473] must be applied. 2462 o On receiving a packet from a correspondent node that is locally 2463 connected and which is destined to a mobile node that is on 2464 another locally connected access link, the mobile access gateway 2465 MUST check the configuration variable, EnableMAGLocalRouting, to 2466 ensure the mobile access gateway is allowed to route the packet 2467 directly to the mobile node. If the mobile access gateway is not 2468 allowed to route the packet directly, it MUST route the packet 2469 through the bi-directional tunnel established between itself and 2470 the mobile node's local mobility anchor. Otherwise, it can route 2471 the packet directly to the mobile node. 2473 Forwarding Packets Sent by the Mobile Node: 2475 o On receiving a packet from a mobile node connected to its access 2476 link, the mobile access gateway MUST ensure that there is an 2477 established binding for that mobile node with its local mobility 2478 anchor before forwarding the packet directly to the destination or 2479 before tunneling the packet to the mobile node's local mobility 2480 anchor. 2482 o On receiving a packet from a mobile node connected to its access 2483 link to a destination that is locally connected, the mobile access 2484 gateway MUST check the configuration variable, 2485 EnableMAGLocalRouting, to ensure the mobile access gateway is 2486 allowed to route the packet directly to the destination. If the 2487 mobile access gateway is not allowed to route the packet directly, 2488 it MUST route the packet through the bi-directional tunnel 2489 established between itself and the mobile node's local mobility 2490 anchor. Otherwise, it can route the packet directly to the 2491 destination. 2493 o On receiving a packet from the mobile node connected to its access 2494 link, to a destination that is not directly connected, the packet 2495 MUST be forwarded to the local mobility anchor through the bi- 2496 directional tunnel established between itself and the mobile 2497 node's local mobility anchor. However, the packets that are sent 2498 with the link-local source address MUST NOT be forwarded. The 2499 format of the tunneled packet is shown below. Additionally, when 2500 using IPv4 transport, the format of the tunneled packet is as 2501 described in [ID-IPV4-PMIP6]. 2503 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2504 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2505 Upper layer protocols /* Packet Content*/ 2507 Figure 13: Tunneled Packets from MAG to LMA 2509 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2511 This section explains how Stateful Address Configuration using DHCPv6 2512 can be enabled on the access link attached to a mobile access gateway 2513 and how a mobile node attached to that link can obtain an address 2514 from its home network prefix using DHCPv6. 2516 o For supporting Stateful Address Configuration using DHCPv6, the 2517 DHCPv6 relay agent [RFC-3315] service MUST be configured on each 2518 of the mobile access gateways in the Proxy Mobile IPv6 domain. 2519 Further, as specified in Section 20 [RFC-3315], the DHCPv6 relay 2520 agent should be configured to use a list of destination addresses, 2521 which MAY include unicast addresses, the All_DHCP_Servers 2522 multicast address, or other addresses selected by the network 2523 administrator. 2525 o The DHCPv6 server in the Proxy Mobile IPv6 domain can be 2526 configured with a list of prefix pools (P1, P2, ..., Pn). Each 2527 one of these prefix pools corresponds to a home network prefix 2528 that a local mobility anchor allocates to a mobile node in that 2529 domain. However, the DHCPv6 server will not know the relation 2530 between a given address pool and a mobile node to which the 2531 corresponding prefix is allocated. It just views these pools as 2532 prefixes hosted on different links in that domain. 2534 o When a mobile node sends a DHCPv6 request message, the DHCPv6 2535 relay agent function on the access link will set the link-address 2536 field in the DHCPv6 message to an address in the mobile node's 2537 home network prefix. The address is generated as per [RFC-4862] 2538 by combining the mobile node's home network prefix (assigned by 2539 the local mobility anchor for this mobility session) and its own 2540 interface identifier on the access link shared with the mobile 2541 node, so as to provide a prefix hint to the DHCPv6 Server for the 2542 address pool selection. The DHCPv6 server on receiving the 2543 request from the mobile node, will allocate an address from the 2544 prefix pool pointed to by the link-address field of the request. 2546 o Once the mobile node obtains an address and moves to a different 2547 link and sends a DHCPv6 request, the DHCPv6 relay agent on the new 2548 link will set the prefix hint in the DHCPv6 message to the mobile 2549 node's home network prefix (assigned by the local mobility anchor 2550 for this mobility session). The DHCPv6 server will identify the 2551 client from the Client-DUID option and present in the request and 2552 will allocate the same address as before. 2554 o The DHCPv6 based address configuration is not recommended for 2555 deployments where the local mobility anchor and the mobile access 2556 gateways are located in different administrative domains. For 2557 this configuration to work, all the mobile access gateways in the 2558 Proxy Mobile IPv6 domain should be able to ensure that the DHCPv6 2559 request messages from a given mobile node anchored on any of the 2560 access links in that domain, will always be handled by the same 2561 DHCPv6 server. 2563 o The DHCPv6 server should be configured to offer low address lease 2564 times. A lease time that is too large prevents the DHCPv6 server 2565 from reclaiming the address even after the local mobility anchor 2566 deletes the mobile node's binding cache entry. 2568 6.12. Home Network Prefix Renumbering 2570 If the mobile node's home network prefix gets renumbered or becomes 2571 invalid during the middle of a mobility session, the mobile access 2572 gateway MUST withdraw the prefix by sending a Router Advertisement on 2573 the access link with zero prefix lifetime for the mobile node's home 2574 network prefix. Also, the local mobility anchor and the mobile 2575 access gateway MUST delete the routing state for that prefix. 2576 However, the specific details on how the local mobility anchor 2577 notifies the mobile access gateway about the mobile node's home 2578 network prefix renumbering are outside the scope of this document. 2580 6.13. Mobile Node Detachment Detection and Resource Cleanup 2582 Before sending a Proxy Binding Update message to the local mobility 2583 anchor for extending the lifetime of a currently existing binding of 2584 a mobile node, the mobile access gateway MUST make sure the mobile 2585 node is still attached to the connected link by using some reliable 2586 method. If the mobile access gateway cannot predictably detect the 2587 presence of the mobile node on the connected link, it MUST NOT 2588 attempt to extend the registration lifetime of the mobile node. 2589 Further, in such scenario, the mobile access gateway SHOULD terminate 2590 the binding of the mobile node by sending a Proxy Binding Update 2591 message to the mobile node's local mobility anchor with lifetime 2592 value set to 0. It MUST also remove any local state such as the 2593 Binding Update List entry created for that mobile node. 2595 The specific detection mechanism of the loss of a visiting mobile 2596 node on the connected link is specific to the access link between the 2597 mobile node and the mobile access gateway and is outside the scope of 2598 this document. Typically, there are various link-layer specific 2599 events specific to each access technology that the mobile access 2600 gateway can depend on for detecting the node loss. In general, the 2601 mobile access gateway can depend on one or more of the following 2602 methods for the detection presence of the mobile node on the 2603 connected link: 2605 o Link-layer event specific to the access technology 2607 o PPP Session termination event on point-to-point link types 2609 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2611 o Notification event from the local mobility anchor 2613 6.14. Allowing network access to other IPv6 nodes 2615 In some Proxy Mobile IPv6 deployments, network operators may want to 2616 provision the mobile access gateway to offer network-based mobility 2617 management service only to some visiting mobile nodes and enable just 2618 regular IP access to some other nodes. This requires the network to 2619 have control on when to enable network-based mobility management 2620 service to a mobile node and when to enable regular IPv6 access. 2621 This specification does not disallow such configuration. 2623 Upon detecting a mobile node on its access link and after policy 2624 considerations, the mobile access gateway MUST determine if network- 2625 based mobility management service should be offered to that mobile 2626 node. If the mobile node is entitled for network-based mobility 2627 management service, then the mobile access gateway must ensure the 2628 mobile node believes it is on its home link, as explained in various 2629 sections of this specification. 2631 If the mobile node is not entitled for the network-based mobility 2632 management service, as determined from the policy considerations, the 2633 mobile access gateway MAY choose to offer regular IPv6 access to the 2634 mobile node and in such scenario the normal IPv6 considerations 2635 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2636 obtain an IPv6 address using normal IPv6 address configuration 2637 procedures. The obtained address must be from a local visitor 2638 network prefix. This essentially ensures that the mobile access 2639 gateway functions as a normal access router to a mobile node attached 2640 to its access link and with out impacting its host-based mobility 2641 protocol operation. 2643 7. Mobile Node Operation 2645 This non-normative section explains the mobile node's operation in a 2646 Proxy Mobile IPv6 domain. 2648 7.1. Moving into a Proxy Mobile IPv6 Domain 2650 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2651 an access network, the mobile access gateway on the access link 2652 detects the attachment of the mobile node and completes the binding 2653 registration with the mobile node's local mobility anchor. If the 2654 binding update operation is successfully performed, the mobile access 2655 gateway will create the required state and setup the data path for 2656 the mobile node's data traffic. 2658 If the mobile node is IPv6 enabled, on attaching to the access link, 2659 it will typically send Router Solicitation message [RFC-4861]. The 2660 mobile access gateway on the access link will respond to the Router 2661 Solicitation message with a Router Advertisement. The Router 2662 Advertisement will have the mobile node's home network prefix, 2663 default-router address and other address configuration parameters. 2665 If the mobile access gateway on the access link, receives a Router 2666 Solicitation message from the mobile node, before it completed the 2667 signaling with the mobile node's local mobility anchor, the mobile 2668 access gateway may not know the mobile node's home network prefix and 2669 may not be able to emulate the mobile node's home link on the access 2670 link. In such scenario, the mobile node may notice a slight delay 2671 before it receives a Router Advertisement message. 2673 If the received Router Advertisement has the Managed Address 2674 Configuration flag set, the mobile node, as it would normally do, 2675 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2676 enabled on that access link will ensure the mobile node will obtain 2677 its IPv6 address as a lease from its home network prefix. 2679 If the received Router Advertisement does not have the Managed 2680 Address Configuration flag set and if the mobile node is allowed to 2681 use an autoconfigured address, the mobile node will be able to obtain 2682 an IPv6 address using an interface identifier generated as per the 2683 Autoconf specification [RFC-4862] or as per the Privacy Extensions 2684 specification [RFC-4941]. 2686 If the mobile node is IPv4 enabled and if the network permits, it 2687 will be able to obtain the IPv4 address configuration as specified in 2688 the companion document [ID-IPV4-PMIP6]. 2690 Once the address configuration is complete, the mobile node can 2691 continue to use this address configuration as long as it is attached 2692 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2694 7.2. Roaming in the Proxy Mobile IPv6 Domain 2696 After obtaining the address configuration in the Proxy Mobile IPv6 2697 domain, as the mobile node moves and changes its point of attachment 2698 from one mobile access gateway to the other, it can still continue to 2699 use the same address configuration. As long as the attached access 2700 network is in the scope of that Proxy Mobile IPv6 domain, the mobile 2701 node will always detect the same link, where it obtained its initial 2702 address configuration. If the mobile node performs DHCP operation, 2703 it will always obtain the same address as before. 2705 However, the mobile node will always detect a new default-router on 2706 each connected link, but still advertising the mobile node's home 2707 network prefix as the on-link prefix and with the other configuration 2708 parameters consistent with its home link properties. 2710 8. Message Formats 2712 This section defines extensions to the Mobile IPv6 [RFC-3775] 2713 protocol messages. 2715 8.1. Proxy Binding Update Message 2717 0 1 2 3 2718 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 2719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2720 | Sequence # | 2721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2722 |A|H|L|K|M|R|P| Reserved | Lifetime | 2723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2724 | | 2725 . . 2726 . Mobility options . 2727 . . 2729 | | 2730 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2732 A Binding Update message that is sent by a mobile access gateway to a 2733 local mobility anchor is referred to as the "Proxy Binding Update" 2734 message. A new flag (P) is included in the Binding Update message. 2735 The rest of the Binding Update message format remains the same as 2736 defined in [RFC-3775] and with the additional (R) and (M) flags as 2737 specified in [RFC-3963] and [RFC-4140] respectively. 2739 Proxy Registration Flag (P) 2741 A new flag (P) is included in the Binding Update message to 2742 indicate to the local mobility anchor that the Binding Update 2743 message is a proxy registration. The flag MUST be set to the 2744 value of 1 for proxy registrations and MUST be set to 0 for direct 2745 registrations sent by a mobile node. 2747 Mobility Options 2749 Variable-length field of such length that the complete Mobility 2750 Header is an integer multiple of 8 octets long. This field 2751 contains zero or more TLV-encoded mobility options. The encoding 2752 and format of defined options are described in Section 6.2 [RFC- 2753 3775]. The local mobility anchor MUST ignore and skip any options 2754 which it does not understand. 2756 As per this specification, the following mobility options are 2757 valid in a Proxy Binding Update message: 2759 Mobile Node Identifier option 2761 Home Network Prefix option 2763 Handoff Indicator option 2765 Access Technology Type option 2767 Timestamp option 2769 Mobile Node Interface Identifier option 2771 Link-local Address option 2773 For descriptions of other fields present in this message, refer to 2774 section 6.1.7 [RFC-3775]. 2776 8.2. Proxy Binding Acknowledgement Message 2778 0 1 2 3 2779 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 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2781 | Status |K|R|P|Reserved | 2782 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2783 | Sequence # | Lifetime | 2784 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 | | 2786 . . 2787 . Mobility options . 2788 . . 2789 | | 2790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2792 A Binding Acknowledgement message that is sent by a local mobility 2793 anchor to a mobile access gateway is referred to as the "Proxy 2794 Binding Acknowledgement" message. A new flag (P) is included in the 2795 Binding Acknowledgement message. The rest of the Binding 2796 Acknowledgement message format remains the same as defined in [RFC- 2797 3775] and with the additional (R) flag as specified in [RFC-3963]. 2799 Proxy Registration Flag (P) 2801 A new flag (P) is included in the Binding Acknowledgement message 2802 to indicate that the local mobility anchor that processed the 2803 corresponding Proxy Binding Update message supports proxy 2804 registrations. The flag is set to value of 1 only if the 2805 corresponding Proxy Binding Update had the Proxy Registration Flag 2806 (P) set to value of 1. 2808 Mobility Options 2810 Variable-length field of such length that the complete Mobility 2811 Header is an integer multiple of 8 octets long. This field 2812 contains zero or more TLV-encoded mobility options. The encoding 2813 and format of defined options are described in Section 6.2 [RFC- 2814 3775]. The mobile access gateway MUST ignore and skip any options 2815 which it does not understand. 2817 As per this specification, the following mobility options are 2818 valid in a Proxy Binding Acknowledgement message: 2820 Mobile Node Identifier option 2822 Home Network Prefix option 2824 Handoff Indicator option 2826 Access Technology Type option 2828 Timestamp option 2830 Mobile Node Interface Identifier option 2832 Link-local Address option 2834 Status 2836 8-bit unsigned integer indicating the disposition of the Proxy 2837 Binding Update. Values of the Status field less than 128 indicate 2838 that the Proxy Binding Update was accepted by the local mobility 2839 anchor. Values greater than or equal to 128 indicate that the 2840 binding registration was rejected by the local mobility anchor. 2841 Section 8.9 defines the Status values that can used in Proxy 2842 Binding Acknowledgement message. 2844 For descriptions of other fields present in this message, refer to 2845 the section 6.1.8 [RFC-3775]. 2847 8.3. Home Network Prefix Option 2849 A new option, Home Network Prefix Option is defined for using it in 2850 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2851 exchanged between a local mobility anchor and a mobile access 2852 gateway. This option is used for exchanging the mobile node's home 2853 network prefix information. 2855 The Home Network Prefix Option has an alignment requirement of 8n+4. 2856 Its format is as follows: 2858 0 1 2 3 2859 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 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 | Type | Length | Reserved | Prefix Length | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 | | 2864 + + 2865 | | 2866 + Home Network Prefix + 2867 | | 2868 + + 2869 | | 2870 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2872 Type 2873 2875 Length 2877 8-bit unsigned integer indicating the length of the option 2878 in octets, excluding the type and length fields. This field 2879 MUST be set to 18. 2881 Reserved (R) 2883 This 8-bit field is unused for now. The value MUST be 2884 initialized to 0 by the sender and MUST be ignored by the 2885 receiver. 2887 Prefix Length 2889 8-bit unsigned integer indicating the prefix length of the 2890 IPv6 prefix contained in the option. 2892 Home Network Prefix 2894 A sixteen-byte field containing the mobile node's IPv6 Home 2895 Network Prefix. 2897 8.4. Handoff Indicator Option 2899 A new option, Handoff Indicator Option is defined for using it in the 2900 Proxy Binding Update and Proxy Binding Acknowledgement messages 2901 exchanged between a local mobility anchor and a mobile access 2902 gateway. This option is used for exchanging the mobile node's 2903 handoff related hints. 2905 The Handoff Indicator Option has no alignment requirement. Its 2906 format is as follows: 2908 0 1 2 3 2909 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 2910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2911 | Type | Length | Reserved (R) | HI | 2912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2914 Type 2915 2917 Length 2919 8-bit unsigned integer indicating the length of the option 2920 in octets, excluding the type and length fields. This field 2921 MUST be set to 2. 2923 Reserved (R) 2925 This 8-bit field is unused for now. The value MUST be 2926 initialized to 0 by the sender and MUST be ignored by the 2927 receiver. 2929 Handoff Indicator (HI) 2931 A 8-bit field that specifies the type of handoff. The values 2932 (0 - 255) will be allocated and managed by IANA. The following 2933 values are currently reserved. 2935 0: Reserved 2936 1: Attachment over a new interface 2937 2: Handoff between two different interfaces of the mobile node 2938 3: Handoff between mobile access gateways for the same interface 2939 4: Handoff state unknown 2940 5: Handoff state not changed (Re-registration) 2942 8.5. Access Technology Type Option 2944 A new option, Access Technology Type Option is defined for using it 2945 in the Proxy Binding Update and Proxy Binding Acknowledgement 2946 messages exchanged between a local mobility anchor and a mobile 2947 access gateway. This option is used for exchanging the type of the 2948 access technology using which the mobile node is currently attached 2949 to the mobile access gateway. 2951 The Access Technology Type Option has no alignment requirement. Its 2952 format is as follows: 2954 0 1 2 3 2955 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 2956 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2957 | Type | Length | Reserved (R) | ATT | 2958 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2960 Type 2961 2963 Length 2965 8-bit unsigned integer indicating the length of the option 2966 in octets, excluding the type and length fields. This field 2967 MUST be set to 2. 2969 Reserved (R) 2971 This 8-bit field is unused for now. The value MUST be 2972 initialized to 0 by the sender and MUST be ignored by the 2973 receiver. 2975 Access Technology Type (ATT) 2977 A 8-bit field that specifies the access technology through 2978 which the mobile node is connected to the access link on the 2979 mobile access gateway. 2981 The values (0 - 255) will be allocated and managed by IANA. The 2982 following values are currently reserved for the below specified 2983 access technology types. 2985 0: Reserved 2986 1: Virtual 2987 2: PPP 2988 3: 802.3 (Ethernet) 2989 4: 802.11a/b/g 2990 5: 802.16e 2992 8.6. Mobile Node Interface Identifier Option 2994 A new option, Mobile Node Interface Identifier Option is defined for 2995 using it in the Proxy Binding Update and Proxy Binding 2996 Acknowledgement messages exchanged between a local mobility anchor 2997 and a mobile access gateway. This option is used for exchanging the 2998 mobile node's interface identifier. 3000 The format of the Interface Identifier option when the interface 3001 identifier is 8 bytes is shown below. When the size is different, 3002 the option MUST be aligned appropriately, as per mobility option 3003 alignment requirements specified in [RFC-3775]. 3005 0 1 2 3 3006 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 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | Type | Length | Reserved | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | | 3011 + Interface Identifier + 3012 . ... . 3013 | | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3016 Type 3017 3019 Length 3020 8-bit unsigned integer indicating the length of the option 3021 in octets, excluding the type and length fields. 3023 Reserved 3025 This field is unused for now. The value MUST be initialized to 3026 0 by the sender and MUST be ignored by the receiver. 3028 Interface Identifier 3030 A variable length field containing the mobile node's interface 3031 identifier. 3033 The content and format of this field (including byte and bit 3034 ordering) is as specified in Section 4.6 [RFC-4861] for 3035 carrying Link-Layer Address. 3037 8.7. Link-local Address Option 3039 A new option, Link-local Address Option is defined for using it in 3040 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3041 exchanged between a local mobility anchor and a mobile access 3042 gateway. This option is used for exchanging the mobile node's link- 3043 local address. 3045 The Link-local Address option has an alignment requirement of 8n+6. 3046 Its format is as follows: 3048 0 1 2 3 3049 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 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | Type | Length | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | | 3054 + + 3055 | | 3056 + Link-local Address + 3057 | | 3058 + + 3059 | | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 Type 3063 3065 Length 3067 8-bit unsigned integer indicating the length of the option 3068 in octets, excluding the type and length fields. This field 3069 MUST be set to 16. 3071 Link-local Address 3073 A sixteen-byte field containing the mobile node's link-local 3074 address. 3076 8.8. Timestamp Option 3078 A new option, Timestamp Option is defined for use in the Proxy 3079 Binding Update and Proxy Binding Acknowledgement messages. 3081 The Timestamp option has an alignment requirement of 8n+2. Its 3082 format is as follows: 3084 0 1 2 3 3085 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 3086 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 | Type | Length | 3088 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 | | 3090 + Timestamp + 3091 | | 3092 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3094 Type 3095 3097 Length 3099 8-bit unsigned integer indicating the length in octets of 3100 the option, excluding the type and length fields. The value 3101 for this field MUST be set to 8. 3103 Timestamp 3105 A 64-bit unsigned integer field containing a timestamp. The value 3106 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3107 by using a fixed point format. In this format, the integer number 3108 of seconds is contained in the first 48 bits of the field, and the 3109 remaining 16 bits indicate the number of 1/65536 fractions of a 3110 second. 3112 8.9. Status Values 3114 This document defines the following new Status values for use in 3115 Proxy Binding Acknowledgement message. These values are to be 3116 allocated from the same number space, as defined in Section 6.1.8 3117 [RFC-3775]. 3119 Status values less than 128 indicate that the Proxy Binding Update 3120 request was accepted by the local mobility anchor. Status values 3121 greater than 128 indicate that the Proxy Binding Update was rejected 3122 by the local mobility anchor. 3124 PROXY_REG_NOT_ENABLED: 3126 Proxy registration not enabled for the mobile node 3128 NOT_LMA_FOR_THIS_MOBILE_NODE: 3130 Not local mobility anchor for this mobile node 3132 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 3134 The mobile access gateway is not authorized to send proxy binding 3135 registrations 3137 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 3139 The mobile node is not authorized for the requesting home network 3140 prefix 3142 TIMESTAMP_MISMATCH: 3144 Invalid timestamp value (the clocks are out of sync) 3146 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 3148 The timestamp value is lower than the previously accepted value 3150 MISSING_HOME_NETWORK_PREFIX_OPTION 3152 Missing home network prefix option 3154 MISSING_MN_IDENTIFIER_OPTION: 3156 Missing mobile node identifier option 3158 MISSING_HANDOFF_INDICATOR_OPTION 3160 Missing handoff indicator option 3162 MISSING_ACCESS_TECH_TYPE_OPTION 3163 Missing access technology type option 3165 Additionally, the following Status values defined in [RFC-3775] can 3166 also be used in Proxy Binding Acknowledgement message. 3168 0 Proxy Binding Update accepted 3170 128 Reason unspecified 3172 129 Administratively prohibited 3174 130 Insufficient resources 3176 9. Protocol Configuration Variables 3178 The local mobility anchor MUST allow the following variables to be 3179 configured by the system management. 3181 MinDelayBeforeBCEDelete 3183 This variable specifies the amount of time in milliseconds the 3184 local mobility anchor MUST wait before it deletes a Binding Cache 3185 entry of a mobile node, upon receiving a Proxy Binding Update 3186 message from a mobile access gateway with a lifetime value of 0. 3187 During this wait time, if the local mobility anchor receives a 3188 Proxy Binding Update for the same mobility binding, with lifetime 3189 value greater than 0, then it must update the binding cache entry 3190 with the accepted binding values. By the end of this wait-time, 3191 if the local mobility anchor did not receive any valid Proxy 3192 Binding Update message for that mobility binding, it MUST delete 3193 the Binding Cache entry. This delay essentially ensures a mobile 3194 node's Binding Cache entry is not deleted too quickly and allows 3195 some time for the new mobile access gateway to complete the 3196 signaling for the mobile node. 3198 The default value for this variable is 10000 milliseconds. 3200 MaxDelayBeforeNewBCEAssign 3202 This variable specifies the amount of time in milliseconds the 3203 local mobility anchor MUST wait for the de-registration message 3204 for an existing mobility session before it decides to create a new 3205 mobility session. 3207 The default value for this variable is 500 milliseconds. 3209 TimestampValidityWindow 3211 This variable specifies the maximum amount of time difference in 3212 milliseconds between the timestamp in the received Proxy Binding 3213 Update message and the current time-of-day on the local mobility 3214 anchor, that is allowed by the local mobility anchor for the 3215 received message to be considered valid. 3217 The default value for this variable is 300 milliseconds. This 3218 variable MUST be adjusted to suit the deployments. 3220 The mobile access gateway MUST allow the following variables to be 3221 configured by the system management. 3223 EnableMAGLocalrouting 3225 This flag indicates whether or not the mobile access gateway is 3226 allowed to enable local routing of the traffic exchanged between a 3227 visiting mobile node and a correspondent node that is locally 3228 connected to one of the interfaces of the mobile access gateway. 3229 The correspondent node can be another visiting mobile node as 3230 well, or a local fixed node. 3232 The default value for this flag is set to value of 0, indicating 3233 that the mobile access gateway MUST reverse tunnel all the traffic 3234 to the mobile node's local mobility anchor. 3236 When the value of this flag is set to value of 1, the mobile 3237 access gateway MUST route the traffic locally. 3239 This aspect of local routing MAY be defined as policy on a per 3240 mobile basis and when present will take precedence over this flag. 3242 10. IANA Considerations 3244 This document defines six new Mobility Header options, the Home 3245 Network Prefix option, Handoff Indicator option, Access Technology 3246 Type option, Interface Identifier option, Link-local Address option 3247 and Timestamp option. These options are described in Section 8. The 3248 Type value for these options needs to be assigned from the same 3249 numbering space as allocated for the other mobility options, as 3250 defined in [RFC-3775]. 3252 The Handoff Indicator option defined in Section 8.4 of this document 3253 introduces a new Handoff Indicator (HI) numbering space, where the 3254 values from 0 to 5 have been reserved by this document. Approval of 3255 new Handoff Indicator type values are to be made through IANA Expert 3256 Review. 3258 The Access Technology Type option defined in Section 8.5 of this 3259 document introduces a new Access Technology type (ATT) numbering 3260 space, where the values from 0 to 5 have been reserved by this 3261 document. Approval of new Access Technology type values are to be 3262 made through IANA Expert Review. 3264 This document also defines new Binding Acknowledgement status values 3265 as described in Section 8.9. The status values MUST be assigned from 3266 the same number space used for Binding Acknowledgement status values, 3267 as defined in [RFC-3775]. The allocated values for each of these 3268 status values MUST be greater than 128. 3270 11. Security Considerations 3272 The potential security threats against any network-based mobility 3273 management protocol are described in [RFC-4832]. This section 3274 explains how Proxy Mobile IPv6 protocol defends itself against those 3275 threats. 3277 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3278 Binding Update and Proxy Binding Acknowledgement, exchanged between 3279 the mobile access gateway and the local mobility anchor to be 3280 protected using IPsec, using the established security association 3281 between them. This essentially eliminates the threats related to the 3282 impersonation of the mobile access gateway or the local mobility 3283 anchor. 3285 This specification allows a mobile access gateway to send binding 3286 registration messages on behalf of a mobile node. If proper 3287 authorization checks are not in place, a malicious node may be able 3288 to hijack a mobile node's session or may carry out a denial-of- 3289 service attack. To prevent this attack, this specification requires 3290 the local mobility anchor to allow only authorized mobile access 3291 gateways that are part of that Proxy Mobile IPv6 domain to send 3292 binding registration messages on behalf of a mobile node. 3294 To eliminate the threats on the interface between the mobile access 3295 gateway and the mobile node, this specification requires an 3296 established trust between the mobile access gateway and the mobile 3297 node and to authenticate and authorize the mobile node before it is 3298 allowed to access the network. Further, the established 3299 authentication mechanisms enabled on that access link will ensure 3300 that there is a secure binding between the mobile node's identity and 3301 its link-layer address. The mobile access gateway will definitively 3302 identify the mobile node from the packets that it receives on that 3303 access link. 3305 To address the threat related to a compromised mobile access gateway, 3306 the local mobility anchor, before accepting a Proxy Binding Update 3307 message for a given mobile node, may ensure that the mobile node is 3308 definitively attached to the mobile access gateway that sent the 3309 proxy binding registration request. This may be accomplished by 3310 contacting a trusted entity which is able to track the mobile node's 3311 current point of attachment. However, the specific details of the 3312 actual mechanisms for achieving this is outside the scope of this 3313 document. 3315 12. Acknowledgements 3317 The authors would like to specially thank Julien Laganier, Christian 3318 Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi, Jari 3319 Arkko and Elwyn Davies for their thorough review of this document. 3321 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3322 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3323 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3324 Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- 3325 Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3326 Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil 3327 Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri 3328 Blumenthal, Ved Kafle, Vidya Narayanan, Youn-Hee Han and many others 3329 for their passionate discussions in the working group mailing list on 3330 the topic of localized mobility management solutions. These 3331 discussions stimulated much of the thinking and shaped the draft to 3332 the current form. We acknowledge that ! 3334 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3335 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 3336 Tim Stammers for their input on this document. 3338 13. References 3340 13.1. Normative References 3342 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3343 Requirement Levels", BCP 14, RFC 2119, March 1997. 3345 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3346 IPv6 Specification", RFC 2473, December 1998. 3348 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3349 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3350 RFC 3315, July 2003. 3352 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3353 IPv6", RFC 3775, June 2004. 3355 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3356 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3357 January 2005. 3359 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3360 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3361 November 2005. 3363 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3364 Internet Protocol", RFC 4301, December 2005. 3366 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3367 4303, December 2005. 3369 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3370 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3371 2007. 3373 13.2. Informative References 3375 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 3376 51, RFC 1661, July 1994. 3378 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3379 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3380 2005. 3382 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3383 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3384 4140, August 2005. 3386 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3387 Protocol", RFC 4306, December 2005. 3389 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3390 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3392 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3393 "Chargeable User Identity", RFC 4372, January 2006. 3395 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3396 G., Liebsch, M., "Problem Statement for Network-based Localized 3397 Mobility Management", September 2006. 3399 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3400 G., Liebsch, M., "Goals for Network-based Localized Mobility 3401 Management", October 2006. 3403 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3404 Localized Mobility Management", September 2006. 3406 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3407 Address Autoconfiguration", RFC 4862, September 2007. 3409 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3410 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3411 2007. 3413 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3414 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3415 November 2007. 3417 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 3418 Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. 3420 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3422 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3423 typically be identified by an identifier, MN-Identifier, and that 3424 identifier will have an associated policy profile that identifies the 3425 mobile node's home network prefix, permitted address configuration 3426 modes, roaming policy and other parameters that are essential for 3427 providing network-based mobility service. This information is 3428 typically configured in AAA. It is possible the home network prefix 3429 is dynamically allocated for the mobile node when it boots up for the 3430 first time in the network, or it could be a statically configured 3431 value on per mobile node basis. However, for all practical purposes, 3432 the network entities in the proxy Mobile IPv6 domain, while serving a 3433 mobile node will have access to this profile and these entities can 3434 query this information using RADIUS/DIAMETER protocols. 3436 Appendix B. Supporting Shared-Prefix Model using DHCPv6 3438 This specification supports Per-MN-Prefix model. However, it is 3439 possible to support Shared-Prefix model under the following 3440 guidelines. 3442 The mobile node is allowed to use stateful address configuration 3443 using DHCPv6 for obtaining its address configuration. The mobile 3444 node is not allowed to use any of the stateless autoconfiguration 3445 techniques. The permitted address configuration models for the 3446 mobile node on the access link can be enforced by the mobile access 3447 gateway, by setting the relevant flags in the Router Advertisements, 3448 as per [RFC-4861]. 3450 The Home Network Prefix option that is sent by the mobile access 3451 gateway in the Proxy Binding Update message, must contain the 128-bit 3452 host address that the mobile node obtained via DHCPv6. 3454 Routing state at the mobile access gateway: 3456 For all IPv6 traffic from the source MN-HoA::/128 to 3457 _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is 3458 the MAG to LMA tunnel. 3460 Routing state at the local mobility anchor: 3462 For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, 3463 next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. 3465 Appendix C. Routing State 3467 The following section explains the routing state for a mobile node on 3468 the mobile access gateway. This routing state reflects only one 3469 specific way of implementation and one MAY choose to implement it in 3470 other ways. The policy based route defined below acts as a traffic 3471 selection rule for routing a mobile node's traffic through a specific 3472 tunnel created between the mobile access gateway and that mobile 3473 node's local mobility anchor and with the specific encapsulation 3474 mode, as negotiated. 3476 The below example identifies the routing state for two visiting 3477 mobile nodes, MN1 and MN2 with their respective local mobility 3478 anchors LMA1 and LMA2. 3480 For all traffic from the mobile node, identified by the mobile node's 3481 MAC address, ingress interface or source prefix (MN-HNP) to 3482 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3484 +==================================================================+ 3485 | Packet Source | Destination Address | Destination Interface | 3486 +==================================================================+ 3487 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3488 | (IPv6 Prefix or |----------------------------------------------| 3489 | Input Interface) | Locally Connected | Tunnel0 | 3490 +------------------------------------------------------------------+ 3491 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3492 + (IPv6 Prefix or -----------------------------------------------| 3493 | Input Interface | Locally Connected | direct | 3494 +------------------------------------------------------------------+ 3496 Figure 22: Example - Policy based Route Table 3498 +==================================================================+ 3499 | Interface | Source Address | Destination Address | Encapsulation | 3500 +==================================================================+ 3501 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3502 +------------------------------------------------------------------+ 3503 | Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 | 3504 +------------------------------------------------------------------+ 3506 Figure 23: Example - Tunnel Interface Table 3508 Authors' Addresses 3510 Sri Gundavelli 3511 Cisco 3512 170 West Tasman Drive 3513 San Jose, CA 95134 3514 USA 3516 Email: sgundave@cisco.com 3517 Kent Leung 3518 Cisco 3519 170 West Tasman Drive 3520 San Jose, CA 95134 3521 USA 3523 Email: kleung@cisco.com 3525 Vijay Devarapalli 3526 Azaire Networks 3527 4800 Great America Pkwy 3528 Santa Clara, CA 95054 3529 USA 3531 Email: vijay.devarapalli@azairenet.com 3533 Kuntal Chowdhury 3534 Starent Networks 3535 30 International Place 3536 Tewksbury, MA 3538 Email: kchowdhury@starentnetworks.com 3540 Basavaraj Patil 3541 Nokia Siemens Networks 3542 6000 Connection Drive 3543 Irving, TX 75039 3544 USA 3546 Email: basavaraj.patil@nsn.com 3548 Full Copyright Statement 3550 Copyright (C) The IETF Trust (2008). 3552 This document is subject to the rights, licenses and restrictions 3553 contained in BCP 78, and except as set forth therein, the authors 3554 retain all their rights. 3556 This document and the information contained herein are provided on an 3557 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3558 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3559 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3560 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3561 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3562 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3564 Intellectual Property 3566 The IETF takes no position regarding the validity or scope of any 3567 Intellectual Property Rights or other rights that might be claimed to 3568 pertain to the implementation or use of the technology described in 3569 this document or the extent to which any license under such rights 3570 might or might not be available; nor does it represent that it has 3571 made any independent effort to identify any such rights. Information 3572 on the procedures with respect to rights in RFC documents can be 3573 found in BCP 78 and BCP 79. 3575 Copies of IPR disclosures made to the IETF Secretariat and any 3576 assurances of licenses to be made available, or the result of an 3577 attempt made to obtain a general license or permission for the use of 3578 such proprietary rights by implementers or users of this 3579 specification can be obtained from the IETF on-line IPR repository at 3580 http://www.ietf.org/ipr. 3582 The IETF invites any interested party to bring to its attention any 3583 copyrights, patents or patent applications, or other proprietary 3584 rights that may cover technology that may be required to implement 3585 this standard. Please address the information to the IETF at 3586 ietf-ipr@ietf.org. 3588 Acknowledgment 3590 Funding for the RFC Editor function is provided by the IETF 3591 Administrative Support Activity (IASA).