[Kea-users] dhcp6 and ntp-server, version 3.0.3

[Darren Ankney]

It looks like I missed this sentence:

> Instead, it contains one or several suboptions that carry NTP server or SNTP server location.

which makes the RFC even more ambiguous than I thought.  I see from
the discussion that Ted Lemon thinks this means that some future (as
yet undefined) sub options that are not time source sub options could
be included.  This seems overly complicated.  From the original
mailing list mails when the document was proceeding through the ietf,
it doesn't look like there was much drama at all.  It was being driven
by people from the ntpwg rather than the dhcwg
("draft-ietf-ntp-dhcpv6-ntp-opt-02.txt").  I'm not sure that the Kea
engineering team can fix this in any meaningful way.  The clients on
the receiving end of the option would have to support whatever is
done, so Kea cannot simply do whatever it wants to do.

Thank you,
Darren Ankney

On Sun, May 3, 2026 at 5:53 AM Karl Gaissmaier
<karl.gaissmaier at uni-ulm.de> wrote:
>
> Hi Darren,
>
> thank you again for taking the time to help me with my problem!
>
> We’re obviously not the only ones tearing our hair out over RFC 5908, see:
>
> https://mailarchive.ietf.org/arch/browse/ntp/?gbt=1&index=Nk0SHEoJ3Ac847FkhHEPTutjAhg
>
> As always, it's a big problem when an RFC isn't absolutely unambiguous.
>
> I’ll test other implementations - both servers and clients - and then
> open an issue with my new findings.
>
> In any case, it’s clear to me that there *must* be a simple way to
> announce *more than one*
> IPv6 NTP server address to the clients.
>
> 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