RFC4330 日本語訳
4330 Simple Network Time Protocol (SNTP) Version 4 for IPv4, IPv6 andOSI. D. Mills. January 2006. (Format: TXT=67930 bytes) (Obsoletes RFC2030, RFC1769) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group D. Mills Request for Comments: 4330 University of Delaware Obsoletes: 2030, 1769 January 2006 Category: Informational
工場がコメントのために要求するワーキンググループD.をネットワークでつないでください: 4330 デラウエア大学は以下を時代遅れにします。 2030、1769年2006年1月のカテゴリ: 情報
Simple Network Time Protocol (SNTP) Version 4
for IPv4, IPv6 and OSI
IPv4、IPv6、およびOSIのための簡単なネットワーク時間プロトコル(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)インターネット協会(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.
このメモはSimple Network Timeプロトコルバージョン4(SNTPv4)について説明します。(それは、インターネットでコンピュータ時計を連動させるのに使用されるNetwork Timeプロトコル(NTP)の部分集合です)。 RFC1305に基づく完全なNTP実装の究極の性能が必要でなく、また正当化されないとき、SNTPv4を使用できます。 現在で前のNTPとSNTPバージョンで作動するとき、SNTPv4は仕様への変化を全く必要としないか、実装を知っていますが、またはむしろ精度で簡単で、状態がない遠隔手続き呼び出し(RPC)モードにおける操作を許すある設計上の特徴とUDP/タイム誌プロトコルと同様の期待がRFC868で説明した信頼性をはっきりさせます。
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.
このメモはRFC1769とRFC2030を時代遅れにします。(RFCはSNTPバージョン3(SNTPv3)について説明します)。(RFCはSNTPv4について説明します)。 目的は、前のドキュメントにおける、ある矛盾を修正して、NTPv3(IPv4)とSNTPv4(IPv4、IPv6、およびOSI)のためにヘッダー形式とプロトコル操作をはっきりさせることです。(また、SNTPv4はSNTPに使用されます)。 さらなる目的はルータと他の民生品が乱用からサーバ人口を保護するようにホームのための指導とビジネスクライアント実装を提供することです。 NTPv3仕様の実用的な知識(RFC1305)はSNTPの実装に必要ではありません。
Mills Informational [Page 1] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[1ページ]のRFC4330SNTPv4を製粉します。
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
1. 序論…2 1.1. 要件の仕様…5 2. オペレーティング・モードとアドレシング…5 3. NTPタイムスタンプ形式…6 4. メッセージ形式…8 5. SNTPクライアント操作…13 6. SNTPサーバ操作…16 7. 構成と管理…19 8. 'キスo'死パケット…20 9. オンであるのは、良いネットワーク国民です…21 10. 最も良い習慣…21 11. セキュリティ問題…24 12. 承認…24 13. 貢献者…24 14. 有益な参照…25
1. Introduction
1. 序論
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.
RFC1305[MIL92]で指定されたNetwork Timeプロトコルバージョン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.
RFC1305は、時間保持品質を改良して、いくつかの同期ソースを緩和するためにイベント、州、変遷機能、動作、および設計されたアルゴリズムでNTPプロトコルマシンを指定します。その或るものは不完全であるかもしれません。 インターネットの主要部にかかりながら経路の上で低いミリセカンドで精度を達成するために、これらの複雑なアルゴリズム、またはそれらの機能的な同等物が必要です。 多くのアプリケーションでは、1秒の重要な何分の一の注文の精度は許容できます。 簡単なホームルータアプリケーションでは、最大1分の精度は十分であるかもしれません。 そのような場合、RFC868[POS83]で指定されたTimeプロトコルなどの、より簡単なプロトコルはこのために使用されました。 クライアントが時刻を要求するところでこれらのプロトコルは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,
NTPは使用のためにクライアントによって設計されています、そして、さまざまなさまざまな能力とネットワークジターとクロック周波数の上のサーバは特性を歩き回ります。 今日のインターネットのNTPの多くのユーザがwww.ntp.orgから利用可能なソフトウェア配布を使用します。 分配。(その分配はNTPオプションの完全なスイートを含んでいます)。
Mills Informational [Page 2] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[2ページ]のRFC4330SNTPv4を製粉します。
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.
緩和アルゴリズム、およびセキュリティ体系は比較的複雑で、リアルタイムのアプリケーションです。 パーソナルコンピュータからスーパーコンピュータまで及ぶさまざまなハードウェアプラットホームにソフトウェアを移植しましたが、多くのアプリケーションには、その全くのサイズと複雑さは適切ではありません。 それに従って、それほど厳しくない精度期待に、適切なより簡単なソフトウェアを使用する代替の戦略を探るのは役に立ちます。
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.
このメモはSimple Network Timeプロトコルバージョン4(SNTPv4)について説明します。(それは、NTPとSNTPの現在で前のバージョンを使用しているサーバとクライアントのための簡易型のアクセスパラダイムです)。 アクセスパラダイムはUDP/タイム誌プロトコルと同じです、そして、事実上、たとえば、パーソナルコンピュータのためにUDP/タイム誌クライアント実装を適合させて、作動するのは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)(RFC2460)とOSI(RFC1629)アドレシングに対応する変更されたヘッダー解釈です。 しかしながら、SNTPv4は基本的なNTPバージョン3(NTPv3)モデルに、ある任意の拡大を含めます、ベースの認証体系が特に放送とmanycastアプリケーションのために設計したmanycastモードと公開鍵を含んでいて。 manycastモードはこのメモで説明されますが、認証体系は、後で提出するために別のRFCで説明されます。 決定的なNTPv4仕様が発表されるくらいの時間まで、manycastと認証機能は暫定的であると考えられるべきです。 'さらに、このメモはoにキスしている'死亡メッセージを紹介します。(それは、サーバによって使用されて、)事情が必要であるようにクライアント要求を抑圧できます。
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クライアントは一度に、ただ一つのサーバだけで働いています。
The full degree of reliability ordinarily expected of NTP servers is possible only using redundant sources, diverse paths, and the crafted
通常、NTPサーバに予想された完全な度合いの信頼性は、余分なソース、さまざまの経路、および作りを使用するだけであることで可能です。
Mills Informational [Page 3] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[3ページ]のRFC4330SNTPv4を製粉します。
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実装のアルゴリズム。 SNTPクライアントが単に同期サブネットの窮境に使用されることが強く勧められます。 同期において、NTPかどんなSNTPクライアントも別の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八重奏のReference Identifier分野です。(その分野は、主として同期輪を検出して、避けるのに使用されます)。 アドレシングをIPv4に供給するすべてのNTPとSNTPバージョンでは、プライマリサーバはこの分野で4キャラクタのASCII基準クロック識別子を使用しますが、セカンダリサーバは同期ソースの32ビットのIPv4アドレスを使用します。 IPv6とOSIにアドレシングを供給するSNTPv4では、プライマリサーバは同じ時計識別子を使用しますが、セカンダリサーバはIPv6のMD5ハッシュか同期ソースのNSAPアドレスの最初の32ビットを使用します。 'この分野のさらなる使用はサーバが後でこのメモに記録された'死亡メッセージをキスoに送る時です。
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と同じReference Identifier分野を使用します。
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の場合Connectionless Transport Service(CLTS)は[ISO86]のように使用されています。 それぞれのSNTPパケットはT-UNITDATA RequestのTS- Userdataパラメタとして原始的に伝えられます。 交互に、TransportプロトコルData Unit(TPDU)でヘッダーをカプセルに入れることができます、RFC1240[DOB91]で説明されるように。(Data Unitは、UDPを使用することでそれ自体で輸送されます)。 NTPがRFC1698[FUR94]から推論されるかもしれないようなOSIスタックの上側の層で操作されると忠告されません、これが真剣に精度を下げることができたとき。 ヘッダー形式がこのメモで定義されている状態で、それは原則として1つのプロトコルファミリーと別のもののサーバとクライアントの間で織り込むのにおいて可能です、これは実用的な困難で勧められなくなるかもしれませんが。
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タイムスタンプ形式、およびセクションについて説明します。
Mills Informational [Page 4] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[4ページ]のRFC4330SNTPv4を製粉します。
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メッセージで新たに造幣されたoにキスしている'死亡メッセージについて説明します。 セクション9は、良いネットワーク市民にとって、重要なデザイン問題をまとめて、ネットワークを最小にしている間、良い信頼性を与えるように設計された例のアルゴリズムとサーバリソース要求を提示します。
1.1. Specification of Requirements
1.1. 要件の仕様
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはRFC2119[BRA97]で説明されるように本書では解釈されることであるべきですか?
2. Operating Modes and Addressing
2. オペレーティング・モードとアドレシング
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アドレスを意味します。 放送/マルチキャストモデルに関する詳細がRFC1112[DEE89]にあります。 アドレス形式の詳細、規則を見るのなどはこのメモの範囲を超えています。 SNTPv4はユニキャスト(ポイント・ツー・ポイント)、放送(多点を示す)、またはmanycast(示す多点)アドレッシング・モードで作動できます。 ユニキャストクライアントは、ユニキャストアドレスの指定されたサーバに要求を送って、それが時間を決定できる回答を予想します、そして、任意に、往復の遅れと時計はサーバに比例して相殺されます。放送サーバは定期的に指定された放送演説にお節介なメッセージを送ります。 放送クライアントは、このアドレスで聴いて、通常、要求を全く送りません。
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.
ManycastはRFC1546[PAR93]で説明されたanycastパラダイムの拡大です。 それは使用のためにアドレスがあらかじめ知られていない1セットの協力サーバで設計されています。 manycastクライアントは普通のNTPクライアント要求を指定された放送演説に送ります。 1つ以上のmanycastサーバがそのアドレスで聴かれます。 要求を受け取ると、manycastサーバは普通の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
放送サーバは、クライアントユニキャスト要求に応じて、求められていない同報メッセージを送るべきです。 放送クライアントがサーバとクライアントの間のネットワーク伝播遅延を測定するためにユニキャスト要求を送って、次に、操作を続けるかもしれない、聴取、-単に、モード。 しかしながら、放送サーバはそうするかもしれません。
Mills Informational [Page 5] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[5ページ]のRFC4330SNTPv4を製粉します。
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.
ユニキャストクライアントが遅れのために測定を捨てて、デフォルト値を仮定する用意ができているべきであるようにユニキャスト要求に応じないのを選んでください。
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)分野を適正価値に調整するのは、この(そして、いかなる他の)マルチキャストサービスで使用されるネットワーク資源を制限するために重要です。 範囲のマルチキャストクライアントだけがマルチキャストサーバメッセージを受け取るでしょう。 協力するだけであって、範囲のmanycastサーバはクライアント要求に答えるでしょう。 固有値が使用されることを決定する工学原理はこのメモの範囲を超えています。
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放送演説が同じサブネットの多くの依存するSNTP放送クライアントと共に主として完全に機能的なNTPサーバを含むIPサブネットとLANセグメントに使用されて、IPマルチキャストグループアドレスがTTLが特にそれぞれのサービスドメインに設計される場合だけに使用されることを意図します。 しかしながら、これらの用途はSNTP仕様に不可欠ではありません。
3. NTP Timestamp Format
3. NTPタイムスタンプ形式
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はRFC1305とそのドキュメントの旧バージョンで説明された標準のNTPタイムスタンプ形式を使用します。 一般的なインターネット習慣に伴う順応では、NTPデータは整数か定点量として指定されます、左の、または、最も重要な終わりの0始めからのビッグエンディアンファッションでビットが付番されている状態で。 別の方法で指定されない場合、すべての量が、未署名であり、ビット0に先行する暗示している0に全分野に及ぶ調査幅を占領するかもしれません。
Mills Informational [Page 6] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[6ページ]のRFC4330SNTPv4を製粉します。
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タイムスタンプは秒に64ビットの未署名の固定小数点数として1900年1月1日の0hに比例して表されます。 最初の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.
無作為の、そして、不遍のbitstringでタイムスタンプの非重要な下位のビットをいっぱいにして、ともに系統的なロンダード誤りを避けて、輪の検出を提供して、検出を再演するのは賢明です(以下を見てください)。 bitstringが侵入者が予測できないのは、重要です。 これをする1つの方法は始動でbitstringしながら無作為の128ビットを生成することです。 その後に、各回、システムクロックは読まれて、タイムスタンプとbitstringのストリングの成ることは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/タイム誌メッセージ(秒)に便利な複数の精度演算と変換を許しますが、ICMP Timestampメッセージ(ミリセカンド)とUnix時間的価値(秒とマイクロセカンドか秒と数ナノ秒)に変換を複雑にします。 およそ232のピコセコンドの精度に従って、表すことができる最大数は42億9496万7295秒です。(最もエキゾチックな要件にさえ、ピコセコンドは適切であるべきです)。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 秒断片(0でそっと歩いている)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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番目の21億4748万3648)のいつかの時間以来、最も重要なビット(整数部のビット0)が設定されていて、64ビットの分野が2036年(2番目の42億9496万7296)にいつかあふれることに注意してください。 64ビットの分野が0になるときの今後は136年毎に無視された無効の、または、入手できないタイムスタンプとしてコンベンションによって解釈される232ピコセコンドの間隔は存在するでしょう。
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
NTPタイムスタンプ形式が20年間以上使用中であるときに、使用中であるのはそれが現在から32年間なる可能です、秒分野があふれると。 ビット0が1968年に設定される前にNTPタイムスタンプを格納するのがたぶん不適当であるので、NTPタイムスタンプの役に立つ寿命を伸ばす便利な方法は以下のコンベンションです: ビット0が設定されて、UTC時間が範囲1968- 2036にあって、UTC時間が1月1日に0mの0h0UTCから数えられるなら
Mills Informational [Page 7] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[7ページ]のRFC4330SNTPv4を製粉します。
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.
1900. ビット0が設定されないなら、時間が範囲2036-2104にあります、そして、UTC時間は2036年2月7日に28mの6h16年代の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年以内に、クライアントが進水する前にあるクライアント時間を必要とします。 Unixベース1970が現在以来の34年以上の時間として、手段は、どちらか時期の現在(TOY)のチップの、より近くかファームウェアからの日付に時計を初期化するために利用可能でなければなりません。
4. Message Format
4. メッセージ・フォーマット
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の両方がRFC768[POS80]で指定されたユーザー・データグラム・プロトコル(UDP)のクライアントです。 IPとUDPヘッダーの構造について、引用された仕様ドキュメントで説明されて、ここにさらに詳述しないでしょう。 IANAによってNTPに割り当てられたUDPポートナンバーは123です。 SNTPクライアントはクライアント要求メッセージにUDP Destination Port分野でこの値を使用するべきです。 これらのメッセージの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].
これはRFC2030仕様と異なっています。(仕様はソースと仕向港の両方が123であることを必要としました)。 この変化の意図は、特定のクライアント実装(彼らが選ぶものを含んでいて、現在、無遠慮なポートナンバーを使用できる)の識別を許して、RFC2663[SRI99]とRFC3022[SRI01]で説明されるNetwork Address Port Translation(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ヘッダーを次に続かせます)。 この形式はRFC1305で説明されたNTPメッセージ・フォーマットと同じです、以下で説明されたReference Identifier分野を除いて。 SNTPクライアントメッセージ、あらかじめ指定されたデータでゼロであるか初期化されたこれらの分野の大部分に。 完全性において、それぞれの分野の関数は以下へ簡潔にまとめられます。
Mills Informational [Page 8] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[8ページ]のRFC4330SNTPv4を製粉します。
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) |
| |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |李| VN|モード| 層| 投票| 精度| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 根の遅れ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 根のディアスポラ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 参照識別子| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 参照タイムスタンプ(64)| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を溯源してください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を受け取ってください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | タイムスタンプ(64)を伝えてください。| | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 主要な識別子(任意の)(32)| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | メッセージダイジェスト(任意の)(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)を跳ねさせてください: これは差し迫っている閏秒が現在の日の土壇場で挿入されるか、または削除されるという安っぽいコード警告です。 この分野はサーバメッセージだけで重要です:(そこでは、値が以下の通り定義されます)。
Mills Informational [Page 9] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[9ページ]のRFC4330SNTPv4を製粉します。
LI Meaning
---------------------------------------------
0 no warning
1 last minute has 61 seconds
2 last minute has 59 seconds
3 alarm condition (clock not synchronized)
LI意味--------------------------------------------- 0 1つの土壇場には3アラームが2土壇場で59秒条件とさせる61秒があると警告しないこと。(連動しない時計)
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): これはNTP/SNTPバージョン番号、現在の4を示す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
モード意味------------------------------------ 0 私的使用目的で予約されたNTPコントロールメッセージ7のために控えられた1つの予約された左右対称の活発な左右対称の受け身の2のクライアント4サーバ5 3放送6
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.
ユニキャストとmanycastモードで、クライアントは要求における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
層の意味---------------------------------------------- 16-255が控えた1つの'0キス○'死亡メッセージ(以下を見る)のプライマリ参照(例えば、ラジオ時計で、連動される)の2-15のセカンダリ参照(NTPかSNTPによって連動されます)
Mills Informational [Page 10] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[10ページ]のRFC4330SNTPv4を製粉します。
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ビットの符号のない整数です。 この分野はSNTPサーバメッセージだけで重要です。そこでは、値が4(16秒間)から17(36時間に関する131,072秒間)に変化します。
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の間には、断片ポイントがある秒に。 相対的な時間と頻度オフセットによって、この変数が積極的なものと同様に否定的な値を呈することができることに注意してください。 この分野はサーバメッセージだけで重要です。そこでは、値が数ミリセカンドの負の数から数100ミリセカンドの正の数まで及びます。
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
コード外部参照ソース------------------------------------------------------------------ LOCL uncalibratedの地方の時計CESMは較正されたRubidium時計1セカンドソースあたりのPPS何らかの較正された水晶時計パルスIRIG射程間計装グループACTS NISTがモデムサービスUSNO USNO電話モデムサービスPTB PTB(ドイツ)電話モデムサービスTDF Allouis(フランス)ラジオ164kHz DCF Mainflingen(ドイツ)ラジオ77.5kHz MSF Rugby(イギリス)ラジオ60kHz WWV Ftに電話をするCesium時計RBDMを較正しました。 コリンズ(米国)Radio2.5、5、10、15、60kHzの20MHzのWWVBボウルダー(米国)ラジオWWVHカウアイハワイ(米国)ラジオ2.5、5、10、15MHzのCHUオタワ(カナダ)ラジオ3330、7335、14670kHz LORC LORAN-C無線航法システムOMEG OMEGA無線航法システムGPS Global Positioning Service
Figure 2. Reference Identifier Codes
図2。 参照識別子コード
Mills Informational [Page 11] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[11ページ]のRFC4330SNTPv4を製粉します。
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の間には、断片ポイントがある秒に。 この分野はサーバメッセージだけで重要です。そこでは、値がゼロから数100ミリセカンドに変化します。
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.
参照識別子: これは特定の照合線源を特定しながらbitstringされる32ビットです。 'この分野は値が層0(キスo'死メッセージ)と1(プライマリサーバ)のための、4キャラクタのASCIIストリングであるところから正当化されるように残っているサーバメッセージだけで重要です、そして、ゼロは32ビットにそっと歩きました。 IPv4セカンダリサーバのために、値は同期ソースの32ビットのIPv4アドレスです。 IPv6とOSIセカンダリサーバのために、値はIPv6のMD5ハッシュか同期ソースのNSAPアドレスの最初の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コントロールメッセージとRFC1305で説明された参照識別子分野を使用することで歩いて戻るのを実行できます。
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.
タイムスタンプを溯源してください: ここで、要求はサーバのために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認証体系が実装されるとき、Key IdentifierとMessage Digest分野はRFC1305のAppendix Cで定義されたメッセージ確認コード(MAC)情報を含んでいます。
Mills Informational [Page 12] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[12ページ]のRFC4330SNTPv4を製粉します。
5. SNTP Client Operations
5. SNTPクライアント操作
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クライアントはユニキャスト、放送、またはmanycastモードで働くことができます。 ユニキャストモードで、クライアントは、要求(NTPモード3)を指定されたユニキャストサーバに送って、そのサーバから回答(NTPモード4)を予想します。放送クライアントモードで、それは、要求を全く送らないで、1つ以上の放送サーバから放送(NTPモード5)を待っています。 manycastモードで、クライアントは、要求(NTPモード3)を指定された放送演説に送って、1つ以上のmanycastサーバから回答(NTPモード4)を予想します。 クライアントはその後のユニキャスト操作に特定のサーバを証明するために受け取られた最初の回答を使用します。 その後、このサーバ(写し)からの回答かいかなる他のサーバも無視されます。 要求における、アドレスの選択を除いて、manycastとユニキャストクライアントの操作は同じです。
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.
ユニキャストかmanycastクライアントが、NTPメッセージヘッダーを初期化して、要求をサーバに送って、Transmit Timestamp分野からの時刻から回答を奪い取ります。 このために、上に示されたすべてのNTPヘッダーフィールドが0に設定されます、Mode、VN、および任意のTransmit Timestamp分野を除いて。
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クライアントはユニキャストとmanycast要求のために3(クライアント)にモード分野を設定します。 彼らは構成か発見で選択されたサーバによってサポートされて、すべての旧バージョンNTPとSNTPサーバで共同利用できるどんなバージョン番号にもVN分野を設定します。 サーバが要求と同じバージョンで返答するので、また、要求のVN分野は回答のVN分野を指定します。 慎重なSNTPクライアントはどんなそのサーバか後のバージョンも反応させる期待で最も初期の許容できるバージョンを指定できます。 NTPバージョン3(RFC1305)とバージョン2(RFC1119)サーバはバージョン1(RFC1059)を含むすべての旧バージョンを受け入れます。 バージョン0(RFC959)がもう現在の、そして、将来の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
クライアント時計に従ってNTPタイムスタンプ形式で時刻への要求にTransmit Timestamp分野をはめ込むのは従っているクライアント実装では必要ではありませんが、それはユニキャストとmanycastモードで非常にお勧めです。 これで、簡単な計算は、サーバとクライアントの間の伝播遅延を決定して、サーバに比例して一般にいくつかの中のシステムクロックを何十ミリセカンドもと同じくらい並べます。さらに、aを前提とします。
Mills Informational [Page 13] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[13ページ]のRFC4330SNTPv4を製粉します。
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.
事実上、サーバ回答が特定のクライアント要求への正統の応答であることを確かめて、その結果、避ける簡単なメソッドは再演されます。 クライアントには、放送モードで、伝播遅延について計算するか、またはサーバの正当性を決定する情報が全くありません、NTP認証体系の1つが使用されていない場合。
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タイムスタンプ形式で時刻への要求にTransmit Timestamp分野をはめ込みます。 このために、時計は連動する必要はありません。 サーバは、回答でこの分野を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
生成されると、タイムスタンプはIDを命名します。------------------------------------------------------------ クライアントによって受け取られたサーバDestination Timestamp T4時間回答で送られたサーバTransmit Timestamp T3時間回答で受け取られたクライアントReceive Timestamp T2時間要求で送られたTimestamp T1時間要求を溯源してください。
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.
d=(T4--T1)--(T3--T2) tは/2と等しいです((T2--T1)+(T3--T4))。
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クライアントは使用するのをモードに禁じられます)。 以下のテーブルはユニキャスト、manycast、および放送モードにおける必要なSNTPクライアント操作をまとめます。 お勧めのエラーチェックはテーブルのReplyとBroadcastコラムに示されます。 示されたすべての分野がそれぞれの範囲に値を保管している場合にだけ、メッセージは有効であると考えられるべきです。 「無視」であることが示される分野の1つ以上が無効の値を含んでいるなら実装の裁量にはメッセージがあると信じるのであるかどうか
Mills Informational [Page 14] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[14ページ]のRFC4330SNTPv4を製粉します。
Field Name Unicast/Manycast Broadcast
Request Reply
---------------------------------------------------------------
LI 0 0-3 0-3
フィールド名ユニキャスト/Manycast放送要求回答--------------------------------------------------------------- 李0 0-3 0-3
VN 1-4 copied from 1-4
request
1-4 要求からコピーされたVN1-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
根のDelay0が無視する、無視
Root Dispersion 0 ignore ignore
根のディアスポラ0が無視する、無視
Reference Identifier 0 ignore ignore
Identifier0が無視する参照、無視
Reference Timestamp 0 ignore ignore
Timestamp0が無視する参照、無視
Originate Timestamp 0 (see text) ignore
起因する、Timestamp0(テキストを見ます)は無視します。
Receive Timestamp 0 (see text) ignore
受信、Timestamp0(テキストを見ます)は無視します。
Transmit Timestamp (see text) nonzero nonzero
Timestamp(テキストを見る)非零非零を伝えてください。
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はクライアント要求で使用されるTransmit Timestampに合っているはずです。
Mills Informational [Page 15] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[15ページ]のRFC4330SNTPv4を製粉します。
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. サーバ回答はMode分野がLI、Stratum、またはTransmit Timestamp分野のいずれが0でもなくて、また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ディアスポラ分野がそれぞれ0以上と無限であることをチェックできます、現在無限が1秒のように居ごこちがよい数であるところで。 このチェックは、ソースが非常に長い時間同期を吐き出しているサーバを使用するのを避けます。
6. SNTP Server Operations
6. SNTPサーバ操作
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サーバはこれらのアドレスのどんなユニキャスト、manycast、放送演説またはどんな組み合わせでも作動できます。 ユニキャストかmanycastサーバが、要求(NTPモード3)を受け取って、NTPヘッダーのある一定の分野を変更して、返信します(NTPモード4)、ことによると要求と同じメッセージ・バッファを使用して。 manycastサーバは、回答のソースアドレス・フィールドで指定された放送演説で聴きますが、それ自身のユニキャストIPアドレスを使用します。 回答における、アドレスの選択を除いて、manycastとユニキャストサーバの操作は同じです。 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.
ユニキャストとmanycastサーバは、回答に完全な要求の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
要求のMode分野が3(クライアント)であるなら、回答は4(サーバ)に設定されます。 この分野が1(左右対称の能動態)に設定されるなら、回答は2(左右対称の受動態)に設定されます。 これで、クライアント(NTPモード3)か左右対称の能動態(NTPモード1)のどちらかで構成されたクライアントは首尾よく共同利用できます、ことによると準最適の方法で構成されても。 Mode分野のいかなる他の値のためにも、要求はそうです。
Mills Informational [Page 16] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[16ページ]のRFC4330SNTPv4を製粉します。
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.
捨てられる。 放送(求められていない)モードで、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.
また、放送サーバがユニキャストクライアントをサポートするのが、非常に望ましいことに注意してください。 これが潜在的放送クライアントがクライアントを放送するために切り替わる前にクライアント/サーバ交換を使用することで伝播遅延について計算できるようにそうである、(聴取、-単に、)、モード。 故意に、また、manycastサーバはユニキャストサーバです。ともに放送されているとして操作するサーバとmanycastのための同時にのかなりの利点はあるように思えません、プロトコル仕様がそれを禁じませんが。
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.
正しく稼働している照合線源に連動しないなら、放送かmanycastサーバがパケットを送りません。 連動しないなら、それはクライアント要求に応じるかもしれませんが、都合のよいオプションはこれが、可到達性が同期状態にかかわらず決定しているのを許容するので応じることです。 サーバが照合線源と一度も同期したことがないなら、LI分野は3に設定されます(非連動しました)。 一度照合線源に連動しています、LI分野は他の3つの値の1つに設定されて、照合線源が手が届かなくなる、または不完全になっても、最終値セットに残ります。
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ソース識別子に設定されます。 サーバが同期しないなら、Stratum分野はゼロに設定されます、そして、Reference Identifier分野は以下で説明された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分野がシステムクロックの最大の読み込み誤りを反映するように設定されます。 すべての実用的なケースにおいて、それは重要なビットの数の否定的ベース-2対数としてNTPタイムスタンプ形式で小数点の右に計算されます。 Root DelayとRootディアスポラ分野はプライマリサーバのために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つの例外に従ったゼロに設定されます。 メッセージが以前に受信されたクライアント要求に関する回答であるなら、要求のTransmit Timestamp分野は回答のOriginate Timestamp分野に変わりがない状態でコピーされます。 この分野が完全な状態でコピーされるのは、重要です、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
サーバが同期するなら、Reference Timestampはアップデートが照合線源から受けられた時に用意ができています。 Originate Timestamp分野は上の非連動しているケースのように設定されます。 Transmit Timestamp分野は時刻にいつを設定するかことです。
Mills Informational [Page 17] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[17ページ]のRFC4330SNTPv4を製粉します。
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.
メッセージを送ります。 同報メッセージでは、他のメッセージのTransmit Timestamp分野からゼロに合わせて、Receive Timestamp分野がコピーするように設定されます。 以下のテーブルはこれらの動作をまとめます。
Field Name Unicast/Manycast Broadcast
Request Reply
----------------------------------------------------------------
LI ignore as needed as needed
フィールド名ユニキャスト/Manycast放送要求回答---------------------------------------------------------------- LIは必要に応じて必要に応じて無視します。
VN 1-4 copied from 4
request
4要求からコピーされたVN1-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
根のDelayは0 0を無視します。
Root Dispersion ignore 0 0
根のディアスポラは0 0を無視します。
Reference Identifier ignore source ident source ident
参照Identifierはソースidentソースidentを無視します。
Reference Timestamp ignore time of last time of last
source update source update
参照Timestampは最近のソースアップデートソース最新版の最後の時間の時間を無視します。
Originate Timestamp ignore copied from 0
transmit
timestamp
起因する、Timestampが無視する、0からコピーされて、タイムスタンプを伝えてください。
Receive Timestamp ignore time of day 0
受信、Timestampは時刻0を無視します。
Transmit Timestamp (see text) time of day time of day
時刻に、時刻に、Timestamp(テキストを見る)を伝えてください。
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
無効のタイムスタンプを許すために、何らかの緯度がほとんどのクライアント側のあります。(タイムスタンプはサーバが期間の上、または、照合線源が効力がない期間間、来ることであると最初に現れるかもしれません)。 不健康なサーバの最も重要なインディケータは中のStratum分野です。
Mills Informational [Page 18] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[18ページ]のRFC4330SNTPv4を製粉します。
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.
0のどのa値が非連動している状態を示しますか? この値を表示するとき、クライアントは他の分野のコンテンツにかかわらずサーバメッセージを捨てるべきです。
7. Configuration and Management
7. 構成と管理
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サーバとクライアントのための初期のセットアップにできます、そうでなければ。 何人かの人々が、発行されるのにSNMPと適当なMIBを使用することでNTP、SNTPv4サーバ、およびクライアントの稼働中の管理を実行できるだろうことを望んでいました、そして、これはいくつかの市販のSNTPサーバで起こりました。 しかし、ここ20年間にたぶん使用された手段は次で使用されているのが、RFC1305で定義された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つを使用できます。 通常、それは一度に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とローカル放送かマルチキャストグループアドレスを放送サーバとmanycastクライアントに提供しなければなりません。 ユニキャスト、manycastサーバ、および放送クライアントはアクセスコントロールのためにアドレスマスク組のリストによって構成されるかもしれません、信じられるのが知られているそれらのクライアントかサーバだけを受け入れるように。 マルチキャストサーバとクライアントは、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クライアントを構成できます。 マルチキャストサーバとクライアントと共に同じアプローチを使用できます。 どちらの場合も、アクセスコントロールリストの支給はシステムクロックを設定するのに信頼できるソースしか使用できないのを保証する早道です。
Mills Informational [Page 19] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[19ページ]のRFC4330SNTPv4を製粉します。
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.
重要なネットワーク伝播遅延によって拡大ネットワークに適した別のシナリオでは、manycastアドレス(初期の始動と現在選択されたユニキャストソースが聞かれていないいつかの期間の後の両方)のためにクライアントを構成できます。 定義されたプロトコルに従って、クライアントは、最初の回答が受け取られているサーバに付いて、ユニキャストモードで操作を続けています。
8. The Kiss-o'-Death Packet
8. 'キスo'死パケット
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仕様RFC1305に従って、Reference Identifier分野はプライマリサーバを示して、NTPヘッダーのStratum分野が1であるなら、特定の基準クロックタイプを特定するASCIIストリングを含んでいます。 しかしながら、RFC1305年に、何もStratum分野が0であるならReference Identifier分野に関して言われません(「不特定である」として大声で叫ばれます)。 しかしながら、Stratum分野が0であるなら、状態報告とアクセスコントロールの役に立つメッセージを伝えるのにReference Identifier分野を使用できます。 'NTPv4とSNTPv4では、この種類のパケットはKiss-o'死亡(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クライアントは、そのサーバがキスコードにかかわらず0のStratum分野がある回答を返して、代替のサーバが利用可能であるなら特定のサーバに発信するのを止めるべきです。 どんな代替のサーバも利用可能でないなら、クライアントは、次のセクションで説明された指数のbackoffアルゴリズムを使用することで再送するべきです。
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.
キスコードは知的なクライアントに役に立つ情報を提供できます。 これらのコードは正当化されるように残っているASCIIストリングとゼロがいっぱいにした4キャラクタでコード化されます。 ストリングはキャラクタディスプレイとログファイルのために設計されています。 これらのコードのいくつかしかDENY、RSTR、およびRATEを含むSNTPクライアントと共に起こることができません。 サーバが何らかの特別な一時的な病態であるとき、INITとSTEPを含んでいて、他のものは、よりめったに起こることができません。 図3は現在定義されているキスコードのリストを示しています。 これらは情報の目的だけのためのものです。 リストは、将来、変更されるか、または広げられるかもしれません。
Mills Informational [Page 20] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[20ページ]のRFC4330SNTPv4を製粉します。
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
コード意味-------------------------------------------------------------- 協会はanycastサーバAUTHサーバー証明の失敗したAUTO Autokey系列の失敗したBCSTに属します。ACST、協会は放送サーバCRYP Cryptographic認証に属すか、または識別の失敗したDENY Accessが、RSTR Accessが協会が初めてまだ連動させていないローカルの方針INITのためMCSTを否定した左右対称のモードによるリモートサーバDROP Lost同輩で協会がNKEYいいえキーが当たったmanycastサーバに属すことを否定しました。 キーは、決してインストールされなかったか、超えられていた信じられたRATE Rateではありません。 サーバは、クライアントがレート敷居RMOT Somebodyを超えていたのでアクセスがntpdcを実行するリモートホストから協会をへたにいじくり回していることを一時否定しました。 やくざ者がシステム時間あなたのキーSTEP A階段状変化を盗んでいない場合心配しないのは起こりましたが、協会はまだ再連動していません。
Figure 3. Kiss Codes
図3。 コードにキスしてください。
9. On Being a Good Network Citizen
9. 良いネットワーク国民であるのに関して
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があります、インターネットの成長を反映して。 ほとんどあらゆるインターネット接続専用端末には、ある種のNTPサポートがあって、Windows XP、シスコルータを含んでいると、コントローラ、およびすべての種類のソフトウェア・システムは埋め込まれました。 これはSNTPクライアント実装のために設計基準の形に交戦規則を定めるのが必要になったSNTP RFCの初版です。 これが、インターネットが広がって、時間サーバにおける要求が増加するのに従ってインターネット時間サーバリソースの適切な使用に関してソフトウェア開発者を教育して、前記のように問題の種類の再発を防ぐのに必要です。
10. Best Practices
10. 最も良い習慣
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
NTPとSNTPクライアントは彼らが良いネットワーク市民でないならかなりのネットワークとサーバリソースを消費できます。 現在、公共の、そして、個人的なNTPの見込み客である数百万とSNTPでサーバに付番する消費者インターネット商品デバイスがあります。 最近の経験は、デバイスデザイナーがリソース影響を最小にすることに関する特別の注意を向けるのを強く示します、特にこれらの多くのデバイスが配布されるなら。 最も重要
Mills Informational [Page 21] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[21ページ]のRFC4330SNTPv4を製粉します。
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.
設計の検討は投票間隔と呼ばれるクライアント要求の間隔です。 デザインが許容できる精度と一致した最大の投票間隔を費やすのは、非常に重要です。
1. A client MUST NOT under any conditions use a poll interval less
than 15 seconds.
1. クライアントはどんな条件のもとでも投票間隔を15秒未満費やしてはいけません。
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は、性能が可能にして、特にサーバが適当な時間内に反応しないなら指数のbackoffを使用することで投票間隔を増強します。
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. SHOULDがサーバIPが扱うと決議するのに、ドメインネームシステム(DNS)を使用するクライアントによって、オペレータは、サーバ徒党の中で有効なロードバランシングをして、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. クライアントSHOULDは周期的な間隔で、サーバ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. 'サーバキスo'死がクライアント要求に対応して返答するようにSHOULDがNTPアクセス拒否メカニズムをサポートするクライアントは、クライアントがそのサーバに要求を送るのをやめて、補欠に切り替わることを引き起こします、利用可能であるなら。
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.
最大のタイムアウト: これは与えられた振動子周波数公差と必要な精度から断固とした最大のタイムアウトです。
Mills Informational [Page 22] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[22ページ]のRFC4330SNTPv4を製粉します。
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. 指定された頻度がシステムクロック発振器の寛容であると考えてください。 システムクロックの必要な精度を定義してください、そして、次に、最大のタイムアウトについて計算してください。 例えば、100万(PPM)あたり周波数公差が200の部品であり、必要な精度が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アドレスが未知であり、システムクロックが非連動すると仮定してください。 さもなければ、前の輪のステップにおける計算されるとしてのタイムアウト値を使用してください。 数人のクラスの国際コンピュータSecurity Association(ICSA)証明のために前述の無作為の遅れを実装するのを控えるのが必要であるかもしれないことに注意してください。
Mills Informational [Page 23] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[23ページ]のRFC4330SNTPv4を製粉します。
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リクエスト・パケットをそのアドレスに送ってください。 最後のタイムアウト以来回答パケットが全く聞かれていないなら、タイムアウトを倍にしなさい、ただし、それを最大のタイムアウトよりすばらしくしないでください。 どんなうまくいっている応答も受けていないとき、プライマリの、そして、セカンダリの時間サーバが構成されたなら、プライマリの、そして、セカンダリのサーバの間の質問を交替してください。
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で続いてください。
11. Security Considerations
11. セキュリティ問題
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のために暗号のセキュリティー対策を定義するでしょう。
12. Acknowledgements
12. 承認
Jeff Learman was helpful in developing the OSI model for this protocol. Ajit Thyagarajan provided valuable suggestions and corrections.
ジェフLearmanはこのプロトコルのためにOSIモデルを開発する際に役立っていました。 Ajit Thyagarajanは貴重な提案と修正を提供しました。
13. Contributors
13. 貢献者
D. Plonka
D.Plonka
J. Montgomery
J.モンゴメリ
Mills Informational [Page 24] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[24ページ]のRFC4330SNTPv4を製粉します。
14. Informative References
14. 有益な参照
[BRA97] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[BRA97] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、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.、ガードナー、E.、およびY.Rekhter、「インターネットのオウシNSAP Allocationのためのガイドライン」、RFC1629)は1994がそうするかもしれません。
[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, August 1989.
[DEE89] デアリング、S.、「IPマルチキャスティングのためのホスト拡大」、STD5、RFC1112、1989年8月。
[DEE98] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[DEE98]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[DOB91] Shue, C., Haggerty, W., and K. Dobbins, "OSI connectionless
transport services on top of UDP: Version 1", RFC 1240, June
1991.
[DOB91] シュー、C.、ハガティ、W.、およびK.ドビンズ、「OSIのコネクションレスな輸送はUDPの上で以下を修理します」。 バージョン1インチ、RFC1240、1991年6月。
[FUR94] Furniss, P., "Octet Sequences for Upper-Layer OSI to Support
Basic Communications Applications", RFC 1698, October 1994.
[FUR94] ファーニス、P.、「サポートの基本的なコミュニケーションアプリケーションへの上側の層のOSIのための八重奏系列」、RFC1698、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] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、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] 工場と、D.と、「Autokeyセキュリティー体系、プロトコル、およびアルゴリズム」、 http://eecis.udel.edu/~mills/database/reports/ stime/stime.pdf、8月2003日
[PAR93] Partridge, C., Mendez, T., and W. Milliken, "Host Anycasting
Service", RFC 1546, November 1993.
[PAR93] ヤマウズラとC.とメンデス、T.とW.ミリケン、「ホストAnycastingサービス」、RFC1546、1993年11月。
[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August
1980.
[POS80] ポステル、J.、「ユーザー・データグラム・プロトコル」、STD6、RFC768、1980年8月。
[POS83] Postel, J. and K. Harrenstien, "Time Protocol", STD 26, RFC
868, May 1983.
[POS83] ポステル、J.、およびK.Harrenstien(「時間プロトコル」、STD26、RFC868)は1983がそうするかもしれません。
[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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
Mills Informational [Page 25] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[25ページ]のRFC4330SNTPv4を製粉します。
[SRI01] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[SRI01] SrisureshとP.とK.Egevang、「伝統的なIPネットワークアドレス変換機構(伝統的なNAT)」、RFC3022、2001年1月。
Author's Address
作者のアドレス
David L. Mills Electrical and Computer Engineering Department University of Delaware Newark, DE 19716
デヴィッドL.は電気とComputer技術部デラウエア大学ニューアーク、DE 19716を製粉します。
Phone: (302) 831-8247 EMail: mills@udel.edu
以下に電話をしてください。 (302) 831-8247 メールしてください: mills@udel.edu
Mills Informational [Page 26] RFC 4330 SNTPv4 for IPv4, IPv6 and OSI January 2006
2006年1月にIPv4、IPv6、およびOSIのために情報[26ページ]のRFC4330SNTPv4を製粉します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2006).
Copyright(C)インターネット協会(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.
このドキュメントはBCP78と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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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はこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC Editor機能のための基金はIETF Administrative Support Activity(IASA)によって提供されます。
Mills Informational [Page 27]
ミルズInformationalです。[27ページ]
一覧
スポンサーリンク
