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