diff options
Diffstat (limited to 'doc/rfc/rfc8028.txt')
| -rw-r--r-- | doc/rfc/rfc8028.txt | 731 |
1 files changed, 731 insertions, 0 deletions
diff --git a/doc/rfc/rfc8028.txt b/doc/rfc/rfc8028.txt new file mode 100644 index 0000000..58614b0 --- /dev/null +++ b/doc/rfc/rfc8028.txt @@ -0,0 +1,731 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Baker +Request for Comments: 8028 +Updates: 4861 B. Carpenter +Category: Standards Track Univ. of Auckland +ISSN: 2070-1721 November 2016 + + + First-Hop Router Selection by Hosts in a Multi-Prefix Network + +Abstract + + This document describes expected IPv6 host behavior in a scenario + that has more than one prefix, each allocated by an upstream network + that is assumed to implement BCP 38 ingress filtering, when the host + has multiple routers to choose from. It also applies to other + scenarios such as the usage of stateful firewalls that effectively + act as address-based filters. Host behavior in choosing a first-hop + router may interact with source address selection in a given + implementation. However, the selection of the source address for a + packet is done before the first-hop router for that packet is chosen. + Given that the network or host is, or appears to be, multihomed with + multiple provider-allocated addresses, that the host has elected to + use a source address in a given prefix, and that some but not all + neighboring routers are advertising that prefix in their Router + Advertisement Prefix Information Options, this document specifies to + which router a host should present its transmission. It updates RFC + 4861. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8028. + + + + + + + + + + +Baker & Carpenter Standards Track [Page 1] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction and Applicability . . . . . . . . . . . . . . . 3 + 1.1. Host Model . . . . . . . . . . . . . . . . . . . . . . . 4 + 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 + 2. Sending Context Expected by the Host . . . . . . . . . . . . 5 + 2.1. Expectations the Host Has of the Network . . . . . . . . 5 + 2.2. Expectations of Multihomed Networks . . . . . . . . . . . 7 + 3. Reasonable Expectations of the Host . . . . . . . . . . . . . 7 + 3.1. Interpreting Router Advertisements . . . . . . . . . . . 7 + 3.2. Default Router Selection . . . . . . . . . . . . . . . . 9 + 3.3. Source Address Selection . . . . . . . . . . . . . . . . 9 + 3.4. Redirects . . . . . . . . . . . . . . . . . . . . . . . . 9 + 3.5. History . . . . . . . . . . . . . . . . . . . . . . . . . 10 + 4. Residual Issues . . . . . . . . . . . . . . . . . . . . . . . 10 + 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 + 7.1. Normative References . . . . . . . . . . . . . . . . . . 11 + 7.2. Informative References . . . . . . . . . . . . . . . . . 12 + Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 13 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 + + + + + + + + + + + + + + +Baker & Carpenter Standards Track [Page 2] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +1. Introduction and Applicability + + This document describes the expected behavior of an IPv6 [RFC2460] + host in a network that has more than one prefix, each allocated by an + upstream network that is assumed to implement BCP 38 [RFC2827] + ingress filtering, and in which the host is presented with a choice + of routers. It expects that the network will implement some form of + egress routing, so that packets sent to a host outside the local + network from a given ISP's prefix will go to that ISP. If the packet + is sent to the wrong egress, it is liable to be discarded by the BCP + 38 filter. However, the mechanics of egress routing once the packet + leaves the host are out of scope. The question here is how the host + interacts with that network. + + Various aspects of this issue, and possible solution approaches, are + discussed in "IPv6 Multihoming without Network Address Translation" + [RFC7157]. + + BCP 38 filtering by ISPs is not the only scenario where such behavior + is valuable. Implementations that combine existing recommendations, + such as [RFC6092] and [RFC7084] can also result in such filtering. + Another case is when the connections to the upstream networks include + stateful firewalls, such that return packets in a stream will be + discarded if they do not return via the firewall that created the + state for the outgoing packets. A similar cause of such discards is + unicast reverse path forwarding (uRPF) [RFC3704]. + + In this document, the term "filter" is used for simplicity to cover + all such cases. In any case, one cannot assume that the host is + aware whether an ingress filter, a stateful firewall, or any other + type of filter is in place. Therefore, the only known consistent + solution is to implement the features defined in this document. + + Note that, apart from ensuring that a message with a given source + address is given to a first-hop router that appears to know about the + prefix in question, this specification is consistent with [RFC4861]. + Nevertheless, implementers of Sections 6.2.3, 6.3.4, 6.3.6, and 8.1 + of RFC 4861 should extend their implementations accordingly. This + specification is fully consistent with [RFC6724] and depends on + support for its Rule 5.5 (see Section 3.3). Hosts that do not + support these features may fail to communicate in the presence of + filters as described above. + + + + + + + + + +Baker & Carpenter Standards Track [Page 3] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +1.1. Host Model + + It could be argued that the proposal in this document, which is to + send messages using a source address in a given prefix to the router + that advertised the prefix in its Router Advertisement (RA), is a + form of the Strong End System (ES, e.g., Host) model, discussed in + Section 3.3.4.2 of [RFC1122]. In short, [RFC1122] identifies two + basic models. First, the "strong host" model describes the host as a + set of hosts in one chassis, each of which uses a single address on a + single interface and always both sends and receives on that + interface. Alternatively, the "weak host" model treats the host as + one system with zero or more addresses on every interface and is + capable of using any interface for any communication. As noted + there, neither model is completely satisfactory. For example, a host + with a link-local-only interface and a default route pointing to that + interface will necessarily send packets using that interface but with + a source address derived from some other interface, and will + therefore be a de facto weak host. If the router upstream from such + a host implements BCP 38 Ingress Filtering [RFC2827], such as by + implementing uRPF on each interface, the router might prevent + communication by weak hosts. + + +-----------------+ + | | + | MIF Router +---/--- Other interfaces + | | + +---+---------+---+ + | | Two interfaces with subnets + | | from a common prefix + --+-+-- --+-+-- + | | + +--+---------+--+ + | MIF Host | + +---------------+ + + Figure 1: Hypothetical MIF Interconnection + + The proposal also differs slightly from the language in [RFC1122] for + the Strong Host model. The proposal is that the packet will go to a + router that advertised a given prefix but that does not specify what + interface that might happen on. Hence, if the router is a multi- + interface (MIF) router and it is using a common prefix spanning two + or more LANs shared by the host (as in Figure 1), the host might use + either of those LANs, according to this proposal. The Strong Host + model is not stated in those terms, but in terms of the interface + used. A strong host would treat such an MIF router as two separate + routers when obeying the rules from RFC 1122 as they apply in the + Strong case: + + + +Baker & Carpenter Standards Track [Page 4] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + (A) A host MUST silently discard an incoming datagram whose + destination address does not correspond to the physical + interface through which it is received. + + (B) A host MUST restrict itself to sending (non-source-routed) IP + datagrams only through the physical interface that corresponds + to the IP source address of the datagrams. + + However, when comparing the presumptive route lookup mechanisms in + each model, this proposal is indeed most similar to the Strong Host + model, as is any source/destination routing paradigm. + + Strong: route (src IP addr, dest IP addr, TOS) -> gateway + + Weak: route (dest IP addr, TOS) -> gateway, interface + + In the hypothetical MIF model suggested in Figure 1, the address + fails to identify a single interface, but it does identify a single + gateway. + +1.2. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +2. Sending Context Expected by the Host + +2.1. Expectations the Host Has of the Network + + A host receives prefixes in a Router Advertisement [RFC4861], which + goes on to identify whether they are usable by Stateless Address + Autoconfiguration (SLAAC) [RFC4862] with any type of interface + identifier [RFC4941] [RFC7217]. When no prefixes are usable for + SLAAC, the Router Advertisement would normally signal the + availability of DHCPv6 [RFC3315] and the host would use it to + configure its addresses. In the latter case (or if both SLAAC and + DHCPv6 are used on the same link for some reason), the configured + addresses generally match one of the prefixes advertised in a Router + Advertisement that are supposed to be on-link for that link. + + The simplest multihomed network implementation in which a host makes + choices among routers might be a LAN with one or more hosts on it and + two or more routers, one for each upstream network, or a host that is + served by disjoint networks on separate interfaces. In such a + network, especially the latter, there is not necessarily a routing + protocol, and the two routers may not even know that the other is a + router as opposed to a host, or may be configured to ignore its + + + +Baker & Carpenter Standards Track [Page 5] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + presence. One might expect that the routers may or may not receive + each other's RAs and form an address in the other router's prefix + (which is not per [RFC4862], but is implemented by some stub router + implementations). However, all hosts in such a network might be + expected to create an address in each prefix so advertised. + + +---------+ +---------+ +---------+ +---------+ + | ISP | | ISP | | ISP | | ISP | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + | | | | + +----+----+ +----+----+ +----+----+ +----+----+ + | Router | | Router | | Router | | Router | + +----+----+ +----+----+ +----+----+ +----+----+ + | | | | + +------+------+ | +--------+ | + | +--+ Host +--+ + +----+----+ +--------+ + | Host | + +---------+ + Common LAN Case Disjoint LAN Case + (Multihomed Network) (Multihomed Host) + + Figure 2: Two Simple Networks + + If there is no routing protocol among those routers, there is no + mechanism by which packets can be deterministically forwarded between + the routers (as described in BCP 84 [RFC3704]) in order to avoid + filters. Even if there was routing, it would result in an indirect + route, rather than a direct route originating with the host; this is + not "wrong", but can be inefficient. Therefore, the host would do + well to select the appropriate router itself. + + Since the host derives fundamental default routing information from + the Router Advertisement, this implies that, in any network with + hosts using multiple prefixes, each prefix SHOULD be advertised via a + Prefix Information Option (PIO) [RFC4861] by one of the attached + routers, even if addresses are being assigned using DHCPv6. A router + that advertises a prefix indicates that it is able to appropriately + route packets with source addresses within that prefix, regardless of + the setting of the L and A flags in the PIO. + + In some circumstances, both L and A might be zero. If SLAAC is not + wanted (A=0) and there is no reason to announce an on-link prefix + (L=0), a PIO SHOULD be sent to inform hosts that they should use the + router in question as the first hop for packets with source addresses + in the PIO prefix. An example case is the MIF router in Figure 1, + which could send PIOs with A=L=0 for the common prefix. Although + + + +Baker & Carpenter Standards Track [Page 6] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + this does not violate the existing standard [RFC4861], such a PIO has + not previously been common, and it is possible that existing host + implementations simply ignore such a PIO or that existing router + implementations are not capable of sending such a PIO. Newer + implementations that support this mechanism should be updated + accordingly: + + o A host SHOULD NOT ignore a PIO simply because both L and A flags + are cleared (extending Section 6.3.4 of [RFC4861]). + + o A router SHOULD be able to send such a PIO (extending + Section 6.2.3 of [RFC4861]). + +2.2. Expectations of Multihomed Networks + + Networking equipment needs to support source/destination routing for + at least some of the routes in the Forwarding Information Base (FIB), + such as default egress routes differentiated by source prefix. + Installation of source/destination routes in the FIB might be + accomplished using static routes, Software-Defined Networking (SDN) + technologies, or dynamic routing protocols. + +3. Reasonable Expectations of the Host + +3.1. Interpreting Router Advertisements + + As described in [RFC4191] and [RFC4861], a Router Advertisement may + contain zero or more Prefix Information Options (PIOs) or zero or + more Route Information Options (RIOs). In their original intent, + these indicate general information to a host: "the router whose + address is found in the source address field of this packet is one of + your default routers", "you might create an address in this prefix", + or "this router would be a good place to send traffic directed to a + given destination prefix". In a multi-prefix network with multiple + exits, the host's characterization of each default router SHOULD + include the prefixes it has announced (extending Section 6.3.4 of + [RFC4861]). In other words, the PIO is reinterpreted to also imply + that the advertising router would be a reasonable first hop for any + packet using a source address in any advertised prefix, regardless of + Default Router Preference. + + + + + + + + + + + +Baker & Carpenter Standards Track [Page 7] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + +---------+ | + ( ISP A ) - + Bob-A +--+ +-----+ + +-------+ / +---------+ +--+ | + | | / | | | + | Alice +--/--( The Internet ) | Bob | + | | \ | | | + +-------+ \ +---------+ +--+ | + ( ISP B ) - + Bob-B +--+ +-----+ + +---------+ | + + Figure 3: PIOs, RIOs, and Default Routes + + The implications bear consideration. Imagine, Figure 3, that hosts + Alice and Bob are in communication. Bob's network consists of at + least Bob (the computer), two routers (Bob-A and Bob-B), and the + links between them; it may be much larger, for example, a campus or + corporate network. Bob's network is therefore multihomed, and Bob's + first-hop routers are Bob-A (to the upstream ISP A advertising prefix + PA) and Bob-B (to the upstream network B and advertising prefix PB). + We assume that Bob is not applying Rule 5.5 of [RFC6724]. If Bob is + responding to a message from Alice, his choice of source address is + forced to be the address Alice used as a destination (which we may + presume to have been in prefix PA). Hence, Bob either created or was + assigned an address in PA, and can only reasonably send traffic using + it to Bob-A as a first-hop router. If there are several routers in + Bob's network advertising the prefix PA (referred to as "Bob-Ax" + routers), then Bob should choose its first-hop router only from among + those routers. From among the multiple Bob-Ax routers, Bob should + choose the first-hop router based on the criteria specified in + Section 3 of [RFC4191]. If none of the Bob-Ax routers has advertised + an RA with a non-zero Router Lifetime or an RIO with a non-zero Route + Lifetime that includes Alice, but router Bob-B has, it is irrelevant. + Bob is using the address allocated in PA and courts a BCP 38 discard + if he doesn't send the packet to Bob-A. + + In the special case that Bob is initiating the conversation, an RIO + might, however, influence source address choice. Bob could + presumably use any address allocated to him, in this case, his + address in PA or PB. If Bob-B has advertised an RIO for Alice's + prefix and Bob-A has not, Bob MAY take that fact into account in + address selection -- choosing an address that would allow him to make + use of the RIO. + + + + + + + + + +Baker & Carpenter Standards Track [Page 8] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +3.2. Default Router Selection + + Default Router Selection (Section 6.3.6 of [RFC4861]) is extended as + follows: A host SHOULD select default routers for each prefix it is + assigned an address in. Routers that have advertised the prefix in + their Router Advertisement message SHOULD be preferred over routers + that do not advertise the prefix, regardless of Default Router + Preference. Note that this document does not change the way in which + default router preferences are communicated [RFC4191]. + + If no router has advertised the prefix in an RA, normal routing + metrics will apply. An example is a host connected to the Internet + via one router, and at the same time connected by a VPN to a private + domain that is also connected to the global Internet. + + As a result of this, when a host sends a packet using a source + address in one of those prefixes and has no history directing it + otherwise, it SHOULD send it to the indicated default router. In the + "simplest" network described in Section 2.1, that would get it to the + only router that is directly capable of getting it to the right ISP. + This will also apply in more complex networks, even when more than + one physical or virtual interface is involved. + + In more complex cases, wherein routers advertise RAs for multiple + prefixes whether or not they have direct or isolated upstream + connectivity, the host is dependent on the routing system already. + If the host gives the packet to a router advertising its source + prefix, it should be able to depend on the router to do the right + thing. + +3.3. Source Address Selection + + There is an interaction with Default Address Selection [RFC6724]. A + host following the recommendation in the previous section will store + information about which next hops advertised which prefixes. Rule + 5.5 of RFC 6724 states that the source address used to send to a + given destination address should, if possible, be chosen from a + prefix known to be advertised by the next-hop router for that + destination. Therefore, this selection rule SHOULD be implemented in + a host following the recommendation in the previous section. + +3.4. Redirects + + There is potential for adverse interaction with any off-link Redirect + (Redirect for a destination that is not on-link) message sent by a + router in accordance with Section 8 of [RFC4861]. Hosts SHOULD apply + off-link redirects only for the specific pair of source and + destination addresses concerned, so the host's Destination Cache + + + +Baker & Carpenter Standards Track [Page 9] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + might need to contain appropriate source-specific entries. This + extends the validity check specified in Section 8.1 of [RFC4861]. + +3.5. History + + Some modern hosts maintain history, in terms of what has previously + worked or not worked for a given address or prefix and in some cases + the effective window and Maximum Segment Size (MSS) values for TCP or + other protocols. This might include a next-hop address for use when + a packet is sent to the indicated address. + + When such a host makes a successful exchange with a remote + destination using a particular address pair, and the host has + previously received a PIO that matches the source address, then the + host SHOULD include the prefix in such history, whatever the setting + of the L and A flags in the PIO. On subsequent attempts to + communicate with that destination, if it has an address in that + prefix at that time, a host MAY use an address in the remembered + prefix for the session. + +4. Residual Issues + + Consider a network where routers on a link run a routing protocol and + are configured with the same information. Thus, on each link, all + routers advertise all prefixes on that link. The assumption that + packets will be forwarded to the appropriate egress by the local + routing system might cause at least one extra hop in the local + network (from the host to the wrong router, and from there to another + router on the same link). + + In a slightly more complex situation such as the disjoint LAN case of + Figure 2, for example, a home plus corporate home-office + configuration, the two upstream routers might be on different LANs + and therefore different subnets (e.g., the host is itself + multihomed). In that case, there is no way for the "wrong" router to + detect the existence of the "right" router, or to route to it. + + In such a case, it is particularly important that hosts take the + responsibility to memorize and select the best first hop as described + in Section 3. + +5. IANA Considerations + + This document does not request any registry actions. + + + + + + + +Baker & Carpenter Standards Track [Page 10] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +6. Security Considerations + + This document is intended to avoid connectivity issues in the + presence of BCP 38 ingress filters or stateful firewalls combined + with multihoming. It does not, in itself, create any new security or + privacy exposures. However, since the solution is designed to ensure + that routing occurs correctly in situations where it previously + failed, this might result in unexpected exposure of networks that + were previously unreachable. + + There might be a small privacy improvement: with the current + practice, a multihomed host that sends packets with the wrong address + to an upstream router or network discloses the prefix of one upstream + to the other upstream network. This practice reduces the probability + of that occurrence. + +7. References + +7.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + <http://www.rfc-editor.org/info/rfc2119>. + + [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 + (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, + December 1998, <http://www.rfc-editor.org/info/rfc2460>. + + [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and + More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, + November 2005, <http://www.rfc-editor.org/info/rfc4191>. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + DOI 10.17487/RFC4861, September 2007, + <http://www.rfc-editor.org/info/rfc4861>. + + [RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown, + "Default Address Selection for Internet Protocol Version 6 + (IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012, + <http://www.rfc-editor.org/info/rfc6724>. + + + + + + + + + +Baker & Carpenter Standards Track [Page 11] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + +7.2. Informative References + + [RFC1122] Braden, R., Ed., "Requirements for Internet Hosts - + Communication Layers", STD 3, RFC 1122, + DOI 10.17487/RFC1122, October 1989, + <http://www.rfc-editor.org/info/rfc1122>. + + [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: + Defeating Denial of Service Attacks which employ IP Source + Address Spoofing", BCP 38, RFC 2827, DOI 10.17487/RFC2827, + May 2000, <http://www.rfc-editor.org/info/rfc2827>. + + [RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, + C., and M. Carney, "Dynamic Host Configuration Protocol + for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July + 2003, <http://www.rfc-editor.org/info/rfc3315>. + + [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed + Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March + 2004, <http://www.rfc-editor.org/info/rfc3704>. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, + DOI 10.17487/RFC4862, September 2007, + <http://www.rfc-editor.org/info/rfc4862>. + + [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy + Extensions for Stateless Address Autoconfiguration in + IPv6", RFC 4941, DOI 10.17487/RFC4941, September 2007, + <http://www.rfc-editor.org/info/rfc4941>. + + [RFC6092] Woodyatt, J., Ed., "Recommended Simple Security + Capabilities in Customer Premises Equipment (CPE) for + Providing Residential IPv6 Internet Service", RFC 6092, + DOI 10.17487/RFC6092, January 2011, + <http://www.rfc-editor.org/info/rfc6092>. + + [RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic + Requirements for IPv6 Customer Edge Routers", RFC 7084, + DOI 10.17487/RFC7084, November 2013, + <http://www.rfc-editor.org/info/rfc7084>. + + [RFC7157] Troan, O., Ed., Miles, D., Matsushima, S., Okimoto, T., + and D. Wing, "IPv6 Multihoming without Network Address + Translation", RFC 7157, DOI 10.17487/RFC7157, March 2014, + <http://www.rfc-editor.org/info/rfc7157>. + + + + + +Baker & Carpenter Standards Track [Page 12] + +RFC 8028 Router Selection in a Multi-Prefix Network November 2016 + + + [RFC7217] Gont, F., "A Method for Generating Semantically Opaque + Interface Identifiers with IPv6 Stateless Address + Autoconfiguration (SLAAC)", RFC 7217, + DOI 10.17487/RFC7217, April 2014, + <http://www.rfc-editor.org/info/rfc7217>. + +Acknowledgements + + Comments were received from Jinmei Tatuya and Ole Troan, who have + suggested important text, plus Mikael Abrahamsson, Steven Barth, + Carlos Bernardos Cano, Chris Bowers, Zhen Cao, Juliusz Chroboczek, + Toerless Eckert, David Farmer, Bob Hinden, Ben Laurie, Dusan Mudric, + Tadahisa Okimoto, Pierre Pfister, Behcet Sarikaya, Mark Smith, and + James Woodyatt. + +Authors' Addresses + + Fred Baker + Santa Barbara, California 93117 + United States of America + + Email: FredBaker.IETF@gmail.com + + + Brian Carpenter + Department of Computer Science + University of Auckland + PB 92019 + Auckland 1142 + New Zealand + + Email: brian.e.carpenter@gmail.com + + + + + + + + + + + + + + + + + + + +Baker & Carpenter Standards Track [Page 13] + |