idnits 2.17.1 draft-ietf-ipngwg-discovery-05.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-19) 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 420: '... MUST have a link-local address. Also, [ADDRCONF]...' RFC 2119 keyword, line 439: '... MUST...' RFC 2119 keyword, line 443: '... MUST NOT...' RFC 2119 keyword, line 447: '... SHOULD...' RFC 2119 keyword, line 453: '... SHOULD NOT...' (206 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 3693 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 3459, but no explicit reference was found in the text == Unused Reference: 'IPv6' is defined on line 3475, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ADDRCONF' ** Obsolete normative reference: RFC 1884 (ref. 'ADDR-ARCH') (Obsoleted by RFC 2373) ** Downref: Normative reference to an Informational RFC: RFC 1546 (ref. 'ANYCST') ** Obsolete normative reference: RFC 1885 (ref. 'ICMPv6') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) -- Possible downref: Non-RFC (?) normative reference: ref. 'IPv6-ETHER' ** Obsolete normative reference: RFC 1825 (ref. 'IPv6-SA') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'IPv6-AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'IPv6-ESP') (Obsoleted by RFC 2406) ** Downref: Normative reference to an Informational RFC: RFC 1620 (ref. 'SH-MEDIA') ** Obsolete normative reference: RFC 1700 (ref. 'ASSIGNED') (Obsoleted by RFC 3232) -- Possible downref: Non-RFC (?) normative reference: ref. 'SYNC' Summary: 18 errors (**), 0 flaws (~~), 5 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Thomas Narten, IBM 3 February 22, 1996 Erik Nordmark, Sun Microsystems 4 W A Simpson, Daydreamer 6 Neighbor Discovery for IP Version 6 (IPv6) 8 10 Status of this Memo 12 This document is an Internet-Draft. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as ``work in progress.'' 22 To learn the current status of any Internet-Draft, please check the 23 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 24 Directories on ds.internic.net (US East Coast), nic.nordu.net 25 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 26 Rim). 28 Distribution of this memo is unlimited. 30 This Internet Draft expires August 22, 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.............................................. 5 47 2.1. General............................................. 5 48 2.2. Link Types.......................................... 8 49 2.3. Addresses........................................... 9 50 2.4. Requirements........................................ 10 52 3. PROTOCOL OVERVIEW........................................ 11 53 3.1. Comparison with IPv4................................ 15 54 3.2. Supported Link Types................................ 17 56 4. MESSAGE FORMATS.......................................... 18 57 4.1. Router Solicitation Message Format.................. 18 58 4.2. Router Advertisement Message Format................. 19 59 4.3. Neighbor Solicitation Message Format................ 22 60 4.4. Neighbor Advertisement Message Format............... 24 61 4.5. Redirect Message Format............................. 26 62 4.6. Option Formats...................................... 28 63 4.6.1. Source/Target Link-layer Address............... 29 64 4.6.2. Prefix Information............................. 30 65 4.6.3. Redirected Header.............................. 32 66 4.6.4. MTU............................................ 33 68 5. CONCEPTUAL MODEL OF A HOST............................... 34 69 5.1. Conceptual Data Structures.......................... 34 70 5.2. Conceptual Sending Algorithm........................ 36 71 5.3. Garbage Collection and Timeout Requirements......... 38 73 6. ROUTER AND PREFIX DISCOVERY.............................. 38 74 6.1. Message Validation.................................. 39 75 6.1.1. Validation of Router Solicitation Messages..... 39 76 6.1.2. Validation of Router Advertisement Messages.... 40 77 6.2. Router Specification................................ 40 78 6.2.1. Router Configuration Variables................. 41 79 6.2.2. Becoming An Advertising Interface.............. 44 80 6.2.3. Router Advertisement Message Content........... 45 81 6.2.4. Sending Unsolicited Router Advertisements...... 46 82 6.2.5. Ceasing To Be An Advertising Interface......... 47 83 6.2.6. Processing Router Solicitations................ 47 84 6.2.7. Router Advertisement Consistency............... 49 85 6.2.8. Link-local Address Change...................... 49 86 6.3. Host Specification.................................. 50 87 6.3.1. Host Configuration Variables................... 50 88 6.3.2. Host Variables................................. 50 89 6.3.3. Interface Initialization....................... 51 90 6.3.4. Processing Received Router Advertisements...... 51 91 6.3.5. Timing out Prefixes and Default Routers........ 54 92 6.3.6. Default Router Selection....................... 54 93 6.3.7. Sending Router Solicitations................... 55 95 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION. 56 96 7.1. Message Validation.................................. 56 97 7.1.1. Validation of Neighbor Solicitations........... 57 98 7.1.2. Validation of Neighbor Advertisements.......... 57 99 7.2. Address Resolution.................................. 58 100 7.2.1. Interface Initialization....................... 58 101 7.2.2. Sending Neighbor Solicitations................. 59 102 7.2.3. Receipt of Neighbor Solicitations.............. 60 103 7.2.4. Sending Solicited Neighbor Advertisements...... 60 104 7.2.5. Receipt of Neighbor Advertisements............. 61 105 7.2.6. Sending Unsolicited Neighbor Advertisements.... 62 106 7.2.7. Anycast Neighbor Advertisements................ 63 107 7.2.8. Proxy Neighbor Advertisements.................. 64 108 7.3. Neighbor Unreachability Detection................... 64 109 7.3.1. Reachability Confirmation...................... 65 110 7.3.2. Neighbor Cache Entry States.................... 66 111 7.3.3. Node Behavior.................................. 67 113 8. REDIRECT FUNCTION........................................ 69 114 8.1. Validation of Redirect Messages..................... 69 115 8.2. Router Specification................................ 70 116 8.3. Host Specification.................................. 71 118 9. EXTENSIBILITY - OPTION PROCESSING........................ 72 120 10. PROTOCOL CONSTANTS...................................... 74 122 11. SECURITY CONSIDERATIONS................................. 75 124 REFERENCES................................................... 77 126 AUTHORS' ADDRESSES........................................... 78 128 APPENDIX A: MULTIHOMED HOSTS................................. 79 130 APPENDIX B: FUTURE EXTENSIONS................................ 80 132 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE......... 81 134 APPENDIX D: IMPLEMENTATION ISSUES............................ 83 135 Appendix D.1: Reachability confirmations.................. 83 137 1. INTRODUCTION 139 This specification defines the Neighbor Discovery (ND) protocol for 140 Internet Protocol Version 6 (IPv6). Nodes (hosts and routers) use 141 Neighbor Discovery to determine the link-layer addresses for neighbors 142 known to reside on attached links and to quickly purge cached values 143 that become invalid. Hosts also use Neighbor Discovery to find 144 neighboring routers that are willing to forward packets on their behalf. 145 Finally, nodes use the protocol to actively keep track of which 146 neighbors are reachable and which are not, and to detect changed link- 147 layer addresses. When a router or the path to a router fails, a host 148 actively searches for functioning alternates. 150 Unless specified otherwise (in a document that covers operating IP over 151 a particular link type) this document applies to all link types. 152 However, because ND uses link-layer multicast for some of its services, 153 it is possible that on some link types (e.g., NBMA links) alternative 154 protocols or mechanisms to implement those services will be specified 155 (in the appropriate document covering the operation of IP over a 156 particular link type). The services described in this document that are 157 not directly dependent on multicast, such as Redirects, Next-hop 158 determination, Neighbor Unreachability Detection, etc., are expected to 159 be provided as specified in this document. The details of how one uses 160 ND on NBMA links is an area for further study. 162 The authors would like to acknowledge the contributions the IPNGWG 163 working group and, in particular, (in alphabetical order) Ran Atkinson, 164 Jim Bound, Scott Bradner, Alex Conta, Stephen Deering, Francis Dupont, 165 Robert Elz, Robert Gilligan, Robert Hinden, Allison Mankin, Dan 166 McDonald, Charles Perkins, Matt Thomas, and Susan Thomson. 168 2. TERMINOLOGY 170 2.1. General 172 IP - Internet Protocol Version 6. The terms IPv4 and IPv6 173 are used only in contexts where necessary to avoid 174 ambiguity. 176 ICMP - Internet Message Control Protocol for the Internet 177 Protocol Version 6. The terms ICMPv4 and ICMPv6 are 178 used only in contexts where necessary to avoid 179 ambiguity. 181 node - a device that implements IP. 183 router - a node that forwards IP packets not explicitly 184 addressed to itself. 186 host - any node that is not a router. 188 upper layer - a protocol layer immediately above IP. Examples are 189 transport protocols such as TCP and UDP, control 190 protocols such as ICMP, routing protocols such as OSPF, 191 and internet or lower-layer protocols being "tunneled" 192 over (i.e., encapsulated in) IP such as IPX, AppleTalk, 193 or IP itself. 195 link - a communication facility or medium over which nodes can 196 communicate at the link layer, i.e., the layer 197 immediately below IP. Examples are Ethernets (simple 198 or bridged), PPP links, X.25, Frame Relay, or ATM 199 networks as well as internet (or higher) layer 200 "tunnels", such as tunnels over IPv4 or IPv6 itself. 202 interface - a node's attachment to a link. 204 neighbors - nodes attached to the same link. 206 address - an IP-layer identifier for an interface or a set of 207 interfaces. 209 anycast address 210 - an identifier for a set of interfaces (typically 211 belonging to different nodes). A packet sent to an 212 anycast address is delivered to one of the interfaces 213 identified by that address (the "nearest" one, 214 according to the routing protocol's measure of 215 distance). See [ADDR-ARCH]. 217 Note that an anycast address is syntactically 218 indistinguishable from a unicast address. Thus, nodes 219 sending packets to anycast addresses don't generally 220 know that an anycast address is being used. Throughout 221 the rest of this document, references to unicast 222 addresses also apply to anycast addresses in those 223 cases where the node is unaware that a unicast address 224 is actually an anycast address. 226 prefix - a bit string that consists of some number of initial 227 bits of an address. 229 link-layer address 230 - a link-layer identifier for an interface. Examples 231 include IEEE 802 addresses for Ethernet links and E.164 232 addresses for ISDN links. 234 on-link - an address that is assigned to an interface on a 235 specified link. A node considers an address to be on- 236 link if: 238 - it is covered by one of the link's prefixes, or 240 - a neighboring router specifies the address as the 241 target of a Redirect message, or 243 - a Neighbor Advertisement message is received for 244 the (target) address, or 246 - any Neighbor Discovery message is received from the 247 address. 249 off-link - the opposite of "on-link"; an address that is not 250 assigned to any interfaces on the specified link. 252 longest prefix match 253 - The process of determining which prefix (if any) in a 254 set of prefixes covers a target address. A target 255 address is covered by a prefix if all of the bits in 256 the prefix match the left-most bits of the target 257 address. When multiple prefixes cover an address, the 258 longest prefix is the one that matches. 260 reachability 261 - whether or not the one-way "forward" path to a neighbor 262 is functioning properly. In particular, whether 263 packets sent to a neighbor are reaching the IP layer on 264 the neighboring machine and are being processed 265 properly by the receiving IP layer. For neighboring 266 routers, reachability means that packets sent by a 267 node's IP layer are delivered to the router's IP layer, 268 and the router is indeed forwarding packets (i.e., it 269 is configured as a router, not a host). For hosts, 270 reachability means that packets sent by a node's IP 271 layer are delivered to the neighbor host's IP layer. 273 packet - an IP header plus payload. 275 link MTU - the maximum transmission unit, i.e., maximum packet 276 size in octets, that can be conveyed in one piece over 277 a link. 279 target - an address about which address resolution information 280 is sought, or an address which is the new first-hop 281 when being redirected. 283 proxy - a router that responds to Neighbor Discovery query 284 messages on behalf of another node. A router acting on 285 behalf of a mobile node that has moved off-link could 286 potentially act as a proxy for the mobile node. 288 ICMP destination unreachable indication 289 - an error indication returned to the original sender of 290 a packet that cannot be delivered for the reasons 291 outlined in [ICMPv6]. If the error occurs on a node 292 other than the node originating the packet, an ICMP 293 error message is generated. If the error occurs on the 294 originating node, an implementation is not required to 295 actually create and send an ICMP error packet to the 296 source, as long as the upper-layer sender is notified 297 through an appropriate mechanism (e.g., return value 298 from a procedure call). Note, however, that an 299 implementation may find it convenient in some cases to 300 return errors to the sender by taking the offending 301 packet, generating an ICMP error message, and then 302 delivering it (locally) through the generic error 303 handling routines. 305 random delay 306 - when sending out messages, it is sometimes necessary to 307 delay a transmission for a random amount of time in 308 order to prevent multiple nodes from transmitting at 309 exactly the same time, or to prevent long-range 310 periodic transmissions from synchronizing with each 311 other [SYNC]. When a random component is required, a 312 node calculates the actual delay in such a way that the 313 computed delay forms a uniformly-distributed random 314 value that falls between the specified minimum and 315 maximum delay times. The implementor must take care to 316 insure that the granularity of the calculated random 317 component and the resolution of the timer used are both 318 high enough to insure that the probability of multiple 319 nodes delaying the same amount of time is small. 321 random delay seed 322 - If a pseudo-random number generator is used in 323 calculating a random delay component, the generator 324 should be initialized with a unique seed prior to being 325 used. Note that it is not sufficient to use the 326 interface token alone as the seed, since interface 327 tokens will not always be unique. To reduce the 328 probability that duplicate interface tokens cause the 329 same seed to be used, the seed should be calculated 330 from a variety of input sources (e.g., machine 331 components) that are likely to be different even on 332 identical "boxes". For example, the seed could be 333 formed by combining the CPU's serial number with an 334 interface token. 336 2.2. Link Types 338 Different link layers have different properties. The ones of concern to 339 Neighbor Discovery are: 341 multicast - a link that supports some mechanism at the link 342 layer for sending packets to all (i.e., broadcast) 343 or a subset of all neighbors. Multicast/broadcast 344 can be provided by a variety of link layer 345 mechanisms such as the physical link layer itself 346 (for example, Ethernet), replicated unicast packets 347 sent by the link layer software, or multicast 348 servers (such as in ATM). Note that all point-to- 349 point links are trivially capable of supporting 350 multicast. 352 point-to-point - a link that connects exactly two interfaces. A 353 point-to-point link is assumed to have multicast 354 capability and have a link-local address. 356 non-broadcast multi-access (NBMA) 357 - a link to which more than two interfaces can attach, 358 but that does not support any form of multicast or 359 broadcast (e.g., X.25). 361 shared media - a link that allows direct communication among a 362 number of nodes, but attached nodes are configured 363 in such a way that they do not have complete prefix 364 information for all on-link destinations. That is, 365 at the IP level, nodes on the same link may not know 366 that they are neighbors; by default, they 367 communicate through a router. Examples are large 368 (switched) public data networks such as SMDS and B- 369 ISDN. Also known as "large clouds". See [SH- 370 MEDIA]. 372 variable MTU - a link that does not have a well-defined MTU (e.g., 373 IEEE 802.5 token rings). Many links (e.g., 374 Ethernet) have a standard MTU defined by the link- 375 layer protocol or by the specific document 376 describing how to run IP over the link layer. 378 asymmetric reachability 379 - a link where non-reflexive and/or non-transitive 380 reachability is part of normal operation. (Non- 381 reflexive reachability means packets from A reach B 382 but packets from B don't reach A. Non-transitive 383 reachability means packets from A reach B, and 384 packets from B reach C, but packets from A don't 385 reach C.) Many radio links exhibit these 386 properties. 388 2.3. Addresses 390 Neighbor Discovery makes use of a number of different addresses defined 391 in [ADDR-ARCH], including: 393 all-nodes multicast address 394 - the link-local scope address to reach all nodes. 395 FF02::1 397 all-routers multicast address 398 - the link-local scope address to reach all routers. 399 FF02::2 401 solicited-node multicast address 402 - a link-local scope multicast address that is computed 403 as a function of the solicited target's address. The 404 solicited-node multicast address is formed by taking 405 the low-order 32 bits of the target IP address and 406 appending those bits to the 96-bit prefix 407 FF02:0:0:0:0:1 to produce a multicast address within 408 the range FF02::1:0:0 to FF02::1:FFFF:FFFF. For 409 example, the solicited node multicast address 410 corresponding to the IP address 4037::01:800:200E:8C6C 411 is FF02::1:200E:8C6C. IP addresses that differ only in 412 the high-order bits, e.g., due to multiple high-order 413 prefixes associated with different providers, will map 414 to the same solicited-node address thereby reducing the 415 number of multicast addresses a node must join. 417 link-local address 418 - a unicast address having link-only scope that can be 419 used to reach neighbors. All interfaces on routers 420 MUST have a link-local address. Also, [ADDRCONF] 421 requires that interfaces on hosts have a link-local 422 address. 424 unspecified address 425 - a reserved address value that indicates the lack of an 426 address (e.g., the address is unknown). It is never 427 used as a destination address, but may be used as a 428 source address if the sender does not (yet) know its 429 own address (e.g., while verifying an address is unused 430 during address autoconfiguration [ADDRCONF]). The 431 unspecified address has a value of 0:0:0:0:0:0:0:0. 433 2.4. Requirements 435 Throughout this document, the words that are used to define the 436 significance of the particular requirements are capitalized. These 437 words are: 439 MUST 440 This word or the adjective "REQUIRED" means that the item is an 441 absolute requirement of this specification. 443 MUST NOT 444 This phrase means the item is an absolute prohibition of this 445 specification. 447 SHOULD 448 This word or the adjective "RECOMMENDED" means that there may 449 exist valid reasons in particular circumstances to ignore this 450 item, but the full implications should be understood and the 451 case carefully weighed before choosing a different course. 453 SHOULD NOT 454 This phrase means that there may exist valid reasons in 455 particular circumstances when the listed behavior is acceptable 456 or even useful, but the full implications should be understood 457 and the case carefully weighted before implementing any behavior 458 described with this label. 460 MAY This word or the adjective "OPTIONAL" means that this item is 461 truly optional. One vendor may choose to include the item 462 because a particular marketplace requires it or because it 463 enhances the product, for example, another vendor may omit the 464 same item. 466 This document also makes use of internal conceptual variables to 467 describe protocol behavior and external variables that an implementation 468 must allow system administrators to change. The specific variable 469 names, how their values change, and how their settings influence 470 protocol behavior are provided to demonstrate protocol behavior. An 471 implementation is not required to have them in the exact form described 472 here, so long as its external behavior is consistent with that described 473 in this document. 475 3. PROTOCOL OVERVIEW 477 This protocol solves a set of problems related to the interaction 478 between nodes attached to the same link. It defines mechanisms for 479 solving each of the following problems: 481 Router Discovery: How hosts locate routers that reside on an 482 attached link. 484 Prefix Discovery: How hosts discover the set of address prefixes 485 that define which destinations are on-link for an 486 attached link. (Nodes use prefixes to distinguish 487 destinations that reside on-link from those only 488 reachable through a router.) 490 Parameter Discovery: How a node learns such link parameters as the 491 link MTU or such Internet parameters as the hop limit 492 value to place in outgoing packets. 494 Address Autoconfiguration: How nodes automatically configure an 495 address for an interface. 497 Address resolution: How nodes determine the link-layer address of an 498 on-link destination (e.g., a neighbor) given only the 499 destination's IP address. 501 Next-hop determination: The algorithm for mapping an IP destination 502 address into the IP address of the neighbor to which 503 traffic for the destination should be sent. The next-hop 504 can be a router or the destination itself. 506 Neighbor Unreachability Detection: How nodes determine that a 507 neighbor is no longer reachable. For neighbors used as 508 routers, alternate default routers can be tried. For 509 both routers and hosts, address resolution can be 510 performed again. 512 Duplicate Address Detection: How a node determines that an address 513 it wishes to use is not already in use by another node. 515 Redirect: How a router informs a host of a better first-hop node to 516 reach a particular destination. 518 Neighbor Discovery defines five different ICMP packet types: A pair of 519 Router Solicitation and Router Advertisement messages, a pair of 520 Neighbor Solicitation and Neighbor Advertisements messages, and a 521 Redirect message. The messages serve the following purpose: 523 Router Solicitation: When an interface becomes enabled, hosts may 524 send out Router Solicitations that request routers to 525 generate Router Advertisements immediately rather than at 526 their next scheduled time. 528 Router Advertisement: Routers advertise their presence together with 529 various link and Internet parameters either periodically, 530 or in response to a Router Solicitation message. Router 531 Advertisements contain prefixes that are used for on-link 532 determination and/or address configuration, a suggested 533 hop limit value, etc. 535 Neighbor Solicitation: Sent by a node to determine the link-layer 536 address of a neighbor, or to verify that a neighbor is 537 still reachable via a cached link-layer address. 538 Neighbor Solicitations are also used for Duplicate 539 Address Detection. 541 Neighbor Advertisement: A response to a Neighbor Solicitation 542 message. A node may also send unsolicited Neighbor 543 Advertisements to announce a link-layer address change. 545 Redirect: Used by routers to inform hosts of a better first hop for 546 a destination. 548 On multicast-capable links, each router periodically multicasts a Router 549 Advertisement packet announcing its availability. A host receives 550 Router Advertisements from all routers, building a list of default 551 routers. Routers generate Router Advertisements frequently enough that 552 hosts will learn of their presence within a few minutes, but not 553 frequently enough to rely on an absence of advertisements to detect 554 router failure; a separate Neighbor Unreachability Detection algorithm 555 provides failure detection. 557 Router Advertisements contain a list of prefixes used for on-link 558 determination and/or autonomous address configuration; flags associated 559 with the prefixes specify the intended uses of a particular prefix. 560 Hosts use the advertised on-link prefixes to build and maintain a list 561 that is used in deciding when a packet's destination is on-link or 562 beyond a router. Note that a destination can be on-link even though it 563 is not covered by any advertised on-link prefix. In such cases a router 564 can send a Redirect informing the sender that the destination is a 565 neighbor. 567 Router Advertisements (and per-prefix flags) allow routers to inform 568 hosts how to perform Address Autoconfiguration. For example, routers 569 can specify whether hosts should use stateful (DHCPv6) and/or autonomous 570 (stateless) address configuration. The exact semantics and usage of the 571 address configuration-related information is specified in [ADDRCONF]. 573 Router Advertisement messages also contain Internet parameters such as 574 the hop limit that hosts should use in outgoing packets and, optionally, 575 link parameters such as the link MTU. This facilitates centralized 576 administration of critical parameters that can be set on routers and 577 automatically propagated to all attached hosts. 579 Nodes accomplish address resolution by multicasting a Neighbor 580 Solicitation that asks the target node to return its link-layer address. 581 Neighbor Solicitation messages are multicast to the solicited-node 582 multicast address of the target address. The target returns its link- 583 layer address in a unicast Neighbor Advertisement message. A single 584 request-response pair of packets is sufficient for both the initiator 585 and the target to resolve each other's link-layer addresses; the 586 initiator includes its link-layer address in the Neighbor Solicitation. 588 Neighbor Solicitation messages can also be used to determine if more 589 than one node has been assigned the same unicast address. The use of 590 Neighbor Solicitation messages for Duplicate Address Detection is 591 specified in [ADDRCONF]. 593 Neighbor Unreachability Detection detects the failure of a neighbor or 594 the failure of the forward path to the neighbor. Doing so requires 595 positive confirmation that packets sent to a neighbor are actually 596 reaching that neighbor and being processed properly by its IP layer. 597 Neighbor Unreachability Detection uses confirmation from two sources. 598 When possible, upper-layer protocols provide a positive confirmation 599 that a connection is making "forward progress", that is, previously sent 600 data is known to have been delivered correctly (e.g., new 601 acknowledgments were received recently). When positive confirmation is 602 not forthcoming through such "hints", a node sends unicast Neighbor 603 Solicitation messages that solicit Neighbor Advertisements as 604 reachability confirmation from the next hop. To reduce unnecessary 605 network traffic, probe messages are only sent to neighbors to which the 606 node is actively sending packets. 608 In addition to addressing the above general problems, Neighbor Discovery 609 also handles the following situations: 611 Link-layer address change - A node that knows its link-layer 612 address has changed can multicast a few (unsolicited) Neighbor 613 Advertisement packets to all nodes to quickly update cached 614 link-layer addresses that have become invalid. Note that the 615 sending of unsolicited advertisements is a performance 616 enhancement only (e.g., unreliable). The Neighbor 617 Unreachability Detection algorithm ensures that all nodes will 618 reliably discover the new address, though the delay may be 619 somewhat longer. 621 Inbound load balancing - Nodes with replicated interfaces may want 622 to load balance the reception of incoming packets across 623 multiple network interfaces on the same link. Such nodes have 624 multiple link-layer addresses assigned to the same interface. 625 For example, a single network driver could represent multiple 626 network interface cards as a single logical interface having 627 multiple link-layer addresses. Load balancing is handled by 628 allowing routers to omit the source link-layer address from 629 Router Advertisement packets, thereby forcing neighbors to use 630 Neighbor Solicitation messages to learn link-layer addresses 631 of routers. Returned Neighbor Advertisement messages can then 632 contain link-layer addresses that differ depending on who 633 issued the solicitation. 635 Anycast addresses - Anycast addresses identify one of a set of 636 nodes providing an equivalent service, and multiple nodes on 637 the same link may be configured to recognize the same Anycast 638 address. Neighbor Discovery handles anycasts by having nodes 639 expect to receive multiple Neighbor Advertisements for the 640 same target. All advertisements for anycast addresses are 641 tagged as being non-Override advertisements. This invokes 642 specific rules to determine which of potentially multiple 643 advertisements should be used. 645 Proxy advertisements - A router willing to accept packets on behalf 646 of a target address that is unable to respond to Neighbor 647 Solicitations can issue non-Override Neighbor Advertisements. 648 There is currently no specified use of proxy, but proxy 649 advertising could potentially be used to handle cases like 650 mobile nodes that have moved off-link. However, it is not 651 intended as a general mechanism to handle nodes that, e.g., do 652 not implement this protocol. 654 3.1. Comparison with IPv4 656 The IPv6 Neighbor Discovery protocol corresponds to a combination of the 657 IPv4 protocols ARP [ARP], ICMP Router Discovery [RDISC], and ICMP 658 Redirect [ICMPv4]. In IPv4 there is no generally agreed upon protocol 659 or mechanism for Neighbor Unreachability Detection, although Hosts 660 Requirements [HR-CL] does specify some possible algorithms for Dead 661 Gateway Detection (a subset of the problems Neighbor Unreachability 662 Detection tackles). 664 The Neighbor Discovery protocol provides a multitude of improvements 665 over the IPv4 set of protocols: 667 Router Discovery is part of the base protocol set; there is no need 668 for hosts to "snoop" the routing protocols. 670 Router advertisements carry link-layer addresses; no additional 671 packet exchange is needed to resolve the router's link-layer 672 address. 674 Router advertisements carry prefixes for a link; there is no need 675 to have a separate mechanism to configure the "netmask". 677 Router advertisements enable Address Autoconfiguration. 679 Routers can advertise an MTU for hosts to use on the link, ensuring 680 that all nodes use the same MTU value on links lacking a well- 681 defined MTU. 683 Address resolution multicasts are "spread" over 4 billion (2^32) 684 multicast addresses greatly reducing address resolution related 685 interrupts on nodes other than the target. Moreover, non-IPv6 686 machines should not be interrupted at all. 688 Redirects contain the link-layer address of the new first hop; 689 separate address resolution is not needed upon receiving a 690 redirect. 692 Multiple prefixes can be associated with the same link. By 693 default, hosts learn all on-link prefixes from Router 694 Advertisements. However, routers may be configured to omit some or 695 all prefixes from Router Advertisements. In such cases hosts 696 assume that destinations are off-link and send traffic to routers. 697 A router can then issue redirects as appropriate. 699 Unlike IPv4, the recipient of an IPv6 redirect assumes that the new 700 next-hop is on-link. In IPv4, a host ignores redirects specifying 701 a next-hop that is not on-link according to the link's network 702 mask. The IPv6 redirect mechanism is analogous to the XRedirect 703 facility specified in [SH-MEDIA]. It is expected to be useful on 704 non-broadcast and shared media links in which it is undesirable or 705 not possible for nodes to know all prefixes for on-link 706 destinations. 708 Neighbor Unreachability Detection is part of the base significantly 709 improving the robustness of packet delivery in the presence of 710 failing routers, partially failing or partitioned links and nodes 711 that change their link-layer addresses. For instance, mobile nodes 712 can move off-link without losing any connectivity due to stale ARP 713 caches. 715 Unlike ARP, Neighbor Discovery detects half-link failures (using 716 Neighbor Unreachability Detection) and avoids sending traffic to 717 neighbors with which two-way connectivity is absent. 719 Unlike in IPv4 Router Discovery the Router Advertisement messages 720 do not contain a preference field. The preference field is not 721 needed to handle routers of different "stability"; the Neighbor 722 Unreachability Detection will detect dead routers and switch to a 723 working one. 725 The use of link-local addresses to uniquely identify routers (for 726 Router Advertisement and Redirect messages) makes it possible for 727 hosts to maintain the router associations in the event of the site 728 renumbering to use new global prefixes. 730 Using the Hop Limit equal to 255 trick Neighbor Discovery is immune 731 to off-link senders that accidentally or intentionally send ND 732 messages. In IPv4 off-link senders can send both ICMP Redirects 733 and Router Advertisement messages. 735 Placing address resolution at the ICMP layer makes the protocol 736 more media-independent than ARP and makes it possible to use 737 standard IP authentication and security mechanisms as appropriate 738 [IPv6-AUTH, IPv6-ESP]. 740 3.2. Supported Link Types 742 Neighbor Discovery supports links with different properties. In the 743 presence of certain properties only a subset of the ND protocol is 744 available: 746 point-to-point - Neighbor Discovery handles such links just like 747 multicast links. (Multicast can be trivially 748 provided on point to point links, and interfaces can 749 be assigned link-local addresses.) 751 multicast - All aspects of Neighbor Discovery are available. 753 non-broadcast multiple access (NBMA) 754 - The only Neighbor Discovery mechanisms available on 755 these links are Redirect handling and Neighbor 756 Unreachability Detection. 758 If hosts support manual configuration of a list of 759 default routers, the hosts can dynamically acquire 760 the link-layer addresses for their neighbors from 761 Redirect messages. 763 shared media - The Redirect message is modeled after the XRedirect 764 message in [SH-MEDIA] in order to simplify use of 765 the protocol on shared media links. 767 This specification does not address shared media 768 issues that only relate to routers, such as: 770 - How routers exchange reachability information on 771 a shared media link. 773 - How a router determines the link-layer address of 774 a host, which it needs to send redirect messages 775 to the host. 777 - How a router determines that it is the first-hop 778 router for a received packet. 780 The protocol is extensible (through the definition 781 of new options) so that other solutions might be 782 possible in the future. 784 variable MTU - Neighbor Discovery allows routers to specify a MTU 785 for the link, which all nodes then use. All nodes 786 on a link must use the same MTU (or Maximum Receive 787 Unit) in order for multicast to work properly. 788 Otherwise when multicasting a sender, which can not 789 know which nodes will receive the packet, could not 790 determine a minimum packet size all receivers can 791 process. 793 asymmetric reachability 794 - Neighbor Discovery detects the absence of symmetric 795 reachability; a node avoids paths to a neighbor with 796 which it does not have symmetric connectivity. 798 The Neighbor Unreachability Detection will typically 799 identify such half-links and the node will refrain 800 from using them. 802 The protocol can presumably be extended in the 803 future to find viable paths in environments that 804 lack reflexive and transitive connectivity. 806 4. MESSAGE FORMATS 808 4.1. Router Solicitation Message Format 810 Hosts send Router Solicitations in order to prompt routers to generate 811 Router Advertisements quickly. 813 0 1 2 3 814 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 815 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 816 | Type | Code | Checksum | 817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 818 | Reserved | 819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 820 | Options ... 821 +-+-+-+-+-+-+-+-+-+-+-+- 823 IP Fields: 825 Source Address 826 An IP address assigned to the sending interface, or 827 the unspecified address if no address is assigned to 828 the sending interface. 830 Destination Address 831 Typically the all-routers multicast address. 833 Hop Limit 255 835 Priority 15 837 Authentication Header 838 If a Security Association for the IP Authentication 839 Header exists between the sender and the destination 840 address, then the sender SHOULD include this header. 842 ICMP Fields: 844 Type 133 846 Code 0 848 Checksum The ICMP checksum. See [ICMPv6]. 850 Reserved This field is unused. It MUST be initialized to zero 851 by the sender and MUST be ignored by the receiver. 853 Valid Options: 855 Source link-layer address 856 The link-layer address of the sender, if known. 858 Future versions of this protocol may define new option types. 859 Receivers MUST silently ignore any options they do not recognize and 860 continue processing the message. 862 4.2. Router Advertisement Message Format 864 Routers send out Router Advertisement message periodically, or in 865 response to a Router Solicitation. 867 0 1 2 3 868 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 869 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 870 | Type | Code | Checksum | 871 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 872 | Cur Hop Limit |M|O| Reserved | Router Lifetime | 873 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 874 | Reachable Time | 875 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 876 | Retrans Timer | 877 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 878 | Options ... 879 +-+-+-+-+-+-+-+-+-+-+-+- 881 IP Fields: 883 Source Address 884 MUST be the link-local address assigned to the 885 interface from which this message is sent. 887 Destination Address 888 Typically the Source Address of an invoking Router 889 Solicitation or the all-nodes multicast address. 891 Hop Limit 255 893 Priority 15 895 Authentication Header 896 If a Security Association for the IP Authentication 897 Header exists between the sender and the destination 898 address, then the sender SHOULD include this header. 900 ICMP Fields: 902 Type 134 904 Code 0 906 Checksum The ICMP checksum. See [ICMPv6]. 908 Cur Hop Limit 8-bit unsigned integer. The default value that should 909 be placed in the Hop Count field of the IP header for 910 outgoing IP packets. A value of zero means 911 unspecified (by this router). 913 M 1-bit "Managed address configuration" flag. When set, 914 hosts use the administered (stateful) protocol for 915 address autoconfiguration in addition to any addresses 916 autoconfigured using stateless address 917 autoconfiguration. The use of this flag is described 918 in [ADDRCONF]. 920 O 1-bit "Other stateful configuration" flag. When set, 921 hosts use the administered (stateful) protocol for 922 autoconfiguration of other (non-address) information. 923 The use of this flag is described in [ADDRCONF]. 925 Reserved A 6-bit unused field. It MUST be initialized to zero 926 by the sender and MUST be ignored by the receiver. 928 Router Lifetime 929 16-bit unsigned integer. The lifetime associated with 930 the default router in units of seconds. The maximum 931 value corresponds to 18.2 hours. A Lifetime of 0 932 indicates that the router is not a default router and 933 SHOULD NOT appear on the default router list. The 934 Router Lifetime applies only to the router's 935 usefulness as a default router; it does not apply to 936 information contained in other message fields or 937 options. Options that need time limits for their 938 information include their own lifetime fields. 940 Reachable Time 32-bit unsigned integer. The time, in milliseconds, 941 that a node assumes a neighbor is reachable after 942 having received a reachability confirmation. Used by 943 the Neighbor Unreachability Detection algorithm (see 944 Section 7.3). A value of zero means unspecified (by 945 this router). 947 Retrans Timer 32-bit unsigned integer. The time, in milliseconds, 948 between retransmitted Neighbor Solicitation messages. 949 Used by address resolution and the Neighbor 950 Unreachability Detection algorithm (see Sections 7.2 951 and 7.3). A value of zero means unspecified (by this 952 router). 954 Possible options: 956 Source link-layer address 957 The link-layer address of the interface from which the 958 Router Advertisement is sent. Only used on link 959 layers that have addresses. A router MAY omit this 960 option in order to enable inbound load sharing across 961 multiple link-layer addresses. 963 MTU SHOULD be sent on links that have a variable MTU (as 964 specified in the document that describes how to run IP 965 over the particular link type). MAY be sent on other 966 links. 968 Prefix Information 969 These options specify the prefixes that are on-link 970 and/or are used for address autoconfiguration. A 971 router SHOULD include all its on-link prefixes (except 972 the link-local prefix) so that multihomed hosts have 973 complete prefix information about on-link destinations 974 for the links to which they attach. If complete 975 information is lacking, a multihomed host may not be 976 able to chose the correct outgoing interface when 977 sending traffic to its neighbors. 979 Future versions of this protocol may define new option types. 980 Receivers MUST silently ignore any options they do not recognize and 981 continue processing the message. 983 4.3. Neighbor Solicitation Message Format 985 Nodes send Neighbor Solicitations to request the link-layer address of a 986 target node while also providing their own link-layer address to the 987 target. Neighbor Solicitations are multicast when the node needs to 988 resolve an address and unicast when the node seeks to verify the 989 reachability of a neighbor. 991 0 1 2 3 992 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 993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 994 | Type | Code | Checksum | 995 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 996 | Reserved | 997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 998 | | 999 + + 1000 | | 1001 + Target Address + 1002 | | 1003 + + 1004 | | 1005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1006 | Options ... 1007 +-+-+-+-+-+-+-+-+-+-+-+- 1009 IP Fields: 1011 Source Address 1012 Either an address assigned to the interface from which 1013 this message is sent or (if Duplicate Address 1014 Detection is in progress [ADDRCONF]) the unspecified 1015 address. 1017 Destination Address 1018 Either the solicited-node multicast address 1019 corresponding to the target address, or the target 1020 address. 1022 Hop Limit 255 1024 Priority 15 1026 Authentication Header 1027 If a Security Association for the IP Authentication 1028 Header exists between the sender and the destination 1029 address, then the sender SHOULD include this header. 1031 ICMP Fields: 1033 Type 135 1035 Code 0 1037 Checksum The ICMP checksum. See [ICMPv6]. 1039 Reserved This field is unused. It MUST be initialized to zero 1040 by the sender and MUST be ignored by the receiver. 1042 Target Address 1043 The IP address of the target of the solicitation. It 1044 MUST NOT be a multicast address. 1046 Possible options: 1048 Source link-layer address 1049 The link-layer address for the sender. On link layers 1050 that have addresses this option MUST be included in 1051 multicast solicitations and SHOULD be included in 1052 unicast solicitations. 1054 Future versions of this protocol may define new option types. 1055 Receivers MUST silently ignore any options they do not recognize and 1056 continue processing the message. 1058 4.4. Neighbor Advertisement Message Format 1060 A node sends Neighbor Advertisements in response to Neighbor 1061 Solicitations and sends unsolicited Neighbor Advertisements in order to 1062 (unreliably) propagate new information quickly. 1064 0 1 2 3 1065 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 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | Type | Code | Checksum | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 |R|S|O| Reserved | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | | 1072 + + 1073 | | 1074 + Target Address + 1075 | | 1076 + + 1077 | | 1078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 | Options ... 1080 +-+-+-+-+-+-+-+-+-+-+-+- 1082 IP Fields: 1084 Source Address 1085 An address assigned to the interface from which the 1086 advertisement is sent. 1088 Destination Address 1089 For solicited advertisements, the Source Address of an 1090 invoking Neighbor Solicitation or, if the 1091 solicitation's Source Address is the unspecified 1092 address, the all-nodes multicast address. 1094 For unsolicited advertisements typically the all-nodes 1095 multicast address. 1097 Hop Limit 255 1099 Priority 15 1101 Authentication Header 1102 If a Security Association for the IP Authentication 1103 Header exists between the sender and the destination 1104 address, then the sender SHOULD include this header. 1106 ICMP Fields: 1108 Type 136 1110 Code 0 1112 Checksum The ICMP checksum. See [ICMPv6]. 1114 R Router flag. When set, the R-bit indicates that the 1115 sender is a router. The R-bit is used by Neighbor 1116 Unreachability Detection to detect a router that 1117 changes to a host. 1119 S Solicited flag. When set, the S-bit indicates that 1120 the advertisement was sent in response to a Neighbor 1121 Solicitation from the Destination address. The S-bit 1122 is used as a reachability confirmation for Neighbor 1123 Unreachability Detection. It MUST NOT be set in 1124 multicast advertisements or in unsolicited unicast 1125 advertisements. 1127 O Override flag. When set, the O-bit indicates that the 1128 advertisement should override an existing cache entry 1129 and update the cached link-layer address. When it is 1130 not set the advertisement will not update a cached 1131 link-layer address though it will update an existing 1132 Neighbor Cache entry for which no link-layer address 1133 is known. It SHOULD NOT be set in solicited 1134 advertisements for anycast addresses and in solicited 1135 proxy advertisements. It SHOULD be set in other 1136 solicited advertisements and in unsolicited 1137 advertisements. 1139 Reserved 29-bit unused field. It MUST be initialized to zero 1140 by the sender and MUST be ignored by the receiver. 1142 Target Address 1143 For solicited advertisements, the Target Address field 1144 in the Neighbor Solicitation message that prompted 1145 this advertisement. For an unsolicited advertisement, 1146 the address whose link-layer address has changed. The 1147 Target Address MUST NOT be a multicast address. 1149 Possible options: 1151 Target link-layer address 1152 The link-layer address for the target, i.e., the 1153 sender of the advertisement. MUST be included on link 1154 layers that have addresses. 1156 Future versions of this protocol may define new option types. 1157 Receivers MUST silently ignore any options they do not recognize and 1158 continue processing the message. 1160 4.5. Redirect Message Format 1162 Routers send Redirect packets to inform a host of a better first-hop 1163 node on the path to a destination. Hosts can be redirected to a better 1164 first-hop router but can also be informed by a redirect that the 1165 destination is in fact a neighbor. The latter is accomplished by 1166 setting the ICMP Target Address equal to the ICMP Destination Address. 1168 0 1 2 3 1169 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 1170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1171 | Type | Code | Checksum | 1172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1173 | Reserved | 1174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1175 | | 1176 + + 1177 | | 1178 + Target Address + 1179 | | 1180 + + 1181 | | 1182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1183 | | 1184 + + 1185 | | 1186 + Destination Address + 1187 | | 1188 + + 1189 | | 1190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1191 | Options ... 1192 +-+-+-+-+-+-+-+-+-+-+-+- 1194 IP Fields: 1196 Source Address 1197 MUST be the link-local address assigned to the 1198 interface from which this message is sent. 1200 Destination Address 1201 The Source Address of the packet that triggered the 1202 redirect. 1204 Hop Limit 255 1206 Priority 15 1208 Authentication Header 1209 If a Security Association for the IP Authentication 1210 Header exists between the sender and the destination 1211 address, then the sender SHOULD include this header. 1213 ICMP Fields: 1215 Type 137 1216 Code 0 1218 Checksum The ICMP checksum. See [ICMPv6]. 1220 Reserved This field is unused. It MUST be initialized to zero 1221 by the sender and MUST be ignored by the receiver. 1223 Target Address An IP address that is a better first hop to use for 1224 the ICMP Destination Address. When the target is the 1225 actual endpoint of communication, i.e., the 1226 destination is a neighbor, the Target Address field 1227 MUST contain the same value as the ICMP Destination 1228 Address field. Otherwise the target is a better 1229 first-hop router and the Target Address MUST be the 1230 router's link-local address so that hosts can uniquely 1231 identify routers. 1233 Destination Address 1234 The IP address of the destination which is redirected 1235 to the target. 1237 Possible options: 1239 Target link-layer address 1240 The link-layer address for the target. It SHOULD be 1241 included (if known). Note that on NBMA links the 1242 sender of the invoking traffic can not use address 1243 resolution to determine the link-layer address of the 1244 target. Routers are advised not to send Redirect 1245 messages on such links unless they can supply the 1246 target link-layer address. 1248 Redirected Header 1249 As much as possible of the IP packet that triggered 1250 the sending of the Redirect without making the 1251 redirect packet exceed 576 octets. 1253 4.6. Option Formats 1255 Neighbor Discovery messages include zero or more options, some of which 1256 may appear multiple times in the same message. All options are of the 1257 form: 1259 0 1 2 3 1260 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 1261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1262 | Type | Length | ... | 1263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1264 ~ ... ~ 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1267 Fields: 1269 Type 8-bit identifier of the type of option. The options 1270 defined in this document are: 1272 Option Name Type 1274 Source Link-Layer Address 1 1275 Target Link-Layer Address 2 1276 Prefix Information 3 1277 Redirected Header 4 1278 MTU 5 1280 Length 8-bit unsigned integer. The length of the option in 1281 units of 8 octets. The value 0 is invalid. Nodes 1282 MUST silently discard an ND packet that contains an 1283 option with length zero. 1285 4.6.1. Source/Target Link-layer Address 1287 0 1 2 3 1288 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 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Type | Length | Link-Layer Address ... 1291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 Fields: 1295 Type 1296 1 for Source Link-layer Address 1297 2 for Target Link-layer Address 1299 Length The length of the option in units of 8 octets. For 1300 example, the length for IEEE 802 addresses is 1 1301 [IPv6-ETHER]. 1303 Link-Layer Address 1304 The variable length link-layer address. 1306 The content and format of this field (including byte 1307 and bit ordering) is expected to be specified in 1308 specific documents that describe how IPv6 operates 1309 over different link layers. For instance, [IPv6- 1310 ETHER]. 1312 Description 1313 The Source Link-Layer Address option contains the 1314 link-layer address of the sender of the packet. It is 1315 used in the Neighbor Solicitation, Router 1316 Solicitation, and Router Advertisement packets. 1318 The Target Link-Layer Address option contains the 1319 link-layer address of the target. It is used in 1320 Neighbor Advertisement and Redirect packets. 1322 These options MUST be silently ignored for other 1323 Neighbor Discovery messages. 1325 4.6.2. Prefix Information 1327 0 1 2 3 1328 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 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1330 | Type | Length | Prefix Length |L|A| Reserved1 | 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Valid Lifetime | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Preferred Lifetime | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Reserved2 | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | | 1339 + + 1340 | | 1341 + Prefix + 1342 | | 1343 + + 1344 | | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1347 Fields: 1349 Type 3 1350 Length 4 1352 Prefix Length 8-bit unsigned integer. The number of leading bits in 1353 the Prefix that are valid. The value ranges from 0 to 1354 128. 1356 L 1-bit on-link flag. When set, indicates that this 1357 prefix can be used for on-link determination. When 1358 not set the advertisement makes no statement about 1359 on-link or off-link properties of the prefix. For 1360 instance, the prefix might be used for address 1361 configuration with some of the addresses belonging to 1362 the prefix being on-link and others being off-link. 1364 A 1-bit autonomous address-configuration flag. When set 1365 indicates that this prefix can be used for autonomous 1366 address configuration as specified in [ADDRCONF]. 1368 Reserved1 6-bit unused field. It MUST be initialized to zero by 1369 the sender and MUST be ignored by the receiver. 1371 Valid Lifetime 1372 32-bit unsigned integer. The length of time in 1373 seconds (relative to the time the packet is sent) that 1374 the prefix is valid for the purpose of on-link 1375 determination. A value of all one bits (0xffffffff) 1376 represents infinity. The Valid Lifetime is also used 1377 by [ADDRCONF]. 1379 Preferred Lifetime 1380 32-bit unsigned integer. The length of time in 1381 seconds (relative to the time the packet is sent) that 1382 addresses generated from the prefix via stateless 1383 address autoconfiguration remain preferred [ADDRCONF]. 1384 A value of all one bits (0xffffffff) represents 1385 infinity. See [ADDRCONF]. 1387 Reserved2 This field is unused. It MUST be initialized to zero 1388 by the sender and MUST be ignored by the receiver. 1390 Prefix An IP address or a prefix of an IP address. The 1391 Prefix Length field contains the number of valid 1392 leading bits in the prefix. The bits in the prefix 1393 after the prefix length are reserved and MUST be 1394 initialized to zero by the sender and ignored by the 1395 receiver. A router SHOULD NOT send a prefix option 1396 for the link-local prefix and a host SHOULD ignore 1397 such a prefix option. 1399 Description 1400 The Prefix Information option provide hosts with on- 1401 link prefixes and prefixes for Address 1402 Autoconfiguration. 1404 The Prefix Information option appears in Router 1405 Advertisement packets and MUST be silently ignored for 1406 other messages. 1408 4.6.3. Redirected Header 1410 0 1 2 3 1411 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 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Type | Length | Reserved | 1414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1415 | Reserved | 1416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1417 | | 1418 ~ IP header + data ~ 1419 | | 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 Fields: 1424 Type 4 1426 Length The length of the option in units of 8 octets. 1428 Reserved These fields are unused. They MUST be initialized to 1429 zero by the sender and MUST be ignored by the 1430 receiver. 1432 IP header + data 1433 The original packet truncated to ensure that the size 1434 of the redirect message does not exceed 576 octets. 1436 Description 1437 The Redirected Header option is used in Redirect 1438 messages and contains all or part of the packet that 1439 is being redirected. 1441 This option MUST be silently ignored for other 1442 Neighbor Discovery messages. 1444 4.6.4. MTU 1446 0 1 2 3 1447 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 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1449 | Type | Length | Reserved | 1450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1451 | MTU | 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Fields: 1456 Type 5 1458 Length 1 1460 Reserved This field is unused. It MUST be initialized to zero 1461 by the sender and MUST be ignored by the receiver. 1463 MTU 32-bit unsigned integer. The recommended MTU for the 1464 link. 1466 Description 1467 The MTU option is used in Router Advertisement 1468 messages to insure that all nodes on a link use the 1469 same MTU value in those cases where the link MTU is 1470 not well known. 1472 This option MUST be silently ignored for other 1473 Neighbor Discovery messages. 1475 In configurations in which heterogeneous technologies 1476 are bridged together, the maximum supported MTU may 1477 differ from one segment to another. If the bridges do 1478 not generate ICMP Packet Too Big messages, 1479 communicating nodes will be unable to use Path MTU to 1480 dynamically determine the appropriate MTU on a per- 1481 neighbor basis. In such cases, routers use the MTU 1482 option to specify an MTU value supported by all 1483 segments. 1485 5. CONCEPTUAL MODEL OF A HOST 1487 This section describes a conceptual model of one possible data structure 1488 organization that hosts (and to some extent routers) will maintain in 1489 interacting with neighboring nodes. The described organization is 1490 provided to facilitate the explanation of how the Neighbor Discovery 1491 protocol should behave. This document does not mandate that 1492 implementations adhere to this model as long as their external behavior 1493 is consistent with that described in this document. 1495 This model is only concerned with the aspects of host behavior directly 1496 related to Neighbor Discovery. In particular, it does not concern 1497 itself with such issues as source address selection or the selecting of 1498 an outgoing interface on a multihomed host. 1500 5.1. Conceptual Data Structures 1502 Hosts will need to maintain the following pieces of information for each 1503 interface: 1505 Neighbor Cache 1506 - A set of entries about individual neighbors to which 1507 traffic has been sent recently. Entries are keyed on 1508 the neighbor's on-link unicast IP address and contain 1509 such information as its link-layer address, a flag 1510 indicating whether the neighbor is a router or a host 1511 (called IsRouter in this document), a pointer to any 1512 queued packets waiting for address resolution to 1513 complete, etc. 1515 A Neighbor Cache entry also contains information used 1516 by the Neighbor Unreachability Detection algorithm, 1517 including the reachability state, the number of 1518 unanswered probes, and the time the next Neighbor 1519 Unreachability Detection event is scheduled to take 1520 place. 1522 Destination Cache 1523 - A set of entries about destinations to which traffic 1524 has been sent recently. The Destination Cache 1525 includes both on-link and off-link destinations and 1526 provides a level of indirection into the Neighbor 1527 Cache; the Destination Cache maps a destination IP 1528 address to the IP address of the next-hop neighbor. 1529 This cache is updated with information learned from 1530 Redirect messages. Implementations may find it 1531 convenient to store additional information not 1532 directly related to Neighbor Discovery in Destination 1533 Cache entries, such as the Path MTU (PMTU) and round 1534 trip timers maintained by transport protocols. 1536 Prefix List - A list of the prefixes that define a set of addresses 1537 that are on-link. Prefix List entries are created 1538 from information received in Router Advertisements. 1539 Each entry has an associated invalidation timer value 1540 (extracted from the advertisement) used to expire 1541 prefixes when they become invalid. A special 1542 "infinity" timer value specifies that a prefix remains 1543 valid forever, unless a new (finite) value is received 1544 in a subsequent advertisement. 1546 The link-local prefix is considered to be on the 1547 prefix list with an infinite invalidation timer 1548 regardless of whether routers are advertising a prefix 1549 for it. Received Router Advertisements SHOULD NOT 1550 modify the invalidation timer for the link-local 1551 prefix. 1553 Default Router List 1554 - A list of routers to which packets may be sent. 1555 Router list entries point to entries in the Neighbor 1556 Cache; the algorithm for selecting a default router 1557 favors routers known to be reachable over those whose 1558 reachability is suspect. Each entry also has an 1559 associated invalidation timer value (extracted from 1560 Router Advertisements) used to delete entries that are 1561 no longer advertised. 1563 Note that the above conceptual data structures can be implemented using 1564 a variety of techniques. One possible implementation is to use a single 1565 longest-match routing table for all of the above data structures. 1566 Regardless of the specific implementation, it is critical that the 1567 Neighbor Cache entry for a router is shared by all Destination Cache 1568 entries using that router in order to prevent redundant Neighbor 1569 Unreachability Detection probes. 1571 Note also that other protocols (e.g. IPv6 Mobility) might add additional 1572 conceptual data structures. An implementation is at liberty to 1573 implement such data structures in any way it pleases. For example, an 1574 implementation could merge all conceptual data structures into a single 1575 routing table. 1577 The Neighbor Cache contains information maintained by the Neighbor 1578 Unreachability Detection algorithm. A key piece of information is a 1579 neighbor's reachability state, which is one of five possible values. 1581 The following definitions are informal; precise definitions can be found 1582 in Section 7.3.2. 1584 INCOMPLETE Address resolution is in progress and the link-layer 1585 address of the neighbor has not yet been determined. 1587 REACHABLE Roughly speaking, the neighbor is known to have been 1588 reachable recently (within tens of seconds ago). 1590 STALE The neighbor is no longer known to be reachable but until 1591 traffic is sent to the neighbor, no attempt should be 1592 made to verify its reachability. 1594 DELAY The neighbor is no longer known to be reachable, and 1595 traffic has recently be sent to the neighbor. Rather 1596 than probe the neighbor immediately, however, delay 1597 sending probes for a short while in order to give upper 1598 layer protocols a chance to provide reachability 1599 confirmation. 1601 PROBE The neighbor is no longer known to be reachable, and 1602 unicast Neighbor Solicitation probes are being sent to 1603 verify reachability. 1605 5.2. Conceptual Sending Algorithm 1607 When sending a packet to a destination, a node uses a combination of the 1608 Destination Cache, the Prefix List, and the Default Router List to 1609 determine the IP address of the appropriate next hop, an operation known 1610 as "next-hop determination". Once the IP address of the next hop is 1611 known, the Neighbor Cache is consulted for link-layer information about 1612 that neighbor. 1614 Next-hop determination for a given unicast destination operates as 1615 follows. The sender performs a longest prefix match against the Prefix 1616 List to determine whether the packet's destination is on- or off-link. 1617 If the destination is on-link, the next-hop address is the same as the 1618 packet's destination address. Otherwise, the sender selects a router 1619 from the Default Router List (following the rules described in Section 1620 6.3.6). If the Default Router List is empty, the sender assumes that 1621 the destination is on-link. 1623 For efficiency reasons, next-hop determination is not performed on every 1624 packet that is sent. Instead, the results of next-hop determination 1625 computations are saved in the Destination Cache (which also contains 1626 updates learned from Redirect messages). When the sending node has a 1627 packet to send, it first examines the Destination Cache. If no entry 1628 exists for the destination, next-hop determination is invoked to create 1629 a Destination Cache entry. 1631 Once the IP address of the next-hop node is known, the sender examines 1632 the Neighbor Cache for link-layer information about that neighbor. If 1633 no entry exists, the sender creates one, sets its state to INCOMPLETE, 1634 initiates Address Resolution, and then queues the data packet pending 1635 completion of address resolution. For multicast-capable interfaces 1636 Address Resolution consists of sending a Neighbor Solicitation message 1637 and waiting for a Neighbor Advertisement. When a Neighbor Advertisement 1638 response is received, the link-layer addresses is entered in the 1639 Neighbor Cache entry and the queued packet is transmitted. The address 1640 resolution mechanism is described in detail in Section 7.2. 1642 For multicast packets the next-hop is always the (multicast) destination 1643 address and is considered to be on-link. The procedure for determining 1644 the link-layer address corresponding to a given IP multicast address can 1645 be found in a separate document that covers operating IP over a 1646 particular link type (e.g., [IPv6-ETHER]). 1648 Each time a Neighbor Cache entry is accessed while transmitting a 1649 unicast packet, the sender checks Neighbor Unreachability Detection 1650 related information according to the Neighbor Unreachability Detection 1651 algorithm (Section 7.3). This unreachability check might result in the 1652 sender transmitting a unicast Neighbor Solicitation to verify that the 1653 neighbor is still reachable. 1655 Next-hop determination is done the first time traffic is sent to a 1656 destination. As long as subsequent communication to that destination 1657 proceeds successfully, the Destination Cache entry continues to be used. 1658 If at some point communication ceases to proceed, as determined by the 1659 Neighbor Unreachability Detection algorithm, next-hop determination may 1660 need to be performed again. For example, traffic through a failed 1661 router should be switched to a working router. Likewise, it may be 1662 possible to reroute traffic destined for a mobile node to a "mobility 1663 agent". 1665 Note that when a node redoes next-hop determination there is no need to 1666 discard the complete Destination Cache entry. In fact, it is generally 1667 beneficial to retain such cached information as the PMTU and round trip 1668 timer values that may also be kept in the Destination Cache entry. 1670 Routers and multihomed hosts have multiple interfaces. The remainder of 1671 this document assumes that all sent and received Neighbor Discovery 1672 messages refer to the interface of appropriate context. For example, 1673 when responding to a Router Solicitation, the corresponding Router 1674 Advertisement is sent out the interface on which the solicitation was 1675 received. 1677 5.3. Garbage Collection and Timeout Requirements 1679 The conceptual data structures described above use different mechanisms 1680 for discarding potentially stale or unused information. 1682 From the perspective of correctness there is no need to periodically 1683 purge Destination and Neighbor Cache entries. Although stale 1684 information can potentially remain in the cache indefinitely, the 1685 Neighbor Unreachability Detection algorithm ensures that stale 1686 information is purged quickly if it is actually being used. 1688 To limit the storage needed for the Destination and Neighbor Caches, a 1689 node may need to garbage-collect old entries. However, care must be 1690 taken to insure that sufficient space is always present to hold the 1691 working set of active entries. A small cache may result in an excessive 1692 number of Neighbor Discovery messages if entries are discarded and 1693 rebuilt in quick succession. Any LRU-based policy that only reclaims 1694 entries that have not been used in some time (e.g., ten minutes or more) 1695 should be adequate for garbage-collecting unused entries. 1697 A node should retain entries in the Default Router List and the Prefix 1698 List until their lifetimes expire. However, a node may garbage collect 1699 entries prematurely if it is low on memory. If not all routers are kept 1700 on the Default Router list, a node should retain at least two entries in 1701 the Default Router List (and preferably more) in order to maintain 1702 robust connectivity for off-link destinations. 1704 When removing an entry from the Prefix List there is no need to purge 1705 any entries from the Destination or Neighbor Caches. Neighbor 1706 Unreachability Detection will efficiently purge any entries in these 1707 caches that have become invalid. When removing an entry from the 1708 Default Router List, however, any entries in the Destination Cache that 1709 go through that router must perform next-hop determination again to 1710 select a new default router. 1712 6. ROUTER AND PREFIX DISCOVERY 1714 This section describes router and host behavior related to the Router 1715 Discovery portion of Neighbor Discovery. Router Discovery is used to 1716 locate neighboring routers as well as learn prefixes and configuration 1717 parameters related to address autoconfiguration. 1719 Prefix Discovery is the process through which hosts learn the ranges of 1720 IP addresses that reside on-link and can be reached directly without 1721 going through a router. Routers send Router Advertisements that 1722 indicate whether the sender is willing to be a default router. Router 1723 Advertisements also contain Prefix Information options that list the set 1724 of prefixes that identify on-link IP addresses. 1726 Stateless Address Autoconfiguration must also obtain subnet prefixes as 1727 part of configuring addresses. Although the prefixes used for address 1728 autoconfiguration are logically distinct from those used for on-link 1729 determination, autoconfiguration information is piggybacked on Router 1730 Discovery messages to reduce network traffic. Indeed, the same prefixes 1731 can be advertised for on-link determination and address 1732 autoconfiguration by specifying the appropriate flags in the Prefix 1733 Information options. See [ADDRCONF] for details on how 1734 autoconfiguration information is processed. 1736 6.1. Message Validation 1738 6.1.1. Validation of Router Solicitation Messages 1740 Hosts MUST silently discard any received Router Solicitation Messages. 1742 A router MUST silently discard any received Router Solicitation messages 1743 that do not satisfy all of the following validity checks: 1745 - The IP Hop Limit field has a value of 255, i.e., the packet could 1746 not possibly have been forwarded by a router. 1748 - If the message includes an IP Authentication Header, the message 1749 authenticates correctly. 1751 - ICMP Checksum is valid. 1753 - ICMP Code is 0. 1755 - ICMP length (derived from the IP length) is 8 or more octets. 1757 - All included options have a length that is greater than zero. 1759 The contents of the Reserved field, and of any unrecognized options, 1760 MUST be ignored. Future, backward-compatible changes to the protocol 1761 may specify the contents of the Reserved field or add new options; 1762 backward-incompatible changes may use different Code values. 1764 The contents of any defined options that are not specified to be used 1765 with Router Solicitation messages MUST be ignored and the packet 1766 processed as normal. The only defined option that may appear is the 1767 Source Link-Layer Address option. 1769 A solicitation that passes the validity checks is called a "valid 1770 solicitation". 1772 6.1.2. Validation of Router Advertisement Messages 1774 A node MUST silently discard any received Router Advertisement messages 1775 that do not satisfy all of the following validity checks: 1777 - IP Source Address is a link-local address. Routers must use their 1778 link-local address as the source for Router Advertisement and 1779 Redirect messages so that hosts can uniquely identify routers. 1781 - The IP Hop Limit field has a value of 255, i.e., the packet could 1782 not possibly have been forwarded by a router. 1784 - If the message includes an IP Authentication Header, the message 1785 authenticates correctly. 1787 - ICMP Checksum is valid. 1789 - ICMP Code is 0. 1791 - ICMP length (derived from the IP length) is 16 or more octets. 1793 - All included options have a length that is greater than zero. 1795 The contents of the Reserved field, and of any unrecognized options, 1796 MUST be ignored. Future, backward-compatible changes to the protocol 1797 may specify the contents of the Reserved field or add new options; 1798 backward-incompatible changes may use different Code values. 1800 The contents of any defined options that are not specified to be used 1801 with Router Advertisement messages MUST be ignored and the packet 1802 processed as normal. The only defined options that may appear are the 1803 Source Link-Layer Address, Prefix Information and MTU options. 1805 An advertisement that passes the validity checks is called a "valid 1806 advertisement". 1808 6.2. Router Specification 1809 6.2.1. Router Configuration Variables 1811 A router MUST allow for the following conceptual variables to be 1812 configured by system management. The specific variable names are used 1813 for demonstration purposes only, and an implementation is not required 1814 to have them, so long as its external behavior is consistent with that 1815 described in this document. Default values are specified to simplify 1816 configuration in common cases. 1818 The default values for some of the variables listed below may be 1819 overridden by specific documents that describe how IPv6 operates over 1820 different link layers. This rule simplifies the configuration of 1821 Neighbor Discovery over link types with widely differing performance 1822 characteristics. 1824 For each multicast interface: 1826 AdvSendAdvertisements 1827 A flag indicating whether or not the router sends 1828 periodic Router Advertisements and responds to 1829 Router Solicitations. 1831 Default: FALSE 1833 Note that AdvSendAdvertisements MUST be false by 1834 default so that a node will not accidentally start 1835 acting as a router unless it is explicitly 1836 configured by system management to send Router 1837 Advertisements. 1839 MaxRtrAdvInterval 1840 The maximum time allowed between sending unsolicited 1841 multicast Router Advertisements from the interface, 1842 in seconds. MUST be no less than 4 seconds and no 1843 greater than 1800 seconds. 1845 Default: 600 seconds 1847 MinRtrAdvInterval 1848 The minimum time allowed between sending unsolicited 1849 multicast Router Advertisements from the interface, 1850 in seconds. MUST be no less than 3 seconds and no 1851 greater than .75 * MaxRtrAdvInterval. 1853 Default: 0.33 * MaxRtrAdvInterval 1855 AdvManagedFlag 1856 The true/false value to be placed in the "Managed 1857 address configuration" flag field in the Router 1858 Advertisement. See [ADDRCONF]. 1860 Default: FALSE 1862 AdvOtherConfigFlag 1863 The true/false value to be placed in the "Other 1864 stateful configuration" flag field in the Router 1865 Advertisement. See [ADDRCONF]. 1867 Default: FALSE 1869 AdvLinkMTU The value to be placed in MTU options sent by the 1870 router. A value of zero indicates that no MTU 1871 options are sent. 1873 Default: 0 1875 AdvReachableTime 1876 The value to be placed in the Reachable Time field 1877 in the Router Advertisement messages sent by the 1878 router. The value zero means unspecified (by this 1879 router). MUST be no greater than 3,600,000 1880 milliseconds (1 hour). 1882 Default: 0 1884 AdvRetransTimer 1885 The value to be placed in the Retrans Timer field in 1886 the Router Advertisement messages sent by the 1887 router. The value zero means unspecified (by this 1888 router). 1890 Default: 0 1892 AdvCurHopLimit 1893 The default value to be placed in the Cur Hop Limit 1894 field in the Router Advertisement messages sent by 1895 the router. The value should be set to that current 1896 diameter of the Internet. The value zero means 1897 unspecified (by this router). 1899 Default: The value specified in the "Assigned 1900 Numbers" RFC [ASSIGNED] that was in effect at the 1901 time of implementation. 1903 AdvDefaultLifetime 1904 The value to be placed in the Router Lifetime field 1905 of Router Advertisements sent from the interface, in 1906 seconds. MUST be either zero or between 1907 MaxRtrAdvInterval and 9000 seconds. A value of zero 1908 indicates that the router is not to be used as a 1909 default router. 1911 Default: 3 * MaxRtrAdvInterval 1913 AdvPrefixList 1914 A list of prefixes to be placed in Prefix 1915 Information options in Router Advertisement messages 1916 sent from the interface. 1918 Default: all prefixes that the router advertises via 1919 routing protocols as being on-link for the interface 1920 from which the advertisement is sent. The link- 1921 local prefix SHOULD NOT be included in the list of 1922 advertised prefixes. 1924 Each prefix has an associated: 1926 AdvValidLifetime 1927 The value to be placed in the Valid Lifetime 1928 in the Prefix Information option, in 1929 seconds. The designated value of all 1's 1930 (0xffffffff) represents infinity. 1932 Default: infinity. 1934 AdvOnLinkFlag 1935 The value to be placed in the on-link flag 1936 ("L-bit") field in the Prefix Information 1937 option. 1939 Default: TRUE 1941 Automatic address configuration [ADDRCONF] defines 1942 additional information associated with each the 1943 prefixes: 1945 AdvPreferredLifetime 1946 The value to be placed in the Preferred 1947 Lifetime in the Prefix Information option, 1948 in seconds. The designated value of all 1's 1949 (0xffffffff) represents infinity. See 1950 [ADDRCONF]. 1952 Default: 604800 seconds (7 days) 1954 AdvAutonomousFlag 1955 The value to be placed in the Autonomous 1956 Flag field in the Prefix Information option. 1957 See [ADDRCONF]. 1959 Default: TRUE 1961 The above variables contain information that is placed in outgoing 1962 Router Advertisement messages. Hosts use the received information to 1963 initialize a set of analogous variables that control their external 1964 behavior (see Section 6.3.2). Some of these host variables (e.g., 1965 CurHopLimit, RetransTimer, and ReachableTime) apply to all nodes 1966 including routers. In practice, these variables may not actually be 1967 present on routers, since their contents can be derived from the 1968 variables described above. However, external router behavior MUST be 1969 the same as host behavior with respect to these variables. In 1970 particular, this includes the occasional randomization of the 1971 ReachableTime value as described in Section 6.3.2. 1973 Protocol constants are defined in Section 10. 1975 6.2.2. Becoming An Advertising Interface 1977 The term "advertising interface" refers to any functioning and enabled 1978 multicast interface that has at least one unicast IP address assigned to 1979 it and whose corresponding AdvSendAdvertisements flag is TRUE. A router 1980 MUST NOT send Router Advertisements out any interface that is not an 1981 advertising interface. 1983 An interface may become an advertising interface at times other than 1984 system startup. For example: 1986 - changing the AdvSendAdvertisements flag on an enabled interface 1987 from FALSE to TRUE, or 1989 - administratively enabling the interface, if it had been 1990 administratively disabled, and its AdvSendAdvertisements flag is 1991 TRUE, or 1993 - enabling IP forwarding capability (i.e., changing the system from 1994 being a host to being a router), when the interface's 1995 AdvSendAdvertisements flag is TRUE. 1997 A router MUST join the all-routers multicast address on an advertising 1998 interface. Routers respond to Router Solicitations sent to the all- 1999 routers address and verify the consistency of Router Advertisements sent 2000 by neighboring routers. 2002 6.2.3. Router Advertisement Message Content 2004 A router sends periodic as well as solicited Router Advertisements out 2005 its advertising interfaces. Outgoing Router Advertisements are filled 2006 with the following values consistent with the message format given in 2007 Section 4.2: 2009 - In the Router Lifetime field: the interface's configured 2010 AdvDefaultLifetime. 2012 - In the M and O flags: the interface's configured AdvManagedFlag and 2013 AdvOtherConfigFlag, respectively. See [ADDRCONF]. 2015 - In the Cur Hop Limit field: the interface's configured CurHopLimit. 2017 - In the Reachable Time field: the interface's configured 2018 AdvReachableTime. 2020 - In the Retrans Timer field: the interface's configured 2021 AdvRetransTimer. 2023 - In the options: 2025 o Source Link-Layer Address option: link-layer address of the 2026 sending interface. This option MAY be omitted to facilitate 2027 in-bound load balancing over replicated interfaces. 2029 o MTU option: the interface's configured AdvLinkMTU value if the 2030 value is non-zero. If AdvLinkMTU is zero the MTU option is 2031 not sent. 2033 o Prefix Information options: one Prefix Information option for 2034 each prefix listed in AdvPrefixList with the option fields set 2035 from the information in the AdvPrefixList entry as follows: 2037 - In the "on-link" flag: the entry's AdvOnLinkFlag. 2039 - In the Valid Lifetime field: the entry's 2040 AdvValidLifetime. 2042 - In the "Autonomous address configuration" flag: the 2043 entry's AdvAutonomousFlag. 2045 - In the Preferred Lifetime field: the entry's 2046 AdvPreferredLifetime. 2048 A router might want to send Router Advertisements without advertising 2049 itself as a default router. For instance, a router might advertise 2050 prefixes for address autoconfiguration while not wishing to forward 2051 packets. Such a router sets the Router Lifetime field in outgoing 2052 advertisements to zero. 2054 A router MAY choose not to include some or all options when sending 2055 unsolicited Router Advertisements. For example, if prefix lifetimes are 2056 much longer than AdvDefaultLifetime, including them every few 2057 advertisements may be sufficient. However, when responding to a Router 2058 Solicitation or while sending the first few initial unsolicited 2059 advertisements, a router SHOULD include all options so that all 2060 information (e.g., prefixes) is propagated quickly during system 2061 initialization. 2063 If including all options causes the size of an advertisement to exceed 2064 the link MTU, multiple advertisements can be sent, each containing a 2065 subset of the options. 2067 6.2.4. Sending Unsolicited Router Advertisements 2069 A host MUST NOT send Router Advertisement messages at any time. 2071 Unsolicited Router Advertisements are not strictly periodic: the 2072 interval between subsequent transmissions is randomized to reduce the 2073 probability of synchronization with the advertisements from other 2074 routers on the same link [SYNC]. Each advertising interface has its own 2075 timer. Whenever a multicast advertisement is sent from an interface, 2076 the timer is reset to a uniformly-distributed random value between the 2077 interface's configured MinRtrAdvInterval and MaxRtrAdvInterval; 2078 expiration of the timer causes the next advertisement to be sent and a 2079 new random value to be chosen. 2081 For the first few advertisements (up to MAX_INITIAL_RTR_ADVERTISEMENTS) 2082 sent from an interface when it becomes an advertising interface, if the 2083 randomly chosen interval is greater than 2084 MAX_INITIAL_RTR_ADVERT_INTERVAL, the timer SHOULD be set to 2085 MAX_INITIAL_RTR_ADVERT_INTERVAL instead. Using a smaller interval for 2086 the initial advertisements increases the likelihood of a router being 2087 discovered quickly when it first becomes available, in the presence of 2088 possible packet loss. 2090 The information contained in Router Advertisements may change through 2091 actions of system management. For instance, the lifetime of advertised 2092 prefixes may change, new prefixes could be added, a router could cease 2093 to be a router (i.e., switch from being a router to being a host), etc. 2094 In such cases, the router MAY transmit up to 2095 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the 2096 same rules as when an interface becomes an advertising interface. 2098 6.2.5. Ceasing To Be An Advertising Interface 2100 An interface may cease to be an advertising interface, through actions 2101 of system management such as: 2103 - changing the AdvSendAdvertisements flag of an enabled interface 2104 from TRUE to FALSE, or 2106 - administratively disabling the interface, or 2108 - shutting down the system. 2110 In such cases the router SHOULD transmit one or more (but not more than 2111 MAX_FINAL_RTR_ADVERTISEMENTS) final multicast Router Advertisements on 2112 the interface with a Router Lifetime field of zero. In the case of a 2113 router becoming a host, the system SHOULD also depart from the all- 2114 routers IP multicast group on all interfaces on which the router 2115 supports IP multicast (whether or not they had been advertising 2116 interfaces). In addition, the host MUST insure that subsequent Neighbor 2117 Advertisement messages sent from the interface have the Router flag set 2118 to zero. 2120 Note that system management may disable a router's IP forwarding 2121 capability (i.e., changing the system from being a router to being a 2122 host), a step that does not necessarily imply that the router's 2123 interfaces stop being advertising interfaces. In such cases, subsequent 2124 Router Advertisements MUST set the Router Lifetime field to zero. 2126 6.2.6. Processing Router Solicitations 2128 A host MUST silently discard any received Router Solicitation messages. 2130 In addition to sending periodic, unsolicited advertisements, a router 2131 sends advertisements in response to valid solicitations received on an 2132 advertising interface. A router MAY choose to unicast the response 2133 directly to the soliciting host's address (if the solicitation's source 2134 address is not the unspecified address), but the usual case is to 2135 multicast the response to the all-nodes group. In the latter case, the 2136 interface's interval timer is reset to a new random value, as if an 2137 unsolicited advertisement had just been sent (see Section 6.2.4). 2139 In all cases, Router Advertisements sent in response to a Router 2140 Solicitation MUST be delayed by a random time between 0 and 2141 MAX_RA_DELAY_TIME seconds. (If a single advertisement is sent in 2142 response to multiple solicitations, the delay is relative to the first 2143 solicitation.) In addition, consecutive Router Advertisements sent to 2144 the all-nodes multicast address MUST be rate limited to no more than one 2145 advertisement every MIN_DELAY_BETWEEN_RAS seconds. 2147 A router might process Router Solicitations as follows: 2149 - Upon receipt of a Router Solicitation, compute a random delay within 2150 the range 0 through MAX_RA_DELAY_TIME. If the computed value 2151 corresponds to a time later than the time the next multicast Router 2152 Advertisement is scheduled to be sent, ignore the random delay and 2153 send the advertisement at the already-scheduled time. 2155 - If the router sent a multicast Router Advertisement (solicited or 2156 unsolicited) within the last MIN_DELAY_BETWEEN_RAS seconds, schedule 2157 the advertisement to be sent at a time corresponding to 2158 MIN_DELAY_BETWEEN_RAS plus the random value after the previous 2159 advertisement was sent. This ensures that the multicast Router 2160 Advertisements are rate limited. 2162 - Otherwise, schedule the sending of a Router Advertisement at the time 2163 given by the random value. 2165 Note that a router is permitted to send multicast Router Advertisements 2166 more frequently than indicated by the MinRtrAdvInterval configuration 2167 variable so long as the more frequent advertisements are responses to 2168 Router Solicitations. In all cases, however, unsolicited multicast 2169 advertisements MUST NOT be sent more frequently than indicated by 2170 MinRtrAdvInterval. 2172 When a router receives a Router Solicitation and the Source Address is 2173 not the unspecified address, it records that the source of the packet is 2174 a neighbor by creating or updating the Neighbor Cache entry. If the 2175 solicitation contains a Source Link-Layer Address option, and the router 2176 has a Neighbor Cache entry for the neighbor, the link-layer address 2177 SHOULD be updated in the Neighbor Cache. If a Neighbor Cache entry is 2178 created for the source its reachability state MUST be set to STALE as 2179 specified in Section 7.3.3. If a cache entry already exists and is 2180 updated with a different link-layer address the reachability state MUST 2181 also be set to STALE. In either case the entry's IsRouter flag SHOULD 2182 be set to false. 2184 If the Source Address is the unspecified address the router MUST NOT 2185 create or update the Neighbor Cache entry. 2187 6.2.7. Router Advertisement Consistency 2189 Routers SHOULD inspect valid Router Advertisements sent by other routers 2190 and verify that the routers are advertising consistent information on a 2191 link. Detected inconsistencies indicate that one or more routers might 2192 be misconfigured and SHOULD be logged to system or network management. 2193 The minimum set of information to check includes: 2195 - Cur Hop Limit values (except for the unspecified value of zero). 2197 - Values of the M or O flags. 2199 - Reachable Time values (except for the unspecified value of zero). 2201 - Retrans Timer values (except for the unspecified value of zero). 2203 - Values in the MTU options. 2205 - Preferred and Valid Lifetimes for the same prefix. 2207 Note that it is not an error for different routers to advertise 2208 different sets of prefixes. Also, some routers might leave some fields 2209 as unspecified, i.e., with the value zero, while other routers specify 2210 values. The logging of errors SHOULD be restricted to conflicting 2211 information that causes hosts to switch from one value to another with 2212 each received advertisement. 2214 Any other action on reception of Router Advertisement messages by a 2215 router is beyond the scope of this document. 2217 6.2.8. Link-local Address Change 2219 The link-local address on a router SHOULD change rarely, if ever. Nodes 2220 receiving Neighbor Discovery messages use the source address to identify 2221 the sender. If multiple packets from the same router contain different 2222 source addresses, nodes will assume they come from different routers, 2223 leading to undesirable behavior. For example, a node will ignore 2224 Redirect messages that are believed to have been sent by a router other 2225 than the current first-hop router. Thus the source address used in 2226 Router Advertisements sent by a particular router must be identical to 2227 the target address in a Redirect message when redirecting to that 2228 router. 2230 Using the link-local address to uniquely identify routers on the link 2231 has the benefit that the address a router is known by should not change 2232 when a site renumbers. 2234 If a router changes the link-local address for one of its interfaces, it 2235 SHOULD inform hosts of this change. The router SHOULD multicast a few 2236 Router Advertisements from the old link-local address with the Router 2237 Lifetime field set to zero and also multicast a few Router 2238 Advertisements from the new link-local address. The overall effect 2239 should be the same as if one interface ceases being an advertising 2240 interface, and a different one starts being an advertising interface. 2242 6.3. Host Specification 2244 6.3.1. Host Configuration Variables 2246 None. 2248 6.3.2. Host Variables 2250 A host maintains certain Neighbor Discovery related variables in 2251 addition to the data structures defined in Section 5.1. The specific 2252 variable names are used for demonstration purposes only, and an 2253 implementation is not required to have them, so long as its external 2254 behavior is consistent with that described in this document. 2256 These variables have default values that are overridden by information 2257 received in Router Advertisement messages. The default values are used 2258 when there is no router on the link or when all received Router 2259 Advertisements have left a particular value unspecified. 2261 The default values in this specification may be overridden by specific 2262 documents that describe how IP operates over different link layers. 2263 This rule allows Neighbor Discovery to operate over links with widely 2264 varying performance characteristics. 2266 For each interface: 2268 LinkMTU The MTU of the link. 2270 Default: The valued defined in the specific document 2271 that describes how IPv6 operates over the particular 2272 link layer (e.g., [IPv6-ETHER]). 2274 CurHopLimit The default hop limit to be used when sending 2275 (unicast) IP packets. 2277 Default: The value specified in the "Assigned 2278 Numbers" RFC [ASSIGNED] that was in effect at the 2279 time of implementation. 2281 BaseReachableTime 2282 A base value used for computing the random 2283 ReachableTime value. 2285 Default: REACHABLE_TIME milliseconds. 2287 ReachableTime The time a neighbor is considered reachable after 2288 receiving a reachability confirmation. 2290 This value should be a uniformly-distributed random 2291 value between MIN_RANDOM_FACTOR and 2292 MAX_RANDOM_FACTOR times BaseReachableTime 2293 milliseconds. A new random value should be 2294 calculated when BaseReachableTime changes (due to 2295 Router Advertisements) or at least every few hours 2296 even if no Router Advertisements are received. 2298 RetransTimer The time between retransmissions of Neighbor 2299 Solicitation messages to a neighbor when resolving 2300 the address or when probing the reachability of a 2301 neighbor. 2303 Default: RETRANS_TIMER milliseconds 2305 6.3.3. Interface Initialization 2307 The host joins the all-nodes multicast address on all multicast-capable 2308 interfaces. 2310 6.3.4. Processing Received Router Advertisements 2312 When multiple routers are present, the information advertised 2313 collectively by all routers may be a superset of the information 2314 contained in a single Router Advertisement. Moreover, information may 2315 also be obtained through other dynamic means, such as stateful 2316 autoconfiguration. Hosts accept the union of all received information; 2317 the receipt of a Router Advertisement MUST NOT invalidate all 2318 information received in a previous advertisement or from another source. 2319 However, when received information for a specific parameter (e.g., Link 2320 MTU) or option (e.g., Lifetime on a specific Prefix) differs from 2321 information received earlier, and the parameter/option can only have one 2322 value, the most recently-received information is considered 2323 authoritative. 2325 Some Router Advertisement fields (e.g., Cur Hop Limit, Reachable Time 2326 and Retrans Timer) may contain a value denoting unspecified. In such 2327 cases, the parameter should be ignored and the host should continue 2328 using whatever value it is already using. In particular, a host MUST 2329 NOT interpret the unspecified value as meaning change back to the 2330 default value that was in use before the first Router Advertisement was 2331 received. This rule prevents hosts from continually changing an 2332 internal variable when one router advertises a specific value, but other 2333 routers advertise the unspecified value. 2335 On receipt of a valid Router Advertisement, a host extracts the source 2336 address of the packet and does the following: 2338 - If the address is not already present in the host's Default Router 2339 List, and the advertisement's Router Lifetime is non-zero, create a 2340 new entry in the list, and initialize its invalidation timer value 2341 from the advertisement's Router Lifetime field. 2343 - If the address is already present in the host's Default Router List 2344 as a result of a previously-received advertisement, reset its 2345 invalidation timer to the Router Lifetime value in the newly- 2346 received advertisement. 2348 - If the address is already present in the host's Default Router List 2349 and the received Router Lifetime value is zero, immediately time- 2350 out the entry as specified in Section 6.3.5. 2352 To limit the storage needed for the Default Router List, a host MAY 2353 choose not to store all of the router addresses discovered via 2354 advertisements. However, a host MUST retain at least two router 2355 addresses and SHOULD retain more. Default router selections are made 2356 whenever communication to a destination appears to be failing. Thus, 2357 the more routers on the list, the more likely an alternative working 2358 router can be found quickly (e.g., without having to wait for the next 2359 advertisement to arrive). 2361 If the received Cur Hop Limit value is non-zero the host SHOULD set its 2362 CurHopLimit variable to the received value. 2364 If the received Reachable Time value is non-zero the host SHOULD set its 2365 BaseReachableTime variable to the received value. If the new value 2366 differs from the previous value, the host SHOULD recompute a new random 2367 ReachableTime value. ReachableTime is computed as a uniformly- 2368 distributed random value between MIN_RANDOM_FACTOR and MAX_RANDOM_FACTOR 2369 times the BaseReachableTime. Using a random component eliminates the 2370 possibility Neighbor Unreachability Detection messages synchronize with 2371 each other. 2373 In most cases, the advertised Reachable Time value will be the same in 2374 consecutive Router Advertisements and a host's BaseReachableTime rarely 2375 changes. In such cases, an implementation SHOULD insure that a new 2376 random value gets recomputed at least once every few hours. 2378 The RetransTimer variable SHOULD be copied from the Retrans Timer field, 2379 if the received value is non-zero. 2381 After extracting information from the fixed part of the Router 2382 Advertisement message, the advertisement is scanned for valid options. 2383 If the advertisement contains a Source Link-Layer Address option the 2384 link-layer address SHOULD be recorded in the Neighbor Cache entry for 2385 the router (creating an entry if necessary) and the IsRouter flag in the 2386 Neighbor Cache entry MUST be set to true. The IsRouter flag is used by 2387 Neighbor Unreachability Detection to determine when a router changes to 2388 being a host (i.e., no longer capable of forwarding packets). If a 2389 Neighbor Cache entry is created for the router its reachability state 2390 MUST be set to STALE as specified in Section 7.3.3. If a cache entry 2391 already exists and is updated with a different link-layer address the 2392 reachability state MUST also be set to STALE. 2394 If the MTU option is present, hosts SHOULD copy the option's value into 2395 LinkMTU if the value does not exceed the default LinkMTU value specified 2396 in the link type specific document (e.g., [IPv6-ETHER]). 2398 Prefix Information options that have the "on-link" (L) flag set indicate 2399 a prefix identifying a range of addresses that should be considered on- 2400 link. Note, however, that a Prefix Information option with the on-link 2401 flag set to zero does not convey any meaning. In particular, such a 2402 prefix MUST NOT be considered to be off-link. Prefixes with the on-link 2403 flag set to zero would normally have the autonomous flag set and be used 2404 by [ADDRCONF]. 2406 For each Prefix Information option with the on-link flag set, a host 2407 does the following: 2409 - If the prefix is the link-local prefix, silently ignore the Prefix 2410 Information option. 2412 - If the prefix is not already present in the Prefix List, and the 2413 Prefix Information option's Valid Lifetime field is non-zero, 2414 create a new entry for the prefix and initialize its invalidation 2415 timer to the Valid Lifetime value in the Prefix Information option. 2417 - If the prefix is already present in the host's Prefix List as the 2418 result of a previously-received advertisement, reset its 2419 invalidation timer to the Valid Lifetime value in the Prefix 2420 Information option. If the new Lifetime value is zero, time-out 2421 the prefix immediately (see Section 6.3.5). 2423 - If the Prefix Information option's Valid Lifetime field is zero, 2424 and the prefix is not present in the host's Prefix List, silently 2425 ignore the option. 2427 Note: Implementations can choose to process the on-link aspects of 2428 the prefixes separately from the address autoconfiguration aspects of 2429 the prefixes by, e.g., passing a copy of each valid Router 2430 Advertisement message to both an "on-link" and an "addrconf" 2431 function. Each function can then operate independently on the 2432 prefixes that have the appropriate flag set. 2434 6.3.5. Timing out Prefixes and Default Routers 2436 Whenever the invalidation timer expires for a Prefix List entry, that 2437 entry is discarded. No existing Destination Cache entries need be 2438 updated, however. Should a reachability problem arise with an existing 2439 Neighbor Cache entry, Neighbor Unreachability Detection will perform any 2440 needed recovery. 2442 Whenever the Lifetime of an entry in the Default Router List expires, 2443 that entry is discarded. When removing a router from the Default Router 2444 list, the node MUST update the Destination Cache in such a way that all 2445 entries using the router perform next-hop determination again rather 2446 than continue sending traffic to the (deleted) router. 2448 6.3.6. Default Router Selection 2450 The algorithm for selecting a router depends in part on whether or not a 2451 router is known to be reachable. The exact details of how a node keeps 2452 track of a neighbor's reachability state are covered in Section 7.3. 2453 The algorithm for selecting a default router is invoked during next-hop 2454 determination when no Destination Cache entry exists for an off-link 2455 destination or when communication through an existing router appears to 2456 be failing. Under normal conditions, a router would be selected the 2457 first time traffic is sent to a destination, with subsequent traffic for 2458 that destination using the same router as indicated in the Destination 2459 Cache modulo any changes to the Destination Cache caused by Redirect 2460 messages. 2462 The policy for selecting routers from the Default Router List is as 2463 follows: 2465 1) Routers that are reachable or probably reachable (i.e., in any 2466 state other than INCOMPLETE) SHOULD be preferred over routers whose 2467 reachability is unknown or suspect (i.e., in the INCOMPLETE state, 2468 or for which no Neighbor Cache entry exists). An implementation 2469 may choose to always return the same router or cycle through the 2470 router list in a round-robin fashion as long as it always returns a 2471 reachable or a probably reachable router when one is available. 2473 2) When no routers on the list are known to be reachable or probably 2474 reachable, routers SHOULD be selected in a round-robin fashion, so 2475 that subsequent requests for a default router do not return the 2476 same router until all other routers have been selected. 2478 Cycling through the router list in this case ensures that all 2479 available routers are actively probed by the Neighbor 2480 Unreachability Detection algorithm. A request for a default router 2481 is made in conjunction with the sending of a packet to a router, 2482 and the selected router will be probed for reachability as a side 2483 effect. 2485 3) If the Default Router List is empty, assume that all destinations 2486 are on-link as specified in Section 5.2. 2488 6.3.7. Sending Router Solicitations 2490 When an interface becomes enabled, a host may be unwilling to wait for 2491 the next unsolicited Router Advertisement to locate default routers or 2492 learn prefixes. To obtain Router Advertisements quickly, a host SHOULD 2493 transmit up to MAX_RTR_SOLICITATIONS Router Solicitation messages each 2494 separated by at least RTR_SOLICITATION_INTERVAL seconds. Router 2495 Solicitations may be sent after any of the following events: 2497 - The interface is initialized at system startup time. 2499 - The interface is reinitialized after a temporary interface failure 2500 or after being temporarily disabled by system management. 2502 - The system changes from being a router to being a host, by having 2503 its IP forwarding capability turned off by system management. 2505 - The host attaches to a link for the first time. 2507 - The host re-attaches to a link after being detached for some time. 2509 A host sends Router Solicitations to the all-routers multicast address. 2510 The IP source address is set to either one of the interface's unicast 2511 addresses or the unspecified address. The Source Link-Layer Address 2512 option SHOULD be set to the host's link-layer address, if the IP source 2513 address is a unicast address. 2515 Before a host sends an initial solicitation, it SHOULD delay the 2516 transmission for a random amount of time between 0 and 2517 MAX_RTR_SOLICITATION_DELAY. This serves to alleviate congestion when 2518 many hosts start up on a link at the same time, such as might happen 2519 after recovery from a power failure. If a host has already performed a 2520 random delay since the interface became (re)enabled (e.g., as part of 2521 Duplicate Address Detection [ADDRCONF]) there is no need to delay again 2522 before sending the first Router Solicitation message. 2524 Once the host sends a Router Solicitation, and receives a valid Router 2525 Advertisement with a non-zero Router Lifetime, the host MUST desist from 2526 sending additional solicitations on that interface, until the next time 2527 one of the above events occurs. Moreover, a host SHOULD send at least 2528 one solicitation in the case where an advertisement is received prior to 2529 having sent a solicitation. Unsolicited Router Advertisements may be 2530 incomplete (see Section 6.2.3); solicited advertisements are expected to 2531 contain complete information. 2533 If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no 2534 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 2535 seconds after sending the last solicitation, the host concludes that 2536 there are no routers on the link for the purpose of [ADDRCONF]. 2537 However, the host continues to receive and process Router Advertisements 2538 messages in the event that routers appear on the link. 2540 7. ADDRESS RESOLUTION AND NEIGHBOR UNREACHABILITY DETECTION 2542 This section describes the functions related to Neighbor Solicitation 2543 and Neighbor Advertisement messages and includes descriptions of address 2544 resolution and the Neighbor Unreachability Detection algorithm. 2546 Neighbor Solicitation and Advertisement messages are also used for 2547 Duplicate Address Detection as specified by [ADDRCONF]. In particular, 2548 Duplicate Address Detection sends Neighbor Solicitation messages with an 2549 unspecified source address targeting its own "tentative" address. Such 2550 messages trigger nodes already using the address to respond with a 2551 multicast Neighbor Advertisement indicating that the address is in use. 2553 7.1. Message Validation 2554 7.1.1. Validation of Neighbor Solicitations 2556 A node MUST silently discard any received Neighbor Solicitation messages 2557 that do not satisfy all of the following validity checks: 2559 - The IP Hop Limit field has a value of 255, i.e., the packet could 2560 not possibly have been forwarded by a router. 2562 - If the message includes an IP Authentication Header, the message 2563 authenticates correctly. 2565 - ICMP Checksum is valid. 2567 - ICMP Code is 0. 2569 - ICMP length (derived from the IP length) is 24 or more octets. 2571 - Target Address is not a multicast address. 2573 - All included options have a length that is greater than zero. 2575 The contents of the Reserved field, and of any unrecognized options, 2576 MUST be ignored. Future, backward-compatible changes to the protocol 2577 may specify the contents of the Reserved field or add new options; 2578 backward-incompatible changes may use different Code values. 2580 The contents of any defined options that are not specified to be used 2581 with Neighbor Solicitation messages MUST be ignored and the packet 2582 processed as normal. The only defined option that may appear is the 2583 Source Link-Layer Address option. 2585 A Neighbor Solicitation that passes the validity checks is called a 2586 "valid solicitation". 2588 7.1.2. Validation of Neighbor Advertisements 2590 A node MUST silently discard any received Neighbor Advertisement 2591 messages that do not satisfy all of the following validity checks: 2593 - The IP Hop Limit field has a value of 255, i.e., the packet could 2594 not possibly have been forwarded by a router. 2596 - If the message includes an IP Authentication Header, the message 2597 authenticates correctly. 2599 - ICMP Checksum is valid. 2601 - ICMP Code is 0. 2603 - ICMP length (derived from the IP length) is 24 or more octets. 2605 - Target Address is not a multicast address. 2607 - If the IP Destination Address is a multicast address the Solicited 2608 flag is zero. 2610 - All included options have a length that is greater than zero. 2612 The contents of the Reserved field, and of any unrecognized options, 2613 MUST be ignored. Future, backward-compatible changes to the protocol 2614 may specify the contents of the Reserved field or add new options; 2615 backward-incompatible changes may use different Code values. 2617 The contents of any defined options that are not specified to be used 2618 with Neighbor Advertisement messages MUST be ignored and the packet 2619 processed as normal. The only defined option that may appear is the 2620 Target Link-Layer Address option. 2622 A Neighbor Advertisements that passes the validity checks is called a 2623 "valid advertisement". 2625 7.2. Address Resolution 2627 Address resolution is the process through which a node determines the 2628 link-layer address of a neighbor given only its IP address. Address 2629 resolution is performed only on addresses that are determined to be on- 2630 link and for which the sender does not know the corresponding link-layer 2631 address. Address resolution is never performed on multicast addresses. 2633 7.2.1. Interface Initialization 2635 When a multicast-capable interface becomes enabled the node MUST join 2636 the all-nodes multicast address on that interface, as well as the 2637 solicited-node multicast address corresponding to each of the IP 2638 addresses assigned to the interface. 2640 The set of addresses assigned to an interface may change over time. New 2641 addresses might be added and old addresses might be removed [ADDRCONF]. 2642 In such cases the node MUST join and leave the solicited-node multicast 2643 address corresponding to the new and old addresses, respectively. Note 2644 that multiple unicast addresses may map into the same solicited-node 2645 multicast address; a node MUST NOT leave the solicited-node multicast 2646 group until all assigned addresses corresponding to that multicast 2647 address have been removed. 2649 7.2.2. Sending Neighbor Solicitations 2651 When a node has a unicast packet to send to a neighbor, but does not 2652 know the neighbor's link-layer address, it performs address resolution. 2653 For multicast-capable interfaces this entails creating a Neighbor Cache 2654 entry in the INCOMPLETE state and transmitting a Neighbor Solicitation 2655 message targeted at the neighbor. The solicitation is sent to the 2656 solicited-node multicast address corresponding to the target address. 2658 If the source address of the packet prompting the solicitation is the 2659 same as one of the addresses assigned to the outgoing interface, that 2660 address SHOULD be placed in the IP Source Address of the outgoing 2661 solicitation. Otherwise, any one of the addresses assigned to the 2662 interface should be used. Using the prompting packet's source address 2663 when possible insures that the recipient of the Neighbor Solicitation 2664 installs in its Neighbor Cache the IP address that is highly likely to 2665 be used in subsequent return traffic belonging to the prompting packet's 2666 "connection". 2668 If the solicitation is being sent to a solicited-node multicast address, 2669 the sender MUST include its link-layer address (if it has one) as a 2670 Source Link-Layer Address option. Otherwise, the sender SHOULD include 2671 its link-layer address (if it has one) as a Source Link-Layer Address 2672 option. Including the source link-layer address in a multicast 2673 solicitation is required to give the target an address to which it can 2674 send the Neighbor Advertisement. 2676 While waiting for address resolution to complete, the sender MUST, for 2677 each neighbor, retain a small queue of packets waiting for address 2678 resolution to complete. The queue MUST hold at least one packet, and 2679 MAY contain more. However, the number of queued packets per neighbor 2680 SHOULD be limited to some small value. When a queue overflows, the new 2681 arrival SHOULD replace the oldest entry. Once address resolution 2682 completes, the node transmits any queued packets. 2684 While awaiting a response, the sender SHOULD retransmit Neighbor 2685 Solicitation messages approximately every RetransTimer milliseconds, 2686 even in the absence of additional traffic to the neighbor. 2687 Retransmissions MUST be rate-limited to at most one solicitation per 2688 neighbor every RetransTimer milliseconds. 2690 If no Neighbor Advertisement is received after MAX_MULTICAST_SOLICIT 2691 solicitations, address resolution has failed. The sender MUST return 2692 ICMP destination unreachable indications with code 3 (Address 2693 Unreachable) for each packet queued awaiting address resolution. 2695 7.2.3. Receipt of Neighbor Solicitations 2697 A valid Neighbor Solicitation where the Target Address is not a unicast 2698 or anycast address assigned to the receiving interface, and the Target 2699 Address is not a "tentative" address on which Duplicate Address 2700 Detection is being performed [ADDRCONF] MUST be silently ignored. If 2701 the Target Address is tentative, the Neighbor Solicitation should be 2702 processed as described in [ADDRCONF]. 2704 Upon receipt of a valid Neighbor Solicitation targeted at the node, the 2705 recipient SHOULD update the Neighbor Cache entry for the IP Source 2706 Address of the solicitation if the Source Address is not the unspecified 2707 address. If an entry does not already exist, the node SHOULD create a 2708 new one and set its reachability state to STALE as specified in 2709 Section 7.3.3. If a cache entry already exists and is updated with a 2710 different link-layer address its reachability state MUST be set to 2711 STALE. If the solicitation contains a Source Link-Layer Address option, 2712 the entry's cached link-layer address should be replaced with the one in 2713 the solicitation. 2715 If the Source Address is the unspecified address the node MUST NOT 2716 create or update the Neighbor Cache entry. 2718 After any updates to the Neighbor Cache, the node sends a Neighbor 2719 Advertisement response as described in the next section. 2721 7.2.4. Sending Solicited Neighbor Advertisements 2723 A node sends a Neighbor Advertisement in response to a valid Neighbor 2724 Solicitation targeting one of the node's assigned addresses. The Target 2725 Address of the advertisement is copied from the Target Address of the 2726 solicitation. If the solicitation's IP Destination Address is a unicast 2727 or anycast address, the Target Link-Layer Address option SHOULD NOT be 2728 included; the neighboring node's cached value must already be current in 2729 order for the solicitation to have been received. If the solicitation's 2730 IP Destination Address is a solicited-node multicast address, the Target 2731 Link-Layer option MUST be included in the advertisement. If the node is 2732 a router, it MUST set the Router flag to one; otherwise it MUST set the 2733 flag to zero. 2735 If the Target Address is either an anycast address or a unicast address 2736 for which the node is providing proxy service, or the Target Link-Layer 2737 Address option is not included in the outgoing advertisement, the 2738 Override flag SHOULD be set to zero. Otherwise, it SHOULD be set to 2739 one. Proper setting of the Override flag insures that nodes give 2740 preference to non-proxy advertisements, even when received after proxy 2741 advertisements, but that the first advertisement for an anycast address 2742 "wins". 2744 If the source of the solicitation is the unspecified address, the node 2745 MUST set the Solicited flag to zero and multicast the advertisement to 2746 the all-nodes address. Otherwise, the node MUST set the Solicited flag 2747 to one and unicast the advertisement to the Source Address of the 2748 solicitation. 2750 If the Target Address is an anycast address the sender SHOULD delay 2751 sending a response for a random time between 0 and 2752 MAX_ANYCAST_DELAY_TIME seconds. 2754 7.2.5. Receipt of Neighbor Advertisements 2756 When a valid Neighbor Advertisement is received (either solicited or 2757 unsolicited), the Neighbor Cache is searched for the target's entry. If 2758 no entry exists, the advertisement SHOULD be silently discarded. There 2759 is no need to create an entry in this case, since the recipient has 2760 apparently not initiated any communication with the target. 2762 Once the appropriate Neighbor Cache entry has been located, the specific 2763 actions taken depend on the state of the Neighbor Cache entry and the 2764 flags in the advertisement. If the entry is in an INCOMPLETE state 2765 (i.e., no link-layer address is cached for the target) the received 2766 advertisement updates the entry. If a cached link-layer address is 2767 already present, however, a node might choose to ignore the received 2768 advertisement and continue using the cached link-layer address. 2770 If the target's Neighbor Cache entry is in the INCOMPLETE state, the 2771 receiving node records the link-layer address in the Neighbor Cache 2772 entry and sends any packets queued for the neighbor awaiting address 2773 resolution. If the Solicited flag is set, the reachability state for 2774 the neighbor MUST be set to REACHABLE; otherwise it MUST be set to 2775 STALE. (A more detailed explanation of reachability state is described 2776 in Section 7.3.3). The Override flag is ignored if the entry is in the 2777 INCOMPLETE state. 2779 If the target's Neighbor Cache entry is in any state other than 2780 INCOMPLETE when the advertisement is received, the advertisement's 2781 Override flag's setting determines whether the Target Link-Layer Address 2782 option (if present) replaces the cached address. If the Override flag 2783 is set, the receiving node MUST install the link-layer address in its 2784 cache; if the flag is zero, the receiving node MUST NOT install the 2785 link-layer address in its cache. An advertisement's sender sets the 2786 Override flag when it wants its Target Link-Layer Address option to 2787 replace the cached value in Neighbor Cache entries, regardless of their 2788 current contents. 2790 If the target's Neighbor Cache entry is in any state other than 2791 INCOMPLETE when the advertisement is received, the advertisement's 2792 Solicited flag setting determines what the entry's new state should be. 2793 If the Solicited flag is set, the entry's state MUST be set to 2794 REACHABLE; if the flag is zero, the entry's state MUST be set to STALE. 2795 An advertisement's Solicited flag should only be set if the 2796 advertisement is a response to a Neighbor Solicitation. Because 2797 Neighbor Unreachability Solicitations are sent to the cached link-layer 2798 address, a receipt of a solicited advertisement indicates that the 2799 forward path is working. Receipt of an unsolicited advertisement, 2800 however, suggests that a neighbor has urgent information to announce 2801 (e.g., a changed link-layer address). Regardless of whether or not the 2802 new link-layer address is installed in the cache, a node should verify 2803 the reachability of the path it is currently using when it sends the 2804 next packet, so that it quickly finds a working path if the existing 2805 path has failed (e.g., as would be the case if the unsolicited Neighbor 2806 Advertisement is sent to announce a link-layer address change). 2808 In those cases where the cached link-layer address is updated, the 2809 receiving node MUST examine the Router flag in the received 2810 advertisement and update the IsRouter flag in the Neighbor Cache entry 2811 to reflect whether the node is a host or router. In those cases where 2812 the neighbor was previously used as a router, but the advertisement's 2813 Router flag is now set to zero, the node MUST remove that router from 2814 the Default Router List and update the Destination Cache entries for all 2815 destinations using that neighbor as a router as specified in 2816 Section 7.3.3. 2818 7.2.6. Sending Unsolicited Neighbor Advertisements 2820 In some cases a node may be able to determine that its link-layer 2821 address has changed (e.g., hot-swap of an interface card) and may wish 2822 to inform its neighbors of the new link-layer address quickly. In such 2823 cases a node MAY send up to MAX_NEIGHBOR_ADVERTISEMENT unsolicited 2824 Neighbor Advertisement messages to the all-nodes multicast address. 2825 These advertisements MUST be separated by at least RetransTimer seconds. 2827 The Target Address field in the unsolicited advertisement is set to an 2828 IP address of the interface, and the Target Link-Layer Address option is 2829 filled with the new link-layer address. The Solicited flag MUST be set 2830 to zero, in order to avoid confusing the Neighbor Unreachability 2831 Detection algorithm. If the node is a router, it MUST set the Router 2832 flag to one; otherwise it MUST set it to zero. The Override flag MAY be 2833 set to either zero or one. In either case, neighboring nodes will 2834 immediately change the state of their Neighbor Cache entries for the 2835 Target Address to STALE, prompting them to verify the path for 2836 reachability. If the Override flag is set to one, neighboring nodes 2837 will install the new link-layer address in their caches. Otherwise, 2838 they will ignore the new link-layer address, choosing instead to probe 2839 the cached address. 2841 A node that has multiple IP addresses assigned to an interface MAY 2842 multicast a separate Neighbor Advertisement for each address. In such a 2843 case the node SHOULD introduce a small delay between the sending of each 2844 advertisement to reduce the probability of the advertisements being lost 2845 due to congestion. 2847 A proxy MAY multicast Neighbor Advertisements when its link-layer 2848 address changes or when it is configured (by system management or other 2849 mechanisms) to proxy for an address. If there are multiple nodes that 2850 are providing proxy services for the same set of addresses the proxies 2851 SHOULD provide a mechanism that prevents multiple proxies from 2852 multicasting advertisements for any one address, in order to reduce the 2853 risk of excessive multicast traffic. 2855 Also, a node belonging to an anycast address MAY multicast unsolicited 2856 Neighbor Advertisements for the anycast address when the node's link- 2857 layer address changes. 2859 Note that because unsolicited Neighbor Advertisements do not reliably 2860 update caches in all nodes (the advertisements might not be received by 2861 all nodes), they should only be viewed as a performance optimization to 2862 quickly update the caches in most neighbors. The Neighbor 2863 Unreachability Detection algorithm ensures that all nodes obtain a 2864 reachable link-layer address, though the delay may be slightly longer. 2866 7.2.7. Anycast Neighbor Advertisements 2868 From the perspective of Neighbor Discovery, anycast addresses are 2869 treated just like unicast addresses in most cases. Because an anycast 2870 address is syntactically the same as a unicast address, nodes performing 2871 address resolution or Neighbor Unreachability Detection on an anycast 2872 address treat it as if it were a unicast address. No special processing 2873 takes place. 2875 Nodes that have an anycast address assigned to an interface treat them 2876 exactly the same as if they were unicast addresses with two exceptions. 2877 First, Neighbor Advertisements sent in response to a Neighbor 2878 Solicitation SHOULD be delayed by a random time between 0 and 2879 MAX_ANYCAST_DELAY_TIME to reduce the probability of network congestion. 2880 Second, the Override flag in Neighbor Advertisements SHOULD be set to 0, 2881 so that when multiple advertisements are received, the first received 2882 advertisement is used rather than the most recently received 2883 advertisement. 2885 As with unicast addresses, Neighbor Unreachability Detection ensures 2886 that a node quickly detects when the current binding for an anycast 2887 address becomes invalid. 2889 7.2.8. Proxy Neighbor Advertisements 2891 Under limited circumstances, a router MAY proxy for one or more other 2892 nodes, that is, through Neighbor Advertisements indicate that it is 2893 willing to accept packets not explicitly addressed to itself. For 2894 example, a router might accept packets on behalf of a mobile node that 2895 has moved off-link. The mechanisms used by proxy are identical to the 2896 mechanisms used with anycast addresses. 2898 A proxy MUST join the solicited-node multicast address(es) that 2899 correspond to the IP address(es) assigned to the node for which it is 2900 proxying. 2902 All solicited proxy Neighbor Advertisement messages MUST have the 2903 Override flag set to zero. This ensures that if the node itself is 2904 present on the link its Neighbor Advertisement (with the Override flag 2905 set to one) will take precedence of any advertisement received from a 2906 proxy. A proxy MAY send unsolicited advertisements with the Override 2907 flag set to one as specified in Section 7.2.6, but doing so may cause 2908 the proxy advertisement to override a valid entry created by the node 2909 itself. 2911 Finally, when sending a proxy advertisement in response to a Neighbor 2912 Solicitation, the sender should delay its response by a random time 2913 between 0 and MAX_ANYCAST_DELAY_TIME seconds. 2915 7.3. Neighbor Unreachability Detection 2917 Communication to or through a neighbor may fail for numerous reasons at 2918 any time, including hardware failure, hot-swap of an interface card, 2919 etc. If the destination has failed, no recovery is possible and 2920 communication fails. On the other hand, if it is the path that has 2921 failed, recovery may be possible. Thus, a node actively tracks the 2922 reachability "state" for the neighbors to which it is sending packets. 2924 Neighbor Unreachability Detection is used for all paths between hosts 2925 and neighboring nodes, including host-to-host, host-to-router, and 2926 router-to-host communication. Neighbor Unreachability Detection may 2927 also be used between routers, but is not required if an equivalent 2928 mechanism is available, for example, as part of the routing protocols. 2930 When a path to a neighbor appears to be failing, the specific recovery 2931 procedure depends on how the neighbor is being used. If the neighbor is 2932 the ultimate destination, for example, address resolution should be 2933 performed again. If the neighbor is a router, however, attempting to 2934 switch to another router would be appropriate. The specific recovery 2935 that takes place is covered under next-hop determination; Neighbor 2936 Unreachability Detection signals the need for next-hop determination by 2937 deleting a Neighbor Cache entry. 2939 Neighbor Unreachability Detection is performed only for neighbors to 2940 which unicast packets are sent; it is not used when sending to multicast 2941 addresses. 2943 7.3.1. Reachability Confirmation 2945 A neighbor is considered reachable if the node has recently received a 2946 confirmation that packets sent recently to the neighbor were received by 2947 its IP layer. Positive confirmation can be gathered in two ways: hints 2948 from upper layer protocols that indicate a connection is making "forward 2949 progress", or receipt of a Neighbor Advertisement message that is a 2950 response to a Neighbor Solicitation message. 2952 A connection makes "forward progress" if the packets received from a 2953 remote peer can only be arriving if recent packets sent to that peer are 2954 actually reaching it. In TCP, for example, receipt of a (new) 2955 acknowledgement indicates that previously sent data reached the peer. 2956 Likewise, the arrival of new (non-duplicate) data indicates that earlier 2957 acknowledgements are being delivered to the remote peer. If packets are 2958 reaching the peer, they must also be reaching the sender's next-hop 2959 neighbor; thus "forward progress" is a confirmation that the next-hop 2960 neighbor is reachable. For off-link destinations, forward progress 2961 implies that the first-hop router is reachable. When available, this 2962 upper-layer information SHOULD be used. 2964 In some cases (e.g., UDP-based protocols and routers forwarding packets 2965 to hosts) such reachability information may not be readily available 2966 from upper-layer protocols. When no hints are available and a node is 2967 sending packets to a neighbor, the node actively probes the neighbor 2968 using unicast Neighbor Solicitation messages to verify that the forward 2969 path is still working. 2971 The receipt of a solicited Neighbor Advertisement serves as reachability 2972 confirmation, since advertisements with the Solicited flag set to one 2973 are sent only in response to a Neighbor Solicitation. Receipt of other 2974 Neighbor Discovery messages such as Router Advertisements and Neighbor 2975 Advertisement with the Solicited flag set to zero MUST NOT be treated as 2976 a reachability confirmation. Receipt of unsolicited messages only 2977 confirm the one-way path from the sender to the recipient node. In 2978 contrast, Neighbor Unreachability Detection requires that a node keep 2979 track of the reachability of the forward path to a neighbor from the its 2980 perspective, not the neighbor's perspective. Note that receipt of a 2981 solicited advertisement indicates that a path is working in both 2982 directions. The solicitation must have reached the neighbor, prompting 2983 it to generate an advertisement. Likewise, receipt of an advertisement 2984 indicates that the path from the sender to the recipient is working. 2985 However, the latter fact is known only to the recipient; the 2986 advertisement's sender has no direct way of knowing that the 2987 advertisement it sent actually reached a neighbor. From the perspective 2988 of Neighbor Unreachability Detection, only the reachability of the 2989 forward path is of interest. 2991 7.3.2. Neighbor Cache Entry States 2993 A Neighbor Cache entry can be in one of five states: 2995 INCOMPLETE Address resolution is being performed on the entry. 2996 Specifically, a Neighbor Solicitation has been sent to 2997 the solicited-node multicast address of the target, but 2998 the corresponding Neighbor Advertisement has not yet been 2999 received. 3001 REACHABLE Positive confirmation was received within the last 3002 ReachableTime milliseconds that the forward path to the 3003 neighbor was functioning properly. While REACHABLE, no 3004 special action takes place as packets are sent. 3006 STALE More than ReachableTime milliseconds have elapsed since 3007 the last positive confirmation was received that the 3008 forward path was functioning properly. While stale, no 3009 action takes place until a packet is sent. 3011 The STALE state is entered upon receiving an unsolicited 3012 Neighbor Discovery message that updates the cached link- 3013 layer address. Receipt of such a message does not 3014 confirm reachability, and entering the STALE state 3015 insures reachability is verified quickly if the entry is 3016 actually being used. However, reachability is not 3017 actually verified until the entry is actually used. 3019 DELAY More than ReachableTime milliseconds have elapsed since 3020 the last positive confirmation was received that the 3021 forward path was functioning properly, and a packet was 3022 sent within the last DELAY_FIRST_PROBE_TIME seconds. If 3023 no reachability confirmation is received within 3024 DELAY_FIRST_PROBE_TIME seconds of entering the DELAY 3025 state, send a Neighbor Solicitation and change the state 3026 to PROBE. 3028 The DELAY state is an optimization that gives upper-layer 3029 protocols additional time to provide reachability 3030 confirmation in those cases where ReachableTime 3031 milliseconds have passed since the last confirmation due 3032 to lack of recent traffic. Without this optimization the 3033 opening of a TCP connection after a traffic lull would 3034 initiate probes even though the subsequent three-way 3035 handshake would provide a reachability confirmation 3036 almost immediately. 3038 PROBE A reachability confirmation is actively sought by 3039 retransmitting Neighbor Solicitations every RetransTimer 3040 milliseconds until a reachability confirmation is 3041 received. 3043 7.3.3. Node Behavior 3045 Neighbor Unreachability Detection operates in parallel with the sending 3046 of packets to a neighbor. While reasserting a neighbor's reachability, 3047 a node continues sending packets to that neighbor using the cached 3048 link-layer address. If no traffic is sent to a neighbor, no probes are 3049 sent. 3051 When a node needs to perform address resolution on a neighboring 3052 address, it creates an entry in the INCOMPLETE state and initiates 3053 address resolution as specified in Section 7.2. If address resolution 3054 fails, the entry SHOULD be deleted, so that subsequent traffic to that 3055 neighbor invokes the next-hop determination procedure again. Invoking 3056 next-hop determination at this point insures that alternate default 3057 routers are tried. 3059 When a reachability confirmation is received (either through upper-layer 3060 advice or a solicited Neighbor Advertisement) an entry's state changes 3061 to REACHABLE. The one exception is that upper-layer advice has no 3062 effect on entries in the INCOMPLETE state (e.g., for which no link-layer 3063 address is cached). 3065 When ReachableTime milliseconds have passed since receipt of the last 3066 reachability confirmation for a neighbor, the Neighbor Cache entry's 3067 state changes from REACHABLE to STALE. 3069 Note: An implementation may actually defer changing the state from 3070 REACHABLE to STALE until a packet is sent to the neighbor, i.e., 3071 there need not be an explicit timeout event associated with the 3072 expiration of ReachableTime. 3074 The first time a node sends a packet to a neighbor whose entry is STALE, 3075 the sender changes the state to DELAY and a sets a timer to expire in 3076 DELAY_FIRST_PROBE_TIME seconds. If the entry is still in the DELAY 3077 state when the timer expires, the entry's state changes to PROBE. If 3078 reachability confirmation is received, the entry's state changes to 3079 REACHABLE. 3081 Upon entering the PROBE state, a node sends a unicast Neighbor 3082 Solicitation message to the neighbor using the cached link-layer 3083 address. While in the PROBE state, a node retransmits Neighbor 3084 Solicitation messages every RetransTimer milliseconds until reachability 3085 confirmation is obtained. Probes are retransmitted even if no 3086 additional packets are sent to the neighbor. If no response is received 3087 after waiting RetransTimer milliseconds after sending the 3088 MAX_UNICAST_SOLICIT solicitations, retransmissions cease and the entry 3089 SHOULD be deleted. Subsequent traffic to that neighbor will recreate 3090 the entry and performs address resolution again. 3092 Note that all Neighbor Solicitations are rate-limited on a per-neighbor 3093 basis. A node MUST NOT send Neighbor Solicitations to the same neighbor 3094 more frequently than once every RetransTimer milliseconds. 3096 A Neighbor Cache entry enters the STALE state when created as a result 3097 of receiving packets other than solicited Neighbor Advertisements (i.e., 3098 Router Solicitations, Router Advertisements, Redirects, and Neighbor 3099 Solicitations). These packets contain the link-layer address of either 3100 the sender or, in the case of Redirect, the redirection target. 3101 However, receipt of these link-layer addresses does not confirm 3102 reachability of the forward-direction path to that node. Placing a 3103 newly created Neighbor Cache entry for which the link-layer address is 3104 known in the STALE state provides assurance that path failures are 3105 detected quickly. In addition, should a cached link-layer address be 3106 modified due to receiving one of the above messages the state SHOULD 3107 also be set to STALE to provide prompt verification that the patch to 3108 the new link-layer address is working. 3110 To properly detect the case where a router switches from being a router 3111 to being a host (e.g., if its IP forwarding capability is turned off by 3112 system management), a node MUST compare the Router flag field in all 3113 received Neighbor Advertisement messages with the IsRouter flag recorded 3114 in the Neighbor Cache entry. When a node detects that a neighbor has 3115 changed from being a router to being a host, the node MUST remove that 3116 router from the Default Router List and update the Destination Cache as 3117 described in Section 6.3.5. Note that a router may not be listed in the 3118 Default Router List, even though a Destination Cache entry is using it 3119 (e.g., a host was redirected to it). In such cases, all Destination 3120 Cache entries that reference the (former) router must perform next-hop 3121 determination again before using the entry. 3123 In some cases, link-specific information may indicate that a path to a 3124 neighbor has failed (e.g., the resetting of a virtual circuit). In such 3125 cases, link-specific information may be used to purge Neighbor Cache 3126 entries before the Neighbor Unreachability Detection would do so. 3127 However, link-specific information MUST NOT be used to confirm the 3128 reachability of a neighbor; such information does not provide end-to-end 3129 confirmation between neighboring IP layers. 3131 8. REDIRECT FUNCTION 3133 This section describes the functions related to the sending and 3134 processing of Redirect messages. 3136 Redirect messages are sent by routers to redirect a host to a better 3137 first-hop router for a specific destination or to inform hosts that a 3138 destination is in fact a neighbor (i.e., on-link). The latter is 3139 accomplished by having the ICMP Target Address be equal to the ICMP 3140 Destination Address. 3142 A router MUST be able to determine the link-local address for each of 3143 its neighboring routers in order to ensure that the target address in a 3144 Redirect message identifies the neighbor router by its link-local 3145 address. For static routing this requirement implies that the next-hop 3146 router's address should be specified using the link-local address of the 3147 router. For dynamic routing this requirement implies that all IPv6 3148 routing protocols must somehow exchange the link-local addresses of 3149 neighboring routers. 3151 8.1. Validation of Redirect Messages 3153 A host MUST silently discard any received Redirect message that does not 3154 satisfy all of the following validity checks: 3156 - IP Source Address is a link-local address. Routers must use their 3157 link-local address as the source for Router Advertisement and 3158 Redirect messages so that hosts can uniquely identify routers. 3160 - The IP Hop Limit field has a value of 255, i.e., the packet could 3161 not possibly have been forwarded by a router. 3163 - If the message includes an IP Authentication Header, the message 3164 authenticates correctly. 3166 - ICMP Checksum is valid. 3168 - ICMP Code is 0. 3170 - ICMP length (derived from the IP length) is 40 or more octets. 3172 - The IP source address of the Redirect is the same as the current 3173 first-hop router for the specified ICMP Destination Address. 3175 - The ICMP Destination Address field in the redirect message does not 3176 contain a multicast address. 3178 - The ICMP Target Address is either a link-local address (when 3179 redirected to a router) or the same as the ICMP Destination Address 3180 (when redirected to the on-link destination). 3182 - All included options have a length that is greater than zero. 3184 The contents of the Reserved field, and of any unrecognized options MUST 3185 be ignored. Future, backward-compatible changes to the protocol may 3186 specify the contents of the Reserved field or add new options; 3187 backward-incompatible changes may use different Code values. 3189 The contents of any defined options that are not specified to be used 3190 with Redirect messages MUST be ignored and the packet processed as 3191 normal. The only defined options that may appear are the Target Link- 3192 Layer Address option and the Redirected Header option. 3194 A host MUST NOT consider a redirect invalid just because the Target 3195 Address of the redirect is not covered under one of the link's prefixes. 3196 Part of the semantics of the Redirect message is that the Target Address 3197 is on-link. 3199 A redirect that passes the validity checks is called a "valid redirect". 3201 8.2. Router Specification 3203 A router SHOULD send a redirect message, subject to rate limiting, 3204 whenever it forwards a packet that is not explicitly addressed to itself 3205 (i.e. a packet that is not source routed through the router) in which: 3207 - the Source Address field of the packet identifies a neighbor, and 3209 - the router determines that a better first-hop node resides on the 3210 same link as the sending node for the Destination Address of the 3211 packet being forwarded, and 3213 - the Destination Address of the packet is not a multicast address, 3214 and 3216 The transmitted redirect packet contains, consistent with the message 3217 format given in Section 4.5: 3219 - In the Target Address field: the address to which subsequent 3220 packets for the destination SHOULD be sent. If the target is a 3221 router, that router's link-local address MUST be used. If the 3222 target is a host the target address field MUST be set to the same 3223 value as the Destination Address field. 3225 - In the Destination Address field: the destination address of the 3226 invoking IP packet. 3228 - In the options: 3230 o Target Link-Layer Address option: link-layer address of the 3231 target, if known. 3233 o Redirected Header: as much of the forwarded packet as can fit 3234 without the redirect packet exceeding 576 octets in size. 3236 A router MUST limit the rate at which Redirect messages are sent, in 3237 order to limit the bandwidth and processing costs incurred by the 3238 Redirect messages when the source does not correctly respond to the 3239 Redirects, or the source chooses to ignore unauthenticated Redirect 3240 messages. More details on the rate-limiting of ICMP error messages can 3241 be found in [ICMPv6]. 3243 A router MUST NOT update its routing tables upon receipt of a Redirect. 3245 8.3. Host Specification 3247 A host receiving a valid redirect SHOULD update its Destination Cache 3248 accordingly so that subsequent traffic goes to the specified target. If 3249 no Destination Cache entry exists for the destination, an implementation 3250 SHOULD create such an entry. 3252 If the redirect contains a Target Link-Layer Address option the host 3253 either creates or updates the Neighbor Cache entry for the target. In 3254 both cases the cached link-layer address is copied from the Target 3255 Link-Layer Address option. If a Neighbor Cache entry is created for the 3256 target its reachability state MUST be set to STALE as specified in 3257 Section 7.3.3. If a cache entry already existed and it is updated with 3258 a different link-layer address its reachability state MUST also be set 3259 to STALE. 3261 In addition, if the Target Address is the same as the Destination 3262 Address, the host MUST treat the destination as on-link and set the 3263 IsRouter field in the corresponding Neighbor Cache entry to FALSE. 3264 Otherwise it MUST set IsRouter to true. 3266 A host MAY have a configuration switch that can be set to make it ignore 3267 a Redirect message that does not have an IP Authentication header. 3269 A host MUST NOT send Redirect messages. 3271 9. EXTENSIBILITY - OPTION PROCESSING 3273 Options provide a mechanism for encoding variable length fields, fields 3274 that may appear multiple times in the same packet, or information that 3275 may not appear in all packets. Options can also be used to add 3276 additional functionality to future versions of ND. 3278 In order to ensure that future extensions properly coexist with current 3279 implementations, all nodes MUST silently ignore any options they do not 3280 recognize in received ND packets and continue processing the packet. 3281 All options specified in this document MUST be recognized. A node MUST 3282 NOT ignore valid options just because the ND message contains 3283 unrecognized ones. 3285 The current set of options is defined in such a way that receivers can 3286 process multiple options in the same packet independently of each other. 3287 In order to maintain these properties future options SHOULD follow the 3288 simple rule: 3290 The option MUST NOT depend on the presence or absence of any other 3291 options. The semantics of an option should depend only on the 3292 information in the fixed part of the ND packet and on the 3293 information contained in the option itself. 3295 Adhering to the above rule has the following benefits: 3297 1) Receivers can process options independently of one another. For 3298 example, an implementation can choose to process the Prefix 3299 Information option contained in a Router Advertisement message in a 3300 user-space process while the link-layer address option in the same 3301 message is processed by routines in the kernel. 3303 2) Should the number of options cause a packet to exceed a link's MTU, 3304 multiple packets can carry subsets of the options without any 3305 change in semantics. 3307 3) Senders MAY send a subset of options in different packets. For 3308 instance, if a prefix's Valid and Preferred Lifetime are high 3309 enough, it might not be necessary to include the Prefix Information 3310 option in every Router Advertisement. In addition, different 3311 routers might send different sets of options. Thus, a receiver 3312 MUST NOT associate any action with the absence of an option in a 3313 particular packet. This protocol specifies that receivers should 3314 only act on the expiration of timers and on the information that is 3315 received in the packets. 3317 Options in Neighbor Discovery packets can appear in any order; receivers 3318 MUST be prepared to process them independently of their order. There 3319 can also be multiple instances of the same option in a message (e.g., 3320 Prefix Information options). 3322 If the number of included options in a Router Advertisement causes the 3323 advertisement's size to exceed the link MTU, the router can send 3324 multiple separate advertisements each containing a subset of the 3325 options. 3327 The amount of data to include in the Redirected Header option MUST be 3328 limited so that the entire redirect packet does not exceed 576 octets. 3330 All options are a multiple of 8 octets of length, ensuring appropriate 3331 alignment without any "pad" options. The fields in the options (as well 3332 as the fields in ND packets) are defined to align on their natural 3333 boundaries (e.g., a 16-bit field is aligned on a 16-bit boundary) with 3334 the exception of the 128-bit IP addresses/prefixes, which are aligned on 3335 a 64-bit boundary. The link-layer address field contains an 3336 uninterpreted octet string; it is aligned on an 8-bit boundary. 3338 The size of an ND packet including the IP header is limited to the link 3339 MTU (which is at least 576 octets). When adding options to an ND packet 3340 a node MUST NOT exceed the link MTU. 3342 Future versions of this protocol may define new option types. Receivers 3343 MUST silently ignore any options they do not recognize and continue 3344 processing the message. 3346 10. PROTOCOL CONSTANTS 3348 Router constants: 3350 MAX_INITIAL_RTR_ADVERT_INTERVAL 16 seconds 3352 MAX_INITIAL_RTR_ADVERTISEMENTS 3 transmissions 3354 MAX_FINAL_RTR_ADVERTISEMENTS 3 transmissions 3356 MIN_DELAY_BETWEEN_RAS 3 seconds 3358 MAX_RA_DELAY_TIME .5 seconds 3360 Host constants: 3362 MAX_RTR_SOLICITATION_DELAY 1 second 3364 RTR_SOLICITATION_INTERVAL 4 seconds 3366 MAX_RTR_SOLICITATIONS 3 transmissions 3368 Node constants: 3370 MAX_MULTICAST_SOLICIT 3 transmissions 3372 MAX_UNICAST_SOLICIT 3 transmissions 3374 MAX_ANYCAST_DELAY_TIME 1 second 3376 MAX_NEIGHBOR_ADVERTISEMENT 3 transmissions 3378 REACHABLE_TIME 30,000 milliseconds 3380 RETRANS_TIMER 1,000 milliseconds 3382 DELAY_FIRST_PROBE_TIME 5 seconds 3384 MIN_RANDOM_FACTOR .5 3386 MAX_RANDOM_FACTOR 1.5 3388 Additional protocol constants are defined with the message formats in 3389 Section 4. 3391 All protocol constants are subject to change in future revisions of the 3392 protocol. 3394 The constants in this specification may be overridden by specific 3395 documents that describe how IPv6 operates over different link layers. 3396 This rule allows Neighbor Discovery to operate over links with widely 3397 varying performance characteristics. 3399 11. SECURITY CONSIDERATIONS 3401 Neighbor Discovery is subject to attacks that cause IP packets to flow 3402 to unexpected places. Such attacks can be used to cause denial of 3403 service but also allow nodes to intercept and optionally modify packets 3404 destined for other nodes. 3406 The protocol reduces the exposure to such threats in the absence of 3407 authentication by ignoring ND packets received from off-link senders. 3408 The Hop Limit field of all received packets is verified to contain 255, 3409 the maximum legal value. Because routers decrement the Hop Limit on all 3410 packets they forward, received packets containing a Hop Limit of 255 3411 must have originated from a neighbor. 3413 The trust model for redirects is the same as in IPv4. A redirect is 3414 accepted only if received from the same router that is currently being 3415 used for that destination. It is natural to trust the routers on the 3416 link. If a host has been redirected to another node (i.e., the 3417 destination is on-link) there is no way to prevent the target from 3418 issuing another redirect to some other destination. However, this 3419 exposure is no worse than it was; the target host, once subverted, could 3420 always act as a hidden router to forward traffic elsewhere. 3422 The protocol contains no mechanism to determine which neighbors are 3423 authorized to send a particular type of message e.g. Router 3424 Advertisements; any neighbor, presumably even in the presence of 3425 authentication, can send Router Advertisement messages thereby being 3426 able to cause denial of service. Furthermore, any neighbor can send 3427 proxy Neighbor Advertisements as well as unsolicited Neighbor 3428 Advertisements as a potential denial of service attack. 3430 Neighbor Discovery protocol packet exchanges can be authenticated using 3431 the IP Authentication Header [IPv6-AUTH]. A node SHOULD include an 3432 Authentication Header when sending Neighbor Discovery packets if a 3433 security association for use with the IP Authentication Header exists 3434 for the destination address. The security associations may have been 3435 created through manual configuration or through the operation of some 3436 key management protocol. 3438 Received Authentication Headers in Neighbor Discovery packets MUST be 3439 verified for correctness and packets with incorrect authentication MUST 3440 be ignored. 3442 It SHOULD be possible for the system administrator to configure a node 3443 to ignore any Neighbor Discovery messages that are not authenticated 3444 using either the Authentication Header or Encapsulating Security 3445 Payload. The configuration technique for this MUST be documented. Such 3446 a switch SHOULD default to allowing unauthenticated messages. 3448 Confidentiality issues are addressed by the IP Security Architecture and 3449 the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-ESP]. 3451 REFERENCES 3453 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 3454 Work in Progress. 3456 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 Addressing 3457 Architecture", RFC 1884, January, 1996. 3459 [ANYCST] C. Partridge, T. Mendez, and W. Milliken, "Host Anycasting 3460 Service", RFC 1546, November 1993. 3462 [ARP] D. Plummer, "An Ethernet Address Resolution Protocol", STD 37, 3463 RFC 826, November 1982. 3465 [HR-CL] R. Braden, Editor, "Requirements for Internet Hosts -- 3466 Communication Layers", STD 3, RFC 1122, October 1989. 3468 [ICMPv4] J. Postel, "Internet Control Message Protocol", STD 5, RFC 3469 792, September 1981. 3471 [ICMPv6] A. Conta, and S. Deering, "Internet Control Message Protocol 3472 (ICMPv6) for the Internet Protocol Version 6 (IPv6)", RFC 3473 1885, January 1996. 3475 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 6 3476 (IPv6) Specification", RFC 1883, January, 1996. 3478 [IPv6-ETHER] M. Crawford. "A Method for the Transmission of IPv6 3479 Packets over Ethernet Networks", Work in Progress. 3481 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 3482 Protocol". RFC 1825, August 1995. 3484 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 3485 August 1995. 3487 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 3488 RFC 1827, August 1995. 3490 [RDISC] S. Deering, "ICMP Router Discovery Messages", RFC 1256, 3491 September 1991. 3493 [SH-MEDIA] R. Braden, J. Postel, Y. Rekhter, "Internet Architecture 3494 Extensions for Shared Media", RFC 1620, May 1994. 3496 [ASSIGNED] J. Reynolds, J. Postel, "ASSIGNED NUMBERS", RFC 1700, 3497 October 1994. 3499 [SYNC] S. Floyd, V. Jacobsen, "The Synchronization of Periodic Routing 3500 Messages", IEEE/ACM Transactions on Networking, April 1994. 3501 ftp://ftp.ee.lbl.gov/papers/sync_94.ps.Z 3503 AUTHORS' ADDRESSES 3505 Erik Nordmark Thomas Narten 3506 Sun Microsystems, Inc. IBM Corporation 3507 2550 Garcia Ave P.O. Box 12195 3508 Mt. View, CA 94041 Research Triangle Park, NC 27709-2195 3509 USA USA 3511 phone: +1 415 786 5166 phone: +1 919 254 7798 3512 fax: +1 415 786 5896 fax: +1 919 254 4027 3513 email: nordmark@sun.com email: narten@vnet.ibm.com 3515 William Allen Simpson 3516 Daydreamer 3517 Computer Systems Consulting Services 3518 1384 Fontaine 3519 Madison Heights, Michigan 48071 3520 USA 3522 email: Bill.Simpson@um.cc.umich.edu 3523 bsimpson@MorningStar.com 3525 APPENDIX A: MULTIHOMED HOSTS 3527 There are a number of complicating issues that arise when Neighbor 3528 Discovery is used by hosts that have multiple interfaces. This section 3529 does not attempt to define the proper operation of multihomed hosts with 3530 regard to Neighbor Discovery. Rather, it identifies issues that require 3531 further study. Implementors are encouraged to experiment with various 3532 approaches to making Neighbor Discovery work on multihomed hosts and to 3533 report their experiences. 3535 If a multihomed host receives Router Advertisements on all of its 3536 interfaces, it will (probably) have learned on-link prefixes for the 3537 addresses residing on each link. When a packet must be sent through a 3538 router, however, selecting the "wrong" router can result in a suboptimal 3539 or non-functioning path. There are number of issues to consider: 3541 1) In order for a router to send a redirect, it must determine that 3542 the packet it is forwarding originates from a neighbor. The 3543 standard test for this case is to compare the source address of the 3544 packet to the list of on-link prefixes associated with the 3545 interface on which the packet was received. If the originating 3546 host is multihomed, however, the source address it uses may belong 3547 to an interface other than the interface from which it was sent. 3548 In such cases, a router will not send redirects, and suboptimal 3549 routing is likely. In order to be redirected, the sending host 3550 must always send packets out the interface corresponding to the 3551 outgoing packet's source address. Note that this issue never 3552 arises with non-multihomed hosts; they only have one interface. 3554 2) If the selected first-hop router does not have a route at all for 3555 the destination, it will be unable to deliver the packet. However, 3556 the destination may be reachable through a router on one of the 3557 other interfaces. Neighbor Discovery does not address this 3558 scenario; it does not arise in the non-multihomed case. 3560 3) Even if the first-hop router does have a route for a destination, 3561 there may be a better route via another interface. No mechanism 3562 exists for the multihomed host to detect this situation. 3564 If a multihomed host fails to receive Router Advertisements on one or 3565 more of its interfaces, it will not know (in the absence of configured 3566 information) which destinations are on-link on the affected 3567 interface(s). This leads to a number of problems: 3569 1) If no Router Advertisement is received on any interfaces, a 3570 multihomed host will have no way of knowing which interface to send 3571 packets out on, even for on-link destinations. Under similar 3572 conditions in the non-multihomed host case, a node treats all 3573 destinations as residing on-link, and communication proceeds. In 3574 the multihomed case, however, additional information is needed to 3575 select the proper outgoing interface. Alternatively, a node could 3576 attempt to perform address resolution on all interfaces, a step 3577 involving significant complexity that is not present in the non- 3578 multihomed host case. 3580 2) If Router Advertisements are received on some, but not all 3581 interfaces, a multihomed host could choose to only send packets out 3582 on the interfaces on which it has received Router Advertisements. 3583 A key assumption made here, however, is that routers on those other 3584 interfaces will be able to route packets to the ultimate 3585 destination, even when those destinations reside on the subnet to 3586 which the sender connects, but has no on-link prefix information. 3587 Should the assumption be false, communication would fail. Even if 3588 the assumption holds, packets will traverse a sub-optimal path. 3590 APPENDIX B: FUTURE EXTENSIONS 3592 Possible extensions for future study are: 3594 o Using dynamic timers to be able to adapt to links with widely varying 3595 delay. Measuring round trip times, however, requires acknowledgments 3596 and sequence numbers in order to match received Neighbor 3597 Advertisements with the actual Neighbor Solicitation that triggered 3598 the advertisement. Implementors wishing to experiment with such a 3599 facility could do so in a backwards-compatible way by defining a new 3600 option carrying the necessary information. Nodes not understanding 3601 the option would simply ignore it. 3603 o Adding capabilities to facilitate the operation over links that 3604 currently require hosts to register with an address resolution 3605 server. This could for instance enable routers to ask hosts to send 3606 them periodic unsolicited advertisements. Once again this can be 3607 added using a new option sent in the Router Advertisements. 3609 o Adding additional procedures for links where asymmetric and non- 3610 transitive reachability is part of normal operations. Such 3611 procedures might allow hosts and routers to find usable paths on, 3612 e.g., radio links. 3614 APPENDIX C: STATE MACHINE FOR THE REACHABILITY STATE 3616 This appendix contains a summary of the rules specified in Sections 7.2 3617 and 7.3. This document does not mandate that implementations adhere to 3618 this model as long as their external behavior is consistent with that 3619 described in this document. 3621 When performing address resolution and Neighbor Unreachability Detection 3622 the following state transitions apply using the conceptual model: 3624 State Event Action New state 3626 - Packet to send. Create entry. INCOMPLETE 3627 Send multicast NS. 3628 Start retransmit timer 3630 INCOMPLETE Retransmit timeout, Retransmit NS INCOMPLETE 3631 less than N Start retransmit timer 3632 retransmissions. 3634 INCOMPLETE Retransmit timeout, Discard entry - 3635 N or more Send ICMP error 3636 retransmissions. 3638 INCOMPLETE NA, Solicited=0, Record link-layer STALE 3639 Override=any address. Send queued 3640 packets. 3642 INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3643 Override=any address. Send queued 3644 packets. 3646 !INCOMPLETE NA, Solicited=1, - REACHABLE 3647 Override=0 3649 !INCOMPLETE NA, Solicited=1, Record link-layer REACHABLE 3650 Override=1 address. 3652 !INCOMPLETE NA, Solicited=0, - STALE 3653 Override=0 3655 !INCOMPLETE NA, Solicited=0, Record link-layer STALE 3656 Override=1 address. 3658 !INCOMPLETE upper-layer reachability - REACHABLE 3659 confirmation 3661 REACHABLE timeout, more than - STALE 3662 N seconds since 3663 reachability confirm. 3665 STALE Sending packet Start delay timer DELAY 3667 DELAY Delay timeout Send unicast NS probe PROBE 3668 Start retransmit timer 3670 PROBE Retransmit timeout, Retransmit NS PROBE 3671 less than N 3672 retransmissions. 3674 PROBE Retransmit timeout, Discard entry - 3675 N or more 3676 retransmissions. 3678 The state transitions for receiving unsolicited information other than 3679 Neighbor Advertisement messages apply to either the source of the packet 3680 (for Neighbor Solicitation, Router Solicitation, and Router 3681 Advertisement messages) or the target address (for Redirect messages) as 3682 follows: 3684 State Event Action New state 3686 - NS, RS, RA, Redirect Create entry. STALE 3688 INCOMPLETE NS, RS, RA, Redirect Record link-layer STALE 3689 address. Send queued 3690 packets. 3692 !INCOMPLETE NS, RS, RA, Redirect Update link-layer STALE 3693 Different link-layer address 3694 address than cached. 3696 !INCOMPLETE NS, RS, RA, Redirect - unchanged 3697 Same link-layer 3698 address as cached. 3700 APPENDIX D: IMPLEMENTATION ISSUES 3702 Appendix D.1: Reachability confirmations 3704 Neighbor Unreachability Detection requires explicit confirmation that a 3705 forward-path is functioning properly. To avoid the need for Neighbor 3706 Solicitation probe messages, upper layer protocols should provide such 3707 an indication when the cost of doing so is small. Reliable connection- 3708 oriented protocols such as TCP are generally aware when the forward-path 3709 is working. When TCP sends (or receives) data, for instance, it updates 3710 its window sequence numbers, sets and cancels retransmit timers, etc. 3711 Specific scenarios that usually indicate a properly functioning 3712 forward-path include: 3714 - Receipt of an acknowledgement that covers a sequence number (e.g., 3715 data) not previously acknowledged indicates that the forward path was 3716 working at the time the data was sent. 3718 - Completion of the initial three-way handshake is a special case of the 3719 previous rule; although no data is sent during the handshake, the SYN 3720 flags are counted as data from the sequence number perspective. This 3721 applies to both the SYN+ACK for the active open the ACK of that 3722 packet on the passively opening peer. 3724 - Receipt of new data (i.e., data not previously received) indicates 3725 that the forward-path was working at the time an acknowledgement was 3726 sent that advanced the peer's send window that allowed the new data 3727 to be sent. 3729 To minimize the cost of communicating reachability information between 3730 the TCP and IP layers, an implementation may wish to rate-limit the 3731 reachability confirmations its sends IP. One possibility is to process 3732 reachability only every few packets. For example, one might update 3733 reachability information once per round trip time, if an implementation 3734 only has one round trip timer per connection. For those implementations 3735 that cache Destination Cache entries within control blocks, it may be 3736 possible to update the Neighbor Cache entry directly (i.e., without an 3737 expensive lookup) once the TCP packet has been demultiplexed to its 3738 corresponding control block. For other implementation it may be 3739 possible to piggyback the reachability confirmation on the next packet 3740 submitted to IP assuming that the implementation guards against the 3741 piggybacked confirmation becoming stale when no packets are sent to IP 3742 for an extended period of time. 3744 TCP must also guard against thinking "stale" information indicates 3745 current reachability. For example, new data received 30 minutes after a 3746 window has opened up does not constitute a confirmation that the path is 3747 currently working. In merely indicates that 30 minutes ago the window 3748 update reached the peer i.e. the patch was working at that point in 3749 time. An implementation must also take into account TCP zero-window 3750 probes that are sent even if the path is broken and the window update 3751 did not reach the peer. 3753 For UDP based applications (RPC, DNS) it is relatively simple to make 3754 the client send reachability confirmations when the response packet is 3755 received. It is more difficult and in some cases impossible for the 3756 server to generate such confirmations since there is no flow control, 3757 i.e., the server can not determine whether a received request indicates 3758 that a previous response reached the client. 3760 Note that an implementation can not use negative upper-layer advise as a 3761 replacement for the Neighbor Unreachability Detection algorithm. 3762 Negative advise (e.g. from TCP when there are excessive retransmissions) 3763 could serve as a hint that the forward path from the sender of the data 3764 might not be working. But it would fail to detect when the path from 3765 the receiver of the data is not functioning causing, none of the 3766 acknowledgement packets to reach the sender.