RFC 3484

Default Address Selection for Internet Protocol version 6 (IPv6)

📅 published March 2003, from ietf

Default Address Selection for Internet Protocol version 6 (IPv6) 🦋

okay bestie, this is RFC 3484 📜 It's from the Network Working Group, written by R. Draves at Microsoft Research, dated February 2003, and it's on the Standards Track 👑 That means it's a real protocol spec, not just vibes.

Status of this Memo

This doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions to make it better 🫶 For where this protocol sits in standardization, check the current edition of "Internet Official Protocol Standards" (STD 1). Distribution of this memo is unlimited ✨

Copyright Notice

Abstract

okay so this doc describes two algorithms 🧚 one for picking a source address and one for picking a destination address. They set the default behavior for every Internet Protocol version 6 (IPv6) implementation. They don't overrule choices that applications or upper-layer protocols already made, and they don't block anyone from building fancier address selection later 💅 The two algorithms share a common context, which includes an optional way for admins to set policy that can override the default behavior.

In dual stack implementations, the destination address selection algorithm can look at both IPv4 and IPv6 addresses. Depending on which source addresses are available, it might prefer IPv6 over IPv4, or the other way around 🌈 it's giving flexibility.

All IPv6 nodes, including both hosts and routers, must implement default address selection as defined in this specification. no cap, it's not optional for them 😭

1.    Introduction................................................2
      1.1.  Conventions Used in This Document.....................4
2.    Context in Which the Algorithms Operate.....................4
      2.1.  Policy Table..........................................5
      2.2.  Common Prefix Length..................................6
3.    Address Properties..........................................6
      3.1.  Scope Comparisons.....................................7
      3.2.  IPv4 Addresses and IPv4-Mapped Addresses..............7
      3.3.  Other IPv6 Addresses with Embedded IPv4 Addresses.....8
      3.4.  IPv6 Loopback Address and Other Format Prefixes.......8
      3.5.  Mobility Addresses....................................8
4.    Candidate Source Addresses..................................8
5.    Source Address Selection...................................10
6.    Destination Address Selection..............................12
7.    Interactions with Routing..................................14
8.    Implementation Considerations..............................15
9.    Security Considerations....................................15
10.   Examples...................................................16
      10.1. Default Source Address Selection.....................16
      10.2. Default Destination Address Selection................17
      10.3. Configuring Preference for IPv6 or IPv4..............18
      10.4. Configuring Preference for Scoped Addresses..........19
      10.5. Configuring a Multi-Homed Site.......................19
Normative References.............................................21
Informative References...........................................22
Acknowledgments..................................................23
Author's Address.................................................23
Full Copyright Statement.........................................24

1. Introduction ✨

okay so the IPv6 addressing architecture [1] lets you assign multiple unicast addresses to an interface 🦋 These addresses can have different reachability scopes: link-local, site-local, or global. They can also be "preferred" or "deprecated" [2]. Privacy concerns gave us "public addresses" and "temporary addresses" [3], and the mobility architecture brought in "home addresses" and "care-of addresses" [8]. Multi-homing adds even more addresses per node 🌸 For example, a node might have several interfaces, some of them tunnels or virtual interfaces, or a site might have several ISP attachments, each with its own global prefix.

So IPv6 implementations are going to be dealing with a bunch of possible source and destination addresses whenever they start talking to someone 🙈 It's really useful to have default algorithms that every implementation shares for picking source and destination addresses. Then developers and admins can actually reason about how their systems will behave and predict it.

Dual or hybrid stack implementations, which support both IPv6 and IPv4, also need to choose between the two a lot when they start communicating. Like, when DNS name resolution gives back both IPv6 and IPv4 addresses, and the stack has both kinds of source addresses available. In that situation, always preferring IPv6 or always preferring IPv4 can give you bad results 😭 Here's an example: say a name resolves to a global IPv6 address and a global IPv4 address. If the node has a global IPv6 address and a 169.254/16 auto-configured IPv4 address [9], then IPv6 is the best choice. But if the node has only a link-local IPv6 address and a global IPv4 address, then IPv4 is the best choice 💜 The destination address selection algorithm handles this with one unified procedure that picks among both IPv6 and IPv4 addresses.

These algorithms are written as a set of rules that define a partial ordering on the addresses available for use 🧚 For source address selection, a node usually has several addresses on its interfaces, and the source address ordering rules in section 5 decide which one is the "best" to use. For destination address selection, DNS might return a set of addresses for one name. The application then has to decide which one to use first, and what order to try the rest in if the first one isn't reachable. Applying the destination address ordering rules in section 6 to the set DNS returned gives you a recommended ordering 🍓

This document specifies source and destination address selection separately, but it uses a common context so that, together, the two algorithms give useful results 💅 They try to pick source and destination addresses with the right scope and configuration status (preferred or deprecated, in the RFC 2462 sense). This document also suggests a preferred method, longest matching prefix, for choosing among addresses that are otherwise equivalent when there isn't better information 🌈

