Network Working Group K. Chowdhury Internet-Draft Starent Networks Expires: August 29, 2006 February 25, 2006 Network Based L3 Connectivity and Mobility Management for IPv4 draft-chowdhury-netmip4-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on August 29, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Abstract The layer 3 mobility management in a mobile wireless network can be performed with Mobile IPv4. The solution however requires the mobile nodes to have Mobile IPv4 clients. There may be scenarios where the mobile devices do not have Mobile IPv4 clients. The layer 3 mobility for these devices (often called simple IPv4 mobiles) can be done if the network has a Mobile IPv4 client function that can perform Mobile IPv4 procedures on behalf of the mobile nodes. This document defines such a mechanism. Chowdhury Expires August 29, 2006 [Page 1] Internet-Draft February 2006 Table of Contents 1. Introduction and Scope . . . . . . . . . . . . . . . . . . . . 3 2. Terminology & Definitions . . . . . . . . . . . . . . . . . . 3 3. Solution Overview . . . . . . . . . . . . . . . . . . . . . . 3 3.1 Network Connection Setup . . . . . . . . . . . . . . . . . 4 3.2 Inter AR Handoff . . . . . . . . . . . . . . . . . . . . . 5 4. MIPv4 Message Enhancements for Inter AR Interaction . . . . . 8 4.1 HO Request Message . . . . . . . . . . . . . . . . . . . . 8 4.2 HO Response Message . . . . . . . . . . . . . . . . . . . 9 5. Node Requirements . . . . . . . . . . . . . . . . . . . . . . 11 5.1 Mobile Node Requirements . . . . . . . . . . . . . . . . . 11 5.2 Access Router Requirements . . . . . . . . . . . . . . . . 11 5.3 Home Agent Requirements . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 9. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . 14 Chowdhury Expires August 29, 2006 [Page 2] Internet-Draft February 2006 1. Introduction and Scope Network based L3 mobility management allows any mobile node to connect to a mobile wireless network and maintain it's L3 connection while crossing subnet boundaries. This type of mobility management solution does not require any Mobile Ipv4 client implementation in the mobile node. Rather, the L3 mobility is handled entirely in the network via a Mobile IPv4 Client function in a network node such as an Access Router. In a typical mobile wireless network the inter base station handoffs (often called L2 handoffs) are handled by local mobility management protocols. There are various flavors of such protocols deployed today. The L3 however are anchored at an Access Router in these networks. The networks using Mobile IPv4 for L3 mobility management typically have the Foreign Agent function in these Access Routers. When the mobile node incurs handoff to a base station that is attached to an Access Router in a different sub-net than the current one, the L3 mobility management procedure is invoked by the new Access Router by sending an Agent Advertisement to the mobile node. If the mobile node has a Mobile IPv4 implementation, it can perform Mobile IPv4 registration procedures to maintain its L3 connectivity (change CoA with the Home Agent). However, if the mobile node does not have Mobile IPv4 implementation, it will simply not understand the Agent Advertisement and its L3 will break. The solution provided in this document allows any mobile to connect to the network and be mobile without Mobile IPv4 in the handset and without losing its L3 connectivity due to handoffs. 2. Terminology & Definitions 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 [RFC2119]. The definitions of some new terms used in this document: SAR: Serving Access Router TAR: Target Access Router 3. Solution Overview The solution has two aspects. The first aspect deals with the network connection setup. The second aspect deals with the L3 mobility management. Chowdhury Expires August 29, 2006 [Page 3] Internet-Draft February 2006 3.1 Network Connection Setup The mobile node connects to the mobile wireless network via any access technology e.g. CDMA, GPRS, 802.11, 802.16e etc. After establishing L2 connection with the network, the mobile node initiates L3 establishment by requesting an IPv4 address from the network. There are various ways the mobile node can request for an IPv4 address e.g. IPCP [RFC1332] and DHCP [RFC2131]. The following message sequence diagram shows the network connectivity procedure. +----+ +-------+ +-------+ +-----+ | | | AR/ | | | | | | MN | | MIPv4 | | AAA | | HA | | | | Client| | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1a | 1b | | |<------------->|<----------->| | | | | | | 2 | | | |-------------->| | | | | 3 | | | |----------------------->| | | | | | | 4 | | | |<-----------------------| | 5 | | | |<--------------| | | | | | | | 6 | | | |<------------->|<===========>|<========>| | | | | Figure 1. Network Connection Setup with MIPv4 Client in the AR. Description of the steps: 1a. MN performs L2 establishment with the base station (not shown) and performs access authentication/authorization with the NAS. During this phase, the MN may run CHAP or PAP if PPP is used or EAP over foo (foo being the specific access technology or PANA). The AR acts as the NAS in this phase. Chowdhury Expires August 29, 2006 [Page 4] Internet-Draft February 2006 1b. The NAS exchanges AAA messages with the AAA infrastructure to perform authentication and authorization of the MN. As part of this step, the AAA server may download some information about the MN (e.g. user's profile, handset type, assigned home agent address, and other capabilities of the MN). 2. The MN sends an IPCP config request to the NAS/AR in case of PPP to request for an IPv4 address. If DHCP is uses, the DHCP client in the MN sends a DHCPDISCOVER message. It is assumed in this document that the AR has a DHCP proxy/server function. 3. Triggered by step 2 the MIPv4 Client in the AR sends an Mobile IPv4 registration request (RRQ) to the Home Agent. The Home Agent's address if either received at step 1b from the Home AAA or it is discovered in an out of band way by the AR. The RRQ contains the Care-of Address (CoA) of the AR (collocated FA in this case). The HoA field is set to ALL-ZERO-ONES-ADDRESS. The RRQ may be protected by MN-HA authorization enabling extension. The derivation and distribution of the MN-HA or FA-HA key is outside the scope of this document. 4. The home agent registers the MN's session and assigns an HoA. The home agent returns the HoA in the RRP. 5. The AR/NAS responds back to the MN with an IPCP config-NAK to suggest the IPv4 address which is the HoA from the HA. This happens in response to step 2. If DHCP was used at step 2, the AR/ DHCP-proxy/server sends back a DHCPOFFER with the IPv4 address set to the received HoA. 6. At this step, regular IPCP/NCP procedures get completed and the MN's IP stack is ready to receive or send IP packets. If DHCP is used, the regular DHCPREQUEST and DHCPACK messages are exchanged and the MN's IP stack is configured with the assigned IPv4 address. 3.2 Inter AR Handoff After connecting to the access network the MN may incur inter AR handoff due to mobility across sub-net boundaries. This poses the challenge of keeping the L3 connection intact for the MN due to possible change in the IPv4 sub-net. The following message sequence diagram shows how the network connectivity can be maintained across this inter AR handoff. Chowdhury Expires August 29, 2006 [Page 5] Internet-Draft February 2006 +----+ +-------+ +-------+ +-----+ | | | | | | | | | MN | | SAR | | TAR | | HA | | | | | | | | | +----+ +-------+ +-------+ +-----+ | | | | | 1 | | | |<------------->|<===========>|<========>| | | | | | | 2.HO trigger | | | arrives | | | | | | | 3 | | | |<------------| | | | | | | | 4 | | | |------------>| | | | | | | | | 5 | | | |--------->| | | | | | | | 6 | | | |<---------| | | | | | | | Bi-cast(optional) MN connects 7.HO occurs | | L2 at | | | new BS | | | | | 8 | | | |----------------------->| | | | | | | 9 | | | |<-----------------------| | | | | | | | Stop Bi-cast | | 10 | | |<--------------------------->|<========>| | | | | Figure 1. Inter AR Mobility Management with MIPv4 Client in the AR. Description of the steps: 1. MN is connected at the Serving AR (SAR) and it is sending/ receiving data via SAR. The HA has a tunnel established with the Chowdhury Expires August 29, 2006 [Page 6] Internet-Draft February 2006 SAR. 2. The MN moves into an area of a target Base Station (not shown in the figure) that is connected to a target AR (TAR). The target BS sends a HO indication message (out of scope of this document) to the target AR. This message contains the address of the SAR and the MN identifier (NAI/MSID) among other parameters. 3. Based on the trigger at step 2, the TAR sends a HO Request message to the SAR to fetch the relevant context for the MN. The HO Request message is defined in the following section 4 of this document. Note that the TAR and the SAR share a security association. The Ho Request message can be protected with an authenticator using the security association between the ARs or by use of IPsec AH. 4. Upon receiving the HO Request message, the SAR validates it by checking it's security association with the TAR. if the validation succeeds, the SAR sends the state information (context) for the identified MN to the TAR in a HO Response message. 5. The Mobile IPv4 Client in the TAR sends a Registration Request to the HA with its' CoA (CoA of the TAR) and sets the HoA to the HoA of the MN which is received as part of the state information at step 4. The key distribution for MN-HA or FA-HA authenticator in this message is outside the scope of this document. The RRQ contains the MN-NAI extension containing the NAI of the MN. 6. Upon receiving the RRQ from the TAR, the HA validates the MN-HA or FA-HA authentication AE. If the validation is successful, the HA assigns an HoA to the MN and returns the HoA in an RRP. Since the binding/tunnel with the SAR is still not torn down, the HA has an option of bi-casting to both SAR and TAR at this time. 7. At this time, the MN connects L2 with the target BS. The target BS (not shown in the figure for brevity) informs the TAR that the MN has connected to the target system now. The Serving BS also detects that the handoff (L2 torn down with the MN) has happened and it informs the SAR about this event. 8. Upon receiving the HO event from the Serving BS, the SAR sends a Revocation Request [RFC3543] to the HA to remove the binding for the MN at the HA. The Revocation Request message is protected with either FA-HA AE. Note, it is assumed in this solution that the Revocation Support extension was exchanged between SAR and the HA at the time of initial Mobile IPv4 registration. 9. The HA validates the FA-HA AE in the Revocation Request message. Chowdhury Expires August 29, 2006 [Page 7] Internet-Draft February 2006 if validation is successful, the HA removes the binding for the MN with CoA of the SAR. The HA sends back an Revocation ACK to the SAR. At this point the HA stops bi-casting traffic to the SAR. 10. The MN continues to receive service (i.e. send/receive data) with the same IPv4 address which is the HoA. The MN is agnostic to the L3 mobility procedures that was performed on it's behalf in the network. 4. MIPv4 Message Enhancements for Inter AR Interaction The format of the inter AR messages are defined her: 4.1 HO Request Message The HO Request message is an inter AR message requesting for context transfer. The message is formatted as follows: IP Fields: Source Address The IPv4 address of the TAR. Destination Address The IPv4 address of the SAR. UDP Fields: Source Port variable. Destination Port TBD-1: MUST be assigned by IANA. The UDP header is followed by the fields as shown below. Chowdhury Expires August 29, 2006 [Page 8] Internet-Draft February 2006 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+- Type A 8-bit field indicating the type of the message. TBD-2, to be assigned by IANA. Reserved Reserved for future use, set to 0s. Identifier A 4-bytes field set to either timestamp or a randomly generated number by the sender. It is used to protect the message from replay attacks. Extensions Extensions relevant to identification of the MN are attached here. This can be the MN-NAI extension. Authenticator The Authenticator is carried in a TBD extension to protect the whole message from tampering and validation check at the receiver. This is optional if IPsec AH is used. 4.2 HO Response Message The HO Response message is an inter AR message that is used to respond to an HO Request message. The message is formatted as follows: IP Fields: Chowdhury Expires August 29, 2006 [Page 9] Internet-Draft February 2006 Source Address The IPv4 address of the SAR. Destination Address The IPv4 address of the TAR. UDP Fields: Source Port This can be the same as the destination port in the HO request message. Destination Port same value as the source port in the HO Request message. The UDP header is followed by the fields as shown below. 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 | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extensions... +-+-+-+-+-+-+-+-+-+-+-+-+- | Authenticator... +-+-+-+-+-+-+-+-+-+-+-+-+- Type A 8-bit field indicating the type of the message. TBD-3, to be assigned by IANA. Reserved Reserved for future use, set to 0s. Chowdhury Expires August 29, 2006 [Page 10] Internet-Draft February 2006 Identifier A 4-bytes field copied from the corresponding Ho Request message. Extensions Extensions relevant to identification of the MN are attached here. This can be the MN-NAI extension. Authenticator The Authenticator is carried in a TBD extension to protect the whole message from tampering and validation check at the receiver. 5. Node Requirements This section describes the requirements for each of the nodes involved in this method. 5.1 Mobile Node Requirements TBD. 5.2 Access Router Requirements TBD. 5.3 Home Agent Requirements TBD. 6. Security Considerations The HO Request and the HO Response messages SHOULD be protected via IPsec AH or via an inter-AR Authentication Extension (the format to be defined). In the absence of such security, the context information of the MN's ongoing session at the SAR may be compromised. At the time of L2 establishment, the SAR may receive security keying information for the MN from the Home AAA server that can be used to secure the subsequent RRQ. The HA should be able to retrieve the corresponding security keying material from the Home AAA server to process the RRQ and send the RRP. Alternatively, if individual security keying material per MN are not available at the AR and the HA, the AR and the HA SHOULD secure the Chowdhury Expires August 29, 2006 [Page 11] Internet-Draft February 2006 RRQ/RRP by a common security association that they share. 7. IANA Considerations The following values must be assigned by IANA: Destination Port for HO Request: TBD-1. HO Request: Type TBD-2. HO Response: Type TBD-3. 8. Acknowledgements TBD. 9. Normative References [RFC1332] McGregor, G., "The PPP Internet Protocol Control Protocol (IPCP)", RFC 1332, May 1992. [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. [RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August 2002. [RFC3543] Glass, S. and M. Chandra, "Registration Revocation in Mobile IPv4", RFC 3543, August 2003. Chowdhury Expires August 29, 2006 [Page 12] Internet-Draft February 2006 Author's Address Kuntal Chowdhury Starent Networks 30 International Place Tewksbury, MA 01876 US Phone: +1 214-550-1416 Email: kchowdhury@starentnetworks.com Chowdhury Expires August 29, 2006 [Page 13] Internet-Draft February 2006 Intellectual Property Statement 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. Disclaimer of Validity 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 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. Copyright Statement Copyright (C) The Internet Society (2006). 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. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Chowdhury Expires August 29, 2006 [Page 14]