Re: DHCPv6 without SLAAC
Joachim Achtzehnter
Fri Jan 09 21:45:09 2015
Hi Roy,
You wrote:
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?
It wouldn't exactly break, but for certain purposes it would then only
use one of these.
In our case, it is mostly a matter of dealing with a big code base for
an application that expects a one-to-one relationship between interfaces
and addresses, so we want to avoid having to deal with multiple
addresses per interface for now. We only use global scope addresses, so
the link-local address is not a problem. At some point in the future we
will enhance the application to support multiple addresses per
interface, and addresses that come and go at runtime (yes, we know this
can happen), but we don't want to tackle this right now. Even then, we
will probably still want to give the users a choice about which address
configuration methods should be used, and which not.
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
Being swamped by other tasks, I probably won't get a chance to try this
until some time next week.
Thanks,
Joachim
Thanks
Roy
--
joachima@xxxxxxxxxxxxxx http://www.netacquire.com
Archive administrator: postmaster@marples.name