draft-ietf-ipv6-2461bis-07.txt   draft-ietf-ipv6-2461bis-08.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: November 2006 IBM Expires: November 2006 IBM
E. Nordmark, Obsoletes: 2461 (if approved) E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
May, 2006 September, 2006
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-07.txt> <draft-ietf-ipv6-2461bis-08.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 other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. 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 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 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/lid-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 document is a submission of the IETF IPv6 WG. Comments should be Copyright Notice
directed to the IPv6 WG mailing list, ipv6@ietf.org.
Copyright (C) The Internet Society (2006).
Abstract Abstract
This document specifies the Neighbor Discovery protocol for IP This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to Version 6. IPv6 nodes on the same link use Neighbor Discovery to
discover each other's presence, to determine each other's link-layer discover each other's presence, to determine each other's link-layer
addresses, to find routers and to maintain reachability information addresses, to find routers and to maintain reachability information
about the paths to active neighbors. about the paths to active neighbors.
Table of Contents Table of Contents
skipping to change at page 3, line 49 skipping to change at page 3, line 50
REFERENCES.........................................................76 REFERENCES.........................................................76
Authors' Addresses.................................................80 Authors' Addresses.................................................80
APPENDIX A: MULTIHOMED HOSTS.......................................80 APPENDIX A: MULTIHOMED HOSTS.......................................80
APPENDIX B: FUTURE EXTENSIONS......................................81 APPENDIX B: FUTURE EXTENSIONS......................................81
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82
APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 APPENDIX D: SUMMARY OF ISROUTER RULES..............................84
APPENDIX E: IMPLEMENTATION ISSUES..................................85 APPENDIX E: IMPLEMENTATION ISSUES..................................85
Appendix E.1: Reachability confirmations...........................85 Appendix E.1: Reachability confirmations...........................85
APPENDIX F: CHANGES FROM RFC 2461..................................86 APPENDIX F: CHANGES FROM RFC 2461..................................87
1. INTRODUCTION 1. INTRODUCTION
This specification defines the Neighbor Discovery (ND) protocol for This specification defines the Neighbor Discovery (ND) protocol for
Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use
Neighbor Discovery to determine the link-layer addresses for Neighbor Discovery to determine the link-layer addresses for
neighbors known to reside on attached links and to quickly purge neighbors known to reside on attached links and to quickly purge
cached values that become invalid. Hosts also use Neighbor Discovery cached values that become invalid. Hosts also use Neighbor Discovery
to find neighboring routers that are willing to forward packets on to find neighboring routers that are willing to forward packets on
their behalf. Finally, nodes use the protocol to actively keep track their behalf. Finally, nodes use the protocol to actively keep track
skipping to change at page 4, line 29 skipping to change at page 4, line 29
over a particular link type) this document applies to all link types. over a particular link type) this document applies to all link types.
However, because ND uses link-layer multicast for some of its However, because ND uses link-layer multicast for some of its
services, it is possible that on some link types (e.g., NBMA links) services, it is possible that on some link types (e.g., NBMA links)
alternative protocols or mechanisms to implement those services will alternative protocols or mechanisms to implement those services will
be specified (in the appropriate document covering the operation of be specified (in the appropriate document covering the operation of
IP over a particular link type). The services described in this IP over a particular link type). The services described in this
document that are not directly dependent on multicast, such as document that are not directly dependent on multicast, such as
Redirects, Next-hop determination, Neighbor Unreachability Detection, Redirects, Next-hop determination, Neighbor Unreachability Detection,
etc., are expected to be provided as specified in this document. The etc., are expected to be provided as specified in this document. The
details of how one uses ND on NBMA links are addressed in [IPv6- details of how one uses ND on NBMA links are addressed in [IPv6-
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELLULAR] discuss the use NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of
of this protocol over some cellular links, which are examples of NBMA this protocol over some cellular links, which are examples of NBMA
links. links.
The authors would like to acknowledge the contributions of the IPv6 The authors would like to acknowledge the contributions of the IPv6
working group and, in particular, (in alphabetical order) Ran working group and, in particular, (in alphabetical order) Ran
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen
Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan,
Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles
Perkins, Matt Thomas, and Susan Thomson. Perkins, Matt Thomas, and Susan Thomson.
2. TERMINOLOGY 2. TERMINOLOGY
skipping to change at page 9, line 24 skipping to change at page 9, line 25
all-routers multicast address all-routers multicast address
- the link-local scope address to reach all routers, - the link-local scope address to reach all routers,
FF02::2. FF02::2.
solicited-node multicast address solicited-node multicast address
- a link-local scope multicast address that is computed - a link-local scope multicast address that is computed
as a function of the solicited target's address. The as a function of the solicited target's address. The
function is described in [ADDR-ARCH]. The function is function is described in [ADDR-ARCH]. The function is
chosen so that IP addresses which differ only in the chosen so that IP addresses which differ only in the
least significant bits, e.g., due to multiple most significant bits, e.g., due to multiple
high-order prefixes associated with different prefixes associated with different providers, will map
providers, will map to the same solicited-node address to the same solicited-node address thereby reducing the
thereby reducing the number of multicast addresses a number of multicast addresses a node must join.
node must join.
link-local address link-local address
- a unicast address having link-only scope that can be - a unicast address having link-only scope that can be
used to reach neighbors. All interfaces on routers used to reach neighbors. All interfaces on routers
MUST have a link-local address. Also, [ADDRCONF] MUST have a link-local address. Also, [ADDRCONF]
requires that interfaces on hosts have a link-local requires that interfaces on hosts have a link-local
address. address.
unspecified address unspecified address
- a reserved address value that indicates the lack of an - a reserved address value that indicates the lack of an
skipping to change at page 17, line 12 skipping to change at page 17, line 14
The protocol can presumably be extended in the The protocol can presumably be extended in the
future to find viable paths in environments that future to find viable paths in environments that
lack reflexive and transitive connectivity. lack reflexive and transitive connectivity.
3.3. Securing Neighbor Discovery messages 3.3. Securing Neighbor Discovery messages
Neighbor Discovery messages are needed for various functions. Several Neighbor Discovery messages are needed for various functions. Several
functions are designed to allow hosts to ascertain the ownership of functions are designed to allow hosts to ascertain the ownership of
an address or the mapping between link layer and IP layer addresses. an address or the mapping between link layer and IP layer addresses.
Having Neighbor Discovery functions on the ICMP layer allows for the
use of IP layer security mechanisms, which are available
independently of the availability of security on the link layer.
Vulnerabilities related to Neighbor Discovery are discussed in Vulnerabilities related to Neighbor Discovery are discussed in
section 11.1. A general solution for securing Neighbor Discovery is section 11.1. A general solution for securing Neighbor Discovery is
outside the scope of this specification and is discussed in [SEND]. outside the scope of this specification and is discussed in [SEND].
However, Section 11.2 explains how and under which constraints IPsec However, Section 11.2 explains how and under which constraints IPsec
AH or ESP can be used to secure Neighbor Discovery. AH or ESP can be used to secure Neighbor Discovery.
4. MESSAGE FORMATS 4. MESSAGE FORMATS
4.1. Router Solicitation Message Format 4.1. Router Solicitation Message Format
skipping to change at page 18, line 4 skipping to change at page 17, line 52
to the sending interface. to the sending interface.
Destination Address Destination Address
Typically the all-routers multicast address. Typically the all-routers multicast address.
Hop Limit 255 Hop Limit 255
ICMP Fields: ICMP Fields:
Type 133 Type 133
Code 0
Code 0
Checksum The ICMP checksum. See [ICMPv6]. Checksum The ICMP checksum. See [ICMPv6].
Reserved This field is unused. It MUST be initialized to Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the zero by the sender and MUST be ignored by the
receiver. receiver.
Valid Options: Valid Options:
Source link-layer address Source link-layer address
The link-layer address of the sender, if known. The link-layer address of the sender, if known.
MUST NOT be included if the Source Address is the MUST NOT be included if the Source Address is the
skipping to change at page 74, line 46 skipping to change at page 74, line 43
11.2 Securing Neighbor Discovery messages 11.2 Securing Neighbor Discovery messages
The protocol reduces the exposure to the above threats in the absence The protocol reduces the exposure to the above threats in the absence
of authentication by ignoring ND packets received from off-link of authentication by ignoring ND packets received from off-link
senders. The Hop Limit field of all received packets is verified to senders. The Hop Limit field of all received packets is verified to
contain 255, the maximum legal value. Because routers decrement the contain 255, the maximum legal value. Because routers decrement the
Hop Limit on all packets they forward, received packets containing a Hop Limit on all packets they forward, received packets containing a
Hop Limit of 255 must have originated from a neighbor. Hop Limit of 255 must have originated from a neighbor.
In order to allow for IP layer authentication, a mechanism is Cryptographic security mechanisms for Neighbor Discovery are outside
required to allow for dynamic keying between neighbors. The use of the scope of this document and are defined in [SEND]. Alternatively,
the Internet Key Exchange [ICMPIKE] is not suited for creating IPsec can be used for IP layer authentication. The use of the
dynamic security associations that can be used to secure address Internet Key Exchange (IKE) is not suited for creating dynamic
resolution or neighbor solicitation messages as documented in security associations that can be used to secure address resolution
[ICMPIKE]. The security of Neighbor Discovery messages through or neighbor solicitation messages as documented in [ICMPIKE].
dynamic keying is outside the scope of this document and is addressed
in [SEND].
In some cases, it may be acceptable to use statically configured In some cases, it may be acceptable to use statically configured
security associations with either [IPv6-AH] or [IPv6-ESP] to secure security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure
Neighbor Discovery messages. However, it is important to note that Neighbor Discovery messages. However, it is important to note that
statically configured security associations are not scalable statically configured security associations are not scalable
(especially when considering multicast links) and are therefore (especially when considering multicast links) and are therefore
limited to small networks with known hosts. In any case, if either limited to small networks with known hosts. In any case, if either
[IPv6-AH] or [IPv6-ESP] is used, ND packets MUST be verified for the [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for
purpose of authentication. Packets that fail authentication checks the purpose of authentication. Packets that fail authentication
MUST be silently discarded. checks MUST be silently discarded.
12. RENUMBERING CONSIDERATIONS 12. RENUMBERING CONSIDERATIONS
The Neighbor Discovery protocol together with IPv6 Address The Neighbor Discovery protocol together with IPv6 Address
Autoconfiguration [ADDRCONF] provides mechanisms to aid in Autoconfiguration [ADDRCONF] provides mechanisms to aid in
renumbering - new prefixes and addresses can be introduced and old renumbering - new prefixes and addresses can be introduced and old
ones can be deprecated and removed. ones can be deprecated and removed.
The robustness of these mechanisms is based on all the nodes on the The robustness of these mechanisms is based on all the nodes on the
link receiving the Router Advertisement messages in a timely manner. link receiving the Router Advertisement messages in a timely manner.
skipping to change at page 76, line 31 skipping to change at page 76, line 26
sending Router Advertisements that contain appropriate (and current) sending Router Advertisements that contain appropriate (and current)
prefixes. A host connected to a network that has no functioning prefixes. A host connected to a network that has no functioning
routers is likely to have more serious problems than just a lack of a routers is likely to have more serious problems than just a lack of a
valid prefix and address. valid prefix and address.
The above discussion does not distinguish between the preferred and The above discussion does not distinguish between the preferred and
valid lifetimes. For all practical purposes it is probably valid lifetimes. For all practical purposes it is probably
sufficient to track the valid lifetime since the preferred lifetime sufficient to track the valid lifetime since the preferred lifetime
will not exceed the valid lifetime. will not exceed the valid lifetime.
13. IPR Acknowledgements
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
REFERENCES REFERENCES
NORMATIVE NORMATIVE
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 3513, April 2003.
[ICMPv6] Conta, A. and S. Deering, "Internet Control Message [ICMPv6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6 Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998. (IPv6) Specification", RFC 2463, December 1998.
skipping to change at page 77, line 18 skipping to change at page 77, line 20
[ARP] Plummer, D., "An Ethernet Address Resolution Protocol", [ARP] Plummer, D., "An Ethernet Address Resolution Protocol",
STD 37, RFC 826, November 1982. STD 37, RFC 826, November 1982.
[ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by [ASSIGNED] Reynolds, J., "Assigned Numbers: RFC 1700 is Replaced by
an On-line Database", RFC 3232, January 2002. an On-line Database", RFC 3232, January 2002.
[DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for [DHCPv6] Droms, R., Ed, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003. IPv6 (DHCPv6)", RFC 3315, July 2003.
[DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP)for IPv6", RFC 3736, April 2004.
[HR-CL] Braden, R., Editor, "Requirements for Internet Hosts -- [HR-CL] Braden, R., Editor, "Requirements for Internet Hosts --
Communication Layers", STD 3, RFC 1122, October 1989. Communication Layers", STD 3, RFC 1122, October 1989.
[ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE",
draft-arkko-icmpv6-ike-effects-02 (work in progress), draft-arkko-icmpv6-ike-effects-02 (work in progress),
March 2003. March 2003.
[ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5,
RFC 792, September 1981. RFC 792, September 1981.
skipping to change at page 77, line 50 skipping to change at page 77, line 49
[IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over
Ethernet Networks", RFC 2464, December 1998. Ethernet Networks", RFC 2464, December 1998.
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, " [IPv6-NBMA] Armitage, G., Schulter, P., Jork, M. and G. Harter, "
IPv6 over Non-broadcast Multiple Access (NBMA) IPv6 over Non-broadcast Multiple Access (NBMA)
networks", RFC 2491, January 1999. networks", RFC 2491, January 1999.
[IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the [IPv6-SA] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[IPv6-AUTH] Kent, S. and R. Atkinson, "IP Authentication Header", [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December
RFC 2402, November 1998. 2005.
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC
Payload (ESP)", RFC 2406, November 1998. 4303, December 2005.
[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005. Sharing", RFC 4311, November 2005.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999. Listener Discovery for IPv6", RFC 2710, October 1999.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[NDMAN] Arkko, J., "Manual Configuration of Security [NDMAN] Arkko, J., "Manual Configuration of Security
Associations for IPv6 Neighbor Discovery", draft-arkko- Associations for IPv6 Neighbor Discovery", draft-arkko-
manual-icmpv6-sas-02 (work in progress), March 2003. manual-icmpv6-sas-02 (work in progress), March 2003.
[PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust and Threats", RFC 3756, May 2004.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004. February 2004.
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
and more Specific Routes", draft-ietf-ipv6-router- and more Specific Routes", draft-ietf-ipv6-router-
selection-07, (work in progress), January 2005. selection-07, (work in progress), January 2005.
[SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet [SH-MEDIA] Braden, R., Postel, J. and Y. Rekhter, "Internet
Architecture Extensions for Shared Media", RFC 1620, May Architecture Extensions for Shared Media", RFC 1620, May
1994. 1994.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)", Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971,
draft-ietf-send-ndopt-04 (work in progress), March 2005.
February 2004.
[SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic
Routing Messages", IEEE/ACM Transactions on Networking, Routing Messages", IEEE/ACM Transactions on Networking,
April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z
IANA CONSIDERATIONS IANA CONSIDERATIONS
This document does not require any new ICMPv6 types or codes to be This document does not require any new ICMPv6 types or codes to be
allocated. However, existing ICMPv6 types should be updated to point allocated. However, existing ICMPv6 types should be updated to point
to the document instead of RFC 2461. The procedure for the assignment to the document instead of RFC 2461. The procedure for the assignment
skipping to change at page 80, line 37 skipping to change at page 80, line 38
Daydreamer Daydreamer
Computer Systems Consulting Services Computer Systems Consulting Services
1384 Fontaine 1384 Fontaine
Madison Heights, Michigan 48071 Madison Heights, Michigan 48071
USA USA
EMail: Bill.Simpson@um.cc.umich.edu EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com bsimpson@MorningStar.com
Hesham Soliman Hesham Soliman
Flarion Technologies Qualcomm-Flarion Technologies
Phone: +1 908 997 9775 Email: Hesham@Qualcomm.com
Email: H.Soliman@flarion.com
APPENDIX A: MULTIHOMED HOSTS APPENDIX A: MULTIHOMED HOSTS
There are a number of complicating issues that arise when Neighbor There are a number of complicating issues that arise when Neighbor
Discovery is used by hosts that have multiple interfaces. This Discovery is used by hosts that have multiple interfaces. This
section does not attempt to define the proper operation of multihomed section does not attempt to define the proper operation of multihomed
hosts with regard to Neighbor Discovery. Rather, it identifies hosts with regard to Neighbor Discovery. Rather, it identifies
issues that require further study. Implementors are encouraged to issues that require further study. Implementors are encouraged to
experiment with various approaches to making Neighbor Discovery work experiment with various approaches to making Neighbor Discovery work
on multihomed hosts and to report their experiences. Further work on multihomed hosts and to report their experiences. Further work
skipping to change at page 88, line 42 skipping to change at page 88, line 45
Disclaimer of Validity Disclaimer of Validity
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.
This Internet-Draft expires November, 2006. This Internet-Draft expires February, 2007.
 End of changes. 24 change blocks. 
46 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/