MIP4Network Working Group K. LeungInternet-DraftRequest for Comments: 5563 G. DommetyIntended status:Category: InformationalP. Yegani Expires: June 1, 2009Cisco Systems P. Yegani Juniper Networks K. Chowdhury Starent NetworksNov 28, 2008May 2009 WiMAXForum/3GPP2Forum / 3GPP2 Proxy Mobile IPv4draft-leung-mip4-proxy-mode-10.txtStatus ofthisThis MemoBy submitting this Internet-Draft, each author represents thatThis memo provides information for the Internet community. It does not specify an Internet standard of anyapplicable patent or other IPR claimskind. Distribution ofwhich he or shethis memo isaware have been or will be disclosed,unlimited. Copyright Notice Copyright (c) 2009 IETF Trust andanythe persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date ofwhich hepublication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. This document may contain material from IETF Documents orshe becomes aware will be disclosed,IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright inaccordance with Section 6some ofBCP 79. Internet-Drafts are working documentsthis material may not have granted the IETF Trust the right to allow modifications of such material outside theInternet Engineering Task Force (IETF), its areas, and its working groups. Note that other groupsIETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document mayalso distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six monthsnot be modified outside the IETF Standards Process, and derivative works of it may not beupdated, replaced, or obsoleted by other documents at any time. It is inappropriatecreated outside the IETF Standards Process, except touse Internet-Draftsformat it for publication asreference materialan RFC or tocite themtranslate it into languages other thanas "work in progress." The listEnglish. IESG Note This RFC is not a candidate for any level ofcurrent Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt.Internet Standard. ThelistIETF disclaims any knowledge ofInternet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expirethe fitness of this RFC for any purpose and in particular notes that the decision to publish is not based onJune 1, 2009.IETF review for such things as security, congestion control, or inappropriate interaction with deployed protocols. The RFC Editor has chosen to publish this document at its discretion. Readers of this document should exercise caution in evaluating its value for implementation and deployment. See RFC 3932 for more information. Abstract Mobile IPv4 is a standard mobility protocol that enables an IPv4 device to move among networks while maintaining its IP address. The mobile device has the Mobile IPv4 client function to signal its location to the routing anchor, known as the Home Agent. However, there are many IPv4 devices without such capability due to various reasons. This document describes Proxy Mobile IPv4 (PMIPv4), a scheme based on having the Mobile IPv4 client function in a network entity to provide mobility support for an unaltered and mobility-unaware IPv4 device. This document also describes a particular application of PMIPv4 as specified in the WiMAX Forum and another application that is to be adopted in 3GPP2. Table of Contents 1. Introduction. . . . . . . . . . . . . . . . . . . . . . . . . 4....................................................3 2. ConventionsusedUsed inthis document . . . . . . . . . . . . . . 4This Document ...............................4 3. Benefits of Proxy Mobile IPv4. . . . . . . . . . . . . . . . 6...................................6 4. Overview of Proxy Mobile IPv4. . . . . . . . . . . . . . . . 8...................................7 4.1. Mobility Signaling for Mobile Device. . . . . . . . . . . 8.......................7 4.1.1. Proxy Registration during Initial Network Attachment. . . . . . . . . . . . . . . . . . . . . . 9..........................................8 4.1.2. Proxy Registration Renewal. . . . . . . . . . . . . . 11.........................11 4.1.3. Proxy Handover Support. . . . . . . . . . . . . . . . 12.............................12 4.1.4. Resource Cleanup. . . . . . . . . . . . . . . . . . . 14...................................13 4.2. Establishment of a Bi-Directional Tunnel. . . . . . . . . . 14..................14 4.2.1. Packet Forwarding. . . . . . . . . . . . . . . . . . 15..................................14 4.2.2. Broadcast and Multicast. . . . . . . . . . . . . . . 15............................14 4.2.3. ForwardingBetweenbetween Devices onsamethe Same PMA. . . . . . . . 15.........15 4.3. Security AssociationBetweenbetween the PMA and the HA. . . . . 16...........15 4.4. Registration Sequencing. . . . . . . . . . . . . . . . . 16...................................15 4.5. Mobile Device Interface Configuration. . . . . . . . . . 17.....................16 4.6. Dynamic HA Discovery. . . . . . . . . . . . . . . . . . . 17......................................16 5. Proxy Mobile IPv4 Extensions. . . . . . . . . . . . . . . . . 17...................................16 5.1. PMIPv4 Per-Node Authentication Method Extension. . . . . 17...........17 5.2. Proxy Mobile IPv4 Interface ID Extension. . . . . . . . . 18..................18 5.3. Proxy Mobile IPv4 Device ID Extension. . . . . . . . . . 19.....................18 5.4. Proxy Mobile IPv4 Subscriber ID Extension. . . . . . . . 20.................19 5.5.PMIPPMIPv4 Access Technology Type Extension. . . . . . . . . . 21...................20 6. Appearance of Being at Home Network. . . . . . . . . . . . . 23............................22 6.1. ARP Considerations. . . . . . . . . . . . . . . . . . . . 23........................................22 6.2. ICMP Considerations. . . . . . . . . . . . . . . . . . . 23.......................................23 6.3. DHCP Considerations. . . . . . . . . . . . . . . . . . . 24.......................................23 6.4. PPP IPCP Considerations. . . . . . . . . . . . . . . . . 25...................................24 6.5. Link-Local Multicast and Broadcast Considerations. . . . 25.........24 7. Proxy Mobility Agent Operation. . . . . . . . . . . . . . . . 25.................................24 8. Home Agent Operation. . . . . . . . . . . . . . . . . . . . . 26...........................................25 8.1. Processing Proxy Registration Requests. . . . . . . . . . 27....................26 9. Mobile Device Operation. . . . . . . . . . . . . . . . . . . 27........................................26 9.1. Initial Network Access. . . . . . . . . . . . . . . . . . 28....................................27 9.2. Mobile Device Mobility. . . . . . . . . . . . . . . . . . 28....................................27 9.3. Sending and ReceivingPacket . . . . . . . . . . . . . . . 28Packets .............................27 10. Proxy Mobile IPv4 Use Case in WiMAX. . . . . . . . . . . . . 29...........................28 10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX. . . . . . . . . . . . . . . . . . . . . . . . . . 32.............................................31 11. Proxy Mobile IPv4 Use Case in 3GPP2. . . . . . . . . . . . . 34...........................33 11.1.HO considerationsHandover Considerations in 3GPP2. . . . . . . . . . . . . . . . 36.........................36 12. IANA Considerations. . . . . . . . . . . . . . . . . . . . . 38...........................................37 12.1. Mobile IPv4 Extension Types. . . . . . . . . . . . . . . 39..............................38 12.2. Mobile IPv4 Error Codes. . . . . . . . . . . . . . . . . 39..................................38 13. Security Considerations. . . . . . . . . . . . . . . . . . . 39.......................................38 14. Acknowledgements. . . . . . . . . . . . . . . . . . . . . . . 39..............................................38 15. References. . . . . . . . . . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 42 Intellectual Property and Copyright Statements . . . . . . . . . . 43....................................................39 15.1. Normative References .....................................39 15.2. Informative References ...................................39 1. Introduction There are many IPv4 deviceswhichthat do not have or cannot be enabled with Mobile IPv4 [RFC3344] functionality. Yet, mobility for them is essential. Proxy Mobile IPv4 provides mobility support without "touching" these devices. The scheme is based on network entitieswhichthat perform themobility managementmobility-management function for a mobile device. The location of the device is signaled by the network element on the access network (referred to as the Proxy MobilityAgent)Agent (PMA)) to inform the networkentitiyentity on the home network (referred to as the HomeAgent)Agent (HA)) associated with the IPv4 address used by the device. Mobile IPv4 messaging is used by the PMA and HA, which correspond to the RFC 3344 entities Mobile Node (in proxy mode) and Home Agent, respectively. These are some examples of Proxy Mobile IPv4: 1. AWLANWireless Local Area Network (WLAN) access point or cellular base station performs registration with the Home Agent when a mobile device is associated on the air-link. 2. An access router or Foreign Agent performs registration with the Home Agent when a mobile device is detected on the network. Mobile IPv4 is used by the network entities because the mobility protocol has the functions needed to set up the route and tunneling endpoints for the mobile device's IP address and to deliver configuration parameters(e.g.(e.g., DNS server addresses, default gateway) for enabling the mobile device's IP stack. When Mobile IPv4 is used in this way, the security association is between the PMA and the HA because these entities are the signaling endpoints. Also, when the mobile device moves to a new PMA, the sequencing of messages sourced from multiple PMAs needs to be handled properly by the HA. This document describes how the network entities, PMA and HA, provide mobility management for the mobile device. It is organized to cover the generic functionality of Proxy Mobile IPv4 and also the specifics pertaining to WiMAX (Section 10) and 3GPP2 (Section 11). Note that Proxy Mobile IPv6 [RFC5213] is an IETF standard for network-based mobility management that enables IP mobility for a host without requiring its participation in any mobility-related signaling. 2. ConventionsusedUsed inthis documentThis Document The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The following new terminology and abbreviations are introduced in thisdocument anddocument; all other generalmobility relatedmobility-related terms are as defined in Mobile IPv4 specification [RFC3344]. Mobile Device The mobile device is used to refer to an IPv4 device with its mobility provided by the network. The mobile device is not required to participate in anymobility relatedmobility-related signaling for achieving mobility for an obtained IP address. Proxy Mobile IPv4 Client(PMIP(PMIPv4 Client) This network function is responsible for initiating and maintaining theproxyProxy Mobile IPv4 registration on behalf of the mobile device. Essentially, it performs the Mobile IPv4 client function butitis hosted in the network. In some cases, this function is collocated with the ForeignAgent andAgent; inothersothers, it is not. In both cases,proxyProxy Mobile IPv4 registration still goes via the Foreign Agent at all practicaleffectseffects, even if it is internal to the node. Home Agent (HA) The Home Agent that is defined in Mobile IPv4 [RFC3344] is used in the Proxy Mobile IPv4 scheme. It is the topological anchor point for the mobile device's home network and is the entity that manages the mobile device'sreach-abilityreachability state. The additional capabilities for supporting Proxy Mobile IPv4 in the Home Agent are defined in this document. Foreign Agent (FA) The Foreign Agent that is defined in [RFC3344] is used in the Proxy Mobile IPv4 scheme. It is either collocated with or separate from thePMIP Client.PMIPv4 client. It serves the purpose of tunnelend-pointendpoint from Proxy Mobile IPv4 perspective. Access Router (AR) Access Router is a commonly used term that refers to the node in the networkwhichthat connects the hosts to the IP network. Proxy Mobility Agent (PMA) Proxy Mobility Agent is the logical entity in the network that encompasses both thePMIP ClientPMIPv4 client and the FA functions. ThePMIP ClientPMIPv4 client and the FA collocation in the Access Router constitute an integrated PMA. When thePMIP ClientPMIPv4 client and the FA functions are not collocated in the Access Router, it is referred to as a split PMA. APMIPPMIPv4 client may have association with multiple FAs, and vice versa. Proxy Registration Request (PRRQ) The Registration Request message is sent by the Proxy Mobility Agent to the Home Agent in order to set up a mobility binding entry for a mobile device. The message format is identical to that of the Mobile IPv4 Registration Request, though the Proxy Mobile IPv4 extensions that are defined in this document may be included for enhanced features of network-based mobility management. Proxy Registration Reply (PRRP) The Registration Reply message is sent by the Home Agent in response to the Proxy Registration Request received from the Proxy Mobility Agent. The message format is identical to that of the Mobile IPv4 Registration Reply, though the Proxy Mobile IPv4 extensions that are defined in this document may be included for enhanced features of network-based mobility management. 3. Benefits of Proxy Mobile IPv4 Proxy Mobile IPv4(PMIP)(PMIPv4) is designed to satisfy the requirements listed below. In addition, while this specification and Proxy Mobile IPv4 are not standards, they employ astandard,standard: Mobile IPv4. Implementations of Mobile IPv4 can be re-used(i.e.(i.e., a client-based mobility protocol can be used "as-is" to support network-based mobility). However, new PMIPv4 extensions that are added to Mobile IPv4 improves the flexibility of the solution. The practical advantage of having a common mobility protocol for both client-based and network-based mobility is that a Home Agent can anchor all types of mobile devices, both ones that haveor othersand ones that lack the Mobile IPv4 function. The network-based mobility management solution defined in this document has the following significant reasons for its use in any wireless network: 1. Support for Unmodified Hosts An overwhelming majority of IPv4 hosts do not have Mobile IPv4 capability. Providing mobility for them is achievable using Proxy Mobile IPv4. This is accomplished without "touching" the user's devices by running on a myriad of operating systems and networking stacks. 2.Re-useRe-Use of Existing Home AgentExistingAn existing Home Agent implementation can be used for network- based mobility as well. Further enhancements are optional and only incremental in nature. There are many commonalities between client-based and network-basedmobilitymobility, and sharing the same protocol is a significant benefit. 3. Reduction ofAir-linkAir-Link Resource Consumption Mobility-related signaling over the air-link is eliminated. 4. Support for Heterogeneous Wireless Link Technologies Since Proxy Mobile IPv4 is based on anaccess technology independentaccess, technology- independent, mobility protocol, it can be used for any type of access network. From the network perspective, a mobile device is identified by theNAINetwork Access Identifier (NAI) and the forwarding is set up between the PMA and HA for the mobile device's current point of attachment on the network. The mobile device may be attached to multiple networks concurrently, although the network treats each access interface independently. This feature can be supported with the use of thePMIPPMIPv4 Access Technology Type Extension (Section 5.5). 5. Support for IPv4 and IPv6HostHosts As IPv6 increases in popularity, the host will likely be dual stack. Adding IPv6 support to the host for Proxy Mobile IPv4 involves the methods defined in[DSMIPv4].[RFC5454]. There are additional enhancementsneededneeded, which are described inProxy"Proxy MobileIPv6IPv6" [RFC5213]. However, support for an IPv6 host is out ofscope.the scope of this document. 4. Overview of Proxy Mobile IPv4 4.1. Mobility Signaling for Mobile Device After the mobile device completesnetwork accessnetwork-access authentication, the PMA exchangesproxyProxy Mobile IPv4 registration messages with the HA to set up proper routing and tunneling of packets from/to the Mobile Node. ThePMIP ClientPMIPv4 client is responsible for initiating theproxyProxy Mobile IPv4 registration. For integrated PMA, thePMIP ClientPMIPv4 client and the FA interaction is all within the node. In the case of split PMA implementation, the interactions between thePMIP ClientPMIPv4 client and the FA are exposed. The interface between the PMIP Client and the FA in the split PMA scenario is defined in a standards organization specification(e.g. WiMAX R4 reference point)[NWG] and is consequently out of the scope of this document. The following call flows describe the operations of Proxy Mobile IPv4. The initial network attachment, registration renewal, and resource cleanup procedures are covered. Note that the protocolswhichthat interact with Proxy Mobile IP are identified and explained in moredetails.detail. The PPP/IPCP (IP Control Protocol) protocol involves a PPP client in the mobile device andNASa Network Access Server (NAS) in the AR. DHCPprotocolinvolves a DHCPClientclient in the MN and a DHCPServerserver in either the AR or the HA.PMIP protocolPMIPv4 involves a PMA in the AR and an HA in the router on the home network.AAAThe Authentication, Authorization, and Accounting (AAA) protocol involves a AAAClientclient in the AR and a AAAServerserver in the network. Thecolocationcollocation of the functional entities in the AR/HA enables parameters to be shared/processed among the protocols. When the various network entities are not collocated, any sharing of parameters or other state information between them is out of the scope of thisdraft.document. 4.1.1. Proxy Registration during Initial Network Attachment +----+ +-------+ +-------+ +-----+ | | | AR / | | | | | | MN | | PMA | | AAA | | HA | | | | | | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1a | 1b | | Authentication |<------------->|<----------->| | | | | | | 2 | | | +-> |-------------->| | | | | | 3 | | | | |-------------------------->| <-+ Address | | | | || PMIP Acquisition ||PMIP Acquisition| | | 4 | | | | | |<--------------------------| <-+ | | 5 | | | +-> |<--------------| | | | | | | | 6 | | | Data Forwarding |<------------->|<=========================>| | | | | Figure 1: Network Connection Setup The initialnetwork attachmentnetwork-attachment procedure is described below. There are three distinct phases. First, authentication and authorization happen when the mobile device accesses the network.ThenThen, the mobile device attempts to obtain an IP address. This triggers Proxy MobileIPIP, which assigns/authorizes the IP address and sets up forwarding between the PMA and HA. The host configuration parameters may be passed in thePMIPPMIPv4 signaling. Finally, the mobile device configures its IP stack with the IP address and the obtained host configuration. Packets to and from the mobile device transit both the PMA and HA. 1a. The mobile device establishes a L2 (Layer 2) link with the base station (not shown) and performs access authentication/authorization with the AR (Access Router). During this phase, the mobile device may runCHAPeither the Challenge Handshake Authentication Protocol (CHAP) [RFC1994] if PPP[RFC1548][RFC1661] is used orEAPthe Extensible Authentication Protocol (EAP) [RFC3748] over foo (foo being the specific accesstechnologytechnology, or PANA [RFC4058]). The AR acts as the NAS (Network Access Server) in this step. 1b. The AAA client exchanges AAA messages with the AAA infrastructure to perform authentication and authorization of the mobile device. As part of this step, the AAA server may download some information about the mobile device(e.g.(e.g., the user's profile, handset type, assignedhome agentHome Agent address, and other capabilities of the mobile device). 2. The mobile device requestsforan IP address viaana PPP/IPCP [RFC1332] or DHCP [RFC2131]. Specifically for PPP, the PPP client sends an IPCP Configure-Request to the NAS. As for DHCP, the DHCP client sends the DHCP Discover message to the DHCP relay agent/ server. For the DHCP case, the DHCP server or DHCP relay agent sends the DHCP Ack message to the DHCP client after PMIPv4 signalinghadhas completed. 3. Triggered by step 2, the PMA sendsana Proxy Registration Request (PRRQ) to the HA. The HA's IP address is either obtained from the AAA server at step 1b or discovered by some other method. The PRRQ contains the Care-of Address (CoA) of the PMA(collocated(the collocated FA in this case). The Home Address field is set to zero or the IP address is specified as a hint in the DHCP or IPCP message. The PRRQ MUST be protected by the methods described in the Security Considerations (Section13).13) of this document. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document. 4. Thehome agentHome Agent sets up the mobility binding entry for the mobile device after assigning an IP address or authorizing the requested Home Address. Thehome agentHome Agent may also assign aGREGeneric Routing Encapsulation (GRE) key in this step (if GRE tunneling is used between the PMA and HA). The HA returns the HomeAddress,Address and the GRE key (if applicable) in the Proxy RegistrationRequestReply (PRRP) to the PMA. If the requested Home Address is not authorized, thehome agentHome Agent denies the registration with error code 129 (administratively prohibited). After the PMA processes the PRRP, the forwarding path for the Home Address between the PMA and HA is established. A GRE tunnel may be used between the PMA and the HA [MIP4GREKEY].TheThis event completes the Proxy Mobile IPv4 signaling for initial network attachment. 5. After the Proxy Mobile IPv4 registration exchange, the AR provides the IP address to the mobile device in response to step 2. For IPCP, the NAS replies to the PPP client with an IPCPConfigure-NakConfigure-Nak, which includes thePMIP assignedPMIPv4-assigned Home Address in theIP-AddressIP address configuration option and the DNS server address in the IPCP configuration option. The following procedure happens when the DHCP server is on the AR. The DHCP server sends a DHCP Offer with thePMIP assignedPMIPv4-assigned Home Address in the yiaddr field to the DHCP client. The DHCP client sends a DHCP Request to the DHCP server, which replies with a DHCP Ack. The host configurationsuch(such as the DNS serveraddressaddress) is included in the DHCP options in the message. Note that the DHCP messages are exchanged directly between the DHCP client and the DHCP server. In the case when AR acts as a DHCP relay agent, the DHCP Discover is relayed to the DHCP server on the HA. The DHCP server sends a DHCP Offer with thePMIP assignedPMIPv4-assigned Home Address in the yiaddr field to the DHCP relay agent, which forwards it to the DHCP client. The DHCP Request and DHCP Ack messages are exchanged between the DHCP client and DHCP server via the DHCP relay agent. Regardless of the sequence ofPMIPPMIPv4 signaling and DHCP exchanges, the interaction betweenPMIPPMIPv4 and DHCP involves in the same IP address for Home Address field and yiaddr field, respectively. 6. At this step, the mobile device's IP stack is configured with an IP address that has a forwarding path between the AR/PMA and HA. Also, the host configurationsuch(such as DNSserversservers) is configured at this time. Now that the IPCP or DHCP procedure has completed, the mobile device is ready to receive or send IP packets. If DHCP is used, the DHCP client renews the IP address by sending a DHCP Request directly to the DHCP server. The lease for the IP address is extended when a DHCP Ack from the DHCP server is received by the DHCP client. 4.1.2. Proxy Registration Renewal +----+ +-------+ +-----+ | | | AR / | | | | MN | | PMA | | HA | | | | | | | +----+ +-------+ +-----+ | | | | | 1 | | |----------------------->|PMIPPMIPv4 | | | Renewal | | 2 | | |<-----------------------| | | | | | | Figure 2: Network Connection Maintenance Thenetwork connectionnetwork-connection maintenance procedure is described below. As long as the mobile device remains attached to the AR, the Proxy Mobile IPv4 session is maintained by re-registrationexchangeexchanges between the AR and HA. 1. Before thePMIPPMIPv4 registration lifetimeexpiresexpires, and assuming the AR has not received any indication that the mobile device detached from the network, the PMA sends a PRRQ to the HA to extend the duration of the mobility binding of the mobile device.TheThis PRRQ is similar to the initial PRRQ(i.e.(i.e., HA field set to the assignedHAHA, and CoA field set to the PMA), though the Home Address field is always set to the assigned IP address of the mobile device. The mobile device's IP stack can continue to send and receive IP packets using the Home Address anchored at the HA. 2. The HA sends the PRRP in response to the PRRQ received from the PMA. After the PMA processes the PRRP, the forwarding path between AR and HA remains intact. 4.1.3. Proxy Handover Support +----+ +-------+ +-------+ +-----+ | | | New | | Old | | | | MN | | AR / | | AR / | | HA | | | | PMA | | PMA | | | +----+ +-------+ +-------+ +-----+ | | | | | 1 | | | Authentication |<------------->| | | | | | | | | 2 | | +-> | |-------------------------->|PMIPPMIPv4 | | | | | | | | 3 | | +-> | |<--------------------------| | | | | | 4 | | | Data Forwarding |<------------->|<=========================>| | | | | Figure 3: AR Handover The AR handover procedure is described below. There are three phases. First, authentication and authorizationhappenshappen when the mobile device attaches to the new AR in the network. The successful authentication triggers the Proxy Mobile IPv4 signaling. In the last phase, the forwarding path between the new AR and HA is set up for the mobile device to send and receive IP packets using the same Home Address anchored at the HA. 1. The mobile device establishes L2 link with the base station (not shown) and performs access authentication/authorization with the newARAR, using the security method for network re-attachment. 2. Triggered by successful authentication, the PMA sendsana PRRQ to the HA. The HA's IP address is typically obtained or is knowntypicallyby the method used for fastreauthenticationre-authentication during AR handover(e.g.(e.g., context transfer between the twoARs). ThoughARs), though other methods may be used. The PRRQ contains the CoA of the new PMA. The Home Address field is set to zero or the assigned IP address of the mobile device. The IP address is also obtained/known by the same method mentioned before. 3. Thehome agentHome Agent updates the existing mobility binding entry for the mobile device upon processing the PRRQ. Thehome agentHome Agent returns the Home Address, fetched from the binding, in the PRRP to the new PMA. After the PMA processes the PRRP, the forwarding path for the Home Address between the new AR and HA is established. The event completes the Proxy Mobile IPv4 signaling for AR handover. 4. At this step, which happens around the same time as step 2, the mobile device's IP stack may detect L2 link going down and up after access re-authentication. The mobile device's IP stack may attempt to validate its IP address connectivity. SeeARP ([RFCARP]) SectionSections 6.1,ICMP ([RFCICMP]) Section 6.26.2, andDHCP ([RFC2131]) Section6.3considerationsof this document fordetails.considerations on ARP [RFCARP], ICMP [RFCICMP], and DHCP [RFC2131], respectively. Because the forwarding path is established between the new PMA and HA, the mobile device can receive or send IP packets using the Home Address. 4.1.4. Resource Cleanup +----+ +-------+ +-------+ +-----+ | | | New | | Old | | | | MN | | AR / | | AR / | | HA | | | | PMA | | PMA | | | +----+ +-------+ +-------+ +-----+ | | | | | | | 1 | +-> | | |<------------| | | | | | Revocation | | | o 2 | | | | | | | | | | 3 | +-> | | |------------>| | | | | Figure 4: Registration Revocation for Previous PMA The resource cleanup procedure for the old AR is described below. This cleanup is necessary when the old AR needs to delete itsPMIPPMIPv4 and other associated states forthea mobile device that has moved to another AR. Therefore, this is an optional procedure for Proxy Mobile IP. The alternative method is based on the new PMA notifying the old PMA to clean up resources.ThisThe alternative method is out of the scope of this document. 1. Triggered by the update of the mobility binding entry for a mobile device that has moved to a new AR, the HA may send a Registration Revocation (as specified in RFC 3543 [RFC3543]) to the old PMA(i.e.(i.e., specifically to the Foreign Agent entity) in order to clean up unused resources in an expeditious manner. 2. The old PMA removes thePMIPPMIPv4 states for the mobile device. 3. The old PMA sends revocation acknowledgement to the HA. 4.2. Establishment of a Bi-Directional Tunnel The PMA and HA set up a tunnel between them for the Home Address after thePMIPPMIPv4 registration message exchange. 4.2.1. Packet Forwarding The bi-directional tunnel between the PMA and the HA allows packets to flow in both directions, while the mobile device is connected on the visited network. All traffic to and from the mobile device travels through this tunnel. While the PMA is serving a mobile device, it MUST be able to intercept all packets sent from the mobile device and forward them out the tunnel created for supporting that mobile device. Typically, forwarding is based onLayerlayer 2 information such as the sourceMACMedia Access Control (MAC) address or ingress interface. This allows overlapping IP addresses to be supported for the packet from the mobile device. For example, the PMA forwards packets from mobile devices with the same IP addressare forwardedto the tunnel associated with eachmobile device by the PMAmobile device, based on the source MAC address.AnyThe PMA de-encapsulates any packets received on the tunnel fromHA,thePMA de-encapsulatesHA before forwarding to the mobile device on its link. Typically, the forwarding is based on the destination IP address and ingress HA tunnel (which may have a GREKey).key). This allows overlapping IP addresses to be supported for the packet destined to the mobile device. For example, the PMA forwards packets to mobile devices with the same IP addressare forwardedto the link associated with each mobiledevice by the PMAdevice, based on the GREKeykey value of the tunnel created for the HA that serves these mobile devices. The tunnel operation between the PMA and HA is the same as between the FA and HA in RFC 3344. The IPTTL,TTL (Time to Live), fragmentation, re-assembly, etc. logic remain the same. The tunnel mode is IPinIP by default or GRE as an option. 4.2.2. Broadcast and Multicast Broadcast packet processing for DHCP and ARP (Address Resolution Protocol) messages are described in Section 6.3 and Section 6.1, respectively. For other types of broadcast packets, the PMA and HA process them in accordance to [RFC3344], [RFC3024], and [MIP4MCBC]. Only the Direct Encapsulation Delivery Style issupportedsupported, as there is no encapsulation for the packets between the mobile device and PMA. 4.2.3. ForwardingBetweenbetween Devices onsamethe Same PMA When the communication peers are both attached to the same PMA, the packet is forwarded as specified in Section 4.2.1. The traffic between themareshould be routed via the HA without taking a local shortcut on the PMA. This ensures thatdata trafficdata-traffic enforcement at the HA is not bypassed. 4.3. Security AssociationBetweenbetween the PMA and the HA The security relationship for protecting the control message exchanges between the PMA and the HA may be either per node(i.e.(i.e., same security association for all mobile devices) or per MN(i.e.(i.e., unique security association per mobile device). The method of obtaining the security association is outsideofthe scope of this document. Forper nodeper-node SA support, the FA-HA AuthenticationExtensionextension orIPSecIPsec (indicated in the PMIPv4 extension) is used to authenticate the signaling messages (including Registration Revocation [RFC3543]) between PMA and HA. In the case ofIPSec,IPsec, Encapsulating Security Payload (ESP) [RFC4303] in transport mode with mandatory integrity protection should be used. TheIPSecIPsec endpoints are the IP addresses of the PMA and HA. Forper MNper-MN SA support, the MN-HA AuthenticationExtensionextension and/orMN-AAAMN- AAA AuthenticationExtensionextension are used to authenticate the signaling. The creation of the security association may be assisted by the AAA server at the time of access authentication. 4.4. Registration Sequencing The Identification field in the registration message provides replay protection and sequencing when the timestamp method is used. This mechanism allows the HA to know the sequence of messages from the same PMA or different PMAs based on the Identification field. The HA can also synchronize the PMA's clock by using the Identification mismatch error code in theproxy registration reply.Proxy Registration Reply. This reply message would not be necessary when the PMA's clocks are synchronized using the Network Time Protocol [RFC1305] or some other method. Note that the use of nonce for sequencing and replay protection is outside the scope ofscope.this document. The method above is sufficient when there is a single source for signaling as in the split PMA case.HoweverHowever, in the integrated PMA case, theproxy registration requestProxy Registration Request is sent from different sources(i.e.(i.e., different PMAs). If the previous PMA is unaware that the mobile device has moved away and continues to send re-registration, then the HA would be misinformed on the location of the device. Therefore, an integrated PMA MUST confirm that the mobile device is still attached before sending aproxy registration request.Proxy Registration Request. Notethatthat, for the split PMA model as used in WiMAXForum, seeForum (see Section10,10), thePMIP ClientPMIPv4 client remains anchored duringhandover, seehandover (see Section10.1.10.1). In this case, thePMIP ClientPMIPv4 client is the only source of the PRRQ. However, there are casessuch(such asPMIP ClientPMIPv4 client relocation and uncontrolled handovereventevents) when more than one PMA performs registration. The same method for the integrated PMA is used to ensure proper sequencing of registration on the HA. 4.5. Mobile Device Interface Configuration Typically, the mobile device's interface needs to be configured with an IP address, network prefix, default gateway, and DNS server addresses before the network connection can be enabled to be used for communication. For some IP stacks, the default gateway IP address has to be on the same subnet as the mobile device's IP address. When the Home Agent's IP address is not on the same subnet as the Home Address,the vendor specificvendor-specific extensions(e.g.(e.g., [RFC4332]) or other methods MAY be used by the PMA to obtain the default gateway. 4.6. Dynamic HA Discovery The PMA can perform dynamic HA discovery by sending the registration with Home Agent field set to 0.0.0.0 or 255.255.255.255. The Home Agent responds with its IP address in the Home Agent field as specified in "Mobile IPv4 DynamicHA AssignmentHome Agent (HA) Assignment" [RFC4433]. 5. Proxy Mobile IPv4 Extensions The following PMIPv4 extensions are not required for base functionality but may be used in some cases where such features are applicable. They are included before the authentication extension(e.g.(e.g., MN-HA or FA-HAauthenticationAuthentication extension) in the registration message. 5.1. PMIPv4 Per-Node Authentication Method Extension The Proxy Mobile IPv4 Authentication Method extension indicates alternative methods for authenticating the registration besides the default MN-HA AuthenticationExtensionextension as specified in RFC 3344. This extension MUST be included in the Registration Request and Registration Reply when the security association for authenticating the message is between the PMA and HA on aper nodeper-node basis. This means that a common key or set of keys (indexed by the SPI) are used for message authentication by the PMA and HA. The key is independent of the mobiledevicedevice, which is identified in the registration. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Sub-Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Method | +-+-+-+-+-+-+-+-+ PMIPv4 Per-Node Authentication Method Extension Type 47 (Proxy Mobile IPv4Non-skippableNon-Skippable Extension) Sub-Type 1 (PMIPv4 Per-Node Authentication Method) Length 1 Method An 8-bit field that specifies the authentication type for protecting the signaling messages. The values (0 - 255)will beare allocated and managed by IANA. The following valuesare currently reserved forhave been assigned to thebelowspecified method types. 0: Reserved 1: FA-HA Authentication 2:IPSecIPsec Authentication 5.2. Proxy Mobile IPv4 Interface ID Extension The Proxy Mobile IPv4 Interface ID extension identifies the interface address of the device used to attach to the network. The information MAY be included in the Registration Request when the PMA is aware of it. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PMIPv4 Interface ID Extension Type 147 (Proxy Mobile IPv4 Skippable Extension) Length The length of the extension in octets, excluding Type and Length fields. Sub-Type 1 (PMIPv4 Interface ID) Identifier A variable-length octet sequence that contains an identifier of the interface. 5.3. Proxy Mobile IPv4 Device ID Extension The Proxy Mobile IPv4 Device ID extension identifies the device used to connect to the network. The information MAY be included in the Registration Request when the PMA is aware of it. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | ID-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PMIPv4 Device ID Extension Type 147 (Proxy Mobile IPv4 Skippable Extension) Length The length of the extension in octets, excluding Type and Length fields. Sub-Type 2 (PMIPv4 Device ID) ID-Type An 8-bit field that specifies the device ID type. The values (0 - 255)will beare allocated and managed by IANA. The following valuesare currently reserved forhave been assigned to thebelowspecified device ID types. 0: Reserved 1: Ethernet MAC address 2: Mobile Equipment Identifier (MEID) 3: International Mobile Equipment Identity (IMEI) 4: Electronic Serial Number (ESN) Identifier A variable-length octet sequence that contains an identifier of the type indicated by the ID-Type field. 5.4. Proxy Mobile IPv4 Subscriber ID Extension The Proxy Mobile IPv4 Subscriber ID extension identifies the mobile subscription. The information MAY be included in the Registration Request when the PMA is aware of it. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | ID-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ PMIPv4 Subscriber ID Extension Type 147 (Proxy Mobile IPv4 Skippable Extension) Length The length of the extension in octets, excluding Type and Length fields. Sub-Type 3 (PMIPv4 Subscriber ID) ID-Type An 8-bit field that specifies the subscriber ID type. The values (0 - 255)will beare allocated and managed by IANA. The following valuesare currently reserved forhave been assigned to thebelowspecified subscriber ID types. 0: Reserved 1: International Mobile Subscriber Identity (IMSI) Identifier A variable-length octet sequence that contains an identifier of the type indicated by the ID-Type field. 5.5.PMIPPMIPv4 Access Technology Type Extension The Proxy Mobile IPv4 Access Technology Type extension indicates the type ofradio accessradio-access technology on which the mobile device is attached. This extension MAY be included in the Registration Request when the PMA is aware of the information. The HA can provide mobility on the same access technology type for a mobile device with multipleinterfacesinterfaces, assuming each interface is connected on a different access technology type. The HA does not include the extension in the associated Registration Reply. 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Sub-Type | Tech-Type | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+PMIPPMIPv4 Access Technology Type Extension Type 147 (Proxy Mobile IPv4 Skippable Extension) Length 2 Sub-Type 4 (Access Technology Type) Tech-Type An 8-bit field that specifies the access technology through which the mobile device is connected to the access network. The values (0 - 255)will beare allocated and managed by IANA. The following valuesare currently reserved forhave been assigned to thebelowspecified access technology types. 0: Reserved 1: 802.3 2: 802.11a/b/g 3: 802.16e 4: 802.16m 5: 3GPP EUTRAN/LTE 6: 3GPP UTRAN/GERAN 7: 3GPP2 1xRTT/HRPD 8: 3GPP2 UMB 6. Appearance of Being at Home Network Since the Mobile Node is not aware of its mobility and does not participate in handover signaling, the network entities emulate the home network to the mobile device attached on the network. From the mobile device's perspective, it operates as if itiswere at the home network. However, the network is directing the mobile device's traffic to and from its current location and will continue to do so when it moves to a new location. An unmodified mobile device on a shared link learns the MAC address of another host on the home network via ARP ([RFCARP]), obtains an IP address and other host configuration via DHCP ([RFC2131]), and sends link-local multicast and broadcast packets. The network's response to the host is equivalent to the situation when a host is on the home network. When the link state changes, some hosts use ARP, ICMP, and/or DHCP to detect if it has changed the point of attachment on the network. 6.1. ARP Considerations For IEEE 802 type of access networks(e.g.(e.g., WLAN, WiMAX Ethernet Convergence Sublayer), the mobile device sends ARPrequestrequests for theCNCorresponding Node (CN) and default gateway on the same network. The purpose of maintaining an ARP entry is to allow the delivery of the packet from the mobile device to the CN using the destination MAC address. The ARP procedure for resolving IP and MAC address mapping is not needed for 3GPP2's cdma2000 and WiMAX IP Convergence Sublayer networks. The access router is always the L2 endpoint for the mobile device. The destination MAC address in the packet does not need to be set to the CN's MAC address. As long as the packet can be received by the access router, it will be forwarded toward the CN via the home network node (further details in Section 4.2.1). The ARP table in the mobile device does not need to be populated with CNs' MAC addresses in order for the packet to reach the CNs. A mobile device has ARP entries for the default gateway and hosts on the same subnet. Regardless of what the MAC addresses are, the AR receives the packets sent from the mobile device. 6.2. ICMP Considerations For movement detection, certain types of network stack on the mobile device will send an ICMP request [RFCICMP] to the default gateway after detecting the link went down and up. The IP TTL in the message is set to 1 to check if the default gateway is still directly reachable on the access network. The PMA MAY send an ICMP reply when it is providing Proxy Mobile IPv4 service for the mobile device. This response confirms to the mobile device that it has remained on the home network after link state change. This behavior is observed on existing client implementation.Detecting"Detecting Network Attachment in IPv4 (DNAv4)" [RFC4436] can be employed. General ICMP traffic is handled as normal IP packets and tunneled between the PMA and HA. 6.3. DHCP Considerations DHCP [RFC2131] is used to obtain an IP address and other host configuration parameters for a mobile device. The mobile device is expected to behave as a normal DHCP client when connected to the network with Proxy Mobile IPv4 service. There are two DHCP phases: bootup and renewal/release. The bootup procedure relies on the DHCP relay agent to obtain a lease on the IP address for the DHCP client from the DHCP server. The DHCP client directly renews and releases the lease with the DHCP server. In Proxy Mobile IPv4, the mobile device boots up on a network that is not the home network associated with the leased IP address. Also, the mobile device can move to other networks that are not related to that IP address. Yet, the DHCP client on the mobile device continues to operate as a stationary device that is directly on the network associated with its IP address. The PMA and HA create the transparency of the remote home network and mobility events by providing the expected network response to the DHCP client. There are several methods for the network infrastructure to interface with the mobile device such that the mobile device believes it is always fixed on the same network. The following methods are identified here, though others may be used aswell:well. DHCP Server in the AR: The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the AR. When the mobile device is on a different AR than the AR/DHCP server, the DHCP message from the client needs to be able to either be forwarded to the DHCP server in the previous AR or handled by the DHCP server in the new AR. When the DHCP lease time expires for the mobile device's IP address or the DHCP release message is received on the current AR, the AR sends PMIPv4 de-registration to the HA. DHCP Relay Agent in the AR: The mobile device boots up and initiates DHCP. The procedure is described in Figure 1. The DHCP client renews or releases the IP address directly with the DHCP server in the HA. When the mobile device is on a different AR,theDHCPmessagemessages from the client are relayed to the DHCP server in the HA. When the DHCP lease time expires for the mobile device's IP address or the DHCP release message is received on the HA, the HA deletes the mobility binding entry for the mobile device and sends registration revocation [RFC3543] to the AR. 6.4. PPP IPCP Considerations When the mobile deviceaccessaccesses the network via PPP[RFC1548],[RFC1661], LCP (Link Control Protocol) CHAP is used to authenticate the user. After authentication, the NAS (which is the AR/PMA) sends theproxyProxy Mobile IPv4 Registration Request to the HA. The HA responds with the Home Address in theproxyProxy Registration Reply. The NAS informs the mobile device to use the Home Address during IPCP [RFC1332]. When the mobile device moves to a new NAS, the same procedure happens and that mobile device has the same IP address for communication. The message exchange is illustrated in Figure 1. 6.5. Link-Local Multicast and Broadcast Considerations Depending on configuration policies, the PMA may tunnel all packets destined to Link-Local Multicast or Broadcast to the HA. The HA looks up the hostswhichthat are in the same subnet andsendsends a duplicated packet to each of them. 7. Proxy Mobility Agent Operation The PMA performs the functions of a Mobile Node entity as described in RFC33443344, with the exceptions identified below. - No agent discovery(i.e.(i.e., agent solicitation and advertisement) issupportedsupported. - The D-bit (De-encapsulation by MN) in the Registration Request is always set tozerozero. The main responsibility of the PMA is to set up and maintain the routing path between itself and the HA for a mobile device that is attached on the network. When it detects a mobile device is no longer attached, the routing path is torn down. It is possible that the PMA functions may be split up in implementations such as WiMAX (Section 10). The PMA needs to know the followinginformationinformation, at aminimumminimum, for sending a proxy registration: 1. NAI of the mobiledevicedevice. 2. MN-HA securityassociationassociation, when per-mobile device security association isusedused. 3. FA-HA MobilitySecurity Associationsecurity association orIPSec Security AssociationIPsec security association when per-node security association is used.Note,Note that these associations are specific only between PMA and HA, and are cryptographically unrelated to the associations between the MN and other network nodes. 4. HAAddress TheAddress. This information is typically downloaded from the AAA server during access authentication. 8. Home Agent Operation The Home Agent has the functionalityasdescribed in RFC 3344 [RFC3344]. In addition, the following features are introduced by Proxy Mobile IPv4: 1. Sequencing between PRRQs from multiple PMAs. For the integrated PMA case, there is a period after handover that may result in both the new PMA and old PMA sending PRRQs. It is imperative that the old PMA confirm that the mobile device is attached before sending a PRRQ when the re-registration timer expires. This would ensure that the HA only receives registration from the PMA that is serving the mobile device. 2. Authentication of PRRQs based onper Node Security Associationper-node security associations (FA-HA AE or IPsec AH/ESP) is applicable in the integrated PMA case. The presence of MN-HA AE or MN-AAA AE in the PRRQ is not necessary in this case. SincePMIPPMIPv4 is based on signaling between the PMA and the HA, the security for the message can be authenticated based on the peers' relationship. The HA can authorizePMIPPMIPv4 service for the mobile device at the PMA by contacting the AAA server. 3. The ability to process the Proxy Mobile IPv4Extensionsextensions defined in this document for enhanced capabilities ofPMIP.PMIPv4. 8.1. Processing Proxy Registration Requests When aproxy registration requestProxy Registration Request is received, the HA looks up the mobility binding entry indexed by the NAI. If the entry exists, HA compares theSequence Numberssequence numbers between the message and mobility binding entry (MBE), if present. If the value in the message is zero or greater than or equal to the one in the MBE, HA accepts the registration. The HA replies with a sequence number that is one greater than the larger value of either the MBE or Proxy Registration Request. If the registration is denied, then HA sends error code "Administratively prohibited (65)". If the HA is not enabled with Proxy Mobile IPv4 oritcannot process the Proxy Mobile IPv4 Extensions defined in this document, it sends aregistration replyRegistration Reply with error code PMIP_UNSUPPORTED(Proxy("Proxy Registration not supported by theHA).HA"). In the case when the PMA is not allowed to send aproxy registration requestProxy Registration Request to the HA, the HA sends aproxy registration replyProxy Registration Reply with error code PMIP_DISALLOWED(Proxy("Proxy Registrations from this PMAisare notallowed).allowed"). A PMA receiving these error codes SHOULDnotNOT retry sendingproxyProxy Mobile IPv4 messages to the HA that sent replies with these error codes. 9. Mobile Device Operation As per this specification, a mobile device would function as a normal IPv4 host. The required behavior of the node will be consistent with the base IPv4 specification[1].[RFC0791]. The mobile station will have the ability to retain its IPv4 address as it moves from one point of network attachment to the other without ever requiring it to participate in anymobility relatedmobility-related signaling. When booting up for the first time, a mobile device obtains an IPv4 address using DHCP or IPCP. As the mobile device roams, it is always able to communicate using the obtained IP address on the home network. The PMA on the currently attached network signals to the HA to ensure a proper forwarding path for the mobile device's traffic. 9.1. Initial Network Access When the mobile device accesses the network for the first time and attaches to a network on the PMA, it will present its identity in the form of an NAI to the network as part of thenetwork accessnetwork-access authentication process. Once the address configuration is complete, the mobile device will always be able to use that IP address anywhere in the network. 9.2. Mobile Device Mobility When a mobile device moves to a new PMA from another PMA, the following occurs: The mobile device may perform anetwork accessnetwork-access authentication with the new AR/PMA. If the authentication fails, the mobile device will not be able to use the link. After a successful authentication, the new PMA will have the identifier and the other profile data of the mobile device. The new PMA can also obtain the mobile device's information using acontext transfer mechanismcontext-transfer mechanism, which is out of the scope of this document. Once thenetwork accessnetwork-access authentication process is complete, the mobile device may sense a change in the Link Layer and use ARP, DHCP, and/or ICMP to detect if it is still on the same subnet. These mechanisms are handled by the network as described in "Appearance of Being At Home Network" (Section6) section.6). 9.3. Sending and ReceivingPacketPackets All packets that are to be sent from the mobile device to the Corresponding Node (CN) will be sent as normal IPv4packetspackets, setting the Source Address of the IPv4 header to the Home Address and the Destination Address to thecorresponding node'sCorresponding Node's IP address. InproxyProxy Mobile IPv4 operation, the default gateway for the mobile device is set up to reach the PMA. Similarly, all packets sent to the mobile device's IPAddressaddress by thecorresponding nodeCorresponding Node will be received by the mobile device in the original form (without any tunneling overhead). For Proxy Mobile IP, the packet from the mobile device is transported to the HA to reach thedestinationdestination, regardless of the destination IP address. For a CN with an IP address on the same network as the mobile device but that is physically located elsewhere, the HA will tunnel the packet to the CN. Otherwise, the HA forwards the traffic via normal routing. No special operation is required by the mobile device to either send or receive packets. Mobile devices attached to the same PMA may be using different HAs for transporting their traffic. 10. Proxy Mobile IPv4 Use Case in WiMAX WiMAX Forum Network Working Group (NWG) uses the Proxy Mobile IPv4 scheme to provide IPv4 connectivity and IP mobility. The relevant specification from WiMAX Forum is [NWG]. The Proxy Mobile IPv4 protocol is used over NWG reference point 3 (R3). Most of the Proxy Mobile IPv4 related procedures and requirements are described in reference to mobility management over R3. The Proxy Mobile IPv4 use case in the WiMAX Forum specification is illustrated in the following diagram: | | CSN | | +-------+ | +-------+ | | | | | |AAAV |--------------|------------| AAAH | | | | | | | | | | | +-------+ | +-------+ | | | | | | | | | +------------------+ | | | +-------+ | | | | | NAS | | | | | | PMIP | ASN1 | | | | | Client| | | | | +-------+ | | | | | | | | | | R4 | | | | +-------+ | | +------+ +----+ | | FA, | | | PMIPv4 | | | MN |-------| DHCP |---------------------------| HA | +----+ | | Relay/| | | R3 | | | | Server| ASN2 | | +------+ | +-------+ | | | | | +------------------+ Split PMA Figure 5: WiMAX NWGnetwork configurationNetwork Configuration forPMIP usePMIPv4 Use As shown in the figure above, WiMAX NWG uses the split PMA model. ThePMIP ClientPMIPv4 client is collocated with the NAS in ASN1(a.k.a.(aka, Authenticator ASN). The NWG architecture divides the network into two parts. The Access part is termedas Accessthe "Access ServiceNetworkNetwork" (ASN). The Core part is termedas Connectivitythe "Connectivity ServiceNetworkNetwork" (CSN). The MN attaches toaan 802.16 radio in the ASN2(aka(aka, Anchor Data Path Function). The radio (base station) connects to the Anchor Data Path Function (A_DPF) inASN2ASN2, which in turn connects to the Authenticator ASN (NAS) in ASN1. ASN1 authenticates and authorizes the MN. The AAA infrastructure is used to authenticate and authorize the MN. Note that, during initial network entry by the MN, the PMA can be an integrated PMA with all the functions collocated in ASN1. Due to mobility, the FA part of the PMA may have to be relocated to a more optimized location for better bearer management. However, to describe the WiMAX specific use case for Proxy Mobile IPv4, we will use the split PMA model since it is a more generic representation of the WiMAX NWG mobility framework. The WiMAX NWG specification[NWG],[NWG] defines a key bootstrapping scheme for use withproxyProxy Mobile IPv4. The specification usesper MNper-MN security association forproxyProxy Mobile IPv4 operation. The relevant keys(e.g.(e.g., MN-HA key) are derived using EAP authentication as specified in this document. For more information, please refer tosectionSection 4.3 of [NWG], stage-3 specification. Mobile IPv4 Registration Revocation is optionally supported in WiMAX. The security association for this is perNode.node. It is provided with FA-HA AE. The FA-HA key is also bootstrapped via the same key hierarchy that is described insectionSection 4.3 of [NWG]. TheproxyProxy Mobile IPv4 operation in WiMAX NWG is aligned with the basicproxyProxy Mobile IPv4 operation as described insectionSection 4 of this document. There are specific considerations for WiMAX NWG 1.0.0 use ofproxyProxy Mobile IPv4. These are listed below: 1. Use ofper MSper-MS SA forproxyProxy Mobile IPv4 registration. In this case, MN-HA AE is used. 2. Use of split PMA to handle FA relocation whilePMIP Clientthe PMIPv4 client remains anchored with the NAS (Authenticator ASN). 3. Only the Proxy Mobile IPv4 Access Technology TypeExtensionextension defined in this document is used in the NWG specification [NWG]. 4. GRE key identifier is optionally used between the HA and the PMA. 5. ThePMIP ClientPMIPv4 client and the FA interact via the WiMAX specific reference point and protocol(aka(aka, R4). For moreinformationinformation, please refer to the NWG specification [NWG]. 6. In order to handleinter ASNinter-ASN (inter Access Router)handover,handover and still allow the MN to use the same DHCP server's IP address that was sent in DHCPOFFER/ACK, the DHCP server(aka(aka, proxy) functions in the ASNisare required to be configured with the same IP address. 7. The MN - AR (trigger forproxyProxy Mobile IPv4) interaction is based on DHCP. DHCPDISCOVER from the MN triggersproxythe Proxy Mobile IPv4 process in the ASN. 10.1. Proxy Mobile IPv4 Call Flow Examples with Split PMA in WiMAX SincetheWiMAX uses the split PMA model, the call flows involve WiMAX proprietary signaling betweenPMIP Clientthe PMIPv4 client and FA within the PMA. The following call flows illustrate this.Proxy Handover Operation in WiMAX with Split PMASplit PMA +-----------------------------------+ +----+ | +------+ +------+ +-----+ | +-----+ | | | | NAS/ | | Old | | New | | | | | MN | | | PMIP | | FA | | FA | | | HA | | | | |Client| | | | | | | | +----+ | +------+ +------+ +-----+ | +-----+ | +----|------------|------------|----+ | | | | PMIP Tunnel | | | |<=======================>| | | | | | | | | R4 tunnel | | | | |<==========>| | | | 1 | | | |<---------------------------------->| | | | | | | | | | 2 | | | | |<---------->| | | | 3 | | | | |<----------------------- | | | | | | | | | 4 | | | +-> | |------------------------>| | | | | | | 5 | | | | | |----------->| | | | | | | PMIP | | | | | 6 | | | | | |<-----------| | | | | | | | | | 7 | | | +-> | |<------------------------| | | | | | | | | | 8 | | | | |<---------->| | | | | | | | 9 | | |PMIP Tunnel | Data |<---------------------------------->|<==========>| Forwarding | | | | | Figure5: AR6: Proxy Handover Operation in WiMAX with Split PMA In this scenario, the MN has moved to a new FA's area (known as the Data Path Function in WiMAX). The old FA and the new FA interact with each other and also with thePMIP ClientPMIPv4 client overWiMAXa WiMAX- specified R4 reference point to perform the handover. The steps are described below: 1. The mobile device establishes a L2 link with a base station (notshown)shown), which connects to a new FA(aka(aka, new Data Path Function in WiMAX). Notethatthat, in this case, the MN does not perform authentication and authorization. ThePMIP TunnelPMIPv4 tunnel remains between theOldold FA(aka(aka, old Data PathFucntionFunction in WiMAX). The data flows throughPMIPthe PMIPv4 tunnel between the HA and the oldFAFA, and through theWiMAX specificWiMAX-specific R4 tunnel between the old FA and the new FA and from the new FA to the MN. 2. The new FA interacts with the old FA usingWiMAX specifica WiMAX-specific R4 reference point to initiate the handover process. 3. The new FA uses theWiMAX specificWiMAX-specific R4 reference point to request thePMIP ClientPMIPv4 client to begin thePMIPPMIPv4 handover. 4. Triggered by step33, thePMIP ClientPMIPv4 client sendsana PRRQ to the new FA. The PRRQ contains the FA-CoA of the new FA. The Home Address field is set to the address of the assigned IP address of themobile node.Mobile Node. The PRRQ is embedded in theWiMAX specificWiMAX-specific R4 packet. 5. The new FA forwards the PRRQ to the HA. 6. Thehome agentHome Agent updates the existing mobility binding entry for the mobile device upon processing the PRRQ. Thehome agentHome Agent responds back to the new FA with PRRP. 7. The new FA forwards the PRRP after encapsulating it in aWiMAXWiMAX- specific R4 packet to thePMIP Client.PMIPv4 client. 8. The new FA and the old FA exchangeWiMAXWiMAX-specific R4specificmessages between them to confirm the handover. The old FA cleans upit'sits resources for the MN. The R4 bearer forwarding also stops at this point. 9. The forward and reverse direction traffic flows via the new FA. The handover is complete at this point. 11. Proxy Mobile IPv4 Use Case in 3GPP2 3GPP2 uses the Proxy Mobile IPv4 scheme to provide mobility service for the following scenarios (as shown in the figures below): 1. Mobility between theBase Stationbase station (BS) andAccess Gatewayaccess gateway (AGW) 2. Mobility between the AGW and the Home Agent (HA). As shown in the diagramsbelowbelow, in use case 1, the BS acts as the PMA and the AGW acts as the HA forproxyProxy Mobile IPv4 operation. In use case 2, the AGW acts as the PMA while the HA assumes the role of thehome agent.Home Agent. RAN Core +-------+ +------+ +----+ | BS/ | PMIPv4 | | | MN |------| PMA |-----------------------| AGW/ | +----+ | | | HA | | | +------+ +-------+ Integrated PMA Figure 7: 3GPP2'sPMIP4 use casePMIPv4 Use Case 1 - BS-AGWinterface mobilityInterface Mobility RAN Core +-------+ +------+ +----+ | AGW/ | PMIPv4 | | | MN |------| PMA |-----------------------| HA | +----+ | | | | | | +------+ +-------+ Integrated PMA Figure 8: 3GPP2'sPMIP4 use casePMIPv4 Use Case 2 - AGW-HAinterface mobilityInterface Mobility The figure below shows a simplified 3GPP2 architecture. Fordetailsdetails, please refer to the 3GPP2 Converged Access Network (CAN) architecture ([3GPP2]). RAN Core -----------^------------ -------^------------- | | | | V V V V +------+ +------+ +-----+ +----+ | | PMIPv4 | | PMIPv4 | | | MN |------| BS |------------| AGW |-----------| HA | +----+ | | | | | | +------+ +------+ +-----+ Figure 9: Simplified 3GPP2 Architecture The Proxy Mobile IPv4 usage scenario in 3GPP2 (case 1) is illustrated in the following diagram: +----+ +-------+ +-------+ +------+ | | | | | | | | | MN | | BS/ | | HAAA | | AGW/ | | | | PMA | | | | HA | +----+ +-------+ +-------+ +------+ | | | | | 1a | 1b | | |<------------->|<----------->| | | | | | | 2 | | | |-------------->| | | | | 3 | | | |----------------------->| | | | | | | 4 | | | |<-----------------------| | 5 | | | |<--------------| | | | | | | | 6 | | | |<======================================>| | | | | Figure 10: Network Connection Setup (use case 1) Description of the steps: 1a. MN performslayelayer 2 establishment with the BS/PMA and performs access authentication/authorization. During this phase, the MNrunruns EAP overUMB.Ultra Mobile Broadband (UMB). The BS acts as the NAS in this phase. 1b. The BS exchanges AAA messages with thehomeHome AAA server via the AR (not shown in the figure) to authenticate the MN. As part of this step, the AR may download some information about the MN(e.g.(e.g., user's profile, handset type, assignedhome agentHome Agent address, and other capabilities of the MN). This information is passed to the PMA/BS (as necessary) tosetupset up thePMIPPMIPv4 tunnel in the next step(s). 2. The MN sends layer 2 signaling messages to the BS/PMA to trigger thePMIPPMIPv4 tunnel setup process. 3. Triggered by step22, the PMA/BS sends a PRRQ to the AGW/HA. The HA's address is either received at step 1b from the Home AAA server (HAAA) or is discovered by other means. The PRRQ contains the Care-of Address (CoA) of the PMA (collocated FA in this case). The HoA field is set to all zeros (or all ones). The PRRQ is protected by the method described in this document. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document. 4. The AGW/HA registers the MN's session, assigns a symmetric GREkeykey, and returns this key in the PRRP to the BS/PMA. 5. The BS/PMA responds back to the MN with a layer 2 signaling message. 6. At this step, the MN is assigned an IP address and is connected to the network (via the AGW). In use case22, the same procedures are followed except the PMIPv4 tunnel is established between the AGW and the HA. In thiscasecase, GRE tunneling may not be used. 11.1.HO considerationsHandover Considerations in 3GPP2 There are some special handover considerations in 3GPP2's Proxy Mobile IPv4 use case. Below is an illustration of the specific use case: +----+ +-------+ +-------+ +-------+ | | | | | | | | | MN | | New | | AGW/ | | Old | | | | PMA/BS| | HA | | PMA/BS| +----+ +-------+ +-------+ +-------+ | | | | | | 1 | | | |------------->| | | | | | | | | | | | o 2 | | | | | | | | | | | 3 | | | |<-------------| | | | | | | | | | | | 4 | | | |<----------------------->| | | | | | | | | | | | o 5 | | | | | | | | Figure 11: 3GPP2 Registration Revocation for Previous PMA Description of the steps: 1. MN attaches to the new BS (L2 gets established). There is an ongoing mobility binding entry (MBE) in the AGW for the MN. The PMA in the new BS sends a PRRQ to the AGW. 2. The AGW receives a Proxy Registration Request for a Mobile Node and detects that it has an existing Mobility Binding Entry (MBE). The AGW validates the PRRQ from the new BS anditupdates the MBE for the MN. The MBE is kept tentative at this point. 3. The AGW sends a Proxy Registration Reply to the new BS. No Registration Revocation is used in the 3GPP2's use case. 4. A 3GPP2's proprietary PMA movement notification message may be exchanged between the AGW and the old BS. 5. The MBE update with the new BS is committed at this step. 12. IANA Considerations This specificationregisteredregisters 47 for the Proxy Mobile IPv4Non- skippableNon-Skippable Extension and 147 for Proxy Mobile IPv4 SkippableExtensionExtension, both of which are described in Section 5. The ranges for Mobile IPv4 [RFC3344] extension types are defined athttp://www.iana.org/assignments/mobileip-numbers.http://www.iana.org. This specification also creates a new subtype space for the type number of the extensions. The subtype value 1 is defined for the PMIPv4Non-skippableNon-Skippable Extension. The subtype values 1 to 4 are defined for the PMIPv4 Skippable Extension. Similar to the procedures specified for Mobile IPv4 number spaces, future allocations from the number space require expert review [RFC5226]. The PMIPv4 Per-Node Authentication MethodExtension,extension defined in Section 5.1 of this document, introduces a new authentication method numbering space, where the values from 0 to 2 have beenreserved byassigned per this document. Approval of new Access Technology type values are to be made through IANA Expert Review. The PMIPv4 Device IDExtension,extension defined in Section 5.3 of this document, introduces a new ID type numbering space, where the values from 0 to 4 have beenreserved byassigned per this document. Approval of new Access Technology type values are to be made through IANA Expert Review. The PMIPv4 Subscriber IDExtension,extension defined in Section 5.4 of this document, introduces a new ID type numbering space, where the values from 0 to 1 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review. The PMIPv4 Access Technology TypeExtension,extension defined in Section 5.5 of this document, introduces a new technology type numbering space, where the values from 0 to 8 have been reserved by this document. Approval of new Access Technology type values are to be made through IANA Expert Review. 12.1. Mobile IPv4 Extension Types This document introduces the following Mobile IP extension types. Name : Proxy Mobile IPv4Non-skippableNon-Skippable Extension Type Value : 47 Section : 5 Name : Proxy Mobile IPv4 Skippable Extension Type Value : 147 Section : 5 12.2. Mobile IPv4 Error Codes This document introduces the following error code that can be returned by the HA in a Proxy Registration Reply. Name Value First referenced ---- ----- ---------------- PMIP_UNSUPPORTED 149 Section 8.1 of RFC 5563 PMIP_DISALLOWED 150 Section 8.1 of RFC 5563 13. Security Considerations The functionality in this document is protected by theAuthentication Extensionsauthentication extensions described in RFC 3344 [RFC3344] orIPSecIPsec [RFC4301]. Each PMA needs to have an security association(e.g.(e.g., MN-HA, FA-HA,IPSecIPsec AH/ESP) with the HA to register the MN's IP address. The security association can be provisioned by theadministrator,administrator or dynamically derived. The dynamic key derivation and distribution for this scheme is outside the scope of this document. 14. Acknowledgements The authors would like to thank the following individuals for their review, comments, and suggestions to improve the content of this document. Shahab Sayeedi (Motorola), Alper Yegin (Samsung), Premec Domagoj (Siemens), Michael Hammer (Cisco), Jun Wang (Qualcomm), Jayshree Bharatia (Nortel), Semyon Mizikovsky (Alcatel-Lucent), Federico De Juan Huarte (Alcatel-Lucent), Paula Tjandra (Motorola), Alice Qinxia (Huawei), Howie Koh (Greenpacket), John Zhao (Huawei), Pete McCann (Motorola), and Sri Gundavelli (Cisco). 15. References 15.1. Normative References [3GPP2] "3GPP2 Basic IP Service for Converged Access Network", X.S0054-100-0 Version 2.0, August 2008.[DSMIPv4] Tsirtsis, G., "Dual Stack Mobile IPv4", draft-ietf-mip4-dsmipv4-06.txt (work in progress), February 2008. [MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", draft-yegani-gre-key-extensions-03.txt (work in progress), Jun 2007. [MIP4MCBC] Chakrabarti, S., "IPv4 Mobility extension for Multicast and Broadcast Packets", draft-chakrabarti-mip4-mcbc-02.txt (work in progress), Nov 2007.[NWG] "WiMAX Forum Network Architecture (Stage 3: Detailed Protocols andProcedures)Procedures)" Release11, Version1.2.3", , Jul1.2.3, July 2008.[RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation", RFC 1305, March 1992. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1548] Simpson, W., "The Point-to-Point Protocol (PPP)", RFC 1548, December 1993. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC 1994, August 1996.[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, March 1997.[RFC2484] Zorn, G., "PPP LCP Internationalization Configuration Option", RFC 2484, January 1999.[RFC3024] Montenegro, G., Ed., "Reverse Tunneling for Mobile IP, revised", RFC3024, January 2001. [RFC3344] Perkins, C., "IP Mobility Support for IPv4",3024, January 2001. [RFC3344] Perkins, C., Ed., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. 15.2. Informative References [MIP4GREKEY] Yegani, P., "GRE Key Extension for Mobile IPv4", Work in Progress, June 2007. [MIP4MCBC] Chakrabarti, S., "IPv4 Mobility extension for Multicast and Broadcast Packets", Work in Progress, November 2007. [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1305] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992. [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [RFC1661] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51, RFC3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4",1661, July 1994. [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication Protocol (CHAP)", RFC3543,1994, August2003.1996. [RFC3748] Aboba, B., Blunk, L., Vollbrecht, J., Carlson, J., and H. Levkowetz, Ed., "Extensible Authentication Protocol (EAP)", RFC 3748, June 2004. [RFC4058] Yegin, A., Ed., Ohba, Y., Penno, R., Tsirtsis, G., and C. Wang, "Protocol for Carrying Authentication for Network Access (PANA) Requirements", RFC 4058, May 2005. [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC4332] Leung, K., Patel, A., Tsirtsis, G., and E. Klovning, "Cisco's Mobile IPv4 Host Configuration Extensions", RFC 4332, December 2005. [RFC4433] Kulkarni, M., Patel, A., and K. Leung, "Mobile IPv4 Dynamic Home Agent (HA) Assignment", RFC 4433, March 2006. [RFC4436] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network Attachment in IPv4 (DNAv4)", RFC 4436, March 2006. [RFC5213] Gundavelli, S., Ed., Leung, K., Devarapalli, V., Chowdhury, K., and B. Patil, "Proxy Mobile IPv6", RFC 5213, August 2008. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. [RFC5454] Tsirtsis, G., Park, V., and H. Soliman, "Dual-Stack Mobile IPv4", RFC 5454, March 2009. [RFCARP] Plummer, D.,"An Ethernet"Ethernet Address ResolutionProtocol",Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, November 1982. [RFCICMP] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. Authors' Addresses Kent Leung Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USEmail:EMail: kleung@cisco.com Gopal Dommety Cisco Systems 170 West Tasman Drive San Jose, CA 95134 USEmail:EMail: gdommety@cisco.com Parviz YeganiCisco Systems 170 West Tasman Drive San Jose,Juniper Networks 1194 North Mathilda Ave. Sunnyvale, CA95134 US Email: pyegani@cisco.com94089-1206 EMail: pyegani@juniper.net Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 USAEmail:EMail: kchowdhury@starentnetworks.comFull Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.