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: 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