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