[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Path MTU Discovery
-----BEGIN PGP SIGNED MESSAGE-----
In message <199702071815.KAA01378@kebe.eng.sun.com>, Dan McDonald writes:
>
>This outer packet is now a datagram originating from the router. It can
>fragment as it sees fit. Yes, it may violate the spirit of no intermediate
>fragmentation, but it certainly is legal. This is legal in IPv6 too, where
>there is an implicit DF bit on all packets.
I didn't question its legality. If the endpoint is trying to do
PathMTU discovery and we care to respect this and we must copy the DF
bit. If we don't, we can just ignore it and none will be the wiser;
however, i can see (pathological maybe) situations where fragmentation
happens between every tunnel endpoint because noone respects the DF bit.
>I question your choice of abstraction. How do you configure these multiple
>tunnels? Or are they automatic tunnels ala. IPv6's ::<v4-address> syntax?
>Since you probably have to configure the tunnels, you might as well provide a
>halfway decent abstraction to take into account Path MTU ratcheting down.
Extended routing entries. All the relevant information (for IP
encapsulation, the IP addresses; for AH/ESP the SPIs) is contained in
the routing table. Or you mean something different
>OTOH it uses defined behavior and available underspecifications to make
>implementations (IMHO) less complex. Security holes come out of complexity,
>just ask any sendmail user.
I doubt either approach (ViF-MTU or "my" way) is overly complex. And i
would argue that it is necessary for good network behaviour.
- -Angelos
-----BEGIN PGP SIGNATURE-----
Version: 2.6.3i
Charset: noconv
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface
iQCVAwUBMvuVor0pBjh2h1kFAQG4BAP/cGxO5qo+0SVgnNJGCFc/2UUEX8oikPup
jusn2O6EcX2tOwWXom50sqbM9iVaACU1QvXdJPnxafhXsxUkrqG9P8fJrtVc5y/W
EZHz/4Udr36gZgwK98VoU3BIX6TkgwDZbmch/OfKAG/+zDwB1rV8ZelPHxuYNGTk
zy0Gv06+b/Q=
=Rt2u
-----END PGP SIGNATURE-----