ROAMOPS Working Group Bernard Aboba
INTERNET-DRAFT Microsoft
Category: Standards Track
<draft-ietf-roamops-mobileip-01.txt>
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 <draft-
ietf-roamops-mobileip-01.txt>, 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]
