As per Relevance of the word registration, we have this rfc below:
Network Working Group P.
Request for Comments: 2794 Sun Microsystems
Updates: 2290 C.
Category: Standards Track Nokia Research
March 2000
Mobile IP Network Access Identifier Extension for IPv
Status of this
This document specifies an Internet standards track protocol for
Internet community, and requests discussion and suggestions
improvements. Please refer to the current edition of the "
Official Protocol Standards" (STD 1) for the standardization
and status of this protocol. Distribution of this memo is unlimited
Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
AAA servers are in use within the Internet today to
authentication and authorization services for dial-up computers
Such services are likely to be equally valuable for mobile
using Mobile IP when the nodes are attempting to connect to
domains with AAA servers. AAA servers today identify clients
using the Network Access Identifier (NAI). Our proposal defines a
for the mobile node to identify itself, by including the NAI
with the Mobile IP Registration Request. This memo also updates
2290 which specifies the Mobile-IPv4 Configuration option for IPCP
by allowing the Mobile Node's Home Address field of this option to
zero
Calhoun & Perkins Standards Track [Page 1]
RFC 2794 Mobile Node NAI March 2000
1.
AAA servers are in use within the Internet today to
authentication and authorization services for dial-up computers
Such services are likely to be equally valuable for mobile
using Mobile IP when the nodes are attempting to connect to
domains with AAA servers. AAA servers today identify clients
using the Network Access Identifier (NAI) [1]. This
specifies the Mobile Node NAI extension to the Mobile IP
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
that function. Thus, it is possible for a mobile node
authenticate itself, and be authorized for connection to the
domain, without even having a home address. A message containing
Mobile Node NAI extension MAY set the Home Address field to zero (0)
in the Registration Request, to request that a home address
assigned
The "Mobile-IPv4 Configuration" option to IPCP has been specified
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
of the option MUST not be zero. However, in the context of this
which allows a mobile node to be identified by its NAI and to
an address after the PPP phase of connection establishment, the
Address field is allowed to be zero while maintaining all
aspects of RFC 2290. Interpretation of various scenarios from
2290 is given in section 4.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
document are to be interpreted as described in [3].
2. Mobile Node NAI
The Mobile Node NAI extension, shown in figure 1, contains the
name following the format defined in [1]. When it is present in
Registration Request, the Home Address field MAY be set to zero (0).
The Mobile Node NAI extension MUST appear in the Registration
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
Type 131 (skippable) [7]
Length The length in bytes of the MN-NAI
MN-NAI A string in the NAI format defined in [1].
3. Foreign Agent
If Home Address is zero in the Registration Request, the
agent MUST use the NAI instead in its pending registration
records, along with the Identification field as usual. If
foreign agent cannot manage pending registration request records
this way, it MUST return a Registration Reply with Code
NONZERO_HOMEADDR_REQD (see section 5).
If the mobile node includes the Mobile Node NAI extension in
Registration Request, then the Registration Reply from the home
MUST include the Mobile Node NAI extension. If not, the
agent SHOULD send the Registration Reply to the mobile node,
the Code to the value MISSING_NAI (see section 5). The
Reply MUST include a nonzero Home Agent address and mobile node'
Home Address. If not, the foreign agent SHOULD send the
Reply to the mobile node, changing the Code to the
MISSING_HOME_AGENT or MISSING_HOMEADDR, respectively (see section 5).
4. Interactions with Mobile-IPv4 Configuration Option to
In the Mobile-IPv4 Configuration Option to IPCP [8], the
Node's Home Address field may be zero. In this section, we
the action to be taken in that case, when the mobile node is
the Mobile Node NAI extension in the Mobile IP Registration Request
Whether or not the IP Address Configuration Option contains a
IP address, the mobile node will subsequently attempt to obtain
home address from the Mobile IP Registration Reply
If the IP Address Configuration Option to IPCP has IP address
to zero, the PPP peer is expected to allocate and assign a co-
care-of address to the Mobile Node. If, on the other hand, the
Calhoun & Perkins Standards Track [Page 3]
RFC 2794 Mobile Node NAI March 2000
Address Configuration Option to IPCP has a nonzero IP address,
PPP peer is expected to assign that address to the Mobile Node as
co-located care-of address
Finally, if the IP Address Configuration Option is left out of
IPCP Configure-Request, then no co-located care of address
assigned during IPCP. The mobile node will acquire a co-located
of address during a later stage of configuration or will use an FA
located care-of address
5. Error
Each entry in the following table contains the name and value for
Code [7] to be returned in a Registration Reply, and the section
which the error Code is first mentioned in this specification
Error Name Value Section of
---------------------- ----- -------------------
NONZERO_HOMEADDR_REQD 96 3
MISSING_NAI 97 3
MISSING_HOME_AGENT 98 3
MISSING_HOMEADDR 99 3
6. IANA
The Mobile Node NAI extension defined in Section 2 is a Mobile
registration extension as defined in RFC 2002 [7] and extended in
2356 [6]. IANA should assign a value of 131 for this purpose
The Code values defined in Section 5 are error codes as defined
RFC 2002 and extended in RFC 2344 [5] and RFC 2356 [6].
correspond to error values conventionally associated with
by the foreign agent (i.e., values from the range 64-127).
should record the values as defined in Section 5.
7. Security
Mobile IP registration messages are authenticated, and
authentication verified by the recipient. This proposal does
prohibit the mobile node from sending its NAI in the clear over
network, but that is not expected to be a security issue
8. IPv6
Supporting NAI-based registrations for Mobile IPv6 [4] is outside
scope of this document. This section contains some ideas
Stateless Address Autoconfiguration [9] and DHCPv6 [2] might
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
mechanisms by which a mobile node may present its credentials,
as exist today with IPv4. Nevertheless, a mobile node using IPv
mobility may wish to specify the domain in which their
may be checked, by using a NAI just as this specification
for IPv4. In the case of IPv6, however, there is no foreign agent
place to manage the connectivity of the mobile node, and thus
manage the verification of the credentials offered by the
node. To identify the HDAF (see appendix A) that has the
relationship with the mobile node, the NAI would have to be
to a local AAA by the local agent involved with configuring
care-of address of the mobile node
This agent can either be a router sending out Router
[9], or a DHCPv6 server. In the former case, the router could
its ability to handle the NAI by attaching some yet to be
option to the Router Advertisement. In the latter case, for
links, the mobile node could include a yet to be defined
extension in its DHCP Solicitation message. Such an NAI
and appropriate authentication would also be required on
subsequent DHCP Request sent by the mobile node to the DHCP
selected on the basis of received DHCP Advertisements. Once a care
of address on the foreign network has been obtained, the mobile
can use regular MIPv6 [4].
9.
The authors would like to thank Gabriel Montenegro and Vipul
for their useful discussions. Thanks to Basaravaj Patil and
McCann for text describing actions to be taken when the home
is zero but the mobile node wishes to use the Mobile-IPv
Configuration Option to IPCP defined in RFC 2290.
[1] Aboba, B. and M. Beadles, "The Network Access Identifier",
2486, January 1999.
[2] Bound, J. and C. Perkins, "Dynamic Host Configuration
for IPv6 (DHCPv6)", Work in Progress
[3] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997.
[4] Johnson, D. and C. Perkins "Mobility Support in IPv6", Work
Progress
Calhoun & Perkins Standards Track [Page 5]
RFC 2794 Mobile Node NAI March 2000
[5] Montenegro, G., "Reverse Tunneling for Mobile IP", RFC 2344,
1998.
[6] Montenegro, G. and V. Gupta, "Sun's SKIP Firewall Traversal
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
PPP IPCP", RFC 2290, February 1998.
[9] Thomson, S. and T. Narten, "IPv6 Stateless
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
Allocation Function (HDAF) that can dynamically assign a Home
to the mobile node
Figure 2 illustrates the Home HDAF, which receives messages
foreign agents (e.g., FA) and assigns a Home Address within the
Domain. The HDAF does not perform any Mobile IP processing on
Registration Request, but simply forwards the request to a Home
(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.
then finds the HDAF that handles requests for the mobile node'
domain. The discovery protocol is outside of the scope of
specification. As an example, however, FA might delegate the duty
finding a HDAF to a local AAA server. The local AAA server may
assist FA in the process of verifying the credentials of the
node, using protocols not specified in this document
Calhoun & Perkins Standards Track [Page 7]
RFC 2794 Mobile Node NAI March 2000
The working group can be contacted via the current chairs
Basavaraj
Nokia
6000 Connection
M/S M8-540
Irving, TX 75039
Phone: +1 972-894-6709
Fax : +1 972-894-5349
EMail: Basavaraj.Patil@nokia.
Phil
1501 West Shure
Arlington Heights, IL 60004
Phone: +1 847-632-3148
EMail: QA3445@email.mot.
Questions about this memo can be directed to
Charles E.
Nokia Research
313 Fairchild
Mountain View, California 94043
Phone: +1-650 625-2986
Fax: +1 650 625-2502
EMail: charliep@iprg.nokia.
Pat R.
Sun Microsystems
15 Network
Menlo Park, California 94025
Phone: +1 650-786-7733
Fax: +1 650-786-6445
EMail: pcalhoun@eng.sun.
Calhoun & Perkins Standards Track [Page 8]
RFC 2794 Mobile Node NAI March 2000
Full Copyright
Copyright (C) The Internet Society (2000). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Calhoun & Perkins Standards Track [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
