Deploy360 1 April 2014

New RFC 7157 Out About IPv6 Multihoming Without NAT

By Dan YorkDirector, Internet Technology

IETF LogoWhat are the challenges with connecting a small network or device to multiple “upstream” IPv6 networks? How can you set up such a network while avoiding the Network Address Translation (NAT) required in IPv4?  To address these questions and provide useful guidance, a group of engineers wrote a document that was just published as RFC 7157, “IPv6 Multihoming without Network Address Translation that is available at:

http://tools.ietf.org/html/rfc7157

The document has an abstract of:

Network Address and Port Translation (NAPT) works well for conserving global addresses and addressing multihoming requirements because an IPv4 NAPT router implements three functions: source address selection, next-hop resolution, and (optionally) DNS resolution. For IPv6 hosts, one approach could be the use of IPv6-to-IPv6 Network Prefix Translation (NPTv6). However, NAT and NPTv6 should be avoided, if at all possible, to permit transparent end-to-end connectivity. In this document, we analyze the use cases of multihoming. We also describe functional requirements and possible solutions for multihoming without the use of NAT in IPv6 for hosts and small IPv6 networks that would otherwise be unable to meet minimum IPv6-allocation criteria. We conclude that DHCPv6-based solutions are suitable to solve the multihoming issues described in this document, but NPTv6 may be required as an intermediate solution.

The document goes into quite some detail for both multihomed hosts (individual computers or servers) and multihomed networks and provides many good points to consider in considering how to set up multihomed environments.  It also includes many links for those interested in learning more.  Definitely worth reading for anyone looking to configure IPv6 to work with multiple Internet connections.

Disclaimer: Viewpoints expressed in this post are those of the author and may or may not reflect official Internet Society positions.

Related articles

Improving Technical Security 15 March 2019

DNS Privacy Frequently Asked Questions (FAQ)

We previously posted about how the DNS does not inherently employ any mechanisms to provide confidentiality for DNS transactions,...

Improving Technical Security 14 March 2019

Introduction to DNS Privacy

Almost every time we use an Internet application, it starts with a DNS (Domain Name System) transaction to map...

Improving Technical Security 13 March 2019

IPv6 Security for IPv4 Engineers

It is often argued that IPv4 practices should be forgotten when deploying IPv6, as after all IPv6 is a...