I have feedback that is generic to both autoconfiguration approaches to distributing NTP configuration information -- RA as well as DHCPv6. Regardless of means, I'm suspicious of standardizing a way to distribute multicast NTP server addresses without also standardizing distribution of NTP symmetric authentication parameters needed to secure broadcast/multicast NTP. If providing such authentication parameters (key number/id, digest algorithm, and shared secret) is deemed too cumbersome, I suggest removing support for distributing multicast NTP server information is preferable to providing means which enable only ill-advised configurations that blindly accept unauthenticated multicast NTP service.
Similarly, I would prefer to see broader support for other NTP configurations. If NTP symmetric authentication parameters are provided for, NTP's manycast mode should be configurable as well. Clients solicit manycast servers via authenticated multicast NTP mode 3 (client) requests destined to a multicast group address. Manycast servers respond via unicast mode 4 (server) responses, which triggers manycast clients to spin authenticated unicast associations. The prime advantage over multicast service is the unicast operation with discovered servers, which allows ongoing round-trip delay measurement as compared to one-time multicast delay calibration at ntpd startup. In short, manycast operation provides the automatic server discovery benefit of multicast NTP without the degraded quality of time service inherent in a one-to-many multicast/broadcast NTP configuration. Cheers, Dave Hart -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
