idnits 2.17.1 draft-ietf-netlmm-proxymip6-17.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 27, 2008) is 5813 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: November 28, 2008 V. Devarapalli 6 Wichorus 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 May 27, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-17.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on November 28, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 Network-based mobility management enables IP mobility for a host 48 without requiring its participation in any mobility related 49 signaling. The Network is responsible for managing IP mobility on 50 behalf of the host. The mobility entities in the network are 51 responsible for tracking the movements of the host and initiating the 52 required mobility signaling on its behalf. This specification 53 describes a network-based mobility management protocol and is 54 referred to as Proxy Mobile IPv6. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 60 2.1. Conventions used in this document . . . . . . . . . . . . 5 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 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 Binding Registrations . . . . . . . . . . . 20 71 5.3.2. Initial Binding Registration (New Mobility Session) . 22 72 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23 73 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24 74 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . . . . . 85 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 binding registration request message sent by a mobile access 354 gateway to a mobile node's local mobility anchor for establishing 355 a binding between the mobile node's home network prefix(es) 356 assigned to a given interface of a mobile node and its current 357 care-of address (Proxy-CoA). 359 Proxy Binding Acknowledgement (PBA) 361 A binding registration reply message sent by a local mobility 362 anchor in response to a Proxy Binding Update request message that 363 it received from a mobile access 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 prefixes(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 binding 631 update request was received and once it accepts the request will wait 632 for certain amount of time for allowing the mobile access gateway on 633 the new link to update the binding. However, if it does not receive 634 any binding update request 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 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 request. 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 request. 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 request. 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, using which the mobile node is 813 currently attached. This is obtained from the Access Technology 814 Type option, present in the Proxy Binding Update request. 816 o The 64-bit timestamp value of the most recently accepted Proxy 817 Binding Update request 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 request (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 Binding Registrations 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 request. 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 request. 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 request. If the Mobile Node 890 Identifier option is not present in the Proxy Binding Update 891 request, 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 requests 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 requests 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 registrations). 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 request, 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 request. 928 10. If there is no Home Network Prefix option(s) (with any value) 929 present in the Proxy Binding Update request, 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 request, 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 request, 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 request 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 request 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 request 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 request (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 request 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 request 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 session is handed off, the local mobility anchor MUST update the 1050 Binding Cache entry with the accepted registration values. 1052 2. The local mobility anchor MUST remove the previously created 1053 route(s) for the mobile node's home network prefix(es) associated 1054 with this mobility session. Additionally, if there are no other 1055 mobile node sessions sharing the dynamically created bi- 1056 directional tunnel to the previous mobile access gateway, the 1057 tunnel SHOULD be deleted applying considerations from section 1058 5.6.1 (if the tunnel is a dynamically created tunnel and not a 1059 fixed pre-established tunnel). 1061 3. If there is no existing bi-directional tunnel to the mobile 1062 access gateway that sent the request, the local mobility anchor 1063 MUST establish a bi-directional tunnel to that mobile access 1064 gateway. Considerations from Section 5.6.1 MUST be applied for 1065 managing the dynamically created bi-directional tunnel. 1067 4. The local mobility anchor MUST create prefix route(s) over the 1068 tunnel to the mobile access gateway for forwarding any traffic 1069 received for the mobile node's home network prefix(es) associated 1070 with that mobility session. The created tunnel and routing state 1071 MUST result in the forwarding behavior on the local mobility 1072 anchor as specified in Section 5.6.2. 1074 5. The local mobility anchor MUST send the Proxy Binding 1075 Acknowledgement message with the Status field set to 0 (Proxy 1076 Binding Update Accepted). The message MUST be constructed as 1077 specified in Section 5.3.6. 1079 5.3.5. Binding De-Registration 1081 1. If the received Proxy Binding Update request with the lifetime 1082 value of zero, has a Source Address in the IPv6 header (or the 1083 address in the Alternate Care-of Address option, if the option is 1084 present) different from what is present in the Proxy-CoA address 1085 field in the Binding Cache entry, the local mobility anchor MUST 1086 ignore the request. 1088 2. Upon accepting the Proxy Binding Update request with the lifetime 1089 value of zero, the local mobility anchor MUST wait for 1090 MinDelayBeforeBCEDelete amount of time, before it deletes the 1091 Binding Cache entry. However, it MUST send the Proxy Binding 1092 Acknowledgement message with the Status field set to 0 (Proxy 1093 Binding Update Accepted). The message MUST be constructed as 1094 specified in Section 5.3.6. 1096 * During this wait period, the local mobility anchor SHOULD drop 1097 the mobile node's data traffic. 1099 * During this wait period, if the local mobility anchor receives 1100 a valid Proxy Binding Update request for the same mobility 1101 session with the lifetime value of greater than zero, and if 1102 that request is accepted, then the Binding Cache entry MUST 1103 NOT be deleted, but must be updated with the newly accepted 1104 registration values and additionally the wait period should be 1105 ended. 1107 * By the end of this wait period, if the local mobility anchor 1108 did not receive any valid Proxy Binding Update request for 1109 this mobility session, then it MUST delete the Binding Cache 1110 entry and remove the routing state created for that mobility 1111 session. The local mobility anchor can potentially reassign 1112 the prefix(es) associated with this mobility session to other 1113 mobile nodes. 1115 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1117 o The local mobility anchor when sending the Proxy Binding 1118 Acknowledgement message to the mobile access gateway MUST 1119 construct the message as specified below. 1121 IPv6 header (src=LMAA, dst=Proxy-CoA) 1122 Mobility header 1123 - BA /* P flag must be set to value of 1 */ 1124 Mobility Options 1125 - Mobile Node Identifier Option (mandatory) 1126 - Home Network Prefix option(s) (mandatory) 1127 - Handoff Indicator option (mandatory) 1128 - Access Technology Type option (mandatory) 1129 - Timestamp Option (optional) 1130 - Mobile Node Link-layer Identifier option (optional) 1131 - Link-local Address option (optional) 1133 Figure 6: Proxy Binding Acknowledgement message format 1135 o The Source Address field in the IPv6 header of the message MUST be 1136 set to the destination address of the received Proxy Binding 1137 Update request. 1139 o The Destination Address field in the IPv6 header of the message 1140 MUST be set to the source address of the received Proxy Binding 1141 Update request. When there is no Alternate Care-of Address option 1142 present in the request, the destination address is the same as the 1143 Proxy-CoA address, otherwise, the address may not be the same as 1144 the Proxy-CoA. 1146 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1147 identifier field in the option MUST be copied from the Mobile Node 1148 Identifier option in the received Proxy Binding Update request. 1149 If the option was not present in the request, the identifier in 1150 the option MUST be set to a zero length identifier. 1152 o At least one Home Network Prefix option MUST be present. 1154 * If the Status field is set to a value greater than or equal to 1155 128, i.e., if the binding request is rejected, all the Home 1156 Network Prefix options that were present in the request (along 1157 with their prefix values) MUST be present in the reply. But, 1158 if there was no Home Network Prefix option present in the 1159 request, then there MUST be only one Home Network Prefix option 1160 and with the value in the option set to ALL_ZERO. 1162 * For all other cases, there MUST be a Home Network Prefix option 1163 for each of the assigned home network prefixes (for that 1164 mobility session) and with the prefix value in the option set 1165 to the allocated prefix value. 1167 o The Handoff Indicator option MUST be present. The handoff 1168 indicator field in the option MUST be copied from the Handoff 1169 Indicator option in the received Proxy Binding Update request. If 1170 the option was not present in the request, the value in the option 1171 MUST be set to zero. 1173 o The Access Technology Type option MUST be present. The access 1174 technology type field in the option MUST be copied from the Access 1175 Technology Type option in the received Proxy Binding Update 1176 request. If the option was not present in the request, the value 1177 in the option MUST be set to zero. 1179 o The Timestamp option MUST be present only if the same option was 1180 present in the received Proxy Binding Update request and MUST NOT 1181 be present otherwise. Considerations from Section 5.5 must be 1182 applied for constructing the Timestamp option. 1184 o The Mobile Node Link-layer Identifier option MUST be present only 1185 if the same option was present in the received Proxy Binding 1186 Update request and MUST NOT be present otherwise. The link-layer 1187 identifier value MUST be copied from the Mobile Node Link-layer 1188 Identifier option present in the received Proxy Binding Update 1189 request. 1191 o The Link-local Address option MUST be present only if the same 1192 option was present in the received Proxy Binding Update request 1193 and MUST NOT be present otherwise. If the Status field in the 1194 reply is set to a value greater than or equal to 128, i.e., if the 1195 binding request is rejected, then the link-local address from the 1196 request MUST be copied to the Link-local Address option in the 1197 reply, otherwise the following considerations apply. 1199 * If the received Proxy Binding Update request has the Link-local 1200 Address option with ALL_ZERO value and if there is an existing 1201 Binding Cache entry associated with this request, then the 1202 link-local address from the Binding Cache entry MUST be copied 1203 to the Link-local Address option in the reply. 1205 * If the received Proxy Binding Update request has the Link-local 1206 Address option with ALL_ZERO value and if there is no existing 1207 Binding Cache entry associated with this request, then the 1208 local mobility anchor MUST generate the link-local address that 1209 the mobile access gateway can use on the point-to-point link 1210 shared with the mobile node. This generated address MUST be 1211 copied to the Link-local Address option in the reply. The same 1212 address MUST also be copied to the link-local address field of 1213 Binding Cache entry created for this mobility session. 1215 * If the received Proxy Binding Update request has the Link-local 1216 Address option with NON_ZERO value, then the link-local address 1217 from the request MUST be copied to the Link-local Address 1218 option in the reply. The same address MUST also be copied to 1219 the link-local address field of the Binding Cache entry 1220 associated with this request (after creating the Binding Cache 1221 entry, if there does not exist one). 1223 o If IPsec is used for protecting the signaling messages, the 1224 message MUST be protected, using the security association existing 1225 between the local mobility anchor and the mobile access gateway. 1227 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1228 NOT be present in the IPv6 header of the packet. 1230 5.4. Multihoming Support 1232 This specification allows mobile nodes to connect to a Proxy Mobile 1233 IPv6 domain through multiple interfaces for simultaneous access. 1234 Following are the key aspects of this multihoming support. 1236 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1237 multiple interfaces for simultaneous access, the local mobility 1238 anchor MUST allocate a mobility session for each of the attached 1239 interfaces. Each mobility session should be managed under a 1240 separate Binding Cache entry and with its own lifetime. 1242 o The local mobility anchor MAY allocate more than one home network 1243 prefix for a given interface of the mobile node. However, all the 1244 prefixes associated with a given interface MUST be managed as part 1245 of one mobility session, associated with that interface. 1247 o The local mobility anchor MUST allow for an handoff between two 1248 different interfaces of a mobile node. In such a scenario, all 1249 the home network prefix(es) associated with one interface (part of 1250 one mobility session) will be associated with a different 1251 interface of the mobile node). The decision on when to create a 1252 new mobility session and when to update an existing mobility 1253 session MUST be based on the Handover hint present in the Proxy 1254 Binding Update message and under the considerations specified in 1255 this section 5.4. 1257 5.4.1. Binding Cache entry lookup considerations 1259 There can be multiple Binding Cache entries for a given mobile node. 1260 When doing a lookup for a mobile node's Binding Cache entry for 1261 processing a received Proxy Binding Update request message, the local 1262 mobility anchor MUST apply the following multihoming considerations 1263 (in the below specified order, starting with Section 5.4.1.1). These 1264 rules are chained with the processing rules specified in Section 5.3. 1266 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1267 request 1269 +=====================================================================+ 1270 | Registration/De-Registration Message | 1271 +=====================================================================+ 1272 | At least one HNP Option with NON_ZERO Value | 1273 +=====================================================================+ 1274 | ATT | 1275 +=====================================================================+ 1276 | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | 1277 +=====================================================================+ 1278 | HI | 1279 +==================================+==================================+ 1280 | BCE Lookup Key: Any of the Home Network Prefixes from the request | 1281 +=====================================================================+ 1283 Figure 7: BCE lookup using home network prefix 1285 If there is at least one Home Network Prefix option present in the 1286 request with a NON_ZERO prefix value and irrespective of the presence 1287 of the Mobile Node Link-layer Identifier option in the request, the 1288 following considerations MUST be applied. If there are more than one 1289 instances of the Home Network Prefix option, any one of the Home 1290 Network Prefix options present in the request (with NON_ZERO prefix 1291 value) can be used for locating the Binding Cache entry. 1293 1. The local mobility anchor MUST verify if there is an existing 1294 Binding Cache entry with one of its home network prefixes 1295 matching the prefix value in one of the Home Network Prefix 1296 options of the received Proxy Binding Update request. 1298 2. If there does not exist a Binding Cache entry (with one of its 1299 home network prefixes in the Binding Cache entry matching the 1300 prefix value in one of the Home Network Prefix options of the 1301 received Proxy Binding Update request), the request MUST be 1302 considered as a request for creating a new mobility session. 1304 3. If there exists a Binding Cache entry (with one of its home 1305 network prefixes in the Binding Cache entry matching the prefix 1306 value in one of the Home Network Prefix options of the received 1307 Proxy Binding Update request) but if the mobile node identifier 1308 in the entry does not match the mobile node identifier in the 1309 Mobile Node Identifier option of the received Proxy Binding 1310 Update request, the local mobility anchor MUST reject the request 1311 with the Status field value set to 1312 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1313 authorized for one or more of the requesting home network 1314 prefixes). 1316 4. If there exists a Binding Cache entry (matching MN-Identifier and 1317 one of its home network prefixes in the Binding Cache entry 1318 matching the prefix value in one of the Home Network Prefix 1319 options of the received Proxy Binding Update request), but if all 1320 the prefixes in the request do not match all the prefixes in the 1321 Binding Cache entry, or if they do not match in count, then the 1322 local mobility anchor MUST reject the request with the Status 1323 field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home 1324 network prefixes listed in the BCE do not match all the prefixes 1325 in the received PBU). 1327 5. If there exists a Binding Cache entry (matching MN-Identifier and 1328 all the home network prefixes in the Binding Cache entry matching 1329 all the home network prefixes in the received Proxy Binding 1330 Update request) and if any one or more of these below stated 1331 conditions match, the request MUST be considered as a request for 1332 updating that Binding Cache entry. 1334 * If the Handoff Indicator field in the Handoff Indicator option 1335 present in the request is set to a value of 2 (Handoff between 1336 two different interfaces of the mobile node). 1338 * If there is no Mobile Node Link-layer Identifier option 1339 present in the request, the link-layer identifier value in the 1340 Binding Cache entry is set to ALL_ZERO, the access technology 1341 type field in the Access Technology Type option present in the 1342 request matches the access technology type in the Binding 1343 Cache entry and if the Handoff Indicator field in the Handoff 1344 Indicator option present in the request is set to a value of 3 1345 (Handoff between mobile access gateways for the same 1346 interface). 1348 * If the Proxy-CoA address in the Binding Cache entry matches 1349 the source address of the request (or the address in the 1350 alternate Care-of Address option, if the option is present) 1351 and if the access technology type field in the Access 1352 Technology Type option present in the request matches the 1353 access technology type in the Binding Cache entry. 1355 6. For all other cases, the message MUST be considered as a request 1356 for creating a new mobility session. However, if the received 1357 Proxy Binding Update request has the lifetime value of zero and 1358 if the request cannot be associated with any existing mobility 1359 session, the message MUST be silently ignored. 1361 5.4.1.2. Mobile Node Link-layer Identifier Option present in the 1362 request 1364 +=====================================================================+ 1365 | Registration/De-Registration Message | 1366 +=====================================================================+ 1367 | No HNP option with a NON_ZERO Value | 1368 +=====================================================================+ 1369 | ATT | 1370 +=====================================================================+ 1371 | MN-LL-Identifier Option Present (NON_ZERO Value) | 1372 +=====================================================================+ 1373 | HI | 1374 +==================================+==================================+ 1375 | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | 1376 +=====================================================================+ 1378 Figure 8: BCE Lookup using Link-layer Identifier 1380 If there is no Home Network Prefix option present in the request with 1381 a NON_ZERO prefix value, but if there is a Mobile Node Link-layer 1382 Identifier option present in the request then the following 1383 considerations MUST be applied for locating the Binding Cache entry. 1385 1. The local mobility anchor MUST verify if there is an existing 1386 Binding Cache entry, with the mobile node identifier matching the 1387 identifier in the received Mobile Node Identifier option, access 1388 technology type matching the value in the received Access 1389 Technology Type option and the link-layer identifier value 1390 matching the identifier in the received Mobile Node Link-layer 1391 Identifier option. 1393 2. If there exists a Binding Cache entry (matching MN-Identifier, 1394 ATT and MN-LL-Identifier), the request MUST be considered as a 1395 request for updating that Binding Cache entry. 1397 3. If there does not exist a Binding Cache entry (matching MN- 1398 Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator 1399 field in the Handoff Indicator option present in the request is 1400 set to a value of 2 (Handoff between two different interfaces of 1401 the mobile node). The local mobility anchor MUST apply the 1402 following additional considerations. 1404 * The local mobility anchor MUST verify if there exists one and 1405 only one Binding Cache entry with the mobile node identifier 1406 matching the identifier in the Mobile Node Identifier option 1407 present in the request and for any link-layer identifier 1408 value. If there exists only one such entry (matching the MN- 1409 Identifier), the request MUST be considered as a request for 1410 updating that Binding Cache entry. 1412 4. If there does not exist a Binding Cache entry (matching MN- 1413 Identifier, ATT and MN-LL-Identifier) and if the Handoff 1414 Indicator field in the Handoff Indicator option present in the 1415 request is set to a value of 4 (Handoff state unknown), the local 1416 mobility anchor MUST apply the following additional 1417 considerations. 1419 * The local mobility anchor MUST verify if there exists one and 1420 only one Binding Cache entry with the mobile node identifier 1421 matching the identifier in the Mobile Node Identifier option 1422 present in the request and for any link-layer identifier 1423 value. If there exists only one such entry (matching the MN- 1424 Identifier), the local mobility anchor SHOULD wait till the 1425 existing Binding Cache entry is de-registered by the 1426 previously serving mobile access gateway, before the request 1427 can be considered as a request for updating that Binding Cache 1428 entry. However, if there is no de-registration message that 1429 is received within MaxDelayBeforeNewBCEAssign amount of time, 1430 the local mobility anchor upon accepting the request MUST 1431 consider the request as a request for creating a new mobility 1432 session. The local mobility anchor MAY also choose to create 1433 a new mobility session and without waiting for a de- 1434 registration message and this should be configurable on the 1435 local mobility anchor. 1437 5. For all other cases, the message MUST be considered as a request 1438 for creating a new mobility session. However, if the received 1439 Proxy Binding Update request has the lifetime value of zero and 1440 if the request cannot be associated with any existing mobility 1441 session, the message MUST be silently ignored. 1443 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 1444 request 1446 +=====================================================================+ 1447 | Registration/De-Registration Message | 1448 +=====================================================================+ 1449 | No HNP option with a NON_ZERO Value | 1450 +=====================================================================+ 1451 | ATT | 1452 +=====================================================================+ 1453 | MN-LL-Identifier Option Not Present | 1454 +=====================================================================+ 1455 | HI | 1456 +==================================+==================================+ 1457 | BCE Lookup Key: (MN-Identifier) | 1458 +=====================================================================+ 1460 Figure 9: BCE Lookup using Mobile Node Identifier 1462 If there is no Home Network Prefix option present in the request with 1463 a NON_ZERO prefix value and if there is also no Mobile Node Link- 1464 layer Identifier option present in the request then the following 1465 considerations MUST be applied for locating the Binding Cache entry. 1467 1. The local mobility anchor MUST verify if there exists one and 1468 only one Binding Cache entry with the mobile node identifier 1469 matching the identifier in the Mobile Node Identifier option 1470 present in the request. 1472 2. If there exists only one such entry (matching the MN-Identifier) 1473 and the Handoff Indicator field in the Handoff Indicator option 1474 present in the request is set to a value of 2 (Handoff between 1475 two different interfaces of the mobile node) or set to a value of 1476 3 (Handoff between mobile access gateways for the same 1477 interface), then the request MUST be considered as a request for 1478 updating that Binding Cache entry. 1480 3. If there exists only one such entry (matching the MN-Identifier) 1481 and the Handoff Indicator field in the Handoff Indicator option 1482 present in the request is set to a value of 4 (Handoff state 1483 unknown), the local mobility anchor SHOULD wait till the existing 1484 Binding Cache entry is de-registered by the previously serving 1485 mobile access gateway, before the request can be considered as a 1486 request for updating that Binding Cache entry. However, if there 1487 is no de-registration message that is received within 1488 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1489 anchor upon accepting the request MUST consider the request as a 1490 request for creating a new mobility session. The local mobility 1491 anchor MAY also choose to create a new mobility session and 1492 without waiting for a de-registration message and this should be 1493 configurable on the local mobility anchor. 1495 4. For all other cases, the message MUST be considered as a request 1496 for creating a new mobility session. However, if the received 1497 Proxy Binding Update request has the lifetime value of zero and 1498 if the request cannot be associated with any existing mobility 1499 session, the message MUST be silently ignored. 1501 5.5. Timestamp Option for Message Ordering 1503 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1504 registration messages as a way for the home agent to process the 1505 binding updates in the order they were sent by a mobile node. The 1506 home agent and the mobile node are required to manage this counter 1507 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1508 the mobile node moves from one mobile access gateway to another and 1509 in the absence of mechanisms such as context transfer between the 1510 mobile access gateways, the serving mobile access gateway will be 1511 unable to determine the sequence number that it needs to use in the 1512 signaling messages. Hence, the sequence number scheme, as specified 1513 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1515 If the local mobility anchor cannot determine the sending order of 1516 the received binding registration messages, it may potentially 1517 process an older message sent by a mobile access gateway where the 1518 mobile node was previously anchored, but delivered out of order, 1519 resulting in incorrectly updating the mobile node's Binding Cache 1520 entry and creating a routing state for tunneling the mobile node's 1521 traffic to the previous mobile access gateway. 1523 For solving this problem, this specification adopts two alternative 1524 solutions. One is based on timestamps and the other based on 1525 sequence numbers, as defined in [RFC-3775]. 1527 The basic principle behind the use of timestamps in binding 1528 registration messages is that the node generating the message inserts 1529 the current time-of-day, and the node receiving the message checks 1530 that this timestamp is greater than all previously accepted 1531 timestamps. The timestamp based solution may be used when the 1532 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1533 have the ability to obtain the last sequence number that was sent in 1534 a binding registration message for updating a given mobile node's 1535 binding. 1537 If the mechanism used for clock synchronization in the Proxy Mobile 1538 IPv6 domain cannot assure a clock drift between the two mobile access 1539 gateways (between which the mobile node did a handoff), which is not 1540 less than half the total time it took for the mobile node to roam 1541 between the two mobile access gateways and the time it took for the 1542 serving mobile access gateway to detect the node on its access link 1543 and construct the Proxy Binding Update message, then this solution 1544 will not predictably work in all cases and hence SHOULD NOT be used. 1546 As an alternative to the Timestamp based approach, the specification 1547 also allows the use of Sequence Number based scheme, as specified in 1548 [RFC-3775]. However, for this scheme to work, the serving mobile 1549 access gateway in a Proxy Mobile IPv6 domain MUST have the ability to 1550 obtain the last sequence number that was sent in a binding 1551 registration message. The sequence number MUST be maintained on a 1552 per mobile node basis and MUST be available to the serving mobile 1553 access gateway. This may be achieved by using context transfer 1554 schemes or by maintaining the sequence number in a policy store. 1555 However, the specific details on how the mobile node's sequence 1556 number is made available to the serving mobile access gateway prior 1557 to sending the binding registration messages is outside the scope of 1558 this document." 1560 Using the Timestamps based approach: 1562 1. A local mobility anchor implementation MUST support the Timestamp 1563 option. If the Timestamp option is present in the received Proxy 1564 Binding Update request message, then the local mobility anchor 1565 MUST include a valid Timestamp option in the Proxy Binding 1566 Acknowledgement message that it sends to the mobile access 1567 gateway. 1569 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1570 exchanging binding registration messages using the Timestamp 1571 option MUST have adequately synchronized time-of-day clocks. 1572 This is the essential requirement for this solution to work. If 1573 this requirement is not met, the solution will not predictably 1574 work in all cases. 1576 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1577 synchronize their clocks to a common time source. For 1578 synchronizing the clocks, the nodes MAY use the Network Time 1579 Protocol [RFC-4330]. Deployments MAY also adopt other approaches 1580 suitable for that specific deployment. Alternatively, if there 1581 is mobile node generated timestamp that is increasing at every 1582 attachment to the access link and if that timestamp is available 1583 to the mobile access gateway (Ex: The timestamp option in the 1584 SEND messages that the mobile node sends), the mobile access 1585 gateway can use this timestamp or sequence number in the Proxy 1586 Binding Update messages and does not have to depend on any 1587 external clock source. However, the specific details on how this 1588 is achieved is outside the scope of this document. 1590 4. When generating the timestamp value for building the Timestamp 1591 option, the mobility entities MUST ensure that the generated 1592 timestamp is the elapsed time past the same reference epoch, as 1593 specified in the format for the Timestamp option (Section 8.8). 1595 5. If the Timestamp option is present in the received Proxy Binding 1596 Update message, the local mobility anchor MUST ignore the 1597 sequence number field in the message. However, it MUST copy the 1598 sequence number from the received Proxy Binding Update message to 1599 the Proxy Binding Acknowledgement message. 1601 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1602 option, the local mobility anchor MUST check the timestamp field 1603 for validity. In order for it to be considered valid, the 1604 following MUST be true. 1606 * The timestamp value contained in the Timestamp option MUST be 1607 close enough (within TimestampValidityWindow amount of time 1608 difference) to the local mobility anchor's time-of-day clock. 1609 However, if the flag MobileNodeGeneratedTimestampInUse is set 1610 to value of 1, the local mobility anchor MUST ignore this 1611 check and perform only the following check. 1613 * The timestamp MUST be greater than all previously accepted 1614 timestamps in the Proxy Binding Update messages sent for that 1615 mobile node. 1617 7. If the timestamp value in the received Proxy Binding Update is 1618 valid (validity as specified in the above considerations) or if 1619 the flag MobileNodeGeneratedTimestampInUse is set to value of 1, 1620 the local mobility anchor MUST return the same timestamp value in 1621 the Timestamp option included in the Proxy Binding 1622 Acknowledgement message that it sends to the mobile access 1623 gateway. 1625 8. If the timestamp value in the received Proxy Binding Update is 1626 lower than the previously accepted timestamp in the Proxy Binding 1627 Update messages sent for that mobility binding, the local 1628 mobility anchor MUST reject the Proxy Binding Update request and 1629 send a Proxy Binding Acknowledgement message with Status field 1630 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1631 previously accepted timestamp). The message MUST also include 1632 the Timestamp option with the value set to the current time-of- 1633 day on the local mobility anchor. 1635 9. If the timestamp value in the received Proxy Binding Update is 1636 not valid (validity as specified in the above considerations), 1637 the local mobility anchor MUST reject the Proxy Binding Update 1638 and send a Proxy Binding Acknowledgement message with Status 1639 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1640 message MUST also include the Timestamp option with the value set 1641 to the current time-of-day on the local mobility anchor. 1643 Using the Sequence Number based approach: 1645 1. If the Timestamp option is not present in the received Proxy 1646 Binding Update request, the local mobility anchor MUST fall back 1647 to the Sequence Number based scheme. It MUST process the 1648 sequence number field as specified in [RFC-3775]. Also, it MUST 1649 NOT include the Timestamp option in the Proxy Binding 1650 Acknowledgement messages that it sends to the mobile access 1651 gateway. 1653 2. An implementation MUST support the Sequence Number based scheme, 1654 as specified in [RFC-3775]. 1656 3. The Sequence Number based approach can be used only when there is 1657 some mechanism (such as context transfer procedure between mobile 1658 access gateways) that allows the serving mobile access gateway to 1659 obtain the last sequence number that was sent in a binding 1660 registration message for updating a given mobile node's binding. 1662 5.6. Routing Considerations 1664 5.6.1. Bi-Directional Tunnel Management 1666 The bi-directional tunnel MUST be used for routing the mobile node's 1667 data traffic between the mobile access gateway and the local mobility 1668 anchor. A tunnel hides the topology and enables a mobile node to use 1669 address(es) from its home network prefix(es) from any access link in 1670 that Proxy Mobile IPv6 domain. A tunnel may be created dynamically 1671 when needed and removed when not needed. However, implementations 1672 MAY choose to use static pre-established tunnels instead of 1673 dynamically creating and tearing them down on a need basis. The 1674 following considerations MUST be applied when using dynamic tunnels. 1676 o A bi-directional tunnel MUST be established between the local 1677 mobility anchor and the mobile access gateway with IPv6-in-IPv6 1678 encapsulation, as described in [RFC-2473]. The tunnel end points 1679 are the Proxy-CoA and LMAA. However, when using IPv4 transport, 1680 the end points of the tunnel are IPv4-LMAA and IPv4-Proxy-CoA with 1681 the encapsulation mode as specified in [ID-IPV4-PMIP6]. 1683 o Implementations MAY use a software timer for managing the tunnel 1684 lifetime and a counter for keeping a count of all the mobile nodes 1685 that are sharing the tunnel. The timer value can be set to the 1686 accepted binding lifetime and can be updated after each periodic 1687 re-registration for extending the lifetime. If the tunnel is 1688 shared for multiple mobile nodes, the tunnel lifetime must be set 1689 to the highest binding lifetime that is granted to any one of 1690 those mobile nodes sharing that tunnel. 1692 o The tunnel SHOULD be deleted when either the tunnel lifetime 1693 expires or when there are no mobile nodes sharing the tunnel. 1695 5.6.2. Forwarding Considerations 1697 Intercepting Packets Sent to the Mobile Node's Home Network: 1699 o When the local mobility anchor is serving a mobile node, it MUST 1700 be able to receive packets that are sent to the mobile node's home 1701 network. In order for it to receive those packets, it MUST 1702 advertise a connected route in to the Routing Infrastructure for 1703 the mobile node's home network prefix(es) or for an aggregated 1704 prefix with a larger scope. This essentially enables IPv6 routers 1705 in that network to detect the local mobility anchor as the last- 1706 hop router for the mobile node's home network prefix(es). 1708 Forwarding Packets to the Mobile Node: 1710 o On receiving a packet from a correspondent node with the 1711 destination address matching a mobile node's home network 1712 prefix(es), the local mobility anchor MUST forward the packet 1713 through the bi-directional tunnel set up for that mobile node. 1715 o The format of the tunneled packet is shown below. Considerations 1716 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 1717 when using IPv4 transport, the format of the packet is as 1718 described in [ID-IPV4-PMIP6]. 1720 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1721 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1722 Upper layer protocols /* Packet Content*/ 1724 Figure 10: Tunneled Packet from LMA to MAG 1726 o The format of the tunneled packet is shown below, when payload 1727 protection using IPsec is enabled for the mobile node's data 1728 traffic. However, when using IPv4 transport, the format of the 1729 packet is as described in [ID-IPV4-PMIP6]. 1731 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1732 ESP Header in tunnel mode /* ESP Header */ 1733 IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */ 1734 Upper layer protocols /* Packet Content*/ 1736 Figure 11: Tunneled Packet from LMA to MAG with Payload Protection 1738 Forwarding Packets Sent by the Mobile Node: 1740 o All the reverse tunneled packets that the local mobility anchor 1741 received from the mobile access gateway, after removing the tunnel 1742 header MUST be routed to the destination specified in the inner 1743 packet header. These routed packets will have the source address 1744 field set to the mobile node's home address. Considerations from 1745 [RFC-2473] MUST be applied for IPv6 decapsulation. 1747 5.6.3. ECN Considerations for Proxy Mobile IPv6 Tunnels 1749 This section describes how the ECN information needs to be handled by 1750 the mobility agents at the tunnel entry and exit points. The ECN 1751 considerations for IP tunnels are specified in [RFC-3168] and the 1752 same considerations apply to Proxy Mobile IPv6 tunnels (using IPv6- 1753 in-IPv6 encapsulation mode). Specifically the full-functionality 1754 option MUST be supported. The relevant ECN considerations from [RFC- 1755 3168] are summarized here for convenience. 1757 Encapsulation Considerations: 1759 o If the Explicit Congestion Notification (ECN) field in the inner 1760 header is set to ECT(0) or ECT(1), where ECT stands for ECN- 1761 Capable Transport (ECT), the ECN field from the inner header MUST 1762 be copied to the outer header. Additionally, when payload 1763 protection using IPsec is enabled for the mobile node's data 1764 traffic, the ECN considerations from [RFC-4301] MUST be applied. 1766 Decapsulation Considerations: 1768 o If the Explicit Congestion Notification (ECN) field in the inner 1769 header is set to ECT(0) or ECT(1), and if the ECN field in the 1770 outer header is set to Congestion Experienced (CE), then the ECN 1771 field in the inner header MUST be set to CE. Otherwise, the ECN 1772 field in the inner header MUST NOT be modified. Additionally, 1773 when payload protection using IPsec is enabled for the mobile 1774 node's data traffic, the ECN considerations from [RFC-4301] MUST 1775 be applied. 1777 5.7. Local Mobility Anchor Address Discovery 1779 Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 1780 10.5 of [RFC-3775], allows a mobile node to discover all the home 1781 agents on its home link by sending an ICMP Home Agent Address 1782 Discovery Request message to the Mobile IPv6 Home-Agents anycast 1783 address, derived from its home network prefix. 1785 The DHAAD message in the current form cannot be used in Proxy Mobile 1786 IPv6 for discovering the address of the mobile node's local mobility 1787 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1788 able to receive any messages sent to the Mobile IPv6 Home-Agents 1789 anycast address corresponding to the mobile node's home network 1790 prefix(es), as the prefix(es) is not hosted on any of its interfaces. 1791 Further, the mobile access gateway will not predictably be able to 1792 locate the serving local mobility anchor that has the mobile node's 1793 binding cache entry. Hence, this specification does not support 1794 Dynamic Home Agent Address Discovery protocol. 1796 In Proxy Mobile IPv6, the address of the local mobility anchor 1797 configured to serve a mobile node can be discovered by the mobility 1798 entities in other ways. This may be a configured entry in the mobile 1799 node's policy profile, or it may be obtained through mechanisms 1800 outside the scope of this document. 1802 5.8. Mobile Prefix Discovery Considerations 1804 This specification does not support mobile prefix discovery. The 1805 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1806 applicable to Proxy Mobile IPv6. 1808 5.9. Route Optimization Considerations 1810 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1811 enables a mobile node to communicate with a correspondent node 1812 directly using its care-of address and further the Return Routability 1813 procedure enables the correspondent node to have reasonable trust 1814 that the mobile node is reachable at both its home address and 1815 care-of address. 1817 This specification does not support the Route Optimization as 1818 specified in Mobile IPv6 [RFC-3775]. However, this specification 1819 does support some other form of route optimization as specified in 1820 Section 6.10.3. 1822 6. Mobile Access Gateway Operation 1824 The Proxy Mobile IPv6 protocol described in this document introduces 1825 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1826 access gateway is the entity that is responsible for detecting the 1827 mobile node's movements to and from the access link and sending the 1828 binding registration requests to the local mobility anchor. In 1829 essence, the mobile access gateway performs mobility management on 1830 behalf of a mobile node. 1832 The mobile access gateway is a function that typically runs on an 1833 access router. However, implementations MAY choose to split this 1834 function and run it across multiple systems. The specifics on how 1835 that is achieved or the signaling interactions between those 1836 functional entities are beyond the scope of this document. 1838 The mobile access gateway has the following key functional roles: 1840 o It is responsible for detecting the mobile node's movements on the 1841 access link and for initiating the mobility signaling with the 1842 mobile node's local mobility anchor. 1844 o Emulation of the mobile node's home link on the access link by 1845 sending Router Advertisement messages containing the mobile node's 1846 home network prefix(es), each prefix carried using the Prefix 1847 Information option [RFC-4861]. 1849 o Responsible for setting up the forwarding for enabling the mobile 1850 node to configure one or more addresses from its home network 1851 prefix(es) and use it from the attached access link. 1853 6.1. Extensions to Binding Update List Entry Data Structure 1855 Every mobile access gateway MUST maintain a Binding Update List. 1856 Each entry in the Binding Update List represents a mobile node's 1857 mobility binding with its local mobility anchor. The Binding Update 1858 List is a conceptual data structure, described in Section 11.1 of 1859 [RFC-3775]. 1861 For supporting this specification, the conceptual Binding Update List 1862 entry data structure needs be extended with the following additional 1863 fields. 1865 o The Identifier of the attached mobile node, MN-Identifier. This 1866 identifier is acquired during the mobile node's attachment to the 1867 access link through mechanisms outside the scope of this document. 1869 o The link-layer identifier of the mobile node's connected 1870 interface. This can be acquired from the received Router 1871 Solicitation messages from the mobile node or during the mobile 1872 node's attachment to the access network. This is typically a 1873 link-layer identifier conveyed by the mobile node; however, the 1874 specific details on how that is conveyed is out of scope for this 1875 specification. If this identifier is not available, this variable 1876 length field MUST be set to two (octets) and MUST be initialized 1877 to a value of ALL_ZERO. 1879 o List of IPv6 home network prefixes assigned to the mobile node's 1880 connected interface. The home network prefix(es) may have been 1881 statically configured in the mobile node's policy profile, or, may 1882 have been dynamically allocated by the local mobility anchor. 1883 Each of these prefix entries will also includes the corresponding 1884 prefix length. 1886 o The Link-local address of the mobile access gateway on the access 1887 link shared with the mobile node. 1889 o The IPv6 address of the local mobility anchor serving the attached 1890 mobile node. This address is acquired from the mobile node's 1891 policy profile or from other means. 1893 o The interface identifier (if-id) of the point-to-point link 1894 between the mobile node and the mobile access gateway. This is 1895 internal to the mobile access gateway and is used to associate the 1896 Proxy Mobile IPv6 tunnel to the access link where the mobile node 1897 is attached. 1899 o The tunnel interface identifier (tunnel-if-id) of the bi- 1900 directional tunnel between the mobile node's local mobility anchor 1901 and the mobile access gateway. This is internal to the mobile 1902 access gateway. The tunnel interface identifier is acquired 1903 during the tunnel creation. 1905 6.2. Mobile Node's Policy Profile 1907 A mobile node's policy profile contains the essential operational 1908 parameters that are required by the network entities for managing the 1909 mobile node's mobility service. These policy profiles are stored in 1910 a local or a remote policy store. The mobile access gateway and the 1911 local mobility anchor MUST be able to obtain a mobile node's policy 1912 profile. The policy profile MAY also be handed over to a serving 1913 mobile access gateway as part of a context transfer procedure during 1914 a handoff or the serving mobile access gateway MAY be able to 1915 dynamically generate this profile. The exact details on how this 1916 achieved is outside the scope of this document. However, this 1917 specification requires that a mobile access gateway serving a mobile 1918 node MUST have access to its policy profile. 1920 The following are the mandatory fields of the policy profile: 1922 o The mobile node's identifier (MN-Identifier) 1924 o The IPv6 address of the local mobility anchor (LMAA) 1926 The following are the optional fields of the policy profile: 1928 o The mobile node's IPv6 home network prefix(es) assigned to the 1929 mobile node's connected interface. These prefix(es) have to be 1930 maintained on a per-interface basis. There can be multiple of 1931 these entries one for each interface of the mobile node. The 1932 specific details on how the network maintains this association 1933 between the prefix set and the interfaces, specially during the 1934 mobility session handoff between interfaces is outside the scope 1935 of this document. 1937 o The mobile node's IPv6 home network Prefix lifetime. This 1938 lifetime will be same for all the hosted prefixes on the link, as 1939 they all are part of one mobility session. This value can also be 1940 same for all the mobile node's mobility sessions. 1942 o Supported address configuration procedures (Stateful, Stateless or 1943 both) for the mobile node in the Proxy Mobile IPv6 domain 1945 6.3. Supported Access Link Types 1947 This specification supports only point-to-point access link types and 1948 thus it assumes that the mobile node and the mobile access gateway 1949 are the only two nodes on the access link. The link is assumed to 1950 have multicast capability. 1952 This protocol may also be used on other link types, as long as the 1953 link is configured in such a way that it emulates point-to-point 1954 delivery between the mobile node and the mobile access gateway for 1955 all the protocol traffic. 1957 It is also necessary to be able to identify mobile nodes attaching to 1958 the link. Requirements relating to this are covered in Section 6.6. 1960 Finally, while this specification can operate without link layer 1961 indications of node attachment and detachment to the link, the 1962 existence of such indications either on the network or mobile node 1963 side improves the resulting performance. 1965 6.4. Supported Address Configuration Modes 1967 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1968 more global IPv6 addresses on its interface (using Stateless, 1969 Stateful or manual address autoconfiguration procedures) from the 1970 hosted prefix(es) on that link. The Router Advertisement messages 1971 sent on the access link specify the address configuration methods 1972 permitted on that access link for that mobile node. However, the 1973 advertised flags with respect to the address configuration will be 1974 consistent for a mobile node, on any of the access links in that 1975 Proxy Mobile IPv6 domain. Typically, these configuration settings 1976 will be based on the domain wide policy or based on a policy specific 1977 to each mobile node. 1979 When stateless address autoconfiguration is supported on the access 1980 link, the mobile node can generate one or more IPv6 addresses from 1981 the hosted prefix(es) by standard IPv6 mechanisms such as Stateless 1982 Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. 1984 When stateful address autoconfiguration is supported on the link, the 1985 mobile node can obtain the address configuration from the DHCP server 1986 located in the Proxy Mobile IPv6 domain, by standard DHCP mechanisms, 1987 as specified in [RFC-3315]. The obtained address(es) will be from 1988 its home network prefix(es). Section 6.11 specifies the details on 1989 how this configuration can be achieved. 1991 Additionally, other address configuration mechanisms specific to the 1992 access link between the mobile node and the mobile access gateway may 1993 also be used for delivering the address configuration to the mobile 1994 node. This specification does not modify the behavior of any of the 1995 standard IPv6 address configuration mechanisms. 1997 6.5. Access Authentication & Mobile Node Identification 1999 When a mobile node attaches to an access link connected to the mobile 2000 access gateway, the deployed access security protocols on that link 2001 SHOULD ensure that the network-based mobility management service is 2002 offered only after authenticating and authorizing the mobile node for 2003 that service. The exact specifics on how this is achieved or the 2004 interactions between the mobile access gateway and the access 2005 security service is outside the scope of this document. This 2006 specification goes with the stated assumption of having an 2007 established trust between the mobile node and the mobile access 2008 gateway, before the protocol operation begins. 2010 6.6. Acquiring Mobile Node's Identifier 2012 All the network entities in a Proxy Mobile IPv6 domain MUST be able 2013 to identify a mobile node, using its MN-Identifier. This identifier 2014 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 2015 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 2016 this identifier in the signaling messages and unambiguously identify 2017 a given mobile node. Following are some of the considerations 2018 related to this MN-Identifier. 2020 o The MN-Identifier is typically obtained as part of the access 2021 authentication or from a notified network attachment event. In 2022 cases where the user identifier authenticated during access 2023 authentication uniquely identifies a mobile node, the MN- 2024 Identifier MAY be the same as the user identifier. However, the 2025 user identifier MUST NOT be used if it identifies a user account 2026 that can be used from more than one mobile node operating in the 2027 same Proxy Mobile IPv6 domain. 2029 o In some cases, the obtained identifier as part of the access 2030 authentication can be a temporary identifier and further that 2031 temporary identifier may be different at each re-authentication. 2032 However, the mobile access gateway MUST be able to use this 2033 temporary identifier and obtain the mobile node's stable 2034 identifier from the policy store. For instance, in AAA-based 2035 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 2036 4372] may be used, as long as it uniquely identifies a mobile 2037 node, and not a user account that can be used with multiple mobile 2038 nodes. 2040 o In some cases and for privacy reasons, the MN-Identifier that the 2041 policy store delivers to the mobile access gateway may not be the 2042 true identifier of the mobile node. However, the mobility access 2043 gateway MUST be able to use this identifier in the signaling 2044 messages exchanged with the local mobility anchor. 2046 o The mobile access gateway MUST be able to identify the mobile node 2047 by its MN-Identifier and it MUST be able to associate this 2048 identity to the point-to-point link shared with the mobile node. 2050 6.7. Home Network Emulation 2052 One of the key functions of a mobile access gateway is to emulate the 2053 mobile node's home network on the access link. It must ensure, the 2054 mobile node does not detect any change with respect to its layer-3 2055 attachment even after it changes its point of attachment in that 2056 Proxy Mobile IPv6 domain. 2058 For emulating the mobile node's home link on the access link, the 2059 mobile access gateway must be able to send Router Advertisement 2060 messages advertising the mobile node's home network prefix(es) 2061 carried using the Prefix Information option(s) [RFC-4861] and with 2062 other address configuration parameters consistent with its home link 2063 properties. Typically, these configuration settings will be based on 2064 the domain wide policy or based on a policy specific to each mobile 2065 node. 2067 Typically, the mobile access gateway learns the mobile node's home 2068 network prefix(es) details from the received Proxy Binding 2069 Acknowledgement message or it may obtain them from the mobile node's 2070 policy profile. However, the mobile access gateway SHOULD send the 2071 Router Advertisements advertising the mobile node's home network 2072 prefix(es) only after successfully completing the binding 2073 registration with the mobile node's local mobility anchor. 2075 When advertising the home network prefix(es) in the Router 2076 Advertisement messages, the mobile access gateway MAY set the prefix 2077 lifetime value for the advertised prefix(es) to any chosen value at 2078 its own discretion. An implementation MAY choose to tie the prefix 2079 lifetime to the mobile node's binding lifetime. The prefix lifetime 2080 can also be an optional configuration parameter in the mobile node's 2081 policy profile. 2083 6.8. Link-Local and Global Address Uniqueness 2085 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 2086 mobile access gateway to the other, will continue to detect its home 2087 network and does not detect a change of layer-3 attachment. Every 2088 time the mobile node attaches to a new link, the event related to the 2089 interface state change will trigger the mobile node to perform DAD 2090 operation on the link-local and global address(es). However, if the 2091 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 2092 detect the link change due to DNAv6 optimizations and may not trigger 2093 the duplicate address detection (DAD) procedure for its existing 2094 addresses, which may potentially lead to address collisions after the 2095 mobile node's handoff to a new link. 2097 The issue of address collision is not relevant to the mobile node's 2098 global address(es). Since the assigned home network prefix(es) are 2099 for the mobile node's exclusive usage, no other node shares an 2100 address (other than Subnet-Router anycast address which is configured 2101 by the mobile access gateway) from the prefix(es) and so the 2102 uniqueness for the mobile node's global address is assured on the 2103 access link. 2105 The issue of address collision is however relevant to the mobile 2106 node's link-local addresses since the mobile access gateway and the 2107 mobile node will have link-local addresses configured from the same 2108 link-local prefix (FE80::/64). This leaves a room for link-local 2109 address collision between the two neighbors (i.e., the mobile node 2110 and the mobile access gateway) on that access link. For solving this 2111 problem, this specification requires that the link-local address that 2112 the mobile access gateway configures on the point-to-point link 2113 shared with a given mobile node be generated by the local mobility 2114 anchor and be stored in the mobile node's Binding Cache entry. This 2115 address will not change for the duration of that mobile node's 2116 session and can be provided to the serving mobile access gateway at 2117 every mobile node's handoff, as part of the Proxy Mobile IPv6 2118 signaling messages. The specific method by which the local mobility 2119 anchor generates the link-local address is out of scope for this 2120 specification. 2122 It is highly desirable that the access link on the mobile access 2123 gateway shared with the mobile node be provisioned in such a way that 2124 before the mobile node completes the DAD operation [RFC-4862] on its 2125 link-local address, the mobile access gateway on that link is aware 2126 of its own link-local address provided by the local mobility anchor 2127 that it needs to use on that access link. This essentially requires 2128 a successful completion of the Proxy Mobile IPv6 signaling by the 2129 mobile access gateway before the mobile node completes the DAD 2130 operation. This can be achieved by ensuring that link layer 2131 attachment does not complete until the Proxy Mobile IPv6 signaling is 2132 completed. Alternatively, network and local mobility anchor capacity 2133 and signaling retransmission timers can be provisioned in such a way 2134 that signaling is extremely likely to complete during the default 2135 waiting period associated with the DAD process. 2137 Optionally, implementations MAY choose to configure a fixed link- 2138 local address across all the access links in a Proxy Mobile IPv6 2139 domain and without a need for carrying this address from the local 2140 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 2141 signaling messages. The configuration variable 2142 FixedMAGLinkLocalAddressOnAllAccessLinks determines the enabled mode 2143 in that Proxy Mobile IPv6 domain. 2145 6.9. Signaling Considerations 2147 6.9.1. Binding Registrations 2149 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 2151 1. After detecting a new mobile node on its access link, the mobile 2152 access gateway MUST identify the mobile node and acquire its MN- 2153 Identifier. If it determines that the network-based mobility 2154 management service needs to be offered to the mobile node, it 2155 MUST send a Proxy Binding Update message to the local mobility 2156 anchor. 2158 2. The Proxy Binding Update message MUST include the Mobile Node 2159 Identifier option [RFC-4283], carrying the MN-Identifier for 2160 identifying the mobile node. 2162 3. The Home Network Prefix option(s) MUST be present in the Proxy 2163 Binding Update message. If the mobile access gateway learns the 2164 mobile node's home network prefix(es) either from its policy 2165 store or from other means, the mobile access gateway MAY choose 2166 to request the local mobility anchor to allocate the requested 2167 prefix(es) by including a Home Network Prefix option for each of 2168 those requested prefixes. The mobile access gateway MAY also 2169 choose to include just one Home Network Prefix option with the 2170 prefix value of ALL_ZERO, for requesting the local mobility 2171 anchor to do the prefix assignment. However, when including a 2172 Home Network Prefix option with the prefix value of ALL_ZERO, 2173 then there MUST be only one instance of the Home Network prefix 2174 option in the request. 2176 4. The Handoff Indicator option MUST be present in the Proxy 2177 Binding Update message. The Handoff Indicator field in the 2178 Handoff Indicator option MUST be set to a value indicating the 2179 handoff hint. 2181 * The Handoff Indicator field MUST be set to value 1 2182 (Attachment over a new interface), if the mobile access 2183 gateway determines (under the Handoff Indicator 2184 considerations specified in this section) that the mobile 2185 node's current attachment to the network over this interface 2186 is not as a result of a handoff of an existing mobility 2187 session (over the same interface or through a different 2188 interface), but as a result of an attachment over a new 2189 interface. This essentially serves as a request to the local 2190 mobility anchor to create a new mobility session and not 2191 update any existing Binding Cache entry created for the same 2192 mobile node connected to the Proxy Mobile IPv6 domain through 2193 a different interface. 2195 * The Handoff Indicator field MUST be set to value 2 (Handoff 2196 between two different interfaces of the mobile node), if the 2197 mobile access gateway definitively knows the mobile node's 2198 current attachment is due to a handoff of an existing 2199 mobility session, between two different interfaces of the 2200 mobile node. 2202 * The Handoff Indicator field MUST be set to value 3 (Handoff 2203 between mobile access gateways for the same interface), if 2204 the mobile access gateway definitively knows the mobile 2205 node's current attachment is due to a handoff of an existing 2206 mobility session between two mobile access gateways and for 2207 the same interface of the mobile node. 2209 * The Handoff Indicator field MUST be set to value 4 (Handoff 2210 state unknown), if the mobile access gateway cannot determine 2211 if the mobile node's current attachment is due to a handoff 2212 of an existing mobility session. 2214 5. The mobile access gateway MUST apply the below considerations 2215 when choosing the value for the Handoff Indicator field. 2217 * The mobile access gateway can choose to use the value 2 2218 (Handoff between two different interfaces of the mobile 2219 node), only when it knows that the mobile node has on purpose 2220 switched from one interface to another, and the previous 2221 interface is going to be disabled. It may know this due to a 2222 number of factors. For instance, most cellular networks have 2223 controlled handovers where the network knows that the host is 2224 moving from one attachment to another. In this situation the 2225 link layer mechanism can inform the mobility functions that 2226 this is indeed a movement, not a new attachment. 2228 * Some link layers have link-layer identifiers that can be used 2229 to distinguish (a) the movement of a particular interface to 2230 a new attachment from (b) the attachment of a new interface 2231 from the same host. Option value 3 (Handoff between mobile 2232 access gateways for the same interface)is appropriate in case 2233 a and value of 1 (Attachment over a new interface) in case b. 2235 * The mobile access gateway MUST NOT set the option value to 2 2236 (Handoff between two different interfaces of the mobile node) 2237 or 3 (Handoff between mobile access gateways for the same 2238 interface) if it can not be determined that the mobile node 2239 can move the address between the interfaces involved in the 2240 handover or that it is the same interface that has moved. 2241 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2242 physical interfaces to the same domain may suffer unexpected 2243 failures. 2245 * Where no support from the link layer exists, the host and the 2246 network would need to inform each other about the intended 2247 movement. The Proxy Mobile IPv6 protocol does not specify 2248 this and simply requires that knowledge about movements can 2249 be derived either from the link-layer or from somewhere else. 2250 The method by which this is accomplished is outside the scope 2251 of this specification. 2253 6. Either the Timestamp option or a valid sequence number 2254 maintained on a per mobile node basis (if the Sequence Number 2255 based scheme is in use) MUST be present. When Timestamp option 2256 is added to the message, the mobile access gateway SHOULD also 2257 set the Sequence Number field to a value of a monotonically 2258 increasing counter (not to be confused with the per mobile node 2259 sequence number specified in [RFC-3775]). The local mobility 2260 anchor will ignore this field when there is a Timestamp option 2261 present in the request, but will return the same value in the 2262 Proxy Binding Acknowledgement message. This will be useful for 2263 matching the reply to the request message. 2265 7. The Mobile Node Link-layer Identifier option carrying the link- 2266 layer identifier of the currently attached interface MUST be 2267 present in the Proxy Binding Update message, if the mobile 2268 access gateway is aware of the same. If the link-layer 2269 identifier of the currently attached interface is not known or 2270 if the identifier value is ALL_ZERO, this option MUST NOT be 2271 present. 2273 8. The Access Technology Type option MUST be present in the Proxy 2274 Binding Update message. The access technology type field in the 2275 option SHOULD be set to the type of access technology using 2276 which the mobile node is currently attached to the mobile access 2277 gateway. 2279 9. The Link-local Address option MUST be present in the Proxy 2280 Binding Update request only if the value of the configuration 2281 variable FixedMAGLinkLocalAddressOnAllAccessLinks is set to a 2282 value of ALL_ZERO, otherwise the Link-local Address option MUST 2283 NOT be present in the request. Considerations from Section 6.8 2284 MUST be applied when using the Link-local Address option. 2286 * For querying the local mobility anchor to provide the link- 2287 local address that it should use on the point-to-point link 2288 shared with the mobile node, this option MUST be set to 2289 ALL_ZERO value. This essentially serves as a request to the 2290 local mobility anchor to provide the link-local address that 2291 it can use on the access link shared with the mobile node. 2293 10. The Proxy Binding Update message MUST be constructed as 2294 specified in Section 6.9.1.5. 2296 11. If there is no existing Binding Update List entry for that 2297 mobile node, the mobile access gateway MUST create a Binding 2298 Update List entry for the mobile node upon sending the Proxy 2299 Binding Update request. 2301 6.9.1.2. Receiving Binding Registration Reply 2303 On receiving a Proxy Binding Acknowledgement message (format 2304 specified in Section 8.2) from the local mobility anchor, the mobile 2305 access gateway MUST process the message as specified below. 2307 1. The received Proxy Binding Acknowledgement message (a Binding 2308 Acknowledgement message with the 'P' flag set to value of 1) 2309 MUST be authenticated as described in Section 4. When IPsec is 2310 used for message authentication, the SPI in the IPsec header 2311 [RFC-4306] of the received packet is needed for locating the 2312 security association, for authenticating the Proxy Binding 2313 Acknowledgement message. 2315 2. The mobile access gateway MUST observe the rules described in 2316 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2317 the received Proxy Binding Acknowledgement message. 2319 3. The mobile access gateway MUST apply the considerations 2320 specified in Section 5.5 for processing the Sequence Number 2321 field and the Timestamp option (if present), in the message. 2323 4. The mobile access gateway MUST ignore any checks, specified in 2324 [RFC-3775] related to the presence of a Type 2 Routing header in 2325 the Proxy Binding Acknowledgement message. 2327 5. The mobile access gateway MAY use the mobile node identifier 2328 present in the Mobile Node Identifier option for matching the 2329 response to the request messages that it sent recently. 2330 However, if there is more than one request message in its 2331 request queue for the same mobile node, the sequence number 2332 field can be used for identifying the exact message from those 2333 messages. There are other ways to achieve this and 2334 implementations are free to adopt the best approach that suits 2335 their implementation. Additionally, if the received Proxy 2336 Binding Acknowledgement message does not match any of the Proxy 2337 Binding Update messages that it sent recently, the message MUST 2338 be ignored. 2340 6. If the received Proxy Binding Acknowledgement message has any 2341 one or more of the following options, Handoff Indicator option, 2342 Access Technology Type option, Mobile Node Link-layer Identifier 2343 option, Mobile Node Identifier option, carrying option values 2344 that are different from the option values present in the 2345 corresponding request (Proxy Binding Update) message, the 2346 message MUST be ignored as the local mobility anchor is expected 2347 to echo back all these listed options and with the same option 2348 values in the reply message. Further, the mobile access gateway 2349 MUST NOT retransmit the Proxy Binding Update message till an 2350 administrative action is taken. 2352 7. If the received Proxy Binding Acknowledgement message has the 2353 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2354 registration not enabled for the mobile node), the mobile access 2355 gateway SHOULD NOT send binding registration requests again for 2356 that mobile node. It MUST deny the mobility service to that 2357 mobile node. 2359 8. If the received Proxy Binding Acknowledgement message has the 2360 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2361 (Timestamp value lower than previously accepted value), the 2362 mobile access gateway SHOULD try to register again to reassert 2363 the mobile node's presence on its access link. The mobile 2364 access gateway is not specifically required to synchronize its 2365 clock upon receiving this error code. 2367 9. If the received Proxy Binding Acknowledgement message has the 2368 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2369 value), the mobile access gateway SHOULD try to register again 2370 only after it has synchronized its clock to a common time source 2371 that is used by all the mobility entities in that domain for 2372 their clock synchronization. The mobile access gateway SHOULD 2373 NOT synchronize its clock to the local mobility anchor's system 2374 clock, based on the timestamp present in the received message. 2376 10. If the received Proxy Binding Acknowledgement message has the 2377 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2378 (The mobile node is not authorized for one or more of the 2379 requesting home network prefix(es)), the mobile access gateway 2380 SHOULD NOT request for the same prefix(es) again, but can only 2381 request the local mobility anchor to do the assignment of 2382 prefix(es) by including only one Home Network Prefix option with 2383 the prefix value set to ALL_ZERO. 2385 11. If the received Proxy Binding Acknowledgement message has the 2386 Status field value set to any value greater than or equal to 128 2387 (i.e., if the binding is rejected), the mobile access gateway 2388 MUST NOT advertise the mobile node's home network prefix(es) in 2389 the Router Advertisement messages sent on that access link and 2390 MUST deny the mobility service to the mobile node by not 2391 forwarding any packets received from the mobile node using an 2392 address from the home network prefix(es). It MAY also tear down 2393 the point-to-point link shared with the mobile node. 2395 12. If the received Proxy Binding Acknowledgement message has the 2396 Status field value set to 0 (Proxy Binding Update accepted), the 2397 mobile access gateway MUST establish a bi-directional tunnel to 2398 the local mobility anchor (if there is no existing bi- 2399 directional tunnel to that local mobility anchor). 2400 Considerations from Section 5.6.1 MUST be applied for managing 2401 the dynamically created bi-directional tunnel. 2403 13. The mobile access gateway MUST set up the route for forwarding 2404 the packets received from the mobile node using address(es) from 2405 its home network prefix(es) through the bi-directional set up 2406 for that mobile node. The created tunnel and the routing state 2407 MUST result in the forwarding behavior on the mobile access 2408 gateway as specified in Section 6.10.5. 2410 14. The mobile access gateway MUST also update the Binding Update 2411 List entry for reflecting the accepted binding registration 2412 values. It MUST also advertise the mobile node's home network 2413 prefix(es) as the hosted on-link prefixes, by including them in 2414 the Router Advertisement messages that it sends on that access 2415 link. 2417 15. If the received Proxy Binding Acknowledgement message has the 2418 address in the Link-local Address option set to a NON_ZERO 2419 value, the mobile access gateway SHOULD configure that link- 2420 local address on that point-to-point link and SHOULD NOT 2421 configure any other link-local address without performing a DAD 2422 operation [RFC-4862]. This will avoid any potential link-local 2423 address collisions on that access link. However, if the link- 2424 local address generated by the local mobility anchor happens to 2425 be already in use by the mobile node on that link, the mobile 2426 access gateway MUST NOT use that address, but SHOULD configure a 2427 different link-local address. It SHOULD also upload this link- 2428 local address to the local mobility anchor by immediately 2429 sending a Proxy Binding Update request and by including this 2430 address in the Link-local Address option. 2432 6.9.1.3. Extending Binding Lifetime 2434 1. For extending the lifetime of a currently registered mobile node 2435 (i.e., after a successful initial binding registration from the 2436 same mobile access gateway), the mobile access gateway can send a 2437 Proxy Binding Update message to the local mobility anchor with a 2438 new lifetime value. This re-registration message MUST be 2439 constructed with the same set of options as the initial binding 2440 registration message, under the considerations specified in 2441 Section 6.9.1.1. However the following exceptions apply. 2443 2. There MUST be a Home Network Prefix option for each of the 2444 assigned home network prefixes assigned for that mobility session 2445 and with the prefix value in the option set to that respective 2446 prefix value. 2448 3. The Handoff Indicator field in the Handoff Indicator option MUST 2449 be set to a value of 5 (Handoff state not changed - Re- 2450 Registration). 2452 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2454 1. If at any point the mobile access gateway detects that the mobile 2455 node has moved away from its access link, or if it decides to 2456 terminate the mobile node's mobility session, it SHOULD send a 2457 Proxy Binding Update message to the local mobility anchor with 2458 the lifetime value set to zero. This de-registration message 2459 MUST be constructed with the same set of options as the initial 2460 binding registration message, under the considerations specified 2461 in Section 6.9.1.1. However, the following exceptions apply. 2463 2. There MUST be a Home Network Prefix option for each of the 2464 assigned home network prefix(es) assigned for that mobility 2465 session and with the prefix value in the option set to the 2466 respective prefix value. 2468 3. The Handoff Indicator field in the Handoff Indicator option MUST 2469 be set to a value of 4 (Handoff state unknown). 2471 Either upon receipt of a Proxy Binding Acknowledgement message from 2472 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2473 timeout waiting for the reply, the mobile access gateway MUST do the 2474 following: 2476 1. It MUST remove the Binding Update List entry for the mobile node 2477 from its Binding Update List. 2479 2. It MUST remove the created routing state for tunneling the mobile 2480 node's traffic. 2482 3. If there is a dynamically created tunnel to the mobile node's 2483 local mobility anchor and if there are not other mobile nodes for 2484 which the tunnel is being used, then the tunnel MUST be deleted. 2486 4. It MUST tear down the point-to-point link shared with the mobile 2487 node. This action will force the mobile node to remove any IPv6 2488 address configuration on the interface connected to this point- 2489 to-point link. 2491 6.9.1.5. Constructing the Proxy Binding Update Message 2493 o The mobile access gateway when sending the Proxy Binding Update 2494 request to the local mobility anchor MUST construct the message as 2495 specified below. 2497 IPv6 header (src=Proxy-CoA, dst=LMAA) 2498 Mobility header 2499 - BU /* P & A flags MUST be set to value 1 */ 2500 Mobility Options 2501 - Mobile Node Identifier option (mandatory) 2502 - Home Network Prefix option(s) (mandatory) 2503 - Handoff Indicator option (mandatory) 2504 - Access Technology Type option (mandatory) 2505 - Timestamp option (optional) 2506 - Mobile Node Link-layer Identifier option (optional) 2507 - Link-local Address option (optional) 2509 Figure 12: Proxy Binding Update message format 2511 o The Source Address field in the IPv6 header of the message MUST be 2512 set to the global address configured on the egress interface of 2513 the mobile access gateway. When there is no Alternate Care-of 2514 Address option present in the request, this address will be 2515 considered as the Proxy-CoA address for this binding registration 2516 request. However, when there is Alternate Care-of Address option 2517 present in the request, this address will be not be considered as 2518 the Proxy-CoA address, but the address in the alternate Care-of 2519 Address option will be considered as the Proxy-CoA address. 2521 o The Destination Address field in the IPv6 header of the message 2522 MUST be set to the local mobility anchor address. 2524 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2526 o At least one Home Network Prefix option MUST be present. 2528 o The Handoff Indicator option MUST be present. 2530 o The Access Technology Type option MUST be present. 2532 o The Timestamp option MAY be present. 2534 o The Mobile Node Link-layer Identifier option MAY be present. 2536 o The Link-local Address option MAY be present. 2538 o If IPsec is used for protecting the signaling messages, the 2539 message MUST be protected, using the security association existing 2540 between the local mobility anchor and the mobile access gateway. 2542 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2543 3775] MUST NOT be present in the IPv6 Destination Options 2544 extension header of the Proxy Binding Update message. 2546 6.9.2. Router Solicitation Messages 2548 A mobile node may send a Router Solicitation message on the access 2549 link shared with the mobile access gateway. The Router Solicitation 2550 message that the mobile node sends is as specified in [RFC-4861]. 2551 The mobile access gateway on receiving the Router Solicitation 2552 message or before sending a Router Advertisement message MUST apply 2553 the following considerations. 2555 1. The mobile access gateway on receiving the Router Solicitation 2556 message SHOULD send a Router Advertisement message containing the 2557 mobile node's home network prefix(es) as the on-link prefix(es). 2558 However, before sending the Router Advertisement message 2559 containing the mobile node's home network prefix(es), it SHOULD 2560 complete the binding registration process with the mobile node's 2561 local mobility anchor. 2563 2. If the local mobility anchor rejects the binding registration 2564 request, or, if the mobile access gateway failed to complete the 2565 binding registration process for whatever reason, the mobile 2566 access gateway MUST NOT advertise the mobile node's home network 2567 prefix(es) in the Router Advertisement messages that it sends on 2568 the access link. However, it MAY choose to advertise a local 2569 visited network prefix(es) to enable the mobile node for regular 2570 IPv6 access. 2572 3. The mobile access gateway SHOULD add the MTU option, as specified 2573 in [RFC-4861], to the Router Advertisement messages that it sends 2574 on the access link. This will ensure the mobile node on the link 2575 uses the advertised MTU value. The MTU value SHOULD reflect the 2576 tunnel MTU for the bi-directional tunnel between the mobile 2577 access gateway and the local mobility anchor. Considerations 2578 from Section 6.9.5 SHOULD be applied for determining the tunnel 2579 MTU value. 2581 6.9.3. Default-Router 2583 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2584 router for the mobile node on the access link. However, as the 2585 mobile node moves from one access link to another, the serving mobile 2586 access gateway on those respective links will send the Router 2587 Advertisement messages. If these Router Advertisements are sent 2588 using a different link-local address or a different link-layer 2589 address, the mobile node will always detect a new default-router 2590 after every handoff. For solving this problem, this specification 2591 requires all the mobile access gateways in the Proxy Mobile IPv6 2592 domain to use the same link-local and link-layer address on any of 2593 the access links where ever the mobile node attaches. These 2594 addresses can be fixed addresses across the entire Proxy Mobile IPv6 2595 domain and all the mobile access gateways can use these globally 2596 fixed address on any of the point-to-point links. The configuration 2597 variables FixedMAGLinkLocalAddressOnAllAccessLinks and 2598 FixedMAGLinkLayerAddressOnAllAccessLinks SHOULD be used for this 2599 purpose. Additionally, this specification allows the local mobility 2600 anchor to generate the link-local address and provide it to the 2601 mobile access gateway as part of the signaling messages. 2603 However, both of these approaches (a link-local address generated by 2604 the local mobility anchor or when using a globally fixed link-local 2605 address) have implications on the deployment of SEcure Neighbor 2606 Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and 2607 public key pairs, and their Router Advertisements are signed with the 2608 private keys of these key pairs. When a number of different routers 2609 use the same addresses, the routers either all have to be able to 2610 construct these signatures for the same key pair, or the used key 2611 pair and the router's cryptographic identity must change after a 2612 movement. Both approaches are problematic. Sharing of private key 2613 information across a number of nodes would be inappropriate. And 2614 changing even the cryptographic identity of the router goes against 2615 the general idea of the Proxy Mobile IPv6 being as invisible to the 2616 hosts as possible. 2618 There is, however, ongoing work at the IETF to revise the SEND 2619 specifications. It is suggested that these revisions also address 2620 the above problem. Other revisions are needed to deal with other 2621 problematic cases (such as Neighbor Discovery proxies) before wide- 2622 spread deployment of SEND. 2624 6.9.4. Retransmissions and Rate Limiting 2626 The mobile access gateway is responsible for retransmissions and rate 2627 limiting the binding registration requests that it sends to the local 2628 mobility anchor. The Retransmission and the Rate Limiting rules are 2629 as specified in [RFC-3775]. However, the following considerations 2630 MUST be applied. 2632 1. When the mobile access gateway sends a Proxy Binding Update 2633 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2634 [RFC-3775], for configuring the retransmission timer, as 2635 specified in Section 11.8 [RFC-3775]. However, the mobile access 2636 gateway is not required to use a longer retransmission interval 2637 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2638 the initial binding registration request. 2640 2. If the mobile access gateway fails to receive a valid matching 2641 response for a registration or re-registration message within the 2642 retransmission interval, it SHOULD retransmit the message until a 2643 response is received. However, the mobile access gateway MUST 2644 ensure the mobile node is still attached to the connected link 2645 before retransmitting the message. 2647 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2648 gateway MUST use an exponential back-off process in which the 2649 timeout period is doubled upon each retransmission, until either 2650 the node receives a response or the timeout period reaches the 2651 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2652 MAY continue to send these messages at this slower rate 2653 indefinitely. 2655 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2656 Binding Update messages MUST use the latest timestamp. If the 2657 Sequence number scheme is in use, the retransmitted Proxy Binding 2658 Update messages MUST use a Sequence Number value greater than 2659 that used for the previous transmission of this Proxy Binding 2660 Update message, just as specified in [RFC-3775]. 2662 6.9.5. Path MTU Discovery 2664 It is important that mobile node, mobile access gateway, and local 2665 mobility anchor have a correct understanding of MTUs. When the 2666 mobile node uses the correct MTU, it can send packets that do not 2667 exceed the local link MTU and do not cause the tunneled packets from 2668 the mobile access gateway to be fragmented. This is important both 2669 from the perspective of efficiency, as well as preventing hard-to- 2670 diagnose MTU problems. The following are some of the considerations 2671 related to Path MTU discovery. 2673 o The local mobility anchor and mobile access gateway MAY use the 2674 Path MTU Discovery mechanisms as specified in [RFC-1981] or in 2675 [RFC-4821] for determining the Path MTU (PMTU) for the (LMA-MAG) 2676 paths. The specific discovery mechanism to be used in a given 2677 deployment can be configurable. 2679 o The mobility entities MUST implement and SHOULD support ICMP-based 2680 Path MTU discovery mechanism as specified in [RFC-1981]. However, 2681 this mechanism may not work correctly if the Proxy Mobile IPv6 2682 network does not deliver or process ICMP Packet Too Big messages. 2684 o The mobility entities MAY implement Packetization Layer Path MTU 2685 discovery mechanisms as specified in [RFC-4821] and use any 2686 application traffic as a payload for the PMTU discovery. Neither 2687 the Proxy Mobile IPv6 protocol or the tunnel between the mobile 2688 access gateway and local mobility agent can easily be used for 2689 this purpose. However, implementations SHOULD support at least 2690 the use of an explicit ICMP Echo Request/Response for this 2691 purpose. 2693 o The mobility entities MAY choose to perform Path MTU discovery for 2694 all the (LMA-MAG) paths at the boot time and may repeat this 2695 operation periodically to ensure the Path MTU values have not 2696 changed for those paths. If the dynamic PMTU discovery mechanisms 2697 fail to determine the Path MTU, an administratively configured 2698 default value MUST be used. 2700 o The IPv6 tunnel MTU for an established tunnel between the local 2701 mobility anchor and the mobile access gateway MUST be computed 2702 based on the determined Path MTU value for that specific path and 2703 the computation should be as specified in Section 6.7 of [RFC- 2704 2473]. 2706 o The mobile access gateway SHOULD use the determined tunnel Path 2707 MTU value (for the tunnel established with the mobile node's local 2708 mobility anchor) as the MTU value in the MTU option that it sends 2709 in the Router Advertisements on the access link shared with the 2710 mobile node. 2712 o If the mobile access gateway detects a change in MTU value for any 2713 of the paths (LMA-MAG) and at any point of time, the corresponding 2714 tunnel MTU value MUST be updated to reflect the change in Path MTU 2715 value. The adjusted tunnel MTU value SHOULD be notified to the 2716 impacted mobile nodes by sending additional Router Advertisement 2717 messages. Additionally, the adjusted tunnel MTU value MUST be 2718 used in all the subsequent Router Advertisement messages as well. 2720 6.10. Routing Considerations 2722 This section describes how the mobile access gateway handles the 2723 traffic to/from the mobile node that is attached to one of its access 2724 interfaces. 2726 Proxy-CoA LMAA 2727 | | 2728 +--+ +---+ +---+ +--+ 2729 |MN|----------|MAG|======================|LMA|----------|CN| 2730 +--+ +---+ +---+ +--+ 2731 IPv6 Tunnel 2733 Figure 13: Proxy Mobile IPv6 Tunnel 2735 6.10.1. Transport Network 2737 As per this specification, the transport network between the local 2738 mobility anchor and the mobile access gateway is an IPv6 network. 2739 The companion document [ID-IPV4-PMIP6] specifies the required 2740 extensions for negotiating IPv4 transport and the corresponding 2741 encapsulation mode. 2743 6.10.2. Tunneling & Encapsulation Modes 2745 An IPv6 address that a mobile node uses from its home network 2746 prefix(es) is topologically anchored at the local mobility anchor. 2747 For a mobile node to use this address from an access network attached 2748 to a mobile access gateway, proper tunneling techniques have to be in 2749 place. Tunneling hides the network topology and allows the mobile 2750 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2751 packet and to be routed between the local mobility anchor and the 2752 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2753 defines the use of IPv6-over-IPv6 tunneling [RFC-2473], between the 2754 home agent and the mobile node and this specification extends the use 2755 of the same tunneling mechanism for use between the local mobility 2756 anchor and the mobile access gateway. 2758 On most operating systems, a tunnel is implemented as a virtual 2759 point-to-point interface. The source and the destination address of 2760 the two end points of this virtual interface along with the 2761 encapsulation mode are specified for this virtual interface. Any 2762 packet that is routed over this interface gets encapsulated with the 2763 outer header as specified for that point to point tunnel interface. 2765 For creating a point to point tunnel to any local mobility anchor, 2766 the mobile access gateway may implement a tunnel interface with the 2767 source address field set to a global address on its egress interface 2768 (Proxy-CoA) and the destination address field set to the global 2769 address of the local mobility anchor (LMAA). 2771 The following is the supported packet encapsulation mode that can be 2772 used by the mobile access gateway and the local mobility anchor for 2773 routing mobile node's IPv6 datagrams. 2775 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2776 2473]. 2778 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2779 modes for supporting IPv4 transport. 2781 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2782 details on how this mode is negotiated is specified in [ID-IPV4- 2783 PMIP6]. 2785 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2786 packet. This mode is specified in [ID-IPV4-PMIP6]. 2788 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2789 packet with a TLV header. This mode is specified in [ID-IPV4- 2790 PMIP6]. 2792 6.10.3. Local Routing 2794 If there is data traffic between a visiting mobile node and a 2795 correspondent node that is locally attached to an access link 2796 connected to the mobile access gateway, the mobile access gateway MAY 2797 optimize on the delivery efforts by locally routing the packets and 2798 by not reverse tunneling them to the mobile node's local mobility 2799 anchor. The flag EnableMAGLocalRouting MAY be used for controlling 2800 this behavior. However, in some systems, this may have an 2801 implication on the mobile node's accounting and policy enforcement as 2802 the local mobility anchor is not in the path for that traffic and it 2803 will not be able to apply any traffic policies or do any accounting 2804 for those flows. 2806 This decision of path optimization SHOULD be based on the policy 2807 configured on the mobile access gateway, but enforced by the mobile 2808 node's local mobility anchor. The specific details on how this is 2809 achieved are beyond of the scope of this document. 2811 6.10.4. Tunnel Management 2813 All the considerations mentioned in Section 5.6.1 for the tunnel 2814 management on the local mobility anchor apply for the mobile access 2815 gateway as well. 2817 6.10.5. Forwarding Rules 2819 Forwarding Packets sent to the Mobile Node's Home Network: 2821 o On receiving a packet from the bi-directional tunnel established 2822 with the mobile node's local mobility anchor, the mobile access 2823 gateway MUST use the destination address of the inner packet for 2824 forwarding it on the interface where the destination network 2825 prefix is hosted. The mobile access gateway MUST remove the outer 2826 header before forwarding the packet. Considerations from [RFC- 2827 2473] MUST be applied for IPv6 decapsulation. If the mobile 2828 access gateway cannot find the connected interface for that 2829 destination address, it MUST silently drop the packet. For 2830 reporting an error in such a scenario, in the form of ICMP control 2831 message, the considerations from [RFC-2473] MUST be applied. 2833 o On receiving a packet from a correspondent node that is locally 2834 connected and which is destined to a mobile node that is on 2835 another locally connected access link, the mobile access gateway 2836 MUST check the flag EnableMAGLocalRouting, to ensure the mobile 2837 access gateway is allowed to route the packet directly to the 2838 mobile node. If the mobile access gateway is not allowed to route 2839 the packet directly, it MUST route the packet through the bi- 2840 directional tunnel established between itself and the mobile 2841 node's local mobility anchor. Otherwise, it can route the packet 2842 directly to the mobile node. 2844 Forwarding Packets Sent by the Mobile Node: 2846 o On receiving a packet from a mobile node connected to its access 2847 link, the mobile access gateway MUST ensure that there is an 2848 established binding for that mobile node with its local mobility 2849 anchor before forwarding the packet directly to the destination or 2850 before tunneling the packet to the mobile node's local mobility 2851 anchor. 2853 o On receiving a packet from a mobile node connected to its access 2854 link for a destination that is locally connected, the mobile 2855 access gateway MUST check the flag EnableMAGLocalRouting, to 2856 ensure the mobile access gateway is allowed to route the packet 2857 directly to the destination. If the mobile access gateway is not 2858 allowed to route the packet directly, it MUST route the packet 2859 through the bi-directional tunnel established between itself and 2860 the mobile node's local mobility anchor. Otherwise, it MUST route 2861 the packet directly to the destination. 2863 o On receiving a packet from a mobile node connected to its access 2864 link, to a destination that is not directly connected, the packet 2865 MUST be forwarded to the local mobility anchor through the bi- 2866 directional tunnel established between itself and the mobile 2867 node's local mobility anchor. However, the packets that are sent 2868 with the link-local source address MUST NOT be forwarded. 2870 o The format of the tunneled packet is shown below. Considerations 2871 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 2872 when using IPv4 transport, the format of the tunneled packet is as 2873 described in [ID-IPV4-PMIP6]. 2875 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2876 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2877 Upper layer protocols /* Packet Content*/ 2879 Figure 14: Tunneled Packet from MAG to LMA 2881 o The format of the tunneled packet is shown below, when payload 2882 protection using IPsec is enabled for the mobile node's data 2883 traffic. However, when using IPv4 transport, the format of the 2884 packet is as described in [ID-IPV4-PMIP6]. 2886 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2887 ESP Header in tunnel mode /* ESP Header */ 2888 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2889 Upper layer protocols /* Packet Content*/ 2891 Figure 15: Tunneled Packet from MAG to LMA with Payload Protection 2893 6.11. Supporting DHCP based Address Configuration on the Access Link 2895 This section explains how Stateful Address Configuration using DHCP 2896 support can be enabled in a Proxy Mobile IPv6 domain. It also 2897 identifies the required configuration in DHCP and mobility 2898 infrastructures for supporting this address configuration mode and 2899 also identifies the protocol interactions between these two systems. 2901 o For supporting Stateful Address Configuration using DHCP, the DHCP 2902 relay agent [RFC-3315] service MUST be supported on all the mobile 2903 access gateways in the Proxy Mobile IPv6 domain. Further, as 2904 specified in Section 20 of [RFC-3315], the DHCP relay agent should 2905 be configured to use a list of destination addresses, which MAY 2906 include unicast addresses, the All_DHCP_Servers multicast address, 2907 or other addresses as required in a given deployment. 2909 o The DHCP infrastructure needs to be configured to assign addresses 2910 from each of the prefixes assigned to a link in that Proxy Mobile 2911 IPv6 domain. The DHCP relay agent indicates the link to which the 2912 mobile node is attached by including an IPv6 address from any of 2913 the prefixes assigned to that link in the link-address field of 2914 the Relay Forward message. Therefore, for each link in the Mobile 2915 IPv6 domain, the DHCP infrastructure will: 2917 * be configured with a list of all of the prefixes associated 2918 with that link; 2920 * identify the link to which the mobile node is attached by 2921 looking up the prefix for the link-address field in the Relay 2922 Forward message in the list of prefixes associated with each 2923 link 2925 * assign to the host an address from each prefix associated with 2926 the link to which the mobile node is attached. 2928 This DHCP infrastructure configuration requirement is identical 2929 with other IPv6 networks; other than receiving DHCP messages from 2930 a mobile node through different relay agents (MAGs) over time, the 2931 DHCP infrastructure will be unaware of the mobile node's 2932 capability with respect to mobility support. 2934 o The local mobility anchor needs to have the same awareness with 2935 respect to the links along with the associated prefixes in a Proxy 2936 Mobile IPv6 domain. When a local mobility anchor assigns 2937 prefix(es) to a mobile node, it MUST assign all the prefixes 2938 associated with a given link and all of those assigned prefixes 2939 will remain as the home network prefixes for that mobile node 2940 through out the life of that mobility session. The serving mobile 2941 access gateway that hosts these prefixes is physically connected 2942 to that link and can function as the DHCP relay agent. This 2943 common understanding between DHCP and mobility entities about all 2944 the links in the domain along with the associated prefixes, 2945 provides the required coordination for allowing mobility entities 2946 to perform prefix assignment dynamically to a mobile node and 2947 still allow the DHCP infrastructure to perform address assignment 2948 for that mobile node only from its home network prefixes. 2950 o When a mobile node sends a DHCP request message, the DHCP relay 2951 agent function on the mobile access gateway will set the link- 2952 address field in the DHCP message to an address in the mobile 2953 node's home network prefix (any one of the mobile node's home 2954 network prefixes assigned to that mobile node's attached 2955 interface). The mobile access gateway can generate an 2956 autoconfiguration address from one of the mobile node's home 2957 network prefixes [RFC-4862] and can use this address link-address 2958 option, so as to provide a hint to the DHCP Server for the link 2959 identification. The DHCP server on receiving the request from the 2960 mobile node, will allocate addresses from all the prefixes 2961 associated with that link (identified using the link-address field 2962 of the request). 2964 o Once the mobile node obtains address(es) and moves to a different 2965 link and sends a DHCP request (at any time) for extending the DHCP 2966 lease, the DHCP relay agent on the new link will set the link- 2967 address field in the DHCP Relay Forward message to one of the 2968 mobile node's home network prefixes. The DHCP server will 2969 identify the client from the Client-DUID option and will identify 2970 the link from the link-address option present in the request and 2971 will allocate the same address(es) as before. 2973 o For correct operation of the model of network-based mobility 2974 management in which the host does not participate in any mobility 2975 management, the mobile node MUST always be assigned an identical 2976 set of IPv6 addresses regardless of the access link to which the 2977 mobile node is attached. For example, the mobile access gateways 2978 in the Proxy Mobile IPv6 domain should be configured so that DHCP 2979 messages from a mobile node will always be handled by the same 2980 DHCP server or by a server from the same group of coordinated DHCP 2981 servers serving that domain. DHCP based address configuration is 2982 not recommended for deployments in which the local mobility anchor 2983 and the mobile access gateway are located in different 2984 administrative domains. 2986 6.12. Home Network Prefix Renumbering 2988 If the mobile node's home network prefix(es) gets renumbered or 2989 becomes invalid during the middle of a mobility session, the mobile 2990 access gateway MUST withdraw the prefix(es) by sending a Router 2991 Advertisement message on the access link with zero prefix lifetime 2992 for the prefix(es) that is being renumbered. Also, the local 2993 mobility anchor and the mobile access gateway MUST delete the created 2994 routing state for the renumbered prefix(es). However, the specific 2995 details on how the local mobility anchor notifies the mobile access 2996 gateway about the mobile node's home network prefix(es) renumbering 2997 are outside the scope of this document. 2999 6.13. Mobile Node Detachment Detection and Resource Cleanup 3001 Before sending a Proxy Binding Update message to the local mobility 3002 anchor for extending the lifetime of a currently existing binding of 3003 a mobile node, the mobile access gateway MUST make sure the mobile 3004 node is still attached to the connected link by using some reliable 3005 method. If the mobile access gateway cannot predictably detect the 3006 presence of the mobile node on the connected link, it MUST NOT 3007 attempt to extend the registration lifetime of the mobile node. 3008 Further, in such a scenario, the mobile access gateway SHOULD 3009 terminate the binding of the mobile node by sending a Proxy Binding 3010 Update message to the mobile node's local mobility anchor with 3011 lifetime value set to 0. It MUST also remove any local state such as 3012 the Binding Update List entry created for that mobile node. 3014 The specific detection mechanism of the loss of a visiting mobile 3015 node on the connected link is specific to the access link between the 3016 mobile node and the mobile access gateway and is outside the scope of 3017 this document. Typically, there are various link-layer specific 3018 events specific to each access technology that the mobile access 3019 gateway can depend on for detecting the node loss. In general, the 3020 mobile access gateway can depend on one or more of the following 3021 methods for the detection presence of the mobile node on the 3022 connected link: 3024 o Link-layer event specific to the access technology 3026 o PPP Session termination event on point-to-point link types 3028 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 3030 o Notification event from the local mobility anchor 3032 6.14. Allowing network access to other IPv6 nodes 3034 In some Proxy Mobile IPv6 deployments, network operators may want to 3035 provision the mobile access gateway to offer network-based mobility 3036 management service only to some visiting mobile nodes and enable just 3037 regular IP access to some other nodes. This requires the network to 3038 have control on when to enable network-based mobility management 3039 service to a mobile node and when to enable regular IPv6 access. 3040 This specification does not disallow such configuration. 3042 Upon detecting a mobile node on its access link and after policy 3043 considerations, the mobile access gateway MUST determine if network- 3044 based mobility management service should be offered to that mobile 3045 node. If the mobile node is entitled for network-based mobility 3046 management service, then the mobile access gateway must ensure the 3047 mobile node does not detect any change with respect to its layer-3 3048 attachment, as explained in various sections of this specification. 3050 If the mobile node is not entitled for the network-based mobility 3051 management service, as determined from the policy considerations, the 3052 mobile access gateway MAY choose to offer regular IPv6 access to the 3053 mobile node and in such a scenario the normal IPv6 considerations 3054 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 3055 obtain IPv6 address(es) using the normal IPv6 address configuration 3056 procedures. The obtained address(es) must be from a local visitor 3057 network prefix(es). This essentially ensures that the mobile access 3058 gateway functions as a normal access router to a mobile node attached 3059 to its access link and without impacting its host-based mobility 3060 protocol operation. 3062 7. Mobile Node Operation 3064 This non-normative section explains the mobile node's operation in a 3065 Proxy Mobile IPv6 domain. 3067 7.1. Moving into a Proxy Mobile IPv6 Domain 3069 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 3070 an access network, the mobile access gateway on the access link 3071 detects the attachment of the mobile node and completes the binding 3072 registration with the mobile node's local mobility anchor. If the 3073 binding update operation is successfully performed, the mobile access 3074 gateway will create the required state and set up the forwarding for 3075 the mobile node's data traffic. 3077 If the mobile node is IPv6 enabled, on attaching to the access link, 3078 it will typically send a Router Solicitation message [RFC-4861]. The 3079 mobile access gateway on the access link will respond to the Router 3080 Solicitation message with a Router Advertisement message. The Router 3081 Advertisement message will carry the mobile node's home network 3082 prefix(es), default-router address and other address configuration 3083 Parameters. 3085 If the mobile access gateway on the access link receives a Router 3086 Solicitation message from the mobile node, before it completes the 3087 signaling with the mobile node's local mobility anchor, the mobile 3088 access gateway may not know the mobile node's home network prefix(es) 3089 and may not be able to emulate the mobile node's home link on the 3090 access link. In such a scenario, the mobile node may notice a delay 3091 before it receives a Router Advertisement message. This will also 3092 affect mobile nodes that would be capable of handling their own 3093 mobility, or mobile nodes that do not need to maintain the same IP 3094 address through movements. 3096 If the received Router Advertisement message has the Managed Address 3097 Configuration flag set, the mobile node, as it would normally do, 3098 will send a DHCP Request [RFC-3315]. The DHCP relay service enabled 3099 on that access link will ensure the mobile node can obtain one or 3100 more addresses from its home network prefix(es). 3102 If the received Router Advertisement message does not have the 3103 Managed Address Configuration flag set and if the mobile node is 3104 allowed to use autoconfigured address(es), the mobile node will be 3105 able to obtain IPv6 address(es) and from each of its home network 3106 prefixes using any of the standard IPv6 address configuration 3107 mechanisms permitted for that mode. 3109 If the mobile node is IPv4 enabled and if the network permits, it 3110 will be able to obtain the IPv4 address configuration as specified in 3111 the companion document [ID-IPV4-PMIP6]. 3113 Once the address configuration is complete, the mobile node can 3114 continue to use this address configuration as long as it is attached 3115 to the network that is in the scope of that Proxy Mobile IPv6 domain. 3117 7.2. Roaming in the Proxy Mobile IPv6 Domain 3119 After obtaining the address configuration in the Proxy Mobile IPv6 3120 domain, as the mobile node moves and changes its point of attachment 3121 from one mobile access gateway to the other, it can still continue to 3122 use the same address configuration. As long as the attached access 3123 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 3124 node will always detect the same router advertising itself as a 3125 default-router and advertising the mobile node's home network 3126 prefix(es) on each connected link. If the mobile node has address 3127 configuration that it obtained using DHCP, it will be able to retain 3128 the address configuration and extend the lease lifetime. 3130 8. Message Formats 3132 This section defines extensions to the Mobile IPv6 [RFC-3775] 3133 protocol messages. 3135 8.1. Proxy Binding Update Message 3137 0 1 2 3 3138 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 3139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3140 | Sequence # | 3141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3142 |A|H|L|K|M|R|P| Reserved | Lifetime | 3143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3144 | | 3145 . . 3146 . Mobility options . 3147 . . 3149 | | 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3152 A Binding Update message that is sent by a mobile access gateway to a 3153 local mobility anchor is referred to as the "Proxy Binding Update" 3154 message. A new flag (P) is included in the Binding Update message. 3155 The rest of the Binding Update message format remains the same as 3156 defined in [RFC-3775] and with the additional (R) and (M) flags as 3157 specified in [RFC-3963] and [RFC-4140] respectively. 3159 Proxy Registration Flag (P) 3161 A new flag (P) is included in the Binding Update message to 3162 indicate to the local mobility anchor that the Binding Update 3163 message is a proxy registration. The flag MUST be set to the 3164 value of 1 for proxy registrations and MUST be set to 0 for direct 3165 registrations sent by a mobile node. 3167 Mobility Options 3169 Variable-length field of such length that the complete Mobility 3170 Header is an integer multiple of 8 octets long. This field 3171 contains zero or more TLV-encoded mobility options. The encoding 3172 and format of defined options are described in Section 6.2 of 3173 [RFC-3775]. The local mobility anchor MUST ignore and skip any 3174 options which it does not understand. 3176 As per this specification, the following mobility options are 3177 valid in a Proxy Binding Update message. These options can be 3178 present in the message in any order. There can be one or more 3179 instances of the Home Network Prefix options present in the 3180 message. However, there cannot be more than one instance of any 3181 of the other options. 3183 Mobile Node Identifier option 3185 Home Network Prefix option 3187 Handoff Indicator option 3189 Access Technology Type option 3191 Timestamp option 3193 Mobile Node Link-layer Identifier option 3195 Link-local Address option 3197 Additionally, there can one or more instances of the Vendor- 3198 Specific Mobility option [RFC-5094]. 3200 For descriptions of other fields present in this message, refer to 3201 section 6.1.7 of [RFC-3775]. 3203 8.2. Proxy Binding Acknowledgement Message 3205 0 1 2 3 3206 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 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | Status |K|R|P|Reserved | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | Sequence # | Lifetime | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3212 | | 3213 . . 3214 . Mobility options . 3215 . . 3216 | | 3217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3219 A Binding Acknowledgement message that is sent by a local mobility 3220 anchor to a mobile access gateway is referred to as the "Proxy 3221 Binding Acknowledgement" message. A new flag (P) is included in the 3222 Binding Acknowledgement message. The rest of the Binding 3223 Acknowledgement message format remains the same as defined in [RFC- 3224 3775] and with the additional (R) flag as specified in [RFC-3963]. 3226 Proxy Registration Flag (P) 3228 A new flag (P) is included in the Binding Acknowledgement message 3229 to indicate that the local mobility anchor that processed the 3230 corresponding Proxy Binding Update message supports proxy 3231 registrations. The flag is set to value of 1 only if the 3232 corresponding Proxy Binding Update had the Proxy Registration Flag 3233 (P) set to value of 1. 3235 Mobility Options 3237 Variable-length field of such length that the complete Mobility 3238 Header is an integer multiple of 8 octets long. This field 3239 contains zero or more TLV-encoded mobility options. The encoding 3240 and format of defined options are described in Section 6.2 of 3241 [RFC-3775]. The mobile access gateway MUST ignore and skip any 3242 options which it does not understand. 3244 As per this specification, the following mobility options are 3245 valid in a Proxy Binding Acknowledgement message. These options 3246 can be present in the message in any order. There can be one or 3247 more instances of the Home Network Prefix options present in the 3248 message. However, there cannot be more than one instance of any 3249 of the other options. 3251 Mobile Node Identifier option 3253 Home Network Prefix option 3255 Handoff Indicator option 3257 Access Technology Type option 3259 Timestamp option 3261 Mobile Node Link-layer Identifier option 3263 Link-local Address option 3265 Additionally, there can one or more instances of the Vendor- 3266 Specific Mobility option [RFC-5094]. 3268 Status 3270 8-bit unsigned integer indicating the disposition of the Proxy 3271 Binding Update. Values of the Status field less than 128 indicate 3272 that the Proxy Binding Update was accepted by the local mobility 3273 anchor. Values greater than or equal to 128 indicate that the 3274 binding registration was rejected by the local mobility anchor. 3275 Section 8.9 defines the Status values that can used in Proxy 3276 Binding Acknowledgement message. 3278 For descriptions of other fields present in this message, refer to 3279 the section 6.1.8 of [RFC-3775]. 3281 8.3. Home Network Prefix Option 3283 A new option, Home Network Prefix Option is defined for using it in 3284 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3285 exchanged between a local mobility anchor and a mobile access 3286 gateway. This option is used for exchanging the mobile node's home 3287 network prefix information. There can be multiple Home Network 3288 Prefix options present in the message. 3290 The Home Network Prefix Option has an alignment requirement of 8n+4. 3291 Its format is as follows: 3293 0 1 2 3 3294 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 3295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3296 | Type | Length | Reserved | Prefix Length | 3297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3298 | | 3299 + + 3300 | | 3301 + Home Network Prefix + 3302 | | 3303 + + 3304 | | 3305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 Type 3308 3310 Length 3312 8-bit unsigned integer indicating the length of the option 3313 in octets, excluding the type and length fields. This field 3314 MUST be set to 18. 3316 Reserved (R) 3318 This 8-bit field is unused for now. The value MUST be 3319 initialized to 0 by the sender and MUST be ignored by the 3320 receiver. 3322 Prefix Length 3324 8-bit unsigned integer indicating the prefix length of the 3325 IPv6 prefix contained in the option. 3327 Home Network Prefix 3329 A sixteen-byte field containing the mobile node's IPv6 Home 3330 Network Prefix. 3332 8.4. Handoff Indicator Option 3334 A new option, Handoff Indicator Option is defined for using it in the 3335 Proxy Binding Update and Proxy Binding Acknowledgement messages 3336 exchanged between a local mobility anchor and a mobile access 3337 gateway. This option is used for exchanging the mobile node's 3338 handoff related hints. 3340 The Handoff Indicator Option has no alignment requirement. Its 3341 format is as follows: 3343 0 1 2 3 3344 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 3345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3346 | Type | Length | Reserved (R) | HI | 3347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3349 Type 3350 3352 Length 3354 8-bit unsigned integer indicating the length of the option 3355 in octets, excluding the type and length fields. This field 3356 MUST be set to 2. 3358 Reserved (R) 3360 This 8-bit field is unused for now. The value MUST be 3361 initialized to 0 by the sender and MUST be ignored by the 3362 receiver. 3364 Handoff Indicator (HI) 3366 A 8-bit field that specifies the type of handoff. The values 3367 (0 - 255) will be allocated and managed by IANA. The following 3368 values are currently defined. 3370 0: Reserved 3371 1: Attachment over a new interface 3372 2: Handoff between two different interfaces of the mobile node 3373 3: Handoff between mobile access gateways for the same interface 3374 4: Handoff state unknown 3375 5: Handoff state not changed (Re-registration) 3377 8.5. Access Technology Type Option 3379 A new option, Access Technology Type Option is defined for using it 3380 in the Proxy Binding Update and Proxy Binding Acknowledgement 3381 messages exchanged between a local mobility anchor and a mobile 3382 access gateway. This option is used for exchanging the type of the 3383 access technology using which the mobile node is currently attached 3384 to the mobile access gateway. 3386 The Access Technology Type Option has no alignment requirement. Its 3387 format is as follows: 3389 0 1 2 3 3390 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 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3392 | Type | Length | Reserved (R) | ATT | 3393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3395 Type 3396 3398 Length 3400 8-bit unsigned integer indicating the length of the option 3401 in octets, excluding the type and length fields. This field 3402 MUST be set to 2. 3404 Reserved (R) 3406 This 8-bit field is unused for now. The value MUST be 3407 initialized to 0 by the sender and MUST be ignored by the 3408 receiver. 3410 Access Technology Type (ATT) 3412 A 8-bit field that specifies the access technology through 3413 which the mobile node is connected to the access link on the 3414 mobile access gateway. 3416 The values (0 - 255) will be allocated and managed by IANA. The 3417 following values are currently reserved for the below specified 3418 access technology types. 3420 0: Reserved ("Reserved") 3421 1: Virtual ("Logical Network Interface") 3422 2: PPP ("Point-to-Point Protocol") 3423 3: IEEE 802.3 ("Ethernet") 3424 4: IEEE 802.11a/b/g ("Wireless LAN") 3425 5: IEEE 802.16e ("WIMAX") 3427 8.6. Mobile Node Link-layer Identifier Option 3429 A new option, Mobile Node Link-layer Identifier Option is defined for 3430 using it in the Proxy Binding Update and Proxy Binding 3431 Acknowledgement messages exchanged between a local mobility anchor 3432 and a mobile access gateway. This option is used for exchanging the 3433 mobile node's link-layer identifier. 3435 The format of the Link-layer Identifier option is shown below. Based 3436 on the size of the identifier, the option MUST be aligned 3437 appropriately, as per mobility option alignment requirements 3438 specified in [RFC-3775]. 3440 0 1 2 3 3441 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 3442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3443 | Type | Length | Reserved | 3444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3445 | | 3446 + Link-layer Identifier + 3447 . ... . 3448 | | 3449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3451 Type 3452 3454 Length 3455 8-bit unsigned integer indicating the length of the option 3456 in octets, excluding the type and length fields. 3458 Reserved 3460 This field is unused for now. The value MUST be initialized to 3461 0 by the sender and MUST be ignored by the receiver. 3463 Link-layer Identifier 3465 A variable length field containing the mobile node's link-layer 3466 identifier. 3468 The content and format of this field (including byte and bit 3469 ordering) is as specified in Section 4.6 of [RFC-4861] for 3470 carrying Link-Layer Address. On certain access links, where 3471 the link-layer address is not used or cannot be determined, 3472 this option cannot be used. 3474 8.7. Link-local Address Option 3476 A new option, Link-local Address Option is defined for using it in 3477 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3478 exchanged between a local mobility anchor and a mobile access 3479 gateway. This option is used for exchanging the link-local address 3480 of the mobile access gateway. 3482 The Link-local Address option has an alignment requirement of 8n+6. 3483 Its format is as follows: 3485 0 1 2 3 3486 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 3487 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3488 | Type | Length | 3489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3490 | | 3491 + + 3492 | | 3493 + Link-local Address + 3494 | | 3495 + + 3496 | | 3497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3499 Type 3500 3502 Length 3504 8-bit unsigned integer indicating the length of the option 3505 in octets, excluding the type and length fields. This field 3506 MUST be set to 16. 3508 Link-local Address 3510 A sixteen-byte field containing the mobile node's link-local 3511 address. 3513 8.8. Timestamp Option 3515 A new option, Timestamp Option is defined for use in the Proxy 3516 Binding Update and Proxy Binding Acknowledgement messages. 3518 The Timestamp option has an alignment requirement of 8n+2. Its 3519 format is as follows: 3521 0 1 2 3 3522 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 3523 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3524 | Type | Length | 3525 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3526 | | 3527 + Timestamp + 3528 | | 3529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3531 Type 3532 3534 Length 3536 8-bit unsigned integer indicating the length in octets of 3537 the option, excluding the type and length fields. The value 3538 for this field MUST be set to 8. 3540 Timestamp 3542 A 64-bit unsigned integer field containing a timestamp. The value 3543 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3544 by using a fixed point format. In this format, the integer number 3545 of seconds is contained in the first 48 bits of the field, and the 3546 remaining 16 bits indicate the number of 1/65536 fractions of a 3547 second. 3549 8.9. Status Values 3551 This document defines the following new Status values for use in 3552 Proxy Binding Acknowledgement message. These values are to be 3553 allocated from the same number space, as defined in Section 6.1.8 of 3554 [RFC-3775]. 3556 Status values less than 128 indicate that the Proxy Binding Update 3557 request was accepted by the local mobility anchor. Status values 3558 greater than 128 indicate that the Proxy Binding Update was rejected 3559 by the local mobility anchor. 3561 PROXY_REG_NOT_ENABLED: IANA 3563 Proxy registration not enabled for the mobile node 3565 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3567 Not local mobility anchor for this mobile node 3569 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3571 The mobile access gateway is not authorized to send proxy binding 3572 registrations 3574 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3576 The mobile node is not authorized for one or more of the 3577 requesting home network prefixes. 3579 TIMESTAMP_MISMATCH: IANA 3581 Invalid timestamp value (the clocks are out of sync) 3583 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3585 The timestamp value is lower than the previously accepted value 3587 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3589 Missing home network prefix option 3591 BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA 3593 All the home network prefixes listed in the BCE do not match all 3594 the prefixes in the received PBU 3596 MISSING_MN_IDENTIFIER_OPTION: IANA 3598 Missing mobile node identifier option 3600 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3602 Missing handoff indicator option 3604 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3606 Missing access technology type option 3608 Additionally, the following Status values defined in [RFC-3775] can 3609 also be used in Proxy Binding Acknowledgement message. 3611 0 Proxy Binding Update accepted 3613 128 Reason unspecified 3615 129 Administratively prohibited 3617 130 Insufficient resources 3619 9. Protocol Configuration Variables 3621 9.1. Local Mobility Anchor - Configuration Variables 3623 The local mobility anchor MUST allow the following variables to be 3624 configured by the system management. The configured values for these 3625 protocol variables MUST survive server reboots and service restarts. 3627 MinDelayBeforeBCEDelete 3629 This variable specifies the amount of time in milliseconds the 3630 local mobility anchor MUST wait before it deletes a Binding Cache 3631 entry of a mobile node, upon receiving a Proxy Binding Update 3632 message from a mobile access gateway with a lifetime value of 0. 3633 During this wait time, if the local mobility anchor receives a 3634 Proxy Binding Update for the same mobility binding, with lifetime 3635 value greater than 0, then it must update the binding cache entry 3636 with the accepted binding values. By the end of this wait-time, 3637 if the local mobility anchor did not receive any valid Proxy 3638 Binding Update message for that mobility binding, it MUST delete 3639 the Binding Cache entry. This delay essentially ensures a mobile 3640 node's Binding Cache entry is not deleted too quickly and allows 3641 some time for the new mobile access gateway to complete the 3642 signaling for the mobile node. 3644 The default value for this variable is 10000 milliseconds. 3646 MaxDelayBeforeNewBCEAssign 3648 This variable specifies the amount of time in milliseconds the 3649 local mobility anchor MUST wait for the de-registration message 3650 for an existing mobility session before it decides to create a new 3651 mobility session. 3653 The default value for this variable is 1500 milliseconds. 3655 Note that there is a dependency between this value and the values 3656 used in the retransmission algorithm for Proxy Binding Updates. 3657 The retransmissions need to happen before 3658 MaxDelayBeforeNewBCEAssign runs out, as otherwise there are 3659 situations where a de-registration from and old mobile access 3660 gateway may be lost, and the local mobility anchor creates 3661 needlessly a new session and new prefixes for the mobile node. 3662 This affects situations where there is no information from the 3663 lower layers about the type of a handoff or other parameters that 3664 can be used for identifying the mobility session, however. 3666 TimestampValidityWindow 3668 This variable specifies the maximum amount of time difference in 3669 milliseconds between the timestamp in the received Proxy Binding 3670 Update message and the current time-of-day on the local mobility 3671 anchor, that is allowed by the local mobility anchor for the 3672 received message to be considered valid. 3674 The default value for this variable is 300 milliseconds. This 3675 variable must be adjusted to suit the deployments. 3677 9.2. Mobile Access Gateway - Configuration Variables 3679 The mobile access gateway MUST allow the following variables to be 3680 configured by the system management. The configured values for these 3681 protocol variables MUST survive server reboots and service restarts. 3683 EnableMAGLocalRouting 3685 This flag indicates whether or not the mobile access gateway is 3686 allowed to enable local routing of the traffic exchanged between a 3687 visiting mobile node and a correspondent node that is locally 3688 connected to one of the interfaces of the mobile access gateway. 3689 The correspondent node can be another visiting mobile node as 3690 well, or a local fixed node. 3692 The default value for this flag is set to value of 0, indicating 3693 that the mobile access gateway MUST reverse tunnel all the traffic 3694 to the mobile node's local mobility anchor. 3696 When the value of this flag is set to value of 1, the mobile 3697 access gateway MUST route the traffic locally. 3699 This aspect of local routing MAY be defined as policy on a per 3700 mobile basis and when present will take precedence over this flag. 3702 9.3. Proxy Mobile IPv6 Domain - Configuration Variables 3704 All the mobile entities (local mobility anchors and mobile access 3705 gateways in a Proxy Mobile IPv6 domain MUST allow the following 3706 variables to be configured by the system management. The configured 3707 values for these protocol variables MUST survive server reboots and 3708 service restarts. These variables MUST be globally fixed for a given 3709 Proxy Mobile IPv6 domain resulting in the same values being enforced 3710 on all the mobility entities in that domain. 3712 MobileNodeGeneratedTimestampInUse 3714 This flag indicates whether or not the mobile node generated 3715 timestamp mechanism is in use in that Proxy Mobile IPv6 domain. 3716 When the value for this flag is set to 1, the local mobility 3717 anchors and mobile access gateways in that Proxy Mobile IPv6 3718 domain MUST apply the mobile node generated timestamp 3719 considerations. 3721 The default value for this flag is set to value of 0, indicating 3722 that the mobile node generated timestamp mechanism is not in use 3723 in that Proxy Mobile IPv6 domain. 3725 FixedMAGLinkLocalAddressOnAllAccessLinks 3726 This variable indicates the link-local address value that all the 3727 mobile access gateways SHOULD use on any of the access links 3728 shared with any of the mobile nodes in that Proxy Mobile IPv6 3729 domain. If this variable is initialized to ALL_ZERO value, it 3730 implies the use of fixed link-local address mode is not enabled 3731 for that Proxy Mobile IPv6 domain. 3733 FixedMAGLinkLayerAddressOnAllAccessLinks 3735 This variable indicates the link-layer address value that all the 3736 mobile access gateways SHOULD use on any of the access links 3737 shared with any of the mobile nodes in that Proxy Mobile IPv6 3738 domain. For access technologies where there is no link-layer 3739 address, this variable MUST be initialized to ALL_ZERO value. 3741 10. IANA Considerations 3743 This document defines six new Mobility Header options, the Home 3744 Network Prefix option, Handoff Indicator option, Access Technology 3745 Type option, Mobile Node Link-layer Identifier option, Link-local 3746 Address option and Timestamp option. These options are described in 3747 Section 8. The Type value for these options needs to be assigned 3748 from the same numbering space as allocated for the other mobility 3749 options, as defined in [RFC-3775]. 3751 The Handoff Indicator option defined in Section 8.4 of this document 3752 introduces a new Handoff Indicator (HI) numbering space, where the 3753 values from 0 to 5 have been reserved by this document. Approval of 3754 new Handoff Indicator type values are to be made through IANA Expert 3755 Review. 3757 The Access Technology Type option defined in Section 8.5 of this 3758 document introduces a new Access Technology type (ATT) numbering 3759 space, where the values from 0 to 5 have been reserved by this 3760 document. Approval of new Access Technology type values are to be 3761 made through IANA Expert Review. 3763 This document also defines new Binding Acknowledgement status values 3764 as described in Section 8.9. The status values MUST be assigned from 3765 the same number space used for Binding Acknowledgement status values, 3766 as defined in [RFC-3775]. The allocated values for each of these 3767 status values must be greater than 128. 3769 11. Security Considerations 3771 The potential security threats against any network-based mobility 3772 management protocol are described in [RFC-4832]. This section 3773 explains how Proxy Mobile IPv6 protocol defends itself against those 3774 threats. 3776 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3777 Binding Update and Proxy Binding Acknowledgement, exchanged between 3778 the mobile access gateway and the local mobility anchor to be 3779 protected using IPsec, using the established security association 3780 between them. This essentially eliminates the threats related to the 3781 impersonation of the mobile access gateway or the local mobility 3782 anchor. 3784 This specification allows a mobile access gateway to send binding 3785 registration messages on behalf of a mobile node. If proper 3786 authorization checks are not in place, a malicious node may be able 3787 to hijack a mobile node's session or may carry out a denial-of- 3788 service attack. To prevent this attack, this specification requires 3789 the local mobility anchor to allow only authorized mobile access 3790 gateways that are part of that Proxy Mobile IPv6 domain to send 3791 binding registration messages on behalf of a mobile node. 3793 To eliminate the threats on the interface between the mobile access 3794 gateway and the mobile node, this specification requires an 3795 established trust between the mobile access gateway and the mobile 3796 node and to authenticate and authorize the mobile node before it is 3797 allowed to access the network. Further, the established 3798 authentication mechanisms enabled on that access link will ensure 3799 that there is a secure binding between the mobile node's identity and 3800 its link-layer address. The mobile access gateway will definitively 3801 identify the mobile node from the packets that it receives on that 3802 access link. 3804 To address the threat related to a compromised mobile access gateway, 3805 the local mobility anchor, before accepting a Proxy Binding Update 3806 message for a given mobile node, may ensure that the mobile node is 3807 definitively attached to the mobile access gateway that sent the 3808 proxy binding registration request. This may be accomplished by 3809 contacting a trusted entity which is able to track the mobile node's 3810 current point of attachment. However, the specific details of the 3811 actual mechanisms for achieving this is outside the scope of this 3812 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).