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
