[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02                                                      
     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 <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
     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-
     4.1.  Mobile-IP-Configuration attribute definition
        This  Attribute indicates whether a user is authorized to do Mobile
        IP.  It MAY be included  in  Access-Accept,  or  Accounting-Request
     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)         |
        ? for Mobile-IP-Configuration
     Aboba                                                         [Page 3]

     INTERNET-DRAFT                                           13 March 1998
        The Address field is four octets, and  encodes  the  Mobile  Node's
        Home Address.
        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
        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
     [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
     [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]