draft-ietf-dhc-l2ra-01.txt   draft-ietf-dhc-l2ra-02.txt 
DHC Working Group B. Joshi DHC Working Group B. Joshi
Internet-Draft P. Kurapati Internet-Draft P. Kurapati
Expires: November 17, 2008 Infosys Technologies Ltd. Expires: April 4, 2009 Infosys Technologies Ltd.
May 16, 2008 October 1, 2008
Layer 2 Relay Agent Information Layer 2 Relay Agent Information
draft-ietf-dhc-l2ra-01.txt draft-ietf-dhc-l2ra-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://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 November 17, 2008. This Internet-Draft will expire on April 4, 2009.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract Abstract
In some networks, DHCP servers rely on Relay Agent Information option In some networks, DHCP servers rely on Relay Agent Information option
appended by Relay Agents for IP address and other parameter appended by Relay Agents for IP address and other parameter
assignment policies. This works fine when end hosts are directly assignment policies. This works fine when end hosts are directly
connected to Relay Agents. In some network configurations, one or connected to Relay Agents. In some network configurations, one or
more Layer 2 devices may reside between DHCP clients and Relay agent. more Layer 2 devices may reside between DHCP clients and Relay agent.
In these network scenarios, it is difficult to use the Relay Agent In these network scenarios, it is difficult to use the Relay Agent
Information option for IP address and other parameter assignment Information option for IP address and other parameter assignment
policies effectively. So there is a need for the device that is policies effectively. So there is a need for the device that is
closest to the end hosts to append Relay Agent Information option in closest to the end hosts to append Relay Agent Information option in
DHCP messages. These devices are typically known as Layer 2 Relay DHCP messages. These devices are typically known as Layer 2 Relay
Agents. Agents.
This document aims to describe the network scenarios where Layer 2 This document aims to describe the network scenarios where Layer 2
Relay Agent is in use and also how it handles DHCP messages. Relay Agent is in use and also how it handles DHCP messages.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 5 3. Need of Layer 2 Relay Agent . . . . . . . . . . . . . . . . . 6
4. Layer 2 Relay Agent in various network scenarios . . . . . . . 6 4. Layer 2 Relay Agent in various network scenarios . . . . . . . 7
4.1. DHCP server and client on same subnet . . . . . . . . . . 6 4.1. DHCP server and client on same subnet . . . . . . . . . . 7
4.1.1. Client-server interaction . . . . . . . . . . . . . . 6 4.1.1. Client-server interaction . . . . . . . . . . . . . . 7
4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 8 4.1.2. Issues due to introduction of Layer 2 Relay Agent . . 9
4.2. Multiple DHCP server and Client on same subnet . . . . . . 8 4.2. Multiple DHCP server and Client on same subnet . . . . . . 9
4.2.1. Client-server interaction . . . . . . . . . . . . . . 9 4.2.1. Client-server interaction . . . . . . . . . . . . . . 10
4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 9 4.2.2. Issues due to introduction of Layer 2 Relay Agent . . 10
4.3. DHCP server on another subnet with one Layer 3 Relay 4.3. DHCP server on another subnet with one Layer 3 Relay
Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Agent . . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.3.1. Client-server interaction . . . . . . . . . . . . . . 10 4.3.1. Client-server interaction . . . . . . . . . . . . . . 11
4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 12 4.3.2. Issues due to introduction of Layer 2 Relay Agent . . 13
5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 13 5. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
6. Security Consideration . . . . . . . . . . . . . . . . . . . . 14 6. Security Consideration . . . . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 16 8.1. Normative Reference . . . . . . . . . . . . . . . . . . . 17
8.2. Informative Reference . . . . . . . . . . . . . . . . . . 16 8.2. Informative Reference . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18
Intellectual Property and Copyright Statements . . . . . . . . . . 18 Intellectual Property and Copyright Statements . . . . . . . . . . 19
1. Introduction 1. Introduction
DHCP Relay Agents eliminate the necessity of having a DHCP server on DHCP Relay Agents eliminate the necessity of having a DHCP server on
each physical network. Relay Agents populate the 'giaddr' field and each physical network. Relay Agents populate the 'giaddr' field and
also append the 'Relay Agent Information' option to the DHCP also append the 'Relay Agent Information' option to the DHCP
messages. DHCP servers use this option for IP address and other messages. DHCP servers use this option for IP address and other
parameter assignment policies. These DHCP Relay Agents are typically parameter assignment policies. These DHCP Relay Agents are typically
an IP routing aware device and are referred as Layer 3 Relay Agents. an IP routing aware device and are referred as Layer 3 Relay Agents.
skipping to change at page 4, line 9 skipping to change at page 5, line 9
This document provides information about where a Layer 2 Relay Agent This document provides information about where a Layer 2 Relay Agent
fits in and how it is used. This document also looks at various fits in and how it is used. This document also looks at various
network scenarios with Layer 2 Relay Agent and discusses various network scenarios with Layer 2 Relay Agent and discusses various
issues caused by introduction of Layer 2 Relay Agent. issues caused by introduction of Layer 2 Relay Agent.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [1]. document are to be interpreted as described in RFC 2119 [RFC2119].
This document uses the following terms: This document uses the following terms:
o "DHCP client" o "DHCP client"
A DHCP client is an Internet host using DHCP to obtain configuration A DHCP client is an Internet host using DHCP to obtain configuration
parameters such as a network address. parameters such as a network address.
o "Layer 3 Relay Agent" o "Layer 3 Relay Agent"
A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap A Layer 3 Relay Agent is a third-party agent that transfers Bootstrap
Protocol (BOOTP) and DHCP messages between clients and servers Protocol (BOOTP) and DHCP messages between clients and servers
residing on different subnets, per RFC951 [6] and RFC1542[7]. residing on different subnets, per RFC951 [RFC951] and
RFC1542[RFC1542].
o "DHCP server" o "DHCP server"
A DHCP server is an Internet host that returns configuration A DHCP server is an Internet host that returns configuration
parameters to DHCP clients. parameters to DHCP clients.
o "Unnumbered Interfaces" o "Unnumbered Interfaces"
An interface with no IP address associated with it. IP packets An interface with no IP address associated with it. IP packets
received on this interface will be processed like any other numbered received on this interface will be processed like any other numbered
skipping to change at page 7, line 6 skipping to change at page 8, line 6
The following summary of protocol message exchanges between clients The following summary of protocol message exchanges between clients
and DHCP servers describes how they are handled in Layer 2 Relay and DHCP servers describes how they are handled in Layer 2 Relay
Agent. Agent.
1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its 1. The client [End Host #1] broadcasts a DHCPDISCOVER message on its
local physical subnet. Layer 2 Relay Agent [#1] intercepts this local physical subnet. Layer 2 Relay Agent [#1] intercepts this
message, appends the Relay Agent Information option and message, appends the Relay Agent Information option and
broadcasts it to all the ports except on which it was received. broadcasts it to all the ports except on which it was received.
Relay Agent Information option could be created as suggested in Relay Agent Information option could be created as suggested in
RFC 3046[3]. Layer 2 Relay Agent does not set the 'giaddr' RFC 3046[RFC3046]. Layer 2 Relay Agent does not set the 'giaddr'
field. field.
2. Layer 2 device [#2] would also receive this DHCPDISCOVER message 2. Layer 2 device [#2] would also receive this DHCPDISCOVER message
from Layer 2 device [#1]. If it is configured as Layer 2 Relay from Layer 2 device [#1]. If it is configured as Layer 2 Relay
Agent, it intercepts this message but does not append another Agent, it intercepts this message but does not append another
Relay Agent Information option to the message. It may discard Relay Agent Information option to the message. It may discard
this message if it is coming from an untrusted entity. this message if it is coming from an untrusted entity.
Otherwise, it will broadcast this on all the ports except on Otherwise, it will broadcast this on all the ports except on
which the message was received. which the message was received.
3. Server responds with a DHCPOFFER message after applying its local 3. Server responds with a DHCPOFFER message after applying its local
policies. DHCP server echoes back the Relay Agent Information policies. DHCP server echoes back the Relay Agent Information
option in the DHCPOFFER message. DHCP server can either unicast option in the DHCPOFFER message. DHCP server can either unicast
the reply to MAC address of End Host #1 or broadcast the reply. the reply to MAC address of End Host #1 or broadcast the reply.
In both the cases, the Layer 2 Relay Agent intercepts this If reply is broadcast, the Layer 2 Relay Agent intercepts this
message and removes the Relay Agent Information option. It message and removes the Relay Agent Information option. It
identifies the outgoing port using Relay Agent Information option identifies the outgoing port using Relay Agent Information option
and forwards to the identified interface. and forwards to the identified interface. A Layer 2 Relay Agent
may be configured to intercept unicast DHCP messages. In such a
case, Layer 2 Relay Agent intercepts unicast DHCP messages and
handle them similar to broadcast messages.
4. Same DHCPOFFER message will be received by the other Layer 2 4. Same DHCPOFFER message will be received by the other Layer 2
Device [#2]. If it is configured as Layer 2 Relay Agent, it Device [#2]. If it is configured as Layer 2 Relay Agent, it
broadcasts this message normally without removing the Relay Agent broadcasts this message normally without removing the Relay Agent
option since it had not added the same. A Layer 2 Relay Agent option since it had not added the same. A Layer 2 Relay Agent
uses the Relay Agent Information option to find out if it had uses the Relay Agent Information option to find out if it had
appended it to the request message. appended it to the request message.
5. The client receives this DHCPOFFER message and it broadcasts a 5. The client receives this DHCPOFFER message and it broadcasts a
DHCPREQUEST message that contains the 'server identifier' option DHCPREQUEST message. Layer 2 Relay Agent [#1] handles this
to indicate the server it has selected. Layer 2 Relay Agent [#1] message similar to how it handles a DHCPDISCOVER message.
handles this message similar to how it handles DHCPDISCOVER
message.
6. The server receives the DHCPREQUEST message from the client and 6. The server receives the DHCPREQUEST message from the client and
responds with a DHCPACK message containing the configuration responds with a DHCPACK/DHCPNACK message A DHCP server may
parameters for the requesting client. A DHCP server may unicast unicast the DHCPACK message. Layer 2 Relay Agent processes the
the DHCPACK message if the broadcast bit in the DHCPREQUEST DHCPACK message similar to DHCPOFFER message.
message is not set. DHCP server would echo back the Relay Agent
Information option in the reply message. A Layer 2 Relay Agent
may intercept this unicast message and process it similar to the
DHCPOFFER message.
7. A server that is unable to satisfy the DHCPREQUEST message, 7. Layer 2 Relay Agent process a DHCPNAK messages similar to DHCPACK
responds with DHCPNACK. Layer 2 Relay Agent process this similar message.
to DHCPACK message.
8. The client receives the DHCPACK message with configuration 8. Layer 2 Relay Agent process a DHCPDECLINE message similar to
parameters. If client detects that the address is already in DHCPDISCOVER message.
use, it sends a DHCPDECLINE message to the server. Layer 2 Relay
Agent process this message similar to DHCPDISCOVER message.
9. When client knows the address of a DHCP server, it may unicast 9. DHCP client can unicast some of the DHCP messages. Layer 2 Relay
DHCPDISCOVER, DHCPREQUEST messages to the server. DHCP clients Agent may or may not intercept these messages based on internal
unicast the DHCP messages like DHCPRELEASE and DHCPREQUEST when
renewing the lease to the DHCP server. Layer 2 Relay Agent may
or may not intercept these messages based on internal
configuration. If Layer 2 Relay Agents intercept these messages, configuration. If Layer 2 Relay Agents intercept these messages,
they append Relay Agent Information option and forward it towards they append Relay Agent Information option and forward it towards
the DHCP server. They also intercept the reply messages and the DHCP server. They also intercept the reply messages and
remove Relay Agent Information option before forwarding them. remove Relay Agent Information option before forwarding them.
4.1.2. Issues due to introduction of Layer 2 Relay Agent 4.1.2. Issues due to introduction of Layer 2 Relay Agent
1. A DHCP server should be able to handle a DHCP message that 1. A DHCP server should be able to handle a DHCP message that
contains the Relay Agent Information option without 'giaddr' contains the Relay Agent Information option without 'giaddr'
field set in the message. Some existing DHCP server field set in the message. Some existing DHCP server
implementations do not echo back the Relay Agent Information implementations do not echo back the Relay Agent Information
option if giaddr is not set. This may lead to issues at Layer 2 option if giaddr is not set. This may lead to issues at Layer 2
Relay Agents as they will not be able to identify the outgoing Relay Agents as they will not be able to identify the outgoing
port correctly and would broadcast it to all ports. Some Layer 2 port correctly and would broadcast it to all ports. Some Layer 2
Relay Agents discard the reply messages if they do not find a Relay Agents discard the reply messages if they do not find a
Relay Agent Information option in a DHCP reply. Relay Agent Information option in a DHCP reply.
2. A DHCP server should be able to handle a unicast DHCP message 2. There is a case when DHCP clients may receive unicast reply
messages like DHCPACK with Relay Agent Information option. This
may happen when DHCP server unicast the DHCPACK message and Layer
2 Relay Agent is configured not to intercept unicast messages.
In such a case, DHCP client can ignore the Relay Agent
Information option.
3. A DHCP server should be able to handle a unicast DHCP message
containing Relay Agent Information option. Some existing DHCP containing Relay Agent Information option. Some existing DHCP
server implementations do not echo back the Relay Agent server implementations do not echo back the Relay Agent
Information option in DHCP reply messages. Information option in responses to unicast messages.
4.2. Multiple DHCP server and Client on same subnet 4.2. Multiple DHCP server and Client on same subnet
In certain network scenarios, there could be multiple DHCP server on In certain network scenarios, there could be multiple DHCP server on
the same subnet. Figure #2 shows a typical network setup. the same subnet. Figure #2 shows a typical network setup.
+--------+ +--------+
| End | +--------+ | | End | +--------+ |
| Host#1 +-----------| | | +-----------+ | Host#1 +-----------| | | +-----------+
+--------+ | Layer +-----| | | +--------+ | Layer +-----| | |
skipping to change at page 13, line 9 skipping to change at page 14, line 9
If Layer 2 Relay Agent is configured to intercept unicast If Layer 2 Relay Agent is configured to intercept unicast
messages, it will append Relay Agent Information option to the messages, it will append Relay Agent Information option to the
unicast DHCP messages. Because of this, it could be difficult unicast DHCP messages. Because of this, it could be difficult
for DHCP server to differentiate between a RENEWING and REBINDING for DHCP server to differentiate between a RENEWING and REBINDING
state. state.
5. Acknowledgments 5. Acknowledgments
This document is the result of a discussion on DHC WG mailing list. This document is the result of a discussion on DHC WG mailing list.
Thanks to David W. Hankins and Michael Wacker for providing inputs on Thanks to David W. Hankins and Michael Wacker for providing inputs on
some of the existing implementations. Thanks to Stefaan.De.Cnodder some of the existing implementations. Thanks to Ted Lemon, Mukund
and Mukund Kamath for reviewing the draft and providing valuable Kamath and Stefaan.De.Cnodder for reviewing the draft and providing
suggestions valuable suggestions.
6. Security Consideration 6. Security Consideration
o A Layer 2 Relay Agent should always be configured to identify a o A Layer 2 Relay Agent should always be configured to identify a
trustable entity so that it appends Relay Agent Information option trustable entity so that it appends Relay Agent Information option
to DHCP messages coming from a trustable entity and forward it. to DHCP messages coming from a trustable entity and forward it.
If a DHCP message is received from a non-trustable entity, it If a DHCP message is received from a non-trustable entity, it
should discard it and may report to the administrator. should discard it and may report to the administrator.
o Introduction of Layer 2 Relay Agent does not introduce any new o Introduction of Layer 2 Relay Agent does not introduce any new
skipping to change at page 16, line 9 skipping to change at page 17, line 9
7. IANA Considerations 7. IANA Considerations
This document does not introduce any new namespaces for the IANA to This document does not introduce any new namespaces for the IANA to
manage. manage.
8. References 8. References
8.1. Normative Reference 8.1. Normative Reference
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131, [RFC2131] Droms, R., "Dynamic Host Configuration Protocol",
March 1997. RFC 2131, March 1997.
[3] Patrick, M., "DHCP Relay Agent Information Option", RFC 3046, [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
January 2001. RFC 3046, January 2001.
[4] Droms, R. and B. Arbaugh, "Authentication for DHCP Messages", [RFC3118] Droms, R. and B. Arbaugh, "Authentication for DHCP
RFC 3118, June 2001. Messages", RFC 3118, June 2001.
[5] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002. [RFC3232] Reynolds, J., "Assigned Numbers", RFC 3232, January 2002.
8.2. Informative Reference 8.2. Informative Reference
[6] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)", RFC 951, [RFC951] Croft, B. and J. Gilmore, "Bootstrap Protocol (BOOTP)",
September 1985. RFC 951, September 1985.
[7] Wimer, W., "Clarifications and Extensions for the Bootstrap [RFC1542] Wimer, W., "Clarifications and Extensions for the
Protocol", RFC 1542, October 1993. Bootstrap Protocol", RFC 1542, October 1993.
[8] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor [RFC2132] Droms, R. and S. Alexander, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
Authors' Addresses Authors' Addresses
Bharat Joshi Bharat Joshi
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
skipping to change at page 18, line 5 skipping to change at page 19, line 5
Pavan Kurapati Pavan Kurapati
Infosys Technologies Ltd. Infosys Technologies Ltd.
44 Electronics City, Hosur Road 44 Electronics City, Hosur Road
Bangalore 560 100 Bangalore 560 100
India India
Email: pavan_kurapati@infosys.com Email: pavan_kurapati@infosys.com
URI: http://www.infosys.com/ URI: http://www.infosys.com/
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
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 Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 18, line 28 skipping to change at line 580
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
Copyright Statement
Copyright (C) The IETF Trust (2008). This document is subject to the
rights, licenses and restrictions contained in BCP 78, and except as
set forth therein, the authors retain all their rights.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 28 change blocks. 
77 lines changed or deleted 88 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/