[Kea-users] Handling of Prefixdelegation hints
Darren Ankney
darren.ankney at gmail.com
Mon Aug 12 09:35:12 UTC 2024
> 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.
This statement leads me to believe that the issue here might be lease
affinity which is on by default. It defaults to 3600 seconds and
might prevent allocation to a client sending a hint. I've not
experimented, so I'm unsure. See here:
https://kea.readthedocs.io/en/kea-2.6.1/arm/lease-expiration.html#
You can turn it off by setting:
"expired-leases-processing": {
"hold-reclaimed-time": 0,
},
By default, the lease will be held for the client beyond the end of
the lease for 3600 seconds and only used if there is no free lease
available (when your third client appears). The only thing I am
unsure of is if this also applies to prefix delegation. But it is easy
enough to test.
Thank you,
Darren Ankney
On Sun, Aug 11, 2024 at 5:22 PM Ede Wolf <listac at nebelschwaden.de> wrote:
>
> 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
>
> --
> 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
More information about the Kea-users
mailing list