idnits 2.17.1 draft-ietf-netlmm-proxymip6-00.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 1977. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1988. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1995. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2001. 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 : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC3775]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 480: '... mobility anchor MUST allow only autho...' RFC 2119 keyword, line 568: '... by relaxing the MUST requirement for ...' RFC 2119 keyword, line 727: '...more ways. This MAY be a configured e...' RFC 2119 keyword, line 728: '...y profile, or it MAY be obtained throu...' RFC 2119 keyword, line 745: '... mobility anchor MUST be able to recei...' (57 more instances...) 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 (April 08, 2007) is 6199 days in the past. Is this intentional? 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: 'RFC3775' is mentioned on line 1555, but not defined ** Obsolete undefined reference: RFC 3775 (Obsoleted by RFC 6275) == Missing Reference: 'MN1' is mentioned on line 369, but not defined == Missing Reference: 'MN2' is mentioned on line 369, but not defined == Missing Reference: 'MN5' is mentioned on line 373, but not defined == Missing Reference: 'MN3' is mentioned on line 375, but not defined == Missing Reference: 'MN4' is mentioned on line 375, but not defined == Missing Reference: 'RFC-4285' is mentioned on line 609, but not defined == Missing Reference: 'RFC-3042' is mentioned on line 971, but not defined == Unused Reference: 'RFC-2473' is defined on line 1800, but no explicit reference was found in the text == Unused Reference: 'RFC-4303' is defined on line 1821, but no explicit reference was found in the text == Unused Reference: 'RFC-1332' is defined on line 1845, but no explicit reference was found in the text == Unused Reference: 'RFC-2434' is defined on line 1854, but no explicit reference was found in the text == Unused Reference: 'RFC-3756' is defined on line 1863, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 2462 (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 2472 (Obsoleted by RFC 5072, RFC 5172) -- Obsolete informational reference (is this intentional?): RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 3041 (Obsoleted by RFC 4941) -- Obsolete informational reference (is this intentional?): RFC 3344 (Obsoleted by RFC 5944) Summary: 11 errors (**), 0 flaws (~~), 14 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 NETLMM WG S. Gundavelli 3 Internet-Draft K. Leung 4 Intended status: Standards Track Cisco 5 Expires: October 10, 2007 V. Devarapalli 6 Azaire Networks 7 K. Chowdhury 8 Starent Networks 9 B. Patil 10 Nokia Siemens Networks 11 April 08, 2007 13 Proxy Mobile IPv6 14 draft-ietf-netlmm-proxymip6-00.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 October 10, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 Host based IPv6 mobility is specified in Mobile IPv6 base 48 specification [RFC3775]. In that model, the mobile node is 49 responsible for doing the signaling to its home agent to enable 50 session continuity as it moves between subnets. The design principle 51 in the case of host-based mobility relies on the mobile node being in 52 control of the mobility management. Network based mobility allows IP 53 session continuity for a mobile node without its involvement in 54 mobility management. This specification describes a protocol 55 solution for network based mobility management that relies on Mobile 56 IPv6 signaling and reuse of home agent functionality. A proxy 57 mobility agent in the network which manages the mobility for a mobile 58 node is the reason for referring to this protocol as Proxy Mobile 59 IPv6. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 2. Conventions & Terminology . . . . . . . . . . . . . . . . . . 5 65 2.1. Conventions used in this document . . . . . . . . . . . . 5 66 2.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 67 3. Proxy Mobile IPv6 Protocol Overview . . . . . . . . . . . . . 8 68 4. Proxy Mobile IPv6 Protocol Security . . . . . . . . . . . . . 11 69 4.1. Peer Authorization Database Entries . . . . . . . . . . . 12 70 4.2. Security Policy Database Entries . . . . . . . . . . . . . 12 71 5. Local Mobility Anchor Operation . . . . . . . . . . . . . . . 13 72 5.1. Extensions to Binding Cache Conceptual Data Structure . . 14 73 5.2. Bi-Directional Tunnel Management . . . . . . . . . . . . . 15 74 5.3. Routing Considerations . . . . . . . . . . . . . . . . . . 16 75 5.4. Local Mobility Anchor Address Discovery . . . . . . . . . 17 76 5.5. Sequence Number and Time-Stamps for Message Ordering . . . 17 77 5.6. Route Optimizations Considerations . . . . . . . . . . . . 19 78 5.7. Mobile Prefix Discovery Considerations . . . . . . . . . . 19 79 5.8. Local Mobility Anchor Operational Summary . . . . . . . . 19 80 6. Mobile Access Gateway Operation . . . . . . . . . . . . . . . 21 81 6.1. Address Configuration Models . . . . . . . . . . . . . . . 22 82 6.2. Conceptual Data Structures . . . . . . . . . . . . . . . . 23 83 6.3. Access Authentication . . . . . . . . . . . . . . . . . . 23 84 6.4. Home Network Emulation . . . . . . . . . . . . . . . . . . 24 85 6.5. Link-Local and Global Address Uniqueness . . . . . . . . . 24 86 6.6. Tunnel Management . . . . . . . . . . . . . . . . . . . . 25 87 6.7. Routing Considerations . . . . . . . . . . . . . . . . . . 26 88 6.8. Interaction with DHCP Relay Agent . . . . . . . . . . . . 27 89 6.9. Mobile Node Detachment Detection and Resource Cleanup . . 27 90 6.10. Coexistence with Mobile Nodes using Host-based Mobility . 28 91 6.11. Mobile Access Gateway Operation Summary . . . . . . . . . 29 92 7. Mobile Node Operation . . . . . . . . . . . . . . . . . . . . 31 93 7.1. Booting up in a Proxy Mobile IPv6 Domain . . . . . . . . . 32 94 7.2. Roaming in the Proxy Mobile IPv6 Network . . . . . . . . . 33 95 7.3. IPv6 Host Protocol Parameters . . . . . . . . . . . . . . 33 97 8. Message Formats . . . . . . . . . . . . . . . . . . . . . . . 34 98 8.1. Proxy Binding Update . . . . . . . . . . . . . . . . . . . 35 99 8.2. Proxy Binding Acknowledgment . . . . . . . . . . . . . . . 35 100 8.3. Home Network Prefix Option . . . . . . . . . . . . . . . . 36 101 8.4. Time Stamp Option . . . . . . . . . . . . . . . . . . . . 38 102 8.5. Status Codes . . . . . . . . . . . . . . . . . . . . . . . 38 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 104 10. Security Considerations . . . . . . . . . . . . . . . . . . . 39 105 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 40 106 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 41 107 12.1. Normative References . . . . . . . . . . . . . . . . . . . 41 108 12.2. Informative References . . . . . . . . . . . . . . . . . . 42 109 Appendix A. Proxy Mobile IPv6 interactions with AAA 110 Infrastructure . . . . . . . . . . . . . . . . . . . 43 111 Appendix B. Supporting Shared-Prefix Model using DHCPv6 . . . . . 43 112 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 113 Intellectual Property and Copyright Statements . . . . . . . . . . 46 115 1. Introduction 117 Mobile IPv6 [RFC-3775] is the enabler for IPv6 mobility. It requires 118 Mobile IPv6 client functionality in the IPv6 stack of a mobile node. 119 Signaling between the MN and HA enables the creation and maintenance 120 of a binding between the MNs home address and care-of-address. 121 Mobile IPv6 has been designed to be an integral part of the IPv6 122 stack in a host. However there exist IPv6 stacks today that do not 123 have Mobile IPv6 functionality and there would likely be IPv6 stacks 124 without MIPv6 functionality in the future as well. It is desirable 125 to support IP mobility for all hosts irrespective of the presence or 126 absence of mobile IPv6 functionality in the IPv6 stack. 128 It is possible to support mobility for IPv6 nodes by extending Mobile 129 IPv6 [RFC-3775] signaling and reusing the home agent via a proxy 130 mobility agent in the network. This approach to supporting mobility 131 does not require the mobile node to be involved in the signaling 132 required for mobility management. The proxy agent in the network 133 performs the signaling and does the mobility management on behalf of 134 the mobile node. Because of the use and extension of Mobile IPv6 135 signaling and home agent functionality, it is referred to as Proxy 136 Mobile IPv6 (PMIP6) in the context of this document. 138 Network deployments which are designed to support mobility would be 139 agnostic to the capability in the IPv6 stack of the nodes which it 140 serves. IP mobility for nodes which have mobile IP client 141 functionality in the IPv6 stack as well as those hosts which do not, 142 would be supported by enabling PMIP6 protocol functionality in the 143 network. The advantages of developing a network based mobility 144 protocol based on Mobile IPv6 are: 146 o Reuse of home agent functionality and the messages/format used in 147 mobility signaling. Mobile IPv6 is a mature protocol with several 148 implementations that have been through interoperability testing. 150 o A common home agent would serve as the mobility agent for all 151 types of IPv6 nodes. 153 o Addresses a real deployment need. 155 The problem statement and the need for a network based mobility 156 protocol solution has been documented in 157 [draft-ietf-netlmm-nohost-ps-05.txt]. PMIP6 is a solution that 158 addresses these issues and requirements. 160 The IP Mobility protocols designed in the IETF so far involve the 161 host in mobility management. There are some deployment scenarios 162 where a network-based mobility management protocol is considered 163 appropriate. The advantages to using a network-based mobility 164 protocol include avoiding tunneling overhead over the air and support 165 for hosts that do not implement any mobility management protocol. 167 The document describes a network-based mobility management protocol 168 based on Mobile IPv6. it is called Proxy Mobile IPv6 (PMIPv6). One 169 of the most important design considerations behind PMIPv6 has been to 170 re-use as much as possible from the existing mobility protocols. 172 There are many advantages to develop a protocol based on Mobile IPv6. 173 Mobile IPv6 is a very mature mobility protocol for IPv6. There have 174 been many implementations and inter-operability events where Mobile 175 IPv6 has been tested. There also numerous specifications enhancing 176 Mobile IPv6 that can be re-used. Further, the Proxy MIPv6 solution 177 described in this document allows the same Home Agent to provide 178 mobility to hosts that use Mobile IPv6 and hosts that do not use any 179 mobility management protocol. Proxy Mobile IPv6 provides solution to 180 a real deployment problem. 182 The specific details related to enabling IPv4 home address mobility 183 for the mobile node and the details related to supporting IPv4 184 transport network are covered in the companion document. 186 2. Conventions & Terminology 188 2.1. Conventions used in this document 190 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 191 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" used in 192 this document are to be interpreted as described in RFC 2119. 194 2.2. Terminology 196 All the general mobility related terms used in this document are to 197 be interpreted as defined in the Mobile IPv6 base specification [RFC- 198 3775]. 200 This document adopts the terms, Local Mobility Anchor (LMA) and 201 Mobile Access Gateway (MAG) from the NETLMM Goals document 202 [draft-ietf-netlmm-nohost-req-05.txt]. It further provides the 203 following context specific explanation to these terms, specific to 204 this solution document. 206 Local Mobility Anchor (LMA) 207 Local Mobility Anchor is the home agent for the mobile node in the 208 Proxy Mobile IPv6 domain. It is the topological anchor point for 209 the mobile node's home prefix and is the entity that manages the 210 mobile node's reachability state. It is important to understand 211 that the LMA has the functional capabilities of a home agent as 212 defined in Mobile IPv6 base specification [RFC-3775] and with the 213 additional required capabilities for supporting Proxy Mobile IPv6 214 as defined in this specification. 216 Proxy Mobile Agent (PMA) 218 Proxy mobility agent is a function that manages the mobility 219 related signaling for a mobile node that is attached to its access 220 link. It is responsible for tracking the mobile node's attachment 221 to the link and for signaling the mobile node's local mobility 222 anchor. 224 Mobile Access Gateway (MAG) 226 It is the entity where the Proxy Mobile Agent function resides. 228 Mobile Node (MN) 230 Through out this document, the term mobile node is used to refer 231 to an IP node whose mobility is provided by the network. The 232 mobile node may be operating in IPv6 mode, IPv4 mode or in IPv4/ 233 IPv6 dual mode. The mobile node is not required to participate in 234 any mobility related signaling for achieving mobility for an IP 235 address that is obtained in that local domain. This document 236 further uses explicit text when referring to a mobile node that is 237 involved in mobility related signaling as per Mobile IPv6 238 specification [RFC-3775]. The mobile node's capability or its 239 involvement in any mobility related signaling for obtaining 240 mobility for an address that is obtained outside the current proxy 241 mobile IPv6 domain, is not relevant in the context of this 242 document and this definition of the Mobile Node shall survive. 244 Mobile Node's Home Address (MN-HoA) 246 MN-HoA is the home address of a mobile node in a Proxy Mobile IPv6 247 domain. It is an address obtained by the mobile node in that 248 domain. The mobile node can continue to use this address as long 249 as it is attached to the network that is in the scope of that 250 Proxy Mobile IPv6 domain. When supporting IPv4 address mobility 251 for a mobile node, the term, IPv4 MN-HoA is used to refer to the 252 IPv4 address of the mobile node. 254 Proxy Care-of Address (Proxy-CoA) 255 Proxy-CoA is the address configured on the interface of the mobile 256 access gateway and is the transport endpoint of the tunnel between 257 the local mobility anchor and the mobile access gateway. The 258 local mobility anchor views this address as the Care-of Address of 259 the mobile node and registers it in the Binding Cache entry for 260 that mobile node. When the transport network between the mobile 261 access gateway and the local mobility anchor is an IPv4 network 262 and if the care-of address that is registered at the local 263 mobility anchor is an IPv4 address, the term, IPv4 Proxy-CoA is 264 used. 266 LMA Address (LMAA) 268 The address that is configured on the interface of the local 269 mobility anchor and is the transport endpoint of the tunnel 270 between the local mobility anchor and the mobile access gateway. 271 This is the address to where the mobile access gateway sends the 272 Proxy Binding Update messages. When supporting IPv4 traversal, 273 i.e. when the network between the local mobility anchor and the 274 mobile access gateway is an IPv4 network, this address will be an 275 IPv4 address and will be referred to as IPv4 LMAA. 277 Proxy Mobile IPv6 Domain (PMIPv6-Domain) 279 It is a localized mobility management domain. It is a portion of 280 the access network where the mobility management of a mobile node 281 is handled using Proxy Mobile IPv6 protocol as defined in this 282 specification. 284 Mobile Node's Home Link 286 This is the link on which the mobile node obtained its initial 287 address configuration after it moved into that Proxy Mobile IPv6 288 domain. This is the link that conceptually follows the mobile 289 node. The network will ensure the mobile node always sees this 290 link with respect to the layer-3 network configuration, on any 291 access link that it attaches to in that proxy mobile IPv6 domain. 293 Mobile Node's Home Network Prefix (MN-HNP) 295 This is the on-link prefix that the mobile always sees in the 296 Proxy Mobile IPv6 domain. The home network prefix is 297 topologically anchored at the mobile's local mobility anchor. The 298 mobile node configures its interface with an address from this 299 prefix. When supporting IPv4 home address mobility, the term, 300 IPv4 Home Network refers to the mobile node's IPv4 home prefix and 301 the term, Home Network always refers to the IPv6 home network 302 prefix. 304 Mobile Node Identifier (MN-Identifier) 306 The identity of the mobile node that is presented to the network 307 as part of the access authentication. This is typically an 308 identifier such as Mobile Node NAI [RFC-4283] any other type of 309 identifier which may be specific to the access technology. 311 Proxy Binding Update (PBU) 313 A signaling message sent by the mobile access gateway to a mobile 314 node's local mobility anchor for establishing a binding between 315 the mobile node's MN-HoA and the Proxy-CoA. 317 Proxy Binding Acknowledgement (PBA) 319 A response message sent by a local mobility anchor in response to 320 a Proxy Binding Update message that it received from a mobile 321 access gateway. 323 3. Proxy Mobile IPv6 Protocol Overview 325 This specification describes a network-based mobility management 326 protocol. It is called Proxy Mobile IPv6 (PMIPv6) and is based on 327 Mobile IPv6 [RFC-3775]. This protocol is for providing network-based 328 mobility management support to a mobile node, within a restricted and 329 topologically localized portion of the network and with out requiring 330 the participation of the mobile node in any mobility related 331 signaling. 333 Every mobile node that roams in a Proxy Mobile IPv6 domain, would 334 typically be identified by an identifier, such as MN-Identifier, and 335 using that identifier the mobile node's policy profile can be 336 obtained from the policy store. The policy profile typically 337 contains the provisioned network-based mobility service 338 characterstics and other related parameters such as the mobile node's 339 home network prefix, permitted address configuration modes, roaming 340 policy and other parameters that are essential for providing network 341 based mobility service. 343 Once a mobile node enters its Proxy Mobile IPv6 domain and performs 344 access authentication, the network will ensure the mobile node is 345 always on its home network and further ensures the mobile node can 346 always obtain its home address on the access link and using any of 347 the address configuration procedures. In other words, there is home 348 network prefix that is assigned for a mobile node and conceptually 349 that address always follows the mobile node, where ever it roams 350 within that proxy mobile IPv6 domain. From the perspective of the 351 mobile node, the entire Proxy Mobile IPv6 domain appears as its home 352 link or a single link. 354 +----+ +----+ 355 |LMA1| |LMA2| 356 +----+ +----+ 357 LMAA1---- | | ---- LMAA2 358 | | 359 \\ // \\ 360 +--\\------------- //---\\----+ 361 ( \\ IPv4/IPv6 // \\ ) 362 ( \\ Network // \\ ) 363 +-----\\--------//---------\\-+ 364 \\ // \\ 365 \\ // \\ <--- Tunnel2 366 \\ // \\ 367 |-- Proxy-CoA1 |-- Proxy-CoA2 368 +----+ +----+ 369 [MN1].__.|MAG1|.__.[MN2] |MAG2| 370 +----+ +----+ 371 | | 372 | | 373 ------------------- [MN5] 374 | | 375 [MN3] [MN4] 377 Figure 1: Proxy Mobile IPv6 Domain 379 The Proxy Mobile IPv6 scheme introduces a new function, the mobile 380 access gateway. It is a function that is on the access link where 381 the mobile is anchored and does the mobility related signaling on 382 behalf of the mobile node. From the perspective of the local 383 mobility anchor, the mobile access gateway is a special element in 384 the network that is authorized to send Mobile IPv6 signaling messages 385 on behalf of a mobile node. 387 When the mobile node attaches to an access link connected to the 388 mobile access gateway, the mobile node presents its identity, MN- 389 Identifier, as part of the access access authentication procedure. 390 After a successful access authentication, the mobile access gateway 391 obtains the mobile node's profile from the policy store, such as from 392 a AAA infrastructure. The mobile access gatway would have all the 393 information for it to emulate the mobile node's home network on the 394 access link. The mobile access gateway also starts sending periodic 395 Router Advertisements to the mobile node advertising its home network 396 prefix. 398 The mobile node on receiving these Router Advertisement messages on 399 the access link will attempt to configure its interface either using 400 statefull or stateless address configuration modes, based on modes 401 that are permitted on that access link. At the end of a successful 402 address configuration procedure, the mobile node would have obtained 403 an address from its home network prefix. If the mobile node is IPv4 404 capable and if network offers IPv4 network mobility for the mobile 405 node, the mobile node would have obtained an IPv4 address as well. 406 The mobile node can be operating in IPv4-only mode, IPv6-only or in 407 dual-mode and based on the services enabled for that mobile, the 408 mobility is enabled only for those address types. Also, the network 409 between the local mobility anchor and the mobile access gateway can 410 be either IPv4, IPv6, IPv4 with NAT translation devices in the access 411 network. 413 For updating the local mobility anchor about the current location of 414 the mobile node, the mobile access gateway sends a Proxy Binding 415 Update message to the mobile node's local mobility anchor. The 416 message will have the mobile node's NAI identifier option and Home 417 Network Prefix Option and/or IPv4 Home Address option. The source 418 address of that message will be the address of the mobile access 419 gateway on its egress interface. Upon accepting the Proxy Binding 420 Update request, the local mobility anchor sends a Proxy Binding 421 Acknowledgment message to the mobile access gateway. It also sets up 422 a route to the mobile node's home network prefix over the tunnel and 423 sends Proxy Binding Acknowledgment message to the mobile access 424 gateway. 426 The mobile access gateway on receiving this Proxy Binding 427 Acknowledgment message sets up a tunnel to the local mobility anchor 428 and adds a default route over the tunnel to the local mobility 429 anchor. All traffic from the mobile node gets routed to the mobile 430 node's local mobility anchor over the tunnel. 432 At this point, the mobile node has a valid home address from its home 433 network prefix, at the current point of attachment. The serving 434 mobile access gateway and the local mobility anchor also have proper 435 routing states for handling the traffic sent to and from the mobile 436 node. 438 The local mobility anchor, being the topological anchor point for the 439 mobile node's home network prefix, it receives any packet sent by any 440 corresponding node to the mobile node. Local mobility anchor 441 forwards the received packet to the mobile access gateway through the 442 tunnel. The mobile access gateway on other end of the tunnel, after 443 receiving the packet removes the tunnel header and forwards the 444 packet on the access link to the mobile node. 446 The mobile access gateway typically acts as a default router on the 447 access link and any packet that the mobile node sends to any 448 corresponding node is received by the mobile access gateway and it 449 forwards the packet to the local mobility anchor through the tunnel. 450 The local mobility anchor on the other end of the tunnel, after 451 receiving the packet removes the tunnel header and routes the packet 452 to the destination. 454 4. Proxy Mobile IPv6 Protocol Security 456 The signaling messages, Proxy Binding Update and Proxy Binding 457 Acknowledgement, exchanged between the mobile access gateway and the 458 local mobility anchor are protected using IPsec and using the 459 established security association between them. The security 460 association of the specific mobile node for which the signaling 461 message is initiated is not required for protecting these messages. 463 ESP in transport mode with mandatory integrity protection is used for 464 protecting the signaling messages. Confidentiality protection is not 465 required. 467 IKEv2 is used to setup security associations between the mobile 468 access gateway and the local mobility anchor to protect the Proxy 469 Binding Update and Proxy Binding Acknowledgment messages. The mobile 470 access gateway and the local mobility anchor can use any of the 471 authentication mechanisms, as specified in IKEv2, for mutual 472 authentication. 474 Mobile IPv6 specification requires the home agent to prevent a mobile 475 node from creating security associations or creating binding cache 476 entries for another mobile node's home address. In the protocol 477 described in this document, the mobile node is not involved in 478 creating security associations for protecting the signaling messages 479 or sending binding updates. Therefore, this is not a concern. 480 However, the local mobility anchor MUST allow only authorized mobile 481 access gateways to create binding cache entries on behalf of the 482 mobile nodes. The actual mechanism by which the local mobility 483 anchor verifies if a specific mobile access gateway is authorized to 484 send Proxy Binding Updates on behalf of a mobile node is outside the 485 scope of this document. One possible way this could be achieved is 486 sending a query to the policy store such as by using AAA 487 infrastrucure. 489 4.1. Peer Authorization Database Entries 491 The following describes PAD entries on the mobile access gateway and 492 the local mobility anchor. The PAD entries are only example 493 configurations. Note that the PAD is a logical concept and a 494 particular mobile access gateway or a local mobility anchor 495 implementation can implement the PAD in an implementation specific 496 manner. The PAD state may also be distributed across various 497 databases in a specific implementation. 499 mobile access gateway PAD: 500 - IF remote_identity = lma_identity_1 501 Then authenticate (shared secret/certificate/EAP) 502 and authorize CHILD_SA for remote address lma_addres_1 504 local mobility anchor PAD: 505 - IF remote_identity = mag_identity_1 506 Then authenticate (shared secret/certificate/EAP) 507 and authorize CHILD_SAs for remote address mag_address_1 509 The list of authentication mechanisms in the above examples is not 510 exhaustive. There could be other credentials used for authentication 511 stored in the PAD. 513 4.2. Security Policy Database Entries 515 The following describes the security policy entries on the mobile 516 access gateway and the local mobility anchor required to protect the 517 Proxy Mobile IPv6 signaling messages. The SPD entries are only 518 example configurations. A particular mobile access gateway or a 519 local mobility anchor implementation could configure different SPD 520 entries as long as they provide the required security. 522 In the examples shown below, the identity of the mobile access 523 gateway is assumed to be mag_1, the address of the mobile access 524 gateway is assumed to be mag_address_1, and the address of the local 525 mobility anchor is assumed to be lma_address_1. 527 mobile access gateway SPD-S: 528 - IF local_address = mag_address_1 & 529 remote_address = lma_address_1 & 530 proto = MH & local_mh_type = BU & remote_mh_type = BAck 531 Then use SA ESP transport mode 532 Initiate using IDi = mag_1 to address lma_1 534 local mobility anchor SPD-S: 535 - IF local_address = lma_address_1 & 536 remote_address = mag_address_1 & 537 proto = MH & local_mh_type = BAck & remote_mh_type = BU 538 Then use SA ESP transport mode 540 5. Local Mobility Anchor Operation 542 For supporting the Proxy Mobile IPv6 scheme defined in this document, 543 the Mobile IPv6 home agent entity, defined in Mobile IPv6 544 specification [RFC-3775], needs some protocol enhancements. The 545 local mobility anchor is the functional entity with these 546 capabilities for supporting Proxy Mobile IPv6. This section 547 describes the operational details of the local mobility anchor. 549 The base Mobile IPv6 specification [RFC-3775], defines home agent and 550 the mobile node as the two functional entities. The Proxy Mobile 551 IPv6 scheme introduces a new entity, the mobile access gateway. This 552 is the entity that will participate in the mobility related 553 signaling. From the perspective of the local mobility anchor, the 554 mobile access gateway is a special element in the network that has 555 the privileges to send mobility related signaling messages on behalf 556 of the mobile node. Typically, the local mobility anchor is 557 provisioned with the list of mobile access gateways authorized to 558 send proxy registrations. 560 When the local mobility anchor receives a Proxy Binding Update 561 message from a mobile access gateway, the message is protected using 562 the IPSec Security Association established between the local mobility 563 anchor and the mobile access gateway. The local mobility anchor can 564 distinguish between a Proxy Binding Update message received from a 565 mobile access gateway from a Binding Update message received directly 566 from a mobile node. This distinction is important for using the 567 right security association for validating the Binding Update and this 568 is achieved by relaxing the MUST requirement for having the Home 569 Address Option presence in Destination Options header and by 570 introducing a new flag in the Binding Update message. The local 571 mobility anchor as a traditional IPSec peer can use the SPI in the 572 IPSec header [RFC-4306] of the received packet for locating the 573 correct security association and for processing the Proxy Binding 574 Update message in the context of the Proxy Mobile IPv6 scheme. 576 For protocol simplicity, the current specification supports the Per- 577 MN-Prefix addressing model. In this addressing model, each mobile 578 node is allocated an exclusively unique home network prefix and the 579 prefix is not hosted on the home link. The local mobility anchor in 580 this addressing model is just a topological anchor point and the 581 prefix is physically hosted on the access link where the mobile node 582 is attached. The local mobility anchor is not required to perform 583 any proxy ND operations [RFC-2461] for defending the mobile node's 584 home address, MN-HoA, on the home link. However, the local mobility 585 anchor is required to manage the binding cache entry of the mobile 586 node for managing the mobility session and also the routing state for 587 creating a proper route path for traffic to/from the mobile node. 589 5.1. Extensions to Binding Cache Conceptual Data Structure 591 The local mobility anchor maintains a Binding Cache entry for each 592 currently registered mobile node. Binding Cache is a conceptual data 593 structure, described in Section 9.1 of [RFC3775]. For supporting 594 this specification, the conceptual Binding Cache entry needs to be 595 extended with the following new fields. 597 o A flag indicating whether or not this Binding Cache entry is 598 created due to a proxy registration. This flag is enabled for 599 Binding Cache entries that are proxy registrations and is turned 600 off for all other entries that are direct registrations from the 601 mobile node. 603 o A flag indicating if IPv6 HoA mobility is accepted. If this flag 604 is set, the relevant IPv6 HoA fields in this data structure have 605 to be set to the configured values. If this flag. 607 o The identifier of the mobile node, MN-Identifier. This MN- 608 Identifier is obtained from the NAI Option present in the Proxy 609 Binding Update request [RFC-4285]. 611 o A flag indicating whether or not the Binding Cache entry has a 612 home address that is on virtual interface. This flag is enabled, 613 if the home prefix of the mobile is configured on a virtual 614 interface. When the configured home prefix of a mobile is on a 615 virtual interface, the home agent is not required to function as a 616 Neighbor Discovery proxy for the mobile node. 618 o The IPv6 home network prefix of the mobile node. 620 o The IPv6 home network prefix length of the mobile node. 622 o The interface id of the tunnel between the local mobility anchor 623 and the mobile access gateway used for sending and receiving the 624 mobile node's traffic. 626 o Tentative binding cache entry with all the above fields. This 627 entry is populated upon tentatively accepting a proxy binding 628 update request for a mobile node whose direct registration still 629 exists, i.e. the mobile has not deregistered and it received a 630 proxy binding update request. 632 5.2. Bi-Directional Tunnel Management 634 The bi-directional tunnel between the local mobility anchor and the 635 mobile access gateway is used for routing the traffic to and from the 636 mobile node. The tunnel hides the topology and enables a mobile node 637 to use an IP address that is topologically anchored at the local 638 mobility anchor, from any attached access link in that proxy mobile 639 IPv6 domain. The base Mobile IPv6 specification [RFC-3775], does use 640 the tunneling scheme for routing traffic to and from the mobile that 641 is using its home address. However, there are subtle differences in 642 the way Proxy Mobile IPv6 uses the tunneling scheme. 644 As in Mobile IPv4 [RFC-3344], the tunnel between the local mobility 645 anchor and the mobile access gateway is typically a shared tunnel and 646 can be used for routing traffic streams for different mobile nodes 647 attached to the same mobile access gateway. This specification 648 extends that 1:1 relation between a tunnel and a binding cache entry 649 to 1:m relation, reflecting the shared nature of the tunnel. 651 The tunnel is creating after accepting a Proxy Binding Update request 652 for a mobile node from a mobile access gateway. The created tunnel 653 may be shared with other mobile nodes attached to the same mobile 654 access gateway and with the local mobility anchor having a binding 655 cache entry for those mobile nodes. Some implementations may prefer 656 to use static tunnels as supposed to creating and tearing them down 657 on a need basis. 659 The one end point of the tunnel is the address configured on the 660 interface of the local mobility anchor, LMAA. The other end point of 661 the tunnel is the address configured on the interface of the mobile 662 access gateway, Proxy-CoA. The tunnel encapsulation mode can be 663 either IPv6/IPv6, IPv6/IPv4, IPv6/IPv4-UDP, IPv4/IPv6, IPv4/IPv4-UDP, 664 based on the transport mode and the presence of NAT translation 665 devices on the path. 667 Implementations typically use a software timer for managing the 668 tunnel lifetime and a counter for keeping a count of all the mobiles 669 that are sharing the tunnel. The timer value will be set to the 670 accepted binding life-time and will be updated after each periodic 671 registrations for extending the lifetime. If the tunnel is shared 672 for multiple mobile node's traffic, the tunnel lifetime will be set 673 to the highest binding life time across all the binding life time 674 that is granted for all the mobiles sharing that tunnel. 676 5.3. Routing Considerations 678 This section describes how the data traffic to/from the mobile node 679 is handled at the local mobility anchor. The following entries 680 explains the routing state that is created for the mobile node home 681 network prefix. 683 IPv6 traffic for the Mobile Node's home address: 684 ================================================ 685 MN-HoA::/64 via tunnel0, next-hop Proxy-CoA 687 tunnel0: 688 ======== 689 Source: LMAA 690 Destination: Proxy-CoA 691 Tunnel Transport: IPv6 692 Tunnel Payload: IPv6 694 The local mobility anchor functions as a topological anchor point for 695 the mobile node's home network prefix. When the local mobility 696 anchor receives a data packet from a corresponding node, destined for 697 the mobile node's home network prefix, the created routing state will 698 enable the packets to be forwarded to the mobile node through the bi- 699 directional tunnel established between itself and the serving mobile 700 access gateway. 702 If the tunnel between the local mobility anchor and the mobile access 703 gateway is an IPv6 tunnel, i.e. if the registered care-of address is 704 the IPv6 Proxy-CoA, any IPv6 packets received from any corresponding 705 node for the mobile node's home network prefix, MN-HNP, will be 706 encapsulated in an IPv6 packet, IPv6/IPv6 mode, and will be carried 707 as an IPv6 packet. And any IPv4 packets for the mobile node's IPv4- 708 MN-HoA, will be encapsulated in an IPv6 packet, IPv4/IPv6 mode, and 709 will be carried as an IPv6 packet. 711 All the reverse tunneled packets that the local mobility anchor 712 receives from the tunnel, after removing the packet encapsulation 713 will get routed to the destination specified in the inner packet 714 header. These routed packets will have the source address field set 715 to the mobile node's home address. 717 5.4. Local Mobility Anchor Address Discovery 719 Dynamic Home Agent Address Discovery, as explained in Section 10.5 of 720 [RFC-3775], allows a mobile node to discover all the home agents on 721 its home link by sending an ICMP Home Agent Address Discovery Request 722 message to the Mobile IPv6 Home-Agents anycast address, derived from 723 its home network prefix. 725 The Proxy Mobile IPv6 model assumes that the mobile access gateway 726 will be able to obtain the address of the local mobility anchor in 727 one or more ways. This MAY be a configured entry in the mobile 728 node's policy profile, or it MAY be obtained through mechanisms 729 outside the scope of this document. It is important to note that 730 there is little value in using DHAAD for discovering the local 731 mobility anchor address dynamically. As a mobile moves from one 732 mobile access gateway to the another, the serving mobile access 733 gateway will not predictably be able to locate the serving local 734 mobility anchor for that mobile that has its binding cache entry for 735 the mobile node. However, if there is only one local mobility anchor 736 configured to serve a mobile node, the mobile access gateway can use 737 Dynamic Home Agent Address Discovery scheme for discovering the 738 address of the local mobility anchor. 740 With the currently supported Per-MN-Prefix addressing model, every 741 mobile node is assigned a unique home network prefix, the local 742 mobility anchor is a topological anchor point for that prefix and 743 with the prefix being hosted on the access link attached to the 744 mobile access gateway. For the discovery scheme to work, the local 745 mobility anchor MUST be able to receive the ICMP discovery packets 746 sent to the anycast address derived from the mobile node's home 747 network prefix. 749 5.5. Sequence Number and Time-Stamps for Message Ordering 751 Mobile IPv6 [RFC-3775] uses the Sequence Number field in registration 752 messages as a way to ensure the correct packet ordering. The local 753 mobility anchor and the mobile node are required to manage this 754 counter over the lifetime of a binding. 756 In Proxy Mobile IPv6, the Proxy Binding Update messages that the 757 local mobility anchor receives on behalf of a specific mobile node 758 may not be from the same mobile access gateway as the previously 759 received message. It creates certain ambiguity and the local 760 mobility anchor will not be predictably order the messages. This 761 could lead to the local mobility anchor processing an older message 762 from a mobile access gateway where the mobile node was previously 763 attached, while ignoring the latest binding update message. 765 In the Proxy Mobile IPv6, the ordering of packets has to be 766 established accross packets received from multiple senders. The 767 sequence number scheme as specified in [RFC-3775] will not be 768 sufficient. A global scale, such as a time stamp, can be used to 769 ensure the correct ordering of the packets. This document proposes 770 the use of a Time Stamp Option, specified in Section 8.4, in all 771 Proxy Binding Update messages sent by mobile access gateways. By 772 leveraging the NTP [RFC-1305] service, all the entities in Proxy 773 Mobile IPv6 domain will be able to synchronize their respective 774 clocks. Having a time stamp option in Proxy Binding Update messages 775 will enable the local mobility anchor to predictably identify the 776 latest message from a list of messages delivered in an out-of-order 777 fashion. 779 The Proxy Mobile IP model, defined in this document requires the 780 Binding Update messages sent by the mobile access gateway to have the 781 time stamp option. The local mobility anchor processing a proxy 782 registration MUST ignore the sequence number field and SHOULD use the 783 value from the Time Stamp option to establish ordering of the 784 received Binding Update messages. If the local mobility anchor 785 receives a Binding Update message with an invalid Time Stamp Option, 786 the Binding Update MUST be rejected and a Binding Acknowledgement 787 MUST be returned in which the Status field is set to 148 (invalid 788 time stamp option). 790 In the absence of Time Stamp option in the Proxy Binding Update, the 791 entities can fall back to Sequence Number scheme for message 792 ordering, as defined in RFC-3775. However, the specifics on how 793 different mobile access gateways synchronize the sequence number is 794 outside the scope of this document. 796 When using the Time Stamp Option, the local mobility anchor or the 797 mobile access gateway MUST set the the timestamp field to a 64-bit 798 value formatted as specified by the Network Time Protocol [RFC-1305]. 799 The low-order 32 bits of the NTP format represent fractional seconds, 800 and those bits which are not available from a time source SHOULD be 801 generated from a good source of randomness. 803 5.6. Route Optimizations Considerations 805 Mobile IPv6 route optimization, as defined in [RFC-3775], enables a 806 mobile node to communicate with a corresponding node directly using 807 its care-of address and further the Return Routability procedure 808 enables the corresponding node to have reasonable trust that the 809 mobile node owns both the home address and care-of address. 811 In the Proxy Mobile IPv6 model, the mobile is not involved in any 812 mobility related signaling and also it does not operate in the dual- 813 address mode. Hence, the return routability procedure as defined in 814 RFC-3775 is not applicable for the proxy model. This document does 815 not address the Route Optimization problem and leaves this work item 816 for future enhancements. 818 5.7. Mobile Prefix Discovery Considerations 820 The ICMP Mobile Prefix Advertisement message, described in Section 821 6.8 and Section 11.4.3 of [RFC-3775], allows a home agent to send a 822 Mobile Prefix Advertisement to the mobile node. 824 In Proxy Mobile IPv6 deployments, the mobile node's home network 825 prefix is hosted on the access link shared between the mobile access 826 gateway and the mobile node, but topologically anchored on the local 827 mobility anchor. Since, there is no physical home-link for the 828 mobile node's home network prefix on the local mobility anchor and as 829 the mobile is always on the link where the prefix is hosted, any 830 prefix change messages can just be advertised by the mobile access 831 gateway on the access link and thus there is no applicability of this 832 messaging for Proxy Mobile IPv6. This specification does not support 833 Mobile Prefix Discovery. 835 5.8. Local Mobility Anchor Operational Summary 837 o For supporting this scheme, the local mobility anchor MUST satisfy 838 all the requirements listed in Section 8.4 of Mobile IPv6 839 specification [RFC-3775] with the following considerations. 841 o For supporting the per-MN-Prefix addressing model as defined in 842 this specification, the local mobility anchor service MUST NOT be 843 tied to a specific interface. It SHOULD be able to accept Proxy 844 Binding Update requests sent to any of the addresses configured on 845 any of its interfaces. 847 o The requirement for a home agent to maintain a list of home agents 848 for a mobile node's home link is not applicable for the local 849 mobility anchor, when supporting Per-MN-Prefix addressing model as 850 there is no link specific relation between the two. 852 o After receiving a Proxy Binding Update request from a mobile 853 access gateway on behalf of mobile node, the local mobility anchor 854 MUST process the request as defined in Section 10, of the base 855 Mobile IPv6 specification [RFC-3775], with one exception that this 856 request is a proxy request, the sender is not the mobile node and 857 so the message has to be processed with the considerations 858 explained in this section. 860 o The local mobility anchor MUST apply the required policy checks, 861 as explained in Section 4.0 of this document to verify the sender 862 is a a trusted mobile access gateway, authorized to send proxy 863 binding updates requests on behalf of that mobile nodes, using its 864 own identity. The local mobility anchor must check the local/ 865 remote policy store to ensure the requesting node is authorized to 866 send proxy binding update requests. 868 o Upon accepting a proxy binding update request from a mobile access 869 gateway, the local mobility anchor must check if there exists a 870 binding cache entry for that mobile node, identified using the MN- 871 Identifier, that was created due to a direct registration from the 872 mobile node. If there exists a binding cache entry with the proxy 873 registration flag turned off, the local mobility anchor MUST NOT 874 modify that binding state, instead it must create a tentative 875 binding cache entry and update the tentative binding cache entry 876 fields of that binding cache entry. 878 o Upon receiving a Binding Update request from a mobile node with 879 lifetime value set to 0, from a tunnel between itself and a 880 trusted mobile access gateway, the local mobility anchor upon 881 accepting that de-registration message, MUST forward the Binding 882 Acknowledgement message in the tunnel from where it received the 883 Binding Update request. It must also replace the binding cache 884 entry with the tentative binding cache entry and enable routing 885 for the mobile node's home prefix through the proxy mobile IPv6 886 tunnel. 888 o The local mobility anchor MUST use the MN-Identifier present in 889 the NAI option of the Proxy Binding Update request for identifying 890 the mobile node. 892 o The local mobility anchor MUST ensure the prefix presented in the 893 Home Network Prefix option of the received Proxy Binding Update 894 request is owned by itself and further the mobile node identified 895 by MN-Identifier is authorized to use this prefix. 897 o The local mobility anchor MUST ignore the sequence number field in 898 the Proxy Binding Updates requests, if the Time-Stamp Option is 899 present in the message. It must also skip all the checks related 900 to sequence number as suggested in the Mobile IPv6 specification 901 [RFC-3775]. However, the received sequence number MUST be copied 902 and returned in the Proxy Binding Acknowledgement sent to the 903 mobile access gateway. 905 o Upon accepting this request, the local mobility anchor must create 906 a Binding Cache entry with the home address from the Home Network 907 Prefix Option in the Binding Update and must set up a tunnel to 908 the proxy mobile agent serving the mobile node. This bi- 909 directional tunnel between the local mobility anchor and the 910 mobile access gateway is used for routing the mobile traffic. 912 o The local mobility anchors SHOULD drop all HoTI messages received 913 for a home address that has corresponding Binding Cache entry with 914 the proxy registration flag set. 916 o The local mobility anchor must handle the mobile node's data 917 traffic as explained in the Routing Considerations section of this 918 document. 920 6. Mobile Access Gateway Operation 922 The Proxy Mobile IPv6 scheme specified in this document, introduces a 923 new functional entity, the Mobile Access Gateway (MAG). It is the 924 entity that detects the mobile node's movements and initiates the 925 signaling with the mobile node's local mobility anchor for updating 926 the route to the mobile node's home address. In essence, the mobile 927 access gateway performs mobility management on behalf of the mobile 928 node. 930 From the perspective of the local mobility anchor, the mobile access 931 gateway is a special element in the network that sends Mobile IPv6 932 signaling messages on behalf of a mobile node, but using its own 933 identity. It is the entity that binds the mobile node's home address 934 to an address on its own access interface. 936 The mobile access gateway has the following functional roles. 938 o It is responsible for detecting the mobile node's attachment or 939 detachment on the connected access link and for initiating the 940 mobility signaling to the mobile node's local mobility anchor. 942 o Emulation of the mobile node's home link on the access link. 944 o It is responsible for setting up the data path for enabling the 945 mobile node to use its home address for communication from the 946 access link. 948 This Proxy Mobile IPv6 scheme is independent of the underlying access 949 technology or the link model. The interface between the mobile node 950 and the mobile access gateway can be either: 952 o Point-to-Point Link 954 o Shared Link 956 This specification does not support split links. 958 6.1. Address Configuration Models 960 Currently, this specification only supports Per-MN-Prefix model In 961 the Per-MN-Prefix model, there is a unique home network prefix 962 assigned for each mobile node and that prefix is hosted on the access 963 link. Conceptually, the prefix just follows the mobile node as it 964 moves within the proxy mobile IPv6 domain. In this addressing model, 965 based on the administrative policy, the mobile node can use either 966 Stateless Address Autoconfiguration or Statefull Address 967 Configuration using DHCP for obtaining the IPv6 address configuration 968 for its interface on the access link. Further, the mobile node can 969 also generate interface identifiers with privacy considerations, as 970 specified in Privacy Extensions specification [RFC-3041] and as per 971 CGA specification [RFC-3042]. For IPv4 home address configuration, 972 the mobile node can obtain the address configuration using DHCP or 973 optionally by using IPCP. In addition to this, Other address 974 configuration mechanisms specific to the access link between the 975 mobile node and the mobile access gateway may also be used by the 976 mobile node. 978 The configured administrative policy for the mobile dictates the type 979 of addressing model that is supported for a mobile on the access 980 link. The mobile access gateway on the access router will control 981 this by setting the relevant flags in the Router Advertisement that 982 it sends on the access link. 984 6.2. Conceptual Data Structures 986 Every mobile access gateway maintains a Binding Update List for each 987 currently attached mobile node. The Binding Update List is a 988 conceptual data structure, described in Section 11.1 of Mobile IPv6 989 base specification [RFC-3775]. For supporting this specification, 990 the conceptual Binding Update List data structure must be extended 991 with the following new additional fields. 993 o The Identifier of the mobile node, MN-Identifier. The format of 994 the MN-Identifier is specific to the access technology. This MN 995 identifier is obtained as part of the Access Authentication 996 procedure and is used for downloading the mobile node's profile 997 from the policy store. 999 o The physical address or the MAC address of the mobile node's 1000 connected interface. 1002 o The IPv6 home network prefix of the mobile node. 1004 o The IPv6 home network prefix length of the mobile node. 1006 o The link-local address of the mobile node on the link. This 1007 address MAY be learnt from the source address of the Router 1008 Solicitation message received from the mobile node. 1010 o The tunnel identifier of the tunnel between the mobile access 1011 gateway and the local mobility anchor used for reverse tunneling 1012 the mobile node's traffic. On a given implementation, if a tunnel 1013 appears like a virtual interface, that applies the proper 1014 encapsulation on every packet that is routed through that 1015 interface, then the interface identifier is stored in the binding 1016 update list. entry. 1018 6.3. Access Authentication 1020 When a mobile node attaches to the access link connected to the 1021 mobile access gateway, the deployed access security protocols will 1022 ensure that only authorized mobile nodes will be able to access the 1023 link and further the mobile access gateway will be able to identify 1024 the mobile node by its MN-Identifier and optionally will be able to 1025 detect the mobile node's attachment or detachment to the link. The 1026 exact specifics on how this is achieved is outside the scope of this 1027 document. This document goes with the stated assumption of having an 1028 established trust between the mobile node and mobile access gateway 1029 on the access link before the protocol operation begins. The mobile 1030 access gateway will be able to use the mobile node's MN-Identity and 1031 will be obtain its policy profile from the network policy store or 1032 from the local policy store. 1034 6.4. Home Network Emulation 1036 One of the key functions of the mobile access gateway is to emulate 1037 the mobile node's home network on the access link. It has to ensure, 1038 the mobile node believes it is connected to its home link or the link 1039 where it obtained its address configuration after it moved into that 1040 proxy mobile IPv6 domain. After the access authentication is 1041 complete, the mobile access gateway will have access to the mobile 1042 node's profile, obtained from querying a local/network policy store 1043 or provided to it as part of some context transfer procedure. After 1044 this point, the mobile access gateway will have enough information to 1045 emulate the mobile node's home link. It must send the Router 1046 Advertisement messages advertising the mobile node's home network 1047 prefix and other parameters. 1049 If the access link connecting the mobile access gateway and the 1050 mobile node is a point-to-point link, the Router Advertisements 1051 advertising a specific home network prefix is received only by the 1052 respective mobile node and hence there is clearly a unique link for 1053 each mobile node that is attached to that mobile access gateway. 1055 If the access link connecting the mobile access gateway and the 1056 mobile node is a shared-link, the mobile access gateway MUST ensure 1057 that each of the mobile node that is attached to that link receives 1058 Router Advertisements with its respective home network prefix as the 1059 on-link prefix. For this to happen, the mobile access gateway MUST 1060 unicast the Router Advertisement to the mobile node. The destination 1061 field of the link-layer header in the Router Advertisement MUST be 1062 the mobile's node's interface physical/MAC address and however, the 1063 destination field in the IPv6 header set to the all-nodes-multicast 1064 address. 1066 6.5. Link-Local and Global Address Uniqueness 1068 A mobile node in a proxy mobile IPv6 domain, as it moves from one 1069 access link to the other, will continue to detect its home network 1070 and hence the issue of link-local address uniqueness arises. The 1071 link-local that the mobile node attempts to use on the new link must 1072 be unique. 1074 On a point-to-point link, such as in a PPP session, when the mobile 1075 node tries to establish a PPP session [RFC-1661] with the mobile 1076 access gateway, the PPP goes through the Network layer Protocol phase 1077 and the IPv6 Control Protocol, IPCP6 [RFC-2472] gets triggered. Both 1078 the PPP peers negotiate a unique identifier using Interface- 1079 Identifier option in IPV6CP and the negotiated identifier is used for 1080 generating a unique link-local address on that link. Now, if the 1081 mobile node moves to a new access router, the PPP session gets torn 1082 down and new PPP session with the new mobile access gateway will be 1083 established and the mobile obtains a new link-local address. Now, 1084 even if the mobile is DNAv6 capable, as specified in the DNAv6 1085 specification [draft-ietf-dna-protocol-03], the mobile node always 1086 configures a new link-local address when ever it moves to a new link. 1088 However, if the link between the mobile node and the mobile access 1089 gateway is a shared link and if a DNAv6 capable mobile node moves 1090 from one access link to the other, the mobile node may not detect a 1091 link change due to the optimizations from DNAv6 and hence there is a 1092 possibility of the link-local address collision on the connected 1093 access link, One of the work around for this issue to the set 1094 following flag on the mobile node, DNASameLinkDADFlag to TRUE and 1095 that will force the mobile node to redo DAD operation even when DNAv6 1096 detects no link change. 1098 The global address or the MN-HoA uniqueness is assured as the 1099 uniqueness is established by the local mobility anchor before 1100 accepting a proxy binding update for a mobile node. This is further 1101 assured with the currently supported per-mn-prefix model, as there 1102 are two mobile nodes that share the same home network prefix. 1103 Further, if the address configuration is based on statefull address 1104 configuration using DHCP, the DHCP server will ensure the uniqueness. 1106 6.6. Tunnel Management 1108 In the traditional Mobile IPv6 model, there is a separate tunnel from 1109 the local mobility anchor to every mobile node that has a binding 1110 cache entry. The one end-point of these tunnels is the respective 1111 mobile node's care-of address and that is unique to that mobile node. 1112 In the case of Proxy Mobile IPv6, the care-of address or the tunnel 1113 end-point is the address of the mobile access gateway and there could 1114 be multiple mobile nodes attached to the same mobile access gateway 1115 and hence the tunnel is a shared tunnel serving multiple mobile 1116 nodes. This is identical to the Mobile IPv4 model [RFC-3344], where 1117 a tunnel between the foreign agent and the home agent is shared by 1118 many visiting mobile nodes and hence the tunnel management needs to 1119 be on a global basis and not be dependent on a specific mobile node's 1120 binding. 1122 The life of the Proxy Mobile IPv6 tunnel should not be based on a 1123 single binding cache entry. The tunnel may get created as part of 1124 creating a mobility state for a mobile node and later the same tunnel 1125 may be associated with other mobile nodes. So, the tearing down 1126 logic of the tunnel must be based on the number of visitors over that 1127 tunnel. Implementations are free to pre-establish tunnels between 1128 every local mobility anchor and every mobile access gateway in a 1129 proxy mobile IPv6 domain and with out having to create and destroy 1130 the tunnels on a need basis. 1132 6.7. Routing Considerations 1134 This section describes how the data traffic to/from the mobile node 1135 is handled at the mobile access gateway. The following entries 1136 explains the routing state for the mobile node on the mobile access 1137 gateway. 1139 Mobile Node's IPv6 traffic: 1140 =========================== 1141 For all traffic from the source address MN-HoA to destination 0::/0 1142 route via tunnel0, next-hop LMAA. 1144 MN-HoA::/64 is reachable via the directly connected interface. 1146 tunnel0: 1147 ======== 1148 Source: Proxy-CoA 1149 Destination: LMAA 1150 Tunnel Payload: IPv6 1151 Tunnel Transport: IPv6 1153 When the mobile access gateway receives any packets from the mobile 1154 node to any destination, the packet will be forwarded to the local 1155 mobility anchor through the bi-directional tunnel established between 1156 itself and the mobile's local mobility anchor. However, the packets 1157 that are sent with link-local source address are not forwarded. 1159 If the tunnel between the mobile access gateway and local mobility 1160 anchor is an IPv6 tunnel i.e. if the registered care-of address is an 1161 IPv6 Proxy-CoA, any IPv6 packet from the mobile node with the source 1162 MN-HoA, will be encapsulated in an IPv6 packet, IPv6/IPv6 mode and 1163 will be carried as an IPv6 packet. And any IPv4 packet from the 1164 mobile node with the source IPv4 Mobile-HoA, will be encapsulated in 1165 an IPv6 packet, IPv4/IPv6 mode, and will be carried as an IPv6 1166 packet. 1168 All the packets that the mobile access gateway receives from the 1169 tunnel, after removing the tunnel encapsulation, will forward it to 1170 the mobile node on the connected interface. 1172 6.8. Interaction with DHCP Relay Agent 1174 If Statefull Address Configuration using DHCP is supported on the 1175 link on which the mobile node is attached, the DHCP relay agent [RFC- 1176 3315] needs to be configured on the access router. When the mobile 1177 node sends a DHCPv6 Request message, the relay agent function on the 1178 access router must set the link-address field in the DHCPv6 message 1179 to the mobile node's home network prefix, so as to provide a prefix 1180 hint to the DHCP Server. On a point-to-point link, this is just a 1181 normal DHCP relay agent configuration. However, on the shared links 1182 supporting multiple mobile nodes with different home prefixes, there 1183 is some interaction required between the relay agent and the mobile 1184 access gateway, for setting the link-address field to the requesting 1185 mobile node's home network prefix. 1187 6.9. Mobile Node Detachment Detection and Resource Cleanup 1189 Before sending a Proxy Binding Update message to the local mobility 1190 anchor for extending the lifetime of a currently existing binding of 1191 a mobile node, the mobile access gateway MUST make sure the mobile 1192 node is still attached to the connected link by using some reliable 1193 method. If the mobile access gateway cannot predictably detect the 1194 presence of the mobile node on the connected link, it MUST NOT 1195 attempt to extend the registration lifetime of the mobile node. 1196 Further, in such scenario, the mobile access gateway MUST terminate 1197 the binding of the mobile node by sending a Proxy Binding Update 1198 message to the mobile node's local mobility anchor with lifetime 1199 value set to 0. It MUST also remove any local state such as binding 1200 update list entry that was created for that mobile node. 1202 The specific detection mechanism of the loss of a visiting mobile 1203 node on the connected link is specific to the access link between the 1204 mobile node and the mobile access gateway and is outside the scope of 1205 this document. Typically, there are various link-layer specific 1206 events specific to each access technology that the mobile access 1207 gateway can depend on for detecting the node loss. In general, the 1208 mobile access gateway can depend on one or more of the following 1209 methods for the detection presence of the mobile node on the 1210 connected link: 1212 o Link-layer event specific to the access technology 1214 o PPP Session termination event on point-to-point link types 1216 o IPv6 Neighbor Unreachability Detection event from IPv6 stack 1218 o Notification event from the local mobility anchor 1220 o Absence of data traffic from the mobile node on the link for a 1221 certain duration of time 1223 6.10. Coexistence with Mobile Nodes using Host-based Mobility 1225 In some operating environments, network operators may want to 1226 provision the access link attached to the mobile access gateway to 1227 offer network-based mobility service only to some nodes and enable 1228 normal IP access support for some other nodes on that link. This 1229 specification supports access links with such mixture of nodes. The 1230 network has the control on when to enable the mobile node with the 1231 network mobility service. 1233 Upon obtaining the mobile node's profile after a successful access 1234 authentication and after a policy consideration, the mobile access 1235 gateway MUST determine if the network based mobility service should 1236 be offered to that mobile node. If the mobile node is entitled for 1237 such service, then the network should ensure the mobile node believes 1238 it is on its home link, as explained in various sections of this 1239 document. 1241 If the mobile node is not entitled for the network based mobility 1242 service, as determined from the policy, the mobile access gateway 1243 MUST ensure the mobile node can obtain an IPv6 address using normal 1244 IPv6 address configuration mechanisms. The obtained address should 1245 be from a local visitor network prefix. In other words the mobile 1246 node should be able to operate as a traditional mobile node roaming 1247 in a visitor network and with the ability to obtain an address from 1248 the local visitor network prefix hosted on that link. This 1249 essentially ensures, the proxy mobile IPv6 protocol will not impact 1250 the behavior of a mobile node that is using host-based mobility, as 1251 per [RFC-3775]. 1253 If the stateless address configuration mode is supported on that 1254 link, the prefix information option in the router advertisements 1255 should contain local visitor network prefix. If statefull address 1256 configuration mode is enforced on the link and if DHCP is in used, 1257 the mobile node should be able to obtain the IPv6 care-of address 1258 from the local visitor network prefix. 1260 If the link between the mobile access gateway and the mobile node is 1261 a shared link, the Router Advertisement has to unicasted to the 1262 mobile node with the destination address in the layer-2 header set to 1263 the mobile's MAC address and the destination address in the IPv6 1264 header set to the all-nodes multicast address. 1266 6.11. Mobile Access Gateway Operation Summary 1268 o After detecting a new mobile node on its access link and after the 1269 successful access authentication and authorization of the mobile 1270 node, the mobile access gateway MUST be able to able to access the 1271 mobile node's profile. This may be downloaded from the local/ 1272 network policy store using MN-Identity or may be obtained as part 1273 of a context transfer procedure. The mobile node's profile at the 1274 minimum MUST have the mobile node's local mobility anchor address 1275 and the MN-Identity. Optionally, it may have the mobile node's 1276 home network prefix and other configuration parameters. 1278 o The mobile access gateway MAY use one or more ways to detect the 1279 attachment of a mobile node on to the link. The techniques can be 1280 specific to the access technology or can be other generic events 1281 as mentioned in the above sections. 1283 o If the network determines that the mobile node will not be offered 1284 the network-based mobility service, the mobile access gateway MUST 1285 ensure that the Router Advertisements it sends will not contain 1286 the mobile node's home prefix, but will be the hosted on-link 1287 prefix. Also, if the mobile node attempts to obtain an IPv6 1288 address, the mobile access gateway or the DHCP relay agent on the 1289 link MUST ensure that the prefix hint that gets added to the DHCP 1290 message will be of the local hosted prefix. 1292 o `The mobile access gateway on receiving a Router Solicitation 1293 message from a mobile node MUST send a Router Advertisement 1294 message containing the mobile node's home network prefix. 1296 o The mobile access gateway MUST send the periodic Router 1297 Advertisement messages, as per the ND specification [RFC-2461], 1298 advertising the mobile node's home network prefix on the access 1299 link. 1301 o If the link between the mobile node and the mobile access gateway 1302 is a shared-link, then the Router Advertisement MUST be unicasted 1303 to the mobile node by setting the destination address in the link- 1304 layer header to the mobile node's MAC address and with the 1305 destination address in the IPv6 header set to the all-nodes 1306 multicast address. 1308 o If the mobile node uses DHCP for address configuration, the mobile 1309 access gateway or specifically the DHCP relay agent on the link 1310 MUST ensure the DHCPv4/v6 packets are properly tagged with the 1311 sending mobile node's MN-HoA, as the prefix hint. 1313 o The Proxy Binding Update message that the mobile access gateway 1314 sends to the local mobility anchor, MUST have the configured IPv6 1315 address of the egress interface. The Proxy Binding Update message 1316 MUST have the NAI option identifying the mobile node, home network 1317 prefix option and optionally the time stamp option. If the home 1318 network prefix option is set to value 0, the local mobility anchor 1319 will assign the home network prefix and will return them in the 1320 Proxy Binding Acknowledgment. This message MUST be protected by 1321 using IPSec security association created between the mobile access 1322 gateway and local mobility anchor. 1324 o After receiving a Proxy Binding Acknowledgment with the status 1325 code indicating the acceptance of the Binding Update, the mobile 1326 access gateway MUST setup a tunnel to the mobile node's local 1327 mobility anchor, as explained in the above sections, if there is 1328 exists no tunnel. The mobile access gateway MUST also add a 1329 default route over the tunnel for all the traffic from the mobile 1330 node. 1332 o If the local mobility anchor denies the Proxy Binding Update 1333 request, the mobile access gateways MUST NOT advertise the mobile 1334 node's home prefix on the access link and there by denying 1335 mobility service to the mobile node. 1337 o Before attempting to extend binding lifetime of a mobile node, the 1338 mobile access gateway MUST make sure the mobile node is still 1339 attached to the connected link by using some reliable method. If 1340 the mobile access gateway cannot predictably detect the presence 1341 of the mobile node on the connected link, it MUST NOT attempt to 1342 extend the registration lifetime of the mobile node. Also, it 1343 MUST terminate the binding of the mobile node by sending a Proxy 1344 Binding Update message to the mobile node's local mobility anchor 1345 with lifetime value set to 0. 1347 o At any point, if the mobile access gateway detects that the mobile 1348 node has roamed away from its access link, it MUST send a Proxy 1349 Binding Update to the local mobility anchor with the lifetime 1350 value set to 0 and it must also remove the default route over the 1351 tunnel for that mobile and also remove the Binding Update list 1352 entry and any other local state created for that mobile node. 1354 7. Mobile Node Operation 1356 The Network-based mobility scheme defined in this document, allows a 1357 mobile node to obtain IP mobility within the proxy mobile IPv6 1358 domain, with out requiring the mobile node to involve in any mobility 1359 management. 1361 When a mobile node enters a proxy mobile IPv6 domain and attached to 1362 an access link, the network identifies the mobile node as part of the 1363 access authentication and establishes an identity for the mobile 1364 node. This identity has a binding to a cryptographic state and 1365 potentially associating the mobile node's link-layer address of the 1366 attached interface. The specifics on how this is achieved is beyond 1367 the scope of this document and is very much specific to the access 1368 technology and depends on the applied security protocols in place. 1369 For all practical purposes, this document assumes that the mobile 1370 node's access to the network is secure. 1372 Once the mobile node enters a Proxy Mobile IPv6 domain and attaches 1373 to an access network, the network identifies the mobile as part of 1374 the access authentication procedure and ensures the mobile using any 1375 of the address configuration mechanisms permitted by the network for 1376 that mobile, will be able to obtain an address and move anywhere in 1377 that managed domain. From the perspective of the mobile, the entire 1378 Proxy Mobile IPv6 domain appears as a single link, the network 1379 ensures the mobile believes it is always on the same link. 1381 The mobile node can be operating in an IPv4-only mode, IPv6-only mode 1382 or in dual IPv4/IPv6 mode. Typically, the configured policy in the 1383 network determines the type of home address(es) i.e. MN-HoA, IPv4 1384 MN-HoA or both, that the network mobility is supported for. If the 1385 configured policy for a mobile node is for IPv6-only home address 1386 mobility, the mobile node will be able to obtain its MN-HoA, any 1387 where in that proxy mobile IPv6 domain and if policy allows only 1388 IPv4-only home address mobility, the mobile node will be able to 1389 obtain its IPv4 MN-HoA, any where in that domain. Similarly, if the 1390 policy permits both the IPv4 and IPv6 home address mobility, the 1391 mobile node will be able to obtain its MN-HoA and IPv4 MN-HoA and 1392 move anywhere in the network. However, if the mobile node is 1393 configured for IPv6-only mobility and if the mobile node attempts to 1394 obtain an IPv4 address configuration via DHCP mechanism, the obtained 1395 address configuration will not have any mobility properties, i.e. the 1396 obtained address will be from a local prefix and not from a prefix 1397 that is topologically anchored at the local mobility anchor and hence 1398 the mobile will loose that address as it moves to a different link. 1399 The specifics on how this is achieved is the operational logic of the 1400 mobile access gateway on the access link. 1402 7.1. Booting up in a Proxy Mobile IPv6 Domain 1404 When a mobile node moves into a proxy mobile IPv6 domain and attaches 1405 to an access link, the mobile node will present its identity, MN- 1406 Identity, to the network as part of the access authentication 1407 procedure. Once the authentication procedure is complete and the 1408 mobile node is authorized to access the network, the network or 1409 specifically the mobile access gateway on the access link will have 1410 the mobile node's profile and so it would know the mobile node's home 1411 network prefix and the permitted address configuration modes. The 1412 mobile node's home network prefix may also be dynamically assigned by 1413 the mobile node's local mobility anchor and the same may be learnt by 1414 the mobile access gateway. 1416 If the mobile node is IPv6 enabled, on attaching to the link and 1417 after access authentication, the mobile node typically would send a 1418 Router Solicitation message. The mobile access gateway on the 1419 attached link will respond to the Router Solicitation message with a 1420 Router Advertisement. The Router Advertisement will have the mobile 1421 node's home network prefix, default-router address and other address 1422 configuration parameters. The address configuration parameters such 1423 as Managed Address Configuration, Statefull Configuration flag values 1424 will typically be consistent through out that domain for that mobile 1425 node. 1427 If the Router Advertisement has the Managed Address Configuration 1428 flag set, the mobile node, as it would normally do, will send a 1429 DHCPv6 Request and the mobile access gateway on that access link will 1430 ensure, the mobile node node gets the MN-HoA as a lease from the DHCP 1431 server. 1433 If the Router Advertisement does not have the Managed Address 1434 Configuration flag set and if the mobile node is allowed to use an 1435 autoconfigured address, the mobile node will generate an interface 1436 identifier, as per the Autoconf specification [RFC-2462] or using 1437 privacy extensions as specified in Privacy Extensions specification 1438 [RFC-3041]. 1440 If the mobile node is IPv4 enabled or IPv4-only enabled, the mobile 1441 node after the access authentication, will be able to obtain the IPv4 1442 address configuration for the connected interface by using DHCPv4. 1444 Once the address configuration is complete, the mobile node will have 1445 the MN-HoA, IPv4 MN-HoA or both, that it can continue to use as long 1446 as it is with in the scope of that proxy mobile IPv6 domain. 1448 7.2. Roaming in the Proxy Mobile IPv6 Network 1450 After booting in the Proxy Mobile IPv6 domain and obtaining the 1451 address configuration, the mobile node as it roams in the network 1452 between access links, will always detect its home network prefix on 1453 the link, as long as the attached access network is in the scope of 1454 that proxy mobile IPv6 domain. The mobile node can continue to use 1455 its IPv4/IPv6 MN-HoA for sending and receiving packets. If the 1456 mobile node uses DHCP for address configuration, it will always be 1457 able to obtain its MN-HoA using DHCP. However, the mobile node will 1458 always detect a new default-router on each connected link, but still 1459 advertising the mobile node's home prefix as the on-link prefix and 1460 with the other configuration parameters consistent with the link 1461 properties as before. 1463 7.3. IPv6 Host Protocol Parameters 1465 This specification assumes the mobile node to be a normal IPv6 node, 1466 with its protocol operation consistent with the base IPv6 1467 specification [RFC-2460]. All aspects of Neighbor Discovery 1468 Protocol, including Router Discovery, Neighbor Discovery, Address 1469 Configuration procedures will just remain consistent with the base 1470 IPv6 Neighbor Discovery Specification [RFC-2461]. However, this 1471 specification recommends that the following IPv6 operating parameters 1472 on the mobile node be adjusted to the below recommended values for 1473 protocol efficiency and for achieving faster hand-offs. 1475 Lower Default-Router List Cache Time-out: 1477 As per the base IPv6 specification [RFC-2460], each IPv6 host will 1478 maintain certain host data structures including a Default-Router 1479 list. This is the list of on-link routers that have sent Router 1480 Advertisement messages and are eligible to be default routers on that 1481 link. The Router Lifetime field in the received Router Advertisement 1482 defines the life of this entry. 1484 In the Proxy Mobile IPv6 scenario, when the mobile node moves from 1485 one link to another, the received Router Advertisement messages 1486 advertising the mobile's home network prefix will be from a different 1487 link-local address and thus making the mobile node believe that there 1488 is a new default-router on the link. It is important that the mobile 1489 node uses the newly learnt default-router as supposed to the 1490 previously learnt default-router. The mobile node must update its 1491 default-router list with the new default router entry and must age 1492 out the previously learnt default router entry from its cache, just 1493 as specified in Section 6.3.5 of the base IPv6 ND specification [RFC- 1494 2461]. This action is critical for minimizing packet losses during a 1495 hand off switch 1497 On detecting a reachability problem, the mobile node will certainly 1498 detect the neighbor or the default-router unreachability by 1499 performing a Neighbor Unreachability Detection procedure, but it is 1500 important that the mobile node times out the previous default router 1501 entry at the earliest. If a given IPv6 host implementation has the 1502 provision to adjust these flush timers, still conforming to the base 1503 IPv6 ND specification, it is desirable to keep the flush-timers to 1504 suit the above consideration. 1506 However, if the mobile access gateway has the ability to with draw 1507 the previous default-router entry, by multicasting a Router 1508 Advertisement using the link-local address that of the previous 1509 mobility proxy agent and with the Router Lifetime field set to value 1510 0, then it is possible to force the flush out of the Previous 1511 Default-Router entry from the mobile node's cache. This certainly 1512 requires some context-transfer mechanisms in place for notifying the 1513 link-local address of the default-router on the previous link to the 1514 mobile access gateway on the new link. 1516 There are other solutions possible for this problem, including the 1517 assignment of a unique link-local address for all the access routers 1518 in the Proxy Mobile IPv6 Network. In either case, this is an 1519 implementation choice and has no bearing on the protocol 1520 interoperability. Implementations are free to adopt the best 1521 approach that suits their target deployments. 1523 8. Message Formats 1525 This section defines extensions to the Mobile IPv6 [RFC-3775] 1526 protocol messages. 1528 8.1. Proxy Binding Update 1530 0 1 2 3 1531 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 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Sequence # | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 |A|H|L|K|M|R|P| Reserved | Lifetime | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | | 1538 | | 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 Figure 6: Proxy Binding Update Message 1543 A Binding Update message that is sent by mobile access gateway is 1544 referred to as the Proxy Binding Update message. 1546 Proxy Registration Flag (P) 1548 The Proxy Registration Flag is set to indicate to the local mobility 1549 anchor that the Binding Update is from a mobile access gateway acting 1550 as a proxy mobility agent. The flag MUST be set to the value of 1 1551 for proxy registrations and MUST be set to 0 for direct registration 1552 send my a mobile node using host-base mobility. 1554 For descriptions of other fields present in this message, refer to 1555 the section 6.1.7 of Mobile IPv6 specification [RFC3775]. 1557 8.2. Proxy Binding Acknowledgment 1558 0 1 2 3 1559 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 1560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1561 | Status |K|R|P|Reserved | 1562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1563 | Sequence # | Lifetime | 1564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1565 | | 1566 | | 1567 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1569 Figure 7: Proxy Binding Acknowledgment Message 1571 Proxy Registration Flag (P) 1573 A new flag (P) is included in the Binding Acknowledgement message to 1574 indicate that the local mobility anchor Agent that processed the 1575 corresponding Binding Update supports Proxy Registrations. The flag 1576 is set only if the corresponding Proxy Binding Update had the Proxy 1577 Registration Flag (P) set to 1. The rest of the Binding 1578 Acknowledgement format remains the same, as defined in [RFC-3775]. 1580 For descriptions of other fields present in this message, refer to 1581 the Mobile IPv6 base specificatoin [RFC-3775]. 1583 A Binding Acknowledgment message that is sent by the mobile access 1584 gateway is also referred to as "Proxy Binding Acknowledgement". 1586 8.3. Home Network Prefix Option 1588 A new option, Home Network Prefix Option is defined for using it in 1589 the Proxy Binding Update and Acknowledgment messages exchanged 1590 between the local mobility anchor to the mobile access gateway. This 1591 option can be used for exchanging the mobile node's home prefix and 1592 home address information. 1594 The home network prefix Option has an alignment requirement of 8n+4. 1595 Its format is as follows: 1597 0 1 2 3 1598 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 1599 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1600 | Type | Length | Reserved | Prefix Length | 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 | | 1603 + + 1604 | | 1605 + Home Network Prefix + 1606 | | 1607 + + 1608 | | 1609 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1611 Type 1612 1614 Length 1616 8-bit unsigned integer indicating the length in octets of 1617 the option, excluding the type and length fields. This field 1618 MUST be set to 18. 1620 Reserved 1622 This field is unused for now. The value MUST be initialized 1623 to 0 by the sender and MUST be ignored by the receiver. 1625 Prefix Length 1627 8-bit unsigned integer indicating the prefix length of the 1628 IPv6 prefix contained in the option. If the prefix length 1629 is set to the value 128, indicates the presence of the 1630 mobile node's 128-bit home address. 1632 Home Network Prefix 1634 A sixteen-byte field containing the Home Network Prefix 1636 Figure 8: Home Network Prefix Option 1638 8.4. Time Stamp Option 1640 A new option, Time Stamp Option is defined for use in Proxy Binding 1641 Update and Acknowledgement messages. This option MUST be present in 1642 all Proxy Binding Update and Acknowledgement messages. 1644 0 1 2 3 1645 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 1646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1647 | Option Type | Option Length | 1648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1649 | | 1650 + Timestamp + 1651 | | 1652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1654 Type 1655 1657 Length 1659 8-bit unsigned integer indicating the length in octets of 1660 the option, excluding the type and length fields. This field 1661 MUST be set to 18. 1663 Timestamp 1665 64-bit time stamp 1667 Figure 9: Time Stamp Option 1669 8.5. Status Codes 1671 This document defines the following new Binding Acknowledgement 1672 status values: 1674 145: Proxy Registration not supported by the local mobility anchor 1676 146: Proxy Registrations from this mobile access gateway not allowed 1678 147: No home address for this NAI is configured and the Home Network 1679 Prefix Option not present in the Binding Update. 1681 148: Invalid Time Stamp Option in the Binding Update 1683 Status values less than 128 indicate that the Binding Update was 1684 processed successfully by the receiving nodes. Values greater than 1685 128 indicate that the Binding Update was rejected by the local 1686 mobility anchor. 1688 The value allocation for this usage needs to be approved by the IANA 1689 and must be updated in the IANA registry. 1691 9. IANA Considerations 1693 This document defines a new Mobility Header Option, the Mobile Home 1694 Network Prefix Option. This option is described in Section 8.3. The 1695 Type value for this option needs to be assigned from the same 1696 numbering space as allocated for the other mobility options defined 1697 in [RFC-3775]. 1699 This document defines a new Mobility Header Option, the Time Stamp 1700 Option. This option is described in Section 8.4. The type value for 1701 this option needs to be assigned from the same numbering space as 1702 allocated for the other mobility options defined in [RFC-3775]. 1704 This document also defines new Binding Acknowledgement status values 1705 as described in Section 8.5. The status values MUST be assigned from 1706 the same space used for Binding Acknowledgement status values in 1707 [RFC-3775]. 1709 10. Security Considerations 1711 The security threats against any general network-based mobility 1712 management protocol are covered in the document, Security Threats to 1713 Network-Based Localized Mobility Management 1714 [draft-ietf-netlmm-threats-04.txt]. This section analyses those 1715 vulnerabilities in the context of Proxy Mobile IPv6 protocol and 1716 covers all aspects around those identified vulnerabilities. 1718 A compromised mobile access gateway can send Proxy Binding Update 1719 requests for mobile nodes that are not attached to its access link. 1720 This threat is similar to an attack on a typical routing protocol or 1721 equivalent to the compromise of a on-path router and hence this 1722 threat exists in the network today and this specification does not 1723 make this vulnerability any worse than what it is. However, to 1724 eliminate this attack, the local mobility anchor can ensure that the 1725 mobile node is attached to the access link of the requesting mobile 1726 access gateway. This can be achieved using out of band mechanisms, 1727 such as from the mobile node's access authentication to the network 1728 and the specifics of how that is achieved is beyond the scope of this 1729 document. 1731 This document does not cover the security requirements for 1732 authorizing the mobile node for the use of the access link. It is 1733 assumed that there are proper Layer-2 based authentication 1734 procedures, such as EAP, in place and will ensure the mobile node is 1735 properly identified and authorized before permitting it to access the 1736 network. It is further assumed that the same security mechanism will 1737 ensure the mobile session is not hijacked by malicious nodes on the 1738 access link. 1740 This specification requires that all the signaling messages exchanged 1741 between the mobile access gateway and the local mobility anchor MUST 1742 be authenticated by IPsec [RFC-4301]. The use of IPsec to protect 1743 Mobile IPv6 signaling messages is described in detail in the HA-MN 1744 IPsec specification [RFC-3776] and the extension of that security 1745 model to Proxy Mobile IPv6 is covered in Section 4.0 of this 1746 document. 1748 As described in the base Mobile IPv6 specification [RFC-3775], 1749 Section 5.1 both the mobile client (in this case, its the mobile 1750 access gateway) and the local mobility anchor MUST support and SHOULD 1751 use the Encapsulating Security Payload (ESP) header in transport mode 1752 and MUST use a non-NULL payload authentication algorithm to provide 1753 data origin authentication, data integrity and optional anti-replay 1754 protection. 1756 The proxy solution allows one device creating a routing state for 1757 some other device at the local mobility anchor. It is important that 1758 the local mobility anchor has proper authorization services in place 1759 to ensure a given mobile access gateway is permitted to be a proxy 1760 for a specific mobile node. If proper security checks are not in 1761 place, a malicious node may be able to hijack a session or may do a 1762 denial-of-service attacks. 1764 11. Acknowledgements 1766 The authors would like to specially thank Julien Laganier, Christian 1767 Vogt, Pete McCann, Brian Haley and Ahmad Muhanna for their thorough 1768 review of this document. 1770 The authors would also like to thank the Gerardo Giaretta, Kilian 1771 Weniger, Alex Petrescu, Mohamed Khalil, Fred Templing, Nishida 1772 Katsutoshi, James Kempf, Vidya Narayanan, Henrik Levkowetz, Phil 1773 Roberts, Jari Arkko, Ashutosh Dutta, Hesham Soliman, Behcet Sarikaya, 1774 George Tsirtsis and many others for their passionate discussions in 1775 the working group mailing list on the topic of localized mobility 1776 management solutions. These discussions stimulated much of the 1777 thinking and shaped the draft to the current form. We acknowledge 1778 that ! 1780 The authors would also like to thank Ole Troan, Akiko Hattori, Perviz 1781 Yegani, Mark Grayson, Michael Hammer, Vojislav Vucetic, Jay Iyer and 1782 Tim Stammers for their input on this document. 1784 12. References 1786 12.1. Normative References 1788 [RFC-1305] Mills, D., "Network Time Protocol (Version 3) 1789 Specification, Implementation", RFC 1305, March 1992. 1791 [RFC-2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1792 (IPv6) Specification", RFC 2460, December 1998. 1794 [RFC-2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1795 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. 1797 [RFC-2462] Thompson, S., Narten, T., "IPv6 Stateless Address 1798 Autoconfiguration", RFC 2462, December 1998. 1800 [RFC-2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1801 IPv6 Specification", RFC 2473, December 1998. 1803 [RFC-3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C. and 1804 M.Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", 1805 RFC 3315, July 2003. 1807 [RFC-3775] Johnson, D., Perkins, C., Arkko, J., "Mobility Support in 1808 IPv6", RFC 3775, June 2004. 1810 [RFC-3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1811 Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", 1812 RFC 3776, June 2004. 1814 [RFC-4283] Patel, A., Leung, K., Khalil, M., Akhtar, H., and K. 1815 Chowdhury, "Mobile Node Identifier Option for Mobile IPv6", RFC 4283, 1816 November 2005. 1818 [RFC-4301] Kent, S. and Atkinson, R., "Security Architecture for the 1819 Internet Protocol", RFC 4301, December 2005. 1821 [RFC-4303] Kent, S. "IP Encapsulating Security Protocol (ESP)", RFC 1822 4303, December 2005. 1824 [RFC-4306] Kaufman, C, et al, "Internet Key Exchange (IKEv2) 1825 Protocol", RFC 4306, December 2005. 1827 [draft-ietf-netlmm-nohost-req-05.txt] Kempf, J., Leung, K., Roberts, 1828 P., Nishida, K., Giaretta, G., Liebsch, M., "Goals for Network-based 1829 Localized Mobility Management", October 2006. 1831 [draft-ietf-netlmm-nohost-ps-05.txt] Kempf, J., Leung, K., Roberts, 1832 P., Nishida, K., Giaretta, G., Liebsch, M., "Problem Statement for 1833 Network-based Localized Mobility Management", September 2006. 1835 [draft-ietf-netlmm-threats-04.txt] Vogt, C., Kempf, J., "Security 1836 Threats to Network-Based Localized Mobility Management", September 1837 2006. 1839 [draft-ietf-mip6-nemo-v4traversal-03.txt] Soliman, H. et al, "Mobile 1840 IPv6 support for dual stack Hosts and Routers (DSMIPv6)", October 1841 2006. 1843 12.2. Informative References 1845 [RFC-1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1846 (IPCP)", RFC 1332, May 1992. 1848 [RFC-1661] Simpson, W., Ed., "The Point-To-Point Protocol (PPP)", STD 1849 51, RFC 1661, July 1994. 1851 [RFC-2472] Haskin, D. and Allen, E., "IP version 6 over PPP", RFC 1852 2472, December 1998. 1854 [RFC-2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1855 IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 1857 [RFC-3041] Narten, T. and Draves, R., "Privacy Extensions for 1858 Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001. 1860 [RFC-3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1861 August 2002. 1863 [RFC-3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor 1864 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 1866 [draft-iab-multilink-subnet-issues-03.txt] Thaler, D., "Multilink 1867 Subnet Issues", January 2006. 1869 [draft-ietf-dna-protocol-03] Kempf, J., et al "Detecting Network 1870 Attachment in IPv6 Networks (DNAv6)", draft-ietf-dna-protocol-03, 1871 October 2006. 1873 [draft-ietf-mip6-ikev2-ipsec-08] Devarapalli, V. and Dupont, F., 1874 "Mobile IPv6 Operation with IKEv2 and the revised IPsec 1875 Architecture", December 2006. 1877 Appendix A. Proxy Mobile IPv6 interactions with AAA Infrastructure 1879 Every mobile node that roams in a proxy Mobile IPv6 domain, would 1880 typically be identified by an identifier, MN-Identifier, and that 1881 identifier will have an associated policy profile that identifies the 1882 mobile node's home network prefix, permitted address configuration 1883 modes, roaming policy and other parameters that are essential for 1884 providing network-based mobility service. This information is 1885 typically configured in AAA. It is possible the home network prefix 1886 is dynamically allocated for the mobile node when it boots up for the 1887 first time in the network, or it could be a statically configured 1888 value on per mobile node basis. However, for all practical purposes, 1889 the network entities in the proxy Mobile IPv6 domain, while serving a 1890 mobile node will have access to this profile and these entities can 1891 query this information using RADIUS/DIAMETER protocols. 1893 Appendix B. Supporting Shared-Prefix Model using DHCPv6 1895 For supporting shared-prefix model, i.e, if multiple mobile nodes are 1896 configured with a common IPv6 network prefix, as in Mobile IPv6 1897 specification, it is possible to support that configuration under the 1898 following guidelines: 1900 The mobile node is allowed to use statefull address configuration 1901 using DHCPv6 for obtaining its address configuration. The mobile 1902 nodes is not allowed to use any of the stateless autoconfiguration 1903 techniques. The permitted address configuration models for the 1904 mobile node on the access link can be enforced by the mobile access 1905 gateway by setting the relevant flags in the Router Advertisements, 1906 as per ND Specification, [RFC-2461] 1908 The Home Network Prefix Option that is sent by the mobile access 1909 gateway in the Proxy Binding Update message, must contain the 128-bit 1910 host address that the mobile node obtained via DHCPv6. 1912 Routing state at the mobile access gateway: 1914 For all IPv6 traffic from the source MN-HoA::/128 to destination 1915 0::/0, route via tunnel0, next-hop LMAA, where tunnel0 is the MAG to 1916 LMA tunnel. 1918 Routing state at the local mobility anchor: 1920 For all IPv6 traffic to destination MN-HoA::/128, route via tunnel0, 1921 next-hop Proxy-CoA, where tunnel0 is the LMA to MAG tunnel. 1923 Authors' Addresses 1925 Sri Gundavelli 1926 Cisco 1927 170 West Tasman Drive 1928 San Jose, CA 95134 1929 USA 1931 Email: sgundave@cisco.com 1933 Kent Leung 1934 Cisco 1935 170 West Tasman Drive 1936 San Jose, CA 95134 1937 USA 1939 Email: kleung@cisco.com 1940 Vijay Devarapalli 1941 Azaire Networks 1942 4800 Great America Pkwy 1943 Santa Clara, CA 95054 1944 USA 1946 Email: vijay.devarapalli@azairenet.com 1948 Kuntal Chowdhury 1949 Starent Networks 1950 30 International Place 1951 Tewksbury, MA 1953 Email: kchowdhury@starentnetworks.com 1955 Basavaraj Patil 1956 Nokia Siemens Networks 1957 6000 Connection Drive 1958 Irving, TX 75039 1959 USA 1961 Email: basavaraj.patil@nsn.com 1963 Full Copyright Statement 1965 Copyright (C) The IETF Trust (2007). 1967 This document is subject to the rights, licenses and restrictions 1968 contained in BCP 78, and except as set forth therein, the authors 1969 retain all their rights. 1971 This document and the information contained herein are provided on an 1972 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1973 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1974 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1975 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1976 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1977 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1979 Intellectual Property 1981 The IETF takes no position regarding the validity or scope of any 1982 Intellectual Property Rights or other rights that might be claimed to 1983 pertain to the implementation or use of the technology described in 1984 this document or the extent to which any license under such rights 1985 might or might not be available; nor does it represent that it has 1986 made any independent effort to identify any such rights. Information 1987 on the procedures with respect to rights in RFC documents can be 1988 found in BCP 78 and BCP 79. 1990 Copies of IPR disclosures made to the IETF Secretariat and any 1991 assurances of licenses to be made available, or the result of an 1992 attempt made to obtain a general license or permission for the use of 1993 such proprietary rights by implementers or users of this 1994 specification can be obtained from the IETF on-line IPR repository at 1995 http://www.ietf.org/ipr. 1997 The IETF invites any interested party to bring to its attention any 1998 copyrights, patents or patent applications, or other proprietary 1999 rights that may cover technology that may be required to implement 2000 this standard. Please address the information to the IETF at 2001 ietf-ipr@ietf.org. 2003 Acknowledgment 2005 Funding for the RFC Editor function is provided by the IETF 2006 Administrative Support Activity (IASA).