I'm working on adding support for IPv6/DHCPv6 on smart-proxy side, and
have come across several issues on which I'd like to hear your
thoughts.
It is not possible to assign ipv6 addresses to host records
(reservations) when ISC dhcpd is used.
This is due to a limitation in host record serialization code in dhcpd
[1], which assumes that fixed address is always four octets long.
I can see two possible approaches to compensate for this. One approach
would be to define host records without ip addresses. To ensure that
dns records stay valid, preferred-lifetime dhcpv6 option can be used
to extend lease duration. On host removal, lease state or lease expiry
date can be updated, or lease object can be destroyed altogether. As
ipv6 addresses are managed by a dhcp server in this scenario, after a
host has been created, an additional call to smart-proxy will be
required to discover its ip address.
Another approach is to delegate dns record updates to dhcp server.
Client fqdn or partial hostname can be passed to dhcp server via
“client fqdn” option [2]. This approach may require additional client
configuration — I don’t know how various linux distributions configure
their dhcpclient (I think recent windows clients send this information
by default).
It is difficult to determine host’s client id (dhcp unique
identifier, AKA DUID)
its value depends on os, dhcp client, and even version of the client.
DUID is persistent across system reboots, but may be lost on os
(re)installation. [3] has more details on how various client generate
DUID. To simplify host management/reduce support issues, it might be
necessary to configure host DUID during system install, possibly by
using uuid value from system’s DMI table [4].
PXE uses client id (UUID/GUID) that is different from that of the host.
This will result in two ipv6 addresses being allocated to every host
that uses PXE. One approach is allocate ipv6 addresses from different
pools with different preferred-lifetime options. In this approach PXE
pool would have very short lease durations. Clients that belong to the
PXE pool can be identified by the presence of “boot file url” dhcp
option.
Another approach is to have smart-proxy act as a simple dhcp server.
It would answer dhcp requests containing “boot file url” itself and
ignore/relay all other requests to the main dhcp server. This approach
could result in less orchestration in Foreman: for example, with this
approach pxe boot configuration can be generated on demand and served
via http, without any config files created/updated on a tftp server.
Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The code
you linked seems to be related to "fixed-address" which is the ipv4
variant.
Another question I have, does DHCP really need to be the one assigning the
address? Should DHCP just be providing config info, and leave the address
up to SLAAC? [1]
···
On Mon, Mar 6, 2017 at 10:53 AM, Dmitri Dolguikh wrote:
I’m working on adding support for IPv6/DHCPv6 on smart-proxy side, and
have come across several issues on which I’d like to hear your
thoughts.
It is not possible to assign ipv6 addresses to host records
(reservations) when ISC dhcpd is used.
This is due to a limitation in host record serialization code in dhcpd
[1], which assumes that fixed address is always four octets long.
I can see two possible approaches to compensate for this. One approach
would be to define host records without ip addresses. To ensure that
dns records stay valid, preferred-lifetime dhcpv6 option can be used
to extend lease duration. On host removal, lease state or lease expiry
date can be updated, or lease object can be destroyed altogether. As
ipv6 addresses are managed by a dhcp server in this scenario, after a
host has been created, an additional call to smart-proxy will be
required to discover its ip address.
Another approach is to delegate dns record updates to dhcp server.
Client fqdn or partial hostname can be passed to dhcp server via
“client fqdn” option [2]. This approach may require additional client
configuration — I don’t know how various linux distributions configure
their dhcpclient (I think recent windows clients send this information
by default).
It is difficult to determine host’s client id (dhcp unique
identifier, AKA DUID)
its value depends on os, dhcp client, and even version of the client.
DUID is persistent across system reboots, but may be lost on os
(re)installation. [3] has more details on how various client generate
DUID. To simplify host management/reduce support issues, it might be
necessary to configure host DUID during system install, possibly by
using uuid value from system’s DMI table [4].
PXE uses client id (UUID/GUID) that is different from that of the host.
This will result in two ipv6 addresses being allocated to every host
that uses PXE. One approach is allocate ipv6 addresses from different
pools with different preferred-lifetime options. In this approach PXE
pool would have very short lease durations. Clients that belong to the
PXE pool can be identified by the presence of “boot file url” dhcp
option.
Another approach is to have smart-proxy act as a simple dhcp server.
It would answer dhcp requests containing “boot file url” itself and
ignore/relay all other requests to the main dhcp server. This approach
could result in less orchestration in Foreman: for example, with this
approach pxe boot configuration can be generated on demand and served
via http, without any config files created/updated on a tftp server.
>
> Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6. The code
> you linked seems to be related to "fixed-address" which is the ipv4 variant.
>
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
> Another question I have, does DHCP really need to be the one assigning the
> address? Should DHCP just be providing config info, and leave the address up
> to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?), but
it has a potential for making our life harder.
-d
···
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote:
> - It is difficult to determine host’s client id (dhcp unique identifier, AKA DUID)
What you mean by that? If sysadmins let DUID to change, they are
breaking IPv6 specs and servers will mis-behave. What exactly are you
trying to solve here. We can provide some tools to help them (e.g.
sending DUIDs alongside with other facts so they can easily recover
them if they reboot or something like that). Do you have some
automatic DUID management in mind?
NM calculates DUID from system-id, we can generate both in advance
when creating new host and provide them via Kickstart or snippet
indeed if this makes things easier.
> - PXE uses client id (UUID/GUID) that is different from that of the host.
Is this a real issue? We already deal with two allocations per PXE
booted system with IPv4 (even three if you use discovery) and it
works.
Anyway, I am writing dnsmasq provider in my spare time. Does dnsmasq
makes it any better? I was primarly targetting to improve out-of-box
experience on IPv4 networks, but if dnsmasq makes it easier (I haven't
looked into IPv6 at all), I can speedup my coding and provide the
plugin earlier. Dnsmasq can work as DHCP or DHCP Proxy and it's in
RHEL. Even if it won't provide a workaround or replacement, we could
send a patch or something as it has smaller and modern codebase.
Writing own DHCP proxy? Meeeh. Just a thought.
···
On Mon, Mar 6, 2017 at 4:53 PM, Dmitri Dolguikh wrote:
>
> This is definitely the case as far as ipv6-specific dhcpd
> configuration goes. The code I linked to is responsible for
> persistence of in-memory host records, and it doesn’t support ipv6 at
> all.
Maybe I am confused. Are you trying to add support for fixed-address6 or
trying to work around the support not being there?
···
On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh wrote:
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for DHCPv6. The
code
you linked seems to be related to “fixed-address” which is the ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Another question I have, does DHCP really need to be the one assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?), but
it has a potential for making our life harder.
>> - It is difficult to determine host’s client id (dhcp unique identifier, AKA DUID)
>
> What you mean by that? If sysadmins let DUID to change, they are
> breaking IPv6 specs and servers will mis-behave. What exactly are you
> trying to solve here. We can provide some tools to help them (e.g.
> sending DUIDs alongside with other facts so they can easily recover
> them if they reboot or something like that). Do you have some
> automatic DUID management in mind?
There are a few issues here:
/etc/machine-id is generated during system install (each new clean
install on the same hardware will yield a different machine-id).
NetworkManager above 0.9.7.997 derives DUID based on
/etc/machine-id. We cannot calculate DUID prior to system installation
unless we manage /etc/machine-id.
sysconfig-based networking by default will use DUID-LLT (link-layer
address plus timestamp) in stateful mode, but it can be overridden in
the interface config file. We will need to manage interface config
files in order to have persistent DUIDs.
Windows hosts use yet another way of configuring DUIDs
As DUID value is dependent on how network interfaces are configured, we:
may need to ask the user how they plan to manage networking and
generate appropriate configuration (probably too error-prone)
create config files for both NetworkManager and sysconfig
>
> NM calculates DUID from system-id, we can generate both in advance
> when creating new host and provide them via Kickstart or snippet
> indeed if this makes things easier.
Yes, also see above.
>
>> - PXE uses client id (UUID/GUID) that is different from that of the host.
>
> Is this a real issue? We already deal with two allocations per PXE
> booted system with IPv4 (even three if you use discovery) and it
> works.
Less so for IPv6. It’s something that we may need to manage however,
esp. if we decide to rely on dns record management by dhcp server.
>
> Anyway, I am writing dnsmasq provider in my spare time. Does dnsmasq
> makes it any better? I was primarly targetting to improve out-of-box
> experience on IPv4 networks, but if dnsmasq makes it easier (I haven't
> looked into IPv6 at all), I can speedup my coding and provide the
> plugin earlier. Dnsmasq can work as DHCP or DHCP Proxy and it's in
> RHEL. Even if it won't provide a workaround or replacement, we could
> send a patch or something as it has smaller and modern codebase.
> Writing own DHCP proxy? Meeeh. Just a thought.
>> This is definitely the case as far as ipv6-specific dhcpd
>> configuration goes. The code I linked to is responsible for
>> persistence of in-memory host records, and it doesn’t support ipv6 at
>> all.
>
> Maybe I am confused. Are you trying to add support for fixed-address6 or
> trying to work around the support not being there?
The latter.
-d
···
On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne wrote:
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for DHCPv6. The
code
you linked seems to be related to “fixed-address” which is the ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Another question I have, does DHCP really need to be the one assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?), but
it has a potential for making our life harder.
Wouldn't it be better to add support for fixed-address6 or is there some
issue with doing that?
···
On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh wrote:
On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne pgagne@redhat.com wrote:
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Maybe I am confused. Are you trying to add support for fixed-address6 or
trying to work around the support not being there?
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for DHCPv6. The
code
you linked seems to be related to “fixed-address” which is the ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Another question I have, does DHCP really need to be the one assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?), but
it has a potential for making our life harder.
> Wouldn't it be better to add support for fixed-address6 or is there some
> issue with doing that?
It looks to me like ISC aren’t really interested in extending
functionality of dhcpd. On top of this, it may actually be more work
than it looks: both memory db serialization and omapi need updates
(the latter accepts fixed-addresses only atm). I have a pretty
high-level understanding of dhcpd codebase, but even at this level it
looks like omapi-related change might be quite big in scope.
-d
···
On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne wrote:
On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne pgagne@redhat.com wrote:
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Maybe I am confused. Are you trying to add support for fixed-address6 or
trying to work around the support not being there?
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for DHCPv6.
The
code
you linked seems to be related to “fixed-address” which is the ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Another question I have, does DHCP really need to be the one
assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?), but
it has a potential for making our life harder.
I'm sorry I was a little confused, I thought we were talking about adding
support for fixed-address6 to foreman. Not adding better support to ISC DHCP
···
On Tue, Mar 7, 2017 at 11:37 AM, Dmitri Dolguikh wrote:
On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne pgagne@redhat.com wrote:
Wouldn’t it be better to add support for fixed-address6 or is there some
issue with doing that?
It looks to me like ISC aren’t really interested in extending
functionality of dhcpd. On top of this, it may actually be more work
than it looks: both memory db serialization and omapi need updates
(the latter accepts fixed-addresses only atm). I have a pretty
high-level understanding of dhcpd codebase, but even at this level it
looks like omapi-related change might be quite big in scope.
On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne pgagne@redhat.com wrote:
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Maybe I am confused. Are you trying to add support for fixed-address6
or
trying to work around the support not being there?
The latter.
-d
On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh < > witlessbird@gmail.com> > >> > wrote:
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com > wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for DHCPv6.
The
code
you linked seems to be related to “fixed-address” which is the ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6 at
all.
Another question I have, does DHCP really need to be the one
assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?),
but
it has a potential for making our life harder.
We can always try to offload the work on platform team, I've been
pretty successful in getting some work done in iPXE project for
example. The only issue is this can take some time until it gets to
the other team backlog.
To be honest, I don't know which path you should take. I'd vote for
the cleanest one, that is trying to push proper IPv6 into ISC. If
there's no politics behind it, I don't believe they would not want to
have this kind of feature. On the other hand, they've been resisting
quite long time now (IPv6 is old how much, 20 years?
Since you already did great amount of investigation in the IPv6 field,
do you want to give dnsmasq a look in this regard? If this turns out
to be a good workaround, maybe the ISC IPv6 would not be so hot topic
then (when I finish with my provider).
LZ
···
On Tue, Mar 7, 2017 at 5:37 PM, Dmitri Dolguikh wrote:
> On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne wrote:
>> Wouldn't it be better to add support for fixed-address6 or is there some
>> issue with doing that?
>
> It looks to me like ISC aren’t really interested in extending
> functionality of dhcpd. On top of this, it may actually be more work
> than it looks: both memory db serialization and omapi need updates
> (the latter accepts fixed-addresses only atm). I have a pretty
> high-level understanding of dhcpd codebase, but even at this level it
> looks like omapi-related change might be quite big in scope.
>
> -d
>
>>
>> On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh >> wrote:
>>>
>>> On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne wrote:
>>> >> This is definitely the case as far as ipv6-specific dhcpd
>>> >> configuration goes. The code I linked to is responsible for
>>> >> persistence of in-memory host records, and it doesn’t support ipv6 at
>>> >> all.
>>> >
>>> > Maybe I am confused. Are you trying to add support for fixed-address6 or
>>> > trying to work around the support not being there?
>>>
>>> The latter.
>>> -d
>>>
>>> >
>>> > On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh >>> > wrote:
>>> >>
>>> >> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote:
>>> >> >
>>> >> > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6.
>>> >> > The
>>> >> > code
>>> >> > you linked seems to be related to "fixed-address" which is the ipv4
>>> >> > variant.
>>> >> >
>>> >>
>>> >> This is definitely the case as far as ipv6-specific dhcpd
>>> >> configuration goes. The code I linked to is responsible for
>>> >> persistence of in-memory host records, and it doesn’t support ipv6 at
>>> >> all.
>>> >>
>>> >> > Another question I have, does DHCP really need to be the one
>>> >> > assigning
>>> >> > the
>>> >> > address? Should DHCP just be providing config info, and leave the
>>> >> > address up
>>> >> > to SLAAC? [1]
>>> >>
>>> >> It is possible to use autoconf for IPv6 address (self-)assignment and
>>> >> rely on dhcp for host configuration only. I’m not sure how useful
>>> >> autoconf is in larger networks (anyone has experience with this?), but
>>> >> it has a potential for making our life harder.
>>> >>
>>> >> -d
>>> >>
>>> >> >
>>> >> >
>>> >> > [1] https://tools.ietf.org/html/rfc3736
>>> >> >
>>> >>
>>> >> --
>>> >> You received this message because you are subscribed to the Google
>>> >> Groups
>>> >> "foreman-dev" group.
>>> >> To unsubscribe from this group and stop receiving emails from it, send
>>> >> an
>>> >> email to foreman-dev+unsubscribe@googlegroups.com.
>>> >> For more options, visit https://groups.google.com/d/optout.
>>> >
>>> >
>>> > --
>>> > You received this message because you are subscribed to the Google
>>> > Groups
>>> > "foreman-dev" group.
>>> > To unsubscribe from this group and stop receiving emails from it, send
>>> > an
>>> > email to foreman-dev+unsubscribe@googlegroups.com.
>>> > For more options, visit https://groups.google.com/d/optout.
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
After thinking about support for ipv6 + dhcpv6 in smart-poxy and
Foreman some more, I realized that:
while host duid management is possible, it’s going to be somewhat
involved (quite a few different scenarios) and possibly fragile
dhcp servers can be configured to update dns records automatically
using hostname (and domain name, if required) that client passes with
dhcp request (or names can be generated automatically)
Foreman's main requirement is to set correct pxe boot options for
managed hosts
multiple dhcp servers can co-exist on the same network/network
segment, with responses selected by the client based on server
precedence
This leads me to think that having a small dhcp server (that we can
interface with using a convenient set of api) dedicated to handling
pxe requests in a given network segment and ignoring all request is an
option that’s worth investigating. Turns out google has a project that
fits the bill (https://github.com/google/netboot). I’m trying to
establish a contact with project’s maintainers to find out about
dhcpv6 state (not currently implemented) and see if they need help.
Cheers,
-d
···
On Wed, Mar 8, 2017 at 11:53 AM, Lukas Zapletal wrote:
> We can always try to offload the work on platform team, I've been
> pretty successful in getting some work done in iPXE project for
> example. The only issue is this can take some time until it gets to
> the other team backlog.
>
> To be honest, I don't know which path you should take. I'd vote for
> the cleanest one, that is trying to push proper IPv6 into ISC. If
> there's no politics behind it, I don't believe they would not want to
> have this kind of feature. On the other hand, they've been resisting
> quite long time now (IPv6 is old how much, 20 years? :-)
>
> Since you already did great amount of investigation in the IPv6 field,
> do you want to give dnsmasq a look in this regard? If this turns out
> to be a good workaround, maybe the ISC IPv6 would not be so hot topic
> then (when I finish with my provider).
>
> LZ
>
> On Tue, Mar 7, 2017 at 5:37 PM, Dmitri Dolguikh wrote:
>> On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne wrote:
>>> Wouldn't it be better to add support for fixed-address6 or is there some
>>> issue with doing that?
>>
>> It looks to me like ISC aren’t really interested in extending
>> functionality of dhcpd. On top of this, it may actually be more work
>> than it looks: both memory db serialization and omapi need updates
>> (the latter accepts fixed-addresses only atm). I have a pretty
>> high-level understanding of dhcpd codebase, but even at this level it
>> looks like omapi-related change might be quite big in scope.
>>
>> -d
>>
>>>
>>> On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh >>> wrote:
>>>>
>>>> On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne wrote:
>>>> >> This is definitely the case as far as ipv6-specific dhcpd
>>>> >> configuration goes. The code I linked to is responsible for
>>>> >> persistence of in-memory host records, and it doesn’t support ipv6 at
>>>> >> all.
>>>> >
>>>> > Maybe I am confused. Are you trying to add support for fixed-address6 or
>>>> > trying to work around the support not being there?
>>>>
>>>> The latter.
>>>> -d
>>>>
>>>> >
>>>> > On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh >>>> > wrote:
>>>> >>
>>>> >> On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne wrote:
>>>> >> >
>>>> >> > Doesn't ISC DHCPD use " fixed-address6", "range6", etc for DHCPv6.
>>>> >> > The
>>>> >> > code
>>>> >> > you linked seems to be related to "fixed-address" which is the ipv4
>>>> >> > variant.
>>>> >> >
>>>> >>
>>>> >> This is definitely the case as far as ipv6-specific dhcpd
>>>> >> configuration goes. The code I linked to is responsible for
>>>> >> persistence of in-memory host records, and it doesn’t support ipv6 at
>>>> >> all.
>>>> >>
>>>> >> > Another question I have, does DHCP really need to be the one
>>>> >> > assigning
>>>> >> > the
>>>> >> > address? Should DHCP just be providing config info, and leave the
>>>> >> > address up
>>>> >> > to SLAAC? [1]
>>>> >>
>>>> >> It is possible to use autoconf for IPv6 address (self-)assignment and
>>>> >> rely on dhcp for host configuration only. I’m not sure how useful
>>>> >> autoconf is in larger networks (anyone has experience with this?), but
>>>> >> it has a potential for making our life harder.
>>>> >>
>>>> >> -d
>>>> >>
>>>> >> >
>>>> >> >
>>>> >> > [1] https://tools.ietf.org/html/rfc3736
>>>> >> >
>>>> >>
>>>> >> --
>>>> >> You received this message because you are subscribed to the Google
>>>> >> Groups
>>>> >> "foreman-dev" group.
>>>> >> To unsubscribe from this group and stop receiving emails from it, send
>>>> >> an
>>>> >> email to foreman-dev+unsubscribe@googlegroups.com.
>>>> >> For more options, visit https://groups.google.com/d/optout.
>>>> >
>>>> >
>>>> > --
>>>> > You received this message because you are subscribed to the Google
>>>> > Groups
>>>> > "foreman-dev" group.
>>>> > To unsubscribe from this group and stop receiving emails from it, send
>>>> > an
>>>> > email to foreman-dev+unsubscribe@googlegroups.com.
>>>> > For more options, visit https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> You received this message because you are subscribed to the Google Groups
>>>> "foreman-dev" group.
>>>> To unsubscribe from this group and stop receiving emails from it, send an
>>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> You received this message because you are subscribed to the Google Groups
>>> "foreman-dev" group.
>>> To unsubscribe from this group and stop receiving emails from it, send an
>>> email to foreman-dev+unsubscribe@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.
>
>
>
> --
> Later,
> Lukas @lzap Zapletal
>
> --
> You received this message because you are subscribed to the Google Groups "foreman-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
···
On Fri, Mar 10, 2017 at 9:40 AM, Dmitri Dolguikh wrote:
After thinking about support for ipv6 + dhcpv6 in smart-poxy and
Foreman some more, I realized that:
while host duid management is possible, it’s going to be somewhat
involved (quite a few different scenarios) and possibly fragile
dhcp servers can be configured to update dns records automatically
using hostname (and domain name, if required) that client passes with
dhcp request (or names can be generated automatically)
Foreman’s main requirement is to set correct pxe boot options for
managed hosts
multiple dhcp servers can co-exist on the same network/network
segment, with responses selected by the client based on server
precedence
This leads me to think that having a small dhcp server (that we can
interface with using a convenient set of api) dedicated to handling
pxe requests in a given network segment and ignoring all request is an
option that’s worth investigating. Turns out google has a project that
fits the bill (GitHub - danderson/netboot: Packages and utilities for network booting). I’m trying to
establish a contact with project’s maintainers to find out about
dhcpv6 state (not currently implemented) and see if they need help.
Cheers,
-d
On Wed, Mar 8, 2017 at 11:53 AM, Lukas Zapletal lzap@redhat.com wrote:
We can always try to offload the work on platform team, I’ve been
pretty successful in getting some work done in iPXE project for
example. The only issue is this can take some time until it gets to
the other team backlog.
To be honest, I don’t know which path you should take. I’d vote for
the cleanest one, that is trying to push proper IPv6 into ISC. If
there’s no politics behind it, I don’t believe they would not want to
have this kind of feature. On the other hand, they’ve been resisting
quite long time now (IPv6 is old how much, 20 years?
Since you already did great amount of investigation in the IPv6 field,
do you want to give dnsmasq a look in this regard? If this turns out
to be a good workaround, maybe the ISC IPv6 would not be so hot topic
then (when I finish with my provider).
On Tue, Mar 7, 2017 at 4:28 PM, Perry Gagne pgagne@redhat.com wrote:
Wouldn’t it be better to add support for fixed-address6 or is there
some
issue with doing that?
It looks to me like ISC aren’t really interested in extending
functionality of dhcpd. On top of this, it may actually be more work
than it looks: both memory db serialization and omapi need updates
(the latter accepts fixed-addresses only atm). I have a pretty
high-level understanding of dhcpd codebase, but even at this level it
looks like omapi-related change might be quite big in scope.
-d
On Tue, Mar 7, 2017 at 11:27 AM, Dmitri Dolguikh < > witlessbird@gmail.com> > >>> wrote:
On Tue, Mar 7, 2017 at 4:22 PM, Perry Gagne pgagne@redhat.com > wrote:
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6
at
all.
Maybe I am confused. Are you trying to add support for
fixed-address6 or
trying to work around the support not being there?
The latter.
-d
On Mon, Mar 6, 2017 at 11:32 AM, Dmitri Dolguikh < > witlessbird@gmail.com> > >>>> > wrote:
On Mon, Mar 6, 2017 at 4:11 PM, Perry Gagne pgagne@redhat.com > wrote:
Doesn’t ISC DHCPD use " fixed-address6", “range6”, etc for
DHCPv6.
The
code
you linked seems to be related to “fixed-address” which is the
ipv4
variant.
This is definitely the case as far as ipv6-specific dhcpd
configuration goes. The code I linked to is responsible for
persistence of in-memory host records, and it doesn’t support ipv6
at
all.
Another question I have, does DHCP really need to be the one
assigning
the
address? Should DHCP just be providing config info, and leave the
address up
to SLAAC? [1]
It is possible to use autoconf for IPv6 address (self-)assignment
and
rely on dhcp for host configuration only. I’m not sure how useful
autoconf is in larger networks (anyone has experience with this?),
but
it has a potential for making our life harder.
I’m aware of Kea. Unfortunately, there is no management api and the
only way to integrate with it is via db (not sure how stable the
schema is, or if it even has been documented). Same goes for dhcpy6d
(which seems to be quite popular in IPv6 networks, and their db schema
is documented)
-d
···
On Fri, Mar 10, 2017 at 3:02 PM, Perry Gagne wrote:
> It also worth mentioning Kea. Which is the ISC next generation DHCP server.
>
> http://kea.isc.org/wiki
>
> After thinking about support for ipv6 + dhcpv6 in smart-poxy and
> Foreman some more, I realized that:
>
> - while host duid management is possible, it’s going to be somewhat
> involved (quite a few different scenarios) and possibly fragile
If I understand it correct then RFC6939 allows you to use the MAC
address as well. Given this is very close to the IPv4 implementation I
believe this is what should be explored first.
ISC dhcpd 4.3 support this and Debian Jessie ships it, but EL7 doesn't.
Do I understand it correct that besides DUID vs MAC the OMAPI protocol
doesn't support setting IPv6 addresses?
> - dhcp servers can be configured to update dns records automatically
> using hostname (and domain name, if required) that client passes with
> dhcp request (or names can be generated automatically)
While possible, I'm not sure how many people use this in a datacenter
context.
> - Foreman's main requirement is to set correct pxe boot options for
> managed hosts
Correct, it's good not to lose focus on this to keep the scope small.
> - multiple dhcp servers can co-exist on the same network/network
> segment, with responses selected by the client based on server
> precedence
>
> This leads me to think that having a small dhcp server (that we can
> interface with using a convenient set of api) dedicated to handling
> pxe requests in a given network segment and ignoring all request is an
> option that’s worth investigating. Turns out google has a project that
> fits the bill (https://github.com/google/netboot). I’m trying to
> establish a contact with project’s maintainers to find out about
> dhcpv6 state (not currently implemented) and see if they need help.
Also note that it should be packaged.
···
On Fri, Mar 10, 2017 at 02:40:04PM +0000, Dmitri Dolguikh wrote:
>> After thinking about support for ipv6 + dhcpv6 in smart-poxy and
>> Foreman some more, I realized that:
>>
>> - while host duid management is possible, it’s going to be somewhat
>> involved (quite a few different scenarios) and possibly fragile
>
> If I understand it correct then RFC6939 allows you to use the MAC
> address as well. Given this is very close to the IPv4 implementation I
> believe this is what should be explored first.
>
Option 79 is used to specify client link-layer address, but it
requires that either:
dhcp client populate the option, or
first hop dhcp relay populates the option
Which isn't guaranteed. For example neither NetworkManager nor
dhclient generate this option by default.
> ISC dhcpd 4.3 support this and Debian Jessie ships it, but EL7 doesn't.
>
> Do I understand it correct that besides DUID vs MAC the OMAPI protocol
> doesn't support setting IPv6 addresses?
Correct.
>
>> - dhcp servers can be configured to update dns records automatically
>> using hostname (and domain name, if required) that client passes with
>> dhcp request (or names can be generated automatically)
>
> While possible, I'm not sure how many people use this in a datacenter
> context.
Neither do I. Would be interesting to learn.
>
>> - Foreman's main requirement is to set correct pxe boot options for
>> managed hosts
>
> Correct, it's good not to lose focus on this to keep the scope small.
>
>> - multiple dhcp servers can co-exist on the same network/network
>> segment, with responses selected by the client based on server
>> precedence
>>
>> This leads me to think that having a small dhcp server (that we can
>> interface with using a convenient set of api) dedicated to handling
>> pxe requests in a given network segment and ignoring all request is an
>> option that’s worth investigating. Turns out google has a project that
>> fits the bill (https://github.com/google/netboot). I’m trying to
>> establish a contact with project’s maintainers to find out about
>> dhcpv6 state (not currently implemented) and see if they need help.
>
> Also note that it should be packaged.
Nods.
-d
···
On Fri, Mar 10, 2017 at 4:45 PM, Ewoud Kohl van Wijngaarden wrote:
> On Fri, Mar 10, 2017 at 02:40:04PM +0000, Dmitri Dolguikh wrote:
We’re using stateless ipv6 address configuration. Therefore each host is calculating a slaac unique global ipv6 address. The configuration by the router advertisement sets option “Other Config Flag”. This enforces the client to look only for non address information with dhcp requests. In an environment like this a computer can be identified by the ipv6 address. The ip-address won’t change unless the mac address changes.
It would be awesome if we could bind the host object to its unique ipv6 address.
For us your last thought:
would be the right approach to fit our setup. We use iPXE anyway - so no fiddling with tftp.
We’re using stateless ipv6 address configuration. Therefore each host is calculating a slaac unique global ipv6 address. The configuration by the router advertisement sets option “Other Config Flag”. This enforces the client to look only for non address information with dhcp requests. In an environment like this a computer can be identified by the ipv6 address. The ip-address won’t change unless the mac address changes.
I didn’t think of this approach.
would be the right approach to fit our setup. We use iPXE anyway - so no fiddling with tftp.
My changes to support pure ipv6 pxe were accepted to netboot (GitHub - danderson/netboot: Packages and utilities for network booting). Would be great if you could try it in your environment, if that’s a possibility. The idea is to use netboot together with smart-proxy to support ipv6 deployments in the future.
Netboot should now support stateless ipv6 addresses too, which might make it easier for you to test it?
Hi Dmitri,
i was trying your setup but the container was not accepting your options. But anyway the given options are not unique per host but this is necessary. I also tried a different setup which uses a host specific file on an webserver see my answer in support-list:
i was trying your setup but the container was not accepting your options.
My apologies, I assumed based on the timestamp of the build that it will contain my changes. You should be able to build pixiecore by executing make build from the project’s root, or go build from cmd/pixiecore/ dir.
FWIW, I’ll continue working with this “dedicated dhcp server” approach, let me know if you have more questions, need help, etc.
