ROAMOPS Working Group Bernard Aboba INTERNET-DRAFT Microsoft Category: Standards Track 13 March 1998 Support for Mobile IP in Roaming 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups MAY also distribute work- ing 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 mate- rial or to cite them other than as ``work in progress.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ds.internic.net (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). The distribution of this memo is unlimited. It is filed as , and expires September 1, 1998. Please send comments to the authors. 2. Abstract This document describes the issues involved in supporting Mobile IP in roaming. 3. Introduction As described in [6], support for Mobile IP is a requirement for a roaming standard. RFC 2002 [7] describes the framework for Mobile IP, while RFC 2290 [8] describes how a mobile node and a peer negotiate the appropriate use of Mobile IP over a PPP link, through use of the IPCP IP Address and Mobile-IPv4 Configuration Options. 3.1. Overview The steps involved in negotiating mobile access to the Internet while roaming between ISPs are as follows: 1. The mobile node dials into a local ISP NAS using PPP, and authenti- cates via LCP, identifying itself via the Network Access Identifier Aboba [Page 1] INTERNET-DRAFT 13 March 1998 (NAI), described in [9]. The NAI identifies the home ISP of the mobile node, providing the local ISP with the information necessary to con- tact the home authentication server. 2. The NAS then sends a RADIUS Access-Request and receives a RADIUS Access-Reply. Based on the Access-Reply, the NAS will grant access to the Internet to the mobile node, or will terminate the conversation. Note that since the RADIUS conversation takes place in LCP, while mobile IP configuration takes place in IPCP, an Access-Accept if sent must include the authorization information required to assist the NAS in negotiating use of Mobile IP with the mobile node. 3.The mobile node will indicate its preference for a foreign care-of- address or a co-located care of address via use of the IP Address and Mobile-IPv4 Configuration Options in IPCP, as described in [8]. If a co-located care-of-address is preferred, this will typically be indi- cated by setting the IP Address option to zero, and the Mobile-IPv4 Configuration option to the Home Address. If a foreign agent care-of- address is preferred, this will typically be indicated by sending only a Mobile-IPv4 Configuration option with the Home Address. 4. The NAS will respond to the mobile node's Configure-Request as described in [8]. If the NAS is not Mobile-IP capable, then it will respond with a Configure-Reject. If the mobile node has requested a co-located care-of-address, and the NAS can comply, it will typically reply with a Configure-NAK including an IP Address Option set to the co-located care-of-address or home address, depending on whether the mobile node is attached via a foreign link or home link. If the NAS only supports a foreign agent care-of-address, it will typically reply with a Configure-NAK including an IP Address Option set to zero. If the mobile node has requested a foreign agent care-of-address, and the NAS is Mobile-IP capable, then the NAS MUST reply with a Mobile-IPv4 Configuration Option set to the Home Address indicated by the mobile node. As noted in [8], the NAS need not know the mobile node's Home Address beforehand in order to decide how to reply. This information is not useful because if the Home Address expected by the NAS did not match that provided by the mobile node, there would be no way to cor- rect the problem, since as described in [8] a Configure-NAK is unde- fined for the Mobile-IPv4 Configuration Option. 5. The IPCP negotiation concludes and the mobile node now has access to the Internet. 6. The NAS sends a RADIUS Accounting Start packet to the RADIUS accounting server. 7. The NAS, acting as a Foreign Agent, sends an agent advertisement on the PPP link. 8. The mobile node sends a Registration Request and receives a Reply. As noted in [8], the mobile node must receive an agent advertisement before registering on a foreign link since even if the mobile node is using a colocated care-of-address, the NAS acting as a foreign agent may wish to enforce a policy requiring registration. Aboba [Page 2] INTERNET-DRAFT 13 March 1998 4. Use of RADIUS In order to carry out the IPCP negotiation described above, the NAS requires the following information: 1. Whether the mobile node is authorized to do mobile IP. This is indicated by the Mobile-IP-Configuration Attribute defined below. Since the mobile node may not always wish to do mobile IP, Mobile IP authorization should not be interpreted as requiring mobile IP. Simi- larly, the mobile node may not always contact an ISP that is Mobile-IP capable, and as a result, while a home server may include Mobile-IP- Configuration attribute in the Access-Accept, this attribute may be stripped by a local ISP proxy. 2. Whether a co-located care-of-address is available for assignment to the mobile node if requested. This is indicated by the inclusion or absence of a Framed-IP-Address attribute in the Access-Accept. When a Mobile-IP-Configuration attribute is present, the absence of a Framed- IP-Address attribute should be interpetted as indicating that a co- located care-of-address MUST NOT be assigned. If a Framed-IP-Address attribute is included along with a Mobile-IP-Configuration attribute, then a co-located care-of-address MAY be assigned. As described in [2], a co-located care-of-address may assigned statically or dynami- cally. 4.1. Mobile-IP-Configuration attribute definition Description This Attribute indicates whether a user is authorized to do Mobile IP. It MAY be included in Access-Accept, or Accounting-Request packets. A summary of the Mobile-IP-Configuration Attribute format is shown below. The fields are transmitted from left to right. 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 2 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type ? for Mobile-IP-Configuration Length 6 Address Aboba [Page 3] INTERNET-DRAFT 13 March 1998 The Address field is four octets, and encodes the Mobile Node's Home Address. Discussion When included in an Access-Accept, the Address field MUST contain the value 0xFFFFFFFF, indicating that Mobile-IP is authorized. Since the absence of Mobile IP authorization is indicated by omis- sion of the attribute, no value is required to signal lack of authorization. When included in an Accounting-Request, the Address field is set to the Home Address supplied by the mobile node. 5. Acknowledgements Thanks to Jim Solomon of Motorola and Pat Calhoun of Sun Microsystems for useful discussions of this problem space. 6. References [1] B. Aboba, J. Lu, J. Alsop, J. Ding, W. Wang. "Review of Roaming Implementations." RFC 2194, Microsoft, Aimnet, i-Pass Alliance, Asi- ainfo, Merit, September 1997. [2] C. Rigney, A. Rubens, W. Simpson, S. Willens. "Remote Authenti- cation Dial In User Service (RADIUS)." RFC 2138, Livingston, Merit, Daydreamer, April 1997. [3] C. Rigney. "RADIUS Accounting." RFC 2139, Livingston, April 1997. [4] S. Bradner. "Key words for use in RFCs to Indicate Requirement Levels." RFC 2119, Harvard University, March, 1997. [5] C. Rigney, W. Willats. "RADIUS Extensions." Internet draft (work in progress), draft-ietf-radius-ext-01.txt, Livingston, December 1997. [6] B. Aboba, G. Zorn. "Roaming Requirements," Internet draft (work in progress), draft-ietf-roamops-roamreq-07.txt, Microsoft, March 1998. [7] C. Perkins. "IP Mobility Support." RFC 2002, IBM October 1996. [8] J. Solomon, S. Glass, "Mobile-IPv4 Configuration Option for PPP IPCP." RFC 2290, Motorola, FTP Software, February 1998. [9] B. Aboba, M. A. Beadles. "The Network Access Identifier." Inter- net draft (work in progress), draft-ietf-roamops-nai-10.txt, Microsoft, CompuServe Network Services, March 1998. Aboba [Page 4] INTERNET-DRAFT 13 March 1998 7. Authors' Addresses Bernard Aboba Microsoft Corporation One Microsoft Way Redmond, WA 98052 Phone: 425-936-6605 EMail: bernarda@microsoft.com Aboba [Page 5]