Internet Engineering Task Force Nigel Bragg Internet Draft Nortel Networks Document: November 2000 Routing support for IPv6 Multi-homing Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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." 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. This document will expire before May 2000. Distribution of this draft is unlimited. 1. Abstract The IPv6 Addressing scheme mandates provider addressing to achieve aggregation. Multi-homing is a fact of life. Current proposals to reconcile these requirements involve mitigation, by constraining deployment topologies to avoid loss of aggregation in the backbone only. This draft views the combined requirement as equivalent to the use of loose source routing by hosts, and makes some outline proposals as to how this can be achieved. 2. 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 RFC-2119 [1]. Bragg 1 Routing support for IPv6 Multi-homing November 2000 3. Introduction The addressing scheme of IPv6 [2] is motivated by the need to perform the aggressive route aggregation required to keep routing tables in the default-free zone of the Internet to a manageable size. This leads to "provider addressing", a consequence of which is that nodes with multiple connections to the Internet via multiple Service Providers have multiple addresses, with a global prefix inherited from each provider's address space. However, multi-homed nodes must make their selections of address for communication in ignorance of the actual state of the network. This can result under fault conditions in a multi-homed node becoming unreachable by a corresponding node, even though connectivity exists, which directly contradicts one of the major motivations for multi-homing. Other authors eg [3][4], have demonstrated that the "traditional" solution to this problem is incompatible with the route aggregation objectives of IPv6, because it requires the explicit exposure of the prefix of the multi-homed entity in the default-free zone. A solution is presented in [4]. However, this solution requires a bilateral agreement between the two Service Providers directly serving a multi-homed client network; it also leaves the client critically dependent on one of them. This document describes an alternative more general solution, which builds on the analysis given in [3]. 4. Problem statement The problem is illustrated in conjunction with the figure below; although the scenario illustrated is simple, the proposed solution generalises to any depth of address space delegation or number of routes. TLA1 TLA2 /|\ /|\ | | | | NLA1 NLA2 /|\ /|\ \____/ \ / NLA3 | H Any node within NLA3 will inherit two prefixes of the form: Tx:Nx:N3::/16+nx+n3 (x=1,2, where Tx is the prefix of TLAx, etc) Bragg 2 Routing support for IPv6 Multi-homing November 2000 Consider the communications of node H with a corresponding node elsewhere on the Internet. If the path TLA1 to NLA1 fails, the address of H with the prefix derived from TLA1 becomes unreachable. If the corresponding node initiates communication using that address, it can be expected to re-try using the alternative address (delegated from TLA2, etc) on receipt of an ICMP unreachable message, and no great harm is done. However, if H initiates communication, local routing mechanisms within NLA3 will deliver outbound packets upwards via TLA2, but potentially selecting the unreachable source address as a result of the mechanisms defined in [5]; no communication can be established, and H will receive no indication of the cause, even though it is H's choice of address that is a contributory factor. If the fault occurs during an established communication, once again H receives no indication of the cause of failure, and so no clue as to a viable recovery strategy. This proposal addresses these cases, which are at root caused by node H unwittingly using a valid but unreachable address. 5. Routing-based Solution The essence of the concept is that each AS advertises its own prefix as a route downwards through all border routers offering transit facilities to lower level aggregators, and also propagates down to lower level aggregators the prefixes of this type received from higher level aggregator(s). Referring to the figure: TLA1 advertises T1::/16 to NLA1, NLA1 advertises T1:N1::/16+n1 and propagates T1::/16 to NLA3, TLA2 advertises T2::/16 to NLA2, NLA2 advertises T2:N2::/16+n2 and propagates T2::/16 to NLA3. This is clearly redundant for upward routing purposes (TLA1 will advertise ::/0 downwards to subtended NLAs), but the semantic is subtly different; a recipient of this advertisement can infer that traffic routed from the general Internet using an address derived from the received prefix can reach him, which is precisely the indication we are seeking to provide. Conversely, withdrawal of a route of this type indicates to the receiving AS that the addresses inherited as a result of the connectivity represented by that route are no longer reachable from the Internet at large. - this is entirely consistent with the IPv6 addressing scheme; when a multi-homed node selects a Source Address, it is defining a loose source route for the return path, and this proposal is ensuring that the status of that return path, over its most sensitive region, is known Bragg 3 Routing support for IPv6 Multi-homing November 2000 These routes should not be aggregated by an AS. Within an AS, these routes are injected into the IGP for distribution. The lack of aggregation is not seen as a problem, because the number of routes required in any one AS is only one per aggregator (total, over all the chains by which the AS inherits its address spaces). Normal routing mechanisms will then ensure that fault propagation is minimised. So, if there are two paths from TLA1 to NLA1 in the earlier figure, and only one fails, the effects are limited to local recovery (there is still a route from T1::/16, and the address space inherited from TLA1 is still reachable from TLA1). So far, the scheme as outlined propagates upward reachability only throughout the routing network, and has not so far reached the hosts which must use it in source address selection. A simple strategy would be to inject and propagate down only the top-level prefix (Tx::/16), and use this single indicator of reachability from the general Internet. Defined host auto- configuration mechanisms [6] allow routers to set the lifetime of the affected global prefix to zero, thus causing the derived host addresses to become deprecated. However, this simple strategy will not yield the most robust behaviour. Referring to the figure, and recalling that the path TLA1 to NLA1 has failed, what if the corresponding node is actually within, or on a network subtended by, NLA1 ? If the corresponding node is single homed, the address of H derived from the "faulted" prefix T1::/16 is precisely the one that must be used in communication (it may of course be that the fault causing the loss of T1::/16 lies within NLA1, and will actually render communication impossible, but an assumption of connectivity within NLA1 is the best chance on offer). The full mechanism described earlier, where each aggregator in the hierarchy injects a route defined by its own prefix, would allow a host to handle this condition. This is described informally below as extensions to the address selection procedures defined in [5]. TLA1 TLA2 /|\ /|\ | X | | NLA1 NLA2 /|\ /|\ \____/ \ \ / \ NLA3 D | H Source Address selection for a Destination D - add initial logic : Bragg 4 Routing support for IPv6 Multi-homing November 2000 FOR each faulted route to backbone /* ie Tx::/16 prefix withdrawn)*/ IF prefixmatch (D, shortest remaining prefix on that route) /* the destination D is connected below the fault */ THEN leave Source Address from faulted route in Candidate Set /* and assume that it will be selected in preference to other global scope addresses because of longest prefix match */ ELSE remove Source Address from faulted route from Candidate Set It does not appear that any explicit modifications are required to the Destination Address selection process. If D is single homed, the NLA3 routing system must route packets to D via NLA2, and the source address selection procedure above will provide a usable return path. If D is itself dual-homed (by a second route not shown above), the choice of destination address will drive the Source Address selection appropriately. In the event that the fault occurs during a session, the host can use the IP Mobility mechanisms defined in [7] to preserve the session, by selecting a reachable care-of address. This scheme is more robust, but requires extension of existing router-host communication mechanisms. A straightforward approach is to extend the semantics of the Router Advertisement message's Prefix Option [6]. Already used for interface auto-configuration, the Option could be extended to allow prefixes to define reachability as described above. 6. Security Considerations Because this scheme uses existing routing protocols, it is not believed that it raises new security issues in this area. However, the use of Router Advertisements to convey reachability information to hosts raises the denial of service threats addressed in [6]; indeed, these are more acute, because ignoring short lifetime prefixes is not a valid option for reachability information. Accordingly, use of these mechanisms will require the existence of a Security Association between router and host as described in [6]. Similarly, the use of IP Mobility mechanisms to maintain existing connections does not raise any additional security concerns over and above those described in [7], but does require there to be Security Associations between the multi-homed host and any destination where service is to be maintained across a failure Bragg 5 Routing support for IPv6 Multi-homing November 2000 7. References 1. Bradner, S, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, Harvard University, March 1997 2. R. Hinden, M. O'Dell, S. Deering, "An IPv6 Aggregatable Global Unicast Address Format", RFC 2374, July 1998 3. F. Dupont, "Multihomed routing domain issues for IPv6 aggregatable scheme", , September 1999 4. J. Yu, "IPv6 Multihoming with Route Aggregation", , August 2000 5. R. Draves, "Default Address Selection for IPv6", , July 2000 6. S. Thomson, T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998 7. D. Johnson, C. Perkins, "Mobility Support in IPv6", , April 2000 8. Acknowledgments The use of the Mobility mechanism for maintaining connections was suggested by Elwyn Davies, Nortel Networks. 9. Author's Addresses Nigel Bragg Nortel Networks plc Harlow Laboratories London Road Harlow Essex CM17 9NA U.K Email: nigel.bragg@nortelnetworks.com Bragg 6