It also specifies policy hooks so an administrator can override the default behavior 🎀 With these hooks, an admin can say which source prefix to use for a given destination prefix, or prefer destination addresses with one prefix over addresses with another. This gives admins flexibility for some multi-homing and transition scenarios, but, as the doc says itself, they are certainly not a panacea 😂

The selection rules in this document MUST NOT be construed to override an application or upper-layer's explicit choice of a legal destination or source address. Hard boundary, bestie 🔥

1.1. Conventions Used in This Document 🎀

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 BCP 14, RFC 2119 [4]. These are the official requirement-level words, so when you see them in caps, they mean something specific 🧚

2. Context in Which the Algorithms Operate 💅

okay so our context for address selection comes from the most common implementation architecture 🦋 That architecture separates choosing a destination address from choosing a source address. Because of that, we have two separate algorithms. They're designed to work well together, and they share a mechanism for administrative policy override 💖

In this architecture, applications use APIs [10] like getaddrinfo(), which give the application a list of addresses. That list might include both IPv6 and IPv4 addresses (sometimes represented as IPv4-mapped addresses). The application then passes a destination address to the network stack with connect() or sendto(). Usually the application tries the first address and loops through the list until it finds one that works 🌸 Either way, the network layer never has to pick a destination from several alternatives. The application might also specify a source address with bind(), but often the source is left unspecified. So the network layer often ends up choosing a source address from several options 🙈

As a result, we intend for getaddrinfo() implementations to use the destination address selection algorithm in this document to sort the list of IPv6 and IPv4 addresses they return ✨ Separately, the IPv6 network layer will use the source address selection algorithm whenever an application or upper-layer hasn't specified a source address. Applying this spec to source address selection in an IPv4 network layer might be possible, but this doc doesn't explore that further 🧚

Well-behaved applications SHOULD iterate through the list of addresses returned from getaddrinfo() until they find a working address. That's the vibe 💅

The algorithms weigh several criteria when making decisions 🌈 Put together, the effect is this: they prefer destination and source address pairs where both addresses have equal scope or type. For the destination address, they prefer smaller scopes over larger ones. They prefer non-deprecated source addresses, avoid transitional addresses when native addresses are available, and, all else being equal, prefer address pairs with the longest possible common prefix 💜 For source address selection, public addresses [3] are preferred over temporary addresses. In mobile situations [8], home addresses are preferred over care-of addresses. And if an address is both a home address and a care-of address (meaning the mobile node is "at home" for that address), then that home/care-of address is preferred over addresses that are only a home address or only a care-of address 🏠

This specification optionally allows administrators to configure policy that can override the default behavior of the algorithms 🎀 The policy override takes the form of a configurable table. The table specifies precedence values and preferred source prefixes for destination prefixes 🦋 If an implementation isn't configurable, or if it hasn't been configured, then the default policy table specified in this document SHOULD be used. Default vibes, unless someone says otherwise 🫶

Ok that's the foundations down, the good stuff comes next 💜

2.1. Policy Table

okay so the policy table is basically a longest-matching-prefix lookup table, just like a routing table 🗺️💖. Give it an address A and you get back two values: a precedence value Precedence(A) and a classification or label Label(A) ✨.

Precedence is what we use to sort destination addresses. If Precedence(A) > Precedence(B), then address A has higher precedence than address B, which means our algorithm will prefer to sort destination address A before destination address B 👑.

The label is for policies that like pairing a particular source address prefix with a particular destination address prefix 🫶. The algorithms prefer to use a source address S with a destination address D if Label(S) = Label(D).

IPv6 implementations SHOULD support configurable address selection via a mechanism at least as powerful as the policy tables defined here. Note that, as of writing, there's only limited experience with policies that select from a set of possible IPv6 addresses 🙈. As more experience is gained, the recommended default policies may change, so it's super important that implementations give you a way to change the default policies. Sections 10.3 and 10.4 show examples of the kinds of changes that might be needed 🧚.

If an implementation is not configurable or hasn't been configured, then it SHOULD operate according to the algorithms specified here, together with the following default policy table:

      Prefix        Precedence Label
      ::1/128               50     0
      ::/0                  40     1
      2002::/16             30     2
      ::/96                 20     3
      ::ffff:0:0/96         10     4

One effect of the default policy table is that it prefers native source addresses with native destination addresses, 6to4 [5] source addresses with 6to4 destination addresses, and v4-compatible [1] source addresses with v4-compatible destination addresses 🌸. Another effect is that it prefers communication using IPv6 addresses over communication using IPv4 addresses, as long as matching source addresses are available 💅.

