idnits 2.17.1 draft-simpson-ipv6-discov-process-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-24) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** 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 87 instances of too long lines in the document, the longest one being 3 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 71: '... each node MUST keep a cache of prio...' RFC 2119 keyword, line 92: '... the Destination MUST have the same ...' RFC 2119 keyword, line 111: '... Field (4) MAY be the full IPv6 Addr...' RFC 2119 keyword, line 115: '... Field (7) SHOULD be included, as it...' RFC 2119 keyword, line 191: '... algorithm MUST be used:...' (43 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 (October 1994) is 10784 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 54 looks like a reference -- Missing reference section? 'D-form' on line 55 looks like a reference -- Missing reference section? '1' on line 741 looks like a reference -- Missing reference section? '11' on line 909 looks like a reference -- Missing reference section? '3' on line 915 looks like a reference -- Missing reference section? 'RFC-1661' on line 993 looks like a reference Summary: 10 errors (**), 0 flaws (~~), 1 warning (==), 8 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 October 1994 5 IPv6 Neighbor Discovery -- Processing 6 draft-simpson-ipv6-discov-process-00.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 ds.internic.net (US East Coast), nic.nordu.net 30 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 31 Rim). 33 Abstract 35 This document discusses the techniques for identification of and 36 forwarding to adjacent IPv6 nodes, including Next Hop Determination 37 and Router Discovery. 39 1. Introduction 41 This document describes how to process ICMP Neighbor Discovery 42 messages 44 - to determine the availability of other IPv6 nodes as demand for 45 communication occurs; 47 - to detect the presence of available IPv6 routers; 49 - to learn the appropriate media address for sending to its 50 neighbors; 52 - and to self-configure using the Cluster prefix(es) for the link. 54 The design requirements are more completely described in [D-sign]. | 55 The ICMP packet formats are described in [D-form]. 57 2. Sending Datagrams 59 The IPv6 node chooses the next hop for each datagram sent. If the | 60 Destination can be readily determined to be on an attached link, the | 61 datagram is sent directly to the Destination. Otherwise, it is sent 62 to a router. 64 2.1. Constants 66 GENERAL_SOLICITATION_INTERVAL 3 seconds 68 2.2. Hop Cache | 70 To efficiently send a series of datagrams to the same Destination, | 71 each node MUST keep a cache of prior decisions, indexed by | 72 Destination. The node uses the following basic algorithm on this | 73 cache to send a datagram: 75 (a) If the cache contains no information for a particular | 76 Destination, a determination is made where to send the 77 datagram. This is described in the "Next Hop Decision" section 78 which follows. | 80 (b) When the cache contains information for a particular | 81 Destination, the cache entry might point directly to the | 82 Destination, or to a router which handles the Destination. 84 (c) The cache entry contains the media address to be used to send | 85 the datagram. It also contains other information which records | 86 previous experience related to the Destination. | 88 (d) When the Destination is determined to be accessible through a | 89 router, the cache entry for the router is used to send the 90 datagram. The router cache entry might be duplicated in the | 91 Hop Cache, or a system of pointers could be used. In any case, | 92 the Hop Cache entry for the Destination MUST have the same | 93 LifeTime as the cache entry for the router. * 95 Each Hop Cache entry needs to include the following items: | 97 (1) LifeTime 98 (2) Next-hop interface (when a node is multi-homed) 99 (3) Next-hop media address 100 (4) Destination IPv6 Address 101 (5) Destination Cluster-prefix size 102 (6) Source IPv6 Address | 103 (7) Flow Label 104 (8) Path Maximum Transmission Unit | 105 (9) Path Round Trip Time | 107 While scanning or making changes to the Hop Cache entries, whenever | 108 the LifeTime expires in any entry that was created as a result of a 109 received advertisement, that entry is discarded. 111 Field (4) MAY be the full IPv6 Address of the Destination, or the | 112 Cluster which includes the Destination. This is determined by the 113 Cluster-prefix size in (5). 115 Field (7) SHOULD be included, as it is related to the Source in (6). | 117 DISCUSSION: 118 Each Hop Cache entry defines the end-points of an internetwork | 119 path. Although the connecting path may change dynamically in an 120 arbitrary way, the transmission characteristics of the path tend 121 to remain approximately constant over a time period longer than a 122 single typical host-host transport connection. Therefore, a Hop | 123 Cache entry is a natural place to cache data on the properties of 124 the path. 126 Examples of such properties might be the maximum unfragmented 127 datagram size, or the average round-trip delay measured by a 128 transport protocol. This data will generally be both gathered and 129 used by a higher layer protocol (that is, by TCP or by an 130 application using UDP). Experiments are currently in progress on 131 caching path properties in this manner. 133 There is no consensus on whether the Hop Cache should be keyed on | 134 destinations alone, or allow both node and Cluster addresses. 135 Those who favor the use of only node identifiers argue that: 137 (1) Redirect messages will generally result in entries keyed on 138 nodes. The simplest and most general scheme would be to 139 only use node identifiers. 141 (2) The internetwork layer may not always know the prefix-size 142 for a Cluster address in a complex environment. 144 (3) The use of only node identifiers may allow the Internet 145 architecture to be more easily extended in the future 146 without any change to the hosts. 148 The opposing view is that allowing a mixture of destination nodes | 149 and clusters in the Hop Cache: 151 (1) Saves memory space. 153 (2) Leads to a simpler data structure, easily combining the 154 cache with the tables of default and static routes. 156 (3) Provides a more useful place to cache path properties. 158 IMPLEMENTATION: 159 The cache needs to be large enough to include entries for the 160 maximum number of destinations that may be in use at one time. 162 A Hop Cache entry may also include control information used to | 163 choose an entry for replacement. This might take the form of a 164 "recently used" bit, a use count, or a last-used timestamp, for 165 example. It is recommended that it include the time of last 166 modification of the entry, for diagnostic purposes. 168 An implementation may wish to reduce the overhead of scanning | 169 the Hop Cache for every datagram to be transmitted. This may 170 be accomplished with a hash table to speed the lookup, or by 171 giving a connection-oriented transport protocol a "hint", or 172 temporary handle on the appropriate cache entry, to be passed 173 to the IP layer with each subsequent datagram. 175 A static route is typically a particular preset mapping for | 176 Destination or Cluster into a particular next-hop router. It 177 might also depend on the Type-of-Service. Static routes would 178 be setup by system administrators to override the normal 179 automatic routing mechanism, and handle exceptional situations. 180 However, any static routing information is a potential source 181 of failure as configurations change or equipment fails. 183 Although the Hop Cache, the lists of default routers, and a | 184 table of static routes are described as conceptually distinct, 185 in practice they may be combined into a single "routing table" 186 data structure. 188 2.3. Next Hop Decision 190 To decide if the destination is on an attached link, the following 191 algorithm MUST be used: 193 (a) For a multicast destination, simply pass the datagram to the 194 link-layer for any indicated interface(s). 196 (b) If no Router Advertisements have been heard, then the | 197 Destination is assumed to be on an attached link. For each | 198 interface, the Destination is located as described in the 199 "Media Address Determination" section which follows. 201 (c) If one or more Router Advertisements have been heard, the | 202 Routing-Information extension Cluster-bit indicates whether the | 203 Cluster-prefix is confined to a single link. The Destination | 204 is compared against the advertised Cluster-prefix. When there | 205 is an exact match, then the Destination is assumed to be on | 206 that specific link. The Destination is located as described in | 207 the "Media Address Determination" section which follows. | 209 (d) If one or more Router Advertisements have been heard, but the | 210 Cluster-bit is not set, or the Destination does not exactly | 211 match the advertised Cluster-prefixes, then the datagram is 212 sent to a single preferred router, as described in the "Router 213 Selection" section which follows. | 215 (e) For a multi-homed node, when one or more Router Advertisements 216 have been heard on some interfaces, but no Router 217 Advertisements have been heard on other interfaces, the | 218 datagram is duplicated, and sent to both the preferred router | 219 and all those interfaces without routers for which a peer | 220 entity is unknown. | 222 This allows a node to continue operation in the presence of 223 private or partitioned links. The correct interface will be 224 learned through the advertisements of the target node. 226 Every host MUST operate correctly in a minimal environment. For 227 example, if the host insists on finding at least one router to 228 initialize, the host will be unable to operate on an isolated link. 230 2.4. Media Address Determination 232 When the media address for a destination is unknown, the following 233 procedure is used: 235 (a) If the interface has no broadcast capability (a point-to-point | 236 link), and the peer entity is unknown, the datagram is sent on 237 that interface. No media address is needed. | 239 (b) If a virtual interface has no broadcast capability (a Frame- 240 Relay or X.25 link), the datagram is duplicated on each virtual 241 circuit for which there is no known peer entity, as if they 242 were each a separate point-to-point interface on a multi-homed 243 node. The media address used is determined by the virtual | 244 circuit setup. | 246 (c) If an interface has no multicast capability, the datagram is 247 sent as a link-layer broadcast. Note that the IPv6 Destination 248 is unchanged. | 250 (d) For an interface with multicast capability, the datagram is 251 sent as a link-layer multicast. Note that the IPv6 Destination 252 is unchanged. 254 The link-layer multicast address used is the exclusive-or of 255 every octet of the IPv6 Destination, added to the base 256 Solicited-Nodes multicast. This distributes the processing 257 load among 1/256 of the nodes, even when the nodes are not 258 attached to a prefix routed link. | 260 When there is no entry in the Hop Cache, a General Solicitation is | 261 sent immediately following the datagram, utilizing the same IPv6 | 262 Destination as the datagram. The same link-layer addressing rules of | 263 (a) to (d) apply. A Hop Cache entry is added with a LifeTime of | 264 GENERAL_SOLICITATION_INTERVAL, to inhibit sending of repeated | 265 solicitations. | 267 When there is already an entry in the Hop Cache for an unknown media 268 address, no further solicitations are sent until the cache entry 269 expires. | 271 On receipt of a unicast datagram from a unicast, broadcast or 272 multicast media address, if the IPv6 Destination does not match any 273 IPv6 IPv6 Address of the node, the datagram is silently discarded. 275 On receipt of a General Solicitation, the target node sends a General 276 Advertisement. 278 On receipt of a General Advertisement, all nodes which have a Hop | 279 Cache entry for the Source update the cache entry with the current 280 LifeTime and Media Address, and any other pertinent field values 281 implemented. 283 2.5. Router Selection 285 To decide which router to send a datagram, the following procedure is 286 used: 288 (a) Cluster-prefixes are learned from the Routing-Information 289 extension of Router Advertisements. The prefix-size is the 290 number of valid bits in the Cluster-prefix. 292 (b) The Source field of the datagram is compared to the list of | 293 Cluster-prefixes in the Router List. 295 (c) If a Cluster-prefix exactly matches the Source prefix extracted 296 by the same prefix-size, then that router is one of the 297 preferred routers for that Source. The node selects the 298 highest preference value of those matching routers. 300 (d) If there are no matching Cluster-prefixes, then there is no 301 preferred router for the Source. The node selects the highest 302 preference value among all routers. 304 (e) If that router is not the best next-hop to the Destination, | 305 that router will forward the datagram to the best next-hop, and | 306 return a Local Redirect message to the sending node. 308 (f) When the sending node receives a Local Redirect, it updates the | 309 next-hop in the appropriate Hop Cache entry, so that later | 310 datagrams to the same Destination will go directly to the best 311 next-hop. 313 Since the Cluster-prefix appropriate to the Destination address is 314 generally not known, a Network Redirect message SHOULD be treated 315 identically to a Host Redirect message. That is, the cache entry for 316 the Destination (only) would be updated (or created when an entry for 317 that node did not exist) for the new router. 319 DISCUSSION: 320 This recommendation is to protect against routers that erroneously 321 send Network Redirects for a prefix routed link, in violation of 322 the router requirements. (Do we still have the Network 323 Redirect???) 325 2.6. Dead Node Detection 327 The internetwork-layer MUST be able to detect the failure of a node | 328 that is listed in its Hop Cache. 330 Each cache entry has a LifeTime, which is obtained through the 331 Solicitation and Advertisement messages. When an entry expires, the | 332 routing availability of the Destination MUST be redetermined as if no 333 prior entry had existed. 335 Negative "advice" from other layers, such as excessive 336 retransmissions by a transport-layer protocol, or a down indication 337 from a link-layer, SHOULD be used to invalidate a cache entry. 339 Positive "advice" from other layers MUST NOT extend the LifeTime of a 340 cache entry. 342 ICMP Echo "pings" MUST NOT be used to actively check a cache entry. 344 3. Router Solicitation 346 Every IPv6 node MUST implement Router Solicitation. 348 When any node starts up, it MUST send the Router Solicitation to 349 prompt the advertisement of neighboring routers. 351 If (and only if) no advertisements from neighboring routers are 352 forthcoming, the node MAY retransmit the Router Solicitation a small 353 number of times, but then MUST desist from sending more 354 solicitations. 356 Any routers that subsequently start up, or that were not discovered 357 because of packet loss or temporary link partitioning, are eventually 358 discovered by reception of their periodic (unsolicited) 359 advertisements. Links that suffer high packet loss rates or frequent 360 partitioning are accommodated by increasing the rate of router 361 advertisements, rather than increasing the number of solicitations 362 that hosts are permitted to send. 364 3.1. Constants 366 MAX_SOLICITATIONS 3 transmissions 368 MAX_SOLICITATION_DELAY 1 second 370 ROUTER_SOLICITATION_INTERVAL 3 seconds 372 3.2. Implementation Details 374 A IPv6 node is required to transmit up to MAX_SOLICITATIONS messages 375 from any of its interfaces after any of the following events: 377 - The interface is initialized at system startup time. 379 - The interface is reinitialized after a temporary interface failure 380 or after being temporarily disabled by system management. 382 - A router has its forwarding capability turned off by system 383 management. 385 If a node chooses to send a solicitation after one of the above 386 events, it should delay transmission for a random amount of time 387 between 0 and MAX_SOLICITATION_DELAY. This serves to alleviate 388 congestion when many nodes start up on a link at the same time, such 389 as might happen after recovery from a power failure. 391 It is recommended that nodes include some unique value (such as one 392 of their interface or link-layer identifiers or addresses) in the 393 seed used to initialize their pseudo-random number generators. 394 Although the randomization range is specified in units of seconds, 395 the actual randomly-chosen value should not be in units of whole 396 seconds, but rather in units of the highest available timer 397 resolution. 399 The small number of retransmissions of a solicitation, which are 400 permitted if no advertisement is received, should be sent at 401 intervals of ROUTER_SOLICITATION_INTERVAL seconds without further 402 randomization. 404 Upon receiving a valid Router Advertisement subsequent to one of the 405 above events, the node MUST NOT send any solicitation on that 406 interface (even if no solicitation has been sent yet) until the next 407 time one of the above events occurs. 409 3.3. Validity Check 411 A non-router MUST silently discard any received Router Solicitation 412 messages. 414 A router MUST silently discard any received Router Solicitation 415 messages that do not satisfy the following validity checks: 417 - Version number is correct. 419 - ICMP Checksum is correct. 421 - ICMP length (derived from the payload length) is 16 or more 422 octets. 424 - For interfaces which are not point-to-point links, the Media- 425 Access extension MUST be present. 427 The IPv6 Source may have any unicast value, including Unknown (zero). 429 If the IPv6 Source does not match one of the router's own IPv6 430 Addresses on the arrival interface, under the Cluster-prefix 431 associated with that IPv6 Address, the sender may be considered a 432 Mobile Node. The location of every reachable Mobile Node is 433 maintained separately within the router. 435 4. Sending Router Advertisements 437 Every IPv6 router MUST implement Router Advertisements. 439 The router advertisements include such important information as a 440 Media Address for the router, other Cluster-prefixes directly 441 accessible through the router, and neighboring routers heard. 443 Identification 445 Each router advertisement includes one or more IPv6 Address 446 fields. These indicate the IPv6 Addresses which are presently in 447 use for the router. 449 Prefix Size 451 Each advertised IPv6 Address has an associated prefix-size. The 452 value ranges from 0 to 126, and indicates the number of bits in 453 the Identifier which define the Cluster-prefix for the link. A 454 value of zero indicates an end-point IPv6 Address. When the value 455 is not zero, the IPv6 Address may be used to discern Cluster- 456 prefix mapping. 458 If all advertised prefix-size values are zero, then prefix routing 459 is not in use on that link. 461 Preference 463 Each advertised IPv6 Address has an associated preference. This 464 is used by a host to choose a default router for the first-hop, 465 when the host has not yet been redirected or configured to use a 466 specific router for a particular Destination. | 468 The host is expected to choose from those routers that have the 469 highest preference level for the best Cluster-prefix match. When 470 there is no match, or prefix routing is not in use, the preference 471 value is used alone. 473 An administrator can configure router preference levels to 474 encourage or discourage the use of particular routers as the 475 default first-hop. The use of separate preferences per Cluster- 476 prefix allows the choice of different routers for each prefix, 477 when there are multiple prefixes in use for the same link. This 478 may be useful where multiple organizations share resources. 480 The preference value is not the same as the "metric" used in many 481 routing protocols. It is used only by hosts in determining the 482 default first-hop, rather than by routers in choosing a link for 483 transit traffic. The values are not additive. The range of 484 values is smaller, and a higher value indicates a higher 485 preference. 487 It should be understood that preference levels learned from router 488 advertisements do not affect any node's cached route entries. For 489 example, if a node has been redirected to use a particular router | 490 to reach a specific Destination, it continues to use that router | 491 for that Destination, even if it discovers another router with a 492 higher preference level. Preference levels influence the choice 493 of router only for a Destination for which there is no cached or | 494 configured route, or whose cached route points to a router that is 495 subsequently determined to be unreachable. 497 4.1. Constants 499 MAX_INITIAL_ADVERTISEMENTS 3 transmissions 501 MAX_INITIAL_ADVERT_INTERVAL 16 seconds 503 MAX_RESPONSE_DELAY 2 seconds 505 4.2. Configuration 507 A router MUST allow the following variables to be configured by 508 system management. Default values are specified which make it 509 unnecessary to re-configure these variables in most cases. 511 For each interface: 513 MaxAdvertisementInterval 515 The maximum time (in seconds) allowed between sending router 516 advertisements from the interface. Must be no less than 4 seconds 517 and no greater than 1800 seconds. 519 Default: 600 seconds 521 MinAdvertisementInterval 523 The minimum time (in seconds) allowed between sending unsolicited 524 router advertisements from the interface. Must be no less than 1 525 second and no greater than MaxAdvertisementInterval. 527 Default: 0.75 * MaxAdvertisementInterval 529 AdvertisementLifetime 531 The value (in seconds) to be placed in the Lifetime field of 532 router advertisements sent from the interface. Must be no less 533 than MaxAdvertisementInterval and no greater than 9000 seconds. 535 Default: 3 * MaxAdvertisementInterval 537 For each of the IPv6 Addresses of each interface: 539 Advertise 541 A flag indicating whether or not the IPv6 Address is to be 542 advertised. 544 Default: TRUE 546 PreferenceLevel 548 The preferability of the interface as a default router choice, 549 relative to other router interfaces serving the same Cluster- 550 prefix on the same link. 552 Values are in the range 0 to 255. Higher values mean more 553 preferable. The minimum value zero is reserved to indicate that 554 the IPv6 Address, even though it may be advertised, is not to be 555 used by neighboring hosts as a default router address. The 556 maximum value 255 is reserved to indicate that the preference was 557 locally configured, and not learned through advertisments. 559 Default: 128 561 It is useful to configure an IPv6 Address with a preference level of 562 zero (rather than simply setting its Advertise flag to FALSE) when 563 advertisements are being used for "black hole" detection. In 564 particular, a router that is to be used to reach only specific 565 destinations could advertise a preference level of zero (so that 566 neighboring hosts will not use it as a default router for reaching 567 arbitrary destinations) and a non-zero lifetime (so that neighboring 568 hosts that have been redirected or configured to use it can detect 569 its failure by timing out the reception of its advertisements). 571 DISCUSSION: 573 It has been suggested that, when the preference level of an IPv6 574 Address has not been explicitly configured, a router could set it 575 according to the metric of the router's "default route" (if it has 576 one), rather than defaulting as suggested above. Thus, a router 577 with a better metric for its default route would advertise a 578 higher preference level for its IPv6 Address. (Note that routing 579 metrics that are encoded such that "lower is better" would have to 580 be inverted before being used as preference levels in router 581 advertisement messages.) Such a strategy might reduce the amount 582 of redirect traffic on some links by making it more likely that 583 the host's first choice for reaching an arbitrary destination is 584 also the best choice. 586 On the other hand, redirect traffic is rarely a significant load 587 on a link, and there are some cases where such a strategy would 588 result in more redirect traffic (on links from which the most 589 frequently chosen destinations are best reached via routers other 590 than the one with the best default route). Also, since the 591 routing algorithms learn of neighboring routers from the 592 advertisements, and the default routes are learned from the 593 routing algorithms, the calculated preference may be unstable from 594 time to time. This document makes no recommendation concerning 595 this issue, and implementors are free to try such a strategy, as 596 long as they also support static configuration of preference 597 levels as specified above. 599 4.3. Implementation Details 601 The term "advertising interface" refers to any functioning and 602 enabled interface that has at least one IPv6 Address whose configured 603 Advertise flag is TRUE. 605 From each advertising interface, the router MUST transmit periodic 606 Advertisements. 608 CONTROVERSIAL: 610 A router MAY proxy for the identifers of other nodes, using the 611 Other-Identifier extension. This SHOULD only be used when the 612 router is translating to another internetwork protocol format. 614 The advertisements are not strictly periodic. The interval between 615 subsequent transmissions is randomized to reduce the probability of 616 synchronization with the advertisements from other routers on the 617 same link. This is done by maintaining a separate transmission 618 interval timer for each advertising interface. Each time an 619 advertisement is sent from an interface, that interface's timer is 620 reset to a uniformly-distributed random value between the configured 621 MinAdvertisementInterval and MaxAdvertisementInterval. Expiration of 622 the timer causes the next advertisement to be sent, and a new random 623 value to be chosen. 625 It is recommended that routers include some unique value (such as one 626 of their interface or link-layer addresses) in the seed used to 627 initialize their pseudo-random number generators. Although the 628 randomization range is configured in units of seconds, the actual 629 randomly-chosen values should not be in units of whole seconds, but 630 rather in units of the highest available timer resolution. 632 For the first few advertisements sent from an interface (up to 633 MAX_INITIAL_ADVERTISEMENTS), if the randomly chosen interval is 634 greater than MAX_INITIAL_ADVERT_INTERVAL, the timer should be set to 635 MAX_INITIAL_ADVERT_INTERVAL instead. Using this smaller interval for 636 the initial advertisements increases the likelihood of a router being 637 discovered quickly when it first becomes available, in the presence 638 of possible packet loss. 640 An interface may become an advertising interface at times other than 641 system startup, as a result of recovery from an interface failure or 642 through actions of system management such as: 644 - enabling the interface, if it had been administratively disabled 645 and it has one or more IPv6 Addresses whose Advertise flag is 646 TRUE, 648 - enabling IPv6 forwarding capability (changing the node from a host 649 to a router), when the interface has one or more IPv6 Addresses 650 whose Advertise flag is TRUE, 652 - setting the Advertise flag of one or more of the interface's IPv6 653 Addresses to TRUE (or adding a new IPv6 Address with a TRUE 654 Advertise flag), when previously the interface had no IPv6 Address 655 whose Advertise flag was TRUE. 657 In such cases, the router must commence transmission of periodic 658 advertisements on the new advertising interface, limiting the first 659 few advertisements to intervals no greater than 660 MAX_INITIAL_ADVERT_INTERVAL. In the case of a host becoming a 661 router, the node must also join the all-routers multicast group on 662 all interfaces on which the router supports multicast (whether or not 663 they are advertising interfaces). 665 An interface MAY also cease to be an advertising interface, through 666 actions of system management such as: 668 - shutting down the node, 670 - administratively disabling the interface, 672 - disabling IPv6 forwarding capability (changing the node from a 673 router to a host), 675 - setting the Advertise flags of all of the interface's IPv6 676 Addresses to FALSE. 678 In such cases, the router MUST transmit a final multicast 679 advertisement on the interface, identical to its previous 680 transmission, but with a Lifetime field of zero. In the case of a 681 router becoming a host, the node must also depart from the all- 682 routers multicast group on all interfaces on which the router 683 supports multicast (whether or not they had been advertising 684 interfaces). 686 When the Advertise flag of one or more of an interface's IPv6 687 Addresses are set to FALSE by system management, but there remain 688 other IPv6 Addresses on that interface whose Advertise flags are 689 TRUE, the router SHOULD send a single multicast advertisement 690 containing only those IPv6 Addresses whose Advertise flags were set 691 to FALSE, with a Lifetime field of zero. 693 In addition to the periodic unsolicited advertisements, a router MUST 694 send advertisements in response to valid Router Advertisements or 695 Router Solicitations received on any of its advertising interfaces. 696 If the advertisement or solicitation does not contain any System- 697 Heard extension, and the time since the previous advertisement is 698 greater than MAX_INITIAL_ADVERT_INTERVAL, the router MUST multicast 699 an advertisement from that interface. 701 Whenever these response advertisements are sent, the advertisement 702 MUST be delayed for a small random interval not greater than 703 MAX_RESPONSE_DELAY, in order to prevent synchronization with other 704 responding routers, and to allow multiple closely-spaced 705 solicitations to be answered with a single advertisement. The 706 interface's interval timer is reset to a new random value, as with 707 unsolicited advertisements. 709 4.4. Validity Check 711 All nodes MUST silently discard any received Router Advertisement 712 messages that do not satisfy the following validity checks: 714 - Version is correct. 716 - ICMP Checksum is correct. 718 - ICMP length (derived from the payload length) is 16 or more 719 octets. 721 - At least one Routing-Information extension MUST be present. 723 - For interfaces which are not point-to-point links, the Media- 724 Access extension MUST be present. 726 5. Processing Router Advertisements 728 Each router saves the information contained in the advertisements, in 729 order to respond to future requests. Any other action on receipt of 730 such messages by a router (for example, as part of a "peer discovery" 731 process) is beyond the scope of this document. 733 Each host saves the information contained in the advertisements, in 734 order to determine the next-hop when sending datagrams. Hop 735 determination is elaborated in the "Sending Datagrams" chapter. 737 5.1. Configuration 739 5.1.1. Router List 741 Host Requirements -- Communication Layers [1], Section 3.3.1.6, 742 specifies that each host must support a configurable list of default 743 routers. The purpose of the Router Advertisement messages is to 744 eliminate the need to configure that list. 746 Each entry in the list contains (at least) the following configurable 747 variables: 749 RouterAddress 751 An IPv6 Address of a default router. 753 Default: (none) 755 Prefix Size 757 Each router entry has an associated prefix-size. The value ranges 758 from 0 to 126, and indicates the number of bits in the IPv6 759 Address which define the Cluster-prefix for the link. A value of 760 zero indicates an end-point IPv6 Address. When the value is not 761 zero, the IPv6 Address may be used to discern Cluster-prefix 762 mapping. 764 If all associated prefix-size values are zero, then prefix routing 765 is not in use on that link. 767 Default: 0 769 PreferenceLevel 771 The preferability of the RouterAddress as a default router choice, 772 relative to other router interfaces serving the same Cluster- 773 prefix on the same link. Host Requirements does not specify how 774 this value is to be encoded. 776 The values used here are defined as in Router Advertisements. 777 Values are in the range 0 to 255. Higher values mean more 778 preferable. The minimum value zero is reserved to indicate that 779 the IPv6 Address, even though it may be advertised, is not to be 780 used by neighboring hosts as a default router address. The 781 maximum value 255 is reserved to indicate that the preference was 782 locally configured, and not learned through advertisments. 784 Default: 255 786 Default routers and preference levels SHOULD NOT be configured 787 manually. On links for which router discovery is administratively 788 disabled, it MAY continue to be necessary to configure the default | 789 Router List in each host. 791 5.1.2. Address List 793 Each node requires at least one IPv6 Address. 795 Each IPv6 Address is bound to zero or more interfaces. 797 Each entry in the list contains (at least) the following configurable 798 variables: 800 IPv6 Address 802 The IPv6 Address which is presently in use for the node. 804 Default: None 806 Prefix Size 808 Each IPv6 Address entry bound to a link interface has an 809 associated prefix-size. The value ranges from 0 to 126, and 810 indicates the number of bits in the IPv6 Address which define the 811 Cluster-prefix for the link. A value of zero indicates an end- 812 point IPv6 Address. When the value is not zero, the IPv6 Address 813 may be used to discern Cluster-prefix mapping. 815 If all associated prefix-size values are zero, then prefix routing 816 is not in use on that link. 818 Default: 0 820 LifeTime 822 The value (in seconds) for the time that the IPv6 Address is 823 associated with an interface. 825 Default: 0 827 The Cluster-prefix(es) for a host interface SHOULD NOT be configured 828 manually. 830 The Cluster-prefix(es) for a router interface SHOULD be configured 831 manually, until such time in the future that an automatic algorithm 832 is developed. 834 5.2. Implementation Details 836 To process an Router Advertisement, the node scans the list of 837 extensions in it. 839 5.2.1. Media-Access 841 If a Media-Access extension is present, the Router List is updated | 842 with the information. The Media-Access extension MAY appear anywhere 843 in the list of extensions, but is most likely at the beginning or 844 end. 846 5.2.2. Change-Identifier 848 Change-Identifier extensions MUST preceed Routing-Information 849 extensions. 851 - If the prefix-size is zero, the IPv6 Address indicates the change 852 of a single node, without affecting other nodes on that link. 854 - If the prefix-size is not zero, the IPv6 Address indicates the 855 change of Cluster-prefix for all nodes on that link. 857 - The IPv6 Address and prefix-size are compared against any IPv6 858 Addresses defined for the node. If there is a match, a new IPv6 859 Address is associated with the node. 861 - If the new IPv6 Address is not already present in the receiving 862 interface list, a new entry is added to the list, containing the 863 IPv6 Address, prefix-size, and the Lifetime value from the 864 advertisement. 866 - If the new IPv6 Address is already present in the receiving 867 interface list as a result of a previously-received advertisement, 868 its LifeTime is reset to the value in the newly-received 869 advertisement. 871 - If the new IPv6 Address is already present in the receiving 872 interface list as a result of static configuration, no change is 873 made. There is no LifeTime associated with a configured IPv6 874 Address. 876 The node MUST continue to accept datagrams destined for the old 877 IPv6 Address, until such time as all stimulus for maintaining the 878 old IPv6 Address has expired. This implies that the node will 879 maintain a LifeTime for most sources of IPv6 Addresses, such as 880 DNS records and dynamic configuration. 882 5.2.3. Routing-Information 884 Routing-Information extensions MUST preceed Other-Identifier 885 extensions. 887 - If the prefix-size is not zero, the IPv6 Address and prefix-size 888 are compared against any IPv6 Addresses defined for the node. If 889 there is a match, the IPv6 Address is associated with the 890 interface on which the message was received, and the prefix-size 891 is set to the advertised prefix-size. 893 - If the IPv6 Address is not already present in the Router List, a | 894 new entry is added to the list, containing the IPv6 Address along 895 with its accompanying preference level, and the Lifetime value 896 from the advertisement. 898 - If the IPv6 Address is already present in the Router List as a | 899 result of a previously-received advertisement, its preference 900 level is updated and its LifeTime is reset to the value in the 901 newly-received advertisement. 903 - If the IPv6 Address is already present in the Router List as a | 904 result of static configuration, no change is made to its 905 preference level. There is no LifeTime associated with a 906 configured IPv6 Address. 908 Note that any router IPv4 Address acquired from the "Gateway" 909 subfield of the vendor extensions field of a BOOTP packet [11] 910 are considered to be configured; they are assigned the default 911 preference level of 255, and they do not have an associated 912 LifeTime. 914 Note further that any IPv6 Address found in the "giaddr" field 915 of a BOOTP packet [3] identifies a BOOTP forwarder which is not 916 necessarily a IPv6 router; such an IPv6 Address should not be 917 installed in the default Router List. | 919 To limit the storage needed for the default Router List, the host | 920 MAY choose not to store all of the router IPv6 Addresses 921 discovered via advertisements. The host SHOULD discard those IPv6 922 Addresses with lower preference levels in favor of those with 923 higher levels. 925 It is desirable to retain more than one default router in the 926 list; if the current choice of default router is discovered to be 927 down, the host may immediately choose another default router 928 without having to wait for the next advertisement to arrive. 930 Any router IPv6 Address advertised with a preference level of zero 931 is not to be used by the host as default router IPv6 Address. | 932 Such an IPv6 Address may be omitted from the default Router List, 933 unless its LifeTime is being used as a "black-hole" detection 934 mechanism. 936 5.2.4. Other-Identifier 938 The Other-Identifier extension is used to indicate IPv6 Addresses 939 which have no effect on the interface Cluster-prefix. 941 - If the IPv6 Address is not already present in the Router List, a | 942 new entry is added to the list, containing the IPv6 Address, the 943 preference level set to zero, and the Lifetime value from the 944 advertisement. 946 - If the IPv6 Address is already present in the Router List as a | 947 result of a previously-received advertisement, and its preference 948 level is zero, its LifeTime is reset to the value in the newly- 949 received advertisement. 951 - If the IPv6 Address is already present in the Router List as a | 952 result of static configuration, no change is made to its 953 preference level. There is no LifeTime associated with a 954 configured IPv6 Address. 956 To limit the storage needed for the default Router List, the host | 957 MAY choose not to store all of the other IPv6 Addresses discovered 958 via advertisements. The most preferred router is used for unknown 959 IPv6 Addresses, and it will send a redirect when appropriate. 961 5.2.5. System-Heard 963 The use of the System-Heard extension is described in a future Mobile 964 Discovery document. 966 A. Configuration Summary 968 Routers 970 A router requires at least one IPv6 Address to be configured. 972 For each interface, a prefix-size is assigned to each IPv6 973 Address, unless automatic prefix discovery is in place. 975 Note that this procedure minimizes the number of items to be 976 configured, and possible configuration errors. 978 Optionally, other values MAY be altered from their defaults, such 979 as preference and advertisement lifetime. 981 Optionally, routing protocols MAY require additional values to be 982 configured, such as metric and priority. Such functions are 983 beyond the scope of this document. 985 Hosts 987 Most hosts need no prior configuration. 989 A node attached to a multi-access media creates a local-use 990 unicast address from the media address. 992 A node attached to a point-to-point media (using the Point-to- 993 Point Protocol [RFC-1661]) can be dynamically assigned either a 994 global or local unicast address. 996 Other nodes require configuration of an IPv6 Address, as described 997 in the section "Address List". 999 When a router is present, a local-use unicast address MAY be 1000 combined with a Cluster address learned from Router Advertisements 1001 to form a routable IPv6 Address. 1003 Security Considerations 1005 Security issues are not discussed in this memo. 1007 Acknowledgements 1009 The document was initially composed of quotations from the RFC-1122 1010 "Requirements for Internet Hosts -- Communication Layers", and RFC- 1011 1256 "ICMP Router Discovery Messages". 1013 Author's Address 1015 Questions about this memo can also be directed to: 1017 William Allen Simpson 1018 Daydreamer 1019 Computer Systems Consulting Services 1020 1384 Fontaine 1021 Madison Heights, Michigan 48071 1023 Bill.Simpson@um.cc.umich.edu 1024 bsimpson@MorningStar.com 1025 Table of Contents 1027 1. Introduction .......................................... 1 1029 2. Sending Datagrams ..................................... 1 1030 2.1 Constants ....................................... 1 1031 2.2 Hop Cache ....................................... 1 1032 2.3 Next Hop Decision ............................... 4 1033 2.4 Media Address Determination ..................... 5 1034 2.5 Router Selection ................................ 6 1035 2.6 Dead Node Detection ............................. 7 1037 3. Router Solicitation ................................... 8 1038 3.1 Constants ....................................... 8 1039 3.2 Implementation Details .......................... 8 1040 3.3 Validity Check .................................. 9 1042 4. Sending Router Advertisements ......................... 10 1043 4.1 Constants ....................................... 11 1044 4.2 Configuration ................................... 11 1045 4.3 Implementation Details .......................... 13 1046 4.4 Validity Check .................................. 15 1048 5. Processing Router Advertisements ...................... 17 1049 5.1 Configuration ................................... 17 1050 5.1.1 Router List ..................................... 17 1051 5.1.2 Address List .................................... 18 1052 5.2 Implementation Details .......................... 19 1053 5.2.1 Media-Access .................................... 19 1054 5.2.2 Change-Identifier ............................... 19 1055 5.2.3 Routing-Information ............................. 20 1056 5.2.4 Other-Identifier ................................ 21 1057 5.2.5 System-Heard .................................... 22 1059 APPENDICES ................................................... 23 1061 A. Configuration Summary ................................. 23 1063 SECURITY CONSIDERATIONS ...................................... 24 1065 ACKNOWLEDGEMENTS ............................................. 24 1067 AUTHOR'S ADDRESS ............................................. 24