idnits 2.17.1 draft-ietf-netlmm-proxymip6-09.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 3476. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3487. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3494. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3500. 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 03, 2008) is 5919 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 6, 2008 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 February 03, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-09.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 6, 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 . . . . . . . . . . . . . . . . . . 33 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 33 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 . . . . . . . . . . . . 39 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 . . . . . . . . . . . . . 49 98 6.9.3. Default-Router Lifetime . . . . . . . . . . . . . . . 50 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 51 100 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 51 101 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 52 102 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 52 103 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 53 104 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 53 105 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 53 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 . . 56 110 6.14. Allowing network access to other IPv6 nodes . . . . . . . 57 111 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 57 112 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 57 113 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 58 114 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 59 115 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 59 116 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 61 117 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 62 118 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 63 119 8.5. Access Technology Type Option . . . . . . . . . . . . . . 64 120 8.6. Mobile Node Interface Identifier Option . . . . . . . . . 66 121 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 67 122 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 67 123 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 68 124 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 70 125 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 71 126 11. Security Considerations . . . . . . . . . . . . . . . . . . . 72 127 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 73 128 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 73 129 13.1. Normative References . . . . . . . . . . . . . . . . . . . 73 130 13.2. Informative References . . . . . . . . . . . . . . . . . . 74 131 Appendix A. Proxy Mobile IPv6 interactions with AAA 132 Infrastructure . . . . . . . . . . . . . . . . . . . 75 133 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 75 134 Appendix C. Routing State . . . . . . . . . . . . . . . . . . . . 76 135 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 77 136 Intellectual Property and Copyright Statements . . . . . . . . . . 79 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.0. 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.0, 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 133 (Not local mobility anchor 810 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 signaling messages and under the 1104 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 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. 1263 5. For all other cases, the message MUST be considered as a request 1264 for creating a new mobility session. 1266 5.4.1.3. Mobile Node Interface Identifier Option not present in the 1267 request 1269 +=====================================================================+ 1270 | Registration/De-Registration Message | 1271 +=====================================================================+ 1272 | HNP (ALL_ZERO Value) | 1273 +=====================================================================+ 1274 | ATT | 1275 +=====================================================================+ 1276 | IID Option Not Present | 1277 +=====================================================================+ 1278 | HI | 1279 +==================================+==================================+ 1280 | BCE Lookup Key: (MN-Identifier) | 1281 +=====================================================================+ 1283 Figure 9: BCE Lookup using Mobile Node Identifier 1285 1. The local mobility anchor MUST verify if there exists one and 1286 only one Binding Cache entry with the mobile node identifier 1287 matching the identifier in the Mobile Node Identifier option 1288 present in the request. 1290 2. If there exists only one such entry (matching the MN-Identifier) 1291 and the Handoff Indicator field in the Handoff Indicator option 1292 present in the request is set to a value of 2 (Handoff between 1293 two different interfaces of the mobile node), the request MUST be 1294 considered as a request for updating that Binding Cache entry. 1295 [PBU(HI) == 2] 1297 3. If there exists only one such entry (matching the MN-Identifier) 1298 and the Handoff Indicator field in the Handoff Indicator option 1299 present in the request is set to a value of 4 (Handoff state 1300 unknown), the local mobility anchor SHOULD wait till the existing 1301 Binding Cache entry is de-registered by the previously serving 1302 mobile access gateway, before the request can be considered as a 1303 request for updating that Binding Cache entry. However, if there 1304 is no de-registration message that is received within 1305 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1306 anchor upon accepting the request MUST consider the request as a 1307 request for updating that Binding Cache entry. The local 1308 mobility anchor MAY also choose to create a new mobility session 1309 and without waiting for a de-registration message. 1311 4. For all other cases, the message MUST be considered as a request 1312 for creating a new mobility session. 1314 5.5. Timestamp Option for Message Ordering 1316 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1317 registration messages as a way for the home agent to process the 1318 binding updates in the order they were sent by a mobile node. The 1319 home agent and the mobile node are required to manage this counter 1320 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1321 the mobile node moves from one mobile access gateway to another and 1322 in the absence of mechanisms such as context transfer between the 1323 mobile access gateways, the serving mobile access gateway will be 1324 unable to determine the sequence number that it needs to use in the 1325 signaling messages. Hence, the sequence number scheme, as specified 1326 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1328 If the local mobility anchor cannot determine the sending order of 1329 the received binding registration messages, it may potentially 1330 process an older message sent by a mobile access gateway where the 1331 mobile node was previously anchored, resulting in an incorrect 1332 Binding Cache entry. 1334 For solving this problem, this specification adopts two alternative 1335 solutions. One is based on timestamps and the other based on 1336 sequence numbers, as defined in [RFC-3775]. 1338 The basic principle behind the use of timestamps in binding 1339 registration messages is that the node generating the message inserts 1340 the current time-of-day, and the node receiving the message checks 1341 that this timestamp is greater than all previously accepted 1342 timestamps. The timestamp based solution may be used, when the 1343 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1344 have the ability to obtain the last sequence number that was sent in 1345 a binding registration message for updating a given mobile node's 1346 binding. 1348 As an alternative to the Timestamp based approach, the specification 1349 also allows the use of Sequence Number based scheme, as per [RFC- 1350 3775]. However, for this scheme to work, the serving mobile access 1351 gateways in a Proxy Mobile IPv6 domain MUST have the ability to 1352 obtain the last sequence number that was sent in a binding 1353 registration message for updating a given mobile node's binding. The 1354 sequence number MUST be maintained on a per mobile node basis and 1355 MUST be synchronized between the serving mobile access gateways. 1356 This may be achieved by using context transfer schemes or by 1357 maintaining the sequence number in a policy store. However, the 1358 specific details on how the mobile node's sequence number is 1359 synchronized between different mobile access gateways is outside the 1360 scope of this document. 1362 Using Timestamps based approach: 1364 1. A local mobility anchor implementation MUST support Timestamp 1365 option. If the Timestamp option is present in the received Proxy 1366 Binding Update request message, then the local mobility anchor 1367 MUST include a valid Timestamp option in the Proxy Binding 1368 Acknowledgement message that it sends to the mobile access 1369 gateway. 1371 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1372 exchanging binding registration messages using the Timestamp 1373 option must have adequately synchronized time-of-day clocks. 1374 This is the essential requirement for this solution to work. If 1375 this requirement is not met, the solution will not predictably 1376 work in all cases. 1378 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1379 synchronize their clocks to a common time source. For 1380 synchronizing the clocks, the nodes may use Network Time Protocol 1381 [RFC-4330]. Deployments may also adopt other approaches suitable 1382 for that specific deployment. Alternatively, if there is mobile 1383 node generated timestamp that is increasing at every attachment 1384 to the access link and if that timestamp is available to the 1385 mobile access gateway (Ex: The timestamp option in the SEND 1386 messages that the mobile node sends), the mobile access gateway 1387 can use this timestamp or sequence number in the Proxy Binding 1388 Update messages and does not have to depend on any external clock 1389 source. However, the specific details on how this is achieved is 1390 outside the scope of this document. 1392 4. When generating the timestamp value for building the Timestamp 1393 option, the mobility entities MUST ensure that the generated 1394 timestamp is the elapsed time past the same reference epoch, as 1395 specified in the format for the Timestamp option [Section 8.8]. 1397 5. If the Timestamp option is present in the received Proxy Binding 1398 Update message, the local mobility anchor MUST ignore the 1399 sequence number field in the message. However, it MUST copy the 1400 sequence number from the received Proxy Binding Update message to 1401 the Proxy Binding Acknowledgement message. 1403 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1404 option, the local mobility anchor MUST check the timestamp field 1405 for validity. In order for it to be considered valid, the 1406 timestamp value contained in the Timestamp option MUST be close 1407 enough (within TimestampValidityWindow amount of time difference) 1408 to the local mobility anchor's time-of-day clock and the 1409 timestamp MUST be greater than all previously accepted timestamps 1410 in the Proxy Binding Update messages sent for that mobile node. 1412 7. If the timestamp value in the received Proxy Binding Update is 1413 valid (validity as specified in the above considerations), the 1414 local mobility anchor MUST return the same timestamp value in the 1415 Timestamp option included in the Proxy Binding Acknowledgement 1416 message that it sends to the mobile access gateway. 1418 8. If the timestamp value in the received Proxy Binding Update is 1419 lower than the previously accepted timestamp in the Proxy Binding 1420 Update messages sent for that mobility binding, the local 1421 mobility anchor MUST reject the Proxy Binding Update request and 1422 send a Proxy Binding Acknowledgement message with Status field 1423 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1424 previously accepted timestamp). The message MUST also include 1425 the Timestamp option with the value set to the current time-of- 1426 day on the local mobility anchor. 1428 9. If the timestamp value in the received Proxy Binding Update is 1429 not valid (validity as specified in the above considerations), 1430 the local mobility anchor MUST reject the Proxy Binding Update 1431 and send a Proxy Binding Acknowledgement message with Status 1432 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1433 message MUST also include the Timestamp option with the value set 1434 to the current time-of-day on the local mobility anchor. 1436 Using Sequence Number based approach: 1438 1. If the Timestamp option is not present in the received Proxy 1439 Binding Update request, the local mobility anchor MUST fallback 1440 to the Sequence Number based scheme. It MUST process the 1441 sequence number field as specified in [RFC-3775]. Also, it MUST 1442 NOT include the Timestamp option in the Proxy Binding 1443 Acknowledgement messages that it sends to the mobile access 1444 gateway. 1446 2. An implementation MUST support Sequence Number based scheme, as 1447 per [RFC-3775]. 1449 5.6. Routing Considerations 1451 5.6.1. Bi-Directional Tunnel Management 1453 o A bi-directional tunnel MUST be established between the local 1454 mobility anchor and the mobile access gateway with IP-in-IP 1455 encapsulation, as described in [RFC-2473]. The tunnel end points 1456 are the Proxy-CoA and LMAA. When using IPv4 transport with a 1457 specific encapsulation mode, the end points of the tunnel are the 1458 IPv4-LMAA and IPv4-Proxy-CoA, as specified in [ID-IPV4-PMIP6]. 1460 o The bi-directional tunnel MUST be used for routing the mobile 1461 node's data traffic between the mobile access gateway and the 1462 local mobility anchor. The tunnel hides the topology and enables 1463 a mobile node to use an address from its home network prefix from 1464 any access link attached to the mobile access gateway. 1466 o The bi-directional tunnel is established after accepting the Proxy 1467 Binding Update request message. The created tunnel may be shared 1468 with other mobile nodes attached to the same mobile access gateway 1469 and with the local mobility anchor having a Binding Cache entry 1470 for those mobile nodes. Implementations MAY choose to use static 1471 tunnels instead of dynamically creating and tearing them down on a 1472 need basis. 1474 o Implementations MAY use a software timer for managing the tunnel 1475 lifetime and a counter for keeping a count of all the mobile nodes 1476 that are sharing the tunnel. The timer value MUST be set to the 1477 accepted binding lifetime and will be updated after each periodic 1478 re-registration for extending the lifetime. If the tunnel is 1479 shared for multiple mobile nodes, the tunnel lifetime MUST be set 1480 to the highest binding lifetime that is granted to any one of 1481 those mobile nodes sharing that tunnel. 1483 5.6.2. Forwarding Considerations 1485 Intercepting Packets Sent to the Mobile Node's Home Network: 1487 o When the local mobility anchor is serving a mobile node, it MUST 1488 be able to receive packets that are sent to the mobile node's home 1489 network. In order for it to receive those packets, it MUST 1490 advertise a connected route in to the Routing Infrastructure for 1491 the mobile node's home network prefix or for an aggregated prefix 1492 with a larger scope. This essentially enables IPv6 routers in 1493 that network to detect the local mobility anchor as the last-hop 1494 router for that prefix. 1496 Forwarding Packets to the Mobile Node: 1498 o On receiving a packet from a correspondent node with the 1499 destination address matching a mobile node's home network prefix, 1500 the local mobility anchor MUST forward the packet through the bi- 1501 directional tunnel setup for that mobile node. The format of the 1502 tunneled packet is shown below. However, when using IPv4 1503 transport, the format of the packet is as described in [ID-IPV4- 1504 PMIP6]. 1506 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1507 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1508 Upper layer protocols /* Packet Content*/ 1510 Figure 10: Tunneled Packets from LMA to MAG 1512 Forwarding Packets Sent by the Mobile Node: 1514 o All the reverse tunneled packets that the local mobility anchor 1515 receives from the mobile access gateway, after removing the tunnel 1516 header MUST be routed to the destination specified in the inner 1517 packet header. These routed packets will have the source address 1518 field set to the mobile node's home address. 1520 5.7. Local Mobility Anchor Address Discovery 1522 Dynamic Home Agent Address Discovery, as explained in Section 10.5 1523 [RFC-3775], allows a mobile node to discover all the home agents on 1524 its home link by sending an ICMP Home Agent Address Discovery Request 1525 message to the Mobile IPv6 Home-Agents anycast address, derived from 1526 its home network prefix. 1528 The DHAAD message in the current form cannot be used in Proxy Mobile 1529 IPv6 for discovering the address of the mobile node's local mobility 1530 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1531 able to receive any messages sent to the Mobile IPv6 Home-Agents 1532 anycast address corresponding to the mobile node's home network 1533 prefix, as the prefix is not hosted on any of its interfaces. 1534 Further, the mobile access gateway will not predictably be able to 1535 locate the serving local mobility anchor that has the mobile node's 1536 binding cache entry. Hence, this specification does not support 1537 Dynamic Home Agent Address Discovery protocol. 1539 In Proxy Mobile IPv6, the address of the local mobility anchor 1540 configured to serve a mobile node can be discovered by the mobility 1541 entities in other ways. This may be a configured entry in the mobile 1542 node's policy profile, or it may be obtained through mechanisms 1543 outside the scope of this document. 1545 5.8. Mobile Prefix Discovery Considerations 1547 This specification does not support mobile prefix discovery. The 1548 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1549 applicable to Proxy Mobile IPv6. 1551 5.9. Route Optimizations Considerations 1553 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1554 enables a mobile node to communicate with a correspondent node 1555 directly using its care-of address and further the Return Routability 1556 procedure enables the correspondent node to have reasonable trust 1557 that the mobile node is reachable at both its home address and 1558 care-of address. 1560 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1561 mobility related signaling. The mobile node uses only its home 1562 address for all its communication and the Care-of address (Proxy-CoA) 1563 is not visible to the mobile node. Hence, the Return Routability 1564 procedure as defined in Mobile IPv6 [RFC-3775] cannot be used in 1565 Proxy Mobile IPv6. 1567 6. Mobile Access Gateway Operation 1569 The Proxy Mobile IPv6 protocol described in this document introduces 1570 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1571 access gateway is the entity that is responsible for detecting the 1572 mobile node's movements to and from the access link and sending the 1573 binding registration requests to the local mobility anchor. In 1574 essence, the mobile access gateway performs mobility management on 1575 behalf of a mobile node. 1577 The mobile access gateway is a function that typically runs on an 1578 access router. However, implementations MAY choose to split this 1579 function and run it across multiple systems. The specifics on how 1580 that is achieved or the signaling interactions between those 1581 functional entities are beyond the scope of this document. 1583 The mobile access gateway has the following key functional roles: 1585 o It is responsible for detecting the mobile node's movements on the 1586 access link and for initiating the mobility signaling with the 1587 mobile node's local mobility anchor. 1589 o Emulation of the mobile node's home link on the access link by 1590 sending Router Advertisements with the mobile node's home network 1591 prefix information. 1593 o Responsible for setting up the data path for enabling the mobile 1594 node to configure an address from its home network prefix and use 1595 it from its access link. 1597 6.1. Extensions to Binding Update List Entry Data Structure 1599 Every mobile access gateway MUST maintain a Binding Update List. 1600 Each entry in the Binding Update List represents a mobile node's 1601 mobility binding with its local mobility anchor. The Binding Update 1602 List is a conceptual data structure, described in Section 11.1 [RFC- 1603 3775]. 1605 For supporting this specification, the conceptual Binding Update List 1606 entry data structure needs be extended with the following additional 1607 fields. 1609 o The Identifier of the attached mobile node, MN-Identifier. This 1610 identifier is acquired during the mobile node's attachment to the 1611 access link through mechanisms outside the scope of this document. 1613 o The interface identifier of the mobile node's connected interface. 1614 This address can be acquired from the received Router Solicitation 1615 messages from the mobile node or during the mobile node's 1616 attachment to the access network. This is typically a Layer-2 1617 identifier conveyed by the mobile node; however, the specific 1618 details on how that is conveyed is out of scope for this 1619 specification. If this identifier is not available, the value 1620 MUST be set to ALL_ZERO. 1622 o The IPv6 home network prefix of the attached mobile node. The 1623 home network prefix of the mobile node is acquired from the mobile 1624 node's local mobility anchor through the received Proxy Binding 1625 Acknowledgement messages. The IPv6 home network prefix also 1626 includes the corresponding prefix length. 1628 o The Link-local address of the mobile node on the interface 1629 attached to the access link. 1631 o The IPv6 address of the local mobility anchor serving the attached 1632 mobile node. This address is acquired from the mobile node's 1633 policy profile or from other means. 1635 o The interface identifier (If-Id) of the access link where the 1636 mobile node is currently attached. This is internal to the mobile 1637 access gateway and is used to associate the Proxy Mobile IPv6 1638 tunnel to the access link where the mobile node is attached. 1640 o The interface identifier (If-Id) of the bi-directional tunnel 1641 between the mobile node's local mobility anchor and the mobile 1642 access gateway. This is internal to the mobile access gateway. 1643 The tunnel interface identifier is acquired during the tunnel 1644 creation. 1646 6.2. Mobile Node's Policy Profile 1648 A mobile node's policy profile contains the essential operational 1649 parameters that are required by the network entities for managing the 1650 mobile node's mobility service. These policy profiles are stored in 1651 a local or a remote policy store. The mobile access gateway and the 1652 local mobility anchor MUST be able to obtain a mobile node's policy 1653 profile. The policy profile MAY also be handed over to a serving 1654 mobile access gateway as part of a context transfer procedure during 1655 a handoff or the serving mobile access gateway MAY be able to 1656 dynamically generate this profile. The exact details on how this 1657 achieved is outside the scope of this document. However, this 1658 specification requires that a mobile access gateway serving a mobile 1659 node MUST have access to its policy profile. 1661 The following are the mandatory fields of the policy profile: 1663 o The mobile node's identifier (MN-Identifier) 1665 o The IPv6 address of the local mobility anchor (LMAA) 1667 The following are the optional fields of the policy profile: 1669 o The mobile node's IPv6 home network prefix (MN-HNP) 1671 o The mobile node's IPv6 home network Prefix lifetime 1673 o Supported address configuration procedures (Stateful, Stateless or 1674 both) for the mobile node in the Proxy Mobile IPv6 domain 1676 6.3. Supported Access Link Types 1678 This specification supports only point-to-point access link types and 1679 thus it assumes that the mobile node and the mobile access gateway 1680 are the only two nodes on the access link. The link is assumed to 1681 have multicast capability. This protocol may also be used on other 1682 link types, as long as the link is configured in such a way that it 1683 guarantees a point-to-point delivery between the mobile node and the 1684 mobile access gateway for all the protocol traffic. 1686 6.4. Supported Address Configuration Modes 1688 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1689 more IPv6 addresses on its interface using Stateless or Stateful 1690 address autoconfiguration procedures. The Router Advertisement 1691 messages sent on the access link specify the address configuration 1692 methods permitted on that access link for that mobile node. However, 1693 the advertised flags with respect to the address configuration will 1694 be consistent for a mobile node, on any of the access links in that 1695 Proxy Mobile IPv6 domain. Typically, these configuration settings 1696 will be based on the domain wide policy or based on a policy specific 1697 to each mobile node. 1699 When stateless address autoconfiguration is supported on the access 1700 link, the mobile node can generate one or more IPv6 addresses by 1701 standard IPv6 mechanisms such as Stateless Autoconfiguration 1702 specification [RFC-4862] or Privacy extension specification [RFC- 1703 4941]. 1705 When stateful address autoconfiguration is supported on the link, the 1706 mobile node can obtain the address configuration from the DHCPv6 1707 server by standard DHCPv6 mechanisms, as specified in DHCPv6 1708 specification [RFC-3315]. 1710 Additionally, other address configuration mechanisms specific to the 1711 access link between the mobile node and the mobile access gateway may 1712 also be used for pushing the address configuration to the mobile 1713 node. This specification does not change the behavior of address 1714 configuration mechanisms in any way. 1716 6.5. Access Authentication & Mobile Node Identification 1718 When a mobile node attaches to an access link connected to the mobile 1719 access gateway, the deployed access security protocols on that link 1720 SHOULD ensure that the network-based mobility management service is 1721 offered only after authenticating and authorizing the mobile node for 1722 that service. The exact specifics on how this is achieved or the 1723 interactions between the mobile access gateway and the access 1724 security service is outside the scope of this document. This 1725 specification goes with the stated assumption of having an 1726 established trust between the mobile node and the mobile access 1727 gateway, before the protocol operation begins. 1729 6.6. Acquiring Mobile Node's Identifier 1731 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1732 to identify a mobile node, using its MN-Identifier. This identifier 1733 MUST be stable across the Proxy Mobile IPv6 domain and the entities 1734 must be able to use this identifier in the signaling messages. 1735 Typically, this identifier is obtained as part of the access 1736 authentication or through other means as specified below. 1738 o The identifier of the mobile node that the mobile access gateway 1739 obtains typically as part of the access authentication or from the 1740 notified network attachment event, can be a temporary identifier 1741 and further that temporary identifier may be different at each re- 1742 authentication. The mobile access gateway MUST be able to use 1743 this temporary identifier and obtain the mobile node's stable 1744 identifier from the policy store. For instance, in AAA-based 1745 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1746 4372] may be used. 1748 o The MN-Identifier that the policy store delivers to the mobile 1749 access gateway may not be the true identifier of the mobile node. 1750 However, the mobility access gateway MUST be able to use this 1751 identifier in the signaling messages exchanged with the local 1752 mobility anchor. 1754 o The mobile access gateway MUST be able to identify the mobile node 1755 by its MN-Identifier and it MUST be able to associate this 1756 identity to the point-to-point link sharing with the mobile node. 1758 6.7. Home Network Emulation 1760 One of the key functions of a mobile access gateway is to emulate the 1761 mobile node's home network on the access link. It must ensure, the 1762 mobile node believes it is still connected to its home link or on the 1763 link where it obtained its initial address configuration after it 1764 moved into that Proxy Mobile IPv6 domain. 1766 For emulating the mobile node's home link on the access link, the 1767 mobile access gateway must be able to send Router Advertisements 1768 advertising the mobile node's home network prefix and other address 1769 configuration parameters consistent with its home link properties. 1770 Typically, these configuration settings will be based on the domain 1771 wide policy or based on a policy specific to each mobile node. 1773 Typically, the mobile access gateway learns the mobile node's home 1774 network prefix information from the received Proxy Binding 1775 Acknowledgement message or it may be obtained from the mobile node's 1776 policy profile. However, the mobile access gateway SHOULD send the 1777 Router Advertisements advertising the mobile node's home network 1778 prefix only after successfully completing the binding registration 1779 with the mobile node's local mobility anchor. 1781 When advertising the home network prefix in the Router Advertisement 1782 messages, the mobile access gateway MAY set the prefix lifetime value 1783 for the advertised prefix to any chosen value at its own discretion. 1784 An implementation MAY choose to tie the prefix lifetime to the mobile 1785 node's binding lifetime. The prefix lifetime can also be an optional 1786 configuration parameter in the mobile node's policy profile. 1788 6.8. Link-Local and Global Address Uniqueness 1790 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1791 mobile access gateway to the other, will continue to detect its home 1792 network and thus making it believe it is still on the same link. 1793 Every time the mobile node attaches to a new link, the event related 1794 to the interface state change will trigger the mobile node to perform 1795 DAD operation on the link-local and global addresses. However, if 1796 the mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may 1797 not detect the link change due to DNAv6 optimizations and may not 1798 trigger the duplicate address detection (DAD) procedure for 1799 establishing the link-local address uniqueness on that new link. 1800 This leaves a room for link-local address collision between the two 1801 neighbors on that access link. 1803 For solving this problem, this specification allows the mobile access 1804 gateway to upload the mobile node's link-local address to the local 1805 mobility anchor using the Link-local Address option, exchanged in the 1806 binding registration messages. The mobile access gateway can learn 1807 the mobile node's link-local address, by snooping the DAD messages 1808 sent by the mobile node for establishing the link-local address 1809 uniqueness on the access link. Subsequently, at each handoff, the 1810 mobile access gateway can obtain this address from the local mobility 1811 anchor to ensure link-local address uniqueness and change its own 1812 link-local address, if it detects a collision. 1814 Alternatively, one of the workarounds for this issue is to set the 1815 DNAv6 configuration parameter, DNASameLinkDADFlag to TRUE and that 1816 will force the mobile node to redo DAD operation on the global and 1817 link-local addresses every time the interface detects an handoff, 1818 even when DNAv6 does not detect a link change. 1820 However, this issue may not impact point-to-point links based on PPP. 1821 Each time the mobile node moves and attaches to a new mobile access 1822 gateway, the PPP session [RFC-1661] can be re-established, or if 1823 there are context transfer procedures in place, the entire PPP 1824 session can be moved to the new link and the link-local addresses of 1825 both the peers will continue to remain the same. In either of these 1826 approaches, the link-local address uniqueness on the link is assured. 1827 The specific details of how the PPP session is re-established without 1828 impacting any layer-3 sessions or how the PPP session can be moved 1829 between the mobile access gateways is outside the scope of this 1830 document. 1832 The issue of address collision is not relevant to the mobile node's 1833 global address. Since there is a unique home network prefix assigned 1834 for each mobile node, the uniqueness for the mobile node's global 1835 address is assured on the access link. 1837 6.9. Signaling Considerations 1839 6.9.1. Binding Registrations 1841 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 1843 1. After detecting a new mobile node on its access link, the mobile 1844 access gateway MUST identify the mobile node and acquire its MN- 1845 Identifier. If it determines that the network-based mobility 1846 management service needs to be offered to the mobile node, it 1847 MUST send a Proxy Binding Update message to the local mobility 1848 anchor. 1850 2. The Proxy Binding Update message MUST include the Mobile Node 1851 Identifier option [RFC-4283], carrying the MN-Identifier for 1852 identifying the mobile node. 1854 3. The Home Network Prefix option MUST be present in the Proxy 1855 Binding Update message. If the mobile access gateway learns the 1856 mobile node's home network prefix either from its policy store 1857 or from other means, the mobile access gateway MAY choose to 1858 specify the same in the Home Network Prefix option for 1859 requesting the local mobility anchor to allocate that prefix, 1860 otherwise it MUST specify a value of ALL_ZERO. If the specified 1861 value is ALL_ZERO, then the local mobility anchor will do the 1862 prefix assignment. 1864 4. The Handoff Indicator option MUST be present in the Proxy 1865 Binding Update message. The Handoff Indicator field in the 1866 Handoff Indicator option MUST be set to a value indicating the 1867 handoff hint. The specific details on how the mobile access 1868 gateway determines if the mobile node's current attachment is 1869 due to an handoff of an existing mobility session or if it is as 1870 a result of an attachment over a different interface is outside 1871 the scope of this document. 1873 * The Handoff Indicator field MUST be set to value 1 1874 (Attachment over a new interface), if the mobile access 1875 gateway predictably knows that the mobile node's current 1876 attachment to the network over this interface is not as a 1877 result of an handoff of an existing mobility session (over 1878 the same interface or through a different interface), but as 1879 a result of an attachment over a new interface. This 1880 essentially serves as a request to the local mobility anchor 1881 to create a new mobility session and not update any existing 1882 Binding Cache entry created for the same mobile node 1883 connected to the Proxy Mobile IPv6 domain through a different 1884 interface. 1886 * The Handoff Indicator field MUST be set to value 2 (Handoff 1887 between two different interfaces of the mobile node), if the 1888 mobile access gateway definitively knows the mobile node's 1889 current attachment is due to an handoff of an existing 1890 mobility session, between two different interfaces of the 1891 mobile node. 1893 * The Handoff Indicator field MUST be set to value 3 (Handoff 1894 between mobile access gateways for the same interface), if 1895 the mobile access gateway definitively knows the mobile 1896 node's current attachment is due to an handoff of an existing 1897 mobility session between two mobile access gateways and for 1898 the same interface of the mobile node. 1900 * The Handoff Indicator field MUST be set to value 4 (Handoff 1901 state unknown), if the mobile access gateway cannot determine 1902 if the mobile node's current attachment is due to an handoff 1903 of an existing mobility session. 1905 5. Either the Timestamp option or a valid sequence number 1906 maintained on a per mobile node basis (if Sequence Number based 1907 scheme is in use) MUST be present. When Timestamp option is 1908 added to the message, the mobile access gateway SHOULD also set 1909 the Sequence Number field to a value of a monotonically 1910 increasing counter (not to be confused with the per mobile node 1911 sequence number specified [RFC-3775]). The local mobility 1912 anchor will ignore this field when there is a Timestamp option 1913 present in the request, but will return the same value in the 1914 Proxy Binding Acknowledgement message. This will be useful for 1915 matching the reply to the request message. 1917 6. The Mobile Node Interface Identifier option carrying the 1918 interface identifier of the currently attached interface MUST be 1919 present in the Proxy Binding Update message, if the mobile 1920 access gateway knows the interface identifier of the mobile 1921 node's currently attached interface. If the interface 1922 identifier is not known or if the identifier value is ALL_ZERO, 1923 this option MUST NOT be present. 1925 7. The Access Technology Type option MUST be present in the Proxy 1926 Binding Update message. The access technology type field in the 1927 option SHOULD be set to the type of access technology using 1928 which the mobile node is currently attached to the mobile access 1929 gateway. 1931 8. The Link-local Address option MAY be present in the Proxy 1932 Binding Update message. Considerations from Section 6.8 MUST be 1933 applied when using the link-local address option. 1935 * When uploading the link-local address to the local mobility 1936 anchor, the value in the option MUST be set to the link-local 1937 address that is configured on the currently attached 1938 interface of the mobile node. 1940 * When querying the local mobility anchor for the mobile node's 1941 link-local address, the option MUST be set to ALL_ZERO value. 1942 This essentially serves as a request to the local mobility 1943 anchor to return the link-local address of the mobile node 1944 from the binding cache entry corresponding to this mobility 1945 session. 1947 9. The Proxy Binding Update message MUST be constructed as 1948 specified in Section 6.9.1.5. 1950 10. If there is no existing Binding Update List entry for that 1951 mobile node, the mobile access gateway MUST create a Binding 1952 Update List entry for the mobile node upon sending the Proxy 1953 Binding Update request. 1955 6.9.1.2. Receiving Binding Registration Reply 1957 On receiving a Proxy Binding Acknowledgement message from the local 1958 mobility anchor, the mobile access gateway MUST process the message 1959 as specified below. 1961 1. The received Proxy Binding Acknowledgement message (a Binding 1962 Acknowledgement message with the 'P' flag set) MUST be 1963 authenticated as described in Section 4.0. When IPsec is used 1964 for message authentication, the SPI in the IPsec header [RFC- 1965 4306] of the received packet is needed for locating the security 1966 association, for authenticating the Proxy Binding 1967 Acknowledgement message . 1969 2. The mobile access gateway MUST observe the rules described in 1970 Section 9.2 [RFC-3775] when processing Mobility Headers in the 1971 received Proxy Binding Acknowledgement message. 1973 3. The mobile access gateway MUST apply the considerations 1974 specified in Section 5.5 for processing the Sequence Number 1975 field and the Timestamp option (if present), in the message. 1977 4. The mobile access gateway MUST ignore any checks, specified in 1978 [RFC-3775] related to the presence of Type 2 Routing header in 1979 the Proxy Binding Acknowledgement message. 1981 5. The mobile access gateway MAY use the mobile node identifier 1982 present in the Mobile Node Identifier option for matching the 1983 response to the request messages that it sent recently . 1984 However, if there are more than one request message in its 1985 request queue for the same mobile node, the sequence number 1986 field can be used for identifying the exact message from those 1987 messages. There are other ways to achieve this and 1988 implementations are free to adopt the best approach that suits 1989 their implementation. Additionally, if the received Proxy 1990 Binding Acknowledgement message does not match any of the Proxy 1991 Binding Update messages that it sent recently, the message MUST 1992 be ignored. 1994 6. If the received Proxy Binding Acknowledgement message has any 1995 one or more of the following options, Handoff Indicator option, 1996 Access Technology Type option, Mobile Node Interface Identifier 1997 option, Mobile Node Identifier option, carrying option values 1998 that are different from the option values present in the 1999 corresponding request (Proxy Binding Update) message, the 2000 message MUST be ignored as the local mobility anchor is expected 2001 to echo back all these listed options and with the same option 2002 values in the reply message. 2004 7. If the received Proxy Binding Acknowledgement message has the 2005 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2006 registration not enabled for the mobile node), the mobile access 2007 gateway SHOULD NOT send binding registration requests again for 2008 that mobile node. It MUST deny the mobility service to that 2009 mobile node. 2011 8. If the received Proxy Binding Acknowledgement message has the 2012 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2013 (Timestamp value lower than previously accepted value), the 2014 mobile access gateway SHOULD try to register again to reassert 2015 the mobile node's presence on its access link. The mobile 2016 access gateway is not specifically required to synchronize its 2017 clock upon receiving this error code. 2019 9. If the received Proxy Binding Acknowledgement message has the 2020 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2021 value), the mobile access gateway SHOULD try to register again 2022 only after it has synchronized its clock to a common time source 2023 that is used by all the mobility entities in that domain for 2024 their clock synchronization. The mobile access gateway SHOULD 2025 NOT synchronize its clock to the local mobility anchor's system 2026 clock, based on the timestamp present in the received message. 2028 10. If the received Proxy Binding Acknowledgement message has the 2029 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2030 (mobile node is not authorized for the requesting home network 2031 prefix), the mobile access gateway SHOULD NOT request for the 2032 same prefix again, but can request the local mobility anchor to 2033 dynamically assign a prefix, by specifying a ALL_ZERO value in 2034 the Home Network Prefix option carried in the subsequent Proxy 2035 Binding Update message. 2037 11. If the received Proxy Binding Acknowledgement message has the 2038 Status field value set to any value greater than or equal to 128 2039 (i.e., if the binding is rejected), the mobile access gateway 2040 MUST NOT advertise the mobile node's home network prefix in the 2041 Router Advertisements sent on that access link and there by 2042 denying mobility service to the mobile node. 2044 12. If the received Proxy Binding Acknowledgement message has the 2045 Status field value set to 0 (Proxy Binding Update accepted), the 2046 mobile access gateway MUST update the routing state, as 2047 explained in section 6.10, and MUST also update the Binding 2048 Update List entry for reflecting the accepted binding 2049 registration status. 2051 13. If the received Proxy Binding Acknowledgement message has the 2052 address in the Link-local Address option set to a value that 2053 matches its own link-local address on that access interface 2054 where the mobile node is anchored, the mobile access gateway 2055 MUST change its link-local address on that interface, to avoid 2056 link-local address collision on that access link. 2058 6.9.1.3. Extending Binding Lifetime 2060 1. For extending the lifetime of a currently registered mobile node 2061 (i.e., after a successful initial binding registration from the 2062 same mobile access gateway), the mobile access gateway can send a 2063 Proxy Binding Update message to the local mobility anchor with a 2064 new lifetime value. This re-registration message MUST be 2065 constructed with the same set of options as the initial binding 2066 registration message, under the considerations specified in 2067 Section 6.9.1.1. However the following exceptions apply. 2069 2. The prefix value in the Home Network Prefix option MUST be set to 2070 the currently assigned home network prefix. 2072 3. The Handoff Indicator field in the Handoff Indicator option MUST 2073 be set to a value of 5 (Handoff state not changed - Re- 2074 Registration). 2076 4. The value in the Link-local Address option (if the option was 2077 present in the initial registration message) MUST be set to the 2078 link-local address of the mobile node's attached interface. 2080 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2082 1. At any point, the mobile access gateway detects that the mobile 2083 node has moved away from its access link, or if it decides to 2084 terminate the mobile node's mobility session, it SHOULD send a 2085 Proxy Binding Update message to the local mobility anchor with 2086 the lifetime value set to zero. This de-registration message 2087 MUST be constructed with the same set of options as the initial 2088 binding registration message, under the considerations specified 2089 in Section 6.9.1.1. However, the following exceptions apply. 2091 2. The prefix value in the Home Network Prefix option MUST be set to 2092 the currently assigned home network prefix. 2094 3. The Handoff Indicator field in the Handoff Indicator option MUST 2095 be set to a value of 4 (Handoff state unknown). 2097 4. The value in the Link-local Address option (if the option was 2098 present in the initial registration message) MUST be set to the 2099 link-local address of the mobile node's attached interface. 2101 Either upon receipt of a Proxy Binding Acknowledgement message from 2102 the local mobility anchor or after INITIAL_BINDINGACK_TIMEOUT [RFC- 2103 3775] timeout waiting for the reply, the mobile access gateway MUST 2104 do the following: 2106 1. It MUST remove the Binding Update List entry for the mobile node 2107 from its Binding Update List. 2109 2. It MUST withdraw the mobile node's home network prefix as the 2110 hosted on-link prefix, by sending a Router Advertisement message 2111 with the prefix lifetime value set to zero. 2113 3. It MUST remove the created routing state for tunneling the mobile 2114 node's traffic. 2116 4. It SHOULD teardown the point-to-point link shared with the mobile 2117 node. This action will force the mobile node to remove any IPv6 2118 address configuration on the interface connected to this point- 2119 to-point link. 2121 6.9.1.5. Constructing the Proxy Binding Update Message 2123 o The mobile access gateway when sending the Proxy Binding Update 2124 request to the local mobility anchor MUST construct the message as 2125 specified below. 2127 IPv6 header (src=Proxy-CoA, dst=LMAA) 2128 Mobility header 2129 - BU /* P & A flags MUST be set */ 2130 Mobility Options 2131 - Mobile Node Identifier option (mandatory) 2132 - Home Network Prefix option (mandatory) 2133 - Handoff Indicator option (mandatory) 2134 - Access Technology Type option (mandatory) 2135 - Timestamp option (optional) 2136 - Mobile Node Interface Identifier option (optional) 2137 - Link-local Address option (optional) 2139 Figure 11: Proxy Binding Update message format 2141 o The Source Address field in the IPv6 header of the message MUST be 2142 set to the address configured on the interface of the mobile 2143 access gateway. When there is no Alternate Care-of Address option 2144 present in the request, this address will be considered as the 2145 Proxy-CoA address for this binding registration request. However, 2146 when there is Alternate Care-of Address option present in the 2147 request, this address will be not be the considered as the Proxy- 2148 CoA address, but the address in the alternate Care-of Address 2149 option will be considered as the Proxy-CoA address. 2151 o The Destination Address field in the IPv6 header of the message 2152 MUST be set to the local mobility anchor address. 2154 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2156 o The Home Network Prefix option MUST be present. 2158 o The Handoff Indicator option MUST be present. 2160 o The Access Technology Type option MUST be present. 2162 o The Timestamp option MAY be present. 2164 o The Mobile Node Interface Identifier option MAY be present. 2166 o The Link-local Address option MAY be present. 2168 o If IPsec is used for protecting the signaling messages, the 2169 message MUST be protected, using the security association existing 2170 between the local mobility anchor and the mobile access gateway. 2172 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2173 3775] MUST NOT be present in the IPv6 Destination Options 2174 extension header of the Proxy Binding Update message. 2176 6.9.2. Router Solicitation Messages 2178 The mobile node may send a Router Solicitation message on the access 2179 link whenever the link-layer detects a media change. The Source 2180 Address in the IPv6 header of the Router Solicitation message may 2181 either be the link-local address of the mobile node or an unspecified 2182 address (::). The Router Solicitation message that the mobile node 2183 sends is as specified in [RFC-4861]. 2185 1. The mobile access gateway on receiving the Router Solicitation 2186 message SHOULD send a Router Advertisement containing the mobile 2187 node's home network prefix as the on-link prefix. However, 2188 before sending the Router Advertisement message containing the 2189 mobile node's home network prefix, it SHOULD complete the binding 2190 registration process with the mobile node's local mobility 2191 anchor. 2193 2. If the local mobility anchor rejects the binding registration 2194 request, or, if the mobile access gateway failed to complete the 2195 binding registration process for whatever reasons, the mobile 2196 access gateway MUST NOT advertise the mobile node's home network 2197 prefix in the Router Advertisement messages that it sends on the 2198 access link. However, it MAY choose to advertise a local visited 2199 network prefix to enable the mobile node for regular IPv6 access. 2201 6.9.3. Default-Router Lifetime 2203 This section is a non-normative section and only provides some 2204 general guidance to implementations. 2206 In Proxy Mobile IPv6, the mobile access gateway is typically the IPv6 2207 default-router for the mobile node on the access link, as it is the 2208 entity that sends the Router Advertisements on the access link. 2209 However, as the mobile node moves from one access link to another, 2210 the serving mobile access gateway on those respective links will send 2211 the Router Advertisements and using their own link-local address. 2212 The mobile node on each of the attached links will receive Router 2213 Advertisement messages with a different source address and this makes 2214 the mobile node believe that there is a new default-router on that 2215 access link. 2217 The mobile node will certainly detect the previous default-router 2218 loss by performing the Neighbor Unreachability Detection procedure 2219 per the standard IPv6 ND mechanisms, but it is important that the 2220 mobile access gateway enables the mobile node to withdraw the 2221 previous default-router entry at the earliest. This action will help 2222 in minimizing packet losses during a hand off switch. Following are 2223 some considerations that implementations can apply. 2225 The Router Lifetime field in the Router Advertisement messages that 2226 the mobile access gateway sends on the access link SHOULD be kept to 2227 low. 2229 In access networks where SEND [RFC-3971] is not deployed, the mobile 2230 access gateway can withdraw the previous default-router entry, by 2231 sending a Router Advertisement using the link-local address that of 2232 the previous mobile access gateway and with the Router Lifetime field 2233 set to value zero, then this will force the flush of the previous 2234 default-router entry from the mobile node's cache, as specified in 2235 Section 6.3.5 [RFC-4861]. However, this approach requires the 2236 serving mobile access gateway to learn the link-local address of the 2237 previous mobile access gateway where the mobile node was handed off. 2239 There are other solutions possible for this problem, including the 2240 assignment of a fixed link-local address for all the mobility 2241 entities in a Proxy Mobile IPv6 domain and where SEND [RFC-3971] is 2242 not deployed. In such scenario, the mobile node is not required to 2243 update the default-router entry. However, this is an implementation 2244 choice and has no bearing on the protocol interoperability. 2245 Implementations are free to adopt the best approach that suits their 2246 target deployments. 2248 6.9.4. Retransmissions and Rate Limiting 2250 The mobile access gateway is responsible for retransmissions and rate 2251 limiting the binding registration requests that it sends to the local 2252 mobility anchor. The Retransmission and the Rate Limiting rules are 2253 as specified in [RFC-3775]. However, the following considerations 2254 MUST be applied. 2256 1. When the mobile access gateway sends a Proxy Binding Update 2257 request, it should use the constant, INITIAL_BINDINGACK_TIMEOUT 2258 [RFC-3775], for configuring the retransmission timer, as 2259 specified in Section 11.8 [RFC-3775]. However, the mobile access 2260 gateway is not required to use a longer retransmission interval 2261 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2262 the initial binding registration request. 2264 2. If the mobile access gateway fails to receive a valid matching 2265 response for a registration or re-registration message within the 2266 retransmission interval, it SHOULD retransmit the message until a 2267 response is received. However, the mobile access gateway MUST 2268 ensure the mobile node is still attached to the connected link 2269 before retransmitting the message. 2271 3. As specified in Section 11.8 [RFC-3775], the mobile access 2272 gateway MUST use an exponential back-off process in which the 2273 timeout period is doubled upon each retransmission, until either 2274 the node receives a response or the timeout period reaches the 2275 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2276 MAY continue to send these messages at this slower rate 2277 indefinitely. 2279 4. If Timestamp based scheme is in use, the retransmitted Proxy 2280 Binding Update messages MUST use the latest timestamp. If 2281 Sequence number scheme is in use, the retransmitted Proxy Binding 2282 Update messages MUST use a Sequence Number value greater than 2283 that used for the previous transmission of this Proxy Binding 2284 Update message, just as specified in [RFC-3775]. 2286 6.10. Routing Considerations 2288 This section describes how the mobile access gateway handles the 2289 traffic to/from the mobile node that is attached to one of its access 2290 interface. 2292 Proxy-CoA LMAA 2293 | | 2294 +--+ +---+ +---+ +--+ 2295 |MN|----------|MAG|======================|LMA|----------|CN| 2296 +--+ +---+ +---+ +--+ 2297 IPv6 Tunnel 2299 Figure 12: Proxy Mobile IPv6 Tunnel 2301 6.10.1. Transport Network 2303 The transport network between the local mobility anchor and the 2304 mobile access gateway can be either an IPv6 or IPv4 network. 2305 However, this specification only deals with the IPv6 transport and 2306 the companion document [ID-IPV4-PMIP6] specifies the required 2307 extensions for negotiating IPv4 transport and the corresponding 2308 encapsulation mode for supporting this protocol operation. 2310 6.10.2. Tunneling & Encapsulation Modes 2312 The IPv6 address that a mobile node uses from its home network prefix 2313 is topologically anchored at the local mobility anchor. For a mobile 2314 node to use this address from an access network attached to a mobile 2315 access gateway, proper tunneling techniques have to be in place. 2316 Tunneling hides the network topology and allows the mobile node's 2317 IPv6 datagram to be encapsulated as a payload of another IPv6 packet 2318 and to be routed between the local mobility anchor and the mobile 2319 access gateway. The Mobile IPv6 base specification [RFC-3775] 2320 defines the use of IPv6-over-IPv6 tunneling, between the home agent 2321 and the mobile node and this specification extends the use of the 2322 same tunneling mechanism between the local mobility anchor and the 2323 mobile access gateway. 2325 On most operating systems, tunnels are implemented as a virtual 2326 point-to-point interface. The source and the destination address of 2327 the two end points of this virtual interface along with the 2328 encapsulation mode are specified for this virtual interface. Any 2329 packet that is routed over this interface gets encapsulated with the 2330 outer header and the addresses as specified for that point to point 2331 tunnel interface. For creating a point to point tunnel to any local 2332 mobility anchor, the mobile access gateway may implement a tunnel 2333 interface with the source address field set to its Proxy-CoA address 2334 and the destination address field set to the LMA address. 2336 The following are the supported packet encapsulation modes that can 2337 be used by the mobile access gateway and the local mobility anchor 2338 for routing mobile node's IPv6 datagrams. 2340 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2341 2473]. 2343 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2344 details on how this mode is negotiated is specified in [ID-IPV4- 2345 PMIP6]. 2347 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2348 packet. This mode is specified in [ID-IPV4-PMIP6]. 2350 6.10.3. Local Routing 2352 If there is data traffic between a visiting mobile node and a 2353 correspondent node that is locally attached to an access link 2354 connected to the mobile access gateway, the mobile access gateway MAY 2355 optimize on the delivery efforts by locally routing the packets and 2356 by not reverse tunneling them to the mobile node's local mobility 2357 anchor. The configuration variable, EnableMAGLocalRouting MAY be 2358 used for controlling this aspect. However, in some systems, this may 2359 have an implication on the mobile node's accounting and policy 2360 enforcement as the local mobility anchor is not in the path for that 2361 traffic and it will not be able to apply any traffic policies or do 2362 any accounting for those flows. 2364 This decision of path optimization SHOULD be based on the policy 2365 configured on the mobile access gateway, but enforced by the mobile 2366 node's local mobility anchor. The specific details on how this is 2367 achieved are beyond of the scope of this document. 2369 6.10.4. Tunnel Management 2371 All the considerations mentioned in Section 5.6.1 for the tunnel 2372 management on the local mobility anchor apply for the mobile access 2373 gateway as well. 2375 6.10.5. Forwarding Rules 2377 Forwarding Packets sent to the Mobile Node's Home Network: 2379 o On receiving a packet from the bi-directional tunnel established 2380 with the mobile node's local mobility anchor, the mobile access 2381 gateway MUST use the destination address of the inner packet for 2382 forwarding it on the interface where the destination network 2383 prefix is hosted. The mobile access gateway MUST remove the outer 2384 header before forwarding the packet. If the mobile access gateway 2385 cannot find the connected interface for that destination address, 2386 it MUST silently drop the packet. For reporting an error in such 2387 a scenario, in the form of ICMP control message, the 2388 considerations from Generic Packet Tunneling specification [RFC- 2389 2473] must be applied. 2391 o On receiving a packet from a correspondent node that is locally 2392 connected and which is destined to a mobile node that is on 2393 another locally connected access link, the mobile access gateway 2394 MUST check the configuration variable, EnableMAGLocalRouting, to 2395 ensure the mobile access gateway is allowed to route the packet 2396 directly to the mobile node. If the mobile access gateway is not 2397 allowed to route the packet directly, it MUST route the packet 2398 through the bi-directional tunnel established between itself and 2399 the mobile node's local mobility anchor. Otherwise, it can route 2400 the packet directly to the mobile node. 2402 Forwarding Packets Sent by the Mobile Node: 2404 o On receiving a packet from a mobile node connected to its access 2405 link, the mobile access gateway MUST ensure that there is an 2406 established binding for that mobile node with its local mobility 2407 anchor before forwarding the packet directly to the destination or 2408 before tunneling the packet to the mobile node's local mobility 2409 anchor. 2411 o On receiving a packet from a mobile node connected to its access 2412 link to a destination that is locally connected, the mobile access 2413 gateway MUST check the configuration variable, 2414 EnableMAGLocalRouting, to ensure the mobile access gateway is 2415 allowed to route the packet directly to the destination. If the 2416 mobile access gateway is not allowed to route the packet directly, 2417 it MUST route the packet through the bi-directional tunnel 2418 established between itself and the mobile node's local mobility 2419 anchor. Otherwise, it can route the packet directly to the 2420 destination. 2422 o On receiving a packet from the mobile node connected to its access 2423 link, to a destination that is not directly connected, the packet 2424 MUST be forwarded to the local mobility anchor through the bi- 2425 directional tunnel established between itself and the mobile 2426 node's local mobility anchor. However, the packets that are sent 2427 with the link-local source address MUST NOT be forwarded. The 2428 format of the tunneled packet is shown below. Additionally, when 2429 using IPv4 transport, the format of the tunneled packet is as 2430 described in [ID-IPV4-PMIP6]. 2432 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2433 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2434 Upper layer protocols /* Packet Content*/ 2435 Figure 13: Tunneled Packets from MAG to LMA 2437 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2439 This section explains how Stateful Address Configuration using DHCPv6 2440 can be enabled on the access link attached to a mobile access gateway 2441 and how a mobile node attached to that link can obtain an address 2442 from its home network prefix using DHCPv6. 2444 o For supporting Stateful Address Configuration using DHCPv6, the 2445 DHCPv6 relay agent [RFC-3315] service MUST be enabled on each of 2446 the access links in the Proxy Mobile IPv6 domain. Further, as 2447 specified in Section 20 [RFC-3315], the relay agent should be 2448 configured to use a list of destination addresses, which MAY 2449 include unicast addresses, the All_DHCP_Servers multicast address, 2450 or other addresses selected by the network administrator. 2452 o The DHCPv6 server in the Proxy Mobile IPv6 domain can be 2453 configured with a list of prefix pools (P1, P2, ..., Pn). Each 2454 one of these prefix pools corresponds to a home network prefix 2455 that a local mobility anchor allocates to a mobile node in that 2456 domain. However, the DHCPv6 server will not know the relation 2457 between a given address pool and a mobile node to which the 2458 corresponding prefix is allocated. It just views these pools as 2459 prefixes hosted on different links in that domain. 2461 o When a mobile node sends a DHCPv6 request message, the DHCP relay 2462 agent function on the access link will set the link-address field 2463 in the DHCP message to an address in the mobile node's home 2464 network prefix, so as to provide a prefix hint to the DHCP Server 2465 for the address pool selection. The DHCP server on receiving the 2466 request from the mobile node, will allocate an address from the 2467 prefix pool present in the link-address field of the request. 2469 o Once the mobile node obtains an address and moves to a different 2470 link and sends a DHCP request, the DHCP relay agent on the new 2471 link will set the prefix hint in the DHCP messages to the mobile 2472 node's home network prefix. The DHCP server will identify the 2473 client from the Client-DUID option and present in the request and 2474 will allocate the same address as before. 2476 o The DHCP based address configuration is not recommended for 2477 deployments where the local mobility anchor and the mobile access 2478 gateways are located in different administrative domains. For 2479 this configuration to work, all the mobile access gateways in the 2480 Proxy Mobile IPv6 domain should be able to ensure that the DHCP 2481 requests from a given mobile node anchored on any of the access 2482 links in that domain, will always be handled by the same DHCP 2483 server. 2485 o The DHCP server should be configured to offer low address lease 2486 times. A lease time that is too large prevents the DHCP server 2487 from reclaiming the address even after the local mobility anchor 2488 deletes the mobile node's binding cache entry. 2490 6.12. Home Network Prefix Renumbering 2492 If the mobile node's home network prefix gets renumbered or becomes 2493 invalid during the middle of a mobility session, the mobile access 2494 gateway MUST withdraw the prefix by sending a Router Advertisement on 2495 the access link with zero prefix lifetime for the mobile node's home 2496 network prefix. Also, the local mobility anchor and the mobile 2497 access gateway MUST delete the routing state for that prefix. 2498 However, the specific details on how the local mobility anchor 2499 notifies the mobile access gateway about the mobile node's home 2500 network prefix renumbering are outside the scope of this document. 2502 6.13. Mobile Node Detachment Detection and Resource Cleanup 2504 Before sending a Proxy Binding Update message to the local mobility 2505 anchor for extending the lifetime of a currently existing binding of 2506 a mobile node, the mobile access gateway MUST make sure the mobile 2507 node is still attached to the connected link by using some reliable 2508 method. If the mobile access gateway cannot predictably detect the 2509 presence of the mobile node on the connected link, it MUST NOT 2510 attempt to extend the registration lifetime of the mobile node. 2511 Further, in such scenario, the mobile access gateway SHOULD terminate 2512 the binding of the mobile node by sending a Proxy Binding Update 2513 message to the mobile node's local mobility anchor with lifetime 2514 value set to 0. It MUST also remove any local state such as the 2515 Binding Update List entry created for that mobile node. 2517 The specific detection mechanism of the loss of a visiting mobile 2518 node on the connected link is specific to the access link between the 2519 mobile node and the mobile access gateway and is outside the scope of 2520 this document. Typically, there are various link-layer specific 2521 events specific to each access technology that the mobile access 2522 gateway can depend on for detecting the node loss. In general, the 2523 mobile access gateway can depend on one or more of the following 2524 methods for the detection presence of the mobile node on the 2525 connected link: 2527 o Link-layer event specific to the access technology 2529 o PPP Session termination event on point-to-point link types 2530 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2532 o Notification event from the local mobility anchor 2534 6.14. Allowing network access to other IPv6 nodes 2536 In some Proxy Mobile IPv6 deployments, network operators may want to 2537 provision the mobile access gateway to offer network-based mobility 2538 management service only to some visiting mobile nodes and enable just 2539 regular IP access to some other nodes. This requires the network to 2540 have control on when to enable network-based mobility management 2541 service to a mobile node and when to enable regular IPv6 access. 2542 This specification does not disallow such configuration. 2544 Upon detecting a mobile node on its access link and after policy 2545 considerations, the mobile access gateway MUST determine if network- 2546 based mobility management service should be offered to that mobile 2547 node. If the mobile node is entitled for network-based mobility 2548 management service, then the mobile access gateway must ensure the 2549 mobile node believes it is on its home link, as explained in various 2550 sections of this specification. 2552 If the mobile node is not entitled for the network-based mobility 2553 management service, as determined from the policy considerations, the 2554 mobile access gateway MAY choose to offer regular IPv6 access to the 2555 mobile node and in such scenario the normal IPv6 considerations 2556 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2557 obtain an IPv6 address using normal IPv6 address configuration 2558 procedures. The obtained address must be from a local visitor 2559 network prefix. This essentially ensures that the mobile access 2560 gateway functions as a normal access router to a mobile node attached 2561 to its access link and with out impacting its host-based mobility 2562 protocol operation. 2564 7. Mobile Node Operation 2566 This non-normative section explains the mobile node's operation in a 2567 Proxy Mobile IPv6 domain. 2569 7.1. Moving into a Proxy Mobile IPv6 Domain 2571 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2572 an access network, the mobile access gateway on the access link 2573 detects the attachment of the mobile node and completes the binding 2574 registration with the mobile node's local mobility anchor. If the 2575 binding update operation is successfully performed, the mobile access 2576 gateway will create the required state and setup the data path for 2577 the mobile node's data traffic. 2579 If the mobile node is IPv6 enabled, on attaching to the access link, 2580 it will typically send Router Solicitation message [RFC-4861]. The 2581 mobile access gateway on the access link will respond to the Router 2582 Solicitation message with a Router Advertisement. The Router 2583 Advertisement will have the mobile node's home network prefix, 2584 default-router address and other address configuration parameters. 2586 If the mobile access gateway on the access link, receives a Router 2587 Solicitation message from the mobile node, before it completed the 2588 signaling with the mobile node's local mobility anchor, the mobile 2589 access gateway may not know the mobile node's home network prefix and 2590 may not be able to emulate the mobile node's home link on the access 2591 link. In such scenario, the mobile node may notice a slight delay 2592 before it receives a Router Advertisement message. 2594 If the received Router Advertisement has the Managed Address 2595 Configuration flag set, the mobile node, as it would normally do, 2596 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2597 enabled on that access link will ensure the mobile node will obtain 2598 its IPv6 address as a lease from its home network prefix. 2600 If the received Router Advertisement does not have the Managed 2601 Address Configuration flag set and if the mobile node is allowed to 2602 use an autoconfigured address, the mobile node will be able to obtain 2603 an IPv6 address using an interface identifier generated as per the 2604 Autoconf specification [RFC-4862] or as per the Privacy Extensions 2605 specification [RFC-4941]. 2607 If the mobile node is IPv4 enabled and if the network permits, it 2608 will be able to obtain the IPv4 address configuration as specified in 2609 the companion document [ID-IPV4-PMIP6]. 2611 Once the address configuration is complete, the mobile node can 2612 continue to use this address configuration as long as it is attached 2613 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2615 7.2. Roaming in the Proxy Mobile IPv6 Domain 2617 After obtaining the address configuration in the Proxy Mobile IPv6 2618 domain, as the mobile node moves and changes its point of attachment 2619 from one mobile access gateway to the other, it can still continue to 2620 use the same address configuration. As long as the attached access 2621 network is in the scope of that Proxy Mobile IPv6 domain, the mobile 2622 node will always detect the same link, where it obtained its initial 2623 address configuration. If the mobile node performs DHCP operation, 2624 it will always obtain the same address as before. 2626 However, the mobile node will always detect a new default-router on 2627 each connected link, but still advertising the mobile node's home 2628 network prefix as the on-link prefix and with the other configuration 2629 parameters consistent with its home link properties. 2631 8. Message Formats 2633 This section defines extensions to the Mobile IPv6 [RFC-3775] 2634 protocol messages. 2636 8.1. Proxy Binding Update Message 2638 0 1 2 3 2639 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 2640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2641 | Sequence # | 2642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2643 |A|H|L|K|M|R|P| Reserved | Lifetime | 2644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2645 | | 2646 . . 2647 . Mobility options . 2648 . . 2650 | | 2651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2653 A Binding Update message that is sent by a mobile access gateway to a 2654 local mobility anchor is referred to as the "Proxy Binding Update" 2655 message. A new flag (P) is included in the Binding Update message. 2656 The rest of the Binding Update message format remains the same as 2657 defined in [RFC-3775] and with the additional (R) and (M) flags as 2658 specified in [RFC-3963] and [RFC-4140] respectively. 2660 Proxy Registration Flag (P) 2661 A new flag (P) is included in the Binding Update message to 2662 indicate to the local mobility anchor that the Binding Update 2663 message is a proxy registration. The flag MUST be set to the 2664 value of 1 for proxy registrations and MUST be set to 0 for direct 2665 registrations sent by a mobile node. 2667 Mobility Options 2669 Variable-length field of such length that the complete Mobility 2670 Header is an integer multiple of 8 octets long. This field 2671 contains zero or more TLV-encoded mobility options. The encoding 2672 and format of defined options are described in Section 6.2 [RFC- 2673 3775]. The local mobility anchor MUST ignore and skip any options 2674 which it does not understand. 2676 As per this specification, the following mobility options are 2677 valid in a Proxy Binding Update message: 2679 Mobile Node Identifier option 2681 Home Network Prefix option 2683 Handoff Indicator option 2685 Access Technology Type option 2687 Timestamp option 2689 Mobile Node Interface Identifier option 2691 Link-local Address option 2693 For descriptions of other fields present in this message, refer to 2694 section 6.1.7 [RFC-3775]. 2696 8.2. Proxy Binding Acknowledgement Message 2698 0 1 2 3 2699 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 2700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2701 | Status |K|R|P|Reserved | 2702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2703 | Sequence # | Lifetime | 2704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2705 | | 2706 . . 2707 . Mobility options . 2708 . . 2709 | | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 A Binding Acknowledgement message that is sent by a local mobility 2713 anchor to a mobile access gateway is referred to as the "Proxy 2714 Binding Acknowledgement" message. A new flag (P) is included in the 2715 Binding Acknowledgement message. The rest of the Binding 2716 Acknowledgement message format remains the same as defined in [RFC- 2717 3775] and with the additional (R) and (M) flags as specified in [RFC- 2718 3963] and [RFC-4140] respectively. 2720 Proxy Registration Flag (P) 2722 A new flag (P) is included in the Binding Acknowledgement message 2723 to indicate that the local mobility anchor that processed the 2724 corresponding Proxy Binding Update message supports proxy 2725 registrations. The flag is set only if the corresponding Proxy 2726 Binding Update had the Proxy Registration Flag (P) set to value of 2727 1. 2729 Mobility Options 2731 Variable-length field of such length that the complete Mobility 2732 Header is an integer multiple of 8 octets long. This field 2733 contains zero or more TLV-encoded mobility options. The encoding 2734 and format of defined options are described in Section 6.2 [RFC- 2735 3775]. The mobile access gateway MUST ignore and skip any options 2736 which it does not understand. 2738 As per this specification, the following mobility options are 2739 valid in a Proxy Binding Acknowledgement message: 2741 Mobile Node Identifier option 2743 Home Network Prefix option 2745 Handoff Indicator option 2747 Access Technology Type option 2749 Timestamp option 2751 Mobile Node Interface Identifier option 2753 Link-local Address option 2755 Status 2757 8-bit unsigned integer indicating the disposition of the Proxy 2758 Binding Update. Values of the Status field less than 128 indicate 2759 that the Proxy Binding Update was accepted by the local mobility 2760 anchor. Values greater than or equal to 128 indicate that the 2761 binding registration was rejected by the local mobility anchor. 2762 Section 8.9 defines the Status values that can used in Proxy 2763 Binding Acknowledgement message. 2765 For descriptions of other fields present in this message, refer to 2766 the section 6.1.8 [RFC-3775]. 2768 8.3. Home Network Prefix Option 2770 A new option, Home Network Prefix Option is defined for using it in 2771 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2772 exchanged between a local mobility anchor and a mobile access 2773 gateway. This option is used for exchanging the mobile node's home 2774 network prefix information. 2776 The Home Network Prefix Option has an alignment requirement of 8n+4. 2777 Its format is as follows: 2779 0 1 2 3 2780 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 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Type | Length | Reserved | Prefix Length | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2784 | | 2785 + + 2786 | | 2787 + Home Network Prefix + 2788 | | 2789 + + 2790 | | 2791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2793 Type 2794 2796 Length 2798 8-bit unsigned integer indicating the length of the option 2799 in octets, excluding the type and length fields. This field 2800 MUST be set to 18. 2802 Reserved (R) 2804 This 8-bit field is unused for now. The value MUST be 2805 initialized to 0 by the sender and MUST be ignored by the 2806 receiver. 2808 Prefix Length 2810 8-bit unsigned integer indicating the prefix length of the 2811 IPv6 prefix contained in the option. 2813 Home Network Prefix 2815 A sixteen-byte field containing the mobile node's IPv6 Home 2816 Network Prefix. 2818 8.4. Handoff Indicator Option 2820 A new option, Handoff Indicator Option is defined for using it in the 2821 Proxy Binding Update and Proxy Binding Acknowledgement messages 2822 exchanged between a local mobility anchor and a mobile access 2823 gateway. This option is used for exchanging the mobile node's 2824 handoff related hints. 2826 The Handoff Indicator Option has no alignment requirement. Its 2827 format is as follows: 2829 0 1 2 3 2830 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 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 | Type | Length | Reserved (R) | HI | 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 Type 2836 2838 Length 2840 8-bit unsigned integer indicating the length of the option 2841 in octets, excluding the type and length fields. This field 2842 MUST be set to 2. 2844 Reserved (R) 2846 This 8-bit field is unused for now. The value MUST be 2847 initialized to 0 by the sender and MUST be ignored by the 2848 receiver. 2850 Handoff Indicator (HI) 2852 A 8-bit field that specifies the type of handoff. The values 2853 (0 - 255) will be allocated and managed by IANA. The following 2854 values are currently reserved. 2856 0: Reserved 2857 1: Attachment over a new interface 2858 2: Handoff between two different interfaces of the mobile node 2859 3: Handoff between mobile access gateways for the same interface 2860 4: Handoff state unknown 2861 5: Handoff state not changed (Re-registration) 2863 8.5. Access Technology Type Option 2865 A new option, Access Technology Type Option is defined for using it 2866 in the Proxy Binding Update and Proxy Binding Acknowledgement 2867 messages exchanged between a local mobility anchor and a mobile 2868 access gateway. This option is used for exchanging the type of the 2869 access technology using which the mobile node is currently attached 2870 to the mobile access gateway. 2872 The Access Technology Type Option has no alignment requirement. Its 2873 format is as follows: 2875 0 1 2 3 2876 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 2877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2878 | Type | Length | Reserved (R) | ATT | 2879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2881 Type 2882 2884 Length 2886 8-bit unsigned integer indicating the length of the option 2887 in octets, excluding the type and length fields. This field 2888 MUST be set to 2. 2890 Reserved (R) 2892 This 8-bit field is unused for now. The value MUST be 2893 initialized to 0 by the sender and MUST be ignored by the 2894 receiver. 2896 Access Technology Type (ATT) 2898 A 8-bit field that specifies the access technology through 2899 which the mobile node is connected to the access link on the 2900 mobile access gateway. 2902 The values (0 - 255) will be allocated and managed by IANA. The 2903 following values are currently reserved for the below specified 2904 access technology types. 2906 0: Reserved 2907 1: Virtual 2908 2: PPP 2909 3: 802.3 (Ethernet) 2910 4: 802.11a/b/g 2911 5: 802.16e 2913 8.6. Mobile Node Interface Identifier Option 2915 A new option, Mobile Node Interface Identifier Option is defined for 2916 using it in the Proxy Binding Update and Proxy Binding 2917 Acknowledgement messages exchanged between a local mobility anchor 2918 and a mobile access gateway. This option is used for exchanging the 2919 mobile node's interface identifier. 2921 The format of the Interface Identifier option when the interface 2922 identifier is 8 bytes is shown below. When the size is different, 2923 the option MUST be aligned appropriately, as per mobility option 2924 alignment requirements specified in [RFC-3775]. 2926 0 1 2 3 2927 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 2928 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2929 | Type | Length | Reserved | 2930 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2931 | | 2932 + Interface Identifier + 2933 . ... . 2934 | | 2935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2937 Type 2938 2940 Length 2941 8-bit unsigned integer indicating the length of the option 2942 in octets, excluding the type and length fields. 2944 Reserved 2946 This field is unused for now. The value MUST be initialized to 2947 0 by the sender and MUST be ignored by the receiver. 2949 Interface Identifier 2951 A variable length field containing the mobile node's interface 2952 identifier. 2954 The content and format of this field (including byte and bit 2955 ordering) is as specified in Section 4.6 [RFC-4861] for 2956 carrying Link-Layer Address. 2958 8.7. Link-local Address Option 2960 A new option, Link-local Address Option is defined for using it in 2961 the Proxy Binding Update and Proxy Binding Acknowledgement messages 2962 exchanged between a local mobility anchor and a mobile access 2963 gateway. This option is used for exchanging the mobile node's link- 2964 local address. 2966 The Link-local Address option has an alignment requirement of 8n+6. 2967 Its format is as follows: 2969 0 1 2 3 2970 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 2971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2972 | Type | Length | 2973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2974 | | 2975 + + 2976 | | 2977 + Link-local Address + 2978 | | 2979 + + 2980 | | 2981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2983 Type 2984 2986 Length 2988 8-bit unsigned integer indicating the length of the option 2989 in octets, excluding the type and length fields. This field 2990 MUST be set to 16. 2992 Link-local Address 2994 A sixteen-byte field containing the mobile node's link-local 2995 address. 2997 8.8. Timestamp Option 2999 A new option, Timestamp Option is defined for use in the Proxy 3000 Binding Update and Proxy Binding Acknowledgement messages. 3002 The Timestamp option has an alignment requirement of 8n+2. Its 3003 format is as follows: 3005 0 1 2 3 3006 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 3007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3008 | Type | Length | 3009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3010 | | 3011 + Timestamp + 3012 | | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 Type 3016 3018 Length 3020 8-bit unsigned integer indicating the length in octets of 3021 the option, excluding the type and length fields. The value 3022 for this field MUST be set to 8. 3024 Timestamp 3026 A 64-bit unsigned integer field containing a timestamp. The value 3027 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3028 by using a fixed point format. In this format, the integer number 3029 of seconds is contained in the first 48 bits of the field, and the 3030 remaining 16 bits indicate the number of 1/65536 fractions of a 3031 second. 3033 8.9. Status Values 3035 This document defines the following new Status values for use in 3036 Proxy Binding Acknowledgement message. These values are to be 3037 allocated from the same number space, as defined in Section 6.1.8 3038 [RFC-3775]. 3040 Status values less than 128 indicate that the Proxy Binding Update 3041 request was accepted by the local mobility anchor. Status values 3042 greater than 128 indicate that the Proxy Binding Update was rejected 3043 by the local mobility anchor. 3045 PROXY_REG_NOT_ENABLED: 3047 Proxy registration not enabled for the mobile node 3049 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: 3051 The mobile access gateway is not authorized to send proxy binding 3052 registrations 3054 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 3056 The mobile node is not authorized for the requesting home network 3057 prefix 3059 TIMESTAMP_MISMATCH: 3061 Invalid timestamp value (the clocks are out of sync) 3063 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: 3065 The timestamp value is lower than the previously accepted value 3067 MISSING_HOME_NETWORK_PREFIX_OPTION 3069 Missing home network prefix option 3071 MISSING_MN_IDENTIFIER_OPTION: 3073 Missing mobile node identifier option 3075 MISSING_HANDOFF_INDICATOR_OPTION 3077 Missing handoff indicator option 3079 MISSING_ACCESS_TECH_TYPE_OPTION 3081 Missing access technology type option 3083 Additionally, the following Status values defined in [RFC-3775] can 3084 also be used in Proxy Binding Acknowledgement message. 3086 0 Proxy Binding Update accepted 3088 128 Reason unspecified 3090 129 Administratively prohibited 3092 130 Insufficient resources 3094 133 Not local mobility anchor for this mobile node 3096 9. Protocol Configuration Variables 3098 The local mobility anchor MUST allow the following variables to be 3099 configured by the system management. 3101 MinDelayBeforeBCEDelete 3103 This variable specifies the amount of time in milliseconds the 3104 local mobility anchor MUST wait before it deletes a Binding Cache 3105 entry of a mobile node, upon receiving a Proxy Binding Update 3106 message from a mobile access gateway with a lifetime value of 0. 3107 During this wait time, if the local mobility anchor receives a 3108 Proxy Binding Update for the same mobility binding, with lifetime 3109 value greater than 0, then it must update the binding cache entry 3110 with the accepted binding values. By the end of this wait-time, 3111 if the local mobility anchor did not receive any valid Proxy 3112 Binding Update message for that mobility binding, it MUST delete 3113 the Binding Cache entry. This delay essentially ensures a mobile 3114 node's Binding Cache entry is not deleted too quickly and allows 3115 some time for the new mobile access gateway to complete the 3116 signaling for the mobile node. 3118 The default value for this variable is 10000 milliseconds. 3120 MaxDelayBeforeNewBCEAssign 3122 This variable specifies the amount of time in milliseconds the 3123 local mobility anchor MUST wait for the de-registration message 3124 for an existing mobility session before it decides to create a new 3125 mobility session. 3127 The default value for this variable is 500 milliseconds. 3129 TimestampValidityWindow 3131 This variable specifies the maximum amount of time difference in 3132 milliseconds between the timestamp in the received Proxy Binding 3133 Update message and the current time-of-day on the local mobility 3134 anchor, that is allowed by the local mobility anchor for the 3135 received message to be considered valid. 3137 The default value for this variable is 300 milliseconds. This 3138 variable MUST be adjusted to suit the deployments. 3140 The mobile access gateway MUST allow the following variables to be 3141 configured by the system management. 3143 EnableMAGLocalrouting 3145 This flag indicates whether or not the mobile access gateway is 3146 allowed to enable local routing of the traffic exchanged between a 3147 visiting mobile node and a correspondent node that is locally 3148 connected to one of the interfaces of the mobile access gateway. 3149 The correspondent node can be another visiting mobile node as 3150 well, or a local fixed node. 3152 The default value for this flag is set to "FALSE", indicating that 3153 the mobile access gateway MUST reverse tunnel all the traffic to 3154 the mobile node's local mobility anchor. 3156 When the value of this flag is set to "TRUE", the mobile access 3157 gateway MUST route the traffic locally. 3159 This aspect of local routing MAY be defined as policy on a per 3160 mobile basis and when present will take precedence over this flag. 3162 10. IANA Considerations 3164 This document defines six new Mobility Header options, the Home 3165 Network Prefix option, Handoff Indicator option, Access Technology 3166 Type option, Interface Identifier option, Link-local Address option 3167 and Timestamp option. These options are described in Section 8. The 3168 Type value for these options needs to be assigned from the same 3169 numbering space as allocated for the other mobility options, as 3170 defined in [RFC-3775]. 3172 The Access Technology Type option defined in Section 8.5 of this 3173 document introduces a new Access Technology type numbering space, 3174 where the values from 0 to 5 have been reserved by this document. 3175 Approval of new Access Technology type numbers are to be made through 3176 IANA Expert Review. 3178 This document also defines new Binding Acknowledgement status values 3179 as described in Section 8.9. The status values MUST be assigned from 3180 the same number space used for Binding Acknowledgement status values, 3181 as defined in [RFC-3775]. The allocated values for each of these 3182 status values MUST be greater than 128. 3184 11. Security Considerations 3186 The potential security threats against any network-based mobility 3187 management protocol are described in [RFC-4832]. This section 3188 explains how Proxy Mobile IPv6 protocol defends itself against those 3189 threats. 3191 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3192 Binding Update and Proxy Binding Acknowledgement, exchanged between 3193 the mobile access gateway and the local mobility anchor to be 3194 protected using IPsec, using the established security association 3195 between them. This essentially eliminates the threats related to the 3196 impersonation of the mobile access gateway or the local mobility 3197 anchor. 3199 This specification allows a mobile access gateway to send binding 3200 registration messages on behalf of a mobile node. If proper 3201 authorization checks are not in place, a malicious node may be able 3202 to hijack a mobile node's session or may carry out a denial-of- 3203 service attack. To prevent this attack, this specification requires 3204 the local mobility anchor to allow only authorized mobile access 3205 gateways that are part of that Proxy Mobile IPv6 domain to send 3206 binding registration messages on behalf of a mobile node. 3208 To eliminate the threats on the interface between the mobile access 3209 gateway and the mobile node, this specification requires an 3210 established trust between the mobile access gateway and the mobile 3211 node and to authenticate and authorize the mobile node before it is 3212 allowed to access the network. Further, the established 3213 authentication mechanisms enabled on that access link will ensure 3214 that there is a secure binding between the mobile node's identity and 3215 its link-layer address. The mobile access gateway will definitively 3216 identify the mobile node from the packets that it receives on that 3217 access link. 3219 To address the threat related to a compromised mobile access gateway, 3220 the local mobility anchor, before accepting a Proxy Binding Update 3221 message for a given mobile node, may ensure that the mobile node is 3222 definitively attached to the mobile access gateway that sent the 3223 proxy binding registration request. This may be accomplished by 3224 contacting a trusted entity which is able to track the mobile node's 3225 current point of attachment. However, the specific details of the 3226 actual mechanisms for achieving this is outside the scope of this 3227 document. 3229 12. Acknowledgements 3231 The authors would like to specially thank Julien Laganier, Christian 3232 Vogt, Pete McCann, Brian Haley, Ahmad Muhanna, JinHyeock Choi for 3233 their thorough review of this document. 3235 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3236 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3237 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3238 Soliman, James Kempf, Jari Arkko, Jean-Michel Combes, John Zhao, 3239 Jong-Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3240 Weniger, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, Phil 3241 Roberts, Ryuji Wakikawa, Sangjin Jeong, Suresh Krishnan, Ved Kafle, 3242 Vidya Narayanan, Youn-Hee Han and many others for their passionate 3243 discussions in the working group mailing list on the topic of 3244 localized mobility management solutions. These discussions 3245 stimulated much of the thinking and shaped the draft to the current 3246 form. We acknowledge that ! 3248 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3249 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 3250 Tim Stammers for their input on this document. 3252 13. References 3254 13.1. Normative References 3256 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3257 Requirement Levels", BCP 14, RFC 2119, March 1997. 3259 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3260 IPv6 Specification", RFC 2473, December 1998. 3262 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3263 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3264 RFC 3315, July 2003. 3266 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3267 IPv6", RFC 3775, June 2004. 3269 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3270 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3271 January 2005. 3273 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3274 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3275 November 2005. 3277 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3278 Internet Protocol", RFC 4301, December 2005. 3280 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3281 4303, December 2005. 3283 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3284 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3285 2007. 3287 13.2. Informative References 3289 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 3290 51, RFC 1661, July 1994. 3292 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3293 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3294 2005. 3296 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3297 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3298 4140, August 2005. 3300 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3301 Protocol", RFC 4306, December 2005. 3303 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3304 for IPv4, IPv6 and OSI", RFC 2030, October 1996. 3306 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3307 "Chargeable User Identity", RFC 4372, January 2006. 3309 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3310 G., Liebsch, M., "Problem Statement for Network-based Localized 3311 Mobility Management", September 2006. 3313 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3314 G., Liebsch, M., "Goals for Network-based Localized Mobility 3315 Management", October 2006. 3317 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3318 Localized Mobility Management", September 2006. 3320 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3321 Address Autoconfiguration", RFC 4862, September 2007. 3323 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3324 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3325 2007. 3327 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3328 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3329 November 2007. 3331 [ID-DNAV6] Kempf, J., et al "Detecting Network Attachment in IPv6 3332 Networks (DNAv6)", draft-ietf-dna-protocol-06.txt, October 2006. 3334 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3336 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3337 typically be identified by an identifier, MN-Identifier, and that 3338 identifier will have an associated policy profile that identifies the 3339 mobile node's home network prefix, permitted address configuration 3340 modes, roaming policy and other parameters that are essential for 3341 providing network-based mobility service. This information is 3342 typically configured in AAA. It is possible the home network prefix 3343 is dynamically allocated for the mobile node when it boots up for the 3344 first time in the network, or it could be a statically configured 3345 value on per mobile node basis. However, for all practical purposes, 3346 the network entities in the proxy Mobile IPv6 domain, while serving a 3347 mobile node will have access to this profile and these entities can 3348 query this information using RADIUS/DIAMETER protocols. 3350 Appendix B. Supporting Shared-Prefix Model using DHCPv6 3352 This specification supports Per-MN-Prefix model. However, it is 3353 possible to support Shared-Prefix model under the following 3354 guidelines. 3356 The mobile node is allowed to use stateful address configuration 3357 using DHCPv6 for obtaining its address configuration. The mobile 3358 node is not allowed to use any of the stateless autoconfiguration 3359 techniques. The permitted address configuration models for the 3360 mobile node on the access link can be enforced by the mobile access 3361 gateway, by setting the relevant flags in the Router Advertisements, 3362 as per [RFC-4861]. 3364 The Home Network Prefix option that is sent by the mobile access 3365 gateway in the Proxy Binding Update message, must contain the 128-bit 3366 host address that the mobile node obtained via DHCPv6. 3368 Routing state at the mobile access gateway: 3370 For all IPv6 traffic from the source MN-HoA::/128 to 3371 _ANY_DESTINATION_, route via tunnel0, next-hop LMAA, where tunnel0 is 3372 the MAG to LMA tunnel. 3374 Routing state at the local mobility anchor: 3376 For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, 3377 next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. 3379 Appendix C. Routing State 3381 The following section explains the routing state for a mobile node on 3382 the mobile access gateway. This routing state reflects only one 3383 specific way of implementation and one MAY choose to implement it in 3384 other ways. The policy based route defined below acts as a traffic 3385 selection rule for routing a mobile node's traffic through a specific 3386 tunnel created between the mobile access gateway and that mobile 3387 node's local mobility anchor and with the specific encapsulation 3388 mode, as negotiated. 3390 The below example identifies the routing state for two visiting 3391 mobile nodes, MN1 and MN2 with their respective local mobility 3392 anchors LMA1 and LMA2. 3394 For all traffic from the mobile node, identified by the mobile node's 3395 MAC address, ingress interface or source prefix (MN-HNP) to 3396 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3398 +==================================================================+ 3399 | Packet Source | Destination Address | Destination Interface | 3400 +==================================================================+ 3401 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3402 | (IPv6 Prefix or |----------------------------------------------| 3403 | Input Interface) | Locally Connected | Tunnel0 | 3404 +------------------------------------------------------------------+ 3405 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3406 + (IPv6 Prefix or -----------------------------------------------| 3407 | Input Interface | Locally Connected | direct | 3408 +------------------------------------------------------------------+ 3410 Figure 22: Example - Policy based Route Table 3412 +==================================================================+ 3413 | Interface | Source Address | Destination Address | Encapsulation | 3414 +==================================================================+ 3415 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3416 +------------------------------------------------------------------+ 3417 | Tunnel1 |IPv4-Proxy-CoA | IPv4-LMA2 | IPv6-in-IPv4 | 3418 +------------------------------------------------------------------+ 3420 Figure 23: Example - Tunnel Interface Table 3422 Authors' Addresses 3424 Sri Gundavelli 3425 Cisco 3426 170 West Tasman Drive 3427 San Jose, CA 95134 3428 USA 3430 Email: sgundave@cisco.com 3432 Kent Leung 3433 Cisco 3434 170 West Tasman Drive 3435 San Jose, CA 95134 3436 USA 3438 Email: kleung@cisco.com 3439 Vijay Devarapalli 3440 Azaire Networks 3441 4800 Great America Pkwy 3442 Santa Clara, CA 95054 3443 USA 3445 Email: vijay.devarapalli@azairenet.com 3447 Kuntal Chowdhury 3448 Starent Networks 3449 30 International Place 3450 Tewksbury, MA 3452 Email: kchowdhury@starentnetworks.com 3454 Basavaraj Patil 3455 Nokia Siemens Networks 3456 6000 Connection Drive 3457 Irving, TX 75039 3458 USA 3460 Email: basavaraj.patil@nsn.com 3462 Full Copyright Statement 3464 Copyright (C) The IETF Trust (2008). 3466 This document is subject to the rights, licenses and restrictions 3467 contained in BCP 78, and except as set forth therein, the authors 3468 retain all their rights. 3470 This document and the information contained herein are provided on an 3471 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3472 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3473 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3474 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3475 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3476 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3478 Intellectual Property 3480 The IETF takes no position regarding the validity or scope of any 3481 Intellectual Property Rights or other rights that might be claimed to 3482 pertain to the implementation or use of the technology described in 3483 this document or the extent to which any license under such rights 3484 might or might not be available; nor does it represent that it has 3485 made any independent effort to identify any such rights. Information 3486 on the procedures with respect to rights in RFC documents can be 3487 found in BCP 78 and BCP 79. 3489 Copies of IPR disclosures made to the IETF Secretariat and any 3490 assurances of licenses to be made available, or the result of an 3491 attempt made to obtain a general license or permission for the use of 3492 such proprietary rights by implementers or users of this 3493 specification can be obtained from the IETF on-line IPR repository at 3494 http://www.ietf.org/ipr. 3496 The IETF invites any interested party to bring to its attention any 3497 copyrights, patents or patent applications, or other proprietary 3498 rights that may cover technology that may be required to implement 3499 this standard. Please address the information to the IETF at 3500 ietf-ipr@ietf.org. 3502 Acknowledgment 3504 Funding for the RFC Editor function is provided by the IETF 3505 Administrative Support Activity (IASA).