idnits 2.17.1 draft-ietf-ipv6-router-selection-06.txt: -(597): 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): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 665. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 676. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 683. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 689. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 657), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 34. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. 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 : ---------------------------------------------------------------------------- ** 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 (October 11, 2004) is 7137 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: 'RFC2893' is mentioned on line 89, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Unused Reference: 'RFC2983' is defined on line 628, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2461 (Obsoleted by RFC 4861) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2893 (ref. 'RFC2983') (Obsoleted by RFC 4213) Summary: 10 errors (**), 0 flaws (~~), 5 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 D. Thaler 4 Document: draft-ietf-ipv6-router-selection-06.txt Microsoft 5 October 11, 2004 7 Default Router Preferences and More-Specific Routes 9 Status of this Memo 11 By submitting this Internet-Draft, I certify that any applicable 12 patent or other IPR claims of which I am aware have been disclosed, 13 or will be disclosed, and any of which I become aware will be 14 disclosed, in accordance with RFC 3668. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six 22 months and may be updated, replaced, or obsoleted by other documents 23 at any time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 Copyright Notice 34 Copyright (C) The Internet Society (2004). All Rights Reserved. 36 Abstract 38 This document describes an optional extension to Router 39 Advertisement messages for communicating default router preferences 40 and more-specific routes from routers to hosts. This improves the 41 ability of hosts to pick an appropriate router, especially when the 42 host is multi-homed and the routers are on different links. The 43 preference values and specific routes advertised to hosts require 44 administrative configuration; they are not automatically derived 45 from routing tables. 47 1. Introduction 49 Neighbor Discovery [RFC2461] specifies a conceptual model for hosts 50 that includes a Default Router List and a Prefix List. Hosts send 51 Router Solicitation messages and receive Router Advertisement 52 messages from routers. Hosts populate their Default Router List and 53 Prefix List based on information in the Router Advertisement 54 messages. A conceptual sending algorithm uses the Prefix List to 55 determine if a destination address is on-link and the Default Router 56 List to select a router for off-link destinations. 58 In some network topologies where the host has multiple routers on 59 its Default Router List, the choice of router for an off-link 60 destination is important. In some situations, one router may provide 61 much better performance than another for a destination. In other 62 situations, choosing the wrong router may result in a failure to 63 communicate. (A later section gives specific examples of these 64 scenarios.) 66 This document describes an optional extension to Neighbor Discovery 67 Router Advertisement messages for communicating default router 68 preferences and more-specific routes from routers to hosts. This 69 improves the ability of hosts to pick an appropriate router for an 70 off-link destination. 72 Neighbor Discovery provides a Redirect message that routers can use 73 to correct a host's choice of router. A router can send a Redirect 74 message to a host, telling it to use a different router for a 75 specific destination. However, the Redirect functionality is limited 76 to a single link. A router on one link cannot redirect a host to a 77 router on another link. Hence, Redirect messages do not help multi- 78 homed (through multiple interfaces) hosts select an appropriate 79 router. 81 Multi-homed hosts are an increasingly important scenario, especially 82 with IPv6. In addition to a wired network connection, like Ethernet, 83 hosts may have one or more wireless connections, like 802.11 or 84 Bluetooth. In addition to physical network connections, hosts may 85 have virtual or tunnel network connections. For example, in addition 86 to a direct connection to the public Internet, a host may have a 87 tunnel into a private corporate network. Some IPv6 transition 88 scenarios can add additional tunnels. For example, hosts may have 89 6to4 [RFC3056] or configured tunnel [RFC2893] network connections. 91 This document requires that the preference values and specific 92 routes advertised to hosts require explicit administrative 93 configuration. They are not automatically derived from routing 94 tables. In particular, the preference values are not routing metrics 95 and it is not recommended that routers "dump out" their entire 96 routing tables to hosts. 98 We use Router Advertisement messages, instead of some other protocol 99 like RIP [RFC2080], because Router Advertisements are an existing 100 standard, stable protocol for router-to-host communication. 101 Piggybacking this information on existing message traffic from 102 routers to hosts reduces network overhead. Neighbor Discovery shares 103 with Multicast Listener Discovery the property that they both define 104 host-to-router interactions, while shielding the host from having to 105 participate in more general router-to-router interactions. In 106 addition, RIP is unsuitable because it does not carry route 107 lifetimes so it requires frequent message traffic with greater 108 processing overheads. 110 In addition, this document addresses the problem of tracking 111 reachability of a host�s routers so that it does not try to use 112 routers which it believes are unreachable. Using end-to-end 113 information is required to solve cases where the router advertises 114 itself to hosts, but the path to the desired destination is broken 115 at some other point. This problem is outside the scope of this 116 document and is left for future work. 118 The mechanisms specified here are backwards-compatible, so that 119 hosts that do not implement them continue to function as well as 120 they did previously. 122 1.1. Conventions used in this document 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 126 this document are to be interpreted as described in [RFC2119]. 128 2. Message Formats 130 2.1. Preference Values 132 Default router preferences and preferences for more-specific routes 133 are encoded the same way. 135 Preference values are encoded as a two bit signed integer, as 136 follows: 137 01 High 138 00 Medium (default) 139 11 Low 140 10 Reserved - MUST NOT be sent 141 Note that implementations can treat the value as a two-bit signed 142 integer. 144 Having just three values reinforces that they are not metrics and 145 more values do not appear to be necessary for reasonable scenarios. 147 2.2. Changes to Router Advertisement Message Format 149 The changes from Neighbor Discovery [RFC2461] section 4.2 and 150 [RFC3775] section 7.1 are as follows: 152 0 1 2 3 153 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 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Type | Code | Checksum | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Reachable Time | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Retrans Timer | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Options ... 164 +-+-+-+-+-+-+-+-+-+-+-+- 166 Fields: 168 Prf (Default Router Preference) 169 2-bit signed integer. Indicates whether or not to prefer 170 this router over other default routers. If Router 171 Lifetime is zero, the preference value MUST be set to 172 (00) by the sender and MUST be ignored by the receiver. 173 If the Reserved (10) value is received, the receiver 174 MUST treat the value as if it were (00). 176 Resvd (Reserved) 177 A 3-bit unused field. It MUST be initialized to zero by 178 the sender and MUST be ignored by the receiver. 180 Possible Options: 182 Route Information 183 These options specify prefixes that are reachable via 184 the router. 186 Discussion: 188 Note that in addition to the preference value in the message header, 189 a Router Advertisement can also contain a Route Information Option 190 for ::/0, with a preference value and lifetime. Encoding a 191 preference value in the Router Advertisement header has some 192 advantages: 194 1. It allows for a distinction between the "best router for the 195 default route" and the "router least likely to redirect common 196 traffic", as described below in section 5.1. 198 2. When the best router for the default route is also the router 199 least likely to redirect common traffic (which will be a common 200 case), encoding the preference value in the message header is more 201 efficient than having to send a separate option. 203 2.3. Route Information Option 205 0 1 2 3 206 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 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Type | Length | Prefix Length |Resvd|Prf|Resvd| 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | Route Lifetime | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | Prefix (Variable Length) | 213 . . 214 . . 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 Fields: 219 Type TBD 221 Length 8-bit unsigned integer. The length of the option 222 (including the Type and Length fields) in units of 223 8 octets. The Length field is 1, 2, or 3 depending on 224 Prefix Length. If Prefix Length is greater than 64, then 225 Length must be 3. If Prefix Length is greater than 0, 226 then Length must be 2 or 3. If Prefix Length is zero, 227 then Length must be 1, 2, or 3. 229 Prefix Length 230 8-bit unsigned integer. The number of leading bits in 231 the Prefix that are valid. The value ranges from 0 to 232 128. The Prefix field is 0, 8, or 16 octets depending on 233 Length. 235 Prf (Route Preference) 236 2-bit signed integer. The Route Preference indicates 237 whether to prefer the router associated with this prefix 238 over others, when multiple identical prefixes (for 239 different routers) have been received. If the Reserved 240 (10) value is received, the Route Information Option 241 MUST be ignored. 243 Resvd (Reserved) 244 Two 3-bit unused fields. They MUST be initialized to 245 zero by the sender and MUST be ignored by the receiver. 247 Route Lifetime 248 32-bit unsigned integer. The length of time in seconds 249 (relative to the time the packet is sent) that the 250 prefix is valid for route determination. A value of all 251 one bits (0xffffffff) represents infinity. 253 Prefix Variable-length field containing an IP address or a 254 prefix of an IP address. The Prefix Length field 255 contains the number of valid leading bits in the prefix. 257 The bits in the prefix after the prefix length (if any) 258 are reserved and MUST be initialized to zero by the 259 sender and ignored by the receiver. 261 Routers MUST NOT include two Route Information Options with the same 262 Prefix and Prefix Length in the same Router Advertisement. 264 Discussion: 266 There are several reasons for using a new Route Information Option, 267 instead of using flag bits to overload the existing Prefix 268 Information Option: 270 1. Prefixes will typically only show up in one or the other kind 271 of option, not both, so a new option does not introduce 272 duplication. 274 2. The Route Information Option is typically 16 octets while the 275 Prefix Information Option is 32 octets. 277 3. Using a new option may improve backwards-compatibility with 278 some host implementations. 280 3. Conceptual Model of a Host 282 There are three possible conceptual models for host implementation 283 of default router preferences and more-specific routes, 284 corresponding to different levels of support. We refer to these as 285 type A, type B, and type C. 287 3.1. Conceptual Data Structures for Hosts 289 Type A hosts ignore default router preferences and more-specific 290 routes. They use the conceptual data structures described in 291 Neighbor Discovery [RFC2461]. 293 Type B hosts use a Default Router List augmented with preference 294 values, but ignore all Route Information Options. They use the 295 Default Router Preference value in the Router Advertisement header. 296 They ignore Route Information Options. 298 Type C hosts use a Routing Table instead of a Default Router List. 299 (The Routing Table may also subsume the Prefix List, but that is 300 beyond the scope of this document.) Entries in the Routing Table 301 have a prefix, prefix length, preference value, lifetime, and next- 302 hop router. Type C hosts use both the Default Router Preference 303 value in the Router Advertisement header and Route Information 304 Options. 306 When a type C host receives a Router Advertisement, it modifies its 307 Routing Table as follows. When processing a Router Advertisement, a 308 type C host first updates a ::/0 route based on the Router Lifetime 309 and Default Router Preference in the Router Advertisement message 310 header. Then as the host processes Route Information Options in the 311 Router Advertisement message body, it updates its routing table for 312 each such option. The Router Preference and Lifetime values in a 313 ::/0 Route Information Option override the preference and lifetime 314 values in the Router Advertisement header. Updating each route is 315 done as follows. A route is located in the Routing Table based on 316 prefix, prefix length, and next-hop router. If the received route's 317 lifetime is zero, the route is removed from the Routing Table if 318 present. If a route's lifetime is non-zero, the route is added to 319 the Routing Table if not present and the route's lifetime and 320 preference is updated if the route is already present. 322 For example, suppose hosts receive a Router Advertisement from 323 router X with a Router Lifetime of 100 seconds and Default Router 324 Preference of Medium. The body of the Router Advertisement contains 325 a Route Information Option for ::/0 with a Route Lifetime of 200 326 seconds and a Route Preference of Low. After processing the Router 327 Advertisement, a type A host will have an entry for router X in its 328 Default Router List with lifetime 100 seconds. If a type B host 329 receives the same Router Advertisement, it will have an entry for 330 router X in its Default Router List with Medium preference and 331 lifetime 100 seconds. A type C host will have an entry in its 332 Routing Table for ::/0 -> router X, with Low preference and lifetime 333 200 seconds. A type C host MAY have a transient state, during 334 processing of the Router Advertisement, in which it has an entry in 335 its Routing Table for ::/0 -> router X with Medium preference and 336 lifetime 100 seconds. 338 3.2. Conceptual Sending Algorithm for Hosts 340 Type A hosts use the conceptual sending algorithm described in 341 Neighbor Discovery [RFC2461]. 343 When a type B host does next-hop determination and consults its 344 Default Router List, it primarily prefers reachable routers over 345 non-reachable routers and secondarily uses the router preference 346 values. If the host has no information about the router's 347 reachability then the host assumes the router is reachable. 349 When a type C host does next-hop determination and consults its 350 Routing Table for an off-link destination, it searches its routing 351 table to find the route with the longest prefix that matches the 352 destination, using route preference values as a tie-breaker if 353 multiple matching routes have the same prefix length. If the best 354 route points to a non-reachable router, this router is remembered 355 for the algorithm described in section 3.5 below, and the next best 356 route is consulted. This check is repeated until a route is found 357 that points to a reachable router, or no matching routes remain. 358 Again, if the host has no information about the router's 359 reachability then the host assumes the router is reachable. 361 If there are no routes matching the destination (i.e., no default 362 routes and no more-specific routes), then a type C host SHOULD 363 discard the packet and report a Destination Unreachable / No Route 364 To Destination error to the upper layer. 366 3.3. Destination Cache Management 368 When a type C host processes a Router Advertisement and updates its 369 conceptual Routing Table, it MUST invalidate or remove Destination 370 Cache Entries and redo next-hop determination for destinations 371 affected by the Routing Table changes. 373 3.4. Client Configurability 375 Type B and C hosts MAY be configurable with preference values that 376 override the values in Router Advertisements received. This is 377 especially useful for dealing with routers which may not support 378 preferences. 380 3.5. Router Reachability Probing 382 When a host avoids using any non-reachable router X and instead 383 sends a data packet to another router Y, and the host would have 384 used router X if router X were reachable, then the host SHOULD probe 385 each such router X's reachability by sending a single Neighbor 386 Solicitation to that router's address. A host MUST NOT probe a 387 router's reachability in the absence of useful traffic that the host 388 would have sent to the router if it were reachable. In any case, 389 these probes MUST be rate-limited to no more than one per minute per 390 router. 392 This requirement allows the host to discover when router X becomes 393 reachable and to start using router X at that point. Otherwise, the 394 host might not notice router X's reachability and continue to use 395 the less-desirable router Y until the next Router Advertisement is 396 sent by X. Note that the router may have been unreachable for 397 reasons other than being down (e.g., a switch in the middle being 398 down), so it may be up to 30 minutes (the maximum advertisement 399 period) before the next Router Advertisement would be sent. 401 For a type A host (following the algorithm in [RFC2461]), no probing 402 is needed since all routers are equally preferable. A type B or C 403 host, on the other hand, explicitly probes unreachable, preferable 404 routers to notice when they become reachable again. 406 3.6. Example 408 Suppose a type C host has four entries in its Routing Table: 409 ::/0 -> router W with Medium preference 410 2002::/16 -> router X with Medium preference 411 2001:db8::/32-> router Y with High preference 412 2001:db8::/32-> router Z with Low preference 413 and the host is sending to 2001:db8::1, an off-link destination. If 414 all routers are reachable, then the host will choose router Y. If 415 router Y is not reachable, then router Z will be chosen and the 416 reachability of router Y will be probed. If routers Y and Z are not 417 reachable, then router W will be chosen and the reachability of 418 routers Y and Z will be probed. If routers W, Y, and Z are all not 419 reachable, then the host should use Y while probing the reachability 420 of W and Z. Router X will never be chosen because its prefix does 421 not match the destination. 423 4. Router Configuration 425 Routers SHOULD NOT advertise preferences or routes by default. In 426 particular, they SHOULD NOT "dump out" their entire routing table to 427 hosts. 429 Routers SHOULD NOT send more than 17 Route Information Options in 430 Router Advertisements per link. This arbitrary bound is meant to 431 reinforce that relatively few and carefully selected routes should 432 be advertised to hosts. 434 The preference values (both Default Router Preferences and Route 435 Preferences) SHOULD NOT be routing metrics or automatically derived 436 from metrics: the preference values SHOULD be configured. 438 The information contained in Router Advertisements may change 439 through actions of system management. For instance, the lifetime or 440 preference of advertised routes may change, new routes could be 441 added, etc. In such cases, the router MAY transmit up to 442 MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the 443 same rules as in [RFC2461]. When ceasing to be an advertising 444 interface and sending Router Advertisements with a Router Lifetime 445 of zero, the Router Advertisement SHOULD also set the Route Lifetime 446 to zero in all Route Information Options. 448 4.1. Guidance to Administrators 450 The High and Low (non-default) preference values should only be used 451 when someone with knowledge of both routers and the network topology 452 configures them explicitly. For example, it could be a common 453 network administrator, or it could be a customer request to 454 different administrators managing the routers. 456 As one exception to this general rule, the administrator of a router 457 that does not have a connection to the Internet, or is connected 458 through a firewall that blocks general traffic, should configure the 459 router to advertise a Low Default Router Preference. 461 In addition, the administrator of a router should configure the 462 router to advertise a specific route for the site prefix of the 463 network(s) to which the router belongs. The administrator may also 464 configure the router to advertise specific routes for directly 465 connected subnets and any shorter prefixes for networks to which the 466 router belongs. 468 For example, if a home user sets up a tunnel into a firewalled 469 corporate network, the access router on the corporate network end of 470 the tunnel should advertise itself as a default router, but with a 471 Low preference. Furthermore the corporate router should advertise a 472 specific route for the corporate site prefix. The net result is that 473 destinations in the corporate network will be reached via the 474 tunnel, and general Internet destinations will be reached via the 475 home ISP. Without these mechanisms, the home machine might choose to 476 send Internet traffic into the corporate network or corporate 477 traffic into the Internet, leading to communication failure because 478 of the firewall. 480 It is worth noting that the network administrator setting up 481 preferences and/or more specific routes in Routing Advertisements 482 typically does not know which kind of nodes (Type A, B, and/or C) 483 will be connected to its links. This requires that the administrator 484 will need to configure the settings that will work in an optimal 485 fashion no matter which kinds of nodes will be attached. Two 486 examples of how to do so follow. 488 5. Examples 490 5.1. Best Router for ::/0 vs Router Least Likely to Redirect 492 The best router for the default route is the router with the best 493 route toward the wider Internet. The router least likely to 494 redirect traffic depends on the actual traffic usage. The two 495 concepts can be different when the majority of communication 496 actually needs to go through some other router. 498 For example, consider a situation where you have a link with two 499 routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 500 site gateway.) Router Y is the best for ::/0. (It connects to the 501 native IPv6 Internet.) Router X forwards native IPv6 traffic to 502 router Y; router Y forwards 6to4 traffic to router X. If most 503 traffic from this site is sent to 2002:/16 destinations, then router 504 X is the one least likely to redirect. 506 To make type A hosts work well, both routers should advertise 507 themselves as default routers. In particular, if router Y goes down, 508 type A hosts should send traffic to router X to maintain 6to4 509 connectivity, so router X as well as router Y needs to be a default 510 router. 512 To make type B hosts work well, router X should in addition 513 advertise itself with a High default router preference. This will 514 cause type B hosts to prefer router X, minimizing the number of 515 redirects. 517 To make type C hosts work well, router X should in addition 518 advertise the ::/0 route with Low preference and the 2002::/16 route 519 with Medium preference. A type C host will end up with three routes 520 in its routing table: ::/0 -> router X (Low), ::/0 -> router Y 521 (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic 522 to router X and other traffic to router Y. Type C hosts will not 523 cause any redirects. 525 Note that when type C hosts process the Router Advertisement from 526 router X, the Low preference for ::/0 overrides the High default 527 router preference. If the ::/0 specific route were not present, then 528 a type C host would apply the High default router preference to its 529 ::/0 route to router X. 531 5.2. Multi-Homed Host and Isolated Network 533 In another scenario, a multi-homed host is connected to the Internet 534 via router X on one link and to an isolated network via router Y on 535 another link. The multi-homed host might have a tunnel into a 536 firewalled corporate network, or it might be directly connected to 537 an isolated test network. 539 In this situation, a type A multi-homed host (which has no default 540 router preferences or more-specific routes) will have no way to 541 intelligently choose between the two routers X and Y on its Default 542 Router List. Users of the host will see unpredictable connectivity 543 failures, depending on the destination address and the choice of 544 router. 546 A multi-homed type B hose in this same situation would have stable 547 Internet connectivity, if the routers are configured appropriately, 548 but would have no connectivity to the isolated test network. 550 A multi-homed type C host in this same situation can correctly 551 choose between routers X and Y, if the routers are configured 552 appropriately. For example, router Y on the isolated network should 553 advertise a Route Information Option for the isolated network 554 prefix. It might not advertise itself as a default router at all 555 (zero Router Lifetime), or it might advertise itself as a default 556 router with Low preference. Router X should advertise itself as a 557 default router with Medium preference. 559 6. Security Considerations 561 A malicious node could send Router Advertisement messages, 562 specifying High Default Router Preference or carrying specific 563 routes, with the effect of pulling traffic away from legitimate 564 routers. However, a malicious node could easily achieve this same 565 effect in other ways. For example, it could fabricate Router 566 Advertisement messages with zero Router Lifetime from the other 567 routers, causing hosts to stop using the other routes. By 568 advertising a specific prefix, this attack could be carried out in a 569 less noticeable way. However, this attack has no significant 570 incremental impact on Internet infrastructure security. 572 A malicious node could also include an infinite lifetime in a Route 573 Information Option causing the route to linger indefinitely. A 574 similar attack already exists with Prefix Information Options in 575 RFC2461, where a malicious node causes a prefix to appear as on-link 576 indefinitely, resulting in lack of connectivity if it is not. In 577 contrast, an infinite lifetime in a Route Information Option will 578 cause router reachability probing to continue indefinitely, but will 579 not result in lack of connectivity. 581 Similarly, a malicious node could also try to overload hosts with a 582 large number of routes in Route Information Options, or with very 583 frequent Route Advertisements. Again this same attack already 584 exists with Prefix Information Options. 586 [RFC3756] provides more details on the trust models, and there is 587 work in progress in the SEND WG on securing router discovery 588 messages that will address these problems. 590 7. IANA Considerations 592 Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the 593 Route Information Option, which has been assigned the value TBD 594 within the numbering space for IPv6 Neighbor Discovery Option 595 Formats. 597 RFC EDITOR�s NOTE (to be removed prior to publication): the IANA is 598 requested to assign a value for "TBD" in the IPv6 Neighbor Discovery 599 Option Formats. When the assignment has been made, the RFC Editor 600 is asked to replace "TBD" (above in this section, and in section 601 2.3) with the assigned value and to remove this note. 603 8. Acknowledgments 605 The authors would like to acknowledge the contributions of Balash 606 Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian 607 Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir 608 Segaric, and Brian Zill. The packet diagrams are derived from 609 Neighbor Discovery [RFC2461]. 611 9. Normative References 613 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 614 Discovery for IP Version 6 (IPv6)", RFC 2461, December 615 1998. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support 621 in IPv6", RFC 3775, June 2004. 623 10. Informative References 625 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 626 via IPv4 Clouds", RFC 3056, February 2001. 628 [RFC2983] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 629 IPv6 Hosts and Routers", RFC 2893, August 2000. 631 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 632 January 1997. 634 [RFC3756] Nikander, P., Ed., Kempf, J. and E. Nordmark, "IPv6 635 Neighbor Discovery (ND) Trust Models and Threats", RFC 636 3756, May 2004. 638 Authors' Addresses 640 Richard Draves 641 Microsoft Research 642 One Microsoft Way 643 Redmond, WA 98052 644 Phone: +1 425 706 2268 645 Email: richdr@microsoft.com 647 Dave Thaler 648 Microsoft 649 One Microsoft Way 650 Redmond, WA 98052 651 Phone: +1 425 703 8835 652 Email: dthaler@microsoft.com 653 Full Copyright Statement 655 Copyright (C) The Internet Society (2004). This document is subject 656 to the rights, licenses and restrictions contained in BCP 78, and 657 except as set forth therein, the authors retain all their rights. 659 This document and the information contained herein are provided on 660 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 661 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE 662 INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR 663 IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 664 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 665 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 667 Intellectual Property 669 The IETF takes no position regarding the validity or scope of any 670 Intellectual Property Rights or other rights that might be claimed 671 to pertain to the implementation or use of the technology described 672 in this document or the extent to which any license under such 673 rights might or might not be available; nor does it represent that 674 it has made any independent effort to identify any such rights. 675 Information on the procedures with respect to rights in RFC 676 documents can be found in BCP 78 and BCP 79. 678 Copies of IPR disclosures made to the IETF Secretariat and any 679 assurances of licenses to be made available, or the result of an 680 attempt made to obtain a general license or permission for the use 681 of such proprietary rights by implementers or users of this 682 specification can be obtained from the IETF on-line IPR repository 683 at http://www.ietf.org/ipr. 685 The IETF invites any interested party to bring to its attention any 686 copyrights, patents or patent applications, or other proprietary 687 rights that may cover technology that may be required to implement 688 this standard. Please address the information to the IETF at ietf- 689 ipr@ietf.org.