idnits 2.17.1 draft-leung-mip4-proxy-mode-10.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1816. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1827. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1840. 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 document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: A PMA receiving these error codes SHOULD not retry sending proxy Mobile IPv4 messages to the HA that sent replies with these error codes. -- 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 (Nov 28, 2008) is 5621 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 1157 == Unused Reference: 'RFC2484' is defined on line 1719, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-mip4-dsmipv4-06 -- No information found for draft-yegani-gre-key-extensions - is the name correct? == Outdated reference: A later version (-04) exists of draft-chakrabarti-mip4-mcbc-02 ** Obsolete normative reference: RFC 1305 (Obsoleted by RFC 5905) ** Obsolete normative reference: RFC 1548 (Obsoleted by RFC 1661) ** Obsolete normative reference: RFC 3344 (Obsoleted by RFC 5944) ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP4 K. Leung 3 Internet-Draft G. Dommety 4 Intended status: Informational P. Yegani 5 Expires: June 1, 2009 Cisco Systems 6 K. Chowdhury 7 Starent Networks 8 Nov 28, 2008 10 WiMAX Forum/3GPP2 Proxy Mobile IPv4 11 draft-leung-mip4-proxy-mode-10.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on June 1, 2009. 38 Abstract 40 Mobile IPv4 is a standard mobility protocol that enables IPv4 device 41 to move among networks while maintaining its IP address. The mobile 42 device has the Mobile IPv4 client function to signal its location to 43 the routing anchor, known as the Home Agent. However, there are many 44 IPv4 devices without such capability due to various reasons. This 45 document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on 46 having the Mobile IPv4 client function in a network entity to provide 47 mobility support for an unaltered and mobility-unaware IPv4 device. 48 This document also describes a particular application of PMIPv4 as 49 specified in the WiMAX Forum and another application that is to be 50 adopted in 3GPP2. 52 Table of Contents 54 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 2. Conventions used in this document . . . . . . . . . . . . . . 4 56 3. Benefits of Proxy Mobile IPv4 . . . . . . . . . . . . . . . . 6 57 4. Overview of Proxy Mobile IPv4 . . . . . . . . . . . . . . . . 8 58 4.1. Mobility Signaling for Mobile Device . . . . . . . . . . . 8 59 4.1.1. Proxy Registration during Initial Network 60 Attachment . . . . . . . . . . . . . . . . . . . . . . 9 61 4.1.2. Proxy Registration Renewal . . . . . . . . . . . . . . 11 62 4.1.3. Proxy Handover Support . . . . . . . . . . . . . . . . 12 63 4.1.4. Resource Cleanup . . . . . . . . . . . . . . . . . . . 14 64 4.2. Establishment of Bi-Directional Tunnel . . . . . . . . . . 14 65 4.2.1. Packet Forwarding . . . . . . . . . . . . . . . . . . 15 66 4.2.2. Broadcast and Multicast . . . . . . . . . . . . . . . 15 67 4.2.3. Forwarding Between Devices on same PMA . . . . . . . . 15 68 4.3. Security Association Between the PMA and the HA . . . . . 16 69 4.4. Registration Sequencing . . . . . . . . . . . . . . . . . 16 70 4.5. Mobile Device Interface Configuration . . . . . . . . . . 17 71 4.6. Dynamic HA Discovery . . . . . . . . . . . . . . . . . . . 17 72 5. Proxy Mobile IPv4 Extensions . . . . . . . . . . . . . . . . . 17 73 5.1. PMIPv4 Per-Node Authentication Method Extension . . . . . 17 74 5.2. Proxy Mobile IPv4 Interface ID Extension . . . . . . . . . 18 75 5.3. Proxy Mobile IPv4 Device ID Extension . . . . . . . . . . 19 76 5.4. Proxy Mobile IPv4 Subscriber ID Extension . . . . . . . . 20 77 5.5. PMIP Access Technology Type Extension . . . . . . . . . . 21 78 6. Appearance of Being at Home Network . . . . . . . . . . . . . 23 79 6.1. ARP Considerations . . . . . . . . . . . . . . . . . . . . 23 80 6.2. ICMP Considerations . . . . . . . . . . . . . . . . . . . 23 81 6.3. DHCP Considerations . . . . . . . . . . . . . . . . . . . 24 82 6.4. PPP IPCP Considerations . . . . . . . . . . . . . . . . . 25 83 6.5. Link-Local Multicast and Broadcast Considerations . . . . 25 84 7. Proxy Mobility Agent Operation . . . . . . . . . . . . . . . . 25 85 8. Home Agent Operation . . . . . . . . . . . . . . . . . . . . . 26 86 8.1. Processing Proxy Registration Requests . . . . . . . . . . 27 87 9. Mobile Device Operation . . . . . . . . . . . . . . . . . . . 27 88 9.1. Initial Network Access . . . . . . . . . . . . . . . . . . 28 89 9.2. Mobile Device Mobility . . . . . . . . . . . . . . . . . . 28 90 9.3. Sending and Receiving Packet . . . . . . . . . . . . . . . 28 91 10. Proxy Mobile IPv4 Use Case in WiMAX . . . . . . . . . . . . . 29 92 10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in 93 WiMAX . . . . . . . . . . . . . . . . . . . . . . . . . . 32 94 11. Proxy Mobile IPv4 Use Case in 3GPP2 . . . . . . . . . . . . . 34 95 11.1. HO considerations in 3GPP2 . . . . . . . . . . . . . . . . 36 96 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 97 12.1. Mobile IPv4 Extension Types . . . . . . . . . . . . . . . 39 98 12.2. Mobile IPv4 Error Codes . . . . . . . . . . . . . . . . . 39 99 13. Security Considerations . . . . . . . . . . . . . . . . . . . 39 100 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 101 15. References . . . . . . . . . . . . . . . . . . . . . . . . . . 40 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 103 Intellectual Property and Copyright Statements . . . . . . . . . . 43 105 1. Introduction 107 There are many IPv4 devices which do not have or cannot be enabled 108 with Mobile IPv4 [RFC3344] functionality. Yet, mobility for them is 109 essential. Proxy Mobile IPv4 provides mobility support without 110 "touching" these devices. The scheme is based on network entities 111 which perform the mobility management function for a mobile device. 112 The location of the device is signaled by the network element on the 113 access network (referred as the Proxy Mobility Agent) to inform the 114 network entitiy on the home network (referred as the Home Agent) 115 associated with the IPv4 address used by the device. Mobile IPv4 116 messaging is used by the PMA and HA, which correspond to the RFC 3344 117 entities Mobile Node (in proxy mode) and Home Agent, respectively. 119 These are some examples of Proxy Mobile IPv4: 121 1. A WLAN access point or cellular base station performs 122 registration with the Home Agent when a mobile device is 123 associated on the air-link. 125 2. An access router or Foreign Agent performs registration with the 126 Home Agent when a mobile device is detected on the network. 128 Mobile IPv4 is used by the network entities because the mobility 129 protocol has the functions needed to set up the route and tunneling 130 endpoints for the mobile device's IP address and to deliver 131 configuration parameters (e.g. DNS server addresses, default 132 gateway) for enabling the mobile device's IP stack. When Mobile IPv4 133 is used in this way, the security association is between the PMA and 134 the HA because these entities are the signaling endpoints. Also, 135 when the mobile device moves to a new PMA, the sequencing of messages 136 sourced from multiple PMAs needs to be handled properly by the HA. 138 This document describes how the network entities, PMA and HA, provide 139 mobility management for the mobile device. It is organized to cover 140 the generic functionality of Proxy Mobile IPv4 and also the specifics 141 pertaining to WiMAX (Section 10) and 3GPP2 (Section 11). 143 Note that Proxy Mobile IPv6 [RFC5213] is an IETF standard for 144 network-based mobility management that enables IP mobility for a host 145 without requiring its participation in any mobility-related 146 signaling. 148 2. Conventions used in this document 150 The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119 [RFC2119]. 154 The following new terminology and abbreviations are introduced in 155 this document and all other general mobility related terms as 156 defined in Mobile IPv4 specification [RFC3344]. 158 Mobile Device 160 The mobile device is used to refer to an IPv4 device with its 161 mobility provided by the network. The mobile device is not 162 required to participate in any mobility related signaling for 163 achieving mobility for an obtained IP address. 165 Proxy Mobile IPv4 Client (PMIP Client) 167 This network function is responsible for initiating and 168 maintaining the proxy Mobile IPv4 registration on behalf of the 169 mobile device. Essentially, it performs the Mobile IPv4 client 170 function but it is hosted in the network. In some cases, this 171 function is collocated with the Foreign Agent and in others it 172 is not. In both cases, proxy Mobile IPv4 registration still 173 goes via the Foreign Agent at all practical effects even if it 174 is internal to the node. 176 Home Agent (HA) 178 The Home Agent that is defined in Mobile IPv4 [RFC3344] is used 179 in the Proxy Mobile IPv4 scheme. It is the topological anchor 180 point for the mobile device's home network and is the entity 181 that manages the mobile device's reach-ability state. The 182 additional capabilities for supporting Proxy Mobile IPv4 in the 183 Home Agent are defined in this document. 185 Foreign Agent (FA) 187 The Foreign Agent that is defined in [RFC3344] is used in the 188 Proxy Mobile IPv4 scheme. It is either collocated with or 189 separate from the PMIP Client. It serves the purpose of tunnel 190 end-point from Proxy Mobile IPv4 perspective. 192 Access Router (AR) 194 Access Router is a commonly used term that refers to the node 195 in the network which connects the hosts to the IP network. 197 Proxy Mobility Agent (PMA) 199 Proxy Mobility Agent is the logical entity in the network that 200 encompasses both the PMIP Client and the FA functions. The 201 PMIP Client and the FA collocation in the Access Router 202 constitute an integrated PMA. When the PMIP Client and the FA 203 functions are not collocated in the Access Router, it is 204 referred as a split PMA. A PMIP client may have association 205 with multiple FAs, and vice versa. 207 Proxy Registration Request (PRRQ) 209 The Registration Request message sent by the Proxy Mobility 210 Agent to the Home Agent to set up a mobility binding entry for 211 a mobile device. The message format is identical to that of 212 Mobile IPv4 Registration Request, though the Proxy Mobile IPv4 213 extensions that are defined in this document may be included 214 for enhanced features of network-based mobility management. 216 Proxy Registration Reply (PRRP) 218 The Registration Reply message sent by the Home Agent in 219 response to the Proxy Registration Request received from the 220 Proxy Mobility Agent. The message format is identical to that 221 of Mobile IPv4 Registration Reply, though the Proxy Mobile IPv4 222 extensions that are defined in this document may be included 223 for enhanced features of network-based mobility management. 225 3. Benefits of Proxy Mobile IPv4 227 Proxy Mobile IPv4 (PMIP) is designed to satisfy the requirements 228 listed below. In addition, while this specification and Proxy Mobile 229 IPv4 are not standards, they employ a standard, Mobile IPv4. 230 Implementations of Mobile IPv4 can be re-used (i.e. client-based 231 mobility protocol can be used "as-is" to support network-based 232 mobility). However, new PMIPv4 extensions that are added to Mobile 233 IPv4 improves the flexibility of the solution. The practical 234 advantage of having a common mobility protocol for both client-based 235 and network-based mobility is that a Home Agent can anchor all types 236 of mobile devices, ones that have or others that lack Mobile IPv4 237 function. 239 The network-based mobility management solution defined in this 240 document has the following significant reasons for its use in any 241 wireless network: 243 1. Support for Unmodified Hosts 245 An overwhelming majority of IPv4 hosts do not have Mobile IPv4 246 capability. Providing mobility for them is achievable using 247 Proxy Mobile IPv4. This is accomplished without "touching" 248 the user's devices running on a myriad of operating systems 249 and networking stacks. 251 2. Re-use of Existing Home Agent 253 Existing Home Agent implementation can be used for network- 254 based mobility as well. Further enhancements are optional and 255 only incremental in nature. There are many commonalities 256 between client-based and network-based mobility and sharing 257 the same protocol is a significant benefit. 259 3. Reduction of Air-link Resource Consumption 261 Mobility-related signaling over the air-link is eliminated. 263 4. Support for Heterogeneous Wireless Link Technologies 265 Since Proxy Mobile IPv4 is based on an access technology 266 independent mobility protocol, it can be used for any type of 267 access network. 269 From the network perspective, a mobile device is identified by 270 the NAI and the forwarding is set up between the PMA and HA 271 for the mobile device's current point of attachment on the 272 network. The mobile device may be attached to multiple 273 networks concurrently, although the network treats each access 274 interface independently. This feature can be supported with 275 the use of the PMIP Access Technology Type Extension 276 (Section 5.5). 278 5. Support for IPv4 and IPv6 Host 280 As IPv6 increases in popularity, the host will likely be dual 281 stack. Adding IPv6 support to the host for Proxy Mobile IPv4 282 involves the methods defined in [DSMIPv4]. There are 283 additional enhancements needed which are described in Proxy 284 Mobile IPv6 [RFC5213]. However, support for IPv6 host is out 285 of scope. 287 4. Overview of Proxy Mobile IPv4 289 4.1. Mobility Signaling for Mobile Device 291 After the mobile device completes network access authentication, the 292 PMA exchanges proxy Mobile IPv4 registration messages with the HA to 293 set up proper routing and tunneling of packets from/to the Mobile 294 Node. The PMIP Client is responsible for initiating the proxy Mobile 295 IPv4 registration. For integrated PMA, the PMIP Client and the FA 296 interaction is all within the node. In the case of split PMA 297 implementation, the interactions between the PMIP Client and the FA 298 are exposed. The interface between the PMIP Client and the FA in the 299 split PMA scenario is defined in standards organization specification 300 (e.g. WiMAX R4 reference point) and consequently out of scope of 301 this document. 303 The following call flows describe the operations of Proxy Mobile 304 IPv4. The initial network attachment, registration renewal, and 305 resource cleanup procedures are covered. Note that the protocols 306 which interact with Proxy Mobile IP are identified and explained in 307 more details. PPP/IPCP protocol involves PPP client in the mobile 308 device and NAS in the AR. DHCP protocol involves a DHCP Client in 309 the MN and DHCP Server in either the AR or the HA. PMIP protocol 310 involves a PMA in the AR and an HA in the router on the home network. 311 AAA protocol involves a AAA Client in the AR and a AAA Server in the 312 network. The colocation of the functional entities in the AR/HA 313 enables parameters to be shared/processed among the protocols. 315 When the various network entities are not collocated, any sharing of 316 parameters or other state information between them is out of the 317 scope of this draft. 319 4.1.1. Proxy Registration during Initial Network Attachment 321 +----+ +-------+ +-------+ +-----+ 322 | | | AR / | | | | | 323 | MN | | PMA | | AAA | | HA | 324 | | | | | | | | 325 +----+ +-------+ +-------+ +-----+ 326 | | | | 327 | 1a | 1b | | 328 Authentication |<------------->|<----------->| | 329 | | | | 330 | 2 | | | 331 +-> |-------------->| | | 332 | | | 3 | | 333 | | |-------------------------->| <-+ 334 Address | | | | | | PMIP 335 Acquisition | | | 4 | | | 336 | | |<--------------------------| <-+ 337 | | 5 | | | 338 +-> |<--------------| | | 339 | | | | 340 | 6 | | | 341 Data Forwarding |<------------->|<=========================>| 342 | | | | 344 Figure 1: Network Connection Setup 346 The initial network attachment procedure is described below. There 347 are three distinct phases. First, authentication and authorization 348 happen when the mobile device accesses the network. Then mobile 349 device attempts to obtain an IP address. This triggers Proxy Mobile 350 IP which assigns/authorizes the IP address and sets up forwarding 351 between the PMA and HA. The host configuration parameters may be 352 passed in the PMIP signaling. Finally, mobile device configures its 353 IP stack with the IP address and obtained host configuration. 354 Packets to and from the mobile device transit both the PMA and HA. 356 1a. The mobile device establishes L2 link with the base station (not 357 shown) and performs access authentication/authorization with the AR 358 (Access Router). During this phase, the mobile device may run CHAP 359 [RFC1994] if PPP [RFC1548] is used or EAP [RFC3748] over foo (foo 360 being the specific access technology or PANA [RFC4058]). The AR acts 361 as the NAS (Network Access Server) in this step. 363 1b. The AAA client exchanges AAA messages with the AAA 364 infrastructure to perform authentication and authorization of the 365 mobile device. As part of this step, the AAA server may download 366 some information about the mobile device (e.g. user's profile, 367 handset type, assigned home agent address, and other capabilities of 368 the mobile device). 370 2. The mobile device requests for an IP address via an PPP/IPCP 371 [RFC1332] or DHCP [RFC2131]. Specifically for PPP, the PPP client 372 sends IPCP Configure-Request to the NAS. As for DHCP, the DHCP 373 client sends the DHCP Discover message to the DHCP relay agent/ 374 server. 376 For the DHCP case, the DHCP server or DHCP relay agent sends the DHCP 377 Ack message to the DHCP client after PMIPv4 signaling had completed. 379 3. Triggered by step 2, the PMA sends an Proxy Registration Request 380 (PRRQ) to the HA. The HA's IP address is either obtained from the 381 AAA server at step 1b or discovered by some other method. The PRRQ 382 contains the Care-of Address (CoA) of the PMA (collocated FA in this 383 case). The Home Address field is set to zero or the IP address 384 specified as hint in the DHCP or IPCP message. The PRRQ MUST be 385 protected by the methods described in Security Considerations 386 (Section 13). The derivation and distribution of the MN-HA or FA-HA 387 key is outside the scope of this document. 389 4. The home agent sets up the mobility binding entry for the mobile 390 device after assigning an IP address or authorizing the requested 391 Home Address. The home agent may also assign a GRE key in this step 392 (if GRE tunneling is used between the PMA and HA). The HA returns 393 the Home Address, and the GRE key (if applicable) in the Proxy 394 Registration Request (PRRP) to the PMA. If the requested Home 395 Address is not authorized, the home agent denies the registration 396 with error code 129 (administratively prohibited). After the PMA 397 processes the PRRP, the forwarding path for the Home Address between 398 the PMA and HA is established. A GRE tunnel may be used between the 399 PMA and the HA [MIP4GREKEY]. The event completes the Proxy Mobile 400 IPv4 signaling for initial network attachment. 402 5. After the Proxy Mobile IPv4 registration exchange, the AR 403 provides the IP address to the mobile device in response to step 2. 404 For IPCP, the NAS replies to the PPP client with IPCP Configure-Nak 405 which includes the PMIP assigned Home Address in the IP-Address 406 configuration option and the DNS server address in the IPCP 407 configuration option. 409 The following procedure happens when the DHCP server is on the AR. 410 The DHCP server sends a DHCP Offer with the PMIP assigned Home 411 Address in the yiaddr field to the DHCP client. The DHCP client 412 sends a DHCP Request to the DHCP server, which replies with a DHCP 413 Ack. The host configuration such as DNS server address is included in 414 the DHCP options in the message. Note that the DHCP messages are 415 exchanged directly between the DHCP client and the DHCP server. 417 In the case when AR acts as a DHCP relay agent, the DHCP Discover is 418 relayed to the DHCP server on the HA. The DHCP server sends a DHCP 419 Offer with the PMIP assigned Home Address in the yiaddr field to the 420 DHCP relay agent, which forwards to the DHCP client. The DHCP 421 Request and DHCP Ack messages are exchanged between the DHCP client 422 and DHCP server via the DHCP relay agent. Regardless of the sequence 423 of PMIP signaling and DHCP exchanges, the interaction between PMIP 424 and DHCP involves in the same IP address for Home Address field and 425 yiaddr field, respectively. 427 6. At this step, the mobile device's IP stack is configured with an 428 IP address that has a forwarding path between the AR/PMA and HA. 429 Also, the host configuration such as DNS servers is configured at 430 this time. Now that the IPCP or DHCP procedure has completed, the 431 mobile device is ready to receive or send IP packets. If DHCP is 432 used, the DHCP client renews the IP address by sending a DHCP Request 433 directly to the DHCP server. The lease for the IP address is 434 extended when a DHCP Ack from the DHCP server is received by the DHCP 435 client. 437 4.1.2. Proxy Registration Renewal 439 +----+ +-------+ +-----+ 440 | | | AR / | | | 441 | MN | | PMA | | HA | 442 | | | | | | 443 +----+ +-------+ +-----+ 444 | | | 445 | | 1 | 446 | |----------------------->| 447 PMIP | | | 448 Renewal | | 2 | 449 | |<-----------------------| 450 | | | 451 | | | 453 Figure 2: Network Connection Maintenance 455 The network connection maintenance procedure is described below. As 456 long as the mobile device remains attached to the AR, the Proxy 457 Mobile IPv4 session is maintained by re-registration exchange between 458 the AR and HA. 460 1. Before the PMIP registration lifetime expires and assuming the AR 461 has not received any indication that the mobile device detached from 462 the network, the PMA sends PRRQ to the HA to extend the duration of 463 the mobility binding of the mobile device. The PRRQ is similar to 464 the initial PRRQ (i.e. HA field set to the assigned HA and CoA field 465 set to the PMA), though the Home Address field is always set to the 466 assigned IP address of the mobile device. The mobile device's IP 467 stack can continue to send and receive IP packets using the Home 468 Address anchored at the HA. 470 2. The HA sends the PRRP in response to the PRRQ received from the 471 PMA. After the PMA processes the PRRP, the forwarding path between 472 AR and HA remains intact. 474 4.1.3. Proxy Handover Support 476 +----+ +-------+ +-------+ +-----+ 477 | | | New | | Old | | | 478 | MN | | AR / | | AR / | | HA | 479 | | | PMA | | PMA | | | 480 +----+ +-------+ +-------+ +-----+ 481 | | | | 482 | 1 | | | 483 Authentication |<------------->| | | 484 | | | | 485 | | 2 | | 486 +-> | |-------------------------->| 487 PMIP | | | | | 488 | | | 3 | | 489 +-> | |<--------------------------| 490 | | | | 491 | 4 | | | 492 Data Forwarding |<------------->|<=========================>| 493 | | | | 495 Figure 3: AR Handover 497 The AR handover procedure is described below. There are three 498 phases. First, authentication and authorization happens when mobile 499 device attaches to the new AR in the network. The successful 500 authentication triggers the Proxy Mobile IPv4 signaling. In the last 501 phase, the forwarding path between new AR and HA is set up for the 502 mobile device to send and receive IP packets using the same Home 503 Address anchored at the HA. 505 1. The mobile device establishes L2 link with the base station (not 506 shown) and performs access authentication/authorization with the new 507 AR using the security method for network re-attachment. 509 2. Triggered by successful authentication, the PMA sends an PRRQ to 510 the HA. The HA's IP address is obtained or known typically by the 511 method used for fast reauthentication during AR handover (e.g. 512 context transfer between the two ARs). Though other methods may be 513 used. The PRRQ contains the CoA of the new PMA. The Home Address 514 field is set to zero or the assigned IP address of the mobile device. 515 The IP address is also obtained/known by the same method mentioned 516 before. 518 3. The home agent updates the existing mobility binding entry for 519 the mobile device upon processing the PRRQ. The home agent returns 520 the Home Address, fetched from the binding, in the PRRP to the new 521 PMA. After the PMA processes the PRRP, the forwarding path for the 522 Home Address between the new AR and HA is established. The event 523 completes the Proxy Mobile IPv4 signaling for AR handover. 525 4. At this step, which happens around the same time as step 2, the 526 mobile device's IP stack may detect L2 link going down and up after 527 access re-authentication. The mobile device's IP stack may attempt 528 to validate its IP address connectivity. See ARP ([RFCARP]) 529 Section 6.1, ICMP ([RFCICMP]) Section 6.2 and DHCP ([RFC2131]) 530 Section 6.3 considerations for details. Because the forwarding path 531 is established between the new PMA and HA, the mobile device can 532 receive or send IP packets using the Home Address. 534 4.1.4. Resource Cleanup 536 +----+ +-------+ +-------+ +-----+ 537 | | | New | | Old | | | 538 | MN | | AR / | | AR / | | HA | 539 | | | PMA | | PMA | | | 540 +----+ +-------+ +-------+ +-----+ 541 | | | | 542 | | | 1 | 543 +-> | | |<------------| 544 | | | | | 545 Revocation | | | o 2 | 546 | | | | | 547 | | | | 3 | 548 +-> | | |------------>| 549 | | | | 551 Figure 4: Registration Revocation for Previous PMA 553 The resource cleanup procedure for the old AR is described below. 554 This is necessary when the old AR needs to delete its PMIP and other 555 associated states for the mobile device that has moved to another AR. 556 Therefore, this is an optional procedure for Proxy Mobile IP. The 557 alternative method is based on the new PMA notifying the old PMA to 558 clean up resources. This method is out of scope of this document. 560 1. Triggered by the update of the mobility binding entry for a 561 mobile device that has moved to a new AR, the HA may send a 562 Registration Revocation (as specified in RFC 3543 [RFC3543]) to the 563 old PMA (i.e. specifically to the Foreign Agent entity) in order to 564 clean up unused resources in an expeditious manner. 566 2. The old PMA removes the PMIP states for the mobile device. 568 3. The old PMA sends revocation acknowledgement to the HA. 570 4.2. Establishment of Bi-Directional Tunnel 572 The PMA and HA set up a tunnel between them for the Home Address 573 after the PMIP registration message exchange. 575 4.2.1. Packet Forwarding 577 The bi-directional tunnel between the PMA and the HA allows packets 578 to flow in both directions, while the mobile device is connected on 579 the visited network. All traffic to and from the mobile device 580 travels through this tunnel. 582 While the PMA is serving a mobile device, it MUST be able to 583 intercept all packets sent from the mobile device and forward them 584 out the tunnel created for supporting that mobile device. Typically, 585 forwarding is based on Layer 2 information such as the source MAC 586 address or ingress interface. This allows overlapping IP addresses 587 to be supported for the packet from the mobile device. For example, 588 packets from mobile devices with the same IP address are forwarded to 589 the tunnel associated with each mobile device by the PMA based on the 590 source MAC address. 592 Any packets received on the tunnel from HA, the PMA de-encapsulates 593 before forwarding to the mobile device on its link. Typically, the 594 forwarding is based on the destination IP address and ingress HA 595 tunnel (which may have GRE Key). This allows overlapping IP 596 addresses to be supported for the packet destined to the mobile 597 device. For example, packets to mobile devices with the same IP 598 address are forwarded to the link associated with each mobile device 599 by the PMA based on the GRE Key value of the tunnel created for the 600 HA that serves these mobile devices. 602 The tunnel operation between the PMA and HA is same as between FA and 603 HA in RFC 3344. The IP TTL, fragmentation, re-assembly, etc. logic 604 remain the same. The tunnel mode is IPinIP by default or GRE as an 605 option. 607 4.2.2. Broadcast and Multicast 609 Broadcast packet processing for DHCP and ARP messages are described 610 in Section 6.3 and Section 6.1, respectively. For other types of 611 broadcast packets, the PMA and HA process them in accordance to 612 [RFC3344], [RFC3024], and [MIP4MCBC]. Only the Direct Encapsulation 613 Delivery Style is supported as there is no encapsulation for the 614 packets between the mobile device and PMA. 616 4.2.3. Forwarding Between Devices on same PMA 618 When the communication peers are both attached to the same PMA, the 619 packet is forwarded as specified in Section 4.2.1. The traffic 620 between them are should be routed via the HA without taking local 621 shortcut on the PMA. This ensures that data traffic enforcement at 622 the HA is not bypassed. 624 4.3. Security Association Between the PMA and the HA 626 The security relationship for protecting the control message 627 exchanges between the PMA and the HA may be either per node (i.e. 628 same security association for all mobile devices) or per MN (i.e. 629 unique security association per mobile device). The method of 630 obtaining the security association is outside of scope of this 631 document. 633 For per node SA support, FA-HA Authentication Extension or IPSec 634 (indicated in the PMIPv4 extension) is used to authenticate the 635 signaling messages (including Registration Revocation [RFC3543]) 636 between PMA and HA. In the case of IPSec, Encapsulating Security 637 Payload (ESP) [RFC4303] in transport mode with mandatory integrity 638 protection should be used. The IPSec endpoints are the IP addresses 639 of the PMA and HA. 641 For per MN SA support, MN-HA Authentication Extension and/or MN-AAA 642 Authentication Extension are used to authenticate the signaling. 644 The creation of the security association may be assisted by the AAA 645 server at the time of access authentication. 647 4.4. Registration Sequencing 649 The Identification field in the registration message provides replay 650 protection and sequencing when the timestamp method is used. This 651 mechanism allows the HA to know the sequence of messages from the 652 same PMA or different PMAs based on the Identification field. The HA 653 can also synchronize the PMA's clock by using the Identification 654 mismatch error code in the proxy registration reply. This reply 655 message would not be necessary when the PMA's clocks are synchronized 656 using Network Time Protocol [RFC1305] or some other method. Note 657 that the use of nonce for sequencing and replay protection is outside 658 of scope. 660 The method above is sufficient when there is a single source for 661 signaling as in the split PMA case. However in the integrated PMA 662 case, the proxy registration request is sent from different sources 663 (i.e. different PMAs). If the previous PMA is unaware that the 664 mobile device has moved away and continues to send re-registration, 665 then HA would be misinformed on the location of the device. 666 Therefore, an integrated PMA MUST confirm that the mobile device is 667 still attached before sending a proxy registration request. 669 Note that for split PMA model as used in WiMAX Forum, see Section 10, 670 the PMIP Client remains anchored during handover, see Section 10.1. 671 In this case, the PMIP Client is the only source of the PRRQ. 673 However, there are cases such as PMIP Client relocation and 674 uncontrolled handover event when more than one PMA performs 675 registration. The same method for the integrated PMA is used to 676 ensure proper sequencing of registration on the HA. 678 4.5. Mobile Device Interface Configuration 680 Typically, the mobile device's interface needs to be configured with 681 an IP address, network prefix, default gateway, and DNS server 682 addresses before the network connection can be enabled to be used for 683 communication. For some IP stacks, the default gateway IP address 684 has to be on the same subnet as the mobile device's IP address. When 685 the Home Agent's IP address is not on the same subnet as the Home 686 Address, the vendor specific extensions (e.g. [RFC4332]) or other 687 methods MAY be used by the PMA to obtain the default gateway. 689 4.6. Dynamic HA Discovery 691 The PMA can perform dynamic HA discovery by sending the registration 692 with Home Agent field set to 0.0.0.0 or 255.255.255.255. The Home 693 Agent responds with its IP address in the Home Agent field as 694 specified in Dynamic HA Assignment [RFC4433]. 696 5. Proxy Mobile IPv4 Extensions 698 The following PMIPv4 extensions are not required for base 699 functionality but may be used in some cases where such features are 700 applicable. They are included before the authentication extension 701 (e.g. MN-HA or FA-HA authentication extension) in the registration 702 message. 704 5.1. PMIPv4 Per-Node Authentication Method Extension 706 The Proxy Mobile IPv4 Authentication Method extension indicates 707 alternative methods for authenticating the registration besides the 708 default MN-HA Authentication Extension as specified in RFC 3344. 709 This extension MUST be included in the Registration Request and 710 Registration Reply when the security association for authenticating 711 the message is between the PMA and HA on a per node basis. This 712 means that a common key or set of keys (indexed by the SPI) are used 713 for message authentication by the PMA and HA. The key is independent 714 of the mobile device which is identified in the registration. 716 0 1 2 3 717 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 718 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 719 | Type | Sub-Type | Length | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 | Method | 722 +-+-+-+-+-+-+-+-+ 724 PMIPv4 Per-Node Authentication Method Extension 726 Type 728 47 (Proxy Mobile IPv4 Non-skippable Extension) 730 Sub-Type 732 1 (PMIPv4 Per-Node Authentication Method) 734 Length 736 1 738 Method 740 An 8-bit field that specifies the authentication type for 741 protecting the signaling messages. 743 The values (0 - 255) will be allocated and managed by IANA. 744 The following values are currently reserved for the below 745 specified method types. 747 0: Reserved 749 1: FA-HA Authentication 751 2: IPSec Authentication 753 5.2. Proxy Mobile IPv4 Interface ID Extension 755 The Proxy Mobile IPv4 Interface ID extension identifies the interface 756 address of the device used to attach to the network. The information 757 MAY be included in the Registration Request when the PMA is aware of 758 it. 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | Type | Length | Sub-Type | Identifier ... 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 PMIPv4 Interface ID Extension 768 Type 770 147 (Proxy Mobile IPv4 Skippable Extension) 772 Length 774 The length of the extension in octets, excluding Type and 775 Length fields. 777 Sub-Type 779 1 (PMIPv4 Interface ID) 781 Identifier 783 A variable-length octet sequence that contains an identifier of 784 the interface. 786 5.3. Proxy Mobile IPv4 Device ID Extension 788 The Proxy Mobile IPv4 Device ID extension identifies the device used 789 to connect to the network. The information MAY be included in the 790 Registration Request when the PMA is aware of it. 792 0 1 2 3 793 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 794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 795 | Type | Length | Sub-Type | ID-Type | 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Identifier ... 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 800 PMIPv4 Device ID Extension 802 Type 804 147 (Proxy Mobile IPv4 Skippable Extension) 806 Length 808 The length of the extension in octets, excluding Type and 809 Length fields. 811 Sub-Type 813 2 (PMIPv4 Device ID) 815 ID-Type 817 An 8-bit field that specifies the device ID type. 819 The values (0 - 255) will be allocated and managed by IANA. 820 The following values are currently reserved for the below 821 specified device ID types. 823 0: Reserved 825 1: Ethernet MAC address 827 2: Mobile Equipment Identifier (MEID) 829 3: International Mobile Equipment Identity (IMEI) 831 4: Electronic Serial Number (ESN) 833 Identifier 835 A variable-length octet sequence that contains an identifier of 836 the type indicated by the ID-Type field. 838 5.4. Proxy Mobile IPv4 Subscriber ID Extension 840 The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile 841 subscription. The information MAY be included in the Registration 842 Request when the PMA is aware of it. 844 0 1 2 3 845 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 846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 847 | Type | Length | Sub-Type | ID-Type | 848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 849 | Identifier ... 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 PMIPv4 Subscriber ID Extension 854 Type 856 147 (Proxy Mobile IPv4 Skippable Extension) 858 Length 860 The length of the extension in octets, excluding Type and 861 Length fields. 863 Sub-Type 865 3 (PMIPv4 Subscriber ID) 867 ID-Type 869 An 8-bit field that specifies the subscriber ID type. 871 The values (0 - 255) will be allocated and managed by IANA. 872 The following values are currently reserved for the below 873 specified subscriber ID types. 875 0: Reserved 877 1: International Mobile Subscriber Identity (IMSI) 879 Identifier 881 A variable-length octet sequence that contains an identifier of 882 the type indicated by the ID-Type field. 884 5.5. PMIP Access Technology Type Extension 886 The Proxy Mobile IPv4 Access Technology Type extension indicates the 887 type of radio access technology on which the mobile device is 888 attached. This extension MAY be included in the Registration Request 889 when the PMA is aware of the information. The HA can provide 890 mobility on the same access technology type for a mobile device with 891 multiple interfaces assuming each interface is connected on a 892 different access technology type. The HA does not include the 893 extension in the associated Registration Reply. 895 0 1 2 3 896 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 897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 898 | Type | Length | Sub-Type | Tech-Type | 899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 PMIP Access Technology Type Extension 903 Type 905 147 (Proxy Mobile IPv4 Skippable Extension) 907 Length 909 2 911 Sub-Type 913 4 (Access Technology Type) 915 Tech-Type 917 An 8-bit field that specifies the access technology through 918 which the mobile device is connected to the access network. 920 The values (0 - 255) will be allocated and managed by IANA. 921 The following values are currently reserved for the below 922 specified access technology types. 924 0: Reserved 926 1: 802.3 928 2: 802.11a/b/g 930 3: 802.16e 932 4: 802.16m 934 5: 3GPP EUTRAN/LTE 936 6: 3GPP UTRAN/GERAN 938 7: 3GPP2 1xRTT/HRPD 940 8: 3GPP2 UMB 942 6. Appearance of Being at Home Network 944 Since the Mobile Node is not aware of its mobility and does not 945 participate in handover signaling, the network entities emulate the 946 home network to the mobile device attached on the network. From the 947 mobile device's perspective, it operates as it is at the home 948 network. However, the network is directing the mobile device's 949 traffic to and from its current location and when it moves to a new 950 location. 952 An unmodified mobile device on a shared link learns the MAC address 953 of another host on the home network via ARP ([RFCARP]), obtains an IP 954 address and other host configuration via DHCP ([RFC2131]), and sends 955 link-local multicast and broadcast packets. The network's response 956 to the host is equivalent to the situation when host is on the home 957 network. When the link state changes, some hosts use ARP, ICMP, 958 and/or DHCP to detect if it has changed the point of attachment on 959 the network. 961 6.1. ARP Considerations 963 For IEEE 802 type of access networks (e.g. WLAN, WiMAX Ethernet 964 Convergence Sublayer), the mobile device sends ARP request for the CN 965 and default gateway on the same network. The purpose of maintaining 966 an ARP entry is to allow the delivery of the packet from the mobile 967 device to the CN using the destination MAC address. The ARP 968 procedure for resolving IP and MAC address mapping is not needed for 969 3GPP2's cdma2000 and WiMAX IP Convergence Sublayer networks. 971 The access router is always the L2 endpoint for the mobile device. 972 The destination MAC address in the packet does not need to be set to 973 the CN's MAC address. As long as the packet can be received by the 974 access router, it will be forwarded toward the CN via the home 975 network node (further details in Section 4.2.1). The ARP table in 976 the mobile device does not need to be populated with CNs' MAC 977 addresses for the packet to reach the CNs. 979 A mobile device has ARP entries for default gateway and hosts on the 980 same subnet. Regardless of what the MAC addresses are, the AR 981 receives the packets sent from the mobile device. 983 6.2. ICMP Considerations 985 For movement detection, certain types of network stack on the mobile 986 device will send an ICMP request [RFCICMP] to the default gateway 987 after detecting the link went down and up. The IP TTL in the message 988 is set to 1 to check if the default gateway is still directly 989 reachable on the access network. The PMA MAY send an ICMP reply when 990 it is providing Proxy Mobile IPv4 service for the mobile device. 991 This response confirms to the mobile device that it has remained on 992 the home network after link state change. This behavior is observed 993 on existing client implementation. Detecting Network Attachment in 994 IPv4 [RFC4436] can be employed. 996 General ICMP traffic is handled as normal IP packets and tunneled 997 between PMA and HA. 999 6.3. DHCP Considerations 1001 DHCP [RFC2131] is used to obtain an IP address and other host 1002 configuration parameters for a mobile device. The mobile device is 1003 expected to behave as a normal DHCP client when connected to the 1004 network with Proxy Mobile IPv4 service. There are two DHCP phases: 1005 bootup and renewal/release. The bootup procedure relies on the DHCP 1006 relay agent to obtain a lease on the IP address for the DHCP client 1007 from the DHCP server. The DHCP client directly renews and releases 1008 the lease with the DHCP server. 1010 In Proxy Mobile IPv4, the mobile device boots up on a network that is 1011 not the home network associated with the leased IP address. Also, 1012 the mobile device can move to other networks that are not related to 1013 that IP address. Yet, the DHCP client on the mobile device continues 1014 to operate as a stationary device that is directly on the network 1015 associated with its IP address. The PMA and HA create the 1016 transparency of the remote home network and mobility events by 1017 providing the expected network response to the DHCP client. 1019 There are several methods for the network infrastructure to interface 1020 with the mobile device such that the mobile device believes it is 1021 always fixed on the same network. The following methods are 1022 identified here, though others may be used as well: 1024 DHCP Server in the AR: 1026 The mobile device boots up and initiates DHCP. The procedure is 1027 described in Figure 1. The DHCP client renews or releases the IP 1028 address directly with the DHCP server in the AR. When the mobile 1029 device is on a different AR than the AR/DHCP server, the DHCP message 1030 from the client needs to be able to be forwarded to the DHCP server 1031 in the previous AR or handled by the DHCP server in the new AR. When 1032 the DHCP lease time expires for the mobile device's IP address or the 1033 DHCP release message is received on the current AR, the AR sends 1034 PMIPv4 de-registration to the HA. 1036 DHCP Relay Agent in the AR: 1038 The mobile device boots up and initiates DHCP. The procedure is 1039 described in Figure 1. The DHCP client renews or releases the IP 1040 address directly with the DHCP server in the HA. When the mobile 1041 device is on a different AR, the DHCP message from the client are 1042 relayed to the DHCP server in the HA. When the DHCP lease time 1043 expires for the mobile device's IP address or the DHCP release 1044 message is received on the HA, the HA deletes the mobility binding 1045 entry for the mobile device and sends registration revocation 1046 [RFC3543] to the AR. 1048 6.4. PPP IPCP Considerations 1050 When the mobile device access the network via PPP [RFC1548], LCP CHAP 1051 is used to authenticate the user. After authentication, the NAS 1052 (which is the AR/PMA) sends the proxy Mobile IPv4 Registration 1053 Request to the HA. The HA responds with the Home Address in the 1054 proxy Registration Reply. The NAS informs the mobile device to use 1055 the Home Address during IPCP [RFC1332]. When mobile device moves to 1056 a new NAS, the same procedure happens and mobile device has the same 1057 IP address for communication. 1059 The message exchange is illustrated in Figure 1. 1061 6.5. Link-Local Multicast and Broadcast Considerations 1063 Depending on configuration policies, the PMA may tunnel all packets 1064 destined to Link-Local Multicast or Broadcast to the HA. The HA 1065 looks up the hosts which are in the same subnet and send a duplicated 1066 packet to each of them. 1068 7. Proxy Mobility Agent Operation 1070 The PMA performs the functions of a Mobile Node entity as described 1071 in RFC 3344 with the exceptions identified below. 1073 - No agent discovery (i.e. agent solicitation and advertisement) 1074 is supported 1076 - D-bit (De-encapsulation by MN) in the Registration Request is 1077 always set to zero 1079 The main responsibility of the PMA is to set up and maintain the 1080 routing path between itself and the HA for a mobile device that is 1081 attached on the network. When it detects a mobile device is no 1082 longer attached, the routing path is torn down. It is possible that 1083 the PMA functions may be split up in implementations such as WiMAX 1084 (Section 10). 1086 The PMA needs to know the following information at a minimum for 1087 sending a proxy registration: 1089 1. NAI of the mobile device 1091 2. MN-HA security association when per-mobile device security 1092 association is used 1094 3. FA-HA Mobility Security Association or IPSec Security Association 1095 when per-node security association is used. Note, these 1096 associations are specific only between PMA and HA, and 1097 cryptographically unrelated to the associations between the MN 1098 and other network nodes. 1100 4. HA Address 1102 The information is typically downloaded from AAA server during access 1103 authentication. 1105 8. Home Agent Operation 1107 The Home Agent has the functionality as described in RFC 3344 1108 [RFC3344]. In addition, the following features are introduced by 1109 Proxy Mobile IPv4: 1111 1. Sequencing between PRRQs from multiple PMAs. For the integrated 1112 PMA case, there is a period after handover that may result in both 1113 the new PMA and old PMA sending PRRQs. It is imperative that the old 1114 PMA confirm that the mobile device is attached before sending a PRRQ 1115 when re-registration timer expires. This would ensure that the HA 1116 only receives registration from PMA that is serving the mobile 1117 device. 1119 2. Authentication of PRRQs based on per Node Security Association 1120 (FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA case. 1121 The presence of MN-HA AE or MN-AAA AE in the PRRQ is not necessary in 1122 this case. Since PMIP is based on signaling between the PMA and the 1123 HA, the security for the message can be authenticated based on the 1124 peers' relationship. The HA can authorize PMIP service for the 1125 mobile device at the PMA by contacting the AAA server. 1127 3. The ability to process the Proxy Mobile IPv4 Extensions defined 1128 in this document for enhanced capabilities of PMIP. 1130 8.1. Processing Proxy Registration Requests 1132 When a proxy registration request is received, the HA looks up the 1133 mobility binding entry indexed by the NAI. If the entry exists, HA 1134 compares the Sequence Numbers between the message and mobility 1135 binding entry (MBE), if present. If the value in the message is zero 1136 or greater than or equal to the one in MBE, HA accepts the 1137 registration. The HA replies with a sequence number that is one 1138 greater than larger value of either the MBE or Proxy Registration 1139 Request. If the registration is denied, then HA sends error code 1140 "Administratively prohibited (65)". If the HA is not enabled with 1141 Proxy Mobile IPv4 or it cannot process the Proxy Mobile IPv4 1142 Extensions defined in this document, it sends a registration reply 1143 with error code PMIP_UNSUPPORTED (Proxy Registration not supported by 1144 the HA). In the case when the PMA is not allowed to send a proxy 1145 registration request to the HA, the HA sends a proxy registration 1146 reply with error code PMIP_DISALLOWED (Proxy Registrations from this 1147 PMA is not allowed). 1149 A PMA receiving these error codes SHOULD not retry sending proxy 1150 Mobile IPv4 messages to the HA that sent replies with these error 1151 codes. 1153 9. Mobile Device Operation 1155 As per this specification, a mobile device would function as a normal 1156 IPv4 host. The required behavior of the node will be consistent with 1157 the base IPv4 specification [1]. The mobile station will have the 1158 ability to retain its IPv4 address as it moves from one point of 1159 network attachment to the other without ever requiring it to 1160 participate in any mobility related signaling. 1162 When booting up for the first time, a mobile device obtains an IPv4 1163 address using DHCP or IPCP. 1165 As the mobile device roams, it is always able to communicate using 1166 the obtained IP address on the home network. The PMA on the 1167 currently attached network signals to the HA to ensure proper 1168 forwarding path for mobile device's traffic. 1170 9.1. Initial Network Access 1172 When the mobile device accesses the network for the first time and 1173 attaches to a network on the PMA, it will present its identity in the 1174 form of NAI to the network as part of the network access 1175 authentication process. 1177 Once the address configuration is complete, the mobile device will 1178 always be able to use that IP address anywhere in the network. 1180 9.2. Mobile Device Mobility 1182 When a mobile device moves to a new PMA from another PMA, the 1183 following occurs: 1185 The mobile device may perform a network access authentication with 1186 the new AR/PMA. If the authentication fails, the mobile device will 1187 not be able to use the link. After a successful authentication, the 1188 new PMA will have the identifier and the other profile data of the 1189 mobile device. The new PMA can also obtain mobile device's 1190 information using a context transfer mechanism which is out of scope 1191 of this document. 1193 Once the network access authentication process is complete, the 1194 mobile device may sense a change in the Link Layer and use ARP, DHCP, 1195 and/or ICMP to detect if it is still on the same subnet. These 1196 mechanisms are handled by the network as described in "Appearance of 1197 Being At Home Network" (Section 6) section. 1199 9.3. Sending and Receiving Packet 1201 All packets that are be sent from the mobile device to the 1202 Corresponding Node (CN) will be sent as normal IPv4 packets setting 1203 the Source Address of the IPv4 header to the Home Address and the 1204 Destination Address to the corresponding node's IP address. In proxy 1205 Mobile IPv4 operation, the default gateway for the mobile device is 1206 set up to reach the PMA. 1208 Similarly, all packets sent to the mobile device's IP Address by the 1209 corresponding node will be received by the mobile device in the 1210 original form (without any tunneling overhead). 1212 For Proxy Mobile IP, the packet from the mobile device is transported 1213 to the HA to reach the destination regardless of the destination IP 1214 address. For a CN with an IP address on the same network as the 1215 mobile device but is physically located elsewhere, the HA will tunnel 1216 the packet to the CN. Otherwise, the HA forwards the traffic via 1217 normal routing. 1219 No special operation is required by the mobile device to either send 1220 or receive packets. 1222 Mobile devices attached to the same PMA may be using different HAs 1223 for transporting their traffic. 1225 10. Proxy Mobile IPv4 Use Case in WiMAX 1227 WiMAX Forum Network Working Group (NWG) uses Proxy Mobile IPv4 scheme 1228 to provide IPv4 connectivity and IP mobility. The relevant 1229 specification from WiMAX Forum is [NWG]. 1231 The Proxy Mobile IPv4 protocol is used over NWG reference point 3 1232 (R3). Most of the Proxy Mobile IPv4 related procedures and 1233 requirements are described in reference to mobility management over 1234 R3. 1236 The Proxy Mobile IPv4 use case in WiMAX Forum specification is 1237 illustrated in the following diagram: 1239 | 1240 | CSN 1241 | 1242 | 1243 +-------+ | +-------+ 1244 | | | | | 1245 |AAAV |--------------|------------| AAAH | 1246 | | | | | 1247 | | | | | 1248 +-------+ | +-------+ 1249 | | | 1250 | | | 1251 | | | 1252 +------------------+ | | 1253 | +-------+ | | | 1254 | | NAS | | | | 1255 | | PMIP | ASN1 | | | 1256 | | Client| | | | 1257 | +-------+ | | | 1258 | | | | | 1259 | | R4 | | | 1260 | +-------+ | | +------+ 1261 +----+ | | FA, | | | PMIPv4 | | 1262 | MN |-------| DHCP |---------------------------| HA | 1263 +----+ | | Relay/| | | R3 | | 1264 | | Server| ASN2 | | +------+ 1265 | +-------+ | | 1266 | | | 1267 +------------------+ 1268 Split PMA 1270 WiMAX NWG network configuration for PMIP use 1272 As shown in the figure above, WiMAX NWG uses the split PMA model. 1273 The PMIP Client is collocated with the NAS in ASN1 (a.k.a. 1274 Authenticator ASN). The NWG architecture divides the network into 1275 two parts. The Access part is termed as Access Service Network 1276 (ASN). The Core part is termed as Connectivity Service Network 1277 (CSN). The MN attaches to a 802.16 radio in the ASN2 (aka Anchor 1278 Data Path Function). The radio (base station) connects to the Anchor 1279 Data Path Function (A_DPF) in ASN2 which in turn connects to 1280 Authenticator ASN (NAS) in ASN1. ASN1 authenticates and authorizes 1281 the MN. The AAA infrastructure is used to authenticate and authorize 1282 the MN. 1284 Note that, during initial network entry by the MN, the PMA can be an 1285 integrated PMA with all the functions collocated in ASN1. Due to 1286 mobility, the FA part of the PMA may have to be relocated to a more 1287 optimized location for better bearer management. However, to 1288 describe the WiMAX specific use case for Proxy Mobile IPv4, we will 1289 use the split PMA model since it is more generic representation of 1290 the WiMAX NWG mobility framework. 1292 WiMAX NWG specification [NWG], defines key bootstrapping scheme for 1293 use with proxy Mobile IPv4. The specification uses per MN security 1294 association for proxy Mobile IPv4 operation. The relevant keys (e.g. 1295 MN-HA key) are derived using EAP authentication as specified in this 1296 document. For more information, please refer to section 4.3 of 1297 [NWG], stage-3 specification. 1299 Mobile IPv4 Registration Revocation is optionally supported in WiMAX. 1300 The security association for this is per Node. It is provided with 1301 FA-HA AE. The FA-HA key is also bootstrapped via the same key 1302 hierarchy that is described in section 4.3 of [NWG]. 1304 The proxy Mobile IPv4 operation in WiMAX NWG is aligned with the 1305 basic proxy Mobile IPv4 operation as described in section 4 of this 1306 document. There are specific considerations for WiMAX NWG 1.0.0 use 1307 of proxy Mobile IPv4. These are listed below: 1309 1. Use of per MS SA for proxy Mobile IPv4 registration. In this 1310 case, MN-HA AE is used. 1312 2. Use of split PMA to handle FA relocation while PMIP Client 1313 remains anchored with the NAS (Authenticator ASN). 1315 3. Only the Proxy Mobile IPv4 Access Technology Type Extension 1316 defined in this document is used in NWG specification [NWG]. 1318 4. GRE key identifier is optionally used between the HA and the PMA. 1320 5. The PMIP Client and the FA interact via the WiMAX specific 1321 reference point and protocol (aka R4). For more information please 1322 refer to the NWG specification [NWG]. 1324 6. In order to handle inter ASN (inter Access Router) handover, and 1325 still allow the MN to use the same DHCP server's IP address that was 1326 sent in DHCPOFFER/ACK, the DHCP server (aka proxy) functions in the 1327 ASN is required to be configured with the same IP address. 1329 7. The MN - AR (trigger for proxy Mobile IPv4) interaction is based 1330 on DHCP. DHCPDISCOVER from the MN triggers proxy Mobile IPv4 process 1331 in the ASN. 1333 10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX 1335 Since the WiMAX uses split PMA model, the call flows involve WiMAX 1336 proprietary signaling between PMIP Client and FA within the PMA. The 1337 following call flows illustrate this. 1339 Proxy Handover Operation in WiMAX with Split PMA 1341 Split PMA 1342 +-----------------------------------+ 1343 +----+ | +------+ +------+ +-----+ | +-----+ 1344 | | | | NAS/ | | Old | | New | | | | 1345 | MN | | | PMIP | | FA | | FA | | | HA | 1346 | | | |Client| | | | | | | | 1347 +----+ | +------+ +------+ +-----+ | +-----+ 1348 | +----|------------|------------|----+ | 1349 | | | PMIP Tunnel | 1350 | | |<=======================>| 1351 | | | | | 1352 | | | R4 tunnel | | 1353 | | |<==========>| | 1354 | | 1 | | | 1355 |<---------------------------------->| | 1356 | | | | | 1357 | | | 2 | | 1358 | | |<---------->| | 1359 | | 3 | | | 1360 | |<----------------------- | | 1361 | | | | | 1362 | | 4 | | | 1363 +-> | |------------------------>| | 1364 | | | | | 5 | 1365 | | | | |----------->| 1366 | | | | | | 1367 PMIP | | | | | 6 | 1368 | | | | |<-----------| 1369 | | | | | | 1370 | | | 7 | | | 1371 +-> | |<------------------------| | 1372 | | | | | 1373 | | | 8 | | 1374 | | |<---------->| | 1375 | | | | | 1376 | 9 | | |PMIP Tunnel | 1377 Data |<---------------------------------->|<==========>| 1378 Forwarding | | | | | 1379 Figure 5: AR Handover in WiMAX 1381 In this scenario, the MN has moved to a new FA's area (known as Data 1382 Path Function in WiMAX). The old FA and the new FA interact with 1383 each other and also with the PMIP Client over WiMAX specified R4 1384 reference point to perform the handover. The steps are described 1385 below: 1387 1. The mobile device establishes L2 link with a base station (not 1388 shown) which connects to a new FA (aka new Data Path Function in 1389 WiMAX). Note that in this case, the MN does not perform 1390 authentication and authorization. The PMIP Tunnel remains between 1391 the Old FA (aka old Data Path Fucntion in WiMAX). The data flows 1392 through PMIP tunnel between the HA and the old FA and the WiMAX 1393 specific R4 tunnel between the old FA and the new FA and from new FA 1394 to the MN. 1396 2. The new FA interacts with the old FA using WiMAX specific R4 1397 reference point to initiate the handover process. 1399 3. The new FA uses the WiMAX specific R4 reference point to request 1400 the PMIP Client to begin the PMIP handover. 1402 4. Triggered by step 3 the PMIP Client sends an PRRQ to the new FA. 1403 The PRRQ contains the FA-CoA of the new FA. The Home Address field 1404 is set to the address the assigned IP address of the mobile node. 1405 The PRRQ is embedded in the WiMAX specific R4 packet. 1407 5. The new FA forwards the PRRQ to the HA. 1409 6. The home agent updates the existing mobility binding entry for 1410 the mobile device upon processing the PRRQ. The home agent responds 1411 back to the new FA with PRRP. 1413 7. The new FA forwards the PRRP after encapsulating it in a WiMAX 1414 specific R4 packet to the PMIP Client. 1416 8. The new FA and the old FA exchange WiMAX R4 specific messages 1417 between them to confirm the handover. The old FA cleans up it's 1418 resources for the MN. The R4 bearer forwarding also stops at this 1419 point. 1421 9. The forward and reverse direction traffic flows via the new FA. 1422 The handover is complete at this point. 1424 11. Proxy Mobile IPv4 Use Case in 3GPP2 1426 3GPP2 uses Proxy Mobile IPv4 scheme to provide mobility service for 1427 the following scenarios (as shown in the figures below): 1429 1. Mobility between the Base Station (BS) and Access Gateway (AGW) 1431 2. Mobility between the AGW and the Home Agent (HA). 1433 As shown in the diagrams below in use case 1, the BS acts as the PMA 1434 and the AGW acts as the HA for proxy Mobile IPv4 operation. In use 1435 case 2, the AGW acts as the PMA while the HA assumes the role of the 1436 home agent. 1438 RAN Core 1440 +-------+ +------+ 1441 +----+ | BS/ | PMIPv4 | | 1442 | MN |------| PMA |-----------------------| AGW/ | 1443 +----+ | | | HA | 1444 | | +------+ 1445 +-------+ 1447 Integrated PMA 1449 3GPP2's PMIP4 use case 1 - BS-AGW interface mobility 1451 RAN Core 1453 +-------+ +------+ 1454 +----+ | AGW/ | PMIPv4 | | 1455 | MN |------| PMA |-----------------------| HA | 1456 +----+ | | | | 1457 | | +------+ 1458 +-------+ 1460 Integrated PMA 1462 3GPP2's PMIP4 use case 2 - AGW-HA interface mobility 1464 The figure below shows a simplified 3GPP2 architecture. For details 1465 please refer to the 3GPP2 Converged Access Network (CAN) architecture 1466 ([3GPP2]). 1468 RAN Core 1469 -----------^------------ -------^------------- 1470 | | | | 1471 V V V V 1473 +------+ +------+ +-----+ 1474 +----+ | | PMIPv4 | | PMIPv4 | | 1475 | MN |------| BS |------------| AGW |-----------| HA | 1476 +----+ | | | | | | 1477 +------+ +------+ +-----+ 1479 The Proxy Mobile IPv4 usage scenario in 3GPP2 (case 1) is illustrated 1480 in the following diagram: 1482 +----+ +-------+ +-------+ +------+ 1483 | | | | | | | | 1484 | MN | | BS/ | | HAAA | | AGW/ | 1485 | | | PMA | | | | HA | 1486 +----+ +-------+ +-------+ +------+ 1487 | | | | 1488 | 1a | 1b | | 1489 |<------------->|<----------->| | 1490 | | | | 1491 | 2 | | | 1492 |-------------->| | | 1493 | | 3 | | 1494 | |----------------------->| 1495 | | | | 1496 | | 4 | | 1497 | |<-----------------------| 1498 | 5 | | | 1499 |<--------------| | | 1500 | | | | 1501 | 6 | | | 1502 |<======================================>| 1503 | | | | 1505 Network Connection Setup (use case 1) 1507 Description of the steps: 1509 1a. MN performs laye 2 establishment with the BS/PMA and performs 1510 access authentication/authorization. During this phase, the MN run 1511 EAP over UMB. The BS acts as the NAS in this phase. 1513 1b. The BS exchanges AAA messages with the home AAA server via the 1514 AR (not shown in the figure) to authenticate the MN. As part of this 1515 step, the AR may download some information about the MN (e.g. user's 1516 profile, handset type, assigned home agent address, and other 1517 capabilities of the MN). This information is passed to the PMA/BS 1518 (as necessary) to setup the PMIP tunnel in the next step(s). 1520 2. The MN sends layer 2 signaling messages to the BS/PMA to trigger 1521 the PMIP tunnel setup process. 1523 3. Triggered by step 2 the PMA/BS sends a PRRQ to the AGW/HA. The 1524 HA's address is either received at step 1b from the Home AAA server 1525 (HAAA) or discovered by other means. The PRRQ contains the Care-of 1526 Address (CoA) of the PMA (collocated FA in this case). The HoA field 1527 is set to all zeros (or all ones). The PRRQ is protected by the 1528 method described in this document. The derivation and distribution 1529 of the MN-HA or FA-HA key is outside the scope of this document. 1531 4. The AGW/HA registers the MN's session, assigns a symmetric GRE 1532 key and returns this key in the PRRP to the BS/PMA. 1534 5. The BS/PMA responds back to the MN with a layer 2 signaling 1535 message. 1537 6. At this step, the MN is assigned an IP address and is connected 1538 to the network (via the AGW). 1540 In use case 2 the same procedures are followed except the PMIPv4 1541 tunnel is established between the AGW and the HA. In this case GRE 1542 tunneling may not be used. 1544 11.1. HO considerations in 3GPP2 1546 There are some special handover considerations in 3GPP2's Proxy 1547 Mobile IPv4 use case. Below is an illustration of the specific use 1548 case: 1550 +----+ +-------+ +-------+ +-------+ 1551 | | | | | | | | 1552 | MN | | New | | AGW/ | | Old | 1553 | | | PMA/BS| | HA | | PMA/BS| 1554 +----+ +-------+ +-------+ +-------+ 1555 | | | | 1556 | | 1 | | 1557 | |------------->| | 1558 | | | | 1559 | | | | 1560 | | o 2 | 1561 | | | | 1562 | | | | 1563 | | 3 | | 1564 | |<-------------| | 1565 | | | | 1566 | | | | 1567 | | 4 | | 1568 | |<----------------------->| 1569 | | | | 1570 | | | | 1571 | | | o 5 1572 | | | | 1573 | | | | 1575 3GPP2 Registration Revocation for Previous PMA 1577 Description of the steps: 1579 1. MN attaches to the new BS (L2 gets established). There is an 1580 ongoing mobility binding entry (MBE) in the AGW for the MN. The PMA 1581 in the new BS sends a PRRQ to the AGW. 1583 2. The AGW receives a Proxy Registration Request for a Mobile Node 1584 and detects that it has an existing Mobility Binding Entry (MBE). 1585 The AGW validates the PRRQ from the new BS and it updates the MBE for 1586 the MN. The MBE is kept tentative at this point. 1588 3. The AGW sends Proxy Registration Reply to the new BS. No 1589 Registration Revocation is used in the 3GPP2's use case. 1591 4. A 3GPP2's proprietary PMA movement notification message may be 1592 exchanged between the AGW and the old BS. 1594 5. The MBE update with the new BS is committed at this step. 1596 12. IANA Considerations 1598 This specification registered 47 for the Proxy Mobile IPv4 Non- 1599 skippable Extension and 147 for Proxy Mobile IPv4 Skippable Extension 1600 in Section 5. The ranges for Mobile IPv4 [RFC3344] extension types 1601 are defined at http://www.iana.org/assignments/mobileip-numbers. 1602 This specification also creates a new subtype space for the type 1603 number of the extensions. The subtype value 1 is defined for the 1604 PMIPv4 Non-skippable Extension. The subtype values 1 to 4 are 1605 defined for the PMIPv4 Skippable Extension. Similar to the 1606 procedures specified for Mobile IPv4 number spaces, future 1607 allocations from the number space require expert review [RFC5226]. 1609 The PMIPv4 Per-Node Authentication Method Extension, defined in 1610 Section 5.1 of this document, introduces a new authentication method 1611 numbering space, where the values from 0 to 2 have been reserved by 1612 this document. Approval of new Access Technology type values are to 1613 be made through IANA Expert Review. 1615 The PMIPv4 Device ID Extension, defined in Section 5.3 of this 1616 document, introduces a new ID type numbering space, where the values 1617 from 0 to 4 have been reserved by this document. Approval of new 1618 Access Technology type values are to be made through IANA Expert 1619 Review. 1621 The PMIPv4 Subscriber ID Extension, defined in Section 5.4 of this 1622 document, introduces a new ID type numbering space, where the values 1623 from 0 to 1 have been reserved by this document. Approval of new 1624 Access Technology type values are to be made through IANA Expert 1625 Review. 1627 The PMIPv4 Access Technology Type Extension, defined in Section 5.5 1628 of this document, introduces a new technology type numbering space, 1629 where the values from 0 to 8 have been reserved by this document. 1630 Approval of new Access Technology type values are to be made through 1631 IANA Expert Review. 1633 12.1. Mobile IPv4 Extension Types 1635 This document introduces the following Mobile IP extension types. 1637 Name : Proxy Mobile IPv4 Non-skippable Extension 1638 Type Value : 47 1639 Section : 5 1641 Name : Proxy Mobile IPv4 Skippable Extension 1642 Type Value : 147 1643 Section : 5 1645 12.2. Mobile IPv4 Error Codes 1647 This document introduces the following error code that can be 1648 returned by the HA in a Proxy Registration Reply. 1650 Name Value First referenced 1651 ---- ----- ---------------- 1652 PMIP_UNSUPPORTED 149 8.1 1653 PMIP_DISALLOWED 150 8.1 1655 13. Security Considerations 1657 The functionality in this document is protected by the Authentication 1658 Extensions described in RFC 3344 [RFC3344] or IPSec [RFC4301]. Each 1659 PMA needs to have an security association (e.g. MN-HA, FA-HA, IPSec 1660 AH/ESP) with the HA to register the MN's IP address. The security 1661 association can be provisioned by the administrator, or dynamically 1662 derived. The dynamic key derivation and distribution for this scheme 1663 is outside the scope of this document. 1665 14. Acknowledgements 1667 The authors would like to thank the following individuals for their 1668 review, comments, and suggestions to improve the content of this 1669 document. 1671 Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj 1672 (Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree 1673 Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De 1674 Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia 1675 (Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann 1676 (Motorola), and Sri Gundavelli (Cisco). 1678 15. References 1680 [3GPP2] "3GPP2 Basic IP Service for Converged Access Network", 1681 X.S0054-100-0 Version 2.0, August 2008. 1683 [DSMIPv4] Tsirtsis, G., "Dual Stack Mobile IPv4", 1684 draft-ietf-mip4-dsmipv4-06.txt (work in progress), 1685 February 2008. 1687 [MIP4GREKEY] 1688 Yegani, P., "GRE Key Extension for Mobile IPv4", 1689 draft-yegani-gre-key-extensions-03.txt (work in progress), 1690 Jun 2007. 1692 [MIP4MCBC] 1693 Chakrabarti, S., "IPv4 Mobility extension for Multicast 1694 and Broadcast Packets", draft-chakrabarti-mip4-mcbc-02.txt 1695 (work in progress), Nov 2007. 1697 [NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed 1698 Protocols and Procedures) Release 1 Version 1.2.3", , 1699 Jul 2008. 1701 [RFC1305] Mills, D., "Network Time Protocol (Version 3) 1702 Specification, Implementation", RFC 1305, March 1992. 1704 [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol 1705 (IPCP)", RFC 1332, May 1992. 1707 [RFC1548] Simpson, W., "The Point-to-Point Protocol (PPP)", 1708 RFC 1548, December 1993. 1710 [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication 1711 Protocol (CHAP)", RFC 1994, August 1996. 1713 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1714 Requirement Levels", BCP 14, RFC 2119, March 1997. 1716 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", 1717 RFC 2131, March 1997. 1719 [RFC2484] Zorn, G., "PPP LCP Internationalization Configuration 1720 Option", RFC 2484, January 1999. 1722 [RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP, 1723 revised", RFC 3024, January 2001. 1725 [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1726 August 2002. 1728 [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in 1729 Mobile IPv4", RFC 3543, August 2003. 1731 [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. 1732 Levkowetz, "Extensible Authentication Protocol (EAP)", 1733 RFC 3748, June 2004. 1735 [RFC4058] Yegin, A., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, 1736 "Protocol for Carrying Authentication for Network Access 1737 (PANA) Requirements", RFC 4058, May 2005. 1739 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1740 Internet Protocol", RFC 4301, December 2005. 1742 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1743 RFC 4303, December 2005. 1745 [RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning, 1746 "Cisco's Mobile IPv4 Host Configuration Extensions", 1747 RFC 4332, December 2005. 1749 [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 1750 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006. 1752 [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting 1753 Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. 1755 [RFC5213] Gundavelli, S., Leung, K., Devarapalli, V., Chowdhury, K., 1756 and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. 1758 [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an 1759 IANA Considerations Section in RFCs", BCP 26, RFC 5226, 1760 May 2008. 1762 [RFCARP] Plummer, D., "An Ethernet Address Resolution Protocol", 1763 RFC 826, November 1982. 1765 [RFCICMP] Postel, J., "Internet Control Message Protocol", RFC 792, 1766 September 1981. 1768 Authors' Addresses 1770 Kent Leung 1771 Cisco Systems 1772 170 West Tasman Drive 1773 San Jose, CA 95134 1774 US 1776 Email: kleung@cisco.com 1778 Gopal Dommety 1779 Cisco Systems 1780 170 West Tasman Drive 1781 San Jose, CA 95134 1782 US 1784 Email: gdommety@cisco.com 1786 Parviz Yegani 1787 Cisco Systems 1788 170 West Tasman Drive 1789 San Jose, CA 95134 1790 US 1792 Email: pyegani@cisco.com 1794 Kuntal Chowdhury 1795 Starent Networks 1796 30 International Place 1797 Tewksbury, MA 01876 1798 USA 1800 Email: kchowdhury@starentnetworks.com 1802 Full Copyright Statement 1804 Copyright (C) The IETF Trust (2008). 1806 This document is subject to the rights, licenses and restrictions 1807 contained in BCP 78, and except as set forth therein, the authors 1808 retain all their rights. 1810 This document and the information contained herein are provided on an 1811 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1812 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1813 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1814 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1815 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1816 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1818 Intellectual Property 1820 The IETF takes no position regarding the validity or scope of any 1821 Intellectual Property Rights or other rights that might be claimed to 1822 pertain to the implementation or use of the technology described in 1823 this document or the extent to which any license under such rights 1824 might or might not be available; nor does it represent that it has 1825 made any independent effort to identify any such rights. Information 1826 on the procedures with respect to rights in RFC documents can be 1827 found in BCP 78 and BCP 79. 1829 Copies of IPR disclosures made to the IETF Secretariat and any 1830 assurances of licenses to be made available, or the result of an 1831 attempt made to obtain a general license or permission for the use of 1832 such proprietary rights by implementers or users of this 1833 specification can be obtained from the IETF on-line IPR repository at 1834 http://www.ietf.org/ipr. 1836 The IETF invites any interested party to bring to its attention any 1837 copyrights, patents or patent applications, or other proprietary 1838 rights that may cover technology that may be required to implement 1839 this standard. Please address the information to the IETF at 1840 ietf-ipr@ietf.org.