idnits 2.17.1 draft-ietf-netlmm-proxymip6-15.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 3891. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3902. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3909. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3915. 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 16, 2008) is 5824 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4282 (Obsoleted by RFC 7542) -- Obsolete informational reference (is this intentional?): RFC 1981 (Obsoleted by RFC 8201) -- Obsolete informational reference (is this intentional?): RFC 3588 (Obsoleted by RFC 6733) -- Obsolete informational reference (is this intentional?): RFC 4140 (Obsoleted by RFC 5380) -- Obsolete informational reference (is this intentional?): RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 4330 (Obsoleted by RFC 5905) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) == Outdated reference: A later version (-18) exists of draft-ietf-netlmm-pmip6-ipv4-support-02 == Outdated reference: A later version (-09) exists of draft-ietf-dna-protocol-07 Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG S. Gundavelli (Editor) 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: November 17, 2008 V. Devarapalli 6 Wichorus 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 May 16, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-15.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 17, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 45 Abstract 47 Network-based mobility management enables IP mobility for a host 48 without requiring its participation in any mobility related 49 signaling. The Network is responsible for managing IP mobility on 50 behalf of the host. The mobility entities in the network are 51 responsible for tracking the movements of the host and initiating the 52 required mobility signaling on its behalf. This specification 53 describes a network-based mobility management protocol and is 54 referred to as Proxy Mobile IPv6. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 59 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 4 60 2.1. Conventions used in this document . . . . . . . . . . . . 5 61 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 9 63 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 15 64 4.1. Peer Authorization Database (PAD) Example Entries . . . . 16 65 4.2. Security Policy Database (SPD) Example Entries . . . . . . 17 66 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 17 67 5.1. Extensions to Binding Cache Entry Data Structure . . . . . 18 68 5.2. Supported Home Network Prefix Models . . . . . . . . . . . 19 69 5.3. Signaling Considerations . . . . . . . . . . . . . . . . . 20 70 5.3.1. Processing Binding Registrations . . . . . . . . . . . 20 71 5.3.2. Initial Binding Registration (New Mobility Session) . 22 72 5.3.3. Binding Lifetime Extension (No handoff) . . . . . . . 23 73 5.3.4. Binding Lifetime Extension (After handoff) . . . . . . 24 74 5.3.5. Binding De-Registration . . . . . . . . . . . . . . . 24 75 5.3.6. Constructing the Proxy Binding Acknowledgement 76 Message . . . . . . . . . . . . . . . . . . . . . . . 25 77 5.4. Multihoming Support . . . . . . . . . . . . . . . . . . . 27 78 5.4.1. Binding Cache entry lookup considerations . . . . . . 28 79 5.5. Timestamp Option for Message Ordering . . . . . . . . . . 33 80 5.6. Routing Considerations . . . . . . . . . . . . . . . . . . 36 81 5.6.1. Bi-Directional Tunnel Management . . . . . . . . . . . 36 82 5.6.2. Forwarding Considerations . . . . . . . . . . . . . . 37 83 5.7. Local Mobility Anchor Address Discovery . . . . . . . . . 38 84 5.8. Mobile Prefix Discovery Considerations . . . . . . . . . . 39 85 5.9. Route Optimization Considerations . . . . . . . . . . . . 39 86 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 39 87 6.1. Extensions to Binding Update List Entry Data Structure . . 40 88 6.2. Mobile Node's Policy Profile . . . . . . . . . . . . . . . 41 89 6.3. Supported Access Link Types . . . . . . . . . . . . . . . 42 90 6.4. Supported Address Configuration Modes . . . . . . . . . . 42 91 6.5. Access Authentication & Mobile Node Identification . . . . 43 92 6.6. Acquiring Mobile Node's Identifier . . . . . . . . . . . . 43 93 6.7. Home Network Emulation . . . . . . . . . . . . . . . . . . 44 94 6.8. Link-Local and Global Address Uniqueness . . . . . . . . . 45 95 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 46 96 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 46 97 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 54 98 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 55 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 56 100 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 56 101 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 57 102 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 58 103 6.10.2. Tunneling & Encapsulation Modes . . . . . . . . . . . 58 104 6.10.3. Local Routing . . . . . . . . . . . . . . . . . . . . 59 105 6.10.4. Tunnel Management . . . . . . . . . . . . . . . . . . 59 106 6.10.5. Forwarding Rules . . . . . . . . . . . . . . . . . . . 59 107 6.11. Supporting DHCPv6 based Address Configuration on the 108 Access Link . . . . . . . . . . . . . . . . . . . . . . . 61 109 6.12. Home Network Prefix Renumbering . . . . . . . . . . . . . 63 110 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 63 111 6.14. Allowing network access to other IPv6 nodes . . . . . . . 64 112 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 64 113 7.1. Moving into a Proxy Mobile IPv6 Domain . . . . . . . . . . 64 114 7.2. Roaming in the Proxy Mobile IPv6 Domain . . . . . . . . . 65 115 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 66 116 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 66 117 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 68 118 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 69 119 8.4. Handoff Indicator Option . . . . . . . . . . . . . . . . . 70 120 8.5. Access Technology Type Option . . . . . . . . . . . . . . 71 121 8.6. Mobile Node Link-layer Identifier Option . . . . . . . . . 73 122 8.7. Link-local Address Option . . . . . . . . . . . . . . . . 74 123 8.8. Timestamp Option . . . . . . . . . . . . . . . . . . . . . 75 124 8.9. Status Values . . . . . . . . . . . . . . . . . . . . . . 75 125 9. Protocol Configuration Variables . . . . . . . . . . . . . . . 77 126 9.1. Local Mobility Anchor - Configuration Variables . . . . . 77 127 9.2. Mobile Access Gateway - Configuration Variables . . . . . 78 128 9.3. Proxy Mobile IPv6 Domain - Configuration Variables . . . . 79 129 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 79 130 11. Security Considerations . . . . . . . . . . . . . . . . . . . 80 131 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 81 132 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 81 133 13.1. Normative References . . . . . . . . . . . . . . . . . . . 82 134 13.2. Informative References . . . . . . . . . . . . . . . . . . 82 135 Appendix A. Proxy Mobile IPv6 interactions with AAA 136 Infrastructure . . . . . . . . . . . . . . . . . . . 84 137 Appendix B. Routing State . . . . . . . . . . . . . . . . . . . . 84 138 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 85 139 Intellectual Property and Copyright Statements . . . . . . . . . . 87 141 1. Introduction 143 IP mobility for IPv6 hosts is specified in Mobile IPv6 [RFC-3775]. 144 Mobile IPv6 requires client functionality in the IPv6 stack of a 145 mobile node. Exchange of signaling messages between the mobile node 146 and home agent enables the creation and maintenance of a binding 147 between the mobile node's home address and its care-of-address. 148 Mobility as specified in [RFC-3775] requires the IP host to send IP 149 mobility management signaling messages to the home agent, which is 150 located in the network. 152 Network-based mobility is another approach to solving the IP mobility 153 challenge. It is possible to support mobility for IPv6 nodes without 154 host involvement by extending Mobile IPv6 [RFC-3775] signaling 155 messages between a network node and a home agent. This approach to 156 supporting mobility does not require the mobile node to be involved 157 in the exchange of signaling messages between itself and the home 158 agent. A proxy mobility agent in the network performs the signaling 159 with the home agent and does the mobility management on behalf of the 160 mobile node attached to the network. Because of the use and 161 extension of Mobile IPv6 signaling and home agent functionality, this 162 protocol is referred to as Proxy Mobile IPv6 (PMIPv6). 164 Network deployments which are designed to support mobility would be 165 agnostic to the capability in the IPv6 stack of the nodes which it 166 serves. IP mobility for nodes which have mobile IP client 167 functionality in the IPv6 stack as well as those nodes which do not, 168 would be supported by enabling Proxy Mobile IPv6 protocol 169 functionality in the network. The advantages of developing a network 170 based mobility protocol based on Mobile IPv6 are: 172 o Reuse of home agent functionality and the messages/format used in 173 mobility signaling. Mobile IPv6 is a mature protocol with several 174 implementations that have undergone interoperability testing. 176 o A common home agent would serve as the mobility agent for all 177 types of IPv6 nodes. 179 The problem statement and the need for a network based mobility 180 protocol solution has been documented in [RFC-4830]. Proxy Mobile 181 IPv6 is a solution that addresses these issues and requirements. 183 2. Conventions & Terminology 184 2.1. Conventions used in this document 186 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 187 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 188 document are to be interpreted as described in RFC 2119 [RFC-2119]. 190 2.2. Terminology 192 All the general mobility related terms used in this document are to 193 be interpreted as defined in the Mobile IPv6 base specification [RFC- 194 3775]. 196 This document adopts the terms, Local Mobility Anchor (LMA) and 197 Mobile Access Gateway (MAG) from the NETLMM Goals document [RFC- 198 4831]. This document also provides the following context specific 199 explanation to the following terms used in this document. 201 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 203 Proxy Mobile IPv6 domain refers to the network where the mobility 204 management of a mobile node is handled using the Proxy Mobile IPv6 205 protocol as defined in this specification. The Proxy Mobile IPv6 206 domain includes local mobility anchors and mobile access gateways 207 between which security associations can be set up and 208 authorization for sending Proxy Binding Updates on behalf of the 209 mobile nodes can be ensured. 211 Local Mobility Anchor (LMA) 213 Local Mobility Anchor is the home agent for the mobile node in a 214 Proxy Mobile IPv6 domain. It is the topological anchor point for 215 the mobile node's home network prefix(es) and is the entity that 216 manages the mobile node's binding state. The local mobility 217 anchor has the functional capabilities of a home agent as defined 218 in Mobile IPv6 base specification [RFC-3775] with the additional 219 capabilities required for supporting Proxy Mobile IPv6 protocol as 220 defined in this specification. 222 Mobile Access Gateway (MAG) 224 Mobile Access Gateway is a function that manages the mobility 225 related signaling for a mobile node that is attached to its access 226 link. It is responsible for tracking the mobile node's movements 227 to and from the access link and for signaling the mobile node's 228 local mobility anchor. 230 Mobile Node (MN) 232 Throughout this document, the term mobile node is used to refer to 233 an IP host or router whose mobility is managed by the network. 234 The mobile node may be an IPv4-only node, IPv6-only node or a 235 dual-stack node and is not required to participate in any IP 236 mobility related signaling for achieving mobility for an IP 237 address that is obtained in that Proxy Mobile IPv6 domain. 239 LMA Address (LMAA) 241 The global address that is configured on the interface of the 242 local mobility anchor and is the transport endpoint of the bi- 243 directional tunnel established between the local mobility anchor 244 and the mobile access gateway. This is the address to where the 245 mobile access gateway sends the Proxy Binding Update messages. 246 When supporting IPv4 traversal, i.e., when the network between the 247 local mobility anchor and the mobile access gateway is an IPv4 248 network, this address will be an IPv4 address and will be referred 249 to as IPv4-LMAA, as specified in [ID-IPV4-PMIP6]. 251 Proxy Care-of Address (Proxy-CoA) 253 Proxy-CoA is the global address configured on the interface of the 254 mobile access gateway and is the transport endpoint of the tunnel 255 between the local mobility anchor and the mobile access gateway. 256 The local mobility anchor views this address as the Care-of 257 Address of the mobile node and registers it in the Binding Cache 258 entry for that mobile node. When the transport network between 259 the mobile access gateway and the local mobility anchor is an IPv4 260 network and if the care-of address that is registered at the local 261 mobility anchor is an IPv4 address, the term, IPv4-Proxy-CoA is 262 used, as specified in [ID-IPV4-PMIP6]. 264 Mobile Node's Home Network Prefix (MN-HNP) 266 This is the prefix that is assigned to a given interface of a 267 mobile node and is always present in the Router Advertisement 268 messages that the mobile node receives on any of the access links 269 in that Proxy Mobile IPv6 domain. There can also be multiple home 270 network prefixes assigned to a given interface of a mobile node 271 and in which case all of those assigned prefixes will still be 272 managed as part of one mobility session. The mobile node 273 configures its interface with one or more addresses from its home 274 network prefix(es). If the mobile node connects to the Proxy 275 Mobile IPv6 domain through multiple interfaces, simultaneously, 276 each of the attached interfaces will be assigned a unique set of 277 home network prefixes and all the prefixes assigned to a given 278 interface of a mobile node will be managed under one mobility 279 session. Additionally, in some configurations the assigned prefix 280 can be of 128-bit prefix length. Ex: Home network prefixes P1, P2 281 assigned to interface I1 will be managed under one mobility 282 session and prefixes P3, P4, P5 assigned to interface I2 of the 283 mobile node will be managed under a different mobility session. 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. 340 Policy Profile 342 Policy Profile is an abstract term for referring to a set of 343 configuration parameters that are configured for a given mobile 344 node. The mobility entities in the Proxy Mobile IPv6 domain 345 require access to these parameters for providing the mobility 346 management to a given mobile node. The specific details on how 347 the network entities obtain this policy profile is outside the 348 scope of this document. 350 Proxy Binding Update (PBU) 352 A binding registration request message sent by a mobile access 353 gateway to a mobile node's local mobility anchor for establishing 354 a binding between the mobile node's home network prefix(es) 355 assigned to a given interface of a mobile node and its current 356 care-of address (Proxy-CoA). 358 Proxy Binding Acknowledgement (PBA) 360 A binding registration reply message sent by a local mobility 361 anchor in response to a Proxy Binding Update request message that 362 it received from a mobile access gateway. 364 Per-MN-Prefix & Shared-Prefix Models 366 The term, Per-MN-Prefix model, is used to refer to an addressing 367 model where there is an unique network prefix assigned for each 368 node. The term, Shared-Prefix model, is used to refer to an 369 addressing model where the prefix is shared by more than one node. 370 This specification supports the Per-MN-Prefix model and does not 371 support the Shared-Prefix model. 373 ALL_ZERO & NON_ZERO 374 Protocol message fields initialized with value 0 in each byte of 375 the field. Ex: An 8-byte link-layer identifier field with the 376 value set to 0 in each of the 8 bytes, or an IPv6 address with the 377 value 0 in all of the 16 bytes. Conversely, the term NON_ZERO is 378 used to refer to any value other than an ALL_ZERO value. 380 3. Proxy Mobile IPv6 Protocol Overview 382 This specification describes a network-based mobility management 383 protocol. It is called Proxy Mobile IPv6 and is based on Mobile IPv6 384 [RFC-3775]. 386 Proxy Mobile IPv6 protocol is intended for providing network-based IP 387 mobility management support to a mobile node, without requiring the 388 participation of the mobile node in any IP mobility related 389 signaling. The mobility entities in the network will track the 390 mobile node's movements and will initiate the mobility signaling and 391 set up the required routing state. 393 The core functional entities in the NETLMM infrastructure are the 394 Local Mobility Anchor (LMA) and the Mobile Access Gateway (MAG). The 395 local mobility anchor is responsible for maintaining the mobile 396 node's reachability state and is the topological anchor point for the 397 mobile node's home network prefix(es). The mobile access gateway is 398 the entity that performs the mobility management on behalf of a 399 mobile node and it resides on the access link where the mobile node 400 is anchored. The mobile access gateway is responsible for detecting 401 the mobile node's movements to and from the access link and for 402 initiating binding registrations to the mobile node's local mobility 403 anchor. The architecture of a Proxy Mobile IPv6 domain is shown in 404 Figure 1. 406 +----+ +----+ 407 |LMA1| |LMA2| 408 +----+ +----+ 409 LMAA1 -> | | <-- LMAA2 410 | | 411 \\ //\\ 412 \\ // \\ 413 \\ // \\ 414 +---\\------------- //------\\----+ 415 ( \\ IPv4/IPv6 // \\ ) 416 ( \\ Network // \\ ) 417 +------\\--------//------------\\-+ 418 \\ // \\ 419 \\ // \\ 420 \\ // \\ 421 Proxy-CoA1--> | | <-- Proxy-CoA2 422 +----+ +----+ 423 |MAG1|-----{MN2} |MAG2| 424 +----+ | +----+ 425 | | | 426 MN-HNP1 --> | MN-HNP2 | <-- MN-HNP3, MN-HNP4 427 {MN1} {MN3} 429 Figure 1: Proxy Mobile IPv6 Domain 431 Once a mobile node enters a Proxy Mobile IPv6 domain and attaches to 432 an access link, the mobile access gateway on that access link, after 433 identifying the mobile node and acquiring its identity, will 434 determine if the mobile node is authorized for the network-based 435 mobility management service. 437 If the network determines that the network-based mobility management 438 service needs to be offered to that mobile node, the network will 439 ensure that the mobile node using any of the address configuration 440 mechanisms permitted by the network will be able to obtain the 441 address configuration on the connected interface and move anywhere in 442 that Proxy Mobile IPv6 domain. The obtained address configuration 443 includes the address(es) from its home network prefix(es), the 444 default-router address on the link and other related configuration 445 parameters. From the perspective of the mobile node, the entire 446 Proxy Mobile IPv6 domain appears as a single link, the network 447 ensures that the mobile node believes it is always on the same link 448 where it obtained its initial address configuration, even after 449 changing its point of attachment in that network. 451 The mobile node may be an IPv4-only node, IPv6-only node or a dual 452 IPv4/IPv6 node. Based on what is enabled in the network for that 453 mobile node, the mobile node will be able to obtain an IPv4, IPv6 or 454 dual IPv4/IPv6 addresses and move anywhere in that Proxy Mobile IPv6 455 domain. However this specification only supports IPv6 address 456 mobility and when the transport network is IPv6 network. The support 457 for IPv4 addressing or IPv4 transport network is specified in the 458 companion document [ID-IPV4-PMIP6]. 460 If the mobile node connects to the Proxy Mobile IPv6 domain through 461 multiple interfaces and over multiple access networks, the network 462 will allocate a unique set of home network prefixes for each of the 463 connected interfaces. The mobile node will be able to configure 464 address(es) on those interfaces from the respective home network 465 prefix(es). However, if the mobile node performs an inter-interface 466 handoff by moving its address configuration from one interface to the 467 other and if the local mobility anchor receives a handoff hint from 468 the serving mobile access gateway about the same, the local mobility 469 anchor will assign the same home network prefix(es) that it 470 previously assigned prior to the handoff. The mobile node will also 471 be able to perform an handoff by changing its point of attachment 472 from one mobile access gateway to a different mobile access gateway 473 using the same interface and will be able to retain the address 474 configuration on the attached interface. 476 +-----+ +-----+ +-----+ 477 | MN | | MAG | | LMA | 478 +-----+ +-----+ +-----+ 479 | | | 480 MN Attached | | 481 | | | 482 | MN Attached Event from MN/Network | 483 | (Acquire MN-Id and Profile) | 484 | | | 485 |--- Rtr Sol --------->| | 486 | | | 487 | |--- PBU ------------->| 488 | | | 489 | | Accept PBU 490 | | (Allocate MN-HNP(s), Setup BCE and Tunnel) 491 | | | 492 | |<------------- PBA ---| 493 | | | 494 | Accept PBA | 495 | (Setup Tunnel and Routing) | 496 | | | 497 | |==== Bi-Dir Tunnel ===| 498 | | | 499 |<--------- Rtr Adv ---| | 500 | | | 501 IP Address | | 502 Configuration | | 503 | | | 505 Figure 2: Mobile Node Attachment - Signaling Call Flow 507 Figure 2 shows the signaling call flow when the mobile node enters 508 the Proxy Mobile IPv6 domain. The Router Solicitation message from 509 the mobile node may arrive at any time after the mobile node's 510 attachment and has no strict ordering relation with the other 511 messages in the call flow. 513 For updating the local mobility anchor about the current location of 514 the mobile node, the mobile access gateway sends a Proxy Binding 515 Update message to the mobile node's local mobility anchor. Upon 516 accepting this Proxy Binding Update message, the local mobility 517 anchor sends a Proxy Binding Acknowledgement message including the 518 mobile node's home network prefix(es). It also creates the Binding 519 Cache entry and sets up its endpoint of the bi-directional tunnel to 520 the mobile access gateway. 522 The mobile access gateway on receiving the Proxy Binding 523 Acknowledgement message sets up its endpoint of the bi-directional 524 tunnel to the local mobility anchor and also sets up the data path 525 for the mobile node's traffic. At this point the mobile access 526 gateway will have all the required information for emulating the 527 mobile node's home link. It sends Router Advertisement messages to 528 the mobile node on the access link advertising the mobile node's home 529 network prefix(es) as the hosted on-link-prefix(es). 531 The mobile node on receiving these Router Advertisement messages on 532 the access link will attempt to configure its interface either using 533 stateful or stateless address configuration modes, based on the modes 534 that are permitted on that access link. At the end of a successful 535 address configuration procedure, the mobile node will end up with one 536 or more addresses from its home network prefixes(es). 538 Once the address configuration is complete, the mobile node has one 539 or more valid addresses from its home network prefix(es) at the 540 current point of attachment. The serving mobile access gateway and 541 the local mobility anchor also have proper routing states for 542 handling the traffic sent to and from the mobile node using any one 543 or more of the addresses from its home network prefix(es). 545 The local mobility anchor, being the topological anchor point for the 546 mobile node's home network prefix(es), receives any packets that are 547 sent to the mobile node by any node in the network. The local 548 mobility anchor forwards these received packets to the mobile access 549 gateway through the bi-directional tunnel. The mobile access gateway 550 on other end of the tunnel, after receiving the packet, removes the 551 outer header and forwards the packet on the access link to the mobile 552 node. However, in some cases the traffic sent from a correspondent 553 node that is locally connected to the mobile access gateway may not 554 be received by the local mobility anchor and may be routed locally by 555 the mobile access gateway. 557 The mobile access gateway acts as the default router on the access 558 link. Any packet that the mobile node sends to any correspondent 559 node will be received by the mobile access gateway and will be sent 560 to its local mobility anchor through the bi-directional tunnel. The 561 local mobility anchor on the other end of the tunnel, after receiving 562 the packet, removes the outer header and routes the packet to the 563 destination. However in some cases the traffic sent to a 564 correspondent node that is locally connected to the mobile access 565 gateway may be locally routed by the mobile access gateway. 567 +-----+ +-----+ +-----+ +-----+ 568 | MN | |p-MAG| | LMA | |n-MAG| 569 +-----+ +-----+ +-----+ +-----+ 570 | | | | 571 | |==Bi-Dir Tunnel=| | 572 MN Detached | | | 573 | MN Detached Event | | 574 | | | | 575 | |-- DeReg PBU -->| | 576 | | | | 577 | | Accept PBU | 578 | | (Start MinDelayBeforeBCEDelete Timer) 579 | | | | 580 | |<-------- PBA --| | 581 | | | | 582 MN Attached | | | 583 | | | MN Attached event received 584 | | | from MN or from network 585 | | | (Acquire MN-Id and Profile) 586 | | | | 587 |--- Rtr Sol ------------------------------------->| 588 .... 589 Registration steps as in fig 2. 590 .... 591 | | |==Bi-Dir Tunnel=| 592 | | | | 593 |<------------------------------------ Rtr Adv ----| 594 | | | | 595 MN retains HoA/HNP(s) 596 | | | | 598 Figure 3: Mobile Node Handoff - Signaling Call Flow 600 Figure 3 shows the signaling call flow for the mobile node's handoff 601 from previously attached mobile access gateway (p-MAG) to the newly 602 attached mobile access gateway (n-MAG). This call flow reflects only 603 a specific message ordering, it is possible the registration message 604 from the n-MAG may arrive before the de-registration message from the 605 p-MAG arrives. 607 After obtaining the initial address configuration in the Proxy Mobile 608 IPv6 domain, if the mobile node changes its point of attachment, the 609 mobile access gateway on the previous link will detect the mobile 610 node's detachment from the link and will signal the local mobility 611 anchor and will remove the binding and routing state for that mobile 612 node. The local mobility anchor upon receiving this request will 613 identify the corresponding mobility session for which the binding 614 update request was received and once it accepts the request will wait 615 for certain amount of time for allowing the mobile access gateway on 616 the new link to update the binding. However, if it does not receive 617 any binding update request within that given amount of time, it will 618 delete the binding cache entry. 620 The mobile access gateway on the new access link upon detecting the 621 mobile node on its access link will signal the local mobility anchor 622 for updating the binding state. Once that signaling is complete, the 623 mobile node will continue to receive the Router Advertisements 624 containing its home network prefix(es) that were assigned to that 625 mobility session, making it believe it is still on the same link and 626 it will be able to use the same address configuration on the new 627 access link. 629 4. Proxy Mobile IPv6 Protocol Security 631 The signaling messages, Proxy Binding Update and Proxy Binding 632 Acknowledgement, exchanged between the mobile access gateway and the 633 local mobility anchor MUST be protected using end-to-end security 634 association(s) offering integrity and data origin authentication. 636 The mobile access gateway and the local mobility anchor MUST 637 implement IPsec for protecting the Proxy Mobile IPv6 signaling 638 messages [RFC-4301]. That is, IPsec is a mandatory to implement 639 security mechanism. However, additional documents may specify 640 alternative mechanisms and the mobility entities can enable a 641 specific mechanism for securing Proxy Mobile IPv6 signaling messages, 642 either based on a static configuration or after a dynamic negotiation 643 using any standard security negotiation protocols. As in Mobile IPv6 644 [RFC-3775], the use of IPsec for protecting mobile node's data 645 traffic is optional. 647 IPsec ESP [RFC-4303] in transport mode with mandatory integrity 648 protection SHOULD be used for protecting the signaling messages. 649 Confidentiality protection of these messages is not required. 651 IPsec ESP [RFC-4303] in tunnel mode MAY be used to protect the mobile 652 node's tunneled data traffic, if protection of data traffic is 653 required. 655 IKEv2 [RFC-4306] SHOULD be used to set up security associations 656 between the mobile access gateway and the local mobility anchor to 657 protect the Proxy Binding Update and Proxy Binding Acknowledgement 658 messages. The mobile access gateway and the local mobility anchor 659 can use any of the authentication mechanisms, as specified in [RFC- 660 4306], for mutual authentication. 662 The Mobile IPv6 specification [RFC-3775] requires the home agent to 663 prevent a mobile node from creating security associations or creating 664 binding cache entries for another mobile node's home address. In the 665 protocol described in this document, the mobile node is not involved 666 in creating security associations for protecting the signaling 667 messages or sending binding updates. Therefore, the local mobility 668 anchor MUST restrict the creation and manipulation of proxy bindings 669 to specifically authorized mobile access gateways and prefixes. The 670 local mobility anchor MUST be locally configurable to authorize such 671 specific combinations. Additional mechanisms such as a policy store 672 or AAA may be employed, but these are outside the scope of this 673 specification. 675 Unlike in Mobile IPv6 [RFC-3775], these signaling messages do not 676 carry either the Home Address destination option or the Type 2 677 Routing header and hence the policy entries and security association 678 selectors stay the same and require no special IPsec related 679 considerations. 681 4.1. Peer Authorization Database (PAD) Example Entries 683 This section describes PAD entries [RFC-4301] on the mobile access 684 gateway and the local mobility anchor. The PAD entries are only 685 example configurations. Note that the PAD is a logical concept and a 686 particular mobile access gateway or a local mobility anchor 687 implementation can implement the PAD in any implementation specific 688 manner. The PAD state may also be distributed across various 689 databases in a specific implementation. 691 mobile access gateway PAD: 692 - IF remote_identity = lma_identity_1 693 Then authenticate (shared secret/certificate/EAP) 694 and authorize CHILD_SA for remote address lma_address_1 696 local mobility anchor PAD: 697 - IF remote_identity = mag_identity_1 698 Then authenticate (shared secret/certificate/EAP) 699 and authorize CHILD_SAs for remote address mag_address_1 701 Figure 4: PAD Entries 703 The list of authentication mechanisms in the above examples is not 704 exhaustive. There could be other credentials used for authentication 705 stored in the PAD. 707 4.2. Security Policy Database (SPD) Example Entries 709 This section describes the security policy entries [RFC-4301] on the 710 mobile access gateway and the local mobility anchor required to 711 protect the Proxy Mobile IPv6 signaling messages. The SPD entries 712 are only example configurations. A particular mobile access gateway 713 or a local mobility anchor implementation could configure different 714 SPD entries as long as they provide the required security. 716 In the examples shown below, the identity of the mobile access 717 gateway is assumed to be mag_1, the address of the mobile access 718 gateway is assumed to be mag_address_1, and the address of the local 719 mobility anchor is assumed to be lma_address_1. 721 mobile access gateway SPD-S: 722 - IF local_address = mag_address_1 & 723 remote_address = lma_address_1 & 724 proto = MH & local_mh_type = BU & remote_mh_type = BA 725 Then use SA ESP transport mode 726 Initiate using IDi = mag_1 to address lma_address_1 728 local mobility anchor SPD-S: 729 - IF local_address = lma_address_1 & 730 remote_address = mag_address_1 & 731 proto = MH & local_mh_type = BA & remote_mh_type = BU 732 Then use SA ESP transport mode 734 Figure 5: SPD Entries 736 5. Local Mobility Anchor Operation 738 The local mobility anchor MUST support the home agent function as 739 defined in [RFC-3775] and additionally the extensions defined in this 740 specification. A home agent with these modifications and enhanced 741 capabilities for supporting the Proxy Mobile IPv6 protocol is 742 referred to as a local mobility anchor. 744 This section describes the operational details of the local mobility 745 anchor. 747 5.1. Extensions to Binding Cache Entry Data Structure 749 Every local mobility anchor MUST maintain a Binding Cache entry for 750 each currently registered mobile node. Binding Cache entry is a 751 conceptual data structure, described in Section 9.1 of [RFC-3775]. 753 For supporting this specification, the Binding Cache Entry data 754 structure needs to be extended with the following additional fields. 756 o A flag indicating whether or not this Binding Cache entry is 757 created due to a proxy registration. This flag is set to value 1 758 for Binding Cache entries that are proxy registrations and is set 759 to value 0 for all other entries. 761 o The identifier of the registered mobile node, MN-Identifier. This 762 identifier is obtained from the Mobile Node Identifier Option 763 [RFC-4283] present in the received Proxy Binding Update request. 765 o The link-layer identifier of the mobile node's connected interface 766 on the access link. This identifier can be acquired from the 767 Mobile Node Link-layer Identifier option, present in the received 768 Proxy Binding Update request. If the option was not present in 769 the request, this variable length field MUST be set to two 770 (octets) and MUST be initialized to a value of ALL_ZERO. 772 o The link-local address of the mobile access gateway on the point- 773 to-point link shared with the mobile node. This is generated by 774 the local mobility anchor after accepting the initial Proxy 775 Binding Update request. 777 o List of IPv6 home network prefixes assigned to the mobile node's 778 connected interface. The home network prefix(es) may have been 779 statically configured in the mobile node's policy profile, or, 780 they may have been dynamically allocated by the local mobility 781 anchor. Each one of these prefix entries will also includes the 782 corresponding prefix length. 784 o The tunnel interface identifier (If-Id) of the bi-directional 785 tunnel between the local mobility anchor and the mobile access 786 gateway where the mobile node is currently anchored. This is 787 internal to the local mobility anchor. The tunnel interface 788 identifier is acquired during the tunnel creation. 790 o The access technology type, using which the mobile node is 791 currently attached. This is obtained from the Access Technology 792 Type option, present in the Proxy Binding Update request. 794 o The 64-bit timestamp value of the most recently accepted Proxy 795 Binding Update request sent for this mobile node. This is the 796 time-of-day on the local mobility anchor, when the message was 797 received. If the Timestamp option is not present in the Proxy 798 Binding Update request (i.e., when the sequence number based 799 scheme is in use), the value MUST be set to ALL_ZERO. 801 Typically, any one of the mobile node's home network prefixes from 802 its mobility session is the key for locating a Binding Cache entry in 803 all cases except when there has been an handoff of the mobile node's 804 session to a new mobile access gateway and that mobile access gateway 805 is unaware of the home network prefix(es) assigned to that mobility 806 session. In such handoff cases, the Binding Cache entry can be 807 located under the considerations specified in Section 5.4.1. 809 5.2. Supported Home Network Prefix Models 811 This specification supports the Per-MN-Prefix model and does not 812 support the Shared-Prefix model. As per the Per-MN-Prefix model, a 813 prefix assigned to a mobile node is for that mobile node's exclusive 814 use and no other node shares an address from that prefix (other than 815 the Subnet-Router anycast address [RFC-4291] which is used by the 816 mobile access gateway hosting that prefix on that link). 818 There may be more than one prefix assigned to a given interface of 819 the mobile node and all of those assigned prefixes are unique to that 820 mobile node and all are part of one mobility session. If the mobile 821 node attaches to the Proxy Mobile IPv6 domain through multiple 822 interfaces and simultaneously, each of the attached interfaces will 823 be assigned one or more unique prefixes and all of the assigned 824 prefixes to a given interface will be managed under a different 825 mobility session. 827 The mobile node's home network prefix(es) assigned to a given 828 interface of a mobile node (part of a mobility session) will be 829 hosted on the access link where the mobile node is attached (using 830 that interface). The local mobility anchor is not required to 831 perform any proxy ND operations [RFC-4861] for defending the mobile 832 node's home address(es), as the prefixes are not locally hosted on 833 the local mobility anchor. However, from the routing perspective, 834 the home network prefix(es) is topologically anchored on the local 835 mobility anchor. 837 5.3. Signaling Considerations 839 This section provides the rules for processing the signaling 840 messages. The processing rules specified in this section and other 841 related sections are chained and are in a specific order. When 842 applying these considerations for processing the signaling messages, 843 the specified order MUST be maintained. 845 5.3.1. Processing Binding Registrations 847 1. The received Proxy Binding Update message (a Binding Update 848 message with the 'P' flag set to value of 1, format specified in 849 Section 8.1) MUST be authenticated as described in Section 4. 850 When IPsec is used for message authentication, the SPI in the 851 IPsec header [RFC-4306] of the received packet is needed for 852 locating the security association, for authenticating the Proxy 853 Binding Update message. 855 2. The local mobility anchor MUST observe the rules described in 856 Section 9.2 of [RFC-3775] when processing Mobility Header in the 857 received Proxy Binding Update request. 859 3. The local mobility anchor MUST ignore the check, specified in 860 Section 10.3.1 of [RFC-3775], related to the presence of Home 861 Address destination option in the Proxy Binding Update request. 863 4. The local mobility anchor MUST identify the mobile node from the 864 identifier present in the Mobile Node Identifier option [RFC- 865 4283] of the Proxy Binding Update request. If the Mobile Node 866 Identifier option is not present in the Proxy Binding Update 867 request, the local mobility anchor MUST reject the request and 868 send a Proxy Binding Acknowledgement message with Status field 869 set to MISSING_MN_IDENTIFIER_OPTION (Missing mobile node 870 identifier option) and the identifier in the Mobile Node 871 Identifier Option carried in the message MUST be set to a zero 872 length identifier. 874 5. The local mobility anchor MUST apply the required policy checks, 875 as explained in Section 4, to verify the sender is a trusted 876 mobile access gateway, authorized to send Proxy Binding Update 877 requests on behalf of this mobile node. 879 6. If the local mobility anchor determines that the requesting node 880 is not authorized to send Proxy Binding Update requests for the 881 identified mobile node, it MUST reject the request and send a 882 Proxy Binding Acknowledgement message with Status field set to 883 MAG_NOT_AUTHORIZED_FOR_PROXY_REG (not authorized to send proxy 884 binding registrations). 886 7. If the local mobility anchor cannot identify the mobile node 887 based on the identifier present in the Mobile Node Identifier 888 option [RFC-4283] of Proxy Binding Update request, it MUST 889 reject the request and send a Proxy Binding Acknowledgement 890 message with Status field set to NOT_LMA_FOR_THIS_MOBILE_NODE 891 (Not local mobility anchor for this mobile node). 893 8. If the local mobility anchor determines that the mobile node is 894 not authorized for the network-based mobility management 895 service, it MUST reject the request and send a Proxy Binding 896 Acknowledgement message with Status field set to 897 PROXY_REG_NOT_ENABLED (Proxy Registration not enabled). 899 9. The local mobility anchor MUST apply the considerations 900 specified in Section 5.5, for processing the Sequence Number 901 field and the Timestamp option (if present), in the Proxy 902 Binding Update request. 904 10. If there is no Home Network Prefix option(s) (with any value) 905 present in the Proxy Binding Update request, the local mobility 906 anchor MUST reject the request and send a Proxy Binding 907 Acknowledgement message with Status field set to 908 MISSING_HOME_NETWORK_PREFIX_OPTION (Missing home network prefix 909 option). 911 11. If the Handoff Indicator option is not present in the Proxy 912 Binding Update request, the local mobility anchor MUST reject 913 the request and send a Proxy Binding Acknowledgement message 914 with Status field set to MISSING_HANDOFF_INDICATOR_OPTION 915 (Missing handoff indicator option). 917 12. If the Access Technology Type option is not present in the Proxy 918 Binding Update request, the local mobility anchor MUST reject 919 the request and send a Proxy Binding Acknowledgement message 920 with Status field set to MISSING_ACCESS_TECH_TYPE_OPTION 921 (Missing access technology type option). 923 13. Considerations specified in Section 5.4.1 MUST be applied for 924 performing the Binding Cache entry existence test. If those 925 checks specified in Section 5.4.1, result in associating the 926 received Proxy Binding Update request to a new mobility session 927 creation request, considerations from Section 5.3.2 (Initial 928 Binding Registration - New Mobility Session), MUST be applied. 929 If those checks result in associating the request to an existing 930 mobility session, the following checks determine the next set of 931 processing rules that needs to be applied. 933 * If the Handoff Indicator field in the Handoff Indicator 934 option present in the request is set to a value of 5 (Handoff 935 state not changed), considerations from Section 5.3.3 936 (Binding Lifetime Extension- No handoff) MUST be applied. 938 * If the received Proxy Binding Update request has the lifetime 939 value of zero, considerations from Section 5.3.5 (Binding De- 940 Registration) MUST be applied. 942 * For all other cases, considerations from Section 5.3.4 943 (Binding Lifetime Extension - After handoff) MUST be applied. 945 14. When sending the Proxy Binding Acknowledgement message with any 946 Status field value, the message MUST be constructed as specified 947 in Section 5.3.6. 949 5.3.2. Initial Binding Registration (New Mobility Session) 951 1. If there is at least one instance of Home Network Prefix option 952 present in the Proxy Binding Update request with the prefix value 953 set to ALL_ZERO, the local mobility anchor MUST allocate one or 954 more home network prefix(es) to the mobile node and assign it to 955 the new mobility session created for the mobile node. The local 956 mobility anchor MUST ensure the allocated prefix(es) is not in 957 use by any other node or mobility session. The decision on how 958 many prefixes to be allocated for the attached interface, can be 959 based on a global policy or a policy specific to that mobile 960 node. However, when stateful address autoconfiguration using 961 DHCPv6 is supported on the link, considerations from Section 6.11 962 MUST be applied for the prefix assignment. 964 2. If the local mobility anchor is unable to allocate any home 965 network prefix for the mobile node, it MUST reject the request 966 and send a Proxy Binding Acknowledgement message with Status 967 field set to 130 (Insufficient resources). 969 3. If there are one or more Home Network Prefix options present in 970 the Proxy Binding Update request (with each of the prefixes set 971 to a NON_ZERO value), the local mobility anchor before accepting 972 that request, MUST ensure each one of those prefixes is owned by 973 the local mobility anchor and further the mobile node is 974 authorized to use these prefixes. If the mobile node is not 975 authorized to use any one or more of those prefixes, the local 976 mobility anchor MUST reject the request and send a Proxy Binding 977 Acknowledgement message with Status field set to 978 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node not 979 authorized for one or more of the requesting home network 980 prefixes). 982 4. Upon accepting the request, the local mobility anchor MUST create 983 a Binding Cache entry for the mobile node. It must set the 984 fields in the Binding Cache entry to the accepted values for that 985 registration. 987 5. If there is no existing bi-directional tunnel to the mobile 988 access gateway that sent the request, the local mobility anchor 989 MUST establish a bi-directional tunnel to that mobile access 990 gateway. Considerations from Section 5.6.1 MUST be applied for 991 managing the dynamically created bi-directional tunnel. 993 6. The local mobility anchor MUST create a prefix route(s) over the 994 tunnel to the mobile access gateway for forwarding any traffic 995 received for the mobile node's home network prefix(es) associated 996 with this mobility session. The created tunnel and the routing 997 state MUST result in the forwarding behavior on the local 998 mobility anchor as specified in Section 5.6.2. 1000 7. The local mobility anchor MUST send the Proxy Binding 1001 Acknowledgement message with the Status field set to 0 (Proxy 1002 Binding Update Accepted). The message MUST be constructed as 1003 specified in Section 5.3.6. 1005 5.3.3. Binding Lifetime Extension (No handoff) 1007 1. Upon accepting the Proxy Binding Update request for extending the 1008 binding lifetime, received from the same mobile access gateway 1009 (if the Proxy-CoA address in the Binding Cache entry is the same 1010 as the Proxy-CoA address in the request) that last updated the 1011 binding, the local mobility anchor MUST update the Binding Cache 1012 entry with the accepted registration values. 1014 2. The local mobility anchor MUST send the Proxy Binding 1015 Acknowledgement message with the Status field set to 0 (Proxy 1016 Binding Update Accepted). The message MUST be constructed as 1017 specified in Section 5.3.6. 1019 5.3.4. Binding Lifetime Extension (After handoff) 1021 1. Upon accepting the Proxy Binding Update request for extending the 1022 binding lifetime, received from a new mobile access gateway (if 1023 the Proxy-CoA address in the Binding Cache entry does not match 1024 the Proxy-CoA address in the request) where the mobile node's 1025 session is handed off, the local mobility anchor MUST update the 1026 Binding Cache entry with the accepted registration values. 1028 2. The local mobility anchor MUST remove the previously created 1029 route(s) for the mobile node's home network prefix(es) associated 1030 with this mobility session. Additionally, if there are no other 1031 mobile node sessions sharing the dynamically created bi- 1032 directional tunnel to the previous mobile access gateway, the 1033 tunnel SHOULD be deleted applying considerations from section 1034 5.6.1 (if the tunnel is a dynamically created tunnel and not a 1035 fixed pre-established tunnel). 1037 3. If there is no existing bi-directional tunnel to the mobile 1038 access gateway that sent the request, the local mobility anchor 1039 MUST establish a bi-directional tunnel to that mobile access 1040 gateway. Considerations from Section 5.6.1 MUST be applied for 1041 managing the dynamically created bi-directional tunnel. 1043 4. The local mobility anchor MUST create prefix route(s) over the 1044 tunnel to the mobile access gateway for forwarding any traffic 1045 received for the mobile node's home network prefix(es) associated 1046 with that mobility session. The created tunnel and routing state 1047 MUST result in the forwarding behavior on the local mobility 1048 anchor as specified in Section 5.6.2. 1050 5. The local mobility anchor MUST send the Proxy Binding 1051 Acknowledgement message with the Status field set to 0 (Proxy 1052 Binding Update Accepted). The message MUST be constructed as 1053 specified in Section 5.3.6. 1055 5.3.5. Binding De-Registration 1057 1. If the received Proxy Binding Update request with the lifetime 1058 value of zero, has a Source Address in the IPv6 header (or the 1059 address in the Alternate Care-of Address option, if the option is 1060 present) different from what is present in the Proxy-CoA address 1061 field in the Binding Cache entry, the local mobility anchor MUST 1062 ignore the request. 1064 2. Upon accepting the Proxy Binding Update request with the lifetime 1065 value of zero, the local mobility anchor MUST wait for 1066 MinDelayBeforeBCEDelete amount of time, before it deletes the 1067 Binding Cache entry. However, it MUST send the Proxy Binding 1068 Acknowledgement message with the Status field set to 0 (Proxy 1069 Binding Update Accepted). The message MUST be constructed as 1070 specified in Section 5.3.6. 1072 * During this wait period, the local mobility anchor SHOULD drop 1073 the mobile node's data traffic. 1075 * During this wait period, if the local mobility anchor receives 1076 a valid Proxy Binding Update request for the same mobility 1077 session with the lifetime value of greater than zero, and if 1078 that request is accepted, then the Binding Cache entry MUST 1079 NOT be deleted, but must be updated with the newly accepted 1080 registration values and additionally the wait period should be 1081 ended. 1083 * By the end of this wait period, if the local mobility anchor 1084 did not receive any valid Proxy Binding Update request for 1085 this mobility session, then it MUST delete the Binding Cache 1086 entry and remove the routing state created for that mobility 1087 session. 1089 5.3.6. Constructing the Proxy Binding Acknowledgement Message 1091 o The local mobility anchor when sending the Proxy Binding 1092 Acknowledgement message to the mobile access gateway MUST 1093 construct the message as specified below. 1095 IPv6 header (src=LMAA, dst=Proxy-CoA) 1096 Mobility header 1097 - BA /* P flag must be set to value of 1 */ 1098 Mobility Options 1099 - Mobile Node Identifier Option (mandatory) 1100 - Home Network Prefix option(s) (mandatory) 1101 - Handoff Indicator option (mandatory) 1102 - Access Technology Type option (mandatory) 1103 - Timestamp Option (optional) 1104 - Mobile Node Link-layer Identifier option (optional) 1105 - Link-local Address option (optional) 1107 Figure 6: Proxy Binding Acknowledgement message format 1109 o The Source Address field in the IPv6 header of the message MUST be 1110 set to the destination address of the received Proxy Binding 1111 Update request. 1113 o The Destination Address field in the IPv6 header of the message 1114 MUST be set to the source address of the received Proxy Binding 1115 Update request. When there is no Alternate Care-of Address option 1116 present in the request, the destination address is the same as the 1117 Proxy-CoA address, otherwise, the address may not be the same as 1118 the Proxy-CoA. 1120 o The Mobile Node Identifier option [RFC-4283] MUST be present. The 1121 identifier field in the option MUST be copied from the Mobile Node 1122 Identifier option in the received Proxy Binding Update request. 1123 If the option was not present in the request, the identifier in 1124 the option MUST be set to a zero length identifier. 1126 o At least one Home Network Prefix option MUST be present. 1128 * If the Status field is set to a value greater than or equal to 1129 128, i.e., if the binding request is rejected, all the Home 1130 Network Prefix options that were present in the request (along 1131 with their prefix values) MUST be present in the reply. But, 1132 if there was no Home Network Prefix option present in the 1133 request, then there MUST be only one Home Network Prefix option 1134 and with the value in the option set to ALL_ZERO. 1136 * For all other cases, there MUST be a Home Network Prefix option 1137 for each of the assigned home network prefixes (for that 1138 mobility session) and with the prefix value in the option set 1139 to the allocated prefix value. 1141 o The Handoff Indicator option MUST be present. The handoff 1142 indicator field in the option MUST be copied from the Handoff 1143 Indicator option in the received Proxy Binding Update request. If 1144 the option was not present in the request, the value in the option 1145 MUST be set to zero. 1147 o The Access Technology Type option MUST be present. The access 1148 technology type field in the option MUST be copied from the Access 1149 Technology Type option in the received Proxy Binding Update 1150 request. If the option was not present in the request, the value 1151 in the option MUST be set to zero. 1153 o The Timestamp option MUST be present only if the same option was 1154 present in the received Proxy Binding Update request and MUST NOT 1155 be present otherwise. Considerations from Section 5.5 must be 1156 applied for constructing the Timestamp option. 1158 o The Mobile Node Link-layer Identifier option MUST be present only 1159 if the same option was present in the received Proxy Binding 1160 Update request and MUST NOT be present otherwise. The link-layer 1161 identifier value MUST be copied from the Mobile Node Link-layer 1162 Identifier option present in the received Proxy Binding Update 1163 request. 1165 o The Link-local Address option MUST be present only if the same 1166 option was present in the received Proxy Binding Update request 1167 and MUST NOT be present otherwise. 1169 * If the received Proxy Binding Update request has the Link-local 1170 Address option with any value other than ALL_ZERO, the same 1171 value MUST be copied to the Link-local Address field of the 1172 Binding Cache entry and it must also be copied to the Link- 1173 local Address option in the reply. 1175 * If there is no existing Binding Cache entry (i.e., if this is a 1176 request for a new mobility session), then the local mobility 1177 anchor MUST generate the link-local address that the mobile 1178 access gateway can use on the point-to-point link shared with 1179 the mobile node and the same must be copied to the Link-local 1180 Address field of the Binding Cache entry and it must also be 1181 copied to the Link-local Address option in the reply. 1183 * For all other cases, the link-local address in the option MUST 1184 be copied from the Link-local Address field of the Binding 1185 Cache entry. 1187 o If IPsec is used for protecting the signaling messages, the 1188 message MUST be protected, using the security association existing 1189 between the local mobility anchor and the mobile access gateway. 1191 o Unlike in Mobile IPv6 [RFC-3775], the Type 2 Routing header MUST 1192 NOT be present in the IPv6 header of the packet. 1194 5.4. Multihoming Support 1196 This specification allows mobile nodes to connect to a Proxy Mobile 1197 IPv6 domain through multiple interfaces for simultaneous access. 1198 Following are the key aspects of this multihoming support. 1200 o When a mobile node connects to a Proxy Mobile IPv6 domain through 1201 multiple interfaces for simultaneous access, the local mobility 1202 anchor MUST allocate a mobility session for each of the attached 1203 interfaces. Each of the mobility session should be managed under 1204 a separate Binding Cache entry and with its own lifetime. 1206 o The local mobility anchor MAY allocate more than one home network 1207 prefix for a given interface of the mobile node. However, all the 1208 prefixes associated with a given interface MUST be managed as part 1209 of one mobility session, associated with that interface. 1211 o The local mobility anchor MUST allow for an handoff between two 1212 different interfaces of a mobile node. In such a scenario, all 1213 the home network prefix(es) associated with one interface (part of 1214 one mobility session) will be associated with a different 1215 interface of the mobile node). The decision on when to create a 1216 new mobility session and when to update an existing mobility 1217 session MUST be based on the Handover hint present in the Proxy 1218 Binding Update message and under the considerations specified in 1219 this section. 1221 5.4.1. Binding Cache entry lookup considerations 1223 There can be multiple Binding Cache entries for a given mobile node. 1224 When doing a lookup for a mobile node's Binding Cache entry for 1225 processing a received Proxy Binding Update request message, the local 1226 mobility anchor MUST apply the following multihoming considerations 1227 (in the below specified order, starting with Section 5.4.1.1). These 1228 rules are chained with the processing rules specified in Section 5.3. 1230 5.4.1.1. Home Network Prefix Option (NON_ZERO Value) present in the 1231 request 1233 +=====================================================================+ 1234 | Registration/De-Registration Message | 1235 +=====================================================================+ 1236 | At least one HNP Option with NON_ZERO Value | 1237 +=====================================================================+ 1238 | ATT | 1239 +=====================================================================+ 1240 | MN-LL-Identifier Opt Present | MN-LL-Identifier Opt Not Present | 1241 +=====================================================================+ 1242 | HI | 1243 +==================================+==================================+ 1244 | BCE Lookup Key: Any of the Home Network Prefixes from the request | 1245 +=====================================================================+ 1247 Figure 7: BCE lookup using home network prefix 1249 If there is at least one Home Network Prefix option present in the 1250 request with NON_ZERO prefix value, the following considerations MUST 1251 be applied. If there are more than one instances of the Home Network 1252 Prefix option, any one of the Home Network Prefix options present in 1253 the request (with NON_ZERO prefix value) can be used for locating the 1254 Binding Cache entry. 1256 1. The local mobility anchor MUST verify if there is an existing 1257 Binding Cache entry with one of its home network prefixes 1258 matching the prefix value in one of the Home Network Prefix 1259 options of the received Proxy Binding Update request. [BCE(HNP) 1260 equals PBU(HNP)] 1262 2. If there does not exist a Binding Cache entry (with one of its 1263 home network prefixes in the Binding Cache entry matching the 1264 prefix value in one of the Home Network Prefix options of the 1265 received Proxy Binding Update request), the request MUST be 1266 considered as a request for creating a new mobility session. 1267 [BCE(HNP) not equals PBU(HNP)] 1269 3. If there exists a Binding Cache entry (with one of its home 1270 network prefixes in the Binding Cache entry matching the prefix 1271 value in one of the Home Network Prefix options of the received 1272 Proxy Binding Update request) but if the mobile node identifier 1273 in the entry does not match the mobile node identifier in the 1274 Mobile Node Identifier option of the received Proxy Binding 1275 Update request, the local mobility anchor MUST reject the request 1276 with the Status field value set to 1277 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX (mobile node is not 1278 authorized for one or more of the requesting home network 1279 prefixes). [BCE(MN-Identifier) not equals PBU(MN-Identifier)] 1281 4. If there exists a Binding Cache entry (matching MN-Identifier and 1282 one of its home network prefixes in the Binding Cache entry 1283 matching the prefix value in one of the Home Network Prefix 1284 options of the received Proxy Binding Update request), but if all 1285 the prefixes in the request do not match all the prefixes in the 1286 Binding Cache entry, or if they do not match in count, then the 1287 local mobility anchor MUST reject the request with the Status 1288 field value set to BCE_PBU_PREFIX_SET_DO_NOT_MATCH (all the home 1289 network prefixes listed in the BCE do not match all the prefixes 1290 in the received PBU). [BCE(HNP1, HNP2, .. HNPn) not equals 1291 PBU(HNP1, HNP2, ..HNPn)] OR [BCE(Count(HNP))] not equals 1292 PBU(Count(HNP))] 1294 5. If there exists a Binding Cache entry (matching MN-Identifier and 1295 all the home network prefixes in the Binding Cache entry matching 1296 all the home network prefixes in the received Proxy Binding 1297 Update request) and if any one or more of these below stated 1298 conditions match, the request MUST be considered as a request for 1299 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1300 PBU(MN-Identifier)] AND [BCE(HNP1, HNP2, .. HNPn) equals 1301 PBU(HNP1, HNP2, ..HNPn)] 1303 * If the Handoff Indicator field in the Handoff Indicator option 1304 present in the request is set to a value of 2 (Handoff between 1305 two different interfaces of the mobile node). [PBU(HI) equals 1306 2] 1308 * If there is no Mobile Node Link-layer Identifier option 1309 present in the request, the link-layer identifier value in the 1310 Binding Cache entry is set to ALL_ZERO, the access technology 1311 type field in the Access Technology Type option present in the 1312 request matches the access technology type in the Binding 1313 Cache entry and if the Handoff Indicator field in the Handoff 1314 Indicator option present in the request is set to a value of 3 1315 (Handoff between mobile access gateways for the same 1316 interface). 1318 * If the Proxy-CoA address in the Binding Cache entry matches 1319 the source address of the request (or the address in the 1320 alternate Care-of Address option, if the option is present) 1321 and if the access technology type field in the Access 1322 Technology Type option present in the request matches the 1323 access technology type in the Binding Cache entry. 1324 [BCE(Proxy-CoA, ATT) equals PBU(Proxy-CoA, ATT)]. 1326 6. For all other cases, the message MUST be considered as a request 1327 for creating a new mobility session. 1329 5.4.1.2. Mobile Node Link-layer Identifier Option present in the 1330 request 1332 +=====================================================================+ 1333 | Registration/De-Registration Message | 1334 +=====================================================================+ 1335 | HNP option with ALL_ZERO Value | 1336 +=====================================================================+ 1337 | ATT | 1338 +=====================================================================+ 1339 | MN-LL-Identifier Option Present (NON_ZERO Value) | 1340 +=====================================================================+ 1341 | HI | 1342 +==================================+==================================+ 1343 | BCE Lookup Keys: (MN-Identifier + ATT + MN-LL-Identifier) | 1344 +=====================================================================+ 1346 Figure 8: BCE Lookup using Link-layer Identifier 1348 1. The local mobility anchor MUST verify if there is an existing 1349 Binding Cache entry, with the mobile node identifier matching the 1350 identifier in the received Mobile Node Identifier option, access 1351 technology type matching the value in the received Access 1352 Technology Type option and the link-layer identifier value 1353 matching the identifier in the received Mobile Node Link-layer 1354 Identifier option. [BCE(MN-Identifier, ATT, MN-LL-Identifier) 1355 equals PBU(MN-Identifier, ATT, MN-LL-Identifier)] 1357 2. If there exists a Binding Cache entry (matching MN-Identifier, 1358 ATT and MN-LL-Identifier), the request MUST be considered as a 1359 request for updating that Binding Cache entry. 1361 3. If there does not exist a Binding Cache entry (matching MN- 1362 Identifier, ATT and MN-LL-Identifier) and the Handoff Indicator 1363 field in the Handoff Indicator option present in the request is 1364 set to a value of 2 (Handoff between two different interfaces of 1365 the mobile node). The local mobility anchor MUST apply the 1366 following additional considerations. [PBU(HI) equals 2] 1368 * The local mobility anchor MUST verify if there exists one and 1369 only one Binding Cache entry with the mobile node identifier 1370 matching the identifier in the Mobile Node Identifier option 1371 present in the request and for any link-layer identifier 1372 value. If there exists only one such entry (matching the MN- 1373 Identifier), the request MUST be considered as a request for 1374 updating that Binding Cache entry. [BCE(MN-Identifier) equals 1375 PBU(MN-Identifier)] 1377 4. If there does not exist a Binding Cache entry (matching MN- 1378 Identifier, ATT and MN-LL-Identifier) and if the Handoff 1379 Indicator field in the Handoff Indicator option present in the 1380 request is set to a value of 4 (Handoff state unknown), the local 1381 mobility anchor MUST apply the following additional 1382 considerations. 1384 * The local mobility anchor MUST verify if there exists one and 1385 only one Binding Cache entry with the mobile node identifier 1386 matching the identifier in the Mobile Node Identifier option 1387 present in the request and for any link-layer identifier 1388 value. If there exists only one such entry (matching the MN- 1389 Identifier), the local mobility anchor SHOULD wait till the 1390 existing Binding Cache entry is de-registered by the 1391 previously serving mobile access gateway, before the request 1392 can be considered as a request for updating that Binding Cache 1393 entry. However, if there is no de-registration message that 1394 is received within MaxDelayBeforeNewBCEAssign amount of time, 1395 the local mobility anchor upon accepting the request MUST 1396 consider the request as a request for creating a new mobility 1397 session. The local mobility anchor MAY also choose to create 1398 a new mobility session and without waiting for a de- 1399 registration message and this should be configurable on the 1400 local mobility anchor. 1402 5. For all other cases, the message MUST be considered as a request 1403 for creating a new mobility session. 1405 5.4.1.3. Mobile Node Link-layer Identifier Option not present in the 1406 request 1408 +=====================================================================+ 1409 | Registration/De-Registration Message | 1410 +=====================================================================+ 1411 | HNP option with ALL_ZERO Value | 1412 +=====================================================================+ 1413 | ATT | 1414 +=====================================================================+ 1415 | MN-LL-Identifier Option Not Present | 1416 +=====================================================================+ 1417 | HI | 1418 +==================================+==================================+ 1419 | BCE Lookup Key: (MN-Identifier) | 1420 +=====================================================================+ 1422 Figure 9: BCE Lookup using Mobile Node Identifier 1424 1. The local mobility anchor MUST verify if there exists one and 1425 only one Binding Cache entry with the mobile node identifier 1426 matching the identifier in the Mobile Node Identifier option 1427 present in the request. 1429 2. If there exists only one such entry (matching the MN-Identifier) 1430 and the Handoff Indicator field in the Handoff Indicator option 1431 present in the request is set to a value of 2 (Handoff between 1432 two different interfaces of the mobile node) or set to a value of 1433 3 (Handoff between mobile access gateways for the same 1434 interface), then the request MUST be considered as a request for 1435 updating that Binding Cache entry. [PBU(HI) equals 2] or 1436 [PBU(HI) equals 3] 1438 3. If there exists only one such entry (matching the MN-Identifier) 1439 and the Handoff Indicator field in the Handoff Indicator option 1440 present in the request is set to a value of 4 (Handoff state 1441 unknown), the local mobility anchor SHOULD wait till the existing 1442 Binding Cache entry is de-registered by the previously serving 1443 mobile access gateway, before the request can be considered as a 1444 request for updating that Binding Cache entry. However, if there 1445 is no de-registration message that is received within 1446 MaxDelayBeforeNewBCEAssign amount of time, the local mobility 1447 anchor upon accepting the request MUST consider the request as a 1448 request for creating a new mobility session. The local mobility 1449 anchor MAY also choose to create a new mobility session and 1450 without waiting for a de-registration message and this should be 1451 configurable on the local mobility anchor. 1453 4. For all other cases, the message MUST be considered as a request 1454 for creating a new mobility session. 1456 5.5. Timestamp Option for Message Ordering 1458 Mobile IPv6 [RFC-3775] uses the Sequence Number field in binding 1459 registration messages as a way for the home agent to process the 1460 binding updates in the order they were sent by a mobile node. The 1461 home agent and the mobile node are required to manage this counter 1462 over the lifetime of a binding. However, in Proxy Mobile IPv6, as 1463 the mobile node moves from one mobile access gateway to another and 1464 in the absence of mechanisms such as context transfer between the 1465 mobile access gateways, the serving mobile access gateway will be 1466 unable to determine the sequence number that it needs to use in the 1467 signaling messages. Hence, the sequence number scheme, as specified 1468 in [RFC-3775], will be insufficient for Proxy Mobile IPv6. 1470 If the local mobility anchor cannot determine the sending order of 1471 the received binding registration messages, it may potentially 1472 process an older message sent by a mobile access gateway where the 1473 mobile node was previously anchored, but delivered out of order, 1474 resulting in incorrectly updating the mobile node's Binding Cache 1475 entry and creating a routing state for tunneling the mobile node's 1476 traffic to the previously serving gateway. 1478 For solving this problem, this specification adopts two alternative 1479 solutions. One is based on timestamps and the other based on 1480 sequence numbers, as defined in [RFC-3775]. 1482 The basic principle behind the use of timestamps in binding 1483 registration messages is that the node generating the message inserts 1484 the current time-of-day, and the node receiving the message checks 1485 that this timestamp is greater than all previously accepted 1486 timestamps. The timestamp based solution may be used when the 1487 serving mobile access gateways in a Proxy Mobile IPv6 domain do not 1488 have the ability to obtain the last sequence number that was sent in 1489 a binding registration message for updating a given mobile node's 1490 binding. 1492 If the mechanism used for clock synchronization in the Proxy Mobile 1493 IPv6 domain cannot assure a clock drift between the two mobile access 1494 gateways (between which the mobile node did a handoff), which is not 1495 less than half the total time it took for the mobile node to roam 1496 between the two mobile access gateways and the time it took for the 1497 serving mobile access gateway to detect the node on its access link 1498 and construct the Proxy Binding Update message, then this solution 1499 will not predictably work in all cases and hence SHOULD NOT be used. 1501 As an alternative to the Timestamp based approach, the specification 1502 also allows the use of Sequence Number based scheme, as specified in 1503 [RFC-3775]. However, for this scheme to work, the serving mobile 1504 access gateway in a Proxy Mobile IPv6 domain MUST have the ability to 1505 obtain the last sequence number that was sent in a binding 1506 registration message. The sequence number MUST be maintained on a 1507 per mobile node basis and MUST be available to the serving mobile 1508 access gateway. This may be achieved by using context transfer 1509 schemes or by maintaining the sequence number in a policy store. 1510 However, the specific details on how the mobile node's sequence 1511 number is made available to the serving mobile access gateway prior 1512 to sending the binding registration messages is outside the scope of 1513 this document." 1515 Using the Timestamps based approach: 1517 1. A local mobility anchor implementation MUST support the Timestamp 1518 option. If the Timestamp option is present in the received Proxy 1519 Binding Update request message, then the local mobility anchor 1520 MUST include a valid Timestamp option in the Proxy Binding 1521 Acknowledgement message that it sends to the mobile access 1522 gateway. 1524 2. All the mobility entities in a Proxy Mobile IPv6 domain that are 1525 exchanging binding registration messages using the Timestamp 1526 option MUST have adequately synchronized time-of-day clocks. 1528 This is the essential requirement for this solution to work. If 1529 this requirement is not met, the solution will not predictably 1530 work in all cases. 1532 3. The mobility entities in a Proxy Mobile IPv6 domain SHOULD 1533 synchronize their clocks to a common time source. For 1534 synchronizing the clocks, the nodes MAY use the Network Time 1535 Protocol [RFC-4330]. Deployments MAY also adopt other approaches 1536 suitable for that specific deployment. Alternatively, if there 1537 is mobile node generated timestamp that is increasing at every 1538 attachment to the access link and if that timestamp is available 1539 to the mobile access gateway (Ex: The timestamp option in the 1540 SEND messages that the mobile node sends), the mobile access 1541 gateway can use this timestamp or sequence number in the Proxy 1542 Binding Update messages and does not have to depend on any 1543 external clock source. However, the specific details on how this 1544 is achieved is outside the scope of this document. 1546 4. When generating the timestamp value for building the Timestamp 1547 option, the mobility entities MUST ensure that the generated 1548 timestamp is the elapsed time past the same reference epoch, as 1549 specified in the format for the Timestamp option (Section 8.8). 1551 5. If the Timestamp option is present in the received Proxy Binding 1552 Update message, the local mobility anchor MUST ignore the 1553 sequence number field in the message. However, it MUST copy the 1554 sequence number from the received Proxy Binding Update message to 1555 the Proxy Binding Acknowledgement message. 1557 6. Upon receipt of a Proxy Binding Update message with the Timestamp 1558 option, the local mobility anchor MUST check the timestamp field 1559 for validity. In order for it to be considered valid, the 1560 timestamp value contained in the Timestamp option MUST be close 1561 enough (within TimestampValidityWindow amount of time difference) 1562 to the local mobility anchor's time-of-day clock and the 1563 timestamp MUST be greater than all previously accepted timestamps 1564 in the Proxy Binding Update messages sent for that mobile node. 1565 However, if the flag MobileNodeGeneratedTimestampInUse is set to 1566 value of 1, this check MUST NOT be performed. 1568 7. If the timestamp value in the received Proxy Binding Update is 1569 valid (validity as specified in the above considerations) or if 1570 the flag MobileNodeGeneratedTimestampInUse is set to value of 1, 1571 the local mobility anchor MUST return the same timestamp value in 1572 the Timestamp option included in the Proxy Binding 1573 Acknowledgement message that it sends to the mobile access 1574 gateway. 1576 8. If the timestamp value in the received Proxy Binding Update is 1577 lower than the previously accepted timestamp in the Proxy Binding 1578 Update messages sent for that mobility binding, the local 1579 mobility anchor MUST reject the Proxy Binding Update request and 1580 send a Proxy Binding Acknowledgement message with Status field 1581 set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED (Timestamp lower than 1582 previously accepted timestamp). The message MUST also include 1583 the Timestamp option with the value set to the current time-of- 1584 day on the local mobility anchor. 1586 9. If the timestamp value in the received Proxy Binding Update is 1587 not valid (validity as specified in the above considerations), 1588 the local mobility anchor MUST reject the Proxy Binding Update 1589 and send a Proxy Binding Acknowledgement message with Status 1590 field set to TIMESTAMP_MISMATCH (Timestamp mismatch). The 1591 message MUST also include the Timestamp option with the value set 1592 to the current time-of-day on the local mobility anchor. 1594 Using the Sequence Number based approach: 1596 1. If the Timestamp option is not present in the received Proxy 1597 Binding Update request, the local mobility anchor MUST fall back 1598 to the Sequence Number based scheme. It MUST process the 1599 sequence number field as specified in [RFC-3775]. Also, it MUST 1600 NOT include the Timestamp option in the Proxy Binding 1601 Acknowledgement messages that it sends to the mobile access 1602 gateway. 1604 2. An implementation MUST support the Sequence Number based scheme, 1605 as specified in [RFC-3775]. 1607 3. The Sequence Number based approach can be used only when there is 1608 some mechanism (such as context transfer procedure between mobile 1609 access gateways) that allows the serving mobile access gateway to 1610 obtain the last sequence number that was sent in a binding 1611 registration message for updating a given mobile node's binding. 1613 5.6. Routing Considerations 1615 5.6.1. Bi-Directional Tunnel Management 1617 The bi-directional tunnel MUST be used for routing the mobile node's 1618 data traffic between the mobile access gateway and the local mobility 1619 anchor. A tunnel hides the topology and enables a mobile node to use 1620 address(es) from its home network prefix(es) from any access link in 1621 that Proxy Mobile IPv6 domain. A tunnel may be created dynamically 1622 when needed and removed when not needed. However, implementations 1623 MAY choose to use static pre-established tunnels instead of 1624 dynamically creating and tearing them down on a need basis. The 1625 following considerations MUST be applied when using dynamic tunnels. 1627 o A bi-directional tunnel MUST be established between the local 1628 mobility anchor and the mobile access gateway with IPv6-in-IPv6 1629 encapsulation, as described in [RFC-2473]. The tunnel end points 1630 are the Proxy-CoA and LMAA. When using IPv4 transport, the end 1631 points of the tunnel are the IPv4-LMAA and IPv4-Proxy-CoA, as 1632 specified in [ID-IPV4-PMIP6]. 1634 o Implementations MAY use a software timer for managing the tunnel 1635 lifetime and a counter for keeping a count of all the mobile nodes 1636 that are sharing the tunnel. The timer value can be set to the 1637 accepted binding lifetime and can be updated after each periodic 1638 re-registration for extending the lifetime. If the tunnel is 1639 shared for multiple mobile nodes, the tunnel lifetime must be set 1640 to the highest binding lifetime that is granted to any one of 1641 those mobile nodes sharing that tunnel. 1643 o The tunnel SHOULD be deleted when either the tunnel lifetime 1644 expires or when there are no mobile nodes sharing the tunnel. 1646 5.6.2. Forwarding Considerations 1648 Intercepting Packets Sent to the Mobile Node's Home Network: 1650 o When the local mobility anchor is serving a mobile node, it MUST 1651 be able to receive packets that are sent to the mobile node's home 1652 network. In order for it to receive those packets, it MUST 1653 advertise a connected route in to the Routing Infrastructure for 1654 the mobile node's home network prefix(es) or for an aggregated 1655 prefix with a larger scope. This essentially enables IPv6 routers 1656 in that network to detect the local mobility anchor as the last- 1657 hop router for the mobile node's home network prefix(es). 1659 Forwarding Packets to the Mobile Node: 1661 o On receiving a packet from a correspondent node with the 1662 destination address matching a mobile node's home network 1663 prefix(es), the local mobility anchor MUST forward the packet 1664 through the bi-directional tunnel set up for that mobile node. 1666 o The format of the tunneled packet is shown below. Considerations 1667 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 1668 when using IPv4 transport, the format of the packet is as 1669 described in [ID-IPV4-PMIP6]. 1671 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1672 IPv6 header (src= CN, dst= MN-HOA ) /* Packet Header */ 1673 Upper layer protocols /* Packet Content*/ 1675 Figure 10: Tunneled Packet from LMA to MAG 1677 o The format of the tunneled packet is shown below, when payload 1678 protection using IPsec is enabled for the mobile node's data 1679 traffic. However, when using IPv4 transport, the format of the 1680 packet is as described in [ID-IPV4-PMIP6]. 1682 IPv6 header (src= LMAA, dst= Proxy-CoA /* Tunnel Header */ 1683 ESP Header in tunnel mode /* ESP Header */ 1684 IPv6 header (src= CN, dst= MN-HoA ) /* Packet Header */ 1685 Upper layer protocols /* Packet Content*/ 1687 Figure 11: Tunneled Packet from LMA to MAG with Payload Protection 1689 Forwarding Packets Sent by the Mobile Node: 1691 o All the reverse tunneled packets that the local mobility anchor 1692 received from the mobile access gateway, after removing the tunnel 1693 header MUST be routed to the destination specified in the inner 1694 packet header. These routed packets will have the source address 1695 field set to the mobile node's home address. Considerations from 1696 [RFC-2473] MUST be applied for IPv6 decapsulation. 1698 5.7. Local Mobility Anchor Address Discovery 1700 Dynamic Home Agent Address Discovery (DHAAD), as explained in Section 1701 10.5 of [RFC-3775], allows a mobile node to discover all the home 1702 agents on its home link by sending an ICMP Home Agent Address 1703 Discovery Request message to the Mobile IPv6 Home-Agents anycast 1704 address, derived from its home network prefix. 1706 The DHAAD message in the current form cannot be used in Proxy Mobile 1707 IPv6 for discovering the address of the mobile node's local mobility 1708 anchor. In Proxy Mobile IPv6, the local mobility anchor will not be 1709 able to receive any messages sent to the Mobile IPv6 Home-Agents 1710 anycast address corresponding to the mobile node's home network 1711 prefix(es), as the prefix(es) is not hosted on any of its interfaces. 1712 Further, the mobile access gateway will not predictably be able to 1713 locate the serving local mobility anchor that has the mobile node's 1714 binding cache entry. Hence, this specification does not support 1715 Dynamic Home Agent Address Discovery protocol. 1717 In Proxy Mobile IPv6, the address of the local mobility anchor 1718 configured to serve a mobile node can be discovered by the mobility 1719 entities in other ways. This may be a configured entry in the mobile 1720 node's policy profile, or it may be obtained through mechanisms 1721 outside the scope of this document. 1723 5.8. Mobile Prefix Discovery Considerations 1725 This specification does not support mobile prefix discovery. The 1726 mobile prefix discovery mechanism as specified in [RFC-3775] is not 1727 applicable to Proxy Mobile IPv6. 1729 5.9. Route Optimization Considerations 1731 The Route Optimization in Mobile IPv6, as defined in [RFC-3775], 1732 enables a mobile node to communicate with a correspondent node 1733 directly using its care-of address and further the Return Routability 1734 procedure enables the correspondent node to have reasonable trust 1735 that the mobile node is reachable at both its home address and 1736 care-of address. 1738 In Proxy Mobile IPv6, the mobile node is not involved in any IP 1739 mobility related signaling. The mobile node uses address(es) from 1740 its home network prefix(es) for all its communication and the Care-of 1741 address (Proxy-CoA) is not visible to the mobile node. Hence, the 1742 Return Routability procedure as defined in Mobile IPv6 [RFC-3775] 1743 cannot be used in Proxy Mobile IPv6. 1745 6. Mobile Access Gateway Operation 1747 The Proxy Mobile IPv6 protocol described in this document introduces 1748 a new functional entity, the Mobile Access Gateway (MAG). The mobile 1749 access gateway is the entity that is responsible for detecting the 1750 mobile node's movements to and from the access link and sending the 1751 binding registration requests to the local mobility anchor. In 1752 essence, the mobile access gateway performs mobility management on 1753 behalf of a mobile node. 1755 The mobile access gateway is a function that typically runs on an 1756 access router. However, implementations MAY choose to split this 1757 function and run it across multiple systems. The specifics on how 1758 that is achieved or the signaling interactions between those 1759 functional entities are beyond the scope of this document. 1761 The mobile access gateway has the following key functional roles: 1763 o It is responsible for detecting the mobile node's movements on the 1764 access link and for initiating the mobility signaling with the 1765 mobile node's local mobility anchor. 1767 o Emulation of the mobile node's home link on the access link by 1768 sending Router Advertisement messages containing the mobile node's 1769 home network prefix(es), each prefix carried using the Prefix 1770 Information option [RFC-4861]. 1772 o Responsible for setting up the data path for enabling the mobile 1773 node to configure one or more addresses from its home network 1774 prefix(es) and use it from the attached access link. 1776 6.1. Extensions to Binding Update List Entry Data Structure 1778 Every mobile access gateway MUST maintain a Binding Update List. 1779 Each entry in the Binding Update List represents a mobile node's 1780 mobility binding with its local mobility anchor. The Binding Update 1781 List is a conceptual data structure, described in Section 11.1 of 1782 [RFC-3775]. 1784 For supporting this specification, the conceptual Binding Update List 1785 entry data structure needs be extended with the following additional 1786 fields. 1788 o The Identifier of the attached mobile node, MN-Identifier. This 1789 identifier is acquired during the mobile node's attachment to the 1790 access link through mechanisms outside the scope of this document. 1792 o The link-layer identifier of the mobile node's connected 1793 interface. This can be acquired from the received Router 1794 Solicitation messages from the mobile node or during the mobile 1795 node's attachment to the access network. This is typically a 1796 link-layer identifier conveyed by the mobile node; however, the 1797 specific details on how that is conveyed is out of scope for this 1798 specification. If this identifier is not available, this variable 1799 length field MUST be set to two (octets) and MUST be initialized 1800 to a value of ALL_ZERO. 1802 o List of IPv6 home network prefixes assigned to the mobile node's 1803 connected interface. The home network prefix(es) may have been 1804 statically configured in the mobile node's policy profile, or, may 1805 have been dynamically allocated by the local mobility anchor. 1806 Each of these prefix entries will also includes the corresponding 1807 prefix length. 1809 o The Link-local address of the mobile access gateway on the access 1810 link shared with the mobile node. 1812 o The IPv6 address of the local mobility anchor serving the attached 1813 mobile node. This address is acquired from the mobile node's 1814 policy profile or from other means. 1816 o The interface identifier (If-Id) of the point-to-point link 1817 between the mobile node and the mobile access gateway. This is 1818 internal to the mobile access gateway and is used to associate the 1819 Proxy Mobile IPv6 tunnel to the access link where the mobile node 1820 is attached. 1822 o The tunnel interface identifier (If-Id) of the bi-directional 1823 tunnel between the mobile node's local mobility anchor and the 1824 mobile access gateway. This is internal to the mobile access 1825 gateway. The tunnel interface identifier is acquired during the 1826 tunnel creation. 1828 6.2. Mobile Node's Policy Profile 1830 A mobile node's policy profile contains the essential operational 1831 parameters that are required by the network entities for managing the 1832 mobile node's mobility service. These policy profiles are stored in 1833 a local or a remote policy store. The mobile access gateway and the 1834 local mobility anchor MUST be able to obtain a mobile node's policy 1835 profile. The policy profile MAY also be handed over to a serving 1836 mobile access gateway as part of a context transfer procedure during 1837 a handoff or the serving mobile access gateway MAY be able to 1838 dynamically generate this profile. The exact details on how this 1839 achieved is outside the scope of this document. However, this 1840 specification requires that a mobile access gateway serving a mobile 1841 node MUST have access to its policy profile. 1843 The following are the mandatory fields of the policy profile: 1845 o The mobile node's identifier (MN-Identifier) 1847 o The IPv6 address of the local mobility anchor (LMAA) 1849 The following are the optional fields of the policy profile: 1851 o The mobile node's IPv6 home network prefix(es) assigned to the 1852 mobile node's connected interface 1854 o The mobile node's IPv6 home network Prefix lifetime. This 1855 lifetime will be same for all the hosted prefixes on the link, as 1856 they all are part of one mobility session. 1858 o Supported address configuration procedures (Stateful, Stateless or 1859 both) for the mobile node in the Proxy Mobile IPv6 domain 1861 6.3. Supported Access Link Types 1863 This specification supports only point-to-point access link types and 1864 thus it assumes that the mobile node and the mobile access gateway 1865 are the only two nodes on the access link. The link is assumed to 1866 have multicast capability. 1868 This protocol may also be used on other link types, as long as the 1869 link is configured in such a way that it emulates point-to-point 1870 delivery between the mobile node and the mobile access gateway for 1871 all the protocol traffic. 1873 It is also necessary to be able to identify mobile nodes attaching to 1874 the link. Requirements relating to this are covered in Section 6.6. 1876 Finally, while this specification can operate without link layer 1877 indications of node attachment and detachment to the link, the 1878 existence of such indications either on the network or mobile node 1879 side improves the resulting performance. 1881 6.4. Supported Address Configuration Modes 1883 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1884 more global IPv6 addresses on its interface (using Stateless, 1885 Stateful or manual address autoconfiguration procedures) from the 1886 hosted prefix(es) on that link. The Router Advertisement messages 1887 sent on the access link specify the address configuration methods 1888 permitted on that access link for that mobile node. However, the 1889 advertised flags with respect to the address configuration will be 1890 consistent for a mobile node, on any of the access links in that 1891 Proxy Mobile IPv6 domain. Typically, these configuration settings 1892 will be based on the domain wide policy or based on a policy specific 1893 to each mobile node. 1895 When stateless address autoconfiguration is supported on the access 1896 link, the mobile node can generate one or more IPv6 addresses from 1897 the hosted prefix(es) by standard IPv6 mechanisms such as Stateless 1898 Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. 1900 When stateful address autoconfiguration is supported on the link, the 1901 mobile node can obtain the address configuration from the DHCPv6 1902 server located in the Proxy Mobile IPv6 domain, by standard DHCPv6 1903 mechanisms, as specified in [RFC-3315]. The obtained address(es) 1904 will be from its home network prefix(es). Section 6.11 specifies the 1905 details on how this configuration can be achieved. 1907 Additionally, other address configuration mechanisms specific to the 1908 access link between the mobile node and the mobile access gateway may 1909 also be used for delivering the address configuration to the mobile 1910 node. This specification does not modify the behavior of any of the 1911 standard IPv6 address configuration mechanisms. 1913 6.5. Access Authentication & Mobile Node Identification 1915 When a mobile node attaches to an access link connected to the mobile 1916 access gateway, the deployed access security protocols on that link 1917 SHOULD ensure that the network-based mobility management service is 1918 offered only after authenticating and authorizing the mobile node for 1919 that service. The exact specifics on how this is achieved or the 1920 interactions between the mobile access gateway and the access 1921 security service is outside the scope of this document. This 1922 specification goes with the stated assumption of having an 1923 established trust between the mobile node and the mobile access 1924 gateway, before the protocol operation begins. 1926 6.6. Acquiring Mobile Node's Identifier 1928 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1929 to identify a mobile node, using its MN-Identifier. This identifier 1930 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 1931 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 1932 this identifier in the signaling messages and unambiguously identify 1933 a given mobile node. Following are some of the considerations 1934 related to this MN-Identifier. 1936 o The MN-Identifier is typically obtained as part of the access 1937 authentication or from a notified network attachment event. In 1938 cases where the user identifier authenticated during access 1939 authentication uniquely identifies a mobile node, the MN- 1940 Identifier MAY be the same as the user identifier. However, the 1941 user identifier MUST NOT be used if it identifies a user account 1942 that can be used from more than one mobile node operating in the 1943 same Proxy Mobile IPv6 domain. 1945 o In some cases, the obtained identifier as part of the access 1946 authentication can be a temporary identifier and further that 1947 temporary identifier may be different at each re-authentication. 1948 However, the mobile access gateway MUST be able to use this 1949 temporary identifier and obtain the mobile node's stable 1950 identifier from the policy store. For instance, in AAA-based 1951 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1952 4372] may be used, as long as it uniquely identifies a mobile 1953 node, and not a user account that can be used with multiple mobile 1954 nodes. 1956 o In some cases and for privacy reasons, the MN-Identifier that the 1957 policy store delivers to the mobile access gateway may not be the 1958 true identifier of the mobile node. However, the mobility access 1959 gateway MUST be able to use this identifier in the signaling 1960 messages exchanged with the local mobility anchor. 1962 o The mobile access gateway MUST be able to identify the mobile node 1963 by its MN-Identifier and it MUST be able to associate this 1964 identity to the point-to-point link shared with the mobile node. 1966 6.7. Home Network Emulation 1968 One of the key functions of a mobile access gateway is to emulate the 1969 mobile node's home network on the access link. It must ensure, the 1970 mobile node believes it is still connected to its home link or on the 1971 link where it obtained its initial address configuration after it 1972 moved into that Proxy Mobile IPv6 domain. 1974 For emulating the mobile node's home link on the access link, the 1975 mobile access gateway must be able to send Router Advertisement 1976 messages advertising the mobile node's home network prefix(es) 1977 carried using the Prefix Information option(s) [RFC-4861] and with 1978 other address configuration parameters consistent with its home link 1979 properties. Typically, these configuration settings will be based on 1980 the domain wide policy or based on a policy specific to each mobile 1981 node. 1983 Typically, the mobile access gateway learns the mobile node's home 1984 network prefix(es) details from the received Proxy Binding 1985 Acknowledgement message or it may obtain them from the mobile node's 1986 policy profile. However, the mobile access gateway SHOULD send the 1987 Router Advertisements advertising the mobile node's home network 1988 prefix(es) only after successfully completing the binding 1989 registration with the mobile node's local mobility anchor. 1991 When advertising the home network prefix(es) in the Router 1992 Advertisement messages, the mobile access gateway MAY set the prefix 1993 lifetime value for the advertised prefix(es) to any chosen value at 1994 its own discretion. An implementation MAY choose to tie the prefix 1995 lifetime to the mobile node's binding lifetime. The prefix lifetime 1996 can also be an optional configuration parameter in the mobile node's 1997 policy profile. 1999 6.8. Link-Local and Global Address Uniqueness 2001 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 2002 mobile access gateway to the other, will continue to detect its home 2003 network and thus believe it is still on the same link. Every time 2004 the mobile node attaches to a new link, the event related to the 2005 interface state change will trigger the mobile node to perform DAD 2006 operation on the link-local and global address(es). However, if the 2007 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 2008 detect the link change due to DNAv6 optimizations and may not trigger 2009 the duplicate address detection (DAD) procedure for its existing 2010 addresses, which may potentially lead to address collisions after the 2011 mobile node's handoff to a new link. 2013 The issue of address collision is not relevant to the mobile node's 2014 global address(es). Since the assigned home network prefix(es) are 2015 for the mobile node's exclusive usage, no other node shares an 2016 address (other than Subnet-Router anycast address which is configured 2017 by the mobile access gateway) from the prefix(es) and so the 2018 uniqueness for the mobile node's global address is assured on the 2019 access link. 2021 The issue of address collision is however relevant to the mobile 2022 node's link-local addresses since the mobile access gateway and the 2023 mobile node will have link-local addresses configured from the same 2024 link-local prefix (FE80::/64). This leaves a room for link-local 2025 address collision between the two neighbors (i.e., the mobile node 2026 and the mobile access gateway) on that access link. For solving this 2027 problem, this specification requires that the link-local address that 2028 the mobile access gateway configures on the point-to-point link 2029 shared with a given mobile node be generated by the local mobility 2030 anchor and be stored in the mobile node's Binding Cache entry. This 2031 address will not change for the duration of that mobile node's 2032 session and can be provided to the serving mobile access gateway at 2033 every mobile node's handoff, as part of the Proxy Mobile IPv6 2034 signaling messages. The specific method by which the local mobility 2035 anchor generates the link-local address is out of scope for this 2036 specification. 2038 Optionally, implementations MAY choose to configure a fixed link- 2039 local address across all the access links in a Proxy Mobile IPv6 2040 domain and without a need for carrying this address from the local 2041 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 2042 signaling messages. 2044 6.9. Signaling Considerations 2046 6.9.1. Binding Registrations 2048 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 2050 1. After detecting a new mobile node on its access link, the mobile 2051 access gateway MUST identify the mobile node and acquire its MN- 2052 Identifier. If it determines that the network-based mobility 2053 management service needs to be offered to the mobile node, it 2054 MUST send a Proxy Binding Update message to the local mobility 2055 anchor. 2057 2. The Proxy Binding Update message MUST include the Mobile Node 2058 Identifier option [RFC-4283], carrying the MN-Identifier for 2059 identifying the mobile node. 2061 3. The Home Network Prefix option(s) MUST be present in the Proxy 2062 Binding Update message. If the mobile access gateway learns the 2063 mobile node's home network prefix(es) either from its policy 2064 store or from other means, the mobile access gateway MAY choose 2065 to request the local mobility anchor to allocate the requested 2066 prefix(es) by including a Home Network Prefix option for each of 2067 those requested prefixes. The mobile access gateway MAY also 2068 choose to include just one Home Network Prefix option with the 2069 prefix value of ALL_ZERO, for requesting the local mobility 2070 anchor to do the prefix assignment. However, when including a 2071 Home Network Prefix option with the prefix value of ALL_ZERO, 2072 then there MUST be only one instance of the Home Network prefix 2073 option in the request. 2075 4. The Handoff Indicator option MUST be present in the Proxy 2076 Binding Update message. The Handoff Indicator field in the 2077 Handoff Indicator option MUST be set to a value indicating the 2078 handoff hint. 2080 * The Handoff Indicator field MUST be set to value 1 2081 (Attachment over a new interface), if the mobile access 2082 gateway determines (under the Handoff Indicator 2083 considerations specified in this section) that the mobile 2084 node's current attachment to the network over this interface 2085 is not as a result of a handoff of an existing mobility 2086 session (over the same interface or through a different 2087 interface), but as a result of an attachment over a new 2088 interface. This essentially serves as a request to the local 2089 mobility anchor to create a new mobility session and not 2090 update any existing Binding Cache entry created for the same 2091 mobile node connected to the Proxy Mobile IPv6 domain through 2092 a different interface. 2094 * The Handoff Indicator field MUST be set to value 2 (Handoff 2095 between two different interfaces of the mobile node), if the 2096 mobile access gateway definitively knows the mobile node's 2097 current attachment is due to a handoff of an existing 2098 mobility session, between two different interfaces of the 2099 mobile node. 2101 * The Handoff Indicator field MUST be set to value 3 (Handoff 2102 between mobile access gateways for the same interface), if 2103 the mobile access gateway definitively knows the mobile 2104 node's current attachment is due to a handoff of an existing 2105 mobility session between two mobile access gateways and for 2106 the same interface of the mobile node. 2108 * The Handoff Indicator field MUST be set to value 4 (Handoff 2109 state unknown), if the mobile access gateway cannot determine 2110 if the mobile node's current attachment is due to a handoff 2111 of an existing mobility session. 2113 5. The mobile access gateway MUST apply the below considerations 2114 when choosing the value for the Handoff Indicator field. 2116 * The mobile access gateway can choose to use the value 2 2117 (Handoff between two different interfaces of the mobile 2118 node), only when it knows that the mobile node has on purpose 2119 switched from one interface to another, and the previous 2120 interface is going to be disabled. It may know this due to a 2121 number of factors. For instance, most cellular networks have 2122 controlled handovers where the network knows that the host is 2123 moving from one attachment to another. In this situation the 2124 link layer mechanism can inform the mobility functions that 2125 this is indeed a movement, not a new attachment. 2127 * Some link layers have link-layer identifiers that can be used 2128 to distinguish (a) the movement of a particular interface to 2129 a new attachment from (b) the attachment of a new interface 2130 from the same host. Option value 3 (Handoff between mobile 2131 access gateways for the same interface)is appropriate in case 2132 a and value of 1 (Attachment over a new interface) in case b. 2134 * The mobile access gateway MUST NOT set the option value to 2 2135 (Handoff between two different interfaces of the mobile node) 2136 or 3 (Handoff between mobile access gateways for the same 2137 interface) if it can not be determined that the mobile node 2138 can move the address between the interfaces involved in the 2139 handover or that it is the same interface that has moved. 2140 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2141 physical interfaces to the same domain may suffer unexpected 2142 failures. 2144 * Where no support from the link layer exists, the host and the 2145 network would need to inform each other about the intended 2146 movement. The Proxy Mobile IPv6 protocol does not specify 2147 this and simply requires that knowledge about movements can 2148 be derived either from the link-layer or from somewhere else. 2149 The method by which this is accomplished is outside the scope 2150 of this specification. 2152 6. Either the Timestamp option or a valid sequence number 2153 maintained on a per mobile node basis (if the Sequence Number 2154 based scheme is in use) MUST be present. When Timestamp option 2155 is added to the message, the mobile access gateway SHOULD also 2156 set the Sequence Number field to a value of a monotonically 2157 increasing counter (not to be confused with the per mobile node 2158 sequence number specified in [RFC-3775]). The local mobility 2159 anchor will ignore this field when there is a Timestamp option 2160 present in the request, but will return the same value in the 2161 Proxy Binding Acknowledgement message. This will be useful for 2162 matching the reply to the request message. 2164 7. The Mobile Node Link-layer Identifier option carrying the link- 2165 layer identifier of the currently attached interface MUST be 2166 present in the Proxy Binding Update message, if the mobile 2167 access gateway is aware of the same. If the link-layer 2168 identifier of the currently attached interface is not known or 2169 if the identifier value is ALL_ZERO, this option MUST NOT be 2170 present. 2172 8. The Access Technology Type option MUST be present in the Proxy 2173 Binding Update message. The access technology type field in the 2174 option SHOULD be set to the type of access technology using 2175 which the mobile node is currently attached to the mobile access 2176 gateway. 2178 9. The Link-local Address option MAY be present in the Proxy 2179 Binding Update message. Considerations from Section 6.8 MUST be 2180 applied when using the link-local address option. 2182 * When querying the local mobility anchor for the link-local 2183 address that it should use on the point-to-point link shared 2184 with the mobile node, this option MUST be set to ALL_ZERO. 2186 This essentially serves as a request to the local mobility 2187 anchor to provide the link-local address that it can use on 2188 the access link shared with the mobile node. 2190 * When uploading the link-local address to the local mobility 2191 anchor, the value in the option MUST be set to the link-local 2192 address that is configured on the point-to-point link shared 2193 with the mobile node. This is allowed only during an initial 2194 mobile node's attachment. 2196 10. The Proxy Binding Update message MUST be constructed as 2197 specified in Section 6.9.1.5. 2199 11. If there is no existing Binding Update List entry for that 2200 mobile node, the mobile access gateway MUST create a Binding 2201 Update List entry for the mobile node upon sending the Proxy 2202 Binding Update request. 2204 6.9.1.2. Receiving Binding Registration Reply 2206 On receiving a Proxy Binding Acknowledgement message (format 2207 specified in Section 8.2) from the local mobility anchor, the mobile 2208 access gateway MUST process the message as specified below. 2210 1. The received Proxy Binding Acknowledgement message (a Binding 2211 Acknowledgement message with the 'P' flag set to value of 1) 2212 MUST be authenticated as described in Section 4. When IPsec is 2213 used for message authentication, the SPI in the IPsec header 2214 [RFC-4306] of the received packet is needed for locating the 2215 security association, for authenticating the Proxy Binding 2216 Acknowledgement message. 2218 2. The mobile access gateway MUST observe the rules described in 2219 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2220 the received Proxy Binding Acknowledgement message. 2222 3. The mobile access gateway MUST apply the considerations 2223 specified in Section 5.5 for processing the Sequence Number 2224 field and the Timestamp option (if present), in the message. 2226 4. The mobile access gateway MUST ignore any checks, specified in 2227 [RFC-3775] related to the presence of a Type 2 Routing header in 2228 the Proxy Binding Acknowledgement message. 2230 5. The mobile access gateway MAY use the mobile node identifier 2231 present in the Mobile Node Identifier option for matching the 2232 response to the request messages that it sent recently. 2233 However, if there is more than one request message in its 2234 request queue for the same mobile node, the sequence number 2235 field can be used for identifying the exact message from those 2236 messages. There are other ways to achieve this and 2237 implementations are free to adopt the best approach that suits 2238 their implementation. Additionally, if the received Proxy 2239 Binding Acknowledgement message does not match any of the Proxy 2240 Binding Update messages that it sent recently, the message MUST 2241 be ignored. 2243 6. If the received Proxy Binding Acknowledgement message has any 2244 one or more of the following options, Handoff Indicator option, 2245 Access Technology Type option, Mobile Node Link-layer Identifier 2246 option, Mobile Node Identifier option, carrying option values 2247 that are different from the option values present in the 2248 corresponding request (Proxy Binding Update) message, the 2249 message MUST be ignored as the local mobility anchor is expected 2250 to echo back all these listed options and with the same option 2251 values in the reply message. Further, the mobile access gateway 2252 MUST NOT retransmit the Proxy Binding Update message till an 2253 administrative action is taken. 2255 7. If the received Proxy Binding Acknowledgement message has the 2256 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2257 registration not enabled for the mobile node), the mobile access 2258 gateway SHOULD NOT send binding registration requests again for 2259 that mobile node. It MUST deny the mobility service to that 2260 mobile node. 2262 8. If the received Proxy Binding Acknowledgement message has the 2263 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2264 (Timestamp value lower than previously accepted value), the 2265 mobile access gateway SHOULD try to register again to reassert 2266 the mobile node's presence on its access link. The mobile 2267 access gateway is not specifically required to synchronize its 2268 clock upon receiving this error code. 2270 9. If the received Proxy Binding Acknowledgement message has the 2271 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2272 value), the mobile access gateway SHOULD try to register again 2273 only after it has synchronized its clock to a common time source 2274 that is used by all the mobility entities in that domain for 2275 their clock synchronization. The mobile access gateway SHOULD 2276 NOT synchronize its clock to the local mobility anchor's system 2277 clock, based on the timestamp present in the received message. 2279 10. If the received Proxy Binding Acknowledgement message has the 2280 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2281 (The mobile node is not authorized for one or more of the 2282 requesting home network prefix(es)), the mobile access gateway 2283 SHOULD NOT request for the same prefix(es) again, but can only 2284 request the local mobility anchor to do the assignment of 2285 prefix(es) by including only one Home Network Prefix option with 2286 the prefix value set to ALL_ZERO. 2288 11. If the received Proxy Binding Acknowledgement message has the 2289 Status field value set to any value greater than or equal to 128 2290 (i.e., if the binding is rejected), the mobile access gateway 2291 MUST NOT advertise the mobile node's home network prefix(es) in 2292 the Router Advertisement messages sent on that access link and 2293 MUST deny the mobility service to the mobile node by not 2294 forwarding any packets received from the mobile node using an 2295 address from the home network prefix(es). It MAY also tear down 2296 the point-to-point link shared with the mobile node. 2298 12. If the received Proxy Binding Acknowledgement message has the 2299 Status field value set to 0 (Proxy Binding Update accepted), the 2300 mobile access gateway MUST establish a bi-directional tunnel to 2301 the local mobility anchor (if there is no existing bi- 2302 directional tunnel to that local mobility anchor). 2303 Considerations from Section 5.6.1 MUST be applied for managing 2304 the dynamically created bi-directional tunnel. 2306 13. The mobile access gateway MUST set up the route for forwarding 2307 the packets received from the mobile node using address(es) from 2308 its home network prefix(es) through the bi-directional set up 2309 for that mobile node. The created tunnel and the routing state 2310 MUST result in the forwarding behavior on the mobile access 2311 gateway as specified in Section 6.10.5. 2313 14. The mobile access gateway MUST also update the Binding Update 2314 List entry for reflecting the accepted binding registration 2315 values. It MUST also advertise the mobile node's home network 2316 prefix(es) as the hosted on-link prefixes, by including them in 2317 the Router Advertisement messages that it sends on that access 2318 link. 2320 15. If the received Proxy Binding Acknowledgement message has the 2321 address in the Link-local Address option set to a NON_ZERO 2322 value, the mobile access gateway MUST configure that link-local 2323 address on that point-to-point link and MUST NOT configure any 2324 other link-local address on that point-to-point link. This will 2325 avoid any link-local address collisions with the mobile node on 2326 that access link. 2328 6.9.1.3. Extending Binding Lifetime 2330 1. For extending the lifetime of a currently registered mobile node 2331 (i.e., after a successful initial binding registration from the 2332 same mobile access gateway), the mobile access gateway can send a 2333 Proxy Binding Update message to the local mobility anchor with a 2334 new lifetime value. This re-registration message MUST be 2335 constructed with the same set of options as the initial binding 2336 registration message, under the considerations specified in 2337 Section 6.9.1.1. However the following exceptions apply. 2339 2. There MUST be a Home Network Prefix option for each of the 2340 assigned home network prefixes assigned for that mobility session 2341 and with the prefix value in the option set to that respective 2342 prefix value. 2344 3. The Handoff Indicator field in the Handoff Indicator option MUST 2345 be set to a value of 5 (Handoff state not changed - Re- 2346 Registration). 2348 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2350 1. If at any point the mobile access gateway detects that the mobile 2351 node has moved away from its access link, or if it decides to 2352 terminate the mobile node's mobility session, it SHOULD send a 2353 Proxy Binding Update message to the local mobility anchor with 2354 the lifetime value set to zero. This de-registration message 2355 MUST be constructed with the same set of options as the initial 2356 binding registration message, under the considerations specified 2357 in Section 6.9.1.1. However, the following exceptions apply. 2359 2. There MUST be a Home Network Prefix option for each of the 2360 assigned home network prefix(es) assigned for that mobility 2361 session and with the prefix value in the option set to the 2362 respective prefix value. 2364 3. The Handoff Indicator field in the Handoff Indicator option MUST 2365 be set to a value of 4 (Handoff state unknown). 2367 Either upon receipt of a Proxy Binding Acknowledgement message from 2368 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2369 timeout waiting for the reply, the mobile access gateway MUST do the 2370 following: 2372 1. It MUST remove the Binding Update List entry for the mobile node 2373 from its Binding Update List. 2375 2. It MUST remove the created routing state for tunneling the mobile 2376 node's traffic. 2378 3. If there is a dynamically created tunnel to the mobile node's 2379 local mobility anchor and if there are not other mobile nodes for 2380 which the tunnel is being used, then the tunnel MUST be deleted. 2382 4. It MUST tear down the point-to-point link shared with the mobile 2383 node. This action will force the mobile node to remove any IPv6 2384 address configuration on the interface connected to this point- 2385 to-point link. 2387 6.9.1.5. Constructing the Proxy Binding Update Message 2389 o The mobile access gateway when sending the Proxy Binding Update 2390 request to the local mobility anchor MUST construct the message as 2391 specified below. 2393 IPv6 header (src=Proxy-CoA, dst=LMAA) 2394 Mobility header 2395 - BU /* P & A flags MUST be set to value 1 */ 2396 Mobility Options 2397 - Mobile Node Identifier option (mandatory) 2398 - Home Network Prefix option(s) (mandatory) 2399 - Handoff Indicator option (mandatory) 2400 - Access Technology Type option (mandatory) 2401 - Timestamp option (optional) 2402 - Mobile Node Link-layer Identifier option (optional) 2403 - Link-local Address option (optional) 2405 Figure 12: Proxy Binding Update message format 2407 o The Source Address field in the IPv6 header of the message MUST be 2408 set to the global address configured on the egress interface of 2409 the mobile access gateway. When there is no Alternate Care-of 2410 Address option present in the request, this address will be 2411 considered as the Proxy-CoA address for this binding registration 2412 request. However, when there is Alternate Care-of Address option 2413 present in the request, this address will be not be considered as 2414 the Proxy-CoA address, but the address in the alternate Care-of 2415 Address option will be considered as the Proxy-CoA address. 2417 o The Destination Address field in the IPv6 header of the message 2418 MUST be set to the local mobility anchor address. 2420 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2422 o At least one Home Network Prefix option MUST be present. 2424 o The Handoff Indicator option MUST be present. 2426 o The Access Technology Type option MUST be present. 2428 o The Timestamp option MAY be present. 2430 o The Mobile Node Link-layer Identifier option MAY be present. 2432 o The Link-local Address option MAY be present. 2434 o If IPsec is used for protecting the signaling messages, the 2435 message MUST be protected, using the security association existing 2436 between the local mobility anchor and the mobile access gateway. 2438 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2439 3775] MUST NOT be present in the IPv6 Destination Options 2440 extension header of the Proxy Binding Update message. 2442 6.9.2. Router Solicitation Messages 2444 A mobile node may send a Router Solicitation message on the access 2445 link shared with the mobile access gateway. The Router Solicitation 2446 message that the mobile node sends is as specified in [RFC-4861]. 2447 The mobile access gateway on receiving the Router Solicitation 2448 message or before sending a Router Advertisement message MUST apply 2449 the following considerations. 2451 1. The mobile access gateway on receiving the Router Solicitation 2452 message SHOULD send a Router Advertisement message containing the 2453 mobile node's home network prefix(es) as the on-link prefix(es). 2454 However, before sending the Router Advertisement message 2455 containing the mobile node's home network prefix(es), it SHOULD 2456 complete the binding registration process with the mobile node's 2457 local mobility anchor. 2459 2. If the local mobility anchor rejects the binding registration 2460 request, or, if the mobile access gateway failed to complete the 2461 binding registration process for whatever reason, the mobile 2462 access gateway MUST NOT advertise the mobile node's home network 2463 prefix(es) in the Router Advertisement messages that it sends on 2464 the access link. However, it MAY choose to advertise a local 2465 visited network prefix(es) to enable the mobile node for regular 2466 IPv6 access. 2468 3. The mobile access gateway SHOULD add the MTU option, as specified 2469 in [RFC-4861], to the Router Advertisement messages that it sends 2470 on the access link. This will ensure the mobile node on the link 2471 uses the advertised MTU value. The MTU value SHOULD reflect the 2472 tunnel MTU for the bi-directional tunnel between the mobile 2473 access gateway and the local mobility anchor. Considerations 2474 from Section 6.9.5 SHOULD be applied for determining the tunnel 2475 MTU value. 2477 6.9.3. Default-Router 2479 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2480 router for the mobile node on the access link, as it is the entity 2481 that sends the Router Advertisements on the access link. However, as 2482 the mobile node moves from one access link to another, the serving 2483 mobile access gateway on those respective links will send the Router 2484 Advertisement messages. If these Router Advertisements are sent 2485 using a different link-local address or a different link-layer 2486 address, the mobile node will always detect a new default-router 2487 after every handoff. For solving this problem, this specification 2488 requires all the mobile access gateways in the Proxy Mobile IPv6 2489 domain to use the same link-local and link-layer address on any of 2490 the access links where ever the mobile node attaches. These 2491 addresses can be fixed addresses across the entire Proxy Mobile IPv6 2492 domain and all the mobile access gateways can use these globally 2493 fixed address on any of the point-to-point links. Additionally, this 2494 specification allows the local mobility anchor to generate the link- 2495 local address and provide it to the mobile access gateway as part of 2496 the signaling messages. 2498 However, both of these approaches (a link-local address generated by 2499 the local mobility anchor or when using a globally fixed link-local 2500 address) have implications on the deployment of SEcure Neighbor 2501 Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and 2502 public key pairs, and their Router Advertisements are signed with the 2503 private keys of these key pairs. When a number of different routers 2504 use the same addresses, the routers either all have to be able to 2505 construct these signatures for the same key pair, or the used key 2506 pair and the router's cryptographic identity must change after a 2507 movement. Both approaches are problematic. Sharing of private key 2508 information across a number of nodes would be inappropriate. And 2509 changing even the cryptographic identity of the router goes against 2510 the general idea of the Proxy Mobile IPv6 being as invisible to the 2511 hosts as possible. 2513 There is, however, ongoing work at the IETF to revise the SEND 2514 specifications. It is suggested that these revisions also address 2515 the above problem. Other revisions are needed to deal with other 2516 problematic cases (such as Neighbor Discovery proxies) before wide- 2517 spread deployment of SEND. 2519 6.9.4. Retransmissions and Rate Limiting 2521 The mobile access gateway is responsible for retransmissions and rate 2522 limiting the binding registration requests that it sends to the local 2523 mobility anchor. The Retransmission and the Rate Limiting rules are 2524 as specified in [RFC-3775]. However, the following considerations 2525 MUST be applied. 2527 1. When the mobile access gateway sends a Proxy Binding Update 2528 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2529 [RFC-3775], for configuring the retransmission timer, as 2530 specified in Section 11.8 [RFC-3775]. However, the mobile access 2531 gateway is not required to use a longer retransmission interval 2532 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2533 the initial binding registration request. 2535 2. If the mobile access gateway fails to receive a valid matching 2536 response for a registration or re-registration message within the 2537 retransmission interval, it SHOULD retransmit the message until a 2538 response is received. However, the mobile access gateway MUST 2539 ensure the mobile node is still attached to the connected link 2540 before retransmitting the message. 2542 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2543 gateway MUST use an exponential back-off process in which the 2544 timeout period is doubled upon each retransmission, until either 2545 the node receives a response or the timeout period reaches the 2546 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2547 MAY continue to send these messages at this slower rate 2548 indefinitely. 2550 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2551 Binding Update messages MUST use the latest timestamp. If the 2552 Sequence number scheme is in use, the retransmitted Proxy Binding 2553 Update messages MUST use a Sequence Number value greater than 2554 that used for the previous transmission of this Proxy Binding 2555 Update message, just as specified in [RFC-3775]. 2557 6.9.5. Path MTU Discovery 2559 For getting optimal throughput, it is required that the routed 2560 packets between the local mobility anchor and the mobile access 2561 gateway are sent in the largest size and without fragmentation. If 2562 the mobility entities are aware of the Path MTU (PMTU) between 2563 themselves, it can be used for determining the Tunnel Path MTU and 2564 also for advertising this value as the link MTU on the access link 2565 shared with the mobile node. The following are some of the 2566 considerations related to Path MTU discovery. 2568 o The local mobility anchor and mobile access gateway MAY use the 2569 Path MTU Discovery mechanisms as specified in [RFC-1981] and [RFC- 2570 4821]. for determining the Path MTU (PMTU) for the path between 2571 themselves. 2573 o The local mobility anchor and the mobile access gateway MAY use 2574 any standard application probes for determining the PMTU. The 2575 specifics details related to the type of traffic that can be used 2576 for the PMTU discovery is outside the scope of this document. 2578 o If there is an administratively configured PMTU value for the path 2579 between the local mobility anchor and the mobile access gateway, 2580 the dynamic discovery of PMTU is not required. 2582 o The IPv6 tunnel MTU for the established tunnel between the local 2583 mobility anchor and the mobile access gateway can be computed 2584 based on this Path MTU value, as specified in Section 6.7 of [RFC- 2585 2473]. 2587 o The mobile access gateway SHOULD use this determined tunnel Path 2588 MTU value (for the tunnel established with the mobile node's local 2589 mobility anchor) as the MTU value in the MTU option that it sends 2590 in the Router Advertisements on the access link shared with the 2591 mobile node. 2593 6.10. Routing Considerations 2595 This section describes how the mobile access gateway handles the 2596 traffic to/from the mobile node that is attached to one of its access 2597 interfaces. 2599 Proxy-CoA LMAA 2600 | | 2601 +--+ +---+ +---+ +--+ 2602 |MN|----------|MAG|======================|LMA|----------|CN| 2603 +--+ +---+ +---+ +--+ 2604 IPv6 Tunnel 2606 Figure 13: Proxy Mobile IPv6 Tunnel 2608 6.10.1. Transport Network 2610 As per this specification, the transport network between the local 2611 mobility anchor and the mobile access gateway is an IPv6 network. 2612 The companion document [ID-IPV4-PMIP6] specifies the required 2613 extensions for negotiating IPv4 transport and the corresponding 2614 encapsulation mode. 2616 6.10.2. Tunneling & Encapsulation Modes 2618 An IPv6 address that a mobile node uses from its home network 2619 prefix(es) is topologically anchored at the local mobility anchor. 2620 For a mobile node to use this address from an access network attached 2621 to a mobile access gateway, proper tunneling techniques have to be in 2622 place. Tunneling hides the network topology and allows the mobile 2623 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2624 packet and to be routed between the local mobility anchor and the 2625 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2626 defines the use of IPv6-over-IPv6 tunneling [RFC-2473], between the 2627 home agent and the mobile node and this specification extends the use 2628 of the same tunneling mechanism for use between the local mobility 2629 anchor and the mobile access gateway. 2631 On most operating systems, a tunnel is implemented as a virtual 2632 point-to-point interface. The source and the destination address of 2633 the two end points of this virtual interface along with the 2634 encapsulation mode are specified for this virtual interface. Any 2635 packet that is routed over this interface gets encapsulated with the 2636 outer header as specified for that point to point tunnel interface. 2638 For creating a point to point tunnel to any local mobility anchor, 2639 the mobile access gateway may implement a tunnel interface with the 2640 source address field set to a global address on its egress interface 2641 (Proxy-CoA) and the destination address field set to the global 2642 address of the local mobility anchor (LMAA). 2644 The following is the supported packet encapsulation mode that can be 2645 used by the mobile access gateway and the local mobility anchor for 2646 routing mobile node's IPv6 datagrams. 2648 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2649 2473]. 2651 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2652 modes for supporting IPv4 transport. 2654 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2655 details on how this mode is negotiated is specified in [ID-IPV4- 2656 PMIP6]. 2658 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2659 packet. This mode is specified in [ID-IPV4-PMIP6]. 2661 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2662 packet with a TLV header. This mode is specified in [ID-IPV4- 2663 PMIP6]. 2665 6.10.3. Local Routing 2667 If there is data traffic between a visiting mobile node and a 2668 correspondent node that is locally attached to an access link 2669 connected to the mobile access gateway, the mobile access gateway MAY 2670 optimize on the delivery efforts by locally routing the packets and 2671 by not reverse tunneling them to the mobile node's local mobility 2672 anchor. The flag EnableMAGLocalRouting MAY be used for controlling 2673 this behavior. However, in some systems, this may have an 2674 implication on the mobile node's accounting and policy enforcement as 2675 the local mobility anchor is not in the path for that traffic and it 2676 will not be able to apply any traffic policies or do any accounting 2677 for those flows. 2679 This decision of path optimization SHOULD be based on the policy 2680 configured on the mobile access gateway, but enforced by the mobile 2681 node's local mobility anchor. The specific details on how this is 2682 achieved are beyond of the scope of this document. 2684 6.10.4. Tunnel Management 2686 All the considerations mentioned in Section 5.6.1 for the tunnel 2687 management on the local mobility anchor apply for the mobile access 2688 gateway as well. 2690 6.10.5. Forwarding Rules 2692 Forwarding Packets sent to the Mobile Node's Home Network: 2694 o On receiving a packet from the bi-directional tunnel established 2695 with the mobile node's local mobility anchor, the mobile access 2696 gateway MUST use the destination address of the inner packet for 2697 forwarding it on the interface where the destination network 2698 prefix is hosted. The mobile access gateway MUST remove the outer 2699 header before forwarding the packet. Considerations from [RFC- 2700 2473] MUST be applied for IPv6 decapsulation. If the mobile 2701 access gateway cannot find the connected interface for that 2702 destination address, it MUST silently drop the packet. For 2703 reporting an error in such a scenario, in the form of ICMP control 2704 message, the considerations from [RFC-2473] MUST be applied. 2706 o On receiving a packet from a correspondent node that is locally 2707 connected and which is destined to a mobile node that is on 2708 another locally connected access link, the mobile access gateway 2709 MUST check the flag EnableMAGLocalRouting, to ensure the mobile 2710 access gateway is allowed to route the packet directly to the 2711 mobile node. If the mobile access gateway is not allowed to route 2712 the packet directly, it MUST route the packet through the bi- 2713 directional tunnel established between itself and the mobile 2714 node's local mobility anchor. Otherwise, it can route the packet 2715 directly to the mobile node. 2717 Forwarding Packets Sent by the Mobile Node: 2719 o On receiving a packet from a mobile node connected to its access 2720 link, the mobile access gateway MUST ensure that there is an 2721 established binding for that mobile node with its local mobility 2722 anchor before forwarding the packet directly to the destination or 2723 before tunneling the packet to the mobile node's local mobility 2724 anchor. 2726 o On receiving a packet from a mobile node connected to its access 2727 link for a destination that is locally connected, the mobile 2728 access gateway MUST check the flag EnableMAGLocalRouting, to 2729 ensure the mobile access gateway is allowed to route the packet 2730 directly to the destination. If the mobile access gateway is not 2731 allowed to route the packet directly, it MUST route the packet 2732 through the bi-directional tunnel established between itself and 2733 the mobile node's local mobility anchor. Otherwise, it MUST route 2734 the packet directly to the destination. 2736 o On receiving a packet from a mobile node connected to its access 2737 link, to a destination that is not directly connected, the packet 2738 MUST be forwarded to the local mobility anchor through the bi- 2739 directional tunnel established between itself and the mobile 2740 node's local mobility anchor. However, the packets that are sent 2741 with the link-local source address MUST NOT be forwarded. 2743 o The format of the tunneled packet is shown below. Considerations 2744 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 2745 when using IPv4 transport, the format of the tunneled packet is as 2746 described in [ID-IPV4-PMIP6]. 2748 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2749 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2750 Upper layer protocols /* Packet Content*/ 2751 Figure 14: Tunneled Packet from MAG to LMA 2753 o The format of the tunneled packet is shown below, when payload 2754 protection using IPsec is enabled for the mobile node's data 2755 traffic. However, when using IPv4 transport, the format of the 2756 packet is as described in [ID-IPV4-PMIP6]. 2758 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2759 ESP Header in tunnel mode /* ESP Header */ 2760 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2761 Upper layer protocols /* Packet Content*/ 2763 Figure 15: Tunneled Packet from MAG to LMA with Payload Protection 2765 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2767 This section explains how Stateful Address Configuration using DHCPv6 2768 support can be enabled in a Proxy Mobile IPv6 domain. It also 2769 identifies the required configuration in DHCP and mobility 2770 infrastructures for supporting this address configuration mode and 2771 also identifies the protocol interactions between these two systems. 2773 o For supporting Stateful Address Configuration using DHCP, the DHCP 2774 relay agent [RFC-3315] service MUST be configured on all the 2775 mobile access gateways in the Proxy Mobile IPv6 domain. Further, 2776 as specified in Section 20 of [RFC-3315], the DHCP relay agent 2777 should be configured to use a list of destination addresses, which 2778 MAY include unicast addresses, the All_DHCP_Servers multicast 2779 address, or other addresses as required in a given deployment. 2781 o The DHCP infrastructure needs to be configured with different IPv6 2782 prefix groups, each group MUST represent a link in that Proxy 2783 Mobile IPv6 domain on which those respective prefixes are hosted. 2784 In essence the DHCP infrastructure is aware of all the links in 2785 that domain along with the associated IPv6 prefixes with each one 2786 of those links. This configuration requirement is identical to 2787 the fixed infrastructure configuration except with the key 2788 difference that these links are mobile in nature, a link along 2789 with its prefixes associated with a given mobile node and a mobile 2790 access gateway pair at a point of time may be associated with a 2791 different mobile access gateway and mobile node pair at a later 2792 point of time. However, from the perspective of the DHCP server, 2793 this aspect of prefix mobility will not be visible to it. 2795 o The local mobility anchor needs to have the same awareness with 2796 respect to the links along with the associated prefixes in a Proxy 2797 Mobile IPv6 domain. When a local mobilty anchor assigns 2798 prefix(es) to a mobile node, it MUST assign all the prefixes 2799 associated with a given link and all of those assigned prefixes 2800 will remain as the home network prefixes for that mobile node 2801 through out the life of that mobility session. The serving mobile 2802 access gateway that hosts these prefixes is physically connected 2803 to that link and can function as the DHCP relay agent. This 2804 common understanding between DHCP and mobility entities about all 2805 the links in the domain along with the associated prefixes, 2806 provides the required coordination for allowing mobility entities 2807 to perform prefix assignment dynamically to a mobile node and 2808 still allowing DHCP infrastructure to perform address assignment 2809 for that mobile node only from its home network prefixes. 2811 o When a mobile node sends a DHCP request message, the DHCP relay 2812 agent function on the mobile access gateway will set the link- 2813 address field in the DHCP message to an address in the mobile 2814 node's home network prefix (any one of the mobile node's home 2815 network prefixes assigned to that mobile node's attached 2816 interface). The address can be generated as per [RFC-4862] by 2817 combining that mobile node's home network prefix and its own 2818 interface identifier on that access link shared with the mobile 2819 node, so as to provide a hint to the DHCP Server for the link 2820 identification. The DHCP server on receiving the request from the 2821 mobile node, will allocate addresses from all the prefixes 2822 associated with that link (identified using the link-address field 2823 of the request). 2825 o Once the mobile node obtains address(es) and moves to a different 2826 link and sends a DHCP request (at any time) for extending the DHCP 2827 lease, the DHCP relay agent on the new link will set the prefix 2828 hint in the DHCP message to one of the mobile node's home network 2829 prefixes. The DHCP server will identify the client from the 2830 Client-DUID option and will identify the link from the link- 2831 address option present in the request and will allocate the same 2832 address(es) as before. 2834 o The DHCP based address configuration is not recommended for 2835 deployments where the local mobility anchor and the mobile access 2836 gateway are located in different administrative domains. For this 2837 configuration to work, all the mobile access gateways in the Proxy 2838 Mobile IPv6 domain should be able to ensure that the DHCP request 2839 messages from a given mobile node anchored on any of the access 2840 links in that domain, will always be handled by the same DHCP 2841 server or by a server from the same group of coordinated DHCP 2842 servers serving that domain. 2844 o The DHCP infrastructure should be configured to offer low address 2845 lease reclaiming the address even after the local mobility anchor 2846 deletes the mobile node's binding cache entry. It is recommended 2847 that the configured lease time be lower than the accepted binding 2848 lifetime for any mobility binding. 2850 6.12. Home Network Prefix Renumbering 2852 If the mobile node's home network prefix(es) gets renumbered or 2853 becomes invalid during the middle of a mobility session, the mobile 2854 access gateway MUST withdraw the prefix(es) by sending a Router 2855 Advertisement message on the access link with zero prefix lifetime 2856 for the prefix(es) that is being renumbered. Also, the local 2857 mobility anchor and the mobile access gateway MUST delete the created 2858 routing state for the renumbered prefix(es). However, the specific 2859 details on how the local mobility anchor notifies the mobile access 2860 gateway about the mobile node's home network prefix(es) renumbering 2861 are outside the scope of this document. 2863 6.13. Mobile Node Detachment Detection and Resource Cleanup 2865 Before sending a Proxy Binding Update message to the local mobility 2866 anchor for extending the lifetime of a currently existing binding of 2867 a mobile node, the mobile access gateway MUST make sure the mobile 2868 node is still attached to the connected link by using some reliable 2869 method. If the mobile access gateway cannot predictably detect the 2870 presence of the mobile node on the connected link, it MUST NOT 2871 attempt to extend the registration lifetime of the mobile node. 2872 Further, in such a scenario, the mobile access gateway SHOULD 2873 terminate the binding of the mobile node by sending a Proxy Binding 2874 Update message to the mobile node's local mobility anchor with 2875 lifetime value set to 0. It MUST also remove any local state such as 2876 the Binding Update List entry created for that mobile node. 2878 The specific detection mechanism of the loss of a visiting mobile 2879 node on the connected link is specific to the access link between the 2880 mobile node and the mobile access gateway and is outside the scope of 2881 this document. Typically, there are various link-layer specific 2882 events specific to each access technology that the mobile access 2883 gateway can depend on for detecting the node loss. In general, the 2884 mobile access gateway can depend on one or more of the following 2885 methods for the detection presence of the mobile node on the 2886 connected link: 2888 o Link-layer event specific to the access technology 2890 o PPP Session termination event on point-to-point link types 2891 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2893 o Notification event from the local mobility anchor 2895 6.14. Allowing network access to other IPv6 nodes 2897 In some Proxy Mobile IPv6 deployments, network operators may want to 2898 provision the mobile access gateway to offer network-based mobility 2899 management service only to some visiting mobile nodes and enable just 2900 regular IP access to some other nodes. This requires the network to 2901 have control on when to enable network-based mobility management 2902 service to a mobile node and when to enable regular IPv6 access. 2903 This specification does not disallow such configuration. 2905 Upon detecting a mobile node on its access link and after policy 2906 considerations, the mobile access gateway MUST determine if network- 2907 based mobility management service should be offered to that mobile 2908 node. If the mobile node is entitled for network-based mobility 2909 management service, then the mobile access gateway must ensure the 2910 mobile node believes it is on its home link, as explained in various 2911 sections of this specification. 2913 If the mobile node is not entitled for the network-based mobility 2914 management service, as determined from the policy considerations, the 2915 mobile access gateway MAY choose to offer regular IPv6 access to the 2916 mobile node and in such a scenario the normal IPv6 considerations 2917 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2918 obtain IPv6 address(es) using the normal IPv6 address configuration 2919 procedures. The obtained address(es) must be from a local visitor 2920 network prefix(es). This essentially ensures that the mobile access 2921 gateway functions as a normal access router to a mobile node attached 2922 to its access link and without impacting its host-based mobility 2923 protocol operation. 2925 7. Mobile Node Operation 2927 This non-normative section explains the mobile node's operation in a 2928 Proxy Mobile IPv6 domain. 2930 7.1. Moving into a Proxy Mobile IPv6 Domain 2932 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2933 an access network, the mobile access gateway on the access link 2934 detects the attachment of the mobile node and completes the binding 2935 registration with the mobile node's local mobility anchor. If the 2936 binding update operation is successfully performed, the mobile access 2937 gateway will create the required state and set up the data path for 2938 the mobile node's data traffic. 2940 If the mobile node is IPv6 enabled, on attaching to the access link, 2941 it will typically send a Router Solicitation message [RFC-4861]. The 2942 mobile access gateway on the access link will respond to the Router 2943 Solicitation message with a Router Advertisement message. The Router 2944 Advertisement message will carry the mobile node's home network 2945 prefix(es), default-router address and other address configuration 2946 Parameters. 2948 If the mobile access gateway on the access link receives a Router 2949 Solicitation message from the mobile node, before it completes the 2950 signaling with the mobile node's local mobility anchor, the mobile 2951 access gateway may not know the mobile node's home network prefix(es) 2952 and may not be able to emulate the mobile node's home link on the 2953 access link. In such a scenario, the mobile node may notice a delay 2954 before it receives a Router Advertisement message. This will also 2955 affect mobile nodes that would be capable of handling their own 2956 mobility, or mobile nodes that do not need to maintain the same IP 2957 address through movements. 2959 If the received Router Advertisement message has the Managed Address 2960 Configuration flag set, the mobile node, as it would normally do, 2961 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2962 enabled on that access link will ensure the mobile node can obtain 2963 one or more addresses and from its home network prefix(es). 2965 If the received Router Advertisement message does not have the 2966 Managed Address Configuration flag set and if the mobile node is 2967 allowed to use autoconfigured address(es), the mobile node will be 2968 able to obtain IPv6 address(es) and from each of its home network 2969 prefixes using any of the standard IPv6 address configuration 2970 mechanisms permitted for that mode. 2972 If the mobile node is IPv4 enabled and if the network permits, it 2973 will be able to obtain the IPv4 address configuration as specified in 2974 the companion document [ID-IPV4-PMIP6]. 2976 Once the address configuration is complete, the mobile node can 2977 continue to use this address configuration as long as it is attached 2978 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2980 7.2. Roaming in the Proxy Mobile IPv6 Domain 2982 After obtaining the address configuration in the Proxy Mobile IPv6 2983 domain, as the mobile node moves and changes its point of attachment 2984 from one mobile access gateway to the other, it can still continue to 2985 use the same address configuration. As long as the attached access 2986 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 2987 node will always detect the same default-router advertising the 2988 mobile node's home network prefix(es) on each connected link. If the 2989 mobile node has address configuration that it obtained using DHCPv6, 2990 it will be able to retain the address configuration and extend the 2991 lease lifetime. 2993 8. Message Formats 2995 This section defines extensions to the Mobile IPv6 [RFC-3775] 2996 protocol messages. 2998 8.1. Proxy Binding Update Message 3000 0 1 2 3 3001 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 3002 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3003 | Sequence # | 3004 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3005 |A|H|L|K|M|R|P| Reserved | Lifetime | 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 | | 3008 . . 3009 . Mobility options . 3010 . . 3012 | | 3013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3015 A Binding Update message that is sent by a mobile access gateway to a 3016 local mobility anchor is referred to as the "Proxy Binding Update" 3017 message. A new flag (P) is included in the Binding Update message. 3018 The rest of the Binding Update message format remains the same as 3019 defined in [RFC-3775] and with the additional (R) and (M) flags as 3020 specified in [RFC-3963] and [RFC-4140] respectively. 3022 Proxy Registration Flag (P) 3023 A new flag (P) is included in the Binding Update message to 3024 indicate to the local mobility anchor that the Binding Update 3025 message is a proxy registration. The flag MUST be set to the 3026 value of 1 for proxy registrations and MUST be set to 0 for direct 3027 registrations sent by a mobile node. 3029 Mobility Options 3031 Variable-length field of such length that the complete Mobility 3032 Header is an integer multiple of 8 octets long. This field 3033 contains zero or more TLV-encoded mobility options. The encoding 3034 and format of defined options are described in Section 6.2 of 3035 [RFC-3775]. The local mobility anchor MUST ignore and skip any 3036 options which it does not understand. 3038 As per this specification, the following mobility options are 3039 valid in a Proxy Binding Update message. These options can be 3040 present in the message in any order. There can be one or more 3041 instances of the Home Network Prefix options present in the 3042 message. However, there cannot be more than one instance of any 3043 of the other options. 3045 Mobile Node Identifier option 3047 Home Network Prefix option 3049 Handoff Indicator option 3051 Access Technology Type option 3053 Timestamp option 3055 Mobile Node Link-layer Identifier option 3057 Link-local Address option 3059 Additionally, there can one or more instances of the Vendor- 3060 Specific Mobility option [RFC-5094]. 3062 For descriptions of other fields present in this message, refer to 3063 section 6.1.7 of [RFC-3775]. 3065 8.2. Proxy Binding Acknowledgement Message 3067 0 1 2 3 3068 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 3069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3070 | Status |K|R|P|Reserved | 3071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3072 | Sequence # | Lifetime | 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 | | 3075 . . 3076 . Mobility options . 3077 . . 3078 | | 3079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 A Binding Acknowledgement message that is sent by a local mobility 3082 anchor to a mobile access gateway is referred to as the "Proxy 3083 Binding Acknowledgement" message. A new flag (P) is included in the 3084 Binding Acknowledgement message. The rest of the Binding 3085 Acknowledgement message format remains the same as defined in [RFC- 3086 3775] and with the additional (R) flag as specified in [RFC-3963]. 3088 Proxy Registration Flag (P) 3090 A new flag (P) is included in the Binding Acknowledgement message 3091 to indicate that the local mobility anchor that processed the 3092 corresponding Proxy Binding Update message supports proxy 3093 registrations. The flag is set to value of 1 only if the 3094 corresponding Proxy Binding Update had the Proxy Registration Flag 3095 (P) set to value of 1. 3097 Mobility Options 3099 Variable-length field of such length that the complete Mobility 3100 Header is an integer multiple of 8 octets long. This field 3101 contains zero or more TLV-encoded mobility options. The encoding 3102 and format of defined options are described in Section 6.2 of 3103 [RFC-3775]. The mobile access gateway MUST ignore and skip any 3104 options which it does not understand. 3106 As per this specification, the following mobility options are 3107 valid in a Proxy Binding Acknowledgement message. These options 3108 can be present in the message in any order. There can be one or 3109 more instances of the Home Network Prefix options present in the 3110 message. However, there cannot be more than one instance of any 3111 of the other options. 3113 Mobile Node Identifier option 3115 Home Network Prefix option 3117 Handoff Indicator option 3119 Access Technology Type option 3121 Timestamp option 3123 Mobile Node Link-layer Identifier option 3125 Link-local Address option 3127 Additionally, there can one or more instances of the Vendor- 3128 Specific Mobility option [RFC-5094]. 3130 Status 3132 8-bit unsigned integer indicating the disposition of the Proxy 3133 Binding Update. Values of the Status field less than 128 indicate 3134 that the Proxy Binding Update was accepted by the local mobility 3135 anchor. Values greater than or equal to 128 indicate that the 3136 binding registration was rejected by the local mobility anchor. 3137 Section 8.9 defines the Status values that can used in Proxy 3138 Binding Acknowledgement message. 3140 For descriptions of other fields present in this message, refer to 3141 the section 6.1.8 of [RFC-3775]. 3143 8.3. Home Network Prefix Option 3145 A new option, Home Network Prefix Option is defined for using it in 3146 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3147 exchanged between a local mobility anchor and a mobile access 3148 gateway. This option is used for exchanging the mobile node's home 3149 network prefix information. There can be multiple Home Network 3150 Prefix options present in the message. 3152 The Home Network Prefix Option has an alignment requirement of 8n+4. 3153 Its format is as follows: 3155 0 1 2 3 3156 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 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | Type | Length | Reserved | Prefix Length | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3160 | | 3161 + + 3162 | | 3163 + Home Network Prefix + 3164 | | 3165 + + 3166 | | 3167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3169 Type 3170 3172 Length 3174 8-bit unsigned integer indicating the length of the option 3175 in octets, excluding the type and length fields. This field 3176 MUST be set to 18. 3178 Reserved (R) 3180 This 8-bit field is unused for now. The value MUST be 3181 initialized to 0 by the sender and MUST be ignored by the 3182 receiver. 3184 Prefix Length 3186 8-bit unsigned integer indicating the prefix length of the 3187 IPv6 prefix contained in the option. 3189 Home Network Prefix 3191 A sixteen-byte field containing the mobile node's IPv6 Home 3192 Network Prefix. 3194 8.4. Handoff Indicator Option 3196 A new option, Handoff Indicator Option is defined for using it in the 3197 Proxy Binding Update and Proxy Binding Acknowledgement messages 3198 exchanged between a local mobility anchor and a mobile access 3199 gateway. This option is used for exchanging the mobile node's 3200 handoff related hints. 3202 The Handoff Indicator Option has no alignment requirement. Its 3203 format is as follows: 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 | Type | Length | Reserved (R) | HI | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3211 Type 3212 3214 Length 3216 8-bit unsigned integer indicating the length of the option 3217 in octets, excluding the type and length fields. This field 3218 MUST be set to 2. 3220 Reserved (R) 3222 This 8-bit field is unused for now. The value MUST be 3223 initialized to 0 by the sender and MUST be ignored by the 3224 receiver. 3226 Handoff Indicator (HI) 3228 A 8-bit field that specifies the type of handoff. The values 3229 (0 - 255) will be allocated and managed by IANA. The following 3230 values are currently defined. 3232 0: Reserved 3233 1: Attachment over a new interface 3234 2: Handoff between two different interfaces of the mobile node 3235 3: Handoff between mobile access gateways for the same interface 3236 4: Handoff state unknown 3237 5: Handoff state not changed (Re-registration) 3239 8.5. Access Technology Type Option 3241 A new option, Access Technology Type Option is defined for using it 3242 in the Proxy Binding Update and Proxy Binding Acknowledgement 3243 messages exchanged between a local mobility anchor and a mobile 3244 access gateway. This option is used for exchanging the type of the 3245 access technology using which the mobile node is currently attached 3246 to the mobile access gateway. 3248 The Access Technology Type Option has no alignment requirement. Its 3249 format is as follows: 3251 0 1 2 3 3252 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 3253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3254 | Type | Length | Reserved (R) | ATT | 3255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3257 Type 3258 3260 Length 3262 8-bit unsigned integer indicating the length of the option 3263 in octets, excluding the type and length fields. This field 3264 MUST be set to 2. 3266 Reserved (R) 3268 This 8-bit field is unused for now. The value MUST be 3269 initialized to 0 by the sender and MUST be ignored by the 3270 receiver. 3272 Access Technology Type (ATT) 3274 A 8-bit field that specifies the access technology through 3275 which the mobile node is connected to the access link on the 3276 mobile access gateway. 3278 The values (0 - 255) will be allocated and managed by IANA. The 3279 following values are currently reserved for the below specified 3280 access technology types. 3282 0: Reserved ("Reserved") 3283 1: Virtual ("Logical Network Interface") 3284 2: PPP ("Point-to-Point Protocol") 3285 3: IEEE 802.3 ("Ethernet") 3286 4: IEEE 802.11a/b/g ("Wireless LAN") 3287 5: IEEE 802.16e ("WIMAX") 3289 8.6. Mobile Node Link-layer Identifier Option 3291 A new option, Mobile Node Link-layer Identifier Option is defined for 3292 using it in the Proxy Binding Update and Proxy Binding 3293 Acknowledgement messages exchanged between a local mobility anchor 3294 and a mobile access gateway. This option is used for exchanging the 3295 mobile node's link-layer identifier. 3297 The format of the Link-layer Identifier option is shown below. Based 3298 on the size of the identifier, the option MUST be aligned 3299 appropriately, as per mobility option alignment requirements 3300 specified in [RFC-3775]. 3302 0 1 2 3 3303 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 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 | Type | Length | Reserved | 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | | 3308 + Link-layer Identifier + 3309 . ... . 3310 | | 3311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 Type 3314 3316 Length 3317 8-bit unsigned integer indicating the length of the option 3318 in octets, excluding the type and length fields. 3320 Reserved 3322 This field is unused for now. The value MUST be initialized to 3323 0 by the sender and MUST be ignored by the receiver. 3325 Link-layer Identifier 3327 A variable length field containing the mobile node's link-layer 3328 identifier. 3330 The content and format of this field (including byte and bit 3331 ordering) is as specified in Section 4.6 of [RFC-4861] for 3332 carrying Link-Layer Address. On certain access links, where 3333 the link-layer address is not used or cannot be determined, 3334 this option cannot be used. 3336 8.7. Link-local Address Option 3338 A new option, Link-local Address Option is defined for using it in 3339 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3340 exchanged between a local mobility anchor and a mobile access 3341 gateway. This option is used for exchanging the link-local address 3342 of the mobile access gateway. 3344 The Link-local Address option has an alignment requirement of 8n+6. 3345 Its format is as follows: 3347 0 1 2 3 3348 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 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3350 | Type | Length | 3351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3352 | | 3353 + + 3354 | | 3355 + Link-local Address + 3356 | | 3357 + + 3358 | | 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3361 Type 3362 3364 Length 3366 8-bit unsigned integer indicating the length of the option 3367 in octets, excluding the type and length fields. This field 3368 MUST be set to 16. 3370 Link-local Address 3372 A sixteen-byte field containing the mobile node's link-local 3373 address. 3375 8.8. Timestamp Option 3377 A new option, Timestamp Option is defined for use in the Proxy 3378 Binding Update and Proxy Binding Acknowledgement messages. 3380 The Timestamp option has an alignment requirement of 8n+2. Its 3381 format is as follows: 3383 0 1 2 3 3384 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 3385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3386 | Type | Length | 3387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3388 | | 3389 + Timestamp + 3390 | | 3391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3393 Type 3394 3396 Length 3398 8-bit unsigned integer indicating the length in octets of 3399 the option, excluding the type and length fields. The value 3400 for this field MUST be set to 8. 3402 Timestamp 3404 A 64-bit unsigned integer field containing a timestamp. The value 3405 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3406 by using a fixed point format. In this format, the integer number 3407 of seconds is contained in the first 48 bits of the field, and the 3408 remaining 16 bits indicate the number of 1/65536 fractions of a 3409 second. 3411 8.9. Status Values 3413 This document defines the following new Status values for use in 3414 Proxy Binding Acknowledgement message. These values are to be 3415 allocated from the same number space, as defined in Section 6.1.8 of 3416 [RFC-3775]. 3418 Status values less than 128 indicate that the Proxy Binding Update 3419 request was accepted by the local mobility anchor. Status values 3420 greater than 128 indicate that the Proxy Binding Update was rejected 3421 by the local mobility anchor. 3423 PROXY_REG_NOT_ENABLED: IANA 3425 Proxy registration not enabled for the mobile node 3427 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3429 Not local mobility anchor for this mobile node 3431 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3433 The mobile access gateway is not authorized to send proxy binding 3434 registrations 3436 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3438 The mobile node is not authorized for one or more of the 3439 requesting home network prefixes. 3441 TIMESTAMP_MISMATCH: IANA 3443 Invalid timestamp value (the clocks are out of sync) 3445 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3447 The timestamp value is lower than the previously accepted value 3449 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3451 Missing home network prefix option 3453 BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA 3455 All the home network prefixes listed in the BCE do not match all 3456 the prefixes in the received PBU 3458 MISSING_MN_IDENTIFIER_OPTION: IANA 3460 Missing mobile node identifier option 3462 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3464 Missing handoff indicator option 3466 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3468 Missing access technology type option 3470 Additionally, the following Status values defined in [RFC-3775] can 3471 also be used in Proxy Binding Acknowledgement message. 3473 0 Proxy Binding Update accepted 3475 128 Reason unspecified 3477 129 Administratively prohibited 3479 130 Insufficient resources 3481 9. Protocol Configuration Variables 3483 9.1. Local Mobility Anchor - Configuration Variables 3485 The local mobility anchor MUST allow the following variables to be 3486 configured by the system management. The configured values for these 3487 protocol variables MUST survive server reboots and service restarts. 3489 MinDelayBeforeBCEDelete 3491 This variable specifies the amount of time in milliseconds the 3492 local mobility anchor MUST wait before it deletes a Binding Cache 3493 entry of a mobile node, upon receiving a Proxy Binding Update 3494 message from a mobile access gateway with a lifetime value of 0. 3495 During this wait time, if the local mobility anchor receives a 3496 Proxy Binding Update for the same mobility binding, with lifetime 3497 value greater than 0, then it must update the binding cache entry 3498 with the accepted binding values. By the end of this wait-time, 3499 if the local mobility anchor did not receive any valid Proxy 3500 Binding Update message for that mobility binding, it MUST delete 3501 the Binding Cache entry. This delay essentially ensures a mobile 3502 node's Binding Cache entry is not deleted too quickly and allows 3503 some time for the new mobile access gateway to complete the 3504 signaling for the mobile node. 3506 The default value for this variable is 10000 milliseconds. 3508 MaxDelayBeforeNewBCEAssign 3510 This variable specifies the amount of time in milliseconds the 3511 local mobility anchor MUST wait for the de-registration message 3512 for an existing mobility session before it decides to create a new 3513 mobility session. 3515 The default value for this variable is 500 milliseconds. 3517 TimestampValidityWindow 3519 This variable specifies the maximum amount of time difference in 3520 milliseconds between the timestamp in the received Proxy Binding 3521 Update message and the current time-of-day on the local mobility 3522 anchor, that is allowed by the local mobility anchor for the 3523 received message to be considered valid. 3525 The default value for this variable is 300 milliseconds. This 3526 variable must be adjusted to suit the deployments. 3528 9.2. Mobile Access Gateway - Configuration Variables 3530 The mobile access gateway MUST allow the following variables to be 3531 configured by the system management. The configured values for these 3532 protocol variables MUST survive server reboots and service restarts. 3534 EnableMAGLocalRouting 3536 This flag indicates whether or not the mobile access gateway is 3537 allowed to enable local routing of the traffic exchanged between a 3538 visiting mobile node and a correspondent node that is locally 3539 connected to one of the interfaces of the mobile access gateway. 3540 The correspondent node can be another visiting mobile node as 3541 well, or a local fixed node. 3543 The default value for this flag is set to value of 0, indicating 3544 that the mobile access gateway MUST reverse tunnel all the traffic 3545 to the mobile node's local mobility anchor. 3547 When the value of this flag is set to value of 1, the mobile 3548 access gateway MUST route the traffic locally. 3550 This aspect of local routing MAY be defined as policy on a per 3551 mobile basis and when present will take precedence over this flag. 3553 9.3. Proxy Mobile IPv6 Domain - Configuration Variables 3555 All the mobile entities (local mobility anchors and mobile access 3556 gateways in a Proxy Mobile IPv6 domain MUST allow the following 3557 variables to be configured by the system management. The configured 3558 values for these protocol variables MUST survive server reboots and 3559 service restarts. These variables MUST be globally fixed for a given 3560 Proxy Mobile IPv6 domain resulting in the same values being enforced 3561 on all the mobility entities in that domain. 3563 MobileNodeGeneratedTimestampInUse 3565 This flag indicates whether or not the mobile node generated 3566 timestamp mechanism is in use in that Proxy Mobile IPv6 domain. 3567 When the value for this flag is set to 1, the local mobility 3568 anchors and mobile access gateways in that Proxy Mobile IPv6 3569 domain MUST apply the mobile node generated timestamp 3570 considerations. 3572 The default value for this flag is set to value of 0, indicating 3573 that the mobile node generated timestamp mechanism is not in use 3574 in that Proxy Mobile IPv6 domain. 3576 10. IANA Considerations 3578 This document defines six new Mobility Header options, the Home 3579 Network Prefix option, Handoff Indicator option, Access Technology 3580 Type option, Mobile Node Link-layer Identifier option, Link-local 3581 Address option and Timestamp option. These options are described in 3582 Section 8. The Type value for these options needs to be assigned 3583 from the same numbering space as allocated for the other mobility 3584 options, as defined in [RFC-3775]. 3586 The Handoff Indicator option defined in Section 8.4 of this document 3587 introduces a new Handoff Indicator (HI) numbering space, where the 3588 values from 0 to 5 have been reserved by this document. Approval of 3589 new Handoff Indicator type values are to be made through IANA Expert 3590 Review. 3592 The Access Technology Type option defined in Section 8.5 of this 3593 document introduces a new Access Technology type (ATT) numbering 3594 space, where the values from 0 to 5 have been reserved by this 3595 document. Approval of new Access Technology type values are to be 3596 made through IANA Expert Review. 3598 This document also defines new Binding Acknowledgement status values 3599 as described in Section 8.9. The status values MUST be assigned from 3600 the same number space used for Binding Acknowledgement status values, 3601 as defined in [RFC-3775]. The allocated values for each of these 3602 status values must be greater than 128. 3604 11. Security Considerations 3606 The potential security threats against any network-based mobility 3607 management protocol are described in [RFC-4832]. This section 3608 explains how Proxy Mobile IPv6 protocol defends itself against those 3609 threats. 3611 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3612 Binding Update and Proxy Binding Acknowledgement, exchanged between 3613 the mobile access gateway and the local mobility anchor to be 3614 protected using IPsec, using the established security association 3615 between them. This essentially eliminates the threats related to the 3616 impersonation of the mobile access gateway or the local mobility 3617 anchor. 3619 This specification allows a mobile access gateway to send binding 3620 registration messages on behalf of a mobile node. If proper 3621 authorization checks are not in place, a malicious node may be able 3622 to hijack a mobile node's session or may carry out a denial-of- 3623 service attack. To prevent this attack, this specification requires 3624 the local mobility anchor to allow only authorized mobile access 3625 gateways that are part of that Proxy Mobile IPv6 domain to send 3626 binding registration messages on behalf of a mobile node. 3628 To eliminate the threats on the interface between the mobile access 3629 gateway and the mobile node, this specification requires an 3630 established trust between the mobile access gateway and the mobile 3631 node and to authenticate and authorize the mobile node before it is 3632 allowed to access the network. Further, the established 3633 authentication mechanisms enabled on that access link will ensure 3634 that there is a secure binding between the mobile node's identity and 3635 its link-layer address. The mobile access gateway will definitively 3636 identify the mobile node from the packets that it receives on that 3637 access link. 3639 To address the threat related to a compromised mobile access gateway, 3640 the local mobility anchor, before accepting a Proxy Binding Update 3641 message for a given mobile node, may ensure that the mobile node is 3642 definitively attached to the mobile access gateway that sent the 3643 proxy binding registration request. This may be accomplished by 3644 contacting a trusted entity which is able to track the mobile node's 3645 current point of attachment. However, the specific details of the 3646 actual mechanisms for achieving this is outside the scope of this 3647 document. 3649 12. Acknowledgements 3651 The authors would like to specially thank Jari Arkko, Julien 3652 Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, 3653 Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their 3654 thorough review of this document. 3656 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3657 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3658 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3659 Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- 3660 Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3661 Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed 3662 Khalil, Nishida Katsutoshi, Phil Roberts, Ralph Droms, Ryuji 3663 Wakikawa, Sangjin Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, 3664 Vidya Narayanan, Youn-Hee Han and many others for their passionate 3665 discussions in the working group mailing list on the topic of 3666 localized mobility management solutions. These discussions 3667 stimulated much of the thinking and shaped the draft to the current 3668 form and we acknowledge that ! 3670 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3671 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer, Tim 3672 Stammers, Bernie Volz and Josh Littlefield for their input on this 3673 document. 3675 13. References 3676 13.1. Normative References 3678 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3679 Requirement Levels", BCP 14, RFC 2119, March 1997. 3681 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3682 IPv6 Specification", RFC 2473, December 1998. 3684 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3685 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3686 RFC 3315, July 2003. 3688 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3689 IPv6", RFC 3775, June 2004. 3691 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3692 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3693 January 2005. 3695 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3696 Network Access Identifier", RFC 4282, December 2005. 3698 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3699 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3700 November 2005. 3702 [RFC-4291] Hinden, R., Deering, S., "IP Version 6 Addressing 3703 Architecture", RFC 4291, February 2006. 3705 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3706 Internet Protocol", RFC 4301, December 2005. 3708 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3709 4303, December 2005. 3711 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3712 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3713 2007. 3715 13.2. Informative References 3717 [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3718 for IP version 6", RFC 1981, August 1996. 3720 [RFC-2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3721 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 3722 2000. 3724 [RFC-3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3725 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3727 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3728 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3729 2005. 3731 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3732 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3733 4140, August 2005. 3735 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3736 Protocol", RFC 4306, December 2005. 3738 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3739 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3741 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3742 "Chargeable User Identity", RFC 4372, January 2006. 3744 [RFC-4821] Mathis, M. and Heffner, J., "Packetization Layer Path MTU 3745 Discovery", RFC 4821, March 2007. 3747 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3748 G., Liebsch, M., "Problem Statement for Network-based Localized 3749 Mobility Management", September 2006. 3751 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3752 G., Liebsch, M., "Goals for Network-based Localized Mobility 3753 Management", October 2006. 3755 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3756 Localized Mobility Management", September 2006. 3758 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3759 Address Autoconfiguration", RFC 4862, September 2007. 3761 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3762 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3763 2007. 3765 [RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6 3766 Vendor Specific Option", RFC 5094, December 2007. 3768 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3769 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3770 November 2007. 3772 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 3773 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. 3775 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3777 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3778 typically be identified by an identifier, MN-Identifier, and that 3779 identifier will have an associated policy profile that identifies the 3780 mobile node's home network prefix(es) on a per-interface basis, 3781 permitted address configuration modes, roaming policy and other 3782 parameters that are essential for providing network-based mobility 3783 management service. This information is typically configured in AAA. 3784 In some cases, the home network prefix(es) may be dynamically 3785 assigned to the mobile node's interface, after its initial attachment 3786 to the Proxy Mobile IPv6 domain over that interface and may not be 3787 configured in the mobile node's policy profile. 3789 The network entities in the proxy Mobile IPv6 domain, while serving a 3790 mobile node will have access to the mobile node's policy profile and 3791 these entities can query this information using RADIUS [RFC-2865] or 3792 DIAMETER [RFC-3588] protocols. 3794 Appendix B. Routing State 3796 The following section explains the routing state created for a mobile 3797 node on the mobile access gateway. This routing state reflects only 3798 one specific way of implementation and one MAY choose to implement it 3799 in other ways. The policy based route defined below acts as a 3800 traffic selection rule for routing a mobile node's traffic through a 3801 specific tunnel created between the mobile access gateway and that 3802 mobile node's local mobility anchor and with the specific 3803 encapsulation mode, as negotiated. 3805 The below example identifies the routing state for two visiting 3806 mobile nodes, MN1 and MN2 with their respective local mobility 3807 anchors LMA1 and LMA2. 3809 For all traffic from the mobile node, identified by the mobile node's 3810 MAC address, ingress interface or source prefix (MN-HNP) to 3811 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3813 +==================================================================+ 3814 | Packet Source | Destination Address | Destination Interface | 3815 +==================================================================+ 3816 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3817 | (IPv6 Prefix or |----------------------------------------------| 3818 | Input Interface) | Locally Connected | Tunnel0 | 3819 +------------------------------------------------------------------+ 3820 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3821 + (IPv6 Prefix or -----------------------------------------------| 3822 | Input Interface | Locally Connected | direct | 3823 +------------------------------------------------------------------+ 3825 Figure 24: Example - Policy based Route Table 3827 +==================================================================+ 3828 | Interface | Source Address | Destination Address | Encapsulation | 3829 +==================================================================+ 3830 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3831 +------------------------------------------------------------------+ 3832 | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | 3833 +------------------------------------------------------------------+ 3835 Figure 25: Example - Tunnel Interface Table 3837 Authors' Addresses 3839 Sri Gundavelli 3840 Cisco 3841 170 West Tasman Drive 3842 San Jose, CA 95134 3843 USA 3845 Email: sgundave@cisco.com 3847 Kent Leung 3848 Cisco 3849 170 West Tasman Drive 3850 San Jose, CA 95134 3851 USA 3853 Email: kleung@cisco.com 3854 Vijay Devarapalli 3855 Wichorus 3856 3590 North First Street 3857 San Jose, CA 95134 3858 USA 3860 Email: vijay@wichorus.com 3862 Kuntal Chowdhury 3863 Starent Networks 3864 30 International Place 3865 Tewksbury, MA 3867 Email: kchowdhury@starentnetworks.com 3869 Basavaraj Patil 3870 Nokia Siemens Networks 3871 6000 Connection Drive 3872 Irving, TX 75039 3873 USA 3875 Email: basavaraj.patil@nsn.com 3877 Full Copyright Statement 3879 Copyright (C) The IETF Trust (2008). 3881 This document is subject to the rights, licenses and restrictions 3882 contained in BCP 78, and except as set forth therein, the authors 3883 retain all their rights. 3885 This document and the information contained herein are provided on an 3886 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3887 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3888 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3889 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3890 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3891 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3893 Intellectual Property 3895 The IETF takes no position regarding the validity or scope of any 3896 Intellectual Property Rights or other rights that might be claimed to 3897 pertain to the implementation or use of the technology described in 3898 this document or the extent to which any license under such rights 3899 might or might not be available; nor does it represent that it has 3900 made any independent effort to identify any such rights. Information 3901 on the procedures with respect to rights in RFC documents can be 3902 found in BCP 78 and BCP 79. 3904 Copies of IPR disclosures made to the IETF Secretariat and any 3905 assurances of licenses to be made available, or the result of an 3906 attempt made to obtain a general license or permission for the use of 3907 such proprietary rights by implementers or users of this 3908 specification can be obtained from the IETF on-line IPR repository at 3909 http://www.ietf.org/ipr. 3911 The IETF invites any interested party to bring to its attention any 3912 copyrights, patents or patent applications, or other proprietary 3913 rights that may cover technology that may be required to implement 3914 this standard. Please address the information to the IETF at 3915 ietf-ipr@ietf.org. 3917 Acknowledgment 3919 Funding for the RFC Editor function is provided by the IETF 3920 Administrative Support Activity (IASA).