Re: Question about NetBSD implementation of IPv6 SLAAC and RFC4941

[Roy Marples <roy%marples.name@localhost>]

On 08/04/2020 17:27, Robert Elz wrote:
>      Date:        Tue, 7 Apr 2020 22:33:45 +0100
>      From:        Roy Marples <roy%marples.name@localhost>
>      Message-ID:  <aedc88ef-b8e7-656f-4cf0-ae4214b7f922%marples.name@localhost>
>
>    | We're at the point where something in userland needs to solicit an RA to
>    | guarantee connectivity ASAP
>
> It is not difficult to have the kernel send an RS when an interface
> comes up. 

You would need DaD to finish on the LL address, which means the carrier needs to 
be up too.

>  It would be a bit more difficult (I suppose, haven't tried)
> to do it properly, with random delays and all that.

Random delay are a RFC requirement.

> (my environment doesn't
> benefit from that - I don't have lots of systems all starting at the same
> time, as in after power to a whole bunch of systems is switched on).
> Similarly, my environment is quiet enough that the RS doesn't get lost
> in practice, so I also survive without any kind of retry.   Eliminate
> all that and an RS is just a very boring multicast (destination) ICMPv6
> packet (not really any different from the DaD packets that are sent).

When I code on the sofa on my pinebook, my urtwn sometimes goes funny for a 
while and suffers packet loss after it associates.
This why 3 RS are sent on carrier up.

Still, no-one has actually come up with a technical reason why the kernel should 
handle RA's. From a security perspective, handling it in a chrooted environment 
with an unpriviledged user would be a lot better yes? That's just one of many 
technical reasons why RA should be removed from the kernel.

Roy