draft-ietf-dhc-agentopt-radius-05.txt   draft-ietf-dhc-agentopt-radius-06.txt 
Network Working Group R. Droms Network Working Group R. Droms
Internet-Draft J. Schnizlein Internet-Draft J. Schnizlein
Expires: September 30, 2004 Cisco Systems Expires: October 11, 2004 Cisco Systems
April 1, 2004 April 12, 2004
RADIUS Attributes Sub-option for the DHCP Relay Agent Information RADIUS Attributes Sub-option for the DHCP Relay Agent Information
Option Option
draft-ietf-dhc-agentopt-radius-05.txt draft-ietf-dhc-agentopt-radius-06.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, I certify that any applicable
all provisions of Section 10 of RFC2026. patent or other IPR claims of which I am aware have been
disclosed, and any of which I become aware will be disclosed, in
accordance with RFC 3667.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six
and may be updated, replaced, or obsoleted by other documents at any months and may be updated, replaced, or obsoleted by other
time. It is inappropriate to use Internet-Drafts as reference documents at any time. It is inappropriate to use Internet-Drafts
material or to cite them other than as "work in progress." as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on September 30, 2004. This Internet-Draft will expire on October 11, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
A NAS (network access server) may choose to authenticate the identity A NAS (network access server) may choose to authenticate the
of a device before granting that device access to the network. The identity of a device before granting that device access to the
IEEE 802.1X protocol is an example of a mechanism for providing network. The IEEE 802.1X protocol is an example of a mechanism
authenticated layer 2 network access. A network element using RADIUS for providing authenticated layer 2 network access. A network
as an authentication authority will receive attributes from a RADIUS element using RADIUS as an authentication authority will receive
server that may be used by a DHCP server in the selection of attributes from a RADIUS server that may be used by a DHCP server
configuration parameters to be delivered to the device through its in the selection of configuration parameters to be delivered to
DHCP client. The RADIUS Attributes sub-option enables a network the device through its DHCP client. The RADIUS Attributes
element to pass along attributes for the user of a device received sub-option enables a network element to pass along attributes for
during RADIUS authentication to a DHCP server. the user of a device received during RADIUS authentication to a
DHCP server.
1. Introduction and Background 1. Introduction and Background
The RADIUS Attributes sub-option for the DHCP Relay Agent option The RADIUS Attributes sub-option for the DHCP Relay Agent option
provides a way in which network elements can pass information provides a way in which a NAS can pass attributes obtained from a
obtained through layer 2 authentication to a DHCP server [2]. IEEE RADIUS server to a DHCP server [1]. IEEE 802.1X [2] is an example
802.1X is an example of a mechanism through which a NAS such as a of a mechanism through which a NAS such as a switch or a wireless
switch or a wireless LAN access point can authenticate the identity LAN access point can authenticate the identity of the user of a
of the user of a device before providing layer 2 network access using device before providing layer 2 network access using RADIUS as the
RADIUS as the Authentication Service specified in RFC3580 [9]. In Authentication Service specified in RFC3580 [10]. In 802.1X
802.1X authenticated access, a device must first exchange some authenticated access, a device must first exchange some
authentication credentials with the NAS. The NAS then supplies these authentication credentials with the NAS. The NAS then supplies
credentials to a RADIUS server, which either confirms or denies the these credentials to a RADIUS server, which eventually sends
identity of the user of the device requesting network access. The either an Access-Accept or an Access-Reject in response to an
NAS, based on the reply of the RADIUS server, then allows or denies Access-Request. The NAS, based on the reply of the RADIUS server,
network access to the requesting device. then allows or denies network access to the requesting device.
Figure 1 summarizes the message exchange among the participants in Figure 1 summarizes the message exchange among the participants in
IEEE 802.1X authentication. IEEE 802.1X authentication.
+-----------------+ +-----------------+
|Device requesting| |Device requesting|
| network access | | network access |
+-----------------+ +-----------------+
| ^ | ^
| | | |
skipping to change at page 2, line 43 skipping to change at page 3, line 27
v | v |
+-----------------+ +-----------------+
| NAS | | NAS |
|(802.1X and DHCP | |(802.1X and DHCP |
| relay agent} | | relay agent} |
+-----------------+ +-----------------+
| ^ | ^
| | | |
(2) Request for authentication (2) Request for authentication
| | | |
| (3) Authentication confirm/deny | (3) Access-Accept/Reject
v | v |
+-----------------+ +-----------------+
| RADIUS | | RADIUS |
| Service | | Server |
+-----------------+ +-----------------+
Figure 1 Figure 1
In the application described in this document, the access device acts
as an 802.1X Authenticator and adds DHCP relay agent options to DHCP
messages. At the successful conclusion of IEEE 802.1X authentication,
a RADIUS Access-Accept provides attributes for service authorizations
to the NAS. The NAS stores these attributes locally. When the NAS
subsequently forwards DHCP messages from the network device, the NAS
adds these attributes in a RADIUS Attributes sub-option. The RADIUS
Attributes sub-option is another suboption of the Relay Agent
Information option [4].
This document uses IEEE 802.1X as an example to motivate the use of In the application described in this document, the access device
RADIUS by a NAS. The RADIUS Attributes sub-option described in this acts as an 802.1X Authenticator and adds DHCP relay agent options
document is not limited to use in conjunction with IEEE 802.1X and to DHCP messages. At the successful conclusion of IEEE 802.1X
can be used to carry RADIUS attributes obtained by the relay agent authentication, a RADIUS Access-Accept provides attributes for
for any reason. service authorizations to the NAS. The NAS stores these
attributes locally. When the NAS subsequently forwards DHCP
messages from the network device, the NAS adds these attributes in
a RADIUS Attributes sub-option. The RADIUS Attributes sub-option
is another suboption of the Relay Agent Information option [5].
This document uses IEEE 802.1X as an example to motivate the use
of RADIUS by a NAS. The RADIUS Attributes sub-option described in
this document is not limited to use in conjunction with IEEE
802.1X and can be used to carry RADIUS attributes obtained by the
relay agent for any reason.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
document are to be interpreted as described in RFC 2119 [1]. in this document are to be interpreted as described in RFC 2119
[3].
2.1 DHCP Terminology 2.1 DHCP Terminology
The following terms are used as defined in RFC2131 and RFC3046: DHCP The following terms are used as defined in RFC2131 and RFC3046:
relay agent, DHCP server, DHCP client. DHCP relay agent, DHCP server, DHCP client.
2.2 RADIUS Terminology 2.2 RADIUS Terminology
The following terms are used in conjunction with RADIUS: The following terms are used in conjunction with RADIUS:
RADIUS server: An entity that provides RADIUS service through the RADIUS server: A RADIUS server is responsible for receiving user
exchange of RADIUS protocol messages connection requests, authenticating the user, and then
Attribute: Data value carried in a RADIUS protocol message returning all configuration information necessary for the
NAS: Network access server; unlike traditional dial NAS, the NAS client to deliver service to the user.
considered here may not have a protocol like PPP through which it Attribute: A Type-Length-Value tuple encapsulating data elements
can pass configuration information from the RADIUS attributes to as defined in RFC 2865 [4].
the client NAS: A Network Access Server (NAS) provides access to the network
and operates as a client of RADIUS. The client is responsible
for passing user information to designated RADIUS servers, and
then acting on the response which is returned. Unlike a
traditional dial NAS, the NAS considered here may not have a
protocol like PPP through which it can pass configuration
information from the RADIUS attributes to the client
2.3 802.1X Terminology 2.3 802.1X Terminology
The following terms are used as defined in the IEEE 802.1X protocol: The following terms are used as defined in the IEEE 802.1X
Authenticator, Supplicant. protocol: Authenticator, Supplicant.
3. RADIUS Attributes sub-option format 3. RADIUS Attributes sub-option format
The RADIUS Attributes Sub-option is a new sub-option for the DHCP The RADIUS Attributes Sub-option is a new sub-option for the DHCP
Relay Agent option. Relay Agent option.
The format of the RADIUS Attributes sub-option is: The format of the RADIUS Attributes sub-option is:
SubOpt Len RADIUS attributes SubOpt Len RADIUS attributes
code code
+-------+-----+------+------+------+------+--...-+------+ +-------+-----+------+------+------+------+--...-+------+
| TBD | N | b1 | b2 | b3 | b4 | | bN | | TBD | N | o1 | o2 | o3 | o4 | | oN |
+-------+-----+------+------+------+------+--...-+------+ +-------+-----+------+------+------+------+--...-+------+
The RADIUS attributes are encoded according to the encoding rules in The RADIUS attributes are encoded according to the encoding rules
RFC 2865, in bytes b1...bN. in RFC 2865, in octets b1...bN.
The NAS truncates the RADIUS attributes to fit in the RADIUS
Attributes sub-option. For predictable behavior, the RADIUS
server should be configured to return few than 255 octets of
RADIUS attributes.
4. RADIUS Server Behavior 4. RADIUS Server Behavior
The RADIUS server that implements this specification MUST be The RADIUS server that implements this specification MUST be
configured to return the User-Name and Class attributes to the NAS, configured to return the User-Name and Class attributes to the
and MAY return other attributes. NAS, and MAY return other attributes.
To avoid dependencies between the address allocation and other state To avoid dependencies between the address allocation and other
information between the RADIUS server and the DHCP server, only the state information between the RADIUS server and the DHCP server,
attributes in the table below SHOULD be included in this sub-option. only the attributes in the table below SHOULD be included in this
Because RADIUS servers rely on the directive in section 1.1 or RFC sub-option. Because RADIUS servers rely on the directive in
2865 that "A NAS MUST treat a RADIUS access-accept authorizing an section 1.1 or RFC 2865 that "A NAS MUST treat a RADIUS
unavailable service as an access-reject instead.", a RADIUS server access-accept authorizing an unavailable service as an
SHOULD send only those attributes for which the relay agent can access-reject instead.", a RADIUS server SHOULD send only those
ensure that either the relay agent or the DHCP server will provide attributes for which the relay agent can ensure that either the
the associated service. The following table, based on the analysis relay agent or the DHCP server will provide the associated
in RFC 3580 [9], lists attributes that MAY be included: service. The following table, based on the analysis in RFC 3580
[10], lists attributes that MAY be included:
# Attribute # Attribute
--- --------- --- ---------
1 User-Name (RFC 2865 [3]) 1 User-Name (RFC 2865 [3])
4 NAS-IP-Address (RFC 2865) 4 NAS-IP-Address (RFC 2865)
6 Service-Type (RFC 2865) 6 Service-Type (RFC 2865)
25 Class (RFC 2865) 25 Class (RFC 2865)
26 Vendor-Specific (RFC 2865) 26 Vendor-Specific (RFC 2865)
27 Session-Timeout (RFC 2865) 27 Session-Timeout (RFC 2865)
30 Called-Station-Id (RFC 2865) 30 Called-Station-Id (RFC 2865)
31 Calling-Station-Id (RFC 2865) 31 Calling-Station-Id (RFC 2865)
32 NAS-Identifier (RFC 2865) 32 NAS-Identifier (RFC 2865)
44 Acct-Session-Id (RFC 2866 [5]) 44 Acct-Session-Id (RFC 2866 [5])
50 Acct-Multi-Session-Id (RFC 2866) 50 Acct-Multi-Session-Id (RFC 2866)
87 NAS-Port-Id (RFC 2869 [6]) 87 NAS-Port-Id (RFC 2869 [6])
88 Framed-Pool (RFC 2869) 88 Framed-Pool (RFC 2869)
100 Framed-IPv6-Pool (RFC 3162 [8]) 100 Framed-IPv6-Pool (RFC 3162 [8])
5. DHCP Relay Agent Behavior 5. DHCP Relay Agent Behavior
When the DHCP relay agent receives a DHCP message from the client, it When the DHCP relay agent receives a DHCP message from the client,
MAY append a DHCP Relay Agent Information option containing the it MAY append a DHCP Relay Agent Information option containing the
RADIUS Attributes sub-option, along with any other sub-options it is RADIUS Attributes sub-option, along with any other sub-options it
configured to supply. The RADIUS Attributes sub-option MUST only is configured to supply. The RADIUS Attributes sub-option MUST
contain the attributes provided in the RADIUS Access/Accept message. only contain the attributes provided in the RADIUS Access/Accept
The DHCP relay agent MUST NOT add more than one RADIUS Attributes message. The DHCP relay agent MUST NOT add more than one RADIUS
sub-option in a message. Attributes sub-option in a message.
The relay agent SHOULD include the User-Name and Class attributes in The relay agent SHOULD include the User-Name and Class attributes
the RADIUS Attributes sub-option if available, and MAY include other in the RADIUS Attributes sub-option if available, and MAY include
attributes. other attributes.
6. DHCP Server Behavior 6. DHCP Server Behavior
When the DHCP server receives a message from a relay agent containing When the DHCP server receives a message from a relay agent
a RADIUS Attributes sub-option, it extracts the contents of the containing a RADIUS Attributes sub-option, it extracts the
sub-option and uses that information in selecting configuration contents of the sub-option and uses that information in selecting
parameters for the client. Even if the relay agent forwards other configuration parameters for the client. If the relay agent
RADIUS attributes from the RADIUS server, the DHCP server SHOULD forwards RADIUS attributes not included in the table in Section 4,
ignore any attributes it receives for which it cannot ensure that the the DHCP server SHOULD ignore them. If the DHCP server uses
associated service will be provided either by the DHCP server or the attributes not specified here, it might result in side effects not
relay agent. If the DHCP server uses attributes not specified here, anticipated in the existing RADIUS specifications.
it might result in side effects not anticipated in the existing
RADIUS specifications.
7. DHCP Client Behavior 7. DHCP Client Behavior
Relay agent options are exchanged only between relay agents and DHCP Relay agent options are exchanged only between relay agents and
server, so DHCP clients are never aware of their use. DHCP server, so DHCP clients are never aware of their use.
8. Security Considerations 8. Security Considerations
Message authentication in DHCP for intradomain use where the Message authentication in DHCP for intradomain use where the
out-of-band exchange of a shared secret is feasible is defined in RFC out-of-band exchange of a shared secret is feasible is defined in
3118 [7]. Potential exposures to attack are discussed in section 7 RFC 3118 [8]. Potential exposures to attack are discussed in
of the DHCP protocol specification in RFC 2131. section 7 of the DHCP protocol specification in RFC 2131.
The DHCP Relay Agent option depends on a trusted relationship between The DHCP Relay Agent option depends on a trusted relationship
the DHCP relay agent and the server, as described in section 5 of RFC between the DHCP relay agent and the server, as described in
3046. While the introduction of fraudulent relay-agent options can section 5 of RFC 3046. While the introduction of fraudulent
be prevented by a perimeter defense that blocks these options unless relay-agent options can be prevented by a perimeter defense that
the relay agent is trusted, a deeper defense using the authentication blocks these options unless the relay agent is trusted, a deeper
option for relay agent options [10] or IPsec [11] SHOULD be deployed defense using the authentication option for relay agent options
as well. [11] or IPsec [12] SHOULD be deployed as well.
9. IANA Considerations 9. IANA Considerations
IANA has assigned the value of TBD for the DHCP Relay Agent IANA has assigned the value of TBD for the DHCP Relay Agent
Information option sub-option code for this sub-option. This Information option sub-option code for this sub-option. This
document does not define any new namespaces or other constants for document does not define any new namespaces or other constants for
which IANA must maintain a registry. which IANA must maintain a registry.
10. Acknowledgments 10. Acknowledgments
Bernard Aboba's expert advice on avoiding RADIUS entanglements is Bernard Aboba's expert advice on avoiding RADIUS entanglements is
gratefully acknowledged. gratefully acknowledged.
Normative References Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [1] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
March 1997. March 1997.
[3] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote [2] Institute of Electrical and Electronics Engineers, "Local and
Metropolitan Area Networks: Port based Network Access
Control", IEEE Standard 802.1X, March 2001.
[3] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Rigney, C., Willens, S., Rubens, A. and W. Simpson, "Remote
Authentication Dial In User Service (RADIUS)", RFC 2865, June Authentication Dial In User Service (RADIUS)", RFC 2865, June
2000. 2000.
[4] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [5] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046,
January 2001. January 2001.
Informative References Informative References
[5] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000. [6] Rigney, C., "RADIUS Accounting", RFC 2866, June 2000.
[6] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions", [7] Rigney, C., Willats, W. and P. Calhoun, "RADIUS Extensions",
RFC 2869, June 2000. RFC 2869, June 2000.
[7] Droms, R. and W. Arbaugh, "Authentication for DHCP Messages", [8] Droms, R. and W. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[8] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC 3162, [9] Aboba, B., Zorn, G. and D. Mitton, "RADIUS and IPv6", RFC
August 2001. 3162, August 2001.
[9] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese, "IEEE [10] Congdon, P., Aboba, B., Smith, A., Zorn, G. and J. Roese,
802.1X Remote Authentication Dial In User Service (RADIUS) "IEEE 802.1X Remote Authentication Dial In User Service
Usage Guidelines", RFC 3580, September 2003. (RADIUS) Usage Guidelines", RFC 3580, September 2003.
[10] Stapp, M. and T. Lemon, "The Authentication Suboption for the [11] Stapp, M. and T. Lemon, "The Authentication Suboption for
DHCP Relay Agent Option", draft-ietf-dhc-auth-suboption-02 the DHCP Relay Agent Option",
(work in progress), October 2003. draft-ietf-dhc-auth-suboption-02 (work in progress), October
2003.
[11] Droms, R., "Authentication of DHCP Relay Agent Options Using [12] Droms, R., "Authentication of DHCP Relay Agent Options Using
IPsec", draft-ietf-dhc-relay-agent-ipsec-00 (work in progress), IPsec", draft-ietf-dhc-relay-agent-ipsec-00 (work in
September 2003. progress), September 2003.
Authors' Addresses Authors' Addresses
Ralph Droms Ralph Droms
Cisco Systems Cisco Systems
1414 Massachusetts Avenue 1414 Massachusetts Avenue
Boxborough, MA 01719 Boxborough, MA 01719
USA USA
EMail: rdroms@cisco.com EMail: rdroms@cisco.com
skipping to change at page 8, line 8 skipping to change at page 9, line 8
Cisco Systems Cisco Systems
9123 Loughran Road 9123 Loughran Road
Fort Washington, MD 20744 Fort Washington, MD 20744
USA USA
EMail: jschnizl@cisco.com EMail: jschnizl@cisco.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed
pertain to the implementation or use of the technology described in to pertain to the implementation or use of the technology
this document or the extent to which any license under such rights described in this document or the extent to which any license
might or might not be available; neither does it represent that it under such rights might or might not be available; nor does it
has made any effort to identify any such rights. Information on the represent that it has made any independent effort to identify any
IETF's procedures with respect to rights in standards-track and such rights. Information on the IETF's procedures with respect to
standards-related documentation can be found in BCP-11. Copies of rights in IETF Documents can be found in BCP 78 and BCP 79.
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 Copies of IPR disclosures made to the IETF Secretariat and any
copyrights, patents or patent applications, or other proprietary assurances of licenses to be made available, or the result of an
rights which may cover technology that may be required to practice attempt made to obtain a general license or permission for the use
this standard. Please address the information to the IETF Executive of such proprietary rights by implementers or users of this
Director. specification can be obtained from the IETF on-line IPR repository
at http://www.ietf.org/ipr.
The IETF has been notified of intellectual property rights claimed in The IETF invites any interested party to bring to its attention
regard to some or all of the specification contained in this any copyrights, patents or patent applications, or other
proprietary rights that may cover technology that may be required
to implement this standard. Please address the information to the
IETF at ietf-ipr@ietf.org.
The IETF has been notified of intellectual property rights claimed
in regard to some or all of the specification contained in this
document. For more information consult the online list of claimed document. For more information consult the online list of claimed
rights. rights.
Full Copyright Statement Disclaimer of Validity
Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on
others, and derivative works that comment on or otherwise explain it an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
or assist in its implementation may be prepared, copied, published REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND
and distributed, in whole or in part, without restriction of any THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES,
kind, provided that the above copyright notice and this paragraph are EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT
included on all such copies and derivative works. However, this THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR
document itself may not be modified in any way, such as by removing ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A
the copyright notice or references to the Internet Society or other PARTICULAR PURPOSE.
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 Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2004). This document is
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING subject to the rights, licenses and restrictions contained in BCP
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 78, and except as set forth therein, the authors retain all their
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION rights.
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/