>
> 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
–
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
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 (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 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
–
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
–
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
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 (https://github.com/google/netboot). 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.
Few years later, I read more of the Kea documentation any my impression is that the management API is present but only very limited portion of it. Parts which Foreman would require (record management) is a Premium hook (plugin) which requires subscription. It’s not free.
Kea also does strictly stick with DUIDs for IPv6, there is a support for MAC address via Client Link Layer Option recognition but that does not cover all the use cases or hardware. Finally, Kea is not present in RHEL 9 (Beta).
All and all, while Kea is definitely one of the best DHCP servers out there, it has its quirks and it does not solve problems of devops/admins in 2021.
As was mentioned by Ewoud, ISC DHCP (the old implementation) now supports MAC-based reservations for IPv6. I was not able to find this feature mentioned in their changelog but RHEL8 now has version 4.3.6 which should have this feature (unless this was a debian-only patch). Unfortunately, this does not help much because omapi does not support IPv6 record creation so Foreman cannot utilize that without modifying configuration files and restarting the daemon. Not something we want to do I guess although I’ve seen this in production too.
An interesting project called dhcpy6d was mentioned, but it intentionally breaks the DHCPv6 contract and I have some concerns about scalability. But it could be a way if we want to keep the tight DHCP records management in Foreman:
To me, it looks like the best approach might be the idea of having two DHCP servers on the same network. One would be only serving PXE clients providing network-boot information (filename option, TFTP server option) and the other would provide network credentials (IP address, router, netmask).
However, I was never sold on the idea of utilizing netboot, the experimental project mentioned above. If you click on the link you will find out that the project is no longer maintained. The idea is valid tho.
Proposal: What you feel about utilizing dnsmasq to do PXE-DHCP (and possibly even TFTP) services? It can be configured in a way that it will only reply to PXE clients providing required filename/TFTP options for both TFTP/PXE and UEFI HTTP boot clients.
This PXEDHCP could be actually a new foreman-proxy feature, there would be no API because there is nothing to configure - it’s completely static. As long as PXE/HTTP directory is managed by Foreman and MAC-based Grub2/PXELinux/iPXE configuration file is deployed, the client will pick it up. It will contain the provisioning UUID (token) that will allow loading of additional templates.
The only question is - would this work in real production? I mean obviously it’s something we can verify in our labs or libvirt networks, however, I can imagine some poor DHCP client implementations might not expect two DHCP replies (although specs allow that and even define exactly what to do).