Policy table entries for scoped address prefixes MAY be qualified with an optional zone index. If they are, a prefix table entry only matches an address during a lookup if the zone index also matches the address's zone index 🦋.

2.2. Common Prefix Length

We define the common prefix length CommonPrefixLen(A, B) of two addresses A and B as the length of the longest prefix (looking at the most significant, or leftmost, bits) that the two addresses have in common. It ranges from 0 to 128 🎀.

3. Address Properties

In the rules given in later sections, addresses of different types (for example IPv4, IPv6, multicast and unicast) get compared against each other. Some of these address types have properties that aren't directly comparable. For example, IPv6 unicast addresses can be "preferred" or "deprecated" [2], while IPv4 addresses have no such notion 🤷‍♀️. So that these addresses can be compared using the ordering rules (for example, to use "preferred" addresses in preference to "deprecated" addresses), the following mappings are defined 💜.

3.1. Scope Comparisons

Multicast destination addresses have a 4-bit scope field that controls how far the multicast packet propagates. The IPv6 addressing architecture defines scope field values for interface-local (0x1), link-local (0x2), subnet-local (0x3), admin-local (0x4), site-local (0x5), organization-local (0x8), and global (0xE) scopes [11] 🌈.

Using the source address selection algorithm with multicast destination addresses means comparing a unicast address scope with a multicast address scope. So we map unicast link-local to multicast link-local, unicast site-local to multicast site-local, and unicast global scope to multicast global scope 🔥. For example, unicast site-local is equal to multicast site-local, which is smaller than multicast organization-local, which is smaller than unicast global, which is equal to multicast global ✨.

We write Scope(A) to mean the scope of address A. For example, if A is a link-local unicast address and B is a site-local multicast address, then Scope(A) < Scope(B) 🧠.

This mapping implicitly mixes up unicast site boundaries and multicast site boundaries [11], so keep that in mind 👀.

3.2. IPv4 Addresses and IPv4-Mapped Addresses

The destination address selection algorithm works on both IPv6 and IPv4 addresses. For this purpose, IPv4 addresses should be represented as IPv4-mapped addresses [1]. For example, to look up the precedence or other attributes of an IPv4 address in the policy table, you look up the corresponding IPv4-mapped IPv6 address 🦄.

IPv4 addresses get assigned scopes like this 💖. IPv4 auto-configuration addresses [9], which have the prefix 169.254/16, are assigned link-local scope. IPv4 private addresses [12], which have the prefixes 10/8, 172.16/12, and 192.168/16, are assigned site-local scope. IPv4 loopback addresses [12, section 4.2.2.11], which have the prefix 127/8, are assigned link-local scope (the same way the IPv6 loopback address is treated [11, section 4]). Other IPv4 addresses are assigned global scope 🌍.

IPv4 addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status 🎀.

3.3. Other IPv6 Addresses with Embedded IPv4 Addresses

IPv4-compatible addresses [1], IPv4-mapped addresses [1], IPv4-translatable addresses [6], and 6to4 addresses [5] all contain an embedded IPv4 address 🧚. For the purposes of this document, these addresses should be treated as having global scope 🌸.

IPv4-compatible, IPv4-mapped, and IPv4-translatable addresses should be treated as having "preferred" (in the RFC 2462 sense) configuration status 💅.

3.4. IPv6 Loopback Address and Other Format Prefixes

The loopback address should be treated as having link-local scope [11, section 4] and "preferred" (in the RFC 2462 sense) configuration status 🔁.

NSAP addresses and other addresses with as-yet-undefined format prefixes should be treated as having global scope and "preferred" (in the RFC 2462) configuration status. Later standards may supersede this treatment 🔮.

3.5. Mobility Addresses

Some nodes may support mobility using the concepts of a home address and a care-of address (for example, see [8]) 🧳. Conceptually, a home address is an IP address assigned to a mobile node and used as that node's permanent address. A care-of address is an IP address associated with a mobile node while it's visiting a foreign link 🏠. When a mobile node is on its home link, it may have an address that is both a home address and a care-of address 💜.

For the purposes of this document, it's enough to know whether or not one's own addresses are designated as home addresses or care-of addresses. Whether or not an address should be designated a home address or care-of address is outside the scope of this document 🫶.

4. Candidate Source Addresses

The source address selection algorithm uses the concept of a "candidate set" of potential source addresses for a given destination address 🎯. The candidate set is the set of all addresses that could be used as a source address, and the source address selection algorithm will pick one address out of that set. We write CandidateSource(A) to denote the candidate set for address A ✨.

It is RECOMMENDED that the candidate source addresses be the set of unicast addresses assigned to the interface that will be used to send to the destination (the "outgoing" interface). On routers, the candidate set MAY include unicast addresses assigned to any interface that forwards packets, subject to the restrictions described below 🚦.

