Test your connectivity for World IPv6 Day

Tore Anderson tore.anderson at redpill-linpro.com
Tue Jun 7 18:11:38 CEST 2011


* Rémi Després

> A tunnel supporting less than 1500 must indeed return ICMP PTB
> messages like any tunnel.
> 
> But if the source host has a firewall that filters inbound ICMPv6
> messages, this becomes this host's problem. It becomes also a problem
> of hosts it communicates with although these hosts have no
> responsibility in the problem.
> 
> This host avoids the problem if it works with an "effective MTU for
> sending" of 1280 for off-link destinations, except for paths where
> PMTUD has detected better values.
> 
>> I refuse to work around their defective network by crippling the
>> MTU for all my visitors.
> 
> In my understanding, it isn't a problem of defective ISP network. It
> is a problem of uncertain effectiveness, so far, of PMTUD (worse in
> UDP than in TCP, and aggravated where some firewalls unduly filter
> ICMPv6 messages).

I have no firewalls that filter ICMPv6 PTB between my servers and my
border routers. So when my servers are the source host, PMTUD will work,
unless something in on the end users's [ISP's/tunnel broker's] side is
making it break. In which case - not my problem.

I have no influence on what MTU is chosen by the remote host (i.e. the
end user's computer). If they'd like to use a MTU of 1280 - that is fine
by me. I'll serve them just fine. If they give me a TCP MSS of 1220,
I'll respect that, too.

Just don't ask me to lower *my own* MTU for *every* packet my servers
transmit because *some* users *may* have defective
firewalls/networks/ISPs/tunnels/whatever that prevents my servers from
discovering the MTU in the end user's inbound path.

>> What MTU do you recommend for IPv4 servers, by the way? 576 or 68?
> 
> As you of course know, despite this ironic question, the problem
> comes up in IPv6 because routers can no longer fragment packets.

And when the DF bit is set?

-- 
Tore Anderson
Redpill Linpro AS - http://www.redpill-linpro.com/
Tel: +47 21 54 41 27


More information about the ipv6-ops mailing list