+------+       ___________
                           |      |      /           \
                       +---| rtr1 |=====/   network   \
                       |   |      |     \      1      /
+------+     +-----+   |   +------+      \___________/
| IPv4 |     |     |   |
| hosts|-----| GW  |---+
|      |     | rtr |   |
+------+     +-----+   |   +------+       ___________
            (NAPT&DNS) |   |      |      /           \
(private               +---| rtr2 |=====/   network   \
    address                |      |     \      2      /
       space)              +------+      \___________/
            

Figure 4: IPv4 Multihomed environment with Gateway Router performing NAPT

3.3. Problem Statement

A multihomed IPv6 host has one or more assigned IPv6 addresses and DNS recursive name servers from each upstream service provider, resulting in the host having multiple valid IPv6 addresses and DNS recursive name servers. The host must be able to resolve the appropriate next-hop, the correct source address and DNS recursive name server to use based on the destination prefix. To prevent IP spoofing, operators will often implement ingress filtering to discard traffic with an inappropriate source address, making it essential for the host to correctly resolve these three items before sourcing the first packet.

IPv6 has mechanisms for the provision of multiple routers on a single link and multiple address assignments to a single host. However, when these mechanisms are applied to the three scenarios in Section 3.1 a number of connectivity issues are identified:

Scenario 1:

The host has been assigned an address from each router and recognizes both rtr1 and rtr2 as valid default routers (in the default routers list).

• The source address selection policy on the host does not deterministically resolve a source address. Ingress filtering or filter policies will discard traffic with source addresses that the operator did not assign.
• The host will select one of the two routers as the active default router. No traffic is sent to the other router.

Scenario 2:

The host has been assigned two different addresses from the single gateway router. The gateway router is the only default router on the link.

• The source address selection policy on the host does not deterministically resolve a source address. Ingress filtering or filter policies will discard traffic with source addresses that the operator did not assign.
• The gateway router does not have an autonomous mechanism for determining which traffic should be sent to which network. If the gateway router is implementing host functions (i.e., processing Router Advertisement) then two valid default routers may be recognized.

Scenario 3:

A host has two separate interfaces and on each interface a different address is assigned. Each link has its own router.

• The host does not have enough information for determining which traffic should be sent to which upstream routers. The host will select one of the two routers as the active default router, and no traffic is sent to the other router. The default address selection rules select the address assigned to the outgoing interface as the source address. So, if a host has an appropriate routing table, an appropriate source address will be selected.

All scenarios:

• In network deployments utilizing local namespaces, the host may choose to communicate with a "wrong" DNS recursive server unable to serve a local namespace.

4. Requirements

This section describes requirements that any solution multi-address and multi-uplink architectures need to meet.

4.1. End-to-End transparency

One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet. If NAT is applied to IP communication between hosts, NAT traversal mechanism are required, to establish bi-directional IP communication. A NAT traversal mechanism does not need to be implemented in an application, in an environment with end-to-end transparency. Therefore, the IPv6 multihoming solution should strive to avoid NPTv6 to achieve end-to-end transparency.

4.2. Scalability

The solution will have to be able to manage a large number of sites/nodes. In services for residential users, provider edge devices have to manage thousands of sites. In such environments, sending packets periodically to each site may affect edge system performance.

5. Problem statement and analysis

The problems described in Section 3 can be classified into these three types:

• Wrong source address selection
• Wrong next-hop selection
• Wrong DNS server selection

This section reviews the problem statements presented above and the proposed functional requirements to resolve the issues.

5.1. Source address selection

A multihomed IPv6 host will typically have different addresses assigned from each service provider either on the same link (scenarios 1 & 2) or different links (scenario 3). When the host wishes to send a packet to any given destination, the current source address selection rules [RFC6724] may not deterministically select the correct source address. [RFC7078] describes the use of the policy table [RFC6724] to resolve this problem, using a DHCPv6 mechanism for host policy table management.

Again, by employing DHCPv6, the server could restrict address assignment (of additional prefixes) only to hosts that support policy table management.

