From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc2794.txt | 507 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 507 insertions(+) create mode 100644 doc/rfc/rfc2794.txt (limited to 'doc/rfc/rfc2794.txt') 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] + -- cgit v1.2.3