RFC 6145, "IP/ICMP Translation Algorithm", April 2011
Note: This RFC has been obsoleted by RFC 7915Source of RFC: behave (tsv)
See Also: RFC 6145 w/ inline errata
Errata ID: 3060
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.
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