idnits 2.17.1 draft-ietf-ipv6-router-selection-03.txt: -(343): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 3 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.) ** There are 3 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 (December 16, 2003) is 7437 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) ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 1933 (Obsoleted by RFC 2893) Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group R. Draves 3 Internet Draft D. Thaler 4 Document: draft-ietf-ipv6-router-selection-03.txt Microsoft 5 December 16, 2003 7 Default Router Preferences and More-Specific Routes 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC 2026. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that 16 other groups may also distribute working documents as Internet- 17 Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six 20 months and may be updated, replaced, or obsoleted by other documents 21 at any time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 The list of current Internet-Drafts can be accessed at 25 http://www.ietf.org/ietf/1id-abstracts.txt. 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes an optional extension to Router 33 Advertisement messages for communicating default router preferences 34 and more-specific routes from routers to hosts. This improves the 35 ability of hosts to pick an appropriate router, especially when the 36 host is multi-homed and the routers are on different links. The 37 preference values and specific routes advertised to hosts require 38 administrative configuration; they are not automatically derived 39 from routing tables. 41 1. Introduction 43 Neighbor Discovery [RFC2461] specifies a conceptual model for hosts 44 that includes a Default Router List and a Prefix List. Hosts send 45 Router Solicitation messages and receive Router Advertisement 46 messages from routers. Hosts populate their Default Router List and 47 Prefix List based on information in the Router Advertisement 48 messages. A conceptual sending algorithm uses the Prefix List to 49 determine if a destination address is on-link and the Default Router 50 List to select a router for off-link destinations. 52 In some network topologies where the host has multiple routers on 53 its Default Router List, the choice of router for an off-link 54 destination is important. In some situations, one router may provide 55 much better performance than another for a destination. In other 56 situations, choosing the wrong router may result in a failure to 57 communicate. (A later section gives specific examples of these 58 scenarios.) 60 This document describes an optional extension to Neighbor Discovery 61 Router Advertisement messages for communicating default router 62 preferences and more-specific routes from routers to hosts. This 63 improves the ability of hosts to pick an appropriate router for an 64 off-link destination. 66 Neighbor Discovery provides a Redirect message that routers can use 67 to correct a host's choice of router. A router can send a Redirect 68 message to a host, telling it to use a different router for a 69 specific destination. However, the Redirect functionality is limited 70 to a single link. A router on one link cannot redirect a host to a 71 router on another link. Hence, Redirect messages do not help multi- 72 homed hosts select an appropriate router. 74 Multi-homed hosts are an increasingly important scenario, especially 75 with IPv6. In addition to a wired network connection, like Ethernet, 76 hosts may have one or more wireless connections, like 802.11 or 77 Bluetooth. In addition to physical network connections, hosts may 78 have virtual or tunnel network connections. For example, in addition 79 to a direct connection to the public Internet, a host may have a 80 tunnel into a private corporate network. Some IPv6 transition 81 scenarios can add additional tunnels. For example, hosts may have 82 6-over-4 [RFC3056] or configured tunnel [RFC1933] network 83 connections. 85 This document requires that the preference values and specific 86 routes advertised to hosts require explicit administrative 87 configuration. They are not automatically derived from routing 88 tables. In particular, the preference values are not routing metrics 89 and it is not recommended that routers "dump out" their entire 90 routing tables to hosts. 92 We use Router Advertisement messages, instead of some other protocol 93 like RIP [RFC2080], because Router Advertisements are an existing 94 standard, stable protocol for router-to-host communication. 95 Piggybacking this information on existing message traffic from 96 routers to hosts reduces network overhead. Neighbor Discovery shares 97 with Multicast Listener Discovery the property that they both define 98 host-to-router interactions, while shielding the host from having to 99 participate in more general router-to-router interactions. In 100 addition, RIP is unsuitable because it does not carry route 101 lifetimes so it requires frequent message traffic with greater 102 processing overheads. 104 The mechanisms specified here are backwards-compatible, so that 105 hosts that do not implement them continue to function as well as 106 they did previously. 108 1.1. Conventions used in this document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 112 this document are to be interpreted as described in [RFC2119]. 114 2. Message Formats 116 2.1. Preference Values 118 Default router preferences and preferences for more-specific routes 119 are encoded the same way. 121 Preference values are encoded in two bits, as follows: 122 01 High 123 00 Medium (default) 124 11 Low 125 10 Reserved - MUST NOT be sent 126 Note that implementations can treat the value as a two-bit signed 127 integer. 129 Having just three values reinforces that they are not metrics and 130 more values do not appear to be necessary for reasonable scenarios. 132 2.2. Changes to Router Advertisement Message Format 134 The changes from Neighbor Discovery [RFC2461] section 4.2 are as 135 follows: 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 | Type | Code | Checksum | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Reachable Time | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | Retrans Timer | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | Options ... 149 +-+-+-+-+-+-+-+-+-+-+-+- 151 Fields: 153 Prf (Default Router Preference) 154 2-bit signed integer. Indicates whether or not to prefer 155 this router over other default routers. If Router 156 Lifetime is zero, it MUST be initialized to zero by the 157 sender and MUST be ignored by the receiver. If the 158 Reserved (10) value is received, the receiver MUST treat 159 the treat the value as if it had the value 00. 161 Resvd (Reserved) 162 A 3-bit unused field. It MUST be initialized to zero by 163 the sender and MUST be ignored by the receiver. 165 Possible Options: 167 Route Information 168 These options specify prefixes that are reachable via 169 the router. 171 Discussion: 173 Note that in addition to the preference value in the message header, 174 a Router Advertisement can also contain a Route Information Option 175 for ::/0, with a preference value and lifetime. Encoding a 176 preference value in the Router Advertisement header has some 177 advantages: 179 1. It allows for a distinction between the "best router for the 180 default route" and the "router least likely to redirect common 181 traffic", as described below in section 5.1. 183 2. When the best router for the default route is also the router 184 least likely to redirect common traffic (which will be a common 185 case), encoding the preference value in the message header is more 186 efficient than having to send a separate option. 188 2.3. Route Information Option 190 0 1 2 3 191 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 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Route Lifetime | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Prefix (Variable Length) | 198 . . 199 . . 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 Fields: 204 Type TBD 206 Length 8-bit unsigned integer. The length of the option 207 (including the Type and Length fields) in units of 208 8 octets. The Length field is 1, 2, or 3 depending on 209 Prefix Length. If Prefix Length is greater than 64, then 210 Length must be 3. If Prefix Length is greater than 0, 211 then Length must be 2 or 3. If Prefix Length is zero, 212 then Length must be 1, 2, or 3. 214 Prefix Length 215 8-bit unsigned integer. The number of leading bits in 216 the Prefix that are valid. The value ranges from 0 to 217 128. The Prefix field is 0, 8, or 16 octets depending on 218 Length. 220 Prf (Route Preference) 221 2-bit signed integer. The Route Preference indicates 222 whether to prefer the router associated with this prefix 223 over others, when multiple identical prefixes (for 224 different routers) have been received. If the Reserved 225 (10) value is received, the Route Information Option 226 MUST be ignored. 228 Resvd (Reserved) 229 Two 3-bit unused fields. They MUST be initialized to 230 zero by the sender and MUST be ignored by the receiver. 232 Route Lifetime 233 32-bit unsigned integer. The length of time in seconds 234 (relative to the time the packet is sent) that the 235 prefix is valid for route determination. A value of all 236 one bits (0xffffffff) represents infinity. 238 Prefix Variable-length field containing an IP address or a 239 prefix of an IP address. The Prefix Length field 240 contains the number of valid leading bits in the prefix. 241 The bits in the prefix after the prefix length (if any) 242 are reserved and MUST be initialized to zero by the 243 sender and ignored by the receiver. 245 Routers MUST NOT include two Route Information Options with the same 246 Prefix and Prefix Length in the same Router Advertisement. If a host 247 processes a Router Advertisement carrying multiple Router 248 Information Options with the same Prefix and Prefix Length, it MUST 249 process one of the options (unspecified which one) and it MUST 250 effectively ignore the rest. It MUST NOT retain some information 251 (like preference) from one option and other information (like 252 lifetime) from another option. 254 Discussion: 256 There are several reasons for using a new Route Information Option, 257 instead of using flag bits to overload the existing Prefix 258 Information Option: 260 1. Prefixes will typically only show up in one or the other kind 261 of option, not both, so a new option does not introduce 262 duplication. 264 2. The Route Information Option is typically 16 octets while the 265 Prefix Information Option is 32 octets. 267 3. Using a new option may improve backwards-compatibility with 268 some host implementations. 270 3. Conceptual Model of a Host 272 There are three possible conceptual models for host implementation 273 of default router preferences and more-specific routes, 274 corresponding to different levels of support. We refer to these as 275 type A, type B, and type C. 277 3.1. Conceptual Data Structures for Hosts 279 Type A hosts ignore default router preferences and more-specific 280 routes. They use the conceptual data structures described in 281 Neighbor Discovery [RFC2461]. 283 Type B hosts use a Default Router List augmented with preference 284 values, but ignore all Route Information Options. They use the 285 Default Router Preference value in the Router Advertisement header. 286 They ignore Route Information Options. 288 Type C hosts use a Routing Table instead of a Default Router List. 289 (The Routing Table may also subsume the Prefix List, but that is 290 beyond the scope of this document.) Entries in the Routing Table 291 have a prefix, prefix length, preference value, lifetime, and next- 292 hop router. Type C hosts use both the Default Router Preference 293 value in the Router Advertisement header and Route Information 294 Options. 296 When a type C host receives a Router Advertisement, it modifies its 297 Routing Table as follows. If the received route's lifetime is zero, 298 the route is removed from the Routing Table if present. If a route's 299 lifetime is non-zero, the route is added to the Routing Table if not 300 present and the route's lifetime and preference is updated if the 301 route is already present. A route is located in the Routing Table 302 based on prefix, prefix length, and next-hop router. When processing 303 a Router Advertisement, a type C host first updates a ::/0 route 304 based on the Router Lifetime and Default Router Preference in the 305 Router Advertisement message header. Then as the host processes 306 Route Information Options in the Router Advertisement message body, 307 it updates its routing table for each such option. The Router 308 Preference and Lifetime values in a ::/0 Route Information Option 309 override the preference and lifetime values in the Router 310 Advertisement header. 312 For example, suppose hosts receive a Router Advertisement from 313 router X with a Router Lifetime of 100 seconds and Default Router 314 Preference of Medium. The body of the Router Advertisement contains 315 a Route Information Option for ::/0 with a Route Lifetime of 200 316 seconds and a Route Preference of Low. After processing the Router 317 Advertisement, a type A host will have an entry for router X in its 318 Default Router List with lifetime 100 seconds. If a type B host 319 receives the same Router Advertisement, it will have an entry in its 320 Default Router List for router X with Medium preference and lifetime 321 100 seconds. A type C host will have an entry in its Routing Table 322 for ::/0 -> router X, with Low preference and lifetime 200 seconds. 323 A type C host MAY have a transient state, during processing of the 324 Router Advertisement, in which it has an entry in its Routing Table 325 for ::/0 -> router X with Medium preference and lifetime 100 326 seconds. 328 3.2. Conceptual Sending Algorithm for Hosts 330 Type A hosts use the conceptual sending algorithm described in 331 Neighbor Discovery [RFC2461]. 333 When a type B host does next-hop determination and consults its 334 Default Router List, it primarily prefers reachable routers over 335 non-reachable routers and secondarily uses the router preference 336 values. If the host has no information about the router�s 337 reachability then the host assumes the router is reachable. 339 When a type C host does next-hop determination and consults its 340 Routing Table for an off-link destination, it first prefers 341 reachable routers over non-reachable routers, second uses longest- 342 matching-prefix, and third uses route preference values. Again, if 343 the host has no information about the router�s reachability then the 344 host assumes the router is reachable. 346 If there are no routes matching the destination (i.e., no default 347 routes and no more-specific routes), then if a type C host has a 348 single interface then it SHOULD assume the destination is on-link to 349 that interface. If the type C host has multiple interfaces then it 350 SHOULD discard the packet and report a Destination Unreachable / No 351 Route To Destination error to the upper layer. 353 3.3. Destination Cache Management 355 When a type C host processes a Router Advertisement and updates its 356 conceptual Routing Table, it MUST invalidate or remove Destination 357 Cache Entries and redo next-hop determination for destinations 358 affected by the Routing Table changes. 360 3.4. Client Configurability 362 Type B and C hosts MAY be configurable with preference values that 363 override the values in Router Advertisements received. This is 364 especially useful for dealing with routers which may not support 365 preferences. 367 3.5. Router Reachability Probing 369 When a host avoids using any non-reachable router X and instead 370 sends a data packet to another router Y, and the host would have 371 used router X if router X were reachable, then the host SHOULD probe 372 each such router X's reachability by sending a single Neighbor 373 Solicitation to that router�s address. A host MUST NOT probe a 374 router's reachability in the absence of useful traffic that the host 375 would have sent to the router if it were reachable. In any case, 376 these 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.6. Example 386 Suppose a type C host has four entries in its Routing Table: 387 ::/0 -> router W with Medium preference 388 2001::/16 -> router X with Medium preference 389 3ffe::/16 -> router Y with High preference 390 3ffe::/16 -> router Z with Low preference 391 and the host is sending to 3ffe::1, an off-link destination. If all 392 routers are reachable, then the host will choose router Y. If router 393 Y is not reachable, then router Z will be chosen and the 394 reachability of router Y will be probed. If routers Y and Z are not 395 reachable, then router W will be chosen and the reachability of 396 routers Y and Z will be probed. If routers W, Y, and Z are all not 397 reachable, then the host should use Y while probing the reachability 398 of W and Z. Router X will never be chosen because its prefix does 399 not match the destination. 401 4. Router Configuration 403 Routers should not advertise preferences or routes by default. In 404 particular, they should not "dump out" their entire routing table to 405 hosts. Routers MAY have a configuration mode where a filter is 406 applied to their routing table to obtain the routes that are 407 advertised to hosts. 409 Routers SHOULD NOT send more than 17 Route Information Options in 410 Router Advertisements per link. This arbitrary bound is meant to 411 reinforce that relatively few and carefully selected routes should 412 be advertised to hosts. 414 The preference values (both Default Router Preferences and Route 415 Preferences) should not be routing metrics or automatically derived 416 from metrics: the preference values should be configured. 418 4.1. Guidance to Administrators 420 The High and Low (non-default) preference values should only be used 421 when someone with knowledge of both routers and the network topology 422 configures them explicitly. For example, it could be a common 423 network administrator, or it could be a customer request to 424 different administrators managing the routers. 426 As one exception to this general rule, the administrator of a router 427 that does not have a connection to the internet, or is connected 428 through a firewall that blocks general traffic, should configure the 429 router to advertise a Low Default Router Preference. 431 In addition, the administrator of a router should configure the 432 router to advertise a specific route for the site prefix of the 433 network(s) to which the router belongs. The administrator may also 434 configure the router to advertise specific routes for directly 435 connected subnets and any shorter prefixes for networks to which the 436 router belongs. 438 For example, if a home user sets up a tunnel into a firewalled 439 corporate network, the access router on the corporate network end of 440 the tunnel should advertise itself as a default router, but with a 441 Low preference. Furthermore the corporate router should advertise a 442 specific route for the corporate site prefix. The net result is that 443 destinations in the corporate network will be reached via the 444 tunnel, and general internet destinations will be reached via the 445 home ISP. Without these mechanisms, the home machine might choose to 446 send internet traffic into the corporate network or corporate 447 traffic into the internet, leading to communication failure because 448 of the firewall. 450 5. Examples 452 5.1. Best Router for ::/0 vs Router Least Likely to Redirect 454 The best router for the default route is the router with the best 455 route toward the wider internet. The router least likely to 456 redirect traffic depends on the actual traffic usage. The two 457 concepts can be different when the majority of communication 458 actually needs to go through some other router. 460 For example, consider a situation where you have a link with two 461 routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 462 site gateway.) Router Y is the best for ::/0. (It connects to the 463 native IPv6 internet.) Router X forwards native IPv6 traffic to 464 router Y; router Y forwards 6to4 traffic to router X. If most 465 traffic from this site is sent to 2002:/16 destinations, then router 466 X is the one least likely to redirect. 468 To make type A hosts work well, both routers should advertise 469 themselves as default routers. In particular, if router Y goes down, 470 type A hosts should send traffic to router X to maintain 6to4 471 connectivity, so router X as well as router Y needs to be a default 472 router. 474 To make type B hosts work well, router X should in addition 475 advertise itself with a High default router preference. This will 476 cause type B hosts to prefer router X, minimizing the number of 477 redirects. 479 To make type C hosts work well, router X should in addition 480 advertise the ::/0 route with Low preference and the 2002::/16 route 481 with Medium preference. A type C host will end up with three routes 482 in its routing table: ::/0 -> router X (Low), ::/0 -> router Y 483 (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic 484 to router X and other traffic to router Y. Type C hosts will not 485 cause any redirects. 487 Note that when type C hosts process the Router Advertisement from 488 router X, the Low preference for ::/0 overrides the High default 489 router preference. If the ::/0 specific route were not present, then 490 a type C host would apply the High default router preference to its 491 ::/0 route to router X. 493 5.2. Multi-Homed Host and Isolated Network 495 Here's another scenario: a multi-homed host is connected to the 496 6bone/internet via router X on one link and to an isolated network 497 via router Y on another link. The multi-homed host might have a 498 tunnel into a firewalled corporate network, or it might be directly 499 connected to an isolated test network. 501 In this situation, a type A multi-homed host (which has no default 502 router preferences or more-specific routes) will have no way to 503 intelligently choose between the two routers X and Y on its Default 504 Router List. Users of the host will see unpredictable connectivity 505 failures, depending on the destination address and the choice of 506 router. 508 A multi-homed type C host in this same situation can correctly 509 choose between routers X and Y, if the routers are configured 510 appropriately. For example, router X on the isolated network should 511 advertise a Route Information Option for the isolated network 512 prefix. It might not advertise itself as a default router at all 513 (zero Router Lifetime), or it might advertise itself as a default 514 router with Low preference. Router Y should advertise itself as a 515 default router with Medium preference. 517 6. Security Considerations 519 A malicious node could send Router Advertisement messages, 520 specifying High Default Router Preference or carrying specific 521 routes, with the effect of pulling traffic away from legitimate 522 routers. However, a malicious node could easily achieve this same 523 effect in other ways. For example, it could fabricate Router 524 Advertisement messages with zero Router Lifetime from the other 525 routers, causing hosts to stop using the other routes. Hence, this 526 document has no new appreciable impact on Internet infrastructure 527 security. 529 7. Acknowledgments 531 The authors would like to acknowledge the contributions of Balash 532 Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian 533 Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir 534 Segaric, and Brian Zill. The packet diagrams are derived from 535 Neighbor Discovery [RFC2461]. 537 8. Normative References 539 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 540 Discovery for IP Version 6 (IPv6)", RFC 2461, December 541 1998. 543 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 544 Requirement Levels", BCP 14, RFC 2119, March 1997. 546 9. Informative References 548 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 549 via IPv4 Clouds", RFC 3056, February 2001. 551 [RFC1933] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 552 IPv6 Hosts and Routers", RFC 1933, April 1996. 554 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 555 January 1997. 557 Author's Addresses 559 Richard Draves 560 Microsoft Research 561 One Microsoft Way 562 Redmond, WA 98052 563 Phone: +1 425 706 2268 564 Email: richdr@microsoft.com 566 Dave Thaler 567 Microsoft 568 One Microsoft Way 569 Redmond, WA 98052 570 Phone: +1 425 703 8835 571 Email: dthaler@microsoft.com 573 Revision History (to be removed before publication as an RFC) 575 Changes from draft-ietf-ipv6-router-selection-02 577 Added Dave Thaler as co-author. 579 Various clarifications and textual improvements. 581 Split all load sharing text back into a separate document. 583 Changes from draft-ietf-ipv6-router-selection-01 585 Added Bob Hinden as co-author. 587 Various clarifications and textual improvements. 589 Slightly simplified the specification of round-robining in next-hop 590 determination, relying on router-reachability probing in some cases. 592 Clarified that router reachability probing only happens when the 593 host is sending packets that would have gone to that router if it 594 were reachable. 596 Changed load sharing to a mandatory requirement and added supporting 597 text to the title, abstract, and introduction. 599 Changes from draft-ietf-ipngwg-router-selection-00 601 Specified reachability probing of otherwise more-preferred but 602 currently unreachable routers. 604 Changed the requirement of Destination Cache invalidation, from MAY 605 to SHOULD, but allowing flushing of the entire Destination Cache. 607 Added a section specifying load sharing among equivalent routers. 609 Changes from draft-draves-ipngwg-router-selection-01 611 Specified receiver processing when the Reserved preference value is 612 seen. 614 Specified that routers SHOULD NOT send more than 17 Route 615 Information Options. 617 Added discussion of Destination Cache invalidation, allowing but not 618 requiring it. 620 Removed references to the fourth conceptual host model, host D. 622 Changes from draft-draves-ipngwg-router-selection-00 624 Made the option variable length. Must ignore prefix bits past prefix 625 length. 627 Added more allowable router configuration scenarios, weakening the 628 requirement that one administrator must coordinate the configuration 629 of all relevant routers. 631 Full Copyright Statement 633 Copyright (C) The Internet Society (2003). All Rights Reserved. 635 This document and translations of it may be copied and furnished to 636 others, and derivative works that comment on or otherwise explain it 637 or assist in its implementation may be prepared, copied, published 638 and distributed, in whole or in part, without restriction of any 639 kind, provided that the above copyright notice and this paragraph 640 are included on all such copies and derivative works. However, this 641 document itself may not be modified in any way, such as by removing 642 the copyright notice or references to the Internet Society or other 643 Internet organizations, except as needed for the purpose of 644 developing Internet standards in which case the procedures for 645 copyrights defined in the Internet Standards process must be 646 followed, or as required to translate it into languages other than 647 English. 649 The limited permissions granted above are perpetual and will not be 650 revoked by the Internet Society or its successors or assigns. 652 This document and the information contained herein is provided on an 653 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 654 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 655 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 656 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 657 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.