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