Hi, all tunnels should be able to support a minimum 1500 MTU even if a small amount of fragmentation is necessary. Any MTU smaller than 1500 is a degenerate MTU and does not support tunnels within tunnels to sufficient levels of recursive depth. When I say "fragmentation", I mean IPv6 fragmentation which fixes the problems in IPv4 fragmentation.
Thanks - Fred fred.l.temp...@boeing.com > -----Original Message----- > From: ipv6-ops-bounces+fred.l.templin=boeing....@lists.cluenet.de > [mailto:ipv6-ops- > bounces+fred.l.templin=boeing....@lists.cluenet.de] On Behalf Of Jeroen Massar > Sent: Tuesday, November 11, 2014 11:27 AM > To: Ryan Hamilton > Cc: IPv6 Ops list; Lorenzo Colitti > Subject: Re: MTU = 1280 everywhere? / QUIC (Was: Some very nice ...) > > On 2014-11-11 20:05, Ryan Hamilton wrote: > [..] > > > Does QUIC work from behind your tunnel? If so, maybe my colleagues > > have > > > already solved that problem. > > > > > > If the MTU is 1280, QUIC will not (currently) work, and Chrome will > > fall back to using TCP. > > Thanks for acknowledging this (and answering the BCC :). > > Are there any plans for resolving it by supporting the minimum MTU of > 1280 or better still, a variable MTU from 1280 upwards? > > > From: > > > > https://docs.google.com/document/d/1RNHkx_VvKWyWg6Lr8SZ-saqsQx7rFV-ev2jRFUoVD34/mobilebasic > > "UDP PACKET FRAGMENTATION" but IPv6 dos not fragment... > > no mention on handling ICMP PTBs either, let alone mention of IPv6. > > > > > > Yup, if the MTU is too small to accommodate our packets we detect QUIC > > as broken and fallback to TCP. We assume that fragmentation and > > reassembly is rarely successful. > > Indeed, please do not rely on fragmentation. It would have been best if > IPv6 did not even had it in the first place as people just think they > should be using it while it just complicates matters. > > As far as I understood the QUIC and TCP connections race each other and > the first one wins (after which QUIC either works and is used, or TCP > works and that is used). > > Hence, QUIC not passing properly will not cause any slow down; though > there are extra packets involved which do not go anywhere. > > As you do that kind of discovery you might want to use a similar > technique as in RFC4821 to get a full packet. > > [..] > > (Btw, note the "UPD" typo there, too minor to report that as a 'bug' ;) > > > > Seems it was 1200, but got upped to a magic 1350: > > https://codereview.chromium.org/427673005/ > > https://codereview.chromium.org/420313005/ > > > > Not much background there; but those sizes are likely > > > > > > Yes, currently our max packet size is 1350 bytes of UDP payload (8 > > bytes fewer for IPv6). We chose this number based on the results of > > experiments we ran which tried various packet sizes and saw what > > fraction of the net was able to send and received them. 1350 was a good > > compromise between reachability and maximum payload. > > Sounds like a reasonable selection indeed. > > Greets, > Jeroen >