Fernando Gont wrote:
In the real world, such packets are not legitimate, so feel free to drop them. draft-ietf-6man-oversized-header-chain formally addresses this issue.
The ID misses the problem of 4->6 translator. That is, though the ID state: Entire IPv6 header chain: All protocol headers starting from the fixed IPv6 header till (and including) the upper layer protocol header (TCP, UDP, etc. -- assuming there is one of those), the translator may not have any knowledge on how long "the upper layer protocol header" is. Thus, the requirement of the ID is impossible to enforce. Moreover, a 68B IPv4 fragment of some packet with 60B upper layer protocol header can not be translated to IPv6. In theory, with 60B IPv4 header, a 68B IPv4 fragment can't even contain an entire TCP header. So, the requirement of the ID should be to require only the first 8B of the upper layer protocol header. All the (pseudo) transport protocols working over IPv4 is designed to identify transport identity with the first 8B of transport headers.
Likewise with the acl I have the property that the initial packet has all the info in it while the fragment does not.
You're talking about initial-fragment vs non-initial fragments? -- If so, in theory *both* might be missing the upper layer information.
Yes, that is one of an annoying point of IPv6. Masataka Ohta