idnits 2.17.1 draft-ietf-netlmm-proxymip6-16.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 3970. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3981. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3994. 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 (May 21, 2008) is 5790 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 normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-02 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-07 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 14 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: November 22, 2008 V. Devarapalli 6 Wichorus 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 May 21, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-16.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 November 22, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 Network-based mobility management enables IP mobility for a host 48 without requiring its participation in any mobility related 49 signaling. The Network is responsible for managing IP mobility on 50 behalf of the host. The mobility entities in the network are 51 responsible for tracking the movements of the host and initiating the 52 required mobility signaling on its behalf. This specification 53 describes a network-based mobility management protocol and is 54 referred to as Proxy Mobile IPv6. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 60 2.1. Conventions used in this document . . . . . . . . . . . . 5 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 9 63 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 15 64 4.1. Peer Authorization Database (PAD) Example Entries . . . . 16 65 4.2. Security Policy Database (SPD) Example Entries . . . . . . 17 66 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 17 67 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 18 68 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 19 69 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 20 70 5.3.1. Processing Binding Registrations . . . . . . . . . . . 20 71 5.3.2. Initial Binding Registration (New Mobility Session) . 22 72 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23 73 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24 74 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 24 75 5.3.6. Constructing the Proxy Binding Acknowledgement 76 Message . . . . . . . . . . . . . . . . . . . . . . . 25 77 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 27 78 5.4.1. Binding Cache entry lookup considerations . . . . . . 28 79 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 33 80 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36 82 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 37 83 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels . . . 38 84 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 39 85 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 39 86 5.9. Route Optimization Considerations . . . . . . . . . . . . 40 87 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 40 88 6.1. Extensions to Binding Update List Entry Data Structure . . 41 89 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 42 90 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42 91 6.4. Supported Address Configuration Modes . . . . . . . . . . 43 92 6.5. Access Authentication & Mobile Node Identification . . . . 44 93 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 44 94 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 45 95 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 45 96 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 46 97 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 46 98 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 55 99 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 56 100 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 56 101 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 57 102 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 58 103 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 59 104 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 59 105 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 60 106 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 60 107 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 60 108 6.11. Supporting DHCP based Address Configuration on the 109 Access Link . . . . . . . . . . . . . . . . . . . . . . . 62 110 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 64 111 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 64 112 6.14. Allowing network access to other IPv6 nodes . . . . . . . 65 113 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 66 114 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 66 115 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 67 116 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 67 117 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 68 118 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 69 119 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 71 120 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 72 121 8.5. Access Technology Type Option . . . . . . . . . . . . . . 73 122 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 75 123 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 76 124 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 77 125 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 77 126 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 79 127 9.1. Local Mobility Anchor - Configuration Variables . . . . . 79 128 9.2. Mobile Access Gateway - Configuration Variables . . . . . 80 129 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 81 130 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 81 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . 82 132 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 83 133 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 83 134 13.1. Normative References . . . . . . . . . . . . . . . . . . . 84 135 13.2. Informative References . . . . . . . . . . . . . . . . . . 84 136 Appendix A. Proxy Mobile IPv6 interactions with AAA 137 Infrastructure . . . . . . . . . . . . . . . . . . . 86 138 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 86 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 87 140 Intellectual Property and Copyright Statements . . . . . . . . . . 89 142 1. Introduction 144 IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. 145 Mobile IPv6 requires client functionality in the IPv6 stack of a 146 mobile node. Exchange of signaling messages between the mobile node 147 and home agent enables the creation and maintenance of a binding 148 between the mobile node's home address and its care-of-address. 149 Mobility as specified in [RFC-3775] requires the IP host to send IP 150 mobility management signaling messages to the home agent, which is 151 located in the network. 153 Network-based mobility is another approach to solving the IP mobility 154 challenge. It is possible to support mobility for IPv6 nodes without 155 host involvement by extending Mobile IPv6 [RFC-3775] signaling 156 messages between a network node and a home agent. This approach to 157 supporting mobility does not require the mobile node to be involved 158 in the exchange of signaling messages between itself and the home 159 agent. A proxy mobility agent in the network performs the signaling 160 with the home agent and does the mobility management on behalf of the 161 mobile node attached to the network. Because of the use and 162 extension of Mobile IPv6 signaling and home agent functionality, this 163 protocol is referred to as Proxy Mobile IPv6 (PMIPv6). 165 Network deployments which are designed to support mobility would be 166 agnostic to the capability in the IPv6 stack of the nodes which it 167 serves. IP mobility for nodes which have mobile IP client 168 functionality in the IPv6 stack as well as those nodes which do not, 169 would be supported by enabling Proxy Mobile IPv6 protocol 170 functionality in the network. The advantages of developing a network 171 based mobility protocol based on Mobile IPv6 are: 173 o Reuse of home agent functionality and the messages/format used in 174 mobility signaling. Mobile IPv6 is a mature protocol with several 175 implementations that have undergone interoperability testing. 177 o A common home agent would serve as the mobility agent for all 178 types of IPv6 nodes. 180 The problem statement and the need for a network based mobility 181 protocol solution has been documented in [RFC-4830]. Proxy Mobile 182 IPv6 is a solution that addresses these issues and requirements. 184 2. Conventions & Terminology 185 2.1. Conventions used in this document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 189 document are to be interpreted as described in RFC 2119 [RFC-2119]. 191 2.2. Terminology 193 All the general mobility related terms used in this document are to 194 be interpreted as defined in the Mobile IPv6 base specification [RFC- 195 3775]. 197 This document adopts the terms, Local Mobility Anchor (LMA) and 198 Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- 199 4831]. This document also provides the following context specific 200 explanation to the following terms used in this document. 202 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 204 Proxy Mobile IPv6 domain refers to the network where the mobility 205 management of a mobile node is handled using the Proxy Mobile IPv6 206 protocol as defined in this specification. The Proxy Mobile IPv6 207 domain includes local mobility anchors and mobile access gateways 208 between which security associations can be set up and 209 authorization for sending Proxy Binding Updates on behalf of the 210 mobile nodes can be ensured. 212 Local Mobility Anchor (LMA) 214 Local Mobility Anchor is the home agent for the mobile node in a 215 Proxy Mobile IPv6 domain. It is the topological anchor point for 216 the mobile node's home network prefix(es) and is the entity that 217 manages the mobile node's binding state. The local mobility 218 anchor has the functional capabilities of a home agent as defined 219 in Mobile IPv6 base specification [RFC-3775] with the additional 220 capabilities required for supporting Proxy Mobile IPv6 protocol as 221 defined in this specification. 223 Mobile Access Gateway (MAG) 225 Mobile Access Gateway is a function that manages the mobility 226 related signaling for a mobile node that is attached to its access 227 link. It is responsible for tracking the mobile node's movements 228 to and from the access link and for signaling the mobile node's 229 local mobility anchor. 231 Mobile Node (MN) 233 Throughout this document, the term mobile node is used to refer to 234 an IP host or router whose mobility is managed by the network. 235 The mobile node may be an IPv4-only node, IPv6-only node or a 236 dual-stack node and is not required to participate in any IP 237 mobility related signaling for achieving mobility for an IP 238 address that is obtained in that Proxy Mobile IPv6 domain. 240 LMA Address (LMAA) 242 The global address that is configured on the interface of the 243 local mobility anchor and is the transport endpoint of the bi- 244 directional tunnel established between the local mobility anchor 245 and the mobile access gateway. This is the address to where the 246 mobile access gateway sends the Proxy Binding Update messages. 247 When supporting IPv4 traversal, i.e., when the network between the 248 local mobility anchor and the mobile access gateway is an IPv4 249 network, this address will be an IPv4 address and will be referred 250 to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. 252 Proxy Care-of Address (Proxy-CoA) 254 Proxy-CoA is the global address configured on the interface of the 255 mobile access gateway and is the transport endpoint of the tunnel 256 between the local mobility anchor and the mobile access gateway. 257 The local mobility anchor views this address as the Care-of 258 Address of the mobile node and registers it in the Binding Cache 259 entry for that mobile node. When the transport network between 260 the mobile access gateway and the local mobility anchor is an IPv4 261 network and if the care-of address that is registered at the local 262 mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is 263 used, as specified in [ID-IPV4-PMIP6]. 265 Mobile Node's Home Network Prefix (MN-HNP) 267 The MN-HNP is a prefix assigned to the link between the mobile 268 node and the mobile access gateway. More than one prefix can be 269 assigned to the link between the mobile node and the mobile access 270 gateway, in which case, all of the assigned prefixes are managed 271 as a set associated with a mobility session. The mobile node 272 configures its interface with one or more addresses from its home 273 network prefix(es). If the mobile node connects to the Proxy 274 Mobile IPv6 domain through multiple interfaces, simultaneously, 275 each of the attached interfaces will be assigned a unique set of 276 home network prefixes and all the prefixes assigned to a given 277 interface of a mobile node will be managed under one mobility 278 session. Additionally, in some configurations the assigned prefix 279 can be of 128-bit prefix length. Ex: Home network prefixes P1, P2 280 assigned to interface I1 will be managed under one mobility 281 session and prefixes P3, P4, P5 assigned to interface I2 of the 282 mobile node will be managed under a different mobility session. 284 Mobile Node's Home Address (MN-HoA) 286 MN-HoA is an address from a mobile node's home network prefix. 287 The mobile node will be able to use this address as long as it is 288 attached to the access network that is in the scope of that Proxy 289 Mobile IPv6 domain. If the mobile node uses more than one address 290 from its home network prefix(es), any one of these addresses is 291 referred to as mobile node's home address. Unlike in Mobile IPv6 292 where the home agent is aware of the home address of the mobile 293 node, in Proxy Mobile IPv6, the mobility entities are only aware 294 of the mobile node's home network prefix(es) and are not always 295 aware of the exact address(es) that the mobile node configured on 296 its interface from its home network prefix(es). However, in some 297 configurations and based on the enabled address configuration 298 modes on the access link, the mobility entities in the network can 299 be certain about the exact address(es) configured by the mobile 300 node. 302 Mobile Node's Home Link 304 This is the link on which the mobile node obtained its Layer-3 305 address configuration for the attached interface after it moved 306 into that Proxy Mobile IPv6 domain. This is the link that 307 conceptually follows the mobile node. The network will ensure the 308 mobile node always sees this link with respect to the layer-3 309 network configuration, on any access link that it attaches to in 310 that Proxy Mobile IPv6 domain. 312 Multihomed Mobile Node 314 A mobile node that connects to the same Proxy Mobile IPv6 domain 315 through more than one interface and uses these interfaces 316 simultaneously is referred to as a multihomed mobile node. 318 Mobile Node Identifier (MN-Identifier) 320 The identity of a mobile node in the Proxy Mobile IPv6 domain. 321 This is the stable identifier of a mobile node that the mobility 322 entities in a Proxy Mobile IPv6 domain can always acquire and use 323 it for predictably identifying a mobile node. This is typically 324 an identifier such as Network Access Identifier (NAI) [RFC-4282] 325 or other identifier such as a Media Access Control (MAC) address. 327 Mobile Node Link-layer Identifier (MN-LL-Identifier) 329 An identifier that identifies the attached interface of a mobile 330 node. For those interfaces that have a link-layer identifier, 331 this identifier can be based on that. The link-layer identifier 332 in some cases is generated by the mobile node and conveyed to the 333 mobile access gateway. This identifier of the attached interface 334 must be stable as seen by any of the mobile access gateways in a 335 given Proxy Mobile IPv6 domain. In some other cases, there might 336 not be any link-layer identifier associated with the mobile node's 337 interface. 339 Policy Profile 341 Policy Profile is an abstract term for referring to a set of 342 configuration parameters that are configured for a given mobile 343 node. The mobility entities in the Proxy Mobile IPv6 domain 344 require access to these parameters for providing the mobility 345 management to a given mobile node. The specific details on how 346 the network entities obtain this policy profile is outside the 347 scope of this document. 349 Proxy Binding Update (PBU) 351 A binding registration request message sent by a mobile access 352 gateway to a mobile node's local mobility anchor for establishing 353 a binding between the mobile node's home network prefix(es) 354 assigned to a given interface of a mobile node and its current 355 care-of address (Proxy-CoA). 357 Proxy Binding Acknowledgement (PBA) 359 A binding registration reply message sent by a local mobility 360 anchor in response to a Proxy Binding Update request message that 361 it received from a mobile access gateway. 363 Per-MN-Prefix & Shared-Prefix Models 365 The term, Per-MN-Prefix model, is used to refer to an addressing 366 model where there is a unique network prefix or prefixes assigned 367 for each node. The term, Shared-Prefix model, is used to refer to 368 an addressing model where the prefix(es) are shared by more than 369 one node. This specification supports the Per-MN-Prefix model and 370 does not support the Shared-Prefix model. 372 Mobility Session 373 In the context of Proxy Mobile IPv6 specification, the term 374 mobility session refers to the creation or existence of state 375 associated with the mobile node's mobility binding on the local 376 mobility anchor and on the serving mobile access gateway. 378 DHCP 380 Throughout this document, the acronym DHCP refers to DHCP for 381 IPv6, as defined in [RFC-3315]. 383 ALL_ZERO & NON_ZERO 385 Protocol message fields initialized with value 0 in each byte of 386 the field. Ex: An 8-byte link-layer identifier field with the 387 value set to 0 in each of the 8 bytes, or an IPv6 address with the 388 value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is 389 used to refer to any value other than an ALL_ZERO value. 391 3. Proxy Mobile IPv6 Protocol Overview 393 This specification describes a network-based mobility management 394 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 395 [RFC-3775]. 397 Proxy Mobile IPv6 protocol is intended for providing network-based IP 398 mobility management support to a mobile node, without requiring the 399 participation of the mobile node in any IP mobility related 400 signaling. The mobility entities in the network will track the 401 mobile node's movements and will initiate the mobility signaling and 402 set up the required routing state. 404 The core functional entities in the NETLMM infrastructure are the 405 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 406 local mobility anchor is responsible for maintaining the mobile 407 node's reachability state and is the topological anchor point for the 408 mobile node's home network prefix(es). The mobile access gateway is 409 the entity that performs the mobility management on behalf of a 410 mobile node and it resides on the access link where the mobile node 411 is anchored. The mobile access gateway is responsible for detecting 412 the mobile node's movements to and from the access link and for 413 initiating binding registrations to the mobile node's local mobility 414 anchor. The architecture of a Proxy Mobile IPv6 domain is shown in 415 Figure 1. 417 +----+ +----+ 418 |LMA1| |LMA2| 419 +----+ +----+ 420 LMAA1 -> | | <-- LMAA2 421 | | 422 \\ //\\ 423 \\ // \\ 424 \\ // \\ 425 +---\\------------- //------\\----+ 426 ( \\ IPv4/IPv6 // \\ ) 427 ( \\ Network // \\ ) 428 +------\\--------//------------\\-+ 429 \\ // \\ 430 \\ // \\ 431 \\ // \\ 432 Proxy-CoA1--> | | <-- Proxy-CoA2 433 +----+ +----+ 434 |MAG1|-----{MN2} |MAG2| 435 +----+ | +----+ 436 | | | 437 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 438 {MN1} {MN3} 440 Figure 1: Proxy Mobile IPv6 Domain 442 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 443 an access link, the mobile access gateway on that access link, after 444 identifying the mobile node and acquiring its identity, will 445 determine if the mobile node is authorized for the network-based 446 mobility management service. 448 If the network determines that the network-based mobility management 449 service needs to be offered to that mobile node, the network will 450 ensure that the mobile node using any of the address configuration 451 mechanisms permitted by the network will be able to obtain the 452 address configuration on the connected interface and move anywhere in 453 that Proxy Mobile IPv6 domain. The obtained address configuration 454 includes the address(es) from its home network prefix(es), the 455 default-router address on the link and other related configuration 456 parameters. From the perspective of the mobile node, the entire 457 Proxy Mobile IPv6 domain appears as a single link, the network 458 ensures that the mobile node does not detect any change with respect 459 to its layer-3 attachment even after changing its point of attachment 460 in the network. 462 The mobile node may be an IPv4-only node, IPv6-only node or a dual 463 IPv4/IPv6 node. Based on what is enabled in the network for that 464 mobile node, the mobile node will be able to obtain an IPv4, IPv6 or 465 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 466 domain. However this specification only supports IPv6 address 467 mobility and when the transport network is IPv6 network. The support 468 for IPv4 addressing or IPv4 transport network is specified in the 469 companion document [ID-IPV4-PMIP6]. 471 If the mobile node connects to the Proxy Mobile IPv6 domain through 472 multiple interfaces and over multiple access networks, the network 473 will allocate a unique set of home network prefixes for each of the 474 connected interfaces. The mobile node will be able to configure 475 address(es) on those interfaces from the respective home network 476 prefix(es). However, if the mobile node performs an inter-interface 477 handoff by moving its address configuration from one interface to the 478 other and if the local mobility anchor receives a handoff hint from 479 the serving mobile access gateway about the same, the local mobility 480 anchor will assign the same home network prefix(es) that it 481 previously assigned prior to the handoff. The mobile node will also 482 be able to perform an handoff by changing its point of attachment 483 from one mobile access gateway to a different mobile access gateway 484 using the same interface and will be able to retain the address 485 configuration on the attached interface. 487 +-----+ +-----+ +-----+ 488 | MN | | MAG | | LMA | 489 +-----+ +-----+ +-----+ 490 | | | 491 MN Attached | | 492 | | | 493 | MN Attached Event from MN/Network | 494 | (Acquire MN-Id and Profile) | 495 | | | 496 |--- Rtr Sol --------->| | 497 | | | 498 | |--- PBU ------------->| 499 | | | 500 | | Accept PBU 501 | | (Allocate MN-HNP(s), Setup BCE and Tunnel) 502 | | | 503 | |<------------- PBA ---| 504 | | | 505 | Accept PBA | 506 | (Setup Tunnel and Routing) | 507 | | | 508 | |==== Bi-Dir Tunnel ===| 509 | | | 510 |<--------- Rtr Adv ---| | 511 | | | 512 IP Address | | 513 Configuration | | 514 | | | 516 Figure 2: Mobile Node Attachment - Signaling Call Flow 518 Figure 2 shows the signaling call flow when the mobile node enters 519 the Proxy Mobile IPv6 domain. The Router Solicitation message from 520 the mobile node may arrive at any time after the mobile node's 521 attachment and has no strict ordering relation with the other 522 messages in the call flow. 524 For updating the local mobility anchor about the current location of 525 the mobile node, the mobile access gateway sends a Proxy Binding 526 Update message to the mobile node's local mobility anchor. Upon 527 accepting this Proxy Binding Update message, the local mobility 528 anchor sends a Proxy Binding Acknowledgement message including the 529 mobile node's home network prefix(es). It also creates the Binding 530 Cache entry and sets up its endpoint of the bi-directional tunnel to 531 the mobile access gateway. 533 The mobile access gateway on receiving the Proxy Binding 534 Acknowledgement message sets up its endpoint of the bi-directional 535 tunnel to the local mobility anchor and also sets up the data path 536 for the mobile node's traffic. At this point the mobile access 537 gateway will have all the required information for emulating the 538 mobile node's home link. It sends Router Advertisement messages to 539 the mobile node on the access link advertising the mobile node's home 540 network prefix(es) as the hosted on-link-prefix(es). 542 The mobile node on receiving these Router Advertisement messages on 543 the access link will attempt to configure its interface either using 544 stateful or stateless address configuration modes, based on the modes 545 that are permitted on that access link. At the end of a successful 546 address configuration procedure, the mobile node will end up with one 547 or more addresses from its home network prefixes(es). 549 Once the address configuration is complete, the mobile node has one 550 or more valid addresses from its home network prefix(es) at the 551 current point of attachment. The serving mobile access gateway and 552 the local mobility anchor also have proper routing states for 553 handling the traffic sent to and from the mobile node using any one 554 or more of the addresses from its home network prefix(es). 556 The local mobility anchor, being the topological anchor point for the 557 mobile node's home network prefix(es), receives any packets that are 558 sent to the mobile node by any node in the network. The local 559 mobility anchor forwards these received packets to the mobile access 560 gateway through the bi-directional tunnel. The mobile access gateway 561 on other end of the tunnel, after receiving the packet, removes the 562 outer header and forwards the packet on the access link to the mobile 563 node. However, in some cases the traffic sent from a correspondent 564 node that is locally connected to the mobile access gateway may not 565 be received by the local mobility anchor and may be routed locally by 566 the mobile access gateway. 568 The mobile access gateway acts as the default router on the access 569 link. Any packet that the mobile node sends to any correspondent 570 node will be received by the mobile access gateway and will be sent 571 to its local mobility anchor through the bi-directional tunnel. The 572 local mobility anchor on the other end of the tunnel, after receiving 573 the packet, removes the outer header and routes the packet to the 574 destination. However in some cases the traffic sent to a 575 correspondent node that is locally connected to the mobile access 576 gateway may be locally routed by the mobile access gateway. 578 +-----+ +-----+ +-----+ +-----+ 579 | MN | |p-MAG| | LMA | |n-MAG| 580 +-----+ +-----+ +-----+ +-----+ 581 | | | | 582 | |==Bi-Dir Tunnel=| | 583 MN Detached | | | 584 | MN Detached Event | | 585 | | | | 586 | |-- DeReg PBU -->| | 587 | | | | 588 | | Accept PBU | 589 | | (Start MinDelayBeforeBCEDelete Timer) 590 | | | | 591 | |<-------- PBA --| | 592 | | | | 593 MN Attached | | | 594 | | | MN Attached event received 595 | | | from MN or from network 596 | | | (Acquire MN-Id and Profile) 597 | | | | 598 |--- Rtr Sol ------------------------------------->| 599 .... 600 Registration steps as in fig 2. 601 .... 602 | | |==Bi-Dir Tunnel=| 603 | | | | 604 |<------------------------------------ Rtr Adv ----| 605 | | | | 606 MN retains HoA/HNP(s) 607 | | | | 609 Figure 3: Mobile Node Handoff - Signaling Call Flow 611 Figure 3 shows the signaling call flow for the mobile node's handoff 612 from previously attached mobile access gateway (p-MAG) to the newly 613 attached mobile access gateway (n-MAG). This call flow reflects only 614 a specific message ordering, it is possible the registration message 615 from the n-MAG may arrive before the de-registration message from the 616 p-MAG arrives. 618 After obtaining the initial address configuration in the Proxy Mobile 619 IPv6 domain, if the mobile node changes its point of attachment, the 620 mobile access gateway on the previous link will detect the mobile 621 node's detachment from the link and will signal the local mobility 622 anchor and will remove the binding and routing state for that mobile 623 node. The local mobility anchor upon receiving this request will 624 identify the corresponding mobility session for which the binding 625 update request was received and once it accepts the request will wait 626 for certain amount of time for allowing the mobile access gateway on 627 the new link to update the binding. However, if it does not receive 628 any binding update request within that given amount of time, it will 629 delete the binding cache entry. 631 The mobile access gateway on the new access link upon detecting the 632 mobile node on its access link will signal the local mobility anchor 633 for updating the binding state. Once that signaling is complete, the 634 serving mobile access gateway will send the Router Advertisements 635 containing the mobile node's home network prefix(es) and this will 636 ensure the mobile node will not detect any change with respect to its 637 layer-3 attachment of its interface. 639 4. Proxy Mobile IPv6 Protocol Security 641 The signaling messages, Proxy Binding Update and Proxy Binding 642 Acknowledgement, exchanged between the mobile access gateway and the 643 local mobility anchor MUST be protected using end-to-end security 644 association(s) offering integrity and data origin authentication. 646 The mobile access gateway and the local mobility anchor MUST 647 implement IPsec for protecting the Proxy Mobile IPv6 signaling 648 messages [RFC-4301]. That is, IPsec is a mandatory to implement 649 security mechanism. However, additional documents may specify 650 alternative mechanisms and the mobility entities can enable a 651 specific mechanism for securing Proxy Mobile IPv6 signaling messages, 652 either based on a static configuration or after a dynamic negotiation 653 using any standard security negotiation protocols. As in Mobile IPv6 654 [RFC-3775], the use of IPsec for protecting mobile node's data 655 traffic is optional. 657 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 658 protection SHOULD be used for protecting the signaling messages. 659 Confidentiality protection of these messages is not required. 661 IPsec ESP [RFC-4303] in tunnel mode MAY be used to protect the mobile 662 node's tunneled data traffic, if protection of data traffic is 663 required. 665 IKEv2 [RFC-4306] SHOULD be used to set up security associations 666 between the mobile access gateway and the local mobility anchor to 667 protect the Proxy Binding Update and Proxy Binding Acknowledgement 668 messages. The mobile access gateway and the local mobility anchor 669 can use any of the authentication mechanisms, as specified in [RFC- 670 4306], for mutual authentication. 672 The Mobile IPv6 specification [RFC-3775] requires the home agent to 673 prevent a mobile node from creating security associations or creating 674 binding cache entries for another mobile node's home address. In the 675 protocol described in this document, the mobile node is not involved 676 in creating security associations for protecting the signaling 677 messages or sending binding updates. Therefore, the local mobility 678 anchor MUST restrict the creation and manipulation of proxy bindings 679 to specifically authorized mobile access gateways and prefixes. The 680 local mobility anchor MUST be locally configurable to authorize such 681 specific combinations. Additional mechanisms such as a policy store 682 or AAA may be employed, but these are outside the scope of this 683 specification. 685 Unlike in Mobile IPv6 [RFC-3775], these signaling messages do not 686 carry either the Home Address destination option or the Type 2 687 Routing header and hence the policy entries and security association 688 selectors stay the same and require no special IPsec related 689 considerations. 691 4.1. Peer Authorization Database (PAD) Example Entries 693 This section describes PAD entries [RFC-4301] on the mobile access 694 gateway and the local mobility anchor. The PAD entries are only 695 example configurations. Note that the PAD is a logical concept and a 696 particular mobile access gateway or a local mobility anchor 697 implementation can implement the PAD in any implementation specific 698 manner. The PAD state may also be distributed across various 699 databases in a specific implementation. 701 mobile access gateway PAD: 702 - IF remote_identity = lma_identity_1 703 Then authenticate (shared secret/certificate/EAP) 704 and authorize CHILD_SA for remote address lma_address_1 706 local mobility anchor PAD: 707 - IF remote_identity = mag_identity_1 708 Then authenticate (shared secret/certificate/EAP) 709 and authorize CHILD_SAs for remote address mag_address_1 711 Figure 4: PAD Entries 713 The list of authentication mechanisms in the above examples is not 714 exhaustive. There could be other credentials used for authentication 715 stored in the PAD. 717 4.2. Security Policy Database (SPD) Example Entries 719 This section describes the security policy entries [RFC-4301] on the 720 mobile access gateway and the local mobility anchor required to 721 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 722 are only example configurations. A particular mobile access gateway 723 or a local mobility anchor implementation could configure different 724 SPD entries as long as they provide the required security. 726 In the examples shown below, the identity of the mobile access 727 gateway is assumed to be mag_1, the address of the mobile access 728 gateway is assumed to be mag_address_1, and the address of the local 729 mobility anchor is assumed to be lma_address_1. 731 mobile access gateway SPD-S: 732 - IF local_address = mag_address_1 & 733 remote_address = lma_address_1 & 734 proto = MH & local_mh_type = BU & remote_mh_type = BA 735 Then use SA ESP transport mode 736 Initiate using IDi = mag_1 to address lma_address_1 738 local mobility anchor SPD-S: 739 - IF local_address = lma_address_1 & 740 remote_address = mag_address_1 & 741 proto = MH & local_mh_type = BA & remote_mh_type = BU 742 Then use SA ESP transport mode 744 Figure 5: SPD Entries 746 5. Local Mobility Anchor Operation 748 The local mobility anchor MUST support the home agent function as 749 defined in [RFC-3775] and additionally the extensions defined in this 750 specification. A home agent with these modifications and enhanced 751 capabilities for supporting the Proxy Mobile IPv6 protocol is 752 referred to as a local mobility anchor. 754 This section describes the operational details of the local mobility 755 anchor. 757 5.1. Extensions to Binding Cache Entry Data Structure 759 Every local mobility anchor MUST maintain a Binding Cache entry for 760 each currently registered mobile node. Binding Cache entry is a 761 conceptual data structure, described in Section 9.1 of [RFC-3775]. 763 For supporting this specification, the Binding Cache Entry data 764 structure needs to be extended with the following additional fields. 766 o A flag indicating whether or not this Binding Cache entry is 767 created due to a proxy registration. This flag is set to value 1 768 for Binding Cache entries that are proxy registrations and is set 769 to value 0 for all other entries. 771 o The identifier of the registered mobile node, MN-Identifier. This 772 identifier is obtained from the Mobile Node Identifier Option 773 [RFC-4283] present in the received Proxy Binding Update request. 775 o The link-layer identifier of the mobile node's connected interface 776 on the access link. This identifier can be acquired from the 777 Mobile Node Link-layer Identifier option, present in the received 778 Proxy Binding Update request. If the option was not present in 779 the request, this variable length field MUST be set to two 780 (octets) and MUST be initialized to a value of ALL_ZERO. 782 o The link-local address of the mobile access gateway on the point- 783 to-point link shared with the mobile node. This is generated by 784 the local mobility anchor after accepting the initial Proxy 785 Binding Update request. 787 o List of IPv6 home network prefixes assigned to the mobile node's 788 connected interface. The home network prefix(es) may have been 789 statically configured in the mobile node's policy profile, or, 790 they may have been dynamically allocated by the local mobility 791 anchor. Each one of these prefix entries will also includes the 792 corresponding prefix length. 794 o The tunnel interface identifier (If-Id) of the bi-directional 795 tunnel between the local mobility anchor and the mobile access 796 gateway where the mobile node is currently anchored. This is 797 internal to the local mobility anchor. The tunnel interface 798 identifier is acquired during the tunnel creation. 800 o The access technology type, using which the mobile node is 801 currently attached. This is obtained from the Access Technology 802 Type option, present in the Proxy Binding Update request. 804 o The 64-bit timestamp value of the most recently accepted Proxy 805 Binding Update request sent for this mobile node. This is the 806 time-of-day on the local mobility anchor, when the message was 807 received. If the Timestamp option is not present in the Proxy 808 Binding Update request (i.e., when the sequence number based 809 scheme is in use), the value MUST be set to ALL_ZERO. 811 Typically, any one of the mobile node's home network prefixes from 812 its mobility session is the key for locating a Binding Cache entry in 813 all cases except when there has been an handoff of the mobile node's 814 session to a new mobile access gateway and that mobile access gateway 815 is unaware of the home network prefix(es) assigned to that mobility 816 session. In such handoff cases, the Binding Cache entry can be 817 located under the considerations specified in Section 5.4.1. 819 5.2. Supported Home Network Prefix Models 821 This specification supports the Per-MN-Prefix model and does not 822 support the Shared-Prefix model. As per the Per-MN-Prefix model, 823 home network prefix(es) assigned to a mobile node are for that mobile 824 node's exclusive use and no other node shares an address from that 825 prefix (other than the Subnet-Router anycast address [RFC-4291] which 826 is used by the mobile access gateway hosting that prefix on that 827 link). 829 There may be more than one prefix assigned to a given interface of 830 the mobile node and all of those assigned prefixes are unique to that 831 mobile node and all are part of one mobility session. If the mobile 832 node attaches to the Proxy Mobile IPv6 domain through multiple 833 interfaces and simultaneously, each of the attached interfaces will 834 be assigned one or more unique prefixes and all of the assigned 835 prefixes to a given interface will be managed under a different 836 mobility session. 838 The mobile node's home network prefix(es) assigned to a given 839 interface of a mobile node (part of a mobility session) will be 840 hosted on the access link where the mobile node is attached (using 841 that interface). The local mobility anchor is not required to 842 perform any proxy ND operations [RFC-4861] for defending the mobile 843 node's home address(es), as the prefixes are not locally hosted on 844 the local mobility anchor. However, from the routing perspective, 845 the home network prefix(es) is topologically anchored on the local 846 mobility anchor. 848 5.3. Signaling Considerations 850 This section provides the rules for processing the signaling 851 messages. The processing rules specified in this section and other 852 related sections are chained and are in a specific order. When 853 applying these considerations for processing the signaling messages, 854 the specified order MUST be maintained. 856 5.3.1. Processing Binding Registrations 858 1. The received Proxy Binding Update message (a Binding Update 859 message with the 'P' flag set to value of 1, format specified in 860 Section 8.1) MUST be authenticated as described in Section 4. 861 When IPsec is used for message authentication, the SPI in the 862 IPsec header [RFC-4306] of the received packet is needed for 863 locating the security association, for authenticating the Proxy 864 Binding Update message. 866 2. The local mobility anchor MUST observe the rules described in 867 Section 9.2 of [RFC-3775] when processing Mobility Header in the 868 received Proxy Binding Update request. 870 3. The local mobility anchor MUST ignore the check, specified in 871 Section 10.3.1 of [RFC-3775], related to the presence of Home 872 Address destination option in the Proxy Binding Update request. 874 4. The local mobility anchor MUST identify the mobile node from the 875 identifier present in the Mobile Node Identifier option [RFC- 876 4283] of the Proxy Binding Update request. If the Mobile Node 877 Identifier option is not present in the Proxy Binding Update 878 request, the local mobility anchor MUST reject the request and 879 send a Proxy Binding Acknowledgement message with Status field 880 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 881 identifier option) and the identifier in the Mobile Node 882 Identifier Option carried in the message MUST be set to a zero 883 length identifier. 885 5. The local mobility anchor MUST apply the required policy checks, 886 as explained in Section 4, to verify the sender is a trusted 887 mobile access gateway, authorized to send Proxy Binding Update 888 requests on behalf of this mobile node. 890 6. If the local mobility anchor determines that the requesting node 891 is not authorized to send Proxy Binding Update requests for the 892 identified mobile node, it MUST reject the request and send a 893 Proxy Binding Acknowledgement message with Status field set to 894 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 895 binding registrations). 897 7. If the local mobility anchor cannot identify the mobile node 898 based on the identifier present in the Mobile Node Identifier 899 option [RFC-4283] of Proxy Binding Update request, it MUST 900 reject the request and send a Proxy Binding Acknowledgement 901 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 902 (Not local mobility anchor for this mobile node). 904 8. If the local mobility anchor determines that the mobile node is 905 not authorized for the network-based mobility management 906 service, it MUST reject the request and send a Proxy Binding 907 Acknowledgement message with Status field set to 908 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 910 9. The local mobility anchor MUST apply the considerations 911 specified in Section 5.5, for processing the Sequence Number 912 field and the Timestamp option (if present), in the Proxy 913 Binding Update request. 915 10. If there is no Home Network Prefix option(s) (with any value) 916 present in the Proxy Binding Update request, the local mobility 917 anchor MUST reject the request and send a Proxy Binding 918 Acknowledgement message with Status field set to 919 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network prefix 920 option). 922 11. If the Handoff Indicator option is not present in the Proxy 923 Binding Update request, the local mobility anchor MUST reject 924 the request and send a Proxy Binding Acknowledgement message 925 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 926 (Missing handoff indicator option). 928 12. If the Access Technology Type option is not present in the Proxy 929 Binding Update request, the local mobility anchor MUST reject 930 the request and send a Proxy Binding Acknowledgement message 931 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 932 (Missing access technology type option). 934 13. Considerations specified in Section 5.4.1 MUST be applied for 935 performing the Binding Cache entry existence test. If those 936 checks specified in Section 5.4.1, result in associating the 937 received Proxy Binding Update request to a new mobility session 938 creation request, considerations from Section 5.3.2 (Initial 939 Binding Registration - New Mobility Session), MUST be applied. 940 If those checks result in associating the request to an existing 941 mobility session, the following checks determine the next set of 942 processing rules that needs to be applied. 944 * If the Handoff Indicator field in the Handoff Indicator 945 option present in the request is set to a value of 5 (Handoff 946 state not changed), considerations from Section 5.3.3 947 (Binding Lifetime Extension- No handoff) MUST be applied. 949 * If the received Proxy Binding Update request has the lifetime 950 value of zero, considerations from Section 5.3.5 (Binding De- 951 Registration) MUST be applied. 953 * For all other cases, considerations from Section 5.3.4 954 (Binding Lifetime Extension - After handoff) MUST be applied. 956 14. When sending the Proxy Binding Acknowledgement message with any 957 Status field value, the message MUST be constructed as specified 958 in Section 5.3.6. 960 5.3.2. Initial Binding Registration (New Mobility Session) 962 1. If there is at least one instance of Home Network Prefix option 963 present in the Proxy Binding Update request with the prefix value 964 set to ALL_ZERO, the local mobility anchor MUST allocate one or 965 more home network prefix(es) to the mobile node and assign it to 966 the new mobility session created for the mobile node. The local 967 mobility anchor MUST ensure the allocated prefix(es) is not in 968 use by any other node or mobility session. The decision on how 969 many prefixes to be allocated for the attached interface, can be 970 based on a global policy or a policy specific to that mobile 971 node. However, when stateful address autoconfiguration using 972 DHCP is supported on the link, considerations from Section 6.11 973 MUST be applied for the prefix assignment. 975 2. If the local mobility anchor is unable to allocate any home 976 network prefix for the mobile node, it MUST reject the request 977 and send a Proxy Binding Acknowledgement message with Status 978 field set to 130 (Insufficient resources). 980 3. If there are one or more Home Network Prefix options present in 981 the Proxy Binding Update request (with each of the prefixes set 982 to a NON_ZERO value), the local mobility anchor before accepting 983 that request, MUST ensure each one of those prefixes is owned by 984 the local mobility anchor and further the mobile node is 985 authorized to use these prefixes. If the mobile node is not 986 authorized to use any one or more of those prefixes, the local 987 mobility anchor MUST reject the request and send a Proxy Binding 988 Acknowledgement message with Status field set to 989 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not 990 authorized for one or more of the requesting home network 991 prefixes). 993 4. Upon accepting the request, the local mobility anchor MUST create 994 a Binding Cache entry for the mobile node. It must set the 995 fields in the Binding Cache entry to the accepted values for that 996 registration. 998 5. If there is no existing bi-directional tunnel to the mobile 999 access gateway that sent the request, the local mobility anchor 1000 MUST establish a bi-directional tunnel to that mobile access 1001 gateway. Considerations from Section 5.6.1 MUST be applied for 1002 managing the dynamically created bi-directional tunnel. 1004 6. The local mobility anchor MUST create a prefix route(s) over the 1005 tunnel to the mobile access gateway for forwarding any traffic 1006 received for the mobile node's home network prefix(es) associated 1007 with this mobility session. The created tunnel and the routing 1008 state MUST result in the forwarding behavior on the local 1009 mobility anchor as specified in Section 5.6.2. 1011 7. The local mobility anchor MUST send the Proxy Binding 1012 Acknowledgement message with the Status field set to 0 (Proxy 1013 Binding Update Accepted). The message MUST be constructed as 1014 specified in Section 5.3.6. 1016 5.3.3. Binding Lifetime Extension (No handoff) 1018 1. Upon accepting the Proxy Binding Update request for extending the 1019 binding lifetime, received from the same mobile access gateway 1020 (if the Proxy-CoA address in the Binding Cache entry is the same 1021 as the Proxy-CoA address in the request) that last updated the 1022 binding, the local mobility anchor MUST update the Binding Cache 1023 entry with the accepted registration values. 1025 2. The local mobility anchor MUST send the Proxy Binding 1026 Acknowledgement message with the Status field set to 0 (Proxy 1027 Binding Update Accepted). The message MUST be constructed as 1028 specified in Section 5.3.6. 1030 5.3.4. Binding Lifetime Extension (After handoff) 1032 1. Upon accepting the Proxy Binding Update request for extending the 1033 binding lifetime, received from a new mobile access gateway (if 1034 the Proxy-CoA address in the Binding Cache entry does not match 1035 the Proxy-CoA address in the request) where the mobile node's 1036 session is handed off, the local mobility anchor MUST update the 1037 Binding Cache entry with the accepted registration values. 1039 2. The local mobility anchor MUST remove the previously created 1040 route(s) for the mobile node's home network prefix(es) associated 1041 with this mobility session. Additionally, if there are no other 1042 mobile node sessions sharing the dynamically created bi- 1043 directional tunnel to the previous mobile access gateway, the 1044 tunnel SHOULD be deleted applying considerations from section 1045 5.6.1 (if the tunnel is a dynamically created tunnel and not a 1046 fixed pre-established tunnel). 1048 3. If there is no existing bi-directional tunnel to the mobile 1049 access gateway that sent the request, the local mobility anchor 1050 MUST establish a bi-directional tunnel to that mobile access 1051 gateway. Considerations from Section 5.6.1 MUST be applied for 1052 managing the dynamically created bi-directional tunnel. 1054 4. The local mobility anchor MUST create prefix route(s) over the 1055 tunnel to the mobile access gateway for forwarding any traffic 1056 received for the mobile node's home network prefix(es) associated 1057 with that mobility session. The created tunnel and routing state 1058 MUST result in the forwarding behavior on the local mobility 1059 anchor as specified in Section 5.6.2. 1061 5. The local mobility anchor MUST send the Proxy Binding 1062 Acknowledgement message with the Status field set to 0 (Proxy 1063 Binding Update Accepted). The message MUST be constructed as 1064 specified in Section 5.3.6. 1066 5.3.5. Binding De-Registration 1068 1. If the received Proxy Binding Update request with the lifetime 1069 value of zero, has a Source Address in the IPv6 header (or the 1070 address in the Alternate Care-of Address option, if the option is 1071 present) different from what is present in the Proxy-CoA address 1072 field in the Binding Cache entry, the local mobility anchor MUST 1073 ignore the request. 1075 2. Upon accepting the Proxy Binding Update request with the lifetime 1076 value of zero, the local mobility anchor MUST wait for 1077 MinDelayBeforeBCEDelete amount of time, before it deletes the 1078 Binding Cache entry. However, it MUST send the Proxy Binding 1079 Acknowledgement message with the Status field set to 0 (Proxy 1080 Binding Update Accepted). The message MUST be constructed as 1081 specified in Section 5.3.6. 1083 * During this wait period, the local mobility anchor SHOULD drop 1084 the mobile node's data traffic. 1086 * During this wait period, if the local mobility anchor receives 1087 a valid Proxy Binding Update request for the same mobility 1088 session with the lifetime value of greater than zero, and if 1089 that request is accepted, then the Binding Cache entry MUST 1090 NOT be deleted, but must be updated with the newly accepted 1091 registration values and additionally the wait period should be 1092 ended. 1094 * By the end of this wait period, if the local mobility anchor 1095 did not receive any valid Proxy Binding Update request for 1096 this mobility session, then it MUST delete the Binding Cache 1097 entry and remove the routing state created for that mobility 1098 session. The local mobility anchor can potentially reassign 1099 the prefix(es) associated with this mobility session to other 1100 mobile nodes. 1102 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1104 o The local mobility anchor when sending the Proxy Binding 1105 Acknowledgement message to the mobile access gateway MUST 1106 construct the message as specified below. 1108 IPv6 header (src=LMAA, dst=Proxy-CoA) 1109 Mobility header 1110 - BA /* P flag must be set to value of 1 */ 1111 Mobility Options 1112 - Mobile Node Identifier Option (mandatory) 1113 - Home Network Prefix option(s) (mandatory) 1114 - Handoff Indicator option (mandatory) 1115 - Access Technology Type option (mandatory) 1116 - Timestamp Option (optional) 1117 - Mobile Node Link-layer Identifier option (optional) 1118 - Link-local Address option (optional) 1120 Figure 6: Proxy Binding Acknowledgement message format 1122 o The Source Address field in the IPv6 header of the message MUST be 1123 set to the destination address of the received Proxy Binding 1124 Update request. 1126 o The Destination Address field in the IPv6 header of the message 1127 MUST be set to the source address of the received Proxy Binding 1128 Update request. When there is no Alternate Care-of Address option 1129 present in the request, the destination address is the same as the 1130 Proxy-CoA address, otherwise, the address may not be the same as 1131 the Proxy-CoA. 1133 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1134 identifier field in the option MUST be copied from the Mobile Node 1135 Identifier option in the received Proxy Binding Update request. 1136 If the option was not present in the request, the identifier in 1137 the option MUST be set to a zero length identifier. 1139 o At least one Home Network Prefix option MUST be present. 1141 * If the Status field is set to a value greater than or equal to 1142 128, i.e., if the binding request is rejected, all the Home 1143 Network Prefix options that were present in the request (along 1144 with their prefix values) MUST be present in the reply. But, 1145 if there was no Home Network Prefix option present in the 1146 request, then there MUST be only one Home Network Prefix option 1147 and with the value in the option set to ALL_ZERO. 1149 * For all other cases, there MUST be a Home Network Prefix option 1150 for each of the assigned home network prefixes (for that 1151 mobility session) and with the prefix value in the option set 1152 to the allocated prefix value. 1154 o The Handoff Indicator option MUST be present. The handoff 1155 indicator field in the option MUST be copied from the Handoff 1156 Indicator option in the received Proxy Binding Update request. If 1157 the option was not present in the request, the value in the option 1158 MUST be set to zero. 1160 o The Access Technology Type option MUST be present. The access 1161 technology type field in the option MUST be copied from the Access 1162 Technology Type option in the received Proxy Binding Update 1163 request. If the option was not present in the request, the value 1164 in the option MUST be set to zero. 1166 o The Timestamp option MUST be present only if the same option was 1167 present in the received Proxy Binding Update request and MUST NOT 1168 be present otherwise. Considerations from Section 5.5 must be 1169 applied for constructing the Timestamp option. 1171 o The Mobile Node Link-layer Identifier option MUST be present only 1172 if the same option was present in the received Proxy Binding 1173 Update request and MUST NOT be present otherwise. The link-layer 1174 identifier value MUST be copied from the Mobile Node Link-layer 1175 Identifier option present in the received Proxy Binding Update 1176 request. 1178 o The Link-local Address option MUST be present only if the same 1179 option was present in the received Proxy Binding Update request 1180 and MUST NOT be present otherwise. 1182 * If the received Proxy Binding Update request has the Link-local 1183 Address option with any value other than ALL_ZERO, the same 1184 value MUST be copied to the Link-local Address field of the 1185 Binding Cache entry and it must also be copied to the Link- 1186 local Address option in the reply. 1188 * If there is no existing Binding Cache entry (i.e., if this is a 1189 request for a new mobility session), then the local mobility 1190 anchor MUST generate the link-local address that the mobile 1191 access gateway can use on the point-to-point link shared with 1192 the mobile node and the same must be copied to the Link-local 1193 Address field of the Binding Cache entry and it must also be 1194 copied to the Link-local Address option in the reply. 1196 * For all other cases, the link-local address in the option MUST 1197 be copied from the Link-local Address field of the Binding 1198 Cache entry. 1200 o If IPsec is used for protecting the signaling messages, the 1201 message MUST be protected, using the security association existing 1202 between the local mobility anchor and the mobile access gateway. 1204 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1205 NOT be present in the IPv6 header of the packet. 1207 5.4. Multihoming Support 1209 This specification allows mobile nodes to connect to a Proxy Mobile 1210 IPv6 domain through multiple interfaces for simultaneous access. 1211 Following are the key aspects of this multihoming support. 1213 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1214 multiple interfaces for simultaneous access, the local mobility 1215 anchor MUST allocate a mobility session for each of the attached 1216 interfaces. Each of the mobility session should be managed under 1217 a separate Binding Cache entry and with its own lifetime. 1219 o The local mobility anchor MAY allocate more than one home network 1220 prefix for a given interface of the mobile node. However, all the 1221 prefixes associated with a given interface MUST be managed as part 1222 of one mobility session, associated with that interface. 1224 o The local mobility anchor MUST allow for an handoff between two 1225 different interfaces of a mobile node. In such a scenario, all 1226 the home network prefix(es) associated with one interface (part of 1227 one mobility session) will be associated with a different 1228 interface of the mobile node). The decision on when to create a 1229 new mobility session and when to update an existing mobility 1230 session MUST be based on the Handover hint present in the Proxy 1231 Binding Update message and under the considerations specified in 1232 this section. 1234 5.4.1. Binding Cache entry lookup considerations 1236 There can be multiple Binding Cache entries for a given mobile node. 1237 When doing a lookup for a mobile node's Binding Cache entry for 1238 processing a received Proxy Binding Update request message, the local 1239 mobility anchor MUST apply the following multihoming considerations 1240 (in the below specified order, starting with Section 5.4.1.1). These 1241 rules are chained with the processing rules specified in Section 5.3. 1243 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1244 request 1246 +=====================================================================+ 1247 | Registration/De-Registration Message | 1248 +=====================================================================+ 1249 | At least one HNP Option with NON_ZERO Value | 1250 +=====================================================================+ 1251 | ATT | 1252 +=====================================================================+ 1253 | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | 1254 +=====================================================================+ 1255 | HI | 1256 +==================================+==================================+ 1257 | BCE Lookup Key: Any of the Home Network Prefixes from the request | 1258 +=====================================================================+ 1260 Figure 7: BCE lookup using home network prefix 1262 If there is at least one Home Network Prefix option present in the 1263 request with NON_ZERO prefix value, the following considerations MUST 1264 be applied. If there are more than one instances of the Home Network 1265 Prefix option, any one of the Home Network Prefix options present in 1266 the request (with NON_ZERO prefix value) can be used for locating the 1267 Binding Cache entry. 1269 1. The local mobility anchor MUST verify if there is an existing 1270 Binding Cache entry with one of its home network prefixes 1271 matching the prefix value in one of the Home Network Prefix 1272 options of the received Proxy Binding Update request. [BCE(HNP) 1273 equals PBU(HNP)] 1275 2. If there does not exist a Binding Cache entry (with one of its 1276 home network prefixes in the Binding Cache entry matching the 1277 prefix value in one of the Home Network Prefix options of the 1278 received Proxy Binding Update request), the request MUST be 1279 considered as a request for creating a new mobility session. 1280 [BCE(HNP) not equals PBU(HNP)] 1282 3. If there exists a Binding Cache entry (with one of its home 1283 network prefixes in the Binding Cache entry matching the prefix 1284 value in one of the Home Network Prefix options of the received 1285 Proxy Binding Update request) but if the mobile node identifier 1286 in the entry does not match the mobile node identifier in the 1287 Mobile Node Identifier option of the received Proxy Binding 1288 Update request, the local mobility anchor MUST reject the request 1289 with the Status field value set to 1290 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1291 authorized for one or more of the requesting home network 1292 prefixes). [BCE(MN-Identifier) not equals PBU(MN-Identifier)] 1294 4. If there exists a Binding Cache entry (matching MN-Identifier and 1295 one of its home network prefixes in the Binding Cache entry 1296 matching the prefix value in one of the Home Network Prefix 1297 options of the received Proxy Binding Update request), but if all 1298 the prefixes in the request do not match all the prefixes in the 1299 Binding Cache entry, or if they do not match in count, then the 1300 local mobility anchor MUST reject the request with the Status 1301 field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home 1302 network prefixes listed in the BCE do not match all the prefixes 1303 in the received PBU). [BCE(HNP1, HNP2, .. HNPn) not equals 1304 PBU(HNP1, HNP2, ..HNPn)] OR [BCE(Count(HNP))] not equals 1305 PBU(Count(HNP))] 1307 5. If there exists a Binding Cache entry (matching MN-Identifier and 1308 all the home network prefixes in the Binding Cache entry matching 1309 all the home network prefixes in the received Proxy Binding 1310 Update request) and if any one or more of these below stated 1311 conditions match, the request MUST be considered as a request for 1312 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1313 PBU(MN-Identifier)] AND [BCE(HNP1, HNP2, .. HNPn) equals 1314 PBU(HNP1, HNP2, ..HNPn)] 1316 * If the Handoff Indicator field in the Handoff Indicator option 1317 present in the request is set to a value of 2 (Handoff between 1318 two different interfaces of the mobile node). [PBU(HI) equals 1319 2] 1321 * If there is no Mobile Node Link-layer Identifier option 1322 present in the request, the link-layer identifier value in the 1323 Binding Cache entry is set to ALL_ZERO, the access technology 1324 type field in the Access Technology Type option present in the 1325 request matches the access technology type in the Binding 1326 Cache entry and if the Handoff Indicator field in the Handoff 1327 Indicator option present in the request is set to a value of 3 1328 (Handoff between mobile access gateways for the same 1329 interface). 1331 * If the Proxy-CoA address in the Binding Cache entry matches 1332 the source address of the request (or the address in the 1333 alternate Care-of Address option, if the option is present) 1334 and if the access technology type field in the Access 1335 Technology Type option present in the request matches the 1336 access technology type in the Binding Cache entry. 1337 [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)]. 1339 6. For all other cases, the message MUST be considered as a request 1340 for creating a new mobility session. 1342 5.4.1.2. Mobile Node Link-layer Identifier Option present in the 1343 request 1345 +=====================================================================+ 1346 | Registration/De-Registration Message | 1347 +=====================================================================+ 1348 | HNP option with ALL_ZERO Value | 1349 +=====================================================================+ 1350 | ATT | 1351 +=====================================================================+ 1352 | MN-LL-Identifier Option Present (NON_ZERO Value) | 1353 +=====================================================================+ 1354 | HI | 1355 +==================================+==================================+ 1356 | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | 1357 +=====================================================================+ 1359 Figure 8: BCE Lookup using Link-layer Identifier 1361 1. The local mobility anchor MUST verify if there is an existing 1362 Binding Cache entry, with the mobile node identifier matching the 1363 identifier in the received Mobile Node Identifier option, access 1364 technology type matching the value in the received Access 1365 Technology Type option and the link-layer identifier value 1366 matching the identifier in the received Mobile Node Link-layer 1367 Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier) 1368 equals PBU(MN-Identifier, ATT, MN-LL-Identifier)] 1370 2. If there exists a Binding Cache entry (matching MN-Identifier, 1371 ATT and MN-LL-Identifier), the request MUST be considered as a 1372 request for updating that Binding Cache entry. 1374 3. If there does not exist a Binding Cache entry (matching MN- 1375 Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator 1376 field in the Handoff Indicator option present in the request is 1377 set to a value of 2 (Handoff between two different interfaces of 1378 the mobile node). The local mobility anchor MUST apply the 1379 following additional considerations. [PBU(HI) equals 2] 1381 * The local mobility anchor MUST verify if there exists one and 1382 only one Binding Cache entry with the mobile node identifier 1383 matching the identifier in the Mobile Node Identifier option 1384 present in the request and for any link-layer identifier 1385 value. If there exists only one such entry (matching the MN- 1386 Identifier), the request MUST be considered as a request for 1387 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1388 PBU(MN-Identifier)] 1390 4. If there does not exist a Binding Cache entry (matching MN- 1391 Identifier, ATT and MN-LL-Identifier) and if the Handoff 1392 Indicator field in the Handoff Indicator option present in the 1393 request is set to a value of 4 (Handoff state unknown), the local 1394 mobility anchor MUST apply the following additional 1395 considerations. 1397 * The local mobility anchor MUST verify if there exists one and 1398 only one Binding Cache entry with the mobile node identifier 1399 matching the identifier in the Mobile Node Identifier option 1400 present in the request and for any link-layer identifier 1401 value. If there exists only one such entry (matching the MN- 1402 Identifier), the local mobility anchor SHOULD wait till the 1403 existing Binding Cache entry is de-registered by the 1404 previously serving mobile access gateway, before the request 1405 can be considered as a request for updating that Binding Cache 1406 entry. However, if there is no de-registration message that 1407 is received within MaxDelayBeforeNewBCEAssign amount of time, 1408 the local mobility anchor upon accepting the request MUST 1409 consider the request as a request for creating a new mobility 1410 session. The local mobility anchor MAY also choose to create 1411 a new mobility session and without waiting for a de- 1412 registration message and this should be configurable on the 1413 local mobility anchor. 1415 5. For all other cases, the message MUST be considered as a request 1416 for creating a new mobility session. 1418 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 1419 request 1421 +=====================================================================+ 1422 | Registration/De-Registration Message | 1423 +=====================================================================+ 1424 | HNP option with ALL_ZERO Value | 1425 +=====================================================================+ 1426 | ATT | 1427 +=====================================================================+ 1428 | MN-LL-Identifier Option Not Present | 1429 +=====================================================================+ 1430 | HI | 1431 +==================================+==================================+ 1432 | BCE Lookup Key: (MN-Identifier) | 1433 +=====================================================================+ 1435 Figure 9: BCE Lookup using Mobile Node Identifier 1437 1. The local mobility anchor MUST verify if there exists one and 1438 only one Binding Cache entry with the mobile node identifier 1439 matching the identifier in the Mobile Node Identifier option 1440 present in the request. 1442 2. If there exists only one such entry (matching the MN-Identifier) 1443 and the Handoff Indicator field in the Handoff Indicator option 1444 present in the request is set to a value of 2 (Handoff between 1445 two different interfaces of the mobile node) or set to a value of 1446 3 (Handoff between mobile access gateways for the same 1447 interface), then the request MUST be considered as a request for 1448 updating that Binding Cache entry. [PBU(HI) equals 2] or 1449 [PBU(HI) equals 3] 1451 3. If there exists only one such entry (matching the MN-Identifier) 1452 and the Handoff Indicator field in the Handoff Indicator option 1453 present in the request is set to a value of 4 (Handoff state 1454 unknown), the local mobility anchor SHOULD wait till the existing 1455 Binding Cache entry is de-registered by the previously serving 1456 mobile access gateway, before the request can be considered as a 1457 request for updating that Binding Cache entry. However, if there 1458 is no de-registration message that is received within 1459 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1460 anchor upon accepting the request MUST consider the request as a 1461 request for creating a new mobility session. The local mobility 1462 anchor MAY also choose to create a new mobility session and 1463 without waiting for a de-registration message and this should be 1464 configurable on the local mobility anchor. 1466 4. For all other cases, the message MUST be considered as a request 1467 for creating a new mobility session. 1469 5.5. Timestamp Option for Message Ordering 1471 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1472 registration messages as a way for the home agent to process the 1473 binding updates in the order they were sent by a mobile node. The 1474 home agent and the mobile node are required to manage this counter 1475 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1476 the mobile node moves from one mobile access gateway to another and 1477 in the absence of mechanisms such as context transfer between the 1478 mobile access gateways, the serving mobile access gateway will be 1479 unable to determine the sequence number that it needs to use in the 1480 signaling messages. Hence, the sequence number scheme, as specified 1481 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1483 If the local mobility anchor cannot determine the sending order of 1484 the received binding registration messages, it may potentially 1485 process an older message sent by a mobile access gateway where the 1486 mobile node was previously anchored, but delivered out of order, 1487 resulting in incorrectly updating the mobile node's Binding Cache 1488 entry and creating a routing state for tunneling the mobile node's 1489 traffic to the previously serving gateway. 1491 For solving this problem, this specification adopts two alternative 1492 solutions. One is based on timestamps and the other based on 1493 sequence numbers, as defined in [RFC-3775]. 1495 The basic principle behind the use of timestamps in binding 1496 registration messages is that the node generating the message inserts 1497 the current time-of-day, and the node receiving the message checks 1498 that this timestamp is greater than all previously accepted 1499 timestamps. The timestamp based solution may be used when the 1500 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1501 have the ability to obtain the last sequence number that was sent in 1502 a binding registration message for updating a given mobile node's 1503 binding. 1505 If the mechanism used for clock synchronization in the Proxy Mobile 1506 IPv6 domain cannot assure a clock drift between the two mobile access 1507 gateways (between which the mobile node did a handoff), which is not 1508 less than half the total time it took for the mobile node to roam 1509 between the two mobile access gateways and the time it took for the 1510 serving mobile access gateway to detect the node on its access link 1511 and construct the Proxy Binding Update message, then this solution 1512 will not predictably work in all cases and hence SHOULD NOT be used. 1514 As an alternative to the Timestamp based approach, the specification 1515 also allows the use of Sequence Number based scheme, as specified in 1516 [RFC-3775]. However, for this scheme to work, the serving mobile 1517 access gateway in a Proxy Mobile IPv6 domain MUST have the ability to 1518 obtain the last sequence number that was sent in a binding 1519 registration message. The sequence number MUST be maintained on a 1520 per mobile node basis and MUST be available to the serving mobile 1521 access gateway. This may be achieved by using context transfer 1522 schemes or by maintaining the sequence number in a policy store. 1523 However, the specific details on how the mobile node's sequence 1524 number is made available to the serving mobile access gateway prior 1525 to sending the binding registration messages is outside the scope of 1526 this document." 1528 Using the Timestamps based approach: 1530 1. A local mobility anchor implementation MUST support the Timestamp 1531 option. If the Timestamp option is present in the received Proxy 1532 Binding Update request message, then the local mobility anchor 1533 MUST include a valid Timestamp option in the Proxy Binding 1534 Acknowledgement message that it sends to the mobile access 1535 gateway. 1537 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1538 exchanging binding registration messages using the Timestamp 1539 option MUST have adequately synchronized time-of-day clocks. 1541 This is the essential requirement for this solution to work. If 1542 this requirement is not met, the solution will not predictably 1543 work in all cases. 1545 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1546 synchronize their clocks to a common time source. For 1547 synchronizing the clocks, the nodes MAY use the Network Time 1548 Protocol [RFC-4330]. Deployments MAY also adopt other approaches 1549 suitable for that specific deployment. Alternatively, if there 1550 is mobile node generated timestamp that is increasing at every 1551 attachment to the access link and if that timestamp is available 1552 to the mobile access gateway (Ex: The timestamp option in the 1553 SEND messages that the mobile node sends), the mobile access 1554 gateway can use this timestamp or sequence number in the Proxy 1555 Binding Update messages and does not have to depend on any 1556 external clock source. However, the specific details on how this 1557 is achieved is outside the scope of this document. 1559 4. When generating the timestamp value for building the Timestamp 1560 option, the mobility entities MUST ensure that the generated 1561 timestamp is the elapsed time past the same reference epoch, as 1562 specified in the format for the Timestamp option (Section 8.8). 1564 5. If the Timestamp option is present in the received Proxy Binding 1565 Update message, the local mobility anchor MUST ignore the 1566 sequence number field in the message. However, it MUST copy the 1567 sequence number from the received Proxy Binding Update message to 1568 the Proxy Binding Acknowledgement message. 1570 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1571 option, the local mobility anchor MUST check the timestamp field 1572 for validity. In order for it to be considered valid, the 1573 timestamp value contained in the Timestamp option MUST be close 1574 enough (within TimestampValidityWindow amount of time difference) 1575 to the local mobility anchor's time-of-day clock and the 1576 timestamp MUST be greater than all previously accepted timestamps 1577 in the Proxy Binding Update messages sent for that mobile node. 1578 However, if the flag MobileNodeGeneratedTimestampInUse is set to 1579 value of 1, this check MUST NOT be performed. 1581 7. If the timestamp value in the received Proxy Binding Update is 1582 valid (validity as specified in the above considerations) or if 1583 the flag MobileNodeGeneratedTimestampInUse is set to value of 1, 1584 the local mobility anchor MUST return the same timestamp value in 1585 the Timestamp option included in the Proxy Binding 1586 Acknowledgement message that it sends to the mobile access 1587 gateway. 1589 8. If the timestamp value in the received Proxy Binding Update is 1590 lower than the previously accepted timestamp in the Proxy Binding 1591 Update messages sent for that mobility binding, the local 1592 mobility anchor MUST reject the Proxy Binding Update request and 1593 send a Proxy Binding Acknowledgement message with Status field 1594 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1595 previously accepted timestamp). The message MUST also include 1596 the Timestamp option with the value set to the current time-of- 1597 day on the local mobility anchor. 1599 9. If the timestamp value in the received Proxy Binding Update is 1600 not valid (validity as specified in the above considerations), 1601 the local mobility anchor MUST reject the Proxy Binding Update 1602 and send a Proxy Binding Acknowledgement message with Status 1603 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1604 message MUST also include the Timestamp option with the value set 1605 to the current time-of-day on the local mobility anchor. 1607 Using the Sequence Number based approach: 1609 1. If the Timestamp option is not present in the received Proxy 1610 Binding Update request, the local mobility anchor MUST fall back 1611 to the Sequence Number based scheme. It MUST process the 1612 sequence number field as specified in [RFC-3775]. Also, it MUST 1613 NOT include the Timestamp option in the Proxy Binding 1614 Acknowledgement messages that it sends to the mobile access 1615 gateway. 1617 2. An implementation MUST support the Sequence Number based scheme, 1618 as specified in [RFC-3775]. 1620 3. The Sequence Number based approach can be used only when there is 1621 some mechanism (such as context transfer procedure between mobile 1622 access gateways) that allows the serving mobile access gateway to 1623 obtain the last sequence number that was sent in a binding 1624 registration message for updating a given mobile node's binding. 1626 5.6. Routing Considerations 1628 5.6.1. Bi-Directional Tunnel Management 1630 The bi-directional tunnel MUST be used for routing the mobile node's 1631 data traffic between the mobile access gateway and the local mobility 1632 anchor. A tunnel hides the topology and enables a mobile node to use 1633 address(es) from its home network prefix(es) from any access link in 1634 that Proxy Mobile IPv6 domain. A tunnel may be created dynamically 1635 when needed and removed when not needed. However, implementations 1636 MAY choose to use static pre-established tunnels instead of 1637 dynamically creating and tearing them down on a need basis. The 1638 following considerations MUST be applied when using dynamic tunnels. 1640 o A bi-directional tunnel MUST be established between the local 1641 mobility anchor and the mobile access gateway with IPv6-in-IPv6 1642 encapsulation, as described in [RFC-2473]. The tunnel end points 1643 are the Proxy-CoA and LMAA. When using IPv4 transport, the end 1644 points of the tunnel are the IPv4-LMAA and IPv4-Proxy-CoA, as 1645 specified in [ID-IPV4-PMIP6]. 1647 o Implementations MAY use a software timer for managing the tunnel 1648 lifetime and a counter for keeping a count of all the mobile nodes 1649 that are sharing the tunnel. The timer value can be set to the 1650 accepted binding lifetime and can be updated after each periodic 1651 re-registration for extending the lifetime. If the tunnel is 1652 shared for multiple mobile nodes, the tunnel lifetime must be set 1653 to the highest binding lifetime that is granted to any one of 1654 those mobile nodes sharing that tunnel. 1656 o The tunnel SHOULD be deleted when either the tunnel lifetime 1657 expires or when there are no mobile nodes sharing the tunnel. 1659 5.6.2. Forwarding Considerations 1661 Intercepting Packets Sent to the Mobile Node's Home Network: 1663 o When the local mobility anchor is serving a mobile node, it MUST 1664 be able to receive packets that are sent to the mobile node's home 1665 network. In order for it to receive those packets, it MUST 1666 advertise a connected route in to the Routing Infrastructure for 1667 the mobile node's home network prefix(es) or for an aggregated 1668 prefix with a larger scope. This essentially enables IPv6 routers 1669 in that network to detect the local mobility anchor as the last- 1670 hop router for the mobile node's home network prefix(es). 1672 Forwarding Packets to the Mobile Node: 1674 o On receiving a packet from a correspondent node with the 1675 destination address matching a mobile node's home network 1676 prefix(es), the local mobility anchor MUST forward the packet 1677 through the bi-directional tunnel set up for that mobile node. 1679 o The format of the tunneled packet is shown below. Considerations 1680 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 1681 when using IPv4 transport, the format of the packet is as 1682 described in [ID-IPV4-PMIP6]. 1684 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1685 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1686 Upper layer protocols /* Packet Content*/ 1688 Figure 10: Tunneled Packet from LMA to MAG 1690 o The format of the tunneled packet is shown below, when payload 1691 protection using IPsec is enabled for the mobile node's data 1692 traffic. However, when using IPv4 transport, the format of the 1693 packet is as described in [ID-IPV4-PMIP6]. 1695 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1696 ESP Header in tunnel mode /* ESP Header */ 1697 IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */ 1698 Upper layer protocols /* Packet Content*/ 1700 Figure 11: Tunneled Packet from LMA to MAG with Payload Protection 1702 Forwarding Packets Sent by the Mobile Node: 1704 o All the reverse tunneled packets that the local mobility anchor 1705 received from the mobile access gateway, after removing the tunnel 1706 header MUST be routed to the destination specified in the inner 1707 packet header. These routed packets will have the source address 1708 field set to the mobile node's home address. Considerations from 1709 [RFC-2473] MUST be applied for IPv6 decapsulation. 1711 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels 1713 This section describes how the ECN information needs to be handled by 1714 the mobility agents at the tunnel entry and exit points. The ECN 1715 considerations for IP tunnels are specified in [RFC-3168] and the 1716 same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6- 1717 in-IPv6 encapsulation mode). Specifically the full-functionality 1718 option MUST be supported. The relevant ECN considerations from [RFC- 1719 3168] are summarized here for convenience. 1721 Encapsulation Considerations: 1723 o If the Explicit Congestion Notification (ECN) field in the inner 1724 header is set to ECT(0) or ECT(1), where ECT stands for ECN- 1725 Capable Transport (ECT), the ECN field from the inner header MUST 1726 be copied to the outer header. Additionally, when payload 1727 protection using IPsec is enabled for the mobile node's data 1728 traffic, the ECN considerations from [RFC-4301] MUST be applied. 1730 Decapsulation Considerations: 1732 o If the Explicit Congestion Notification (ECN) field in the inner 1733 header is set to ECT(0) or ECT(1), and if the ECN field in the 1734 outer header is set to Congestion Experienced (CE), then the ECN 1735 field in the inner header MUST be set to CE. Otherwise, the ECN 1736 field in the inner header MUST NOT be modified. Additionally, 1737 when payload protection using IPsec is enabled for the mobile 1738 node's data traffic, the ECN considerations from [RFC-4301] MUST 1739 be applied. 1741 5.7. Local Mobility Anchor Address Discovery 1743 Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 1744 10.5 of [RFC-3775], allows a mobile node to discover all the home 1745 agents on its home link by sending an ICMP Home Agent Address 1746 Discovery Request message to the Mobile IPv6 Home-Agents anycast 1747 address, derived from its home network prefix. 1749 The DHAAD message in the current form cannot be used in Proxy Mobile 1750 IPv6 for discovering the address of the mobile node's local mobility 1751 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1752 able to receive any messages sent to the Mobile IPv6 Home-Agents 1753 anycast address corresponding to the mobile node's home network 1754 prefix(es), as the prefix(es) is not hosted on any of its interfaces. 1755 Further, the mobile access gateway will not predictably be able to 1756 locate the serving local mobility anchor that has the mobile node's 1757 binding cache entry. Hence, this specification does not support 1758 Dynamic Home Agent Address Discovery protocol. 1760 In Proxy Mobile IPv6, the address of the local mobility anchor 1761 configured to serve a mobile node can be discovered by the mobility 1762 entities in other ways. This may be a configured entry in the mobile 1763 node's policy profile, or it may be obtained through mechanisms 1764 outside the scope of this document. 1766 5.8. Mobile Prefix Discovery Considerations 1768 This specification does not support mobile prefix discovery. The 1769 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1770 applicable to Proxy Mobile IPv6. 1772 5.9. Route Optimization Considerations 1774 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1775 enables a mobile node to communicate with a correspondent node 1776 directly using its care-of address and further the Return Routability 1777 procedure enables the correspondent node to have reasonable trust 1778 that the mobile node is reachable at both its home address and 1779 care-of address. 1781 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1782 mobility related signaling. The mobile node uses address(es) from 1783 its home network prefix(es) for all its communication and the Care-of 1784 address (Proxy-CoA) is not visible to the mobile node. Hence, the 1785 Return Routability procedure as defined in Mobile IPv6 [RFC-3775] 1786 cannot be used in Proxy Mobile IPv6. 1788 6. Mobile Access Gateway Operation 1790 The Proxy Mobile IPv6 protocol described in this document introduces 1791 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1792 access gateway is the entity that is responsible for detecting the 1793 mobile node's movements to and from the access link and sending the 1794 binding registration requests to the local mobility anchor. In 1795 essence, the mobile access gateway performs mobility management on 1796 behalf of a mobile node. 1798 The mobile access gateway is a function that typically runs on an 1799 access router. However, implementations MAY choose to split this 1800 function and run it across multiple systems. The specifics on how 1801 that is achieved or the signaling interactions between those 1802 functional entities are beyond the scope of this document. 1804 The mobile access gateway has the following key functional roles: 1806 o It is responsible for detecting the mobile node's movements on the 1807 access link and for initiating the mobility signaling with the 1808 mobile node's local mobility anchor. 1810 o Emulation of the mobile node's home link on the access link by 1811 sending Router Advertisement messages containing the mobile node's 1812 home network prefix(es), each prefix carried using the Prefix 1813 Information option [RFC-4861]. 1815 o Responsible for setting up the data path for enabling the mobile 1816 node to configure one or more addresses from its home network 1817 prefix(es) and use it from the attached access link. 1819 6.1. Extensions to Binding Update List Entry Data Structure 1821 Every mobile access gateway MUST maintain a Binding Update List. 1822 Each entry in the Binding Update List represents a mobile node's 1823 mobility binding with its local mobility anchor. The Binding Update 1824 List is a conceptual data structure, described in Section 11.1 of 1825 [RFC-3775]. 1827 For supporting this specification, the conceptual Binding Update List 1828 entry data structure needs be extended with the following additional 1829 fields. 1831 o The Identifier of the attached mobile node, MN-Identifier. This 1832 identifier is acquired during the mobile node's attachment to the 1833 access link through mechanisms outside the scope of this document. 1835 o The link-layer identifier of the mobile node's connected 1836 interface. This can be acquired from the received Router 1837 Solicitation messages from the mobile node or during the mobile 1838 node's attachment to the access network. This is typically a 1839 link-layer identifier conveyed by the mobile node; however, the 1840 specific details on how that is conveyed is out of scope for this 1841 specification. If this identifier is not available, this variable 1842 length field MUST be set to two (octets) and MUST be initialized 1843 to a value of ALL_ZERO. 1845 o List of IPv6 home network prefixes assigned to the mobile node's 1846 connected interface. The home network prefix(es) may have been 1847 statically configured in the mobile node's policy profile, or, may 1848 have been dynamically allocated by the local mobility anchor. 1849 Each of these prefix entries will also includes the corresponding 1850 prefix length. 1852 o The Link-local address of the mobile access gateway on the access 1853 link shared with the mobile node. 1855 o The IPv6 address of the local mobility anchor serving the attached 1856 mobile node. This address is acquired from the mobile node's 1857 policy profile or from other means. 1859 o The interface identifier (If-Id) of the point-to-point link 1860 between the mobile node and the mobile access gateway. This is 1861 internal to the mobile access gateway and is used to associate the 1862 Proxy Mobile IPv6 tunnel to the access link where the mobile node 1863 is attached. 1865 o The tunnel interface identifier (If-Id) of the bi-directional 1866 tunnel between the mobile node's local mobility anchor and the 1867 mobile access gateway. This is internal to the mobile access 1868 gateway. The tunnel interface identifier is acquired during the 1869 tunnel creation. 1871 6.2. Mobile Node's Policy Profile 1873 A mobile node's policy profile contains the essential operational 1874 parameters that are required by the network entities for managing the 1875 mobile node's mobility service. These policy profiles are stored in 1876 a local or a remote policy store. The mobile access gateway and the 1877 local mobility anchor MUST be able to obtain a mobile node's policy 1878 profile. The policy profile MAY also be handed over to a serving 1879 mobile access gateway as part of a context transfer procedure during 1880 a handoff or the serving mobile access gateway MAY be able to 1881 dynamically generate this profile. The exact details on how this 1882 achieved is outside the scope of this document. However, this 1883 specification requires that a mobile access gateway serving a mobile 1884 node MUST have access to its policy profile. 1886 The following are the mandatory fields of the policy profile: 1888 o The mobile node's identifier (MN-Identifier) 1890 o The IPv6 address of the local mobility anchor (LMAA) 1892 The following are the optional fields of the policy profile: 1894 o The mobile node's IPv6 home network prefix(es) assigned to the 1895 mobile node's connected interface 1897 o The mobile node's IPv6 home network Prefix lifetime. This 1898 lifetime will be same for all the hosted prefixes on the link, as 1899 they all are part of one mobility session. 1901 o Supported address configuration procedures (Stateful, Stateless or 1902 both) for the mobile node in the Proxy Mobile IPv6 domain 1904 6.3. Supported Access Link Types 1906 This specification supports only point-to-point access link types and 1907 thus it assumes that the mobile node and the mobile access gateway 1908 are the only two nodes on the access link. The link is assumed to 1909 have multicast capability. 1911 This protocol may also be used on other link types, as long as the 1912 link is configured in such a way that it emulates point-to-point 1913 delivery between the mobile node and the mobile access gateway for 1914 all the protocol traffic. 1916 It is also necessary to be able to identify mobile nodes attaching to 1917 the link. Requirements relating to this are covered in Section 6.6. 1919 Finally, while this specification can operate without link layer 1920 indications of node attachment and detachment to the link, the 1921 existence of such indications either on the network or mobile node 1922 side improves the resulting performance. 1924 6.4. Supported Address Configuration Modes 1926 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1927 more global IPv6 addresses on its interface (using Stateless, 1928 Stateful or manual address autoconfiguration procedures) from the 1929 hosted prefix(es) on that link. The Router Advertisement messages 1930 sent on the access link specify the address configuration methods 1931 permitted on that access link for that mobile node. However, the 1932 advertised flags with respect to the address configuration will be 1933 consistent for a mobile node, on any of the access links in that 1934 Proxy Mobile IPv6 domain. Typically, these configuration settings 1935 will be based on the domain wide policy or based on a policy specific 1936 to each mobile node. 1938 When stateless address autoconfiguration is supported on the access 1939 link, the mobile node can generate one or more IPv6 addresses from 1940 the hosted prefix(es) by standard IPv6 mechanisms such as Stateless 1941 Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. 1943 When stateful address autoconfiguration is supported on the link, the 1944 mobile node can obtain the address configuration from the DHCP server 1945 located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms, 1946 as specified in [RFC-3315]. The obtained address(es) will be from 1947 its home network prefix(es). Section 6.11 specifies the details on 1948 how this configuration can be achieved. 1950 Additionally, other address configuration mechanisms specific to the 1951 access link between the mobile node and the mobile access gateway may 1952 also be used for delivering the address configuration to the mobile 1953 node. This specification does not modify the behavior of any of the 1954 standard IPv6 address configuration mechanisms. 1956 6.5. Access Authentication & Mobile Node Identification 1958 When a mobile node attaches to an access link connected to the mobile 1959 access gateway, the deployed access security protocols on that link 1960 SHOULD ensure that the network-based mobility management service is 1961 offered only after authenticating and authorizing the mobile node for 1962 that service. The exact specifics on how this is achieved or the 1963 interactions between the mobile access gateway and the access 1964 security service is outside the scope of this document. This 1965 specification goes with the stated assumption of having an 1966 established trust between the mobile node and the mobile access 1967 gateway, before the protocol operation begins. 1969 6.6. Acquiring Mobile Node's Identifier 1971 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1972 to identify a mobile node, using its MN-Identifier. This identifier 1973 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 1974 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 1975 this identifier in the signaling messages and unambiguously identify 1976 a given mobile node. Following are some of the considerations 1977 related to this MN-Identifier. 1979 o The MN-Identifier is typically obtained as part of the access 1980 authentication or from a notified network attachment event. In 1981 cases where the user identifier authenticated during access 1982 authentication uniquely identifies a mobile node, the MN- 1983 Identifier MAY be the same as the user identifier. However, the 1984 user identifier MUST NOT be used if it identifies a user account 1985 that can be used from more than one mobile node operating in the 1986 same Proxy Mobile IPv6 domain. 1988 o In some cases, the obtained identifier as part of the access 1989 authentication can be a temporary identifier and further that 1990 temporary identifier may be different at each re-authentication. 1991 However, the mobile access gateway MUST be able to use this 1992 temporary identifier and obtain the mobile node's stable 1993 identifier from the policy store. For instance, in AAA-based 1994 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1995 4372] may be used, as long as it uniquely identifies a mobile 1996 node, and not a user account that can be used with multiple mobile 1997 nodes. 1999 o In some cases and for privacy reasons, the MN-Identifier that the 2000 policy store delivers to the mobile access gateway may not be the 2001 true identifier of the mobile node. However, the mobility access 2002 gateway MUST be able to use this identifier in the signaling 2003 messages exchanged with the local mobility anchor. 2005 o The mobile access gateway MUST be able to identify the mobile node 2006 by its MN-Identifier and it MUST be able to associate this 2007 identity to the point-to-point link shared with the mobile node. 2009 6.7. Home Network Emulation 2011 One of the key functions of a mobile access gateway is to emulate the 2012 mobile node's home network on the access link. It must ensure, the 2013 mobile node does not detect any change with respect to its layer-3 2014 attachment even after it changes its point of attachment in that 2015 Proxy Mobile IPv6 domain. 2017 For emulating the mobile node's home link on the access link, the 2018 mobile access gateway must be able to send Router Advertisement 2019 messages advertising the mobile node's home network prefix(es) 2020 carried using the Prefix Information option(s) [RFC-4861] and with 2021 other address configuration parameters consistent with its home link 2022 properties. Typically, these configuration settings will be based on 2023 the domain wide policy or based on a policy specific to each mobile 2024 node. 2026 Typically, the mobile access gateway learns the mobile node's home 2027 network prefix(es) details from the received Proxy Binding 2028 Acknowledgement message or it may obtain them from the mobile node's 2029 policy profile. However, the mobile access gateway SHOULD send the 2030 Router Advertisements advertising the mobile node's home network 2031 prefix(es) only after successfully completing the binding 2032 registration with the mobile node's local mobility anchor. 2034 When advertising the home network prefix(es) in the Router 2035 Advertisement messages, the mobile access gateway MAY set the prefix 2036 lifetime value for the advertised prefix(es) to any chosen value at 2037 its own discretion. An implementation MAY choose to tie the prefix 2038 lifetime to the mobile node's binding lifetime. The prefix lifetime 2039 can also be an optional configuration parameter in the mobile node's 2040 policy profile. 2042 6.8. Link-Local and Global Address Uniqueness 2044 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 2045 mobile access gateway to the other, will continue to detect its home 2046 network and does not detect a change of layer-3 attachment. Every 2047 time the mobile node attaches to a new link, the event related to the 2048 interface state change will trigger the mobile node to perform DAD 2049 operation on the link-local and global address(es). However, if the 2050 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 2051 detect the link change due to DNAv6 optimizations and may not trigger 2052 the duplicate address detection (DAD) procedure for its existing 2053 addresses, which may potentially lead to address collisions after the 2054 mobile node's handoff to a new link. 2056 The issue of address collision is not relevant to the mobile node's 2057 global address(es). Since the assigned home network prefix(es) are 2058 for the mobile node's exclusive usage, no other node shares an 2059 address (other than Subnet-Router anycast address which is configured 2060 by the mobile access gateway) from the prefix(es) and so the 2061 uniqueness for the mobile node's global address is assured on the 2062 access link. 2064 The issue of address collision is however relevant to the mobile 2065 node's link-local addresses since the mobile access gateway and the 2066 mobile node will have link-local addresses configured from the same 2067 link-local prefix (FE80::/64). This leaves a room for link-local 2068 address collision between the two neighbors (i.e., the mobile node 2069 and the mobile access gateway) on that access link. For solving this 2070 problem, this specification requires that the link-local address that 2071 the mobile access gateway configures on the point-to-point link 2072 shared with a given mobile node be generated by the local mobility 2073 anchor and be stored in the mobile node's Binding Cache entry. This 2074 address will not change for the duration of that mobile node's 2075 session and can be provided to the serving mobile access gateway at 2076 every mobile node's handoff, as part of the Proxy Mobile IPv6 2077 signaling messages. The specific method by which the local mobility 2078 anchor generates the link-local address is out of scope for this 2079 specification. 2081 Optionally, implementations MAY choose to configure a fixed link- 2082 local address across all the access links in a Proxy Mobile IPv6 2083 domain and without a need for carrying this address from the local 2084 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 2085 signaling messages. 2087 6.9. Signaling Considerations 2089 6.9.1. Binding Registrations 2091 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 2093 1. After detecting a new mobile node on its access link, the mobile 2094 access gateway MUST identify the mobile node and acquire its MN- 2095 Identifier. If it determines that the network-based mobility 2096 management service needs to be offered to the mobile node, it 2097 MUST send a Proxy Binding Update message to the local mobility 2098 anchor. 2100 2. The Proxy Binding Update message MUST include the Mobile Node 2101 Identifier option [RFC-4283], carrying the MN-Identifier for 2102 identifying the mobile node. 2104 3. The Home Network Prefix option(s) MUST be present in the Proxy 2105 Binding Update message. If the mobile access gateway learns the 2106 mobile node's home network prefix(es) either from its policy 2107 store or from other means, the mobile access gateway MAY choose 2108 to request the local mobility anchor to allocate the requested 2109 prefix(es) by including a Home Network Prefix option for each of 2110 those requested prefixes. The mobile access gateway MAY also 2111 choose to include just one Home Network Prefix option with the 2112 prefix value of ALL_ZERO, for requesting the local mobility 2113 anchor to do the prefix assignment. However, when including a 2114 Home Network Prefix option with the prefix value of ALL_ZERO, 2115 then there MUST be only one instance of the Home Network prefix 2116 option in the request. 2118 4. The Handoff Indicator option MUST be present in the Proxy 2119 Binding Update message. The Handoff Indicator field in the 2120 Handoff Indicator option MUST be set to a value indicating the 2121 handoff hint. 2123 * The Handoff Indicator field MUST be set to value 1 2124 (Attachment over a new interface), if the mobile access 2125 gateway determines (under the Handoff Indicator 2126 considerations specified in this section) that the mobile 2127 node's current attachment to the network over this interface 2128 is not as a result of a handoff of an existing mobility 2129 session (over the same interface or through a different 2130 interface), but as a result of an attachment over a new 2131 interface. This essentially serves as a request to the local 2132 mobility anchor to create a new mobility session and not 2133 update any existing Binding Cache entry created for the same 2134 mobile node connected to the Proxy Mobile IPv6 domain through 2135 a different interface. 2137 * The Handoff Indicator field MUST be set to value 2 (Handoff 2138 between two different interfaces of the mobile node), if the 2139 mobile access gateway definitively knows the mobile node's 2140 current attachment is due to a handoff of an existing 2141 mobility session, between two different interfaces of the 2142 mobile node. 2144 * The Handoff Indicator field MUST be set to value 3 (Handoff 2145 between mobile access gateways for the same interface), if 2146 the mobile access gateway definitively knows the mobile 2147 node's current attachment is due to a handoff of an existing 2148 mobility session between two mobile access gateways and for 2149 the same interface of the mobile node. 2151 * The Handoff Indicator field MUST be set to value 4 (Handoff 2152 state unknown), if the mobile access gateway cannot determine 2153 if the mobile node's current attachment is due to a handoff 2154 of an existing mobility session. 2156 5. The mobile access gateway MUST apply the below considerations 2157 when choosing the value for the Handoff Indicator field. 2159 * The mobile access gateway can choose to use the value 2 2160 (Handoff between two different interfaces of the mobile 2161 node), only when it knows that the mobile node has on purpose 2162 switched from one interface to another, and the previous 2163 interface is going to be disabled. It may know this due to a 2164 number of factors. For instance, most cellular networks have 2165 controlled handovers where the network knows that the host is 2166 moving from one attachment to another. In this situation the 2167 link layer mechanism can inform the mobility functions that 2168 this is indeed a movement, not a new attachment. 2170 * Some link layers have link-layer identifiers that can be used 2171 to distinguish (a) the movement of a particular interface to 2172 a new attachment from (b) the attachment of a new interface 2173 from the same host. Option value 3 (Handoff between mobile 2174 access gateways for the same interface)is appropriate in case 2175 a and value of 1 (Attachment over a new interface) in case b. 2177 * The mobile access gateway MUST NOT set the option value to 2 2178 (Handoff between two different interfaces of the mobile node) 2179 or 3 (Handoff between mobile access gateways for the same 2180 interface) if it can not be determined that the mobile node 2181 can move the address between the interfaces involved in the 2182 handover or that it is the same interface that has moved. 2183 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2184 physical interfaces to the same domain may suffer unexpected 2185 failures. 2187 * Where no support from the link layer exists, the host and the 2188 network would need to inform each other about the intended 2189 movement. The Proxy Mobile IPv6 protocol does not specify 2190 this and simply requires that knowledge about movements can 2191 be derived either from the link-layer or from somewhere else. 2192 The method by which this is accomplished is outside the scope 2193 of this specification. 2195 6. Either the Timestamp option or a valid sequence number 2196 maintained on a per mobile node basis (if the Sequence Number 2197 based scheme is in use) MUST be present. When Timestamp option 2198 is added to the message, the mobile access gateway SHOULD also 2199 set the Sequence Number field to a value of a monotonically 2200 increasing counter (not to be confused with the per mobile node 2201 sequence number specified in [RFC-3775]). The local mobility 2202 anchor will ignore this field when there is a Timestamp option 2203 present in the request, but will return the same value in the 2204 Proxy Binding Acknowledgement message. This will be useful for 2205 matching the reply to the request message. 2207 7. The Mobile Node Link-layer Identifier option carrying the link- 2208 layer identifier of the currently attached interface MUST be 2209 present in the Proxy Binding Update message, if the mobile 2210 access gateway is aware of the same. If the link-layer 2211 identifier of the currently attached interface is not known or 2212 if the identifier value is ALL_ZERO, this option MUST NOT be 2213 present. 2215 8. The Access Technology Type option MUST be present in the Proxy 2216 Binding Update message. The access technology type field in the 2217 option SHOULD be set to the type of access technology using 2218 which the mobile node is currently attached to the mobile access 2219 gateway. 2221 9. The Link-local Address option MAY be present in the Proxy 2222 Binding Update message. Considerations from Section 6.8 MUST be 2223 applied when using the link-local address option. 2225 * When querying the local mobility anchor for the link-local 2226 address that it should use on the point-to-point link shared 2227 with the mobile node, this option MUST be set to ALL_ZERO. 2228 This essentially serves as a request to the local mobility 2229 anchor to provide the link-local address that it can use on 2230 the access link shared with the mobile node. 2232 * When uploading the link-local address to the local mobility 2233 anchor, the value in the option MUST be set to the link-local 2234 address that is configured on the point-to-point link shared 2235 with the mobile node. This is allowed only during an initial 2236 mobile node's attachment. 2238 10. The Proxy Binding Update message MUST be constructed as 2239 specified in Section 6.9.1.5. 2241 11. If there is no existing Binding Update List entry for that 2242 mobile node, the mobile access gateway MUST create a Binding 2243 Update List entry for the mobile node upon sending the Proxy 2244 Binding Update request. 2246 6.9.1.2. Receiving Binding Registration Reply 2248 On receiving a Proxy Binding Acknowledgement message (format 2249 specified in Section 8.2) from the local mobility anchor, the mobile 2250 access gateway MUST process the message as specified below. 2252 1. The received Proxy Binding Acknowledgement message (a Binding 2253 Acknowledgement message with the 'P' flag set to value of 1) 2254 MUST be authenticated as described in Section 4. When IPsec is 2255 used for message authentication, the SPI in the IPsec header 2256 [RFC-4306] of the received packet is needed for locating the 2257 security association, for authenticating the Proxy Binding 2258 Acknowledgement message. 2260 2. The mobile access gateway MUST observe the rules described in 2261 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2262 the received Proxy Binding Acknowledgement message. 2264 3. The mobile access gateway MUST apply the considerations 2265 specified in Section 5.5 for processing the Sequence Number 2266 field and the Timestamp option (if present), in the message. 2268 4. The mobile access gateway MUST ignore any checks, specified in 2269 [RFC-3775] related to the presence of a Type 2 Routing header in 2270 the Proxy Binding Acknowledgement message. 2272 5. The mobile access gateway MAY use the mobile node identifier 2273 present in the Mobile Node Identifier option for matching the 2274 response to the request messages that it sent recently. 2275 However, if there is more than one request message in its 2276 request queue for the same mobile node, the sequence number 2277 field can be used for identifying the exact message from those 2278 messages. There are other ways to achieve this and 2279 implementations are free to adopt the best approach that suits 2280 their implementation. Additionally, if the received Proxy 2281 Binding Acknowledgement message does not match any of the Proxy 2282 Binding Update messages that it sent recently, the message MUST 2283 be ignored. 2285 6. If the received Proxy Binding Acknowledgement message has any 2286 one or more of the following options, Handoff Indicator option, 2287 Access Technology Type option, Mobile Node Link-layer Identifier 2288 option, Mobile Node Identifier option, carrying option values 2289 that are different from the option values present in the 2290 corresponding request (Proxy Binding Update) message, the 2291 message MUST be ignored as the local mobility anchor is expected 2292 to echo back all these listed options and with the same option 2293 values in the reply message. Further, the mobile access gateway 2294 MUST NOT retransmit the Proxy Binding Update message till an 2295 administrative action is taken. 2297 7. If the received Proxy Binding Acknowledgement message has the 2298 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2299 registration not enabled for the mobile node), the mobile access 2300 gateway SHOULD NOT send binding registration requests again for 2301 that mobile node. It MUST deny the mobility service to that 2302 mobile node. 2304 8. If the received Proxy Binding Acknowledgement message has the 2305 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2306 (Timestamp value lower than previously accepted value), the 2307 mobile access gateway SHOULD try to register again to reassert 2308 the mobile node's presence on its access link. The mobile 2309 access gateway is not specifically required to synchronize its 2310 clock upon receiving this error code. 2312 9. If the received Proxy Binding Acknowledgement message has the 2313 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2314 value), the mobile access gateway SHOULD try to register again 2315 only after it has synchronized its clock to a common time source 2316 that is used by all the mobility entities in that domain for 2317 their clock synchronization. The mobile access gateway SHOULD 2318 NOT synchronize its clock to the local mobility anchor's system 2319 clock, based on the timestamp present in the received message. 2321 10. If the received Proxy Binding Acknowledgement message has the 2322 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2323 (The mobile node is not authorized for one or more of the 2324 requesting home network prefix(es)), the mobile access gateway 2325 SHOULD NOT request for the same prefix(es) again, but can only 2326 request the local mobility anchor to do the assignment of 2327 prefix(es) by including only one Home Network Prefix option with 2328 the prefix value set to ALL_ZERO. 2330 11. If the received Proxy Binding Acknowledgement message has the 2331 Status field value set to any value greater than or equal to 128 2332 (i.e., if the binding is rejected), the mobile access gateway 2333 MUST NOT advertise the mobile node's home network prefix(es) in 2334 the Router Advertisement messages sent on that access link and 2335 MUST deny the mobility service to the mobile node by not 2336 forwarding any packets received from the mobile node using an 2337 address from the home network prefix(es). It MAY also tear down 2338 the point-to-point link shared with the mobile node. 2340 12. If the received Proxy Binding Acknowledgement message has the 2341 Status field value set to 0 (Proxy Binding Update accepted), the 2342 mobile access gateway MUST establish a bi-directional tunnel to 2343 the local mobility anchor (if there is no existing bi- 2344 directional tunnel to that local mobility anchor). 2345 Considerations from Section 5.6.1 MUST be applied for managing 2346 the dynamically created bi-directional tunnel. 2348 13. The mobile access gateway MUST set up the route for forwarding 2349 the packets received from the mobile node using address(es) from 2350 its home network prefix(es) through the bi-directional set up 2351 for that mobile node. The created tunnel and the routing state 2352 MUST result in the forwarding behavior on the mobile access 2353 gateway as specified in Section 6.10.5. 2355 14. The mobile access gateway MUST also update the Binding Update 2356 List entry for reflecting the accepted binding registration 2357 values. It MUST also advertise the mobile node's home network 2358 prefix(es) as the hosted on-link prefixes, by including them in 2359 the Router Advertisement messages that it sends on that access 2360 link. 2362 15. If the received Proxy Binding Acknowledgement message has the 2363 address in the Link-local Address option set to a NON_ZERO 2364 value, the mobile access gateway MUST configure that link-local 2365 address on that point-to-point link and MUST NOT configure any 2366 other link-local address on that point-to-point link. This will 2367 avoid any link-local address collisions with the mobile node on 2368 that access link. 2370 6.9.1.3. Extending Binding Lifetime 2372 1. For extending the lifetime of a currently registered mobile node 2373 (i.e., after a successful initial binding registration from the 2374 same mobile access gateway), the mobile access gateway can send a 2375 Proxy Binding Update message to the local mobility anchor with a 2376 new lifetime value. This re-registration message MUST be 2377 constructed with the same set of options as the initial binding 2378 registration message, under the considerations specified in 2379 Section 6.9.1.1. However the following exceptions apply. 2381 2. There MUST be a Home Network Prefix option for each of the 2382 assigned home network prefixes assigned for that mobility session 2383 and with the prefix value in the option set to that respective 2384 prefix value. 2386 3. The Handoff Indicator field in the Handoff Indicator option MUST 2387 be set to a value of 5 (Handoff state not changed - Re- 2388 Registration). 2390 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2392 1. If at any point the mobile access gateway detects that the mobile 2393 node has moved away from its access link, or if it decides to 2394 terminate the mobile node's mobility session, it SHOULD send a 2395 Proxy Binding Update message to the local mobility anchor with 2396 the lifetime value set to zero. This de-registration message 2397 MUST be constructed with the same set of options as the initial 2398 binding registration message, under the considerations specified 2399 in Section 6.9.1.1. However, the following exceptions apply. 2401 2. There MUST be a Home Network Prefix option for each of the 2402 assigned home network prefix(es) assigned for that mobility 2403 session and with the prefix value in the option set to the 2404 respective prefix value. 2406 3. The Handoff Indicator field in the Handoff Indicator option MUST 2407 be set to a value of 4 (Handoff state unknown). 2409 Either upon receipt of a Proxy Binding Acknowledgement message from 2410 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2411 timeout waiting for the reply, the mobile access gateway MUST do the 2412 following: 2414 1. It MUST remove the Binding Update List entry for the mobile node 2415 from its Binding Update List. 2417 2. It MUST remove the created routing state for tunneling the mobile 2418 node's traffic. 2420 3. If there is a dynamically created tunnel to the mobile node's 2421 local mobility anchor and if there are not other mobile nodes for 2422 which the tunnel is being used, then the tunnel MUST be deleted. 2424 4. It MUST tear down the point-to-point link shared with the mobile 2425 node. This action will force the mobile node to remove any IPv6 2426 address configuration on the interface connected to this point- 2427 to-point link. 2429 6.9.1.5. Constructing the Proxy Binding Update Message 2431 o The mobile access gateway when sending the Proxy Binding Update 2432 request to the local mobility anchor MUST construct the message as 2433 specified below. 2435 IPv6 header (src=Proxy-CoA, dst=LMAA) 2436 Mobility header 2437 - BU /* P & A flags MUST be set to value 1 */ 2438 Mobility Options 2439 - Mobile Node Identifier option (mandatory) 2440 - Home Network Prefix option(s) (mandatory) 2441 - Handoff Indicator option (mandatory) 2442 - Access Technology Type option (mandatory) 2443 - Timestamp option (optional) 2444 - Mobile Node Link-layer Identifier option (optional) 2445 - Link-local Address option (optional) 2447 Figure 12: Proxy Binding Update message format 2449 o The Source Address field in the IPv6 header of the message MUST be 2450 set to the global address configured on the egress interface of 2451 the mobile access gateway. When there is no Alternate Care-of 2452 Address option present in the request, this address will be 2453 considered as the Proxy-CoA address for this binding registration 2454 request. However, when there is Alternate Care-of Address option 2455 present in the request, this address will be not be considered as 2456 the Proxy-CoA address, but the address in the alternate Care-of 2457 Address option will be considered as the Proxy-CoA address. 2459 o The Destination Address field in the IPv6 header of the message 2460 MUST be set to the local mobility anchor address. 2462 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2464 o At least one Home Network Prefix option MUST be present. 2466 o The Handoff Indicator option MUST be present. 2468 o The Access Technology Type option MUST be present. 2470 o The Timestamp option MAY be present. 2472 o The Mobile Node Link-layer Identifier option MAY be present. 2474 o The Link-local Address option MAY be present. 2476 o If IPsec is used for protecting the signaling messages, the 2477 message MUST be protected, using the security association existing 2478 between the local mobility anchor and the mobile access gateway. 2480 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2481 3775] MUST NOT be present in the IPv6 Destination Options 2482 extension header of the Proxy Binding Update message. 2484 6.9.2. Router Solicitation Messages 2486 A mobile node may send a Router Solicitation message on the access 2487 link shared with the mobile access gateway. The Router Solicitation 2488 message that the mobile node sends is as specified in [RFC-4861]. 2489 The mobile access gateway on receiving the Router Solicitation 2490 message or before sending a Router Advertisement message MUST apply 2491 the following considerations. 2493 1. The mobile access gateway on receiving the Router Solicitation 2494 message SHOULD send a Router Advertisement message containing the 2495 mobile node's home network prefix(es) as the on-link prefix(es). 2496 However, before sending the Router Advertisement message 2497 containing the mobile node's home network prefix(es), it SHOULD 2498 complete the binding registration process with the mobile node's 2499 local mobility anchor. 2501 2. If the local mobility anchor rejects the binding registration 2502 request, or, if the mobile access gateway failed to complete the 2503 binding registration process for whatever reason, the mobile 2504 access gateway MUST NOT advertise the mobile node's home network 2505 prefix(es) in the Router Advertisement messages that it sends on 2506 the access link. However, it MAY choose to advertise a local 2507 visited network prefix(es) to enable the mobile node for regular 2508 IPv6 access. 2510 3. The mobile access gateway SHOULD add the MTU option, as specified 2511 in [RFC-4861], to the Router Advertisement messages that it sends 2512 on the access link. This will ensure the mobile node on the link 2513 uses the advertised MTU value. The MTU value SHOULD reflect the 2514 tunnel MTU for the bi-directional tunnel between the mobile 2515 access gateway and the local mobility anchor. Considerations 2516 from Section 6.9.5 SHOULD be applied for determining the tunnel 2517 MTU value. 2519 6.9.3. Default-Router 2521 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2522 router for the mobile node on the access link. However, as the 2523 mobile node moves from one access link to another, the serving mobile 2524 access gateway on those respective links will send the Router 2525 Advertisement messages. If these Router Advertisements are sent 2526 using a different link-local address or a different link-layer 2527 address, the mobile node will always detect a new default-router 2528 after every handoff. For solving this problem, this specification 2529 requires all the mobile access gateways in the Proxy Mobile IPv6 2530 domain to use the same link-local and link-layer address on any of 2531 the access links where ever the mobile node attaches. These 2532 addresses can be fixed addresses across the entire Proxy Mobile IPv6 2533 domain and all the mobile access gateways can use these globally 2534 fixed address on any of the point-to-point links. Additionally, this 2535 specification allows the local mobility anchor to generate the link- 2536 local address and provide it to the mobile access gateway as part of 2537 the signaling messages. 2539 However, both of these approaches (a link-local address generated by 2540 the local mobility anchor or when using a globally fixed link-local 2541 address) have implications on the deployment of SEcure Neighbor 2542 Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and 2543 public key pairs, and their Router Advertisements are signed with the 2544 private keys of these key pairs. When a number of different routers 2545 use the same addresses, the routers either all have to be able to 2546 construct these signatures for the same key pair, or the used key 2547 pair and the router's cryptographic identity must change after a 2548 movement. Both approaches are problematic. Sharing of private key 2549 information across a number of nodes would be inappropriate. And 2550 changing even the cryptographic identity of the router goes against 2551 the general idea of the Proxy Mobile IPv6 being as invisible to the 2552 hosts as possible. 2554 There is, however, ongoing work at the IETF to revise the SEND 2555 specifications. It is suggested that these revisions also address 2556 the above problem. Other revisions are needed to deal with other 2557 problematic cases (such as Neighbor Discovery proxies) before wide- 2558 spread deployment of SEND. 2560 6.9.4. Retransmissions and Rate Limiting 2562 The mobile access gateway is responsible for retransmissions and rate 2563 limiting the binding registration requests that it sends to the local 2564 mobility anchor. The Retransmission and the Rate Limiting rules are 2565 as specified in [RFC-3775]. However, the following considerations 2566 MUST be applied. 2568 1. When the mobile access gateway sends a Proxy Binding Update 2569 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2570 [RFC-3775], for configuring the retransmission timer, as 2571 specified in Section 11.8 [RFC-3775]. However, the mobile access 2572 gateway is not required to use a longer retransmission interval 2573 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2574 the initial binding registration request. 2576 2. If the mobile access gateway fails to receive a valid matching 2577 response for a registration or re-registration message within the 2578 retransmission interval, it SHOULD retransmit the message until a 2579 response is received. However, the mobile access gateway MUST 2580 ensure the mobile node is still attached to the connected link 2581 before retransmitting the message. 2583 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2584 gateway MUST use an exponential back-off process in which the 2585 timeout period is doubled upon each retransmission, until either 2586 the node receives a response or the timeout period reaches the 2587 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2588 MAY continue to send these messages at this slower rate 2589 indefinitely. 2591 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2592 Binding Update messages MUST use the latest timestamp. If the 2593 Sequence number scheme is in use, the retransmitted Proxy Binding 2594 Update messages MUST use a Sequence Number value greater than 2595 that used for the previous transmission of this Proxy Binding 2596 Update message, just as specified in [RFC-3775]. 2598 6.9.5. Path MTU Discovery 2600 It is important that mobile node, mobile access gateway, and local 2601 mobility anchor have a correct understanding of MTUs. When the 2602 mobile node uses the correct MTU, it can send packets that do not 2603 exceed the local link MTU and do not cause the tunneled packets from 2604 the mobile access gateway to be fragmented. This is important both 2605 from the perspective of efficiency, as well as preventing hard-to- 2606 diagnose MTU problems. The following are some of the considerations 2607 related to Path MTU discovery. 2609 o The local mobility anchor and mobile access gateway MAY use the 2610 Path MTU Discovery mechanisms as specified in [RFC-1981] or in 2611 [RFC-4821] for determining the Path MTU (PMTU) for the (LMA-MAG) 2612 paths. The specific discovery mechanism to be used in a given 2613 deployment can be configurable. 2615 o The mobility entities MUST implement and SHOULD support ICMP-based 2616 Path MTU discovery mechanism as specified in [RFC-1981]. However, 2617 this mechanism may not work correctly if the Proxy Mobile IPv6 2618 network does not deliver or process ICMP Packet Too Big messages. 2620 o The mobility entities MAY implement Packetization Layer Path MTU 2621 discovery mechanisms as specified in [RFC-4821] and use any 2622 application traffic as a payload for the PMTU discovery. Neither 2623 the Proxy Mobile IPv6 protocol or the tunnel between the mobile 2624 access gateway and local mobility agent can easily be used for 2625 this purpose. However, implementations SHOULD support at least 2626 the use of an explicit ICMP Echo Request/Response for this 2627 purpose. 2629 o The mobility entities MAY choose to perform Path MTU discovery for 2630 all the (LMA-MAG) paths at the boot time and may repeat this 2631 operation periodically to ensure the Path MTU values have not 2632 changed for those paths. If the dynamic PMTU discovery mechanisms 2633 fail to determine the Path MTU, an administratively configured 2634 default value MUST be used. 2636 o The IPv6 tunnel MTU for an established tunnel between the local 2637 mobility anchor and the mobile access gateway MUST be computed 2638 based on the determined Path MTU value for that specific path and 2639 the computation should be as specified in Section 6.7 of [RFC- 2640 2473]. 2642 o The mobile access gateway SHOULD use the determined tunnel Path 2643 MTU value (for the tunnel established with the mobile node's local 2644 mobility anchor) as the MTU value in the MTU option that it sends 2645 in the Router Advertisements on the access link shared with the 2646 mobile node. 2648 o If the mobile access gateway detects a change in MTU value for any 2649 of the paths (LMA-MAG) and at any point of time, the corresponding 2650 tunnel MTU value MUST be updated to reflect the change in Path MTU 2651 value. The adjusted tunnel MTU value SHOULD be notified to the 2652 impacted mobile nodes by sending additional Router Advertisement 2653 messages. Additionally, the adjusted tunnel MTU value MUST be 2654 used in all the subsequent Router Advertisement messages as well. 2656 6.10. Routing Considerations 2658 This section describes how the mobile access gateway handles the 2659 traffic to/from the mobile node that is attached to one of its access 2660 interfaces. 2662 Proxy-CoA LMAA 2663 | | 2664 +--+ +---+ +---+ +--+ 2665 |MN|----------|MAG|======================|LMA|----------|CN| 2666 +--+ +---+ +---+ +--+ 2667 IPv6 Tunnel 2669 Figure 13: Proxy Mobile IPv6 Tunnel 2671 6.10.1. Transport Network 2673 As per this specification, the transport network between the local 2674 mobility anchor and the mobile access gateway is an IPv6 network. 2675 The companion document [ID-IPV4-PMIP6] specifies the required 2676 extensions for negotiating IPv4 transport and the corresponding 2677 encapsulation mode. 2679 6.10.2. Tunneling & Encapsulation Modes 2681 An IPv6 address that a mobile node uses from its home network 2682 prefix(es) is topologically anchored at the local mobility anchor. 2683 For a mobile node to use this address from an access network attached 2684 to a mobile access gateway, proper tunneling techniques have to be in 2685 place. Tunneling hides the network topology and allows the mobile 2686 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2687 packet and to be routed between the local mobility anchor and the 2688 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2689 defines the use of IPv6-over-IPv6 tunneling [RFC-2473], between the 2690 home agent and the mobile node and this specification extends the use 2691 of the same tunneling mechanism for use between the local mobility 2692 anchor and the mobile access gateway. 2694 On most operating systems, a tunnel is implemented as a virtual 2695 point-to-point interface. The source and the destination address of 2696 the two end points of this virtual interface along with the 2697 encapsulation mode are specified for this virtual interface. Any 2698 packet that is routed over this interface gets encapsulated with the 2699 outer header as specified for that point to point tunnel interface. 2701 For creating a point to point tunnel to any local mobility anchor, 2702 the mobile access gateway may implement a tunnel interface with the 2703 source address field set to a global address on its egress interface 2704 (Proxy-CoA) and the destination address field set to the global 2705 address of the local mobility anchor (LMAA). 2707 The following is the supported packet encapsulation mode that can be 2708 used by the mobile access gateway and the local mobility anchor for 2709 routing mobile node's IPv6 datagrams. 2711 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2712 2473]. 2714 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2715 modes for supporting IPv4 transport. 2717 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2718 details on how this mode is negotiated is specified in [ID-IPV4- 2719 PMIP6]. 2721 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2722 packet. This mode is specified in [ID-IPV4-PMIP6]. 2724 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2725 packet with a TLV header. This mode is specified in [ID-IPV4- 2726 PMIP6]. 2728 6.10.3. Local Routing 2730 If there is data traffic between a visiting mobile node and a 2731 correspondent node that is locally attached to an access link 2732 connected to the mobile access gateway, the mobile access gateway MAY 2733 optimize on the delivery efforts by locally routing the packets and 2734 by not reverse tunneling them to the mobile node's local mobility 2735 anchor. The flag EnableMAGLocalRouting MAY be used for controlling 2736 this behavior. However, in some systems, this may have an 2737 implication on the mobile node's accounting and policy enforcement as 2738 the local mobility anchor is not in the path for that traffic and it 2739 will not be able to apply any traffic policies or do any accounting 2740 for those flows. 2742 This decision of path optimization SHOULD be based on the policy 2743 configured on the mobile access gateway, but enforced by the mobile 2744 node's local mobility anchor. The specific details on how this is 2745 achieved are beyond of the scope of this document. 2747 6.10.4. Tunnel Management 2749 All the considerations mentioned in Section 5.6.1 for the tunnel 2750 management on the local mobility anchor apply for the mobile access 2751 gateway as well. 2753 6.10.5. Forwarding Rules 2755 Forwarding Packets sent to the Mobile Node's Home Network: 2757 o On receiving a packet from the bi-directional tunnel established 2758 with the mobile node's local mobility anchor, the mobile access 2759 gateway MUST use the destination address of the inner packet for 2760 forwarding it on the interface where the destination network 2761 prefix is hosted. The mobile access gateway MUST remove the outer 2762 header before forwarding the packet. Considerations from [RFC- 2763 2473] MUST be applied for IPv6 decapsulation. If the mobile 2764 access gateway cannot find the connected interface for that 2765 destination address, it MUST silently drop the packet. For 2766 reporting an error in such a scenario, in the form of ICMP control 2767 message, the considerations from [RFC-2473] MUST be applied. 2769 o On receiving a packet from a correspondent node that is locally 2770 connected and which is destined to a mobile node that is on 2771 another locally connected access link, the mobile access gateway 2772 MUST check the flag EnableMAGLocalRouting, to ensure the mobile 2773 access gateway is allowed to route the packet directly to the 2774 mobile node. If the mobile access gateway is not allowed to route 2775 the packet directly, it MUST route the packet through the bi- 2776 directional tunnel established between itself and the mobile 2777 node's local mobility anchor. Otherwise, it can route the packet 2778 directly to the mobile node. 2780 Forwarding Packets Sent by the Mobile Node: 2782 o On receiving a packet from a mobile node connected to its access 2783 link, the mobile access gateway MUST ensure that there is an 2784 established binding for that mobile node with its local mobility 2785 anchor before forwarding the packet directly to the destination or 2786 before tunneling the packet to the mobile node's local mobility 2787 anchor. 2789 o On receiving a packet from a mobile node connected to its access 2790 link for a destination that is locally connected, the mobile 2791 access gateway MUST check the flag EnableMAGLocalRouting, to 2792 ensure the mobile access gateway is allowed to route the packet 2793 directly to the destination. If the mobile access gateway is not 2794 allowed to route the packet directly, it MUST route the packet 2795 through the bi-directional tunnel established between itself and 2796 the mobile node's local mobility anchor. Otherwise, it MUST route 2797 the packet directly to the destination. 2799 o On receiving a packet from a mobile node connected to its access 2800 link, to a destination that is not directly connected, the packet 2801 MUST be forwarded to the local mobility anchor through the bi- 2802 directional tunnel established between itself and the mobile 2803 node's local mobility anchor. However, the packets that are sent 2804 with the link-local source address MUST NOT be forwarded. 2806 o The format of the tunneled packet is shown below. Considerations 2807 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 2808 when using IPv4 transport, the format of the tunneled packet is as 2809 described in [ID-IPV4-PMIP6]. 2811 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2812 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2813 Upper layer protocols /* Packet Content*/ 2815 Figure 14: Tunneled Packet from MAG to LMA 2817 o The format of the tunneled packet is shown below, when payload 2818 protection using IPsec is enabled for the mobile node's data 2819 traffic. However, when using IPv4 transport, the format of the 2820 packet is as described in [ID-IPV4-PMIP6]. 2822 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2823 ESP Header in tunnel mode /* ESP Header */ 2824 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2825 Upper layer protocols /* Packet Content*/ 2827 Figure 15: Tunneled Packet from MAG to LMA with Payload Protection 2829 6.11. Supporting DHCP based Address Configuration on the Access Link 2831 This section explains how Stateful Address Configuration using DHCP 2832 support can be enabled in a Proxy Mobile IPv6 domain. It also 2833 identifies the required configuration in DHCP and mobility 2834 infrastructures for supporting this address configuration mode and 2835 also identifies the protocol interactions between these two systems. 2837 o For supporting Stateful Address Configuration using DHCP, the DHCP 2838 relay agent [RFC-3315] service MUST be supported on all the mobile 2839 access gateways in the Proxy Mobile IPv6 domain. Further, as 2840 specified in Section 20 of [RFC-3315], the DHCP relay agent should 2841 be configured to use a list of destination addresses, which MAY 2842 include unicast addresses, the All_DHCP_Servers multicast address, 2843 or other addresses as required in a given deployment. 2845 o The DHCP infrastructure needs to be configured to assign addresses 2846 from each of the prefixes assigned to a link in that Proxy Mobile 2847 IPv6 domain. The DHCP relay agent indicates the link to which the 2848 mobile node is attached by including an IPv6 address from any of 2849 the prefixes assigned to that link in the link-address field of 2850 the Relay Forward message. Therefore, for each link in the Mobile 2851 IPv6 domain, the DHCP infrastructure will: 2853 * be configured with a list of all of the prefixes associated 2854 with that link; 2856 * identify the link to which the mobile node is attached by 2857 looking up the prefix for the link-address field in the Relay 2858 Forward message in the list of prefixes associated with each 2859 link 2861 * assign to the host an address from each prefix associated with 2862 the link to which the mobile node is attached. 2864 This DHCP infrastructure configuration requirement is identical 2865 with other IPv6 networks; other than receiving DHCP messages from 2866 a mobile node through different relay agents (MAGs) over time, the 2867 DHCP infrastructure will be unaware of the mobile node's 2868 capability with respect to mobility support. 2870 o The local mobility anchor needs to have the same awareness with 2871 respect to the links along with the associated prefixes in a Proxy 2872 Mobile IPv6 domain. When a local mobility anchor assigns 2873 prefix(es) to a mobile node, it MUST assign all the prefixes 2874 associated with a given link and all of those assigned prefixes 2875 will remain as the home network prefixes for that mobile node 2876 through out the life of that mobility session. The serving mobile 2877 access gateway that hosts these prefixes is physically connected 2878 to that link and can function as the DHCP relay agent. This 2879 common understanding between DHCP and mobility entities about all 2880 the links in the domain along with the associated prefixes, 2881 provides the required coordination for allowing mobility entities 2882 to perform prefix assignment dynamically to a mobile node and 2883 still allow the DHCP infrastructure to perform address assignment 2884 for that mobile node only from its home network prefixes. 2886 o When a mobile node sends a DHCP request message, the DHCP relay 2887 agent function on the mobile access gateway will set the link- 2888 address field in the DHCP message to an address in the mobile 2889 node's home network prefix (any one of the mobile node's home 2890 network prefixes assigned to that mobile node's attached 2891 interface). The mobile access gateway can generate an 2892 autoconfiguration address from one of the mobile node's home 2893 network prefixes [RFC-4862] and can use this address link-address 2894 option, so as to provide a hint to the DHCP Server for the link 2895 identification. The DHCP server on receiving the request from the 2896 mobile node, will allocate addresses from all the prefixes 2897 associated with that link (identified using the link-address field 2898 of the request). 2900 o Once the mobile node obtains address(es) and moves to a different 2901 link and sends a DHCP request (at any time) for extending the DHCP 2902 lease, the DHCP relay agent on the new link will set the link- 2903 address field in the DHCP Relay Forward message to one of the 2904 mobile node's home network prefixes. The DHCP server will 2905 identify the client from the Client-DUID option and will identify 2906 the link from the link-address option present in the request and 2907 will allocate the same address(es) as before. 2909 o For correct operation of the model of network-based mobility 2910 management in which the host does not participate in any mobility 2911 management, the mobile node MUST always be assigned an identical 2912 set of IPv6 addresses regardless of the access link to which the 2913 mobile node is attached. For example, the mobile access gateways 2914 in the Proxy Mobile IPv6 domain should be configured so that DHCP 2915 messages from a mobile node will always be handled by the same 2916 DHCP server or by a server from the same group of coordinated DHCP 2917 servers serving that domain. DHCP based address configuration is 2918 not recommended for deployments in which the local mobility anchor 2919 and the mobile access gateway are located in different 2920 administrative domains. 2922 6.12. Home Network Prefix Renumbering 2924 If the mobile node's home network prefix(es) gets renumbered or 2925 becomes invalid during the middle of a mobility session, the mobile 2926 access gateway MUST withdraw the prefix(es) by sending a Router 2927 Advertisement message on the access link with zero prefix lifetime 2928 for the prefix(es) that is being renumbered. Also, the local 2929 mobility anchor and the mobile access gateway MUST delete the created 2930 routing state for the renumbered prefix(es). However, the specific 2931 details on how the local mobility anchor notifies the mobile access 2932 gateway about the mobile node's home network prefix(es) renumbering 2933 are outside the scope of this document. 2935 6.13. Mobile Node Detachment Detection and Resource Cleanup 2937 Before sending a Proxy Binding Update message to the local mobility 2938 anchor for extending the lifetime of a currently existing binding of 2939 a mobile node, the mobile access gateway MUST make sure the mobile 2940 node is still attached to the connected link by using some reliable 2941 method. If the mobile access gateway cannot predictably detect the 2942 presence of the mobile node on the connected link, it MUST NOT 2943 attempt to extend the registration lifetime of the mobile node. 2945 Further, in such a scenario, the mobile access gateway SHOULD 2946 terminate the binding of the mobile node by sending a Proxy Binding 2947 Update message to the mobile node's local mobility anchor with 2948 lifetime value set to 0. It MUST also remove any local state such as 2949 the Binding Update List entry created for that mobile node. 2951 The specific detection mechanism of the loss of a visiting mobile 2952 node on the connected link is specific to the access link between the 2953 mobile node and the mobile access gateway and is outside the scope of 2954 this document. Typically, there are various link-layer specific 2955 events specific to each access technology that the mobile access 2956 gateway can depend on for detecting the node loss. In general, the 2957 mobile access gateway can depend on one or more of the following 2958 methods for the detection presence of the mobile node on the 2959 connected link: 2961 o Link-layer event specific to the access technology 2963 o PPP Session termination event on point-to-point link types 2965 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2967 o Notification event from the local mobility anchor 2969 6.14. Allowing network access to other IPv6 nodes 2971 In some Proxy Mobile IPv6 deployments, network operators may want to 2972 provision the mobile access gateway to offer network-based mobility 2973 management service only to some visiting mobile nodes and enable just 2974 regular IP access to some other nodes. This requires the network to 2975 have control on when to enable network-based mobility management 2976 service to a mobile node and when to enable regular IPv6 access. 2977 This specification does not disallow such configuration. 2979 Upon detecting a mobile node on its access link and after policy 2980 considerations, the mobile access gateway MUST determine if network- 2981 based mobility management service should be offered to that mobile 2982 node. If the mobile node is entitled for network-based mobility 2983 management service, then the mobile access gateway must ensure the 2984 mobile node does not detect any change with respect to its layer-3 2985 attachment, as explained in various sections of this specification. 2987 If the mobile node is not entitled for the network-based mobility 2988 management service, as determined from the policy considerations, the 2989 mobile access gateway MAY choose to offer regular IPv6 access to the 2990 mobile node and in such a scenario the normal IPv6 considerations 2991 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2992 obtain IPv6 address(es) using the normal IPv6 address configuration 2993 procedures. The obtained address(es) must be from a local visitor 2994 network prefix(es). This essentially ensures that the mobile access 2995 gateway functions as a normal access router to a mobile node attached 2996 to its access link and without impacting its host-based mobility 2997 protocol operation. 2999 7. Mobile Node Operation 3001 This non-normative section explains the mobile node's operation in a 3002 Proxy Mobile IPv6 domain. 3004 7.1. Moving into a Proxy Mobile IPv6 Domain 3006 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 3007 an access network, the mobile access gateway on the access link 3008 detects the attachment of the mobile node and completes the binding 3009 registration with the mobile node's local mobility anchor. If the 3010 binding update operation is successfully performed, the mobile access 3011 gateway will create the required state and set up the data path for 3012 the mobile node's data traffic. 3014 If the mobile node is IPv6 enabled, on attaching to the access link, 3015 it will typically send a Router Solicitation message [RFC-4861]. The 3016 mobile access gateway on the access link will respond to the Router 3017 Solicitation message with a Router Advertisement message. The Router 3018 Advertisement message will carry the mobile node's home network 3019 prefix(es), default-router address and other address configuration 3020 Parameters. 3022 If the mobile access gateway on the access link receives a Router 3023 Solicitation message from the mobile node, before it completes the 3024 signaling with the mobile node's local mobility anchor, the mobile 3025 access gateway may not know the mobile node's home network prefix(es) 3026 and may not be able to emulate the mobile node's home link on the 3027 access link. In such a scenario, the mobile node may notice a delay 3028 before it receives a Router Advertisement message. This will also 3029 affect mobile nodes that would be capable of handling their own 3030 mobility, or mobile nodes that do not need to maintain the same IP 3031 address through movements. 3033 If the received Router Advertisement message has the Managed Address 3034 Configuration flag set, the mobile node, as it would normally do, 3035 will send a DHCP Request [RFC-3315]. The DHCP relay service enabled 3036 on that access link will ensure the mobile node can obtain one or 3037 more addresses from its home network prefix(es). 3039 If the received Router Advertisement message does not have the 3040 Managed Address Configuration flag set and if the mobile node is 3041 allowed to use autoconfigured address(es), the mobile node will be 3042 able to obtain IPv6 address(es) and from each of its home network 3043 prefixes using any of the standard IPv6 address configuration 3044 mechanisms permitted for that mode. 3046 If the mobile node is IPv4 enabled and if the network permits, it 3047 will be able to obtain the IPv4 address configuration as specified in 3048 the companion document [ID-IPV4-PMIP6]. 3050 Once the address configuration is complete, the mobile node can 3051 continue to use this address configuration as long as it is attached 3052 to the network that is in the scope of that Proxy Mobile IPv6 domain. 3054 7.2. Roaming in the Proxy Mobile IPv6 Domain 3056 After obtaining the address configuration in the Proxy Mobile IPv6 3057 domain, as the mobile node moves and changes its point of attachment 3058 from one mobile access gateway to the other, it can still continue to 3059 use the same address configuration. As long as the attached access 3060 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 3061 node will always detect the same router advertising itself as a 3062 default-router and advertising the mobile node's home network 3063 prefix(es) on each connected link. If the mobile node has address 3064 configuration that it obtained using DHCP, it will be able to retain 3065 the address configuration and extend the lease lifetime. 3067 8. Message Formats 3069 This section defines extensions to the Mobile IPv6 [RFC-3775] 3070 protocol messages. 3072 8.1. Proxy Binding Update Message 3074 0 1 2 3 3075 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 3076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3077 | Sequence # | 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 |A|H|L|K|M|R|P| Reserved | Lifetime | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | | 3082 . . 3083 . Mobility options . 3084 . . 3086 | | 3087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3089 A Binding Update message that is sent by a mobile access gateway to a 3090 local mobility anchor is referred to as the "Proxy Binding Update" 3091 message. A new flag (P) is included in the Binding Update message. 3092 The rest of the Binding Update message format remains the same as 3093 defined in [RFC-3775] and with the additional (R) and (M) flags as 3094 specified in [RFC-3963] and [RFC-4140] respectively. 3096 Proxy Registration Flag (P) 3098 A new flag (P) is included in the Binding Update message to 3099 indicate to the local mobility anchor that the Binding Update 3100 message is a proxy registration. The flag MUST be set to the 3101 value of 1 for proxy registrations and MUST be set to 0 for direct 3102 registrations sent by a mobile node. 3104 Mobility Options 3106 Variable-length field of such length that the complete Mobility 3107 Header is an integer multiple of 8 octets long. This field 3108 contains zero or more TLV-encoded mobility options. The encoding 3109 and format of defined options are described in Section 6.2 of 3110 [RFC-3775]. The local mobility anchor MUST ignore and skip any 3111 options which it does not understand. 3113 As per this specification, the following mobility options are 3114 valid in a Proxy Binding Update message. These options can be 3115 present in the message in any order. There can be one or more 3116 instances of the Home Network Prefix options present in the 3117 message. However, there cannot be more than one instance of any 3118 of the other options. 3120 Mobile Node Identifier option 3122 Home Network Prefix option 3124 Handoff Indicator option 3126 Access Technology Type option 3128 Timestamp option 3130 Mobile Node Link-layer Identifier option 3132 Link-local Address option 3134 Additionally, there can one or more instances of the Vendor- 3135 Specific Mobility option [RFC-5094]. 3137 For descriptions of other fields present in this message, refer to 3138 section 6.1.7 of [RFC-3775]. 3140 8.2. Proxy Binding Acknowledgement Message 3142 0 1 2 3 3143 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 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 | Status |K|R|P|Reserved | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | Sequence # | Lifetime | 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3149 | | 3150 . . 3151 . Mobility options . 3152 . . 3153 | | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 A Binding Acknowledgement message that is sent by a local mobility 3157 anchor to a mobile access gateway is referred to as the "Proxy 3158 Binding Acknowledgement" message. A new flag (P) is included in the 3159 Binding Acknowledgement message. The rest of the Binding 3160 Acknowledgement message format remains the same as defined in [RFC- 3161 3775] and with the additional (R) flag as specified in [RFC-3963]. 3163 Proxy Registration Flag (P) 3165 A new flag (P) is included in the Binding Acknowledgement message 3166 to indicate that the local mobility anchor that processed the 3167 corresponding Proxy Binding Update message supports proxy 3168 registrations. The flag is set to value of 1 only if the 3169 corresponding Proxy Binding Update had the Proxy Registration Flag 3170 (P) set to value of 1. 3172 Mobility Options 3174 Variable-length field of such length that the complete Mobility 3175 Header is an integer multiple of 8 octets long. This field 3176 contains zero or more TLV-encoded mobility options. The encoding 3177 and format of defined options are described in Section 6.2 of 3178 [RFC-3775]. The mobile access gateway MUST ignore and skip any 3179 options which it does not understand. 3181 As per this specification, the following mobility options are 3182 valid in a Proxy Binding Acknowledgement message. These options 3183 can be present in the message in any order. There can be one or 3184 more instances of the Home Network Prefix options present in the 3185 message. However, there cannot be more than one instance of any 3186 of the other options. 3188 Mobile Node Identifier option 3190 Home Network Prefix option 3192 Handoff Indicator option 3194 Access Technology Type option 3196 Timestamp option 3198 Mobile Node Link-layer Identifier option 3200 Link-local Address option 3202 Additionally, there can one or more instances of the Vendor- 3203 Specific Mobility option [RFC-5094]. 3205 Status 3207 8-bit unsigned integer indicating the disposition of the Proxy 3208 Binding Update. Values of the Status field less than 128 indicate 3209 that the Proxy Binding Update was accepted by the local mobility 3210 anchor. Values greater than or equal to 128 indicate that the 3211 binding registration was rejected by the local mobility anchor. 3212 Section 8.9 defines the Status values that can used in Proxy 3213 Binding Acknowledgement message. 3215 For descriptions of other fields present in this message, refer to 3216 the section 6.1.8 of [RFC-3775]. 3218 8.3. Home Network Prefix Option 3220 A new option, Home Network Prefix Option is defined for using it in 3221 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3222 exchanged between a local mobility anchor and a mobile access 3223 gateway. This option is used for exchanging the mobile node's home 3224 network prefix information. There can be multiple Home Network 3225 Prefix options present in the message. 3227 The Home Network Prefix Option has an alignment requirement of 8n+4. 3228 Its format is as follows: 3230 0 1 2 3 3231 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 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | Type | Length | Reserved | Prefix Length | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | | 3236 + + 3237 | | 3238 + Home Network Prefix + 3239 | | 3240 + + 3241 | | 3242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3244 Type 3245 3247 Length 3249 8-bit unsigned integer indicating the length of the option 3250 in octets, excluding the type and length fields. This field 3251 MUST be set to 18. 3253 Reserved (R) 3255 This 8-bit field is unused for now. The value MUST be 3256 initialized to 0 by the sender and MUST be ignored by the 3257 receiver. 3259 Prefix Length 3261 8-bit unsigned integer indicating the prefix length of the 3262 IPv6 prefix contained in the option. 3264 Home Network Prefix 3266 A sixteen-byte field containing the mobile node's IPv6 Home 3267 Network Prefix. 3269 8.4. Handoff Indicator Option 3271 A new option, Handoff Indicator Option is defined for using it in the 3272 Proxy Binding Update and Proxy Binding Acknowledgement messages 3273 exchanged between a local mobility anchor and a mobile access 3274 gateway. This option is used for exchanging the mobile node's 3275 handoff related hints. 3277 The Handoff Indicator Option has no alignment requirement. Its 3278 format is as follows: 3280 0 1 2 3 3281 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 3282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3283 | Type | Length | Reserved (R) | HI | 3284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 Type 3287 3289 Length 3291 8-bit unsigned integer indicating the length of the option 3292 in octets, excluding the type and length fields. This field 3293 MUST be set to 2. 3295 Reserved (R) 3297 This 8-bit field is unused for now. The value MUST be 3298 initialized to 0 by the sender and MUST be ignored by the 3299 receiver. 3301 Handoff Indicator (HI) 3303 A 8-bit field that specifies the type of handoff. The values 3304 (0 - 255) will be allocated and managed by IANA. The following 3305 values are currently defined. 3307 0: Reserved 3308 1: Attachment over a new interface 3309 2: Handoff between two different interfaces of the mobile node 3310 3: Handoff between mobile access gateways for the same interface 3311 4: Handoff state unknown 3312 5: Handoff state not changed (Re-registration) 3314 8.5. Access Technology Type Option 3316 A new option, Access Technology Type Option is defined for using it 3317 in the Proxy Binding Update and Proxy Binding Acknowledgement 3318 messages exchanged between a local mobility anchor and a mobile 3319 access gateway. This option is used for exchanging the type of the 3320 access technology using which the mobile node is currently attached 3321 to the mobile access gateway. 3323 The Access Technology Type Option has no alignment requirement. Its 3324 format is as follows: 3326 0 1 2 3 3327 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 3328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3329 | Type | Length | Reserved (R) | ATT | 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3332 Type 3333 3335 Length 3337 8-bit unsigned integer indicating the length of the option 3338 in octets, excluding the type and length fields. This field 3339 MUST be set to 2. 3341 Reserved (R) 3343 This 8-bit field is unused for now. The value MUST be 3344 initialized to 0 by the sender and MUST be ignored by the 3345 receiver. 3347 Access Technology Type (ATT) 3349 A 8-bit field that specifies the access technology through 3350 which the mobile node is connected to the access link on the 3351 mobile access gateway. 3353 The values (0 - 255) will be allocated and managed by IANA. The 3354 following values are currently reserved for the below specified 3355 access technology types. 3357 0: Reserved ("Reserved") 3358 1: Virtual ("Logical Network Interface") 3359 2: PPP ("Point-to-Point Protocol") 3360 3: IEEE 802.3 ("Ethernet") 3361 4: IEEE 802.11a/b/g ("Wireless LAN") 3362 5: IEEE 802.16e ("WIMAX") 3364 8.6. Mobile Node Link-layer Identifier Option 3366 A new option, Mobile Node Link-layer Identifier Option is defined for 3367 using it in the Proxy Binding Update and Proxy Binding 3368 Acknowledgement messages exchanged between a local mobility anchor 3369 and a mobile access gateway. This option is used for exchanging the 3370 mobile node's link-layer identifier. 3372 The format of the Link-layer Identifier option is shown below. Based 3373 on the size of the identifier, the option MUST be aligned 3374 appropriately, as per mobility option alignment requirements 3375 specified in [RFC-3775]. 3377 0 1 2 3 3378 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 3379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3380 | Type | Length | Reserved | 3381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3382 | | 3383 + Link-layer Identifier + 3384 . ... . 3385 | | 3386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 Type 3389 3391 Length 3392 8-bit unsigned integer indicating the length of the option 3393 in octets, excluding the type and length fields. 3395 Reserved 3397 This field is unused for now. The value MUST be initialized to 3398 0 by the sender and MUST be ignored by the receiver. 3400 Link-layer Identifier 3402 A variable length field containing the mobile node's link-layer 3403 identifier. 3405 The content and format of this field (including byte and bit 3406 ordering) is as specified in Section 4.6 of [RFC-4861] for 3407 carrying Link-Layer Address. On certain access links, where 3408 the link-layer address is not used or cannot be determined, 3409 this option cannot be used. 3411 8.7. Link-local Address Option 3413 A new option, Link-local Address Option is defined for using it in 3414 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3415 exchanged between a local mobility anchor and a mobile access 3416 gateway. This option is used for exchanging the link-local address 3417 of the mobile access gateway. 3419 The Link-local Address option has an alignment requirement of 8n+6. 3420 Its format is as follows: 3422 0 1 2 3 3423 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 3424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3425 | Type | Length | 3426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3427 | | 3428 + + 3429 | | 3430 + Link-local Address + 3431 | | 3432 + + 3433 | | 3434 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3436 Type 3437 3439 Length 3441 8-bit unsigned integer indicating the length of the option 3442 in octets, excluding the type and length fields. This field 3443 MUST be set to 16. 3445 Link-local Address 3447 A sixteen-byte field containing the mobile node's link-local 3448 address. 3450 8.8. Timestamp Option 3452 A new option, Timestamp Option is defined for use in the Proxy 3453 Binding Update and Proxy Binding Acknowledgement messages. 3455 The Timestamp option has an alignment requirement of 8n+2. Its 3456 format is as follows: 3458 0 1 2 3 3459 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 3460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3461 | Type | Length | 3462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3463 | | 3464 + Timestamp + 3465 | | 3466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3468 Type 3469 3471 Length 3473 8-bit unsigned integer indicating the length in octets of 3474 the option, excluding the type and length fields. The value 3475 for this field MUST be set to 8. 3477 Timestamp 3479 A 64-bit unsigned integer field containing a timestamp. The value 3480 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3481 by using a fixed point format. In this format, the integer number 3482 of seconds is contained in the first 48 bits of the field, and the 3483 remaining 16 bits indicate the number of 1/65536 fractions of a 3484 second. 3486 8.9. Status Values 3488 This document defines the following new Status values for use in 3489 Proxy Binding Acknowledgement message. These values are to be 3490 allocated from the same number space, as defined in Section 6.1.8 of 3491 [RFC-3775]. 3493 Status values less than 128 indicate that the Proxy Binding Update 3494 request was accepted by the local mobility anchor. Status values 3495 greater than 128 indicate that the Proxy Binding Update was rejected 3496 by the local mobility anchor. 3498 PROXY_REG_NOT_ENABLED: IANA 3500 Proxy registration not enabled for the mobile node 3502 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3504 Not local mobility anchor for this mobile node 3506 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3508 The mobile access gateway is not authorized to send proxy binding 3509 registrations 3511 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3513 The mobile node is not authorized for one or more of the 3514 requesting home network prefixes. 3516 TIMESTAMP_MISMATCH: IANA 3518 Invalid timestamp value (the clocks are out of sync) 3520 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3522 The timestamp value is lower than the previously accepted value 3524 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3526 Missing home network prefix option 3528 BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA 3530 All the home network prefixes listed in the BCE do not match all 3531 the prefixes in the received PBU 3533 MISSING_MN_IDENTIFIER_OPTION: IANA 3535 Missing mobile node identifier option 3537 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3539 Missing handoff indicator option 3541 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3543 Missing access technology type option 3545 Additionally, the following Status values defined in [RFC-3775] can 3546 also be used in Proxy Binding Acknowledgement message. 3548 0 Proxy Binding Update accepted 3550 128 Reason unspecified 3552 129 Administratively prohibited 3554 130 Insufficient resources 3556 9. Protocol Configuration Variables 3558 9.1. Local Mobility Anchor - Configuration Variables 3560 The local mobility anchor MUST allow the following variables to be 3561 configured by the system management. The configured values for these 3562 protocol variables MUST survive server reboots and service restarts. 3564 MinDelayBeforeBCEDelete 3566 This variable specifies the amount of time in milliseconds the 3567 local mobility anchor MUST wait before it deletes a Binding Cache 3568 entry of a mobile node, upon receiving a Proxy Binding Update 3569 message from a mobile access gateway with a lifetime value of 0. 3570 During this wait time, if the local mobility anchor receives a 3571 Proxy Binding Update for the same mobility binding, with lifetime 3572 value greater than 0, then it must update the binding cache entry 3573 with the accepted binding values. By the end of this wait-time, 3574 if the local mobility anchor did not receive any valid Proxy 3575 Binding Update message for that mobility binding, it MUST delete 3576 the Binding Cache entry. This delay essentially ensures a mobile 3577 node's Binding Cache entry is not deleted too quickly and allows 3578 some time for the new mobile access gateway to complete the 3579 signaling for the mobile node. 3581 The default value for this variable is 10000 milliseconds. 3583 MaxDelayBeforeNewBCEAssign 3585 This variable specifies the amount of time in milliseconds the 3586 local mobility anchor MUST wait for the de-registration message 3587 for an existing mobility session before it decides to create a new 3588 mobility session. 3590 The default value for this variable is 500 milliseconds. 3592 TimestampValidityWindow 3594 This variable specifies the maximum amount of time difference in 3595 milliseconds between the timestamp in the received Proxy Binding 3596 Update message and the current time-of-day on the local mobility 3597 anchor, that is allowed by the local mobility anchor for the 3598 received message to be considered valid. 3600 The default value for this variable is 300 milliseconds. This 3601 variable must be adjusted to suit the deployments. 3603 9.2. Mobile Access Gateway - Configuration Variables 3605 The mobile access gateway MUST allow the following variables to be 3606 configured by the system management. The configured values for these 3607 protocol variables MUST survive server reboots and service restarts. 3609 EnableMAGLocalRouting 3611 This flag indicates whether or not the mobile access gateway is 3612 allowed to enable local routing of the traffic exchanged between a 3613 visiting mobile node and a correspondent node that is locally 3614 connected to one of the interfaces of the mobile access gateway. 3615 The correspondent node can be another visiting mobile node as 3616 well, or a local fixed node. 3618 The default value for this flag is set to value of 0, indicating 3619 that the mobile access gateway MUST reverse tunnel all the traffic 3620 to the mobile node's local mobility anchor. 3622 When the value of this flag is set to value of 1, the mobile 3623 access gateway MUST route the traffic locally. 3625 This aspect of local routing MAY be defined as policy on a per 3626 mobile basis and when present will take precedence over this flag. 3628 9.3. Proxy Mobile IPv6 Domain - Configuration Variables 3630 All the mobile entities (local mobility anchors and mobile access 3631 gateways in a Proxy Mobile IPv6 domain MUST allow the following 3632 variables to be configured by the system management. The configured 3633 values for these protocol variables MUST survive server reboots and 3634 service restarts. These variables MUST be globally fixed for a given 3635 Proxy Mobile IPv6 domain resulting in the same values being enforced 3636 on all the mobility entities in that domain. 3638 MobileNodeGeneratedTimestampInUse 3640 This flag indicates whether or not the mobile node generated 3641 timestamp mechanism is in use in that Proxy Mobile IPv6 domain. 3642 When the value for this flag is set to 1, the local mobility 3643 anchors and mobile access gateways in that Proxy Mobile IPv6 3644 domain MUST apply the mobile node generated timestamp 3645 considerations. 3647 The default value for this flag is set to value of 0, indicating 3648 that the mobile node generated timestamp mechanism is not in use 3649 in that Proxy Mobile IPv6 domain. 3651 10. IANA Considerations 3653 This document defines six new Mobility Header options, the Home 3654 Network Prefix option, Handoff Indicator option, Access Technology 3655 Type option, Mobile Node Link-layer Identifier option, Link-local 3656 Address option and Timestamp option. These options are described in 3657 Section 8. The Type value for these options needs to be assigned 3658 from the same numbering space as allocated for the other mobility 3659 options, as defined in [RFC-3775]. 3661 The Handoff Indicator option defined in Section 8.4 of this document 3662 introduces a new Handoff Indicator (HI) numbering space, where the 3663 values from 0 to 5 have been reserved by this document. Approval of 3664 new Handoff Indicator type values are to be made through IANA Expert 3665 Review. 3667 The Access Technology Type option defined in Section 8.5 of this 3668 document introduces a new Access Technology type (ATT) numbering 3669 space, where the values from 0 to 5 have been reserved by this 3670 document. Approval of new Access Technology type values are to be 3671 made through IANA Expert Review. 3673 This document also defines new Binding Acknowledgement status values 3674 as described in Section 8.9. The status values MUST be assigned from 3675 the same number space used for Binding Acknowledgement status values, 3676 as defined in [RFC-3775]. The allocated values for each of these 3677 status values must be greater than 128. 3679 11. Security Considerations 3681 The potential security threats against any network-based mobility 3682 management protocol are described in [RFC-4832]. This section 3683 explains how Proxy Mobile IPv6 protocol defends itself against those 3684 threats. 3686 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3687 Binding Update and Proxy Binding Acknowledgement, exchanged between 3688 the mobile access gateway and the local mobility anchor to be 3689 protected using IPsec, using the established security association 3690 between them. This essentially eliminates the threats related to the 3691 impersonation of the mobile access gateway or the local mobility 3692 anchor. 3694 This specification allows a mobile access gateway to send binding 3695 registration messages on behalf of a mobile node. If proper 3696 authorization checks are not in place, a malicious node may be able 3697 to hijack a mobile node's session or may carry out a denial-of- 3698 service attack. To prevent this attack, this specification requires 3699 the local mobility anchor to allow only authorized mobile access 3700 gateways that are part of that Proxy Mobile IPv6 domain to send 3701 binding registration messages on behalf of a mobile node. 3703 To eliminate the threats on the interface between the mobile access 3704 gateway and the mobile node, this specification requires an 3705 established trust between the mobile access gateway and the mobile 3706 node and to authenticate and authorize the mobile node before it is 3707 allowed to access the network. Further, the established 3708 authentication mechanisms enabled on that access link will ensure 3709 that there is a secure binding between the mobile node's identity and 3710 its link-layer address. The mobile access gateway will definitively 3711 identify the mobile node from the packets that it receives on that 3712 access link. 3714 To address the threat related to a compromised mobile access gateway, 3715 the local mobility anchor, before accepting a Proxy Binding Update 3716 message for a given mobile node, may ensure that the mobile node is 3717 definitively attached to the mobile access gateway that sent the 3718 proxy binding registration request. This may be accomplished by 3719 contacting a trusted entity which is able to track the mobile node's 3720 current point of attachment. However, the specific details of the 3721 actual mechanisms for achieving this is outside the scope of this 3722 document. 3724 12. Acknowledgements 3726 The authors would like to specially thank Jari Arkko, Julien 3727 Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, 3728 Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their 3729 thorough review of this document. 3731 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3732 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3733 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3734 Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- 3735 Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3736 Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed 3737 Khalil, Nishida Katsutoshi, Phil Roberts, Ralph Droms, Ryuji 3738 Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, 3739 Vidya Narayanan, Youn-Hee Han and many others for their passionate 3740 discussions in the working group mailing list on the topic of 3741 localized mobility management solutions. These discussions 3742 stimulated much of the thinking and shaped the draft to the current 3743 form and we acknowledge that ! 3745 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3746 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim 3747 Stammers, Bernie Volz and Josh Littlefield for their input on this 3748 document. 3750 13. References 3751 13.1. Normative References 3753 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3754 Requirement Levels", BCP 14, RFC 2119, March 1997. 3756 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3757 IPv6 Specification", RFC 2473, December 1998. 3759 [RFC-3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3760 of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 3761 2001. 3763 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3764 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3765 RFC 3315, July 2003. 3767 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3768 IPv6", RFC 3775, June 2004. 3770 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3771 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3772 January 2005. 3774 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3775 Network Access Identifier", RFC 4282, December 2005. 3777 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3778 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3779 November 2005. 3781 [RFC-4291] Hinden, R., Deering, S., "IP Version 6 Addressing 3782 Architecture", RFC 4291, February 2006. 3784 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3785 Internet Protocol", RFC 4301, December 2005. 3787 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3788 4303, December 2005. 3790 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3791 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3792 2007. 3794 13.2. Informative References 3796 [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3797 for IP version 6", RFC 1981, August 1996. 3799 [RFC-2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3800 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 3801 2000. 3803 [RFC-3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3804 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3806 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3807 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3808 2005. 3810 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3811 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3812 4140, August 2005. 3814 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3815 Protocol", RFC 4306, December 2005. 3817 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3818 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3820 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3821 "Chargeable User Identity", RFC 4372, January 2006. 3823 [RFC-4821] Mathis, M. and Heffner, J., "Packetization Layer Path MTU 3824 Discovery", RFC 4821, March 2007. 3826 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3827 G., Liebsch, M., "Problem Statement for Network-based Localized 3828 Mobility Management", September 2006. 3830 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3831 G., Liebsch, M., "Goals for Network-based Localized Mobility 3832 Management", October 2006. 3834 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3835 Localized Mobility Management", September 2006. 3837 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3838 Address Autoconfiguration", RFC 4862, September 2007. 3840 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3841 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3842 2007. 3844 [RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6 3845 Vendor Specific Option", RFC 5094, December 2007. 3847 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3848 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3849 November 2007. 3851 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 3852 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. 3854 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3856 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3857 typically be identified by an identifier, MN-Identifier, and that 3858 identifier will have an associated policy profile that identifies the 3859 mobile node's home network prefix(es) on a per-interface basis, 3860 permitted address configuration modes, roaming policy and other 3861 parameters that are essential for providing network-based mobility 3862 management service. This information is typically configured in AAA. 3863 In some cases, the home network prefix(es) may be dynamically 3864 assigned to the mobile node's interface, after its initial attachment 3865 to the Proxy Mobile IPv6 domain over that interface and may not be 3866 configured in the mobile node's policy profile. 3868 The network entities in the proxy Mobile IPv6 domain, while serving a 3869 mobile node will have access to the mobile node's policy profile and 3870 these entities can query this information using RADIUS [RFC-2865] or 3871 DIAMETER [RFC-3588] protocols. 3873 Appendix B. Routing State 3875 The following section explains the routing state created for a mobile 3876 node on the mobile access gateway. This routing state reflects only 3877 one specific way of implementation and one MAY choose to implement it 3878 in other ways. The policy based route defined below acts as a 3879 traffic selection rule for routing a mobile node's traffic through a 3880 specific tunnel created between the mobile access gateway and that 3881 mobile node's local mobility anchor and with the specific 3882 encapsulation mode, as negotiated. 3884 The below example identifies the routing state for two visiting 3885 mobile nodes, MN1 and MN2 with their respective local mobility 3886 anchors LMA1 and LMA2. 3888 For all traffic from the mobile node, identified by the mobile node's 3889 MAC address, ingress interface or source prefix (MN-HNP) to 3890 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3892 +==================================================================+ 3893 | Packet Source | Destination Address | Destination Interface | 3894 +==================================================================+ 3895 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3896 | (IPv6 Prefix or |----------------------------------------------| 3897 | Input Interface) | Locally Connected | Tunnel0 | 3898 +------------------------------------------------------------------+ 3899 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3900 + (IPv6 Prefix or -----------------------------------------------| 3901 | Input Interface | Locally Connected | direct | 3902 +------------------------------------------------------------------+ 3904 Figure 24: Example - Policy based Route Table 3906 +==================================================================+ 3907 | Interface | Source Address | Destination Address | Encapsulation | 3908 +==================================================================+ 3909 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3910 +------------------------------------------------------------------+ 3911 | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | 3912 +------------------------------------------------------------------+ 3914 Figure 25: Example - Tunnel Interface Table 3916 Authors' Addresses 3918 Sri Gundavelli 3919 Cisco 3920 170 West Tasman Drive 3921 San Jose, CA 95134 3922 USA 3924 Email: sgundave@cisco.com 3926 Kent Leung 3927 Cisco 3928 170 West Tasman Drive 3929 San Jose, CA 95134 3930 USA 3932 Email: kleung@cisco.com 3933 Vijay Devarapalli 3934 Wichorus 3935 3590 North First Street 3936 San Jose, CA 95134 3937 USA 3939 Email: vijay@wichorus.com 3941 Kuntal Chowdhury 3942 Starent Networks 3943 30 International Place 3944 Tewksbury, MA 3946 Email: kchowdhury@starentnetworks.com 3948 Basavaraj Patil 3949 Nokia Siemens Networks 3950 6000 Connection Drive 3951 Irving, TX 75039 3952 USA 3954 Email: basavaraj.patil@nsn.com 3956 Full Copyright Statement 3958 Copyright (C) The IETF Trust (2008). 3960 This document is subject to the rights, licenses and restrictions 3961 contained in BCP 78, and except as set forth therein, the authors 3962 retain all their rights. 3964 This document and the information contained herein are provided on an 3965 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3966 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3967 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3968 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3969 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3970 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3972 Intellectual Property 3974 The IETF takes no position regarding the validity or scope of any 3975 Intellectual Property Rights or other rights that might be claimed to 3976 pertain to the implementation or use of the technology described in 3977 this document or the extent to which any license under such rights 3978 might or might not be available; nor does it represent that it has 3979 made any independent effort to identify any such rights. Information 3980 on the procedures with respect to rights in RFC documents can be 3981 found in BCP 78 and BCP 79. 3983 Copies of IPR disclosures made to the IETF Secretariat and any 3984 assurances of licenses to be made available, or the result of an 3985 attempt made to obtain a general license or permission for the use of 3986 such proprietary rights by implementers or users of this 3987 specification can be obtained from the IETF on-line IPR repository at 3988 http://www.ietf.org/ipr. 3990 The IETF invites any interested party to bring to its attention any 3991 copyrights, patents or patent applications, or other proprietary 3992 rights that may cover technology that may be required to implement 3993 this standard. Please address the information to the IETF at 3994 ietf-ipr@ietf.org. 3996 Acknowledgment 3998 Funding for the RFC Editor function is provided by the IETF 3999 Administrative Support Activity (IASA).