[Kea-users] Handling of Prefixdelegation hints

[Ede Wolf]

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 <listac at nebelschwaden.de> 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
>> Kea-users at lists.isc.org
>> https://lists.isc.org/mailman/listinfo/kea-users