RFC relevance of reference

As per Relevance of the word reference, we have this rfc below:

Network Working Group D.
Request for Comments: 2030 University of
Obsoletes: 1769 October 1996
Category:

Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and

Status of this

This memo provides information for the Internet community. This
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

This memorandum describes the Simple Network Time Protocol (SNTP
Version 4, which is an adaptation of the Network Time Protocol (NTP
used to synchronize computer clocks in the Internet. SNTP can be
when the ultimate performance of the full NTP
described in RFC-1305 is not needed or justified. When operating
current and previous NTP and SNTP versions, SNTP Version 4
no changes to the NTP specification or known implementations,
rather a clarification of certain design features of NTP which
operation in a simple, stateless remote-procedure call (RPC)
with accuracy and reliability expectations similar to the UDP/
protocol described in RFC-868.

The only significant protocol change in SNTP Version 4 over
versions of NTP and SNTP is a modified header interpretation
accommodate Internet Protocol Version 6 (IPv6) [DEE96] and
[COL94] addressing. However, SNTP Version 4 includes certain
extensions to the basic Version 3 model, including an anycast
and an authentication scheme designed specifically for multicast
anycast modes. While the anycast mode extension is described in
document, the authentication scheme extension will be described
another document to be published later. Until such time that
definitive specification is published, these extensions should
considered provisional

This memorandum obsoletes RFC-1769, which describes SNTP Version 3.
Its purpose is to correct certain inconsistencies in the
document and to clarify header formats and protocol operations
current NTP Version 3 (IPv4) and proposed NTP Version 4 (IPv6
OSI), which are also used for SNTP. A working knowledge of the
Version 3 specification RFC-1305 is not required for
implementation of SNTP

Mills Informational [Page 1]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

1.

The Network Time Protocol (NTP) Version 3 specified in RFC-1305
[MIL92] is widely used to synchronize computer clocks in the
Internet. It provides comprehensive mechanisms to access
time and frequency dissemination services, organize the time
synchronization subnet and adjust the local clock in
participating subnet peer. In most places of the Internet of today
NTP provides accuracies of 1-50 ms, depending on the
of the synchronization source and network paths

RFC-1305 specifies the NTP Version 3 protocol machine in terms
events, states, transition functions and actions and, in addition
engineered algorithms to improve the timekeeping quality and
among several synchronization sources, some of which may be faulty
To achieve accuracies in the low milliseconds over paths
major portions of the Internet of today, these intricate algorithms
or their functional equivalents, are necessary. However, in
cases accuracies in the order of significant fractions of a
are acceptable. In such cases, simpler protocols such as the
Protocol [POS83], have been used for this purpose. These
usually involve an RPC exchange where the client requests the time
day and the server returns it in seconds past some known
epoch

NTP is designed for use by clients and servers with a wide range
capabilities and over a wide range of network delays and
characteristics. Most users of the Internet NTP
subnet of today use a software package including the full suite
NTP options and algorithms, which are relatively complex, real-
applications (see http://www.eecis.udel.edu/~ntp). While the
has been ported to a wide variety of hardware platforms ranging
personal computers to supercomputers, its sheer size and
is not appropriate for many applications. Accordingly, it is
to explore alternative access strategies using simpler
appropriate for less stringent accuracy expectations

This document describes the Simple Network Time Protocol (SNTP
Version 4, which is a simplified access strategy for servers
clients using NTP Version 3 as now specified and deployed in
Internet, as well as NTP Version 4 now under development. The
paradigm is identical to the UDP/TIME Protocol and, in fact,
should be easily possible to adapt a UDP/TIME client implementation
say for a personal computer, to operate using SNTP. Moreover, SNTP
also designed to operate in a dedicated server
including an integrated radio clock. With careful design and
of the various latencies in the system, which is practical in
dedicated design, it is possible to deliver time accurate to

Mills Informational [Page 2]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

order of microseconds

SNTP Version 4 is designed to coexist with existing NTP and
Version 3 clients and servers, as well as proposed Version 4
and servers. When operating with current and previous versions of
and SNTP, SNTP Version 4 requires no changes to the protocol
implementations now running or likely to be implemented
for NTP ir SNTP Version 4. To a NTP or SNTP server, NTP and
clients are undistinguishable; to a NTP or SNTP client, NTP and
servers are undistinguishable. Like NTP servers operating in non
symmetric modes, SNTP servers are stateless and can support
numbers of clients; however, unlike most NTP clients, SNTP
normally operate with only a single server. NTP and SNTP Version 3
servers can operate in unicast and multicast modes. In addition,
Version 4 clients and servers can implement extensions to operate
anycast mode

It is strongly recommended that SNTP be used only at the
of the synchronization subnet. SNTP clients should operate only
the leaves (highest stratum) of the subnet and in
where no NTP or SNTP client is dependent on another SNTP client
synchronization. SNTP servers should operate only at the
(stratum 1) of the subnet and then only in configurations where
other source of synchronization other than a reliable radio or
time service is available. The full degree of reliability
expected of primary servers is possible only using the
sources, diverse subnet paths and crafted algorithms of a full
implementation. This extends to the primary source of
itself in the form of multiple radio or modem sources and
paths to other primary servers should all sources fail or
majority deliver incorrect time. Therefore, the use of SNTP
than NTP in primary servers should be carefully considered

An important provision in this document is the reinterpretation
certain NTP Versino 4 header fields which provide for IPv6 and
addressing and optional anycast extensions designed specifically
multicast service. These additions are in conjunction with
proposed NTP Version 4 specification, which will appear as a
document. The only difference between the current NTP Version 3
proposed NTP Version 4 header formats is the interpretation of
four-octet Reference Identifier field, which is used primarily
detect and avoid synchronization loops. In Version 3 and Version 4
primary (stratum-1) servers, this field contains the four-
ASCII reference identifier defined later in this document. In
3 secondary servers and clients, it contains the 32-bit IPv4
of the synchronization source. In Version 4 secondary servers
clients, it contains the low order 32 bits of the last
timestamp received from the synchronization source

Mills Informational [Page 3]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

In the case of OSI, the Connectionless Transport Service (CLTS)
used [ISO86]. Each SNTP packet is transmitted as tht TS-
parameter of a T-UNITDATA Request primitive. Alternately, the
can be encapsulated in a TPDU which itself is transported using
[DOB91]. It is not advised that NTP be operated at the upper
of the OSI stack, such as might be inferred from [FUR94], as
could seriously degrade accuracy. With the header formats defined
this document, it is in principle possible to interwork
servers and clients of one protocol family and another, although
practical difficulties may make this inadvisable

In the following, indented paragraphs such as this one
information not required by the formal protocol specification,
considered good practice in protocol implementations

2. Operating Modes and

SNTP Version 4 can operate in either unicast (point to point),
multicast (point to multipoint) or anycast (multipoint to point
modes. A unicast client sends a request to a designated server at
unicast address and expects a reply from which it can determine
time and, optionally, the roundtrip delay and local clock
relative to the server. A multicast server periodically sends
unsolicited message to a designated IPv4 or IPv6 local
address or multicast group address and ordinarily expects no
from clients. A multicast client listens on this address
ordinarily sends no requests. An anycast client sends a request to
designated IPv4 or IPv6 local broadcast address or multicast
address. One or more anycast servers reply with their
unicast addresses. The client binds to the first one received,
continues operation in unicast mode

Multicast servers should respond to client unicast requests,
well as send unsolicited multicast messages. Multicast clients
send unicast requests in order to determine the
propagation delay between the server and client and then
operation in multicast mode

In unicast mode, the client and server end-system addresses
assigned following the usual IPv4, IPv6 or OSI conventions.
multicast mode, the server uses a designated local broadcast
or multicast group address. An IP local broadcast address has
limited to a single IP subnet, since routers do not propagate
broadcast datagrams. On the other hand, an IP multicast group
has scope extending to potentially the entire Internet. The scoping
routing and group membership procedures are determined
considerations beyond the scope of this document. For IPv4, the
has assigned the multicast group address 224.0.1.1 for NTP, which

Mills Informational [Page 4]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

used both by multicast servers and anycast clients. NTP
addresses for IPv6 and OSI have yet to be determined

Multicast clients listen on the designated local broadcast address
multicast group address. In the case of local broadcast addresses,
further provisions are necessary. In the case of IP
addresses, the multicast client and anycast server must implement
Internet Group Management Protocol (IGMP) [DEE89], in order that
local router joins the multicast group and relays messages to
IPv4 or IPv6 multicast group addresses assigned by the IANA.
than the IP addressing conventions and IGMP, there is no
in server or client operations with either the local
address or multicast group address

It is important to adjust the time-to-live (TTL) field in the
header of multicast messages to a reasonable value, in order
limit the network resources used by this (and any other)
service. Only multicast clients in scope will receive
server messages. Only cooperating anycast servers in scope
reply to a client request. The engineering principles
determine the proper value to be used are beyond the scope of
document

Anycast mode is designed for use with a set of cooperating
whose addresses are not known beforehand by the client. An
client sends a request to the designated local broadcast or
group address as described below. For this purpose, the NTP
group address assigned by the IANA is used. One or more
servers listen on the designated local broadcast address or
group address. Each anycast server, upon receiving a request, sends
unicast reply message to the originating client. The client
binds to the first such message received and continues operation
unicast mode. Subsequent replies from other anycast servers
ignored

In the case of SNTP as specified herein, there is a very
vulnerability that SNTP multicast clients can be disrupted
misbehaving or hostile SNTP or NTP multicast servers elsewhere
the Internet, since at present all such servers use the same IPv
multicast group address assigned by the IANA. Where necessary
access control based on the server source address can be used
select only the designated server known to and trusted by
client. The use of cryptographic authentication scheme defined
RFC-1305 is optional; however, implementors should be advised
extensions to this scheme are planned specifically for
multicast and anycast modes

Mills Informational [Page 5]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

While not integral to the SNTP specification, it is intended
IP broadcast addresses will be used primarily in IP subnets
LAN segments including a fully functional NTP server with a
of dependent SNTP multicast clients on the same subnet, while
multicast group addresses will be used only in cases where the
is engineered specifically for each service domain

In NTP Version 3, the reference identifier was often used
walk-back the synchronization subnet to the root (primary server
for management purposes. In NTP Version 4, this feature is
available, since the addresses are longer than 32 bits. However
the intent in the protocol design was to provide a way to
and avoid loops. A peer could determine that a loop was
by comparing the contents of this field with the IPv4
address in the same packet. A NTP Version 4 server can
the same thing by comparing the contents of this field with
low order 32 bits of the originate timestamp in the same packet
There is a small possibility of false alarm in this scheme,
the false alarm rate can be minimized by randomizing the low
unused bits of the transmit timestamp

3. NTP Timestamp

SNTP uses the standard NTP timestamp format described in RFC-1305
previous versions of that document. In conformance with
Internet practice, NTP data are specified as integer or fixed-
quantities, with bits numbered in big-endian fashion from 0
at the left, or high-order, position. Unless specified otherwise,
quantities are unsigned and may occupy the full field width with
implied 0 preceding bit 0.

Since NTP timestamps are cherished data and, in fact, represent
main product of the protocol, a special timestamp format has
established. NTP timestamps are represented as a 64-bit
fixed-point number, in seconds relative to 0h on 1 January 1900.
integer part is in the first 32 bits and the fraction part in
last 32 bits. In the fraction part, the non-significant low order
be set to 0.

It is advisable to fill the non-significant low order bits of
timestamp with a random, unbiased bitstring, both to
systematic roundoff errors and as a means of loop detection
replay detection (see below). One way of doing this is to
a random bitstring in a 64-bit word, then perform an
right shift a number of bits equal to the number of
bits of the timestamp, then add the result to the
timestamp

Mills Informational [Page 6]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

This format allows convenient multiple-precision arithmetic
conversion to UDP/TIME representation (seconds), but does
the conversion to ICMP Timestamp message representation, which is
milliseconds. The maximum number that can be represented
4,294,967,295 seconds with a precision of about 200 picoseconds
which should be adequate for even the most exotic requirements

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Seconds Fraction (0-padded) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Note that, since some time in 1968 (second 2,147,483,648) the
significant bit (bit 0 of the integer part) has been set and that
64-bit field will overflow some time in 2036 (second 4,294,967,296).
Should NTP or SNTP be in use in 2036, some external means will
necessary to qualify time relative to 1900 and time relative to 2036
(and other multiples of 136 years). There will exist a 200-
interval, henceforth ignored, every 136 years when the 64-bit
will be 0, which by convention is interpreted as an invalid
unavailable timestamp

As the NTP timestamp format has been in use for the last 17 years
it remains a possibility that it will be in use 40 years from
when the seconds field overflows. As it is probably
to archive NTP timestamps before bit 0 was set in 1968,
convenient way to extend the useful life of NTP timestamps is
following convention: If bit 0 is set, the UTC time is in
range 1968-2036 and UTC time is reckoned from 0h 0m 0s UTC on 1
January 1900. If bit 0 is not set, the time is in the range 2036-
2104 and UTC time is reckoned from 6h 28m 16s UTC on 7
2036. Note that when calculating the correspondence, 2000 is not
leap year. Note also that leap seconds are not counted in
reckoning

4. NTP Message

Both NTP and SNTP are clients of the User Datagram Protocol (UDP
[POS80], which itself is a client of the Internet Protocol (IP
[DAR81]. The structure of the IP and UDP headers is described in
cited specification documents and will not be detailed further here
The UDP port number assigned to NTP is 123, which should be used
both the Source Port and Destination Port fields in the UDP header
The remaining UDP header fields should be set as described in
specification

Mills Informational [Page 7]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

Below is a description of the NTP/SNTP Version 4 message format
which follows the IP and UDP headers. This format is identical
that described in RFC-1305, with the exception of the contents of
reference identifier field. The header fields are defined as follows

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|LI | VN |Mode | Stratum | Poll | Precision |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Delay |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Root Dispersion |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reference Identifier |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Reference Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Originate Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Receive Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Transmit Timestamp (64) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Identifier (optional) (32) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
| Message Digest (optional) (128) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

As described in the next section, in SNTP most of these fields
initialized with pre-specified data. For completeness, the
of each field is briefly summarized below

Mills Informational [Page 8]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

Leap Indicator (LI): This is a two-bit code warning of an
leap second to be inserted/deleted in the last minute of the
day, with bit 0 and bit 1, respectively, coded as follows

LI Value
-------------------------------------------------------
00 0 no
01 1 last minute has 61
10 2 last minute has 59 seconds
11 3 alarm condition (clock not synchronized

Version Number (VN): This is a three-bit integer indicating
NTP/SNTP version number. The version number is 3 for Version 3 (IPv
only) and 4 for Version 4 (IPv4, IPv6 and OSI). If necessary
distinguish between IPv4, IPv6 and OSI, the encapsulating
must be inspected

Mode: This is a three-bit integer indicating the mode, with
defined as follows

Mode
------------------------------------
0
1 symmetric
2 symmetric
3
4
5
6 reserved for NTP control
7 reserved for private

In unicast and anycast modes, the client sets this field to 3
(client) in the request and the server sets it to 4 (server) in
reply. In multicast mode, the server sets this field to 5
(broadcast).

Stratum: This is a eight-bit unsigned integer indicating the
level of the local clock, with values defined as follows

Stratum
----------------------------------------------
0 unspecified or
1 primary reference (e.g., radio clock
2-15 secondary reference (via NTP or SNTP
16-255

Mills Informational [Page 9]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

Poll Interval: This is an eight-bit signed integer indicating
maximum interval between successive messages, in seconds to
nearest power of two. The values that can appear in this
presently range from 4 (16 s) to 14 (16284 s); however,
applications use only the sub-range 6 (64 s) to 10 (1024 s).

Precision: This is an eight-bit signed integer indicating
precision of the local clock, in seconds to the nearest power of two
The values that normally appear in this field range from -6
mains-frequency clocks to -20 for microsecond clocks found in
workstations

Root Delay: This is a 32-bit signed fixed-point number indicating
total roundtrip delay to the primary reference source, in
with fraction point between bits 15 and 16. Note that this
can take on both positive and negative values, depending on
relative time and frequency offsets. The values that normally
in this field range from negative values of a few milliseconds
positive values of several hundred milliseconds

Root Dispersion: This is a 32-bit unsigned fixed-point
indicating the nominal error relative to the primary
source, in seconds with fraction point between bits 15 and 16.
values that normally appear in this field range from 0 to
hundred milliseconds

Reference Identifier: This is a 32-bit bitstring identifying
particular reference source. In the case of NTP Version 3 or
4 stratum-0 (unspecified) or stratum-1 (primary) servers, this is
four-character ASCII string, left justified and zero padded to 32
bits. In NTP Version 3 secondary servers, this is the 32-bit IPv
address of the reference source. In NTP Version 4 secondary servers
this is the low order 32 bits of the latest transmit timestamp of
reference source. NTP primary (stratum 1) servers should set
field to a code identifying the external reference source
to the following list. If the external reference is one of
listed, the associated code should be used. Codes for sources
listed can be contrived as appropriate

Mills Informational [Page 10]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

Code External Reference
----------------------------------------------------------------
LOCL uncalibrated local clock used as a primary reference
a subnet without external means of
PPS atomic clock or other pulse-per-second
individually calibrated to national
ACTS NIST dialup modem
USNO USNO modem
PTB PTB (Germany) modem
TDF Allouis (France) Radio 164
DCF Mainflingen (Germany) Radio 77.5
MSF Rugby (UK) Radio 60
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20
WWVB Boulder (US) Radio 60
WWVH Kaui Hawaii (US) Radio 2.5, 5, 10, 15
CHU Ottawa (Canada) Radio 3330, 7335, 14670
LORC LORAN-C radionavigation
OMEG OMEGA radionavigation
GPS Global Positioning
GOES Geostationary Orbit Environment

Reference Timestamp: This is the time at which the local clock
last set or corrected, in 64-bit timestamp format

Originate Timestamp: This is the time at which the request
the client for the server, in 64-bit timestamp format

Receive Timestamp: This is the time at which the request arrived
the server, in 64-bit timestamp format

Transmit Timestamp: This is the time at which the reply departed
server for the client, in 64-bit timestamp format

Authenticator (optional): When the NTP authentication scheme
implemented, the Key Identifier and Message Digest fields contain
message authentication code (MAC) information defined in Appendix
of RFC-1305.

5. SNTP Client

A SNTP client can operate in multicast mode, unicast mode or
mode. In multicast mode, the client sends no request and waits for
broadcast (mode 5) from a designated multicast server. In
mode, the client sends a request (mode 3) to a designated
server and expects a reply (mode 4) from that server. In
mode, the client sends a request (mode 3) to a designated
broadcast or multicast group address and expects a reply (mode 4)
from one or more anycast servers. The client uses the first

Mills Informational [Page 11]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

received to establish the particular server for subsequent
operations. Later replies from this server (duplicates) or any
server are ignored. Other than the selection of address in
request, the operations of anycast and unicast clients are identical
Requests are normally sent at intervals from 64 s to 1024 s
depending on the frequency tolerance of the client clock and
required accuracy

A unicast or anycast client initializes the NTP message header,
the request to the server and strips the time of day from
Transmit Timestamp field of the reply. For this purpose, all of
NTP header fields shown above can be set to 0, except the first
and (optional) Transmit Timestamp fields. In the first octet, the
field is set to 0 (no warning) and the Mode field is set to 3
(client). The VN field must agree with the version number of
NTP/SNTP server; however, Version 4 servers will also accept
versions. Version 3 (RFC-1305) and Version 2 (RFC-1119)
already accept all previous versions, including Version 1 (RFC-1059).
Note that Version 0 (RFC-959) is no longer supported by any
version

Since there will probably continue to be NTP and SNTP servers of
four versions interoperating in the Internet, careful
should be given to the version used by SNTP Version 4 clients. It
recommended that clients use the latest version known to be
by the selected server in the interest of the highest accuracy
reliability. SNTP Version 4 clients can interoperate with
previous version NTP and SNTP servers, since the header fields
by SNTP clients are unchanged. Version 4 servers are required
reply in the same version as the request, so the VN field of
request also specifies the version of the reply

While not necessary in a conforming client implementation, in
and anycast modes it highly recommended that the transmit
in the request is set to the time of day according to the
clock in NTP timestamp format. This allows a simple calculation
determine the propagation delay between the server and client and
align the local clock generally within a few tens of
relative to the server. In addition, this provides a simple method
verify that the server reply is in fact a legitimate response to
specific client request and avoid replays. In multicast mode,
client has no information to calculate the propagation delay
determine the validity of the server, unless the NTP
scheme is used

To calculate the roundtrip delay d and local clock offset t
to the server, the client sets the transmit timestamp in the
to the time of day according to the client clock in NTP

Mills Informational [Page 12]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

format. The server copies this field to the originate timestamp
the reply and sets the receive timestamp and transmit timestamp
the time of day according to the server clock in NTP
format

When the server reply is received, the client determines
Destination Timestamp variable as the time of arrival according
its clock in NTP timestamp format. The following table summarizes
four timestamps

Timestamp Name ID When
------------------------------------------------------------
Originate Timestamp T1 time request sent by
Receive Timestamp T2 time request received by
Transmit Timestamp T3 time reply sent by
Destination Timestamp T4 time reply received by

The roundtrip delay d and local clock offset t are defined

d = (T4 - T1) - (T2 - T3) t = ((T2 - T1) + (T3 - T4)) / 2.

The following table summarizes the SNTP client operations in unicast
anycast and multicast modes. The recommended error checks are
in the Reply and Multicast columns in the table. The message
be considered valid only if all the fields shown contain values
the respective ranges. Whether to believe the message if one or
of the fields marked "ignore" contain invalid values is at
discretion of the implementation

Field Name Unicast/Anycast
Request
----------------------------------------------------------
LI 0 0-2 0-2
VN 1-4 copied from 1-4

Mode 3 4 5
Stratum 0 1-14 1-14
Poll 0 ignore
Precision 0 ignore
Root Delay 0 ignore
Root Dispersion 0 ignore
Reference Identifier 0 ignore
Reference Timestamp 0 ignore
Originate Timestamp 0 (see text)
Receive Timestamp 0 (see text)
Transmit Timestamp (see text) nonzero
Authenticator optional optional

Mills Informational [Page 13]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

6. SNTP Server

A SNTP Version 4 server operating with either a NTP or SNTP client
the same or previous versions retains no persistent state. Since
SNTP server ordinarily does not implement the full set of
algorithms intended to support redundant peers and diverse
paths, a SNTP server should be operated only in conjunction with
source of external synchronization, such as a reliable radio clock
telephone modem. In this case it always operates as a
(stratum 1) server

A SNTP server can operate in unicast mode, anycast mode,
mode or any combination of these modes. In unicast and anycast modes
the server receives a request (mode 3), modifies certain fields
the NTP header, and sends a reply (mode 4), possibly using the
message buffer as the request. In anycast mode, the server listens
the designated local broadcast or multicast group address assigned
the IANA, but uses its own unicast address in the source
field of the reply. Other than the selection of address in the reply
the operations of anycast and unicast servers are identical
Multicast messages are normally sent at poll intervals from 64 s
1024 s, depending on the expected frequency tolerance of the
clocks and the required accuracy

In unicast and anycast modes, the VN and Poll fields of the
are copied intact to the reply. If the Mode field of the request is 3
(client), it is set to 4 (server) in the reply; otherwise, this
is set to 2 (symmetric passive) in order to conform to the
specification. This allows clients configured in symmetric
(mode 1) to interoperate successfully, even if configured in
suboptimal ways. In multicast (unsolicited) mode, the VN field is
to 4, the Mode field is set to 5 (broadcast), and the Poll field
to the nearest integer base-2 logarithm of the poll interval

Note that it is highly desirable that, if a server
multicast mode, it also supports unicast mode. This is so
potential multicast client can calculate the propagation
using a client/server exchange prior to regular operation
only multicast mode. If the server supports anycast mode, then
must support unicast mode. There does not seem to be a
advantage to operate both multicast and anycast modes at the
time, although the protocol specification does not forbid it

In unicast and anycast modes, the server may or may not respond
not synchronized to a correctly operating radio clock, but
preferred option is to respond, since this allows reachability to
determined regardless of synchronization state. In multicast mode
the server sends broadcasts only if synchronized to a

Mills Informational [Page 14]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

operating reference clock

The remaining fields of the NTP header are set in the following way
Assuming the server is synchronized to a radio clock or other
reference source and operating correctly, the LI field is set to 0
and the Stratum field is set to 1 (primary server); if not,
Stratum field is set to 0 and the LI field is set to 3. The
field is set to reflect the maximum reading error of the local clock
For all practical cases it is computed as the negative of the
of significant bits to the right of the decimal point in the
timestamp format. The Root Delay and Root Dispersion fields are
to 0 for a primary server; optionally, the Root Dispersion field
be set to a value corresponding to the maximum expected error of
radio clock itself. The Reference Identifier is set to designate
primary reference source, as indicated in the table of Section 5
this document

The timestamp fields are set as follows. If the server
unsynchronized or first coming up, all timestamp fields are set
zero. If synchronized, the Reference Timestamp is set to the time
last update was received from the radio clock or modem. In
and anycast modes, the Receive Timestamp and Transmit
fields are set to the time of day when the message is sent and
Originate Timestamp field is copied unchanged from the
Timestamp field of the request. It is important that this field
copied intact, as a NTP client uses it to avoid replays. In
mode, the Originate Timestamp and Receive Timestamp fields are set
0 and the Transmit Timestamp field is set to the time of day when
message is sent. The following table summarizes these actions

Field Name Unicast/Anycast
Request
----------------------------------------------------------
LI ignore 0 or 3 0 or 3
VN 1-4 copied from 4

Mode 3 2 or 4 5
Stratum ignore 1 1
Poll ignore copied from log2
request
Precision ignore -log2 server -log2
significant
bits
Root Delay ignore 0 0
Root Dispersion ignore 0 0
Reference Identifier ignore source ident source
Reference Timestamp ignore time of last time of
radio update radio

Mills Informational [Page 15]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

Originate Timestamp ignore copied from 0

Receive Timestamp ignore time of day 0
Transmit Timestamp (see text) time of day time of
Authenticator optional optional

There is some latitude on the part of most clients to forgive
timestamps, such as might occur when first coming up or
periods when the primary reference source is inoperative. The
important indicator of an unhealthy server is the LI field, in
a value of 3 indicates an unsynchronized condition. When this
is displayed, clients should discard the server message,
of the contents of other fields

7. Configuration and

Initial setup for SNTP servers and clients can be done using
configuration file if a file system is available, or a serial port
not. It is intended that in-service management of NTP and
Version 4 servers and clients be performed using SNMP and a
MIB to be published later. Ordinarily, SNTP servers and clients
expected to operate with little or no site-specific configuration
other than specifying the IP address and subnet mask or OSI
address

Unicast clients must be provided with the designated server name
address. If a server name is used, the address of one of more
servers must be provided. Multicast servers and anycast clients
be provided with the TTL and local broadcast or multicast
address. Anycast servers and multicast clients may be configured
a list of address-mask pairs for access control, so that only
clients or servers known to be trusted will be used. These
and clients must implement the IGMP protocol and be provided with
local broadcast or multicast group address as well. The
data for cryptographic authentication is beyond the scope of
document

There are several scenarios which provide automatic server
and selection for SNTP clients with no pre-specified configuration
other than the IP address and subnet mask or OSI NSAP address. For
IP subnet or LAN segment including a fully functional NTP server,
clients can be configured for multicast mode using the
broadcast address. The same approach can be used with other
using the multicast group address. In both cases, provision of
access control list is a good way to insure only trusted sources
be used to set the local clock

Mills Informational [Page 16]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

In another scenario suitable for an extended network with
network propagation delays, clients can be configured for
mode, both upon initial startup and after some period when
currently selected unicast source has not been heard. Following
defined protocol, the client binds to the first reply heard
continues operation in unicast mode. In this mode the local clock
be automatically adjusted to compensate for the propagation delay

In still another scenario suitable for any network and
multicast service is not available, the DNS can be set up with
common CNAME, like time.domain.net, and a list of address records
NTP servers in the same domain. Upon resolving time.domain.net
obtaining the list, the client selects a server at random and
operation in unicast mode with that server. Many variations on
theme are possible

8.

Jeff Learman was helpful in developing the OSI model for
protocol. Ajit Thyagarajan provided valuable suggestions
corrections

9.

[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "
for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.

[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
USC Information Sciences Institute, September 1981.

[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, Stanford University, August 1989.

[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, Xerox and Ipsilon, January 1996.

[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI
transport services on top of UDP - Version: 1", RFC 1240,
Software Foundation, June 1991.

[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name
Security Extensions", Work in Progress

[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to
basic communications applications", RFC 1698, Consultant
October 1994.

Mills Informational [Page 17]

RFC 2030 SNTPv4 for IPv4, IPv6 and OSI October 1996

[HIN96] Hinden, R., and S. Deering, "IP Version 6
Architecture", RFC 1884, Ipsilon and Xerox, January 1996.

[ISO86] International Standards 8602 - Information Processing
- OSI: Connectionless Transport Protocol Specification.
Standards Organization, December 1986.

[MIL92] Mills, D., "Network Time Protocol (Version 3) specification
implementation and analysis", RFC 1305, University of Delaware
March 1992.

[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host
service", RFC 1546, Bolt Beranek Newman, November 1993.

[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC Information Sciences Institute, August 1980.

[POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
USC Information Sciences Institute, May 1983.

Security

Security issues are not discussed in this memo

Author's

David L.
Electrical Engineering
University of
Newark, DE 19716

Phone: (302) 831-8247

Mills Informational [Page 18]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX