NAT64 RFCs Published Last Week

By stretch | Monday, May 2, 2011 at 3:17 a.m. UTC

Several RFCs relevant to IPv6 were published last week, the majority of them pertaining to NAT64. The first initiative to produce an IPv4/IPv6 translation mechanism, NAT-PT, was deprecated in July of 2007 per RFC 4966. Its less ambitious successor dubbed NAT64 has been developed in the years since and has now moved to the RFC stage. Following is a brief description of each of the new NAT64 RFCs released last week.

RFC 6144: Framework for IPv4/IPv6 Translation

This note describes a framework for IPv4/IPv6 translation. This is in the context of replacing Network Address Translation - Protocol Translation (NAT-PT), which was deprecated by RFC 4966, and to enable networks to have IPv4 and IPv6 coexist in a somewhat rational manner while transitioning to an IPv6 network.

RFC 6144 embodies the conceptual framework for NAT64. Section 2 describes the eight likely scenarios in which NAT64 might be deployed, although section 5 notes that not all possible scenarios have been considered. Section 3 outlines the function of the translation components described in the companion RFCs. It also references RFC 6052, IPv6 Addressing of IPv4/IPv6 Translators, which is worth reading as well.

RFC 6145: IP/ICMP Translation Algorithm

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 2765.

RFC 6145 deals with the actual translation of IP and ICMP packets. It has been adapted from and obsoletes RFC 2765; significant changes are noted in section 2. Two translation modes are defined: stateless, which employs a designated IPv6 prefix to map IPv4 addresses, and stateful, which requires the maintenance of a translation table similar to IPv4-only NAT.

RFC 6146: Stateful NAT64

This document describes stateful NAT64 translation, which allows IPv6-only clients to contact IPv4 servers using unicast UDP, TCP, or ICMP. One or more public IPv4 addresses assigned to a NAT64 translator are shared among several IPv6-only clients. When stateful NAT64 is used in conjunction with DNS64, no changes are usually required in the IPv6 client or the IPv4 server.

RFC 6146 details the operation of stateful NAT64. Section 1.2.2 provides a handy walkthrough of the process.

RFC 6147: DNS64

DNS64 is a mechanism for synthesizing AAAA records from A records. DNS64 is used with an IPv6/IPv4 translator to enable client-server communication between an IPv6-only client and an IPv4-only server, without requiring any changes to either the IPv6 or the IPv4 node, for the class of applications that work through NATs. This document specifies DNS64, and provides suggestions on how it should be deployed in conjunction with IPv6/IPv4 translators.

RFC 6147 discusses the translation of A (IPv4) and AAAA (IPv6) DNS records used in conjunction with NAT64.

Other New IPv6 RFCs

  • RFC 6156 - Traversal Using Relays around NAT (TURN) Extension for IPv6
  • RFC 6157 - IPv6 Transition in the Session Initiation Protocol (SIP)
  • RFC 6204 - Basic Requirements for IPv6 Customer Edge Routers

About the Author

Jeremy Stretch is a network engineer living in the Raleigh-Durham, North Carolina area. He is known for his blog and cheat sheets here at Packet Life. You can reach him by email or follow him on Twitter.

Posted in IPv6, News

Comments


Robin Kumar (guest)
May 2, 2011 at 3:32 p.m. UTC

I was searching for vrf lite and incidently landed on to your site and blew up my mind. You have suddenly became my role model for networking. You know about everything. How a single man can know all the technologies.


henrique (guest)
July 12, 2011 at 4:00 a.m. UTC

Well, everyone is so scared that there is only one reply to this bunch of RFC! =)
I do prefer the IPv4.1, by the way.

Comments have closed for this article due to its age.