18 May
2022
18 May
'22
5:38 a.m.
On 12/05/2022 07.31, [EXT] Rick van Rein wrote:
Hello,
IPv6 routers never fragment packets. Rather, they drop a packet that
is too large for a (local) MTU and send back ICMPv6 "Packet Too Big".
This seems to cause loss of larger SIP messages when an ISP tunnels
their IPv6 at the expense of the MTU.
The pmtu_discovery flag sets Don't Fragment in IPv4 traffic; in IPv6
this is an implied property. Does Kamailio learn a lower MTU from
any "Packet Too Big" for IPv6 even if pmtu_discovery is not set?
Future resends can then be fragemented appropriately.
The udp_mtu setting diverts to another protocol, but that would be a
setting as low as the worst peer, impacting all. It would be a weird
struggle with a telco serving many. PMTU would be better to rely on,
but how does it work in Kamailio?
I haven't looked at the Kamailio code either, but in general this is
handled by the network stack directly (e.g. the Linux kernel),
transparent to the application (Kamailio).
1. The application wants to send a packet and uses the appropriate API
(e.g. the kernel's send() system call).
2. The kernel takes care to actually send the packet out to its
destination.
3. The packet then hits an MTU barrier along its path. The packet is
discarded by the remote router and the router sends back an ICMPv6
packet to the originator.
4. The kernel receives this ICMPv6 packet and from this learns that the
path MTU to that destination is lower. The application generally is
not notified about this. An automatic retransmission also doesn't
happen.
5. The application wants to send another packet to the same destination
(e.g. in Kamailio's case probably a retransmission of the first one,
as that packet was never acknowledged).
6. The application does exactly the same thing as in step 1.
7. The kernel now knows about the smaller PMTU to that packet's
destination and will therefore fragment the packet appropriately
before sending the fragments out.
Cheers