summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc2794.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc2794.txt')
-rw-r--r--doc/rfc/rfc2794.txt507
1 files changed, 507 insertions, 0 deletions
diff --git a/doc/rfc/rfc2794.txt b/doc/rfc/rfc2794.txt
new file mode 100644
index 0000000..4322021
--- /dev/null
+++ b/doc/rfc/rfc2794.txt
@@ -0,0 +1,507 @@
+
+
+
+
+
+
+Network Working Group P. Calhoun
+Request for Comments: 2794 Sun Microsystems Laboratories
+Updates: 2290 C. Perkins
+Category: Standards Track Nokia Research Center
+ March 2000
+
+
+ Mobile IP Network Access Identifier Extension for IPv4
+
+Status of this Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Copyright Notice
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+Abstract
+
+ AAA servers are in use within the Internet today to provide
+ authentication and authorization services for dial-up computers.
+ Such services are likely to be equally valuable for mobile nodes
+ using Mobile IP when the nodes are attempting to connect to foreign
+ domains with AAA servers. AAA servers today identify clients by
+ using the Network Access Identifier (NAI). Our proposal defines a way
+ for the mobile node to identify itself, by including the NAI along
+ with the Mobile IP Registration Request. This memo also updates RFC
+ 2290 which specifies the Mobile-IPv4 Configuration option for IPCP,
+ by allowing the Mobile Node's Home Address field of this option to be
+ zero.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 1]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+1. Introduction
+
+ AAA servers are in use within the Internet today to provide
+ authentication and authorization services for dial-up computers.
+ Such services are likely to be equally valuable for mobile nodes
+ using Mobile IP when the nodes are attempting to connect to foreign
+ domains with AAA servers. AAA servers today identify clients by
+ using the Network Access Identifier (NAI) [1]. This document
+ specifies the Mobile Node NAI extension to the Mobile IP Registration
+ Request [7] message from the mobile node.
+
+ Since the NAI is typically used to uniquely identify the mobile node,
+ the mobile node's home address is not always necessary to provide
+ that function. Thus, it is possible for a mobile node to
+ authenticate itself, and be authorized for connection to the foreign
+ domain, without even having a home address. A message containing the
+ Mobile Node NAI extension MAY set the Home Address field to zero (0)
+ in the Registration Request, to request that a home address be
+ assigned.
+
+ The "Mobile-IPv4 Configuration" option to IPCP has been specified in
+ RFC 2290 [8] for proper interaction between a mobile node and a peer,
+ through which the mobile node connects to the network using PPP.
+ According to that specification the Mobile Node's Home Address field
+ of the option MUST not be zero. However, in the context of this memo
+ which allows a mobile node to be identified by its NAI and to obtain
+ an address after the PPP phase of connection establishment, the Home
+ Address field is allowed to be zero while maintaining all other
+ aspects of RFC 2290. Interpretation of various scenarios from RFC
+ 2290 is given in section 4.
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [3].
+
+2. Mobile Node NAI Extension
+
+ The Mobile Node NAI extension, shown in figure 1, contains the user
+ name following the format defined in [1]. When it is present in the
+ Registration Request, the Home Address field MAY be set to zero (0).
+ The Mobile Node NAI extension MUST appear in the Registration Request
+ before both the Mobile-Home Authentication extension and Mobile-
+ Foreign Authentication extension, if present.
+
+
+
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 2]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+ 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 | MN-NAI ...
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+ Figure 1: The Mobile Node NAI Extension
+
+
+ Type 131 (skippable) [7]
+
+ Length The length in bytes of the MN-NAI field
+
+ MN-NAI A string in the NAI format defined in [1].
+
+3. Foreign Agent Considerations
+
+ If Home Address is zero in the Registration Request, the foreign
+ agent MUST use the NAI instead in its pending registration request
+ records, along with the Identification field as usual. If the
+ foreign agent cannot manage pending registration request records in
+ this way, it MUST return a Registration Reply with Code indicating
+ NONZERO_HOMEADDR_REQD (see section 5).
+
+ If the mobile node includes the Mobile Node NAI extension in its
+ Registration Request, then the Registration Reply from the home agent
+ MUST include the Mobile Node NAI extension. If not, the foreign
+ agent SHOULD send the Registration Reply to the mobile node, changing
+ the Code to the value MISSING_NAI (see section 5). The Registration
+ Reply MUST include a nonzero Home Agent address and mobile node's
+ Home Address. If not, the foreign agent SHOULD send the Registration
+ Reply to the mobile node, changing the Code to the value
+ MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5).
+
+4. Interactions with Mobile-IPv4 Configuration Option to IPCP
+
+ In the Mobile-IPv4 Configuration Option to IPCP [8], the Mobile
+ Node's Home Address field may be zero. In this section, we specify
+ the action to be taken in that case, when the mobile node is using
+ the Mobile Node NAI extension in the Mobile IP Registration Request.
+ Whether or not the IP Address Configuration Option contains a nonzero
+ IP address, the mobile node will subsequently attempt to obtain a
+ home address from the Mobile IP Registration Reply.
+
+ If the IP Address Configuration Option to IPCP has IP address equal
+ to zero, the PPP peer is expected to allocate and assign a co-located
+ care-of address to the Mobile Node. If, on the other hand, the IP
+
+
+
+
+Calhoun & Perkins Standards Track [Page 3]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+ Address Configuration Option to IPCP has a nonzero IP address, the
+ PPP peer is expected to assign that address to the Mobile Node as its
+ co-located care-of address.
+
+ Finally, if the IP Address Configuration Option is left out of the
+ IPCP Configure-Request, then no co-located care of address is
+ assigned during IPCP. The mobile node will acquire a co-located care
+ of address during a later stage of configuration or will use an FA-
+ located care-of address.
+
+5. Error Values
+
+ Each entry in the following table contains the name and value for the
+ Code [7] to be returned in a Registration Reply, and the section in
+ which the error Code is first mentioned in this specification.
+
+ Error Name Value Section of Document
+ ---------------------- ----- -------------------
+ NONZERO_HOMEADDR_REQD 96 3
+ MISSING_NAI 97 3
+ MISSING_HOME_AGENT 98 3
+ MISSING_HOMEADDR 99 3
+
+6. IANA Considerations
+
+ The Mobile Node NAI extension defined in Section 2 is a Mobile IP
+ registration extension as defined in RFC 2002 [7] and extended in RFC
+ 2356 [6]. IANA should assign a value of 131 for this purpose.
+
+ The Code values defined in Section 5 are error codes as defined in
+ RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6]. They
+ correspond to error values conventionally associated with rejection
+ by the foreign agent (i.e., values from the range 64-127). IANA
+ should record the values as defined in Section 5.
+
+7. Security Considerations
+
+ Mobile IP registration messages are authenticated, and the
+ authentication verified by the recipient. This proposal does not
+ prohibit the mobile node from sending its NAI in the clear over the
+ network, but that is not expected to be a security issue.
+
+8. IPv6 Considerations
+
+ Supporting NAI-based registrations for Mobile IPv6 [4] is outside the
+ scope of this document. This section contains some ideas how
+ Stateless Address Autoconfiguration [9] and DHCPv6 [2] might be
+ extended to support NAI-based Mobile IPv6 registrations.
+
+
+
+Calhoun & Perkins Standards Track [Page 4]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+ For mobile nodes using IPv6, there are no commonly deployed
+ mechanisms by which a mobile node may present its credentials, such
+ as exist today with IPv4. Nevertheless, a mobile node using IPv6
+ mobility may wish to specify the domain in which their credentials
+ may be checked, by using a NAI just as this specification proposes
+ for IPv4. In the case of IPv6, however, there is no foreign agent in
+ place to manage the connectivity of the mobile node, and thus to
+ manage the verification of the credentials offered by the mobile
+ node. To identify the HDAF (see appendix A) that has the expected
+ relationship with the mobile node, the NAI would have to be forwarded
+ to a local AAA by the local agent involved with configuring the
+ care-of address of the mobile node.
+
+ This agent can either be a router sending out Router Advertisements
+ [9], or a DHCPv6 server. In the former case, the router could signal
+ its ability to handle the NAI by attaching some yet to be defined
+ option to the Router Advertisement. In the latter case, for managed
+ links, the mobile node could include a yet to be defined NAI
+ extension in its DHCP Solicitation message. Such an NAI extension
+ and appropriate authentication would also be required on the
+ subsequent DHCP Request sent by the mobile node to the DHCP Server
+ selected on the basis of received DHCP Advertisements. Once a care-
+ of address on the foreign network has been obtained, the mobile node
+ can use regular MIPv6 [4].
+
+9. Acknowledgements
+
+ The authors would like to thank Gabriel Montenegro and Vipul Gupta
+ for their useful discussions. Thanks to Basaravaj Patil and Pete
+ McCann for text describing actions to be taken when the home address
+ is zero but the mobile node wishes to use the Mobile-IPv4
+ Configuration Option to IPCP defined in RFC 2290.
+
+References
+
+ [1] Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
+ 2486, January 1999.
+
+ [2] Bound, J. and C. Perkins, "Dynamic Host Configuration Protocol
+ for IPv6 (DHCPv6)", Work in Progress.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work in
+ Progress.
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 5]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+ [5] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344, May
+ 1998.
+
+ [6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal for
+ Mobile IP", RFC 2356, June 1998.
+
+ [7] Perkins, C., "IP Mobility Support", RFC 2002, October 1996.
+
+ [8] Solomon, J. and S. Glass, "Mobile-IPv4 Configuration Option for
+ PPP IPCP", RFC 2290, February 1998.
+
+ [9] Thomson, S. and T. Narten, "IPv6 Stateless Address
+ Autoconfiguration", RFC 2462, December 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 6]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+A. Home Domain Allocation Function (HDAF)
+
+ This appendix introduces a new function named the Home Domain
+ Allocation Function (HDAF) that can dynamically assign a Home Address
+ to the mobile node.
+
+ Figure 2 illustrates the Home HDAF, which receives messages from
+ foreign agents (e.g., FA) and assigns a Home Address within the Home
+ Domain. The HDAF does not perform any Mobile IP processing on the
+ Registration Request, but simply forwards the request to a Home Agent
+ (HA) within the network that is able to handle the request.
+
+ +------+
+ | |
+ +---+ HA-1 |
+ +------+ +------+ +------+ | | |
+ | | | | | | | +------+
+ | MN |-------| FA |-------| HDAF +---+ ...
+ | | | | | | | +------+
+ +------+ +------+ +------+ | | |
+ +---+ HA-n |
+ | |
+ +------+
+
+ Figure 2: Home Domain Allocator Function (HDAF)
+
+ Upon receipt of the Registration Request from the mobile node (MN),
+ FA extracts the NAI and finds the domain name associated with it. FA
+ then finds the HDAF that handles requests for the mobile node's
+ domain. The discovery protocol is outside of the scope of this
+ specification. As an example, however, FA might delegate the duty of
+ finding a HDAF to a local AAA server. The local AAA server may also
+ assist FA in the process of verifying the credentials of the mobile
+ node, using protocols not specified in this document.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 7]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+Addresses
+
+ The working group can be contacted via the current chairs:
+
+ Basavaraj Patil
+ Nokia Corporation
+ 6000 Connection Drive
+ M/S M8-540
+ Irving, TX 75039
+ USA
+
+ Phone: +1 972-894-6709
+ Fax : +1 972-894-5349
+ EMail: Basavaraj.Patil@nokia.com
+
+
+ Phil Roberts
+ Motorola
+ 1501 West Shure Drive
+ Arlington Heights, IL 60004
+ USA
+
+ Phone: +1 847-632-3148
+ EMail: QA3445@email.mot.com
+
+
+ Questions about this memo can be directed to:
+
+ Charles E. Perkins
+ Nokia Research Center
+ 313 Fairchild Drive
+ Mountain View, California 94043
+ USA
+
+ Phone: +1-650 625-2986
+ Fax: +1 650 625-2502
+ EMail: charliep@iprg.nokia.com
+
+
+ Pat R. Calhoun
+ Sun Microsystems Laboratories
+ 15 Network Circle
+ Menlo Park, California 94025
+ USA
+
+ Phone: +1 650-786-7733
+ Fax: +1 650-786-6445
+ EMail: pcalhoun@eng.sun.com
+
+
+
+Calhoun & Perkins Standards Track [Page 8]
+
+RFC 2794 Mobile Node NAI March 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS 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.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Calhoun & Perkins Standards Track [Page 9]
+