Re: Last Call: <draft-ietf-intarea-ipv4-id-update-05.txt> (Updated Specification of the IPv4 ID Field) to Proposed Standard

[Joe Touch <[e-mail]>]

On 6/18/2012 5:09 AM, Masataka Ohta wrote:
> Joe Touch wrote:
> 
>>> 	draft-generic-v6ops-tunmtu-03.txt
>>>
>>> to fragment IPv6 packets by intermediate routers should be
>>> very interesting to you.
>>
>> It is aware of our IPv4-ID doc, and consistent with it.
> 
> What?

I looked more closely, and the doc is deeply flawed, even though it
appears to intend to be consistent with our IPv4-update doc through rate
limiting.  I'll post a summary to the v6-ops mailing list of those
issues. To summarize:

- it fragments inner packets at the ingress but does not reassemble them
	this means its choice of unique IDs isn't unique; other
	paths that don't use the tunnel might have IDs that
	are set by the source that collide with those assigned
	by the ingress, causing reassembly errors

- it creates inner fragments that interfere with arriving fragments
	i.e., it claims the IDs are unique, but this is true only
	for those it assigns; it does not attempt to monitor or
	drop collisions due to fragments that arrive with
	recently assigned IDs

>> When the DF is "ignored", the ID field is rewritten - i.e.,
> 
> If the ID field could be rewritten by intermediate entities,
> it is fine for intermediate routers to clear DF.

The counterexample is, as above:

	- when source-generated fragments can go around the rewriter

	- when other rewriters exist on other paths

Any time this sort of rewriting occurs, it might be safe if contained
inside a tunnel that "cleans up its mess", i.e., when it knows that only
its ingrees can generate fragments, and that the egress reassembles the
fragments and sets the DF=1.

Since that's not the case here, it's not safe.

Joe