[ntpwg] [dhcwg] Network Time Protocol (NTP) OptionsforDHCPv6

[Richard Gayraud (rgayraud)]

Hello All,

Thank you very much for all your comments about our draft. 
Benoit and I did not expect such a passionate discussion when we 
submitted it 3 weeks ago.

With this email, I would like to summarize the current 
situation, objections, issues, and possible solutions. We will 
try to take into account as much as possible of the remarks and 
questions. The possibility of an increased risk of catastrophic 
event will be considered very carefully and will be mitigated.

First of all, I would like to expose again the motivation for 
this work (I believe there was some confusion about the 
rationale for it):

System administrators like to configure a large number of hosts 
from a centralized DHCP server. Today, DHCP is a protocol of 
choice for remote configuration of IP hosts. DHCPv6 is lacking 
the ability to configure NTP clients. This is our main 
motivation. So, this work is not intended to address some 
hypothetical NTP requirement to improve its peer discovery 
mechanisms. Instead, this work is intended to address a DHCPv6 
need to include NTP configuration. In other words, we are 
working in the context of DHCPv6, to make it more comprehensive. 
One may argue that some other protocol than DHCP might be more 
suitable for this, but our precise purpose is to extend DHCPv6 
expressiveness.

This is not a replacement for existing NTP configuration 
mechanisms. This will simplify the work of system administrators 
(or ISPs) by allowing global, remote configuration of NTP 
clients, instead of individual, per-host configuration of the 
ntpd.conf file. 

We try to be implementation agnostic. As someone mentioned, 
the parameters we selected exist in the reference implementation,
but they are also clearly defined as part of the NTPv4 
specification. The relevance of these parameters in DHCP 
will be discussed. Some of will be removed, some will be added 
(I encourage people in the NTP WG to propose some other useful 
parameters). All depends on the level of expressiveness we want 
to give to DHCP regarding NTP. In any case, all parameters will 
be optional (in the same way they are in ntpd.conf). Only the 
server identity will be required (IP address or FQDN depending 
on the outcome of the discussion about this).

That being said, I tried to collect all the issues you raised in 
a sort of 'dashboard' that I will update.
	

Issue #1: DHCPv6 NTP option may trigger some catastrophic event
---------------------------------------------------------------

This is similar to what happened in the past with hardcoded NTP 
servers IP addresses in SOHO routers. We can imagine that a 
badly designed SOHO equipment with an embedded DHCP server would 
advertise a hardcoded address over the SOHO LAN. There has been 
no consensus yet about the validity of this scenario:

- Some people think adding the possibility to carry an FQDN 
  instead of an IP address will solve this,

- Others think FQDN will not solve the issue but move it to the 
  DNS system, (though it might reduce the amplitude of the issue 
  due to the distributed nature of DNS),

- Others think this is a non-issue as DHCP servers in SOHO 
  equipments only redistribute information they got from their 
  client side. Bigger DHCP servers are manually configured. 
  
  The same problem would happen to DNS servers if SOHO equipments 
  would contain hardcoded DNS servers addresses. But in the case 
  of DNS, DHCP have contributed to avoid the issue rather than 
  amplifying it (please refer to the 2 messages Mark Andrews sent
  on sunday and monday for details).

Unless we all agree with Mark Andrews that this is a non-issue, 
we need to fully understand the exact use case involved if this 
problem can happen, and provide a way to avoid it. Next week 
discussions might be a good opportunity to clarify this.

=> Possible solutions include:

 - use of FQDN,

 - add clear statement an NTP server IP address MUST NOT be 
   hardcoded in a DHCP servers, unless it points to an equipments 
   operated by the vendor. describe the risk in the document 
   itself

 - mandatory use of FQDN ?

 - aren't KOD packets part of the solution ? (This draft only 
   addresses NTPv4 clients with IPv6 connectivity). Maybe we 
   can enforce support for KOD for clients supporting DHCP NTP 
   configuration.


