doc: Add RFC documents

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]
+