Re: DHCPv6 without SLAAC
Joachim Achtzehnter
Thu Jan 08 18:32:29 2015
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.
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.
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.
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. ;)
Thanks,
Joachim
On 2015-01-08 6:00, Roy Marples wrote:
Hi Joachim
On 08/01/2015 03:31, Joachim Achtzehnter 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).
It helps if I read messages like this if not concentrating on
Christmas :)
OK, so basically if Auto is set AND Managed is set, you want an option to
ignore Auto.
Yes, exactly. The addrconf RFC says that "Creation of global and
site-local addresses and configuration of other parameters as described
in this section SHOULD be locally configurable. However, the processing
described below MUST be enabled by default."
So the standards do not object to having an option for a local system to
opt-out of stateless auto-configuration. On Linux systems, this is
usually controlled by the autoconf kernel parameter, which my original
patch tried to honour.
Here is a patch which allows this, but before I commit it, a question.
If we set this new option and receive a RA with Managed set so DHCPv6 is
kicking off but a new RA appears without Managed set but with prefixes
and auto
flags set, should dhcpcd ignore these also or generate SLAAC addresses
for
them?
Yes, otherwise the option would be pointless. When this option is
engaged no other global scope addresses should be configured, except the
one negotiated with a DHCP server.
We have a similar use case when the local administrator wants to assign
an address manually, and not have anything assigned automatically,
except for the link-local address. Of course, in this case we simply
don't call the DHCP client.
So many use cases and possible problems.
I played around with my patch in various scenarios it and wasn't exactly
ideal.
So I revisited your original patch (respect Linux ipv6/conf/autoconf
parameter) and changed it to a generic dhcpcd option as this kernel
tunable doesn't exist in any BSD I know of. This puts the decision
entirely in the hands of the user.
Comitted here:
http://roy.marples.name/projects/dhcpcd/ci/4dd3f7b8d9e0ae20755b1224eb0375a141bf21f6?sbs=0
But still, this doesn't match your original request:
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).
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? What is there is another router with a different subnet on the
same network that requires autoconf as there is no DHCP?
Admittedly the last one is unlikely, but still technically possible.
Now, it's only really tricky because of your statement:
only configures the address assigned by DHCP
So let us revisit the rationale for your request, ie why you asked this
in the first place. I'm hopeful that you are asking for this to control
source address selection - as all things being equal Linux will use the
last IPv6 address added to the interface. So, lets make things unequal
with a new setting which will set the preferred lifetime of the autoconf
addresses to 0 when a DHCPv6 address exists on the interface. If, for
any reason, the DHCPv6 addresses expire or are removed then the
preferred lifetimes are restored to the autoconf addresses.
Is this what you really want - source address selection?
Roy
--
joachima@xxxxxxxxxxxxxx http://www.netacquire.com
Archive administrator: postmaster@marples.name