Re: Path MTU Discovery
"Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu> Mon, 10 February 1997 13:23 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08436 for ipsec-outgoing; Mon, 10 Feb 1997 08:23:38 -0500 (EST)
Message-Id: <9702072051.AA79389@aurora.cis.upenn.edu>
To: Dan.McDonald@Eng.sun.com
Cc: ipsec@tis.com
Subject: Re: Path MTU Discovery
Date: Fri, 07 Feb 1997 15:50:42 -0500
From: "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----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-----
- Path MTU Discovery Angelos D. Keromytis
- RE: Path MTU Discovery Sanjay Anand
- RE: Path MTU Discovery Stephen Kent
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Craig Metz
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Dan McDonald
- Re: Path MTU Discovery Angelos D. Keromytis
- Re: Path MTU Discovery Ben Rogers
- Re: Path MTU Discovery Oliver Spatscheck
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Ran Atkinson
- Re: Path MTU Discovery Angelos D. Keromytis
- Re[2]: Path MTU Discovery Whelan, Bill