RFC Errata
Found 4 records.
Status: Verified (2)
RFC 6145, "IP/ICMP Translation Algorithm", April 2011
Note: This RFC has been obsoleted by RFC 7915
Note: This RFC has been updated by RFC 6791, RFC 7757
Source of RFC: behave (tsv)
Errata ID: 3059
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Verifier Name: Wesley Eddy
Date Verified: 2012-06-01
Section 5.1 says:
<Removed from RFC 2765 where it had existed after Destination Address field description>
It should say:
If any of an IPv6 Hop-by-Hop Options header, Destination Options header, or Routing header with the Segments Left field equal to zero are present in the IPv6 packet, those IPv6 extension headers MUST be ignored (i.e., there is no attempt to translate the extension headers) and the packet translated normally. However, the Total Length field and the Protocol field are adjusted to "skip" these extension headers.
Notes:
Since the extension headers shall be removed from the packet while translating to IPv4 the translator should deduct from IPv4 Total Length the length of all the extension headers present in the original IPv6 packet except ESP header (in transport mode). AH is not supposed to be translated. RFC 2765 had explicitly stated this and RFC 6145 also should continue to have this stated. Copied the correction text from RFC 2765.
A BEHAVE WG chair said on 1/19/2012:
I believe the filer is correct. Although the intent might be clear from Section 4:
" As with [RFC2765], the translating function specified in this
document does not translate any IPv4 options, and it does not
translate IPv6 extension headers except the Fragment Header."
Although the Length portion of the omitted paragraph is actually covered by
errata ID 3060 above (and we don't need 2 technical errata for the same thing)
the omitted paragraph does contain a statement about how to fill in the
Protocol field when IPv6 extension headers were present, which is nowhere
else in the doc and might not be obvious to an implementer from the
section 4 text.
Errata ID: 3060
Status: Verified
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Verifier Name: Wesley Eddy
Date Verified: 2012-06-01
Section 5.1.1 says:
Total Length: Payload length value from IPv6 header, minus 8 for the
Fragment Header, plus the size of the IPv4 header.
It should say:
Total Length: If the Next Header field of the Fragment Header is not
an extension header (except ESP) then Total Length MUST be set to
Payload Length value from IPv6 header, minus length of extension
headers up to Fragmentation Header, minus 8 for the Fragment
Header, plus the size of the IPv4 header. If the Next Header
field of the Fragment Header is an extension header (except ESP)
then the packet SHOULD be dropped and logged.
Notes:
If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the total length of the IPv4 fragment for non-initial fragments. In case of initial fragment also, only if all the extension headers of the fragmentable part are contained within the initial fragment itself then translator can know of how much length to deduct from the total length.
A BEHAVE WG chair said on 1/19/2012:
I believe the filer is correct. The RFC does not contain the right statement with
respect to handling of IPv6 extension headers. It says they're skipped when
filling in the payload but it doesn't say they're skipped when filling in the
length field.
Status: Held for Document Update (2)
RFC 6145, "IP/ICMP Translation Algorithm", April 2011
Note: This RFC has been obsoleted by RFC 7915
Note: This RFC has been updated by RFC 6791, RFC 7757
Source of RFC: behave (tsv)
Errata ID: 3061
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Gandhar Gokhale
Date Reported: 2011-12-23
Held for Document Update by: Wesley Eddy
Section 5.1.1 says:
Fragment Offset: Copied from the Fragment Offset field of the IPv6
Fragment Header.
It should say:
Fragment Offset: If the Next Header field of the Fragment Header is
not an extension header (except ESP) then Fragment Offset MUST be
copied from the Fragment Offset field of the IPv6 Fragment Header.
If the Next Header field of the Fragment Header is an extension
header (except ESP) then the packet SHOULD be dropped and logged.
Notes:
If the fragmentable part (as described in RFC 2460) of the original unfragmented IPv6 packet had extension headers then the translator can not calculate the offset of the IPv4 fragment for non-initial fragments. If extension headers are present in the fragmentable part then the fragment offset value of the IPv6 header includes length of the extension headers also. Since translator strips of the IPv6 extension headers the fragment offset value set by the sender of IPv6 fragments can not match that received by the IPv4 receiver and the reassembly will fail. For non-initial fragments the translator does not have the knowledge of this delta when there is no state maintained.
The legth issue stated in erratum 2 is not in itself sufficient to advocate packet drop. However, the offset issue is sufficient to advocate packet drop as the reassembly is bound to fail. Therefore I'm putting a SHOULD in both cases.
Errata ID: 4090
Status: Held for Document Update
Type: Technical
Publication Format(s) : TEXT
Reported By: Fernando Gont
Date Reported: 2014-08-20
Held for Document Update by: Magnus Westerlund
Date Held: 2020-06-02
Section 6 says:
1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet
Too Big (PTB) messages is less than 1280, change it to 1280.
This is intended to cause the IPv6 host and IPv6 firewall to
process the ICMP PTB message and generate subsequent packets to
this destination with an IPv6 Fragment Header.
It should say:
1. In the IPv4-to-IPv6 direction: if the MTU value of ICMPv4 Packet
Too Big (PTB) messages is less than 1280, change it to 1280.
This is intended to cause the IPv6 host and IPv6 firewall to
process the ICMP PTB message.
Notes:
An ICMPv6 PTB message reporting an MTU equal to 1280 does not trigger IPv6 atomic fragments. Only ICMPv6 PTB < 1280 do.
AD Comment (Magnus Westerlund): As RFC 6145 has been superseeded by RFC 7915. In that document the above text is gone. So I consider this issue handled and not necessary to determine if it is verified or not.