idnits 2.17.1 draft-ietf-ipngwg-discovery-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 74 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. == There are 1 instance of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 342: '...neighbors. All interfaces MUST have a...' RFC 2119 keyword, line 343: '...ddress. Routers MUST NOT forward pack...' RFC 2119 keyword, line 361: '... MUST...' RFC 2119 keyword, line 365: '... MUST NOT...' RFC 2119 keyword, line 369: '... SHOULD...' (195 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'ANYCST' is defined on line 3197, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 3212, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRCONF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDR-ARCH' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCST') -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ETHER' ** Obsolete normative reference: RFC 1825 (ref. 'IPv6-SA') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'IPv6-AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'IPv6-ESP') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1620 (ref. 'SH-MEDIA') ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'SYNC' Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Thomas Narten, IBM 2 September 15, 1995 Erik Nordmark, Sun Microsystems 3 W A Simpson, Daydreamer 5 Neighbor Discovery for IP Version 6 (IPv6) 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. 29 This Internet Draft expires March 15, 1996. 31 Abstract 33 This document specifies the Neighbor Discovery protocol for IP 34 Version 6. IPv6 nodes on the same link use Neighbor Discovery to 35 discover each other's presence, to determine each other's link-layer 36 addresses, to find routers and to maintain reachability information 37 about the paths to active neighbors. 39 Contents 41 Status of this Memo.......................................... 1 43 1. INTRODUCTION............................................. 4 45 2. TERMINOLOGY.............................................. 4 46 2.1. General............................................. 4 47 2.2. Link Types.......................................... 7 48 2.3. Addresses........................................... 8 49 2.4. Requirements........................................ 9 51 3. PROTOCOL OVERVIEW........................................ 9 52 3.1. Comparison with IPv4................................ 13 53 3.2. Supported Link Types................................ 15 55 4. CONCEPTUAL MODEL OF A HOST............................... 16 56 4.1. Conceptual Data Structures.......................... 16 57 4.2. Conceptual Sending Algorithm........................ 18 58 4.3. Garbage Collection and Timeout Requirements......... 19 60 5. ROUTER AND PREFIX DISCOVERY.............................. 20 61 5.1. Message Formats..................................... 21 62 5.1.1. Router Solicitation Message Format............. 21 63 5.1.2. Router Advertisement Message Format............ 22 64 5.2. Router Specification................................ 24 65 5.2.1. Router Configuration Variables................. 24 66 5.2.2. Validation of Router Solicitation Messages..... 27 67 5.2.3. Router Behavior................................ 28 68 5.2.4. Router Advertisement Consistency............... 32 69 5.2.5. Link-local Address Change...................... 33 70 5.3. Host Specification.................................. 33 71 5.3.1. Host Configuration Variables................... 33 72 5.3.2. Host Variables................................. 34 73 5.3.3. Validation of Router Advertisement Messages.... 34 74 5.3.4. Host Behavior.................................. 35 76 6. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 39 77 6.1. Message Formats..................................... 39 78 6.1.1. Neighbor Solicitation Message Format........... 39 79 6.1.2. Neighbor Advertisement Message Format.......... 42 80 6.2. Address Resolution.................................. 44 81 6.2.1. Node Specification............................. 44 82 6.2.2. Sending Neighbor Solicitations................. 44 83 6.2.3. Validation of Neighbor Solicitations........... 45 84 6.2.4. Receipt of Neighbor Solicitations.............. 46 85 6.2.5. Sending Solicited Neighbor Advertisements...... 46 86 6.2.6. Validation of Neighbor Advertisements.......... 47 87 6.2.7. Receipt of Neighbor Advertisments.............. 47 88 6.2.8. Sending Unsolicited Neighbor Advertisements.... 48 89 6.2.9. Anycast Neighbor Advertisements................ 49 90 6.2.10. Proxy Neighbor Advertisements................. 50 91 6.3. Neighbor Unreachability Detection................... 50 92 6.3.1. Reachability Confirmation...................... 51 93 6.3.2. Node Behavior.................................. 52 95 7. REDIRECT FUNCTION........................................ 55 96 7.1. Redirect Message Format............................. 55 97 7.2. Router Specification................................ 57 98 7.3. Host Specification.................................. 58 99 7.3.1. Validation of Redirect Messages................ 58 100 7.3.2. Host Behavior.................................. 59 102 8. OPTIONS.................................................. 59 103 8.1. Source/Target Link-layer Address.................... 61 104 8.2. Prefix Information.................................. 62 105 8.3. Redirected Header................................... 64 106 8.4. MTU................................................. 64 108 9. MULTIHOMED HOSTS......................................... 65 110 10. PROTOCOL CONSTANTS...................................... 67 112 11. FUTURE EXTENSIONS....................................... 68 114 12. OPEN ISSUES............................................. 68 116 13. SECURITY CONSIDERATIONS................................. 68 118 REFERENCES................................................... 71 120 AUTHORS' ADDRESSES........................................... 72 122 CHANGES SINCE PREVIOUS DOCUMENT.............................. 73 124 1. INTRODUCTION 126 This specification defines the Neighbor Discovery (ND) protocol for 127 Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use 128 Neighbor Discovery to determine the link-layer addresses for neighbors 129 known to reside on attached links and to quickly purge cached values 130 that become invalid. Hosts also use Neighbor Discovery to find 131 neighboring routers that are willing to forward packets on their behalf. 132 Finally, nodes use the protocol to actively keep track of which 133 neighbors are reachable and which are not, and to detect changed link- 134 layer addresses. When a router or the path to a router fails, a host 135 actively searches for functioning alternates. 137 This document is a revision of 138 which was itself based on the protocol specified in the two documents: 139 , and 140 142 The authors would like to acknowledge the contributions the IPNGWG 143 working group an, in particular, (in alphabetical order) Ran Atkinson, 144 Jim Bound, Scott Bradner, Stephen Deering, Robert Hinden, Allison 145 Mankin, Dan McDonald, Charles Perkins, and Sue Thomson. 147 2. TERMINOLOGY 149 2.1. General 151 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 152 are used only in contexts where necessary to avoid 153 ambiguity. 155 ICMP - Internet Message Control Protocol for the Internet 156 Protocol Version 6. The terms ICMPv4 and ICMPv6 are 157 used only in contexts where necessary to avoid 158 ambiguity. 160 node - a device that implements IP. 162 router - a node that forwards IP packets not explicitly 163 addressed to itself. 165 host - any node that is not a router. 167 upper layer - a protocol layer immediately above IP. Examples are 168 transport protocols such as TCP and UDP, control 169 protocols such as ICMP, routing protocols such as OSPF, 170 and internet or lower-layer protocols being "tunneled" 171 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 172 or IP itself. 174 link - a communication facility or medium over which nodes can 175 communicate at the link layer, i.e., the layer 176 immediately below IP. Examples are Ethernets (simple 177 or bridged); PPP links; X.25, Frame Relay, or ATM 178 networks; and internet (or higher) layer "tunnels", 179 such as tunnels over IPv4 or IPv6 itself. 181 interface - a node's attachment to a link. 183 neighbors - nodes attached to the same link. 185 address - an IP-layer identifier for an interface or a set of 186 interfaces. 188 anycast address 189 - an identifier for a set of interfaces (typically 190 belonging to different nodes). A packet sent to an 191 anycast address is delivered to one of the interfaces 192 identified by that address (the "nearest" one, 193 according to the routing protocol's measure of 194 distance). See [ADDR-ARCH]. 196 link-layer address 197 - a link-layer identifier for an interface. Examples 198 include IEEE 802 addresses for Ethernet links and E.164 199 addresses for ISDN links. 201 on-link - an address that is assigned to an interface on a 202 specified link. A node considers an address to be on- 203 link if: 205 - it is covered by one of the link's prefixes, or 206 - a neighboring router specifies the address as the 207 target of a Redirect message, or 208 - a Neighbor Advertisement message is received for 209 the (target) address, or 210 - a Neighbor Discovery message is received from the 211 address. 213 off-link - the opposite of "on-link"; an address that is not 214 assigned to any interfaces on the specified link. 216 reachability 217 - whether or not the one-way "forward" path to a neighbor 218 is functioning properly. In particular, whether 219 packets sent to a neighbor are reaching the IP layer on 220 the neighboring machine and are being processed 221 properly by the receiving layer. For neighboring 222 routers, reachability means that packets sent by a 223 node's IP layer are delivered to the router's IP layer, 224 and the router is indeed forwarding packets (i.e., it 225 is configured as a router, not a host). For hosts, 226 reachability means that packets sent by a node's IP 227 layer are delivered to the neighbor host's IP layer. 229 packet - an IP header plus payload. 231 link MTU - the maximum transmission unit, i.e., maximum packet 232 size in octets, that can be conveyed in one piece over 233 a link. 235 target - an address about which address resolution information 236 is sought, or an address which is the new first-hop 237 when being redirected. 239 proxy - a router that responds to Neighbor Discovery query 240 messages on behalf of another node. A router acting on 241 behalf of a mobile node that has moved off-link 242 potentially acts as a proxy for the mobile node. 244 ICMP destination unreachable indication 245 - an error indication returned to the original sender of 246 a packet that cannot be delivered for the reasons 247 outlined in [ICMPv6]. If the error occurs on a node 248 other than the node originating the packet, an ICMP 249 error message is generated. If the error occurs on the 250 originating node, an implementation is not required to 251 actually create and send an ICMP error packet to the 252 source, as long as the sender is notified through an 253 appropriate mechanism (e.g., return value from a 254 procedure call). Note, however, that an implementation 255 may find it convenient in some cases to return errors 256 to the sender by taking the offending packet, 257 generating an ICMP error message, and then delivering 258 it (locally) through the generic error handling 259 routines. 261 2.2. Link Types 263 Different link layers have different properties. The ones of concern to 264 Neighbor Discovery are: 266 multicast - a link that supports some mechanism at the link 267 layer for sending packets to all (i.e. broadcast) or 268 a subset of all neighbors. Multicast/broadcast can 269 be provided by a variety of link layer mechanisms 270 such as the physical link layer itself (for example, 271 Ethernet), replicated unicast packets sent by the 272 link layer software, or multicast servers (such as 273 in ATM). Note that all point-to-point links are 274 multicast links. 276 point-to-point - a link that connects exactly two interfaces. A 277 point-to-point link is assumed to have multicast 278 capability and have a link-local address. 280 non-broadcast multi-access (NBMA) 281 - a link to which more than two interfaces can attach, 282 but that does not support any form of multicast or 283 broadcast (e.g., X.25). 285 shared media - a link that allows direct communication among a 286 number of nodes, but attached nodes are configured 287 in such a way that they do not have complete prefix 288 information for all on-link destinations. That is, 289 at the IP level, nodes on the same link may not know 290 that they are neighbors; by default, they 291 communicate through a router. Examples are large 292 (switched) public data networks such as SMDS and B- 293 ISDN. Also known as "large clouds". See [SH- 294 MEDIA]. 296 variable MTU - a link that does not have a well-defined MTU (e.g., 297 IEEE 802.5 token rings). Many links (e.g., 298 Ethernet) have a standard MTU defined by the link- 299 layer protocol. 301 asymmetric reachability 302 - a link where non-reflexive and/or non-transitive 303 reachability is part of normal operation. (Non- 304 reflexive reachability means packets from A reach B 305 but packets from B don't reach A. Non-transitive 306 reachability means packets from A reach B, and 307 packets from B reach C, but packets from A don't 308 reach C.) Many radio links exhibit these 309 properties. 311 2.3. Addresses 313 Neighbor Discovery makes use of a number of different addresses defined 314 in [ADDR-ARCH], including: 316 all-nodes multicast address 317 - the link-local scope address to reach all nodes. 318 FF02::1 320 all-routers multicast address 321 - the link-local scope address to reach all routers. 322 FF02::2 324 solicited-node multicast address 325 - a link-local scope multicast address that is computed 326 as a function of the solicited target's address. The 327 solicited-node multicast address is formed by taking 328 the low-order 32 bits of the target IP address and 329 appending those bits to the 96-bit prefix 330 FF02:0:0:0:0:1 to produce a multicast address within 331 the range FF02::1:0:0 to FF02::1:FFFF:FFFF. For 332 example, the solicited node multicast address 333 corresponding to the IP address 4037::01:800:200E:8C6C 334 is FF02::1:200E:8C6C. IP addresses that differ only in 335 the high-order bits, e.g. due to multiple high-order 336 prefixes associated with different providers, will map 337 to the same solicited-node address thereby reducing the 338 number of multicast addresses a node must join. 340 link-local address 341 - a unicast address having link-only scope that can be 342 used to reach neighbors. All interfaces MUST have a 343 link-local address. Routers MUST NOT forward packets 344 with a link-local source address. See [ADDR-ARCH]. 346 unspecified address 347 - a reserved address value that indicates the lack of an 348 address (e.g., the address is unknown). It is never 349 used as a destination address, but may be used as a 350 source address if the sender does not (yet) know its 351 own address (e.g., while verifying an address is unused 352 during address autoconfiguration [ADDRCONF]). The 353 unspecified address has a value of 0:0:0:0:0:0:0:0. 355 2.4. Requirements 357 Throughout this document, the words that are used to define the 358 significance of the particular requirements are capitalized. These 359 words are: 361 MUST 362 This word or the adjective "REQUIRED" means that the item is an 363 absolute requirement of this specification. 365 MUST NOT 366 This phrase means the item is an absolute prohibition of this 367 specification. 369 SHOULD 370 This word or the adjective "RECOMMENDED" means that there may 371 exist valid reasons in particular circumstances to ignore this 372 item, but the full implications should be understood and the 373 case carefully weighed before choosing a different course. 375 SHOULD NOT 376 This phrase means that there may exist valid reasons in 377 particular circumstances when the listed behavior is acceptable 378 or even useful, but the full implications should be understood 379 and the case carefully weighted before implementing any behavior 380 described with this label. 382 MAY This word or the adjective "OPTIONAL" means that this item is 383 truly optional. One vendor may choose to include the item 384 because a particular marketplace requires it or because it 385 enhances the product, for example, another vendor may omit the 386 same item. 388 3. PROTOCOL OVERVIEW 390 This protocol solves a set of problems related to the interaction 391 between nodes attached to the same link. It defines mechanisms for 392 solving each of the following problems: 394 Router Discovery: How hosts locate routers that reside on an 395 attached link. 397 Prefix Discovery: How hosts discover the set of address prefixes 398 that define which destinations are on-link for an 399 attached link. (Nodes use prefixes to distinguish 400 destinations that reside on-link from those only 401 reachable through a router.) 403 Parameter Discovery: How a node learns such link parameters as the 404 link MTU or such Internet parameters as the maximum hop 405 limit value to place in outgoing packets. 407 Address Autoconfiguration: How nodes automatically configure an 408 address for an interface. 410 Address Resolution: How nodes determine the link-layer address of an 411 on-link destination (e.g., a neighbor) given only the 412 destination's IP address. 414 Next-hop determination: The algorithm for mapping an IP destination 415 address into the IP address of the neighbor to which 416 traffic for the destination should be sent. The next-hop 417 can be a router or the destination itself. 419 Neighbor Unreachability Detection: How nodes determine that a 420 neighbor is no longer reachable. For neighbors used as 421 routers, alternate default routers can be tried. For 422 both routers and hosts, address resolution can be 423 performed again. 425 Duplicate Address Detection: How a node determines that an address 426 it wishes to use is not already in use by another node. 428 Redirect: How a router informs a host of a better first-hop node to 429 reach a particular destination. 431 Neighbor Discovery defines five different ICMP packet types: A pair of 432 Router Solicitation and Router Advertisement messages, a pair of 433 Neighbor Solicitation and Neighbor Advertisements messages, and a 434 Redirect message. The messages serve the following purpose: 436 Router Solicitation: When an interface becomes enabled, hosts may 437 send out Router Solicitations that request routers to 438 generate Router Advertisements immediately rather than at 439 their next scheduled time. 441 Router Advertisement: Routers advertise their presence together with 442 various link and Internet parameters either periodically, 443 or in response to an explicit Router Solicitation 444 message. Router Advertisements contain prefixes that are 445 used for on-link determination and/or address 446 configuration, a Maximum Hop Limit value, etc. 448 Neighbor Solicitation: Sent by a node to determine the link-layer 449 address of a neighbor, or to verify that a neighbor is 450 still reachable via a cached link-layer address. 451 Neighbor Solicitations are also used for Duplicate 452 Address Detection. 454 Neighbor Advertisement: A response to a Neighbor Solicitation 455 message. A node may also send unsolicited Neighbor 456 Advertisements to announce a link-layer address change. 458 Redirect: Used by routers to inform hosts of a better first hop for 459 a destination. 461 On multicast-capable links, each router periodically multicasts a Router 462 Advertisement packet announcing its availability. A host receives 463 Router Advertisements from all routers, building a list of default 464 routers. Routers generate Router Advertisements frequently enough that 465 hosts will learn of their presence within a few minutes, but not 466 frequently enough to rely on an absence of advertisements to detect 467 router failure; a separate Neighbor Unreachability Detection algorithm 468 provides failure detection. 470 Router Advertisements contain a list of prefixes used for on-link 471 determination and/or autonomous address configuration; flags associated 472 with the prefixes specify the intended uses of a particular prefix. 473 Hosts use the advertised on-link prefixes to build and maintain a list 474 that is used in deciding when a packet's destination is on-link or 475 beyond a router. Note that a destination can be on-link even though it 476 is not covered by any advertised on-link prefix. In such cases a router 477 can send a Redirect informing the sender that the destination is a 478 neighbor. 480 Router Advertisements (and per-prefix flags) allow routers to inform 481 hosts how to perform Address Autoconfiguration. For example, routers 482 can specify whether hosts should use stateful (DHCPv6) and/or autonomous 483 (stateless) address configuration. The exact semantics and usage of the 484 address configuration-related information is specified in [ADDRCONF]. 486 Router Advertisement messages also contain Internet parameters such as 487 the maximum hop that hosts should use in outgoing packets and, 488 optionally, link parameters such as the link MTU. This facilitates 489 centralized administration of critical parameters that can be set on 490 routers and automatically propagated to all attached hosts. 492 Nodes accomplish Address Resolution by multicasting a Neighbor 493 Solicitation that asks the target node to return its link-layer address. 494 Neighbor Solicitation messages are multicast to the solicited-node 495 multicast address of the target address. The target returns its link- 496 layer address in a unicast Neighbor Advertisement message. A single 497 request-response pair of packets is sufficient for both the initiator 498 and the target to resolve each other's link-layer addresses; the 499 initiator includes its IP address and link-layer address in the Neighbor 500 Solicitation. 502 Neighbor Solicitation messages can also be used to determine if more 503 than one node has been configured to use a particular unicast address. 504 The use of Neighbor Solicitation messages for Duplicate Address 505 Detection is specified in [ADDRCONF]. 507 Neighbor Unreachability Detection detects the failure of a neighbor or 508 the failure of the forward path to the neighbor. Doing so requires 509 positive confirmation that packets sent to a neighbor are actually 510 reaching that neighbor and being processed properly by its IP layer. 511 Neighbor Unreachability Detection uses confirmation from two sources. 512 When possible, upper-layer protocols provide a positive confirmation 513 that a connection is making "forward progress", that is, previously sent 514 data is known to have been delivered correctly (e.g., new 515 acknowledgments were received recently). When positive confirmation is 516 not forthcoming through such "hints", a node sends explicit unicast 517 Neighbor Solicitation messages that solicit Neighbor Advertisements as 518 reachability confirmation from the next hop. To reduce unnecessary 519 network traffic, probe messages are only sent to neighbors to which the 520 node is actively sending packets. 522 In addition to addressing the above general problems, Neighbor Discovery 523 also handles the following situations: 525 Link-layer address change - A node that knows its link-layer 526 address has changed can multicast a few (unsolicited) Neighbor 527 Advertisement packets to all nodes to quickly (but unreliably) 528 update cached link-layer addresses that have become invalid. 529 Note that the sending of unsolicited advertisements is a 530 performance enhancement only (e.g., unreliable). The Neighbor 531 Unreachability Detection algorithm ensures that all nodes will 532 reliably discover the new address, though the delay may be 533 somewhat longer. 535 Inbound load balancing - Nodes with replicated interfaces may want 536 to load balance the reception of incoming packets across 537 multiple network interfaces on the same link. Such nodes have 538 multiple link-layer addresses assigned to the same interface. 539 For example, a single network driver could represent multiple 540 network interface cards as a single logical interface having 541 multiple link-layer addresses. Load balancing is handled by 542 allowing routers to omit the source link-layer address from 543 Router Advertisement packets, thereby forcing neighbors to use 544 Neighbor Solicitation messages to learn the link-layer 545 addresses. Returned Neighbor Advertisement messages can then 546 contain link-layer addresses that differ depending on who 547 issued the solicitation. 549 Anycast addresses - Anycast addresses identify one of a set of 550 nodes providing an equivalent service, and multiple nodes on 551 the same link may be configured to recognize the same Anycast 552 address. Neighbor Discovery handles anycasts by having nodes 553 expect to receive multiple Neighbor Advertisements for the 554 same target. All advertisements for anycast addresses are 555 tagged as being "Secondary" advertisements. This invokes 556 specific rules to determine which of potentially multiple 557 advertisements should be used. 559 Proxy advertisements - A router willing to accept packets on behalf 560 of a target address that is unable to respond to Neighbor 561 Solicitations can issue Secondary Neighbor Advertisements. 562 There is currently no specified use of proxy, but proxy 563 advertising could potentially be used to handle cases like 564 mobile nodes that have moved off-link. However, it is not 565 intended as a general mechanism to handle nodes that, e.g., do 566 not implement this protocol. 568 3.1. Comparison with IPv4 570 The IPv6 Neighbor Discovery protocol corresponds to a combination of the 571 IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP 572 Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol 573 or mechanism for Neighbor Unreachability Detection, although Hosts 574 Requirements [HR-CL] does specify some possible algorithms for Dead 575 Gateway Detection (a subset of the problems Neighbor Unreachability 576 Detection tackles). 578 The Neighbor Discovery protocol provides a multitude of improvements 579 over the IPv4 set of protocols: 581 Router Discovery is part of the base protocol set; there is no need 582 for hosts to "snoop" the routing protocols. 584 Router advertisements carry link-layer addresses; no additional 585 packet exchange is needed to resolve the router's link-layer 586 address. 588 Router advertisements carry prefixes for a link; there is no need 589 to have a separate mechanism to configure the "netmask". 591 Router advertisements enable Address Autoconfiguration. 593 Routers can advertise an MTU for hosts to use on the link, ensuring 594 that all nodes use the same MTU value on links lacking a well- 595 defined MTU. 597 Address Resolution multicasts are "spread" over 4 billion (2^32) 598 multicast addresses greatly reducing Address Resolution related 599 interrupts on nodes other than the target. Moreover, non-IPv6 600 machines should not be interrupted at all. 602 Redirects contain the link-layer address of the new first hop; 603 separate Address Resolution is not needed upon receiving a 604 redirect. 606 Multiple prefixes can be associated with the same link. By 607 default, hosts learn all on-link prefixes from Router 608 Advertisements. However, routers may be configured to omit some or 609 all prefixes from Router Advertisements. In such cases hosts 610 assume that destinations are off-link and send traffic to routers. 611 A router can then issue redirects as appropriate. 613 Unlike IPv4, the recipient of an IPv6 redirect assumes that the new 614 next-hop is on-link. In IPv4, a host ignores redirects specifying 615 a next-hop that is not on-link according to the link's network 616 mask. The IPv6 redirect mechanism is analogous to the XRedirect 617 facility specified in [SH-MEDIA]. It is expected to be useful on 618 non-broadcast and shared media links in which it is undesirable or 619 not possible for nodes to know all prefixes for on-link 620 destinations. 622 Neighbor Unreachability Detection is part of the base, 623 significantly improving the robustness of packet delivery in the 624 presence of failing routers, partially failing or partitioned links 625 and nodes that change their link-layer addresses. For instance, 626 mobile nodes can move off-link without losing any connectivity due 627 to stale ARP caches. 629 Unlike ARP, Neighbor Discovery detects half-link failures and 630 avoids sending traffic to neighbors with which two-way connectivity 631 is absent. 633 Placing address resolution at the ICMP layer makes the protocol 634 more media-independent than ARP and makes it possible to use 635 standard IP authentication and security mechanisms as appropriate 636 [IPv6-AUTH, IPv6-ESP]. 638 3.2. Supported Link Types 640 Neighbor Discovery supports links with different properties. In the 641 presence of certain properties only a subset of the ND protocol is 642 available: 644 point-to-point - Neighbor Discovery handles such links just like 645 multicast links. (Multicast can be trivially 646 provided on point to point links, and interfaces can 647 be assigned link-local addresses.) 649 multicast - All aspects of Neighbor Discovery are available. 651 non-broadcast multiple access (NBMA) 652 - The only Neighbor Discovery mechanisms available on 653 these links are Redirect handling and Neighbor 654 Unreachability Detection. 656 If hosts support manual configuration of a list of 657 default routers, the hosts can dynamically acquire 658 the link-layer addresses for their neighbors from 659 Redirect messages. 661 shared media - The Redirect message is modeled after the XRedirect 662 message in [SH-MEDIA] in order to simplify use of 663 the protocol on shared media links. 665 This specification does not address shared media 666 issues that only relate to routers, such as: 668 - How routers exchange reachability information on 669 a shared media link. 671 - How a router determines the link-layer address of 672 a host, which it needs to send redirect messages 673 to the host. 675 - How a router determines that it is the first hop 676 router for a received packet. 678 The protocol is extensible (through the definition 679 of new options) so that other solutions might be 680 possible in the future. 682 variable MTU - Neighbor Discovery allows routers to specify a MTU 683 for the link, which all nodes then use. All nodes 684 on a link must use the same MTU (or Maximum Receive 685 Unit) in order for multicast to work properly. When 686 multicasting, a sender has no way of knowing which 687 nodes will receive the packet, and cannot determine 688 a minimum packet size all receivers can process. 690 asymmetric reachability 691 - Neighbor Discovery detects the absence of symmetric 692 reachability; a node avoids paths to a neighbor with 693 which it does not have symmetric connectivity. 695 The Neighbor Unreachability Detection will typically 696 identify such half-links and the node will refrain 697 from using them. 699 The protocol can presumably be extended in the 700 future to find viable paths in environments that 701 lack reflexive and transitive connectivity. 703 4. CONCEPTUAL MODEL OF A HOST 705 This section describes a conceptual model of one possible data structure 706 organization that hosts (and to some extent routers) will maintain in 707 interacting with neighboring nodes. The described organization is 708 provided to facilitate the explanation of how the Neighbor Discovery 709 protocol should behave. This document does not mandate that 710 implementations adhere to this model as long as their behavior is 711 consistent with the protocol specification. 713 This model is only concerned with the aspects of host behavior directly 714 related to Neighbor Discovery. In particular, it does not concern 715 itself with such issues as source address selection or the selecting of 716 an outgoing interface on a multihomed host. 718 4.1. Conceptual Data Structures 720 Hosts will need to maintain the following pieces of information about an 721 interface: 723 Neighbor Cache - A set of entries about individual neighbors to which 724 traffic has been sent recently. Entries are keyed on 725 the neighbor's on-link IP address and contain such 726 information as its link-layer address, a flag 727 indicating whether the neighbor is a router or a host 728 (called "is_router" in this document), a pointer to 729 any queued packets waiting for Address Resolution to 730 complete, etc. 732 A Neighbor Cache entry also contains information used 733 by the Neighbor Unreachability Detection algorithm. 734 This includes the reachability state, the number of 735 unanswered probes, and the time the next Neighbor 736 Unreachability Detection event is scheduled to take 737 place. 739 Destination Cache 740 - A set of entries for each destination to which traffic 741 has been sent recently. The Destination Cache 742 includes both on-link and off-link destinations and 743 provides a level of indirection into the Neighbor 744 Cache; the Destination Cache maps a destination IP 745 address to the IP address of the next-hop neighbor. 746 Implementations may find it convenient to store 747 additional information not directly related to 748 Neighbor Discovery in Destination Cache entries, such 749 as the Path MTU (PMTU) and round trip timers 750 maintained by transport protocols. 752 Prefix List - A list of the prefixes that define a set of 753 addresses that are on-link. Prefix List entries are 754 created from information received in Router 755 Advertisements. Each entry has an associated 756 invalidation timer value (extracted from the 757 advertisement) used to delete prefixes that routers 758 stop advertising. A special "infinity" timer value 759 specifies that a prefix remains valid forever, unless 760 a new (finite) value is received in a subsequent 761 advertisement. 763 Default Router List 764 - A list of routers to which packets may be sent. 765 Router list entries point to entries in the Neighbor 766 Cache; the algorithm for selecting a default router 767 favors routers known to be reachable over those whose 768 reachability is suspect. Each entry also has an 769 associated invalidation timer value (extracted from 770 Router Advertisements) used to delete entries that are 771 no longer advertised. 773 Note that the above conceptual data structures can be implemented using 774 a variety of techniques. One possible implementation is to use a single 775 longest-match routing table for all of the above data structures. 776 However, in all cases it is important to not duplicate the conceptual 777 Neighbor Cache entry for a router in order to prevent redundant Neighbor 778 Unreachability Detection probes. 780 The Neighbor Cache contains information maintained by the Neighbor 781 Unreachability Detection algorithm. A key piece of information is a 782 neighbor's reachability state, which is one of three possible values: 784 INCOMPLETE Address Resolution is in progress and the link-layer 785 address of the neighbor has not yet been determined. 787 REACHABLE Roughly speaking, the neighbor is known to have been 788 reachable recently (within tens of seconds ago). 790 PROBE The neighbor may be reachable, but the last explicit 791 reachability confirmation was received long enough ago 792 that verification is now actively sought. 794 4.2. Conceptual Sending Algorithm 796 When sending a packet, a node uses a combination of the Destination 797 Cache, the Prefix List, and the Default Router List to determine the IP 798 address of the appropriate next hop, an operation known as "next-hop 799 determination". Once the IP address of the next hop is known, the 800 Neighbor Cache is consulted for link-level information about that 801 neighbor. 803 Next-hop determination operates as follows for unicast packets. The 804 sender examines the Prefix List to determine whether the packet's 805 destination is on- or off-link. If the destination is on-link, the 806 next-hop address is the same as the packet's destination address. If 807 the destination is off-link, the sender selects a router from the 808 Default Router List (following the rules described in Section 5.3.4). 809 If the Default Router List is empty, the sender assumes that the 810 destination is on-link. 812 For multicast packets the next-hop is always the (multicast) destination 813 address. 815 For efficiency reasons, next-hop determination is not performed on every 816 packet that is sent. Instead, the results of next-hop determination 817 computations are saved in the Destination Cache. When the sending node 818 has a packet to send, it first examines the Destination Cache. If no 819 entry exists for the destination, next-hop determination is invoked to 820 create a Destination Cache entry. 822 Once the IP address of the next-hop node is known, the sender examines 823 the Neighbor Cache for link-level information about that neighbor. If 824 no entry exists for a multicast destination, an entry is created using 825 the link specific mapping to a multicast link-layer address (see e.g. 826 [IPv6-ETHER]). If no entry exists for a unicast destination, the sender 827 creates a new one, sets its state to INCOMPLETE, sends a Neighbor 828 Solicitation message, and then queues the data packet pending completion 829 of Address Resolution. When a Neighbor Advertisement response is 830 received, the link-layer addresses is entered in the Neighbor Cache 831 entry and the queued packet is transmitted. The Address Resolution 832 mechanism is described in detail in Section 6.2. 834 Each time a Neighbor Cache entry is accessed while transmitting a 835 unicast packet, the sender checks Neighbor Unreachability Detection 836 related information according to the Neighbor Unreachability Detection 837 algorithm (Section 6.3), unless the upper-layer has indicated that such 838 checks are not needed. For instance, the Neighbor Discovery protocol 839 itself when sending packets should pass an indication to IP that the 840 packet should not trigger Neighbor Unreachability Detection. This 841 unreachability check might result in the sender transmitting a unicast 842 Neighbor Solicitation to verify that the neighbor is still reachable. 844 Next-hop determination is done the first time traffic is sent to a 845 destination. As long as subsequent communication to that destination 846 proceeds successfully, the Destination Cache entry continues to be used. 847 If at some point communication ceases to proceed, as determined by the 848 Neighbor Unreachability Detection algorithm, next-hop determination may 849 need to be performed again. For example, traffic through a failed 850 router should be switched to a working router. Likewise, it may be 851 possible to reroute traffic destined for a mobile node to a "mobility 852 agent". 854 Note that when a node redoes next-hop determination there is no need to 855 discard the complete Destination Cache entry. In fact, it is generally 856 beneficial to retain such cached information as the PMTU and round trip 857 timer values that may also be kept in the Destination Cache entry. 859 4.3. Garbage Collection and Timeout Requirements 861 The conceptual data structures described above use different mechanisms 862 for discarding potentially stale or unused information. 864 =46rom the perspective of correctness there is no need to periodically 865 purge Destination and Neighbor Cache entries. Although stale 866 information can potentially remain in the cache indefinitely, the 867 Neighbor Unreachability Detection algorithm ensures that stale 868 information is purged quickly if it is actually being used. 870 To limit the storage needed for the Destination and Neighbor Caches, a 871 node may need to garbage-collect old entries. However, care must be 872 taken to insure that sufficient space is always present to hold the 873 working set of active entries. A small cache may result in an excessive 874 number of Neighbor Discovery messages if entries are discarded and 875 rebuilt in quick succession. Any LRU-based policy that only reclaims 876 entries that have not been used in some time (e.g., ten minutes or more) 877 should be adequate for garbage-collecting unused entries. 879 A node should retain entries in the Default Router List and the Prefix 880 List until their lifetimes expire. However, a node may garbage collect 881 entries prematurely if it is low on memory. If not all routers are kept 882 on the Default Router list, a node should retain at least two entries in 883 the Default Router List (and preferably more) in order to maintain 884 robust connectivity for off-link destinations. 886 When removing an entry from the Default Router List or the Prefix List 887 there is no need to purge any entries from the Destination or Neighbor 888 Caches. Neighbor Unreachability Detection will efficiently purge any 889 entries in these caches that have become invalid. 891 5. ROUTER AND PREFIX DISCOVERY 893 This section describes message formats, router behavior and host 894 behavior related to the Router Discovery portion of Neighbor Discovery. 895 Router Discovery is used to locate neighboring routers as well as learn 896 prefixes and configuration parameters related to address 897 autoconfiguration. 899 Prefix Discovery provides a mechanism through which hosts learn of 900 ranges of IP addresses that reside on-link and thus can be reached 901 directly without going through a router. Routers advertise a set of 902 prefixes that cover those IP addresses that are on-link. Prefix 903 discovery is logically separate from Router Discovery. In practice, 904 prefix information is included in options piggybacked on Router 905 Advertisement messages to reduce network traffic. 907 Address Autoconfiguration information is also logically separate from 908 Router Discovery. To reduce network traffic, however, autoconfiguration 909 information is piggybacked on Router Discovery messages. In fact, the 910 same prefixes can be advertised for on-link determination and address 911 autoconfiguration by specifying the appropriate flags in the Prefix 912 Information options. This document does not define how 913 autoconfiguration information is processed. See [ADDRCONF] for details. 915 5.1. Message Formats 917 5.1.1. Router Solicitation Message Format 919 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 920 | Type | Code | Checksum | 921 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 922 | Reserved | 923 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 924 | Options ... 925 +-+-+-+-+-+-+-+-+-+-+-+- 927 IP Fields: 929 Source Address 930 MUST be the link-local address assigned to the 931 interface from which this message is sent. 933 Destination Address 934 The all-routers link-local multicast address. 936 Hop Count 1 938 Authentication Header 939 If a Security Association for the IP Authentication 940 Header exists between the sender and the destination 941 address, then the sender SHOULD include this header. 943 Routing Header MUST NOT be sent. 945 ICMP Fields: 947 Type 133 949 Code 0 951 Checksum The ICMP checksum. See [ICMPv6]. 953 Reserved This field is unused. It MUST be initialized to zero 954 by the sender and ignored by the receiver. 956 Options: 958 Source link-layer address 959 The link-layer address for the sender. This option 960 SHOULD be included on link layers that have addresses 961 so that routers responding to the request can unicast 962 a response without the need to first perform address 963 resolution. 965 Future versions of this protocol may define new option types. 966 Receivers MUST skip over and ignore any options they do not recognize 967 and continue processing the message. 969 5.1.2. Router Advertisement Message Format 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type | Code | Checksum | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Max Hop Limit |M|O| Reserved | Router Lifetime | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | Reachable Time | 977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 978 | Retrans Timer | 979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 980 | Options ... 981 +-+-+-+-+-+-+-+-+-+-+-+- 983 IP Fields: 985 Source Address 986 MUST be the link-local address assigned to the 987 interface from which this message is sent. 989 Destination Address 990 Either the Source Address of an invoking Router 991 Solicitation or the all-nodes link-local multicast 992 address. 994 Hop Count 1 996 Authentication Header 997 If a Security Association for the IP Authentication 998 Header exists between the sender and the destination 999 address, then the sender SHOULD include this header. 1001 Routing Header MUST NOT be sent. 1003 ICMP Fields: 1005 Type 134 1006 Code 0 1008 Checksum The ICMP checksum. See [ICMPv6]. 1010 Max Hop Limit 8-bit unsigned integer. The maximum hop limit that 1011 the router suggests that hosts use when sending IP 1012 packets. A value of zero means unspecified. 1014 M 1-bit "Managed address configuration" flag. Use the 1015 administered (stateful) protocol for address 1016 autoconfiguration in addition to any addresses 1017 autoconfigured using stateless address 1018 autoconfiguration. The use of this flag is described 1019 in [ADDRCONF]. 1021 O 1-bit "Other configuration" flag. Use the 1022 administered (stateful) protocol for autoconfiguration 1023 of other (non-address) information. The use of this 1024 flag is described in [ADDRCONF]. 1026 Reserved A 6-bit unused field. It MUST be initialized to zero 1027 by the sender and ignored by the receiver. 1029 Router Lifetime 1030 16-bit unsigned integer. The lifetime associated with 1031 the default router in units of seconds. The maximum 1032 value corresponds to 18.2 hours. A Lifetime of 0 1033 indicates that the router is not a default router and 1034 SHOULD NOT appear on the default router list. The 1035 Router Lifetime does not apply to information 1036 contained in any options in the message. Options that 1037 need time limits for their information include their 1038 own lifetime fields. 1040 Reachable Time 32-bit unsigned integer. The time, in milliseconds, 1041 that a node assumes a neighbor is reachable after 1042 receiving some reachability confirmation. Used by the 1043 Neighbor Unreachability Detection algorithm (see 1044 Section 6.3). A value of zero means unspecified (by 1045 the router). 1047 Retrans Timer 32-bit unsigned integer. The time, in milliseconds, 1048 between retransmitted Neighbor Solicitation messages. 1049 Used by Address Resolution and the Neighbor 1050 Unreachability Detection algorithm (see Sections 6.2 1051 and 6.3). A value of zero means unspecified (by the 1052 router). 1054 Options: 1056 Source link-layer address 1057 The link-layer address of the interface from which the 1058 Router Advertisement is sent. Only used on link 1059 layers that have addresses. A router MAY omit this 1060 option in order to enable inbound load sharing across 1061 multiple link-layer addresses. 1063 MTU SHOULD be sent on links that have a variable MTU. MAY 1064 be sent on other links. 1066 Prefix Information 1067 These options specify the prefixes that are on-link 1068 and/or are used for address autoconfiguration. A 1069 router SHOULD include all its on-link prefixes so that 1070 multihomed hosts have complete prefix information 1071 about on-link destinations for the links to which they 1072 attach. If complete information is lacking, a 1073 multihomed host may not be able to chose the correct 1074 outgoing interface when sending traffic to its 1075 neighbors. 1077 Future versions of this protocol may define new option types. 1078 Receivers MUST skip over and ignore any options they do not recognize 1079 and continue processing the message. 1081 5.2. Router Specification 1083 5.2.1. Router Configuration Variables 1085 A router MUST allow for the following variables to be configured by 1086 system management; default values are specified so as to make it 1087 unnecessary to configure any of these variables in many cases. 1089 For each multicast interface: 1091 AdvertiseDefault 1092 A flag indicating whether or not the router should 1093 advertise itself as a default router on the 1094 interface. 1096 Default: TRUE 1098 ManagedFlag The true/false value to be placed in the "Managed 1099 address configuration" field in the Router 1100 Advertisement. See [ADDRCONF]. 1102 Default: FALSE 1104 OtherFlag The true/false value to be placed in the "Other 1105 configuration" field in the Router Advertisement. 1106 See [ADDRCONF]. 1108 Default: FALSE 1110 LinkMTU The value to be placed in MTU options sent by the 1111 router. If the value is set to zero no MTU options 1112 are sent. 1114 Default: 0 1116 AdvReachableTime 1117 The value to be placed in the Reachable Time field 1118 in the Router Advertisement messages sent by the 1119 router. The value zero means unspecified (by this 1120 router). MUST be no greater than 3,600,000 1121 milliseconds (1 hour). 1123 Default: REACHABLE_TIME milliseconds 1125 ReachableTime The time a neighbor is considered reachable after 1126 receiving a reachability confirmation. 1128 Default: If AdvReachableTime is non-zero (specified) 1129 a uniformly-distributed random value between 1130 MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times 1131 AdvReachableTime milliseconds. Otherwise, A 1132 uniformly-distributed random value between 1133 MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR times 1134 REACHABLE_TIME milliseconds. 1136 RetransTimer The value to be placed in the Retrans Timer field in 1137 the Router Advertisement messages sent by the 1138 router. The value zero means unspecified (by this 1139 router). 1141 Default: RETRANS_TIMER milliseconds 1143 MaximumHopLimit 1144 The value to be placed in the Max Hop Limit field in 1145 the Router Advertisement messages sent by the 1146 router. The value zero means unspecified (by this 1147 router). 1149 Default: The value specified in the most recent 1150 "Assigned Numbers" RFC [ASSIGNED]. 1152 MaxRtrAdvInterval 1153 The maximum time allowed between sending unsolicited 1154 multicast Router Advertisements from the interface, 1155 in seconds. MUST be no less than 1 second and no 1156 greater than 1800 seconds. 1158 Default: 600 seconds 1160 MinRtrAdvInterval 1161 The minimum time allowed between sending unsolicited 1162 multicast Router Advertisements from the interface, 1163 in seconds. MUST be no less than 0.1 seconds and no 1164 greater than .75 * MaxRtrAdvInterval. 1166 Default: 0.33 * MaxRtrAdvInterval 1168 RtrAdvLifetime 1169 The value to be placed in the Router Lifetime field 1170 of Router Advertisements sent from the interface, in 1171 seconds. MUST be no less than MaxRtrAdvInterval and 1172 no greater than 9000 seconds. 1174 Note: if AdvertiseDefault is false, the value of 1175 RtrAdvLifetime is irrelevant; a Lifetime value of 0 1176 MUST be placed in outgoing Router Advertisements 1177 messages so that hosts do not use the router as a 1178 default router. 1180 Default: 3 * MaxRtrAdvInterval 1182 PrefixList 1183 A list of prefixes to be placed in Prefix 1184 Information options in Router Advertisement messages 1185 sent from the interface. 1187 Default: The PrefixList contains all prefixes that 1188 the router advertises via routing protocols as being 1189 on-link for the interface from which the 1190 advertisement is sent. 1192 Each prefix is associated with: 1194 InvalidationLifetime 1195 The value to be placed in the Invalidation 1196 Lifetime in the Prefix Information option, 1197 in seconds. The designated value of all 1's 1198 (0xffffffff) represents infinity. 1200 Default: infinity. 1202 OnLinkFlag 1203 The value to be placed in the on-link flag 1204 ("L-bit") field in the Prefix Information 1205 option. 1207 Default: TRUE 1209 Automatic address configuration [ADDRCONF] defines 1210 additional information associated with each the 1211 prefixes: 1213 DeprecationLifetime 1214 The value to be placed in the Deprecation 1215 Lifetime in the Prefix Information option, 1216 in seconds. The designated value of all 1's 1217 (0xffffffff) represents infinity. See 1218 [ADDRCONF]. 1220 Default: 604800 seconds (7 days) 1222 AutonomousFlag 1223 The value to be placed in the Autonomous 1224 Flag field in the Prefix Information option. 1225 See [ADDRCONF]. 1227 Default: TRUE 1229 Protocol constants are defined in Section 10. 1231 5.2.2. Validation of Router Solicitation Messages 1233 A router MUST silently discard any received Router Solicitation messages 1234 that do not satisfy all of the following validity checks: 1236 - IP Source Address is a link-local address. 1238 - IP Destination Address is a link-local address or a multicast 1239 address with link-local scope. 1241 - IP Routing Header is not present. 1243 - if the message includes an IP Authentication Header, the message 1244 authenticates correctly. 1246 - ICMP Checksum is valid. 1248 - ICMP Code is 0. 1250 - ICMP length (derived from the IP length) is 8 or more octets. 1252 - all included options have a length that is greater than zero. 1254 The contents of the Reserved field, and of any unrecognized options, 1255 MUST be ignored. Future, backward-compatible changes to the protocol 1256 may specify the contents of the Reserved field or add new options; 1257 backward-incompatible changes may use different Code values. 1259 A solicitation that passes the validity checks is called a "valid 1260 solicitation". 1262 Routers MUST also validate Router Advertisements as described in Section 1263 5.3.3. 1265 5.2.3. Router Behavior 1267 A router MUST join the all-routers multicast address on all multicast 1268 capable interfaces. 1270 The term "advertising interface" refers to any functioning and enabled 1271 interface that has at least one IP address assigned to it. From each 1272 advertising interface, the router transmits periodic, multicast Router 1273 Advertisements, containing the following values consistent with the 1274 message format above: 1276 - In the Router Lifetime field: the interface's configured 1277 RtrAdvLifetime. If the router's AdvertiseDefault flag is set to 1278 false, the Router Lifetime field MUST be set to 0. 1280 - In the M and O flags: the interface's configured ManagedFlag and 1281 OtherFlag, respectively. See [ADDRCONF]. 1283 - In the Max Hop Limit field: the interface's configured 1284 MaximumHopLimit. 1286 - In the Reachable Time field: the interface's configured 1287 AdvReachableTime. 1289 - In the Retrans Timer field: the interface's configured 1290 RetransTimer. 1292 - In the options: 1294 o Source Link-Layer Address option: link-layer address of the 1295 sending interface. This option MAY be omitted to facilitate 1296 in-bound load balancing over replicated interfaces. 1298 o MTU option: the MTU value that all nodes should be using. 1300 o Prefix Information options: one Prefix Information option for 1301 each prefix listed in PrefixList with the option fields set 1302 from the information in the PrefixList entry as follows: 1304 - In the "on-link" flag: the entry's OnLinkFlag. 1306 - In the Invalidation Lifetime field: the entry's 1307 InvalidationLifetime. 1309 - In the "Autonomous address configuration" flag: the 1310 entry's AutonomousFlag. 1312 - In the Deprecation Lifetime field: the entry's 1313 DeprecationLifetime. 1315 Router advertisements are not strictly periodic: the interval between 1316 subsequent transmissions is randomized to reduce the probability of 1317 synchronization with the advertisements from other routers on the same 1318 link [SYNC]. Each advertising interface has its own timer. Whenever a 1319 multicast advertisement is sent from an interface, that interface's 1320 timer is reset to a uniformly-distributed random value between the 1321 interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; 1322 expiration of the timer causes the next advertisement to be sent from 1323 the interface, and a new random value to be chosen. (It is recommended 1324 that routers include some unique value, such as one of their IP or 1325 link-layer addresses, in the seed used to initialize their pseudo-random 1326 number generators. Although the randomization range is configured in 1327 units of seconds, the actual randomly-chosen values should not be in 1328 units of whole seconds, but rather in units of the highest available 1329 timer resolution.) 1331 For the first few advertisements sent from an interface (up to 1332 MAX_INITIAL_RTR_ADVERTISEMENTS), if the randomly chosen interval is 1333 greater than MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to 1334 MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using this smaller interval 1335 for the initial advertisements increases the likelihood of a router 1336 being discovered quickly when it first becomes available, in the 1337 presence of possible packet loss. 1339 In addition to the periodic, unsolicited advertisements, a router sends 1340 advertisements in response to valid solicitations received on any of its 1341 advertising interfaces. A router MAY choose to unicast the response 1342 directly to the soliciting host's address, or multicast it to the all- 1343 nodes address; in the latter case, the interface's interval timer is 1344 reset to a new random value, as with unsolicited advertisements. A 1345 unicast response MAY be delayed, and a multicast response MUST be 1346 delayed, for a small random interval not greater than 1347 MAX_RTR_RESPONSE_DELAY, in order to prevent synchronization with other 1348 responding routers, and to allow multiple, closely-spaced solicitations 1349 to be answered with a single multicast advertisement. A router that 1350 chooses to delay responses behaves as follows: 1352 - Upon receipt of a Router Solicitation, start a timer taken from a 1353 random value within the range 0-MAX_RTR_RESPONSE_DELAY. 1355 - When the timer expires, send out the Router Advertisement. If no 1356 other Router Solicitation was received while waiting for the timer to 1357 expire, unicast the advertisement. Otherwise, multicast the response 1358 and reset the interface timer to a new random value, as is done when 1359 multicasting an unsolicited response. 1361 Note that a router is permitted to send multicast Router Advertisements 1362 more frequently than indicated by the MinRtrAdvInterval configuration 1363 variable if the additional advertisements are responses to explicit 1364 solicitations. In all cases, however, unsolicited multicast 1365 advertisements MUST NOT be sent more frequently than indicated by 1366 MinRtrAdvInterval. 1368 When a router receives a Router Solicitation it records that the source 1369 of the packet is a neighbor. If the solicitation contains a Source 1370 Link-Layer Address option, and the router has a Neighbor Cache entry for 1371 the neighbor, the link-layer address SHOULD be updated in the Neighbor 1372 Cache and the entry's "is_router" flag SHOULD be set to false. If a 1373 Neighbor Cache entry is created for the source its reachability state 1374 MUST be set to PROBE as specified in Section 6.3.2. 1376 It should be noted that an interface may become an advertising interface 1377 at times other than system startup, as a result of recovery from an 1378 interface failure or through actions of system management such as: 1380 - enabling the interface, if it had been administratively disabled, 1381 and its AdvertiseDefault flag is TRUE, or 1383 - enabling IP forwarding capability (i.e., changing the system from 1384 being a host to being a router), when the interface's 1385 AdvertiseDefault flag is TRUE, or 1387 - changing the AdvertiseDefault flag from FALSE to TRUE. 1389 In such cases the router MUST commence transmission of periodic 1390 advertisements on the new advertising interface, limiting the first few 1391 advertisements to intervals no greater than 1392 MAX_INITIAL_RTR_ADVERT_INTERVAL. In the case of a host becoming a 1393 router, the system MUST also join the all-routers IP multicast group on 1394 all interfaces on which the router supports IP multicast (whether or not 1395 they are advertising interfaces). 1397 An interface may also cease to be an advertising interface, through 1398 actions of system management such as: 1400 - administratively disabling the interface, or 1402 - shutting down the system, or disabling the IP forwarding capability 1403 (i.e., changing the system from being a router to being a host), or 1405 - setting the AdvertiseDefault flag of the interface to FALSE. 1407 In such cases the router SHOULD transmit a final multicast Router 1408 Advertisement on the interface with a Router Lifetime field of zero. In 1409 the case of a router becoming a host, the system MUST also depart from 1410 the all-routers IP multicast group on all interfaces on which the router 1411 supports IP multicast (whether or not they had been advertising 1412 interfaces). In addition, the host MUST insure that subsequent Neighbor 1413 Advertisement messages sent from the interface have the Router flag set 1414 to zero. 1416 The information advertised in Router Advertisements may change through 1417 actions of system management. For instance, the lifetime of advertised 1418 prefixes may change, the advertised MTU may change, etc. In such cases, 1419 the router MAY transmit a few (no more than 1420 MAX_INITIAL_RTR_ADVERTISEMENTS) Router Advertisements separated by an 1421 interval of MAX_INITIAL_RTR_ADVERT_INTERVAL. 1423 A router might want to send Router Advertisements without advertising 1424 itself as being a default router. For instance, a router might 1425 advertise prefixes for address autoconfiguration while not wishing to 1426 forward packets. Such a router MUST set the Router Lifetime field to 1427 zero in its advertisements. 1429 A router MAY choose not to include all Prefix Information options in 1430 every Router Advertisement. For example, if prefix lifetimes are much 1431 longer than RtrAdvLifetime, including them every few advertisements may 1432 be sufficient. However, when responding to a Router Solicitation the 1433 router SHOULD transmit all prefixes to allow hosts to quickly discover 1434 the prefixes during system initialization. 1436 5.2.4. Router Advertisement Consistency 1438 Routers SHOULD inspect valid Router Advertisements sent by other routers 1439 on the link and verify that the routers are advertising consistent 1440 information. Detected inconsistencies indicate that one or more routers 1441 might be misconfigured and SHOULD be logged to system or network 1442 management. The minimum set of information that should be checked 1443 includes: 1445 - Max Hop Limit values (except for the unspecified value of zero). 1447 - Values of the M or O flags. 1449 - Reachable Time values (except for the unspecified value of zero). 1451 - Retrans Timer values (except for the unspecified value of zero). 1453 - Values in the MTU options. 1455 - Invalidation Lifetimes for the same prefix. 1457 - Deprecation Lifetimes for the same prefix. 1459 Note that it is not an error for different routers to advertise 1460 different sets of prefixes. Also, some routers might leave some fields 1461 as unspecified i.e. with the value zero. The logging of errors SHOULD 1462 be restricted to conflicting information that causes hosts to 1463 continually switch from one value to another. 1465 In addition, routers can optionally examine the source address of Router 1466 Advertisements to determine which of a neighboring router's addresses is 1467 its link-local address. 1469 Any other action on reception of Router Advertisement messages by a 1470 router is beyond the scope of this document. 1472 5.2.5. Link-local Address Change 1474 The link-local address on a router SHOULD change infrequently. Nodes 1475 receiving Neighbor Discovery messages use the source address to identify 1476 the sender. If multiple packets from the same router contain different 1477 source addresses, nodes will assume they come from different nodes, 1478 leading to undesirable behavior. For example, a node will ignore 1479 Redirect messages that are believed to have been sent by a router other 1480 than the current first-hop router. Thus the source address used in 1481 Router Advertisements must be identical to the target address in a 1482 Redirect message when redirecting to the router. 1484 Using the link-local address to uniquely identify routers on the link 1485 has the benefit that the link-local address does not change when a site 1486 renumbers. 1488 If a router changes the link-local address for one of its interfaces, it 1489 SHOULD inform hosts of this change. The router SHOULD multicast a few 1490 Router Advertisements with Router Lifetime field set to zero for the old 1491 link-local address and also multicast a few Router Advertisements for 1492 the new link-local address. The exact procedures SHOULD be the same as 1493 when an interface ceases being an advertising interface, and when an 1494 interface becomes an advertising interface, respectively. 1496 A router MUST be able to determine the link-local address for each of 1497 its neighboring routers in order to ensure that the target address in a 1498 Redirect message identifies the neighbor router by its link-local 1499 address. This may require that routing protocols exchange link-local 1500 addresses. Alternatively, routers could listen to Router Advertisements 1501 messages to determine link-local addresses of neighboring routers. 1502 However, doing so only works if all routers are sending out Router 1503 Advertisements. 1505 5.3. Host Specification 1507 5.3.1. Host Configuration Variables 1509 None. 1511 5.3.2. Host Variables 1513 A host maintains certain Neighbor Discovery related variables in 1514 addition to the data structures defined in Section 4.1. These variables 1515 have default values that are overridden by information received in 1516 Router Advertisement messages. The default values are used when there 1517 is no router on the link, or when all received Router Advertisements 1518 have left a particular value unspecified. 1520 For each interface: 1522 LinkMTU The MTU of the link. 1524 Default: The valued defined in the specific document 1525 that describe how IPv6 operates over the particular 1526 link layer (e.g., [IPv6-ETHER]). 1528 MaximumHopLimit 1529 The maximum Hop Count to be used when sending IP 1530 packets. 1532 Default: The value specified in the most recent 1533 "Assigned Numbers" RFC [ASSIGNED]. 1535 ReachableTime The time a neighbor is considered reachable after 1536 receiving a reachability confirmation. 1538 Default: A uniformly-distributed random value 1539 between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR 1540 times REACHABLE_TIME milliseconds. 1542 RetransTimer The time between retransmissions of Neighbor 1543 Solicitation messages to a neighbor when resolving 1544 the address or when probing the reachability of a 1545 neighbor. 1547 Default: RETRANS_TIMER milliseconds 1549 5.3.3. Validation of Router Advertisement Messages 1551 A node MUST silently discard any received Router Advertisement messages 1552 that do not satisfy all of the following validity checks: 1554 - IP Source Address is a link-local address. 1556 - IP Destination Address is a link-local address or a multicast 1557 address with link-local scope. 1559 - IP Routing Header is not present. 1561 - if the message includes an IP Authentication Header, the message 1562 authenticates correctly. 1564 - ICMP Checksum is valid. 1566 - ICMP Code is 0. 1568 - ICMP length (derived from the IP length) is 16 or more octets. 1570 - all included options have a length that is greater than zero. 1572 The contents of the Reserved field, and of any unrecognized options, 1573 MUST be ignored. Future, backward-compatible changes to the protocol 1574 may specify the contents of the Reserved field or add new options; 1575 backward-incompatible changes may use different Code values. 1577 An advertisement that passes the validity checks is called a "valid 1578 advertisement". 1580 A host MUST silently discard any received Router Solicitation messages. 1582 5.3.4. Host Behavior 1584 The host joins the all-nodes multicast address on all multicast capable 1585 interfaces. 1587 A host MUST NOT send a Router Advertisement message at any time. 1589 To process a valid Router Advertisement, a host extracts the source 1590 address of the packet and does the following: 1592 - If the address is not already present in the host's Default Router 1593 List, and the advertisement's Router Lifetime is non-zero, create a 1594 new entry in the list, and initialize its timer value from the 1595 advertisement's Router Lifetime field. 1597 - If the address is already present in the host's Default Router List 1598 as a result of a previously-received advertisement, reset its timer 1599 to the Router Lifetime value in the newly-received advertisement. 1601 - If the address is already present in the host's Default Router List 1602 and the received Router Lifetime value is zero, time-out the entry 1603 immediately and remove it from the Default Router list. 1605 If the received Max Hop Limit value is non-zero the host SHOULD set its 1606 MaximumHopLimit variable to the received value. Hosts use the last Max 1607 Hop Limit value they have received; routers should be configured to 1608 advertise identical values to avoid hosts switching between different 1609 values. 1611 The host SHOULD set its ReachableTime variable based on the Reachable 1612 Time field, if the received value is non-zero. The value is computed as 1613 a uniformly-distributed random value between MIN_RANDOM_FACTOR and 1614 MAX_RANDOM_FACTOR times the value received in the Reachable Time field. 1615 Reception of another Router Advertisement causes a new random value to 1616 be chosen. This avoids any synchronization of Neighbor Unreachability 1617 Detection messages. 1619 The RetransTimer SHOULD be set to the Retrans Timer field, if the 1620 received value is non-zero. 1622 Hosts use the last Reachable Time and Retrans Timer values they have 1623 received; routers should be configured to advertise identical values to 1624 avoid having hosts switch between different values as they receive 1625 advertisements from different routers. 1627 After extracting information from the fixed part of the Router 1628 Advertisement message, the advertisement MUST be scanned for valid 1629 options. If the advertisement contains a source link-layer address 1630 option the link-layer address MUST be recorded in the Neighbor Cache 1631 entry for the router (creating an entry if necessary) and the 1632 "is_router" flag in the Neighbor Cache entry MUST be set to true. The 1633 "is_route" flag is used by Neighbor Unreachability Detection to 1634 determine when a router changes to being a host (i.e. no longer capable 1635 of forwarding packets). If a Neighbor Cache entry is created for the 1636 router its reachability state MUST be set to PROBE as specified in 1637 Section 6.3.2. 1639 Received MTU options are handled as specified in Section 8.4. 1641 For each Prefix Information option that has the "on-link" (L) flag set, 1642 the host does the following: 1644 - If the prefix is not already present in the Prefix List, create a 1645 new entry for the prefix and initialize its invalidation timer to 1646 the Invalidation Lifetime value in the Prefix Information option. 1648 - If the prefix is already present in the host's Prefix List as the 1649 result of a previously-received advertisement, reset its 1650 invalidation timer to the Invalidation Lifetime value in the Prefix 1651 Information option. If the new Lifetime value is zero, time-out 1652 the prefix immediately. 1654 - If the received Invalidation Lifetime value is zero, and the prefix 1655 is not present in the host's Prefix List, silently ignore the 1656 option. 1658 Note: Implementations can choose to process the on-link aspects of 1659 the prefixes separately from the address autoconfiguration aspects of 1660 the prefixes by e.g. passing a copy of each valid Router 1661 Advertisement message to both an "on-link" and an "addrconf" 1662 function. Each function can then operate independently on the 1663 prefixes that have the appropriate flag set. 1665 Whenever the invalidation timer expires for a Prefix List entry, that 1666 entry is discarded. No existing Destination Cache entries are affected, 1667 however. 1669 Whenever a timer expires for an entry in the Default Router List, that 1670 entry is discarded. Any entries in the Destination Cache going through 1671 that router will continue to be used. Neighbor Unreachability Detection 1672 will purge them if appropriate. 1674 To limit the storage needed for the Default Router List, a host MAY 1675 choose not to store all of the router addresses discovered via 1676 advertisements. However, a host MUST retain at least two router 1677 addresses and SHOULD retain more. Default router selections are made 1678 whenever communication to a destination appears to be failing. Thus, 1679 the more routers on the list, the more likely an alternative working 1680 router can be found quickly (e.g., without having to wait for the next 1681 advertisement to arrive). 1683 The algorithm for selecting a router depends in part on whether or not a 1684 router is known to be reachable. The exact details of how a node keeps 1685 track of a neighbor's reachability state are covered in Section 6.3. 1686 The algorithm for selecting a default router is invoked only when a 1687 Destination Cache entry is incomplete or when communication through an 1688 existing router appears to be failing. Under normal conditions, a 1689 router would be selected the first time traffic is sent to a 1690 destination, with subsequent traffic for that destination using the same 1691 router as indicated in the Destination Cache. The policy for selecting 1692 routers from the Default Router List is as follows: 1694 1) Routers reachable or probably reachable (e.g., in the REACHABLE or 1695 PROBE state) MUST be preferred over routers whose reachability is 1696 unknown or suspect. An implementation may choose to always return 1697 the same router or cycle through the router list in a round-robin 1698 fashion as long as it always returns a reachable or probably 1699 reachable router when one is available. 1701 2) When no routers on the list are known to be reachable or probably 1702 reachable, routers SHOULD be selected in a round-robin fashion, so 1703 that subsequent requests for a default router do not return the 1704 same router until all other routers have been selected. 1706 Cycling through the router list in this case ensures that all 1707 available routers are actively probed by the Neighbor 1708 Unreachability Detection algorithm. A request for a default router 1709 is made in conjunction with the sending of a packet to a router, 1710 and the selected router will be probed for reachability as a side 1711 effect. 1713 3) If the Default Router List is empty, assume that the destination is 1714 on-link as specified in Section 4.2. 1716 A host is permitted (but not required) to transmit up to 1717 MAX_RTR_SOLICITATIONS Router Solicitation messages from any of its 1718 multicast interfaces after any of the following events: 1720 - The interface is initialized at system startup time. 1722 - The interface is reinitialized after a temporary interface failure 1723 or after being temporarily disabled by system management. 1725 - The system changes from being a router to being a host, by having 1726 its IP forwarding capability turned off by system management. 1728 - The host is re-attached to a link after being detached for some 1729 time. 1731 The IP destination address of the solicitations is the all-routers 1732 multicast address. The IP source address MUST be one of the interface's 1733 addresses and MUST be a link-local address. The Source Link-Layer 1734 Address option is set to the host's link-layer address. 1736 If a host does choose to send a solicitation after one of the above 1737 events, it SHOULD delay that transmission for a random amount of time 1738 between 0 and MAX_RTR_SOLICITATION_DELAY. This serves to alleviate 1739 congestion when many hosts start up on a link at the same time, such as 1740 might happen after recovery from a power failure. (It is recommended 1741 that hosts include some unique value, such as one of their IP or link- 1742 layer addresses, in the seed used to initialize their pseudo-random 1743 number generators.) Although the randomization range is specified in 1744 units of seconds, the actual randomly-chosen values should not be in 1745 units of whole seconds, but rather in units of the highest available 1746 timer resolution. 1748 If a host has performed a random delay earlier during the system startup 1749 (e.g. as part of Duplicate Address Detection [ADDRCONF]) there is no 1750 need to randomly delay the first Router Solicitation message. 1752 A host MAY also choose to further postpone its solicitations, subsequent 1753 to one of the above events, until the first time it needs to use a 1754 default router. 1756 Upon receiving a valid advertisement with a non-zero Lifetime, the host 1757 MUST desist from sending any solicitations on that interface (even if 1758 none have been sent yet), until the next time one of the above events 1759 occurs. The small number of retransmissions of a solicitation, which 1760 are permitted if no such advertisement is received, SHOULD be sent at 1761 intervals of RTR_SOLICITATION_INTERVAL seconds, without randomization. 1763 6. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 1765 This section describes the functions related to the Neighbor 1766 Solicitation and Neighbor Advertisement messages and includes 1767 descriptions of Address Resolution and the Neighbor Unreachability 1768 Detection algorithm. 1770 These messages are also used for Duplicate Address Detection as 1771 specified by [ADDRCONF]. In particular, Duplicate Address Detection 1772 sends Neighbor Solicitation messages using an unspecified source address 1773 targeting its own address. This will generate a multicast Neighbor 1774 Advertisement from any node(s) that have been configured with the same 1775 address. 1777 6.1. Message Formats 1779 6.1.1. Neighbor Solicitation Message Format 1781 Nodes send Neighbor Solicitations to request the link-layer address of a 1782 target node while also providing their own link-layer address to the 1783 target. Neighbor Solicitations are multicast when the node needs to 1784 resolve an address and unicast when the node seeks to verify the 1785 reachability of a neighbor. 1787 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1788 | Type | Code | Checksum | 1789 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1790 | Reserved | 1791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1792 | | 1793 + + 1794 | | 1795 + Sender Address + 1796 | | 1797 + + 1798 | | 1799 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1800 | | 1801 + + 1802 | | 1803 + Target Address + 1804 | | 1805 + + 1806 | | 1807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1808 | Options ... 1809 +-+-+-+-+-+-+-+-+-+-+-+- 1811 IP Fields: 1813 Source Address 1814 MUST be either the link-local address assigned to the 1815 interface from which this message is sent, or the 1816 unspecified address. Use of the unspecified address 1817 directs the target node to multicast the resultant 1818 Neighbor Advertisement as required by Duplicate 1819 Address Detection in [ADDRCONF]. 1821 Destination Address 1822 Either the solicited-node link-local multicast address 1823 corresponding to the target address, or the target 1824 address. Packets unicast to the target address are 1825 used to verify reachability. 1827 Hop Count 1 1829 Authentication Header 1830 If a Security Association for the IP Authentication 1831 Header exists between the sender and the destination 1832 address, then the sender SHOULD include this header. 1834 Routing Header MUST NOT be sent. 1836 ICMP Fields: 1838 Type 135 1840 Code 0 1842 Checksum The ICMP checksum. See [ICMPv6]. 1844 Reserved This field is unused. It MUST be initialized to zero 1845 by the sender and ignored by the receiver. 1847 Sender Address 1848 An IP address assigned to the interface from which the 1849 solicitation is sent. If the source address of the 1850 data packet prompting the solicitation is the same of 1851 one of the sending interface's addresses, that address 1852 SHOULD be used. Doing so ensures that the receiver of 1853 the solicitation places the data packet's source 1854 address in its Neighbor Cache, eliminating the need 1855 for address resolution in the likely case that reverse 1856 traffic for that destination will follow. 1858 Target Address 1859 The IP address of the target of the solicitation. It 1860 MUST NOT be a multicast address. 1862 Options: 1864 Source link-layer address 1865 The link-layer address for the sender. MUST NOT be 1866 included in unicast solicitations, in order to prevent 1867 off-link senders from creating or modifying cached 1868 link-layer addresses. For multicast solicitations 1869 sent on link layers that have addresses it SHOULD be 1870 included. 1872 Future versions of this protocol may define new option types. 1873 Receivers MUST skip over and ignore any options they do not recognize 1874 and continue processing the message. 1876 6.1.2. Neighbor Advertisement Message Format 1878 A node MUST send a Neighbor Advertisement in response to a Neighbor 1879 Solicitation for a target IP address that matches an assigned address on 1880 the receiving interface. A node MAY also send an unsolicited Neighbor 1881 Advertisement if wishes to advertise that its link-layer address has 1882 changed. 1884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1885 | Type | Code | Checksum | 1886 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1887 |R|S|N| Reserved | 1888 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1889 | | 1890 + + 1891 | | 1892 + Target Address + 1893 | | 1894 + + 1895 | | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Options ... 1898 +-+-+-+-+-+-+-+-+-+-+-+- 1900 IP Fields: 1902 Source Address 1903 MUST be the link-local address assigned to the 1904 interface from which this message is sent. 1906 Destination Address 1907 The Source Address of an invoking Neighbor 1908 Solicitation or, if the source address in the 1909 solicitation is the unspecified address, the all-nodes 1910 link-local multicast address. For an unsolicited 1911 advertisement the destination is typically the all- 1912 nodes link-local multicast address. 1914 Hop Count 1 1916 Authentication Header 1917 If a Security Association for the IP Authentication 1918 Header exists between the sender and the destination 1919 address, then the sender SHOULD include this header. 1921 Routing Header MUST NOT be sent. 1923 ICMP Fields: 1925 Type 136 1927 Code 0 1929 Checksum The ICMP checksum. See [ICMPv6]. 1931 R Router flag. When set, the R-bit indicates that the 1932 sender is a router. The R-bit is used by Neighbor 1933 Unreachability Detection to detect a router that 1934 changes to a host. 1936 S Solicited flag. When set, the S-bit indicates that 1937 the advertisement was sent in response to a Neighbor 1938 Solicitation from the Destination address. It MUST be 1939 zero in a multicast advertisement and in an 1940 unsolicited unicast advertisement. 1942 N Secondary Advertisement flag. When set, the N-bit 1943 indicates that the advertisement should only be used 1944 if no other advertisement has been received i.e. the 1945 advertisement will not update a cached link-layer 1946 address. It SHOULD be set in solicited advertisements 1947 for anycast addresses and in solicited proxy 1948 advertisements. It SHOULD be zero in other solicited 1949 advertisements and in unsolicited advertisements. 1951 Reserved 29-bit unused field. It MUST be initialized to zero 1952 by the sender and ignored by the receiver. 1954 Target Address 1955 The address from the Target Address field in the 1956 Neighbor Solicitation message that prompted this 1957 advertisement. For an unsolicited advertisement, the 1958 address whose link-layer address has changed. The 1959 Target Address MUST NOT be a multicast address. 1961 Options: 1963 Target link-layer address 1964 The link-layer address for the target. MUST be 1965 included on link layers that have addresses. 1967 Future versions of this protocol may define new option types. 1968 Receivers MUST skip over and ignore any options they do not recognize 1969 and continue processing the message. 1971 6.2. Address Resolution 1973 Address Resolution provides the mechanism through which a node 1974 determines the link-layer address of a neighbor. Address Resolution is 1975 only used for destinations that are determined to be on-link and for 1976 which the sender does not know the corresponding link-layer address. 1977 Address resolution is never used for multicast destinations. 1979 6.2.1. Node Specification 1981 When a multicast-capable interface is initialized the node MUST join the 1982 all-nodes multicast address on that interface, as well as the 1983 solicited-node multicast address corresponding to each of the IP 1984 addresses assigned to the interface. 1986 The operation of automatic address configuration [ADDRCONF] may, over 1987 time, change the set of addresses assigned to an interface; new 1988 addresses might be added and old addresses might be removed. In such 1989 case the node MUST join and leave the solicited-node multicast address 1990 corresponding to the new and old addresses, respectively. Note that 1991 multiple assigned addresses might correspond to the same solicited-node 1992 multicast address; a node MUST NOT leave the solicited-node multicast 1993 group until all assigned addresses corresponding to that multicast 1994 address have been removed. 1996 6.2.2. Sending Neighbor Solicitations 1998 When a node has a unicast packet to send, but does not know the next- 1999 hop's link-layer address, it performs address resolution by creating a 2000 Neighbor Cache entry in the INCOMPLETE state and transmitting a Neighbor 2001 Solicitation message targeted at the neighbor. The solicitation must be 2002 sent to the solicited-node multicast address of the target address. 2004 The sender SHOULD include its link-layer address (if it has one) in the 2005 multicast solicitation as a Source Link-Layer Address option. If the 2006 source address of the packet prompting the solicitation is the same as 2007 one of the addresses assigned to the outgoing interface, that address 2008 SHOULD be placed in the ICMP Sender Address of the outgoing 2009 solicitation. Otherwise, the interface's link-local address should be 2010 used. Using the prompting packet's source address when possible insures 2011 that the recipient of the Neighbor Solicitation installs in its Neighbor 2012 Cache the IP address that is highly likely to be used in subsequent 2013 traffic belonging to the prompting packet's "connection". 2015 While waiting for address resolution to complete, the sender MUST retain 2016 packets waiting for address resolution to complete in a small queue. 2018 The queue MUST hold at least one packet, and MAY contain more. However, 2019 the number of queued packets per neighbor SHOULD be limited to some 2020 small value. When a queue overflows, the new arrival SHOULD replace the 2021 oldest entry. Once address resolution completes, all queued packets 2022 SHOULD be transmitted. 2024 While awaiting a response, the sender MUST retransmit Neighbor 2025 Solicitation messages approximately every RetransTimer milliseconds, 2026 even in the absence of additional traffic to the neighbor. 2027 Retransmissions MUST be rate-limited for each neighbor to at most one 2028 solicitation every RetransTimer milliseconds. 2030 If no advertisement is received after MAX_MULTICAST_SOLICIT 2031 solicitations, address resolution has failed. The sender MUST return 2032 ICMP destination unreachable indications with code 3 (Address 2033 Unreachable) for each packet queued awaiting address resolution. 2035 6.2.3. Validation of Neighbor Solicitations 2037 A node MUST silently discard any received Neighbor Solicitation messages 2038 that do not satisfy all of the following validity checks: 2040 - IP Source Address is a link-local address or the unspecified 2041 address. 2043 - if the IP Destination Address is a multicast address, its scope is 2044 link-local. 2046 - IP Routing Header is not present. 2048 - if the message includes an IP Authentication Header, the message 2049 authenticates correctly. 2051 - ICMP Checksum is valid. 2053 - ICMP Code is 0. 2055 - ICMP length (derived from the IP length) is 40 or more octets. 2057 - Target Address is not a multicast address. 2059 - if the Source Address is the unspecified address or the Destination 2060 Address is a unicast address, there is no Source Link-layer Address 2061 option. 2063 - all included options have a length that is greater than zero. 2065 - the Target Address matches an address assigned to the receiving 2066 interface. 2068 The contents of the Reserved field, and of any unrecognized options, 2069 MUST be ignored. Future, backward-compatible changes to the protocol 2070 may specify the contents of the Reserved field or add new options; 2071 backward-incompatible changes may use different Code values. 2073 A Neighbor Solicitation that passes the validity checks is called a 2074 "valid solicitation". 2076 6.2.4. Receipt of Neighbor Solicitations 2078 If and the Source Link-Layer Address option is present, the recipient 2079 SHOULD update the Neighbor Cache entries for both the IP Source Address 2080 and the ICMP Sender Address of the solicitation. In those cases where a 2081 corresponding entry does not already exist, the node SHOULD create a new 2082 one and set its reachability state to PROBE as specified in 2083 Section 6.3.2. In all cases the source link-layer address option in the 2084 received advertisement SHOULD replace any cached link-layer addresses. 2086 A Neighbor Solicitation that is being used for Duplicate Address 2087 Detection, i.e. with an unspecified source address, can not contain a 2088 source link-layer address option thus it has no effect on the Neighbor 2089 Cache. 2091 6.2.5. Sending Solicited Neighbor Advertisements 2093 A Neighbor Advertisement is sent in response to a valid Neighbor 2094 Solicitation. The Target Address of the advertisement is copied from 2095 the Target Address of the Solicitation. The Target Link-Layer Address 2096 option SHOULD be included, using as its value the interface's link-layer 2097 address. If the node is a router, it MUST set the Router flag to one; 2098 otherwise it MUST set the flag to zero. 2100 If the Target Address is either an anycast address or a unicast address 2101 for which the node is providing proxy service, the Secondary 2102 Advertisement flag SHOULD be set to one. Otherwise, it SHOULD be set 2103 to 0. Proper setting of the Secondary Advertisement flag insures that 2104 nodes give preference to "primary" advertisements, even when received 2105 after "secondary" advertisements. 2107 If the source of the solicitation is the unspecified address, the node 2108 MUST set the Solicited flag to zero and multicast the advertisement to 2109 the all-nodes address. Otherwise, the node MUST set the Solicited flag 2110 to one and unicast the advertisement to the link-local Source Address of 2111 the solicitation. 2113 6.2.6. Validation of Neighbor Advertisements 2115 A node MUST silently discard any received Neighbor Advertisement 2116 messages that do not satisfy all of the following validity checks: 2118 - IP Source Address is a link-local address. 2120 - IP Destination Address is a link-local address or a multicast 2121 address with link-local scope. 2123 - IP Routing Header is not present. 2125 - if the message includes an IP Authentication Header, the message 2126 authenticates correctly. 2128 - ICMP Checksum is valid. 2130 - ICMP Code is 0. 2132 - ICMP length (derived from the IP length) is 24 or more octets. 2134 - Target Address is not a multicast address. 2136 - if the Destination Address is a multicast address the Solicited 2137 flag is zero. 2139 - all included options have a length that is greater than zero. 2141 The contents of the Reserved field, and of any unrecognized options, 2142 MUST be ignored. Future, backward-compatible changes to the protocol 2143 may specify the contents of the Reserved field or add new options; 2144 backward-incompatible changes may use different Code values. 2146 A Neighbor Advertisements that passes the validity checks is called a 2147 "valid advertisement". 2149 6.2.7. Receipt of Neighbor Advertisments 2151 When a valid Neighbor Advertisement is received (either solicited or 2152 unsolicited), the Neighbor Cache is searched for the target's entry. If 2153 no entry exists, the advertisement SHOULD be silently discarded. There 2154 is no need to create an entry in this case, since the recipient has 2155 apparently not initiated any communication with the target. 2157 Once the appropriate Neighbor Cache entry has been located, the specific 2158 actions taken depend on the state of the Neighbor Cache entry. In 2159 particular, if no link-layer address is cached for the target (e.g., it 2160 is in the INCOMPLETE state), the first received advertisement would be 2161 used. On the other hand, if we already have a cached link-layer 2162 address, we can safely be more selective about what information is used 2163 in received advertisements. 2165 If the target's Neighbor Cache entry is in the INCOMPLETE state, the 2166 advertisement is the first response to a solicitation. The receiving 2167 node MUST record the link-layer address in the Neighbor Cache entry and 2168 send any packets queued for the neighbor awaiting address resolution. 2169 If the Solicited flag is set, the reachability state for the neighbor 2170 MUST be set to REACHABLE; otherwise it MUST be set to PROBE. (A more 2171 detailed explanation of reachability state is described in Section 2172 6.3.2). The Secondary Advertisement flag is ignored if the entry is in 2173 the INCOMPLETE state. 2175 If the target's Neighbor Cache entry is in the REACHABLE or PROBE state, 2176 the Secondary Advertisement flag is examined. If set, the entry's state 2177 should be set to PROBE, and the packet SHOULD be silently discarded; no 2178 other changes are made to the Neighbor Cache entry. 2180 If the Secondary Advertisement flag is not set, the link-layer address 2181 in the Target Link-Layer Address option should be copied into the 2182 Neighbor Cache entry. Furthermore, if the Solicited flag is set, the 2183 entry's state should be set to REACHABLE. Otherwise, the entry's state 2184 should be set to PROBE. 2186 Finally, the receiving node MUST examine the Router flag in the received 2187 advertisement and update the "is_router" flag in the Neighbor Cache 2188 entry to reflect whether the node is a host or router. In those cases 2189 where the neighbor was previously used as a router, but the 2190 advertisement's Router flag is now set to zero, the node MUST remove 2191 that router from the Default Router List and update the Destination 2192 Cache entries for all destinations using that neighbor as a router as 2193 specified in Section 6.3.2. 2195 6.2.8. Sending Unsolicited Neighbor Advertisements 2197 In some cases a node may be able to determine that its link-layer 2198 address has changed (e.g., hot-swap of an interface card) and may wish 2199 to inform its neighbors of the new link-layer address quickly. In such 2200 cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited 2201 Neighbor Advertisement messages to the all-nodes multicast address. 2203 These advertisements MUST be separated by at least 2204 MIN_NEIGHBOR_ADVERT_INTERVAL seconds. 2206 The Target Address field in the unsolicited advertisement is set to an 2207 IP address of the interface, and the Target Link-Layer Address option is 2208 filled with the new link-layer address. The Solicited flag MUST be set 2209 to zero, in order to avoid confusing the Neighbor Unreachability 2210 Detection algorithm. If the node is a router, it MUST set the Router 2211 flag to one; otherwise it MUST set it to zero. The Secondary 2212 Advertisement flag MAY be either set or cleared. In either case, 2213 neighboring nodes will immediately change the state of their Neighbor 2214 Cache entries for the Target Address to PROBE, prompting them to verify 2215 the path for reachability. If the Secondary Advertisement is set, 2216 neighboring nodes will install the new link-layer address in their 2217 caches. Otherwise, they will ignore the new link-layer address, 2218 choosing instead to probe the cached address instead. 2220 A node that has multiple IP addresses assigned to an interface MAY 2221 multicast a separate Neighbor Advertisement for each address. In such a 2222 case the node SHOULD introduce a small delay between the sending of each 2223 advertisement to reduce the probability of the advertisements being lost 2224 due to congestion. 2226 A proxy MAY multicast Neighbor Advertisements when its link-layer 2227 address changes or when it is configured (by system management or other 2228 mechanisms) to proxy for an address. If there are multiple nodes that 2229 are providing proxy services for the same set of addresses the proxies 2230 SHOULD provide a mechanism that prevents multiple proxies from 2231 multicasting advertisements for any one address, in order to reduce the 2232 risk of excessive multicast traffic. 2234 Also, a node belonging to an anycast address MAY multicast unsolicited 2235 Neighbor Advertisements for the anycast address when the node's link- 2236 layer address changes. 2238 Note that because unsolicited Neighbor Advertisements do not reliably 2239 update caches in all nodes (the advertisements might not be received by 2240 all nodes), they should only be viewed as a performance optimization to 2241 quickly update the caches in most neighbors. The Neighbor 2242 Unreachability Detection algorithm ensures that all nodes reliably 2243 obtain the new link-layer address, though the delay may be slightly 2244 longer. 2246 6.2.9. Anycast Neighbor Advertisements 2248 A node belonging to an anycast address MUST join the solicited-node 2249 multicast address that corresponds to the anycast address. 2251 When a node responds to a Neighbor Solicitation for an anycast address, 2252 it MUST respond with an Neighbor Advertisement that has the Secondary 2253 Advertisement flag set to one. In addition, the sender should delay 2254 sending a response for a random time between 0 and 2255 MAX_ANYCAST_DELAY_TIME seconds. 2257 Neighbor Unreachability Detection ensures that a node quickly detects 2258 when the current binding for an anycast address becomes invalid. 2260 6.2.10. Proxy Neighbor Advertisements 2262 Under limited circumstances, a router MAY proxy for one or more other 2263 nodes, that is, through Neighbor Advertisements indicate that it is 2264 willing to accept packets not explicitly addressed to itself. For 2265 example, a router might potentially accept packets on behalf of a mobile 2266 node that has moved off-link. The mechanisms used by proxy are 2267 identical to the mechanisms needed for anycast addresses. 2269 A proxy MUST join the solicited-node multicast address(es) that 2270 correspond to the IP address(es) assigned to the node for which it is 2271 proxying. 2273 All solicited proxy Neighbor Advertisement messages MUST have the 2274 Secondary Advertisement flag set to one. This ensures that if the node 2275 itself is present on the link its Neighbor Advertisement (with the 2276 Secondary flag set to zero) will take precedence of any advertisement 2277 received from a proxy. A proxy MAY send unsolicited advertisements with 2278 the Secondary Advertisement flag set to zero as specified in Section 2279 6.2.8, but doing so may cause the proxy advertisement to override a 2280 valid entry created by the node itself. 2282 Finally, when sending a proxy advertisement in response to a Neighbor 2283 Solicitation, the sender should delay its response by a random time 2284 between 0 and MAX_ANYCAST_DELAY_TIME seconds. 2286 6.3. Neighbor Unreachability Detection 2288 Communication to or through a neighbor may fail for numerous reasons at 2289 any time, including hardware failure, hot-swap of an interface card, 2290 etc. If the destination has failed, no recovery is possible and 2291 communication fails. On the other hand, if it is the path that has 2292 failed, recovery may be possible. Thus, a node actively tracks the 2293 reachability "state" for the neighbors to which it is sending packets. 2295 Neighbor Unreachability Detection is used for all paths between hosts 2296 and neighboring nodes, including host-to-host, host-to-router, and 2297 router-to-host communication. Neighbor Unreachability Detection may 2298 also be used between routers, but is not required if an equivalent 2299 mechanism is available, for example, as part of the routing protocols. 2300 The conceptual model allows an upper-layer to indicate to IP that 2301 Neighbor Unreachability Detection is not needed for a packet being sent. 2302 This is used by Neighbor Discovery to skip these checks when sending 2303 Neighbor Discovery messages. 2305 When a path to a neighbor appears to be failing, the specific recovery 2306 procedure depends on how the neighbor is being used. For example, the 2307 specific recovery procedure used when the neighbor is used as a router 2308 differs from that used when the neighbor is the destination. 2310 Neighbor Unreachability Detection is performed only for neighbors to 2311 which unicast packets are sent; it is not used when sending to multicast 2312 addresses. 2314 6.3.1. Reachability Confirmation 2316 A neighbor is considered reachable if the node has recently received a 2317 confirmation that packets sent recently to the neighbor were received by 2318 its IP layer. Positive confirmation can be gathered in two ways: hints 2319 from upper layer protocols that indicate a connection is making "forward 2320 progress", or receipt of a Neighbor Advertisement message that is a 2321 response to an explicit Neighbor Solicitation probe. 2323 A connection makes "forward progress" if the packets received from a 2324 remote peer can only be arriving if recent packets sent to that peer are 2325 actually reaching it. For example, receipt of a (new) acknowledgement 2326 indicates that previously sent data reached the peer. Likewise, the 2327 arrival of a new (non-duplicate) packet indicates that earlier 2328 acknowledgements are being delivered to the remote peer. If packets are 2329 reaching the peer, they must also be reaching the sender's next-hop 2330 neighbor; thus "forward progress" is a confirmation that the next-hop 2331 neighbor is reachable. For off-link destinations, forward progress 2332 implies that the first-hop router is reachable. When available, this 2333 upper-layer information SHOULD be used. 2335 In some cases (e.g., UDP-based protocols and routers forwarding packets 2336 to hosts) such reachability information may not be readily available 2337 from upper-layer protocols. When no hints are available and a node is 2338 sending packets to a neighbor, the node actively probes the neighbor 2339 using unicast Neighbor Solicitation messages to verify that the forward 2340 path is still working. 2342 The receipt of a solicited Neighbor Advertisement that is a response to 2343 a Neighbor Solicitation probe serves as reachability confirmation, since 2344 advertisements with the Solicited flag set to one are sent only in 2345 response to a solicitation. Receipt of other Neighbor Discovery 2346 messages such as Router Advertisements and Neighbor Advertisement with 2347 the Solicited flag set to zero MUST NOT be treated as a reachability 2348 confirmation. Receipt of such unsolicited messages only confirm the 2349 one-way path from the neighbor to the recipient node. In contrast, 2350 Neighbor Unreachability Detection requires that the forward path from 2351 the sender to the neighbor be working. Note that an advertisement sent 2352 in response to an explicit solicitation confirms that a path is working 2353 in both directions; the solicitation reached the neighbor, prompting it 2354 to generate an advertisement, and the advertisement reached the querying 2355 node. However, from the perspective of Neighbor Unreachability 2356 Detection, only the reachability of the forward path is of interest. 2358 6.3.2. Node Behavior 2360 Neighbor Unreachability Detection operates in parallel with the sending 2361 of packets to a neighbor. While reasserting a neighbor's reachability, 2362 a node continues sending packets to that neighbor using the cached 2363 link-layer address. 2365 A Neighbor Cache entry can be in one of three states: 2367 INCOMPLETE Address resolution is being performed on the entry. 2368 Specifically, a Neighbor Solicitation has been sent to 2369 the solicited-node multicast address of the target, but 2370 the corresponding Neighbor Advertisement has not yet been 2371 received. 2373 REACHABLE Positive confirmation was received within the last 2374 ReachableTime milliseconds that the forward path to the 2375 neighbor was functioning properly. While REACHABLE, no 2376 special action takes place as packets are sent. 2378 PROBE More than ReachableTime milliseconds have elapsed since the 2379 last positive confirmation was received that the forward 2380 path was functioning properly. Upon entering the PROBE 2381 state, no Neighbor Solicitation is sent. However, a 2382 timer is set to expire DELAY_FIRST_PROBE_TIME seconds 2383 later, and a Neighbor Solicitation probe is sent if the 2384 entry is still in a PROBE state when the timer expires. 2385 Delaying the sending of the initial Neighbor Solicitation 2386 gives the upper layers additional time to provide 2387 reachability confirmation information. After the initial 2388 delay, Neighbor Solicitations are retransmitted every 2389 RetransTimer milliseconds until a reachability 2390 confirmation is received. 2392 When an entry is created as a result of needing to perform address 2393 resolution, a Neighbor Solicitation is sent to the solicited-node 2394 multicast address of the target, a timer is started to expire 2395 RETRANS_TIMER milliseconds later and the entry's state is set to 2396 INCOMPLETE. 2398 As specified in Section 6.2.2, when in the INCOMPLETE state, Neighbor 2399 Solicitation messages are retransmitted every RETRANS_TIMER milliseconds 2400 until a response is received. If no response is received within 2401 RETRANS_TIMER milliseconds after sending MAX_MULTICAST_SOLICIT probes to 2402 the solicited-node multicast address, address resolution fails. Upon 2403 failure, ICMP destination unreachable indications with code 3 (Address 2404 unreachable) are returned for any queued packets and the entry is 2405 deleted. Note that deleting the entry implies that all destinations 2406 using that neighbor must perform next-hop resolution again before 2407 sending a subsequent packet. Thus, if the neighbor is a router, an 2408 alternate router may be selected. Alternatively, a destination 2409 previously thought to be on-link, may now only be reachable through a 2410 router. 2412 Unreachability detection changes a neighbor's state from REACHABLE to 2413 PROBE only on-demand, as a side effect of sending a data packet to that 2414 neighbor. If no traffic is sent to a neighbor, no probes are sent 2415 either. Note that an entry may technically no longer be in a REACHABLE 2416 state, but the condition need not be checked or acted upon until a 2417 packet is sent to the neighbor. 2419 The first time a Neighbor Cache entry is referenced and more than 2420 ReachableTime milliseconds have passed since receipt of the last 2421 reachability confirmation, its state changes to PROBE. However, no 2422 Neighbor Solicitation probe is sent. Probing is deferred for an 2423 additional DELAY_FIRST_PROBE_TIME seconds, an optimization that gives 2424 the upper-layer protocol additional time to provide a reachability 2425 confirmation in those cases where ReachableTime milliseconds have passed 2426 since the last confirmation due to lack of recent traffic. Without this 2427 optimization the opening of a TCP connection after a traffic lull would 2428 initiate probes even though the subsequent three-way handshake would 2429 provide a reachability confirmation almost immediately. 2431 If no reachability confirmation is received within 2432 DELAY_FIRST_PROBE_TIME seconds after entering the PROBE state, a unicast 2433 Neighbor Solicitation message is sent to the neighbor using the cached 2434 link-layer address. In addition, the sender starts a timer to 2435 retransmit probe messages every RetransTimer milliseconds until the 2436 desired solicitation is received. Subsequent probes are retransmitted 2437 even if no additional packets are sent to the neighbor. If no response 2438 is received after waiting RetransTimer milliseconds after sending the 2439 MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry 2440 SHOULD be deleted. Subsequent traffic to that neighbor recreates the 2441 entry and performs address resolution again. 2443 Note that all Neighbor Solicitations are rate-limited on a per-neighbor 2444 basis. A node MUST NOT send Neighbor Solicitations to the same neighbor 2445 more frequently than once every RetransTimer milliseconds. 2447 A Neighbor Cache entry also enters the PROBE state when created as a 2448 result of receiving packets other than solicited Neighbor Advertisements 2449 (e.g., Router Solicitations, Router Advertisements, Redirects, and 2450 Neighbor Solicitations). These packets contain the link-layer address 2451 of either the sender or, in the case of Redirect, the redirection 2452 target. However, receipt of these link-layer addresses does not confirm 2453 reachability of the forward-direction path to that node. Placing a 2454 newly created Neighbor Cache entry for which the link-layer address is 2455 known in the PROBE state provides assurance that path failures are 2456 detected quickly. As always, when entering the PROBE state, the first 2457 probe is delayed for DELAY_FIRST_PROBE_TIME to give the upper layer some 2458 time to provide a reachability confirmation thereby suppressing the 2459 sending of a probe. 2461 To detect the case where a router switches from being a router to being 2462 a host (e.g., by having its IP forwarding capability turned off by 2463 system management), a node MUST compare the Router flag field in all 2464 received Neighbor Advertisement messages with the "is_router" flag 2465 recorded in the Neighbor Cache entry. When a node detects that a 2466 neighbor has changed from being a router to being a host, the node MUST 2467 remove that router from the Default Router List and update the 2468 Destination Cache so that all entries using that neighbor as a router 2469 switch to another router. Note that a router may not be listed in the 2470 Default Router List, even though a Destination Cache entry is using it 2471 (e.g., the a host was redirected to it). 2473 In some cases, link-specific information may indicate that a path to a 2474 neighbor has failed (e.g., the resetting of a virtual circuit). In such 2475 cases, link-specific information may be used to purge Neighbor Cache 2476 entries before the Neighbor Unreachability Detection would do so. 2477 However, link-specific information MUST NOT be used to confirm the 2478 reachability of a neighbor; such information does not provide end-to-end 2479 confirmation between neighboring IP layers. 2481 7. REDIRECT FUNCTION 2483 This section describes the functions related to the sending and 2484 processing of Redirect messages. 2486 7.1. Redirect Message Format 2488 A Redirect packet is sent from a router to a host to inform the host of 2489 a better first-hop node on the path to a destination. 2491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2492 | Type | Code | Checksum | 2493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2494 | Reserved | 2495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2496 | | 2497 + + 2498 | | 2499 + Target Address + 2500 | | 2501 + + 2502 | | 2503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2504 | | 2505 + + 2506 | | 2507 + Destination Address + 2508 | | 2509 + + 2510 | | 2511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2512 | Options ... 2513 +-+-+-+-+-+-+-+-+-+-+-+- 2515 IP Fields: 2517 Source Address 2518 MUST be the link-local address assigned to the 2519 interface from which this message is sent. 2521 Destination Address 2522 The Source Address of the packet that triggered the 2523 redirect. 2525 Hop Count 1 2527 Authentication Header 2528 If a Security Association for the IP Authentication 2529 Header exists between the sender and the destination 2530 address, then the sender SHOULD include this header. 2532 Routing Header MUST NOT be sent. 2534 ICMP Fields: 2536 Type 5 2538 Code 0 2540 Checksum The ICMP checksum. See [ICMPv6]. 2542 Reserved This field is unused. It MUST be initialized to zero 2543 by the sender and ignored by the receiver. 2545 Target Address An IP address of the node to which traffic for the 2546 Destination SHOULD be sent. When the target is a 2547 router, the Target Address MUST be the router's link- 2548 local address so that hosts can uniquely identify 2549 routers. When the target is the actual endpoint of 2550 communication, the target address field MUST contain 2551 the same value as the Destination Address field. 2553 Destination Address 2554 The IP address of the destination which is redirected 2555 to the target. 2557 Options: 2559 Target link-layer address 2560 The link-layer address for the target. It MUST be 2561 included on non-broadcast links, since the host can 2562 not use the multicast Neighbor Solicitation to resolve 2563 the address. If known by the router, it SHOULD be 2564 included on all link layers that have addresses. 2566 Redirected Header 2567 As much as possible of the IP packet that triggered 2568 the sending of the Redirect without making the 2569 redirect packet exceed 576 octets. 2571 Future versions of this protocol may define new option types. 2572 Receivers MUST skip over and ignore any options they do not recognize 2573 and continue processing the message. 2575 7.2. Router Specification 2577 A router SHOULD send a redirect message, subject to rate limiting, 2578 whenever it forwards a packet in which: 2580 - the Source Address field of the packet identifies a neighbor, and 2582 - the router determines that a better first-hop node resides on the 2583 same link as the sending node for the Destination Address of the 2584 packet being forwarded, and 2586 - the Destination Address of the packet is not a multicast address, 2587 and 2589 - the packet is not source routed through the router, i.e. the 2590 destination address (when the packet was received by the router) 2591 did not match one of the router's addresses. Other source routed 2592 packets, not explicitly source routed through the router, can be 2593 redirected. 2595 The transmitted redirect packet contains, consistent with the above 2596 message format: 2598 - In the Target Address field: the address to which subsequent 2599 packets for the destination SHOULD be sent. If the target is a 2600 router, that router's link-local address MUST be used. If the 2601 target is a host the target address field MUST be set to the same 2602 value as the Destination Address field. 2604 - In the Destination Address field: the destination address of the 2605 invoking IP packet. 2607 - In the options: 2609 o Target Link-Layer Address option: link-layer address of the 2610 target, if known. 2612 o Redirected Header: as much of the forwarded packet as can fit 2613 without the redirect packet exceeding 576 octets in size. 2615 A router MUST limit the rate at which Redirect messages are sent, in 2616 order to limit the bandwidth and processing costs incurred by the 2617 Redirect messages when the source does not correctly respond to the 2618 Redirects, or the source chooses to ignore unauthenticated Redirect 2619 messages. More details on the rate-limiting of ICMP error messages can 2620 be found in [ICMPv6]. 2622 A router MUST NOT update its routing tables upon receipt of a Redirect. 2624 7.3. Host Specification 2626 7.3.1. Validation of Redirect Messages 2628 A host MUST silently discard any received Redirect messages that do not 2629 satisfy all of the following validity checks: 2631 - IP Source Address is a link-local address. 2633 - IP Routing Header is not present. 2635 - if the message includes an IP Authentication Header, the message 2636 authenticates correctly. 2638 - ICMP Checksum is valid. 2640 - ICMP Code is 0. 2642 - ICMP length (derived from the IP length) is 40 or more octets. 2644 - the IP source address of the Redirect is the same as the current 2645 first-hop router for the specified destination. 2647 - the Target Address of the redirect is not a multicast address. 2649 - the Destination Address field in the redirect message does not 2650 contain a multicast address. 2652 - all included options have a length that is greater than zero. 2654 The contents of the Reserved field, and of any unrecognized options MUST 2655 be ignored. Future, backward-compatible changes to the protocol may 2656 specify the contents of the Reserved field or add new options; 2657 backward-incompatible changes may use different Code values. 2659 A host MUST NOT consider a redirect invalid just because the Target 2660 Address of the redirect is not covered under one of the link's prefixes. 2661 That is, identical values in the Target and Destination Address fields 2662 indicates that the target destination is on-link. 2664 A redirect that passes the validity checks is called a "valid redirect". 2666 7.3.2. Host Behavior 2668 A host receiving a valid redirect SHOULD update its routing information 2669 accordingly. When a redirect is received, the host updates the 2670 Destination Cache entry for the destination to use to the specified 2671 target as the new next-hop. If no Destination Cache entry exists for 2672 the destination, such an entry is created (placing it in the PROBE 2673 state). 2675 If the redirect contains a Target Link-Layer Address option the host 2676 either creates or updates the Neighbor Cache entry for the target. The 2677 link-layer address in the Neighbor Cache entry MUST be copied from the 2678 Target Link-Layer Address option into the appropriate Neighbor Cache 2679 entry. If a Neighbor Cache entry is created for the target its 2680 reachability state MUST be set to PROBE as specified in Section 6.3.2. 2681 In addition, if the Target Address is the same as the Destination 2682 Address, the host MUST treat the destination as on-link and set the 2683 "is_router" field in the corresponding Neighbor Cache entry to false. 2684 Otherwise it MUST set to true. 2686 A host MAY have a configuration switch that can be set to make it ignore 2687 a Redirect message that does not have an IP Authentication header. 2689 A host MUST NOT send Redirect messages. 2691 8. OPTIONS 2693 Options provide a mechanism for encoding variable length fields, fields 2694 that may appear multiple times in the same packet, or information that 2695 is optional and may not appear in all packets. Options can also be used 2696 to add additional functionality to future versions of ND. 2698 In order to ensure that future extensions properly coexist with current 2699 implementations, all nodes MUST silently ignore any options they do not 2700 recognize in received ND packets and continue processing the packet. 2701 All options specified in this document MUST be recognized. A node MUST 2702 NOT ignore valid options just because the ND message contains 2703 unrecognized ones. 2705 The current set of options is defined in such a way that receivers can 2706 process multiple options in the same packet independently of each other. 2707 In order to maintain these properties future options SHOULD follow the 2708 simple rule: 2710 The option MUST NOT depend on the presence or absence of any other 2711 options. The semantics of an option should depend only on the 2712 information in the fixed part of the ND packet and on the 2713 information contained in the option itself. 2715 Adhering to the above rule has the following benefits: 2717 1) Receivers can process options independently of one another. For 2718 example, an implementation can choose to process the Prefix 2719 Information option contained in a Router Advertisement message in a 2720 user-space process while the link-layer address in the same message 2721 is processed by routines in the kernel. 2723 2) Should the number of options cause a packet to exceed a link's MTU, 2724 multiple packets can carry subsets of the options without any 2725 change in semantics. 2727 3) Senders MAY send a subset of options in different packets. For 2728 instance, if the prefix Invalidation Lifetime is high it might not 2729 be necessary to include the Prefix Information option in every 2730 Router Advertisement. In addition, different routers might send 2731 different sets of options. Thus, a receiver MUST NOT associate any 2732 action with the absence of an option in a particular packet. This 2733 protocol specifies that receivers should only act on the expiration 2734 of timers and on the information that is received in the packets. 2736 When multiple options are present in a Neighbor Discovery packet, they 2737 may appear in any order; receivers MUST be prepared to process them 2738 independently of their order. There can also be multiple instances of 2739 the same option in a message, for instance Prefix Information options. 2741 The length of all options is a multiple of 8 octets, ensuring 2742 appropriate alignment without any "pad" options. The fields in the 2743 options, as well as the fields in ND packets, are defined to align them 2744 on their natural boundaries (e.g. a 16-bit field is aligned on a 16-bit 2745 boundary) with the exception of the 128-bit IP addresses/prefixes, which 2746 are aligned on a 64-bit boundary. 2748 The link-layer address field contains an uninterpreted octet string; it 2749 is aligned on an 8-bit boundary. 2751 All options are of the form: 2753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2754 | Type | Length | ... | 2755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2756 ~ ... ~ 2757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2759 Fields: 2761 Type 8-bit identifier of the type of option. The options 2762 defined in this document are: 2764 Option Name Type 2766 Source Link-Layer Address 1 2767 Target Link-Layer Address 2 2768 Prefix Information 3 2769 Redirected Header 4 2770 MTU 5 2772 Length 8-bit unsigned integer. The length of the option in 2773 units of 8 octets. The value 0 is invalid. Nodes 2774 MUST silently discard an ND packet that contains an 2775 option with length zero. 2777 The size of an ND packet including the IP header is limited to the link 2778 MTU (which is at least 576 octets). When adding options to an ND packet 2779 a node MUST NOT exceed the link MTU. 2781 The only ND packets that can potentially exceed the link MTU are Router 2782 Advertisements and Redirects; the former due to a large number of Prefix 2783 Information options and the latter due to the Redirected Header option. 2785 If there are more Prefix Information options than can fit in a single 2786 Router Advertisement packet the router MUST send multiple separate 2787 advertisements that each contain a subset of the set of prefixes. 2789 The amount of data to include in the Redirected Header option MUST be 2790 limited so that the entire redirect packet does not exceed 576 octets. 2792 8.1. Source/Target Link-layer Address 2794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2795 | Type | Length | Link-Layer Address ... 2796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2798 Fields: 2800 Type 2801 1 for Source Link-layer Address 2802 2 for Target Link-layer Address 2804 Length The length of the option in units of 8 octets. For 2805 example, the length for IEEE 802 addresses is 1 2806 [IPv6-ETHER]. 2808 Link-Layer Address 2809 The variable length link-layer address. 2811 The content and format of this field is expected to be 2812 specified in specific documents that describe how IPv6 2813 operates over different link layers. For instance, 2814 [IPv6-ETHER]. 2816 Description 2817 The Source Link-Layer address option contains the 2818 link-layer address of the sender of the packet. It is 2819 used in the Neighbor Solicitation, Router 2820 Solicitation, and Router Advertisement packets. 2822 The Target Link-Layer address option contains the 2823 link-layer address of the target. It is used in 2824 Neighbor Advertisement and Redirect packets. 2826 8.2. Prefix Information 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | Type | Length | Prefix Length |L|A| Reserved1 | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2831 | Invalidation Lifetime | 2832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2833 | Deprecation Lifetime | 2834 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 | Reserved2 | 2836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2837 | | 2838 + + 2839 | | 2840 + Prefix + 2841 | | 2842 + + 2843 | | 2844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2846 Fields: 2848 Type 3 2849 Length 4 2851 Prefix Length 8-bit unsigned integer. The number of leading bits in 2852 the Prefix that are valid. The value ranges from 0 to 2853 128. 2855 L 1-bit on-link flag. When set, indicates that this 2856 prefix can be used for on-link determination. 2858 A 1-bit autonomous address-configuration flag. When set 2859 indicates that this prefix can used for autonomous 2860 address configuration as specified in [ADDRCONF]. 2862 Reserved1 6-bit unused field. It MUST be initialized to zero by 2863 the sender and ignored by the receiver. 2865 Invalidation Lifetime 2866 32-bit unsigned integer. The lifetime of the prefix 2867 in seconds for the purpose of on-link determination. 2868 A value of all one bits (0xffffffff) represents 2869 infinity. This lifetime is also used by [ADDRCONF]. 2871 Deprecation Lifetime 2872 32 bits reserved for autonomous address configuration. 2873 A value of all one bits (0xffffffff) represents 2874 infinity. See [ADDRCONF]. 2876 Reserved2 This field is unused. It MUST be initialized to zero 2877 by the sender and ignored by the receiver. 2879 Prefix An IP address or a prefix of an IP address. The 2880 prefix length field contains the number of valid 2881 leading bits in the prefix. 2883 Description 2884 The Prefix Information option is only used in Router 2885 Advertisement packets. It provide hosts with on-link 2886 prefixes and prefixes for Address Autoconfiguration. 2888 Implementations can choose to process the on-link 2889 aspects of the prefixes separately from the address 2890 autoconfiguration aspects of the prefixes e.g. by 2891 passing a copy of each valid Router Advertisement 2892 message to both an "on-link" and an "addrconf" 2893 function. Each function can then operate on the 2894 prefixes that have the appropriate flag set. 2896 8.3. Redirected Header 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2899 | Type | Length | Reserved | 2900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2901 | Reserved | 2902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 | | 2904 ~ IP header + data ~ 2905 | | 2906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2908 Fields: 2910 Type 4 2912 Length The length of the option in units of 8 octets. 2914 Reserved These fields are unused. They MUST be initialized to 2915 zero by the sender and ignored by the receiver. 2917 IP header + data 2918 The original packet truncated to ensure that the size 2919 of the redirect message does not exceed 576 octets. 2921 Description 2922 The Redirected Header option MUST be included in 2923 Redirect packets. 2925 8.4. MTU 2927 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2928 | Type | Length | Reserved | 2929 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2930 | MTU | 2931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2933 Fields: 2935 Type 5 2937 Length 1 2939 Reserved This field is unused. It MUST be initialized to zero 2940 by the sender and ignored by the receiver. 2942 MTU 32-bit unsigned integer. The recommended MTU for the 2943 link. 2945 Description 2946 The MTU option SHOULD be included in Router 2947 Advertisement packets when the link has no well-known 2948 MTU and it MAY be included on links with a well-known 2949 MTU. 2951 Hosts MUST handle this option by setting the LinkMTU 2952 variable for the interface to the received value. If 2953 the routers on the link are advertising different MTU 2954 values this will result in hosts switching between the 2955 different MTUs. Therefore, routers SHOULD verify the 2956 consistency between the MTU they and other routers 2957 advertise, logging a network management event when 2958 contradictory advertisements are detected. 2960 When a host or its interface is initialized the 2961 LinkMTU of the interface SHOULD be set to the 2962 predefined value for that type of link. If the host 2963 receives no MTU option it MUST continue to use that 2964 predefined value. The MTU option can be used by 2965 routers to both increase and decrease the MTU. 2967 In configurations in which heterogeneous technologies 2968 are bridged together, the maximum supported MTU may 2969 differ from one segment to another. If the bridges do 2970 not generate ICMP Packet Too Big messages, 2971 communicating nodes will be unable to use Path MTU to 2972 dynamically determine the appropriate MTU on a per- 2973 neighbor basis. In such cases, routers use the MTU 2974 option to specify an MTU value supported by all 2975 segments. 2977 9. MULTIHOMED HOSTS 2979 There are a number of complicating issues that arise when Neighbor 2980 Discovery is used by hosts that have multiple interfaces. This section 2981 does not attempt to define the proper operation of multihomed hosts with 2982 regard to Neighbor Discovery. Rather, it identifies issues that require 2983 further study. Implementors are encouraged to experiment with various 2984 approaches to making Neighbor Discovery work on multihomed hosts and to 2985 report their experiences. 2987 If a multihomed host receives Router Advertisements on all of its 2988 interfaces, it will (probably) have learned on-link prefixes for the 2989 addresses residing on each link. When a packet must be sent through a 2990 router, however, selecting the "wrong" router can result in a suboptimal 2991 or non-functioning path. There are number of issues to consider: 2993 1) In order for a router to send a redirect, it must determine that 2994 the packet it is forwarding originates from a neighbor. The 2995 standard test for this case is to compare the source address of the 2996 packet to the list of on-link prefixes associated with the 2997 interface on which the packet was received. If the originating 2998 host is multihomed, however, the source address it uses may belong 2999 to an interface other than the interface from which it was sent. 3000 In such cases, a router will not send redirects, and suboptimal 3001 routing is likely. In order to be redirected, the sending host 3002 must always send packets out the interface corresponding to the 3003 outgoing packet's source address. Note that this issue never 3004 arises with non-multihomed hosts; they only have one interface. 3006 2) If the selected first-hop router does not have a route at all for 3007 the destination, it will be unable to deliver the packet. However, 3008 the destination may be reachable through a router on one of the 3009 other interfaces. Neighbor Discovery does not address this 3010 scenario; it does not arise in the non-multihomed case. 3012 3) Even if the first-hop router does have a route for a destination, 3013 there may be a better route via another interface. No mechanism 3014 exists for the multihomed host to detect this situation. 3016 If a multihomed host fails to receive Router Advertisements on one or 3017 more of its interfaces, it will not know (in the absence of configured 3018 information) which destinations are on-link on the affected 3019 interface(s). This leads to a number of problems: 3021 1) If no Router Advertisement is received on any interfaces, a 3022 multihomed host will have no way of knowing which interface to send 3023 packets out on, even for on-link destinations. Under similar 3024 conditions in the non-multihomed host case, a node treats all 3025 destinations as residing on-link, and communication proceeds. In 3026 the multihomed case, however, additional information is needed to 3027 select the proper outgoing interface. Alternatively, a node could 3028 attempt to perform address resolution on all interfaces, a step 3029 involving significant complexity that is not present in the non- 3030 multihomed host case. 3032 2) If Router Advertisements are received on some, but not all 3033 interfaces, a multihomed host could choose to only send packets out 3034 on the interfaces on which it has received Router Advertisements. 3036 A key assumption made here, however, is that routers on those other 3037 interfaces will be able to route packets to the ultimate 3038 destination, even when those destinations reside on the subnet to 3039 which the sender connects, but has no on-link prefix information. 3040 Should the assumption be false, communication would fail. Even if 3041 the assumption holds, packets will traverse a sub-optimal path. 3043 10. PROTOCOL CONSTANTS 3045 Router constants: 3047 MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds 3049 MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions 3051 MAX_RTR_RESPONSE_DELAY 6 seconds 3053 Host constants: 3055 MAX_RTR_SOLICITATION_DELAY 1 second 3057 RTR_SOLICITATION_INTERVAL 3 seconds 3059 MAX_RTR_SOLICITATIONS 3 transmissions 3061 Node constants: 3063 MAX_MULTICAST_SOLICIT 3 transmissions 3065 MAX_UNICAST_SOLICIT 3 transmissions 3067 MAX_ANYCAST_DELAY_TIME 1 second 3069 MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions 3071 MIN_NEIGHBOR_ADVERT_INTERVAL 16 seconds 3073 REACHABLE_TIME 30,000 milliseconds 3075 RETRANS_TIMER 10,000 milliseconds 3077 DELAY_FIRST_PROBE_TIME 5 seconds 3079 MIN_RANDOM_FACTOR .5 3081 MAX_RANDOM_FACTOR 1.5 3083 Additional protocol constants are defined with the message formats in 3084 Section 5.1, 6.1, and 7.1. 3086 All protocol constants are subject to change in future revisions of the 3087 protocol. 3089 11. FUTURE EXTENSIONS 3091 Possible extensions for future study are: 3093 o Using dynamic timers to be able to adapt to links with widely varying 3094 delay. Measuring round trip times, however, requires acknowledgments 3095 and sequence numbers in order to match received Neighbor 3096 Advertisements with the actual Neighbor Solicitation that triggered 3097 the advertisement. Implementors wishing to experiment with such a 3098 facility could do so in a backwards-compatible way by defining a new 3099 option carrying the necessary information. Nodes not understanding 3100 the option would simply ignore it. 3102 o Adding capabilities to facilitate the operation over links that 3103 currently require hosts to register with an address resolution 3104 server. This could for instance enable routers to ask hosts to send 3105 them periodic unsolicited advertisements. Once again this can be 3106 added using a new option sent in the Router Advertisements. 3108 o Adding additional procedures for links where asymmetric and non- 3109 transitive reachability is part of normal operations. Such 3110 procedures might allow hosts and routers to find usable paths on, 3111 e.g., radio links. 3113 12. OPEN ISSUES 3115 o Should the routers listed in Router Advertisements include a 3116 precedence metric? What are the semantics of such metrics (e.g., 3117 "router preferences" vs. "default router preferences"). 3119 13. SECURITY CONSIDERATIONS 3121 Neighbor Discovery is subject attacks that cause IP packets to flow to 3122 unexpected places. Such attacks can be used to cause denial of service 3123 but also allow nodes to intercept and optionally modify packets destined 3124 for other nodes. 3126 The protocol reduces the exposure to such threats in the absence of 3127 authentication by designing ND packets that modify neighbor state (e.g. 3128 cached link-layer addresses) in such a way that routers cannot or will 3129 not forward them. Limiting the scope of ND packets to a particular link 3130 makes the protocol more robust against the accidental sending of ND 3131 messages with a hop count larger than one. Specifically: 3133 - the source address of all packets have link-local scope. Routers 3134 MUST NOT forward such packets. See [ADDR-ARCH]. 3136 - with the exception of Redirects, the destination address in all ND 3137 packets that can modify any state in the recipient node have link- 3138 local scope; routers will be unable to forward them. 3140 - packets containing a Routing Header are ignored upon receipt. If 3141 Routing Headers were allowed, it would be possible to forward packets 3142 through routers, even if the packet's ultimate destination has link- 3143 local scope. 3145 Note that the use of link-local destination address makes the checks for 3146 link-local source address somewhat redundant for ND messages other than 3147 Redirects. The Redirect message is the only message type sent to a 3148 global unicast address that can modify the state in the receiving node. 3149 Thus proper robustness for Redirect messages requires that routers not 3150 forward packets with link-local source addresses. 3152 The trust model for redirects is the same as in IPv4. A redirect is 3153 accepted only if received from the same router that is currently being 3154 used for that destination. It is natural to trust the routers on the 3155 link. If a host has been redirected to another node (i.e. the 3156 destination is on-link) there is no way to prevent the target from 3157 issuing another redirect to some other destination. However, this 3158 exposure is no worse than it was; the target host, once subverted, could 3159 always act as a hidden router to forward traffic elsewhere. 3161 The protocol contains no mechanism to determine which nodes are 3162 authorized to send Router Advertisements; any node, presumably even in 3163 the presence of authentication, can send Router Advertisement messages 3164 thereby being able to cause denial of service. Furthermore, any node 3165 can send proxy Neighbor Advertisements as well as unsolicited Neighbor 3166 Advertisements as a potential denial of service attack. 3168 Neighbor Discovery protocol packet exchanges can be authenticated using 3169 the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an 3170 Authentication Header when sending Neighbor Discovery packets if a 3171 security association for use with the IP Authentication Header exists 3172 for the destination address. The security associations may have been 3173 created through manual configuration or through the operation of some 3174 key management protocol. 3176 Received Authentication Headers in Neighbor Discovery packets MUST be 3177 verified for correctness and packets with incorrect authentication MUST 3178 be ignored. 3180 It SHOULD be possible for the system administrator to configure a node 3181 to ignore any Neighbor Discovery messages that are not authenticated 3182 using either the Authentication Header or Encapsulating Security 3183 Payload. The configuration technique for this MUST be documented. Such 3184 a switch SHOULD default to allowing unauthenticated messages. 3186 Confidentiality issues are addressed by the IP Security Architecture and 3187 the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP]. 3189 REFERENCES 3191 [ADDRCONF] S. Thomson, "IPv6 Address Autoconfiguration", Internet 3192 Draft. 3194 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing 3195 Architecture", Internet Draft. 3197 [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 3198 Service", RFC 1546, November 1993. 3200 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 3201 RFC 826, November 1982. 3203 [HR-CL] R. Braden, Editor, "Requirements for Internet Hosts -- 3204 Communication Layers", STD 3, RFC 1122, October 1989. 3206 [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 3207 792, September 1981. 3209 [ICMPv6] A. Conta, and S. Deering, "ICMP for the Internet Protocol 3210 Version 6 (IPv6)", Internet Draft. 3212 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 3213 (IPv6) Specification", Internet Draft. 3215 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 3216 Packets over Ethernet Networks", Internet Draft. 3218 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 3219 Protocol". RFC 1825, August 1995. 3221 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 3222 August 1995. 3224 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 3225 RFC 1827, August 1995. 3227 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 3228 September 1991. 3230 [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture 3231 Extensions for Shared Media", RFC 1620, May 1994. 3233 [ASSIGNED] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 3234 October 1994. 3236 [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing 3237 Messages", IEEE/ACM Transactions on Networking, April 1994. 3238 ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z 3240 AUTHORS' ADDRESSES 3242 Erik Nordmark Thomas Narten 3243 Sun Microsystems, Inc. IBM Corporation 3244 2550 Garcia Ave P.O. Box 12195 3245 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 3246 USA USA 3248 phone: +1 415 336 2788 phone: +1 919 254 7798 3249 fax: +1 415 336 6015 fax: +1 919 254 4027 3250 email: nordmark@sun.com email: narten@vnet.ibm.com 3252 William Allen Simpson 3253 Daydreamer 3254 Computer Systems Consulting Services 3255 1384 Fontaine 3256 Madison Heights, Michigan 48071 3257 USA 3259 email: Bill.Simpson@um.cc.umich.edu 3260 bsimpson@MorningStar.com 3262 CHANGES SINCE PREVIOUS DOCUMENT 3264 There are several changes since the previous version documented in: 3265 3266 based on feedback from the working group: 3268 o Link-local source address required for Neighbor Solicitation 3269 and Neighbor Advertisement messages. This change implied 3270 adding an ICMP Sender Address field to the Neighbor 3271 Solicitation message and a Secondary Advertisement flag to 3272 the Neighbor Advertisement message. This change improves 3273 the robustness of the protocol - it is no longer possible 3274 for off-link nodes to send ND messages to a link. 3276 o Made the ReachableTime value random to avoid synchronizing 3277 Neighbor Unreachability Detection messages when there is 3278 more of less "constant" traffic (i.e. packets are sent with 3279 spacing that is very short compared to the ReachableTime 3280 value). Without such randomization the NUD probes from all 3281 nodes on the link would be sent with almost the same spacing 3282 which can result in synchronization. There is no need for 3283 any additional randomization elsewhere in the protocol since 3284 there is no long-term periodic behavior - at most 3 packets 3285 are transmitted. 3287 o Added definitions for MUST, SHOULD, and MAY. 3289 o Made NUD and address resolution use the same retransmission 3290 timer (which can be specified in the Router Advertisements). 3291 Increased the default value of this timer from 3 seconds to 3292 10 seconds. 3294 o Restricted ReachableTime so that it can not be set to more 3295 than 1 hour to prevent misconfiguration that would make ND 3296 not detect e.g. changed link-layer addresses. 3298 o Added text about the support for links with multiple MTUs 3299 (e.g. bridged Ethernet and FDDI). With unmodified bridges 3300 the routers must send MTU options containing the smaller 3301 (smallest) MTU. If the bridges are made aware of IPv6 they 3302 can participate in path MTU discovery (for unicast and 3303 multicast) and send ICMP packet too big errors for IPv6 3304 packets that cross the bridge. 3306 o Added additional validatity checks for Router Solicitation 3307 and Router Advertisement messages: the destination address 3308 must be a link local address or a multicast address with 3309 link-local scope. 3311 o Added validity check for all messages: no routing header is 3312 allowed. 3314 o Changed the use of the "designated address" term to using 3315 "link-local address". 3317 o Clarified authentication header text. 3319 o Clarified how multicast packets are handled in the 3320 conceptual model. 3322 o Added text that ND messages are themselves not subject to 3323 NUD probes. This avoids an observed problem where a NUD 3324 NS/NA exchange would result in a subsequent NUD NS/NA 3325 exchange of packets. 3327 o Clarified that the neighbor cache entries generated by 3328 unsolicited information (RS, RA, NA, Redirect) do still get 3329 DELAY_FIRST_PROBE_TIME seconds before a probe is sent (in 3330 order to benefit from upper-layer advise). 3332 o Solicited Proxy/anycast advertisements are delayed 0-1 3333 second to avoid creating a load on the network and/or 3334 receiver.