idnits 2.17.1 draft-ietf-6man-multi-homed-host-07.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 (June 23, 2016) is 2864 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: December 25, 2016 June 23, 2016 8 Routing packets from hosts in a multi-prefix network 9 draft-ietf-6man-multi-homed-host-07 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 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. This host behavior may interact with source address 19 selection in a given implementation, but logically follows it. Given 20 that the network or host is, or appears to be, multihomed with 21 multiple provider-allocated addresses, that the host has elected to 22 use a source address in a given prefix, and that some but not all 23 neighboring routers are advertising that prefix in their Router 24 Advertisement Prefix Information Options, this document specifies to 25 which router a host should present its transmission. It updates RFC 26 4861. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on December 25, 2016. 45 Copyright Notice 47 Copyright (c) 2016 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction and Applicability . . . . . . . . . . . . . . . 2 63 1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 65 2. Sending context expected by the host . . . . . . . . . . . . 5 66 2.1. Expectations the host has of the network . . . . . . . . 5 67 2.2. Expectations of multihomed networks . . . . . . . . . . . 7 68 3. Reasonable expectations of the host . . . . . . . . . . . . . 7 69 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 70 3.2. Default Router Selection . . . . . . . . . . . . . . . . 8 71 3.3. Source Address Selection . . . . . . . . . . . . . . . . 9 72 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 73 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Residual issues . . . . . . . . . . . . . . . . . . . . . . . 9 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 77 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 10 78 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 79 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 80 8.2. Informative References . . . . . . . . . . . . . . . . . 11 81 Appendix A. Change Log (RFC Editor: please delete) . . . . . . . 12 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 84 1. Introduction and Applicability 86 This document describes the expected behavior of an IPv6 [RFC2460] 87 host 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 Various aspects of this issue, and possible solution approaches, are 99 discussed in the document IPv6 Multihoming without Network Address 100 Translation [RFC7157]. 102 BCP 38 filtering by ISPs is not the only scenario where such behavior 103 is valuable. Implementations that combine existing recommendations, 104 such as [RFC6092] [RFC7084] can also result in such filtering. 105 Another case is when the connections to the upstream networks include 106 stateful firewalls, such that return packets in a stream will be 107 discarded if they do not return via the firewall that created state 108 for the outgoing packets. A similar cause of such discards is 109 unicast reverse path forwarding (uRPF) [RFC3704]. 111 In this document, the term "filter" is used for simplicity to cover 112 all such cases. In any case, one cannot assume the host to be aware 113 whether an ingress filter, a stateful firewall, or any other type of 114 filter is in place. Therefore, the only consistent solution is to 115 implement the features defined in this document. 117 Note that, apart from ensuring that a message with a given source 118 address is given to a first-hop router that appears to know about the 119 prefix in question, this specification is consistent with [RFC4861]. 120 Nevertheless, implementers of Sections 5.2, 6.2.3, 6.3.4 and 8 of RFC 121 4861 will need to extend their implementations accordingly. This 122 specification is fully consistent with [RFC6724] and implementers 123 will need to add support for its Rule 5.5. Hosts that do not support 124 these features may fail to communicate in the presence of filters as 125 described above. 127 1.1. Host Model 129 It could be argued that the proposal of this document, which is to 130 send messages using a source address in a given prefix to the router 131 that advertised the prefix in its Router Advertisement (RA), is a 132 form of [RFC1122]'s Strong End System (ES, e.g. Host) Model, 133 discussed in section 3.3.4.2 of that document. In short, [RFC1122] 134 identifies two basic models, in which the "strong host" model models 135 the host as a set of hosts in one chassis, each of which uses a 136 single address on a single interface, and always both sends and 137 receives on that interface, and the "weak host" model treats the host 138 as one system with zero or more addresses on every interface, and 139 capable of using any interface for any communication. As noted 140 there, neither model is completely satisfactory. For example, a host 141 with a link-local-only interface and a default route pointing to that 142 interface will necessarily send packets using that interface but with 143 a source address derived from some other interface, and will 144 therefore be a de facto weak host. If the router upstream from such 145 a host implements BCP 38 Ingress Filtering [RFC2827], such as by 146 implementing uRPF on each interface, the router might prevent 147 communication by weak hosts. 149 +-----------------+ 150 | | 151 | MIF Router +---/--- other interfaces 152 | | 153 +---+---------+---+ 154 | | Two interfaces sharing a prefix 155 --+-+-- --+-+-- 156 | | 157 +--+---------+--+ 158 | MIF Host | 159 +---------------+ 161 Figure 1: Hypothetical MIF interconnection 163 The proposal also differs slightly from [RFC1122]'s language of the 164 Strong Host Model. The statement is that the packet will go to the 165 router that advertised a given prefix, but doesn't state what 166 interface that might happen on. Hence, if the router is a multi- 167 interface (MIF) router and is using the same prefix on two or more 168 LANs shared by the host (as in Figure 1), the host might use each of 169 those LANs and meet the requirement. The Strong Host Model is not 170 stated in those terms, but in terms of the interface used, and would 171 find a MIF router quite confusing: 173 (A) A host MUST silently discard an incoming datagram whose 174 destination address does not correspond to the physical interface 175 through which it is received. 177 (B) A host MUST restrict itself to sending (non-source- routed) IP 178 datagrams only through the physical interface that corresponds to 179 the IP source address of the datagrams. 181 However, comparing the presumptive route lookup mechanisms in each 182 model, this proposal is indeed most similar to the Strong Host Model, 183 as is any source/destination routing paradigm. 185 Strong: route(src IP addr, dest IP addr, TOS) -> gateway 187 Weak: route(dest IP addr, TOS) -> gateway, interface 188 In the hypothetical MIF model suggested in Figure 1, the address 189 fails to identify a single interface, but it does identify a single 190 gateway. 192 1.2. Requirements Language 194 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 195 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 196 document are to be interpreted as described in [RFC2119]. 198 2. Sending context expected by the host 200 2.1. Expectations the host has of the network 202 A host receives prefixes in a Router Advertisement [RFC4861], which 203 goes on to identify whether they are usable by SLAAC [RFC4862] 204 [RFC4941] [RFC7217]. When no prefixes are usable for SLAAC, the 205 Router Advertisement would normally signal the availability of DHCPv6 206 [RFC3315] and the host would use it to configure its addresses. In 207 the latter case (or if both SLAAC and DHCPv6 are used on the same 208 link for some reason) it will generally be the case that the 209 configured addresses match one of the prefixes advertised in a Router 210 Advertisement that are supposed to be on-link for that link. 212 The simplest multihomed network implementation in which a host makes 213 choices among routers might be a LAN with one or more hosts on it and 214 two or more routers, one for each upstream network, or a host that is 215 served by disjoint networks on separate interfaces. In such a 216 network, especially the latter, there is not necessarily a routing 217 protocol, and the two routers may not even know that the other is a 218 router as opposed to a host, or may be configured to ignore its 219 presence. One might expect that the routers may or may not receive 220 each other's RAs and form an address in the other router's prefix 221 (which is not per [RFC4862], but is implemented by some stub router 222 implementations). However, all hosts in such a network might be 223 expected to create an address in each prefix so advertised. 225 +---------+ +---------+ +---------+ +---------+ 226 | ISP | | ISP | | ISP | | ISP | 227 +----+----+ +----+----+ +----+----+ +----+----+ 228 | | | | 229 | | | | 230 +----+----+ +----+----+ +----+----+ +----+----+ 231 | Router | | Router | | Router | | Router | 232 +----+----+ +----+----+ +----+----+ +----+----+ 233 | | | | 234 +------+------+ | +--------+ | 235 | +--+ Host +--+ 236 +----+----+ +--------+ 237 | Host | 238 +---------+ 239 Common LAN Case Disjoint LAN Case 240 (Multihomed Network) (Multihomed Host) 242 Figure 2: Two simple networks 244 If there is no routing protocol among those routers, there is no 245 mechanism by which packets can be deterministically forwarded between 246 the routers (as described in BCP 84 [RFC3704]) in order to avoid 247 filters. Even if there was routing, it would result in an indirect 248 route, rather than a direct route originating with the host; this is 249 not "wrong", but can be inefficient. Therefore the host would do 250 well to select the appropriate router itself. 252 Since the host derives fundamental default routing information from 253 the Router Advertisement, this implies that, in any network with 254 hosts using multiple prefixes, each prefix SHOULD be advertised via a 255 Prefix Information Option (PIO) [RFC4861] by one of the attached 256 routers, even if addresses are being assigned using DHCPv6. A router 257 that advertises a prefix indicates that it is able to appropriately 258 route packets with source addresses within that prefix, regardless of 259 the setting of the L and A flags in the PIO. 261 In some circumstances both L and A might be zero. If SLAAC is not 262 wanted (A=0) and there is no reason to announce an on-link prefix 263 (L=0), a PIO SHOULD be sent to inform hosts that the prefix is 264 source-routed by the router in question. Although this does not 265 violate the existing standard [RFC4861], such a PIO has not 266 previously been common, and it is possible that existing host 267 implementations simply ignore such a PIO or that a router 268 implementation rejects such a PIO as a configuration error. Newer 269 implementations that support this mechanism will need to be updated 270 accordingly: a host SHOULD NOT ignore a PIO simply because both L and 271 A flags are cleared; a router SHOULD be able to send such a PIO. 273 2.2. Expectations of multihomed networks 275 The direct implication of Section 2.1 is that, if the network uses a 276 routing protocol, the routing protocols used in multihomed networks 277 SHOULD implement source-prefix based egress routing, for example as 278 described in [I-D.ietf-rtgwg-dst-src-routing]. Network designs exist 279 that can usefully limit themselves to static routing (such as a 280 simple tree network), or may internally use no routers at all, such 281 as a single LAN with two CE routers, each of which leads to a 282 different upstream network. 284 3. Reasonable expectations of the host 286 3.1. Interpreting Router Advertisements 288 As described in [RFC4191] and [RFC4861], a Router Advertisement may 289 contain zero or more Prefix information Options (PIOs), or zero or 290 more Route Information Options (RIOs). In their original intent, 291 these indicate general information to a host: "the router whose 292 address is found in the source address field of this packet is one of 293 your default routers", "you might create an address in this prefix", 294 or "this router would be a good place to send traffic directed to a 295 given destination prefix". In a multi-homed network implementing 296 source/destination routing, the interpretation of default router or 297 an RIO has to be modified with the words "if the source address is in 298 one of the prefixes I advertise in a PIO". Additionally, the PIO 299 must be reinterpreted to also imply that the advertising router would 300 be a reasonable first hop for any packet using a source address in 301 any advertised prefix. 303 +---------+ | 304 ( ISP A ) - + Bob-A +--+ +-----+ 305 +-------+ / +---------+ +--+ | 306 | | / | | | 307 | Alice +--/--( The Internet ) | Bob | 308 | | \ | | | 309 +-------+ \ +---------+ +--+ | 310 ( ISP B ) - + Bob-B +--+ +-----+ 311 +---------+ | 313 Figure 3: PIOs, RIOs, and Default Routes 315 The implications bear consideration. Imagine, Figure 3, that hosts 316 Alice and Bob are in communication. Bob's network consists at least 317 of Bob (the computer), 2 routers (Bob-A and Bob-B), and the links 318 between them; it may be much larger, for example a campus or 319 corporate network. Bob's network is therefore multihomed, and Bob's 320 first hop routers are Bob-A (to upstream ISP A advertising prefix PA) 321 and Bob-B (to upstream network B and advertising prefix PB). If Bob 322 is responding to a message from Alice, his choice of source address 323 is forced to be the address Alice used as a destination (which we may 324 presume to have been in prefix PA). Hence, Bob created or was 325 assigned an address in PA, and can only reasonably send traffic using 326 it to Bob-A as a first hop router. If there were several instances 327 of Bob-A and one had advertised itself as a default router or as 328 having a route to Alice, that is the router Bob should choose. If 329 none of Bob-A have advertised that but Bob-B has, it is irrelevant; 330 Bob is using the address allocated in PA and courts a BCP 38 discard 331 if he doesn't send the packet to Bob-A. 333 In the special case that Bob is initiating the conversation, an RIO 334 might, however, influence source address choice. Bob could 335 presumably use any address allocated to him, in this case his address 336 in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and 337 Bob-A has not, Bob MAY take that fact into account in address 338 selection - choosing an address that would allow him to make use of 339 the RIO. 341 3.2. Default Router Selection 343 Default Router Selection is modified as follows: A host SHOULD select 344 default routers for each prefix it is assigned an address in. 345 Routers that have advertised the prefix in its Router Advertisement 346 message SHOULD be preferred over routers that do not advertise the 347 prefix. (If no router has advertised the prefix in an RA, normal 348 routing metrics will apply. An example is a host connected to the 349 Internet via one router, and at the same time connected by a VPN to a 350 private domain which is also connected to the global Internet.) 352 As a result of this, when a host sends a packet using a source 353 address in one of those prefixes and has no history directing it 354 otherwise, it SHOULD send it to the indicated default router. In the 355 "simplest" network described in Section 2.1, that would get it to the 356 only router that is directly capable of getting it to the right ISP. 357 This will also apply in more complex networks, even when more than 358 one physical or virtual interface is involved. 360 In more complex cases, wherein routers advertise RAs for multiple 361 prefixes whether or not they have direct or isolated upstream 362 connectivity, the host is dependent on the routing system already. 363 If the host gives the packet to a router advertising its source 364 prefix, it should be able to depend on the router to do the right 365 thing. 367 3.3. Source Address Selection 369 There is an interaction with Default Address Selection [RFC6724]. A 370 host following the recommendation in the previous section will store 371 information about which next-hops advertised which prefixes. Rule 372 5.5 of RFC 6724 states that the source address used to send to a 373 given destination address should if possible be chosen from a prefix 374 known to be advertised by the next-hop router for that destination. 375 This selection rule would therefore be applicable in a host following 376 the recommendation in the previous section. 378 3.4. Redirects 380 There is potential for adverse interaction with any off-link Redirect 381 (Redirect for a destination that is not on-link) message sent by a 382 router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply 383 off-link redirects only for the specific pair of source and 384 destination addresses concerned, so the host's Destination Cache may 385 need to contain appropriate source-specific entries. 387 3.5. History 389 Some modern hosts maintain history, in terms of what has previously 390 worked or not worked for a given address or prefix and in some cases 391 the effective window and MSS values for TCP or other protocols. This 392 might include a next hop address for use when a packet is sent to the 393 indicated address. 395 When such a host makes a successful exchange with a remote 396 destination using a particular address pair, and the host has 397 previously received a PIO that matches the source address, then the 398 host SHOULD include the prefix in such history, whatever the setting 399 of the L and A flags in the PIO. On subsequent attempts to 400 communicate with that destination, if it has an address in that 401 prefix at that time, a host MAY use an address in the remembered 402 prefix for the session. 404 4. Residual issues 406 Consider a network where routers on a link run a routing protocol and 407 are configured with the same information. Thus, on each link all 408 routers advertise all prefixes on the link. The assumption that 409 packets will be forwarded to the appropriate egress by the local 410 routing system might cause at least one extra hop in the local 411 network (from the host to the wrong router, and from there to another 412 router on the same link). 414 In a slightly more complex situation such as the disjoint LAN case of 415 Figure 2, for example a home plus corporate home-office 416 configuration, the two upstream routers might be on different LANs 417 and therefore different subnets (e.g., the host is itself multi- 418 homed). In that case, there is no way for the "wrong" router to 419 detect the existence of the "right" router, or to route to it. 421 In such a case it is particularly important that hosts take the 422 responsibility to memorize and select the best first-hop as described 423 in Section 3. 425 5. IANA Considerations 427 This memo asks the IANA for no new parameters. 429 6. Security Considerations 431 This document does not create any new security or privacy exposures. 432 It is intended to avoid connectivity issues in the presence of BCP 38 433 ingress filters or stateful firewalls combined with multihoming. 435 There might be a small privacy improvement, however: with the current 436 practice, a multihomed host that sends packets with the wrong address 437 to an upstream router or network discloses the prefix of one upstream 438 to the other upstream network. This practice reduces the probability 439 of that occurrence. 441 7. Acknowledgements 443 Comments were received from Jinmei Tatuya and Ole Troan, who have 444 suggested important text, plus Mikael Abrahamsson, Steven Barth, 445 Carlos Bernardos Cano, Zhen Cao, Juliusz Chroboczek, Toerless Eckert, 446 David Farmer, Dusan Mudric, Tadahisa Okimoto, Pierre Pfister, Behcet 447 Sarikaya, Mark Smith, Bob Hinden, and James Woodyatt. 449 8. References 451 8.1. Normative References 453 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", BCP 14, RFC 2119, 455 DOI 10.17487/RFC2119, March 1997, 456 . 458 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 459 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, 460 December 1998, . 462 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 463 More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, 464 November 2005, . 466 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 467 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 468 DOI 10.17487/RFC4861, September 2007, 469 . 471 [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, 472 "Default Address Selection for Internet Protocol Version 6 473 (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, 474 . 476 8.2. Informative References 478 [I-D.ietf-rtgwg-dst-src-routing] 479 Lamparter, D. and A. Smirnov, "Destination/Source 480 Routing", draft-ietf-rtgwg-dst-src-routing-02 (work in 481 progress), May 2016. 483 [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - 484 Communication Layers", STD 3, RFC 1122, 485 DOI 10.17487/RFC1122, October 1989, 486 . 488 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 489 Defeating Denial of Service Attacks which employ IP Source 490 Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, 491 May 2000, . 493 [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, 494 C., and M. Carney, "Dynamic Host Configuration Protocol 495 for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 496 2003, . 498 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 499 Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 500 2004, . 502 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 503 Address Autoconfiguration", RFC 4862, 504 DOI 10.17487/RFC4862, September 2007, 505 . 507 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 508 Extensions for Stateless Address Autoconfiguration in 509 IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, 510 . 512 [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security 513 Capabilities in Customer Premises Equipment (CPE) for 514 Providing Residential IPv6 Internet Service", RFC 6092, 515 DOI 10.17487/RFC6092, January 2011, 516 . 518 [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic 519 Requirements for IPv6 Customer Edge Routers", RFC 7084, 520 DOI 10.17487/RFC7084, November 2013, 521 . 523 [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., 524 and D. Wing, "IPv6 Multihoming without Network Address 525 Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, 526 . 528 [RFC7217] Gont, F., "A Method for Generating Semantically Opaque 529 Interface Identifiers with IPv6 Stateless Address 530 Autoconfiguration (SLAAC)", RFC 7217, 531 DOI 10.17487/RFC7217, April 2014, 532 . 534 Appendix A. Change Log (RFC Editor: please delete) 536 Initial Version: 2015-08-05 538 Version 01: Update text on PIOs, added text on Redirects, and 539 clarified the concept of a "simple" network, 2015-08-13. 541 Version 02: Clarifications after WG discussions, 2015-08-19. 543 Version 03: More clarifications after more WG discussions, 544 especially adding stateful firewalls, uRPF, and more precise 545 discussion of RFC 4861, 2015-09-03. 547 Version 04: Responds to various comments including 549 * Questions regarding RFC 1122's strong and weak host models. 550 This model is, strictly speaking, neither, but is most similar 551 to the strong host model. 553 * Some wording errors. 555 * Requests for discussion of the handling of the RIO, PIO, and 556 Default Router List in an RA. 558 WG Versions 00-02: More clarifications after more WG discussions, 559 2015-11-03. 561 WG Version 03: A final clarification re uRPF, 2015-12-15. 563 WG Versions 04-07: Various clarifications and review comments, 564 2016-06-23. 566 Authors' Addresses 568 Fred Baker 569 Cisco Systems 570 Santa Barbara, California 93117 571 USA 573 Email: fred@cisco.com 575 Brian Carpenter 576 Department of Computer Science 577 University of Auckland 578 PB 92019 579 Auckland 1142 580 New Zealand 582 Email: brian.e.carpenter@gmail.com