draft-ietf-ipv6-2461bis-01.txt   draft-ietf-ipv6-2461bis-02.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: April 2005 IBM Expires: August 2005 IBM
E. Nordmark, E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Flarion
October, 2004 February, 2005
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-01.txt> <draft-ietf-ipv6-2461bis-02.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, we certify that any applicable By submitting this Internet-Draft, we certify that any applicable
patent or other IPR claims of which we are aware have been disclosed, patent or other IPR claims of which we are aware have been disclosed,
and any of which we become aware will be disclosed, in accordance and any of which we become aware will be disclosed, in accordance
with RFC 3668 (BCP 79). with RFC 3668 (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).
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.............................................10 2.4. Requirements..............................................9
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
skipping to change at page 2, line 50 skipping to change at page 2, line 50
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..............41
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............43
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.......................................46 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.......53
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.............54
7.2. Address Resolution.......................................55 7.2. Address Resolution.......................................55
7.2.1. Interface Initialization..........................55 7.2.1. Interface Initialization..........................55
7.2.2. Sending Neighbor Solicitations....................55 7.2.2. Sending Neighbor Solicitations....................56
7.2.3. Receipt of Neighbor Solicitations.................56 7.2.3. Receipt of Neighbor Solicitations.................57
7.2.4. Sending Solicited Neighbor Advertisements.........57 7.2.4. Sending Solicited Neighbor Advertisements.........58
7.2.5. Receipt of Neighbor Advertisements................58 7.2.5. Receipt of Neighbor Advertisements................58
7.2.6. Sending Unsolicited Neighbor Advertisements.......60 7.2.6. Sending Unsolicited Neighbor Advertisements.......60
7.2.7. Anycast Neighbor Advertisements...................61 7.2.7. Anycast Neighbor Advertisements...................61
7.2.8. Proxy Neighbor Advertisements.....................61 7.2.8. Proxy Neighbor Advertisements.....................62
7.3. Neighbor Unreachability Detection........................62 7.3. Neighbor Unreachability Detection........................62
7.3.1. Reachability Confirmation.........................62 7.3.1. Reachability Confirmation.........................63
7.3.2. Neighbor Cache Entry States.......................63 7.3.2. Neighbor Cache Entry States.......................64
7.3.3. Node Behavior.....................................64 7.3.3. Node Behavior.....................................65
8. REDIRECT FUNCTION..............................................66 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..............................69 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...........................................72
11.2 Securing Neighbor Discovery messages......................73 11.2 Securing Neighbor Discovery messages......................74
12. RENUMBERING CONSIDERATIONS....................................74 12. RENUMBERING CONSIDERATIONS....................................74
REFERENCES.........................................................75 REFERENCES.........................................................76
Authors' Addresses.................................................77 Authors' Addresses.................................................78
APPENDIX A: MULTIHOMED HOSTS.......................................78 APPENDIX A: MULTIHOMED HOSTS.......................................78
APPENDIX B: FUTURE EXTENSIONS......................................79 APPENDIX B: FUTURE EXTENSIONS......................................80
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............80
APPENDIX D: SUMMARY OF ISROUTER RULES..............................82 APPENDIX D: SUMMARY OF ISROUTER RULES..............................82
APPENDIX E: IMPLEMENTATION ISSUES..................................83 APPENDIX E: IMPLEMENTATION ISSUES..................................83
Appendix E.1: Reachability confirmations...........................83 Appendix E.1: Reachability confirmations...........................83
APPENDIX F: CHANGES FROM RFC 2461..................................84 APPENDIX F: CHANGES FROM RFC 2461..................................85
Full Copyright Statement.................Error! Bookmark not defined.
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 5, line 51 skipping to change at page 5, line 51
the rest of this document, references to unicast the rest of this document, references to unicast
addresses also apply to anycast addresses in those addresses also apply to anycast addresses in those
cases where the node is unaware that a unicast address cases where the node is unaware that a unicast address
is actually an anycast address. is actually an anycast address.
prefix - a bit string that consists of some number of initial prefix - a bit string that consists of some number of initial
bits of an address. bits of an address.
link-layer address link-layer address
- a link-layer identifier for an interface. Examples - a link-layer identifier for an interface. Examples
include IEEE 802 addresses for Ethernet links and E.164 include IEEE 802 addresses for Ethernet links.
addresses for ISDN links.
on-link - an address that is assigned to an interface on a on-link - an address that is assigned to an interface on a
specified link. A node considers an address to be on- specified link. A node considers an address to be on-
link if: link if:
- it is covered by one of the link's prefixes, or - it is covered by one of the link's prefixes, or
- a neighboring router specifies the address as - a neighboring router specifies the address as
the target of a Redirect message, or the target of a Redirect message, or
skipping to change at page 9, line 14 skipping to change at page 9, line 12
packets from B reach C, but packets from A don't packets from B reach C, but packets from A don't
reach C.) Many radio links exhibit these reach C.) Many radio links exhibit these
properties. properties.
2.3. Addresses 2.3. Addresses
Neighbor Discovery makes use of a number of different addresses Neighbor Discovery makes use of a number of different addresses
defined in [ADDR-ARCH], including: defined in [ADDR-ARCH], including:
all-nodes multicast address all-nodes multicast address
- the link-local scope address to reach all nodes. - the link-local scope address to reach all nodes,
FF02::1 FF02::1.
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 high-order bits, e.g., due to multiple high-order
prefixes associated with different providers, will map prefixes associated with different providers, will map
to the same solicited-node address thereby reducing the to the same solicited-node address thereby reducing the
number of multicast addresses a node must join. number of multicast addresses a node must join.
skipping to change at page 12, line 12 skipping to change at page 12, line 8
associated with the prefixes specify the intended uses of a associated with the prefixes specify the intended uses of a
particular prefix. Hosts use the advertised on-link prefixes to particular prefix. Hosts use the advertised on-link prefixes to
build and maintain a list that is used in deciding when a packet's build and maintain a list that is used in deciding when a packet's
destination is on-link or beyond a router. Note that a destination destination is on-link or beyond a router. Note that a destination
can be on-link even though it is not covered by any advertised on- can be on-link even though it is not covered by any advertised on-
link prefix. In such cases a router can send a Redirect informing link prefix. In such cases a router can send a Redirect informing
the sender that the destination is a neighbor. the sender that the destination is a neighbor.
Router Advertisements (and per-prefix flags) allow routers to inform Router Advertisements (and per-prefix flags) allow routers to inform
hosts how to perform Address Autoconfiguration. For example, routers hosts how to perform Address Autoconfiguration. For example, routers
can specify whether hosts should use stateful (DHCPv6) and/or can specify whether hosts should use DHCPv6 and/or
autonomous (stateless) address configuration. The exact semantics autonomous (stateless) address configuration.
and usage of the address configuration-related information is
specified in [ADDRCONF].
Router Advertisement messages also contain Internet parameters such Router Advertisement messages also contain Internet parameters such
as the hop limit that hosts should use in outgoing packets and, as the hop limit that hosts should use in outgoing packets and,
optionally, link parameters such as the link MTU. This facilitates optionally, link parameters such as the link MTU. This facilitates
centralized administration of critical parameters that can be set on centralized administration of critical parameters that can be set on
routers and automatically propagated to all attached hosts. routers and automatically propagated to all attached hosts.
Nodes accomplish address resolution by multicasting a Neighbor Nodes accomplish address resolution by multicasting a Neighbor
Solicitation that asks the target node to return its link-layer Solicitation that asks the target node to return its link-layer
address. Neighbor Solicitation messages are multicast to the address. Neighbor Solicitation messages are multicast to the
skipping to change at page 13, line 23 skipping to change at page 13, line 17
delay may be somewhat longer. delay may be somewhat longer.
Inbound load balancing - Nodes with replicated interfaces may want Inbound load balancing - Nodes with replicated interfaces may want
to load balance the reception of incoming packets across to load balance the reception of incoming packets across
multiple network interfaces on the same link. Such nodes multiple network interfaces on the same link. Such nodes
have multiple link-layer addresses assigned to the same have multiple link-layer addresses assigned to the same
interface. For example, a single network driver could interface. For example, a single network driver could
represent multiple network interface cards as a single represent multiple network interface cards as a single
logical interface having multiple link-layer addresses. logical interface having multiple link-layer addresses.
Load balancing is handled by allowing routers to omit the Neighbor Discovery allows a router to perform Load balancing
source link-layer address from Router Advertisement packets, for traffic addressed to itself by allowing routers to omit
thereby forcing neighbors to use Neighbor Solicitation the source link-layer address from Router Advertisement
messages to learn link-layer addresses of routers. Returned packets, thereby forcing neighbors to use Neighbor
Neighbor Advertisement messages can then contain link-layer Solicitation messages to learn link-layer addresses of
addresses that differ depending on who issued the routers. Returned Neighbor Advertisement messages can then
solicitation. contain link-layer addresses that differ depending on who
issued the solicitation. This specification does not support
a mechanism that allows host to Load balance incoming
packets.
Anycast addresses - Anycast addresses identify one of a set of Anycast addresses - Anycast addresses identify one of a set of
nodes providing an equivalent service, and multiple nodes on nodes providing an equivalent service, and multiple nodes on
the same link may be configured to recognize the same Anycast the same link may be configured to recognize the same Anycast
address. Neighbor Discovery handles anycasts by having nodes address. Neighbor Discovery handles anycasts by having nodes
expect to receive multiple Neighbor Advertisements for the expect to receive multiple Neighbor Advertisements for the
same target. All advertisements for anycast addresses are same target. All advertisements for anycast addresses are
tagged as being non-Override advertisements. This invokes tagged as being non-Override advertisements. This invokes
specific rules to determine which of potentially multiple specific rules to determine which of potentially multiple
advertisements should be used. advertisements should be used.
skipping to change at page 15, line 30 skipping to change at page 15, line 27
hosts to maintain the router associations in the event of the site hosts to maintain the router associations in the event of the site
renumbering to use new global prefixes. renumbering to use new global prefixes.
By setting the Hop Limit to 255, Neighbor Discovery is immune to By setting the Hop Limit to 255, Neighbor Discovery is immune to
off-link senders that accidentally or intentionally send ND off-link senders that accidentally or intentionally send ND
messages. In IPv4 off-link senders can send both ICMP Redirects messages. In IPv4 off-link senders can send both ICMP Redirects
and Router Advertisement messages. and Router Advertisement messages.
Placing address resolution at the ICMP layer makes the protocol Placing address resolution at the ICMP layer makes the protocol
more media-independent than ARP and makes it possible to use more media-independent than ARP and makes it possible to use
standard IP authentication and security mechanisms as appropriate. generic IP layer authentication and security mechanisms as
appropriate.
3.2. Supported Link Types 3.2. Supported Link Types
Neighbor Discovery supports links with different properties. In the Neighbor Discovery supports links with different properties. In the
presence of certain properties only a subset of the ND protocol presence of certain properties only a subset of the ND protocol
mechanisms are fully specified in this document: mechanisms are fully specified in this document:
point-to-point - Neighbor Discovery handles such links just like point-to-point - Neighbor Discovery handles such links just like
multicast links. (Multicast can be trivially multicast links. (Multicast can be trivially
provided on point to point links, and interfaces provided on point to point links, and interfaces
skipping to change at page 16, line 35 skipping to change at page 16, line 34
hop router for a received packet. hop router for a received packet.
The protocol is extensible (through the definition The protocol is extensible (through the definition
of new options) so that other solutions might be of new options) so that other solutions might be
possible in the future. possible in the future.
variable MTU - Neighbor Discovery allows routers to specify a MTU variable MTU - Neighbor Discovery allows routers to specify a MTU
for the link, which all nodes then use. All nodes for the link, which all nodes then use. All nodes
on a link must use the same MTU (or Maximum on a link must use the same MTU (or Maximum
Receive Unit) in order for multicast to work Receive Unit) in order for multicast to work
properly. Otherwise when multicasting a sender, properly. Otherwise when multicasting, a sender,
which can not know which nodes will receive the which can not know which nodes will receive the
packet, could not determine a minimum packet size packet, could not determine a minimum packet size
all receivers can process. that all receivers can process (or Maximum Receive
Unit).
asymmetric reachability asymmetric reachability
- Neighbor Discovery detects the absence of - Neighbor Discovery detects the absence of
symmetric reachability; a node avoids paths to a symmetric reachability; a node avoids paths to a
neighbor with which it does not have symmetric neighbor with which it does not have symmetric
connectivity. connectivity.
The Neighbor Unreachability Detection will The Neighbor Unreachability Detection will
typically identify such half-links and the node typically identify such half-links and the node
will refrain from using them. will refrain from using them.
skipping to change at page 19, line 21 skipping to change at page 19, line 21
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. The use of this flag is
further described in [ADDRCONF]. further described in [ADDRCONF].
O 1-bit "Other stateful 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. The use of this flag for add is within the network.
further described in [ADDRCONF].
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
receiver. receiver.
Router Lifetime Router Lifetime
16-bit unsigned integer. The lifetime associated 16-bit unsigned integer. The lifetime associated
with the default router in units of seconds. with the default router in units of seconds.
The field can contain values up to 65535 and The field can contain values up to 65535 and
receivers should handle any value, while the receivers should handle any value, while the
skipping to change at page 31, line 5 skipping to change at page 31, line 5
This option MUST be silently ignored for other This option MUST be silently ignored for other
Neighbor Discovery messages. Neighbor Discovery messages.
In configurations in which heterogeneous In configurations in which heterogeneous
technologies are bridged together, the maximum technologies are bridged together, the maximum
supported MTU may differ from one segment to supported MTU may differ from one segment to
another. If the bridges do not generate ICMP another. If the bridges do not generate ICMP
Packet Too Big messages, communicating nodes will Packet Too Big messages, communicating nodes will
be unable to use Path MTU to dynamically determine be unable to use Path MTU to dynamically determine
the appropriate MTU on a per-neighbor basis. In the appropriate MTU on a per-neighbor basis. In
such cases, routers use the MTU option to specify such cases, routers can be configured to use the
the maximum MTU value that is supported by all MTU option to specify the maximum MTU value that is
segments. supported by all segments.
5. CONCEPTUAL MODEL OF A HOST 5. CONCEPTUAL MODEL OF A HOST
This section describes a conceptual model of one possible data This section describes a conceptual model of one possible data
structure organization that hosts (and to some extent routers) will structure organization that hosts (and to some extent routers) will
maintain in interacting with neighboring nodes. The described maintain in interacting with neighboring nodes. The described
organization is provided to facilitate the explanation of how the organization is provided to facilitate the explanation of how the
Neighbor Discovery protocol should behave. This document does not Neighbor Discovery protocol should behave. This document does not
mandate that implementations adhere to this model as long as their mandate that implementations adhere to this model as long as their
external behavior is consistent with that described in this document. external behavior is consistent with that described in this document.
skipping to change at page 38, line 40 skipping to change at page 38, line 40
AdvManagedFlag AdvManagedFlag
The TRUE/FALSE value to be placed in the "Managed The TRUE/FALSE value to be placed in the "Managed
address configuration" flag field in the Router address configuration" flag field in the Router
Advertisement. See [ADDRCONF]. Advertisement. See [ADDRCONF].
Default: FALSE Default: FALSE
AdvOtherConfigFlag AdvOtherConfigFlag
The TRUE/FALSE value to be placed in the "Other The TRUE/FALSE value to be placed in the "Other
stateful configuration" flag field in the Router configuration" flag field in the Router
Advertisement. See [ADDRCONF]. Advertisement. See [ADDRCONF].
Default: FALSE Default: FALSE
AdvLinkMTU The value to be placed in MTU options sent by the AdvLinkMTU The value to be placed in MTU options sent by the
router. A value of zero indicates that no MTU router. A value of zero indicates that no MTU
options are sent. options are sent.
Default: 0 Default: 0
skipping to change at page 40, line 5 skipping to change at page 40, line 5
The link-local prefix SHOULD NOT be included in the The link-local prefix SHOULD NOT be included in the
list of advertised prefixes. list of advertised prefixes.
Each prefix has an associated: Each prefix has an associated:
AdvValidLifetime AdvValidLifetime
The value to be placed in the Valid The value to be placed in the Valid
Lifetime in the Prefix Information Lifetime in the Prefix Information
option, in seconds. The designated value option, in seconds. The designated value
of all 1's (0xffffffff) represents of all 1's (0xffffffff) represents
infinity. Implementations MUST allow infinity. Implementations MAY allow
AdvValidLifetime to be specified in two AdvValidLifetime to be specified in two
ways: ways:
- a time that decrements in real time, - a time that decrements in real time,
that is, one that will result in a that is, one that will result in a
Lifetime of zero at the specified Lifetime of zero at the specified
time in the future, or time in the future, or
- a fixed time that stays the same in - a fixed time that stays the same in
consecutive advertisements. consecutive advertisements.
skipping to change at page 40, line 39 skipping to change at page 40, line 39
defines additional information associated with defines additional information associated with
each the prefixes: each the prefixes:
AdvPreferredLifetime AdvPreferredLifetime
The value to be placed in the Preferred The value to be placed in the Preferred
Lifetime in the Prefix Information Lifetime in the Prefix Information
option, in seconds. The designated value option, in seconds. The designated value
of all 1's (0xffffffff) represents of all 1's (0xffffffff) represents
infinity. See [ADDRCONF] for details on infinity. See [ADDRCONF] for details on
how this value is used. Implementations how this value is used. Implementations
MUST allow AdvPreferredLifetime to be MAY allow AdvPreferredLifetime to be
specified in two ways: specified in two ways:
- a time that decrements in real time, - a time that decrements in real time,
that is, one that will result in a that is, one that will result in a
Lifetime of zero at a specified time Lifetime of zero at a specified time
in the future, or in the future, or
- a fixed time that stays the same in - a fixed time that stays the same in
consecutive advertisements. consecutive advertisements.
skipping to change at page 45, line 35 skipping to change at page 45, line 35
address MUST NOT update the router's Neighbor Cache; solicitations address MUST NOT update the router's Neighbor Cache; solicitations
with a proper source address update the Neighbor Cache as follows. If with a proper source address update the Neighbor Cache as follows. If
the router already has a Neighbor Cache entry for the solicitation's the router already has a Neighbor Cache entry for the solicitation's
sender, the solicitation contains a Source Link-Layer Address option, sender, the solicitation contains a Source Link-Layer Address option,
and the received link-layer address differs from that already in the and the received link-layer address differs from that already in the
cache, the link-layer address SHOULD be updated in the appropriate cache, the link-layer address SHOULD be updated in the appropriate
Neighbor Cache entry, and its reachability state MUST also be set to Neighbor Cache entry, and its reachability state MUST also be set to
STALE. If there is no existing Neighbor Cache entry for the STALE. If there is no existing Neighbor Cache entry for the
solicitation's sender, the router creates one, installs the link- solicitation's sender, the router creates one, installs the link-
layer address and sets its reachability state to STALE as specified layer address and sets its reachability state to STALE as specified
in Section 7.3.3. Whether or not a Source Link-Layer Address option in Section 7.3.3. If there is no existing Neighbor Cache entry and no
Source Link-Layer Address option was present in the solicitation, the
router may respond with either a multicast or a unicast router
advertisement. Whether or not a Source Link-Layer Address option
is provided, if a Neighbor Cache entry for the solicitation's sender is provided, if a Neighbor Cache entry for the solicitation's sender
exists (or is created) the entry's IsRouter flag MUST be set to exists (or is created) the entry's IsRouter flag MUST be set to
FALSE. FALSE.
6.2.7. Router Advertisement Consistency 6.2.7. Router Advertisement Consistency
Routers SHOULD inspect valid Router Advertisements sent by other Routers SHOULD inspect valid Router Advertisements sent by other
routers and verify that the routers are advertising consistent routers and verify that the routers are advertising consistent
information on a link. Detected inconsistencies indicate that one or information on a link. Detected inconsistencies indicate that one or
more routers might be misconfigured and SHOULD be logged to system or more routers might be misconfigured and SHOULD be logged to system or
network management. The minimum set of information to check network management. The minimum set of information to check
includes: includes:
- Cur Hop Limit values (except for the unspecified value of zero). - Cur Hop Limit values (except for the unspecified value of zero
other inconsistencies SHOULD be logged to system network
management).
- Values of the M or O flags. - Values of the M or O flags.
- Reachable Time values (except for the unspecified value of zero). - Reachable Time values (except for the unspecified value of zero).
- Retrans Timer values (except for the unspecified value of zero). - Retrans Timer values (except for the unspecified value of zero).
- Values in the MTU options. - Values in the MTU options.
- Preferred and Valid Lifetimes for the same prefix. If - Preferred and Valid Lifetimes for the same prefix. If
AdvPreferredLifetime and/or AdvValidLifetime decrement in real AdvPreferredLifetime and/or AdvValidLifetime decrement in real
time as specified in section 6.2.7 then the comparison of the time as specified in section 6.2.1 then the comparison of the
lifetimes can not compare the content of the fields in the Router lifetimes can not compare the content of the fields in the Router
Advertisement but must instead compare the time at which the Advertisement but must instead compare the time at which the
prefix will become deprecated and invalidated, respectively. Due prefix will become deprecated and invalidated, respectively. Due
to link propagation delays and potentially poorly synchronized to link propagation delays and potentially poorly synchronized
clocks between the routers such comparison SHOULD allow some time clocks between the routers such comparison SHOULD allow some time
skew. skew.
Note that it is not an error for different routers to advertise Note that it is not an error for different routers to advertise
different sets of prefixes. Also, some routers might leave some different sets of prefixes. Also, some routers might leave some
fields as unspecified, i.e., with the value zero, while other routers fields as unspecified, i.e., with the value zero, while other routers
specify values. The logging of errors SHOULD be restricted to specify values. The logging of errors SHOULD be restricted to
conflicting information that causes hosts to switch from one value to conflicting information that causes hosts to switch from one value to
another with each received advertisement. another with each received advertisement.
Any other action on reception of Router Advertisement messages by a Any other action on reception of Router Advertisement messages by a
router is beyond the scope of this document. router is beyond the scope of this document.
6.2.8. Link-local Address Change 6.2.8. Link-local Address Change
The link-local address on a router SHOULD change rarely, if ever. The link-local address on a router should rarely change, if ever.
Nodes receiving Neighbor Discovery messages use the source address to Nodes receiving Neighbor Discovery messages use the source address to
identify the sender. If multiple packets from the same router identify the sender. If multiple packets from the same router
contain different source addresses, nodes will assume they come from contain different source addresses, nodes will assume they come from
different routers, leading to undesirable behavior. For example, a different routers, leading to undesirable behavior. For example, a
node will ignore Redirect messages that are believed to have been node will ignore Redirect messages that are believed to have been
sent by a router other than the current first-hop router. Thus the sent by a router other than the current first-hop router. Thus the
source address used in Router Advertisements sent by a particular source address used in Router Advertisements sent by a particular
router must be identical to the target address in a Redirect message router must be identical to the target address in a Redirect message
when redirecting to that router. when redirecting to that router.
skipping to change at page 48, line 25 skipping to change at page 48, line 29
6.3.3. Interface Initialization 6.3.3. Interface Initialization
The host joins the all-nodes multicast address on all multicast- The host joins the all-nodes multicast address on all multicast-
capable interfaces. capable interfaces.
6.3.4. Processing Received Router Advertisements 6.3.4. Processing Received Router Advertisements
When multiple routers are present, the information advertised When multiple routers are present, the information advertised
collectively by all routers may be a superset of the information collectively by all routers may be a superset of the information
contained in a single Router Advertisement. Moreover, information contained in a single Router Advertisement. Moreover, information
may also be obtained through other dynamic means, such as stateful may also be obtained through other dynamic means like DHCPv6. Hosts
autoconfiguration. Hosts accept the union of all received accept the union of all received information; the receipt of a Router
information; the receipt of a Router Advertisement MUST NOT Advertisement MUST NOT invalidate all information received in a
invalidate all information received in a previous advertisement or previous advertisement or from another source. However, when
from another source. However, when received information for a received information for a specific parameter (e.g., Link MTU) or
specific parameter (e.g., Link MTU) or option (e.g., Lifetime on a option (e.g., Lifetime on a specific Prefix) differs from information
specific Prefix) differs from information received earlier, and the received earlier, and the parameter/option can only have one value,
parameter/option can only have one value, the most recently-received the most recently-received information is considered authoritative.
information is considered authoritative.
Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time
and Retrans Timer) may contain a value denoting unspecified. In such and Retrans Timer) may contain a value denoting unspecified. In such
cases, the parameter should be ignored and the host should continue cases, the parameter should be ignored and the host should continue
using whatever value it is already using. In particular, a host MUST using whatever value it is already using. In particular, a host MUST
NOT interpret the unspecified value as meaning change back to the NOT interpret the unspecified value as meaning change back to the
default value that was in use before the first Router Advertisement default value that was in use before the first Router Advertisement
was received. This rule prevents hosts from continually changing an was received. This rule prevents hosts from continually changing an
internal variable when one router advertises a specific value, but internal variable when one router advertises a specific value, but
other routers advertise the unspecified value. other routers advertise the unspecified value.
skipping to change at page 53, line 10 skipping to change at page 53, line 12
Link-Layer Address option SHOULD be set to the host's link-layer Link-Layer Address option SHOULD be set to the host's link-layer
address, if the IP source address is not the unspecified address. address, if the IP source address is not the unspecified address.
Before a host sends an initial solicitation, it SHOULD delay the Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when
many hosts start up on a link at the same time, such as might happen many hosts start up on a link at the same time, such as might happen
after recovery from a power failure. If a host has already performed after recovery from a power failure. If a host has already performed
a random delay since the interface became (re)enabled (e.g., as part a random delay since the interface became (re)enabled (e.g., as part
of Duplicate Address Detection [ADDRCONF]) there is no need to delay of Duplicate Address Detection [ADDRCONF]) there is no need to delay
again before sending the first Router Solicitation message. In some again before sending the first Router Solicitation message.
cases, the random delay MAY be omitted if necessary. For instance, a
mobile node, using [MIPv6], moving to a new link would need to In some cases, the random delay MAY be omitted if necessary. For
discover such movement as soon as possible to minimize the amount of instance, a mobile node, using [MIPv6], moving to a new link would
packet losses resulting from the change in its topological movement. need to discover such movement as soon as possible to minimize the
Router Solicitations provide a useful tool for movement detection in amount of packet losses resulting from the change in its topological
Mobile IPv6 as they allow mobile nodes to determine movement to new movement. Router Solicitations provide a useful tool for movement
links. Hence, if a mobile node received link layer information detection in Mobile IPv6 as they allow mobile nodes to determine
indicating that movement might have taken place, it MAY send a Router movement to new links. Hence, if a mobile node received link layer
Solicitation immediately, without random delays. The strength of such information indicating that movement might have taken place, it MAY
indications should be assessed by the mobile node's implementation send a Router Solicitation immediately, without random delays. The
and is outside the scope of this specification. strength of such indications should be assessed by the mobile node's
implementation depending on the level of certainty of the link layer
hints and is outside the scope of this specification. Note that using
this mechanism inappropriately (e.g. based on weak or transient
indications) may result in Router Solicitation storms. Furthermore,
simultaneous mobility of a large number of mobile nodes that use this
mechanism can result in a large number of solicitations sent
simultaneously.
Once the host sends a Router Solicitation, and receives a valid Once the host sends a Router Solicitation, and receives a valid
Router Advertisement with a non-zero Router Lifetime, the host MUST Router Advertisement with a non-zero Router Lifetime, the host MUST
desist from sending additional solicitations on that interface, until desist from sending additional solicitations on that interface, until
the next time one of the above events occurs. Moreover, a host the next time one of the above events occurs. Moreover, a host
SHOULD send at least one solicitation in the case where an SHOULD send at least one solicitation in the case where an
advertisement is received prior to having sent a solicitation. advertisement is received prior to having sent a solicitation.
Unsolicited Router Advertisements may be incomplete (see Section Unsolicited Router Advertisements may be incomplete (see Section
6.2.3); solicited advertisements are expected to contain complete 6.2.3); solicited advertisements are expected to contain complete
information. information.
skipping to change at page 56, line 17 skipping to change at page 56, line 26
Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor Cache entry in the INCOMPLETE state and transmitting a
Neighbor Solicitation message targeted at the neighbor. The Neighbor Solicitation message targeted at the neighbor. The
solicitation is sent to the solicited-node multicast address solicitation is sent to the solicited-node multicast address
corresponding to the target address. corresponding to the target address.
If the source address of the packet prompting the solicitation is the If the source address of the packet prompting the solicitation is the
same as one of the addresses assigned to the outgoing interface, that same as one of the addresses assigned to the outgoing interface, that
address SHOULD be placed in the IP Source Address of the outgoing address SHOULD be placed in the IP Source Address of the outgoing
solicitation. Otherwise, any one of the addresses assigned to the solicitation. Otherwise, any one of the addresses assigned to the
interface should be used. Using the prompting packet's source interface should be used. Using the prompting packet's source
address when possible insures that the recipient of the Neighbor address when possible ensures that the recipient of the Neighbor
Solicitation installs in its Neighbor Cache the IP address that is Solicitation installs in its Neighbor Cache the IP address that is
highly likely to be used in subsequent return traffic belonging to highly likely to be used in subsequent return traffic belonging to
the prompting packet's "connection". the prompting packet's "connection".
If the solicitation is being sent to a solicited-node multicast If the solicitation is being sent to a solicited-node multicast
address, the sender MUST include its link-layer address (if it has address, the sender MUST include its link-layer address (if it has
one) as a Source Link-Layer Address option. Otherwise, the sender one) as a Source Link-Layer Address option. Otherwise, the sender
SHOULD include its link-layer address (if it has one) as a Source SHOULD include its link-layer address (if it has one) as a Source
Link-Layer Address option. Including the source link-layer address Link-Layer Address option. Including the source link-layer address
in a multicast solicitation is required to give the target an address in a multicast solicitation is required to give the target an address
skipping to change at page 56, line 46 skipping to change at page 57, line 4
for each neighbor, retain a small queue of packets waiting for for each neighbor, retain a small queue of packets waiting for
address resolution to complete. The queue MUST hold at least one address resolution to complete. The queue MUST hold at least one
packet, and MAY contain more. However, the number of queued packets packet, and MAY contain more. However, the number of queued packets
per neighbor SHOULD be limited to some small value. When a queue per neighbor SHOULD be limited to some small value. When a queue
overflows, the new arrival SHOULD replace the oldest entry. Once overflows, the new arrival SHOULD replace the oldest entry. Once
address resolution completes, the node transmits any queued packets. address resolution completes, the node transmits any queued packets.
While awaiting a response, the sender SHOULD retransmit Neighbor While awaiting a response, the sender SHOULD retransmit Neighbor
Solicitation messages approximately every RetransTimer milliseconds, Solicitation messages approximately every RetransTimer milliseconds,
even in the absence of additional traffic to the neighbor. even in the absence of additional traffic to the neighbor.
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 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 address for which the node is - The Target Address is a unicast or anycast address for which the
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].
If the Target Address is tentative, the Neighbor Solicitation should If the Target Address is tentative, the Neighbor Solicitation should
be processed as described in [ADDRCONF]. Otherwise, the following be processed as described in [ADDRCONF]. Otherwise, the following
description applies. If the Source Address is not the unspecified description applies. If the Source Address is not the unspecified
address and, on link layers that have addresses, the solicitation address and, on link layers that have addresses, the solicitation
includes a Source Link-Layer Address option, then the recipient includes a Source Link-Layer Address option, then the recipient
SHOULD create or update the Neighbor Cache entry for the IP Source SHOULD create or update the Neighbor Cache entry for the IP Source
skipping to change at page 58, line 33 skipping to change at page 58, line 43
If the Target Address is an anycast address the sender SHOULD delay If the Target Address is an anycast address the sender SHOULD delay
sending a response for a random time between 0 and sending a response for a random time between 0 and
MAX_ANYCAST_DELAY_TIME seconds. MAX_ANYCAST_DELAY_TIME seconds.
Because unicast Neighbor Solicitations are not required to include a Because unicast Neighbor Solicitations are not required to include a
Source Link-Layer Address, it is possible that a node sending a Source Link-Layer Address, it is possible that a node sending a
solicited Neighbor Advertisement does not have a corresponding link- solicited Neighbor Advertisement does not have a corresponding link-
layer address for its neighbor in its Neighbor Cache. In such layer address for its neighbor in its Neighbor Cache. In such
situations, a node will first have to use Neighbor Discovery to situations, a node will first have to use Neighbor Discovery to
determine the link-layer address of its neighbor (i.e, send out a determine the link-layer address of its neighbor (i.e., send out a
multicast Neighbor Solicitation). multicast Neighbor Solicitation).
7.2.5. Receipt of Neighbor Advertisements 7.2.5. Receipt of Neighbor Advertisements
When a valid Neighbor Advertisement is received (either solicited or When a valid Neighbor Advertisement is received (either solicited or
unsolicited), the Neighbor Cache is searched for the target's entry. unsolicited), the Neighbor Cache is searched for the target's entry.
If no entry exists, the advertisement SHOULD be silently discarded. If no entry exists, the advertisement SHOULD be silently discarded.
There is no need to create an entry if none exists, since the There is no need to create an entry if none exists, since the
recipient has apparently not initiated any communication with the recipient has apparently not initiated any communication with the
target. target.
skipping to change at page 59, line 6 skipping to change at page 59, line 14
specific actions taken depend on the state of the Neighbor Cache specific actions taken depend on the state of the Neighbor Cache
entry, the flags in the advertisement and the actual link-layer entry, the flags in the advertisement and the actual link-layer
address supplied. address supplied.
In any state, if the link layer has addresses and an unsolicited In any state, if the link layer has addresses and an unsolicited
Neighbor Advertisement is received with the O flag cleared, with no Neighbor Advertisement is received with the O flag cleared, with no
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 happens. the advertisement is received, one of two things happen: If the
Otherwise, the receiving node performs the following advertisement were solicited, the state is changed to REACHABLE.
steps: Otherwise, the state is set to STALE. Note that the Override flag is
ignored if the entry is in the
INCOMPLETE state.
If the Neighbor Cache entry is not in INCOMPLETE state, the receiving
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.
- It sends any packets queued for the neighbor awaiting address - It sends any packets queued for the neighbor awaiting address
resolution. resolution.
Note that the Override flag is ignored if the entry is in the
INCOMPLETE state.
If the target's Neighbor Cache entry is in any state other than If the target's Neighbor Cache entry is in any state other than
INCOMPLETE when the advertisement is received, processing becomes INCOMPLETE when the advertisement is received, the following actions
quite a bit more complex. If the Override flag is clear and the take place:
supplied link-layer address differs from that in the cache, then one
of two actions takes place: if the state of the entry is REACHABLE, I. If the Override flag is clear and the supplied link-layer address
set it to STALE, but do not update the entry in any other way; differs from that in the cache, then one of two actions takes
otherwise, the received advertisement should be ignored and MUST NOT place:
update the cache. If the Override flag is set, both the Override a. If the state of the entry is REACHABLE, set it to STALE, but
flag is clear and the supplied link-layer address is the same as that do not update the entry in any other way.
in the cache, or no Target Link-layer address option was supplied, b. Otherwise, the received advertisement should be ignored and MUST
NOT update the cache.
II. If the Override flag is set, or, both the Override flag is clear
and the supplied link-layer address is the same as that in 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 as
follows: 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
skipping to change at page 61, line 9 skipping to change at page 61, line 24
such a case the node SHOULD introduce a small delay between the such a case the node SHOULD introduce a small delay between the
sending of each advertisement to reduce the probability of the sending of each advertisement to reduce the probability of the
advertisements being lost due to congestion. advertisements being lost due to congestion.
A proxy MAY multicast Neighbor Advertisements when its link-layer A proxy MAY multicast Neighbor Advertisements when its link-layer
address changes or when it is configured (by system management or address changes or when it is configured (by system management or
other mechanisms) to proxy for an address. If there are multiple other mechanisms) to proxy for an address. If there are multiple
nodes that are providing proxy services for the same set of addresses nodes that are providing proxy services for the same set of addresses
the proxies SHOULD provide a mechanism that prevents multiple proxies the proxies SHOULD provide a mechanism that prevents multiple proxies
from multicasting advertisements for any one address, in order to from multicasting advertisements for any one address, in order to
reduce the risk of excessive multicast traffic. reduce the risk of excessive multicast traffic. This is a requirement
on other protocols that need to use proxies for Neighbor
Advertisements. An example of a node that performs proxy
advertisements is the Home Agent specified in [MIPv6].
Also, a node belonging to an anycast address MAY multicast Also, a node belonging to an anycast address MAY multicast
unsolicited Neighbor Advertisements for the anycast address when the unsolicited Neighbor Advertisements for the anycast address when the
node's link-layer address changes. node's link-layer address changes.
Note that because unsolicited Neighbor Advertisements do not reliably Note that because unsolicited Neighbor Advertisements do not reliably
update caches in all nodes (the advertisements might not be received update caches in all nodes (the advertisements might not be received
by all nodes), they should only be viewed as a performance by all nodes), they should only be viewed as a performance
optimization to quickly update the caches in most neighbors. The optimization to quickly update the caches in most neighbors. The
Neighbor Unreachability Detection algorithm ensures that all nodes Neighbor Unreachability Detection algorithm ensures that all nodes
skipping to change at page 68, line 18 skipping to change at page 68, line 36
8.2. Router Specification 8.2. Router Specification
A router SHOULD send a redirect message, subject to rate limiting, A router SHOULD send a redirect message, subject to rate limiting,
whenever it forwards a packet that is not explicitly addressed to whenever it forwards a packet that is not explicitly addressed to
itself (i.e. a packet that is not source routed through the router) itself (i.e. a packet that is not source routed through the router)
in which: in which:
- 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 that a better first-hop node resides on - the router determines (by means outside the scope of this
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, and
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
skipping to change at page 73, line 18 skipping to change at page 73, line 36
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. It is natural to trust the routers
on the link. If a host has been redirected to another node (i.e., on the link. If a host has been redirected to another node (i.e.,
the destination is on-link) there is no way to prevent the target the destination is on-link) there is no way to prevent the target
from issuing another redirect to some other destination. However, from issuing another redirect to some other destination. However,
this exposure is no worse than it was; the target host, once this exposure is no worse than it was before being redirected; the
subverted, could always act as a hidden router to forward traffic target host, once subverted, could always act as a hidden router to
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
attacks such as continuously occupying the link in CSMA/CD networks attacks such as continuously occupying the link in CSMA/CD networks
(e.g., by sending packets closely back-to-back or asserting the (e.g., by sending packets closely back-to-back or asserting the
collision signal on the link), or originating packets with somebody collision signal on the link), or originating packets with somebody
else's source MAC address to confuse, e.g., Ethernet switches. On the else's source MAC address to confuse, e.g., Ethernet switches. On the
other hand, many of the threats discussed in this section are less other hand, many of the threats discussed in this section are less
effective, or non-existent, on point-to-point links, or cellular effective, or non-existent, on point-to-point links, or cellular
links where hosts share links with one neighbor, i.e. the default links where a host shares a link with only one neighbor, i.e. the
router. default router.
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.
skipping to change at page 75, line 44 skipping to change at page 76, line 11
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.
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 2373, July 1998. 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.
[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.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Listener Discovery for IPv6", RFC 2710, October 1999. 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-02, June Autoconfiguration", draft-ietf-ipv6-rfc2462bis-07, Dec
2004. 2004.
[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
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 [DHCPv6lite] Droms, R., "Stateless Dynamic Host Configuration
Protocol (DHCP)for IPv6", RFC 3736, April 2004. 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",
skipping to change at page 77, line 6 skipping to change at page 77, line 28
[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] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
[IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security [IPv6-ESP] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[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
Listener Discovery for IPv6", RFC 2710, October 1999.
[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.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[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.
[ASSIGNED] Reynolds, J. and J. Postel, "ASSIGNED NUMBERS", STD 2,
RFC 1700, October 1994. See also:
http://www.iana.org/numbers.html
[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)",
draft-ietf-send-ndopt-04 (work in progress), draft-ietf-send-ndopt-04 (work in progress),
February 2004. 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
This document does not require any new ICMPv6 types or codes to be
allocated. However, existing ICMPv6 types should be updated to point
to the document instead of RFC 2461. Assignment of ICMPv6 types/codes
is described in Section 7 of RFC 2780.
Authors' Addresses Authors' Addresses
Thomas Narten Thomas Narten
IBM Corporation IBM Corporation
P.O. Box 12195 P.O. Box 12195
Research Triangle Park, NC 27709-2195 Research Triangle Park, NC 27709-2195
USA USA
Phone: +1 919 254 7798 Phone: +1 919 254 7798
EMail: narten@raleigh.ibm.com EMail: narten@raleigh.ibm.com
skipping to change at page 84, line 44 skipping to change at page 85, line 15
causing, none of the acknowledgement packets to reach the sender. causing, none of the acknowledgement packets to reach the sender.
APPENDIX F: CHANGES FROM RFC 2461 APPENDIX F: CHANGES FROM RFC 2461
o Removed all references to IPsec AH and ESP for securing messages o Removed all references to IPsec AH and ESP for securing messages
or as part of validating the received message. or as part of validating the received message.
o Added section 3.3. o Added section 3.3.
o Updated section 11 to include more detailed discussion on threats, o Updated section 11 to include more detailed discussion on threats,
IPsec limitations, and use of SEND. IPsec limitations, and use of SeND.
o Removed the on-link assumption in section 5.2 o Removed the on-link assumption in section 5.2 based on
draft-ietf-v6ops-onlinkassumption
o Clarified the definition of the Router Lifetime field in section o Clarified the definition of the Router Lifetime field in section
4.2. 4.2.
o Updated the text in section 4.6.2 and 6.2.1 to indicate that the o Updated the text in section 4.6.2 and 6.2.1 to indicate that the
preferred lifetime must not be larger than valid lifetime. preferred lifetime must not be larger than valid lifetime.
o Updated the reference to stateful configuration and added o Removed the reference to stateful configuration and added
reference for DHCPv6. reference for DHCPv6 instead.
o Added the IsRouter flag definition to section 6.2.1 to allow for o Added the IsRouter flag definition to section 6.2.1 to allow for
mixed host/router behavior. mixed host/router behavior.
o Allowed mobile nodes to be exempt from adding random delays before o Allowed mobile nodes to be exempt from adding random delays before
sending an RS during a handover. sending an RS during a handover.
o Updated the definition of the prefix length in the prefix option o Updated the definition of the prefix length in the prefix option
o Updated the applicability to NBMA links in the introduction and o Updated the applicability to NBMA links in the introduction and
added references to 3GPP RFCs. added references to 3GPP RFCs.
o Clarified support for Load balancing is limited to routers.
o Clarified router behaviour when receiving a Router Solicitation
without SLLAO.
o Clarified that inconsistency checks for CurHopLimit are done for
none zero values only.
o Rearranged section 7.2.5 for clarity and described the processing
when receiving the NA in INCOMPLETE state.
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 85, line 43 skipping to change at page 86, line 29
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at ietf-
ipr@ietf.org. ipr@ietf.org.
Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject Copyright (C) The Internet Society (2004). 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 April, 2005. This Internet-Draft expires August, 2005.
 End of changes. 

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