Discussion: The Neighbor Discovery Redirect mechanism [14] requires that routers verify the source address of a packet identifies a neighbor before generating a Redirect, so it's advantageous for hosts to choose source addresses assigned to the outgoing interface 💁‍♀️. Implementations that want to support the use of global source addresses assigned to a loopback interface should behave as if the loopback interface originates and forwards the packet 🔄.

In some cases the destination address may be qualified with a zone index or other information that constrains the candidate set 🧩.

For multicast and link-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same link as the outgoing interface 🔗.

Discussion: The restriction for multicast destination addresses is necessary because currently deployed multicast forwarding algorithms use Reverse Path Forwarding (RPF) checks 🛡️.

For site-local destination addresses, the set of candidate source addresses MUST only include addresses assigned to interfaces belonging to the same site as the outgoing interface 🏡.

In any case, anycast addresses, multicast addresses, and the unspecified address MUST NOT be included in a candidate set 🚫.

If an application or upper-layer specifies a source address that is not in the candidate set for the destination, then the network layer MUST treat this as an error 💀. The specified source address may influence the candidate set by affecting the choice of outgoing interface. If the application or upper-layer specifies a source address that is in the candidate set for the destination, then the network layer MUST respect that choice 🫶. If the application or upper-layer does not specify a source address, then the network layer uses the source address selection algorithm specified in the next section 🧚‍♀️.

On IPv6-only nodes that support SIIT [6, especially section 5], if the destination address is an IPv4-mapped address, then the candidate set MUST contain only IPv4-translatable addresses. If the destination address is not an IPv4-mapped address, then the candidate set MUST NOT contain IPv4-translatable addresses 🎀.

5. Source Address Selection ✨

okay so the source address selection algorithm gives you back one single source address to use for a given destination address 💅 it only works for IPv6 destinations though, IPv4 is not its problem 🙈

the algorithm is written as a bunch of pairwise comparison rules that (for some destination D) put the addresses in the candidate set CandidateSource(D) into a "greater than" order. whichever address ends up at the front of the list when everything's done is the winner 👑

conceptually it's sorting the candidate set, bestie, but since you only need ONE answer, you don't have to actually sort anything. you just need to find the "maximum" that ends up at the front 🧚

so there are eight pairwise rules, and each one can say "greater than," "less than," or "equal to" for two source addresses. if a rule ties, the remaining rules get applied in order, but only to the addresses that tied 🫶 and if a rule has a clear winner (or a group of winners when there's a tie), the losers get tossed and the later rules only look at the rest 🗑️ if all eight rules still can't pick one address, some unspecified tie-breaker should be used. no cap, that's the vibe.

when we compare SA and SB from the candidate set, "prefer SA" means SA is "greater than" SB, and "prefer SB" means SA is "less than" SB. simple 🌸

Rule 1: Prefer same address. If SA = D, then prefer SA. Similarly, if SB = D, then prefer SB. 💖

Rule 2: Prefer appropriate scope. If Scope(SA) < Scope(SB): if Scope(SA) < Scope(D), then prefer SB, and otherwise prefer SA. Similarly, if Scope(SB) < Scope(SA): if Scope(SB) < Scope(D), then prefer SA, and otherwise prefer SB. this one is so important it's giving main character energy 👑

Rule 3: Avoid deprecated addresses. SA and SB have the same scope. if one of them is "preferred" and the other is "deprecated" (in the RFC 2462 sense), then prefer the "preferred" one. 🦋

Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. 🏠

Implementations should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). the mechanism should only affect the selection rules for the invoking application. so it's app-specific, not a global thing 🎀

Rule 5: Prefer outgoing interface. If SA is assigned to the interface that will be used to send to D and SB is assigned to a different interface, then prefer SA. Similarly, if SB is assigned to the interface that will be used to send to D and SA is assigned to a different interface, then prefer SB. ✨

Rule 6: Prefer matching label. If Label(SA) = Label(D) and Label(SB) <> Label(D), then prefer SA. Similarly, if Label(SB) = Label(D) and Label(SA) <> Label(D), then prefer SB. the labels have to match, periodt 🫶

Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. 🕵️‍♀️

Implementations MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer temporary addresses over public addresses (e.g., via appropriate API extensions). the mechanism should only affect the selection rules for the invoking application. this rule exists so apps don't break because temporary addresses have a pretty short lifetime, or because reverse lookups on a temporary address might fail or hand back a randomized name 😭 implementations where privacy outweighs those app compatibility worries MAY reverse the sense of this rule and by default prefer temporary addresses over public addresses. privacy girlies, this is for you 🌈

Rule 8: Use longest matching prefix. If CommonPrefixLen(SA, D) > CommonPrefixLen(SB, D), then prefer SA. Similarly, if CommonPrefixLen(SB, D) > CommonPrefixLen(SA, D), then prefer SB. 🍓

