RFC 8028
First-Hop Router Selection by Hosts in a Multi-Prefix Network
First-Hop Router Selection by Hosts in a Multi-Prefix Network 💖
okay bestie, this is RFC 8028 🎀 It's a Standards Track doc from the IETF, published in November 2016. Fred Baker and Brian Carpenter (Univ. of Auckland) wrote it, and it's ISSN 2070-1721. It updates RFC 4861 (Neighbor Discovery), so anything it changes about RFC 4861 is part of the deal 🫶
Abstract ✨
So this doc is about what an IPv6 host should do when it has more than one prefix and more than one router to pick from 🦋 Each prefix comes from an upstream network that's assumed to do BCP 38 ingress filtering. Stateful firewalls that act like address-based filters are also in scope, which is giving "the network will check your return address" energy 👀
The source address gets picked first, and the first-hop router gets picked after that. The host might be multihomed with provider-allocated addresses, it has chosen a source address from a particular prefix, and only some of its neighboring routers are advertising that prefix in their Router Advertisement Prefix Information Options. In that situation, this doc says which router the host should send its packet to 💅
Status of This Memo 🌸
This is an Internet Standards Track document, meaning it's an actual Internet Standard in the making 🔥 It's a product of the Internet Engineering Task Force (IETF) and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check Section 2 of RFC 7841.
For the current status, errata, and feedback info, go to http://www.rfc-editor.org/info/rfc8028 🧚
Copyright Notice 💜
The copyright line reads Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. 📜
This doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as they're in effect on the publication date. Read those carefully, because they spell out your rights and restrictions for this doc 🙈 Code components pulled out of this doc must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, same as the Simplified BSD License says.
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 . . . . . . . . . . . . . . . . . . . . . . . 131. Introduction and Applicability 🌈
Okay, so this doc describes how an IPv6 [RFC2460] host should behave when its network has more than one prefix. Each of those prefixes is allocated by an upstream network that's assumed to do BCP 38 [RFC2827] ingress filtering, and the host gets a choice of routers 🦋
The network is expected to do some kind of egress routing, so packets going from a given ISP's prefix to a host outside the local network head out through that ISP. If a packet leaves through the wrong egress, the BCP 38 filter can toss it 😭 How egress routing works once the packet leaves the host is out of scope. The real question here is how the host talks to the network ✨
Various parts of this problem, plus possible solutions, are covered in "IPv6 Multihoming without Network Address Translation" [RFC7157] 📚
BCP 38 filtering by ISPs isn't the only case where this behavior matters. Implementations that combine [RFC6092] and [RFC7084] can also end up causing this kind of filtering 🙈 Another case is when the upstream connections include stateful firewalls. In that case, return packets in a stream get discarded if they don't come back through the firewall that made the state for the outgoing packets. Unicast reverse path forwarding (uRPF) [RFC3704] can cause similar discards 💀
This doc uses the word "filter" to cover all of these cases, just for simplicity. Either way, you can't assume the host knows whether an ingress filter, a stateful firewall, or some other filter is in place. So the only known consistent fix is to implement the features defined in this doc 🫶
Here's the thing: apart from making sure a message with a given source address goes to a first-hop router that appears to know about that prefix, this spec is consistent with [RFC4861] ✨ Still, implementers of Sections 6.2.3, 6.3.4, 6.3.6, and 8.1 of RFC 4861 should extend their implementations accordingly. This spec is also fully consistent with [RFC6724] and depends on support for its Rule 5.5 (see Section 3.3) 💅 Hosts that don't support these features may fail to communicate when filters like the ones above are in place 😬
1.1. Host Model 🦋
Okay, so one could argue that the proposal here, which is to send messages using a source address from a given prefix to the router that advertised that prefix in its Router Advertisement (RA), is a form of the Strong End System (ES, e.g., Host) model. That model is discussed in Section 3.3.4.2 of [RFC1122] 🧚
Quick recap of [RFC1122], which identifies two basic models. First, there's the "strong host" model, where the host is a set of hosts in one chassis. Each one uses a single address on a single interface and always both sends and receives on that interface. Second, there's the "weak host" model, where the host is one system with zero or more addresses on every interface, and it can use any interface for any communication. As noted there, neither model is totally satisfying 🙈
For example, a host with a link-local-only interface and a default route pointing to that interface will always send packets out that interface, but with a source address taken from some other interface. So it's a de facto weak host 👀 If the router upstream from a host like that implements BCP 38 Ingress Filtering [RFC2827], for example by doing uRPF on each interface, the router might block communication from weak hosts 🚫
+-----------------+
| |
| MIF Router +---/--- Other interfaces
| |
+---+---------+---+
| | Two interfaces with subnets
| | from a common prefix
--+-+-- --+-+--
| |
+--+---------+--+
| MIF Host |
+---------------+
Figure 1: Hypothetical MIF InterconnectionThis proposal also differs a little from what [RFC1122] says about the Strong Host model. The proposal is that the packet goes to a router that advertised a given prefix, but that router isn't tied to any particular interface 🌸 So if the router is a multi-interface (MIF) router and it uses a common prefix spanning two or more LANs shared by the host (like in Figure 1), the host might use either of those LANs under this proposal 💜 The Strong Host model isn't written in those terms. It's written in terms of the interface used. A strong host would treat a MIF router like that as two separate routers when following the rules from RFC 1122 as they apply to the Strong case:
- (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.
That said, if you compare the presumed route lookup mechanisms in each model, this proposal is actually most similar to the Strong Host model, same as any source/destination routing paradigm 🔥
Strong: route (src IP addr, dest IP addr, TOS) -> gateway
Weak: route (dest IP addr, TOS) -> gateway, interfaceIn the hypothetical MIF model from Figure 1, the address doesn't 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
Okay so, bestie, let's talk about what a host actually expects from the network 💅✨ A host gets its prefixes from a Router Advertisement [RFC4861]. That RA tells it whether those prefixes can be used for Stateless Address Autoconfiguration (SLAAC) [RFC4862] with any type of interface identifier [RFC4941] [RFC7217]. 🎀 If no prefixes are usable for SLAAC, the RA would normally say DHCPv6 [RFC3315] is available, and the host uses that to configure its addresses. In that second case (or if both SLAAC and DHCPv6 are on the same link for some reason 🙈), the configured addresses usually match one of the advertised prefixes that are supposed to be on-link for that link. Iconic, honestly 🦋
Now the multihomed stuff is where it gets spicy 🌶️ The simplest multihomed setup where a host has to pick between routers is a LAN with one or more hosts and two or more routers, one for each upstream network. The other version is a host served by disjoint networks on separate interfaces. In both, especially the second one, there's not necessarily a routing protocol 😭 The two routers might not even know the other one is a router and not just a host, or they might be set up to ignore it. You might expect the routers to receive each other's RAs and form an address in the other router's prefix. That isn't per [RFC4862], but some stub router implementations do it anyway 💀 Still, every host in a network like this might be expected to create an address in each prefix that's 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 NetworksIf there's no routing protocol among those routers, there's no mechanism for packets to be deterministically forwarded between them (as described in BCP 84 [RFC3704]) to avoid filters 🙅♀️ Even if there were routing, you'd get an indirect route instead of a direct one from the host. That's not "wrong," but it can be inefficient 😤 So, the host would do well to pick the right router itself 👑
Since the host gets its fundamental default routing info from the Router Advertisement, this means 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 is saying it can route packets with source addresses in that prefix, no matter what the L and A flags in the PIO are set to 💅
Sometimes both L and A might be zero. If SLAAC isn't wanted (A=0) and there's no reason to announce an on-link prefix (L=0), a PIO SHOULD be sent to tell hosts to use that router as the first hop for packets with source addresses in the PIO prefix 🧚 An example is the MIF router in Figure 1, which could send PIOs with A=L=0 for the common prefix. Honestly, this doesn't violate the existing standard [RFC4861], but a PIO like this hasn't been common before. It's possible existing hosts just ignore it, or existing routers can't send it at all 🙈 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), like default egress routes differentiated by source prefix 🌈 Source/destination routes can be installed in the FIB using static routes, Software-Defined Networking (SDN) technologies, or dynamic routing protocols. Pick your favourite, bestie 🍓
- 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). Originally, these were meant to give hosts general info: "the router whose address is 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 for 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. It's giving main character energy 🦋
+---------+ |
( ISP A ) - + Bob-A +--+ +-----+
+-------+ / +---------+ +--+ |
| | / | | |
| Alice +--/--( The Internet ) | Bob |
| | \ | | |
+-------+ \ +---------+ +--+ |
( ISP B ) - + Bob-B +--+ +-----+
+---------+ |
Figure 3: PIOs, RIOs, and Default RoutesThe implications are worth thinking about 🤔 Picture Figure 3, where Alice and Bob are talking. Bob's network has at least Bob (the computer), two routers (Bob-A and Bob-B), and the links between them. It could be way bigger, like a campus or corporate network 🏫 So Bob's network is multihomed, and his first-hop routers are Bob-A (going to upstream ISP A, advertising prefix PA) and Bob-B (going to upstream network B, advertising prefix PB). We assume Bob is not applying Rule 5.5 of [RFC6724]. If Bob is responding to a message from Alice, his source address is forced to be the address Alice used as a destination (which we may presume was in prefix PA). So Bob either created or was assigned an address in PA, and he can only reasonably send traffic with it to Bob-A as his first-hop router 💖 If several routers in Bob's network advertise prefix PA (called "Bob-Ax" routers), then Bob SHOULD choose his 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 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 Bob-B has, it doesn't matter. Bob is using the address allocated in PA, and he risks a BCP 38 discard if he doesn't send the packet to Bob-A 😬
In the special case where Bob starts the conversation, an RIO might influence source address choice. Bob could presumably use any address allocated to him, so in this case, his address in PA or PB. If Bob-B has advertised an RIO for Alice's prefix and Bob-A hasn't, Bob MAY take that into account in address selection, choosing an address that lets him use the RIO 🧠
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 has an address in. Routers that have advertised the prefix in their Router Advertisement message SHOULD be preferred over routers that don't advertise the prefix, regardless of Default Router Preference. Note that this document doesn't change how default router preferences are communicated [RFC4191] 🍓
If no router has advertised the prefix in an RA, normal routing metrics apply. For example, a host connected to the Internet through one router, and also connected by VPN to a private domain that's connected to the global Internet 🔐
So, when a host sends a packet using a source address in one of those prefixes and has no history telling it otherwise, it SHOULD send it to the indicated default router. In the "simplest" network from Section 2.1, that gets it to the only router directly able to reach the right ISP 🎯 This also applies in more complex networks, even when more than one physical or virtual interface is involved.
In more complex cases, where routers advertise RAs for multiple prefixes whether or not they have direct or isolated upstream connectivity, the host depends on the routing system already in place. If the host gives the packet to a router advertising its source prefix, it should be able to count on that router to do the right thing 🫶
3.3. Source Address Selection
There's 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 says 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. So this selection rule SHOULD be implemented in a host following the recommendation in the previous section 💅
3.4. Redirects
There's potential for adverse interaction with any off-link Redirect (a 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 might need to contain appropriate source-specific entries. This extends the validity check specified in Section 8.1 of [RFC4861] 🌸
3.5. History 🕰️
okay so some modern hosts keep a little diary 📓 of what has worked and what hasn't for a given address or prefix. ngl it's so smart. in some cases they even remember the effective window and Maximum Segment Size (MSS) values for TCP or other protocols 🧠. this might also include a next-hop address to use when a packet is sent to the indicated address 🦋.
here's the key bit 💅: when a host makes a successful exchange with a remote destination using a particular address pair, AND it has previously received a PIO that matches the source address, then the host SHOULD include the prefix in that history, no matter how the L and A flags are set in the PIO. later on, when it tries to reach that destination again and 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 🧩
picture a network where routers on a link run a routing protocol and are configured with the same information 🌐. so 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. so the host goes to the wrong router, and then that router passes it to another router on the same link. the detour is real 😭.
in a slightly more complex situation like 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 🙈.
so in a case like this, it's really important that hosts take the responsibility to memorize and select the best first hop, as described in Section 3 👑.
5. IANA Considerations 📋
quick one: this document does not request any registry actions 🌸.
6. Security Considerations 🔐
okay this section is serious, bestie. 💀
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 make routing work 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 happening.
7. References 📚
7.1. Normative References
these are the must-read ones, the foundation of the whole vibe 🧱:
[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>.7.2. Informative References
these ones are extra context, super useful for going deeper 🔍✨:
[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>.
[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 🫶
big thank you 💖 to everyone who helped out! comments were received from Jinmei Tatuya and Ole Troan, who 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📦 where this page comes from
- ietf: rfc8028 2016-11
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms