draft-ietf-v6ops-onlinkassumption-03.txt   draft-ietf-v6ops-onlinkassumption-04.txt 
Network Working Group S. Roy Network Working Group S. Roy
Internet-Draft Sun Microsystems, Inc. Internet-Draft Sun Microsystems, Inc.
Expires: October 3, 2005 A. Durand Expires: July 13, 2006 A. Durand
Comcast Corporation Comcast Corporation
J. Paugh J. Paugh
April 2005 Nominum, Inc.
January 9, 2006
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
draft-ietf-v6ops-onlinkassumption-03.txt draft-ietf-v6ops-onlinkassumption-04.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 36 skipping to change at page 1, line 37
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 October 3, 2005. This Internet-Draft will expire on July 13, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
This document describes the historical and background information This document describes the historical and background information
behind the removal of the "on-link assumption" from the conceptual behind the removal of the "on-link assumption" from the conceptual
host sending algorithm defined in Neighbor Discovery for IP Version 6 host sending algorithm defined in Neighbor Discovery for IP Version 6
(IPv6). According to the algorithm as originally described, when a (IPv6). According to the algorithm as originally described, when a
host's default router list is empty, the host assumes that all host's default router list is empty, the host assumes that all
destinations are on-link. This is particularly problematic with destinations are on-link. This is particularly problematic with
IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g.,
no default router). This document describes how making this no default router). This document describes how making this
assumption causes problems, and describes how these problems outweigh assumption causes problems, and describes how these problems outweigh
the benefits of this part of the conceptual sending algorithm. the benefits of this part of the conceptual sending algorithm.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Background on the On-link Assumption . . . . . . . . . . . . . 3 2. Background on the On-link Assumption . . . . . . . . . . . . . 3
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1 First Rule of Destination Address Selection . . . . . . . 3 3.1. First Rule of Destination Address Selection . . . . . . . 4
3.2 Delays Associated with Address Resolution . . . . . . . . 4 3.2. Delays Associated with Address Resolution . . . . . . . . 4
3.3 Multi-interface Ambiguity . . . . . . . . . . . . . . . . 5 3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . 5
3.4 Security Related Issues . . . . . . . . . . . . . . . . . 5 3.4. Security Related Issues . . . . . . . . . . . . . . . . . 5
4. Changes to RFC2461 . . . . . . . . . . . . . . . . . . . . . . 6 4. Changes to RFC2461 . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1 Normative References . . . . . . . . . . . . . . . . . . . 6 6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2 Informative References . . . . . . . . . . . . . . . . . . 7 6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7 Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-03 . . 7
B. Changes from draft-ietf-v6ops-onlinkassumption-02 . . . . . . 7 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-02 . . 8
C. Changes from draft-ietf-v6ops-onlinkassumption-01 . . . . . . 8 Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-01 . . 8
D. Changes from draft-ietf-v6ops-onlinkassumption-00 . . . . . . 8 Appendix E. Changes from draft-ietf-v6ops-onlinkassumption-00 . . 9
Intellectual Property and Copyright Statements . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
Intellectual Property and Copyright Statements . . . . . . . . . . 11
1. Introduction 1. Introduction
Neighbor Discovery for IPv6 [I-D.ietf-ipv6-2461bis] defines a Neighbor Discovery for IPv6 [I-D.ietf-ipv6-2461bis] defines a
conceptual sending algorithm for hosts. The version of the algorithm conceptual sending algorithm for hosts. The version of the algorithm
described in [RFC2461] states that if a host's default router list is described in [RFC2461] states that if a host's default router list is
empty, then the host assumes that all destinations are on-link. This empty, then the host assumes that all destinations are on-link. This
memo documents the removal of this assumption in the updated Neighbor memo documents the removal of this assumption in the updated Neighbor
Discovery specification [I-D.ietf-ipv6-2461bis], and describes the Discovery specification [I-D.ietf-ipv6-2461bis], and describes the
reasons why this assumption was removed. reasons why this assumption was removed.
skipping to change at page 3, line 35 skipping to change at page 3, line 35
associated with unnecessary address resolution and neighbor associated with unnecessary address resolution and neighbor
unreachability detection. The behavior associated with the unreachability detection. The behavior associated with the
assumption is undefined on multi-interface nodes, and has some subtle assumption is undefined on multi-interface nodes, and has some subtle
security implications. All of these issues are discussed in this security implications. All of these issues are discussed in this
document. document.
2. Background on the On-link Assumption 2. Background on the On-link Assumption
This part of Neighbor Discovery's [RFC2461] conceptual sending This part of Neighbor Discovery's [RFC2461] conceptual sending
algorithm was created to facilitate communication on a single link algorithm was created to facilitate communication on a single link
between systems manually configured with different global prefixes. between systems configured with different global prefixes in the
For example, consider the case where two systems on separate links absence of an IPv6 router. For example, consider the case where two
are manually configured with global addresses, and are then plugged systems on separate links are manually configured with global
in back-to-back. They can still communicate with each other via addresses, and are then plugged in back-to-back. They can still
their global addresses because they'll correctly assume that each is communicate with each other via their global addresses because
on-link. they'll correctly assume that each is on-link.
Without the on-link assumption, the above scenario wouldn't work, and Without the on-link assumption, the above scenario wouldn't work, and
the systems would need to be configured to share a common prefix such the systems would need to be configured to share a common prefix such
as the link-local prefix. as the link-local prefix. On the other hand, the on-link assumption
introduces several problems to various parts of the networking stack
described in Section 3. As such, this document points out that the
problems introduced by the on-link assumption outweigh the benefit
that the assumption lends to this scenario. It is more beneficial to
the end user to remove the on-link assumption from Neighbor Discovery
and declare this scenario illegitimate (or a misconfiguration).
3. Problems 3. Problems
The on-link assumption causes the following problems. The on-link assumption causes the following problems.
3.1 First Rule of Destination Address Selection 3.1. First Rule of Destination Address Selection
Default Address Selection for IPv6 [RFC3484] defines a destination Default Address Selection for IPv6 [RFC3484] defines a destination
address selection algorithm that takes an unordered list of address selection algorithm that takes an unordered list of
destination addresses as input, and produces a sorted list of destination addresses as input, and produces a sorted list of
destination addresses as output. The algorithm consists of destination addresses as output. The algorithm consists of
destination address sorting rules, the first of which is "Avoid destination address sorting rules, the first of which is "Avoid
unusable destinations". The idea behind this rule is to place unusable destinations". The idea behind this rule is to place
unreachable destinations at the end of the sorted list so that unreachable destinations at the end of the sorted list so that
applications will be least likely to try to communicate with those applications will be least likely to try to communicate with those
addresses first. addresses first.
The on-link assumption could potentially cause false positives when The on-link assumption could potentially cause false positives when
attempting unreachability determination for this rule. On a network attempting unreachability determination for this rule. On a network
where there is no IPv6 router (all off-link IPv6 destinations are where there is no IPv6 router (all off-link IPv6 destinations are
unreachable), the on-link assumption states that destinations are unreachable), the on-link assumption states that destinations are
assumed to be on-link. An implementation could interpret that as, if assumed to be on-link. An implementation could interpret that as, if
the default router list is empty, then all destinations are reachable the default router list is empty, then all destinations are reachable
on-link. This may cause the rule to prefer an unreachable IPv6 on-link. This may cause the rule to prefer an unreachable IPv6
destination over a reachable IPv4 destination. destination over a reachable IPv4 destination.
3.2 Delays Associated with Address Resolution 3.2. Delays Associated with Address Resolution
Users expect that applications quickly connect to a given destination Users expect that applications quickly connect to a given destination
regardless of the number of IP addresses assigned to that regardless of the number of IP addresses assigned to that
destination. If a destination name resolves to multiple addresses destination. If a destination name resolves to multiple addresses
and the application attempts to communicate to each address until one and the application attempts to communicate to each address until one
succeeds, this process shouldn't take an unreasonable amount of time. succeeds, this process shouldn't take an unreasonable amount of time.
It is therefore important that the system quickly determine if IPv6 It is therefore important that the system quickly determine if IPv6
destinations are unreachable so that the application can try other destinations are unreachable so that the application can try other
destinations when those IPv6 destinations are unreachable. destinations when those IPv6 destinations are unreachable.
For an IPv6 enabled host deployed on a network that has no IPv6 For an IPv6 enabled host deployed on a network that has no IPv6
routers, the result of the on-link assumption is that link-layer routers, the result of the on-link assumption is that link-layer
address resolution must be performed on all IPv6 addresses to which address resolution must be performed on all IPv6 addresses to which
the host sends packets. The Application will not receive the host sends packets. The Application will not receive
acknowledgment of the unreachability of destinations that are not on- acknowledgment of the unreachability of destinations that are not on-
link until at least address resolution has failed, which is no less link until at least address resolution has failed, which is no less
than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is than three seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is
greatly amplified by transport protocol delays. For example, greatly amplified by transport protocol delays. For example,
[RFC1122] requires that TCP retransmit for at least 3 minutes before [RFC1122] section 4.2.3.5 requires that TCP retransmit for at least 3
aborting the connection attempt. minutes before aborting the connection attempt.
When the application has a large list of off-link unreachable IPv6 When the application has a large list of off-link unreachable IPv6
addresses followed by at least one reachable IPv4 address, the delay addresses followed by at least one reachable IPv4 address, the delay
associated with Neighbor Unreachability Detection (NUD) of each IPv6 associated with Neighbor Unreachability Detection (NUD) of each IPv6
addresses before successful communication with the IPv4 address is addresses before successful communication with the IPv4 address is
unacceptable. unacceptable.
3.3 Multi-interface Ambiguity 3.3. Multi-interface Ambiguity
There is no defined way to implement this aspect of the sending There is no defined way to implement this aspect of the sending
algorithm on a node that is attached to multiple links. From an algorithm on a node that is attached to multiple links.
implementor's point of view, there are three ways to handle sending Specifically, a problem arises when a node is faced with sending a
an IPv6 packet to a destination in the face of the on-link assumption packet to an IPv6 destination address to which it has no route, and
on a multi-interface node: the sending node is attached to multiple links. With the on-link
assumption, this node assumes that the destination is on-link, but on
which link? From an implementor's point of view, there are three
ways to handle sending an IPv6 packet to a destination in the face of
the on-link assumption on a multi-interface node:
1. Attempt to resolve the destination on a single link. 1. Attempt to send the packet on a single link (either
administratively pre-defined or using some algorithm.)
2. Attempt to resolve the destination on every link. 2. Attempt to send the packet on every link.
3. Drop the packet. 3. Drop the packet.
If the destination is indeed on-link, the first option might not If the destination is indeed on-link, the first option might not
succeed since the wrong link could be picked. The second option succeed since the wrong link could be picked. The second option
might succeed in reaching a destination (assuming that one is might succeed in reaching the destination but is more complex to
reachable) but is more complex to implement, and isn't guaranteed to implement, and isn't guaranteed to pick the correct destination. For
pick the correct destination. For example, there is still ambiguity example, there could be more than one node configured with the same
about which link to use if more than one node answers the address, each reachable through a different link. The address by
solicitations on multiple links. Dropping the packet is equivalent itself does not disambiguate which destination the sender actually
to not making the on-link assumption at all. In other words, if wanted to reach, so attempting to send the packet to every link is
there is no route to the destination, don't attempt to send the not guaranteed to reach the anticipated destination. The third
packet. option, dropping the packet, is equivalent to not making the on-link
assumption at all. In other words, if there is no route to the
destination, don't attempt to send the packet. An implementation
that behaves this way would require an administrator to configure
routes to the destination in order to have reachability to the
destination, thus eliminating the ambiguity.
3.4 Security Related Issues 3.4. Security Related Issues
The on-link assumption discussed here introduces a security The on-link assumption discussed here introduces a security
vulnerability to the Neighbor Discovery protocol described in section vulnerability to the Neighbor Discovery protocol described in section
4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756]
titled "Default router is 'killed'". There is a threat that a host's titled "Default router is 'killed'". There is a threat that a host's
router can be maliciously killed in order to cause the host to start router can be maliciously killed in order to cause the host to start
sending all packets on-link. The attacker can then spoof off-link sending all packets on-link. The attacker can then spoof off-link
nodes by sending packets on the same link as the host. The nodes by sending packets on the same link as the host. The
vulnerability is discussed in detail in [RFC3756]. vulnerability is discussed in detail in [RFC3756].
skipping to change at page 6, line 33 skipping to change at page 6, line 47
The result of these changes is that destinations are considered The result of these changes is that destinations are considered
unreachable when there is no routing information for that destination unreachable when there is no routing information for that destination
(through a default router or otherwise). Instead of attempting link- (through a default router or otherwise). Instead of attempting link-
layer address resolution when sending to such a destination, a node layer address resolution when sending to such a destination, a node
should send an ICMPv6 Destination Unreachable message (code 0 - no should send an ICMPv6 Destination Unreachable message (code 0 - no
route to destination) message up the stack. route to destination) message up the stack.
5. Security Considerations 5. Security Considerations
The removal of the on-link assumption from Neighbor Discovery removes The removal of the on-link assumption from Neighbor Discovery
some security related vulnerabilities of the protocol as described in addresses all of the security-related vulnerabilities of the protocol
Section 3.4. as described in Section 3.4.
6. References 6. References
6.1 Normative References 6.1. Normative References
[I-D.ietf-ipv6-2461bis] [I-D.ietf-ipv6-2461bis]
Narten, T., "Neighbor Discovery for IP version 6 (IPv6)", Narten, T., "Neighbor Discovery for IP version 6 (IPv6)",
draft-ietf-ipv6-2461bis-02 (work in progress), draft-ietf-ipv6-2461bis-05 (work in progress),
February 2005. October 2005.
[RFC1122] Braden, R., "Requirements for Internet Hosts - [RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461, Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998. December 1998.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor [RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004. May 2004.
6.2 Informative References 6.2. Informative References
[RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998. Autoconfiguration", RFC 2462, December 1998.
Authors' Addresses Appendix A. Acknowledgments
Sebastien Roy
Sun Microsystems, Inc.
1 Network Drive
UBUR02-212
Burlington, MA 01801
Email: sebastien.roy@sun.com The authors gratefully acknowledge the contributions of Jim Bound,
Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka
Savola, and Ronald van der Pol.
Alain Durand Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-03
Comcast Corporation
1500 Market St.
Philadelphia, PA 09102
Email: alain_durand@cable.comcast.com o Clarified that the scenario described in the background section
(section 2) is considered a misconfiguration.
James Paugh o In section 3.2, specified the section number of RFC1122 that
specifies the 3 minute TCP retransmission period.
Email: jpaugh@speakeasy.net o Clarified section 3.3 (Multi-interface Ambiguity) to make explicit
that it's talking about an interface selection problem, and not an
address selection problem. The change also clarifies that the
third behavior eliminates the problematic ambiguity of the
described scenario.
Appendix A. Acknowledgments o Modified section 5 (Security Considerations) to state that the
removal of the on-link assumption addresses all security concerns
described in section 3.4.
The authors gratefully acknowledge the contributions of Jim Bound, o Changed Jim Paugh's (co-author) organization and mailing address.
Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald
van der Pol.
Appendix B. Changes from draft-ietf-v6ops-onlinkassumption-02 Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-02
o Changed abstract to reflect the historical nature of this o Changed abstract to reflect the historical nature of this
document. document.
o Changed the introduction to stress that this is historical o Changed the introduction to stress that this is historical
information documenting the removal of the on-link assumption from information documenting the removal of the on-link assumption from
the ND spec. the ND spec.
o Added text to the introduction stating that the assumption is a o Added text to the introduction stating that the assumption is a
problem for nodes with IPv6 on by default. problem for nodes with IPv6 on by default.
o Added mention to RFC1122 in section 3.2. o Added mention to RFC1122 in section 3.2.
o Changed use of the term multi-homed nodes to "nodes that are o Changed use of the term multi-homed nodes to "nodes that are
attached to multiple links". attached to multiple links".
o Changed section 4 from "Proposed Changes" to "Changes" and o Changed section 4 from "Proposed Changes" to "Changes" and
adjusted included text to reflect that the changes have been made. adjusted included text to reflect that the changes have been made.
Appendix C. Changes from draft-ietf-v6ops-onlinkassumption-01 Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-01
o Added text in the Introduction stating that rfc2461bis has removed o Added text in the Introduction stating that rfc2461bis has removed
the on-link assumption, and that this memo gives the historical the on-link assumption, and that this memo gives the historical
reference and background for its removal. reference and background for its removal.
o Stated in Section 2 that users may not have sufficient privileges o Stated in Section 2 that users may not have sufficient privileges
or knowledge to manually configure addresses or routers in order or knowledge to manually configure addresses or routers in order
to work-around the lack of an on-link assumption. to work-around the lack of an on-link assumption.
o Removed implementation details of the on-link assumption from o Removed implementation details of the on-link assumption from
Section 3.1. Section 3.1.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
Appendix D. Changes from draft-ietf-v6ops-onlinkassumption-00 Appendix E. Changes from draft-ietf-v6ops-onlinkassumption-00
o Clarified in the abstract and introduction that the problem is o Clarified in the abstract and introduction that the problem is
with systems that are IPv6 enabled but have no off-link with systems that are IPv6 enabled but have no off-link
connectivity. connectivity.
o In Section 3.3, clarified that soliciting on all links could have o In Section 3.3, clarified that soliciting on all links could have
ambiguous results. ambiguous results.
o The old Security Considerations section was moved to Section 3.4, o The old Security Considerations section was moved to Section 3.4,
and the new Security Considerations section refers to that new and the new Security Considerations section refers to that new
section. section.
o Miscellaneous editorial changes. o Miscellaneous editorial changes.
Authors' Addresses
Sebastien Roy
Sun Microsystems, Inc.
1 Network Drive
UBUR02-212
Burlington, MA 01803
Email: sebastien.roy@sun.com
Alain Durand
Comcast Corporation
1500 Market Street
Philadelphia, PA 09102
Email: alain_durand@cable.comcast.com
James Paugh
Nominum, Inc.
2385 Bay Road
Redwood City, CA 94063
Email: jim.paugh@nominum.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 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 9, line 41 skipping to change at page 11, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
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. 35 change blocks. 
76 lines changed or deleted 117 lines changed or added

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