The limitation are of course you can’t receive fragmented packages :-). For TCP based protocols this is no problem, because you can fragment at layer 4.
For UDP based protocols it depends. Either you have some sort of fragmentation on the application layer or you might need to upgrade to TCP. If both is not possible you are limited to the Path MTU in package size (in most cases about 1500 byte).
Biggest problem is DNS, but with the TC bit there is a easy way to upgrade to TCP. So a server could send a response with the TC bit set instead of fragmented the package. This also limits the impact of amplification attacks.
This is the second bug in FreeBSD regarding IPv6 fragmentation in a short time. First one is a overflow on reassemble (https://www.freebsd.org/security/advisories/FreeBSD-SA-23:06.ipv6.asc). Might be a good idea to disable fragmentation support by default.
What’s the implication of that? Will that limit ipv6 connectivity?
First of all, I meant ipv4 and v6 fragmentation.
The limitation are of course you can’t receive fragmented packages :-). For TCP based protocols this is no problem, because you can fragment at layer 4.
For UDP based protocols it depends. Either you have some sort of fragmentation on the application layer or you might need to upgrade to TCP. If both is not possible you are limited to the Path MTU in package size (in most cases about 1500 byte).
Biggest problem is DNS, but with the TC bit there is a easy way to upgrade to TCP. So a server could send a response with the TC bit set instead of fragmented the package. This also limits the impact of amplification attacks.
There is a RFC discussing the problems: https://www.rfc-editor.org/rfc/rfc8900.html