Rule 8 may be superseded if the implementation has other means of choosing among source addresses. for example, if the implementation somehow knows which source address will give the "best" communications performance. 🔥

Rule 2 (prefer appropriate scope) MUST be implemented and given high priority because it can affect interoperability. this one is non-negotiable, bestie 💀

6. Destination Address Selection ✨

the destination address selection algorithm takes a list of destination addresses and sorts them into a brand new list 💖 it's written as pairwise comparisons of DA and DB, where DA shows up before DB in the original list.

the algorithm sorts IPv6 and IPv4 addresses together. to look up an IPv4 address's attributes in the policy table, you represent it as an IPv4-mapped address 🦋

we write Source(D) for the source address that got selected for destination D. for IPv6, the previous section is where the source address selection algorithm lives. source address selection for IPv4 addresses is not specified in this document, so it's not our tea 🙈

we say Source(D) is undefined if there's no source address available for destination D. for IPv6, that only happens when CandidateSource(D) is the empty set. 🕳️

the pairwise comparison of destinations has ten rules, and they should be applied in order. if a rule gives you a result, the remaining rules are not relevant and should be ignored. later rules act as tie-breakers for earlier ones. for a longer explanation of how tie-breaker rules can sort a list, check out the previous section 📚

Rule 1: Avoid unusable destinations. If DB is known to be unreachable or if Source(DB) is undefined, then prefer DA. Similarly, if DA is known to be unreachable or if Source(DA) is undefined, then prefer DB. 🚫

💭 Discussion: an implementation can know a destination is unreachable in a few different ways. for example, the destination might be reached through a network interface that's currently unplugged. or the implementation might hang onto information from Neighbor Unreachability Detection [14] for some period of time. either way, what counts as unreachable for this rule is up to the implementation 🌸

Rule 2: Prefer matching scope. If Scope(DA) = Scope(Source(DA)) and Scope(DB) <> Scope(Source(DB)), then prefer DA. Similarly, if Scope(DA) <> Scope(Source(DA)) and Scope(DB) = Scope(Source(DB)), then prefer DB. ✨

Rule 3: Avoid deprecated addresses. If Source(DA) is deprecated and Source(DB) is not, then prefer DB. Similarly, if Source(DA) is not deprecated and Source(DB) is deprecated, then prefer DA. 🦋

Rule 4: Prefer home addresses. If Source(DA) is simultaneously a home address and care-of address and Source(DB) is not, then prefer DA. Similarly, if Source(DB) is simultaneously a home address and care-of address and Source(DA) is not, then prefer DB.

If Source(DA) is just a home address and Source(DB) is just a care-of address, then prefer DA. Similarly, if Source(DA) is just a care-of address and Source(DB) is just a home address, then prefer DB. 🏠

Rule 5: Prefer matching label. If Label(Source(DA)) = Label(DA) and Label(Source(DB)) <> Label(DB), then prefer DA. Similarly, if Label(Source(DA)) <> Label(DA) and Label(Source(DB)) = Label(DB), then prefer DB. 🫶

Rule 6: Prefer higher precedence. If Precedence(DA) > Precedence(DB), then prefer DA. Similarly, if Precedence(DA) < Precedence(DB), then prefer DB. 👑

Rule 7: Prefer native transport. If DA is reached via an encapsulating transition mechanism (e.g., IPv6 in IPv4) and DB is not, then prefer DB. Similarly, if DB is reached via encapsulation and DA is not, then prefer DA. 🌈

💭 Discussion: 6-over-4 [15], ISATAP [16], and configured tunnels [17] are examples of encapsulating transition mechanisms. their destination addresses don't have a specific prefix, so they can't get a lower precedence in the policy table. an implementation MAY generalize this rule by using a concept of interface preference, giving virtual interfaces (like the IPv6-in-IPv4 encapsulating interfaces) a lower preference than native interfaces (like ethernet interfaces). ✨

Rule 8: Prefer smaller scope. If Scope(DA) < Scope(DB), then prefer DA. Similarly, if Scope(DA) > Scope(DB), then prefer DB. 🔍

Rule 9: Use longest matching prefix. When DA and DB belong to the same address family (both are IPv6 or both are IPv4): if CommonPrefixLen(DA, Source(DA)) > CommonPrefixLen(DB, Source(DB)), then prefer DA. Similarly, if CommonPrefixLen(DA, Source(DA)) < CommonPrefixLen(DB, Source(DB)), then prefer DB. 🍓

Rule 10: Otherwise, leave the order unchanged. If DA preceded DB in the original list, prefer DA. Otherwise prefer DB. 🧚

Rules 9 and 10 may be superseded if the implementation has other means of sorting destination addresses. for example, if the implementation somehow knows which destination addresses will give the "best" communications performance. 💜

7. Interactions with Routing ✨

