idnits 2.17.1 draft-ietf-netlmm-proxymip6-10.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 3518. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3529. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3536. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3542. 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 09, 2008) is 5922 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 2030 (ref. 'RFC-4330') (Obsoleted by RFC 4330) -- 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 12, 2008 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 February 09, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-10.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 12, 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 Entries . . . . . . . . . . . 15 65 4.2. Security Policy Database 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 . . . . . . . . . . . . . . . 50 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51 100 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 52 101 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52 102 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 53 103 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53 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 . . . . . . . . . . . . . . . . . . . . . . . 55 108 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 56 109 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 57 110 6.14. Allowing network access to other IPv6 nodes . . . . . . . 57 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 . . . . . . . . . . . . . . . . . . . . . . . 59 115 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 60 116 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61 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 . . . . . 76 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. 274 Mobile Node's Home Network Prefix (MN-HNP) 275 This is the on-link IPv6 prefix that is always present in the 276 Router Advertisements that the mobile node receives when it is 277 attached to any of the access links in that Proxy Mobile IPv6 278 domain. This home network prefix is topologically anchored at the 279 mobile node's local mobility anchor. The mobile node configures 280 its interface with an address from this prefix. If the mobile 281 node connects to the Proxy Mobile IPv6 domain through multiple 282 interfaces, simultaneously, each of the connected interface will 283 be assigned a unique home network prefix and under a different 284 mobility session. 286 Mobile Node's Home Link 288 This is the link on which the mobile node obtained its Layer-3 289 address configuration for the attached interface after it moved 290 into that Proxy Mobile IPv6 domain. This is the link that 291 conceptually follows the mobile node. The network will ensure the 292 mobile node always sees this link with respect to the layer-3 293 network configuration, on any access link that it attaches to in 294 that Proxy Mobile IPv6 domain. 296 Multihomed Mobile Node 298 A mobile node that connects to the Proxy Mobile IPv6 domain 299 through more than one interface and uses these interfaces 300 simultaneously is referred to as a multihomed mobile node. 302 Mobile Node Identifier (MN-Identifier) 304 The identity of a mobile node in the Proxy Mobile IPv6 domain. 305 This is the stable identifier of a mobile node that the mobility 306 entities in a Proxy Mobile IPv6 domain can always acquire and use 307 it for predictably identifying a mobile node. This is typically 308 an identifier such as NAI or other identifier such as a MAC 309 address. 311 Mobile Node Interface Identifier (MN-Interface-Identifier) 313 The interface identifier that identifies a given interface of a 314 mobile node. For those interfaces that have a layer-2 identifier, 315 the interface identifier can be based on that layer-2 identifier. 316 The interface identifier in some cases is generated by the mobile 317 node and conveyed to the access router or the mobile access 318 gateway. In some cases, there might not be any interface 319 identifier associated with the mobile node's interface. 321 Policy Profile 322 Policy Profile is an abstract term for referring to a set of 323 configuration parameters that are configured for a given mobile 324 node. The mobility entities in the Proxy Mobile IPv6 domain 325 require access to these parameters for providing the mobility 326 management to a given mobile node. The specific details on how 327 the network entities obtain this policy profile is outside the 328 scope of this document. 330 Proxy Binding Update (PBU) 332 A binding registration request message sent by a mobile access 333 gateway to a mobile node's local mobility anchor for establishing 334 a binding between the mobile node's MN-HNP and the Proxy-CoA. 336 Proxy Binding Acknowledgement (PBA) 338 A binding registration reply message sent by a local mobility 339 anchor in response to a Proxy Binding Update request message that 340 it received from a mobile access gateway. 342 3. Proxy Mobile IPv6 Protocol Overview 344 This specification describes a network-based mobility management 345 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 346 [RFC-3775]. 348 Proxy Mobile IPv6 protocol is intended for providing network-based IP 349 mobility management support to a mobile node, without requiring the 350 participation of the mobile node in any IP mobility related 351 signaling. The mobility entities in the network will track the 352 mobile node's movements and will initiate the mobility signaling and 353 setup the required routing state. 355 The core functional entities in the NETLMM infrastructure are the 356 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 357 local mobility anchor is responsible for maintaining the mobile 358 node's reachability state and is the topological anchor point for the 359 mobile node's home network prefix. The mobile access gateway is the 360 entity that performs the mobility management on behalf of a mobile 361 node and it resides on the access link where the mobile node is 362 anchored. The mobile access gateway is responsible for detecting the 363 mobile node's movements to and from the access link and for 364 initiating binding registrations to the mobile node's local mobility 365 anchor. The architecture of a Proxy Mobile IPv6 domain is shown in 366 Figure 1. 368 +----+ +----+ 369 |LMA1| |LMA2| 370 +----+ +----+ 371 LMAA1 -> | | <-- LMAA2 372 | | 373 \\ //\\ 374 \\ // \\ 375 \\ // \\ 376 +---\\------------- //------\\----+ 377 ( \\ IPv4/IPv6 // \\ ) 378 ( \\ Network // \\ ) 379 +------\\--------//------------\\-+ 380 \\ // \\ 381 \\ // \\ 382 \\ // \\ 383 Proxy-CoA1--> | | <-- Proxy-CoA2 384 +----+ +----+ 385 |MAG1|-----{MN2} |MAG2| 386 +----+ | +----+ 387 | | | 388 MN-HoA1 --> | MN-HoA2 | <-- MN-HoA3 389 {MN1} {MN3} 391 Figure 1: Proxy Mobile IPv6 Domain 393 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 394 an access link, the mobile access gateway on that access link, after 395 identifying the mobile node and acquiring its identity, will 396 determine if the mobile node is authorized for the network-based 397 mobility management service. 399 If the network determines that the network-based mobility management 400 service needs to be offered to that mobile node, the network will 401 ensure that the mobile node using any of the address configuration 402 mechanisms permitted by the network will be able to obtain the 403 address configuration on the connected interface and move anywhere in 404 that Proxy Mobile IPv6 domain. The obtained address configuration 405 includes the address(es) from its home network prefix, the default- 406 router address on the link and other related configuration 407 parameters. From the perspective of the mobile node, the entire 408 Proxy Mobile IPv6 domain appears as a single link, the network 409 ensures that the mobile node believes it is always on the same link 410 where it obtained its initial address configuration, even after 411 changing its point of attachment in that network. 413 The mobile node may be operating in an IPv4-only mode, IPv6-only mode 414 or in dual IPv4/IPv6 mode. Based on what is enabled in the network 415 for that mobile node, the mobile node will be able to obtain an IPv4, 416 IPv6 or dual IPv4/IPv6 addresses and move anywhere in that Proxy 417 Mobile IPv6 domain. However, the specific details related to the 418 IPv4 addressing or IPv4 transport support are specified in the 419 companion document [ID-IPV4-PMIP6]. 421 If the mobile node connects to the Proxy Mobile IPv6 domain, through 422 multiple interfaces and over multiple access networks, the network 423 will allocate a unique home network prefix for each of the connected 424 interfaces and the mobile node will be able to configure an 425 address(es) on those interfaces from the respective home network 426 prefixes. However, if the mobile node performs an handoff from one 427 interface to another and if the local mobility anchor receives an 428 handoff hint from the serving mobile access gateway about the same, 429 the local mobility anchor will assign the same prefix to the new 430 interface. 432 +-----+ +-----+ +-----+ 433 | MN | | MAG | | LMA | 434 +-----+ +-----+ +-----+ 435 | | | 436 MN Attached | | 437 | | | 438 | MN Attached Event | 439 | (Acquire MN-Id and Profile) | 440 | | | 441 | |----- PBU ----------->| 442 | | | 443 | | Accept PBU 444 | | (Allocate MN-HNP, Setup BCE and Tunnel) 445 | | | 446 | |<--------- PBA -------| 447 | | | 448 | Accept PBA | 449 | (Setup Tunnel and Routing) | 450 | | | 451 | |==== Bi-Dir Tunnel ===| 452 | | | 453 |--- Rtr Sol --------->| | 454 | | | 455 |<------- Rtr Adv -----| | 456 | | | 457 IP Address | | 458 Configuration | | 459 | | | 461 Figure 2: Mobile Node Attachment - Signaling Call Flow 463 Figure 2 shows the signaling call flow when the mobile node enters 464 the Proxy Mobile IPv6 domain. 466 For updating the local mobility anchor about the current location of 467 the mobile node, the mobile access gateway sends a Proxy Binding 468 Update message to the mobile node's local mobility anchor. Upon 469 accepting this Proxy Binding Update message, the local mobility 470 anchor sends a Proxy Binding Acknowledgement message including the 471 mobile node's home network prefix. It also creates the Binding Cache 472 entry and establishes a bi-directional tunnel to the mobile access 473 gateway. 475 The mobile access gateway on receiving the Proxy Binding 476 Acknowledgement message sets up a bi-directional tunnel to the local 477 mobility anchor and sets up the data path for the mobile node's 478 traffic. At this point the mobile access gateway will have all the 479 required information for emulating the mobile node's home link. It 480 sends Router Advertisement messages to the mobile node on the access 481 link advertising the mobile node's home network prefix as the hosted 482 on-link-prefix. 484 The mobile node on receiving these Router Advertisement messages on 485 the access link will attempt to configure its interface either using 486 stateful or stateless address configuration modes, based on the modes 487 that are permitted on that access link. At the end of a successful 488 address configuration procedure, the mobile node will end up with an 489 address from its home network prefix. 491 Once the address configuration is complete, the mobile node has a 492 valid address from its home network prefix at the current point of 493 attachment. The serving mobile access gateway and the local mobility 494 anchor also have proper routing states for handling the traffic sent 495 to and from the mobile node using an address from its home network 496 prefix. 498 The local mobility anchor, being the topological anchor point for the 499 mobile node's home network prefix, receives any packets that are sent 500 by any correspondent node to the mobile node. The local mobility 501 anchor forwards these received packets to the mobile access gateway 502 through the bi-directional tunnel. The mobile access gateway on 503 other end of the tunnel, after receiving the packet, removes the 504 outer header and forwards the packet on the access link to the mobile 505 node. 507 The mobile access gateway typically acts as a default router on the 508 access link. Any packet that the mobile node sends to any 509 correspondent node will be received by the mobile access gateway and 510 will be sent to its local mobility anchor through the bi-directional 511 tunnel. The local mobility anchor on the other end of the tunnel, 512 after receiving the packet, removes the outer header and routes the 513 packet to the destination. 515 +-----+ +-----+ +-----+ +-----+ 516 | MN | |p-MAG| | LMA | |n-MAG| 517 +-----+ +-----+ +-----+ +-----+ 518 | | | | 519 | |==Bi-Dir Tunnel=| | 520 MN Detached | | | 521 | MN Detached Event | | 522 | | | | 523 | |-- DeReg PBU -->| | 524 | | | | 525 | | Accept PBU | 526 | | (Start MinDelayBeforeBCEDelete Timer) 527 | | | | 528 | |<-------- PBA --| | 529 | | | | 530 MN Attached | | | 531 | | | MN Attached Event 532 | | | (Acquire MN-Id and Profile) 533 .... 534 Registration steps as in fig 2. 535 .... 536 | | |==Bi-Dir Tunnel=| 537 |--- Rtr Sol ------------------------------------->| 538 | | | | 539 |<------------------------------------ Rtr Adv ----| 540 | | | | 541 MN retains HoA/HNP 542 | | | | 544 Figure 3: Mobile Node Handoff - Signaling Call Flow 546 Figure 3 shows the signaling call flow for the mobile node's handoff 547 from previously attached mobile access gateway (p-MAG) to the newly 548 attached mobile access gateway (n-MAG). This call flow reflects only 549 a specific message ordering, it is possible the registration message 550 from the n-MAG may arrive before the de-registration message from the 551 p-MAG arrives. 553 After obtaining the initial address configuration in the Proxy Mobile 554 IPv6 domain, if the mobile node changes its point of attachment, the 555 mobile access gateway on the previous link will detect the mobile 556 node's detachment from the link and will signal the local mobility 557 anchor and will remove the binding and routing state for that mobile 558 node. However, the local mobility anchor upon accepting the request 559 will wait for certain amount of time before it deletes the binding, 560 for allowing a smooth handoff. 562 The mobile access gateway on the new access link upon detecting the 563 mobile node on its access link will signal the local mobility anchor 564 for updating the binding state. Once that signaling is complete, the 565 mobile node will continue to receive the Router Advertisements 566 containing its home network prefix, making it believe it is still on 567 the same link and it will use the same address configuration on the 568 new access link. 570 4. Proxy Mobile IPv6 Protocol Security 572 The signaling messages, Proxy Binding Update and Proxy Binding 573 Acknowledgement, exchanged between the mobile access gateway and the 574 local mobility anchor MUST be protected using end-to-end security 575 association(s) offering integrity and data origin authentication. 577 The mobile access gateway and the local mobility anchor MUST 578 implement IPsec for protecting the Proxy Mobile IPv6 signaling 579 messages [RFC-4301]. That is, IPsec is mandatory to implement 580 security mechanism. However, additional documents may specify 581 alternative mechanisms. 583 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 584 protection SHOULD be used for protecting the signaling messages. 585 Confidentiality protection of these messages is not required. 587 IKEv2 [RFC-4306] SHOULD be used to setup security associations 588 between the mobile access gateway and the local mobility anchor to 589 protect the Proxy Binding Update and Proxy Binding Acknowledgement 590 messages. The mobile access gateway and the local mobility anchor 591 can use any of the authentication mechanisms, as specified in IKEv2, 592 for mutual authentication. 594 The Mobile IPv6 specification [RFC-3775] requires the home agent to 595 prevent a mobile node from creating security associations or creating 596 binding cache entries for another mobile node's home address. In the 597 protocol described in this document, the mobile node is not involved 598 in creating security associations for protecting the signaling 599 messages or sending binding updates. Therefore, the local mobility 600 anchor MUST restrict the creation and manipulation of proxy bindings 601 to specifically authorized mobile access gateways and prefixes. The 602 local mobility anchor MUST be locally configurable to authorize such 603 specific combinations. Additional mechanisms such as a policy store 604 or AAA may be employed, but these are outside the scope of this 605 specification. 607 4.1. Peer Authorization Database Entries 609 This section describes PAD entries [RFC-4301] on the mobile access 610 gateway and the local mobility anchor. The PAD entries are only 611 example configurations. Note that the PAD is a logical concept and a 612 particular mobile access gateway or a local mobility anchor 613 implementation can implement the PAD in any implementation specific 614 manner. The PAD state may also be distributed across various 615 databases in a specific implementation. 617 mobile access gateway PAD: 618 - IF remote_identity = lma_identity_1 619 Then authenticate (shared secret/certificate/EAP) 620 and authorize CHILD_SA for remote address lma_addres_1 622 local mobility anchor PAD: 623 - IF remote_identity = mag_identity_1 624 Then authenticate (shared secret/certificate/EAP) 625 and authorize CHILD_SAs for remote address mag_address_1 627 Figure 4: PAD Entries 629 The list of authentication mechanisms in the above examples is not 630 exhaustive. There could be other credentials used for authentication 631 stored in the PAD. 633 4.2. Security Policy Database Entries 635 This section describes the security policy entries [RFC-4301] on the 636 mobile access gateway and the local mobility anchor required to 637 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 638 are only example configurations. A particular mobile access gateway 639 or a local mobility anchor implementation could configure different 640 SPD entries as long as they provide the required security. 642 In the examples shown below, the identity of the mobile access 643 gateway is assumed to be mag_1, the address of the mobile access 644 gateway is assumed to be mag_address_1, and the address of the local 645 mobility anchor is assumed to be lma_address_1. 647 mobile access gateway SPD-S: 648 - IF local_address = mag_address_1 & 649 remote_address = lma_address_1 & 650 proto = MH & local_mh_type = BU & remote_mh_type = BA 651 Then use SA ESP transport mode 652 Initiate using IDi = mag_1 to address lma_address_1 654 local mobility anchor SPD-S: 655 - IF local_address = lma_address_1 & 656 remote_address = mag_address_1 & 657 proto = MH & local_mh_type = BA & remote_mh_type = BU 658 Then use SA ESP transport mode 660 Figure 5: SPD Entries 662 5. Local Mobility Anchor Operation 664 The local mobility anchor MUST support the home agent function as 665 defined in [RFC-3775] and additionally the extensions defined in this 666 specification. A home agent with these modifications and enhanced 667 capabilities for supporting Proxy Mobile IPv6 protocol is referred to 668 as the local mobility anchor. 670 This section describes the operational details of the local mobility 671 anchor. 673 5.1. Extensions to Binding Cache Entry Data Structure 675 Every local mobility anchor MUST maintain a Binding Cache entry for 676 each currently registered mobile node. Binding Cache entry is a 677 conceptual data structure, described in Section 9.1 [RFC-3775]. 679 For supporting this specification, the Binding Cache Entry data 680 structure needs to be extended with the following additional fields. 682 o A flag indicating whether or not this Binding Cache entry is 683 created due to a proxy registration. This flag is enabled for 684 Binding Cache entries that are proxy registrations and is turned 685 off for all other entries. 687 o The identifier of the registered mobile node, MN-Identifier. This 688 identifier is obtained from the Mobile Node Identifier Option 689 [RFC-4283] present in the received Proxy Binding Update request. 691 o The interface identifier of the mobile node's connected interface 692 on the access link. This identifier can be acquired from the 693 Mobile Node Interface Identifier option, present in the received 694 Proxy Binding Update request. If the option was not present in 695 the request, the value MUST be set to ALL_ZERO. 697 o The Link-local address of the mobile node on the interface 698 attached to the access link. This is obtained from the Link-local 699 Address option, present in the Proxy Binding Update request. If 700 the option was not present in the request, the value MUST be set 701 to ALL_ZERO. 703 o The IPv6 home network prefix that is assigned to the mobile node's 704 connected interface. The home network prefix of the mobile node 705 may have been statically configured in the mobile node's policy 706 profile, or, it may have been dynamically allocated by the local 707 mobility anchor. The IPv6 home network prefix also includes the 708 corresponding prefix length. 710 o The interface identifier (If-Id) of the bi-directional tunnel 711 between the local mobility anchor and the mobile access gateway 712 where the mobile node is currently anchored. This is internal to 713 the local mobility anchor. The tunnel interface identifier is 714 acquired during the tunnel creation. 716 o The access technology type, using which the mobile node is 717 currently attached. This is obtained from the Access Technology 718 Type option, present in the Proxy Binding Update request. 720 o The 64-bit timestamp value of the most recently accepted Proxy 721 Binding Update request sent for this mobile node. This is the 722 time-of-day on the local mobility anchor, when the message was 723 received. If the Timestamp option is not present in the Proxy 724 Binding Update request (i.e., when sequence number based scheme is 725 in use), the value MUST be set to ALL_ZERO. 727 Typically, the mobile node's home network prefix is the key for 728 locating a Binding Cache entry in all cases except when there has 729 been an handoff of the mobile node's session to a new mobile access 730 gateway and that mobile access gateway is unaware of the home network 731 prefix that was assigned to the handed of session. In such handoff 732 cases, the Binding Cache entry can be located under the 733 considerations specified in Section 5.4.1. 735 5.2. Supported Home Network Prefix Models 737 This specification supports Per-MN-Prefix model and does not support 738 Shared-Prefix model. As per the Per-MN-Prefix model, there will be a 739 unique home network prefix assigned to each mobile node and no other 740 node shares an address from that prefix. The assigned prefix is 741 unique to a mobile node and also unique to a given interface of the 742 mobile node. If the mobile node attaches to the Proxy Mobile IPv6 743 domain through multiple interfaces and simultaneously, each of those 744 connected interfaces will be assigned a different prefix. 746 The mobile node's home network prefix is always hosted on the access 747 link where the mobile node is anchored. Conceptually, the entire 748 home network prefix follows the mobile node as it moves within the 749 Proxy Mobile IPv6 domain. The local mobility anchor is not required 750 to perform any proxy ND operations [RFC-4861] for defending the 751 mobile node's home address on the home link. However, from the 752 routing perspective, the home network prefix is topologically 753 anchored on the local mobility anchor. 755 5.3. Signaling Considerations 757 This section provides the rules for processing the signaling 758 messages. The processing rules specified in this section and other 759 related sections are chained and are in a specific order. When 760 applying these considerations for processing the signaling messages, 761 the specified order MUST be maintained. 763 5.3.1. Processing Binding Registrations 765 1. The received Proxy Binding Update message (a Binding Update 766 message with the 'P' flag set) MUST be authenticated as 767 described in Section 4. When IPsec is used for message 768 authentication, the SPI in the IPsec header [RFC-4306] of the 769 received packet is needed for locating the security association, 770 for authenticating the Proxy Binding Update message. 772 2. The local mobility anchor MUST observe the rules described in 773 Section 9.2 [RFC-3775] when processing Mobility Header in the 774 received Proxy Binding Update request. Additionally, the rules 775 specified in Section 10.3 [RFC-3775] MUST be applied when 776 processing this message. 778 3. The local mobility anchor MUST ignore the check, specified in 779 Section 10.3.1 [RFC-3775], related to the presence of Home 780 Address destination option in the Proxy Binding Update request. 782 4. The local mobility anchor MUST identify the mobile node from the 783 identifier present in the Mobile Node Identifier option [RFC- 784 4283] of the Proxy Binding Update request. If the Mobile Node 785 Identifier option is not present in the Proxy Binding Update 786 request, the local mobility anchor MUST reject the request and 787 send a Proxy Binding Acknowledgement message with Status field 788 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 789 identifier option) and the identifier in the Mobile Node 790 Identifier Option carried in the message MUST be set to a zero 791 length identifier. 793 5. The local mobility anchor MUST apply the required policy checks, 794 as explained in Section 4, to verify the sender is a trusted 795 mobile access gateway, authorized to send Proxy Binding Update 796 requests on behalf of this mobile node. 798 6. If the local mobility anchor determines that the requesting node 799 is not authorized to send Proxy Binding Update requests for the 800 identified mobile node, it MUST reject the request and send a 801 Proxy Binding Acknowledgement message with Status field set to 802 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 803 binding registrations). 805 7. If the local mobility anchor cannot identify the mobile node 806 based on the identifier present in the Mobile Node Identifier 807 option [RFC-4283] of Proxy Binding Update request, it MUST 808 reject the request and send a Proxy Binding Acknowledgement 809 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 810 (Not local mobility anchor for this mobile node). 812 8. If the local mobility anchor determines that the mobile node is 813 not authorized for the network-based mobility management 814 service, it MUST reject the request and send a Proxy Binding 815 Acknowledgement message with Status field set to 816 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 818 9. The local mobility anchor MUST apply the considerations 819 specified in Section 5.5, for processing the Sequence Number 820 field and the Timestamp option (if present), in the Proxy 821 Binding Update request. 823 10. If the Home Network Prefix option (containing either ALL_ZERO or 824 some prefix value) is not present in the Proxy Binding Update 825 request, the local mobility anchor MUST reject the request and 826 send a Proxy Binding Acknowledgement message with Status field 827 set to MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network 828 prefix option). 830 11. If the Handoff Indicator option is not present in the Proxy 831 Binding Update request, the local mobility anchor MUST reject 832 the request and send a Proxy Binding Acknowledgement message 833 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 834 (Missing handoff indicator option). 836 12. If the Access Technology Type option is not present in the Proxy 837 Binding Update request, the local mobility anchor MUST reject 838 the request and send a Proxy Binding Acknowledgement message 839 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 840 (Missing access technology type option). 842 13. Considerations specified in Section 5.4.1 MUST be applied for 843 performing the Binding Cache entry existence test. If those 844 checks specified in Section 5.4.1, result in associating the 845 received Proxy Binding Update request to a new mobility session 846 creation request, considerations from Section 5.3.2 (Initial 847 Binding Registration - New Mobility Session), MUST be applied. 848 If those checks result in associating the request to an existing 849 mobility session, the following checks determine the next set of 850 processing rules that needs to be applied. 852 * If the Handoff Indicator field in the Handoff Indicator 853 option present in the request is set to a value of 5 (Handoff 854 state not changed), considerations from Section 5.3.3 855 (Binding Lifetime Extension- No handoff) MUST be applied. 857 * If the received Proxy Binding Update request has the lifetime 858 value of zero, considerations from Section 5.3.5 (Binding De- 859 Registration) MUST be applied. 861 * For all other cases, considerations from Section 5.3.4 862 (Binding Lifetime Extension - After handoff) MUST be applied. 864 14. When sending the Proxy Binding Acknowledgement message with any 865 Status field value, the message MUST be constructed as specified 866 in Section 5.3.6. 868 5.3.2. Initial Binding Registration (New Mobility Session) 870 1. If the Home Network Prefix option present in the Proxy Binding 871 Update request has the value set to ALL_ZERO, the local mobility 872 anchor MUST allocate a prefix and assign it to a new mobility 873 session created for the mobile node. The local mobility anchor 874 MUST ensure the allocated prefix is not in use by any other node 875 or mobility session. 877 2. If the local mobility anchor is unable to allocate any home 878 network prefix for the mobile node, it MUST reject the request 879 and send a Proxy Binding Acknowledgement message with Status 880 field set to 130 (Insufficient resources). 882 3. If the Home Network Prefix option present in the request has a 883 specific prefix hint, the local mobility anchor before accepting 884 that request, MUST ensure the prefix is owned by the local 885 mobility anchor and further the mobile node is authorized to use 886 that prefix. If the mobile node is not authorized to use that 887 prefix, the local mobility anchor MUST reject the request and 888 send a Proxy Binding Acknowledgement message with Status field 889 set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (Mobile node not 890 authorized to use that prefix). 892 4. Upon accepting the request, the local mobility anchor MUST create 893 a Binding Cache entry for the mobile node. It must set the 894 fields in the Binding Cache entry to the accepted values for that 895 registration. 897 5. The local mobility anchor MUST establish a bi-directional tunnel 898 to the mobile access gateway (if there does not exist one) that 899 sent the request and setup the routing state. Considerations 900 from Section 5.6 MUST be applied for creating the routing state. 902 6. The local mobility anchor MUST send the Proxy Binding 903 Acknowledgement message with the Status field set to 0 (Proxy 904 Binding Update Accepted). The message MUST be constructed as 905 specified in Section 5.3.6. 907 5.3.3. Binding Lifetime Extension (No handoff) 909 1. Upon accepting the Proxy Binding Update request for extending the 910 binding lifetime, received from the same mobile access gateway 911 that last updated the binding (i.e., when there is no handoff), 912 the local mobility anchor MUST update the Binding Cache entry 913 with the accepted registration values. However, if the link- 914 local address value in the Link-local address option is ALL_ZERO 915 value, the link-local address field in the Binding Cache entry 916 MUST NOT be updated. 918 2. The local mobility anchor MUST send the Proxy Binding 919 Acknowledgement message with the Status field set to 0 (Proxy 920 Binding Update Accepted). The message MUST be constructed as 921 specified in Section 5.3.6. 923 5.3.4. Binding Lifetime Extension (After handoff) 925 1. Upon accepting the Proxy Binding Update request for extending the 926 binding lifetime, received from a new mobile access gateway where 927 the mobile node's session is handed off, the local mobility 928 anchor MUST update the Binding Cache entry with the accepted 929 registration values. However, if the link-local address value in 930 the Link-local address option is ALL_ZERO value, the link-local 931 address field in the Binding Cache entry MUST NOT be updated. 933 2. The local mobility anchor MUST remove the previously created 934 route for the mobile node's home network prefix. Additionally, 935 if there are no other mobile node's sessions sharing the tunnel 936 to the previous mobile access gateway, the tunnel MUST be 937 deleted. 939 3. The local mobility anchor MUST establish a bi-directional tunnel 940 to the mobile access gateway that sent the request. 941 Considerations from Section 5.6 MUST be applied for creating the 942 routing state. 944 4. The local mobility anchor MUST send the Proxy Binding 945 Acknowledgement message with the Status field set to 0 (Proxy 946 Binding Update Accepted). The message MUST be constructed as 947 specified in Section 5.3.6. 949 5.3.5. Binding De-Registration 951 1. If the received Proxy Binding Update request with the lifetime 952 value of zero, has a Source Address in the IPv6 header (or the 953 address in the Alternate Care-of Address option, if the option is 954 present) different from what is present in the Proxy-CoA address 955 field in the Binding Cache entry, the local mobility anchor MUST 956 ignore the request. 958 2. Upon accepting the Proxy Binding Update request with the lifetime 959 value of zero, the local mobility anchor MUST wait for 960 MinDelayBeforeBCEDelete amount of time, before it deletes the 961 Binding Cache entry. However, it MUST send the Proxy Binding 962 Acknowledgement message with the Status field set to 0 (Proxy 963 Binding Update Accepted). The message MUST be constructed as 964 specified in Section 5.3.6. 966 * During this wait period, the local mobility anchor SHOULD drop 967 the mobile node's data traffic. 969 * During this wait period, if the local mobility anchor receives 970 a valid Proxy Binding Update request for the same mobility 971 session with the lifetime value of greater than zero, and if 972 that request is accepted, then the Binding Cache entry MUST 973 NOT be deleted, but must be updated with the newly accepted 974 registration values and additionally the wait period should be 975 ended. 977 * By the end of this wait period, if the local mobility anchor 978 did not receive any valid Proxy Binding Update request for 979 this mobility session, then it MUST delete the Binding Cache 980 entry and remove the routing state created for that mobility 981 session. 983 5.3.6. Constructing the Proxy Binding Acknowledgement Message 985 o The local mobility anchor when sending the Proxy Binding 986 Acknowledgement message to the mobile access gateway MUST 987 construct the message as specified below. 989 IPv6 header (src=LMAA, dst=Proxy-CoA) 990 Mobility header 991 - BA /* P flag must be set */ 992 Mobility Options 993 - Mobile Node Identifier Option (mandatory) 994 - Home Network Prefix option (mandatory) 995 - Handoff Indicator option (mandatory) 996 - Access Technology Type option (mandatory) 997 - Timestamp Option (optional) 998 - Mobile Node Interface Identifier option (optional) 999 - Link-local Address option (optional) 1001 Figure 6: Proxy Binding Acknowledgement message format 1003 o The Source Address field in the IPv6 header of the message MUST be 1004 set to the destination address of the received Proxy Binding 1005 Update request. 1007 o The Destination Address field in the IPv6 header of the message 1008 MUST be set to the source address of the received Proxy Binding 1009 Update request. When there is no Alternate Care-of Address option 1010 present in the request, the destination address is the same as the 1011 Proxy-CoA address, otherwise, the address may not be the same as 1012 the Proxy-CoA. 1014 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1015 identifier field in the option MUST be copied from the Mobile Node 1016 Identifier option in the received Proxy Binding Update request. 1017 If the option was not present in the request, the identifier in 1018 the option MUST be set to a zero length identifier. 1020 o The Home Network Prefix option MUST be present. 1022 * If the Status field is set to a value greater than or equal to 1023 128, i.e., if the binding request is rejected, then the prefix 1024 value in the Home Network Prefix option MUST be set to the 1025 prefix value in the Home Network Prefix option of the received 1026 Proxy Binding Update request. But, if the option was not 1027 present in the request, the value in the option MUST be set to 1028 ALL_ZERO. 1030 * For all other cases, the prefix value in the option MUST be set 1031 to the allocated prefix value for that mobility session. 1033 o The Handoff Indicator option MUST be present. The handoff 1034 indicator field in the option MUST be copied from the Handoff 1035 Indicator option in the received Proxy Binding Update request. If 1036 the option was not present in the request, the value in the option 1037 MUST be set to zero. 1039 o The Access Technology Type option MUST be present. The access 1040 technology type field in the option MUST be copied from the Access 1041 Technology Type option in the received Proxy Binding Update 1042 request. If the option was not present in the request, the value 1043 in the option MUST be set to zero. 1045 o The Timestamp option MUST be present, if the same option was 1046 present in the received Proxy Binding Update request. 1047 Considerations from Section 5.5 must be applied for constructing 1048 the Timestamp option. 1050 o The Mobile Node Interface Identifier option MUST be present, if 1051 the same option was present in the received Proxy Binding Update 1052 request. The interface identifier value MUST be copied from the 1053 Mobile Node Interface Indicator option present in the received 1054 Proxy Binding Update request. 1056 o The Link-local Address option MUST be present, if the same option 1057 was present in the received Proxy Binding Update request. 1059 * If the received Proxy Binding Update request has the Link-local 1060 Address option with any value other than ALL_ZERO, the same 1061 value MUST be copied to the Link-local Address option in the 1062 reply. 1064 * If there is no existing Binding Cache entry (i.e., if this is a 1065 request for a new mobility session), or if there is an existing 1066 Binding Cache entry with the link-local address value set to 1067 ALL_ZERO, then the link-local address in the option MUST be 1068 copied from the Link-local Address option present in the 1069 received Proxy Binding Update request. 1071 * For all other cases, the link-local address in the option MUST 1072 be copied from the Link-local Address field of the Binding 1073 Cache entry. 1075 o If IPsec is used for protecting the signaling messages, the 1076 message MUST be protected, using the security association existing 1077 between the local mobility anchor and the mobile access gateway. 1079 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1080 NOT be present in the IPv6 header of the packet. 1082 5.4. Multihoming Support 1084 This specification allows mobile nodes to connect to a Proxy Mobile 1085 IPv6 domain through multiple interfaces and for simultaneous access. 1086 Following are the key aspects of this multihoming support. 1088 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1089 multiple interfaces and for simultaneous access, the local 1090 mobility anchor MUST allocate a unique home network prefix for 1091 each of the connected interfaces. 1093 o The local mobility anchor MUST manage each of the allocated home 1094 network prefixes as part of a separate mobility session, each 1095 under a separate Binding Cache entry and with its own lifetime. 1097 o The local mobility anchor MUST allow for an handoff between two 1098 different interfaces of the mobile node. In such a case, the home 1099 network prefix that is associated with a specific interface 1100 identifier of a mobile node will be updated with the new interface 1101 identifier. The decision on when to create a new mobility session 1102 and when to update an existing mobility session MUST be based on 1103 the Handover hint present in the Proxy Binding Update message and 1104 under the considerations specified in this section. 1106 5.4.1. Binding Cache entry lookup considerations 1108 There can be multiple Binding Cache entries for a given mobile node. 1109 When doing a lookup for a mobile node's Binding Cache entry for 1110 processing a received Proxy Binding Update request message, the local 1111 mobility anchor MUST apply the following multihoming considerations 1112 (in the below specified order). These rules are chained with the 1113 processing rules specified in Section 5.3. 1115 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1116 request 1118 +=====================================================================+ 1119 | Registration/De-Registration Message | 1120 +=====================================================================+ 1121 | HNP (NON_ZERO Value) | 1122 +=====================================================================+ 1123 | ATT | 1124 +=====================================================================+ 1125 | IID Option Present | IID Option Not present | 1126 +=====================================================================+ 1127 | HI | 1128 +==================================+==================================+ 1129 | BCE Lookup Key: (Home Network Prefix) | 1130 +=====================================================================+ 1132 Figure 7: BCE lookup using home network prefix 1134 1. The local mobility anchor MUST verify if there is an existing 1135 Binding Cache entry with the home network prefix value matching 1136 the prefix value in the Home Network Prefix option of the 1137 received Proxy Binding Update request. [BCE(HNP) == PBU(HNP)] 1139 2. If there does not exist a Binding Cache entry (matching the MN- 1140 HNP), the request MUST be considered as a request for creating a 1141 new mobility session. 1143 3. If there exists a Binding Cache entry (matching MN-HNP), and if 1144 the mobile node identifier in the entry does not match the mobile 1145 node identifier in the Mobile Node Identifier option of the 1146 received Proxy Binding Update request, the local mobility anchor 1147 MUST reject the request with the Status field value set to 1148 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1149 authorized for the requesting home network prefix). [BCE(MN- 1150 Identifier) != PBU(MN-Identifier)] 1152 4. If there exists a Binding Cache entry (matching MN-Identifier and 1153 MN-HNP) and if any one or more of these below stated conditions 1154 match, the request MUST be considered as a request for updating 1155 that Binding Cache entry. [BCE(MN-Identifier) == PBU(MN- 1156 Identifier)] 1158 * If there is a Mobile Node Interface Identifier option present 1159 in the request, and if the interface identifier value in that 1160 option matches the interface identifier value in the Binding 1161 Cache entry and the access technology type field in the Access 1162 Technology Type option present in the request matches the 1163 access technology type in the Binding Cache entry . [BCE(ATT, 1164 MN-Interface-Identifier) == PBU(ATT, MN-Interface-Identifier)] 1166 * If the Handoff Indicator field in the Handoff Indicator option 1167 present in the request is set to a value of 2 (Handoff between 1168 two different interfaces of the mobile node). 1170 * If there is no Mobile Node Interface Identifier option present 1171 in the request, the interface identifier value in the Binding 1172 Cache entry is set to ALL_ZERO, the access technology type 1173 field in the Access Technology Type option present in the 1174 request matches the access technology type in the Binding 1175 Cache entry and if the Handoff Indicator field in the Handoff 1176 Indicator option present in the request is set to a value of 3 1177 (Handoff between mobile access gateways for the same 1178 interface). 1180 * If the Proxy-CoA address in the Binding Cache entry matches 1181 the source address of the request (or the address in the 1182 alternate Care-of Address option, if the option is present) 1183 and if the access technology type field in the Access 1184 Technology Type option present in the request matches the 1185 access technology type in the Binding Cache entry. 1186 [BCE(Proxy-CoA, ATT) == PBU(Proxy-CoA, ATT)]. 1188 5. For all other cases, the message MUST be considered as a request 1189 for creating a new mobility session. 1191 5.4.1.2. Mobile Node Interface Identifier Option present in the request 1193 +=====================================================================+ 1194 | Registration/De-Registration Message | 1195 +=====================================================================+ 1196 | HNP (ALL_ZERO Value) | 1197 +=====================================================================+ 1198 | ATT | 1199 +=====================================================================+ 1200 | IID Option Present (NON_ZERO Value) | 1201 +=====================================================================+ 1202 | HI | 1203 +==================================+==================================+ 1204 | BCE Lookup Keys: (MN-Identifier + Access Technology Type + | 1205 | MN-Interface-Identifier) | 1206 +=====================================================================+ 1208 Figure 8: BCE Lookup using Interface Identifier 1210 1. The local mobility anchor MUST verify if there is an existing 1211 Binding Cache entry, with the mobile node identifier matching the 1212 identifier in the received Mobile Node Identifier option, access 1213 technology type matching the value in the received Access 1214 Technology Type option and the interface identifier value 1215 matching the identifier in the received Mobile Node Interface 1216 Identifier option. [BCE(MN-Identifier, ATT, MN-Interface- 1217 Identifier) == PBU(MN-Identifier, ATT, MN-Interface-Identifier)] 1219 2. If there exists a Binding Cache entry (matching MN-Identifier, 1220 ATT and MN-Interface-Identifier), the request MUST be considered 1221 as a request for updating that Binding Cache entry. 1223 3. If there does not exist a Binding Cache entry (matching MN- 1224 Identifier, ATT and MN-Interface-Identifier) and the Handoff 1225 Indicator field in the Handoff Indicator option present in the 1226 request is set to a value of 2 (Handoff between two different 1227 interfaces of the mobile node). The local mobility anchor MUST 1228 apply the following additional considerations. [PBU(HI) == 2] 1230 * The local mobility anchor MUST verify if there exists one and 1231 only one Binding Cache entry with the mobile node identifier 1232 matching the identifier in the Mobile Node Identifier option 1233 present in the request and for any interface identifier value. 1234 If there exists only one such entry (matching the MN- 1235 Identifier), the request MUST be considered as a request for 1236 updating that Binding Cache entry. [BCE(MN-Identifier) == 1237 PBU(MN-Identifier)] 1239 4. If there does not exist a Binding Cache entry (matching MN- 1240 Identifier, ATT and MN-Interface-Identifier) and if the Handoff 1241 Indicator field in the Handoff Indicator option present in the 1242 request is set to a value of 4 (Handoff state unknown), the local 1243 mobility anchor MUST apply the following additional 1244 considerations. 1246 * The local mobility anchor MUST verify if there exists one and 1247 only one Binding Cache entry with the mobile node identifier 1248 matching the identifier in the Mobile Node Identifier option 1249 present in the request and for any interface identifier value. 1250 If there exists only one such entry (matching the MN- 1251 Identifier), the local mobility anchor SHOULD wait till the 1252 existing Binding Cache entry is de-registered by the 1253 previously serving mobile access gateway, before the request 1254 can be considered as a request for updating that Binding Cache 1255 entry. However, if there is no de-registration message that 1256 is received within MaxDelayBeforeNewBCEAssign amount of time, 1257 the local mobility anchor upon accepting the request MUST 1258 consider the request as a request for updating that Binding 1259 Cache entry. The local mobility anchor MAY also choose to 1260 create a new mobility session and without waiting for a de- 1261 registration message and this should be configurable on the 1262 local mobility anchor. 1264 5. For all other cases, the message MUST be considered as a request 1265 for creating a new mobility session. 1267 5.4.1.3. Mobile Node Interface Identifier Option not present in the 1268 request 1270 +=====================================================================+ 1271 | Registration/De-Registration Message | 1272 +=====================================================================+ 1273 | HNP (ALL_ZERO Value) | 1274 +=====================================================================+ 1275 | ATT | 1276 +=====================================================================+ 1277 | IID Option Not Present | 1278 +=====================================================================+ 1279 | HI | 1280 +==================================+==================================+ 1281 | BCE Lookup Key: (MN-Identifier) | 1282 +=====================================================================+ 1284 Figure 9: BCE Lookup using Mobile Node Identifier 1286 1. The local mobility anchor MUST verify if there exists one and 1287 only one Binding Cache entry with the mobile node identifier 1288 matching the identifier in the Mobile Node Identifier option 1289 present in the request. 1291 2. If there exists only one such entry (matching the MN-Identifier) 1292 and the Handoff Indicator field in the Handoff Indicator option 1293 present in the request is set to a value of 2 (Handoff between 1294 two different interfaces of the mobile node), the request MUST be 1295 considered as a request for updating that Binding Cache entry. 1296 [PBU(HI) == 2] 1298 3. If there exists only one such entry (matching the MN-Identifier) 1299 and the Handoff Indicator field in the Handoff Indicator option 1300 present in the request is set to a value of 4 (Handoff state 1301 unknown), the local mobility anchor SHOULD wait till the existing 1302 Binding Cache entry is de-registered by the previously serving 1303 mobile access gateway, before the request can be considered as a 1304 request for updating that Binding Cache entry. However, if there 1305 is no de-registration message that is received within 1306 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1307 anchor upon accepting the request MUST consider the request as a 1308 request for updating that Binding Cache entry. The local 1309 mobility anchor MAY also choose to create a new mobility session 1310 and without waiting for a de-registration message and this should 1311 be configurable on the local mobility anchor. 1313 4. For all other cases, the message MUST be considered as a request 1314 for creating a new mobility session. 1316 5.5. Timestamp Option for Message Ordering 1318 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1319 registration messages as a way for the home agent to process the 1320 binding updates in the order they were sent by a mobile node. The 1321 home agent and the mobile node are required to manage this counter 1322 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1323 the mobile node moves from one mobile access gateway to another and 1324 in the absence of mechanisms such as context transfer between the 1325 mobile access gateways, the serving mobile access gateway will be 1326 unable to determine the sequence number that it needs to use in the 1327 signaling messages. Hence, the sequence number scheme, as specified 1328 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1330 If the local mobility anchor cannot determine the sending order of 1331 the received binding registration messages, it may potentially 1332 process an older message sent by a mobile access gateway where the 1333 mobile node was previously anchored, resulting in an incorrect 1334 Binding Cache entry. 1336 For solving this problem, this specification adopts two alternative 1337 solutions. One is based on timestamps and the other based on 1338 sequence numbers, as defined in [RFC-3775]. 1340 The basic principle behind the use of timestamps in binding 1341 registration messages is that the node generating the message inserts 1342 the current time-of-day, and the node receiving the message checks 1343 that this timestamp is greater than all previously accepted 1344 timestamps. The timestamp based solution may be used, when the 1345 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1346 have the ability to obtain the last sequence number that was sent in 1347 a binding registration message for updating a given mobile node's 1348 binding. 1350 As an alternative to the Timestamp based approach, the specification 1351 also allows the use of Sequence Number based scheme, as per [RFC- 1352 3775]. However, for this scheme to work, the serving mobile access 1353 gateways in a Proxy Mobile IPv6 domain MUST have the ability to 1354 obtain the last sequence number that was sent in a binding 1355 registration message for updating a given mobile node's binding. The 1356 sequence number MUST be maintained on a per mobile node basis and 1357 MUST be synchronized between the serving mobile access gateways. 1359 This may be achieved by using context transfer schemes or by 1360 maintaining the sequence number in a policy store. However, the 1361 specific details on how the mobile node's sequence number is 1362 synchronized between different mobile access gateways is outside the 1363 scope of this document. 1365 Using Timestamps based approach: 1367 1. A local mobility anchor implementation MUST support Timestamp 1368 option. If the Timestamp option is present in the received Proxy 1369 Binding Update request message, then the local mobility anchor 1370 MUST include a valid Timestamp option in the Proxy Binding 1371 Acknowledgement message that it sends to the mobile access 1372 gateway. 1374 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1375 exchanging binding registration messages using the Timestamp 1376 option must have adequately synchronized time-of-day clocks. 1377 This is the essential requirement for this solution to work. If 1378 this requirement is not met, the solution will not predictably 1379 work in all cases. 1381 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1382 synchronize their clocks to a common time source. For 1383 synchronizing the clocks, the nodes may use Network Time Protocol 1384 [RFC-4330]. Deployments may also adopt other approaches suitable 1385 for that specific deployment. Alternatively, if there is mobile 1386 node generated timestamp that is increasing at every attachment 1387 to the access link and if that timestamp is available to the 1388 mobile access gateway (Ex: The timestamp option in the SEND 1389 messages that the mobile node sends), the mobile access gateway 1390 can use this timestamp or sequence number in the Proxy Binding 1391 Update messages and does not have to depend on any external clock 1392 source. However, the specific details on how this is achieved is 1393 outside the scope of this document. 1395 4. When generating the timestamp value for building the Timestamp 1396 option, the mobility entities MUST ensure that the generated 1397 timestamp is the elapsed time past the same reference epoch, as 1398 specified in the format for the Timestamp option [Section 8.8]. 1400 5. If the Timestamp option is present in the received Proxy Binding 1401 Update message, the local mobility anchor MUST ignore the 1402 sequence number field in the message. However, it MUST copy the 1403 sequence number from the received Proxy Binding Update message to 1404 the Proxy Binding Acknowledgement message. 1406 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1407 option, the local mobility anchor MUST check the timestamp field 1408 for validity. In order for it to be considered valid, the 1409 timestamp value contained in the Timestamp option MUST be close 1410 enough (within TimestampValidityWindow amount of time difference) 1411 to the local mobility anchor's time-of-day clock and the 1412 timestamp MUST be greater than all previously accepted timestamps 1413 in the Proxy Binding Update messages sent for that mobile node. 1415 7. If the timestamp value in the received Proxy Binding Update is 1416 valid (validity as specified in the above considerations), the 1417 local mobility anchor MUST return the same timestamp value in the 1418 Timestamp option included in the Proxy Binding Acknowledgement 1419 message that it sends to the mobile access gateway. 1421 8. If the timestamp value in the received Proxy Binding Update is 1422 lower than the previously accepted timestamp in the Proxy Binding 1423 Update messages sent for that mobility binding, the local 1424 mobility anchor MUST reject the Proxy Binding Update request and 1425 send a Proxy Binding Acknowledgement message with Status field 1426 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1427 previously accepted timestamp). The message MUST also include 1428 the Timestamp option with the value set to the current time-of- 1429 day on the local mobility anchor. 1431 9. If the timestamp value in the received Proxy Binding Update is 1432 not valid (validity as specified in the above considerations), 1433 the local mobility anchor MUST reject the Proxy Binding Update 1434 and send a Proxy Binding Acknowledgement message with Status 1435 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1436 message MUST also include the Timestamp option with the value set 1437 to the current time-of-day on the local mobility anchor. 1439 Using Sequence Number based approach: 1441 1. If the Timestamp option is not present in the received Proxy 1442 Binding Update request, the local mobility anchor MUST fallback 1443 to the Sequence Number based scheme. It MUST process the 1444 sequence number field as specified in [RFC-3775]. Also, it MUST 1445 NOT include the Timestamp option in the Proxy Binding 1446 Acknowledgement messages that it sends to the mobile access 1447 gateway. 1449 2. An implementation MUST support Sequence Number based scheme, as 1450 per [RFC-3775]. 1452 5.6. Routing Considerations 1454 5.6.1. Bi-Directional Tunnel Management 1456 o A bi-directional tunnel MUST be established between the local 1457 mobility anchor and the mobile access gateway with IP-in-IP 1458 encapsulation, as described in [RFC-2473]. The tunnel end points 1459 are the Proxy-CoA and LMAA. When using IPv4 transport with a 1460 specific encapsulation mode, the end points of the tunnel are the 1461 IPv4-LMAA and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. 1463 o The bi-directional tunnel MUST be used for routing the mobile 1464 node's data traffic between the mobile access gateway and the 1465 local mobility anchor. The tunnel hides the topology and enables 1466 a mobile node to use an address from its home network prefix from 1467 any access link attached to the mobile access gateway. 1469 o The bi-directional tunnel is established after accepting the Proxy 1470 Binding Update request message. The created tunnel may be shared 1471 with other mobile nodes attached to the same mobile access gateway 1472 and with the local mobility anchor having a Binding Cache entry 1473 for those mobile nodes. Implementations MAY choose to use static 1474 tunnels instead of dynamically creating and tearing them down on a 1475 need basis. 1477 o Implementations MAY use a software timer for managing the tunnel 1478 lifetime and a counter for keeping a count of all the mobile nodes 1479 that are sharing the tunnel. The timer value MUST be set to the 1480 accepted binding lifetime and will be updated after each periodic 1481 re-registration for extending the lifetime. If the tunnel is 1482 shared for multiple mobile nodes, the tunnel lifetime MUST be set 1483 to the highest binding lifetime that is granted to any one of 1484 those mobile nodes sharing that tunnel. 1486 5.6.2. Forwarding Considerations 1488 Intercepting Packets Sent to the Mobile Node's Home Network: 1490 o When the local mobility anchor is serving a mobile node, it MUST 1491 be able to receive packets that are sent to the mobile node's home 1492 network. In order for it to receive those packets, it MUST 1493 advertise a connected route in to the Routing Infrastructure for 1494 the mobile node's home network prefix or for an aggregated prefix 1495 with a larger scope. This essentially enables IPv6 routers in 1496 that network to detect the local mobility anchor as the last-hop 1497 router for that prefix. 1499 Forwarding Packets to the Mobile Node: 1501 o On receiving a packet from a correspondent node with the 1502 destination address matching a mobile node's home network prefix, 1503 the local mobility anchor MUST forward the packet through the bi- 1504 directional tunnel setup for that mobile node. The format of the 1505 tunneled packet is shown below. However, when using IPv4 1506 transport, the format of the packet is as described in [ID-IPV4- 1507 PMIP6]. 1509 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1510 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1511 Upper layer protocols /* Packet Content*/ 1513 Figure 10: Tunneled Packets from LMA to MAG 1515 Forwarding Packets Sent by the Mobile Node: 1517 o All the reverse tunneled packets that the local mobility anchor 1518 receives from the mobile access gateway, after removing the tunnel 1519 header MUST be routed to the destination specified in the inner 1520 packet header. These routed packets will have the source address 1521 field set to the mobile node's home address. 1523 5.7. Local Mobility Anchor Address Discovery 1525 Dynamic Home Agent Address Discovery, as explained in Section 10.5 1526 [RFC-3775], allows a mobile node to discover all the home agents on 1527 its home link by sending an ICMP Home Agent Address Discovery Request 1528 message to the Mobile IPv6 Home-Agents anycast address, derived from 1529 its home network prefix. 1531 The DHAAD message in the current form cannot be used in Proxy Mobile 1532 IPv6 for discovering the address of the mobile node's local mobility 1533 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1534 able to receive any messages sent to the Mobile IPv6 Home-Agents 1535 anycast address corresponding to the mobile node's home network 1536 prefix, as the prefix is not hosted on any of its interfaces. 1537 Further, the mobile access gateway will not predictably be able to 1538 locate the serving local mobility anchor that has the mobile node's 1539 binding cache entry. Hence, this specification does not support 1540 Dynamic Home Agent Address Discovery protocol. 1542 In Proxy Mobile IPv6, the address of the local mobility anchor 1543 configured to serve a mobile node can be discovered by the mobility 1544 entities in other ways. This may be a configured entry in the mobile 1545 node's policy profile, or it may be obtained through mechanisms 1546 outside the scope of this document. 1548 5.8. Mobile Prefix Discovery Considerations 1550 This specification does not support mobile prefix discovery. The 1551 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1552 applicable to Proxy Mobile IPv6. 1554 5.9. Route Optimizations Considerations 1556 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1557 enables a mobile node to communicate with a correspondent node 1558 directly using its care-of address and further the Return Routability 1559 procedure enables the correspondent node to have reasonable trust 1560 that the mobile node is reachable at both its home address and 1561 care-of address. 1563 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1564 mobility related signaling. The mobile node uses only its home 1565 address for all its communication and the Care-of address (Proxy-CoA) 1566 is not visible to the mobile node. Hence, the Return Routability 1567 procedure as defined in Mobile IPv6 [RFC-3775] cannot be used in 1568 Proxy Mobile IPv6. 1570 6. Mobile Access Gateway Operation 1572 The Proxy Mobile IPv6 protocol described in this document introduces 1573 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1574 access gateway is the entity that is responsible for detecting the 1575 mobile node's movements to and from the access link and sending the 1576 binding registration requests to the local mobility anchor. In 1577 essence, the mobile access gateway performs mobility management on 1578 behalf of a mobile node. 1580 The mobile access gateway is a function that typically runs on an 1581 access router. However, implementations MAY choose to split this 1582 function and run it across multiple systems. The specifics on how 1583 that is achieved or the signaling interactions between those 1584 functional entities are beyond the scope of this document. 1586 The mobile access gateway has the following key functional roles: 1588 o It is responsible for detecting the mobile node's movements on the 1589 access link and for initiating the mobility signaling with the 1590 mobile node's local mobility anchor. 1592 o Emulation of the mobile node's home link on the access link by 1593 sending Router Advertisements with the mobile node's home network 1594 prefix information. 1596 o Responsible for setting up the data path for enabling the mobile 1597 node to configure an address from its home network prefix and use 1598 it from its access link. 1600 6.1. Extensions to Binding Update List Entry Data Structure 1602 Every mobile access gateway MUST maintain a Binding Update List. 1603 Each entry in the Binding Update List represents a mobile node's 1604 mobility binding with its local mobility anchor. The Binding Update 1605 List is a conceptual data structure, described in Section 11.1 [RFC- 1606 3775]. 1608 For supporting this specification, the conceptual Binding Update List 1609 entry data structure needs be extended with the following additional 1610 fields. 1612 o The Identifier of the attached mobile node, MN-Identifier. This 1613 identifier is acquired during the mobile node's attachment to the 1614 access link through mechanisms outside the scope of this document. 1616 o The interface identifier of the mobile node's connected interface. 1617 This address can be acquired from the received Router Solicitation 1618 messages from the mobile node or during the mobile node's 1619 attachment to the access network. This is typically a Layer-2 1620 identifier conveyed by the mobile node; however, the specific 1621 details on how that is conveyed is out of scope for this 1622 specification. If this identifier is not available, the value 1623 MUST be set to ALL_ZERO. 1625 o The IPv6 home network prefix of the attached mobile node. The 1626 home network prefix of the mobile node is acquired from the mobile 1627 node's local mobility anchor through the received Proxy Binding 1628 Acknowledgement messages. The IPv6 home network prefix also 1629 includes the corresponding prefix length. 1631 o The Link-local address of the mobile node on the interface 1632 attached to the access link. 1634 o The IPv6 address of the local mobility anchor serving the attached 1635 mobile node. This address is acquired from the mobile node's 1636 policy profile or from other means. 1638 o The interface identifier (If-Id) of the access link where the 1639 mobile node is currently attached. This is internal to the mobile 1640 access gateway and is used to associate the Proxy Mobile IPv6 1641 tunnel to the access link where the mobile node is attached. 1643 o The interface identifier (If-Id) of the bi-directional tunnel 1644 between the mobile node's local mobility anchor and the mobile 1645 access gateway. This is internal to the mobile access gateway. 1646 The tunnel interface identifier is acquired during the tunnel 1647 creation. 1649 6.2. Mobile Node's Policy Profile 1651 A mobile node's policy profile contains the essential operational 1652 parameters that are required by the network entities for managing the 1653 mobile node's mobility service. These policy profiles are stored in 1654 a local or a remote policy store. The mobile access gateway and the 1655 local mobility anchor MUST be able to obtain a mobile node's policy 1656 profile. The policy profile MAY also be handed over to a serving 1657 mobile access gateway as part of a context transfer procedure during 1658 a handoff or the serving mobile access gateway MAY be able to 1659 dynamically generate this profile. The exact details on how this 1660 achieved is outside the scope of this document. However, this 1661 specification requires that a mobile access gateway serving a mobile 1662 node MUST have access to its policy profile. 1664 The following are the mandatory fields of the policy profile: 1666 o The mobile node's identifier (MN-Identifier) 1668 o The IPv6 address of the local mobility anchor (LMAA) 1670 The following are the optional fields of the policy profile: 1672 o The mobile node's IPv6 home network prefix (MN-HNP) 1674 o The mobile node's IPv6 home network Prefix lifetime 1676 o Supported address configuration procedures (Stateful, Stateless or 1677 both) for the mobile node in the Proxy Mobile IPv6 domain 1679 6.3. Supported Access Link Types 1681 This specification supports only point-to-point access link types and 1682 thus it assumes that the mobile node and the mobile access gateway 1683 are the only two nodes on the access link. The link is assumed to 1684 have multicast capability. This protocol may also be used on other 1685 link types, as long as the link is configured in such a way that it 1686 guarantees a point-to-point delivery between the mobile node and the 1687 mobile access gateway for all the protocol traffic. 1689 6.4. Supported Address Configuration Modes 1691 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1692 more IPv6 addresses on its interface using Stateless or Stateful 1693 address autoconfiguration procedures. The Router Advertisement 1694 messages sent on the access link specify the address configuration 1695 methods permitted on that access link for that mobile node. However, 1696 the advertised flags with respect to the address configuration will 1697 be consistent for a mobile node, on any of the access links in that 1698 Proxy Mobile IPv6 domain. Typically, these configuration settings 1699 will be based on the domain wide policy or based on a policy specific 1700 to each mobile node. 1702 When stateless address autoconfiguration is supported on the access 1703 link, the mobile node can generate one or more IPv6 addresses by 1704 standard IPv6 mechanisms such as Stateless Autoconfiguration 1705 specification [RFC-4862] or Privacy extension specification [RFC- 1706 4941]. 1708 When stateful address autoconfiguration is supported on the link, the 1709 mobile node can obtain the address configuration from the DHCPv6 1710 server by standard DHCPv6 mechanisms, as specified in DHCPv6 1711 specification [RFC-3315]. 1713 Additionally, other address configuration mechanisms specific to the 1714 access link between the mobile node and the mobile access gateway may 1715 also be used for pushing the address configuration to the mobile 1716 node. This specification does not change the behavior of address 1717 configuration mechanisms in any way. 1719 6.5. Access Authentication & Mobile Node Identification 1721 When a mobile node attaches to an access link connected to the mobile 1722 access gateway, the deployed access security protocols on that link 1723 SHOULD ensure that the network-based mobility management service is 1724 offered only after authenticating and authorizing the mobile node for 1725 that service. The exact specifics on how this is achieved or the 1726 interactions between the mobile access gateway and the access 1727 security service is outside the scope of this document. This 1728 specification goes with the stated assumption of having an 1729 established trust between the mobile node and the mobile access 1730 gateway, before the protocol operation begins. 1732 6.6. Acquiring Mobile Node's Identifier 1734 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1735 to identify a mobile node, using its MN-Identifier. This identifier 1736 MUST be stable across the Proxy Mobile IPv6 domain and the entities 1737 must be able to use this identifier in the signaling messages. 1738 Typically, this identifier is obtained as part of the access 1739 authentication or through other means as specified below. 1741 o The identifier of the mobile node that the mobile access gateway 1742 obtains typically as part of the access authentication or from the 1743 notified network attachment event, can be a temporary identifier 1744 and further that temporary identifier may be different at each re- 1745 authentication. The mobile access gateway MUST be able to use 1746 this temporary identifier and obtain the mobile node's stable 1747 identifier from the policy store. For instance, in AAA-based 1748 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1749 4372] may be used. 1751 o The MN-Identifier that the policy store delivers to the mobile 1752 access gateway may not be the true identifier of the mobile node. 1753 However, the mobility access gateway MUST be able to use this 1754 identifier in the signaling messages exchanged with the local 1755 mobility anchor. 1757 o The mobile access gateway MUST be able to identify the mobile node 1758 by its MN-Identifier and it MUST be able to associate this 1759 identity to the point-to-point link shared with the mobile node. 1761 6.7. Home Network Emulation 1763 One of the key functions of a mobile access gateway is to emulate the 1764 mobile node's home network on the access link. It must ensure, the 1765 mobile node believes it is still connected to its home link or on the 1766 link where it obtained its initial address configuration after it 1767 moved into that Proxy Mobile IPv6 domain. 1769 For emulating the mobile node's home link on the access link, the 1770 mobile access gateway must be able to send Router Advertisements 1771 advertising the mobile node's home network prefix and other address 1772 configuration parameters consistent with its home link properties. 1773 Typically, these configuration settings will be based on the domain 1774 wide policy or based on a policy specific to each mobile node. 1776 Typically, the mobile access gateway learns the mobile node's home 1777 network prefix information from the received Proxy Binding 1778 Acknowledgement message or it may be obtained from the mobile node's 1779 policy profile. However, the mobile access gateway SHOULD send the 1780 Router Advertisements advertising the mobile node's home network 1781 prefix only after successfully completing the binding registration 1782 with the mobile node's local mobility anchor. 1784 When advertising the home network prefix in the Router Advertisement 1785 messages, the mobile access gateway MAY set the prefix lifetime value 1786 for the advertised prefix to any chosen value at its own discretion. 1787 An implementation MAY choose to tie the prefix lifetime to the mobile 1788 node's binding lifetime. The prefix lifetime can also be an optional 1789 configuration parameter in the mobile node's policy profile. 1791 6.8. Link-Local and Global Address Uniqueness 1793 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1794 mobile access gateway to the other, will continue to detect its home 1795 network and thus making it believe it is still on the same link. 1796 Every time the mobile node attaches to a new link, the event related 1797 to the interface state change will trigger the mobile node to perform 1798 DAD operation on the link-local and global addresses. However, if 1799 the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may 1800 not detect the link change due to DNAv6 optimizations and may not 1801 trigger the duplicate address detection (DAD) procedure for 1802 establishing the link-local address uniqueness on that new link. 1803 This leaves a room for link-local address collision between the two 1804 neighbors on that access link. 1806 For solving this problem, this specification allows the mobile access 1807 gateway to upload the mobile node's link-local address to the local 1808 mobility anchor using the Link-local Address option, exchanged in the 1809 binding registration messages. The mobile access gateway can learn 1810 the mobile node's link-local address, by snooping the DAD messages 1811 sent by the mobile node for establishing the link-local address 1812 uniqueness on the access link. Subsequently, at each handoff, the 1813 mobile access gateway can obtain this address from the local mobility 1814 anchor to ensure link-local address uniqueness and change its own 1815 link-local address, if it detects a collision. 1817 Alternatively, one of the workarounds for this issue is to set the 1818 DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 1819 will force the mobile node to redo DAD operation on the global and 1820 link-local addresses every time the interface detects an handoff, 1821 even when DNAv6 does not detect a link change. 1823 However, this issue may not impact point-to-point links based on PPP. 1824 Each time the mobile node moves and attaches to a new mobile access 1825 gateway, the PPP session [RFC-1661] can be re-established, or if 1826 there are context transfer procedures in place, the entire PPP 1827 session can be moved to the new link and the link-local addresses of 1828 both the peers will continue to remain the same. In either of these 1829 approaches, the link-local address uniqueness on the link is assured. 1830 The specific details of how the PPP session is re-established without 1831 impacting any layer-3 sessions or how the PPP session can be moved 1832 between the mobile access gateways is outside the scope of this 1833 document. 1835 The issue of address collision is not relevant to the mobile node's 1836 global address. Since there is a unique home network prefix assigned 1837 for each mobile node, the uniqueness for the mobile node's global 1838 address is assured on the access link. 1840 6.9. Signaling Considerations 1842 6.9.1. Binding Registrations 1844 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 1846 1. After detecting a new mobile node on its access link, the mobile 1847 access gateway MUST identify the mobile node and acquire its MN- 1848 Identifier. If it determines that the network-based mobility 1849 management service needs to be offered to the mobile node, it 1850 MUST send a Proxy Binding Update message to the local mobility 1851 anchor. 1853 2. The Proxy Binding Update message MUST include the Mobile Node 1854 Identifier option [RFC-4283], carrying the MN-Identifier for 1855 identifying the mobile node. 1857 3. The Home Network Prefix option MUST be present in the Proxy 1858 Binding Update message. If the mobile access gateway learns the 1859 mobile node's home network prefix either from its policy store 1860 or from other means, the mobile access gateway MAY choose to 1861 specify the same in the Home Network Prefix option for 1862 requesting the local mobility anchor to allocate that prefix, 1863 otherwise it MUST specify a value of ALL_ZERO. If the specified 1864 value is ALL_ZERO, then the local mobility anchor will do the 1865 prefix assignment. 1867 4. The Handoff Indicator option MUST be present in the Proxy 1868 Binding Update message. The Handoff Indicator field in the 1869 Handoff Indicator option MUST be set to a value indicating the 1870 handoff hint. 1872 * The Handoff Indicator field MUST be set to value 1 1873 (Attachment over a new interface), if the mobile access 1874 gateway predictably knows that the mobile node's current 1875 attachment to the network over this interface is not as a 1876 result of an handoff of an existing mobility session (over 1877 the same interface or through a different interface), but as 1878 a result of an attachment over a new interface. This 1879 essentially serves as a request to the local mobility anchor 1880 to create a new mobility session and not update any existing 1881 Binding Cache entry created for the same mobile node 1882 connected to the Proxy Mobile IPv6 domain through a different 1883 interface. 1885 * The Handoff Indicator field MUST be set to value 2 (Handoff 1886 between two different interfaces of the mobile node), if the 1887 mobile access gateway definitively knows the mobile node's 1888 current attachment is due to an handoff of an existing 1889 mobility session, between two different interfaces of the 1890 mobile node. 1892 * The Handoff Indicator field MUST be set to value 3 (Handoff 1893 between mobile access gateways for the same interface), if 1894 the mobile access gateway definitively knows the mobile 1895 node's current attachment is due to an handoff of an existing 1896 mobility session between two mobile access gateways and for 1897 the same interface of the mobile node. 1899 * The Handoff Indicator field MUST be set to value 4 (Handoff 1900 state unknown), if the mobile access gateway cannot determine 1901 if the mobile node's current attachment is due to an handoff 1902 of an existing mobility session. 1904 5. The mobile access gateway MUST apply the below considerations 1905 when choosing the value for the Handoff Indicator field. 1907 * The mobile access gateway can choose to use the value 2 1908 (Handoff between two different interfaces of the mobile 1909 node), only when it knows that the mobile node has on purpose 1910 switched from one interface to another, and the previous 1911 interface is going to be disabled. It may know this due to a 1912 number of factors. For instance, most cellular networks have 1913 controlled handovers where the network knows that the host is 1914 moving from one attachment to another. In this situation the 1915 link layer mechanism can inform the mobility functions that 1916 this is indeed a movement, not a new attachment. 1918 * Some link layers have interface identifiers that can be used 1919 to distinguish (a) the movement of a particular interface to 1920 a new attachment from (b) the attachment of new interface 1921 from the same host. Option value 3 (Handoff between mobile 1922 access gateways for the same interface)is appropriate in case 1923 a and value of 1 (Attachment over a new interface) in case b. 1925 * The mobile access gateway MUST NOT set the option value to 2 1926 (Handoff between two different interfaces of the mobile node) 1927 or 3 (Handoff between mobile access gateways for the same 1928 interface) if it can not be determined that the mobile node 1929 can move the address between the interfaces involved in the 1930 handover or that it is the same interface that has moved. 1931 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 1932 physical interfaces to the same domain may suffer unexpected 1933 failures. 1935 * Where no support from link-layer exists, the host and the 1936 network would need to inform each other about the intended 1937 movement. Proxy Mobile IPv6 protocol does not specify this 1938 and simply requires that knowledge about movements can be 1939 derived either from the link-layer or from somewhere else. 1940 The method by which this is accomplished is outside the scope 1941 of this specification. 1943 6. Either the Timestamp option or a valid sequence number 1944 maintained on a per mobile node basis (if Sequence Number based 1945 scheme is in use) MUST be present. When Timestamp option is 1946 added to the message, the mobile access gateway SHOULD also set 1947 the Sequence Number field to a value of a monotonically 1948 increasing counter (not to be confused with the per mobile node 1949 sequence number specified [RFC-3775]). The local mobility 1950 anchor will ignore this field when there is a Timestamp option 1951 present in the request, but will return the same value in the 1952 Proxy Binding Acknowledgement message. This will be useful for 1953 matching the reply to the request message. 1955 7. The Mobile Node Interface Identifier option carrying the 1956 interface identifier of the currently attached interface MUST be 1957 present in the Proxy Binding Update message, if the mobile 1958 access gateway knows the interface identifier of the mobile 1959 node's currently attached interface. If the interface 1960 identifier is not known or if the identifier value is ALL_ZERO, 1961 this option MUST NOT be present. 1963 8. The Access Technology Type option MUST be present in the Proxy 1964 Binding Update message. The access technology type field in the 1965 option SHOULD be set to the type of access technology using 1966 which the mobile node is currently attached to the mobile access 1967 gateway. 1969 9. The Link-local Address option MAY be present in the Proxy 1970 Binding Update message. Considerations from Section 6.8 MUST be 1971 applied when using the link-local address option. 1973 * When uploading the link-local address to the local mobility 1974 anchor, the value in the option MUST be set to the link-local 1975 address that is configured on the currently attached 1976 interface of the mobile node. 1978 * When querying the local mobility anchor for the mobile node's 1979 link-local address, the option MUST be set to ALL_ZERO value. 1980 This essentially serves as a request to the local mobility 1981 anchor to return the link-local address of the mobile node 1982 from the binding cache entry corresponding to this mobility 1983 session. 1985 10. The Proxy Binding Update message MUST be constructed as 1986 specified in Section 6.9.1.5. 1988 11. If there is no existing Binding Update List entry for that 1989 mobile node, the mobile access gateway MUST create a Binding 1990 Update List entry for the mobile node upon sending the Proxy 1991 Binding Update request. 1993 6.9.1.2. Receiving Binding Registration Reply 1995 On receiving a Proxy Binding Acknowledgement message from the local 1996 mobility anchor, the mobile access gateway MUST process the message 1997 as specified below. 1999 1. The received Proxy Binding Acknowledgement message (a Binding 2000 Acknowledgement message with the 'P' flag set) MUST be 2001 authenticated as described in Section 4. When IPsec is used for 2002 message authentication, the SPI in the IPsec header [RFC-4306] 2003 of the received packet is needed for locating the security 2004 association, for authenticating the Proxy Binding 2005 Acknowledgement message . 2007 2. The mobile access gateway MUST observe the rules described in 2008 Section 9.2 [RFC-3775] when processing Mobility Headers in the 2009 received Proxy Binding Acknowledgement message. 2011 3. The mobile access gateway MUST apply the considerations 2012 specified in Section 5.5 for processing the Sequence Number 2013 field and the Timestamp option (if present), in the message. 2015 4. The mobile access gateway MUST ignore any checks, specified in 2016 [RFC-3775] related to the presence of Type 2 Routing header in 2017 the Proxy Binding Acknowledgement message. 2019 5. The mobile access gateway MAY use the mobile node identifier 2020 present in the Mobile Node Identifier option for matching the 2021 response to the request messages that it sent recently . 2022 However, if there are more than one request message in its 2023 request queue for the same mobile node, the sequence number 2024 field can be used for identifying the exact message from those 2025 messages. There are other ways to achieve this and 2026 implementations are free to adopt the best approach that suits 2027 their implementation. Additionally, if the received Proxy 2028 Binding Acknowledgement message does not match any of the Proxy 2029 Binding Update messages that it sent recently, the message MUST 2030 be ignored. 2032 6. If the received Proxy Binding Acknowledgement message has any 2033 one or more of the following options, Handoff Indicator option, 2034 Access Technology Type option, Mobile Node Interface Identifier 2035 option, Mobile Node Identifier option, carrying option values 2036 that are different from the option values present in the 2037 corresponding request (Proxy Binding Update) message, the 2038 message MUST be ignored as the local mobility anchor is expected 2039 to echo back all these listed options and with the same option 2040 values in the reply message. Further, the mobile access gateway 2041 MUST NOT retransmit the Proxy Binding Update message till an 2042 administrative action is taken. 2044 7. If the received Proxy Binding Acknowledgement message has the 2045 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2046 registration not enabled for the mobile node), the mobile access 2047 gateway SHOULD NOT send binding registration requests again for 2048 that mobile node. It MUST deny the mobility service to that 2049 mobile node. 2051 8. If the received Proxy Binding Acknowledgement message has the 2052 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2053 (Timestamp value lower than previously accepted value), the 2054 mobile access gateway SHOULD try to register again to reassert 2055 the mobile node's presence on its access link. The mobile 2056 access gateway is not specifically required to synchronize its 2057 clock upon receiving this error code. 2059 9. If the received Proxy Binding Acknowledgement message has the 2060 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2061 value), the mobile access gateway SHOULD try to register again 2062 only after it has synchronized its clock to a common time source 2063 that is used by all the mobility entities in that domain for 2064 their clock synchronization. The mobile access gateway SHOULD 2065 NOT synchronize its clock to the local mobility anchor's system 2066 clock, based on the timestamp present in the received message. 2068 10. If the received Proxy Binding Acknowledgement message has the 2069 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2070 (mobile node is not authorized for the requesting home network 2071 prefix), the mobile access gateway SHOULD NOT request for the 2072 same prefix again, but can request the local mobility anchor to 2073 dynamically assign a prefix, by specifying a ALL_ZERO value in 2074 the Home Network Prefix option carried in the subsequent Proxy 2075 Binding Update message. 2077 11. If the received Proxy Binding Acknowledgement message has the 2078 Status field value set to any value greater than or equal to 128 2079 (i.e., if the binding is rejected), the mobile access gateway 2080 MUST NOT advertise the mobile node's home network prefix in the 2081 Router Advertisements sent on that access link and there by 2082 denying mobility service to the mobile node. 2084 12. If the received Proxy Binding Acknowledgement message has the 2085 Status field value set to 0 (Proxy Binding Update accepted), the 2086 mobile access gateway MUST update the routing state, as 2087 explained in section 6.10, and MUST also update the Binding 2088 Update List entry for reflecting the accepted binding 2089 registration status. 2091 13. If the received Proxy Binding Acknowledgement message has the 2092 address in the Link-local Address option set to a value that 2093 matches its own link-local address on that access interface 2094 where the mobile node is anchored, the mobile access gateway 2095 MUST change its link-local address on that interface, to avoid 2096 link-local address collision on that access link. 2098 6.9.1.3. Extending Binding Lifetime 2100 1. For extending the lifetime of a currently registered mobile node 2101 (i.e., after a successful initial binding registration from the 2102 same mobile access gateway), the mobile access gateway can send a 2103 Proxy Binding Update message to the local mobility anchor with a 2104 new lifetime value. This re-registration message MUST be 2105 constructed with the same set of options as the initial binding 2106 registration message, under the considerations specified in 2107 Section 6.9.1.1. However the following exceptions apply. 2109 2. The prefix value in the Home Network Prefix option MUST be set to 2110 the currently assigned home network prefix. 2112 3. The Handoff Indicator field in the Handoff Indicator option MUST 2113 be set to a value of 5 (Handoff state not changed - Re- 2114 Registration). 2116 4. The value in the Link-local Address option (if the option was 2117 present in the initial registration message) MUST be set to the 2118 link-local address of the mobile node's attached interface. 2120 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2122 1. At any point, the mobile access gateway detects that the mobile 2123 node has moved away from its access link, or if it decides to 2124 terminate the mobile node's mobility session, it SHOULD send a 2125 Proxy Binding Update message to the local mobility anchor with 2126 the lifetime value set to zero. This de-registration message 2127 MUST be constructed with the same set of options as the initial 2128 binding registration message, under the considerations specified 2129 in Section 6.9.1.1. However, the following exceptions apply. 2131 2. The prefix value in the Home Network Prefix option MUST be set to 2132 the currently assigned home network prefix. 2134 3. The Handoff Indicator field in the Handoff Indicator option MUST 2135 be set to a value of 4 (Handoff state unknown). 2137 4. The value in the Link-local Address option (if the option was 2138 present in the initial registration message) MUST be set to the 2139 link-local address of the mobile node's attached interface. 2141 Either upon receipt of a Proxy Binding Acknowledgement message from 2142 the local mobility anchor or after INITIAL_BINDINGACK_TIMEOUT [RFC- 2143 3775] timeout waiting for the reply, the mobile access gateway MUST 2144 do the following: 2146 1. It MUST remove the Binding Update List entry for the mobile node 2147 from its Binding Update List. 2149 2. It MUST withdraw the mobile node's home network prefix as the 2150 hosted on-link prefix, by sending a Router Advertisement message 2151 with the prefix lifetime value set to zero. 2153 3. It MUST remove the created routing state for tunneling the mobile 2154 node's traffic. 2156 4. It SHOULD teardown the point-to-point link shared with the mobile 2157 node. This action will force the mobile node to remove any IPv6 2158 address configuration on the interface connected to this point- 2159 to-point link. 2161 6.9.1.5. Constructing the Proxy Binding Update Message 2163 o The mobile access gateway when sending the Proxy Binding Update 2164 request to the local mobility anchor MUST construct the message as 2165 specified below. 2167 IPv6 header (src=Proxy-CoA, dst=LMAA) 2168 Mobility header 2169 - BU /* P & A flags MUST be set */ 2170 Mobility Options 2171 - Mobile Node Identifier option (mandatory) 2172 - Home Network Prefix option (mandatory) 2173 - Handoff Indicator option (mandatory) 2174 - Access Technology Type option (mandatory) 2175 - Timestamp option (optional) 2176 - Mobile Node Interface Identifier option (optional) 2177 - Link-local Address option (optional) 2179 Figure 11: Proxy Binding Update message format 2181 o The Source Address field in the IPv6 header of the message MUST be 2182 set to the address configured on the interface of the mobile 2183 access gateway. When there is no Alternate Care-of Address option 2184 present in the request, this address will be considered as the 2185 Proxy-CoA address for this binding registration request. However, 2186 when there is Alternate Care-of Address option present in the 2187 request, this address will be not be the considered as the Proxy- 2188 CoA address, but the address in the alternate Care-of Address 2189 option will be considered as the Proxy-CoA address. 2191 o The Destination Address field in the IPv6 header of the message 2192 MUST be set to the local mobility anchor address. 2194 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2196 o The Home Network Prefix option MUST be present. 2198 o The Handoff Indicator option MUST be present. 2200 o The Access Technology Type option MUST be present. 2202 o The Timestamp option MAY be present. 2204 o The Mobile Node Interface Identifier option MAY be present. 2206 o The Link-local Address option MAY be present. 2208 o If IPsec is used for protecting the signaling messages, the 2209 message MUST be protected, using the security association existing 2210 between the local mobility anchor and the mobile access gateway. 2212 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2213 3775] MUST NOT be present in the IPv6 Destination Options 2214 extension header of the Proxy Binding Update message. 2216 6.9.2. Router Solicitation Messages 2218 The mobile node may send a Router Solicitation message on the access 2219 link whenever the link-layer detects a media change. The Source 2220 Address in the IPv6 header of the Router Solicitation message may 2221 either be the link-local address of the mobile node or an unspecified 2222 address (::). The Router Solicitation message that the mobile node 2223 sends is as specified in [RFC-4861]. 2225 1. The mobile access gateway on receiving the Router Solicitation 2226 message SHOULD send a Router Advertisement containing the mobile 2227 node's home network prefix as the on-link prefix. However, 2228 before sending the Router Advertisement message containing the 2229 mobile node's home network prefix, it SHOULD complete the binding 2230 registration process with the mobile node's local mobility 2231 anchor. 2233 2. If the local mobility anchor rejects the binding registration 2234 request, or, if the mobile access gateway failed to complete the 2235 binding registration process for whatever reasons, the mobile 2236 access gateway MUST NOT advertise the mobile node's home network 2237 prefix in the Router Advertisement messages that it sends on the 2238 access link. However, it MAY choose to advertise a local visited 2239 network prefix to enable the mobile node for regular IPv6 access. 2241 6.9.3. Default-Router Lifetime 2243 In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6 2244 default-router for the mobile node on the access link, as it is the 2245 entity that sends the Router Advertisements on the access link. 2246 However, as the mobile node moves from one access link to another, 2247 the serving mobile access gateway on those respective links will send 2248 the Router Advertisements and using their own link-local address. 2249 The mobile node on each of the attached links will receive Router 2250 Advertisement messages with a different source address and this makes 2251 the mobile node believe that there is a new default-router on that 2252 access link. 2254 The mobile node will certainly detect the previous default-router 2255 loss by performing the Neighbor Unreachability Detection procedure 2256 per the standard IPv6 ND mechanisms, but it is important that the 2257 mobile access gateway enables the mobile node to withdraw the 2258 previous default-router entry at the earliest. This action will help 2259 in minimizing packet losses during a hand off switch. Following are 2260 some considerations that implementations can apply. 2262 The Router Lifetime field in the Router Advertisement messages that 2263 the mobile access gateway sends on the access link SHOULD be kept to 2264 low. 2266 In access networks where SEND [RFC-3971] is not deployed, the mobile 2267 access gateway can withdraw the previous default-router entry, by 2268 sending a Router Advertisement using the link-local address that of 2269 the previous mobile access gateway and with the Router Lifetime field 2270 set to value zero, then this will force the flush of the previous 2271 default-router entry from the mobile node's cache, as specified in 2272 Section 6.3.5 [RFC-4861]. However, this approach requires the 2273 serving mobile access gateway to learn the link-local address of the 2274 previous mobile access gateway where the mobile node was handed off. 2276 There are other solutions possible for this problem, including the 2277 assignment of a fixed link-local address for all the mobility 2278 entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is 2279 not deployed. In such scenario, the mobile node is not required to 2280 update the default-router entry. However, this is an implementation 2281 choice and has no bearing on the protocol interoperability. 2282 Implementations are free to adopt the best approach that suits their 2283 target deployments. 2285 6.9.4. Retransmissions and Rate Limiting 2287 The mobile access gateway is responsible for retransmissions and rate 2288 limiting the binding registration requests that it sends to the local 2289 mobility anchor. The Retransmission and the Rate Limiting rules are 2290 as specified in [RFC-3775]. However, the following considerations 2291 MUST be applied. 2293 1. When the mobile access gateway sends a Proxy Binding Update 2294 request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT 2295 [RFC-3775], for configuring the retransmission timer, as 2296 specified in Section 11.8 [RFC-3775]. However, the mobile access 2297 gateway is not required to use a longer retransmission interval 2298 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2299 the initial binding registration request. 2301 2. If the mobile access gateway fails to receive a valid matching 2302 response for a registration or re-registration message within the 2303 retransmission interval, it SHOULD retransmit the message until a 2304 response is received. However, the mobile access gateway MUST 2305 ensure the mobile node is still attached to the connected link 2306 before retransmitting the message. 2308 3. As specified in Section 11.8 [RFC-3775], the mobile access 2309 gateway MUST use an exponential back-off process in which the 2310 timeout period is doubled upon each retransmission, until either 2311 the node receives a response or the timeout period reaches the 2312 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2313 MAY continue to send these messages at this slower rate 2314 indefinitely. 2316 4. If Timestamp based scheme is in use, the retransmitted Proxy 2317 Binding Update messages MUST use the latest timestamp. If 2318 Sequence number scheme is in use, the retransmitted Proxy Binding 2319 Update messages MUST use a Sequence Number value greater than 2320 that used for the previous transmission of this Proxy Binding 2321 Update message, just as specified in [RFC-3775]. 2323 6.10. Routing Considerations 2325 This section describes how the mobile access gateway handles the 2326 traffic to/from the mobile node that is attached to one of its access 2327 interface. 2329 Proxy-CoA LMAA 2330 | | 2331 +--+ +---+ +---+ +--+ 2332 |MN|----------|MAG|======================|LMA|----------|CN| 2333 +--+ +---+ +---+ +--+ 2334 IPv6 Tunnel 2336 Figure 12: Proxy Mobile IPv6 Tunnel 2338 6.10.1. Transport Network 2340 The transport network between the local mobility anchor and the 2341 mobile access gateway can be either an IPv6 or IPv4 network. 2342 However, this specification only deals with the IPv6 transport and 2343 the companion document [ID-IPV4-PMIP6] specifies the required 2344 extensions for negotiating IPv4 transport and the corresponding 2345 encapsulation mode for supporting this protocol operation. 2347 6.10.2. Tunneling & Encapsulation Modes 2349 The IPv6 address that a mobile node uses from its home network prefix 2350 is topologically anchored at the local mobility anchor. For a mobile 2351 node to use this address from an access network attached to a mobile 2352 access gateway, proper tunneling techniques have to be in place. 2353 Tunneling hides the network topology and allows the mobile node's 2354 IPv6 datagram to be encapsulated as a payload of another IPv6 packet 2355 and to be routed between the local mobility anchor and the mobile 2356 access gateway. The Mobile IPv6 base specification [RFC-3775] 2357 defines the use of IPv6-over-IPv6 tunneling, between the home agent 2358 and the mobile node and this specification extends the use of the 2359 same tunneling mechanism between the local mobility anchor and the 2360 mobile access gateway. 2362 On most operating systems, tunnels are implemented as a virtual 2363 point-to-point interface. The source and the destination address of 2364 the two end points of this virtual interface along with the 2365 encapsulation mode are specified for this virtual interface. Any 2366 packet that is routed over this interface gets encapsulated with the 2367 outer header and the addresses as specified for that point to point 2368 tunnel interface. For creating a point to point tunnel to any local 2369 mobility anchor, the mobile access gateway may implement a tunnel 2370 interface with the source address field set to its Proxy-CoA address 2371 and the destination address field set to the LMA address. 2373 The following are the supported packet encapsulation modes that can 2374 be used by the mobile access gateway and the local mobility anchor 2375 for routing mobile node's IPv6 datagrams. 2377 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2378 2473]. 2380 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2381 details on how this mode is negotiated is specified in [ID-IPV4- 2382 PMIP6]. 2384 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2385 packet. This mode is specified in [ID-IPV4-PMIP6]. 2387 6.10.3. Local Routing 2389 If there is data traffic between a visiting mobile node and a 2390 correspondent node that is locally attached to an access link 2391 connected to the mobile access gateway, the mobile access gateway MAY 2392 optimize on the delivery efforts by locally routing the packets and 2393 by not reverse tunneling them to the mobile node's local mobility 2394 anchor. The configuration variable, EnableMAGLocalRouting MAY be 2395 used for controlling this aspect. However, in some systems, this may 2396 have an implication on the mobile node's accounting and policy 2397 enforcement as the local mobility anchor is not in the path for that 2398 traffic and it will not be able to apply any traffic policies or do 2399 any accounting for those flows. 2401 This decision of path optimization SHOULD be based on the policy 2402 configured on the mobile access gateway, but enforced by the mobile 2403 node's local mobility anchor. The specific details on how this is 2404 achieved are beyond of the scope of this document. 2406 6.10.4. Tunnel Management 2408 All the considerations mentioned in Section 5.6.1 for the tunnel 2409 management on the local mobility anchor apply for the mobile access 2410 gateway as well. 2412 6.10.5. Forwarding Rules 2414 Forwarding Packets sent to the Mobile Node's Home Network: 2416 o On receiving a packet from the bi-directional tunnel established 2417 with the mobile node's local mobility anchor, the mobile access 2418 gateway MUST use the destination address of the inner packet for 2419 forwarding it on the interface where the destination network 2420 prefix is hosted. The mobile access gateway MUST remove the outer 2421 header before forwarding the packet. If the mobile access gateway 2422 cannot find the connected interface for that destination address, 2423 it MUST silently drop the packet. For reporting an error in such 2424 a scenario, in the form of ICMP control message, the 2425 considerations from Generic Packet Tunneling specification [RFC- 2426 2473] must be applied. 2428 o On receiving a packet from a correspondent node that is locally 2429 connected and which is destined to a mobile node that is on 2430 another locally connected access link, the mobile access gateway 2431 MUST check the configuration variable, EnableMAGLocalRouting, to 2432 ensure the mobile access gateway is allowed to route the packet 2433 directly to the mobile node. If the mobile access gateway is not 2434 allowed to route the packet directly, it MUST route the packet 2435 through the bi-directional tunnel established between itself and 2436 the mobile node's local mobility anchor. Otherwise, it can route 2437 the packet directly to the mobile node. 2439 Forwarding Packets Sent by the Mobile Node: 2441 o On receiving a packet from a mobile node connected to its access 2442 link, the mobile access gateway MUST ensure that there is an 2443 established binding for that mobile node with its local mobility 2444 anchor before forwarding the packet directly to the destination or 2445 before tunneling the packet to the mobile node's local mobility 2446 anchor. 2448 o On receiving a packet from a mobile node connected to its access 2449 link to a destination that is locally connected, the mobile access 2450 gateway MUST check the configuration variable, 2451 EnableMAGLocalRouting, to ensure the mobile access gateway is 2452 allowed to route the packet directly to the destination. If the 2453 mobile access gateway is not allowed to route the packet directly, 2454 it MUST route the packet through the bi-directional tunnel 2455 established between itself and the mobile node's local mobility 2456 anchor. Otherwise, it can route the packet directly to the 2457 destination. 2459 o On receiving a packet from the mobile node connected to its access 2460 link, to a destination that is not directly connected, the packet 2461 MUST be forwarded to the local mobility anchor through the bi- 2462 directional tunnel established between itself and the mobile 2463 node's local mobility anchor. However, the packets that are sent 2464 with the link-local source address MUST NOT be forwarded. The 2465 format of the tunneled packet is shown below. Additionally, when 2466 using IPv4 transport, the format of the tunneled packet is as 2467 described in [ID-IPV4-PMIP6]. 2469 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2470 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2471 Upper layer protocols /* Packet Content*/ 2473 Figure 13: Tunneled Packets from MAG to LMA 2475 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2477 This section explains how Stateful Address Configuration using DHCPv6 2478 can be enabled on the access link attached to a mobile access gateway 2479 and how a mobile node attached to that link can obtain an address 2480 from its home network prefix using DHCPv6. 2482 o For supporting Stateful Address Configuration using DHCPv6, the 2483 DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of 2484 the access links in the Proxy Mobile IPv6 domain. Further, as 2485 specified in Section 20 [RFC-3315], the relay agent should be 2486 configured to use a list of destination addresses, which MAY 2487 include unicast addresses, the All_DHCP_Servers multicast address, 2488 or other addresses selected by the network administrator. 2490 o The DHCPv6 server in the Proxy Mobile IPv6 domain can be 2491 configured with a list of prefix pools (P1, P2, ..., Pn). Each 2492 one of these prefix pools corresponds to a home network prefix 2493 that a local mobility anchor allocates to a mobile node in that 2494 domain. However, the DHCPv6 server will not know the relation 2495 between a given address pool and a mobile node to which the 2496 corresponding prefix is allocated. It just views these pools as 2497 prefixes hosted on different links in that domain. 2499 o When a mobile node sends a DHCPv6 request message, the DHCP relay 2500 agent function on the access link will set the link-address field 2501 in the DHCP message to an address in the mobile node's home 2502 network prefix, so as to provide a prefix hint to the DHCP Server 2503 for the address pool selection. The DHCP server on receiving the 2504 request from the mobile node, will allocate an address from the 2505 prefix pool present in the link-address field of the request. 2507 o Once the mobile node obtains an address and moves to a different 2508 link and sends a DHCP request, the DHCP relay agent on the new 2509 link will set the prefix hint in the DHCP messages to the mobile 2510 node's home network prefix. The DHCP server will identify the 2511 client from the Client-DUID option and present in the request and 2512 will allocate the same address as before. 2514 o The DHCP based address configuration is not recommended for 2515 deployments where the local mobility anchor and the mobile access 2516 gateways are located in different administrative domains. For 2517 this configuration to work, all the mobile access gateways in the 2518 Proxy Mobile IPv6 domain should be able to ensure that the DHCP 2519 requests from a given mobile node anchored on any of the access 2520 links in that domain, will always be handled by the same DHCP 2521 server. 2523 o The DHCP server should be configured to offer low address lease 2524 times. A lease time that is too large prevents the DHCP server 2525 from reclaiming the address even after the local mobility anchor 2526 deletes the mobile node's binding cache entry. 2528 6.12. Home Network Prefix Renumbering 2530 If the mobile node's home network prefix gets renumbered or becomes 2531 invalid during the middle of a mobility session, the mobile access 2532 gateway MUST withdraw the prefix by sending a Router Advertisement on 2533 the access link with zero prefix lifetime for the mobile node's home 2534 network prefix. Also, the local mobility anchor and the mobile 2535 access gateway MUST delete the routing state for that prefix. 2537 However, the specific details on how the local mobility anchor 2538 notifies the mobile access gateway about the mobile node's home 2539 network prefix renumbering are outside the scope of this document. 2541 6.13. Mobile Node Detachment Detection and Resource Cleanup 2543 Before sending a Proxy Binding Update message to the local mobility 2544 anchor for extending the lifetime of a currently existing binding of 2545 a mobile node, the mobile access gateway MUST make sure the mobile 2546 node is still attached to the connected link by using some reliable 2547 method. If the mobile access gateway cannot predictably detect the 2548 presence of the mobile node on the connected link, it MUST NOT 2549 attempt to extend the registration lifetime of the mobile node. 2550 Further, in such scenario, the mobile access gateway SHOULD terminate 2551 the binding of the mobile node by sending a Proxy Binding Update 2552 message to the mobile node's local mobility anchor with lifetime 2553 value set to 0. It MUST also remove any local state such as the 2554 Binding Update List entry created for that mobile node. 2556 The specific detection mechanism of the loss of a visiting mobile 2557 node on the connected link is specific to the access link between the 2558 mobile node and the mobile access gateway and is outside the scope of 2559 this document. Typically, there are various link-layer specific 2560 events specific to each access technology that the mobile access 2561 gateway can depend on for detecting the node loss. In general, the 2562 mobile access gateway can depend on one or more of the following 2563 methods for the detection presence of the mobile node on the 2564 connected link: 2566 o Link-layer event specific to the access technology 2568 o PPP Session termination event on point-to-point link types 2570 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2572 o Notification event from the local mobility anchor 2574 6.14. Allowing network access to other IPv6 nodes 2576 In some Proxy Mobile IPv6 deployments, network operators may want to 2577 provision the mobile access gateway to offer network-based mobility 2578 management service only to some visiting mobile nodes and enable just 2579 regular IP access to some other nodes. This requires the network to 2580 have control on when to enable network-based mobility management 2581 service to a mobile node and when to enable regular IPv6 access. 2582 This specification does not disallow such configuration. 2584 Upon detecting a mobile node on its access link and after policy 2585 considerations, the mobile access gateway MUST determine if network- 2586 based mobility management service should be offered to that mobile 2587 node. If the mobile node is entitled for network-based mobility 2588 management service, then the mobile access gateway must ensure the 2589 mobile node believes it is on its home link, as explained in various 2590 sections of this specification. 2592 If the mobile node is not entitled for the network-based mobility 2593 management service, as determined from the policy considerations, the 2594 mobile access gateway MAY choose to offer regular IPv6 access to the 2595 mobile node and in such scenario the normal IPv6 considerations 2596 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2597 obtain an IPv6 address using normal IPv6 address configuration 2598 procedures. The obtained address must be from a local visitor 2599 network prefix. This essentially ensures that the mobile access 2600 gateway functions as a normal access router to a mobile node attached 2601 to its access link and with out impacting its host-based mobility 2602 protocol operation. 2604 7. Mobile Node Operation 2606 This non-normative section explains the mobile node's operation in a 2607 Proxy Mobile IPv6 domain. 2609 7.1. Moving into a Proxy Mobile IPv6 Domain 2611 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2612 an access network, the mobile access gateway on the access link 2613 detects the attachment of the mobile node and completes the binding 2614 registration with the mobile node's local mobility anchor. If the 2615 binding update operation is successfully performed, the mobile access 2616 gateway will create the required state and setup the data path for 2617 the mobile node's data traffic. 2619 If the mobile node is IPv6 enabled, on attaching to the access link, 2620 it will typically send Router Solicitation message [RFC-4861]. The 2621 mobile access gateway on the access link will respond to the Router 2622 Solicitation message with a Router Advertisement. The Router 2623 Advertisement will have the mobile node's home network prefix, 2624 default-router address and other address configuration parameters. 2626 If the mobile access gateway on the access link, receives a Router 2627 Solicitation message from the mobile node, before it completed the 2628 signaling with the mobile node's local mobility anchor, the mobile 2629 access gateway may not know the mobile node's home network prefix and 2630 may not be able to emulate the mobile node's home link on the access 2631 link. In such scenario, the mobile node may notice a slight delay 2632 before it receives a Router Advertisement message. 2634 If the received Router Advertisement has the Managed Address 2635 Configuration flag set, the mobile node, as it would normally do, 2636 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2637 enabled on that access link will ensure the mobile node will obtain 2638 its IPv6 address as a lease from its home network prefix. 2640 If the received Router Advertisement does not have the Managed 2641 Address Configuration flag set and if the mobile node is allowed to 2642 use an autoconfigured address, the mobile node will be able to obtain 2643 an IPv6 address using an interface identifier generated as per the 2644 Autoconf specification [RFC-4862] or as per the Privacy Extensions 2645 specification [RFC-4941]. 2647 If the mobile node is IPv4 enabled and if the network permits, it 2648 will be able to obtain the IPv4 address configuration as specified in 2649 the companion document [ID-IPV4-PMIP6]. 2651 Once the address configuration is complete, the mobile node can 2652 continue to use this address configuration as long as it is attached 2653 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2655 7.2. Roaming in the Proxy Mobile IPv6 Domain 2657 After obtaining the address configuration in the Proxy Mobile IPv6 2658 domain, as the mobile node moves and changes its point of attachment 2659 from one mobile access gateway to the other, it can still continue to 2660 use the same address configuration. As long as the attached access 2661 network is in the scope of that Proxy Mobile IPv6 domain, the mobile 2662 node will always detect the same link, where it obtained its initial 2663 address configuration. If the mobile node performs DHCP operation, 2664 it will always obtain the same address as before. 2666 However, the mobile node will always detect a new default-router on 2667 each connected link, but still advertising the mobile node's home 2668 network prefix as the on-link prefix and with the other configuration 2669 parameters consistent with its home link properties. 2671 8. Message Formats 2673 This section defines extensions to the Mobile IPv6 [RFC-3775] 2674 protocol messages. 2676 8.1. Proxy Binding Update Message 2678 0 1 2 3 2679 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 2680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2681 | Sequence # | 2682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2683 |A|H|L|K|M|R|P| Reserved | Lifetime | 2684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2685 | | 2686 . . 2687 . Mobility options . 2688 . . 2690 | | 2691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2693 A Binding Update message that is sent by a mobile access gateway to a 2694 local mobility anchor is referred to as the "Proxy Binding Update" 2695 message. A new flag (P) is included in the Binding Update message. 2696 The rest of the Binding Update message format remains the same as 2697 defined in [RFC-3775] and with the additional (R) and (M) flags as 2698 specified in [RFC-3963] and [RFC-4140] respectively. 2700 Proxy Registration Flag (P) 2702 A new flag (P) is included in the Binding Update message to 2703 indicate to the local mobility anchor that the Binding Update 2704 message is a proxy registration. The flag MUST be set to the 2705 value of 1 for proxy registrations and MUST be set to 0 for direct 2706 registrations sent by a mobile node. 2708 Mobility Options 2710 Variable-length field of such length that the complete Mobility 2711 Header is an integer multiple of 8 octets long. This field 2712 contains zero or more TLV-encoded mobility options. The encoding 2713 and format of defined options are described in Section 6.2 [RFC- 2714 3775]. The local mobility anchor MUST ignore and skip any options 2715 which it does not understand. 2717 As per this specification, the following mobility options are 2718 valid in a Proxy Binding Update message: 2720 Mobile Node Identifier option 2722 Home Network Prefix option 2724 Handoff Indicator option 2726 Access Technology Type option 2728 Timestamp option 2730 Mobile Node Interface Identifier option 2732 Link-local Address option 2734 For descriptions of other fields present in this message, refer to 2735 section 6.1.7 [RFC-3775]. 2737 8.2. Proxy Binding Acknowledgement Message 2739 0 1 2 3 2740 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 2741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2742 | Status |K|R|P|Reserved | 2743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2744 | Sequence # | Lifetime | 2745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2746 | | 2747 . . 2748 . Mobility options . 2749 . . 2750 | | 2751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2753 A Binding Acknowledgement message that is sent by a local mobility 2754 anchor to a mobile access gateway is referred to as the "Proxy 2755 Binding Acknowledgement" message. A new flag (P) is included in the 2756 Binding Acknowledgement message. The rest of the Binding 2757 Acknowledgement message format remains the same as defined in [RFC- 2758 3775] and with the additional (R) and (M) flags as specified in [RFC- 2759 3963] and [RFC-4140] respectively. 2761 Proxy Registration Flag (P) 2763 A new flag (P) is included in the Binding Acknowledgement message 2764 to indicate that the local mobility anchor that processed the 2765 corresponding Proxy Binding Update message supports proxy 2766 registrations. The flag is set only if the corresponding Proxy 2767 Binding Update had the Proxy Registration Flag (P) set to value of 2768 1. 2770 Mobility Options 2772 Variable-length field of such length that the complete Mobility 2773 Header is an integer multiple of 8 octets long. This field 2774 contains zero or more TLV-encoded mobility options. The encoding 2775 and format of defined options are described in Section 6.2 [RFC- 2776 3775]. The mobile access gateway MUST ignore and skip any options 2777 which it does not understand. 2779 As per this specification, the following mobility options are 2780 valid in a Proxy Binding Acknowledgement message: 2782 Mobile Node Identifier option 2784 Home Network Prefix option 2786 Handoff Indicator option 2788 Access Technology Type option 2790 Timestamp option 2792 Mobile Node Interface Identifier option 2794 Link-local Address option 2796 Status 2798 8-bit unsigned integer indicating the disposition of the Proxy 2799 Binding Update. Values of the Status field less than 128 indicate 2800 that the Proxy Binding Update was accepted by the local mobility 2801 anchor. Values greater than or equal to 128 indicate that the 2802 binding registration was rejected by the local mobility anchor. 2803 Section 8.9 defines the Status values that can used in Proxy 2804 Binding Acknowledgement message. 2806 For descriptions of other fields present in this message, refer to 2807 the section 6.1.8 [RFC-3775]. 2809 8.3. Home Network Prefix Option 2811 A new option, Home Network Prefix Option is defined for using it in 2812 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2813 exchanged between a local mobility anchor and a mobile access 2814 gateway. This option is used for exchanging the mobile node's home 2815 network prefix information. 2817 The Home Network Prefix Option has an alignment requirement of 8n+4. 2818 Its format is as follows: 2820 0 1 2 3 2821 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 2822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 | Type | Length | Reserved | Prefix Length | 2824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2825 | | 2826 + + 2827 | | 2828 + Home Network Prefix + 2829 | | 2830 + + 2831 | | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2834 Type 2835 2837 Length 2839 8-bit unsigned integer indicating the length of the option 2840 in octets, excluding the type and length fields. This field 2841 MUST be set to 18. 2843 Reserved (R) 2845 This 8-bit field is unused for now. The value MUST be 2846 initialized to 0 by the sender and MUST be ignored by the 2847 receiver. 2849 Prefix Length 2851 8-bit unsigned integer indicating the prefix length of the 2852 IPv6 prefix contained in the option. 2854 Home Network Prefix 2856 A sixteen-byte field containing the mobile node's IPv6 Home 2857 Network Prefix. 2859 8.4. Handoff Indicator Option 2861 A new option, Handoff Indicator Option is defined for using it in the 2862 Proxy Binding Update and Proxy Binding Acknowledgement messages 2863 exchanged between a local mobility anchor and a mobile access 2864 gateway. This option is used for exchanging the mobile node's 2865 handoff related hints. 2867 The Handoff Indicator Option has no alignment requirement. Its 2868 format is as follows: 2870 0 1 2 3 2871 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 2872 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2873 | Type | Length | Reserved (R) | HI | 2874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2876 Type 2877 2879 Length 2881 8-bit unsigned integer indicating the length of the option 2882 in octets, excluding the type and length fields. This field 2883 MUST be set to 2. 2885 Reserved (R) 2887 This 8-bit field is unused for now. The value MUST be 2888 initialized to 0 by the sender and MUST be ignored by the 2889 receiver. 2891 Handoff Indicator (HI) 2893 A 8-bit field that specifies the type of handoff. The values 2894 (0 - 255) will be allocated and managed by IANA. The following 2895 values are currently reserved. 2897 0: Reserved 2898 1: Attachment over a new interface 2899 2: Handoff between two different interfaces of the mobile node 2900 3: Handoff between mobile access gateways for the same interface 2901 4: Handoff state unknown 2902 5: Handoff state not changed (Re-registration) 2904 8.5. Access Technology Type Option 2906 A new option, Access Technology Type Option is defined for using it 2907 in the Proxy Binding Update and Proxy Binding Acknowledgement 2908 messages exchanged between a local mobility anchor and a mobile 2909 access gateway. This option is used for exchanging the type of the 2910 access technology using which the mobile node is currently attached 2911 to the mobile access gateway. 2913 The Access Technology Type Option has no alignment requirement. Its 2914 format is as follows: 2916 0 1 2 3 2917 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 2918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2919 | Type | Length | Reserved (R) | ATT | 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2922 Type 2923 2925 Length 2927 8-bit unsigned integer indicating the length of the option 2928 in octets, excluding the type and length fields. This field 2929 MUST be set to 2. 2931 Reserved (R) 2933 This 8-bit field is unused for now. The value MUST be 2934 initialized to 0 by the sender and MUST be ignored by the 2935 receiver. 2937 Access Technology Type (ATT) 2939 A 8-bit field that specifies the access technology through 2940 which the mobile node is connected to the access link on the 2941 mobile access gateway. 2943 The values (0 - 255) will be allocated and managed by IANA. The 2944 following values are currently reserved for the below specified 2945 access technology types. 2947 0: Reserved 2948 1: Virtual 2949 2: PPP 2950 3: 802.3 (Ethernet) 2951 4: 802.11a/b/g 2952 5: 802.16e 2954 8.6. Mobile Node Interface Identifier Option 2956 A new option, Mobile Node Interface Identifier Option is defined for 2957 using it in the Proxy Binding Update and Proxy Binding 2958 Acknowledgement messages exchanged between a local mobility anchor 2959 and a mobile access gateway. This option is used for exchanging the 2960 mobile node's interface identifier. 2962 The format of the Interface Identifier option when the interface 2963 identifier is 8 bytes is shown below. When the size is different, 2964 the option MUST be aligned appropriately, as per mobility option 2965 alignment requirements specified in [RFC-3775]. 2967 0 1 2 3 2968 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 2969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2970 | Type | Length | Reserved | 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 | | 2973 + Interface Identifier + 2974 . ... . 2975 | | 2976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2978 Type 2979 2981 Length 2982 8-bit unsigned integer indicating the length of the option 2983 in octets, excluding the type and length fields. 2985 Reserved 2987 This field is unused for now. The value MUST be initialized to 2988 0 by the sender and MUST be ignored by the receiver. 2990 Interface Identifier 2992 A variable length field containing the mobile node's interface 2993 identifier. 2995 The content and format of this field (including byte and bit 2996 ordering) is as specified in Section 4.6 [RFC-4861] for 2997 carrying Link-Layer Address. 2999 8.7. Link-local Address Option 3001 A new option, Link-local Address Option is defined for using it in 3002 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3003 exchanged between a local mobility anchor and a mobile access 3004 gateway. This option is used for exchanging the mobile node's link- 3005 local address. 3007 The Link-local Address option has an alignment requirement of 8n+6. 3008 Its format is as follows: 3010 0 1 2 3 3011 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 3012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3013 | Type | Length | 3014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 | | 3016 + + 3017 | | 3018 + Link-local Address + 3019 | | 3020 + + 3021 | | 3022 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3024 Type 3025 3027 Length 3029 8-bit unsigned integer indicating the length of the option 3030 in octets, excluding the type and length fields. This field 3031 MUST be set to 16. 3033 Link-local Address 3035 A sixteen-byte field containing the mobile node's link-local 3036 address. 3038 8.8. Timestamp Option 3040 A new option, Timestamp Option is defined for use in the Proxy 3041 Binding Update and Proxy Binding Acknowledgement messages. 3043 The Timestamp option has an alignment requirement of 8n+2. Its 3044 format is as follows: 3046 0 1 2 3 3047 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 3048 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3049 | Type | Length | 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | | 3052 + Timestamp + 3053 | | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3056 Type 3057 3059 Length 3061 8-bit unsigned integer indicating the length in octets of 3062 the option, excluding the type and length fields. The value 3063 for this field MUST be set to 8. 3065 Timestamp 3067 A 64-bit unsigned integer field containing a timestamp. The value 3068 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3069 by using a fixed point format. In this format, the integer number 3070 of seconds is contained in the first 48 bits of the field, and the 3071 remaining 16 bits indicate the number of 1/65536 fractions of a 3072 second. 3074 8.9. Status Values 3076 This document defines the following new Status values for use in 3077 Proxy Binding Acknowledgement message. These values are to be 3078 allocated from the same number space, as defined in Section 6.1.8 3079 [RFC-3775]. 3081 Status values less than 128 indicate that the Proxy Binding Update 3082 request was accepted by the local mobility anchor. Status values 3083 greater than 128 indicate that the Proxy Binding Update was rejected 3084 by the local mobility anchor. 3086 PROXY_REG_NOT_ENABLED: 3088 Proxy registration not enabled for the mobile node 3090 NOT_LMA_FOR_THIS_MOBILE_NODE: 3092 Not local mobility anchor for this mobile node 3094 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 3096 The mobile access gateway is not authorized to send proxy binding 3097 registrations 3099 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 3101 The mobile node is not authorized for the requesting home network 3102 prefix 3104 TIMESTAMP_MISMATCH: 3106 Invalid timestamp value (the clocks are out of sync) 3108 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 3110 The timestamp value is lower than the previously accepted value 3112 MISSING_HOME_NETWORK_PREFIX_OPTION 3114 Missing home network prefix option 3116 MISSING_MN_IDENTIFIER_OPTION: 3118 Missing mobile node identifier option 3120 MISSING_HANDOFF_INDICATOR_OPTION 3122 Missing handoff indicator option 3124 MISSING_ACCESS_TECH_TYPE_OPTION 3125 Missing access technology type option 3127 Additionally, the following Status values defined in [RFC-3775] can 3128 also be used in Proxy Binding Acknowledgement message. 3130 0 Proxy Binding Update accepted 3132 128 Reason unspecified 3134 129 Administratively prohibited 3136 130 Insufficient resources 3138 9. Protocol Configuration Variables 3140 The local mobility anchor MUST allow the following variables to be 3141 configured by the system management. 3143 MinDelayBeforeBCEDelete 3145 This variable specifies the amount of time in milliseconds the 3146 local mobility anchor MUST wait before it deletes a Binding Cache 3147 entry of a mobile node, upon receiving a Proxy Binding Update 3148 message from a mobile access gateway with a lifetime value of 0. 3149 During this wait time, if the local mobility anchor receives a 3150 Proxy Binding Update for the same mobility binding, with lifetime 3151 value greater than 0, then it must update the binding cache entry 3152 with the accepted binding values. By the end of this wait-time, 3153 if the local mobility anchor did not receive any valid Proxy 3154 Binding Update message for that mobility binding, it MUST delete 3155 the Binding Cache entry. This delay essentially ensures a mobile 3156 node's Binding Cache entry is not deleted too quickly and allows 3157 some time for the new mobile access gateway to complete the 3158 signaling for the mobile node. 3160 The default value for this variable is 10000 milliseconds. 3162 MaxDelayBeforeNewBCEAssign 3164 This variable specifies the amount of time in milliseconds the 3165 local mobility anchor MUST wait for the de-registration message 3166 for an existing mobility session before it decides to create a new 3167 mobility session. 3169 The default value for this variable is 500 milliseconds. 3171 TimestampValidityWindow 3173 This variable specifies the maximum amount of time difference in 3174 milliseconds between the timestamp in the received Proxy Binding 3175 Update message and the current time-of-day on the local mobility 3176 anchor, that is allowed by the local mobility anchor for the 3177 received message to be considered valid. 3179 The default value for this variable is 300 milliseconds. This 3180 variable MUST be adjusted to suit the deployments. 3182 The mobile access gateway MUST allow the following variables to be 3183 configured by the system management. 3185 EnableMAGLocalrouting 3187 This flag indicates whether or not the mobile access gateway is 3188 allowed to enable local routing of the traffic exchanged between a 3189 visiting mobile node and a correspondent node that is locally 3190 connected to one of the interfaces of the mobile access gateway. 3191 The correspondent node can be another visiting mobile node as 3192 well, or a local fixed node. 3194 The default value for this flag is set to "FALSE", indicating that 3195 the mobile access gateway MUST reverse tunnel all the traffic to 3196 the mobile node's local mobility anchor. 3198 When the value of this flag is set to "TRUE", the mobile access 3199 gateway MUST route the traffic locally. 3201 This aspect of local routing MAY be defined as policy on a per 3202 mobile basis and when present will take precedence over this flag. 3204 10. IANA Considerations 3206 This document defines six new Mobility Header options, the Home 3207 Network Prefix option, Handoff Indicator option, Access Technology 3208 Type option, Interface Identifier option, Link-local Address option 3209 and Timestamp option. These options are described in Section 8. The 3210 Type value for these options needs to be assigned from the same 3211 numbering space as allocated for the other mobility options, as 3212 defined in [RFC-3775]. 3214 The Access Technology Type option defined in Section 8.5 of this 3215 document introduces a new Access Technology type numbering space, 3216 where the values from 0 to 5 have been reserved by this document. 3217 Approval of new Access Technology type numbers are to be made through 3218 IANA Expert Review. 3220 This document also defines new Binding Acknowledgement status values 3221 as described in Section 8.9. The status values MUST be assigned from 3222 the same number space used for Binding Acknowledgement status values, 3223 as defined in [RFC-3775]. The allocated values for each of these 3224 status values MUST be greater than 128. 3226 11. Security Considerations 3228 The potential security threats against any network-based mobility 3229 management protocol are described in [RFC-4832]. This section 3230 explains how Proxy Mobile IPv6 protocol defends itself against those 3231 threats. 3233 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3234 Binding Update and Proxy Binding Acknowledgement, exchanged between 3235 the mobile access gateway and the local mobility anchor to be 3236 protected using IPsec, using the established security association 3237 between them. This essentially eliminates the threats related to the 3238 impersonation of the mobile access gateway or the local mobility 3239 anchor. 3241 This specification allows a mobile access gateway to send binding 3242 registration messages on behalf of a mobile node. If proper 3243 authorization checks are not in place, a malicious node may be able 3244 to hijack a mobile node's session or may carry out a denial-of- 3245 service attack. To prevent this attack, this specification requires 3246 the local mobility anchor to allow only authorized mobile access 3247 gateways that are part of that Proxy Mobile IPv6 domain to send 3248 binding registration messages on behalf of a mobile node. 3250 To eliminate the threats on the interface between the mobile access 3251 gateway and the mobile node, this specification requires an 3252 established trust between the mobile access gateway and the mobile 3253 node and to authenticate and authorize the mobile node before it is 3254 allowed to access the network. Further, the established 3255 authentication mechanisms enabled on that access link will ensure 3256 that there is a secure binding between the mobile node's identity and 3257 its link-layer address. The mobile access gateway will definitively 3258 identify the mobile node from the packets that it receives on that 3259 access link. 3261 To address the threat related to a compromised mobile access gateway, 3262 the local mobility anchor, before accepting a Proxy Binding Update 3263 message for a given mobile node, may ensure that the mobile node is 3264 definitively attached to the mobile access gateway that sent the 3265 proxy binding registration request. This may be accomplished by 3266 contacting a trusted entity which is able to track the mobile node's 3267 current point of attachment. However, the specific details of the 3268 actual mechanisms for achieving this is outside the scope of this 3269 document. 3271 12. Acknowledgements 3273 The authors would like to specially thank Julien Laganier, Christian 3274 Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for 3275 their thorough review of this document. 3277 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3278 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3279 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3280 Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao, 3281 Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3282 Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil 3283 Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Ved Kafle, 3284 Vidya Narayanan, Youn-Hee Han and many others for their passionate 3285 discussions in the working group mailing list on the topic of 3286 localized mobility management solutions. These discussions 3287 stimulated much of the thinking and shaped the draft to the current 3288 form. We acknowledge that ! 3290 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3291 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 3292 Tim Stammers for their input on this document. 3294 13. References 3296 13.1. Normative References 3298 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3299 Requirement Levels", BCP 14, RFC 2119, March 1997. 3301 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3302 IPv6 Specification", RFC 2473, December 1998. 3304 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3305 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3306 RFC 3315, July 2003. 3308 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3309 IPv6", RFC 3775, June 2004. 3311 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3312 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3313 January 2005. 3315 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3316 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3317 November 2005. 3319 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3320 Internet Protocol", RFC 4301, December 2005. 3322 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3323 4303, December 2005. 3325 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3326 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3327 2007. 3329 13.2. Informative References 3331 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 3332 51, RFC 1661, July 1994. 3334 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3335 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3336 2005. 3338 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3339 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3340 4140, August 2005. 3342 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3343 Protocol", RFC 4306, December 2005. 3345 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3346 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 3348 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3349 "Chargeable User Identity", RFC 4372, January 2006. 3351 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3352 G., Liebsch, M., "Problem Statement for Network-based Localized 3353 Mobility Management", September 2006. 3355 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3356 G., Liebsch, M., "Goals for Network-based Localized Mobility 3357 Management", October 2006. 3359 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3360 Localized Mobility Management", September 2006. 3362 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3363 Address Autoconfiguration", RFC 4862, September 2007. 3365 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3366 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3367 2007. 3369 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3370 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3371 November 2007. 3373 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 3374 Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. 3376 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3378 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3379 typically be identified by an identifier, MN-Identifier, and that 3380 identifier will have an associated policy profile that identifies the 3381 mobile node's home network prefix, permitted address configuration 3382 modes, roaming policy and other parameters that are essential for 3383 providing network-based mobility service. This information is 3384 typically configured in AAA. It is possible the home network prefix 3385 is dynamically allocated for the mobile node when it boots up for the 3386 first time in the network, or it could be a statically configured 3387 value on per mobile node basis. However, for all practical purposes, 3388 the network entities in the proxy Mobile IPv6 domain, while serving a 3389 mobile node will have access to this profile and these entities can 3390 query this information using RADIUS/DIAMETER protocols. 3392 Appendix B. Supporting Shared-Prefix Model using DHCPv6 3394 This specification supports Per-MN-Prefix model. However, it is 3395 possible to support Shared-Prefix model under the following 3396 guidelines. 3398 The mobile node is allowed to use stateful address configuration 3399 using DHCPv6 for obtaining its address configuration. The mobile 3400 node is not allowed to use any of the stateless autoconfiguration 3401 techniques. The permitted address configuration models for the 3402 mobile node on the access link can be enforced by the mobile access 3403 gateway, by setting the relevant flags in the Router Advertisements, 3404 as per [RFC-4861]. 3406 The Home Network Prefix option that is sent by the mobile access 3407 gateway in the Proxy Binding Update message, must contain the 128-bit 3408 host address that the mobile node obtained via DHCPv6. 3410 Routing state at the mobile access gateway: 3412 For all IPv6 traffic from the source MN-HoA::/128 to 3413 _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is 3414 the MAG to LMA tunnel. 3416 Routing state at the local mobility anchor: 3418 For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, 3419 next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. 3421 Appendix C. Routing State 3423 The following section explains the routing state for a mobile node on 3424 the mobile access gateway. This routing state reflects only one 3425 specific way of implementation and one MAY choose to implement it in 3426 other ways. The policy based route defined below acts as a traffic 3427 selection rule for routing a mobile node's traffic through a specific 3428 tunnel created between the mobile access gateway and that mobile 3429 node's local mobility anchor and with the specific encapsulation 3430 mode, as negotiated. 3432 The below example identifies the routing state for two visiting 3433 mobile nodes, MN1 and MN2 with their respective local mobility 3434 anchors LMA1 and LMA2. 3436 For all traffic from the mobile node, identified by the mobile node's 3437 MAC address, ingress interface or source prefix (MN-HNP) to 3438 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3440 +==================================================================+ 3441 | Packet Source | Destination Address | Destination Interface | 3442 +==================================================================+ 3443 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3444 | (IPv6 Prefix or |----------------------------------------------| 3445 | Input Interface) | Locally Connected | Tunnel0 | 3446 +------------------------------------------------------------------+ 3447 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3448 + (IPv6 Prefix or -----------------------------------------------| 3449 | Input Interface | Locally Connected | direct | 3450 +------------------------------------------------------------------+ 3452 Figure 22: Example - Policy based Route Table 3454 +==================================================================+ 3455 | Interface | Source Address | Destination Address | Encapsulation | 3456 +==================================================================+ 3457 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3458 +------------------------------------------------------------------+ 3459 | Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 | 3460 +------------------------------------------------------------------+ 3462 Figure 23: Example - Tunnel Interface Table 3464 Authors' Addresses 3466 Sri Gundavelli 3467 Cisco 3468 170 West Tasman Drive 3469 San Jose, CA 95134 3470 USA 3472 Email: sgundave@cisco.com 3474 Kent Leung 3475 Cisco 3476 170 West Tasman Drive 3477 San Jose, CA 95134 3478 USA 3480 Email: kleung@cisco.com 3481 Vijay Devarapalli 3482 Azaire Networks 3483 4800 Great America Pkwy 3484 Santa Clara, CA 95054 3485 USA 3487 Email: vijay.devarapalli@azairenet.com 3489 Kuntal Chowdhury 3490 Starent Networks 3491 30 International Place 3492 Tewksbury, MA 3494 Email: kchowdhury@starentnetworks.com 3496 Basavaraj Patil 3497 Nokia Siemens Networks 3498 6000 Connection Drive 3499 Irving, TX 75039 3500 USA 3502 Email: basavaraj.patil@nsn.com 3504 Full Copyright Statement 3506 Copyright (C) The IETF Trust (2008). 3508 This document is subject to the rights, licenses and restrictions 3509 contained in BCP 78, and except as set forth therein, the authors 3510 retain all their rights. 3512 This document and the information contained herein are provided on an 3513 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3514 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3515 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3516 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3517 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3518 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3520 Intellectual Property 3522 The IETF takes no position regarding the validity or scope of any 3523 Intellectual Property Rights or other rights that might be claimed to 3524 pertain to the implementation or use of the technology described in 3525 this document or the extent to which any license under such rights 3526 might or might not be available; nor does it represent that it has 3527 made any independent effort to identify any such rights. Information 3528 on the procedures with respect to rights in RFC documents can be 3529 found in BCP 78 and BCP 79. 3531 Copies of IPR disclosures made to the IETF Secretariat and any 3532 assurances of licenses to be made available, or the result of an 3533 attempt made to obtain a general license or permission for the use of 3534 such proprietary rights by implementers or users of this 3535 specification can be obtained from the IETF on-line IPR repository at 3536 http://www.ietf.org/ipr. 3538 The IETF invites any interested party to bring to its attention any 3539 copyrights, patents or patent applications, or other proprietary 3540 rights that may cover technology that may be required to implement 3541 this standard. Please address the information to the IETF at 3542 ietf-ipr@ietf.org. 3544 Acknowledgment 3546 Funding for the RFC Editor function is provided by the IETF 3547 Administrative Support Activity (IASA).