idnits 2.17.1 draft-baker-ipv6-isis-dst-src-routing-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2013) is 3866 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-01) exists of draft-baker-ipv6-isis-dst-flowlabel-routing-00 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group F.J. Baker 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track August 28, 2013 5 Expires: March 01, 2014 7 IPv6 Source/Destination Routing using IS-IS 8 draft-baker-ipv6-isis-dst-src-routing-01 10 Abstract 12 This note describes the changes necessary for IS-IS to route IPv6 13 traffic from a specified prefix to a specified prefix. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on March 01, 2014. 32 Copyright Notice 34 Copyright (c) 2013 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 49 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 50 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 2 51 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 3 53 2.3. Interactions with other constraints . . . . . . . . . . . 4 54 3. Extensions necessary for IPv6 Source/Destination Routing in 55 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 5 57 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 5 61 7.1. Normative References . . . . . . . . . . . . . . . . . . 5 62 7.2. Informative References . . . . . . . . . . . . . . . . . 6 63 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 6 64 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 66 1. Introduction 68 This specification builds on IS-IS for IPv6 [RFC5308] and its 69 extensible TLV. This note defines the sub-TLV for an IPv6 [RFC2460] 70 Source Prefix, to define routes from a source prefix to a destination 71 prefix. 73 This implies not simply routing "to a destination", but routing "to 74 that destination AND from a specified source". It may be combined 75 with other qualifying attributes, such as "traffic going to that 76 destination AND using a specified flow label AND from a specified 77 source prefix". The obvious application is egress routing, as 78 required for a multihomed entity with a provider-allocated prefix 79 from each of several upstream networks. Traffic within the network 80 could be source/destination routed as well, or could be implicitly or 81 explicitly routed from "any prefix", ::/0. Other use cases are 82 described in [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB 83 contains a route to a given destination from one or more prefixes not 84 including ::/0, and a given packet destined there that has a source 85 address that is in none of them, the packet in effect has no route, 86 just as if the destination itself were not in the route table. 88 1.1. Requirements Language 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Theory of Routing 95 Both IS-IS and OSPF perform their calculations by building a lattice 96 of routers and links from the router performing the calculation to 97 each router, and then use routes (sequences in the lattice) to get to 98 destinations that those routes advertise connectivity to. Following 99 the SPF algorithm, calculation starts by selecting a starting point 100 (typically the router doing the calculation), and successively adding 101 {link, router} pairs until one has calculated a route to every router 102 in the network. As each router is added, including the original 103 router, destinations that it is directly connected to are turned into 104 routes in the route table: "to get to 2001:db8::/32, route traffic to 105 {interface, list of next hop routers}". For immediate neighbors to 106 the originating router, of course, there is no next hop router; 107 traffic is handled locally. 109 In this context, the route is qualified by a source prefix; It is 110 installed into the FIB with the destination prefix, and the FIB 111 applies the route if and only if the IPv6 source address also matches 112 the advertised prefix. Of course, there may be multiple LSPs in the 113 RIB with the same destination and differing source prefixes; these 114 may also have the same or differing next hop lists. The intended 115 forwarding action is to forward matching traffic to one of the next 116 hop routers associated with this destination and source prefix, or to 117 discard non-matching traffic as "destination unreachable". 119 LSAs that lack a source prefix sub-TLV match any source address 120 (i.e., the source prefix TLV defaults to ::/0), by definition. 122 2.1. Notation 124 For the purposes of this document, a route from the prefix A to the 125 prefix B (in other words, whose source prefix is A and whose 126 destination prefix is B) is expressed as A->B. A packet with the 127 source address A and the destination address B is similarly described 128 as A->B. 130 2.2. Dealing with ambiguity 132 In any routing protocol, there is the possibility of ambiguity. For 133 example, one router might advertise a fairly general prefix - a 134 default route, a discard prefix (which consumes all traffic that is 135 not directed to an instantiated subnet), or simply an aggregated 136 prefix while another router advertises a more specific one. In 137 source/destination routing, potentially ambiguous cases include cases 138 in which the link state database contains two routes A->B' and A'->B, 139 in which A' is a more specific prefix within the prefix A and B' is a 140 more specific prefix within the prefix B. Traditionally, we have 141 dealt with ambiguous destination routes using a "longest match first" 142 rule. If the same datagram matches more than one destination prefix 143 advertised within an area, we follow the route with the longest 144 matching prefix. 146 With source/destination routes, as noted in 147 [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but 148 slightly different rule; the FIB lookup MUST yield the route with the 149 longest matching destination prefix that also matches the source 150 prefix constraint. In the event of a tie on the destination prefix, 151 it MUST also match the longest matching source prefix among those 152 options. 154 An example of the issue is this. Suppose we have two routes: 156 1. 2001:db8:1::/48 -> 2001:db8:3:3::/64 158 2. 2001:db8:2::/48 -> 2001:db8:3::/48 160 and a packet 162 2001:db8:2::1 -> 2001:db8:3:3::1 164 If we require the algorithm to follow the longest destination match 165 without regard to the source, the destination address matches 166 2001:db8:3:3::/64 (the first route), and the source address doesn't 167 match the constraint of the first route; we therefore have no route. 168 The FIB algorithm, in this example, must therefore match the second 169 route, even though it is not the longest destination match, because 170 it also matches the source address. 172 2.3. Interactions with other constraints 174 In the event that there are other constraints on routing, such as 175 proposed in [I-D.baker-ipv6-isis-dst-flowlabel-routing], the effect 176 is a logical AND. The FIB lookup must yield the route with the 177 longest matching destination prefix that also matches each of the 178 constraints. 180 3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS 182 Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and 183 carries in it destination prefix advertisements. It has the 184 capability of extension, using sub-TLVs. 186 We define the Source Prefix Sub-TLV as in Section 3.1. As noted in 187 Section 2, any IPv6 Reachability TLV that does not specify a source 188 prefix is understood to as specifying ::/0 as the source prefix. 190 3.1. Source Prefix sub-TLV 192 0 1 2 3 193 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 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Type | Length |Prefix Length | Prefix 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Source Prefix Sub-TLV 200 Source Prefix Type: assigned by IANA 202 TLV Length: Length of the sub-TLV in octets 204 Prefix Length: Length of the prefix in bits 206 Prefix: (source prefix length+7)/8 octets of prefix 208 4. IANA Considerations 210 The source prefix type mentioned in Section 3 must be defined. 212 5. Security Considerations 214 While source/destination routing could be used as part of a security 215 solution, it is not really intended for the purpose. The approach 216 limits routing, in the sense that it routes traffic to an appropriate 217 egress, or gives a way to prevent communication between systems not 218 included in a source/destination route, and in that sense could be 219 considered similar to an access list that is managed by and scales 220 with routing. 222 6. Acknowledgements 224 7. References 226 7.1. Normative References 228 [ISO.10589.1992] 229 International Organization for Standardization, 230 "Intermediate system to intermediate system intra-domain- 231 routing routine information exchange protocol for use in 232 conjunction with the protocol for providing the 233 connectionless-mode Network Service (ISO 8473)", ISO 234 Standard 10589, 1992. 236 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 237 Requirement Levels", BCP 14, RFC 2119, March 1997. 239 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 240 6 (IPv6) Specification", RFC 2460, December 1998. 242 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 243 2008. 245 7.2. Informative References 247 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 248 Baker, F., "Using IS-IS with Role-Based Access Control", 249 draft-baker-ipv6-isis-dst-flowlabel-routing-00 (work in 250 progress), February 2013. 252 [I-D.baker-rtgwg-src-dst-routing-use-cases] 253 Baker, F., "Requirements and Use Cases for Source/ 254 Destination Routing", draft-baker-rtgwg-src-dst-routing- 255 use-cases-00 (work in progress), August 2013. 257 Appendix A. Change Log 259 Initial Version: February 2013 261 updated Version: August 2013 263 Author's Address 265 Fred Baker 266 Cisco Systems 267 Santa Barbara, California 93117 268 USA 270 Email: fred@cisco.com