Issue #2: Use of FQDN should be allowed for DNS indirection
-----------------------------------------------------------

Regardless the outcome of Issue #1, there seems to be some 
interest in the community to carry either an IP address or an 
FQDN (ntpd.conf also offers FQDN as a way to specify server 
identity).

We could re-define the option syntax to use sub-options. FQDN 
and Server address being 2 possible sub-options. Other 
parameters (if suitable) could also be defined as sub-options.


Issue #3: Irrelevant parameters (maxpoll/minpoll/burst/iburst)
--------------------------------------------------------------

When writing the first version of this draft, one of our goals 
was to allow better control of the tradeoff between NTP clock 
precision and traffic generated over a LAN. IPv6 has a large 
address space, and an IPv6 subnet can contain a huge number of 
hosts. Thus, it may be suitable to reduce the amount of traffic 
generated by NTP clients. On the other hand, some deployments 
may require fast and precise clock synchronization. Hence the 
Maxpoll, Minpoll, Burst and IBurst parameters. Again, these are 
not mandatory and will rarely be used.

- some people says you have to be an expert to set these 
  parameters and these should not be opened.

=> I do not understand why theworkstation users (controlling 
   their individual ntpd.conf file) would be more skilled to 
   set these parameters than network administrators (controlling
   the DHCP server)? 

If some parameter is questionable in a DHCP option, I think it 
is also questionable as an ntpd.conf option. Isn't it?

I do remember examples of customers requesting that their NTP 
clients quickly sync (and acquire time) on startup. If the network 
administrator wants NTP this kind of behavior, he will set the 
Burst flag to reach fast NTP convergence. Anything I missed here?


Issue #4: "maxpoll is useless"
------------------------------

Even people who like additional parameters, agree to say that 
maxpoll is useless (Brian, Dave). Could you explain why this is 
useless?.


Issue #5: "delay is useless"
----------------------------

The delay field serves as a trigger to enable/disable the 
client volley in multicast mode. Again, I don't understand why 
this is useless. The goal of this parameter is not to have the 
DHCP server to measure the network delay. It is simply to allow 
the network administrator to manually configure a constant delay 
to compensate for having no volley (please refer to  
http://www.cis.udel.edu/~mills/ntp/html/confopt.html where the
'broadcastdelay' option has a similar purpose). I believe the 
default 4ms might not be suitable for all network topologies.


Issue #6: "multiple instances versus list of addresses"
-------------------------------------------------------

The use of multiple instances of the same DHCP option to 
advertise several NTP servers seems to be somewhat confusing. 
Depending on the decision made for other issues, we will 
probably change the syntax of the options (or sub-options if 
any).

Having a list of "struct" or "records" is not usual in DHCP and 
it is not guaranteed that implementations will support it. This 
is why we opted for the simpler "multiple instances option" as 
we have some per-server configuration parameters (Key-ID, issue 
#7, might become another one). Any suggestion for a better 
syntax allowing a list of "struct" to be carried over DHCPv6 is 
welcome.

The sub-option syntax would enable easier future evolutions, but 
it seems difficult to use it to attach per-server parameters like
Burst or Key-ID (unless we consider the order of sub-options to 
be relevant, which is a bit weird, isn't it?).


Issue #7: Key ID
----------------

Some people suggest it might be useful to carry a Key ID with 
each server name/address. There is no opposition to this I 
believe.

	
Issue #8: Carrying an URL for a config file
-------------------------------------------

This has been suggested a few times, but has 2 major drawbacks:

 - It requires the client to be ftp/tftp/http-enabled (a lot 
   of complexity on the client),
   
 - It would be implementation dependant,

If sub-options are used in the DHCP message, we will certainly 
have the same level of flexibility. 

----

Please tell me if I made any mistakes, I would like to converge 
on a comprehensive list of issues.

Thanks you very much,

Richard.