idnits 2.17.1 draft-ietf-ipv6-router-selection-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 2 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 5 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (June 10, 2002) is 7991 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? '1' on line 14 looks like a reference -- Missing reference section? '2' on line 563 looks like a reference -- Missing reference section? '3' on line 85 looks like a reference -- Missing reference section? '4' on line 85 looks like a reference -- Missing reference section? '5' on line 95 looks like a reference -- Missing reference section? '6' on line 121 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group R. Draves 3 Internet Draft Microsoft Research 4 Document: draft-ietf-ipv6-router-selection-02.txt R. Hinden 5 Nokia 6 June 10, 2002 8 Default Router Preferences, More-Specific Routes, and Load Sharing 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC 2026 [1]. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six 21 months and may be updated, replaced, or obsoleted by other documents 22 at any time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 Abstract 33 This document describes two changes to Neighbor Discovery. The first 34 change is an optional extension to Router Advertisement messages for 35 communicating default router preferences and more-specific routes 36 from routers to hosts. This improves the ability of hosts to pick an 37 appropriate router, especially when the host is multi-homed and the 38 routers are on different links. The preference values and specific 39 routes advertised to hosts require administrative configuration; 40 they are not automatically derived from routing tables. The second 41 change is a mandatory modification of the conceptual sending 42 algorithm to support load-sharing among equivalent routers. 44 1. Introduction 46 Neighbor Discovery [2] specifies a conceptual model for hosts that 47 includes a Default Router List and a Prefix List. Hosts send Router 48 Solicitation messages and receive Router Advertisement messages from 49 routers. Hosts populate their Default Router List and Prefix List 50 based on information in the Router Advertisement messages. A 51 conceptual sending algorithm uses the Prefix List to determine if a 52 destination address is on-link and the Default Router List to select 53 a router for off-link destinations. 55 In some network topologies where the host has multiple routers on 56 its Default Router List, the choice of router for an off-link 57 destination is important. In some situations, one router may provide 58 much better performance than another for a destination. In other 59 situations, choosing the wrong router may result in a failure to 60 communicate. (A later section gives specific examples of these 61 scenarios.) 63 This document describes an optional extension to Neighbor Discovery 64 Router Advertisement messages for communicating default router 65 preferences and more-specific routes from routers to hosts. This 66 improves the ability of hosts to pick an appropriate router for an 67 off-link destination. 69 Neighbor Discovery provides a Redirect message that routers can use 70 to correct a host's choice of router. A router can send a Redirect 71 message to a host, telling it to use a different router for a 72 specific destination. However, the Redirect functionality is limited 73 to a single link. A router on one link cannot redirect a host to a 74 router on another link. Hence, Redirect messages do not help multi- 75 homed hosts select an appropriate router. 77 Multi-homed hosts are an increasingly important scenario, especially 78 with IPv6. In addition to a wired network connection, like Ethernet, 79 hosts may have one or more wireless connections, like 802.11 or 80 Bluetooth. In addition to physical network connections, hosts may 81 have virtual or tunnel network connections. For example, in addition 82 to a direct connection to the public Internet, a host may have a 83 tunnel into a private corporate network. Some IPv6 transition 84 scenarios can add additional tunnels. For example, hosts may have 85 6-over-4 [3] or configured tunnel [4] network connections. 87 This document requires that the preference values and specific 88 routes advertised to hosts require explicit administrative 89 configuration. They are not automatically derived from routing 90 tables. In particular, the preference values are not routing metrics 91 and it is not recommended that routers "dump out" their entire 92 routing tables to hosts. 94 We use Router Advertisement messages, instead of some other protocol 95 like RIP [5], because Router Advertisements are an existing 96 standard, stable protocol for router-to-host communication. 97 Piggybacking this information on existing message traffic from 98 routers to hosts reduces network overhead. Neighbor Discovery is to 99 unicast routing as Multicast Listener Discovery is to multicast 100 routing. In both cases, a single simple protocol insulates the host 101 from the variety of router-to-router protocols. In addition, RIP is 102 unsuitable because it does not carry route lifetimes so it requires 103 frequent message traffic with greater processing overheads. 105 This document also describes a mandatory change in host behavior. 106 Neighbor Discovery�s conceptual sending algorithm is modified to 107 require hosts to select randomly among equivalent routers. This 108 distributes traffic to different destinations among the routers. 109 Traffic to a single destination continues to use a single router, 110 because of the Destination Cache. 112 The mechanisms specified here are backwards-compatible, so that 113 hosts that do not implement them continue to function as well as 114 they did previously. 116 1.1. Conventions used in this document 118 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 119 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 120 this document are to be interpreted as described in RFC-2119 [6]. 122 2. Message Formats 124 2.1. Preference Values 126 Default router preferences and preferences for more-specific routes 127 are encoded the same way. 129 Preference values are encoded in two bits, as follows: 130 01 High 131 00 Medium (default) 132 11 Low 133 10 Reserved - MUST NOT be sent 134 Note that implementations can treat the value as a two-bit signed 135 integer. 137 Having just three values reinforces that they are not metrics and 138 more values does not appear to be necessary for reasonable 139 scenarios. 141 2.2. Changes to Router Advertisement Message Format 143 The changes from Neighbor Discovery [2] section 4.2 are as follows: 145 0 1 2 3 146 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Type | Code | Checksum | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Reachable Time | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Retrans Timer | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Options ... 157 +-+-+-+-+-+-+-+-+-+-+-+- 159 Fields: 161 Prf (Default Router Preference) 162 2-bit signed integer. Indicates whether or not to prefer 163 this router over other default routers. If Router 164 Lifetime is zero, it MUST be initialized to zero by the 165 sender and MUST be ignored by the receiver. If the 166 Reserved (10) value is received, the receiver should 167 treat the RA as having a zero Router Lifetime. 169 Resvd (Reserved) 170 A 3-bit unused field. It MUST be initialized to zero by 171 the sender and MUST be ignored by the receiver. 173 Possible Options: 175 Route Information 176 These options specify prefixes that are reachable via 177 the router. 179 Discussion: 181 Note that in addition to the preference value in the message header, 182 a Router Advertisement can also contain a Route Information Option 183 for ::/0, with a preference value and lifetime. Encoding a 184 preference value in the Router Advertisement header has some 185 advantages: 187 1. It allows for a distinction between "best default router" and 188 "best router for default", as described below in section 5.1. 190 2. When the best default router is also the best router for 191 default (which will be a common case), encoding the preference 192 value in the message header is more efficient than having to send 193 a separate option. 195 2.3. Route Information Option 197 0 1 2 3 198 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Route Lifetime | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | | 205 + + 206 | | 207 + Prefix + 208 | | 209 + + 210 | | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 Fields: 215 Type TBD 217 Length 8-bit unsigned integer. The length of the option 218 (including the Type and Length fields) in units of 219 8 octets. 221 Prefix Length 222 8-bit unsigned integer. The number of leading bits in 223 the Prefix that are valid. The value ranges from 0 to 224 128. 226 Prf (Route Preference) 227 2-bit signed integer. Indicates whether or not to prefer 228 this router for the prefix over others. If the Reserved 229 (10) value is received, the Route Information Option 230 MUST be ignored. 232 Resvd (Reserved) 233 Two 3-bit unused fields. They MUST be initialized to 234 zero by the sender and MUST be ignored by the receiver. 236 Route Lifetime 237 32-bit unsigned integer. The length of time in seconds 238 (relative to the time the packet is sent) that the 239 prefix is valid for route determination. A value of all 240 one bits (0xffffffff) represents infinity. 242 Prefix Variable-length field containing an IP address or a 243 prefix of an IP address. The Prefix Length field 244 contains the number of valid leading bits in the prefix. 245 The bits in the prefix after the prefix length (if any) 246 are reserved and MUST be initialized to zero by the 247 sender and ignored by the receiver. 249 The Length field is 1, 2, or 3 depending on Prefix Length. If Prefix 250 Length is greater than 64, then Length must be 3. If Prefix Length 251 is greater than 0, then Length must be 2 or 3. If Prefix Length is 252 zero, then Length must be 1, 2, or 3. 254 The Prefix field is 0, 8, or 16 octets depending on Length. 256 Routers SHOULD NOT include in a Router Advertisement two Route 257 Information Options with the same Prefix and Prefix Length. If a 258 host processes a Router Advertisement carrying multiple Router 259 Information Options with the same Prefix and Prefix Length, it MUST 260 process one of the options (unspecified which one) and it MUST 261 effectively ignore the rest. It MUST NOT retain some information 262 (like preference) from one option and other information (like 263 lifetime) from another option. 265 Discussion: 267 There are several reasons for using a new Route Information Option, 268 instead of using flag bits to overload the existing Prefix 269 Information Option: 271 1. Prefixes will typically only show up in one or the other kind 272 of option, not both, so a new option does not introduce 273 duplication. 275 2. The Route Information Option is typically 16 octets while the 276 Prefix Information Option is 32 octets. 278 3. Using a new option may improve backwards-compatibility with 279 some host implementations. 281 3. Conceptual Model of a Host 283 There are three possible conceptual models for host implementation 284 of default router preferences and more-specific routes, 285 corresponding to different levels of support. We refer to these as 286 host A, host B, and host C. Note that these are really classes of 287 hosts, not individual hosts. 289 3.1. Conceptual Data Structures for Hosts 291 Host A ignores default router preferences and more-specific routes. 292 Host A uses the conceptual data structures described in Neighbor 293 Discovery [2]. 295 Host B uses a Default Router List augmented with preference values. 296 Host B does not have a routing table. Host B uses the Default Router 297 Preference value in the Router Advertisement header. Host B ignores 298 Route Information Options. 300 Host C uses a Routing Table instead of a Default Router List. (The 301 Routing Table may also subsume the Prefix List, but that is beyond 302 the scope of this document.) Entries in the Routing Table have a 303 prefix, prefix length, preference value, lifetime, and next-hop 304 router. Host C uses both the Default Router Preference value in the 305 Router Advertisement header and Route Information Options. 307 When host C receives a Router Advertisement, it modifies its Routing 308 Table as follows. If the received route's lifetime is zero, the 309 route is removed from the Routing Table if present. If a route's 310 lifetime is non-zero, the route is added to the Routing Table if not 311 present and the route's lifetime and preference is updated if the 312 route is already present. A route is located in the Routing Table 313 based on prefix, prefix length, and next-hop router. When processing 314 a Router Advertisement, host C first updates a ::/0 route based on 315 the Router Lifetime and Default Router Preference in the Router 316 Advertisement message header. Then as host C processes Route 317 Information Options in the Router Advertisement message body, it 318 updates its routing table for each such option. The Router 319 Preference and Lifetime values in a ::/0 Route Information Option 320 override the preference and lifetime values in the Router 321 Advertisement header. 323 For example, suppose a host receives a Router Advertisement from 324 router X with a Router Lifetime of 100 seconds and Default Router 325 Preference of Medium. The body of the Router Advertisement contains 326 a Route Information Option for ::/0 with a Route Lifetime of 200 327 seconds and a Route Preference of Low. After processing the Router 328 Advertisement, host A will have an entry for router X in its Default 329 Router List with lifetime 100 seconds. If host B receives the same 330 Router Advertisement, it will have an entry in its Default Router 331 List for router X with Medium preference and lifetime 100 seconds. 332 Host C will have an entry in its Routing Table for ::/0 -> router X, 333 with Low preference and lifetime 200 seconds. Host C MAY have a 334 transient state, during processing of the Router Advertisement, in 335 which it has an entry in its Routing Table for ::/0 -> router X with 336 Medium preference and lifetime 100 seconds. 338 3.2. Conceptual Sending Algorithm for Hosts 340 Host A uses the conceptual sending algorithm described in Neighbor 341 Discovery [2], modified slightly to support load sharing as 342 described in section 3.5. 344 When host B does next-hop determination and consults its Default 345 Router List, it primarily prefers reachable routers over non- 346 reachable routers and secondarily uses the router preference values. 348 When host C does next-hop determination and consults its Routing 349 Table for an off-link destination, it first prefers reachable 350 routers over non-reachable routers, second uses longest-matching- 351 prefix, and third uses route preference values. 353 If there are no routes matching the destination (i.e., no default 354 routes and no more-specific routes), then if host C has a single 355 interface then it SHOULD assume the destination is on-link to that 356 interface. If host C has multiple interfaces then it SHOULD discard 357 the packet and report a Destination Unreachable / No Route To 358 Destination error to the upper layer. 360 3.3. Destination Cache Management 362 When host C processes a Router Advertisement and updates its 363 conceptual Routing Table, it SHOULD invalidate or remove Destination 364 Cache Entries and redo next-hop determination for destinations 365 affected by the Routing Table changes. The host MAY implement this 366 requirement by flushing its entire Destination Cache. 368 3.4. Router Reachability Probing 370 When a host avoids using a non-reachable router X and instead uses 371 another router Y, and the host would have used router X if router X 372 were reachable, then the host SHOULD probe router X's reachability 373 by sending a Neighbor Solicitation. A host MUST NOT probe a router's 374 reachability in the absence of useful traffic that the host would 375 have sent to the router if it were reachable. In any case, these 376 probes MUST be rate-limited to no more than one per minute per 377 router. 379 This requirement allows the host to discover when router X becomes 380 reachable and to start using router X at that point. Otherwise, the 381 host might not notice router X�s reachability and continue to use 382 the less-desirable router Y. 384 3.5. Host Load Sharing 386 Sometimes a host has a choice of multiple "equivalent" routers for a 387 destination. We say that two routers are equivalent for a 388 destination if they have the same reachability, the same matching 389 prefix length (if the host supports a Routing Table), and the same 390 preference values (if the host supports preference values). 392 When a host chooses from multiple equivalent routers, it MUST choose 393 randomly. 395 This has the effect of distributing load for new destinations among 396 the equivalent routers. Note that traffic to a single destination 397 will use a single router as long as the Destination Cache Entry for 398 the destination is not deleted. Random selection, instead of round- 399 robin, is used to avoid synchronization issues. 401 3.6. Example 403 For example: suppose host C has five entries in its Routing Table: 404 ::/0 -> router W with Medium preference 405 2001::/16 -> router X with Medium preference 406 3ffe::/16 -> router Y1 with High preference 407 3ffe::/16 -> router Y2 with High preference 408 3ffe::/16 -> router Z with Low preference 409 and host C is sending to 3ffe::1, an off-link destination. If all 410 routers are reachable, then the host will choose randomly between 411 routers Y1 and Y2. If routers Y1 and Y2 are not reachable, then 412 router Z will be chosen and the reachability of routers Y1 and Y2 413 will be probed. If routers Y1, Y2, and Z are not reachable, then 414 router W will be chosen and the reachability of routers Y1, Y2, and 415 Z will be probed. If routers W, Y1, Y2, and Z are all not reachable, 416 then host C should round-robin among Y1 and Y2 while probing the 417 reachability of W and Z. Router X will never be chosen because its 418 prefix does not match the destination. 420 4. Router Configuration 422 Routers should not advertise preferences or routes by default. In 423 particular, they should not "dump out" their entire routing table to 424 hosts. Routers MAY have a configuration mode where a filter is 425 applied to their routing table to obtain the routes that are 426 advertised to hosts. 428 The preference values (both Default Router Preferences and Route 429 Preferences) should not be routing metrics or automatically derived 430 from metrics: the preference values should be configured. The High 431 and Low (non-default) preference values should only be used when 432 someone with knowledge of both routers and the network topology 433 configures them explicitly. For example, it could be a common 434 network administrator, or it could be a customer request to 435 different administrators managing the routers. 437 As one exception to this general rule, the administrator of a router 438 that does not have a connection to the internet, or is connected 439 through a firewall that blocks general traffic, may configure the 440 router to advertise a Low Default Router Preference. 442 An administrator of a router may configure the router to advertise 443 specific routes for directly connected subnets and any shorter 444 prefixes (eg, site, NLA, or TLA prefixes) for networks to which the 445 router belongs. 447 For example, if a home user sets up a tunnel into a firewalled 448 corporate network, the access router on the corporate network end of 449 the tunnel can advertise itself as a default router, but with a Low 450 preference. Furthermore the corporate router can advertise a 451 specific route for the corporate site prefix. The net result is that 452 destinations in the corporate network will be reached via the 453 tunnel, and general internet destinations will be reached via the 454 home ISP. Without these mechanisms, the home machine might choose to 455 send internet traffic into the corporate network or corporate 456 traffic into the internet, leading to communication failure because 457 of the firewall. 459 Routers SHOULD NOT send more than 17 Route Information Options in 460 Router Advertisements per link. This arbitrary bound is meant to 461 reinforce that relatively few and carefully selected routes should 462 be advertised to hosts. 464 5. Examples 466 5.1. Best Default Router vs Best Route for Default 468 The best default router is not quite the same thing as the best 469 router for default. The best default router is the router that will 470 generate the fewest number of redirects for the host's traffic. The 471 best router for default is the router with the best route toward the 472 wider internet. 474 For example, suppose a situation where you have a link with two 475 routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 476 site gateway.) Router Y is the best for ::/0. (It connects to the 477 native IPv6 internet.) Router X forwards native IPv6 traffic to 478 router Y; router Y forwards 6to4 traffic to router X. But most 479 traffic from this site is sent to 2002:/16 destinations. In this 480 scenario, router X is the best default router and router Y is the 481 best router for default. 483 To make host A work well, both routers should advertise themselves 484 as default routers. In particular, if router Y goes down host A 485 should send traffic to router X to maintain 6to4 connectivity, so 486 router X as well as router Y needs to be a default router. 487 To make host B work well, router X should in addition advertise 488 itself with a High default router preference. This will cause host B 489 to prefer router X, minimizing the number of redirects. 491 To make host C work well, router X should in addition advertise the 492 ::/0 route with Low preference and the 2002::/16 route with Medium 493 preference. Host C will end up with three routes in its routing 494 table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 495 -> router X (Medium). It will send 6to4 traffic to router X and 496 other traffic to router Y. Host C will not cause any redirects. 498 Note that when host C processes the Router Advertisement from router 499 X, the Low preference for ::/0 overrides the High default router 500 preference. If the ::/0 specific route were not present, then host C 501 would apply the High default router preference to its ::/0 route to 502 router X. 504 5.2. Multi-Homed Host and Isolated Network 506 Here's another scenario: a multi-homed host is connected to the 507 6bone/internet via router X on one link and to an isolated network 508 via router Y on another link. The multi-homed host might have a 509 tunnel into a fire-walled corporate network, or it might be directly 510 connected to an isolated test network. 512 In this situation, a multi-homed host A (which has no default router 513 preferences or more-specific routes) will have no way to choose 514 between the two routers X and Y on its Default Router List. Users of 515 the host will see unpredictable connectivity failures, depending on 516 the destination address and the choice of router. 518 A multi-homed host C in this same situation can correctly choose 519 between routers X and Y, if the routers are configured 520 appropriately. For example, router X on the isolated network should 521 advertise a Route Information Option for the isolated network 522 prefix. It might not advertise itself as a default router at all 523 (zero Router Lifetime), or it might advertise itself as a default 524 router with Low preference. Router Y should advertise itself as a 525 default router with Medium preference. 527 6. Security Considerations 529 A malicious node could send Router Advertisement messages, 530 specifying High Default Router Preference or carrying specific 531 routes, with the effect of pulling traffic away from legitimate 532 routers. However, a malicious node could easily achieve this same 533 effect in other ways. For example, it could fabricate Router 534 Advertisement messages with zero Router Lifetime from the other 535 routers, causing hosts to stop using the other routes. Hence, this 536 document has no new appreciable impact on Internet infrastructure 537 security. 539 References 541 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 542 9, RFC 2026, October 1996. 544 2 T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP 545 Version 6 (IPv6)", RFC 2461, December 1998. 547 3 B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 548 Clouds", RFC 3056, February 2001. 550 4 R. Gilligan, E. Nordmark. "Transition Mechanisms for IPv6 Hosts 551 and Routers", RFC 1933, April 1996. 553 5 G. Malkin, R. Minnear. "RIPng for IPv6", RFC 2080 , January 1997. 555 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement 556 Levels", BCP 14, RFC 2119, March 1997. 558 Acknowledgments 560 The authors would like to acknowledge the contributions of Balash 561 Akbari, Steve Deering, Robert Elz, Tony Hain, Christian Huitema, 562 JINMEI Tatuya, Erik Nordmark, Pekka Savola, Dave Thaler, and Brian 563 Zill. The packet diagrams are derived from Neighbor Discovery [2]. 564 The description of host load sharing is derived from Bob Hinden's 565 draft on the subject. 567 Author's Addresses 569 Richard Draves 570 Microsoft Research 571 One Microsoft Way 572 Redmond, WA 98052 573 Phone: +1 425 706 2268 574 Email: richdr@microsoft.com 576 Robert M. Hinden 577 Nokia 578 313 Fairchild Drive 579 Mountain View, CA 94043 580 Phone: +1 650 625 2004 581 Email: hinden@iprg.nokia.com 582 Revision History 584 Changes from draft-ietf-ipv6-router-selection-01 586 Added Bob Hinden as co-author. 588 Various clarifications and textual improvements. 590 Slightly simplified the specification of round-robining in next-hop 591 determination, relying on router-reachability probing in some cases. 593 Clarified that router reachability probing only happens when the 594 host is sending packets that would have gone to that router if it 595 were reachable. 597 Changed load sharing to a mandatory requirement and added supporting 598 text to the title, abstract, and introduction. 600 Changes from draft-ietf-ipngwg-router-selection-00 602 Specified reachability probing of otherwise more-preferred but 603 currently unreachable routers. 605 Changed the requirement of Destination Cache invalidation, from MAY 606 to SHOULD, but allowing flushing of the entire Destination Cache. 608 Added a section specifying load sharing among equivalent routers. 610 Changes from draft-draves-ipngwg-router-selection-01 612 Specified receiver processing when the Reserved preference value is 613 seen. 615 Specified that routers SHOULD NOT send more than 17 Route 616 Information Options. 618 Added discussion of Destination Cache invalidation, allowing but not 619 requiring it. 621 Removed references to the fourth conceptual host model, host D. 623 Changes from draft-draves-ipngwg-router-selection-00 625 Made the option variable length. Must ignore prefix bits past prefix 626 length. 628 Added more allowable router configuration scenarios, weakening the 629 requirement that one administrator must coordinate the configuration 630 of all relevant routers. 632 Full Copyright Statement 634 Copyright (C) The Internet Society (2000). All Rights Reserved. 636 This document and translations of it may be copied and furnished to 637 others, and derivative works that comment on or otherwise explain it 638 or assist in its implementation may be prepared, copied, published 639 and distributed, in whole or in part, without restriction of any 640 kind, provided that the above copyright notice and this paragraph 641 are included on all such copies and derivative works. However, this 642 document itself may not be modified in any way, such as by removing 643 the copyright notice or references to the Internet Society or other 644 Internet organizations, except as needed for the purpose of 645 developing Internet standards in which case the procedures for 646 copyrights defined in the Internet Standards process must be 647 followed, or as required to translate it into languages other than 648 English. 650 The limited permissions granted above are perpetual and will not be 651 revoked by the Internet Society or its successors or assigns. 653 This document and the information contained herein is provided on an 654 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 655 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 656 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 657 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 658 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.