Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
Ah, ok. In my experience, devices that don't support DHCP option 108, are
not ready to live on an ipv6 only network, and need some sort of ipv4 to
function.
--Dan
On Mon, Jul 31, 2023 at 1:42 PM Brian Candler wrote:
> On 31/07/2023 19:32, Dan Oachs wrote:
> > I'm confused. What is the issue with Kea offering v6 only clients an
> > ipv4 address? The client will not accept the ipv4 address and kea
> > will not reserve that IP address for them. The end result is a
> > drastic reduction in ipv4 pool usage. At least, that's how it is
> > working for me.
>
> This is a proof-of-concept IPv6-only network: no IPv4 addresses at all,
> and no NAT44 (only NAT64).
>
> You are correct that RFC8925-aware clients refuse the IPv4 address
> offered. However if someone plugs in a non-RFC8925 client, and Kea
> offers them an IPv4 address, they will use it.
>
> That's why I want to detect whether the client is announcing RFC8925
> capability, and I was hoping for something less ugly (and more robust)
> than this:
>
> "client-classes": [
> {
> "name": "rfc8925",
> "test": "substring(option[55].hex, 0, 1) == 0x6c or
> substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
> 1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
> substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
> 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
> substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
> 1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
> substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
> 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
> },
> ],
>
>
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
On 31/07/2023 19:32, Dan Oachs wrote:
I'm confused. What is the issue with Kea offering v6 only clients an
ipv4 address? The client will not accept the ipv4 address and kea
will not reserve that IP address for them. The end result is a
drastic reduction in ipv4 pool usage. At least, that's how it is
working for me.
This is a proof-of-concept IPv6-only network: no IPv4 addresses at all,
and no NAT44 (only NAT64).
You are correct that RFC8925-aware clients refuse the IPv4 address
offered. However if someone plugs in a non-RFC8925 client, and Kea
offers them an IPv4 address, they will use it.
That's why I want to detect whether the client is announcing RFC8925
capability, and I was hoping for something less ugly (and more robust)
than this:
"client-classes": [
{
"name": "rfc8925",
"test": "substring(option[55].hex, 0, 1) == 0x6c or
substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
},
],
--
ISC funds the development of this software with paid support subscriptions.
Contact us at https://www.isc.org/contact/ for more information.
To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users.
Kea-users mailing list
Kea-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
I'm confused. What is the issue with Kea offering v6 only clients an ipv4 address? The client will not accept the ipv4 address and kea will not reserve that IP address for them. The end result is a drastic reduction in ipv4 pool usage. At least, that's how it is working for me. Thanks, Dan Oachs On Sun, Jul 30, 2023 at 2:44 PM Brian Candler wrote: > On 30/07/2023 14:28, Darren Ankney wrote: > > I have not tested this, but you could use the 'v6-only-preferred' > > setting in the subnet (see: > > > https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#ipv6-only-preferred-networks > ). > > As the config I included in my original mail shows, I'm already using > that option. Yes it works. But I still end up *offering* clients an > IPv4 address from the pool, even those which request the > v6-only-preferred option and will actually not request the offered > address; and RFC 8925 says the server should set yiaddr 0.0.0.0 in this > situation. > > > If I'm understanding what you are saying ... DON'T allocate v4 to > > clients who DON'T send v6 only option? Won't that result in a bunch > > of clients with no IP at all? > > No, because those clients will still be able to get an IPv6 address (via > either SLAAC or DHCPv6, depending on what I set up on the network) > > > Kea does not appear to offer native support for RFC 2563. I must not > > be understanding what you are saying. You also want the clients that > > didn't receive any ip address (v4 or v6) to not auto-configure a > > 169.254 address? > > Correct. Clients which don't understand RFC 8925 will still try to > obtain an IPv4 address. However, if they support RFC 2563 then I can > detect this, and use this option to control whether or not they assign a > link-local IPv4 address. Again: if I'm not offering them a real IPv4 > address, then the RFC says the yiaddr should be 0.0.0.0. > > Clients which don't implement either RFC 2563 or RFC 8925, I don't want > to respond to. If they choose to assign a link-local IPv4 address, > that's up to them. > > Regards, > > Brian. > > -- > ISC funds the development of this software with paid support > subscriptions. Contact us at https://www.isc.org/contact/ for more > information. > > To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. > > Kea-users mailing list > Kea-users@lists.isc.org > https://lists.isc.org/mailman/listinfo/kea-users > -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
On 30/07/2023 14:28, Darren Ankney wrote: I have not tested this, but you could use the 'v6-only-preferred' setting in the subnet (see: https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#ipv6-only-preferred-networks). As the config I included in my original mail shows, I'm already using that option. Yes it works. But I still end up *offering* clients an IPv4 address from the pool, even those which request the v6-only-preferred option and will actually not request the offered address; and RFC 8925 says the server should set yiaddr 0.0.0.0 in this situation. If I'm understanding what you are saying ... DON'T allocate v4 to clients who DON'T send v6 only option? Won't that result in a bunch of clients with no IP at all? No, because those clients will still be able to get an IPv6 address (via either SLAAC or DHCPv6, depending on what I set up on the network) Kea does not appear to offer native support for RFC 2563. I must not be understanding what you are saying. You also want the clients that didn't receive any ip address (v4 or v6) to not auto-configure a 169.254 address? Correct. Clients which don't understand RFC 8925 will still try to obtain an IPv4 address. However, if they support RFC 2563 then I can detect this, and use this option to control whether or not they assign a link-local IPv4 address. Again: if I'm not offering them a real IPv4 address, then the RFC says the yiaddr should be 0.0.0.0. Clients which don't implement either RFC 2563 or RFC 8925, I don't want to respond to. If they choose to assign a link-local IPv4 address, that's up to them. Regards, Brian. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
Hi Brian,
I have not tested this, but you could use the 'v6-only-preferred'
setting in the subnet (see:
https://kea.readthedocs.io/en/kea-2.4.0/arm/dhcp4-srv.html#ipv6-only-preferred-networks).
I'm not sure what you are trying to do is possible. But try this
setting to see if it accomplishes your ultimate goal (clients that
send v6 only option don't configure v4).
If I'm understanding what you are saying ... DON'T allocate v4 to
clients who DON'T send v6 only option? Won't that result in a bunch
of clients with no IP at all?
Kea does not appear to offer native support for RFC 2563. I must not
be understanding what you are saying. You also want the clients that
didn't receive any ip address (v4 or v6) to not auto-configure a
169.254 address? I must not be understanding your goal...
Thank you,
Darren Ankney
On Fri, Jul 28, 2023 at 3:12 PM Brian Candler wrote:
>
> Hello,
>
> I have a somewhat out-of-the-ordinary config question. I'm using
> isc-kea-dhcp4 version 2.4.0 under Ubuntu 22.04. The full config is at
> the end of this mail.
>
> Background: I have set up a "mostly IPv6" subnet, as per this article:
> https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/
>
> I have it working when offering IPv4 addresses to all clients. Those
> which support the v6-only-preferred option happily ignore the IPv4
> address that I offer, and will configure themselves as IPv6-only. Neat.
>
> However, I want to tighten this up to make it a true "IPv6-only"
> network, as follows:
>
> (a) Only make an offer to clients which request the "v6-only-preferred"
> parameter (option 108, RFC 8925). That is: I don't want to offer IPv4
> addresses to anyone who will actually use them.
>
> (b) Offer yiaddr 0.0.0.0, as RFC 8925 section 3.3 says I should, instead
> of a pool address. And preferably get rid of the pool entirely.
>
>
> Problem 1: in order to test whether the client supports
> v6-only-preferred, I have to check whether 108 is included in the
> dhcp-parameter-request-list (option 55) from the request.
>
> Unfortunately, "option[108].exists" does not work for this, because the
> client isn't sending option 108; they are only requesting option 108 as
> a response parameter.
>
> The only solution I could come up with was this:
>
> "client-classes": [
> {
> "name": "rfc8925",
> "test": "substring(option[55].hex, 0, 1) == 0x6c or
> substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
> 1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
> substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
> 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
> substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
> 1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
> substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
> 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
> },
> ],
>
> ... and even that's not complete, in case the client requests more than
> 13 options. Is there a better way to do this?
>
>
> Problem 2: how can I return a yiaddr of 0.0.0.0 ? I thought about
> setting a static dummy flex-id, e.g.
>
> "reservations": [
> {
> "flex-id": "'any'",
> "ip-address": "0.0.0.0"
> }
> ]
>
> but I'm using the open-source version of Kea, which means I don't have
> the flex_id hook. I don't think a pool starting from 0.0.0.0 will work,
> because once that's been given out to one client, it's no longer
> available for other clients (unless I use a tiny lease time??) In any
> case, I'd also avoid allocating addresses from a pool in the first
> place, so that the pool doesn't become exhausted.
>
> If I can get this to work, I'd do the same for clients which support RFC
> 2563 (auto-configure option), which also allows the server to return
> yiaddr 0.0.0.0.
>
> Any clues appreciated. If Kea doesn't support this use case, maybe I
> need to cobble together something custom for this.
>
> Thanks in advance,
>
> Brian.
>
> 8<
>
> {
> "Dhcp4": {
> "interfaces-config": {
> "interfaces": [ "enp6s0" ]
> },
>
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/tmp/kea4-ctrl-socket"
> },
>
> "lease-database": {
> "type": "memfile",
> "lfc-interval": 3600
> },
>
> "renew-timer": 900,
> "rebind-timer": 1800,
> "valid-lifetime": 3600,
>
> "subnet4": [
> {
> // Subnet identifier should be unique for each subnet.
> "id": 1,
>
> // Subnet binds to dummy interface address (10.12.65.1)
> "subnet": "10.12.65.0/24",
> "authoritative": true,
>
> // Dummy pool - still needs to be big enough for all unique
> clients
> "pools": [
>
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
On 28/07/2023 22:03, Dan Oachs wrote: I'm a little confused about what you are trying to do. What don't you like about the way it is working now? I want to make this a pure IPv6-only network (not dual-stack), which means: - not offering any IPv4 address to clients which don't support RFC 8925 (which means detecting whether they request option 108, and not responding to clients which don't) - more correctly following RFC 8925 by returning 0.0.0.0 in the offer (which would also allow me to support RFC 2563) - not having to worry about IPv4 pool exhaustion I *could* simply not run any DHCPv4 service at all, but macOS doesn't activate its CLAT unless it gets an RFC 8925 DHCPv4 response. -- ISC funds the development of this software with paid support subscriptions. Contact us at https://www.isc.org/contact/ for more information. To unsubscribe visit https://lists.isc.org/mailman/listinfo/kea-users. Kea-users mailing list Kea-users@lists.isc.org https://lists.isc.org/mailman/listinfo/kea-users
Re: [Kea-users] Problems trying to implement RFC 8925 (v6-only-preferred)
I'm a little confused about what you are trying to do. What don't you like
about the way it is working now?
I have also configured an "ipv6-mostly" network and have kea doing the
option 108 thing and am happy with the way it is all working.
--Dan
On Fri, Jul 28, 2023 at 2:12 PM Brian Candler wrote:
> Hello,
>
> I have a somewhat out-of-the-ordinary config question. I'm using
> isc-kea-dhcp4 version 2.4.0 under Ubuntu 22.04. The full config is at
> the end of this mail.
>
> Background: I have set up a "mostly IPv6" subnet, as per this article:
>
> https://labs.ripe.net/author/ondrej_caletka_1/deploying-ipv6-mostly-access-networks/
>
> I have it working when offering IPv4 addresses to all clients. Those
> which support the v6-only-preferred option happily ignore the IPv4
> address that I offer, and will configure themselves as IPv6-only. Neat.
>
> However, I want to tighten this up to make it a true "IPv6-only"
> network, as follows:
>
> (a) Only make an offer to clients which request the "v6-only-preferred"
> parameter (option 108, RFC 8925). That is: I don't want to offer IPv4
> addresses to anyone who will actually use them.
>
> (b) Offer yiaddr 0.0.0.0, as RFC 8925 section 3.3 says I should, instead
> of a pool address. And preferably get rid of the pool entirely.
>
>
> Problem 1: in order to test whether the client supports
> v6-only-preferred, I have to check whether 108 is included in the
> dhcp-parameter-request-list (option 55) from the request.
>
> Unfortunately, "option[108].exists" does not work for this, because the
> client isn't sending option 108; they are only requesting option 108 as
> a response parameter.
>
> The only solution I could come up with was this:
>
> "client-classes": [
> {
> "name": "rfc8925",
> "test": "substring(option[55].hex, 0, 1) == 0x6c or
> substring(option[55].hex, 1, 1) == 0x6c or substring(option[55].hex, 2,
> 1) == 0x6c or substring(option[55].hex, 3, 1) == 0x6c or
> substring(option[55].hex, 4, 1) == 0x6c or substring(option[55].hex, 5,
> 1) == 0x6c or substring(option[55].hex, 6, 1) == 0x6c or
> substring(option[55].hex, 7, 1) == 0x6c or substring(option[55].hex, 8,
> 1) == 0x6c or substring(option[55].hex, 9, 1) == 0x6c or
> substring(option[55].hex, 10, 1) == 0x6c or substring(option[55].hex,
> 11, 1) == 0x6c or substring(option[55].hex, 12, 1) == 0x6c"
> },
> ],
>
> ... and even that's not complete, in case the client requests more than
> 13 options. Is there a better way to do this?
>
>
> Problem 2: how can I return a yiaddr of 0.0.0.0 ? I thought about
> setting a static dummy flex-id, e.g.
>
> "reservations": [
> {
> "flex-id": "'any'",
> "ip-address": "0.0.0.0"
> }
> ]
>
> but I'm using the open-source version of Kea, which means I don't have
> the flex_id hook. I don't think a pool starting from 0.0.0.0 will work,
> because once that's been given out to one client, it's no longer
> available for other clients (unless I use a tiny lease time??) In any
> case, I'd also avoid allocating addresses from a pool in the first
> place, so that the pool doesn't become exhausted.
>
> If I can get this to work, I'd do the same for clients which support RFC
> 2563 (auto-configure option), which also allows the server to return
> yiaddr 0.0.0.0.
>
> Any clues appreciated. If Kea doesn't support this use case, maybe I
> need to cobble together something custom for this.
>
> Thanks in advance,
>
> Brian.
>
> 8<
>
> {
> "Dhcp4": {
> "interfaces-config": {
> "interfaces": [ "enp6s0" ]
> },
>
> "control-socket": {
> "socket-type": "unix",
> "socket-name": "/tmp/kea4-ctrl-socket"
> },
>
> "lease-database": {
> "type": "memfile",
> "lfc-interval": 3600
> },
>
> "renew-timer": 900,
> "rebind-timer": 1800,
> "valid-lifetime": 3600,
>
> "subnet4": [
> {
> // Subnet identifier should be unique for each subnet.
> "id": 1,
>
> // Subnet binds to dummy interface address (10.12.65.1)
> "subnet": "10.12.65.0/24",
> "authoritative": true,
>
> // Dummy pool - still needs to be big enough for all unique
> clients
> "pools": [
> {
> // Only give OFFERs to devices which support RFC 8925
> "pool": "10.12.65.2 - 10.12.65.254",
> "client-class": "rfc8925"
> }
> ],
>
> //
>
> https://kea.readthedocs.io/en/latest/arm/dhcp4-srv.html#dhcp4-std-options-list
> "option-data": [
> {
> // RFC 8925: option 108
> // (Note that client does not *send* this option,
> but includes it in
> // the requested parameters