this spec for source address selection assumes that routing happens before source address selection. more precisely, it assumes you've already picked an outgoing interface on a node with multiple interfaces 🗺️ however, implementations may use source address considerations as a tiebreaker when choosing among routes that are otherwise equivalent.

for example, say a node has interfaces on two different links, and both links have a working default router. both interfaces have preferred (in the RFC 2462 sense) global addresses. when sending to a global destination address, if there's no routing reason to pick one interface over the other, an implementation may choose the outgoing interface that lets it use the source address sharing a longer common prefix with the destination 💖

implementations may also use the choice of router to influence the choice of source address. for example, say a host is on a link with two routers. one router advertises global prefix A and the other advertises global prefix B. then when sending via the first router, the host may prefer source addresses with prefix A, and when sending via the second router, it may prefer source addresses with prefix B. routing and addressing really do have a whole group chat going on 🫶🦋

8. Implementation Considerations ✨

okay so destination address selection needs to know about the source addresses that could be used, which is a lot to ask 🫠 There are a couple of ways to pull it off.

One option is for getaddrinfo() to hand the list of destination addresses down to the network layer, let the network layer sort them with full, up-to-date knowledge of the available source addresses, and then get the sorted list back. This is simple and gives the best results, but it adds the overhead of another system call. To cut that down, you can cache the sorted list in the resolver, so later calls for the same name don't have to sort it all over again 💅

Another option is to call down to the network layer just to get source address information, then sort the destination list right inside getaddrinfo(). To keep this one fast, you can cache the source address information so the cost of fetching it is spread across many calls to getaddrinfo() ✨ The catch is that the implementation might not know which outgoing interface goes with each destination, so it MAY use a looser definition of the candidate set while ordering destinations. 🦋

Either way, if you're using cached information that could be stale, or the cached ordering of destination addresses could be stale, you should make sure the ordering handed back to the application is no more than one second out of date. For example, an implementation could make a system call to check whether any routing table entries or source address assignments that affect these algorithms have changed. Another trick is an invalidation counter that goes up whenever any underlying state changes. You store the current counter value alongside the derived state, then compare it with the current value later on, and that tells you whether the derived state might be stale 🧚

9. Security Considerations 🔒

This document has no direct impact on Internet infrastructure security.

BUT, and this part is important bestie, most source address selection algorithms have a privacy concern, and that includes the one in this document 🙈 An unfriendly node can work out which addresses belong to the same target node by probing it with request packets that force the target host to pick its source address for the replies. This can happen because the request packets go to an anycast or multicast address, or because the upper-layer protocol being used doesn't specify a particular source address for its reply packets. By using different addresses for itself, the unfriendly node can make the target reveal its own addresses. Not a vibe ☠️

10. Examples 🎀

This section has a bunch of examples, starting with the default behavior and then showing how useful it is to configure the policy table. These examples are only for illustration, so they should not be construed as normative. Think of them as cute little snapshots, not rules 💖

10.1. Default Source Address Selection

Here's how the source address selection rules behave together with the default policy table 👑

Destination: 2001::1
Candidate Source Addresses: 3ffe::1 or fe80::1
Result: 3ffe::1 (prefer appropriate scope)

Destination: 2001::1
Candidate Source Addresses: fe80::1 or fec0::1
Result: fec0::1 (prefer appropriate scope)

Destination: fec0::1
Candidate Source Addresses: fe80::1 or 2001::1
Result: 2001::1 (prefer appropriate scope)

Destination: ff05::1
Candidate Source Addresses: fe80::1 or fec0::1 or 2001::1
Result: fec0::1 (prefer appropriate scope)

Destination: 2001::1
Candidate Source Addresses: 2001::1 (deprecated) or 2002::1
Result: 2001::1 (prefer same address)

Destination: fec0::1
Candidate Source Addresses: fec0::2 (deprecated) or 2001::1
Result: fec0::2 (prefer appropriate scope)

Destination: 2001::1
Candidate Source Addresses: 2001::2 or 3ffe::2
Result: 2001::2 (longest-matching-prefix)
Destination: 2001::1
Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::2
(home address)
Result: 3ffe::2 (prefer home address)

Destination: 2002:836b:2179::1
Candidate Source Addresses: 2002:836b:2179::d5e3:7953:13eb:22e8
(temporary) or 2001::2
Result: 2002:836b:2179::d5e3:7953:13eb:22e8 (prefer matching label)

Destination: 2001::d5e3:0:0:1
Candidate Source Addresses: 2001::2 or 2001::d5e3:7953:13eb:22e8
(temporary)
Result: 2001::2 (prefer public address)

10.2. Default Destination Address Selection

Now the destination address selection rules, working together with the default policy table and the source address selection rules 🌸

Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)

Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Result: 131.107.65.121 (src 131.107.65.117) then 2001::1 (src
fe80::1) (prefer matching scope)

Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
Result: 2001::1 (src 2001::2) then 10.1.2.3 (src 10.1.2.4) (prefer
higher precedence)

Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
Result: fe80::1 (src fe80::2) then fec0::1 (src fec0::2) then
2001::1 (src 2001::2) (prefer smaller scope)

