[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path MTU for draft-ietf-v6ops-mech-v2-00.txt
> I notice that in the latest draft version, you are no longer requiring an
> MRU of 4420 bytes in decapsulators and seem to be taking a less
> aggressive approach in the dynamic MTU discovery in the encapsulator.
> Can you say more as to the reasons for the change?
This change (the non-need for the 4420 limit) was presented in
Atlanta even though it was not in the previous version of the draft.
The basic results (which I think were on the slides, or perhaps only
in the discussion in Atlanta) is that the decapsulator needs to
support reassembly of up to the max (of its interface MTUs) and 1280+20.
(There is a note in the spec about it really being its neighbors MTU
that matter when the MTU != MRU).
Then the encapsulator can choose between the static approach of
a fixed tunnel MTU of 1280 and DF not set in the IPv4 header, or a dynamic
tunnel MTU detection using IPv4 path MTU discovery. The latter will never
result in IPv4 packets at the decapsulator larger than the max of the
decapsualtor's interface MTUs.
Finally the spec allows for manual configuration to override the 1280 number
in the static/fixed MTU case, but only if the receiver can handle reassembly
of the larger IPv4 packets. Thus it requires manual coordination between
the encapsulator and decapsulator to do this manual override.
Erik