mtu

Geoff Huston gih at apnic.net
Mon Feb 2 22:13:04 CET 2009


I had found a problem with the RFC Editor web site that prompted me to
look at PMTU behavior and write the article that Erik references. The
somewhat annoying aspect of this problem is that both the server and the
client  can be fully IPv6 "compliant" and doing absolutely nothing wrong
IPv6-wise, and still the client can get a white screen "hang".

What I find (as described in that article) was an initial TCP  
handshake with a
MSS of 1440 was being used, while the true path MTU was 1480 bytes,
or a TCP MSS of 1420. What I also found was that a change in end-to-end
path resolved the issue for me.

It seems that the most pragmatic advice is to use a lower-than-1500 MTU
from the outset for IPv6 servers. More details of what I found are at
http://ispcolumn.isoc.org/2009-01/mtu6.html

Given that the IPv6 spec requires all network elements to cope with a
1280 octet IPv6 packet without fragmentation Google's approach here
appears to be a "safe" one in terms of maximizing the prospects of a
successful connection. (www.ripe.net uses a similar reduced IPv6 MTU  
size, as does
www.apnic.net - I have not done any exhaustive survey here, but the  
problems
with the original rfc-editor server prompted me to look around a bit  
to see what
others did with their initial MTU.





On 03/02/2009, at 5:59 AM, Erik Kline wrote:

> You tried to contact us?  I must have missed that email, sorry.
>
> We set the MTU to 1280 near the server.  We've not had any reported
> MTU problems (knock on wood), to the best of my knowledge.
>
> FWIW:  http://ispcolumn.isoc.org/2009-01/mtu6.html
>
> 2009/2/2 Ricardo Patara <patara at lacnic.net>:
>> Hi,
>> Just wondering if some of you are using this technique to avoid  
>> problems
>> from someone else accessing your website, for instance.
>>
>> We have our site with ipv6 for a while now, and have received  
>> complaints and
>> we had opportunity to face the same problem several times.
>>
>> This happens when trying to access the site via a tunnel  
>> connection. The
>> browser simply gives a timeout.
>> We think this is related to pmtu and sites filtering icmp6.
>>
>> One of the solutions was to lower down the MTU at the site server.
>> The question is, if this is the solution you did in case you also  
>> faced this
>> problem.
>> I tried to contact someone from google, but with no success.
>>
>> I mention google as we always try ipv6.google.com when having this  
>> type of
>> problem just to make sure there is nothing "completely" wrong the  
>> network
>> setup.
>>
>> thanks
>> --
>> Ricardo Patara
>>
>>



More information about the ipv6-ops mailing list