Hello Arren,
thank you very much for your reply. As for confusion, we are in the same
boat.
In deed, the server logs do claim, the client is requesting the aa80
prefix, but the tcpdump proves otherwise, as I have posted an excerpt of.
And the configuration of the client goes d'accord with the contents of
the tcpdump - both of which contradict the server message.
Here is a snipped from the client config, that, again, seems to get
mirrored with the tcpdump, from systemd-networkd, in case you are
familiar with its syntax:
[DHCPv6]
UseAddress=true
UseDelegatedPrefix=true
PrefixDelegationHint=2001:dead:beef:aa00::/57
...
And, for better readability, here again the snippet from wireshark:
A Prefix
Option: IA Prefix (26)
Length: 25
Preferred lifetime: 0
Valid lifetime: 0
Prefix length: 57
Prefix address: 2001:dead:beef:aa00::
So in fact, the only one who believes, that the aa80 prefix has been
requested, is the server.
And it does not think this way everytime anyway. If above client is the
first one to request a lease (after a full cleanup), it is presented the
aa00 net - with an according hint log. As to be expected.
If another machine came before, this one will get's the aa80 prefix. The
third machine would be assigned the aa00 net again. And so on.
So basically, in this example the server is ignoring the hint every
other time a lease gets requested and is writing into its logs, whatever
subnet it feels it wants to delegate.
In other words: the hint message the server log is writing does not
actually correspond to what the client packet contains as a prefix
request, but to what subnet the server feels it wants to delegate this
time.
Hence my question. And my confusion. But I am hoping, I have been able
to make my issue clearer.
I am aware, that honoring hints is no requirement and optional, but it
would be helpful to know, wether this behaviour is intented or wether we
might have a configuration issue.
If it is works as designed, then this log entry:
... and hint=2001:dead:beef:aa80::
is misleading at best as it almost surely does not refer to the hint
send by the client, unless I have missed something fundamentally. Not
unlikely, though.
As a side note, we've witnessed this behaviour with kea 2.6.1 on FreeBSD
as well.
Thank again for your time.
Ede
Am 10.08.24 um 17:14 schrieb Darren Ankney:
Hi Ede,
I am not sure I understand what you are asking here but if the client
is being allocated 2001:dead:beef:aa80::/57 this should be no
surprise. This prefix pool:
"pd-pools": [
{ "prefix": "2001:dead:beef:aa00::",
"prefix-len": 56,
"delegated-len": 57
} ]
contains two /57 prefix:
2001:dead:beef:aa00::/57
2001:dead:beef:aa80::/57
The client seems to have sent a hint for 2001:dead:beef:aa80:: as
shown in this log message:
DEBUG DHCP6_PROCESS_IA_PD_REQUEST duid=[00:..], tid=0x..: server is
processing IA_PD option with iaid=.. and hint=2001:dead:beef:aa80::
Then you said:
"And of course that upper aa80 net is finally being delegated, despite
the client requesting the lower of the two."
But that doesn't seem to be the prefix for which the client sent a
hint as was shown in the provided log message.
I am confused.
Thank you,
Darren Ankney
On Thu, Aug 8, 2024 at 6:59 AM Ede Wolf <[email protected]> wrote:
Hello,
new to kea I am having a /56 network, that is being delegated downstream
by kea in two /57 nets.
Kea seems to assign those two subnets in a round robin fashion to
clients, so to have a group of clients receiving a certain subnet, I am
using prefix hints containing the netid desired with the /57 length.
According to my limited understanding of wireshark, those hints are
being sent by the client, but seemingly ignored by kea.
The question is, is this likely to be a misconfiguration or sloppieness
on my side or just works as designed? I have found astonishingly little
about prefix hints and kea, but maybe my google skills lack as well.
I am running kea-2.2 as shipped by debian 12
From the client solicit:
A Prefix
Option: IA Prefix (26)
Length: 25
Preferred lifetime: 0
Valid lifetime: 0
Prefix length: 57
Prefix address: 2001:dead:beef:aa00::
But from the server logs:
DEBUG DHCP6_PROCESS_IA_PD_REQUEST duid=[00:..], tid=0x..: server is
processing IA_PD option with iaid=.. and hint=2001:dead:beef:aa80::
And of course that upper aa80 net is finally being delegated, despite
the client requesting the lower of the two. And this is a
testenvironment, so the pools are certainly not exhausted. Would be kind
of impossible anyway.
The subnet configuration is pretty much bare minimum:
{
"subnet": "fde1:dead:beef:16::/64",
"interface": "eth0",
"id": 11,
"pools": [ { "pool": "fde1:dead:beef:16::12 -
fde1:dead:beef:16::ffba" } ],
"pd-pools": [
{ "prefix": "2001:dead:beef:aa00::",
"prefix-len": 56,
"delegated-len": 57
} ]
}
Thanks
Ede
--
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
[email protected]
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
[email protected]
https://lists.isc.org/mailman/listinfo/kea-users