Scenario 1: "Host" needs to support the solution for this problem.

Scenario 2: "Host" needs to support the solution for this problem.

Scenario 3: If "Host" support the next-hop selection solution, there is no need to support the address selection functionality on the host.

It is noted that the service providers (i.e., ISP and enterprise/VPN) must also support [RFC7078].

5.2. Next-hop selection

A multihomed IPv6 host or gateway may have multiple uplinks to different service providers. Here each router would use Router Advertisements [RFC4861] for distributing default route/next-hop information to the host or gateway router.

In this case, the host or gateway router may select any valid default router from the default routers list, resulting in traffic being sent to the wrong router and discarded by the upstream service provider. Using the above scenarios as an example, whenever the host wishes to reach a destination in network 2 and there is no connectivity between networks 1 and 2 (as is the case for a walled-garden or closed service), the host or gateway router does not know whether to forward traffic to rtr1 or rtr2 to reach a destination in network 2. The host or gateway router may choose rtr1 as the default router, and traffic fails to reach the destination server. The host or gateway router requires route information for each upstream service provider, but the use of a routing protocol between the gateway and the two routers causes both configuration and scaling issues. For IPv4 hosts, the gateway router is often pre-configured with static route information or uses of Classless Static Route Options [RFC3442] for DHCPv4. Extensions to Router Advertisements through Default Router Preference and More-Specific Routes [RFC4191] provides for link-specific preferences but does not address per-host configuration in a multi-access topology because of its reliance on Router Advertisements.

Scenario 1: "Host" needs to support the solution for this problem.

Scenario 2: "GW rtr" needs to support the solution for this problem.

Scenario 3: "Host" needs to support the solution for this problem.

5.3. DNS recursive name server selection

A multihomed IPv6 host or gateway router may be provided multiple DNS recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106]. When the host or gateway router sends a DNS query, it would normally choose one of the available DNS recursive name servers for the query.

In the IPv6 gateway router scenario, the Broadband Forum [TR124] requires that the query be sent to all DNS recursive name servers, and the gateway waits for the first reply. In IPv6, given our use of specific destination-based policy for both routing and source address selection, it is desirable to extend a policy-based concept to DNS recursive name server selection. Doing so can minimize DNS recursive name server load and avoid issues where DNS recursive name servers in different networks have connectivity issues, or the DNS recursive name server are not publicly accessible. In the worst case, a DNS query for a name from a local namespace may not be resolved correctly if sent towards a DNS server not aware of said local namespace, resulting in a lack of connectivity.

It is not an issue of Domain Name System model itself, but an IPv6 multihomed host or gateway router should have the ability to select appropriate DNS recursive name servers for each service based on the domain space for the destination, and each service should provide rules specific to that network. [RFC6731] proposes a solution for distributing DNS server selection policy using a DHCPv6 option.

Scenario 1: "Host" needs to support the solution for this problem.

Scenario 2: "GW rtr" needs to support the solution for this problem.

Scenario 3: "Host" needs to support the solution for this problem.

It is noted that the service providers (i.e., ISP and enterprise/VPN) must also support [RFC6731].

6. Implementation approach

As mentioned in Section 5, in the multi-prefix environment, we have three problems; source address selection, next-hop selection, and DNS recursive name server selection. In this section, possible solutions for each problem are introduced and evaluated against the requirements in Section 4.

6.1. Source address selection

The problems of address selection in multi-prefix environments are summarized in [RFC5220]. When solutions are examined against the requirements in Section 4, the proactive approaches, such as the policy table distribution mechanism and the routing hints mechanism, are more appropriate in that they can propagate the network administrator's policy directly. The policy distribution mechanism has an advantage with regard to the host's protocol stack impact and the static nature of the assumed target network environment.

6.2. Next-hop selection

As for the source address selection problem, both a policy-based approach and a non policy-based approach are possible with regard to the next-hop selection problem. Because of the same requirements, the policy propagation-based solution mechanism, whatever the policy, should be more appropriate.

