draft-ietf-v6ops-rfc6146-bis-14.txt   draft-ietf-v6ops-rfc6146-bis-15.txt 
v6ops M. Bagnulo v6ops M. Bagnulo
Internet-Draft UC3M Internet-Draft UC3M
Obsoletes: 6146 (if approved) P. Matthews Obsoletes: 6146 (if approved) P. Matthews
Intended status: Standards Track Intended status: Standards Track
Expires: 12 February 2027 J. Palet Martinez, Ed. Expires: 26 February 2027 J. Palet Martinez, Ed.
The IPv6 Company The IPv6 Company
11 August 2026 25 August 2026
Stateful NAT64: Network Address and Protocol Translation Stateful NAT64: Network Address and Protocol Translation
from IPv6 Clients to IPv4 Servers from IPv6 Clients to IPv4 Servers
draft-ietf-v6ops-rfc6146-bis-14 draft-ietf-v6ops-rfc6146-bis-15
Abstract Abstract
This document specifies a stateful NAT64 translation, which allows This document specifies a stateful NAT64 translation, which allows
IPv6-Only clients to contact IPv4 servers using unicast UDP, TCP, or IPv6-Only clients to contact IPv4 servers using unicast UDP, TCP, or
ICMP. One or more public IPv4 addresses assigned to a stateful NAT64 ICMP. One or more public IPv4 addresses assigned to a stateful NAT64
translator are shared among several IPv6-Only clients. Stateful translator are shared among several IPv6-Only clients. Stateful
NAT64 translation also supports IPv4-initiated communications to a NAT64 translation also supports IPv4-initiated communications to a
subset of the IPv6 hosts through statically configured bindings in subset of the IPv6 hosts through configured bindings in the stateful
the stateful NAT64 translator. When the stateful NAT64 translation NAT64 translator. When the stateful NAT64 translation is used in
is used in conjunction with DNS64, no changes are required in either conjunction with DNS64, no changes are required in either the IPv6
the IPv6 client or the IPv4 server. client or the IPv4 server.
This document obsoletes RFC 6146. This document obsoletes RFC 6146.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on 12 February 2027. This Internet-Draft will expire on 26 February 2027.
Copyright Notice Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/ Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document. license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License. provided without warranty as described in the Revised BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Features of the Stateful NAT64 translation . . . . . . . 5 1.1. Features of the Stateful NAT64 Translation . . . . . . . 5
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . 7 1.2.1. Stateful NAT64 Solution Elements . . . . . . . . . . 7
1.2.2. Stateful NAT64 Translator Behaviour Walk-Through . . 9 1.2.2. Stateful NAT64 Translator Behaviour Walk-Through . . 9
1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 12 1.2.3. Filtering . . . . . . . . . . . . . . . . . . . . . . 12
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 12
3. Stateful NAT64 Prefix Considerations . . . . . . . . . . . . 15 3. Stateful NAT64 Translator Normative Specification . . . . . . 15
3.1. Stateful NAT64 Prefix . . . . . . . . . . . . . . . . . . 15 3.1. Binding Information Bases (BIBs) . . . . . . . . . . . . 16
3.2. Stateful NAT64 Prefix Discovery . . . . . . . . . . . . . 15 3.2. Session Tables . . . . . . . . . . . . . . . . . . . . . 17
4. Stateful NAT64 Translator Normative Specification . . . . . . 16 3.3. Packet Processing Overview . . . . . . . . . . . . . . . 18
4.1. Binding Information Bases (BIBs) . . . . . . . . . . . . 17 3.4. Determining the Incoming Tuple . . . . . . . . . . . . . 20
4.2. Session Tables . . . . . . . . . . . . . . . . . . . . . 18 3.5. Filtering and Updating Binding and Session Information . 23
4.3. Packet Processing Overview . . . . . . . . . . . . . . . 19 3.5.1. UDP Session Handling . . . . . . . . . . . . . . . . 23
4.4. Determining the Incoming Tuple . . . . . . . . . . . . . 21 3.5.1.1. Rules for Allocation of IPv4 Transport Addresses
4.5. Filtering and Updating Binding and Session Information . 24 for UDP . . . . . . . . . . . . . . . . . . . . . . 26
4.5.1. UDP Session Handling . . . . . . . . . . . . . . . . 24 3.5.2. TCP Session Handling . . . . . . . . . . . . . . . . 27
4.5.1.1. Rules for Allocation of IPv4 Transport Addresses 3.5.2.1. State Definition . . . . . . . . . . . . . . . . 27
for UDP . . . . . . . . . . . . . . . . . . . . . . 27 3.5.2.2. State Machine for TCP Processing in the Stateful
4.5.2. TCP Session Handling . . . . . . . . . . . . . . . . 28 NAT64 Translator . . . . . . . . . . . . . . . . . 28
4.5.2.1. State Definition . . . . . . . . . . . . . . . . 28 3.5.2.3. Rules for Allocation of IPv4 Transport Addresses
4.5.2.2. State Machine for TCP Processing in the Stateful for TCP . . . . . . . . . . . . . . . . . . . . . . 36
NAT64 Translator . . . . . . . . . . . . . . . . . 29 3.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 37
4.5.2.3. Rules for Allocation of IPv4 Transport Addresses 3.5.4. Generation of the IPv6 Representations of IPv4
for TCP . . . . . . . . . . . . . . . . . . . . . . 37 Addresses . . . . . . . . . . . . . . . . . . . . . . 39
4.5.3. ICMP Query Session Handling . . . . . . . . . . . . . 37 3.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . 40
4.5.4. Generation of the IPv6 Representations of IPv4 3.6.1. Computing the Outgoing 5-Tuple for UDP, TCP, and for
Addresses . . . . . . . . . . . . . . . . . . . . . . 40 ICMP Error Messages Containing UDP or TCP Packets . . 40
4.6. Computing the Outgoing Tuple . . . . . . . . . . . . . . 41 3.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages
4.6.1. Computing the Outgoing 5-Tuple for UDP, TCP, and for and for ICMP Error Messages Containing an ICMP Query 41
ICMP Error Messages Containing UDP or TCP Packets . . 41 3.7. Translating the Packet . . . . . . . . . . . . . . . . . 41
4.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages 3.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . 42
and for ICMP Error Messages Containing an ICMP Query 42 4. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 43
4.7. Translating the Packet . . . . . . . . . . . . . . . . . 42 5. Stateful NAT64 Prefix Considerations . . . . . . . . . . . . 43
4.8. Handling Hairpinning . . . . . . . . . . . . . . . . . . 43 5.1. Stateful NAT64 Prefix . . . . . . . . . . . . . . . . . . 43
5. Protocol Constants . . . . . . . . . . . . . . . . . . . . . 43 5.2. Stateful NAT64 Prefix Discovery . . . . . . . . . . . . . 43
6. Operational Considerations . . . . . . . . . . . . . . . . . 44 6. Operational Considerations . . . . . . . . . . . . . . . . . 44
6.1. Stateful NAT64 in Other Protocols . . . . . . . . . . . . 44 6.1. Stateful NAT64 in Other Protocols . . . . . . . . . . . . 44
6.2. Port Control Protocol . . . . . . . . . . . . . . . . . . 44 6.2. Port Control Protocol . . . . . . . . . . . . . . . . . . 45
6.3. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 45 6.3. QUIC . . . . . . . . . . . . . . . . . . . . . . . . . . 45
6.4. Issues with IP Address Sharing . . . . . . . . . . . . . 45 6.4. Issues with IP Address Sharing . . . . . . . . . . . . . 45
6.5. Previous Operational Experience . . . . . . . . . . . . . 45 6.5. Previous Operational Experience . . . . . . . . . . . . . 45
6.6. Benchmarking and Scalability . . . . . . . . . . . . . . 45 6.6. Benchmarking and Scalability . . . . . . . . . . . . . . 45
6.7. Port Allocation Schemes . . . . . . . . . . . . . . . . . 45 6.7. Port Allocation Schemes . . . . . . . . . . . . . . . . . 45
6.8. Logging, Alarms and Event Reporting . . . . . . . . . . . 45 6.8. Logging, Alarms and Event Reporting . . . . . . . . . . . 46
7. Implementation Status . . . . . . . . . . . . . . . . . . . . 46 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 46
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 48
9. Security Considerations . . . . . . . . . . . . . . . . . . . 49 9. Security Considerations . . . . . . . . . . . . . . . . . . . 49
9.1. Implications on End-to-End Security . . . . . . . . . . . 49 9.1. Implications on End-to-End Security . . . . . . . . . . . 49
9.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 49 9.2. Filtering . . . . . . . . . . . . . . . . . . . . . . . . 49
9.3. Attacks on Stateful NAT64 Translators . . . . . . . . . . 50 9.3. Attacks on Stateful NAT64 Translators . . . . . . . . . . 50
9.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . 51 9.4. Avoiding Hairpinning Loops . . . . . . . . . . . . . . . 51
9.5. DNS64 and DNSSEC . . . . . . . . . . . . . . . . . . . . 52 9.5. DNS64 and DNSSEC . . . . . . . . . . . . . . . . . . . . 52
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 54
skipping to change at page 3, line 42 skipping to change at page 3, line 42
communications to an IPv4-Only server. They also enable peer-to-peer communications to an IPv4-Only server. They also enable peer-to-peer
communication between an IPv4 and an IPv6 node, where the communication between an IPv4 and an IPv6 node, where the
communication can be initiated when either end uses existing, NAT- communication can be initiated when either end uses existing, NAT-
traversal, peer-to-peer communication techniques, such as Interactive traversal, peer-to-peer communication techniques, such as Interactive
Connectivity Establishment (ICE) [RFC8445] [RFC8839]. Connectivity Establishment (ICE) [RFC8445] [RFC8839].
The stateful NAT64 translation, can also be used in combination with The stateful NAT64 translation, can also be used in combination with
a 464XLAT [RFC6877] customer-side translator (CLAT), in order to a 464XLAT [RFC6877] customer-side translator (CLAT), in order to
further increase and facilitate the deployment of IPv6, by supporting further increase and facilitate the deployment of IPv6, by supporting
applications that do not use DNS (e.g., when using literal IPv4 applications that do not use DNS (e.g., when using literal IPv4
addresses, code-embedded IPv4 addresses, etc.). addresses, code-embedded IPv4 addresses).
The stateful NAT64 translation also supports IPv4-initiated The stateful NAT64 translation also supports IPv4-initiated
communications to a subset of the IPv6 hosts through statically communications to a subset of the IPv6 hosts through statically
configured bindings in the stateful NAT64 translator, which is configured bindings in the stateful NAT64 translator, which is
usually implemented, following the same approach as for Explicit usually implemented, following the same approach as for Explicit
Address Mappings for Stateless IP/ICMP Translation [RFC7757]. Address Mappings for Stateless IP/ICMP Translation [RFC7757].
Note that the server may be actually a peer "exposing a server Note that the server may be actually a peer "exposing a server
function", so across the document, references to IPv4-Only servers function", so across the document, references to IPv4-Only servers
also mean IPv4-Only peers even if not specifically stated. also mean IPv4-Only peers even if not specifically stated.
skipping to change at page 5, line 12 skipping to change at page 5, line 12
to initiate communications to an IPv4-only server. to initiate communications to an IPv4-only server.
Note that in some cases, when using the stateful NAT64 translation Note that in some cases, when using the stateful NAT64 translation
together with other mechanisms (such as a 464XLAT [RFC6877] customer- together with other mechanisms (such as a 464XLAT [RFC6877] customer-
side translator - CLAT), this may be possible just using stateful side translator - CLAT), this may be possible just using stateful
NAT64 translation, without the need of DNS64. However, as described NAT64 translation, without the need of DNS64. However, as described
in [RFC8683], it has the impact of forcing a double translation and in [RFC8683], it has the impact of forcing a double translation and
may induce an extra delay for the connection establishment. As a may induce an extra delay for the connection establishment. As a
side note, for completeness, the stateful NAT64 function is also side note, for completeness, the stateful NAT64 function is also
called PLAT (provider-side translator), using the 464XLAT [RFC6877] called provider-side translator (PLAT), using the 464XLAT [RFC6877]
terminology. terminology.
For the remainder of this document, an IPv6-only client or node For the remainder of this document, an IPv6-only client or node
refers to one of the cases enumerated in the preceding bulleted list, refers to one of the cases enumerated in the preceding bulleted list,
unless explicitly stated otherwise. unless explicitly stated otherwise.
These mechanisms play a critical role in IPv4-IPv6 transition and These mechanisms play a critical role in IPv4-IPv6 transition and
coexistence. Due to public IPv4 address depletion and the limited coexistence. Due to public IPv4 address depletion and the limited
size of [RFC1918] addressing space (in hyperscale data centres or size of [RFC1918] addressing space (in hyperscale data centers or
mobile networks, for example), new clients are IPv6-only and still mobile networks, for example), new clients are IPv6-only and still
need to connect to the existing IPv4-only servers. The stateful need to connect to the existing IPv4-only servers. The stateful
NAT64 and DNS64 mechanisms are easily deployable, since they do not NAT64 and DNS64 mechanisms are easily deployable, since they do not
require changes to either the IPv6 client or the IPv4 server. For require changes to either the IPv6 client or the IPv4 server. For
basic functionality, the approach only requires the deployment of the basic functionality, the approach only requires the deployment of the
stateful NAT64 function somewhere in the path between the devices stateful NAT64 function somewhere in the path between the devices
connecting an IPv6-only network to the IPv4-only network, along with connecting an IPv6-only network to the IPv4-only network, along with
the deployment of a DNS64-enabled name server accessible to the the deployment of a DNS64-enabled name server accessible to the
IPv6-only hosts. If a host can be updated, then the DNS64 IPv6-only hosts. If a host can be updated, then the DNS64
functionality can be built-in, as well as supporting some new functionality can be built-in, as well as supporting some new
features which improve the functionality, such as the support of features which improve the functionality, such as the support of
IPv6-Mostly. An analysis of the application scenarios can be found IPv6-Mostly. An analysis of the application scenarios can be found
in [RFC6144]. in [RFC6144].
This document obsoletes [RFC6146]. The primary changes are listed in This document obsoletes [RFC6146]. The primary changes are listed in
Appendix A. Appendix A.
1.1. Features of the Stateful NAT64 translation 1.1. Features of the Stateful NAT64 Translation
The features of the stateful NAT64 translation are: The features of the stateful NAT64 translation are:
* The stateful NAT64 translation is compliant with the * The stateful NAT64 translation is compliant with the
recommendations for how NATs should handle UDP [RFC4787], TCP recommendations for how NATs should handle UDP [RFC4787], TCP
[RFC5382], and ICMP [RFC5508]. As such, the stateful NAT64 [RFC5382], and ICMP [RFC5508]. As such, the stateful NAT64
translation only supports Endpoint-Independent Mappings and translation only supports Endpoint-Independent Mappings and
supports both Endpoint-Independent and Address-Dependent supports both Endpoint-Independent and Address-Dependent
Filtering. Because of the compliance with the aforementioned Filtering. Because of the compliance with the aforementioned
requirements, the stateful NAT64 translation is compatible with requirements, the stateful NAT64 translation is compatible with
skipping to change at page 7, line 5 skipping to change at page 7, line 5
stateful NAT64 function, a single DNS64, and a simple network stateful NAT64 function, a single DNS64, and a simple network
topology. The goal of this description is to provide the reader with topology. The goal of this description is to provide the reader with
a general view of the stateful NAT64 translation. It is not the goal a general view of the stateful NAT64 translation. It is not the goal
of this section to describe all possible configurations nor to of this section to describe all possible configurations nor to
provide a normative specification of the stateful NAT64 translation provide a normative specification of the stateful NAT64 translation
behaviour. A more complete set of possible deployment scenarios is behaviour. A more complete set of possible deployment scenarios is
described in [RFC8683]. For the sake of clarity, only UDP and TCP described in [RFC8683]. For the sake of clarity, only UDP and TCP
are described in this overview; the details of ICMP, fragmentation, are described in this overview; the details of ICMP, fragmentation,
and other aspects of translation are purposefully avoided in this and other aspects of translation are purposefully avoided in this
overview. The normative specification of the stateful NAT64 overview. The normative specification of the stateful NAT64
translation is provided in Section 4. translation is provided in Section 3.
The stateful NAT64 function is implemented in a device that has (at The stateful NAT64 function is implemented in a device that has (at
least) two interfaces, an IPv4 interface connected to the IPv4 least) two interfaces, an IPv4 interface connected to the IPv4
network, and an IPv6 interface connected to the IPv6 network. network, and an IPv6 interface connected to the IPv6 network.
Packets generated in the IPv6 network for a receiver located in the Packets generated in the IPv6 network for a receiver located in the
IPv4 network will be forwarded within the IPv6 network towards the IPv4 network will be forwarded within the IPv6 network towards the
stateful NAT64 function. The stateful NAT64 function will translate stateful NAT64 function. The stateful NAT64 function will translate
them and forward them as IPv4 packets through the IPv4 network to the them and forward them as IPv4 packets through the IPv4 network to the
IPv4 receiver. The reverse takes place for packets generated by IPv4 receiver. The reverse takes place for packets generated by
hosts connected to the IPv4 network for an IPv6 receiver. The hosts connected to the IPv4 network for an IPv6 receiver. The
skipping to change at page 8, line 18 skipping to change at page 8, line 18
stateful NAT64 translator, the comments made about Pref64::/n apply stateful NAT64 translator, the comments made about Pref64::/n apply
to each of them. Pref64::/n will be used by the stateful NAT64 to each of them. Pref64::/n will be used by the stateful NAT64
translator to construct IPv4-Converted IPv6 addresses as defined in translator to construct IPv4-Converted IPv6 addresses as defined in
[RFC6052]. Due to the abundance of IPv6 address space, it is [RFC6052]. Due to the abundance of IPv6 address space, it is
possible to assign one or more Pref64::/n, each of them being equal possible to assign one or more Pref64::/n, each of them being equal
to or even bigger than the size of the whole IPv4 address space. to or even bigger than the size of the whole IPv4 address space.
This allows each IPv4 address to be mapped into a different IPv6 This allows each IPv4 address to be mapped into a different IPv6
address by simply concatenating a Pref64::/n with the IPv4 address address by simply concatenating a Pref64::/n with the IPv4 address
being mapped and a suffix. The address format of the Pref64::/n is being mapped and a suffix. The address format of the Pref64::/n is
defined in [RFC6052]. Pref64::/n provisioning protocols are defined in [RFC6052]. Pref64::/n provisioning protocols are
described in Section 3.2. described in Section 5.2.
The IPv4 address pool is a set of IPv4 addresses, normally a prefix The IPv4 address pool is a set of IPv4 addresses, normally a prefix
assigned by the local administrator. Since IPv4 address space is a assigned by the local administrator. Since IPv4 address space is a
scarce resource, the IPv4 address pool is small and typically not scarce resource, the IPv4 address pool is small and typically not
sufficient to establish permanent one-to-one mappings with IPv6 sufficient to establish permanent one-to-one mappings with IPv6
addresses. So, except for the static/manually created ones, mappings addresses. So, except for the static/manually created ones, mappings
using the IPv4 address pool will be created and released dynamically. using the IPv4 address pool will be created and released dynamically.
Moreover, because of the IPv4 address scarcity, the usual practice Moreover, because of the IPv4 address scarcity, the usual practice
for the stateful NAT64 translators is to be the binding of IPv6 for the stateful NAT64 translators is to be the binding of IPv6
transport addresses into IPv4 transport addresses, instead of IPv6 transport addresses into IPv4 transport addresses, instead of IPv6
skipping to change at page 12, line 49 skipping to change at page 12, line 49
source IP address of the incoming IPv4 packet. source IP address of the incoming IPv4 packet.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
The following additional terms are used in this document: The following terms are used in this document:
3-Tuple: The tuple (source IP address, destination IP address, ICMP 3-Tuple: The tuple (source IP address, destination IP address, ICMP
Identifier). A 3-tuple uniquely identifies an ICMP Query session. Identifier). A 3-tuple uniquely identifies an ICMP Query session.
When an ICMP Query session flows through a stateful NAT64 When an ICMP Query session flows through a stateful NAT64
translator, each session has two different 3-tuples: one with IPv4 translator, each session has two different 3-tuples: one with IPv4
addresses and one with IPv6 addresses. addresses and one with IPv6 addresses.
5-Tuple: The tuple (source IP address, source port, destination IP 5-Tuple: The tuple (source IP address, source port, destination IP
address, destination port, transport protocol). A 5-tuple address, destination port, transport protocol). A 5-tuple
uniquely identifies a UDP/TCP session. When a UDP/TCP session uniquely identifies a UDP/TCP session. When a UDP/TCP session
skipping to change at page 15, line 20 skipping to change at page 15, line 20
Transport Address: The combination of an IPv6 or IPv4 address and a Transport Address: The combination of an IPv6 or IPv4 address and a
port. Typically written as (IP address,port), e.g., port. Typically written as (IP address,port), e.g.,
(192.0.2.15,8001). (192.0.2.15,8001).
Tuple: Refers to either a 3-tuple or a 5-tuple as defined above. Tuple: Refers to either a 3-tuple or a 5-tuple as defined above.
For a detailed understanding of this document, the reader should also For a detailed understanding of this document, the reader should also
be familiar with NAT terminology [RFC4787]. be familiar with NAT terminology [RFC4787].
3. Stateful NAT64 Prefix Considerations 3. Stateful NAT64 Translator Normative Specification
3.1. Stateful NAT64 Prefix
The stateful NAT64 protocol does not make an assumption about whether
the WKP or a Network Specific Prefix (NSP) is used. Such decision is
deployment-specific. However, [RFC6052] used to have a deployment
constraint for the use of WKP and includes a restriction against the
use of non-global IPv4 addresses. This restriction is relaxed in
[I-D.ietf-v6ops-nat64-wkp-1918].
Note for the RFC Editor, please remove this note before publication.
If [I-D.ietf-v6ops-nat64-wkp-1918] has not been published when
publishing this document, to avoid holding the document, the last
sentence of the previous paragraph should be shortened as "This
restriction maybe relaxed in the future", removing the reference.
Further, [RFC8215] specifies a Local-Use IPv4/IPv6 Translation
Prefix, adjacent to the WKP, facilitating the coexistence of multiple
IPv4/IPv6 translation mechanisms in a single network domain.
3.2. Stateful NAT64 Prefix Discovery
In order to improve the discovery by clients of the Pref64::/n being
used by the stateful NAT64 translator, [RFC8781] specifies a ND
option to be used in RAs. [RFC9872] further provides a
recommendation for using [RFC8781] instead of a best effort method as
defined by [RFC7050] (updated by [RFC8880]).
One more alternative is specified by [RFC7225] "Discovering NAT64
IPv6 Prefixes Using the Port Control Protocol (PCP)".
Section 3 of [RFC7051] already exposed the issues of the stateful
NAT64 prefix discovery, and most of them are resolved in [RFC8781],
but it is important for operators to review that in order to ensure a
proper deployment.
It should be noticed that the DHCPv6 OPTION_V6_PREFIX64, defined in
[RFC8115], is not a stateful NAT64 prefix discovery mechanism and
should not be used for that purpose. This is remarked to ensure
avoiding confusion for deployers who notice the option name or the
uPrefix64 field.
4. Stateful NAT64 Translator Normative Specification
A stateful NAT64 translator is a device with at least one IPv6 A stateful NAT64 translator is a device with at least one IPv6
interface and at least one IPv4 interface. Note these two interfaces interface and at least one IPv4 interface. Note these two interfaces
can actually be a single layer-2 interface. Each stateful NAT64 can actually be a single layer-2 interface. Each stateful NAT64
device MUST have at least one unicast /n IPv6 prefix assigned to it, device MUST have at least one unicast /n IPv6 prefix assigned to it,
denoted Pref64::/n. Additional considerations about the Pref64::/n denoted Pref64::/n. Additional considerations about the Pref64::/n
are presented in Section 4.5.4. A stateful NAT64 translator MUST are presented in Section 3.5.4. A stateful NAT64 translator MUST
have one or more unicast non link-local IPv4 addresses assigned to have one or more unicast non link-local IPv4 addresses assigned to
it. it.
A stateful NAT64 translator uses the following conceptual dynamic A stateful NAT64 translator uses the following conceptual dynamic
data structures: data structures:
* UDP Binding Information Base * UDP Binding Information Base
* UDP Session Table * UDP Session Table
skipping to change at page 16, line 41 skipping to change at page 16, line 4
* UDP Session Table * UDP Session Table
* TCP Binding Information Base * TCP Binding Information Base
* TCP Session Table * TCP Session Table
* ICMP Query Binding Information Base * ICMP Query Binding Information Base
* ICMP Query Session Table * ICMP Query Session Table
These tables contain information needed for the stateful NAT64 These tables contain information needed for the stateful NAT64
translator processing. The actual division of the information into translator processing. The actual division of the information into
six tables is done in order to ease the description of the stateful six tables is done in order to ease the description of the stateful
NAT64 translator behaviour. The stateful NAT64 translator NAT64 translator behaviour. The stateful NAT64 translator
implementations are free to use different data structures but they implementations are free to use different data structures but they
MUST store all the required information, and the externally visible MUST store all the required information, and the externally visible
outcome MUST be the same as the one described in this document. outcome MUST be the same as the one described in this document.
The notation used is the following: uppercase letters are IPv4 The notation used is the following: uppercase letters are IPv4
addresses; uppercase letters with a prime(') are IPv6 addresses; addresses; uppercase letters with a prime(') are IPv6 addresses;
lowercase letters are ports; IPv6 prefixes of length n are indicated lowercase letters are ports; IPv6 prefixes of length n are indicated
by "P::/n". For UDP and TCP mappings are indicated as "(X,x) <--> by "P::/n". For UDP and TCP mappings are indicated as "(X,x) <-->
(Y',y)". For ICMP instead of the port number, "in" is used for the (Y',y)". For ICMP instead of the port number, "in" is used for the
ICMPv4/6 identifier, such as in [X',i1] <--> [Y,i2] and [X',Y',i1] ICMPv4/6 identifier, such as in [X',i1] <--> [Y,i2] and [X',Y',i1]
<--> [X,Y,i2]. <--> [X,Y,i2].
4.1. Binding Information Bases (BIBs) 3.1. Binding Information Bases (BIBs)
A stateful NAT64 translator has three BIBs: one for UDP, one for TCP, A stateful NAT64 translator has three BIBs: one for UDP, one for TCP,
and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB and one for ICMP Queries. In the case of UDP and TCP BIBs, each BIB
entry specifies a mapping between an IPv6 transport address and an entry specifies a mapping between an IPv6 transport address and an
IPv4 transport address: IPv4 transport address:
(X',x) <--> (T,t) (X',x) <--> (T,t)
where X' is some IPv6 address, T is an IPv4 address, and x and t are where X' is some IPv6 address, T is an IPv4 address, and x and t are
ports. T will always be one of the IPv4 addresses assigned to the ports. T will always be one of the IPv4 addresses assigned to the
skipping to change at page 18, line 6 skipping to change at page 17, line 12
[X',i1] <--> [T,i2] [X',i1] <--> [T,i2]
where X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6 where X' is some IPv6 address, T is an IPv4 address, i1 is an ICMPv6
Identifier, and i2 is an ICMPv4 Identifier. T will always be one of Identifier, and i2 is an ICMPv4 Identifier. T will always be one of
the IPv4 addresses assigned to the stateful NAT64 translator. A the IPv4 addresses assigned to the stateful NAT64 translator. A
given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can given (IPv6 or IPv4 address, ICMPv6 or ICMPv4 Identifier) pair can
appear in at most one entry in the ICMP Query BIB. appear in at most one entry in the ICMP Query BIB.
Entries in any of the three BIBs can be created dynamically as the Entries in any of the three BIBs can be created dynamically as the
result of the flow of packets as described in Section 4.5, but they result of the flow of packets as described in Section 3.5, but they
can also be created manually by an administrator. The stateful NAT64 can also be created manually by an administrator. The stateful NAT64
translator implementations should support manually configured BIB translator implementations SHOULD support manually configured BIB
entries for any of the three BIBs. Dynamically created entries are entries for any of the three BIBs. Otherwise, incoming connections
deleted from the corresponding BIB when the last session associated won't be supported in the presence of a NAT64 function. Dynamically
with the BIB entry is removed from the session table. Manually created entries are deleted from the corresponding BIB when the last
configured BIB entries are not deleted when there is no corresponding session associated with the BIB entry is removed from the session
Session Table Entry and can only be deleted by the administrator. table. Manually configured BIB entries are not deleted when there is
no corresponding Session Table Entry and can only be deleted by the
administrator.
4.2. Session Tables 3.2. Session Tables
A stateful NAT64 translator also has three session tables: one for A stateful NAT64 translator also has three session tables: one for
UDP sessions, one for TCP sessions, and one for ICMP Query sessions. UDP sessions, one for TCP sessions, and one for ICMP Query sessions.
Each entry keeps information on the state of the corresponding Each entry keeps information on the state of the corresponding
session. In the UDP and TCP session tables, each entry specifies a session. In the UDP and TCP session tables, each entry specifies a
mapping between a pair of IPv6 transport addresses and a pair of IPv4 mapping between a pair of IPv6 transport addresses and a pair of IPv4
transport addresses: transport addresses:
(X',x),(Y',y) <--> (T,t),(Z,z) (X',x),(Y',y) <--> (T,t),(Z,z)
skipping to change at page 19, line 37 skipping to change at page 18, line 42
The STE ICMPv6 Identifier; i1 in the example above. The STE ICMPv6 Identifier; i1 in the example above.
The STE source IPv4 address; T in the example above. The STE source IPv4 address; T in the example above.
The STE destination IPv4 address; Z in the example above. The STE destination IPv4 address; Z in the example above.
The STE ICMPv4 Identifier; i2 in the example above. The STE ICMPv4 Identifier; i2 in the example above.
The STE lifetime. The STE lifetime.
4.3. Packet Processing Overview 3.3. Packet Processing Overview
The stateful NAT64 translator uses the session state information to The stateful NAT64 translator uses the session state information to
determine when the session is completed, and also uses session determine when the session is completed, and also uses session
information for Address-Dependent Filtering. A session can be information for Address-Dependent Filtering. A session can be
uniquely identified by either an incoming tuple or an outgoing tuple. uniquely identified by either an incoming tuple or an outgoing tuple.
For each UDP or TCP session, there is a corresponding BIB entry, For each UDP or TCP session, there is a corresponding BIB entry,
uniquely specified by either the source IPv6 transport address (in uniquely specified by either the source IPv6 transport address (in
the IPv6 --> IPv4 direction) or the destination IPv4 transport the IPv6 --> IPv4 direction) or the destination IPv4 transport
address (in the IPv4 --> IPv6 direction). For each ICMP Query address (in the IPv4 --> IPv6 direction). For each ICMP Query
skipping to change at page 20, line 30 skipping to change at page 19, line 25
traffic. The processing of the packets will be described next. In traffic. The processing of the packets will be described next. In
the case that the processing is common to all the aforementioned the case that the processing is common to all the aforementioned
types of packets, this document refers to the packet as the incoming types of packets, this document refers to the packet as the incoming
IP packet in general. In the case that the processing is specific to IP packet in general. In the case that the processing is specific to
IPv6 packets, this document will explicitly refer to the incoming IPv6 packets, this document will explicitly refer to the incoming
packet as an incoming IPv6 packet; analogous terminology will apply packet as an incoming IPv6 packet; analogous terminology will apply
in the case of processing that is specific to IPv4 packets. in the case of processing that is specific to IPv4 packets.
The processing of an incoming IP packet takes the following steps: The processing of an incoming IP packet takes the following steps:
1. Determining the incoming tuple (Section 4.4). 1. Determining the incoming tuple (Section 3.4).
2. Filtering and updating binding and session information 2. Filtering and updating binding and session information
(Section 4.5). (Section 3.5).
3. Computing the outgoing tuple (Section 4.6). 3. Computing the outgoing tuple (Section 3.6).
4. Translating the packet (Section 4.7). 4. Translating the packet (Section 3.7).
5. Handling hairpinning (Section 4.8). 5. Handling hairpinning (Section 3.8).
The details of these steps are specified in the following The details of these steps are specified in the following
subsections. subsections.
This breakdown of the stateful NAT64 translator behaviour into This breakdown of the stateful NAT64 translator behaviour into
processing steps is done for ease of presentation. A stateful NAT64 processing steps is done for ease of presentation. A stateful NAT64
translator may perform the steps in a different order or may perform translator MAY perform the steps in a different order or MAY perform
different steps, but the externally visible outcome MUST be the same different steps, but the externally visible outcome MUST be the same
as described. as described.
4.4. Determining the Incoming Tuple 3.4. Determining the Incoming Tuple
This step associates an incoming tuple with every incoming IP packet This step associates an incoming tuple with every incoming IP packet
for use in subsequent steps. In the case of UDP, TCP, and ICMP error for use in subsequent steps. In the case of UDP, TCP, and ICMP error
packets, the tuple is a 5-tuple consisting of the source IP address, packets, the tuple is a 5-tuple consisting of the source IP address,
source port, destination IP address, destination port, and transport source port, destination IP address, destination port, and transport
protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting protocol. In case of ICMP Queries, the tuple is a 3-tuple consisting
of the source IP address, destination IP address, and ICMP of the source IP address, destination IP address, and ICMP
Identifier. Identifier.
If the incoming IP packet contains a complete (un-fragmented) UDP or If the incoming IP packet contains a complete (un-fragmented) UDP or
skipping to change at page 22, line 23 skipping to change at page 21, line 23
particular, a stateful NAT64 translator MUST handle fragments particular, a stateful NAT64 translator MUST handle fragments
arriving out of order, conditional on the following: arriving out of order, conditional on the following:
- The stateful NAT64 translator MUST limit the amount of - The stateful NAT64 translator MUST limit the amount of
resources devoted to the storage of fragmented packets in order resources devoted to the storage of fragmented packets in order
to protect itself from DoS attacks. to protect itself from DoS attacks.
- As long as the stateful NAT64 translator has available - As long as the stateful NAT64 translator has available
resources, the stateful NAT64 translator MUST allow the resources, the stateful NAT64 translator MUST allow the
fragments to arrive over a time interval. The time interval fragments to arrive over a time interval. The time interval
should be configurable and the default value MUST be of at SHOULD be configurable and the default value MUST be of at
least FRAGMENT_MIN. least FRAGMENT_MIN. This configuration parameter allows
operators to accommodate different traffic patterns and,
therefore, increase the serviceability of flows that cross such
NAT64 function.
- The stateful NAT64 translator may require that the UDP, TCP, or - The stateful NAT64 translator MAY require that the UDP, TCP, or
ICMP header be completely contained within the fragment that ICMP header be completely contained within the fragment that
contains fragment offset equal to zero. Note that [RFC8200] contains fragment offset equal to zero. Note that Section 4.5
Section 4.5 states "If the first fragment does not include all of [RFC8200] states "If the first fragment does not include all
headers through an Upper-Layer header, then that fragment headers through an Upper-Layer header, then that fragment
should be discarded and an ICMP Parameter Problem, Code 3, should be discarded and an ICMP Parameter Problem, Code 3,
message should be sent to the source of the fragment, with the message should be sent to the source of the fragment, with the
Pointer field set to zero". Pointer field set to zero".
For incoming packets carrying UDP or TCP fragments with a non-zero For incoming packets carrying UDP or TCP fragments with a non-zero
checksum, a stateful NAT64 translator MAY elect to queue the checksum, a stateful NAT64 translator MAY elect to queue the
fragments as they arrive and translate all fragments at the same fragments as they arrive and translate all fragments at the same
time. In this case, the incoming tuple is determined as time. In this case, the incoming tuple is determined as
documented above to the un-fragmented packets. Alternatively, a documented above to the un-fragmented packets. Alternatively, a
stateful NAT64 translator may translate the fragments as they stateful NAT64 translator MAY translate the fragments as they
arrive, by storing information that allows it to compute the arrive, by storing information that allows it to compute the
5-tuple for fragments other than the first. In the latter case, 5-tuple for fragments other than the first. In the latter case,
subsequent fragments may arrive before the first, and the rules subsequent fragments may arrive before the first, and the rules
(in the bulleted list above) about how the stateful NAT64 (in the bulleted list above) about how the stateful NAT64
translator handles (out-of-order) fragments apply. translator handles (out-of-order) fragments apply.
For incoming IPv4 packets carrying UDP packets with a zero For incoming IPv4 packets carrying UDP packets with a zero
checksum, if the stateful NAT64 translator has enough resources, checksum, if the stateful NAT64 translator has enough resources,
the stateful NAT64 translator MUST reassemble the packets and MUST the stateful NAT64 translator MUST reassemble the packets and MUST
calculate the checksum. If the stateful NAT64 translator does not calculate the checksum. If the stateful NAT64 translator does not
skipping to change at page 23, line 20 skipping to change at page 22, line 16
The handling of fragmented and un-fragmented UDP packets with a The handling of fragmented and un-fragmented UDP packets with a
zero checksum as specified above deviates from that specified in zero checksum as specified above deviates from that specified in
[RFC7915]. [RFC7915].
Note that, as indicated in Section 1.2 of [RFC7915], "Fragmented Note that, as indicated in Section 1.2 of [RFC7915], "Fragmented
IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP
checksum field is zero) are not of significant use on the checksum field is zero) are not of significant use on the
Internet", so in those rare cases, if there was a corruption in Internet", so in those rare cases, if there was a corruption in
transit, by not discarding the packets and recalculating the transit, by not discarding the packets and recalculating the
checksum, there is a risk for the destination to believe the data checksum, there is a risk for the destination to believe the data
is correct. To avoid uncertainty, implementations may provide a is correct. To avoid uncertainty, implementations MAY provide a
configuration function, as described in Section 4.5 of [RFC7915]. configuration function, as described in Section 4.5 of [RFC7915].
Implementers of stateful NAT64 translators should be aware that Implementers of stateful NAT64 translators should be aware that
there are a number of well-known attacks against IP fragmentation; there are a number of well-known attacks against IP fragmentation;
see [RFC1858], [RFC3128], [RFC6980] and [RFC8900]. Implementers see [RFC1858], [RFC3128], [RFC6980] and [RFC8900]. Implementers
should also be aware of additional issues with reassembling should also be aware of additional issues with reassembling
packets at high rates, described in [RFC4963], as well as fragment packets at high rates, described in [RFC4963], as well as fragment
translation processing in sections 1.4 and 5.1.1 of [RFC7915]. translation processing in sections 1.4 and 5.1.1 of [RFC7915].
Only unicast UDP, TCP, and ICMPv4/ICMPv6 incoming packets are Only unicast UDP, TCP, and ICMPv4/ICMPv6 incoming packets are
supported, consequently: supported, consequently:
* If the incoming packet is an IPv6 packet that contains a protocol * If the incoming packet is an IPv6 packet that contains a protocol
other than unicast UDP, TCP, or ICMPv6 in the last Next Header, other than unicast UDP, TCP, or ICMPv6 in the last Next Header,
then the packet should be discarded and, if the security policy then the packet SHOULD be discarded and, if the security policy
permits, the stateful NAT64 translator should send an ICMPv6 permits, the stateful NAT64 translator SHOULD send an ICMPv6
Destination Unreachable error message with Code 4 (Port Destination Unreachable error message with Code 4 (Port
Unreachable) to the source address of the received packet. Same Unreachable) to the source address of the received packet. Same
applies to extension headers as per Section 1.2 of [RFC7915]. applies to extension headers as per Section 1.2 of [RFC7915].
* If the incoming packet is an IPv4 packet that contains a protocol * If the incoming packet is an IPv4 packet that contains a protocol
other than unicast UDP, TCP, or ICMPv4, then the packet should be other than unicast UDP, TCP, or ICMPv4, then the packet SHOULD be
discarded and, if the security policy permits, the stateful NAT64 discarded and, if the security policy permits, the stateful NAT64
translator should send an ICMPv4 Destination Unreachable error translator SHOULD send an ICMPv4 Destination Unreachable error
message with Code 2 (Protocol Unreachable) to the source address message with Code 2 (Protocol Unreachable) to the source address
of the received packet. of the received packet.
NOTE: In both cases, this behaviour may be updated by future NOTE: In both cases, this behaviour may be updated by future
documents that define how other protocols (such as SCTP, DCCP or documents that define how other protocols (such as SCTP, DCCP or
others), are processed by a stateful NAT64 translator. In order to others), are processed by a stateful NAT64 translator. In order to
support other protocols, specific BIBs and mapping/translation rules support other protocols, specific BIBs and mapping/translation rules
could be added. could be added.
4.5. Filtering and Updating Binding and Session Information 3.5. Filtering and Updating Binding and Session Information
This step updates binding and session information stored in the This step updates binding and session information stored in the
appropriate tables. It may also filter incoming packets, if desired. appropriate tables. It may also filter incoming packets, if desired.
The details depend on the protocol, i.e., UDP, TCP, or ICMP. The The details depend on the protocol, i.e., UDP, TCP, or ICMP. The
behaviour for UDP, TCP, and ICMP Queries is described in behaviour for UDP, TCP, and ICMP Queries is described in
Section 4.5.1, Section 4.5.2, and Section 4.5.3, respectively. For Section 3.5.1, Section 3.5.2, and Section 3.5.3, respectively. For
the case of ICMP error messages, they do not affect in any way either the case of ICMP error messages, they do not affect in any way either
the BIBs or the session tables, so there is no processing resulting the BIBs or the session tables, so there is no processing resulting
from these messages in this section. ICMP error message processing from these messages in this section. ICMP error message processing
continues in Section 4.6. continues in Section 3.6.
Irrespective of the transport protocol used, the stateful NAT64 Irrespective of the transport protocol used, the stateful NAT64
translator MUST silently discard all incoming IPv6 packets containing translator MUST silently discard all incoming IPv6 packets containing
a source address that contains the Pref64::/n. This is required in a source address that contains the Pref64::/n. This is required in
order to prevent hairpinning loops as described in Section 9.4. In order to prevent hairpinning loops as described in Section 9.4. In
addition, the stateful NAT64 translator MUST only process incoming addition, the stateful NAT64 translator MUST only process incoming
IPv6 packets that contain a destination address that contains IPv6 packets that contain a destination address that contains
Pref64::/n. Likewise, the stateful NAT64 translator MUST only Pref64::/n. Likewise, the stateful NAT64 translator MUST only
process incoming IPv4 packets that contain a destination address that process incoming IPv4 packets that contain a destination address that
belongs to the IPv4 pool assigned to the stateful NAT64 translator. belongs to the IPv4 pool assigned to the stateful NAT64 translator.
4.5.1. UDP Session Handling 3.5.1. UDP Session Handling
The following state information is stored for a UDP session: The following state information is stored for a UDP session:
Binding:(X',x),(Y',y) <--> (T,t),(Z,z) Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Lifetime: a timer that tracks the remaining lifetime of the UDP Lifetime: a timer that tracks the remaining lifetime of the UDP
session. When the timer expires, the UDP session is deleted. If session. When the timer expires, the UDP session is deleted. If
all the UDP sessions corresponding to a dynamically created UDP all the UDP sessions corresponding to a dynamically created UDP
BIB entry are deleted, then the UDP BIB entry is also deleted. BIB entry are deleted, then the UDP BIB entry is also deleted.
skipping to change at page 24, line 50 skipping to change at page 23, line 50
address (X',x) and destination transport address (Y',y) is processed address (X',x) and destination transport address (Y',y) is processed
as follows: as follows:
The stateful NAT64 translator searches for a UDP BIB entry that The stateful NAT64 translator searches for a UDP BIB entry that
contains the BIB IPv6 transport address that matches the IPv6 contains the BIB IPv6 transport address that matches the IPv6
source transport address (X',x). If such an entry does not exist, source transport address (X',x). If such an entry does not exist,
the stateful NAT64 translator tries to create a new entry (if the stateful NAT64 translator tries to create a new entry (if
resources and policy permit). The source IPv6 transport address resources and policy permit). The source IPv6 transport address
of the packet (X',x) is used as the BIB IPv6 transport address, of the packet (X',x) is used as the BIB IPv6 transport address,
and the BIB IPv4 transport address is set to (T,t), which is and the BIB IPv4 transport address is set to (T,t), which is
allocated using the rules defined in Section 4.5.1.1. The result allocated using the rules defined in Section 3.5.1.1. The result
is a BIB entry as follows: (X',x) <--> (T,t). is a BIB entry as follows: (X',x) <--> (T,t).
The stateful NAT64 translator searches for the Session Table Entry The stateful NAT64 translator searches for the Session Table Entry
corresponding to the incoming 5-tuple. If no such entry is found, corresponding to the incoming 5-tuple. If no such entry is found,
the stateful NAT64 translator tries to create a new entry (if the stateful NAT64 translator tries to create a new entry (if
resources and policy permit). The information included in the resources and policy permit). The information included in the
session table is as follows: session table is as follows:
- The STE source IPv6 transport address is set to (X',x), i.e., - The STE source IPv6 transport address is set to (X',x), i.e.,
the source IPv6 transport address contained in the received the source IPv6 transport address contained in the received
skipping to change at page 25, line 26 skipping to change at page 24, line 26
i.e., the destination IPv6 transport address contained in the i.e., the destination IPv6 transport address contained in the
received IPv6 packet. received IPv6 packet.
- The STE source IPv4 transport address is extracted from the - The STE source IPv4 transport address is extracted from the
corresponding UDP BIB entry, i.e., it is set to (T,t). corresponding UDP BIB entry, i.e., it is set to (T,t).
- The STE destination IPv4 transport is set to (Z(Y'),y), y being - The STE destination IPv4 transport is set to (Z(Y'),y), y being
the same port as the STE destination IPv6 transport address and the same port as the STE destination IPv6 transport address and
Z(Y') being algorithmically generated from the IPv6 destination Z(Y') being algorithmically generated from the IPv6 destination
address (i.e., Y') using the reverse algorithm (see address (i.e., Y') using the reverse algorithm (see
Section 4.5.4). Section 3.5.4).
The result is a Session Table Entry as follows: The result is a Session Table Entry as follows:
(X',x),(Y',y) <--> (T,t),(Z(Y'),y) (X',x),(Y',y) <--> (T,t),(Z(Y'),y)
The stateful NAT64 translator sets (or resets) the timer in the The stateful NAT64 translator sets (or resets) the timer in the
Session Table Entry to the maximum session lifetime. The maximum Session Table Entry to the maximum session lifetime. The maximum
session lifetime may be configurable, and the default should be at session lifetime may be configurable, and the default SHOULD be at
least UDP_DEFAULT. The maximum session lifetime MUST NOT be less least UDP_DEFAULT, to comply with REQ-5 in [RFC4787]. The maximum
than UDP_MIN. The packet is translated and forwarded as described session lifetime MUST NOT be less than UDP_MIN. The packet is
in the following sections. translated and forwarded as described in the following sections.
An IPv4 incoming packet, with an incoming tuple with source IPv4 An IPv4 incoming packet, with an incoming tuple with source IPv4
transport address (W,w) and destination IPv4 transport address (T,t) transport address (W,w) and destination IPv4 transport address (T,t)
is processed as follows: is processed as follows:
The stateful NAT64 translator searches for a UDP BIB entry that The stateful NAT64 translator searches for a UDP BIB entry that
contains the BIB IPv4 transport address matching (T,t), i.e., the contains the BIB IPv4 transport address matching (T,t), i.e., the
IPv4 destination transport address in the incoming IPv4 packet. IPv4 destination transport address in the incoming IPv4 packet.
If such an entry does not exist, the packet MUST be dropped. An If such an entry does not exist, the packet MUST be dropped. An
ICMP error message with Type 3 (Destination Unreachable) with Code ICMP error message with Type 3 (Destination Unreachable) with Code
3 (Port Unreachable) may be sent to the original sender of the 3 (Port Unreachable) MAY be sent to the original sender of the
packet. packet.
If the stateful NAT64 translator applies Address-Dependent Filters If the stateful NAT64 translator applies Address-Dependent Filters
on its IPv4 interface, then the stateful NAT64 translator checks on its IPv4 interface, then the stateful NAT64 translator checks
to see if the incoming packet is allowed according to the Address- to see if the incoming packet is allowed according to the Address-
Dependent Filtering rule. To do this, it searches for a Session Dependent Filtering rule. To do this, it searches for a Session
Table Entry with an STE source IPv4 transport address equal to Table Entry with an STE source IPv4 transport address equal to
(T,t), i.e., the destination IPv4 transport address in the (T,t), i.e., the destination IPv4 transport address in the
incoming packet, and STE destination IPv4 address equal to W, incoming packet, and STE destination IPv4 address equal to W,
i.e., the source IPv4 address in the incoming packet. If such an i.e., the source IPv4 address in the incoming packet. If such an
entry is found (there may be more than one), packet processing entry is found (there may be more than one), packet processing
continues. Otherwise, the packet is discarded. If the packet is continues. Otherwise, the packet is discarded. If the packet is
discarded, then an ICMP error message may be sent to the original discarded, then an ICMP error message MAY be sent to the original
sender of the packet. The ICMP error message, if sent, has Type 3 sender of the packet. The ICMP error message, if sent, has Type 3
(Destination Unreachable) and Code 13 (Communication (Destination Unreachable) and Code 13 (Communication
Administratively Prohibited). Administratively Prohibited).
In case the packet is not discarded in the previous processing In case the packet is not discarded in the previous processing
(either because the stateful NAT64 translator is not filtering or (either because the stateful NAT64 translator is not filtering or
because the packet is compliant with the Address-Dependent because the packet is compliant with the Address-Dependent
Filtering rule), then the stateful NAT64 translator searches for Filtering rule), then the stateful NAT64 translator searches for
the Session Table Entry containing the STE source IPv4 transport the Session Table Entry containing the STE source IPv4 transport
address equal to (T,t) and the STE destination IPv4 transport address equal to (T,t) and the STE destination IPv4 transport
skipping to change at page 26, line 37 skipping to change at page 25, line 37
NAT64 translator tries to create a new entry (if resources and NAT64 translator tries to create a new entry (if resources and
policy permit). In case a new UDP Session Table Entry is created, policy permit). In case a new UDP Session Table Entry is created,
it contains the following information: it contains the following information:
- The STE source IPv6 transport address is extracted from the - The STE source IPv6 transport address is extracted from the
corresponding UDP BIB entry. corresponding UDP BIB entry.
- The STE destination IPv6 transport address is set to (Y'(W),w), - The STE destination IPv6 transport address is set to (Y'(W),w),
w being the same port w as the source IPv4 transport address w being the same port w as the source IPv4 transport address
and Y'(W) being the IPv6 representation of W, generated using and Y'(W) being the IPv6 representation of W, generated using
the algorithm described in Section 4.5.4. the algorithm described in Section 3.5.4.
- The STE source IPv4 transport address is set to (T,t), i.e., - The STE source IPv4 transport address is set to (T,t), i.e.,
the destination IPv4 transport addresses contained in the the destination IPv4 transport addresses contained in the
received IPv4 packet. received IPv4 packet.
- The STE destination IPv4 transport is set to (W,w), i.e., the - The STE destination IPv4 transport is set to (W,w), i.e., the
source IPv4 transport addresses contained in the received IPv4 source IPv4 transport addresses contained in the received IPv4
packet. packet.
The stateful NAT64 translator sets (or resets) the timer in the The stateful NAT64 translator sets (or resets) the timer in the
Session Table Entry to the maximum session lifetime. The maximum Session Table Entry to the maximum session lifetime. The maximum
session lifetime may be configurable, and the default should be at session lifetime may be configurable, and the default SHOULD be at
least UDP_DEFAULT. The maximum session lifetime MUST NOT be less least UDP_DEFAULT, to comply with REQ-5 in [RFC4787]. The maximum
than UDP_MIN. The packet is translated and forwarded as described session lifetime MUST NOT be less than UDP_MIN. The packet is
in the following sections. translated and forwarded as described in the following sections.
4.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP 3.5.1.1. Rules for Allocation of IPv4 Transport Addresses for UDP
When a new UDP BIB entry is created for a source transport address of When a new UDP BIB entry is created for a source transport address of
(S',s), the stateful NAT64 translator allocates an IPv4 transport (S',s), the stateful NAT64 translator allocates an IPv4 transport
address for this BIB entry as follows: address for this BIB entry as follows:
If there exists some other BIB entry containing S' as the IPv6 If there exists some other BIB entry containing S' as the IPv6
address and mapping it to some IPv4 address T, then the stateful address and mapping it to some IPv4 address T, then the stateful
NAT64 translator should use T as the IPv4 address. Otherwise, use NAT64 translator SHOULD use T as the IPv4 address. Otherwise, use
any IPv4 address of the IPv4 pool assigned to the stateful NAT64 any IPv4 address of the IPv4 pool assigned to the stateful NAT64
translator to be used for translation. translator to be used for translation.
If the port s is in the Well-Known port range 0-1023, and the If the port s is in the Well-Known port range 0-1023, and the
stateful NAT64 translator has an available port t in the same port stateful NAT64 translator has an available port t in the same port
range, then the stateful NAT64 translator should allocate the port range, then the stateful NAT64 translator SHOULD allocate the port
t. If the stateful NAT64 translator does not have a port t. If the stateful NAT64 translator does not have a port
available in the same range, the stateful NAT64 translator may available in the same range, the stateful NAT64 translator MAY
assign a port t from another range where it has an available port. assign a port t from another range where it has an available port.
(This behaviour is recommended in REQ 3-a of [RFC4787].) (This behaviour is recommended in REQ 3-a of [RFC4787].)
If the port s is in the range 1024-65535, and the stateful NAT64 If the port s is in the range 1024-65535, and the stateful NAT64
translator has an available port t in the same port range, then translator has an available port t in the same port range, then
the stateful NAT64 translator should allocate the port t. If the the stateful NAT64 translator SHOULD allocate the port t. If the
stateful NAT64 translator does not have a port available in the stateful NAT64 translator does not have a port available in the
same range, the stateful NAT64 translator may assign a port t from same range, the stateful NAT64 translator MAY assign a port t from
another range where it has an available port. (This behaviour is another range where it has an available port. (This behaviour is
recommended in REQ 3-a of [RFC4787].) recommended in REQ 3-a of [RFC4787].)
The stateful NAT64 translator should preserve the port parity The stateful NAT64 translator SHOULD preserve the port parity
(odd/even), as per Section 4.2.2 of [RFC4787]. The stateful NAT64 (odd/even), as per Section 4.2.2 of [RFC4787]. The stateful NAT64
translator may disable port parity preservation for all dynamic translator MAY disable port parity preservation for all dynamic
Mappings, per Section 8 of [RFC7857]. Mappings, per Section 8 of [RFC7857].
In all cases, the allocated IPv4 transport address (T,t) MUST NOT In all cases, the allocated IPv4 transport address (T,t) MUST NOT
be in use in another entry in the same BIB, but can be in use in be in use in another entry in the same BIB, but can be in use in
other BIBs (e.g., the TCP and ICMP BIBs). other BIBs (e.g., the TCP and ICMP BIBs).
If it is not possible to allocate an appropriate IPv4 transport If it is not possible to allocate an appropriate IPv4 transport
address or create a BIB entry, then the packet is discarded. In this address or create a BIB entry, then the packet is discarded. In this
case, the stateful NAT64 translator should send an ICMPv6 Destination case, the stateful NAT64 translator SHOULD send an ICMPv6 Destination
Unreachable error message with Code 3 (Address Unreachable). Unreachable error message with Code 3 (Address Unreachable). Sending
such ICMPv6 message may be disabled by local policy (e.g., rate-
limit).
4.5.2. TCP Session Handling 3.5.2. TCP Session Handling
A description about how the TCP BIB and session tables are populated A description about how the TCP BIB and session tables are populated
is provided by defining the state machine that the stateful NAT64 is provided by defining the state machine that the stateful NAT64
translator uses for TCP. First the states and the information translator uses for TCP. First the states and the information
contained in them are described, followed by the actual state machine contained in them are described, followed by the actual state machine
and state transitions. and state transitions.
4.5.2.1. State Definition 3.5.2.1. State Definition
The following state information is stored for a TCP session: The following state information is stored for a TCP session:
Binding:(X',x),(Y',y) <--> (T,t),(Z,z) Binding:(X',x),(Y',y) <--> (T,t),(Z,z)
Lifetime: a timer that tracks the remaining lifetime of the TCP Lifetime: a timer that tracks the remaining lifetime of the TCP
session. When the timer expires, the TCP session is deleted. If session. When the timer expires, the TCP session is deleted. If
all the TCP sessions corresponding to a TCP BIB entry are deleted, all the TCP sessions corresponding to a TCP BIB entry are deleted,
then the dynamically created TCP BIB entry is also deleted. then the dynamically created TCP BIB entry is also deleted.
skipping to change at page 29, line 31 skipping to change at page 28, line 31
TRANS: The lifetime of the state for the connection is set to TRANS: The lifetime of the state for the connection is set to
TCP_TRANS minutes either because a packet containing a TCP RST was TCP_TRANS minutes either because a packet containing a TCP RST was
received by the stateful NAT64 translator for this connection or received by the stateful NAT64 translator for this connection or
simply because the lifetime of the connection has decreased and simply because the lifetime of the connection has decreased and
there are only TCP_TRANS minutes left. The stateful NAT64 there are only TCP_TRANS minutes left. The stateful NAT64
translator will keep the state for the connection for TCP_TRANS translator will keep the state for the connection for TCP_TRANS
minutes, and if no other data packets for that connection are minutes, and if no other data packets for that connection are
received, the state for this connection is then terminated. received, the state for this connection is then terminated.
4.5.2.2. State Machine for TCP Processing in the Stateful NAT64 3.5.2.2. State Machine for TCP Processing in the Stateful NAT64
Translator Translator
The state machine used by the stateful NAT64 translator for the TCP The state machine used by the stateful NAT64 translator for the TCP
session processing is depicted in Figure 2. The described state session processing is depicted in Figure 2. The described state
machine handles all TCP segments received through the IPv6 and IPv4 machine handles all TCP segments received through the IPv6 and IPv4
interface. There is one state machine per TCP connection that is interface. There is one state machine per TCP connection that is
potentially established through the stateful NAT64 translator. After potentially established through the stateful NAT64 translator. After
bootstrapping of the stateful NAT64 function, all TCP sessions are in bootstrapping of the stateful NAT64 function, all TCP sessions are in
CLOSED state. As mentioned above, the CLOSED state is a fictional CLOSED state. As mentioned above, the CLOSED state is a fictional
state when there is no state for that particular connection in the state when there is no state for that particular connection in the
skipping to change at page 31, line 17 skipping to change at page 30, line 17
processing is as follows: processing is as follows:
1. The stateful NAT64 translator searches for a TCP BIB entry that 1. The stateful NAT64 translator searches for a TCP BIB entry that
matches the IPv6 source transport address (X',x). matches the IPv6 source transport address (X',x).
If such an entry does not exist, the stateful NAT64 translator If such an entry does not exist, the stateful NAT64 translator
tries to create a new BIB entry (if resources and policy tries to create a new BIB entry (if resources and policy
permit). The BIB IPv6 transport address is set to (X',x), permit). The BIB IPv6 transport address is set to (X',x),
i.e., the source IPv6 transport address of the packet. The i.e., the source IPv6 transport address of the packet. The
BIB IPv4 transport address is set to an IPv4 transport address BIB IPv4 transport address is set to an IPv4 transport address
allocated using the rules defined in Section 4.5.2.3. The allocated using the rules defined in Section 3.5.2.3. The
processing of the packet continues as described in bullet 2. processing of the packet continues as described in bullet 2.
If the entry already exists, then the processing continues as If the entry already exists, then the processing continues as
described in bullet 2. described in bullet 2.
2. Then the stateful NAT64 translator tries to create a new TCP 2. Then the stateful NAT64 translator tries to create a new TCP
session entry in the TCP session table (if resources and policy session entry in the TCP session table (if resources and policy
permit). The information included in the session table is as permit). The information included in the session table is as
follows: follows:
skipping to change at page 31, line 43 skipping to change at page 30, line 43
i.e., the destination transport address contained in the i.e., the destination transport address contained in the
received V6 SYN packet. received V6 SYN packet.
The STE source IPv4 transport address is set to the BIB IPv4 The STE source IPv4 transport address is set to the BIB IPv4
transport address of the corresponding TCP BIB entry. transport address of the corresponding TCP BIB entry.
The STE destination IPv4 transport address contains the port y The STE destination IPv4 transport address contains the port y
(i.e., the same port as the IPv6 destination transport (i.e., the same port as the IPv6 destination transport
address) and the IPv4 address that is algorithmically address) and the IPv4 address that is algorithmically
generated from the IPv6 destination address (i.e., Y') using generated from the IPv6 destination address (i.e., Y') using
the reverse algorithm as specified in Section 4.5.4. the reverse algorithm as specified in Section 3.5.4.
The lifetime of the TCP Session Table Entry is set to at least The lifetime of the TCP Session Table Entry is set to at least
TCP_TRANS (the transitory connection idle timeout as defined TCP_TRANS (the transitory connection idle timeout as defined
in [RFC5382]). in [RFC5382]).
3. The state of the session is moved to V6 INIT. 3. The state of the session is moved to V6 INIT.
4. The stateful NAT64 function translates and forwards the packet as 4. The stateful NAT64 function translates and forwards the packet as
described in the following sections. described in the following sections.
skipping to change at page 32, line 37 skipping to change at page 31, line 37
i.e., the source transport address contained in the V4 SYN. i.e., the source transport address contained in the V4 SYN.
o The STE source IPv6 transport address is left unspecified o The STE source IPv6 transport address is left unspecified
and may be populated by other protocols that are out of the and may be populated by other protocols that are out of the
scope of this specification. scope of this specification.
o The STE destination IPv6 transport address contains the port o The STE destination IPv6 transport address contains the port
y (i.e., the same port as the STE destination IPv4 transport y (i.e., the same port as the STE destination IPv4 transport
address) and the IPv6 representation of Y (i.e., the IPv4 address) and the IPv6 representation of Y (i.e., the IPv4
address of the STE destination IPv4 transport address), address of the STE destination IPv4 transport address),
generated using the algorithm described in Section 4.5.4. generated using the algorithm described in Section 3.5.4.
- The state is moved to V4 INIT. - The state is moved to V4 INIT.
- The lifetime of the STE entry is set to TCP_INCOMING_SYN as per - The lifetime of the STE entry is set to TCP_INCOMING_SYN as per
[RFC5382], and the packet is stored. The result is that the [RFC5382], and the packet is stored. The result is that the
stateful NAT64 translator will not drop the packet based on the stateful NAT64 translator will not drop the packet based on the
filtering, nor create a BIB entry. Instead, the stateful NAT64 filtering, nor create a BIB entry. Instead, the stateful NAT64
translator will only create the Session Table Entry and store translator will only create the Session Table Entry and store
the packet. The motivation for this is to support simultaneous the packet. The motivation for this is to support simultaneous
open of TCP connections. open of TCP connections.
skipping to change at page 33, line 23 skipping to change at page 32, line 23
i.e., the source transport address contained in the V4 SYN. i.e., the source transport address contained in the V4 SYN.
o The STE source IPv6 transport address is set to the IPv6 o The STE source IPv6 transport address is set to the IPv6
transport address contained in the corresponding TCP BIB transport address contained in the corresponding TCP BIB
entry. entry.
o The STE destination IPv6 transport address contains the port o The STE destination IPv6 transport address contains the port
y (i.e., the same port as the STE destination IPv4 transport y (i.e., the same port as the STE destination IPv4 transport
address) and the IPv6 representation of Y (i.e., the IPv4 address) and the IPv6 representation of Y (i.e., the IPv4
address of the STE destination IPv4 transport address), address of the STE destination IPv4 transport address),
generated using the algorithm described in Section 4.5.4. generated using the algorithm described in Section 3.5.4.
- The state is moved to V4 INIT. - The state is moved to V4 INIT.
- If the stateful NAT64 translator is performing Address- - If the stateful NAT64 translator is performing Address-
Dependent Filtering, the lifetime of the STE entry is set to Dependent Filtering, the lifetime of the STE entry is set to
TCP_INCOMING_SYN as per [RFC5382], and the packet is stored. TCP_INCOMING_SYN as per [RFC5382], and the packet is stored.
The motivation for creating the Session Table Entry and storing The motivation for creating the Session Table Entry and storing
the packet (instead of simply dropping the packet based on the the packet (instead of simply dropping the packet based on the
filtering) is to support simultaneous open of TCP connections. filtering) is to support simultaneous open of TCP connections.
- If the stateful NAT64 translator is not performing Address- - If the stateful NAT64 translator is not performing Address-
Dependent Filtering, the lifetime of the STE is set to at least Dependent Filtering, the lifetime of the STE is set to at least
TCP_TRANS (the transitory connection idle timeout as defined in TCP_TRANS (the transitory connection idle timeout as defined in
[RFC5382]), and it translates and forwards the packet as [RFC5382]), and it translates and forwards the packet as
described in the following sections. described in the following sections.
For any other packet belonging to this connection: For any other packet belonging to this connection:
If there is a corresponding entry in the TCP BIB, the packet If there is a corresponding entry in the TCP BIB, the packet
should be translated and forwarded if the security policy allows SHOULD be translated and forwarded if the security policy allows
doing so. The state remains unchanged. doing so. The state remains unchanged.
Note that a SHOULD level requirement is used here to
accommodate other policies (rate-limit, traffic shaping, etc.)
that may be provided to an implementation.
If there is no corresponding entry in the TCP BIB, the packet is If there is no corresponding entry in the TCP BIB, the packet is
silently discarded. silently discarded.
*** V4 INIT *** *** V4 INIT ***
If a V6 SYN is received with incoming tuple with source transport If a V6 SYN is received with incoming tuple with source transport
address (X',x) and destination transport address (Y',y), then the address (X',x) and destination transport address (Y',y), then the
lifetime of the TCP Session Table Entry is set to at least the lifetime of the TCP Session Table Entry is set to at least the
maximum session lifetime. The value for the maximum session lifetime maximum session lifetime. The value for the maximum session lifetime
may be configurable, but it MUST NOT be less than TCP_EST (the MAY be configurable, but it MUST NOT be less than TCP_EST (the
established connection idle timeout as defined in [RFC5382]). The established connection idle timeout as defined in [RFC5382]). The
default value for the maximum session lifetime should be set to default value for the maximum session lifetime SHOULD be set to
TCP_EST. The packet is translated and forwarded. The state is moved TCP_EST. Per Section 9 of [RFC5382]), an implementation may attempt
to ESTABLISHED. to actively determine the liveliness of a TCP connection when it is
under attack. The packet is translated and forwarded. The state is
moved to ESTABLISHED.
If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code If the lifetime expires, an ICMP Port Unreachable error (Type 3, Code
3) containing the IPv4 SYN packet stored is sent back to the source 3) containing the IPv4 SYN packet stored is sent back to the source
of the v4 SYN, the Session Table Entry is deleted, and the state is of the v4 SYN, the Session Table Entry is deleted, and the state is
moved to CLOSED. moved to CLOSED.
For any other packet, the packet should be translated and forwarded For any other packet, the packet SHOULD be translated and forwarded
if the security policy allows doing so. The state remains unchanged. if the security policy allows doing so. The state remains unchanged.
*** V6 INIT *** *** V6 INIT ***
If a V4 SYN is received (with or without the ACK flag set), with an If a V4 SYN is received (with or without the ACK flag set), with an
incoming tuple with source IPv4 transport address (Y,y) and incoming tuple with source IPv4 transport address (Y,y) and
destination IPv4 transport address (X,x), then the state is moved to destination IPv4 transport address (X,x), then the state is moved to
ESTABLISHED. The lifetime of the TCP Session Table Entry is set to ESTABLISHED. The lifetime of the TCP Session Table Entry is set to
at least the maximum session lifetime. The value for the maximum at least the maximum session lifetime. The value for the maximum
session lifetime may be configurable, but it MUST NOT be less than session lifetime MAY be configurable, but it MUST NOT be less than
TCP_EST (the established connection idle timeout as defined in TCP_EST (the established connection idle timeout as defined in
[RFC5382]). The default value for the maximum session lifetime [RFC5382]). The default value for the maximum session lifetime
should be set to TCP_EST. The packet is translated and forwarded. SHOULD be set to TCP_EST. Per Section 9 of [RFC5382]), an
implementation may attempt to actively determine the liveliness of a
TCP connection when it is under attack. The packet is translated and
forwarded.
If the lifetime expires, the Session Table Entry is deleted, and the If the lifetime expires, the Session Table Entry is deleted, and the
state is moved to CLOSED. state is moved to CLOSED.
If a V6 SYN packet is received, the packet is translated and If a V6 SYN packet is received, the packet is translated and
forwarded. The lifetime of the TCP Session Table Entry is set to at forwarded. The lifetime of the TCP Session Table Entry is set to at
least TCP_TRANS. The state remains unchanged. least TCP_TRANS. The state remains unchanged.
For any other packet, the packet should be translated and forwarded For any other packet, the packet SHOULD be translated and forwarded
if the security policy allows doing so. The state remains unchanged. if the security policy allows doing so. The state remains unchanged.
*** ESTABLISHED *** *** ESTABLISHED ***
If a V4 FIN packet is received, the packet is translated and If a V4 FIN packet is received, the packet is translated and
forwarded. The state is moved to V4 FIN RCV. forwarded. The state is moved to V4 FIN RCV.
If a V6 FIN packet is received, the packet is translated and If a V6 FIN packet is received, the packet is translated and
forwarded. The state is moved to V6 FIN RCV. forwarded. The state is moved to V6 FIN RCV.
If a V4 RST or a V6 RST packet is received, the packet is translated If a V4 RST or a V6 RST packet is received, the packet is translated
and forwarded. The lifetime is set to TCP_TRANS and the state is and forwarded. The lifetime is set to TCP_TRANS and the state is
moved to TRANS. (Since the stateful NAT64 translator is uncertain moved to TRANS. (Since the stateful NAT64 translator is uncertain
whether the peer will accept the RST packet, instead of moving the whether the peer will accept the RST packet, instead of moving the
skipping to change at page 35, line 20 skipping to change at page 34, line 25
no other packets are received for this connection during the short no other packets are received for this connection during the short
timer, the stateful NAT64 translator assumes that the peer has timer, the stateful NAT64 translator assumes that the peer has
accepted the RST packet and moves to CLOSED. If packets keep accepted the RST packet and moves to CLOSED. If packets keep
flowing, the stateful NAT64 translator assumes that the peer has not flowing, the stateful NAT64 translator assumes that the peer has not
accepted the RST packet and moves back to the ESTABLISHED state. accepted the RST packet and moves back to the ESTABLISHED state.
This is described below in the TRANS state processing description.) This is described below in the TRANS state processing description.)
If any other packet is received, the packet is translated and If any other packet is received, the packet is translated and
forwarded. The lifetime of the TCP Session Table Entry is set to at forwarded. The lifetime of the TCP Session Table Entry is set to at
least the maximum session lifetime. The value for the maximum least the maximum session lifetime. The value for the maximum
session lifetime may be configurable, but it MUST NOT be less than session lifetime MAY be configurable, but it MUST NOT be less than
TCP_EST (the established connection idle timeout as defined in TCP_EST (the established connection idle timeout as defined in
[RFC5382]). The default value for the maximum session lifetime [RFC5382]). The default value for the maximum session lifetime
should be set to TCP_EST. The state remains unchanged as SHOULD be set to TCP_EST. Per Section 9 of [RFC5382]), an
ESTABLISHED. implementation may attempt to actively determine the liveliness of a
TCP connection when it is under attack. The state remains unchanged
as ESTABLISHED.
If the lifetime expires, then the stateful NAT64 translator should If the lifetime expires, then the stateful NAT64 translator SHOULD
send a probe packet (as defined next) to at least one of the send a probe packet (as defined next) to at least one of the
endpoints of the TCP connection. The probe packet is a TCP segment endpoints of the TCP connection. The probe packet is a TCP segment
for the connection with no data. The sequence number and the for the connection with no data. The sequence number and the
acknowledgment number are set to zero. All flags but the ACK flag acknowledgment number are set to zero. All flags but the ACK flag
are set to zero. The state is moved to TRANS. are set to zero. The state is moved to TRANS.
Upon the reception of this probe packet, the endpoint will reply Upon the reception of this probe packet, the endpoint will reply
with an ACK containing the expected sequence number for that with an ACK containing the expected sequence number for that
connection. It should be noted that, for an active connection, connection. It should be noted that, for an active connection,
each of these probe packets will generate one packet from each end each of these probe packets will generate one packet from each end
skipping to change at page 36, line 8 skipping to change at page 35, line 8
*** V4 FIN RCV *** *** V4 FIN RCV ***
If a V6 FIN packet is received, the packet is translated and If a V6 FIN packet is received, the packet is translated and
forwarded. The lifetime is set to TCP_TRANS. The state is moved to forwarded. The lifetime is set to TCP_TRANS. The state is moved to
V6 FIN + V4 FIN RCV. V6 FIN + V4 FIN RCV.
If any packet other than the V6 FIN is received, the packet is If any packet other than the V6 FIN is received, the packet is
translated and forwarded. The lifetime of the TCP Session translated and forwarded. The lifetime of the TCP Session
Table Entry is set to at least the maximum session lifetime. The Table Entry is set to at least the maximum session lifetime. The
value for the maximum session lifetime may be configurable, but it value for the maximum session lifetime MAY be configurable, but it
MUST NOT be less than TCP_EST (the established connection idle MUST NOT be less than TCP_EST (the established connection idle
timeout as defined in [RFC5382]). The default value for the maximum timeout as defined in [RFC5382]). The default value for the maximum
session lifetime should be set to TCP_EST. The state remains session lifetime SHOULD be set to TCP_EST. Per Section 9 of
unchanged as V4 FIN RCV. [RFC5382]), an implementation may attempt to actively determine the
liveliness of a TCP connection when it is under attack. The state
remains unchanged as V4 FIN RCV.
If the lifetime expires, the Session Table Entry is deleted, and the If the lifetime expires, the Session Table Entry is deleted, and the
state is moved to CLOSED. state is moved to CLOSED.
*** V6 FIN RCV *** *** V6 FIN RCV ***
If a V4 FIN packet is received, the packet is translated and If a V4 FIN packet is received, the packet is translated and
forwarded. The lifetime is set to TCP_TRANS. The state is moved to forwarded. The lifetime is set to TCP_TRANS. The state is moved to
V6 FIN + V4 FIN RCV. V6 FIN + V4 FIN RCV.
If any packet other than the V4 FIN is received, the packet is If any packet other than the V4 FIN is received, the packet is
translated and forwarded. The lifetime of the TCP Session translated and forwarded. The lifetime of the TCP Session
Table Entry is set to at least the maximum session lifetime. The Table Entry is set to at least the maximum session lifetime. The
value for the maximum session lifetime may be configurable, but it value for the maximum session lifetime MAY be configurable, but it
MUST NOT be less than TCP_EST (the established connection idle MUST NOT be less than TCP_EST (the established connection idle
timeout as defined in [RFC5382]). The default value for the maximum timeout as defined in [RFC5382]). The default value for the maximum
session lifetime should be set to TCP_EST. The state remains session lifetime SHOULD be set to TCP_EST. Per Section 9 of
unchanged as V6 FIN RCV. [RFC5382]), an implementation may attempt to actively determine the
liveliness of a TCP connection when it is under attack. The state
remains unchanged as V6 FIN RCV.
If the lifetime expires, the Session Table Entry is deleted and the If the lifetime expires, the Session Table Entry is deleted and the
state is moved to CLOSED. state is moved to CLOSED.
*** V6 FIN + V4 FIN RCV *** *** V6 FIN + V4 FIN RCV ***
All packets are translated and forwarded. All packets are translated and forwarded.
If the lifetime expires, the Session Table Entry is deleted and the If the lifetime expires, the Session Table Entry is deleted and the
state is moved to CLOSED. state is moved to CLOSED.
*** TRANS *** *** TRANS ***
If a packet other than a RST packet is received, the lifetime of the If a packet other than a RST packet is received, the lifetime of the
TCP Session Table Entry is set to at least the maximum session TCP Session Table Entry is set to at least the maximum session
lifetime. The value for the maximum session lifetime may be lifetime. The value for the maximum session lifetime MAY be
configurable, but it MUST NOT be less than TCP_EST (the established configurable, but it MUST NOT be less than TCP_EST (the established
connection idle timeout as defined in [RFC5382]). The default value connection idle timeout as defined in [RFC5382]). The default value
for the maximum session lifetime should be set to TCP_EST. The state for the maximum session lifetime SHOULD be set to TCP_EST. Per
is moved to ESTABLISHED. Section 9 of [RFC5382]), an implementation may attempt to actively
determine the liveliness of a TCP connection when it is under attack.
The state is moved to ESTABLISHED.
If the lifetime expires, the Session Table Entry is deleted and the If the lifetime expires, the Session Table Entry is deleted and the
state is moved to CLOSED. state is moved to CLOSED.
4.5.2.3. Rules for Allocation of IPv4 Transport Addresses for TCP 3.5.2.3. Rules for Allocation of IPv4 Transport Addresses for TCP
When a new TCP BIB entry is created for a source transport address of When a new TCP BIB entry is created for a source transport address of
(S',s), the stateful NAT64 translator allocates an IPv4 transport (S',s), the stateful NAT64 translator allocates an IPv4 transport
address for this BIB entry as follows: address for this BIB entry as follows:
If there exists some other BIB entry in any of the BIBs that If there exists some other BIB entry in any of the BIBs that
contains S' as the IPv6 address and maps it to some IPv4 address contains S' as the IPv6 address and maps it to some IPv4 address
T, then T should be used as the IPv4 address. Otherwise, use any T, then T SHOULD be used as the IPv4 address. Otherwise, use any
IPv4 address of the IPv4 pool assigned to the stateful NAT64 IPv4 address of the IPv4 pool assigned to the stateful NAT64
translator to be used for translation. translator to be used for translation.
If the port s is in the Well-Known port range 0-1023, and the If the port s is in the Well-Known port range 0-1023, and the
stateful NAT64 translator has an available port t in the same port stateful NAT64 translator has an available port t in the same port
range, then the stateful NAT64 translator should allocate the port range, then the stateful NAT64 translator SHOULD allocate the port
t. If the stateful NAT64 translator does not have a port t. If the stateful NAT64 translator does not have a port
available in the same range, the stateful NAT64 translator may available in the same range, the stateful NAT64 translator MAY
assign a port t from another range where it has an available port. assign a port t from another range where it has an available port.
If the port s is in the range 1024-65535, and the stateful NAT64 If the port s is in the range 1024-65535, and the stateful NAT64
translator has an available port t in the same port range, then translator has an available port t in the same port range, then
the stateful NAT64 translator should allocate the port t. If the the stateful NAT64 translator SHOULD allocate the port t. If the
stateful NAT64 translator does not have a port available in the stateful NAT64 translator does not have a port available in the
same range, the stateful NAT64 translator may assign a port t from same range, the stateful NAT64 translator MAY assign a port t from
another range where it has an available port. another range where it has an available port.
In all cases, the allocated IPv4 transport address (T,t) MUST NOT In all cases, the allocated IPv4 transport address (T,t) MUST NOT
be in use in another entry in the same BIB, but can be in use in be in use in another entry in the same BIB, but can be in use in
other BIBs (e.g., the UDP and ICMP BIBs). other BIBs (e.g., the UDP and ICMP BIBs).
If it is not possible to allocate an appropriate IPv4 transport If it is not possible to allocate an appropriate IPv4 transport
address or create a BIB entry, then the packet is discarded. In this address or create a BIB entry, then the packet is discarded. In this
case, the stateful NAT64 translator should send an ICMPv6 Destination case, the stateful NAT64 translator SHOULD send an ICMPv6 Destination
Unreachable error message with Code 3 (Address Unreachable). Unreachable error message with Code 3 (Address Unreachable). Sending
such ICMPv6 message may be disabled by local policy (e.g., rate-
limit).
4.5.3. ICMP Query Session Handling 3.5.3. ICMP Query Session Handling
The following state information is stored for an ICMP Query session The following state information is stored for an ICMP Query session
in the ICMP Query session table: in the ICMP Query session table:
Binding: [X',Y',i1] <--> [T,Z,i2] Binding: [X',Y',i1] <--> [T,Z,i2]
Lifetime: a timer that tracks the remaining lifetime of the ICMP Lifetime: a timer that tracks the remaining lifetime of the ICMP
Query session. When the timer expires, the session is deleted. Query session. When the timer expires, the session is deleted.
If all the ICMP Query sessions corresponding to a dynamically If all the ICMP Query sessions corresponding to a dynamically
created ICMP Query BIB entry are deleted, then the ICMP Query BIB created ICMP Query BIB entry are deleted, then the ICMP Query BIB
entry is also deleted. entry is also deleted.
An incoming ICMPv6 Informational packet with IPv6 source address X', An incoming ICMPv6 Informational packet with IPv6 source address X',
IPv6 destination address Y', and ICMPv6 Identifier i1 is processed as IPv6 destination address Y', and ICMPv6 Identifier i1 is processed as
follows: follows:
skipping to change at page 39, line 13 skipping to change at page 38, line 19
contained in the received IPv6 packet). contained in the received IPv6 packet).
- The STE IPv4 source address is set to the IPv4 address - The STE IPv4 source address is set to the IPv4 address
contained in the corresponding BIB entry. contained in the corresponding BIB entry.
- The STE ICMPv4 Identifier is set to the IPv4 identifier - The STE ICMPv4 Identifier is set to the IPv4 identifier
contained in the corresponding BIB entry. contained in the corresponding BIB entry.
- The STE IPv4 destination address is algorithmically generated - The STE IPv4 destination address is algorithmically generated
from Y' using the reverse algorithm as specified in from Y' using the reverse algorithm as specified in
Section 4.5.4. Section 3.5.4.
The stateful NAT64 translator sets (or resets) the timer in the The stateful NAT64 translator sets (or resets) the timer in the
session table entry to the maximum session lifetime. By default, session table entry to the maximum session lifetime. By default,
the maximum session lifetime is ICMP_DEFAULT. The maximum the maximum session lifetime is ICMP_DEFAULT. The maximum
lifetime value should be configurable. lifetime value SHOULD be configurable to comply with REQ-2 in
[RFC5508].
The packet is translated and forwarded as described in the The packet is translated and forwarded as described in the
following sections. following sections.
An incoming ICMPv4 Query packet with source IPv4 address Y, An incoming ICMPv4 Query packet with source IPv4 address Y,
destination IPv4 address X, and ICMPv4 Identifier i2 is processed as destination IPv4 address X, and ICMPv4 Identifier i2 is processed as
follows: follows:
The stateful NAT64 translator searches for an ICMP Query BIB entry The stateful NAT64 translator searches for an ICMP Query BIB entry
that contains X as the IPv4 address and i2 as the ICMPv4 that contains X as the IPv4 address and i2 as the ICMPv4
Identifier. If such an entry does not exist, the packet is Identifier. If such an entry does not exist, the packet is
dropped. An ICMP error message may be sent to the original sender dropped. An ICMP error message MAY be sent to the original sender
of the packet. The ICMP error message, if sent, has Type 3, Code of the packet. The ICMP error message, if sent, has Type 3, Code
1 (Host Unreachable). 1 (Host Unreachable).
In contrast to the UDP and TCP specifications in previous In contrast to the UDP and TCP specifications in previous
sections, ICMP Query session have no transport ports and therefore sections, ICMP Query session have no transport ports and therefore
there is no analogous Address-Dependent Filtering case at that there is no analogous Address-Dependent Filtering case at that
stage. stage.
Consequently, in case the packet is not discarded in the previous Consequently, in case the packet is not discarded in the previous
processing steps, the stateful NAT64 translator then searches for processing steps, the stateful NAT64 translator then searches for
skipping to change at page 40, line 13 skipping to change at page 39, line 19
- The STE destination IPv4 address is set to Y. - The STE destination IPv4 address is set to Y.
- The STE source IPv6 address is set to the IPv6 address of the - The STE source IPv6 address is set to the IPv6 address of the
corresponding BIB entry. corresponding BIB entry.
- The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of - The STE ICMPv6 Identifier is set to the ICMPv6 Identifier of
the corresponding BIB entry. the corresponding BIB entry.
- The STE destination IPv6 address is set to the IPv6 - The STE destination IPv6 address is set to the IPv6
representation of the IPv4 address of Y, generated using the representation of the IPv4 address of Y, generated using the
algorithm described in Section 4.5.4. algorithm described in Section 3.5.4.
- The stateful NAT64 translator sets (or resets) the timer in the - The stateful NAT64 translator sets (or resets) the timer in the
session table entry to the maximum session lifetime. By session table entry to the maximum session lifetime. By
default, the maximum session lifetime is ICMP_DEFAULT. The default, the maximum session lifetime is ICMP_DEFAULT. The
maximum lifetime value should be configurable. The packet is maximum lifetime value SHOULD be configurable to comply with
translated and forwarded as described in the following REQ-2 in [RFC5508]. The packet is translated and forwarded as
sections. described in the following sections.
4.5.4. Generation of the IPv6 Representations of IPv4 Addresses 3.5.4. Generation of the IPv6 Representations of IPv4 Addresses
A stateful NAT64 translator supports multiple algorithms for the A stateful NAT64 translator supports multiple algorithms for the
generation of the IPv6 representation of an IPv4 address and vice generation of the IPv6 representation of an IPv4 address and vice
versa. The constraints imposed on the generation algorithms are the versa. The constraints imposed on the generation algorithms are the
following: following:
The algorithm MUST be reversible, i.e., it MUST be possible to The algorithm MUST be reversible, i.e., it MUST be possible to
derive the original IPv4 address from the IPv6 representation. derive the original IPv4 address from the IPv6 representation.
The input for the algorithm MUST be limited to the IPv4 address, The input for the algorithm MUST be limited to the IPv4 address,
the IPv6 prefix (denoted Pref64::/n) used in the IPv6 the IPv6 prefix (denoted Pref64::/n) used in the IPv6
representations, and optionally a set of stable parameters that representations, and optionally a set of stable parameters that
are configured in the stateful NAT64 translator (such as a fixed are configured in the stateful NAT64 translator (such as a fixed
string to be used as a suffix). string to be used as a suffix).
- "n" is the length of the prefix Pref64::/n, and MUST be less - "n" is the length of the prefix Pref64::/n, and MUST be less
than or equal to 96. If a Pref64::/n is configured through any than or equal to 96. If a Pref64::/n is configured through any
means in the stateful NAT64 translator (such as manually means in the stateful NAT64 translator (such as manually
configured, or other automatic means not specified in this configured, or other automatic means not specified in this
document), the default algorithm MUST use this prefix. If no document), the default algorithm MUST use this prefix. If no
prefix is configured, the algorithm should use the Well-Known prefix is configured, the algorithm SHOULD use the Well-Known
Prefix (64:ff9b::/96) defined in [RFC6052]. Prefix (64:ff9b::/96) defined in [RFC6052].
A stateful NAT64 translator MUST support the algorithm for generating A stateful NAT64 translator MUST support the algorithm for generating
IPv6 representations of IPv4 addresses defined in Section 2.3 of IPv6 representations of IPv4 addresses defined in Section 2.3 of
[RFC6052]. The aforementioned algorithm should be used as default [RFC6052]. The aforementioned algorithm SHOULD be used as default
algorithm. algorithm.
4.6. Computing the Outgoing Tuple 3.6. Computing the Outgoing Tuple
This step computes the outgoing tuple by translating the IP addresses This step computes the outgoing tuple by translating the IP addresses
and port numbers or ICMP Identifier in the incoming tuple. and port numbers or ICMP Identifier in the incoming tuple.
In the text below, a reference to a BIB means the UDP BIB, the TCP In the text below, a reference to a BIB means the UDP BIB, the TCP
BIB, or the ICMP Query BIB, as appropriate. BIB, or the ICMP Query BIB, as appropriate.
NOTE: Not all addresses are translated using the BIB. BIB entries NOTE: Not all addresses are translated using the BIB. BIB entries
are used to translate IPv6 source transport addresses to IPv4 are used to translate IPv6 source transport addresses to IPv4
source transport addresses, and IPv4 destination transport source transport addresses, and IPv4 destination transport
addresses to IPv6 destination transport addresses. They are NOT addresses to IPv6 destination transport addresses. They are NOT
used to translate IPv6 destination transport addresses to IPv4 used to translate IPv6 destination transport addresses to IPv4
destination transport addresses, nor to translate IPv4 source destination transport addresses, nor to translate IPv4 source
transport addresses to IPv6 source transport addresses. The transport addresses to IPv6 source transport addresses. The
latter cases are handled by applying the algorithmic latter cases are handled by applying the algorithmic
transformation described in Section 4.5.4. This distinction is transformation described in Section 3.5.4. This distinction is
important; without it, hairpinning doesn't work correctly. important; without it, hairpinning doesn't work correctly.
4.6.1. Computing the Outgoing 5-Tuple for UDP, TCP, and for ICMP Error 3.6.1. Computing the Outgoing 5-Tuple for UDP, TCP, and for ICMP Error
Messages Containing UDP or TCP Packets Messages Containing UDP or TCP Packets
The transport protocol in the outgoing 5-tuple is always the same as The transport protocol in the outgoing 5-tuple is always the same as
that in the incoming 5-tuple. When translating from IPv4 ICMP to that in the incoming 5-tuple. When translating from IPv4 ICMP to
IPv6 ICMP, the protocol number in the last next header field in the IPv6 ICMP, the protocol number in the last next header field in the
protocol chain is set to 58 (IPv6-ICMP). When translating from IPv6 protocol chain is set to 58 (IPv6-ICMP). When translating from IPv6
ICMP to IPv4 ICMP, the protocol number in the protocol field of the ICMP to IPv4 ICMP, the protocol number in the protocol field of the
IP header is set to 1 (ICMPv4). IP header is set to 1 (ICMPv4).
When translating in the IPv6 --> IPv4 direction, let the source and When translating in the IPv6 --> IPv4 direction, let the source and
destination transport addresses in the incoming 5-tuple be (S',s) and destination transport addresses in the incoming 5-tuple be (S',s) and
(D',d), respectively. The outgoing source transport address is (D',d), respectively. The outgoing source transport address is
computed as follows: if the BIB contains an entry (S',s) <--> (T,t), computed as follows: if the BIB contains an entry (S',s) <--> (T,t),
then the outgoing source transport address is (T,t). then the outgoing source transport address is (T,t).
The outgoing destination address is computed algorithmically from D' The outgoing destination address is computed algorithmically from D'
using the address transformation described in Section 4.5.4. using the address transformation described in Section 3.5.4.
When translating in the IPv4 --> IPv6 direction, let the source and When translating in the IPv4 --> IPv6 direction, let the source and
destination transport addresses in the incoming 5-tuple be (S,s) and destination transport addresses in the incoming 5-tuple be (S,s) and
(D,d), respectively. The outgoing source transport address is (D,d), respectively. The outgoing source transport address is
computed as follows: computed as follows:
The outgoing source transport address is generated from S using The outgoing source transport address is generated from S using
the address transformation algorithm described in Section 4.5.4. the address transformation algorithm described in Section 3.5.4.
The BIB table is searched for an entry (X',x) <--> (D,d), and if The BIB table is searched for an entry (X',x) <--> (D,d), and if
one is found, the outgoing destination transport address is set to one is found, the outgoing destination transport address is set to
(X',x). (X',x).
4.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages and for 3.6.2. Computing the Outgoing 3-Tuple for ICMP Query Messages and for
ICMP Error Messages Containing an ICMP Query ICMP Error Messages Containing an ICMP Query
When translating in the IPv6 --> IPv4 direction, let the source and When translating in the IPv6 --> IPv4 direction, let the source and
destination addresses in the incoming 3-tuple be S' and D', destination addresses in the incoming 3-tuple be S' and D',
respectively, and the ICMPv6 Identifier be i1. The outgoing source respectively, and the ICMPv6 Identifier be i1. The outgoing source
address is computed as follows: if the BIB contains an entry (S',i1) address is computed as follows: if the BIB contains an entry (S',i1)
<--> (T,i2), then the outgoing source address is T and the ICMPv4 <--> (T,i2), then the outgoing source address is T and the ICMPv4
Identifier is i2. Identifier is i2.
The outgoing IPv4 destination address is computed algorithmically The outgoing IPv4 destination address is computed algorithmically
from D' using the address transformation described in Section 4.5.4. from D' using the address transformation described in Section 3.5.4.
When translating in the IPv4 --> IPv6 direction, let the source and When translating in the IPv4 --> IPv6 direction, let the source and
destination addresses in the incoming 3-tuple be S and D, destination addresses in the incoming 3-tuple be S and D,
respectively, and the ICMPv4 Identifier is i2. The outgoing source respectively, and the ICMPv4 Identifier is i2. The outgoing source
address is generated from S using the address transformation address is generated from S using the address transformation
algorithm described in Section 4.5.4. The BIB is searched for an algorithm described in Section 3.5.4. The BIB is searched for an
entry containing (X',i1) <--> (D,i2), and, if found, the outgoing entry containing (X',i1) <--> (D,i2), and, if found, the outgoing
destination address is X' and the outgoing ICMPv6 Identifier is i1. destination address is X' and the outgoing ICMPv6 Identifier is i1.
4.7. Translating the Packet 3.7. Translating the Packet
This step translates the packet from IPv6 to IPv4 or vice versa. This step translates the packet from IPv6 to IPv4 or vice versa.
The translation of the packet is as specified in Sections 4 and 5 of The translation of the packet is as specified in Sections 4 and 5 of
the IP/ICMP Translation Algorithm [RFC7915], with the following the IP/ICMP Translation Algorithm [RFC7915], with the following
modifications: modifications:
* When translating an IP header (Sections 4.1 and 5.1 of [RFC7915]), * When translating an IP header (Sections 4.1 and 5.1 of [RFC7915]),
the source and destination IP address fields are set to the source the source and destination IP address fields are set to the source
and destination IP addresses from the outgoing tuple as determined and destination IP addresses from the outgoing tuple as determined
in Section 4.6. in Section 3.6.
* When the protocol following the IP header is UDP or TCP, then the * When the protocol following the IP header is UDP or TCP, then the
source and destination ports are modified to the source and source and destination ports are modified to the source and
destination ports from the outgoing 5-tuple. In addition, the UDP destination ports from the outgoing 5-tuple. In addition, the UDP
or TCP checksum must also be updated to reflect the translated or TCP checksum must also be updated to reflect the translated
addresses and ports; note that the UDP and TCP checksum covers the addresses and ports; note that the UDP and TCP checksum covers the
pseudo-header that contains the source and destination IP pseudo-header that contains the source and destination IP
addresses. An algorithm for efficiently updating these checksums addresses. An algorithm for efficiently updating these checksums
is described in [RFC3022]. is described in [RFC3022].
* When the protocol following the IP header is ICMP and it is an * When the protocol following the IP header is ICMP and it is an
ICMP Query message, the ICMP Identifier is set to the one from the ICMP Query message, the ICMP Identifier is set to the one from the
outgoing 3-tuple as determined in Section 4.6.2. outgoing 3-tuple as determined in Section 3.6.2.
* When the protocol following the IP header is ICMP error containing * When the protocol following the IP header is ICMP error containing
an ICMP Query message, the source and destination addresses and an ICMP Query message, the source and destination addresses and
ICMP identifier in the embedded packet are set to the destination ICMP identifier in the embedded packet are set to the destination
and source transport addresses from the outgoing 3-tuple (note the and source transport addresses from the outgoing 3-tuple (note the
swap of source and destination). swap of source and destination).
* When the protocol following the IP header is ICMP and it is an * When the protocol following the IP header is ICMP and it is an
ICMP error message, the source and destination transport addresses ICMP error message, the source and destination transport addresses
in the embedded packet are set to the destination and source in the embedded packet are set to the destination and source
transport addresses from the outgoing 5-tuple (note the swap of transport addresses from the outgoing 5-tuple (note the swap of
source and destination). source and destination).
The size of outgoing packets as well and the potential need for The size of outgoing packets as well and the potential need for
fragmentation is done according to the behaviour defined in the IP/ fragmentation is done according to the behaviour defined in the IP/
ICMP Translation Algorithm [RFC7915]. ICMP Translation Algorithm [RFC7915].
Other IP fields, such as the IP DSCP [RFC2474] and ECN Fields By default, other IP fields, such as the IP DSCP [RFC2474] and ECN
[RFC3168] are copied to the translated packet. These fields have Fields [RFC3168] are copied to the translated packet. These fields
identical semantics in IPv4 and IPv6. have identical semantics in IPv4 and IPv6.
4.8. Handling Hairpinning 3.8. Handling Hairpinning
If the destination IP address of the translated packet is an IPv4 If the destination IP address of the translated packet is an IPv4
address assigned to the stateful NAT64 translator itself, then the address assigned to the stateful NAT64 translator itself, then the
packet is a hairpin packet. Hairpin packets are processed as packet is a hairpin packet. Hairpin packets are processed as
follows: follows:
* The outgoing 5-tuple becomes the incoming 5-tuple. * The outgoing 5-tuple becomes the incoming 5-tuple.
* The packet is treated as if it was received on the outgoing * The packet is treated as if it was received on the outgoing
interface. interface.
* Processing of the packet continues at step 2 - "Filtering and * Processing of the packet continues at step 2 - "Filtering and
Updating Binding and Session Information" (Section 4.5). Updating Binding and Session Information" (Section 3.5).
5. Protocol Constants 4. Protocol Constants
UDP_MIN: 2 minutes (as defined in [RFC4787]) UDP_MIN: 2 minutes (as defined in [RFC4787])
UDP_DEFAULT: 5 minutes (as defined in [RFC4787]) UDP_DEFAULT: 5 minutes (as defined in [RFC4787])
TCP_TRANS: 4 minutes (as defined in [RFC5382]) TCP_TRANS: 4 minutes (as defined in [RFC5382])
TCP_EST: 2 hours (The minimum lifetime for an established TCP session TCP_EST: 2 hours (The minimum lifetime for an established TCP session
defined in [RFC5382] is 2 hours and 4 minutes, which is achieved by defined in [RFC5382] is 2 hours and 4 minutes, which is achieved by
adding the 2 hours with this timer and the 4 minutes with the adding the 2 hours with this timer and the 4 minutes with the
TCP_TRANS timer.) TCP_TRANS timer.)
TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382]) TCP_INCOMING_SYN: 6 seconds (as defined in [RFC5382])
FRAGMENT_MIN: 2 seconds FRAGMENT_MIN: 2 seconds
ICMP_DEFAULT: 60 seconds (as defined in [RFC5508]) ICMP_DEFAULT: 60 seconds (as defined in [RFC5508])
5. Stateful NAT64 Prefix Considerations
5.1. Stateful NAT64 Prefix
The stateful NAT64 protocol does not make an assumption about whether
the WKP or a Network Specific Prefix (NSP) is used. Such decision is
deployment-specific. However, [RFC6052] used to have a deployment
constraint for the use of WKP and includes a restriction against the
use of non-global IPv4 addresses. This restriction is relaxed in
[I-D.ietf-v6ops-nat64-wkp-1918].
Note for the RFC Editor, please remove this note before publication.
If [I-D.ietf-v6ops-nat64-wkp-1918] has not been published when
publishing this document, to avoid holding the document, the last
sentence of the previous paragraph should be shortened as "This
restriction maybe relaxed in the future", removing the reference.
Further, [RFC8215] specifies a Local-Use IPv4/IPv6 Translation
Prefix, adjacent to the WKP, facilitating the coexistence of multiple
IPv4/IPv6 translation mechanisms in a single network domain.
5.2. Stateful NAT64 Prefix Discovery
In order to improve the discovery by clients of the Pref64::/n being
used by the stateful NAT64 translator, [RFC8781] specifies a ND
option to be used in RAs. [RFC9872] further provides a
recommendation for using [RFC8781] instead of a best effort method as
defined by [RFC7050] (updated by [RFC8880]).
One more alternative is specified by [RFC7225] "Discovering NAT64
IPv6 Prefixes Using the Port Control Protocol (PCP)".
Section 3 of [RFC7051] already exposed the issues of the stateful
NAT64 prefix discovery, and most of them are resolved in [RFC8781],
but it is important for operators to review that in order to ensure a
proper deployment.
It should be noticed that the DHCPv6 OPTION_V6_PREFIX64, defined in
[RFC8115], is not a stateful NAT64 prefix discovery mechanism and
should not be used for that purpose. This is remarked to ensure
avoiding confusion for deployers who notice the option name or the
uPrefix64 field.
6. Operational Considerations 6. Operational Considerations
Since [RFC6146] was published, there have been a notable number of Since [RFC6146] was published, there have been a notable number of
specifications that, in conjunction with the stateful NAT64 specifications that, in conjunction with the stateful NAT64
translation, have made significant improvements in the deployment of translation, have made significant improvements in the deployment of
IPv6, greatly facilitating the transition. IPv6, greatly facilitating the transition.
This non-normative section briefly summarizes those specifications This non-normative section briefly summarizes those specifications
and their relevance to the stateful NAT64 translation updated and their relevance to the stateful NAT64 translation updated
specification, as well as relevant operational considerations. specification, as well as relevant operational considerations.
skipping to change at page 49, line 34 skipping to change at page 49, line 43
Independent Mapping". This means: Independent Mapping". This means:
For any IPv6 packet with source (S'1,s1) and destination For any IPv6 packet with source (S'1,s1) and destination
(Pref64::D1,d1) that creates an external mapping to (S1,s1v4), (Pref64::D1,d1) that creates an external mapping to (S1,s1v4),
(D1,d1), for any subsequent packet from (S'1,s1) to (D1,d1), for any subsequent packet from (S'1,s1) to
(Pref64::D2,d2) that creates an external mapping to (S2,s2v4), (Pref64::D2,d2) that creates an external mapping to (S2,s2v4),
(D2,d2), within a given binding timer window, (D2,d2), within a given binding timer window,
(S1,s1v4) = (S2,s2v4) for all values of D2,d2 (S1,s1v4) = (S2,s2v4) for all values of D2,d2
Implementations may also provide support for "Address-Dependent Implementations MAY also provide support for "Address-Dependent
Mapping" as also defined in this specification and following the Mapping" as also defined in this specification and following the
guidelines defined in [RFC4787]. guidelines defined in [RFC4787].
The security properties, however, are determined by which packets the The security properties, however, are determined by which packets the
stateful NAT64 translator filter allows in and which it does not. stateful NAT64 translator filter allows in and which it does not.
The security properties are determined by the filtering behaviour and The security properties are determined by the filtering behaviour and
filtering configuration in the filtering portions of the stateful filtering configuration in the filtering portions of the stateful
NAT64 translator, not by the address mapping behaviour. For example: NAT64 translator, not by the address mapping behaviour. For example:
Without filtering - When "Endpoint-Independent Mapping" is used in Without filtering - When "Endpoint-Independent Mapping" is used in
skipping to change at page 50, line 31 skipping to change at page 50, line 38
but instead by its filtering behaviour. but instead by its filtering behaviour.
As currently specified, the stateful NAT64 translator only requires As currently specified, the stateful NAT64 translator only requires
filtering traffic based on the 5-tuple. In some cases (e.g., filtering traffic based on the 5-tuple. In some cases (e.g.,
statically configured mappings), this may make it easy for an statically configured mappings), this may make it easy for an
attacker to guess. An attacker need not be able to guess other attacker to guess. An attacker need not be able to guess other
fields, e.g., the TCP sequence number, to get a packet through the fields, e.g., the TCP sequence number, to get a packet through the
stateful NAT64 translator. While such traffic might be dropped by stateful NAT64 translator. While such traffic might be dropped by
the final destination, it does not provide additional mitigations the final destination, it does not provide additional mitigations
against bandwidth/CPU attacks targeting the internal network. To against bandwidth/CPU attacks targeting the internal network. To
avoid this type of abuse, a stateful NAT64 translator may keep track avoid this type of abuse, a stateful NAT64 translator MAY keep track
of the sequence number of TCP packets in order to verify the proper of the sequence number of TCP packets in order to verify the proper
sequencing of exchanged segments, in particular, those of the SYNs sequencing of exchanged segments, in particular, those of the SYNs
and the FINs. and the FINs.
9.3. Attacks on Stateful NAT64 Translators 9.3. Attacks on Stateful NAT64 Translators
The stateful NAT64 function itself is a potential victim of different The stateful NAT64 function itself is a potential victim of different
types of attacks. In particular, the stateful NAT64 translator can types of attacks. In particular, the stateful NAT64 translator can
be a victim of DoS attacks. The stateful NAT64 device has a limited be a victim of DoS attacks. The stateful NAT64 device has a limited
number of resources that can be consumed by attackers creating a DoS number of resources that can be consumed by attackers creating a DoS
skipping to change at page 51, line 14 skipping to change at page 51, line 21
stateful NAT64 translator will store for a given period. If the stateful NAT64 translator will store for a given period. If the
number of fragments is high enough, the memory of the stateful NAT64 number of fragments is high enough, the memory of the stateful NAT64
translator could be exhausted. Similarly, a DoS attack against the translator could be exhausted. Similarly, a DoS attack against the
stateful NAT64 translator can be crafted by sending either V4 or V6 stateful NAT64 translator can be crafted by sending either V4 or V6
SYN packets that consume memory in the form of session and/or binding SYN packets that consume memory in the form of session and/or binding
table entries. In the case of IPv4 SYNs the situation is aggravated table entries. In the case of IPv4 SYNs the situation is aggravated
by the requirement to also store the data packets for a given amount by the requirement to also store the data packets for a given amount
of time, requiring more memory from the stateful NAT64 device. The of time, requiring more memory from the stateful NAT64 device. The
stateful NAT64 devices must implement proper protection against such stateful NAT64 devices must implement proper protection against such
attacks, for instance, allocating a limited amount of memory for attacks, for instance, allocating a limited amount of memory for
fragmented packet storage as specified in Section 4.4. fragmented packet storage as specified in Section 3.4.
Another consideration related to the stateful NAT64 translator Another consideration related to the stateful NAT64 translator
resource depletion refers to the preservation of binding state. resource depletion refers to the preservation of binding state.
Attackers may try to keep a binding state alive forever by sending Attackers may try to keep a binding state alive forever by sending
periodic packets that refresh the state. In order to allow the periodic packets that refresh the state. In order to allow the
stateful NAT64 translator to defend against such attacks, the stateful NAT64 translator to defend against such attacks, the
stateful NAT64 translator may choose not to extend the session entry stateful NAT64 translator MAY choose not to extend the session entry
lifetime for a specific entry upon the reception of packets for that lifetime for a specific entry upon the reception of packets for that
entry through the interface facing the Internet or external side, as entry through the interface facing the Internet or external side, as
configured. As described in the framework document [RFC6144], the configured. As described in the framework document [RFC6144], the
stateful NAT64 translator can be deployed in multiple scenarios, in stateful NAT64 translator can be deployed in multiple scenarios, in
some of which the Internet side is the IPv6 one, and in others of some of which the Internet side is the IPv6 one, and in others of
which the Internet side is the IPv4 one. It is then important to which the Internet side is the IPv4 one. It is then important to
properly set which is the Internet side of the stateful NAT64 properly set which is the Internet side of the stateful NAT64
translator in each specific configuration. translator in each specific configuration.
9.4. Avoiding Hairpinning Loops 9.4. Avoiding Hairpinning Loops
skipping to change at page 52, line 19 skipping to change at page 52, line 25
It is not hard to guess the IPv4 address that will be allocated. It is not hard to guess the IPv4 address that will be allocated.
First, the attacker creates a binding and uses (for example) Simple First, the attacker creates a binding and uses (for example) Simple
Traversal of the UDP Protocol through NAT (STUN) [RFC8489] to learn Traversal of the UDP Protocol through NAT (STUN) [RFC8489] to learn
its external IPv4 address. New bindings will always have this its external IPv4 address. New bindings will always have this
address. Then, it uses a source port in the range 1-1023. This will address. Then, it uses a source port in the range 1-1023. This will
increase the chances to 1/512 (since range and parity are preserved increase the chances to 1/512 (since range and parity are preserved
by a stateful NAT64 translators in UDP). by a stateful NAT64 translators in UDP).
In order to address this vulnerability, the stateful NAT64 translator In order to address this vulnerability, the stateful NAT64 translator
MUST drop IPv6 packets whose source address is in Pref64::/n, as MUST drop IPv6 packets whose source address is in Pref64::/n, as
defined in Section 4.5. defined in Section 3.5.
9.5. DNS64 and DNSSEC 9.5. DNS64 and DNSSEC
If DNS64 is used, potentially it can interfere with DNSSEC. In that If DNS64 is used, potentially it can interfere with DNSSEC. In that
case, see the Security Considerations of [RFC6147]. case, see the Security Considerations of [RFC6147].
10. Acknowledgements 10. Acknowledgements
Thanks to Mohamed Boucadair, Michael Richardson, Tom Petch, Ted Thanks to Mohamed Boucadair, Michael Richardson, Tom Petch, Ted
Lemon, Daryll Sweer, Brian E. Carpenter, Goetz Goerisch, Gabor Lemon, Daryll Sweer, Brian E. Carpenter, Goetz Goerisch, Gabor
skipping to change at page 55, line 33 skipping to change at page 55, line 39
Customer-side Translator (CLAT): Node Behavior and Customer-side Translator (CLAT): Node Behavior and
Recommendations", Work in Progress, Internet-Draft, draft- Recommendations", Work in Progress, Internet-Draft, draft-
ietf-v6ops-claton-16, 5 March 2026, ietf-v6ops-claton-16, 5 March 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
claton-16>. claton-16>.
[I-D.ietf-v6ops-nat64-wkp-1918] [I-D.ietf-v6ops-nat64-wkp-1918]
Kumari, W. and J. Linkova, "Using the Well-Known IPv6 Kumari, W. and J. Linkova, "Using the Well-Known IPv6
Prefix to Represent Non-Global IPv4 Addresses", Work in Prefix to Represent Non-Global IPv4 Addresses", Work in
Progress, Internet-Draft, draft-ietf-v6ops-nat64-wkp- Progress, Internet-Draft, draft-ietf-v6ops-nat64-wkp-
1918-06, 4 August 2026, 1918-07, 14 August 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-v6ops- <https://datatracker.ietf.org/doc/html/draft-ietf-v6ops-
nat64-wkp-1918-06>. nat64-wkp-1918-07>.
[Len2023] Lencse, G., Shima, K., and K. Cho, "Benchmarking [Len2023] Lencse, G., Shima, K., and K. Cho, "Benchmarking
methodology for stateful NAT64 gateways", Computer methodology for stateful NAT64 gateways", Computer
Communications, vol. 210, no. 1, pp. 256-272, Communications, vol. 210, no. 1, pp. 256-272,
DOI 10.1016/j.comcom.2023.08.009, 1 October 2023, DOI 10.1016/j.comcom.2023.08.009, 1 October 2023,
<https://www.sciencedirect.com/science/article/pii/ <https://www.sciencedirect.com/science/article/pii/
S0140366423002931>. S0140366423002931>.
[Len2024] Lencse, G., "Making Stateless and Stateful Network [Len2024] Lencse, G., "Making Stateless and Stateful Network
Performance Measurements Unbiased", Computer Performance Measurements Unbiased", Computer
 End of changes. 126 change blocks. 
221 lines changed or deleted 249 lines changed or added

This html diff was produced by rfcdiff 1.49. The latest version is available from https://github.com/ietf-tools/rfcdiff