idnits 2.17.1 draft-troan-homenet-sadr-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 2) being 60 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (September 04, 2013) is 3887 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ospf-ospfv3-autoconfig' is defined on line 285, but no explicit reference was found in the text == Unused Reference: 'RFC6724' is defined on line 304, but no explicit reference was found in the text == Unused Reference: 'I-D.baker-ipv6-isis-dst-src-routing' is defined on line 310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-homenet-arch' is defined on line 320, but no explicit reference was found in the text == Outdated reference: A later version (-04) exists of draft-arkko-homenet-prefix-assignment-03 == Outdated reference: A later version (-15) exists of draft-ietf-ospf-ospfv3-autoconfig-00 == Outdated reference: A later version (-07) exists of draft-baker-ipv6-isis-dst-src-routing-00 == Outdated reference: A later version (-03) exists of draft-baker-ipv6-ospf-dst-src-routing-00 == Outdated reference: A later version (-17) exists of draft-ietf-homenet-arch-06 Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Homenet working Group O. Troan 3 Internet-Draft Cisco Systems 4 Intended status: Informational L. Colitti 5 Expires: March 08, 2014 Google 6 September 04, 2013 8 IPv6 Multihoming with Source Address Dependent Routing (SADR) 9 draft-troan-homenet-sadr-01 11 Abstract 13 A multihomed network using provider aggregatable addresses must send 14 the packet out the right path to avoid violating the provider's 15 ingress filtering. This memo suggests a mechanism called Source 16 Address Dependent Routing to solve that problem. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on March 08, 2014. 35 Copyright Notice 37 Copyright (c) 2013 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 53 2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 2 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 55 4. Using SADR for multihoming . . . . . . . . . . . . . . . . . . 3 56 5. A Conceptual Forwarding Algorithm . . . . . . . . . . . . . . 3 57 6. Routing considerations . . . . . . . . . . . . . . . . . . . . 4 58 6.1. Routing Protocol extensions . . . . . . . . . . . . . . . 5 59 6.2. Simplified SADR in home networks . . . . . . . . . . . . . 5 60 7. Interaction between routers and hosts . . . . . . . . . . . . 5 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . 6 63 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 64 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 11.1. Normative References . . . . . . . . . . . . . . . . . . 6 66 11.2. Informative References . . . . . . . . . . . . . . . . . 7 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 69 1. Introduction 71 IPv6 is designed to support multiple addresses on an interface, and 72 the intention was to use this feature to support multihoming with 73 provider aggregatable addresses. 75 One difficulty of multihoming with provider-aggregatable space is 76 that providers typically employ BCP38 [RFC2827] filtering. If a 77 network sends traffic to its upstream provider using a source address 78 that was not assigned by that provider, the traffic will be dropped. 79 Thus, if a network is multihomed to multiple providers, it must 80 ensure that traffic is sent out the correct exit for the packet's 81 source address. 83 As long as upstream traffic is sent to the correct provider, hosts 84 inside the network are free to use source addresses assigned by any 85 of the network's upstream providers. In such a scenario, each host 86 has multiple addresses, one or more from each provider the network is 87 connected to. The network ensures that packets are sent to the 88 correct upstream by forwarding packets based on the destination 89 address and the source address. This we call source address 90 dependent routing (SADR). This memo shows how SADR can be used to 91 implement multihoming. 93 2. Conventions 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 3. Terminology 101 Service Provider An entity that provides the network with 102 external connectivity, e.g. to the Internet. 104 WAN Interface An interface connected to a Service 105 Providers. WAN interfaces may either be 106 physical links or virtual interfaces such as 107 tunnels. WAN interfaces are used to send 108 ingress traffic from the Internet to the End- 109 User, and egress traffic from the End-User 110 network to the Internet. Ingress traffic may 111 be received on any active interface at any 112 time. Egress traffic follows a set of rules 113 within the router in order to choose the 114 proper WAN interface. 116 Border Router A border router has one or more external 117 interfaces connecting it to one or more 118 Service Providers. The border router 119 receives one or more delegated prefixes, each 120 associated with one or more WAN interfaces. 122 External Route A route that is learned from a Service 123 Provider. Each External Route has an 124 Acceptable Source Prefix which determines 125 which source addresses may use that route. 127 Internal Router A router that is not a Border Router. 129 Internal Route A route to a destination inside the network. 131 4. Using SADR for multihoming 133 SADR is similar to policy based routing. This memo proposes a simple 134 extension to the destination based longest match algorithm to 135 constrain it to source address. 137 In order to support ingress filtering by upstream networks, the 138 network MUST treat external routes specially. Ingress filtering MAY 139 also be used internally, by installing (S,D) routes for locally 140 assigned prefixes, where the source prefix would be the aggregatable 141 prefix. If no ingress filtering is performed inside the network, 142 then normal non-source constrained forwarding is used. 144 5. A Conceptual Forwarding Algorithm 146 This section describes a conceptual forwarding algorithm. An 147 implementation might implement this differently, e.g. with multiple 148 tables, as long as the external behaviour is as described. 150 First a longest match lookup is done in the routing table for the 151 destination address, then for the resulting set a longest matching 152 lookup is done for the source address. 154 In a destination based routing table, an entry in the routing table 155 can be shown as "D -> NH". That is, to get to a destination D, use 156 next-hop NH. For a source constrained routing table we propose the 157 following notation. (Source Network, Destination network) -> Next- 158 hop. (S, D) -> NH. A route that is not source constrained can be 159 represented as (*, D) -> NH. 161 For convenience this document shows the routing table as a single 162 destination based routing table, with source address constrained 163 paths. This does not preclude other implementations, as long as the 164 external behaviour is the same. 166 A router forwarding a packet does a longest match look-up on the 167 destination address. If this is a (*, D) entry, it forwards the 168 packet out the best next-hop as before (doing equal cost multi path 169 load balancing etc). If the look-up results in a (S, D) entry, the 170 look-up function does a longest match on the source address among the 171 set of (S, D) paths. If there is a match the packet is forwarded out 172 the given next-hop, if not an ICMP destination address unreachable 173 message, code 5 is returned [RFC4443]. A routing entry may have both 174 (S, D) paths and (*, D) paths. The longest match wins. 176 The following example show the routing table of a network connected 177 to two ISPs, ISP A and ISP B. Both ISPs offer default connectivity 178 and ISP B also offers a more specific route to a walled garden 179 service. 181 (2001:db8::/56, ::/0) -> ISP_A # Default route to ISP A 182 (2001:db9::/56, ::/0) -> ISP_B # Default route to ISP B 183 (*, 2001:db8::/64) -> R1 # Internal network, prefix from A 184 (*, 2001:db8:1::/64) -> R2 # Internal network, prefix from A 185 (*, 2001:db9::/64) -> R1 # Internal network, prefix from B 186 (*, 2001:db9:1::/64) -> R2 # Internal network, prefix from B 187 (*, fd00::/64) -> R3 # Internal network ULA 188 (2001:db9::/56, 2001:420::/32) -> ISP_B # Walled garden route from ISP B 190 Figure 1: Example Routing Table 192 A packet with the SA, DA of 2001:db8::1, 2001:dead:beef::1 would be 193 forwarded to ISP A, likewise a packet with SA, DA 2001:db9::1, 194 2001:dead:beef::1 would be forward to ISP B. An packet with SA,DA 195 2001:db8::1, 2001:db9::1 would be forwarded using normal destination 196 based routing. A packet to the walled garden SA,DA 2001:db9::1, 197 2001:420::1 would be sent to ISP B. A packet with SA,DA 198 2001:db8::1,2001:420::1 would be dropped with an ICMP unreachable 199 message being sent back. 201 6. Routing considerations 203 Now that we have described the function of the source constrained 204 routing table. How does the table get populated? 206 6.1. Routing Protocol extensions 208 The generic answer is that the routing protocol used in the network 209 has to be extended to support (S, D) routes. Specifically, the 210 routing protocol should distribute, for each External Route, the 211 Acceptable Source Prefix(es) for that route. This may be done, for 212 example, using [I-D.baker-ipv6-ospf-dst-src-routing] or [I-D.baker- 213 ipv6-isis-dst-src-routing]. In the case of OSPFv3, for example, 214 external routes are advertised in an AS-External-prefix LSA, 215 [RFC5340] 217 6.2. Simplified SADR in home networks 219 In a home network using a dynamic prefix assignment mechanism such as 220 [I-D.arkko-homenet-prefix-assignment] it may be known that a 221 particular Border Router is announcing both an External Route and an 222 Aggregated Prefix (for example, if the same router ID is announcing 223 both). In this case, interior routers may assume that the Acceptable 224 Source Prefix of the External Route announced by that Border Router 225 is in fact the Aggregated Prefix announced by that Border Router. 227 An internal router when receiving a AS-External LSA route will 228 install that in the routing table as normal. When the internal 229 router receives a aggregated prefix as part of prefix assignment, the 230 router shall add source constrained entries to all the AS-External 231 routes received from the same border router (matching router-ID). 233 Routes that are not associated with a border router or are not AS- 234 External do not have source constrained paths. 236 The routing protocol requirements for simplified SADR in the home 237 network are: 239 1. Routing protocol must flood all information to all routers in the 240 home network. (Single area). 242 2. Prefix assignment and unicast routing must be done in the same 243 protocol. 245 3. A router must be uniquely identified (router-id) so that router 246 advertisements and prefix assignment can be tied together 248 7. Interaction between routers and hosts 249 Generally, hosts need not be aware that SADR is in use in the 250 network. Hosts simply choose source addresses and the network will 251 deliver the traffic to the appropriate upstream. One exception is 252 when an Acceptable Source Prefix becomes invalid (e.g., if the Border 253 Router which announced it crashes, or its WAN link goes down). In 254 this case, current hosts will continue to use source addresses in 255 that Acceptable Source Prefix without knowing that all communication 256 outside the network is likely to fail. In this case, interior 257 routers can improve responsiveness by deprecating the addresses in 258 that Acceptable Source Prefix. 260 ICMP [RFC4443] includes a Destination unreachable code 5 - "Source 261 address failed ingress/egress policy". Hosts MUST adhered to this 262 message, and based on the unreachable message try another source 263 address. 265 8. IANA Considerations 267 This specification does not require any IANA actions. 269 9. Security Considerations 271 10. Acknowledgements 273 The authors would like to thank Jari Arkko and Andrew Yourtchenko for 274 their ideas and review. 276 11. References 278 11.1. Normative References 280 [I-D.arkko-homenet-prefix-assignment] 281 Arkko, J., Lindem, A., and B. Paterson, "Prefix Assignment 282 in a Home Network", draft-arkko-homenet-prefix- 283 assignment-03 (work in progress), October 2012. 285 [I-D.ietf-ospf-ospfv3-autoconfig] 286 Lindem, A. and J. Arkko, "OSPFv3 Auto-Configuration", 287 draft-ietf-ospf-ospfv3-autoconfig-00 (work in progress), 288 October 2012. 290 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 291 Requirement Levels", BCP 14, RFC 2119, March 1997. 293 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 294 Defeating Denial of Service Attacks which employ IP Source 295 Address Spoofing", BCP 38, RFC 2827, May 2000. 297 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 298 Message Protocol (ICMPv6) for the Internet Protocol 299 Version 6 (IPv6) Specification", RFC 4443, March 2006. 301 [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF 302 for IPv6", RFC 5340, July 2008. 304 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 305 "Default Address Selection for Internet Protocol Version 6 306 (IPv6)", RFC 6724, September 2012. 308 11.2. Informative References 310 [I-D.baker-ipv6-isis-dst-src-routing] 311 Baker, F., "IPv6 Source/Destination Routing using IS-IS", 312 draft-baker-ipv6-isis-dst-src-routing-00 (work in 313 progress), February 2013. 315 [I-D.baker-ipv6-ospf-dst-src-routing] 316 Baker, F., "IPv6 Source/Destination Routing using OSPFv3", 317 draft-baker-ipv6-ospf-dst-src-routing-00 (work in 318 progress), February 2013. 320 [I-D.ietf-homenet-arch] 321 Chown, T., Arkko, J., Brandt, A., Troan, O., and J. Weil, 322 "Home Networking Architecture for IPv6", draft-ietf- 323 homenet-arch-06 (work in progress), October 2012. 325 Authors' Addresses 327 Ole Troan 328 Cisco Systems 329 Philip Pedersens vei 1 330 Lysaker 1366 331 Norway 333 Email: ot@cisco.com 335 Lorenzo Colitti 336 Google 337 Roppongi Hills Mori Tower PO box 22 338 Minato, Tokyo 106-6126 339 Japan 341 Email: lorenzo@google.com