What happend to "accept_ra" and "ip6slaac"?

For Developers
1

So accept_ra is removed as an config option from /etc/config/network since 9a62439c282490622d5817f3464b1870e9f1b87c (Fri Feb 1 12:28:39 2013 +0000)?
Any more details about the intention back in the days?

In 3abc91552264757680134b2be9f2f870c77aabcc (Tue Apr 9 12:12:30 2013 +0000) I see that once upon a time there was also ip6slaac available. What happened here?

As I got it somehow working, I assume, for an slaac-only interface configuration, I have to do

        option  proto           'dhcpv6'
        option  reqaddress      'none'
        option  reqprefix       'no'
        option  noslaaconly     '0'

This is somehow not quiet clear from the wiki and also am I confused why a user "needs" to configure slaac via the dhcpv6 proto....

The following one achieves the same result but is on the same level of confusion:

        option  proto           'none'
        option  auto            '1'
        option  force_link      '1'
        option  ip6assign       '64'

I'm also under the impression that the user needs to set net.ipv6.conf.eth0.accept_ra=2 because I could not find any reference that OpenWRT supports this any longer (Read as: Applying net.ipv6.conf.eth0.accept_ra=2 for the user because of some wrapper settings).

Thanks for any pointers and hits.

PS: Yes the interface config from above is on an interface where a router on the other side sends RA.
PPS: I used git log -p -S 'accept_ra' and git log -p -S 'ip6slaac', if there is another good way please let me know!
PPPS: Nah, I'm still not quiet sure what I really want to achieve, I'm just playing around.

1 Like
2

Could someone at least confirm that's the way to configure slaac only on an interface? Searching for accept_ra here in the forum gave me the impression that proto dhcpv6 is the "official" way and I am not the first one who gets confused from it...

3

Maybe @hauke can say something to it? I would also be interested why accept_ra was removed completely.

1 Like
4

OpenWrt made a deliberate design decision to process RAs completely in userspace. The dropped accept_ra uci option was just a wrapper around the sysctl option which only makes sense in conjunction with kernel based RA processing, that's why it was dropped.

Reasoning behind processing RAs in userspace is that we want complete control over the IPv6 addressing on the system and not have the kernel interfere with netifd's network address state management by adding/removing addresses "beneath" the system.

2 Likes