RFC 2766
Network Address Translation - Protocol Translation (NAT-PT)
RFC 2766: Network Address Translation - Protocol Translation (NAT-PT) 🦋
Part 1 of 5
The header facts: this is from the Network Working Group, written by G. Tsirtsis (BT) and P. Srisuresh (Campio Communications). It's a Standards Track doc, dated February 2000. The header doesn't list anything it obsoletes or updates, so there's nothing to cross-check. 🎀
Status of This Memo 📋
okay so this doc is an Internet standards track protocol for the Internet community, and it's asking for discussion and suggestions for improvements 💬 For the standardization state and status of this protocol, check the current edition of the "Internet Official Protocol Standards" (STD 1) 🔍 Distribution of this memo is unlimited ✨
Copyright Notice ©️
Copyright (C) The Internet Society (2000). All Rights Reserved. 🔒
Abstract 🌸
this doc specifies an IPv4-to-IPv6 transition mechanism, on top of the ones already specified in [TRANS] 💖 the goal is transparent routing (as defined in [NAT-TERM]) so end-nodes in the V6 realm can talk to end-nodes in the V4 realm, and the other way around 🔁 it does this by mixing Network Address Translation with Protocol Translation, which is giving main character energy 👑 the scheme does not mandate dual-stacks (IPv4 and V6 protocol support) or special routing requirements (like needing tunneling support) on end nodes 🙌 it's built on the address translation idea from [NAT-TERM] and the V6/V4 protocol translation idea from [SIIT] 🧚
Acknowledgements 🫶
major thank-you to Pedro Marques for reviewing an earlier version of this memo 💜 also huge thanks to Alan O'Neill and Martin Tatham, because the mechanism in this doc was originally developed through discussions with them 🙏
Table of Contents 📑
1. Introduction.................................................. 2
2. Terminology................................................... 3
2.1 Network Address Translation (NAT)......................... 4
2.2 NAT-PT flavors............................................ 4
2.2.1 Traditional-NAT-PT................................... 4
2.2.2 Bi-directional-NAT-PT................................ 5
2.3 Protocol Translation (PT)................................. 5
2.4 Application Level Gateway (ALG)........................... 5
2.5 Requirements.............................................. 5
3. Traditional-NAT-PT operation (V6 to V4)....................... 6
3.1 NAT-PT Outgoing Sessions.................................. 6
3.2 NAPT-PT Outgoing Sessions................................. 7
4. Use of DNS-ALG for Address assignment......................... 8
4.1 V4 Address Assignment for Incoming Connections (V4 to V6). 9
4.2 V4 Address Assignment for Outgoing Connections (V6 to V4). 11
5. Protocol Translation Details.................................. 12
5.1 Translating IPv4 Headers to IPv6 Headers.................. 13
5.2 Translating IPv6 Headers to IPv4 Headers.................. 13
5.3 TCP/UDP/ICMP Checksum Update.............................. 13
6. FTP Application Level Gateway (FTP-ALG) Support............... 14
6.1 Payload modifications for V4 originated FTP sessions...... 15
6.2 Payload modifications for V6 originated FTP sessions...... 16
6.3 Header updates for FTP control packets.................... 16
7. NAT-PT Limitations and Future Work............................ 17
7.1 Topology Limitations...................................... 17
7.2 Protocol Translation Limitations.......................... 17
7.3 Impact of Address Translation............................. 18
7.4 Lack of End-to-End Security............................... 18
7.5 DNS Translation and DNSSEC................................ 18
8. Applicability Statement....................................... 18
9. Security Considerations....................................... 19
10. References................................................... 19
Authors' Addresses............................................... 20
Full Copyright Statement......................................... 211. Introduction ✨
okay so IPv6 is the new version of IP, basically a glow-up of IPv4, which was designed back in the 1970s 🕰️ IPv6 has a bunch of perks that set it up for future Internet growth and make IP configuration and administration way simpler 💅 it has a bigger address space, an addressing model that promotes aggressive route aggregation, and a powerful autoconfiguration mechanism 🔥 over time, Internet growth and the need for a plug-and-play solution are expected to lead to widespread IPv6 adoption 🌈
but first there's expected to be a long transition period where IPv4 and IPv6 nodes have to coexist and communicate 🫠 that means we need a strong, flexible set of IPv4-to-IPv6 transition and coexistence mechanisms during this stage 🎀
the SIIT proposal [SIIT] is a protocol translation mechanism that lets IPv6-only and IPv4-only nodes talk to each other by doing protocol independent translation of IPv4 and IPv6 datagrams 🦋 it needs no state information for the session 🧠 SIIT assumes V6 nodes are given a V4 address for talking to V4 nodes, but it doesn't specify how those addresses get assigned 🤷♀️
NAT-PT uses a pool of V4 addresses that get handed out to V6 nodes dynamically, as sessions start across V4-V6 boundaries 🌊 the V4 addresses are assumed to be globally unique 💎 NAT-PT with private V4 addresses is outside the scope of this document and is left for further study 📚 NAT-PT binds addresses in the V6 network with addresses in the V4 network and the other way around, to provide transparent routing [NAT-TERM] between address realms 🤝 this needs no changes to end nodes, and IP packet routing is completely transparent [NAT-TERM] to them 🙈 the catch is that NAT-PT has to track the sessions it supports, and inbound and outbound datagrams for a session must go through the same NAT-PT router 🚧 honestly, the topology restrictions on NAT-PT match the ones described for V4 NATs in [NAT-TERM] 💅 protocol translation details from [SIIT] are used to extend address translation with protocol syntax/semantics translation 🔁 a detailed applicability statement for NAT-PT is at the end of this document in section 7 📖
✨ the combo move: by mixing SIIT protocol translation with the dynamic address translation powers of NAT and the right ALGs, NAT-PT becomes a complete solution that lets a big pile of commonly used applications interoperate between IPv6-only nodes and IPv4-only
there's one fundamental assumption: NAT-PT is only to be use when no other native IPv6 or IPv6 over IPv4 tunneled means of communication is possible 🙅♀️ in other words, the aim is to only use translation between IPv6 only nodes and IPv4 only nodes, and translation between IPv6 only nodes and the IPv4 part of a dual stack node should be avoided in favor of the other alternatives 🫶
2. Terminology 📖
most of the terms in this doc are borrowed pretty much as-is from [NAT-TERM] 💕 the following list has the terms that are specific to this document 🍓
2.1. Network Address Translation (NAT) 🌐
the term NAT here is very similar to the IPv4 NAT described in [NAT-TERM], but it's not identical 👀 IPv4 NAT translates one IPv4 address into another IPv4 address, but in this document, NAT means translating an IPv4 address into an IPv6 address and vice versa 🔄
the V4 NAT [NAT-TERM] gives routing between private V4 and external V4 address realms 🏠 NAT in this document gives routing between a V6 address realm and an external V4 address realm 🌍
2.2. NAT-PT flavors 🍦
just like there are various flavors of V4 NAT in [NAT-TERM], this doc identifies the following NAT-PT variations 🎨
2.2.1. Traditional NAT-PT 🧁
Traditional-NAT-PT lets hosts in a V6 network access hosts in the V4 network 🚪 in Traditional-NAT-PT, sessions are uni-directional and outbound from the V6 network 🛫 that's the opposite of Bi-directional-NAT-PT, which allows sessions in both the inbound and outbound directions 🔀
just like with V4 traditional-NAT, Traditional-NAT-PT has two variations: Basic-NAT-PT and NAPT-PT 👯
with Basic-NAT-PT, a block of V4 addresses is set aside for translating the addresses of V6 hosts when they start sessions to V4 hosts in an external domain 🎁 for packets going outbound from the V6 domain, the source IP address and related fields like the IP, TCP, UDP and ICMP header checksums get translated 💫 for inbound packets, the destination IP address and the checksums listed above get translated 🔧
NAPT-PT takes translation one step further by also translating transport identifiers (like TCP and UDP port numbers and ICMP query identifiers) ✨ this lets the transport identifiers of a bunch of V6 hosts get multiplexed into the transport identifiers of one assigned V4 address 🪄 so basically a whole set of V6 hosts can share a single V4 address 🫂 note that NAPT-PT can be combined with Basic-NAT-PT, so a pool of external addresses gets used together with port translation 🏊
for packets going outbound from the V6 network, NAPT-PT translates the source IP address, the source transport identifier, and related fields like the IP, TCP, UDP and ICMP header checksums 📤 the transport identifier can be either a TCP/UDP port or an ICMP query ID 🆔 for inbound packets, the destination IP address, the destination transport identifier, and the IP and transport header checksums get translated 📥
2.2.2. Bi-Directional-NAT-PT ↔️
with Bi-directional-NAT-PT, sessions can be started from hosts in the V4 network as well as the V6 network 🙌 V6 network addresses are bound to V4 addresses, either statically or dynamically, as connections get set up in either direction 🔗 the name space (meaning their Fully Qualified Domain Names) between hosts in V4 and V6 networks is assumed to be end-to-end unique 🏷️ hosts in the V4 realm reach V6-realm hosts by using DNS for address resolution 🔍 a DNS-ALG [DNS-ALG] must be employed together with Bi-Directional-NAT-PT to make name-to-address mapping work 🪪 specifically, the DNS-ALG has to be able to translate V6 addresses in DNS queries and responses into their V4-address bindings, and vice versa, as DNS packets travel between V6 and V4 realms 🛸
2.3. Protocol Translation (PT) 🔁
PT in this document means translating an IPv4 packet into a semantically equivalent IPv6 packet, and vice versa 💞 the protocol translation details are described in [SIIT] 📘
2.4. Application Level Gateway (ALG) 🚪
an Application Level Gateway (ALG) [NAT-TERM] is an application specific agent that lets a V6 node talk to a V4 node, and the other way around 🗣️ some applications carry network addresses in their payloads 📦 NAT-PT is application unaware and doesn't snoop the payload 🙈 an ALG can work together with NAT-PT to support many of these applications 🫶
2.5. Requirements 📜
the keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they show up in this document, are to be interpreted as described in [KEYWORDS] 🔑✨
Part 2 is coming next, bestie, so stay tuned 💖🧚
3. Traditional-NAT-PT Operation (V6 to V4) ✨
okay so NAT-PT has a lowkey iconic solution built on transparent routing [NAT-TERM] plus address and protocol translation 🦋 It lets a huge pile of apps in the V6 and V4 realms talk to each other without any of those apps needing to change a single thing. no cap, main character energy 💅
Here's how traditional-NAT-PT works, and how a connection can get started from a host in the IPv6 domain to a host in the IPv4 domain through a traditional-NAT-PT 🎀
3.1 Basic-NAT-PT Operation
[IPv6-B]-+
| +==============+
[IPv6-A]-+-[NAT-PT]---------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 1: IPv6 to IPv4 communication Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24 🌸
The V4 addresses in the pool could be handed out one-to-one to the V6 addresses of the V6 end nodes, in which case you'd need as many V4 addresses as V6 end points. In this document we assume the V6 network has fewer V4 addresses than V6 end nodes, so dynamic address allocation is required for at least some of them. that's the whole vibe of this section 🫶
Say IPv6 Node A wants to talk to IPv4 Node C. Node A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 and Destination
Address, DA = PREFIX::132.146.243.30NOTE: The prefix PREFIX::/96 is advertised in the stub domain by the NAT-PT, and packets addressed to this PREFIX will be routed to the NAT-PT. The pre-configured PREFIX only needs to be routable within the IPv6 stub domain, so it can be any routable prefix that the network administrator chooses. 🧚
The packet gets routed via the NAT-PT gateway, where it's translated to IPv4.
If the outgoing packet is not a session initialisation packet, the NAT-PT SHOULD already have stored some state about the related session, including the assigned IPv4 address and other parameters for the translation. If this state does not exist, the packet SHOULD be silently discarded. 🙈
If the packet IS a session initialisation packet, the NAT-PT locally allocates an address (e.g: 120.130.26.10) from its pool and the packet gets translated to IPv4. The translation parameters are cached for the duration of the session, and the IPv6 to IPv4 mapping is retained by NAT-PT. ✨
The resulting IPv4 packet has:
SA=120.130.26.10
DA=132.146.243.30Any returning traffic gets recognised as belonging to the same session by NAT-PT. NAT-PT uses the state information to translate the packet, and the resulting addresses are:
SA=PREFIX::132.146.243.30
DA=FEDC:BA98::7654:3210Note that this packet can now be routed inside the IPv6-only stub network as normal. it's giving seamless 💖
3.2 NAPT-PT Operation
NAPT-PT, which stands for "Network Address Port Translation + Protocol Translation", lets V6 nodes talk to V4 nodes transparently using a single V4 address. The TCP/UDP ports of the V6 nodes get translated into TCP/UDP ports of the registered V4 address. 🦋
NAT-PT support is limited to TCP, UDP and other port-multiplexing kinds of applications, but NAPT-PT fixes a problem that's baked into NAT-PT. NAT-PT falls flat when the pool of V4 addresses assigned for translation runs out. Once the address pool is exhausted, newer V6 nodes can't establish sessions with the outside world anymore 💀 NAPT-PT, on the other hand, allows for a maximum of 63K TCP and 63K UDP sessions per IPv4 address before there are no TCP and UDP ports left to assign. the ports really do be going a long way 🌈
To tweak the example in figure 1, we could put NAPT-PT on the border router (instead of NAT-PT) and map all V6 addresses to a single V4 address, 120.130.26.10. 🎀
IPv6 Node A would establish a TCP session with IPv4 Node C like this:
Node A creates a packet with:
Source Address, SA=FEDC:BA98::7654:3210 , source TCP port = 3017 and
Destination Address, DA = PREFIX::132.146.243.30, destination TCP
port = 23.When the packet reaches the NAPT-PT box, NAPT-PT assigns one of the TCP ports from the assigned V4 address to translate the tuple of (Source Address, Source TCP port), like so:
SA=120.130.26.10, source TCP port = 1025 and
DA=132.146.243.30, destination TCP port = 23.The returning traffic from 132.146.243.30, TCP port 23 gets recognised as belonging to the same session and translated back to V6:
SA = PREFIX::132.146.243.30, source TCP port = 23;
DA = FEDC:BA98::7654:3210 , destination TCP port = 3017Inbound NAPT-PT sessions are restricted to one server per service, assigned via static TCP/UDP port mapping. For example, Node [IPv6-A] in figure 1 may be the only HTTP server (port 80) in the V6 domain. Then Node [IPv4-C] sends a packet:
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.10, destination TCP port = 80NAPT-PT translates this packet to:
SA=PREFIX::132.146.243.30, source TCP port = 1025
DA=FEDC:BA98::7654:3210, destination TCP port = 80In the example above, all sessions that reach NAPT-PT with a destination port of 80 get redirected to the same node, [IPv6-A]. one node, one port, zero confusion 👑
4. Use of DNS-ALG for Address Assignment ✨
An IPv4 address is assigned by NAT-PT to a V6 node when NAT-PT identifies the start of a session, whether inbound or outbound. Spotting the start of a new inbound session works differently from spotting an outbound one. The same V4 address pool gets used for assignment to V6 nodes either way, whether the session is started outbound from a V6 node or inbound from a V4 node. 🌸
Policies deciding what types of sessions are allowed, in which direction, and to or from which nodes are out of scope for this document. not our tea today 🙅♀️
IPv4 name-to-address mappings live in the DNS as "A" records. IPv6 name-to-address mappings are, at the moment, held in the DNS as "AAAA" records. "A6" records have also been defined, but at the time of writing they're neither fully standardized nor deployed. 🧚
The DNS-ALG's principle of operation in this section is the same with either "AAAA" or "A6" records. The only difference is that resolving a name with "A6" records may need more than one query-reply pair. In that case the DNS-ALG SHOULD track all the replies in the transaction before translating an "A6" record into an "A" record. 🤓
One of the goals of the NAT-PT design is to only use translation when there's no other means of communication, such as native IPv6 or some form of tunneling. For the following discussion, NAT-PT may have native IPv6 and/or tunneled IPv6 connectivity on top of the IPv4 connectivity it already has. 💜
4.1 V4 Address assignment for incoming connections (V4 to V6)
[DNS]--+
| [DNS]------[DNS]-------[DNS]
[IPv6-B]-+ | |
| +==============+ |
[IPv6-A]-+----[NAT-PT]------| IPv4 network |--[IPv4-C]
| +==============+
(pool of v4 addresses)
Figure 2: IPv4 to IPv6 communication Node IPv6-A has an IPv6 address -> FEDC:BA98::7654:3210
Node IPv6-B has an IPv6 address -> FEDC:BA98::7654:3211
Node IPv4-C has an IPv4 address -> 132.146.243.30NAT-PT has a pool of addresses including the IPv4 subnet 120.130.26/24 🎀
In figure 2, when Node C's name resolver sends a name lookup request for Node A, the lookup query goes to the DNS server on the V6 network. Since NAT-PT sits on the border router between the V4 and V6 networks, this request datagram traverses the NAT-PT router. The DNS-ALG on the NAT-PT device rewrites DNS queries for A records going into the V6 domain as follows. (A TCP/UDP DNS packet is recognised by the fact that its source or destination port number is 53.) 💅
- a) For Node Name to Node Address query requests: change the query type from
"A"to"AAAA"or"A6". - b) For Node Address to Node Name query requests: replace the string
IN-ADDR.ARPAwith the stringIP6.INT. Replace the V4 address octets (in reverse order) preceding the stringIN-ADDR.ARPAwith the corresponding V6 address octets (if a map exists), in reverse order.
Going the other way, when a DNS response travels from the DNS server on the V6 network to the V4 node, the DNS-ALG intercepts the DNS packet again and:
- a) Translates DNS responses for
"AAAA"or"A6"records into"A"records (only translating"A6"records once the name has been completely resolved). - b) Replaces the V6 address resolved by the V6 DNS with the V4 address internally assigned by the NAT-PT router.
If no V4 address has been assigned to this V6 node yet, NAT-PT assigns one at this point. 🦋 Say IPv4-C tries to start a session with node IPv6-A by doing a name lookup ("A" record) for Node-A. The name query goes to the local DNS, and from there it's propagated to the DNS server of the IPv6 network. The DNS-ALG intercepts it and translates the "A" query into an "AAAA" or "A6" query, then forwards it to the DNS server in the IPv6 network, which replies as follows. (The example uses AAAA records for convenience.)
Node-A AAAA FEDC:BA98::7654:3210,The DNS server returns this, and the DNS-ALG intercepts it and translates it to:
Node-A A 120.130.26.1The DNS-ALG also holds the mapping between FEDC:BA98::7654:3210 and 120.130.26.1 in NAT-PT. The "A" record is then returned to Node-C, and Node-C can now initiate a session like this:
SA=132.146.243.30, source TCP port = 1025 and
DA=120.130.26.1, destination TCP port = 80The packet is routed to NAT-PT, which already holds a mapping between FEDC:BA98::7654:3210 and 120.130.26.1, so it can translate the packet to:
SA=PREFIX::132.146.243.30, source TCP port = 1025
DA=FEDC:BA98::7654:3210, destination TCP port = 80And the communication can proceed as normal. 🫶
The TTL values on all DNS resource records (RRs) passing through NAT-PT SHOULD be set to 0, so DNS servers and clients don't cache temporarily assigned RRs. Heads up though: because some buggy DNS client implementations exist, a value of 1 might work better in some cases. TTL values should be left unchanged for statically mapped addresses. ⏰
Address mappings for incoming sessions, as described above, are open to denial of service attacks. One can make multiple queries for nodes residing in the V6 network, causing the DNS-ALG to map all V4 addresses in NAT-PT and thereby block legitimate incoming sessions. 😭 So address mappings for incoming sessions should time out to minimise the effect of denial of service attacks. Additionally, one IPv4 address (using NAPT-PT, see 3.2) could be reserved for outgoing sessions only, so such attacks have less effect on outgoing sessions. this one is seriously important, bestie, don't skip it 🚨
4.2. V4 Address assignment for outgoing connections (V6 to V4) 🌸
okay so V6 nodes learn the address of V4 nodes from either the DNS server in the V4 domain or the DNS server inside the V6 network 🧚 we recommend that DNS servers inside V6 domains keep a mapping of names to IPv6 addresses for internal nodes, and maybe cache some mappings for external nodes 💖 if the DNS server in the v6 domain already has the mapping for external V4 nodes, the DNS queries never cross the V6 domain, and that means you don't need DNS-ALG intervention at all, which is so clean 😭 otherwise, the queries cross the V6 domain and DNS-ALG gets involved 👀 we also recommend that external DNS servers in the V4 domain cache name mappings for external nodes (i.e., V4 nodes) only 💅 and zone transfers across IPv4 - IPv6 boundaries are strongly discouraged, so maybe don't go there, bestie 🙈
in the case of NAPT-PT, a TCP/UDP source port gets assigned from the registered V4 address the moment each new outbound session is detected ✨
we saw that a V6 node that needs to talk to a V4 node has to put a specific prefix (PREFIX::/96) in front of the IPv4 address of that V4 node 🎀 the technique above lets you use this PREFIX without configuring anything on the nodes, which is giving effortless 🫶
let's do another example from Figure 2! say Node-A wants to set up a session with Node-C 🦋 for this, Node-A starts by doing a name lookup ("AAAA" or "A6" record) for Node-C 🔍
since Node-C might have IPv6 and/or IPv4 addresses, the DNS-ALG on the NAT-PT device forwards the original AAAA/A6 query to the external DNS system unchanged, and also sends an A query for the same node 💅 if an AAAA/A6 record exists for the destination, that gets returned to NAT-PT, which forwards it, also unchanged, to the originating host ✨
if there is an A record for Node-C, the reply also comes back to NAT-PT 🌈 the DNS-ALG then translates the reply by adding the appropriate PREFIX and forwards it to the originating device, along with any IPv6 addresses it might have learned 🧚 so, if the reply is
NodeC A 132.146.243.30, it is translated to
NodeC AAAA PREFIX::132.146.243.30 or to
NodeC A6 PREFIX::132.146.243.30now Node A can use this address like any other IPv6 address, and the V6 DNS server can even cache it, as long as the PREFIX doesn't change 🥹💜
an issue here is how the V6 DNS server in the V6 stub domain talks to the V4 domain outside the V6 stub domain 😬 remember that there are no dual stack nodes here! the external V4 DNS server needs to point to a V4 address, part of the V4 pool of addresses available to NAT-PT 🍓 NAT-PT keeps a one-to-one mapping between this V4 address and the V6 address of the internal V6 DNS server 🫧 in the other direction, the V6 DNS server points to a V6 address formed by the IPv4 address of the external V4 DNS servers plus the prefix (PREFIX::/96) that indicates non IPv6 nodes 🔥 this mechanism can easily be extended to accommodate secondary DNS servers, so it's super flexible 💖
heads up: the scheme in this section impacts DNSSEC! see section 7.5 of this document for the details 🙈
5. Protocol Translation Details 🎀
okay, so the IPv4 and ICMPv4 headers are similar to their V6 counterparts, but a bunch of fields are either missing, have a different meaning, or have a different length 💅 NAT-PT SHOULD translate all IP/ICMP headers from v4 to v6 and vice versa, so that end-to-end IPv6 to IPv4 communication is possible 🦋 because of the address translation function and possible port multiplexing, NAT-PT SHOULD also make appropriate adjustments to the upper layer protocol (TCP/UDP) headers ✨ there's a separate section on FTP-ALG that describes the changes FTP-ALG would make to the FTP payload as an FTP packet travels from the V4 to V6 realm, or the other way around 🧚
protocol translation details are described in [SIIT], but there are some modifications required to SIIT, because NAT-PT also performs Network Address Translation 🌸
5.1. Translating IPv4 headers to IPv6 headers 💖
this is done exactly the same as in SIIT, apart from the following fields:
- Source Address: the low-order 32 bits are the IPv4 source address 🫶 the high-order 96 bits are the designated PREFIX for all v4 communications. Addresses using this PREFIX get routed to the NAT-PT gateway (
PREFIX::/96) 🌈 - Destination Address: NAT-PT retains a mapping between the IPv4 destination address and the IPv6 address of the destination node 🔍 the IPv4 destination address gets replaced by the IPv6 address retained in that mapping ✨
5.2. Translating IPv6 headers to IPv4 headers 🦋
this is done exactly the same as in SIIT, apart from the Source Address, which should be determined as follows:
- Source Address: NAT-PT retains a mapping between the IPv6 source address and an IPv4 address from the pool of IPv4 addresses available 🍓 the IPv6 source address gets replaced by the IPv4 address retained in that mapping 💅
- Destination Address: IPv6 packets that get translated have a destination address of the form
PREFIX::IPv4/96, so the low-order 32 bits of the IPv6 destination address are copied to the IPv4 destination address 🧚
5.3. TCP/UDP/ICMP Checksum Update 🔥
NAT-PT retains a mapping between an IPv6 address and an IPv4 address from the pool of IPv4 addresses available, and this mapping is used when translating packets that go through NAT-PT 🫧
the following sub-sections describe the TCP/UDP/ICMP checksum update procedure in NAT-PT, as packets get translated from V4 to V6 and vice versa 💜
5.3.1. TCP/UDP/ICMP Checksum Update from IPv4 to IPv6 ✨
UDP checksums, when set to a non-zero value, and the TCP checksum SHOULD be recalculated to reflect the address change from v4 to v6 💖 the incremental checksum adjustment algorithm may be borrowed from [NAT] 🎀 in the case of NAPT-PT, the TCP/UDP checksum should be adjusted to account for the address and TCP/UDP port changes going from V4 to V6 address 🦋
when the checksum of a V4 UDP packet is set to zero, NAT-PT MUST evaluate the checksum in its entirety for the V6-translated UDP packet 😭 if a V4 UDP packet with a checksum of zero arrives in fragments, NAT-PT MUST await all the fragments until they can be assembled into a single non-fragmented packet, and then evaluate the checksum before forwarding the translated V6 UDP packet 🫶
ICMPv6, unlike ICMPv4, uses a pseudo-header during checksum computation, just like UDP and TCP do 🌈 as a result, when the ICMPv6 header checksum is computed [SIIT], the checksum needs to be adjusted to account for the additional pseudo-header 🔍 also note: there may be adjustments required to the checksum due to changes in the source and destination addresses (and changes in TCP/UDP/ICMP identifiers in the case of NAPT-PT) of the payload carried within ICMP 🧚
5.3.2. TCP/UDP/ICMP Checksum Update from IPv6 to IPv4 💅
TCP and UDP checksums SHOULD be recalculated to reflect the address change from v6 to v4 🍓 the incremental checksum adjustment algorithm may be borrowed from [NAT] ✨ in the case of NAPT-PT, the TCP/UDP checksums should be adjusted to account for the address and TCP/UDP port changes going from V6 to V4 addresses 🌸 for UDP packets, optionally, the checksum may simply be changed to zero 🫧
the checksum calculation for a V4 ICMP header needs to be derived from the V6 ICMP header by running the checksum adjustment algorithm [NAT] to remove the V6 pseudo-header from the computation 🔥 the adjustment must also take into account changes to the checksum as a result of updates to the source and destination addresses (and transport ports in the case of NAPT-PT) made to the payload carried within ICMP 💖
6. FTP Application Level Gateway (FTP-ALG) Support 🦋
because an FTP control session carries, in its payload, the IP address and TCP port information for the data session, an FTP-ALG is required to provide application level transparency for this popular Internet application 👑
in the FTP application running on a legacy V4 node, the arguments to the FTP PORT command and the arguments in a successful PASV response include an IP V4 address and a TCP port, both represented in ASCII as h1,h2,h3,h4,p1,p2 🧚 however, [FTP-IPV6] suggests EPRT and EPSV command extensions to FTP, with the intent to eventually retire the use of the PORT and PASV commands 🌸 these extensions may be used on a V4 or V6 node 🎀 FTP-ALG, which makes transparent FTP between V4 and V6 nodes work, operates as follows 💅
6.1. Payload modifications for V4 originated FTP sessions 💜
a V4 host may or may not have the EPRT and EPSV command extensions implemented in its FTP application 🤷♀️ if a V4 host originates the FTP session and uses the PORT or PASV command, the FTP-ALG translates these commands into EPRT and EPSV commands, respectively, before forwarding them to the V6 node 🫶 likewise, an EPSV response from V6 nodes gets translated into a PASV response before being forwarded to V4 nodes ✨ the format of the EPRT and EPSV commands and the EPSV response may be specified as follows [FTP-IPV6]:
EPRT<space><d><net-prt><d><net-addr><d><tcp-port><d>
EPSV<space><net-prt>
(or)
EPSV<space>ALL
Format of EPSV response(Positive): 229 <text indicating
extended passive mode> (<d><d><d><tcp-port><d>)a PORT command from a V4 node gets translated into an EPRT command by setting the protocol <net-prt> field to AF #2 (IPV6), and by translating the V4 host Address (represented as h1,h2,h3,h4) into its NAT-PT assigned V6 address in string notation, as defined in [V6ADDR], in the <net-addr> field 🦋 the TCP port represented by p1,p2 in the PORT command must be specified as a decimal <tcp-port> in the EPRT command 💖 further, <tcp-port> translation may also be required in the case of NAPT-PT 🌈 a PASV command from a V4 node is translated into an EPSV command with the <net-prt> argument set to AF #2 🍓 an EPSV response from a V6 node is translated into a PASV response before being forwarded to the target V4 host 🫧
if a V4 host originated the FTP session and was using the EPRT and EPSV commands, the FTP-ALG simply translates the parameters to these commands, without altering the commands themselves ✨ the protocol Number <net-prt> field gets translated from AF #1 to AF #2 💅 the <net-addr> gets translated from the V4 address in ASCII to its NAT-PT assigned V6 address in string notation, as defined in [V6ADDR] 🔥 the <tcp-port> argument in the EPSV response requires translation only in the case of NAPT-PT 👑
6.2 Payload modifications for V6 originated FTP sessions 🎀
Okay, bestie, now the flip side! 💅 If a V6 host starts the FTP session, the FTP-ALG has two approaches it can take 👀
In the first approach, the FTP-ALG leaves the command strings EPRT and EPSV alone ✨. It just translates the <net-prt>, <net-addr> and <tcp-port> arguments from V6 into the V4 info that NAT-PT (or NAPT-PT) assigned. <tcp-port> only gets translated in the NAPT-PT case 🌸. Same deal for the EPSV response from the V4 node 🧚. This is the approach we recommend, because it keeps forward support for RFC 2428 🫶. The catch? V4 hosts are mandated to have their FTP application upgraded to support the EPRT and EPSV extensions, so they can reach V4 and V6 hosts alike 😭.
In the second approach, the FTP-ALG translates EPRT and EPSV (and their parameters) from the V6 node into the equivalent NAT-PT assigned V4 node info, then attaches that to PORT and PASV commands before forwarding to the V4 node 💖. And the other way around: a PASV response from a V4 node gets turned into an EPSV response before it's forwarded to the target V6 node 🦋. Now, the FTP-ALG can't translate the command EPSV ALL issued by V6 nodes 💀. So the V4 host that gets it might send back an error code saying the function isn't supported 🙈. That can make a lot of RFC 2428 compliant FTP applications just... fail, because RFC 2428 mandates EPSV support 😩. The big perk of this approach, though? It doesn't force any FTP upgrade requirements on V4 hosts 🔥.
6.3 Header updates for FTP control packets 🍓
Everything we've covered in the previous sections is based on ASCII encoded data 📝. Which means these translations can change the size of the packet 👀.
If the new size is the same as the old one, the only thing that needs fixing is the TCP checksum 🧼. If the size is different, the TCP sequence numbers should also change to reflect the new length of the FTP control session payload 🔢. The IP packet length field in the V4 header (or the IP payload length field in the V6 header) should change too, so it matches the new payload size 📏. The FTP-ALG uses a table to correct the TCP sequence and acknowledgement numbers in the TCP header for control packets, in both directions 🗂️.
Each table entry should have the source address, source data port, destination address and destination data port for the V4 and V6 portions of the session 🧭, plus a sequence number delta for outbound control packets and a sequence number delta for inbound control packets 💜.
Here's the math, lowkey simple but so important ✨. The sequence number for an outbound control packet goes up by the outbound sequence number delta, and the acknowledgement number for that same outbound packet goes down by the inbound sequence number delta 📉📈. And for an inbound packet, the sequence number goes up by the inbound sequence number delta, while its acknowledgement number goes down by the outbound sequence number delta 🦋. Precision is everything, periodt 💅.
7. NAT-PT Limitations and Future Work 🥺
All the limitations that come with NAT [NAT-TERM] also come with NAT-PT 🙈. Here are the most important ones in detail, plus a few that are unique to NAT-PT 💖.
7.1 Topology limitations 🗺️
NAT-PT has some limitations you need to know about 🚧. It is mandatory that all requests and responses for a session get routed through the same NAT-PT router 🛣️. One way to guarantee this is to run NAT-PT on a border router that's unique to a stub domain, where every IP packet either comes from that domain or is headed to it 🏠. This is a generic NAT problem, and it's fully described in [NAT-TERM] 📖.
Note, this limitation does not apply to packets going to or coming from dual-stack nodes that don't need packet translation 🫶. Why? In a dual-stack setup, the IPv4 addresses implied in a V6 address can be identified from the address format PREFIX::x.y.z.w, so a dual-stack router can route a packet between v4 and dual-stack nodes without tracking any state information 🧠✨.
This also shouldn't affect IPv6 to IPv6 communication 🌈. Translation should only actually get used when no other means of communication is possible 🙌. For example, NAT-PT might also have a native IPv6 connection and/or some kind of tunneled IPv6 connection 🚇. Both of those should be preferred over translation whenever possible 👑. So the whole point is that NAT-PT is only a tool to help you transition to native IPv6 to IPv6 communication 🦋.
7.2 Protocol Translation Limitations 🔄
A bunch of IPv4 fields changed meaning in IPv6, so translating them isn't straightforward 😵💫. For example, the option headers' semantics and syntax changed a lot in IPv6 🎀. If you want the details on IPv4 to IPv6 Protocol Translation, check out [SIIT] 📚.
7.3 Impact of Address Translation 📍
Since NAT-PT does address translation, applications that carry the IP address in the higher layers won't work 💀. In this case, Application Layer Gateways (ALG) need to be added to support those applications 🛠️. This is a generic problem with NAT too, and it's fully described in [NAT-TERM] 🔍.
7.4 Lack of end-to-end security 🔐
This is one of the biggest limitations of the NAT-PT proposal, no cap 😭. End-to-end network layer security is not possible 🚫. Transport and application layer security may also not be possible for applications that carry IP addresses up to the application layer 💔. It's an inherent limitation of the Network Address Translation function 🥀.
Independent of NAT-PT, end-to-end IPSec security is not possible across different address realms 🧱. The two end-nodes that want IPSec network level security must both support one of IPv4 or IPv6 💜.
7.5 DNS Translation and DNSSEC 🧚♀️
The scheme described in section 4.2 involves translating DNS messages 📬. It's clear that this scheme cannot be deployed together with secure DNS 🚫. Like, an authoritative DNS name server in the V6 domain can't sign replies to queries that come from the V4 world 😤. So a V4 end-node that demands DNS replies be signed will reject replies that NAT-PT has tampered with 🙅♀️.
The good news is that only the servers in the V6 domain that need to be reachable from the V4 world pay the price for this limitation 🌸. V4 end-nodes may not access V6 servers because their DNS replies aren't signed 🫠.
Also note that zone transfers between DNS-SEC servers within the same V6 network are not impacted 🫶.
Clearly, once DNS SEC is deployed on DNS servers and end-host resolvers, the scheme suggested in this document would not work 💀✨.
Full Copyright Statement ✨
okay bestie, let's talk legal stuff 💅 the copyright belongs to the Internet Society, and it's Copyright (C) The Internet Society (2000). All Rights Reserved. 🎀
anyone can copy this document and pass it around 🦋 you can also write derivative works that comment on it, explain it, or help people implement it, and publish and distribute those however you like, in whole or in part, with no restriction of any kind. the one catch is that the copyright notice and this paragraph have to stay on every copy and every derivative work 🫶
the document itself is a different story 🙈 it may not be modified in any way. that means no removing the copyright notice, and no removing references to the Internet Society or other Internet organizations. there are a few exceptions though 🌈 you can change it for developing Internet standards, but then the copyright procedures in the Internet Standards process must be followed. you can also translate it into languages other than English.
these permissions are perpetual, and the Internet Society or its successors or assigns will never revoke them ⭐ forever and ever, no cap 💜
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 💀
Acknowledgement 🌸
funding for the RFC Editor function is currently provided by the Internet Society 🍓🫶
📦 where this page comes from
- ietf: rfc2766 2000-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms