[ntpwg] Network Time Protocol (NTP) Options for DHCPv6

[Benoit Lourdelet (blourdel)]

Hello,

A possible usage of all the NTP parameters specified in the new options
is to configure router gateway . In that scenario, the goal of a Service
Provider or an Enterprise IT  is to autoconfigure the gateway as much as
possible, including some NTP client behavior, in order to keep the
control. An additional benefit is that the gateway can be shipped to
remote sites virtually without any configuration while keeping full
control of the NTP behavior.

Following that line of thought, I may still see a need for  "minpoll,
maxpoll, I and B fields".

Considering a central DHCP server, the use of remote-id [RFC4649] or
just link-id may tell the server from where 
the request is coming then giving it the knowledge of the delay to
apply.
In the case of a DHCP server hosted by the first hop, the DHCP server is
well positioned to know the delay.

Considering the current option format which includes more than IP
addresses, the choice of multiple occurrences of the 
 same option looks sensible. Should we reduce the new options to IPv6
addresses only, a list makes more sense.


Benoit

-----Original Message-----
From: Brian Utterback [mailto:brian.utterback at sun.com] 
Sent: Thursday, November 08, 2007 6:32 PM
To: Benoit Lourdelet (blourdel)
Cc: ntpwg at lists.ntp.org; dhcwg at ietf.org; Richard Gayraud (rgayraud)
Subject: Re: [ntpwg] Network Time Protocol (NTP) Options for DHCPv6

I think that you should eliminate the minpoll, maxpoll, I and B fields,
which would mean you could eliminate the reserved field, although you
might want to keep it.

As a policy request, maxpoll is useless. How can you specify the maximum
poll interval? That just doesn't make sense.

The minpoll parameter make some sense, but since you are depending on
the client implementation to obey it, it seems likely that any such
implementation will either get minpoll right or not. If it gets it
right, then the minpoll parameter is not needed, and if it gets it wrong
then it probably won't be obeyed anyway.

I just don't see the point in having the I field since that is pretty
much a client side kind of issue. The use of the B field might be useful
in some weird circumstances, but I don't see this as something that the
server could know.

The multicast looks okay as is, although I would suggest that there be
advice to leave delay as 0 if possible. The proper delay doesn't seem to
me to be likely to be known by the server and possibly different across
a subnet.

I am not sure about the idea of allowing multiple instances. Is that
normal for DHCP? I understand the need to have multiple addresses
returned, I would have thought a single list would have made more sense,
but that is a DHCP thing, not a NTP thing, so I leave that to the DHCP
experts.

Benoit Lourdelet (blourdel) wrote:
> Hello,
> 
> We have just submitted a new draft proposing an NTP option for DHCPv6.

> 
> The goal of this draft is to standardize automatic configuration of
> NTPv4 (IPv6) clients over DHCPv6.
> We think there is currently no satisfactory solution for configuring
> NTPv4 clients from a centralized DHCPv6 server.
> 
> We'd be very happy to hear feedback about the draft, and I'm planning 
> to ask that it becomes a WG draft eventually.
> 
> Here's a url:
> 
>  
> http://www.ietf.org/internet-drafts/draft-gayraud-dhcpv6-ntp-opt-00.tx
> t
> 
> 
> Thanks,
> 
> Richard and Benoit
> _______________________________________________
> ntpwg mailing list
> ntpwg at lists.ntp.org
> https://lists.ntp.org/mailman/listinfo/ntpwg

--
blu

"You've added a new disk. Do you want to replace your current drive,
protect your data from a drive failure or expand your storage capacity?"
- Disk management as it should be.
----------------------------------------------------------------------
Brian Utterback - Solaris RPE, Sun Microsystems, Inc.
Ph:877-259-7345, Em:brian.utterback-at-ess-you-enn-dot-kom