IP tunnel MTU
Templin, Fred L
Fred.L.Templin at boeing.com
Tue Oct 30 14:10:55 UTC 2012
> -----Original Message-----
> From: Chris Woodfield [mailto:rekoil at semihuman.com]
> Sent: Monday, October 29, 2012 4:40 PM
> To: Templin, Fred L
> Cc: William Herrin; Ray Soucy; NANOG list
> Subject: Re: IP tunnel MTU
> True, but it could be used as an alternative PMTUD algorithm - raise the
> segment size and wait for the "I got this as fragments" option to show
Yes; it is a very attractive option on the surface. Steve Deering
called it "Report Fragmentation (RF)" when he first proposed it
back in 1988, but it didn't gain sufficient traction and what we
got instead was RFC1191.
As I mentioned, SEAL does this already but in a "best effort"
fashion. SEAL will work over paths that don't conform well to
the RF model, but will derive some useful benefit from paths
> Of course, this only works for IPv4. IPv6 users are SOL if something in
> the middle is dropping ICMPv6.
Sad, but true.
Thanks - Fred
fred.l.templin at boeing.com
> On Oct 29, 2012, at 4:02 PM, Templin, Fred L wrote:
> > Hi Bill,
> >> Maybe something as simple as clearing the don't fragment flag and
> >> adding a TCP option to report receipt of a fragmented packet along
> >> with the fragment sizes back to the sender so he can adjust his mss to
> >> avoid fragmentation.
> > That is in fact what SEAL is doing, but there is no guarantee
> > that the size of the largest fragment is going to be an accurate
> > reflection of the true path MTU. RFC1812 made sure of that when
> > it more or less gave IPv4 routers permission to fragment packets
> > pretty much any way they want.
> > Thanks - Fred
> > fred.l.templin at boeing.com
More information about the NANOG