idnits 2.17.1 draft-baker-ipv6-ospf-dst-src-routing-03.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 3893 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) == Outdated reference: A later version (-02) exists of draft-acee-ospfv3-lsa-extend-00 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-flowlabel-routing-02 == Outdated reference: A later version (-02) exists of draft-baker-rtgwg-src-dst-routing-use-cases-00 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 OSPF 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 OSPFv3 8 draft-baker-ipv6-ospf-dst-src-routing-03 10 Abstract 12 This note describes the changes necessary for OSPFv3 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 OSPFv3 . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 3.1. IPv6 Source Prefix TLV . . . . . . . . . . . . . . . . . 4 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 OSPF for IPv6 [RFC5340] and the 69 extensible LSAs defined in [I-D.acee-ospfv3-lsa-extend]. It defines 70 the TLV for an IPv6 [RFC2460] Source Prefix, to define routes from a 71 source prefix to a destination 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 LSAs in the 113 LSDB 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 TLV match any source address (i.e., 120 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-ospf-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 OSPFv3 182 The extensible LSA format defined in [I-D.acee-ospfv3-lsa-extend] 183 requires one additional option to accomplish source/destination 184 routing: the source prefix. This is defined here. As noted in 185 Section 2, any prefix LSA that does not specify a source prefix is 186 understood to as specifying ::/0 as the source prefix. 188 3.1. IPv6 Source Prefix TLV 189 0 1 2 3 190 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 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Type | Length | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | PrefixLength | PrefixOptions | 0 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Address Prefix | 197 | ... | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 Source Prefix TLV 202 Type: assigned by IANA 204 TLV Length: Length of the value portion of the TLV in octets. This 205 is by definition 20. 207 PrefixLength, PrefixOptions, and Address Prefix: Representation of 208 an IPv6 address prefix, as described in [RFC5340] Appendix A.4.1 210 4. IANA Considerations 212 As discussed in [I-D.acee-ospfv3-lsa-extend], the IPv6 Source Prefix 213 TLV code should be allocated from the OSPFv3 IANA registry. 215 5. Security Considerations 217 While source/destination routing could be used as part of a security 218 solution, it is not really intended for the purpose. The approach 219 limits routing, in the sense that it routes traffic to an appropriate 220 egress, or gives a way to prevent communication between systems not 221 included in a source/destination route, and in that sense could be 222 considered similar to an access list that is managed by and scales 223 with routing. 225 6. Acknowledgements 227 Acee Lindem contributed to the concepts in this draft. 229 7. References 231 7.1. Normative References 233 [I-D.acee-ospfv3-lsa-extend] 234 Lindem, A., Mirtorabi, S., Roy, A., and F. Baker, "OSPFv3 235 LSA Extendibility", draft-acee-ospfv3-lsa-extend-00 (work 236 in progress), May 2013. 238 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 239 Requirement Levels", BCP 14, RFC 2119, March 1997. 241 [RFC2460] Deering, S.E. and R.M. Hinden, "Internet Protocol, Version 242 6 (IPv6) Specification", RFC 2460, December 1998. 244 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 245 for IPv6", RFC 5340, July 2008. 247 7.2. Informative References 249 [I-D.baker-ipv6-ospf-dst-flowlabel-routing] 250 Baker, F., "Using OSPFv3 with Role-Based Access Control", 251 draft-baker-ipv6-ospf-dst-flowlabel-routing-02 (work in 252 progress), May 2013. 254 [I-D.baker-rtgwg-src-dst-routing-use-cases] 255 Baker, F., "Requirements and Use Cases for Source/ 256 Destination Routing", draft-baker-rtgwg-src-dst-routing- 257 use-cases-00 (work in progress), August 2013. 259 Appendix A. Change Log 261 Initial Version: February 2013 263 First revision: April 2013 265 Correction: Corrected the reference to [I-D.acee-ospfv3-lsa-extend] 267 Use Case: Remove appendices, clarify the discussion of ambiguity and 268 refer to [I-D.baker-rtgwg-src-dst-routing-use-cases] 270 Author's Address 272 Fred Baker 273 Cisco Systems 274 Santa Barbara, California 93117 275 USA 277 Email: fred@cisco.com