1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
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]
^L
|