idnits 2.17.1 draft-draves-ipngwg-router-selection-01.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: ---------------------------------------------------------------------------- == 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 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 (March 3, 2001) is 8454 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 12 looks like a reference -- Missing reference section? '2' on line 506 looks like a reference -- Missing reference section? '3' on line 81 looks like a reference -- Missing reference section? '4' on line 81 looks like a reference -- Missing reference section? '5' on line 91 looks like a reference -- Missing reference section? '6' on line 110 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPng Working Group Richard Draves 3 Internet Draft Microsoft Research 4 Document: draft-draves-ipngwg-router-selection-01.txt March 3, 2001 6 Default Router Preferences and More-Specific Routes 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC 2026 [1]. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six 19 months and may be updated, replaced, or obsoleted by other documents 20 at any time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes an optional extension to Neighbor Discovery 32 Router Advertisement messages for communicating default router 33 preferences and more-specific routes from routers to hosts. This 34 improves the ability of hosts to pick an appropriate router, 35 especially when the host is multi-homed and the routers are on 36 different links. The preference values and specific routes 37 advertised to hosts require administrative configuration; they are 38 not automatically derived from routing tables. 40 1. Introduction 42 Neighbor Discovery [2] specifies a conceptual model for hosts that 43 includes a Default Router List and a Prefix List. Hosts send Router 44 Solicitation messages and receive from routers Router Advertisement 45 messages. Hosts populate their Default Router List and Prefix List 46 based on information in the Router Advertisement messages. A 47 conceptual sending algorithm uses the Prefix List to determine if a 48 destination address is on-link and the Default Router List to select 49 a router for off-link destinations. 51 In some network topologies where the host has multiple routers on 52 its Default Router List, the choice of router for an off-link 53 destination is important. In some situations, one router may provide 54 much better performance than another for a destination. In other 55 situations, choosing the wrong router may result in a failure to 56 communicate. (A later section gives specific examples of these 57 scenarios.) 59 This document describes an optional extension to Neighbor Discovery 60 Router Advertisement messages for communicating default router 61 preferences and more-specific routes from routers to hosts. This 62 improves the ability of hosts to pick an appropriate router for an 63 off-link destination. 65 Neighbor Discovery provides a Redirect message that routers can use 66 to correct a host's choice of router. A router can send a Redirect 67 message to a host, telling it to use a different router for a 68 specific destination. However, the Redirect functionality is limited 69 to a single link. A router on one link cannot redirect a host to a 70 router on another link. Hence, Redirect messages do not help multi- 71 homed hosts select an appropriate router. 73 Multi-homed hosts are an increasingly important scenario, especially 74 with IPv6. In addition to a wired network connection, like Ethernet, 75 hosts may have one or more wireless connections, like 802.11 or 76 Bluetooth. In addition to physical network connections, hosts may 77 have virtual or tunnel network connections. For example, in addition 78 to a direct connection to the public Internet, a host may have a 79 tunnel into a private corporate network. Some IPv6 transition 80 scenarios can add additional tunnels. For example, hosts may have 81 6-over-4 [3] or configured tunnel [4] network connections. 83 This document requires that the preference values and specific 84 routes advertised to hosts require explicit administrative 85 configuration. They are not automatically derived from routing 86 tables. In particular, the preference values are not routing metrics 87 and it is not recommended that routers "dump out" their entire 88 routing tables to hosts. 90 We use Router Advertisement messages, instead of some other protocol 91 like RIP [5], is that Router Advertisements are an existing 92 standard, stable protocol for router-to-host communication. 93 Piggybacking this information on existing message traffic from 94 routers to hosts reduces network overhead. Neighbor Discovery is to 95 unicast routing as Multicast Listener Discovery is to multicast 96 routing. In both cases, a single simple protocol insulates the host 97 from the variety of router-to-router protocols. In addition, RIP is 98 unsuitable because it does not carry route lifetimes so it requires 99 frequent message traffic with greater processing overheads. 101 The mechanisms specified here are backwards-compatible, so that 102 hosts that do not implement them continue to function as well as 103 they did previously. 105 1.1. Conventions used in this document 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 109 this document are to be interpreted as described in RFC-2119 [6]. 111 2. Message Formats 113 2.1. Preference Values 115 Default router preferences and preferences for more-specific routes 116 are encoded the same way. 118 Preference values are encoded in two bits, as follows: 119 01 High 120 00 Medium (default) 121 11 Low 122 10 Reserved - MUST NOT be sent 123 Note that implementations can treat the value as a two-bit signed 124 integer. 126 Having just three values reinforces that they are not metrics and 127 more values does not appear to be necessary for reasonable 128 scenarios. 130 2.2. Changes to Router Advertisement Message Format 132 The changes from Neighbor Discovery [2] section 4.2 are as follows: 134 0 1 2 3 135 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 136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 137 | Type | Code | Checksum | 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Reachable Time | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Retrans Timer | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Options ... 146 +-+-+-+-+-+-+-+-+-+-+-+- 148 Fields: 150 Prf (Default Router Preference) 151 2-bit signed integer. Indicates whether or not to prefer 152 this router over other default routers. If Router 153 Lifetime is zero, it MUST be initialized to zero by the 154 sender and MUST be ignored by the receiver. 156 Reserved A 3-bit unused field. It MUST be initialized to zero by 157 the sender and MUST be ignored by the receiver. 159 Possible Options: 161 Route Information 162 These options specify prefixes that are reachable via 163 the router. 165 Discussion: 167 Note that in addition to the preference value in the message header, 168 a Router Advertisement can also contain a Route Information Option 169 for ::/0, with a preference value and lifetime. Encoding a 170 preference value in the Router Advertisement header has some 171 advantages: 173 1. It allows for a distinction between "best default router" and 174 "best router for default", as described below. 176 2. When the best default router is also the best router for 177 default (which will be a common case), encoding the preference 178 value in the message header is more efficient than having to send 179 a separate option. 181 2.3. Route Information Option 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Route Lifetime | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | | 191 + + 192 | | 193 + Prefix + 194 | | 195 + + 196 | | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 Fields: 201 Type TBD 203 Length 1, 2, or 3 depending on Prefix Length. If Prefix Length 204 is greater than 64, then Length must be at least 3. If 205 Prefix Length is greater than 0, then Length must be at 206 least 2. If Prefix Length is zero, then Length may be 1. 208 Prefix Length 209 8-bit unsigned integer. The number of leading bits in 210 the Prefix that are valid. The value ranges from 0 to 211 128. 213 Prf (Route Preference) 214 2-bit signed integer. Indicates whether or not to prefer 215 this router for the prefix over others. 217 Resvd (Reserved) 218 Two 3-bit unused fields. They MUST be initialized to 219 zero by the sender and MUST be ignored by the receiver. 221 Route Lifetime 222 32-bit unsigned integer. The length of time in seconds 223 (relative to the time the packet is sent) that the 224 prefix is valid for route determination. A value of all 225 one bits (0xffffffff) represents infinity. 227 Prefix An IP address or a prefix of an IP address. The Prefix 228 Length field contains the number of valid leading bits 229 in the prefix. The bits in the prefix after the prefix 230 length are reserved and MUST be initialized to zero by 231 the sender and ignored by the receiver. 233 The Prefix field is 0, 8, or 16 octets depending on 234 Length. 236 Routers SHOULD NOT include in a Router Advertisement two Route 237 Information Options with the same Prefix and Prefix Length. If a 238 host processes a Router Advertisement carrying multiple Router 239 Information Options with the same Prefix and Prefix Length, it MUST 240 process one of the options (unspecified which one) and it MUST 241 effectively ignore the rest. It MUST NOT retain some information 242 (like preference) from one option and other information (like 243 lifetime) from another option. 245 Discussion: 247 There are several reasons for using a new Route Information Option, 248 instead of using flag bits to overload the existing Prefix 249 Information Option: 251 1. Prefixes will typically only show up in one or the other kind 252 of option, not both, so a new option does not introduce 253 duplication. 255 2. The Route Information Option is typically 16 octets while the 256 Prefix Information Option is 32 octets. 258 3. Using a new option may improve backwards-compatibility with 259 some host implementations. 261 3. Conceptual Model of a Host 263 There are four possible conceptual models for host implementation of 264 default router preferences and more-specific routes, corresponding 265 to different levels of support. We refer to these as host A, host B, 266 host C, and host D. Note that these are really classes of hosts, not 267 individual hosts. 269 3.1. Conceptual Data Structures for Hosts 271 Host A ignores default router preferences and more-specific routes. 272 Host A uses the conceptual data structures described in Neighbor 273 Discovery [2]. 275 Host B uses a Default Router List augmented with preference values. 276 Host B does not have a routing table. Host B uses the Default Router 277 Preference value in the Router Advertisement header. Host B ignores 278 Route Information Options. 280 Host C uses a Routing Table instead of a Default Router List. (The 281 Routing Table may also subsume the Prefix List, but that is beyond 282 the scope of this document.) Entries in the Routing Table have a 283 prefix, prefix length, preference value, lifetime, and next-hop 284 router. Host C uses both the Default Router Preference value in the 285 Router Advertisement header and Route Information Options. 287 When host C receives a Router Advertisement, it modifies its Routing 288 Table as follows. If a route's lifetime is zero, the route is 289 removed from the Routing Table if present. If a route's lifetime is 290 non-zero, the route is added to the Routing Table if not present and 291 the route's lifetime and preference is updated if the route is 292 already present. A route is located in the Routing Table based on 293 prefix, prefix length, and next-hop router. When processing a Router 294 Advertisment, host C first updates a ::/0 route based on the Router 295 Lifetime and Default Router Preference in the Router Advertisement 296 message header. Then as host C processes Route Information Options 297 in the Router Advertisement message body, it updates its routing 298 table for each such option. The Router Preference and Lifetime 299 values in a ::/0 Route Information Option override the preference 300 and lifetime values in the Router Advertisement header. 302 Host D uses a Routing Table but does not support preference values. 303 Host D uses Route Information Options, but it ignores the Route 304 Preference in the options and the Default Router Preference in the 305 Router Advertisement header. 307 For example, suppose a host receives a Router Advertisement from 308 router X with a Router Lifetime of 100 seconds and Default Router 309 Preference of Medium. The body of the Router Advertisement contains 310 a Route Information Option for ::/0 with a Route Lifetime of 200 311 seconds and a Route Preference of Low. After processing the Router 312 Advertisement, host A will have an entry for router X in its Default 313 Router List with lifetime 100 seconds. If host B receives the same 314 Router Advertisement, it will have an entry in its Default Router 315 List for router X with Medium preference and lifetime 100 seconds. 316 Host C will have an entry in its Routing Table for ::/0 -> router X, 317 with Low preference and lifetime 200 seconds. And host D will have 318 an entry in its Routing Table for ::/0 -> router X with lifetime 200 319 seconds. 321 3.2. Conceptual Sending Algorithm for Hosts 323 Host A uses the conceptual sending algorithm described in Neighbor 324 Discovery [2]. 326 When host B does next-hop determination and consults its Default 327 Router List, it first prefers reachable routers over non-reachable 328 routers and second uses the router preference values. If all default 329 routers are not reachable, then it SHOULD round-robin among them all 330 regardless of preference value. 332 When host C does next-hop determination and consults its Routing 333 Table for an off-link destination, it first prefers reachable 334 routers over non-reachable routers, second uses longest-matching- 335 prefix, and third uses route preference values. 337 If there are no reachable routers with routes matching the 338 destination, then host C SHOULD round-robin among all routers with 339 routes matching the destination regardless of preference value or 340 prefix length. 342 If there are no routes matching the destination, then if host C has 343 a single interface then it SHOULD assume the destination is on-link. 344 If host C has multiple interfaces then it SHOULD discard the packet 345 and report a Destination Unreachable / No Route To Destination error 346 to the upper layer. 348 For example: suppose host C has four entries in its Routing Table: 349 ::/0 -> router W with Medium preference 350 2001::/16 -> router X with Medium preference 351 3ffe::/16 -> router Y with High preference 352 3ffe::/16 -> router Z with Low preference 353 and host C is sending to 3ffe::1, an off-link destination. If all 354 routers are reachable, then router Y will be chosen. If router Y is 355 not reachable, then router Z will be chosen. If routers Y and Z are 356 not reachable, then router W will be chosen. If routers W, Y, and Z 357 are all not reachable, then host C should round-robin among the 358 three routers. Router X will never be chosen because its prefix does 359 not match the destination. 361 Host D operates like host C, but without preference values. 363 4. Router Configuration 365 Routers should not advertise preferences or routes by default. In 366 particular, they should not "dump out" their entire routing table to 367 hosts. Routers MAY have a configuration mode where a filter is 368 applied to their routing table to obtain the routes that are 369 advertised to hosts. 371 The preference values (both Default Router Preferences and Route 372 Preferences) should not be routing metrics or automatically derived 373 from metrics: the preference values should be configured. The High 374 and Low (non-default) preference values should only be used when 375 someone with knowledge of both routers and the network topology 376 configures them explicitly. For example, it could be a common 377 network administrator, or it could be a customer request to 378 different administrators managing the routers. 380 As one exception to this general rule, the administrator of a router 381 that does not have a connection to the internet, or is connected 382 through a firewall that blocks general traffic, may configure the 383 router to advertise a Low Default Router Preference. 385 An administrator of a router may configure the router to advertise 386 specific routes for directly connected subnets and any shorter 387 prefixes (eg, site, NLA, or TLA prefixes) for networks to which the 388 router belongs. 390 For example, if a home user sets up a tunnel into a firewalled 391 corporate network, the access router on the corporate network end of 392 the tunnel can advertise itself as a default router, but with a Low 393 preference. Furthermore the corporate router can advertise a 394 specific route for the corporate site prefix. The net result is that 395 destinations in the corporate network will be reached via the 396 tunnel, and general internet destinations will be reached via the 397 home ISP. Without these mechanisms, the home machine might choose to 398 send internet traffic into the corporate network or corporate 399 traffic into the internet, leading to communication failure because 400 of the firewall. 402 5. Examples 404 5.1. Best Default Router vs Best Route for Default 406 The best default router is not quite the same thing as the best 407 router for default. The best default router is the router that will 408 generate the fewest number of redirects for the host's traffic. The 409 best router for default is the router with the best route toward the 410 wider internet. 412 For example, suppose a situation where you have a link with two 413 routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 414 site gateway.) Router Y is the best for ::/0. (It connects to the 415 native IPv6 internet.) Router X forwards native IPv6 traffic to 416 router Y; router Y forwards 6to4 traffic to router X. But most 417 traffic from this site is sent to 2002:/16 destinations. In this 418 scenario, router X is the best default router and router Y is the 419 best router for default. 421 To make host A work well, both routers should advertise themselves 422 as default routers. In particular, if router Y goes down host A 423 should send traffic to router X to maintain 6to4 connectivity, so 424 router X as well as router Y needs to be a default router. 426 To make host B work well, router X should in addition advertise 427 itself with a High default router preference. This will cause host B 428 to prefer router X, minimizing the number of redirects. 430 To make host C work well, router X should in addition advertise the 431 ::/0 route with Low preference and the 2002::/16 route with Medium 432 preference. Host C will end up with three routes in its routing 433 table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 434 -> router X (Medium). It will send 6to4 traffic to router X and 435 other traffic to router Y. Host C will not cause any redirects. 437 Note that when host C processes the Router Advertisement from router 438 X, the Low preference for ::/0 overrides the High default router 439 preference. If the ::/0 specific route were not present, then host C 440 would apply the High default router preference to its ::/0 route to 441 router X. 443 Host D will see the specific route but ignore the preferences. It 444 will send 6to4 traffic to router X but it will have no means to 445 choose between routers X and Y for other traffic. 447 5.2. Multi-Homed Host and Isolated Network 449 Here's another scenario: a multi-homed host is connected to the 450 6bone/internet via router X on one link and to an isolated network 451 via router Y on another link. The multi-homed host might have a 452 tunnel into a fire-walled corporate network, or it might be directly 453 connected to an isolated test network. 455 In this situation, a multi-homed host A (which has no default router 456 preferences or more-specific routes) will have no way to choose 457 between the two routers X and Y on its Default Router List. Users of 458 the host will see unpredictable connectivity failures, depending on 459 the destination address and the choice of router. 461 A multi-homed host C in this same situation can correctly choose 462 between routers X and Y, if the routers are configured 463 appropriately. For example, router X on the isolated network should 464 advertise a Route Information Option for the isolated network 465 prefix. It might not advertise itself as a default router at all 466 (zero Router Lifetime), or it might advertise itself as a default 467 router with Low preference. Router Y should advertise itself as a 468 default router with Medium preference. 470 6. Security Considerations 472 A malicious node could send Router Advertisement messages, 473 specifying High Default Router Preference or carrying specific 474 routes, with the effect of pulling traffic away from legitimate 475 routers. However, a malicious node could easily achieve this same 476 effect in other ways. For example, it could fabricate Router 477 Advertisement messages with zero Router Lifetime from the other 478 routers, causing hosts to stop using the other routes. Hence, this 479 document has no appreciable impact on Internet infrastructure 480 security. 482 References 484 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 485 9, RFC 2026, October 1996. 487 2 T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP 488 Version 6 (IPv6)", RFC 2461, December 1998. 490 3 B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 491 Clouds", draft-ietf-ngtrans-6to4-07.txt, September 2000. 493 4 R. Gilligan, E. Nordmark. "Transition Mechanisms for IPv6 Hosts 494 and Routers", RFC 1933, April 1996. 496 5 G. Malkin, R. Minnear. "RIPng for IPv6", RFC 2080 , January 1997. 498 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement 499 Levels", BCP 14, RFC 2119, March 1997. 501 Acknowledgments 503 The author would like to acknowledge the contributions of Balash 504 Akbari, Steve Deering, Robert Elz, Tony Hain, Christian Huitema, 505 Dave Thaler, and Brian Zill. The packet diagrams are derived from 506 Neighbor Discovery [2]. 508 Author's Addresses 510 Richard Draves 511 Microsoft Research 512 One Microsoft Way 513 Redmond, WA 98052 514 Phone: 1-425-936-2268 515 Email: richdr@microsoft.com 517 Revision History 519 Changes from draft-draves-ipngwg-router-selection-00 521 Made the option variable length. Must ignore prefix bits past prefix 522 length. 524 Added more allowable router configuration scenarios, weakening the 525 requirement that one administrator must coordinate the configuration 526 of all relevant routers. 528 Full Copyright Statement 530 Copyright (C) The Internet Society (2000). All Rights Reserved. 532 This document and translations of it may be copied and furnished to 533 others, and derivative works that comment on or otherwise explain it 534 or assist in its implementation may be prepared, copied, published 535 and distributed, in whole or in part, without restriction of any 536 kind, provided that the above copyright notice and this paragraph 537 are included on all such copies and derivative works. However, this 538 document itself may not be modified in any way, such as by removing 539 the copyright notice or references to the Internet Society or other 540 Internet organizations, except as needed for the purpose of 541 developing Internet standards in which case the procedures for 542 copyrights defined in the Internet Standards process must be 543 followed, or as required to translate it into languages other than 544 English. 546 The limited permissions granted above are perpetual and will not be 547 revoked by the Internet Society or its successors or assigns. 549 This document and the information contained herein is provided on an 550 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 551 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 552 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 553 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 554 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.