idnits 2.17.1 draft-ietf-6man-multi-homed-host-08.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 (August 19, 2016) is 2797 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 (-07) exists of draft-ietf-rtgwg-dst-src-routing-02 -- 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 (~~), 2 warnings (==), 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: February 20, 2017 August 19, 2016 8 First-hop router selection by hosts in a multi-prefix network 9 draft-ietf-6man-multi-homed-host-08 11 Abstract 13 This document describes expected IPv6 host behavior in a scenario 14 that has more than one prefix, each allocated by an upstream network 15 that is assumed to implement BCP 38 ingress filtering, when the host 16 has multiple routers to choose from. It also applies to other 17 scenarios such as the usage of stateful firewalls that effectively 18 act as address-based filters. Host behavior in choosing a first-hop 19 router may interact with source address selection in a given 20 implementation. However, the selection of the source address for a 21 packet is done before the first-hop router for that packet is chosen. 22 Given that the network or host is, or appears to be, multihomed with 23 multiple provider-allocated addresses, that the host has elected to 24 use a 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 February 20, 2017. 47 Copyright Notice 49 Copyright (c) 2016 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. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3 66 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 67 2. Sending context expected by the host . . . . . . . . . . . . 5 68 2.1. Expectations the host has of the network . . . . . . . . 5 69 2.2. Expectations of multihomed networks . . . . . . . . . . . 7 70 3. Reasonable expectations of the host . . . . . . . . . . . . . 7 71 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 72 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8 73 3.3. Source Address Selection . . . . . . . . . . . . . . . . 9 74 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 75 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 76 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 10 77 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 79 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 80 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 82 8.2. Informative References . . . . . . . . . . . . . . . . . 11 83 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction and Applicability 88 This document describes the expected behavior of an IPv6 [RFC2460] 89 host in a network that has more than one prefix, each allocated by an 90 upstream network that is assumed to implement BCP 38 [RFC2827] 91 ingress filtering, and in which the host is presented with a choice 92 of routers. It expects that the network will implement some form of 93 egress routing, so that packets sent to a host outside the local 94 network from a given ISP's prefix will go to that ISP. If the packet 95 is sent to the wrong egress, it is liable to be discarded by the BCP 96 38 filter. However, the mechanics of egress routing once the packet 97 leaves the host are out of scope. The question here is how the host 98 interacts with that network. 100 Various aspects of this issue, and possible solution approaches, are 101 discussed in the document IPv6 Multihoming without Network Address 102 Translation [RFC7157]. 104 BCP 38 filtering by ISPs is not the only scenario where such behavior 105 is valuable. Implementations that combine existing recommendations, 106 such as [RFC6092] [RFC7084] can also result in such filtering. 107 Another case is when the connections to the upstream networks include 108 stateful firewalls, such that return packets in a stream will be 109 discarded if they do not return via the firewall that created state 110 for the outgoing packets. A similar cause of such discards is 111 unicast reverse path forwarding (uRPF) [RFC3704]. 113 In this document, the term "filter" is used for simplicity to cover 114 all such cases. In any case, one cannot assume the host to be aware 115 whether an ingress filter, a stateful firewall, or any other type of 116 filter is in place. Therefore, the only known consistent solution is 117 to implement the features defined in this document. 119 Note that, apart from ensuring that a message with a given source 120 address is given to a first-hop router that appears to know about the 121 prefix in question, this specification is consistent with [RFC4861]. 122 Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6 and 8.1 of 123 RFC 4861 should extend their implementations accordingly. This 124 specification is fully consistent with [RFC6724] and depends on 125 support for its Rule 5.5 (see Section 3.3). Hosts that do not 126 support these features may fail to communicate in the presence of 127 filters as described above. 129 1.1. Host Model 131 It could be argued that the proposal of this document, which is to 132 send messages using a source address in a given prefix to the router 133 that advertised the prefix in its Router Advertisement (RA), is a 134 form of [RFC1122]'s Strong End System (ES, e.g. Host) Model, 135 discussed in section 3.3.4.2 of that document. In short, [RFC1122] 136 identifies two basic models, in which the "strong host" model models 137 the host as a set of hosts in one chassis, each of which uses a 138 single address on a single interface, and always both sends and 139 receives on that interface, and the "weak host" model treats the host 140 as one system with zero or more addresses on every interface, and 141 capable of using any interface for any communication. As noted 142 there, neither model is completely satisfactory. For example, a host 143 with a link-local-only interface and a default route pointing to that 144 interface will necessarily send packets using that interface but with 145 a source address derived from some other interface, and will 146 therefore be a de facto weak host. If the router upstream from such 147 a host implements BCP 38 Ingress Filtering [RFC2827], such as by 148 implementing uRPF on each interface, the router might prevent 149 communication by weak hosts. 151 +-----------------+ 152 | | 153 | MIF Router +---/--- other interfaces 154 | | 155 +---+---------+---+ 156 | | Two interfaces using same prefix 157 --+-+-- --+-+-- 158 | | 159 +--+---------+--+ 160 | MIF Host | 161 +---------------+ 163 Figure 1: Hypothetical MIF interconnection 165 The proposal also differs slightly from [RFC1122]'s language of the 166 Strong Host Model. The statement is that the packet will go to the 167 router that advertised a given prefix, but doesn't state what 168 interface that might happen on. Hence, if the router is a multi- 169 interface (MIF) router and is using the same prefix on two or more 170 LANs shared by the host (as in Figure 1), the host might use each of 171 those LANs and meet the requirement. The Strong Host Model is not 172 stated in those terms, but in terms of the interface used, and would 173 find such a MIF router quite confusing: 175 (A) A host MUST silently discard an incoming datagram whose 176 destination address does not correspond to the physical interface 177 through which it is received. 179 (B) A host MUST restrict itself to sending (non-source- routed) IP 180 datagrams only through the physical interface that corresponds to 181 the IP source address of the datagrams. 183 However, comparing the presumptive route lookup mechanisms in each 184 model, this proposal is indeed most similar to the Strong Host Model, 185 as is any source/destination routing paradigm. 187 Strong: route(src IP addr, dest IP addr, TOS) -> gateway 189 Weak: route(dest IP addr, TOS) -> gateway, interface 190 In the hypothetical MIF model suggested in Figure 1, the address 191 fails to identify a single interface, but it does identify a single 192 gateway. 194 1.2. Requirements Language 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 197 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 198 document are to be interpreted as described in [RFC2119]. 200 2. Sending context expected by the host 202 2.1. Expectations the host has of the network 204 A host receives prefixes in a Router Advertisement [RFC4861], which 205 goes on to identify whether they are usable by SLAAC [RFC4862] with 206 any type of interface identifier [RFC4941] [RFC7217]. When no 207 prefixes are usable for SLAAC, the Router Advertisement would 208 normally signal the availability of DHCPv6 [RFC3315] and the host 209 would use it to configure its addresses. In the latter case (or if 210 both SLAAC and DHCPv6 are used on the same link for some reason) it 211 will generally be the case that the configured addresses match one of 212 the prefixes advertised in a Router Advertisement that are supposed 213 to be on-link for that link. 215 The simplest multihomed network implementation in which a host makes 216 choices among routers might be a LAN with one or more hosts on it and 217 two or more routers, one for each upstream network, or a host that is 218 served by disjoint networks on separate interfaces. In such a 219 network, especially the latter, there is not necessarily a routing 220 protocol, and the two routers may not even know that the other is a 221 router as opposed to a host, or may be configured to ignore its 222 presence. One might expect that the routers may or may not receive 223 each other's RAs and form an address in the other router's prefix 224 (which is not per [RFC4862], but is implemented by some stub router 225 implementations). However, all hosts in such a network might be 226 expected to create an address in each prefix so advertised. 228 +---------+ +---------+ +---------+ +---------+ 229 | ISP | | ISP | | ISP | | ISP | 230 +----+----+ +----+----+ +----+----+ +----+----+ 231 | | | | 232 | | | | 233 +----+----+ +----+----+ +----+----+ +----+----+ 234 | Router | | Router | | Router | | Router | 235 +----+----+ +----+----+ +----+----+ +----+----+ 236 | | | | 237 +------+------+ | +--------+ | 238 | +--+ Host +--+ 239 +----+----+ +--------+ 240 | Host | 241 +---------+ 242 Common LAN Case Disjoint LAN Case 243 (Multihomed Network) (Multihomed Host) 245 Figure 2: Two simple networks 247 If there is no routing protocol among those routers, there is no 248 mechanism by which packets can be deterministically forwarded between 249 the routers (as described in BCP 84 [RFC3704]) in order to avoid 250 filters. Even if there was routing, it would result in an indirect 251 route, rather than a direct route originating with the host; this is 252 not "wrong", but can be inefficient. Therefore the host would do 253 well to select the appropriate router itself. 255 Since the host derives fundamental default routing information from 256 the Router Advertisement, this implies that, in any network with 257 hosts using multiple prefixes, each prefix SHOULD be advertised via a 258 Prefix Information Option (PIO) [RFC4861] by one of the attached 259 routers, even if addresses are being assigned using DHCPv6. A router 260 that advertises a prefix indicates that it is able to appropriately 261 route packets with source addresses within that prefix, regardless of 262 the setting of the L and A flags in the PIO. 264 In some circumstances both L and A might be zero. If SLAAC is not 265 wanted (A=0) and there is no reason to announce an on-link prefix 266 (L=0), a PIO SHOULD be sent to inform hosts that they should use the 267 router in question as the first hop for packets with source addresses 268 in the PIO prefix. Although this does not violate the existing 269 standard [RFC4861], such a PIO has not previously been common, and it 270 is possible that existing host implementations simply ignore such a 271 PIO or that existing router implementations are not capable of 272 sending such a PIO. Newer implementations that support this 273 mechanism should be updated accordingly: 275 o A host SHOULD NOT ignore a PIO simply because both L and A flags 276 are cleared (extending Section 6.3.4 of [RFC4861]). 278 o A router SHOULD be able to send such a PIO (extending 279 Section 6.2.3 of [RFC4861]). 281 2.2. Expectations of multihomed networks 283 The mechanism specified in this document requires some form of 284 support from the routing protocols used in multihomed networks. One 285 such way of providing the requisite support in routing protocols is 286 described in a routing protocol independent fashion 287 [I-D.ietf-rtgwg-dst-src-routing]. Network designs exist that can 288 usefully limit themselves to static routing (such as a simple tree 289 network), or may internally use no routers at all, such as a single 290 LAN with two CE routers, each of which leads to a different upstream 291 network. 293 3. Reasonable expectations of the host 295 3.1. Interpreting Router Advertisements 297 As described in [RFC4191] and [RFC4861], a Router Advertisement may 298 contain zero or more Prefix information Options (PIOs), or zero or 299 more Route Information Options (RIOs). In their original intent, 300 these indicate general information to a host: "the router whose 301 address is found in the source address field of this packet is one of 302 your default routers", "you might create an address in this prefix", 303 or "this router would be a good place to send traffic directed to a 304 given destination prefix". In a multi-prefix network with multiple 305 exits, the host's characterization of each default router SHOULD 306 include the prefixes it has announced (extending Section 6.3.4 of 307 [RFC4861]). In other words, the PIO is reinterpreted to also imply 308 that the advertising router would be a reasonable first hop for any 309 packet using a source address in any advertised prefix, regardless of 310 Default Router Preference. 312 +---------+ | 313 ( ISP A ) - + Bob-A +--+ +-----+ 314 +-------+ / +---------+ +--+ | 315 | | / | | | 316 | Alice +--/--( The Internet ) | Bob | 317 | | \ | | | 318 +-------+ \ +---------+ +--+ | 319 ( ISP B ) - + Bob-B +--+ +-----+ 320 +---------+ | 322 Figure 3: PIOs, RIOs, and Default Routes 324 The implications bear consideration. Imagine, Figure 3, that hosts 325 Alice and Bob are in communication. Bob's network consists at least 326 of Bob (the computer), 2 routers (Bob-A and Bob-B), and the links 327 between them; it may be much larger, for example a campus or 328 corporate network. Bob's network is therefore multihomed, and Bob's 329 first hop routers are Bob-A (to upstream ISP A advertising prefix PA) 330 and Bob-B (to upstream network B and advertising prefix PB). We 331 assume that Bob is not applying Rule 5.5 of [RFC6724]. If Bob is 332 responding to a message from Alice, his choice of source address is 333 forced to be the address Alice used as a destination (which we may 334 presume to have been in prefix PA). Hence, Bob created or was 335 assigned an address in PA, and can only reasonably send traffic using 336 it to Bob-A as a first hop router. If there are several routers in 337 Bob's network advertising the prefix PA (referred to as Bob-Ax 338 routers), then Bob should choose its first-hop router only from among 339 those routers. From among the multiple Bob-Ax routers, Bob should 340 choose the first-hop router based on the criteria specified in 341 Section 3 of [RFC4191]. If none of the Bob-Ax routers has advertised 342 an RA with a non-zero Router Lifetime or an RIO with a non-zero Route 343 Lifetime that includes Alice, but router Bob-B has, it is irrelevant. 344 Bob is using the address allocated in PA and courts a BCP 38 discard 345 if he doesn't send the packet to Bob-A. 347 In the special case that Bob is initiating the conversation, an RIO 348 might, however, influence source address choice. Bob could 349 presumably use any address allocated to him, in this case his address 350 in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and 351 Bob-A has not, Bob MAY take that fact into account in address 352 selection - choosing an address that would allow him to make use of 353 the RIO. 355 3.2. Default Router Selection 357 Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as 358 follows: A host SHOULD select default routers for each prefix it is 359 assigned an address in. Routers that have advertised the prefix in 360 its Router Advertisement message SHOULD be preferred over routers 361 that do not advertise the prefix, regardless of Default Router 362 Preference. Note that this document does not change the way in which 363 default router preferences are communicated [RFC4191]. 365 If no router has advertised the prefix in an RA, normal routing 366 metrics will apply. An example is a host connected to the Internet 367 via one router, and at the same time connected by a VPN to a private 368 domain which is also connected to the global Internet. 370 As a result of this, when a host sends a packet using a source 371 address in one of those prefixes and has no history directing it 372 otherwise, it SHOULD send it to the indicated default router. In the 373 "simplest" network described in Section 2.1, that would get it to the 374 only router that is directly capable of getting it to the right ISP. 375 This will also apply in more complex networks, even when more than 376 one physical or virtual interface is involved. 378 In more complex cases, wherein routers advertise RAs for multiple 379 prefixes whether or not they have direct or isolated upstream 380 connectivity, the host is dependent on the routing system already. 381 If the host gives the packet to a router advertising its source 382 prefix, it should be able to depend on the router to do the right 383 thing. 385 3.3. Source Address Selection 387 There is an interaction with Default Address Selection [RFC6724]. A 388 host following the recommendation in the previous section will store 389 information about which next-hops advertised which prefixes. Rule 390 5.5 of RFC 6724 states that the source address used to send to a 391 given destination address should if possible be chosen from a prefix 392 known to be advertised by the next-hop router for that destination. 393 This selection rule SHOULD therefore be implemented in a host 394 following the recommendation in the previous section. 396 3.4. Redirects 398 There is potential for adverse interaction with any off-link Redirect 399 (Redirect for a destination that is not on-link) message sent by a 400 router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply 401 off-link redirects only for the specific pair of source and 402 destination addresses concerned, so the host's Destination Cache 403 might need to contain appropriate source-specific entries. This 404 extends the validity check specified in Section 8.1 of [RFC4861]. 406 3.5. History 408 Some modern hosts maintain history, in terms of what has previously 409 worked or not worked for a given address or prefix and in some cases 410 the effective window and MSS values for TCP or other protocols. This 411 might include a next hop address for use when a packet is sent to the 412 indicated address. 414 When such a host makes a successful exchange with a remote 415 destination using a particular address pair, and the host has 416 previously received a PIO that matches the source address, then the 417 host SHOULD include the prefix in such history, whatever the setting 418 of the L and A flags in the PIO. On subsequent attempts to 419 communicate with that destination, if it has an address in that 420 prefix at that time, a host MAY use an address in the remembered 421 prefix for the session. 423 4. Residual issues 425 Consider a network where routers on a link run a routing protocol and 426 are configured with the same information. Thus, on each link all 427 routers advertise all prefixes on the link. The assumption that 428 packets will be forwarded to the appropriate egress by the local 429 routing system might cause at least one extra hop in the local 430 network (from the host to the wrong router, and from there to another 431 router on the same link). 433 In a slightly more complex situation such as the disjoint LAN case of 434 Figure 2, for example a home plus corporate home-office 435 configuration, the two upstream routers might be on different LANs 436 and therefore different subnets (e.g., the host is itself multi- 437 homed). In that case, there is no way for the "wrong" router to 438 detect the existence of the "right" router, or to route to it. 440 In such a case it is particularly important that hosts take the 441 responsibility to memorize and select the best first-hop as described 442 in Section 3. 444 5. IANA Considerations 446 This memo asks the IANA for no new parameters. 448 6. Security Considerations 450 This document is intended to avoid connectivity issues in the 451 presence of BCP 38 ingress filters or stateful firewalls combined 452 with multihoming. It does not in itself create any new security or 453 privacy exposures. However, since the solution is designed to ensure 454 that routing occurs correctly in situations where it previously 455 failed, this might result in unexpected exposure of networks that 456 were previously unreachable. 458 There might be a small privacy improvement: with the current 459 practice, a multihomed host that sends packets with the wrong address 460 to an upstream router or network discloses the prefix of one upstream 461 to the other upstream network. This practice reduces the probability 462 of that occurrence. 464 7. Acknowledgements 466 Comments were received from Jinmei Tatuya and Ole Troan, who have 467 suggested important text, plus Mikael Abrahamsson, Steven Barth, 468 Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz Chroboczek, 469 Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric, 470 Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith and 471 James Woodyatt. 473 8. References 475 8.1. Normative References 477 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 478 Requirement Levels", BCP 14, RFC 2119, 479 DOI 10.17487/RFC2119, March 1997, 480 . 482 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 483 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 484 December 1998, . 486 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 487 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 488 November 2005, . 490 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 491 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 492 DOI 10.17487/RFC4861, September 2007, 493 . 495 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 496 "Default Address Selection for Internet Protocol Version 6 497 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 498 . 500 8.2. Informative References 502 [I-D.ietf-rtgwg-dst-src-routing] 503 Lamparter, D. and A. Smirnov, "Destination/Source 504 Routing", draft-ietf-rtgwg-dst-src-routing-02 (work in 505 progress), May 2016. 507 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 508 Communication Layers", STD 3, RFC 1122, 509 DOI 10.17487/RFC1122, October 1989, 510 . 512 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 513 Defeating Denial of Service Attacks which employ IP Source 514 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 515 May 2000, . 517 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 518 C., and M. Carney, "Dynamic Host Configuration Protocol 519 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 520 2003, . 522 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 523 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 524 2004, . 526 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 527 Address Autoconfiguration", RFC 4862, 528 DOI 10.17487/RFC4862, September 2007, 529 . 531 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 532 Extensions for Stateless Address Autoconfiguration in 533 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 534 . 536 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 537 Capabilities in Customer Premises Equipment (CPE) for 538 Providing Residential IPv6 Internet Service", RFC 6092, 539 DOI 10.17487/RFC6092, January 2011, 540 . 542 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 543 Requirements for IPv6 Customer Edge Routers", RFC 7084, 544 DOI 10.17487/RFC7084, November 2013, 545 . 547 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 548 and D. Wing, "IPv6 Multihoming without Network Address 549 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 550 . 552 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 553 Interface Identifiers with IPv6 Stateless Address 554 Autoconfiguration (SLAAC)", RFC 7217, 555 DOI 10.17487/RFC7217, April 2014, 556 . 558 Appendix A. Change Log (RFC Editor: please delete) 560 Initial Version: 2015-08-05 562 Version 01: Update text on PIOs, added text on Redirects, and 563 clarified the concept of a "simple" network, 2015-08-13. 565 Version 02: Clarifications after WG discussions, 2015-08-19. 567 Version 03: More clarifications after more WG discussions, 568 especially adding stateful firewalls, uRPF, and more precise 569 discussion of RFC 4861, 2015-09-03. 571 Version 04: Responds to various comments including 573 * Questions regarding RFC 1122's strong and weak host models. 574 This model is, strictly speaking, neither, but is most similar 575 to the strong host model. 577 * Some wording errors. 579 * Requests for discussion of the handling of the RIO, PIO, and 580 Default Router List in an RA. 582 WG Versions 00-02: More clarifications after more WG discussions, 583 2015-11-03. 585 WG Version 03: A final clarification re uRPF, 2015-12-15. 587 WG Versions 04-07: Various clarifications and review comments, 588 2016-06-23. 590 WG Version 08: Fixes for IETF Last Call and IESG comments, 591 2016-08-15. 593 Authors' Addresses 595 Fred Baker 596 Cisco Systems 597 Santa Barbara, California 93117 598 USA 600 Email: fred@cisco.com 601 Brian Carpenter 602 Department of Computer Science 603 University of Auckland 604 PB 92019 605 Auckland 1142 606 New Zealand 608 Email: brian.e.carpenter@gmail.com