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