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

Report New Errata