IPv6 Multihoming with Source Address Dependent Routing (SADR)
Author(s): Lorenzo Colitti, Ole Troan
A multihomed network using provider aggregatable addresses must send the packet out the right path to avoid violating the provider's ingress filtering. This memo suggests a mechanism called Source Address Dependent Routing to solve that problem....
Homenet working Group O. Troan Internet-Draft Cisco Systems Intended status: Informational L. Colitti Expires: August 22, 2013 Google February 18, 2013 IPv6 Multihoming with Source Address Dependent Routing (SADR) draft-troan-homenet-sadr-00 Abstract A multihomed network using provider aggregatable addresses must send the packet out the right path to avoid violating the provider's ingress filtering. This memo suggests a mechanism called Source Address Dependent Routing to solve that problem. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on August 22, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 Troan & Colitti Expires August 22, 2013 [Page 1] Internet-Draft SADR February 2013 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 4. Using SADR for multihoming . . . . . . . . . . . . . . . . . . 3 5. A Conceptual Forwarding Algorithm . . . . . . . . . . . . . . 3 6. Routing considerations . . . . . . . . . . . . . . . . . . . . 4 6.1. Routing Protocol extensions . . . . . . . . . . . . . . . 5 6.2. Simplified SADR in home networks . . . . . . . . . . . . . 5 7. Interaction between routers and hosts . . . . . . . . . . . . 5 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 11.2. Informative References . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 1. Introduction IPv6 is designed to support multiple addresses on an interface, and the intention was to use this feature to support multihoming with provider aggregatable addresses. One difficulty of multihoming with provider-aggregatable space is that providers typically employ BCP38 [RFC2827] filtering. If a network sends traffic to its upstream provider using a source address that was not assigned by that provider, the traffic will be dropped. Thus, if a network is multihomed to multiple providers, it must ensure that traffic is sent out the correct exit for the packet's source address. As long as upstream traffic is sent to the correct provider, hosts inside the network are free to use source addresses assigned by any of the network's upstream providers. In such a scenario, each host has multiple addresses, one or more from each provider the network is connected to. The network ensures that packets are sent to the correct upstream by forwarding packets based on the destination address and the source address. This we call source address dependent routing (SADR). This memo shows how SADR can be used to implement multihoming. 2. Conventions 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 [RFC 2119]. 3. Terminology Service Provider An entity that provides the network with external connectivity, e.g. to the Internet. Troan & Colitti Expires August 22, 2013 [Page 2] Internet-Draft SADR February 2013 WAN Interface An interface connected to a Service Providers. WAN interfaces may either be physical links or virtual interfaces such as tunnels. WAN interfaces are used to send ingress traffic from the Internet to the End- User, and egress traffic from the End-User network to the Internet. Ingress traffic may be received on any active interface at any time. Egress traffic follows a set of rules within the router in order to choose the proper WAN interface. Border Router A border router has one or more external interfaces connecting it to one or more Service Providers. The border router receives one or more delegated prefixes, each associated with one or more WAN interfaces. External Route A route that is learned from a Service Provider. Each External Route has an Acceptable Source Prefix which determines which source addresses may use that route. Internal Router A router that is not a Border Router. Internal Route A route to a destination inside the network. 4. Using SADR for multihoming SADR is similar to policy based routing. This memo proposes a simple extension to the destination based longest match algorithm to constrain it to source address. In order to support ingress filtering by upstream networks, the network MUST treat external routes specially. Ingress filtering MAY also be used internally, by installing (S,D) routes for locally assigned prefixes, where the source prefix would be the aggregatable prefix. If no ingress filtering is performed inside the network, then normal non-source constrained forwarding is used. 5. A Conceptual Forwarding Algorithm This section describes a conceptual forwarding algorithm. An implementation might implement this differently, e.g. with multiple tables, as long as the external behaviour is as described. First a longest match lookup is done in the routing table for the destination address, then for the resulting set a longest matching lookup is done for the source address. Troan & Colitti Expires August 22, 2013 [Page 3] Internet-Draft SADR February 2013 In a destination based routing table, an entry in the routing table can be shown as "D -> NH". That is, to get to a destination D, use next-hop NH. For a source constrained routing table we propose the following notation. (Source Network, Destination network) -> Next- hop. (S, D) -> NH. A route that is not source constrained can be represented as (*, D) -> NH. For convenience this document shows the routing table as a single destination based routing table, with source address constrained paths. This does not preclude other implementations, as long as the external behaviour is the same. A router forwarding a packet does a longest match look-up on the destination address. If this is a (*, D) entry, it forwards the packet out the best next-hop as before (doing equal cost multi path load balancing etc). If the look-up results in a (S, D) entry, the look-up function does a longest match on the source address among the set of (S, D) paths. If there is a match the packet is forwarded out the given next-hop, if not an ICMP destination address unreachable message, code 5 is returned [RFC4443]. A routing entry may have both (S, D) paths and (*, D) paths. The longest match wins. The following example show the routing table of a network connected to two ISPs, ISP A and ISP B. Both ISPs offer default connectivity and ISP B also offers a more specific route to a walled garden service. (2001:db8::/56, ::/0) -> ISP_A # Default route to ISP A (2001:db9::/56, ::/0) -> ISP_B # Default route to ISP B (*, 2001:db8::/64) -> R1 # Internal network, prefix from A (*, 2001:db8:1::/64) -> R2 # Internal network, prefix from A (*, 2001:db9::/64) -> R1 # Internal network, prefix from B (*, 2001:db9:1::/64) -> R2 # Internal network, prefix from B (*, fd00::/64) -> R3 # Internal network ULA (2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B Figure 1: Example Routing Table A packet with the SA, DA of 2001:db8::1, 2001:dead:beef::1 would be forwarded to ISP A, likewise a packet with SA, DA 2001:db9::1, 2001:dead:beef::1 would be forward to ISP B. An packet with SA,DA 2001:db8::1, 2001:db9::1 would be forwarded using normal destination based routing. A packet to the walled garden SA,DA 2001:db9::1, 2001:420::1 would be sent to ISP B. A packet with SA,DA 2001:db8::1,2001:420::1 would be dropped with an ICMP unreachable message being sent back. 6. Routing considerations Now that we have described the function of the source constrained routing table. How does the table get populated? Troan & Colitti Expires August 22, 2013 [Page 4] Internet-Draft SADR February 2013 6.1. Routing Protocol extensions The generic answer is that the routing protocol used in the network has to be extended to support (S, D) routes. Specifically, the routing protocol should distribute, for each External Route, the Acceptable Source Prefix(es) for that route. This may be done, for example, using [I-D.baker-ipv6-ospf-dst-src-routing] or [I-D.baker- ipv6-isis-dst-src-routing]. In the case of OSPFv3, for example, external routes are advertised in an AS-External-prefix LSA, [RFC5340] 6.2. Simplified SADR in home networks In a home network using a dynamic prefix assignment mechanism such as [I-D.arkko-homenet-prefix-assignment] it may be known that a particular Border Router is announcing both an External Route and a Usable Prefix (for example, if the same router ID is announcing both). In this case, interior routers may assume that the Acceptable Source Prefix of the External Route announced by that Border Router is in fact the Usable Prefix announced by that Border Router. An internal router when receiving a AS-External LSA route will install that in the routing table as normal. When the internal router receives a usable prefix as part of prefix assignment, the router shall add source constrained entries to all the AS-External routes received from the same border router (matching router-ID). Routes that are not associated with a border router or are not AS- External do not have source constrained paths. The routing protocol requirements for simplified SADR in the home network are: 1. Routing protocol must flood all information to all routers in the home network. (Single area). 2. Prefix assignment and unicast routing must be done in the same protocol. 3. A router must be uniquely identified (router-id) so that router advertisements and prefix assignment can be tied together 7. Interaction between routers and hosts Troan & Colitti Expires August 22, 2013 [Page 5] Internet-Draft SADR February 2013 Generally, hosts need not be aware that SADR is in use in the network. Hosts simply choose source addresses and the network will deliver the traffic to the appropriate upstream. One exception is when an Acceptable Source Prefix becomes invalid (e.g., if the Border Router which announced it crashes, or its WAN link goes down). In this case, current hosts will continue to use source addresses in that Acceptable Source Prefix without knowing that all communication outside the network is likely to fail. In this case, interior routers can improve responsiveness by deprecating the addresses in that Acceptable Source Prefix. ICMP [RFC4443] includes a Destination unreachable code 5 - "Source address failed ingress/egress policy". Hosts MUST adhered to this message, and based on the unreachable message try another source address. 8. IANA Considerations This specification does not require any IANA actions. 9. Security Considerations 10. Acknowledgements The authors would like to thank Jari Arkko and Andrew Yourtchenko for their ideas and review. 11. References 11.1. Normative References [I-D.arkko-homenet-prefix-assignment] Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment in a Home Network", draft-arkko-homenet-prefix- assignment-03 (work in progress), October 2012. [I-D.ietf-ospf-ospfv3-autoconfig] Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", draft-ietf-ospf-ospfv3-autoconfig-00 (work in progress), October 2012. [RFC 2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC2827, May 2000. [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC4443, March 2006. Troan & Colitti Expires August 22, 2013 [Page 6] Internet-Draft SADR February 2013 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC5340, July 2008. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC6724, September 2012. 11.2. Informative References [I-D.baker-ipv6-isis-dst-src-routing] Baker, F., "IPv6 Source/Destination Routing using IS-IS", draft-baker-ipv6-isis-dst-src-routing-00 (work in progress), February 2013. [I-D.baker-ipv6-ospf-dst-src-routing] Baker, F., "IPv6 Source/Destination Routing using OSPFv3", draft-baker-ipv6-ospf-dst-src-routing-00 (work in progress), February 2013. [I-D.ietf-homenet-arch] Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, "Home Networking Architecture for IPv6", draft-ietf- homenet-arch-06 (work in progress), October 2012. Authors' Addresses Ole Troan Cisco Systems Philip Pedersens vei 1 Lysaker 1366 Norway Email: firstname.lastname@example.org Lorenzo Colitti Google Roppongi Hills Mori Tower PO box 22 Minato, Tokyo 106-6126 Japan Email: email@example.com Troan & Colitti Expires August 22, 2013 [Page 7]