idnits 2.17.1 draft-ietf-ipngwg-discovery-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard 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 419: '... MUST have a link-local address. Also, [ADDRCONF]...' RFC 2119 keyword, line 438: '... MUST...' RFC 2119 keyword, line 442: '... MUST NOT...' RFC 2119 keyword, line 446: '... SHOULD...' RFC 2119 keyword, line 452: '... SHOULD NOT...' (207 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3710 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 3476, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 3492, 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 March 14, 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 September 14, 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.......................................... 8 49 2.3. Addresses........................................... 9 50 2.4. Requirements........................................ 10 52 3. PROTOCOL OVERVIEW........................................ 11 53 3.1. Comparison with IPv4................................ 15 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................ 22 60 4.4. Neighbor Advertisement Message Format............... 24 61 4.5. Redirect Message Format............................. 26 62 4.6. Option Formats...................................... 28 63 4.6.1. Source/Target Link-layer Address............... 29 64 4.6.2. Prefix Information............................. 30 65 4.6.3. Redirected Header.............................. 32 66 4.6.4. MTU............................................ 33 68 5. CONCEPTUAL MODEL OF A HOST............................... 34 69 5.1. Conceptual Data Structures.......................... 34 70 5.2. Conceptual Sending Algorithm........................ 36 71 5.3. Garbage Collection and Timeout Requirements......... 38 73 6. ROUTER AND PREFIX DISCOVERY.............................. 38 74 6.1. Message Validation.................................. 39 75 6.1.1. Validation of Router Solicitation Messages..... 39 76 6.1.2. Validation of Router Advertisement Messages.... 40 77 6.2. Router Specification................................ 40 78 6.2.1. Router Configuration Variables................. 41 79 6.2.2. Becoming An Advertising Interface.............. 44 80 6.2.3. Router Advertisement Message Content........... 45 81 6.2.4. Sending Unsolicited Router Advertisements...... 46 82 6.2.5. Ceasing To Be An Advertising Interface......... 47 83 6.2.6. Processing Router Solicitations................ 47 84 6.2.7. Router Advertisement Consistency............... 49 85 6.2.8. Link-local Address Change...................... 49 86 6.3. Host Specification.................................. 50 87 6.3.1. Host Configuration Variables................... 50 88 6.3.2. Host Variables................................. 50 89 6.3.3. Interface Initialization....................... 51 90 6.3.4. Processing Received Router Advertisements...... 51 91 6.3.5. Timing out Prefixes and Default Routers........ 54 92 6.3.6. Default Router Selection....................... 54 93 6.3.7. Sending Router Solicitations................... 55 95 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 56 96 7.1. Message Validation.................................. 57 97 7.1.1. Validation of Neighbor Solicitations........... 57 98 7.1.2. Validation of Neighbor Advertisements.......... 57 99 7.2. Address Resolution.................................. 58 100 7.2.1. Interface Initialization....................... 58 101 7.2.2. Sending Neighbor Solicitations................. 59 102 7.2.3. Receipt of Neighbor Solicitations.............. 60 103 7.2.4. Sending Solicited Neighbor Advertisements...... 60 104 7.2.5. Receipt of Neighbor Advertisements............. 61 105 7.2.6. Sending Unsolicited Neighbor Advertisements.... 62 106 7.2.7. Anycast Neighbor Advertisements................ 63 107 7.2.8. Proxy Neighbor Advertisements.................. 64 108 7.3. Neighbor Unreachability Detection................... 64 109 7.3.1. Reachability Confirmation...................... 65 110 7.3.2. Neighbor Cache Entry States.................... 66 111 7.3.3. Node Behavior.................................. 67 113 8. REDIRECT FUNCTION........................................ 69 114 8.1. Validation of Redirect Messages..................... 69 115 8.2. Router Specification................................ 70 116 8.3. Host Specification.................................. 71 118 9. EXTENSIBILITY - OPTION PROCESSING........................ 72 120 10. PROTOCOL CONSTANTS...................................... 74 122 11. SECURITY CONSIDERATIONS................................. 75 124 REFERENCES................................................... 77 126 AUTHORS' ADDRESSES........................................... 78 128 APPENDIX A: MULTIHOMED HOSTS................................. 79 130 APPENDIX B: FUTURE EXTENSIONS................................ 80 132 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 81 134 APPENDIX D: IMPLEMENTATION ISSUES............................ 83 135 Appendix D.1: Reachability confirmations.................. 83 137 1. INTRODUCTION 139 This specification defines the Neighbor Discovery (ND) protocol for 140 Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use 141 Neighbor Discovery to determine the link-layer addresses for neighbors 142 known to reside on attached links and to quickly purge cached values 143 that become invalid. Hosts also use Neighbor Discovery to find 144 neighboring routers that are willing to forward packets on their behalf. 145 Finally, nodes use the protocol to actively keep track of which 146 neighbors are reachable and which are not, and to detect changed link- 147 layer addresses. When a router or the path to a router fails, a host 148 actively searches for functioning alternates. 150 Unless specified otherwise (in a document that covers operating IP over 151 a particular link type) this document applies to all link types. 152 However, because ND uses link-layer multicast for some of its services, 153 it is possible that on some link types (e.g., NBMA links) alternative 154 protocols or mechanisms to implement those services will be specified 155 (in the appropriate document covering the operation of IP over a 156 particular link type). The services described in this document that are 157 not directly dependent on multicast, such as Redirects, Next-hop 158 determination, Neighbor Unreachability Detection, etc., are expected to 159 be provided as specified in this document. The details of how one uses 160 ND on NBMA links is an area for further study. 162 The authors would like to acknowledge the contributions the IPNGWG 163 working group and, in particular, (in alphabetical order) Ran Atkinson, 164 Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Francis Dupont, 165 Robert Elz, Robert Gilligan, Robert Hinden, Allison Mankin, Dan 166 McDonald, Charles Perkins, Matt Thomas, and Susan Thomson. 168 2. TERMINOLOGY 170 2.1. General 172 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 173 are used only in contexts where necessary to avoid 174 ambiguity. 176 ICMP - Internet Message Control Protocol for the Internet 177 Protocol Version 6. The terms ICMPv4 and ICMPv6 are 178 used only in contexts where necessary to avoid 179 ambiguity. 181 node - a device that implements IP. 183 router - a node that forwards IP packets not explicitly 184 addressed to itself. 186 host - any node that is not a router. 188 upper layer - a protocol layer immediately above IP. Examples are 189 transport protocols such as TCP and UDP, control 190 protocols such as ICMP, routing protocols such as OSPF, 191 and internet or lower-layer protocols being "tunneled" 192 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 193 or IP itself. 195 link - a communication facility or medium over which nodes can 196 communicate at the link layer, i.e., the layer 197 immediately below IP. Examples are Ethernets (simple 198 or bridged), PPP links, X.25, Frame Relay, or ATM 199 networks as well as internet (or higher) layer 200 "tunnels", such as tunnels over IPv4 or IPv6 itself. 202 interface - a node's attachment to a link. 204 neighbors - nodes attached to the same link. 206 address - an IP-layer identifier for an interface or a set of 207 interfaces. 209 anycast address 210 - an identifier for a set of interfaces (typically 211 belonging to different nodes). A packet sent to an 212 anycast address is delivered to one of the interfaces 213 identified by that address (the "nearest" one, 214 according to the routing protocol's measure of 215 distance). See [ADDR-ARCH]. 217 Note that an anycast address is syntactically 218 indistinguishable from a unicast address. Thus, nodes 219 sending packets to anycast addresses don't generally 220 know that an anycast address is being used. Throughout 221 the rest of this document, references to unicast 222 addresses also apply to anycast addresses in those 223 cases where the node is unaware that a unicast address 224 is actually an anycast address. 226 prefix - a bit string that consists of some number of initial 227 bits of an address. 229 link-layer address 230 - a link-layer identifier for an interface. Examples 231 include IEEE 802 addresses for Ethernet links and E.164 232 addresses for ISDN links. 234 on-link - an address that is assigned to an interface on a 235 specified link. A node considers an address to be on- 236 link if: 238 - it is covered by one of the link's prefixes, or 240 - a neighboring router specifies the address as the 241 target of a Redirect message, or 243 - a Neighbor Advertisement message is received for 244 the (target) address, or 246 - any Neighbor Discovery message is received from the 247 address. 249 off-link - the opposite of "on-link"; an address that is not 250 assigned to any interfaces on the specified link. 252 longest prefix match 253 - The process of determining which prefix (if any) in a 254 set of prefixes covers a target address. A target 255 address is covered by a prefix if all of the bits in 256 the prefix match the left-most bits of the target 257 address. When multiple prefixes cover an address, the 258 longest prefix is the one that matches. 260 reachability 261 - whether or not the one-way "forward" path to a neighbor 262 is functioning properly. In particular, whether 263 packets sent to a neighbor are reaching the IP layer on 264 the neighboring machine and are being processed 265 properly by the receiving IP layer. For neighboring 266 routers, reachability means that packets sent by a 267 node's IP layer are delivered to the router's IP layer, 268 and the router is indeed forwarding packets (i.e., it 269 is configured as a router, not a host). For hosts, 270 reachability means that packets sent by a node's IP 271 layer are delivered to the neighbor host's IP layer. 273 packet - an IP header plus payload. 275 link MTU - the maximum transmission unit, i.e., maximum packet 276 size in octets, that can be conveyed in one piece over 277 a link. 279 target - an address about which address resolution information 280 is sought, or an address which is the new first-hop 281 when being redirected. 283 proxy - a router that responds to Neighbor Discovery query 284 messages on behalf of another node. A router acting on 285 behalf of a mobile node that has moved off-link could 286 potentially act as a proxy for the mobile node. 288 ICMP destination unreachable indication 289 - an error indication returned to the original sender of 290 a packet that cannot be delivered for the reasons 291 outlined in [ICMPv6]. If the error occurs on a node 292 other than the node originating the packet, an ICMP 293 error message is generated. If the error occurs on the 294 originating node, an implementation is not required to 295 actually create and send an ICMP error packet to the 296 source, as long as the upper-layer sender is notified 297 through an appropriate mechanism (e.g., return value 298 from a procedure call). Note, however, that an 299 implementation may find it convenient in some cases to 300 return errors to the sender by taking the offending 301 packet, generating an ICMP error message, and then 302 delivering it (locally) through the generic error 303 handling routines. 305 random delay 306 - when sending out messages, it is sometimes necessary to 307 delay a transmission for a random amount of time in 308 order to prevent multiple nodes from transmitting at 309 exactly the same time, or to prevent long-range 310 periodic transmissions from synchronizing with each 311 other [SYNC]. When a random component is required, a 312 node calculates the actual delay in such a way that the 313 computed delay forms a uniformly-distributed random 314 value that falls between the specified minimum and 315 maximum delay times. The implementor must take care to 316 insure that the granularity of the calculated random 317 component and the resolution of the timer used are both 318 high enough to insure that the probability of multiple 319 nodes delaying the same amount of time is small. 321 random delay seed 322 - If a pseudo-random number generator is used in 323 calculating a random delay component, the generator 324 should be initialized with a unique seed prior to being 325 used. Note that it is not sufficient to use the 326 interface token alone as the seed, since interface 327 tokens will not always be unique. To reduce the 328 probability that duplicate interface tokens cause the 329 same seed to be used, the seed should be calculated 330 from a variety of input sources (e.g., machine 331 components) that are likely to be different even on 332 identical "boxes". For example, the seed could be 333 formed by combining the CPU's serial number with an 334 interface token. 336 2.2. Link Types 338 Different link layers have different properties. The ones of concern to 339 Neighbor Discovery are: 341 multicast - a link that supports a native mechanism at the link 342 layer for sending packets to all (i.e., broadcast) 343 or a subset of all neighbors. 345 point-to-point - a link that connects exactly two interfaces. A 346 point-to-point link is assumed to have multicast 347 capability and have a link-local address. 349 non-broadcast multi-access (NBMA) 350 - a link to which more than two interfaces can attach, 351 but that does not support a native form of multicast 352 or broadcast (e.g., X.25, ATM, frame relay, etc.). 353 Note that all link types (including NBMA) are 354 expected to provide multicast service for IP (e.g., 355 using multicast servers), but it is an issue for 356 further study whether ND should use such facilities 357 or an alternate mechanism that provides the 358 equivalent ND services. 360 shared media - a link that allows direct communication among a 361 number of nodes, but attached nodes are configured 362 in such a way that they do not have complete prefix 363 information for all on-link destinations. That is, 364 at the IP level, nodes on the same link may not know 365 that they are neighbors; by default, they 366 communicate through a router. Examples are large 367 (switched) public data networks such as SMDS and B- 368 ISDN. Also known as "large clouds". See [SH- 369 MEDIA]. 371 variable MTU - a link that does not have a well-defined MTU (e.g., 372 IEEE 802.5 token rings). Many links (e.g., 373 Ethernet) have a standard MTU defined by the link- 374 layer protocol or by the specific document 375 describing how to run IP over the link layer. 377 asymmetric reachability 378 - a link where non-reflexive and/or non-transitive 379 reachability is part of normal operation. (Non- 380 reflexive reachability means packets from A reach B 381 but packets from B don't reach A. Non-transitive 382 reachability means packets from A reach B, and 383 packets from B reach C, but packets from A don't 384 reach C.) Many radio links exhibit these 385 properties. 387 2.3. Addresses 389 Neighbor Discovery makes use of a number of different addresses defined 390 in [ADDR-ARCH], including: 392 all-nodes multicast address 393 - the link-local scope address to reach all nodes. 394 FF02::1 396 all-routers multicast address 397 - the link-local scope address to reach all routers. 398 FF02::2 400 solicited-node multicast address 401 - a link-local scope multicast address that is computed 402 as a function of the solicited target's address. The 403 solicited-node multicast address is formed by taking 404 the low-order 32 bits of the target IP address and 405 appending those bits to the 96-bit prefix 406 FF02:0:0:0:0:1 to produce a multicast address within 407 the range FF02::1:0:0 to FF02::1:FFFF:FFFF. For 408 example, the solicited node multicast address 409 corresponding to the IP address 4037::01:800:200E:8C6C 410 is FF02::1:200E:8C6C. IP addresses that differ only in 411 the high-order bits, e.g., due to multiple high-order 412 prefixes associated with different providers, will map 413 to the same solicited-node address thereby reducing the 414 number of multicast addresses a node must join. 416 link-local address 417 - a unicast address having link-only scope that can be 418 used to reach neighbors. All interfaces on routers 419 MUST have a link-local address. Also, [ADDRCONF] 420 requires that interfaces on hosts have a link-local 421 address. 423 unspecified address 424 - a reserved address value that indicates the lack of an 425 address (e.g., the address is unknown). It is never 426 used as a destination address, but may be used as a 427 source address if the sender does not (yet) know its 428 own address (e.g., while verifying an address is unused 429 during address autoconfiguration [ADDRCONF]). The 430 unspecified address has a value of 0:0:0:0:0:0:0:0. 432 2.4. Requirements 434 Throughout this document, the words that are used to define the 435 significance of the particular requirements are capitalized. These 436 words are: 438 MUST 439 This word or the adjective "REQUIRED" means that the item is an 440 absolute requirement of this specification. 442 MUST NOT 443 This phrase means the item is an absolute prohibition of this 444 specification. 446 SHOULD 447 This word or the adjective "RECOMMENDED" means that there may 448 exist valid reasons in particular circumstances to ignore this 449 item, but the full implications should be understood and the 450 case carefully weighed before choosing a different course. 452 SHOULD NOT 453 This phrase means that there may exist valid reasons in 454 particular circumstances when the listed behavior is acceptable 455 or even useful, but the full implications should be understood 456 and the case carefully weighted before implementing any behavior 457 described with this label. 459 MAY This word or the adjective "OPTIONAL" means that this item is 460 truly optional. One vendor may choose to include the item 461 because a particular marketplace requires it or because it 462 enhances the product, for example, another vendor may omit the 463 same item. 465 This document also makes use of internal conceptual variables to 466 describe protocol behavior and external variables that an implementation 467 must allow system administrators to change. The specific variable 468 names, how their values change, and how their settings influence 469 protocol behavior are provided to demonstrate protocol behavior. An 470 implementation is not required to have them in the exact form described 471 here, so long as its external behavior is consistent with that described 472 in this document. 474 3. PROTOCOL OVERVIEW 476 This protocol solves a set of problems related to the interaction 477 between nodes attached to the same link. It defines mechanisms for 478 solving each of the following problems: 480 Router Discovery: How hosts locate routers that reside on an 481 attached link. 483 Prefix Discovery: How hosts discover the set of address prefixes 484 that define which destinations are on-link for an 485 attached link. (Nodes use prefixes to distinguish 486 destinations that reside on-link from those only 487 reachable through a router.) 489 Parameter Discovery: How a node learns such link parameters as the 490 link MTU or such Internet parameters as the hop limit 491 value to place in outgoing packets. 493 Address Autoconfiguration: How nodes automatically configure an 494 address for an interface. 496 Address resolution: How nodes determine the link-layer address of an 497 on-link destination (e.g., a neighbor) given only the 498 destination's IP address. 500 Next-hop determination: The algorithm for mapping an IP destination 501 address into the IP address of the neighbor to which 502 traffic for the destination should be sent. The next-hop 503 can be a router or the destination itself. 505 Neighbor Unreachability Detection: How nodes determine that a 506 neighbor is no longer reachable. For neighbors used as 507 routers, alternate default routers can be tried. For 508 both routers and hosts, address resolution can be 509 performed again. 511 Duplicate Address Detection: How a node determines that an address 512 it wishes to use is not already in use by another node. 514 Redirect: How a router informs a host of a better first-hop node to 515 reach a particular destination. 517 Neighbor Discovery defines five different ICMP packet types: A pair of 518 Router Solicitation and Router Advertisement messages, a pair of 519 Neighbor Solicitation and Neighbor Advertisements messages, and a 520 Redirect message. The messages serve the following purpose: 522 Router Solicitation: When an interface becomes enabled, hosts may 523 send out Router Solicitations that request routers to 524 generate Router Advertisements immediately rather than at 525 their next scheduled time. 527 Router Advertisement: Routers advertise their presence together with 528 various link and Internet parameters either periodically, 529 or in response to a Router Solicitation message. Router 530 Advertisements contain prefixes that are used for on-link 531 determination and/or address configuration, a suggested 532 hop limit value, etc. 534 Neighbor Solicitation: Sent by a node to determine the link-layer 535 address of a neighbor, or to verify that a neighbor is 536 still reachable via a cached link-layer address. 537 Neighbor Solicitations are also used for Duplicate 538 Address Detection. 540 Neighbor Advertisement: A response to a Neighbor Solicitation 541 message. A node may also send unsolicited Neighbor 542 Advertisements to announce a link-layer address change. 544 Redirect: Used by routers to inform hosts of a better first hop for 545 a destination. 547 On multicast-capable links, each router periodically multicasts a Router 548 Advertisement packet announcing its availability. A host receives 549 Router Advertisements from all routers, building a list of default 550 routers. Routers generate Router Advertisements frequently enough that 551 hosts will learn of their presence within a few minutes, but not 552 frequently enough to rely on an absence of advertisements to detect 553 router failure; a separate Neighbor Unreachability Detection algorithm 554 provides failure detection. 556 Router Advertisements contain a list of prefixes used for on-link 557 determination and/or autonomous address configuration; flags associated 558 with the prefixes specify the intended uses of a particular prefix. 559 Hosts use the advertised on-link prefixes to build and maintain a list 560 that is used in deciding when a packet's destination is on-link or 561 beyond a router. Note that a destination can be on-link even though it 562 is not covered by any advertised on-link prefix. In such cases a router 563 can send a Redirect informing the sender that the destination is a 564 neighbor. 566 Router Advertisements (and per-prefix flags) allow routers to inform 567 hosts how to perform Address Autoconfiguration. For example, routers 568 can specify whether hosts should use stateful (DHCPv6) and/or autonomous 569 (stateless) address configuration. The exact semantics and usage of the 570 address configuration-related information is specified in [ADDRCONF]. 572 Router Advertisement messages also contain Internet parameters such as 573 the hop limit that hosts should use in outgoing packets and, optionally, 574 link parameters such as the link MTU. This facilitates centralized 575 administration of critical parameters that can be set on routers and 576 automatically propagated to all attached hosts. 578 Nodes accomplish address resolution by multicasting a Neighbor 579 Solicitation that asks the target node to return its link-layer address. 580 Neighbor Solicitation messages are multicast to the solicited-node 581 multicast address of the target address. The target returns its link- 582 layer address in a unicast Neighbor Advertisement message. A single 583 request-response pair of packets is sufficient for both the initiator 584 and the target to resolve each other's link-layer addresses; the 585 initiator includes its link-layer address in the Neighbor Solicitation. 587 Neighbor Solicitation messages can also be used to determine if more 588 than one node has been assigned the same unicast address. The use of 589 Neighbor Solicitation messages for Duplicate Address Detection is 590 specified in [ADDRCONF]. 592 Neighbor Unreachability Detection detects the failure of a neighbor or 593 the failure of the forward path to the neighbor. Doing so requires 594 positive confirmation that packets sent to a neighbor are actually 595 reaching that neighbor and being processed properly by its IP layer. 596 Neighbor Unreachability Detection uses confirmation from two sources. 597 When possible, upper-layer protocols provide a positive confirmation 598 that a connection is making "forward progress", that is, previously sent 599 data is known to have been delivered correctly (e.g., new 600 acknowledgments were received recently). When positive confirmation is 601 not forthcoming through such "hints", a node sends unicast Neighbor 602 Solicitation messages that solicit Neighbor Advertisements as 603 reachability confirmation from the next hop. To reduce unnecessary 604 network traffic, probe messages are only sent to neighbors to which the 605 node is actively sending packets. 607 In addition to addressing the above general problems, Neighbor Discovery 608 also handles the following situations: 610 Link-layer address change - A node that knows its link-layer 611 address has changed can multicast a few (unsolicited) Neighbor 612 Advertisement packets to all nodes to quickly update cached 613 link-layer addresses that have become invalid. Note that the 614 sending of unsolicited advertisements is a performance 615 enhancement only (e.g., unreliable). The Neighbor 616 Unreachability Detection algorithm ensures that all nodes will 617 reliably discover the new address, though the delay may be 618 somewhat longer. 620 Inbound load balancing - Nodes with replicated interfaces may want 621 to load balance the reception of incoming packets across 622 multiple network interfaces on the same link. Such nodes have 623 multiple link-layer addresses assigned to the same interface. 624 For example, a single network driver could represent multiple 625 network interface cards as a single logical interface having 626 multiple link-layer addresses. Load balancing is handled by 627 allowing routers to omit the source link-layer address from 628 Router Advertisement packets, thereby forcing neighbors to use 629 Neighbor Solicitation messages to learn link-layer addresses 630 of routers. Returned Neighbor Advertisement messages can then 631 contain link-layer addresses that differ depending on who 632 issued the solicitation. 634 Anycast addresses - Anycast addresses identify one of a set of 635 nodes providing an equivalent service, and multiple nodes on 636 the same link may be configured to recognize the same Anycast 637 address. Neighbor Discovery handles anycasts by having nodes 638 expect to receive multiple Neighbor Advertisements for the 639 same target. All advertisements for anycast addresses are 640 tagged as being non-Override advertisements. This invokes 641 specific rules to determine which of potentially multiple 642 advertisements should be used. 644 Proxy advertisements - A router willing to accept packets on behalf 645 of a target address that is unable to respond to Neighbor 646 Solicitations can issue non-Override Neighbor Advertisements. 647 There is currently no specified use of proxy, but proxy 648 advertising could potentially be used to handle cases like 649 mobile nodes that have moved off-link. However, it is not 650 intended as a general mechanism to handle nodes that, e.g., do 651 not implement this protocol. 653 3.1. Comparison with IPv4 655 The IPv6 Neighbor Discovery protocol corresponds to a combination of the 656 IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP 657 Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol 658 or mechanism for Neighbor Unreachability Detection, although Hosts 659 Requirements [HR-CL] does specify some possible algorithms for Dead 660 Gateway Detection (a subset of the problems Neighbor Unreachability 661 Detection tackles). 663 The Neighbor Discovery protocol provides a multitude of improvements 664 over the IPv4 set of protocols: 666 Router Discovery is part of the base protocol set; there is no need 667 for hosts to "snoop" the routing protocols. 669 Router advertisements carry link-layer addresses; no additional 670 packet exchange is needed to resolve the router's link-layer 671 address. 673 Router advertisements carry prefixes for a link; there is no need 674 to have a separate mechanism to configure the "netmask". 676 Router advertisements enable Address Autoconfiguration. 678 Routers can advertise an MTU for hosts to use on the link, ensuring 679 that all nodes use the same MTU value on links lacking a well- 680 defined MTU. 682 Address resolution multicasts are "spread" over 4 billion (2^32) 683 multicast addresses greatly reducing address resolution related 684 interrupts on nodes other than the target. Moreover, non-IPv6 685 machines should not be interrupted at all. 687 Redirects contain the link-layer address of the new first hop; 688 separate address resolution is not needed upon receiving a 689 redirect. 691 Multiple prefixes can be associated with the same link. By 692 default, hosts learn all on-link prefixes from Router 693 Advertisements. However, routers may be configured to omit some or 694 all prefixes from Router Advertisements. In such cases hosts 695 assume that destinations are off-link and send traffic to routers. 697 A router can then issue redirects as appropriate. 699 Unlike IPv4, the recipient of an IPv6 redirect assumes that the new 700 next-hop is on-link. In IPv4, a host ignores redirects specifying 701 a next-hop that is not on-link according to the link's network 702 mask. The IPv6 redirect mechanism is analogous to the XRedirect 703 facility specified in [SH-MEDIA]. It is expected to be useful on 704 non-broadcast and shared media links in which it is undesirable or 705 not possible for nodes to know all prefixes for on-link 706 destinations. 708 Neighbor Unreachability Detection is part of the base significantly 709 improving the robustness of packet delivery in the presence of 710 failing routers, partially failing or partitioned links and nodes 711 that change their link-layer addresses. For instance, mobile nodes 712 can move off-link without losing any connectivity due to stale ARP 713 caches. 715 Unlike ARP, Neighbor Discovery detects half-link failures (using 716 Neighbor Unreachability Detection) and avoids sending traffic to 717 neighbors with which two-way connectivity is absent. 719 Unlike in IPv4 Router Discovery the Router Advertisement messages 720 do not contain a preference field. The preference field is not 721 needed to handle routers of different "stability"; the Neighbor 722 Unreachability Detection will detect dead routers and switch to a 723 working one. 725 The use of link-local addresses to uniquely identify routers (for 726 Router Advertisement and Redirect messages) makes it possible for 727 hosts to maintain the router associations in the event of the site 728 renumbering to use new global prefixes. 730 Using the Hop Limit equal to 255 trick Neighbor Discovery is immune 731 to off-link senders that accidentally or intentionally send ND 732 messages. In IPv4 off-link senders can send both ICMP Redirects 733 and Router Advertisement messages. 735 Placing address resolution at the ICMP layer makes the protocol 736 more media-independent than ARP and makes it possible to use 737 standard IP authentication and security mechanisms as appropriate 738 [IPv6-AUTH, IPv6-ESP]. 740 3.2. Supported Link Types 742 Neighbor Discovery supports links with different properties. In the 743 presence of certain properties only a subset of the ND protocol 744 mechanisms are fully specified in this document: 746 point-to-point - Neighbor Discovery handles such links just like 747 multicast links. (Multicast can be trivially 748 provided on point to point links, and interfaces can 749 be assigned link-local addresses.) Neighbor 750 Discovery should be implemented as described in this 751 document. 753 multicast - Neighbor Discovery should be implemented as 754 described in this document. 756 non-broadcast multiple access (NBMA) 757 - Redirect, Neighbor Unreachability Detection and 758 next-hop determination should be implemented as 759 described in this document. Address resolution, and 760 the mechanism for delivering Router Solicitations 761 and Advertisements on NBMA links is not specified in 762 this document. Note that if hosts support manual 763 configuration of a list of default routers, hosts 764 can dynamically acquire the link-layer addresses for 765 their neighbors from Redirect messages. 767 shared media - The Redirect message is modeled after the XRedirect 768 message in [SH-MEDIA] in order to simplify use of 769 the protocol on shared media links. 771 This specification does not address shared media 772 issues that only relate to routers, such as: 774 - How routers exchange reachability information on 775 a shared media link. 777 - How a router determines the link-layer address of 778 a host, which it needs to send redirect messages 779 to the host. 781 - How a router determines that it is the first-hop 782 router for a received packet. 784 The protocol is extensible (through the definition 785 of new options) so that other solutions might be 786 possible in the future. 788 variable MTU - Neighbor Discovery allows routers to specify a MTU 789 for the link, which all nodes then use. All nodes 790 on a link must use the same MTU (or Maximum Receive 791 Unit) in order for multicast to work properly. 792 Otherwise when multicasting a sender, which can not 793 know which nodes will receive the packet, could not 794 determine a minimum packet size all receivers can 795 process. 797 asymmetric reachability 798 - Neighbor Discovery detects the absence of symmetric 799 reachability; a node avoids paths to a neighbor with 800 which it does not have symmetric connectivity. 802 The Neighbor Unreachability Detection will typically 803 identify such half-links and the node will refrain 804 from using them. 806 The protocol can presumably be extended in the 807 future to find viable paths in environments that 808 lack reflexive and transitive connectivity. 810 4. MESSAGE FORMATS 812 4.1. Router Solicitation Message Format 814 Hosts send Router Solicitations in order to prompt routers to generate 815 Router Advertisements quickly. 817 0 1 2 3 818 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 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Type | Code | Checksum | 821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 822 | Reserved | 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 | Options ... 825 +-+-+-+-+-+-+-+-+-+-+-+- 827 IP Fields: 829 Source Address 830 An IP address assigned to the sending interface, or 831 the unspecified address if no address is assigned to 832 the sending interface. 834 Destination Address 835 Typically the all-routers multicast address. 837 Hop Limit 255 839 Priority 15 841 Authentication Header 842 If a Security Association for the IP Authentication 843 Header exists between the sender and the destination 844 address, then the sender SHOULD include this header. 846 ICMP Fields: 848 Type 133 850 Code 0 852 Checksum The ICMP checksum. See [ICMPv6]. 854 Reserved This field is unused. It MUST be initialized to zero 855 by the sender and MUST be ignored by the receiver. 857 Valid Options: 859 Source link-layer address 860 The link-layer address of the sender, if known. 862 Future versions of this protocol may define new option types. 863 Receivers MUST silently ignore any options they do not recognize and 864 continue processing the message. 866 4.2. Router Advertisement Message Format 868 Routers send out Router Advertisement message periodically, or in 869 response to a Router Solicitation. 871 0 1 2 3 872 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 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Type | Code | Checksum | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Reachable Time | 879 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 880 | Retrans Timer | 881 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 882 | Options ... 883 +-+-+-+-+-+-+-+-+-+-+-+- 885 IP Fields: 887 Source Address 888 MUST be the link-local address assigned to the 889 interface from which this message is sent. 891 Destination Address 892 Typically the Source Address of an invoking Router 893 Solicitation or the all-nodes multicast address. 895 Hop Limit 255 897 Priority 15 899 Authentication Header 900 If a Security Association for the IP Authentication 901 Header exists between the sender and the destination 902 address, then the sender SHOULD include this header. 904 ICMP Fields: 906 Type 134 908 Code 0 910 Checksum The ICMP checksum. See [ICMPv6]. 912 Cur Hop Limit 8-bit unsigned integer. The default value that should 913 be placed in the Hop Count field of the IP header for 914 outgoing IP packets. A value of zero means 915 unspecified (by this router). 917 M 1-bit "Managed address configuration" flag. When set, 918 hosts use the administered (stateful) protocol for 919 address autoconfiguration in addition to any addresses 920 autoconfigured using stateless address 921 autoconfiguration. The use of this flag is described 922 in [ADDRCONF]. 924 O 1-bit "Other stateful configuration" flag. When set, 925 hosts use the administered (stateful) protocol for 926 autoconfiguration of other (non-address) information. 927 The use of this flag is described in [ADDRCONF]. 929 Reserved A 6-bit unused field. It MUST be initialized to zero 930 by the sender and MUST be ignored by the receiver. 932 Router Lifetime 933 16-bit unsigned integer. The lifetime associated with 934 the default router in units of seconds. The maximum 935 value corresponds to 18.2 hours. A Lifetime of 0 936 indicates that the router is not a default router and 937 SHOULD NOT appear on the default router list. The 938 Router Lifetime applies only to the router's 939 usefulness as a default router; it does not apply to 940 information contained in other message fields or 941 options. Options that need time limits for their 942 information include their own lifetime fields. 944 Reachable Time 32-bit unsigned integer. The time, in milliseconds, 945 that a node assumes a neighbor is reachable after 946 having received a reachability confirmation. Used by 947 the Neighbor Unreachability Detection algorithm (see 948 Section 7.3). A value of zero means unspecified (by 949 this router). 951 Retrans Timer 32-bit unsigned integer. The time, in milliseconds, 952 between retransmitted Neighbor Solicitation messages. 953 Used by address resolution and the Neighbor 954 Unreachability Detection algorithm (see Sections 7.2 955 and 7.3). A value of zero means unspecified (by this 956 router). 958 Possible options: 960 Source link-layer address 961 The link-layer address of the interface from which the 962 Router Advertisement is sent. Only used on link 963 layers that have addresses. A router MAY omit this 964 option in order to enable inbound load sharing across 965 multiple link-layer addresses. 967 MTU SHOULD be sent on links that have a variable MTU (as 968 specified in the document that describes how to run IP 969 over the particular link type). MAY be sent on other 970 links. 972 Prefix Information 973 These options specify the prefixes that are on-link 974 and/or are used for address autoconfiguration. A 975 router SHOULD include all its on-link prefixes (except 976 the link-local prefix) so that multihomed hosts have 977 complete prefix information about on-link destinations 978 for the links to which they attach. If complete 979 information is lacking, a multihomed host may not be 980 able to chose the correct outgoing interface when 981 sending traffic to its neighbors. 983 Future versions of this protocol may define new option types. 984 Receivers MUST silently ignore any options they do not recognize and 985 continue processing the message. 987 4.3. Neighbor Solicitation Message Format 989 Nodes send Neighbor Solicitations to request the link-layer address of a 990 target node while also providing their own link-layer address to the 991 target. Neighbor Solicitations are multicast when the node needs to 992 resolve an address and unicast when the node seeks to verify the 993 reachability of a neighbor. 995 0 1 2 3 996 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 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | Type | Code | Checksum | 999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1000 | Reserved | 1001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1002 | | 1003 + + 1004 | | 1005 + Target Address + 1006 | | 1007 + + 1008 | | 1009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1010 | Options ... 1011 +-+-+-+-+-+-+-+-+-+-+-+- 1013 IP Fields: 1015 Source Address 1016 Either an address assigned to the interface from which 1017 this message is sent or (if Duplicate Address 1018 Detection is in progress [ADDRCONF]) the unspecified 1019 address. 1021 Destination Address 1022 Either the solicited-node multicast address 1023 corresponding to the target address, or the target 1024 address. 1026 Hop Limit 255 1028 Priority 15 1030 Authentication Header 1031 If a Security Association for the IP Authentication 1032 Header exists between the sender and the destination 1033 address, then the sender SHOULD include this header. 1035 ICMP Fields: 1037 Type 135 1039 Code 0 1041 Checksum The ICMP checksum. See [ICMPv6]. 1043 Reserved This field is unused. It MUST be initialized to zero 1044 by the sender and MUST be ignored by the receiver. 1046 Target Address 1047 The IP address of the target of the solicitation. It 1048 MUST NOT be a multicast address. 1050 Possible options: 1052 Source link-layer address 1053 The link-layer address for the sender. On link layers 1054 that have addresses this option MUST be included in 1055 multicast solicitations and SHOULD be included in 1056 unicast solicitations. 1058 Future versions of this protocol may define new option types. 1059 Receivers MUST silently ignore any options they do not recognize and 1060 continue processing the message. 1062 4.4. Neighbor Advertisement Message Format 1064 A node sends Neighbor Advertisements in response to Neighbor 1065 Solicitations and sends unsolicited Neighbor Advertisements in order to 1066 (unreliably) propagate new information quickly. 1068 0 1 2 3 1069 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 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | Type | Code | Checksum | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 |R|S|O| Reserved | 1074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1075 | | 1076 + + 1077 | | 1078 + Target Address + 1079 | | 1080 + + 1081 | | 1082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1083 | Options ... 1084 +-+-+-+-+-+-+-+-+-+-+-+- 1086 IP Fields: 1088 Source Address 1089 An address assigned to the interface from which the 1090 advertisement is sent. 1092 Destination Address 1093 For solicited advertisements, the Source Address of an 1094 invoking Neighbor Solicitation or, if the 1095 solicitation's Source Address is the unspecified 1096 address, the all-nodes multicast address. 1098 For unsolicited advertisements typically the all-nodes 1099 multicast address. 1101 Hop Limit 255 1103 Priority 15 1105 Authentication Header 1106 If a Security Association for the IP Authentication 1107 Header exists between the sender and the destination 1108 address, then the sender SHOULD include this header. 1110 ICMP Fields: 1112 Type 136 1114 Code 0 1116 Checksum The ICMP checksum. See [ICMPv6]. 1118 R Router flag. When set, the R-bit indicates that the 1119 sender is a router. The R-bit is used by Neighbor 1120 Unreachability Detection to detect a router that 1121 changes to a host. 1123 S Solicited flag. When set, the S-bit indicates that 1124 the advertisement was sent in response to a Neighbor 1125 Solicitation from the Destination address. The S-bit 1126 is used as a reachability confirmation for Neighbor 1127 Unreachability Detection. It MUST NOT be set in 1128 multicast advertisements or in unsolicited unicast 1129 advertisements. 1131 O Override flag. When set, the O-bit indicates that the 1132 advertisement should override an existing cache entry 1133 and update the cached link-layer address. When it is 1134 not set the advertisement will not update a cached 1135 link-layer address though it will update an existing 1136 Neighbor Cache entry for which no link-layer address 1137 is known. It SHOULD NOT be set in solicited 1138 advertisements for anycast addresses and in solicited 1139 proxy advertisements. It SHOULD be set in other 1140 solicited advertisements and in unsolicited 1141 advertisements. 1143 Reserved 29-bit unused field. It MUST be initialized to zero 1144 by the sender and MUST be ignored by the receiver. 1146 Target Address 1147 For solicited advertisements, the Target Address field 1148 in the Neighbor Solicitation message that prompted 1149 this advertisement. For an unsolicited advertisement, 1150 the address whose link-layer address has changed. The 1151 Target Address MUST NOT be a multicast address. 1153 Possible options: 1155 Target link-layer address 1156 The link-layer address for the target, i.e., the 1157 sender of the advertisement. MUST be included on link 1158 layers that have addresses. 1160 Future versions of this protocol may define new option types. 1161 Receivers MUST silently ignore any options they do not recognize and 1162 continue processing the message. 1164 4.5. Redirect Message Format 1166 Routers send Redirect packets to inform a host of a better first-hop 1167 node on the path to a destination. Hosts can be redirected to a better 1168 first-hop router but can also be informed by a redirect that the 1169 destination is in fact a neighbor. The latter is accomplished by 1170 setting the ICMP Target Address equal to the ICMP Destination Address. 1172 0 1 2 3 1173 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 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | Type | Code | Checksum | 1176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1177 | Reserved | 1178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1179 | | 1180 + + 1181 | | 1182 + Target Address + 1183 | | 1184 + + 1185 | | 1186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1187 | | 1188 + + 1189 | | 1190 + Destination Address + 1191 | | 1192 + + 1193 | | 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Options ... 1196 +-+-+-+-+-+-+-+-+-+-+-+- 1198 IP Fields: 1200 Source Address 1201 MUST be the link-local address assigned to the 1202 interface from which this message is sent. 1204 Destination Address 1205 The Source Address of the packet that triggered the 1206 redirect. 1208 Hop Limit 255 1210 Priority 15 1212 Authentication Header 1213 If a Security Association for the IP Authentication 1214 Header exists between the sender and the destination 1215 address, then the sender SHOULD include this header. 1217 ICMP Fields: 1219 Type 137 1220 Code 0 1222 Checksum The ICMP checksum. See [ICMPv6]. 1224 Reserved This field is unused. It MUST be initialized to zero 1225 by the sender and MUST be ignored by the receiver. 1227 Target Address An IP address that is a better first hop to use for 1228 the ICMP Destination Address. When the target is the 1229 actual endpoint of communication, i.e., the 1230 destination is a neighbor, the Target Address field 1231 MUST contain the same value as the ICMP Destination 1232 Address field. Otherwise the target is a better 1233 first-hop router and the Target Address MUST be the 1234 router's link-local address so that hosts can uniquely 1235 identify routers. 1237 Destination Address 1238 The IP address of the destination which is redirected 1239 to the target. 1241 Possible options: 1243 Target link-layer address 1244 The link-layer address for the target. It SHOULD be 1245 included (if known). Note that on NBMA links, hosts 1246 may rely on the presence of the Target Link-Layer 1247 Address option in Redirect messages as the means for 1248 determining the link-layer addresses of neighbors. In 1249 such cases, the option MUST be included in Redirect 1250 messages. 1252 Redirected Header 1253 As much as possible of the IP packet that triggered 1254 the sending of the Redirect without making the 1255 redirect packet exceed 576 octets. 1257 4.6. Option Formats 1259 Neighbor Discovery messages include zero or more options, some of which 1260 may appear multiple times in the same message. All options are of the 1261 form: 1263 0 1 2 3 1264 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 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Type | Length | ... | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 ~ ... ~ 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1271 Fields: 1273 Type 8-bit identifier of the type of option. The options 1274 defined in this document are: 1276 Option Name Type 1278 Source Link-Layer Address 1 1279 Target Link-Layer Address 2 1280 Prefix Information 3 1281 Redirected Header 4 1282 MTU 5 1284 Length 8-bit unsigned integer. The length of the option in 1285 units of 8 octets. The value 0 is invalid. Nodes 1286 MUST silently discard an ND packet that contains an 1287 option with length zero. 1289 4.6.1. Source/Target Link-layer Address 1291 0 1 2 3 1292 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 1293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1294 | Type | Length | Link-Layer Address ... 1295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1297 Fields: 1299 Type 1300 1 for Source Link-layer Address 1301 2 for Target Link-layer Address 1303 Length The length of the option in units of 8 octets. For 1304 example, the length for IEEE 802 addresses is 1 1305 [IPv6-ETHER]. 1307 Link-Layer Address 1308 The variable length link-layer address. 1310 The content and format of this field (including byte 1311 and bit ordering) is expected to be specified in 1312 specific documents that describe how IPv6 operates 1313 over different link layers. For instance, [IPv6- 1314 ETHER]. 1316 Description 1317 The Source Link-Layer Address option contains the 1318 link-layer address of the sender of the packet. It is 1319 used in the Neighbor Solicitation, Router 1320 Solicitation, and Router Advertisement packets. 1322 The Target Link-Layer Address option contains the 1323 link-layer address of the target. It is used in 1324 Neighbor Advertisement and Redirect packets. 1326 These options MUST be silently ignored for other 1327 Neighbor Discovery messages. 1329 4.6.2. Prefix Information 1331 0 1 2 3 1332 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 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Type | Length | Prefix Length |L|A| Reserved1 | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Valid Lifetime | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Preferred Lifetime | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Reserved2 | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | | 1343 + + 1344 | | 1345 + Prefix + 1346 | | 1347 + + 1348 | | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1351 Fields: 1353 Type 3 1354 Length 4 1356 Prefix Length 8-bit unsigned integer. The number of leading bits in 1357 the Prefix that are valid. The value ranges from 0 to 1358 128. 1360 L 1-bit on-link flag. When set, indicates that this 1361 prefix can be used for on-link determination. When 1362 not set the advertisement makes no statement about 1363 on-link or off-link properties of the prefix. For 1364 instance, the prefix might be used for address 1365 configuration with some of the addresses belonging to 1366 the prefix being on-link and others being off-link. 1368 A 1-bit autonomous address-configuration flag. When set 1369 indicates that this prefix can be used for autonomous 1370 address configuration as specified in [ADDRCONF]. 1372 Reserved1 6-bit unused field. It MUST be initialized to zero by 1373 the sender and MUST be ignored by the receiver. 1375 Valid Lifetime 1376 32-bit unsigned integer. The length of time in 1377 seconds (relative to the time the packet is sent) that 1378 the prefix is valid for the purpose of on-link 1379 determination. A value of all one bits (0xffffffff) 1380 represents infinity. The Valid Lifetime is also used 1381 by [ADDRCONF]. 1383 Preferred Lifetime 1384 32-bit unsigned integer. The length of time in 1385 seconds (relative to the time the packet is sent) that 1386 addresses generated from the prefix via stateless 1387 address autoconfiguration remain preferred [ADDRCONF]. 1388 A value of all one bits (0xffffffff) represents 1389 infinity. See [ADDRCONF]. 1391 Reserved2 This field is unused. It MUST be initialized to zero 1392 by the sender and MUST be ignored by the receiver. 1394 Prefix An IP address or a prefix of an IP address. The 1395 Prefix Length field contains the number of valid 1396 leading bits in the prefix. The bits in the prefix 1397 after the prefix length are reserved and MUST be 1398 initialized to zero by the sender and ignored by the 1399 receiver. A router SHOULD NOT send a prefix option 1400 for the link-local prefix and a host SHOULD ignore 1401 such a prefix option. 1403 Description 1404 The Prefix Information option provide hosts with on- 1405 link prefixes and prefixes for Address 1406 Autoconfiguration. 1408 The Prefix Information option appears in Router 1409 Advertisement packets and MUST be silently ignored for 1410 other messages. 1412 4.6.3. Redirected Header 1414 0 1 2 3 1415 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 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | Type | Length | Reserved | 1418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1419 | Reserved | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | | 1422 ~ IP header + data ~ 1423 | | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Fields: 1428 Type 4 1430 Length The length of the option in units of 8 octets. 1432 Reserved These fields are unused. They MUST be initialized to 1433 zero by the sender and MUST be ignored by the 1434 receiver. 1436 IP header + data 1437 The original packet truncated to ensure that the size 1438 of the redirect message does not exceed 576 octets. 1440 Description 1441 The Redirected Header option is used in Redirect 1442 messages and contains all or part of the packet that 1443 is being redirected. 1445 This option MUST be silently ignored for other 1446 Neighbor Discovery messages. 1448 4.6.4. MTU 1450 0 1 2 3 1451 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 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 | Type | Length | Reserved | 1454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1455 | MTU | 1456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1458 Fields: 1460 Type 5 1462 Length 1 1464 Reserved This field is unused. It MUST be initialized to zero 1465 by the sender and MUST be ignored by the receiver. 1467 MTU 32-bit unsigned integer. The recommended MTU for the 1468 link. 1470 Description 1471 The MTU option is used in Router Advertisement 1472 messages to insure that all nodes on a link use the 1473 same MTU value in those cases where the link MTU is 1474 not well known. 1476 This option MUST be silently ignored for other 1477 Neighbor Discovery messages. 1479 In configurations in which heterogeneous technologies 1480 are bridged together, the maximum supported MTU may 1481 differ from one segment to another. If the bridges do 1482 not generate ICMP Packet Too Big messages, 1483 communicating nodes will be unable to use Path MTU to 1484 dynamically determine the appropriate MTU on a per- 1485 neighbor basis. In such cases, routers use the MTU 1486 option to specify an MTU value supported by all 1487 segments. 1489 5. CONCEPTUAL MODEL OF A HOST 1491 This section describes a conceptual model of one possible data structure 1492 organization that hosts (and to some extent routers) will maintain in 1493 interacting with neighboring nodes. The described organization is 1494 provided to facilitate the explanation of how the Neighbor Discovery 1495 protocol should behave. This document does not mandate that 1496 implementations adhere to this model as long as their external behavior 1497 is consistent with that described in this document. 1499 This model is only concerned with the aspects of host behavior directly 1500 related to Neighbor Discovery. In particular, it does not concern 1501 itself with such issues as source address selection or the selecting of 1502 an outgoing interface on a multihomed host. 1504 5.1. Conceptual Data Structures 1506 Hosts will need to maintain the following pieces of information for each 1507 interface: 1509 Neighbor Cache 1510 - A set of entries about individual neighbors to which 1511 traffic has been sent recently. Entries are keyed on 1512 the neighbor's on-link unicast IP address and contain 1513 such information as its link-layer address, a flag 1514 indicating whether the neighbor is a router or a host 1515 (called IsRouter in this document), a pointer to any 1516 queued packets waiting for address resolution to 1517 complete, etc. 1519 A Neighbor Cache entry also contains information used 1520 by the Neighbor Unreachability Detection algorithm, 1521 including the reachability state, the number of 1522 unanswered probes, and the time the next Neighbor 1523 Unreachability Detection event is scheduled to take 1524 place. 1526 Destination Cache 1527 - A set of entries about destinations to which traffic 1528 has been sent recently. The Destination Cache 1529 includes both on-link and off-link destinations and 1530 provides a level of indirection into the Neighbor 1531 Cache; the Destination Cache maps a destination IP 1532 address to the IP address of the next-hop neighbor. 1533 This cache is updated with information learned from 1534 Redirect messages. Implementations may find it 1535 convenient to store additional information not 1536 directly related to Neighbor Discovery in Destination 1537 Cache entries, such as the Path MTU (PMTU) and round 1538 trip timers maintained by transport protocols. 1540 Prefix List - A list of the prefixes that define a set of addresses 1541 that are on-link. Prefix List entries are created 1542 from information received in Router Advertisements. 1543 Each entry has an associated invalidation timer value 1544 (extracted from the advertisement) used to expire 1545 prefixes when they become invalid. A special 1546 "infinity" timer value specifies that a prefix remains 1547 valid forever, unless a new (finite) value is received 1548 in a subsequent advertisement. 1550 The link-local prefix is considered to be on the 1551 prefix list with an infinite invalidation timer 1552 regardless of whether routers are advertising a prefix 1553 for it. Received Router Advertisements SHOULD NOT 1554 modify the invalidation timer for the link-local 1555 prefix. 1557 Default Router List 1558 - A list of routers to which packets may be sent. 1559 Router list entries point to entries in the Neighbor 1560 Cache; the algorithm for selecting a default router 1561 favors routers known to be reachable over those whose 1562 reachability is suspect. Each entry also has an 1563 associated invalidation timer value (extracted from 1564 Router Advertisements) used to delete entries that are 1565 no longer advertised. 1567 Note that the above conceptual data structures can be implemented using 1568 a variety of techniques. One possible implementation is to use a single 1569 longest-match routing table for all of the above data structures. 1570 Regardless of the specific implementation, it is critical that the 1571 Neighbor Cache entry for a router is shared by all Destination Cache 1572 entries using that router in order to prevent redundant Neighbor 1573 Unreachability Detection probes. 1575 Note also that other protocols (e.g. IPv6 Mobility) might add additional 1576 conceptual data structures. An implementation is at liberty to 1577 implement such data structures in any way it pleases. For example, an 1578 implementation could merge all conceptual data structures into a single 1579 routing table. 1581 The Neighbor Cache contains information maintained by the Neighbor 1582 Unreachability Detection algorithm. A key piece of information is a 1583 neighbor's reachability state, which is one of five possible values. 1585 The following definitions are informal; precise definitions can be found 1586 in Section 7.3.2. 1588 INCOMPLETE Address resolution is in progress and the link-layer 1589 address of the neighbor has not yet been determined. 1591 REACHABLE Roughly speaking, the neighbor is known to have been 1592 reachable recently (within tens of seconds ago). 1594 STALE The neighbor is no longer known to be reachable but until 1595 traffic is sent to the neighbor, no attempt should be 1596 made to verify its reachability. 1598 DELAY The neighbor is no longer known to be reachable, and 1599 traffic has recently be sent to the neighbor. Rather 1600 than probe the neighbor immediately, however, delay 1601 sending probes for a short while in order to give upper 1602 layer protocols a chance to provide reachability 1603 confirmation. 1605 PROBE The neighbor is no longer known to be reachable, and 1606 unicast Neighbor Solicitation probes are being sent to 1607 verify reachability. 1609 5.2. Conceptual Sending Algorithm 1611 When sending a packet to a destination, a node uses a combination of the 1612 Destination Cache, the Prefix List, and the Default Router List to 1613 determine the IP address of the appropriate next hop, an operation known 1614 as "next-hop determination". Once the IP address of the next hop is 1615 known, the Neighbor Cache is consulted for link-layer information about 1616 that neighbor. 1618 Next-hop determination for a given unicast destination operates as 1619 follows. The sender performs a longest prefix match against the Prefix 1620 List to determine whether the packet's destination is on- or off-link. 1621 If the destination is on-link, the next-hop address is the same as the 1622 packet's destination address. Otherwise, the sender selects a router 1623 from the Default Router List (following the rules described in Section 1624 6.3.6). If the Default Router List is empty, the sender assumes that 1625 the destination is on-link. 1627 For efficiency reasons, next-hop determination is not performed on every 1628 packet that is sent. Instead, the results of next-hop determination 1629 computations are saved in the Destination Cache (which also contains 1630 updates learned from Redirect messages). When the sending node has a 1631 packet to send, it first examines the Destination Cache. If no entry 1632 exists for the destination, next-hop determination is invoked to create 1633 a Destination Cache entry. 1635 Once the IP address of the next-hop node is known, the sender examines 1636 the Neighbor Cache for link-layer information about that neighbor. If 1637 no entry exists, the sender creates one, sets its state to INCOMPLETE, 1638 initiates Address Resolution, and then queues the data packet pending 1639 completion of address resolution. For multicast-capable interfaces 1640 Address Resolution consists of sending a Neighbor Solicitation message 1641 and waiting for a Neighbor Advertisement. When a Neighbor Advertisement 1642 response is received, the link-layer addresses is entered in the 1643 Neighbor Cache entry and the queued packet is transmitted. The address 1644 resolution mechanism is described in detail in Section 7.2. 1646 For multicast packets the next-hop is always the (multicast) destination 1647 address and is considered to be on-link. The procedure for determining 1648 the link-layer address corresponding to a given IP multicast address can 1649 be found in a separate document that covers operating IP over a 1650 particular link type (e.g., [IPv6-ETHER]). 1652 Each time a Neighbor Cache entry is accessed while transmitting a 1653 unicast packet, the sender checks Neighbor Unreachability Detection 1654 related information according to the Neighbor Unreachability Detection 1655 algorithm (Section 7.3). This unreachability check might result in the 1656 sender transmitting a unicast Neighbor Solicitation to verify that the 1657 neighbor is still reachable. 1659 Next-hop determination is done the first time traffic is sent to a 1660 destination. As long as subsequent communication to that destination 1661 proceeds successfully, the Destination Cache entry continues to be used. 1662 If at some point communication ceases to proceed, as determined by the 1663 Neighbor Unreachability Detection algorithm, next-hop determination may 1664 need to be performed again. For example, traffic through a failed 1665 router should be switched to a working router. Likewise, it may be 1666 possible to reroute traffic destined for a mobile node to a "mobility 1667 agent". 1669 Note that when a node redoes next-hop determination there is no need to 1670 discard the complete Destination Cache entry. In fact, it is generally 1671 beneficial to retain such cached information as the PMTU and round trip 1672 timer values that may also be kept in the Destination Cache entry. 1674 Routers and multihomed hosts have multiple interfaces. The remainder of 1675 this document assumes that all sent and received Neighbor Discovery 1676 messages refer to the interface of appropriate context. For example, 1677 when responding to a Router Solicitation, the corresponding Router 1678 Advertisement is sent out the interface on which the solicitation was 1679 received. 1681 5.3. Garbage Collection and Timeout Requirements 1683 The conceptual data structures described above use different mechanisms 1684 for discarding potentially stale or unused information. 1686 From the perspective of correctness there is no need to periodically 1687 purge Destination and Neighbor Cache entries. Although stale 1688 information can potentially remain in the cache indefinitely, the 1689 Neighbor Unreachability Detection algorithm ensures that stale 1690 information is purged quickly if it is actually being used. 1692 To limit the storage needed for the Destination and Neighbor Caches, a 1693 node may need to garbage-collect old entries. However, care must be 1694 taken to insure that sufficient space is always present to hold the 1695 working set of active entries. A small cache may result in an excessive 1696 number of Neighbor Discovery messages if entries are discarded and 1697 rebuilt in quick succession. Any LRU-based policy that only reclaims 1698 entries that have not been used in some time (e.g., ten minutes or more) 1699 should be adequate for garbage-collecting unused entries. 1701 A node should retain entries in the Default Router List and the Prefix 1702 List until their lifetimes expire. However, a node may garbage collect 1703 entries prematurely if it is low on memory. If not all routers are kept 1704 on the Default Router list, a node should retain at least two entries in 1705 the Default Router List (and preferably more) in order to maintain 1706 robust connectivity for off-link destinations. 1708 When removing an entry from the Prefix List there is no need to purge 1709 any entries from the Destination or Neighbor Caches. Neighbor 1710 Unreachability Detection will efficiently purge any entries in these 1711 caches that have become invalid. When removing an entry from the 1712 Default Router List, however, any entries in the Destination Cache that 1713 go through that router must perform next-hop determination again to 1714 select a new default router. 1716 6. ROUTER AND PREFIX DISCOVERY 1718 This section describes router and host behavior related to the Router 1719 Discovery portion of Neighbor Discovery. Router Discovery is used to 1720 locate neighboring routers as well as learn prefixes and configuration 1721 parameters related to address autoconfiguration. 1723 Prefix Discovery is the process through which hosts learn the ranges of 1724 IP addresses that reside on-link and can be reached directly without 1725 going through a router. Routers send Router Advertisements that 1726 indicate whether the sender is willing to be a default router. Router 1727 Advertisements also contain Prefix Information options that list the set 1728 of prefixes that identify on-link IP addresses. 1730 Stateless Address Autoconfiguration must also obtain subnet prefixes as 1731 part of configuring addresses. Although the prefixes used for address 1732 autoconfiguration are logically distinct from those used for on-link 1733 determination, autoconfiguration information is piggybacked on Router 1734 Discovery messages to reduce network traffic. Indeed, the same prefixes 1735 can be advertised for on-link determination and address 1736 autoconfiguration by specifying the appropriate flags in the Prefix 1737 Information options. See [ADDRCONF] for details on how 1738 autoconfiguration information is processed. 1740 6.1. Message Validation 1742 6.1.1. Validation of Router Solicitation Messages 1744 Hosts MUST silently discard any received Router Solicitation Messages. 1746 A router MUST silently discard any received Router Solicitation messages 1747 that do not satisfy all of the following validity checks: 1749 - The IP Hop Limit field has a value of 255, i.e., the packet could 1750 not possibly have been forwarded by a router. 1752 - If the message includes an IP Authentication Header, the message 1753 authenticates correctly. 1755 - ICMP Checksum is valid. 1757 - ICMP Code is 0. 1759 - ICMP length (derived from the IP length) is 8 or more octets. 1761 - All included options have a length that is greater than zero. 1763 The contents of the Reserved field, and of any unrecognized options, 1764 MUST be ignored. Future, backward-compatible changes to the protocol 1765 may specify the contents of the Reserved field or add new options; 1766 backward-incompatible changes may use different Code values. 1768 The contents of any defined options that are not specified to be used 1769 with Router Solicitation messages MUST be ignored and the packet 1770 processed as normal. The only defined option that may appear is the 1771 Source Link-Layer Address option. 1773 A solicitation that passes the validity checks is called a "valid 1774 solicitation". 1776 6.1.2. Validation of Router Advertisement Messages 1778 A node MUST silently discard any received Router Advertisement messages 1779 that do not satisfy all of the following validity checks: 1781 - IP Source Address is a link-local address. Routers must use their 1782 link-local address as the source for Router Advertisement and 1783 Redirect messages so that hosts can uniquely identify routers. 1785 - The IP Hop Limit field has a value of 255, i.e., the packet could 1786 not possibly have been forwarded by a router. 1788 - If the message includes an IP Authentication Header, the message 1789 authenticates correctly. 1791 - ICMP Checksum is valid. 1793 - ICMP Code is 0. 1795 - ICMP length (derived from the IP length) is 16 or more octets. 1797 - All included options have a length that is greater than zero. 1799 The contents of the Reserved field, and of any unrecognized options, 1800 MUST be ignored. Future, backward-compatible changes to the protocol 1801 may specify the contents of the Reserved field or add new options; 1802 backward-incompatible changes may use different Code values. 1804 The contents of any defined options that are not specified to be used 1805 with Router Advertisement messages MUST be ignored and the packet 1806 processed as normal. The only defined options that may appear are the 1807 Source Link-Layer Address, Prefix Information and MTU options. 1809 An advertisement that passes the validity checks is called a "valid 1810 advertisement". 1812 6.2. Router Specification 1813 6.2.1. Router Configuration Variables 1815 A router MUST allow for the following conceptual variables to be 1816 configured by system management. The specific variable names are used 1817 for demonstration purposes only, and an implementation is not required 1818 to have them, so long as its external behavior is consistent with that 1819 described in this document. Default values are specified to simplify 1820 configuration in common cases. 1822 The default values for some of the variables listed below may be 1823 overridden by specific documents that describe how IPv6 operates over 1824 different link layers. This rule simplifies the configuration of 1825 Neighbor Discovery over link types with widely differing performance 1826 characteristics. 1828 For each multicast interface: 1830 AdvSendAdvertisements 1831 A flag indicating whether or not the router sends 1832 periodic Router Advertisements and responds to 1833 Router Solicitations. 1835 Default: FALSE 1837 Note that AdvSendAdvertisements MUST be false by 1838 default so that a node will not accidentally start 1839 acting as a router unless it is explicitly 1840 configured by system management to send Router 1841 Advertisements. 1843 MaxRtrAdvInterval 1844 The maximum time allowed between sending unsolicited 1845 multicast Router Advertisements from the interface, 1846 in seconds. MUST be no less than 4 seconds and no 1847 greater than 1800 seconds. 1849 Default: 600 seconds 1851 MinRtrAdvInterval 1852 The minimum time allowed between sending unsolicited 1853 multicast Router Advertisements from the interface, 1854 in seconds. MUST be no less than 3 seconds and no 1855 greater than .75 * MaxRtrAdvInterval. 1857 Default: 0.33 * MaxRtrAdvInterval 1859 AdvManagedFlag 1860 The true/false value to be placed in the "Managed 1861 address configuration" flag field in the Router 1862 Advertisement. See [ADDRCONF]. 1864 Default: FALSE 1866 AdvOtherConfigFlag 1867 The true/false value to be placed in the "Other 1868 stateful configuration" flag field in the Router 1869 Advertisement. See [ADDRCONF]. 1871 Default: FALSE 1873 AdvLinkMTU The value to be placed in MTU options sent by the 1874 router. A value of zero indicates that no MTU 1875 options are sent. 1877 Default: 0 1879 AdvReachableTime 1880 The value to be placed in the Reachable Time field 1881 in the Router Advertisement messages sent by the 1882 router. The value zero means unspecified (by this 1883 router). MUST be no greater than 3,600,000 1884 milliseconds (1 hour). 1886 Default: 0 1888 AdvRetransTimer 1889 The value to be placed in the Retrans Timer field in 1890 the Router Advertisement messages sent by the 1891 router. The value zero means unspecified (by this 1892 router). 1894 Default: 0 1896 AdvCurHopLimit 1897 The default value to be placed in the Cur Hop Limit 1898 field in the Router Advertisement messages sent by 1899 the router. The value should be set to that current 1900 diameter of the Internet. The value zero means 1901 unspecified (by this router). 1903 Default: The value specified in the "Assigned 1904 Numbers" RFC [ASSIGNED] that was in effect at the 1905 time of implementation. 1907 AdvDefaultLifetime 1908 The value to be placed in the Router Lifetime field 1909 of Router Advertisements sent from the interface, in 1910 seconds. MUST be either zero or between 1911 MaxRtrAdvInterval and 9000 seconds. A value of zero 1912 indicates that the router is not to be used as a 1913 default router. 1915 Default: 3 * MaxRtrAdvInterval 1917 AdvPrefixList 1918 A list of prefixes to be placed in Prefix 1919 Information options in Router Advertisement messages 1920 sent from the interface. 1922 Default: all prefixes that the router advertises via 1923 routing protocols as being on-link for the interface 1924 from which the advertisement is sent. The link- 1925 local prefix SHOULD NOT be included in the list of 1926 advertised prefixes. 1928 Each prefix has an associated: 1930 AdvValidLifetime 1931 The value to be placed in the Valid Lifetime 1932 in the Prefix Information option, in 1933 seconds. The designated value of all 1's 1934 (0xffffffff) represents infinity. 1936 Default: infinity. 1938 AdvOnLinkFlag 1939 The value to be placed in the on-link flag 1940 ("L-bit") field in the Prefix Information 1941 option. 1943 Default: TRUE 1945 Automatic address configuration [ADDRCONF] defines 1946 additional information associated with each the 1947 prefixes: 1949 AdvPreferredLifetime 1950 The value to be placed in the Preferred 1951 Lifetime in the Prefix Information option, 1952 in seconds. The designated value of all 1's 1953 (0xffffffff) represents infinity. See 1954 [ADDRCONF]. 1956 Default: 604800 seconds (7 days) 1958 AdvAutonomousFlag 1959 The value to be placed in the Autonomous 1960 Flag field in the Prefix Information option. 1961 See [ADDRCONF]. 1963 Default: TRUE 1965 The above variables contain information that is placed in outgoing 1966 Router Advertisement messages. Hosts use the received information to 1967 initialize a set of analogous variables that control their external 1968 behavior (see Section 6.3.2). Some of these host variables (e.g., 1969 CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes 1970 including routers. In practice, these variables may not actually be 1971 present on routers, since their contents can be derived from the 1972 variables described above. However, external router behavior MUST be 1973 the same as host behavior with respect to these variables. In 1974 particular, this includes the occasional randomization of the 1975 ReachableTime value as described in Section 6.3.2. 1977 Protocol constants are defined in Section 10. 1979 6.2.2. Becoming An Advertising Interface 1981 The term "advertising interface" refers to any functioning and enabled 1982 multicast interface that has at least one unicast IP address assigned to 1983 it and whose corresponding AdvSendAdvertisements flag is TRUE. A router 1984 MUST NOT send Router Advertisements out any interface that is not an 1985 advertising interface. 1987 An interface may become an advertising interface at times other than 1988 system startup. For example: 1990 - changing the AdvSendAdvertisements flag on an enabled interface 1991 from FALSE to TRUE, or 1993 - administratively enabling the interface, if it had been 1994 administratively disabled, and its AdvSendAdvertisements flag is 1995 TRUE, or 1997 - enabling IP forwarding capability (i.e., changing the system from 1998 being a host to being a router), when the interface's 1999 AdvSendAdvertisements flag is TRUE. 2001 A router MUST join the all-routers multicast address on an advertising 2002 interface. Routers respond to Router Solicitations sent to the all- 2003 routers address and verify the consistency of Router Advertisements sent 2004 by neighboring routers. 2006 6.2.3. Router Advertisement Message Content 2008 A router sends periodic as well as solicited Router Advertisements out 2009 its advertising interfaces. Outgoing Router Advertisements are filled 2010 with the following values consistent with the message format given in 2011 Section 4.2: 2013 - In the Router Lifetime field: the interface's configured 2014 AdvDefaultLifetime. 2016 - In the M and O flags: the interface's configured AdvManagedFlag and 2017 AdvOtherConfigFlag, respectively. See [ADDRCONF]. 2019 - In the Cur Hop Limit field: the interface's configured CurHopLimit. 2021 - In the Reachable Time field: the interface's configured 2022 AdvReachableTime. 2024 - In the Retrans Timer field: the interface's configured 2025 AdvRetransTimer. 2027 - In the options: 2029 o Source Link-Layer Address option: link-layer address of the 2030 sending interface. This option MAY be omitted to facilitate 2031 in-bound load balancing over replicated interfaces. 2033 o MTU option: the interface's configured AdvLinkMTU value if the 2034 value is non-zero. If AdvLinkMTU is zero the MTU option is 2035 not sent. 2037 o Prefix Information options: one Prefix Information option for 2038 each prefix listed in AdvPrefixList with the option fields set 2039 from the information in the AdvPrefixList entry as follows: 2041 - In the "on-link" flag: the entry's AdvOnLinkFlag. 2043 - In the Valid Lifetime field: the entry's 2044 AdvValidLifetime. 2046 - In the "Autonomous address configuration" flag: the 2047 entry's AdvAutonomousFlag. 2049 - In the Preferred Lifetime field: the entry's 2050 AdvPreferredLifetime. 2052 A router might want to send Router Advertisements without advertising 2053 itself as a default router. For instance, a router might advertise 2054 prefixes for address autoconfiguration while not wishing to forward 2055 packets. Such a router sets the Router Lifetime field in outgoing 2056 advertisements to zero. 2058 A router MAY choose not to include some or all options when sending 2059 unsolicited Router Advertisements. For example, if prefix lifetimes are 2060 much longer than AdvDefaultLifetime, including them every few 2061 advertisements may be sufficient. However, when responding to a Router 2062 Solicitation or while sending the first few initial unsolicited 2063 advertisements, a router SHOULD include all options so that all 2064 information (e.g., prefixes) is propagated quickly during system 2065 initialization. 2067 If including all options causes the size of an advertisement to exceed 2068 the link MTU, multiple advertisements can be sent, each containing a 2069 subset of the options. 2071 6.2.4. Sending Unsolicited Router Advertisements 2073 A host MUST NOT send Router Advertisement messages at any time. 2075 Unsolicited Router Advertisements are not strictly periodic: the 2076 interval between subsequent transmissions is randomized to reduce the 2077 probability of synchronization with the advertisements from other 2078 routers on the same link [SYNC]. Each advertising interface has its own 2079 timer. Whenever a multicast advertisement is sent from an interface, 2080 the timer is reset to a uniformly-distributed random value between the 2081 interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; 2082 expiration of the timer causes the next advertisement to be sent and a 2083 new random value to be chosen. 2085 For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) 2086 sent from an interface when it becomes an advertising interface, if the 2087 randomly chosen interval is greater than 2088 MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to 2089 MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for 2090 the initial advertisements increases the likelihood of a router being 2091 discovered quickly when it first becomes available, in the presence of 2092 possible packet loss. 2094 The information contained in Router Advertisements may change through 2095 actions of system management. For instance, the lifetime of advertised 2096 prefixes may change, new prefixes could be added, a router could cease 2097 to be a router (i.e., switch from being a router to being a host), etc. 2098 In such cases, the router MAY transmit up to 2099 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the 2100 same rules as when an interface becomes an advertising interface. 2102 6.2.5. Ceasing To Be An Advertising Interface 2104 An interface may cease to be an advertising interface, through actions 2105 of system management such as: 2107 - changing the AdvSendAdvertisements flag of an enabled interface 2108 from TRUE to FALSE, or 2110 - administratively disabling the interface, or 2112 - shutting down the system. 2114 In such cases the router SHOULD transmit one or more (but not more than 2115 MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on 2116 the interface with a Router Lifetime field of zero. In the case of a 2117 router becoming a host, the system SHOULD also depart from the all- 2118 routers IP multicast group on all interfaces on which the router 2119 supports IP multicast (whether or not they had been advertising 2120 interfaces). In addition, the host MUST insure that subsequent Neighbor 2121 Advertisement messages sent from the interface have the Router flag set 2122 to zero. 2124 Note that system management may disable a router's IP forwarding 2125 capability (i.e., changing the system from being a router to being a 2126 host), a step that does not necessarily imply that the router's 2127 interfaces stop being advertising interfaces. In such cases, subsequent 2128 Router Advertisements MUST set the Router Lifetime field to zero. 2130 6.2.6. Processing Router Solicitations 2132 A host MUST silently discard any received Router Solicitation messages. 2134 In addition to sending periodic, unsolicited advertisements, a router 2135 sends advertisements in response to valid solicitations received on an 2136 advertising interface. A router MAY choose to unicast the response 2137 directly to the soliciting host's address (if the solicitation's source 2138 address is not the unspecified address), but the usual case is to 2139 multicast the response to the all-nodes group. In the latter case, the 2140 interface's interval timer is reset to a new random value, as if an 2141 unsolicited advertisement had just been sent (see Section 6.2.4). 2143 In all cases, Router Advertisements sent in response to a Router 2144 Solicitation MUST be delayed by a random time between 0 and 2145 MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in 2146 response to multiple solicitations, the delay is relative to the first 2147 solicitation.) In addition, consecutive Router Advertisements sent to 2148 the all-nodes multicast address MUST be rate limited to no more than one 2149 advertisement every MIN_DELAY_BETWEEN_RAS seconds. 2151 A router might process Router Solicitations as follows: 2153 - Upon receipt of a Router Solicitation, compute a random delay within 2154 the range 0 through MAX_RA_DELAY_TIME. If the computed value 2155 corresponds to a time later than the time the next multicast Router 2156 Advertisement is scheduled to be sent, ignore the random delay and 2157 send the advertisement at the already-scheduled time. 2159 - If the router sent a multicast Router Advertisement (solicited or 2160 unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, schedule 2161 the advertisement to be sent at a time corresponding to 2162 MIN_DELAY_BETWEEN_RAS plus the random value after the previous 2163 advertisement was sent. This ensures that the multicast Router 2164 Advertisements are rate limited. 2166 - Otherwise, schedule the sending of a Router Advertisement at the time 2167 given by the random value. 2169 Note that a router is permitted to send multicast Router Advertisements 2170 more frequently than indicated by the MinRtrAdvInterval configuration 2171 variable so long as the more frequent advertisements are responses to 2172 Router Solicitations. In all cases, however, unsolicited multicast 2173 advertisements MUST NOT be sent more frequently than indicated by 2174 MinRtrAdvInterval. 2176 When a router receives a Router Solicitation and the Source Address is 2177 not the unspecified address, it records that the source of the packet is 2178 a neighbor by creating or updating the Neighbor Cache entry. If the 2179 solicitation contains a Source Link-Layer Address option, and the router 2180 has a Neighbor Cache entry for the neighbor, the link-layer address 2181 SHOULD be updated in the Neighbor Cache. If a Neighbor Cache entry is 2182 created for the source its reachability state MUST be set to STALE as 2183 specified in Section 7.3.3. If a cache entry already exists and is 2184 updated with a different link-layer address the reachability state MUST 2185 also be set to STALE. In either case the entry's IsRouter flag SHOULD 2186 be set to false. 2188 If the Source Address is the unspecified address the router MUST NOT 2189 create or update the Neighbor Cache entry. 2191 6.2.7. Router Advertisement Consistency 2193 Routers SHOULD inspect valid Router Advertisements sent by other routers 2194 and verify that the routers are advertising consistent information on a 2195 link. Detected inconsistencies indicate that one or more routers might 2196 be misconfigured and SHOULD be logged to system or network management. 2197 The minimum set of information to check includes: 2199 - Cur Hop Limit values (except for the unspecified value of zero). 2201 - Values of the M or O flags. 2203 - Reachable Time values (except for the unspecified value of zero). 2205 - Retrans Timer values (except for the unspecified value of zero). 2207 - Values in the MTU options. 2209 - Preferred and Valid Lifetimes for the same prefix. 2211 Note that it is not an error for different routers to advertise 2212 different sets of prefixes. Also, some routers might leave some fields 2213 as unspecified, i.e., with the value zero, while other routers specify 2214 values. The logging of errors SHOULD be restricted to conflicting 2215 information that causes hosts to switch from one value to another with 2216 each received advertisement. 2218 Any other action on reception of Router Advertisement messages by a 2219 router is beyond the scope of this document. 2221 6.2.8. Link-local Address Change 2223 The link-local address on a router SHOULD change rarely, if ever. Nodes 2224 receiving Neighbor Discovery messages use the source address to identify 2225 the sender. If multiple packets from the same router contain different 2226 source addresses, nodes will assume they come from different routers, 2227 leading to undesirable behavior. For example, a node will ignore 2228 Redirect messages that are believed to have been sent by a router other 2229 than the current first-hop router. Thus the source address used in 2230 Router Advertisements sent by a particular router must be identical to 2231 the target address in a Redirect message when redirecting to that 2232 router. 2234 Using the link-local address to uniquely identify routers on the link 2235 has the benefit that the address a router is known by should not change 2236 when a site renumbers. 2238 If a router changes the link-local address for one of its interfaces, it 2239 SHOULD inform hosts of this change. The router SHOULD multicast a few 2240 Router Advertisements from the old link-local address with the Router 2241 Lifetime field set to zero and also multicast a few Router 2242 Advertisements from the new link-local address. The overall effect 2243 should be the same as if one interface ceases being an advertising 2244 interface, and a different one starts being an advertising interface. 2246 6.3. Host Specification 2248 6.3.1. Host Configuration Variables 2250 None. 2252 6.3.2. Host Variables 2254 A host maintains certain Neighbor Discovery related variables in 2255 addition to the data structures defined in Section 5.1. The specific 2256 variable names are used for demonstration purposes only, and an 2257 implementation is not required to have them, so long as its external 2258 behavior is consistent with that described in this document. 2260 These variables have default values that are overridden by information 2261 received in Router Advertisement messages. The default values are used 2262 when there is no router on the link or when all received Router 2263 Advertisements have left a particular value unspecified. 2265 The default values in this specification may be overridden by specific 2266 documents that describe how IP operates over different link layers. 2267 This rule allows Neighbor Discovery to operate over links with widely 2268 varying performance characteristics. 2270 For each interface: 2272 LinkMTU The MTU of the link. 2274 Default: The valued defined in the specific document 2275 that describes how IPv6 operates over the particular 2276 link layer (e.g., [IPv6-ETHER]). 2278 CurHopLimit The default hop limit to be used when sending 2279 (unicast) IP packets. 2281 Default: The value specified in the "Assigned 2282 Numbers" RFC [ASSIGNED] that was in effect at the 2283 time of implementation. 2285 BaseReachableTime 2286 A base value used for computing the random 2287 ReachableTime value. 2289 Default: REACHABLE_TIME milliseconds. 2291 ReachableTime The time a neighbor is considered reachable after 2292 receiving a reachability confirmation. 2294 This value should be a uniformly-distributed random 2295 value between MIN_RANDOM_FACTOR and 2296 MAX_RANDOM_FACTOR times BaseReachableTime 2297 milliseconds. A new random value should be 2298 calculated when BaseReachableTime changes (due to 2299 Router Advertisements) or at least every few hours 2300 even if no Router Advertisements are received. 2302 RetransTimer The time between retransmissions of Neighbor 2303 Solicitation messages to a neighbor when resolving 2304 the address or when probing the reachability of a 2305 neighbor. 2307 Default: RETRANS_TIMER milliseconds 2309 6.3.3. Interface Initialization 2311 The host joins the all-nodes multicast address on all multicast-capable 2312 interfaces. 2314 6.3.4. Processing Received Router Advertisements 2316 When multiple routers are present, the information advertised 2317 collectively by all routers may be a superset of the information 2318 contained in a single Router Advertisement. Moreover, information may 2319 also be obtained through other dynamic means, such as stateful 2320 autoconfiguration. Hosts accept the union of all received information; 2321 the receipt of a Router Advertisement MUST NOT invalidate all 2322 information received in a previous advertisement or from another source. 2323 However, when received information for a specific parameter (e.g., Link 2324 MTU) or option (e.g., Lifetime on a specific Prefix) differs from 2325 information received earlier, and the parameter/option can only have one 2326 value, the most recently-received information is considered 2327 authoritative. 2329 Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time 2330 and Retrans Timer) may contain a value denoting unspecified. In such 2331 cases, the parameter should be ignored and the host should continue 2332 using whatever value it is already using. In particular, a host MUST 2333 NOT interpret the unspecified value as meaning change back to the 2334 default value that was in use before the first Router Advertisement was 2335 received. This rule prevents hosts from continually changing an 2336 internal variable when one router advertises a specific value, but other 2337 routers advertise the unspecified value. 2339 On receipt of a valid Router Advertisement, a host extracts the source 2340 address of the packet and does the following: 2342 - If the address is not already present in the host's Default Router 2343 List, and the advertisement's Router Lifetime is non-zero, create a 2344 new entry in the list, and initialize its invalidation timer value 2345 from the advertisement's Router Lifetime field. 2347 - If the address is already present in the host's Default Router List 2348 as a result of a previously-received advertisement, reset its 2349 invalidation timer to the Router Lifetime value in the newly- 2350 received advertisement. 2352 - If the address is already present in the host's Default Router List 2353 and the received Router Lifetime value is zero, immediately time- 2354 out the entry as specified in Section 6.3.5. 2356 To limit the storage needed for the Default Router List, a host MAY 2357 choose not to store all of the router addresses discovered via 2358 advertisements. However, a host MUST retain at least two router 2359 addresses and SHOULD retain more. Default router selections are made 2360 whenever communication to a destination appears to be failing. Thus, 2361 the more routers on the list, the more likely an alternative working 2362 router can be found quickly (e.g., without having to wait for the next 2363 advertisement to arrive). 2365 If the received Cur Hop Limit value is non-zero the host SHOULD set its 2366 CurHopLimit variable to the received value. 2368 If the received Reachable Time value is non-zero the host SHOULD set its 2369 BaseReachableTime variable to the received value. If the new value 2370 differs from the previous value, the host SHOULD recompute a new random 2371 ReachableTime value. ReachableTime is computed as a uniformly- 2372 distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR 2373 times the BaseReachableTime. Using a random component eliminates the 2374 possibility Neighbor Unreachability Detection messages synchronize with 2375 each other. 2377 In most cases, the advertised Reachable Time value will be the same in 2378 consecutive Router Advertisements and a host's BaseReachableTime rarely 2379 changes. In such cases, an implementation SHOULD insure that a new 2380 random value gets recomputed at least once every few hours. 2382 The RetransTimer variable SHOULD be copied from the Retrans Timer field, 2383 if the received value is non-zero. 2385 After extracting information from the fixed part of the Router 2386 Advertisement message, the advertisement is scanned for valid options. 2387 If the advertisement contains a Source Link-Layer Address option the 2388 link-layer address SHOULD be recorded in the Neighbor Cache entry for 2389 the router (creating an entry if necessary) and the IsRouter flag in the 2390 Neighbor Cache entry MUST be set to true. The IsRouter flag is used by 2391 Neighbor Unreachability Detection to determine when a router changes to 2392 being a host (i.e., no longer capable of forwarding packets). If a 2393 Neighbor Cache entry is created for the router its reachability state 2394 MUST be set to STALE as specified in Section 7.3.3. If a cache entry 2395 already exists and is updated with a different link-layer address the 2396 reachability state MUST also be set to STALE. 2398 If the MTU option is present, hosts SHOULD copy the option's value into 2399 LinkMTU if the value does not exceed the default LinkMTU value specified 2400 in the link type specific document (e.g., [IPv6-ETHER]). 2402 Prefix Information options that have the "on-link" (L) flag set indicate 2403 a prefix identifying a range of addresses that should be considered on- 2404 link. Note, however, that a Prefix Information option with the on-link 2405 flag set to zero conveys no information concerning on-link determination 2406 and MUST NOT be interpreted to mean that addresses covered by the prefix 2407 are off-link. The default behavior (see Section 5.2) when no 2408 information is known about an address is to send the packets to a 2409 default router and the reception of a Prefix Information option with the 2410 "on-link " (L) flag set to zero does not change this behavior. The 2411 reasons for an address being treated as on-link is specified in the 2412 definition of "on-link" in Section 2.1. Prefixes with the on-link flag 2413 set to zero would normally have the autonomous flag set and be used by 2414 [ADDRCONF]. 2416 For each Prefix Information option with the on-link flag set, a host 2417 does the following: 2419 - If the prefix is the link-local prefix, silently ignore the Prefix 2420 Information option. 2422 - If the prefix is not already present in the Prefix List, and the 2423 Prefix Information option's Valid Lifetime field is non-zero, 2424 create a new entry for the prefix and initialize its invalidation 2425 timer to the Valid Lifetime value in the Prefix Information option. 2427 - If the prefix is already present in the host's Prefix List as the 2428 result of a previously-received advertisement, reset its 2429 invalidation timer to the Valid Lifetime value in the Prefix 2430 Information option. If the new Lifetime value is zero, time-out 2431 the prefix immediately (see Section 6.3.5). 2433 - If the Prefix Information option's Valid Lifetime field is zero, 2434 and the prefix is not present in the host's Prefix List, silently 2435 ignore the option. 2437 Note: Implementations can choose to process the on-link aspects of 2438 the prefixes separately from the address autoconfiguration aspects of 2439 the prefixes by, e.g., passing a copy of each valid Router 2440 Advertisement message to both an "on-link" and an "addrconf" 2441 function. Each function can then operate independently on the 2442 prefixes that have the appropriate flag set. 2444 6.3.5. Timing out Prefixes and Default Routers 2446 Whenever the invalidation timer expires for a Prefix List entry, that 2447 entry is discarded. No existing Destination Cache entries need be 2448 updated, however. Should a reachability problem arise with an existing 2449 Neighbor Cache entry, Neighbor Unreachability Detection will perform any 2450 needed recovery. 2452 Whenever the Lifetime of an entry in the Default Router List expires, 2453 that entry is discarded. When removing a router from the Default Router 2454 list, the node MUST update the Destination Cache in such a way that all 2455 entries using the router perform next-hop determination again rather 2456 than continue sending traffic to the (deleted) router. 2458 6.3.6. Default Router Selection 2460 The algorithm for selecting a router depends in part on whether or not a 2461 router is known to be reachable. The exact details of how a node keeps 2462 track of a neighbor's reachability state are covered in Section 7.3. 2463 The algorithm for selecting a default router is invoked during next-hop 2464 determination when no Destination Cache entry exists for an off-link 2465 destination or when communication through an existing router appears to 2466 be failing. Under normal conditions, a router would be selected the 2467 first time traffic is sent to a destination, with subsequent traffic for 2468 that destination using the same router as indicated in the Destination 2469 Cache modulo any changes to the Destination Cache caused by Redirect 2470 messages. 2472 The policy for selecting routers from the Default Router List is as 2473 follows: 2475 1) Routers that are reachable or probably reachable (i.e., in any 2476 state other than INCOMPLETE) SHOULD be preferred over routers whose 2477 reachability is unknown or suspect (i.e., in the INCOMPLETE state, 2478 or for which no Neighbor Cache entry exists). An implementation 2479 may choose to always return the same router or cycle through the 2480 router list in a round-robin fashion as long as it always returns a 2481 reachable or a probably reachable router when one is available. 2483 2) When no routers on the list are known to be reachable or probably 2484 reachable, routers SHOULD be selected in a round-robin fashion, so 2485 that subsequent requests for a default router do not return the 2486 same router until all other routers have been selected. 2488 Cycling through the router list in this case ensures that all 2489 available routers are actively probed by the Neighbor 2490 Unreachability Detection algorithm. A request for a default router 2491 is made in conjunction with the sending of a packet to a router, 2492 and the selected router will be probed for reachability as a side 2493 effect. 2495 3) If the Default Router List is empty, assume that all destinations 2496 are on-link as specified in Section 5.2. 2498 6.3.7. Sending Router Solicitations 2500 When an interface becomes enabled, a host may be unwilling to wait for 2501 the next unsolicited Router Advertisement to locate default routers or 2502 learn prefixes. To obtain Router Advertisements quickly, a host SHOULD 2503 transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each 2504 separated by at least RTR_SOLICITATION_INTERVAL seconds. Router 2505 Solicitations may be sent after any of the following events: 2507 - The interface is initialized at system startup time. 2509 - The interface is reinitialized after a temporary interface failure 2510 or after being temporarily disabled by system management. 2512 - The system changes from being a router to being a host, by having 2513 its IP forwarding capability turned off by system management. 2515 - The host attaches to a link for the first time. 2517 - The host re-attaches to a link after being detached for some time. 2519 A host sends Router Solicitations to the all-routers multicast address. 2520 The IP source address is set to either one of the interface's unicast 2521 addresses or the unspecified address. The Source Link-Layer Address 2522 option SHOULD be set to the host's link-layer address, if the IP source 2523 address is a unicast address. 2525 Before a host sends an initial solicitation, it SHOULD delay the 2526 transmission for a random amount of time between 0 and 2527 MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when 2528 many hosts start up on a link at the same time, such as might happen 2529 after recovery from a power failure. If a host has already performed a 2530 random delay since the interface became (re)enabled (e.g., as part of 2531 Duplicate Address Detection [ADDRCONF]) there is no need to delay again 2532 before sending the first Router Solicitation message. 2534 Once the host sends a Router Solicitation, and receives a valid Router 2535 Advertisement with a non-zero Router Lifetime, the host MUST desist from 2536 sending additional solicitations on that interface, until the next time 2537 one of the above events occurs. Moreover, a host SHOULD send at least 2538 one solicitation in the case where an advertisement is received prior to 2539 having sent a solicitation. Unsolicited Router Advertisements may be 2540 incomplete (see Section 6.2.3); solicited advertisements are expected to 2541 contain complete information. 2543 If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no 2544 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 2545 seconds after sending the last solicitation, the host concludes that 2546 there are no routers on the link for the purpose of [ADDRCONF]. 2547 However, the host continues to receive and process Router Advertisements 2548 messages in the event that routers appear on the link. 2550 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 2552 This section describes the functions related to Neighbor Solicitation 2553 and Neighbor Advertisement messages and includes descriptions of address 2554 resolution and the Neighbor Unreachability Detection algorithm. 2556 Neighbor Solicitation and Advertisement messages are also used for 2557 Duplicate Address Detection as specified by [ADDRCONF]. In particular, 2558 Duplicate Address Detection sends Neighbor Solicitation messages with an 2559 unspecified source address targeting its own "tentative" address. Such 2560 messages trigger nodes already using the address to respond with a 2561 multicast Neighbor Advertisement indicating that the address is in use. 2563 7.1. Message Validation 2565 7.1.1. Validation of Neighbor Solicitations 2567 A node MUST silently discard any received Neighbor Solicitation messages 2568 that do not satisfy all of the following validity checks: 2570 - The IP Hop Limit field has a value of 255, i.e., the packet could 2571 not possibly have been forwarded by a router. 2573 - If the message includes an IP Authentication Header, the message 2574 authenticates correctly. 2576 - ICMP Checksum is valid. 2578 - ICMP Code is 0. 2580 - ICMP length (derived from the IP length) is 24 or more octets. 2582 - Target Address is not a multicast address. 2584 - All included options have a length that is greater than zero. 2586 The contents of the Reserved field, and of any unrecognized options, 2587 MUST be ignored. Future, backward-compatible changes to the protocol 2588 may specify the contents of the Reserved field or add new options; 2589 backward-incompatible changes may use different Code values. 2591 The contents of any defined options that are not specified to be used 2592 with Neighbor Solicitation messages MUST be ignored and the packet 2593 processed as normal. The only defined option that may appear is the 2594 Source Link-Layer Address option. 2596 A Neighbor Solicitation that passes the validity checks is called a 2597 "valid solicitation". 2599 7.1.2. Validation of Neighbor Advertisements 2601 A node MUST silently discard any received Neighbor Advertisement 2602 messages that do not satisfy all of the following validity checks: 2604 - The IP Hop Limit field has a value of 255, i.e., the packet could 2605 not possibly have been forwarded by a router. 2607 - If the message includes an IP Authentication Header, the message 2608 authenticates correctly. 2610 - ICMP Checksum is valid. 2612 - ICMP Code is 0. 2614 - ICMP length (derived from the IP length) is 24 or more octets. 2616 - Target Address is not a multicast address. 2618 - If the IP Destination Address is a multicast address the Solicited 2619 flag is zero. 2621 - All included options have a length that is greater than zero. 2623 The contents of the Reserved field, and of any unrecognized options, 2624 MUST be ignored. Future, backward-compatible changes to the protocol 2625 may specify the contents of the Reserved field or add new options; 2626 backward-incompatible changes may use different Code values. 2628 The contents of any defined options that are not specified to be used 2629 with Neighbor Advertisement messages MUST be ignored and the packet 2630 processed as normal. The only defined option that may appear is the 2631 Target Link-Layer Address option. 2633 A Neighbor Advertisements that passes the validity checks is called a 2634 "valid advertisement". 2636 7.2. Address Resolution 2638 Address resolution is the process through which a node determines the 2639 link-layer address of a neighbor given only its IP address. Address 2640 resolution is performed only on addresses that are determined to be on- 2641 link and for which the sender does not know the corresponding link-layer 2642 address. Address resolution is never performed on multicast addresses. 2644 7.2.1. Interface Initialization 2646 When a multicast-capable interface becomes enabled the node MUST join 2647 the all-nodes multicast address on that interface, as well as the 2648 solicited-node multicast address corresponding to each of the IP 2649 addresses assigned to the interface. 2651 The set of addresses assigned to an interface may change over time. New 2652 addresses might be added and old addresses might be removed [ADDRCONF]. 2653 In such cases the node MUST join and leave the solicited-node multicast 2654 address corresponding to the new and old addresses, respectively. Note 2655 that multiple unicast addresses may map into the same solicited-node 2656 multicast address; a node MUST NOT leave the solicited-node multicast 2657 group until all assigned addresses corresponding to that multicast 2658 address have been removed. 2660 7.2.2. Sending Neighbor Solicitations 2662 When a node has a unicast packet to send to a neighbor, but does not 2663 know the neighbor's link-layer address, it performs address resolution. 2664 For multicast-capable interfaces this entails creating a Neighbor Cache 2665 entry in the INCOMPLETE state and transmitting a Neighbor Solicitation 2666 message targeted at the neighbor. The solicitation is sent to the 2667 solicited-node multicast address corresponding to the target address. 2669 If the source address of the packet prompting the solicitation is the 2670 same as one of the addresses assigned to the outgoing interface, that 2671 address SHOULD be placed in the IP Source Address of the outgoing 2672 solicitation. Otherwise, any one of the addresses assigned to the 2673 interface should be used. Using the prompting packet's source address 2674 when possible insures that the recipient of the Neighbor Solicitation 2675 installs in its Neighbor Cache the IP address that is highly likely to 2676 be used in subsequent return traffic belonging to the prompting packet's 2677 "connection". 2679 If the solicitation is being sent to a solicited-node multicast address, 2680 the sender MUST include its link-layer address (if it has one) as a 2681 Source Link-Layer Address option. Otherwise, the sender SHOULD include 2682 its link-layer address (if it has one) as a Source Link-Layer Address 2683 option. Including the source link-layer address in a multicast 2684 solicitation is required to give the target an address to which it can 2685 send the Neighbor Advertisement. 2687 While waiting for address resolution to complete, the sender MUST, for 2688 each neighbor, retain a small queue of packets waiting for address 2689 resolution to complete. The queue MUST hold at least one packet, and 2690 MAY contain more. However, the number of queued packets per neighbor 2691 SHOULD be limited to some small value. When a queue overflows, the new 2692 arrival SHOULD replace the oldest entry. Once address resolution 2693 completes, the node transmits any queued packets. 2695 While awaiting a response, the sender SHOULD retransmit Neighbor 2696 Solicitation messages approximately every RetransTimer milliseconds, 2697 even in the absence of additional traffic to the neighbor. 2698 Retransmissions MUST be rate-limited to at most one solicitation per 2699 neighbor every RetransTimer milliseconds. 2701 If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT 2702 solicitations, address resolution has failed. The sender MUST return 2703 ICMP destination unreachable indications with code 3 (Address 2704 Unreachable) for each packet queued awaiting address resolution. 2706 7.2.3. Receipt of Neighbor Solicitations 2708 A valid Neighbor Solicitation where the Target Address is not a unicast 2709 or anycast address assigned to the receiving interface, and the Target 2710 Address is not a "tentative" address on which Duplicate Address 2711 Detection is being performed [ADDRCONF] MUST be silently ignored. If 2712 the Target Address is tentative, the Neighbor Solicitation should be 2713 processed as described in [ADDRCONF]. 2715 Upon receipt of a valid Neighbor Solicitation targeted at the node, the 2716 recipient SHOULD update the Neighbor Cache entry for the IP Source 2717 Address of the solicitation if the Source Address is not the unspecified 2718 address. If an entry does not already exist, the node SHOULD create a 2719 new one and set its reachability state to STALE as specified in 2720 Section 7.3.3. If a cache entry already exists and is updated with a 2721 different link-layer address its reachability state MUST be set to 2722 STALE. If the solicitation contains a Source Link-Layer Address option, 2723 the entry's cached link-layer address should be replaced with the one in 2724 the solicitation. 2726 If the Source Address is the unspecified address the node MUST NOT 2727 create or update the Neighbor Cache entry. 2729 After any updates to the Neighbor Cache, the node sends a Neighbor 2730 Advertisement response as described in the next section. 2732 7.2.4. Sending Solicited Neighbor Advertisements 2734 A node sends a Neighbor Advertisement in response to a valid Neighbor 2735 Solicitation targeting one of the node's assigned addresses. The Target 2736 Address of the advertisement is copied from the Target Address of the 2737 solicitation. If the solicitation's IP Destination Address is a unicast 2738 or anycast address, the Target Link-Layer Address option SHOULD NOT be 2739 included; the neighboring node's cached value must already be current in 2740 order for the solicitation to have been received. If the solicitation's 2741 IP Destination Address is a solicited-node multicast address, the Target 2742 Link-Layer option MUST be included in the advertisement. If the node is 2743 a router, it MUST set the Router flag to one; otherwise it MUST set the 2744 flag to zero. 2746 If the Target Address is either an anycast address or a unicast address 2747 for which the node is providing proxy service, or the Target Link-Layer 2748 Address option is not included in the outgoing advertisement, the 2749 Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to 2750 one. Proper setting of the Override flag insures that nodes give 2751 preference to non-proxy advertisements, even when received after proxy 2752 advertisements, but that the first advertisement for an anycast address 2753 "wins". 2755 If the source of the solicitation is the unspecified address, the node 2756 MUST set the Solicited flag to zero and multicast the advertisement to 2757 the all-nodes address. Otherwise, the node MUST set the Solicited flag 2758 to one and unicast the advertisement to the Source Address of the 2759 solicitation. 2761 If the Target Address is an anycast address the sender SHOULD delay 2762 sending a response for a random time between 0 and 2763 MAX_ANYCAST_DELAY_TIME seconds. 2765 7.2.5. Receipt of Neighbor Advertisements 2767 When a valid Neighbor Advertisement is received (either solicited or 2768 unsolicited), the Neighbor Cache is searched for the target's entry. If 2769 no entry exists, the advertisement SHOULD be silently discarded. There 2770 is no need to create an entry in this case, since the recipient has 2771 apparently not initiated any communication with the target. 2773 Once the appropriate Neighbor Cache entry has been located, the specific 2774 actions taken depend on the state of the Neighbor Cache entry and the 2775 flags in the advertisement. If the entry is in an INCOMPLETE state 2776 (i.e., no link-layer address is cached for the target) the received 2777 advertisement updates the entry. If a cached link-layer address is 2778 already present, however, a node might choose to ignore the received 2779 advertisement and continue using the cached link-layer address. 2781 If the target's Neighbor Cache entry is in the INCOMPLETE state, the 2782 receiving node records the link-layer address in the Neighbor Cache 2783 entry and sends any packets queued for the neighbor awaiting address 2784 resolution. If the Solicited flag is set, the reachability state for 2785 the neighbor MUST be set to REACHABLE; otherwise it MUST be set to 2786 STALE. (A more detailed explanation of reachability state is described 2787 in Section 7.3.3). The Override flag is ignored if the entry is in the 2788 INCOMPLETE state. 2790 If the target's Neighbor Cache entry is in any state other than 2791 INCOMPLETE when the advertisement is received, the advertisement's 2792 Override flag's setting determines whether the Target Link-Layer Address 2793 option (if present) replaces the cached address. If the Override flag 2794 is set, the receiving node MUST install the link-layer address in its 2795 cache; if the flag is zero, the receiving node MUST NOT install the 2796 link-layer address in its cache. An advertisement's sender sets the 2797 Override flag when it wants its Target Link-Layer Address option to 2798 replace the cached value in Neighbor Cache entries, regardless of their 2799 current contents. 2801 If the target's Neighbor Cache entry is in any state other than 2802 INCOMPLETE when the advertisement is received, the advertisement's 2803 Solicited flag setting determines what the entry's new state should be. 2804 If the Solicited flag is set, the entry's state MUST be set to 2805 REACHABLE; if the flag is zero, the entry's state MUST be set to STALE. 2806 An advertisement's Solicited flag should only be set if the 2807 advertisement is a response to a Neighbor Solicitation. Because 2808 Neighbor Unreachability Solicitations are sent to the cached link-layer 2809 address, a receipt of a solicited advertisement indicates that the 2810 forward path is working. Receipt of an unsolicited advertisement, 2811 however, suggests that a neighbor has urgent information to announce 2812 (e.g., a changed link-layer address). Regardless of whether or not the 2813 new link-layer address is installed in the cache, a node should verify 2814 the reachability of the path it is currently using when it sends the 2815 next packet, so that it quickly finds a working path if the existing 2816 path has failed (e.g., as would be the case if the unsolicited Neighbor 2817 Advertisement is sent to announce a link-layer address change). 2819 In those cases where the cached link-layer address is updated, the 2820 receiving node MUST examine the Router flag in the received 2821 advertisement and update the IsRouter flag in the Neighbor Cache entry 2822 to reflect whether the node is a host or router. In those cases where 2823 the neighbor was previously used as a router, but the advertisement's 2824 Router flag is now set to zero, the node MUST remove that router from 2825 the Default Router List and update the Destination Cache entries for all 2826 destinations using that neighbor as a router as specified in 2827 Section 7.3.3. 2829 7.2.6. Sending Unsolicited Neighbor Advertisements 2831 In some cases a node may be able to determine that its link-layer 2832 address has changed (e.g., hot-swap of an interface card) and may wish 2833 to inform its neighbors of the new link-layer address quickly. In such 2834 cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited 2835 Neighbor Advertisement messages to the all-nodes multicast address. 2836 These advertisements MUST be separated by at least RetransTimer seconds. 2838 The Target Address field in the unsolicited advertisement is set to an 2839 IP address of the interface, and the Target Link-Layer Address option is 2840 filled with the new link-layer address. The Solicited flag MUST be set 2841 to zero, in order to avoid confusing the Neighbor Unreachability 2842 Detection algorithm. If the node is a router, it MUST set the Router 2843 flag to one; otherwise it MUST set it to zero. The Override flag MAY be 2844 set to either zero or one. In either case, neighboring nodes will 2845 immediately change the state of their Neighbor Cache entries for the 2846 Target Address to STALE, prompting them to verify the path for 2847 reachability. If the Override flag is set to one, neighboring nodes 2848 will install the new link-layer address in their caches. Otherwise, 2849 they will ignore the new link-layer address, choosing instead to probe 2850 the cached address. 2852 A node that has multiple IP addresses assigned to an interface MAY 2853 multicast a separate Neighbor Advertisement for each address. In such a 2854 case the node SHOULD introduce a small delay between the sending of each 2855 advertisement to reduce the probability of the advertisements being lost 2856 due to congestion. 2858 A proxy MAY multicast Neighbor Advertisements when its link-layer 2859 address changes or when it is configured (by system management or other 2860 mechanisms) to proxy for an address. If there are multiple nodes that 2861 are providing proxy services for the same set of addresses the proxies 2862 SHOULD provide a mechanism that prevents multiple proxies from 2863 multicasting advertisements for any one address, in order to reduce the 2864 risk of excessive multicast traffic. 2866 Also, a node belonging to an anycast address MAY multicast unsolicited 2867 Neighbor Advertisements for the anycast address when the node's link- 2868 layer address changes. 2870 Note that because unsolicited Neighbor Advertisements do not reliably 2871 update caches in all nodes (the advertisements might not be received by 2872 all nodes), they should only be viewed as a performance optimization to 2873 quickly update the caches in most neighbors. The Neighbor 2874 Unreachability Detection algorithm ensures that all nodes obtain a 2875 reachable link-layer address, though the delay may be slightly longer. 2877 7.2.7. Anycast Neighbor Advertisements 2879 From the perspective of Neighbor Discovery, anycast addresses are 2880 treated just like unicast addresses in most cases. Because an anycast 2881 address is syntactically the same as a unicast address, nodes performing 2882 address resolution or Neighbor Unreachability Detection on an anycast 2883 address treat it as if it were a unicast address. No special processing 2884 takes place. 2886 Nodes that have an anycast address assigned to an interface treat them 2887 exactly the same as if they were unicast addresses with two exceptions. 2888 First, Neighbor Advertisements sent in response to a Neighbor 2889 Solicitation SHOULD be delayed by a random time between 0 and 2890 MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. 2891 Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, 2892 so that when multiple advertisements are received, the first received 2893 advertisement is used rather than the most recently received 2894 advertisement. 2896 As with unicast addresses, Neighbor Unreachability Detection ensures 2897 that a node quickly detects when the current binding for an anycast 2898 address becomes invalid. 2900 7.2.8. Proxy Neighbor Advertisements 2902 Under limited circumstances, a router MAY proxy for one or more other 2903 nodes, that is, through Neighbor Advertisements indicate that it is 2904 willing to accept packets not explicitly addressed to itself. For 2905 example, a router might accept packets on behalf of a mobile node that 2906 has moved off-link. The mechanisms used by proxy are identical to the 2907 mechanisms used with anycast addresses. 2909 A proxy MUST join the solicited-node multicast address(es) that 2910 correspond to the IP address(es) assigned to the node for which it is 2911 proxying. 2913 All solicited proxy Neighbor Advertisement messages MUST have the 2914 Override flag set to zero. This ensures that if the node itself is 2915 present on the link its Neighbor Advertisement (with the Override flag 2916 set to one) will take precedence of any advertisement received from a 2917 proxy. A proxy MAY send unsolicited advertisements with the Override 2918 flag set to one as specified in Section 7.2.6, but doing so may cause 2919 the proxy advertisement to override a valid entry created by the node 2920 itself. 2922 Finally, when sending a proxy advertisement in response to a Neighbor 2923 Solicitation, the sender should delay its response by a random time 2924 between 0 and MAX_ANYCAST_DELAY_TIME seconds. 2926 7.3. Neighbor Unreachability Detection 2928 Communication to or through a neighbor may fail for numerous reasons at 2929 any time, including hardware failure, hot-swap of an interface card, 2930 etc. If the destination has failed, no recovery is possible and 2931 communication fails. On the other hand, if it is the path that has 2932 failed, recovery may be possible. Thus, a node actively tracks the 2933 reachability "state" for the neighbors to which it is sending packets. 2935 Neighbor Unreachability Detection is used for all paths between hosts 2936 and neighboring nodes, including host-to-host, host-to-router, and 2937 router-to-host communication. Neighbor Unreachability Detection may 2938 also be used between routers, but is not required if an equivalent 2939 mechanism is available, for example, as part of the routing protocols. 2941 When a path to a neighbor appears to be failing, the specific recovery 2942 procedure depends on how the neighbor is being used. If the neighbor is 2943 the ultimate destination, for example, address resolution should be 2944 performed again. If the neighbor is a router, however, attempting to 2945 switch to another router would be appropriate. The specific recovery 2946 that takes place is covered under next-hop determination; Neighbor 2947 Unreachability Detection signals the need for next-hop determination by 2948 deleting a Neighbor Cache entry. 2950 Neighbor Unreachability Detection is performed only for neighbors to 2951 which unicast packets are sent; it is not used when sending to multicast 2952 addresses. 2954 7.3.1. Reachability Confirmation 2956 A neighbor is considered reachable if the node has recently received a 2957 confirmation that packets sent recently to the neighbor were received by 2958 its IP layer. Positive confirmation can be gathered in two ways: hints 2959 from upper layer protocols that indicate a connection is making "forward 2960 progress", or receipt of a Neighbor Advertisement message that is a 2961 response to a Neighbor Solicitation message. 2963 A connection makes "forward progress" if the packets received from a 2964 remote peer can only be arriving if recent packets sent to that peer are 2965 actually reaching it. In TCP, for example, receipt of a (new) 2966 acknowledgement indicates that previously sent data reached the peer. 2967 Likewise, the arrival of new (non-duplicate) data indicates that earlier 2968 acknowledgements are being delivered to the remote peer. If packets are 2969 reaching the peer, they must also be reaching the sender's next-hop 2970 neighbor; thus "forward progress" is a confirmation that the next-hop 2971 neighbor is reachable. For off-link destinations, forward progress 2972 implies that the first-hop router is reachable. When available, this 2973 upper-layer information SHOULD be used. 2975 In some cases (e.g., UDP-based protocols and routers forwarding packets 2976 to hosts) such reachability information may not be readily available 2977 from upper-layer protocols. When no hints are available and a node is 2978 sending packets to a neighbor, the node actively probes the neighbor 2979 using unicast Neighbor Solicitation messages to verify that the forward 2980 path is still working. 2982 The receipt of a solicited Neighbor Advertisement serves as reachability 2983 confirmation, since advertisements with the Solicited flag set to one 2984 are sent only in response to a Neighbor Solicitation. Receipt of other 2985 Neighbor Discovery messages such as Router Advertisements and Neighbor 2986 Advertisement with the Solicited flag set to zero MUST NOT be treated as 2987 a reachability confirmation. Receipt of unsolicited messages only 2988 confirm the one-way path from the sender to the recipient node. In 2989 contrast, Neighbor Unreachability Detection requires that a node keep 2990 track of the reachability of the forward path to a neighbor from the its 2991 perspective, not the neighbor's perspective. Note that receipt of a 2992 solicited advertisement indicates that a path is working in both 2993 directions. The solicitation must have reached the neighbor, prompting 2994 it to generate an advertisement. Likewise, receipt of an advertisement 2995 indicates that the path from the sender to the recipient is working. 2996 However, the latter fact is known only to the recipient; the 2997 advertisement's sender has no direct way of knowing that the 2998 advertisement it sent actually reached a neighbor. From the perspective 2999 of Neighbor Unreachability Detection, only the reachability of the 3000 forward path is of interest. 3002 7.3.2. Neighbor Cache Entry States 3004 A Neighbor Cache entry can be in one of five states: 3006 INCOMPLETE Address resolution is being performed on the entry. 3007 Specifically, a Neighbor Solicitation has been sent to 3008 the solicited-node multicast address of the target, but 3009 the corresponding Neighbor Advertisement has not yet been 3010 received. 3012 REACHABLE Positive confirmation was received within the last 3013 ReachableTime milliseconds that the forward path to the 3014 neighbor was functioning properly. While REACHABLE, no 3015 special action takes place as packets are sent. 3017 STALE More than ReachableTime milliseconds have elapsed since 3018 the last positive confirmation was received that the 3019 forward path was functioning properly. While stale, no 3020 action takes place until a packet is sent. 3022 The STALE state is entered upon receiving an unsolicited 3023 Neighbor Discovery message that updates the cached link- 3024 layer address. Receipt of such a message does not 3025 confirm reachability, and entering the STALE state 3026 insures reachability is verified quickly if the entry is 3027 actually being used. However, reachability is not 3028 actually verified until the entry is actually used. 3030 DELAY More than ReachableTime milliseconds have elapsed since 3031 the last positive confirmation was received that the 3032 forward path was functioning properly, and a packet was 3033 sent within the last DELAY_FIRST_PROBE_TIME seconds. If 3034 no reachability confirmation is received within 3035 DELAY_FIRST_PROBE_TIME seconds of entering the DELAY 3036 state, send a Neighbor Solicitation and change the state 3037 to PROBE. 3039 The DELAY state is an optimization that gives upper-layer 3040 protocols additional time to provide reachability 3041 confirmation in those cases where ReachableTime 3042 milliseconds have passed since the last confirmation due 3043 to lack of recent traffic. Without this optimization the 3044 opening of a TCP connection after a traffic lull would 3045 initiate probes even though the subsequent three-way 3046 handshake would provide a reachability confirmation 3047 almost immediately. 3049 PROBE A reachability confirmation is actively sought by 3050 retransmitting Neighbor Solicitations every RetransTimer 3051 milliseconds until a reachability confirmation is 3052 received. 3054 7.3.3. Node Behavior 3056 Neighbor Unreachability Detection operates in parallel with the sending 3057 of packets to a neighbor. While reasserting a neighbor's reachability, 3058 a node continues sending packets to that neighbor using the cached 3059 link-layer address. If no traffic is sent to a neighbor, no probes are 3060 sent. 3062 When a node needs to perform address resolution on a neighboring 3063 address, it creates an entry in the INCOMPLETE state and initiates 3064 address resolution as specified in Section 7.2. If address resolution 3065 fails, the entry SHOULD be deleted, so that subsequent traffic to that 3066 neighbor invokes the next-hop determination procedure again. Invoking 3067 next-hop determination at this point insures that alternate default 3068 routers are tried. 3070 When a reachability confirmation is received (either through upper-layer 3071 advice or a solicited Neighbor Advertisement) an entry's state changes 3072 to REACHABLE. The one exception is that upper-layer advice has no 3073 effect on entries in the INCOMPLETE state (e.g., for which no link-layer 3074 address is cached). 3076 When ReachableTime milliseconds have passed since receipt of the last 3077 reachability confirmation for a neighbor, the Neighbor Cache entry's 3078 state changes from REACHABLE to STALE. 3080 Note: An implementation may actually defer changing the state from 3081 REACHABLE to STALE until a packet is sent to the neighbor, i.e., 3082 there need not be an explicit timeout event associated with the 3083 expiration of ReachableTime. 3085 The first time a node sends a packet to a neighbor whose entry is STALE, 3086 the sender changes the state to DELAY and a sets a timer to expire in 3087 DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY 3088 state when the timer expires, the entry's state changes to PROBE. If 3089 reachability confirmation is received, the entry's state changes to 3090 REACHABLE. 3092 Upon entering the PROBE state, a node sends a unicast Neighbor 3093 Solicitation message to the neighbor using the cached link-layer 3094 address. While in the PROBE state, a node retransmits Neighbor 3095 Solicitation messages every RetransTimer milliseconds until reachability 3096 confirmation is obtained. Probes are retransmitted even if no 3097 additional packets are sent to the neighbor. If no response is received 3098 after waiting RetransTimer milliseconds after sending the 3099 MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry 3100 SHOULD be deleted. Subsequent traffic to that neighbor will recreate 3101 the entry and performs address resolution again. 3103 Note that all Neighbor Solicitations are rate-limited on a per-neighbor 3104 basis. A node MUST NOT send Neighbor Solicitations to the same neighbor 3105 more frequently than once every RetransTimer milliseconds. 3107 A Neighbor Cache entry enters the STALE state when created as a result 3108 of receiving packets other than solicited Neighbor Advertisements (i.e., 3109 Router Solicitations, Router Advertisements, Redirects, and Neighbor 3110 Solicitations). These packets contain the link-layer address of either 3111 the sender or, in the case of Redirect, the redirection target. 3112 However, receipt of these link-layer addresses does not confirm 3113 reachability of the forward-direction path to that node. Placing a 3114 newly created Neighbor Cache entry for which the link-layer address is 3115 known in the STALE state provides assurance that path failures are 3116 detected quickly. In addition, should a cached link-layer address be 3117 modified due to receiving one of the above messages the state SHOULD 3118 also be set to STALE to provide prompt verification that the path to the 3119 new link-layer address is working. 3121 To properly detect the case where a router switches from being a router 3122 to being a host (e.g., if its IP forwarding capability is turned off by 3123 system management), a node MUST compare the Router flag field in all 3124 received Neighbor Advertisement messages with the IsRouter flag recorded 3125 in the Neighbor Cache entry. When a node detects that a neighbor has 3126 changed from being a router to being a host, the node MUST remove that 3127 router from the Default Router List and update the Destination Cache as 3128 described in Section 6.3.5. Note that a router may not be listed in the 3129 Default Router List, even though a Destination Cache entry is using it 3130 (e.g., a host was redirected to it). In such cases, all Destination 3131 Cache entries that reference the (former) router must perform next-hop 3132 determination again before using the entry. 3134 In some cases, link-specific information may indicate that a path to a 3135 neighbor has failed (e.g., the resetting of a virtual circuit). In such 3136 cases, link-specific information may be used to purge Neighbor Cache 3137 entries before the Neighbor Unreachability Detection would do so. 3138 However, link-specific information MUST NOT be used to confirm the 3139 reachability of a neighbor; such information does not provide end-to-end 3140 confirmation between neighboring IP layers. 3142 8. REDIRECT FUNCTION 3144 This section describes the functions related to the sending and 3145 processing of Redirect messages. 3147 Redirect messages are sent by routers to redirect a host to a better 3148 first-hop router for a specific destination or to inform hosts that a 3149 destination is in fact a neighbor (i.e., on-link). The latter is 3150 accomplished by having the ICMP Target Address be equal to the ICMP 3151 Destination Address. 3153 A router MUST be able to determine the link-local address for each of 3154 its neighboring routers in order to ensure that the target address in a 3155 Redirect message identifies the neighbor router by its link-local 3156 address. For static routing this requirement implies that the next-hop 3157 router's address should be specified using the link-local address of the 3158 router. For dynamic routing this requirement implies that all IPv6 3159 routing protocols must somehow exchange the link-local addresses of 3160 neighboring routers. 3162 8.1. Validation of Redirect Messages 3164 A host MUST silently discard any received Redirect message that does not 3165 satisfy all of the following validity checks: 3167 - IP Source Address is a link-local address. Routers must use their 3168 link-local address as the source for Router Advertisement and 3169 Redirect messages so that hosts can uniquely identify routers. 3171 - The IP Hop Limit field has a value of 255, i.e., the packet could 3172 not possibly have been forwarded by a router. 3174 - If the message includes an IP Authentication Header, the message 3175 authenticates correctly. 3177 - ICMP Checksum is valid. 3179 - ICMP Code is 0. 3181 - ICMP length (derived from the IP length) is 40 or more octets. 3183 - The IP source address of the Redirect is the same as the current 3184 first-hop router for the specified ICMP Destination Address. 3186 - The ICMP Destination Address field in the redirect message does not 3187 contain a multicast address. 3189 - The ICMP Target Address is either a link-local address (when 3190 redirected to a router) or the same as the ICMP Destination Address 3191 (when redirected to the on-link destination). 3193 - All included options have a length that is greater than zero. 3195 The contents of the Reserved field, and of any unrecognized options MUST 3196 be ignored. Future, backward-compatible changes to the protocol may 3197 specify the contents of the Reserved field or add new options; 3198 backward-incompatible changes may use different Code values. 3200 The contents of any defined options that are not specified to be used 3201 with Redirect messages MUST be ignored and the packet processed as 3202 normal. The only defined options that may appear are the Target Link- 3203 Layer Address option and the Redirected Header option. 3205 A host MUST NOT consider a redirect invalid just because the Target 3206 Address of the redirect is not covered under one of the link's prefixes. 3207 Part of the semantics of the Redirect message is that the Target Address 3208 is on-link. 3210 A redirect that passes the validity checks is called a "valid redirect". 3212 8.2. Router Specification 3214 A router SHOULD send a redirect message, subject to rate limiting, 3215 whenever it forwards a packet that is not explicitly addressed to itself 3216 (i.e. a packet that is not source routed through the router) in which: 3218 - the Source Address field of the packet identifies a neighbor, and 3220 - the router determines that a better first-hop node resides on the 3221 same link as the sending node for the Destination Address of the 3222 packet being forwarded, and 3224 - the Destination Address of the packet is not a multicast address, 3225 and 3227 The transmitted redirect packet contains, consistent with the message 3228 format given in Section 4.5: 3230 - In the Target Address field: the address to which subsequent 3231 packets for the destination SHOULD be sent. If the target is a 3232 router, that router's link-local address MUST be used. If the 3233 target is a host the target address field MUST be set to the same 3234 value as the Destination Address field. 3236 - In the Destination Address field: the destination address of the 3237 invoking IP packet. 3239 - In the options: 3241 o Target Link-Layer Address option: link-layer address of the 3242 target, if known. 3244 o Redirected Header: as much of the forwarded packet as can fit 3245 without the redirect packet exceeding 576 octets in size. 3247 A router MUST limit the rate at which Redirect messages are sent, in 3248 order to limit the bandwidth and processing costs incurred by the 3249 Redirect messages when the source does not correctly respond to the 3250 Redirects, or the source chooses to ignore unauthenticated Redirect 3251 messages. More details on the rate-limiting of ICMP error messages can 3252 be found in [ICMPv6]. 3254 A router MUST NOT update its routing tables upon receipt of a Redirect. 3256 8.3. Host Specification 3258 A host receiving a valid redirect SHOULD update its Destination Cache 3259 accordingly so that subsequent traffic goes to the specified target. If 3260 no Destination Cache entry exists for the destination, an implementation 3261 SHOULD create such an entry. 3263 If the redirect contains a Target Link-Layer Address option the host 3264 either creates or updates the Neighbor Cache entry for the target. In 3265 both cases the cached link-layer address is copied from the Target 3266 Link-Layer Address option. If a Neighbor Cache entry is created for the 3267 target its reachability state MUST be set to STALE as specified in 3268 Section 7.3.3. If a cache entry already existed and it is updated with 3269 a different link-layer address its reachability state MUST also be set 3270 to STALE. 3272 In addition, if the Target Address is the same as the Destination 3273 Address, the host MUST treat the destination as on-link and set the 3274 IsRouter field in the corresponding Neighbor Cache entry to FALSE. 3275 Otherwise it MUST set IsRouter to true. 3277 Redirect messages apply to all flows that are being sent to a given 3278 destination. That is, upon receipt of a Redirect for a Destination 3279 Address, all Destination Cache entries to that address should be updated 3280 to use the specified next-hop, regardless of the contents of the Flow 3281 Label field that appears in the Redirected Header option. 3283 A host MAY have a configuration switch that can be set to make it ignore 3284 a Redirect message that does not have an IP Authentication header. 3286 A host MUST NOT send Redirect messages. 3288 9. EXTENSIBILITY - OPTION PROCESSING 3290 Options provide a mechanism for encoding variable length fields, fields 3291 that may appear multiple times in the same packet, or information that 3292 may not appear in all packets. Options can also be used to add 3293 additional functionality to future versions of ND. 3295 In order to ensure that future extensions properly coexist with current 3296 implementations, all nodes MUST silently ignore any options they do not 3297 recognize in received ND packets and continue processing the packet. 3298 All options specified in this document MUST be recognized. A node MUST 3299 NOT ignore valid options just because the ND message contains 3300 unrecognized ones. 3302 The current set of options is defined in such a way that receivers can 3303 process multiple options in the same packet independently of each other. 3304 In order to maintain these properties future options SHOULD follow the 3305 simple rule: 3307 The option MUST NOT depend on the presence or absence of any other 3308 options. The semantics of an option should depend only on the 3309 information in the fixed part of the ND packet and on the 3310 information contained in the option itself. 3312 Adhering to the above rule has the following benefits: 3314 1) Receivers can process options independently of one another. For 3315 example, an implementation can choose to process the Prefix 3316 Information option contained in a Router Advertisement message in a 3317 user-space process while the link-layer address option in the same 3318 message is processed by routines in the kernel. 3320 2) Should the number of options cause a packet to exceed a link's MTU, 3321 multiple packets can carry subsets of the options without any 3322 change in semantics. 3324 3) Senders MAY send a subset of options in different packets. For 3325 instance, if a prefix's Valid and Preferred Lifetime are high 3326 enough, it might not be necessary to include the Prefix Information 3327 option in every Router Advertisement. In addition, different 3328 routers might send different sets of options. Thus, a receiver 3329 MUST NOT associate any action with the absence of an option in a 3330 particular packet. This protocol specifies that receivers should 3331 only act on the expiration of timers and on the information that is 3332 received in the packets. 3334 Options in Neighbor Discovery packets can appear in any order; receivers 3335 MUST be prepared to process them independently of their order. There 3336 can also be multiple instances of the same option in a message (e.g., 3337 Prefix Information options). 3339 If the number of included options in a Router Advertisement causes the 3340 advertisement's size to exceed the link MTU, the router can send 3341 multiple separate advertisements each containing a subset of the 3342 options. 3344 The amount of data to include in the Redirected Header option MUST be 3345 limited so that the entire redirect packet does not exceed 576 octets. 3347 All options are a multiple of 8 octets of length, ensuring appropriate 3348 alignment without any "pad" options. The fields in the options (as well 3349 as the fields in ND packets) are defined to align on their natural 3350 boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with 3351 the exception of the 128-bit IP addresses/prefixes, which are aligned on 3352 a 64-bit boundary. The link-layer address field contains an 3353 uninterpreted octet string; it is aligned on an 8-bit boundary. 3355 The size of an ND packet including the IP header is limited to the link 3356 MTU (which is at least 576 octets). When adding options to an ND packet 3357 a node MUST NOT exceed the link MTU. 3359 Future versions of this protocol may define new option types. Receivers 3360 MUST silently ignore any options they do not recognize and continue 3361 processing the message. 3363 10. PROTOCOL CONSTANTS 3365 Router constants: 3367 MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds 3369 MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions 3371 MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions 3373 MIN_DELAY_BETWEEN_RAS 3 seconds 3375 MAX_RA_DELAY_TIME .5 seconds 3377 Host constants: 3379 MAX_RTR_SOLICITATION_DELAY 1 second 3381 RTR_SOLICITATION_INTERVAL 4 seconds 3383 MAX_RTR_SOLICITATIONS 3 transmissions 3385 Node constants: 3387 MAX_MULTICAST_SOLICIT 3 transmissions 3389 MAX_UNICAST_SOLICIT 3 transmissions 3391 MAX_ANYCAST_DELAY_TIME 1 second 3393 MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions 3395 REACHABLE_TIME 30,000 milliseconds 3397 RETRANS_TIMER 1,000 milliseconds 3399 DELAY_FIRST_PROBE_TIME 5 seconds 3401 MIN_RANDOM_FACTOR .5 3403 MAX_RANDOM_FACTOR 1.5 3405 Additional protocol constants are defined with the message formats in 3406 Section 4. 3408 All protocol constants are subject to change in future revisions of the 3409 protocol. 3411 The constants in this specification may be overridden by specific 3412 documents that describe how IPv6 operates over different link layers. 3413 This rule allows Neighbor Discovery to operate over links with widely 3414 varying performance characteristics. 3416 11. SECURITY CONSIDERATIONS 3418 Neighbor Discovery is subject to attacks that cause IP packets to flow 3419 to unexpected places. Such attacks can be used to cause denial of 3420 service but also allow nodes to intercept and optionally modify packets 3421 destined for other nodes. 3423 The protocol reduces the exposure to such threats in the absence of 3424 authentication by ignoring ND packets received from off-link senders. 3425 The Hop Limit field of all received packets is verified to contain 255, 3426 the maximum legal value. Because routers decrement the Hop Limit on all 3427 packets they forward, received packets containing a Hop Limit of 255 3428 must have originated from a neighbor. 3430 The trust model for redirects is the same as in IPv4. A redirect is 3431 accepted only if received from the same router that is currently being 3432 used for that destination. It is natural to trust the routers on the 3433 link. If a host has been redirected to another node (i.e., the 3434 destination is on-link) there is no way to prevent the target from 3435 issuing another redirect to some other destination. However, this 3436 exposure is no worse than it was; the target host, once subverted, could 3437 always act as a hidden router to forward traffic elsewhere. 3439 The protocol contains no mechanism to determine which neighbors are 3440 authorized to send a particular type of message e.g. Router 3441 Advertisements; any neighbor, presumably even in the presence of 3442 authentication, can send Router Advertisement messages thereby being 3443 able to cause denial of service. Furthermore, any neighbor can send 3444 proxy Neighbor Advertisements as well as unsolicited Neighbor 3445 Advertisements as a potential denial of service attack. 3447 Neighbor Discovery protocol packet exchanges can be authenticated using 3448 the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an 3449 Authentication Header when sending Neighbor Discovery packets if a 3450 security association for use with the IP Authentication Header exists 3451 for the destination address. The security associations may have been 3452 created through manual configuration or through the operation of some 3453 key management protocol. 3455 Received Authentication Headers in Neighbor Discovery packets MUST be 3456 verified for correctness and packets with incorrect authentication MUST 3457 be ignored. 3459 It SHOULD be possible for the system administrator to configure a node 3460 to ignore any Neighbor Discovery messages that are not authenticated 3461 using either the Authentication Header or Encapsulating Security 3462 Payload. The configuration technique for this MUST be documented. Such 3463 a switch SHOULD default to allowing unauthenticated messages. 3465 Confidentiality issues are addressed by the IP Security Architecture and 3466 the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP]. 3468 REFERENCES 3470 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 3471 Work in Progress. 3473 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing 3474 Architecture", RFC 1884, January, 1996. 3476 [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 3477 Service", RFC 1546, November 1993. 3479 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 3480 RFC 826, November 1982. 3482 [HR-CL] R. Braden, Editor, "Requirements for Internet Hosts -- 3483 Communication Layers", STD 3, RFC 1122, October 1989. 3485 [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 3486 792, September 1981. 3488 [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol 3489 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 3490 1885, January 1996. 3492 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 3493 (IPv6) Specification", RFC 1883, January, 1996. 3495 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 3496 Packets over Ethernet Networks", Work in Progress. 3498 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 3499 Protocol". RFC 1825, August 1995. 3501 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 3502 August 1995. 3504 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 3505 RFC 1827, August 1995. 3507 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 3508 September 1991. 3510 [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture 3511 Extensions for Shared Media", RFC 1620, May 1994. 3513 [ASSIGNED] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 3514 October 1994. 3516 [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing 3517 Messages", IEEE/ACM Transactions on Networking, April 1994. 3518 ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z 3520 AUTHORS' ADDRESSES 3522 Erik Nordmark Thomas Narten 3523 Sun Microsystems, Inc. IBM Corporation 3524 2550 Garcia Ave P.O. Box 12195 3525 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 3526 USA USA 3528 phone: +1 415 786 5166 phone: +1 919 254 7798 3529 fax: +1 415 786 5896 fax: +1 919 254 4027 3530 email: nordmark@sun.com email: narten@vnet.ibm.com 3532 William Allen Simpson 3533 Daydreamer 3534 Computer Systems Consulting Services 3535 1384 Fontaine 3536 Madison Heights, Michigan 48071 3537 USA 3539 email: Bill.Simpson@um.cc.umich.edu 3540 bsimpson@MorningStar.com 3542 APPENDIX A: MULTIHOMED HOSTS 3544 There are a number of complicating issues that arise when Neighbor 3545 Discovery is used by hosts that have multiple interfaces. This section 3546 does not attempt to define the proper operation of multihomed hosts with 3547 regard to Neighbor Discovery. Rather, it identifies issues that require 3548 further study. Implementors are encouraged to experiment with various 3549 approaches to making Neighbor Discovery work on multihomed hosts and to 3550 report their experiences. 3552 If a multihomed host receives Router Advertisements on all of its 3553 interfaces, it will (probably) have learned on-link prefixes for the 3554 addresses residing on each link. When a packet must be sent through a 3555 router, however, selecting the "wrong" router can result in a suboptimal 3556 or non-functioning path. There are number of issues to consider: 3558 1) In order for a router to send a redirect, it must determine that 3559 the packet it is forwarding originates from a neighbor. The 3560 standard test for this case is to compare the source address of the 3561 packet to the list of on-link prefixes associated with the 3562 interface on which the packet was received. If the originating 3563 host is multihomed, however, the source address it uses may belong 3564 to an interface other than the interface from which it was sent. 3565 In such cases, a router will not send redirects, and suboptimal 3566 routing is likely. In order to be redirected, the sending host 3567 must always send packets out the interface corresponding to the 3568 outgoing packet's source address. Note that this issue never 3569 arises with non-multihomed hosts; they only have one interface. 3571 2) If the selected first-hop router does not have a route at all for 3572 the destination, it will be unable to deliver the packet. However, 3573 the destination may be reachable through a router on one of the 3574 other interfaces. Neighbor Discovery does not address this 3575 scenario; it does not arise in the non-multihomed case. 3577 3) Even if the first-hop router does have a route for a destination, 3578 there may be a better route via another interface. No mechanism 3579 exists for the multihomed host to detect this situation. 3581 If a multihomed host fails to receive Router Advertisements on one or 3582 more of its interfaces, it will not know (in the absence of configured 3583 information) which destinations are on-link on the affected 3584 interface(s). This leads to a number of problems: 3586 1) If no Router Advertisement is received on any interfaces, a 3587 multihomed host will have no way of knowing which interface to send 3588 packets out on, even for on-link destinations. Under similar 3589 conditions in the non-multihomed host case, a node treats all 3590 destinations as residing on-link, and communication proceeds. In 3591 the multihomed case, however, additional information is needed to 3592 select the proper outgoing interface. Alternatively, a node could 3593 attempt to perform address resolution on all interfaces, a step 3594 involving significant complexity that is not present in the non- 3595 multihomed host case. 3597 2) If Router Advertisements are received on some, but not all 3598 interfaces, a multihomed host could choose to only send packets out 3599 on the interfaces on which it has received Router Advertisements. 3600 A key assumption made here, however, is that routers on those other 3601 interfaces will be able to route packets to the ultimate 3602 destination, even when those destinations reside on the subnet to 3603 which the sender connects, but has no on-link prefix information. 3604 Should the assumption be false, communication would fail. Even if 3605 the assumption holds, packets will traverse a sub-optimal path. 3607 APPENDIX B: FUTURE EXTENSIONS 3609 Possible extensions for future study are: 3611 o Using dynamic timers to be able to adapt to links with widely varying 3612 delay. Measuring round trip times, however, requires acknowledgments 3613 and sequence numbers in order to match received Neighbor 3614 Advertisements with the actual Neighbor Solicitation that triggered 3615 the advertisement. Implementors wishing to experiment with such a 3616 facility could do so in a backwards-compatible way by defining a new 3617 option carrying the necessary information. Nodes not understanding 3618 the option would simply ignore it. 3620 o Adding capabilities to facilitate the operation over links that 3621 currently require hosts to register with an address resolution 3622 server. This could for instance enable routers to ask hosts to send 3623 them periodic unsolicited advertisements. Once again this can be 3624 added using a new option sent in the Router Advertisements. 3626 o Adding additional procedures for links where asymmetric and non- 3627 transitive reachability is part of normal operations. Such 3628 procedures might allow hosts and routers to find usable paths on, 3629 e.g., radio links. 3631 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE 3633 This appendix contains a summary of the rules specified in Sections 7.2 3634 and 7.3. This document does not mandate that implementations adhere to 3635 this model as long as their external behavior is consistent with that 3636 described in this document. 3638 When performing address resolution and Neighbor Unreachability Detection 3639 the following state transitions apply using the conceptual model: 3641 State Event Action New state 3643 - Packet to send. Create entry. INCOMPLETE 3644 Send multicast NS. 3645 Start retransmit timer 3647 INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE 3648 less than N Start retransmit timer 3649 retransmissions. 3651 INCOMPLETE Retransmit timeout, Discard entry - 3652 N or more Send ICMP error 3653 retransmissions. 3655 INCOMPLETE NA, Solicited=0, Record link-layer STALE 3656 Override=any address. Send queued 3657 packets. 3659 INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3660 Override=any address. Send queued 3661 packets. 3663 !INCOMPLETE NA, Solicited=1, - REACHABLE 3664 Override=0 3666 !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3667 Override=1 address. 3669 !INCOMPLETE NA, Solicited=0, - STALE 3670 Override=0 3672 !INCOMPLETE NA, Solicited=0, Record link-layer STALE 3673 Override=1 address. 3675 !INCOMPLETE upper-layer reachability - REACHABLE 3676 confirmation 3678 REACHABLE timeout, more than - STALE 3679 N seconds since 3680 reachability confirm. 3682 STALE Sending packet Start delay timer DELAY 3684 DELAY Delay timeout Send unicast NS probe PROBE 3685 Start retransmit timer 3687 PROBE Retransmit timeout, Retransmit NS PROBE 3688 less than N 3689 retransmissions. 3691 PROBE Retransmit timeout, Discard entry - 3692 N or more 3693 retransmissions. 3695 The state transitions for receiving unsolicited information other than 3696 Neighbor Advertisement messages apply to either the source of the packet 3697 (for Neighbor Solicitation, Router Solicitation, and Router 3698 Advertisement messages) or the target address (for Redirect messages) as 3699 follows: 3701 State Event Action New state 3703 - NS, RS, RA, Redirect Create entry. STALE 3705 INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE 3706 address. Send queued 3707 packets. 3709 !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE 3710 Different link-layer address 3711 address than cached. 3713 !INCOMPLETE NS, RS, RA, Redirect - unchanged 3714 Same link-layer 3715 address as cached. 3717 APPENDIX D: IMPLEMENTATION ISSUES 3719 Appendix D.1: Reachability confirmations 3721 Neighbor Unreachability Detection requires explicit confirmation that a 3722 forward-path is functioning properly. To avoid the need for Neighbor 3723 Solicitation probe messages, upper layer protocols should provide such 3724 an indication when the cost of doing so is small. Reliable connection- 3725 oriented protocols such as TCP are generally aware when the forward-path 3726 is working. When TCP sends (or receives) data, for instance, it updates 3727 its window sequence numbers, sets and cancels retransmit timers, etc. 3728 Specific scenarios that usually indicate a properly functioning 3729 forward-path include: 3731 - Receipt of an acknowledgement that covers a sequence number (e.g., 3732 data) not previously acknowledged indicates that the forward path was 3733 working at the time the data was sent. 3735 - Completion of the initial three-way handshake is a special case of the 3736 previous rule; although no data is sent during the handshake, the SYN 3737 flags are counted as data from the sequence number perspective. This 3738 applies to both the SYN+ACK for the active open the ACK of that 3739 packet on the passively opening peer. 3741 - Receipt of new data (i.e., data not previously received) indicates 3742 that the forward-path was working at the time an acknowledgement was 3743 sent that advanced the peer's send window that allowed the new data 3744 to be sent. 3746 To minimize the cost of communicating reachability information between 3747 the TCP and IP layers, an implementation may wish to rate-limit the 3748 reachability confirmations its sends IP. One possibility is to process 3749 reachability only every few packets. For example, one might update 3750 reachability information once per round trip time, if an implementation 3751 only has one round trip timer per connection. For those implementations 3752 that cache Destination Cache entries within control blocks, it may be 3753 possible to update the Neighbor Cache entry directly (i.e., without an 3754 expensive lookup) once the TCP packet has been demultiplexed to its 3755 corresponding control block. For other implementation it may be 3756 possible to piggyback the reachability confirmation on the next packet 3757 submitted to IP assuming that the implementation guards against the 3758 piggybacked confirmation becoming stale when no packets are sent to IP 3759 for an extended period of time. 3761 TCP must also guard against thinking "stale" information indicates 3762 current reachability. For example, new data received 30 minutes after a 3763 window has opened up does not constitute a confirmation that the path is 3764 currently working. In merely indicates that 30 minutes ago the window 3765 update reached the peer i.e. the path was working at that point in time. 3766 An implementation must also take into account TCP zero-window probes 3767 that are sent even if the path is broken and the window update did not 3768 reach the peer. 3770 For UDP based applications (RPC, DNS) it is relatively simple to make 3771 the client send reachability confirmations when the response packet is 3772 received. It is more difficult and in some cases impossible for the 3773 server to generate such confirmations since there is no flow control, 3774 i.e., the server can not determine whether a received request indicates 3775 that a previous response reached the client. 3777 Note that an implementation can not use negative upper-layer advise as a 3778 replacement for the Neighbor Unreachability Detection algorithm. 3779 Negative advise (e.g. from TCP when there are excessive retransmissions) 3780 could serve as a hint that the forward path from the sender of the data 3781 might not be working. But it would fail to detect when the path from 3782 the receiver of the data is not functioning causing, none of the 3783 acknowledgement packets to reach the sender.