dhcpcd-discuss

Hi Roy,

You wrote:

> > This is an answer only if one wanted to disable autonomous
> > auto-configuration globally as a policy for the subnet, but this
> > wasn't my question. Sorry, I should have made this clear.
> >
> > The question is about client-side configuration. On a subnet where the
> > router allows both autonomous and managed address configuration we
> > want to configure a host such that it only configures the address
> > assigned by DHCP, but not generate addresses autonomously based on the
> > hardware address or randomized (privacy extension).
>
> I see.
> With dhcpcd you can disable RS solicitation and RA processing per
> interface (noipv6rs as you found).
> However, this is an all or nothing flag. We would add a new option to
> dhcpcd to ignore the Auto flag in RA messages.
> We can't use the kernels autoconf option because we may have a RA
> without the Managed flag set and as such still need to configure an
> address autonomously.

Not really. If the interface is configured to use only a DHCP address 
then only DHCP addresses should be used. In my opinion, systems should 
not behave as if they knew better than the humans who configured them.

If the global policy on the subnet does not allow the use of DHCP 
addresses, but the local configuration asked for DHCP-only, then dhcpcd 
should simply not configure a global address at all. This would likely 
be a configuration error and the failure should be made obvious to the 
user instead of silently doing something that was explicitly not wanted.

Just to be clear, the default configuration on most systems would be to 
use SLAAC, of course, we are here discussing the special case where a 
system administrator has made the explicit decision to use DHCP-only on 
a specific interface on a specific host, and this decision should be 
honoured by the software.

> Before we even add this option, what is your expected outcome if this
> new option is set and dhcpcd receives a RA from two or more different
> routers, one with Auto and Managed, one with only Auto and one with only
> Managed?
> I ask because any outcome will conflict with the configuration and
> expected functionality when connecting to the network.

Multiple routers on the same link will not be a typical scenario, and 
those routers advertising different policies will be even less likely, 
hence I wouldn't use such a scenario to drive the design. On the other 
hand, it can happen, so I agree that the behaviour needs to be defined.

If an RA with the manage flag set is received it will be legitimate to 
look for a dhcp server and negotiate an address. If other routers send 
RAs that don't have the manage flag set, then so be it, those RAs can be 
ignored.

Like I wrote above, the unlikely scenario of multiple routers sending 
RAs with inconsistent policies should not be the focus, but if one 
wanted to get fancy, I suppose you could match the prefixes from the RAs 
with the address the DHCP server returns and only configure the address 
if it matches a prefix from an RA that had the manage flag set, but this 
extra work would probably not be worth the effort.

Thanks,

Joachim



> > Although I haven't confirmed this, I'm guessing that ISC's dhclient
> > does this when the autoconf kernel setting is off, but accept_ra
> > turned on. Unfortunately, dhcpcd currently seems to treat this as an
> > error and won't start the DHCP negotiation.
>
> ISC's dhclient doesn't even look at the RA - it's up-to another userland
> agent to process this and then start dhclient when needed.
>
> Thanks
>
> Roy

--
joachima@xxxxxxxxxxxxxx http://www.netacquire.com