> But it is still more kernel code reached. Very true. And I appreciate the feedback on due diligence in general.
On the IPv6 front: What gives me further hesitation is that not matching the router-advertised MTU may still lead to issues. RFC 4861 notes: > Neighbor Discovery allows routers to specify an > MTU for the link, which all nodes then use. All > nodes on a link must use the same MTU (or Maximum > Receive Unit) in order for multicast to work > properly. Otherwise, when multicasting, a sender, > which can not know which nodes will receive the > packet, could not determine a minimum packet size > that all receivers can process (or Maximum Receive > Unit). So, either slaacd fails fully and does not change the MTU (current behavior), or it enters a perhaps less broken state: the MTU is larger, but still not large enough to match the router (proposed behavior). The best course of action may be to fix the router configuration instead, in which a software change to slaacd isn't necessary. On Sun, Nov 20, 2022 at 6:27 PM Theo de Raadt <[email protected]> wrote: > > Stefan R. Filipek <[email protected]> wrote: > > > > they could change the mtu on an interface. > > > > No. I'm only proposing the ability to GET the MTU (SIOCG...). > > > > Setting the MTU (SIOCSIFMTU) is currently in "wroute", which slaacd > > already has pledged. > > OK. > > But it is still more kernel code reached.
