--- 1/draft-ietf-ipv6-router-selection-06.txt 2006-02-05 00:03:55.000000000 +0100 +++ 2/draft-ietf-ipv6-router-selection-07.txt 2006-02-05 00:03:55.000000000 +0100 @@ -1,15 +1,15 @@ IPng Working Group R. Draves Internet Draft D. Thaler -Document: draft-ietf-ipv6-router-selection-06.txt Microsoft -October 11, 2004 +Document: draft-ietf-ipv6-router-selection-07.txt Microsoft +January 17, 2005 Default Router Preferences and More-Specific Routes Status of this Memo 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. @@ -24,21 +24,21 @@ material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Copyright Notice - Copyright (C) The Internet Society (2004). All Rights Reserved. + Copyright (C) The Internet Society (2005). All Rights Reserved. Abstract This document describes an optional extension to Router Advertisement messages for communicating default router preferences and more-specific routes from routers to hosts. This improves the ability of hosts to pick an appropriate router, especially when the host is multi-homed and the routers are on different links. The preference values and specific routes advertised to hosts require administrative configuration; they are not automatically derived @@ -46,21 +46,21 @@ 1. Introduction Neighbor Discovery [RFC2461] specifies a conceptual model for hosts that includes a Default Router List and a Prefix List. Hosts send Router Solicitation messages and receive Router Advertisement messages from routers. Hosts populate their Default Router List and Prefix List based on information in the Router Advertisement messages. A conceptual sending algorithm uses the Prefix List to -Draves Expires April 2005 1 +Draves Expires July 2005 1 determine if a destination address is on-link and the Default Router List to select a router for off-link destinations. In some network topologies where the host has multiple routers on its Default Router List, the choice of router for an off-link destination is important. In some situations, one router may provide much better performance than another for a destination. In other situations, choosing the wrong router may result in a failure to communicate. (A later section gives specific examples of these scenarios.) @@ -104,28 +104,20 @@ routers to hosts reduces network overhead. Neighbor Discovery shares with Multicast Listener Discovery the property that they both define host-to-router interactions, while shielding the host from having to participate in more general router-to-router interactions. In addition, RIP is unsuitable because it does not carry route Draves Expires April 2005 2 lifetimes so it requires frequent message traffic with greater processing overheads. - In addition, this document addresses the problem of tracking - reachability of a hostĘs routers so that it does not try to use - routers which it believes are unreachable. Using end-to-end - information is required to solve cases where the router advertises - itself to hosts, but the path to the desired destination is broken - at some other point. This problem is outside the scope of this - document and is left for future work. - The mechanisms specified here are backwards-compatible, so that hosts that do not implement them continue to function as well as they did previously. 1.1. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. @@ -146,37 +138,37 @@ integer. Having just three values reinforces that they are not metrics and more values do not appear to be necessary for reasonable scenarios. 2.2. Changes to Router Advertisement Message Format The changes from Neighbor Discovery [RFC2461] section 4.2 and [RFC3775] section 7.1 are as follows: -Draves Expires April 2005 3 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Cur Hop Limit |M|O|H|Prf|Resvd| Router Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Fields: +Draves Expires April 2005 3 Prf (Default Router Preference) 2-bit signed integer. Indicates whether or not to prefer this router over other default routers. If Router Lifetime is zero, the preference value MUST be set to (00) by the sender and MUST be ignored by the receiver. If the Reserved (10) value is received, the receiver MUST treat the value as if it were (00). Resvd (Reserved) A 3-bit unused field. It MUST be initialized to zero by @@ -198,40 +190,39 @@ 1. It allows for a distinction between the "best router for the default route" and the "router least likely to redirect common traffic", as described below in section 5.1. 2. When the best router for the default route is also the router least likely to redirect common traffic (which will be a common case), encoding the preference value in the message header is more efficient than having to send a separate option. -Draves Expires April 2005 4 - 2.3. Route Information Option 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Prefix Length |Resvd|Prf|Resvd| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Route Lifetime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBD +Draves Expires April 2005 4 Length 8-bit unsigned integer. The length of the option (including the Type and Length fields) in units of 8 octets. The Length field is 1, 2, or 3 depending on Prefix Length. If Prefix Length is greater than 64, then Length must be 3. If Prefix Length is greater than 0, then Length must be 2 or 3. If Prefix Length is zero, then Length must be 1, 2, or 3. Prefix Length 8-bit unsigned integer. The number of leading bits in @@ -253,39 +244,38 @@ Route Lifetime 32-bit unsigned integer. The length of time in seconds (relative to the time the packet is sent) that the prefix is valid for route determination. A value of all one bits (0xffffffff) represents infinity. Prefix Variable-length field containing an IP address or a prefix of an IP address. The Prefix Length field contains the number of valid leading bits in the prefix. - -Draves Expires April 2005 5 The bits in the prefix after the prefix length (if any) are reserved and MUST be initialized to zero by the sender and ignored by the receiver. Routers MUST NOT include two Route Information Options with the same Prefix and Prefix Length in the same Router Advertisement. Discussion: There are several reasons for using a new Route Information Option, instead of using flag bits to overload the existing Prefix Information Option: 1. Prefixes will typically only show up in one or the other kind of option, not both, so a new option does not introduce duplication. +Draves Expires April 2005 5 2. The Route Information Option is typically 16 octets while the Prefix Information Option is 32 octets. 3. Using a new option may improve backwards-compatibility with some host implementations. 3. Conceptual Model of a Host There are three possible conceptual models for host implementation of default router preferences and more-specific routes, @@ -308,39 +298,39 @@ beyond the scope of this document.) Entries in the Routing Table have a prefix, prefix length, preference value, lifetime, and next- hop router. Type C hosts use both the Default Router Preference value in the Router Advertisement header and Route Information Options. When a type C host receives a Router Advertisement, it modifies its Routing Table as follows. When processing a Router Advertisement, a type C host first updates a ::/0 route based on the Router Lifetime and Default Router Preference in the Router Advertisement message - -Draves Expires April 2005 6 header. Then as the host processes Route Information Options in the Router Advertisement message body, it updates its routing table for each such option. The Router Preference and Lifetime values in a ::/0 Route Information Option override the preference and lifetime values in the Router Advertisement header. Updating each route is done as follows. A route is located in the Routing Table based on prefix, prefix length, and next-hop router. If the received route's lifetime is zero, the route is removed from the Routing Table if present. If a route's lifetime is non-zero, the route is added to the Routing Table if not present and the route's lifetime and preference is updated if the route is already present. For example, suppose hosts receive a Router Advertisement from router X with a Router Lifetime of 100 seconds and Default Router Preference of Medium. The body of the Router Advertisement contains a Route Information Option for ::/0 with a Route Lifetime of 200 seconds and a Route Preference of Low. After processing the Router + +Draves Expires April 2005 6 Advertisement, a type A host will have an entry for router X in its Default Router List with lifetime 100 seconds. If a type B host receives the same Router Advertisement, it will have an entry for router X in its Default Router List with Medium preference and lifetime 100 seconds. A type C host will have an entry in its Routing Table for ::/0 -> router X, with Low preference and lifetime 200 seconds. A type C host MAY have a transient state, during processing of the Router Advertisement, in which it has an entry in its Routing Table for ::/0 -> router X with Medium preference and lifetime 100 seconds. @@ -356,46 +346,46 @@ values. If the host has no information about the router's reachability then the host assumes the router is reachable. When a type C host does next-hop determination and consults its Routing Table for an off-link destination, it searches its routing table to find the route with the longest prefix that matches the destination, using route preference values as a tie-breaker if multiple matching routes have the same prefix length. If the best route points to a non-reachable router, this router is remembered for the algorithm described in section 3.5 below, and the next best - route is consulted. This check is repeated until a route is found - that points to a reachable router, or no matching routes remain. - Again, if the host has no information about the router's + route is consulted. This check is repeated until a matching route + is found that points to a reachable router, or no matching routes + remain. Again, if the host has no information about the router's reachability then the host assumes the router is reachable. If there are no routes matching the destination (i.e., no default routes and no more-specific routes), then a type C host SHOULD - -Draves Expires April 2005 7 discard the packet and report a Destination Unreachable / No Route To Destination error to the upper layer. 3.3. Destination Cache Management When a type C host processes a Router Advertisement and updates its conceptual Routing Table, it MUST invalidate or remove Destination Cache Entries and redo next-hop determination for destinations affected by the Routing Table changes. 3.4. Client Configurability Type B and C hosts MAY be configurable with preference values that override the values in Router Advertisements received. This is especially useful for dealing with routers which may not support preferences. +Draves Expires April 2005 7 + 3.5. Router Reachability Probing When a host avoids using any non-reachable router X and instead sends a data packet to another router Y, and the host would have used router X if router X were reachable, then the host SHOULD probe each such router X's reachability by sending a single Neighbor Solicitation to that router's address. A host MUST NOT probe a router's reachability in the absence of useful traffic that the host would have sent to the router if it were reachable. In any case, these probes MUST be rate-limited to no more than one per minute per @@ -418,35 +408,45 @@ 3.6. Example Suppose a type C host has four entries in its Routing Table: ::/0 -> router W with Medium preference 2002::/16 -> router X with Medium preference 2001:db8::/32-> router Y with High preference 2001:db8::/32-> router Z with Low preference and the host is sending to 2001:db8::1, an off-link destination. If all routers are reachable, then the host will choose router Y. If router Y is not reachable, then router Z will be chosen and the - -Draves Expires April 2005 8 reachability of router Y will be probed. If routers Y and Z are not reachable, then router W will be chosen and the reachability of routers Y and Z will be probed. If routers W, Y, and Z are all not reachable, then the host should use Y while probing the reachability of W and Z. Router X will never be chosen because its prefix does not match the destination. 4. Router Configuration Routers SHOULD NOT advertise preferences or routes by default. In particular, they SHOULD NOT "dump out" their entire routing table to hosts. + Routers MAY have a configuration mode where announcement of a + specific prefix is dependent on a specific condition, such as + operational status of a link or presence of the same or another + prefix in the routing table installed by another source, such as a + +Draves Expires April 2005 8 + dynamic routing protocol. If done, router implementations SHOULD + make sure that announcement of prefixes to hosts is decoupled from + the routing table dynamics to prevent excessive load on hosts during + periods of routing instability. In particular, unstable routes + SHOULD NOT be announced to hosts until their stability has improved. + Routers SHOULD NOT send more than 17 Route Information Options in Router Advertisements per link. This arbitrary bound is meant to reinforce that relatively few and carefully selected routes should be advertised to hosts. The preference values (both Default Router Preferences and Route Preferences) SHOULD NOT be routing metrics or automatically derived from metrics: the preference values SHOULD be configured. The information contained in Router Advertisements may change @@ -472,29 +472,30 @@ through a firewall that blocks general traffic, should configure the router to advertise a Low Default Router Preference. In addition, the administrator of a router should configure the router to advertise a specific route for the site prefix of the network(s) to which the router belongs. The administrator may also configure the router to advertise specific routes for directly connected subnets and any shorter prefixes for networks to which the router belongs. -Draves Expires April 2005 9 For example, if a home user sets up a tunnel into a firewalled corporate network, the access router on the corporate network end of the tunnel should advertise itself as a default router, but with a Low preference. Furthermore the corporate router should advertise a specific route for the corporate site prefix. The net result is that destinations in the corporate network will be reached via the tunnel, and general Internet destinations will be reached via the home ISP. Without these mechanisms, the home machine might choose to + +Draves Expires April 2005 9 send Internet traffic into the corporate network or corporate traffic into the Internet, leading to communication failure because of the firewall. It is worth noting that the network administrator setting up preferences and/or more specific routes in Routing Advertisements typically does not know which kind of nodes (Type A, B, and/or C) will be connected to its links. This requires that the administrator will need to configure the settings that will work in an optimal fashion no matter which kinds of nodes will be attached. Two @@ -526,29 +527,29 @@ To make type B hosts work well, router X should in addition advertise itself with a High default router preference. This will cause type B hosts to prefer router X, minimizing the number of redirects. To make type C hosts work well, router X should in addition advertise the ::/0 route with Low preference and the 2002::/16 route with Medium preference. A type C host will end up with three routes in its routing table: ::/0 -> router X (Low), ::/0 -> router Y - -Draves Expires April 2005 10 (Medium), 2002::/16 -> router X (Medium). It will send 6to4 traffic to router X and other traffic to router Y. Type C hosts will not cause any redirects. Note that when type C hosts process the Router Advertisement from router X, the Low preference for ::/0 overrides the High default router preference. If the ::/0 specific route were not present, then + +Draves Expires April 2005 10 a type C host would apply the High default router preference to its ::/0 route to router X. 5.2. Multi-Homed Host and Isolated Network In another scenario, a multi-homed host is connected to the Internet via router X on one link and to an isolated network via router Y on another link. The multi-homed host might have a tunnel into a firewalled corporate network, or it might be directly connected to an isolated test network. @@ -581,83 +582,82 @@ routers. However, a malicious node could easily achieve this same effect in other ways. For example, it could fabricate Router Advertisement messages with zero Router Lifetime from the other routers, causing hosts to stop using the other routes. By advertising a specific prefix, this attack could be carried out in a less noticeable way. However, this attack has no significant incremental impact on Internet infrastructure security. A malicious node could also include an infinite lifetime in a Route Information Option causing the route to linger indefinitely. A - -Draves Expires April 2005 11 similar attack already exists with Prefix Information Options in RFC2461, where a malicious node causes a prefix to appear as on-link indefinitely, resulting in lack of connectivity if it is not. In contrast, an infinite lifetime in a Route Information Option will cause router reachability probing to continue indefinitely, but will not result in lack of connectivity. +Draves Expires April 2005 11 Similarly, a malicious node could also try to overload hosts with a large number of routes in Route Information Options, or with very frequent Route Advertisements. Again this same attack already exists with Prefix Information Options. [RFC3756] provides more details on the trust models, and there is work in progress in the SEND WG on securing router discovery messages that will address these problems. 7. IANA Considerations Section 2.3 defines a new Neighbor Discovery [RFC2461] option, the Route Information Option, which has been assigned the value TBD within the numbering space for IPv6 Neighbor Discovery Option Formats. - RFC EDITORĘs NOTE (to be removed prior to publication): the IANA is + RFC EDITOR's NOTE (to be removed prior to publication): the IANA is requested to assign a value for "TBD" in the IPv6 Neighbor Discovery Option Formats. When the assignment has been made, the RFC Editor is asked to replace "TBD" (above in this section, and in section 2.3) with the assigned value and to remove this note. 8. Acknowledgments The authors would like to acknowledge the contributions of Balash Akbari, Steve Deering, Robert Elz, Tony Hain, Bob Hinden, Christian Huitema, JINMEI Tatuya, Erik Nordmark, Pekka Savola, Kresimir Segaric, and Brian Zill. The packet diagrams are derived from Neighbor Discovery [RFC2461]. 9. Normative References + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate - Requirement Levels", BCP 14, RFC 2119, March 1997. - [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. 10. Informative References - [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains - via IPv4 Clouds", RFC 3056, February 2001. + [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, + January 1997. -Draves Expires April 2005 12 - [RFC2983] Gilligan, R. and E. Nordmark, "Transition Mechanisms for + [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 2893, August 2000. - [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, - January 1997. + [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains + via IPv4 Clouds", RFC 3056, February 2001. +Draves Expires April 2005 12 [RFC3756] Nikander, P., Ed., Kempf, J. and E. Nordmark, "IPv6 Neighbor Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. Authors' Addresses Richard Draves Microsoft Research One Microsoft Way Redmond, WA 98052 @@ -668,21 +668,21 @@ Microsoft One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8835 Email: dthaler@microsoft.com Draves Expires April 2005 13 Full Copyright Statement - Copyright (C) The Internet Society (2004). This document is subject + Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.