Found 2 records.

Status: Reported (1)

RFC 6146, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", April 2011

Errata ID: 8416
Status: Reported
Type: Technical
Publication Format(s) : TEXT
Reported By: Marc Lepage
Date Reported: 2025-05-15

Section 3.5.1.1 says:

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 other BIBs (e.g., the UDP and TCP BIBs).

It should say:

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 other BIBs (e.g., the TCP and ICMP BIBs).

Notes:

The confusing wording appears in section 3.5.1.1 (regarding UDP BIB) and 3.5.2.3 (regarding TCP BIB).

It's possible and reasonable to interpret section 3.5.1.1's text

"but can be in use in other BIBs (e.g., the UDP and TCP BIBs)"

as if the text were:

"but can be in use in other BIBs (i.e., can be in use in the other BIBs, which in this case are the UDP and TCP BIBs)."

This looks like an error, because when *this* BIB is the UDP BIB, the *other* BIBs are the TCP and ICMP BIBs, not the UDP and TCP BIBs.

This interpretation is reasonable because use of the Latin "e.g." ("for example") makes it seem like the given BIBs are examples of "other BIBs."

Similarly, in section 3.5.2.3, *this* BIB is the TCP BIB, the *other* BIBs are the UDP and ICMP BIBs, but the text mentions UDP and TCP BIBs in the parenthetical example, and again looks like an error.

If this is the correct interpretation, then each section simply requires the correct *other* example BIBs in the parenthetical. [Section 3.5.1.1 corrected text given above; section 3.5.2.3 would be corrected in a similar manner.]

However, there is another possible interpretation, in which the given BIBs are correctly stated, but the wording is unclear as to what is denoted by the parenthetical example. In this interpretation, section 3.5.1.1 is intended as if the text were:

"but can be in use in other BIBs (i.e., the same address can be used in entries in both the UDP and TCP BIBs),"

or

""but can be in use in other BIBs (i.e., the UDP and TCP BIBs can have an entry using the same address)."

If this interpretation is intended, then it should be made clearer, and probably should use the Latin "i.e." ("that is") for the clarifying situation. [Again, in sections 3.5.1.1 and 3.5.2.3.]

Either way, because interpretation of the text is ambiguous in a way that affects its normative meaning, it should be clarified.

Status: Held for Document Update (1)

RFC 6146, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", April 2011

Errata ID: 4756
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Alberto Leiva Popper
Date Reported: 2016-08-02
Held for Document Update by: Magnus Westerlund
Date Held: 2021-01-13

Section 3.5.3 says:

If the NAT64 filters on its IPv4 interface, then the NAT64 checks
to see if the incoming packet is allowed according to the Address-
Dependent Filtering rule.  To do this, it searches for a Session
Table Entry with an STE source IPv4 address equal to X, an STE
ICMPv4 Identifier equal to i2, and a STE destination IPv4 address
equal to Y.  If such an entry is found (there may be more than
one), packet processing continues.  Otherwise, the packet is
discarded.  If the packet is 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 (Destination Unreachable) and Code 13
(Communication Administratively Prohibited).

In case the packet is not discarded in the previous processing
steps (either because the NAT64 is not filtering or because the
packet is compliant with the Address-Dependent Filtering rule),
then the NAT64 searches for a Session Table Entry (...)

It should say:

The NAT64 then searches for a Session Table Entry (...)

Notes:

The statement "there may be more than one" is incorrect; the triplet (X,i2,Y) constitutes the whole ICMP session's v4 identifier. Considering that, the whole paragraph tends to fall apart.

The point of Address-Dependent Filtering (ADF) is to provide a means to allow or disallow IPv4-started "sibling" connections. If there is an ongoing connection whose binding state is

BIB entry: (*,*) <--> (T,t)
Session: (*,*),(*,*) <--> (T,t),(Z,z)

(Left side is v6, right side is v4. This is the same notation as the RFC; see for example https://tools.ietf.org/html/rfc6146#section-3.5.1; '*' is anything/irrelevant)

Then ADF dictates whether the v4 endpoint is allowed to create the following new session (using the same BIB entry):

Session: (*,*),(*,*) <--> (T,t),(Z,m)

(where 'z' is not equal to 'm')

ADF works in UDP/TCP because t and z/m are separate variables. This is not the case in ICMP:

BIB entry: (*,*) <--> (T,t)
Session: (*,*,*) <--> (T,t,Z)

If only one ICMP triplet can match, there is no room for "sibling" ICMP "connections" that share a "source" IPv4 identifier but not a "destination" IPv4 identifier like TCP and UDP do. The two pings will share both BIB entry and v4 endpoint address and therefore also share the session. The NAT64 is incapable of telling the two pings apart, and therefore cannot filter one of them.

There is no such thing as "Address-Dependent Filtering" on ICMP.

Report New Errata