draft-ietf-ipv6-2461bis-09.txt   draft-ietf-ipv6-2461bis-10.txt 
INTERNET-DRAFT T. Narten, INTERNET-DRAFT T. Narten,
Expires: April 2007 IBM Expires: June 2007 IBM
Obsoletes: 2461 (if approved) E. Nordmark, Obsoletes: 2461 (if approved) E. Nordmark,
Sun Microsystems Sun Microsystems
W. Simpson, W. Simpson,
Daydreamer Daydreamer
H. Soliman, H. Soliman,
Flarion Elevate Technologies
October, 2006 January, 2007
Neighbor Discovery for IP version 6 (IPv6) Neighbor Discovery for IP version 6 (IPv6)
<draft-ietf-ipv6-2461bis-09.txt> <draft-ietf-ipv6-2461bis-10.txt>
Status of this memo Status of this memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
skipping to change at page 1, line 40 skipping to change at page 1, line 40
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2007).
Abstract Abstract
This document specifies the Neighbor Discovery protocol for IP This document specifies the Neighbor Discovery protocol for IP
Version 6. IPv6 nodes on the same link use Neighbor Discovery to Version 6. IPv6 nodes on the same link use Neighbor Discovery to
discover each other's presence, to determine each other's link-layer discover each other's presence, to determine each other's link-layer
addresses, to find routers and to maintain reachability information addresses, to find routers and to maintain reachability information
about the paths to active neighbors. about the paths to active neighbors.
Table of Contents Table of Contents
1. INTRODUCTION....................................................4 1. INTRODUCTION....................................................3
2. TERMINOLOGY.....................................................4 2. TERMINOLOGY.....................................................4
2.1. General...................................................4 2.1. General....................................................4
2.2. Link Types................................................8 2.2. Link Types.................................................7
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
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.1. Source/Target Link-layer Address.....................26
4.6.3. Redirected Header..................................29 4.6.2. Prefix Information...................................27
4.6.4. MTU................................................30 4.6.3. Redirected Header....................................29
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..............35 5.3. Garbage Collection and Timeout Requirements...............34
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........37 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..............42 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............44 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..................46 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.......54 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.............55 7.1.2. Validation of Neighbor Advertisements................55
7.2. Address Resolution.......................................55 7.2. Address Resolution........................................55
7.2.1. Interface Initialization..........................56 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................59 7.2.5. Receipt of Neighbor Advertisements...................59
7.2.6. Sending Unsolicited Neighbor Advertisements.......61 7.2.6. Sending Unsolicited Neighbor Advertisements..........61
7.2.7. Anycast Neighbor Advertisements...................62 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........................63 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............................................72 10. PROTOCOL CONSTANTS............................................72
11. SECURITY CONSIDERATIONS.......................................73 11. SECURITY CONSIDERATIONS.......................................73
11.1 Threat analysis...........................................73 11.1 Threat analysis............................................73
11.2 Securing Neighbor Discovery messages......................74 11.2 Securing Neighbor Discovery messages.......................74
12. RENUMBERING CONSIDERATIONS....................................75 12. RENUMBERING CONSIDERATIONS....................................75
IANA CONSIDERATIONS................................................76
REFERENCES.........................................................76 REFERENCES.........................................................77
Authors' Addresses.................................................79 Authors' Addresses.................................................79
APPENDIX A: MULTIHOMED HOSTS.......................................80 APPENDIX A: MULTIHOMED HOSTS.......................................80
APPENDIX B: FUTURE EXTENSIONS......................................81 APPENDIX B: FUTURE EXTENSIONS......................................81
APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE...............82
APPENDIX D: SUMMARY OF ISROUTER RULES..............................84 APPENDIX D: SUMMARY OF ISROUTER RULES..............................84
APPENDIX E: IMPLEMENTATION ISSUES..................................85 APPENDIX E: IMPLEMENTATION ISSUES..................................85
Appendix E.1: Reachability confirmations...........................85
APPENDIX F: CHANGES FROM RFC 2461..................................86 APPENDIX F: CHANGES FROM RFC 2461..................................86
Intellectual Property Statement....................................87
Full Copyright Statement...........................................88
Disclaimer of Validity.............................................88
1. INTRODUCTION 1. INTRODUCTION
This specification defines the Neighbor Discovery (ND) protocol for This specification defines the Neighbor Discovery (ND) protocol for
Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use
Neighbor Discovery to determine the link-layer addresses for Neighbor Discovery to determine the link-layer addresses for
neighbors known to reside on attached links and to quickly purge neighbors known to reside on attached links and to quickly purge
cached values that become invalid. Hosts also use Neighbor Discovery cached values that become invalid. Hosts also use Neighbor Discovery
to find neighboring routers that are willing to forward packets on to find neighboring routers that are willing to forward packets on
their behalf. Finally, nodes use the protocol to actively keep track their behalf. Finally, nodes use the protocol to actively keep track
skipping to change at page 4, line 33 skipping to change at page 4, line 20
be specified (in the appropriate document covering the operation of be specified (in the appropriate document covering the operation of
IP over a particular link type). The services described in this IP over a particular link type). The services described in this
document that are not directly dependent on multicast, such as document that are not directly dependent on multicast, such as
Redirects, Next-hop determination, Neighbor Unreachability Detection, Redirects, Next-hop determination, Neighbor Unreachability Detection,
etc., are expected to be provided as specified in this document. The etc., are expected to be provided as specified in this document. The
details of how one uses ND on NBMA links are addressed in [IPv6- details of how one uses ND on NBMA links are addressed in [IPv6-
NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of NBMA]. In addition, [IPv6-3GPP] and [IPv6-CELL] discuss the use of
this protocol over some cellular links, which are examples of NBMA this protocol over some cellular links, which are examples of NBMA
links. links.
The authors would like to acknowledge the contributions of the IPv6 The authors of RFC 2461 would like to acknowledge the contributions
working group and, in particular, (in alphabetical order) Ran of the IPv6 working group and, in particular, (in alphabetical order)
Atkinson, Jim Bound, Scott Bradner, Alex Conta, Elwyn Davies, Stephen Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering,
Deering Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert
Robert Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins,
Perkins, Matt Thomas, and Susan Thomson. Matt Thomas, and Susan Thomson.
The editor of this document (Hesham Soliman) would like to thank the
ipv6 working group for the numerous contributions to this revision,
in particular, (in alphabetical order), Greg Daley, Elwyn Davies,
Ralph Droms, Brian Haberman, Bob Hinden, Tatuya Jinmei, Pekka Savola,
Fred Templin and Christian Vogt.
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 Control Message Protocol for the Internet
Protocol Version 6. The terms ICMPv4 and ICMPv6 are Protocol Version 6. The terms ICMPv4 and ICMPv6 are
used only in contexts where necessary to avoid used only in contexts where necessary to avoid
ambiguity. ambiguity.
node - a device that implements IP. node - a device that implements IP.
router - a node that forwards IP packets not explicitly router - a node that forwards IP packets not explicitly
addressed to itself. addressed to itself.
host - any node that is not a router. host - any node that is not a router.
upper layer - a protocol layer immediately above IP. Examples are upper layer - a protocol layer immediately above IP. Examples are
transport protocols such as TCP and UDP, control transport protocols such as TCP and UDP, control
protocols such as ICMP, routing protocols such as OSPF, protocols such as ICMP, routing protocols such as OSPF,
and internet or lower-layer protocols being "tunneled" and internet or lower-layer protocols being "tunneled"
over (i.e., encapsulated in) IP such as IPX, AppleTalk, over (i.e., encapsulated in) IP such as IPX, AppleTalk,
or IP itself. or IP itself.
link - a communication facility or medium over which nodes can link - a communication facility or medium over which nodes can
communicate at the link layer, i.e., the layer communicate at the link-layer, i.e., the layer
immediately below IP. Examples are Ethernets (simple immediately below IP. Examples are Ethernets (simple
or bridged), PPP links, X.25, Frame Relay, or ATM or bridged), PPP links, X.25, Frame Relay, or ATM
networks as well as internet (or higher) layer networks as well as internet (or higher) layer
"tunnels", such as tunnels over IPv4 or IPv6 itself. "tunnels", such as tunnels over IPv4 or IPv6 itself.
interface - a node's attachment to a link. interface - a node's attachment to a link.
neighbors - nodes attached to the same link. neighbors - nodes attached to the same link.
address - an IP-layer identifier for an interface or a set of address - an IP-layer identifier for an interface or a set of
skipping to change at page 6, line 9 skipping to change at page 5, line 50
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. include IEEE 802 addresses for Ethernet 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 (e.g.
as indicated by the on-link flag in the Prefix
Information option), 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
- a Neighbor Advertisement message is received for - a Neighbor Advertisement message is received for
the (target) address, or the (target) address, or
- any Neighbor Discovery message is received from - any Neighbor Discovery message is received from
the address. the address.
skipping to change at page 6, line 48 skipping to change at page 6, line 40
sent by a node's IP layer are delivered to the sent by a node's IP layer are delivered to the
router's IP layer, and the router is indeed router's IP layer, and the router is indeed
forwarding packets (i.e., it is configured as a forwarding packets (i.e., it is configured as a
router, not a host). For hosts, reachability means router, not a host). For hosts, reachability means
that packets sent by a node's IP layer are delivered that packets sent by a node's IP layer are delivered
to the neighbor host's IP layer. to the neighbor host's IP layer.
packet - an IP header plus payload. packet - an IP header plus payload.
link MTU - the maximum transmission unit, i.e., maximum packet link MTU - the maximum transmission unit, i.e., maximum packet
size in octets, that can be conveyed in one piece size in octets, that can be conveyed in one
over a link. transmission unit over a link.
target - an address about which address resolution target - an address about which address resolution
information is sought, or an address which is the information is sought, or an address which is the
new first-hop when being redirected. new first-hop when being redirected.
proxy - a router that responds to Neighbor Discovery query proxy - a node that responds to Neighbor Discovery query
messages on behalf of another node. A router acting messages on behalf of another node. A router acting
on behalf of a mobile node that has moved off-link on behalf of a mobile node that has moved off-link
could potentially act as a proxy for the mobile could potentially act as a proxy for the mobile
node. node.
ICMP destination unreachable indication ICMP destination unreachable indication
- an error indication returned to the original sender - an error indication returned to the original sender
of a packet that cannot be delivered for the reasons of a packet that cannot be delivered for the reasons
outlined in [ICMPv6]. If the error occurs on a node outlined in [ICMPv6]. If the error occurs on a node
other than the node originating the packet, an ICMP other than the node originating the packet, an ICMP
skipping to change at page 7, line 47 skipping to change at page 7, line 40
insure that the granularity of the calculated random insure that the granularity of the calculated random
component and the resolution of the timer used are both component and the resolution of the timer used are both
high enough to insure that the probability of multiple high enough to insure that the probability of multiple
nodes delaying the same amount of time is small. nodes delaying the same amount of time is small.
random delay seed random delay seed
- If a pseudo-random number generator is used in - If a pseudo-random number generator is used in
calculating a random delay component, the generator calculating a random delay component, the generator
should be initialized with a unique seed prior to being should be initialized with a unique seed prior to being
used. Note that it is not sufficient to use the used. Note that it is not sufficient to use the
interface token alone as the seed, since interface interface identifier alone as the seed, since interface
tokens will not always be unique. To reduce the identifiers will not always be unique. To reduce the
probability that duplicate interface tokens cause the probability that duplicate interface identifiers cause
same seed to be used, the seed should be calculated the same seed to be used, the seed should be calculated
from a variety of input sources (e.g., machine from a variety of input sources (e.g., machine
components) that are likely to be different even on components) that are likely to be different even on
identical "boxes". For example, the seed could be identical "boxes". For example, the seed could be
formed by combining the CPU's serial number with an formed by combining the CPU's serial number with an
interface token. interface identifier. Additional information on
randomness and random number generation can be found in
[RAND].
2.2. Link Types 2.2. Link Types
Different link layers have different properties. The ones of concern Different link-layers have different properties. The ones of concern
to Neighbor Discovery are: to Neighbor Discovery are:
multicast capable multicast capable
- a link that supports a native mechanism at the - a link that supports a native mechanism at the
link layer for sending packets to all (i.e., link-layer for sending packets to all (i.e.,
broadcast) or a subset of all neighbors. broadcast) or a subset of all neighbors.
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.).
skipping to change at page 8, line 47 skipping to change at page 8, line 42
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-
MEDIA]. MEDIA].
variable MTU - a link that does not have a well-defined MTU (e.g., variable MTU - a link that does not have a well-defined MTU (e.g.,
IEEE 802.5 token rings). Many links (e.g., IEEE 802.5 token rings). Many links (e.g.,
Ethernet) have a standard MTU defined by the link- Ethernet) have a standard MTU defined by the link-
layer protocol or by the specific document layer protocol or by the specific document
describing how to run IP over the link layer. describing how to run IP over the link-layer.
asymmetric reachability asymmetric reachability
- a link where non-reflexive and/or non-transitive - a link where non-reflexive and/or non-transitive
reachability is part of normal operation. (Non- reachability is part of normal operation. (Non-
reflexive reachability means packets from A reach B reflexive reachability means packets from A reach B
but packets from B don't reach A. Non-transitive but packets from B don't reach A. Non-transitive
reachability means packets from A reach B, and reachability means packets from A reach B, and
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.
skipping to change at page 9, line 29 skipping to change at page 9, line 26
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
most significant bits, e.g., due to multiple most significant bits, e.g., due to multiple
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 at the
link-layer.
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 stateless address autoconfiguration [ADDRCONF]).
unspecified address has a value of 0:0:0:0:0:0:0:0. The 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 in [ADDR-SEL] for the scopes of source and consistency requirements in [ADDR-SEL] for the scopes of source and
destination addresses. It is possible in some cases for hosts to use destination addresses. It is possible in some cases for hosts to use
a source address of a larger scope than the destination address in a source address of a larger scope than the destination address in
the IPv6 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 10, line 40 skipping to change at page 10, line 34
that define which destinations are on-link for an that define which destinations are on-link for an
attached link. (Nodes use prefixes to distinguish attached link. (Nodes use prefixes to distinguish
destinations that reside on-link from those only destinations that reside on-link from those only
reachable through a router.) reachable through a router.)
Parameter Discovery: How a node learns such link parameters as the Parameter Discovery: How a node learns such link parameters as the
link MTU or such Internet parameters as the hop limit link MTU or such Internet parameters as the hop limit
value to place in outgoing packets. value to place in outgoing packets.
Address Autoconfiguration: Introduces the mechanisms needed in Address Autoconfiguration: Introduces the mechanisms needed in
order to allow nodes to automatically configure an order to allow nodes to configure an address for an
address for an interface. interface in a stateless manner. Stateless address
autoconfiguration is specified in [ADDRCONF].
Address resolution: How nodes determine the link-layer address of Address resolution: How nodes determine the link-layer address of
an on-link destination (e.g., a neighbor) given only the an on-link destination (e.g., a neighbor) given only the
destination's IP address. destination's IP address.
Next-hop determination: The algorithm for mapping an IP destination Next-hop determination: The algorithm for mapping an IP destination
address into the IP address of the neighbor to which address into the IP address of the neighbor to which
traffic for the destination should be sent. The next- traffic for the destination should be sent. The next-
hop can be a router or the destination itself. hop can be a router or the destination itself.
Neighbor Unreachability Detection: How nodes determine that a Neighbor Unreachability Detection: How nodes determine that a
neighbor is no longer reachable. For neighbors used as neighbor is no longer reachable. For neighbors used as
routers, alternate default routers can be tried. For routers, alternate default routers can be tried. For
both routers and hosts, address resolution can be both routers and hosts, address resolution can be
performed again. performed again.
Duplicate Address Detection: How a node determines that an address Duplicate Address Detection: How a node determines whether or not
it wishes to use is not already in use by another node. an address it wishes to use is already in use by
another node.
Redirect: How a router informs a host of a better first-hop node Redirect: How a router informs a host of a better first-hop node
to reach a particular destination. to reach a particular destination.
Neighbor Discovery defines five different ICMP packet types: A pair Neighbor Discovery defines five different ICMP packet types: A pair
of Router Solicitation and Router Advertisement messages, a pair of of Router Solicitation and Router Advertisement messages, a pair of
Neighbor Solicitation and Neighbor Advertisements messages, and a Neighbor Solicitation and Neighbor Advertisements messages, and a
Redirect message. The messages serve the following purpose: Redirect message. The messages serve the following purpose:
Router Solicitation: When an interface becomes enabled, hosts may Router Solicitation: When an interface becomes enabled, hosts may
send out Router Solicitations that request routers to send out Router Solicitations that request routers to
generate Router Advertisements immediately rather than generate Router Advertisements immediately rather than
at their next scheduled time. at their next scheduled time.
Router Advertisement: Routers advertise their presence together Router Advertisement: Routers advertise their presence together
with various link and Internet parameters either with various link and Internet parameters either
periodically, or in response to a Router Solicitation periodically, or in response to a Router Solicitation
message. Router Advertisements contain prefixes that message. Router Advertisements contain prefixes that
are used for on-link determination and/or address are used for determining whether an another address
configuration, a suggested hop limit value, etc. shares the same link (on-link determination) and/or
address configuration, a suggested hop limit value, etc.
Neighbor Solicitation: Sent by a node to determine the link-layer Neighbor Solicitation: Sent by a node to determine the link-layer
address of a neighbor, or to verify that a neighbor is address of a neighbor, or to verify that a neighbor is
still reachable via a cached link-layer address. still reachable via a cached link-layer address.
Neighbor Solicitations are also used for Duplicate Neighbor Solicitations are also used for Duplicate
Address Detection. Address Detection.
Neighbor Advertisement: A response to a Neighbor Solicitation Neighbor Advertisement: A response to a Neighbor Solicitation
message. A node may also send unsolicited Neighbor message. A node may also send unsolicited Neighbor
Advertisements to announce a link-layer address change. Advertisements to announce a link-layer address change.
skipping to change at page 13, line 29 skipping to change at page 13, line 25
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.
Neighbor Discovery allows a router to perform Load balancing Neighbor Discovery allows a router to perform Load balancing
for traffic addressed to itself by allowing routers to omit for traffic addressed to itself by allowing routers to omit
the source link-layer address from Router Advertisement the source link-layer address from Router Advertisement
packets, thereby forcing neighbors to use Neighbor packets, thereby forcing neighbors to use Neighbor
Solicitation messages to learn link-layer addresses of Solicitation messages to learn link-layer addresses of
routers. Returned Neighbor Advertisement messages can then routers. Returned Neighbor Advertisement messages can then
contain link-layer addresses that differ depending on who contain link-layer addresses that differ depending on, e.g.,
issued the solicitation. This specification does not support who issued the solicitation. This specification does not
a mechanism that allows host to Load balance incoming support a mechanism that allows hosts to Load-balance
packets. 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. A non-Override
specific rules to determine which of potentially multiple advertisement is one that does not replace the information
advertisements should be used. sent by another advertisement. These advertisements are
discussed later in the context of Neighbor advertisement
messages. This invokes specific rules to determine which of
potentially multiple advertisements should be used.
Proxy advertisements - A router willing to accept packets on behalf Proxy advertisements - A node willing to accept packets on behalf
of a target address that is unable to respond to Neighbor of a target address that is unable to respond to Neighbor
Solicitations can issue non-Override Neighbor Advertisements. Solicitations can issue non-Override Neighbor Advertisements.
Proxy advertisements are used by Mobile IPv6 home Agents to Proxy advertisements are used by Mobile IPv6 home Agents to
defend mobile nodes' addresses when they move off-link. defend mobile nodes' addresses when they move off-link.
However, it is not intended as a general mechanism to handle However, it is not intended as a general mechanism to handle
nodes that, e.g., do not implement this protocol. nodes that, e.g., do not implement this protocol.
3.1. Comparison with IPv4 3.1. Comparison with IPv4
The IPv6 Neighbor Discovery protocol corresponds to a combination of The IPv6 Neighbor Discovery protocol corresponds to a combination of
skipping to change at page 15, line 5 skipping to change at page 14, line 54
Unlike IPv4, the recipient of an IPv6 redirect assumes that the Unlike IPv4, the recipient of an IPv6 redirect assumes that the
new next-hop is on-link. In IPv4, a host ignores redirects new next-hop is on-link. In IPv4, a host ignores redirects
specifying a next-hop that is not on-link according to the link's specifying a next-hop that is not on-link according to the link's
network mask. The IPv6 redirect mechanism is analogous to the network mask. The IPv6 redirect mechanism is analogous to the
XRedirect facility specified in [SH-MEDIA]. It is expected to be XRedirect facility specified in [SH-MEDIA]. It is expected to be
useful on non-broadcast and shared media links in which it is useful on non-broadcast and shared media links in which it is
undesirable or not possible for nodes to know all prefixes for undesirable or not possible for nodes to know all prefixes for
on-link destinations. on-link destinations.
Neighbor Unreachability Detection is part of the base Neighbor Unreachability Detection is part of the base, which
significantly improving the robustness of packet delivery in the significantly improves the robustness of packet delivery in the
presence of failing routers, partially failing or partitioned presence of failing routers, partially failing or partitioned
links and nodes that change their link-layer addresses. For links and nodes that change their link-layer addresses. For
instance, mobile nodes can move off-link without losing any instance, mobile nodes can move off-link without losing any
connectivity due to stale ARP caches. connectivity due to stale ARP caches.
Unlike ARP, Neighbor Discovery detects half-link failures (using Unlike ARP, Neighbor Discovery detects half-link failures (using
Neighbor Unreachability Detection) and avoids sending traffic to Neighbor Unreachability Detection) and avoids sending traffic to
neighbors with which two-way connectivity is absent. neighbors with which two-way connectivity is absent.
Unlike in IPv4 Router Discovery the Router Advertisement messages Unlike in IPv4 Router Discovery the Router Advertisement messages
skipping to change at page 15, line 45 skipping to change at page 15, line 43
appropriate. 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
can be assigned link-local addresses.) Neighbor can be assigned link-local addresses.)
Discovery should be implemented as described in
this document.
multicast - Neighbor Discovery should be implemented as multicast - Neighbor Discovery supports multicast capable
described in this document. links as described in this document.
non-broadcast multiple access (NBMA) non-broadcast multiple access (NBMA)
- Redirect, Neighbor Unreachability Detection and - Redirect, Neighbor Unreachability Detection and
next-hop determination should be implemented as next-hop determination should be implemented as
described in this document. Address resolution, described in this document. Address resolution,
and the mechanism for delivering Router and the mechanism for delivering Router
Solicitations and Advertisements on NBMA links is Solicitations and Advertisements on NBMA links is
not specified in this document. Note that if not specified in this document. Note that if
hosts support manual configuration of a list of hosts support manual configuration of a list of
default routers, hosts can dynamically acquire the default routers, hosts can dynamically acquire the
link-layer addresses for their neighbors from link-layer addresses for their neighbors from
Redirect messages. Redirect messages.
shared media - The Redirect message is modeled after the shared media - The Redirect message is modeled after the
XRedirect message in [SH-MEDIA] in order to XRedirect message in [SH-MEDIA] in order to
simplify use of the protocol on shared media simplify use of the protocol on shared media
links. links.
skipping to change at page 17, line 13 skipping to change at page 17, line 10
will refrain from using them. will refrain from using them.
The protocol can presumably be extended in the The protocol can presumably be extended in the
future to find viable paths in environments that future to find viable paths in environments that
lack reflexive and transitive connectivity. lack reflexive and transitive connectivity.
3.3. Securing Neighbor Discovery messages 3.3. Securing Neighbor Discovery messages
Neighbor Discovery messages are needed for various functions. Several Neighbor Discovery messages are needed for various functions. Several
functions are designed to allow hosts to ascertain the ownership of functions are designed to allow hosts to ascertain the ownership of
an address or the mapping between link layer and IP layer addresses. an address or the mapping between link-layer and IP layer addresses.
Vulnerabilities related to Neighbor Discovery are discussed in Vulnerabilities related to Neighbor Discovery are discussed in
section 11.1. A general solution for securing Neighbor Discovery is section 11.1. A general solution for securing Neighbor Discovery is
outside the scope of this specification and is discussed in [SEND]. outside the scope of this specification and is discussed in [SEND].
However, Section 11.2 explains how and under which constraints IPsec However, Section 11.2 explains how and under which constraints IPsec
AH or ESP can be used to secure Neighbor Discovery. AH or ESP can be used to secure Neighbor Discovery.
4. MESSAGE FORMATS 4. MESSAGE FORMATS
This section introduces message formats for all messages used in this
specification.
4.1. Router Solicitation Message Format 4.1. Router Solicitation Message Format
Hosts send Router Solicitations in order to prompt routers to Hosts send Router Solicitations in order to prompt routers to
generate Router Advertisements quickly. generate Router Advertisements quickly.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Checksum | | Type | Code | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 18, line 15 skipping to change at page 18, line 15
Reserved This field is unused. It MUST be initialized to Reserved This field is unused. It MUST be initialized to
zero by the sender and MUST be ignored by the zero by the sender and MUST be ignored by the
receiver. receiver.
Valid Options: Valid Options:
Source link-layer address Source link-layer address
The link-layer address of the sender, if known. The link-layer address of the sender, if known.
MUST NOT be included if the Source Address is the MUST NOT be included if the Source Address is the
unspecified address. Otherwise it SHOULD be unspecified address. Otherwise it SHOULD be
included on link layers that have addresses. included on link-layers that have addresses.
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.
4.2. Router Advertisement Message Format 4.2. Router Advertisement Message Format
Routers send out Router Advertisement message periodically, or in Routers send out Router Advertisement message periodically, or in
response to a Router Solicitation. response to a Router Solicitation.
skipping to change at page 20, line 20 skipping to change at page 20, line 19
Solicitation messages. Used by address resolution Solicitation messages. Used by address resolution
and the Neighbor Unreachability Detection algorithm and the Neighbor Unreachability Detection algorithm
(see Sections 7.2 and 7.3). A value of zero means (see Sections 7.2 and 7.3). A value of zero means
unspecified (by this router). unspecified (by this router).
Possible options: Possible options:
Source link-layer address Source link-layer address
The link-layer address of the interface from which The link-layer address of the interface from which
the Router Advertisement is sent. Only used on the Router Advertisement is sent. Only used on
link layers that have addresses. A router MAY omit link-layers that have addresses. A router MAY omit
this option in order to enable inbound load sharing this option in order to enable inbound load sharing
across multiple link-layer addresses. across multiple link-layer addresses.
MTU SHOULD be sent on links that have a variable MTU MTU SHOULD be sent on links that have a variable MTU
(as specified in the document that describes how to (as specified in the document that describes how to
run IP over the particular link type). MAY be sent run IP over the particular link type). MAY be sent
on other links. on other links.
Prefix Information Prefix Information
These options specify the prefixes that are on-link These options specify the prefixes that are on-link
and/or are used for address autoconfiguration. A and/or are used for stateless address
router SHOULD include all its on-link prefixes autoconfiguration. A router SHOULD include all its
(except the link-local prefix) so that multihomed on-link prefixes (except the link-local prefix) so
hosts have complete prefix information about on- that multihomed hosts have complete prefix
link destinations for the links to which they information about on-link destinations for the
attach. If complete information is lacking, a links to which they attach. If complete
multihomed host may not be able to choose the information is lacking, a host with multiple
correct outgoing interface when sending traffic to interfaces may not be able to choose the correct
its neighbors. outgoing interface when sending traffic to its
neighbors.
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.
4.3. Neighbor Solicitation Message Format 4.3. Neighbor Solicitation Message Format
Nodes send Neighbor Solicitations to request the link-layer address Nodes send Neighbor Solicitations to request the link-layer address
of a target node while also providing their own link-layer address to of a target node while also providing their own link-layer address to
the target. Neighbor Solicitations are multicast when the node needs the target. Neighbor Solicitations are multicast when the node needs
skipping to change at page 22, line 10 skipping to change at page 21, line 54
Target Address Target Address
The IP address of the target of the solicitation. The IP address of the target of the solicitation.
It MUST NOT be a multicast address. It MUST NOT be a multicast address.
Possible options: Possible options:
Source link-layer address Source link-layer address
The link-layer address for the sender. MUST NOT be The link-layer address for the sender. MUST NOT be
included when the source IP address is the included when the source IP address is the
unspecified address. Otherwise, on link layers unspecified address. Otherwise, on link-layers
that have addresses this option MUST be included in that have addresses this option MUST be included in
multicast solicitations and SHOULD be included in multicast solicitations and SHOULD be included in
unicast solicitations. unicast solicitations.
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.
4.4. Neighbor Advertisement Message Format 4.4. Neighbor Advertisement Message Format
skipping to change at page 24, line 8 skipping to change at page 23, line 50
prompted this advertisement. For an unsolicited prompted this advertisement. For an unsolicited
advertisement, the address whose link-layer address advertisement, the address whose link-layer address
has changed. The Target Address MUST NOT be a has changed. The Target Address MUST NOT be a
multicast address. multicast address.
Possible options: Possible options:
Target link-layer address Target link-layer address
The link-layer address for the target, i.e., the The link-layer address for the target, i.e., the
sender of the advertisement. This option MUST be sender of the advertisement. This option MUST be
included on link layers that have addresses when included on link-layers that have addresses when
responding to multicast solicitations. When responding to multicast solicitations. When
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
skipping to change at page 27, line 30 skipping to change at page 27, line 20
length fields) in units of 8 octets. For example, length fields) in units of 8 octets. For example,
the length for IEEE 802 addresses is 1 [IPv6- the length for IEEE 802 addresses is 1 [IPv6-
ETHER]. ETHER].
Link-Layer Address Link-Layer Address
The variable length link-layer address. The variable length link-layer address.
The content and format of this field (including The content and format of this field (including
byte and bit ordering) is expected to be specified byte and bit ordering) is expected to be specified
in specific documents that describe how IPv6 in specific documents that describe how IPv6
operates over different link layers. For instance, operates over different link-layers. For instance,
[IPv6-ETHER]. [IPv6-ETHER].
Description Description
The Source Link-Layer Address option contains the The Source Link-Layer Address option contains the
link-layer address of the sender of the packet. It link-layer address of the sender of the packet. It
is used in the Neighbor Solicitation, Router is used in the Neighbor Solicitation, Router
Solicitation, and Router Advertisement packets. Solicitation, and Router Advertisement packets.
The Target Link-Layer Address option contains the The Target Link-Layer Address option contains the
link-layer address of the target. It is used in link-layer address of the target. It is used in
skipping to change at page 28, line 37 skipping to change at page 28, line 26
necessary information for on-link determination necessary information for on-link determination
(when combined with the L flag in the prefix (when combined with the L flag in the prefix
information option). It also assists with address information 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. In
instance, the prefix might be used for address other words, if the L flag is not set a host MUST
configuration with some of the addresses belonging NOT assume that an address derived from the prefix
to the prefix being on-link and others being off- is on-link unless it is explicitly told in another
link. message (e.g. Redirect). For instance, the prefix
might be used for address configuration with some
of the addresses belonging to the prefix being on-
link and others being off-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
stateless 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
skipping to change at page 29, line 35 skipping to change at page 29, line 27
leading bits in the prefix. The bits in the prefix leading bits in the prefix. The bits in the prefix
after the prefix length are reserved and MUST be after the prefix length are reserved and MUST be
initialized to zero by the sender and ignored by initialized to zero by the sender and ignored by
the receiver. A router SHOULD NOT send a prefix the receiver. A router SHOULD NOT send a prefix
option for the link-local prefix and a host SHOULD option for the link-local prefix and a host SHOULD
ignore such a prefix option. ignore such a prefix option.
Description Description
The Prefix Information option provide hosts with The Prefix Information option provide hosts with
on-link prefixes and prefixes for Address on-link prefixes and prefixes for Address
Autoconfiguration. Autoconfiguration. The Prefix Information option
appears in Router Advertisement packets and MUST be
The Prefix Information option appears in Router silently ignored for other messages.
Advertisement packets and MUST be silently ignored
for other messages.
4.6.3. Redirected Header 4.6.3. Redirected Header
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Reserved | | Type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
skipping to change at page 35, line 51 skipping to change at page 35, line 41
caches that have become invalid. When removing an entry from the caches that have become invalid. When removing an entry from the
Default Router List, however, any entries in the Destination Cache Default Router List, however, any entries in the Destination Cache
that go through that router must perform next-hop determination again that go through that router must perform next-hop determination again
to select a new default router. to select a new default router.
6. ROUTER AND PREFIX DISCOVERY 6. ROUTER AND PREFIX DISCOVERY
This section describes router and host behavior related to the Router This section describes router and host behavior related to the Router
Discovery portion of Neighbor Discovery. Router Discovery is used to Discovery portion of Neighbor Discovery. Router Discovery is used to
locate neighboring routers as well as learn prefixes and locate neighboring routers as well as learn prefixes and
configuration parameters related to address autoconfiguration. configuration parameters related to stateless address
autoconfiguration.
Prefix Discovery is the process through which hosts learn the ranges Prefix Discovery is the process through which hosts learn the ranges
of IP addresses that reside on-link and can be reached directly of IP addresses that reside on-link and can be reached directly
without going through a router. Routers send Router Advertisements without going through a router. Routers send Router Advertisements
that indicate whether the sender is willing to be a default router. that indicate whether the sender is willing to be a default router.
Router Advertisements also contain Prefix Information options that Router Advertisements also contain Prefix Information options that
list the set of prefixes that identify on-link IP addresses. list the set of prefixes that identify on-link IP addresses.
Stateless Address Autoconfiguration must also obtain subnet prefixes Stateless Address Autoconfiguration must also obtain subnet prefixes
as part of configuring addresses. Although the prefixes used for as part of configuring addresses. Although the prefixes used for
skipping to change at page 37, line 52 skipping to change at page 37, line 43
A router MUST allow for the following conceptual variables to be A router MUST allow for the following conceptual variables to be
configured by system management. The specific variable names are configured by system management. The specific variable names are
used for demonstration purposes only, and an implementation is not used for demonstration purposes only, and an implementation is not
required to have them, so long as its external behavior is consistent required to have them, so long as its external behavior is consistent
with that described in this document. Default values are specified with that described in this document. Default values are specified
to simplify configuration in common cases. to simplify configuration in common cases.
The default values for some of the variables listed below may be The default values for some of the variables listed below may be
overridden by specific documents that describe how IPv6 operates over overridden by specific documents that describe how IPv6 operates over
different link layers. This rule simplifies the configuration of different link-layers. This rule simplifies the configuration of
Neighbor Discovery over link types with widely differing performance Neighbor Discovery over link types with widely differing performance
characteristics. characteristics.
For each interface: For each interface:
IsRouter A flag indicating whether routing is enabled on IsRouter A flag indicating whether routing is enabled on
this interface. Enabling routing on the interface this interface. Enabling routing on the interface
would imply that a router can forward packets would imply that a router can forward packets
to or from the interface. to or from the interface.
skipping to change at page 38, line 40 skipping to change at page 38, line 29
unsolicited multicast Router Advertisements from unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 4 the interface, in seconds. MUST be no less than 4
seconds and no greater than 1800 seconds. seconds and no greater than 1800 seconds.
Default: 600 seconds Default: 600 seconds
MinRtrAdvInterval MinRtrAdvInterval
The minimum time allowed between sending The minimum time allowed between sending
unsolicited multicast Router Advertisements from unsolicited multicast Router Advertisements from
the interface, in seconds. MUST be no less than 3 the interface, in seconds. MUST be no less than 3
seconds and no greater than .75 *MaxRtrAdvInterval. seconds and no greater than .75 *
MaxRtrAdvInterval.
Default: 0.33 * MaxRtrAdvInterval Default: 0.33 * MaxRtrAdvInterval
If MaxRtrAdvInterval >= 9 seconds, otherwise the
Default is MaxRtrAdvInterval.
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
skipping to change at page 39, line 32 skipping to change at page 39, line 26
AdvRetransTimer The value to be placed in the Retrans Timer field AdvRetransTimer The value to be placed in the Retrans Timer field
in the Router Advertisement messages sent by the in the Router Advertisement messages sent by the
router. The value zero means unspecified (by this router. The value zero means unspecified (by this
router). router).
Default: 0 Default: 0
AdvCurHopLimit AdvCurHopLimit
The default value to be placed in the Cur Hop Limit The default value to be placed in the Cur Hop Limit
field in the Router Advertisement messages sent by field in the Router Advertisement messages sent by
the router. The value should be set to that the router. The value should be set to the
current diameter of the Internet. The value zero current diameter of the Internet. The value zero
means unspecified (by this router). means unspecified (by this router).
Default: The value specified in the "Assigned Default: The value specified in the "Assigned
Numbers" RFC [ASSIGNED] that was in effect at the Numbers" RFC [ASSIGNED] that was in effect at the
time of implementation. time of implementation.
AdvDefaultLifetime AdvDefaultLifetime
The value to be placed in the Router Lifetime field The value to be placed in the Router Lifetime field
of Router Advertisements sent from the interface, of Router Advertisements sent from the interface,
skipping to change at page 40, line 41 skipping to change at page 40, line 35
(i.e., stays the same in consecutive (i.e., stays the same in consecutive
advertisements). advertisements).
AdvOnLinkFlag AdvOnLinkFlag
The value to be placed in the on-link The value to be placed in the on-link
flag ("L-bit") field in the Prefix flag ("L-bit") field in the Prefix
Information option. Information option.
Default: TRUE Default: TRUE
Automatic address configuration [ADDRCONF] Stateless address configuration [ADDRCONF]
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
skipping to change at page 43, line 14 skipping to change at page 43, line 7
AdvValidLifetime. AdvValidLifetime.
- In the "Autonomous address configuration" flag: the - In the "Autonomous address configuration" flag: the
entry's AdvAutonomousFlag. entry's AdvAutonomousFlag.
- In the Preferred Lifetime field: the entry's - In the Preferred Lifetime field: the entry's
AdvPreferredLifetime. AdvPreferredLifetime.
A router might want to send Router Advertisements without advertising A router might want to send Router Advertisements without advertising
itself as a default router. For instance, a router might advertise itself as a default router. For instance, a router might advertise
prefixes for address autoconfiguration while not wishing to forward prefixes for stateless address autoconfiguration while not wishing to
packets. Such a router sets the Router Lifetime field in outgoing forward packets. Such a router sets the Router Lifetime field in
advertisements to zero. outgoing advertisements to zero.
A router MAY choose not to include some or all options when sending A router MAY choose not to include some or all options when sending
unsolicited Router Advertisements. For example, if prefix lifetimes unsolicited Router Advertisements. For example, if prefix lifetimes
are much longer than AdvDefaultLifetime, including them every few are much longer than AdvDefaultLifetime, including them every few
advertisements may be sufficient. However, when responding to a advertisements may be sufficient. However, when responding to a
Router Solicitation or while sending the first few initial Router Solicitation or while sending the first few initial
unsolicited advertisements, a router SHOULD include all options so unsolicited advertisements, a router SHOULD include all options so
that all information (e.g., prefixes) is propagated quickly during that all information (e.g., prefixes) is propagated quickly during
system initialization. system initialization.
skipping to change at page 44, line 29 skipping to change at page 44, line 23
- administratively disabling the interface, or - administratively disabling the interface, or
- shutting down the system. - shutting down the system.
In such cases the router SHOULD transmit one or more (but not more In such cases the router SHOULD transmit one or more (but not more
than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router
Advertisements on the interface with a Router Lifetime field of zero. Advertisements on the interface with a Router Lifetime field of zero.
In the case of a router becoming a host, the system SHOULD also In the case of a router becoming a host, the system SHOULD also
depart from the all-routers IP multicast group on all interfaces on depart from the all-routers IP multicast group on all interfaces on
which the router supports IP multicast (whether or not they had been which the router supports IP multicast (whether or not they had been
advertising interfaces). In addition, the host MUST insure that advertising interfaces). In addition, the host MUST ensure that
subsequent Neighbor Advertisement messages sent from the interface subsequent Neighbor Advertisement messages sent from the interface
have the Router flag set to zero. have the Router flag set to zero.
Note that system management may disable a router's IP forwarding Note that system management may disable a router's IP forwarding
capability (i.e., changing the system from being a router to being a capability (i.e., changing the system from being a router to being a
host), a step that does not necessarily imply that the router's host), a step that does not necessarily imply that the router's
interfaces stop being advertising interfaces. In such cases, interfaces stop being advertising interfaces. In such cases,
subsequent Router Advertisements MUST set the Router Lifetime field subsequent Router Advertisements MUST set the Router Lifetime field
to zero. to zero.
skipping to change at page 47, line 50 skipping to change at page 47, line 43
The default values in this specification may be overridden by The default values in this specification may be overridden by
specific documents that describe how IP operates over different link specific documents that describe how IP operates over different link
layers. This rule allows Neighbor Discovery to operate over links layers. This rule allows Neighbor Discovery to operate over links
with widely varying performance characteristics. with widely varying performance characteristics.
For each interface: For each interface:
LinkMTU The MTU of the link. LinkMTU The MTU of the link.
Default: The valued defined in the specific Default: The valued defined in the specific
document that describes how IPv6 operates over document that describes how IPv6 operates over
the particular link layer (e.g., [IPv6-ETHER]). the particular link-layer (e.g., [IPv6-ETHER]).
CurHopLimit The default hop limit to be used when sending CurHopLimit The default hop limit to be used when sending
(unicast) IP packets. IP packets.
Default: The value specified in the "Assigned Default: The value specified in the "Assigned
Numbers" RFC [ASSIGNED] that was in effect at the Numbers" RFC [ASSIGNED] that was in effect at the
time of implementation. time of implementation.
BaseReachableTime BaseReachableTime
A base value used for computing the random A base value used for computing the random
ReachableTime value. ReachableTime value.
Default: REACHABLE_TIME milliseconds. Default: REACHABLE_TIME milliseconds.
skipping to change at page 51, line 31 skipping to change at page 51, line 24
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
with other flags in the prefix option. with other flags in the prefix option.
Note: Implementations can choose to process the on-link aspects of Note: Implementations can choose to process the on-link aspects of
the prefixes separately from the address autoconfiguration aspects the prefixes separately from the stateless address
of the prefixes by, e.g., passing a copy of each valid Router autoconfiguration aspects of the prefixes by, e.g., passing a copy
Advertisement message to both an "on-link" and an "addrconf" of each valid Router Advertisement message to both an "on-link"
function. Each function can then operate independently on the and an "addrconf" function. Each function can then operate
prefixes that have the appropriate flag set. independently on the prefixes that have the appropriate flag set.
6.3.5. Timing out Prefixes and Default Routers 6.3.5. Timing out Prefixes and Default Routers
Whenever the invalidation timer expires for a Prefix List entry, that Whenever the invalidation timer expires for a Prefix List entry, that
entry is discarded. No existing Destination Cache entries need be entry is discarded. No existing Destination Cache entries need be
updated, however. Should a reachability problem arise with an updated, however. Should a reachability problem arise with an
existing Neighbor Cache entry, Neighbor Unreachability Detection will existing Neighbor Cache entry, Neighbor Unreachability Detection will
perform any needed recovery. perform any needed recovery.
Whenever the Lifetime of an entry in the Default Router List expires, Whenever the Lifetime of an entry in the Default Router List expires,
skipping to change at page 53, line 33 skipping to change at page 53, line 26
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. again before sending the first Router Solicitation message.
In some cases, the random delay MAY be omitted if necessary. For In some cases, the random delay MAY be omitted if necessary. For
instance, a mobile node, using [MIPv6], moving to a new link would instance, a mobile node, using [MIPv6], moving to a new link would
need to discover such movement as soon as possible to minimize the need to discover such movement as soon as possible to minimize the
amount of packet losses resulting from the change in its topological amount of packet losses resulting from the change in its topological
movement. Router Solicitations provide a useful tool for movement movement. Router Solicitations provide a useful tool for movement
detection in Mobile IPv6 as they allow mobile nodes to determine detection in Mobile IPv6 as they allow mobile nodes to determine
movement to new links. Hence, if a mobile node received link layer movement to new links. Hence, if a mobile node received link-layer
information indicating that movement might have taken place, it MAY information indicating that movement might have taken place, it MAY
send a Router Solicitation immediately, without random delays. The send a Router Solicitation immediately, without random delays. The
strength of such indications should be assessed by the mobile node's strength of such indications should be assessed by the mobile node's
implementation depending on the level of certainty of the link layer implementation depending on the level of certainty of the link-layer
hints and is outside the scope of this specification. Note that using hints and is outside the scope of this specification. Note that using
this mechanism inappropriately (e.g. based on weak or transient this mechanism inappropriately (e.g. based on weak or transient
indications) may result in Router Solicitation storms. Furthermore, indications) may result in Router Solicitation storms. Furthermore,
simultaneous mobility of a large number of mobile nodes that use this simultaneous mobility of a large number of mobile nodes that use this
mechanism can result in a large number of solicitations sent mechanism can result in a large number of solicitations sent
simultaneously. 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 Responses to solicited advertisements are expected to contain
6.2.3); solicited advertisements are expected to contain complete complete information.
information.
If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no
Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY
seconds after sending the last solicitation, the host concludes that seconds after sending the last solicitation, the host concludes that
there are no routers on the link for the purpose of [ADDRCONF]. there are no routers on the link for the purpose of [ADDRCONF].
However, the host continues to receive and process Router However, the host continues to receive and process Router
Advertisements messages in the event that routers appear on the link. Advertisements messages in the event that routers appear on the link.
7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION
skipping to change at page 56, line 13 skipping to change at page 56, line 5
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, a router It is possible that a host may receive a solicitation, a router
advertisement, or a Redirect message without a link-layer address advertisement, or a Redirect message without a link-layer address
option included. These messages MUST NOT create or update neighbor option included. These messages MUST NOT create or update neighbor
cache entries, except with respect to the IsRouter flag as specified 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 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 for the source of such a message, Address Resolution will be required
before unicast communications with that address to begin. This is before unicast communications with that address can begin. This is
particularly relevant for unicast responses to solicitations where an particularly relevant for unicast responses to solicitations where an
additional packet exchange is required for advertisement delivery. 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
solicited-node multicast address corresponding to the new and old solicited-node multicast address corresponding to the new and old
addresses, respectively. Joining the solicited-node multicast address addresses, respectively. Joining the solicited-node multicast address
SHOULD be done using the Multicast Listener Discovery [MLD] or is done using a Multicast Listener Discovery such as [MLD] or [MLDv2]
[MLDv2] protocols. Note that multiple unicast addresses may map into protocols. Note that multiple unicast addresses may map into the same
the same solicited-node multicast address; a node MUST NOT leave the solicited-node multicast address; a node MUST NOT leave the
solicited-node multicast group until all assigned addresses solicited-node multicast group until all assigned addresses
corresponding to that multicast address have been removed. corresponding to that multicast address have been removed.
7.2.2. Sending Neighbor Solicitations 7.2.2. Sending Neighbor Solicitations
When a node has a unicast packet to send to a neighbor, but does not When a node has a unicast packet to send to a neighbor, but does not
know the neighbor's link-layer address, it performs address know the neighbor's link-layer address, it performs address
resolution. For multicast-capable interfaces this entails creating a resolution. For multicast-capable interfaces this entails creating a
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
skipping to change at page 57, line 54 skipping to change at page 57, line 45
- 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].
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
Address of the solicitation. If an entry does not already exist, the Address of the solicitation. If an entry does not already exist, the
node SHOULD create a new one and set its reachability state to STALE node SHOULD create a new one and set its reachability state to STALE
as specified in Section 7.3.3. If an entry already exists, and the as specified in Section 7.3.3. If an entry already exists, and the
cached link-layer address differs from the one in the received Source cached link-layer address differs from the one in the received Source
Link-Layer option, the cached address should be replaced by the Link-Layer option, the cached address should be replaced by the
received address and the entry's reachability state MUST be set to received address and the entry's reachability state MUST be set to
STALE. STALE.
skipping to change at page 59, line 34 skipping to change at page 59, line 26
recipient has apparently not initiated any communication with the recipient has apparently not initiated any communication with the
target. target.
Once the appropriate Neighbor Cache entry has been located, the Once the appropriate Neighbor Cache entry has been located, the
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.
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. If the the advertisement is received, one of two things happens. If the
link layer has addresses and no Target Link-Layer address option is link-layer has addresses and no Target Link-Layer address option is
included, the receiving node SHOULD silently discard the received included, the receiving node SHOULD silently discard the received
advertisement. Otherwise, the receiving node performs the following advertisement. Otherwise, the receiving node performs the following
steps: 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
skipping to change at page 60, line 20 skipping to change at page 60, line 12
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 b. Otherwise, the received advertisement should be ignored and
MUST NOT update the cache. MUST NOT update the cache.
II. If the Override flag is set, or the supplied link-layer address II. If the Override flag is set, or the supplied link-layer address
is the same as that in the cache, or no Target 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 option was supplied, the received advertisement MUST update the
Neighbor Cache entry as follows: Neighbor Cache entry 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 MUST be inserted in the cache (if one is supplied and differs
Different than the already recorded address). from the already recorded address).
- If the Solicited flag is set, the state of the entry MUST be - 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 set to REACHABLE. If the Solicited flag is zero and the link
layer address was updated with a different address the state layer address was updated with a different address the state
MUST be set to STALE. Otherwise, the entry's state remains MUST be set to STALE. Otherwise, the entry's state remains
unchanged. unchanged.
An advertisement's Solicited flag should only be set if the An advertisement's Solicited flag should only be set if the
advertisement is a response to a Neighbor Solicitation. advertisement is a response to a Neighbor Solicitation.
Because Neighbor Unreachability Detection Solicitations are Because Neighbor Unreachability Detection Solicitations are
sent to the cached link-layer address, receipt of a solicited sent to the cached link-layer address, receipt of a solicited
advertisement indicates that the forward path is working. advertisement indicates that the forward path is working.
Receipt of an unsolicited advertisement, however, suggests that Receipt of an unsolicited advertisement, however, may indicate
a neighbor has urgent information to announce (e.g., a changed that a neighbor has urgent information to announce (e.g., a
link-layer address). If the urgent information indicates a changed link-layer address). If the urgent information
change from what a node is currently using, the node should indicates a change from what a node is currently using, the
verify the reachability of the (new) path when it sends the node should verify the reachability of the (new) path when it
next packet. There is no need to update the state for sends the next packet. There is no need to update the state for
unsolicited advertisements that do not change the contents of unsolicited advertisements that do not change the contents of
the cache. the cache.
- The IsRouter flag in the cache entry MUST be set based on the - The IsRouter flag in the cache entry MUST be set based on the
Router flag in the received advertisement. In those cases Router flag in the received advertisement. In those cases
where the IsRouter flag changes from TRUE to FALSE as a result where the IsRouter flag changes from TRUE to FALSE as a result
of this update, the node MUST remove that router from the of this update, the node MUST remove that router from the
Default Router List and update the Destination Cache entries Default Router List and update the Destination Cache entries
for all destinations using that neighbor as a router as for all destinations using that neighbor as a router as
specified in Section 7.3.3. This is needed to detect when a specified in Section 7.3.3. This is needed to detect when a
skipping to change at page 61, line 44 skipping to change at page 61, line 39
A node that has multiple IP addresses assigned to an interface MAY A node that has multiple IP addresses assigned to an interface MAY
multicast a separate Neighbor Advertisement for each address. In multicast a separate Neighbor Advertisement for each address. In
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. This is a requirement reduce the risk of excessive multicast traffic. This is a requirement
on other protocols that need to use proxies for Neighbor on other protocols that need to use proxies for Neighbor
Advertisements. An example of a node that performs proxy Advertisements. An example of a node that performs proxy
advertisements is the Home Agent specified in [MIPv6]. 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.
skipping to change at page 62, line 42 skipping to change at page 62, line 35
As with unicast addresses, Neighbor Unreachability Detection ensures As with unicast addresses, Neighbor Unreachability Detection ensures
that a node quickly detects when the current binding for an anycast that a node quickly detects when the current binding for an anycast
address becomes invalid. address becomes invalid.
7.2.8. Proxy Neighbor Advertisements 7.2.8. Proxy Neighbor Advertisements
Under limited circumstances, a router MAY proxy for one or more other Under limited circumstances, a router MAY proxy for one or more other
nodes, that is, through Neighbor Advertisements indicate that it is nodes, that is, through Neighbor Advertisements indicate that it is
willing to accept packets not explicitly addressed to itself. For willing to accept packets not explicitly addressed to itself. For
example, a router might accept packets on behalf of a mobile node example, a router might accept packets on behalf of a mobile node
that has moved off-link. The mechanisms used by proxy are identical that has moved off-link. The mechanisms used by proxy are
to the mechanisms used with anycast addresses. essentially the same as the mechanisms used with anycast addresses.
A proxy MUST join the solicited-node multicast address(es) that A proxy MUST join the solicited-node multicast address(es) that
correspond to the IP address(es) assigned to the node for which it is correspond to the IP address(es) assigned to the node for which it is
proxying. This SHOULD be done using [MLD] or [MLDv2]. proxying. This SHOULD be done using a multicast listener discovery
protocol such as [MLD] or [MLDv2].
All solicited proxy Neighbor Advertisement messages MUST have the All solicited proxy Neighbor Advertisement messages MUST have the
Override flag set to zero. This ensures that if the node itself is Override flag set to zero. This ensures that if the node itself is
present on the link its Neighbor Advertisement (with the Override present on the link its Neighbor Advertisement (with the Override
flag set to one) will take precedence of any advertisement received flag set to one) will take precedence of any advertisement received
from a proxy. A proxy MAY send unsolicited advertisements with the from a proxy. A proxy MAY send unsolicited advertisements with the
Override flag set to one as specified in Section 7.2.6, but doing so Override flag set to one as specified in Section 7.2.6, but doing so
may cause the proxy advertisement to override a valid entry created may cause the proxy advertisement to override a valid entry created
by the node itself. by the node itself.
Finally, when sending a proxy advertisement in response to a Neighbor Finally, when sending a proxy advertisement in response to a Neighbor
Solicitation, the sender should delay its response by a random time Solicitation, the sender should delay its response by a random time
between 0 and MAX_ANYCAST_DELAY_TIME seconds. between 0 and MAX_ANYCAST_DELAY_TIME seconds to avoid collisions due
to multiple responses sent by several proxies. However, in some cases
(e.g. Mobile IPv6) where only one proxy is present, such delay is not
necessary.
7.3. Neighbor Unreachability Detection 7.3. Neighbor Unreachability Detection
Communication to or through a neighbor may fail for numerous reasons Communication to or through a neighbor may fail for numerous reasons
at any time, including hardware failure, hot-swap of an interface at any time, including hardware failure, hot-swap of an interface
card, etc. If the destination has failed, no recovery is possible card, etc. If the destination has failed, no recovery is possible
and communication fails. On the other hand, if it is the path that and communication fails. On the other hand, if it is the path that
has failed, recovery may be possible. Thus, a node actively tracks has failed, recovery may be possible. Thus, a node actively tracks
the reachability "state" for the neighbors to which it is sending the reachability "state" for the neighbors to which it is sending
packets. packets.
skipping to change at page 64, line 26 skipping to change at page 64, line 25
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 confirms the one-way path from the of unsolicited messages only confirms the one-way path from the
sender 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 its perspective, not the neighbor's
neighbor's perspective. Note that receipt of a solicited perspective. Note that receipt of a solicited advertisement
advertisement indicates that a path is working in both directions. indicates that a path is working in both directions. The solicitation
The solicitation must have reached the neighbor, prompting it to must have reached the neighbor, prompting it to generate an
generate an advertisement. Likewise, receipt of an advertisement advertisement. Likewise, receipt of an advertisement indicates that
indicates that the path from the sender to the recipient is working. the path from the sender to the recipient is working. However, the
However, the latter fact is known only to the recipient; the latter fact is known only to the recipient; the advertisement's
advertisement's sender has no direct way of knowing that the sender has no direct way of knowing that the advertisement it sent
advertisement it sent actually reached a neighbor. From the actually reached a neighbor. From the perspective of Neighbor
perspective of Neighbor Unreachability Detection, only the Unreachability Detection, only the reachability of the forward path
reachability of the forward path is of interest. is of interest.
7.3.2. Neighbor Cache Entry States 7.3.2. Neighbor Cache Entry States
A Neighbor Cache entry can be in one of five states: A Neighbor Cache entry can be in one of five states:
INCOMPLETE Address resolution is being performed on the entry. INCOMPLETE Address resolution is being performed on the entry.
Specifically, a Neighbor Solicitation has been sent to Specifically, a Neighbor Solicitation has been sent to
the solicited-node multicast address of the target, the solicited-node multicast address of the target,
but the corresponding Neighbor Advertisement has not but the corresponding Neighbor Advertisement has not
yet been received. yet been received.
skipping to change at page 69, line 20 skipping to change at page 69, line 18
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 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.
- In the Destination Address field: the destination address of the - In the Destination Address field: the destination address of the
invoking IP packet. invoking IP packet.
- In the options: - In the options:
o Target Link-Layer Address option: link-layer address of the o Target Link-Layer Address option: link-layer address of the
skipping to change at page 73, line 6 skipping to change at page 72, line 54
MAX_RANDOM_FACTOR 1.5 MAX_RANDOM_FACTOR 1.5
Additional protocol constants are defined with the message formats in Additional protocol constants are defined with the message formats in
Section 4. Section 4.
All protocol constants are subject to change in future revisions of All protocol constants are subject to change in future revisions of
the protocol. the protocol.
The constants in this specification may be overridden by specific The constants in this specification may be overridden by specific
documents that describe how IPv6 operates over different link layers. documents that describe how IPv6 operates over different link-layers.
This rule allows Neighbor Discovery to operate over links with widely This rule allows Neighbor Discovery to operate over links with widely
varying performance characteristics. varying performance characteristics.
11. SECURITY CONSIDERATIONS 11. SECURITY CONSIDERATIONS
Neighbor Discovery is subject to attacks that cause IP packets to Neighbor Discovery is subject to attacks that cause IP packets to
flow to unexpected places. Such attacks can be used to cause denial flow to unexpected places. Such attacks can be used to cause denial
of service but also allow nodes to intercept and optionally modify of service but also allow nodes to intercept and optionally modify
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
skipping to change at page 73, line 54 skipping to change at page 73, line 52
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. If a host has been redirected to being used for that destination. If a host has been redirected to
another node (i.e., the destination is on-link) there is no way to another node (i.e., the destination is on-link) there is no way to
prevent the target from issuing another redirect to some other prevent the target from issuing another redirect to some other
destination. However, this exposure is no worse than it was before destination. However, this exposure is no worse than it was before
skipping to change at page 74, line 26 skipping to change at page 74, line 24
as a hidden router to forward traffic elsewhere. as a hidden router to 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 a host shares a link with only one neighbor, i.e. the links where a host shares a link with only one neighbor, i.e. the
default router. default router.
11.2 Securing Neighbor Discovery messages 11.2 Securing Neighbor Discovery messages
skipping to change at page 76, line 29 skipping to change at page 76, line 26
sending Router Advertisements that contain appropriate (and current) sending Router Advertisements that contain appropriate (and current)
prefixes. A host connected to a network that has no functioning prefixes. A host connected to a network that has no functioning
routers is likely to have more serious problems than just a lack of a routers is likely to have more serious problems than just a lack of a
valid prefix and address. valid prefix and address.
The above discussion does not distinguish between the preferred and The above discussion does not distinguish between the preferred and
valid lifetimes. For all practical purposes it is probably valid lifetimes. For all practical purposes it is probably
sufficient to track the valid lifetime since the preferred lifetime sufficient to track the valid lifetime since the preferred lifetime
will not exceed the valid lifetime. will not exceed the valid lifetime.
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. The procedure for the assignment
of ICMPv6 types/codes is described in Section 6 of [ICMPv6].
This document continues to use the following ICMPv6 message types
introduced in RFC 2461 and already assigned by IANA:
Message name ICMPv6 Type
Router Solicitation 133
Router Advertisement 134
Neighbor Solicitation 135
Neighbor Advertisement 136
Redirect 137
This document continues to use the following Neighbor Discovery
option types introduced in RFC 2461 and already assigned by IANA:
Option Name Type
Source Link-Layer Address 1
Target Link-Layer Address 2
Prefix Information 3
Redirected Header 4
MTU 5
Neighbor Discovery option types are allocated using following
procedure:
1. The IANA should allocate and permanently register new option types
from IETF RFC publication. This is for all RFC types
including standards track, informational, and experimental status
that originate from the IETF and have been approved by the IESG
for publication.
2. IETF working groups with working group consensus and area director
approval can request reclaimable Neighbor Discovery option type
assignments from the IANA. The IANA will tag the values as
"reclaimable in future".
The "reclaimable in the future" tag will be removed when an RFC is
published documenting the protocol as defined in 1). This will
make the assignment permanent and update the reference on the IANA
web pages.
At the point where the option type values are 85% assigned, the
IETF will review the assignments tagged "reclaimable in the
future" and inform the IANA which ones should be reclaimed and
reassigned.
3. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document,
per 1) above. Note also that documents published as "RFC Editor
contributions" [RFC3667] are not considered to be IETF documents.
REFERENCES REFERENCES
NORMATIVE NORMATIVE
[ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 3513, April 2003. Architecture", RFC 4291, February 2006.
[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 4443, March 2006.
[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
skipping to change at page 77, line 43 skipping to change at page 78, line 50
[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 4301, December 2005. Internet Protocol", RFC 4301, December 2005.
[IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December [IPv6-AUTH] S. Kent, "IP Authentication Header", RFC 4302, December
2005. 2005.
[IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC [IPv6-ESP] S. Kent, "IP Encapsulating Security Payload (ESP)", RFC
4303, December 2005. 4303, December 2005.
[IPv6-NBMA] Armitage, G., Schulter, P., Jork, M and G. Harter "IPv6
over Non-Broadcast Multiple Access (NBMA) networks", RFC
2491, January 1999.
[LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load [LD-SHRE] Hinden, R. and D. Thaler, "IPv6 Host-to-Router Load
Sharing", RFC 4311, November 2005. Sharing", RFC 4311, November 2005.
[MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support [MIPv6] D. Johnson, C. Perkins and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004. in IPv6", RFC 3775, June 2004.
[MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast [MLD] Deering, S., Fenner, W, and B. Haberman, "Multicast
Listener Discovery for IPv6", RFC 2710, October 1999. Listener Discovery for IPv6", RFC 2710, October 1999.
[MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery [MLDv2] Vida, R. and L. Costa, "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor [PSREQ] Nikander, P., Kempf, J. And E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust and Threats", RFC 3756, May 2004. Discovery (ND) Trust and Threats", RFC 3756, May 2004.
rd [RAND] Eastlake, 3 , D., Schiller, J and S. Crocker,
"Randomness Requirements for Security", RFC 4086, June
2005.
[RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256, [RDISC] Deering, S., "ICMP Router Discovery Messages", RFC 1256,
September 1991. September 1991.
[RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667,
February 2004. February 2004.
[RTSEL] Draves, R. and D. Thaler, "Default Router Preferences [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences
and more Specific Routes", draft-ietf-ipv6-router- and more Specific Routes", draft-ietf-ipv6-router-
selection-07, (work in progress), January 2005. selection-07, (work in progress), January 2005.
skipping to change at page 78, line 30 skipping to change at page 79, line 43
1994. 1994.
[SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P. [SEND] Arkko, J., Kempf, J., Sommerfeld, B., Zill, B. and P.
Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971, Nikander, "SEcure Neighbor Discovery (SEND)",RFC3971,
March 2005. March 2005.
[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. The procedure for the assignment
of ICMPv6 types/codes is described in Section 6 of [ICMPv6].
This document continues to use the following ICMPv6 message types
introduced in RFC 2461 and already assigned by IANA:
Message name ICMPv6 Type
Router Solicitation 133
Router Advertisement 134
Neighbor Solicitation 135
Neighbor Advertisement 136
Redirect 137
This document continues to use the following Neighbor Discovery
option types introduced in RFC 2461 and already assigned by IANA:
Option Name Type
Source Link-Layer Address 1
Target Link-Layer Address 2
Prefix Information 3
Redirected Header 4
MTU 5
Neighbor Discovery option types are allocated using following
procedure:
1. The IANA should allocate and permanently register new option types
from IETF RFC publication. This is for all RFC types
including standards track, informational, and experimental status
that originate from the IETF and have been approved by the IESG
for publication.
2. IETF working groups with working group consensus and area director
approval can request reclaimable Neighbor Discovery option type
assignments from the IANA. The IANA will tag the values as
"reclaimable in future".
The "reclaimable in the future" tag will be removed when an RFC is
published documenting the protocol as defined in 1). This will
make the assignment permanent and update the reference on the IANA
web pages.
At the point where the option type values are 85% assigned, the
IETF will review the assignments tagged "reclaimable in the
future" and inform the IANA which ones should be reclaimed and
reassigned.
3. Requests for new option type value assignments from outside the
IETF are only made through the publication of an IETF document,
per 1) above. Note also that documents published as "RFC Editor
contributions" [RFC3667] are not considered to be IETF documents.
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@us.ibm.com
Erik Nordmark Erik Nordmark
Sun Microsystems, Inc. Sun Microsystems, Inc.
901 San Antonio Road 901 San Antonio Road
Palo Alto, CA 94303 Palo Alto, CA 94303
USA USA
Phone: +1 650 786 5166 Phone: +1 650 786 5166
Fax: +1 650 786 5896 Fax: +1 650 786 5896
EMail: nordmark@sun.com EMail: nordmark@sun.com
skipping to change at page 80, line 24 skipping to change at page 80, line 25
Daydreamer Daydreamer
Computer Systems Consulting Services Computer Systems Consulting Services
1384 Fontaine 1384 Fontaine
Madison Heights, Michigan 48071 Madison Heights, Michigan 48071
USA USA
EMail: Bill.Simpson@um.cc.umich.edu EMail: Bill.Simpson@um.cc.umich.edu
bsimpson@MorningStar.com bsimpson@MorningStar.com
Hesham Soliman Hesham Soliman
Qualcomm-Flarion Technologies Elevate Technologies
Email: Hesham@Qualcomm.com Email: hesham@elevatemobile.com
APPENDIX A: MULTIHOMED HOSTS APPENDIX A: MULTIHOMED HOSTS
There are a number of complicating issues that arise when Neighbor There are a number of complicating issues that arise when Neighbor
Discovery is used by hosts that have multiple interfaces. This Discovery is used by hosts that have multiple interfaces. This
section does not attempt to define the proper operation of multihomed section does not attempt to define the proper operation of multihomed
hosts with regard to Neighbor Discovery. Rather, it identifies hosts with regard to Neighbor Discovery. Rather, it identifies
issues that require further study. Implementors are encouraged to issues that require further study. Implementors are encouraged to
experiment with various approaches to making Neighbor Discovery work experiment with various approaches to making Neighbor Discovery work
on multihomed hosts and to report their experiences. Further work on multihomed hosts and to report their experiences. Further work
skipping to change at page 81, line 7 skipping to change at page 81, line 9
standard test for this case is to compare the source address of standard test for this case is to compare the source address of
the packet to the list of on-link prefixes associated with the the packet to the list of on-link prefixes associated with the
interface on which the packet was received. If the originating interface on which the packet was received. If the originating
host is multihomed, however, the source address it uses may host is multihomed, however, the source address it uses may
belong to an interface other than the interface from which it belong to an interface other than the interface from which it
was sent. In such cases, a router will not send redirects, and was sent. In such cases, a router will not send redirects, and
suboptimal routing is likely. In order to be redirected, the suboptimal routing is likely. In order to be redirected, the
sending host must always send packets out the interface sending host must always send packets out the interface
corresponding to the outgoing packet's source address. Note corresponding to the outgoing packet's source address. Note
that this issue never arises with non-multihomed hosts; they that this issue never arises with non-multihomed hosts; they
only have one interface. only have one interface. Additional discussion on this topic can
be found in RFC1122 under section 3.3.4.2.
2) If the selected first-hop router does not have a route at all 2) If the selected first-hop router does not have a route at all
for the destination, it will be unable to deliver the packet. for the destination, it will be unable to deliver the packet.
However, the destination may be reachable through a router on However, the destination may be reachable through a router on
one of the other interfaces. Neighbor Discovery does not one of the other interfaces. Neighbor Discovery does not
address this scenario; it does not arise in the non-multihomed address this scenario; it does not arise in the non-multihomed
case. case.
3) Even if the first-hop router does have a route for a 3) Even if the first-hop router does have a route for a
destination, there may be a better route via another interface. destination, there may be a better route via another interface.
skipping to change at page 82, line 46 skipping to change at page 82, line 49
INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE
Override=any address. Send queued Override=any address. Send queued
packets. packets.
INCOMPLETE NA, Solicited=any, Update content of unchanged INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No IsRouter flag Override=any, No IsRouter flag
Link-layer address Link-layer address
- NS, RS, Redirect - - - NS, RS, Redirect - -
No link layer address No link-layer address
!INCOMPLETE NA, Solicited=1, - REACHABLE !INCOMPLETE NA, Solicited=1, - REACHABLE
Override=0 Override=0
Same link-layer Same link-layer
address as cached. address as cached.
!INCOMPLETE NA, Solicited=any, Update content of unchanged !INCOMPLETE NA, Solicited=any, Update content of unchanged
Override=any, No IsRouter flag. Override=any, No IsRouter flag.
link-layer address link-layer address
REACHABLE NA, Solicited=1, - STALE REACHABLE NA, Solicited=1, - STALE
Override=0 Override=0
Different link-layer Different link-layer
address than cached. address than cached.
STALE, PROBE NA, Solicited=1, - unchanged STALE, PROBE NA, Solicited=1, - unchanged
Or DELAY Override=0 Or DELAY Override=0
Different link-layer Different link-layer
skipping to change at page 84, line 37 skipping to change at page 84, line 40
APPENDIX D: SUMMARY OF ISROUTER RULES APPENDIX D: SUMMARY OF ISROUTER RULES
This appendix presents a summary of the rules for maintaining the This appendix presents a summary of the rules for maintaining the
IsRouter flag as specified in this document. IsRouter flag as specified in this document.
The background for these rules is that the ND messages contain, The background for these rules is that the ND messages contain,
either implicitly or explicitly, information that indicates whether either implicitly or explicitly, information that indicates whether
or not the sender (or Target Address) is a host or a router. The or not the sender (or Target Address) is a host or a router. The
following assumptions are used: following assumptions are used:
- The sender of a Router Solicitation is implicitly assumed to be a
host since there is no need for routers to send such messages.
- The sender of a Router Advertisement is implicitly assumed to be a - The sender of a Router Advertisement is implicitly assumed to be a
router. router.
- Neighbor Solicitation messages do not contain either an implicit - Neighbor Solicitation messages do not contain either an implicit
or explicit indication about the sender. Both hosts and routers or explicit indication about the sender. Both hosts and routers
send such messages. send such messages.
- Neighbor Advertisement messages contain an explicit "IsRouter - Neighbor Advertisement messages contain an explicit "IsRouter
flag", the R-bit. flag", the R-bit.
skipping to change at page 85, line 12 skipping to change at page 85, line 12
node is expected to be able to forward the packets towards the node is expected to be able to forward the packets towards the
destination. destination.
- The target of the redirect, when the target is the same as the - The target of the redirect, when the target is the same as the
destination, does not carry any host vs. router information. All destination, does not carry any host vs. router information. All
that is known is that the destination (i.e. target) is on-link but that is known is that the destination (i.e. target) is on-link but
it could be either a host or a router. it could be either a host or a router.
The rules for setting the IsRouter flag are based on the information The rules for setting the IsRouter flag are based on the information
content above. If an ND message contains explicit or implicit content above. If an ND message contains explicit or implicit
information the receipt of the message will cause the IsRouter flag information, the receipt of the message will cause the IsRouter flag
to be updated. But when there is no host vs. router information in to be updated. But when there is no host vs. router information in
the ND message the receipt of the message MUST NOT cause a change to the ND message the receipt of the message MUST NOT cause a change to
the IsRouter state. When the receipt of such a message causes a the IsRouter state. When the receipt of such a message causes a
Neighbor Cache entry to be created this document specifies that the Neighbor Cache entry to be created this document specifies that the
IsRouter flag be set to FALSE. There is greater potential for IsRouter flag be set to FALSE. There is greater potential for
mischief when a node incorrectly thinks a host is a router, than the mischief when a node incorrectly thinks a host is a router, than the
other way around. In these cases a subsequent Neighbor Advertisement other way around. In these cases a subsequent Neighbor Advertisement
or Router Advertisement message will set the correct IsRouter value. or Router Advertisement message will set the correct IsRouter value.
APPENDIX E: IMPLEMENTATION ISSUES APPENDIX E: IMPLEMENTATION ISSUES
skipping to change at page 86, line 10 skipping to change at page 86, line 10
To minimize the cost of communicating reachability information To minimize the cost of communicating reachability information
between the TCP and IP layers, an implementation may wish to rate- between the TCP and IP layers, an implementation may wish to rate-
limit the reachability confirmations its sends IP. One possibility limit the reachability confirmations its sends IP. One possibility
is to process reachability only every few packets. For example, one is to process reachability only every few packets. For example, one
might update reachability information once per round trip time, if an might update reachability information once per round trip time, if an
implementation only has one round trip timer per connection. For implementation only has one round trip timer per connection. For
those implementations that cache Destination Cache entries within those implementations that cache Destination Cache entries within
control blocks, it may be possible to update the Neighbor Cache entry control blocks, it may be possible to update the Neighbor Cache entry
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 implementations 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. It 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
request indicates that a previous response reached the client. request indicates that a previous response reached the client.
Note that an implementation can not use negative upper-layer advise Note that an implementation can not use negative upper-layer advice
as a replacement for the Neighbor Unreachability Detection algorithm. as a replacement for the Neighbor Unreachability Detection algorithm.
Negative advise (e.g. from TCP when there are excessive Negative advice (e.g., from TCP when there are excessive
retransmissions) could serve as a hint that the forward path from the retransmissions) could serve as a hint that the forward path from the
sender of the data might not be working. But it would fail to detect sender of the data might not be working. But it would fail to detect
when the path from the receiver of the data is not functioning when the path from the receiver of the data is not functioning,
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 references to IPsec AH and ESP for securing messages o Removed 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.
skipping to change at page 87, line 28 skipping to change at page 87, line 28
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 support for Load balancing is limited to routers.
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. non-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 o Added clarifications in section 7.2 on how a node should react
upon receiving a message without SLLAO. upon receiving a message without SLLAO.
O Added New IANA section. O Added New IANA section.
o Miscellaneous editorials. o Miscellaneous editorials.
skipping to change at page 88, line 15 skipping to change at page 88, line 15
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 (2006). This document is subject Copyright (C) The Internet Society (2007). 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, 2007. This Internet-Draft expires June, 2007.
 End of changes. 104 change blocks. 
289 lines changed or deleted 308 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/