Google filtering ICMPv6 type 2?

[Benedikt Stockebrand]

Hello everybody,

Erik Kline <ek at google.com> writes:

>>> I don't know you're exact setup but in the meantime you might set the
>>> MTU in the RA for hosts behind that tunnel; that way they know their
>>> correct MSS...

there was a discussion on a similar approach to this on a (near dead)
German IPv6 list.  Conclusion: DON'T (sorry for the shouting).

Path MTU Discovery problems are already quite misleading in nature and
as such difficult enough to diagnose and even more difficult to
resolve.  Wantonly clamping down MTUs will only make these tasks
worse.

Strategically even more important, once we go down that path we're
quickly at the point that this approach becomes a "standard procedure"
and it becomes "your fault" if something breaks "because you
configured a non-standard MTU" (i.e. one larger than 1280).

>> They're actually a few hops away from the tunnel in both test cases,
>> connected by GigE, so the MSS is correct for their local interfaces. Â I
>> suppose I could change everything to 1280 on the links via radvd, but by
>> then I'm sure things will be long resolved.. :-)
>
> Right.  And we could force 1280 on our end, with the same result.  The
> general feeling at the moment is that if we can get/keep pMTUd working
> then that's better than just clamping everything at 1280.

For this to work you have to do it on both sides.  If the server side
does but the client doesn't then all that will happen is that "small"
HTTP requests (with the HTTP request fitting within a packet smaller
than the actual pMTU) work but "large" ones won't.

Now have somebody call this an application problem and all sorts of
developers will start to search for a bug that's not in their code at
all.


Cheers,

    Benedikt

-- 
			 Business Grade IPv6
		    Consulting, Training, Projects

Dipl. Inform.                 Tel.:  +49 (0) 69 - 247 512 362
Benedikt Stockebrand          Mobil: +49 (0) 177 - 41 73 985           
Fichardstr. 38                Mail:  me at benedikt-stockebrand.de        
D-60322 Frankfurt am Main     WWW:   http://www.benedikt-stockebrand.de/

Bitte kein Spam, keine unaufgeforderten Werbeanrufe, keine telefonischen
Umfragen.  Anrufe werden ggf. zu rechtlichen Zwecken aufgezeichnet.  
No spam, no unsolicited sales calls, no telephone surveys, please. Calls
may be recorded for legal purposes.