Steve Kostecke <[EMAIL PROTECTED]> writes: > 1. Multicast associations can not compensate for changing network > conditions at each poll.
I'm picturing a second class of home user or small business that would be very happy to have their computers all within a second of the correct time and within milliseconds of each others time. Looking at the usage graphs of the pools, there are only 2-6 million pools users. That probably accounts for most of the ntp users in the world. The current estimates are over 400 million internet-connected computers. It is going to be challenging to pick up all these users using any unicast-based scheme. > 2. Muticast clients must use NTP authentication if they wish to control > which multicast servers they will accept. This requirement impacts > the autonomous configuration aspect of multicast (or manycast, for that > matter). This is the part that might be the easiest. If a few well known stratum 1's (say NIST itself) were to emit signed multicast packets the clients could just pick the servers they trusted. This obviously isn't secure from playback attacks, but would keep misconfigured servers from screwing things up too terribly. (Although the playback attacks could be dealt with by simply discarding any multicast packet from a normally trusted server that was too much older than the time being displayed in packets from other trusted servers.) -wolfgang -- Wolfgang S. Rupprecht http://www.wsrcc.com/wolfgang/ Hints for IPv6 on FC6 http://www.wsrcc.com/wolfgang/fedora/ipv6-tunnel.html _______________________________________________ questions mailing list [email protected] https://lists.ntp.isc.org/mailman/listinfo/questions
