mtu

[Erik Kline]

Ricardo,

Without being too explicit, let me just toss out ~4 categories of IPv6
brokenness we've seen in various network devices/scenarios:


(1)  Just no IPv6 implementation whatsoever

Pretty self-explanatory.  (My mom's home gateway falls into this
category.  Poor mom.)


(2) No or low quality or quantity of testing

Sometimes devices/code will actually have basically working IPv6
implementations but because of various constraints they have not had
sufficient real world testing.  If you're lucky you find these in your
testing sandbox.  Otherwise you probably only see the brokenness when
live traffic starts to pass through it.


(3) IPv6 != IPv4 with bigger addresses

This is particularly annoying.  Some implementations fail to notice
the subtle differences, like that Path MTU is required to work, or you
might have to (gasp!) process an IPv6 extension header, etc.  Some
implementations appear to understand that these differences exist but
don't implement them properly anyway.  These could fall in category
#2, so maybe this is really #2.5 in stead of #3.


(4) Misconfiguration

This is the category to which I think folks refer most often, namely
misconfigured ICMP6 filtering (either breaking pMTU or in some cases
even breaking ND!), not paying careful attention to route preferences
when one of them goes through a tunnel, and other symptoms of not
generally paying the same attention to IPv6 as folks do to IPv4.


Depending on your mood you might consider software IPv6
implementations a "brokenness" where there should be hardware
implementations.  Or add a general category for "poor performing
implementations", but mostly I'd be concerned with *working* over
performing, at least for current levels of IPv6 traffic.

That being said, I'm not aware of any significant performance problem
IPv6 Google services might be experiencing due to an MTU of 1280.  If
you see some please let us know (google-ipv6 at google.com).  Obviously
it would be cooler to run with a slightly higher MTU but I would
listen to Geoff on the "1480 might be pushing your luck" point.  YMMV,
obviously.

(Geoff:  I still have no idea why those other 8 bytes are shaved off,
but I've not had time to look into it.  :-)

2009/2/2 Geoff Huston <gih at apnic.net>:
> 1480 still appears to be a little too high if you want to be conservative. A
> teredo packet requires a 40 octet header, not 20 becuase of the UDP packet.
>
> Google offer an initial TCP mss of 1212 (which corresponds to an IPv6 packet
> of 1272 octects - I'm not sure why they left 'headroom' of 8 octets here -
> maybe some TCP option? Or allowing for an MPLS header? Or ...?
>
> I've seen 1300 octets and 1400 octets being used.
>
> but I'd offer the view that 1480 is pushing it close.
>
> But perhaps there is another way of looking at this. Ricardo, why do you
> want to keep the MTU as large as you can? What issues do you think you will
> encounter for your web pages with a MTU of, say, 1300 octets, as compared to
> using 1480 octets?
>
>  Geoff
>
>
>
>
> On 03/02/2009, at 8:06 AM, Ricardo Patara wrote:
>
>> Hello Erik,
>> Actually I tried to send an email to point of contact associated with the
>> IP block :)
>> Then I search for some google folks email address with no success. Thanks
>> for your promptly answer and attention on this.
>>
>> In our case, in order to test if the MTU was the problem, we lowered it to
>> 1480. But maybe it should be something around the number you mentioned.
>>
>> Just for curiosity, did google tried to contact upstream providers or
>> peering to find out if there was any icmp6 filtering in some of the paths?
>>
>> thanks again.
>> --
>>  Ricardo Patara
>>
>> Em 02/02/2009, às 16:59, Erik Kline escreveu:
>>
>>> 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
>>>>
>>>>
>>
>
>