Ipv6 mtu problem with microsoft skype for business/lync

JKnott

Maybe I don't understand something but how does my MTU impact their sending behavior?

Your MTU also affects how large of packet you can receive. With TCP, the 2 ends exchange the Maximum Segment Size (MSS) which is determined by the MTU. This allows the 2 ends to agree on a size that both can handle. However, it appears Skype might be ignoring that.

dopey

Huh. I thought that mss/mtu was only relevant between hops and, especially with ipv6, that path mtu discovery should be used.

Still, yeah either way it looks like MS' end is broken. Even if they aren't acknowledging a "negotiated" mtu/mss, they should be handling an icmpv6 packet too big response shouldn't they?

yay for big nebulous enterprise solutions. Microsoft doesn't provide end-user support for their lync/skype for business service, and my company's IT response is "we don't support ipv6 so stop using it".

JKnott

MSS is used to set the packet size at the ends only. It doesn't know what intermediate hops can support. If intermediate hops can't support the packet size, then an ICMP too big message is sent, which the source should respond to.

dopey

Huh. I'm definitely a little confused here. I just set my client (macos) to an mtu of 1480 and it works. That seems to be the cut-off point. Anything higher than 1480 doesn't work.

I understand the significance of 1480 for 6rd but i wonder why that makes a difference? Isn't that just to prevent the ipv4 fragmentation? That's still feasible with 6rd isn't it? Not ideal but should function right?

JKnott

1480 or 1280? 1280 is commonly used for MTU on tunnels such as 6rd. I don't know what the reason for that is, though the IPv6 MTU must allow for the IPv4 header within whatever the LAN MTU is.

dopey

wan_stf on pfsense has mtu set to 1280.
But in order for skype/lync to work I just have to set the interface mtu to no higher than 1480 (checked with mac os and linux):
2: wlp58s0: <broadcast,multicast,up,lower_up>mtu 1480 qdisc mq state UP mode DORMANT group default qlen 1000

i was under the impression the reason for 1480 (1472 if you're using pppoe) is for the 1500byte packet to handle the 20 ipv4 headers and the 8 byte ppp headers.
So I'm really confused why 1480 works (centurylink uses pppoe and 6rd, so i was expecting 1472 to work). If wan_stf is only 1280, it would seem that even 1480 would still be aproblem right?

The wireshark capture (From the mac) shows a 1494 length ethernet frame and 1440 IP frame for the successful response from webdir.online.lync.com. I couldn't figure out how to disable tso with the ath10k wireless device on my linux laptop.</broadcast,multicast,up,lower_up>

JKnott

Setting the interface MTU to 1500 will result in a 1480 maximum IPv6 packet size, after allowing 20 bytes for IPv4, because the IPv6 packet is just data to IPv4. Regardless, for some reason tunnels are often set to the minimum IPv6 MTU of 1280, as was the case with the tunnel I used to use. I don't know what 6rd uses though. What's the tunnel MTU?

dopey

@JKnott:

I don't know what 6rd uses though. What's the tunnel MTU?

I don't know. How do I tell?
I coudl only tell that the wan_stf interface has an mtu of 1280. Not sure what other mtu there is.

JKnott

@dopey:

@JKnott:

I don't know what 6rd uses though. What's the tunnel MTU?

I don't know. How do I tell?
I coudl only tell that the wan_stf interface has an mtu of 1280. Not sure what other mtu there is.

Is that wan_stf your 6rd tunnel? I haven't used a tunnel with pfSense, so I don't know what to look for there. Netstat -r should show the prefix, but I see it's truncated when displayed. I'll have to figure out how to see the entire line.

dopey

https://www.freebsd.org/cgi/man.cgi?query=stf

Looks like the stf interface is the tunnel interface, and
https://redmine.pfsense.org/issues/6377

It appears to be hardcoded for 1280
the default gateway for Internet6 is out the wan_stf interface.

But back to my point, the purpose of setting a lower MTU for ipv6 in a tunnel enviroment is to ensure that the encapsulation doesn't result in ipv4 packet fragmentation. So in proper settings, the actual internal ipv6 mtu shouldn't matter, and since the 1280 is being enforced my the ipv6 tunnel, my guess is if I tried to send a larger packet than 1280 (tested with ping) i get an icmpv6 packet too big response that would normally be handled. So on my transmit side, everything works fine.
But on my receive side something microsoft is transmitting too, between them and my network has a lower mtu than 1500, and they aren't properly handling packet too big, likely causing the problem right?

The reason why setting my mtu lower makes this work is because it negotiates an initially smaller transmit size on the MS end that doesn't appear to run into a packet too big problem on the network? Maybe they have a 6to4 tunnel in between somewhere :)

dopey

Let's see if I get any traction with this post:
https://answers.microsoft.com/en-us/msoffice/forum/msoffice_sfb-mso_mac-mso_o365b/skype-for-businesslync-services-dont-appear-to/c204b511-8b0b-4338-924e-729603627413