Candidate Source Addresses: 2001::2 (care-of address) or 3ffe::1
(home address) or fec0::2 (care-of address) or fe80::2 (care-of
address)
Destination Address List: 2001::1 or fec0::1
Result: 2001:1 (src 3ffe::1) then fec0::1 (src fec0::2) (prefer home
address)
Candidate Source Addresses: 2001::2 or fec0::2 (deprecated) or
fe80::2
Destination Address List: 2001::1 or fec0::1
Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) (avoid
deprecated addresses)

Candidate Source Addresses: 2001::2 or 3f44::2 or fe80::2
Destination Address List: 2001::1 or 3ffe::1
Result: 2001::1 (src 2001::2) then 3ffe::1 (src 3f44::2) (longest
matching prefix)

Candidate Source Addresses: 2002:836b:4179::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2002:836b:4179::1 (src 2002:836b:4179::2) then 2001::1 (src
2002:836b:4179::2) (prefer matching label)

Candidate Source Addresses: 2002:836b:4179::2 or 2001::2 or fe80::2
Destination Address List: 2002:836b:4179::1 or 2001::1
Result: 2001::1 (src 2001::2) then 2002:836b:4179::1 (src
2002:836b:4179::2) (prefer higher precedence)

10.3. Configuring Preference for IPv6 or IPv4

The default policy table gives IPv6 addresses higher precedence than IPv4 addresses 💜 So when the two are equally suitable, applications will go with IPv6. An administrator who wants IPv4 to win can give the ::ffff:0.0.0.0/96 prefix a higher precedence, like this:

   Prefix        Precedence Label
   ::1/128               50     0
   ::/0                  40     1
   2002::/16             30     2
   ::/96                 20     3
   ::ffff:0:0/96        100     4

With that change to the default policy table, you get this behavior:

Candidate Source Addresses: 2001::2 or fe80::1 or 169.254.13.78
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 2001::1 (src 2001::2) then 131.107.65.121 (src
169.254.13.78) (prefer matching scope)

Candidate Source Addresses: fe80::1 or 131.107.65.117
Destination Address List: 2001::1 or 131.107.65.121
Unchanged Result: 131.107.65.121 (src 131.107.65.117) then 2001::1
(src fe80::1) (prefer matching scope)

Candidate Source Addresses: 2001::2 or fe80::1 or 10.1.2.4
Destination Address List: 2001::1 or 10.1.2.3
New Result: 10.1.2.3 (src 10.1.2.4) then 2001::1 (src 2001::2)
(prefer higher precedence)

10.4. Configuring Preference for Scoped Addresses

The destination address selection rules like smaller scopes 🦋 For example, a site-local destination gets sorted ahead of a global scope destination when the two are otherwise equally suitable. But an administrator can flip that around, so global destinations sort before site-local ones, and site-local ones sort before link-local ones, by changing the policy table to this:

   Prefix        Precedence Label
   ::1/128               50     0
   ::/0                  40     1
   fec0::/10             37     1
   fe80::/10             33     1
   2002::/16             30     2
   ::/96                 20     3
   ::ffff:0:0/96         10     4

With this change to the default policy table, the behavior looks like this:

Candidate Source Addresses: 2001::2 or fec0::2 or fe80::2
Destination Address List: 2001::1 or fec0::1 or fe80::1
New Result: 2001::1 (src 2001::2) then fec0::1 (src fec0::2) then
fe80::1 (src fe80::2) (prefer higher precedence)

Candidate Source Addresses: 2001::2 (deprecated) or fec0::2 or
fe80::2
Destination Address List: 2001::1 or fec0::1
Unchanged Result: fec0::1 (src fec0::2) then 2001::1 (src 2001::2)
(avoid deprecated addresses)

10.5. Configuring a Multi-Homed Site ✨

okay so picture site A and site B 🫶 They have a business-critical relationship, so they both paid for a special high-performance ISP. That's on top of the normal internet connection each site already has with a different ISP. The high-performance one is pricey 💸, so they only want it used for their business-critical traffic with each other.

Each site has two global prefixes, one from the high-performance ISP and one from their normal ISP. Site A has 2001:aaaa:aaaa::/48 from the high-performance ISP and 2007:0:aaaa::/48 from its normal ISP. Site B has 2001:bbbb:bbbb::/48 from the high-performance ISP and 2007:0:bbbb::/48 from its normal ISP. Every host in both sites registers two addresses in the DNS 🌸

Routing inside both sites sends most traffic out the egress to the normal ISP, but traffic going to the other site's 2001 prefix gets sent out the egress to the high-performance ISP. To stop anyone using that expensive connection by accident, both sites run ingress filtering that discards traffic coming in from the high-performance ISP unless it's from the other site 🛡️

