errata logo graphic

Found 4 records.

Status: Verified (2)

RFC6145, "IP/ICMP Translation Algorithm", April 2011

Source of RFC: behave (tsv)

Errata ID: 3059

Status: Verified
Type: Technical

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

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: Reported (1)

RFC6145, "IP/ICMP Translation Algorithm", April 2011

Source of RFC: behave (tsv)

Errata ID: 4090

Status: Reported
Type: Technical

Reported By: Fernando Gont
Date Reported: 2014-08-20

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.


Status: Held for Document Update (1)

RFC6145, "IP/ICMP Translation Algorithm", April 2011

Source of RFC: behave (tsv)

Errata ID: 3061

Status: Held for Document Update
Type: Technical

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.


Report New Errata