RFC 7157
IPv6 Multihoming without Network Address Translation
IPv6 Multihoming without Network Address Translation 🎀
okay bestie, this RFC is an Informational doc from the IETF, published in March 2014 as RFC 7157 🌸 It's not a Standards Track spec, so it's a "here's what we explored" doc, not a "you must implement this" doc. ISSN 2070-1721. The authors are O. Troan (editor, Cisco), D. Miles (Google Fiber), S. Matsushima (Softbank Telecom), T. Okimoto (NTT West), and D. Wing (Cisco). The title block doesn't list any RFC it obsoletes or updates, so it's a standalone vibe ✨
Abstract
okay so the big idea 💖 NAPT works really well for stretching global addresses and handling multihoming, because an IPv4 NAPT router does three jobs: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one option could be IPv6-to-IPv6 Network Prefix Translation (NPTv6). But NAT and NPTv6 should be avoided, if at all possible, so that end-to-end connectivity stays transparent 🦋 This doc looks at multihoming use cases and describes the functional requirements and possible solutions for doing multihoming without NAT in IPv6, for hosts and small IPv6 networks that couldn't meet the minimum IPv6 allocation criteria otherwise. The conclusion? DHCPv6-based solutions are suitable for the multihoming issues described here, but NPTv6 may be required as an intermediate solution 🫶
Status of This Memo
this section is the official "what kind of doc is this" part 📜 This document is not an Internet Standards Track specification. It's published for informational purposes.
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). Not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 for the details 💅
For info on the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc7157.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review those documents carefully, because they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions, and they are provided without warranty as described in the Simplified BSD License 📝
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPv6 Multihomed Network Scenarios . . . . . . . . . . . . . . 6
3.1. Classification of Network Scenarios for Multihomed Host . 6
3.2. Multihomed Network Environment . . . . . . . . . . . . . 8
3.3. Problem Statement . . . . . . . . . . . . . . . . . . . . 9
4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. End-to-End Transparency . . . . . . . . . . . . . . . . . 11
4.2. Scalability . . . . . . . . . . . . . . . . . . . . . . . 11
5. Problem Analysis . . . . . . . . . . . . . . . . . . . . . . 11
5.1. Source Address Selection . . . . . . . . . . . . . . . . 11
5.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 12
5.3. DNS Recursive Name Server Selection . . . . . . . . . . . 13
6. Implementation Approach . . . . . . . . . . . . . . . . . . . 13
6.1. Source Address Selection . . . . . . . . . . . . . . . . 14
6.2. Next Hop Selection . . . . . . . . . . . . . . . . . . . 14
6.3. DNS Recursive Name Server Selection . . . . . . . . . . . 15
6.4. Other Algorithms Available in RFCs . . . . . . . . . . . 16
7. Considerations for MHMP Deployment . . . . . . . . . . . . . 16
7.1. Non-MHMP Host Consideration . . . . . . . . . . . . . . . 16
7.2. Coexistence Considerations . . . . . . . . . . . . . . . 17
7.3. Policy Collision Consideration . . . . . . . . . . . . . 17
8. Security Considerations . . . . . . . . . . . . . . . . . . . 18
9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 19
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20
10.1. Normative References . . . . . . . . . . . . . . . . . . 20
10.2. Informative References . . . . . . . . . . . . . . . . . 201. Introduction ✨
okay so in this doc we analyze multihoming use cases 🔥 describe functional requirements, and describe the problems with IPv6 multihoming. There are two ways to avoid those problems:
- using IPv6-to-IPv6 network prefix translation (NPTv6) [RFC6296], or;
- refining IPv6 specifications to resolve the problems with IPv6 multihoming.
This doc is all about the latter and explores the solution space 🌈 We hope it encourages people to build solutions, so that in the long run NPTv6 can be avoided.
IPv6 gives us enough globally unique addresses to let every conceivable host on the Internet be uniquely addressed without needing Network Address Port Translation (NAPT) [RFC3022], which is giving renaissance energy for end-to-end transparent connectivity 💜
Unfortunately, this might not be possible in every case, because even in IPv6 NAT may be needed for multihoming 😭 There are mechanisms for multihoming, like BGP multihoming [RFC4116] at the network level and multihoming based on the Stream Control Transmission Protocol (SCTP) [RFC4960] at the transport layer. But IPv6 has no mechanism that replaces NAT-based multihoming from IPv4. In IPv4, for a host or a small network, NAT-based multihoming is easy to deploy and is already a deployed technique 🍓
Whenever a host or small network (one that doesn't meet minimum IPv6 allocation criteria) connects to multiple upstream networks, each service provider assigns an IPv6 address. That means the host ends up with multiple global scope IPv6 addresses, each with a different prefix. Since each service provider gets a different address space from its Internet Registry, it assigns a different address space to the end-user network or host in turn. For example, a remote access user's host or router might use a VPN to connect to a remote network while keeping a default route to the Internet for other purposes 🧚
In IPv4, a common fix for multihoming is to run NAPT on a border router and use private address space for individual host addressing. With NAPT, a host has exactly one IP address visible on the public network. The combo of NAPT, provider-specific outside addresses (one for each uplink), and destination-based routing shields a host from the impacts of multiple upstream networks. The border router may also run a DNS cache or DNS policy to resolve address queries from hosts 💅
It's our goal to avoid the IPv6 equivalent of NAT. So the goals for IPv6 multihoming defined in [RFC3582] don't match the goals of this doc. Also, no matter what the NPTv6 specification says, we're trying to avoid any form of network address translation that might not be visible to either end host 🙈 To get there, several mechanisms are needed so end-user hosts can have multiple address assignments and sort out issues like which address to use for sourcing traffic to which destination:
- If multiple routers exist on a single link, the host must select the appropriate next hop for each connected network. Each router is in turn connected to a different service provider network, which provides independent address assignment. Routing protocols that would normally run between router-to-router network advertisement seem inappropriate for individual hosts to use 🦋
- Source address selection gets difficult whenever a host has more than one address of the same address scope. Current address selection criteria may result in hosts using an arbitrary or random address when sourcing upstream traffic. Unfortunately, for the host, the right source address depends on the upstream network the packet is bound for. If an upstream service provider uses IP anti-spoofing or ingress filtering, packets with an inappropriate source address for that upstream network might never reach their destination 😬
- In a multihomed environment, different DNS scopes or partitions may exist in each independent upstream network. A DNS query sent to an arbitrary upstream DNS recursive name server may result in incorrect or poisoned responses 💀
In short, IPv6 lets hosts have more than one address in the same address scope, but that causes real issues for a host from the routing, source address selection, and DNS resolution perspectives. A possible consequence of giving a host multiple identically scoped addresses is severely impaired IP connectivity 😭
If a host connects to a network behind an IPv4 NAPT, the host has one private address in the local network. There's no confusion there. The NAT becomes the gateway of the host and forwards the packet to an appropriate network when it's multihomed. It also runs a DNS cache server or DNS proxy, which receives all DNS inquires and gives the host a correct answer 🌸
2. Terminology 📚
here are the key terms, bestie 💜
NPTv6 IPv6-to-IPv6 Network Prefix Translation as described in
[RFC6296].
NAPT Network Address Port Translation as described in
[RFC3022]. In other contexts, NAPT is often pronounced
"NAT" or written as "NAT".
MHMP Multihomed with multi-prefix. A host implementation that
supports the mechanisms described in this document;
namely, source address selection policy, next hop
selection, and DNS selection policy.3. IPv6 Multihomed Network Scenarios 🦋
okay so in this section we sort the multihoming environment into three scenarios 🎀
3.1. Classification of Network Scenarios for Multihomed Host 💖
Scenario 1:
okay so in this one, there are two or more routers chilling on a single link with the host(s) 🫶 each router is hooked up to a different service provider network, and each provider runs its own independent address assignment and DNS recursive name servers. so a host here gets offered multiple prefixes and DNS recursive name servers advertised from the two different routers 💅
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ | +------+ \___________/
| | |
| hosts|-----+
| | |
+------+ | +------+ ___________
| | | / \
+---| rtr2 |=====/ network \
| | \ 2 /
+------+ \___________/
Figure 1: Single Uplink, Multiple Next Hop, Multiple Prefix
(Scenario 1)figure 1 is giving the host connecting to rtr1 and rtr2 over a shared link ✨ network 1 is reachable via rtr1 and network 2 is reachable via rtr2. when the host sends packets to network 1, the next hop is rtr1. similarly, rtr2 is the next hop to network 2 🦋
Example: multiple broadband service providers (Internet, VoIP, IPTV, etc.) 📺
Scenario 2:
in this one, a single gateway router is the host's connection to two or more upstream service provider networks 🌸 this gateway router gets prefix delegations and a different set of DNS recursive name servers from each independent service provider network. then the gateway advertises the provider prefixes to the host. for DNS, it may either act as a lightweight DNS cache server or advertise the complete set of service provider DNS recursive name servers to the hosts 🧚
+------+ ___________
+-----+ | | / \
| |=======| rtr1 |=====/ network \
| |port1 | | \ 1 /
+------+ | | +------+ \___________/
| | | |
| hosts|-----| GW |
| | | rtr |
+------+ | | +------+ ___________
| |port2 | | / \
| |-------| rtr2 |=====/ network \
+-----+ | | \ 2 /
+------+ \___________/
Figure 2: Single Uplink, Single Next Hop, Multiple Prefix
(Scenario 2)figure 2 shows the host connected to GW rtr, and GW rtr connects to networks 1 and 2 via port1 and port2 respectively 🎀 as the figure shows a logical topology of the scenario, port1 could be a pseudo-interface for tunneling, which connects to network 1 through network 2 and vice versa 🌈 when the host sends packets to either network 1 or 2, the next hop is GW rtr. when the packets are sent to network 1 (network 2), GW rtr forwards the packets to port1 (port2) 💜
Example: Internet + VPN / Application Service Provider (ASP) 🍓
Scenario 3:
in this one, a host has more than one active interface connecting to different routers and service provider networks 🦋 each router gives the host a different address prefix and set of DNS recursive name servers, so the host ends up with a unique address per link/interface 💖
+------+ +------+ ___________
| | | | / \
| |-----| rtr1 |=====/ network \
| | | | \ 1 /
| | +------+ \___________/
| |
| host |
| |
| | +------+ ___________
| | | | / \
| |=====| rtr2 |=====/ network \
| | | | \ 2 /
+------+ +------+ \___________/
Figure 3: Multiple Uplink, Multiple Next Hop, Multiple Prefix
(Scenario 3)figure 3 shows the host connecting to rtr1 and rtr2 via a direct connection or a virtual link 🫧 when the host sends packets to network 1, the next hop is rtr1. similarly, rtr2 is the next hop to network 2 ✨
Example: Mobile Wifi + 3G, ISP A + ISP B 📱
3.2. Multihomed Network Environment 🌸
ok so in an IPv6 multihomed network, a host gets two or more IPv6 addresses and DNS recursive name servers from independent service provider networks 🧚 when this multihomed host tries to connect with other hosts, it may incorrectly resolve the next-hop router, use an inappropriate source address, or use a DNS response from an incorrect service provider. that can result in impaired IP connectivity 😭
in lots of cases, multihomed networks in IPv4 were built using a gateway router with NAPT function (scenario 2 with NAPT) 🍓 looking at how the current IPv4 NAPT and DNS functions work inside that gateway router should give us a baseline set of requirements for IPv6 multihomed environments 🔥 a destination prefix/route is often used on the gateway router to separate traffic between the networks 🫶
+------+ ___________
| | / \
+---| rtr1 |=====/ network \
| | | \ 1 /
+------+ +-----+ | +------+ \___________/
| IPv4 | | | |
| hosts|-----| GW |---+
| | | rtr | |
+------+ +-----+ | +------+ ___________
(NAPT&DNS) | | | / \
(private +---| rtr2 |=====/ network \
address | | \ 2 /
space) +------+ \___________/
Figure 4: IPv4 Multihomed Environment with
Gateway Router Performing NAPT3.3. Problem Statement 💀
so a multihomed IPv6 host has one or more assigned IPv6 addresses and DNS recursive name servers from each upstream service provider 😭 that means the host ends up with 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 the correct 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. that makes 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 described 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, and 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 (RA)), then two valid default routers may be recognized 🌀
Scenario 3:
a host has two separate interfaces, and each interface has a different address assigned. each link has its own router 🦋
- the host does not have enough information to determine 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 for multi-address and multi-uplink architectures needs 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 mechanisms are required to establish bidirectional IP communication. in an environment with end-to-end transparency, a NAT traversal mechanism does not need to be implemented in an application (e.g., ICE [RFC5245]). 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 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 💅
okay so a multihomed IPv6 host is typically going to have different addresses handed out by each service provider, either on the same link (scenarios 1 and 2) or on different links (scenario 3) 🌸 when the host wants to send a packet to some destination, the current source address selection rules [RFC6724] may not reliably pick the right source address 😭 [RFC7078] describes using the policy table (as discussed in [RFC6724]) to fix this, using a DHCPv6 mechanism for host policy table management ✨
and again, by using DHCPv6, the server could limit address assignment (of additional prefixes) to only the 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 supports the next hop selection solution, there is no need to support the address selection functionality on the host. 🦋
also, the network's DHCP server and DHCP-forwarding routers must also support the Address Selection option [RFC7078] 💜
5.2. Next Hop Selection 🧚
a multihomed IPv6 host or gateway might have several uplinks to different service providers 🌈 in that case each router would use Router Advertisements [RFC4861] to hand out default route and next-hop info to the host or gateway router 💖
here's the tea 🍓 the host or gateway router can pick any valid default router from the default routers list, and that can send traffic to the wrong router, which then gets dropped by the upstream service provider 💀 using the scenarios above as an example: whenever the host wants to reach a destination in network 2, and there's no connectivity between networks 1 and 2 (like with a walled-garden or closed service), the host or gateway router has no idea whether to forward traffic to rtr1 or rtr2 to get to network 2 😵 it might choose rtr1 as the default router, but the traffic will fail to reach the destination server 😩 the host or gateway router needs route information for each upstream service provider, but running a routing protocol between the gateway and the two routers causes both configuration and scaling issues 🙈 in IPv4, gateway routers are often pre-configured with static routes or use the Classless Static Route Options [RFC3442] for DHCPv4 ✨ an extension to Router Advertisements called Default Router Preference and More-Specific Routes [RFC4191] gives link-specific preferences, but it doesn't address per-host configuration in a multi-access topology, because it relies 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 might be given multiple DNS recursive name servers through DHCPv6 [RFC3646] or RA [RFC6106] 💅 when the host or gateway router sends a DNS query, it would normally pick one of the available DNS recursive name servers for that query 🌸
in the IPv6 gateway router scenario, the Broadband Forum (BBF) [TR-124] requires that the query be sent to all DNS recursive name servers, and that the gateway wait for the first reply 😳 in IPv6, since we already use specific destination-based policy for both routing and source address selection, it's desirable to extend that policy-based concept to DNS recursive name server selection ✨ doing this can minimize DNS recursive name server load, and it avoids issues where DNS recursive name servers in different networks have connectivity problems, or the DNS recursive name servers aren't publicly accessible 🦋 in the worst case, a DNS query for a name from a local namespace may not get resolved correctly if it's sent to a DNS server that isn't aware of that local namespace, which means a lack of connectivity 😭
this isn't an issue with the Domain Name System model itself 🧚 but an IPv6 multihomed host or gateway router should be able 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 its own 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.
also, the network's DHCP server and DHCP-forwarding routers must also support the Address Selection option [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 💜 this section introduces possible solutions for each problem, and evaluates them 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 checked against the requirements in Section 4, the proactive approaches, like the policy table distribution mechanism and the routing hints mechanism, are more appropriate, because they can pass the network administrator's policy along directly ✨ the policy distribution mechanism has an advantage when it comes to the host's protocol stack impact, and the static nature of the assumed target network environment 👑
6.2. Next Hop Selection 🧚
just like with source address selection, both a policy-based approach and a non-policy-based approach are possible for next hop selection 🌸 because of those same requirements, the policy propagation-based solution mechanism, whatever the policy is, 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 it's already commonly used 🫶
the existing proposed or standardized routing information distribution mechanisms are routing protocols (such as Routing Information Protocol Next Generation (RIPng) and OSPFv3), the RA extension option defined in [RFC4191], and the CPE WAN Management Protocol (CWMP) [TR069] standardized at BBF 🌈
the RA-based mechanism doesn't handle distribution of per-host routing information easily 🙈 dynamic routing protocols aren't typically used between residential users and ISPs, because of their scalability and security implications 😬 the DHCPv6 mechanism doesn't have these problems, and it has the advantage of relay functionality ✨ it's commonly used, so it's easy to deploy 💅
[TR069], mentioned above, defines a possible solution mechanism for distributing routing information to customer premises equipment (CPE) 🦋 it assumes, however, that IP reachability to the Auto Configuration Server (ACS) has already been established 🥺 so if the CPE needs routing information to reach the ACS, CWMP [TR069] can't be used to distribute that 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 that 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 that do not need network address translation. Two solutions appear possible: improve the function of split-horizon DNS (which is discussed below) or meet network administrators' requirements without split-horizon DNS (which is out of scope of this document). 🙈
as with 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, if a query goes to a DNS recursive name server from a different service provider than the one hosting the service, a user could be sent to an unexpected IP address or receive an invalid response 😱 so they couldn't 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 queries a different provider's DNS recursive name server to resolve a Fully Qualified Domain Name (FQDN) of another provider's private service, and that server uses the split-horizon configuration, the queried server returns an IP address for 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 users 🙃
the alternative to 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 with 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 the time of writing, there isn't enough operational experience to base a recommendation on 🥹 if such operational experience becomes available, this document may be updated in the future ✨
7. Considerations for MHMP Deployment 💜
this section describes considerations for mitigating possible problems in a network that implements MHMP (described in Section 6) 🫶
7.1. Non-MHMP Host Consideration
okay so in a typical IPv4 multihomed setup, people basically use IPv4 NAPT 💅 and it can eventually stop you from handing out multiple addresses to every host, and it solves the next hop selection problem too 🎀 same vibe for IPv6: NPTv6 can be the last resort when you need to give a single IPv6 address to a non-MHMP host 🦋
__________
/ \
+---/ Internet \
gateway router | \ /
+------+ +---------------------+ | \__________/
| | | | | WAN1 +--+
| host |-----|LAN| Router |--------|
| | | | |NAT|WAN2+--+
+------+ +---------------------+ | __________
| / \
+---/ ASP \
\ /
\__________/
Figure 5: Legacy Hostthe gateway router also has to support the two features, next hop selection and DNS server selection, which you can see in Section 6 🌸
the implementation and issues of NPTv6 are out of scope for this doc, but they're covered in Section 5 of [RFC6296] 📚
7.2. Coexistence Considerations
so non-MHMP hosts and MHMP hosts (aka hosts that support multi-prefix with the enhancements for source address selection) need to live together 🫶 the GW rtr may need to treat those hosts differently
one idea: the GW rtr identifies the hosts, gives non-MHMP hosts a single prefix, and gives MHMP hosts multiple prefixes ✨ then the GW rtr can do IPv6 NAT only for traffic from non-MHMP hosts when their source address isn't appropriate
another idea: the GW rtr could give multiple prefixes to both kinds of hosts, and still do IPv6 NAT for traffic from non-MHMP hosts when their source address isn't appropriate 💜
in scenarios 1 and 3, non-MHMP hosts can be placed behind the NAT box, and then they can still reach services through the NAT box 🧚
how to identify non-MHMP hosts and set up the NAT policy is outside the scope of this document 🙈
7.3. Policy Collision Consideration
when there are multiple policy distributors, a policy receiver might not follow every single policy it gets 😭 especially when one policy conflicts with another, because the receiver can't implement both of them
to solve or mitigate this, you need a prioritization rule that lines the policies up with the preferences of a trusted interface 👑 another option is to stop the receiver from accepting multiple policies at all. in that case, the policy distributors have to cooperate, and a single representative provider should distribute one merged policy 🎀
this document doesn't recommend any specific way to resolve policy collisions. it's expected that each implementation will decide how to handle conflicts for itself 💅 but if different implementations don't resolve them consistently, that could mess with interoperability and security trust boundaries 💀 future work is expected to tackle consistent policy resolution so this doesn't happen 🔥
8. Security Considerations
okay this section is SERIOUS bestie 😭🔥 in today's multihomed IPv4 networks, it's really hard to resolve or coordinate conflicts between the two upstream networks. and this problem is still there with IPv6, whether the hosts use provider-dependent or provider-independent addresses 💀
this document requires that MHMP solutions have functions that provide policy controls. new security threats can show up depending on the kind and form of the policy 🚨 the threats split into two parts: the policy receiver side and the policy distributor side 👑
a policy receiver may receive an evil policy from a policy distributor 😈 and a policy distributor should expect that some hosts in its network won't follow the distributed policy. as of writing, there are no known methods to resolve conflicts between the host's own policy (the policy receiver) and the policies from upstream providers (the policy provider) 😭 since this document is analyzing the problem space rather than proposing a solution, here are the problems we noticed:
Threats related to the policy distributor side:
The service provider should expect that there will be hosts that won't obey the received policy. one possible fix is to ingress-filter any packets that don't match the distributed policy and drop them. for route selection, packet forwarding or redirection can be another option. for source address selection, IPv6 NAT can be another option 🦋
in a multihomed multiple-provider network, nodes may be run by different organizations. administrators might need to control policies (and a node's behavior) independently of other administrators 💼 so access control policies need to be in place to restrict each administrator's access to only the nodes they're authorized to control 🔐
Threats related to the policy receiver side:
on the policy receiver side, who should be trusted to accept policies is a fundamental issue 🥺 how is trust established? and how can a network element make sure it can establish that trust before the network is fully configured? if a policy receiver trusts an untrusted network, it will end up with the unwanted and unauthorized policy described below 🙈
a policy receiver is exposed to threats from unauthorized policy, which can lead to session hijack, falsification, DoS, wiretapping, and phishing 😱 unauthorized policy here means a policy distributed from an entity that doesn't have the rights to do so. usually, only a site administrator and a network service provider have the rights to distribute these policies, along with IP address assignment and DNS server address notification 🧾 for source address selection, unauthorized policy can expose an IP address that normally wouldn't be exposed to an external server, which can be a privacy problem 👀
to solve or mitigate unauthorized policy, one approach is to limit the use of these policy distribution mechanisms, as described in the Section 4.4 of [RFC6731] 🛡️ for example, a policy should be preferred or accepted if it's delivered over a secure, trusted channel, such as a cellular data connection 📶 the proposed solutions are based on DHCP, so limiting local site communication (which is often used in WiFi access services) should be another solution or mitigation 🌈 for the DNS server selection issue, DNS Security (DNSSEC) can be another solution ✨ for source address selection, the ingress filter at the network service provider's router can be a solution 🫧
another threat is leakage of the policy and the privacy issues that come with it. especially when clients receive different policies from the network service provider, that difference gives hints about the host itself and can be useful for uniquely identifying the host 🕵️♀️ encrypting the communication channel and separating the communication channel per host can be solutions for this problem 🔒
the security threats related to IPv6 multihoming are described in [RFC4218] 💖
9. Contributors
the following people contributed to this document: Akiko Hattori, Arifumi Matsumoto, Frank Brockners, Fred Baker, Tomohiro Fujisaki, Jun-ya Kato, Shigeru Akiyama, Seiichi Morikawa, Mark Townsley, Wojciech Dec, Yasuo Kashimura, and Yuji Yamazaki 🌟 this document has also hugely benefited from input by Randy Bush, Brian Carpenter, and Teemu Savolainen 🫶✨
10. References
10.1. Normative References
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and
More-Specific Routes", RFC 4191, November 2005.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC6296] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Prefix
Translation", RFC 6296, June 2011.
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, September 2012.
[RFC6731] Savolainen, T., Kato, J., and T. Lemon, "Improved
Recursive DNS Server Selection for Multi-Interfaced
Nodes", RFC 6731, December 2012.
[RFC7078] Matsumoto, A., Fujisaki, T., and T. Chown, "Distributing
Address Selection Policy Using DHCPv6", RFC 7078, January
2014.10.2. Informative References ✨
okay bestie, this is the reading list 📚🫶 these ones aren't required to build the protocol, but they're the background drama that explains why everything in here exists. the big cast includes NAT, DHCP, Multihoming, Shim6, and more 💅
[RFC3022]Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 🦋[RFC3442]Lemon, T., Cheshire, S., and B. Volz, "The Classless Static Route Option for Dynamic Host Configuration Protocol (DHCP) version 4", RFC 3442, December 2002. 🌸[RFC3582]Abley, J., Black, B., and V. Gill, "Goals for IPv6 Site-Multihoming Architectures", RFC 3582, August 2003. 🧚[RFC3646]Droms, R., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003. 🍓[RFC4116]Abley, J., Lindqvist, K., Davies, E., Black, B., and V. Gill, "IPv4 Multihoming Practices and Limitations", RFC 4116, July 2005. 🌈[RFC4218]Nordmark, E. and T. Li, "Threats Relating to IPv6 Multihoming Solutions", RFC 4218, October 2005. 💀[RFC4960]Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007. ✨[RFC5206]Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End-Host Mobility and Multihoming with the Host Identity Protocol", RFC 5206, April 2008. 👑[RFC5220]Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, "Problem Statement for Default Address Selection in Multi-Prefix Environments: Operational Issues of RFC 3484 Default Rules", RFC 5220, July 2008. 🔥[RFC5245]Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 💜[RFC5533]Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming Shim Protocol for IPv6", RFC 5533, June 2009. 🎀[RFC6106]Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. 🌸[TR-124]The Broadband Forum, "TR-124, Functional Requirements for Broadband Residential Gateway Devices", Issue: 2, May 2010,http://www.broadband-forum.org/technical/download/TR-124_Issue-2.pdf. 🦋[TR069]The Broadband Forum, "TR-069, CPE WAN Management Protocol v1.1", Version: Issue 1 Amendment 2, December 2007,http://www.broadband-forum.org/technical/download/TR-069_Amendment-2.pdf. 🧚
Authors' Addresses ✨
The squad behind this doc, and how to reach them 💖
Ole Troan (editor) Cisco Oslo Norway
EMail: ot@cisco.com 💅
David Miles Google Fiber Mountain View, CA USA
EMail: davidmiles@google.com 🫶
Satoru Matsushima Softbank Telecom Tokyo Japan
EMail: satoru.matsushima@g.softbank.co.jp ✨
Tadahisa Okimoto NTT West Osaka Japan
EMail: t.okimoto@west.ntt.co.jp 🌈
Dan Wing Cisco 170 West Tasman Drive San Jose USA
EMail: dwing@cisco.com 👑
that's the whole RFC, bestie 🎀🦋💖
📦 where this page comes from
- ietf: rfc7157 2014-03
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms