[SR-Users] Path MTU issues over UDP/IPv6

Richard Fuchs rfuchs at sipwise.com
Wed May 18 07:38:22 CEST 2022


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.kamailio.org/pipermail/sr-users/attachments/20220518/b5f098df/attachment.htm>


More information about the sr-users mailing list