idnits 2.17.1 draft-ietf-netlmm-proxymip6-14.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 3875. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3886. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3893. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3899. 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 13, 2008) is 5828 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) == Missing Reference: 'P1' is mentioned on line 2773, but not defined == Missing Reference: 'P2' is mentioned on line 2773, but not defined == Missing Reference: 'Pn' is mentioned on line 2774, but not defined == Missing Reference: 'P5' is mentioned on line 2774, but not defined == Missing Reference: 'P6' is mentioned on line 2774, but not defined == Missing Reference: 'P7' is mentioned on line 2774, but not defined == Missing Reference: 'P8' is mentioned on line 2774, but not defined == Missing Reference: 'Pm-1' is mentioned on line 2774, but not defined == Missing Reference: 'Pm' is mentioned on line 2774, but not defined == Unused Reference: 'RFC-1661' is defined on line 3702, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4140 (Obsoleted by RFC 5380) ** 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 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: 5 errors (**), 0 flaws (~~), 13 warnings (==), 13 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 14, 2008 V. Devarapalli 6 Wichorus 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 May 13, 2008 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-14.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 14, 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 . . . . . . . . . 44 95 6.9. Signaling Considerations . . . . . . . . . . . . . . . . . 45 96 6.9.1. Binding Registrations . . . . . . . . . . . . . . . . 45 97 6.9.2. Router Solicitation Messages . . . . . . . . . . . . . 54 98 6.9.3. Default-Router . . . . . . . . . . . . . . . . . . . . 55 99 6.9.4. Retransmissions and Rate Limiting . . . . . . . . . . 55 100 6.9.5. Path MTU Discovery . . . . . . . . . . . . . . . . . . 56 101 6.10. Routing Considerations . . . . . . . . . . . . . . . . . . 57 102 6.10.1. Transport Network . . . . . . . . . . . . . . . . . . 57 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 . . . . . . . . . . . . . 62 110 6.13. Mobile Node Detachment Detection and Resource Cleanup . . 63 111 6.14. Allowing network access to other IPv6 nodes . . . . . . . 63 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 . . . . . . . . . . . . . . . . . . . . . . . 65 116 8.1. Proxy Binding Update Message . . . . . . . . . . . . . . . 66 117 8.2. Proxy Binding Acknowledgement Message . . . . . . . . . . 67 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 . . . . . . . . . . . . . . . . . . . 81 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. This protocol may also be used on other 1867 link types, as long as the link is configured in such a way that it 1868 emulates point-to-point delivery between the mobile node and the 1869 mobile access gateway for all the protocol traffic. 1871 6.4. Supported Address Configuration Modes 1873 A mobile node in the Proxy Mobile IPv6 domain can configure one or 1874 more global IPv6 addresses on its interface (using Stateless, 1875 Stateful or manual address autoconfiguration procedures) from the 1876 hosted prefix(es) on that link. The Router Advertisement messages 1877 sent on the access link specify the address configuration methods 1878 permitted on that access link for that mobile node. However, the 1879 advertised flags with respect to the address configuration will be 1880 consistent for a mobile node, on any of the access links in that 1881 Proxy Mobile IPv6 domain. Typically, these configuration settings 1882 will be based on the domain wide policy or based on a policy specific 1883 to each mobile node. 1885 When stateless address autoconfiguration is supported on the access 1886 link, the mobile node can generate one or more IPv6 addresses from 1887 the hosted prefix(es) by standard IPv6 mechanisms such as Stateless 1888 Autoconfiguration [RFC-4862] or Privacy extensions [RFC-4941]. 1890 When stateful address autoconfiguration is supported on the link, the 1891 mobile node can obtain the address configuration from the DHCPv6 1892 server located in the Proxy Mobile IPv6 domain, by standard DHCPv6 1893 mechanisms, as specified in [RFC-3315]. The obtained address(es) 1894 will be from its home network prefix(es). Section 6.11 specifies the 1895 details on how this configuration can be achieved. 1897 Additionally, other address configuration mechanisms specific to the 1898 access link between the mobile node and the mobile access gateway may 1899 also be used for delivering the address configuration to the mobile 1900 node. This specification does not modify the behavior of any of the 1901 standard IPv6 address configuration mechanisms. 1903 6.5. Access Authentication & Mobile Node Identification 1905 When a mobile node attaches to an access link connected to the mobile 1906 access gateway, the deployed access security protocols on that link 1907 SHOULD ensure that the network-based mobility management service is 1908 offered only after authenticating and authorizing the mobile node for 1909 that service. The exact specifics on how this is achieved or the 1910 interactions between the mobile access gateway and the access 1911 security service is outside the scope of this document. This 1912 specification goes with the stated assumption of having an 1913 established trust between the mobile node and the mobile access 1914 gateway, before the protocol operation begins. 1916 6.6. Acquiring Mobile Node's Identifier 1918 All the network entities in a Proxy Mobile IPv6 domain MUST be able 1919 to identify a mobile node, using its MN-Identifier. This identifier 1920 MUST be stable and unique across the Proxy Mobile IPv6 domain. The 1921 mobility entities in the Proxy Mobile IPv6 domain MUST be able to use 1922 this identifier in the signaling messages and unambiguously identify 1923 a given mobile node. Following are some of the considerations 1924 related to this MN-Identifier. 1926 o The MN-Identifier is typically obtained as part of the access 1927 authentication or from a notified network attachment event. In 1928 cases where the user identifier authenticated during access 1929 authentication uniquely identifies a mobile node, the MN- 1930 Identifier MAY be the same as the user identifier. However, the 1931 user identifier MUST NOT be used if it identifies a user account 1932 that can be used from more than one mobile node operating in the 1933 same Proxy Mobile IPv6 domain. 1935 o In some cases, the obtained identifier as part of the access 1936 authentication can be a temporary identifier and further that 1937 temporary identifier may be different at each re-authentication. 1938 However, the mobile access gateway MUST be able to use this 1939 temporary identifier and obtain the mobile node's stable 1940 identifier from the policy store. For instance, in AAA-based 1941 systems the RADIUS attribute, Chargeable-User-Identifier [RFC- 1942 4372] may be used, as long as it uniquely identifies a mobile 1943 node, and not a user account that can be used with multiple mobile 1944 nodes. 1946 o In some cases and for privacy reasons, the MN-Identifier that the 1947 policy store delivers to the mobile access gateway may not be the 1948 true identifier of the mobile node. However, the mobility access 1949 gateway MUST be able to use this identifier in the signaling 1950 messages exchanged with the local mobility anchor. 1952 o The mobile access gateway MUST be able to identify the mobile node 1953 by its MN-Identifier and it MUST be able to associate this 1954 identity to the point-to-point link shared with the mobile node. 1956 6.7. Home Network Emulation 1958 One of the key functions of a mobile access gateway is to emulate the 1959 mobile node's home network on the access link. It must ensure, the 1960 mobile node believes it is still connected to its home link or on the 1961 link where it obtained its initial address configuration after it 1962 moved into that Proxy Mobile IPv6 domain. 1964 For emulating the mobile node's home link on the access link, the 1965 mobile access gateway must be able to send Router Advertisement 1966 messages advertising the mobile node's home network prefix(es) 1967 carried using the Prefix Information option(s) [RFC-4861] and with 1968 other address configuration parameters consistent with its home link 1969 properties. Typically, these configuration settings will be based on 1970 the domain wide policy or based on a policy specific to each mobile 1971 node. 1973 Typically, the mobile access gateway learns the mobile node's home 1974 network prefix(es) details from the received Proxy Binding 1975 Acknowledgement message or it may obtain them from the mobile node's 1976 policy profile. However, the mobile access gateway SHOULD send the 1977 Router Advertisements advertising the mobile node's home network 1978 prefix(es) only after successfully completing the binding 1979 registration with the mobile node's local mobility anchor. 1981 When advertising the home network prefix(es) in the Router 1982 Advertisement messages, the mobile access gateway MAY set the prefix 1983 lifetime value for the advertised prefix(es) to any chosen value at 1984 its own discretion. An implementation MAY choose to tie the prefix 1985 lifetime to the mobile node's binding lifetime. The prefix lifetime 1986 can also be an optional configuration parameter in the mobile node's 1987 policy profile. 1989 6.8. Link-Local and Global Address Uniqueness 1991 A mobile node in the Proxy Mobile IPv6 domain, as it moves from one 1992 mobile access gateway to the other, will continue to detect its home 1993 network and thus believe it is still on the same link. Every time 1994 the mobile node attaches to a new link, the event related to the 1995 interface state change will trigger the mobile node to perform DAD 1996 operation on the link-local and global address(es). However, if the 1997 mobile node is DNAv6 enabled, as specified in [ID-DNAV6], it may not 1998 detect the link change due to DNAv6 optimizations and may not trigger 1999 the duplicate address detection (DAD) procedure for its existing 2000 addresses, which may potentially lead to address collisions after the 2001 mobile node's handoff to a new link. 2003 The issue of address collision is not relevant to the mobile node's 2004 global address(es). Since the assigned home network prefix(es) are 2005 for the mobile node's exclusive usage, no other node shares an 2006 address (other than Subnet-Router anycast address which is configured 2007 by the mobile access gateway) from the prefix(es) and so the 2008 uniqueness for the mobile node's global address is assured on the 2009 access link. 2011 The issue of address collision is however relevant to the mobile 2012 node's link-local addresses since the mobile access gateway and the 2013 mobile node will have link-local addresses configured from the same 2014 link-local prefix (FE80::/64). This leaves a room for link-local 2015 address collision between the two neighbors (i.e., the mobile node 2016 and the mobile access gateway) on that access link. For solving this 2017 problem, this specification requires that the link-local address that 2018 the mobile access gateway configures on the point-to-point link 2019 shared with a given mobile node be generated by the local mobility 2020 anchor and be stored in the mobile node's Binding Cache entry. This 2021 address will not change for the duration of that mobile node's 2022 session and can be provided to the serving mobile access gateway at 2023 every mobile node's handoff, as part of the Proxy Mobile IPv6 2024 signaling messages. The specific method by which the local mobility 2025 anchor generates the link-local address is out of scope for this 2026 specification. 2028 Optionally, implementations MAY choose to configure a fixed link- 2029 local address across all the access links in a Proxy Mobile IPv6 2030 domain and without a need for carrying this address from the local 2031 mobility anchor to the mobile access gateway in the Proxy Mobile IPv6 2032 signaling messages. 2034 6.9. Signaling Considerations 2036 6.9.1. Binding Registrations 2038 6.9.1.1. Mobile Node Attachment and Initial Binding Registration 2040 1. After detecting a new mobile node on its access link, the mobile 2041 access gateway MUST identify the mobile node and acquire its MN- 2042 Identifier. If it determines that the network-based mobility 2043 management service needs to be offered to the mobile node, it 2044 MUST send a Proxy Binding Update message to the local mobility 2045 anchor. 2047 2. The Proxy Binding Update message MUST include the Mobile Node 2048 Identifier option [RFC-4283], carrying the MN-Identifier for 2049 identifying the mobile node. 2051 3. The Home Network Prefix option(s) MUST be present in the Proxy 2052 Binding Update message. If the mobile access gateway learns the 2053 mobile node's home network prefix(es) either from its policy 2054 store or from other means, the mobile access gateway MAY choose 2055 to request the local mobility anchor to allocate the requested 2056 prefix(es) by including a Home Network Prefix option for each of 2057 those requested prefixes. The mobile access gateway MAY also 2058 choose to include just one Home Network Prefix option with the 2059 prefix value of ALL_ZERO, for requesting the local mobility 2060 anchor to do the prefix assignment. However, when including a 2061 Home Network Prefix option with the prefix value of ALL_ZERO, 2062 then there MUST be only one instance of the Home Network prefix 2063 option in the request. 2065 4. The Handoff Indicator option MUST be present in the Proxy 2066 Binding Update message. The Handoff Indicator field in the 2067 Handoff Indicator option MUST be set to a value indicating the 2068 handoff hint. 2070 * The Handoff Indicator field MUST be set to value 1 2071 (Attachment over a new interface), if the mobile access 2072 gateway determines (under the Handoff Indicator 2073 considerations specified in this section) that the mobile 2074 node's current attachment to the network over this interface 2075 is not as a result of a handoff of an existing mobility 2076 session (over the same interface or through a different 2077 interface), but as a result of an attachment over a new 2078 interface. This essentially serves as a request to the local 2079 mobility anchor to create a new mobility session and not 2080 update any existing Binding Cache entry created for the same 2081 mobile node connected to the Proxy Mobile IPv6 domain through 2082 a different interface. 2084 * The Handoff Indicator field MUST be set to value 2 (Handoff 2085 between two different interfaces of the mobile node), if the 2086 mobile access gateway definitively knows the mobile node's 2087 current attachment is due to a handoff of an existing 2088 mobility session, between two different interfaces of the 2089 mobile node. 2091 * The Handoff Indicator field MUST be set to value 3 (Handoff 2092 between mobile access gateways for the same interface), if 2093 the mobile access gateway definitively knows the mobile 2094 node's current attachment is due to a handoff of an existing 2095 mobility session between two mobile access gateways and for 2096 the same interface of the mobile node. 2098 * The Handoff Indicator field MUST be set to value 4 (Handoff 2099 state unknown), if the mobile access gateway cannot determine 2100 if the mobile node's current attachment is due to a handoff 2101 of an existing mobility session. 2103 5. The mobile access gateway MUST apply the below considerations 2104 when choosing the value for the Handoff Indicator field. 2106 * The mobile access gateway can choose to use the value 2 2107 (Handoff between two different interfaces of the mobile 2108 node), only when it knows that the mobile node has on purpose 2109 switched from one interface to another, and the previous 2110 interface is going to be disabled. It may know this due to a 2111 number of factors. For instance, most cellular networks have 2112 controlled handovers where the network knows that the host is 2113 moving from one attachment to another. In this situation the 2114 link layer mechanism can inform the mobility functions that 2115 this is indeed a movement, not a new attachment. 2117 * Some link layers have link-layer identifiers that can be used 2118 to distinguish (a) the movement of a particular interface to 2119 a new attachment from (b) the attachment of a new interface 2120 from the same host. Option value 3 (Handoff between mobile 2121 access gateways for the same interface)is appropriate in case 2122 a and value of 1 (Attachment over a new interface) in case b. 2124 * The mobile access gateway MUST NOT set the option value to 2 2125 (Handoff between two different interfaces of the mobile node) 2126 or 3 (Handoff between mobile access gateways for the same 2127 interface) if it can not be determined that the mobile node 2128 can move the address between the interfaces involved in the 2129 handover or that it is the same interface that has moved. 2130 Otherwise Proxy Mobile IPv6-unaware hosts that have multiple 2131 physical interfaces to the same domain may suffer unexpected 2132 failures. 2134 * Where no support from the link layer exists, the host and the 2135 network would need to inform each other about the intended 2136 movement. The Proxy Mobile IPv6 protocol does not specify 2137 this and simply requires that knowledge about movements can 2138 be derived either from the link-layer or from somewhere else. 2140 The method by which this is accomplished is outside the scope 2141 of this specification. 2143 6. Either the Timestamp option or a valid sequence number 2144 maintained on a per mobile node basis (if the Sequence Number 2145 based scheme is in use) MUST be present. When Timestamp option 2146 is added to the message, the mobile access gateway SHOULD also 2147 set the Sequence Number field to a value of a monotonically 2148 increasing counter (not to be confused with the per mobile node 2149 sequence number specified in [RFC-3775]). The local mobility 2150 anchor will ignore this field when there is a Timestamp option 2151 present in the request, but will return the same value in the 2152 Proxy Binding Acknowledgement message. This will be useful for 2153 matching the reply to the request message. 2155 7. The Mobile Node Link-layer Identifier option carrying the link- 2156 layer identifier of the currently attached interface MUST be 2157 present in the Proxy Binding Update message, if the mobile 2158 access gateway is aware of the same. If the link-layer 2159 identifier of the currently attached interface is not known or 2160 if the identifier value is ALL_ZERO, this option MUST NOT be 2161 present. 2163 8. The Access Technology Type option MUST be present in the Proxy 2164 Binding Update message. The access technology type field in the 2165 option SHOULD be set to the type of access technology using 2166 which the mobile node is currently attached to the mobile access 2167 gateway. 2169 9. The Link-local Address option MAY be present in the Proxy 2170 Binding Update message. Considerations from Section 6.8 MUST be 2171 applied when using the link-local address option. 2173 * When querying the local mobility anchor for the link-local 2174 address that it should use on the point-to-point link shared 2175 with the mobile node, this option MUST be set to ALL_ZERO. 2176 This essentially serves as a request to the local mobility 2177 anchor to provide the link-local address that it can use on 2178 the access link shared with the mobile node. 2180 * When uploading the link-local address to the local mobility 2181 anchor, the value in the option MUST be set to the link-local 2182 address that is configured on the point-to-point link shared 2183 with the mobile node. This is allowed only during an initial 2184 mobile node's attachment. 2186 10. The Proxy Binding Update message MUST be constructed as 2187 specified in Section 6.9.1.5. 2189 11. If there is no existing Binding Update List entry for that 2190 mobile node, the mobile access gateway MUST create a Binding 2191 Update List entry for the mobile node upon sending the Proxy 2192 Binding Update request. 2194 6.9.1.2. Receiving Binding Registration Reply 2196 On receiving a Proxy Binding Acknowledgement message (format 2197 specified in Section 8.2) from the local mobility anchor, the mobile 2198 access gateway MUST process the message as specified below. 2200 1. The received Proxy Binding Acknowledgement message (a Binding 2201 Acknowledgement message with the 'P' flag set to value of 1) 2202 MUST be authenticated as described in Section 4. When IPsec is 2203 used for message authentication, the SPI in the IPsec header 2204 [RFC-4306] of the received packet is needed for locating the 2205 security association, for authenticating the Proxy Binding 2206 Acknowledgement message. 2208 2. The mobile access gateway MUST observe the rules described in 2209 Section 9.2 of [RFC-3775] when processing Mobility Headers in 2210 the received Proxy Binding Acknowledgement message. 2212 3. The mobile access gateway MUST apply the considerations 2213 specified in Section 5.5 for processing the Sequence Number 2214 field and the Timestamp option (if present), in the message. 2216 4. The mobile access gateway MUST ignore any checks, specified in 2217 [RFC-3775] related to the presence of a Type 2 Routing header in 2218 the Proxy Binding Acknowledgement message. 2220 5. The mobile access gateway MAY use the mobile node identifier 2221 present in the Mobile Node Identifier option for matching the 2222 response to the request messages that it sent recently. 2223 However, if there is more than one request message in its 2224 request queue for the same mobile node, the sequence number 2225 field can be used for identifying the exact message from those 2226 messages. There are other ways to achieve this and 2227 implementations are free to adopt the best approach that suits 2228 their implementation. Additionally, if the received Proxy 2229 Binding Acknowledgement message does not match any of the Proxy 2230 Binding Update messages that it sent recently, the message MUST 2231 be ignored. 2233 6. If the received Proxy Binding Acknowledgement message has any 2234 one or more of the following options, Handoff Indicator option, 2235 Access Technology Type option, Mobile Node Link-layer Identifier 2236 option, Mobile Node Identifier option, carrying option values 2237 that are different from the option values present in the 2238 corresponding request (Proxy Binding Update) message, the 2239 message MUST be ignored as the local mobility anchor is expected 2240 to echo back all these listed options and with the same option 2241 values in the reply message. Further, the mobile access gateway 2242 MUST NOT retransmit the Proxy Binding Update message till an 2243 administrative action is taken. 2245 7. If the received Proxy Binding Acknowledgement message has the 2246 Status field value set to PROXY_REG_NOT_ENABLED (Proxy 2247 registration not enabled for the mobile node), the mobile access 2248 gateway SHOULD NOT send binding registration requests again for 2249 that mobile node. It MUST deny the mobility service to that 2250 mobile node. 2252 8. If the received Proxy Binding Acknowledgement message has the 2253 Status field value set to TIMESTAMP_LOWER_THAN_PREV_ACCEPTED 2254 (Timestamp value lower than previously accepted value), the 2255 mobile access gateway SHOULD try to register again to reassert 2256 the mobile node's presence on its access link. The mobile 2257 access gateway is not specifically required to synchronize its 2258 clock upon receiving this error code. 2260 9. If the received Proxy Binding Acknowledgement message has the 2261 Status field value set to TIMESTAMP_MISMATCH (Invalid timestamp 2262 value), the mobile access gateway SHOULD try to register again 2263 only after it has synchronized its clock to a common time source 2264 that is used by all the mobility entities in that domain for 2265 their clock synchronization. The mobile access gateway SHOULD 2266 NOT synchronize its clock to the local mobility anchor's system 2267 clock, based on the timestamp present in the received message. 2269 10. If the received Proxy Binding Acknowledgement message has the 2270 Status field value set to NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX 2271 (The mobile node is not authorized for one or more of the 2272 requesting home network prefix(es)), the mobile access gateway 2273 SHOULD NOT request for the same prefix(es) again, but can only 2274 request the local mobility anchor to do the assignment of 2275 prefix(es) by including only one Home Network Prefix option with 2276 the prefix value set to ALL_ZERO. 2278 11. If the received Proxy Binding Acknowledgement message has the 2279 Status field value set to any value greater than or equal to 128 2280 (i.e., if the binding is rejected), the mobile access gateway 2281 MUST NOT advertise the mobile node's home network prefix(es) in 2282 the Router Advertisement messages sent on that access link and 2283 MUST deny the mobility service to the mobile node by not 2284 forwarding any packets received from the mobile node using an 2285 address from the home network prefix(es). It MAY also tear down 2286 the point-to-point link shared with the mobile node. 2288 12. If the received Proxy Binding Acknowledgement message has the 2289 Status field value set to 0 (Proxy Binding Update accepted), the 2290 mobile access gateway MUST establish a bi-directional tunnel to 2291 the local mobility anchor (if there is no existing bi- 2292 directional tunnel to that local mobility anchor). 2293 Considerations from Section 5.6.1 MUST be applied for managing 2294 the dynamically created bi-directional tunnel. 2296 13. The mobile access gateway MUST set up the route for forwarding 2297 the packets received from the mobile node using address(es) from 2298 its home network prefix(es) through the bi-directional set up 2299 for that mobile node. The created tunnel and the routing state 2300 MUST result in the forwarding behavior on the mobile access 2301 gateway as specified in Section 6.10.5. 2303 14. The mobile access gateway MUST also update the Binding Update 2304 List entry for reflecting the accepted binding registration 2305 values. It MUST also advertise the mobile node's home network 2306 prefix(es) as the hosted on-link prefixes, by including them in 2307 the Router Advertisement messages that it sends on that access 2308 link. 2310 15. If the received Proxy Binding Acknowledgement message has the 2311 address in the Link-local Address option set to a NON_ZERO 2312 value, the mobile access gateway MUST configure that link-local 2313 address on that point-to-point link and MUST NOT configure any 2314 other link-local address on that point-to-point link. This will 2315 avoid any link-local address collisions with the mobile node on 2316 that access link. 2318 6.9.1.3. Extending Binding Lifetime 2320 1. For extending the lifetime of a currently registered mobile node 2321 (i.e., after a successful initial binding registration from the 2322 same mobile access gateway), the mobile access gateway can send a 2323 Proxy Binding Update message to the local mobility anchor with a 2324 new lifetime value. This re-registration message MUST be 2325 constructed with the same set of options as the initial binding 2326 registration message, under the considerations specified in 2327 Section 6.9.1.1. However the following exceptions apply. 2329 2. There MUST be a Home Network Prefix option for each of the 2330 assigned home network prefixes assigned for that mobility session 2331 and with the prefix value in the option set to that respective 2332 prefix value. 2334 3. The Handoff Indicator field in the Handoff Indicator option MUST 2335 be set to a value of 5 (Handoff state not changed - Re- 2336 Registration). 2338 6.9.1.4. Mobile Node Detachment and Binding De-Registration 2340 1. If at any point the mobile access gateway detects that the mobile 2341 node has moved away from its access link, or if it decides to 2342 terminate the mobile node's mobility session, it SHOULD send a 2343 Proxy Binding Update message to the local mobility anchor with 2344 the lifetime value set to zero. This de-registration message 2345 MUST be constructed with the same set of options as the initial 2346 binding registration message, under the considerations specified 2347 in Section 6.9.1.1. However, the following exceptions apply. 2349 2. There MUST be a Home Network Prefix option for each of the 2350 assigned home network prefix(es) assigned for that mobility 2351 session and with the prefix value in the option set to the 2352 respective prefix value. 2354 3. The Handoff Indicator field in the Handoff Indicator option MUST 2355 be set to a value of 4 (Handoff state unknown). 2357 Either upon receipt of a Proxy Binding Acknowledgement message from 2358 the local mobility anchor or after INITIAL_BINDACK_TIMEOUT [RFC-3775] 2359 timeout waiting for the reply, the mobile access gateway MUST do the 2360 following: 2362 1. It MUST remove the Binding Update List entry for the mobile node 2363 from its Binding Update List. 2365 2. It MUST remove the created routing state for tunneling the mobile 2366 node's traffic. 2368 3. If there is a dynamically created tunnel to the mobile node's 2369 local mobility anchor and if there are not other mobile nodes for 2370 which the tunnel is being used, then the tunnel MUST be deleted. 2372 4. It MUST tear down the point-to-point link shared with the mobile 2373 node. This action will force the mobile node to remove any IPv6 2374 address configuration on the interface connected to this point- 2375 to-point link. 2377 6.9.1.5. Constructing the Proxy Binding Update Message 2379 o The mobile access gateway when sending the Proxy Binding Update 2380 request to the local mobility anchor MUST construct the message as 2381 specified below. 2383 IPv6 header (src=Proxy-CoA, dst=LMAA) 2384 Mobility header 2385 - BU /* P & A flags MUST be set to value 1 */ 2386 Mobility Options 2387 - Mobile Node Identifier option (mandatory) 2388 - Home Network Prefix option(s) (mandatory) 2389 - Handoff Indicator option (mandatory) 2390 - Access Technology Type option (mandatory) 2391 - Timestamp option (optional) 2392 - Mobile Node Link-layer Identifier option (optional) 2393 - Link-local Address option (optional) 2395 Figure 12: Proxy Binding Update message format 2397 o The Source Address field in the IPv6 header of the message MUST be 2398 set to the global address configured on the egress interface of 2399 the mobile access gateway. When there is no Alternate Care-of 2400 Address option present in the request, this address will be 2401 considered as the Proxy-CoA address for this binding registration 2402 request. However, when there is Alternate Care-of Address option 2403 present in the request, this address will be not be considered as 2404 the Proxy-CoA address, but the address in the alternate Care-of 2405 Address option will be considered as the Proxy-CoA address. 2407 o The Destination Address field in the IPv6 header of the message 2408 MUST be set to the local mobility anchor address. 2410 o The Mobile Node Identifier option [RFC-4283] MUST be present. 2412 o At least one Home Network Prefix option MUST be present. 2414 o The Handoff Indicator option MUST be present. 2416 o The Access Technology Type option MUST be present. 2418 o The Timestamp option MAY be present. 2420 o The Mobile Node Link-layer Identifier option MAY be present. 2422 o The Link-local Address option MAY be present. 2424 o If IPsec is used for protecting the signaling messages, the 2425 message MUST be protected, using the security association existing 2426 between the local mobility anchor and the mobile access gateway. 2428 o Unlike in Mobile IPv6 [RFC-3775], the Home Address option [RFC- 2429 3775] MUST NOT be present in the IPv6 Destination Options 2430 extension header of the Proxy Binding Update message. 2432 6.9.2. Router Solicitation Messages 2434 A mobile node may send a Router Solicitation message on the access 2435 link shared with the mobile access gateway. The Router Solicitation 2436 message that the mobile node sends is as specified in [RFC-4861]. 2437 The mobile access gateway on receiving the Router Solicitation 2438 message or before sending a Router Advertisement message MUST apply 2439 the following considerations. 2441 1. The mobile access gateway on receiving the Router Solicitation 2442 message SHOULD send a Router Advertisement message containing the 2443 mobile node's home network prefix(es) as the on-link prefix(es). 2444 However, before sending the Router Advertisement message 2445 containing the mobile node's home network prefix(es), it SHOULD 2446 complete the binding registration process with the mobile node's 2447 local mobility anchor. 2449 2. If the local mobility anchor rejects the binding registration 2450 request, or, if the mobile access gateway failed to complete the 2451 binding registration process for whatever reason, the mobile 2452 access gateway MUST NOT advertise the mobile node's home network 2453 prefix(es) in the Router Advertisement messages that it sends on 2454 the access link. However, it MAY choose to advertise a local 2455 visited network prefix(es) to enable the mobile node for regular 2456 IPv6 access. 2458 3. The mobile access gateway SHOULD add the MTU option, as specified 2459 in [RFC-4861], to the Router Advertisement messages that it sends 2460 on the access link. This will ensure the mobile node on the link 2461 uses the advertised MTU value. The MTU value SHOULD reflect the 2462 tunnel MTU for the bi-directional tunnel between the mobile 2463 access gateway and the local mobility anchor. Considerations 2464 from Section 6.9.5 SHOULD be applied for determining the tunnel 2465 MTU value. 2467 6.9.3. Default-Router 2469 In Proxy Mobile IPv6, the mobile access gateway is the IPv6 default- 2470 router for the mobile node on the access link, as it is the entity 2471 that sends the Router Advertisements on the access link. However, as 2472 the mobile node moves from one access link to another, the serving 2473 mobile access gateway on those respective links will send the Router 2474 Advertisement messages. If these Router Advertisements are sent 2475 using a different link-local address or a different link-layer 2476 address, the mobile node will always detect a new default-router 2477 after every handoff. For solving this problem, this specification 2478 requires all the mobile access gateways in the Proxy Mobile IPv6 2479 domain to use the same link-local and link-layer address on any of 2480 the access links where ever the mobile node attaches. These 2481 addresses can be fixed addresses across the entire Proxy Mobile IPv6 2482 domain and all the mobile access gateways can use these globally 2483 fixed address on any of the point-to-point links. Additionally, this 2484 specification allows the local mobility anchor to generate the link- 2485 local address and provide it to the mobile access gateway as part of 2486 the signaling messages. 2488 However, both of these approaches (a link-local address generated by 2489 the local mobility anchor or when using a globally fixed link-local 2490 address) have implications on the deployment of SEcure Neighbor 2491 Discovery (SEND) [RFC-3971]. In SEND, routers have certificates and 2492 public key pairs, and their Router Advertisements are signed with the 2493 private keys of these key pairs. When a number of different routers 2494 use the same addresses, the routers either all have to be able to 2495 construct these signatures for the same key pair, or the used key 2496 pair and the router's cryptographic identity must change after a 2497 movement. Both approaches are problematic. Sharing of private key 2498 information across a number of nodes would be inappropriate. And 2499 changing even the cryptographic identity of the router goes against 2500 the general idea of the Proxy Mobile IPv6 being as invisible to the 2501 hosts as possible. 2503 There is, however, ongoing work at the IETF to revise the SEND 2504 specifications. It is suggested that these revisions also address 2505 the above problem. Other revisions are needed to deal with other 2506 problematic cases (such as Neighbor Discovery proxies) before wide- 2507 spread deployment of SEND. 2509 6.9.4. Retransmissions and Rate Limiting 2511 The mobile access gateway is responsible for retransmissions and rate 2512 limiting the binding registration requests that it sends to the local 2513 mobility anchor. The Retransmission and the Rate Limiting rules are 2514 as specified in [RFC-3775]. However, the following considerations 2515 MUST be applied. 2517 1. When the mobile access gateway sends a Proxy Binding Update 2518 request, it should use the constant, INITIAL_BINDACK_TIMEOUT 2519 [RFC-3775], for configuring the retransmission timer, as 2520 specified in Section 11.8 [RFC-3775]. However, the mobile access 2521 gateway is not required to use a longer retransmission interval 2522 of InitialBindackTimeoutFirstReg as specified in [RFC-3775] for 2523 the initial binding registration request. 2525 2. If the mobile access gateway fails to receive a valid matching 2526 response for a registration or re-registration message within the 2527 retransmission interval, it SHOULD retransmit the message until a 2528 response is received. However, the mobile access gateway MUST 2529 ensure the mobile node is still attached to the connected link 2530 before retransmitting the message. 2532 3. As specified in Section 11.8 of [RFC-3775], the mobile access 2533 gateway MUST use an exponential back-off process in which the 2534 timeout period is doubled upon each retransmission, until either 2535 the node receives a response or the timeout period reaches the 2536 value MAX_BINDACK_TIMEOUT [RFC-3775]. The mobile access gateway 2537 MAY continue to send these messages at this slower rate 2538 indefinitely. 2540 4. If the Timestamp based scheme is in use, the retransmitted Proxy 2541 Binding Update messages MUST use the latest timestamp. If the 2542 Sequence number scheme is in use, the retransmitted Proxy Binding 2543 Update messages MUST use a Sequence Number value greater than 2544 that used for the previous transmission of this Proxy Binding 2545 Update message, just as specified in [RFC-3775]. 2547 6.9.5. Path MTU Discovery 2549 For getting optimal throughput, it is required that the routed 2550 packets between the local mobility anchor and the mobile access 2551 gateway are sent in the largest size and without fragmentation. If 2552 the mobility entities are aware of the Path MTU (PMTU) between 2553 themselves, it can be used for determining the Tunnel Path MTU and 2554 also for advertising this value as the link MTU on the access link 2555 shared with the mobile node. The following are some of the 2556 considerations related to Path MTU discovery. 2558 o The local mobility anchor and mobile access gateway MAY use the 2559 Path MTU Discovery mechanisms as specified in [RFC-1981] and [RFC- 2560 4821]. for determining the Path MTU (PMTU) for the path between 2561 themselves. 2563 o The local mobility anchor and the mobile access gateway MAY use 2564 any standard application probes for determining the PMTU. The 2565 specifics details related to the type of traffic that can be used 2566 for the PMTU discovery is outside the scope of this document. 2568 o If there is an administratively configured PMTU value for the path 2569 between the local mobility anchor and the mobile access gateway, 2570 the dynamic discovery of PMTU is not required. 2572 o The IPv6 tunnel MTU for the established tunnel between the local 2573 mobility anchor and the mobile access gateway can be computed 2574 based on this Path MTU value, as specified in Section 6.7 of [RFC- 2575 2473]. 2577 o The mobile access gateway SHOULD use this determined tunnel Path 2578 MTU value (for the tunnel established with the mobile node's local 2579 mobility anchor) as the MTU value in the MTU option that it sends 2580 in the Router Advertisements on the access link shared with the 2581 mobile node. 2583 6.10. Routing Considerations 2585 This section describes how the mobile access gateway handles the 2586 traffic to/from the mobile node that is attached to one of its access 2587 interfaces. 2589 Proxy-CoA LMAA 2590 | | 2591 +--+ +---+ +---+ +--+ 2592 |MN|----------|MAG|======================|LMA|----------|CN| 2593 +--+ +---+ +---+ +--+ 2594 IPv6 Tunnel 2596 Figure 13: Proxy Mobile IPv6 Tunnel 2598 6.10.1. Transport Network 2600 As per this specification, the transport network between the local 2601 mobility anchor and the mobile access gateway is an IPv6 network. 2602 The companion document [ID-IPV4-PMIP6] specifies the required 2603 extensions for negotiating IPv4 transport and the corresponding 2604 encapsulation mode. 2606 6.10.2. Tunneling & Encapsulation Modes 2608 An IPv6 address that a mobile node uses from its home network 2609 prefix(es) is topologically anchored at the local mobility anchor. 2610 For a mobile node to use this address from an access network attached 2611 to a mobile access gateway, proper tunneling techniques have to be in 2612 place. Tunneling hides the network topology and allows the mobile 2613 node's IPv6 datagram to be encapsulated as a payload of another IPv6 2614 packet and to be routed between the local mobility anchor and the 2615 mobile access gateway. The Mobile IPv6 base specification [RFC-3775] 2616 defines the use of IPv6-over-IPv6 tunneling [RFC-2473], between the 2617 home agent and the mobile node and this specification extends the use 2618 of the same tunneling mechanism for use between the local mobility 2619 anchor and the mobile access gateway. 2621 On most operating systems, a tunnel is implemented as a virtual 2622 point-to-point interface. The source and the destination address of 2623 the two end points of this virtual interface along with the 2624 encapsulation mode are specified for this virtual interface. Any 2625 packet that is routed over this interface gets encapsulated with the 2626 outer header as specified for that point to point tunnel interface. 2628 For creating a point to point tunnel to any local mobility anchor, 2629 the mobile access gateway may implement a tunnel interface with the 2630 source address field set to a global address on its egress interface 2631 (Proxy-CoA) and the destination address field set to the global 2632 address of the local mobility anchor (LMAA). 2634 The following is the supported packet encapsulation mode that can be 2635 used by the mobile access gateway and the local mobility anchor for 2636 routing mobile node's IPv6 datagrams. 2638 o IPv6-In-IPv6 - IPv6 datagram encapsulated in an IPv6 packet [RFC- 2639 2473]. 2641 The companion document [ID-IPV4-PMIP6] specifies other encapsulation 2642 modes for supporting IPv4 transport. 2644 o IPv6-In-IPv4 - IPv6 datagram encapsulation in an IPv4 packet. The 2645 details on how this mode is negotiated is specified in [ID-IPV4- 2646 PMIP6]. 2648 o IPv6-In-IPv4-UDP - IPv6 datagram encapsulation in an IPv4 UDP 2649 packet. This mode is specified in [ID-IPV4-PMIP6]. 2651 o IPv6-In-IPv4-UDP-TLV - IPv6 datagram encapsulation in an IPv4 UDP 2652 packet with a TLV header. This mode is specified in [ID-IPV4- 2653 PMIP6]. 2655 6.10.3. Local Routing 2657 If there is data traffic between a visiting mobile node and a 2658 correspondent node that is locally attached to an access link 2659 connected to the mobile access gateway, the mobile access gateway MAY 2660 optimize on the delivery efforts by locally routing the packets and 2661 by not reverse tunneling them to the mobile node's local mobility 2662 anchor. The flag EnableMAGLocalRouting MAY be used for controlling 2663 this behavior. However, in some systems, this may have an 2664 implication on the mobile node's accounting and policy enforcement as 2665 the local mobility anchor is not in the path for that traffic and it 2666 will not be able to apply any traffic policies or do any accounting 2667 for those flows. 2669 This decision of path optimization SHOULD be based on the policy 2670 configured on the mobile access gateway, but enforced by the mobile 2671 node's local mobility anchor. The specific details on how this is 2672 achieved are beyond of the scope of this document. 2674 6.10.4. Tunnel Management 2676 All the considerations mentioned in Section 5.6.1 for the tunnel 2677 management on the local mobility anchor apply for the mobile access 2678 gateway as well. 2680 6.10.5. Forwarding Rules 2682 Forwarding Packets sent to the Mobile Node's Home Network: 2684 o On receiving a packet from the bi-directional tunnel established 2685 with the mobile node's local mobility anchor, the mobile access 2686 gateway MUST use the destination address of the inner packet for 2687 forwarding it on the interface where the destination network 2688 prefix is hosted. The mobile access gateway MUST remove the outer 2689 header before forwarding the packet. Considerations from [RFC- 2690 2473] MUST be applied for IPv6 decapsulation. If the mobile 2691 access gateway cannot find the connected interface for that 2692 destination address, it MUST silently drop the packet. For 2693 reporting an error in such a scenario, in the form of ICMP control 2694 message, the considerations from [RFC-2473] MUST be applied. 2696 o On receiving a packet from a correspondent node that is locally 2697 connected and which is destined to a mobile node that is on 2698 another locally connected access link, the mobile access gateway 2699 MUST check the flag EnableMAGLocalRouting, to ensure the mobile 2700 access gateway is allowed to route the packet directly to the 2701 mobile node. If the mobile access gateway is not allowed to route 2702 the packet directly, it MUST route the packet through the bi- 2703 directional tunnel established between itself and the mobile 2704 node's local mobility anchor. Otherwise, it can route the packet 2705 directly to the mobile node. 2707 Forwarding Packets Sent by the Mobile Node: 2709 o On receiving a packet from a mobile node connected to its access 2710 link, the mobile access gateway MUST ensure that there is an 2711 established binding for that mobile node with its local mobility 2712 anchor before forwarding the packet directly to the destination or 2713 before tunneling the packet to the mobile node's local mobility 2714 anchor. 2716 o On receiving a packet from a mobile node connected to its access 2717 link for a destination that is locally connected, the mobile 2718 access gateway MUST check the flag EnableMAGLocalRouting, to 2719 ensure the mobile access gateway is allowed to route the packet 2720 directly to the destination. If the mobile access gateway is not 2721 allowed to route the packet directly, it MUST route the packet 2722 through the bi-directional tunnel established between itself and 2723 the mobile node's local mobility anchor. Otherwise, it MUST route 2724 the packet directly to the destination. 2726 o On receiving a packet from a mobile node connected to its access 2727 link, to a destination that is not directly connected, the packet 2728 MUST be forwarded to the local mobility anchor through the bi- 2729 directional tunnel established between itself and the mobile 2730 node's local mobility anchor. However, the packets that are sent 2731 with the link-local source address MUST NOT be forwarded. 2733 o The format of the tunneled packet is shown below. Considerations 2734 from [RFC-2473] MUST be applied for IPv6 encapsulation. However, 2735 when using IPv4 transport, the format of the tunneled packet is as 2736 described in [ID-IPV4-PMIP6]. 2738 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2739 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2740 Upper layer protocols /* Packet Content*/ 2742 Figure 14: Tunneled Packet from MAG to LMA 2744 o The format of the tunneled packet is shown below, when payload 2745 protection using IPsec is enabled for the mobile node's data 2746 traffic. However, when using IPv4 transport, the format of the 2747 packet is as described in [ID-IPV4-PMIP6]. 2749 IPv6 header (src= Proxy-CoA, dst= LMAA /* Tunnel Header */ 2750 ESP Header in tunnel mode /* ESP Header */ 2751 IPv6 header (src= MN-HoA, dst= CN ) /* Packet Header */ 2752 Upper layer protocols /* Packet Content*/ 2754 Figure 15: Tunneled Packet from MAG to LMA with Payload Protection 2756 6.11. Supporting DHCPv6 based Address Configuration on the Access Link 2758 This section explains how Stateful Address Configuration using DHCPv6 2759 can be enabled on the point-to-point link between the mobile node and 2760 the mobile access gateway and how a mobile node attached to that link 2761 can obtain an address from its home network prefix and using DHCPv6. 2763 o For supporting Stateful Address Configuration using DHCPv6, the 2764 DHCPv6 relay agent [RFC-3315] service MUST be configured on each 2765 of the mobile access gateways in the Proxy Mobile IPv6 domain. 2766 Further, as specified in Section 20 of [RFC-3315], the DHCPv6 2767 relay agent should be configured to use a list of destination 2768 addresses, which MAY include unicast addresses, the 2769 All_DHCP_Servers multicast address, or other addresses selected by 2770 the network administrator. 2772 o The DHCPv6 server in the Proxy Mobile IPv6 domain MUST be 2773 configured with prefix groups, One Prefix Group: ([P1], [P2], .. , 2774 [Pn]), Two Prefix Group: ([P5,P6], [P7,P8] .. [Pm-1, Pm]. Each 2775 of the entries represent a link on which the prefix(es) are 2776 hosted. The local mobility anchor(s) will assign all the 2777 prefix(es) under a given entry to a mobile node's interface. The 2778 prefixes under a given entry always go as a group and cannot be 2779 mixed in any order and can only be assigned to only one mobile 2780 node's interface. If the Proxy Mobile IPv6 domain support only 2781 single prefix for a given mobile node's interface, then the DHCPv6 2782 server need to maintain just one group of single prefixes. 2784 o The DHCPv6 server will not know the relation between the 2785 prefix(es) listed under an entry and a mobile node to which the 2786 corresponding prefixes are allocated. It just views these 2787 prefixes as hosted prefixes on a given link in that domain. Based 2788 on the prefix value present in the link-address option of the 2789 received DHCPv6 request, the DHCPv6 server assigns addresses from 2790 all of the prefixes associated with that link, 2792 o When a mobile node sends a DHCPv6 request message, the DHCPv6 2793 relay agent function on the mobile access gateway will set the 2794 link-address field in the DHCPv6 message to an address in the 2795 mobile node's home network prefix (any one of the mobile node's 2796 home network prefixes assigned to that mobile node's attached 2797 interface). The address is generated as per [RFC-4862] by 2798 combining that mobile node's home network prefix and its own 2799 interface identifier on the access link shared with the mobile 2800 node, so as to provide a hint to the DHCPv6 Server for the link 2801 identification. The DHCPv6 server on receiving the request from 2802 the mobile node, will allocate address(es) from the prefixes 2803 associated with that link (identified using the link-address field 2804 of the request). 2806 o Once the mobile node obtains address(es) and moves to a different 2807 link and sends a DHCPv6 request (at any time) for extending the 2808 DHCP lease, the DHCPv6 relay agent on the new link will set the 2809 prefix hint in the DHCPv6 message to one of the mobile node's home 2810 network prefix (assigned by the local mobility anchor for this 2811 mobility session). The DHCPv6 server will identify the client 2812 from the Client-DUID option present in the request and will 2813 allocate the same address(es) as before. 2815 o The DHCPv6 based address configuration is not recommended for 2816 deployments where the local mobility anchor and the mobile access 2817 gateways are located in different administrative domains. For 2818 this configuration to work, all the mobile access gateways in the 2819 Proxy Mobile IPv6 domain should be able to ensure that the DHCPv6 2820 request messages from a given mobile node anchored on any of the 2821 access links in that domain, will always be handled by the same 2822 DHCPv6 server or by a server from the same group of coordinated 2823 DHCPv6 servers serving that domain. 2825 o The DHCPv6 server should be configured to offer low address lease 2826 times. A lease time that is too large prevents the DHCPv6 server 2827 from reclaiming the address even after the local mobility anchor 2828 deletes the mobile node's binding cache entry. It is recommended 2829 that the configured lease time be lower than the accepted binding 2830 lifetime for any mobility binding. 2832 6.12. Home Network Prefix Renumbering 2834 If the mobile node's home network prefix(es) gets renumbered or 2835 becomes invalid during the middle of a mobility session, the mobile 2836 access gateway MUST withdraw the prefix(es) by sending a Router 2837 Advertisement message on the access link with zero prefix lifetime 2838 for the prefix(es) that is being renumbered. Also, the local 2839 mobility anchor and the mobile access gateway MUST delete the created 2840 routing state for the renumbered prefix(es). However, the specific 2841 details on how the local mobility anchor notifies the mobile access 2842 gateway about the mobile node's home network prefix(es) renumbering 2843 are outside the scope of this document. 2845 6.13. Mobile Node Detachment Detection and Resource Cleanup 2847 Before sending a Proxy Binding Update message to the local mobility 2848 anchor for extending the lifetime of a currently existing binding of 2849 a mobile node, the mobile access gateway MUST make sure the mobile 2850 node is still attached to the connected link by using some reliable 2851 method. If the mobile access gateway cannot predictably detect the 2852 presence of the mobile node on the connected link, it MUST NOT 2853 attempt to extend the registration lifetime of the mobile node. 2854 Further, in such a scenario, the mobile access gateway SHOULD 2855 terminate the binding of the mobile node by sending a Proxy Binding 2856 Update message to the mobile node's local mobility anchor with 2857 lifetime value set to 0. It MUST also remove any local state such as 2858 the Binding Update List entry created for that mobile node. 2860 The specific detection mechanism of the loss of a visiting mobile 2861 node on the connected link is specific to the access link between the 2862 mobile node and the mobile access gateway and is outside the scope of 2863 this document. Typically, there are various link-layer specific 2864 events specific to each access technology that the mobile access 2865 gateway can depend on for detecting the node loss. In general, the 2866 mobile access gateway can depend on one or more of the following 2867 methods for the detection presence of the mobile node on the 2868 connected link: 2870 o Link-layer event specific to the access technology 2872 o PPP Session termination event on point-to-point link types 2874 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 2876 o Notification event from the local mobility anchor 2878 6.14. Allowing network access to other IPv6 nodes 2880 In some Proxy Mobile IPv6 deployments, network operators may want to 2881 provision the mobile access gateway to offer network-based mobility 2882 management service only to some visiting mobile nodes and enable just 2883 regular IP access to some other nodes. This requires the network to 2884 have control on when to enable network-based mobility management 2885 service to a mobile node and when to enable regular IPv6 access. 2886 This specification does not disallow such configuration. 2888 Upon detecting a mobile node on its access link and after policy 2889 considerations, the mobile access gateway MUST determine if network- 2890 based mobility management service should be offered to that mobile 2891 node. If the mobile node is entitled for network-based mobility 2892 management service, then the mobile access gateway must ensure the 2893 mobile node believes it is on its home link, as explained in various 2894 sections of this specification. 2896 If the mobile node is not entitled for the network-based mobility 2897 management service, as determined from the policy considerations, the 2898 mobile access gateway MAY choose to offer regular IPv6 access to the 2899 mobile node and in such a scenario the normal IPv6 considerations 2900 apply. If IPv6 access is enabled, the mobile node SHOULD be able to 2901 obtain IPv6 address(es) using the normal IPv6 address configuration 2902 procedures. The obtained address(es) must be from a local visitor 2903 network prefix(es). This essentially ensures that the mobile access 2904 gateway functions as a normal access router to a mobile node attached 2905 to its access link and without impacting its host-based mobility 2906 protocol operation. 2908 7. Mobile Node Operation 2910 This non-normative section explains the mobile node's operation in a 2911 Proxy Mobile IPv6 domain. 2913 7.1. Moving into a Proxy Mobile IPv6 Domain 2915 When a mobile node enters a Proxy Mobile IPv6 domain and attaches to 2916 an access network, the mobile access gateway on the access link 2917 detects the attachment of the mobile node and completes the binding 2918 registration with the mobile node's local mobility anchor. If the 2919 binding update operation is successfully performed, the mobile access 2920 gateway will create the required state and set up the data path for 2921 the mobile node's data traffic. 2923 If the mobile node is IPv6 enabled, on attaching to the access link, 2924 it will typically send a Router Solicitation message [RFC-4861]. The 2925 mobile access gateway on the access link will respond to the Router 2926 Solicitation message with a Router Advertisement message. The Router 2927 Advertisement message will carry the mobile node's home network 2928 prefix(es), default-router address and other address configuration 2929 Parameters. 2931 If the mobile access gateway on the access link receives a Router 2932 Solicitation message from the mobile node, before it completes the 2933 signaling with the mobile node's local mobility anchor, the mobile 2934 access gateway may not know the mobile node's home network prefix(es) 2935 and may not be able to emulate the mobile node's home link on the 2936 access link. In such a scenario, the mobile node may notice a slight 2937 delay before it receives a Router Advertisement message. 2939 If the received Router Advertisement message has the Managed Address 2940 Configuration flag set, the mobile node, as it would normally do, 2941 will send a DHCPv6 Request [RFC-3315]. The DHCP relay service 2942 enabled on that access link will ensure the mobile node can obtain 2943 one or more addresses and from its home network prefix(es). 2945 If the received Router Advertisement message does not have the 2946 Managed Address Configuration flag set and if the mobile node is 2947 allowed to use autoconfigured address(es), the mobile node will be 2948 able to obtain IPv6 address(es) and from each of its home network 2949 prefixes using any of the standard IPv6 address configuration 2950 mechanisms permitted for that mode. 2952 If the mobile node is IPv4 enabled and if the network permits, it 2953 will be able to obtain the IPv4 address configuration as specified in 2954 the companion document [ID-IPV4-PMIP6]. 2956 Once the address configuration is complete, the mobile node can 2957 continue to use this address configuration as long as it is attached 2958 to the network that is in the scope of that Proxy Mobile IPv6 domain. 2960 7.2. Roaming in the Proxy Mobile IPv6 Domain 2962 After obtaining the address configuration in the Proxy Mobile IPv6 2963 domain, as the mobile node moves and changes its point of attachment 2964 from one mobile access gateway to the other, it can still continue to 2965 use the same address configuration. As long as the attached access 2966 link is in the scope of that Proxy Mobile IPv6 domain, the mobile 2967 node will always detect the same default-router advertising the 2968 mobile node's home network prefix(es) on each connected link. If the 2969 mobile node has address configuration that it obtained using DHCPv6, 2970 it will be able to retain the address configuration and extend the 2971 lease lifetime. 2973 8. Message Formats 2975 This section defines extensions to the Mobile IPv6 [RFC-3775] 2976 protocol messages. 2978 8.1. Proxy Binding Update Message 2980 0 1 2 3 2981 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 2982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2983 | Sequence # | 2984 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2985 |A|H|L|K|M|R|P| Reserved | Lifetime | 2986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2987 | | 2988 . . 2989 . Mobility options . 2990 . . 2992 | | 2993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2995 A Binding Update message that is sent by a mobile access gateway to a 2996 local mobility anchor is referred to as the "Proxy Binding Update" 2997 message. A new flag (P) is included in the Binding Update message. 2998 The rest of the Binding Update message format remains the same as 2999 defined in [RFC-3775] and with the additional (R) and (M) flags as 3000 specified in [RFC-3963] and [RFC-4140] respectively. 3002 Proxy Registration Flag (P) 3004 A new flag (P) is included in the Binding Update message to 3005 indicate to the local mobility anchor that the Binding Update 3006 message is a proxy registration. The flag MUST be set to the 3007 value of 1 for proxy registrations and MUST be set to 0 for direct 3008 registrations sent by a mobile node. 3010 Mobility Options 3012 Variable-length field of such length that the complete Mobility 3013 Header is an integer multiple of 8 octets long. This field 3014 contains zero or more TLV-encoded mobility options. The encoding 3015 and format of defined options are described in Section 6.2 of 3016 [RFC-3775]. The local mobility anchor MUST ignore and skip any 3017 options which it does not understand. 3019 As per this specification, the following mobility options are 3020 valid in a Proxy Binding Update message. These options can be 3021 present in the message in any order. There can be one or more 3022 instances of the Home Network Prefix options present in the 3023 message. However, there cannot be more than one instance of any 3024 of the other options. 3026 Mobile Node Identifier option 3028 Home Network Prefix option 3030 Handoff Indicator option 3032 Access Technology Type option 3034 Timestamp option 3036 Mobile Node Link-layer Identifier option 3038 Link-local Address option 3040 Additionally, there can one or more instances of the Vendor- 3041 Specific Mobility option [RFC-5094]. 3043 For descriptions of other fields present in this message, refer to 3044 section 6.1.7 of [RFC-3775]. 3046 8.2. Proxy Binding Acknowledgement Message 3048 0 1 2 3 3049 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 3050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3051 | Status |K|R|P|Reserved | 3052 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3053 | Sequence # | Lifetime | 3054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3055 | | 3056 . . 3057 . Mobility options . 3058 . . 3059 | | 3060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3062 A Binding Acknowledgement message that is sent by a local mobility 3063 anchor to a mobile access gateway is referred to as the "Proxy 3064 Binding Acknowledgement" message. A new flag (P) is included in the 3065 Binding Acknowledgement message. The rest of the Binding 3066 Acknowledgement message format remains the same as defined in [RFC- 3067 3775] and with the additional (R) flag as specified in [RFC-3963]. 3069 Proxy Registration Flag (P) 3071 A new flag (P) is included in the Binding Acknowledgement message 3072 to indicate that the local mobility anchor that processed the 3073 corresponding Proxy Binding Update message supports proxy 3074 registrations. The flag is set to value of 1 only if the 3075 corresponding Proxy Binding Update had the Proxy Registration Flag 3076 (P) set to value of 1. 3078 Mobility Options 3080 Variable-length field of such length that the complete Mobility 3081 Header is an integer multiple of 8 octets long. This field 3082 contains zero or more TLV-encoded mobility options. The encoding 3083 and format of defined options are described in Section 6.2 of 3084 [RFC-3775]. The mobile access gateway MUST ignore and skip any 3085 options which it does not understand. 3087 As per this specification, the following mobility options are 3088 valid in a Proxy Binding Acknowledgement message. These options 3089 can be present in the message in any order. There can be one or 3090 more instances of the Home Network Prefix options present in the 3091 message. However, there cannot be more than one instance of any 3092 of the other options. 3094 Mobile Node Identifier option 3096 Home Network Prefix option 3098 Handoff Indicator option 3100 Access Technology Type option 3102 Timestamp option 3104 Mobile Node Link-layer Identifier option 3106 Link-local Address option 3108 Additionally, there can one or more instances of the Vendor- 3109 Specific Mobility option [RFC-5094]. 3111 Status 3113 8-bit unsigned integer indicating the disposition of the Proxy 3114 Binding Update. Values of the Status field less than 128 indicate 3115 that the Proxy Binding Update was accepted by the local mobility 3116 anchor. Values greater than or equal to 128 indicate that the 3117 binding registration was rejected by the local mobility anchor. 3118 Section 8.9 defines the Status values that can used in Proxy 3119 Binding Acknowledgement message. 3121 For descriptions of other fields present in this message, refer to 3122 the section 6.1.8 of [RFC-3775]. 3124 8.3. Home Network Prefix Option 3126 A new option, Home Network Prefix Option is defined for using it in 3127 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3128 exchanged between a local mobility anchor and a mobile access 3129 gateway. This option is used for exchanging the mobile node's home 3130 network prefix information. There can be multiple Home Network 3131 Prefix options present in the message. 3133 The Home Network Prefix Option has an alignment requirement of 8n+4. 3134 Its format is as follows: 3136 0 1 2 3 3137 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 3138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3139 | Type | Length | Reserved | Prefix Length | 3140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3141 | | 3142 + + 3143 | | 3144 + Home Network Prefix + 3145 | | 3146 + + 3147 | | 3148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3150 Type 3151 3153 Length 3155 8-bit unsigned integer indicating the length of the option 3156 in octets, excluding the type and length fields. This field 3157 MUST be set to 18. 3159 Reserved (R) 3161 This 8-bit field is unused for now. The value MUST be 3162 initialized to 0 by the sender and MUST be ignored by the 3163 receiver. 3165 Prefix Length 3167 8-bit unsigned integer indicating the prefix length of the 3168 IPv6 prefix contained in the option. 3170 Home Network Prefix 3172 A sixteen-byte field containing the mobile node's IPv6 Home 3173 Network Prefix. 3175 8.4. Handoff Indicator Option 3177 A new option, Handoff Indicator Option is defined for using it in the 3178 Proxy Binding Update and Proxy Binding Acknowledgement messages 3179 exchanged between a local mobility anchor and a mobile access 3180 gateway. This option is used for exchanging the mobile node's 3181 handoff related hints. 3183 The Handoff Indicator Option has no alignment requirement. Its 3184 format is as follows: 3186 0 1 2 3 3187 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 3188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3189 | Type | Length | Reserved (R) | HI | 3190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3192 Type 3193 3195 Length 3197 8-bit unsigned integer indicating the length of the option 3198 in octets, excluding the type and length fields. This field 3199 MUST be set to 2. 3201 Reserved (R) 3203 This 8-bit field is unused for now. The value MUST be 3204 initialized to 0 by the sender and MUST be ignored by the 3205 receiver. 3207 Handoff Indicator (HI) 3209 A 8-bit field that specifies the type of handoff. The values 3210 (0 - 255) will be allocated and managed by IANA. The following 3211 values are currently defined. 3213 0: Reserved 3214 1: Attachment over a new interface 3215 2: Handoff between two different interfaces of the mobile node 3216 3: Handoff between mobile access gateways for the same interface 3217 4: Handoff state unknown 3218 5: Handoff state not changed (Re-registration) 3220 8.5. Access Technology Type Option 3222 A new option, Access Technology Type Option is defined for using it 3223 in the Proxy Binding Update and Proxy Binding Acknowledgement 3224 messages exchanged between a local mobility anchor and a mobile 3225 access gateway. This option is used for exchanging the type of the 3226 access technology using which the mobile node is currently attached 3227 to the mobile access gateway. 3229 The Access Technology Type Option has no alignment requirement. Its 3230 format is as follows: 3232 0 1 2 3 3233 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 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3235 | Type | Length | Reserved (R) | ATT | 3236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3238 Type 3239 3241 Length 3243 8-bit unsigned integer indicating the length of the option 3244 in octets, excluding the type and length fields. This field 3245 MUST be set to 2. 3247 Reserved (R) 3249 This 8-bit field is unused for now. The value MUST be 3250 initialized to 0 by the sender and MUST be ignored by the 3251 receiver. 3253 Access Technology Type (ATT) 3255 A 8-bit field that specifies the access technology through 3256 which the mobile node is connected to the access link on the 3257 mobile access gateway. 3259 The values (0 - 255) will be allocated and managed by IANA. The 3260 following values are currently reserved for the below specified 3261 access technology types. 3263 0: Reserved ("Reserved") 3264 1: Virtual ("Logical Network Interface") 3265 2: PPP ("Point-to-Point Protocol") 3266 3: IEEE 802.3 ("Ethernet") 3267 4: IEEE 802.11a/b/g ("Wireless LAN") 3268 5: IEEE 802.16e ("WIMAX") 3270 8.6. Mobile Node Link-layer Identifier Option 3272 A new option, Mobile Node Link-layer Identifier Option is defined for 3273 using it in the Proxy Binding Update and Proxy Binding 3274 Acknowledgement messages exchanged between a local mobility anchor 3275 and a mobile access gateway. This option is used for exchanging the 3276 mobile node's link-layer identifier. 3278 The format of the Link-layer Identifier option is shown below. Based 3279 on the size of the identifier, the option MUST be aligned 3280 appropriately, as per mobility option alignment requirements 3281 specified in [RFC-3775]. 3283 0 1 2 3 3284 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 3285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3286 | Type | Length | Reserved | 3287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 | | 3289 + Link-layer Identifier + 3290 . ... . 3291 | | 3292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3294 Type 3295 3297 Length 3298 8-bit unsigned integer indicating the length of the option 3299 in octets, excluding the type and length fields. 3301 Reserved 3303 This field is unused for now. The value MUST be initialized to 3304 0 by the sender and MUST be ignored by the receiver. 3306 Link-layer Identifier 3308 A variable length field containing the mobile node's link-layer 3309 identifier. 3311 The content and format of this field (including byte and bit 3312 ordering) is as specified in Section 4.6 of [RFC-4861] for 3313 carrying Link-Layer Address. On certain access links, where 3314 the link-layer address is not used or cannot be determined, 3315 this option cannot be used. 3317 8.7. Link-local Address Option 3319 A new option, Link-local Address Option is defined for using it in 3320 the Proxy Binding Update and Proxy Binding Acknowledgement messages 3321 exchanged between a local mobility anchor and a mobile access 3322 gateway. This option is used for exchanging the link-local address 3323 of the mobile access gateway. 3325 The Link-local Address option has an alignment requirement of 8n+6. 3326 Its format is as follows: 3328 0 1 2 3 3329 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 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Type | Length | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | | 3334 + + 3335 | | 3336 + Link-local Address + 3337 | | 3338 + + 3339 | | 3340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3342 Type 3343 3345 Length 3347 8-bit unsigned integer indicating the length of the option 3348 in octets, excluding the type and length fields. This field 3349 MUST be set to 16. 3351 Link-local Address 3353 A sixteen-byte field containing the mobile node's link-local 3354 address. 3356 8.8. Timestamp Option 3358 A new option, Timestamp Option is defined for use in the Proxy 3359 Binding Update and Proxy Binding Acknowledgement messages. 3361 The Timestamp option has an alignment requirement of 8n+2. Its 3362 format is as follows: 3364 0 1 2 3 3365 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 3366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3367 | Type | Length | 3368 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 | | 3370 + Timestamp + 3371 | | 3372 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3374 Type 3375 3377 Length 3379 8-bit unsigned integer indicating the length in octets of 3380 the option, excluding the type and length fields. The value 3381 for this field MUST be set to 8. 3383 Timestamp 3385 A 64-bit unsigned integer field containing a timestamp. The value 3386 indicates the number of seconds since January 1, 1970, 00:00 UTC, 3387 by using a fixed point format. In this format, the integer number 3388 of seconds is contained in the first 48 bits of the field, and the 3389 remaining 16 bits indicate the number of 1/65536 fractions of a 3390 second. 3392 8.9. Status Values 3394 This document defines the following new Status values for use in 3395 Proxy Binding Acknowledgement message. These values are to be 3396 allocated from the same number space, as defined in Section 6.1.8 of 3397 [RFC-3775]. 3399 Status values less than 128 indicate that the Proxy Binding Update 3400 request was accepted by the local mobility anchor. Status values 3401 greater than 128 indicate that the Proxy Binding Update was rejected 3402 by the local mobility anchor. 3404 PROXY_REG_NOT_ENABLED: IANA 3406 Proxy registration not enabled for the mobile node 3408 NOT_LMA_FOR_THIS_MOBILE_NODE: IANA 3410 Not local mobility anchor for this mobile node 3412 MAG_NOT_AUTHORIZED_FOR_PROXY_REG: IANA 3414 The mobile access gateway is not authorized to send proxy binding 3415 registrations 3417 NOT_AUTHORIZED_FOR_HOME_NETWORK_PREFIX: IANA 3419 The mobile node is not authorized for one or more of the 3420 requesting home network prefixes. 3422 TIMESTAMP_MISMATCH: IANA 3424 Invalid timestamp value (the clocks are out of sync) 3426 TIMESTAMP_LOWER_THAN_PREV_ACCEPTED: IANA 3428 The timestamp value is lower than the previously accepted value 3430 MISSING_HOME_NETWORK_PREFIX_OPTION: IANA 3432 Missing home network prefix option 3434 BCE_PBU_PREFIX_SET_DO_NOT_MATCH: IANA 3436 All the home network prefixes listed in the BCE do not match all 3437 the prefixes in the received PBU 3439 MISSING_MN_IDENTIFIER_OPTION: IANA 3441 Missing mobile node identifier option 3443 MISSING_HANDOFF_INDICATOR_OPTION: IANA 3445 Missing handoff indicator option 3447 MISSING_ACCESS_TECH_TYPE_OPTION: IANA 3449 Missing access technology type option 3451 Additionally, the following Status values defined in [RFC-3775] can 3452 also be used in Proxy Binding Acknowledgement message. 3454 0 Proxy Binding Update accepted 3456 128 Reason unspecified 3458 129 Administratively prohibited 3460 130 Insufficient resources 3462 9. Protocol Configuration Variables 3464 9.1. Local Mobility Anchor - Configuration Variables 3466 The local mobility anchor MUST allow the following variables to be 3467 configured by the system management. The configured values for these 3468 protocol variables MUST survive server reboots and service restarts. 3470 MinDelayBeforeBCEDelete 3472 This variable specifies the amount of time in milliseconds the 3473 local mobility anchor MUST wait before it deletes a Binding Cache 3474 entry of a mobile node, upon receiving a Proxy Binding Update 3475 message from a mobile access gateway with a lifetime value of 0. 3476 During this wait time, if the local mobility anchor receives a 3477 Proxy Binding Update for the same mobility binding, with lifetime 3478 value greater than 0, then it must update the binding cache entry 3479 with the accepted binding values. By the end of this wait-time, 3480 if the local mobility anchor did not receive any valid Proxy 3481 Binding Update message for that mobility binding, it MUST delete 3482 the Binding Cache entry. This delay essentially ensures a mobile 3483 node's Binding Cache entry is not deleted too quickly and allows 3484 some time for the new mobile access gateway to complete the 3485 signaling for the mobile node. 3487 The default value for this variable is 10000 milliseconds. 3489 MaxDelayBeforeNewBCEAssign 3491 This variable specifies the amount of time in milliseconds the 3492 local mobility anchor MUST wait for the de-registration message 3493 for an existing mobility session before it decides to create a new 3494 mobility session. 3496 The default value for this variable is 500 milliseconds. 3498 TimestampValidityWindow 3500 This variable specifies the maximum amount of time difference in 3501 milliseconds between the timestamp in the received Proxy Binding 3502 Update message and the current time-of-day on the local mobility 3503 anchor, that is allowed by the local mobility anchor for the 3504 received message to be considered valid. 3506 The default value for this variable is 300 milliseconds. This 3507 variable must be adjusted to suit the deployments. 3509 9.2. Mobile Access Gateway - Configuration Variables 3511 The mobile access gateway MUST allow the following variables to be 3512 configured by the system management. The configured values for these 3513 protocol variables MUST survive server reboots and service restarts. 3515 EnableMAGLocalRouting 3517 This flag indicates whether or not the mobile access gateway is 3518 allowed to enable local routing of the traffic exchanged between a 3519 visiting mobile node and a correspondent node that is locally 3520 connected to one of the interfaces of the mobile access gateway. 3521 The correspondent node can be another visiting mobile node as 3522 well, or a local fixed node. 3524 The default value for this flag is set to value of 0, indicating 3525 that the mobile access gateway MUST reverse tunnel all the traffic 3526 to the mobile node's local mobility anchor. 3528 When the value of this flag is set to value of 1, the mobile 3529 access gateway MUST route the traffic locally. 3531 This aspect of local routing MAY be defined as policy on a per 3532 mobile basis and when present will take precedence over this flag. 3534 9.3. Proxy Mobile IPv6 Domain - Configuration Variables 3536 All the mobile entities (local mobility anchors and mobile access 3537 gateways in a Proxy Mobile IPv6 domain MUST allow the following 3538 variables to be configured by the system management. The configured 3539 values for these protocol variables MUST survive server reboots and 3540 service restarts. These variables MUST be globally fixed for a given 3541 Proxy Mobile IPv6 domain resulting in the same values being enforced 3542 on all the mobility entities in that domain. 3544 MobileNodeGeneratedTimestampInUse 3546 This flag indicates whether or not the mobile node generated 3547 timestamp mechanism is in use in that Proxy Mobile IPv6 domain. 3548 When the value for this flag is set to 1, the local mobility 3549 anchors and mobile access gateways in that Proxy Mobile IPv6 3550 domain MUST apply the mobile node generated timestamp 3551 considerations. 3553 The default value for this flag is set to value of 0, indicating 3554 that the mobile node generated timestamp mechanism is not in use 3555 in that Proxy Mobile IPv6 domain. 3557 10. IANA Considerations 3559 This document defines six new Mobility Header options, the Home 3560 Network Prefix option, Handoff Indicator option, Access Technology 3561 Type option, Mobile Node Link-layer Identifier option, Link-local 3562 Address option and Timestamp option. These options are described in 3563 Section 8. The Type value for these options needs to be assigned 3564 from the same numbering space as allocated for the other mobility 3565 options, as defined in [RFC-3775]. 3567 The Handoff Indicator option defined in Section 8.4 of this document 3568 introduces a new Handoff Indicator (HI) numbering space, where the 3569 values from 0 to 5 have been reserved by this document. Approval of 3570 new Handoff Indicator type values are to be made through IANA Expert 3571 Review. 3573 The Access Technology Type option defined in Section 8.5 of this 3574 document introduces a new Access Technology type (ATT) numbering 3575 space, where the values from 0 to 5 have been reserved by this 3576 document. Approval of new Access Technology type values are to be 3577 made through IANA Expert Review. 3579 This document also defines new Binding Acknowledgement status values 3580 as described in Section 8.9. The status values MUST be assigned from 3581 the same number space used for Binding Acknowledgement status values, 3582 as defined in [RFC-3775]. The allocated values for each of these 3583 status values must be greater than 128. 3585 11. Security Considerations 3587 The potential security threats against any network-based mobility 3588 management protocol are described in [RFC-4832]. This section 3589 explains how Proxy Mobile IPv6 protocol defends itself against those 3590 threats. 3592 Proxy Mobile IPv6 protocol requires the signaling messages, Proxy 3593 Binding Update and Proxy Binding Acknowledgement, exchanged between 3594 the mobile access gateway and the local mobility anchor to be 3595 protected using IPsec, using the established security association 3596 between them. This essentially eliminates the threats related to the 3597 impersonation of the mobile access gateway or the local mobility 3598 anchor. 3600 This specification allows a mobile access gateway to send binding 3601 registration messages on behalf of a mobile node. If proper 3602 authorization checks are not in place, a malicious node may be able 3603 to hijack a mobile node's session or may carry out a denial-of- 3604 service attack. To prevent this attack, this specification requires 3605 the local mobility anchor to allow only authorized mobile access 3606 gateways that are part of that Proxy Mobile IPv6 domain to send 3607 binding registration messages on behalf of a mobile node. 3609 To eliminate the threats on the interface between the mobile access 3610 gateway and the mobile node, this specification requires an 3611 established trust between the mobile access gateway and the mobile 3612 node and to authenticate and authorize the mobile node before it is 3613 allowed to access the network. Further, the established 3614 authentication mechanisms enabled on that access link will ensure 3615 that there is a secure binding between the mobile node's identity and 3616 its link-layer address. The mobile access gateway will definitively 3617 identify the mobile node from the packets that it receives on that 3618 access link. 3620 To address the threat related to a compromised mobile access gateway, 3621 the local mobility anchor, before accepting a Proxy Binding Update 3622 message for a given mobile node, may ensure that the mobile node is 3623 definitively attached to the mobile access gateway that sent the 3624 proxy binding registration request. This may be accomplished by 3625 contacting a trusted entity which is able to track the mobile node's 3626 current point of attachment. However, the specific details of the 3627 actual mechanisms for achieving this is outside the scope of this 3628 document. 3630 12. Acknowledgements 3632 The authors would like to specially thank Jari Arkko, Julien 3633 Laganier, Christian Vogt, Dave Thaler, Pasi Eronen, Pete McCann, 3634 Brian Haley, Ahmad Muhanna, JinHyeock Choi and Elwyn Davies for their 3635 thorough review of this document. 3637 The authors would also like to thank Alex Petrescu, Alice Qinxia, 3638 Alper Yegin, Ashutosh Dutta, Behcet Sarikaya, Fred Templin, Genadi 3639 Velev, George Tsirtsis, Gerardo Giaretta, Henrik Levkowetz, Hesham 3640 Soliman, James Kempf, Jean-Michel Combes, Jun Awano, John Zhao, Jong- 3641 Hyouk Lee, Jonne Soininen, Jouni Korhonen, Kalin Getov, Kilian 3642 Weniger, Lars Eggert, Magnus Westerlund, Marco Liebsch, Mohamed 3643 Khalil, Nishida Katsutoshi, Phil Roberts, Ryuji Wakikawa, Sangjin 3644 Jeong, Suresh Krishnan, Uri Blumenthal, Ved Kafle, Vidya Narayanan, 3645 Youn-Hee Han and many others for their passionate discussions in the 3646 working group mailing list on the topic of localized mobility 3647 management solutions. These discussions stimulated much of the 3648 thinking and shaped the draft to the current form and we acknowledge 3649 that ! 3651 The authors would also like to thank Ole Troan, Akiko Hattori, Parviz 3652 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 3653 Tim Stammers for their input on this document. 3655 13. References 3657 13.1. Normative References 3659 [RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate 3660 Requirement Levels", BCP 14, RFC 2119, March 1997. 3662 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 3663 IPv6 Specification", RFC 2473, December 1998. 3665 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 3666 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 3667 RFC 3315, July 2003. 3669 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 3670 IPv6", RFC 3775, June 2004. 3672 [RFC-3963] Devarapalli, V., Wakikawa, R., Petrescu, A., and P. 3673 Thubert, "Network Mobility (NEMO) Basic Support Protocol", RFC 3963, 3674 January 2005. 3676 [RFC-4140] Soliman, H., Castelluccia, C., El Malki, K., and L. 3677 Bellier, "Hierarchical Mobile IPv6 Mobility Management (HMIPv6)", RFC 3678 4140, August 2005. 3680 [RFC-4282] Aboba, B., Beadles, M., Arkko, J., and P. Eronen, "The 3681 Network Access Identifier", RFC 4282, December 2005. 3683 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 3684 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 3685 November 2005. 3687 [RFC-4291] Hinden, R., Deering, S., "IP Version 6 Addressing 3688 Architecture", RFC 4291, February 2006. 3690 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 3691 Internet Protocol", RFC 4301, December 2005. 3693 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 3694 4303, December 2005. 3696 [RFC-4861] Narten, T., Nordmark, E. and W. Simpson, Soliman, H., 3697 "Neighbor Discovery for IP Version 6 (IPv6)", RFC 4861, September 3698 2007. 3700 13.2. Informative References 3702 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 3703 51, RFC 1661, July 1994. 3705 [RFC-1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery 3706 for IP version 6", RFC 1981, August 1996. 3708 [RFC-2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 3709 "Remote Authentication Dial In User Service (RADIUS)", RFC 2865, June 3710 2000. 3712 [RFC-3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J. 3713 Arkko, "Diameter Base Protocol", RFC 3588, September 2003. 3715 [RFC-3971] Arkko, J., Ed., Kempf, J., Sommerfeld, B., Zill, B., and 3716 P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 3717 2005. 3719 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 3720 Protocol", RFC 4306, December 2005. 3722 [RFC-4330] Mills, D., "Simple Network Time Protocol (SNTP) Version 4 3723 for IPv4, IPv6 and OSI", RFC 4330, October 1996. 3725 [RFC-4372] Adrangi, F., Lior, A., Korhonen, J., and J. Loughney, 3726 "Chargeable User Identity", RFC 4372, January 2006. 3728 [RFC-4821] Mathis, M. and Heffner, J., "Packetization Layer Path MTU 3729 Discovery", RFC 4821, March 2007. 3731 [RFC-4830] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3732 G., Liebsch, M., "Problem Statement for Network-based Localized 3733 Mobility Management", September 2006. 3735 [RFC-4831] Kempf, J., Leung, K., Roberts, P., Nishida, K., Giaretta, 3736 G., Liebsch, M., "Goals for Network-based Localized Mobility 3737 Management", October 2006. 3739 [RFC-4832] Vogt, C., Kempf, J., "Security Threats to Network-Based 3740 Localized Mobility Management", September 2006. 3742 [RFC-4862] Thompson, S., Narten, T., Jinmei, T., "IPv6 Stateless 3743 Address Autoconfiguration", RFC 4862, September 2007. 3745 [RFC-4941] Narten, T., Draves, R., Krishnan, S., "Privacy Extensions 3746 for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 3747 2007. 3749 [RFC-5094] Devarapalli, V., Leung, K. and Patel, A., "Mobile IPv6 3750 Vendor Specific Option", RFC 5094, December 2007. 3752 [ID-IPV4-PMIP6] Wakikawa, R. and Gundavelli, S., "IPv4 Support for 3753 Proxy Mobile IPv6", draft-ietf-netlmm-pmip6-ipv4-support-02.txt, 3754 November 2007. 3756 [ID-DNAV6] Narayanan, S., et al "Detecting Network Attachment in IPv6 3757 Networks (DNAv6)", draft-ietf-dna-protocol-07.txt, February 2008. 3759 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 3761 Every mobile node that roams in a proxy Mobile IPv6 domain, would 3762 typically be identified by an identifier, MN-Identifier, and that 3763 identifier will have an associated policy profile that identifies the 3764 mobile node's home network prefix(es) on a per-interface basis, 3765 permitted address configuration modes, roaming policy and other 3766 parameters that are essential for providing network-based mobility 3767 management service. This information is typically configured in AAA. 3768 In some cases, the home network prefix(es) may be dynamically 3769 assigned to the mobile node's interface, after its initial attachment 3770 to the Proxy Mobile IPv6 domain over that interface and may not be 3771 configured in the mobile node's policy profile. 3773 The network entities in the proxy Mobile IPv6 domain, while serving a 3774 mobile node will have access to the mobile node's policy profile and 3775 these entities can query this information using RADIUS [RFC-2865] or 3776 DIAMETER [RFC-3588] protocols. 3778 Appendix B. Routing State 3780 The following section explains the routing state created for a mobile 3781 node on the mobile access gateway. This routing state reflects only 3782 one specific way of implementation and one MAY choose to implement it 3783 in other ways. The policy based route defined below acts as a 3784 traffic selection rule for routing a mobile node's traffic through a 3785 specific tunnel created between the mobile access gateway and that 3786 mobile node's local mobility anchor and with the specific 3787 encapsulation mode, as negotiated. 3789 The below example identifies the routing state for two visiting 3790 mobile nodes, MN1 and MN2 with their respective local mobility 3791 anchors LMA1 and LMA2. 3793 For all traffic from the mobile node, identified by the mobile node's 3794 MAC address, ingress interface or source prefix (MN-HNP) to 3795 _ANY_DESTINATION_ route via interface tunnel0, next-hop LMAA. 3797 +==================================================================+ 3798 | Packet Source | Destination Address | Destination Interface | 3799 +==================================================================+ 3800 | MAC_Address_MN1, | _ANY_DESTINATION_ | Tunnel0 | 3801 | (IPv6 Prefix or |----------------------------------------------| 3802 | Input Interface) | Locally Connected | Tunnel0 | 3803 +------------------------------------------------------------------+ 3804 | MAC_Address_MN2, | _ANY_DESTINATION_ | Tunnel1 | 3805 + (IPv6 Prefix or -----------------------------------------------| 3806 | Input Interface | Locally Connected | direct | 3807 +------------------------------------------------------------------+ 3809 Figure 24: Example - Policy based Route Table 3811 +==================================================================+ 3812 | Interface | Source Address | Destination Address | Encapsulation | 3813 +==================================================================+ 3814 | Tunnel0 | Proxy-CoA | LMAA1 | IPv6-in-IPv6 | 3815 +------------------------------------------------------------------+ 3816 | Tunnel1 | Proxy-CoA | LMAA2 | IPv6-in-IPv6 | 3817 +------------------------------------------------------------------+ 3819 Figure 25: Example - Tunnel Interface Table 3821 Authors' Addresses 3823 Sri Gundavelli 3824 Cisco 3825 170 West Tasman Drive 3826 San Jose, CA 95134 3827 USA 3829 Email: sgundave@cisco.com 3831 Kent Leung 3832 Cisco 3833 170 West Tasman Drive 3834 San Jose, CA 95134 3835 USA 3837 Email: kleung@cisco.com 3838 Vijay Devarapalli 3839 Wichorus 3840 3590 North First Street 3841 San Jose, CA 95134 3842 USA 3844 Email: vijay@wichorus.com 3846 Kuntal Chowdhury 3847 Starent Networks 3848 30 International Place 3849 Tewksbury, MA 3851 Email: kchowdhury@starentnetworks.com 3853 Basavaraj Patil 3854 Nokia Siemens Networks 3855 6000 Connection Drive 3856 Irving, TX 75039 3857 USA 3859 Email: basavaraj.patil@nsn.com 3861 Full Copyright Statement 3863 Copyright (C) The IETF Trust (2008). 3865 This document is subject to the rights, licenses and restrictions 3866 contained in BCP 78, and except as set forth therein, the authors 3867 retain all their rights. 3869 This document and the information contained herein are provided on an 3870 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3871 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 3872 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 3873 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 3874 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3875 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3877 Intellectual Property 3879 The IETF takes no position regarding the validity or scope of any 3880 Intellectual Property Rights or other rights that might be claimed to 3881 pertain to the implementation or use of the technology described in 3882 this document or the extent to which any license under such rights 3883 might or might not be available; nor does it represent that it has 3884 made any independent effort to identify any such rights. Information 3885 on the procedures with respect to rights in RFC documents can be 3886 found in BCP 78 and BCP 79. 3888 Copies of IPR disclosures made to the IETF Secretariat and any 3889 assurances of licenses to be made available, or the result of an 3890 attempt made to obtain a general license or permission for the use of 3891 such proprietary rights by implementers or users of this 3892 specification can be obtained from the IETF on-line IPR repository at 3893 http://www.ietf.org/ipr. 3895 The IETF invites any interested party to bring to its attention any 3896 copyrights, patents or patent applications, or other proprietary 3897 rights that may cover technology that may be required to implement 3898 this standard. Please address the information to the IETF at 3899 ietf-ipr@ietf.org. 3901 Acknowledgment 3903 Funding for the RFC Editor function is provided by the IETF 3904 Administrative Support Activity (IASA).