Re: WIndows Updates Fail Via IPv6 - Update!

[Jeroen Massar <jeroen () massar ch>]

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