I-D on operational MTU/fragmentation issues in tunneling

Thu Oct 14 16:45:50 UTC 2004

Thanks to you, and all who have replied (both off and on-list). I was 
pleasantly surprised at the amount of review I've received.  Keep them 
coming!  I'll try to respond/react to them shortly.

I'll respond to both posts on this list in one message:

On Wed, 13 Oct 2004, Iljitsch van Beijnum wrote:
> 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???

True -- thanks for catching this.  I had a brain fart when I thought
that there isn't enough information in the IP header to do that.  But
as long as you don't exhaust the IP identification number space, it's
OK..

> 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.

I don't think it's quite as simple as that.  First, even if you used
Ethernet, you would seem to have to require that all the tunnel entry
and exit points reside in the same Ethernet VLAN "space".  That is,
all the entry/exit points would have to be hooked to the Ethernet
switch core network (somehow), or that the routers would support some
kind of VLAN 'passthrough' -- encapsulating the VLAN's traffic to some
other interface's VLAN.

These may hold in some situations, but not in general.

Remember that the problem comes up especially if you need to tunnel
beyond the "domain" where you have a high MTU (or can use VLANs).  If
you can assume that.. well, that's one solution proposed in the draft.

> 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.

Actually, it can be done, see RFC2473 ('Generic Packet Tunneling in
IPv6').  The entry point trying to encapsulate a 1280 byte packet in
1280 byte MTU just have to do some fragmentation, see section 7.1 (b).

..........

On Thu, 14 Oct 2004, Sabri Berisha wrote:
>
> On Mon, Oct 11, 2004 at 11:12:55AM +0300, Pekka Savola wrote:
>
> Hi Pekka and others,
>
> > Please send comments to me by the end of this week, either on- of
> > off-list, as you deem appropriate.
>
> With the risk of stating the obvious I would say that normally, PMTUD
> should do the trick. [...]

For some (mostly host-based) tunnels, yes.  But the point is that if
you insert such a tunnel in the middle of the network, where you have
e.g. Internet traffic from millions of nodes passing through on both
directions, just counting on PMTUD would require that your network 
originated billions of Packet too Big messages each day, and depended 
on the fact that the users have not blocked the ICMPs.  Further, there 
are also passive monitoring applications (like wiretaps) where you 
DON'T want anyone to know something "fishy" is going on.

So, in practice, I fail to see how PMTUD or the like would really work
in the more generic environments than just host-based or "last-hop"  
tunnels.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings