draft-ietf-dhc-agent-vpn-id-02.txt | draft-ietf-dhc-agent-vpn-id-03.txt | |||
---|---|---|---|---|
Network Working Group Kim Kinnear | Network Working Group Kim Kinnear | |||
INTERNET DRAFT Mark Stapp | INTERNET DRAFT Mark Stapp | |||
Richard Johnson | Richard Johnson | |||
Jay Kumarasamy | Jay Kumarasamy | |||
Cisco Systems | Cisco Systems | |||
November 2002 | February 2005 | |||
Expires May 2003 | Expires July 2005 | |||
VPN Identifier sub-option | Virtual Subnet Selection Sub-Option | |||
for the Relay Agent Information Option | for the Relay Agent Information Option | |||
<draft-ietf-dhc-agent-vpn-id-02.txt> | <draft-ietf-dhc-agent-vpn-id-03.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, | |||
or will be disclosed, and any of which I become aware will be | ||||
disclosed, in accordance with RFC 3668. | ||||
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 | |||
other groups may also distribute working documents as Internet- | other groups may also distribute working documents as Internet- | |||
Drafts. | Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six months | Internet-Drafts are draft documents valid for a maximum of six months | |||
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/1id-abstracts.html | |||
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 | |||
Copyright Notice | Copyright Notice | |||
Copyright (C) The Internet Society (2002). All Rights Reserved. | Copyright (C) The Internet Society (2005). All Rights Reserved. | |||
Abstract | Abstract | |||
In some environments, a relay agent resides in a network element | In some environments, a relay agent resides in a network element | |||
which also has access to one or more VPNs. If one DHCP server wishes | which also has access to one or more virtual private networks (VPNs). | |||
to offer service to DHCP clients on those different VPNs the DHCP | If one DHCP server wishes to offer service to DHCP clients on those | |||
server needs to know the VPN on which each client resides. The vpn- | different VPNs the DHCP server needs to know information about the | |||
id sub-option of the relay-agent-information option is used by the | VPN on which each client resides. The virtual-subnet-selection sub- | |||
relay agent to tell the DHCP server the VPN for every DHCP request it | option of the relay-agent-information option is used by the relay | |||
passes on to the DHCP server, and is also used to properly forward | agent to tell the DHCP server important information about the VPN | |||
any DHCP reply that the DHCP server sends back to the relay agent. | (called the Virtual Subnet Selection information, or VSS) for every | |||
DHCP request it passes on to the DHCP server, and is also used to | ||||
properly forward any DHCP reply that the DHCP server sends back to | ||||
the relay agent. | ||||
1. Introduction | 1. Introduction | |||
There exist situations where there are multiple VPNs serviced by one | There exist situations where there are multiple VPNs serviced by one | |||
or more network elements which also contain relay agents. These | or more network elements which also contain relay agents. These | |||
VPNs contain DHCP clients, and there is a desire to allow one DHCP | VPNs contain DHCP clients, and there is a desire to allow one DHCP | |||
server to supply the full range of DHCP services to these DHCP | server to supply the full range of DHCP services to these DHCP | |||
clients. | clients. | |||
The network element which contains the relay agent typically is also | The network element which contains the relay agent typically is also | |||
the network element which knows about the VPN association of the DHCP | the network element which knows about the VPN association of the DHCP | |||
client and could include this information in the relay-agent- | client and could include information about the VPN in the relay- | |||
information option in the client's DHCP requests. This document | agent-information option in the client's DHCP requests. This informa- | |||
defines a sub-option for the relay-agent-information option which | tion about the VPN is called the Virtual Subnet Selection informa- | |||
contains the vpn-id, and which allows the relay agent to communicate | tion, or VSS information. This document defines a sub-option for the | |||
the VPN association to the DHCP server. | relay-agent-information option which contains this VSS information, | |||
and which allows the relay agent to communicate the VSS information | ||||
to the DHCP server. | ||||
When the DHCP server sends its response to the relay agent for for- | When the DHCP server sends its response to the relay agent for for- | |||
warding back to the DHCP client, the relay agent will also need to | warding back to the DHCP client, the relay agent will also need to | |||
use the vpn-id sub-option to determine to which VPN to send the DHCP | use the virtual-subnet-selection sub-option to determine to which VPN | |||
response. | to send the DHCP response. | |||
This sub-option can also be used by the DHCP server to inform a relay | This sub-option can also be used by the DHCP server to inform a relay | |||
agent that a particular DHCP client is associated with a particular | agent that a particular DHCP client is associated with a particular | |||
VPN by sending the vpn-id sub-option to the relay agent in the | VPN by sending the virtual-subnet-selection sub-option in the relay- | |||
relay-agent-information option back to the relay agent. | agent-information option back to the relay agent. | |||
Consider the following architecture: | Consider the following architecture: | |||
+--------+ +---------------+ | +--------+ +---------------+ | |||
| DHCP | IP x| Relay Agent | IP z | | DHCP | IP x| Relay Agent | IP z | |||
| Server |-.......-| and +---+-------+-------+ | | Server |-.......-| and +---+-------+-------+ | |||
+--------+ | VPN manager | | | | | +--------+ | VPN manager | | | | | |||
+---+-----------+ | | | | +---+-----------+ | | | | |||
|IP y +-----+ +--+--+ +--+--+ | |IP y +-----+ +--+--+ +--+--+ | |||
+-+-----+ |Host1| |Host2| |Host3| | +-+-----+ |Host1| |Host2| |Host3| | |||
skipping to change at page 3, line 4 | skipping to change at page 3, line 21 | |||
+---+-----------+ | | | | +---+-----------+ | | | | |||
|IP y +-----+ +--+--+ +--+--+ | |IP y +-----+ +--+--+ +--+--+ | |||
+-+-----+ |Host1| |Host2| |Host3| | +-+-----+ |Host1| |Host2| |Host3| | |||
| | +-----+ +-----+ +-----+ | | | +-----+ +-----+ +-----+ | |||
| | | | | | |||
+-----+ +--+--+ VPN 2 | +-----+ +--+--+ VPN 2 | |||
|Host1| |Host2| | |Host1| |Host2| | |||
+-----+ +-----+ | +-----+ +-----+ | |||
VPN 1 | VPN 1 | |||
In this architecture, the relay agent knows the VPN for each of the | In this architecture, the relay agent knows the VPN for each of the | |||
DHCP clients, and inserts that information in the vpn-id sub-option | DHCP clients, and inserts the VSS information about the VPN in the | |||
in every DHCP request it forwards onto the DHCP server. | virtual-subnet-selection sub-option in every DHCP request it forwards | |||
on to the DHCP server. | ||||
When the DHCP server copies over the relay-agent-information option | When the DHCP server copies over the relay-agent-information option | |||
from the request to the reply packet, it will copy over the vpn-id | from the request to the reply packet, it will copy over the virtual- | |||
sub-option as well. | subnet-selection sub-option as well. | |||
When the relay agent receives a DHCP reply packet from the server | When the relay agent receives a DHCP reply packet from the server | |||
with a vpn-id sub-option, it will forward the packet onto the proper | with a virtual-subnet-selection sub-option, it will forward the | |||
VPN based on the value of the vpn-id sub-option. | packet onto the proper VPN based on the VSS information in the | |||
virtual-subnet-selection sub-option. | ||||
2. | 2. | |||
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 [RFC 2119]. | document are to be interpreted as described in RFC 2119 [RFC 2119]. | |||
This document uses the following terms: | This document uses the following terms: | |||
o "DHCP client" | o "DHCP client" | |||
skipping to change at page 3, line 50 | skipping to change at page 4, line 26 | |||
o "downstream" | o "downstream" | |||
Downstream is the direction from the access concentrator towards | Downstream is the direction from the access concentrator towards | |||
the subscriber. | the subscriber. | |||
o "upstream" | o "upstream" | |||
Upstream is the direction from the subscriber towards the access | Upstream is the direction from the subscriber towards the access | |||
concentrator. | concentrator. | |||
o "VSS information" | ||||
Information about a VPN necessary to allocate an address to a | ||||
DHCP client on that VPN and necessary to forward a DHCP reply | ||||
packet to a DHCP client on that VPN. | ||||
o "VPN" | o "VPN" | |||
Virtual private network. A network which appears to the client | Virtual private network. A network which appears to the client | |||
to be a private network. | to be a private network. | |||
o "VPN Identifier" | o "VPN Identifier" | |||
The VPN-ID is defined by [RFC2685] to be a sequence of 14 hex | The VPN-ID is defined by [RFC2685] to be a sequence of 14 hex | |||
digits. | digits. | |||
3. VPN identifier sub-option definition | 3. Virtual Subnet Selection Sub-Option Definition | |||
The vpn-id sub-option MAY be used by any DHCP relay agent which | The virtual-subnet-selection sub-option MAY be used by any DHCP relay | |||
desires to specify the VPN from which a DHCP client request was sent. | agent which desires to specify the VSS information about a VPN from | |||
which a DHCP client request was sent. | ||||
The vpn-id sub-option contains a generalized VPN identifier. | The virtual-subnet-selection sub-option contains a generalized way to | |||
specify the VSS information about a VPN. | ||||
The format of the option is: | The format of the option is: | |||
SubOpt Len Type VPN identifier | SubOpt Len Type VPN identifier | |||
+------+------+------+------+------+------+--- | +------+------+------+------+------+------+--- | |||
| TBD | n | t | id1 | id2 | id3 | ... | | TBD | n | t | id1 | id2 | id3 | ... | |||
+------+------+------+------+------+------+--- | +------+------+------+------+------+------+--- | |||
Type: 0 NVT ASCII VPN identifier | Type: 0 NVT ASCII VPN identifier | |||
1 RFC2685 VPN-ID | 1 RFC2685 VPN-ID | |||
2-255 Not Allowed | 2-255 Not Allowed | |||
There are two types of identifiers which can be placed in the vpn-id | There are two types of identifiers which can be placed in the | |||
sub-option. The first type of identifier which can be placed in the | virtual-subnet-selection sub-option. The first type of identifier | |||
vpn-id sub-option is an NVT ASCII string. It MUST NOT be terminated | which can be placed in the virtual-subnet-selection sub-option is an | |||
with a zero byte. | NVT ASCII string. It MUST NOT be terminated with a zero byte. | |||
The second type of identifier which can be placed in the vpn-id sub- | The second type of identifier which can be placed in the virtual- | |||
option is an RFC2685 VPN-ID [RFC 2685], which is typically 14 hex | subnet-selection sub-option is an RFC2685 VPN-ID [RFC 2685], which is | |||
digits in length (though it can be any length as far as the vpn-id | typically 14 hex digits in length (though it can be any length as far | |||
sub-option is concerned). | as the virtual-subnet-selection sub-option is concerned). | |||
All other values of the type field are invalid as of this memo and | ||||
VSS sub-options containing any other value than zero (0) or one (1) | ||||
SHOULD be ignored. | ||||
A relay agent which recieves a DHCP request from a DHCP client on a | A relay agent which recieves a DHCP request from a DHCP client on a | |||
VPN SHOULD include a vpn-id sub-option in the relay-agent-information | VPN SHOULD include a virtual-subnet-selection sub-option in the | |||
option that it inserts in the DHCP packet prior to forwarding it on | relay-agent-information option that it inserts in the DHCP packet | |||
to the DHCP server. | prior to forwarding it on to the DHCP server. | |||
The value placed in the vpn-id sub-option SHOULD be sufficient for | The value placed in the virtual-subnet-selection sub-option SHOULD be | |||
the relay agent to properly route any DHCP reply packet returned from | sufficient for the relay agent to properly route any DHCP reply | |||
the DHCP server to the DHCP client for which it is destined. Servers | packet returned from the DHCP server to the DHCP client for which it | |||
supporting this sub-option MUST return an identical copy of the sub- | is destined. Servers supporting this sub-option MUST return an | |||
option in the relay-agent-info option to any relay-agent that sends | instance of this sub-option in the relay-agent-info option to any | |||
it. | relay-agent that sends it. Servers SHOULD return the an exact copy | |||
of the sub-option unless they desire to change the VPN on which a | ||||
client was configured, which would typically be a very unusual thing | ||||
to do. | ||||
In the event that a vpn-id option and a vpn-id sub-option are both | In the event that a virtual-subnet-selection option and a virtual- | |||
received in a particular DHCP client packet, the information from the | subnet-selection sub-option are both received in a particular DHCP | |||
vpn-id sub-option MUST be used in preference to the information in | client packet, the information from the virtual-subnet-selection | |||
the vpn-id option. | sub-option MUST be used in preference to the information in the | |||
virtual-subnet-selection option. | ||||
Relay agents which include this sub-option when forwarding DHCP | Relay agents which include this sub-option when forwarding DHCP | |||
client requests MUST discard DHCPOFFER or DHCPACK packets that do not | client requests MUST discard DHCPOFFER or DHCPACK packets that do not | |||
contain this sub-option in their associated relay-agent-info options. | contain this sub-option in their associated relay-agent-info options. | |||
This does not imply any memory of the particular packets forwarded | ||||
with this sub-option included. Rather, the expectation is that the | ||||
relay agent will use whatever algorithm that it used on the DHCPDIS- | ||||
COVER and DHCPREQUEST packets to decide to include this sub-option on | ||||
the DHCPOFFER and DHCPACK packets to decide if they MUST have this | ||||
sub-option included in their relay-agent-info options. | ||||
In some cases, a DHCP server may use the vpn-id sub-option to inform | In some cases, a DHCP server may use the virtual-subnet-selection | |||
a relay agent that a particular DHCP client is associated with a par- | sub-option to inform a relay agent that a particular DHCP client is | |||
ticular VPN. It does this by sending the vpn-id sub-option with the | associated with a particular VPN. It does this by sending the | |||
appropriate information to the relay agent in the relay-agent- | virtual-subnet-selection sub-option with the appropriate information | |||
information option. If the relay agent is unable to honor the DHCP | to the relay agent in the relay-agent-information option. If the | |||
server's requirement to place the DHCP client into that VPN it MUST | relay agent is unable to honor the DHCP server's requirement to place | |||
drop the packet and not send it back to the DHCP client. | the DHCP client into that VPN it MUST drop the packet and not send it | |||
to the DHCP client. | ||||
This sub-option SHOULD NOT be used without also making use of some | ||||
form of authentication for relay-agent-information option. | ||||
4. Security | 4. Security | |||
Message authentication in DHCP for intradomain use where the out-of- | Message authentication in DHCP for intradomain use where the out-of- | |||
band exchange of a shared secret is feasible is defined in [RFC | band exchange of a shared secret is feasible is defined in [RFC | |||
3118]. Potential exposures to attack are discussed in section 7 of | 3118]. Potential exposures to attack are discussed in section 7 of | |||
the DHCP protocol specification in [RFC 2131]. | the DHCP protocol specification in [RFC 2131]. | |||
The vpn-id sub-option could be used by a client in order to obtain an | The virtual-subnet-selection sub-option could be used by a client in | |||
IP address from a VPN other than the one on which it resides. This | order to obtain an IP address from a VPN other than the one on which | |||
attack can be partially prevented by the relay agent not forwarding | it resides. This attack can be partially prevented by the relay | |||
any DHCP packet which already contains a relay-agent-information | agent not forwarding any DHCP packet which already contains a relay- | |||
option. | agent-information option. | |||
Any program which unicasts a DHCP packet to the DHCP server with a | Any program which unicasts a DHCP packet to the DHCP server with a | |||
relay-agent-information option in it with a vpn-id for a different | relay-agent-information option in it with a vpn-id for a different | |||
VPN would cause the DHCP server to allocate an address from that dif- | VPN would cause the DHCP server to allocate an address from that dif- | |||
ferent VPN, but since the DHCP server cannot (in general) communicate | ferent VPN, but since the DHCP server cannot (in general) communicate | |||
directly back to the program that sent in the malicious DHCP packet, | directly back to the program that sent in the malicious DHCP packet, | |||
the entire cycle of creating a lease will not be completed. Cer- | the entire cycle of creating a lease will not be completed. Cer- | |||
tainly many leases could be offered, which would result in a form of | tainly many leases could be offered, which would result in a tem- | |||
address-pool exhaustion. | poraty form of address-pool exhaustion. | |||
Servers that implement the vpn-id sub-option MUST by default disable | Servers that implement the virtual-subnet-selection sub-option MUST | |||
use of the feature; it must specifically be enabled through confi- | by default disable use of the feature; it must specifically be | |||
guration. Moreover, a server SHOULD provide the ability to selec- | enabled through configuration. Moreover, a server SHOULD provide the | |||
tively enable use of the feature under restricted conditions, e.g., | ability to selectively enable use of the feature under restricted | |||
by enabling use of the option only from explicitly configured | conditions, e.g., by enabling use of the option only from explicitly | |||
client-ids, enabling its use only by clients on a particular subnet, | configured client-ids, enabling its use only by clients on a particu- | |||
or restricting the VPNs from which addresses may be requested. | lar subnet, or restricting the VPNs from which addresses may be | |||
requested. | ||||
5. IANA Considerations | 5. IANA Considerations | |||
IANA has assigned the value of TBD for the VPN Identifier sub-option | IANA has assigned the value of TBD for the VPN Identifier sub-option | |||
from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN | from the DHCP Relay Agent Sub-options space [RFC 3046] for the VPN | |||
Identifier sub-option defined in Section 3. | Identifier sub-option defined in Section 3. | |||
This document defines a number space for the type byte of the vpn-id | This document defines a number space for the type byte of the | |||
sub-option. Certain allowable values for this byte are defined in | virtual-subnet-selection sub-option. Certain allowable values for | |||
this specification (see Section 3). New values may only be defined | this byte are defined in this specification (see Section 3). New | |||
by IETF Consensus, as described in [RFC 2434]. Basically, this means | values may only be defined by IETF Consensus, as described in [RFC | |||
that they are defined by RFCs approved by the IESG. | 2434]. Basically, this means that they are defined by RFCs approved | |||
by the IESG. | ||||
Moreover, any changes or additions to the type byte codes MUST be | Moreover, any changes or additions to the type byte codes MUST be | |||
made concurrently in the type byte codes of the vpn-id option. The | made concurrently in the type byte codes of the virtual-subnet- | |||
type bytes and data formats of the vpn-id option and vpn-id sub- | selection option. The type bytes and data formats of the virtual- | |||
option MUST always be identical. | subnet-selection option and virtual-subnet-selection sub-option MUST | |||
always be identical. | ||||
6. Acknowledgments | 6. Acknowledgments | |||
None (yet). | None. | |||
7. References | 7. Normative References | |||
[RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
Requirement Levels", RFC 2119, March 1997. | Requirement Levels", RFC 2119, March 1997. | |||
[RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC | [RFC 2131] Droms, R., "Dynamic Host Configuration Protocol", RFC | |||
2131, March 1997. | 2131, March 1997. | |||
[RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor | [RFC 2132] Alexander, S., Droms, R., "DHCP Options and BOOTP Vendor | |||
Extensions", Internet RFC 2132, March 1997. | Extensions", Internet RFC 2132, March 1997. | |||
skipping to change at page 7, line 10 | skipping to change at page 8, line 11 | |||
3046, January 2001. | 3046, January 2001. | |||
[RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, | [RFC 3118] Droms, R. "Authentication for DHCP Messages", RFC 3118, | |||
June 2001. | June 2001. | |||
8. Author's information | 8. Author's information | |||
Kim Kinnear | Kim Kinnear | |||
Mark Stapp | Mark Stapp | |||
Cisco Systems | Cisco Systems | |||
250 Apollo Drive | 1414 Massachusetts Ave. | |||
Chelmsford, MA 01824 | Boxborough, Massachusetts 01719 | |||
Phone: (978) 497-8000 | Phone: (978) 936-0000 | |||
EMail: kkinnear@cisco.com | EMail: kkinnear@cisco.com | |||
mjs@cisco.com | mjs@cisco.com | |||
Jay Kumarasamy | Jay Kumarasamy | |||
Richard Johnson | Richard Johnson | |||
Cisco Systems | Cisco Systems | |||
170 W. Tasman Dr. | 170 W. Tasman Dr. | |||
San Jose, CA 95134 | San Jose, CA 95134 | |||
skipping to change at page 7, line 46 | skipping to change at page 8, line 47 | |||
identify any such rights. Information on the IETF's procedures with | identify any such rights. Information on the IETF's procedures with | |||
respect to rights in standards-track and standards-related documentation | respect to rights in standards-track and standards-related documentation | |||
can be found in BCP-11. Copies of claims of rights made available for | 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 | 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 | 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 | the use of such proprietary rights by implementors or users of this | |||
specification can be obtained from the IETF Secretariat. | specification can be obtained from the IETF Secretariat. | |||
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 rights | copyrights, patents or patent applications, or other proprietary rights | |||
which may cover technology that may be required to practice this stan- | which may cover technology that may be required to practice this | |||
dard. Please address the information to the IETF Executive Director. | ||||
10. Full Copyright Statement | ||||
Copyright (C) The Internet Society (2002). All Rights Reserved. | standard. Please address the information to the IETF Executive Direc- | |||
tor. | ||||
This document and translations of it may be copied and furnished to oth- | 10. Full Copyright Statement | |||
ers, and derivative works that comment on or otherwise explain it or | ||||
assist in its implementation may be prepared, copied, published and dis- | ||||
tributed, 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 Stan- | ||||
dards 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 (C) The Internet Society (2005). This document is subject to | |||
revoked by the Internet Society or its successors or assigns. | 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 is provided on an "AS | This document and the information contained herein are provided on an | |||
IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK | "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR | |||
FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT | IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET | |||
LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT | ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, | |||
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FIT- | INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMA- | |||
NESS FOR A PARTICULAR PURPOSE. | TION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | |||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |