diff --git a/technikzeugs/theorie/ipv6/rfc4861.txt b/technikzeugs/theorie/ipv6/rfc4861.txt new file mode 100644 index 0000000..816dda6 --- /dev/null +++ b/technikzeugs/theorie/ipv6/rfc4861.txt @@ -0,0 +1,5435 @@ + + + + + + +Network Working Group T. Narten +Request for Comments: 4861 IBM +Obsoletes: 2461 E. Nordmark +Category: Standards Track Sun Microsystems + W. Simpson + Daydreamer + H. Soliman + Elevate Technologies + September 2007 + + + Neighbor Discovery for IP version 6 (IPv6) + +Status of This Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Abstract + + This document specifies the Neighbor Discovery protocol for IP + Version 6. IPv6 nodes on the same link use Neighbor Discovery to + discover each other's presence, to determine each other's link-layer + addresses, to find routers, and to maintain reachability information + about the paths to active neighbors. + + + + + + + + + + + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 1] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Table of Contents + + 1. Introduction ....................................................4 + 2. Terminology .....................................................4 + 2.1. General ....................................................4 + 2.2. Link Types .................................................8 + 2.3. Addresses ..................................................9 + 2.4. Requirements ..............................................10 + 3. Protocol Overview ..............................................10 + 3.1. Comparison with IPv4 ......................................14 + 3.2. Supported Link Types ......................................16 + 3.3. Securing Neighbor Discovery Messages ......................18 + 4. Message Formats ................................................18 + 4.1. Router Solicitation Message Format ........................18 + 4.2. Router Advertisement Message Format .......................19 + 4.3. Neighbor Solicitation Message Format ......................22 + 4.4. Neighbor Advertisement Message Format .....................23 + 4.5. Redirect Message Format ...................................26 + 4.6. Option Formats ............................................28 + 4.6.1. Source/Target Link-layer Address ...................28 + 4.6.2. Prefix Information .................................29 + 4.6.3. Redirected Header ..................................31 + 4.6.4. MTU ................................................32 + 5. Conceptual Model of a Host .....................................33 + 5.1. Conceptual Data Structures ................................33 + 5.2. Conceptual Sending Algorithm ..............................36 + 5.3. Garbage Collection and Timeout Requirements ...............37 + 6. Router and Prefix Discovery ....................................38 + 6.1. Message Validation ........................................39 + 6.1.1. Validation of Router Solicitation Messages .........39 + 6.1.2. Validation of Router Advertisement Messages ........39 + 6.2. Router Specification ......................................40 + 6.2.1. Router Configuration Variables .....................40 + 6.2.2. Becoming an Advertising Interface ..................45 + 6.2.3. Router Advertisement Message Content ...............45 + 6.2.4. Sending Unsolicited Router Advertisements ..........47 + 6.2.5. Ceasing To Be an Advertising Interface .............47 + 6.2.6. Processing Router Solicitations ....................48 + 6.2.7. Router Advertisement Consistency ...................50 + 6.2.8. Link-local Address Change ..........................50 + 6.3. Host Specification ........................................51 + 6.3.1. Host Configuration Variables .......................51 + 6.3.2. Host Variables .....................................51 + 6.3.3. Interface Initialization ...........................52 + 6.3.4. Processing Received Router Advertisements ..........53 + 6.3.5. Timing out Prefixes and Default Routers ............56 + 6.3.6. Default Router Selection ...........................56 + 6.3.7. Sending Router Solicitations .......................57 + + + +Narten, et al. Standards Track [Page 2] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + 7. Address Resolution and Neighbor Unreachability Detection .......59 + 7.1. Message Validation ........................................59 + 7.1.1. Validation of Neighbor Solicitations ...............59 + 7.1.2. Validation of Neighbor Advertisements ..............60 + 7.2. Address Resolution ........................................60 + 7.2.1. Interface Initialization ...........................61 + 7.2.2. Sending Neighbor Solicitations .....................61 + 7.2.3. Receipt of Neighbor Solicitations ..................62 + 7.2.4. Sending Solicited Neighbor Advertisements ..........63 + 7.2.5. Receipt of Neighbor Advertisements .................64 + 7.2.6. Sending Unsolicited Neighbor Advertisements ........66 + 7.2.7. Anycast Neighbor Advertisements ....................67 + 7.2.8. Proxy Neighbor Advertisements ......................68 + 7.3. Neighbor Unreachability Detection .........................68 + 7.3.1. Reachability Confirmation ..........................69 + 7.3.2. Neighbor Cache Entry States ........................70 + 7.3.3. Node Behavior ......................................71 + 8. Redirect Function ..............................................73 + 8.1. Validation of Redirect Messages ...........................74 + 8.2. Router Specification ......................................75 + 8.3. Host Specification ........................................76 + 9. Extensibility - Option Processing ..............................76 + 10. Protocol Constants ............................................78 + 11. Security Considerations .......................................79 + 11.1. Threat Analysis ..........................................79 + 11.2. Securing Neighbor Discovery Messages .....................81 + 12. Renumbering Considerations ....................................81 + 13. IANA Considerations ...........................................83 + 14. References ....................................................84 + 14.1. Normative References .....................................84 + 14.2. Informative References ...................................84 + Appendix A: Multihomed Hosts ......................................87 + Appendix B: Future Extensions .....................................88 + Appendix C: State Machine for the Reachability State ..............89 + Appendix D: Summary of IsRouter Rules .............................91 + Appendix E: Implementation Issues .................................92 + Appendix F: Changes from RFC 2461 .................................94 + Acknowledgments ...................................................95 + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 3] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +1. Introduction + + This specification defines the Neighbor Discovery (ND) protocol for + Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use + Neighbor Discovery to determine the link-layer addresses for + neighbors known to reside on attached links and to quickly purge + cached values that become invalid. Hosts also use Neighbor Discovery + to find neighboring routers that are willing to forward packets on + their behalf. Finally, nodes use the protocol to actively keep track + of which neighbors are reachable and which are not, and to detect + changed link-layer addresses. When a router or the path to a router + fails, a host actively searches for functioning alternates. + + Unless specified otherwise (in a document that covers operating IP + over a particular link type) this document applies to all link types. + However, because ND uses link-layer multicast for some of its + services, it is possible that on some link types (e.g., Non-Broadcast + Multi-Access (NBMA) links), alternative protocols or mechanisms to + implement those services will be specified (in the appropriate + document covering the operation of IP over a particular link type). + The services described in this document that are not directly + dependent on multicast, such as Redirects, Next-hop determination, + Neighbor Unreachability Detection, 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-NBMA]. In addition, [IPv6-3GPP] + and[IPv6-CELL] discuss the use of this protocol over some cellular + links, which are examples of NBMA links. + +2. Terminology + +2.1. General + + IP - Internet Protocol Version 6. The terms IPv4 and IPv6 + are used only in contexts where necessary to avoid + ambiguity. + + ICMP - Internet Control Message Protocol for the Internet + Protocol Version 6. The terms ICMPv4 and ICMPv6 are + used only in contexts where necessary to avoid + ambiguity. + + node - a device that implements IP. + + router - a node that forwards IP packets not explicitly + addressed to itself. + + host - any node that is not a router. + + + + +Narten, et al. Standards Track [Page 4] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + upper layer - a protocol layer immediately above IP. Examples are + transport protocols such as TCP and UDP, control + protocols such as ICMP, routing protocols such as OSPF, + and Internet-layer (or lower-layer) protocols being + "tunneled" over (i.e., encapsulated in) IP such as + Internetwork Packet Exchange (IPX), AppleTalk, or IP + itself. + + link - a communication facility or medium over which nodes can + communicate at the link layer, i.e., the layer + immediately below IP. Examples are Ethernets (simple + or bridged), PPP links, X.25, Frame Relay, or ATM + networks as well as Internet-layer (or higher-layer) + "tunnels", such as tunnels over IPv4 or IPv6 itself. + + interface - a node's attachment to a link. + + neighbors - nodes attached to the same link. + + address - an IP-layer identifier for an interface or a set of + interfaces. + + anycast address + - an identifier for a set of interfaces (typically + belonging to different nodes). A packet sent to an + anycast address is delivered to one of the interfaces + identified by that address (the "nearest" one, + according to the routing protocol's measure of + distance). See [ADDR-ARCH]. + + Note that an anycast address is syntactically + indistinguishable from a unicast address. Thus, nodes + sending packets to anycast addresses don't generally + know that an anycast address is being used. Throughout + the rest of this document, references to unicast + addresses also apply to anycast addresses in those + cases where the node is unaware that a unicast address + is actually an anycast address. + + prefix - a bit string that consists of some number of initial + bits of an address. + + link-layer address + - a link-layer identifier for an interface. Examples + include IEEE 802 addresses for Ethernet links. + + + + + + +Narten, et al. Standards Track [Page 5] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + on-link - an address that is assigned to an interface on a + specified link. A node considers an address to be on- + link if: + + - 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 the + target of a Redirect message, or + + - a Neighbor Advertisement message is received for + the (target) address, or + + - any Neighbor Discovery message is received from + the address. + + off-link - the opposite of "on-link"; an address that is not + assigned to any interfaces on the specified link. + + longest prefix match + - the process of determining which prefix (if any) in a + set of prefixes covers a target address. A target + address is covered by a prefix if all of the bits in + the prefix match the left-most bits of the target + address. When multiple prefixes cover an address, the + longest prefix is the one that matches. + + reachability + - whether or not the one-way "forward" path to a neighbor + is functioning properly. In particular, whether + packets sent to a neighbor are reaching the IP layer on + the neighboring machine and are being processed + properly by the receiving IP layer. For neighboring + routers, reachability means that packets sent by a + node's IP layer are delivered to the router's IP layer, + and the router is indeed forwarding packets (i.e., it + is configured as a router, not a host). For hosts, + reachability means that packets sent by a node's IP + layer are delivered to the neighbor host's IP layer. + + packet - an IP header plus payload. + + link MTU - the maximum transmission unit, i.e., maximum packet + size in octets, that can be conveyed in one + transmission unit over a link. + + + + + +Narten, et al. Standards Track [Page 6] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + target - an address about which address resolution information + is sought, or an address that is the new first hop when + being redirected. + + proxy - a node that responds to Neighbor Discovery query + messages on behalf of another node. A router acting on + behalf of a mobile node that has moved off-link could + potentially act as a proxy for the mobile node. + + ICMP destination unreachable indication + - an error indication returned to the original sender of + a packet that cannot be delivered for the reasons + outlined in [ICMPv6]. If the error occurs on a node + other than the node originating the packet, an ICMP + error message is generated. If the error occurs on the + originating node, an implementation is not required to + actually create and send an ICMP error packet to the + source, as long as the upper-layer sender is notified + through an appropriate mechanism (e.g., return value + from a procedure call). Note, however, that an + implementation may find it convenient in some cases to + return errors to the sender by taking the offending + packet, generating an ICMP error message, and then + delivering it (locally) through the generic error- + handling routines. + + random delay + - when sending out messages, it is sometimes necessary to + delay a transmission for a random amount of time in + order to prevent multiple nodes from transmitting at + exactly the same time, or to prevent long-range + periodic transmissions from synchronizing with each + other [SYNC]. When a random component is required, a + node calculates the actual delay in such a way that the + computed delay forms a uniformly distributed random + value that falls between the specified minimum and + maximum delay times. The implementor must take care to + ensure that the granularity of the calculated random + component and the resolution of the timer used are both + high enough to ensure that the probability of multiple + nodes delaying the same amount of time is small. + + random delay seed + - if a pseudo-random number generator is used in + calculating a random delay component, the generator + should be initialized with a unique seed prior to being + used. Note that it is not sufficient to use the + interface identifier alone as the seed, since interface + + + +Narten, et al. Standards Track [Page 7] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + identifiers will not always be unique. To reduce the + probability that duplicate interface identifiers cause + the same seed to be used, the seed should be calculated + from a variety of input sources (e.g., machine + components) that are likely to be different even on + identical "boxes". For example, the seed could be + formed by combining the CPU's serial number with an + interface identifier. Additional information on + randomness and random number generation can be found in + [RAND]. + +2.2. Link Types + + Different link layers have different properties. The ones of concern + to Neighbor Discovery are: + + multicast capable + - a link that supports a native mechanism at the link + layer for sending packets to all (i.e., broadcast) + or a subset of all neighbors. + + point-to-point - a link that connects exactly two interfaces. A + point-to-point link is assumed to have multicast + capability and a link-local address. + + non-broadcast multi-access (NBMA) + - a link to which more than two interfaces can attach, + but that does not support a native form of multicast + or broadcast (e.g., X.25, ATM, frame relay, etc.). + Note that all link types (including NBMA) are + expected to provide multicast service for + applications that need it (e.g., using multicast + servers). However, it is an issue for further study + whether ND should use such facilities or an + alternate mechanism that provides the equivalent + multicast capability for ND. + + shared media - a link that allows direct communication among a + number of nodes, but attached nodes are configured + in such a way that they do not have complete prefix + information for all on-link destinations. That is, + at the IP level, nodes on the same link may not know + that they are neighbors; by default, they + communicate through a router. Examples are large + (switched) public data networks such as Switched + Multimegabit Data Service (SMDS) and Broadband + Integrated Services Digital Network (B-ISDN). Also + known as "large clouds". See [SH-MEDIA]. + + + +Narten, et al. Standards Track [Page 8] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + variable MTU - a link that does not have a well-defined MTU (e.g., + IEEE 802.5 token rings). Many links (e.g., + Ethernet) have a standard MTU defined by the link- + layer protocol or by the specific document + describing how to run IP over the link layer. + + asymmetric reachability + - a link where non-reflexive and/or non-transitive + reachability is part of normal operation. (Non- + reflexive reachability means packets from A reach B, + but packets from B don't reach A. Non-transitive + reachability means packets from A reach B, and + packets from B reach C, but packets from A don't + reach C.) Many radio links exhibit these + properties. + +2.3. Addresses + + Neighbor Discovery makes use of a number of different addresses + defined in [ADDR-ARCH], including: + + all-nodes multicast address + - the link-local scope address to reach all nodes, + FF02::1. + + all-routers multicast address + - the link-local scope address to reach all routers, + FF02::2. + + solicited-node multicast address + - a link-local scope multicast address that is computed + as a function of the solicited target's address. The + function is described in [ADDR-ARCH]. The function is + chosen so that IP addresses that differ only in the + most significant bits, e.g., due to multiple prefixes + associated with different providers, will map to the + same solicited-node address thereby reducing the number + of multicast addresses a node must join at the link + layer. + + link-local address + - a unicast address having link-only scope that can be + used to reach neighbors. All interfaces on routers + MUST have a link-local address. Also, [ADDRCONF] + requires that interfaces on hosts have a link-local + address. + + + + + +Narten, et al. Standards Track [Page 9] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + unspecified address + - a reserved address value that indicates the lack of an + address (e.g., the address is unknown). It is never + used as a destination address, but may be used as a + source address if the sender does not (yet) know its + own address (e.g., while verifying an address is unused + during stateless address autoconfiguration [ADDRCONF]). + 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 + consistency requirements in [ADDR-SEL] for the scopes of source and + destination addresses. It is possible in some cases for hosts to use + a source address of a larger scope than the destination address in + the IPv6 header. + +2.4. Requirements + + The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, + SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this + document, are to be interpreted as described in [KEYWORDS]. + + This document also makes use of internal conceptual variables to + describe protocol behavior and external variables that an + implementation must allow system administrators to change. The + specific variable names, how their values change, and how their + settings influence protocol behavior are provided to demonstrate + protocol behavior. An implementation is not required to have them in + the exact form described here, so long as its external behavior is + consistent with that described in this document. + +3. Protocol Overview + + This protocol solves a set of problems related to the interaction + between nodes attached to the same link. It defines mechanisms for + solving each of the following problems: + + Router Discovery: How hosts locate routers that reside on an + attached link. + + Prefix Discovery: How hosts discover the set of address prefixes + that define which destinations are on-link for an + attached link. (Nodes use prefixes to distinguish + destinations that reside on-link from those only + reachable through a router.) + + Parameter Discovery: How a node learns link parameters (such as the + link MTU) or Internet parameters (such as the hop limit + value) to place in outgoing packets. + + + +Narten, et al. Standards Track [Page 10] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Address Autoconfiguration: Introduces the mechanisms needed in + order to allow nodes to configure an address for an + interface in a stateless manner. Stateless address + autoconfiguration is specified in [ADDRCONF]. + + Address resolution: How nodes determine the link-layer address of + an on-link destination (e.g., a neighbor) given only the + destination's IP address. + + Next-hop determination: The algorithm for mapping an IP destination + address into the IP address of the neighbor to which + traffic for the destination should be sent. The next- + hop can be a router or the destination itself. + + Neighbor Unreachability Detection: How nodes determine that a + neighbor is no longer reachable. For neighbors used as + routers, alternate default routers can be tried. For + both routers and hosts, address resolution can be + performed again. + + Duplicate Address Detection: How a node determines whether or not + 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 + to reach a particular destination. + + Neighbor Discovery defines five different ICMP packet types: A pair + of Router Solicitation and Router Advertisement messages, a pair of + Neighbor Solicitation and Neighbor Advertisements messages, and a + Redirect message. The messages serve the following purpose: + + Router Solicitation: When an interface becomes enabled, hosts may + send out Router Solicitations that request routers to + generate Router Advertisements immediately rather than + at their next scheduled time. + + Router Advertisement: Routers advertise their presence together + with various link and Internet parameters either + periodically, or in response to a Router Solicitation + message. Router Advertisements contain prefixes that + are used for determining whether another address shares + the same link (on-link determination) and/or address + configuration, a suggested hop limit value, etc. + + + + + + + +Narten, et al. Standards Track [Page 11] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Neighbor Solicitation: Sent by a node to determine the link-layer + address of a neighbor, or to verify that a neighbor is + still reachable via a cached link-layer address. + Neighbor Solicitations are also used for Duplicate + Address Detection. + + Neighbor Advertisement: A response to a Neighbor Solicitation + message. A node may also send unsolicited Neighbor + Advertisements to announce a link-layer address change. + + Redirect: Used by routers to inform hosts of a better first hop + for a destination. + + On multicast-capable links, each router periodically multicasts a + Router Advertisement packet announcing its availability. A host + receives Router Advertisements from all routers, building a list of + default routers. Routers generate Router Advertisements frequently + enough that hosts will learn of their presence within a few minutes, + but not frequently enough to rely on an absence of advertisements to + detect router failure; a separate Neighbor Unreachability Detection + algorithm provides failure detection. + + Router Advertisements contain a list of prefixes used for on-link + determination and/or autonomous address configuration; flags + associated with the prefixes specify the intended uses of a + particular prefix. Hosts use the advertised on-link prefixes to + build and maintain a list that is used in deciding when a packet's + destination is on-link or beyond a router. Note that a destination + can be on-link even though it is not covered by any advertised on- + link prefix. In such cases, a router can send a Redirect informing + the sender that the destination is a neighbor. + + Router Advertisements (and per-prefix flags) allow routers to inform + hosts how to perform Address Autoconfiguration. For example, routers + can specify whether hosts should use DHCPv6 and/or autonomous + (stateless) address configuration. + + Router Advertisement messages also contain Internet parameters such + as the hop limit that hosts should use in outgoing packets and, + optionally, link parameters such as the link MTU. This facilitates + centralized administration of critical parameters that can be set on + routers and automatically propagated to all attached hosts. + + Nodes accomplish address resolution by multicasting a Neighbor + Solicitation that asks the target node to return its link-layer + address. Neighbor Solicitation messages are multicast to the + solicited-node multicast address of the target address. The target + returns its link-layer address in a unicast Neighbor Advertisement + + + +Narten, et al. Standards Track [Page 12] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + message. A single request-response pair of packets is sufficient for + both the initiator and the target to resolve each other's link-layer + addresses; the initiator includes its link-layer address in the + Neighbor Solicitation. + + Neighbor Solicitation messages can also be used to determine if more + than one node has been assigned the same unicast address. The use of + Neighbor Solicitation messages for Duplicate Address Detection is + specified in [ADDRCONF]. + + Neighbor Unreachability Detection detects the failure of a neighbor + or the failure of the forward path to the neighbor. Doing so + requires positive confirmation that packets sent to a neighbor are + actually reaching that neighbor and being processed properly by its + IP layer. Neighbor Unreachability Detection uses confirmation from + two sources. When possible, upper-layer protocols provide a positive + confirmation that a connection is making "forward progress", that is, + previously sent data is known to have been delivered correctly (e.g., + new acknowledgments were received recently). When positive + confirmation is not forthcoming through such "hints", a node sends + unicast Neighbor Solicitation messages that solicit Neighbor + Advertisements as reachability confirmation from the next hop. To + reduce unnecessary network traffic, probe messages are only sent to + neighbors to which the node is actively sending packets. + + In addition to addressing the above general problems, Neighbor + Discovery also handles the following situations: + + Link-layer address change - A node that knows its link-layer + address has changed can multicast a few (unsolicited) + Neighbor Advertisement packets to all nodes to quickly update + cached link-layer addresses that have become invalid. Note + that the sending of unsolicited advertisements is a + performance enhancement only (e.g., unreliable). The + Neighbor Unreachability Detection algorithm ensures that all + nodes will reliably discover the new address, though the + delay may be somewhat longer. + + Inbound load balancing - Nodes with replicated interfaces may want + to load balance the reception of incoming packets across + multiple network interfaces on the same link. Such nodes + have multiple link-layer addresses assigned to the same + interface. For example, a single network driver could + represent multiple network interface cards as a single + logical interface having multiple link-layer addresses. + + + + + + +Narten, et al. Standards Track [Page 13] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Neighbor Discovery allows a router to perform load balancing + for traffic addressed to itself by allowing routers to omit + the source link-layer address from Router Advertisement + packets, thereby forcing neighbors to use Neighbor + Solicitation messages to learn link-layer addresses of + routers. Returned Neighbor Advertisement messages can then + contain link-layer addresses that differ depending on, e.g., + who issued the solicitation. This specification does not + define a mechanism that allows hosts to Load-balance incoming + packets. See [LD-SHRE]. + + Anycast addresses - Anycast addresses identify one of a set of + nodes providing an equivalent service, and multiple nodes on + the same link may be configured to recognize the same anycast + address. Neighbor Discovery handles anycasts by having nodes + expect to receive multiple Neighbor Advertisements for the + same target. All advertisements for anycast addresses are + tagged as being non-Override advertisements. A non-Override + advertisement is one that does not update or replace the + information 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 node willing to accept packets on behalf + of a target address that is unable to respond to Neighbor + Solicitations can issue non-Override Neighbor Advertisements. + Proxy advertisements are used by Mobile IPv6 Home Agents to + defend mobile nodes' addresses when they move off-link. + However, it is not intended as a general mechanism to handle + nodes that, e.g., do not implement this protocol. + +3.1. Comparison with IPv4 + + The IPv6 Neighbor Discovery protocol corresponds to a combination of + the IPv4 protocols Address Resolution Protocol [ARP], ICMP Router + Discovery [RDISC], and ICMP Redirect [ICMPv4]. In IPv4 there is no + generally agreed upon protocol or mechanism for Neighbor + Unreachability Detection, although the Hosts Requirements document + [HR-CL] does specify some possible algorithms for Dead Gateway + Detection (a subset of the problems Neighbor Unreachability Detection + tackles). + + + + + + + + +Narten, et al. Standards Track [Page 14] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + The Neighbor Discovery protocol provides a multitude of improvements + over the IPv4 set of protocols: + + Router Discovery is part of the base protocol set; there is no + need for hosts to "snoop" the routing protocols. + + Router Advertisements carry link-layer addresses; no additional + packet exchange is needed to resolve the router's link-layer + address. + + Router Advertisements carry prefixes for a link; there is no need + to have a separate mechanism to configure the "netmask". + + Router Advertisements enable Address Autoconfiguration. + + Routers can advertise an MTU for hosts to use on the link, + ensuring that all nodes use the same MTU value on links lacking a + well-defined MTU. + + Address resolution multicasts are "spread" over 16 million (2^24) + multicast addresses, greatly reducing address-resolution-related + interrupts on nodes other than the target. Moreover, non-IPv6 + machines should not be interrupted at all. + + Redirects contain the link-layer address of the new first hop; + separate address resolution is not needed upon receiving a + redirect. + + Multiple prefixes can be associated with the same link. By + default, hosts learn all on-link prefixes from Router + Advertisements. However, routers may be configured to omit some + or all prefixes from Router Advertisements. In such cases hosts + assume that destinations are off-link and send traffic to routers. + A router can then issue redirects as appropriate. + + Unlike IPv4, the recipient of an IPv6 redirect assumes that the + 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 + network mask. The IPv6 redirect mechanism is analogous to the + XRedirect facility specified in [SH-MEDIA]. It is expected to be + useful on non-broadcast and shared media links in which it is + undesirable or not possible for nodes to know all prefixes for + on-link destinations. + + Neighbor Unreachability Detection is part of the base, which + significantly improves the robustness of packet delivery in the + presence of failing routers, partially failing or partitioned + links, or nodes that change their link-layer addresses. For + + + +Narten, et al. Standards Track [Page 15] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + instance, mobile nodes can move off-link without losing any + connectivity due to stale ARP caches. + + Unlike ARP, Neighbor Discovery detects half-link failures (using + Neighbor Unreachability Detection) and avoids sending traffic to + neighbors with which two-way connectivity is absent. + + Unlike in IPv4 Router Discovery, the Router Advertisement messages + do not contain a preference field. The preference field is not + needed to handle routers of different "stability"; the Neighbor + Unreachability Detection will detect dead routers and switch to a + working one. + + The use of link-local addresses to uniquely identify routers (for + Router Advertisement and Redirect messages) makes it possible for + hosts to maintain the router associations in the event of the site + renumbering to use new global prefixes. + + By setting the Hop Limit to 255, Neighbor Discovery is immune to + off-link senders that accidentally or intentionally send ND + messages. In IPv4, off-link senders can send both ICMP Redirects + and Router Advertisement messages. + + Placing address resolution at the ICMP layer makes the protocol + more media-independent than ARP and makes it possible to use + generic IP-layer authentication and security mechanisms as + appropriate. + +3.2. Supported Link Types + + Neighbor Discovery supports links with different properties. In the + presence of certain properties, only a subset of the ND protocol + mechanisms are fully specified in this document: + + point-to-point - Neighbor Discovery handles such links just like + multicast links. (Multicast can be trivially + provided on point-to-point links, and interfaces + can be assigned link-local addresses.) + + multicast - Neighbor Discovery operates over multicast capable + links as described in this document. + + non-broadcast multiple access (NBMA) + - Redirect, Neighbor Unreachability Detection and + next-hop determination should be implemented as + described in this document. Address resolution, + and the mechanism for delivering Router + Solicitations and Advertisements on NBMA links are + + + +Narten, et al. Standards Track [Page 16] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + not specified in this document. Note that if + hosts support manual configuration of a list of + default routers, hosts can dynamically acquire the + link-layer addresses for their neighbors from + Redirect messages. + + shared media - The Redirect message is modeled after the + XRedirect message in [SH-MEDIA] in order to + simplify use of the protocol on shared media + links. + + This specification does not address shared media + issues that only relate to routers, such as: + + - How routers exchange reachability information + on a shared media link. + + - How a router determines the link-layer address + of a host, which it needs to send redirect + messages to the host. + + - How a router determines that it is the first- + hop router for a received packet. + + The protocol is extensible (through the definition + of new options) so that other solutions might be + possible in the future. + + variable MTU - Neighbor Discovery allows routers to specify an + MTU for the link, which all nodes then use. All + nodes on a link must use the same MTU (or Maximum + Receive Unit) in order for multicast to work + properly. Otherwise, when multicasting, a sender, + which can not know which nodes will receive the + packet, could not determine a minimum packet size + that all receivers can process (or Maximum Receive + Unit). + + asymmetric reachability + - Neighbor Discovery detects the absence of + symmetric reachability; a node avoids paths to a + neighbor with which it does not have symmetric + connectivity. + + The Neighbor Unreachability Detection will + typically identify such half-links and the node + will refrain from using them. + + + + +Narten, et al. Standards Track [Page 17] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + The protocol can presumably be extended in the + future to find viable paths in environments that + lack reflexive and transitive connectivity. + +3.3. Securing Neighbor Discovery Messages + + Neighbor Discovery messages are needed for various functions. + Several functions are designed to allow hosts to ascertain the + ownership of an address or the mapping between link-layer and IP- + layer addresses. Vulnerabilities related to Neighbor Discovery are + discussed in Section 11.1. A general solution for securing Neighbor + Discovery is outside the scope of this specification and is discussed + in [SEND]. However, Section 11.2 explains how and under which + constraints IPsec Authentication Header (AH) or Encapsulating + Security Payload (ESP) can be used to secure Neighbor Discovery. + +4. Message Formats + + This section introduces message formats for all messages used in this + specification. + +4.1. Router Solicitation Message Format + + Hosts send Router Solicitations in order to prompt routers to + generate Router Advertisements quickly. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + IP Fields: + + Source Address + An IP address assigned to the sending interface, or + the unspecified address if no address is assigned + to the sending interface. + + Destination Address + Typically the all-routers multicast address. + + Hop Limit 255 + + + + +Narten, et al. Standards Track [Page 18] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + ICMP Fields: + + Type 133 + + Code 0 + + Checksum The ICMP checksum. See [ICMPv6]. + + Reserved This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + Valid Options: + + Source link-layer address The link-layer address of the sender, if + known. MUST NOT be included if the Source Address + is the unspecified address. Otherwise, it SHOULD + be included on link layers that have addresses. + + Future versions of this protocol may define new option types. + Receivers MUST silently ignore any options they do not recognize + and continue processing the message. + +4.2. Router Advertisement Message Format + + Routers send out Router Advertisement messages periodically, or in + response to Router Solicitations. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Cur Hop Limit |M|O| Reserved | Router Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reachable Time | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Retrans Timer | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + IP Fields: + + Source Address + MUST be the link-local address assigned to the + interface from which this message is sent. + + + + + +Narten, et al. Standards Track [Page 19] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Destination Address + Typically the Source Address of an invoking Router + Solicitation or the all-nodes multicast address. + + Hop Limit 255 + + ICMP Fields: + + Type 134 + + Code 0 + + Checksum The ICMP checksum. See [ICMPv6]. + + Cur Hop Limit 8-bit unsigned integer. The default value that + should be placed in the Hop Count field of the IP + header for outgoing IP packets. A value of zero + means unspecified (by this router). + + M 1-bit "Managed address configuration" flag. When + set, it indicates that addresses are available via + Dynamic Host Configuration Protocol [DHCPv6]. + + If the M flag is set, the O flag is redundant and + can be ignored because DHCPv6 will return all + available configuration information. + + O 1-bit "Other configuration" flag. When set, it + indicates that other configuration information is + available via DHCPv6. Examples of such information + are DNS-related information or information on other + servers within the network. + + Note: If neither M nor O flags are set, this indicates that no + information is available via DHCPv6. + + Reserved A 6-bit unused field. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Router Lifetime + 16-bit unsigned integer. The lifetime associated + with the default router in units of seconds. The + field can contain values up to 65535 and receivers + should handle any value, while the sending rules in + Section 6 limit the lifetime to 9000 seconds. A + Lifetime of 0 indicates that the router is not a + default router and SHOULD NOT appear on the default + + + +Narten, et al. Standards Track [Page 20] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + router list. The Router Lifetime applies only to + the router's usefulness as a default router; it + does not apply to information contained in other + message fields or options. Options that need time + limits for their information include their own + lifetime fields. + + Reachable Time 32-bit unsigned integer. The time, in + milliseconds, that a node assumes a neighbor is + reachable after having received a reachability + confirmation. Used by the Neighbor Unreachability + Detection algorithm (see Section 7.3). A value of + zero means unspecified (by this router). + + Retrans Timer 32-bit unsigned integer. The time, in + milliseconds, between retransmitted Neighbor + Solicitation messages. Used by address resolution + and the Neighbor Unreachability Detection algorithm + (see Sections 7.2 and 7.3). A value of zero means + unspecified (by this router). + + Possible options: + + Source link-layer address + The link-layer address of the interface from which + the Router Advertisement is sent. Only used on + link layers that have addresses. A router MAY omit + this option in order to enable inbound load sharing + across multiple link-layer addresses. + + MTU SHOULD be sent on links that have a variable MTU + (as specified in the document that describes how to + run IP over the particular link type). MAY be sent + on other links. + + Prefix Information + These options specify the prefixes that are on-link + and/or are used for stateless address + autoconfiguration. A router SHOULD include all its + on-link prefixes (except the link-local prefix) so + that multihomed hosts have complete prefix + information about on-link destinations for the + links to which they attach. If complete + information is lacking, a host with multiple + interfaces may not be able to choose the correct + outgoing interface when sending traffic to its + neighbors. + + + + +Narten, et al. Standards Track [Page 21] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Future versions of this protocol may define new option types. + Receivers MUST silently ignore any options they do not recognize + and continue processing the message. + +4.3. Neighbor Solicitation Message Format + + Nodes send Neighbor Solicitations to request the link-layer address + of a target node while also providing their own link-layer address to + the target. Neighbor Solicitations are multicast when the node needs + to resolve an address and unicast when the node seeks to verify the + reachability of a neighbor. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + IP Fields: + + Source Address + Either an address assigned to the interface from + which this message is sent or (if Duplicate Address + Detection is in progress [ADDRCONF]) the + unspecified address. + Destination Address + Either the solicited-node multicast address + corresponding to the target address, or the target + address. + Hop Limit 255 + + ICMP Fields: + + Type 135 + + Code 0 + + + +Narten, et al. Standards Track [Page 22] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Checksum The ICMP checksum. See [ICMPv6]. + + Reserved This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Target Address The IP address of the target of the solicitation. + It MUST NOT be a multicast address. + + Possible options: + + Source link-layer address + The link-layer address for the sender. MUST NOT be + included when the source IP address is the + unspecified address. Otherwise, on link layers + that have addresses this option MUST be included in + multicast solicitations and SHOULD be included in + unicast solicitations. + + Future versions of this protocol may define new option types. + Receivers MUST silently ignore any options they do not recognize + and continue processing the message. + +4.4. Neighbor Advertisement Message Format + + A node sends Neighbor Advertisements in response to Neighbor + Solicitations and sends unsolicited Neighbor Advertisements in order + to (unreliably) propagate new information quickly. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + |R|S|O| Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + + + + +Narten, et al. Standards Track [Page 23] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + IP Fields: + + Source Address + An address assigned to the interface from which the + advertisement is sent. + Destination Address + For solicited advertisements, the Source Address of + an invoking Neighbor Solicitation or, if the + solicitation's Source Address is the unspecified + address, the all-nodes multicast address. + + For unsolicited advertisements typically the all- + nodes multicast address. + + Hop Limit 255 + + ICMP Fields: + + Type 136 + + Code 0 + + Checksum The ICMP checksum. See [ICMPv6]. + + R Router flag. When set, the R-bit indicates that + the sender is a router. The R-bit is used by + Neighbor Unreachability Detection to detect a + router that changes to a host. + + S Solicited flag. When set, the S-bit indicates that + the advertisement was sent in response to a + Neighbor Solicitation from the Destination address. + The S-bit is used as a reachability confirmation + for Neighbor Unreachability Detection. It MUST NOT + be set in multicast advertisements or in + unsolicited unicast advertisements. + + O Override flag. When set, the O-bit indicates that + the advertisement should override an existing cache + entry and update the cached link-layer address. + When it is not set the advertisement will not + update a cached link-layer address though it will + update an existing Neighbor Cache entry for which + no link-layer address is known. It SHOULD NOT be + set in solicited advertisements for anycast + addresses and in solicited proxy advertisements. + It SHOULD be set in other solicited advertisements + and in unsolicited advertisements. + + + +Narten, et al. Standards Track [Page 24] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Reserved 29-bit unused field. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Target Address + For solicited advertisements, the Target Address + field in the Neighbor Solicitation message that + prompted this advertisement. For an unsolicited + advertisement, the address whose link-layer address + has changed. The Target Address MUST NOT be a + multicast address. + + Possible options: + + Target link-layer address + The link-layer address for the target, i.e., the + sender of the advertisement. This option MUST be + included on link layers that have addresses when + responding to multicast solicitations. When + responding to a unicast Neighbor Solicitation this + option SHOULD be included. + + The option MUST be included for multicast + solicitations in order to avoid infinite Neighbor + Solicitation "recursion" when the peer node does + not have a cache entry to return a Neighbor + Advertisements message. When responding to unicast + solicitations, the option can be omitted since the + sender of the solicitation has the correct link- + layer address; otherwise, it would not be able to + send the unicast solicitation in the first place. + However, including the link-layer address in this + case adds little overhead and eliminates a + potential race condition where the sender deletes + the cached link-layer address prior to receiving a + response to a previous solicitation. + + Future versions of this protocol may define new option types. + Receivers MUST silently ignore any options they do not recognize + and continue processing the message. + + + + + + + + + + + +Narten, et al. Standards Track [Page 25] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +4.5. Redirect Message Format + + Routers send Redirect packets to inform a host of a better first-hop + node on the path to a destination. Hosts can be redirected to a + better first-hop router but can also be informed by a redirect that + the destination is in fact a neighbor. The latter is accomplished by + setting the ICMP Target Address equal to the ICMP Destination + Address. + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Code | Checksum | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Target Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Destination Address + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Options ... + +-+-+-+-+-+-+-+-+-+-+-+- + + IP Fields: + + Source Address + MUST be the link-local address assigned to the + interface from which this message is sent. + + Destination Address + The Source Address of the packet that triggered the + redirect. + + Hop Limit 255 + + + + + +Narten, et al. Standards Track [Page 26] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + ICMP Fields: + + Type 137 + + Code 0 + + Checksum The ICMP checksum. See [ICMPv6]. + + Reserved This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Target Address + An IP address that is a better first hop to use for + the ICMP Destination Address. When the target is + the actual endpoint of communication, i.e., the + destination is a neighbor, the Target Address field + MUST contain the same value as the ICMP Destination + Address field. Otherwise, the target is a better + first-hop router and the Target Address MUST be the + router's link-local address so that hosts can + uniquely identify routers. + + Destination Address + The IP address of the destination that is + redirected to the target. + + Possible options: + + Target link-layer address + The link-layer address for the target. It SHOULD + be included (if known). Note that on NBMA links, + hosts may rely on the presence of the Target Link- + Layer Address option in Redirect messages as the + means for determining the link-layer addresses of + neighbors. In such cases, the option MUST be + included in Redirect messages. + + Redirected Header + As much as possible of the IP packet that triggered + the sending of the Redirect without making the + redirect packet exceed the minimum MTU specified in + [IPv6]. + + + + + + + + +Narten, et al. Standards Track [Page 27] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +4.6. Option Formats + + Neighbor Discovery messages include zero or more options, some of + which may appear multiple times in the same message. Options should + be padded when necessary to ensure that they end on their natural + 64-bit boundaries. All options are of the form: + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | ... | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + ~ ... ~ + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type 8-bit identifier of the type of option. The + options defined in this document are: + + Option Name Type + + Source Link-Layer Address 1 + Target Link-Layer Address 2 + Prefix Information 3 + Redirected Header 4 + MTU 5 + + Length 8-bit unsigned integer. The length of the option + (including the type and length fields) in units of + 8 octets. The value 0 is invalid. Nodes MUST + silently discard an ND packet that contains an + option with length zero. + +4.6.1. Source/Target Link-layer Address + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Link-Layer Address ... + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type + 1 for Source Link-layer Address + 2 for Target Link-layer Address + + + + +Narten, et al. Standards Track [Page 28] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Length The length of the option (including the type and + length fields) in units of 8 octets. For example, + the length for IEEE 802 addresses is 1 + [IPv6-ETHER]. + + Link-Layer Address + The variable length link-layer address. + + The content and format of this field (including + byte and bit ordering) is expected to be specified + in specific documents that describe how IPv6 + operates over different link layers. For instance, + [IPv6-ETHER]. + + Description + The Source Link-Layer Address option contains the + link-layer address of the sender of the packet. It + is used in the Neighbor Solicitation, Router + Solicitation, and Router Advertisement packets. + + The Target Link-Layer Address option contains the + link-layer address of the target. It is used in + Neighbor Advertisement and Redirect packets. + + These options MUST be silently ignored for other + Neighbor Discovery messages. + +4.6.2. Prefix Information + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Prefix Length |L|A| Reserved1 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Valid Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Preferred Lifetime | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved2 | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + + + + | | + + Prefix + + | | + + + + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + + +Narten, et al. Standards Track [Page 29] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Fields: + + Type 3 + + Length 4 + + Prefix Length 8-bit unsigned integer. The number of leading bits + in the Prefix that are valid. The value ranges + from 0 to 128. The prefix length field provides + necessary information for on-link determination + (when combined with the L flag in the prefix + information option). It also assists with address + autoconfiguration as specified in [ADDRCONF], for + which there may be more restrictions on the prefix + length. + + L 1-bit on-link flag. When set, indicates that this + prefix can be used for on-link determination. When + not set the advertisement makes no statement about + on-link or off-link properties of the prefix. In + other words, if the L flag is not set a host MUST + NOT conclude that an address derived from the + prefix is off-link. That is, it MUST NOT update a + previous indication that the address is on-link. + + A 1-bit autonomous address-configuration flag. When + set indicates that this prefix can be used for + stateless address configuration as specified in + [ADDRCONF]. + + Reserved1 6-bit unused field. It MUST be initialized to zero + by the sender and MUST be ignored by the receiver. + + Valid Lifetime + 32-bit unsigned integer. The length of time in + seconds (relative to the time the packet is sent) + that the prefix is valid for the purpose of on-link + determination. A value of all one bits + (0xffffffff) represents infinity. The Valid + Lifetime is also used by [ADDRCONF]. + + Preferred Lifetime + 32-bit unsigned integer. The length of time in + seconds (relative to the time the packet is sent) + that addresses generated from the prefix via + stateless address autoconfiguration remain + preferred [ADDRCONF]. A value of all one bits + (0xffffffff) represents infinity. See [ADDRCONF]. + + + +Narten, et al. Standards Track [Page 30] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Note that the value of this field MUST NOT exceed + the Valid Lifetime field to avoid preferring + addresses that are no longer valid. + + Reserved2 This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + Prefix An IP address or a prefix of an IP address. The + Prefix Length field contains the number of valid + leading bits in the prefix. The bits in the prefix + after the prefix length are reserved and MUST be + initialized to zero by the sender and ignored by + the receiver. A router SHOULD NOT send a prefix + option for the link-local prefix and a host SHOULD + ignore such a prefix option. + + Description + The Prefix Information option provide hosts with + on-link prefixes and prefixes for Address + Autoconfiguration. The Prefix Information option + appears in Router Advertisement packets and MUST be + silently ignored for other messages. + +4.6.3. Redirected Header + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | | + ~ IP header + data ~ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type 4 + + Length The length of the option in units of 8 octets. + + Reserved These fields are unused. They MUST be initialized + to zero by the sender and MUST be ignored by the + receiver. + + + + +Narten, et al. Standards Track [Page 31] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + IP header + data + The original packet truncated to ensure that the + size of the redirect message does not exceed the + minimum MTU required to support IPv6 as specified + in [IPv6]. + + Description + The Redirected Header option is used in Redirect + messages and contains all or part of the packet + that is being redirected. + + This option MUST be silently ignored for other + Neighbor Discovery messages. + +4.6.4. MTU + + 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 + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Type | Length | Reserved | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | MTU | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + + Fields: + + Type 5 + + Length 1 + + Reserved This field is unused. It MUST be initialized to + zero by the sender and MUST be ignored by the + receiver. + + MTU 32-bit unsigned integer. The recommended MTU for + the link. + + Description + The MTU option is used in Router Advertisement + messages to ensure that all nodes on a link use the + same MTU value in those cases where the link MTU is + not well known. + + This option MUST be silently ignored for other + Neighbor Discovery messages. + + + + + + +Narten, et al. Standards Track [Page 32] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + In configurations in which heterogeneous + technologies are bridged together, the maximum + supported MTU may differ from one segment to + another. If the bridges do not generate ICMP + Packet Too Big messages, communicating nodes will + be unable to use Path MTU to dynamically determine + the appropriate MTU on a per-neighbor basis. In + such cases, routers can be configured to use the + MTU option to specify the maximum MTU value that is + supported by all segments. + +5. Conceptual Model of a Host + + This section describes a conceptual model of one possible data + structure organization that hosts (and, to some extent, routers) will + maintain in interacting with neighboring nodes. The described + organization is provided to facilitate the explanation of how the + Neighbor Discovery protocol should behave. This document does not + mandate that implementations adhere to this model as long as their + external behavior is consistent with that described in this document. + + This model is only concerned with the aspects of host behavior + directly related to Neighbor Discovery. In particular, it does not + concern itself with such issues as source address selection or the + selecting of an outgoing interface on a multihomed host. + +5.1. Conceptual Data Structures + + Hosts will need to maintain the following pieces of information for + each interface: + + Neighbor Cache + - A set of entries about individual neighbors to + which traffic has been sent recently. Entries are + keyed on the neighbor's on-link unicast IP address + and contain such information as its link-layer + address, a flag indicating whether the neighbor is + a router or a host (called IsRouter in this + document), a pointer to any queued packets waiting + for address resolution to complete, etc. A + Neighbor Cache entry also contains information used + by the Neighbor Unreachability Detection algorithm, + including the reachability state, the number of + unanswered probes, and the time the next Neighbor + Unreachability Detection event is scheduled to take + place. + + + + + +Narten, et al. Standards Track [Page 33] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Destination Cache + - A set of entries about destinations to which + traffic has been sent recently. The Destination + Cache includes both on-link and off-link + destinations and provides a level of indirection + into the Neighbor Cache; the Destination Cache maps + a destination IP address to the IP address of the + next-hop neighbor. This cache is updated with + information learned from Redirect messages. + Implementations may find it convenient to store + additional information not directly related to + Neighbor Discovery in Destination Cache entries, + such as the Path MTU (PMTU) and round-trip timers + maintained by transport protocols. + + Prefix List - A list of the prefixes that define a set of + addresses that are on-link. Prefix List entries + are created from information received in Router + Advertisements. Each entry has an associated + invalidation timer value (extracted from the + advertisement) used to expire prefixes when they + become invalid. A special "infinity" timer value + specifies that a prefix remains valid forever, + unless a new (finite) value is received in a + subsequent advertisement. + + The link-local prefix is considered to be on the + prefix list with an infinite invalidation timer + regardless of whether routers are advertising a + prefix for it. Received Router Advertisements + SHOULD NOT modify the invalidation timer for the + link-local prefix. + + Default Router List + - A list of routers to which packets may be sent. + Router list entries point to entries in the + Neighbor Cache; the algorithm for selecting a + default router favors routers known to be reachable + over those whose reachability is suspect. Each + entry also has an associated invalidation timer + value (extracted from Router Advertisements) used + to delete entries that are no longer advertised. + + + + + + + + + +Narten, et al. Standards Track [Page 34] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Note that the above conceptual data structures can be implemented + using a variety of techniques. One possible implementation is to use + a single longest-match routing table for all of the above data + structures. Regardless of the specific implementation, it is + critical that the Neighbor Cache entry for a router is shared by all + Destination Cache entries using that router in order to prevent + redundant Neighbor Unreachability Detection probes. + + Note also that other protocols (e.g., Mobile IPv6) might add + additional conceptual data structures. An implementation is at + liberty to implement such data structures in any way it pleases. For + example, an implementation could merge all conceptual data structures + into a single routing table. + + The Neighbor Cache contains information maintained by the Neighbor + Unreachability Detection algorithm. A key piece of information is a + neighbor's reachability state, which is one of five possible values. + The following definitions are informal; precise definitions can be + found in Section 7.3.2. + + INCOMPLETE Address resolution is in progress and the link-layer + address of the neighbor has not yet been determined. + + REACHABLE Roughly speaking, the neighbor is known to have been + reachable recently (within tens of seconds ago). + + STALE The neighbor is no longer known to be reachable but + until traffic is sent to the neighbor, no attempt + should be made to verify its reachability. + + DELAY The neighbor is no longer known to be reachable, and + traffic has recently been sent to the neighbor. + Rather than probe the neighbor immediately, however, + delay sending probes for a short while in order to + give upper-layer protocols a chance to provide + reachability confirmation. + + PROBE The neighbor is no longer known to be reachable, and + unicast Neighbor Solicitation probes are being sent to + verify reachability. + + + + + + + + + + + +Narten, et al. Standards Track [Page 35] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +5.2. Conceptual Sending Algorithm + + When sending a packet to a destination, a node uses a combination of + the Destination Cache, the Prefix List, and the Default Router List + to determine the IP address of the appropriate next hop, an operation + known as "next-hop determination". Once the IP address of the next + hop is known, the Neighbor Cache is consulted for link-layer + information about that neighbor. + + Next-hop determination for a given unicast destination operates as + follows. The sender performs a longest prefix match against the + Prefix List to determine whether the packet's destination is on- or + off-link. If the destination is on-link, the next-hop address is the + same as the packet's destination address. Otherwise, the sender + selects a router from the Default Router List (following the rules + described in Section 6.3.6). + + For efficiency reasons, next-hop determination is not performed on + every packet that is sent. Instead, the results of next-hop + determination computations are saved in the Destination Cache (which + also contains updates learned from Redirect messages). When the + sending node has a packet to send, it first examines the Destination + Cache. If no entry exists for the destination, next-hop + determination is invoked to create a Destination Cache entry. + + Once the IP address of the next-hop node is known, the sender + examines the Neighbor Cache for link-layer information about that + neighbor. If no entry exists, the sender creates one, sets its state + to INCOMPLETE, initiates Address Resolution, and then queues the data + packet pending completion of address resolution. For multicast- + capable interfaces Address Resolution consists of sending a Neighbor + Solicitation message and waiting for a Neighbor Advertisement. When + a Neighbor Advertisement response is received, the link-layer + addresses is entered in the Neighbor Cache entry and the queued + packet is transmitted. The address resolution mechanism is described + in detail in Section 7.2. + + For multicast packets, the next-hop is always the (multicast) + destination address and is considered to be on-link. The procedure + for determining the link-layer address corresponding to a given IP + multicast address can be found in a separate document that covers + operating IP over a particular link type (e.g., [IPv6-ETHER]). + + + + + + + + + +Narten, et al. Standards Track [Page 36] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Each time a Neighbor Cache entry is accessed while transmitting a + unicast packet, the sender checks Neighbor Unreachability Detection + related information according to the Neighbor Unreachability + Detection algorithm (Section 7.3). This unreachability check might + result in the sender transmitting a unicast Neighbor Solicitation to + verify that the neighbor is still reachable. + + Next-hop determination is done the first time traffic is sent to a + destination. As long as subsequent communication to that destination + proceeds successfully, the Destination Cache entry continues to be + used. If at some point communication ceases to proceed, as + determined by the Neighbor Unreachability Detection algorithm, next- + hop determination may need to be performed again. For example, + traffic through a failed router should be switched to a working + router. Likewise, it may be possible to reroute traffic destined for + a mobile node to a "mobility agent". + + Note that when a node redoes next-hop determination there is no need + to discard the complete Destination Cache entry. In fact, it is + generally beneficial to retain such cached information as the PMTU + and round-trip timer values that may also be kept in the Destination + Cache entry. + + Routers and multihomed hosts have multiple interfaces. The remainder + of this document assumes that all sent and received Neighbor + Discovery messages refer to the interface of appropriate context. + For example, when responding to a Router Solicitation, the + corresponding Router Advertisement is sent out the interface on which + the solicitation was received. + +5.3. Garbage Collection and Timeout Requirements + + The conceptual data structures described above use different + mechanisms for discarding potentially stale or unused information. + + From the perspective of correctness, there is no need to periodically + purge Destination and Neighbor Cache entries. Although stale + information can potentially remain in the cache indefinitely, the + Neighbor Unreachability Detection algorithm ensures that stale + information is purged quickly if it is actually being used. + + To limit the storage needed for the Destination and Neighbor Caches, + a node may need to garbage-collect old entries. However, care must + be taken to ensure that sufficient space is always present to hold + the working set of active entries. A small cache may result in an + excessive number of Neighbor Discovery messages if entries are + discarded and rebuilt in quick succession. Any Least Recently Used + (LRU)-based policy that only reclaims entries that have not been used + + + +Narten, et al. Standards Track [Page 37] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + in some time (e.g., ten minutes or more) should be adequate for + garbage-collecting unused entries. + + A node should retain entries in the Default Router List and the + Prefix List until their lifetimes expire. However, a node may + garbage-collect entries prematurely if it is low on memory. If not + all routers are kept on the Default Router list, a node should retain + at least two entries in the Default Router List (and preferably more) + in order to maintain robust connectivity for off-link destinations. + + When removing an entry from the Prefix List, there is no need to + purge any entries from the Destination or Neighbor Caches. Neighbor + Unreachability Detection will efficiently purge any entries in these + caches that have become invalid. When removing an entry from the + Default Router List, however, any entries in the Destination Cache + that go through that router must perform next-hop determination again + to select a new default router. + +6. Router and Prefix Discovery + + This section describes router and host behavior related to the Router + Discovery portion of Neighbor Discovery. Router Discovery is used to + locate neighboring routers as well as learn prefixes and + configuration parameters related to stateless address + autoconfiguration. + + Prefix Discovery is the process through which hosts learn the ranges + of IP addresses that reside on-link and can be reached directly + without going through a router. Routers send Router Advertisements + that indicate whether the sender is willing to be a default router. + Router Advertisements also contain Prefix Information options that + list the set of prefixes that identify on-link IP addresses. + + Stateless Address Autoconfiguration must also obtain subnet prefixes + as part of configuring addresses. Although the prefixes used for + address autoconfiguration are logically distinct from those used for + on-link determination, autoconfiguration information is piggybacked + on Router Discovery messages to reduce network traffic. Indeed, the + same prefixes can be advertised for on-link determination and address + autoconfiguration by specifying the appropriate flags in the Prefix + Information options. See [ADDRCONF] for details on how + autoconfiguration information is processed. + + + + + + + + + +Narten, et al. Standards Track [Page 38] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +6.1. Message Validation + +6.1.1. Validation of Router Solicitation Messages + + Hosts MUST silently discard any received Router Solicitation + Messages. + + A router MUST silently discard any received Router Solicitation + messages that do not satisfy all of the following validity checks: + + - The IP Hop Limit field has a value of 255, i.e., the packet + could not possibly have been forwarded by a router. + + - ICMP Checksum is valid. + + - ICMP Code is 0. + + - ICMP length (derived from the IP length) is 8 or more octets. + + - All included options have a length that is greater than zero. + + - If the IP source address is the unspecified address, there is no + source link-layer address option in the message. + + The contents of the Reserved field, and of any unrecognized options, + MUST be ignored. Future, backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + The contents of any defined options that are not specified to be used + with Router Solicitation messages MUST be ignored and the packet + processed as normal. The only defined option that may appear is the + Source Link-Layer Address option. + + A solicitation that passes the validity checks is called a "valid + solicitation". + +6.1.2. Validation of Router Advertisement Messages + + A node MUST silently discard any received Router Advertisement + messages that do not satisfy all of the following validity checks: + + - IP Source Address is a link-local address. Routers must use + their link-local address as the source for Router Advertisement + and Redirect messages so that hosts can uniquely identify + routers. + + + + + +Narten, et al. Standards Track [Page 39] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - The IP Hop Limit field has a value of 255, i.e., the packet + could not possibly have been forwarded by a router. + + - ICMP Checksum is valid. + + - ICMP Code is 0. + + - ICMP length (derived from the IP length) is 16 or more octets. + + - All included options have a length that is greater than zero. + + The contents of the Reserved field, and of any unrecognized options, + MUST be ignored. Future, backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + The contents of any defined options that are not specified to be used + with Router Advertisement messages MUST be ignored and the packet + processed as normal. The only defined options that may appear are + the Source Link-Layer Address, Prefix Information and MTU options. + + An advertisement that passes the validity checks is called a "valid + advertisement". + +6.2. Router Specification + +6.2.1. Router Configuration Variables + + A router MUST allow for the following conceptual variables to be + configured by system management. The specific variable names are + used for demonstration purposes only, and an implementation is not + required to have them, so long as its external behavior is consistent + with that described in this document. Default values are specified + to simplify configuration in common cases. + + The default values for some of the variables listed below may be + overridden by specific documents that describe how IPv6 operates over + different link layers. This rule simplifies the configuration of + Neighbor Discovery over link types with widely differing performance + characteristics. + + + + + + + + + + + +Narten, et al. Standards Track [Page 40] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + For each interface: + + IsRouter A flag indicating whether routing is enabled on + this interface. Enabling routing on the interface + would imply that a router can forward packets to or + from the interface. + + Default: FALSE + + AdvSendAdvertisements + A flag indicating whether or not the router sends + periodic Router Advertisements and responds to + Router Solicitations. + + Default: FALSE + + Note that AdvSendAdvertisements MUST be FALSE by + default so that a node will not accidentally start + acting as a router unless it is explicitly + configured by system management to send Router + Advertisements. + + MaxRtrAdvInterval + The maximum time allowed between sending + unsolicited multicast Router Advertisements from + the interface, in seconds. MUST be no less than 4 + seconds and no greater than 1800 seconds. + + Default: 600 seconds + + MinRtrAdvInterval + The minimum time allowed between sending + unsolicited multicast Router Advertisements from + the interface, in seconds. MUST be no less than 3 + seconds and no greater than .75 * + MaxRtrAdvInterval. + + Default: 0.33 * MaxRtrAdvInterval If + MaxRtrAdvInterval >= 9 seconds; otherwise, the + Default is MaxRtrAdvInterval. + + AdvManagedFlag + The TRUE/FALSE value to be placed in the "Managed + address configuration" flag field in the Router + Advertisement. See [ADDRCONF]. + + Default: FALSE + + + + +Narten, et al. Standards Track [Page 41] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + AdvOtherConfigFlag + The TRUE/FALSE value to be placed in the "Other + configuration" flag field in the Router + Advertisement. See [ADDRCONF]. + + Default: FALSE + + AdvLinkMTU The value to be placed in MTU options sent by the + router. A value of zero indicates that no MTU + options are sent. + + Default: 0 + + AdvReachableTime + The value to be placed in the Reachable Time field + in the Router Advertisement messages sent by the + router. The value zero means unspecified (by this + router). MUST be no greater than 3,600,000 + milliseconds (1 hour). + + Default: 0 + + AdvRetransTimer The value to be placed in the Retrans Timer field + in the Router Advertisement messages sent by the + router. The value zero means unspecified (by this + router). + + Default: 0 + + AdvCurHopLimit + The default value to be placed in the Cur Hop Limit + field in the Router Advertisement messages sent by + the router. The value should be set to the current + diameter of the Internet. The value zero means + unspecified (by this router). + + Default: The value specified in the "Assigned + Numbers" [ASSIGNED] that was in effect at the time + of implementation. + + + + + + + + + + + + +Narten, et al. Standards Track [Page 42] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + AdvDefaultLifetime + The value to be placed in the Router Lifetime field + of Router Advertisements sent from the interface, + in seconds. MUST be either zero or between + MaxRtrAdvInterval and 9000 seconds. A value of + zero indicates that the router is not to be used as + a default router. These limits may be overridden + by specific documents that describe how IPv6 + operates over different link layers. For instance, + in a point-to-point link the peers may have enough + information about the number and status of devices + at the other end so that advertisements are needed + less frequently. + + Default: 3 * MaxRtrAdvInterval + + AdvPrefixList + A list of prefixes to be placed in Prefix + Information options in Router Advertisement + messages sent from the interface. + + Default: all prefixes that the router advertises + via routing protocols as being on-link for the + interface from which the advertisement is sent. + The link-local prefix SHOULD NOT be included in the + list of advertised prefixes. + + Each prefix has an associated: + + AdvValidLifetime + The value to be placed in the Valid + Lifetime in the Prefix Information option, + in seconds. The designated value of all + 1's (0xffffffff) represents infinity. + Implementations MAY allow AdvValidLifetime + to be specified in two ways: + + - a time that decrements in real time, + that is, one that will result in a + Lifetime of zero at the specified time + in the future, or + + - a fixed time that stays the same in + consecutive advertisements. + + Default: 2592000 seconds (30 days), fixed + (i.e., stays the same in consecutive + advertisements). + + + +Narten, et al. Standards Track [Page 43] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + AdvOnLinkFlag + The value to be placed in the on-link flag + ("L-bit") field in the Prefix Information + option. + + Default: TRUE + + Stateless address configuration [ADDRCONF] defines + additional information associated with each of the + prefixes: + + AdvPreferredLifetime + The value to be placed in the Preferred + Lifetime in the Prefix Information option, + in seconds. The designated value of all + 1's (0xffffffff) represents infinity. See + [ADDRCONF] for details on how this value is + used. Implementations MAY allow + AdvPreferredLifetime to be specified in two + ways: + + - a time that decrements in real time, + that is, one that will result in a + Lifetime of zero at a specified time in + the future, or + + - a fixed time that stays the same in + consecutive advertisements. + + Default: 604800 seconds (7 days), fixed + (i.e., stays the same in consecutive + advertisements). This value MUST NOT be + larger than AdvValidLifetime. + + AdvAutonomousFlag + The value to be placed in the Autonomous + Flag field in the Prefix Information + option. See [ADDRCONF]. + + Default: TRUE + + The above variables contain information that is placed in outgoing + Router Advertisement messages. Hosts use the received information to + initialize a set of analogous variables that control their external + behavior (see Section 6.3.2). Some of these host variables (e.g., + CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes + including routers. In practice, these variables may not actually be + present on routers, since their contents can be derived from the + + + +Narten, et al. Standards Track [Page 44] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + variables described above. However, external router behavior MUST be + the same as host behavior with respect to these variables. In + particular, this includes the occasional randomization of the + ReachableTime value as described in Section 6.3.2. + + Protocol constants are defined in Section 10. + +6.2.2. Becoming an Advertising Interface + + The term "advertising interface" refers to any functioning and + enabled interface that has at least one unicast IP address assigned + to it and whose corresponding AdvSendAdvertisements flag is TRUE. A + router MUST NOT send Router Advertisements out any interface that is + not an advertising interface. + + An interface may become an advertising interface at times other than + system startup. For example: + + - changing the AdvSendAdvertisements flag on an enabled interface + from FALSE to TRUE, or + + - administratively enabling the interface, if it had been + administratively disabled, and its AdvSendAdvertisements flag is + TRUE, or + + - enabling IP forwarding capability (i.e., changing the system + from being a host to being a router), when the interface's + AdvSendAdvertisements flag is TRUE. + + A router MUST join the all-routers multicast address on an + advertising interface. Routers respond to Router Solicitations sent + to the all-routers address and verify the consistency of Router + Advertisements sent by neighboring routers. + +6.2.3. Router Advertisement Message Content + + A router sends periodic as well as solicited Router Advertisements + out its advertising interfaces. Outgoing Router Advertisements are + filled with the following values consistent with the message format + given in Section 4.2: + + - In the Router Lifetime field: the interface's configured + AdvDefaultLifetime. + + - In the M and O flags: the interface's configured AdvManagedFlag + and AdvOtherConfigFlag, respectively. + + + + + +Narten, et al. Standards Track [Page 45] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - In the Cur Hop Limit field: the interface's configured + CurHopLimit. + + - In the Reachable Time field: the interface's configured + AdvReachableTime. + + - In the Retrans Timer field: the interface's configured + AdvRetransTimer. + + - In the options: + + o Source Link-Layer Address option: link-layer address of the + sending interface. This option MAY be omitted to + facilitate in-bound load balancing over replicated + interfaces. + + o MTU option: the interface's configured AdvLinkMTU value if + the value is non-zero. If AdvLinkMTU is zero, the MTU + option is not sent. + + o Prefix Information options: one Prefix Information option + for each prefix listed in AdvPrefixList with the option + fields set from the information in the AdvPrefixList entry + as follows: + + - In the "on-link" flag: the entry's AdvOnLinkFlag. + + - In the Valid Lifetime field: the entry's + AdvValidLifetime. + + - In the "Autonomous address configuration" flag: the + entry's AdvAutonomousFlag. + + - In the Preferred Lifetime field: the entry's + AdvPreferredLifetime. + + A router might want to send Router Advertisements without advertising + itself as a default router. For instance, a router might advertise + prefixes for stateless address autoconfiguration while not wishing to + forward packets. Such a router sets the Router Lifetime field in + outgoing advertisements to zero. + + A router MAY choose not to include some or all options when sending + unsolicited Router Advertisements. For example, if prefix lifetimes + are much longer than AdvDefaultLifetime, including them every few + advertisements may be sufficient. However, when responding to a + Router Solicitation or while sending the first few initial + + + + +Narten, et al. Standards Track [Page 46] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + unsolicited advertisements, a router SHOULD include all options so + that all information (e.g., prefixes) is propagated quickly during + system initialization. + + If including all options causes the size of an advertisement to + exceed the link MTU, multiple advertisements can be sent, each + containing a subset of the options. + +6.2.4. Sending Unsolicited Router Advertisements + + A host MUST NOT send Router Advertisement messages at any time. + + Unsolicited Router Advertisements are not strictly periodic: the + interval between subsequent transmissions is randomized to reduce the + probability of synchronization with the advertisements from other + routers on the same link [SYNC]. Each advertising interface has its + own timer. Whenever a multicast advertisement is sent from an + interface, the timer is reset to a uniformly distributed random value + between the interface's configured MinRtrAdvInterval and + MaxRtrAdvInterval; expiration of the timer causes the next + advertisement to be sent and a new random value to be chosen. + + For the first few advertisements (up to + MAX_INITIAL_RTR_ADVERTISEMENTS) sent from an interface when it + becomes an advertising interface, if the randomly chosen interval is + greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set + to MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval + for the initial advertisements increases the likelihood of a router + being discovered quickly when it first becomes available, in the + presence of possible packet loss. + + The information contained in Router Advertisements may change through + actions of system management. For instance, the lifetime of + advertised prefixes may change, new prefixes could be added, a router + could cease to be a router (i.e., switch from being a router to being + a host), etc. In such cases, the router MAY transmit up to + MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the + same rules as when an interface becomes an advertising interface. + +6.2.5. Ceasing To Be an Advertising Interface + + An interface may cease to be an advertising interface, through + actions of system management such as: + + - changing the AdvSendAdvertisements flag of an enabled interface + from TRUE to FALSE, or + + - administratively disabling the interface, or + + + +Narten, et al. Standards Track [Page 47] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - shutting down the system. + + In such cases, the router SHOULD transmit one or more (but not more + than MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router + Advertisements on the interface with a Router Lifetime field of zero. + 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 + which the router supports IP multicast (whether or not they had been + advertising interfaces). In addition, the host MUST ensure that + subsequent Neighbor Advertisement messages sent from the interface + have the Router flag set to zero. + + Note that system management may disable a router's IP forwarding + 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 + interfaces stop being advertising interfaces. In such cases, + subsequent Router Advertisements MUST set the Router Lifetime field + to zero. + +6.2.6. Processing Router Solicitations + + A host MUST silently discard any received Router Solicitation + messages. + + In addition to sending periodic, unsolicited advertisements, a router + sends advertisements in response to valid solicitations received on + an advertising interface. A router MAY choose to unicast the + response directly to the soliciting host's address (if the + solicitation's source address is not the unspecified address), but + the usual case is to multicast the response to the all-nodes group. + In the latter case, the interface's interval timer is reset to a new + random value, as if an unsolicited advertisement had just been sent + (see Section 6.2.4). + + In all cases, Router Advertisements sent in response to a Router + Solicitation MUST be delayed by a random time between 0 and + MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in + response to multiple solicitations, the delay is relative to the + first solicitation.) In addition, consecutive Router Advertisements + sent to the all-nodes multicast address MUST be rate limited to no + more than one advertisement every MIN_DELAY_BETWEEN_RAS seconds. + + + + + + + + + + +Narten, et al. Standards Track [Page 48] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + A router might process Router Solicitations as follows: + + - Upon receipt of a Router Solicitation, compute a random delay + within the range 0 through MAX_RA_DELAY_TIME. If the computed + value corresponds to a time later than the time the next multicast + Router Advertisement is scheduled to be sent, ignore the random + delay and send the advertisement at the already-scheduled time. + + - If the router sent a multicast Router Advertisement (solicited or + unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, + schedule the advertisement to be sent at a time corresponding to + MIN_DELAY_BETWEEN_RAS plus the random value after the previous + advertisement was sent. This ensures that the multicast Router + Advertisements are rate limited. + + - Otherwise, schedule the sending of a Router Advertisement at the + time given by the random value. + + Note that a router is permitted to send multicast Router + Advertisements more frequently than indicated by the + MinRtrAdvInterval configuration variable so long as the more frequent + advertisements are responses to Router Solicitations. In all cases, + however, unsolicited multicast advertisements MUST NOT be sent more + frequently than indicated by MinRtrAdvInterval. + + Router Solicitations in which the Source Address is the unspecified + address MUST NOT update the router's Neighbor Cache; solicitations + with a proper source address update the Neighbor Cache as follows. + If the router already has a Neighbor Cache entry for the + solicitation's sender, the solicitation contains a Source Link-Layer + Address option, and the received link-layer address differs from that + already in the cache, then the link-layer address SHOULD be updated + in the appropriate Neighbor Cache entry, and its reachability state + MUST also be set to STALE. If there is no existing Neighbor Cache + entry for the solicitation's sender, the router creates one, installs + the link- layer address and sets its reachability state to STALE as + specified in Section 7.3.3. If there is no existing Neighbor Cache + entry and no Source Link-Layer Address option was present in the + solicitation, the router may respond with either a multicast or a + unicast router advertisement. Whether or not a Source Link-Layer + Address option is provided, if a Neighbor Cache entry for the + solicitation's sender exists (or is created) the entry's IsRouter + flag MUST be set to FALSE. + + + + + + + + +Narten, et al. Standards Track [Page 49] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +6.2.7. Router Advertisement Consistency + + Routers SHOULD inspect valid Router Advertisements sent by other + routers and verify that the routers are advertising consistent + information on a link. Detected inconsistencies indicate that one or + more routers might be misconfigured and SHOULD be logged to system or + network management. The minimum set of information to check + includes: + + - Cur Hop Limit values (except for the unspecified value of zero + other inconsistencies SHOULD be logged to system network + management). + + - Values of the M or O flags. + + - Reachable Time values (except for the unspecified value of zero). + + - Retrans Timer values (except for the unspecified value of zero). + + - Values in the MTU options. + + - Preferred and Valid Lifetimes for the same prefix. If + AdvPreferredLifetime and/or AdvValidLifetime decrement in real + time as specified in Section 6.2.1 then the comparison of the + lifetimes cannot compare the content of the fields in the Router + Advertisement, but must instead compare the time at which the + prefix will become deprecated and invalidated, respectively. Due + to link propagation delays and potentially poorly synchronized + clocks between the routers such comparison SHOULD allow some time + skew. + + Note that it is not an error for different routers to advertise + different sets of prefixes. Also, some routers might leave some + fields as unspecified, i.e., with the value zero, while other routers + specify values. The logging of errors SHOULD be restricted to + conflicting information that causes hosts to switch from one value to + another with each received advertisement. + + Any other action on reception of Router Advertisement messages by a + router is beyond the scope of this document. + +6.2.8. Link-local Address Change + + The link-local address on a router should rarely change, if ever. + Nodes receiving Neighbor Discovery messages use the source address to + identify the sender. If multiple packets from the same router + contain different source addresses, nodes will assume they come from + different routers, leading to undesirable behavior. For example, a + + + +Narten, et al. Standards Track [Page 50] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + node will ignore Redirect messages that are believed to have been + sent by a router other than the current first-hop router. Thus, the + source address used in Router Advertisements sent by a particular + router must be identical to the target address in a Redirect message + when redirecting to that router. + + Using the link-local address to uniquely identify routers on the link + has the benefit that the address a router is known by should not + change when a site renumbers. + + If a router changes the link-local address for one of its interfaces, + it SHOULD inform hosts of this change. The router SHOULD multicast a + few Router Advertisements from the old link-local address with the + Router Lifetime field set to zero and also multicast a few Router + Advertisements from the new link-local address. The overall effect + should be the same as if one interface ceases being an advertising + interface, and a different one starts being an advertising interface. + +6.3. Host Specification + +6.3.1. Host Configuration Variables + + None. + +6.3.2. Host Variables + + A host maintains certain Neighbor-Discovery-related variables in + addition to the data structures defined in Section 5.1. The specific + variable names are used for demonstration purposes only, and an + implementation is not required to have them, so long as its external + behavior is consistent with that described in this document. + + These variables have default values that are overridden by + information received in Router Advertisement messages. The default + values are used when there is no router on the link or when all + received Router Advertisements have left a particular value + unspecified. + + The default values in this specification may be overridden by + specific documents that describe how IP operates over different link + layers. This rule allows Neighbor Discovery to operate over links + with widely varying performance characteristics. + + + + + + + + + +Narten, et al. Standards Track [Page 51] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + For each interface: + + LinkMTU The MTU of the link. + Default: The valued defined in the specific + document that describes how IPv6 operates over + the particular link layer (e.g., [IPv6-ETHER]). + + CurHopLimit The default hop limit to be used when sending IP + packets. + + Default: The value specified in the "Assigned + Numbers" [ASSIGNED] that was in effect at the + time of implementation. + + BaseReachableTime + A base value used for computing the random + ReachableTime value. + + Default: REACHABLE_TIME milliseconds. + + ReachableTime The time a neighbor is considered reachable after + receiving a reachability confirmation. + + This value should be a uniformly distributed + random value between MIN_RANDOM_FACTOR and + MAX_RANDOM_FACTOR times BaseReachableTime + milliseconds. A new random value should be + calculated when BaseReachableTime changes (due to + Router Advertisements) or at least every few + hours even if no Router Advertisements are + received. + + RetransTimer The time between retransmissions of Neighbor + Solicitation messages to a neighbor when + resolving the address or when probing the + reachability of a neighbor. + + Default: RETRANS_TIMER milliseconds + +6.3.3. Interface Initialization + + The host joins the all-nodes multicast address on all multicast- + capable interfaces. + + + + + + + + +Narten, et al. Standards Track [Page 52] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +6.3.4. Processing Received Router Advertisements + + When multiple routers are present, the information advertised + collectively by all routers may be a superset of the information + contained in a single Router Advertisement. Moreover, information + may also be obtained through other dynamic means like DHCPv6. Hosts + accept the union of all received information; the receipt of a Router + Advertisement MUST NOT invalidate all information received in a + previous advertisement or from another source. However, when + received information for a specific parameter (e.g., Link MTU) or + option (e.g., Lifetime on a specific Prefix) differs from information + received earlier, and the parameter/option can only have one value, + the most recently received information is considered authoritative. + + A Router Advertisement field (e.g., Cur Hop Limit, Reachable Time, + and Retrans Timer) may contain a value denoting that it is + unspecified. In such cases, the parameter should be ignored and the + host should continue using whatever value it is already using. In + particular, a host MUST NOT interpret the unspecified value as + meaning change back to the default value that was in use before the + first Router Advertisement was received. This rule prevents hosts + from continually changing an internal variable when one router + advertises a specific value, but other routers advertise the + unspecified value. + + On receipt of a valid Router Advertisement, a host extracts the + source address of the packet and does the following: + + - If the address is not already present in the host's Default + Router List, and the advertisement's Router Lifetime is non- + zero, create a new entry in the list, and initialize its + invalidation timer value from the advertisement's Router + Lifetime field. + + - If the address is already present in the host's Default Router + List as a result of a previously received advertisement, reset + its invalidation timer to the Router Lifetime value in the newly + received advertisement. + + - If the address is already present in the host's Default Router + List and the received Router Lifetime value is zero, immediately + time-out the entry as specified in Section 6.3.5. + + To limit the storage needed for the Default Router List, a host MAY + choose not to store all of the router addresses discovered via + advertisements. However, a host MUST retain at least two router + addresses and SHOULD retain more. Default router selections are made + whenever communication to a destination appears to be failing. Thus, + + + +Narten, et al. Standards Track [Page 53] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + the more routers on the list, the more likely an alternative working + router can be found quickly (e.g., without having to wait for the + next advertisement to arrive). + + If the received Cur Hop Limit value is non-zero, the host SHOULD set + its CurHopLimit variable to the received value. + + If the received Reachable Time value is non-zero, the host SHOULD set + its BaseReachableTime variable to the received value. If the new + value differs from the previous value, the host SHOULD re-compute a + new random ReachableTime value. ReachableTime is computed as a + uniformly distributed random value between MIN_RANDOM_FACTOR and + MAX_RANDOM_FACTOR times the BaseReachableTime. Using a random + component eliminates the possibility that Neighbor Unreachability + Detection messages will synchronize with each other. + + In most cases, the advertised Reachable Time value will be the same + in consecutive Router Advertisements, and a host's BaseReachableTime + rarely changes. In such cases, an implementation SHOULD ensure that + a new random value gets re-computed at least once every few hours. + + The RetransTimer variable SHOULD be copied from the Retrans Timer + field, if the received value is non-zero. + + After extracting information from the fixed part of the Router + Advertisement message, the advertisement is scanned for valid + options. If the advertisement contains a Source Link-Layer Address + option, the link-layer address SHOULD be recorded in the Neighbor + Cache entry for the router (creating an entry if necessary) and the + IsRouter flag in the Neighbor Cache entry MUST be set to TRUE. If no + Source Link-Layer Address is included, but a corresponding Neighbor + Cache entry exists, its IsRouter flag MUST be set to TRUE. The + IsRouter flag is used by Neighbor Unreachability Detection to + determine when a router changes to being a host (i.e., no longer + capable of forwarding packets). If a Neighbor Cache entry is created + for the router, its reachability state MUST be set to STALE as + specified in Section 7.3.3. If a cache entry already exists and is + updated with a different link-layer address, the reachability state + MUST also be set to STALE. + + If the MTU option is present, hosts SHOULD copy the option's value + into LinkMTU so long as the value is greater than or equal to the + minimum link MTU [IPv6] and does not exceed the maximum LinkMTU value + specified in the link-type-specific document (e.g., [IPv6-ETHER]). + + Prefix Information options that have the "on-link" (L) flag set + indicate a prefix identifying a range of addresses that should be + considered on-link. Note, however, that a Prefix Information option + + + +Narten, et al. Standards Track [Page 54] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + with the on-link flag set to zero conveys no information concerning + on-link determination and MUST NOT be interpreted to mean that + addresses covered by the prefix are off-link. The only way to cancel + a previous on-link indication is to advertise that prefix with the + L-bit set and the Lifetime set to zero. The default behavior (see + Section 5.2) when sending a packet to an address for which no + information is known about the on-link status of the address is to + forward the packet to a default router; the reception of a Prefix + Information option with the "on-link" (L) flag set to zero does not + change this behavior. The reasons for an address being treated as + on-link is specified in the definition of "on-link" in Section 2.1. + Prefixes with the on-link flag set to zero would normally have the + autonomous flag set and be used by [ADDRCONF]. + + For each Prefix Information option with the on-link flag set, a host + does the following: + + - If the prefix is the link-local prefix, silently ignore the + Prefix Information option. + + - If the prefix is not already present in the Prefix List, and the + Prefix Information option's Valid Lifetime field is non-zero, + create a new entry for the prefix and initialize its + invalidation timer to the Valid Lifetime value in the Prefix + Information option. + + - If the prefix is already present in the host's Prefix List as + the result of a previously received advertisement, reset its + invalidation timer to the Valid Lifetime value in the Prefix + Information option. If the new Lifetime value is zero, time-out + the prefix immediately (see Section 6.3.5). + + - If the Prefix Information option's Valid Lifetime field is zero, + and the prefix is not present in the host's Prefix List, + silently ignore the option. + + Stateless address autoconfiguration [ADDRCONF] may in some + circumstances use a larger Valid Lifetime of a prefix or ignore it + completely in order to prevent a particular denial-of-service attack. + However, since the effect of the same denial of service targeted at + the on-link prefix list is not catastrophic (hosts would send packets + to a default router and receive a redirect rather than sending + packets directly to a neighbor), the Neighbor Discovery protocol does + not impose such a check on the prefix lifetime values. Similarly, + [ADDRCONF] may impose certain restrictions on the prefix length for + address configuration purposes. Therefore, the prefix might be + rejected by [ADDRCONF] implementation in the host. However, the + + + + +Narten, et al. Standards Track [Page 55] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + prefix length is still valid for on-link determination when combined + with other flags in the prefix option. + + Note: Implementations can choose to process the on-link aspects of + the prefixes separately from the stateless address + autoconfiguration aspects of the prefixes by, e.g., passing a copy + of each valid Router Advertisement message to both an "on-link" + and an "addrconf" function. Each function can then operate + independently on the prefixes that have the appropriate flag set. + +6.3.5. Timing out Prefixes and Default Routers + + Whenever the invalidation timer expires for a Prefix List entry, that + entry is discarded. No existing Destination Cache entries need be + updated, however. Should a reachability problem arise with an + existing Neighbor Cache entry, Neighbor Unreachability Detection will + perform any needed recovery. + + Whenever the Lifetime of an entry in the Default Router List expires, + that entry is discarded. When removing a router from the Default + Router list, the node MUST update the Destination Cache in such a way + that all entries using the router perform next-hop determination + again rather than continue sending traffic to the (deleted) router. + +6.3.6. Default Router Selection + + The algorithm for selecting a router depends in part on whether or + not a router is known to be reachable. The exact details of how a + node keeps track of a neighbor's reachability state are covered in + Section 7.3. The algorithm for selecting a default router is invoked + during next-hop determination when no Destination Cache entry exists + for an off-link destination or when communication through an existing + router appears to be failing. Under normal conditions, a router + would be selected the first time traffic is sent to a destination, + with subsequent traffic for that destination using the same router as + indicated in the Destination Cache modulo any changes to the + Destination Cache caused by Redirect messages. + + The policy for selecting routers from the Default Router List is as + follows: + + 1) Routers that are reachable or probably reachable (i.e., in any + state other than INCOMPLETE) SHOULD be preferred over routers + whose reachability is unknown or suspect (i.e., in the + INCOMPLETE state, or for which no Neighbor Cache entry exists). + Further implementation hints on default router selection when + multiple equivalent routers are available are discussed in + [LD-SHRE]. + + + +Narten, et al. Standards Track [Page 56] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + 2) When no routers on the list are known to be reachable or + probably reachable, routers SHOULD be selected in a round-robin + fashion, so that subsequent requests for a default router do not + return the same router until all other routers have been + selected. + + Cycling through the router list in this case ensures that all + available routers are actively probed by the Neighbor + Unreachability Detection algorithm. A request for a default + router is made in conjunction with the sending of a packet to a + router, and the selected router will be probed for reachability + as a side effect. + +6.3.7. Sending Router Solicitations + + When an interface becomes enabled, a host may be unwilling to wait + for the next unsolicited Router Advertisement to locate default + routers or learn prefixes. To obtain Router Advertisements quickly, + a host SHOULD transmit up to MAX_RTR_SOLICITATIONS Router + Solicitation messages, each separated by at least + RTR_SOLICITATION_INTERVAL seconds. Router Solicitations may be sent + after any of the following events: + + - The interface is initialized at system startup time. + + - The interface is reinitialized after a temporary interface + failure or after being temporarily disabled by system + management. + + - The system changes from being a router to being a host, by + having its IP forwarding capability turned off by system + management. + + - The host attaches to a link for the first time. + + - The host re-attaches to a link after being detached for some + time. + + A host sends Router Solicitations to the all-routers multicast + address. The IP source address is set to either one of the + interface's unicast addresses or the unspecified address. The Source + Link-Layer Address option SHOULD be set to the host's link-layer + address, if the IP source address is not the unspecified address. + + Before a host sends an initial solicitation, it SHOULD delay the + transmission for a random amount of time between 0 and + MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when + many hosts start up on a link at the same time, such as might happen + + + +Narten, et al. Standards Track [Page 57] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + after recovery from a power failure. If a host has already performed + a random delay since the interface became (re)enabled (e.g., as part + of Duplicate Address Detection [ADDRCONF]), there is no need to delay + again before sending the first Router Solicitation message. + + In some cases, the random delay MAY be omitted if necessary. For + instance, a mobile node, using [MIPv6], moving to a new link would + need to discover such movement as soon as possible to minimize the + amount of packet losses resulting from the change in its topological + movement. Router Solicitations provide a useful tool for movement + detection in Mobile IPv6 as they allow mobile nodes to determine + movement to new links. Hence, if a mobile node received link-layer + information indicating that movement might have taken place, it MAY + send a Router Solicitation immediately, without random delays. The + strength of such indications should be assessed by the mobile node's + implementation depending on the level of certainty of the link-layer + hints, and it is outside the scope of this specification. Note that + using this mechanism inappropriately (e.g., based on weak or + transient indications) may result in Router Solicitation storms. + Furthermore, simultaneous mobility of a large number of mobile nodes + that use this mechanism can result in a large number of solicitations + sent simultaneously. + + Once the host sends a Router Solicitation, and receives a valid + Router Advertisement with a non-zero Router Lifetime, the host MUST + desist from sending additional solicitations on that interface, until + the next time one of the above events occurs. Moreover, a host + SHOULD send at least one solicitation in the case where an + advertisement is received prior to having sent a solicitation. + Responses to solicited advertisements may contain more information + than unsolicited advertisements. + + If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no + Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY + seconds after sending the last solicitation, the host concludes that + there are no routers on the link for the purpose of [ADDRCONF]. + However, the host continues to receive and process Router + Advertisements messages in the event that routers appear on the link. + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 58] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +7. Address Resolution and Neighbor Unreachability Detection + + This section describes the functions related to Neighbor Solicitation + and Neighbor Advertisement messages and includes descriptions of + address resolution and the Neighbor Unreachability Detection + algorithm. + + Neighbor Solicitation and Advertisement messages are also used for + Duplicate Address Detection as specified by [ADDRCONF]. In + particular, Duplicate Address Detection sends Neighbor Solicitation + messages with an unspecified source address targeting its own + "tentative" address. Such messages trigger nodes already using the + address to respond with a multicast Neighbor Advertisement indicating + that the address is in use. + +7.1. Message Validation + +7.1.1. Validation of Neighbor Solicitations + + A node MUST silently discard any received Neighbor Solicitation + messages that do not satisfy all of the following validity checks: + + - The IP Hop Limit field has a value of 255, i.e., the packet + could not possibly have been forwarded by a router. + + - ICMP Checksum is valid. + + - ICMP Code is 0. + + - ICMP length (derived from the IP length) is 24 or more octets. + + - Target Address is not a multicast address. + + - All included options have a length that is greater than zero. + + - If the IP source address is the unspecified address, the IP + destination address is a solicited-node multicast address. + + - If the IP source address is the unspecified address, there is no + source link-layer address option in the message. + + The contents of the Reserved field, and of any unrecognized options, + MUST be ignored. Future, backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + + + + + +Narten, et al. Standards Track [Page 59] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + The contents of any defined options that are not specified to be used + with Neighbor Solicitation messages MUST be ignored and the packet + processed as normal. The only defined option that may appear is the + Source Link-Layer Address option. + + A Neighbor Solicitation that passes the validity checks is called a + "valid solicitation". + +7.1.2. Validation of Neighbor Advertisements + + A node MUST silently discard any received Neighbor Advertisement + messages that do not satisfy all of the following validity checks: + + - The IP Hop Limit field has a value of 255, i.e., the packet + could not possibly have been forwarded by a router. + + - ICMP Checksum is valid. + + - ICMP Code is 0. + + - ICMP length (derived from the IP length) is 24 or more octets. + + - Target Address is not a multicast address. + + - If the IP Destination Address is a multicast address the + Solicited flag is zero. + + - All included options have a length that is greater than zero. + + The contents of the Reserved field, and of any unrecognized options, + MUST be ignored. Future, backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + The contents of any defined options that are not specified to be used + with Neighbor Advertisement messages MUST be ignored and the packet + processed as normal. The only defined option that may appear is the + Target Link-Layer Address option. + + A Neighbor Advertisements that passes the validity checks is called a + "valid advertisement". + +7.2. Address Resolution + + Address resolution is the process through which a node determines the + link-layer address of a neighbor given only its IP address. Address + resolution is performed only on addresses that are determined to be + on-link and for which the sender does not know the corresponding + + + +Narten, et al. Standards Track [Page 60] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + link-layer address (see Section 5.2). Address resolution is never + performed on multicast addresses. + + It is possible that a host may receive a solicitation, a router + advertisement, or a Redirect message without a link-layer address + option included. These messages MUST NOT create or update neighbor + cache entries, except with respect to the IsRouter flag as specified + in Sections 6.3.4 and 7.2.5. If a Neighbor Cache entry does not + exist for the source of such a message, Address Resolution will be + required before unicast communications with that address can begin. + This is particularly relevant for unicast responses to solicitations + where an additional packet exchange is required for advertisement + delivery. + +7.2.1. Interface Initialization + + When a multicast-capable interface becomes enabled, the node MUST + join the all-nodes multicast address on that interface, as well as + the solicited-node multicast address corresponding to each of the IP + addresses assigned to the interface. + + The set of addresses assigned to an interface may change over time. + New addresses might be added and old addresses might be removed + [ADDRCONF]. In such cases the node MUST join and leave the + solicited-node multicast address corresponding to the new and old + addresses, respectively. Joining the solicited-node multicast + address is done using a Multicast Listener Discovery such as [MLD] or + [MLDv2] protocols. Note that multiple unicast addresses may map into + the same solicited-node multicast address; a node MUST NOT leave the + solicited-node multicast group until all assigned addresses + corresponding to that multicast address have been removed. + +7.2.2. Sending Neighbor Solicitations + + 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 + resolution. For multicast-capable interfaces, this entails creating + a Neighbor Cache entry in the INCOMPLETE state and transmitting a + Neighbor Solicitation message targeted at the neighbor. The + solicitation is sent to the solicited-node multicast address + corresponding to the target address. + + If the source address of the packet prompting the solicitation is the + same as one of the addresses assigned to the outgoing interface, that + address SHOULD be placed in the IP Source Address of the outgoing + solicitation. Otherwise, any one of the addresses assigned to the + interface should be used. Using the prompting packet's source + address when possible ensures that the recipient of the Neighbor + + + +Narten, et al. Standards Track [Page 61] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Solicitation installs in its Neighbor Cache the IP address that is + highly likely to be used in subsequent return traffic belonging to + the prompting packet's "connection". + + If the solicitation is being sent to a solicited-node multicast + address, the sender MUST include its link-layer address (if it has + one) as a Source Link-Layer Address option. Otherwise, the sender + SHOULD include its link-layer address (if it has one) as a Source + Link-Layer Address option. Including the source link-layer address + in a multicast solicitation is required to give the target an address + to which it can send the Neighbor Advertisement. On unicast + solicitations, an implementation MAY omit the Source Link-Layer + Address option. The assumption here is that if the sender has a + peer's link-layer address in its cache, there is a high probability + that the peer will also have an entry in its cache for the sender. + Consequently, it need not be sent. + + While waiting for address resolution to complete, the sender MUST, + for each neighbor, retain a small queue of packets waiting for + address resolution to complete. The queue MUST hold at least one + packet, and MAY contain more. However, the number of queued packets + per neighbor SHOULD be limited to some small value. When a queue + overflows, the new arrival SHOULD replace the oldest entry. Once + address resolution completes, the node transmits any queued packets. + + While awaiting a response, the sender SHOULD retransmit Neighbor + Solicitation messages approximately every RetransTimer milliseconds, + even in the absence of additional traffic to the neighbor. + Retransmissions MUST be rate-limited to at most one solicitation per + neighbor every RetransTimer milliseconds. + + If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT + solicitations, address resolution has failed. The sender MUST return + ICMP destination unreachable indications with code 3 (Address + Unreachable) for each packet queued awaiting address resolution. + +7.2.3. Receipt of Neighbor Solicitations + + A valid Neighbor Solicitation that does not meet any of the following + requirements MUST be silently discarded: + + - The Target Address is a "valid" unicast or anycast address + assigned to the receiving interface [ADDRCONF], + + - The Target Address is a unicast or anycast address for which the + node is offering proxy service, or + + + + + +Narten, et al. Standards Track [Page 62] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - The Target Address is a "tentative" address on which Duplicate + Address Detection is being performed [ADDRCONF]. + + If the Target Address is tentative, the Neighbor Solicitation should + be processed as described in [ADDRCONF]. Otherwise, the following + description applies. If the Source Address is not the unspecified + address and, on link layers that have addresses, the solicitation + includes a Source Link-Layer Address option, then the recipient + SHOULD create or update the Neighbor Cache entry for the IP Source + 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 + 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 + Link-Layer option, the cached address should be replaced by the + received address, and the entry's reachability state MUST be set to + STALE. + + If a Neighbor Cache entry is created, the IsRouter flag SHOULD be set + to FALSE. This will be the case even if the Neighbor Solicitation is + sent by a router since the Neighbor Solicitation messages do not + contain an indication of whether or not the sender is a router. In + the event that the sender is a router, subsequent Neighbor + Advertisement or Router Advertisement messages will set the correct + IsRouter value. If a Neighbor Cache entry already exists, its + IsRouter flag MUST NOT be modified. + + If the Source Address is the unspecified address, the node MUST NOT + create or update the Neighbor Cache entry. + + After any updates to the Neighbor Cache, the node sends a Neighbor + Advertisement response as described in the next section. + +7.2.4. Sending Solicited Neighbor Advertisements + + A node sends a Neighbor Advertisement in response to a valid Neighbor + Solicitation targeting one of the node's assigned addresses. The + Target Address of the advertisement is copied from the Target Address + of the solicitation. If the solicitation's IP Destination Address is + not a multicast address, the Target Link-Layer Address option MAY be + omitted; the neighboring node's cached value must already be current + in order for the solicitation to have been received. If the + solicitation's IP Destination Address is a multicast address, the + Target Link-Layer option MUST be included in the advertisement. + Furthermore, if the node is a router, it MUST set the Router flag to + one; otherwise, it MUST set the flag to zero. + + + + + + +Narten, et al. Standards Track [Page 63] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + If the Target Address is either an anycast address or a unicast + address for which the node is providing proxy service, or the Target + Link-Layer Address option is not included, the Override flag SHOULD + be set to zero. Otherwise, the Override flag SHOULD be set to one. + Proper setting of the Override flag ensures that nodes give + preference to non-proxy advertisements, even when received after + proxy advertisements, and also ensures that the first advertisement + for an anycast address "wins". + + If the source of the solicitation is the unspecified address, the + node MUST set the Solicited flag to zero and multicast the + advertisement to the all-nodes address. Otherwise, the node MUST set + the Solicited flag to one and unicast the advertisement to the Source + Address of the solicitation. + + If the Target Address is an anycast address, the sender SHOULD delay + sending a response for a random time between 0 and + MAX_ANYCAST_DELAY_TIME seconds. + + Because unicast Neighbor Solicitations are not required to include a + Source Link-Layer Address, it is possible that a node sending a + solicited Neighbor Advertisement does not have a corresponding link- + layer address for its neighbor in its Neighbor Cache. In such + situations, a node will first have to use Neighbor Discovery to + determine the link-layer address of its neighbor (i.e., send out a + multicast Neighbor Solicitation). + +7.2.5. Receipt of Neighbor Advertisements + + When a valid Neighbor Advertisement is received (either solicited or + unsolicited), the Neighbor Cache is searched for the target's entry. + If no entry exists, the advertisement SHOULD be silently discarded. + There is no need to create an entry if none exists, since the + recipient has apparently not initiated any communication with the + target. + + Once the appropriate Neighbor Cache entry has been located, the + specific actions taken depend on the state of the Neighbor Cache + entry, the flags in the advertisement, and the actual link-layer + address supplied. + + If the target's Neighbor Cache entry is in the INCOMPLETE state when + the advertisement is received, one of two things happens. If the + link layer has addresses and no Target Link-Layer Address option is + included, the receiving node SHOULD silently discard the received + advertisement. Otherwise, the receiving node performs the following + steps: + + + + +Narten, et al. Standards Track [Page 64] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - It records the link-layer address in the Neighbor Cache entry. + + - If the advertisement's Solicited flag is set, the state of the + entry is set to REACHABLE; otherwise, it is set to STALE. + + - It sets the IsRouter flag in the cache entry based on the Router + flag in the received advertisement. + + - It sends any packets queued for the neighbor awaiting address + resolution. + + Note that the Override flag is ignored if the entry is in the + INCOMPLETE state. + + If the target's Neighbor Cache entry is in any state other than + INCOMPLETE when the advertisement is received, the following actions + take place: + + I. If the Override flag is clear and the supplied link-layer address + differs from that in the cache, then one of two actions takes + place: + a. If the state of the entry is REACHABLE, set it to STALE, but + do not update the entry in any other way. + b. Otherwise, the received advertisement should be ignored and + MUST NOT update the cache. + + 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 + option was supplied, the received advertisement MUST update the + Neighbor Cache entry as follows: + + - The link-layer address in the Target Link-Layer Address option + MUST be inserted in the cache (if one is supplied and differs + from the already recorded address). + + - If the Solicited flag is set, the state of the entry MUST be + set to REACHABLE. If the Solicited flag is zero and the link- + layer address was updated with a different address, the state + MUST be set to STALE. Otherwise, the entry's state remains + unchanged. + + An advertisement's Solicited flag should only be set if the + advertisement is a response to a Neighbor Solicitation. + Because Neighbor Unreachability Detection Solicitations are + sent to the cached link-layer address, receipt of a solicited + advertisement indicates that the forward path is working. + Receipt of an unsolicited advertisement, however, may indicate + that a neighbor has urgent information to announce (e.g., a + + + +Narten, et al. Standards Track [Page 65] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + changed link-layer address). If the urgent information + indicates a change from what a node is currently using, the + node should verify the reachability of the (new) path when it + sends the next packet. There is no need to update the state + for unsolicited advertisements that do not change the contents + of the cache. + + - The IsRouter flag in the cache entry MUST be set based on the + Router flag in the received advertisement. In those cases + where the IsRouter flag changes from TRUE to FALSE as a result + of this update, the node MUST remove that router from the + Default Router List and update the Destination Cache entries + for all destinations using that neighbor as a router as + specified in Section 7.3.3. This is needed to detect when a + node that is used as a router stops forwarding packets due to + being configured as a host. + + The above rules ensure that the cache is updated either when the + Neighbor Advertisement takes precedence (i.e., the Override flag is + set) or when the Neighbor Advertisement refers to the same link-layer + address that is currently recorded in the cache. If none of the + above apply, the advertisement prompts future Neighbor Unreachability + Detection (if it is not already in progress) by changing the state in + the cache entry. + +7.2.6. Sending Unsolicited Neighbor Advertisements + + In some cases, a node may be able to determine that its link-layer + address has changed (e.g., hot-swap of an interface card) and may + wish to inform its neighbors of the new link-layer address quickly. + In such cases, a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT + unsolicited Neighbor Advertisement messages to the all-nodes + multicast address. These advertisements MUST be separated by at + least RetransTimer seconds. + + The Target Address field in the unsolicited advertisement is set to + an IP address of the interface, and the Target Link-Layer Address + option is filled with the new link-layer address. The Solicited flag + MUST be set to zero, in order to avoid confusing the Neighbor + Unreachability Detection algorithm. If the node is a router, it MUST + set the Router flag to one; otherwise, it MUST set it to zero. The + Override flag MAY be set to either zero or one. In either case, + neighboring nodes will immediately change the state of their Neighbor + Cache entries for the Target Address to STALE, prompting them to + verify the path for reachability. If the Override flag is set to + one, neighboring nodes will install the new link-layer address in + their caches. Otherwise, they will ignore the new link-layer + address, choosing instead to probe the cached address. + + + +Narten, et al. Standards Track [Page 66] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + A node that has multiple IP addresses assigned to an interface MAY + multicast a separate Neighbor Advertisement for each address. In + such a case, the node SHOULD introduce a small delay between the + sending of each advertisement to reduce the probability of the + advertisements being lost due to congestion. + + A proxy MAY multicast Neighbor Advertisements when its link-layer + address changes or when it is configured (by system management or + other mechanisms) to proxy for an address. If there are multiple + nodes that are providing proxy services for the same set of + addresses, the proxies should provide a mechanism that prevents + multiple proxies from multicasting advertisements for any one + address, in order to reduce the risk of excessive multicast traffic. + This is a requirement on other protocols that need to use proxies for + Neighbor Advertisements. An example of a node that performs proxy + advertisements is the Home Agent specified in [MIPv6]. + + Also, a node belonging to an anycast address MAY multicast + unsolicited Neighbor Advertisements for the anycast address when the + node's link-layer address changes. + + Note that because unsolicited Neighbor Advertisements do not reliably + update caches in all nodes (the advertisements might not be received + by all nodes), they should only be viewed as a performance + optimization to quickly update the caches in most neighbors. The + Neighbor Unreachability Detection algorithm ensures that all nodes + obtain a reachable link-layer address, though the delay may be + slightly longer. + +7.2.7. Anycast Neighbor Advertisements + + From the perspective of Neighbor Discovery, anycast addresses are + treated just like unicast addresses in most cases. Because an + anycast address is syntactically the same as a unicast address, nodes + performing address resolution or Neighbor Unreachability Detection on + an anycast address treat it as if it were a unicast address. No + special processing takes place. + + Nodes that have an anycast address assigned to an interface treat + them exactly the same as if they were unicast addresses with two + exceptions. First, Neighbor Advertisements sent in response to a + Neighbor Solicitation SHOULD be delayed by a random time between 0 + and MAX_ANYCAST_DELAY_TIME to reduce the probability of network + congestion. Second, the Override flag in Neighbor Advertisements + SHOULD be set to 0, so that when multiple advertisements are + received, the first received advertisement is used rather than the + most recently received advertisement. + + + + +Narten, et al. Standards Track [Page 67] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + As with unicast addresses, Neighbor Unreachability Detection ensures + that a node quickly detects when the current binding for an anycast + address becomes invalid. + +7.2.8. Proxy Neighbor Advertisements + + Under limited circumstances, a router MAY proxy for one or more other + nodes, that is, through Neighbor Advertisements indicate that it is + willing to accept packets not explicitly addressed to itself. For + example, a router might accept packets on behalf of a mobile node + that has moved off-link. The mechanisms used by proxy are + essentially the same as the mechanisms used with anycast addresses. + + 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 + 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 + Override flag set to zero. This ensures that if the node itself is + present on the link, its Neighbor Advertisement (with the Override + flag set to one) will take precedence of any advertisement received + 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 + may cause the proxy advertisement to override a valid entry created + by the node itself. + + Finally, when sending a proxy advertisement in response to a Neighbor + Solicitation, the sender should delay its response by a random time + 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 + + Communication to or through a neighbor may fail for numerous reasons + at any time, including hardware failure, hot-swap of an interface + card, etc. If the destination has failed, no recovery is possible + and communication fails. On the other hand, if it is the path that + has failed, recovery may be possible. Thus, a node actively tracks + the reachability "state" for the neighbors to which it is sending + packets. + + Neighbor Unreachability Detection is used for all paths between hosts + and neighboring nodes, including host-to-host, host-to-router, and + router-to-host communication. Neighbor Unreachability Detection may + also be used between routers, but is not required if an equivalent + + + +Narten, et al. Standards Track [Page 68] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + mechanism is available, for example, as part of the routing + protocols. + + When a path to a neighbor appears to be failing, the specific + recovery procedure depends on how the neighbor is being used. If the + neighbor is the ultimate destination, for example, address resolution + should be performed again. If the neighbor is a router, however, + attempting to switch to another router would be appropriate. The + specific recovery that takes place is covered under next-hop + determination; Neighbor Unreachability Detection signals the need for + next-hop determination by deleting a Neighbor Cache entry. + + Neighbor Unreachability Detection is performed only for neighbors to + which unicast packets are sent; it is not used when sending to + multicast addresses. + +7.3.1. Reachability Confirmation + + A neighbor is considered reachable if the node has recently received + a confirmation that packets sent recently to the neighbor were + received by its IP layer. Positive confirmation can be gathered in + two ways: hints from upper-layer protocols that indicate a connection + is making "forward progress", or receipt of a Neighbor Advertisement + message that is a response to a Neighbor Solicitation message. + + A connection makes "forward progress" if the packets received from a + remote peer can only be arriving if recent packets sent to that peer + are actually reaching it. In TCP, for example, receipt of a (new) + acknowledgment indicates that previously sent data reached the peer. + Likewise, the arrival of new (non-duplicate) data indicates that + earlier acknowledgments are being delivered to the remote peer. If + packets are reaching the peer, they must also be reaching the + sender's next-hop neighbor; thus, "forward progress" is a + confirmation that the next-hop neighbor is reachable. For off-link + destinations, forward progress implies that the first-hop router is + reachable. When available, this upper-layer information SHOULD be + used. + + In some cases (e.g., UDP-based protocols and routers forwarding + packets to hosts), such reachability information may not be readily + available from upper-layer protocols. When no hints are available + and a node is sending packets to a neighbor, the node actively probes + the neighbor using unicast Neighbor Solicitation messages to verify + that the forward path is still working. + + The receipt of a solicited Neighbor Advertisement serves as + reachability confirmation, since advertisements with the Solicited + flag set to one are sent only in response to a Neighbor Solicitation. + + + +Narten, et al. Standards Track [Page 69] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Receipt of other Neighbor Discovery messages, such as Router + Advertisements and Neighbor Advertisement with the Solicited flag set + to zero, MUST NOT be treated as a reachability confirmation. Receipt + of unsolicited messages only confirms the one-way path from the + sender to the recipient node. In contrast, Neighbor Unreachability + Detection requires that a node keep track of the reachability of the + forward path to a neighbor from its perspective, not the neighbor's + perspective. Note that receipt of a solicited advertisement + indicates that a path is working in both directions. The + solicitation must have reached the neighbor, prompting it to generate + an advertisement. Likewise, receipt of an advertisement indicates + that the path from the sender to the recipient is working. However, + the latter fact is known only to the recipient; the advertisement's + sender has no direct way of knowing that the advertisement it sent + actually reached a neighbor. From the perspective of Neighbor + Unreachability Detection, only the reachability of the forward path + is of interest. + +7.3.2. Neighbor Cache Entry States + + A Neighbor Cache entry can be in one of five states: + + INCOMPLETE Address resolution is being performed on the entry. + Specifically, a Neighbor Solicitation has been sent to + the solicited-node multicast address of the target, + but the corresponding Neighbor Advertisement has not + yet been received. + + REACHABLE Positive confirmation was received within the last + ReachableTime milliseconds that the forward path to + the neighbor was functioning properly. While + REACHABLE, no special action takes place as packets + are sent. + + STALE More than ReachableTime milliseconds have elapsed + since the last positive confirmation was received that + the forward path was functioning properly. While + stale, no action takes place until a packet is sent. + + The STALE state is entered upon receiving an + unsolicited Neighbor Discovery message that updates + the cached link-layer address. Receipt of such a + message does not confirm reachability, and entering + the STALE state ensures reachability is verified + quickly if the entry is actually being used. However, + reachability is not actually verified until the entry + is actually used. + + + + +Narten, et al. Standards Track [Page 70] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + DELAY More than ReachableTime milliseconds have elapsed + since the last positive confirmation was received that + the forward path was functioning properly, and a + packet was sent within the last DELAY_FIRST_PROBE_TIME + seconds. If no reachability confirmation is received + within DELAY_FIRST_PROBE_TIME seconds of entering the + DELAY state, send a Neighbor Solicitation and change + the state to PROBE. + + The DELAY state is an optimization that gives upper- + layer protocols additional time to provide + reachability confirmation in those cases where + ReachableTime milliseconds have passed since the last + confirmation due to lack of recent traffic. Without + this optimization, the opening of a TCP connection + after a traffic lull would initiate probes even though + the subsequent three-way handshake would provide a + reachability confirmation almost immediately. + + PROBE A reachability confirmation is actively sought by + retransmitting Neighbor Solicitations every + RetransTimer milliseconds until a reachability + confirmation is received. + +7.3.3. Node Behavior + + Neighbor Unreachability Detection operates in parallel with the + sending of packets to a neighbor. While reasserting a neighbor's + reachability, a node continues sending packets to that neighbor using + the cached link-layer address. If no traffic is sent to a neighbor, + no probes are sent. + + When a node needs to perform address resolution on a neighboring + address, it creates an entry in the INCOMPLETE state and initiates + address resolution as specified in Section 7.2. If address + resolution fails, the entry SHOULD be deleted, so that subsequent + traffic to that neighbor invokes the next-hop determination procedure + again. Invoking next-hop determination at this point ensures that + alternate default routers are tried. + + When a reachability confirmation is received (either through upper- + layer advice or a solicited Neighbor Advertisement), an entry's state + changes to REACHABLE. The one exception is that upper-layer advice + has no effect on entries in the INCOMPLETE state (e.g., for which no + link-layer address is cached). + + + + + + +Narten, et al. Standards Track [Page 71] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + When ReachableTime milliseconds have passed since receipt of the last + reachability confirmation for a neighbor, the Neighbor Cache entry's + state changes from REACHABLE to STALE. + + Note: An implementation may actually defer changing the state from + REACHABLE to STALE until a packet is sent to the neighbor, i.e., + there need not be an explicit timeout event associated with the + expiration of ReachableTime. + + The first time a node sends a packet to a neighbor whose entry is + STALE, the sender changes the state to DELAY and sets a timer to + expire in DELAY_FIRST_PROBE_TIME seconds. If the entry is still in + the DELAY state when the timer expires, the entry's state changes to + PROBE. If reachability confirmation is received, the entry's state + changes to REACHABLE. + + Upon entering the PROBE state, a node sends a unicast Neighbor + Solicitation message to the neighbor using the cached link-layer + address. While in the PROBE state, a node retransmits Neighbor + Solicitation messages every RetransTimer milliseconds until + reachability confirmation is obtained. Probes are retransmitted even + if no additional packets are sent to the neighbor. If no response is + received after waiting RetransTimer milliseconds after sending the + MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the + entry SHOULD be deleted. Subsequent traffic to that neighbor will + recreate the entry and perform address resolution again. + + Note that all Neighbor Solicitations are rate-limited on a per- + neighbor basis. A node MUST NOT send Neighbor Solicitations to the + same neighbor more frequently than once every RetransTimer + milliseconds. + + A Neighbor Cache entry enters the STALE state when created as a + result of receiving packets other than solicited Neighbor + Advertisements (i.e., Router Solicitations, Router Advertisements, + Redirects, and Neighbor Solicitations). These packets contain the + link-layer address of either the sender or, in the case of Redirect, + the redirection target. However, receipt of these link-layer + addresses does not confirm reachability of the forward-direction path + to that node. Placing a newly created Neighbor Cache entry for which + the link-layer address is known in the STALE state provides assurance + that path failures are detected quickly. In addition, should a + cached link-layer address be modified due to receiving one of the + above messages, the state SHOULD also be set to STALE to provide + prompt verification that the path to the new link-layer address is + working. + + + + + +Narten, et al. Standards Track [Page 72] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + To properly detect the case where a router switches from being a + router to being a host (e.g., if its IP forwarding capability is + turned off by system management), a node MUST compare the Router flag + field in all received Neighbor Advertisement messages with the + IsRouter flag recorded in the Neighbor Cache entry. When a node + detects that a neighbor has changed from being a router to being a + host, the node MUST remove that router from the Default Router List + and update the Destination Cache as described in Section 6.3.5. Note + that a router may not be listed in the Default Router List, even + though a Destination Cache entry is using it (e.g., a host was + redirected to it). In such cases, all Destination Cache entries that + reference the (former) router must perform next-hop determination + again before using the entry. + + In some cases, link-specific information may indicate that a path to + a neighbor has failed (e.g., the resetting of a virtual circuit). In + such cases, link-specific information may be used to purge Neighbor + Cache entries before the Neighbor Unreachability Detection would do + so. However, link-specific information MUST NOT be used to confirm + the reachability of a neighbor; such information does not provide + end-to-end confirmation between neighboring IP layers. + +8. Redirect Function + + This section describes the functions related to the sending and + processing of Redirect messages. + + Redirect messages are sent by routers to redirect a host to a better + first-hop router for a specific destination or to inform hosts that a + destination is in fact a neighbor (i.e., on-link). The latter is + accomplished by having the ICMP Target Address be equal to the ICMP + Destination Address. + + A router MUST be able to determine the link-local address for each of + its neighboring routers in order to ensure that the target address in + a Redirect message identifies the neighbor router by its link-local + address. For static routing, this requirement implies that the next- + hop router's address should be specified using the link-local address + of the router. For dynamic routing, this requirement implies that + all IPv6 routing protocols must somehow exchange the link-local + addresses of neighboring routers. + + + + + + + + + + +Narten, et al. Standards Track [Page 73] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +8.1. Validation of Redirect Messages + + A host MUST silently discard any received Redirect message that does + not satisfy all of the following validity checks: + + - IP Source Address is a link-local address. Routers must use + their link-local address as the source for Router Advertisement + and Redirect messages so that hosts can uniquely identify + routers. + + - The IP Hop Limit field has a value of 255, i.e., the packet + could not possibly have been forwarded by a router. + + - ICMP Checksum is valid. + + - ICMP Code is 0. + + - ICMP length (derived from the IP length) is 40 or more octets. + + - The IP source address of the Redirect is the same as the current + first-hop router for the specified ICMP Destination Address. + + - The ICMP Destination Address field in the redirect message does + not contain a multicast address. + + - The ICMP Target Address is either a link-local address (when + redirected to a router) or the same as the ICMP Destination + Address (when redirected to the on-link destination). + + - All included options have a length that is greater than zero. + + The contents of the Reserved field, and of any unrecognized options, + MUST be ignored. Future, backward-compatible changes to the protocol + may specify the contents of the Reserved field or add new options; + backward-incompatible changes may use different Code values. + + The contents of any defined options that are not specified to be used + with Redirect messages MUST be ignored and the packet processed as + normal. The only defined options that may appear are the Target + Link-Layer Address option and the Redirected Header option. + + A host MUST NOT consider a redirect invalid just because the Target + Address of the redirect is not covered under one of the link's + prefixes. Part of the semantics of the Redirect message is that the + Target Address is on-link. + + A redirect that passes the validity checks is called a "valid + redirect". + + + +Narten, et al. Standards Track [Page 74] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +8.2. Router Specification + + A router SHOULD send a redirect message, subject to rate limiting, + whenever it forwards a packet that is not explicitly addressed to + itself (i.e., a packet that is not source routed through the router) + in which: + + - the Source Address field of the packet identifies a neighbor, + and + + - the router determines (by means outside the scope of this + specification) that a better first-hop node resides on the same + link as the sending node for the Destination Address of the + packet being forwarded, and + + - the Destination Address of the packet is not a multicast + address. + + The transmitted redirect packet contains, consistent with the message + format given in Section 4.5: + + - In the Target Address field: the address to which subsequent + packets for the destination should be sent. If the target is a + 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 + same value as the Destination Address field. + + - In the Destination Address field: the destination address of the + invoking IP packet. + + - In the options: + + o Target Link-Layer Address option: link-layer address of the + target, if known. + + o Redirected Header: as much of the forwarded packet as can + fit without the redirect packet exceeding the minimum MTU + required to support IPv6 as specified in [IPv6]. + + A router MUST limit the rate at which Redirect messages are sent, in + order to limit the bandwidth and processing costs incurred by the + Redirect messages when the source does not correctly respond to the + Redirects, or the source chooses to ignore unauthenticated Redirect + messages. More details on the rate-limiting of ICMP error messages + can be found in [ICMPv6]. + + A router MUST NOT update its routing tables upon receipt of a + Redirect. + + + +Narten, et al. Standards Track [Page 75] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +8.3. Host Specification + + A host receiving a valid redirect SHOULD update its Destination Cache + accordingly so that subsequent traffic goes to the specified target. + If no Destination Cache entry exists for the destination, an + implementation SHOULD create such an entry. + + If the redirect contains a Target Link-Layer Address option, the host + either creates or updates the Neighbor Cache entry for the target. + In both cases, the cached link-layer address is copied from the + Target Link-Layer Address option. If a Neighbor Cache entry is + created for the target, its reachability state MUST be set to STALE + as specified in Section 7.3.3. If a cache entry already existed and + it is updated with a different link-layer address, its reachability + state MUST also be set to STALE. If the link-layer address is the + same as that already in the cache, the cache entry's state remains + unchanged. + + If the Target and Destination Addresses are the same, the host MUST + treat the Target as on-link. If the Target Address is not the same + as the Destination Address, the host MUST set IsRouter to TRUE for + the target. If the Target and Destination Addresses are the same, + however, one cannot reliably determine whether the Target Address is + a router. Consequently, newly created Neighbor Cache entries should + set the IsRouter flag to FALSE, while existing cache entries should + leave the flag unchanged. If the Target is a router, subsequent + Neighbor Advertisement or Router Advertisement messages will update + IsRouter accordingly. + + Redirect messages apply to all flows that are being sent to a given + destination. That is, upon receipt of a Redirect for a Destination + Address, all Destination Cache entries to that address should be + updated to use the specified next-hop, regardless of the contents of + the Flow Label field that appears in the Redirected Header option. + + A host MUST NOT send Redirect messages. + +9. Extensibility - Option Processing + + Options provide a mechanism for encoding variable length fields, + fields that may appear multiple times in the same packet, or + information that may not appear in all packets. Options can also be + used to add additional functionality to future versions of ND. + + In order to ensure that future extensions properly coexist with + current implementations, all nodes MUST silently ignore any options + they do not recognize in received ND packets and continue processing + the packet. All options specified in this document MUST be + + + +Narten, et al. Standards Track [Page 76] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + recognized. A node MUST NOT ignore valid options just because the ND + message contains unrecognized ones. + + The current set of options is defined in such a way that receivers + can process multiple options in the same packet independently of each + other. In order to maintain these properties, future options SHOULD + follow the simple rule: + + The option MUST NOT depend on the presence or absence of any other + options. The semantics of an option should depend only on the + information in the fixed part of the ND packet and on the + information contained in the option itself. + + Adhering to the above rule has the following benefits: + + 1) Receivers can process options independently of one another. For + example, an implementation can choose to process the Prefix + Information option contained in a Router Advertisement message + in a user-space process while the link-layer address option in + the same message is processed by routines in the kernel. + + 2) Should the number of options cause a packet to exceed a link's + MTU, multiple packets can carry subsets of the options without + any change in semantics. + + 3) Senders MAY send a subset of options in different packets. For + instance, if a prefix's Valid and Preferred Lifetime are high + enough, it might not be necessary to include the Prefix + Information option in every Router Advertisement. In addition, + different routers might send different sets of options. Thus, a + receiver MUST NOT associate any action with the absence of an + option in a particular packet. This protocol specifies that + receivers should only act on the expiration of timers and on the + information that is received in the packets. + + Options in Neighbor Discovery packets can appear in any order; + receivers MUST be prepared to process them independently of their + order. There can also be multiple instances of the same option in a + message (e.g., Prefix Information options). + + If the number of included options in a Router Advertisement causes + the advertisement's size to exceed the link MTU, the router can send + multiple separate advertisements, each containing a subset of the + options. + + The amount of data to include in the Redirected Header option MUST be + limited so that the entire redirect packet does not exceed the + minimum MTU required to support IPv6 as specified in [IPv6]. + + + +Narten, et al. Standards Track [Page 77] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + All options are a multiple of 8 octets of length, ensuring + appropriate alignment without any "pad" options. The fields in the + options (as well as the fields in ND packets) are defined to align on + their natural boundaries (e.g., a 16-bit field is aligned on a 16-bit + boundary) with the exception of the 128-bit IP addresses/prefixes, + which are aligned on a 64-bit boundary. The link-layer address field + contains an uninterpreted octet string; it is aligned on an 8-bit + boundary. + + The size of an ND packet including the IP header is limited to the + link MTU. When adding options to an ND packet, a node MUST NOT + exceed the link MTU. + + Future versions of this protocol may define new option types. + Receivers MUST silently ignore any options they do not recognize and + continue processing the message. + +10. Protocol Constants + + Router constants: + + MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds + + MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions + + MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions + + MIN_DELAY_BETWEEN_RAS 3 seconds + + MAX_RA_DELAY_TIME .5 seconds + + Host constants: + + MAX_RTR_SOLICITATION_DELAY 1 second + + RTR_SOLICITATION_INTERVAL 4 seconds + + MAX_RTR_SOLICITATIONS 3 transmissions + + Node constants: + + MAX_MULTICAST_SOLICIT 3 transmissions + + MAX_UNICAST_SOLICIT 3 transmissions + + MAX_ANYCAST_DELAY_TIME 1 second + + MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions + + + +Narten, et al. Standards Track [Page 78] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + REACHABLE_TIME 30,000 milliseconds + + RETRANS_TIMER 1,000 milliseconds + + DELAY_FIRST_PROBE_TIME 5 seconds + + MIN_RANDOM_FACTOR .5 + + MAX_RANDOM_FACTOR 1.5 + + Additional protocol constants are defined with the message formats in + Section 4. + + All protocol constants are subject to change in future revisions of + the protocol. + + The constants in this specification may be overridden by specific + documents that describe how IPv6 operates over different link layers. + This rule allows Neighbor Discovery to operate over links with widely + varying performance characteristics. + +11. Security Considerations + + Neighbor Discovery is subject to attacks that cause IP packets to + flow to unexpected places. Such attacks can be used to cause denial + of service but also allow nodes to intercept and optionally modify + packets destined for other nodes. This section deals with the main + threats related to Neighbor Discovery messages and possible security + mechanisms that can mitigate these threats. + +11.1. Threat Analysis + + This section discusses the main threats associated with Neighbor + Discovery. A more detailed analysis can be found in [PSREQ]. The + main vulnerabilities of the protocol fall under three categories: + + - Denial-of-Service (DoS) attacks. + - Address spoofing attacks. + - Router spoofing attacks. + + An example of denial of service attacks is that a node on the link + that can send packets with an arbitrary IP source address can both + advertise itself as a default router and also send "forged" Router + Advertisement messages that immediately time out all other default + routers as well as all on-link prefixes. An intruder can achieve + this by sending out multiple Router Advertisements, one for each + legitimate router, with the source address set to the address of + another router, the Router Lifetime field set to zero, and the + + + +Narten, et al. Standards Track [Page 79] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + Preferred and Valid lifetimes set to zero for all the prefixes. Such + an attack would cause all packets, for both on-link and off-link + destinations, to go to the rogue router. That router can then + selectively examine, modify, or drop all packets sent on the link. + The Neighbor Unreachability Detection (NUD) will not detect such a + black hole as long as the rogue router politely answers the NUD + probes with a Neighbor Advertisement with the R-bit set. + + It is also possible for any host to launch a DoS attack on another + host by preventing it from configuring an address using [ADDRCONF]. + The protocol does not allow hosts to verify whether the sender of a + Neighbor Advertisement is the true owner of the IP address included + in the message. + + 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 (in response to a solicitation) that contains its IP + address and a victim's link-layer address in order to flood the + victim with unwanted traffic. Alternatively, the host can send a + Neighbor Advertisement that includes a victim's IP address and its + own link-layer address to overwrite an existing entry in the sender's + destination cache, thereby forcing the sender to forward all of the + victim's traffic to itself. + + 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 + 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 + prevent the target from issuing another redirect to some other + destination. However, this exposure is no worse than it was before + being redirected; the target host, once subverted, could always act + as a hidden router to forward traffic elsewhere. + + The protocol contains no mechanism to determine which neighbors are + authorized to send a particular type of message (e.g., Router + Advertisements); any neighbor, presumably even in the presence of + authentication, can send Router Advertisement messages thereby being + able to cause denial of service. Furthermore, any neighbor can send + proxy Neighbor Advertisements as well as unsolicited Neighbor + Advertisements as a potential denial-of-service attack. + + Many link layers are also subject to different denial-of-service + attacks such as continuously occupying the link in CSMA/CD (Carrier + Sense Multiple Access with Collision Detection) networks (e.g., by + sending packets closely back-to-back or asserting the collision + signal on the link), or originating packets with somebody 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 + + + +Narten, et al. Standards Track [Page 80] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + 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 + default router. + +11.2. Securing Neighbor Discovery Messages + + The protocol reduces the exposure to the above threats in the absence + of authentication by ignoring ND packets received from off-link + senders. The Hop Limit field of all received packets is verified to + contain 255, the maximum legal value. Because routers decrement the + Hop Limit on all packets they forward, received packets containing a + Hop Limit of 255 must have originated from a neighbor. + + Cryptographic security mechanisms for Neighbor Discovery are outside + the scope of this document and are defined in [SEND]. Alternatively, + IPsec can be used for IP layer authentication [IPv6-SA]. The use of + the Internet Key Exchange (IKE) is not suited for creating dynamic + security associations that can be used to secure address resolution + or neighbor solicitation messages as documented in [ICMPIKE]. + + In some cases, it may be acceptable to use statically configured + security associations with either [IPv6-AUTH] or [IPv6-ESP] to secure + Neighbor Discovery messages. However, it is important to note that + statically configured security associations are not scalable + (especially when considering multicast links) and are therefore + limited to small networks with known hosts. In any case, if either + [IPv6-AUTH] or [IPv6-ESP] is used, ND packets MUST be verified for + the purpose of authentication. Packets that fail authentication + checks MUST be silently discarded. + +12. Renumbering Considerations + + The Neighbor Discovery protocol together with IPv6 Address + Autoconfiguration [ADDRCONF] provides mechanisms to aid in + renumbering -- new prefixes and addresses can be introduced and old + ones can be deprecated and removed. + + The robustness of these mechanisms is based on all the nodes on the + link receiving the Router Advertisement messages in a timely manner. + However, a host might be turned off or be unreachable for an extended + period of time (i.e., a machine is powered down for months after a + project terminates). It is possible to preserve robust renumbering + in such cases, but it does place some constraints on how long + prefixes must be advertised. + + Consider the following example in which a prefix is initially + advertised with a lifetime of 2 months, but on August 1st it is + determined that the prefix needs to be deprecated and removed due to + + + +Narten, et al. Standards Track [Page 81] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + renumbering by September 1st. This can be done by reducing the + advertised lifetime to 1 week starting on August 1st, and as the + cutoff gets closer, the lifetimes can be made shorter until by + September 1st the prefix is advertised with a lifetime of 0. The + point is that, if one or more nodes were unplugged from the link + prior to September 1st, they might still think that the prefix is + valid since the last lifetime they received was 2 months. Thus, if a + node was unplugged on July 31st, it thinks the prefix is valid until + September 30th. If that node is plugged back in prior to September + 30th, it may continue to use the old prefix. The only way to force a + node to stop using a prefix that was previously advertised with a + long lifetime is to have that node receive an advertisement for that + prefix that changes the lifetime downward. The solution in this + example is simple: continue advertising the prefix with a lifetime of + 0 from September 1st until October 1st. + + In general, in order to be robust against nodes that might be + unplugged from the link, it is important to track the furthest into + the future that a particular prefix can be viewed as valid by any + node on the link. The prefix must then be advertised with a 0 + lifetime until that point in the future. This "furthest into the + future" time is simply the maximum, over all Router Advertisements, + of the time the advertisement was sent, plus the prefix's lifetime + contained in the advertisement. + + The above has an important implication on using infinite lifetimes. + If a prefix is advertised with an infinite lifetime, and that prefix + later needs to be renumbered, it is undesirable to continue + advertising that prefix with a zero lifetime forever. Thus, either + infinite lifetimes should be avoided or there must be a limit on how + long of a time a node can be unplugged from the link before it is + plugged back in again. However, it is unclear how the network + administrator can enforce a limit on how long time hosts such as + laptops can be unplugged from the link. + + Network administrators should give serious consideration to using + relatively short lifetimes (i.e., no more than a few weeks). While + it might appear that using long lifetimes would help ensure + robustness, in reality, a host will be unable to communicate in the + absence of properly functioning routers. Such routers will be + sending Router Advertisements that contain appropriate (and current) + 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 + valid prefix and address. + + + + + + + +Narten, et al. Standards Track [Page 82] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + The above discussion does not distinguish between the preferred and + valid lifetimes. For all practical purposes, it is probably + sufficient to track the valid lifetime since the preferred lifetime + will not exceed the valid lifetime. + +13. IANA Considerations + + This document does not require any new ICMPv6 types or codes to be + allocated. However, existing ICMPv6 types have been updated to point + to this 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 the 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". + + + +Narten, et al. Standards Track [Page 83] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + 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. + +14. References + +14.1. Normative References + + [ADDR-ARCH] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, February 2006. + + [ICMPv6] Conta, A., Deering, S., and M. Gupta, Ed., "Internet + Control Message Protocol (ICMPv6) for the Internet + Protocol Version 6 (IPv6) Specification", RFC 4443, + March 2006. + + [IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, December 1998. + + [KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + +14.2. Informative References + + [ADDRCONF] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + + [ADDR-SEL] Draves, R., "Default Address Selection for Internet + Protocol version 6 (IPv6)", RFC 3484, February 2003. + + [ARP] Plummer, D., "Ethernet Address Resolution Protocol: Or + Converting Network Protocol Addresses to 48.bit Ethernet + Address for Transmission on Ethernet Hardware", STD 37, + RFC 826, November 1982. + + [ASSIGNED] Reynolds, J., Ed., "Assigned Numbers: RFC 1700 is + Replaced by an On-line Database", RFC 3232, January + 2002. + + + +Narten, et al. Standards Track [Page 84] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + [DHCPv6] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, July 2003. + + [HR-CL] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, October 1989. + + [ICMPIKE] Arkko, J., "Effects of ICMPv6 on IKE", Work in Progress, + March 2003. + + [ICMPv4] Postel, J., "Internet Control Message Protocol", STD 5, + RFC 792, September 1981. + + [IPv6-3GPP] Wasserman, M., Ed., "Recommendations for IPv6 in Third + Generation Partnership Project (3GPP) Standards", RFC + 3314, September 2002. + + [IPv6-CELL] Arkko, J., Kuijpers, G., Soliman, H., Loughney, J., and + J. Wiljakka, "Internet Protocol Version 6 (IPv6) for + Some Second and Third Generation Cellular Hosts", RFC + 3316, April 2003. + + [IPv6-ETHER] Crawford, M., "Transmission of IPv6 Packets over + Ethernet Networks", RFC 2464, December 1998. + + [IPv6-SA] Kent, S. and K. Seo, "Security Architecture for the + Internet Protocol", RFC 4301, December 2005. + + [IPv6-AUTH] Kent, S., "IP Authentication Header", RFC 4302, December + 2005. + + [IPv6-ESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC + 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 + Sharing", RFC 4311, November 2005. + + [MIPv6] Johnson, D., Perkins, C., and J. Arkko, "Mobility + Support in IPv6", RFC 3775, June 2004. + + [MLD] Deering, S., Fenner, W., and B. Haberman, "Multicast + Listener Discovery (MLD) for IPv6", RFC 2710, October + 1999. + + + + +Narten, et al. Standards Track [Page 85] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + [MLDv2] Vida, R., Ed., and L. Costa, Ed., "Multicast Listener + Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June + 2004. + + [PSREQ] Nikander, P., Ed., Kempf, J., and E. Nordmark, "IPv6 + Neighbor Discovery (ND) Trust Models and Threats", RFC + 3756, May 2004. + + [RAND] Eastlake, D., 3rd, Schiller, J., and S. Crocker, + "Randomness Requirements for Security", BCP 106, RFC + 4086, June 2005. + + [RDISC] Deering, S., Ed., "ICMP Router Discovery Messages", RFC + 1256, September 1991. + + [RFC3667] Bradner, S., "IETF Rights in Contributions", RFC 3667, + February 2004. + + [RTSEL] Draves, R. and D. Thaler, "Default Router Preferences + and More-Specific Routes", RFC 4191, November 2005. + + [SH-MEDIA] Braden, B., Postel, J., and Y. Rekhter, "Internet + Architecture Extensions for Shared Media", RFC 1620, May + 1994. + + [SEND] Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander, + "SEcure Neighbor Discovery (SEND)", RFC 3971, March + 2005. + + [SYNC] S. Floyd, V. Jacobson, "The Synchronization of Periodic + Routing Messages", IEEE/ACM Transactions on Networking, + April 1994. ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z + + + + + + + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 86] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Appendix A: Multihomed Hosts + + There are a number of complicating issues that arise when Neighbor + Discovery is used by hosts that have multiple interfaces. This + section does not attempt to define the proper operation of multihomed + hosts with regard to Neighbor Discovery. Rather, it identifies + issues that require further study. Implementors are encouraged to + experiment with various approaches to making Neighbor Discovery work + on multihomed hosts and to report their experiences. Further work + related to this problem can be found in [RTSEL]. + + If a multihomed host receives Router Advertisements on all of its + interfaces, it will (probably) have learned on-link prefixes for the + addresses residing on each link. When a packet must be sent through + a router, however, selecting the "wrong" router can result in a + suboptimal or non-functioning path. There are number of issues to + consider: + + 1) In order for a router to send a redirect, it must determine that + the packet it is forwarding originates from a neighbor. The + standard test for this case is to compare the source address of + the packet to the list of on-link prefixes associated with the + interface on which the packet was received. If the originating + host is multihomed, however, the source address it uses may + belong to an interface other than the interface from which it + was sent. In such cases, a router will not send redirects, and + suboptimal routing is likely. In order to be redirected, the + sending host must always send packets out the interface + corresponding to the outgoing packet's source address. Note + that this issue never arises with non-multihomed hosts; they + only have one interface. Additional discussion on this topic + can be found in RFC 1122 under Section 3.3.4.2. + + 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. + However, the destination may be reachable through a router on + one of the other interfaces. Neighbor Discovery does not + address this scenario; it does not arise in the non-multihomed + case. + + 3) Even if the first-hop router does have a route for a + destination, there may be a better route via another interface. + No mechanism exists for the multihomed host to detect this + situation. + + If a multihomed host fails to receive Router Advertisements on one or + more of its interfaces, it will not know (in the absence of + configured information) which destinations are on-link on the + + + +Narten, et al. Standards Track [Page 87] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + affected interface(s). This leads to the following problem: If + Router Advertisements are received on some, but not all, interfaces, + a multihomed host could choose to only send packets out on the + interfaces on which it has received Router Advertisements. A key + assumption made here, however, is that routers on those other + interfaces will be able to route packets to the ultimate destination, + even when those destinations reside on the subnet to which the sender + connects, but has no on-link prefix information. Should the + assumption be FALSE, communication would fail. Even if the + assumption holds, packets will traverse a suboptimal path. + +Appendix B: Future Extensions + + Possible extensions for future study are: + + o Using dynamic timers to be able to adapt to links with widely + varying delay. Measuring round-trip times, however, requires + acknowledgments and sequence numbers in order to match received + Neighbor Advertisements with the actual Neighbor Solicitation that + triggered the advertisement. Implementors wishing to experiment + with such a facility could do so in a backwards-compatible way by + defining a new option carrying the necessary information. Nodes + not understanding the option would simply ignore it. + + o Adding capabilities to facilitate the operation over links that + currently require hosts to register with an address resolution + server. This could, for instance, enable routers to ask hosts to + send them periodic unsolicited advertisements. Once again, this + can be added using a new option sent in the Router Advertisements. + + o Adding additional procedures for links where asymmetric and non- + transitive reachability is part of normal operations. Such + procedures might allow hosts and routers to find usable paths on, + e.g., radio links. + + + + + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 88] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Appendix C: State Machine for the Reachability State + + This appendix contains a summary of the rules specified in Sections + 7.2 and 7.3. This document does not mandate that implementations + adhere to this model as long as their external behavior is consistent + with that described in this document. + + When performing address resolution and Neighbor Unreachability + Detection the following state transitions apply using the conceptual + model: + + State Event Action New state + + - Packet to send. Create entry. INCOMPLETE + Send multicast NS. + Start retransmit timer + + INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE + less than N Start retransmit + retransmissions. timer + + INCOMPLETE Retransmit timeout, Discard entry - + N or more Send ICMP error + retransmissions. + + INCOMPLETE NA, Solicited=0, Record link-layer STALE + Override=any address. Send queued + packets. + + INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE + Override=any address. Send queued + packets. + + INCOMPLETE NA, Solicited=any, Update content of unchanged + Override=any, No IsRouter flag + Link-layer address + + - NS, RS, Redirect - - + No link-layer address + + !INCOMPLETE NA, Solicited=1, - REACHABLE + Override=0 + Same link-layer + address as cached. + + !INCOMPLETE NA, Solicited=any, Update content of unchanged + Override=any, No IsRouter flag. + link-layer address + + + +Narten, et al. Standards Track [Page 89] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + REACHABLE NA, Solicited=1, - STALE + Override=0 + Different link-layer + address than cached. + + STALE, PROBE NA, Solicited=1, - unchanged + Or DELAY Override=0 + Different link-layer + address than cached. + + !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE + Override=1 address (if + different). + + !INCOMPLETE NA, Solicited=0, - unchanged + Override=0 + + !INCOMPLETE NA, Solicited=0, - unchanged + Override=1 + Same link-layer + address as cached. + + !INCOMPLETE NA, Solicited=0, Record link-layer STALE + Override=1 address. + Different link-layer + address than cached. + + !INCOMPLETE upper-layer reachability - REACHABLE + confirmation + + REACHABLE timeout, more than - STALE + N seconds since + reachability confirm. + + STALE Sending packet Start delay timer DELAY + + DELAY Delay timeout Send unicast NS probe PROBE + Start retransmit timer + + PROBE Retransmit timeout, Retransmit NS PROBE + less than N + retransmissions. + + PROBE Retransmit timeout, Discard entry - + N or more + retransmissions. + + + + + +Narten, et al. Standards Track [Page 90] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + The state transitions for receiving unsolicited information other + than Neighbor Advertisement messages apply to either the source of + the packet (for Neighbor Solicitation, Router Solicitation, and + Router Advertisement messages) or the target address (for Redirect + messages) as follows: + + State Event Action New state + + - NS, RS, RA, Redirect Create entry. STALE + + INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE + address. Send queued + packets. + + !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE + Different link-layer address + address than cached. + + INCOMPLETE NS, RS No link-layer - unchanged + address + + !INCOMPLETE NS, RS, RA, Redirect - unchanged + Same link-layer + address as cached. + +Appendix D: Summary of IsRouter Rules + + This appendix presents a summary of the rules for maintaining the + IsRouter flag as specified in this document. + + The background for these rules is that the ND messages contain, + either implicitly or explicitly, information that indicates whether + or not the sender (or Target Address) is a host or a router. The + following assumptions are used: + + - The sender of a Router Advertisement is implicitly assumed to be a + router. + + - Neighbor Solicitation messages do not contain either an implicit + or explicit indication about the sender. Both hosts and routers + send such messages. + + - Neighbor Advertisement messages contain an explicit "IsRouter + flag", the R-bit. + + + + + + + +Narten, et al. Standards Track [Page 91] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - The target of the redirect, when the target differs from the + destination address in the packet being redirected, is implicitly + assumed to be a router. This is a natural assumption since that + node is expected to be able to forward the packets towards the + destination. + + - The target of the redirect, when the target is the same as the + destination, does not carry any host vs. router information. All + that is known is that the destination (i.e., target) is on-link + but it could be either a host or a router. + + The rules for setting the IsRouter flag are based on the information + content above. If an ND message contains explicit or implicit + information, the receipt of the message will cause the IsRouter flag + 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 IsRouter state. When the receipt of such a message causes a + Neighbor Cache entry to be created, this document specifies that the + IsRouter flag be set to FALSE. There is greater potential for + mischief when a node incorrectly thinks a host is a router, than the + other way around. In these cases, a subsequent Neighbor + Advertisement or Router Advertisement message will set the correct + IsRouter value. + +Appendix E: Implementation Issues + +E.1. Reachability Confirmations + + Neighbor Unreachability Detection requires explicit confirmation that + a forward-path is functioning properly. To avoid the need for + Neighbor Solicitation probe messages, upper-layer protocols should + provide such an indication when the cost of doing so is small. + Reliable connection-oriented protocols such as TCP are generally + aware when the forward-path is working. When TCP sends (or receives) + data, for instance, it updates its window sequence numbers, sets and + cancels retransmit timers, etc. Specific scenarios that usually + indicate a properly functioning forward-path include: + + - Receipt of an acknowledgment that covers a sequence number (e.g., + data) not previously acknowledged indicates that the forward path + was working at the time the data was sent. + + - Completion of the initial three-way handshake is a special case of + the previous rule; although no data is sent during the handshake, + the SYN flags are counted as data from the sequence number + perspective. This applies to both the SYN+ACK for the active open + and the ACK of that packet on the passively opening peer. + + + + +Narten, et al. Standards Track [Page 92] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + - Receipt of new data (i.e., data not previously received) indicates + that the forward-path was working at the time an acknowledgment + was sent that advanced the peer's send window that allowed the new + data to be sent. + + To minimize the cost of communicating reachability information + between the TCP and IP layers, an implementation may wish to rate- + limit the reachability confirmations its sends IP. One possibility + is to process reachability only every few packets. For example, one + might update reachability information once per round-trip time, if an + implementation only has one round-trip timer per connection. For + those implementations that cache Destination Cache entries within + control blocks, it may be possible to update the Neighbor Cache entry + directly (i.e., without an expensive lookup) once the TCP packet has + been demultiplexed to its corresponding control block. For other + implementations, it may be possible to piggyback the reachability + confirmation on the next packet submitted to IP assuming that the + implementation guards against the piggybacked confirmation becoming + stale when no packets are sent to IP for an extended period of time. + + TCP must also guard against thinking "stale" information indicates + current reachability. For example, new data received 30 minutes + after a window has opened up does not constitute a confirmation that + 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 + 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 + the window update did not reach the peer. + + For UDP-based applications (Remote Procedure Call (RPC), DNS), it is + relatively simple to make the client send reachability confirmations + when the response packet is received. It is more difficult and in + some cases impossible for the server to generate such confirmations + since there is no flow control, i.e., the server cannot determine + whether a received request indicates that a previous response reached + the client. + + Note that an implementation cannot use negative upper-layer advice as + a replacement for the Neighbor Unreachability Detection algorithm. + Negative advice (e.g., from TCP when there are excessive + 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 + when the path from the receiver of the data is not functioning, + causing none of the acknowledgment packets to reach the sender. + + + + + + + +Narten, et al. Standards Track [Page 93] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Appendix F: Changes from RFC 2461 + + o Removed references to IPsec AH and ESP for securing messages or as + part of validating the received message. + + o Added Section 3.3. + + o Updated Section 11 to include more detailed discussion on threats, + IPsec limitations, and use of SEND. + + o Removed the on-link assumption in Section 5.2 based on RFC 4942, + "IPv6 Neighbor Discovery On-Link Assumption Considered Harmful". + + o Clarified the definition of the Router Lifetime field in Section + 4.2. + + o Updated the text in Sections 4.6.2 and 6.2.1 to indicate that the + preferred lifetime must not be larger than valid lifetime. + + o Removed the reference to stateful configuration and added reference + for DHCPv6 instead. + + o Added the IsRouter flag definition to Section 6.2.1 to allow for + mixed host/router behavior. + + o Allowed mobile nodes to be exempt from adding random delays before + sending an RS during a handover. + + o Updated the definition of the prefix length in the prefix option. + + o Updated the applicability to NBMA links in the introduction and + added references to 3GPP RFCs. + + o Clarified that support for load balancing is limited to routers. + + o Clarified router behavior when receiving a Router Solicitation + without Source Link-Layer Address Option (SLLAO). + + o Clarified that inconsistency checks for CurHopLimit are done for + non-zero values only. + + o Rearranged Section 7.2.5 for clarity, and described the processing + when receiving the NA in INCOMPLETE state. + + o Added clarifications in Section 7.2 on how a node should react upon + receiving a message without SLLAO. + + o Added new IANA section. + + + +Narten, et al. Standards Track [Page 94] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + + o Miscellaneous editorials. + +Acknowledgments + + The authors of RFC 2461 would like to acknowledge the contributions + of the IPV6 working group and, in particular, (in alphabetical order) + Ran Atkinson, Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, + Richard Draves, Francis Dupont, Robert Elz, Robert Gilligan, Robert + Hinden, Tatuya Jinmei, Allison Mankin, Dan McDonald, Charles Perkins, + 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. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 95] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Authors' Addresses + + Thomas Narten + IBM Corporation + P.O. Box 12195 + Research Triangle Park, NC 27709-2195 + USA + + Phone: +1 919 254 7798 + EMail: narten@us.ibm.com + + + Erik Nordmark + Sun Microsystems, Inc. + 17 Network Circle + Menlo Park, CA 94025 + USA + + Phone: +1 650 786 2921 + Fax: +1 650 786 5896 + EMail: erik.nordmark@sun.com + + + William Allen Simpson + Daydreamer + Computer Systems Consulting Services + 1384 Fontaine + Madison Heights, Michigan 48071 + USA + + EMail: william.allen.simpson@gmail.com + + + Hesham Soliman + Elevate Technologies + + EMail: hesham@elevatemobile.com + + + + + + + + + + + + + + +Narten, et al. Standards Track [Page 96] + +RFC 4861 Neighbor Discovery in IPv6 September 2007 + + +Full Copyright Statement + + Copyright (C) The IETF Trust (2007). + + This document is subject to the rights, licenses and restrictions + contained in BCP 78, and except as set forth therein, the authors + retain all their rights. + + This document and the information contained herein are provided on an + "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS + OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND + THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS + OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF + THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED + WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. + +Intellectual Property + + The IETF takes no position regarding the validity or scope of any + Intellectual Property Rights or other rights that might be claimed to + pertain to the implementation or use of the technology described in + this document or the extent to which any license under such rights + might or might not be available; nor does it represent that it has + made any independent effort to identify any such rights. Information + on the procedures with respect to rights in RFC documents can be + found in BCP 78 and BCP 79. + + Copies of IPR disclosures made to the IETF Secretariat and any + assurances of licenses to be made available, or the result of an + attempt made to obtain a general license or permission for the use of + such proprietary rights by implementers or users of this + specification can be obtained from the IETF on-line IPR repository at + http://www.ietf.org/ipr. + + The IETF invites any interested party to bring to its attention any + copyrights, patents or patent applications, or other proprietary + rights that may cover technology that may be required to implement + this standard. Please address the information to the IETF at + ietf-ipr@ietf.org. + + + + + + + + + + + + +Narten, et al. Standards Track [Page 97] +