Network Working Group F.J. Baker Internet-Draft Cisco Systems Intended status: Standards Track August 28, 2013 Expires: March 01, 2014 IPv6 Source/Destination Routing using IS-IS draft-baker-ipv6-isis-dst-src-routing-01 Abstract This note describes the changes necessary for IS-IS to route IPv6 traffic from a specified prefix to a specified prefix. 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 March 01, 2014. 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 Baker Expires March 01, 2014 [Page 1] Internet-Draft IS-IS Source/Destination Routing August 2013 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 2 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 3 2.3. Interactions with other constraints . . . . . . . . . . . 4 3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 5 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 7.2. Informative References . . . . . . . . . . . . . . . . . 6 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. Introduction This specification builds on IS-IS for IPv6 [RFC5308] and its extensible TLV. This note defines the sub-TLV for an IPv6 [RFC2460] Source Prefix, to define routes from a source prefix to a destination prefix. This implies not simply routing "to a destination", but routing "to that destination AND from a specified source". It may be combined with other qualifying attributes, such as "traffic going to that destination AND using a specified flow label AND from a specified source prefix". The obvious application is egress routing, as required for a multihomed entity with a provider-allocated prefix from each of several upstream networks. Traffic within the network could be source/destination routed as well, or could be implicitly or explicitly routed from "any prefix", ::/0. Other use cases are described in [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a route to a given destination from one or more prefixes not including ::/0, and a given packet destined there that has a source address that is in none of them, the packet in effect has no route, just as if the destination itself were not in the route table. 1.1. Requirements Language 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]. 2. Theory of Routing Baker Expires March 01, 2014 [Page 2] Internet-Draft IS-IS Source/Destination Routing August 2013 Both IS-IS and OSPF perform their calculations by building a lattice of routers and links from the router performing the calculation to each router, and then use routes (sequences in the lattice) to get to destinations that those routes advertise connectivity to. Following the SPF algorithm, calculation starts by selecting a starting point (typically the router doing the calculation), and successively adding {link, router} pairs until one has calculated a route to every router in the network. As each router is added, including the original router, destinations that it is directly connected to are turned into routes in the route table: "to get to 2001:db8::/32, route traffic to {interface, list of next hop routers}". For immediate neighbors to the originating router, of course, there is no next hop router; traffic is handled locally. In this context, the route is qualified by a source prefix; It is installed into the FIB with the destination prefix, and the FIB applies the route if and only if the IPv6 source address also matches the advertised prefix. Of course, there may be multiple LSPs in the RIB with the same destination and differing source prefixes; these may also have the same or differing next hop lists. The intended forwarding action is to forward matching traffic to one of the next hop routers associated with this destination and source prefix, or to discard non-matching traffic as "destination unreachable". LSAs that lack a source prefix sub-TLV match any source address (i.e., the source prefix TLV defaults to ::/0), by definition. 2.1. Notation For the purposes of this document, a route from the prefix A to the prefix B (in other words, whose source prefix is A and whose destination prefix is B) is expressed as A->B. A packet with the source address A and the destination address B is similarly described as A->B. 2.2. Dealing with ambiguity In any routing protocol, there is the possibility of ambiguity. For example, one router might advertise a fairly general prefix - a default route, a discard prefix (which consumes all traffic that is not directed to an instantiated subnet), or simply an aggregated prefix while another router advertises a more specific one. In source/destination routing, potentially ambiguous cases include cases in which the link state database contains two routes A->B' and A'->B, in which A' is a more specific prefix within the prefix A and B' is a more specific prefix within the prefix B. Traditionally, we have dealt with ambiguous destination routes using a "longest match first" rule. If the same datagram matches more than one destination prefix Baker Expires March 01, 2014 [Page 3] Internet-Draft IS-IS Source/Destination Routing August 2013 advertised within an area, we follow the route with the longest matching prefix. With source/destination routes, as noted in [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but slightly different rule; the FIB lookup MUST yield the route with the longest matching destination prefix that also matches the source prefix constraint. In the event of a tie on the destination prefix, it MUST also match the longest matching source prefix among those options. An example of the issue is this. Suppose we have two routes: 1. 2001:db8:1::/48 -> 2001:db8:3:3::/64 2. 2001:db8:2::/48 -> 2001:db8:3::/48 and a packet 2001:db8:2::1 -> 2001:db8:3:3::1 If we require the algorithm to follow the longest destination match without regard to the source, the destination address matches 2001:db8:3:3::/64 (the first route), and the source address doesn't match the constraint of the first route; we therefore have no route. The FIB algorithm, in this example, must therefore match the second route, even though it is not the longest destination match, because it also matches the source address. 2.3. Interactions with other constraints In the event that there are other constraints on routing, such as proposed in [I-D.baker-ipv6-isis-dst-flowlabel-routing], the effect is a logical AND. The FIB lookup must yield the route with the longest matching destination prefix that also matches each of the constraints. 3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and carries in it destination prefix advertisements. It has the capability of extension, using sub-TLVs. We define the Source Prefix Sub-TLV as in Section 3.1. As noted in Section 2, any IPv6 Reachability TLV that does not specify a source prefix is understood to as specifying ::/0 as the source prefix. Baker Expires March 01, 2014 [Page 4] Internet-Draft IS-IS Source/Destination Routing August 2013 3.1. Source Prefix sub-TLV 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 | Prefix +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source Prefix Sub-TLV Source Prefix Type: assigned by IANA TLV Length: Length of the sub-TLV in octets Prefix Length: Length of the prefix in bits Prefix: (source prefix length+7)/8 octets of prefix 4. IANA Considerations The source prefix type mentioned in Section 3 must be defined. 5. Security Considerations While source/destination routing could be used as part of a security solution, it is not really intended for the purpose. The approach limits routing, in the sense that it routes traffic to an appropriate egress, or gives a way to prevent communication between systems not included in a source/destination route, and in that sense could be considered similar to an access list that is managed by and scales with routing. 6. Acknowledgements 7. References 7.1. Normative References [ISO.10589.1992] International Organization for Standardization, "Intermediate system to intermediate system intra-domain- routing routine information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode Network Service (ISO 8473)", ISO Standard 10589, 1992. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Baker Expires March 01, 2014 [Page 5] Internet-Draft IS-IS Source/Destination Routing August 2013 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 2008. 7.2. Informative References [I-D.baker-ipv6-isis-dst-flowlabel-routing] Baker, F., "Using IS-IS with Role-Based Access Control", draft-baker-ipv6-isis-dst-flowlabel-routing-00 (work in progress), February 2013. [I-D.baker-rtgwg-src-dst-routing-use-cases] Baker, F., "Requirements and Use Cases for Source/ Destination Routing", draft-baker-rtgwg-src-dst-routing- use-cases-00 (work in progress), August 2013. Appendix A. Change Log Initial Version: February 2013 updated Version: August 2013 Author's Address Fred Baker Cisco Systems Santa Barbara, California 93117 USA Email: fred@cisco.com Baker Expires March 01, 2014 [Page 6]