idnits 2.17.1 draft-simpson-ipv6-discov-process-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-03-29) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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.) ** There are 240 instances of too long lines in the document, the longest one being 34 characters in excess of 72. ** 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 75: '..., every link address MUST be unique |...' RFC 2119 keyword, line 78: '...ame link address MAY be used by the sa...' RFC 2119 keyword, line 87: '... 893] MUST NOT be used....' RFC 2119 keyword, line 97: '...ch cases, a node MUST NOT allow a data...' RFC 2119 keyword, line 101: '...ogical interface MUST be configurable,...' (131 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 1995) is 10635 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'D-Sign' on line 55 looks like a reference -- Missing reference section? 'D-Form' on line 312 looks like a reference -- Missing reference section? 'RFC-826' on line 82 looks like a reference -- Missing reference section? 'RFC-893' on line 86 looks like a reference -- Missing reference section? 'RFC-1661' on line 1654 looks like a reference -- Missing reference section? '1' on line 1326 looks like a reference -- Missing reference section? 'Mobility' on line 1586 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group W A Simpson 2 Internet Draft Daydreamer 3 expires in six months February 1995 5 IPv6 Neighbor Discovery -- Processing 6 draft-simpson-ipv6-discov-process-02.txt | 8 Status of this Memo 10 This document is a submission to the IPng Working Group of the 11 Internet Engineering Task Force (IETF). Comments should be submitted 12 to the ipng@sunroof.eng.sun.com mailing list. 14 Distribution of this memo is unlimited. 16 This document is an Internet-Draft. Internet Drafts are working 17 documents of the Internet Engineering Task Force (IETF), its Areas, 18 and its Working Groups. Note that other groups may also distribute 19 working documents as Internet Drafts. 21 Internet Drafts are draft documents valid for a maximum of six 22 months, and may be updated, replaced, or obsoleted by other documents 23 at any time. It is not appropriate to use Internet Drafts as 24 reference material, or to cite them other than as a ``working draft'' 25 or ``work in progress.'' 27 To learn the current status of any Internet-Draft, please check the 28 ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow | 29 Directories on: | 31 ds.internic.net (US East Coast) 32 nic.nordu.net (Europe) 33 ftp.isi.edu (US West Coast) 34 munnari.oz.au (Pacific Rim) 36 Abstract 38 This document discusses the implementation techniques for 39 identification of and forwarding to adjacent IPv6 nodes, including 40 Next Hop Determination and Router Discovery. 42 1. Introduction 44 This document describes how to 46 - determine the availability of other IPv6 nodes as demand for 47 communication occurs; 49 - detect the presence of available IPv6 routers; 51 - learn the appropriate link address for sending to its neighbors; | 53 - and redirect traffic where appropriate. 55 The design requirements are more completely described in [D-Sign]. 56 The ICMP packet formats are described in [D-Form]. 58 This document contains only that information which is particularly 59 relevant to IPv6 Neighbor Discovery, or that differs from IPv4 60 techniques. Other IPv6 documents should be consulted for further 61 details. 63 2. Link-Layers 65 This document anticipates that link-layer material will be covered in 66 a separate Link Layer Requirements document. Specific link-layer 67 protocol implementation details are beyond the scope of this 68 document. 70 2.1. Addresses | 72 For multi-access links, every node requires a unique address on the | 73 link. | 75 When multi-homed hosts are present, every link address MUST be unique | 76 over all such attached links. | 78 The same link address MAY be used by the same node on multiple links. | 80 2.2. Address Resolution Protocol (ARP) 82 ARP [RFC-826] is no longer used for IPv6. 84 2.3. Trailers 86 Because ARP is no longer used for IPv6, trailer encapsulation [RFC- 87 893] MUST NOT be used. 89 2.4. Maximum Transmission Unit (MTU) 91 The MTU is a internetwork-layer indication of the maximum datagram 92 size which can be sent on an interface. This does not include link- 93 layer encapsulation and framing, but includes padding which can be | 94 added by the link-layer for small frames. 96 Many link-layer protocols define a maximum frame size that may be 97 sent. In such cases, a node MUST NOT allow a datagram to be sent 98 which would require frames larger than those allowed by the link- 99 layer protocol. 101 The MTU of each logical interface MUST be configurable, as limited by | 102 the link-layer frame size. However, a node MUST be able to receive a 103 packet as large as the maximum frame size, even if that is larger 104 than the currently configured MTU. 106 2.5. Maximum Receive Unit (MRU) 108 The MRU is a internetwork-layer indication of maximum datagram size 109 that can be received by a peer. This does not include link-layer 110 encapsulation and framing, but includes padding which can be added by | 111 the link-layer for small frames. 113 Some link-layer protocols [RFC-1661] define a mechanism for adjusting 114 the maximum frame size. In addition, this protocol provides the 115 advertisement of an MRU independently of the link-layer. 117 When the advertised MRU of a peer node is less than the configured 118 link MTU, that MRU MUST be maintained on a per peer basis. 120 2.6. Incoming Interface 122 On receipt of a link-layer unicast, broadcast or multicast packet, | 123 the node MAY check against a list of valid link addresses. If the | 124 packet passes the link-layer, then internetwork-layer will ensure the | 125 validity of the datagram. 127 For each received packet, the link-layer MUST pass the following 128 information to the internetwork-layer: 130 (1) the datagram itself. 132 (2) the length of the data portion of the link-layer frame, | 133 including padding (not including encapsulation and framing). 135 (3) the identity of the physical interface from which the datagram 136 was received. 138 (4) the classification of the received destination link-layer 139 address as unicast or multicast (including broadcast). | 141 In addition, the link-layer SHOULD provide: 143 (5) the source link-layer address, if any. 145 RATIONALE: 146 This section is included because other parts of this document 147 require specific information to be passed across this layer 148 boundary. 150 Although every different medium typically has a different address 151 format, the broadcast and multicast addresses are an important 152 special case. 154 Some link adapters check only a coarse grained hash or suffix of 155 the link destination. It is the responsiblity of the interface 156 implementation to prevent leaking. See also "Processing 157 Datagrams". 159 The source link address might be required in some implementations 160 to map an essentially transient link-layer address (such as, a 161 Frame-Relay DLCI) to the more stable family link address (that is, | 162 E.164). 164 2.7. Outgoing Interface 166 For each transmitted packet, the internetwork-layer MUST pass the 167 following information to the link-layer: 169 (1) the datagram itself. 171 (2) the length of the datagram. 173 (3) the destination physical interface. 175 (4) the destination link-layer address, if any. 177 In addition, the internetwork-layer SHOULD provide: 179 (5) the link-layer priority value. 181 The link-layer MUST notify the internetwork-layer if the packet to be 182 transmitted causes a link-layer precedence-related error. 184 2.8. Unreachable 186 The link-layer MUST NOT report a Destination Unreachable error to the 187 internetwork-layer solely because there is no Hop Cache entry for a 188 particular Destination. 190 3. Sending Datagrams 192 For outgoing datagrams, the internetwork-layer: 194 (1) sets any fields not set by the transport-layer. 196 (2) chooses the interface and next hop. 198 (3) fragments the datagram if necessary, when intentional 199 fragmentation is configured. 201 (4) passes the packet(s) to the appropriate link-layer interface. 203 3.1. Choosing a Source Address 205 When a node sends a datagram, the IPv6 Source MUST be one of its own 206 IPv6 Unicast Addresses (not an IPv6 Cluster or Multicast Address). 208 NOTE: | 209 This process is essentially the same as choosing the next hop (see | 210 "Next Hop Decision"). Implementors might be able to combine the | 211 two functions. | 213 If the datagram is sent in response to a received datagram, the 214 Destination from that datagram SHOULD be used as the Source for the 215 response (unless it was an IPv6 Unspecified, Cluster or Multicast | 216 Address). 218 An application MUST be able to explicitly specify the Source for 219 initiating a connection or a request. 221 If the Source to be used is unknown, a Source MUST be selected by the 222 internetwork-layer. 224 (a) When no Router Advertisements have been heard, the Destination 225 is assumed to be on an attached link. 227 The Source is chosen from an IPv6 Unicast Address which is 228 bound to any interface. 230 (b) When one or more Router Advertisements have been heard, the 231 Router List is examined. 233 If the Destination exactly matches the Primary Identifier of a 234 router, a Prefix-Information entension, or an Known-Identifier | 235 extension, then the Source is chosen from the interface on 236 which the advertisement was received. 238 (c) The Destination is compared against the routing-prefixes | 239 configured for each interface, or learned from Prefix- | 240 Information and Known-Identifier extensions. 242 If the Destination exactly matches one of the routing-prefixes, | 243 then the Source is chosen from the indicated interface. 245 (d) If the Destination does not match any routing-prefixes, then | 246 the Source is chosen from the interface of the most preferred | 247 router, as described in the "Router Selection" section which 248 follows. 250 When more than one IPv6 Unicast Address meets the criteria, the | 251 Source chosen SHOULD have the longest bit-wise prefix match with the 252 Destination. 254 Other selection preferences are implementation dependent. * 256 3.2. Hop Cache * 258 To efficiently send a series of datagrams to the same Destination, 259 each node MUST keep a cache of prior decisions, indexed by 260 Destination. * 262 The cache entry MUST include the link address (if any) to be used to | 263 send the datagram. This entry might point directly to the | 264 Destination, or to a router which forwards to the Destination. It 265 MAY contain other information which records previous experience 266 related to the Destination. 268 If the cache contains no information for a particular Destination, a 269 determination is made where to send the datagram. This is described 270 in the "Next Hop Decision" section which follows. * 272 3.3. Next Hop Decision 274 The next hop is chosen based on the IPv6 Destination. If the | 275 Destination can be readily determined to be on an attached link, the 276 datagram is sent directly to the Destination. * 278 To determine the next hop, the following algorithm is used: | 279 (a) If the Destination is the IPv6 Loopback Address, or an IPv6 280 Multicast Address with scope intra-node, process as an incoming 281 datagram. 283 (b) If the Destination is another scope of IPv6 Multicast Address, 284 simply pass the datagram to the link-layer for any indicated 285 interface(s). | 287 This requires that multicast datagrams are registered on a per | 288 interface basis. Other aspects of multicast routing are beyond | 289 the scope of this document. 291 (c) When no Router Advertisements have been heard, the Destination 292 is assumed to be on an attached link. 294 The datagram is duplicated for each interface. Each interface | 295 separately solicits the Destination location, as described in 296 "Sending General Solicitations". The correct interface will be | 297 learned when the Hop Cache is updated through the future | 298 advertisements of the target node. 300 (d) When one or more Router Advertisements have been heard, the 301 Router List is examined. 303 If the Destination exactly matches the Primary Identifier of a 304 router, a Prefix-Information entension, or an Known-Identifier | 305 extension, then the datagram is sent directly to the indicated 306 router (using the Media-Access extension provided, if any). 308 (e) The Destination is compared against the routing-prefixes | 309 configured for each interface, or learned from Prefix- | 310 Information and Known-Identifier extensions. There is a | 311 Contiguous-bit which indicates whether the routing-prefix is | 312 confined to a single link [D-Form]. 314 If the Destination exactly matches one of the routing-prefixes, | 315 and the Contiguous-bit is set, then the Destination is assumed 316 to be on that specific link. For that interface, the 317 Destination is located as described in "Sending General 318 Solicitations". 320 (f) If the Destination exactly matches one of the routing-prefixes, | 321 but the Contiguous-bit is not set, then the datagram is sent 322 directly to the indicated router (using the Media-Access 323 extension provided, if any). 325 (g) If the Destination does not match any routing-prefixes, then | 326 the datagram is sent to a single preferred router, as described 327 in the "Router Selection" section which follows. 329 For a node with multiple interfaces, when one or more Router 330 Advertisements have been heard on some interfaces, but no Router 331 Advertisements have been heard on other interfaces, the datagram is | 332 duplicated as described above. It is sent to the most preferred | 333 router, and also to all those interfaces without routers for which a 334 peer entity is unknown. This allows a node to continue operation in 335 the presence of private or partitioned links. * 337 Every host MUST operate correctly in a minimal environment. For 338 example, if the host insists on finding at least one router to 339 initialize, the host will be unable to operate on an isolated link. 341 3.4. Router Selection 343 The router is chosen based on the IPv6 Source. To decide which | 344 router to send a datagram, the following procedure is used: 346 (a) routing-prefixes are learned from the Prefix-Information | 347 extension of Router Advertisements. The Prefix_Size is the | 348 number of valid bits in the routing-prefix. 350 (b) The Source is compared to the list of routing-prefixes in the | 351 Router List. 353 (c) If a routing-prefix exactly matches the Source prefix extracted | 354 by the same Prefix_Size, then that router is one of the 355 preferred routers for that Source. The node selects the 356 highest preference value among those matching routers. 358 (d) If there are no matching routing-prefixes, or the Source is the | 359 Unknown Address, then there is no preferred router for the 360 Source. The node selects the highest preference value among 361 all routers found on all interfaces. 363 (e) If that router is not the best next-hop to the Destination, 364 that router will forward the datagram to the best next-hop, and 365 return a Local Redirect message to the sending node. See 366 "Sending Local Redirects". 368 (f) When the sending node receives a Local Redirect, it updates the 369 next-hop in the appropriate Hop Cache entry, so that later 370 datagrams to the same Destination will go directly to the best 371 next-hop. See "Processing Local Redirects". 373 When the Destination is determined to be accessible through a router, 374 a separate entry is created in the Hop Cache for that Destination, 375 and the cache entry for the router is used to send the datagram. The 376 Router List entry might be duplicated in the Hop Cache, or a system 377 of pointers could be used. In any case, the Hop Cache entry for the 378 Destination MUST have the same LifeTime as the cache entry for the 379 router. | 381 Once a Hop Cache entry has been added for a Destination, it is not | 382 affected by future Router Advertisements from new routers, or changes | 383 in Prefix-Information extensions. Only a Local Redirect changes the | 384 Hop Cache. | 386 RATIONALE: | 387 In a multiple router environment, this permits a saturated router | 388 to dynamically lower its preferences or reduce its number of | 389 advertised Prefix-Information extentions, in order to better share | 390 the load, without dumping its entire load on another router. 392 3.5. Static Routes | 394 A static route is typically a particular preset mapping for a 395 Destination IPv6 Unicast or Cluster Address. Static routes would be | 396 installed by administrators to override the normal automatic routing 397 mechanism, and to handle exceptional situations. 399 However, any static routing information is a potential source of 400 failure as configurations change or equipment fails. 402 Each such static route MUST be overridden by Local Redirects for the 403 LifeTime indicated. Otherwise, every datagram sent will result in a 404 repeated Redirect message. 406 3.6. Dead Node Detection 408 Routers periodically advertise their availability. The advertisement | 409 frequency is always greater than the LifeTime of the advertisement. | 410 When the LifeTime of a Router Advertisement expires, the router is | 411 presumed dead, and that Router List entry is immediately removed. | 412 All dependent Hop Cache Destinations are also removed. 414 RATIONALE: | 415 The exact constraints on the timeliness of "black hole" detection | 416 may vary somewhat depending on the nature of the node's mission, | 417 but a node generally needs to detect a failed first-hop router | 418 quickly enough that transport-layer connections will not break | 419 before an alternate router can be selected. | 421 Hosts do not periodically advertise. Therefore, when the LifeTime of | 422 a General Advertisement expires, it is retained for an implementation | 423 dependent period of time. This retention time MAY be a reasonably | 424 large value, to avoid excessive multicast probes for that Destination | 425 when a node only occasionally communicates with a given peer node. | 426 The retention time SHOULD NOT be arbitrarily large or infinite, to | 427 avoid losses and delays after an extended idle period when the link | 428 address of the Destination has changed. | 430 NOTE: | 431 This does not preclude purging of a cache entry prior to the | 432 expiration of its LifeTime or retention time, such as when the | 433 implementation has insufficient storage. | 435 When a datagram is to be sent, but the Hop Cache entry has expired | 436 and is retained, the datagram is sent using the last known link | 437 address. It is immediately followed by a General Solicitation, which | 438 is unicast to the Destination. The Hop Cache LifeTime is updated as | 439 described in "Sending General Solicitations". | 441 When an entry is purged, the routing availability of the Destination 442 MUST be redetermined as if no prior entry had existed. 444 Negative "advice" from other layers, such as excessive 445 retransmissions by a transport-layer protocol, or a down indication 446 from a link-layer interface, SHOULD be used to purge a cache entry. | 448 Positive "advice" from other layers, such as returning 449 acknowledgements from a transport-layer protocol, MUST NOT extend the 450 LifeTime of a cache entry. 452 Promiscuous observation of link-layer or internetwork-layer Source 453 fields MUST NOT extend the LifeTime of a cache entry. 455 ICMP Echo "pings" by the internetowrk-layer MUST NOT be used to | 456 actively check a cache entry. 458 RATIONALE: 459 If the cache has timed out, the node does not re-solicit until it | 460 has a datagram to send. 462 Queuing is avoided when any former link address is known. | 464 Passing advice from other layers of the protocol stack complicates 465 the interfaces between the layers, but it is the preferred 466 approach. 468 The detection mechanism must not cause unacceptable load on the 469 node, on congested links, or on first-hop router(s). | 471 Using other layer information to shorten, but not to lengthen, the | 472 cache LifeTime ensures that failed nodes are found quickly. | 473 Assuming that the configured LifeTime results in a light load on | 474 the network, then there is not much to be gained by lengthening | 475 the period. | 477 Packets arriving from a particular link-layer address are evidence 478 that the system at this address is alive. However, turning this 479 information into advice requires mapping the link-layer address | 480 into an internetwork-layer address, and then checking that address | 481 against the entries in the Hop Cache. This is probably 482 prohibitively inefficient. 484 Positive advice that is given for every datagram received could 485 cause unacceptable overhead in the implementation. 487 Ping scales poorly. 489 4. Processing Datagrams 491 For incoming datagrams, the internetwork-layer: 493 (1) verifies that the datagram is correctly formatted for the IP 494 version. 496 (2) verifies that it is destined to the local host. 498 (3) processes subsequent headers and options. 500 (4) reassembles the datagram as necessary. 502 (5) passes the final payload to the appropriate transport-layer 503 protocol module. 505 4.1. Address List 507 Each interface requires at least one IPv6 Address. 509 Each IPv6 Address is bound to at most one interface. 511 Each interface contains (at least) the following configurable 512 variables: 514 Address 516 The IPv6 Unicast Address which is presently in use for the 517 interface. 519 Default: None 521 Prefix_Size 523 Each Address entry bound to a link interface has an associated 524 Prefix_Size. The value ranges from 0 to 127, and indicates the 525 number of bits in the Address which define the routing-prefix for | 526 the link. 528 When the value is not zero, the Address may be used to discern | 529 routing-prefix mapping. 531 If all associated Prefix_Size values are zero, then prefix routing 532 is not in use on that link. 534 Default: 0 536 LifeTime 538 The value for the time that the Address is associated with an 539 interface. 541 Default: infinity 543 The routing-prefix(es) for a host interface SHOULD NOT be configured | 544 manually. 546 The routing-prefix(es) for a router interface SHOULD be configured | 547 manually, until such time in the future that an automatic algorithm 548 is developed. 550 4.2. Details 552 An incoming datagram is destined for the node when the IPv6 553 Destination is: 555 (1) (one of) the IPv6 Unicast Address(es) on any interface of the 556 node. 558 A host MUST NOT discard an incoming datagram whose Destination 559 does not correspond to the logical interface through which it 560 is received. 562 (2) an IPv6 Cluster Address which corresponds to the incoming | 563 interface, and which matches the Prefix_Size. 565 (3) an IPv6 Multicast group of which the host is a member on the 566 incoming interface. 568 A host MUST silently discard any IPv6 datagram which is not destined 569 for itself. 571 A router MUST silently discard any IPv6 unicast datagram which is not 572 destined for itself, and that has arrived with a link-layer broadcast 573 or multicast indication. Other unicast, cluster and multicast 574 routing details are beyond the scope of this document. 576 All nodes MUST silently discard any IPv6 datagram containing an 577 invalid IPv6 Source, such as an IPv6 Cluster or Multicast Address. 578 This validation could be done in either the internetwork-layer, or by 579 each protocol in the transport-layer. 581 RATIONALE: 583 A mis-addressed datagram might be caused by a link-layer broadcast 584 of a unicast datagram, or by any node that is confused or mis- 585 configured. 587 All nodes are required to check for a link-layer broadcast or 588 multicast, as well as an internetwork-layer address. This is 589 necessary to prevent propagation of mis-addressed datagrams, which 590 can result in broadcast storms. 592 An architectural goal for hosts is to allow addresses to be 593 featureless numbers, avoiding algorithms that required a knowledge 594 of the format. Otherwise, any future change in the format or 595 interpretation of addresses will require host software changes. 597 However, validation of IPv6 Cluster and Multicast Addresses 598 violates this goal. This is mitigated by the need to explicitly 599 learn or join these groups. 601 5. Sending General Solicitations 603 Every IPv6 node MUST implement General Solicitations. 605 The General Solicitation is used by any node to determine both the 606 reachability and the link-layer information of a neighboring node. | 608 5.1. Configuration * 610 A node SHOULD allow the following variables to be configured by 611 system management. Default values are specified which make it 612 unnecessary to re-configure these variables in most cases. 614 For each interface: 616 General_Solicitation_Interval 618 The value to be placed in the Lifetime field of the Hop Cache 619 entry for General Solicitations sent from the interface. MUST | 620 NOT be less than 1 second, and SHOULD NOT be greater than 10 621 seconds. 623 Default: 3 seconds 625 5.2. Details 627 A node is required to transmit a single General Solicitation, at the | 628 times specified in "Next Hop Decision" and "Dead Node Detection". 630 Whenever a solicitation is sent, a Hop Cache entry is added or | 631 updated with a LifeTime of General_Solicitation_Interval. No further 632 solicitations are sent until this Hop Cache entry expires. | 634 RATIONALE: 635 This mechanism prevents flooding (repeating a solicitation at a 636 high rate). 638 The General_Solicitation_Interval is chosen to allow sufficient 639 round trip time for low bandwidth or congested links, and response 640 time for heavily loaded nodes. 642 A LifeTime this short could create noticeable overhead traffic on 643 a link with large number of nodes. Therefore, it may be necessary 644 to configure busy routers or active servers with a longer 645 General_Solicitation_Interval. 647 The following method is used to send the solicitation: | 649 (a)If the interface and link address are known from an expired Hop | 650 Cache entry, the General Solicitation is sent using the retained | 651 link address. | 653 (b) If the interface has no broadcast capability (a point-to-point 654 link), and the peer entity is unknown (no advertisements 655 received), the General Solicitation is sent on that interface. | 656 No link address is needed. | 658 (c) If a virtual interface has no broadcast capability (a Frame- 659 Relay or X.25 link), the General Solicitation is duplicated on 660 each virtual circuit for which there is no known peer entity, 661 as if they were each a separate point-to-point interface on a 662 node with multiple physical interfaces. The link address used | 663 is determined by the virtual circuit setup. | 665 (d) If an interface has no multicast capability, the General 666 Solicitation is sent as a link-layer broadcast. The IPv6 667 Destination is unchanged. | 669 (e) For an interface with multicast capability, the General 670 Solicitation is sent as a link-layer multicast. The IPv6 | 671 Destination is used to calculate the appropriate multicast. 673 The solicitation is not delayed. | 675 Upon receiving a valid advertisement (of any kind) from the target * 676 Destination, the node MUST NOT send any solicitation on that 677 interface (even if no solicitation has been sent yet) until the 678 advertisement LifeTime expires. 680 RATIONALE: 681 This serves to alleviate congestion when many nodes start up on a 682 link at the same time, such as might happen after recovery from a 683 power failure, or the periodic Hop Cache refresh of a large number 684 of clients sharing a server. 686 When the link address is unknown, the original datagram SHOULD be held | 687 (rather than discarded) until a valid advertisement is received. When * 688 additional datagrams for the same Destination are received, the most * 689 recent are saved, and earlier datagrams MAY be discarded. 691 When the Hop Cache entry expires while waiting for an advertisement, any | 692 held datagrams MUST be discarded, and the entry is purged. 694 RATIONALE: 695 Failure to follow this recommendation causes the first packet of 696 every exchange to be lost. Although transport-layer protocols can 697 generally cope with packet loss by retransmission, packet loss does 698 impact performance. 700 For example, loss of a TCP open request causes the initial round-trip 701 time estimate to be inflated. UDP applications, such as the Domain 702 Name System, are more seriously affected. | 704 Purging the link address after failure to receive a response ensures | 705 that changes in link address are detected. | 707 Repeating solicitations after failure to receive a response, without | 708 waiting for renewed transport-layer stimulus, can cause congestive | 709 collapse. 711 6. Processing General Solicitations 713 Every IPv6 node MUST process General Solicitations. 715 All IPv6 nodes MUST accept the calculated Solicited-Nodes IPv6 716 Multicast Address for every address bound to every interface. 718 This is calculated by starting with the exclusive-or of each byte of 719 the target IPv6 Unicast Address, then adding the result to the base | 720 Solicited-Nodes multicast (FFxx::0700). 722 For example, to calculate the destination value for target A::B:C, | 723 the exclusive-or is D. The calculated destination would be | 724 FFxx::070D. 726 On receipt of a valid General Solicitation, the target node sends a 727 General Advertisement, using the extension information provided. 729 6.1. Validity 731 All nodes MUST silently discard any received General Solicitation 732 messages that do not satisfy the following validity checks: 734 - IPv6 Version is correct. 736 - IPv6 Source is a Unicast Address, is not the Unspecified Address, 737 and is not a Cluster or Multicast Address. 739 - When an Authentication Header is present, it is correct. | 741 - ICMP Checksum is correct. 743 - ICMP length (derived from the payload length) is 8 or more octets. 745 - The Known-Identifier extension indicates one of the IPv6 Unicast | 746 Addresses which is bound to any interface of the node. 748 - For interfaces which are not point-to-point links, the Media- 749 Access extension is present. 751 6.2. Details 753 The solicitation has no LifeTime. The extension information is used 754 only for returning the advertisement, and then discarded. 756 No new Hop Cache entry is added, and any existing entry is not 757 updated. 759 RATIONALE: 760 At the time of solicitation, the extension information might not 761 be complete. For example, the initial solicitation will not 762 contain the Node-Heard for the target, and the target will not be 763 assured that the path to the sender is complete. 765 This also helps stagger solicitations. 767 To process a General Solicitation, the node scans the list of 768 extensions in it. 770 6.2.1. Media-Access 772 If a Media-Access extension is present, the information MAY be used 773 to return the General Advertisement directly to the solicitor. The 774 Media-Access extension MAY appear anywhere in the list of extensions, 775 but is most likely at the beginning or end. 777 6.2.2. Node-Heard 779 The absence of the Node-Heard extension serves as an indication that 780 the solicitor has not yet heard any Router Advertisement. The 781 General Advertisement MUST be sent directly to the solicitor. 783 If a Node-Heard extension is present which indicates that the 784 solicitor has previously heard the node, it is confirmation of 785 contact in those cases where the routing-prefix is not entirely | 786 confined to the link. The General Advertisement MAY be sent directly 787 to the solicitor. 789 7. Sending General Advertisements 791 Every IPv6 node MUST implement General Advertisements. 793 A General Advertisement is sent in response to a General | 794 Solicitation, or to expire a previous Advertisement. 796 7.1. Constants 798 GENERAL_ADVERTISEMENT_COUNT 4 entries 800 7.2. Configuration 802 A node SHOULD allow the following variables to be configured by 803 system management. Default values are specified which make it 804 unnecessary to re-configure these variables in most cases. 806 For each interface: 808 Advertisement_LifeTime 810 The value to be placed in the Lifetime field of General 811 Advertisements sent from the interface. The value MAY be | 812 reduced on a case by case basis for demand critical | 813 applications operating in a low delay environment. 815 Default: 600 seconds 817 7.3. Details 819 The IPv6 Source specified in the solicitation is used as the IPv6 820 Destination in the advertisement, except under the following 821 conditions: 823 (a) When the number of current Hop Cache entries (exclusive of 824 static routes and router list entries) is 825 GENERAL_ADVERTISEMENT_COUNT or more. 827 (b) When one or more Router Advertisements have been heard, and the | 828 Source does not match any routing-prefixes configured for an 829 interface, or learned from Prefix-Information extensions. | 831 (c) When the Source exactly matches one of the routing-prefixes, | 832 but the Contiguous-bit is not set. 834 In these cases, the advertisement is sent to the All-Nodes IPv6 835 Multicast Address (FF02::1). The scope is intra-link. 837 RATIONALE: 838 The decision to multicast an advertisement to all nodes, instead 839 of repeating a unicast to each successive soliciting node, is a 840 balance between disturbing a large number of nodes at the 841 internetwork-layer against a greater amount of traffic. 843 Assuming that each node communicates with every neighbor, the 844 discovery traffic increases at the rate of 2n*n nodes. When most 845 nodes communicate only with a server, a multicast advertisement 846 reduces the traffic to 2n. 848 The multicast advertisements could be particularly disruptive when 849 they interrupt the sleep mode of a battery powered device. 850 However, the device might already have been disrupted by the 851 solicitation when the link has broadcast and not multicast 852 capability. Also, it is precisely those devices which are most 853 likely to be deployed on bandwidth-limited links, where a 854 reduction of traffic is most important. 856 In addition, roaming nodes which experience multipath and half- 857 link conditions use the multicast advertisement to learn whether a 858 direct contact is possible. 860 8. Processing General Advertisements 862 Every IPv6 node MUST process General Advertisements. 864 All IPv6 nodes MUST accept the All-Nodes IPv6 Multicast Address 865 (FFxx::1) on every interface. 867 On receipt of a valid General Advertisement, all nodes which have a 868 Hop Cache entry for the Source update the cache entry with the | 869 current LifeTime and link address, and any other pertinent field 870 values implemented. 872 8.1. Validity 874 All nodes MUST silently discard any received General Advertisement 875 messages that do not satisfy the following validity checks: 877 - IPv6 Version is correct. 879 - IPv6 Source is a Unicast Address, is not the Unspecified Address, 880 and is not a Cluster or Multicast Address. 882 - When an Authentication Header is present, it is correct. | 884 - ICMP Checksum is correct. 886 - ICMP length (derived from the payload length) is 16 or more 887 octets. 889 - For interfaces which are not point-to-point links, the Media- 890 Access extension is present. 892 8.2. Details 894 To process a General Advertisement, the node scans the list of 895 extensions in it. 897 8.2.1. Media-Access 899 If a Media-Access extension is present, the Hop Cache is updated with 900 the information. The Media-Access extension MAY appear anywhere in 901 the list of extensions, but is most likely at the beginning or end. | 902 When an unsolicited advertisement is received, this extension MUST | 903 NOT be compared with the current contents of the Hop Cache, since the | 904 advertisement might have been sent from another interface. 906 8.2.2. Known-Identifier | 908 The Known-Identifier extension is used to indicate IPv6 Addresses | 909 bound to other interfaces of the node, or other IPv6 addresses on the 910 same interface which are not subsumed by the same routing-prefix. | 912 Each Known-Identifier MAY be used to add or update another Hop Cache | 913 entry. 915 8.2.3. Node-Heard 917 If a Node-Heard extension is present which indicates that the 918 advertiser has previously heard the node, it is confirmation of 919 contact in those cases where the routing-prefix is not entirely | 920 confined to the link. 922 If the Quality specified is not zero, but is less than the Quality 923 for some other router Node-Heard extension, the Hop Cache entry MAY 924 be updated to point to that router instead. A Routing Header can be 925 used to direct datagrams along the more reliable path. 927 9. Sending Router Solicitations 929 Every IPv6 node MUST implement Router Solicitations. 931 When any node initializes, it MUST send the Router Solicitation to 932 prompt the advertisement of neighboring routers. 934 If (and only if) no advertisements from neighboring routers are 935 forthcoming, the node MAY retransmit the Router Solicitation a small 936 number of times, but then MUST desist from sending more 937 solicitations. 939 Any routers that subsequently start up, or that were not discovered 940 because of packet loss or temporary link partitioning, are eventually 941 discovered by reception of their periodic (unsolicited) 942 advertisements. Links that suffer high packet loss rates or frequent 943 partitioning are accommodated by increasing the rate of Router 944 Advertisements, rather than increasing the number of solicitations 945 that nodes are permitted to send. 947 9.1. Constants 949 MAX_SOLICITATIONS 3 transmissions 950 MAX_SOLICITATION_DELAY 2 seconds | 952 9.2. Configuration 954 A node SHOULD allow the following variables to be configured by 955 system management. Default values are specified which make it 956 unnecessary to re-configure these variables in most cases. 958 For each interface: 960 Router_Solicitation_Interval 962 The value to be used for repeated Router Solicitations sent 963 from the interface. MUST NOT be less than 2 * 964 MAX_SOLICITATION_DELAY, and SHOULD NOT be greater than 10 965 seconds. 967 Default: 6 seconds | 969 9.3. Details 971 A node is required to transmit up to MAX_SOLICITATIONS messages from 972 any of its interfaces after any of the following events: 974 - The interface is initialized at system startup time. 976 - The interface is reinitialized after a temporary interface failure 977 or after being temporarily disabled by system management. 979 - A router has its forwarding capability for that interface turned 980 off by system management. 982 If a node chooses to send a solicitation after one of the above 983 events, it MUST delay transmission for a random amount of time | 984 between 0 and MAX_SOLICITATION_DELAY. 986 It is recommended that nodes include some unique value (such as one | 987 of their interface or link-layer identifiers or addresses) in the | 988 seed used to initialize their pseudo-random number generators. | 989 Although the randomization range is specified in units of seconds, | 990 the actual randomly-chosen value SHOULD NOT be in units of whole | 991 seconds, but rather in units of the highest available timer | 992 resolution. | 994 The small number of retransmissions of a solicitation, which are 995 permitted if no advertisement is received, should be sent at 996 intervals of Router_Solicitation_Interval without further 997 randomization. 999 Upon receiving a valid Router Advertisement subsequent to one of the 1000 above events, the node MUST NOT send any solicitation on that 1001 interface (even if no solicitation has been sent yet) until the next 1002 time one of the above events occurs. | 1004 RATIONALE: | 1005 This serves to alleviate congestion when many nodes start up on a | 1006 link at the same time, such as might happen after recovery from a | 1007 power failure. 1009 10. Processing Router Solicitations | 1011 Every IPv6 router MUST process Router Solicitations. 1013 All IPv6 routers MUST accept the All-Routers IPv6 Multicast Address 1014 (FFxx::2) on every interface for which forwarding is enabled. 1016 On receipt of a valid Router Solicitation, the target router sends a 1017 Router Advertisement. 1019 If the IPv6 Source does not match one of the router's own IPv6 1020 Cluster Addresses on the arrival interface, by matching the | 1021 associated routing-prefix, the sender is considered a Mobile Node. 1022 The location of every reachable Mobile Node is maintained separately 1023 within the router. 1025 10.1. Validity 1027 A non-router MUST silently discard any received Router Solicitation 1028 messages. 1030 A router MUST silently discard any received Router Solicitation 1031 messages that do not satisfy the following validity checks: 1033 - IPv6 Version is correct. 1035 - IPv6 Source is the Unspecified Address, or an IPv6 Unicast 1036 Address, but is not a Cluster or Multicast Address. 1038 - When an Authentication Header is present, it is correct. | 1040 - ICMP Checksum is correct. 1042 - ICMP length (derived from the payload length) is 8 or more octets. 1044 - For interfaces which are not point-to-point links, the Media- 1045 Access extension is present. 1047 10.2. Details 1049 To process a Router Solicitation, the node scans the list of 1050 extensions in it. 1052 10.2.1. Media-Access 1054 If a Media-Access extension is present, the information MAY be used 1055 to return the Router Advertisement directly to the solicitor. The 1056 Media-Access extension MAY appear anywhere in the list of extensions, 1057 but is most likely at the beginning or end. 1059 10.2.2. Node-Heard 1061 The absence of the Node-Heard extension serves as an indication that 1062 the solicitor has not yet heard any Router Advertisement. The Router 1063 Advertisement MUST be sent promptly, at the accelerated initial rate. 1065 If a Node-Heard extension is present which indicates that the 1066 solicitor has previously heard the node, it is confirmation of 1067 contact in those cases where the routing-prefix is not entirely | 1068 confined to the link. 1070 11. Sending Router Advertisements 1072 Every IPv6 router MUST implement Router Advertisements. 1074 A Router Advertisement is sent periodically, and also in response to 1075 a Router Solicitation. 1077 11.1. Constants 1079 MAX_INITIAL_ADVERTISEMENTS 3 transmissions 1081 MAX_INITIAL_ADVERT_INTERVAL 10 seconds 1083 MAX_ADVERTISEMENT_DELAY 1 second | 1085 11.2. Configuration 1087 A router MUST allow the following variables to be configured by 1088 system management. Default values are specified which make it 1089 unnecessary to re-configure these variables in most cases. 1091 For each interface: 1093 Minimum_Advertisement_Interval 1095 The minimum time allowed between sending unsolicited Router 1096 Advertisements from the interface. MUST NOT be less than | 1097 MAX_ADVERTISEMENT_DELAY. 1099 Default: 30 seconds | 1101 Maximum_Advertisement_Interval 1103 The maximum time allowed between sending Router Advertisements 1104 from the interface. MUST NOT be less than | 1105 Minimum_Advertisement_Interval. 1107 Default: 1.50 * Minimum_Advertisement_Interval 1109 Advertisement_LifeTime 1111 The value to be placed in the Lifetime field of Router 1112 Advertisements sent from the interface. MUST NOT be less than 1113 Maximum_Advertisement_Interval, and SHOULD NOT be greater than | 1114 600 seconds (10 minutes). 1116 Default: 3 * Maximum_Advertisement_Interval 1118 For each of the IPv6 Unicast or Cluster Addresses of each interface: 1120 Advertise 1122 A flag indicating whether or not the IPv6 Address is to be 1123 advertised. 1125 Default: TRUE 1127 Preference 1129 The preferability of the interface as a default router choice, 1130 relative to other router interfaces serving the same routing- | 1131 prefix on the same link. 1133 Values are in the range 0 to 255. Higher values mean more 1134 preferable. The minimum value zero is reserved to indicate 1135 that the IPv6 Address, even though it may be advertised, is not 1136 to be used by neighboring hosts as a default Router Address. 1137 The maximum value 255 is reserved to indicate that the 1138 preference was locally configured, and not learned through 1139 advertisments. 1141 Default: 128 1143 It is useful to configure an IPv6 Address with a preference level 1144 of zero (rather than simply setting its Advertise flag to FALSE) 1145 when advertisements are being used for "black hole" detection. In 1146 particular, a router that is to be used to reach only specific 1147 destinations could advertise a preference level of zero (so that 1148 neighboring hosts will not use it as a default router for reaching 1149 arbitrary destinations) and a non-zero lifetime (so that 1150 neighboring hosts that have been redirected or configured to use 1151 it can detect its failure by timing out the reception of its 1152 advertisements). 1154 DISCUSSION: 1156 It has been suggested that, when the preference level of an 1157 IPv6 Address has not been explicitly configured, a router could 1158 set it according to the metric of the router's "default route" 1159 (if it has one), rather than defaulting as suggested above. 1160 Thus, a router with a better metric for its default route would 1161 advertise a higher preference level for its IPv6 Address. 1163 (Note that routing metrics that are encoded such that "lower is 1164 better" would have to be inverted before being used as 1165 preference levels in Router Advertisement messages.) Such a 1166 strategy might reduce the amount of redirect traffic on some 1167 links by making it more likely that the host's first choice for 1168 reaching an arbitrary destination is also the best choice. 1170 On the other hand, redirect traffic is rarely a significant 1171 load on a link, and there are some cases where such a strategy 1172 would result in more redirect traffic (on links from which the 1173 most frequently chosen destinations are best reached via 1174 routers other than the one with the best default route). Also, 1175 since the routing algorithms learn of neighboring routers from 1176 the advertisements, and the default routes are learned from the 1177 routing algorithms, the calculated preference may be unstable 1178 from time to time. This document makes no recommendation 1179 concerning this issue, and implementors are free to try such a 1180 strategy, as long as they also support static configuration of 1181 preference levels as specified above. 1183 11.3. Details 1185 The term "advertising interface" refers to any functioning and 1186 enabled interface that has at least one IPv6 Address whose configured 1187 Advertise flag is TRUE. 1189 From each advertising interface, the router MUST transmit Router 1190 Advertisements. 1192 The advertisements are not strictly periodic. The interval between 1193 subsequent transmissions is randomized to reduce the probability of 1194 synchronization with the advertisements from other routers on the 1195 same link. This is done by maintaining a separate transmission 1196 interval timer for each advertising interface. Each time an 1197 advertisement is sent from an interface, that interface's timer is 1198 reset to a uniformly-distributed random value between the configured 1199 Minimum_Advertisement_Interval and Maximum_Advertisement_Interval. 1200 Expiration of the timer causes the next advertisement to be sent, and 1201 a new random value to be chosen. 1203 For the first few advertisements sent from an interface (up to 1204 MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is 1205 greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to 1206 MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for 1207 the initial advertisements increases the likelihood of a router being 1208 discovered quickly when it first becomes available, in the presence 1209 of possible packet loss. 1211 An interface may become an advertising interface at times other than 1212 system startup, as a result of recovery from an interface failure or 1213 through actions of system management such as: 1215 - enabling the interface, if it had been administratively disabled 1216 and it has one or more IPv6 Addresses whose Advertise flag is 1217 TRUE, 1219 - enabling IPv6 forwarding capability (changing the node from a host 1220 to a router), when the interface has one or more IPv6 Addresses 1221 whose Advertise flag is TRUE, 1223 - setting the Advertise flag of one or more of the interface's IPv6 1224 Addresses to TRUE (or adding a new IPv6 Address with a TRUE 1225 Advertise flag), when previously the interface had no IPv6 Address 1226 whose Advertise flag was TRUE. 1228 In such cases, the router MUST commence transmission of periodic 1229 advertisements on the new advertising interface, limiting the first 1230 few advertisements to intervals no greater than 1231 MAX_INITIAL_ADVERT_INTERVAL. In the case of a host becoming a 1232 router, the node MUST also accept the All-Routers IPv6 Multicast 1233 Address on all interfaces on which the router supports multicast 1234 (whether or not they are advertising interfaces). 1236 An interface MAY also cease to be an advertising interface, through 1237 actions of system management such as: 1239 - shutting down the node, 1241 - administratively disabling the interface, 1243 - disabling IPv6 forwarding capability (changing the node from a 1244 router to a host), 1246 - setting the Advertise flags of all of the interface's IPv6 1247 Addresses to FALSE. 1249 In such cases, the router MUST transmit a final multicast 1250 advertisement on the interface, identical to its previous 1251 transmission, but with a Lifetime of zero. In the case of a router 1252 becoming a host, the node MUST also drop the All-Routers IPv6 1253 Multicast Address on all interfaces on which the router supports 1254 multicast (whether or not they had been advertising interfaces). 1256 When the Advertise flag of one or more of an interface's IPv6 1257 Addresses are set to FALSE by system management, but there remain 1258 other IPv6 Addresses on that interface whose Advertise flags are 1259 TRUE, the router SHOULD send a single multicast advertisement 1260 containing only those IPv6 Addresses whose Advertise flags were set 1261 to FALSE, with a Lifetime of zero. 1263 In addition to the periodic unsolicited advertisements, a router MUST 1264 send advertisements in response to valid Router Advertisements or 1265 Router Solicitations received on any of its advertising interfaces. 1266 If the received advertisement or solicitation does not contain any 1267 Node-Heard extension, and the time since the previous advertisement 1268 is greater than MAX_INITIAL_ADVERT_INTERVAL, the router MUST 1269 multicast an advertisement from that interface. 1271 Whenever these response advertisements are sent, the node MUST delay 1272 transmission for a random amount of time between 0 and | 1273 MAX_ADVERTISEMENT_DELAY, in order to prevent synchronization with 1274 other responding routers, and to allow multiple closely-spaced 1275 solicitations to be answered with a single advertisement. The 1276 interface's interval timer is reset to a new random value, as with 1277 unsolicited advertisements. 1279 It is recommended that routers include some unique value (such as one 1280 of their interface or link-layer addresses) in the seed used to 1281 initialize their pseudo-random number generators. Although the 1282 randomization range is configured in units of seconds, the actual 1283 randomly-chosen values SHOULD NOT be in units of whole seconds, but 1284 rather in units of the highest available timer resolution. 1286 12. Processing Router Advertisements 1288 Every IPv6 node MUST process Router Advertisements. 1290 All IPv6 nodes MUST accept the All-Nodes IPv6 Multicast Address 1291 (FFxx::1) on every interface. 1293 Each router saves the information contained in the advertisements, in 1294 order to respond to future requests. Any other action on receipt of 1295 such messages by a router (for example, as part of a "peer discovery" 1296 process) is beyond the scope of this document. 1298 Each host saves the information contained in the advertisements, in 1299 order to determine the next-hop when sending datagrams. Hop 1300 determination is elaborated in "Sending Datagrams". 1302 12.1. Validity 1304 All nodes MUST silently discard any received Router Advertisement 1305 messages that do not satisfy the following validity checks: 1307 - IPv6 Version is correct. 1309 - IPv6 Source is a Unicast Address, is not the Unspecified Address, 1310 and is not a Cluster or Multicast Address. 1312 - When an Authentication Header is present, it is correct. | 1314 - ICMP Checksum is correct. 1316 - ICMP length (derived from the payload length) is 16 or more 1317 octets. 1319 - At least one Prefix-Information extension is present. | 1321 - For interfaces which are not point-to-point links, the Media- 1322 Access extension is present. 1324 12.2. Router List 1326 Host Requirements -- Communication Layers [1], Section 3.3.1.6, 1327 specifies that each host (must) support a configurable list of 1328 default routers. The purpose of the Router Advertisement messages is 1329 to eliminate the need to configure that list. 1331 Each entry in the list contains (at least) the following configurable 1332 variables: 1334 Router_Identifier 1336 An IPv6 Unicast Address of a default router. 1338 Default: (none) 1340 Prefix_Size 1342 Each router entry has an associated Prefix_Size. The value ranges 1343 from 0 to 127, and indicates the number of bits in the IPv6 1344 Address which define the routing-prefix for the link. A value of | 1345 zero indicates an end-point IPv6 Address. When the value is not 1346 zero, the IPv6 Address may be used to discern routing-prefix | 1347 mapping. 1349 If all associated Prefix_Size values are zero, then prefix routing 1350 is not in use on that link. 1352 Default: 0 1354 Preference 1356 The preferability of the Router_Identifier as a default router 1357 choice, relative to other router interfaces serving the same | 1358 routing-prefix on the same link. Host Requirements does not 1359 specify how this value is to be encoded. 1361 The values used here are defined as in Router Advertisements. 1362 Values are in the range 0 to 255. Higher values mean more 1363 preferable. The minimum value zero is reserved to indicate that 1364 the IPv6 Address, even though it may be advertised, is not to be 1365 used by neighboring hosts as a default Router Address. The 1366 maximum value 255 is reserved to indicate that the preference was 1367 locally configured, and not learned through advertisments. 1369 Default: 255 1371 Default routers and preference levels SHOULD NOT be configured 1372 manually. On links for which router discovery is administratively 1373 disabled, it MAY continue to be necessary to configure the default 1374 Router List in each host. 1376 NOTES: Any router IPv4 Address acquired from the "Gateway" 1377 subfield of the vendor extensions field of a BOOTP packet [RFC- 1378 BOOTP?11] are considered to be configured; they are assigned the 1379 default preference level of 255, and they do not have an 1380 associated LifeTime. 1382 Any IPv4 Address found in the "giaddr" field of a BOOTP packet 1383 [RFC-BOOTP?3] identifies a BOOTP forwarder which is not 1384 necessarily a router; an entry SHOULD NOT be installed in the 1385 default Router List. 1387 12.3. Details 1389 To process a Router Advertisement, the node scans the list of 1390 extensions in it. 1392 12.3.1. Media-Access 1394 If a Media-Access extension is present, the Router List is updated 1395 with the information. The Media-Access extension MAY appear anywhere 1396 in the list of extensions, but is most likely at the beginning or 1397 end. 1399 12.3.2. Change-Identifier 1401 This extension gives advance indication that an address or prefix 1402 will no longer be routable. Applications SHOULD cease to accept new 1403 connections with the old value. Existing connections SHOULD issue a 1404 Remote Redirect. 1406 Change-Identifier extensions MUST preceed Prefix-Information | 1407 extensions. 1409 - If the Prefix_Size is zero, the IPv6 Address indicates the change 1410 of a single node, without affecting other nodes on that link. 1412 - If the Prefix_Size is not zero, the IPv6 Address indicates the | 1413 change of routing-prefix for all nodes on that link. 1415 - The IPv6 Address and Prefix_Size are compared against any IPv6 1416 Addresses defined for the node. If there is a match, a Remote 1417 Redirect MAY be sent to correspondents to inform them of the 1418 change. 1420 The node MUST continue to accept datagrams destined for the old IPv6 1421 Address(es), until such time as all stimulus for maintaining the 1422 entry has expired. This implies that the node will maintain a 1423 LifeTime for most sources of IPv6 Addresses, such as DNS records and 1424 dynamic configuration. 1426 12.3.3. Prefix-Information | 1428 Prefix-Information extensions MUST preceed Known-Identifier | 1429 extensions. 1431 - If the Prefix_Size is not zero, the IPv6 Address and Prefix_Size 1432 are compared against any IPv6 Addresses defined for the node. If 1433 there is a match, the IPv6 Address is associated with the 1434 interface on which the message was received, and the Prefix_Size 1435 is set to the advertised Prefix_Size. 1437 - If the IPv6 Address is not already present in the Router List, a 1438 new entry is added to the list, containing the IPv6 Address along 1439 with its accompanying preference level, and the Lifetime value 1440 from the advertisement. 1442 - If the IPv6 Address is already present in the Router List as a 1443 result of a previously-received advertisement, its preference 1444 level is updated and its LifeTime is reset to the value in the 1445 newly-received advertisement. 1447 - If the IPv6 Address is already present in the Router List as a 1448 result of static configuration, no change is made to its 1449 preference level. There is no LifeTime associated with a 1450 configured IPv6 Address. To limit the storage needed for the 1451 default Router List, the host MAY choose not to store all of the 1452 router IPv6 Addresses discovered via advertisements. The host 1453 SHOULD discard those IPv6 Addresses with lower preference levels 1454 in favor of those with higher levels. 1456 It is desirable to retain more than one default router in the list; 1457 if the current choice of default router is discovered to be down, the 1458 host may immediately choose another default router without having to 1459 wait for the next advertisement to arrive. 1461 Any router IPv6 Address advertised with a preference level of zero is 1462 not to be used by the host as default router IPv6 Address. Such an 1463 IPv6 Address may be omitted from the default Router List, unless its 1464 LifeTime is being used as a "black-hole" detection mechanism. 1466 12.3.4. Known-Identifier | 1468 The Known-Identifier extension is used to indicate IPv6 Addresses | 1469 bound to other interfaces of the router, or other IPv6 Addresses on 1470 the same interface which are not subsumed by the same routing-prefix. | 1472 - If the IPv6 Address is not already present in the Router List, a 1473 new entry MAY be added, containing the IPv6 Address, the 1474 preference level set to zero, and the Lifetime value from the 1475 advertisement. 1477 - If the IPv6 Address is already present in the Router List as a 1478 result of a previously-received advertisement, and its preference 1479 level is zero, its LifeTime is reset to the value in the newly- 1480 received advertisement. 1482 - If the IPv6 Address is already present in the Router List as a 1483 result of static configuration, no change is made to its 1484 preference level. There is no LifeTime associated with a 1485 configured IPv6 Address. 1487 To limit the storage needed for the default Router List, the host 1488 MAY choose not to store all of the other IPv6 Addresses discovered 1489 via advertisements. The most preferred router is used for unknown 1490 Destinations, and it will send a redirect when appropriate. 1492 12.3.5. Node-Heard 1494 As in a General or Router Solicitation, the absence of the Node-Heard 1495 extension serves as an indication that the router has not yet heard 1496 any other Router Advertisement. 1498 If the Quality specified is not zero, but is less than the Quality 1499 for some other router Node-Heard extension, the Hop Cache entry MAY 1500 be updated to point to that router instead. A Routing Header can be 1501 used to direct datagrams along the more reliable path. 1503 13. Sending Local Redirects 1505 Every IPv6 router MUST implement Local Redirect. 1507 A router sends a Local Redirect when it receives datagrams for which 1508 that router is not the best next-hop to the Destination. The router 1509 will forward the datagram to the best next-hop, and return a Local 1510 Redirect message to the sending node. 1512 A host SHOULD NOT send a Local Redirect. 1514 14. Processing Local Redirects 1516 Every IPv6 host MUST process Local Redirects. | 1518 On receipt of a valid Local Redirect, a host MUST update its Hop 1519 Cache. | 1521 Every IPv6 router which is participating in a routing protocol MUST | 1522 ignore Local Redirects. 1524 14.1. Validity 1526 All nodes MUST silently discard any received Local Redirect messages 1527 that do not satisfy the following validity checks: 1529 - IPv6 Version is correct. 1531 - IPv6 Source is a Unicast Address, is not the Unspecified Address, 1532 is not a Cluster or Multicast Address, and is the current next hop 1533 router for the target specified in the Known-Identifier | 1534 extension(s). 1536 - When an Authentication Header is present, it is correct. | 1538 - ICMP Checksum is correct. 1540 - ICMP length (derived from the payload length) is 16 or more 1541 octets. 1543 - The Known-Identifier extension indicates one of the IPv6 Unicast | 1544 Addresses in the Hop Cache. 1546 - For interfaces which are not point-to-point links, the Media- 1547 Access extension is present. 1549 14.2. Details 1551 Since the routing-prefixes bound to an interface are not required to | 1552 be relevant for all Destinations, the next hop specified is always * 1553 presumed to be accessible via the same interface through which the | 1554 Redirect arrived. The Redirect MUST NOT be discarded simply because | 1555 it arrives on an interface which has no matching advertised prefix. 1557 RATIONALE: 1558 A Mobile Node will likely not have a prefix which matches any 1559 router advertised prefixes. When a local host (such as a printer 1560 or DNS) responds to a message from the Mobile Node, it will 1561 initially send to its preferred router. That router will send a 1562 Redirect to the Mobile Node. 1564 When a Redirect is received with a non-zero Prefix_Size, it is | 1565 treated as if it has a zero Prefix_Size. That is, the cache entry 1566 for the Destination (only) would be updated (or created when an entry 1567 for that Destination did not exist), with a Prefix_Size of zero. 1569 RATIONALE: 1570 This recommendation is to protect against routers that erroneously | 1571 send Redirects for an entire routing prefix. 1573 15. Sending Remote Redirects 1575 Every IPv6 node MUST implement Remote Redirects. 1577 A node sends a Remote Redirect when it receives a Router 1578 Advertisement containing Change-Identifier extensions. The Hop Cache 1579 is examined for Destinations accessed through that router. Those 1580 remote nodes are sent the Remote Redirect with an indication of a 1581 Care-Of-Address to use in order to reach the expiring identification 1582 of the node. 1584 A Mobile Node MAY also send a Remote Redirect when it receives a 1585 datagram which does not have a Routing Header containing its current 1586 Care-Of-Address(es). See [Mobility] for details. | 1588 The Remote Redirect is only sent to those remote nodes with which the 1589 node maintains a Security Association. 1591 16. Processing Remote Redirects 1593 Every IPv6 node MUST process Remote Redirects. 1595 On receipt of a valid Remote Redirect, the node uses a Routing Header 1596 to reach the sender. 1598 16.1. Validity 1600 All nodes MUST silently discard any received Remote Redirect messages 1601 that do not satisfy the following validity checks: 1603 - IPv6 Version is correct. 1605 - IPv6 Source is a Unicast Address, is not the Unspecified Address, 1606 is not a Cluster or Multicast Address, and indicates one of the 1607 IPv6 Unicast Addresses in the Hop Cache. 1609 - An Authentication Header is present, and it is correct. | 1611 - ICMP Checksum is correct. 1613 - ICMP length (derived from the payload length) is 16 or more 1614 octets. 1616 16.2. Details 1618 To process a Remote Redirect, the node scans the list of extensions 1619 in it. 1621 16.2.1. Known-Identifier | 1623 The Known-Identifier extension is used to indicate the IPv6 Unicast | 1624 or Cluster Address which is used as a Care-Of-Address to reach the 1625 Source. 1627 A. Configuration Summary 1629 A.1. Router Configuration 1631 A router requires at least one IPv6 Address to be configured. 1633 For each interface, a Prefix_Size is assigned to each IPv6 Address, 1634 unless automatic prefix discovery is in place. 1636 Note that this procedure minimizes the number of items to be 1637 configured, and possible configuration errors. 1639 Optionally, other values MAY be altered from their defaults, such as 1640 preference and advertisement lifetime. 1642 Optionally, routing protocols MAY require additional values to be 1643 configured, such as metric and priority. Such functions are beyond 1644 the scope of this document. 1646 A.2. Host Configuration 1648 Most hosts need no prior configuration. 1650 A node attached to a multi-access link creates a local-use unicast | 1651 address from the link address. 1653 A node attached to a point-to-point link (using the Point-to-Point | 1654 Protocol [RFC-1661]) can be dynamically assigned either a global or 1655 local unicast address. 1657 Other nodes require configuration of an IPv6 Address, as described in 1658 "Address List". 1660 B. Hop Cache Implementation 1662 Each Hop Cache entry needs to include the following items: 1664 (1) LifeTime 1665 (2) Next-hop interface (when a node is multi-homed) 1666 (3) Next-hop link address | 1667 (4) Destination IPv6 Address 1668 (5) Destination Prefix_Size 1669 (6) Source IPv6 Address 1670 (7) Flow Label 1671 (8) Path Maximum Transmission Unit 1672 (9) Path Round Trip Time 1674 Field (4) MAY be the full IPv6 Address of the Destination, or the 1675 Cluster which includes the Destination. This is determined by the | 1676 routing-prefix size in (5). 1678 Field (7) SHOULD be included, as it is related to the Source in (6). 1680 DISCUSSION: 1681 Each Hop Cache entry defines the end-points of an internetwork 1682 path. Although the connecting path may change dynamically in an 1683 arbitrary way, the transmission characteristics of the path tend 1684 to remain approximately constant over a time period longer than a 1685 single typical host-host transport connection. Therefore, a Hop 1686 Cache entry is a natural place to cache data on the properties of 1687 the path. 1689 Examples of such properties might be the maximum unfragmented 1690 datagram size, or the average round-trip delay measured by a 1691 transport protocol. This data will generally be both gathered and 1692 used by a higher layer protocol (that is, by TCP or by an 1693 application using UDP). Experiments are currently in progress on 1694 caching path properties in this manner. 1696 There is no consensus on whether the Hop Cache should be keyed on 1697 destinations alone, or allow both Unicast and Cluster addresses. 1698 Those who favor the use of only node identifiers argue that: 1700 (1) Redirect messages will generally result in entries keyed on 1701 nodes. The simplest and most general scheme would be to 1702 only use node identifiers. 1704 (2) The internetwork layer may not always know the Prefix_Size | 1705 for a remote link. 1707 (3) The use of only node identifiers may allow the Internet 1708 architecture to be more easily extended in the future 1709 without any change to the hosts. 1711 The opposing view is that allowing a mixture of destination nodes | 1712 and routing-prefixes in the Hop Cache: 1714 (1) Saves memory space. 1716 (2) Leads to a simpler data structure, easily combining the 1717 cache with the tables of default and static routes. 1719 (3) Provides a more useful place to cache path properties. 1721 The cache needs to be large enough to include entries for the maximum 1722 number of destinations that may be in use at one time. 1724 Advertisement updates could indefinitely continue to refresh 1725 otherwise unused entries. A Hop Cache entry SHOULD also include 1726 control information used to choose an entry for replacement. For 1727 example, this might take the form of a "recently used" bit, a use 1728 count, or a last-used timestamp. It is also recommended that it 1729 include the time of last modification of the entry, for diagnostic 1730 purposes. 1732 An implementation may wish to reduce the overhead of scanning the Hop 1733 Cache for every datagram to be transmitted. This may be accomplished 1734 with a hash table to speed the lookup, or by giving a connection- 1735 oriented transport protocol a "hint", or temporary handle on the 1736 appropriate cache entry, to be passed to the internetwork-layer with 1737 each subsequent datagram. 1739 Although the Hop Cache, the Router List, and a table of static routes 1740 are described as conceptually distinct, in practice they may be 1741 combined into a single "routing table" data structure. 1743 C. Proxy Advertisements 1745 A router MAY proxy for the identifiers of other nodes, using the | 1746 Known-Identifier extension. 1748 This SHOULD only be used when the router is translating to another 1749 internetwork protocol format. 1751 D. Examples 1753 D.1. Simple Solicitation 1755 Assume host A has address 1 and host B has addresses 2 and 3. There 1756 is only one interface on A, and only one interface on B. 1758 A is trying to talk to B, so it sends a General Solicitation to B, 1759 fills in portions of a Hop Cache entry, and waits for the General 1760 Advertisement from B. 1762 The Known-Identifier extension in the solicitation is 2. | 1764 B sends a General Advertisement with the Media-Access for its 1765 interface. It also puts 3 in an Known-Identifier extension. | 1767 A MUST update its cache entry for 2. 1769 A SHOULD also add another cache entry for 3, using the same link | 1770 address. This is not required in a minimal memory implementation. 1772 D.2. Complex Solicitation 1774 Assume that host B had a different interface for 3 on the same link. 1776 If host A already had a Hop Cache entry for 3 (using the original | 1777 link address), but the advertisement (above) contains a different | 1778 link address for 3, A MUST add another cache entry for 3, pointing to 1779 2. 1781 This is required in order that the purpose of redundant interfaces on 1782 the same link be fulfilled, and 3 is accessible through 2 (and vice 1783 versa) when its interface fails. 1785 The pairing of IPv6 address and link address can be considered a | 1786 tuple consisting of {IPv6 address, interface, link address}. 1788 This allows annealing of partitioned links with no effort by hosts. 1790 Security Considerations 1792 There are a lot of Security issues which are not discussed in this 1793 memo. 1795 Acknowledgements 1797 The document was initially composed of quotations from the RFC-1122 1798 "Requirements for Internet Hosts -- Communication Layers" (Robert 1799 Braden, Editor), and RFC-1256 "ICMP Router Discovery Messages" (Steve 1800 Deering, Editor), and "Requirements for IP Routers" (Almquist and 1801 Kastenholz, Editors). 1803 Thanks also for suggestions and contributions from the Simple-IP 1804 Working Group. 1806 The Dead Node detection method was clarified by Robert Elz. | 1808 Special thanks for implementation review by Ran Atkinson (Naval 1809 Research Laboratory), Alex Conta (Digital Equipment Corporation), Dan | 1810 McDonald (Naval Research Laboratory), Fred Rabouw (Network Systems 1811 Netherlands), and Brad Stone (Hewlett-Packard). 1813 Author's Address 1815 Questions about this memo can also be directed to: 1817 William Allen Simpson 1818 Daydreamer 1819 Computer Systems Consulting Services 1820 1384 Fontaine 1821 Madison Heights, Michigan 48071 1823 Bill.Simpson@um.cc.umich.edu 1824 bsimpson@MorningStar.com 1825 Table of Contents 1827 1. Introduction .......................................... 1 1829 2. Link-Layers ........................................... 1 1830 2.1 Addresses .......................................1 | 1831 2.2 Address Resolution Protocol (ARP) ............... 1 1832 2.3 Trailers ........................................ 2 1833 2.4 Maximum Transmission Unit (MTU) ................. 2 1834 2.5 Maximum Receive Unit (MRU) ...................... 2 1835 2.6 Incoming Interface .............................. 2 1836 2.7 Outgoing Interface .............................. 3 1837 2.8 Unreachable ..................................... 4 1839 3. Sending Datagrams ..................................... 5 1840 3.1 Choosing a Source Address ....................... 5 1841 3.2 Hop Cache ....................................... 6 1842 3.3 Next Hop Decision ............................... 6 1843 3.4 Router Selection ................................ 8 1844 3.5 Static Routes ................................... 9 1845 3.6 Dead Node Detection ............................. 9 1847 4. Processing Datagrams .................................. 12 1848 4.1 Address List .................................... 12 1849 4.2 Details ......................................... 13 1851 5. Sending General Solicitations ......................... 15 1852 5.1 Configuration ................................... 15 1853 5.2 Details ......................................... 15 1855 6. Processing General Solicitations ...................... 18 1856 6.1 Validity ........................................ 18 1857 6.2 Details ......................................... 18 1858 6.2.1 Media-Access .................................... 19 1859 6.2.2 Node-Heard ...................................... 19 1861 7. Sending General Advertisements ........................ 20 1862 7.1 Constants ....................................... 20 1863 7.2 Configuration ................................... 20 1864 7.3 Details ......................................... 20 1866 8. Processing General Advertisements ..................... 22 1867 8.1 Validity ........................................ 22 1868 8.2 Details ......................................... 22 1869 8.2.1 Media-Access .................................... 22 1870 8.2.2 Known-Identifier ................................23 | 1871 8.2.3 Node-Heard ...................................... 23 1873 9. Sending Router Solicitations .......................... 24 1874 9.1 Constants ....................................... 24 1875 9.2 Configuration ................................... 24 1876 9.3 Details ......................................... 25 1878 10. Processing Router Solicitations ....................... 26 1879 10.1 Validity ........................................ 26 1880 10.2 Details ......................................... 26 1881 10.2.1 Media-Access .................................... 27 1882 10.2.2 Node-Heard ...................................... 27 1884 11. Sending Router Advertisements ......................... 28 1885 11.1 Constants ....................................... 28 1886 11.2 Configuration ................................... 28 1887 11.3 Details ......................................... 30 1889 12. Processing Router Advertisements ...................... 33 1890 12.1 Validity ........................................ 33 1891 12.2 Router List ..................................... 33 1892 12.3 Details ......................................... 35 1893 12.3.1 Media-Access .................................... 35 1894 12.3.2 Change-Identifier ............................... 35 1895 12.3.3 Prefix-Information ..............................36 | 1896 12.3.4 Known-Identifier ................................37 | 1897 12.3.5 Node-Heard ...................................... 37 1899 13. Sending Local Redirects ............................... 38 1901 14. Processing Local Redirects ............................ 38 1902 14.1 Validity ........................................ 38 1903 14.2 Details ......................................... 39 1905 15. Sending Remote Redirects .............................. 40 1907 16. Processing Remote Redirects ........................... 40 1908 16.1 Validity ........................................ 40 1909 16.2 Details ......................................... 41 1910 16.2.1 Known-Identifier ................................41 | 1912 APPENDICES ................................................... 42 1914 A. Configuration Summary ................................. 42 1915 A.1 Router Configuration ............................ 42 1916 A.2 Host Configuration .............................. 42 1918 B. Hop Cache Implementation .............................. 43 1920 C. Proxy Advertisements .................................. 45 1921 D. Examples .............................................. 46 1922 D.1 Simple Solicitation ............................. 46 1923 D.2 Complex Solicitation ............................ 46 1925 SECURITY CONSIDERATIONS ...................................... 47 1927 ACKNOWLEDGEMENTS ............................................. 47 1929 AUTHOR'S ADDRESS ............................................. 47