Re: Path MTU Discovery
Oliver Spatscheck <spatsch@cs.arizona.edu> Mon, 10 February 1997 16:05 UTC
Received: (from majordom@localhost) by portal.ex.tis.com (8.8.2/8.8.2) id LAA09945 for ipsec-outgoing; Mon, 10 Feb 1997 11:05:32 -0500 (EST)
X-Authentication-Warning: P-spatsch.cs.arizona.edu: spatsch owned process doing -bs
Date: Mon, 10 Feb 1997 09:01:08 -0700
From: Oliver Spatscheck <spatsch@cs.arizona.edu>
To: Ben Rogers <ben@ascend.com>
cc: Dan McDonald <Dan.McDonald@Eng.sun.com>, "Angelos D. Keromytis" <angelos@aurora.cis.upenn.edu>, ipsec@tis.com
Subject: Re: Path MTU Discovery
In-Reply-To: <199702081237.HAA24954@carp.morningstar.com>
Message-ID: <Pine.LNX.3.94.970210085430.2648A-100000@P-spatsch.cs.arizona.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
Sender: owner-ipsec@ex.tis.com
Precedence: bulk
-----BEGIN PGP SIGNED MESSAGE----- On Sat, 8 Feb 1997, Ben Rogers wrote: > >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. This example only works for IPv4. IPv6 requires a MINIMUM MTU of 576 Octets. Which requieres your second router to do link specific fragmentation. This schouldn't be a problem in your scenario since r2 has to do link specific fragmentation anyway (MTU 500 Byte) . However if you assume a tunneling router with a link MTU of 580 byte and you add IP in IP the router suddenly has to do link specific fragmentation. Something he didn't do before. Oliver > >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 > -----BEGIN PGP SIGNATURE----- Version: 2.6.3i Charset: noconv iQCVAwUBMv9GRjnVPgUZ7uZJAQGDWwP/aFlUYlzPN0AqyknfCEF4jKK/TWtGPn9H PU12zESdKmmzA2pRyZMo7EEFLU30Z2256WeuZsVVlbbJD4zZ4vJvNhIl31WCDFPX o6WBv+jLFemTSQOKfF8dlUtJRhQr4erh73pPL4IFxy2Xw5g4gyRXQuqG0mJvvdR/ 8U3NDPUFHdE= =j/qJ -----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