dhcpcd-discuss

Hi Joachim

On Thursday 08 Jan 2015 10:31:54 Joachim Achtzehnter wrote:
> Hi Roy,
> 
> > So this is actually quite tricky, for a variety of reasons. What if
> > there is no DHCP server? What if it stops responding and the address
> > expires?
> 
> Then the system has no connectivity. The same will be the case on a
> network that does not allow autonomous address configuration, i.e.,
> where routers do not set the A bit, only the M bit. In both cases
> connectivity depends on a working DHCPv6 server. These are
> administrative choices.

Agreed that they are entirely administrative choices.

> > What is there is another router with a different subnet on the
> > same network that requires autoconf as there is no DHCP?
> 
> A host configured to use DHCP-only will not communicate on that subnet.
> 
> > Admittedly the last one is unlikely, but still technically possible.
> 
> Exactly, it is unlikely, and in any case, nobody is forced to choose the
> DHCP-only setting, but some may want to.
> 
> > Now, it's only really tricky because of your statement:
> >> only configures the address assigned by DHCP
> 
> Sorry, I fail to see how this is tricky. It is sanctioned by the RFCs,
> and widely supported. Systems using ifupdown, like Debian, offer the
> inet6 methods static, auto, dhcp, and manual. For dhcp there is a
> sub-option autoconf, which controls whether stateless auto-configuration
> will or will not be done in addition to dhcp. Fedora 20 with network
> manager offers "Automatic", "Automatic, DHCP only", "Manual", and
> "Link-Local Only" via its Gnome 3 GUI settings dialog.

Agreed it's all RFC compliant. Maybe I'm just picking nits and over-
engineering this trying to work out what you really want vs what you actually 
asked for. I suspect my reasoning here is entirely to blame.

> > Is this what you really want - source address selection?
> 
> There can be many reasons why one may want one kind of IPv6 address and
> not another. We have an unusual technical reason imposed by a ported
> legacy application. For some reason, you seem to be fine with this
> administrative choice when it is made network-wide via A and M flags,
> but are reluctant to acknowledge the legitimacy of an equivalent choice
> for client-side configuration.

I'm just trying to understand the motive, that is all.
Out of curiosity, have you considered if your application would break if it's 
offered two addresses in the DHCPv6 transaction? Or if the order they are given 
swaps over?

> Offering this client-side choice is only a 'SHOULD' requirement in the
> RFC, so you can certainly choose to ignore it, in which case we can
> choose to use dhclient instead of dhcpcd, or use a locally modified
> version of dhcpcd.  ;)

Of course I would prefer everyone didn't locally patch their dhcpcd to suit as 
that makes upgrading that much harder, but heh ho. I would prefer it even less 
if you changed to dhclient, but then again I have an obvious bias.
Such is the nature of open source!

Hopefully the patch I committed today has the result you want!
Here it is again incase you missed it:
http://roy.marples.name/projects/dhcpcd/ci/4dd3f7b8d9e0ae20755b1224eb0375a141bf21f6?sbs=0

Thanks

Roy