idnits 2.17.1 draft-ietf-ipngwg-discovery-04.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-04-26) 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 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 401: '... MUST have a link-local address. Also, [ADDRCONF]...' RFC 2119 keyword, line 420: '... MUST...' RFC 2119 keyword, line 424: '... MUST NOT...' RFC 2119 keyword, line 428: '... SHOULD...' RFC 2119 keyword, line 434: '... SHOULD NOT...' (205 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3651 has weird spacing: '...k-layer add...' -- 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 3423, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 3439, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRCONF' ** Obsolete normative reference: RFC 1884 (ref. 'ADDR-ARCH') (Obsoleted by RFC 2373) ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCST') ** Obsolete normative reference: RFC 1885 (ref. 'ICMPv6') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) -- 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: 18 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten, IBM 3 February 1, 1996 Erik Nordmark, Sun Microsystems 4 W A Simpson, Daydreamer 6 Neighbor Discovery for IP Version 6 (IPv6) 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this memo is unlimited. 30 This Internet Draft expires August 1, 1996. 32 Abstract 34 This document specifies the Neighbor Discovery protocol for IP 35 Version 6. IPv6 nodes on the same link use Neighbor Discovery to 36 discover each other's presence, to determine each other's link-layer 37 addresses, to find routers and to maintain reachability information 38 about the paths to active neighbors. 40 Contents 42 Status of this Memo.......................................... 1 44 1. INTRODUCTION............................................. 4 46 2. TERMINOLOGY.............................................. 4 47 2.1. General............................................. 4 48 2.2. Link Types.......................................... 7 49 2.3. Addresses........................................... 9 50 2.4. Requirements........................................ 10 52 3. PROTOCOL OVERVIEW........................................ 11 53 3.1. Comparison with IPv4................................ 14 54 3.2. Supported Link Types................................ 16 56 4. MESSAGE FORMATS.......................................... 18 57 4.1. Router Solicitation Message Format.................. 18 58 4.2. Router Advertisement Message Format................. 19 59 4.3. Neighbor Solicitation Message Format................ 21 60 4.4. Neighbor Advertisement Message Format............... 23 61 4.5. Redirect Message Format............................. 25 62 4.6. Option Formats...................................... 27 63 4.6.1. Source/Target Link-layer Address............... 28 64 4.6.2. Prefix Information............................. 29 65 4.6.3. Redirected Header.............................. 31 66 4.6.4. MTU............................................ 32 68 5. CONCEPTUAL MODEL OF A HOST............................... 33 69 5.1. Conceptual Data Structures.......................... 33 70 5.2. Conceptual Sending Algorithm........................ 35 71 5.3. Garbage Collection and Timeout Requirements......... 37 73 6. ROUTER AND PREFIX DISCOVERY.............................. 37 74 6.1. Message Validation.................................. 38 75 6.1.1. Validation of Router Solicitation Messages..... 38 76 6.1.2. Validation of Router Advertisement Messages.... 39 77 6.2. Router Specification................................ 39 78 6.2.1. Router Configuration Variables................. 39 79 6.2.2. Becoming An Advertising Interface.............. 43 80 6.2.3. Router Advertisement Message Content........... 44 81 6.2.4. Sending Unsolicited Router Advertisements...... 45 82 6.2.5. Ceasing To Be An Advertising Interface......... 46 83 6.2.6. Processing Router Solicitations................ 46 84 6.2.7. Router Advertisement Consistency............... 48 85 6.2.8. Link-local Address Change...................... 48 86 6.3. Host Specification.................................. 49 87 6.3.1. Host Configuration Variables................... 49 88 6.3.2. Host Variables................................. 49 89 6.3.3. Interface Initialization....................... 50 90 6.3.4. Processing Received Router Advertisements...... 50 91 6.3.5. Timing out Prefixes and Default Routers........ 53 92 6.3.6. Default Router Selection....................... 53 93 6.3.7. Sending Router Solicitations................... 54 95 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 55 96 7.1. Message Validation.................................. 55 97 7.1.1. Validation of Neighbor Solicitations........... 55 98 7.1.2. Validation of Neighbor Advertisements.......... 56 99 7.2. Address Resolution.................................. 57 100 7.2.1. Interface Initialization....................... 57 101 7.2.2. Sending Neighbor Solicitations................. 57 102 7.2.3. Receipt of Neighbor Solicitations.............. 58 103 7.2.4. Sending Solicited Neighbor Advertisements...... 59 104 7.2.5. Receipt of Neighbor Advertisements............. 60 105 7.2.6. Sending Unsolicited Neighbor Advertisements.... 61 106 7.2.7. Anycast Neighbor Advertisements................ 62 107 7.2.8. Proxy Neighbor Advertisements.................. 62 108 7.3. Neighbor Unreachability Detection................... 63 109 7.3.1. Reachability Confirmation...................... 64 110 7.3.2. Neighbor Cache Entry States.................... 65 111 7.3.3. Node Behavior.................................. 66 113 8. REDIRECT FUNCTION........................................ 68 114 8.1. Validation of Redirect Messages..................... 68 115 8.2. Router Specification................................ 69 116 8.3. Host Specification.................................. 70 118 9. EXTENSIBILITY - OPTION PROCESSING........................ 71 120 10. PROTOCOL CONSTANTS...................................... 72 122 11. SECURITY CONSIDERATIONS................................. 73 124 REFERENCES................................................... 75 126 AUTHORS' ADDRESSES........................................... 76 128 APPENDIX A: MULTIHOMED HOSTS................................. 77 130 APPENDIX B: FUTURE EXTENSIONS................................ 78 132 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 79 134 APPENDIX D: IMPLEMENTATION ISSUES............................ 80 136 1. INTRODUCTION 138 This specification defines the Neighbor Discovery (ND) protocol for 139 Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use 140 Neighbor Discovery to determine the link-layer addresses for neighbors 141 known to reside on attached links and to quickly purge cached values 142 that become invalid. Hosts also use Neighbor Discovery to find 143 neighboring routers that are willing to forward packets on their behalf. 144 Finally, nodes use the protocol to actively keep track of which 145 neighbors are reachable and which are not, and to detect changed link- 146 layer addresses. When a router or the path to a router fails, a host 147 actively searches for functioning alternates. 149 Unless specified otherwise (in a document that covers operating IP over 150 a particular link type) this document applies to all link types. 151 However, because ND uses link-layer multicast for some of its services, 152 it is possible that on some link types (e.g., NBMA links) alternative 153 protocols or mechanisms to implement those services will be specified 154 (in the appropriate document covering the operation of IP over a 155 particular link type). The services described in this document that are 156 not directly dependent on multicast, such as Redirects, Next-hop 157 determination, Neighbor Unreachability Detection, etc., are expected to 158 be provided as specified in this document. The details of how one uses 159 ND on NBMA links is an area for further study. 161 The authors would like to acknowledge the contributions the IPNGWG 162 working group and, in particular, (in alphabetical order) Ran Atkinson, 163 Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Francis Dupont, 164 Robert Elz, Robert Gilligan, Robert Hinden, Allison Mankin, Dan 165 McDonald, Charles Perkins, Matt Thomas, and Susan Thomson. 167 2. TERMINOLOGY 169 2.1. General 171 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 172 are used only in contexts where necessary to avoid 173 ambiguity. 175 ICMP - Internet Message Control Protocol for the Internet 176 Protocol Version 6. The terms ICMPv4 and ICMPv6 are 177 used only in contexts where necessary to avoid 178 ambiguity. 180 node - a device that implements IP. 182 router - a node that forwards IP packets not explicitly 183 addressed to itself. 185 host - any node that is not a router. 187 upper layer - a protocol layer immediately above IP. Examples are 188 transport protocols such as TCP and UDP, control 189 protocols such as ICMP, routing protocols such as OSPF, 190 and internet or lower-layer protocols being "tunneled" 191 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 192 or IP itself. 194 link - a communication facility or medium over which nodes can 195 communicate at the link layer, i.e., the layer 196 immediately below IP. Examples are Ethernets (simple 197 or bridged), PPP links, X.25, Frame Relay, or ATM 198 networks as well as internet (or higher) layer 199 "tunnels", such as tunnels over IPv4 or IPv6 itself. 201 interface - a node's attachment to a link. 203 neighbors - nodes attached to the same link. 205 address - an IP-layer identifier for an interface or a set of 206 interfaces. 208 anycast address 209 - an identifier for a set of interfaces (typically 210 belonging to different nodes). A packet sent to an 211 anycast address is delivered to one of the interfaces 212 identified by that address (the "nearest" one, 213 according to the routing protocol's measure of 214 distance). See [ADDR-ARCH]. 216 prefix - a bit string that consists of some number of initial 217 bits of an address. 219 link-layer address 220 - a link-layer identifier for an interface. Examples 221 include IEEE 802 addresses for Ethernet links and E.164 222 addresses for ISDN links. 224 on-link - an address that is assigned to an interface on a 225 specified link. A node considers an address to be on- 226 link if: 228 - it is covered by one of the link's prefixes, or 229 - a neighboring router specifies the address as the 230 target of a Redirect message, or 232 - a Neighbor Advertisement message is received for 233 the (target) address, or 235 - any Neighbor Discovery message is received from the 236 address. 238 off-link - the opposite of "on-link"; an address that is not 239 assigned to any interfaces on the specified link. 241 reachability 242 - whether or not the one-way "forward" path to a neighbor 243 is functioning properly. In particular, whether 244 packets sent to a neighbor are reaching the IP layer on 245 the neighboring machine and are being processed 246 properly by the receiving IP layer. For neighboring 247 routers, reachability means that packets sent by a 248 node's IP layer are delivered to the router's IP layer, 249 and the router is indeed forwarding packets (i.e., it 250 is configured as a router, not a host). For hosts, 251 reachability means that packets sent by a node's IP 252 layer are delivered to the neighbor host's IP layer. 254 packet - an IP header plus payload. 256 link MTU - the maximum transmission unit, i.e., maximum packet 257 size in octets, that can be conveyed in one piece over 258 a link. 260 target - an address about which address resolution information 261 is sought, or an address which is the new first-hop 262 when being redirected. 264 proxy - a router that responds to Neighbor Discovery query 265 messages on behalf of another node. A router acting on 266 behalf of a mobile node that has moved off-link could 267 potentially act as a proxy for the mobile node. 269 ICMP destination unreachable indication 270 - an error indication returned to the original sender of 271 a packet that cannot be delivered for the reasons 272 outlined in [ICMPv6]. If the error occurs on a node 273 other than the node originating the packet, an ICMP 274 error message is generated. If the error occurs on the 275 originating node, an implementation is not required to 276 actually create and send an ICMP error packet to the 277 source, as long as the upper-layer sender is notified 278 through an appropriate mechanism (e.g., return value 279 from a procedure call). Note, however, that an 280 implementation may find it convenient in some cases to 281 return errors to the sender by taking the offending 282 packet, generating an ICMP error message, and then 283 delivering it (locally) through the generic error 284 handling routines. 286 random delay 287 - when sending out messages, it is sometimes necessary to 288 delay a transmission for a random amount of time in 289 order to prevent multiple nodes from transmitting at 290 exactly the same time, or to prevent long-range 291 periodic transmissions from synchronizing with each 292 other [SYNC]. When a random component is required, a 293 node calculates the actual delay in such a way that the 294 computed delay forms a uniformly-distributed random 295 value that falls between the specified minimum and 296 maximum delay times. The implementor must take care to 297 insure that the granularity of the calculated random 298 component and the resolution of the timer used are both 299 high enough to insure that the probability of multiple 300 nodes delaying the same amount of time is small. 302 random delay seed 303 - If a pseudo-random number generator is used in 304 calculating a random delay component, the generator 305 should be initialized with a unique seed prior to being 306 used. Note that it is not sufficient to use the 307 interface token alone as the seed, since interface 308 tokens will not always be unique. To reduce the 309 probability that duplicate interface tokens cause the 310 same seed to be used, the seed should be calculated 311 from a variety of input sources (e.g., machine 312 components) that are likely to be different even on 313 identical "boxes". For example, the seed could be 314 formed by combining the CPU's serial number with an 315 interface token. 317 2.2. Link Types 319 Different link layers have different properties. The ones of concern to 320 Neighbor Discovery are: 322 multicast - a link that supports some mechanism at the link 323 layer for sending packets to all (i.e., broadcast) 324 or a subset of all neighbors. Multicast/broadcast 325 can be provided by a variety of link layer 326 mechanisms such as the physical link layer itself 327 (for example, Ethernet), replicated unicast packets 328 sent by the link layer software, or multicast 329 servers (such as in ATM). Note that all point-to- 330 point links are trivially capable of supporting 331 multicast. 333 point-to-point - a link that connects exactly two interfaces. A 334 point-to-point link is assumed to have multicast 335 capability and have a link-local address. 337 non-broadcast multi-access (NBMA) 338 - a link to which more than two interfaces can attach, 339 but that does not support any form of multicast or 340 broadcast (e.g., X.25). 342 shared media - a link that allows direct communication among a 343 number of nodes, but attached nodes are configured 344 in such a way that they do not have complete prefix 345 information for all on-link destinations. That is, 346 at the IP level, nodes on the same link may not know 347 that they are neighbors; by default, they 348 communicate through a router. Examples are large 349 (switched) public data networks such as SMDS and B- 350 ISDN. Also known as "large clouds". See [SH- 351 MEDIA]. 353 variable MTU - a link that does not have a well-defined MTU (e.g., 354 IEEE 802.5 token rings). Many links (e.g., 355 Ethernet) have a standard MTU defined by the link- 356 layer protocol or by the specific document 357 describing how to run IP over the link layer. 359 asymmetric reachability 360 - a link where non-reflexive and/or non-transitive 361 reachability is part of normal operation. (Non- 362 reflexive reachability means packets from A reach B 363 but packets from B don't reach A. Non-transitive 364 reachability means packets from A reach B, and 365 packets from B reach C, but packets from A don't 366 reach C.) Many radio links exhibit these 367 properties. 369 2.3. Addresses 371 Neighbor Discovery makes use of a number of different addresses defined 372 in [ADDR-ARCH], including: 374 all-nodes multicast address 375 - the link-local scope address to reach all nodes. 376 FF02::1 378 all-routers multicast address 379 - the link-local scope address to reach all routers. 380 FF02::2 382 solicited-node multicast address 383 - a link-local scope multicast address that is computed 384 as a function of the solicited target's address. The 385 solicited-node multicast address is formed by taking 386 the low-order 32 bits of the target IP address and 387 appending those bits to the 96-bit prefix 388 FF02:0:0:0:0:1 to produce a multicast address within 389 the range FF02::1:0:0 to FF02::1:FFFF:FFFF. For 390 example, the solicited node multicast address 391 corresponding to the IP address 4037::01:800:200E:8C6C 392 is FF02::1:200E:8C6C. IP addresses that differ only in 393 the high-order bits, e.g., due to multiple high-order 394 prefixes associated with different providers, will map 395 to the same solicited-node address thereby reducing the 396 number of multicast addresses a node must join. 398 link-local address 399 - a unicast address having link-only scope that can be 400 used to reach neighbors. All interfaces on routers 401 MUST have a link-local address. Also, [ADDRCONF] 402 requires that interfaces on hosts have a link-local 403 address. 405 unspecified address 406 - a reserved address value that indicates the lack of an 407 address (e.g., the address is unknown). It is never 408 used as a destination address, but may be used as a 409 source address if the sender does not (yet) know its 410 own address (e.g., while verifying an address is unused 411 during address autoconfiguration [ADDRCONF]). The 412 unspecified address has a value of 0:0:0:0:0:0:0:0. 414 2.4. Requirements 416 Throughout this document, the words that are used to define the 417 significance of the particular requirements are capitalized. These 418 words are: 420 MUST 421 This word or the adjective "REQUIRED" means that the item is an 422 absolute requirement of this specification. 424 MUST NOT 425 This phrase means the item is an absolute prohibition of this 426 specification. 428 SHOULD 429 This word or the adjective "RECOMMENDED" means that there may 430 exist valid reasons in particular circumstances to ignore this 431 item, but the full implications should be understood and the 432 case carefully weighed before choosing a different course. 434 SHOULD NOT 435 This phrase means that there may exist valid reasons in 436 particular circumstances when the listed behavior is acceptable 437 or even useful, but the full implications should be understood 438 and the case carefully weighted before implementing any behavior 439 described with this label. 441 MAY This word or the adjective "OPTIONAL" means that this item is 442 truly optional. One vendor may choose to include the item 443 because a particular marketplace requires it or because it 444 enhances the product, for example, another vendor may omit the 445 same item. 447 This document also makes use of internal conceptual variables to 448 describe protocol behavior and external variables that an implementation 449 must allow system administrators to change. The specific variable 450 names, how their values change, and how their settings influence 451 protocol behavior are provided to demonstrate protocol behavior. An 452 implementation is not required to have them in the exact form described 453 here, so long as its external behavior is consistent with that described 454 in this document. 456 3. PROTOCOL OVERVIEW 458 This protocol solves a set of problems related to the interaction 459 between nodes attached to the same link. It defines mechanisms for 460 solving each of the following problems: 462 Router Discovery: How hosts locate routers that reside on an 463 attached link. 465 Prefix Discovery: How hosts discover the set of address prefixes 466 that define which destinations are on-link for an 467 attached link. (Nodes use prefixes to distinguish 468 destinations that reside on-link from those only 469 reachable through a router.) 471 Parameter Discovery: How a node learns such link parameters as the 472 link MTU or such Internet parameters as the hop limit 473 value to place in outgoing packets. 475 Address Autoconfiguration: How nodes automatically configure an 476 address for an interface. 478 Address resolution: How nodes determine the link-layer address of an 479 on-link destination (e.g., a neighbor) given only the 480 destination's IP address. 482 Next-hop determination: The algorithm for mapping an IP destination 483 address into the IP address of the neighbor to which 484 traffic for the destination should be sent. The next-hop 485 can be a router or the destination itself. 487 Neighbor Unreachability Detection: How nodes determine that a 488 neighbor is no longer reachable. For neighbors used as 489 routers, alternate default routers can be tried. For 490 both routers and hosts, address resolution can be 491 performed again. 493 Duplicate Address Detection: How a node determines that an address 494 it wishes to use is not already in use by another node. 496 Redirect: How a router informs a host of a better first-hop node to 497 reach a particular destination. 499 Neighbor Discovery defines five different ICMP packet types: A pair of 500 Router Solicitation and Router Advertisement messages, a pair of 501 Neighbor Solicitation and Neighbor Advertisements messages, and a 502 Redirect message. The messages serve the following purpose: 504 Router Solicitation: When an interface becomes enabled, hosts may 505 send out Router Solicitations that request routers to 506 generate Router Advertisements immediately rather than at 507 their next scheduled time. 509 Router Advertisement: Routers advertise their presence together with 510 various link and Internet parameters either periodically, 511 or in response to a Router Solicitation message. Router 512 Advertisements contain prefixes that are used for on-link 513 determination and/or address configuration, a suggested 514 hop limit value, etc. 516 Neighbor Solicitation: Sent by a node to determine the link-layer 517 address of a neighbor, or to verify that a neighbor is 518 still reachable via a cached link-layer address. 519 Neighbor Solicitations are also used for Duplicate 520 Address Detection. 522 Neighbor Advertisement: A response to a Neighbor Solicitation 523 message. A node may also send unsolicited Neighbor 524 Advertisements to announce a link-layer address change. 526 Redirect: Used by routers to inform hosts of a better first hop for 527 a destination. 529 On multicast-capable links, each router periodically multicasts a Router 530 Advertisement packet announcing its availability. A host receives 531 Router Advertisements from all routers, building a list of default 532 routers. Routers generate Router Advertisements frequently enough that 533 hosts will learn of their presence within a few minutes, but not 534 frequently enough to rely on an absence of advertisements to detect 535 router failure; a separate Neighbor Unreachability Detection algorithm 536 provides failure detection. 538 Router Advertisements contain a list of prefixes used for on-link 539 determination and/or autonomous address configuration; flags associated 540 with the prefixes specify the intended uses of a particular prefix. 541 Hosts use the advertised on-link prefixes to build and maintain a list 542 that is used in deciding when a packet's destination is on-link or 543 beyond a router. Note that a destination can be on-link even though it 544 is not covered by any advertised on-link prefix. In such cases a router 545 can send a Redirect informing the sender that the destination is a 546 neighbor. 548 Router Advertisements (and per-prefix flags) allow routers to inform 549 hosts how to perform Address Autoconfiguration. For example, routers 550 can specify whether hosts should use stateful (DHCPv6) and/or autonomous 551 (stateless) address configuration. The exact semantics and usage of the 552 address configuration-related information is specified in [ADDRCONF]. 554 Router Advertisement messages also contain Internet parameters such as 555 the hop limit that hosts should use in outgoing packets and, optionally, 556 link parameters such as the link MTU. This facilitates centralized 557 administration of critical parameters that can be set on routers and 558 automatically propagated to all attached hosts. 560 Nodes accomplish address resolution by multicasting a Neighbor 561 Solicitation that asks the target node to return its link-layer address. 562 Neighbor Solicitation messages are multicast to the solicited-node 563 multicast address of the target address. The target returns its link- 564 layer address in a unicast Neighbor Advertisement message. A single 565 request-response pair of packets is sufficient for both the initiator 566 and the target to resolve each other's link-layer addresses; the 567 initiator includes its link-layer address in the Neighbor Solicitation. 569 Neighbor Solicitation messages can also be used to determine if more 570 than one node has been assigned the same unicast address. The use of 571 Neighbor Solicitation messages for Duplicate Address Detection is 572 specified in [ADDRCONF]. 574 Neighbor Unreachability Detection detects the failure of a neighbor or 575 the failure of the forward path to the neighbor. Doing so requires 576 positive confirmation that packets sent to a neighbor are actually 577 reaching that neighbor and being processed properly by its IP layer. 578 Neighbor Unreachability Detection uses confirmation from two sources. 579 When possible, upper-layer protocols provide a positive confirmation 580 that a connection is making "forward progress", that is, previously sent 581 data is known to have been delivered correctly (e.g., new 582 acknowledgments were received recently). When positive confirmation is 583 not forthcoming through such "hints", a node sends unicast Neighbor 584 Solicitation messages that solicit Neighbor Advertisements as 585 reachability confirmation from the next hop. To reduce unnecessary 586 network traffic, probe messages are only sent to neighbors to which the 587 node is actively sending packets. 589 In addition to addressing the above general problems, Neighbor Discovery 590 also handles the following situations: 592 Link-layer address change - A node that knows its link-layer 593 address has changed can multicast a few (unsolicited) Neighbor 594 Advertisement packets to all nodes to quickly update cached 595 link-layer addresses that have become invalid. Note that the 596 sending of unsolicited advertisements is a performance 597 enhancement only (e.g., unreliable). The Neighbor 598 Unreachability Detection algorithm ensures that all nodes will 599 reliably discover the new address, though the delay may be 600 somewhat longer. 602 Inbound load balancing - Nodes with replicated interfaces may want 603 to load balance the reception of incoming packets across 604 multiple network interfaces on the same link. Such nodes have 605 multiple link-layer addresses assigned to the same interface. 606 For example, a single network driver could represent multiple 607 network interface cards as a single logical interface having 608 multiple link-layer addresses. Load balancing is handled by 609 allowing routers to omit the source link-layer address from 610 Router Advertisement packets, thereby forcing neighbors to use 611 Neighbor Solicitation messages to learn link-layer addresses 612 of routers. Returned Neighbor Advertisement messages can then 613 contain link-layer addresses that differ depending on who 614 issued the solicitation. 616 Anycast addresses - Anycast addresses identify one of a set of 617 nodes providing an equivalent service, and multiple nodes on 618 the same link may be configured to recognize the same Anycast 619 address. Neighbor Discovery handles anycasts by having nodes 620 expect to receive multiple Neighbor Advertisements for the 621 same target. All advertisements for anycast addresses are 622 tagged as being non-Override advertisements. This invokes 623 specific rules to determine which of potentially multiple 624 advertisements should be used. 626 Proxy advertisements - A router willing to accept packets on behalf 627 of a target address that is unable to respond to Neighbor 628 Solicitations can issue non-Override Neighbor Advertisements. 629 There is currently no specified use of proxy, but proxy 630 advertising could potentially be used to handle cases like 631 mobile nodes that have moved off-link. However, it is not 632 intended as a general mechanism to handle nodes that, e.g., do 633 not implement this protocol. 635 3.1. Comparison with IPv4 637 The IPv6 Neighbor Discovery protocol corresponds to a combination of the 638 IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP 639 Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol 640 or mechanism for Neighbor Unreachability Detection, although Hosts 641 Requirements [HR-CL] does specify some possible algorithms for Dead 642 Gateway Detection (a subset of the problems Neighbor Unreachability 643 Detection tackles). 645 The Neighbor Discovery protocol provides a multitude of improvements 646 over the IPv4 set of protocols: 648 Router Discovery is part of the base protocol set; there is no need 649 for hosts to "snoop" the routing protocols. 651 Router advertisements carry link-layer addresses; no additional 652 packet exchange is needed to resolve the router's link-layer 653 address. 655 Router advertisements carry prefixes for a link; there is no need 656 to have a separate mechanism to configure the "netmask". 658 Router advertisements enable Address Autoconfiguration. 660 Routers can advertise an MTU for hosts to use on the link, ensuring 661 that all nodes use the same MTU value on links lacking a well- 662 defined MTU. 664 Address resolution multicasts are "spread" over 4 billion (2^32) 665 multicast addresses greatly reducing address resolution related 666 interrupts on nodes other than the target. Moreover, non-IPv6 667 machines should not be interrupted at all. 669 Redirects contain the link-layer address of the new first hop; 670 separate address resolution is not needed upon receiving a 671 redirect. 673 Multiple prefixes can be associated with the same link. By 674 default, hosts learn all on-link prefixes from Router 675 Advertisements. However, routers may be configured to omit some or 676 all prefixes from Router Advertisements. In such cases hosts 677 assume that destinations are off-link and send traffic to routers. 678 A router can then issue redirects as appropriate. 680 Unlike IPv4, the recipient of an IPv6 redirect assumes that the new 681 next-hop is on-link. In IPv4, a host ignores redirects specifying 682 a next-hop that is not on-link according to the link's network 683 mask. The IPv6 redirect mechanism is analogous to the XRedirect 684 facility specified in [SH-MEDIA]. It is expected to be useful on 685 non-broadcast and shared media links in which it is undesirable or 686 not possible for nodes to know all prefixes for on-link 687 destinations. 689 Neighbor Unreachability Detection is part of the base significantly 690 improving the robustness of packet delivery in the presence of 691 failing routers, partially failing or partitioned links and nodes 692 that change their link-layer addresses. For instance, mobile nodes 693 can move off-link without losing any connectivity due to stale ARP 694 caches. 696 Unlike ARP, Neighbor Discovery detects half-link failures (using 697 Neighbor Unreachability Detection) and avoids sending traffic to 698 neighbors with which two-way connectivity is absent. 700 Unlike in IPv4 Router Discovery the Router Advertisement messages 701 do not contain a preference field. The preference field is not 702 needed to handle routers of different "stability"; the Neighbor 703 Unreachability Detection will detect dead routers and switch to a 704 working one. 706 The use of link-local addresses to uniquely identify routers (for 707 Router Advertisement and Redirect messages) makes it possible for 708 hosts to maintain the router associations in the event of the site 709 renumbering to use new global prefixes. 711 Using the Hop Limit equal to 255 trick Neighbor Discovery is immune 712 to off-link senders that accidentally of intentionally send ND 713 messages. In IPv4 off-link senders can send both ICMP Redirects 714 and Router Advertisement messages. 716 Placing address resolution at the ICMP layer makes the protocol 717 more media-independent than ARP and makes it possible to use 718 standard IP authentication and security mechanisms as appropriate 719 [IPv6-AUTH, IPv6-ESP]. 721 3.2. Supported Link Types 723 Neighbor Discovery supports links with different properties. In the 724 presence of certain properties only a subset of the ND protocol is 725 available: 727 point-to-point - Neighbor Discovery handles such links just like 728 multicast links. (Multicast can be trivially 729 provided on point to point links, and interfaces can 730 be assigned link-local addresses.) 732 multicast - All aspects of Neighbor Discovery are available. 734 non-broadcast multiple access (NBMA) 735 - The only Neighbor Discovery mechanisms available on 736 these links are Redirect handling and Neighbor 737 Unreachability Detection. 739 If hosts support manual configuration of a list of 740 default routers, the hosts can dynamically acquire 741 the link-layer addresses for their neighbors from 742 Redirect messages. 744 shared media - The Redirect message is modeled after the XRedirect 745 message in [SH-MEDIA] in order to simplify use of 746 the protocol on shared media links. 748 This specification does not address shared media 749 issues that only relate to routers, such as: 751 - How routers exchange reachability information on 752 a shared media link. 754 - How a router determines the link-layer address of 755 a host, which it needs to send redirect messages 756 to the host. 758 - How a router determines that it is the first-hop 759 router for a received packet. 761 The protocol is extensible (through the definition 762 of new options) so that other solutions might be 763 possible in the future. 765 variable MTU - Neighbor Discovery allows routers to specify a MTU 766 for the link, which all nodes then use. All nodes 767 on a link must use the same MTU (or Maximum Receive 768 Unit) in order for multicast to work properly. 769 Otherwise when multicasting a sender, which can not 770 know which nodes will receive the packet, could not 771 determine a minimum packet size all receivers can 772 process. 774 asymmetric reachability 775 - Neighbor Discovery detects the absence of symmetric 776 reachability; a node avoids paths to a neighbor with 777 which it does not have symmetric connectivity. 779 The Neighbor Unreachability Detection will typically 780 identify such half-links and the node will refrain 781 from using them. 783 The protocol can presumably be extended in the 784 future to find viable paths in environments that 785 lack reflexive and transitive connectivity. 787 4. MESSAGE FORMATS 789 4.1. Router Solicitation Message Format 791 Hosts send Router Solicitations in order to prompt routers to generate 792 Router Advertisements quickly. 794 0 1 2 3 795 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 797 | Type | Code | Checksum | 798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 799 | Reserved | 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 | Options ... 802 +-+-+-+-+-+-+-+-+-+-+-+- 804 IP Fields: 806 Source Address 807 An IP address assigned to the sending interface. If 808 no address is assigned the unspecified address can be 809 used. 811 Destination Address 812 Typically the all-routers multicast address. 814 Hop Limit 255 816 Priority 15 818 Authentication Header 819 If a Security Association for the IP Authentication 820 Header exists between the sender and the destination 821 address, then the sender SHOULD include this header. 823 ICMP Fields: 825 Type 133 827 Code 0 829 Checksum The ICMP checksum. See [ICMPv6]. 831 Reserved This field is unused. It MUST be initialized to zero 832 by the sender and MUST be ignored by the receiver. 834 Valid Options: 836 Source link-layer address 837 The link-layer address of the sender, if known. 839 Future versions of this protocol may define new option types. 840 Receivers MUST silently ignore any options they do not recognize and 841 continue processing the message. 843 4.2. Router Advertisement Message Format 845 Routers send out Router Advertisement message periodically, or in 846 response to a Router Solicitation. 848 0 1 2 3 849 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 851 | Type | Code | Checksum | 852 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 853 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 854 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 855 | Reachable Time | 856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 | Retrans Timer | 858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 859 | Options ... 860 +-+-+-+-+-+-+-+-+-+-+-+- 862 IP Fields: 864 Source Address 865 MUST be the link-local address assigned to the 866 interface from which this message is sent. 868 Destination Address 869 Typically the Source Address of an invoking Router 870 Solicitation or the all-nodes multicast address. 872 Hop Limit 255 874 Priority 15 876 Authentication Header 877 If a Security Association for the IP Authentication 878 Header exists between the sender and the destination 879 address, then the sender SHOULD include this header. 881 ICMP Fields: 883 Type 134 885 Code 0 887 Checksum The ICMP checksum. See [ICMPv6]. 889 Cur Hop Limit 8-bit unsigned integer. The default value that should 890 be placed in the Hop Count field of the IP header for 891 outgoing IP packets. A value of zero means 892 unspecified (by this router). 894 M 1-bit "Managed address configuration" flag. When set, 895 hosts use the administered (stateful) protocol for 896 address autoconfiguration in addition to any addresses 897 autoconfigured using stateless address 898 autoconfiguration. The use of this flag is described 899 in [ADDRCONF]. 901 O 1-bit "Other stateful configuration" flag. When set, 902 hosts use the administered (stateful) protocol for 903 autoconfiguration of other (non-address) information. 904 The use of this flag is described in [ADDRCONF]. 906 Reserved A 6-bit unused field. It MUST be initialized to zero 907 by the sender and MUST be ignored by the receiver. 909 Router Lifetime 910 16-bit unsigned integer. The lifetime associated with 911 the default router in units of seconds. The maximum 912 value corresponds to 18.2 hours. A Lifetime of 0 913 indicates that the router is not a default router and 914 SHOULD NOT appear on the default router list. The 915 Router Lifetime applies only to the router's 916 usefulness as a default router; it does not apply to 917 information contained in other message fields or 918 options. Options that need time limits for their 919 information include their own lifetime fields. 921 Reachable Time 32-bit unsigned integer. The time, in milliseconds, 922 that a node assumes a neighbor is reachable after 923 having received a reachability confirmation. Used by 924 the Neighbor Unreachability Detection algorithm (see 925 Section 7.3). A value of zero means unspecified (by 926 this router). 928 Retrans Timer 32-bit unsigned integer. The time, in milliseconds, 929 between retransmitted Neighbor Solicitation messages. 930 Used by address resolution and the Neighbor 931 Unreachability Detection algorithm (see Sections 7.2 932 and 7.3). A value of zero means unspecified (by this 933 router). 935 Possible options: 937 Source link-layer address 938 The link-layer address of the interface from which the 939 Router Advertisement is sent. Only used on link 940 layers that have addresses. A router MAY omit this 941 option in order to enable inbound load sharing across 942 multiple link-layer addresses. 944 MTU SHOULD be sent on links that have a variable MTU (as 945 specified in the document that describes how to run IP 946 over the particular link type). MAY be sent on other 947 links. 949 Prefix Information 950 These options specify the prefixes that are on-link 951 and/or are used for address autoconfiguration. A 952 router SHOULD include all its on-link prefixes (except 953 the link-local prefix) so that multihomed hosts have 954 complete prefix information about on-link destinations 955 for the links to which they attach. If complete 956 information is lacking, a multihomed host may not be 957 able to chose the correct outgoing interface when 958 sending traffic to its neighbors. 960 Future versions of this protocol may define new option types. 961 Receivers MUST silently ignore any options they do not recognize and 962 continue processing the message. 964 4.3. Neighbor Solicitation Message Format 966 Nodes send Neighbor Solicitations to request the link-layer address of a 967 target node while also providing their own link-layer address to the 968 target. Neighbor Solicitations are multicast when the node needs to 969 resolve an address and unicast when the node seeks to verify the 970 reachability of a neighbor. 972 0 1 2 3 973 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 974 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 975 | Type | Code | Checksum | 976 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 977 | Reserved | 978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 979 | | 980 + + 981 | | 982 + Target Address + 983 | | 984 + + 985 | | 986 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 | Options ... 988 +-+-+-+-+-+-+-+-+-+-+-+- 990 IP Fields: 992 Source Address 993 Either an address assigned to the interface from which 994 this message is sent or (if Duplicate Address 995 Detection is in progress [ADDRCONF]) the unspecified 996 address. 998 Destination Address 999 Either the solicited-node multicast address 1000 corresponding to the target address, or the target 1001 address. 1003 Hop Limit 255 1005 Priority 15 1007 Authentication Header 1008 If a Security Association for the IP Authentication 1009 Header exists between the sender and the destination 1010 address, then the sender SHOULD include this header. 1012 ICMP Fields: 1014 Type 135 1016 Code 0 1018 Checksum The ICMP checksum. See [ICMPv6]. 1020 Reserved This field is unused. It MUST be initialized to zero 1021 by the sender and MUST be ignored by the receiver. 1023 Target Address 1024 The IP address of the target of the solicitation. It 1025 MUST NOT be a multicast address. 1027 Possible options: 1029 Source link-layer address 1030 The link-layer address for the sender. SHOULD be 1031 included on link layers that have addresses. 1033 Future versions of this protocol may define new option types. 1034 Receivers MUST silently ignore any options they do not recognize and 1035 continue processing the message. 1037 4.4. Neighbor Advertisement Message Format 1039 A node sends Neighbor Advertisements in response to Neighbor 1040 Solicitations and sends unsolicited Neighbor Advertisements in order to 1041 (unreliably) propagate new information quickly. 1043 0 1 2 3 1044 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1046 | Type | Code | Checksum | 1047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1048 |R|S|O| Reserved | 1049 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1050 | | 1051 + + 1052 | | 1053 + Target Address + 1054 | | 1055 + + 1056 | | 1057 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1058 | Options ... 1059 +-+-+-+-+-+-+-+-+-+-+-+- 1061 IP Fields: 1063 Source Address 1064 An address assigned to the interface from which the 1065 advertisement is sent. 1067 Destination Address 1068 For solicited advertisements, the Source Address of an 1069 invoking Neighbor Solicitation or, if the 1070 solicitation's Source Address is the unspecified 1071 address, the all-nodes multicast address. 1073 For unsolicited advertisements typically the all-nodes 1074 multicast address. 1076 Hop Limit 255 1078 Priority 15 1080 Authentication Header 1081 If a Security Association for the IP Authentication 1082 Header exists between the sender and the destination 1083 address, then the sender SHOULD include this header. 1085 ICMP Fields: 1087 Type 136 1089 Code 0 1091 Checksum The ICMP checksum. See [ICMPv6]. 1093 R Router flag. When set, the R-bit indicates that the 1094 sender is a router. The R-bit is used by Neighbor 1095 Unreachability Detection to detect a router that 1096 changes to a host. 1098 S Solicited flag. When set, the S-bit indicates that 1099 the advertisement was sent in response to a Neighbor 1100 Solicitation from the Destination address. The S-bit 1101 is used as a reachability confirmation for Neighbor 1102 Unreachability Detection. It MUST NOT be set in 1103 multicast advertisements or in unsolicited unicast 1104 advertisements. 1106 O Override flag. When set, the O-bit indicates that the 1107 advertisement should override an existing cache entry 1108 and update the cached link-layer address. When it is 1109 not set the advertisement will not update a cached 1110 link-layer address though it will update an existing 1111 Neighbor Cache entry for which no link-layer address 1112 is known. It SHOULD NOT be set in solicited 1113 advertisements for anycast addresses and in solicited 1114 proxy advertisements. It SHOULD be set in other 1115 solicited advertisements and in unsolicited 1116 advertisements. 1118 Reserved 29-bit unused field. It MUST be initialized to zero 1119 by the sender and MUST be ignored by the receiver. 1121 Target Address 1122 For solicited advertisements, the Target Address field 1123 in the Neighbor Solicitation message that prompted 1124 this advertisement. For an unsolicited advertisement, 1125 the address whose link-layer address has changed. The 1126 Target Address MUST NOT be a multicast address. 1128 Possible options: 1130 Target link-layer address 1131 The link-layer address for the target, i.e., the 1132 sender of the advertisement. MUST be included on link 1133 layers that have addresses. 1135 Future versions of this protocol may define new option types. 1136 Receivers MUST silently ignore any options they do not recognize and 1137 continue processing the message. 1139 4.5. Redirect Message Format 1141 Routers send Redirect packets to inform a host of a better first-hop 1142 node on the path to a destination. Hosts can be redirected to a better 1143 first-hop router but can also be informed by a redirect that the 1144 destination is in fact a neighbor. The latter is accomplished by 1145 setting the ICMP Target Address equal to the ICMP Destination Address. 1147 0 1 2 3 1148 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 | Type | Code | Checksum | 1151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1152 | Reserved | 1153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1154 | | 1155 + + 1156 | | 1157 + Target Address + 1158 | | 1159 + + 1160 | | 1161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1162 | | 1163 + + 1164 | | 1165 + Destination Address + 1166 | | 1167 + + 1168 | | 1169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1170 | Options ... 1171 +-+-+-+-+-+-+-+-+-+-+-+- 1173 IP Fields: 1175 Source Address 1176 MUST be the link-local address assigned to the 1177 interface from which this message is sent. 1179 Destination Address 1180 The Source Address of the packet that triggered the 1181 redirect. 1183 Hop Limit 255 1185 Priority 15 1187 Authentication Header 1188 If a Security Association for the IP Authentication 1189 Header exists between the sender and the destination 1190 address, then the sender SHOULD include this header. 1192 ICMP Fields: 1194 Type 137 1195 Code 0 1197 Checksum The ICMP checksum. See [ICMPv6]. 1199 Reserved This field is unused. It MUST be initialized to zero 1200 by the sender and MUST be ignored by the receiver. 1202 Target Address An IP address that is a better first hop to use for 1203 the ICMP Destination Address. When the target is the 1204 actual endpoint of communication, i.e., the 1205 destination is a neighbor, the Target Address field 1206 MUST contain the same value as the ICMP Destination 1207 Address field. Otherwise the target is a better 1208 first-hop router and the Target Address MUST be the 1209 router's link-local address so that hosts can uniquely 1210 identify routers. 1212 Destination Address 1213 The IP address of the destination which is redirected 1214 to the target. 1216 Possible options: 1218 Target link-layer address 1219 The link-layer address for the target. It SHOULD be 1220 included (if known). Note that on NBMA links the 1221 sender of the invoking traffic can not use address 1222 resolution to determine the link-layer address of the 1223 target. Routers are advised not to send Redirect 1224 messages on such links unless they can supply the 1225 target link-layer address. 1227 Redirected Header 1228 As much as possible of the IP packet that triggered 1229 the sending of the Redirect without making the 1230 redirect packet exceed 576 octets. 1232 4.6. Option Formats 1234 Neighbor Discovery messages include zero or more options, some of which 1235 may appear multiple times in the same message. All options are of the 1236 form: 1238 0 1 2 3 1239 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1241 | Type | Length | ... | 1242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1243 ~ ... ~ 1244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1246 Fields: 1248 Type 8-bit identifier of the type of option. The options 1249 defined in this document are: 1251 Option Name Type 1253 Source Link-Layer Address 1 1254 Target Link-Layer Address 2 1255 Prefix Information 3 1256 Redirected Header 4 1257 MTU 5 1259 Length 8-bit unsigned integer. The length of the option in 1260 units of 8 octets. The value 0 is invalid. Nodes 1261 MUST silently discard an ND packet that contains an 1262 option with length zero. 1264 4.6.1. Source/Target Link-layer Address 1266 0 1 2 3 1267 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1269 | Type | Length | Link-Layer Address ... 1270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 Fields: 1274 Type 1275 1 for Source Link-layer Address 1276 2 for Target Link-layer Address 1278 Length The length of the option in units of 8 octets. For 1279 example, the length for IEEE 802 addresses is 1 1280 [IPv6-ETHER]. 1282 Link-Layer Address 1283 The variable length link-layer address. 1285 The content and format of this field is expected to be 1286 specified in specific documents that describe how IPv6 1287 operates over different link layers. For instance, 1288 [IPv6-ETHER]. 1290 Description 1291 The Source Link-Layer Address option contains the 1292 link-layer address of the sender of the packet. It is 1293 used in the Neighbor Solicitation, Router 1294 Solicitation, and Router Advertisement packets. 1296 The Target Link-Layer Address option contains the 1297 link-layer address of the target. It is used in 1298 Neighbor Advertisement and Redirect packets. 1300 These options MUST be silently ignored for other 1301 Neighbor Discovery messages. 1303 4.6.2. Prefix Information 1305 0 1 2 3 1306 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Type | Length | Prefix Length |L|A| Reserved1 | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Valid Lifetime | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | Preferred Lifetime | 1313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1314 | Reserved2 | 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1316 | | 1317 + + 1318 | | 1319 + Prefix + 1320 | | 1321 + + 1322 | | 1323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1325 Fields: 1327 Type 3 1328 Length 4 1330 Prefix Length 8-bit unsigned integer. The number of leading bits in 1331 the Prefix that are valid. The value ranges from 0 to 1332 128. 1334 L 1-bit on-link flag. When set, indicates that this 1335 prefix can be used for on-link determination. When 1336 not set the advertisement makes no statement about 1337 on-link or off-link properties of the prefix. For 1338 instance, the prefix might be used for address 1339 configuration with some of the addresses belonging to 1340 the prefix being on-link and others being off-link. 1342 A 1-bit autonomous address-configuration flag. When set 1343 indicates that this prefix can be used for autonomous 1344 address configuration as specified in [ADDRCONF]. 1346 Reserved1 6-bit unused field. It MUST be initialized to zero by 1347 the sender and MUST be ignored by the receiver. 1349 Valid Lifetime 1350 32-bit unsigned integer. The length of time in 1351 seconds (relative to the time the packet is sent) that 1352 the prefix is valid for the purpose of on-link 1353 determination. A value of all one bits (0xffffffff) 1354 represents infinity. The Valid Lifetime is also used 1355 by [ADDRCONF]. 1357 Preferred Lifetime 1358 32-bit unsigned integer. The length of time in 1359 seconds (relative to the time the packet is sent) that 1360 addresses generated from the prefix via stateless 1361 address autoconfiguration remain preferred [ADDRCONF]. 1362 A value of all one bits (0xffffffff) represents 1363 infinity. See [ADDRCONF]. 1365 Reserved2 This field is unused. It MUST be initialized to zero 1366 by the sender and MUST be ignored by the receiver. 1368 Prefix An IP address or a prefix of an IP address. The 1369 Prefix Length field contains the number of valid 1370 leading bits in the prefix. The bits in the prefix 1371 after the prefix length are reserved and MUST be 1372 initialized to zero by the sender and ignored by the 1373 receiver. A router SHOULD NOT send a prefix option 1374 for the link-local prefix and a host SHOULD ignore 1375 such a prefix option. 1377 Description 1378 The Prefix Information option provide hosts with on- 1379 link prefixes and prefixes for Address 1380 Autoconfiguration. 1382 The Prefix Information option appears in Router 1383 Advertisement packets and MUST be silently ignored for 1384 other messages. 1386 4.6.3. Redirected Header 1388 0 1 2 3 1389 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1391 | Type | Length | Reserved | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1393 | Reserved | 1394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1395 | | 1396 ~ IP header + data ~ 1397 | | 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 Fields: 1402 Type 4 1404 Length The length of the option in units of 8 octets. 1406 Reserved These fields are unused. They MUST be initialized to 1407 zero by the sender and MUST be ignored by the 1408 receiver. 1410 IP header + data 1411 The original packet truncated to ensure that the size 1412 of the redirect message does not exceed 576 octets. 1414 Description 1415 The Redirected Header option is used in Redirect 1416 messages and contains all or part of the packet that 1417 is being redirected. 1419 This option MUST be silently ignored for other 1420 Neighbor Discovery messages. 1422 4.6.4. MTU 1424 0 1 2 3 1425 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1427 | Type | Length | Reserved | 1428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1429 | MTU | 1430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1432 Fields: 1434 Type 5 1436 Length 1 1438 Reserved This field is unused. It MUST be initialized to zero 1439 by the sender and MUST be ignored by the receiver. 1441 MTU 32-bit unsigned integer. The recommended MTU for the 1442 link. 1444 Description 1445 The MTU option is used in Router Advertisement 1446 messages to insure that all nodes on a link use the 1447 same MTU value in those cases where the link MTU is 1448 not well known. 1450 This option MUST be silently ignored for other 1451 Neighbor Discovery messages. 1453 In configurations in which heterogeneous technologies 1454 are bridged together, the maximum supported MTU may 1455 differ from one segment to another. If the bridges do 1456 not generate ICMP Packet Too Big messages, 1457 communicating nodes will be unable to use Path MTU to 1458 dynamically determine the appropriate MTU on a per- 1459 neighbor basis. In such cases, routers use the MTU 1460 option to specify an MTU value supported by all 1461 segments. 1463 5. CONCEPTUAL MODEL OF A HOST 1465 This section describes a conceptual model of one possible data structure 1466 organization that hosts (and to some extent routers) will maintain in 1467 interacting with neighboring nodes. The described organization is 1468 provided to facilitate the explanation of how the Neighbor Discovery 1469 protocol should behave. This document does not mandate that 1470 implementations adhere to this model as long as their external behavior 1471 is consistent with that described in this document. 1473 This model is only concerned with the aspects of host behavior directly 1474 related to Neighbor Discovery. In particular, it does not concern 1475 itself with such issues as source address selection or the selecting of 1476 an outgoing interface on a multihomed host. 1478 5.1. Conceptual Data Structures 1480 Hosts will need to maintain the following pieces of information for each 1481 interface: 1483 Neighbor Cache 1484 - A set of entries about individual neighbors to which 1485 traffic has been sent recently. Entries are keyed on 1486 the neighbor's on-link unicast IP address and contain 1487 such information as its link-layer address, a flag 1488 indicating whether the neighbor is a router or a host 1489 (called IsRouter in this document), a pointer to any 1490 queued packets waiting for address resolution to 1491 complete, etc. 1493 A Neighbor Cache entry also contains information used 1494 by the Neighbor Unreachability Detection algorithm, 1495 including the reachability state, the number of 1496 unanswered probes, and the time the next Neighbor 1497 Unreachability Detection event is scheduled to take 1498 place. 1500 Destination Cache 1501 - A set of entries about destinations to which traffic 1502 has been sent recently. The Destination Cache 1503 includes both on-link and off-link destinations and 1504 provides a level of indirection into the Neighbor 1505 Cache; the Destination Cache maps a destination IP 1506 address to the IP address of the next-hop neighbor. 1507 This cache is updated with information learned from 1508 Redirect messages. Implementations may find it 1509 convenient to store additional information not 1510 directly related to Neighbor Discovery in Destination 1511 Cache entries, such as the Path MTU (PMTU) and round 1512 trip timers maintained by transport protocols. 1514 Prefix List - A list of the prefixes that define a set of addresses 1515 that are on-link. Prefix List entries are created 1516 from information received in Router Advertisements. 1517 Each entry has an associated invalidation timer value 1518 (extracted from the advertisement) used to expire 1519 prefixes when they become invalid. A special 1520 "infinity" timer value specifies that a prefix remains 1521 valid forever, unless a new (finite) value is received 1522 in a subsequent advertisement. 1524 The link-local prefix is considered to be on the 1525 prefix list with an infinite invalidation timer 1526 regardless of whether routers are advertising a prefix 1527 for it. Received Router Advertisements SHOULD NOT 1528 modify the invalidation timer for the link-local 1529 prefix. 1531 Default Router List 1532 - A list of routers to which packets may be sent. 1533 Router list entries point to entries in the Neighbor 1534 Cache; the algorithm for selecting a default router 1535 favors routers known to be reachable over those whose 1536 reachability is suspect. Each entry also has an 1537 associated invalidation timer value (extracted from 1538 Router Advertisements) used to delete entries that are 1539 no longer advertised. 1541 Note that the above conceptual data structures can be implemented using 1542 a variety of techniques. One possible implementation is to use a single 1543 longest-match routing table for all of the above data structures. 1544 Regardless of the specific implementation, it is critical that the 1545 Neighbor Cache entry for a router is shared by all Destination Cache 1546 entries using that router in order to prevent redundant Neighbor 1547 Unreachability Detection probes. 1549 Note also that other protocols (e.g. IPv6 Mobility) might add additional 1550 conceptual data structures. An implementation is at liberty to 1551 implement such data structures in any way it pleases. For example, an 1552 implementation could merge all conceptual data structures into a single 1553 routing table. 1555 The Neighbor Cache contains information maintained by the Neighbor 1556 Unreachability Detection algorithm. A key piece of information is a 1557 neighbor's reachability state, which is one of five possible values. 1559 The following definitions are informal; precise definitions can be found 1560 in Section 7.3.2. 1562 INCOMPLETE Address resolution is in progress and the link-layer 1563 address of the neighbor has not yet been determined. 1565 REACHABLE Roughly speaking, the neighbor is known to have been 1566 reachable recently (within tens of seconds ago). 1568 STALE The neighbor is no longer known to be reachable but until 1569 traffic is sent to the neighbor, no attempt should be 1570 made to verify its reachability. 1572 DELAY The neighbor is no longer known to be reachable, and 1573 traffic has recently be sent to the neighbor. Rather 1574 than probe the neighbor immediately, however, delay 1575 sending probes for a short while in order to give upper 1576 layer protocols a chance to provide reachability 1577 confirmation. 1579 PROBE The neighbor is no longer known to be reachable, and 1580 unicast Neighbor Solicitation probes are being sent to 1581 verify reachability. 1583 5.2. Conceptual Sending Algorithm 1585 When sending a packet to a destination, a node uses a combination of the 1586 Destination Cache, the Prefix List, and the Default Router List to 1587 determine the IP address of the appropriate next hop, an operation known 1588 as "next-hop determination". Once the IP address of the next hop is 1589 known, the Neighbor Cache is consulted for link-layer information about 1590 that neighbor. 1592 Next-hop determination for a given unicast destination operates as 1593 follows. The sender examines the Prefix List to determine whether the 1594 packet's destination is on- or off-link. If the destination is on-link, 1595 the next-hop address is the same as the packet's destination address. 1596 Otherwise, the sender selects a router from the Default Router List 1597 (following the rules described in Section 6.3.6). If the Default Router 1598 List is empty, the sender assumes that the destination is on-link. 1600 For efficiency reasons, next-hop determination is not performed on every 1601 packet that is sent. Instead, the results of next-hop determination 1602 computations are saved in the Destination Cache (which also contains 1603 updates learned from Redirect messages). When the sending node has a 1604 packet to send, it first examines the Destination Cache. If no entry 1605 exists for the destination, next-hop determination is invoked to create 1606 a Destination Cache entry. 1608 Once the IP address of the next-hop node is known, the sender examines 1609 the Neighbor Cache for link-layer information about that neighbor. If 1610 no entry exists, the sender creates one, sets its state to INCOMPLETE, 1611 initiates Address Resolution, and then queues the data packet pending 1612 completion of address resolution. For multicast-capable interfaces 1613 Address Resolution consists of sending a Neighbor Solicitation message 1614 and waiting for a Neighbor Advertisement. When a Neighbor Advertisement 1615 response is received, the link-layer addresses is entered in the 1616 Neighbor Cache entry and the queued packet is transmitted. The address 1617 resolution mechanism is described in detail in Section 7.2. 1619 For multicast packets the next-hop is always the (multicast) destination 1620 address and is considered to be on-link. The procedure for determining 1621 the link-layer address corresponding to a given IP multicast address can 1622 be found in a separate document that covers operating IP over a 1623 particular link type (e.g., [IPv6-ETHER]). 1625 Each time a Neighbor Cache entry is accessed while transmitting a 1626 unicast packet, the sender checks Neighbor Unreachability Detection 1627 related information according to the Neighbor Unreachability Detection 1628 algorithm (Section 7.3). This unreachability check might result in the 1629 sender transmitting a unicast Neighbor Solicitation to verify that the 1630 neighbor is still reachable. 1632 Next-hop determination is done the first time traffic is sent to a 1633 destination. As long as subsequent communication to that destination 1634 proceeds successfully, the Destination Cache entry continues to be used. 1635 If at some point communication ceases to proceed, as determined by the 1636 Neighbor Unreachability Detection algorithm, next-hop determination may 1637 need to be performed again. For example, traffic through a failed 1638 router should be switched to a working router. Likewise, it may be 1639 possible to reroute traffic destined for a mobile node to a "mobility 1640 agent". 1642 Note that when a node redoes next-hop determination there is no need to 1643 discard the complete Destination Cache entry. In fact, it is generally 1644 beneficial to retain such cached information as the PMTU and round trip 1645 timer values that may also be kept in the Destination Cache entry. 1647 Routers and multihomed hosts have multiple interfaces. The remainder of 1648 this document assumes that all sent and received Neighbor Discovery 1649 messages refer to the interface of appropriate context. For example, 1650 when responding to a Router Solicitation, the corresponding Router 1651 Advertisement is sent out the interface on which the solicitation was 1652 received. 1654 5.3. Garbage Collection and Timeout Requirements 1656 The conceptual data structures described above use different mechanisms 1657 for discarding potentially stale or unused information. 1659 From the perspective of correctness there is no need to periodically 1660 purge Destination and Neighbor Cache entries. Although stale 1661 information can potentially remain in the cache indefinitely, the 1662 Neighbor Unreachability Detection algorithm ensures that stale 1663 information is purged quickly if it is actually being used. 1665 To limit the storage needed for the Destination and Neighbor Caches, a 1666 node may need to garbage-collect old entries. However, care must be 1667 taken to insure that sufficient space is always present to hold the 1668 working set of active entries. A small cache may result in an excessive 1669 number of Neighbor Discovery messages if entries are discarded and 1670 rebuilt in quick succession. Any LRU-based policy that only reclaims 1671 entries that have not been used in some time (e.g., ten minutes or more) 1672 should be adequate for garbage-collecting unused entries. 1674 A node should retain entries in the Default Router List and the Prefix 1675 List until their lifetimes expire. However, a node may garbage collect 1676 entries prematurely if it is low on memory. If not all routers are kept 1677 on the Default Router list, a node should retain at least two entries in 1678 the Default Router List (and preferably more) in order to maintain 1679 robust connectivity for off-link destinations. 1681 When removing an entry from the Prefix List there is no need to purge 1682 any entries from the Destination or Neighbor Caches. Neighbor 1683 Unreachability Detection will efficiently purge any entries in these 1684 caches that have become invalid. When removing an entry from the 1685 Default Router List, however, any entries in the Destination Cache that 1686 go through that router must perform next-hop determination again to 1687 select a new default router. 1689 6. ROUTER AND PREFIX DISCOVERY 1691 This section describes router and host behavior related to the Router 1692 Discovery portion of Neighbor Discovery. Router Discovery is used to 1693 locate neighboring routers as well as learn prefixes and configuration 1694 parameters related to address autoconfiguration. 1696 Prefix Discovery is the process through which hosts learn the ranges of 1697 IP addresses that reside on-link and can be reached directly without 1698 going through a router. Routers send Router Advertisements that 1699 indicate whether the sender is willing to be a default router. Router 1700 Advertisements also contain Prefix Information options that list the set 1701 of prefixes that identify on-link IP addresses. 1703 Stateless Address Autoconfiguration must also obtain subnet prefixes as 1704 part of configuring addresses. Although the prefixes used for address 1705 autoconfiguration are logically distinct from those used for on-link 1706 determination, autoconfiguration information is piggybacked on Router 1707 Discovery messages to reduce network traffic. Indeed, the same prefixes 1708 can be advertised for on-link determination and address 1709 autoconfiguration by specifying the appropriate flags in the Prefix 1710 Information options. See [ADDRCONF] for details on how 1711 autoconfiguration information is processed. 1713 6.1. Message Validation 1715 6.1.1. Validation of Router Solicitation Messages 1717 Hosts MUST silently discard any received Router Solicitation Messages. 1719 A router MUST silently discard any received Router Solicitation messages 1720 that do not satisfy all of the following validity checks: 1722 - The IP Hop Limit field has a value of 255, i.e., the packet could 1723 not possibly have been forwarded by a router. 1725 - If the message includes an IP Authentication Header, the message 1726 authenticates correctly. 1728 - ICMP Checksum is valid. 1730 - ICMP Code is 0. 1732 - ICMP length (derived from the IP length) is 8 or more octets. 1734 - All included options have a length that is greater than zero. 1736 The contents of the Reserved field, and of any unrecognized options, 1737 MUST be ignored. Future, backward-compatible changes to the protocol 1738 may specify the contents of the Reserved field or add new options; 1739 backward-incompatible changes may use different Code values. 1741 The contents of any defined options that are not specified to be used 1742 with Router Solicitation messages MUST be ignored and the packet 1743 processed as normal. The only defined option that may appear is the 1744 Source Link-Layer Address option. 1746 A solicitation that passes the validity checks is called a "valid 1747 solicitation". 1749 6.1.2. Validation of Router Advertisement Messages 1751 A node MUST silently discard any received Router Advertisement messages 1752 that do not satisfy all of the following validity checks: 1754 - IP Source Address is a link-local address. Routers must use their 1755 link-local address as the source for Router Advertisement and 1756 Redirect messages so that hosts can uniquely identify routers. 1758 - The IP Hop Limit field has a value of 255, i.e., the packet could 1759 not possibly have been forwarded by a router. 1761 - If the message includes an IP Authentication Header, the message 1762 authenticates correctly. 1764 - ICMP Checksum is valid. 1766 - ICMP Code is 0. 1768 - ICMP length (derived from the IP length) is 16 or more octets. 1770 - All included options have a length that is greater than zero. 1772 The contents of the Reserved field, and of any unrecognized options, 1773 MUST be ignored. Future, backward-compatible changes to the protocol 1774 may specify the contents of the Reserved field or add new options; 1775 backward-incompatible changes may use different Code values. 1777 The contents of any defined options that are not specified to be used 1778 with Router Advertisement messages MUST be ignored and the packet 1779 processed as normal. The only defined options that may appear are the 1780 Source Link-Layer Address, Prefix Information and MTU options. 1782 An advertisement that passes the validity checks is called a "valid 1783 advertisement". 1785 6.2. Router Specification 1787 6.2.1. Router Configuration Variables 1789 A router MUST allow for the following conceptual variables to be 1790 configured by system management. The specific variable names are used 1791 for demonstration purposes only, and an implementation is not required 1792 to have them, so long as its external behavior is consistent with that 1793 described in this document. Default values are specified to simplify 1794 configuration in common cases. 1796 The default values for some of the variables listed below may be 1797 overridden by specific documents that describe how IPv6 operates over 1798 different link layers. This rule simplifies the configuration of 1799 Neighbor Discovery over link types with widely differing performance 1800 characteristics. 1802 For each multicast interface: 1804 AdvSendAdvertisements 1805 A flag indicating whether or not the router sends 1806 periodic Router Advertisements and responds to 1807 Router Solicitations. 1809 Default: FALSE 1811 Note that AdvSendAdvertisements MUST be false by 1812 default so that a node will not accidentally start 1813 acting as a router unless it is explicitly 1814 configured by system management to send Router 1815 Advertisements. 1817 MaxRtrAdvInterval 1818 The maximum time allowed between sending unsolicited 1819 multicast Router Advertisements from the interface, 1820 in seconds. MUST be no less than 4 seconds and no 1821 greater than 1800 seconds. 1823 Default: 600 seconds 1825 MinRtrAdvInterval 1826 The minimum time allowed between sending unsolicited 1827 multicast Router Advertisements from the interface, 1828 in seconds. MUST be no less than 3 seconds and no 1829 greater than .75 * MaxRtrAdvInterval. 1831 Default: 0.33 * MaxRtrAdvInterval 1833 AdvManagedFlag 1834 The true/false value to be placed in the "Managed 1835 address configuration" flag field in the Router 1836 Advertisement. See [ADDRCONF]. 1838 Default: FALSE 1840 AdvOtherConfigFlag 1841 The true/false value to be placed in the "Other 1842 stateful configuration" flag field in the Router 1843 Advertisement. See [ADDRCONF]. 1845 Default: FALSE 1847 AdvLinkMTU The value to be placed in MTU options sent by the 1848 router. A value of zero indicates that no MTU 1849 options are sent. 1851 Default: 0 1853 AdvReachableTime 1854 The value to be placed in the Reachable Time field 1855 in the Router Advertisement messages sent by the 1856 router. The value zero means unspecified (by this 1857 router). MUST be no greater than 3,600,000 1858 milliseconds (1 hour). 1860 Default: 0 1862 AdvRetransTimer 1863 The value to be placed in the Retrans Timer field in 1864 the Router Advertisement messages sent by the 1865 router. The value zero means unspecified (by this 1866 router). 1868 Default: 0 1870 AdvCurHopLimit 1871 The default value to be placed in the Cur Hop Limit 1872 field in the Router Advertisement messages sent by 1873 the router. The value should be set to that current 1874 diameter of the Internet. The value zero means 1875 unspecified (by this router). 1877 Default: The value specified in the most recent 1878 "Assigned Numbers" RFC [ASSIGNED]. 1880 AdvDefaultLifetime 1881 The value to be placed in the Router Lifetime field 1882 of Router Advertisements sent from the interface, in 1883 seconds. MUST be either zero or between 1884 MaxRtrAdvInterval and 9000 seconds. A value of zero 1885 indicates that the router is not to be used as a 1886 default router. 1888 Default: 3 * MaxRtrAdvInterval 1890 AdvPrefixList 1891 A list of prefixes to be placed in Prefix 1892 Information options in Router Advertisement messages 1893 sent from the interface. 1895 Default: all prefixes that the router advertises via 1896 routing protocols as being on-link for the interface 1897 from which the advertisement is sent. The link- 1898 local prefix SHOULD NOT be included in the list of 1899 advertised prefixes. 1901 Each prefix has an associated: 1903 AdvValidLifetime 1904 The value to be placed in the Valid Lifetime 1905 in the Prefix Information option, in 1906 seconds. The designated value of all 1's 1907 (0xffffffff) represents infinity. 1909 Default: infinity. 1911 AdvOnLinkFlag 1912 The value to be placed in the on-link flag 1913 ("L-bit") field in the Prefix Information 1914 option. 1916 Default: TRUE 1918 Automatic address configuration [ADDRCONF] defines 1919 additional information associated with each the 1920 prefixes: 1922 AdvPreferredLifetime 1923 The value to be placed in the Preferred 1924 Lifetime in the Prefix Information option, 1925 in seconds. The designated value of all 1's 1926 (0xffffffff) represents infinity. See 1927 [ADDRCONF]. 1929 Default: 604800 seconds (7 days) 1931 AdvAutonomousFlag 1932 The value to be placed in the Autonomous 1933 Flag field in the Prefix Information option. 1934 See [ADDRCONF]. 1936 Default: TRUE 1938 The above variables contain information that is placed in outgoing 1939 Router Advertisement messages. Hosts use the received information to 1940 initialize a set of analogous variables that control their external 1941 behavior (see Section 6.3.2). Some of these host variables (e.g., 1942 CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes 1943 including routers. In practice, these variables may not actually be 1944 present on routers, since their contents can be derived from the 1945 variables described above. However, external router behavior MUST be 1946 the same as host behavior with respect to these variables. In 1947 particular, this includes the occasional randomization of the 1948 ReachableTime value as described in Section 6.3.2. 1950 Protocol constants are defined in Section 10. 1952 6.2.2. Becoming An Advertising Interface 1954 The term "advertising interface" refers to any functioning and enabled 1955 multicast interface that has at least one unicast IP address assigned to 1956 it and whose corresponding AdvSendAdvertisements flag is TRUE. A router 1957 MUST NOT send Router Advertisements out any interface that is not an 1958 advertising interface. 1960 An interface may become an advertising interface at times other than 1961 system startup. For example: 1963 - changing the AdvSendAdvertisements flag on an enabled interface 1964 from FALSE to TRUE, or 1966 - administratively enabling the interface, if it had been 1967 administratively disabled, and its AdvSendAdvertisements flag is 1968 TRUE, or 1970 - enabling IP forwarding capability (i.e., changing the system from 1971 being a host to being a router), when the interface's 1972 AdvSendAdvertisements flag is TRUE. 1974 A router MUST join the all-routers multicast address on an advertising 1975 interface. Routers respond to Router Solicitations sent to the all- 1976 routers address and verify the consistency of Router Advertisements sent 1977 by neighboring routers. 1979 6.2.3. Router Advertisement Message Content 1981 A router sends periodic as well as solicited Router Advertisements out 1982 its advertising interfaces. Outgoing Router Advertisements are filled 1983 with the following values consistent with the message format given in 1984 Section 4.2: 1986 - In the Router Lifetime field: the interface's configured 1987 AdvDefaultLifetime. 1989 - In the M and O flags: the interface's configured AdvManagedFlag and 1990 AdvOtherConfigFlag, respectively. See [ADDRCONF]. 1992 - In the Cur Hop Limit field: the interface's configured CurHopLimit. 1994 - In the Reachable Time field: the interface's configured 1995 AdvReachableTime. 1997 - In the Retrans Timer field: the interface's configured 1998 AdvRetransTimer. 2000 - In the options: 2002 o Source Link-Layer Address option: link-layer address of the 2003 sending interface. This option MAY be omitted to facilitate 2004 in-bound load balancing over replicated interfaces. 2006 o MTU option: the interface's configured AdvLinkMTU value if the 2007 value is non-zero. If AdvLinkMTU is zero the MTU option is 2008 not sent. 2010 o Prefix Information options: one Prefix Information option for 2011 each prefix listed in AdvPrefixList with the option fields set 2012 from the information in the AdvPrefixList entry as follows: 2014 - In the "on-link" flag: the entry's AdvOnLinkFlag. 2016 - In the Valid Lifetime field: the entry's 2017 AdvValidLifetime. 2019 - In the "Autonomous address configuration" flag: the 2020 entry's AdvAutonomousFlag. 2022 - In the Preferred Lifetime field: the entry's 2023 AdvPreferredLifetime. 2025 A router might want to send Router Advertisements without advertising 2026 itself as a default router. For instance, a router might advertise 2027 prefixes for address autoconfiguration while not wishing to forward 2028 packets. Such a router sets the Router Lifetime field in outgoing 2029 advertisements to zero. 2031 A router MAY choose not to include some or all options when sending 2032 unsolicited Router Advertisements. For example, if prefix lifetimes are 2033 much longer than AdvDefaultLifetime, including them every few 2034 advertisements may be sufficient. However, when responding to a Router 2035 Solicitation or while sending the first few initial unsolicited 2036 advertisements, a router SHOULD include all options so that all 2037 information (e.g., prefixes) is propagated quickly during system 2038 initialization. 2040 If including all options causes the size of an advertisement to exceed 2041 the link MTU, multiple advertisements can be sent, each containing a 2042 subset of the options. 2044 6.2.4. Sending Unsolicited Router Advertisements 2046 A host MUST NOT send Router Advertisement messages at any time. 2048 Unsolicited Router Advertisements are not strictly periodic: the 2049 interval between subsequent transmissions is randomized to reduce the 2050 probability of synchronization with the advertisements from other 2051 routers on the same link [SYNC]. Each advertising interface has its own 2052 timer. Whenever a multicast advertisement is sent from an interface, 2053 the timer is reset to a uniformly-distributed random value between the 2054 interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; 2055 expiration of the timer causes the next advertisement to be sent and a 2056 new random value to be chosen. 2058 For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) 2059 sent from an interface when it becomes an advertising interface, if the 2060 randomly chosen interval is greater than 2061 MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to 2062 MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for 2063 the initial advertisements increases the likelihood of a router being 2064 discovered quickly when it first becomes available, in the presence of 2065 possible packet loss. 2067 The information contained in Router Advertisements may change through 2068 actions of system management. For instance, the lifetime of advertised 2069 prefixes may change, new prefixes could be added, a router could cease 2070 to be a router (i.e., switch from being a router to being a host), etc. 2071 In such cases, the router MAY transmit up to 2072 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the 2073 same rules as when an interface becomes an advertising interface. 2075 6.2.5. Ceasing To Be An Advertising Interface 2077 An interface may cease to be an advertising interface, through actions 2078 of system management such as: 2080 - changing the AdvSendAdvertisements flag of an enabled interface 2081 from TRUE to FALSE, or 2083 - administratively disabling the interface, or 2085 - shutting down the system. 2087 In such cases the router SHOULD transmit one or more (but not more than 2088 MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on 2089 the interface with a Router Lifetime field of zero. In the case of a 2090 router becoming a host, the system SHOULD also depart from the all- 2091 routers IP multicast group on all interfaces on which the router 2092 supports IP multicast (whether or not they had been advertising 2093 interfaces). In addition, the host MUST insure that subsequent Neighbor 2094 Advertisement messages sent from the interface have the Router flag set 2095 to zero. 2097 Note that system management may disable a router's IP forwarding 2098 capability (i.e., changing the system from being a router to being a 2099 host), a step that does not necessarily imply that the router's 2100 interfaces stop being advertising interfaces. In such cases, subsequent 2101 Router Advertisements MUST set the Router Lifetime field to zero. 2103 6.2.6. Processing Router Solicitations 2105 A host MUST silently discard any received Router Solicitation messages. 2107 In addition to sending periodic, unsolicited advertisements, a router 2108 sends advertisements in response to valid solicitations received on an 2109 advertising interface. A router MAY choose to unicast the response 2110 directly to the soliciting host's address (if the solicitation's source 2111 address is not the unspecified address), but the usual case is to 2112 multicast the response to the all-nodes group. In the latter case, the 2113 interface's interval timer is reset to a new random value, as if an 2114 unsolicited advertisement had just been sent (see Section 6.2.4). 2116 In all cases, Router Advertisements sent in response to a Router 2117 Solicitation MUST be delayed by a random time between 0 and 2118 MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in 2119 response to multiple solicitations, the delay is relative to the first 2120 solicitation.) In addition, consecutive Router Advertisements sent to 2121 the all-nodes multicast address MUST be rate limited to no more than one 2122 advertisement every MIN_DELAY_BETWEEN_RAS seconds. 2124 A router might process Router Solicitations as follows: 2126 - Upon receipt of a Router Solicitation, compute a random delay within 2127 the range 0 through MAX_RA_DELAY_TIME. If the computed value 2128 corresponds to a time later than the time the next multicast Router 2129 Advertisement is scheduled to be sent, ignore the random delay and 2130 send the advertisement at the already-scheduled time. 2132 - If the router sent a multicast Router Advertisement (solicited or 2133 unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, schedule 2134 the advertisement to be sent at a time corresponding to 2135 MIN_DELAY_BETWEEN_RAS plus the random value after the previous 2136 advertisement was sent. This ensures that the multicast Router 2137 Advertisements are rate limited. 2139 - Otherwise, schedule the sending of a Router Advertisement at the time 2140 given by the random value. 2142 Note that a router is permitted to send multicast Router Advertisements 2143 more frequently than indicated by the MinRtrAdvInterval configuration 2144 variable so long as the more frequent advertisements are responses to 2145 Router Solicitations. In all cases, however, unsolicited multicast 2146 advertisements MUST NOT be sent more frequently than indicated by 2147 MinRtrAdvInterval. 2149 When a router receives a Router Solicitation and the Source Address is 2150 not the unspecified address, it records that the source of the packet is 2151 a neighbor by creating or updating the Neighbor Cache entry. If the 2152 solicitation contains a Source Link-Layer Address option, and the router 2153 has a Neighbor Cache entry for the neighbor, the link-layer address 2154 SHOULD be updated in the Neighbor Cache. If a Neighbor Cache entry is 2155 created for the source its reachability state MUST be set to STALE as 2156 specified in Section 7.3.3. If a cache entry already exists and is 2157 updated with a different link-layer address the reachability state MUST 2158 also be set to STALE. In either case the entry's IsRouter flag SHOULD 2159 be set to false. 2161 If the Source Address is the unspecified address the router MUST NOT 2162 create or update the Neighbor Cache entry. 2164 6.2.7. Router Advertisement Consistency 2166 Routers SHOULD inspect valid Router Advertisements sent by other routers 2167 and verify that the routers are advertising consistent information on a 2168 link. Detected inconsistencies indicate that one or more routers might 2169 be misconfigured and SHOULD be logged to system or network management. 2170 The minimum set of information to check includes: 2172 - Cur Hop Limit values (except for the unspecified value of zero). 2174 - Values of the M or O flags. 2176 - Reachable Time values (except for the unspecified value of zero). 2178 - Retrans Timer values (except for the unspecified value of zero). 2180 - Values in the MTU options. 2182 - Preferred and Valid Lifetimes for the same prefix. 2184 Note that it is not an error for different routers to advertise 2185 different sets of prefixes. Also, some routers might leave some fields 2186 as unspecified, i.e., with the value zero, while other routers specify 2187 values. The logging of errors SHOULD be restricted to conflicting 2188 information that causes hosts to switch from one value to another with 2189 each received advertisement. 2191 Any other action on reception of Router Advertisement messages by a 2192 router is beyond the scope of this document. 2194 6.2.8. Link-local Address Change 2196 The link-local address on a router SHOULD change rarely, if ever. Nodes 2197 receiving Neighbor Discovery messages use the source address to identify 2198 the sender. If multiple packets from the same router contain different 2199 source addresses, nodes will assume they come from different routers, 2200 leading to undesirable behavior. For example, a node will ignore 2201 Redirect messages that are believed to have been sent by a router other 2202 than the current first-hop router. Thus the source address used in 2203 Router Advertisements sent by a particular router must be identical to 2204 the target address in a Redirect message when redirecting to that 2205 router. 2207 Using the link-local address to uniquely identify routers on the link 2208 has the benefit that the address a router is known by should not change 2209 when a site renumbers. 2211 If a router changes the link-local address for one of its interfaces, it 2212 SHOULD inform hosts of this change. The router SHOULD multicast a few 2213 Router Advertisements from the old link-local address with the Router 2214 Lifetime field set to zero and also multicast a few Router 2215 Advertisements from the new link-local address. The overall effect 2216 should be the same as if one interface ceases being an advertising 2217 interface, and a different one starts being an advertising interface. 2219 6.3. Host Specification 2221 6.3.1. Host Configuration Variables 2223 None. 2225 6.3.2. Host Variables 2227 A host maintains certain Neighbor Discovery related variables in 2228 addition to the data structures defined in Section 5.1. The specific 2229 variable names are used for demonstration purposes only, and an 2230 implementation is not required to have them, so long as its external 2231 behavior is consistent with that described in this document. 2233 These variables have default values that are overridden by information 2234 received in Router Advertisement messages. The default values are used 2235 when there is no router on the link or when all received Router 2236 Advertisements have left a particular value unspecified. 2238 The default values in this specification may be overridden by specific 2239 documents that describe how IP operates over different link layers. 2240 This rule allows Neighbor Discovery to operate over links with widely 2241 varying performance characteristics. 2243 For each interface: 2245 LinkMTU The MTU of the link. 2247 Default: The valued defined in the specific document 2248 that describes how IPv6 operates over the particular 2249 link layer (e.g., [IPv6-ETHER]). 2251 CurHopLimit The default hop limit to be used when sending 2252 (unicast) IP packets. 2254 Default: The value specified in the most recent 2255 "Assigned Numbers" RFC [ASSIGNED]. 2257 BaseReachableTime 2258 A base value used for computing the random 2259 ReachableTime value. 2261 Default: REACHABLE_TIME milliseconds. 2263 ReachableTime The time a neighbor is considered reachable after 2264 receiving a reachability confirmation. 2266 This value should be a uniformly-distributed random 2267 value between MIN_RANDOM_FACTOR and 2268 MAX_RANDOM_FACTOR times BaseReachableTime 2269 milliseconds. A new random value should be 2270 calculated when BaseReachableTime changes (due to 2271 Router Advertisements) or at least every few hours 2272 even if no Router Advertisements are received. 2274 RetransTimer The time between retransmissions of Neighbor 2275 Solicitation messages to a neighbor when resolving 2276 the address or when probing the reachability of a 2277 neighbor. 2279 Default: RETRANS_TIMER milliseconds 2281 6.3.3. Interface Initialization 2283 The host joins the all-nodes multicast address on all multicast-capable 2284 interfaces. 2286 6.3.4. Processing Received Router Advertisements 2288 When multiple routers are present, the information advertised 2289 collectively by all routers may be a superset of the information 2290 contained in a single Router Advertisement. Hosts accept the union of 2291 all advertised information; the receipt of a Router Advertisement MUST 2292 NOT invalidate all information received in a previous advertisement. 2293 However, when received information for a specific parameter (e.g., Link 2294 MTU) or option (e.g., Lifetime on a specific Prefix) is different than 2295 information received earlier, and the parameter/option can only have one 2296 value, the most recently-received information is considered 2297 authoritative. 2299 Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time 2300 and Retrans Timer) may contain a value denoting unspecified. In such 2301 cases, the parameter should be ignored and the host should continue 2302 using whatever value it is already using. In particular, a host MUST 2303 NOT interpret the unspecified value as meaning change back to the 2304 default value that was in use before the first Router Advertisement was 2305 received. This rule prevents hosts from continually changing an 2306 internal variable when one router advertises a specific value, but other 2307 routers advertise the unspecified value. 2309 On receipt of a valid Router Advertisement, a host extracts the source 2310 address of the packet and does the following: 2312 - If the address is not already present in the host's Default Router 2313 List, and the advertisement's Router Lifetime is non-zero, create a 2314 new entry in the list, and initialize its invalidation timer value 2315 from the advertisement's Router Lifetime field. 2317 - If the address is already present in the host's Default Router List 2318 as a result of a previously-received advertisement, reset its 2319 invalidation timer to the Router Lifetime value in the newly- 2320 received advertisement. 2322 - If the address is already present in the host's Default Router List 2323 and the received Router Lifetime value is zero, immediately time- 2324 out the entry as specified in Section 6.3.5. 2326 To limit the storage needed for the Default Router List, a host MAY 2327 choose not to store all of the router addresses discovered via 2328 advertisements. However, a host MUST retain at least two router 2329 addresses and SHOULD retain more. Default router selections are made 2330 whenever communication to a destination appears to be failing. Thus, 2331 the more routers on the list, the more likely an alternative working 2332 router can be found quickly (e.g., without having to wait for the next 2333 advertisement to arrive). 2335 If the received Cur Hop Limit value is non-zero the host SHOULD set its 2336 CurHopLimit variable to the received value. 2338 If the received Reachable Time value is non-zero the host SHOULD set its 2339 BaseReachableTime variable to the received value. If the new value 2340 differs from the previous value, the host SHOULD recompute a new random 2341 ReachableTime value. ReachableTime is computed as a uniformly- 2342 distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR 2343 times the BaseReachableTime. Using a random component eliminates the 2344 possibility Neighbor Unreachability Detection messages synchronize with 2345 each other. 2347 In most cases, the advertised Reachable Time value will be the same in 2348 consecutive Router Advertisements and a host's BaseReachableTime rarely 2349 changes. In such cases, an implementation SHOULD insure that a new 2350 random value gets recomputed at least once every few hours. 2352 The RetransTimer variable SHOULD be copied from the Retrans Timer field, 2353 if the received value is non-zero. 2355 After extracting information from the fixed part of the Router 2356 Advertisement message, the advertisement is scanned for valid options. 2357 If the advertisement contains a Source Link-Layer Address option the 2358 link-layer address SHOULD be recorded in the Neighbor Cache entry for 2359 the router (creating an entry if necessary) and the IsRouter flag in the 2360 Neighbor Cache entry MUST be set to true. The IsRouter flag is used by 2361 Neighbor Unreachability Detection to determine when a router changes to 2362 being a host (i.e., no longer capable of forwarding packets). If a 2363 Neighbor Cache entry is created for the router its reachability state 2364 MUST be set to STALE as specified in Section 7.3.3. If a cache entry 2365 already exists and is updated with a different link-layer address the 2366 reachability state MUST also be set to STALE. 2368 If the MTU option is present, hosts SHOULD copy the option's value into 2369 LinkMTU if the value does not exceed the default LinkMTU value specified 2370 in the link type specific document (e.g., [IPv6-ETHER]). 2372 Prefix Information options that have the "on-link" (L) flag set indicate 2373 a prefix identifying a range of addresses that should be considered on- 2374 link. Note, however, that a Prefix Information option with the on-link 2375 flag set to zero does not convey any meaning. In particular, such a 2376 prefix MUST NOT be considered to be off-link. Prefixes with the on-link 2377 flag set to zero would normally have the autonomous flag set and be used 2378 by [ADDRCONF]. 2380 For each Prefix Information option with the on-link flag set, a host 2381 does the following: 2383 - If the prefix is the link-local prefix, silently ignore the Prefix 2384 Information option. 2386 - If the prefix is not already present in the Prefix List, and the 2387 Prefix Information option's Valid Lifetime field is non-zero, 2388 create a new entry for the prefix and initialize its invalidation 2389 timer to the Valid Lifetime value in the Prefix Information option. 2391 - If the prefix is already present in the host's Prefix List as the 2392 result of a previously-received advertisement, reset its 2393 invalidation timer to the Valid Lifetime value in the Prefix 2394 Information option. If the new Lifetime value is zero, time-out 2395 the prefix immediately (see Section 6.3.5). 2397 - If the Prefix Information option's Valid Lifetime field is zero, 2398 and the prefix is not present in the host's Prefix List, silently 2399 ignore the option. 2401 Note: Implementations can choose to process the on-link aspects of 2402 the prefixes separately from the address autoconfiguration aspects of 2403 the prefixes by, e.g., passing a copy of each valid Router 2404 Advertisement message to both an "on-link" and an "addrconf" 2405 function. Each function can then operate independently on the 2406 prefixes that have the appropriate flag set. 2408 6.3.5. Timing out Prefixes and Default Routers 2410 Whenever the invalidation timer expires for a Prefix List entry, that 2411 entry is discarded. No existing Destination Cache entries need be 2412 updated, however. Should a reachability problem arise with an existing 2413 Neighbor Cache entry, Neighbor Unreachability Detection will perform any 2414 needed recovery. 2416 Whenever the Lifetime of an entry in the Default Router List expires, 2417 that entry is discarded. When removing a router from the Default Router 2418 list, the node MUST update the Destination Cache in such a way that all 2419 entries using the router perform next-hop determination again rather 2420 than continue sending traffic to the (deleted) router. 2422 6.3.6. Default Router Selection 2424 The algorithm for selecting a router depends in part on whether or not a 2425 router is known to be reachable. The exact details of how a node keeps 2426 track of a neighbor's reachability state are covered in Section 7.3. 2427 The algorithm for selecting a default router is invoked during next-hop 2428 determination when no Destination Cache entry exists for an off-link 2429 destination or when communication through an existing router appears to 2430 be failing. Under normal conditions, a router would be selected the 2431 first time traffic is sent to a destination, with subsequent traffic for 2432 that destination using the same router as indicated in the Destination 2433 Cache modulo any changes to the Destination Cache caused by Redirect 2434 messages. 2436 The policy for selecting routers from the Default Router List is as 2437 follows: 2439 1) Routers that are reachable or probably reachable (i.e., in any 2440 state other than INCOMPLETE) SHOULD be preferred over routers whose 2441 reachability is unknown or suspect (i.e., in the INCOMPLETE state, 2442 or for which no Neighbor Cache entry exists). An implementation 2443 may choose to always return the same router or cycle through the 2444 router list in a round-robin fashion as long as it always returns a 2445 reachable or a probably reachable router when one is available. 2447 2) When no routers on the list are known to be reachable or probably 2448 reachable, routers SHOULD be selected in a round-robin fashion, so 2449 that subsequent requests for a default router do not return the 2450 same router until all other routers have been selected. 2452 Cycling through the router list in this case ensures that all 2453 available routers are actively probed by the Neighbor 2454 Unreachability Detection algorithm. A request for a default router 2455 is made in conjunction with the sending of a packet to a router, 2456 and the selected router will be probed for reachability as a side 2457 effect. 2459 3) If the Default Router List is empty, assume that all destinations 2460 are on-link as specified in Section 5.2. 2462 6.3.7. Sending Router Solicitations 2464 When an interface becomes enabled, a host may be unwilling to wait for 2465 the next unsolicited Router Advertisement to locate default routers or 2466 learn prefixes. To obtain Router Advertisements quickly, a host SHOULD 2467 transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each 2468 separated by at least RTR_SOLICITATION_INTERVAL seconds. Router 2469 Solicitations may be sent after any of the following events: 2471 - The interface is initialized at system startup time. 2473 - The interface is reinitialized after a temporary interface failure 2474 or after being temporarily disabled by system management. 2476 - The system changes from being a router to being a host, by having 2477 its IP forwarding capability turned off by system management. 2479 - The host attaches to a link for the first time. 2481 - The host re-attaches to a link after being detached for some time. 2483 A host sends Router Solicitations to the all-routers multicast address. 2484 The IP source address is set to either one of the interface's unicast 2485 addresses or the unspecified address. The Source Link-Layer Address 2486 option SHOULD be set to the host's link-layer address, if the IP source 2487 address is a unicast address. 2489 Before a host sends an initial solicitation, it SHOULD delay the 2490 transmission for a random amount of time between 0 and 2491 MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when 2492 many hosts start up on a link at the same time, such as might happen 2493 after recovery from a power failure. If a host has already performed a 2494 random delay since the interface became (re)enabled (e.g., as part of 2495 Duplicate Address Detection [ADDRCONF]) there is no need to delay again 2496 before sending the first Router Solicitation message. 2498 Once the host sends a Router Solicitation, and receives a valid Router 2499 Advertisement with a non-zero Router Lifetime, the host MUST desist from 2500 sending additional solicitations on that interface, until the next time 2501 one of the above events occurs. Moreover, a host SHOULD send at least 2502 one solicitation in the case where an advertisement is received prior to 2503 having sent a solicitation. Unsolicited Router Advertisements may be 2504 incomplete (see Section 6.2.3); solicited advertisements are expected to 2505 contain complete information. 2507 If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no 2508 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 2509 seconds after sending the last solicitation, the host concludes that 2510 there are no routers on the link for the purpose of [ADDRCONF]. 2511 However, the host continues to receive and process Router Advertisements 2512 messages in the event that routers appear on the link. 2514 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 2516 This section describes the functions related to Neighbor Solicitation 2517 and Neighbor Advertisement messages and includes descriptions of address 2518 resolution and the Neighbor Unreachability Detection algorithm. 2520 Neighbor Solicitation and Advertisement messages are also used for 2521 Duplicate Address Detection as specified by [ADDRCONF]. In particular, 2522 Duplicate Address Detection sends Neighbor Solicitation messages with an 2523 unspecified source address targeting its own "tentative" address. Such 2524 messages trigger nodes already using the address to respond with a 2525 multicast Neighbor Advertisement indicating that the address is in use. 2527 7.1. Message Validation 2529 7.1.1. Validation of Neighbor Solicitations 2531 A node MUST silently discard any received Neighbor Solicitation messages 2532 that do not satisfy all of the following validity checks: 2534 - The IP Hop Limit field has a value of 255, i.e., the packet could 2535 not possibly have been forwarded by a router. 2537 - If the message includes an IP Authentication Header, the message 2538 authenticates correctly. 2540 - ICMP Checksum is valid. 2542 - ICMP Code is 0. 2544 - ICMP length (derived from the IP length) is 24 or more octets. 2546 - Target Address is not a multicast address. 2548 - All included options have a length that is greater than zero. 2550 The contents of the Reserved field, and of any unrecognized options, 2551 MUST be ignored. Future, backward-compatible changes to the protocol 2552 may specify the contents of the Reserved field or add new options; 2553 backward-incompatible changes may use different Code values. 2555 The contents of any defined options that are not specified to be used 2556 with Neighbor Solicitation messages MUST be ignored and the packet 2557 processed as normal. The only defined option that may appear is the 2558 Source Link-Layer Address option. 2560 A Neighbor Solicitation that passes the validity checks is called a 2561 "valid solicitation". 2563 7.1.2. Validation of Neighbor Advertisements 2565 A node MUST silently discard any received Neighbor Advertisement 2566 messages that do not satisfy all of the following validity checks: 2568 - The IP Hop Limit field has a value of 255, i.e., the packet could 2569 not possibly have been forwarded by a router. 2571 - If the message includes an IP Authentication Header, the message 2572 authenticates correctly. 2574 - ICMP Checksum is valid. 2576 - ICMP Code is 0. 2578 - ICMP length (derived from the IP length) is 24 or more octets. 2580 - Target Address is not a multicast address. 2582 - If the IP Destination Address is a multicast address the Solicited 2583 flag is zero. 2585 - All included options have a length that is greater than zero. 2587 The contents of the Reserved field, and of any unrecognized options, 2588 MUST be ignored. Future, backward-compatible changes to the protocol 2589 may specify the contents of the Reserved field or add new options; 2590 backward-incompatible changes may use different Code values. 2592 The contents of any defined options that are not specified to be used 2593 with Neighbor Advertisement messages MUST be ignored and the packet 2594 processed as normal. The only defined option that may appear is the 2595 Target Link-Layer Address option. 2597 A Neighbor Advertisements that passes the validity checks is called a 2598 "valid advertisement". 2600 7.2. Address Resolution 2602 Address resolution is the process through which a node determines the 2603 link-layer address of a neighbor given only its IP address. Address 2604 resolution is performed only on addresses that are determined to be on- 2605 link and for which the sender does not know the corresponding link-layer 2606 address. Address resolution is never performed on multicast addresses. 2608 7.2.1. Interface Initialization 2610 When a multicast-capable interface becomes enabled the node MUST join 2611 the all-nodes multicast address on that interface, as well as the 2612 solicited-node multicast address corresponding to each of the IP 2613 addresses assigned to the interface. 2615 The set of addresses assigned to an interface may change over time. New 2616 addresses might be added and old addresses might be removed [ADDRCONF]. 2617 In such cases the node MUST join and leave the solicited-node multicast 2618 address corresponding to the new and old addresses, respectively. Note 2619 that multiple unicast addresses may map into the same solicited-node 2620 multicast address; a node MUST NOT leave the solicited-node multicast 2621 group until all assigned addresses corresponding to that multicast 2622 address have been removed. 2624 7.2.2. Sending Neighbor Solicitations 2626 When a node has a unicast packet to send to a neighbor, but does not 2627 know the neighbor's link-layer address, it performs address resolution. 2628 For multicast-capable interfaces this entails creating a Neighbor Cache 2629 entry in the INCOMPLETE state and transmitting a Neighbor Solicitation 2630 message targeted at the neighbor. The solicitation is sent to the 2631 solicited-node multicast address corresponding to the target address. 2633 If the source address of the packet prompting the solicitation is the 2634 same as one of the addresses assigned to the outgoing interface, that 2635 address SHOULD be placed in the IP Source Address of the outgoing 2636 solicitation. Otherwise, any one of the addresses assigned to the 2637 interface should be used. Using the prompting packet's source address 2638 when possible insures that the recipient of the Neighbor Solicitation 2639 installs in its Neighbor Cache the IP address that is highly likely to 2640 be used in subsequent return traffic belonging to the prompting packet's 2641 "connection". 2643 The sender SHOULD include its link-layer address (if it has one) in the 2644 solicitation as a Source Link-Layer Address option. 2646 While waiting for address resolution to complete, the sender MUST, for 2647 each neighbor, retain a small queue of packets waiting for address 2648 resolution to complete. The queue MUST hold at least one packet, and 2649 MAY contain more. However, the number of queued packets per neighbor 2650 SHOULD be limited to some small value. When a queue overflows, the new 2651 arrival SHOULD replace the oldest entry. Once address resolution 2652 completes, the node transmits any queued packets. 2654 While awaiting a response, the sender SHOULD retransmit Neighbor 2655 Solicitation messages approximately every RetransTimer milliseconds, 2656 even in the absence of additional traffic to the neighbor. 2657 Retransmissions MUST be rate-limited to at most one solicitation per 2658 neighbor every RetransTimer milliseconds. 2660 If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT 2661 solicitations, address resolution has failed. The sender MUST return 2662 ICMP destination unreachable indications with code 3 (Address 2663 Unreachable) for each packet queued awaiting address resolution. 2665 7.2.3. Receipt of Neighbor Solicitations 2667 A valid Neighbor Solicitation where the Target Address is not a unicast 2668 or anycast address assigned to the receiving interface, and the Target 2669 Address is not a "tentative" address on which Duplicate Address 2670 Detection is being performed [ADDRCONF] MUST be silently ignored. If 2671 the Target Address is tentative, the Neighbor Solicitation should be 2672 processed as described in [ADDRCONF]. 2674 Upon receipt of a valid Neighbor Solicitation targeted at the node, the 2675 recipient SHOULD update the Neighbor Cache entry for the IP Source 2676 Address of the solicitation if the Source Address is not the unspecified 2677 address. If an entry does not already exist, the node SHOULD create a 2678 new one and set its reachability state to STALE as specified in 2679 Section 7.3.3. If a cache entry already exists and is updated with a 2680 different link-layer address its reachability state MUST be set to 2681 STALE. If the solicitation contains a Source Link-Layer Address option, 2682 the entry's cached link-layer address should be replaced with the one in 2683 the solicitation. 2685 If the Source Address is the unspecified address the node MUST NOT 2686 create or update the Neighbor Cache entry. 2688 After any updates to the Neighbor Cache, the node sends a Neighbor 2689 Advertisement response as described in the next section. 2691 7.2.4. Sending Solicited Neighbor Advertisements 2693 A node sends a Neighbor Advertisement in response to a valid Neighbor 2694 Solicitation targeting one of the node's assigned addresses. The Target 2695 Address of the advertisement is copied from the Target Address of the 2696 solicitation. If the solicitation's IP Destination Address is a unicast 2697 or anycast address, the Target Link-Layer Address option SHOULD NOT be 2698 included; the neighboring node's cached value must already be current in 2699 order for the solicitation to have been received. If the solicitation's 2700 IP Destination Address is a solicited-node multicast address, the Target 2701 Link-Layer option MUST be included in the advertisement. If the node is 2702 a router, it MUST set the Router flag to one; otherwise it MUST set the 2703 flag to zero. 2705 If the Target Address is either an anycast address or a unicast address 2706 for which the node is providing proxy service, the Override flag SHOULD 2707 be set to zero. Otherwise, it SHOULD be set to one. Proper setting of 2708 the Override flag insures that nodes give preference to non-proxy 2709 advertisements, even when received after proxy advertisements, but that 2710 the first advertisement for an anycast address "wins". 2712 If the source of the solicitation is the unspecified address, the node 2713 MUST set the Solicited flag to zero and multicast the advertisement to 2714 the all-nodes address. Otherwise, the node MUST set the Solicited flag 2715 to one and unicast the advertisement to the Source Address of the 2716 solicitation. 2718 If the Target Address is an anycast address the sender SHOULD delay 2719 sending a response for a random time between 0 and 2720 MAX_ANYCAST_DELAY_TIME seconds. 2722 7.2.5. Receipt of Neighbor Advertisements 2724 When a valid Neighbor Advertisement is received (either solicited or 2725 unsolicited), the Neighbor Cache is searched for the target's entry. If 2726 no entry exists, the advertisement SHOULD be silently discarded. There 2727 is no need to create an entry in this case, since the recipient has 2728 apparently not initiated any communication with the target. 2730 Once the appropriate Neighbor Cache entry has been located, the specific 2731 actions taken depend on the state of the Neighbor Cache entry and the 2732 flags in the advertisement. If the entry is in an INCOMPLETE state 2733 (i.e., no link-layer address is cached for the target) the received 2734 advertisement updates the entry. If a cached link-layer address is 2735 already present, however, a node might choose to ignore the received 2736 advertisement and continue using the cached link-layer address. 2738 If the target's Neighbor Cache entry is in the INCOMPLETE state, the 2739 receiving node records the link-layer address in the Neighbor Cache 2740 entry and sends any packets queued for the neighbor awaiting address 2741 resolution. If the Solicited flag is set, the reachability state for 2742 the neighbor MUST be set to REACHABLE; otherwise it MUST be set to 2743 STALE. (A more detailed explanation of reachability state is described 2744 in Section 7.3.3). The Override flag is ignored if the entry is in the 2745 INCOMPLETE state. 2747 If the target's Neighbor Cache entry is in any state other than 2748 INCOMPLETE when the advertisement is received, the advertisement's 2749 Override flag's setting determines whether the Target Link-Layer Address 2750 option (if present) replaces the cached address. If the Override flag 2751 is set, the receiving node MUST install the link-layer address in its 2752 cache; if the flag is zero, the receiving node MUST NOT install the 2753 link-layer address in its cache. An advertisement's sender sets the 2754 Override flag when it wants its Target Link-Layer Address option to 2755 replace the cached value in Neighbor Cache entries, regardless of their 2756 current contents. 2758 If the target's Neighbor Cache entry is in any state other than 2759 INCOMPLETE when the advertisement is received, the advertisement's 2760 Solicited flag setting determines what the entry's new state should be. 2761 If the Solicited flag is set, the entry's state MUST be set to 2762 REACHABLE; if the flag is zero, the entry's state MUST be set to STALE. 2763 An advertisement's Solicited flag should only be set if the 2764 advertisement is a response to a Neighbor Solicitation. Because 2765 Neighbor Unreachability Solicitations are sent to the cached link-layer 2766 address, a receipt of a solicited advertisement indicates that the 2767 forward path is working. Receipt of an unsolicited advertisement, 2768 however, suggests that a neighbor has urgent information to announce 2769 (e.g., a changed link-layer address). Regardless of whether or not the 2770 new link-layer address is installed in the cache, a node should verify 2771 the reachability of the path it is currently using when it sends the 2772 next packet, so that it quickly finds a working path if the existing 2773 path has failed (e.g., as would be the case if the unsolicited Neighbor 2774 Advertisement is sent to announce a link-layer address change). 2776 In those cases where the cached link-layer address is updated, the 2777 receiving node MUST examine the Router flag in the received 2778 advertisement and update the IsRouter flag in the Neighbor Cache entry 2779 to reflect whether the node is a host or router. In those cases where 2780 the neighbor was previously used as a router, but the advertisement's 2781 Router flag is now set to zero, the node MUST remove that router from 2782 the Default Router List and update the Destination Cache entries for all 2783 destinations using that neighbor as a router as specified in 2784 Section 7.3.3. 2786 7.2.6. Sending Unsolicited Neighbor Advertisements 2788 In some cases a node may be able to determine that its link-layer 2789 address has changed (e.g., hot-swap of an interface card) and may wish 2790 to inform its neighbors of the new link-layer address quickly. In such 2791 cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited 2792 Neighbor Advertisement messages to the all-nodes multicast address. 2793 These advertisements MUST be separated by at least RetransTimer seconds. 2795 The Target Address field in the unsolicited advertisement is set to an 2796 IP address of the interface, and the Target Link-Layer Address option is 2797 filled with the new link-layer address. The Solicited flag MUST be set 2798 to zero, in order to avoid confusing the Neighbor Unreachability 2799 Detection algorithm. If the node is a router, it MUST set the Router 2800 flag to one; otherwise it MUST set it to zero. The Override flag MAY be 2801 set to either zero or one. In either case, neighboring nodes will 2802 immediately change the state of their Neighbor Cache entries for the 2803 Target Address to STALE, prompting them to verify the path for 2804 reachability. If the Override flag is set to one, neighboring nodes 2805 will install the new link-layer address in their caches. Otherwise, 2806 they will ignore the new link-layer address, choosing instead to probe 2807 the cached address. 2809 A node that has multiple IP addresses assigned to an interface MAY 2810 multicast a separate Neighbor Advertisement for each address. In such a 2811 case the node SHOULD introduce a small delay between the sending of each 2812 advertisement to reduce the probability of the advertisements being lost 2813 due to congestion. 2815 A proxy MAY multicast Neighbor Advertisements when its link-layer 2816 address changes or when it is configured (by system management or other 2817 mechanisms) to proxy for an address. If there are multiple nodes that 2818 are providing proxy services for the same set of addresses the proxies 2819 SHOULD provide a mechanism that prevents multiple proxies from 2820 multicasting advertisements for any one address, in order to reduce the 2821 risk of excessive multicast traffic. 2823 Also, a node belonging to an anycast address MAY multicast unsolicited 2824 Neighbor Advertisements for the anycast address when the node's link- 2825 layer address changes. 2827 Note that because unsolicited Neighbor Advertisements do not reliably 2828 update caches in all nodes (the advertisements might not be received by 2829 all nodes), they should only be viewed as a performance optimization to 2830 quickly update the caches in most neighbors. The Neighbor 2831 Unreachability Detection algorithm ensures that all nodes obtain a 2832 reachable link-layer address, though the delay may be slightly longer. 2834 7.2.7. Anycast Neighbor Advertisements 2836 From the perspective of Neighbor Discovery, anycast addresses are 2837 treated just like unicast addresses in most cases. Because an anycast 2838 address is syntactically the same as a unicast address, nodes performing 2839 address resolution or Neighbor Unreachability Detection on an anycast 2840 address treat it as if it were a unicast address. No special processing 2841 takes place. 2843 Nodes that have an anycast address assigned to an interface treat them 2844 exactly the same as if they were unicast addresses with two exceptions. 2845 First, Neighbor Advertisements sent in response to a Neighbor 2846 Solicitation SHOULD be delayed by a random time between 0 and 2847 MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. 2848 Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, 2849 so that when multiple advertisements are received, the first received 2850 advertisement is used rather than the most recently received 2851 advertisement. 2853 As with unicast addresses, Neighbor Unreachability Detection ensures 2854 that a node quickly detects when the current binding for an anycast 2855 address becomes invalid. 2857 7.2.8. Proxy Neighbor Advertisements 2859 Under limited circumstances, a router MAY proxy for one or more other 2860 nodes, that is, through Neighbor Advertisements indicate that it is 2861 willing to accept packets not explicitly addressed to itself. For 2862 example, a router might accept packets on behalf of a mobile node that 2863 has moved off-link. The mechanisms used by proxy are identical to the 2864 mechanisms used with anycast addresses. 2866 A proxy MUST join the solicited-node multicast address(es) that 2867 correspond to the IP address(es) assigned to the node for which it is 2868 proxying. 2870 All solicited proxy Neighbor Advertisement messages MUST have the 2871 Override flag set to zero. This ensures that if the node itself is 2872 present on the link its Neighbor Advertisement (with the Override flag 2873 set to one) will take precedence of any advertisement received from a 2874 proxy. A proxy MAY send unsolicited advertisements with the Override 2875 flag set to one as specified in Section 7.2.6, but doing so may cause 2876 the proxy advertisement to override a valid entry created by the node 2877 itself. 2879 Finally, when sending a proxy advertisement in response to a Neighbor 2880 Solicitation, the sender should delay its response by a random time 2881 between 0 and MAX_ANYCAST_DELAY_TIME seconds. 2883 7.3. Neighbor Unreachability Detection 2885 Communication to or through a neighbor may fail for numerous reasons at 2886 any time, including hardware failure, hot-swap of an interface card, 2887 etc. If the destination has failed, no recovery is possible and 2888 communication fails. On the other hand, if it is the path that has 2889 failed, recovery may be possible. Thus, a node actively tracks the 2890 reachability "state" for the neighbors to which it is sending packets. 2892 Neighbor Unreachability Detection is used for all paths between hosts 2893 and neighboring nodes, including host-to-host, host-to-router, and 2894 router-to-host communication. Neighbor Unreachability Detection may 2895 also be used between routers, but is not required if an equivalent 2896 mechanism is available, for example, as part of the routing protocols. 2898 When a path to a neighbor appears to be failing, the specific recovery 2899 procedure depends on how the neighbor is being used. If the neighbor is 2900 the ultimate destination, for example, address resolution should be 2901 performed again. If the neighbor is a router, however, attempting to 2902 switch to another router would be appropriate. The specific recovery 2903 that takes place is covered under next-hop determination; Neighbor 2904 Unreachability Detection signals the need for next-hop determination by 2905 deleting a Neighbor Cache entry. 2907 Neighbor Unreachability Detection is performed only for neighbors to 2908 which unicast packets are sent; it is not used when sending to multicast 2909 addresses. 2911 7.3.1. Reachability Confirmation 2913 A neighbor is considered reachable if the node has recently received a 2914 confirmation that packets sent recently to the neighbor were received by 2915 its IP layer. Positive confirmation can be gathered in two ways: hints 2916 from upper layer protocols that indicate a connection is making "forward 2917 progress", or receipt of a Neighbor Advertisement message that is a 2918 response to a Neighbor Solicitation message. 2920 A connection makes "forward progress" if the packets received from a 2921 remote peer can only be arriving if recent packets sent to that peer are 2922 actually reaching it. In TCP, for example, receipt of a (new) 2923 acknowledgement indicates that previously sent data reached the peer. 2924 Likewise, the arrival of new (non-duplicate) data indicates that earlier 2925 acknowledgements are being delivered to the remote peer. If packets are 2926 reaching the peer, they must also be reaching the sender's next-hop 2927 neighbor; thus "forward progress" is a confirmation that the next-hop 2928 neighbor is reachable. For off-link destinations, forward progress 2929 implies that the first-hop router is reachable. When available, this 2930 upper-layer information SHOULD be used. 2932 In some cases (e.g., UDP-based protocols and routers forwarding packets 2933 to hosts) such reachability information may not be readily available 2934 from upper-layer protocols. When no hints are available and a node is 2935 sending packets to a neighbor, the node actively probes the neighbor 2936 using unicast Neighbor Solicitation messages to verify that the forward 2937 path is still working. 2939 The receipt of a solicited Neighbor Advertisement serves as reachability 2940 confirmation, since advertisements with the Solicited flag set to one 2941 are sent only in response to a Neighbor Solicitation. Receipt of other 2942 Neighbor Discovery messages such as Router Advertisements and Neighbor 2943 Advertisement with the Solicited flag set to zero MUST NOT be treated as 2944 a reachability confirmation. Receipt of unsolicited messages only 2945 confirm the one-way path from the sender to the recipient node. In 2946 contrast, Neighbor Unreachability Detection requires that a node keep 2947 track of the reachability of the forward path to a neighbor from the its 2948 perspective, not the neighbor's perspective. Note that receipt of a 2949 solicited advertisement indicates that a path is working in both 2950 directions. The solicitation must have reached the neighbor, prompting 2951 it to generate an advertisement. Likewise, receipt of an advertisement 2952 indicates that the path from the sender to the recipient is working. 2953 However, the latter fact is known only to the recipient; the 2954 advertisement's sender has no direct way of knowing that the 2955 advertisement it sent actually reached a neighbor. From the perspective 2956 of Neighbor Unreachability Detection, only the reachability of the 2957 forward path is of interest. 2959 7.3.2. Neighbor Cache Entry States 2961 A Neighbor Cache entry can be in one of five states: 2963 INCOMPLETE Address resolution is being performed on the entry. 2964 Specifically, a Neighbor Solicitation has been sent to 2965 the solicited-node multicast address of the target, but 2966 the corresponding Neighbor Advertisement has not yet been 2967 received. 2969 REACHABLE Positive confirmation was received within the last 2970 ReachableTime milliseconds that the forward path to the 2971 neighbor was functioning properly. While REACHABLE, no 2972 special action takes place as packets are sent. 2974 STALE More than ReachableTime milliseconds have elapsed since 2975 the last positive confirmation was received that the 2976 forward path was functioning properly. While stale, no 2977 action takes place until a packet is sent. 2979 The STALE state is entered upon receiving an unsolicited 2980 Neighbor Discovery message that updates the cached link- 2981 layer address. Receipt of such a message does not 2982 confirm reachability, and entering the STALE state 2983 insures reachability is verified quickly if the entry is 2984 actually being used. However, reachability is not 2985 actually verified until the entry is actually used. 2987 DELAY More than ReachableTime milliseconds have elapsed since 2988 the last positive confirmation was received that the 2989 forward path was functioning properly, and a packet was 2990 sent within the last DELAY_FIRST_PROBE_TIME seconds. If 2991 no reachability confirmation is received within 2992 DELAY_FIRST_PROBE_TIME seconds of entering the DELAY 2993 state, send a Neighbor Solicitation and change the state 2994 to PROBE. 2996 The DELAY state is an optimization that gives upper-layer 2997 protocols additional time to provide reachability 2998 confirmation in those cases where ReachableTime 2999 milliseconds have passed since the last confirmation due 3000 to lack of recent traffic. Without this optimization the 3001 opening of a TCP connection after a traffic lull would 3002 initiate probes even though the subsequent three-way 3003 handshake would provide a reachability confirmation 3004 almost immediately. 3006 PROBE A reachability confirmation is actively sought by 3007 retransmitting Neighbor Solicitations every RetransTimer 3008 milliseconds until a reachability confirmation is 3009 received. 3011 7.3.3. Node Behavior 3013 Neighbor Unreachability Detection operates in parallel with the sending 3014 of packets to a neighbor. While reasserting a neighbor's reachability, 3015 a node continues sending packets to that neighbor using the cached 3016 link-layer address. If no traffic is sent to a neighbor, no probes are 3017 sent. 3019 When a node needs to performs address resolution on a neighboring 3020 address, it creates an entry in the INCOMPLETE state and initiates 3021 address resolution as specified in Section 7.2. If address resolution 3022 fails, the entry SHOULD be deleted, so that subsequent traffic to that 3023 neighbor invokes the next-hop determination procedure again. Invoking 3024 next-hop determination at this point insures that alternate default 3025 routers are tried. 3027 When a reachability conformation is received (either through upper-layer 3028 advice or a solicited Neighbor Advertisement) an entry's state changes 3029 to REACHABLE. The one exception is that upper-layer advice has no 3030 effect on entries in the INCOMPLETE state (e.g., for which no link-layer 3031 address is cached). 3033 When ReachableTime milliseconds have passed since receipt of the last 3034 reachability confirmation for a neighbor, the Neighbor Cache entries 3035 state changes from REACHABLE to STALE. 3037 Note: An implementation may actually defer changing the state from 3038 REACHABLE to STALE until a packet is sent to the neighbor, i.e., 3039 there need not be an explicit timeout event associated with the 3040 expiration of ReachableTime. 3042 The first time a node sends a packet to a neighbor whose entry is STALE, 3043 the sender changes the state to DELAY and a sets a timer to expire in 3044 DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY 3045 state when the timer expires, the entry's state changes to PROBE. If 3046 reachability confirmation is received, the entry's state changes to 3047 REACHABLE. 3049 Upon entering the PROBE state, a node sends a unicast Neighbor 3050 Solicitation message to the neighbor using the cached link-layer 3051 address. While in the PROBE state, a node retransmits Neighbor 3052 Solicitation messages every RetransTimer milliseconds until reachability 3053 confirmation is obtained. Probes are retransmitted even if no 3054 additional packets are sent to the neighbor. If no response is received 3055 after waiting RetransTimer milliseconds after sending the 3056 MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry 3057 SHOULD be deleted. Subsequent traffic to that neighbor will recreate 3058 the entry and performs address resolution again. 3060 Note that all Neighbor Solicitations are rate-limited on a per-neighbor 3061 basis. A node MUST NOT send Neighbor Solicitations to the same neighbor 3062 more frequently than once every RetransTimer milliseconds. 3064 A Neighbor Cache entry enters the STALE state when created as a result 3065 of receiving packets other than solicited Neighbor Advertisements (i.e., 3066 Router Solicitations, Router Advertisements, Redirects, and Neighbor 3067 Solicitations). These packets contain the link-layer address of either 3068 the sender or, in the case of Redirect, the redirection target. 3069 However, receipt of these link-layer addresses does not confirm 3070 reachability of the forward-direction path to that node. Placing a 3071 newly created Neighbor Cache entry for which the link-layer address is 3072 known in the STALE state provides assurance that path failures are 3073 detected quickly. In addition, should a cached link-layer address be 3074 modified due to receiving one of the above messages the state SHOULD 3075 also be set to STALE to provide prompt verification that the patch to 3076 the new link-layer address is working. 3078 To properly detect the case where a router switches from being a router 3079 to being a host (e.g., if its IP forwarding capability is turned off by 3080 system management), a node MUST compare the Router flag field in all 3081 received Neighbor Advertisement messages with the IsRouter flag recorded 3082 in the Neighbor Cache entry. When a node detects that a neighbor has 3083 changed from being a router to being a host, the node MUST remove that 3084 router from the Default Router List and update the Destination Cache as 3085 described in Section 6.3.5. Note that a router may not be listed in the 3086 Default Router List, even though a Destination Cache entry is using it 3087 (e.g., a host was redirected to it). In such cases, all Destination 3088 Cache entries that reference the (former) router must perform next-hop 3089 determination again before using the entry. 3091 In some cases, link-specific information may indicate that a path to a 3092 neighbor has failed (e.g., the resetting of a virtual circuit). In such 3093 cases, link-specific information may be used to purge Neighbor Cache 3094 entries before the Neighbor Unreachability Detection would do so. 3095 However, link-specific information MUST NOT be used to confirm the 3096 reachability of a neighbor; such information does not provide end-to-end 3097 confirmation between neighboring IP layers. 3099 8. REDIRECT FUNCTION 3101 This section describes the functions related to the sending and 3102 processing of Redirect messages. 3104 Redirect messages are sent by routers to redirect a host to a better 3105 first-hop router for a specific destination or to inform hosts that a 3106 destination is in fact a neighbor (i.e., on-link). The latter is 3107 accomplished by having the ICMP Target Address be equal to the ICMP 3108 Destination Address. 3110 A router MUST be able to determine the link-local address for each of 3111 its neighboring routers in order to ensure that the target address in a 3112 Redirect message identifies the neighbor router by its link-local 3113 address. This may require that routing protocols exchange link-local 3114 addresses. 3116 8.1. Validation of Redirect Messages 3118 A host MUST silently discard any received Redirect message that does not 3119 satisfy all of the following validity checks: 3121 - IP Source Address is a link-local address. Routers must use their 3122 link-local address as the source for Router Advertisement and 3123 Redirect messages so that hosts can uniquely identify routers. 3125 - The IP Hop Limit field has a value of 255, i.e., the packet could 3126 not possibly have been forwarded by a router. 3128 - If the message includes an IP Authentication Header, the message 3129 authenticates correctly. 3131 - ICMP Checksum is valid. 3133 - ICMP Code is 0. 3135 - ICMP length (derived from the IP length) is 40 or more octets. 3137 - The IP source address of the Redirect is the same as the current 3138 first-hop router for the specified ICMP Destination Address. 3140 - The ICMP Destination Address field in the redirect message does not 3141 contain a multicast address. 3143 - The ICMP Target Address is either a link-local address (when 3144 redirected to a router) or the same as the ICMP Destination Address 3145 (when redirected to the on-link destination). 3147 - All included options have a length that is greater than zero. 3149 The contents of the Reserved field, and of any unrecognized options MUST 3150 be ignored. Future, backward-compatible changes to the protocol may 3151 specify the contents of the Reserved field or add new options; 3152 backward-incompatible changes may use different Code values. 3154 The contents of any defined options that are not specified to be used 3155 with Redirect messages MUST be ignored and the packet processed as 3156 normal. The only defined options that may appear are the Target Link- 3157 Layer Address option and the Redirected Header option. 3159 A host MUST NOT consider a redirect invalid just because the Target 3160 Address of the redirect is not covered under one of the link's prefixes. 3161 Part of the semantics of the Redirect message is that the Target Address 3162 is on-link. 3164 A redirect that passes the validity checks is called a "valid redirect". 3166 8.2. Router Specification 3168 A router SHOULD send a redirect message, subject to rate limiting, 3169 whenever it forwards a packet that it not explicitly addressed to itself 3170 (i.e. a packet that is not source routed through the router) in which: 3172 - the Source Address field of the packet identifies a neighbor, and 3174 - the router determines that a better first-hop node resides on the 3175 same link as the sending node for the Destination Address of the 3176 packet being forwarded, and 3178 - the Destination Address of the packet is not a multicast address, 3179 and 3181 The transmitted redirect packet contains, consistent with the message 3182 format given in Section 4.5: 3184 - In the Target Address field: the address to which subsequent 3185 packets for the destination SHOULD be sent. If the target is a 3186 router, that router's link-local address MUST be used. If the 3187 target is a host the target address field MUST be set to the same 3188 value as the Destination Address field. 3190 - In the Destination Address field: the destination address of the 3191 invoking IP packet. 3193 - In the options: 3195 o Target Link-Layer Address option: link-layer address of the 3196 target, if known. 3198 o Redirected Header: as much of the forwarded packet as can fit 3199 without the redirect packet exceeding 576 octets in size. 3201 A router MUST limit the rate at which Redirect messages are sent, in 3202 order to limit the bandwidth and processing costs incurred by the 3203 Redirect messages when the source does not correctly respond to the 3204 Redirects, or the source chooses to ignore unauthenticated Redirect 3205 messages. More details on the rate-limiting of ICMP error messages can 3206 be found in [ICMPv6]. 3208 A router MUST NOT update its routing tables upon receipt of a Redirect. 3210 8.3. Host Specification 3212 A host receiving a valid redirect SHOULD update its Destination Cache 3213 accordingly so that subsequent traffic goes to the specified target. If 3214 no Destination Cache entry exists for the destination, an implementation 3215 SHOULD create such an entry. 3217 If the redirect contains a Target Link-Layer Address option the host 3218 either creates or updates the Neighbor Cache entry for the target. In 3219 both cases the cached link-layer address is copied from the Target 3220 Link-Layer Address option. If a Neighbor Cache entry is created for the 3221 target its reachability state MUST be set to STALE as specified in 3222 Section 7.3.3. If a cache entry already existed and it is updated with 3223 a different link-layer address its reachability state MUST also be set 3224 to STALE. 3226 In addition, if the Target Address is the same as the Destination 3227 Address, the host MUST treat the destination as on-link and set the 3228 IsRouter field in the corresponding Neighbor Cache entry to FALSE. 3229 Otherwise it MUST set IsRouter to true. 3231 A host MAY have a configuration switch that can be set to make it ignore 3232 a Redirect message that does not have an IP Authentication header. 3234 A host MUST NOT send Redirect messages. 3236 9. EXTENSIBILITY - OPTION PROCESSING 3238 Options provide a mechanism for encoding variable length fields, fields 3239 that may appear multiple times in the same packet, or information that 3240 may not appear in all packets. Options can also be used to add 3241 additional functionality to future versions of ND. 3243 In order to ensure that future extensions properly coexist with current 3244 implementations, all nodes MUST silently ignore any options they do not 3245 recognize in received ND packets and continue processing the packet. 3246 All options specified in this document MUST be recognized. A node MUST 3247 NOT ignore valid options just because the ND message contains 3248 unrecognized ones. 3250 The current set of options is defined in such a way that receivers can 3251 process multiple options in the same packet independently of each other. 3252 In order to maintain these properties future options SHOULD follow the 3253 simple rule: 3255 The option MUST NOT depend on the presence or absence of any other 3256 options. The semantics of an option should depend only on the 3257 information in the fixed part of the ND packet and on the 3258 information contained in the option itself. 3260 Adhering to the above rule has the following benefits: 3262 1) Receivers can process options independently of one another. For 3263 example, an implementation can choose to process the Prefix 3264 Information option contained in a Router Advertisement message in a 3265 user-space process while the link-layer address option in the same 3266 message is processed by routines in the kernel. 3268 2) Should the number of options cause a packet to exceed a link's MTU, 3269 multiple packets can carry subsets of the options without any 3270 change in semantics. 3272 3) Senders MAY send a subset of options in different packets. For 3273 instance, if a prefix's Valid and Preferred Lifetime are high 3274 enough, it might not be necessary to include the Prefix Information 3275 option in every Router Advertisement. In addition, different 3276 routers might send different sets of options. Thus, a receiver 3277 MUST NOT associate any action with the absence of an option in a 3278 particular packet. This protocol specifies that receivers should 3279 only act on the expiration of timers and on the information that is 3280 received in the packets. 3282 Options in Neighbor Discovery packets can appear in any order; receivers 3283 MUST be prepared to process them independently of their order. There 3284 can also be multiple instances of the same option in a message (e.g., 3285 Prefix Information options). 3287 If the number of included options in a Router Advertisement causes the 3288 advertisement's size to exceed the link MTU, the router can send 3289 multiple separate advertisements each containing a subset of the 3290 options. 3292 The amount of data to include in the Redirected Header option MUST be 3293 limited so that the entire redirect packet does not exceed 576 octets. 3295 All options are a multiple of 8 octets of length, ensuring appropriate 3296 alignment without any "pad" options. The fields in the options (as well 3297 as the fields in ND packets) are defined to align on their natural 3298 boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with 3299 the exception of the 128-bit IP addresses/prefixes, which are aligned on 3300 a 64-bit boundary. The link-layer address field contains an 3301 uninterpreted octet string; it is aligned on an 8-bit boundary. 3303 The size of an ND packet including the IP header is limited to the link 3304 MTU (which is at least 576 octets). When adding options to an ND packet 3305 a node MUST NOT exceed the link MTU. 3307 Future versions of this protocol may define new option types. Receivers 3308 MUST silently ignore any options they do not recognize and continue 3309 processing the message. 3311 10. PROTOCOL CONSTANTS 3313 Router constants: 3315 MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds 3317 MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions 3319 MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions 3321 MIN_DELAY_BETWEEN_RAS 3 seconds 3323 MAX_RA_DELAY_TIME .5 seconds 3325 Host constants: 3327 MAX_RTR_SOLICITATION_DELAY 1 second 3329 RTR_SOLICITATION_INTERVAL 4 seconds 3330 MAX_RTR_SOLICITATIONS 3 transmissions 3332 Node constants: 3334 MAX_MULTICAST_SOLICIT 3 transmissions 3336 MAX_UNICAST_SOLICIT 3 transmissions 3338 MAX_ANYCAST_DELAY_TIME 1 second 3340 MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions 3342 REACHABLE_TIME 30,000 milliseconds 3344 RETRANS_TIMER 1,000 milliseconds 3346 DELAY_FIRST_PROBE_TIME 5 seconds 3348 MIN_RANDOM_FACTOR .5 3350 MAX_RANDOM_FACTOR 1.5 3352 Additional protocol constants are defined with the message formats in 3353 Section 4. 3355 All protocol constants are subject to change in future revisions of the 3356 protocol. 3358 The constants in this specification may be overridden by specific 3359 documents that describe how IPv6 operates over different link layers. 3360 This rule allows Neighbor Discovery to operate over links with widely 3361 varying performance characteristics. 3363 11. SECURITY CONSIDERATIONS 3365 Neighbor Discovery is subject attacks that cause IP packets to flow to 3366 unexpected places. Such attacks can be used to cause denial of service 3367 but also allow nodes to intercept and optionally modify packets destined 3368 for other nodes. 3370 The protocol reduces the exposure to such threats in the absence of 3371 authentication by ignoring ND packets received from off-link senders. 3372 The Hop Limit field of all received packets is verified to contain 255, 3373 the maximum legal value. Because routers decrement the Hop Limit on all 3374 packets they forward, received packets containing a Hop Limit of 255 3375 must have originated from a neighbor. 3377 The trust model for redirects is the same as in IPv4. A redirect is 3378 accepted only if received from the same router that is currently being 3379 used for that destination. It is natural to trust the routers on the 3380 link. If a host has been redirected to another node (i.e., the 3381 destination is on-link) there is no way to prevent the target from 3382 issuing another redirect to some other destination. However, this 3383 exposure is no worse than it was; the target host, once subverted, could 3384 always act as a hidden router to forward traffic elsewhere. 3386 The protocol contains no mechanism to determine which neighbors are 3387 authorized to send a particular type of message e.g. Router 3388 Advertisements; any neighbor, presumably even in the presence of 3389 authentication, can send Router Advertisement messages thereby being 3390 able to cause denial of service. Furthermore, any neighbor can send 3391 proxy Neighbor Advertisements as well as unsolicited Neighbor 3392 Advertisements as a potential denial of service attack. 3394 Neighbor Discovery protocol packet exchanges can be authenticated using 3395 the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an 3396 Authentication Header when sending Neighbor Discovery packets if a 3397 security association for use with the IP Authentication Header exists 3398 for the destination address. The security associations may have been 3399 created through manual configuration or through the operation of some 3400 key management protocol. 3402 Received Authentication Headers in Neighbor Discovery packets MUST be 3403 verified for correctness and packets with incorrect authentication MUST 3404 be ignored. 3406 It SHOULD be possible for the system administrator to configure a node 3407 to ignore any Neighbor Discovery messages that are not authenticated 3408 using either the Authentication Header or Encapsulating Security 3409 Payload. The configuration technique for this MUST be documented. Such 3410 a switch SHOULD default to allowing unauthenticated messages. 3412 Confidentiality issues are addressed by the IP Security Architecture and 3413 the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP]. 3415 REFERENCES 3417 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 3418 Work in Progress. 3420 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing 3421 Architecture", RFC 1884, January, 1996. 3423 [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 3424 Service", RFC 1546, November 1993. 3426 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 3427 RFC 826, November 1982. 3429 [HR-CL] R. Braden, Editor, "Requirements for Internet Hosts -- 3430 Communication Layers", STD 3, RFC 1122, October 1989. 3432 [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 3433 792, September 1981. 3435 [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol 3436 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 3437 1885, January 1996. 3439 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 3440 (IPv6) Specification", RFC 1883, January, 1996. 3442 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 3443 Packets over Ethernet Networks", Work in Progress. 3445 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 3446 Protocol". RFC 1825, August 1995. 3448 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 3449 August 1995. 3451 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 3452 RFC 1827, August 1995. 3454 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 3455 September 1991. 3457 [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture 3458 Extensions for Shared Media", RFC 1620, May 1994. 3460 [ASSIGNED] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 3461 October 1994. 3463 [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing 3464 Messages", IEEE/ACM Transactions on Networking, April 1994. 3465 ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z 3467 AUTHORS' ADDRESSES 3469 Erik Nordmark Thomas Narten 3470 Sun Microsystems, Inc. IBM Corporation 3471 2550 Garcia Ave P.O. Box 12195 3472 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 3473 USA USA 3475 phone: +1 415 336 2788 phone: +1 919 254 7798 3476 fax: +1 415 336 6015 fax: +1 919 254 4027 3477 email: nordmark@sun.com email: narten@vnet.ibm.com 3479 William Allen Simpson 3480 Daydreamer 3481 Computer Systems Consulting Services 3482 1384 Fontaine 3483 Madison Heights, Michigan 48071 3484 USA 3486 email: Bill.Simpson@um.cc.umich.edu 3487 bsimpson@MorningStar.com 3489 APPENDIX A: MULTIHOMED HOSTS 3491 There are a number of complicating issues that arise when Neighbor 3492 Discovery is used by hosts that have multiple interfaces. This section 3493 does not attempt to define the proper operation of multihomed hosts with 3494 regard to Neighbor Discovery. Rather, it identifies issues that require 3495 further study. Implementors are encouraged to experiment with various 3496 approaches to making Neighbor Discovery work on multihomed hosts and to 3497 report their experiences. 3499 If a multihomed host receives Router Advertisements on all of its 3500 interfaces, it will (probably) have learned on-link prefixes for the 3501 addresses residing on each link. When a packet must be sent through a 3502 router, however, selecting the "wrong" router can result in a suboptimal 3503 or non-functioning path. There are number of issues to consider: 3505 1) In order for a router to send a redirect, it must determine that 3506 the packet it is forwarding originates from a neighbor. The 3507 standard test for this case is to compare the source address of the 3508 packet to the list of on-link prefixes associated with the 3509 interface on which the packet was received. If the originating 3510 host is multihomed, however, the source address it uses may belong 3511 to an interface other than the interface from which it was sent. 3512 In such cases, a router will not send redirects, and suboptimal 3513 routing is likely. In order to be redirected, the sending host 3514 must always send packets out the interface corresponding to the 3515 outgoing packet's source address. Note that this issue never 3516 arises with non-multihomed hosts; they only have one interface. 3518 2) If the selected first-hop router does not have a route at all for 3519 the destination, it will be unable to deliver the packet. However, 3520 the destination may be reachable through a router on one of the 3521 other interfaces. Neighbor Discovery does not address this 3522 scenario; it does not arise in the non-multihomed case. 3524 3) Even if the first-hop router does have a route for a destination, 3525 there may be a better route via another interface. No mechanism 3526 exists for the multihomed host to detect this situation. 3528 If a multihomed host fails to receive Router Advertisements on one or 3529 more of its interfaces, it will not know (in the absence of configured 3530 information) which destinations are on-link on the affected 3531 interface(s). This leads to a number of problems: 3533 1) If no Router Advertisement is received on any interfaces, a 3534 multihomed host will have no way of knowing which interface to send 3535 packets out on, even for on-link destinations. Under similar 3536 conditions in the non-multihomed host case, a node treats all 3537 destinations as residing on-link, and communication proceeds. In 3538 the multihomed case, however, additional information is needed to 3539 select the proper outgoing interface. Alternatively, a node could 3540 attempt to perform address resolution on all interfaces, a step 3541 involving significant complexity that is not present in the non- 3542 multihomed host case. 3544 2) If Router Advertisements are received on some, but not all 3545 interfaces, a multihomed host could choose to only send packets out 3546 on the interfaces on which it has received Router Advertisements. 3547 A key assumption made here, however, is that routers on those other 3548 interfaces will be able to route packets to the ultimate 3549 destination, even when those destinations reside on the subnet to 3550 which the sender connects, but has no on-link prefix information. 3551 Should the assumption be false, communication would fail. Even if 3552 the assumption holds, packets will traverse a sub-optimal path. 3554 APPENDIX B: FUTURE EXTENSIONS 3556 Possible extensions for future study are: 3558 o Using dynamic timers to be able to adapt to links with widely varying 3559 delay. Measuring round trip times, however, requires acknowledgments 3560 and sequence numbers in order to match received Neighbor 3561 Advertisements with the actual Neighbor Solicitation that triggered 3562 the advertisement. Implementors wishing to experiment with such a 3563 facility could do so in a backwards-compatible way by defining a new 3564 option carrying the necessary information. Nodes not understanding 3565 the option would simply ignore it. 3567 o Adding capabilities to facilitate the operation over links that 3568 currently require hosts to register with an address resolution 3569 server. This could for instance enable routers to ask hosts to send 3570 them periodic unsolicited advertisements. Once again this can be 3571 added using a new option sent in the Router Advertisements. 3573 o Adding additional procedures for links where asymmetric and non- 3574 transitive reachability is part of normal operations. Such 3575 procedures might allow hosts and routers to find usable paths on, 3576 e.g., radio links. 3578 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE 3580 This appendix contains a summary of the rules specified in Sections 7.2 3581 and 7.3. This document does not mandate that implementations adhere to 3582 this model as long as their external behavior is consistent with that 3583 described in this document. 3585 When performing address resolution and Neighbor Unreachability Detection 3586 the following state transitions apply using the conceptual model: 3588 State Event Action New state 3590 - Packet to send. Create entry. INCOMPLETE 3591 Send multicast NS. 3592 Start retransmit timer 3594 INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE 3595 less than N Start retransmit timer 3596 retransmissions. 3598 INCOMPLETE Retransmit timeout, Discard entry - 3599 N or more Send ICMP error 3600 retransmissions. 3602 INCOMPLETE NA, Solicited=0, Record link-layer STALE 3603 Override=any address. 3605 INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3606 Override=any address. 3608 !INCOMPLETE NA, Solicited=1, - REACHABLE 3609 Override=0 3611 !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3612 Override=1 address. 3614 !INCOMPLETE NA, Solicited=0, - STALE 3615 Override=0 3617 !INCOMPLETE NA, Solicited=0, Record link-layer STALE 3618 Override=1 address. 3620 !INCOMPLETE upper-layer reachability - REACHABLE 3621 confirmation 3623 REACHABLE timeout, more than - STALE 3624 N seconds since 3625 reachability confirm. 3627 STALE Sending packet Start delay timer DELAY 3629 DELAY Delay timeout Send unicast NS probe PROBE 3630 Start retransmit timer 3632 PROBE Retransmit timeout, Retransmit NS PROBE 3633 less than N 3634 retransmissions. 3636 PROBE Retransmit timeout, Discard entry - 3637 N or more 3638 retransmissions. 3640 The state transitions for receiving unsolicited information other than 3641 Neighbor Advertisement messages apply to either the source of the packet 3642 (for Neighbor Solicitation, Router Solicitation, and Router 3643 Advertisement messages) or the target address (for Redirect messages) as 3644 follows: 3646 State Event Action New state 3648 - NS, RS, RA, Redirect Create entry. STALE 3650 !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE 3651 Different link-layer address 3652 address than cached. 3654 !INCOMPLETE NS, RS, RA, Redirect - unchanged 3655 Same link-layer 3656 address as cached. 3658 APPENDIX D: IMPLEMENTATION ISSUES 3660 Appendix D.1: Reachability confirmations 3662 Neighbor Unreachability Detection requires explicit confirmation that a 3663 forward-path is functioning properly. To avoid the need for Neighbor 3664 Solicitation probe messages, upper layer protocols should provide such 3665 an indication when the cost of doing so is small. Reliable connection- 3666 oriented protocols such as TCP are generally aware when the forward-path 3667 is working. When TCP sends (or receives) data, for instance, it updates 3668 its window sequence numbers, sets and cancels retransmit timers, etc. 3669 Specific scenarios that usually indicate a properly functioning 3670 forward-path include: 3672 - Receipt of an acknowledgement that covers a sequence number (e.g., 3673 data) not previously acknowledged indicates that the forward path was 3674 working at the time the data was sent. 3676 - Completion of the initial three-way handshake is a special case of the 3677 previous rule; although no data is sent during the handshake, the SYN 3678 flags are counted as data from the sequence number perspective. This 3679 applies to both the SYN+ACK for the active open the ACK of that 3680 packet on the passively opening peer. 3682 - Receipt of new data (i.e., data not previously received) indicates 3683 that the forward-path was working at the time an acknowledgement was 3684 sent that advanced the peer's send window that allowed the new data 3685 to be sent. 3687 To minimize the cost of communicating reachability information between 3688 the TCP and IP layers, an implementation may wish to rate-limit the 3689 reachability confirmations its sends IP. One possibility is to process 3690 reachability only every few packets. For example, one might update 3691 reachability information once per round trip time, if an implementation 3692 only has one round trip timer per connection. For those implementations 3693 that cache Destination Cache entries within control blocks, it may be 3694 possible to update the Neighbor Cache entry directly (i.e., without an 3695 expensive lookup) once the TCP packet has been demultiplexed to its 3696 corresponding control block. For other implementation it may be 3697 possible to piggyback the reachability confirmation on the next packet 3698 submitted to IP assuming that the implementation guards against the 3699 piggybacked confirmation becoming stale when no packets are sent to IP 3700 for an extended period of time. 3702 TCP must also guard against thinking "stale" information indicates 3703 current reachability. For example, new data received 30 minutes after a 3704 window has opened up does not constitute a confirmation that the path is 3705 currently working. In merely indicates that 30 minutes ago the window 3706 update reached the peer i.e. the patch was working at that point in 3707 time. An implementation must also take into account TCP zero-window 3708 probes that are sent even if the path is broken and the window update 3709 did not reach the peer. 3711 For UDP based applications (RPC, DNS) it is relatively simple to make 3712 the client send reachability confirmations when the response packet is 3713 received. It is more difficult and in some cases impossible for the 3714 server to generate such confirmations since there is no flow control, 3715 i.e., the server can not determine whether a received request indicates 3716 that a previous response reached the client. 3718 Note that an implementation can not use negative upper-layer advise as a 3719 replacement for the Neighbor Unreachability Detection algorithm. 3720 Negative advise (e.g. from TCP when there are excessive retransmissions) 3721 could serve as a hint that the forward path from the sender of the data 3722 might not be working. But it would fail to detect when the path from 3723 the receiver of the data is not functioning causing, none of the 3724 acknowledgement packets to reach the sender.