Found 2 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

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.

Report New Errata