Found 3 records.

Status: Rejected (3)

RFC 6052, "IPv6 Addressing of IPv4/IPv6 Translators", October 2010

Errata ID: 5415
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Dale R. Worley
Date Reported: 2018-07-01
Rejected by: Magnus Westerlund
Date Rejected: 2020-01-16

Section 2.2 says:

   Bits 64 to 71 of the address are reserved for compatibility with the
   host identifier format defined in the IPv6 addressing architecture
   [RFC4291].  These bits MUST be set to zero.  When using a /96
   Network-Specific Prefix, the administrators MUST ensure that the bits
   64 to 71 are set to zero.  A simple way to achieve that is to
   construct the /96 Network-Specific Prefix by picking a /64 prefix,
   and then adding 4 octets set to zero.

[and other parts of the text]

It should say:

[This paragraph should be removed and corresponding changes made to
the rest of section 2.2.]

Notes:

Section 2.2 says that bits 64 to 71 of the Ipv6 address MUST be set to zero and references RFC 4291 as the authority. However, RFC 7136 says:

In particular, RFC 4291 defines a method by which the
Universal and Group bits of an IEEE link-layer address are mapped
into an IPv6 unicast interface identifier. This document clarifies
that those two bits are significant only in the process of deriving
interface identifiers from an IEEE link-layer address, and it updates
RFC 4291 accordingly.

Thus, the text I've referenced in RFC 6052 is to enforce a requirement that was not correctly applied, and RFC 6052's statement about bits 64 to 71 should be removed. In addition, there are consequent changes in other parts of RFC 6052, including Figure 1, where the "u" field should be removed from the address formats.
--VERIFIER NOTES--
AD (Magnus Westerlund): A clarification by a later RFC that impacts this RFC is not an errata. The change appears to require a consensus decision on how to handle it. Thus rejected on formal grounds, should be considered if document is revised in the future.

Errata ID: 5547
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Fred Baker
Date Reported: 2018-11-06
Rejected by: Mirja Kühlewind
Date Rejected: 2018-11-26

Section 3.1 says:

   The Well-Known Prefix MUST NOT be used to represent non-global IPv4
   addresses, such as those defined in [RFC1918] or listed in Section 3
   of [RFC5735].  Address translators MUST NOT translate packets in
   which an address is composed of the Well-Known Prefix and a non-
   global IPv4 address; they MUST drop these packets.

It should say:

The paragraph should be removed.

Notes:

IPv4 packets with private addresses are routinely translated to IPv4 packets with global addresses in NAT44. If a 464XLAT CLAT (stateless NAT64) cannot translate a private address to an IPv6 /96 prefix with that address as an IID (or whatever it's called), then the packet may not be translated to an IPv4 packet with a global address by the 464XLAT PLAT (stateful NAT64). This changes the intent of the sender, and in so doing violates the end to end principle. Practically speaking, it means that a network that uses 464XLAT or MAP-T with IPv4 in the subscriber and translating to IPv4 via NAT64 into the IPv4 Internet, it forces the network or the subscriber to purchase global address space. That's just silly. Let the user use private address space in the home or whatever.
--VERIFIER NOTES--
The orginial text was intended at time of publication. If this is not current anymore, the RFC needs to be updated by an IETF consensus doc.

Errata ID: 5984
Status: Rejected
Type: Technical
Publication Format(s) : TEXT
Reported By: Jordi Palet Martinez
Date Reported: 2020-02-16
Rejected by: Magnus Westerlund
Date Rejected: 2020-02-17

Section 3.3 says:

Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix to their IPv4/IPv6 translation service.

It should say:

Organizations deploying stateless IPv4/IPv6 translation SHOULD assign a Network-Specific Prefix for the exclusive use of their IPv4/IPv6 translation service.

Notes:

This seems obvious but is not. The NSP must only be used for the translation service. If the NSP is used only, for example in an enterprise network, in the LANs, and the translator allows it, it may create conflicts, as the resulting IPv6 address (NSP+IPv4 address) may be the same as a host inside the LAN has been configured with (either manually, or with SLAAC, DHCPv6), etc.

It has been confirmed that at least one vendor already realized this and the implementation doesn't work if the prefix is used both for the translator service and one of the LANs, but there is no explicit documentation on that. So if configured, the box doesn't work, but doesn't report is an an "invalid" config.
--VERIFIER NOTES--
This Errata requests requires WG consensus decision and thus outside of the Errata process. The specification does not prevent what is propsed as the appropriate way of assigning a NSP. The RFC does not restrict the usage, and as commented on the mailing list, there are ways to make even using the same prefix for both clients and the NAT64 device.

Report New Errata