Routing information is a typical example of policy related to next-hop selection. If we assume source address-based routing at hosts or intermediate routers, pairs of source prefixes and next-hops can be another example of next-hop selection policy.

The routing information-based approach has a clear advantage in implementation and is already commonly used.

The existing proposed or standardized routing information distribution mechanisms are routing protocols, such as RIPng and OSPFv3, the RA extension option defined in [RFC4191], and the [TR069] standardized at BBF.

The RA-based mechanism doesn't handle distribution of per-host routing information easily. Dynamic routing protocols are not typically used between residential users and ISPs, because of their scalability and security implications. The DHCPv6 mechanism does not have these problems and has the advantage of its relaying functionality. It is commonly used and is thus easy to deploy.

[TR069], mentioned above, is a possible solution mechanism for routing information distribution to customer-premises equipment (CPE). It assumes, however, IP reachability to the Auto Configuration Server (ACS) is established. Therefore, if the CPE requires routing information to reach the ACS, [TR069] cannot be used to distribute this information.

6.3. DNS recursive name server selection

• Note: Split-horizon DNS is discussed in this section. Split-horizon DNS is known to cause problems with applications to allow information leakage. The discussion of split-horizon DNS is not condoning its use, but rather acknowledging that split-horizon DNS is used and that its use is another justification for network address translation. The goal of this document is to encourage building solutions which do not need network address translation. Two solutions appear possible: make split-horizon DNS work better (which is discussed below) or meet network administrator's requirements without split-horizon DNS (which is out of scope of this document).

As in the above two problems, a policy-based approach and a non policy-based approach are possible. In a non policy-based approach, a host or a home gateway router is assumed to send DNS queries to several DNS recursive name servers at once or to select one of the available servers.

In the non policy-based approach, by making a query to a DNS recursive name server in a different service provider to that which hosts the service, a user could be directed to unexpected IP address or receive an invalid response, and thus cannot connect to the service provider's private and legitimate service. For example, some DNS recursive name servers reply with different answers depending on the source address of the DNS query, which is sometimes called split-horizon. When the host mistakenly makes a query to a different provider's DNS recursive name server to resolve a FQDN of another provider's private service, and the DNS recursive name server adopts the split-horizon configuration, the queried server returns an IP address of the non-private side of the service. Another problem with this approach is that it causes unnecessary DNS traffic to the DNS recursive name servers that are visible to the users.

The alternative of a policy-based approach is documented in [RFC6731], where several pairs of DNS recursive name server addresses and DNS domain suffixes are defined as part of a policy and conveyed to hosts in a new DHCP option. In an environment where there is a home gateway router, that router can act as a DNS recursive name server, interpret this option and distribute DNS queries to the appropriate DNS servers according to the policy.

6.4. Other algorithms available in RFCs

The authors of this document are aware of a variety of other algorithms and architectures, such as shim6 [RFC5533] and HIP [RFC5206], that may be useful in this environment. At this writing, there is not enough operational experience on which to base a recommendation. Should such operational experience become available, this document may be updated in the future.

7. Considerations for MHMP deployment

This section describes considerations to mitigate possible problem in a network which implements MHMP described in Section 6.

7.1. Non-MHMP host consideration

In a typical IPv4 multihomed network deployment, IPv4 NAPT is practically used and it can eventually avoid assigning multiple addresses to the hosts and solve the next-hop selection problem. In a similar fashion, NPTv6 can be used as a last resort for IPv6 multihomed network deployments where one needs to assign a single IPv6 address to a non-MHMP host.

                                              __________
                                             /          \
                                        +---/  Internet  \
                    gateway router      |   \            /
  +------+     +---------------------+  |    \__________/
  |      |     |   |        |  WAN1  +--+
  | host |-----|LAN| Router |--------|
  |      |     |   |        |NAT|WAN2+--+
  +------+     +---------------------+  |     __________
                                        |    /          \
                                        +---/    ASP     \
                                            \            /
                                             \__________/