The default policy table and address selection rules give this:

Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
Result: 2007:0:bbbb::b (src 2007:0:aaaa::a) then 2001:bbbb:bbbb::b
(src 2001:aaaa:aaaa::a) (longest matching prefix)

So when a host in site A starts a connection to a host in site B, the traffic does not use the high-performance ISP 😭 That's not what they want at all.

Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
Result: 2001:cccc:cccc::c (src 2001:aaaa:aaaa::a) then
2006:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)

And when a host in site A talks to a host in some other site C, the reply might come back through the high-performance ISP. Again, not the goal 🙈

This whole mess shows the limits of the longest-matching-prefix heuristic in multi-homed setups. It's giving "good idea, wrong situation" 💀

Good news though: the site administrators can get what they want by configuring the policy table. For example, they can use this one:

      Prefix              Precedence Label
      ::1                         50     0
      2001:aaaa:aaaa::/48         45     5
      2001:bbbb:bbbb::/48         45     5
      ::/0                        40     1
      2002::/16                   30     2
      ::/96                       20     3
      ::ffff:0:0/96               10     4

With that table, the results change 🦋

Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:bbbb:bbbb::b or 2007:0:bbbb::b
New Result: 2001:bbbb:bbbb::b (src 2001:aaaa:aaaa::a) then
2007:0:bbbb::b (src 2007:0:aaaa::a) (prefer higher precedence)

Now when a host in site A connects to a host in site B, the traffic uses the high-performance ISP exactly like they planned. Main character energy 👑

Candidate Source Addresses: 2001:aaaa:aaaa::a or 2007:0:aaaa::a or
fe80::a
Destination Address List: 2001:cccc:cccc::c or 2006:cccc:cccc::c
New Result: 2006:cccc:cccc::c (src 2007:0:aaaa::a) then
2001:cccc:cccc::c (src 2007:0:aaaa::a) (longest matching prefix)

And when a host in site A talks to a host in site C, the traffic uses the normal ISP like it's supposed to ✨ Iconic.

Normative References 📚

[1] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 2373, July 1998.
[2] Thompson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462 , December 1998.
[3] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[4] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[5] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[6] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.

Informative References 🧚

[7] Bradner, S., "The Internet Standards Process -- Revision 3", BCP 9, RFC 2026, October 1996.
[8] Johnson, D. and C. Perkins, "Mobility Support in IPv6", Work in Progress.
[9] S. Cheshire, B. Aboba, "Dynamic Configuration of IPv4 Link-local Addresses", Work in Progress.
[10] Gilligan, R., Thomson, S., Bound, J. and W. Stevens, "Basic Socket Interface Extensions for IPv6", RFC 2553, March 1999.
[11] S. Deering et. al, "IP Version 6 Scoped Address Architecture", Work in Progress.
[12] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[13] Baker, F, "Requirements for IP Version 4 Routers", RFC 1812, June 1995.
[14] Narten, T. and E. Nordmark, and W. Simpson, "Neighbor Discovery for IP Version 6", RFC 2461, December 1998.
[15] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 Domains without Explicit Tunnels", RFC 2529, March 1999.
[16] F. Templin et. al, "Intra-Site Automatic Tunnel Addressing Protocol (ISATAP)", Work in Progress.
[17] Gilligan, R. and E. Nordmark, "Transition Mechanisms for IPv6 Hosts and Routers", RFC 1933, April 1996.

Acknowledgments 🫶

Huge thank-you to the IPng Working Group 💖 Special shoutout to Marc Blanchet, Brian Carpenter, Matt Crawford, Alain Durand, Steve Deering, Robert Elz, Jun-ichiro itojun Hagino, Tony Hain, M.T. Hollinger, JINMEI Tatuya, Thomas Narten, Erik Nordmark, Ken Powell, Markku Savela, Pekka Savola, Hesham Soliman, Dave Thaler, Mauro Tortonesi, Ole Troan, and Stig Venaas. The anonymous IESG reviewers also left great comments and suggestions for clarification, which is so iconic of them 🙌

Author's Address 🎀

Richard Draves
Microsoft Research
One Microsoft Way
Redmond, WA 98052

Phone: +1 425 706 2268
EMail: richdr@microsoft.com

Full Copyright Statement ⚖️

This is the legal bit, so I'm keeping it word for word 🙏

Copyright (C) The Internet Society (2003).  All Rights Reserved.

This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works.  However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.

The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.

This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Acknowledgement 💜

Funding for the RFC Editor function is currently provided by the Internet Society. Bestie, that's the whole RFC 🦋✨

📦 where this page comes from

ietf: rfc3484 2003-03
💖 girlified by claude-haiku-5-5 on 2026-10-16: a language model's rewrite of the original, under its terms