[Kea-users] dhcp6 and ntp-server, version 3.0.3
Darren Ankney
darren.ankney at gmail.com
Sat May 2 20:32:08 UTC 2026
Hi Charly,
I have done some testing. You can specify additional sub options of
different types (as you observed). These are attached to the packet
as additional option 56 (instead of a single option 56 with several
sub-options). You cannot specify additional options of the same type.
Well, technically you can, but the first one is the only one that is
attached.
The RFC (https://datatracker.ietf.org/doc/html/rfc5908#section-4) itself says:
- This option can appear multiple times in a DHCPv6 message.
- This option MUST include one, and only one, time source sub option.
This is ambiguous as on the very next page, the format shows:
The format of the NTP Server Option is:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_NTP_SERVER | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-1 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-2 |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| suboption-n |
: :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
implying that the option carry multiple sub options where the text
just said it MUST contain only one.
> If you have different sub-options, you must use another option-56 for them.
I do not think this is correct. I have no idea why it was done this
way, but it seems (to me) that the authors preferred one or more
options each with exactly one sub option (though that is made
ambiguous by the format shown above).
The RFC then goes on to describe each time source sub option type.
I do not see anything here that would prevent multiple option 56
instances with multiple types of sub options or the same type of sub
options. In fact, this part in section 5:
- The client uses its usual algorithms to determine which server(s) or
multicast group(s) should be preferred to synchronize its clock.
Heavily implies that you can have one or more option 56 each including
only one sub option but nothing stopping the same type appearing more
than once (or multiple types) and the client will decide which one(s)
to use.
In other words, the RFC does not (to me) seem to forbid three of each
(as long as there is only one sub-option per option 56 instance) as
shown:
option[56].option[1] = 2001:db8::1
option[56].option[1] = 2001:db8::2
option[56].option[1] = 2001:db8::3
option[56].option[2] = ff05::101
option[56].option[2] = ff0e::101
option[56].option[2] = ff0e::102
option[56].option[3] = ntp1.example.org
option[56].option[3] = ntp2.example.org
option[56].option[3] = ntp3.example.org
Here is the issue where this support was added:
https://gitlab.isc.org/isc-projects/kea/-/issues/3390 where it looks
like Francis had the same confusion I just did when reading the RFC.
I don't see any relevant discussion in the merge request, however.
Suggest you open an issue about this here:
https://gitlab.isc.org/isc-projects/kea/-/issues
Attaching example configuration and packet capture from my testing.
Thank you,
Darren Ankney
On Fri, May 1, 2026 at 3:15 PM Karl Gaissmaier
<karl.gaissmaier at uni-ulm.de> wrote:
>
> Hi Darren,
>
> thanks for the discussion!
>
> Am 01.05.26 um 11:33 schrieb Darren Ankney:
> > Hi again Charly,
> >
> > Just looked at the title more closely and saw that you were asking
> > about dhcp6. Same two files may be of interest (different directory):
> >
> > - https://gitlab.isc.org/isc-projects/kea/-/blob/master/doc/examples/kea6/all-keys.json
> > - https://gitlab.isc.org/isc-projects/kea/-/blob/master/doc/examples/kea6/all-options.json
>
> sure, I've already read this information and grep-ed the Git repository,
> but I can't find any
> examples of how to use option-56 to assign IPv6 addresses to NTP servers.
>
> Nevertheless, I am able to deliver **one** IPv6 address for NTP servers,
> but only one,
> and the question was whether anyone has managed to assign **more than
> one** IPv6 address
> for NTP servers and what the configuration should look like.
>
> And that it would be extremely helpful if this were included in the
> documents you linked to.
>
> My testing config snippet is:
>
> > "option-data": [
> > {
> > "name": "ntp-server",
> > "code": 56
> > // encapsulates v6-ntp-server-suboptions
> > },
> > {
> > "name": "ntp-server-address",
> > "space": "v6-ntp-server-suboptions",
> > "data": "2001:db8::1"
> > }
> > ],
>
>
> I think there’s a misunderstanding of the RFC here. It should be clear
> that there **must** be a way
> to provide the client with more than one IPv6 address for NTP servers.
>
> However, within option-56, you can only use one **type** of sub-option,
> but you can use that selected type **multiple** times.
>
> If you have different sub-options, you must use another option-56 for them.
>
> In any case, I can’t seem to deliver more than one IPv6 NTP server
> address with ISC-KEA to the client.
> I think this is a bug in KEA or a misunderstanding in the interpretation
> of the RFC, which is really quite ambiguous in this section.
>
> Best regards
> Charly
> --
> 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 at lists.isc.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kea-dhcp6.json
Type: application/json
Size: 1367 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260502/02ab6eee/attachment.json>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: dhcp6-ntp.pcap
Type: application/octet-stream
Size: 792 bytes
Desc: not available
URL: <https://lists.isc.org/pipermail/kea-users/attachments/20260502/02ab6eee/attachment.obj>
More information about the Kea-users
mailing list