I-D on operational MTU/fragmentation issues in tunneling

Iljitsch van Beijnum iljitsch at muada.com
Wed Oct 13 11:17:06 UTC 2004


On 11-okt-04, at 10:12, Pekka Savola wrote:

> The document is about to be IETF Last Called for Informational RFC,
> but prior to that, I'd like to solicit comments/feedback/review from
> the people here because I'm 100% sure a lot of people have been faced
> with these issues (we certainly have..).

Well, tunnels suck. No news there.

    It is interesting to note that at least one implementation provides a
    special knob to fragment the inner packet prior to encapsulation even
    if the DF bit has been set -- this is non-compliant behaviour, but
    possibly has been required in certain tightly controlled passive
    monitoring scenarios.  Such a setup wouldn't work for packets which
    have already been fragmented if they needed to be fragmented again,
    though.

Why would it be impossible to refragment fragments???

I have a setup with dial-up over L2TP that doesn't support an MTU 
bigger than 576 (which is completely unnecessary of course, but try 
telling the people at the other end of the L2TP thingy that) so I clear 
the DF bit for all incoming packets that have to go through the 
PPP/L2TP tunnel. Works like a charm. (Surprisingly, all users seem to 
have systems that are capable of reassembling 1.5 kB packets now.)

But I don't understand why anyone would want to use tunnels in the 
backbone. That's what VLANs are for. And if you don't use ether, you 
aren't bound by yester-millennium's 1500 byte MTU anyway.

In IPv6 there is the interesting problem that there are already many 
tunnels all over the place that often have a 1280 byte MTU, so 
tunneling over that can't be done because of the mandatory minimum MTU 
of 1280 bytes.




More information about the NANOG mailing list