[要約] RFC 4330は、IPv4、IPv6、およびOSIのためのSimple Network Time Protocol（SNTP）バージョン4に関する規格です。このRFCの目的は、ネットワーク上のデバイス間で正確な時刻情報を同期するためのプロトコルを提供することです。
Network Working Group D. Mills
Request for Comments: 4330 University of Delaware
Obsoletes: 2030, 1769 January 2006
Category: Informational
Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 and OSI
IPv4、IPv6、OSI用のSimple Network Time Protocol（SNTP）バージョン4
Status of This Memo
本文書の状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
Abstract
概要
This memorandum describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a subset of the Network Time Protocol (NTP) used to synchronize computer clocks in the Internet. SNTPv4 can be used when the ultimate performance of a full NTP implementation based on RFC 1305 is neither needed nor justified. When operating with current and previous NTP and SNTP versions, SNTPv4 requires no changes to the specifications or known implementations, but rather clarifies certain design features that allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC 868.
この覚書は、インターネットでコンピューターのクロックを同期するために使用されるネットワークタイムプロトコル（NTP）のサブセットであるシンプルネットワークタイムプロトコルバージョン4（SNTPv4）について説明しています。 SNTPv4は、RFC 1305に基づく完全なNTP実装の究極のパフォーマンスが必要でなく、正当化されていない場合に使用できます。 SNTPv4は、現在および以前のNTPおよびSNTPバージョンで動作する場合、仕様や既知の実装を変更する必要はありませんが、同様の精度と信頼性が期待されるシンプルでステートレスなリモートプロシージャコール（RPC）モードでの動作を可能にする特定の設計機能を明確にします。 RFC 868で説明されているUDP / TIMEプロトコルに。
This memorandum obsoletes RFC 1769, which describes SNTP Version 3 (SNTPv3), and RFC 2030, which describes SNTPv4. Its purpose is to correct certain inconsistencies in the previous documents and to clarify header formats and protocol operations for NTPv3 (IPv4) and SNTPv4 (IPv4, IPv6, and OSI), which are also used for SNTP. A further purpose is to provide guidance for home and business client implementations for routers and other consumer devices to protect the server population from abuse. A working knowledge of the NTPv3 specification, RFC 1305, is not required for an implementation of SNTP.
この覚書は、SNTPバージョン3（SNTPv3）を説明するRFC 1769、およびSNTPv4を説明するRFC 2030を廃止します。その目的は、以前の文書の特定の不整合を修正し、SNTPにも使用されるNTPv3（IPv4）およびSNTPv4（IPv4、IPv6、およびOSI）のヘッダー形式とプロトコル操作を明確にすることです。さらなる目的は、ルーターおよびその他のコンシューマーデバイスのホームクライアントおよびビジネスクライアントの実装に関するガイダンスを提供して、サーバーの乱用からサーバーを保護することです。 NTPv3仕様の実用的な知識であるRFC 1305は、SNTPの実装には必要ありません。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Specification of Requirements ..............................5
2. Operating Modes and Addressing ..................................5
3. NTP Timestamp Format ............................................6
4. Message Format ..................................................8
5. SNTP Client Operations .........................................13
6. SNTP Server Operations .........................................16
7. Configuration and Management ...................................19
8. The Kiss-o'-Death Packet .......................................20
9. On Being a Good Network Citizen ................................21
10. Best Practices ................................................21
11. Security Considerations .......................................24
12. Acknowledgements ..............................................24
13. Contributors ..................................................24
14. Informative References ........................................25
The Network Time Protocol Version 3 (NTPv3), specified in RFC 1305 [MIL92], is widely used to synchronize computer clocks in the global Internet. It provides comprehensive mechanisms to access national time and frequency dissemination services, organize the NTP subnet of servers and clients, and adjust the system clock in each participant. In most places of the Internet of today, NTP provides accuracies of 1-50 ms, depending on the characteristics of the synchronization source and network paths.
RFC 1305 [MIL92]で指定されているネットワークタイムプロトコルバージョン3（NTPv3）は、グローバルインターネットでコンピューターのクロックを同期するために広く使用されています。全国的な時間と周波数の普及サービスにアクセスし、サーバーとクライアントのNTPサブネットを編成し、各参加者のシステムクロックを調整するための包括的なメカニズムを提供します。今日のインターネットのほとんどの場所で、NTPは、同期ソースとネットワークパスの特性に応じて、1〜50 msの精度を提供します。
RFC 1305 specifies the NTP protocol machine in terms of events, states, transition functions and actions, and engineered algorithms to improve the timekeeping quality and to mitigate several synchronization sources, some of which may be faulty. To achieve accuracies in the low milliseconds over paths spanning major portions of the Internet, these intricate algorithms, or their functional equivalents, are necessary. In many applications, accuracies on the order of significant fractions of a second are acceptable. In simple home router applications, accuracies of up to a minute may suffice. In such cases, simpler protocols, such as the Time Protocol specified in RFC 868 [POS83], have been used for this purpose. These protocols involve an RPC exchange where the client requests the time of day and the server returns it in seconds past a known reference epoch.
RFC 1305は、NTPプロトコルマシンをイベント、状態、遷移機能とアクションの観点から指定し、計時品質を向上させ、いくつかの同期ソースを軽減するために設計されたアルゴリズムを提供しています。インターネットの主要部分にまたがるパスで数ミリ秒の精度を実現するには、これらの複雑なアルゴリズム、またはそれらの同等の機能が必要です。多くのアプリケーションでは、1秒の数分の1程度の精度が許容範囲です。シンプルなホームルーターアプリケーションでは、最大1分の精度で十分な場合があります。このような場合、RFC 868 [POS83]で指定されているTime Protocolなどのより単純なプロトコルがこの目的で使用されています。これらのプロトコルにはRPC交換が含まれ、クライアントは時刻を要求し、サーバーは既知の参照エポックを過ぎて秒単位で時刻を返します。
NTP is designed for use by clients and servers with a wide range of capabilities and over a wide range of network jitter and clock frequency wander characteristics. Many users of NTP in the Internet of today use a software distribution available from www.ntp.org. The distribution, which includes the full suite of NTP options, mitigation algorithms, and security schemes, is a relatively complex, real-time application. Although the software has been ported to a wide variety of hardware platforms ranging from personal computers to supercomputers, its sheer size and complexity is not appropriate for many applications. Accordingly, it is useful to explore alternative strategies using simpler software appropriate for less stringent accuracy expectations.
NTPは、幅広い機能を備え、幅広いネットワークジッタとクロック周波数ワンダー特性を備えたクライアントとサーバーで使用するように設計されています。今日のインターネットでのNTPの多くのユーザーは、www.ntp.orgから入手可能なソフトウェア配布を使用しています。 NTPオプション、軽減アルゴリズム、セキュリティスキームの完全なスイートを含む配布は、比較的複雑なリアルタイムアプリケーションです。このソフトウェアは、パーソナルコンピューターからスーパーコンピューターまで、さまざまなハードウェアプラットフォームに移植されていますが、そのサイズと複雑さは、多くのアプリケーションには適していません。したがって、それほど厳密ではない精度の期待に適した、より単純なソフトウェアを使用して代替戦略を検討することは有用です。
This memo describes the Simple Network Time Protocol Version 4 (SNTPv4), which is a simplified access paradigm for servers and clients using current and previous versions of NTP and SNTP. The access paradigm is identical to the UDP/TIME Protocol, and, in fact, it should be easy to adapt a UDP/TIME client implementation, say for a personal computer, to operate using SNTP. Moreover, SNTP is also designed to operate in a dedicated server configuration including an integrated radio clock. With careful design and control of the various latencies in the system, which is practical in a dedicated design, it is possible to deliver time accurate on the order of microseconds.
このメモは、現在および以前のバージョンのNTPとSNTPを使用するサーバーとクライアントの簡略化されたアクセスパラダイムである、Simple Network Time Protocol Version 4（SNTPv4）について説明しています。アクセスパラダイムは、UDP / TIMEプロトコルと同じであり、実際には、UDP / TIMEクライアントの実装、たとえばパーソナルコンピューターをSNTPを使用して操作するように簡単に適合させることができます。さらに、SNTPは、統合された電波時計を含む専用サーバー構成で動作するようにも設計されています。専用設計では実用的である、システム内のさまざまな待ち時間の注意深い設計と制御により、マイクロ秒のオーダーで正確な時間を提供することが可能です。
The only significant protocol change in SNTPv4 from previous SNTP versions is a modified header interpretation to accommodate Internet Protocol Version 6 (IPv6) (RFC 2460) and OSI (RFC 1629) addressing. However, SNTPv4 includes certain optional extensions to the basic NTP Version 3 (NTPv3) model, including a manycast mode and a public-key-based authentication scheme designed specifically for broadcast and manycast applications. Although the manycast mode is described in this memo, the authentication scheme is described in another RFC to be submitted later. Until such time that a definitive NTPv4 specification is published, the manycast and authentication features should be considered provisional. In addition, this memo introduces the kiss-o'-death message, which can be used by servers to suppress client requests as circumstances require.
以前のSNTPバージョンからのSNTPv4での重要なプロトコル変更は、インターネットプロトコルバージョン6（IPv6）（RFC 2460）およびOSI（RFC 1629）アドレッシングに対応するために変更されたヘッダー解釈です。ただし、SNTPv4には、基本的なNTPバージョン3（NTPv3）モデルに対するオプションの拡張機能がいくつか含まれています。これには、ブロードキャストおよびメニーキャストアプリケーション用に特別に設計されたメニーキャストモードや公開鍵ベースの認証スキームが含まれます。メニーキャストモードはこのメモで説明されていますが、認証スキームは後で送信される別のRFCで説明されています。決定的なNTPv4仕様が公開されるまでは、メニーキャストと認証機能は暫定的なものと見なす必要があります。さらに、このメモはkiss-o'-deathメッセージを紹介しています。このメッセージは、状況に応じてサーバーがクライアント要求を抑制するために使用できます。
When operating with current and previous versions of NTP and SNTP, SNTPv4 requires no changes to the protocol or implementations now running or likely to be implemented specifically for future NTP or SNTP versions. The NTP and SNTP packet formats are the same, and the arithmetic operations to calculate the client time, clock offset, and roundtrip delay are the same. To an NTP or SNTP server, NTP and SNTP clients are indistinguishable; to an NTP or SNTP client, NTP and SNTP servers are indistinguishable. Like NTP servers operating in non-symmetric modes, SNTP servers are stateless and can support large numbers of clients; however, unlike most NTP clients, SNTP clients normally operate with only a single server at a time.
現在および以前のバージョンのNTPおよびSNTPで動作する場合、SNTPv4は、現在実行中のプロトコルまたは実装に変更を加える必要がなく、将来のNTPまたはSNTPバージョン用に実装される可能性が高いです。 NTPとSNTPのパケット形式は同じで、クライアント時間、クロックオフセット、往復遅延を計算する算術演算は同じです。 NTPまたはSNTPサーバーにとって、NTPクライアントとSNTPクライアントは区別できません。 NTPまたはSNTPクライアントにとって、NTPサーバーとSNTPサーバーは区別できません。非対称モードで動作するNTPサーバーと同様に、SNTPサーバーはステートレスであり、多数のクライアントをサポートできます。ただし、ほとんどのNTPクライアントとは異なり、SNTPクライアントは通常、一度に1つのサーバーのみで動作します。
The full degree of reliability ordinarily expected of NTP servers is possible only using redundant sources, diverse paths, and the crafted algorithms of a full NTP implementation. It is strongly recommended that SNTP clients be used only at the extremities of the synchronization subnet. SNTP clients should operate only at the leaves (highest stratum) of the subnet and in configurations where no NTP or SNTP client is dependent on another SNTP client for synchronization. SNTP servers should operate only at the root (stratum 1) of the subnet, and then only in configurations where no other source of synchronization other than a reliable radio clock or telephone modem is available.
NTPサーバーに通常期待される完全な信頼性は、冗長なソース、多様なパス、および完全なNTP実装の巧妙に細工されたアルゴリズムを使用してのみ可能です。 SNTPクライアントは、同期サブネットの末端でのみ使用することを強くお勧めします。 SNTPクライアントは、サブネットのリーフ（最も高い層）でのみ、またNTPまたはSNTPクライアントが同期のために別のSNTPクライアントに依存していない構成でのみ動作する必要があります。 SNTPサーバーは、サブネットのルート（層1）でのみ動作し、信頼できるラジオクロックまたは電話モデム以外の同期のソースが利用できない構成でのみ動作します。
An important provision in this memo is the interpretation of certain NTP header fields that provide for IPv6 [DEE98] and OSI [COL94] addressing. The only significant difference between the NTP and SNTPv4 header formats is the four-octet Reference Identifier field, which is used primarily to detect and avoid synchronization loops. In all NTP and SNTP versions providing IPv4 addressing, primary servers use a four-character ASCII reference clock identifier in this field, whereas secondary servers use the 32-bit IPv4 address of the synchronization source. In SNTPv4 providing IPv6 and OSI addressing, primary servers use the same clock identifier, but secondary servers use the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source. A further use of this field is when the server sends a kiss-o'-death message, documented later in this memo.
このメモの重要な規定は、IPv6 [DEE98]およびOSI [COL94]アドレス指定を提供する特定のNTPヘッダーフィールドの解釈です。 NTPとSNTPv4のヘッダー形式の唯一の重要な違いは、4オクテットのリファレンスIDフィールドです。これは、主に同期ループを検出して回避するために使用されます。 IPv4アドレッシングを提供するすべてのNTPおよびSNTPバージョンでは、プライマリサーバーはこのフィールドで4文字のASCII参照クロック識別子を使用しますが、セカンダリサーバーは同期ソースの32ビットIPv4アドレスを使用します。 IPv6およびOSIアドレッシングを提供するSNTPv4では、プライマリサーバーは同じクロック識別子を使用しますが、セカンダリサーバーは、同期ソースのIPv6またはNSAPアドレスのMD5ハッシュの最初の32ビットを使用します。このフィールドのさらなる用途は、サーバーがkiss-o'-deathメッセージを送信する場合です。
NTP Version 4 (NTPv4), now in deployment, but not yet the subject of a standards document, uses the same Reference Identifier field as SNTPv4.
NTPバージョン4（NTPv4）は現在展開中ですが、標準ドキュメントの主題ではありませんが、SNTPv4と同じ参照識別子フィールドを使用します。
In the case of OSI, the Connectionless Transport Service (CLTS) is used as in [ISO86]. Each SNTP packet is transmitted as the TS-Userdata parameter of a T-UNITDATA Request primitive. Alternately, the header can be encapsulated in a Transport Protocol Data Unit (TPDU), which itself is transported using UDP, as described in RFC 1240 [DOB91]. It is not advised that NTP be operated at the upper layers of the OSI stack, such as might be inferred from RFC 1698 [FUR94], as this could seriously degrade accuracy. With the header formats defined in this memo, it is in principle possible to interwork between servers and clients of one protocol family and another, although the practical difficulties may make this inadvisable.
OSIの場合、コネクションレス型トランスポートサービス（CLTS）は[ISO86]のように使用されます。各SNTPパケットは、T-UNITDATA要求プリミティブのTS-Userdataパラメーターとして送信されます。代わりに、RFC 1240 [DOB91]で説明されているように、UDPを使用してそれ自体が転送されるトランスポートプロトコルデータユニット（TPDU）にヘッダーをカプセル化できます。 RFC 1698 [FUR94]から推測されるように、NTPがOSIスタックの上位層で動作することはお勧めできません。これは、精度が著しく低下する可能性があるためです。このメモで定義されたヘッダー形式を使用すると、原則として、あるプロトコルファミリと別のプロトコルファミリのサーバーとクライアントの間で相互運用することができますが、実際の問題により、これは賢明ではありません。
In the following, indented paragraphs such as this one contain information not required by the formal protocol specification, but considered good practice in protocol implementations.
以下では、このようなインデントされた段落には、正式なプロトコル仕様では必要とされない情報が含まれていますが、プロトコル実装における適切な慣行と見なされています。
This memo is organized as follows. Section 2 describes how the protocol works, the various modes, and how IP addresses and UDP ports are used. Section 3 describes the NTP timestamp format, and Section
このメモは次のように構成されています。セクション2では、プロトコルの動作、さまざまなモード、およびIPアドレスとUDPポートの使用方法について説明します。セクション3では、NTPタイムスタンプ形式について説明します。
4 the NTP message format. Section 5 summarizes SNTP client operations, and Section 6 summarizes SNTP server operations. Section 7 summarizes operation and management issues. Section 8 describes the kiss-o'-death message, newly minted with functions similar to the ICMP Source Quench and ICMP Destination Unreachable messages. Section 9 summarizes design issues important for good network citizenry and presents an example algorithm designed to give good reliability while minimizing network and server resource demands.
4 NTPメッセージ形式。セクション5はSNTPクライアント操作を要約し、セクション6はSNTPサーバー操作を要約します。セクション7では、運用と管理の問題を要約します。セクション8では、ICMP Source QuenchおよびICMP Destination Unreachableメッセージと同様の機能で新しく作成されたkiss-o'-deathメッセージについて説明します。セクション9では、優れたネットワーク市民にとって重要な設計上の問題を要約し、ネットワークとサーバーのリソース要求を最小限に抑えながら、優れた信頼性を提供するように設計されたアルゴリズムの例を示します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [BRA97].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 RFC 2119 [BRA97]で説明されているように解釈されます。
Unless excepted in context, a reference to broadcast address means IPv4 broadcast address, IPv4 multicast group address, or IPv6 address of appropriate scope. Further information on the broadcast/multicast model is in RFC 1112 [DEE89]. Details of address format, scoping rules, etc., are beyond the scope of this memo. SNTPv4 can operate with either unicast (point to point), broadcast (point to multipoint), or manycast (multipoint to point) addressing modes. A unicast client sends a request to a designated server at its unicast address and expects a reply from which it can determine the time and, optionally, the roundtrip delay and clock offset relative to the server. A broadcast server periodically sends an unsolicited message to a designated broadcast address. A broadcast client listens on this address and ordinarily sends no requests.
コンテキストで例外がない限り、ブロードキャストアドレスへの参照は、IPv4ブロードキャストアドレス、IPv4マルチキャストグループアドレス、または適切なスコープのIPv6アドレスを意味します。ブロードキャスト/マルチキャストモデルの詳細については、RFC 1112 [DEE89]を参照してください。アドレス形式、スコープ規則などの詳細は、このメモの範囲を超えています。 SNTPv4は、ユニキャスト（ポイントツーポイント）、ブロードキャスト（ポイントツーマルチポイント）、またはメニーキャスト（マルチポイントツーポイント）アドレッシングモードで動作できます。ユニキャストクライアントは、そのユニキャストアドレスで指定されたサーバーに要求を送信し、応答を期待します。この応答から、時間と、必要に応じて、サーバーに対する往復遅延とクロックオフセットを決定できます。ブロードキャストサーバーは、指定されたブロードキャストアドレスに非請求メッセージを定期的に送信します。ブロードキャストクライアントはこのアドレスをリッスンし、通常はリクエストを送信しません。
Manycast is an extension of the anycast paradigm described in RFC 1546 [PAR93]. It is designed for use with a set of cooperating servers whose addresses are not known beforehand. The manycast client sends an ordinary NTP client request to a designated broadcast address. One or more manycast servers listen on that address. Upon receiving a request, a manycast server sends an ordinary NTP server reply to the client. The client then mobilizes an association for each server found and continues operation with all of them. Subsequently, the NTP mitigation algorithms operate to cast out all except the best three.
メニーキャストは、RFC 1546 [PAR93]で説明されているエニーキャストパラダイムの拡張版です。これは、事前にアドレスがわからない一連の連携サーバーで使用するように設計されています。メニーキャストクライアントは、通常のNTPクライアント要求を指定されたブロードキャストアドレスに送信します。 1つ以上のメニーキャストサーバーがそのアドレスをリッスンします。メニーキャストサーバーは、要求を受信すると、通常のNTPサーバー応答をクライアントに送信します。次に、クライアントは見つかった各サーバーの関連付けを動員し、それらすべてで操作を続行します。その後、NTP軽減アルゴリズムは、ベスト3を除くすべてをキャストアウトするように動作します。
Broadcast servers should respond to client unicast requests, as well as send unsolicited broadcast messages. Broadcast clients may send unicast requests in order to measure the network propagation delay between the server and client and then continue operation in listen-only mode. However, broadcast servers may choose not to respond to unicast requests, so unicast clients should be prepared to abandon the measurement and assume a default value for the delay.
ブロードキャストサーバーは、クライアントのユニキャスト要求に応答し、一方的なブロードキャストメッセージを送信する必要があります。ブロードキャストクライアントは、サーバーとクライアントの間のネットワーク伝播遅延を測定するためにユニキャスト要求を送信し、listen-onlyモードで操作を続行できます。ただし、ブロードキャストサーバーはユニキャスト要求に応答しないことを選択する場合があるため、ユニキャストクライアントは測定を中止して遅延のデフォルト値を想定する準備をする必要があります。
The client and server addresses are assigned following the usual IPv4, IPv6 or OSI conventions. For NTP multicast, the IANA has reserved the IPv4 group address 224.0.1.1 and the IPv6 address ending :101 with appropriate scope. The NTP broadcast address for OSI has yet to be determined. Notwithstanding the IANA reserved addresses, other multicast addresses can be used that do not conflict with others assigned in scope. The scoping, routing, and group membership procedures are determined by considerations beyond the scope of this memo.
クライアントとサーバーのアドレスは、通常のIPv4、IPv6、またはOSIの規則に従って割り当てられます。 NTPマルチキャストの場合、IANAはIPv4グループアドレス224.0.1.1および末尾が：101のIPv6アドレスを適切なスコープで予約しています。 OSIのNTPブロードキャストアドレスはまだ決定されていません。 IANAの予約済みアドレスにもかかわらず、スコープ内で割り当てられた他のアドレスと競合しない他のマルチキャストアドレスを使用できます。スコーピング、ルーティング、およびグループメンバーシップの手順は、このメモの範囲を超える考慮事項によって決定されます。
It is important to adjust the time-to-live (TTL) field in the IP header of multicast messages to a reasonable value in order to limit the network resources used by this (and any other) multicast service. Only multicast clients in scope will receive multicast server messages. Only cooperating manycast servers in scope will reply to a client request. The engineering principles that determine the proper values to be used are beyond the scope of this memo.
この（およびその他の）マルチキャストサービスで使用されるネットワークリソースを制限するには、マルチキャストメッセージのIPヘッダーの存続可能時間（TTL）フィールドを適切な値に調整することが重要です。スコープ内のマルチキャストクライアントのみがマルチキャストサーバーメッセージを受信します。スコープ内で協力しているメニーキャストサーバーのみがクライアント要求に応答します。使用する適切な値を決定するエンジニアリングの原則は、このメモの範囲を超えています。
In the case of SNTP as specified herein, there is a very real vulnerability that SNTP broadcast clients can be disrupted by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security in such cases.
ここで指定されているSNTPの場合、SNTPブロードキャストクライアントがインターネットの他の場所にあるSNTPまたはNTPブロードキャストサーバーの誤動作または悪意のあるサーバーによって妨害される可能性があるという非常に現実的な脆弱性があります。このような場合のセキュリティを強化するために、アクセス制御や暗号化認証手段を提供することを強くお勧めします。
It is intended that IP broadcast addresses will be used primarily in IP subnets and LAN segments including a fully functional NTP server with a number of dependent SNTP broadcast clients on the same subnet, and that IP multicast group addresses will be used only in cases where the TTL is engineered specifically for each service domain. However, these uses are not integral to the SNTP specification.
IPブロードキャストアドレスは、主にIPサブネットとLANセグメントで使用され、同じサブネット上に多数の依存SNTPブロードキャストクライアントを持つ完全に機能するNTPサーバーを含み、IPマルチキャストグループアドレスは、 TTLは、サービスドメインごとに特別に設計されています。ただし、これらの使用法はSNTP仕様に不可欠ではありません。
SNTP uses the standard NTP timestamp format described in RFC 1305 and previous versions of that document. In conformance with standard Internet practice, NTP data are specified as integer or fixed-point quantities, with bits numbered in big-endian fashion from 0 starting at the left or most significant end. Unless specified otherwise, all quantities are unsigned and may occupy the full field width with an implied 0 preceding bit 0.
SNTPは、RFC 1305およびそのドキュメントの以前のバージョンで説明されている標準のNTPタイムスタンプ形式を使用します。標準のインターネット慣行に準拠して、NTPデータは整数または固定小数点数として指定され、ビットは左端または最上位から0からビッグエンディアン形式で番号が付けられます。特に明記されていない限り、すべての数量は符号なしであり、ビット0の前に暗黙の0があるフィールド幅全体を占めることがあります。
Because NTP timestamps are cherished data and, in fact, represent the main product of the protocol, a special timestamp format has been established. NTP timestamps are represented as a 64-bit unsigned fixed-point number, in seconds relative to 0h on 1 January 1900. The integer part is in the first 32 bits, and the fraction part in the last 32 bits. In the fraction part, the non-significant low-order bits are not specified and are ordinarily set to 0.
NTPタイムスタンプは大切なデータであり、実際にはプロトコルの主要製品であるため、特別なタイムスタンプ形式が確立されています。 NTPタイムスタンプは、1900年1月1日の0hを基準にした秒単位の64ビットの符号なし固定小数点数として表されます。整数部分は最初の32ビットで、小数部分は最後の32ビットです。小数部では、重要でない下位ビットは指定されず、通常は0に設定されます。
It is advisable to fill the non-significant low-order bits of the timestamp with a random, unbiased bitstring, both to avoid systematic roundoff errors and to provide loop detection and replay detection (see below). It is important that the bitstring be unpredictable by an intruder. One way of doing this is to generate a random 128-bit bitstring at startup. After that, each time the system clock is read, the string consisting of the timestamp and bitstring is hashed with the MD5 algorithm, then the non-significant bits of the timestamp are copied from the result.
体系的な丸めエラーを回避し、ループ検出と再生検出を提供するために（以下を参照）、タイムスタンプの重要でない下位ビットをランダムな不偏ビット文字列で埋めることをお勧めします。侵入者がビットストリングを予測できないことが重要です。これを行う1つの方法は、起動時にランダムな128ビットのビット文字列を生成することです。その後、システムクロックが読み取られるたびに、タイムスタンプとビット文字列で構成される文字列がMD5アルゴリズムでハッシュされ、タイムスタンプの重要でないビットが結果からコピーされます。
The NTP format allows convenient multiple-precision arithmetic and conversion to UDP/TIME message (seconds), but does complicate the conversion to ICMP Timestamp message (milliseconds) and Unix time values (seconds and microseconds or seconds and nanoseconds). The maximum number that can be represented is 4,294,967,295 seconds with a precision of about 232 picoseconds, which should be adequate for even the most exotic requirements.
NTP形式では、便利な倍精度演算とUDP / TIMEメッセージ（秒）への変換が可能ですが、ICMPタイムスタンプメッセージ（ミリ秒）とUnix時間値（秒とマイクロ秒または秒とナノ秒）への変換は複雑になります。表現できる最大数は、4,294,967,295秒で、精度は約232ピコ秒です。これは、最も特殊な要件でも十分なはずです。
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 most significant bit (bit 0 of the integer part) has been set and that the 64-bit field will overflow some time in 2036 (second 4,294,967,296). There will exist a 232-picosecond interval, henceforth ignored, every 136 years when the 64-bit field will be 0, which by convention is interpreted as an invalid or unavailable timestamp.
1968年のある時点（2番目の2,147,483,648）以降、最上位ビット（整数部のビット0）が設定され、64ビットフィールドが2036年のある時点（2番目の4,294,967,296）でオーバーフローすることに注意してください。 232ピコ秒の間隔が存在し、以降は無視されます。64ビットのフィールドが0になる136年ごとに、慣例により無効または使用不可のタイムスタンプとして解釈されます。
As the NTP timestamp format has been in use for over 20 years, it is possible that it will be in use 32 years from now, when the seconds field overflows. As it is probably inappropriate to archive NTP timestamps before bit 0 was set in 1968, a convenient way to extend the useful life of NTP timestamps is the following convention: If bit 0 is set, the UTC time is in the 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 February 2036. Note that when calculating the correspondence, 2000 is a leap year, and leap seconds are not included in the reckoning.
NTPタイムスタンプ形式は20年以上使用されているため、秒フィールドがオーバーフローした場合、32年後に使用される可能性があります。 1968年にビット0が設定される前にNTPタイムスタンプをアーカイブすることはおそらく不適切であるため、NTPタイムスタンプの有効期間を延長する便利な方法は次の規則です。ビット0が設定されている場合、UTC時間は1968〜2036の範囲です。また、UTC時間は1900年1月1日の0h 0m 0s UTCから計算されます。ビット0が設定されていない場合、時間は2036〜2104の範囲にあり、UTC時間は2036年2月7日の6h 28m 16s UTCから計算されます。 2000年はうるう年であり、うるう秒は計算に含まれません。
The arithmetic calculations used by NTP to determine the clock offset and roundtrip delay require the client time to be within 34 years of the server time before the client is launched. As the time since the Unix base 1970 is now more than 34 years, means must be available to initialize the clock at a date closer to the present, either with a time-of-year (TOY) chip or from firmware.
NTPがクロックオフセットと往復遅延を決定するために使用する算術計算では、クライアントを起動する前に、クライアントの時間をサーバーの時間の34年以内にする必要があります。 1970年のUnixベースからの経過時間が34年を超えているため、現在時刻に近い日付で時計を初期化する手段が必要です。これは、年式（TOY）チップまたはファームウェアのいずれかによるものです。
Both NTP and SNTP are clients of the User Datagram Protocol (UDP) specified in RFC 768 [POS80]. The structures of the IP and UDP headers are described in the cited specification documents and will not be detailed further here. The UDP port number assigned by the IANA to NTP is 123. The SNTP client should use this value in the UDP Destination Port field for client request messages. The Source Port field of these messages can be any nonzero value chosen for identification or multiplexing purposes. The server interchanges these fields for the corresponding reply messages.
NTPとSNTPはどちらも、RFC 768 [POS80]で指定されているユーザーデータグラムプロトコル（UDP）のクライアントです。 IPヘッダーとUDPヘッダーの構造は、引用された仕様書に記載されており、ここではこれ以上詳しく説明しません。 IANAによってNTPに割り当てられたUDPポート番号は123です。SNTPクライアントは、クライアント要求メッセージのUDP宛先ポートフィールドでこの値を使用する必要があります。これらのメッセージのSource Portフィールドは、識別または多重化の目的で選択されたゼロ以外の値にすることができます。サーバーは、対応する応答メッセージのこれらのフィールドを交換します。
This differs from the RFC 2030 specifications, which required both the source and destination ports to be 123. The intent of this change is to allow the identification of particular client implementations (which are now allowed to use unreserved port numbers, including ones of their choosing) and to attain compatibility with Network Address Port Translation (NAPT) described in RFC 2663 [SRI99] and RFC 3022 [SRI01].
これは、送信元ポートと宛先ポートの両方を123にする必要のあるRFC 2030仕様とは異なります。この変更の目的は、特定のクライアント実装（選択したものを含む、予約されていないポート番号を使用できるようになった）を識別できるようにすることです。 ）およびRFC 2663 [SRI99]およびRFC 3022 [SRI01]で説明されているネットワークアドレスポート変換（NAPT）との互換性を実現します。
Figure 1 is a description of the NTP and SNTP message format, which follows the IP and UDP headers in the message. This format is identical to the NTP message format described in RFC 1305, with the exception of the Reference Identifier field described below. For SNTP client messages, most of these fields are zero or initialized with pre-specified data. For completeness, the function of each field is briefly summarized below.
図1は、NTPおよびSNTPメッセージ形式の説明であり、メッセージのIPおよびUDPヘッダーの後に続きます。このフォーマットは、RFC 1305で説明されているNTPメッセージフォーマットと同じですが、以下で説明するReference Identifierフィールドを除きます。 SNTPクライアントメッセージの場合、これらのフィールドのほとんどはゼロであるか、事前に指定されたデータで初期化されています。完全を期すために、各フィールドの機能を以下に簡単に要約します。
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1. NTP Packet Header
図1. NTPパケットヘッダー
Leap Indicator (LI): This is a two-bit code warning of an impending leap second to be inserted/deleted in the last minute of the current day. This field is significant only in server messages, where the values are defined as follows:
うるうインジケータ（LI）：これは、当日の最後の分に挿入/削除される差し迫ったうるう秒の2ビットのコード警告です。このフィールドは、値が次のように定義されているサーバーメッセージでのみ重要です。
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)
On startup, servers set this field to 3 (clock not synchronized), and set this field to some other value when synchronized to the primary reference clock. Once set to a value other than 3, the field is never set to that value again, even if all synchronization sources become unreachable or defective.
起動時に、サーバーはこのフィールドを3（クロックが同期されていない）に設定し、プライマリリファレンスクロックに同期されている場合はこのフィールドを他の値に設定します。 3以外の値に設定すると、すべての同期ソースが到達不能または欠陥になった場合でも、フィールドがその値に再度設定されることはありません。
Version Number (VN): This is a three-bit integer indicating the NTP/SNTP version number, currently 4. If necessary to distinguish between IPv4, IPv6, and OSI, the encapsulating context must be inspected.
バージョン番号（VN）：これは、現在4のNTP / SNTPバージョン番号を示す3ビットの整数です。IPv4、IPv6、およびOSIを区別する必要がある場合は、カプセル化コンテキストを検査する必要があります。
Mode: This is a three-bit number indicating the protocol mode. The values are defined as follows:
モード：これは、プロトコルモードを示す3ビットの数値です。値は次のように定義されます。
Mode Meaning
------------------------------------
0 reserved
1 symmetric active
2 symmetric passive
3 client
4 server
5 broadcast
6 reserved for NTP control message
7 reserved for private use
In unicast and manycast modes, the client sets this field to 3 (client) in the request, and the server sets it to 4 (server) in the reply. In broadcast mode, the server sets this field to 5 (broadcast). The other modes are not used by SNTP servers and clients.
ユニキャストモードおよびメニーキャストモードでは、クライアントは要求でこのフィールドを3（クライアント）に設定し、サーバーは応答で4（サーバー）に設定します。ブロードキャストモードでは、サーバーはこのフィールドを5（ブロードキャスト）に設定します。その他のモードは、SNTPサーバーおよびクライアントでは使用されません。
Stratum: This is an eight-bit unsigned integer indicating the stratum. This field is significant only in SNTP server messages, where the values are defined as follows:
層：これは層を示す8ビットの符号なし整数です。このフィールドは、値が次のように定義されているSNTPサーバーメッセージでのみ重要です。
Stratum Meaning
----------------------------------------------
0 kiss-o'-death message (see below)
1 primary reference (e.g., synchronized by radio clock)
2-15 secondary reference (synchronized by NTP or SNTP)
16-255 reserved
Poll Interval: This is an eight-bit unsigned integer used as an exponent of two, where the resulting value is the maximum interval between successive messages in seconds. This field is significant only in SNTP server messages, where the values range from 4 (16 s) to 17 (131,072 s -- about 36 h).
ポーリング間隔：これは、2の指数として使用される8ビットの符号なし整数です。結果の値は、秒単位の連続するメッセージ間の最大間隔です。このフィールドは、値が4（16秒）から17（131,072秒-約36時間）の範囲のSNTPサーバーメッセージでのみ重要です。
Precision: This is an eight-bit signed integer used as an exponent of two, where the resulting value is the precision of the system clock in seconds. This field is significant only in server messages, where the values range from -6 for mains-frequency clocks to -20 for microsecond clocks found in some workstations.
精度：これは、2の指数として使用される8ビットの符号付き整数で、結果の値はシステムクロックの精度（秒単位）です。このフィールドは、一部のワークステーションにある主周波数クロックの-6からマイクロ秒クロックの-20までの値の範囲のサーバーメッセージでのみ重要です。
Root Delay: This is a 32-bit signed fixed-point number indicating the total roundtrip delay to the primary reference source, in seconds with the fraction point between bits 15 and 16. Note that this variable can take on both positive and negative values, depending on the relative time and frequency offsets. This field is significant only in server messages, where the values range from negative values of a few milliseconds to positive values of several hundred milliseconds.
ルート遅延：これは32ビットの符号付き固定小数点数で、ビット15と16の間の小数ポイントを使用して秒単位でプライマリリファレンスソースへの総往復遅延を示します。この変数は正と負の両方の値を取ることができます。相対時間と周波数オフセットに依存します。このフィールドは、値が数ミリ秒の負の値から数百ミリ秒の正の値までの範囲であるサーバーメッセージでのみ重要です。
Code External Reference Source
------------------------------------------------------------------
LOCL uncalibrated local clock
CESM calibrated Cesium clock
RBDM calibrated Rubidium clock
PPS calibrated quartz clock or other pulse-per-second
source
IRIG Inter-Range Instrumentation Group
ACTS NIST telephone modem service
USNO USNO telephone modem service
PTB PTB (Germany) telephone modem service
TDF Allouis (France) Radio 164 kHz
DCF Mainflingen (Germany) Radio 77.5 kHz
MSF Rugby (UK) Radio 60 kHz
WWV Ft. Collins (US) Radio 2.5, 5, 10, 15, 20 MHz
WWVB Boulder (US) Radio 60 kHz
WWVH Kauai Hawaii (US) Radio 2.5, 5, 10, 15 MHz
CHU Ottawa (Canada) Radio 3330, 7335, 14670 kHz
LORC LORAN-C radionavigation system
OMEG OMEGA radionavigation system
GPS Global Positioning Service
Figure 2. Reference Identifier Codes
図2.参照IDコード
Root Dispersion: This is a 32-bit unsigned fixed-point number indicating the maximum error due to the clock frequency tolerance, in seconds with the fraction point between bits 15 and 16. This field is significant only in server messages, where the values range from zero to several hundred milliseconds.
ルート分散：これは、クロック周波数許容誤差による最大エラーを示す32ビットの符号なし固定小数点数であり、ビット15と16の間の小数ポイントで秒単位です。このフィールドは、値の範囲であるサーバーメッセージでのみ重要ですゼロから数百ミリ秒まで。
Reference Identifier: This is a 32-bit bitstring identifying the particular reference source. This field is significant only in server messages, where for stratum 0 (kiss-o'-death message) and 1 (primary server), the value is a four-character ASCII string, left justified and zero padded to 32 bits. For IPv4 secondary servers, the value is the 32-bit IPv4 address of the synchronization source. For IPv6 and OSI secondary servers, the value is the first 32 bits of the MD5 hash of the IPv6 or NSAP address of the synchronization source.
参照識別子：これは、特定の参照ソースを識別する32ビットのビット文字列です。このフィールドはサーバーメッセージでのみ重要です。ストラタム0（kiss-o'-deathメッセージ）および1（プライマリサーバー）の場合、値は4文字のASCII文字列で、左揃えされ、32ビットにゼロが埋め込まれます。 IPv4セカンダリサーバーの場合、値は同期ソースの32ビットIPv4アドレスです。 IPv6およびOSIセカンダリサーバーの場合、値は、同期ソースのIPv6またはNSAPアドレスのMD5ハッシュの最初の32ビットです。
Primary (stratum 1) servers set this field to a code identifying the external reference source according to Figure 2. If the external reference is one of those listed, the associated code should be used. Codes for sources not listed can be contrived, as appropriate.
プライマリ（層1）サーバーは、このフィールドを図2に従って外部参照ソースを識別するコードに設定します。外部参照がリストされているものの1つである場合、関連するコードを使用する必要があります。リストされていないソースのコードは、必要に応じて工夫できます。
In previous NTP and SNTP secondary servers and clients, this field was often used to walk-back the synchronization subnet to the root (primary server) for management purposes. In SNTPv4 with IPv6 or OSI, this feature is not available, because the addresses are longer than 32 bits, and only a hash is available. However, a walk-back can be accomplished using the NTP control message and the reference identifier field described in RFC 1305.
以前のNTPおよびSNTPセカンダリサーバーとクライアントでは、このフィールドは、管理目的で同期サブネットをルート（プライマリサーバー）にウォークバックするためによく使用されていました。 IPv6またはOSIを使用するSNTPv4では、アドレスが32ビットより長く、ハッシュしか使用できないため、この機能は使用できません。ただし、ウォークバックは、NTP制御メッセージとRFC 1305に記載されている参照識別子フィールドを使用して実行できます。
Reference Timestamp: This field is the time the system clock was last set or corrected, in 64-bit timestamp format.
参照タイムスタンプ：このフィールドは、システムクロックが最後に設定または修正された時刻で、64ビットのタイムスタンプ形式です。
Originate Timestamp: This is the time at which the request departed the client for the server, in 64-bit timestamp format.
Originate Timestamp：これは、64ビットのタイムスタンプ形式で、リクエストがサーバーのクライアントを出発した時間です。
Receive Timestamp: This is the time at which the request arrived at the server or the reply arrived at the client, in 64-bit timestamp format.
受信タイムスタンプ：これは、リクエストがサーバーに到着した時刻、または応答がクライアントに到着した時刻で、64ビットのタイムスタンプ形式です。
Transmit Timestamp: This is the time at which the request departed the client or the reply departed the server, in 64-bit timestamp format.
送信タイムスタンプ：これは、64ビットのタイムスタンプ形式で、要求がクライアントを出発した時刻または応答がサーバーを出発した時刻です。
Authenticator (optional): When the NTP authentication scheme is implemented, the Key Identifier and Message Digest fields contain the message authentication code (MAC) information defined in Appendix C of RFC 1305.
オーセンティケーター（オプション）：NTP認証スキームが実装されている場合、キーIDおよびメッセージダイジェストフィールドには、RFC 1305の付録Cで定義されているメッセージ認証コード（MAC）情報が含まれます。
An SNTP client can operate in unicast, broadcast, or manycast modes. In unicast mode, the client sends a request (NTP mode 3) to a designated unicast server and expects a reply (NTP mode 4) from that server. In broadcast client mode, it sends no request and waits for a broadcast (NTP mode 5) from one or more broadcast servers. In manycast mode, the client sends a request (NTP mode 3) to a designated broadcast address and expects a reply (NTP mode 4) from one or more manycast servers. The client uses the first reply received to establish the particular server for subsequent unicast operations. Later replies from this server (duplicates) or any other server are ignored. Other than the selection of address in the request, the operations of manycast and unicast clients are identical.
SNTPクライアントは、ユニキャスト、ブロードキャスト、またはメニーキャストモードで動作できます。ユニキャストモードでは、クライアントは指定されたユニキャストサーバーに要求（NTPモード3）を送信し、そのサーバーからの応答（NTPモード4）を予期します。ブロードキャストクライアントモードでは、要求を送信せず、1つ以上のブロードキャストサーバーからのブロードキャスト（NTPモード5）を待ちます。メニーキャストモードでは、クライアントは指定されたブロードキャストアドレスに要求（NTPモード3）を送信し、1つ以上のメニーキャストサーバーからの応答（NTPモード4）を予期します。クライアントは、受信した最初の応答を使用して、後続のユニキャスト操作のために特定のサーバーを確立します。その後、このサーバー（重複）または他のサーバーからの応答は無視されます。リクエストでのアドレスの選択を除いて、メニーキャストクライアントとユニキャストクライアントの操作は同じです。
Client requests are normally sent at intervals depending on the frequency tolerance of the client clock and the required accuracy. However, under no conditions should requests be sent at less than one minute intervals. Further discussion on this point is in Section 9.
クライアント要求は通常、クライアントクロックの周波数許容度と必要な精度に応じて、一定の間隔で送信されます。ただし、どのような状況でも、要求が1分未満の間隔で送信されることはありません。この点については、セクション9で詳しく説明します。
A unicast or manycast client initializes the NTP message header, sends the request to the server, and strips the time of day from the Transmit Timestamp field of the reply. For this purpose, all the NTP header fields shown above are set to 0, except the Mode, VN, and optional Transmit Timestamp fields.
ユニキャストまたはメニーキャストクライアントは、NTPメッセージヘッダーを初期化し、要求をサーバーに送信し、応答の[送信タイムスタンプ]フィールドから時刻を取り除きます。この目的のため、上記のすべてのNTPヘッダーフィールドは、モード、VN、およびオプションの送信タイムスタンプフィールドを除き、0に設定されています。
NTP and SNTP clients set the mode field to 3 (client) for unicast and manycast requests. They set the VN field to any version number that is supported by the server, selected by configuration or discovery, and that can interoperate with all previous version NTP and SNTP servers. Servers reply with the same version as the request, so the VN field of the request also specifies the VN field of the reply. A prudent SNTP client can specify the earliest acceptable version on the expectation that any server of that or a later version will respond. NTP Version 3 (RFC 1305) and Version 2 (RFC 1119) servers accept all previous versions, including Version 1 (RFC 1059). Note that Version 0 (RFC 959) is no longer supported by current and future NTP and SNTP servers.
NTPおよびSNTPクライアントは、ユニキャストおよびメニーキャスト要求のモードフィールドを3（クライアント）に設定します。それらは、VNフィールドを、サーバーでサポートされ、構成またはディスカバリーによって選択され、以前のすべてのバージョンのNTPおよびSNTPサーバーと相互運用できる任意のバージョン番号に設定します。サーバーは要求と同じバージョンで応答するため、要求のVNフィールドは応答のVNフィールドも指定します。賢明なSNTPクライアントは、それ以降のバージョンのサーバーが応答することを期待して、受け入れ可能な最も古いバージョンを指定できます。 NTPバージョン3（RFC 1305）およびバージョン2（RFC 1119）サーバーは、バージョン1（RFC 1059）を含む以前のすべてのバージョンを受け入れます。バージョン0（RFC 959）は、現在および将来のNTPおよびSNTPサーバーでサポートされなくなったことに注意してください。
Although setting the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format is not necessary in a conforming client implementation, it is highly recommended in unicast and manycast modes. This allows a simple calculation to determine the propagation delay between the server and client and to align the system clock generally within a few tens of milliseconds relative to the server. In addition, this provides a simple method for verifying that the server reply is in fact a legitimate response to the specific client request and thereby for avoiding replays. In broadcast mode, the client has no information to calculate the propagation delay or to determine the validity of the server, unless one of the NTP authentication schemes is used.
要求のTransmit Timestampフィールドを、NTPタイムスタンプ形式のクライアントクロックに応じた時刻に設定することは、適合クライアントの実装では必要ありませんが、ユニキャストモードおよびメニーキャストモードでは強く推奨されます。これにより、簡単な計算でサーバーとクライアント間の伝播遅延を決定し、システムクロックをサーバーに対して通常数十ミリ秒以内に合わせることができます。さらに、これは、サーバーの応答が実際に特定のクライアント要求に対する正当な応答であることを確認し、それによってリプレイを回避するための簡単な方法を提供します。ブロードキャストモードでは、NTP認証方式のいずれかが使用されていない限り、クライアントには伝播遅延を計算したり、サーバーの有効性を判断したりするための情報がありません。
To calculate the roundtrip delay d and system clock offset t relative to the server, the client sets the Transmit Timestamp field in the request to the time of day according to the client clock in NTP timestamp format. For this purpose, the clock need not be synchronized. The server copies this field to the Originate Timestamp in the reply and sets the Receive Timestamp and Transmit Timestamp fields to the time of day according to the server clock in NTP timestamp format.
サーバーに対するラウンドトリップ遅延dおよびシステムクロックオフセットtを計算するために、クライアントは、NTPタイムスタンプ形式のクライアントクロックに従って、要求の送信タイムスタンプフィールドを時刻に設定します。このため、クロックを同期させる必要はありません。サーバーは、このフィールドを応答のOriginate Timestampにコピーし、NTPタイムスタンプ形式のサーバークロックに従って、Receive TimestampおよびTransmit Timestampフィールドに時刻を設定します。
When the server reply is received, the client determines a Destination Timestamp variable as the time of arrival according to its clock in NTP timestamp format. The following table summarizes the four timestamps.
サーバーの応答を受信すると、クライアントは、NTPタイムスタンプ形式のクロックに従って、Destination Timestamp変数を到着時刻として決定します。次の表は、4つのタイムスタンプをまとめたものです。
Timestamp Name ID When Generated
------------------------------------------------------------
Originate Timestamp T1 time request sent by client
Receive Timestamp T2 time request received by server
Transmit Timestamp T3 time reply sent by server
Destination Timestamp T4 time reply received by client
The roundtrip delay d and system clock offset t are defined as:
往復遅延dおよびシステムクロックオフセットtは、次のように定義されます。
d = (T4 - T1) - (T3 - T2) t = ((T2 - T1) + (T3 - T4)) / 2.
Note that in general both delay and offset are signed quantities and can be less than zero; however, a delay less than zero is possible only in symmetric modes, which SNTP clients are forbidden to use. The following table summarizes the required SNTP client operations in unicast, manycast, and broadcast modes. The recommended error checks are shown in the Reply and Broadcast columns in the table. The message should be considered valid only if all the fields shown contain values in the respective ranges. Whether to believe the message if one or more of the fields marked "ignore" contain invalid values is at the discretion of the implementation.
一般に、遅延とオフセットはどちらも符号付きの量であり、ゼロ未満になる可能性があることに注意してください。ただし、ゼロ未満の遅延は、SNTPクライアントが使用を禁止されている対称モードでのみ可能です。次の表は、ユニキャスト、メニーキャスト、およびブロードキャストの各モードで必要なSNTPクライアント操作をまとめたものです。推奨されるエラーチェックは、表の[返信]および[ブロードキャスト]列に表示されます。メッセージは、表示されているすべてのフィールドにそれぞれの範囲の値が含まれている場合にのみ有効と見なされます。 「無視」とマークされた1つ以上のフィールドに無効な値が含まれている場合にメッセージを信じるかどうかは、実装の裁量に委ねられています。
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
VN 1-4 copied from 1-4 request
1-4リクエストからコピーされたVN 1-4
Mode 3 4 5
モード3 4 5
Stratum 0 0-15 0-15
層0 0-15 0-15
Poll 0 ignore ignore
投票0無視無視
Precision 0 ignore ignore
精度0無視無視
Root Delay 0 ignore ignore
ルート遅延0無視無視
Root Dispersion 0 ignore ignore
ルート分散0無視無視
Reference Identifier 0 ignore ignore
参照識別子0無視無視
Reference Timestamp 0 ignore ignore
参照タイムスタンプ0無視無視
Originate Timestamp 0 (see text) ignore
元のタイムスタンプ0（テキストを参照）無視
Receive Timestamp 0 (see text) ignore
受信タイムスタンプ0（テキストを参照）無視
Transmit Timestamp (see text) nonzero nonzero
送信タイムスタンプ（テキストを参照）非ゼロ非ゼロ
Authenticator optional optional optional
オーセンティケーターオプションオプションオプション
Although not required in a conforming SNTP client implementation, it is wise to consider a suite of sanity checks designed to avoid various kinds of abuse that might happen as the result of server implementation errors or malicious attack. Following is a list of suggested checks.
準拠するSNTPクライアント実装では必須ではありませんが、サーバー実装エラーまたは悪意のある攻撃の結果として発生する可能性のあるさまざまな種類の悪用を回避するように設計された一連の健全性チェックを検討することをお勧めします。以下は、推奨されるチェックのリストです。
1. When the IP source and destination addresses are available for the client request, they should match the interchanged addresses in the server reply.
1. IPの送信元アドレスと宛先アドレスがクライアント要求で使用できる場合、それらはサーバー応答で交換されたアドレスと一致する必要があります。
2. When the UDP source and destination ports are available for the client request, they should match the interchanged ports in the server reply.
2. UDPの送信元ポートと宛先ポートがクライアント要求に使用できる場合、それらはサーバー応答の交換されたポートと一致する必要があります。
3. The Originate Timestamp in the server reply should match the Transmit Timestamp used in the client request.
3. サーバー応答のOriginate Timestampは、クライアント要求で使用される送信タイムスタンプと一致する必要があります。
4. The server reply should be discarded if any of the LI, Stratum, or Transmit Timestamp fields is 0 or the Mode field is not 4 (unicast) or 5 (broadcast).
4. LI、Stratum、またはTransmit Timestampフィールドのいずれかが0であるか、Modeフィールドが4（ユニキャスト）または5（ブロードキャスト）でない場合、サーバー応答は破棄されます。
5. A truly paranoid client can check that the Root Delay and Root Dispersion fields are each greater than or equal to 0 and less than infinity, where infinity is currently a cozy number like one second. This check avoids using a server whose synchronization source has expired for a very long time.
5. 真にパラノイアなクライアントは、Root DelayおよびRoot Dispersionフィールドがそれぞれ0以上で無限大未満であることを確認できます。現在、無限大は1秒のような居心地の良い数値です。このチェックにより、同期ソースの有効期限が非常に長いサーバーを使用しないようにします。
A SNTP server operating with either an NTP or SNTP client of the same or previous versions retains no persistent state. Because an SNTP server ordinarily does not implement the full suite of grooming and mitigation algorithms intended to support redundant servers and diverse network paths, it should be operated only in conjunction with a source of external synchronization, such as a reliable radio clock or telephone modem. In this case it operates as a primary (stratum 1) server.
同じまたは以前のバージョンのNTPまたはSNTPクライアントのいずれかで動作するSNTPサーバーは、永続的な状態を保持しません。 SNTPサーバーは通常、冗長サーバーと多様なネットワークパスをサポートすることを目的としたグルーミングと軽減アルゴリズムの完全なスイートを実装していないため、信頼できるラジオクロックや電話モデムなどの外部同期のソースと組み合わせてのみ動作させる必要があります。この場合、プライマリ（層1）サーバーとして動作します。
A SNTP server can operate with any unicast, manycast, or broadcast address or any combination of these addresses. A unicast or manycast server receives a request (NTP mode 3), modifies certain fields in the NTP header, and sends a reply (NTP mode 4), possibly using the same message buffer as the request. A manycast server listens on the designated broadcast address, but uses its own unicast IP address in the source address field of the reply. Other than the selection of address in the reply, the operations of manycast and unicast servers are identical. Broadcast messages are normally sent at intervals from 64 s to 1024 s, depending on the expected frequency tolerance of the client clocks and the required accuracy.
SNTPサーバーは、任意のユニキャスト、メニーキャスト、ブロードキャストアドレス、またはこれらのアドレスの任意の組み合わせで動作できます。ユニキャストサーバーまたはメニーキャストサーバーは、要求を受信し（NTPモード3）、NTPヘッダーの特定のフィールドを変更し、応答を送信します（NTPモード4）。おそらく、要求と同じメッセージバッファーを使用します。メニーキャストサーバーは、指定されたブロードキャストアドレスをリッスンしますが、応答の送信元アドレスフィールドに独自のユニキャストIPアドレスを使用します。応答でのアドレスの選択を除いて、メニーキャストサーバーとユニキャストサーバーの操作は同じです。ブロードキャストメッセージは通常、クライアントクロックの予想される周波数許容度と必要な精度に応じて、64秒から1024秒の間隔で送信されます。
Unicast and manycast servers copy the VN and Poll fields of the request intact to the reply and set the Stratum field to 1.
ユニキャストサーバーとメニーキャストサーバーは、要求のVNフィールドとPollフィールドをそのまま応答にコピーし、Stratumフィールドを1に設定します。
Note that SNTP servers normally operate as primary (stratum 1) servers. Although operating at higher strata (up to 15) while synchronizing to an external source such as a GPS receiver is not forbidden, this is strongly discouraged.
SNTPサーバーは通常、プライマリ（層1）サーバーとして動作することに注意してください。 GPSレシーバーなどの外部ソースと同期しているときに上位層（最大15）で動作することは禁止されていませんが、これは強くお勧めしません。
If the Mode field of the request is 3 (client), the reply is set to 4 (server). If this field is set to 1 (symmetric active), the reply is set to 2 (symmetric passive). This allows clients configured in either client (NTP mode 3) or symmetric active (NTP mode 1) to interoperate successfully, even if configured in possibly suboptimal ways. For any other value in the Mode field, the request is discarded. In broadcast (unsolicited) mode, the VN field is set to 4, the Mode field is set to 5 (broadcast), and the Poll field set to the nearest integer base-2 logarithm of the poll interval.
要求のModeフィールドが3（クライアント）の場合、応答は4（サーバー）に設定されます。このフィールドが1（対称アクティブ）に設定されている場合、応答は2（対称パッシブ）に設定されます。これにより、クライアント（NTPモード3）または対称アクティブ（NTPモード1）のいずれかで構成されたクライアントが、準最適な方法で構成されていても、正常に相互運用できます。 Modeフィールドのその他の値の場合、要求は破棄されます。ブロードキャスト（非送信請求）モードでは、VNフィールドは4に設定され、Modeフィールドは5（ブロードキャスト）に設定され、Pollフィールドはポーリング間隔の最も近い整数の2対数に設定されます。
Note that it is highly desirable that a broadcast server also supports unicast clients. This is so a potential broadcast client can calculate the propagation delay using a client/server exchange prior to switching to broadcast client (listen-only) mode. By design, a manycast server is also a unicast server. There does not seem to be a great advantage for a server to operate as both broadcast and manycast at the same time, although the protocol specification does not forbid it.
ブロードキャストサーバーがユニキャストクライアントもサポートすることが非常に望ましいことに注意してください。これは、潜在的なブロードキャストクライアントが、ブロードキャストクライアント（リッスンのみ）モードに切り替える前に、クライアント/サーバー交換を使用して伝播遅延を計算できるようにするためです。設計上、メニーキャストサーバーはユニキャストサーバーでもあります。プロトコル仕様では禁止されていませんが、サーバーがブロードキャストとメニーキャストの両方として同時に動作することには大きな利点はないようです。
A broadcast or manycast server does not send packets if not synchronized to a correctly operating reference source. It may or may not respond to a client request if it is not synchronized, but the preferred option is to respond because this allows reachability to be determined regardless of synchronization state. If the server has never synchronized to a reference source, the LI field is set to 3 (unsynchronized). Once synchronized to a reference source, the LI field is set to one of the other three values and remains at the last value set even if the reference source becomes unreachable or turns faulty.
ブロードキャストサーバーまたはメニーキャストサーバーは、正しく動作している参照ソースと同期していない場合、パケットを送信しません。同期されていない場合、クライアント要求に応答する場合と応答しない場合がありますが、同期状態に関係なく到達可能性を判別できるため、応答することをお勧めします。サーバーが参照ソースに同期したことがない場合、LIフィールドは3（非同期）に設定されます。参照ソースに同期すると、LIフィールドは他の3つの値のいずれかに設定され、参照ソースが到達不能になったり障害が発生したりした場合でも、最後に設定された値のままになります。
If the server is synchronized to a reference source, the Stratum field is set to 1, and the Reference Identifier field is set to the ASCII source identifier shown in Figure 2. If the server is not synchronized, the Stratum field is set to zero, and the Reference Identifier field is set to an ASCII error identifier described below.
サーバーが参照ソースと同期している場合、Stratumフィールドは1に設定され、Reference Identifierフィールドは図2に示すASCIIソースIDに設定されます。サーバーが同期していない場合、Stratumフィールドはゼロに設定されます。参照識別子フィールドは、以下で説明するASCIIエラー識別子に設定されます。
The Precision field is set to reflect the maximum reading error of the system clock. For all practical cases it is computed as the negative base-2 logarithm of the number of significant bits to the right of the decimal point in the NTP timestamp format. The Root Delay and Root Dispersion fields are set to 0 for a primary server.
Precisionフィールドは、システムクロックの最大読み取りエラーを反映するように設定されます。実際のすべてのケースでは、NTPタイムスタンプ形式の小数点の右側の有効ビット数の負の2を底とする対数として計算されます。プライマリサーバーのRoot DelayおよびRoot Dispersionフィールドは0に設定されています。
The timestamp fields in the server message are set as follows. If the server is unsynchronized or first coming up, all timestamp fields are set to zero, with one exception. If the message is a reply to a previously received client request, the Transmit Timestamp field of the request is copied unchanged to the Originate Timestamp field of the reply. It is important that this field be copied intact, as an NTP or SNTP client uses it to avoid bogus messages.
サーバーメッセージのタイムスタンプフィールドは次のように設定されます。サーバーが同期していないか最初に起動する場合、1つの例外を除いて、すべてのタイムスタンプフィールドがゼロに設定されます。メッセージが以前に受信したクライアント要求への応答である場合、要求の送信タイムスタンプフィールドは変更されずに、応答の[元のタイムスタンプ]フィールドにコピーされます。 NTPまたはSNTPクライアントは偽のメッセージを回避するためにこのフィールドを使用するため、このフィールドをそのままコピーすることが重要です。
If the server is synchronized, the Reference Timestamp is set to the time the last update was received from the reference source. The Originate Timestamp field is set as in the unsynchronized case above. The Transmit Timestamp field is set to the time of day when the message is sent. In broadcast messages the Receive Timestamp field is set to zero and copied from the Transmit Timestamp field in other messages. The following table summarizes these actions.
サーバーが同期されている場合、参照タイムスタンプは、参照ソースから最後の更新を受信した時刻に設定されます。 Originate Timestampフィールドは、上記の非同期の場合と同様に設定されます。 Transmit Timestampフィールドは、メッセージが送信された時刻に設定されます。ブロードキャストメッセージでは、Receive Timestampフィールドはゼロに設定され、他のメッセージのTransmit Timestampフィールドからコピーされます。次の表は、これらのアクションをまとめたものです。
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
VN 1-4 copied from 4 request
4リクエストからコピーされたVN 1-4
Mode 3 4 5
モード3 4 5
Stratum ignore 1 1
層無視1 1
Poll ignore copied from log2 poll request interval
log2ポーリング要求間隔からコピーされたポーリング無視
Precision ignore -log2 server -log2 server significant significant bits bits
精度無視-log2サーバー-log2サーバーの有効ビット
Root Delay ignore 0 0
ルート遅延無視0 0
Root Dispersion ignore 0 0
ルート分散は無視する0 0
Reference Identifier ignore source ident source ident
参照識別子はソースIDを無視するソースID
Reference Timestamp ignore time of last time of last source update source update
参照タイムスタンプは、最後のソース更新ソース更新の最後の時間の無視時間
Originate Timestamp ignore copied from 0 transmit timestamp
0送信タイムスタンプからコピーされた元のタイムスタンプ無視
Receive Timestamp ignore time of day 0
タイムスタンプ無視の受信時刻0
Transmit Timestamp (see text) time of day time of day
送信タイムスタンプ（テキストを参照）時刻時刻
Authenticator optional optional optional
オーセンティケーターオプションオプションオプション
There is some latitude on the part of most clients to forgive invalid timestamps, such as might occur when the server is first coming up or during periods when the reference source is inoperative. The most important indicator of an unhealthy server is the Stratum field, in which a value of 0 indicates an unsynchronized condition. When this value is displayed, clients should discard the server message, regardless of the contents of other fields.
ほとんどのクライアントは、サーバーが最初に起動したときや、参照ソースが動作していないときに発生する可能性があるなど、無効なタイムスタンプを許す余裕があります。異常なサーバーの最も重要なインジケーターはStratumフィールドです。このフィールドでは、値0は非同期状態を示します。この値が表示される場合、クライアントは他のフィールドの内容に関係なく、サーバーメッセージを破棄する必要があります。
Initial setup for SNTP servers and clients can be done using a web client, if available, or a serial port, if not. Some folks hoped that in-service management of NTP and SNTPv4 servers and clients could be performed using SNMP and a suitable MIB to be published, and this has happened in some commercial SNTP servers. But, the means that have been used in the last two decades and probably will be used in the next is the NTP control and monitoring protocol defined in RFC 1305. Ordinarily, SNTP servers and clients are expected to operate with little or no site-specific configuration, other than specifying the client IP address, subnet mask, and gateway.
SNTPサーバーとクライアントの初期設定は、Webクライアント（利用可能な場合）またはシリアルポート（利用できない場合）を使用して行うことができます。一部の人々は、NTPおよびSNTPv4サーバーとクライアントのインサービス管理が、SNMPと適切なMIBを使用して実行できることを望んでおり、これは一部の商用SNTPサーバーで発生しました。ただし、過去20年間に使用されてきたものであり、おそらく今後使用されるであろう手段は、RFC 1305で定義されているNTP制御および監視プロトコルです。通常、SNTPサーバーおよびクライアントは、サイト固有の機能がほとんどまたはまったくない状態で動作することが予想されます。クライアントIPアドレス、サブネットマスク、ゲートウェイを指定する以外の構成。
Unicast clients must be provided with one or more designated server names or IP addresses. If more than one server is provided, one can be used for active operation and one of the others for backup should the active one fail or show an error condition. It is not normally useful to use more than one server at a time, as with millions of SNTP-enabled devices expected in the near future, such use would represent unnecessary drain on network and server resources.
ユニキャストクライアントには、1つ以上の指定されたサーバー名またはIPアドレスを提供する必要があります。複数のサーバーが提供されている場合、1つをアクティブな操作に使用し、他のサーバーの1つをアクティブなサーバーに障害が発生したりエラー状態が発生した場合のバックアップに使用したりできます。近い将来に数百万のSNTP対応デバイスが予想されるため、このような使用はネットワークおよびサーバーリソースの不要な浪費を表すため、通常は一度に複数のサーバーを使用することは役に立ちません。
Broadcast servers and manycast clients must be provided with the TTL and local broadcast or multicast group address. Unicast and manycast servers and broadcast clients may be configured with a list of address-mask pairs for access control, so that only those clients or servers known to be trusted will be accepted. Multicast servers and clients must implement the IGMP protocol and be provided with the local broadcast or multicast group address as well. The configuration data for cryptographic authentication is beyond the scope of this memo.
ブロードキャストサーバーとメニーキャストクライアントには、TTLとローカルブロードキャストまたはマルチキャストグループアドレスを提供する必要があります。ユニキャストサーバーとメニーキャストサーバー、およびブロードキャストクライアントは、アクセス制御用のアドレスマスクペアのリストを使用して構成できるため、信頼されていることがわかっているクライアントまたはサーバーのみが受け入れられます。マルチキャストサーバーとクライアントは、IGMPプロトコルを実装し、ローカルブロードキャストまたはマルチキャストグループアドレスも提供する必要があります。暗号認証の構成データは、このメモの範囲を超えています。
There are several scenarios that provide automatic server discovery and selection for SNTP clients with no pre-specified server configuration. For instance, a role server with CNAME such as pool.ntp.org returns a randomized list of volunteer secondary server addresses, and the client can select one or more as candidates. For an IP subnet or LAN segment including an NTP or SNTP server, SNTP clients can be configured as broadcast clients. The same approach can be used with multicast servers and clients. In both cases, provision of an access control list is a good way to ensure that only trusted sources can be used to set the system clock.
事前に指定されたサーバー構成のないSNTPクライアントに自動サーバー検出と選択を提供するいくつかのシナリオがあります。たとえば、pool.ntp.orgなどのCNAMEを持つ役割サーバーは、ボランティアのセカンダリサーバーアドレスのランダムなリストを返し、クライアントは1つ以上を候補として選択できます。 NTPまたはSNTPサーバーを含むIPサブネットまたはLANセグメントの場合、SNTPクライアントをブロードキャストクライアントとして構成できます。同じアプローチをマルチキャストサーバーとクライアントで使用できます。どちらの場合も、アクセス制御リストを提供することは、信頼できるソースのみを使用してシステムクロックを設定できるようにするための優れた方法です。
In another scenario suitable for an extended network with significant network propagation delays, clients can be configured for manycast addresses, both upon initial startup and after some period when the currently selected unicast source has not been heard. Following the defined protocol, the client binds to the server from which the first reply is received and continues operation in unicast mode.
ネットワークの伝播遅延が大きい拡張ネットワークに適した別のシナリオでは、クライアントは、最初の起動時と、現在選択されているユニキャストソースが聞こえない一定期間後の両方で、メニーキャストアドレス用に構成できます。定義されたプロトコルに従って、クライアントは最初の応答を受信したサーバーにバインドし、ユニキャストモードで操作を続行します。
In the rambunctious Internet of today, it is imperative that some means be available to tell a client to stop making requests and to go somewhere else. A recent experience involved a large number of home/office routers all configured to use a particular university time server. Under some error conditions, a substantial fraction of these routers would send packets at intervals of one second. The resulting traffic spike was dramatic, and extreme measures were required to diagnose the problem and to bring it under control. The conclusion is that clients must respect the means available to targeted servers to stop them from sending packets.
今日の騒々しいインターネットでは、クライアントにリクエストの作成を中止し、別の場所に移動するように伝えるための手段が利用可能であることが不可欠です。最近の経験では、特定の大学のタイムサーバーを使用するように構成された多数のホーム/オフィスルーターが関係していました。一部のエラー状態では、これらのルーターのかなりの部分が1秒間隔でパケットを送信します。結果として生じるトラフィックの急増は劇的であり、問題を診断してそれを制御するためには、極端な対策が必要でした。結論として、クライアントは、ターゲットサーバーが利用できる手段を尊重して、パケットを送信しないようにする必要があります。
According to the NTP specification RFC 1305, if the Stratum field in the NTP header is 1, indicating a primary server, the Reference Identifier field contains an ASCII string identifying the particular reference clock type. However, in RFC 1305 nothing is said about the Reference Identifier field if the Stratum field is 0, which is called out as "unspecified". However, if the Stratum field is 0, the Reference Identifier field can be used to convey messages useful for status reporting and access control. In NTPv4 and SNTPv4, packets of this kind are called Kiss-o'-Death (KoD) packets, and the ASCII messages they convey are called kiss codes. The KoD packets got their name because an early use was to tell clients to stop sending packets that violate server access controls.
NTP仕様RFC 1305によると、NTPヘッダーのStratumフィールドが1であり、プライマリサーバーを示している場合、参照識別子フィールドには、特定の参照クロックタイプを識別するASCII文字列が含まれます。ただし、RFC 1305では、Stratumフィールドが0の場合、Reference Identifierフィールドについては何も言われていません。これは「未指定」と呼ばれています。ただし、Stratumフィールドが0の場合、参照識別子フィールドを使用して、ステータスレポートとアクセス制御に役立つメッセージを伝えることができます。 NTPv4およびSNTPv4では、この種のパケットはKiss-o'-Death（KoD）パケットと呼ばれ、それらが伝達するASCIIメッセージはキスコードと呼ばれます。 KoDパケットの名前は、初期の用途がサーバーのアクセス制御に違反するパケットの送信を停止するようにクライアントに指示することであったためです。
In general, an SNTP client should stop sending to a particular server if that server returns a reply with a Stratum field of 0, regardless of kiss code, and an alternate server is available. If no alternate server is available, the client should retransmit using an exponential-backoff algorithm described in the next section.
一般に、SNTPクライアントは、特定のサーバーがキスコードに関係なく、Stratumフィールドが0の応答を返し、代替サーバーが使用可能な場合、そのサーバーへの送信を停止する必要があります。代替サーバーが利用できない場合、クライアントは次のセクションで説明する指数バックオフアルゴリズムを使用して再送信する必要があります。
The kiss codes can provide useful information for an intelligent client. These codes are encoded in four-character ASCII strings left justified and zero filled. The strings are designed for character displays and log files. Usually, only a few of these codes can occur with SNTP clients, including DENY, RSTR, and RATE. Others can occur more rarely, including INIT and STEP, when the server is in some special temporary condition. Figure 3 shows a list of the kiss codes currently defined. These are for informational purposes only; the list might be modified or extended in the future.
キスコードは、インテリジェントクライアントに役立つ情報を提供します。これらのコードは、4文字のASCII文字列でエンコードされ、左揃えされ、ゼロで埋められます。文字列は、文字表示とログファイル用に設計されています。通常、DENY、RSTR、RATEなど、SNTPクライアントで発生する可能性のあるコードはごくわずかです。サーバーが特別な一時的な状態にあるときに、INITやSTEPを含むその他の問題が発生することはまれです。図3に、現在定義されているキスコードのリストを示します。これらは情報提供のみを目的としています。リストは将来変更または拡張される可能性があります。
Code Meaning
--------------------------------------------------------------
ACST The association belongs to a anycast server
AUTH Server authentication failed
AUTO Autokey sequence failed
BCST The association belongs to a broadcast server
CRYP Cryptographic authentication or identification failed
DENY Access denied by remote server
DROP Lost peer in symmetric mode
RSTR Access denied due to local policy
INIT The association has not yet synchronized for the first
time
MCST The association belongs to a manycast server
NKEY No key found. Either the key was never installed or
is not trusted
RATE Rate exceeded. The server has temporarily denied access
because the client exceeded the rate threshold
RMOT Somebody is tinkering with the association from a remote
host running ntpdc. Not to worry unless some rascal has
stolen your keys
STEP A step change in system time has occurred, but the
association has not yet resynchronized
Figure 3. Kiss Codes
図3.キスコード
SNTP and its big brother NTP have been in explosive growth over the last few years, mirroring the growth of the Internet. Just about every Internet appliance has some kind of NTP support, including Windows XP, Cisco routers, embedded controllers, and software systems of all kinds. This is the first edition of the SNTP RFC where it has become necessary to lay down rules of engagement in the form of design criteria for SNTP client implementations. This is necessary to educate software developers regarding the proper use of Internet time server resources as the Internet expands and demands on time servers increase, and to prevent the recurrence of the sort of problem mentioned above.
SNTPとその兄弟であるNTPは、インターネットの成長を反映して、ここ数年で爆発的に成長しています。ほぼすべてのインターネットアプライアンスは、Windows XP、Ciscoルーター、組み込みコントローラー、あらゆる種類のソフトウェアシステムなど、何らかの種類のNTPサポートを備えています。これはSNTP RFCの最初の版であり、SNTPクライアント実装の設計基準の形式で関与規則を規定することが必要になりました。これは、インターネットの拡大とタイムサーバーに対する要求の増加に伴うインターネットタイムサーバーリソースの適切な使用についてソフトウェア開発者を教育し、上記のような問題の再発を防ぐために必要です。
NTP and SNTP clients can consume considerable network and server resources if they are not good network citizens. There are now consumer Internet commodity devices numbering in the millions that are potential customers of public and private NTP and SNTP servers. Recent experience strongly suggests that device designers pay particular attention to minimizing resource impacts, especially if large numbers of these devices are deployed. The most important design consideration is the interval between client requests, called the poll interval. It is extremely important that the design use the maximum poll interval consistent with acceptable accuracy.
NTPおよびSNTPクライアントは、ネットワークの市民でないと、かなりのネットワークおよびサーバーリソースを消費する可能性があります。現在、数百万に上る民生用インターネット商品デバイスがあり、パブリックおよびプライベートNTPおよびSNTPサーバーの潜在的な顧客です。最近の経験では、特にこれらのデバイスが多数導入されている場合、デバイス設計者はリソースへの影響を最小限に抑えることに特に注意を払うことが強く推奨されています。最も重要な設計上の考慮事項は、ポーリング間隔と呼ばれるクライアント要求間の間隔です。設計では、許容可能な精度と一致する最大ポーリング間隔を使用することが非常に重要です。
1. A client MUST NOT under any conditions use a poll interval less than 15 seconds.
1. クライアントは、いかなる状況でも15秒未満のポーリング間隔を使用してはなりません（MUST NOT）。
2. A client SHOULD increase the poll interval using exponential backoff as performance permits and especially if the server does not respond within a reasonable time.
2. クライアントは、パフォーマンスが許す限り、特にサーバーが妥当な時間内に応答しない場合、指数バックオフを使用してポーリング間隔を増やす必要があります（SHOULD）。
3. A client SHOULD use local servers whenever available to avoid unnecessary traffic on backbone networks.
3. クライアントは、バックボーンネットワーク上の不要なトラフィックを回避するために、可能な限りローカルサーバーを使用する必要があります（SHOULD）。
4. A client MUST allow the operator to configure the primary and/or alternate server names or addresses in addition to or in place of a firmware default IP address.
4. クライアントは、オペレーターがファームウェアのデフォルトIPアドレスに加えて、またはその代わりに、プライマリーおよび/または代替サーバーの名前またはアドレスを構成できるようにする必要があります。
5. If a firmware default server IP address is provided, it MUST be a server operated by the manufacturer or seller of the device or another server, but only with the operator's permission.
5. ファームウェアのデフォルトサーバーIPアドレスを指定する場合は、デバイスの製造元または販売者が操作するサーバーまたは別のサーバーでなければなりませんが、オペレーターの許可が必要です。
6. A client SHOULD use the Domain Name System (DNS) to resolve the server IP addresses, so the operator can do effective load balancing among a server clique and change IP address binding to canonical names.
6. クライアントはドメインネームシステム（DNS）を使用してサーバーのIPアドレスを解決する必要があるため、オペレーターはサーバークリーク間で効果的な負荷分散を実行し、IPアドレスのバインディングを正規名に変更できます。
7. A client SHOULD re-resolve the server IP address at periodic intervals, but not at intervals less than the time-to-live field in the DNS response.
7. クライアントは、定期的にサーバーのIPアドレスを解決する必要がありますが、DNS応答の存続可能時間フィールドよりも短い間隔では解決しません。
8. A client SHOULD support the NTP access-refusal mechanism so that a server kiss-o'-death reply in response to a client request causes the client to cease sending requests to that server and to switch to an alternate, if available.
8. クライアントはNTPアクセス拒否メカニズムをサポートする必要があるため（SHOULD）、クライアント要求に応答したサーバーのkiss-o'-death応答により、クライアントはそのサーバーへの要求の送信を中止し、可能な場合は代替サーバーに切り替えます。
The following algorithm can be used as a pattern for specific implementations. It uses the following variables:
次のアルゴリズムは、特定の実装のパターンとして使用できます。次の変数を使用します。
Timer: This is a counter that decrements at a fixed rate. When it reaches zero, a packet is sent, and the timer is initialized with the timeout for the next packet.
タイマー：これは、固定レートで減少するカウンターです。ゼロに達すると、パケットが送信され、タイマーは次のパケットのタイムアウトで初期化されます。
Maximum timeout: This is the maximum timeout determined from the given oscillator frequency tolerance and the required accuracy.
最大タイムアウト：これは、特定の発振器周波数許容誤差と必要な精度から決定される最大タイムアウトです。
Server Name: This is the DNS name of the server. There may be more than one of them, to be selected by some algorithm not considered here.
サーバー名：サーバーのDNS名です。それらは複数ある可能性があり、ここでは考慮されていないアルゴリズムによって選択されます。
Server IP Address: This is the IPv4, IPv6, or OSI address of the server.
サーバーIPアドレス：サーバーのIPv4、IPv6、またはOSIアドレスです。
If the firmware or documentation includes specific server names, the names should be those the manufacturer or seller operates as a customer convenience or those for which specific permission has been obtained from the operator. A DNS request for a generic server name, such as ntp.mytimeserver.com, should result in a random selection of server IP addresses available for that purpose. Each time a DNS request is received, a new randomized list is returned. The client ordinarily uses the first address on the list.
ファームウェアまたはドキュメントに特定のサーバー名が含まれている場合、その名前は、製造者または販売者が顧客の便宜のために操作するもの、またはオペレーターから特定の許可を得たものでなければなりません。 ntp.mytimeserver.comなどの一般的なサーバー名に対するDNS要求では、その目的で使用できるサーバーIPアドレスがランダムに選択されます。 DNS要求が受信されるたびに、新しいランダム化されたリストが返されます。クライアントは通常、リストの最初のアドレスを使用します。
When candidate SNTP or NTP servers are selected, it is imperative to respect the server operator's conditions of access. Lists of public servers and their conditions of access are available at www.ntp.org. A semi-automatic server discovery scheme using DNS is described at that site. Some ISPs operate public servers, although finding them via their help desks can be difficult.
SNTPまたはNTPサーバーの候補を選択する場合、サーバーオペレーターのアクセス条件を尊重することが不可欠です。公開サーバーとそのアクセス条件のリストは、www.ntp.orgで入手できます。 DNSを使用した半自動サーバー検出スキームがそのサイトで説明されています。一部のISPはパブリックサーバーを運用していますが、ヘルプデスク経由で見つけるのは難しい場合があります。
A well-behaved client operates as follows (note that steps 2-4 constitute a synchronization loop):
正常に動作するクライアントは次のように動作します（ステップ2〜4は同期ループを構成することに注意してください）。
1. Consider the specified frequency tolerance of the system clock oscillator. Define the required accuracy of the system clock, then calculate the maximum timeout. For instance, if the frequency tolerance is 200 parts per million (PPM) and the required accuracy is one minute, the maximum timeout is about 3.5 days. Use the longest maximum timeout possible given the system constraints to minimize time server aggregate load, but never make it less than 15 minutes.
1. システムクロック発振器の指定された周波数許容誤差を考慮します。システムクロックの必要な精度を定義してから、最大タイムアウトを計算します。たとえば、周波数許容誤差が200 ppm（PPM）で、必要な精度が1分である場合、最大タイムアウトは約3.5日です。システムの制約を考慮して、可能な限り長い最大タイムアウトを使用して、タイムサーバーの総負荷を最小化しますが、15分未満にしないでください。
2. When the client is first coming up or after reset, randomize the timeout from one to five minutes. This is to minimize shock when 3000 PCs are rebooted at the same time power is restored after a blackout. Assume at this time that the IP address is unknown and that the system clock is unsynchronized. Otherwise, use the timeout value as calculated in previous loop steps. Note that it may be necessary to refrain from implementing the aforementioned random delay for some classes of International Computer Security Association (ICSA) certification.
2. クライアントが最初に起動するとき、またはリセット後に、タイムアウトを1〜5分にランダム化します。これは、停電後に3000台のPCが再起動すると同時に電源が回復したときのショックを最小限に抑えるためです。この時点で、IPアドレスが不明であり、システムクロックが非同期であると想定します。それ以外の場合は、前のループ手順で計算されたタイムアウト値を使用します。国際コンピュータセキュリティアソシエーション（ICSA）認定の一部のクラスでは、前述のランダム遅延の実装を控える必要がある場合があることに注意してください。
3. When the timer reaches zero, if the IP address is not known, send a DNS query packet; otherwise, send an NTP request packet to that address. If no reply packet has been heard since the last timeout, double the timeout, but do not make it greater than the maximum timeout. If primary and secondary time servers have been configured, alternate queries between the primary and secondary servers when no successful response has been received.
3. タイマーがゼロに達したときに、IPアドレスが不明の場合は、DNSクエリパケットを送信します。それ以外の場合は、NTP要求パケットをそのアドレスに送信します。最後のタイムアウト以降に応答パケットが聞こえない場合は、タイムアウトを2倍にしますが、最大タイムアウトより大きくしないでください。プライマリサーバーとセカンダリタイムサーバーが構成されている場合、正常な応答が受信されない場合は、プライマリサーバーとセカンダリサーバー間の代替クエリ。
4. If a DNS reply packet is received, save the IP address and continue at step 2. If a KoD packet is received, remove that time server from the list, activate the secondary time server, and continue at step 2. If a received packet fails the sanity checks, drop that packet and also continue at step 2. If a valid NTP packet is received, update the system clock, set the timeout to the maximum, and continue at step 2.
4. DNS応答パケットを受信した場合は、IPアドレスを保存してステップ2に進みます。KoDパケットを受信した場合は、そのタイムサーバーをリストから削除し、セカンダリタイムサーバーをアクティブにして、ステップ2に進みます。受信したパケットが失敗した場合健全性チェック、そのパケットのドロップ、およびステップ2への続行。有効なNTPパケットを受信した場合は、システムクロックを更新し、タイムアウトを最大に設定して、ステップ2へ進みます。
Without cryptographic authentication, SNTPv4 service is vulnerable to disruption by misbehaving or hostile SNTP or NTP broadcast servers elsewhere in the Internet. It is strongly recommended that access controls and/or cryptographic authentication means be provided for additional security. This document includes protocol provisions for adding such security mechanisms, but it does not define the mechanisms themselves. A separate document [MIL03] in preparation will define a cryptographic security mechanism for SNTP.
暗号化認証がない場合、SNTPv4サービスは、インターネット内の別の場所にあるSNTPまたはNTPブロードキャストサーバーの誤動作や悪意による混乱に対して脆弱です。セキュリティを強化するために、アクセス制御や暗号認証手段を提供することを強くお勧めします。このドキュメントには、そのようなセキュリティメカニズムを追加するためのプロトコル規定が含まれていますが、メカニズム自体は定義されていません。準備中の別のドキュメント[MIL03]は、SNTPの暗号化セキュリティメカニズムを定義します。
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and corrections.
Jeff Learmanは、このプロトコルのOSIモデルの開発に役立ちました。 Ajit Thyagarajanは貴重な提案と修正を行いました。
D. Plonka
D.プルホンカ
J. Montgomery
J.モンゴメリー
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[BRA97] Bradner、S。、「RFCで使用して要件レベルを示すためのキーワード」、BCP 14、RFC 2119、1997年3月。
[COL94] Colella, R., Callon, R., Gardner, E., and Y. Rekhter, "Guidelines for OSI NSAP Allocation in the Internet", RFC 1629, May 1994.
[COL94] Colella、R.、Callon、R.、Gardner、E。、およびY. Rekhter、「インターネットにおけるOSI NSAP割り当てのガイドライン」、RFC 1629、1994年5月。
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5, RFC 1112, August 1989.
[DEE89] Deering、S。、「IPマルチキャストのホスト拡張」、STD 5、RFC 1112、1989年8月。
[DEE98] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[DEE98] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[DOB91] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless transport services on top of UDP: Version 1", RFC 1240, June 1991.
[DOB91] Shue、C.、Haggerty、W。、およびK. Dobbins、「UDP上のOSIコネクションレス型トランスポートサービス：バージョン1」、RFC 1240、1991年6月。
[FUR94] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support Basic Communications Applications", RFC 1698, October 1994.
[FUR94] Furniss、P。、「基本的な通信アプリケーションをサポートするための上位OSIのオクテットシーケンス」、RFC 1698、1994年10月。
[ISO86] International Standards 8602 - Information Processing Systems - OSI: Connectionless Transport Protocol Specification. International Standards Organization, December 1986.
[ISO86]国際規格8602-情報処理システム-OSI：コネクションレス型トランスポートプロトコル仕様。国際標準化機構、1986年12月。
[MIL92] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[MIL92] Mills、D。、「Network Time Protocol（Version 3）Specification、Implementation and Analysis」、RFC 1305、1992年3月。
[MIL03] Mills, D., "The Autokey Security Architecture, Protocol and Algorithms", http://eecis.udel.edu/~mills/database/reports/ stime/stime.pdf, August 2003.
[MIL03] Mills、D。、「The Autokey Security Architecture、Protocol and Algorithms」、http：//eecis.udel.edu/~mills/database/reports/ stime / stime.pdf、2003年8月。
[PAR93] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting Service", RFC 1546, November 1993.
[PAR93] Partridge、C.、Mendez、T。、およびW. Milliken、「Host Anycasting Service」、RFC 1546、1993年11月。
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980.
[POS80] Postel、J。、「ユーザーデータグラムプロトコル」、STD 6、RFC 768、1980年8月。
[POS83] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC 868, May 1983.
[POS83] Postel、J。およびK. Harrenstien、「Time Protocol」、STD 26、RFC 868、1983年5月。
[SRI99] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[SRI99] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年8月。
[SRI01] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[SRI01] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
Author's Address
著者のアドレス
David L. Mills Electrical and Computer Engineering Department University of Delaware Newark, DE 19716
デビッドL.ミルズデラウェア大学ニューアーク大学電気およびコンピュータエンジニアリング学部、DE 19716
Phone: (302) 831-8247 EMail: mills@udel.edu
電話：（302）831-8247メール：mills@udel.edu
Full Copyright Statement
完全な著作権表示
Copyright (C) The Internet Society (2006).
Copyright（C）The Internet Society（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78 and at www.rfc-editor.org/copyright.html, and except as set forth therein, the authors retain all their rights.
このドキュメントは、BCP 78およびwww.rfc-editor.org/copyright.htmlに含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」で提供され、寄稿者、彼/彼女の代理人、または（もしあれば）組織、インターネットエンジニアリングおよびインターネットエンジニアリングタスクフォースは、すべての保証を明示的または明示的に提供します。ここに含まれる情報の使用により、商品性または特定の目的への適合性に関するいかなる権利または黙示の保証も侵害されないという保証を含みますが、これに限定されるものではありません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、このドキュメントに記載されているテクノロジーの実装または使用に関連すると主張される可能性がある知的財産権またはその他の権利の有効性または範囲、またはそのような権利に基づくライセンスが適用されるかどうかに関係なく、いかなる立場も取りません。利用できる;また、そのような権利を特定するために独立した取り組みを行ったことを表すものでもありません。 RFC文書の権利に関する手順に関する情報は、BCP 78およびBCP 79にあります。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に対して行われたIPR開示のコピー、および利用可能になるライセンスの保証、または一般ライセンスを取得しようとした試み、またはこの仕様の実装者またはユーザーがそのような所有権を使用するための許可を取得した結果を取得できます。 http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、この規格を実装するために必要となる可能性のある技術をカバーする可能性のある著作権、特許、特許出願、またはその他の所有権に注意を向けるよう、関係者に呼びかけます。 IEETのietf-ipr@ietf.orgに情報を送信してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディター機能の資金は、IETF管理サポート活動（IASA）によって提供されます。