Subject: Re: Patch for timiting TCP MSS (i.e. for new PPPoE)
To: None <email@example.com>
From: Bill Sommerfeld <firstname.lastname@example.org>
Date: 12/06/2001 21:36:55
> Date: Thu, 6 Dec 2001 18:05:36 -0500
> From: Thor Lancelot Simon <email@example.com>
> To: Martin Husemann <firstname.lastname@example.org>
> Cc: email@example.com
> 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:
> ____ ---- ____
> ---- ---- ----
> 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 firstname.lastname@example.org
> And now he couldn't remember when this passion had flown, leaving him so
> foolish and bewildered and astray: can any man?
> William Styron