There are many ways clients can receive time-server information. It depends on your local architecture and requirements. NTP server authentication is a key part of this process because time data should come from a reliable, trusted source. The exception is a client-server model where the server is unknown to the client from the start of the conversation.
Here are the main NTP architecture models:
Client-server: This is the typical mode used for NTP deployments, and the one described in this workshop. The client or server is configured to communicate with a specific set of NTP time servers.
Broadcast: The NTP server broadcasts its presence to local networks, and the clients respond through a packet exchange to determine round-trip time and delay. Broadcast mode can be used to synchronize large numbers of hosts on an IP address block.
Manycast: The clients send an NTP broadcast to a destination network. Once an NTP server responds to the client broadcast, the client will continue to use that specific NTP server. This is useful when hosts are mobile and don't know the address of the current NTP server. Manycast is only available in NTP 4, which is not yet a formal IETF RFC.
Multicast: NTP clients and servers are configured to use the multicast group address (224.0.1.1) for sending and receiving NTP messages. Make sure your intervening routers support multicast as well. This model is for environments with mobile devices and destination networks that support multicast.