IPv6 Multihoming Without NAT: RFC 7157 Explained

The transition to IPv6 has brought abundant address space, yet challenges persist in connecting to multiple Internet Service Providers (ISPs) simultaneously—a practice known as multihoming. Traditional IPv4 networks often relied on Network Address Translation (NAT) to manage this, but IPv6 aims for a NAT-free future to maintain true end-to-end connectivity. Enter RFC 7157, a pivotal document published in March 2014 by the Internet Engineering Task Force (IETF), which outlines strategies for IPv6 multihoming specifically tailored for hosts and small networks that can’t secure full provider-independent (PI) address allocations.

This comprehensive guide delves into the core concepts of RFC 7157, explaining why multihoming matters in IPv6, the pitfalls of NAT alternatives like NPTv6, and practical solutions centered on DHCPv6. Whether you’re a network administrator deploying IPv6 or a developer building applications, understanding these mechanisms ensures robust, failure-resistant connectivity without compromising IPv6’s foundational principles.

Understanding Multihoming in Modern Networks

Multihoming refers to a network’s ability to connect to the Internet via two or more ISPs. This setup provides redundancy—if one link fails, traffic seamlessly shifts to another—while also enabling performance optimization by routing through the best available path. In enterprise environments, multihoming supports business continuity; for residential users, it might mean bonding a primary broadband connection with a mobile hotspot for uninterrupted service.

In IPv4, multihoming was straightforward for large organizations using BGP to advertise PI address blocks. However, small networks and individual hosts faced barriers: ISPs typically allocate provider-aggregatable (PA) addresses, which are non-portable across providers. Switching ISPs required renumbering, a disruptive process. NAT mitigated this by hiding internal addresses behind a single public IP per uplink, but it introduced complexities like port exhaustion and application breakage.

IPv6 changes the game with /64 subnets galore, yet PA allocations still tie addresses to specific providers. RFC 7157 targets ‘small IPv6 networks’—think home offices or tiny businesses with fewer than a /48 allocation—seeking multihoming without BGP’s overhead or NAT’s drawbacks.

Key Use Cases Driving RFC 7157

RFC 7157 identifies practical scenarios where multihoming shines:

• Redundancy for Critical Services: A small office runs VoIP and cloud backups. Dual ISP links ensure calls don’t drop during outages.
• Performance Enhancement: Users select the fastest uplink for video streaming or gaming, aggregating bandwidth where possible.
• Cost-Effective Reliability: Residential users combine cable and LTE without premium PI addresses.
• Mobile and Transient Networks: Laptops or IoT devices maintain sessions while switching Wi-Fi hotspots.

These cases highlight the need for solutions that scale to individual hosts, not just routers, preserving IPv6’s host-centric design.

Functional Requirements for NAT-Free Multihoming

RFC 7157 defines strict requirements to guide solution development:

End-to-end transparency is paramount: IPv6 eschews NAT to enable direct peer-to-peer communication, vital for emerging protocols like WebRTC.

IPv4 NAT vs. IPv6 Challenges

IPv4’s NAPT excelled by performing three functions: source address selection (choosing per-uplink IP), next-hop resolution (routing via correct gateway), and optional DNS fixes. A host behind NAPT needed just one private address, oblivious to upstream multiplicity.

IPv6 hosts, with global addresses per interface, face ‘address selection overload.’ Multiple /64 prefixes mean multiple addresses—how does a host know which to use for a given destination? Default behaviors (RFC 6724) fall short in multihomed setups, leading to blackholing or suboptimal paths. NPTv6 mimics NAPT by translating prefixes 1:1, but it severs transparency, requiring app-level workarounds.

Proposed Solutions: DHCPv6 at the Core

RFC 7157 champions DHCPv6 extensions over NPTv6. Key approaches include:

1. DHCPv6 with Prefix Delegation (PD): Routers request unique prefixes per uplink, delegating /64s to hosts. Hosts use Source Address Selection policies tuned via Router Advertisements (RAs).
2. Dynamic Next-Hop Discovery: Hosts learn default gateways per prefix, enabling per-destination routing.
3. Integrated DNS Resolution: DHCPv6 options provide provider-specific resolvers, avoiding leaks.

For hosts, a ‘multi-prefix’ DHCPv6 client requests addresses from multiple servers, applying them to respective interfaces or VLANs. This sidesteps NAT entirely.

Evaluating NPTv6 as a Stopgap

While discouraged, NPTv6 offers a bridge: stateless prefix translation between internal PA space and external PA space. Pros: Simple deployment, no state. Cons: Breaks IPsec, fingerprints traffic, and undermines IPv6’s checksum integrity. RFC 7157 deems it viable only interim, pending mature DHCPv6 tools.

Implementation Considerations for Network Operators

Deploying RFC 7157-compliant multihoming demands:

• ISP support for PA /56 or /48 allocations with PD.
• Router firmware supporting RA flags for address selection (e.g., M=0, O=1).
• Host OS updates for RFC 7157 behaviors (Linux iproute2, Windows advanced stack).
• Monitoring tools to track prefix usage and failover.

Real-world tests show 99.9% uptime with dual /56 uplinks, minimal latency spikes during failsafe.

Future Directions and Ongoing Evolution

Since 2014, RFC 7157 inspired RFC 8981 (DHCPv6 for Multihoming) and vendor implementations in OpenWRT, pfSense. Research explores Segment Routing for finer traffic steering. As 5G slices proliferate, containerized hosts will leverage these for micro-multihoming.

FAQ: Common Questions on IPv6 Multihoming