Re: Path MTU Discovery
Ben Rogers <ben@ascend.com> Mon, 10 February 1997 13:31 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id IAA08504 for ipsec-outgoing; Mon, 10 Feb 1997 08:31:36 -0500 (EST)
Date: Sat, 08 Feb 1997 07:37:08 -0500
Message-Id: <199702081237.HAA24954@carp.morningstar.com>
From: Ben Rogers <ben@ascend.com>
To: Dan.McDonald@Eng.sun.com
Cc: angelos@aurora.cis.upenn.edu, ipsec@tis.com
Subject: Re: Path MTU Discovery
Reply-To: ben@ascend.com
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
Dan McDonald writes: > > Well, wouldn't ignoring the DF bit defeat the original endpoint's > > PathMTU ? > > DF applies to the IP datagram on which it is set. DF is not inherited by any > encapsulating IP headers. Hate to be picky, but RFC1853 states: Don't Fragment copied from the inner IP header. This allows the originator to control the level of performance tradeoffs. See "Tunnel MTU Discovery". So, in fact, the IP-in-IP header requires that DF bit be set, and neither AH, nor ESP will touch this part of the header. Of course, if you would like to tunnel using a protocol other than IP in IP, that is your prerogative... Are there people who do this? > <SNIP!> > > So one can establish multiple tunnels to different (or the same) hosts and > > use the same ViF. In this case, if you receive an ICMP toobig, you don't > > know who if "belongs" to until you parse the internal packet a bit and > > check the destination/SPI of the original packet. And then of course you > > can't (shouldn't) change the "MTU" of the ViF. > > 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. Hopefully, if each tunnel properly supports Path MTU and "soft state", the MTU should propagate upwards. Personally I wonder what the point is in requiring Path MTU be done, while only recommending that soft state be kept. (Perhaps RFC1853 should be updated to require the keeping of soft state?) Then, we would see everything perform nicely, a la: Host -> Tunnelling Router 1 -> Tunneling Router 2 --A--> ... Where each router is doing rfc1828 MD5 tunneling (20 byte IP header + 24 bytes of AH = 44 bytes total), and path A has an MTU of 500 bytes. Packet 1: 1500 bytes, DF set Tunneled by R1 (1544 bytes) (Dropped) Packet 2: 1500 bytes, DF set R1 sends ICMP too big with size limit 1456 to host Tunneled by R1 (1544 bytes) (Dropped) (An effort to rediscover a "growing" MTU) Packet 3: 1456 bytes, DF set Tunneled by R1 (1500 bytes) Tunneled by R2 (1544 bytes) (Dropped) Packet 4: 1456 bytes, DF set Tunneled by R1 (1500 bytes) R2 sends ICMP too big with size limit 456 to R1 Tunneled by R2 (1544 bytes) (Dropped) Packet 4: 1456 bytes, DF set R1 sends ICMP too big with size limit 412 to host Tunneled by R1 (1500 bytes) R2 sends ICMP too big with size limit 456 to R1 Tunneled by R2 (1544 bytes) (Dropped) Packet 5: 412 bytes, DF set Tunneled by R1 (456 bytes) Tunneled by R2 (500 bytes) Received. ben
- 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