3. Problem history for the host-driven solution

Client applications typically utilize getaddrinfo() to establish communication and to perform source address selection. It was initially assumed in [SASA] and implemented by getaddrinfo() that the next hop is chosen before the source address.
Bind() permits overriding this order, but it is typically used only in server-side applications.
This specific process is the reason why in the case of a network fault, when a redundant CPE/link is promoted to the primary role, some specific destinations may become unreachable, causing the solutions listed hereafter to leave some unresolved scenarios.
The initial discussion on carrier resiliency occurred in the [multi6] and [Shim6] working groups. [multi6] requirements were reused in this document. [shim6] proposed to separate the location and identity properties of addresses. [Shim6] did not gain market acceptance. It is not currently supported by available software and hardware options.
The host-based solution is highly dependent on the availability of the information that the prefix is stale. [6renum] has a deep discussion on how to best react in cases where there is missing information, including the use of other mechanisms to automatically resolve the problem. The best way to provide warnings about stale prefixes is still in discussion [flash renumbering].
The next notable step was the addition of rule 5.5 to [SASA] to prefer the selection of a source address covered by a prefix advertised by the chosen next hop router. This allows the packet to be on the path to the PA-owning carrier and avoid packet filtering due to the application of [BCP38].
Concerning Figure 1, if connectivity to Carrier 1 were lost then the host would select a source address in the prefix belonging to Carrier 2 to communicate with a certain destination outside of its local segment, thus achieving resiliency.
On the other hand, this method is not a solution when only a particular source address is permitted (i.e., not filtered) to access a particular outside resource (e.g., “subscriber-only services”) or when any type of deterministic traffic distribution policy is desired, because the random next hop choice would in turn lead to a random choice of source address.
[MHMP] then discussed the problem thoroughly, attempting to use only already available tools. It was suggested that the solution must push related policies to the host as 1) “Routing Information Options” of [Route Preferences] and 2) [Policy by DHCP] to modify policies in the host's [SASA] selection algorithm. This solution has not gained market acceptance due to complexity reasons. Moreover, DHCPv6 is not universally implemented, being notably absent from some of the most widely deployed client platforms.
Additionally, [HNCP] prescribes deprecating delegated prefixes (by setting their preferred lifetime to zero) when the router has information about loss of reachability to the carrier that sourced the prefix. This is particularly important when renumbering occurs (the PA prefix may change after disconnection and re-connection to the carrier).
The next solution was proposed in [Multi-Homing]. The document incorrectly assumed (errata 7009 and 7010 are published) that the source address is chosen first in the typical scenario when a client initiates outbound communications. [Multi-Homing] section 3.2 proposed to prefer next hops from those routers that advertise the prefix covering the already selected source address. Hence, [Multi-Homing] unblocked the possibility for an application to use bind() to select the source address first since section 3.2 contains vital instructions on how to choose the next hop in that condition. It is important to note that the more common scenario of choosing the next hop before the source address is not solved by [Multi-Homing].
Further progress in the problem discussion was made in [MHMP Enterprise], which discusses potentially complex on-site topologies and the source routing that is needed in such a scenario; it may be considered a comprehensive guide covering the source routing aspect of the complex site with carrier resiliency. Unfortunately, at this time it is not yet possible to use it in practice due to the lack of any market-accepted solutions to split and distribute PA prefixes throughout the complex site. All other solutions (PI, ULA+NAT66, ULA+NPTv6) do not require source routing. [MHMP Enterprise] might become vital in the future if a solution were to be adopted for splitting and propagating PA prefixes through the complex site; however, such a solution is currently unavailable.
Restrictions to the list of applicable source addresses for a specific next hop (rule 5 or 5.5 of [SASA]) may not have been implemented in certain host operating systems. [Conditional PIO] can in this case mitigate the problem through selective PIO announcements to a particular host. This represents a valuable transition mechanism until rule 5.5 of [SASA] will be universally applied.
[DNS Options] allows the router to supply the addresses of many different DNS resolvers, including those of completely unrelated carriers. It is not possible, however, to provide information to clients regarding which DNS resolver is related to which particular prefix; such information might be crucial in scenarios where traffic steering policies are required for successful communication (including when accessing filtered resources such as “subscriber-only services”).
Finally, [Provisioning domains] permit virtualization of the router on the link, representing one physical device as many logical ones with fully separate sets of link parameters. This solution is valuable in some scenarios to deliver more diverse information to the host but does little to assist it with choosing the proper combination of next hop and source address that is still restricted by [SASA]. The challenge remains the same independent of how many physical or logical routers are present on the link. Moreover, virtualization of a single router on a link having two uplinks to different carriers creates a problem, because the host could randomly choose the wrong combination of source address and next hop announced by one of the virtual routers.
Yet, [Provisioning domains] remains valuable in scenarios where several different routers are behind a single router, as well as when multiple physical routers are present on the same link (i.e., the problem of host choice already exists). This is because, in contrast to [DNS Options], [Provisioning domains] retains the information that associates prefixes with the DNS resolvers of their respective carrier.