idnits 2.17.1 draft-ietf-netlmm-proxymip6-18.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 4062. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4073. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4080. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4086. 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 30, 2008) is 5810 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-03 == 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: December 1, 2008 V. Devarapalli 6 Wichorus 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 May 30, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-18.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 December 1, 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 . . . . . . . . . . . . . . . 18 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 Proxy Binding Updates . . . . . . . . . . . 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 . . . . . . . . . . . . . . . 25 75 5.3.6. Constructing the Proxy Binding Acknowledgement 76 Message . . . . . . . . . . . . . . . . . . . . . . . 25 77 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 28 78 5.4.1. Binding Cache entry lookup considerations . . . . . . 28 79 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 34 80 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 37 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 37 82 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 38 83 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels . . . 39 84 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 40 85 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 40 86 5.9. Route Optimization Considerations . . . . . . . . . . . . 41 87 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 41 88 6.1. Extensions to Binding Update List Entry Data Structure . . 42 89 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 43 90 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 44 91 6.4. Supported Address Configuration Modes . . . . . . . . . . 44 92 6.5. Access Authentication & Mobile Node Identification . . . . 45 93 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 45 94 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 46 95 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 46 96 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 48 97 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 48 98 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 56 99 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 57 100 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 58 101 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 59 102 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 60 103 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 60 104 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 60 105 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 61 106 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 62 107 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 62 108 6.11. Supporting DHCP based Address Configuration on the 109 Access Link . . . . . . . . . . . . . . . . . . . . . . . 64 110 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 66 111 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 66 112 6.14. Allowing network access to other IPv6 nodes . . . . . . . 67 113 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 67 114 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 67 115 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 68 116 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 69 117 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 69 118 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 71 119 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 72 120 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 73 121 8.5. Access Technology Type Option . . . . . . . . . . . . . . 74 122 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 76 123 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 77 124 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 78 125 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 78 126 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 80 127 9.1. Local Mobility Anchor - Configuration Variables . . . . . 80 128 9.2. Mobile Access Gateway - Configuration Variables . . . . . 81 129 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 82 130 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 83 131 11. Security Considerations . . . . . . . . . . . . . . . . . . . 84 132 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 84 133 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 85 134 13.1. Normative References . . . . . . . . . . . . . . . . . . . 85 135 13.2. Informative References . . . . . . . . . . . . . . . . . . 86 136 Appendix A. Proxy Mobile IPv6 interactions with AAA 137 Infrastructure . . . . . . . . . . . . . . . . . . . 87 138 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 88 139 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 89 140 Intellectual Property and Copyright Statements . . . . . . . . . . 91 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 on an access router that 226 manages the mobility related signaling for a mobile node that is 227 attached to its access link. It is responsible for tracking the 228 mobile node's movements to and from the access link and for 229 signaling the mobile node's 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 egress interface 255 of the mobile access gateway and is the transport endpoint of the 256 tunnel between the local mobility anchor and the mobile access 257 gateway. The local mobility anchor views this address as the 258 Care-of Address of the mobile node and registers it in the Binding 259 Cache entry for that mobile node. When the transport network 260 between the mobile access gateway and the local mobility anchor is 261 an IPv4 network and if the care-of address that is registered at 262 the local mobility anchor is an IPv4 address, the term, IPv4- 263 Proxy-CoA is 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. Ex: Home network prefixes P1, P2 assigned to interface 279 I1 will be managed under one mobility session and prefixes P3, P4, 280 P5 assigned to interface I2 of the mobile node will be managed 281 under a different mobility session. Additionally, in some 282 configurations the assigned prefix can be of 128-bit prefix 283 length. 285 Mobile Node's Home Address (MN-HoA) 287 MN-HoA is an address from a mobile node's home network prefix. 288 The mobile node will be able to use this address as long as it is 289 attached to the access network that is in the scope of that Proxy 290 Mobile IPv6 domain. If the mobile node uses more than one address 291 from its home network prefix(es), any one of these addresses is 292 referred to as mobile node's home address. Unlike in Mobile IPv6 293 where the home agent is aware of the home address of the mobile 294 node, in Proxy Mobile IPv6, the mobility entities are only aware 295 of the mobile node's home network prefix(es) and are not always 296 aware of the exact address(es) that the mobile node configured on 297 its interface from its home network prefix(es). However, in some 298 configurations and based on the enabled address configuration 299 modes on the access link, the mobility entities in the network can 300 be certain about the exact address(es) configured by the mobile 301 node. 303 Mobile Node's Home Link 305 This is the link on which the mobile node obtained its Layer-3 306 address configuration for the attached interface after it moved 307 into that Proxy Mobile IPv6 domain. This is the link that 308 conceptually follows the mobile node. The network will ensure the 309 mobile node always sees this link with respect to the layer-3 310 network configuration, on any access link that it attaches to in 311 that Proxy Mobile IPv6 domain. 313 Multihomed Mobile Node 315 A mobile node that connects to the same Proxy Mobile IPv6 domain 316 through more than one interface and uses these interfaces 317 simultaneously is referred to as a multihomed mobile node. 319 Mobile Node Identifier (MN-Identifier) 321 The identity of a mobile node in the Proxy Mobile IPv6 domain. 322 This is the stable identifier of a mobile node that the mobility 323 entities in a Proxy Mobile IPv6 domain can always acquire and use 324 it for predictably identifying a mobile node. This is typically 325 an identifier such as Network Access Identifier (NAI) [RFC-4282] 326 or other identifier such as a Media Access Control (MAC) address. 328 Mobile Node Link-layer Identifier (MN-LL-Identifier) 330 An identifier that identifies the attached interface of a mobile 331 node. For those interfaces that have a link-layer identifier, 332 this identifier can be based on that. The link-layer identifier 333 in some cases is generated by the mobile node and conveyed to the 334 mobile access gateway. This identifier of the attached interface 335 must be stable as seen by any of the mobile access gateways in a 336 given Proxy Mobile IPv6 domain. In some other cases, there might 337 not be any link-layer identifier associated with the mobile node's 338 interface. An identifier value of ALL_ZERO is not considered a 339 valid identifier and cannot be used as an interface identifier. 341 Policy Profile 343 Policy Profile is an abstract term for referring to a set of 344 configuration parameters that are configured for a given mobile 345 node. The mobility entities in the Proxy Mobile IPv6 domain 346 require access to these parameters for providing the mobility 347 management to a given mobile node. The specific details on how 348 the network entities obtain this policy profile is outside the 349 scope of this document. 351 Proxy Binding Update (PBU) 353 A request message sent by a mobile access gateway to a mobile 354 node's local mobility anchor for establishing a binding between 355 the mobile node's home network prefix(es) assigned to a given 356 interface of a mobile node and its current care-of address (Proxy- 357 CoA). 359 Proxy Binding Acknowledgement (PBA) 361 A reply message sent by a local mobility anchor in response to a 362 Proxy Binding Update message that it received from a mobile access 363 gateway. 365 Per-MN-Prefix & Shared-Prefix Models 367 The term, Per-MN-Prefix model, is used to refer to an addressing 368 model where there is a unique network prefix or prefixes assigned 369 for each node. The term, Shared-Prefix model, is used to refer to 370 an addressing model where the prefix(es) are shared by more than 371 one node. This specification supports the Per-MN-Prefix model and 372 does not support the Shared-Prefix model. 374 Mobility Session 375 In the context of Proxy Mobile IPv6 specification, the term 376 mobility session refers to the creation or existence of state 377 associated with the mobile node's mobility binding on the local 378 mobility anchor and on the serving mobile access gateway. 380 DHCP 382 Throughout this document, the acronym DHCP refers to DHCP for 383 IPv6, as defined in [RFC-3315]. 385 ALL_ZERO & NON_ZERO 387 Protocol message fields initialized with value 0 in each byte of 388 the field. Ex: An 8-byte link-layer identifier field with the 389 value set to 0 in each of the 8 bytes, or an IPv6 address with the 390 value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is 391 used to refer to any value other than an ALL_ZERO value. 393 3. Proxy Mobile IPv6 Protocol Overview 395 This specification describes a network-based mobility management 396 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 397 [RFC-3775]. 399 Proxy Mobile IPv6 protocol is intended for providing network-based IP 400 mobility management support to a mobile node, without requiring the 401 participation of the mobile node in any IP mobility related 402 signaling. The mobility entities in the network will track the 403 mobile node's movements and will initiate the mobility signaling and 404 set up the required routing state. 406 The core functional entities in the NETLMM infrastructure are the 407 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 408 local mobility anchor is responsible for maintaining the mobile 409 node's reachability state and is the topological anchor point for the 410 mobile node's home network prefix(es). The mobile access gateway is 411 the entity that performs the mobility management on behalf of a 412 mobile node and it resides on the access link where the mobile node 413 is anchored. The mobile access gateway is responsible for detecting 414 the mobile node's movements to and from the access link and for 415 initiating binding registrations to the mobile node's local mobility 416 anchor. There can be multiple local mobility anchors in a Proxy 417 Mobile IPv6 domain each serving a different group of mobile nodes. 418 The architecture of a Proxy Mobile IPv6 domain is shown in Figure 1. 420 +----+ +----+ 421 |LMA1| |LMA2| 422 +----+ +----+ 423 LMAA1 -> | | <-- LMAA2 424 | | 425 \\ //\\ 426 \\ // \\ 427 \\ // \\ 428 +---\\------------- //------\\----+ 429 ( \\ IPv4/IPv6 // \\ ) 430 ( \\ Network // \\ ) 431 +------\\--------//------------\\-+ 432 \\ // \\ 433 \\ // \\ 434 \\ // \\ 435 Proxy-CoA1--> | | <-- Proxy-CoA2 436 +----+ +----+ 437 |MAG1|-----{MN2} |MAG2| 438 +----+ | +----+ 439 | | | 440 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 441 {MN1} {MN3} 443 Figure 1: Proxy Mobile IPv6 Domain 445 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 446 an access link, the mobile access gateway on that access link, after 447 identifying the mobile node and acquiring its identity, will 448 determine if the mobile node is authorized for the network-based 449 mobility management service. 451 If the network determines that the network-based mobility management 452 service needs to be offered to that mobile node, the network will 453 ensure that the mobile node using any of the address configuration 454 mechanisms permitted by the network will be able to obtain the 455 address configuration on the connected interface and move anywhere in 456 that Proxy Mobile IPv6 domain. The obtained address configuration 457 includes the address(es) from its home network prefix(es), the 458 default-router address on the link and other related configuration 459 parameters. From the perspective of each mobile node, the entire 460 Proxy Mobile IPv6 domain appears as a single link, the network 461 ensures that the mobile node does not detect any change with respect 462 to its layer-3 attachment even after changing its point of attachment 463 in the network. 465 The mobile node may be an IPv4-only node, IPv6-only node or a dual 466 IPv4/IPv6 node. Based on what is enabled in the network for that 467 mobile node, the mobile node will be able to obtain an IPv4, IPv6 or 468 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 469 domain. However this specification only supports IPv6 address 470 mobility and when the transport network is IPv6 network. The support 471 for IPv4 addressing or IPv4 transport network is specified in the 472 companion document [ID-IPV4-PMIP6]. 474 If the mobile node connects to the Proxy Mobile IPv6 domain through 475 multiple interfaces and over multiple access networks, the network 476 will allocate a unique set of home network prefixes for each of the 477 connected interfaces. The mobile node will be able to configure 478 address(es) on those interfaces from the respective home network 479 prefix(es). However, if the mobile node performs an handoff by 480 moving its address configuration from one interface to the other and 481 if the local mobility anchor receives a handoff hint from the serving 482 mobile access gateway about the same, the local mobility anchor will 483 assign the same home network prefix(es) that it previously assigned 484 prior to the handoff. The mobile node will also be able to perform 485 an handoff by changing its point of attachment from one mobile access 486 gateway to a different mobile access gateway using the same interface 487 and will be able to retain the address configuration on the attached 488 interface. 490 +-----+ +-----+ +-----+ 491 | MN | | MAG | | LMA | 492 +-----+ +-----+ +-----+ 493 | | | 494 MN Attached | | 495 | | | 496 | MN Attached Event from MN/Network | 497 | (Acquire MN-Id and Profile) | 498 | | | 499 |--- Rtr Sol --------->| | 500 | | | 501 | |--- PBU ------------->| 502 | | | 503 | | Accept PBU 504 | | (Allocate MN-HNP(s), Setup BCE and Tunnel) 505 | | | 506 | |<------------- PBA ---| 507 | | | 508 | Accept PBA | 509 | (Setup Tunnel and Routing) | 510 | | | 511 | |==== Bi-Dir Tunnel ===| 512 | | | 513 |<--------- Rtr Adv ---| | 514 | | | 515 IP Address | | 516 Configuration | | 517 | | | 519 Figure 2: Mobile Node Attachment - Signaling Call Flow 521 Figure 2 shows the signaling call flow when the mobile node enters 522 the Proxy Mobile IPv6 domain. The Router Solicitation message from 523 the mobile node may arrive at any time after the mobile node's 524 attachment and has no strict ordering relation with the other 525 messages in the call flow. 527 For updating the local mobility anchor about the current location of 528 the mobile node, the mobile access gateway sends a Proxy Binding 529 Update message to the mobile node's local mobility anchor. Upon 530 accepting this Proxy Binding Update message, the local mobility 531 anchor sends a Proxy Binding Acknowledgement message including the 532 mobile node's home network prefix(es). It also creates the Binding 533 Cache entry and sets up its endpoint of the bi-directional tunnel to 534 the mobile access gateway. 536 The mobile access gateway on receiving the Proxy Binding 537 Acknowledgement message sets up its endpoint of the bi-directional 538 tunnel to the local mobility anchor and also sets up the forwarding 539 for the mobile node's traffic. At this point the mobile access 540 gateway will have all the required information for emulating the 541 mobile node's home link. It sends Router Advertisement messages to 542 the mobile node on the access link advertising the mobile node's home 543 network prefix(es) as the hosted on-link-prefix(es). 545 The mobile node on receiving these Router Advertisement messages on 546 the access link will attempt to configure its interface either using 547 stateful or stateless address configuration modes, based on the modes 548 that are permitted on that access link as indicated in Router 549 Advertisement messages. At the end of a successful address 550 configuration procedure, the mobile node will end up with one or more 551 addresses from its home network prefix(es). 553 Once the address configuration is complete, the mobile node has one 554 or more valid addresses from its home network prefix(es) at the 555 current point of attachment. The serving mobile access gateway and 556 the local mobility anchor also have proper routing states for 557 handling the traffic sent to and from the mobile node using any one 558 or more of the addresses from its home network prefix(es). 560 The local mobility anchor, being the topological anchor point for the 561 mobile node's home network prefix(es), receives any packets that are 562 sent to the mobile node by any node in or outside the Proxy Mobile 563 IPv6 domain. The local mobility anchor forwards these received 564 packets to the mobile access gateway through the bi-directional 565 tunnel. The mobile access gateway on other end of the tunnel, after 566 receiving the packet, removes the outer header and forwards the 567 packet on the access link to the mobile node. However, in some cases 568 the traffic sent from a correspondent node that is locally connected 569 to the mobile access gateway may not be received by the local 570 mobility anchor and may be routed locally by the mobile access 571 gateway (Refer to Section 6.10.3). 573 The mobile access gateway acts as the default router on the point-to- 574 point link shared with the mobile node. Any packet that the mobile 575 node sends to any correspondent node will be received by the mobile 576 access gateway and will be sent to its local mobility anchor through 577 the bi-directional tunnel. The local mobility anchor on the other 578 end of the tunnel, after receiving the packet, removes the outer 579 header and routes the packet to the destination. However in some 580 cases the traffic sent to a correspondent node that is locally 581 connected to the mobile access gateway may be locally routed by the 582 mobile access gateway (Refer to Section 6.10.3). 584 +-----+ +-----+ +-----+ +-----+ 585 | MN | |p-MAG| | LMA | |n-MAG| 586 +-----+ +-----+ +-----+ +-----+ 587 | | | | 588 | |==Bi-Dir Tunnel=| | 589 MN Detached | | | 590 | MN Detached Event | | 591 | | | | 592 | |-- DeReg PBU -->| | 593 | | | | 594 | | Accept PBU | 595 | | (Start MinDelayBeforeBCEDelete Timer) 596 | | | | 597 | |<-------- PBA --| | 598 | | | | 599 MN Attached | | | 600 | | | MN Attached event received 601 | | | from MN or from network 602 | | | (Acquire MN-Id and Profile) 603 | | | | 604 |--- Rtr Sol ------------------------------------->| 605 .... 606 Registration steps as in fig 2. 607 .... 608 | | |==Bi-Dir Tunnel=| 609 | | | | 610 |<------------------------------------ Rtr Adv ----| 611 | | | | 612 MN retains HoA/HNP(s) 613 | | | | 615 Figure 3: Mobile Node Handoff - Signaling Call Flow 617 Figure 3 shows the signaling call flow for the mobile node's handoff 618 from previously attached mobile access gateway (p-MAG) to the newly 619 attached mobile access gateway (n-MAG). This call flow reflects only 620 a specific message ordering, it is possible the registration message 621 from the n-MAG may arrive before the de-registration message from the 622 p-MAG arrives. 624 After obtaining the initial address configuration in the Proxy Mobile 625 IPv6 domain, if the mobile node changes its point of attachment, the 626 mobile access gateway on the previous link will detect the mobile 627 node's detachment from the link and will signal the local mobility 628 anchor and will remove the binding and routing state for that mobile 629 node. The local mobility anchor upon receiving this request will 630 identify the corresponding mobility session for which the request was 631 received and once it accepts the request will wait for certain amount 632 of time for allowing the mobile access gateway on the new link to 633 update the binding. However, if it does not receive any Proxy 634 Binding Update message within that given amount of time, it will 635 delete the binding cache entry. 637 The mobile access gateway on the new access link upon detecting the 638 mobile node on its access link will signal the local mobility anchor 639 for updating the binding state. Once that signaling is complete, the 640 serving mobile access gateway will send the Router Advertisements 641 containing the mobile node's home network prefix(es) and this will 642 ensure the mobile node will not detect any change with respect to its 643 layer-3 attachment of its interface. 645 4. Proxy Mobile IPv6 Protocol Security 647 The signaling messages, Proxy Binding Update and Proxy Binding 648 Acknowledgement, exchanged between the mobile access gateway and the 649 local mobility anchor MUST be protected using end-to-end security 650 association(s) offering integrity and data origin authentication. 652 The mobile access gateway and the local mobility anchor MUST 653 implement IPsec for protecting the Proxy Mobile IPv6 signaling 654 messages [RFC-4301]. That is, IPsec is a mandatory to implement 655 security mechanism. However, additional documents may specify 656 alternative mechanisms and the mobility entities can enable a 657 specific mechanism for securing Proxy Mobile IPv6 signaling messages, 658 either based on a static configuration or after a dynamic negotiation 659 using any standard security negotiation protocols. As in Mobile IPv6 660 [RFC-3775], the use of IPsec for protecting mobile node's data 661 traffic is optional. 663 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 664 protection SHOULD be used for protecting the signaling messages. 665 Confidentiality protection of these messages is not required. 667 IPsec ESP [RFC-4303] in tunnel mode MAY be used to protect the mobile 668 node's tunneled data traffic, if protection of data traffic is 669 required. 671 IKEv2 [RFC-4306] SHOULD be used to set up security associations 672 between the mobile access gateway and the local mobility anchor to 673 protect the Proxy Binding Update and Proxy Binding Acknowledgement 674 messages. The mobile access gateway and the local mobility anchor 675 can use any of the authentication mechanisms, as specified in [RFC- 676 4306], for mutual authentication. 678 The Mobile IPv6 specification [RFC-3775] requires the home agent to 679 prevent a mobile node from creating security associations or creating 680 binding cache entries for another mobile node's home address. In the 681 protocol described in this document, the mobile node is not involved 682 in creating security associations for protecting the signaling 683 messages or sending binding updates. Therefore, the local mobility 684 anchor MUST restrict the creation and manipulation of proxy bindings 685 to specifically authorized mobile access gateways and prefixes. The 686 local mobility anchor MUST be locally configurable to authorize such 687 specific combinations. Additional mechanisms such as a policy store 688 or AAA may be employed, but these are outside the scope of this 689 specification. 691 Unlike in Mobile IPv6 [RFC-3775], these signaling messages do not 692 carry either the Home Address destination option or the Type 2 693 Routing header and hence the policy entries and security association 694 selectors stay the same and require no special IPsec related 695 considerations. 697 4.1. Peer Authorization Database (PAD) Example Entries 699 This section describes PAD entries [RFC-4301] on the mobile access 700 gateway and the local mobility anchor. The PAD entries are only 701 example configurations. Note that the PAD is a logical concept and a 702 particular mobile access gateway or a local mobility anchor 703 implementation can implement the PAD in any implementation specific 704 manner. The PAD state may also be distributed across various 705 databases in a specific implementation. 707 In the example shown below, the identity of the local mobility anchor 708 is assumed to be lma_identity_1 and the identity of the mobile access 709 gateway is assumed to be mag_identity_1. 711 mobile access gateway PAD: 712 - IF remote_identity = lma_identity_1 713 Then authenticate (shared secret/certificate/EAP) 714 and authorize CHILD_SAs for remote address lma_address_1 716 local mobility anchor PAD: 717 - IF remote_identity = mag_identity_1 718 Then authenticate (shared secret/certificate/EAP) 719 and authorize CHILD_SAs for remote address mag_address_1 721 Figure 4: PAD Entries 723 The list of authentication mechanisms in the above examples is not 724 exhaustive. There could be other credentials used for authentication 725 stored in the PAD. 727 4.2. Security Policy Database (SPD) Example Entries 729 This section describes the security policy entries [RFC-4301] on the 730 mobile access gateway and the local mobility anchor required to 731 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 732 are only example configurations. A particular mobile access gateway 733 or a local mobility anchor implementation could configure different 734 SPD entries as long as they provide the required security. 736 In the example shown below, the identity of the mobile access gateway 737 is assumed to be mag_identity_1, the address of the mobile access 738 gateway is assumed to be mag_address_1, and the address of the local 739 mobility anchor is assumed to be lma_address_1. The acronym MH 740 represents the protocol number for the Mobility Header [RFC-3775]; 741 while the terms local_mh_type and remote_mh_type stand for local 742 mobility header type and remote mobility header type respectively. 744 mobile access gateway SPD-S: 745 - IF local_address = mag_address_1 & 746 remote_address = lma_address_1 & 747 proto = MH & (local_mh_type = BU | remote_mh_type = BA) 748 Then use SA ESP transport mode 749 Initiate using IDi = mag_identity_1 to address lma_address_1 751 local mobility anchor SPD-S: 752 - IF local_address = lma_address_1 & 753 remote_address = mag_address_1 & 754 proto = MH & (local_mh_type = BA | remote_mh_type = BU) 755 Then use SA ESP transport mode 756 Figure 5: SPD Entries 758 5. Local Mobility Anchor Operation 760 The local mobility anchor MUST support the home agent function as 761 defined in [RFC-3775] and additionally the extensions defined in this 762 specification. A home agent with these modifications and enhanced 763 capabilities for supporting the Proxy Mobile IPv6 protocol is 764 referred to as a local mobility anchor. 766 This section describes the operational details of the local mobility 767 anchor. 769 5.1. Extensions to Binding Cache Entry Data Structure 771 Every local mobility anchor MUST maintain a Binding Cache entry for 772 each currently registered mobile node. A Binding Cache entry is a 773 conceptual data structure, described in Section 9.1 of [RFC-3775]. 775 For supporting this specification, the Binding Cache Entry data 776 structure needs to be extended with the following additional fields. 778 o A flag indicating whether or not this Binding Cache entry is 779 created due to a proxy registration. This flag is set to value 1 780 for Binding Cache entries that are proxy registrations and is set 781 to value 0 for all other entries. 783 o The identifier of the registered mobile node, MN-Identifier. This 784 identifier is obtained from the Mobile Node Identifier Option 785 [RFC-4283] present in the received Proxy Binding Update message. 787 o The link-layer identifier of the mobile node's connected interface 788 on the access link. This identifier can be acquired from the 789 Mobile Node Link-layer Identifier option, present in the received 790 Proxy Binding Update message. If the option was not present in 791 the request, this variable length field MUST be set to two 792 (octets) and MUST be initialized to a value of ALL_ZERO. 794 o The link-local address of the mobile access gateway on the point- 795 to-point link shared with the mobile node. This is generated by 796 the local mobility anchor after accepting the initial Proxy 797 Binding Update message. 799 o List of IPv6 home network prefixes assigned to the mobile node's 800 connected interface. The home network prefix(es) may have been 801 statically configured in the mobile node's policy profile, or, 802 they may have been dynamically allocated by the local mobility 803 anchor. Each one of these prefix entries will also includes the 804 corresponding prefix length. 806 o The tunnel interface identifier (tunnel-if-id) of the bi- 807 directional tunnel between the local mobility anchor and the 808 mobile access gateway where the mobile node is currently anchored. 809 This is internal to the local mobility anchor. The tunnel 810 interface identifier is acquired during the tunnel creation. 812 o The access technology type, by which the mobile node is currently 813 attached. This is obtained from the Access Technology Type 814 option, present in the Proxy Binding Update message. 816 o The 64-bit timestamp value of the most recently accepted Proxy 817 Binding Update message sent for this mobile node. This is the 818 time-of-day on the local mobility anchor, when the message was 819 received. If the Timestamp option is not present in the Proxy 820 Binding Update message (i.e., when the sequence number based 821 scheme is in use), the value MUST be set to ALL_ZERO. 823 Typically, any one of the mobile node's home network prefixes from 824 its mobility session may be used as a key for locating its Binding 825 Cache entry in all cases except when there has been an handoff of the 826 mobile node's session to a new mobile access gateway and that mobile 827 access gateway is unaware of the home network prefix(es) assigned to 828 that mobility session. In such handoff cases, the Binding Cache 829 entry can be located under the considerations specified in Section 830 5.4.1. 832 5.2. Supported Home Network Prefix Models 834 This specification supports the Per-MN-Prefix model and does not 835 support the Shared-Prefix model. According to the Per-MN-Prefix 836 model, home network prefix(es) assigned to a mobile node are for that 837 mobile node's exclusive use and no other node shares an address from 838 that prefix (other than the Subnet-Router anycast address [RFC-4291] 839 which is used by the mobile access gateway hosting that prefix on 840 that link). 842 There may be more than one prefix assigned to a given interface of 843 the mobile node; all of those assigned prefixes MUST be unique to 844 that mobile node and all are part of exactly one mobility session. 845 If the mobile node simultaneously attaches to the Proxy Mobile IPv6 846 domain through multiple interfaces, each of the attached interfaces 847 MUST be assigned one or more unique prefixes. Prefixes that are not 848 assigned to the same interface MUST NOT be managed under the same 849 mobility session. 851 The mobile node's home network prefix(es) assigned to a given 852 interface of a mobile node (part of a mobility session) will be 853 hosted on the access link where the mobile node is attached (using 854 that interface). The local mobility anchor is not required to 855 perform any proxy ND operations [RFC-4861] for defending the mobile 856 node's home address(es), as the prefixes are not locally hosted on 857 the local mobility anchor. However, from the routing perspective, 858 the home network prefix(es) is topologically anchored on the local 859 mobility anchor. 861 5.3. Signaling Considerations 863 This section provides the rules for processing the signaling 864 messages. The processing rules specified in this section and other 865 related sections are chained and are in a specific order. When 866 applying these considerations for processing the signaling messages, 867 the specified order MUST be maintained. 869 5.3.1. Processing Proxy Binding Updates 871 1. The received Proxy Binding Update message (a Binding Update 872 message with the 'P' flag set to value of 1, format specified in 873 Section 8.1) MUST be authenticated as described in Section 4. 874 When IPsec is used for message authentication, the SPI in the 875 IPsec header [RFC-4306] of the received packet is needed for 876 locating the security association, for authenticating the Proxy 877 Binding Update message. 879 2. The local mobility anchor MUST observe the rules described in 880 Section 9.2 of [RFC-3775] when processing the Mobility Header in 881 the received Proxy Binding Update message. 883 3. The local mobility anchor MUST ignore the check, specified in 884 Section 10.3.1 of [RFC-3775], related to the presence of Home 885 Address destination option in the Proxy Binding Update message. 887 4. The local mobility anchor MUST identify the mobile node from the 888 identifier present in the Mobile Node Identifier option [RFC- 889 4283] of the Proxy Binding Update message. If the Mobile Node 890 Identifier option is not present in the Proxy Binding Update 891 message, the local mobility anchor MUST reject the request and 892 send a Proxy Binding Acknowledgement message with Status field 893 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 894 identifier option) and the identifier in the Mobile Node 895 Identifier Option carried in the message MUST be set to a zero 896 length identifier. 898 5. The local mobility anchor MUST apply the required policy checks, 899 as explained in Section 4, to verify the sender is a trusted 900 mobile access gateway, authorized to send Proxy Binding Update 901 messages on behalf of this mobile node. 903 6. If the local mobility anchor determines that the requesting node 904 is not authorized to send Proxy Binding Update messages for the 905 identified mobile node, it MUST reject the request and send a 906 Proxy Binding Acknowledgement message with Status field set to 907 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 908 binding updates). 910 7. If the local mobility anchor cannot identify the mobile node 911 based on the identifier present in the Mobile Node Identifier 912 option [RFC-4283] of Proxy Binding Update message, it MUST 913 reject the request and send a Proxy Binding Acknowledgement 914 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 915 (Not local mobility anchor for this mobile node). 917 8. If the local mobility anchor determines that the mobile node is 918 not authorized for the network-based mobility management 919 service, it MUST reject the request and send a Proxy Binding 920 Acknowledgement message with Status field set to 921 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 923 9. The local mobility anchor MUST apply the considerations 924 specified in Section 5.5, for processing the Sequence Number 925 field and the Timestamp option (if present), in the Proxy 926 Binding Update message. 928 10. If there is no Home Network Prefix option(s) (with any value) 929 present in the Proxy Binding Update message, the local mobility 930 anchor MUST reject the request and send a Proxy Binding 931 Acknowledgement message with Status field set to 932 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network prefix 933 option). 935 11. If the Handoff Indicator option is not present in the Proxy 936 Binding Update message, the local mobility anchor MUST reject 937 the request and send a Proxy Binding Acknowledgement message 938 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 939 (Missing handoff indicator option). 941 12. If the Access Technology Type option is not present in the Proxy 942 Binding Update message, the local mobility anchor MUST reject 943 the request and send a Proxy Binding Acknowledgement message 944 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 945 (Missing access technology type option). 947 13. Considerations specified in Section 5.4.1 MUST be applied for 948 performing the Binding Cache entry existence test. If those 949 checks specified in Section 5.4.1, result in associating the 950 received Proxy Binding Update message to a new mobility session 951 creation request, considerations from Section 5.3.2 (Initial 952 Binding Registration - New Mobility Session), MUST be applied. 953 If those checks result in associating the request to an existing 954 mobility session, the following checks determine the next set of 955 processing rules that needs to be applied. 957 * If the Handoff Indicator field in the Handoff Indicator 958 option present in the request is set to a value of 5 (Handoff 959 state not changed), considerations from Section 5.3.3 960 (Binding Lifetime Extension- No handoff) MUST be applied. 962 * If the received Proxy Binding Update message has the lifetime 963 value of zero, considerations from Section 5.3.5 (Binding De- 964 Registration) MUST be applied. 966 * For all other cases, considerations from Section 5.3.4 967 (Binding Lifetime Extension - After handoff) MUST be applied. 969 14. When sending the Proxy Binding Acknowledgement message with any 970 Status field value, the message MUST be constructed as specified 971 in Section 5.3.6. 973 5.3.2. Initial Binding Registration (New Mobility Session) 975 1. If there is at least one instance of Home Network Prefix option 976 present in the Proxy Binding Update message with the prefix value 977 set to ALL_ZERO, the local mobility anchor MUST allocate one or 978 more home network prefix(es) to the mobile node and assign it to 979 the new mobility session created for the mobile node. The local 980 mobility anchor MUST ensure the allocated prefix(es) is not in 981 use by any other node or mobility session. The decision on how 982 many prefixes to be allocated for the attached interface, can be 983 based on a global policy or a policy specific to that mobile 984 node. However, when stateful address autoconfiguration using 985 DHCP is supported on the link, considerations from Section 6.11 986 MUST be applied for the prefix assignment. 988 2. If the local mobility anchor is unable to allocate any home 989 network prefix for the mobile node, it MUST reject the request 990 and send a Proxy Binding Acknowledgement message with Status 991 field set to 130 (Insufficient resources). 993 3. If there are one or more Home Network Prefix options present in 994 the Proxy Binding Update message (with each of the prefixes set 995 to a NON_ZERO value), the local mobility anchor before accepting 996 that request, MUST ensure each one of those prefixes is owned by 997 the local mobility anchor and further the mobile node is 998 authorized to use these prefixes. If the mobile node is not 999 authorized to use any one or more of those prefixes, the local 1000 mobility anchor MUST reject the request and send a Proxy Binding 1001 Acknowledgement message with Status field set to 1002 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not 1003 authorized for one or more of the requesting home network 1004 prefixes). 1006 4. Upon accepting the request, the local mobility anchor MUST create 1007 a Binding Cache entry for the mobile node. It must set the 1008 fields in the Binding Cache entry to the accepted values for that 1009 registration. 1011 5. If there is no existing bi-directional tunnel to the mobile 1012 access gateway that sent the request, the local mobility anchor 1013 MUST establish a bi-directional tunnel to that mobile access 1014 gateway. Considerations from Section 5.6.1 MUST be applied for 1015 managing the dynamically created bi-directional tunnel. 1017 6. The local mobility anchor MUST create a prefix route(s) over the 1018 tunnel to the mobile access gateway for forwarding any traffic 1019 received for the mobile node's home network prefix(es) associated 1020 with this mobility session. The created tunnel and the routing 1021 state MUST result in the forwarding behavior on the local 1022 mobility anchor as specified in Section 5.6.2. 1024 7. The local mobility anchor MUST send the Proxy Binding 1025 Acknowledgement message with the Status field set to 0 (Proxy 1026 Binding Update Accepted). The message MUST be constructed as 1027 specified in Section 5.3.6. 1029 5.3.3. Binding Lifetime Extension (No handoff) 1031 1. Upon accepting the Proxy Binding Update message for extending the 1032 binding lifetime, received from the same mobile access gateway 1033 (if the Proxy-CoA address in the Binding Cache entry is the same 1034 as the Proxy-CoA address in the request) that last updated the 1035 binding, the local mobility anchor MUST update the Binding Cache 1036 entry with the accepted registration values. 1038 2. The local mobility anchor MUST send the Proxy Binding 1039 Acknowledgement message with the Status field set to 0 (Proxy 1040 Binding Update Accepted). The message MUST be constructed as 1041 specified in Section 5.3.6. 1043 5.3.4. Binding Lifetime Extension (After handoff) 1045 1. Upon accepting the Proxy Binding Update message for extending the 1046 binding lifetime, received from a new mobile access gateway (if 1047 the Proxy-CoA address in the Binding Cache entry does not match 1048 the Proxy-CoA address in the request) where the mobile node's 1049 mobility session is handed off, the local mobility anchor MUST 1050 update the Binding Cache entry with the accepted registration 1051 values. 1053 2. The local mobility anchor MUST remove the previously created 1054 route(s) for the mobile node's home network prefix(es) associated 1055 with this mobility session. Additionally, if there are no other 1056 mobile node sharing the dynamically created bi-directional tunnel 1057 to the previous mobile access gateway, the tunnel SHOULD be 1058 deleted applying considerations from section 5.6.1 (if the tunnel 1059 is a dynamically created tunnel and not a fixed pre-established 1060 tunnel). 1062 3. If there is no existing bi-directional tunnel to the mobile 1063 access gateway that sent the request, the local mobility anchor 1064 MUST establish a bi-directional tunnel to that mobile access 1065 gateway. Considerations from Section 5.6.1 MUST be applied for 1066 managing the dynamically created bi-directional tunnel. 1068 4. The local mobility anchor MUST create prefix route(s) over the 1069 tunnel to the mobile access gateway for forwarding any traffic 1070 received for the mobile node's home network prefix(es) associated 1071 with that mobility session. The created tunnel and routing state 1072 MUST result in the forwarding behavior on the local mobility 1073 anchor as specified in Section 5.6.2. 1075 5. The local mobility anchor MUST send the Proxy Binding 1076 Acknowledgement message with the Status field set to 0 (Proxy 1077 Binding Update Accepted). The message MUST be constructed as 1078 specified in Section 5.3.6. 1080 5.3.5. Binding De-Registration 1082 1. If the received Proxy Binding Update message with the lifetime 1083 value of zero, has a Source Address in the IPv6 header (or the 1084 address in the Alternate Care-of Address option, if the option is 1085 present) different from what is present in the Proxy-CoA address 1086 field in the Binding Cache entry, the local mobility anchor MUST 1087 ignore the request. 1089 2. Upon accepting the Proxy Binding Update message with the lifetime 1090 value of zero, the local mobility anchor MUST wait for 1091 MinDelayBeforeBCEDelete amount of time, before it deletes the 1092 Binding Cache entry. However, it MUST send the Proxy Binding 1093 Acknowledgement message with the Status field set to 0 (Proxy 1094 Binding Update Accepted). The message MUST be constructed as 1095 specified in Section 5.3.6. 1097 * During this wait period, the local mobility anchor SHOULD drop 1098 the mobile node's data traffic. 1100 * During this wait period, if the local mobility anchor receives 1101 a valid Proxy Binding Update message for the same mobility 1102 session with the lifetime value of greater than zero, and if 1103 that request is accepted, then the Binding Cache entry MUST 1104 NOT be deleted, but must be updated with the newly accepted 1105 registration values and additionally the wait period should be 1106 ended. 1108 * By the end of this wait period, if the local mobility anchor 1109 did not receive any valid Proxy Binding Update message for 1110 this mobility session, then it MUST delete the Binding Cache 1111 entry and remove the routing state created for that mobility 1112 session. The local mobility anchor can potentially reassign 1113 the prefix(es) associated with this mobility session to other 1114 mobile nodes. 1116 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1118 o The local mobility anchor when sending the Proxy Binding 1119 Acknowledgement message to the mobile access gateway MUST 1120 construct the message as specified below. 1122 IPv6 header (src=LMAA, dst=Proxy-CoA) 1123 Mobility header 1124 - BA /* P flag must be set to value of 1 */ 1125 Mobility Options 1126 - Mobile Node Identifier Option (mandatory) 1127 - Home Network Prefix option(s) (mandatory) 1128 - Handoff Indicator option (mandatory) 1129 - Access Technology Type option (mandatory) 1130 - Timestamp Option (optional) 1131 - Mobile Node Link-layer Identifier option (optional) 1132 - Link-local Address option (optional) 1134 Figure 6: Proxy Binding Acknowledgement message format 1136 o The Source Address field in the IPv6 header of the message MUST be 1137 set to the destination address of the received Proxy Binding 1138 Update message. 1140 o The Destination Address field in the IPv6 header of the message 1141 MUST be set to the source address of the received Proxy Binding 1142 Update message. When there is no Alternate Care-of Address option 1143 present in the request, the destination address is the same as the 1144 Proxy-CoA address, otherwise, the address may not be the same as 1145 the Proxy-CoA. 1147 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1148 identifier field in the option MUST be copied from the Mobile Node 1149 Identifier option in the received Proxy Binding Update message. 1150 If the option was not present in the request, the identifier in 1151 the option MUST be set to a zero length identifier. 1153 o At least one Home Network Prefix option MUST be present. 1155 * If the Status field is set to a value greater than or equal to 1156 128, i.e., if the Proxy Binding Update is rejected, all the 1157 Home Network Prefix options that were present in the request 1158 (along with their prefix values) MUST be present in the reply. 1159 But, if there was no Home Network Prefix option present in the 1160 request, then there MUST be only one Home Network Prefix option 1161 and with the value in the option set to ALL_ZERO. 1163 * For all other cases, there MUST be a Home Network Prefix option 1164 for each of the assigned home network prefixes (for that 1165 mobility session) and with the prefix value in the option set 1166 to the allocated prefix value. 1168 o The Handoff Indicator option MUST be present. The handoff 1169 indicator field in the option MUST be copied from the Handoff 1170 Indicator option in the received Proxy Binding Update message. If 1171 the option was not present in the request, the value in the option 1172 MUST be set to zero. 1174 o The Access Technology Type option MUST be present. The access 1175 technology type field in the option MUST be copied from the Access 1176 Technology Type option in the received Proxy Binding Update 1177 message. If the option was not present in the request, the value 1178 in the option MUST be set to zero. 1180 o The Timestamp option MUST be present only if the same option was 1181 present in the received Proxy Binding Update message and MUST NOT 1182 be present otherwise. Considerations from Section 5.5 must be 1183 applied for constructing the Timestamp option. 1185 o The Mobile Node Link-layer Identifier option MUST be present only 1186 if the same option was present in the received Proxy Binding 1187 Update message and MUST NOT be present otherwise. The link-layer 1188 identifier value MUST be copied from the Mobile Node Link-layer 1189 Identifier option present in the received Proxy Binding Update 1190 message. 1192 o The Link-local Address option MUST be present only if the same 1193 option was present in the received Proxy Binding Update message 1194 and MUST NOT be present otherwise. If the Status field in the 1195 reply is set to a value greater than or equal to 128, i.e., if the 1196 Proxy Binding Update is rejected, then the link-local address from 1197 the request MUST be copied to the Link-local Address option in the 1198 reply, otherwise the following considerations apply. 1200 * If the received Proxy Binding Update message has the Link-local 1201 Address option with ALL_ZERO value and if there is an existing 1202 Binding Cache entry associated with this request, then the 1203 link-local address from the Binding Cache entry MUST be copied 1204 to the Link-local Address option in the reply. 1206 * If the received Proxy Binding Update message has the Link-local 1207 Address option with ALL_ZERO value and if there is no existing 1208 Binding Cache entry associated with this request, then the 1209 local mobility anchor MUST generate the link-local address that 1210 the mobile access gateway can use on the point-to-point link 1211 shared with the mobile node. This generated address MUST be 1212 copied to the Link-local Address option in the reply. The same 1213 address MUST also be copied to the link-local address field of 1214 Binding Cache entry created for this mobility session. 1216 * If the received Proxy Binding Update message has the Link-local 1217 Address option with NON_ZERO value, then the link-local address 1218 from the request MUST be copied to the Link-local Address 1219 option in the reply. The same address MUST also be copied to 1220 the link-local address field of the Binding Cache entry 1221 associated with this request (after creating the Binding Cache 1222 entry, if there does not exist one). 1224 o If IPsec is used for protecting the signaling messages, the 1225 message MUST be protected, using the security association existing 1226 between the local mobility anchor and the mobile access gateway. 1228 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1229 NOT be present in the IPv6 header of the packet. 1231 5.4. Multihoming Support 1233 This specification allows mobile nodes to connect to a Proxy Mobile 1234 IPv6 domain through multiple interfaces for simultaneous access. 1235 Following are the key aspects of this multihoming support. 1237 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1238 multiple interfaces for simultaneous access, the local mobility 1239 anchor MUST allocate a mobility session for each of the attached 1240 interfaces. Each mobility session should be managed under a 1241 separate Binding Cache entry and with its own lifetime. 1243 o The local mobility anchor MAY allocate more than one home network 1244 prefix for a given interface of the mobile node. However, all the 1245 prefixes associated with a given interface MUST be managed as part 1246 of one mobility session, associated with that interface. 1248 o The local mobility anchor MUST allow for an handoff between two 1249 different interfaces of a mobile node. In such a scenario, all 1250 the home network prefix(es) associated with one interface (part of 1251 one mobility session) will be associated with a different 1252 interface of the mobile node). The decision on when to create a 1253 new mobility session and when to update an existing mobility 1254 session MUST be based on the Handover hint present in the Proxy 1255 Binding Update message and under the considerations specified in 1256 this section 5.4. 1258 5.4.1. Binding Cache entry lookup considerations 1260 There can be multiple Binding Cache entries for a given mobile node. 1261 When doing a lookup for a mobile node's Binding Cache entry for 1262 processing a received Proxy Binding Update message, the local 1263 mobility anchor MUST apply the following multihoming considerations 1264 (in the below specified order, starting with Section 5.4.1.1). These 1265 rules are chained with the processing rules specified in Section 5.3. 1267 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1268 request 1270 +=====================================================================+ 1271 | Registration/De-Registration Message | 1272 +=====================================================================+ 1273 | At least one HNP Option with NON_ZERO Value | 1274 +=====================================================================+ 1275 | ATT | 1276 +=====================================================================+ 1277 | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | 1278 +=====================================================================+ 1279 | HI | 1280 +==================================+==================================+ 1281 | BCE Lookup Key: Any of the Home Network Prefixes from the request | 1282 +=====================================================================+ 1284 Figure 7: BCE lookup using home network prefix 1286 If there is at least one Home Network Prefix option present in the 1287 request with a NON_ZERO prefix value and irrespective of the presence 1288 of the Mobile Node Link-layer Identifier option in the request, the 1289 following considerations MUST be applied. If there are more than one 1290 instances of the Home Network Prefix option, any one of the Home 1291 Network Prefix options present in the request (with NON_ZERO prefix 1292 value) can be used for locating the Binding Cache entry. 1294 1. The local mobility anchor MUST verify if there is an existing 1295 Binding Cache entry with one of its home network prefixes 1296 matching the prefix value in one of the Home Network Prefix 1297 options of the received Proxy Binding Update message. 1299 2. If there does not exist a Binding Cache entry (with one of its 1300 home network prefixes in the Binding Cache entry matching the 1301 prefix value in one of the Home Network Prefix options of the 1302 received Proxy Binding Update message), the request MUST be 1303 considered as a request for creating a new mobility session. 1305 3. If there exists a Binding Cache entry (with one of its home 1306 network prefixes in the Binding Cache entry matching the prefix 1307 value in one of the Home Network Prefix options of the received 1308 Proxy Binding Update message) but if the mobile node identifier 1309 in the entry does not match the mobile node identifier in the 1310 Mobile Node Identifier option of the received Proxy Binding 1311 Update message, the local mobility anchor MUST reject the request 1312 with the Status field value set to 1313 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1314 authorized for one or more of the requesting home network 1315 prefixes). 1317 4. If there exists a Binding Cache entry (matching MN-Identifier and 1318 one of its home network prefixes in the Binding Cache entry 1319 matching the prefix value in one of the Home Network Prefix 1320 options of the received Proxy Binding Update message), but if all 1321 the prefixes in the request do not match all the prefixes in the 1322 Binding Cache entry, or if they do not match in count, then the 1323 local mobility anchor MUST reject the request with the Status 1324 field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home 1325 network prefixes listed in the BCE do not match all the prefixes 1326 in the received PBU). 1328 5. If there exists a Binding Cache entry (matching MN-Identifier and 1329 all the home network prefixes in the Binding Cache entry matching 1330 all the home network prefixes in the received Proxy Binding 1331 Update message) and if any one or more of these below stated 1332 conditions match, the request MUST be considered as a request for 1333 updating that Binding Cache entry. 1335 * If the Handoff Indicator field in the Handoff Indicator option 1336 present in the request is set to a value of 2 (Handoff between 1337 two different interfaces of the mobile node). 1339 * If there is no Mobile Node Link-layer Identifier option 1340 present in the request, the link-layer identifier value in the 1341 Binding Cache entry is set to ALL_ZERO, the access technology 1342 type field in the Access Technology Type option present in the 1343 request matches the access technology type in the Binding 1344 Cache entry and if the Handoff Indicator field in the Handoff 1345 Indicator option present in the request is set to a value of 3 1346 (Handoff between mobile access gateways for the same 1347 interface). 1349 * If the Proxy-CoA address in the Binding Cache entry matches 1350 the source address of the request (or the address in the 1351 alternate Care-of Address option, if the option is present) 1352 and if the access technology type field in the Access 1353 Technology Type option present in the request matches the 1354 access technology type in the Binding Cache entry. 1356 6. For all other cases, the message MUST be considered as a request 1357 for creating a new mobility session. However, if the received 1358 Proxy Binding Update message has the lifetime value of zero and 1359 if the request cannot be associated with any existing mobility 1360 session, the message MUST be silently ignored. 1362 5.4.1.2. Mobile Node Link-layer Identifier Option present in the 1363 request 1365 +=====================================================================+ 1366 | Registration/De-Registration Message | 1367 +=====================================================================+ 1368 | No HNP option with a NON_ZERO Value | 1369 +=====================================================================+ 1370 | ATT | 1371 +=====================================================================+ 1372 | MN-LL-Identifier Option Present (NON_ZERO Value) | 1373 +=====================================================================+ 1374 | HI | 1375 +==================================+==================================+ 1376 | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | 1377 +=====================================================================+ 1379 Figure 8: BCE Lookup using Link-layer Identifier 1381 If there is no Home Network Prefix option present in the request with 1382 a NON_ZERO prefix value, but if there is a Mobile Node Link-layer 1383 Identifier option present in the request then the following 1384 considerations MUST be applied for locating the Binding Cache entry. 1386 1. The local mobility anchor MUST verify if there is an existing 1387 Binding Cache entry, with the mobile node identifier matching the 1388 identifier in the received Mobile Node Identifier option, access 1389 technology type matching the value in the received Access 1390 Technology Type option and the link-layer identifier value 1391 matching the identifier in the received Mobile Node Link-layer 1392 Identifier option. 1394 2. If there exists a Binding Cache entry (matching MN-Identifier, 1395 ATT and MN-LL-Identifier), the request MUST be considered as a 1396 request for updating that Binding Cache entry. 1398 3. If there does not exist a Binding Cache entry (matching MN- 1399 Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator 1400 field in the Handoff Indicator option present in the request is 1401 set to a value of 2 (Handoff between two different interfaces of 1402 the mobile node). The local mobility anchor MUST apply the 1403 following additional considerations. 1405 * The local mobility anchor MUST verify if there exists one and 1406 only one Binding Cache entry with the mobile node identifier 1407 matching the identifier in the Mobile Node Identifier option 1408 present in the request and for any link-layer identifier 1409 value. If there exists only one such entry (matching the MN- 1410 Identifier), the request MUST be considered as a request for 1411 updating that Binding Cache entry. 1413 4. If there does not exist a Binding Cache entry (matching MN- 1414 Identifier, ATT and MN-LL-Identifier) and if the Handoff 1415 Indicator field in the Handoff Indicator option present in the 1416 request is set to a value of 4 (Handoff state unknown), the local 1417 mobility anchor MUST apply the following additional 1418 considerations. 1420 * The local mobility anchor MUST verify if there exists one and 1421 only one Binding Cache entry with the mobile node identifier 1422 matching the identifier in the Mobile Node Identifier option 1423 present in the request and for any link-layer identifier 1424 value. If there exists only one such entry (matching the MN- 1425 Identifier), the local mobility anchor SHOULD wait till the 1426 existing Binding Cache entry is de-registered by the 1427 previously serving mobile access gateway, before the request 1428 can be considered as a request for updating that Binding Cache 1429 entry. However, if there is no de-registration message that 1430 is received within MaxDelayBeforeNewBCEAssign amount of time, 1431 the local mobility anchor upon accepting the request MUST 1432 consider the request as a request for creating a new mobility 1433 session. The local mobility anchor MAY also choose to create 1434 a new mobility session without waiting for a de-registration 1435 message and this should be configurable on the local mobility 1436 anchor. 1438 5. For all other cases, the message MUST be considered as a request 1439 for creating a new mobility session. However, if the received 1440 Proxy Binding Update message has the lifetime value of zero and 1441 if the request cannot be associated with any existing mobility 1442 session, the message MUST be silently ignored. 1444 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 1445 request 1447 +=====================================================================+ 1448 | Registration/De-Registration Message | 1449 +=====================================================================+ 1450 | No HNP option with a NON_ZERO Value | 1451 +=====================================================================+ 1452 | ATT | 1453 +=====================================================================+ 1454 | MN-LL-Identifier Option Not Present | 1455 +=====================================================================+ 1456 | HI | 1457 +==================================+==================================+ 1458 | BCE Lookup Key: (MN-Identifier) | 1459 +=====================================================================+ 1461 Figure 9: BCE Lookup using Mobile Node Identifier 1463 If there is no Home Network Prefix option present in the request with 1464 a NON_ZERO prefix value and if there is also no Mobile Node Link- 1465 layer Identifier option present in the request then the following 1466 considerations MUST be applied for locating the Binding Cache entry. 1468 1. The local mobility anchor MUST verify if there exists one and 1469 only one Binding Cache entry with the mobile node identifier 1470 matching the identifier in the Mobile Node Identifier option 1471 present in the request. 1473 2. If there exists only one such entry (matching the MN-Identifier) 1474 and the Handoff Indicator field in the Handoff Indicator option 1475 present in the request is set to a value of 2 (Handoff between 1476 two different interfaces of the mobile node) or set to a value of 1477 3 (Handoff between mobile access gateways for the same 1478 interface), then the request MUST be considered as a request for 1479 updating that Binding Cache entry. 1481 3. If there exists only one such entry (matching the MN-Identifier) 1482 and the Handoff Indicator field in the Handoff Indicator option 1483 present in the request is set to a value of 4 (Handoff state 1484 unknown), the local mobility anchor SHOULD wait till the existing 1485 Binding Cache entry is de-registered by the previously serving 1486 mobile access gateway, before the request can be considered as a 1487 request for updating that Binding Cache entry. However, if there 1488 is no de-registration message that is received within 1489 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1490 anchor upon accepting the request MUST consider the request as a 1491 request for creating a new mobility session. The local mobility 1492 anchor MAY also choose to create a new mobility session and 1493 without waiting for a de-registration message and this should be 1494 configurable on the local mobility anchor. 1496 4. For all other cases, the message MUST be considered as a request 1497 for creating a new mobility session. However, if the received 1498 Proxy Binding Update message has the lifetime value of zero and 1499 if the request cannot be associated with any existing mobility 1500 session, the message MUST be silently ignored. 1502 5.5. Timestamp Option for Message Ordering 1504 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1505 registration messages as a way for the home agent to process the 1506 binding updates in the order they were sent by a mobile node. The 1507 home agent and the mobile node are required to manage this counter 1508 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1509 the mobile node moves from one mobile access gateway to another and 1510 in the absence of mechanisms such as context transfer between the 1511 mobile access gateways, the serving mobile access gateway will be 1512 unable to determine the sequence number that it needs to use in the 1513 signaling messages. Hence, the sequence number scheme, as specified 1514 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1516 If the local mobility anchor cannot determine the sending order of 1517 the received Proxy Binding Update messages, it may potentially 1518 process an older message sent by a mobile access gateway where the 1519 mobile node was previously anchored, but delivered out of order, 1520 resulting in incorrectly updating the mobile node's Binding Cache 1521 entry and creating a routing state for tunneling the mobile node's 1522 traffic to the previous mobile access gateway. 1524 For solving this problem, this specification adopts two alternative 1525 solutions. One is based on timestamps and the other based on 1526 sequence numbers, as defined in [RFC-3775]. 1528 The basic principle behind the use of timestamps in binding 1529 registration messages is that the node generating the message inserts 1530 the current time-of-day, and the node receiving the message checks 1531 that this timestamp is greater than all previously accepted 1532 timestamps. The timestamp based solution may be used when the 1533 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1534 have the ability to obtain the last sequence number that was sent in 1535 a Proxy Binding Update message for updating a given mobile node's 1536 binding. 1538 Clock drift reduces the effectiveness of the timestamp mechanism. 1539 The time required for reconnection is the total of the time required 1540 for the mobile node to roam between two mobile access gateways and 1541 the time required for the serving mobile access gateway to detect the 1542 mobile node on its access link and construct the Proxy Binding Update 1543 message. If the clock skew on any one of these two neighboring 1544 mobile access gateways (relative to the common time source used for 1545 clock synchronization) is more than half this reconnection time, the 1546 timestamp solution will not predictably work in all cases and hence 1547 SHOULD NOT be used. 1549 As an alternative to the Timestamp based approach, the specification 1550 also allows the use of Sequence Number based scheme, as specified in 1551 [RFC-3775]. However, for this scheme to work, the serving mobile 1552 access gateway in a Proxy Mobile IPv6 domain MUST have the ability to 1553 obtain the last sequence number that was sent in a binding 1554 registration message. The sequence number MUST be maintained on a 1555 per mobile node basis and MUST be available to the serving mobile 1556 access gateway. This may be achieved by using context transfer 1557 schemes or by maintaining the sequence number in a policy store. 1558 However, the specific details on how the mobile node's sequence 1559 number is made available to the serving mobile access gateway prior 1560 to sending the Proxy Binding Update message is outside the scope of 1561 this document." 1563 Using the Timestamps based approach: 1565 1. A local mobility anchor implementation MUST support the Timestamp 1566 option. If the Timestamp option is present in the received Proxy 1567 Binding Update message, then the local mobility anchor MUST 1568 include a valid Timestamp option in the Proxy Binding 1569 Acknowledgement message that it sends to the mobile access 1570 gateway. 1572 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1573 exchanging binding registration messages using the Timestamp 1574 option MUST have adequately synchronized time-of-day clocks. 1575 This is the essential requirement for this solution to work. If 1576 this requirement is not met, the solution will not predictably 1577 work in all cases. 1579 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1580 synchronize their clocks to a common time source. For 1581 synchronizing the clocks, the nodes MAY use the Network Time 1582 Protocol [RFC-4330]. Deployments MAY also adopt other approaches 1583 suitable for that specific deployment. Alternatively, if there 1584 is mobile node generated timestamp that is increasing at every 1585 attachment to the access link and if that timestamp is available 1586 to the mobile access gateway (Ex: the timestamp option in the 1587 SEND [RFC-3971] messages that the mobile node sends), the mobile 1588 access gateway can use this timestamp or sequence number in the 1589 Proxy Binding Update messages and does not have to depend on any 1590 external clock source. However, the specific details on how this 1591 is achieved are outside the scope of this document. 1593 4. When generating the timestamp value for building the Timestamp 1594 option, the mobility entities MUST ensure that the generated 1595 timestamp is the elapsed time past the same reference epoch, as 1596 specified in the format for the Timestamp option (Section 8.8). 1598 5. If the Timestamp option is present in the received Proxy Binding 1599 Update message, the local mobility anchor MUST ignore the 1600 sequence number field in the message. However, it MUST copy the 1601 sequence number from the received Proxy Binding Update message to 1602 the Proxy Binding Acknowledgement message. 1604 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1605 option, the local mobility anchor MUST check the timestamp field 1606 for validity. In order for it to be considered valid, the 1607 following MUST be true. 1609 * The timestamp value contained in the Timestamp option MUST be 1610 close enough (within TimestampValidityWindow amount of time 1611 difference) to the local mobility anchor's time-of-day clock. 1612 However, if the flag MobileNodeGeneratedTimestampInUse is set 1613 to value of 1, the local mobility anchor MUST ignore this 1614 check and perform only the following check. 1616 * The timestamp MUST be greater than all previously accepted 1617 timestamps in the Proxy Binding Update messages sent for that 1618 mobile node. 1620 7. If the timestamp value in the received Proxy Binding Update is 1621 valid (validity as specified in the above considerations) or if 1622 the flag MobileNodeGeneratedTimestampInUse is set to value of 1, 1623 the local mobility anchor MUST return the same timestamp value in 1624 the Timestamp option included in the Proxy Binding 1625 Acknowledgement message that it sends to the mobile access 1626 gateway. 1628 8. If the timestamp value in the received Proxy Binding Update is 1629 lower than the previously accepted timestamp in the Proxy Binding 1630 Update messages sent for that mobility binding, the local 1631 mobility anchor MUST reject the Proxy Binding Update message and 1632 send a Proxy Binding Acknowledgement message with Status field 1633 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1634 previously accepted timestamp). The message MUST also include 1635 the Timestamp option with the value set to the current time-of- 1636 day on the local mobility anchor. 1638 9. If the timestamp value in the received Proxy Binding Update is 1639 not valid (validity as specified in the above considerations), 1640 the local mobility anchor MUST reject the Proxy Binding Update 1641 and send a Proxy Binding Acknowledgement message with Status 1642 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1643 message MUST also include the Timestamp option with the value set 1644 to the current time-of-day on the local mobility anchor. 1646 Using the Sequence Number based approach: 1648 1. If the Timestamp option is not present in the received Proxy 1649 Binding Update message, the local mobility anchor MUST fall back 1650 to the Sequence Number based scheme. It MUST process the 1651 sequence number field as specified in [RFC-3775]. Also, it MUST 1652 NOT include the Timestamp option in the Proxy Binding 1653 Acknowledgement messages that it sends to the mobile access 1654 gateway. 1656 2. An implementation MUST support the Sequence Number based scheme, 1657 as specified in [RFC-3775]. 1659 3. The Sequence Number based approach can be used only when there is 1660 some mechanism (such as context transfer procedure between mobile 1661 access gateways) that allows the serving mobile access gateway to 1662 obtain the last sequence number that was sent in a Proxy Binding 1663 Update message for updating a given mobile node's binding. 1665 5.6. Routing Considerations 1667 5.6.1. Bi-Directional Tunnel Management 1669 The bi-directional tunnel MUST be used for routing the mobile node's 1670 data traffic between the mobile access gateway and the local mobility 1671 anchor. A tunnel hides the topology and enables a mobile node to use 1672 address(es) from its home network prefix(es) from any access link in 1673 that Proxy Mobile IPv6 domain. A tunnel may be created dynamically 1674 when needed and removed when not needed. However, implementations 1675 MAY choose to use static pre-established tunnels instead of 1676 dynamically creating and tearing them down on a need basis. The 1677 following considerations MUST be applied when using dynamic tunnels. 1679 o A bi-directional tunnel MUST be established between the local 1680 mobility anchor and the mobile access gateway with IPv6-in-IPv6 1681 encapsulation, as described in [RFC-2473]. The tunnel end points 1682 are the Proxy-CoA and LMAA. However, when using IPv4 transport, 1683 the end points of the tunnel are IPv4-LMAA and IPv4-Proxy-CoA with 1684 the encapsulation mode as specified in [ID-IPV4-PMIP6]. 1686 o Implementations MAY use a software timer for managing the tunnel 1687 lifetime and a counter for keeping a count of all the mobile nodes 1688 that are sharing the tunnel. The timer value can be set to the 1689 accepted binding lifetime and can be updated after each periodic 1690 re-registration for extending the lifetime. If the tunnel is 1691 shared for multiple mobile nodes, the tunnel lifetime must be set 1692 to the highest binding lifetime that is granted to any one of 1693 those mobile nodes sharing that tunnel. 1695 o The tunnel SHOULD be deleted when either the tunnel lifetime 1696 expires or when there are no mobile nodes sharing the tunnel. 1698 5.6.2. Forwarding Considerations 1700 Intercepting Packets Sent to the Mobile Node's Home Network: 1702 o When the local mobility anchor is serving a mobile node, it MUST 1703 be able to receive packets that are sent to the mobile node's home 1704 network. In order for it to receive those packets, it MUST 1705 advertise a connected route in to the Routing Infrastructure for 1706 the mobile node's home network prefix(es) or for an aggregated 1707 prefix with a larger scope. This essentially enables IPv6 routers 1708 in that network to detect the local mobility anchor as the last- 1709 hop router for the mobile node's home network prefix(es). 1711 Forwarding Packets to the Mobile Node: 1713 o On receiving a packet from a correspondent node with the 1714 destination address matching a mobile node's home network 1715 prefix(es), the local mobility anchor MUST forward the packet 1716 through the bi-directional tunnel set up for that mobile node. 1718 o The format of the tunneled packet is shown below. Considerations 1719 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 1720 when using IPv4 transport, the format of the packet is as 1721 described in [ID-IPV4-PMIP6]. 1723 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1724 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1725 Upper layer protocols /* Packet Content*/ 1727 Figure 10: Tunneled Packet from LMA to MAG 1729 o The format of the tunneled packet is shown below, when payload 1730 protection using IPsec is enabled for the mobile node's data 1731 traffic. However, when using IPv4 transport, the format of the 1732 packet is as described in [ID-IPV4-PMIP6]. 1734 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1735 ESP Header in tunnel mode /* ESP Header */ 1736 IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */ 1737 Upper layer protocols /* Packet Content*/ 1739 Figure 11: Tunneled Packet from LMA to MAG with Payload Protection 1741 Forwarding Packets Sent by the Mobile Node: 1743 o All the reverse tunneled packets that the local mobility anchor 1744 received from the mobile access gateway, after removing the tunnel 1745 header MUST be routed to the destination specified in the inner 1746 packet header. These routed packets will have the source address 1747 field set to the mobile node's home address. Considerations from 1748 [RFC-2473] MUST be applied for IPv6 decapsulation. 1750 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels 1752 This section describes how the ECN information needs to be handled by 1753 the mobility agents at the tunnel entry and exit points. The ECN 1754 considerations for IP tunnels are specified in [RFC-3168] and the 1755 same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6- 1756 in-IPv6 encapsulation mode). Specifically the full-functionality 1757 option MUST be supported. The relevant ECN considerations from [RFC- 1758 3168] are summarized here for convenience. 1760 Encapsulation Considerations: 1762 o If the Explicit Congestion Notification (ECN) field in the inner 1763 header is set to ECT(0) or ECT(1), where ECT stands for ECN- 1764 Capable Transport (ECT), the ECN field from the inner header MUST 1765 be copied to the outer header. Additionally, when payload 1766 protection using IPsec is enabled for the mobile node's data 1767 traffic, the ECN considerations from [RFC-4301] MUST be applied. 1769 Decapsulation Considerations: 1771 o If the Explicit Congestion Notification (ECN) field in the inner 1772 header is set to ECT(0) or ECT(1), and if the ECN field in the 1773 outer header is set to Congestion Experienced (CE), then the ECN 1774 field in the inner header MUST be set to CE. Otherwise, the ECN 1775 field in the inner header MUST NOT be modified. Additionally, 1776 when payload protection using IPsec is enabled for the mobile 1777 node's data traffic, the ECN considerations from [RFC-4301] MUST 1778 be applied. 1780 5.7. Local Mobility Anchor Address Discovery 1782 Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 1783 10.5 of [RFC-3775], allows a mobile node to discover all the home 1784 agents on its home link by sending an ICMP Home Agent Address 1785 Discovery Request message to the Mobile IPv6 Home-Agents anycast 1786 address, derived from its home network prefix. 1788 The DHAAD message in the current form cannot be used in Proxy Mobile 1789 IPv6 for discovering the address of the mobile node's local mobility 1790 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1791 able to receive any messages sent to the Mobile IPv6 Home-Agents 1792 anycast address corresponding to the mobile node's home network 1793 prefix(es), as the prefix(es) is not hosted on any of its interfaces. 1794 Further, the mobile access gateway will not predictably be able to 1795 locate the serving local mobility anchor that has the mobile node's 1796 binding cache entry. Hence, this specification does not support 1797 Dynamic Home Agent Address Discovery protocol. 1799 In Proxy Mobile IPv6, the address of the local mobility anchor 1800 configured to serve a mobile node can be discovered by the mobility 1801 entities in other ways. This may be a configured entry in the mobile 1802 node's policy profile, or it may be obtained through mechanisms 1803 outside the scope of this document. 1805 5.8. Mobile Prefix Discovery Considerations 1807 This specification does not support mobile prefix discovery. The 1808 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1809 applicable to Proxy Mobile IPv6. 1811 5.9. Route Optimization Considerations 1813 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1814 enables a mobile node to communicate with a correspondent node 1815 directly using its care-of address and further the Return Routability 1816 procedure enables the correspondent node to have reasonable trust 1817 that the mobile node is reachable at both its home address and 1818 care-of address. 1820 This specification does not support the Route Optimization as 1821 specified in Mobile IPv6 [RFC-3775]. However, this specification 1822 does support some other form of route optimization as specified in 1823 Section 6.10.3. 1825 6. Mobile Access Gateway Operation 1827 The Proxy Mobile IPv6 protocol described in this document introduces 1828 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1829 access gateway is the entity that is responsible for detecting the 1830 mobile node's movements to and from the access link and sending the 1831 Proxy Binding Update messages to the local mobility anchor. In 1832 essence, the mobile access gateway performs mobility management on 1833 behalf of a mobile node. 1835 The mobile access gateway is a function that typically runs on an 1836 access router. However, implementations MAY choose to split this 1837 function and run it across multiple systems. The specifics on how 1838 that is achieved or the signaling interactions between those 1839 functional entities are beyond the scope of this document. 1841 The mobile access gateway has the following key functional roles: 1843 o It is responsible for detecting the mobile node's movements on the 1844 access link and for initiating the mobility signaling with the 1845 mobile node's local mobility anchor. 1847 o Emulation of the mobile node's home link on the access link by 1848 sending Router Advertisement messages containing the mobile node's 1849 home network prefix(es), each prefix carried using the Prefix 1850 Information option [RFC-4861]. 1852 o Responsible for setting up the forwarding for enabling the mobile 1853 node to configure one or more addresses from its home network 1854 prefix(es) and use it from the attached access link. 1856 6.1. Extensions to Binding Update List Entry Data Structure 1858 Every mobile access gateway MUST maintain a Binding Update List. 1859 Each entry in the Binding Update List represents a mobile node's 1860 mobility binding with its local mobility anchor. The Binding Update 1861 List is a conceptual data structure, described in Section 11.1 of 1862 [RFC-3775]. 1864 For supporting this specification, the conceptual Binding Update List 1865 entry data structure needs be extended with the following additional 1866 fields. 1868 o The Identifier of the attached mobile node, MN-Identifier. This 1869 identifier is acquired during the mobile node's attachment to the 1870 access link through mechanisms outside the scope of this document. 1872 o The link-layer identifier of the mobile node's connected 1873 interface. This can be acquired from the received Router 1874 Solicitation messages from the mobile node or during the mobile 1875 node's attachment to the access network. This is typically a 1876 link-layer identifier conveyed by the mobile node; however, the 1877 specific details on how that is conveyed is out of scope for this 1878 specification. If this identifier is not available, this variable 1879 length field MUST be set to two (octets) and MUST be initialized 1880 to a value of ALL_ZERO. 1882 o List of IPv6 home network prefixes assigned to the mobile node's 1883 connected interface. The home network prefix(es) may have been 1884 statically configured in the mobile node's policy profile, or, may 1885 have been dynamically allocated by the local mobility anchor. 1886 Each of these prefix entries will also includes the corresponding 1887 prefix length. 1889 o The Link-local address of the mobile access gateway on the access 1890 link shared with the mobile node. 1892 o The IPv6 address of the local mobility anchor serving the attached 1893 mobile node. This address is acquired from the mobile node's 1894 policy profile or from other means. 1896 o The interface identifier (if-id) of the point-to-point link 1897 between the mobile node and the mobile access gateway. This is 1898 internal to the mobile access gateway and is used to associate the 1899 Proxy Mobile IPv6 tunnel to the access link where the mobile node 1900 is attached. 1902 o The tunnel interface identifier (tunnel-if-id) of the bi- 1903 directional tunnel between the mobile node's local mobility anchor 1904 and the mobile access gateway. This is internal to the mobile 1905 access gateway. The tunnel interface identifier is acquired 1906 during the tunnel creation. 1908 6.2. Mobile Node's Policy Profile 1910 A mobile node's policy profile contains the essential operational 1911 parameters that are required by the network entities for managing the 1912 mobile node's mobility service. These policy profiles are stored in 1913 a local or a remote policy store. The mobile access gateway and the 1914 local mobility anchor MUST be able to obtain a mobile node's policy 1915 profile. The policy profile MAY also be handed over to a serving 1916 mobile access gateway as part of a context transfer procedure during 1917 a handoff or the serving mobile access gateway MAY be able to 1918 dynamically generate this profile. The exact details on how this 1919 achieved is outside the scope of this document. However, this 1920 specification requires that a mobile access gateway serving a mobile 1921 node MUST have access to its policy profile. 1923 The following are the mandatory fields of the policy profile: 1925 o The mobile node's identifier (MN-Identifier) 1927 o The IPv6 address of the local mobility anchor (LMAA) 1929 The following are the optional fields of the policy profile: 1931 o The mobile node's IPv6 home network prefix(es) assigned to the 1932 mobile node's connected interface. These prefix(es) have to be 1933 maintained on a per-interface basis. There can be multiple unique 1934 entries for each interface of the mobile node. The specific 1935 details on how the network maintains this association between the 1936 prefix set and the interfaces, specially during the mobility 1937 session handoff between interfaces is outside the scope of this 1938 document. 1940 o The mobile node's IPv6 home network Prefix lifetime. This 1941 lifetime will be same for all the hosted prefixes on the link, as 1942 they all are part of one mobility session. This value can also be 1943 same for all the mobile node's mobility sessions. 1945 o Supported address configuration procedures (Stateful, Stateless or 1946 both) for the mobile node in the Proxy Mobile IPv6 domain 1948 6.3. Supported Access Link Types 1950 This specification supports only point-to-point access link types and 1951 thus it assumes that the mobile node and the mobile access gateway 1952 are the only two nodes on the access link. The link is assumed to 1953 have multicast capability. 1955 This protocol may also be used on other link types, as long as the 1956 link is configured in such a way that it emulates point-to-point 1957 delivery between the mobile node and the mobile access gateway for 1958 all the protocol traffic. 1960 It is also necessary to be able to identify mobile nodes attaching to 1961 the link. Requirements relating to this are covered in Section 6.6. 1963 Finally, while this specification can operate without link layer 1964 indications of node attachment and detachment to the link, the 1965 existence of such indications either on the network or mobile node 1966 side improves the resulting performance. 1968 6.4. Supported Address Configuration Modes 1970 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1971 more global IPv6 addresses on its interface (using Stateless, 1972 Stateful or manual address autoconfiguration procedures) from the 1973 hosted prefix(es) on that link. The Router Advertisement messages 1974 sent on the access link specify the address configuration methods 1975 permitted on that access link for that mobile node. However, the 1976 advertised flags with respect to the address configuration will be 1977 consistent for a mobile node, on any of the access links in that 1978 Proxy Mobile IPv6 domain. Typically, these configuration settings 1979 will be based on the domain wide policy or based on a policy specific 1980 to each mobile node. 1982 When stateless address autoconfiguration is supported on the access 1983 link, the mobile node can generate one or more IPv6 addresses from 1984 the hosted prefix(es) by standard IPv6 mechanisms such as Stateless 1985 Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. 1987 When stateful address autoconfiguration is supported on the link, the 1988 mobile node can obtain the address configuration from the DHCP server 1989 located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms, 1990 as specified in [RFC-3315]. The obtained address(es) will be from 1991 its home network prefix(es). Section 6.11 specifies the details on 1992 how this configuration can be achieved. 1994 Additionally, other address configuration mechanisms specific to the 1995 access link between the mobile node and the mobile access gateway may 1996 also be used for delivering the address configuration to the mobile 1997 node. This specification does not modify the behavior of any of the 1998 standard IPv6 address configuration mechanisms. 2000 6.5. Access Authentication & Mobile Node Identification 2002 When a mobile node attaches to an access link connected to the mobile 2003 access gateway, the deployed access security protocols on that link 2004 SHOULD ensure that the network-based mobility management service is 2005 offered only after authenticating and authorizing the mobile node for 2006 that service. The exact specifics on how this is achieved or the 2007 interactions between the mobile access gateway and the access 2008 security service is outside the scope of this document. This 2009 specification goes with the stated assumption of having an 2010 established trust between the mobile node and the mobile access 2011 gateway, before the protocol operation begins. 2013 6.6. Acquiring Mobile Node's Identifier 2015 All the network entities in a Proxy Mobile IPv6 domain MUST be able 2016 to identify a mobile node, using its MN-Identifier. This identifier 2017 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 2018 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 2019 this identifier in the signaling messages and unambiguously identify 2020 a given mobile node. Following are some of the considerations 2021 related to this MN-Identifier. 2023 o The MN-Identifier is typically obtained as part of the access 2024 authentication or from a notified network attachment event. In 2025 cases where the user identifier authenticated during access 2026 authentication uniquely identifies a mobile node, the MN- 2027 Identifier MAY be the same as the user identifier. However, the 2028 user identifier MUST NOT be used if it identifies a user account 2029 that can be used from more than one mobile node operating in the 2030 same Proxy Mobile IPv6 domain. 2032 o In some cases, the obtained identifier as part of the access 2033 authentication can be a temporary identifier and further that 2034 temporary identifier may be different at each re-authentication. 2035 However, the mobile access gateway MUST be able to use this 2036 temporary identifier and obtain the mobile node's stable 2037 identifier from the policy store. For instance, in AAA-based 2038 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 2039 4372] may be used, as long as it uniquely identifies a mobile 2040 node, and not a user account that can be used with multiple mobile 2041 nodes. 2043 o In some cases and for privacy reasons, the MN-Identifier that the 2044 policy store delivers to the mobile access gateway may not be the 2045 true identifier of the mobile node. However, the mobility access 2046 gateway MUST be able to use this identifier in the signaling 2047 messages exchanged with the local mobility anchor. 2049 o The mobile access gateway MUST be able to identify the mobile node 2050 by its MN-Identifier and it MUST be able to associate this 2051 identity to the point-to-point link shared with the mobile node. 2053 6.7. Home Network Emulation 2055 One of the key functions of a mobile access gateway is to emulate the 2056 mobile node's home network on the access link. It must ensure, the 2057 mobile node does not detect any change with respect to its layer-3 2058 attachment even after it changes its point of attachment in that 2059 Proxy Mobile IPv6 domain. 2061 For emulating the mobile node's home link on the access link, the 2062 mobile access gateway must be able to send Router Advertisement 2063 messages advertising the mobile node's home network prefix(es) 2064 carried using the Prefix Information option(s) [RFC-4861] and with 2065 other address configuration parameters consistent with its home link 2066 properties. Typically, these configuration settings will be based on 2067 the domain wide policy or based on a policy specific to each mobile 2068 node. 2070 Typically, the mobile access gateway learns the mobile node's home 2071 network prefix(es) details from the received Proxy Binding 2072 Acknowledgement message or it may obtain them from the mobile node's 2073 policy profile. However, the mobile access gateway SHOULD send the 2074 Router Advertisements advertising the mobile node's home network 2075 prefix(es) only after successfully completing the binding 2076 registration with the mobile node's local mobility anchor. 2078 When advertising the home network prefix(es) in the Router 2079 Advertisement messages, the mobile access gateway MAY set the prefix 2080 lifetime value for the advertised prefix(es) to any chosen value at 2081 its own discretion. An implementation MAY choose to tie the prefix 2082 lifetime to the mobile node's binding lifetime. The prefix lifetime 2083 can also be an optional configuration parameter in the mobile node's 2084 policy profile. 2086 6.8. Link-Local and Global Address Uniqueness 2088 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 2089 mobile access gateway to the other, will continue to detect its home 2090 network and does not detect a change of layer-3 attachment. Every 2091 time the mobile node attaches to a new link, the event related to the 2092 interface state change will trigger the mobile node to perform DAD 2093 operation on the link-local and global address(es). However, if the 2094 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 2095 detect the link change due to DNAv6 optimizations and may not trigger 2096 the duplicate address detection (DAD) procedure for its existing 2097 addresses, which may potentially lead to address collisions after the 2098 mobile node's handoff to a new link. 2100 The issue of address collision is not relevant to the mobile node's 2101 global address(es). Since the assigned home network prefix(es) are 2102 for the mobile node's exclusive usage, no other node shares an 2103 address (other than Subnet-Router anycast address which is configured 2104 by the mobile access gateway) from the prefix(es) and so the 2105 uniqueness for the mobile node's global address is assured on the 2106 access link. 2108 The issue of address collision is however relevant to the mobile 2109 node's link-local addresses since the mobile access gateway and the 2110 mobile node will have link-local addresses configured from the same 2111 link-local prefix (FE80::/64). This leaves a room for link-local 2112 address collision between the two neighbors (i.e., the mobile node 2113 and the mobile access gateway) on that access link. For solving this 2114 problem, this specification requires that the link-local address that 2115 the mobile access gateway configures on the point-to-point link 2116 shared with a given mobile node be generated by the local mobility 2117 anchor and be stored in the mobile node's Binding Cache entry. This 2118 address will not change for the duration of that mobile node's 2119 mobility session and can be provided to the serving mobile access 2120 gateway at every mobile node's handoff, as part of the Proxy Mobile 2121 IPv6 signaling messages. The specific method by which the local 2122 mobility anchor generates the link-local address is out of scope for 2123 this specification. 2125 It is highly desirable that the access link on the mobile access 2126 gateway shared with the mobile node be provisioned in such a way that 2127 before the mobile node completes the DAD operation [RFC-4862] on its 2128 link-local address, the mobile access gateway on that link is aware 2129 of its own link-local address provided by the local mobility anchor 2130 that it needs to use on that access link. This essentially requires 2131 a successful completion of the Proxy Mobile IPv6 signaling by the 2132 mobile access gateway before the mobile node completes the DAD 2133 operation. This can be achieved by ensuring that link layer 2134 attachment does not complete until the Proxy Mobile IPv6 signaling is 2135 completed. Alternatively, network and local mobility anchor capacity 2136 and signaling retransmission timers can be provisioned in such a way 2137 that signaling is extremely likely to complete during the default 2138 waiting period associated with the DAD process. 2140 Optionally, implementations MAY choose to configure a fixed link- 2141 local address across all the access links in a Proxy Mobile IPv6 2142 domain and without a need for carrying this address from the local 2143 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 2144 signaling messages. The configuration variable 2145 FixedMAGLinkLocalAddressOnAllAccessLinks determines the enabled mode 2146 in that Proxy Mobile IPv6 domain. 2148 6.9. Signaling Considerations 2150 6.9.1. Binding Registrations 2152 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 2154 1. After detecting a new mobile node on its access link, the mobile 2155 access gateway MUST identify the mobile node and acquire its MN- 2156 Identifier. If it determines that the network-based mobility 2157 management service needs to be offered to the mobile node, it 2158 MUST send a Proxy Binding Update message to the local mobility 2159 anchor. 2161 2. The Proxy Binding Update message MUST include the Mobile Node 2162 Identifier option [RFC-4283], carrying the MN-Identifier for 2163 identifying the mobile node. 2165 3. The Home Network Prefix option(s) MUST be present in the Proxy 2166 Binding Update message. If the mobile access gateway learns the 2167 mobile node's home network prefix(es) either from its policy 2168 store or from other means, the mobile access gateway MAY choose 2169 to request the local mobility anchor to allocate the requested 2170 prefix(es) by including a Home Network Prefix option for each of 2171 those requested prefixes. The mobile access gateway MAY also 2172 choose to include just one Home Network Prefix option with the 2173 prefix value of ALL_ZERO, for requesting the local mobility 2174 anchor to do the prefix assignment. However, when including a 2175 Home Network Prefix option with the prefix value of ALL_ZERO, 2176 then there MUST be only one instance of the Home Network prefix 2177 option in the request. 2179 4. The Handoff Indicator option MUST be present in the Proxy 2180 Binding Update message. The Handoff Indicator field in the 2181 Handoff Indicator option MUST be set to a value indicating the 2182 handoff hint. 2184 * The Handoff Indicator field MUST be set to value 1 2185 (Attachment over a new interface), if the mobile access 2186 gateway determines (under the Handoff Indicator 2187 considerations specified in this section) that the mobile 2188 node's current attachment to the network over this interface 2189 is not as a result of a handoff of an existing mobility 2190 session (over the same interface or through a different 2191 interface), but as a result of an attachment over a new 2192 interface. This essentially serves as a request to the local 2193 mobility anchor to create a new mobility session and not 2194 update any existing Binding Cache entry created for the same 2195 mobile node connected to the Proxy Mobile IPv6 domain through 2196 a different interface. 2198 * The Handoff Indicator field MUST be set to value 2 (Handoff 2199 between two different interfaces of the mobile node), if the 2200 mobile access gateway definitively knows the mobile node's 2201 current attachment is due to a handoff of an existing 2202 mobility session, between two different interfaces of the 2203 mobile node. 2205 * The Handoff Indicator field MUST be set to value 3 (Handoff 2206 between mobile access gateways for the same interface), if 2207 the mobile access gateway definitively knows the mobile 2208 node's current attachment is due to a handoff of an existing 2209 mobility session between two mobile access gateways and for 2210 the same interface of the mobile node. 2212 * The Handoff Indicator field MUST be set to value 4 (Handoff 2213 state unknown), if the mobile access gateway cannot determine 2214 if the mobile node's current attachment is due to a handoff 2215 of an existing mobility session. 2217 5. The mobile access gateway MUST apply the below considerations 2218 when choosing the value for the Handoff Indicator field. 2220 * The mobile access gateway can choose to use the value 2 2221 (Handoff between two different interfaces of the mobile 2222 node), only when it knows that the mobile node has on purpose 2223 switched from one interface to another, and the previous 2224 interface is going to be disabled. It may know this due to a 2225 number of factors. For instance, most cellular networks have 2226 controlled handovers where the network knows that the host is 2227 moving from one attachment to another. In this situation the 2228 link layer mechanism can inform the mobility functions that 2229 this is indeed a movement, not a new attachment. 2231 * Some link layers have link-layer identifiers that can be used 2232 to distinguish (a) the movement of a particular interface to 2233 a new attachment from (b) the attachment of a new interface 2234 from the same host. Option value 3 (Handoff between mobile 2235 access gateways for the same interface)is appropriate in case 2236 a and value of 1 (Attachment over a new interface) in case b. 2238 * The mobile access gateway MUST NOT set the option value to 2 2239 (Handoff between two different interfaces of the mobile node) 2240 or 3 (Handoff between mobile access gateways for the same 2241 interface) if it can not be determined that the mobile node 2242 can move the address between the interfaces involved in the 2243 handover or that it is the same interface that has moved. 2244 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2245 physical interfaces to the same domain may suffer unexpected 2246 failures. 2248 * Where no support from the link layer exists, the host and the 2249 network would need to inform each other about the intended 2250 movement. The Proxy Mobile IPv6 protocol does not specify 2251 this and simply requires that knowledge about movements can 2252 be derived either from the link-layer or from somewhere else. 2253 The method by which this is accomplished is outside the scope 2254 of this specification. 2256 6. Either the Timestamp option or a valid sequence number 2257 maintained on a per mobile node basis (if the Sequence Number 2258 based scheme is in use) MUST be present. When Timestamp option 2259 is added to the message, the mobile access gateway SHOULD also 2260 set the Sequence Number field to a value of a monotonically 2261 increasing counter (not to be confused with the per mobile node 2262 sequence number specified in [RFC-3775]). The local mobility 2263 anchor will ignore this field when there is a Timestamp option 2264 present in the request, but will return the same value in the 2265 Proxy Binding Acknowledgement message. This will be useful for 2266 matching the reply to the request message. 2268 7. The Mobile Node Link-layer Identifier option carrying the link- 2269 layer identifier of the currently attached interface MUST be 2270 present in the Proxy Binding Update message, if the mobile 2271 access gateway is aware of the same. If the link-layer 2272 identifier of the currently attached interface is not known or 2273 if the identifier value is ALL_ZERO, this option MUST NOT be 2274 present. 2276 8. The Access Technology Type option MUST be present in the Proxy 2277 Binding Update message. The access technology type field in the 2278 option SHOULD be set to the type of access technology by which 2279 the mobile node is currently attached to the mobile access 2280 gateway. 2282 9. The Link-local Address option MUST be present in the Proxy 2283 Binding Update message only if the value of the configuration 2284 variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a 2285 value of ALL_ZERO, otherwise the Link-local Address option MUST 2286 NOT be present in the request. Considerations from Section 6.8 2287 MUST be applied when using the Link-local Address option. 2289 * For querying the local mobility anchor to provide the link- 2290 local address that it should use on the point-to-point link 2291 shared with the mobile node, this option MUST be set to 2292 ALL_ZERO value. This essentially serves as a request to the 2293 local mobility anchor to provide the link-local address that 2294 it can use on the access link shared with the mobile node. 2296 10. The Proxy Binding Update message MUST be constructed as 2297 specified in Section 6.9.1.5. 2299 11. If there is no existing Binding Update List entry for that 2300 mobile node, the mobile access gateway MUST create a Binding 2301 Update List entry for the mobile node upon sending the Proxy 2302 Binding Update message. 2304 6.9.1.2. Receiving Proxy Binding Acknowledgement 2306 On receiving a Proxy Binding Acknowledgement message (format 2307 specified in Section 8.2) from the local mobility anchor, the mobile 2308 access gateway MUST process the message as specified below. 2310 1. The received Proxy Binding Acknowledgement message (a Binding 2311 Acknowledgement message with the 'P' flag set to value of 1) 2312 MUST be authenticated as described in Section 4. When IPsec is 2313 used for message authentication, the SPI in the IPsec header 2314 [RFC-4306] of the received packet is needed for locating the 2315 security association, for authenticating the Proxy Binding 2316 Acknowledgement message. 2318 2. The mobile access gateway MUST observe the rules described in 2319 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2320 the received Proxy Binding Acknowledgement message. 2322 3. The mobile access gateway MUST apply the considerations 2323 specified in Section 5.5 for processing the Sequence Number 2324 field and the Timestamp option (if present), in the message. 2326 4. The mobile access gateway MUST ignore any checks, specified in 2327 [RFC-3775] related to the presence of a Type 2 Routing header in 2328 the Proxy Binding Acknowledgement message. 2330 5. The mobile access gateway MAY use the mobile node identifier 2331 present in the Mobile Node Identifier option for matching the 2332 response to the request messages that it sent recently. 2333 However, if there is more than one request message in its 2334 request queue for the same mobile node, the sequence number 2335 field can be used for identifying the exact message from those 2336 messages. There are other ways to achieve this and 2337 implementations are free to adopt the best approach that suits 2338 their implementation. Additionally, if the received Proxy 2339 Binding Acknowledgement message does not match any of the Proxy 2340 Binding Update messages that it sent recently, the message MUST 2341 be ignored. 2343 6. If the received Proxy Binding Acknowledgement message has any 2344 one or more of the following options, Handoff Indicator option, 2345 Access Technology Type option, Mobile Node Link-layer Identifier 2346 option, Mobile Node Identifier option, carrying option values 2347 that are different from the option values present in the 2348 corresponding request (Proxy Binding Update) message, the 2349 message MUST be ignored as the local mobility anchor is expected 2350 to echo back all these listed options and with the same option 2351 values in the reply message. In this case, the mobile access 2352 gateway MUST NOT retransmit the Proxy Binding Update message 2353 till an administrative action is taken. 2355 7. If the received Proxy Binding Acknowledgement message has the 2356 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2357 registration not enabled for the mobile node), the mobile access 2358 gateway SHOULD NOT send a Proxy Binding Update message again for 2359 that mobile node till an administrative action is taken. It 2360 MUST deny the mobility service to that mobile node. 2362 8. If the received Proxy Binding Acknowledgement message has the 2363 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2364 (Timestamp value lower than previously accepted value), the 2365 mobile access gateway SHOULD try to register again to reassert 2366 the mobile node's presence on its access link. The mobile 2367 access gateway is not specifically required to synchronize its 2368 clock upon receiving this error code. 2370 9. If the received Proxy Binding Acknowledgement message has the 2371 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2372 value), the mobile access gateway SHOULD try to register again 2373 only after it has synchronized its clock to a common time source 2374 that is used by all the mobility entities in that domain for 2375 their clock synchronization. The mobile access gateway SHOULD 2376 NOT synchronize its clock to the local mobility anchor's system 2377 clock, based on the timestamp present in the received message. 2379 10. If the received Proxy Binding Acknowledgement message has the 2380 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2381 (The mobile node is not authorized for one or more of the 2382 requesting home network prefix(es)), the mobile access gateway 2383 SHOULD NOT request for the same prefix(es) again, but MAY 2384 request the local mobility anchor to do the assignment of 2385 prefix(es) by including only one Home Network Prefix option with 2386 the prefix value set to ALL_ZERO. 2388 11. If the received Proxy Binding Acknowledgement message has the 2389 Status field value set to any value greater than or equal to 128 2390 (i.e., if the binding is rejected), the mobile access gateway 2391 MUST NOT advertise the mobile node's home network prefix(es) in 2392 the Router Advertisement messages sent on that access link and 2393 MUST deny the mobility service to the mobile node by not 2394 forwarding any packets received from the mobile node using an 2395 address from the home network prefix(es). It MAY also tear down 2396 the point-to-point link shared with the mobile node. 2398 12. If the received Proxy Binding Acknowledgement message has the 2399 Status field value set to 0 (Proxy Binding Update accepted), the 2400 mobile access gateway MUST establish a bi-directional tunnel to 2401 the local mobility anchor (if there is no existing bi- 2402 directional tunnel to that local mobility anchor). 2403 Considerations from Section 5.6.1 MUST be applied for managing 2404 the dynamically created bi-directional tunnel. 2406 13. The mobile access gateway MUST set up the route for forwarding 2407 the packets received from the mobile node using address(es) from 2408 its home network prefix(es) through the bi-directional set up 2409 for that mobile node. The created tunnel and the routing state 2410 MUST result in the forwarding behavior on the mobile access 2411 gateway as specified in Section 6.10.5. 2413 14. The mobile access gateway MUST also update the Binding Update 2414 List entry to reflect the accepted binding registration values. 2415 It MUST also advertise the mobile node's home network prefix(es) 2416 as the hosted on-link prefixes, by including them in the Router 2417 Advertisement messages that it sends on that access link. 2419 15. If the received Proxy Binding Acknowledgement message has the 2420 address in the Link-local Address option set to a NON_ZERO 2421 value, the mobile access gateway SHOULD configure that link- 2422 local address on that point-to-point link and SHOULD NOT 2423 configure any other link-local address without performing a DAD 2424 operation [RFC-4862]. This will avoid any potential link-local 2425 address collisions on that access link. However, if the link- 2426 local address generated by the local mobility anchor happens to 2427 be already in use by the mobile node on that link, the mobile 2428 access gateway MUST NOT use that address, but SHOULD configure a 2429 different link-local address. It SHOULD also upload this link- 2430 local address to the local mobility anchor by immediately 2431 sending a Proxy Binding Update message and by including this 2432 address in the Link-local Address option. 2434 6.9.1.3. Extending Binding Lifetime 2436 1. For extending the lifetime of a currently registered mobile node 2437 (i.e., after a successful initial binding registration from the 2438 same mobile access gateway), the mobile access gateway can send a 2439 Proxy Binding Update message to the local mobility anchor with a 2440 new lifetime value. This re-registration message MUST be 2441 constructed with the same set of options as the initial Proxy 2442 Binding Update message, under the considerations specified in 2443 Section 6.9.1.1. However the following exceptions apply. 2445 2. There MUST be a Home Network Prefix option for each of the 2446 assigned home network prefixes assigned for that mobility session 2447 and with the prefix value in the option set to that respective 2448 prefix value. 2450 3. The Handoff Indicator field in the Handoff Indicator option MUST 2451 be set to a value of 5 (Handoff state not changed - Re- 2452 Registration). 2454 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2456 1. If at any point the mobile access gateway detects that the mobile 2457 node has moved away from its access link, or if it decides to 2458 terminate the mobile node's mobility session, it SHOULD send a 2459 Proxy Binding Update message to the local mobility anchor with 2460 the lifetime value set to zero. This de-registration message 2461 MUST be constructed with the same set of options as the initial 2462 Proxy Binding Update message, under the considerations specified 2463 in Section 6.9.1.1. However, the following exceptions apply. 2465 2. There MUST be a Home Network Prefix option for each of the 2466 assigned home network prefix(es) assigned for that mobility 2467 session and with the prefix value in the option set to the 2468 respective prefix value. 2470 3. The Handoff Indicator field in the Handoff Indicator option MUST 2471 be set to a value of 4 (Handoff state unknown). 2473 Either upon receipt of a Proxy Binding Acknowledgement message from 2474 the local mobility anchor with the Status field set to 0 (Proxy 2475 Binding Update Accepted), or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2476 timeout waiting for the reply, the mobile access gateway MUST do the 2477 following: 2479 1. It MUST remove the Binding Update List entry for the mobile node 2480 from its Binding Update List. 2482 2. It MUST remove the created routing state for tunneling the mobile 2483 node's traffic. 2485 3. If there is a dynamically created tunnel to the mobile node's 2486 local mobility anchor and if there are not other mobile nodes for 2487 which the tunnel is being used, then the tunnel MUST be deleted. 2489 4. It MUST tear down the point-to-point link shared with the mobile 2490 node. This action will force the mobile node to remove any IPv6 2491 address configuration on the interface connected to this point- 2492 to-point link. 2494 6.9.1.5. Constructing the Proxy Binding Update Message 2496 o The mobile access gateway when sending the Proxy Binding Update 2497 message to the local mobility anchor MUST construct the message as 2498 specified below. 2500 IPv6 header (src=Proxy-CoA, dst=LMAA) 2501 Mobility header 2502 - BU /* P & A flags MUST be set to value 1 */ 2503 Mobility Options 2504 - Mobile Node Identifier option (mandatory) 2505 - Home Network Prefix option(s) (mandatory) 2506 - Handoff Indicator option (mandatory) 2507 - Access Technology Type option (mandatory) 2508 - Timestamp option (optional) 2509 - Mobile Node Link-layer Identifier option (optional) 2510 - Link-local Address option (optional) 2512 Figure 12: Proxy Binding Update message format 2514 o The Source Address field in the IPv6 header of the message MUST be 2515 set to the global address configured on the egress interface of 2516 the mobile access gateway. When there is no Alternate Care-of 2517 Address option present in the request, this address will be 2518 considered as the Proxy-CoA address for this Proxy Binding Update 2519 message. However, when there is Alternate Care-of Address option 2520 present in the request, this address will be not be considered as 2521 the Proxy-CoA address, but the address in the alternate Care-of 2522 Address option will be considered as the Proxy-CoA address. 2524 o The Destination Address field in the IPv6 header of the message 2525 MUST be set to the local mobility anchor address. 2527 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2529 o At least one Home Network Prefix option MUST be present. 2531 o The Handoff Indicator option MUST be present. 2533 o The Access Technology Type option MUST be present. 2535 o The Timestamp option MAY be present. 2537 o The Mobile Node Link-layer Identifier option MAY be present. 2539 o The Link-local Address option MAY be present. 2541 o If IPsec is used for protecting the signaling messages, the 2542 message MUST be protected, using the security association existing 2543 between the local mobility anchor and the mobile access gateway. 2545 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2546 3775] MUST NOT be present in the IPv6 Destination Options 2547 extension header of the Proxy Binding Update message. 2549 6.9.2. Router Solicitation Messages 2551 A mobile node may send a Router Solicitation message on the access 2552 link shared with the mobile access gateway. The Router Solicitation 2553 message that the mobile node sends is as specified in [RFC-4861]. 2554 The mobile access gateway on receiving the Router Solicitation 2555 message or before sending a Router Advertisement message MUST apply 2556 the following considerations. 2558 1. The mobile access gateway on receiving the Router Solicitation 2559 message SHOULD send a Router Advertisement message containing the 2560 mobile node's home network prefix(es) as the on-link prefix(es). 2561 However, before sending the Router Advertisement message 2562 containing the mobile node's home network prefix(es), it SHOULD 2563 complete the binding registration process with the mobile node's 2564 local mobility anchor. 2566 2. If the local mobility anchor rejects the Proxy Binding Update 2567 message, or, if the mobile access gateway failed to complete the 2568 binding registration process for whatever reason, the mobile 2569 access gateway MUST NOT advertise the mobile node's home network 2570 prefix(es) in the Router Advertisement messages that it sends on 2571 the access link. However, it MAY choose to advertise a local 2572 visited network prefix(es) to enable the mobile node for regular 2573 IPv6 access. 2575 3. The mobile access gateway SHOULD add the MTU option, as specified 2576 in [RFC-4861], to the Router Advertisement messages that it sends 2577 on the access link. This will ensure the mobile node on the link 2578 uses the advertised MTU value. The MTU value SHOULD reflect the 2579 tunnel MTU for the bi-directional tunnel between the mobile 2580 access gateway and the local mobility anchor. Considerations 2581 from Section 6.9.5 SHOULD be applied for determining the tunnel 2582 MTU value. 2584 6.9.3. Default-Router 2586 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2587 router for the mobile node on the access link. However, as the 2588 mobile node moves from one access link to another, the serving mobile 2589 access gateway on those respective links will send the Router 2590 Advertisement messages. If these Router Advertisements are sent 2591 using a different link-local address or a different link-layer 2592 address, the mobile node will always detect a new default-router 2593 after every handoff. For solving this problem, this specification 2594 requires all the mobile access gateways in the Proxy Mobile IPv6 2595 domain to use the same link-local and link-layer address on any of 2596 the access links where ever the mobile node attaches. These 2597 addresses can be fixed addresses across the entire Proxy Mobile IPv6 2598 domain and all the mobile access gateways can use these globally 2599 fixed address on any of the point-to-point links. The configuration 2600 variables FixedMAGLinkLocalAddressOnAllAccessLinks and 2601 FixedMAGLinkLayerAddressOnAllAccessLinks SHOULD be used for this 2602 purpose. Additionally, this specification allows the local mobility 2603 anchor to generate the link-local address and provide it to the 2604 mobile access gateway as part of the signaling messages. 2606 However, both of these approaches (a link-local address generated by 2607 the local mobility anchor or when using a globally fixed link-local 2608 address) have implications on the deployment of SEcure Neighbor 2609 Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and 2610 public key pairs, and their Router Advertisements are signed with the 2611 private keys of these key pairs. When a number of different routers 2612 use the same addresses, the routers either all have to be able to 2613 construct these signatures for the same key pair, or the used key 2614 pair and the router's cryptographic identity must change after a 2615 movement. Both approaches are problematic. Sharing of private key 2616 information across a number of nodes would be inappropriate. And 2617 changing even the cryptographic identity of the router goes against 2618 the general idea of the Proxy Mobile IPv6 being as invisible to the 2619 hosts as possible. 2621 There is, however, ongoing work at the IETF to revise the SEND 2622 specifications. It is suggested that these revisions also address 2623 the above problem. Other revisions are needed to deal with other 2624 problematic cases (such as Neighbor Discovery proxies) before wide- 2625 spread deployment of SEND. 2627 6.9.4. Retransmissions and Rate Limiting 2629 The mobile access gateway is responsible for retransmissions and rate 2630 limiting the Proxy Binding Update messages that it sends to the local 2631 mobility anchor. The Retransmission and the Rate Limiting rules are 2632 as specified in [RFC-3775]. However, the following considerations 2633 MUST be applied. 2635 1. When the mobile access gateway sends a Proxy Binding Update 2636 message, it should use the constant, INITIAL_BINDACK_TIMEOUT 2637 [RFC-3775], for configuring the retransmission timer, as 2638 specified in Section 11.8 [RFC-3775]. However, the mobile access 2639 gateway is not required to use a longer retransmission interval 2640 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2641 the initial Proxy Binding Update message. 2643 2. If the mobile access gateway fails to receive a valid matching 2644 response for a registration or re-registration message within the 2645 retransmission interval, it SHOULD retransmit the message until a 2646 response is received. However, the mobile access gateway MUST 2647 ensure the mobile node is still attached to the connected link 2648 before retransmitting the message. 2650 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2651 gateway MUST use an exponential back-off process in which the 2652 timeout period is doubled upon each retransmission, until either 2653 the node receives a response or the timeout period reaches the 2654 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2655 MAY continue to send these messages at this slower rate 2656 indefinitely. 2658 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2659 Binding Update messages MUST use the latest timestamp. If the 2660 Sequence number scheme is in use, the retransmitted Proxy Binding 2661 Update messages MUST use a Sequence Number value greater than 2662 that used for the previous transmission of this Proxy Binding 2663 Update message, just as specified in [RFC-3775]. 2665 6.9.5. Path MTU Discovery 2667 It is important that mobile node, mobile access gateway, and local 2668 mobility anchor have a correct understanding of MTUs. When the 2669 mobile node uses the correct MTU, it can send packets that do not 2670 exceed the local link MTU and do not cause the tunneled packets from 2671 the mobile access gateway to be fragmented. This is important both 2672 from the perspective of efficiency, as well as preventing hard-to- 2673 diagnose MTU problems. The following are some of the considerations 2674 related to Path MTU discovery. 2676 o The local mobility anchor and mobile access gateway MAY use the 2677 Path MTU Discovery mechanisms as specified in [RFC-1981] or in 2678 [RFC-4821] for determining the Path MTU (PMTU) for the (LMA-MAG) 2679 paths. The specific discovery mechanism to be used in a given 2680 deployment can be configurable. 2682 o The mobility entities MUST implement and SHOULD support ICMP-based 2683 Path MTU discovery mechanism as specified in [RFC-1981]. However, 2684 this mechanism may not work correctly if the Proxy Mobile IPv6 2685 network does not deliver or process ICMP Packet Too Big messages. 2687 o The mobility entities MAY implement Packetization Layer Path MTU 2688 discovery mechanisms as specified in [RFC-4821] and use any 2689 application traffic as a payload for the PMTU discovery. Neither 2690 the Proxy Mobile IPv6 protocol or the tunnel between the mobile 2691 access gateway and local mobility agent can easily be used for 2692 this purpose. However, implementations SHOULD support at least 2693 the use of an explicit ICMP Echo Request/Response for this 2694 purpose. 2696 o The mobility entities MAY choose to perform Path MTU discovery for 2697 all the (LMA-MAG) paths at the boot time and may repeat this 2698 operation periodically to ensure the Path MTU values have not 2699 changed for those paths. If the dynamic PMTU discovery mechanisms 2700 fail to determine the Path MTU, an administratively configured 2701 default value MUST be used. 2703 o The IPv6 tunnel MTU for an established tunnel between the local 2704 mobility anchor and the mobile access gateway MUST be computed 2705 based on the determined Path MTU value for that specific path and 2706 the computation should be as specified in Section 6.7 of [RFC- 2707 2473]. 2709 o The mobile access gateway SHOULD use the determined tunnel Path 2710 MTU value (for the tunnel established with the mobile node's local 2711 mobility anchor) as the MTU value in the MTU option that it sends 2712 in the Router Advertisements on the access link shared with the 2713 mobile node. 2715 o If the mobile access gateway detects a change in MTU value for any 2716 of the paths (LMA-MAG) and at any point of time, the corresponding 2717 tunnel MTU value MUST be updated to reflect the change in Path MTU 2718 value. The adjusted tunnel MTU value SHOULD be notified to the 2719 impacted mobile nodes by sending additional Router Advertisement 2720 messages. Additionally, the adjusted tunnel MTU value MUST be 2721 used in all the subsequent Router Advertisement messages as well. 2723 6.10. Routing Considerations 2725 This section describes how the mobile access gateway handles the 2726 traffic to/from the mobile node that is attached to one of its access 2727 interfaces. 2729 Proxy-CoA LMAA 2730 | | 2731 +--+ +---+ +---+ +--+ 2732 |MN|----------|MAG|======================|LMA|----------|CN| 2733 +--+ +---+ +---+ +--+ 2734 IPv6 Tunnel 2736 Figure 13: Proxy Mobile IPv6 Tunnel 2738 6.10.1. Transport Network 2740 As per this specification, the transport network between the local 2741 mobility anchor and the mobile access gateway is an IPv6 network. 2742 The companion document [ID-IPV4-PMIP6] specifies the required 2743 extensions for negotiating IPv4 transport and the corresponding 2744 encapsulation mode. 2746 6.10.2. Tunneling & Encapsulation Modes 2748 An IPv6 address that a mobile node uses from its home network 2749 prefix(es) is topologically anchored at the local mobility anchor. 2750 For a mobile node to use this address from an access network attached 2751 to a mobile access gateway, proper tunneling techniques have to be in 2752 place. Tunneling hides the network topology and allows the mobile 2753 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2754 packet and to be routed between the local mobility anchor and the 2755 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2756 defines the use of IPv6-over-IPv6 tunneling [RFC-2473], between the 2757 home agent and the mobile node and this specification extends the use 2758 of the same tunneling mechanism for use between the local mobility 2759 anchor and the mobile access gateway. 2761 On most operating systems, a tunnel is implemented as a virtual 2762 point-to-point interface. The source and the destination address of 2763 the two end points of this virtual interface along with the 2764 encapsulation mode are specified for this virtual interface. Any 2765 packet that is routed over this interface gets encapsulated with the 2766 outer header as specified for that point to point tunnel interface. 2768 For creating a point to point tunnel to any local mobility anchor, 2769 the mobile access gateway may implement a tunnel interface with the 2770 source address field set to a global address on its egress interface 2771 (Proxy-CoA) and the destination address field set to the global 2772 address of the local mobility anchor (LMAA). 2774 The following is the supported packet encapsulation mode that can be 2775 used by the mobile access gateway and the local mobility anchor for 2776 routing mobile node's IPv6 datagrams. 2778 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2779 2473]. 2781 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2782 modes for supporting IPv4 transport. 2784 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2785 details on how this mode is negotiated is specified in [ID-IPV4- 2786 PMIP6]. 2788 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2789 packet. This mode is specified in [ID-IPV4-PMIP6]. 2791 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2792 packet with a TLV header. This mode is specified in [ID-IPV4- 2793 PMIP6]. 2795 6.10.3. Local Routing 2797 If there is data traffic between a visiting mobile node and a 2798 correspondent node that is locally attached to an access link 2799 connected to the mobile access gateway, the mobile access gateway MAY 2800 optimize on the delivery efforts by locally routing the packets and 2801 by not reverse tunneling them to the mobile node's local mobility 2802 anchor. The flag EnableMAGLocalRouting MAY be used for controlling 2803 this behavior. However, in some systems, this may have an 2804 implication on the mobile node's accounting and policy enforcement as 2805 the local mobility anchor is not in the path for that traffic and it 2806 will not be able to apply any traffic policies or do any accounting 2807 for those flows. 2809 This decision of path optimization SHOULD be based on the policy 2810 configured on the mobile access gateway, but enforced by the mobile 2811 node's local mobility anchor. The specific details on how this is 2812 achieved are beyond of the scope of this document. 2814 6.10.4. Tunnel Management 2816 All the considerations mentioned in Section 5.6.1 for the tunnel 2817 management on the local mobility anchor apply for the mobile access 2818 gateway as well. 2820 6.10.5. Forwarding Rules 2822 Forwarding Packets sent to the Mobile Node's Home Network: 2824 o On receiving a packet from the bi-directional tunnel established 2825 with the mobile node's local mobility anchor, the mobile access 2826 gateway MUST use the destination address of the inner packet for 2827 forwarding it on the interface where the destination network 2828 prefix is hosted. The mobile access gateway MUST remove the outer 2829 header before forwarding the packet. Considerations from [RFC- 2830 2473] MUST be applied for IPv6 decapsulation. If the mobile 2831 access gateway cannot find the connected interface for that 2832 destination address, it MUST silently drop the packet. For 2833 reporting an error in such a scenario, in the form of a ICMP 2834 control message, the considerations from [RFC-2473] MUST be 2835 applied. 2837 o On receiving a packet from a correspondent node that is locally 2838 connected and which is destined to a mobile node that is on 2839 another locally connected access link, the mobile access gateway 2840 MUST check the flag EnableMAGLocalRouting, to ensure the mobile 2841 access gateway is allowed to route the packet directly to the 2842 mobile node. If the mobile access gateway is not allowed to route 2843 the packet directly, it MUST route the packet through the bi- 2844 directional tunnel established between itself and the mobile 2845 node's local mobility anchor. Otherwise, it can route the packet 2846 directly to the mobile node. 2848 Forwarding Packets Sent by the Mobile Node: 2850 o On receiving a packet from a mobile node connected to its access 2851 link, the mobile access gateway MUST ensure that there is an 2852 established binding for that mobile node with its local mobility 2853 anchor before forwarding the packet directly to the destination or 2854 before tunneling the packet to the mobile node's local mobility 2855 anchor. 2857 o On receiving a packet from a mobile node connected to its access 2858 link for a destination that is locally connected, the mobile 2859 access gateway MUST check the flag EnableMAGLocalRouting, to 2860 ensure the mobile access gateway is allowed to route the packet 2861 directly to the destination. If the mobile access gateway is not 2862 allowed to route the packet directly, it MUST route the packet 2863 through the bi-directional tunnel established between itself and 2864 the mobile node's local mobility anchor. Otherwise, it MUST route 2865 the packet directly to the destination. 2867 o On receiving a packet from a mobile node connected to its access 2868 link, to a destination that is not directly connected, the packet 2869 MUST be forwarded to the local mobility anchor through the bi- 2870 directional tunnel established between itself and the mobile 2871 node's local mobility anchor. However, the packets that are sent 2872 with the link-local source address MUST NOT be forwarded. 2874 o The format of the tunneled packet is shown below. Considerations 2875 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 2876 when using IPv4 transport, the format of the tunneled packet is as 2877 described in [ID-IPV4-PMIP6]. 2879 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2880 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2881 Upper layer protocols /* Packet Content*/ 2883 Figure 14: Tunneled Packet from MAG to LMA 2885 o The format of the tunneled packet is shown below, when payload 2886 protection using IPsec is enabled for the mobile node's data 2887 traffic. However, when using IPv4 transport, the format of the 2888 packet is as described in [ID-IPV4-PMIP6]. 2890 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2891 ESP Header in tunnel mode /* ESP Header */ 2892 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2893 Upper layer protocols /* Packet Content*/ 2895 Figure 15: Tunneled Packet from MAG to LMA with Payload Protection 2897 6.11. Supporting DHCP based Address Configuration on the Access Link 2899 This section explains how Stateful Address Configuration using DHCP 2900 support can be enabled in a Proxy Mobile IPv6 domain. It also 2901 identifies the required configuration in DHCP and mobility 2902 infrastructures for supporting this address configuration mode and 2903 also identifies the protocol interactions between these two systems. 2905 o For supporting Stateful Address Configuration using DHCP, the DHCP 2906 relay agent [RFC-3315] service MUST be supported on all the mobile 2907 access gateways in the Proxy Mobile IPv6 domain. Further, as 2908 specified in Section 20 of [RFC-3315], the DHCP relay agent should 2909 be configured to use a list of destination addresses, which MAY 2910 include unicast addresses, the All_DHCP_Servers multicast address, 2911 or other addresses as required in a given deployment. 2913 o The DHCP infrastructure needs to be configured to assign addresses 2914 from each of the prefixes assigned to a link in that Proxy Mobile 2915 IPv6 domain. The DHCP relay agent indicates the link to which the 2916 mobile node is attached by including an IPv6 address from any of 2917 the prefixes assigned to that link in the link-address field of 2918 the Relay Forward message. Therefore, for each link in the Mobile 2919 IPv6 domain, the DHCP infrastructure will: 2921 * be configured with a list of all of the prefixes associated 2922 with that link; 2924 * identify the link to which the mobile node is attached by 2925 looking up the prefix for the link-address field in the Relay 2926 Forward message in the list of prefixes associated with each 2927 link 2929 * assign to the host an address from each prefix associated with 2930 the link to which the mobile node is attached. 2932 This DHCP infrastructure configuration requirement is identical 2933 with other IPv6 networks; other than receiving DHCP messages from 2934 a mobile node through different relay agents (MAGs) over time, the 2935 DHCP infrastructure will be unaware of the mobile node's 2936 capability with respect to mobility support. 2938 o The local mobility anchor needs to have the same awareness with 2939 respect to the links along with the associated prefixes in a Proxy 2940 Mobile IPv6 domain. When a local mobility anchor assigns 2941 prefix(es) to a mobile node, it MUST assign all the prefixes 2942 associated with a given link and all of those assigned prefixes 2943 will remain as the home network prefixes for that mobile node 2944 through out the life of that mobility session. The serving mobile 2945 access gateway that hosts these prefixes is physically connected 2946 to that link and can function as the DHCP relay agent. This 2947 common understanding between DHCP and mobility entities about all 2948 the links in the domain along with the associated prefixes, 2949 provides the required coordination for allowing mobility entities 2950 to perform prefix assignment dynamically to a mobile node and 2951 still allow the DHCP infrastructure to perform address assignment 2952 for that mobile node only from its home network prefixes. 2954 o When a mobile node sends a DHCP request message, the DHCP relay 2955 agent function on the mobile access gateway will set the link- 2956 address field in the DHCP message to an address in the mobile 2957 node's home network prefix (any one of the mobile node's home 2958 network prefixes assigned to that mobile node's attached 2959 interface). The mobile access gateway can generate an 2960 autoconfiguration address from one of the mobile node's home 2961 network prefixes [RFC-4862] and can use this address link-address 2962 option, so as to provide a hint to the DHCP Server for the link 2963 identification. The DHCP server on receiving the request from the 2964 mobile node, will allocate addresses from all the prefixes 2965 associated with that link (identified using the link-address field 2966 of the request). 2968 o Once the mobile node obtains address(es) and moves to a different 2969 link and sends a DHCP request (at any time) for extending the DHCP 2970 lease, the DHCP relay agent on the new link will set the link- 2971 address field in the DHCP Relay Forward message to one of the 2972 mobile node's home network prefixes. The DHCP server will 2973 identify the client from the Client-DUID option and will identify 2974 the link from the link-address option present in the request and 2975 will allocate the same address(es) as before. 2977 o For correct operation of the model of network-based mobility 2978 management in which the host does not participate in any mobility 2979 management, the mobile node MUST always be assigned an identical 2980 set of IPv6 addresses regardless of the access link to which the 2981 mobile node is attached. For example, the mobile access gateways 2982 in the Proxy Mobile IPv6 domain should be configured so that DHCP 2983 messages from a mobile node will always be handled by the same 2984 DHCP server or by a server from the same group of coordinated DHCP 2985 servers serving that domain. DHCP based address configuration is 2986 not recommended for deployments in which the local mobility anchor 2987 and the mobile access gateway are located in different 2988 administrative domains. 2990 6.12. Home Network Prefix Renumbering 2992 If the mobile node's home network prefix(es) gets renumbered or 2993 becomes invalid during the middle of a mobility session, the mobile 2994 access gateway MUST withdraw the prefix(es) by sending a Router 2995 Advertisement message on the access link with zero prefix lifetime 2996 for the prefix(es) that is being renumbered. Also, the local 2997 mobility anchor and the mobile access gateway MUST delete the created 2998 routing state for the renumbered prefix(es). However, the specific 2999 details on how the local mobility anchor notifies the mobile access 3000 gateway about the mobile node's home network prefix(es) renumbering 3001 are outside the scope of this document. 3003 6.13. Mobile Node Detachment Detection and Resource Cleanup 3005 Before sending a Proxy Binding Update message to the local mobility 3006 anchor for extending the lifetime of a currently existing binding of 3007 a mobile node, the mobile access gateway MUST make sure the mobile 3008 node is still attached to the connected link by using some reliable 3009 method. If the mobile access gateway cannot predictably detect the 3010 presence of the mobile node on the connected link, it MUST NOT 3011 attempt to extend the registration lifetime of the mobile node. 3012 Further, in such a scenario, the mobile access gateway SHOULD 3013 terminate the binding of the mobile node by sending a Proxy Binding 3014 Update message to the mobile node's local mobility anchor with 3015 lifetime value set to 0. It MUST also remove any local state such as 3016 the Binding Update List entry created for that mobile node. 3018 The specific detection mechanism of the loss of a visiting mobile 3019 node on the connected link is specific to the access link between the 3020 mobile node and the mobile access gateway and is outside the scope of 3021 this document. Typically, there are various link-layer specific 3022 events specific to each access technology that the mobile access 3023 gateway can depend on for detecting the node loss. In general, the 3024 mobile access gateway can depend on one or more of the following 3025 methods for the detection presence of the mobile node on the 3026 connected link: 3028 o Link-layer event specific to the access technology 3030 o Session termination event on point-to-point link types 3031 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 3033 o Notification event from the local mobility anchor 3035 6.14. Allowing network access to other IPv6 nodes 3037 In some Proxy Mobile IPv6 deployments, network operators may want to 3038 provision the mobile access gateway to offer network-based mobility 3039 management service only to some visiting mobile nodes and enable just 3040 regular IP access to some other nodes. This requires the network to 3041 have control on when to enable network-based mobility management 3042 service to a mobile node and when to enable regular IPv6 access. 3043 This specification does not disallow such configuration. 3045 Upon detecting a mobile node on its access link and after policy 3046 considerations, the mobile access gateway MUST determine if network- 3047 based mobility management service should be offered to that mobile 3048 node. If the mobile node is entitled for network-based mobility 3049 management service, then the mobile access gateway must ensure the 3050 mobile node does not detect any change with respect to its layer-3 3051 attachment, as explained in various sections of this specification. 3053 If the mobile node is not entitled for the network-based mobility 3054 management service, as determined from the policy considerations, the 3055 mobile access gateway MAY choose to offer regular IPv6 access to the 3056 mobile node and in such a scenario the normal IPv6 considerations 3057 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 3058 obtain IPv6 address(es) using the normal IPv6 address configuration 3059 procedures. The obtained address(es) must be from a local visitor 3060 network prefix(es). This essentially ensures that the mobile access 3061 gateway functions as a normal access router to a mobile node attached 3062 to its access link and without impacting its host-based mobility 3063 protocol operation. 3065 7. Mobile Node Operation 3067 This non-normative section explains the mobile node's operation in a 3068 Proxy Mobile IPv6 domain. 3070 7.1. Moving into a Proxy Mobile IPv6 Domain 3072 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 3073 an access network, the mobile access gateway on the access link 3074 detects the attachment of the mobile node and completes the binding 3075 registration with the mobile node's local mobility anchor. If the 3076 binding update operation is successfully performed, the mobile access 3077 gateway will create the required state and set up the forwarding for 3078 the mobile node's data traffic. 3080 When a mobile node attaches to the access link, it will typically 3081 send a Router Solicitation message [RFC-4861]. The mobile access 3082 gateway on the access link will respond to the Router Solicitation 3083 message with a Router Advertisement message. The Router 3084 Advertisement message will carry the mobile node's home network 3085 prefix(es), default-router address and other address configuration 3086 Parameters. 3088 If the mobile access gateway on the access link receives a Router 3089 Solicitation message from the mobile node, before it completes the 3090 signaling with the mobile node's local mobility anchor, the mobile 3091 access gateway may not know the mobile node's home network prefix(es) 3092 and may not be able to emulate the mobile node's home link on the 3093 access link. In such a scenario, the mobile node may notice a delay 3094 before it receives a Router Advertisement message. This will also 3095 affect mobile nodes that would be capable of handling their own 3096 mobility, or mobile nodes that do not need to maintain the same IP 3097 address through movements. 3099 If the received Router Advertisement message has the Managed Address 3100 Configuration flag set, the mobile node, as it would normally do, 3101 will send a DHCP Request [RFC-3315]. The DHCP relay service enabled 3102 on that access link will ensure the mobile node can obtain one or 3103 more addresses from its home network prefix(es). 3105 If the received Router Advertisement message does not have the 3106 Managed Address Configuration flag set and if the mobile node is 3107 allowed to use autoconfigured address(es), the mobile node will be 3108 able to obtain IPv6 address(es) and from each of its home network 3109 prefixes using any of the standard IPv6 address configuration 3110 mechanisms permitted for that mode. 3112 If the mobile node is IPv4 enabled and if the network permits, it 3113 will be able to obtain the IPv4 address configuration as specified in 3114 the companion document [ID-IPV4-PMIP6]. 3116 Once the address configuration is complete, the mobile node can 3117 continue to use this address configuration as long as it is attached 3118 to the network that is in the scope of that Proxy Mobile IPv6 domain. 3120 7.2. Roaming in the Proxy Mobile IPv6 Domain 3122 After obtaining the address configuration in the Proxy Mobile IPv6 3123 domain, as the mobile node moves and changes its point of attachment 3124 from one mobile access gateway to the other, it can still continue to 3125 use the same address configuration. As long as the attached access 3126 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 3127 node will always detect the same router advertising itself as a 3128 default-router and advertising the mobile node's home network 3129 prefix(es) on each connected link. If the mobile node has address 3130 configuration that it obtained using DHCP, it will be able to retain 3131 the address configuration and extend the lease lifetime. 3133 8. Message Formats 3135 This section defines extensions to the Mobile IPv6 [RFC-3775] 3136 protocol messages. 3138 8.1. Proxy Binding Update Message 3140 0 1 2 3 3141 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 3142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3143 | Sequence # | 3144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3145 |A|H|L|K|M|R|P| Reserved | Lifetime | 3146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3147 | | 3148 . . 3149 . Mobility options . 3150 . . 3152 | | 3153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 A Binding Update message that is sent by a mobile access gateway to a 3156 local mobility anchor is referred to as the "Proxy Binding Update" 3157 message. A new flag (P) is included in the Binding Update message. 3158 The rest of the Binding Update message format remains the same as 3159 defined in [RFC-3775] and with the additional (R) and (M) flags as 3160 specified in [RFC-3963] and [RFC-4140] respectively. 3162 Proxy Registration Flag (P) 3163 A new flag (P) is included in the Binding Update message to 3164 indicate to the local mobility anchor that the Binding Update 3165 message is a proxy registration. The flag MUST be set to the 3166 value of 1 for proxy registrations and MUST be set to 0 for direct 3167 registrations sent by a mobile node. 3169 Mobility Options 3171 Variable-length field of such length that the complete Mobility 3172 Header is an integer multiple of 8 octets long. This field 3173 contains zero or more TLV-encoded mobility options. The encoding 3174 and format of defined options are described in Section 6.2 of 3175 [RFC-3775]. The local mobility anchor MUST ignore and skip any 3176 options which it does not understand. 3178 As per this specification, the following mobility options are 3179 valid in a Proxy Binding Update message. These options can be 3180 present in the message in any order. There can be one or more 3181 instances of the Home Network Prefix options present in the 3182 message. However, there cannot be more than one instance of any 3183 of the other options. 3185 Mobile Node Identifier option 3187 Home Network Prefix option 3189 Handoff Indicator option 3191 Access Technology Type option 3193 Timestamp option 3195 Mobile Node Link-layer Identifier option 3197 Link-local Address option 3199 Additionally, there can one or more instances of the Vendor- 3200 Specific Mobility option [RFC-5094]. 3202 For descriptions of other fields present in this message, refer to 3203 section 6.1.7 of [RFC-3775]. 3205 8.2. Proxy Binding Acknowledgement Message 3207 0 1 2 3 3208 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 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | Status |K|R|P|Reserved | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | Sequence # | Lifetime | 3213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3214 | | 3215 . . 3216 . Mobility options . 3217 . . 3218 | | 3219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3221 A Binding Acknowledgement message that is sent by a local mobility 3222 anchor to a mobile access gateway is referred to as the "Proxy 3223 Binding Acknowledgement" message. A new flag (P) is included in the 3224 Binding Acknowledgement message. The rest of the Binding 3225 Acknowledgement message format remains the same as defined in [RFC- 3226 3775] and with the additional (R) flag as specified in [RFC-3963]. 3228 Proxy Registration Flag (P) 3230 A new flag (P) is included in the Binding Acknowledgement message 3231 to indicate that the local mobility anchor that processed the 3232 corresponding Proxy Binding Update message supports proxy 3233 registrations. The flag is set to value of 1 only if the 3234 corresponding Proxy Binding Update had the Proxy Registration Flag 3235 (P) set to value of 1. 3237 Mobility Options 3239 Variable-length field of such length that the complete Mobility 3240 Header is an integer multiple of 8 octets long. This field 3241 contains zero or more TLV-encoded mobility options. The encoding 3242 and format of defined options are described in Section 6.2 of 3243 [RFC-3775]. The mobile access gateway MUST ignore and skip any 3244 options which it does not understand. 3246 As per this specification, the following mobility options are 3247 valid in a Proxy Binding Acknowledgement message. These options 3248 can be present in the message in any order. There can be one or 3249 more instances of the Home Network Prefix options present in the 3250 message. However, there cannot be more than one instance of any 3251 of the other options. 3253 Mobile Node Identifier option 3255 Home Network Prefix option 3257 Handoff Indicator option 3259 Access Technology Type option 3261 Timestamp option 3263 Mobile Node Link-layer Identifier option 3265 Link-local Address option 3267 Additionally, there can one or more instances of the Vendor- 3268 Specific Mobility option [RFC-5094]. 3270 Status 3272 8-bit unsigned integer indicating the disposition of the Proxy 3273 Binding Update. Values of the Status field less than 128 indicate 3274 that the Proxy Binding Update was accepted by the local mobility 3275 anchor. Values greater than or equal to 128 indicate that the 3276 Proxy Binding Update message was rejected by the local mobility 3277 anchor. Section 8.9 defines the Status values that can used in 3278 Proxy Binding Acknowledgement message. 3280 For descriptions of other fields present in this message, refer to 3281 the section 6.1.8 of [RFC-3775]. 3283 8.3. Home Network Prefix Option 3285 A new option, Home Network Prefix Option is defined for use with the 3286 Proxy Binding Update and Proxy Binding Acknowledgement messages 3287 exchanged between a local mobility anchor and a mobile access 3288 gateway. This option is used for exchanging the mobile node's home 3289 network prefix information. There can be multiple Home Network 3290 Prefix options present in the message. 3292 The Home Network Prefix Option has an alignment requirement of 8n+4. 3293 Its format is as follows: 3295 0 1 2 3 3296 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 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 | Type | Length | Reserved | Prefix Length | 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 | | 3301 + + 3302 | | 3303 + Home Network Prefix + 3304 | | 3305 + + 3306 | | 3307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3309 Type 3310 3312 Length 3314 8-bit unsigned integer indicating the length of the option 3315 in octets, excluding the type and length fields. This field 3316 MUST be set to 18. 3318 Reserved (R) 3320 This 8-bit field is unused for now. The value MUST be 3321 initialized to 0 by the sender and MUST be ignored by the 3322 receiver. 3324 Prefix Length 3326 8-bit unsigned integer indicating the prefix length of the 3327 IPv6 prefix contained in the option. 3329 Home Network Prefix 3331 A sixteen-byte field containing the mobile node's IPv6 Home 3332 Network Prefix. 3334 8.4. Handoff Indicator Option 3336 A new option, Handoff Indicator Option is defined for use with the 3337 Proxy Binding Update and Proxy Binding Acknowledgement messages 3338 exchanged between a local mobility anchor and a mobile access 3339 gateway. This option is used for exchanging the mobile node's 3340 handoff related hints. 3342 The Handoff Indicator Option has no alignment requirement. Its 3343 format is as follows: 3345 0 1 2 3 3346 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 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 | Type | Length | Reserved (R) | HI | 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 Type 3352 3354 Length 3356 8-bit unsigned integer indicating the length of the option 3357 in octets, excluding the type and length fields. This field 3358 MUST be set to 2. 3360 Reserved (R) 3362 This 8-bit field is unused for now. The value MUST be 3363 initialized to 0 by the sender and MUST be ignored by the 3364 receiver. 3366 Handoff Indicator (HI) 3368 A 8-bit field that specifies the type of handoff. The values 3369 (0 - 255) will be allocated and managed by IANA. The following 3370 values are currently defined. 3372 0: Reserved 3373 1: Attachment over a new interface 3374 2: Handoff between two different interfaces of the mobile node 3375 3: Handoff between mobile access gateways for the same interface 3376 4: Handoff state unknown 3377 5: Handoff state not changed (Re-registration) 3379 8.5. Access Technology Type Option 3381 A new option, Access Technology Type Option is defined for use with 3382 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3383 exchanged between a local mobility anchor and a mobile access 3384 gateway. This option is used for exchanging the type of the access 3385 technology by which the mobile node is currently attached to the 3386 mobile access gateway. 3388 The Access Technology Type Option has no alignment requirement. Its 3389 format is as follows: 3391 0 1 2 3 3392 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 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3394 | Type | Length | Reserved (R) | ATT | 3395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3397 Type 3398 3400 Length 3402 8-bit unsigned integer indicating the length of the option 3403 in octets, excluding the type and length fields. This field 3404 MUST be set to 2. 3406 Reserved (R) 3408 This 8-bit field is unused for now. The value MUST be 3409 initialized to 0 by the sender and MUST be ignored by the 3410 receiver. 3412 Access Technology Type (ATT) 3414 A 8-bit field that specifies the access technology through 3415 which the mobile node is connected to the access link on the 3416 mobile access gateway. 3418 The values (0 - 255) will be allocated and managed by IANA. The 3419 following values are currently reserved for the below specified 3420 access technology types. 3422 0: Reserved ("Reserved") 3423 1: Virtual ("Logical Network Interface") 3424 2: PPP ("Point-to-Point Protocol") 3425 3: IEEE 802.3 ("Ethernet") 3426 4: IEEE 802.11a/b/g ("Wireless LAN") 3427 5: IEEE 802.16e ("WIMAX") 3429 8.6. Mobile Node Link-layer Identifier Option 3431 A new option, Mobile Node Link-layer Identifier Option is defined for 3432 use with the Proxy Binding Update and Proxy Binding Acknowledgement 3433 messages exchanged between a local mobility anchor and a mobile 3434 access gateway. This option is used for exchanging the mobile node's 3435 link-layer identifier. 3437 The format of the Link-layer Identifier option is shown below. Based 3438 on the size of the identifier, the option MUST be aligned 3439 appropriately, as per mobility option alignment requirements 3440 specified in [RFC-3775]. 3442 0 1 2 3 3443 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 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 | Type | Length | Reserved | 3446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3447 | | 3448 + Link-layer Identifier + 3449 . ... . 3450 | | 3451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3453 Type 3454 3456 Length 3457 8-bit unsigned integer indicating the length of the option 3458 in octets, excluding the type and length fields. 3460 Reserved 3462 This field is unused for now. The value MUST be initialized to 3463 0 by the sender and MUST be ignored by the receiver. 3465 Link-layer Identifier 3467 A variable length field containing the mobile node's link-layer 3468 identifier. 3470 The content and format of this field (including byte and bit 3471 ordering) is as specified in Section 4.6 of [RFC-4861] for 3472 carrying Link-Layer Address. On certain access links, where 3473 the link-layer address is not used or cannot be determined, 3474 this option cannot be used. 3476 8.7. Link-local Address Option 3478 A new option, Link-local Address Option is defined for use with the 3479 Proxy Binding Update and Proxy Binding Acknowledgement messages 3480 exchanged between a local mobility anchor and a mobile access 3481 gateway. This option is used for exchanging the link-local address 3482 of the mobile access gateway. 3484 The Link-local Address option has an alignment requirement of 8n+6. 3485 Its format is as follows: 3487 0 1 2 3 3488 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 3489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 | Type | Length | 3491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3492 | | 3493 + + 3494 | | 3495 + Link-local Address + 3496 | | 3497 + + 3498 | | 3499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3501 Type 3502 3504 Length 3506 8-bit unsigned integer indicating the length of the option 3507 in octets, excluding the type and length fields. This field 3508 MUST be set to 16. 3510 Link-local Address 3512 A sixteen-byte field containing the link-local address. 3514 8.8. Timestamp Option 3516 A new option, Timestamp Option is defined for use in the Proxy 3517 Binding Update and Proxy Binding Acknowledgement messages. 3519 The Timestamp option has an alignment requirement of 8n+2. Its 3520 format is as follows: 3522 0 1 2 3 3523 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 3524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3525 | Type | Length | 3526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3527 | | 3528 + Timestamp + 3529 | | 3530 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3532 Type 3533 3535 Length 3537 8-bit unsigned integer indicating the length in octets of 3538 the option, excluding the type and length fields. The value 3539 for this field MUST be set to 8. 3541 Timestamp 3543 A 64-bit unsigned integer field containing a timestamp. The value 3544 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3545 by using a fixed point format. In this format, the integer number 3546 of seconds is contained in the first 48 bits of the field, and the 3547 remaining 16 bits indicate the number of 1/65536 fractions of a 3548 second. 3550 8.9. Status Values 3552 This document defines the following new Status values for use in 3553 Proxy Binding Acknowledgement message. These values are to be 3554 allocated from the same number space, as defined in Section 6.1.8 of 3555 [RFC-3775]. 3557 Status values less than 128 indicate that the Proxy Binding Update 3558 message was accepted by the local mobility anchor. Status values 3559 greater than 128 indicate that the Proxy Binding Update was rejected 3560 by the local mobility anchor. 3562 PROXY_REG_NOT_ENABLED: IANA 3564 Proxy registration not enabled for the mobile node 3566 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3568 Not local mobility anchor for this mobile node 3570 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3572 The mobile access gateway is not authorized to send proxy binding 3573 updates 3575 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3577 The mobile node is not authorized for one or more of the 3578 requesting home network prefixes 3580 TIMESTAMP_MISMATCH: IANA 3582 Invalid timestamp value (the clocks are out of sync) 3584 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3586 The timestamp value is lower than the previously accepted value 3588 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3590 Missing home network prefix option 3592 BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA 3594 All the home network prefixes listed in the BCE do not match all 3595 the prefixes in the received PBU 3597 MISSING_MN_IDENTIFIER_OPTION: IANA 3599 Missing mobile node identifier option 3601 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3603 Missing handoff indicator option 3605 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3607 Missing access technology type option 3609 Additionally, the following Status values defined in [RFC-3775] can 3610 also be used in a Proxy Binding Acknowledgement message. 3612 0 Proxy Binding Update accepted 3614 128 Reason unspecified 3616 129 Administratively prohibited 3618 130 Insufficient resources 3620 9. Protocol Configuration Variables 3622 9.1. Local Mobility Anchor - Configuration Variables 3624 The local mobility anchor MUST allow the following variables to be 3625 configured by the system management. The configured values for these 3626 protocol variables MUST survive server reboots and service restarts. 3628 MinDelayBeforeBCEDelete 3630 This variable specifies the amount of time in milliseconds the 3631 local mobility anchor MUST wait before it deletes a Binding Cache 3632 entry of a mobile node, upon receiving a Proxy Binding Update 3633 message from a mobile access gateway with a lifetime value of 0. 3634 During this wait time, if the local mobility anchor receives a 3635 Proxy Binding Update for the same mobility binding, with lifetime 3636 value greater than 0, then it must update the binding cache entry 3637 with the accepted binding values. By the end of this wait-time, 3638 if the local mobility anchor did not receive any valid Proxy 3639 Binding Update message for that mobility binding, it MUST delete 3640 the Binding Cache entry. This delay essentially ensures a mobile 3641 node's Binding Cache entry is not deleted too quickly and allows 3642 some time for the new mobile access gateway to complete the 3643 signaling for the mobile node. 3645 The default value for this variable is 10000 milliseconds. 3647 MaxDelayBeforeNewBCEAssign 3649 This variable specifies the amount of time in milliseconds the 3650 local mobility anchor MUST wait for the de-registration message 3651 for an existing mobility session before it decides to create a new 3652 mobility session. 3654 The default value for this variable is 1500 milliseconds. 3656 Note that there is a dependency between this value and the values 3657 used in the retransmission algorithm for Proxy Binding Updates. 3658 The retransmissions need to happen before 3659 MaxDelayBeforeNewBCEAssign runs out, as otherwise there are 3660 situations where a de-registration from a previous mobile access 3661 gateway may be lost, and the local mobility anchor creates 3662 needlessly a new mobility session and new prefixes for the mobile 3663 node. This affects situations where there is no information from 3664 the lower layers about the type of a handoff or other parameters 3665 that can be used for identifying the mobility session, however. 3667 TimestampValidityWindow 3669 This variable specifies the maximum amount of time difference in 3670 milliseconds between the timestamp in the received Proxy Binding 3671 Update message and the current time-of-day on the local mobility 3672 anchor, that is allowed by the local mobility anchor for the 3673 received message to be considered valid. 3675 The default value for this variable is 300 milliseconds. This 3676 variable must be adjusted to suit the deployments. 3678 9.2. Mobile Access Gateway - Configuration Variables 3680 The mobile access gateway MUST allow the following variables to be 3681 configured by the system management. The configured values for these 3682 protocol variables MUST survive server reboots and service restarts. 3684 EnableMAGLocalRouting 3686 This flag indicates whether or not the mobile access gateway is 3687 allowed to enable local routing of the traffic exchanged between a 3688 visiting mobile node and a correspondent node that is locally 3689 connected to one of the interfaces of the mobile access gateway. 3690 The correspondent node can be another visiting mobile node as 3691 well, or a local fixed node. 3693 The default value for this flag is set to value of 0, indicating 3694 that the mobile access gateway MUST reverse tunnel all the traffic 3695 to the mobile node's local mobility anchor. 3697 When the value of this flag is set to value of 1, the mobile 3698 access gateway MUST route the traffic locally. 3700 This aspect of local routing MAY be defined as policy on a per 3701 mobile basis and when present will take precedence over this flag. 3703 9.3. Proxy Mobile IPv6 Domain - Configuration Variables 3705 All the mobile entities (local mobility anchors and mobile access 3706 gateways) in a Proxy Mobile IPv6 domain MUST allow the following 3707 variables to be configured by the system management. The configured 3708 values for these protocol variables MUST survive server reboots and 3709 service restarts. These variables MUST be globally fixed for a given 3710 Proxy Mobile IPv6 domain resulting in the same values being enforced 3711 on all the mobility entities in that domain. 3713 MobileNodeGeneratedTimestampInUse 3715 This flag indicates whether or not the mobile node generated 3716 timestamp mechanism is in use in that Proxy Mobile IPv6 domain. 3717 When the value for this flag is set to 1, the local mobility 3718 anchors and mobile access gateways in that Proxy Mobile IPv6 3719 domain MUST apply the mobile node generated timestamp 3720 considerations as specified in Section 5.5. 3722 The default value for this flag is set to value of 0, indicating 3723 that the mobile node generated timestamp mechanism is not in use 3724 in that Proxy Mobile IPv6 domain. 3726 FixedMAGLinkLocalAddressOnAllAccessLinks 3727 This variable indicates the link-local address value that all the 3728 mobile access gateways SHOULD use on any of the access links 3729 shared with any of the mobile nodes in that Proxy Mobile IPv6 3730 domain. If this variable is initialized to ALL_ZERO value, it 3731 implies the use of fixed link-local address mode is not enabled 3732 for that Proxy Mobile IPv6 domain. 3734 FixedMAGLinkLayerAddressOnAllAccessLinks 3736 This variable indicates the link-layer address value that all the 3737 mobile access gateways SHOULD use on any of the access links 3738 shared with any of the mobile nodes in that Proxy Mobile IPv6 3739 domain. For access technologies where there is no link-layer 3740 address, this variable MUST be initialized to ALL_ZERO value. 3742 10. IANA Considerations 3744 This document defines six new Mobility Header options, the Home 3745 Network Prefix option, Handoff Indicator option, Access Technology 3746 Type option, Mobile Node Link-layer Identifier option, Link-local 3747 Address option and Timestamp option. These options are described in 3748 Section 8. The Type value for these options needs to be assigned 3749 from the same numbering space as allocated for the other mobility 3750 options, as defined in [RFC-3775]. 3752 The Handoff Indicator option defined in Section 8.4 of this document 3753 introduces a new Handoff Indicator (HI) numbering space, where the 3754 values from 0 to 5 have been reserved by this document. Approval of 3755 new Handoff Indicator type values are to be made through IANA Expert 3756 Review. 3758 The Access Technology Type option defined in Section 8.5 of this 3759 document introduces a new Access Technology type (ATT) numbering 3760 space, where the values from 0 to 5 have been reserved by this 3761 document. Approval of new Access Technology type values are to be 3762 made through IANA Expert Review. 3764 This document also defines new Binding Acknowledgement status values 3765 as described in Section 8.9. The status values MUST be assigned from 3766 the same number space used for Binding Acknowledgement status values, 3767 as defined in [RFC-3775]. The allocated values for each of these 3768 status values must be greater than 128. 3770 11. Security Considerations 3772 The potential security threats against any network-based mobility 3773 management protocol are described in [RFC-4832]. This section 3774 explains how Proxy Mobile IPv6 protocol defends itself against those 3775 threats. 3777 Proxy Mobile IPv6 protocol recommends the signaling messages, Proxy 3778 Binding Update and Proxy Binding Acknowledgement, exchanged between 3779 the mobile access gateway and the local mobility anchor to be 3780 protected using IPsec, using the established security association 3781 between them. This essentially eliminates the threats related to the 3782 impersonation of the mobile access gateway or the local mobility 3783 anchor. 3785 This specification allows a mobile access gateway to send binding 3786 registration messages on behalf of a mobile node. If proper 3787 authorization checks are not in place, a malicious node may be able 3788 to hijack a mobile node's mobility session or may carry out a denial- 3789 of-service attack. To prevent this attack, this specification 3790 requires the local mobility anchor to allow only authorized mobile 3791 access gateways that are part of that Proxy Mobile IPv6 domain to 3792 send Proxy Binding Update messages on behalf of a mobile node. 3794 To eliminate the threats on the interface between the mobile access 3795 gateway and the mobile node, this specification requires an 3796 established trust between the mobile access gateway and the mobile 3797 node and to authenticate and authorize the mobile node before it is 3798 allowed to access the network. Further, the established 3799 authentication mechanisms enabled on that access link will ensure 3800 that there is a secure binding between the mobile node's identity and 3801 its link-layer address. The mobile access gateway will definitively 3802 identify the mobile node from the packets that it receives on that 3803 access link. 3805 To address the threat related to a compromised mobile access gateway, 3806 the local mobility anchor, before accepting a Proxy Binding Update 3807 message for a given mobile node, may ensure that the mobile node is 3808 attached to the mobile access gateway that sent the Proxy Binding 3809 Update message. This may be accomplished by contacting a trusted 3810 entity which is able to track the mobile node's current point of 3811 attachment. However, the specific details of the actual mechanisms 3812 for achieving this is outside the scope of this document. 3814 12. Acknowledgements 3816 The authors would like to specially thank Jari Arkko, Julien 3817 Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, 3818 Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their 3819 thorough review of this document. 3821 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3822 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Charlie Perkins, Fred 3823 Templin, Genadi Velev, George Tsirtsis, Gerardo Giaretta, Henrik 3824 Levkowetz, Hesham Soliman, James Kempf, Jean-Michel Combes, John 3825 Jason Brzozowski, Jun Awano, John Zhao, Jong-Hyouk Lee, Jonne 3826 Soininen, Jouni Korhonen, Kalin Getov, Kilian Weniger, Lars Eggert, 3827 Magnus Westerlund, Marco Liebsch, Mohamed Khalil, Nishida Katsutoshi, 3828 Pierrick Seite, Phil Roberts, Ralph Droms, Ryuji Wakikawa, Sangjin 3829 Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, Vidya Narayanan, 3830 Youn-Hee Han and many others for their passionate discussions in the 3831 working group mailing list on the topic of localized mobility 3832 management solutions. These discussions stimulated much of the 3833 thinking and shaped the draft to the current form and we acknowledge 3834 that ! 3836 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3837 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim 3838 Stammers, Bernie Volz and Josh Littlefield for their input on this 3839 document. 3841 13. References 3843 13.1. Normative References 3845 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3846 Requirement Levels", BCP 14, RFC 2119, March 1997. 3848 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3849 IPv6 Specification", RFC 2473, December 1998. 3851 [RFC-3168] Ramakrishnan, K., Floyd, S., and D. Black, "The Addition 3852 of Explicit Congestion Notification (ECN) to IP", RFC 3168, September 3853 2001. 3855 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3856 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3857 RFC 3315, July 2003. 3859 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3860 IPv6", RFC 3775, June 2004. 3862 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3863 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3864 January 2005. 3866 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3867 Network Access Identifier", RFC 4282, December 2005. 3869 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3870 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3871 November 2005. 3873 [RFC-4291] Hinden, R., Deering, S., "IP Version 6 Addressing 3874 Architecture", RFC 4291, February 2006. 3876 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3877 Internet Protocol", RFC 4301, December 2005. 3879 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3880 4303, December 2005. 3882 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3883 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3884 2007. 3886 13.2. Informative References 3888 [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3889 for IP version 6", RFC 1981, August 1996. 3891 [RFC-2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3892 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 3893 2000. 3895 [RFC-3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3896 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3898 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3899 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3900 2005. 3902 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3903 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3904 4140, August 2005. 3906 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3907 Protocol", RFC 4306, December 2005. 3909 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3910 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3912 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3913 "Chargeable User Identity", RFC 4372, January 2006. 3915 [RFC-4821] Mathis, M. and Heffner, J., "Packetization Layer Path MTU 3916 Discovery", RFC 4821, March 2007. 3918 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3919 G., Liebsch, M., "Problem Statement for Network-based Localized 3920 Mobility Management", September 2006. 3922 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3923 G., Liebsch, M., "Goals for Network-based Localized Mobility 3924 Management", October 2006. 3926 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3927 Localized Mobility Management", September 2006. 3929 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3930 Address Autoconfiguration", RFC 4862, September 2007. 3932 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3933 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3934 2007. 3936 [RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6 3937 Vendor Specific Option", RFC 5094, December 2007. 3939 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3940 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-03.txt, 3941 2008. 3943 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 3944 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. 3946 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3948 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3949 typically be identified by an identifier, MN-Identifier, and that 3950 identifier will have an associated policy profile that identifies the 3951 mobile node's home network prefix(es) on a per-interface basis, 3952 permitted address configuration modes, roaming policy and other 3953 parameters that are essential for providing network-based mobility 3954 management service. This information is typically configured in AAA. 3955 In some cases, the home network prefix(es) may be dynamically 3956 assigned to the mobile node's interface, after its initial attachment 3957 to the Proxy Mobile IPv6 domain over that interface and may not be 3958 configured in the mobile node's policy profile. 3960 The network entities in the proxy Mobile IPv6 domain, while serving a 3961 mobile node will have access to the mobile node's policy profile and 3962 these entities can query this information using RADIUS [RFC-2865] or 3963 DIAMETER [RFC-3588] protocols. 3965 Appendix B. Routing State 3967 The following section explains the routing state created for a mobile 3968 node on the mobile access gateway. This routing state reflects only 3969 one specific way of implementation and one MAY choose to implement it 3970 in other ways. The policy based route defined below acts as a 3971 traffic selection rule for routing a mobile node's traffic through a 3972 specific tunnel created between the mobile access gateway and that 3973 mobile node's local mobility anchor and with the specific 3974 encapsulation mode, as negotiated. 3976 The below example identifies the routing state for two visiting 3977 mobile nodes, MN1 and MN2 with their respective local mobility 3978 anchors LMA1 and LMA2. 3980 For all traffic from the mobile node, identified by the mobile node's 3981 MAC address, ingress interface or source prefix (MN-HNP) to 3982 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3984 +==================================================================+ 3985 | Packet Source | Destination Address | Destination Interface | 3986 +==================================================================+ 3987 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3988 | (IPv6 Prefix or |----------------------------------------------| 3989 | Input Interface) | Locally Connected | Tunnel0 | 3990 +------------------------------------------------------------------+ 3991 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3992 + (IPv6 Prefix or -----------------------------------------------| 3993 | Input Interface | Locally Connected | direct | 3994 +------------------------------------------------------------------+ 3996 Example - Policy based Route Table 3998 +==================================================================+ 3999 | Interface | Source Address | Destination Address | Encapsulation | 4000 +==================================================================+ 4001 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 4002 +------------------------------------------------------------------+ 4003 | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | 4004 +------------------------------------------------------------------+ 4006 Example - Tunnel Interface Table 4008 Authors' Addresses 4010 Sri Gundavelli 4011 Cisco 4012 170 West Tasman Drive 4013 San Jose, CA 95134 4014 USA 4016 Email: sgundave@cisco.com 4018 Kent Leung 4019 Cisco 4020 170 West Tasman Drive 4021 San Jose, CA 95134 4022 USA 4024 Email: kleung@cisco.com 4026 Vijay Devarapalli 4027 Wichorus 4028 3590 North First Street 4029 San Jose, CA 95134 4030 USA 4032 Email: vijay@wichorus.com 4033 Kuntal Chowdhury 4034 Starent Networks 4035 30 International Place 4036 Tewksbury, MA 4038 Email: kchowdhury@starentnetworks.com 4040 Basavaraj Patil 4041 Nokia Siemens Networks 4042 6000 Connection Drive 4043 Irving, TX 75039 4044 USA 4046 Email: basavaraj.patil@nsn.com 4048 Full Copyright Statement 4050 Copyright (C) The IETF Trust (2008). 4052 This document is subject to the rights, licenses and restrictions 4053 contained in BCP 78, and except as set forth therein, the authors 4054 retain all their rights. 4056 This document and the information contained herein are provided on an 4057 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4058 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 4059 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 4060 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 4061 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4062 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4064 Intellectual Property 4066 The IETF takes no position regarding the validity or scope of any 4067 Intellectual Property Rights or other rights that might be claimed to 4068 pertain to the implementation or use of the technology described in 4069 this document or the extent to which any license under such rights 4070 might or might not be available; nor does it represent that it has 4071 made any independent effort to identify any such rights. Information 4072 on the procedures with respect to rights in RFC documents can be 4073 found in BCP 78 and BCP 79. 4075 Copies of IPR disclosures made to the IETF Secretariat and any 4076 assurances of licenses to be made available, or the result of an 4077 attempt made to obtain a general license or permission for the use of 4078 such proprietary rights by implementers or users of this 4079 specification can be obtained from the IETF on-line IPR repository at 4080 http://www.ietf.org/ipr. 4082 The IETF invites any interested party to bring to its attention any 4083 copyrights, patents or patent applications, or other proprietary 4084 rights that may cover technology that may be required to implement 4085 this standard. Please address the information to the IETF at 4086 ietf-ipr@ietf.org. 4088 Acknowledgment 4090 Funding for the RFC Editor function is provided by the IETF 4091 Administrative Support Activity (IASA).