Found 2 records.

Status: Verified (2)

RFC 6333, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", August 2011

Note: This RFC has been updated by RFC 7335

Errata ID: 5847
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Mikael Abrahamsson
Date Reported: 2019-08-26
Verifier Name: Eric Vyncke
Date Verified: 2021-05-17

Section 5.3 says:

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv6 packet.  Reassembly MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2.

It should say:

   However, as not all service providers will be able to increase their
   link MTU, the B4 element MUST perform fragmentation and reassembly if
   the outgoing link MTU cannot accommodate the extra IPv6 header.  The
   original IPv4 packet is not oversized.  The packet is oversized after
   the IPv6 encapsulation.  The inner IPv4 packet MUST NOT be
   fragmented.  Fragmentation MUST happen after the encapsulation of the
   IPv4 packet in the IPv6 packet.  Reassembly of the IPv6 packet MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2 following point b) and ignoring the DF-bit setting.

Notes:

I do not have a corrected text. The above text doesn't say what RFC2473 section 7.2 says, so... what should it be? RFC2473 7.2 says to use the DF bit and decide whether to inner fragment or drop+send ICMP error. The above text seems to make normative statements that counter at least the DF=1 case in RFC2473 7.2. Also the text above says "Fragmentation MUST happen after the encapsulation of the IPv6 packet.". The IPv6 packet isn't encapsulated, so that sentence should be changed?

--- Verifier note ---
Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation.

Errata ID: 6584
Status: Verified
Type: Editorial
Publication Format(s) : TEXT
Reported By: Mohamed Boucadair
Date Reported: 2021-05-17
Verifier Name: Eric Vyncke
Date Verified: 2021-05-17

Section 6.3 says:

   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the encapsulation on the IPv6 packet.  Reassembly MUST happen
                           ^^^^^^^^^^^^^^^^^^
   before the decapsulation of the IPv6 header.  A detailed procedure
   has been specified in [RFC2473] Section 7.2.

It should say:

   As noted previously, fragmentation and reassembly need to be taken
   care of by the tunnel endpoints.  As such, the AFTR MUST perform
   fragmentation and reassembly if the underlying link MTU cannot
   accommodate the encapsulation overhead.  Fragmentation MUST happen
   after the IPv6 encapsulation.  Fragmentation MUST happen after the encapsulation of the
   IPv4 packet in the IPv6 packet.  Reassembly of the IPv6 packet MUST happen before the decapsulation of the
   IPv4 packet.  A detailed procedure has been specified in [RFC2473]
   Section 7.2 following point b) and ignoring the DF-bit setting.

Notes:

The original text is confusing as it seems to assume an extra encapsulation on the IPv6 packet, while this should be about adding an IPv6 header to an IPv4 packet.

-- verifier notes --
Following the discussion in https://mailarchive.ietf.org/arch/msg/softwires/bBQT97R7p1Ho4cUZIP2MFU5ZYJ4/ , the original intent is to avoid fragmenting the IPv4 packet before encapsulation.
See also errata 5874 on section 5.3 (the submitter's proposal has been updated by the verifier to be consistent with errata 5874).

Report New Errata