It's set in rdnssd (
ndisc6/rdnssd/icmp.c:106). And that isn't the issue, although there may be other issues with ipv6_ra_conf (see below). At least it has nothing to do with the "Cannot set address" issue I was experiencing. I can't say what is causing that issue (it shouldn't be happening in the first place), but I can say it isn't ipv6_ra_conf.
I do think Asus messed up setting ipv6_ra_conf. rdnssd only ever sets ipv6_ra_conf to
"oset" or "noneset". In start_dhcp6c, they only ever check against the values
"mset" and "noneset". A couple of the checks are if the value is
not "noneset", so one of the places it's set to "oset" may be intentional. Based on the flags they're testing against in rdnssd (ND_RA_FLAG_MANAGED and ND_RA_FLAG_OTHER) and the config file generation in start_dhcp6c, I strongly suspect the first condition is supposed to set it to "mset" instead of "oset". That would make the following values for ipv6_ra_conf:
- noneset = None. Address and DNS provided by RA. dhcp6c is only used to request a prefix delegation.
- mset = Managed. Address and DNS provided by DHCPv6. dhcp6c is used to request an address, DNS servers and a prefix delegation.
- oset = Other. Address provided by RA, DNS provided by DHCPv6. dhcp6c is only used to request DNS servers and a prefix delegation.
Comcast users fall under the case that probably should be "mset" and explains why we never get a WAN IPv6 address. It's never requested! I just haven't had a chance to test changing this yet. This should be the only issue caused by this bug, though.
This actually won't have any effect if you reboot, it's set every time in rdnssd just before start_dhcp6c is called (the only place it's read). You would have to set it, then restart dhcp6c.
Code:
nvram set ipv6_ra_conf=mset
nvram commit
service restart_dhcp6c