Subject: NTP and the MBone

From: [email-masked] (W. Richard Stevens)
Date: Thu, 19 Jun 1997 11:39:05 -0700

(I posted this to comp.protocols.time.ntp, but also want to see what
the MBone experts have to say.)

I run NTP on my subnet with one "master" server synchronizing with some
"outside" peers, and then redistributing the time using multicasting.
All multicast-capable hosts just have trivial configuration file:
 
        multicastclient 224.0.1.1
        driftfile /etc/ntp.drift
 
Those hosts that are not multicast-capable just have a "server" line
specifying my "master" server.  This works fine.
 
When I bring up my MBone connection (I get charged by usage on my
frame relay Internet connection, so I only turn on mrouted when
necessary) I notice the multicast clients have about a dozen hosts
that they are receiving multicasts from, some from Europe.  Watching
the network with tcpdump shows lots of NTP traffic to these sites,
even after I bring my MBone link down.  About an hour after the
link is down I see the reachability go to 0 but there is still NTP
traffic to these sites.
 
I notice that when my "master" multicasts on the local subnet, the TTL
is 1, as I would expect, so I would guess these other sites have set
the TTL way up in their configuration file.
 
My feeling is that no site should be sending NTP *multicasts* outside
their "site" ("link-local", "site-local", or "organization-local"
should be the limits for the scope, in IPv6 multicasting-speak, but
never "global").  Is this reasonable?  Or should stratum 1 servers
multicast to the world?  (I notice only one of these sites is a
stratum 1 server in the list that's going across the MBone today.)
 
I would guess the only way around this is to add some "restrict" lines
to my multicast client's configuration files, to ignore anyone not on
the local subnet?  Or should NTP default to only accept multicasts
from hosts on the local net?
 
        Rich Stevens

---

From: Piete Brooks <[email-masked]>
Date: Thu, 19 Jun 1997 20:16:08 +0100

>         multicastclient 224.0.1.1

If you want local multicast, don't use this address.
Use an administratively scoped one.

> When I bring up my MBone connection I notice the multicast clients have about
> a dozen hosts that they are receiving multicasts from, some from Europe.

yes -- NTP thrives on diversity !

> Watching the network with tcpdump shows lots of NTP traffic to these sites,
> even after I bring my MBone link down.

When a M/C server is first seen, a client peers with it using std unicast,
so as to get an approximation to RTT/2.
This is wrong (unicast and multicast may well sue different routes), but the
best we could easily manage with the existing code ...

Maybe it's been tweaked (the above was done many years ago -- I've not been
following things since then) to fall back to unicast if things go wrong ...

> is 1, as I would expect,

for local use only, yes ...

> so I would guess these other sites have set the TTL way up in their
> configuration file.

Yup.
 
> never "global").  Is this reasonable?

No -- the idea was that S1s should multicast to anyone interested in listening

> Or should stratum 1 servers multicast to the world? 

That was the idea ...
(but note that the stratum of a clock is not static property -- it may change)

> (I notice only one of these sites is a stratum 1 server in the list that's
> going across the MBone today.)

RATS -- I appears to have lost my S0, so have dropped to S2 :-(

yes, they should be S1, maybe S2, but S3 and above really should not M?C with
a high TTL ...
 
> the local subnet?

No -- if you don't want the global multicast time, don't use 224.0.1.1
You an administratively scoped address.

[ or even just use broadcast ? ]

> Or should NTP default to only accept multicasts from hosts on the local net?

No.

---

From: John Hawkinson <[email-masked]>
Date: Fri, 20 Jun 1997 04:11:31 -0400 (EDT)

> yes -- NTP thrives on diversity !

Yeah, but it would be good if the diversity were accurate.

> You an administratively scoped address.

I do not think this is a good idea.

A goal here is to *not* have to configure every client with a special
address. One should not have to configure one's NTP clients with the
NTP multicast group when a well-known group is defined. I suppose
one could argue that DHCP should be used for setting NTP group addresses
instead of using a well-known address, but this seems inconsistent with
the model of well-known addressing.

> [ or even just use broadcast ? ]

No. That causes other devices on the same L2 medium to receive the
frames, even if they don't speak NTP, or don't even speak IP. That's
part of what link-local multicast is supposed to be saving us from.

> > Or should NTP default to only accept multicasts from hosts on the

This is a security issue, so it deserves more than a trivial
answer, I'm afraid.

The question of defaults is always a tricky one.

--jhawk