idnits 2.17.1 draft-ietf-ipngwg-discovery-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) 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 398: '... MUST have a link-local address. Also, [ADDRCONF]...' RFC 2119 keyword, line 417: '... MUST...' RFC 2119 keyword, line 421: '... MUST NOT...' RFC 2119 keyword, line 425: '... SHOULD...' RFC 2119 keyword, line 431: '... SHOULD NOT...' (202 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3616 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 3389, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 3404, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRCONF' -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDR-ARCH' ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCST') -- Possible downref: Non-RFC (?) normative reference: ref. 'ICMPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6' -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ETHER' ** Obsolete normative reference: RFC 1825 (ref. 'IPv6-SA') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'IPv6-AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'IPv6-ESP') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1620 (ref. 'SH-MEDIA') ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'SYNC' Summary: 15 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten, IBM 3 November 17, 1995 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 May 17, 1996. 32 Abstract 34 This document specifies the Neighbor Discovery protocol for IP 35 Version 6. IPv6 nodes on the same link use Neighbor Discovery to 36 discover each other's presence, to determine each other's link-layer 37 addresses, to find routers and to maintain reachability information 38 about the paths to active neighbors. 40 Contents 42 Status of this Memo.......................................... 1 44 1. INTRODUCTION............................................. 4 46 2. TERMINOLOGY.............................................. 4 47 2.1. General............................................. 4 48 2.2. Link Types.......................................... 7 49 2.3. Addresses........................................... 9 50 2.4. Requirements........................................ 10 52 3. PROTOCOL OVERVIEW........................................ 11 53 3.1. Comparison with IPv4................................ 14 54 3.2. Supported Link Types................................ 16 56 4. MESSAGE FORMATS.......................................... 18 57 4.1. Router Solicitation Message Format.................. 18 58 4.2. Router Advertisement Message Format................. 19 59 4.3. Neighbor Solicitation Message Format................ 21 60 4.4. Neighbor Advertisement Message Format............... 23 61 4.5. Redirect Message Format............................. 25 62 4.6. Option Formats...................................... 27 63 4.6.1. Source/Target Link-layer Address............... 28 64 4.6.2. Prefix Information............................. 29 65 4.6.3. Redirected Header.............................. 31 66 4.6.4. MTU............................................ 32 68 5. CONCEPTUAL MODEL OF A HOST............................... 33 69 5.1. Conceptual Data Structures.......................... 33 70 5.2. Conceptual Sending Algorithm........................ 35 71 5.3. Garbage Collection and Timeout Requirements......... 36 73 6. ROUTER AND PREFIX DISCOVERY.............................. 37 74 6.1. Message Validation.................................. 38 75 6.1.1. Validation of Router Solicitation Messages..... 38 76 6.1.2. Validation of Router Advertisement Messages.... 38 77 6.2. Router Specification................................ 39 78 6.2.1. Router Configuration Variables................. 39 79 6.2.2. Becoming An Advertising Interface.............. 43 80 6.2.3. Router Advertisement Message Content........... 43 81 6.2.4. Sending Unsolicited Router Advertisements...... 45 82 6.2.5. Ceasing To Be An Advertising Interface......... 45 83 6.2.6. Processing Router Solicitations................ 46 84 6.2.7. Router Advertisement Consistency............... 47 85 6.2.8. Link-local Address Change...................... 48 86 6.3. Host Specification.................................. 48 87 6.3.1. Host Configuration Variables................... 48 88 6.3.2. Host Variables................................. 48 89 6.3.3. Interface Initialization....................... 50 90 6.3.4. Processing Received Router Advertisements...... 50 91 6.3.5. Timing out Prefixes and Default Routers........ 52 92 6.3.6. Default Router Selection....................... 53 93 6.3.7. Sending Router Solicitations................... 53 95 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 55 96 7.1. Message Validation.................................. 55 97 7.1.1. Validation of Neighbor Solicitations........... 55 98 7.1.2. Validation of Neighbor Advertisements.......... 56 99 7.2. Address Resolution.................................. 56 100 7.2.1. Interface Initialization....................... 57 101 7.2.2. Sending Neighbor Solicitations................. 57 102 7.2.3. Receipt of Neighbor Solicitations.............. 58 103 7.2.4. Sending Solicited Neighbor Advertisements...... 58 104 7.2.5. Receipt of Neighbor Advertisements............. 59 105 7.2.6. Sending Unsolicited Neighbor Advertisements.... 60 106 7.2.7. Anycast Neighbor Advertisements................ 61 107 7.2.8. Proxy Neighbor Advertisements.................. 62 108 7.3. Neighbor Unreachability Detection................... 62 109 7.3.1. Reachability Confirmation...................... 63 110 7.3.2. Neighbor Cache Entry States.................... 64 111 7.3.3. Node Behavior.................................. 65 113 8. REDIRECT FUNCTION........................................ 67 114 8.1. Validation of Redirect Messages..................... 67 115 8.2. Router Specification................................ 68 116 8.3. Host Specification.................................. 69 118 9. EXTENSIBILITY - OPTION PROCESSING........................ 70 120 10. PROTOCOL CONSTANTS...................................... 72 122 11. SECURITY CONSIDERATIONS................................. 73 124 REFERENCES................................................... 75 126 AUTHORS' ADDRESSES........................................... 76 128 APPENDIX A: MULTIHOMED HOSTS................................. 77 130 APPENDIX B: FUTURE EXTENSIONS................................ 78 132 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 79 134 APPENDIX D: IMPLEMENTATION ISSUES............................ 80 135 Appendix D.1: Reachability confirmations.................. 80 137 APPENDIX E: CHANGES SINCE PREVIOUS VERSION................... 82 139 1. INTRODUCTION 141 This specification defines the Neighbor Discovery (ND) protocol for 142 Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use 143 Neighbor Discovery to determine the link-layer addresses for neighbors 144 known to reside on attached links and to quickly purge cached values 145 that become invalid. Hosts also use Neighbor Discovery to find 146 neighboring routers that are willing to forward packets on their behalf. 147 Finally, nodes use the protocol to actively keep track of which 148 neighbors are reachable and which are not, and to detect changed link- 149 layer addresses. When a router or the path to a router fails, a host 150 actively searches for functioning alternates. 152 This document is a revision of 153 which was itself based on the protocol specified in the two documents: 154 , and 155 157 The authors would like to acknowledge the contributions the IPNGWG 158 working group an, in particular, (in alphabetical order) Ran Atkinson, 159 Jim Bound, Scott Bradner, Stephen Deering, Francis Dupont, Robert Elz, 160 Robert Gilligan, Robert Hinden, Allison Mankin, Dan McDonald, Charles 161 Perkins, Matt Thomas, and Susan Thomson. 163 2. TERMINOLOGY 165 2.1. General 167 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 168 are used only in contexts where necessary to avoid 169 ambiguity. 171 ICMP - Internet Message Control Protocol for the Internet 172 Protocol Version 6. The terms ICMPv4 and ICMPv6 are 173 used only in contexts where necessary to avoid 174 ambiguity. 176 node - a device that implements IP. 178 router - a node that forwards IP packets not explicitly 179 addressed to itself. 181 host - any node that is not a router. 183 upper layer - a protocol layer immediately above IP. Examples are 184 transport protocols such as TCP and UDP, control 185 protocols such as ICMP, routing protocols such as OSPF, 186 and internet or lower-layer protocols being "tunneled" 187 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 188 or IP itself. 190 link - a communication facility or medium over which nodes can 191 communicate at the link layer, i.e., the layer 192 immediately below IP. Examples are Ethernets (simple 193 or bridged), PPP links, X.25, Frame Relay, or ATM 194 networks as well as internet (or higher) layer 195 "tunnels", such as tunnels over IPv4 or IPv6 itself. 197 interface - a node's attachment to a link. 199 neighbors - nodes attached to the same link. 201 address - an IP-layer identifier for an interface or a set of 202 interfaces. 204 anycast address 205 - an identifier for a set of interfaces (typically 206 belonging to different nodes). A packet sent to an 207 anycast address is delivered to one of the interfaces 208 identified by that address (the "nearest" one, 209 according to the routing protocol's measure of 210 distance). See [ADDR-ARCH]. 212 prefix - a bit string that consists of some number of initial 213 bits of an address. 215 link-layer address 216 - a link-layer identifier for an interface. Examples 217 include IEEE 802 addresses for Ethernet links and E.164 218 addresses for ISDN links. 220 on-link - an address that is assigned to an interface on a 221 specified link. A node considers an address to be on- 222 link if: 224 - it is covered by one of the link's prefixes, or 226 - a neighboring router specifies the address as the 227 target of a Redirect message, or 229 - a Neighbor Advertisement message is received for 230 the (target) address, or 232 - any Neighbor Discovery message is received from the 233 address. 235 off-link - the opposite of "on-link"; an address that is not 236 assigned to any interfaces on the specified link. 238 reachability 239 - whether or not the one-way "forward" path to a neighbor 240 is functioning properly. In particular, whether 241 packets sent to a neighbor are reaching the IP layer on 242 the neighboring machine and are being processed 243 properly by the receiving IP layer. For neighboring 244 routers, reachability means that packets sent by a 245 node's IP layer are delivered to the router's IP layer, 246 and the router is indeed forwarding packets (i.e., it 247 is configured as a router, not a host). For hosts, 248 reachability means that packets sent by a node's IP 249 layer are delivered to the neighbor host's IP layer. 251 packet - an IP header plus payload. 253 link MTU - the maximum transmission unit, i.e., maximum packet 254 size in octets, that can be conveyed in one piece over 255 a link. 257 target - an address about which address resolution information 258 is sought, or an address which is the new first-hop 259 when being redirected. 261 proxy - a router that responds to Neighbor Discovery query 262 messages on behalf of another node. A router acting on 263 behalf of a mobile node that has moved off-link could 264 potentially act as a proxy for the mobile node. 266 ICMP destination unreachable indication 267 - an error indication returned to the original sender of 268 a packet that cannot be delivered for the reasons 269 outlined in [ICMPv6]. If the error occurs on a node 270 other than the node originating the packet, an ICMP 271 error message is generated. If the error occurs on the 272 originating node, an implementation is not required to 273 actually create and send an ICMP error packet to the 274 source, as long as the upper-layer sender is notified 275 through an appropriate mechanism (e.g., return value 276 from a procedure call). Note, however, that an 277 implementation may find it convenient in some cases to 278 return errors to the sender by taking the offending 279 packet, generating an ICMP error message, and then 280 delivering it (locally) through the generic error 281 handling routines. 283 random delay 284 - when sending out messages, it is sometimes necessary to 285 delay a transmission for a random amount of time in 286 order to prevent multiple nodes from transmitting at 287 exactly the same time, or to prevent long-range 288 periodic transmissions from synchronizing with each 289 other [SYNC]. When a random component is required, a 290 node calculates the actual delay in such a way that the 291 computed delay forms a uniformly-distributed random 292 value that falls between the specified minimum and 293 maximum delay times. The implementor must take care to 294 insure that the granularity of the calculated random 295 component and the resolution of the timer used are both 296 high enough to insure that the probability of multiple 297 nodes delaying the same amount of time is small. 299 random delay seed 300 - If a pseudo-random number generator is used in 301 calculating a random delay component, the generator 302 should be initialized with a unique seed prior to being 303 used. Note that it is not sufficient to use the 304 interface token alone as the seed, since interface 305 tokens will not always be unique. To reduce the 306 probability that duplicate interface tokens cause the 307 same seed to be used, the seed should be calculated 308 from a variety of input sources (e.g., machine 309 components) that are likely to be different even on 310 identical "boxes". For example, the seed could be 311 formed by combining the CPU's serial number with an 312 interface token. 314 2.2. Link Types 316 Different link layers have different properties. The ones of concern to 317 Neighbor Discovery are: 319 multicast - a link that supports some mechanism at the link 320 layer for sending packets to all (i.e., broadcast) 321 or a subset of all neighbors. Multicast/broadcast 322 can be provided by a variety of link layer 323 mechanisms such as the physical link layer itself 324 (for example, Ethernet), replicated unicast packets 325 sent by the link layer software, or multicast 326 servers (such as in ATM). Note that all point-to- 327 point links are trivially capable of supporting 328 multicast. 330 point-to-point - a link that connects exactly two interfaces. A 331 point-to-point link is assumed to have multicast 332 capability and have a link-local address. 334 non-broadcast multi-access (NBMA) 335 - a link to which more than two interfaces can attach, 336 but that does not support any form of multicast or 337 broadcast (e.g., X.25). 339 shared media - a link that allows direct communication among a 340 number of nodes, but attached nodes are configured 341 in such a way that they do not have complete prefix 342 information for all on-link destinations. That is, 343 at the IP level, nodes on the same link may not know 344 that they are neighbors; by default, they 345 communicate through a router. Examples are large 346 (switched) public data networks such as SMDS and B- 347 ISDN. Also known as "large clouds". See [SH- 348 MEDIA]. 350 variable MTU - a link that does not have a well-defined MTU (e.g., 351 IEEE 802.5 token rings). Many links (e.g., 352 Ethernet) have a standard MTU defined by the link- 353 layer protocol or by the specific document 354 describing how to run IP over the link layer. 356 asymmetric reachability 357 - a link where non-reflexive and/or non-transitive 358 reachability is part of normal operation. (Non- 359 reflexive reachability means packets from A reach B 360 but packets from B don't reach A. Non-transitive 361 reachability means packets from A reach B, and 362 packets from B reach C, but packets from A don't 363 reach C.) Many radio links exhibit these 364 properties. 366 2.3. Addresses 368 Neighbor Discovery makes use of a number of different addresses defined 369 in [ADDR-ARCH], including: 371 all-nodes multicast address 372 - the link-local scope address to reach all nodes. 373 FF02::1 375 all-routers multicast address 376 - the link-local scope address to reach all routers. 377 FF02::2 379 solicited-node multicast address 380 - a link-local scope multicast address that is computed 381 as a function of the solicited target's address. The 382 solicited-node multicast address is formed by taking 383 the low-order 32 bits of the target IP address and 384 appending those bits to the 96-bit prefix 385 FF02:0:0:0:0:1 to produce a multicast address within 386 the range FF02::1:0:0 to FF02::1:FFFF:FFFF. For 387 example, the solicited node multicast address 388 corresponding to the IP address 4037::01:800:200E:8C6C 389 is FF02::1:200E:8C6C. IP addresses that differ only in 390 the high-order bits, e.g., due to multiple high-order 391 prefixes associated with different providers, will map 392 to the same solicited-node address thereby reducing the 393 number of multicast addresses a node must join. 395 link-local address 396 - a unicast address having link-only scope that can be 397 used to reach neighbors. All interfaces on routers 398 MUST have a link-local address. Also, [ADDRCONF] 399 requires that interfaces on hosts have a link-local 400 address. 402 unspecified address 403 - a reserved address value that indicates the lack of an 404 address (e.g., the address is unknown). It is never 405 used as a destination address, but may be used as a 406 source address if the sender does not (yet) know its 407 own address (e.g., while verifying an address is unused 408 during address autoconfiguration [ADDRCONF]). The 409 unspecified address has a value of 0:0:0:0:0:0:0:0. 411 2.4. Requirements 413 Throughout this document, the words that are used to define the 414 significance of the particular requirements are capitalized. These 415 words are: 417 MUST 418 This word or the adjective "REQUIRED" means that the item is an 419 absolute requirement of this specification. 421 MUST NOT 422 This phrase means the item is an absolute prohibition of this 423 specification. 425 SHOULD 426 This word or the adjective "RECOMMENDED" means that there may 427 exist valid reasons in particular circumstances to ignore this 428 item, but the full implications should be understood and the 429 case carefully weighed before choosing a different course. 431 SHOULD NOT 432 This phrase means that there may exist valid reasons in 433 particular circumstances when the listed behavior is acceptable 434 or even useful, but the full implications should be understood 435 and the case carefully weighted before implementing any behavior 436 described with this label. 438 MAY This word or the adjective "OPTIONAL" means that this item is 439 truly optional. One vendor may choose to include the item 440 because a particular marketplace requires it or because it 441 enhances the product, for example, another vendor may omit the 442 same item. 444 This document also makes use of internal conceptual variables to 445 describe protocol behavior and external variables that an implementation 446 must allow system administrators to change. The specific variable 447 names, how their values change, and how their settings influence 448 protocol behavior are provided to demonstrate protocol behavior. An 449 implementation is not required to have them in the exact form described 450 here, so long as its external behavior is consistent with that described 451 in this document. 453 3. PROTOCOL OVERVIEW 455 This protocol solves a set of problems related to the interaction 456 between nodes attached to the same link. It defines mechanisms for 457 solving each of the following problems: 459 Router Discovery: How hosts locate routers that reside on an 460 attached link. 462 Prefix Discovery: How hosts discover the set of address prefixes 463 that define which destinations are on-link for an 464 attached link. (Nodes use prefixes to distinguish 465 destinations that reside on-link from those only 466 reachable through a router.) 468 Parameter Discovery: How a node learns such link parameters as the 469 link MTU or such Internet parameters as the maximum hop 470 limit value to place in outgoing packets. 472 Address Autoconfiguration: How nodes automatically configure an 473 address for an interface. 475 Address resolution: How nodes determine the link-layer address of an 476 on-link destination (e.g., a neighbor) given only the 477 destination's IP address. 479 Next-hop determination: The algorithm for mapping an IP destination 480 address into the IP address of the neighbor to which 481 traffic for the destination should be sent. The next-hop 482 can be a router or the destination itself. 484 Neighbor Unreachability Detection: How nodes determine that a 485 neighbor is no longer reachable. For neighbors used as 486 routers, alternate default routers can be tried. For 487 both routers and hosts, address resolution can be 488 performed again. 490 Duplicate Address Detection: How a node determines that an address 491 it wishes to use is not already in use by another node. 493 Redirect: How a router informs a host of a better first-hop node to 494 reach a particular destination. 496 Neighbor Discovery defines five different ICMP packet types: A pair of 497 Router Solicitation and Router Advertisement messages, a pair of 498 Neighbor Solicitation and Neighbor Advertisements messages, and a 499 Redirect message. The messages serve the following purpose: 501 Router Solicitation: When an interface becomes enabled, hosts may 502 send out Router Solicitations that request routers to 503 generate Router Advertisements immediately rather than at 504 their next scheduled time. 506 Router Advertisement: Routers advertise their presence together with 507 various link and Internet parameters either periodically, 508 or in response to a Router Solicitation message. Router 509 Advertisements contain prefixes that are used for on-link 510 determination and/or address configuration, a maximum hop 511 limit value, etc. 513 Neighbor Solicitation: Sent by a node to determine the link-layer 514 address of a neighbor, or to verify that a neighbor is 515 still reachable via a cached link-layer address. 516 Neighbor Solicitations are also used for Duplicate 517 Address Detection. 519 Neighbor Advertisement: A response to a Neighbor Solicitation 520 message. A node may also send unsolicited Neighbor 521 Advertisements to announce a link-layer address change. 523 Redirect: Used by routers to inform hosts of a better first hop for 524 a destination. 526 On multicast-capable links, each router periodically multicasts a Router 527 Advertisement packet announcing its availability. A host receives 528 Router Advertisements from all routers, building a list of default 529 routers. Routers generate Router Advertisements frequently enough that 530 hosts will learn of their presence within a few minutes, but not 531 frequently enough to rely on an absence of advertisements to detect 532 router failure; a separate Neighbor Unreachability Detection algorithm 533 provides failure detection. 535 Router Advertisements contain a list of prefixes used for on-link 536 determination and/or autonomous address configuration; flags associated 537 with the prefixes specify the intended uses of a particular prefix. 538 Hosts use the advertised on-link prefixes to build and maintain a list 539 that is used in deciding when a packet's destination is on-link or 540 beyond a router. Note that a destination can be on-link even though it 541 is not covered by any advertised on-link prefix. In such cases a router 542 can send a Redirect informing the sender that the destination is a 543 neighbor. 545 Router Advertisements (and per-prefix flags) allow routers to inform 546 hosts how to perform Address Autoconfiguration. For example, routers 547 can specify whether hosts should use stateful (DHCPv6) and/or autonomous 548 (stateless) address configuration. The exact semantics and usage of the 549 address configuration-related information is specified in [ADDRCONF]. 551 Router Advertisement messages also contain Internet parameters such as 552 the maximum hop limit that hosts should use in outgoing packets and, 553 optionally, link parameters such as the link MTU. This facilitates 554 centralized administration of critical parameters that can be set on 555 routers and automatically propagated to all attached hosts. 557 Nodes accomplish address resolution by multicasting a Neighbor 558 Solicitation that asks the target node to return its link-layer address. 559 Neighbor Solicitation messages are multicast to the solicited-node 560 multicast address of the target address. The target returns its link- 561 layer address in a unicast Neighbor Advertisement message. A single 562 request-response pair of packets is sufficient for both the initiator 563 and the target to resolve each other's link-layer addresses; the 564 initiator includes its link-layer address in the Neighbor Solicitation. 566 Neighbor Solicitation messages can also be used to determine if more 567 than one node has been assigned the same unicast address. The use of 568 Neighbor Solicitation messages for Duplicate Address Detection is 569 specified in [ADDRCONF]. 571 Neighbor Unreachability Detection detects the failure of a neighbor or 572 the failure of the forward path to the neighbor. Doing so requires 573 positive confirmation that packets sent to a neighbor are actually 574 reaching that neighbor and being processed properly by its IP layer. 575 Neighbor Unreachability Detection uses confirmation from two sources. 576 When possible, upper-layer protocols provide a positive confirmation 577 that a connection is making "forward progress", that is, previously sent 578 data is known to have been delivered correctly (e.g., new 579 acknowledgments were received recently). When positive confirmation is 580 not forthcoming through such "hints", a node sends unicast Neighbor 581 Solicitation messages that solicit Neighbor Advertisements as 582 reachability confirmation from the next hop. To reduce unnecessary 583 network traffic, probe messages are only sent to neighbors to which the 584 node is actively sending packets. 586 In addition to addressing the above general problems, Neighbor Discovery 587 also handles the following situations: 589 Link-layer address change - A node that knows its link-layer 590 address has changed can multicast a few (unsolicited) Neighbor 591 Advertisement packets to all nodes to quickly update cached 592 link-layer addresses that have become invalid. Note that the 593 sending of unsolicited advertisements is a performance 594 enhancement only (e.g., unreliable). The Neighbor 595 Unreachability Detection algorithm ensures that all nodes will 596 reliably discover the new address, though the delay may be 597 somewhat longer. 599 Inbound load balancing - Nodes with replicated interfaces may want 600 to load balance the reception of incoming packets across 601 multiple network interfaces on the same link. Such nodes have 602 multiple link-layer addresses assigned to the same interface. 603 For example, a single network driver could represent multiple 604 network interface cards as a single logical interface having 605 multiple link-layer addresses. Load balancing is handled by 606 allowing routers to omit the source link-layer address from 607 Router Advertisement packets, thereby forcing neighbors to use 608 Neighbor Solicitation messages to learn link-layer addresses 609 of routers. Returned Neighbor Advertisement messages can then 610 contain link-layer addresses that differ depending on who 611 issued the solicitation. 613 Anycast addresses - Anycast addresses identify one of a set of 614 nodes providing an equivalent service, and multiple nodes on 615 the same link may be configured to recognize the same Anycast 616 address. Neighbor Discovery handles anycasts by having nodes 617 expect to receive multiple Neighbor Advertisements for the 618 same target. All advertisements for anycast addresses are 619 tagged as being non-Override advertisements. This invokes 620 specific rules to determine which of potentially multiple 621 advertisements should be used. 623 Proxy advertisements - A router willing to accept packets on behalf 624 of a target address that is unable to respond to Neighbor 625 Solicitations can issue non-Override Neighbor Advertisements. 626 There is currently no specified use of proxy, but proxy 627 advertising could potentially be used to handle cases like 628 mobile nodes that have moved off-link. However, it is not 629 intended as a general mechanism to handle nodes that, e.g., do 630 not implement this protocol. 632 3.1. Comparison with IPv4 634 The IPv6 Neighbor Discovery protocol corresponds to a combination of the 635 IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP 636 Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol 637 or mechanism for Neighbor Unreachability Detection, although Hosts 638 Requirements [HR-CL] does specify some possible algorithms for Dead 639 Gateway Detection (a subset of the problems Neighbor Unreachability 640 Detection tackles). 642 The Neighbor Discovery protocol provides a multitude of improvements 643 over the IPv4 set of protocols: 645 Router Discovery is part of the base protocol set; there is no need 646 for hosts to "snoop" the routing protocols. 648 Router advertisements carry link-layer addresses; no additional 649 packet exchange is needed to resolve the router's link-layer 650 address. 652 Router advertisements carry prefixes for a link; there is no need 653 to have a separate mechanism to configure the "netmask". 655 Router advertisements enable Address Autoconfiguration. 657 Routers can advertise an MTU for hosts to use on the link, ensuring 658 that all nodes use the same MTU value on links lacking a well- 659 defined MTU. 661 Address resolution multicasts are "spread" over 4 billion (2^32) 662 multicast addresses greatly reducing address resolution related 663 interrupts on nodes other than the target. Moreover, non-IPv6 664 machines should not be interrupted at all. 666 Redirects contain the link-layer address of the new first hop; 667 separate address resolution is not needed upon receiving a 668 redirect. 670 Multiple prefixes can be associated with the same link. By 671 default, hosts learn all on-link prefixes from Router 672 Advertisements. However, routers may be configured to omit some or 673 all prefixes from Router Advertisements. In such cases hosts 674 assume that destinations are off-link and send traffic to routers. 675 A router can then issue redirects as appropriate. 677 Unlike IPv4, the recipient of an IPv6 redirect assumes that the new 678 next-hop is on-link. In IPv4, a host ignores redirects specifying 679 a next-hop that is not on-link according to the link's network 680 mask. The IPv6 redirect mechanism is analogous to the XRedirect 681 facility specified in [SH-MEDIA]. It is expected to be useful on 682 non-broadcast and shared media links in which it is undesirable or 683 not possible for nodes to know all prefixes for on-link 684 destinations. 686 Neighbor Unreachability Detection is part of the base significantly 687 improving the robustness of packet delivery in the presence of 688 failing routers, partially failing or partitioned links and nodes 689 that change their link-layer addresses. For instance, mobile nodes 690 can move off-link without losing any connectivity due to stale ARP 691 caches. 693 Unlike ARP, Neighbor Discovery detects half-link failures (using 694 Neighbor Unreachability Detection) and avoids sending traffic to 695 neighbors with which two-way connectivity is absent. 697 Unlike in IPv4 Router Discovery the Router Advertisement messages 698 do not contain a preference field. The preference field is not 699 needed to handle routers of different "stability"; the Neighbor 700 Unreachability Detection will detect dead routers and switch to a 701 working one. 703 The use of link-local addresses to uniquely identify routers (for 704 Router Advertisement and Redirect messages) makes it possible for 705 hosts the maintain the router associations in the event of the site 706 renumbering to use new global prefixes. 708 Using the Hop Limit equal to 255 trick Neighbor Discovery is immune 709 to off-link senders that accidentally of intentionally send ND 710 messages. In IPv4 off-link senders can send both ICMP Redirects 711 and Router Advertisement messages. 713 Placing address resolution at the ICMP layer makes the protocol 714 more media-independent than ARP and makes it possible to use 715 standard IP authentication and security mechanisms as appropriate 716 [IPv6-AUTH, IPv6-ESP]. 718 3.2. Supported Link Types 720 Neighbor Discovery supports links with different properties. In the 721 presence of certain properties only a subset of the ND protocol is 722 available: 724 point-to-point - Neighbor Discovery handles such links just like 725 multicast links. (Multicast can be trivially 726 provided on point to point links, and interfaces can 727 be assigned link-local addresses.) 729 multicast - All aspects of Neighbor Discovery are available. 731 non-broadcast multiple access (NBMA) 732 - The only Neighbor Discovery mechanisms available on 733 these links are Redirect handling and Neighbor 734 Unreachability Detection. 736 If hosts support manual configuration of a list of 737 default routers, the hosts can dynamically acquire 738 the link-layer addresses for their neighbors from 739 Redirect messages. 741 shared media - The Redirect message is modeled after the XRedirect 742 message in [SH-MEDIA] in order to simplify use of 743 the protocol on shared media links. 745 This specification does not address shared media 746 issues that only relate to routers, such as: 748 - How routers exchange reachability information on 749 a shared media link. 751 - How a router determines the link-layer address of 752 a host, which it needs to send redirect messages 753 to the host. 755 - How a router determines that it is the first-hop 756 router for a received packet. 758 The protocol is extensible (through the definition 759 of new options) so that other solutions might be 760 possible in the future. 762 variable MTU - Neighbor Discovery allows routers to specify a MTU 763 for the link, which all nodes then use. All nodes 764 on a link must use the same MTU (or Maximum Receive 765 Unit) in order for multicast to work properly. 766 Otherwise when multicasting a sender, which can not 767 know which nodes will receive the packet, could not 768 determine a minimum packet size all receivers can 769 process. 771 asymmetric reachability 772 - Neighbor Discovery detects the absence of symmetric 773 reachability; a node avoids paths to a neighbor with 774 which it does not have symmetric connectivity. 776 The Neighbor Unreachability Detection will typically 777 identify such half-links and the node will refrain 778 from using them. 780 The protocol can presumably be extended in the 781 future to find viable paths in environments that 782 lack reflexive and transitive connectivity. 784 4. MESSAGE FORMATS 786 4.1. Router Solicitation Message Format 788 Hosts send Router Solicitations in order to prompt routers to generate 789 Router Advertisements quickly. 791 0 1 2 3 792 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 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | Type | Code | Checksum | 795 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 796 | Reserved | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 | Options ... 799 +-+-+-+-+-+-+-+-+-+-+-+- 801 IP Fields: 803 Source Address 804 An IP address assigned to the sending interface. If 805 no address is assigned the unspecified address can be 806 used. 808 Destination Address 809 Typically the all-routers multicast address. 811 Hop Limit 255 813 Priority 15 815 Authentication Header 816 If a Security Association for the IP Authentication 817 Header exists between the sender and the destination 818 address, then the sender SHOULD include this header. 820 ICMP Fields: 822 Type 133 824 Code 0 826 Checksum The ICMP checksum. See [ICMPv6]. 828 Reserved This field is unused. It MUST be initialized to zero 829 by the sender and MUST be ignored by the receiver. 831 Valid Options: 833 Source link-layer address 834 The link-layer address of the sender, if known. 836 Future versions of this protocol may define new option types. 837 Receivers MUST silently ignore any options they do not recognize and 838 continue processing the message. 840 4.2. Router Advertisement Message Format 842 Routers send out Router Advertisement message periodically, or in 843 response to a Router Solicitation. 845 0 1 2 3 846 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 847 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 848 | Type | Code | Checksum | 849 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 850 | Max Hop Limit |M|O| Reserved | Router Lifetime | 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 | Reachable Time | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Retrans Timer | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 856 | Options ... 857 +-+-+-+-+-+-+-+-+-+-+-+- 859 IP Fields: 861 Source Address 862 MUST be the link-local address assigned to the 863 interface from which this message is sent. 865 Destination Address 866 Typically the Source Address of an invoking Router 867 Solicitation or the all-nodes multicast address. 869 Hop Limit 255 871 Priority 15 873 Authentication Header 874 If a Security Association for the IP Authentication 875 Header exists between the sender and the destination 876 address, then the sender SHOULD include this header. 878 ICMP Fields: 880 Type 134 882 Code 0 884 Checksum The ICMP checksum. See [ICMPv6]. 886 Max Hop Limit 8-bit unsigned integer. The maximum hop limit that 887 hosts should place in outgoing IP packets. A value of 888 zero means unspecified (by this router). 890 M 1-bit "Managed address configuration" flag. When set, 891 hosts use the administered (stateful) protocol for 892 address autoconfiguration in addition to any addresses 893 autoconfigured using stateless address 894 autoconfiguration. The use of this flag is described 895 in [ADDRCONF]. 897 O 1-bit "Other stateful configuration" flag. When set, 898 hosts use the administered (stateful) protocol for 899 autoconfiguration of other (non-address) information. 900 The use of this flag is described in [ADDRCONF]. 902 Reserved A 6-bit unused field. It MUST be initialized to zero 903 by the sender and MUST be ignored by the receiver. 905 Router Lifetime 906 16-bit unsigned integer. The lifetime associated with 907 the default router in units of seconds. The maximum 908 value corresponds to 18.2 hours. A Lifetime of 0 909 indicates that the router is not a default router and 910 SHOULD NOT appear on the default router list. The 911 Router Lifetime applies only to the router's 912 usefulness as a default router; it does not apply to 913 information contained in other message fields or 914 options. Options that need time limits for their 915 information include their own lifetime fields. 917 Reachable Time 32-bit unsigned integer. The time, in milliseconds, 918 that a node assumes a neighbor is reachable after 919 having received a reachability confirmation. Used by 920 the Neighbor Unreachability Detection algorithm (see 921 Section 7.3). A value of zero means unspecified (by 922 this router). 924 Retrans Timer 32-bit unsigned integer. The time, in milliseconds, 925 between retransmitted Neighbor Solicitation messages. 927 Used by address resolution and the Neighbor 928 Unreachability Detection algorithm (see Sections 7.2 929 and 7.3). A value of zero means unspecified (by this 930 router). 932 Possible options: 934 Source link-layer address 935 The link-layer address of the interface from which the 936 Router Advertisement is sent. Only used on link 937 layers that have addresses. A router MAY omit this 938 option in order to enable inbound load sharing across 939 multiple link-layer addresses. 941 MTU SHOULD be sent on links that have a variable MTU (as 942 specified in the document that describes how to run IP 943 over the particular link type). MAY be sent on other 944 links. 946 Prefix Information 947 These options specify the prefixes that are on-link 948 and/or are used for address autoconfiguration. A 949 router SHOULD include all its on-link prefixes so that 950 multihomed hosts have complete prefix information 951 about on-link destinations for the links to which they 952 attach. If complete information is lacking, a 953 multihomed host may not be able to chose the correct 954 outgoing interface when sending traffic to its 955 neighbors. 957 Future versions of this protocol may define new option types. 958 Receivers MUST silently ignore any options they do not recognize and 959 continue processing the message. 961 4.3. Neighbor Solicitation Message Format 963 Nodes send Neighbor Solicitations to request the link-layer address of a 964 target node while also providing their own link-layer address to the 965 target. Neighbor Solicitations are multicast when the node needs to 966 resolve an address and unicast when the node seeks to verify the 967 reachability of a neighbor. 969 0 1 2 3 970 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 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 972 | Type | Code | Checksum | 973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 974 | Reserved | 975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 976 | | 977 + + 978 | | 979 + Target Address + 980 | | 981 + + 982 | | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Options ... 985 +-+-+-+-+-+-+-+-+-+-+-+- 987 IP Fields: 989 Source Address 990 Either an address assigned to the interface from which 991 this message is sent or (if Duplicate Address 992 Detection is in progress [ADDRCONF]) the unspecified 993 address. 995 Destination Address 996 Either the solicited-node multicast address 997 corresponding to the target address, or the target 998 address. 1000 Hop Limit 255 1002 Priority 15 1004 Authentication Header 1005 If a Security Association for the IP Authentication 1006 Header exists between the sender and the destination 1007 address, then the sender SHOULD include this header. 1009 ICMP Fields: 1011 Type 135 1013 Code 0 1015 Checksum The ICMP checksum. See [ICMPv6]. 1017 Reserved This field is unused. It MUST be initialized to zero 1018 by the sender and MUST be ignored by the receiver. 1020 Target Address 1021 The IP address of the target of the solicitation. It 1022 MUST NOT be a multicast address. 1024 Possible options: 1026 Source link-layer address 1027 The link-layer address for the sender. SHOULD be 1028 included on link layers that have addresses. 1030 Future versions of this protocol may define new option types. 1031 Receivers MUST silently ignore any options they do not recognize and 1032 continue processing the message. 1034 4.4. Neighbor Advertisement Message Format 1036 A node sends Neighbor Advertisements in response to Neighbor 1037 Solicitations and sends unsolicited Neighbor Advertisements in order to 1038 (unreliably) propagate new information quickly. 1040 0 1 2 3 1041 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 1042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1043 | Type | Code | Checksum | 1044 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1045 |R|S|O| Reserved | 1046 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1047 | | 1048 + + 1049 | | 1050 + Target Address + 1051 | | 1052 + + 1053 | | 1054 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1055 | Options ... 1056 +-+-+-+-+-+-+-+-+-+-+-+- 1058 IP Fields: 1060 Source Address 1061 An address assigned to the interface from which the 1062 advertisement is sent. 1064 Destination Address 1065 For solicited advertisements, the Source Address of an 1066 invoking Neighbor Solicitation or, if the 1067 solicitation's Source Address is the unspecified 1068 address, the all-nodes multicast address. 1070 For unsolicited advertisements typically the all-nodes 1071 multicast address. 1073 Hop Limit 255 1075 Priority 15 1077 Authentication Header 1078 If a Security Association for the IP Authentication 1079 Header exists between the sender and the destination 1080 address, then the sender SHOULD include this header. 1082 ICMP Fields: 1084 Type 136 1086 Code 0 1088 Checksum The ICMP checksum. See [ICMPv6]. 1090 R Router flag. When set, the R-bit indicates that the 1091 sender is a router. The R-bit is used by Neighbor 1092 Unreachability Detection to detect a router that 1093 changes to a host. 1095 S Solicited flag. When set, the S-bit indicates that 1096 the advertisement was sent in response to a Neighbor 1097 Solicitation from the Destination address. The S-bit 1098 is used as a reachability confirmation for Neighbor 1099 Unreachability Detection. It MUST NOT be set in 1100 multicast advertisements or in unsolicited unicast 1101 advertisements. 1103 O Override flag. When set, the O-bit indicates that the 1104 advertisement should override an existing cache entry 1105 and update the cached link-layer address. When it is 1106 not set the advertisement will not update a cached 1107 link-layer address though it will update an existing 1108 Neighbor Cache entry for which no link-layer address 1109 is known. It SHOULD NOT be set in solicited 1110 advertisements for anycast addresses and in solicited 1111 proxy advertisements. It SHOULD be set in other 1112 solicited advertisements and in unsolicited 1113 advertisements. 1115 Reserved 29-bit unused field. It MUST be initialized to zero 1116 by the sender and MUST be ignored by the receiver. 1118 Target Address 1119 For solicited advertisements, the Target Address field 1120 in the Neighbor Solicitation message that prompted 1121 this advertisement. For an unsolicited advertisement, 1122 the address whose link-layer address has changed. The 1123 Target Address MUST NOT be a multicast address. 1125 Possible options: 1127 Target link-layer address 1128 The link-layer address for the target, i.e., the 1129 sender of the advertisement. MUST be included on link 1130 layers that have addresses. 1132 Future versions of this protocol may define new option types. 1133 Receivers MUST silently ignore any options they do not recognize and 1134 continue processing the message. 1136 4.5. Redirect Message Format 1138 Routers send Redirect packets to inform a host of a better first-hop 1139 node on the path to a destination. Hosts can be redirected to a better 1140 first-hop router but can also be informed by a redirect that the 1141 destination is in fact a neighbor. The latter is accomplished by 1142 setting the ICMP Target Address equal to the ICMP Destination Address. 1144 0 1 2 3 1145 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 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Type | Code | Checksum | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1149 | Reserved | 1150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1151 | | 1152 + + 1153 | | 1154 + Target Address + 1155 | | 1156 + + 1157 | | 1158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1159 | | 1160 + + 1161 | | 1162 + Destination Address + 1163 | | 1164 + + 1165 | | 1166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1167 | Options ... 1168 +-+-+-+-+-+-+-+-+-+-+-+- 1170 IP Fields: 1172 Source Address 1173 MUST be the link-local address assigned to the 1174 interface from which this message is sent. 1176 Destination Address 1177 The Source Address of the packet that triggered the 1178 redirect. 1180 Hop Limit 255 1182 Priority 15 1184 Authentication Header 1185 If a Security Association for the IP Authentication 1186 Header exists between the sender and the destination 1187 address, then the sender SHOULD include this header. 1189 ICMP Fields: 1191 Type 137 1192 Code 0 1194 Checksum The ICMP checksum. See [ICMPv6]. 1196 Reserved This field is unused. It MUST be initialized to zero 1197 by the sender and MUST be ignored by the receiver. 1199 Target Address An IP address that is a better first hop to use for 1200 the ICMP Destination Address. When the target is a 1201 router, the Target Address MUST be the router's link- 1202 local address so that hosts can uniquely identify 1203 routers. When the target is the actual endpoint of 1204 communication, i.e., the destination is a neighbor, 1205 the Target Address field MUST contain the same value 1206 as the ICMP Destination Address field. 1208 Destination Address 1209 The IP address of the destination which is redirected 1210 to the target. 1212 Possible options: 1214 Target link-layer address 1215 The link-layer address for the target. It SHOULD be 1216 included (if known). Note that on NBMA links the 1217 sender of the invoking traffic can not use address 1218 resolution to determine the link-layer address of the 1219 target. Routers are advised not to send Redirect 1220 messages on such links unless they can supply the 1221 target link-layer address. 1223 Redirected Header 1224 As much as possible of the IP packet that triggered 1225 the sending of the Redirect without making the 1226 redirect packet exceed 576 octets. 1228 4.6. Option Formats 1230 Neighbor Discovery messages include zero or more options, some of which 1231 may appear multiple times in the same message. All options are of the 1232 form: 1234 0 1 2 3 1235 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 1236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1237 | Type | Length | ... | 1238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1239 ~ ... ~ 1240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 Fields: 1244 Type 8-bit identifier of the type of option. The options 1245 defined in this document are: 1247 Option Name Type 1249 Source Link-Layer Address 1 1250 Target Link-Layer Address 2 1251 Prefix Information 3 1252 Redirected Header 4 1253 MTU 5 1255 Length 8-bit unsigned integer. The length of the option in 1256 units of 8 octets. The value 0 is invalid. Nodes 1257 MUST silently discard an ND packet that contains an 1258 option with length zero. 1260 4.6.1. Source/Target Link-layer Address 1262 0 1 2 3 1263 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 1264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1265 | Type | Length | Link-Layer Address ... 1266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 Fields: 1270 Type 1271 1 for Source Link-layer Address 1272 2 for Target Link-layer Address 1274 Length The length of the option in units of 8 octets. For 1275 example, the length for IEEE 802 addresses is 1 1276 [IPv6-ETHER]. 1278 Link-Layer Address 1279 The variable length link-layer address. 1281 The content and format of this field is expected to be 1282 specified in specific documents that describe how IPv6 1283 operates over different link layers. For instance, 1284 [IPv6-ETHER]. 1286 Description 1287 The Source Link-Layer Address option contains the 1288 link-layer address of the sender of the packet. It is 1289 used in the Neighbor Solicitation, Router 1290 Solicitation, and Router Advertisement packets. 1292 The Target Link-Layer Address option contains the 1293 link-layer address of the target. It is used in 1294 Neighbor Advertisement and Redirect packets. 1296 These options MUST be silently ignored for other 1297 Neighbor Discovery messages. 1299 4.6.2. Prefix Information 1301 0 1 2 3 1302 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 1303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1304 | Type | Length | Prefix Length |L|A| Reserved1 | 1305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1306 | Valid Lifetime | 1307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1308 | Preferred Lifetime | 1309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1310 | Reserved2 | 1311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1312 | | 1313 + + 1314 | | 1315 + Prefix + 1316 | | 1317 + + 1318 | | 1319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1321 Fields: 1323 Type 3 1324 Length 4 1326 Prefix Length 8-bit unsigned integer. The number of leading bits in 1327 the Prefix that are valid. The value ranges from 0 to 1328 128. 1330 L 1-bit on-link flag. When set, indicates that this 1331 prefix can be used for on-link determination. When 1332 not set the advertisement makes no statement about 1333 on-link or off-link properties of the prefix. For 1334 instance, the prefix might be used for address 1335 configuration with some of the addresses belonging to 1336 the prefix being on-link and others being off-link. 1338 A 1-bit autonomous address-configuration flag. When set 1339 indicates that this prefix can be used for autonomous 1340 address configuration as specified in [ADDRCONF]. 1342 Reserved1 6-bit unused field. It MUST be initialized to zero by 1343 the sender and MUST be ignored by the receiver. 1345 Valid Lifetime 1346 32-bit unsigned integer. The length of time in 1347 seconds (relative to the time the packet is sent) that 1348 the prefix is valid for the purpose of on-link 1349 determination. A value of all one bits (0xffffffff) 1350 represents infinity. The Valid Lifetime is also used 1351 by [ADDRCONF]. 1353 Preferred Lifetime 1354 32-bit unsigned integer. The length of time in 1355 seconds (relative to the time the packet is sent) that 1356 addresses generated from the prefix via stateless 1357 address autoconfiguration remain preferred [ADDRCONF]. 1358 A value of all one bits (0xffffffff) represents 1359 infinity. See [ADDRCONF]. 1361 Reserved2 This field is unused. It MUST be initialized to zero 1362 by the sender and MUST be ignored by the receiver. 1364 Prefix An IP address or a prefix of an IP address. The 1365 Prefix Length field contains the number of valid 1366 leading bits in the prefix. The bits in the prefix 1367 after the prefix length are reserved and MUST be 1368 initialized to zero by the sender and ignored by the 1369 receiver. 1371 Description 1372 The Prefix Information option provide hosts with on- 1373 link prefixes and prefixes for Address 1374 Autoconfiguration. 1376 The Prefix Information option appears in Router 1377 Advertisement packets and MUST be silently ignored for 1378 other messages. 1380 4.6.3. Redirected Header 1382 0 1 2 3 1383 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 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1385 | Type | Length | Reserved | 1386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1387 | Reserved | 1388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 | | 1390 ~ IP header + data ~ 1391 | | 1392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1394 Fields: 1396 Type 4 1398 Length The length of the option in units of 8 octets. 1400 Reserved These fields are unused. They MUST be initialized to 1401 zero by the sender and MUST be ignored by the 1402 receiver. 1404 IP header + data 1405 The original packet truncated to ensure that the size 1406 of the redirect message does not exceed 576 octets. 1408 Description 1409 The Redirected Header option is used in Redirect 1410 messages and contains all or part of the packet that 1411 is being redirected. 1413 This option MUST be silently ignored for other 1414 Neighbor Discovery messages. 1416 4.6.4. MTU 1418 0 1 2 3 1419 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 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1421 | Type | Length | Reserved | 1422 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1423 | MTU | 1424 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1426 Fields: 1428 Type 5 1430 Length 1 1432 Reserved This field is unused. It MUST be initialized to zero 1433 by the sender and MUST be ignored by the receiver. 1435 MTU 32-bit unsigned integer. The recommended MTU for the 1436 link. 1438 Description 1439 The MTU option is used in Router Advertisement 1440 messages to insure that all nodes on a link use the 1441 same MTU value in those cases where the link MTU is 1442 not well known. 1444 This option MUST be silently ignored for other 1445 Neighbor Discovery messages. 1447 In configurations in which heterogeneous technologies 1448 are bridged together, the maximum supported MTU may 1449 differ from one segment to another. If the bridges do 1450 not generate ICMP Packet Too Big messages, 1451 communicating nodes will be unable to use Path MTU to 1452 dynamically determine the appropriate MTU on a per- 1453 neighbor basis. In such cases, routers use the MTU 1454 option to specify an MTU value supported by all 1455 segments. 1457 5. CONCEPTUAL MODEL OF A HOST 1459 This section describes a conceptual model of one possible data structure 1460 organization that hosts (and to some extent routers) will maintain in 1461 interacting with neighboring nodes. The described organization is 1462 provided to facilitate the explanation of how the Neighbor Discovery 1463 protocol should behave. This document does not mandate that 1464 implementations adhere to this model as long as their external behavior 1465 is consistent with that described in this document. 1467 This model is only concerned with the aspects of host behavior directly 1468 related to Neighbor Discovery. In particular, it does not concern 1469 itself with such issues as source address selection or the selecting of 1470 an outgoing interface on a multihomed host. 1472 5.1. Conceptual Data Structures 1474 Hosts will need to maintain the following pieces of information for each 1475 interface: 1477 Neighbor Cache 1478 - A set of entries about individual neighbors to which 1479 traffic has been sent recently. Entries are keyed on 1480 the neighbor's on-link unicast IP address and contain 1481 such information as its link-layer address, a flag 1482 indicating whether the neighbor is a router or a host 1483 (called IsRouter in this document), a pointer to any 1484 queued packets waiting for address resolution to 1485 complete, etc. 1487 A Neighbor Cache entry also contains information used 1488 by the Neighbor Unreachability Detection algorithm, 1489 including the reachability state, the number of 1490 unanswered probes, and the time the next Neighbor 1491 Unreachability Detection event is scheduled to take 1492 place. 1494 Destination Cache 1495 - A set of entries about destinations to which traffic 1496 has been sent recently. The Destination Cache 1497 includes both on-link and off-link destinations and 1498 provides a level of indirection into the Neighbor 1499 Cache; the Destination Cache maps a destination IP 1500 address to the IP address of the next-hop neighbor. 1501 Implementations may find it convenient to store 1502 additional information not directly related to 1503 Neighbor Discovery in Destination Cache entries, such 1504 as the Path MTU (PMTU) and round trip timers 1505 maintained by transport protocols. 1507 Prefix List - A list of the prefixes that define a set of addresses 1508 that are on-link. Prefix List entries are created 1509 from information received in Router Advertisements. 1510 Each entry has an associated invalidation timer value 1511 (extracted from the advertisement) used to expire 1512 prefixes when they become invalid. A special 1513 "infinity" timer value specifies that a prefix remains 1514 valid forever, unless a new (finite) value is received 1515 in a subsequent advertisement. 1517 Default Router List 1518 - A list of routers to which packets may be sent. 1519 Router list entries point to entries in the Neighbor 1520 Cache; the algorithm for selecting a default router 1521 favors routers known to be reachable over those whose 1522 reachability is suspect. Each entry also has an 1523 associated invalidation timer value (extracted from 1524 Router Advertisements) used to delete entries that are 1525 no longer advertised. 1527 Note that the above conceptual data structures can be implemented using 1528 a variety of techniques. One possible implementation is to use a single 1529 longest-match routing table for all of the above data structures. 1530 Regardless of the specific implementation, it is critical that the 1531 Neighbor Cache entry for a router is shared by all Destination Cache 1532 entries using that router in order to prevent redundant Neighbor 1533 Unreachability Detection probes. 1535 The Neighbor Cache contains information maintained by the Neighbor 1536 Unreachability Detection algorithm. A key piece of information is a 1537 neighbor's reachability state, which is one of five possible values. 1538 The following definitions are informal; precise definitions can be found 1539 in Section 7.3.2. 1541 INCOMPLETE Address resolution is in progress and the link-layer 1542 address of the neighbor has not yet been determined. 1544 REACHABLE Roughly speaking, the neighbor is known to have been 1545 reachable recently (within tens of seconds ago). 1547 STALE The neighbor is no longer known to be reachable but until 1548 traffic is sent to the neighbor, no attempt should be 1549 made to verify its reachability. 1551 DELAY The neighbor is no longer known to be reachable, and 1552 traffic has recently be sent to the neighbor. Rather 1553 than probe the neighbor immediately, however, delay 1554 sending probes for a short while in order to give upper 1555 layer protocols a chance to provide reachability 1556 confirmation. 1558 PROBE The neighbor is no longer known to be reachable, and 1559 unicast Neighbor Solicitation probes are being sent to 1560 verify reachability. 1562 5.2. Conceptual Sending Algorithm 1564 When sending a packet to a destination, a node uses a combination of the 1565 Destination Cache, the Prefix List, and the Default Router List to 1566 determine the IP address of the appropriate next hop, an operation known 1567 as "next-hop determination". Once the IP address of the next hop is 1568 known, the Neighbor Cache is consulted for link-layer information about 1569 that neighbor. 1571 Next-hop determination for a given unicast destination operates as 1572 follows. The sender examines the Prefix List to determine whether the 1573 packet's destination is on- or off-link. If the destination is on-link, 1574 the next-hop address is the same as the packet's destination address. 1575 Otherwise, the sender selects a router from the Default Router List 1576 (following the rules described in Section 6.3.6). If the Default Router 1577 List is empty, the sender assumes that the destination is on-link. 1579 For efficiency reasons, next-hop determination is not performed on every 1580 packet that is sent. Instead, the results of next-hop determination 1581 computations are saved in the Destination Cache. When the sending node 1582 has a packet to send, it first examines the Destination Cache. If no 1583 entry exists for the destination, next-hop determination is invoked to 1584 create a Destination Cache entry. 1586 Once the IP address of the next-hop node is known, the sender examines 1587 the Neighbor Cache for link-layer information about that neighbor. If 1588 no entry exists, the sender creates one, sets its state to INCOMPLETE, 1589 sends a Neighbor Solicitation message, and then queues the data packet 1590 pending completion of address resolution. When a Neighbor Advertisement 1591 response is received, the link-layer addresses is entered in the 1592 Neighbor Cache entry and the queued packet is transmitted. The address 1593 resolution mechanism is described in detail in Section 7.2. 1595 For multicast packets the next-hop is always the (multicast) destination 1596 address and is considered to be on-link. The procedure for determining 1597 the link-layer address corresponding to a given IP multicast address can 1598 be found in a separate document that covers operating IP over a 1599 particular link type (e.g., [IPv6-ETHER]). 1601 Each time a Neighbor Cache entry is accessed while transmitting a 1602 unicast packet, the sender checks Neighbor Unreachability Detection 1603 related information according to the Neighbor Unreachability Detection 1604 algorithm (Section 7.3). This unreachability check might result in the 1605 sender transmitting a unicast Neighbor Solicitation to verify that the 1606 neighbor is still reachable. 1608 Next-hop determination is done the first time traffic is sent to a 1609 destination. As long as subsequent communication to that destination 1610 proceeds successfully, the Destination Cache entry continues to be used. 1611 If at some point communication ceases to proceed, as determined by the 1612 Neighbor Unreachability Detection algorithm, next-hop determination may 1613 need to be performed again. For example, traffic through a failed 1614 router should be switched to a working router. Likewise, it may be 1615 possible to reroute traffic destined for a mobile node to a "mobility 1616 agent". 1618 Note that when a node redoes next-hop determination there is no need to 1619 discard the complete Destination Cache entry. In fact, it is generally 1620 beneficial to retain such cached information as the PMTU and round trip 1621 timer values that may also be kept in the Destination Cache entry. 1623 Routers and multihomed hosts have multiple interfaces. The remainder of 1624 this document assumes that all sent and received Neighbor Discovery 1625 messages refer to the interface of appropriate context. For example, 1626 when responding to a Router Solicitation, the corresponding Router 1627 Advertisement is sent out the interface on which the solicitation was 1628 received. 1630 5.3. Garbage Collection and Timeout Requirements 1632 The conceptual data structures described above use different mechanisms 1633 for discarding potentially stale or unused information. 1635 From the perspective of correctness there is no need to periodically 1636 purge Destination and Neighbor Cache entries. Although stale 1637 information can potentially remain in the cache indefinitely, the 1638 Neighbor Unreachability Detection algorithm ensures that stale 1639 information is purged quickly if it is actually being used. 1641 To limit the storage needed for the Destination and Neighbor Caches, a 1642 node may need to garbage-collect old entries. However, care must be 1643 taken to insure that sufficient space is always present to hold the 1644 working set of active entries. A small cache may result in an excessive 1645 number of Neighbor Discovery messages if entries are discarded and 1646 rebuilt in quick succession. Any LRU-based policy that only reclaims 1647 entries that have not been used in some time (e.g., ten minutes or more) 1648 should be adequate for garbage-collecting unused entries. 1650 A node should retain entries in the Default Router List and the Prefix 1651 List until their lifetimes expire. However, a node may garbage collect 1652 entries prematurely if it is low on memory. If not all routers are kept 1653 on the Default Router list, a node should retain at least two entries in 1654 the Default Router List (and preferably more) in order to maintain 1655 robust connectivity for off-link destinations. 1657 When removing an entry from the Prefix List there is no need to purge 1658 any entries from the Destination or Neighbor Caches. Neighbor 1659 Unreachability Detection will efficiently purge any entries in these 1660 caches that have become invalid. When removing an entry from the 1661 Default Router List, however, any entries in the Destination Cache that 1662 go through that router must perform next-hop determination again to 1663 select a new default router. 1665 6. ROUTER AND PREFIX DISCOVERY 1667 This section describes router and host behavior related to the Router 1668 Discovery portion of Neighbor Discovery. Router Discovery is used to 1669 locate neighboring routers as well as learn prefixes and configuration 1670 parameters related to address autoconfiguration. 1672 Prefix Discovery is the process through which hosts learn the ranges of 1673 IP addresses that reside on-link and can be reached directly without 1674 going through a router. Routers send Router Advertisements that 1675 indicate whether the sender is willing to be a default router. Router 1676 Advertisements also contain Prefix Information options that list the set 1677 of prefixes that identify on-link IP addresses. 1679 Stateless Address Autoconfiguration must also obtain subnet prefixes as 1680 part of configuring addresses. Although the prefixes used for address 1681 autoconfiguration are logically distinct from those used for on-link 1682 determination, autoconfiguration information is piggybacked on Router 1683 Discovery messages to reduce network traffic. Indeed, the same prefixes 1684 can be advertised for on-link determination and address 1685 autoconfiguration by specifying the appropriate flags in the Prefix 1686 Information options. See [ADDRCONF] for details on how 1687 autoconfiguration information is processed. 1689 6.1. Message Validation 1691 6.1.1. Validation of Router Solicitation Messages 1693 Hosts MUST silently discard any received Router Solicitation Messages. 1695 A router MUST silently discard any received Router Solicitation messages 1696 that do not satisfy all of the following validity checks: 1698 - The IP Hop Limit field has a value of 255, i.e., the packet could 1699 not possibly have been forwarded by a router. 1701 - If the message includes an IP Authentication Header, the message 1702 authenticates correctly. 1704 - ICMP Checksum is valid. 1706 - ICMP Code is 0. 1708 - ICMP length (derived from the IP length) is 8 or more octets. 1710 - All included options have a length that is greater than zero. 1712 The contents of the Reserved field, and of any unrecognized options, 1713 MUST be ignored. Future, backward-compatible changes to the protocol 1714 may specify the contents of the Reserved field or add new options; 1715 backward-incompatible changes may use different Code values. 1717 The contents of any defined options that are not specified to be used 1718 with Router Solicitation messages MUST be ignored and the packet 1719 processed as normal. The only defined option that may appear is the 1720 Source Link-Layer Address option. 1722 A solicitation that passes the validity checks is called a "valid 1723 solicitation". 1725 6.1.2. Validation of Router Advertisement Messages 1727 A node MUST silently discard any received Router Advertisement messages 1728 that do not satisfy all of the following validity checks: 1730 - IP Source Address is a link-local address. Routers must use their 1731 link-local address as the source for Router Advertisement and 1732 Redirect messages so that hosts can uniquely identify routers. 1734 - The IP Hop Limit field has a value of 255, i.e., the packet could 1735 not possibly have been forwarded by a router. 1737 - If the message includes an IP Authentication Header, the message 1738 authenticates correctly. 1740 - ICMP Checksum is valid. 1742 - ICMP Code is 0. 1744 - ICMP length (derived from the IP length) is 16 or more octets. 1746 - All included options have a length that is greater than zero. 1748 The contents of the Reserved field, and of any unrecognized options, 1749 MUST be ignored. Future, backward-compatible changes to the protocol 1750 may specify the contents of the Reserved field or add new options; 1751 backward-incompatible changes may use different Code values. 1753 The contents of any defined options that are not specified to be used 1754 with Router Advertisement messages MUST be ignored and the packet 1755 processed as normal. The only defined options that may appear are the 1756 Source Link-Layer Address, Prefix Information and MTU options. 1758 An advertisement that passes the validity checks is called a "valid 1759 advertisement". 1761 6.2. Router Specification 1763 6.2.1. Router Configuration Variables 1765 A router MUST allow for the following conceptual variables to be 1766 configured by system management. The specific variable names are used 1767 for demonstration purposes only, and an implementation is not required 1768 to have them, so long as its external behavior is consistent with that 1769 described in this document. Default values are specified to simplify 1770 configuration in common cases. 1772 The default values for some of the variables listed below may be 1773 overridden by specific documents that describe how IPv6 operates over 1774 different link layers. This rule simplifies the configuration of 1775 Neighbor Discovery over link types with widely differing performance 1776 characteristics. 1778 For each multicast interface: 1780 AdvSendAdvertisements 1781 A flag indicating whether or not the router sends 1782 periodic Router Advertisements and responds to 1783 Router Solicitations. 1785 Default: FALSE 1787 Note that AdvSendAdvertisements MUST be false by 1788 default so that a node will not accidentally start 1789 acting as a router unless it is explicitly 1790 configured by system management to send Router 1791 Advertisements. 1793 MaxRtrAdvInterval 1794 The maximum time allowed between sending unsolicited 1795 multicast Router Advertisements from the interface, 1796 in seconds. MUST be no less than 4 seconds and no 1797 greater than 1800 seconds. 1799 Default: 600 seconds 1801 MinRtrAdvInterval 1802 The minimum time allowed between sending unsolicited 1803 multicast Router Advertisements from the interface, 1804 in seconds. MUST be no less than 3 seconds and no 1805 greater than .75 * MaxRtrAdvInterval. 1807 Default: 0.33 * MaxRtrAdvInterval 1809 AdvManagedFlag 1810 The true/false value to be placed in the "Managed 1811 address configuration" flag field in the Router 1812 Advertisement. See [ADDRCONF]. 1814 Default: FALSE 1816 AdvOtherConfigFlag 1817 The true/false value to be placed in the "Other 1818 stateful configuration" flag field in the Router 1819 Advertisement. See [ADDRCONF]. 1821 Default: FALSE 1823 AdvLinkMTU The value to be placed in MTU options sent by the 1824 router. A value of zero indicates that no MTU 1825 options are sent. 1827 Default: 0 1829 AdvReachableTime 1830 The value to be placed in the Reachable Time field 1831 in the Router Advertisement messages sent by the 1832 router. The value zero means unspecified (by this 1833 router). MUST be no greater than 3,600,000 1834 milliseconds (1 hour). 1836 Default: 0 1838 AdvRetransTimer 1839 The value to be placed in the Retrans Timer field in 1840 the Router Advertisement messages sent by the 1841 router. The value zero means unspecified (by this 1842 router). 1844 Default: 0 1846 AdvMaxHopLimit 1847 The value to be placed in the Max Hop Limit field in 1848 the Router Advertisement messages sent by the 1849 router. The value zero means unspecified (by this 1850 router). 1852 Default: The value specified in the most recent 1853 "Assigned Numbers" RFC [ASSIGNED]. 1855 AdvDefaultLifetime 1856 The value to be placed in the Router Lifetime field 1857 of Router Advertisements sent from the interface, in 1858 seconds. MUST be either zero or between 1859 MaxRtrAdvInterval and 9000 seconds. A value of zero 1860 indicates that the router is not to be used as a 1861 default router. 1863 Default: 3 * MaxRtrAdvInterval 1865 AdvPrefixList 1866 A list of prefixes to be placed in Prefix 1867 Information options in Router Advertisement messages 1868 sent from the interface. 1870 Default: all prefixes that the router advertises via 1871 routing protocols as being on-link for the interface 1872 from which the advertisement is sent. 1874 Each prefix has an associated: 1876 AdvValidLifetime 1877 The value to be placed in the Valid Lifetime 1878 in the Prefix Information option, in 1879 seconds. The designated value of all 1's 1880 (0xffffffff) represents infinity. 1882 Default: infinity. 1884 AdvOnLinkFlag 1885 The value to be placed in the on-link flag 1886 ("L-bit") field in the Prefix Information 1887 option. 1889 Default: TRUE 1891 Automatic address configuration [ADDRCONF] defines 1892 additional information associated with each the 1893 prefixes: 1895 AdvPreferredLifetime 1896 The value to be placed in the Preferred 1897 Lifetime in the Prefix Information option, 1898 in seconds. The designated value of all 1's 1899 (0xffffffff) represents infinity. See 1900 [ADDRCONF]. 1902 Default: 604800 seconds (7 days) 1904 AdvAutonomousFlag 1905 The value to be placed in the Autonomous 1906 Flag field in the Prefix Information option. 1907 See [ADDRCONF]. 1909 Default: TRUE 1911 The above variables contain information that is placed in outgoing 1912 Router Advertisement messages. Hosts use the received information to 1913 initialize a set of analogous variables that control their external 1914 behavior (see Section 6.3.2). Some of these host variables (e.g., 1915 MaxHopLimit, RetransTimer, and ReachableTime) apply to all nodes 1916 including routers. In practice, these variables may not actually be 1917 present on routers, since their contents can be derived from the 1918 variables described above. However, external router behavior MUST be 1919 the same as host behavior with respect to these variables. In 1920 particular, this includes the occasional randomization of the 1921 ReachableTime value as described in Section 6.3.2. 1923 Protocol constants are defined in Section 10. 1925 6.2.2. Becoming An Advertising Interface 1927 The term "advertising interface" refers to any functioning and enabled 1928 multicast interface that has at least one unicast IP address assigned to 1929 it and whose corresponding AdvSendAdvertisements flag is TRUE. A router 1930 MUST NOT send Router Advertisements out any interface that is not an 1931 advertising interface. 1933 An interface may become an advertising interface at times other than 1934 system startup. For example: 1936 - changing the AdvSendAdvertisements flag on an enabled interface 1937 from FALSE to TRUE, or 1939 - administratively enabling the interface, if it had been 1940 administratively disabled, and its AdvSendAdvertisements flag is 1941 TRUE, or 1943 - enabling IP forwarding capability (i.e., changing the system from 1944 being a host to being a router), when the interface's 1945 AdvSendAdvertisements flag is TRUE. 1947 A router MUST join the all-routers multicast address on an advertising 1948 interface. Routers respond to Router Solicitations sent to the all- 1949 routers address and verify the consistency of Router Advertisements sent 1950 by neighboring routers. 1952 6.2.3. Router Advertisement Message Content 1954 A router sends periodic as well as solicited Router Advertisements out 1955 its advertising interfaces. Outgoing Router Advertisements are filled 1956 with the following values consistent with the message format given in 1957 Section 4.2: 1959 - In the Router Lifetime field: the interface's configured 1960 AdvDefaultLifetime. 1962 - In the M and O flags: the interface's configured AdvManagedFlag and 1963 AdvOtherConfigFlag, respectively. See [ADDRCONF]. 1965 - In the Max Hop Limit field: the interface's configured 1966 AdvMaxHopLimit. 1968 - In the Reachable Time field: the interface's configured 1969 AdvReachableTime. 1971 - In the Retrans Timer field: the interface's configured 1972 AdvRetransTimer. 1974 - In the options: 1976 o Source Link-Layer Address option: link-layer address of the 1977 sending interface. This option MAY be omitted to facilitate 1978 in-bound load balancing over replicated interfaces. 1980 o MTU option: the interface's configured AdvLinkMTU value if the 1981 value is non-zero. If AdvLinkMTU is zero the MTU option is 1982 not sent. 1984 o Prefix Information options: one Prefix Information option for 1985 each prefix listed in AdvPrefixList with the option fields set 1986 from the information in the AdvPrefixList entry as follows: 1988 - In the "on-link" flag: the entry's AdvOnLinkFlag. 1990 - In the Valid Lifetime field: the entry's 1991 AdvValidLifetime. 1993 - In the "Autonomous address configuration" flag: the 1994 entry's AdvAutonomousFlag. 1996 - In the Preferred Lifetime field: the entry's 1997 AdvPreferredLifetime. 1999 A router might want to send Router Advertisements without advertising 2000 itself as a default router. For instance, a router might advertise 2001 prefixes for address autoconfiguration while not wishing to forward 2002 packets. Such a router sets the Router Lifetime field in outgoing 2003 advertisements to zero. 2005 A router MAY choose not to include some or all options when sending 2006 unsolicited Router Advertisements. For example, if prefix lifetimes are 2007 much longer than AdvDefaultLifetime, including them every few 2008 advertisements may be sufficient. However, when responding to a Router 2009 Solicitation or while sending the first few initial unsolicited 2010 advertisements, a router SHOULD include all options so that all 2011 information (e.g., prefixes) is propagated quickly during system 2012 initialization. 2014 If including all options causes the size of an advertisement to exceed 2015 the link MTU, multiple advertisements can be sent, each containing a 2016 subset of the options. 2018 6.2.4. Sending Unsolicited Router Advertisements 2020 A host MUST NOT send Router Advertisement messages at any time. 2022 Unsolicited Router Advertisements are not strictly periodic: the 2023 interval between subsequent transmissions is randomized to reduce the 2024 probability of synchronization with the advertisements from other 2025 routers on the same link [SYNC]. Each advertising interface has its own 2026 timer. Whenever a multicast advertisement is sent from an interface, 2027 the timer is reset to a uniformly-distributed random value between the 2028 interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; 2029 expiration of the timer causes the next advertisement to be sent and a 2030 new random value to be chosen. 2032 For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) 2033 sent from an interface when it becomes an advertising interface, if the 2034 randomly chosen interval is greater than 2035 MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to 2036 MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for 2037 the initial advertisements increases the likelihood of a router being 2038 discovered quickly when it first becomes available, in the presence of 2039 possible packet loss. 2041 The information contained in Router Advertisements may change through 2042 actions of system management. For instance, the lifetime of advertised 2043 prefixes may change, new prefixes could be added, a router could cease 2044 to be a router (i.e., switch from being a router to being a host), etc. 2045 In such cases, the router MAY transmit up to 2046 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the 2047 same rules as when an interface becomes an advertising interface. 2049 6.2.5. Ceasing To Be An Advertising Interface 2051 An interface may cease to be an advertising interface, through actions 2052 of system management such as: 2054 - changing the AdvSendAdvertisements flag of an enabled interface 2055 from TRUE to FALSE, or 2057 - administratively disabling the interface, or 2059 - shutting down the system. 2061 In such cases the router SHOULD transmit one or more (but not more than 2062 MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on 2063 the interface with a Router Lifetime field of zero. In the case of a 2064 router becoming a host, the system SHOULD also depart from the all- 2065 routers IP multicast group on all interfaces on which the router 2066 supports IP multicast (whether or not they had been advertising 2067 interfaces). In addition, the host MUST insure that subsequent Neighbor 2068 Advertisement messages sent from the interface have the Router flag set 2069 to zero. 2071 Note that system management may disable a router's IP forwarding 2072 capability (i.e., changing the system from being a router to being a 2073 host), a step that does not necessarily imply that the router's 2074 interfaces stop being advertising interfaces. In such cases, subsequent 2075 Router Advertisements MUST set the Router Lifetime field to zero. 2077 6.2.6. Processing Router Solicitations 2079 A host MUST silently discard any received Router Solicitation messages. 2081 In addition to sending periodic, unsolicited advertisements, a router 2082 sends advertisements in response to valid solicitations received on an 2083 advertising interface. A router MAY choose to unicast the response 2084 directly to the soliciting host's address (if the solicitation's source 2085 address is not the unspecified address), but the usual case is to 2086 multicast the response to the all-nodes group. In the latter case, the 2087 interface's interval timer is reset to a new random value, as if an 2088 unsolicited advertisement had just been sent (see Section 6.2.4). 2090 In all cases, Router Advertisements sent in response to a Router 2091 Solicitation MUST be delayed by a random time between 0 and 2092 MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in 2093 response to multiple solicitations, the delay is relative to the first 2094 solicitation.) In addition, consecutive Router Advertisements sent to 2095 the all-nodes multicast address MUST be rate limited to no more than one 2096 advertisement every MIN_DELAY_BETWEEN_RAS seconds. 2098 A router might process Router Solicitations as follows: 2100 - Upon receipt of a Router Solicitation, compute a random delay within 2101 the range 0 through MAX_RA_DELAY_TIME. If the computed value 2102 corresponds to a time later than the time the next multicast Router 2103 Advertisement is scheduled to be sent, ignore the random delay and 2104 send the advertisement at the already-scheduled time. 2106 - If the router sent a multicast Router Advertisement (solicited or 2107 unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, schedule 2108 the advertisement to be sent at a time corresponding to 2109 MIN_DELAY_BETWEEN_RAS plus the random value after the previous 2110 advertisement was sent. This ensures that the multicast Router 2111 Advertisements are rate limited. 2113 - Otherwise, schedule the sending of a Router Advertisement at the time 2114 given by the random value. 2116 Note that a router is permitted to send multicast Router Advertisements 2117 more frequently than indicated by the MinRtrAdvInterval configuration 2118 variable so long as the more frequent advertisements are responses to 2119 Router Solicitations. In all cases, however, unsolicited multicast 2120 advertisements MUST NOT be sent more frequently than indicated by 2121 MinRtrAdvInterval. 2123 When a router receives a Router Solicitation and the Source Address is 2124 not the unspecified address, it records that the source of the packet is 2125 a neighbor by creating or updating the Neighbor Cache entry. If the 2126 solicitation contains a Source Link-Layer Address option, and the router 2127 has a Neighbor Cache entry for the neighbor, the link-layer address 2128 SHOULD be updated in the Neighbor Cache. If a Neighbor Cache entry is 2129 created for the source its reachability state MUST be set to STALE as 2130 specified in Section 7.3.3. If a cache entry already exists and is 2131 updated with a different link-layer address the reachability state MUST 2132 also be set to STALE. In either case the entry's IsRouter flag SHOULD 2133 be set to false. 2135 If the Source Address is the unspecified address the router MUST NOT 2136 create or update the Neighbor Cache entry. 2138 6.2.7. Router Advertisement Consistency 2140 Routers SHOULD inspect valid Router Advertisements sent by other routers 2141 and verify that the routers are advertising consistent information on a 2142 link. Detected inconsistencies indicate that one or more routers might 2143 be misconfigured and SHOULD be logged to system or network management. 2144 The minimum set of information to check includes: 2146 - Max Hop Limit values (except for the unspecified value of zero). 2148 - Values of the M or O flags. 2150 - Reachable Time values (except for the unspecified value of zero). 2152 - Retrans Timer values (except for the unspecified value of zero). 2154 - Values in the MTU options. 2156 - Preferred and Valid Lifetimes for the same prefix. 2158 Note that it is not an error for different routers to advertise 2159 different sets of prefixes. Also, some routers might leave some fields 2160 as unspecified, i.e., with the value zero, while other routers specify 2161 values. The logging of errors SHOULD be restricted to conflicting 2162 information that causes hosts to switch from one value to another with 2163 each received advertisement. 2165 Any other action on reception of Router Advertisement messages by a 2166 router is beyond the scope of this document. 2168 6.2.8. Link-local Address Change 2170 The link-local address on a router SHOULD change rarely, if ever. Nodes 2171 receiving Neighbor Discovery messages use the source address to identify 2172 the sender. If multiple packets from the same router contain different 2173 source addresses, nodes will assume they come from different routers, 2174 leading to undesirable behavior. For example, a node will ignore 2175 Redirect messages that are believed to have been sent by a router other 2176 than the current first-hop router. Thus the source address used in 2177 Router Advertisements sent by a particular router must be identical to 2178 the target address in a Redirect message when redirecting to that 2179 router. 2181 Using the link-local address to uniquely identify routers on the link 2182 has the benefit that the address a router is known by should not change 2183 when a site renumbers. 2185 If a router changes the link-local address for one of its interfaces, it 2186 SHOULD inform hosts of this change. The router SHOULD multicast a few 2187 Router Advertisements from the old link-local address with the Router 2188 Lifetime field set to zero and also multicast a few Router 2189 Advertisements from the new link-local address. The overall effect 2190 should be the same as if one interface ceases being an advertising 2191 interface, and a different one starts being an advertising interface. 2193 6.3. Host Specification 2195 6.3.1. Host Configuration Variables 2197 None. 2199 6.3.2. Host Variables 2201 A host maintains certain Neighbor Discovery related variables in 2202 addition to the data structures defined in Section 5.1. The specific 2203 variable names are used for demonstration purposes only, and an 2204 implementation is not required to have them, so long as its external 2205 behavior is consistent with that described in this document. 2207 These variables have default values that are overridden by information 2208 received in Router Advertisement messages. The default values are used 2209 when there is no router on the link or when all received Router 2210 Advertisements have left a particular value unspecified. 2212 The default values in this specification may be overridden by specific 2213 documents that describe how IP operates over different link layers. 2214 This rule allows Neighbor Discovery to operate over links with widely 2215 varying performance characteristics. 2217 For each interface: 2219 LinkMTU The MTU of the link. 2221 Default: The valued defined in the specific document 2222 that describes how IPv6 operates over the particular 2223 link layer (e.g., [IPv6-ETHER]). 2225 MaxHopLimit The maximum hop limit to be used when sending IP 2226 packets. 2228 Default: The value specified in the most recent 2229 "Assigned Numbers" RFC [ASSIGNED]. 2231 BaseReachableTime 2232 A base value used for computing the random 2233 ReachableTime value. 2235 Default: REACHABLE_TIME milliseconds. 2237 ReachableTime The time a neighbor is considered reachable after 2238 receiving a reachability confirmation. 2240 This value should be a uniformly-distributed random 2241 value between MIN_RANDOM_FACTOR and 2242 MAX_RANDOM_FACTOR times BaseReachableTime 2243 milliseconds. A new random value should be 2244 calculated when BaseReachableTime changes (due to 2245 Router Advertisements) or at least every few hours 2246 even if no Router Advertisements are received. 2248 RetransTimer The time between retransmissions of Neighbor 2249 Solicitation messages to a neighbor when resolving 2250 the address or when probing the reachability of a 2251 neighbor. 2253 Default: RETRANS_TIMER milliseconds 2255 6.3.3. Interface Initialization 2257 The host joins the all-nodes multicast address on all multicast-capable 2258 interfaces. 2260 6.3.4. Processing Received Router Advertisements 2262 When multiple routers are present, the information advertised 2263 collectively by all routers may be a superset of the information 2264 contained in a single Router Advertisement. Hosts accept the union of 2265 all advertised information; the receipt of a Router Advertisement MUST 2266 NOT invalidate all information received in a previous advertisement. 2267 However, when received information for a specific parameter (e.g., Link 2268 MTU) or option (e.g., Lifetime on a specific Prefix) is different than 2269 information received earlier, and the parameter/option can only have one 2270 value, the most recently-received information is considered 2271 authoritative. 2273 Some Router Advertisement fields (e.g., Max Hop Limit, Reachable Time 2274 and Retrans Timer) may contain a value denoting unspecified. In such 2275 cases, the parameter should be ignored and the host should continue 2276 using whatever value it is already using. In particular, a host MUST 2277 NOT interpret the unspecified value as meaning change back to the 2278 default value that was in use before the first Router Advertisement was 2279 received. This rule prevents hosts from continually changing an 2280 internal variable when one router advertises a specific value, but other 2281 routers advertise the unspecified value. 2283 On receipt of a valid Router Advertisement, a host extracts the source 2284 address of the packet and does the following: 2286 - If the address is not already present in the host's Default Router 2287 List, and the advertisement's Router Lifetime is non-zero, create a 2288 new entry in the list, and initialize its invalidation timer value 2289 from the advertisement's Router Lifetime field. 2291 - If the address is already present in the host's Default Router List 2292 as a result of a previously-received advertisement, reset its 2293 invalidation timer to the Router Lifetime value in the newly- 2294 received advertisement. 2296 - If the address is already present in the host's Default Router List 2297 and the received Router Lifetime value is zero, immediately time- 2298 out the entry as specified in Section 6.3.5. 2300 To limit the storage needed for the Default Router List, a host MAY 2301 choose not to store all of the router addresses discovered via 2302 advertisements. However, a host MUST retain at least two router 2303 addresses and SHOULD retain more. Default router selections are made 2304 whenever communication to a destination appears to be failing. Thus, 2305 the more routers on the list, the more likely an alternative working 2306 router can be found quickly (e.g., without having to wait for the next 2307 advertisement to arrive). 2309 If the received Max Hop Limit value is non-zero the host SHOULD set its 2310 MaxHopLimit variable to the received value. 2312 If the received Reachable Time value is non-zero the host SHOULD set its 2313 BaseReachableTime variable to the received value. If the new value 2314 differs from the previous value, the host SHOULD recompute a new random 2315 ReachableTime value. ReachableTime is computed as a uniformly- 2316 distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR 2317 times the BaseReachableTime. Using a random component eliminates the 2318 possibility Neighbor Unreachability Detection messages synchronize with 2319 each other. 2321 In most cases, the advertised Reachable Time value will be the same in 2322 consecutive Router Advertisements and a host's BaseReachableTime rarely 2323 changes. In such cases, an implementation SHOULD insure that a new 2324 random value gets recomputed at least once every few hours. 2326 The RetransTimer variable SHOULD be copied from the Retrans Timer field, 2327 if the received value is non-zero. 2329 After extracting information from the fixed part of the Router 2330 Advertisement message, the advertisement is scanned for valid options. 2331 If the advertisement contains a Source Link-Layer Address option the 2332 link-layer address SHOULD be recorded in the Neighbor Cache entry for 2333 the router (creating an entry if necessary) and the IsRouter flag in the 2334 Neighbor Cache entry MUST be set to true. The IsRouter flag is used by 2335 Neighbor Unreachability Detection to determine when a router changes to 2336 being a host (i.e., no longer capable of forwarding packets). If a 2337 Neighbor Cache entry is created for the router its reachability state 2338 MUST be set to STALE as specified in Section 7.3.3. If a cache entry 2339 already exists and is updated with a different link-layer address the 2340 reachability state MUST also be set to STALE. 2342 If the MTU option is present, hosts SHOULD copy the option's value into 2343 LinkMTU if the value does not exceed the default LinkMTU value specified 2344 in the link type specific document (e.g., [IPv6-ETHER]). 2346 Prefix Information options that have the "on-link" (L) flag set indicate 2347 a prefix identifying a range of addresses that should be considered on- 2348 link. Note, however, that a Prefix Information option with the on-link 2349 flag set to zero does not convey any meaning. In particular, such a 2350 prefix MUST NOT be considered to be off-link. Prefixes with the on-link 2351 flag set to zero would normally have the autonomous flag set and be used 2352 by [ADDRCONF]. 2354 For each Prefix Information option with the on-link flag set, a host 2355 does the following: 2357 - If the prefix is not already present in the Prefix List, and the 2358 Prefix Information option's Valid Lifetime field is non-zero, 2359 create a new entry for the prefix and initialize its invalidation 2360 timer to the Valid Lifetime value in the Prefix Information option. 2362 - If the prefix is already present in the host's Prefix List as the 2363 result of a previously-received advertisement, reset its 2364 invalidation timer to the Valid Lifetime value in the Prefix 2365 Information option. If the new Lifetime value is zero, time-out 2366 the prefix immediately (see Section 6.3.5). 2368 - If the Prefix Information option's Valid Lifetime field is zero, 2369 and the prefix is not present in the host's Prefix List, silently 2370 ignore the option. 2372 Note: Implementations can choose to process the on-link aspects of 2373 the prefixes separately from the address autoconfiguration aspects of 2374 the prefixes by, e.g., passing a copy of each valid Router 2375 Advertisement message to both an "on-link" and an "addrconf" 2376 function. Each function can then operate independently on the 2377 prefixes that have the appropriate flag set. 2379 6.3.5. Timing out Prefixes and Default Routers 2381 Whenever the invalidation timer expires for a Prefix List entry, that 2382 entry is discarded. No existing Destination Cache entries need be 2383 updated, however. Should a reachability problem arise with an existing 2384 Neighbor Cache entry, Neighbor Unreachability Detection will perform any 2385 needed recovery. 2387 Whenever the Lifetime of an entry in the Default Router List expires, 2388 that entry is discarded. When removing a router from the Default Router 2389 list, the node MUST update the Destination Cache in such a way that all 2390 entries using the router perform next-hop determination again rather 2391 than continue sending traffic to the (deleted) router. 2393 6.3.6. Default Router Selection 2395 The algorithm for selecting a router depends in part on whether or not a 2396 router is known to be reachable. The exact details of how a node keeps 2397 track of a neighbor's reachability state are covered in Section 7.3. 2398 The algorithm for selecting a default router is invoked during next-hop 2399 determination when no Destination Cache entry exists for an off-link 2400 destination or when communication through an existing router appears to 2401 be failing. Under normal conditions, a router would be selected the 2402 first time traffic is sent to a destination, with subsequent traffic for 2403 that destination using the same router as indicated in the Destination 2404 Cache modulo any changes to the Destination Cache caused by Redirect 2405 messages. 2407 The policy for selecting routers from the Default Router List is as 2408 follows: 2410 1) Routers that are reachable or probably reachable (i.e., in any 2411 state other than INCOMPLETE) SHOULD be preferred over routers whose 2412 reachability is unknown or suspect (i.e., in the INCOMPLETE state, 2413 or for which no Neighbor Cache entry exists). An implementation 2414 may choose to always return the same router or cycle through the 2415 router list in a round-robin fashion as long as it always returns a 2416 reachable or a probably reachable router when one is available. 2418 2) When no routers on the list are known to be reachable or probably 2419 reachable, routers SHOULD be selected in a round-robin fashion, so 2420 that subsequent requests for a default router do not return the 2421 same router until all other routers have been selected. 2423 Cycling through the router list in this case ensures that all 2424 available routers are actively probed by the Neighbor 2425 Unreachability Detection algorithm. A request for a default router 2426 is made in conjunction with the sending of a packet to a router, 2427 and the selected router will be probed for reachability as a side 2428 effect. 2430 3) If the Default Router List is empty, assume that all destinations 2431 are on-link as specified in Section 5.2. 2433 6.3.7. Sending Router Solicitations 2435 When an interface becomes enabled, a host may be unwilling to wait for 2436 the next unsolicited Router Advertisement to locate default routers or 2437 learn prefixes. To obtain Router Advertisements quickly, a host SHOULD 2438 transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each 2439 separated by at least RTR_SOLICITATION_INTERVAL seconds. Router 2440 Solicitations may be sent after any of the following events: 2442 - The interface is initialized at system startup time. 2444 - The interface is reinitialized after a temporary interface failure 2445 or after being temporarily disabled by system management. 2447 - The system changes from being a router to being a host, by having 2448 its IP forwarding capability turned off by system management. 2450 - The host attaches to a link for the first time. 2452 - The host re-attaches to a link after being detached for some time. 2454 A host sends Router Solicitations to the all-routers multicast address. 2455 The IP source address is set to either one of the interface's unicast 2456 addresses or the unspecified address. The Source Link-Layer Address 2457 option SHOULD be set to the host's link-layer address, if the IP source 2458 address is a unicast address. 2460 Before a host sends an initial solicitation, it SHOULD delay the 2461 transmission for a random amount of time between 0 and 2462 MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when 2463 many hosts start up on a link at the same time, such as might happen 2464 after recovery from a power failure. If a host has already performed a 2465 random delay since the interface became (re)enabled (e.g., as part of 2466 Duplicate Address Detection [ADDRCONF]) there is no need to delay again 2467 before sending the first Router Solicitation message. 2469 Once the host sends a Router Solicitation, and receives a valid Router 2470 Advertisement with a non-zero Router Lifetime, the host MUST desist from 2471 sending additional solicitations on that interface, until the next time 2472 one of the above events occurs. Moreover, a host SHOULD send at least 2473 one solicitation in the case where an advertisement is received prior to 2474 having sent a solicitation. Unsolicited Router Advertisements may be 2475 incomplete (see Section 6.2.3); solicited advertisements are expected to 2476 contain complete information. 2478 If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no 2479 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 2480 seconds after sending the last solicitation, the host concludes that 2481 there are no routers on the link for the purpose of [ADDRCONF]. 2482 However, the host continues to receive and process Router Advertisements 2483 messages in the event that routers appear on the link. 2485 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 2487 This section describes the functions related to Neighbor Solicitation 2488 and Neighbor Advertisement messages and includes descriptions of address 2489 resolution and the Neighbor Unreachability Detection algorithm. 2491 Neighbor Solicitation and Advertisement messages are also used for 2492 Duplicate Address Detection as specified by [ADDRCONF]. In particular, 2493 Duplicate Address Detection sends Neighbor Solicitation messages with an 2494 unspecified source address targeting its own "tentative" address. Such 2495 messages trigger nodes already using the address to respond with a 2496 multicast Neighbor Advertisement indicating that the address is in use. 2498 7.1. Message Validation 2500 7.1.1. Validation of Neighbor Solicitations 2502 A node MUST silently discard any received Neighbor Solicitation messages 2503 that do not satisfy all of the following validity checks: 2505 - The IP Hop Limit field has a value of 255, i.e., the packet could 2506 not possibly have been forwarded by a router. 2508 - If the message includes an IP Authentication Header, the message 2509 authenticates correctly. 2511 - ICMP Checksum is valid. 2513 - ICMP Code is 0. 2515 - ICMP length (derived from the IP length) is 24 or more octets. 2517 - Target Address is not a multicast address. 2519 - All included options have a length that is greater than zero. 2521 The contents of the Reserved field, and of any unrecognized options, 2522 MUST be ignored. Future, backward-compatible changes to the protocol 2523 may specify the contents of the Reserved field or add new options; 2524 backward-incompatible changes may use different Code values. 2526 The contents of any defined options that are not specified to be used 2527 with Neighbor Solicitation messages MUST be ignored and the packet 2528 processed as normal. The only defined option that may appear is the 2529 Source Link-Layer Address option. 2531 A Neighbor Solicitation that passes the validity checks is called a 2532 "valid solicitation". 2534 7.1.2. Validation of Neighbor Advertisements 2536 A node MUST silently discard any received Neighbor Advertisement 2537 messages that do not satisfy all of the following validity checks: 2539 - The IP Hop Limit field has a value of 255, i.e., the packet could 2540 not possibly have been forwarded by a router. 2542 - If the message includes an IP Authentication Header, the message 2543 authenticates correctly. 2545 - ICMP Checksum is valid. 2547 - ICMP Code is 0. 2549 - ICMP length (derived from the IP length) is 24 or more octets. 2551 - Target Address is not a multicast address. 2553 - If the IP Destination Address is a multicast address the Solicited 2554 flag is zero. 2556 - All included options have a length that is greater than zero. 2558 The contents of the Reserved field, and of any unrecognized options, 2559 MUST be ignored. Future, backward-compatible changes to the protocol 2560 may specify the contents of the Reserved field or add new options; 2561 backward-incompatible changes may use different Code values. 2563 The contents of any defined options that are not specified to be used 2564 with Neighbor Advertisement messages MUST be ignored and the packet 2565 processed as normal. The only defined option that may appear is the 2566 Target Link-Layer Address option. 2568 A Neighbor Advertisements that passes the validity checks is called a 2569 "valid advertisement". 2571 7.2. Address Resolution 2573 Address resolution is the process through which a node determines the 2574 link-layer address of a neighbor given only its IP address. Address 2575 resolution is performed only on addresses that are determined to be on- 2576 link and for which the sender does not know the corresponding link-layer 2577 address. Address resolution is never performed on multicast addresses. 2579 7.2.1. Interface Initialization 2581 When a multicast-capable interface becomes enabled the node MUST join 2582 the all-nodes multicast address on that interface, as well as the 2583 solicited-node multicast address corresponding to each of the IP 2584 addresses assigned to the interface. 2586 The set of addresses assigned to an interface may change over time. New 2587 addresses might be added and old addresses might be removed [ADDRCONF]. 2588 In such cases the node MUST join and leave the solicited-node multicast 2589 address corresponding to the new and old addresses, respectively. Note 2590 that multiple unicast addresses may map into the same solicited-node 2591 multicast address; a node MUST NOT leave the solicited-node multicast 2592 group until all assigned addresses corresponding to that multicast 2593 address have been removed. 2595 7.2.2. Sending Neighbor Solicitations 2597 When a node has a unicast packet to send to a neighbor, but does not 2598 know the neighbor's link-layer address, it performs address resolution 2599 by creating a Neighbor Cache entry in the INCOMPLETE state and 2600 transmitting a Neighbor Solicitation message targeted at the neighbor. 2601 The solicitation is sent to the solicited-node multicast address 2602 corresponding to the target address. 2604 If the source address of the packet prompting the solicitation is the 2605 same as one of the addresses assigned to the outgoing interface, that 2606 address SHOULD be placed in the IP Source Address of the outgoing 2607 solicitation. Otherwise, any one of the addresses assigned to the 2608 interface should be used. Using the prompting packet's source address 2609 when possible insures that the recipient of the Neighbor Solicitation 2610 installs in its Neighbor Cache the IP address that is highly likely to 2611 be used in subsequent return traffic belonging to the prompting packet's 2612 "connection". 2614 The sender SHOULD include its link-layer address (if it has one) in the 2615 solicitation as a Source Link-Layer Address option. 2617 While waiting for address resolution to complete, the sender MUST, for 2618 each neighbor, retain a small queue of packets waiting for address 2619 resolution to complete. The queue MUST hold at least one packet, and 2620 MAY contain more. However, the number of queued packets per neighbor 2621 SHOULD be limited to some small value. When a queue overflows, the new 2622 arrival SHOULD replace the oldest entry. Once address resolution 2623 completes, the node transmits any queued packets. 2625 While awaiting a response, the sender SHOULD retransmit Neighbor 2626 Solicitation messages approximately every RetransTimer milliseconds, 2627 even in the absence of additional traffic to the neighbor. 2628 Retransmissions MUST be rate-limited to at most one solicitation per 2629 neighbor every RetransTimer milliseconds. 2631 If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT 2632 solicitations, address resolution has failed. The sender MUST return 2633 ICMP destination unreachable indications with code 3 (Address 2634 Unreachable) for each packet queued awaiting address resolution. 2636 7.2.3. Receipt of Neighbor Solicitations 2638 A valid Neighbor Solicitation where the Target Address is not a unicast 2639 or anycast address assigned to the receiving interface, and the Target 2640 Address is not a "tentative" address on which Duplicate Address 2641 Detection is being performed [ADDRCONF] MUST be silently ignored. 2643 Upon receipt of a valid Neighbor Solicitation targeted at the node, the 2644 recipient SHOULD update the Neighbor Cache entry for the IP Source 2645 Address of the solicitation if the Source Address is not the unspecified 2646 address. If an entry does not already exist, the node SHOULD create a 2647 new one and set its reachability state to STALE as specified in 2648 Section 7.3.3. If a cache entry already exists and is updated with a 2649 different link-layer address its reachability state MUST be set to 2650 STALE. If the solicitation contains a Source Link-Layer Address option, 2651 the entry's cached link-layer address should be replaced with the one in 2652 the solicitation. 2654 If the Source Address is the unspecified address the node MUST NOT 2655 create or update the Neighbor Cache entry. 2657 After any updates to the Neighbor Cache, the node sends a Neighbor 2658 Advertisement response as described in the next section. 2660 7.2.4. Sending Solicited Neighbor Advertisements 2662 A node sends a Neighbor Advertisement in response to a valid Neighbor 2663 Solicitation targeting one of the node's assigned or "tentative" 2664 address. The Target Address of the advertisement is copied from the 2665 Target Address of the solicitation. The Target Link-Layer Address 2666 option SHOULD be included, using as its value the interface's link-layer 2667 address. If the node is a router, it MUST set the Router flag to one; 2668 otherwise it MUST set the flag to zero. 2670 If the Target Address is either an anycast address or a unicast address 2671 for which the node is providing proxy service, the Override flag SHOULD 2672 be set to zero. Otherwise, it SHOULD be set to one. Proper setting of 2673 the Override flag insures that nodes give preference to non-proxy 2674 advertisements, even when received after proxy advertisements, but that 2675 the first advertisement for an anycast address "wins". 2677 If the source of the solicitation is the unspecified address, the node 2678 MUST set the Solicited flag to zero and multicast the advertisement to 2679 the all-nodes address. Otherwise, the node MUST set the Solicited flag 2680 to one and unicast the advertisement to the Source Address of the 2681 solicitation. 2683 If the Target Address is an anycast address the sender SHOULD delay 2684 sending a response for a random time between 0 and 2685 MAX_ANYCAST_DELAY_TIME seconds. 2687 7.2.5. Receipt of Neighbor Advertisements 2689 When a valid Neighbor Advertisement is received (either solicited or 2690 unsolicited), the Neighbor Cache is searched for the target's entry. If 2691 no entry exists, the advertisement SHOULD be silently discarded. There 2692 is no need to create an entry in this case, since the recipient has 2693 apparently not initiated any communication with the target. 2695 Once the appropriate Neighbor Cache entry has been located, the specific 2696 actions taken depend on the state of the Neighbor Cache entry and the 2697 flags in the advertisement. If the entry is in an INCOMPLETE state 2698 (i.e., no link-layer address is cached for the target) the received 2699 advertisement updates the entry. If a cached link-layer address is 2700 already present, however, a node might choose to ignore the received 2701 advertisement and continue using the cached link-layer address. 2703 If the target's Neighbor Cache entry is in the INCOMPLETE state, the 2704 receiving node records the link-layer address in the Neighbor Cache 2705 entry and sends any packets queued for the neighbor awaiting address 2706 resolution. If the Solicited flag is set, the reachability state for 2707 the neighbor MUST be set to REACHABLE; otherwise it MUST be set to 2708 STALE. (A more detailed explanation of reachability state is described 2709 in Section 7.3.3). The Override flag is ignored if the entry is in the 2710 INCOMPLETE state. 2712 If the target's Neighbor Cache entry is in any state other than 2713 INCOMPLETE when the advertisement is received, the advertisement's 2714 Override flag's setting determines whether the Target Link-Layer Address 2715 option (if present) replaces the cached address. If the Override flag 2716 is set, the receiving node MUST install the link-layer address in its 2717 cache; if the flag is zero, the receiving node MUST NOT install the 2718 link-layer address in its cache. An advertisement's sender sets the 2719 Override flag when it wants its Target Link-Layer Address option to 2720 replace the cached value in Neighbor Cache entries, regardless of their 2721 current contents. 2723 If the target's Neighbor Cache entry is in any state other than 2724 INCOMPLETE when the advertisement is received, the advertisement's 2725 Solicited flag setting determines what the entry's new state should be. 2726 If the Solicited flag is set, the entry's state MUST be set to 2727 REACHABLE; if the flag is zero, the entry's state MUST be set to STALE. 2728 An advertisement's Solicited flag should only be set if the 2729 advertisement is a response to a Neighbor Solicitation. Because 2730 Neighbor Unreachability Solicitations are sent to the cached link-layer 2731 address, a receipt of a solicited advertisement indicates that the 2732 forward path is working. Receipt of an unsolicited advertisement, 2733 however, suggests that a neighbor has urgent information to announce 2734 (e.g., a changed link-layer address). Regardless of whether or not the 2735 new link-layer address is installed in the cache, a node should verify 2736 the reachability of the path it is currently using when it sends the 2737 next packet, so that it quickly finds a working path if the existing 2738 path has failed (e.g., as would be the case if the unsolicited Neighbor 2739 Advertisement is sent to announce a link-layer address change). 2741 In those cases where the cached link-layer address is updated, the 2742 receiving node MUST examine the Router flag in the received 2743 advertisement and update the IsRouter flag in the Neighbor Cache entry 2744 to reflect whether the node is a host or router. In those cases where 2745 the neighbor was previously used as a router, but the advertisement's 2746 Router flag is now set to zero, the node MUST remove that router from 2747 the Default Router List and update the Destination Cache entries for all 2748 destinations using that neighbor as a router as specified in 2749 Section 7.3.3. 2751 7.2.6. Sending Unsolicited Neighbor Advertisements 2753 In some cases a node may be able to determine that its link-layer 2754 address has changed (e.g., hot-swap of an interface card) and may wish 2755 to inform its neighbors of the new link-layer address quickly. In such 2756 cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited 2757 Neighbor Advertisement messages to the all-nodes multicast address. 2758 These advertisements MUST be separated by at least RetransTimer seconds. 2760 The Target Address field in the unsolicited advertisement is set to an 2761 IP address of the interface, and the Target Link-Layer Address option is 2762 filled with the new link-layer address. The Solicited flag MUST be set 2763 to zero, in order to avoid confusing the Neighbor Unreachability 2764 Detection algorithm. If the node is a router, it MUST set the Router 2765 flag to one; otherwise it MUST set it to zero. The Override flag MAY be 2766 set to either zero or one. In either case, neighboring nodes will 2767 immediately change the state of their Neighbor Cache entries for the 2768 Target Address to STALE, prompting them to verify the path for 2769 reachability. If the Override flag is set to one, neighboring nodes 2770 will install the new link-layer address in their caches. Otherwise, 2771 they will ignore the new link-layer address, choosing instead to probe 2772 the cached address. 2774 A node that has multiple IP addresses assigned to an interface MAY 2775 multicast a separate Neighbor Advertisement for each address. In such a 2776 case the node SHOULD introduce a small delay between the sending of each 2777 advertisement to reduce the probability of the advertisements being lost 2778 due to congestion. 2780 A proxy MAY multicast Neighbor Advertisements when its link-layer 2781 address changes or when it is configured (by system management or other 2782 mechanisms) to proxy for an address. If there are multiple nodes that 2783 are providing proxy services for the same set of addresses the proxies 2784 SHOULD provide a mechanism that prevents multiple proxies from 2785 multicasting advertisements for any one address, in order to reduce the 2786 risk of excessive multicast traffic. 2788 Also, a node belonging to an anycast address MAY multicast unsolicited 2789 Neighbor Advertisements for the anycast address when the node's link- 2790 layer address changes. 2792 Note that because unsolicited Neighbor Advertisements do not reliably 2793 update caches in all nodes (the advertisements might not be received by 2794 all nodes), they should only be viewed as a performance optimization to 2795 quickly update the caches in most neighbors. The Neighbor 2796 Unreachability Detection algorithm ensures that all nodes obtain a 2797 reachable link-layer address, though the delay may be slightly longer. 2799 7.2.7. Anycast Neighbor Advertisements 2801 From the perspective of Neighbor Discovery, anycast addresses are 2802 treated just like unicast addresses in most cases. Because an anycast 2803 address is syntactically the same as a unicast address, nodes performing 2804 address resolution or Neighbor Unreachability Detection on an anycast 2805 address treat it as if it were a unicast address. No special processing 2806 takes place. 2808 Nodes that have an anycast address assigned to an interface treat them 2809 exactly the same as if they were unicast addresses with two exceptions. 2810 First, Neighbor Advertisements sent in response to a Neighbor 2811 Solicitation SHOULD be delayed by a random time between 0 and 2812 MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. 2813 Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, 2814 so that when multiple advertisements are received, the first received 2815 advertisement is used rather than the most recently received 2816 advertisement. 2818 As with unicast addresses, Neighbor Unreachability Detection ensures 2819 that a node quickly detects when the current binding for an anycast 2820 address becomes invalid. 2822 7.2.8. Proxy Neighbor Advertisements 2824 Under limited circumstances, a router MAY proxy for one or more other 2825 nodes, that is, through Neighbor Advertisements indicate that it is 2826 willing to accept packets not explicitly addressed to itself. For 2827 example, a router might accept packets on behalf of a mobile node that 2828 has moved off-link. The mechanisms used by proxy are identical to the 2829 mechanisms used with anycast addresses. 2831 A proxy MUST join the solicited-node multicast address(es) that 2832 correspond to the IP address(es) assigned to the node for which it is 2833 proxying. 2835 All solicited proxy Neighbor Advertisement messages MUST have the 2836 Override flag set to zero. This ensures that if the node itself is 2837 present on the link its Neighbor Advertisement (with the Override flag 2838 set to one) will take precedence of any advertisement received from a 2839 proxy. A proxy MAY send unsolicited advertisements with the Override 2840 flag set to one as specified in Section 7.2.6, but doing so may cause 2841 the proxy advertisement to override a valid entry created by the node 2842 itself. 2844 Finally, when sending a proxy advertisement in response to a Neighbor 2845 Solicitation, the sender should delay its response by a random time 2846 between 0 and MAX_ANYCAST_DELAY_TIME seconds. 2848 7.3. Neighbor Unreachability Detection 2850 Communication to or through a neighbor may fail for numerous reasons at 2851 any time, including hardware failure, hot-swap of an interface card, 2852 etc. If the destination has failed, no recovery is possible and 2853 communication fails. On the other hand, if it is the path that has 2854 failed, recovery may be possible. Thus, a node actively tracks the 2855 reachability "state" for the neighbors to which it is sending packets. 2857 Neighbor Unreachability Detection is used for all paths between hosts 2858 and neighboring nodes, including host-to-host, host-to-router, and 2859 router-to-host communication. Neighbor Unreachability Detection may 2860 also be used between routers, but is not required if an equivalent 2861 mechanism is available, for example, as part of the routing protocols. 2863 When a path to a neighbor appears to be failing, the specific recovery 2864 procedure depends on how the neighbor is being used. If the neighbor is 2865 the ultimate destination, for example, address resolution should be 2866 performed again. If the neighbor is a router, however, attempting to 2867 switch to another router would be appropriate. The specific recovery 2868 that takes place is covered under next-hop determination; Neighbor 2869 Unreachability Detection signals the need for next-hop determination by 2870 deleting a Neighbor Cache entry. 2872 Neighbor Unreachability Detection is performed only for neighbors to 2873 which unicast packets are sent; it is not used when sending to multicast 2874 addresses. 2876 7.3.1. Reachability Confirmation 2878 A neighbor is considered reachable if the node has recently received a 2879 confirmation that packets sent recently to the neighbor were received by 2880 its IP layer. Positive confirmation can be gathered in two ways: hints 2881 from upper layer protocols that indicate a connection is making "forward 2882 progress", or receipt of a Neighbor Advertisement message that is a 2883 response to a Neighbor Solicitation message. 2885 A connection makes "forward progress" if the packets received from a 2886 remote peer can only be arriving if recent packets sent to that peer are 2887 actually reaching it. In TCP, for example, receipt of a (new) 2888 acknowledgement indicates that previously sent data reached the peer. 2889 Likewise, the arrival of new (non-duplicate) data indicates that earlier 2890 acknowledgements are being delivered to the remote peer. If packets are 2891 reaching the peer, they must also be reaching the sender's next-hop 2892 neighbor; thus "forward progress" is a confirmation that the next-hop 2893 neighbor is reachable. For off-link destinations, forward progress 2894 implies that the first-hop router is reachable. When available, this 2895 upper-layer information SHOULD be used. 2897 In some cases (e.g., UDP-based protocols and routers forwarding packets 2898 to hosts) such reachability information may not be readily available 2899 from upper-layer protocols. When no hints are available and a node is 2900 sending packets to a neighbor, the node actively probes the neighbor 2901 using unicast Neighbor Solicitation messages to verify that the forward 2902 path is still working. 2904 The receipt of a solicited Neighbor Advertisement serves as reachability 2905 confirmation, since advertisements with the Solicited flag set to one 2906 are sent only in response to a Neighbor Solicitation. Receipt of other 2907 Neighbor Discovery messages such as Router Advertisements and Neighbor 2908 Advertisement with the Solicited flag set to zero MUST NOT be treated as 2909 a reachability confirmation. Receipt of unsolicited messages only 2910 confirm the one-way path from the sender to the recipient node. In 2911 contrast, Neighbor Unreachability Detection requires that a node keep 2912 track of the reachability of the forward path to a neighbor from the its 2913 perspective, not the neighbor's perspective. Note that receipt of a 2914 solicited advertisement indicates that a path is working in both 2915 directions. The solicitation must have reached the neighbor, prompting 2916 it to generate an advertisement. Likewise, receipt of an advertisement 2917 indicates that the path from the sender to the recipient is working. 2918 However, the latter fact is known only to the recipient; the 2919 advertisement's sender has no direct way of knowing that the 2920 advertisement it sent actually reached a neighbor. From the perspective 2921 of Neighbor Unreachability Detection, only the reachability of the 2922 forward path is of interest. 2924 7.3.2. Neighbor Cache Entry States 2926 A Neighbor Cache entry can be in one of five states: 2928 INCOMPLETE Address resolution is being performed on the entry. 2929 Specifically, a Neighbor Solicitation has been sent to 2930 the solicited-node multicast address of the target, but 2931 the corresponding Neighbor Advertisement has not yet been 2932 received. 2934 REACHABLE Positive confirmation was received within the last 2935 ReachableTime milliseconds that the forward path to the 2936 neighbor was functioning properly. While REACHABLE, no 2937 special action takes place as packets are sent. 2939 STALE More than ReachableTime milliseconds have elapsed since 2940 the last positive confirmation was received that the 2941 forward path was functioning properly. While stale, no 2942 action takes place until a packet is sent. 2944 The STALE state is entered upon receiving an unsolicited 2945 Neighbor Discovery message that updates the cached link- 2946 layer address. Receipt of such a message does not 2947 confirm reachability, and entering the STALE state 2948 insures reachability is verified quickly if the entry is 2949 actually being used. However, reachability is not 2950 actually verified until the entry is actually used. 2952 DELAY More than ReachableTime milliseconds have elapsed since 2953 the last positive confirmation was received that the 2954 forward path was functioning properly, and a packet was 2955 sent within the last DELAY_FIRST_PROBE_TIME seconds. If 2956 no reachability confirmation is received within 2957 DELAY_FIRST_PROBE_TIME seconds of entering the DELAY 2958 state, send a Neighbor Solicitation and change the state 2959 to PROBE. 2961 The DELAY state is an optimization that gives upper-layer 2962 protocols additional time to provide reachability 2963 confirmation in those cases where ReachableTime 2964 milliseconds have passed since the last confirmation due 2965 to lack of recent traffic. Without this optimization the 2966 opening of a TCP connection after a traffic lull would 2967 initiate probes even though the subsequent three-way 2968 handshake would provide a reachability confirmation 2969 almost immediately. 2971 PROBE A reachability confirmation is actively sought by 2972 retransmitting Neighbor Solicitations every RetransTimer 2973 milliseconds until a reachability confirmation is 2974 received. 2976 7.3.3. Node Behavior 2978 Neighbor Unreachability Detection operates in parallel with the sending 2979 of packets to a neighbor. While reasserting a neighbor's reachability, 2980 a node continues sending packets to that neighbor using the cached 2981 link-layer address. If no traffic is sent to a neighbor, no probes are 2982 sent. 2984 When a node needs to performs address resolution on a neighboring 2985 address, it creates an entry in the INCOMPLETE state and initiates 2986 address resolution as specified in Section 7.2. If address resolution 2987 fails, the entry SHOULD be deleted, so that subsequent traffic to that 2988 neighbor invokes the next-hop determination procedure again. Invoking 2989 next-hop determination at this point insures that alternate default 2990 routers are tried. 2992 When a reachability conformation is received (either through upper-layer 2993 advice or a solicited Neighbor Advertisement) an entry's state changes 2994 to REACHABLE. The one exception is that upper-layer advice has no 2995 effect on entries in the INCOMPLETE state (e.g., for which no link-layer 2996 address is cached). 2998 When ReachableTime milliseconds have passed since receipt of the last 2999 reachability confirmation for a neighbor, the Neighbor Cache entries 3000 state changes from REACHABLE to STALE. 3002 Note: An implementation may actually defer changing the state from 3003 REACHABLE to STALE until a packet is sent to the neighbor, i.e., 3004 there need not be an explicit timeout event associated with the 3005 expiration of ReachableTime. 3007 The first time a node sends a packet to a neighbor whose entry is STALE, 3008 the sender changes the state to DELAY and a sets a timer to expire in 3009 DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY 3010 state when the timer expires, the entry's state changes to PROBE. If 3011 reachability confirmation is received, the entry's state changes to 3012 REACHABLE. 3014 Upon entering the PROBE state, a node sends a unicast Neighbor 3015 Solicitation message to the neighbor using the cached link-layer 3016 address. While in the PROBE state, a node retransmits Neighbor 3017 Solicitation messages every RetransTimer milliseconds until reachability 3018 confirmation is obtained. Probes are retransmitted even if no 3019 additional packets are sent to the neighbor. If no response is received 3020 after waiting RetransTimer milliseconds after sending the 3021 MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry 3022 SHOULD be deleted. Subsequent traffic to that neighbor will recreate 3023 the entry and performs address resolution again. 3025 Note that all Neighbor Solicitations are rate-limited on a per-neighbor 3026 basis. A node MUST NOT send Neighbor Solicitations to the same neighbor 3027 more frequently than once every RetransTimer milliseconds. 3029 A Neighbor Cache entry enters the STALE state when created as a result 3030 of receiving packets other than solicited Neighbor Advertisements (i.e., 3031 Router Solicitations, Router Advertisements, Redirects, and Neighbor 3032 Solicitations). These packets contain the link-layer address of either 3033 the sender or, in the case of Redirect, the redirection target. 3034 However, receipt of these link-layer addresses does not confirm 3035 reachability of the forward-direction path to that node. Placing a 3036 newly created Neighbor Cache entry for which the link-layer address is 3037 known in the STALE state provides assurance that path failures are 3038 detected quickly. In addition, should a cached link-layer address be 3039 modified due to receiving one of the above messages the state SHOULD 3040 also be set to STALE to provide prompt verification that the patch to 3041 the new link-layer address is working. 3043 To properly detect the case where a router switches from being a router 3044 to being a host (e.g., if its IP forwarding capability is turned off by 3045 system management), a node MUST compare the Router flag field in all 3046 received Neighbor Advertisement messages with the IsRouter flag recorded 3047 in the Neighbor Cache entry. When a node detects that a neighbor has 3048 changed from being a router to being a host, the node MUST remove that 3049 router from the Default Router List and update the Destination Cache as 3050 described in Section 6.3.5. Note that a router may not be listed in the 3051 Default Router List, even though a Destination Cache entry is using it 3052 (e.g., a host was redirected to it). In such cases, all Destination 3053 Cache entries that reference the (former) router must perform next-hop 3054 determination again before using the entry. 3056 In some cases, link-specific information may indicate that a path to a 3057 neighbor has failed (e.g., the resetting of a virtual circuit). In such 3058 cases, link-specific information may be used to purge Neighbor Cache 3059 entries before the Neighbor Unreachability Detection would do so. 3060 However, link-specific information MUST NOT be used to confirm the 3061 reachability of a neighbor; such information does not provide end-to-end 3062 confirmation between neighboring IP layers. 3064 8. REDIRECT FUNCTION 3066 This section describes the functions related to the sending and 3067 processing of Redirect messages. 3069 Redirect messages are sent by routers to redirect a host to a better 3070 first-hop router for a specific destination or to inform hosts that a 3071 destination is in fact a neighbor (i.e., on-link). The latter is 3072 accomplished by having the ICMP Target Address be equal to the ICMP 3073 Destination Address. 3075 A router MUST be able to determine the link-local address for each of 3076 its neighboring routers in order to ensure that the target address in a 3077 Redirect message identifies the neighbor router by its link-local 3078 address. This may require that routing protocols exchange link-local 3079 addresses. 3081 8.1. Validation of Redirect Messages 3083 A host MUST silently discard any received Redirect message that does not 3084 satisfy all of the following validity checks: 3086 - IP Source Address is a link-local address. Routers must use their 3087 link-local address as the source for Router Advertisement and 3088 Redirect messages so that hosts can uniquely identify routers. 3090 - The IP Hop Limit field has a value of 255, i.e., the packet could 3091 not possibly have been forwarded by a router. 3093 - If the message includes an IP Authentication Header, the message 3094 authenticates correctly. 3096 - ICMP Checksum is valid. 3098 - ICMP Code is 0. 3100 - ICMP length (derived from the IP length) is 40 or more octets. 3102 - The IP source address of the Redirect is the same as the current 3103 first-hop router for the specified ICMP Destination Address. 3105 - The ICMP Destination Address field in the redirect message does not 3106 contain a multicast address. 3108 - The ICMP Target Address is either a link-local address (when 3109 redirected to a router) or the same as the ICMP Destination Address 3110 (when redirected to the on-link destination). 3112 - All included options have a length that is greater than zero. 3114 The contents of the Reserved field, and of any unrecognized options MUST 3115 be ignored. Future, backward-compatible changes to the protocol may 3116 specify the contents of the Reserved field or add new options; 3117 backward-incompatible changes may use different Code values. 3119 The contents of any defined options that are not specified to be used 3120 with Redirect messages MUST be ignored and the packet processed as 3121 normal. The only defined options that may appear are the Target Link- 3122 Layer Address option and the Redirected Header option. 3124 A host MUST NOT consider a redirect invalid just because the Target 3125 Address of the redirect is not covered under one of the link's prefixes. 3126 Part of the semantics of the Redirect message is that the Target Address 3127 is on-link. 3129 A redirect that passes the validity checks is called a "valid redirect". 3131 8.2. Router Specification 3133 A router SHOULD send a redirect message, subject to rate limiting, 3134 whenever it forwards a packet that it not explicitly addressed to itself 3135 (i.e. a packet that is not source routed through the router) in which: 3137 - the Source Address field of the packet identifies a neighbor, and 3139 - the router determines that a better first-hop node resides on the 3140 same link as the sending node for the Destination Address of the 3141 packet being forwarded, and 3143 - the Destination Address of the packet is not a multicast address, 3144 and 3146 The transmitted redirect packet contains, consistent with the message 3147 format given in Section 4.5: 3149 - In the Target Address field: the address to which subsequent 3150 packets for the destination SHOULD be sent. If the target is a 3151 router, that router's link-local address MUST be used. If the 3152 target is a host the target address field MUST be set to the same 3153 value as the Destination Address field. 3155 - In the Destination Address field: the destination address of the 3156 invoking IP packet. 3158 - In the options: 3160 o Target Link-Layer Address option: link-layer address of the 3161 target, if known. 3163 o Redirected Header: as much of the forwarded packet as can fit 3164 without the redirect packet exceeding 576 octets in size. 3166 A router MUST limit the rate at which Redirect messages are sent, in 3167 order to limit the bandwidth and processing costs incurred by the 3168 Redirect messages when the source does not correctly respond to the 3169 Redirects, or the source chooses to ignore unauthenticated Redirect 3170 messages. More details on the rate-limiting of ICMP error messages can 3171 be found in [ICMPv6]. 3173 A router MUST NOT update its routing tables upon receipt of a Redirect. 3175 8.3. Host Specification 3177 A host receiving a valid redirect SHOULD update its Destination Cache 3178 accordingly so that subsequent traffic goes to the specified target. If 3179 no Destination Cache entry exists for the destination, an implementation 3180 SHOULD create such an entry. 3182 If the redirect contains a Target Link-Layer Address option the host 3183 either creates or updates the Neighbor Cache entry for the target. In 3184 both cases the cached link-layer address is copied from the Target 3185 Link-Layer Address option. If a Neighbor Cache entry is created for the 3186 target its reachability state MUST be set to STALE as specified in 3187 Section 7.3.3. If a cache entry already existed and it is updated with 3188 a different link-layer address its reachability state MUST also be set 3189 to STALE. 3191 In addition, if the Target Address is the same as the Destination 3192 Address, the host MUST treat the destination as on-link and set the 3193 IsRouter field in the corresponding Neighbor Cache entry to FALSE. 3194 Otherwise it MUST set IsRouter to true. 3196 A host MAY have a configuration switch that can be set to make it ignore 3197 a Redirect message that does not have an IP Authentication header. 3199 A host MUST NOT send Redirect messages. 3201 9. EXTENSIBILITY - OPTION PROCESSING 3203 Options provide a mechanism for encoding variable length fields, fields 3204 that may appear multiple times in the same packet, or information that 3205 may not appear in all packets. Options can also be used to add 3206 additional functionality to future versions of ND. 3208 In order to ensure that future extensions properly coexist with current 3209 implementations, all nodes MUST silently ignore any options they do not 3210 recognize in received ND packets and continue processing the packet. 3211 All options specified in this document MUST be recognized. A node MUST 3212 NOT ignore valid options just because the ND message contains 3213 unrecognized ones. 3215 The current set of options is defined in such a way that receivers can 3216 process multiple options in the same packet independently of each other. 3217 In order to maintain these properties future options SHOULD follow the 3218 simple rule: 3220 The option MUST NOT depend on the presence or absence of any other 3221 options. The semantics of an option should depend only on the 3222 information in the fixed part of the ND packet and on the 3223 information contained in the option itself. 3225 Adhering to the above rule has the following benefits: 3227 1) Receivers can process options independently of one another. For 3228 example, an implementation can choose to process the Prefix 3229 Information option contained in a Router Advertisement message in a 3230 user-space process while the link-layer address option in the same 3231 message is processed by routines in the kernel. 3233 2) Should the number of options cause a packet to exceed a link's MTU, 3234 multiple packets can carry subsets of the options without any 3235 change in semantics. 3237 3) Senders MAY send a subset of options in different packets. For 3238 instance, if a prefix's Valid and Preferred Lifetime are high 3239 enough, it might not be necessary to include the Prefix Information 3240 option in every Router Advertisement. In addition, different 3241 routers might send different sets of options. Thus, a receiver 3242 MUST NOT associate any action with the absence of an option in a 3243 particular packet. This protocol specifies that receivers should 3244 only act on the expiration of timers and on the information that is 3245 received in the packets. 3247 Options in Neighbor Discovery packets can appear in any order; receivers 3248 MUST be prepared to process them independently of their order. There 3249 can also be multiple instances of the same option in a message (e.g., 3250 Prefix Information options). 3252 If the number of included options in a Router Advertisement causes the 3253 advertisement's size to exceed the link MTU, the router can send 3254 multiple separate advertisements each containing a subset of the 3255 options. 3257 The amount of data to include in the Redirected Header option MUST be 3258 limited so that the entire redirect packet does not exceed 576 octets. 3260 All options are a multiple of 8 octets of length, ensuring appropriate 3261 alignment without any "pad" options. The fields in the options (as well 3262 as the fields in ND packets) are defined to align on their natural 3263 boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with 3264 the exception of the 128-bit IP addresses/prefixes, which are aligned on 3265 a 64-bit boundary. The link-layer address field contains an 3266 uninterpreted octet string; it is aligned on an 8-bit boundary. 3268 The size of an ND packet including the IP header is limited to the link 3269 MTU (which is at least 576 octets). When adding options to an ND packet 3270 a node MUST NOT exceed the link MTU. 3272 Future versions of this protocol may define new option types. Receivers 3273 MUST silently ignore any options they do not recognize and continue 3274 processing the message. 3276 10. PROTOCOL CONSTANTS 3278 Router constants: 3280 MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds 3282 MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions 3284 MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions 3286 MIN_DELAY_BETWEEN_RAS 3 seconds 3288 MAX_RA_DELAY_TIME .5 seconds 3290 Host constants: 3292 MAX_RTR_SOLICITATION_DELAY 1 second 3294 RTR_SOLICITATION_INTERVAL 4 seconds 3296 MAX_RTR_SOLICITATIONS 3 transmissions 3298 Node constants: 3300 MAX_MULTICAST_SOLICIT 3 transmissions 3302 MAX_UNICAST_SOLICIT 3 transmissions 3304 MAX_ANYCAST_DELAY_TIME 1 second 3306 MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions 3308 REACHABLE_TIME 30,000 milliseconds 3310 RETRANS_TIMER 1,000 milliseconds 3312 DELAY_FIRST_PROBE_TIME 5 seconds 3314 MIN_RANDOM_FACTOR .5 3316 MAX_RANDOM_FACTOR 1.5 3318 Additional protocol constants are defined with the message formats in 3319 Section 4. 3321 All protocol constants are subject to change in future revisions of the 3322 protocol. 3324 The constants in this specification may be overridden by specific 3325 documents that describe how IPv6 operates over different link layers. 3326 This rule allows Neighbor Discovery to operate over links with widely 3327 varying performance characteristics. 3329 11. SECURITY CONSIDERATIONS 3331 Neighbor Discovery is subject attacks that cause IP packets to flow to 3332 unexpected places. Such attacks can be used to cause denial of service 3333 but also allow nodes to intercept and optionally modify packets destined 3334 for other nodes. 3336 The protocol reduces the exposure to such threats in the absence of 3337 authentication by ignoring ND packets received from off-link senders. 3338 The Hop Limit field of all received packets is verified to contain 255, 3339 the maximum legal value. Because routers decrement the Hop Limit on all 3340 packets they forward, received packets containing a Hop Limit of 255 3341 must have originated from a neighbor. 3343 The trust model for redirects is the same as in IPv4. A redirect is 3344 accepted only if received from the same router that is currently being 3345 used for that destination. It is natural to trust the routers on the 3346 link. If a host has been redirected to another node (i.e., the 3347 destination is on-link) there is no way to prevent the target from 3348 issuing another redirect to some other destination. However, this 3349 exposure is no worse than it was; the target host, once subverted, could 3350 always act as a hidden router to forward traffic elsewhere. 3352 The protocol contains no mechanism to determine which neighbors are 3353 authorized to send a particular type of message e.g. Router 3354 Advertisements; any neighbor, presumably even in the presence of 3355 authentication, can send Router Advertisement messages thereby being 3356 able to cause denial of service. Furthermore, any neighbor can send 3357 proxy Neighbor Advertisements as well as unsolicited Neighbor 3358 Advertisements as a potential denial of service attack. 3360 Neighbor Discovery protocol packet exchanges can be authenticated using 3361 the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an 3362 Authentication Header when sending Neighbor Discovery packets if a 3363 security association for use with the IP Authentication Header exists 3364 for the destination address. The security associations may have been 3365 created through manual configuration or through the operation of some 3366 key management protocol. 3368 Received Authentication Headers in Neighbor Discovery packets MUST be 3369 verified for correctness and packets with incorrect authentication MUST 3370 be ignored. 3372 It SHOULD be possible for the system administrator to configure a node 3373 to ignore any Neighbor Discovery messages that are not authenticated 3374 using either the Authentication Header or Encapsulating Security 3375 Payload. The configuration technique for this MUST be documented. Such 3376 a switch SHOULD default to allowing unauthenticated messages. 3378 Confidentiality issues are addressed by the IP Security Architecture and 3379 the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP]. 3381 REFERENCES 3383 [ADDRCONF] S. Thomson, "IPv6 Address Autoconfiguration", Internet 3384 Draft. 3386 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing 3387 Architecture", Internet Draft. 3389 [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 3390 Service", RFC 1546, November 1993. 3392 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 3393 RFC 826, November 1982. 3395 [HR-CL] R. Braden, Editor, "Requirements for Internet Hosts -- 3396 Communication Layers", STD 3, RFC 1122, October 1989. 3398 [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 3399 792, September 1981. 3401 [ICMPv6] A. Conta, and S. Deering, "ICMP for the Internet Protocol 3402 Version 6 (IPv6)", Internet Draft. 3404 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 3405 (IPv6) Specification", Internet Draft. 3407 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 3408 Packets over Ethernet Networks", Internet Draft. 3410 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 3411 Protocol". RFC 1825, August 1995. 3413 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 3414 August 1995. 3416 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 3417 RFC 1827, August 1995. 3419 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 3420 September 1991. 3422 [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture 3423 Extensions for Shared Media", RFC 1620, May 1994. 3425 [ASSIGNED] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 3426 October 1994. 3428 [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing 3429 Messages", IEEE/ACM Transactions on Networking, April 1994. 3430 ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z 3432 AUTHORS' ADDRESSES 3434 Erik Nordmark Thomas Narten 3435 Sun Microsystems, Inc. IBM Corporation 3436 2550 Garcia Ave P.O. Box 12195 3437 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 3438 USA USA 3440 phone: +1 415 336 2788 phone: +1 919 254 7798 3441 fax: +1 415 336 6015 fax: +1 919 254 4027 3442 email: nordmark@sun.com email: narten@vnet.ibm.com 3444 William Allen Simpson 3445 Daydreamer 3446 Computer Systems Consulting Services 3447 1384 Fontaine 3448 Madison Heights, Michigan 48071 3449 USA 3451 email: Bill.Simpson@um.cc.umich.edu 3452 bsimpson@MorningStar.com 3454 APPENDIX A: MULTIHOMED HOSTS 3456 There are a number of complicating issues that arise when Neighbor 3457 Discovery is used by hosts that have multiple interfaces. This section 3458 does not attempt to define the proper operation of multihomed hosts with 3459 regard to Neighbor Discovery. Rather, it identifies issues that require 3460 further study. Implementors are encouraged to experiment with various 3461 approaches to making Neighbor Discovery work on multihomed hosts and to 3462 report their experiences. 3464 If a multihomed host receives Router Advertisements on all of its 3465 interfaces, it will (probably) have learned on-link prefixes for the 3466 addresses residing on each link. When a packet must be sent through a 3467 router, however, selecting the "wrong" router can result in a suboptimal 3468 or non-functioning path. There are number of issues to consider: 3470 1) In order for a router to send a redirect, it must determine that 3471 the packet it is forwarding originates from a neighbor. The 3472 standard test for this case is to compare the source address of the 3473 packet to the list of on-link prefixes associated with the 3474 interface on which the packet was received. If the originating 3475 host is multihomed, however, the source address it uses may belong 3476 to an interface other than the interface from which it was sent. 3477 In such cases, a router will not send redirects, and suboptimal 3478 routing is likely. In order to be redirected, the sending host 3479 must always send packets out the interface corresponding to the 3480 outgoing packet's source address. Note that this issue never 3481 arises with non-multihomed hosts; they only have one interface. 3483 2) If the selected first-hop router does not have a route at all for 3484 the destination, it will be unable to deliver the packet. However, 3485 the destination may be reachable through a router on one of the 3486 other interfaces. Neighbor Discovery does not address this 3487 scenario; it does not arise in the non-multihomed case. 3489 3) Even if the first-hop router does have a route for a destination, 3490 there may be a better route via another interface. No mechanism 3491 exists for the multihomed host to detect this situation. 3493 If a multihomed host fails to receive Router Advertisements on one or 3494 more of its interfaces, it will not know (in the absence of configured 3495 information) which destinations are on-link on the affected 3496 interface(s). This leads to a number of problems: 3498 1) If no Router Advertisement is received on any interfaces, a 3499 multihomed host will have no way of knowing which interface to send 3500 packets out on, even for on-link destinations. Under similar 3501 conditions in the non-multihomed host case, a node treats all 3502 destinations as residing on-link, and communication proceeds. In 3503 the multihomed case, however, additional information is needed to 3504 select the proper outgoing interface. Alternatively, a node could 3505 attempt to perform address resolution on all interfaces, a step 3506 involving significant complexity that is not present in the non- 3507 multihomed host case. 3509 2) If Router Advertisements are received on some, but not all 3510 interfaces, a multihomed host could choose to only send packets out 3511 on the interfaces on which it has received Router Advertisements. 3512 A key assumption made here, however, is that routers on those other 3513 interfaces will be able to route packets to the ultimate 3514 destination, even when those destinations reside on the subnet to 3515 which the sender connects, but has no on-link prefix information. 3516 Should the assumption be false, communication would fail. Even if 3517 the assumption holds, packets will traverse a sub-optimal path. 3519 APPENDIX B: FUTURE EXTENSIONS 3521 Possible extensions for future study are: 3523 o Using dynamic timers to be able to adapt to links with widely varying 3524 delay. Measuring round trip times, however, requires acknowledgments 3525 and sequence numbers in order to match received Neighbor 3526 Advertisements with the actual Neighbor Solicitation that triggered 3527 the advertisement. Implementors wishing to experiment with such a 3528 facility could do so in a backwards-compatible way by defining a new 3529 option carrying the necessary information. Nodes not understanding 3530 the option would simply ignore it. 3532 o Adding capabilities to facilitate the operation over links that 3533 currently require hosts to register with an address resolution 3534 server. This could for instance enable routers to ask hosts to send 3535 them periodic unsolicited advertisements. Once again this can be 3536 added using a new option sent in the Router Advertisements. 3538 o Adding additional procedures for links where asymmetric and non- 3539 transitive reachability is part of normal operations. Such 3540 procedures might allow hosts and routers to find usable paths on, 3541 e.g., radio links. 3543 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE 3545 This appendix contains a summary of the rules specified in Sections 7.2 3546 and 7.3. This document does not mandate that implementations adhere to 3547 this model as long as their external behavior is consistent with that 3548 described in this document. 3550 When performing address resolution and Neighbor Unreachability Detection 3551 the following state transitions apply using the conceptual model: 3553 State Event Action New state 3555 - Packet to send. Create entry. INCOMPLETE 3556 Send multicast NS. 3557 Start retransmit timer 3559 INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE 3560 less than N Start retransmit timer 3561 retransmissions. 3563 INCOMPLETE Retransmit timeout, Discard entry - 3564 N or more Send ICMP error 3565 retransmissions. 3567 INCOMPLETE NA, Solicited=0, Record link-layer STALE 3568 Override=any address. 3570 INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3571 Override=any address. 3573 !INCOMPLETE NA, Solicited=1, - REACHABLE 3574 Override=0 3576 !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3577 Override=1 address. 3579 !INCOMPLETE NA, Solicited=0, - STALE 3580 Override=0 3582 !INCOMPLETE NA, Solicited=0, Record link-layer STALE 3583 Override=1 address. 3585 !INCOMPLETE upper-layer reachability - REACHABLE 3586 confirmation 3588 REACHABLE timeout, more than - STALE 3589 N seconds since 3590 reachability confirm. 3592 STALE Sending packet Start delay timer DELAY 3594 DELAY Delay timeout Send unicast NS probe PROBE 3595 Start retransmit timer 3597 PROBE Retransmit timeout, Retransmit NS PROBE 3598 less than N 3599 retransmissions. 3601 PROBE Retransmit timeout, Discard entry - 3602 N or more 3603 retransmissions. 3605 The state transitions for receiving unsolicited information other than 3606 Neighbor Advertisement messages apply to either the source of the packet 3607 (for Neighbor Solicitation, Router Solicitation, and Router 3608 Advertisement messages) or the target address (for Redirect messages) as 3609 follows: 3611 State Event Action New state 3613 - NS, RS, RA, Redirect Create entry. STALE 3615 !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE 3616 Different link-layer address 3617 address than cached. 3619 !INCOMPLETE NS, RS, RA, Redirect - unchanged 3620 Same link-layer 3621 address as cached. 3623 APPENDIX D: IMPLEMENTATION ISSUES 3625 Appendix D.1: Reachability confirmations 3627 Neighbor Unreachability Detection requires explicit confirmation that a 3628 forward-path is functioning properly. To avoid the need for Neighbor 3629 Solicitation probe messages, upper layer protocols should provide such 3630 an indication when the cost of doing so is small. Reliable connection- 3631 oriented protocols such as TCP are generally aware when the forward-path 3632 is working. When TCP sends (or receives) data, for instance, it updates 3633 its window sequence numbers, sets and cancels retransmit timers, etc. 3634 Specific scenarios that usually indicate a properly functioning 3635 forward-path include: 3637 - Receipt of an acknowledgement that covers a sequence number (e.g., 3638 data) not previously acknowledged indicates that the forward path was 3639 working at the time the data was sent. 3641 - Completion of the initial three-way handshake is a special case of the 3642 previous rule; although no data is sent during the handshake, the SYN 3643 flags are counted as data from the sequence number perspective. This 3644 applies to both the SYN+ACK for the active open the ACK of that 3645 packet on the passively opening peer. 3647 - Receipt of new data (i.e., data not previously received) indicates 3648 that the forward-path was working at the time an acknowledgement was 3649 sent that advanced the peer's send window that allowed the new data 3650 to be sent. 3652 To minimize the cost of communicating reachability information between 3653 the TCP and IP layers, an implementation may wish to rate-limit the 3654 reachability confirmations its sends IP. One possibility is to process 3655 reachability only every few packets. For example, one might update 3656 reachability information once per round trip time, if an implementation 3657 only has one round trip timer per connection. For those implementations 3658 that cache Destination Cache entries within control blocks, it may be 3659 possible to update the Neighbor Cache entry directly (i.e., without an 3660 expensive lookup) once the TCP packet has been demultiplexed to its 3661 corresponding control block. For other implementation it may be 3662 possible to piggyback the reachability confirmation on the next packet 3663 submitted to IP assuming that the implementation guards against the 3664 piggybacked confirmation becoming stale when no packets are sent to IP 3665 for an extended period of time. 3667 TCP must also guard against thinking "stale" information indicates 3668 current reachability. For example, new data received 30 minutes after a 3669 window has opened up does not constitute a confirmation that the path is 3670 currently working. In merely indicates that 30 minutes ago the window 3671 update reached the peer i.e. the patch was working at that point in 3672 time. An implementation must also take into account TCP zero-window 3673 probes that are sent even if the path is broken and the window update 3674 did not reach the peer. 3676 For UDP based applications (RPC, DNS) it is relatively simple to make 3677 the client send reachability confirmations when the response packet is 3678 received. It is more difficult and in some cases impossible for the 3679 server to generate such confirmations since there is no flow control, 3680 i.e., the server can not determine whether a received request indicates 3681 that a previous response reached the client. 3683 Note that an implementation can not use negative upper-layer advise as a 3684 replacement for the Neighbor Unreachability Detection algorithm. 3685 Negative advise (e.g. from TCP when there are excessive retransmissions) 3686 could serve as a hint that the forward path from the sender of the data 3687 might not be working. But it would fail to detect when the path from 3688 the receiver of the data is not functioning causing, none of the 3689 acknowledgement packets to reach the sender. 3691 APPENDIX E: CHANGES SINCE PREVIOUS VERSION 3693 There are several changes since the previous version documented in: 3694 3695 based on feedback from the working group: 3697 Protocol changes: 3699 o Changed redirect ICMP type from 5 to 137 to make it an 3700 informational ICMP message. 3702 o Simplified the technique for filtering out ND packets sent from 3703 off-link sources. This entailed: 3705 o Added the Hop Count 255 rules for transmit and receive 3706 verification to be able to ignore packets sent from off-link 3707 sources. 3709 o Removed the requirement that NS and NA be sent with link-local 3710 source address. This removed the need for the ICMP Sender 3711 Address field in the NA messages. These changes undo many of 3712 the changes between the -01 and -02 revisions of this 3713 document. 3715 o Removed the validity check for all messages that did not allow 3716 a routing header. 3718 o Removed "no NUD for ND Packets" rule 3720 o Setting the IP priority field to 15 in all ND packets. 3722 o Inverted the semantics of the 'N' flag (secondary advertisement 3723 flag) in Neighbor Advertisements and renamed it to the Override 3724 flag. 3726 o Added rules for periodic randomization of ReachableTime to avoid 3727 long-range periodic behavior when there are no routers on the 3728 link. The ReachableTime randomization only takes place when a RA 3729 advertises a different value or once every few hours. 3731 o Made the bits in the prefix after prefix length bit reserved 3732 (zero on transmit and ignored on receipt). 3734 o Allow RS packets to be sent with an unspecified source address so 3735 that duplicate address detection can be done in parallel with 3736 sending a RS. 3738 o Changed the router behavior for responding to RS so that all 3739 solicited RA messages are multicast to all-nodes with a rate 3740 limit (one message at most every 3 seconds) and a random 3741 dithering (of .5 seconds). 3743 o Increased the lower limit on MaxRtrAdvInterval and 3744 MinRtrAdvInterval to match the rate limit imposed on solicited RA 3745 messages. 3747 o Changed the timers for hosts sending RS to match the routers 3748 response. 3750 o Made hosts always send one RS messages when initializing to avoid 3751 problems when routers only send subsets of options in RA 3752 messages. 3754 o Made the RETRANS_TIMER 1 second with the ability for IP-over-foo 3755 documents to override this default value. 3757 o Added general rules that default values for protocol constants 3758 and variables may be overridden by an IP-over-foo document. This 3759 rule allows ND to operate over links with widely varying 3760 performance characteristics. 3762 o Default setting of AdvSendAdvertisements changed to FALSE to 3763 prevent "routers" from connecting to the network "out of the box" 3764 and sending out bogus advertisements prior to being explicitly 3765 configured. 3767 Editorial changes: 3769 o Created standalone Packet Formats Section between Overview and 3770 Conceptual Model sections. Packet Formats had previously 3771 appeared at the start of the section describing a particular 3772 message type. 3774 o Changed AdvertiseDefault flag to AdvSendAdvertisements. Flag now 3775 indicates whether RAs should be sent. The variable 3776 AdvDefaultLifetime controls whether we advertise ourselves as a 3777 default router. Thus, a router can advertise prefixes and other 3778 info without being used as a default router. 3780 o Added paragraph to Requirements section making it clear that 3781 compliance is defined by external behavior, not use of variables 3782 described in the document 3784 o Changed the name of "is_router" flag to IsRouter for consistency 3785 with other names. 3787 o Changed names of all router configuration variables to begin with 3788 the prefix Adv (e.g., AdvRetransTimer) 3790 o Changed deprecation lifetime to preferred lifetime and 3791 invalidation lifetime to valid lifetime to make the names 3792 consistent with [ADDRCONF]. 3794 o Added text to point out that options that don't belong in a 3795 particular ND message (e.g., prefix option on neighbor 3796 solicitation) MUST be silently ignored. 3798 o Added text to state that on-link flag being zero in a prefix 3799 option does not imply that the prefix is off-link. 3801 o Moved the multihoming material to an appendix. 3803 o Added bit numbering to all formats. 3805 o Clarified that the Target link-layer address option in a NA has 3806 to be the address of the sender. 3808 o Introduced the STALE and DELAY states to better explain the 3809 behavior of NUD. 3811 o Clarified that updated cache entries only go to STALE state when 3812 the link-layer address is different than the recorded address. 3814 o Clarified that NUD specifies that reachability confirmations to 3815 change state to REACHABLE independent of current state. 3817 o Created an appendix to illustrate the rules for reachability 3818 state transitions. 3820 o Added some minor text to "Comparison with IPv4" about why IPv4 3821 router discovery preferences are not needed in ND. 3823 o Added text to "Comparison with IPv4" to point out that the use of 3824 link-local source addresses for RA and Redirect messages makes it 3825 possible for hosts the maintain the router associations in the 3826 event of renumbering. 3828 o Strengthened text pointing out that the conceptual model is not 3829 required by implementations but instead it is only the externally 3830 visible behavior that is specified. 3832 o Added text about implementation issues with positive reachability 3833 advice from upper layers. 3835 o Add wording that says all subsequent text assumes that 3836 message/action applies to a specific interface so we don't always 3837 have to say "receiving interface", etc.? 3839 o Made it more clear that the text in the packet format describes 3840 "common use", e.g., "the destination address is ...". It does 3841 not (always) list hard constraints. 3843 o Added text to point out that when an entry is deleted from the 3844 router list all destination cache entries using that router must 3845 be "updated". 3847 TODO 3849 o Should we change the definition of option lengths so that length 3850 excludes the first 8-byte part? This would make the option 3851 length follow that same rules as the Hdr Ext Len in the base 3852 specification and it would remove the validation checks that 3853 check length > 0. 3855 o This revision increase the minimum values for MinRtrAdvInterval 3856 and MaxRtrAdvInterval from .1 and 1 second respectively to make 3857 the numbers consistent with the Router Advertisement rate limit 3858 of on RA every 3 seconds. If the Router Advertisements will be 3859 use for beaconing in IPv6 mobility those times probably have to 3860 be smaller. With such a change the MIN_DELAY_BETWEEN_RAS would 3861 either have to be configurable or have a lower value. 3863 o Get WG feedback on need for booting hosts to always send out 1 3864 RS, so that routers know to include all options in outgoing RAs. 3865 Or remove the capability that routers can sent a subset of the 3866 options in their RAs? The reason ND allows RAs that contain a 3867 subset of the options is in anticipation of IPv6 mobility using 3868 RAs for frequent beaconing. 3870 o Make all timer constants be in units of milliseconds? (to 3871 implicitly make it more clear that implementations need higher 3872 timer resolution than 1 second).