idnits 2.17.1 draft-baker-ipv6-isis-dst-src-routing-02.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 == Line 214 has weird spacing: '...d usage appl...' == Line 215 has weird spacing: '...opology yes...' == Line 216 has weird spacing: '...agement no...' == Line 220 has weird spacing: '...agement yes...' -- The document date (October 20, 2014) is 3477 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) == Unused Reference: 'IS-IS' is defined on line 280, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'IS-IS' ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). 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 D. Lamparter 5 Expires: April 23, 2015 NetDEF 6 October 20, 2014 8 IPv6 Source/Destination Routing using IS-IS 9 draft-baker-ipv6-isis-dst-src-routing-02 11 Abstract 13 This note describes the changes necessary for IS-IS to route IPv6 14 traffic from a specified prefix to a specified prefix. 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on April 23, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 2 51 2. Theory of Routing . . . . . . . . . . . . . . . . . . . . . . 3 52 2.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2.2. Dealing with ambiguity . . . . . . . . . . . . . . . . . 4 54 2.3. Interactions with other constraints . . . . . . . . . . . 4 55 2.4. Multi-topology Routing . . . . . . . . . . . . . . . . . 5 56 3. Extensions necessary for IPv6 Source/Destination Routing in 57 IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 3.1. Source Prefix sub-TLV . . . . . . . . . . . . . . . . . . 5 59 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 60 5. Security Considerations . . . . . . . . . . . . . . . . . . . 6 61 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6 62 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 7.1. Normative References . . . . . . . . . . . . . . . . . . 6 64 7.2. Informative References . . . . . . . . . . . . . . . . . 7 65 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 7 66 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 This specification builds on IS-IS for IPv6 [RFC5308] and the 71 critical extension TLV in [critical-subtlvs]. This note defines the 72 sub-TLV for an IPv6 [RFC2460] Source Prefix, to define routes from a 73 source prefix to a destination prefix. 75 This implements the Destination/Source Routing mechanism described in 76 [dst-src-routing]. This implies not simply routing "to a 77 destination", but routing "to that destination AND from a specified 78 source". It may be combined with other qualifying attributes, such 79 as "traffic going to that destination AND using a specified flow 80 label AND from a specified source prefix". The obvious application 81 is egress routing, as required for a multihomed entity with a 82 provider-allocated prefix from each of several upstream networks. 83 Traffic within the network could be source/destination routed as 84 well, or could be implicitly or explicitly routed from "any prefix", 85 ::/0. Other use cases are described in 86 [I-D.baker-rtgwg-src-dst-routing-use-cases]. If a FIB contains a 87 route to a given destination from one or more prefixes not including 88 ::/0, and a given packet destined there that has a source address 89 that is in none of them, the packet in effect has no route, just as 90 if the destination itself were not in the route table. 92 1.1. Requirements Language 93 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 94 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 95 document are to be interpreted as described in [RFC2119]. 97 2. Theory of Routing 99 Both IS-IS and OSPF perform their calculations by building a lattice 100 of routers and links from the router performing the calculation to 101 each router, and then use routes (sequences in the lattice) to get to 102 destinations that those routes advertise connectivity to. Following 103 the SPF algorithm, calculation starts by selecting a starting point 104 (typically the router doing the calculation), and successively adding 105 {link, router} pairs until one has calculated a route to every router 106 in the network. As each router is added, including the original 107 router, destinations that it is directly connected to are turned into 108 routes in the route table: "to get to 2001:db8::/32, route traffic to 109 {interface, list of next hop routers}". For immediate neighbors to 110 the originating router, of course, there is no next hop router; 111 traffic is handled locally. 113 In this context, the route is qualified by a source prefix; It is 114 installed into the FIB with the destination prefix, and the FIB 115 applies the route if and only if the IPv6 source address also matches 116 the advertised prefix. Of course, there may be multiple LSPs in the 117 RIB with the same destination and differing source prefixes; these 118 may also have the same or differing next hop lists. The intended 119 forwarding action is to forward matching traffic to one of the next 120 hop routers associated with this destination and source prefix, or to 121 discard non-matching traffic as "destination unreachable". 123 TLVs that lack a source prefix sub-TLV match any source address 124 (i.e., the source prefix TLV defaults to ::/0), by definition. 126 When resolving Destination/Source Reachabilities, the SPF calculation 127 results used MUST reflect a calculation performed including only 128 routers that advertise support for the critical Source Prefix TLV 129 defined in section 3. The mechanism for signaling this is described 130 in [critical-subtlvs]. Routers that support this extension MUST 131 advertise support as described there. 133 2.1. Notation 135 For the purposes of this document, a route from the prefix A to the 136 prefix B (in other words, whose source prefix is A and whose 137 destination prefix is B) is expressed as A->B. A packet with the 138 source address A and the destination address B is similarly described 139 as A->B. 141 2.2. Dealing with ambiguity 143 In any routing protocol, there is the possibility of ambiguity. For 144 example, one router might advertise a fairly general prefix - a 145 default route, a discard prefix (which consumes all traffic that is 146 not directed to an instantiated subnet), or simply an aggregated 147 prefix while another router advertises a more specific one. In 148 source/destination routing, potentially ambiguous cases include cases 149 in which the link state database contains two routes A->B' and A'->B, 150 in which A' is a more specific prefix within the prefix A and B' is a 151 more specific prefix within the prefix B. Traditionally, we have 152 dealt with ambiguous destination routes using a "longest match first" 153 rule. If the same datagram matches more than one destination prefix 154 advertised within an area, we follow the route with the longest 155 matching prefix. 157 With source/destination routes, as noted in 158 [I-D.baker-rtgwg-src-dst-routing-use-cases], we follow a similar but 159 slightly different rule; the FIB lookup MUST yield the route with the 160 longest matching destination prefix that also matches the source 161 prefix constraint. In the event of a tie on the destination prefix, 162 it MUST also match the longest matching source prefix among those 163 options. 165 An example of the issue is this. Suppose we have two routes: 167 1. 2001:db8:1::/48 -> 2001:db8:3:3::/64 169 2. 2001:db8:2::/48 -> 2001:db8:3::/48 171 and a packet 173 2001:db8:2::1 -> 2001:db8:3:3::1 175 If we require the algorithm to follow the longest destination match 176 without regard to the source, the destination address matches 177 2001:db8:3:3::/64 (the first route), and the source address doesn't 178 match the constraint of the first route; we therefore have no route. 179 The FIB algorithm, in this example, must therefore match the second 180 route, even though it is not the longest destination match, because 181 it also matches the source address. 183 2.3. Interactions with other constraints 185 In the event that there are other constraints on routing, such as 186 proposed in [I-D.baker-ipv6-isis-dst-flowlabel-routing], the effect 187 is a logical AND. The FIB lookup must yield the route with the 188 longest matching destination prefix that also matches each of the 189 constraints. The general mechanics for this are described in 190 [extra-qualifiers]. 192 2.4. Multi-topology Routing 194 While not mandatory, IS-IS is often implemented as Multi Topology 195 Routing [RFC5120] with IPv4 or other protocols in the same or 196 different topologies. The TLV structure in [critical-subtlvs] is 197 topology-agnostic in that it always includes the topology ID, which 198 may be zero to indicate the default topology. 200 The mechanism in this document and its Sub-TLV are applicable to any 201 topology that carries routing information used for IPv6 Unicast 202 routing. Destination/Source reachability information SHOULD NOT be 203 placed differently from "plain" destination reachabilities. 205 A system MUST NOT originate Destination/Source Reachabilities in a 206 topology that is exclusively configured for multicast RPF operation. 207 If a topology is shared between unicast lookups and multicast reverse 208 path lookups, reachabilities with a source prefix other than ::/0 209 MUST be ignored for multicast reverse path lookups. 211 The statements in the previous two paragraphs currently result in 212 applicability of Destination/Source routes as: 214 MT-ID designated usage applicability 215 0 default topology yes 216 1 IPv4 management no 217 2 IPv6 default yes 218 3 IPv4 multicast no 219 4 IPv6 multicast no 220 5 IPv6 management yes 222 Applicability of Destination/Source IPv6 Reachabilities 224 3. Extensions necessary for IPv6 Source/Destination Routing in IS-IS 226 Section 2 of [RFC5308] defines the "IPv6 Reachability TLV", and 227 carries in it destination prefix advertisements. It has the 228 capability of extension, using sub-TLVs. 230 We define the Source Prefix Sub-TLV as in Section 3.1. As noted in 231 Section 2, any IPv6 Reachability TLV that does not specify a source 232 prefix is understood to as specifying ::/0 (any IPv6 address) as the 233 source prefix. 235 3.1. Source Prefix sub-TLV 236 The following Sub-TLV is defined for the critical part of TLV TBD2 237 defined in [critical-subtlvs]: 239 0 1 2 3 240 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 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Type | Length |Prefix Length | Prefix 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 Source Prefix Sub-TLV 247 Source Prefix Type: assigned by IANA 249 TLV Length: Length of the sub-TLV in octets 251 Prefix Length: Length of the prefix in bits 253 Prefix: (source prefix length+7)/8 octets of prefix 255 4. IANA Considerations 257 The "Sub-TLVs for TLVs TBD1 (critical) and TBD2 (critical)" registry 258 defined in [critical-subtlvs] is extended by the following element: 260 Source Prefix Type: assigned by IANA 262 Description: IPv6 Source Prefix 264 Applicable to TLV TBD1 (IPv4): No 266 Applicable to TLV TBD2 (IPv6): Yes 268 5. Security Considerations 270 There are no security considerations specific to this document. 271 However, the considerations from [dst-src-routing] and 272 [critical-subtlvs] are particularly relevant to this document. 274 6. Acknowledgements 276 7. References 278 7.1. Normative References 280 [IS-IS] ISO/IEC, "Intermediate System to Intermediate System 281 Intra-Domain Routing Exchange Protocol for use in 282 Conjunction with the Protocol for Providing the 283 Connectionless-mode Network Service (ISO 8473)", ISO/IEC 284 10589:2002, Second Edition, 2002. 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 290 6 (IPv6) Specification", RFC 2460, December 1998. 292 [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi 293 Topology (MT) Routing in Intermediate System to 294 Intermediate Systems (IS-ISs)", RFC 5120, February 2008. 296 [RFC5308] Hopps, C., "Routing IPv6 with IS-IS", RFC 5308, October 297 2008. 299 [critical-subtlvs] 300 Lamparter, D., "IS-IS Reachability with critical Sub- 301 TLVs", draft-lamparter-isis-reachability-critical- 302 subtlvs-00 (work in progress), October 2014. 304 [dst-src-routing] 305 Lamparter, D., "Destination/Source Routing", draft- 306 lamparter-rtgwg-dst-src-routing-00 (work in progress), 307 October 2014. 309 [extra-qualifiers] 310 Lamparter, D., "Considerations and Registry for extending 311 IP route lookup", draft-lamparter-rtgwg-routing- 312 discriminators-00 (work in progress), October 2014. 314 7.2. Informative References 316 [I-D.baker-ipv6-isis-dst-flowlabel-routing] 317 Baker, F., "Using IS-IS with Token-based Access Control", 318 draft-baker-ipv6-isis-dst-flowlabel-routing-01 (work in 319 progress), August 2013. 321 [I-D.baker-rtgwg-src-dst-routing-use-cases] 322 Baker, F., "Requirements and Use Cases for Source/ 323 Destination Routing", draft-baker-rtgwg-src-dst-routing- 324 use-cases-00 (work in progress), August 2013. 326 Appendix A. Change Log 327 Initial Version: February 2013 329 updated Version: August 2013 331 Added MTR: August 2014 333 Split into 4 drafts: October 2014 335 Authors' Addresses 337 Fred Baker 338 Cisco Systems 339 Santa Barbara, California 93117 340 USA 342 Email: fred@cisco.com 344 David Lamparter 345 NetDEF 346 Leipzig 04103 347 Germany 349 Email: david@opensourcerouting.org