WIndows Updates Fail Via IPv6 - Update!
Jeroen Massar
jeroen at massar.ch
Sun Mar 3 19:57:02 UTC 2019
On 2019-03-03 20:13, Mark Tinka wrote:
>
>
> On 3/Mar/19 18:05, Jeroen Massar wrote:
>
>> IPv6 requires a minimum MTU of 1280.
>>
>> If you cannot transport it, then the transport (the tunnel in this case) needs to handle the fragmentation of packets of 1280 down to whatever does fit in the tunnel.
>
> As you know, IPv6 does not support fragmentation in transit. So that's
> not an option.
The transport (tunnel) CAN support that kind of fragmentation.
(e.g. the tunnel could chop up a 1280 byte packet into two packets and the remote then join them together; that is a "ethernet" level thing).
Indeed, IPv6 won't do it: get a better transport.
> Host fragmentation is per standard, but signaling of that was not so
> successful in IPv4. Real world scenarios for IPv6 (reasonably) apply here.
Real world for IPv6 is: do not try to transport it over a medium that does not support packets of at least 1280 bytes.
>> Have fun with all your UDP traffic that does not care about your TCP MSS adjustment. You just hid the problem...
>
> I considered this issue, but as with all things UDP re: fragmentation,
> it depends.
>
> Testing I've been doing all day shows previously (mostly-TCP) issues
> have resolved, and I've not run into any major problems that are
> impacting UDP. Nonetheless, I'm keeping an eye out.
>
>
>>
>> And a correctly configured MTU is especially going to be fun with "HTTP/3" that is being pushed through, even though the predecessor QUIC does not care about MTU at all... good that it is all in the hands of a company that can fix it themselves ;)
>
> Is it an ideal situation? About as ideal as flying in the cargo bay. But
> my reality is that until my FTTH provider can deliver native IPv6, this
> is what I have.
Maybe you should ask this "FTTH" provider to deliver a decent MTU size? (next to native IPv6, something something, 20+ years old protocol...)
Greets,
Jeroen
More information about the NANOG
mailing list