Erik Nordmark wrote:
Makes sense; it seems the 4420 requirement may have been too big for some low-endI 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 ofSure. Setting the DF bit prevents packets that are too big from reaching the decapsulator.
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.
Are there any concerns for denial of service based on receive buffer overrun at the decapsulator in this case? Fred ftemplin@iprg.nokia.com