--- 1/draft-ietf-ipv6-router-selection-04.txt 2006-02-05 00:03:53.000000000 +0100 +++ 2/draft-ietf-ipv6-router-selection-05.txt 2006-02-05 00:03:53.000000000 +0100 @@ -1,22 +1,24 @@ IPng Working Group R. Draves Internet Draft D. Thaler -Document: draft-ietf-ipv6-router-selection-04.txt Microsoft -June 15, 2004 +Document: draft-ietf-ipv6-router-selection-05.txt Microsoft +August 10, 2004 Default Router Preferences and More-Specific Routes Status of this Memo - This document is an Internet-Draft and is in full conformance with - all provisions of Section 10 of RFC 2026. + 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." @@ -43,24 +45,25 @@ from routing tables. 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 February 2005 1 determine if a destination address is on-link and the Default Router List to select a router for off-link destinations. -Draves Expires May 2004 1 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.) This document describes an optional extension to Neighbor Discovery Router Advertisement messages for communicating default router @@ -96,24 +99,25 @@ We use Router Advertisement messages, instead of some other protocol like RIP [RFC2080], because Router Advertisements are an existing standard, stable protocol for router-to-host communication. Piggybacking this information on existing message traffic from 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 June 2004 2 lifetimes so it requires frequent message traffic with greater processing overheads. -Draves Expires June 2004 2 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]. @@ -149,26 +153,25 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Reachable Time | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Retrans Timer | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options ... +-+-+-+-+-+-+-+-+-+-+-+- Fields: +Draves Expires June 2004 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 - -Draves Expires June 2004 3 (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 the sender and MUST be ignored by the receiver. Possible Options: @@ -204,26 +207,25 @@ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Prefix (Variable Length) | . . . . +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fields: Type TBD +Draves Expires June 2004 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 - -Draves Expires June 2004 4 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 the Prefix that are valid. The value ranges from 0 to 128. The Prefix field is 0, 8, or 16 octets depending on Length. @@ -258,28 +260,27 @@ 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 June 2004 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. -Draves Expires June 2004 5 - 3. Conceptual Model of a Host There are three possible conceptual models for host implementation of default router preferences and more-specific routes, corresponding to different levels of support. We refer to these as type A, type B, and type C. 3.1. Conceptual Data Structures for Hosts Type A hosts ignore default router preferences and more-specific @@ -311,28 +312,28 @@ done as follows. 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. A route is located in the Routing Table based on prefix, prefix length, and next-hop router. 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 + +Draves Expires June 2004 6 a Route Information Option for ::/0 with a Route Lifetime of 200 seconds and a Route Preference of Low. After processing the Router 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 in its Default Router List for router X with Medium preference and lifetime - -Draves Expires June 2004 6 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. 3.2. Conceptual Sending Algorithm for Hosts Type A hosts use the conceptual sending algorithm described in @@ -363,31 +364,31 @@ 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 June 2004 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, - -Draves Expires June 2004 7 these probes MUST be rate-limited to no more than one per minute per router. This requirement allows the host to discover when router X becomes reachable and to start using router X at that point. Otherwise, the host might not notice router X's reachability and continue to use the less-desirable router Y until the next Router Advertisement is sent by X. Note that the router may have been unreachable for reasons other than being down (e.g., a switch in the middle being down), so it may be up to 30 minutes (the maximum advertisement @@ -418,31 +419,31 @@ 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 a filter is applied to their routing table to obtain the routes that are advertised to hosts. Routers SHOULD NOT send more than 17 Route Information Options in Router Advertisements per link. This arbitrary bound is meant to + +Draves Expires June 2004 8 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 through actions of system management. For instance, the lifetime or - -Draves Expires June 2004 8 preference of advertised routes may change, new routes could be added, etc. In such cases, the router MAY transmit up to MAX_INITIAL_RTR_ADVERTISEMENTS unsolicited advertisements, using the same rules as in [RFC2461]. When ceasing to be an advertising interface and sending Router Advertisements with a Router Lifetime of zero, the Router Advertisement SHOULD also set the Route Lifetime to zero in all Route Information Options. 4.1. Guidance to Administrators @@ -473,39 +474,39 @@ tunnel, and general Internet destinations will be reached via the home ISP. Without these mechanisms, the home machine might choose to 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 + +Draves Expires June 2004 9 will need to configure the settings that will work in an optimal fashion no matter which kinds of nodes will be attached. 5. Examples 5.1. Best Router for ::/0 vs Router Least Likely to Redirect The best router for the default route is the router with the best route toward the wider Internet. The router least likely to - -Draves Expires June 2004 9 redirect traffic depends on the actual traffic usage. The two concepts can be different when the majority of communication actually needs to go through some other router. For example, consider a situation where you have a link with two routers X and Y. Router X is the best for 2002::/16. (It's your 6to4 site gateway.) Router Y is the best for ::/0. (It connects to the - native IPv6 Iinternet.) Router X forwards native IPv6 traffic to + native IPv6 Internet.) Router X forwards native IPv6 traffic to router Y; router Y forwards 6to4 traffic to router X. If most traffic from this site is sent to 2002:/16 destinations, then router X is the one least likely to redirect. To make type A hosts work well, both routers should advertise themselves as default routers. In particular, if router Y goes down, type A hosts should send traffic to router X to maintain 6to4 connectivity, so router X as well as router Y needs to be a default router. @@ -529,28 +530,28 @@ ::/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. +Draves Expires June 2004 10 In this situation, a type A multi-homed host (which has no default router preferences or more-specific routes) will have no way to intelligently choose between the two routers X and Y on its Default Router List. Users of the host will see unpredictable connectivity failures, depending on the destination address and the choice of router. -Draves Expires June 2004 10 A multi-homed type C host in this same situation can correctly choose between routers X and Y, if the routers are configured appropriately. For example, router Y on the isolated network should advertise a Route Information Option for the isolated network prefix. It might not advertise itself as a default router at all (zero Router Lifetime), or it might advertise itself as a default router with Low preference. Router X should advertise itself as a default router with Medium preference. 6. Security Considerations @@ -572,42 +573,56 @@ 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. [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. Acknowledgments +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 + requested to assign a value for "TBD" in the IPv6 Neighbor Discovery + Option Formats. When the assignment has been made, the RFC Editor + +Draves Expires June 2004 11 + 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]. -8. Normative References +9. Normative References [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. -Draves Expires June 2004 11 [RFC3775] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004. -9. Informative References +10. Informative References [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001. [RFC2983] 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. @@ -628,45 +643,31 @@ Microsoft One Microsoft Way Redmond, WA 98052 Phone: +1 425 703 8835 Email: dthaler@microsoft.com Draves Expires June 2004 12 Full Copyright Statement - Copyright (C) The Internet Society (2004). All Rights Reserved. - - This document and translations of it may be copied and furnished to - others, and derivative works that comment on or otherwise explain it - or assist in its implementation may be prepared, copied, published - and distributed, in whole or in part, without restriction of any - kind, provided that the above copyright notice and this paragraph - are included on all such copies and derivative works. However, this - document itself may not be modified in any way, such as by removing - the copyright notice or references to the Internet Society or other - Internet organizations, except as needed for the purpose of - developing Internet standards in which case the procedures for - copyrights defined in the Internet Standards process must be - followed, or as required to translate it into languages other than - English. - - The limited permissions granted above are perpetual and will not be - revoked by the Internet Society or its successors or assigns. + Copyright (C) The Internet Society (2004). 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 is provided on an - "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING - TASK FORCE DISCLAIMS 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. + 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC