Subject: kern/13131: there's no way for raw IPv4 socket applications to use PMTUD
To: None <email@example.com>
From: None <firstname.lastname@example.org>
Date: 06/07/2001 12:12:30
>Synopsis: there's no way for raw IPv4 socket applications to use PMTUD
>Arrival-Date: Wed Jun 06 20:11:01 PDT 2001
>Originator: Jun-ichiro itojun Hagino
System: NetBSD starfruit.itojun.org 1.5W NetBSD 1.5W (STARFRUIT) #497: Tue Jun 5 10:52:25 JST 2001 email@example.com:/usr/home/itojun/NetBSD/src/sys/arch/i386/compile/STARFRUIT i386
we have a new path MTU discovery validation code in TCP layer. ICMPv4
does not handle ICMPv4 need fragment by default; ICMPv4 layer needs
to be informed of need fragment messages, from L4 code (foo_ctlinput)
by a call to icmp_mtudisc().
with raw IPv4 socket (IP_HDRINCL case), we can generate IPv4 packet
with DF bit set. however, we do not have any foo_ctlinput logic, nor
the calls to icmp_mtudisc(), so PMTUD won't happen. userland code
cannot run PMTUD by itself, as ICMPv4 need fragment messages will not
be presented to the userland programs.
4.4BSD code accepts any ICMPv4 need fragment messages, so raw IPv4
socket can assume that the kernel will do PMTUD automatically.
(however, 4.4BSD code is vulnerable against DoS attempts that use
ICMPv4 need fragment storm - routing table entries will overflow
the kernel memory)
TCP layer do call icmp_mtudisc(), so it can run PMTUD.
UDP layer has no problem, since we cannot throw any UDP packet with
DF bit set with the current API.
- the issue is very minor issue, so leave it as is.
- have rip_ctlinput() and call icmp_mtudisc() as necessary - i plan
to do this anyways, to solve issues with stale inp->inp_route
- just like ICMPv6 sockets, throw ICMPv4 messages up to listening
raw sockets as necessary. ask IP_HDRINCL userland apps to handle
ICMPv4 need fragment messages. (too much kernel API change)