Subject: Re: Patch for timiting TCP MSS (i.e. for new PPPoE)
To: None <tls@rek.tjls.com>
From: Bill Sommerfeld <sommerfeld@orchard.arlington.ma.us>
List: tech-net
Date: 12/06/2001 21:36:55
> Date: Thu, 6 Dec 2001 18:05:36 -0500
> From: Thor Lancelot Simon <tls@rek.tjls.com>
> To: Martin Husemann <martin@duskware.de>
> Cc: tech-net@netbsd.org
> Subject: Re: Patch for timiting TCP MSS (i.e. for new PPPoE)
> 
> On Thu, Dec 06, 2001 at 09:24:37PM +0100, Martin Husemann wrote:
> > > 2) Our NAT code appears to corrupt locally-generated needs-frag ICMP
> > >    messages, so a NetBSD router separating, say, an MTU-1400 PPPOE link
> > >    and an MTU-1500 Ethernet will create a Path MTU blackhole.
> > 
> > Maybe, but the typical PPPoE router will have a 1492 byte MTU, and the need
> > to fragment packet will not be send from the router but from it's pppoe peer.
> 
> That's just not right.  Let's draw a picture:
> 
> 
> ____         ----           ____
> |CL|----E----|NB|----POE----|RB|
> ----         ----           ----
> 
> So here we have a "client" ("CL") connected by MTU-1500 Ethernet to a
> router running NetBSD ("NB") connected by PPP-over-Ethernet (MTU 1492) to 
> a DSL headend box ("RB").
> 
> If CL tries to do path MTU discovery, sending packets with Don't Fragment
> set, it is NB that is responsible for sending back Needs Fragment messages
> for anything that doesn't fit in the 1492 byte MTU.
> 
> If NB is a NetBSD system that's doing ipf and NAT and exhibiting the bug
> I'm talking about, CL will ignore its Needs Fragment messages because
> they will have invalid checksums.
> 
> That creates a Path MTU blackhole.
> 
> -- 
> Thor Lancelot Simon	                                      tls@rek.tjls.com
>     And now he couldn't remember when this passion had flown, leaving him so
>   foolish and bewildered and astray: can any man?
> 						   William Styron