idnits 2.17.1 draft-baker-6man-multi-homed-host-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 (Using the creation date from RFC4861, updated by this document, for RFC5378 checks: 2004-07-16) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 3, 2015) is 3130 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) -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Maintenance F. Baker 3 Internet-Draft Cisco Systems 4 Updates: 4861 (if approved) B. Carpenter 5 Intended status: Standards Track Univ. of Auckland 6 Expires: March 6, 2016 September 3, 2015 8 Host routing in a multi-prefix network 9 draft-baker-6man-multi-homed-host-03 11 Abstract 13 This note describes expected IPv6 host behavior in a network that has 14 more than one prefix, each allocated by an upstream network that 15 implements BCP 38 ingress filtering, when the host has multiple 16 routers to choose from. It also applies to other scenarios such as 17 the usage of stateful firewalls that effectively act as address-based 18 filters. 20 This host behavior may interact with source address selection in a 21 given implementation, but logically follows it. Given that the 22 network or host is, or appears to be, multihomed with multiple 23 provider-allocated addresses, that the host has elected to use a 24 source address in a given prefix, and that some but not all 25 neighboring routers are advertising that prefix in their Router 26 Advertisement Prefix Information Options, this document specifies to 27 which router a host should present its transmission. It updates RFC 28 4861. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at http://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 6, 2016. 47 Copyright Notice 49 Copyright (c) 2015 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction and Applicability . . . . . . . . . . . . . . . 2 65 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 66 2. Sending context expected by the host . . . . . . . . . . . . 3 67 2.1. Expectations the host has of the network . . . . . . . . 3 68 2.2. Expectations of multihomed networks . . . . . . . . . . . 5 69 3. Reasonable expectations of the host . . . . . . . . . . . . . 5 70 3.1. Default Router Selection . . . . . . . . . . . . . . . . 5 71 3.2. Source Address Selection . . . . . . . . . . . . . . . . 5 72 3.3. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.4. History . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 6 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 7 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 7 80 8.2. Informative References . . . . . . . . . . . . . . . . . 8 81 Appendix A. Change Log . . . . . . . . . . . . . . . . . . . . . 9 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9 84 1. Introduction and Applicability 86 This note describes the expected behavior of an IPv6 [RFC2460] host 87 in a network that has more than one prefix, each allocated by an 88 upstream network that implements BCP 38 [RFC2827] ingress filtering, 89 and in which the host is presented with a choice of routers. It 90 expects that the network will implement some form of egress routing, 91 so that packets sent to a host outside the local network from a given 92 ISP's prefix will go to that ISP. If the packet is sent to the wrong 93 egress, it is liable to be discarded by the BCP 38 filter. However, 94 the mechanics of egress routing once the packet leaves the host are 95 out of scope. The question here is how the host interacts with that 96 network. 98 BCP 38 filtering by ISPs is not the only scenario where such behavior 99 is valuable. The combination of existing recommendations for home 100 gateways [RFC6092] [RFC7084] can also result in such filtering. 101 Another case is when the connections to the upstream networks include 102 stateful firewalls, such that return packets in a stream will be 103 discarded if they do not return via the firewall that created state 104 for the outgoing packets. A similar cause of such discards is 105 unicast reverse path forwarding (uRPF) [RFC3704]. 107 In this document, the term "filter" is used for simplicity to cover 108 all such cases. In any case, one cannot assume the host to be aware 109 whether an ingress filter, a stateful firewall, or any other type of 110 filter is in place. Therefore, the only safe solution is to 111 implement the features defined in this document. 113 Note that, apart from ensuring that a message with a given source 114 address is given to a first-hop router that appears to know about the 115 prefix in question, this specification is consistent with [RFC4861]. 116 Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 117 4861 will need to extend their implementations accordingly. This 118 specification is fully consistent with [RFC6724] and implementers 119 will need to add support for its Rule 5.5. Hosts that do not support 120 these features may fail to communicate in the presence of filters as 121 described above. 123 1.1. Requirements Language 125 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 126 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 127 document are to be interpreted as described in [RFC2119]. 129 2. Sending context expected by the host 131 2.1. Expectations the host has of the network 133 A host receives prefixes in a Router Advertisement [RFC4861], which 134 goes on to identify whether they are usable by SLAAC [RFC4862] 135 [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the 136 Router Advertisement would normally signal the availability of DHCPv6 137 [RFC3315] and the host would use it to configure its addresses. In 138 the latter case (or if both SLAAC and DHCPv6 are used on the same 139 link for some reason) it will be generally the case that the 140 configured addresses match one of the prefixes advertised in a Router 141 Advertisement that are supposed to be in that link. 143 The simplest multihomed network implementation in which a host makes 144 choices among routers might be a LAN with one or more hosts on it and 145 two or more routers, one for each upstream network, or a host that is 146 served by disjoint networks on separate interfaces. In such a 147 network, especially the latter, there is not necessarily a routing 148 protocol, and the two routers may not even know that the other is a 149 router as opposed to a host, or may be configured to ignore its 150 presence. One might expect that the routers may or may not receive 151 each other's RAs and form an address in the other router's prefix 152 (which is not per [RFC4862], but is implemented by some stub router 153 implementations). However, all hosts in such a network might be 154 expected to create an address in each prefix so advertised. 156 +---------+ +---------+ +---------+ +---------+ 157 | ISP | | ISP | | ISP | | ISP | 158 +----+----+ +----+----+ +----+----+ +----+----+ 159 | | | | 160 | | | | 161 +----+----+ +----+----+ +----+----+ +----+----+ 162 | Router | | Router | | Router | | Router | 163 +----+----+ +----+----+ +----+----+ +----+----+ 164 | | | | 165 +------+------+ | +--------+ | 166 | +--+ Host +--+ 167 +----+----+ +--------+ 168 | Host | 169 +---------+ 170 Common LAN Case Disjoint LAN Case 171 (Multihomed Network) (Multihomed Host) 173 Figure 1: Two simple networks 175 If there is no routing protocol among those routers, there is no 176 mechanism by which packets can be deterministically forwarded between 177 the routers (as described in BCP 84 [RFC3704]) in order to avoid 178 filters. Even if there was routing, it would result in an indirect 179 route, rather than a direct route originating with the host; this is 180 not "wrong", but can be inefficient. Therefore the host would do 181 well to select the appropriate router itself. 183 Since the host derives fundamental default routing information from 184 the Router Advertisement, this implies that, in any network with 185 hosts using multiple prefixes, each prefix SHOULD be advertised via a 186 Prefix Information Option (PIO) [RFC4861] by one of the attached 187 routers, even if addresses are being assigned using DHCPv6. A router 188 that advertises a prefix indicates that it is able to appropriately 189 route packets with source addresses within that prefix, regardless of 190 the setting of the L and A flags in the PIO. In some circumstances 191 both L and A might be zero. 193 Although this does not violate the existing standard [RFC4861], such 194 a PIO has not previously been common, and it is possible that 195 existing host implementations simply ignore such a PIO or that a 196 router implementation rejects such a PIO as a configuration error. 197 Newer implementations that support this mechanism will need to be 198 updated accordingly: a host SHOULD NOT ignore a PIO simply because 199 both L and A flags are cleared; a router SHOULD be able to send such 200 a PIO. 202 2.2. Expectations of multihomed networks 204 The direct implication of Section 2.1 is that routing protocols used 205 in multihomed networks SHOULD be capable of source-prefix based 206 egress routing, and that multihomed networks SHOULD deploy them. 208 3. Reasonable expectations of the host 210 3.1. Default Router Selection 212 Default Router Selection is modified as follows: A host SHOULD select 213 default routers for each prefix it is assigned an address in. 214 Routers that have advertised the prefix in its Router Advertisement 215 message SHOULD be preferred over routers that do not advertise the 216 prefix. 218 As a result of doing so, when a host sends a packet using a source 219 address in one of those prefixes and has no history directing it 220 otherwise, it SHOULD send it to the indicated default router. In the 221 "simplest" network described in Section 2.1, that would get it to the 222 only router that is directly capable of getting it to the right ISP. 223 This will also apply in more complex networks, even when more than 224 one physical or virtual interface is involved. 226 In more complex cases, wherein routers advertise RAs for multiple 227 prefixes whether or not they have direct or isolated upstream 228 connectivity, the host is dependent on the routing system already. 229 If the host gives the packet to a router advertising its source 230 prefix, it should be able to depend on the router to do the right 231 thing. 233 3.2. Source Address Selection 235 There is an interaction with Default Address Selection [RFC6724]. 236 Rule 5.5 of that specification states that the source address used to 237 send to a given destination address should if possible be chosen from 238 a prefix known to be advertised by the first-hop router for that 239 destination. This selection rule would be applicable in a host 240 following the recommendation in the previous paragraph. 242 3.3. Redirects 244 There is potential for adverse interaction with any off-link Redirect 245 (Redirect for a GUA destination that is not on-link) message sent by 246 a router in accordance with Section 8 of [RFC4861]. Hosts SHOULD 247 apply off-link redirects only for the specific pair of source and 248 destination addresses concerned, so the host's Destination Cache may 249 need to contain appropriate source-specific entries. 251 3.4. History 253 Some modern hosts maintain history, in terms of what has previously 254 worked or not worked for a given address or prefix and in some cases 255 the effective window and MSS values for TCP or other protocols. This 256 might include a next hop address for use when a packet is sent to the 257 indicated address. 259 When such a host makes a successful exchange with a remote 260 destination using a particular address pair, and the host has 261 previously received a PIO that matches the source address, then the 262 host SHOULD include the prefix in such history, whatever the setting 263 of the L and A flags in the PIO. On subsequent attempts to 264 communicate with that destination, if it has an address in that 265 prefix at that time, a host MAY use an address in the remembered 266 prefix for the session. 268 4. Residual issues 270 Consider a network where routers on a link run a routing protocol and 271 are configured with the same information. Thus, on each link all 272 routers advertise all prefixes on the link. The assumption that 273 packets will be forwarded to the appropriate egress by the local 274 routing system might cause at least one extra hop in the local 275 network (from the host to the wrong router, and from there to another 276 router on the same link). 278 In a slightly more complex situation such as the disjoint LAN case of 279 Figure 1, which happens to be one of the authors' home plus corporate 280 home-office configuration, the two upstream routers might be on 281 different LANs and therefore different subnets (e.g., the host is 282 itself multi-homed). In that case, there is no way for the "wrong" 283 router to detect the existence of the "right" router, or to route to 284 it. 286 In such a case it is particularly important that hosts take the 287 responsibility to memorize and select the best first-hop as described 288 in Section 3. 290 5. IANA Considerations 292 This memo asks the IANA for no new parameters. 294 6. Security Considerations 296 This document does not create any new security or privacy exposures. 297 It is intended to avoid connectivity issues in the presence of BCP 38 298 ingress filters or stateful firewalls combined with multihoming. 300 There might be a small privacy improvement, however: with the current 301 practice, a multihomed host that sends packets with the wrong address 302 to an upstream router or network discloses the prefix of one upstream 303 to the other upstream network. This practice reduces the probability 304 of that occurrence. 306 7. Acknowledgements 308 Comments were received from Jinmei Tatuya and Ole Troan, who have 309 suggested important text, plus Mikael Abrahamsson, Steven Barth, 310 Juliusz Chroboczek, Toerless Eckert, David Farmer, Pierre Pfister, 311 Mark Smith, Dusan Mudric, and James Woodyatt. 313 8. References 315 8.1. Normative References 317 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 318 Requirement Levels", BCP 14, RFC 2119, 319 DOI 10.17487/RFC2119, March 1997, 320 . 322 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 323 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 324 December 1998, . 326 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 327 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 328 DOI 10.17487/RFC4861, September 2007, 329 . 331 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 332 "Default Address Selection for Internet Protocol Version 6 333 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 334 . 336 8.2. Informative References 338 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 339 Defeating Denial of Service Attacks which employ IP Source 340 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 341 May 2000, . 343 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 344 C., and M. Carney, "Dynamic Host Configuration Protocol 345 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 346 2003, . 348 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 349 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 350 2004, . 352 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 353 Address Autoconfiguration", RFC 4862, 354 DOI 10.17487/RFC4862, September 2007, 355 . 357 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 358 Extensions for Stateless Address Autoconfiguration in 359 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 360 . 362 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 363 Capabilities in Customer Premises Equipment (CPE) for 364 Providing Residential IPv6 Internet Service", RFC 6092, 365 DOI 10.17487/RFC6092, January 2011, 366 . 368 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 369 Requirements for IPv6 Customer Edge Routers", RFC 7084, 370 DOI 10.17487/RFC7084, November 2013, 371 . 373 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 374 Interface Identifiers with IPv6 Stateless Address 375 Autoconfiguration (SLAAC)", RFC 7217, 376 DOI 10.17487/RFC7217, April 2014, 377 . 379 Appendix A. Change Log 381 Initial Version: 2015-08-05 383 Version 01: Update text on PIOs, added text on Redirects, and 384 clarified the concept of a "simple" network, 2015-08-13. 386 Version 02: Clarifications after WG discussions, 2015-08-19. 388 Version 03: More clarifications after more WG discussions, 389 especially adding stateful firewalls, uRPF, and more precise 390 discussion of RFC 4861, 2015-09-03. 392 Authors' Addresses 394 Fred Baker 395 Cisco Systems 396 Santa Barbara, California 93117 397 USA 399 Email: fred@cisco.com 401 Brian Carpenter 402 Department of Computer Science 403 University of Auckland 404 PB 92019 405 Auckland 1142 406 New Zealand 408 Email: brian.e.carpenter@gmail.com