10

With IPv4, TCP MSS "clamping" (a network device editing the MSS value in a TCP header) can help when path maximum transmission unit discovery is not working. (e.g., when ICMP is being blocked somewhere in the path.) Since there's no fragmentation in IPv6, we still have ICMPv6's 'packet too big' to signal the originating end point.

Is there any guidance about clamping TCP MSS over IPv6 specifically?

Improve this question

2 Answers 2

Reset to default
15

Well technically fragmentation can happen in IPv6; This is the wikipedia article on it.

This Juniper page is a bit old but it shows that you can clamp an MSS for TCP over IPv6 on Junos the same as you would in IPv4 using the same command, tcp mss. The same is shown in this article for Cisco IOS 15, using the traditional ip tcp adjust-mss command.

So you can configure MSS clamping if PMTUD isn't working as it should be in a part of your network, otherwise, you should be ensuring that you are aiding the smoothing running of PTMUD across your networking so that MSS clamping isn't required (I understand this isn't always under your control).

Update

Here is a link to a newer Junos article for Junos 10x rather than 9, I can't find one for 11 and I'm not in front of 11 right now, but I expect it will be the same.

Improve this answer
3
  • ...am I reading the fragmentation description correctly? IPv4 fragmenting could happen at any hop in the route, while in IPv6, the routers must drop the packet (notify via ICMPv6) and then fragmentation is done by the end-points?
    – Craig Constantine
    May 9, 2013 at 19:43
  • 2
    Yes, that's correct. Fragmentation in v6 is not done by the routers unless the router is acting as a host. IE: Management traffic over v6, etc.
    – bigmstone
    May 9, 2013 at 19:46
  • 1
    There's a subtlety here in that at least the IOS version of adjust-mss is broken, in that it clamps v6, but incorrectly: blog.ioshints.info/2013/01/…
    – LapTop006
    May 10, 2013 at 13:07
3

There are definitely cases - usually involving IPv6-in-IPv4 tunnels at some point along the path - where even if PMTUD works correctly, MSS negotiation fails. In this case a TCP session may start correctly (since the SYN/ACK packets are small) but no data packets arrive (since those packets are too big for the tunnel). In this case MSS clamping at the far end would help, but is not under control of the "victim" waiting for the packets. The fail-safe solution is for both ends to set the IPv6 MTU to 1280, which should get through any tunnel.

Improve this answer
1
  • "MSS negotiation fails." MSS is not negotiated. Each side sends, in the SYN, what its MSS is. The other side needs to respect the MSS sent by the other side, and each can be different. MSS is not negotiated, it is dictated. One, or both, side(s) could set MSS to '0', meaning that there is no MSS in that direction, and any size segment can be sent in that direction. That is explained in RFC 793.
    – Ron Maupin ♦
    Dec 20, 2020 at 2:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.