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