Subject: Re: [dhcwg] Network Time Protocol (NTP) Server Option for DHCPv6, WG item updated

From: Jyrki Soini <[email-masked]>
Date: Mon, 07 Jul 2008 10:07:51 +0300

> Date: Fri, 4 Jul 2008 14:17:06 +0200
> From: "Benoit Lourdelet (blourdel)" <[email-masked]>
> Subject: [dhcwg] Network Time Protocol (NTP) Server Option for DHCPv6
> 	WG	item updated
> To: <[email-masked]>, <[email-masked]>
> Message-ID:
> 	<[email-masked]>
> Content-Type: text/plain;	charset="us-ascii"
> 
>  Hello,
> 
> Based on the comments mentioned in the previous e-mail (in copy), we
> modified the working group item and republished it here as version 1 :
> 
> http://www.ietf.org/internet-drafts/draft-ietf-ntp-dhcpv6-ntp-opt-01.txt
> 

The multicast suboption as specified on the draft only allows any source 
multicast. IMHO source specific multicast (RFC4607) must be supported on 
the option as well. I.e. in addition to the multicast source address the 
sender address needs to be specified as well. I would allocate another 
suboption for that purpose. For instance:

3.?.  NTP Source Specific Multicast Channel Suboption

    This suboption is intended to appear inside the OPTION_NTP_SERVER
    option.  It specifies the IPv6 address of the sender and the IPv6
    address of the multicast group used by NTP on the local network.

    The format of the SSM NTP Multicast Channel Suboption 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |  NTP_SUBOPTION_SSM_MC_CHANNEL |        suboption-len = 32     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                     Sender IPv6 address                       |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      |                                                               |
      |                   Multicast IPv6 address                      |
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        suboption-code: NTP_SUBOPTION_SSM_MC_CHANNEL (?),

        suboption-len: 32.

> Regards
> Benoit

--
Jyrki Soini
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Mon, 7 Jul 2008 11:15:24 +0200

Hello Jyrki,

If you look at the history of this draft, you can see the 
first version contained a lot of additionnal configuration 
parameters, for advanced NTP client configuration.

It has been discussed, and decided, to go for a minimalistic
subset of NTP configuration parameters in this document. 
Various reasons influenced this choice. Please refer to 
the NTP and DHCP mailing lists archives for details. The 
main reason was that such configuration should be done on 
the client side (via config file for instance) rather than
using DHCP.

The option you propose falls into this category. Moreover, it 
looks like it is not supported by current implementations of 
NTP (does not exists in the reference implementation config 
file). This makes me think it is not really required on the 
the NTP side.

Regards,

Richard.

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Jyrki Soini
> Sent: lundi 7 juillet 2008 09:08
> To: [email-masked]; Benoit Lourdelet (blourdel)
> Subject: Re: [dhcwg] Network Time Protocol (NTP) Server 
> Option for DHCPv6, WG item updated
> 
> 
>       |                                                       
>         |
>       |                                                       
>         |
>       |                     Sender IPv6 address               
>         |
>       |                                                       
>         |
>       |                                                       
>         |
>       |                                                       
>         |
>       |                                                       
>         |

---

From: Jyrki Soini <[email-masked]>
Date: Mon, 07 Jul 2008 13:38:27 +0300

> parameters, for advanced NTP client configuration.

I did read the first draft ;-)

> the client side (via config file for instance) rather than

Makes sense. KISS is a good principle.

That reminds me another issues with your draft, namely introducing
sub-options into DHCPv6. DHCPv6 option number space is 16 bit in 
contrast to 8 bits of DHCP. Why not just have different options intead 
of sub-options?

> file). This makes me think it is not really required on the 

I think it is not that much an NTP issue, but multicast usage issue.
Source specific multicast is somewhat simpler and more robust to 
implement on network infrastructure. Please refer mbone and magma 
mailing list archives.

--
Jyrki Soini

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Mon, 7 Jul 2008 13:28:54 +0200

> contrast to 8 bits of DHCP. Why not just have different 

The option versus suboption question is also a long story and the 
result of a consensus. The sub-option syntax leaves a space for
specifying additional parameters for a given server. One instance
of the Option describes one NTP source. Then the content of the
inner sub-options gives information about this source.

> implement on network infrastructure. Please refer mbone and magma 

I tend to agree with you. But I'm not aware of any NTP implementation
using of it (or simply supporting it as a config parameter). Multicast 
in NTP is a "zero-config" tool: simply listening messages on a 
well-known multicat group instead of having to specify a given 
NTP server.
_______________________________________________
dhcwg mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 7 Jul 2008 13:29:29 -0700

> inner sub-options gives information about this source.

The main reason for doing sub-option encapsulations was scarcity of option codes.   This is not a problem in DHCPv6, so if there's any question in your mind as to whether or not to use sub-option encapsulation, don't.   If you want to add additional information later, add it later as a new option.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 07 Jul 2008 17:07:56 -0400

> suboption for that purpose. For instance:

NTP does not support the concept of source specific multicast. See the 
NTPv4 draft: 
http://www.ietf.org/internet-drafts/draft-ietf-ntp-ntpv4-proto-09.txt . 
There is not much point in including an unsupported option. NTP uses 
autokey to validate the multicast servers. Distribution of the autokey 
keys is a much more important option than this.

Danny

---

From: "Richard Gayraud (rgayraud)" <[email-masked]>
Date: Mon, 7 Jul 2008 23:20:16 +0200

Ted,

We choosed sub-options not for scarcity of option codes, but
for their ability to group all the information associated
to a given NTP server inside one option.

Like this:

  NTP server 1, param 1.1, param 1.2, ...
  NTP server 2, param 2.1, param 2.2,

Where each line is an option, and each comma-separated item 
is a sub-option. For now, only server identities are defined
but we can add per-server parameters when required.

Richard.

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: lundi 7 juillet 2008 22:29
To: Richard Gayraud (rgayraud); Jyrki Soini
Cc: [email-masked]
Subject: RE: [dhcwg] Network Time Protocol (NTP) Server Option for
DHCPv6,WG item updated

> inner sub-options gives information about this source.

The main reason for doing sub-option encapsulations was scarcity of
option codes.   This is not a problem in DHCPv6, so if there's any
question in your mind as to whether or not to use sub-option
encapsulation, don't.   If you want to add additional information later,
add it later as a new option.

---

From: Danny Mayer <[email-masked]>
Date: Mon, 07 Jul 2008 22:12:57 -0400

Jyrki Soini wrote:
>> The option you propose falls into this category. Moreover, it looks 
>> like it is not supported by current implementations of NTP (does not 
>> exists in the reference implementation config file). This makes me 
>> think it is not really required on the the NTP side.
>>
> 

Not for NTP. NTP's main concern is that the server can be authenticated. 
not so much where the multicast packet supposedly came from. Source 
addresses are easy to spoof. Having the right keys to get authenticated 
using autokey is much harder to do and is the preferred way of accepting 
multicast packets. There are also different ways that we use multicast 
packets to handle isolated networks for example.

Danny

---

From: Danny Mayer <[email-masked]>
Date: Mon, 07 Jul 2008 22:16:09 -0400

> well-known multicat group instead of having to specify a given 

No, by default NTP requires authentication of the server before 
accepting multicast packets.

Danny