idnits 2.17.1 draft-draves-ipngwg-router-selection-00.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 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 (November 17, 2000) is 8554 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 472 looks like a reference -- Missing reference section? '3' on line 83 looks like a reference -- Missing reference section? '4' on line 83 looks like a reference -- Missing reference section? '5' on line 93 looks like a reference -- Missing reference section? '6' on line 112 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-00.txt Balash Akbari 5 Microsoft 6 November 17, 2000 8 Default Router Preferences and More-Specific Routes 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 an optional extension to Neighbor Discovery 34 Router Advertisement messages for communicating default router 35 preferences and more-specific routes from routers to hosts. This 36 improves the ability of hosts to pick an appropriate router, 37 especially when the host is multi-homed and the routers are on 38 different links. The preference values and specific routes 39 advertised to hosts require administrative configuration; they are 40 not automatically derived from routing tables. 42 1. Introduction 44 Neighbor Discovery [2] specifies a conceptual model for hosts that 45 includes a Default Router List and a Prefix List. Hosts send Router 46 Solicitation messages and receive from routers Router Advertisement 47 messages. Hosts populate their Default Router List and Prefix List 48 based on information in the Router Advertisement messages. A 49 conceptual sending algorithm uses the Prefix List to determine if a 50 destination address is on-link and the Default Router List to select 51 a router for off-link destinations. 53 In some network topologies where the host has multiple routers on 54 its Default Router List, the choice of router for an off-link 55 destination is important. In some situations, one router may provide 56 much better performance than another for a destination. In other 57 situations, choosing the wrong router may result in a failure to 58 communicate. (A later section gives specific examples of these 59 scenarios.) 61 This document describes an optional extension to Neighbor Discovery 62 Router Advertisement messages for communicating default router 63 preferences and more-specific routes from routers to hosts. This 64 improves the ability of hosts to pick an appropriate router for an 65 off-link destination. 67 Neighbor Discovery provides a Redirect message that routers can use 68 to correct a host's choice of router. A router can send a Redirect 69 message to a host, telling it to use a different router for a 70 specific destination. However, the Redirect functionality is limited 71 to a single link. A router on one link cannot redirect a host to a 72 router on another link. Hence, Redirect messages do not help multi- 73 homed hosts select an appropriate router. 75 Multi-homed hosts are an increasingly important scenario, especially 76 with IPv6. In addition to a wired network connection, like Ethernet, 77 hosts may have one or more wireless connections, like 802.11 or 78 Bluetooth. In addition to physical network connections, hosts may 79 have virtual or tunnel network connections. For example, in addition 80 to a direct connection to the public Internet, a host may have a 81 tunnel into a private corporate network. Some IPv6 transition 82 scenarios can add additional tunnels. For example, hosts may have 83 6-over-4 [3] or configured tunnel [4] network 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 [5], is that 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 is to 97 unicast routing as Multicast Listener Discovery is to multicast 98 routing. In both cases, a single simple protocol insulates the host 99 from the variety of router-to-router protocols. In addition, RIP is 100 unsuitable because it does not carry route lifetimes so it requires 101 frequent message traffic with greater processing overheads. 103 The mechanisms specified here are backwards-compatible, so that 104 hosts that do not implement them continue to function as well as 105 they did previously. 107 1.1. Conventions used in this document 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 111 this document are to be interpreted as described in RFC-2119 [6]. 113 2. Message Formats 115 2.1. Preference Values 117 Default router preferences and preferences for more-specific routes 118 are encoded the same way. 120 Preference values are encoded in two bits, as follows: 121 01 High 122 00 Medium (default) 123 11 Low 124 10 Reserved - MUST NOT be sent 125 Note that implementations can treat the value as a two-bit signed 126 integer. 128 Having just three values reinforces that they are not metrics and 129 more values does not appear to be necessary for reasonable 130 scenarios. 132 2.2. Changes to Router Advertisement Message Format 134 The changes from Neighbor Discovery [2] section 4.2 are as follows: 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 | Type | Code | Checksum | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Reachable Time | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Retrans Timer | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Options ... 148 +-+-+-+-+-+-+-+-+-+-+-+- 150 Fields: 152 Prf (Default Router Preference) 153 2-bit signed integer. Indicates whether or not to prefer 154 this router over other default routers. If Router 155 Lifetime is zero, it MUST be initialized to zero by the 156 sender and MUST be ignored by the receiver. 158 Reserved A 3-bit unused field. It MUST be initialized to zero by 159 the sender and MUST be ignored by the receiver. 161 Possible Options: 163 Route Information 164 These options specify prefixes that are reachable via 165 the router. 167 Discussion: 169 Note that in addition to the preference value in the message header, 170 a Router Advertisement can also contain a Route Information Option 171 for ::/0, with a preference value and lifetime. Encoding a 172 preference value in the Router Advertisement header has some 173 advantages: 175 1. It allows for a distinction between "best default router" and 176 "best router for default", as described below. 178 2. When the best default router is also the best router for 179 default (which will be a common case), encoding the preference 180 value in the message header is more efficient than having to send 181 a separate option. 183 2.3. Route Information Option 185 0 1 2 3 186 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 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Route Lifetime | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | | 193 + + 194 | | 195 + Prefix + 196 | | 197 + + 198 | | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 Fields: 203 Type TBD 205 Length 3 207 Prefix Length 208 8-bit unsigned integer. The number of leading bits in 209 the Prefix that are valid. The value ranges from 0 to 210 128. 212 Prf (Route Preference) 213 2-bit signed integer. Indicates whether or not to prefer 214 this router for the prefix over others. 216 Resvd (Reserved) 217 Two 3-bit unused fields. They MUST be initialized to 218 zero by the sender and MUST be ignored by the receiver. 220 Route Lifetime 221 32-bit unsigned integer. The length of time in seconds 222 (relative to the time the packet is sent) that the 223 prefix is valid for route determination. A value of all 224 one bits (0xffffffff) represents infinity. 226 Prefix An IP address or a prefix of an IP address. The Prefix 227 Length field contains the number of valid leading bits 228 in the prefix. The bits in the prefix after the prefix 229 length are reserved and MUST be initialized to zero by 230 the sender and ignored by the receiver. 232 Routers SHOULD NOT include in a Router Advertisement two Route 233 Information Options with the same Prefix and Prefix Length. If a 234 host processes a Router Advertisement carrying multiple Router 235 Information Options with the same Prefix and Prefix Length, it MUST 236 process one of the options (unspecified which one) and it MUST 237 effectively ignore the rest. It MUST NOT retain some information 238 (like preference) from one option and other information (like 239 lifetime) from another option. 241 Discussion: 243 There are several reasons for using a new Route Information Option, 244 instead of using flag bits to overload the existing Prefix 245 Information Option: 247 1. Prefixes will typically only show up in one or the other kind 248 of option, not both, so a new option does not introduce 249 duplication. 251 2. The Route Information Option is 24 octets while the Prefix 252 Information Option is 32 octets. (Question: Perhaps the Prefix 253 field should be 8 octets instead of 16, saving even more space?) 255 3. Using a new option may improve backwards-compatibility with 256 some host implementations. 258 3. Conceptual Model of a Host 260 There are four possible conceptual models for host implementation of 261 default router preferences and more-specific routes, corresponding 262 to different levels of support. We refer to these as host A, host B, 263 host C, and host D. Note that these are really classes of hosts, not 264 individual hosts. 266 3.1. Conceptual Data Structures for Hosts 268 Host A ignores default router preferences and more-specific routes. 269 Host A uses the conceptual data structures described in Neighbor 270 Discovery [2]. 272 Host B uses a Default Router List augmented with preference values. 273 Host B does not have a routing table. Host B uses the Default Router 274 Preference value in the Router Advertisement header. Host B ignores 275 Route Information Options. 277 Host C uses a Routing Table instead of a Default Router List. (The 278 Routing Table may also subsume the Prefix List, but that is beyond 279 the scope of this document.) Entries in the Routing Table have a 280 prefix, prefix length, preference value, lifetime, and next-hop 281 router. Host C uses both the Default Router Preference value in the 282 Router Advertisement header and Route Information Options. 284 When host C receives a Router Advertisement, it modifies its Routing 285 Table as follows. If a route's lifetime is zero, the route is 286 removed from the Routing Table if present. If a route's lifetime is 287 non-zero, the route is added to the Routing Table if not present and 288 the route's lifetime and preference is updated if the route is 289 already present. A route is located in the Routing Table based on 290 prefix, prefix length, and next-hop router. When processing a Router 291 Advertisment, host C first updates a ::/0 route based on the Router 292 Lifetime and Default Router Preference in the Router Advertisement 293 message header. Then as host C processes Route Information Options 294 in the Router Advertisement message body, it updates its routing 295 table for each such option. The Router Preference and Lifetime 296 values in a ::/0 Route Information Option override the preference 297 and lifetime values in the Router Advertisement header. 299 Host D uses a Routing Table but does not support preference values. 300 Host D uses Route Information Options, but it ignores the Route 301 Preference in the options and the Default Router Preference in the 302 Router Advertisement header. 304 For example, suppose a host receives a Router Advertisement from 305 router X with a Router Lifetime of 100 seconds and Default Router 306 Preference of Medium. The body of the Router Advertisement contains 307 a Route Information Option for ::/0 with a Route Lifetime of 200 308 seconds and a Route Preference of Low. After processing the Router 309 Advertisement, host A will have an entry for router X in its Default 310 Router List with lifetime 100 seconds. If host B receives the same 311 Router Advertisement, it will have an entry in its Default Router 312 List for router X with Medium preference and lifetime 100 seconds. 313 Host C will have an entry in its Routing Table for ::/0 -> router X, 314 with Low preference and lifetime 200 seconds. And host D will have 315 an entry in its Routing Table for ::/0 -> router X with lifetime 200 316 seconds. 318 3.2. Conceptual Sending Algorithm for Hosts 320 Host A uses the conceptual sending algorithm described in Neighbor 321 Discovery [2]. 323 When host B does next-hop determination and consults its Default 324 Router List, it first prefers reachable routers over non-reachable 325 routers and second uses the router preference values. If all default 326 routers are not reachable, then it SHOULD round-robin among them all 327 regardless of preference value. 329 When host C does next-hop determination and consults its Routing 330 Table for an off-link destination, it first prefers reachable 331 routers over non-reachable routers, second uses longest-matching- 332 prefix, and third uses route preference values. If there are no 333 reachable routers with routes matching the destination, then it 334 SHOULD round-robin among all routers with routes matching the 335 destination regardless of preference value or prefix length. 337 For example: suppose host C has four entries in its Routing Table: 338 ::/0 -> router W with Medium preference 339 2001::/16 -> router X with Medium preference 340 3ffe::/16 -> router Y with High preference 341 3ffe::/16 -> router Z with Low preference 342 and host C is sending to 3ffe::1, an off-link destination. If all 343 routers are reachable, then router Y will be chosen. If router Y is 344 not reachable, then router Z will be chosen. If routers Y and Z are 345 not reachable, then router W will be chosen. If routers W, Y, and Z 346 are all not reachable, then host C should round-robin among the 347 three routers. Router X will never be chosen because its prefix does 348 not match the destination. 350 Host D operates like host C, but without preference values. 352 4. Router Configuration 354 Routers should not advertise preferences or routes by default. In 355 particular, they should not "dump out" their entire routing table to 356 hosts. Routers MAY have a configuration mode where a filter is 357 applied to their routing table to obtain the routes that are 358 advertised to hosts. 360 The preference values (both Default Router Preferences and Route 361 Preferences) should not be routing metrics or automatically derived 362 from metrics: the preference values should be configured. The High 363 and Low (non-default) preference values should only be used when 364 someone with knowledge of both routers and the network topology 365 configures them explicitly. For example, it could be a common 366 network administrator, or it could be a customer request to 367 different administrators managing the routers. 369 5. Examples 371 5.1. Best Default Router vs Best Route for Default 373 The best default router is not quite the same thing as the best 374 router for default. The best default router is the router that will 375 generate the fewest number of redirects for the host's traffic. The 376 best router for default is the router with the best route toward the 377 wider internet. 379 For example, suppose a situation where you have a link with two 380 routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 381 site gateway.) Router Y is the best for ::/0. (It connects to the 382 native IPv6 internet.) Router X forwards native IPv6 traffic to 383 router Y; router Y forwards 6to4 traffic to router X. But most 384 traffic from this site is sent to 2002:/16 destinations. In this 385 scenario, router X is the best default router and router Y is the 386 best router for default. 388 To make host A work well, both routers should advertise themselves 389 as default routers. In particular, if router Y goes down host A 390 should send traffic to router X to maintain 6to4 connectivity, so 391 router X as well as router Y needs to be a default router. 393 To make host B work well, router X should in addition advertise 394 itself with a High default router preference. This will cause host B 395 to prefer router X, minimizing the number of redirects. 397 To make host C work well, router X should in addition advertise the 398 ::/0 route with Low preference and the 2002::/16 route with Medium 399 preference. Host C will end up with three routes in its routing 400 table: ::/0 -> router X (Low), ::/0 -> router Y (Medium), 2002::/16 401 -> router X (Medium). It will send 6to4 traffic to router X and 402 other traffic to router Y. Host C will not cause any redirects. 404 Note that when host C processes the Router Advertisement from router 405 X, the Low preference for ::/0 overrides the High default router 406 preference. If the ::/0 specific route were not present, then host C 407 would apply the High default router preference to its ::/0 route to 408 router X. 410 Host D will see the specific route but ignore the preferences. It 411 will send 6to4 traffic to router X but it will have no means to 412 choose between routers X and Y for other traffic. 414 5.2. Multi-Homed Host and Isolated Network 416 Here's another scenario: a multi-homed host is connected to the 417 6bone/internet via router X on one link and to an isolated network 418 via router Y on another link. The multi-homed host might have a 419 tunnel into a fire-walled corporate network, or it might be directly 420 connected to an isolated test network. 422 In this situation, a multi-homed host A (which has no default router 423 preferences or more-specific routes) will have no way to choose 424 between the two routers X and Y on its Default Router List. Users of 425 the host will see unpredictable connectivity failures, depending on 426 the destination address and the choice of router. 428 A multi-homed host C in this same situation can correctly choose 429 between routers X and Y, if the routers are configured 430 appropriately. For example, router X on the isolated network should 431 advertise a Route Information Option for the isolated network 432 prefix. It might not advertise itself as a default router at all 433 (zero Router Lifetime), or it might advertise itself as a default 434 router with Low preference. Router Y should advertise itself as a 435 default router with Medium preference. 437 6. Security Considerations 439 A malicious node could send Router Advertisement messages, 440 specifying High Default Router Preference or carrying specific 441 routes, with the effect of pulling traffic away from legitimate 442 routers. However, a malicious node could easily achieve this same 443 effect in other ways. For example, it could fabricate Router 444 Advertisement messages with zero Router Lifetime from the other 445 routers, causing hosts to stop using the other routes. Hence, this 446 document has no appreciable impact on Internet infrastructure 447 security. 449 References 451 1 S. Bradner, "The Internet Standards Process -- Revision 3", BCP 452 9, RFC 2026, October 1996. 454 2 T. Narten, E. Nordmark, W. Simpson. "Neighbor Discovery for IP 455 Version 6 (IPv6)", RFC 2461, December 1998. 457 3 B. Carpenter, K. Moore. "Connection of IPv6 Domains via IPv4 458 Clouds", draft-ietf-ngtrans-6to4-07.txt, September 2000. 460 4 R. Gilligan, E. Nordmark. "Transition Mechanisms for IPv6 Hosts 461 and Routers", RFC 1933, April 1996. 463 5 G. Malkin, R. Minnear. "RIPng for IPv6", RFC 2080 , January 1997. 465 6 S. Bradner, "Key words for use in RFCs to Indicate Requirement 466 Levels", BCP 14, RFC 2119, March 1997. 468 Acknowledgments 470 The authors would like to acknowledge the contributions of Steve 471 Deering, Tony Hain, Christian Huitema, Dave Thaler, and Brian Zill. 472 The packet diagrams are derived from Neighbor Discovery [2]. 474 Author's Addresses 476 Richard Draves 477 Microsoft Research 478 One Microsoft Way 479 Redmond, WA 98052 480 Phone: 1-425-936-2268 481 Email: richdr@microsoft.com 483 Balash Akbari 484 Microsoft Corporation 485 One Microsoft Way 486 Redmond, WA 98052 487 Phone: 1-425-936-8213 488 Email: balasha@microsoft.com 489 Full Copyright Statement 491 Copyright (C) The Internet Society (2000). All Rights Reserved. 493 This document and translations of it may be copied and furnished to 494 others, and derivative works that comment on or otherwise explain it 495 or assist in its implementation may be prepared, copied, published 496 and distributed, in whole or in part, without restriction of any 497 kind, provided that the above copyright notice and this paragraph 498 are included on all such copies and derivative works. However, this 499 document itself may not be modified in any way, such as by removing 500 the copyright notice or references to the Internet Society or other 501 Internet organizations, except as needed for the purpose of 502 developing Internet standards in which case the procedures for 503 copyrights defined in the Internet Standards process must be 504 followed, or as required to translate it into languages other than 505 English. 507 The limited permissions granted above are perpetual and will not be 508 revoked by the Internet Society or its successors or assigns. 510 This document and the information contained herein is provided on an 511 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 512 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 513 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 514 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 515 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.