draft-ietf-ipv6-2461bis-02.txt   draft-ietf-ipv6-2461bis-03.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: August 2005 IBM Expires: November 2005 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
February, 2005 May, 2005
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-02.txt> <draft-ietf-ipv6-2461bis-03.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, each author represents that any
patent or other IPR claims of which we are aware have been disclosed, applicable patent or other IPR claims of which he or she is aware
and any of which we become aware will be disclosed, in accordance have been or will be disclosed, and any of which he or she becomes
with RFC 3668 (BCP 79). aware will be disclosed, in accordance with Section 6 of BCP 79.
By submitting this Internet-Draft, we accept the provisions of By submitting this Internet-Draft, we accept the provisions of
Section 4 of RFC 3667 (BCP 78). Section 4 of RFC 3667 (BCP 78).
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
skipping to change at page 2, line 14 skipping to change at page 2, line 14
about the paths to active neighbors. about the paths to active neighbors.
Table of Contents Table of Contents
1. INTRODUCTION....................................................4 1. INTRODUCTION....................................................4
2. TERMINOLOGY.....................................................4 2. TERMINOLOGY.....................................................4
2.1. General...................................................4 2.1. General...................................................4
2.2. Link Types................................................8 2.2. Link Types................................................8
2.3. Addresses.................................................9 2.3. Addresses.................................................9
2.4. Requirements..............................................9 2.4. Requirements.............................................10
3. PROTOCOL OVERVIEW..............................................10 3. PROTOCOL OVERVIEW..............................................10
3.1. Comparison with IPv4.....................................13 3.1. Comparison with IPv4.....................................13
3.2. Supported Link Types.....................................15 3.2. Supported Link Types.....................................15
3.3. Securing Neighbor Discovery messages......................17 3.3. Securing Neighbor Discovery messages......................17
4. MESSAGE FORMATS................................................17 4. MESSAGE FORMATS................................................17
4.1. Router Solicitation Message Format.......................17 4.1. Router Solicitation Message Format.......................17
4.2. Router Advertisement Message Format......................18 4.2. Router Advertisement Message Format......................18
4.3. Neighbor Solicitation Message Format.....................20 4.3. Neighbor Solicitation Message Format.....................20
4.4. Neighbor Advertisement Message Format....................22 4.4. Neighbor Advertisement Message Format....................22
4.5. Redirect Message Format..................................24 4.5. Redirect Message Format..................................24
4.6. Option Formats...........................................26 4.6. Option Formats...........................................26
4.6.2. Prefix Information.................................27 4.6.2. Prefix Information.................................27
4.6.3. Redirected Header..................................29 4.6.3. Redirected Header..................................29
4.6.4. MTU................................................30 4.6.4. MTU................................................30
5. CONCEPTUAL MODEL OF A HOST.....................................31 5. CONCEPTUAL MODEL OF A HOST.....................................31
5.1. Conceptual Data Structures...............................31 5.1. Conceptual Data Structures...............................31
5.2. Conceptual Sending Algorithm.............................33 5.2. Conceptual Sending Algorithm.............................33
5.3. Garbage Collection and Timeout Requirements..............34 5.3. Garbage Collection and Timeout Requirements..............35
6. ROUTER AND PREFIX DISCOVERY....................................35 6. ROUTER AND PREFIX DISCOVERY....................................35
6.1. Message Validation.......................................36 6.1. Message Validation.......................................36
6.1.1. Validation of Router Solicitation Messages.........36 6.1.1. Validation of Router Solicitation Messages.........36
6.1.2. Validation of Router Advertisement Messages........36 6.1.2. Validation of Router Advertisement Messages........36
6.2. Router Specification.....................................37 6.2. Router Specification.....................................37
6.2.1. Router Configuration Variables....................37 6.2.1. Router Configuration Variables....................37
6.2.2. Becoming An Advertising Interface.................41 6.2.2. Becoming An Advertising Interface.................41
6.2.3. Router Advertisement Message Content..............41 6.2.3. Router Advertisement Message Content..............42
6.2.4. Sending Unsolicited Router Advertisements.........43 6.2.4. Sending Unsolicited Router Advertisements.........43
6.2.5. Ceasing To Be An Advertising Interface............43 6.2.5. Ceasing To Be An Advertising Interface............44
6.2.6. Processing Router Solicitations...................44 6.2.6. Processing Router Solicitations...................44
6.2.7. Router Advertisement Consistency..................45 6.2.7. Router Advertisement Consistency..................45
6.2.8. Link-local Address Change.........................46 6.2.8. Link-local Address Change.........................46
6.3. Host Specification.......................................47 6.3. Host Specification.......................................47
6.3.1. Host Configuration Variables......................47 6.3.1. Host Configuration Variables......................47
6.3.2. Host Variables....................................47 6.3.2. Host Variables....................................47
6.3.3. Interface Initialization..........................48 6.3.3. Interface Initialization..........................48
6.3.4. Processing Received Router Advertisements.........48 6.3.4. Processing Received Router Advertisements.........48
6.3.5. Timing out Prefixes and Default Routers...........51 6.3.5. Timing out Prefixes and Default Routers...........51
6.3.6. Default Router Selection..........................51 6.3.6. Default Router Selection..........................51
6.3.7. Sending Router Solicitations......................52 6.3.7. Sending Router Solicitations......................52
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......53 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION.......54
7.1. Message Validation.......................................54 7.1. Message Validation.......................................54
7.1.1. Validation of Neighbor Solicitations..............54 7.1.1. Validation of Neighbor Solicitations..............54
7.1.2. Validation of Neighbor Advertisements.............54 7.1.2. Validation of Neighbor Advertisements.............55
7.2. Address Resolution.......................................55 7.2. Address Resolution.......................................55
7.2.1. Interface Initialization..........................55 7.2.1. Interface Initialization..........................56
7.2.2. Sending Neighbor Solicitations....................56 7.2.2. Sending Neighbor Solicitations....................56
7.2.3. Receipt of Neighbor Solicitations.................57 7.2.3. Receipt of Neighbor Solicitations.................57
7.2.4. Sending Solicited Neighbor Advertisements.........58 7.2.4. Sending Solicited Neighbor Advertisements.........58
7.2.5. Receipt of Neighbor Advertisements................58 7.2.5. Receipt of Neighbor Advertisements................59
7.2.6. Sending Unsolicited Neighbor Advertisements.......60 7.2.6. Sending Unsolicited Neighbor Advertisements.......61
7.2.7. Anycast Neighbor Advertisements...................61 7.2.7. Anycast Neighbor Advertisements...................62
7.2.8. Proxy Neighbor Advertisements.....................62 7.2.8. Proxy Neighbor Advertisements.....................62
7.3. Neighbor Unreachability Detection........................62 7.3. Neighbor Unreachability Detection........................63
7.3.1. Reachability Confirmation.........................63 7.3.1. Reachability Confirmation.........................63
7.3.2. Neighbor Cache Entry States.......................64 7.3.2. Neighbor Cache Entry States.......................64
7.3.3. Node Behavior.....................................65 7.3.3. Node Behavior.....................................65
8. REDIRECT FUNCTION..............................................67 8. REDIRECT FUNCTION..............................................67
8.1. Validation of Redirect Messages..........................67 8.1. Validation of Redirect Messages..........................67
8.2. Router Specification.....................................68 8.2. Router Specification.....................................68
8.3. Host Specification.......................................69 8.3. Host Specification.......................................69
9. EXTENSIBILITY - OPTION PROCESSING..............................70 9. EXTENSIBILITY - OPTION PROCESSING..............................70
10. PROTOCOL CONSTANTS............................................71 10. PROTOCOL CONSTANTS............................................71
11. SECURITY CONSIDERATIONS.......................................72 11. SECURITY CONSIDERATIONS.......................................72
11.1 Threat analysis...........................................72 11.1 Threat analysis...........................................73
11.2 Securing Neighbor Discovery messages......................74 11.2 Securing Neighbor Discovery messages......................74
12. RENUMBERING CONSIDERATIONS....................................74 12. RENUMBERING CONSIDERATIONS....................................75
REFERENCES.........................................................76 REFERENCES.........................................................76
Authors' Addresses.................................................78 Authors' Addresses.................................................78
APPENDIX A: MULTIHOMED HOSTS.......................................78 APPENDIX A: MULTIHOMED HOSTS.......................................79
APPENDIX B: FUTURE EXTENSIONS......................................80 APPENDIX B: FUTURE EXTENSIONS......................................80
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............81
APPENDIX D: SUMMARY OF ISROUTER RULES..............................82 APPENDIX D: SUMMARY OF ISROUTER RULES..............................83
APPENDIX E: IMPLEMENTATION ISSUES..................................83 APPENDIX E: IMPLEMENTATION ISSUES..................................84
Appendix E.1: Reachability confirmations...........................83 Appendix E.1: Reachability confirmations...........................84
APPENDIX F: CHANGES FROM RFC 2461..................................85 APPENDIX F: CHANGES FROM RFC 2461..................................85
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
skipping to change at page 4, line 37 skipping to change at page 4, line 37
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-CELLULAR] discuss the use
of this protocol over some cellular links, which are examples of NBMA of 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, Allison Mankin, Dan McDonald, Charles Perkins, Matt Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles
Thomas, and Susan Thomson. Perkins, Matt Thomas, and Susan Thomson.
2. TERMINOLOGY 2. TERMINOLOGY
2.1. General 2.1. General
IP - Internet Protocol Version 6. The terms IPv4 and IP - Internet Protocol Version 6. The terms IPv4 and
IPv6 are used only in contexts where necessary to avoid IPv6 are used only in contexts where necessary to avoid
ambiguity. ambiguity.
ICMP - Internet Message Control Protocol for the Internet ICMP - Internet Message Control Protocol for the Internet
skipping to change at page 8, line 25 skipping to change at page 8, line 25
point-to-point - a link that connects exactly two interfaces. A point-to-point - a link that connects exactly two interfaces. A
point-to-point link is assumed to have multicast point-to-point link is assumed to have multicast
capability and have a link-local address. capability and have a link-local address.
non-broadcast multi-access (NBMA) non-broadcast multi-access (NBMA)
- a link to which more than two interfaces can attach, - a link to which more than two interfaces can attach,
but that does not support a native form of multicast but that does not support a native form of multicast
or broadcast (e.g., X.25, ATM, frame relay, etc.). or broadcast (e.g., X.25, ATM, frame relay, etc.).
Note that all link types (including NBMA) are Note that all link types (including NBMA) are
expected to provide multicast service for IP (e.g., expected to provide multicast service for
using multicast servers), but it is an issue for applications that need it(e.g., using multicast
further study whether ND should use such facilities servers). However, it is an issue for further study
whether ND should use such facilities
or an alternate mechanism that provides the or an alternate mechanism that provides the
equivalent ND services. equivalent multicast capability for ND.
shared media - a link that allows direct communication among a shared media - a link that allows direct communication among a
number of nodes, but attached nodes are configured number of nodes, but attached nodes are configured
in such a way that they do not have complete prefix in such a way that they do not have complete prefix
information for all on-link destinations. That is, information for all on-link destinations. That is,
at the IP level, nodes on the same link may not know at the IP level, nodes on the same link may not know
that they are neighbors; by default, they that they are neighbors; by default, they
communicate through a router. Examples are large communicate through a router. Examples are large
(switched) public data networks such as SMDS and B- (switched) public data networks such as SMDS and B-
ISDN. Also known as "large clouds". See [SH- ISDN. Also known as "large clouds". See [SH-
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
high-order bits, e.g., due to multiple high-order least significant bits, e.g., due to multiple
prefixes associated with different providers, will map high-order prefixes associated with different
to the same solicited-node address thereby reducing the providers, will map to the same solicited-node address
number of multicast addresses a node must join. thereby reducing the number of multicast addresses a
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
address (e.g., the address is unknown). It is never address (e.g., the address is unknown). It is never
used as a destination address, but may be used as a used as a destination address, but may be used as a
source address if the sender does not (yet) know its source address if the sender does not (yet) know its
own address (e.g., while verifying an address is unused own address (e.g., while verifying an address is unused
during address autoconfiguration [ADDRCONF]). The during address autoconfiguration [ADDRCONF]). The
unspecified address has a value of 0:0:0:0:0:0:0:0. unspecified address has a value of 0:0:0:0:0:0:0:0.
Note that this specification does not strictly comply with the Note that this specification does not strictly comply with the
consistency requirements for the scopes of source and destination consistency requirements in [ADDR-SEL] for the scopes of source and
addresses. It is possible in some cases for hosts to use a source destination addresses. It is possible in some cases for hosts to use
address of a larger scope than the destination address in the IPv6 a source address of a larger scope than the destination address in
header. the IPv6 header.
2.4. Requirements 2.4. Requirements
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in [KEYWORDS]. document, are to be interpreted as described in [KEYWORDS].
This document also makes use of internal conceptual variables to This document also makes use of internal conceptual variables to
describe protocol behavior and external variables that an describe protocol behavior and external variables that an
implementation must allow system administrators to change. The implementation must allow system administrators to change. The
skipping to change at page 19, line 18 skipping to change at page 19, line 22
Cur Hop Limit 8-bit unsigned integer. The default value that Cur Hop Limit 8-bit unsigned integer. The default value that
should be placed in the Hop Count field of the IP should be placed in the Hop Count field of the IP
header for outgoing IP packets. A value of zero header for outgoing IP packets. A value of zero
means unspecified (by this router). means unspecified (by this router).
M 1-bit "Managed address configuration" flag. When M 1-bit "Managed address configuration" flag. When
set, it indicates that Dynamic Host Configuration set, it indicates that Dynamic Host Configuration
Protocol [DHCPv6] is available for address Protocol [DHCPv6] is available for address
configuration in addition to any addresses configuration in addition to any addresses
autoconfigured using stateless address autoconfigured using stateless address
autoconfiguration. The use of this flag is autoconfiguration.
further described in [ADDRCONF].
O 1-bit "Other configuration" flag. When O 1-bit "Other configuration" flag. When
set, it indicates that [DHCPv6lite] is available set, it indicates that [DHCPv6lite] is available
for autoconfiguration of other (non-address) for autoconfiguration of other (non-address)
information. Examples of such information are DNS- information. Examples of such information are DNS-
related information or information on other servers related information or information on other servers
within the network. within the network.
Reserved A 6-bit unused field. It MUST be initialized to Reserved A 6-bit unused field. 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
skipping to change at page 24, line 14 skipping to change at page 24, line 17
responding to a unicast Neighbor Solicitation this responding to a unicast Neighbor Solicitation this
option SHOULD be included. option SHOULD be included.
The option MUST be included for multicast The option MUST be included for multicast
solicitations in order to avoid infinite Neighbor solicitations in order to avoid infinite Neighbor
Solicitation "recursion" when the peer node does Solicitation "recursion" when the peer node does
not have a cache entry to return a Neighbor not have a cache entry to return a Neighbor
Advertisements message. When responding to unicast Advertisements message. When responding to unicast
solicitations, the option can be omitted since the solicitations, the option can be omitted since the
sender of the solicitation has the correct link- sender of the solicitation has the correct link-
layer address; otherwise it would not have be able layer address; otherwise it would not be able
to send the unicast solicitation in the first to send the unicast solicitation in the first
place. However, including the link-layer address in place. However, including the link-layer address in
this case adds little overhead and eliminates a this case adds little overhead and eliminates a
potential race condition where the sender deletes potential race condition where the sender deletes
the cached link-layer address prior to receiving a the cached link-layer address prior to receiving a
response to a previous solicitation. response to a previous solicitation.
Future versions of this protocol may define new option types. Future versions of this protocol may define new option types.
Receivers MUST silently ignore any options they do not recognize Receivers MUST silently ignore any options they do not recognize
and continue processing the message. and continue processing the message.
skipping to change at page 28, line 18 skipping to change at page 28, line 24
Fields: Fields:
Type 3 Type 3
Length 4 Length 4
Prefix Length 8-bit unsigned integer. The number of leading bits Prefix Length 8-bit unsigned integer. The number of leading bits
in the Prefix that are valid. The value ranges in the Prefix that are valid. The value ranges
from 0 to 128. The prefix length field provides from 0 to 128. The prefix length field provides
necessary information for on-link determination necessary information for on-link determination
(when combined with other flags in the prefix (when combined with the L flag in the prefix
option). It also assists with address option). It also assists with address
autoconfiguration as specified in [ADDRCONF], for autoconfiguration as specified in [ADDRCONF], for
which there may be more restrictions on the prefix which there may be more restrictions on the prefix
length. length.
L 1-bit on-link flag. When set, indicates that this L 1-bit on-link flag. When set, indicates that this
prefix can be used for on-link determination. When prefix can be used for on-link determination. When
not set the advertisement makes no statement about not set the advertisement makes no statement about
on-link or off-link properties of the prefix. For on-link or off-link properties of the prefix. For
instance, the prefix might be used for address instance, the prefix might be used for address
configuration with some of the addresses belonging configuration with some of the addresses belonging
to the prefix being on-link and others being off- to the prefix being on-link and others being off-
link. link.
A 1-bit autonomous address-configuration flag. When A 1-bit autonomous address-configuration flag. When
set indicates that this prefix can be used for set indicates that this prefix can be used for
autonomous address configuration as specified in stateless address configuration as specified in
[ADDRCONF]. [ADDRCONF].
Reserved1 6-bit unused field. It MUST be initialized to zero Reserved1 6-bit unused field. It MUST be initialized to zero
by the sender and MUST be ignored by the receiver. by the sender and MUST be ignored by the receiver.
Valid Lifetime Valid Lifetime
32-bit unsigned integer. The length of time in 32-bit unsigned integer. The length of time in
seconds (relative to the time the packet is sent) seconds (relative to the time the packet is sent)
that the prefix is valid for the purpose of on-link that the prefix is valid for the purpose of on-link
determination. A value of all one bits determination. A value of all one bits
skipping to change at page 42, line 12 skipping to change at page 42, line 18
A router sends periodic as well as solicited Router Advertisements A router sends periodic as well as solicited Router Advertisements
out its advertising interfaces. Outgoing Router Advertisements are out its advertising interfaces. Outgoing Router Advertisements are
filled with the following values consistent with the message format filled with the following values consistent with the message format
given in Section 4.2: given in Section 4.2:
- In the Router Lifetime field: the interface's configured - In the Router Lifetime field: the interface's configured
AdvDefaultLifetime. AdvDefaultLifetime.
- In the M and O flags: the interface's configured AdvManagedFlag - In the M and O flags: the interface's configured AdvManagedFlag
and AdvOtherConfigFlag, respectively. See [ADDRCONF]. and AdvOtherConfigFlag, respectively.
- In the Cur Hop Limit field: the interface's configured - In the Cur Hop Limit field: the interface's configured
CurHopLimit. CurHopLimit.
- In the Reachable Time field: the interface's configured - In the Reachable Time field: the interface's configured
AdvReachableTime. AdvReachableTime.
- In the Retrans Timer field: the interface's configured - In the Retrans Timer field: the interface's configured
AdvRetransTimer. AdvRetransTimer.
skipping to change at page 50, line 54 skipping to change at page 51, line 10
the result of a previously-received advertisement, reset its the result of a previously-received advertisement, reset its
invalidation timer to the Valid Lifetime value in the Prefix invalidation timer to the Valid Lifetime value in the Prefix
Information option. If the new Lifetime value is zero, time-out Information option. If the new Lifetime value is zero, time-out
the prefix immediately (see Section 6.3.5). the prefix immediately (see Section 6.3.5).
- If the Prefix Information option's Valid Lifetime field is zero, - If the Prefix Information option's Valid Lifetime field is zero,
and the prefix is not present in the host's Prefix List, and the prefix is not present in the host's Prefix List,
silently ignore the option. silently ignore the option.
Stateless address autoconfiguration [ADDRCONF] may in some Stateless address autoconfiguration [ADDRCONF] may in some
circumstances increase the Valid Lifetime of a prefix or ignore it circumstances use a larger Valid Lifetime of a prefix or ignore it
completely in order to prevent a particular denial of service attack. completely in order to prevent a particular denial of service attack.
However, since the effect of the same denial of service targeted at However, since the effect of the same denial of service targeted at
the on-link prefix list is not catastrophic (hosts would send packets the on-link prefix list is not catastrophic (hosts would send packets
to a default router and receive a redirect rather than sending to a default router and receive a redirect rather than sending
packets directly to a neighbor) the Neighbor Discovery protocol does packets directly to a neighbor) the Neighbor Discovery protocol does
not impose such a check on the prefix lifetime values. Similarly, not impose such a check on the prefix lifetime values. Similarly,
[ADDRCONF] may impose certain restrictions on the prefix length for [ADDRCONF] may impose certain restrictions on the prefix length for
address configuration purposes. Therefore, the prefix might be address configuration purposes. Therefore, the prefix might be
rejected by [ADDRCONF] implementation in the host. However, the rejected by [ADDRCONF] implementation in the host. However, the
prefix length is still valid for on-link determination when combined prefix length is still valid for on-link determination when combined
skipping to change at page 55, line 44 skipping to change at page 55, line 51
7.2. Address Resolution 7.2. Address Resolution
Address resolution is the process through which a node determines the Address resolution is the process through which a node determines the
link-layer address of a neighbor given only its IP address. Address link-layer address of a neighbor given only its IP address. Address
resolution is performed only on addresses that are determined to be resolution is performed only on addresses that are determined to be
on-link and for which the sender does not know the corresponding on-link and for which the sender does not know the corresponding
link-layer address (see section 5.2). Address resolution is never link-layer address (see section 5.2). Address resolution is never
performed on multicast addresses. performed on multicast addresses.
It is possible that a host may receive a solicitation or a router
advertisement without a link-layer address option included. These
messages MUST not create or update neighbor cache entries, except
with respect to the IsRouter flag as specified in sections 6.3.4 and
7.2.5. If a neighbor cache entry does not exist for the source of
such a message, Address Resolution will be required before unicast
communications with that address to begin. This is particularly
relevant for unicast responses to solicitations where an additional
packet exchange is required for advertisement delivery.
7.2.1. Interface Initialization 7.2.1. Interface Initialization
When a multicast-capable interface becomes enabled the node MUST join When a multicast-capable interface becomes enabled the node MUST join
the all-nodes multicast address on that interface, as well as the the all-nodes multicast address on that interface, as well as the
solicited-node multicast address corresponding to each of the IP solicited-node multicast address corresponding to each of the IP
addresses assigned to the interface. addresses assigned to the interface.
The set of addresses assigned to an interface may change over time. The set of addresses assigned to an interface may change over time.
New addresses might be added and old addresses might be removed New addresses might be added and old addresses might be removed
[ADDRCONF]. In such cases the node MUST join and leave the [ADDRCONF]. In such cases the node MUST join and leave the
skipping to change at page 57, line 15 skipping to change at page 57, line 31
Retransmissions MUST be rate-limited to at most one solicitation per Retransmissions MUST be rate-limited to at most one solicitation per
neighbor every RetransTimer milliseconds. neighbor every RetransTimer milliseconds.
If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT
solicitations, address resolution has failed. The sender MUST return solicitations, address resolution has failed. The sender MUST return
ICMP destination unreachable indications with code 3 (Address ICMP destination unreachable indications with code 3 (Address
Unreachable) for each packet queued awaiting address resolution. Unreachable) for each packet queued awaiting address resolution.
7.2.3. Receipt of Neighbor Solicitations 7.2.3. Receipt of Neighbor Solicitations
A valid Neighbor Solicitation that does not meet any the following A valid Neighbor Solicitation that does not meet any of the following
requirements MUST be silently discarded: requirements MUST be silently discarded:
- The Target Address is a "valid" unicast or anycast address - The Target Address is a "valid" unicast or anycast address
assigned to the receiving interface [ADDRCONF], assigned to the receiving interface [ADDRCONF],
- The Target Address is a unicast or anycast address for which the - The Target Address is a unicast or anycast address for which the
node is offering proxy service, or node is offering proxy service, or
- The Target Address is a "tentative" address on which Duplicate - The Target Address is a "tentative" address on which Duplicate
Address Detection is being performed [ADDRCONF]. Address Detection is being performed [ADDRCONF].
skipping to change at page 59, line 20 skipping to change at page 59, line 37
Target Link-Layer address option included, the receiving node SHOULD Target Link-Layer address option included, the receiving node SHOULD
silently discard the received advertisement. silently discard the received advertisement.
If the target's Neighbor Cache entry is in the INCOMPLETE state when If the target's Neighbor Cache entry is in the INCOMPLETE state when
the advertisement is received, one of two things happen: If the the advertisement is received, one of two things happen: If the
advertisement were solicited, the state is changed to REACHABLE. advertisement were solicited, the state is changed to REACHABLE.
Otherwise, the state is set to STALE. Note that the Override flag is Otherwise, the state is set to STALE. Note that the Override flag is
ignored if the entry is in the ignored if the entry is in the
INCOMPLETE state. INCOMPLETE state.
If the Neighbor Cache entry is not in INCOMPLETE state, the receiving If the Neighbor Cache entry is in INCOMPLETE state, the receiving
node performs the following steps: node performs the following steps:
- It records the link-layer address in the Neighbor Cache entry. - It records the link-layer address in the Neighbor Cache entry.
- If the advertisement's Solicited flag is set, the state of the - If the advertisement's Solicited flag is set, the state of the
entry is set to REACHABLE, otherwise it is set to STALE. entry is set to REACHABLE, otherwise it is set to STALE.
- It sets the IsRouter flag in the cache entry based on the Router - It sets the IsRouter flag in the cache entry based on the Router
flag in the received advertisement. flag in the received advertisement.
skipping to change at page 59, line 45 skipping to change at page 60, line 12
INCOMPLETE when the advertisement is received, the following actions INCOMPLETE when the advertisement is received, the following actions
take place: take place:
I. If the Override flag is clear and the supplied link-layer address I. If the Override flag is clear and the supplied link-layer address
differs from that in the cache, then one of two actions takes differs from that in the cache, then one of two actions takes
place: place:
a. If the state of the entry is REACHABLE, set it to STALE, but a. If the state of the entry is REACHABLE, set it to STALE, but
do not update the entry in any other way. do not update the entry in any other way.
b. Otherwise, the received advertisement should be ignored and MUST b. Otherwise, the received advertisement should be ignored and MUST
NOT update the cache. NOT update the cache.
II. If the Override flag is set, or, both the Override flag is clear II. If the Override flag is set, or the supplied Override flag is
and the supplied link-layer address is the same as that in the Clear, or the supplied link-layer address is the same as that in
cache, or no Target Link-layer address option was supplied, the cache, or no Target Link-layer address option was supplied,
the received advertisement MUST update the Neighbor Cache entry as the received advertisement MUST update the Neighbor Cache entry
follows: as follows:
- The link-layer address in the Target Link-Layer Address option - The link-layer address in the Target Link-Layer Address option
MUST be inserted in the cache (if one is supplied and is different MUST be inserted in the cache (if one is supplied and is different
than the already recorded address). than the already recorded address).
- If the Solicited flag is set, the state of the entry MUST be set - If the Solicited flag is set, the state of the entry MUST be set
to REACHABLE. If the Solicited flag is zero and the link-layer to REACHABLE. If the Solicited flag is zero and the link-layer
address was updated with a different address the state MUST be set address was updated with a different address the state MUST be set
to STALE. Otherwise, the entry's state remains unchanged. to STALE. Otherwise, the entry's state remains unchanged.
skipping to change at page 63, line 52 skipping to change at page 64, line 18
and a node is sending packets to a neighbor, the node actively probes and a node is sending packets to a neighbor, the node actively probes
the neighbor using unicast Neighbor Solicitation messages to verify the neighbor using unicast Neighbor Solicitation messages to verify
that the forward path is still working. that the forward path is still working.
The receipt of a solicited Neighbor Advertisement serves as The receipt of a solicited Neighbor Advertisement serves as
reachability confirmation, since advertisements with the Solicited reachability confirmation, since advertisements with the Solicited
flag set to one are sent only in response to a Neighbor Solicitation. flag set to one are sent only in response to a Neighbor Solicitation.
Receipt of other Neighbor Discovery messages such as Router Receipt of other Neighbor Discovery messages such as Router
Advertisements and Neighbor Advertisement with the Solicited flag set Advertisements and Neighbor Advertisement with the Solicited flag set
to zero MUST NOT be treated as a reachability confirmation. Receipt to zero MUST NOT be treated as a reachability confirmation. Receipt
of unsolicited messages only confirm the one-way path from the sender of unsolicited messages only confirms the one-way path from the
to the recipient node. In contrast, Neighbor Unreachability sender to the recipient node. In contrast, Neighbor Unreachability
Detection requires that a node keep track of the reachability of the Detection requires that a node keep track of the reachability of the
forward path to a neighbor from the its perspective, not the forward path to a neighbor from the its perspective, not the
neighbor's perspective. Note that receipt of a solicited neighbor's perspective. Note that receipt of a solicited
advertisement indicates that a path is working in both directions. advertisement indicates that a path is working in both directions.
The solicitation must have reached the neighbor, prompting it to The solicitation must have reached the neighbor, prompting it to
generate an advertisement. Likewise, receipt of an advertisement generate an advertisement. Likewise, receipt of an advertisement
indicates that the path from the sender to the recipient is working. indicates that the path from the sender to the recipient is working.
However, the latter fact is known only to the recipient; the However, the latter fact is known only to the recipient; the
advertisement's sender has no direct way of knowing that the advertisement's sender has no direct way of knowing that the
advertisement it sent actually reached a neighbor. From the advertisement it sent actually reached a neighbor. From the
skipping to change at page 68, line 42 skipping to change at page 69, line 8
- the Source Address field of the packet identifies a neighbor, - the Source Address field of the packet identifies a neighbor,
and and
- the router determines (by means outside the scope of this - the router determines (by means outside the scope of this
specification) that a better first-hop node resides on specification) that a better first-hop node resides on
the same link as the sending node for the Destination Address of the same link as the sending node for the Destination Address of
the packet being forwarded, and the packet being forwarded, and
- the Destination Address of the packet is not a multicast - the Destination Address of the packet is not a multicast
address, and address
The transmitted redirect packet contains, consistent with the message The transmitted redirect packet contains, consistent with the message
format given in Section 4.5: format given in Section 4.5:
- In the Target Address field: the address to which subsequent - In the Target Address field: the address to which subsequent
packets for the destination SHOULD be sent. If the target is a packets for the destination SHOULD be sent. If the target is a
router, that router's link-local address MUST be used. If the router, that router's link-local address MUST be used. If the
target is a host the target address field MUST be set to the target is a host the target address field MUST be set to the
same value as the Destination Address field. same value as the Destination Address field.
skipping to change at page 72, line 52 skipping to change at page 73, line 17
packets destined for other nodes. This section deals with the main packets destined for other nodes. This section deals with the main
threats related to Neighbor Discovery messages and possible security threats related to Neighbor Discovery messages and possible security
mechanisms that can mitigate these threats. mechanisms that can mitigate these threats.
11.1 Threat analysis 11.1 Threat analysis
This section discusses the main threats associated with Neighbor This section discusses the main threats associated with Neighbor
Discovery. A more detailed analysis can be found in [PSREQ]. The main Discovery. A more detailed analysis can be found in [PSREQ]. The main
vulnerabilities of the protocol fall under three categories: vulnerabilities of the protocol fall under three categories:
- DoS attacks - Denial of Service (DoS) attacks.
- Address spoofing attacks - Address spoofing attacks.
- Router spoofing attacks. - Router spoofing attacks.
An example of denial of service attacks is that a node on the link An example of denial of service attacks is that a node on the link
that can send packets with an arbitrary IP source address can both that can send packets with an arbitrary IP source address can both
advertise itself as a default router and also send "forged" Router advertise itself as a default router and also send "forged" Router
Advertisement messages that immediately time out all other default Advertisement messages that immediately time out all other default
routers as well as all on-link prefixes. An intruder can achieve routers as well as all on-link prefixes. An intruder can achieve
this by sending out multiple Router Advertisements, one for each this by sending out multiple Router Advertisements, one for each
legitimate router, with the source address set to the address of legitimate router, with the source address set to the address of
another router, the Router Lifetime field set to zero, and the another router, the Router Lifetime field set to zero, and the
Preferred and Valid lifetimes set to zero for all the prefixes. Such Preferred and Valid lifetimes set to zero for all the prefixes. Such
an attack would cause all packets, for both on-link and off-link an attack would cause all packets, for both on-link and off-link
destinations, to go to the rogue router. That router can then destinations, to go to the rogue router. That router can then
selectively examine, modify or drop all packets sent on the link. The selectively examine, modify or drop all packets sent on the link. The
Neighbor Unreachability Detection will not detect such a black hole Neighbor Unreachability Detection (NUD) will not detect such a black
as long as the rogue router politely answers the NUD probes with a hole as long as the rogue router politely answers the NUD probes with
Neighbor Advertisement with the R-bit set. a Neighbor Advertisement with the R-bit set.
It is also possible for any host to launch a DoS attack on another It is also possible for any host to launch a DoS attack on another
host by preventing it from configuring an address using [ADDRCONF]. host by preventing it from configuring an address using [ADDRCONF].
The protocol does not allow hosts to verify whether the sender of a The protocol does not allow hosts to verify whether the sender of a
Neighbor Advertisement is the true owner of the IP address included Neighbor Advertisement is the true owner of the IP address included
in the message. in the message.
Redirect attacks can also be achieved by any host in order to flood a Redirect attacks can also be achieved by any host in order to flood a
victim or steal its traffic. A host can send a Neighbor advertisement victim or steal its traffic. A host can send a Neighbor advertisement
(in response to a solicitation) that contains its IP address and a (in response to a solicitation) that contains its IP address and a
victim's link layer address in order to flood the victim with victim's link layer address in order to flood the victim with
unwanted traffic. Alternatively, the host can send a Neighbor unwanted traffic. Alternatively, the host can send a Neighbor
Advertisement that includes a victim's IP address and its own link Advertisement that includes a victim's IP address and its own link
layer address to overwrite an existing entry in the sender's layer address to overwrite an existing entry in the sender's
destination cache, thereby forcing the sender to forward all of the destination cache, thereby forcing the sender to forward all of the
victim's traffic to itself. victim's traffic to itself.
The trust model for redirects is the same as in IPv4. A redirect is The trust model for redirects is the same as in IPv4. A redirect is
accepted only if received from the same router that is currently accepted only if received from the same router that is currently
being used for that destination. It is natural to trust the routers being used for that destination. If a host has been redirected to
on the link. If a host has been redirected to another node (i.e., another node (i.e., the destination is on-link) there is no way to
the destination is on-link) there is no way to prevent the target prevent the target from issuing another redirect to some other
from issuing another redirect to some other destination. However, destination. However, this exposure is no worse than it was before
this exposure is no worse than it was before being redirected; the being redirected; the target host, once subverted, could always act
target host, once subverted, could always act as a hidden router to as a hidden router to forward traffic elsewhere.
forward traffic elsewhere.
The protocol contains no mechanism to determine which neighbors are The protocol contains no mechanism to determine which neighbors are
authorized to send a particular type of message (e.g., Router authorized to send a particular type of message (e.g., Router
Advertisements); any neighbor, presumably even in the presence of Advertisements); any neighbor, presumably even in the presence of
authentication, can send Router Advertisement messages thereby being authentication, can send Router Advertisement messages thereby being
able to cause denial of service. Furthermore, any neighbor can send able to cause denial of service. Furthermore, any neighbor can send
proxy Neighbor Advertisements as well as unsolicited Neighbor proxy Neighbor Advertisements as well as unsolicited Neighbor
Advertisements as a potential denial of service attack. Advertisements as a potential denial of service attack.
Many link layers are also subject to different denial of service Many link layers are also subject to different denial of service
skipping to change at page 74, line 38 skipping to change at page 74, line 55
resolution or neighbor solicitation messages as documented in resolution or neighbor solicitation messages as documented in
[ICMPIKE]. The security of Neighbor Discovery messages through [ICMPIKE]. The security of Neighbor Discovery messages through
dynamic keying is outside the scope of this document and is addressed dynamic keying is outside the scope of this document and is addressed
in [SEND]. 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-AH] 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. 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
purpose of authentication. Packets that fail authentication 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 26 skipping to change at page 76, line 45
[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998. (IPv6) Specification", RFC 2460, December 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
INFORMATIVE INFORMATIVE
[ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address [ADDRCONF] Thomson, S. Narten, T, and T. Jinmei, "IPv6 Address
Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07, Dec Autoconfiguration", draft-ietf-ipv6-rfc2462bis-08, May
2004. 2005.
[ADDR-SEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host [ANYCST] Partridge, C., Mendez, T. and W. Milliken, "Host
Anycasting Service", RFC 1546, November 1993. Anycasting Service", RFC 1546, November 1993.
[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
skipping to change at page 79, line 48 skipping to change at page 80, line 22
No mechanism exists for the multihomed host to detect this No mechanism exists for the multihomed host to detect this
situation. situation.
If a multihomed host fails to receive Router Advertisements on one or If a multihomed host fails to receive Router Advertisements on one or
more of its interfaces, it will not know (in the absence of more of its interfaces, it will not know (in the absence of
configured information) which destinations are on-link on the configured information) which destinations are on-link on the
affected interface(s). This leads to a number of problems: affected interface(s). This leads to a number of problems:
1) If no Router Advertisement is received on any interfaces, a 1) If no Router Advertisement is received on any interfaces, a
multihomed host will have no way of knowing which interface to multihomed host will have no way of knowing which interface to
send packets out on, even for on-link destinations. Under send packets out on, even for on-link destinations.
similar conditions in the non-multihomed host case, a node One possible approach for a multihomed node would be to attempt
treats all destinations as residing on-link, and communication to perform address resolution on all interfaces, a step
proceeds. In the multihomed case, however, additional involving significant complexity.
information is needed to select the proper outgoing interface.
Alternatively, a node could attempt to perform address
resolution on all interfaces, a step involving significant
complexity that is not present in the non-multihomed host case.
2) If Router Advertisements are received on some, but not all 2) If Router Advertisements are received on some, but not all
interfaces, a multihomed host could choose to only send packets interfaces, a multihomed host could choose to only send packets
out on the interfaces on which it has received Router out on the interfaces on which it has received Router
Advertisements. A key assumption made here, however, is that Advertisements. A key assumption made here, however, is that
routers on those other interfaces will be able to route packets routers on those other interfaces will be able to route packets
to the ultimate destination, even when those destinations reside to the ultimate destination, even when those destinations reside
on the subnet to which the sender connects, but has no on-link on the subnet to which the sender connects, but has no on-link
prefix information. Should the assumption be FALSE, prefix information. Should the assumption be FALSE,
communication would fail. Even if the assumption holds, packets communication would fail. Even if the assumption holds, packets
skipping to change at page 84, line 38 skipping to change at page 85, line 6
directly (i.e., without an expensive lookup) once the TCP packet has directly (i.e., without an expensive lookup) once the TCP packet has
been demultiplexed to its corresponding control block. For other been demultiplexed to its corresponding control block. For other
implementation it may be possible to piggyback the reachability implementation it may be possible to piggyback the reachability
confirmation on the next packet submitted to IP assuming that the confirmation on the next packet submitted to IP assuming that the
implementation guards against the piggybacked confirmation becoming implementation guards against the piggybacked confirmation becoming
stale when no packets are sent to IP for an extended period of time. stale when no packets are sent to IP for an extended period of time.
TCP must also guard against thinking "stale" information indicates TCP must also guard against thinking "stale" information indicates
current reachability. For example, new data received 30 minutes current reachability. For example, new data received 30 minutes
after a window has opened up does not constitute a confirmation that after a window has opened up does not constitute a confirmation that
the path is currently working. In merely indicates that 30 minutes the path is currently working. It merely indicates that 30 minutes
ago the window update reached the peer i.e. the path was working at ago the window update reached the peer i.e. the path was working at
that point in time. An implementation must also take into account that point in time. An implementation must also take into account
TCP zero-window probes that are sent even if the path is broken and TCP zero-window probes that are sent even if the path is broken and
the window update did not reach the peer. the window update did not reach the peer.
For UDP based applications (RPC, DNS) it is relatively simple to make For UDP based applications (RPC, DNS) it is relatively simple to make
the client send reachability confirmations when the response packet the client send reachability confirmations when the response packet
is received. It is more difficult and in some cases impossible for is received. It is more difficult and in some cases impossible for
the server to generate such confirmations since there is no flow the server to generate such confirmations since there is no flow
control, i.e., the server can not determine whether a received control, i.e., the server can not determine whether a received
skipping to change at page 85, line 51 skipping to change at page 86, line 21
o Clarified router behaviour when receiving a Router Solicitation o Clarified router behaviour when receiving a Router Solicitation
without SLLAO. without SLLAO.
o Clarified that inconsistency checks for CurHopLimit are done for o Clarified that inconsistency checks for CurHopLimit are done for
none zero values only. none zero values only.
o Rearranged section 7.2.5 for clarity and described the processing o Rearranged section 7.2.5 for clarity and described the processing
when receiving the NA in INCOMPLETE state. when receiving the NA in INCOMPLETE state.
o Added clarifications in section 7.2 on how a node should react
upon receiving a message without SLLAO.
o Miscellaneous editorials. o Miscellaneous editorials.
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
skipping to change at page 86, line 31 skipping to change at page 86, line 52
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 ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2005). 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.
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 August, 2005. This Internet-Draft expires November, 2005.
 End of changes. 

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