Public servers?
Arne 'Timwi' Heizmann
Hi,
I've checked out the lists at
http://www.eecis.udel.edu/~mills/ntp/clock1a.html
and
http://www.eecis.udel.edu/~mills/ntp/clock2a.html
and none of the servers seem to be responding.
Granted, I haven't gone through the lists and tested them all, but ...
Is there an up-to-date list of functioning time servers?
Also, as I understand it, NTP uses TCP and Port 123. Are both of these
assumptions correct? If not, what is correct?
Thank you,
Timwi
James Griffin
>
> Hi,
>
[snip]
>
> Also, as I understand it, NTP uses TCP and Port 123. Are both of these
> assumptions correct? If not, what is correct?
NTP uses UDP and port 123. If you have a firewall that is blocking
123:udp that may explain why no servers answered.
Jim
>
> Thank you,
> Timwi
>
Tapio Sokura
> and none of the servers seem to be responding.
> Granted, I haven't gone through the lists and tested them all, but ...
Most (over 50%) of the servers listed on the pages you mentined do work,
but not all. The server list is not (officially) monitored for
unresponsive servers, instead it relies on server keepers to update
the information themselves via email.
I also guess that a part of the servers that seem unresponsive and are
listed on those pages use some sort of access control that defaults to
not serving unknown clients.
> Is there an up-to-date list of functioning time servers?
I'm not aware of one that has servers listed from around the world.
One thing you could try is the pool.ntp.org project, see
http://www.pool.ntp.org/
> Also, as I understand it, NTP uses TCP and Port 123. Are both of these
> assumptions correct? If not, what is correct?
You're 50% right, NTP uses UDP and port 123. Make sure your firewall (if you
have one) allows outgoing requests to UDP port 123 and also lets the replies
pass.
David L. Mills
You say evil. NTP does not use TCP in any form whatsoever and an evil
pox on anybody who claims the contrary. As for the lists of public
severs, I put up exactly and prescisely what folks send me, no more no
less. I do not verify or monitor the liveness of any entry. What you get
is what you get.
Dave
Arne 'Timwi' Heizmann
> NTP uses UDP and port 123.
Thank you.
I was under the impression that it used TCP because it used to. At least
I remember having tried telnetting some of the servers on that list, and
they reponded to TCP port 123.
Anyway, thanks,
Timwi
David L. Mills
I don't know what you found behind TCP port 123. There has never at any
time in the last twenty years been a NTP version from here that
responded to TCP. The spec RFC-1305 and all of its predecessors clearly
specify <only> UDP. Some of the public servers are getting 300-500
NTP/UDP packets per second. Can you imagine the gried if those were TCP
based?
Dave
Tim Hogard
:
: Hi,
:
: I've checked out the lists at
: http://www.eecis.udel.edu/~mills/ntp/clock1a.html
: and
: http://www.eecis.udel.edu/~mills/ntp/clock2a.html
:
: and none of the servers seem to be responding.
:
: Granted, I haven't gone through the lists and tested them all, but ...
:
: Is there an up-to-date list of functioning time servers?
http://www.abnormal.com/cgi-bin/findntp
In most cases it produces a list thats up-to-date to the second :-)
In most cases any old upstream router is likly to be good enough.
The findntp script just does a traceroute from my server to yours
and askes each router for the current time via ntp. Find out who
runs the ones on the top of the list and ask them. They should
belong to your ISP and they tend to use NTP to make sure the logs
all have correct time stamps. If the router belongs to your ISP
(or their ISP) and the tech support people don't know, then it
should be ok to use it to keep your PC's time right.
If your have time needs better than trusting some random third
party, you might want to ask a real NTP provider if you can access
their clocks. One provider in Australia was getting hit by so many
requests that they were expecting to pay millions of dollars for
bandwidht had they let it continue. So ask first.
David L. Mills
The public lists contain exactly the information supplied to me, nothing
more nothing less. In the past there has been serious problems when
folks cache old copies of these lists. If you have a reliable source
more suitable to your needs, I would be glad to cease maintaining the
lists. It does take nontrivial effort to do that. However, and this is a
gigantic consideration, does your source respect the access requirements
stated in the public lists?
Dave
Mike Ayers
> Arne,
>
> I don't know what you found behind TCP port 123. There has never at any
> time in the last twenty years been a NTP version from here that
> responded to TCP. The spec RFC-1305 and all of its predecessors clearly
> specify <only> UDP.
From http://www.iana.org/assignments/port-numbers:
<SNIP>
ntp 123/tcp Network Time Protocol
ntp 123/udp Network Time Protocol
# Dave Mills <Mi...@HUEY.UDEL.EDU>
</SNIP>
So any confusion is at least understandable. A scan of the port number
assignments indicates that both TCP and UDP ports are assigned to an
application, whether it needs them or not.
/|/|ike
David L. Mills
You are absolutely correct and the issue came up many years ago. There
is no way to disown a TCP (or UDP) port in the IANA and even older
Numbers Czar RFCs and I'm not sure there should be. In any case, I have
repeatedly, repeatedly and every five years sounded the trumpet that NTP
will never go anywhere near a stateful transport protocol. Once upon a
time some adventurous folks mounted NTP headers on top of OSI ROSE, then
climbed on TP-4 and then scrambled on X.25. I thought that a wonderful
adventure, even if it gave lousy time, but would never admit that in public.
Dave
Piotr Trojanek
>: Is there an up-to-date list of functioning time servers?
here is my attempt to do this:
http://elproma.com.pl/~ntp/ntpdb.php
at now it has all from official NTP stratum 1 and 2 list, which
I could parse by some perl script.
--
Piotr Trojanek
David Malone
>http://elproma.com.pl/~ntp/ntpdb.php
This is quite nice, but I can think of two issues with it:
1) It doesn't account for servers that only allow access after
you contact their maintainer.
2) Over the years several people have produced varients of the
list of NTP servers, many of which are now neglected, out
of date, and list machines that are no longer supposed to be
offering a public NTP service.
Getting around issue 1 is relatively easy if you contact all the people
who ask for notification on the NTP server list. Getting around issue 2
shouldn't be hard if you grab the official list and parse it every time
you generate the web page.
David.
Tim Hogard
: Tim,
:
: The public lists contain exactly the information supplied to me, nothing
: more nothing less. In the past there has been serious problems when
: folks cache old copies of these lists. If you have a reliable source
: more suitable to your needs, I would be glad to cease maintaining the
: lists. It does take nontrivial effort to do that. However, and this is a
: gigantic consideration, does your source respect the access requirements
: stated in the public lists?
David,
I think there is a misunderstanding about the two lists. I see
your list as where to go when you must have a good server, my list
is where I feel people should go when they would like their PC's
to have about the right time.
The "reliable" source is just a guess that a gives person's upstream
provider is already running an NTP network using their routers.
The result is that for 99% of the people out there, the method I
used to find NTP servers will work fine because they just want their
clocks close to a minute or so. They shouldn't be hitting the
stratum 1 or even 2 clocks but they don't have anywhere else to
turn so they overload the clocks on your list.
Your list is very useful to the other 1% who need NTP for things
other than setting the clock on their PC.
My list simply asks the core rotuers between the server that hosts
the script and the IP address of the person that hits it for the
time using ntpdate. The result is a list of nearby routers that
respond to NTP request from outside the network. Since most of
these are major backbone routers, I expect their operators will
look at it as one less packet it has to forward. None of the NTP
servers I will ever list are run soley as a time server (like the
ones on your list).
My script's purpose was to show most people (the ones who don't want
to set their PC's clock by their watch anymore), that there are
near by servers that will work for their needs without overloading
the master clocks.
:
: Dave
: >
David L. Mills
I'm not sure we should be having this discussion. I make no claims
whatsoever about the public lists other than to put up whatever folks
send me without any checking whatsoever. Life is too short. I do insist,
quite radically in fact, that the access conditions be really and truly
respected, having been victim myself of folks who have violated them on
our time servers for 17 years (sic!).
If you have an alternate scheme other than the public lists and
pool.ntp.org, it should be posted on the web at www.ntp.org. The twenty
volunteer servers returned from a DNS query to pool.ntp.org have agreed
to open access and are scattered all over the world.
Your scheme should be useful in other cases, as long as the servers have
agreed to open access. Remember, open access can lead to (and has in
several cases) to over 300 packets per second and in one case (U
Wisconsin) several thousand packets per second. This is why our primary
servers have serious access restrictions and draconion traffic shaping.
I do not in any way want those servers to be accidently discovered
without access restrictions being very visible and respected.
Dave
David L. Mills
If your script has discovered primary and secondary servers appearing in
the public lists without respecting the access controls, you have done
an evil, evil thing. As for our own overloaded primary servers, our ouly
defense is to go enrypted and we have done so with one of our prominent
servers pogo.udel.edu as an experiment. I am recommending that all
servers listed in the public lists do the same.
Dave
Piotr Trojanek
>If your script has discovered primary and secondary servers appearing in
>the public lists without respecting the access controls, you have done
>an evil, evil thing.
Yes, my fault. The reason was that I had experiences with stratum 1/2 list
when trying to find server that I could sync to and finding inactive or
out of sync ones.
Once discovered all data is provided from local database, so no more
overhead is putted on servers. Mayby some kind of more "up to date"
list than official staratum 1/2 would prevent people from such a ideas
like mine? As stated in pool.ntp.org it provides no way to check quality
of server we get in DNS round robin -- ie. if somebody don't want to
sync to Windows machine?
But there really seems to be no way to make everybody happy about
NTP server lists...:(
--
Piotr Trojanek
Tim Hogard
: send me without any checking whatsoever. Life is too short. I do insist,
: quite radically in fact, that the access conditions be really and truly
: respected, having been victim myself of folks who have violated them on
: our time servers for 17 years (sic!).
:
: If you have an alternate scheme other than the public lists and
: pool.ntp.org, it should be posted on the web at www.ntp.org. The twenty
: volunteer servers returned from a DNS query to pool.ntp.org have agreed
: to open access and are scattered all over the world.
: Your scheme should be useful in other cases, as long as the servers have
: agreed to open access. Remember, open access can lead to (and has in
: several cases) to over 300 packets per second and in one case (U
: Wisconsin) several thousand packets per second. This is why our primary
: servers have serious access restrictions and draconion traffic shaping.
: I do not in any way want those servers to be accidently discovered
: without access restrictions being very visible and respected.
I generate a different list for everyone that hits the server. The
only way its going to "discover" a limited access stratum one or
two server is if you run a web browser on that server. All it does
it ask nearby routers for the time using an NTP version 1 packet.
If any of these routers are bothered by 300 packets per second,
they have many other problems.
I will change the wording on the output page a bit.
I am well aware of the problem with the stratum 1/2 servers and them
being overloaded (including the recent issue at csiro).
The problem I'm tring to solve is people hear about NTP, and think
it would be good not to set their clocks again. The go to google and
find your page about NTP servers. They figure they are a little
unimportaint site and set things up to talk to a stratum 1 server wihout
asking. Sometimes they even put the IP address into a device and
then ship a few hundred thousand. Thats what we both want to stop.
You also have the people who figure stratum two is ok but stratum
1 must be better. After reading "In most cases the accuracy of the
NTP secondary (stratum 2) servers is only slightly degraded relative
to the primary servers and, as a group, the secondary servers may
be just as reliable.", they are more likly to use a stratum 1 server.
Degraded time and lower reliabilityto the average person means the
clocks could be minutes slow as opposed to miliseconds off.
I've had that discussion with someone before. In the end I convinced
him that he should find a stratum 3 because the stratum 1 servers
were for radio telescopes and scientist and in general sent more
zero bits to his server than the stratum 3 server would. He was
looking for something to reset his clock every hour and had no
business using a stratum one server. I wrote the script after that
because I got tired of explainging traceroute and ntpdate.
I would like to see your page have some wording along the lines of:
If your tring to sync your pc network so that the time is within a
second or so, please consider looking here for a server with a link
to pool.ntp.org.
I would also think it would be a good idea to put the wording like
"Do no use any of these as default servers in software package or
hardware device without first contacting the server operator and
obtaining permission"
I'm now off to add more words of warning to my script...
David L. Mills
I find your statement "If any of these routers are bothered by 300
packets per second, they have many other problems." absolutely mind
warping. This is normal flux for the NIST and USNO routers and our own
servers. The NIST and USNO folks really have no way to throttle the flux
without getting Congress and the stock brokers mad at them, but we
campus types are much more ugly when it comes to abusing priviledge.
We do have some NTP servers running web browsers as well and in these
cases have a very strict NTP access policy as specified in the public
lists. One of these servers happens to be a TrueTime NTS-200, which as
in all such boxes has an integrated web server. If you wiretap those
servers without handing down the access policy in the public lists, we
must consider you evil.
There are a number of defense mechanisms in ntpd as you may know,
including access controls, kiss-o'-death, call gapping, etc., some of
which are even effective against the boobs who lobby 256-packet bursts
within one second. The number and variety of these gangsters are growing
alarmingly fast.
As the result of the U Wisconsin incident, RFC-2030 is under revision
right now and a draft has been circulated for comment. Your comments
about what should be in the public lists and on the web are well meaning
and we will do something about that.
We have discussed the casual configuration issues many times in the NTP
developers group and come to no comfortable conclusion about scripts
like yours that discover ad hoc NTP servers. Best advice I have is to
not use those things at all and rely on pool.ntp.org to do the right thing.
Let me expand on our pool.ntp.org experience. Right now it requires two
steps. The first is to do a DNS lookup on pool.ntp.org, craft a
configuration file with all 20 servers so revealed and then start up
NTP. After a few minutes NTP has found the best 3 or 4 servers and
continues with them. The next step is to whittle down the configuration
file to just those servers. Works gangbusters. Of course, the steps
could be automated with due incisions in the NTP source code. At the
moment, this is a little messy, since the configuration code is
smothered in weeds. It may even be possible to do these steps with a
script without changing the source code. Volunteers needed.
Dave
Brad Knowles
> I generate a different list for everyone that hits the server. The
> only way its going to "discover" a limited access stratum one or
> two server is if you run a web browser on that server. All it does
> it ask nearby routers for the time using an NTP version 1 packet.
> If any of these routers are bothered by 300 packets per second,
> they have many other problems.
From what I can gather, it appears that you do a traceroute from
your server to the IP address of the web browser, then do an NTP
query to each IP address that appears in the list. Is this correct?
If this is correct, I don't see how this is really helpful. It
assumes that clients should be configured to get their NTP time sync
from a router and not a server that has been explicitly set up for
this task, and the router is likely to be very sub-optimal in this
role.
Moreover, it assumes that clients would be able to get this
information from the servers, since you were able to get a response.
However, since the clients are not likely to be using NTP version 1,
this is not an accurate assumption.
Finally, there is the issue of asymmetric routing -- just because
you take a particular path getting from your server to their IP
address doesn't mean that they would take the same path going out, or
that the NTP query that you sent to a particular external interface
would be accepted by the same device from an internal address.
To get a really useful idea of what time servers should be used
by a particular person, you need to know the network topological
location of the user. This is usually closely related to their
geographical location, but there are places in the world where
geographical next door neighbors may in fact each be closer to
somewhere else on the network that is thousands of miles away, due to
the vagaries of presence at exchanges, international network
connectivity, etc....
You also need to know what time servers are topologically close
to them, what stratum they are, what their jitter is, how much their
clock is offset, etc.... With NAT, tunneling, VPNs, differential
routing between IPv4 and IPv6, and a whole host of other issues, this
"topological distance" issue is actually a very tough problem to
solve.
I tried your tool at <http://www.abnormal.com/cgi-bin/findntp>,
and it gave me the following information:
194.78.0.170 Thu Jul 31 14:30:05 2003 (3)
206.24.147.154 Thu Jul 31 14:30:05 2003 (3)
206.24.146.62 No Time Server
208.172.139.9 No Time Server
208.172.130.103 No Time Server
208.172.129.201 No Time Server
144.232.8.245 No Time Server
144.232.204.9 No Time Server
64.39.2.39 Thu Jul 31 14:30:18 2003 (3)
64.39.2.217 Thu Jul 31 14:30:18 2003 (3)
64.49.222.130 Thu Jul 31 14:30:18 2003 (3)
However, doing a traceroute from my machine to your server, I got
quite a different list of IP address that should have been considered:
% traceroute www.abnormal.com
traceroute to www.abnormal.com (64.49.222.146), 30 hops max, 40 byte packets
1 * * *
2 1.200-200-80.adsl.skynet.be (80.200.200.1) 13.243 ms 83.441 ms 14.849 ms
3 77.255-200-80.adsl.skynet.be (80.200.255.77) 20.396 ms 15.324
ms 14.351 ms
4 ae1-0.intlbnc3.skynet.be (194.78.0.142) 13.242 ms 13.108 ms
ae0-0.intlbnc3.skynet.be (194.78.0.42) 12.964 ms
5 gigabitethernet8-0.hsa2.brussels1.level3.net (212.3.234.21)
15.102 ms 12.437 ms 16.18 ms
6 unknown.level3.net (212.3.239.161) 13.112 ms 14.514 ms 102.35 ms
7 so-3-0-0.mp1.amsterdam1.level3.net (212.187.128.14) 17.123 ms
17.239 ms 16.616 ms
8 gige1-0.core1.amsterdam1.level3.net (213.244.165.13) 17.877 ms
18.346 ms 67.14 ms
9 sl-bb20-ams-1-0.sprintlink.net (213.206.131.45) 20.735 ms
18.077 ms 37.061 ms
10 sl-bb21-bru-14-0.sprintlink.net (213.206.129.46) 85.764 ms
20.952 ms 20.806 ms
11 sl-bb20-bru-15-0.sprintlink.net (80.66.128.41) 30.778 ms 21.757
ms 191.756 ms
12 sl-bb22-lon-13-0.sprintlink.net (213.206.129.41) 25.014 ms
46.221 ms 26.593 ms
13 sl-bb20-lon-12-0.sprintlink.net (213.206.128.52) 24.543 ms
34.189 ms 24.777 ms
14 sl-bb21-lon-15-0.sprintlink.net (213.206.128.38) 24.408 ms
25.508 ms 25.639 ms
15 sl-bb21-tuk-10-0.sprintlink.net (144.232.19.69) 332.334 ms
153.984 ms 326.642 ms
16 sl-bb23-pen-10-3.sprintlink.net (144.232.20.118) 94.485 ms
188.57 ms 94.02 ms
17 sl-bb22-pen-14-0.sprintlink.net (144.232.8.178) 92.233 ms
138.388 ms 232.409 ms
18 sl-bb21-fw-15-0.sprintlink.net (144.232.9.31) 164.889 ms
269.093 ms 137.888 ms
19 sl-gw40-fw-8-0.sprintlink.net (144.232.8.246) 138.824 ms
188.795 ms 212.009 ms
20 sl-racks-2-0.sprintlink.net (144.232.204.10) 198.247 ms 144.478
ms 144.715 ms
21 vl130.core1.sat.rackspace.com (64.39.2.33) 280.645 ms 144.153
ms 145.634 ms
22 vlan907.aggr7.sat.rackspace.com (64.39.2.218) 147.487 ms
143.479 ms 143.166 ms
23 0.abnormal.com (64.49.222.146) 158.925 ms 197.75 ms 149.171 ms
In fact, Skynet (a service of the former PTT Belgacom) uses NTP
servers provided by Belbone.be (a backbone network service that I
believe is provided by a different arm of Belgacom). The official
servers are ntp1.belbone.be and ntp2.belbone.be (Stratum 2), both of
which sync from ntp0.belbone.be (Stratum 1, and not publicly
accessible).
All Belgacom customers of one form or another should be using
these two NTP time servers, either directly or indirectly (if they
set up their own NTP server(s) to slave and redistribute time
information locally), or they are welcome to set up their own NTP
Stratum 1 time servers.
If you check the list of public servers at
<http://www.eecis.udel.edu/~mills/ntp/clock2a.html>, you would note
that the belbone servers are the only public servers listed for
Belgium.
However, you would not necessarily have any way to associate me
with Belgacom or Belgium, unless you looked at the topological
network location and routing maps (e.g., from BGP peering), or maybe
you were able to obtain useful information from WhoIs or maybe
radb.ra.net regarding my IP address, who the network owner is, what
other networks they might also own, etc....
All this aside, for large providers, it might be best to point me
towards an NTP server that is outside of their network, as opposed to
one that is on their network but very far away from me.
The only real way to resolve this issue is to run a tool on the
client side to try to find out this kind of information, or perhaps
to query pool.ntp.org and try to find out which of the returned
servers have good Stratum values, low jitter, and low offset, and
then do a "sort | uniq" of the IP addresses on that list, and then
feed that to NTP. Of course, that list might change next week, so
this is something that should be periodically checked and updated.
My understanding is that client-side tools of this nature are
already under development.
> They figure they are a little
> unimportaint site and set things up to talk to a stratum 1 server wihout
> asking. Sometimes they even put the IP address into a device and
> then ship a few hundred thousand. Thats what we both want to stop.
>
> You also have the people who figure stratum two is ok but stratum
> 1 must be better. After reading "In most cases the accuracy of the
> NTP secondary (stratum 2) servers is only slightly degraded relative
> to the primary servers and, as a group, the secondary servers may
> be just as reliable.", they are more likly to use a stratum 1 server.
> Degraded time and lower reliabilityto the average person means the
> clocks could be minutes slow as opposed to miliseconds off.
Agreed. That is bad. End users should definitely be discouraged
from hitting Stratum 1 time servers, and should probably be
discouraged from hitting Stratum 2 timeservers. They should be
encouraged to contact their provider first, who should be able to
answer these questions.
Organizations setting up their own time servers to redistribute
time information locally should be pointed at the Stratum 2 time
servers, and/or encouraged to set up their own Stratum 1 time server.
However, I don't see how your tool helps us do any of this. I
mean, your tool is interesting, but it seems to me that it is trying
to solve the problem from the wrong end.
> I would like to see your page have some wording along the lines of:
> If your tring to sync your pc network so that the time is within a
> second or so, please consider looking here for a server with a link
> to pool.ntp.org.
Speaking only for myself, I think that would be a good
improvement to the documentation.
> I would also think it would be a good idea to put the wording like
> "Do no use any of these as default servers in software package or
> hardware device without first contacting the server operator and
> obtaining permission"
Also agreed.
--
Brad Knowles, <brad.k...@skynet.be>
"They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety."
-Benjamin Franklin, Historical Review of Pennsylvania.
GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+
!w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++)
tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
David L. Mills
I don't understand what you mean by "if somebody don't want to sync to
Windows machine?" In and of itself, that is not a useful quality
discriminator. The mitigation and grooming algorithms in ntpd are a
wonderful quality discriminator and pool.ntp.org is a completely correct
way to discover a swatch of servers from which ntpd can pick.
The public lists have been around for twenty years in one form or
another. I originally intended the lists for use by campus and workplace
network administrators, as in the early days before PCs. They are still
very useful when designing secondary and tertiary NTP subnets, but less
so for j-random PC users. There is no way to make everybody happy about
the lists and I won't even try.
I don't apologize for the liveness or deadness of the public lists, not
even a little. What you see is exactly what I get and I do not volunteer
to groom the lists in any way. Many times in the past some well meaning
folkster has pointed out absent response from one server or another only
to discover the DNS has changed or the server has been temporarily
disabled. I insist on solid evidence, such as notification from the
designated responsible person or confirmed report the server
organization has filed for bankruptcy. The latter happens a lot.
There are scripts around that swallow the lists and independently verify
the entries. The issue is whether the swallower can effectively convey
the access policy for automatic retrieval. We have discussed this issue
many times in the NTP developers corps and have considered various ways
to codify the access rules, but this gets awkward when it comes to
geographic scope. My advice is don't use the lists for j-random PCs.
Better to pester your ISP.
DO NOT CACHE THOSE LISTS. DO NOT CACHE THOSE LISTS. DO NOT CACHE THOSE
LISTS.
The lists change almost on a daily basis. There has been a lot of evil
in my past experience when some j-random boob caches the lists and I get
flak from folks (like you) who complain the lists are out of date. The
mea culpa middle finger points at multiple target cachers. Once you
parse the lists and verify entries and select candidates, update your
configuration file and lobotomize all memory of past actions. Do NOT, as
some silicon boobs do now, do a DNS lookup for every NTP packet sent.
Dave
Tim Hogard
:
: I find your statement "If any of these routers are bothered by 300
: packets per second, they have many other problems." absolutely mind
: warping.
Let me define a few terms:
1) NTP server - devices like your NTS-200
2) PC User - guy who wants his PC clock to be good enough so
he won't miss his favorite show on TV.
3) ISP router - device that sends packes around the Internet
and may just respond to a NTP packet if you send it one.
4) Hard core time users - You and anyone that has posted in this
group for more than a year. My script isn't for them.
Any "ISP router" that will be overloaded by its downstream users
sending it NTP requests is going to have problems because if they
used pool.ntp.org, that very same router would send thouse NTP
requests out to the network and would send 20 times as many. And
then double it because of the responces. All using a local router
as an NTP clock is doing is moving the traffic away from the core
NTP servers to the routers on the edge of the Ineternet.
Think about my scripts as a way to find nearby routers that are
caching NTP.
: This is normal flux for the NIST and USNO routers and our own
: servers. The NIST and USNO folks really have no way to throttle the flux
: without getting Congress and the stock brokers mad at them, but we
: campus types are much more ugly when it comes to abusing priviledge.
If 99% of the people that are now setting their windows clocks using
their ISP's router, then even NIST and USNO wouldn't have a problem.
: We do have some NTP servers running web browsers as well and in these
: cases have a very strict NTP access policy as specified in the public
: lists. One of these servers happens to be a TrueTime NTS-200, which as
: in all such boxes has an integrated web server. If you wiretap those
: servers without handing down the access policy in the public lists, we
: must consider you evil.
The only way my script will find that is if you access my
script from that box or you publish a BGP route saying
that box is a router.
: There are a number of defense mechanisms in ntpd as you may know,
: including access controls, kiss-o'-death, call gapping, etc., some of
: which are even effective against the boobs who lobby 256-packet bursts
: within one second. The number and variety of these gangsters are growing
: alarmingly fast.
And they will get worse. Which is why it is importaint to get
ISPs to provide time services. Which they are doing anyway
because its easier to tell a cisco router to use NTP than it is
to set its clock.
: As the result of the U Wisconsin incident, RFC-2030 is under revision
: right now and a draft has been circulated for comment. Your comments
: about what should be in the public lists and on the web are well meaning
: and we will do something about that.
NTP was built to solve a complex time problem that simply does not
exist for 99.99+% of the users on the net however because NTP is a
solution to a problem they have, NTP server operators get nailed.
For most time applications, round trip time is meaningless. A
"set the clock" operation is one UDP packet to a nearby router
which sends back the time.
I would propose that a field be set up so say protocol 5 (is that
next consider it VerySimpleNTP), simply sends a packet back with
the current time with the assumption that none of the other issues
need to be considered. That means a VSNTP overhead on a typical
NTP server is a syscal to get the time and one to send it in the
packet. It would also make sense to put in the RFC that any router
that responds to public NTP packets is assumed to give concent for
its use only to thouse users who's packets would normally flow
through that router. With those two things and Cisco IOS, its
faster to send back the current time than it is to forward the
packet.
: We have discussed the casual configuration issues many times in the NTP
: developers group and come to no comfortable conclusion about scripts
: like yours that discover ad hoc NTP servers. Best advice I have is to
: not use those things at all and rely on pool.ntp.org to do the right thing.
People write scripts like mine because they don't know about pool.ntp.org
or it didn't exist when I 1st wrote the script.
: Let me expand on our pool.ntp.org experience. Right now it requires two
: steps. The first is to do a DNS lookup on pool.ntp.org, craft a
: configuration file with all 20 servers so revealed and then start up
: NTP. After a few minutes NTP has found the best 3 or 4 servers and
: continues with them. The next step is to whittle down the configuration
: file to just those servers. Works gangbusters. Of course, the steps
: could be automated with due incisions in the NTP source code. At the
: moment, this is a little messy, since the configuration code is
: smothered in weeds. It may even be possible to do these steps with a
: script without changing the source code. Volunteers needed.
pool.ntp.org is the right way of doing things but I fear that
until the tools are ready, people will keep hitting the overloaded
stratum 1 servers when they don't need to.
For thouse that looked at the script, I have changed the wording
and Brad found bug which I haven't fixed yet.
It still lives here:
web.abnormal.com/cgi-bin/findntp
I do appreciate the feedback.
Harlan Stenn
servers is:
- return the first system it finds
- return additional servers until it finds an S2 server (which it would
*not* return, and at that point it would stop looking for more
servers)
How would that be?
And I've started a topic on this at twiki.ntp.org. I'd appreciate more
people adding to it (perhaps creating a ...Discussion topic underneath
it).
H
Brad Knowles
> Any "ISP router" that will be overloaded by its downstream users
> sending it NTP requests is going to have problems because if they
> used pool.ntp.org, that very same router would send thouse NTP
> requests out to the network and would send 20 times as many.
As a former employee of the largest ISP in Belgium, I don't want
*ANYONE* abusing my routers to provide time information, unless I
have explicitly told them to do so. My routers run NTP as clients,
not servers. If anyone wants time sync information, they can come to
the NTP servers that I have explicitly provided for this function.
Anyone and anything that might possibly encourage them to act
contrary to my policies on this subject should be terminated with
extreme prejudice.
Under no circumstances whatsoever, should any customer be
configured to use a router as an NTP server, unless they have been
explicitly told to do so by the entity/organization that owns that
network device.
> If 99% of the people that are now setting their windows clocks using
> their ISP's router, then even NIST and USNO wouldn't have a problem.
s/router/time service equipment that they are explicitly told to use/
> And they will get worse. Which is why it is importaint to get
> ISPs to provide time services. Which they are doing anyway
> because its easier to tell a cisco router to use NTP than it is
> to set its clock.
Maybe some ISPs choose to use their routers as time servers.
That's fine. Others don't. That's fine, too. But no one, under any
circumstances whatsoever, should be telling their customers what time
server to use without the express permission of the entity that
provides that equipment.
This is the whole problem that we have been fighting all along.
You're just making it worse.
> : Let me expand on our pool.ntp.org experience. Right now it requires two
> : steps. The first is to do a DNS lookup on pool.ntp.org, craft a
> : configuration file with all 20 servers so revealed and then start up
> : NTP. After a few minutes NTP has found the best 3 or 4 servers and
> : continues with them. The next step is to whittle down the configuration
> : file to just those servers. Works gangbusters. Of course, the steps
> : could be automated with due incisions in the NTP source code. At the
> : moment, this is a little messy, since the configuration code is
> : smothered in weeds. It may even be possible to do these steps with a
> : script without changing the source code. Volunteers needed.
>
> pool.ntp.org is the right way of doing things but I fear that
> until the tools are ready, people will keep hitting the overloaded
> stratum 1 servers when they don't need to.
The right tools for this problem are already under development.
If nothing else, I'll have a shell script written and ready to go by
the end of the weekend, even though I haven't started yet.
David L. Mills
Let me introduce you to SNTP (RFC-2030, as amended in process). SNTP,
meet Tim. If I have unfairly accused you, my apologies.
That's an interesting idea to wiretap NTP on the way past a router and
flip back a reply. Very trusting, but most of us would consider that a
middleman attack unless validated by NTPv4 Autokey.
Dave
Tim Hogard wrote:
...
> NTP was built to solve a complex time problem that simply does not
> exist for 99.99+% of the users on the net however because NTP is a
> solution to a problem they have, NTP server operators get nailed.
> For most time applications, round trip time is meaningless. A
> "set the clock" operation is one UDP packet to a nearby router
> which sends back the time.
>
> I would propose that a field be set up so say protocol 5 (is that
> next consider it VerySimpleNTP), simply sends a packet back with
> the current time with the assumption that none of the other issues
> need to be considered. That means a VSNTP overhead on a typical
> NTP server is a syscal to get the time and one to send it in the
> packet. It would also make sense to put in the RFC that any router
> that responds to public NTP packets is assumed to give concent for
> its use only to thouse users who's packets would normally flow
> through that router. With those two things and Cisco IOS, its
> faster to send back the current time than it is to forward the
> packet.
...
David L. Mills
I apologize if my previous messages have not adequately and strongly
emphasized the issue: No cigar unless some way is found to either
guarantee a priori that servers returned by a ad hoc discorvery agent
have volunteered ubiquitous access (pool.ntp.org) or to respect the
rules of engagement prescribed in the public lists. Routine violation of
these rules has led to the premature departure of several servers
operated by national laboratories, which is a damn shame.
If somebody independently discovers one of our heavily restricted
servers and then comes up without knowing about or agreeing to the rules
of engagement in the public lists, I get really ugly, inspirationally
rude and in general creatively revengeful. There are a couple of server
operators in the public lists who are even more inflamable than me.
Please note really very carefully, there are numerous private stratum 1
and 2 servers whose access controls forbid no access outside the
institution at all. We have many servers in that category now protected
by draconian access control lists. You find one of those and you get a
kiss-o'-death packet in reply. It would then seem to require ad hoc
address collectors to properly respond to kiss packets.
Twiki not spoken here. Please keep this discussion on public airwaves
and not in in chat rooms.
Dave
David L. Mills
Hear, hear; glad others see the point, too. I would hope whatever you
come up with that is politically correct, and for that matter anybody
else comes up with, is lit on the web at www.ntp.org.
Dave
Harlan Stenn
First, won't manycast solve this problem?
> I apologize if my previous messages have not adequately and strongly
> emphasized the issue: No cigar unless some way is found to either
> guarantee a priori that servers returned by a ad hoc discorvery agent
> have volunteered ubiquitous access (pool.ntp.org) or to respect the
> rules of engagement prescribed in the public lists. Routine violation of
> these rules has led to the premature departure of several servers
> operated by national laboratories, which is a damn shame.
Help me out here. You are talking about a case where a Large Number of
folks start killing a low-stratum server that folks do not want touched.
I am talking about a mechanism that will, for the most part:
- find a router within a hop or three of the user's gateway
- that is from their ISP
- that is not an S2 or an S1 server
> If somebody independently discovers one of our heavily restricted
> servers and then comes up without knowing about or agreeing to the rules
> of engagement in the public lists, I get really ugly, inspirationally
> rude and in general creatively revengeful. There are a couple of server
> operators in the public lists who are even more inflamable than me.
Sure, but this mechanism won't find those, will it?
> Please note really very carefully, there are numerous private stratum 1
> and 2 servers whose access controls forbid no access outside the
> institution at all. We have many servers in that category now protected
> by draconian access control lists. You find one of those and you get a
> kiss-o'-death packet in reply. It would then seem to require ad hoc
> address collectors to properly respond to kiss packets.
OK, and the mechanism I describe won't find these, will it?
> Twiki not spoken here. Please keep this discussion on public airwaves
> and not in in chat rooms.
The TWiki is not a chat room.
Nobody expects you to do anything there.
The twiki is public. It is a forum where people can go and see answers
and discussions that are archived, easily updated, and easily
searchable, so we don't have to re-hash discussions like this ad nausem.
You want this information easily available and you apparently don't want
to be bothered by this stuff time and time again.
H
--
Harlan Stenn
In my exerience with several other ISPs, when I ask about an NTP server
I have been told "get it from router upstream of your connection".
So we're back to "how does one find the closest stable servers we have
permission to talk to"?
H
David Schwartz
"Harlan Stenn" <st...@whimsy.udel.edu> wrote in message
news:o4ptjqj...@whimsy.udel.edu...
> In my exerience with several other ISPs, when I ask about an NTP server
> I have been told "get it from router upstream of your connection".
> So we're back to "how does one find the closest stable servers we have
> permission to talk to"?
That's the problem. If you obtain permission, odds are at the same time
you'll also be told which servers you should talk to. Server discovery might
be useful to tell you who you should talk to about obtaining permission, but
assuming you are allowed to talk to any server you might find, regardless of
how close it might be to you, sounds like a very bad idea to me.
DS
Brad Knowles
> Hear, hear; glad others see the point, too. I would hope whatever you
> come up with that is politically correct, and for that matter anybody
> else comes up with, is lit on the web at www.ntp.org.
I will certainly do everything I can to make sure any tool I
create "Does The Right Thing", to the degree that I can manage to
make it do so. I will also strongly encourage others to do the same.
David L. Mills
Restraint, restraint, I must breathe slowly.
Yes, verily, the problem is vast numbers of clients ganging up on
servers that have loudly hollered "Do not tread on me!" You have not
addresed squarely the access issue and I must conclude you do not
completelyi understand the depth of these issues.
With due respect, please try very hard to understand the anycast
protocol, which has no way of parsing the public rules of engagement. An
anycast server ipso facto volunteers service to any that asks.
DO NOT FIND A ROUTER THAT HAS NOT VOLUNTEERED EVER EVER EVER. The most
capable of which very much and violently object to deflecting from the
line card and fast path to a NTP server on a dinky CPU. Our campus
routers flame at 2.4 Gb/s. You get off the fast path with them, and our
IT department sends a hit squad.
The Twiki is not public as is the newsgroup. I do not want my flames to
be buried in anything else than an inflammable public forum.
No Twiki. None.
Dave
David L. Mills
If the ISP explicitly suggests a victim router, rejoice. If not, do not
rejoice and do not assume in any case whatsoever that a casual pry of
ISP routers for NTP response would be anything but evil. Please talk to
the CSIRO and U Wisconsin and Ultimeth operator for consensus views.
"how does one find the closest stable servers we have permission to talk
to"? There are only two, repeat and emphasis two, either you boogie with
pool.ntp.org or you MANUALLY parse the public lists and personally read
and respect the access restrictions. There are no other discovery means
acceptable at this time.
Dave
Brad Knowles
> If the ISP explicitly suggests a victim router, rejoice. If not,
> do not rejoice and do not assume in any case whatsoever that a
> casual pry of ISP routers for NTP response would be anything but
> evil. Please talk to the CSIRO and U Wisconsin and Ultimeth
> operator for consensus views.
Harlan is not the criminal here. Harlan doesn't have a tool that
does a traceroute from his server to the IP address of the web
browser, then does an ntpdate command against each of the IP
addresses that show up. Tim Hogard has that tool, and apparently has
had it since 1995. If you want to yell at someone, yell at Tim and
not Harlan.
What Harlan is trying to do is open a wider discussion on the
possibility of NTP protocol enhancements that might allow us to do
local auto-discovery of proper NTP servers, in accordance with the
access and usage policies of the individuals or organizations that
own the devices in question. I think this is a good subject to
discuss.
David L. Mills
Huh? There is no intent whatsoever to demonize Harlan in any way, shape
of form. I am reacting strictly to the content of his message. My
message said nothing about traceroute or who may have tools based on
traceroute. How did you get the impression otherwise?
We have had many prior discussions on the newsgroup about the access
control, service area and automatic configuration in one form or another
and each and every time the discussion has mired in the access controls
and service area issues. Discussion would be vastly more productive if
these issues could be resolve. Upon closure, technical details and
prototol augmentation are essentialy trivial.
You might start with BGP as a point of departure.
Dave
Adrian 'Dagurashibanipal' von Bidder
> The twenty
> volunteer servers returned from a DNS query to pool.ntp.org have agreed
> to open access and are scattered all over the world.
Slight correction: server count is at 78 right now. You only see 15 at any
given time as I want to avoid TCP dns queries, and also because bind has a
compiled-in upper limit on entries before it stops rotating them (32 per
default) - problems with not all DNS servers rotating at all have been
discussed previously and cannot be solved outside of hacking ntp, I
believe.
Also don't forget the per continent/per country subzones of pool.ntp.org.
Just visit http://www.pool.ntp.org (and, David, Harlan & Co.: please
forgive me for being slow with the integrate-it-into-www.ntp.org-project)
cheers
-- vbi
--
no .sig this time
Adrian 'Dagurashibanipal' von Bidder
> I would like to see your page have some wording along the lines of:
> If your tring to sync your pc network so that the time is within a
> second or so, please consider looking here for a server with a link
> to pool.ntp.org.
Just FYI: I definitely think the pool.ntp.org project can take much more
load right now. So you're very welcome to mention it as often as possible
:-)
You're even more welcome, of course, to encourage people with static IPs to
donate their servers. Load right now is as close to zero as makes no
difference - and if people donate new servers fast enough, it'll stay that
way.
cheers
-- vbi
--
random link of the day: http://fortytwo.ch/sienapei/yoolooqu
Brad Knowles
> Slight correction: server count is at 78 right now. You only see 15 at any
> given time as I want to avoid TCP dns queries, and also because bind has a
> compiled-in upper limit on entries before it stops rotating them (32 per
> default) - problems with not all DNS servers rotating at all have been
> discussed previously and cannot be solved outside of hacking ntp, I
> believe.
I think I've got an alternative technique that would allow us to
list all 78 servers within the zone and still have BIND hand out a
limited number of addresses, but without constantly changing the
contents of the zone (based on my experience of doing this sort of
thing at AOL). I'm going to do some private testing and let you know.
Brad Knowles
> You're even more welcome, of course, to encourage people with static IPs to
> donate their servers.
Especially in regions or countries that are under-represented
today. There are no pool.ntp.org servers for Belgium, for example.
And how many are there for Australia?
Adrian 'Dagurashibanipal' von Bidder
> At 10:43 AM +0200 2003/08/02, Adrian 'Dagurashibanipal' von Bidder wrote:
>
>> Slight correction: server count is at 78 right now. You only see 15 at
any
>> given time as I want to avoid TCP dns queries, and also because bind has
a
>> compiled-in upper limit on entries before it stops rotating them (32 per
>> default) - problems with not all DNS servers rotating at all have been
>> discussed previously and cannot be solved outside of hacking ntp, I
>> believe.
>
> I think I've got an alternative technique that would allow us to
> list all 78 servers within the zone and still have BIND hand out a
> limited number of addresses, but without constantly changing the
> contents of the zone (based on my experience of doing this sort of
> thing at AOL). I'm going to do some private testing and let you know.
The difficult bit is that I don't want to require special configuration on
the secondaries. IIRC two of them are not even running bind.
cheers
-- vbi
--
Civilization is the limitless multiplication of unnecessary necessities.
-- Mark Twain
David Woolley
Brad Knowles <brad.k...@skynet.be> wrote:
> s/router/time service equipment that they are explicitly told to use/
Whilst my ISP does volunteer this information (although I would be sure
that their help desk would know this if asked), with most consumer ISP
you will need to get past the scripted help desk (re-install Windows) and
the help desk supervisor (maybe knows how to configure IE to work with
multiple ISPs) and reach someone who has real technical knowledge, before
you will even discover that the service is available.
In this sort of environment you have to consider that the vast majority
of users don't want to think (hence the popularity of "plug and play" as
a marketing slogan). Of those who do think, the majority, especially if
they are using a service for business purposes, will want the best for
themselves with no regard to the consequences to the network as a whole.
It's in this context that any solution must work, not one in which everyone
is knowledgeable and public spirited.
Brad Knowles
> The difficult bit is that I don't want to require special configuration on
> the secondaries. IIRC two of them are not even running bind.
If it works the way I expect it to, it shouldn't require anything
special from the secondaries.
Brad Knowles
> It's in this context that any solution must work, not one in which everyone
> is knowledgeable and public spirited.
Which means what? That anyone should be allowed to abuse any
server they like in any way they like?!?
David Woolley
Brad Knowles <brad.k...@skynet.be> wrote:
> Which means what? That anyone should be allowed to abuse any
> server they like in any way they like?!?
It means that any mechanism to ensure globally efficient use of NTP cannot
rely on users making informed decisions about anything other then monetary,
or possibly, personal time costs.
Consequently, it means that the only way that people will act responsibly
is if the cost to them is proportional to the cost to the network. To achieve
that, you probably have to both reduce the cost of doing the right thing and
increase the cost of doing the wrong thing. For most users, fighting through
an ISP's support system is much more expensive than using the first
stratum 1 server in the public servers list (people will assume that a
stratum two may not be as good quality), or using a program that finds the
nearest NTP capable router.
For a vendor, using USNO, which they can assume will always be there,
is much cheaper than providing advice to their users and leaving the
system unconfigured would make the product less saleable.
Decisions ceased to be made on the basis of anything other than "what's
best for me in the short term" when the internet was commercialised.
Note that you cannot enforce good behaviour in a client, without heavy
use of intellectual property law, as market forces will result in more
successful competing products that are the same but without the restriction.
(This is potentially true of kiss-of-death; there is no benefit to a mass
market commercial vendor in supporting that in their clients, only the
cost of actually finding and removing the code will stop them removing it.)
PS Please do not duplicate postings in email, and if insist on doing so,
please don't post through a mechanism that corrupts the Message-ID, making
it impossible to anticipate the posting's arrival. Actually, the original
Message-ID is an example of users doing things for ease rather than best
operation of the internet. Message-IDs include the host name to define
the scope of uniqueness of the rest of the identity, but yours contains
a non-unique network 10 address, so could clash with other network 10
users. (The best solution I've seen for senders who don't know their
domain name, or don't want to reveal it, is Agent, which makes the "user"
field unique and and uses a domain owned by the vendor to scope that.)
Brad Knowles
> For most users, fighting through
> an ISP's support system is much more expensive than using the first
> stratum 1 server in the public servers list (people will assume that a
> stratum two may not be as good quality), or using a program that finds the
> nearest NTP capable router.
Auto-discovery tools that are not implemented client-side are not
going to reach many users, and therefore will not be usable to most.
> For a vendor, using USNO, which they can assume will always be there,
> is much cheaper than providing advice to their users and leaving the
> system unconfigured would make the product less saleable.
I disagree. The USNO could always decide to set up new Stratum 1
time servers on different (unpublished) IP addresses, then contact
their authorized time service clients (i.e., owners of certain
specified Stratum 2 time servers) and tell them what the new IP
address is. Anyone other than their authorized time service clients
should get a kiss-of-death packet. Once that is done and a suitable
amount of notice time passes, they set up a new server at the old IP
address(es) which is designed to do nothing but issue kiss-of-death
packets.
This would really get people's attention, and vendors who
stupidly abused them in the past would pay the price.
> Decisions ceased to be made on the basis of anything other than "what's
> best for me in the short term" when the internet was commercialised.
Agreed. This is why the old "default accept" policy should be
eliminated, regardless of the type of service we're talking about --
SMTP, DNS, or NTP. We should instead have a "default reject" policy,
which we can then selectively open up to allow certain specific
clients to pass through.
Indeed, I'm also thinking that we should eliminate unicast and
unauthenticated time servers, instead using multicast authenticated
services exclusively.
> Note that you cannot enforce good behaviour in a client, without heavy
> use of intellectual property law, as market forces will result in more
> successful competing products that are the same but without the
> restriction.
True enough. This is why the security you trust must be
implemented in the server. The client can decide how much security
they want to implement, if they're not sure they can trust the server.
> (This is potentially true of kiss-of-death; there is no benefit to a mass
> market commercial vendor in supporting that in their clients, only the
> cost of actually finding and removing the code will stop them removing it.)
Not true. There is an amazingly high cost of maintaining your
own codebase, which is what would be required if they wanted to
remove kiss-of-death. The least painful option for them would be to
actually implement the access control policies as specified by the
owners of the time servers in question, or set up their own time
servers for their customers to use (as Apple has done, and as
Microsoft has apparently done).
> PS Please do not duplicate postings in email,
Fair enough.
> and if insist on doing so,
> please don't post through a mechanism that corrupts the Message-ID, making
> it impossible to anticipate the posting's arrival.
That's probably a side-effect of the news gateway function
provided by mailman. I'm not sure that there's much we can do about
this, but I will check with the developers for mailman to see if they
can suggest any solutions.
> Actually, the original
> Message-ID is an example of users doing things for ease rather than best
> operation of the internet. Message-IDs include the host name to define
> the scope of uniqueness of the rest of the identity, but yours contains
> a non-unique network 10 address, so could clash with other network 10
> users.
Looking at the other message-ids in this thread, I see things
like <mailman.10.1059686...@ntp.org> and
<mailman.16.1059945...@ntp.org>, both of which can be
guaranteed to be unique -- they identify the domain that the message
is passing through, the mailing list in question, the mailing list
management software, and pretty unique strings of numbers on top of
all that.
I don't see anything like what you're suggesting.
David L. Mills
You make good points; however, keep in mind the U Wisconsin debacle. The
Netgear folks were tarred and feathered bigtime, even if my
recommendation they be sued for damages and forced to recall defective
routers has not happened.However, what good came of the exercise was
that Netgear developed a design policy document that is consistent with
best practices proposed in the RFC-2030 update, including respect for
the KoD packet.
See http://www.eecis.udel.edu/~mills/database/rfc/rfc-xxxx.pdf. Keep in
mind this is a proposed RFC, but at the instant has not been submitted
to the RFC Editor. I would very much welcome advice, amendment and
corrections to that document.
Dave
Paul Repacholi
> You make good points; however, keep in mind the U Wisconsin
> debacle. The Netgear folks were tarred and feathered bigtime, even
> if my recommendation they be sued for damages and forced to recall
> defective routers has not happened.However, what good came of the
> exercise was that Netgear developed a design policy document that is
> consistent with best practices proposed in the RFC-2030 update,
> including respect for the KoD packet.
Have you considered adding raw LAN multi-cast address/Protocol types
so you can auto configure NTP services on a LAN?
--
Paul Repacholi 1 Crescent Rd.,
+61 (08) 9257-1001 Kalamunda.
West Australia 6076
comp.os.vms,- The Older, Grumpier Slashdot
Raw, Cooked or Well-done, it's all half baked.
EPIC, The Architecture of the future, always has been, always will be.
David L. Mills
Thanks for the suggestion. Are the automatic configuration options in
the NTP documentation what you have in mind?
Dave