DHC Working Group H. Levkowetz
Internet-Draft ipUnplugged
Expires: August 1, 2004 Feb 2004
DHCP Option for Mobile IP Mobility Agents
<draft-ietf-dhc-mipadvert-opt-02.txt>
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress".
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt .
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html .
This Internet-Draft will expire on August 1, 2004.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
This document defines a Dynamic Host Configuration Protocol (DHCP)
option with sub-options. One sub-option is passed from the DHCP
Server to the DHCP Client to announce the presence of one or more
Mobile IP Mobility Agents. For each announced Mobility Agent,
information is provided which is the same as that of the Mobile IP
Agent Advertisement extension to ICMP Router Advertisements. There
is also one sub-option which may be used by a DHCP client to provide
identity information to the DHCP server.
Levkowetz Expires August 1, 2004 [Page 1]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1 Requirements Terminology . . . . . . . . . . . . . . . . 3
2.2 Mobile IP Terminology . . . . . . . . . . . . . . . . . 3
2.3 DHCP Terminology . . . . . . . . . . . . . . . . . . . . 3
3. Mobility Agent Information Option . . . . . . . . . . . . . . 3
3.1 Mobility Agent Information Option Definition . . . . . . 3
3.2 Network Access Identifier Sub-Option . . . . . . . . . . 5
3.3 Mobility Agent Announcement (Dynamic) Sub-Option . . . . 6
3.4 Mobility Agent Announcement (Static) Sub-Option . . . . 8
4. Mobility Agent Option Usage . . . . . . . . . . . . . . . . . 9
4.1 DHCP Server - Mobility Agent Interaction . . . . . . . . 9
4.2 Mobile Node Considerations . . . . . . . . . . . . . . . 10
4.3 DHCP Server Considerations . . . . . . . . . . . . . . . 10
5. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
Normative References . . . . . . . . . . . . . . . . . . . . . 12
Informative References . . . . . . . . . . . . . . . . . . . . 12
Author's Address . . . . . . . . . . . . . . . . . . . . . . . 13
A. Open issues . . . . . . . . . . . . . . . . . . . . . . . . . 13
Intellectual Property and Copyright Statements . . . . . . . . 14
Levkowetz Expires August 1, 2004 [Page 2]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
1. Introduction
There already exists a DHCP [RFC2131] option to announce Mobile IP v4
Home Agent addresses, this is described in [RFC2132]. There is,
however, no DHCP option available to announce Mobile IP v4 Foreign
Agents.
Announcement of available Mobile IP v4 Mobility Agents by means of
DHCP provides possibilities for selective and individual assignment
of Mobility Agents to Mobile Nodes. This in turn makes load-sharing
and selective service offerings easier. This draft describes a DHCP
option for announcing IPv4 Mobility Agents to DHCP Clients.
2. Terminology
2.1 Requirements Terminology
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 [RFC2119].
2.2 Mobile IP Terminology
The Mobile IP related terminology used in this document is described
in [RFC3344].
2.3 DHCP Terminology
The DHCP related terminology used in this document is described in
[RFC2131].
3. Mobility Agent Information Option
3.1 Mobility Agent Information Option Definition
This document defines a new DHCP Option called the Mobility Agent
Option. It is a "container" option for specific agent- supplied
sub-options. The format of the Mobility Agent option is:
Code Len Mobility Agent Information Field
+-------+------+------+------+------+------+--...-+------+
| TBD | N | a1 | a2 | a3 | a4 | | aN |
+-------+------+------+------+------+------+--...-+------+
The length N gives the total number of octets in the Mobility Agent
Field. The Mobility Agent Information field consists of a sequence
Levkowetz Expires August 1, 2004 [Page 3]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
of SubOpt/Length/Value tuples for each sub-option, encoded in the
following manner:
Levkowetz Expires August 1, 2004 [Page 4]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 1 | N | s1 | s2 | s3 | s4 | | sN |
+------+------+------+------+------+------+--...-+------+
SubOpt Len Sub-option Value
+------+------+------+------+------+------+--...-+------+
| 2 | N | t1 | t2 | t3 | t4 | | tN |
+------+------+------+------+------+------+--...-+------+
...
The length N of the DHCP Mobility Agent Information Option shall
include all bytes of the sub-option code/length/value tuples. Since
at least one sub-option must be included in the option, the minimum
Mobility Agent Information length is two (2). The length N of the
sub-options shall be the number of octets in only that sub-option's
value field. A sub-option length may not be zero; if the only
purpose of a sub-option is to signal a boolean value, a flag byte
MUST be defined to carry that value. The sub-options need not appear
in any particular order. There is no 255 (End) sub-option defined
for this option, so the Mobility Agent Information field SHALL NOT be
terminated with a 255 sub-option.
3.2 Network Access Identifier Sub-Option
The Network Access Identifier (NAI) defined in [RFC2486] is already
used in Mobile IP as an alternative to the home address as an
identifier of a mobile node [RFC2794].
o The Network Access Identifier sub-option of the Mobility Agent
Information Option MAY be used by the DHCP client to provide
identifying information to the DHCP server, as part of the
DHCPDISCOVER, DHCPREQUEST and DHCPINFORM messages. The server MAY
use this information in selecting mobility agent announcement
parameters for the client.
o If the client requests the server to provide the Mobility Agent
Option by including it in the Parameter Request List Option of a
DHCPDISCOVER, DHCPREQUEST or DHCPINFORM message, the client also
SHOULD include the Mobility Agent Option with the Network Access
Identifier sub-option in the DHCPDISCOVER message.
o The server MAY include the Network Access Identifier sub-option
from the client DHCPDISCOVER message in subsequent DHCPOFFER and
DHCPACK messages if the server used this sub-option in selecting
client parameters.
o The client MUST include the Network Access Identifier sub-option
in a DHCPREQUEST message if it included it in the DHCPDISCOVER
message.
Levkowetz Expires August 1, 2004 [Page 5]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
The number of this sub-option is 1.
The format of the Network Access Identifier sub-option is as follows:
SubOpt Len Sub-option Value
+------+-----+-----+-----+-----+-----+--...-+-----+
| 1 | N | Network Access Identifier |
+------+-----+-----+-----+-----+-----+--...-+-----+
3.3 Mobility Agent Announcement (Dynamic) Sub-Option
The Mobility Agent Announcement (Dynamic) sub-option announces the
address of one or more mobility agents, together with all the
information about the mobility agent which is normally found in a
Mobile IP Agent Advertisement extension to ICMP Router Advertisements
as described in [RFC3344].
All fields are defined so as to correspond to fields of the same name
in a Mobility Agent Advertisement Extension as described in
[RFC3344], and if in the future additional bits are allocated from
the 'reserved' field for the Mobility Agent Advertisement Extension,
they should be equally valid in a DHCP Mobility Agent option.
However, if RFC 3344 is revised and additional fields are defined for
the Mobility Agent Advertisement Extension, a new sub-option SHOULD
be defined to carry such a new format Mobility Agent Announcement.
This option may contain announcements of one Mobility Agents. If it
is desired to announce more than one Mobility Agent, multiple
instances of this sub-option may occur within the Mobility Agent
Information Option.
The number of this sub-option is 2.
SubOpt Len Sub-option Value (Announcements)
+------+-----+-----+-----+--...-+-----+
| 2 | N | Announcement |
+------+-----+-----+-----+--...-+-----+
The format of one Mobility Agent Announcement is as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Mobility Agent IP Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Levkowetz Expires August 1, 2004 [Page 6]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
| Type | Adv-Length | Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Registration Lifetime |R|B|H|F|M|G|r|T| reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| zero or more care-of addresses |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Agent IP Address
The address through which the Mobile Node may reach the announced
Mobility Agent in order to do a Mobile IP registration.
Type
16. This is the same value as for the type field in a Mobility
Agent Advertisement Extension as described in [RFC3344]. If other
Mobility Agent Advertisement Extensions are defined in the future,
this field will make it possible to differentiate between them
without using new DHCP option numbers.
Adv-Length
(6 + 4*N), where 6 accounts for the number of bytes in the
Sequence Number, Registration Lifetime, flags, and reserved
fields, and N is the number of care-of addresses advertised for
the Mobility Agent.
Sequence Number
The count of Mobility Agent DHCP announcements made since the DHCP
server was initialised or the Mobility Agent was re-booted,
starting at zero. This is a total count, not a per-client count.
If this count rolls over, it continues with the value 256
following the value 0xffff, to be able to distinguish a roll-over
from a Mobility Agent re-boot, (see Section 2.3.2 of [RFC3344]).
Note that this requires the DHCP server to have knowledge of part
of the state of the Mobility Agent; if the DHCP server does not
have this capability, the sub-option described in Section 3.4
should be used instead of the Mobility Agent Announcement
(Dynamic) sub-option.
Registration Lifetime
The longest lifetime (measured in seconds) that this agent is
willing to accept in any Registration Request. A value of 0xffff
indicates infinity.
R
Registration required. Registration with this foreign agent (or
another foreign agent listed in this DHCP option) is required even
when using a co-located care-of address.
B
Busy. The foreign agent will not accept registrations from
additional mobile nodes.
Note that this requires the DHCP server to have knowledge of part
of the state of the Mobility Agent; if the DHCP server does not
have this capability, the sub-option described in Section 3.4
Levkowetz Expires August 1, 2004 [Page 7]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
should be used instead of the Mobility Agent Announcement
(Dynamic) sub-option.
H
Home agent. This agent offers service as a home agent with the IP
address given in the announcement.
F
Foreign agent. This agent offers service as a foreign agent with
the IP address given in the announcement.
M
Minimal encapsulation. This agent implements receiving tunnelled
datagrams that use minimal encapsulation [RFC2004].
G
GRE encapsulation. This agent implements receiving tunnelled
datagrams that use GRE encapsulation [RFC1701].
r
Sent as zero; ignored on reception. SHOULD NOT be allocated for
any other uses.
T
Foreign agent supports reverse tunnelling [RFC3024].
reserved
Sent as zero; ignored on reception.
Care-of Address(es)
The foreign agent care-of address(es) provided by this foreign
agent. An DHCP Mobility Agent Announcement MUST include at least
one care-of address if the 'F' bit is set. The number of care-of
addresses present is determined by the Length field in the
Extension.
3.4 Mobility Agent Announcement (Static) Sub-Option
In the Mobility Agent Announcement (Dynamic) Sub-Option described
above, the 'B' bit and the 'Sequence Number' field is expected to
faithfully reflect the state of the Mobility Agent announced. This
requires continuous state information update between Mobility Agent
and DHCP Server, which will normally not be available to a
stand-alone DHCP Server.
The Mobility Agent Announcement (Static) Sub-Option is adapted to
this case. In format it is identical to the Mobility Agent
Announcement (Dynamic) Sub-Option, but it always has the 'B' bit and
the 'Sequence Number' field set to zero. Mobile Nodes which receive
this sub-option should be aware of this, and in particular should be
prepared to handle the case where a Mobility Agent is announced by
this DHCP Option and sub-option, but is found to be busy and not able
to handle new registrations when a registration attempt is made.
This sub-option may contain announcements of one Mobility Agent. If
it is desired to announce more than one Mobility Agent, multiple
Levkowetz Expires August 1, 2004 [Page 8]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
instances of this sub-option may occur within the Mobility Agent
Information Option.
The number of this sub-option is 3.
SubOpt Len Sub-option Value (Announcements)
+------+-----+-----+-----+--...-+-----+
| 3 | N | Announcement |
+------+-----+-----+-----+--...-+-----+
For both the Static and the Dynamic Mobility Agent Announcement
sub-option the following applies:
o The Mobility Agent Announcement sub-options of the Mobility Agent
Information Option MAY be used by the DHCP server to provide
Mobility Agent information to the DHCP client, as part of a
DHCPOFFER or DHCPACK message. If a Network Access Identifier
sub-option was provided by the client, it SHOULD be used to choose
the particular Mobility Agent or Agents to announce if the server
has more than one Mobility Agent to offer.
o If the server provides the Mobility Agent Option with a Mobility
Agent Announcement sub-option in a DHCPOFFER message, it also MUST
include the same Mobility Agent Option and sub-options in a
subsequent corresponding DHCPACK message.
4. Mobility Agent Option Usage
The requesting and sending of this option follows the rules for DHCP
options in [RFC2131].
4.1 DHCP Server - Mobility Agent Interaction
A stand-alone DHCP server providing the Mobility Agent Announcement
Sub-Option will normally not have any knowledge of the state of the
mobility agent which the sub-option refers to. This means that some
of the information in the announcement (such as the 'B' bit in
particular) cannot be dynamically updated. In this case, the
Mobility Agent Announcement (Static) Sub-Option SHOULD be used.
A DHCP server co-located with a Mobility Agent may have more
information about the dynamic state of the Mobility agent, and may
therefore be able to provide reliable state information in the
announcement. In this case, the Mobility Agent Announcement
(Dynamic) Sub-Option MAY be used. Mechanisms to provide state
information transfer between the Mobility Agent and the DHCP server
are not in the scope of this document.
Levkowetz Expires August 1, 2004 [Page 9]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
4.2 Mobile Node Considerations
A Mobile IP v4 Mobile Node may request the Mobility Agent Information
option at it's discretion. This may be done before, concurrently
with, or after doing an ICMP Mobility Agent Solicitation according to
[RFC3344], or without doing such an ICMP solicitation at all. It is
however expected that a common usage would be for a mobile node which
connects to a new access node to acquire a DHCP address and solicit
for FAs in parallel. To differentiate between possible services, the
Mobility Agents could be announced solely through DHCP by use of the
Mobility Agent Information Option with one of the Mobility Agent
Announcement sub-options, not by responding to router solicitations;
this way the Mobility Agent and service level offered could be
dependent on the NAI provided by the MN in the Network Access
Identifier sub-option.
When a Mobility Agent is announced by means of an ICMP Mobility Agent
Advertisement according to [RFC3344], the listening Mobile Node is
able to directly acquire the link-layer address of the Mobility Agent
from the advertisement message. If however the Mobility Agent is
advertised through the DHCP Mobility Agent Information Option, the
link-layer address will not be part of the advertisement, and it is
necessary for the Mobile Node to issue an ARP request for the
link-layer address corresponding to the Mobility Agent's IP address.
Further, when a Mobility Agent is announced by means of an ICMP
Mobility Agent Advertisement, the advertisement may also contain
information about the available on-link routers. When the Mobility
Agent announcement is done through the DHCP Mobility Agent
Information Option, the information about available routers SHOULD
instead be provided through the DHCP Router Option.
4.3 DHCP Server Considerations
By providing a NAI to the DHCP server (through use of the Network
Access Identifier Sub-Option), the Mobile Node makes it possible for
the server to match the realm of the NAI to a realm which is known to
the server through static configuration or possibly through a AAA
infrastructure. The exact mechanism used is however out of scope for
this specification.
If the DHCP server does not have the capability to match the realm of
the NAI provided by the Mobile Node against known realms, or if it
finds no matching realm, it MUST fall back to the method of matching
client to configuration parameters described in [RFC2131] (See
especially Section 2.1 of RFC 2131). It is for instance completely
acceptable to select parameter values for the Mobility Agent
Information Option Sub-Options based on the hardware address or
Levkowetz Expires August 1, 2004 [Page 10]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
client-identifier of the client.
An alternative to providing the NAI to the DHCP server for use in
selecting Mobility Agent parameters could be to use a mechanism such
as the one described in [RADIUS-SUBOPT] to provide Mobility Agent
information obtained through AAA authentication to the DHCP server
for subsequent delivery to a client using the Mobility Agent
Information Option.
5. Security Considerations
Mobile IP Agent Advertisements as described in [RFC3344] requires no
authentication for Agent Advertisement and Agent Solicitation
messages.
DHCP provides an authentication mechanism, as described in [RFC3118],
which may be used if authentication is required before offering the
Mobility Agent option described here. Because it may be cumbersome
or practically impossible to distribute keys to foreign networks a
Mobile Node may visit, the ability to use the DHCP authentication
mechanism is not viewed as a major advantage of distributing Mobility
Agent Announcements through DHCP rather than through regular ICMP
Mobile IP Agent Advertisements.
By providing Agent Advertisements by means of DHCP as an alternative
to extended ICMP Router Advertisement messages it is possible to do
so more selectively, and it does not offer any new threat to the
internet.
6. IANA Considerations
This document defines one new DHCP v4 option value, and one new
sub-type numbering space to be managed by IANA.
Section 3.1 defines a new DHCP v4 option value, the Mobility Agent
Information Option. The type number for this option is [TBD,
assigned by IANA]. This option introduces a new sub-type numbering
space where the values 1, 2 and 3 has been assigned values in this
document. Approval of new Mobility Agent Information Option sub-type
numbers is subject to Expert Review, and a specification is required
[RFC2434].
The value for the DHCP_MIP_OPTION code must be assigned from the
numbering space defined for public DHCP Options in [RFC2939].
7. Acknowledgements
Normative References
Levkowetz Expires August 1, 2004 [Page 11]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 2434,
October 1998.
[RFC2486] Aboba, B. and M. Beadles, "The Network Access Identifier",
RFC 2486, January 1999.
[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
Messages", RFC 3118, June 2001.
[RFC3344] Perkins, C., "IP Mobility Support for IPv4", RFC 3344,
August 2002.
Informative References
[RFC1701] Hanks, S., Li, T., Farinacci, D. and P. Traina, "Generic
Routing Encapsulation (GRE)", RFC 1701, October 1994.
[RFC2004] Perkins, C., "Minimal Encapsulation within IP", RFC 2004,
October 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2794] Calhoun, P. and C. Perkins, "Mobile IP Network Access
Identifier Extension for IPv4", RFC 2794, March 2000.
[RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
of New DHCP Options and Message Types", BCP 43, RFC 2939,
September 2000.
[RFC3024] Montenegro, G., "Reverse Tunneling for Mobile IP,
revised", RFC 3024, January 2001.
[RADIUS-SUBOPT]
Droms, R. and J. Schnizlein, "RADIUS Attributes Sub-option
for the DHCP Relay Agent Information Option",
draft-ietf-dhc-agentopt-radius-03 (work in progress),
November 2003.
Levkowetz Expires August 1, 2004 [Page 12]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
Author's Address
Henrik Levkowetz
ipUnplugged AB
Arenavagen 33
Stockholm S-121 28
SWEDEN
Phone: +46 8 725 9513
EMail: henrik@levkowetz.com
Appendix A. Open issues
(This section should be removed by the RFC editor before publication)
Discussion about this draft should be sent to dhcwg@ietf.org.
Open issues relating to this specification are tracked on the
following web site: http://www.mip4.org/issues/tracker/mip4/
The current working documents for this draft are available at this
web site: http://ietf.levkowetz.com/drafts/dhc/mipadvert/
Levkowetz Expires August 1, 2004 [Page 13]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2004). 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 assignees.
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
Levkowetz Expires August 1, 2004 [Page 14]
Internet-Draft DHCP Option for Mobility Agents Feb 2004
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Levkowetz Expires August 1, 2004 [Page 15]
