Internet Engineering Task Force (IETF)                        M. Lichvar
Request for Comments: 9769                                       Red Hat
Updates: 5905                                                A. Malhotra
Category: Standards Track                              Boston University
ISSN: 2070-1721                                                 May 2025
        
NTP Interleaved Modes
NTPインターリーブモード
Abstract
概要

This document specifies interleaved modes for the Network Time Protocol (NTP). These new modes improve the accuracy of time synchronization by enabling the use of more accurate transmit timestamps that are available only after the transmission of NTP messages. These enhancements are intended to improve timekeeping in environments where high accuracy is critical. This document updates RFC 5905 by defining these new operational modes.

このドキュメントは、ネットワークタイムプロトコル(NTP)のインターリーブモードを指定します。これらの新しいモードは、NTPメッセージの送信後にのみ利用可能なより正確な送信タイムスタンプを使用することにより、時間同期の精度を改善します。これらの機能強化は、高精度が重要な環境でのタイムキーピングを改善することを目的としています。このドキュメントは、これらの新しい運用モードを定義することにより、RFC 5905を更新します。

Status of This Memo
本文書の位置付け

This is an Internet Standards Track document.

これは、インターネット標準トラックドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

このドキュメントは、インターネットエンジニアリングタスクフォース(IETF)の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ(IESG)からの出版が承認されています。インターネット標準の詳細については、RFC 7841のセクション2で入手できます。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9769.

このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9769で取得できます。

著作権表示

Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.

著作権(c)2025 IETF Trustおよび文書著者として特定された人。無断転載を禁じます。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.

このドキュメントは、BCP 78およびIETFドキュメント(https://trustee.ietf.org/license-info)に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。

Table of Contents
目次
   1.  Introduction
     1.1.  Requirements Language
   2.  Interleaved Client/Server Mode
   3.  Interleaved Symmetric Mode
   4.  Interleaved Broadcast Mode
   5.  Impact of Implementation Errors
   6.  Security Considerations
   7.  IANA Considerations
   8.  References
     8.1.  Normative References
     8.2.  Informative References
   Acknowledgements
   Authors' Addresses
        
1. Introduction
1. はじめに

RFC 5905 [RFC5905] describes the operations of NTPv4 in a client/ server mode, symmetric mode, and broadcast mode. The transmit and receive timestamps are two of the four timestamps included in every NTPv4 packet used for time synchronization.

RFC 5905 [RFC5905]は、クライアント/サーバーモード、対称モード、およびブロードキャストモードでのNTPV4の操作を説明しています。送信および受信タイムスタンプは、時間同期に使用されるすべてのNTPV4パケットに含まれる4つのタイムスタンプのうち2つです。

For a highly accurate and stable synchronization, the transmit and receive timestamps should be captured close to the beginning of the actual transmission and the end of the reception, respectively. An asymmetry in the timestamping causes the offset measured by NTP to have an error.

非常に正確で安定した同期のために、実際の送信の開始とレセプションの終わりの近くで、送信および受信タイムスタンプをキャプチャする必要があります。タイムスタンプの非対称性により、NTPによって測定されたオフセットがエラーが発生します。

Four options where a timestamp of an NTP packet may be captured with a software NTP implementation running on a general-purpose operating system are as follows:

NTPパケットのタイムスタンプが、汎用オペレーティングシステムで実行されているソフトウェアNTP実装でキャプチャされる可能性がある4つのオプションは次のとおりです。

1. User space (software)

1. ユーザースペース(ソフトウェア)

2. Network device driver or kernel (software)

2. ネットワークデバイスドライバーまたはカーネル(ソフトウェア)

3. Data link layer (hardware - MAC chip)

3. データリンクレイヤー(ハードウェア-Macチップ)

4. Physical layer (hardware - PHY chip)

4. 物理レイヤー(ハードウェア-Phyチップ)

Software timestamps captured in the user space in the NTP implementation itself are the least accurate. They do not account for delays due to system calls used for sending and receiving packets, processing and queuing delays in the system, network device drivers, and hardware. Hardware timestamps captured at the physical layer are the most accurate.

NTP実装自体のユーザースペースでキャプチャされたソフトウェアタイムスタンプは、最も正確ではありません。これらは、システムの送信と受信に使用されるシステムコール、システム、ネットワークデバイスドライバー、ハードウェアの遅延の処理とキューイングに使用される遅延を考慮していません。物理層でキャプチャされたハードウェアタイムスタンプが最も正確です。

A transmit timestamp captured in the driver or hardware is more accurate than the user-space timestamp, but it is available to the NTP implementation only after it sent the packet using a system call. The timestamp cannot be included in the packet itself unless the driver or hardware supports NTP and can modify the packet before or during the actual transmission.

ドライバーまたはハードウェアでキャプチャされた送信タイムスタンプは、ユーザースペースのタイムスタンプよりも正確ですが、システムコールを使用してパケットを送信した後にのみ、NTP実装が利用できます。ドライバーまたはハードウェアがNTPをサポートし、実際の送信前または実際にパケットを変更できない限り、タイムスタンプはパケット自体に含めることはできません。

The protocol described in RFC 5905 [RFC5905] does not specify any mechanism for a server to provide its clients and peers with a more accurate transmit timestamp that is known only after the transmission. A packet that strictly follows RFC 5905 [RFC5905], i.e., that contains a transmit timestamp corresponding to the packet itself, is said to be in the basic mode.

RFC 5905 [RFC5905]で説明されているプロトコルは、サーバーがクライアントとピアに、送信後にのみ知られているより正確な送信タイムスタンプを提供するメカニズムを指定していません。RFC 5905 [RFC5905]、つまりパケット自体に対応する送信タイムスタンプを含むパケットは、基本モードにあると言われています。

Different mechanisms could be used to exchange timestamps known after the transmission. The server could respond to each request with two packets. The second packet would contain the transmit timestamp corresponding to the first packet. However, such a protocol would enable a traffic amplification attack, or it would use packets with an asymmetric length, which would cause an asymmetry in the network delay and an error in the measured offset.

さまざまなメカニズムを使用して、送信後に知られているタイムスタンプを交換できます。サーバーは、2つのパケットで各要求に応答できます。2番目のパケットには、最初のパケットに対応する送信タイムスタンプが含まれます。ただし、このようなプロトコルはトラフィック増幅攻撃を可能にするか、非対称の長さのパケットを使用して、ネットワーク遅延の非対称性と測定されたオフセットにエラーが発生します。

This document describes an interleaved client/server mode, interleaved symmetric mode, and interleaved broadcast mode. In these modes, the server sends a packet that contains a transmit timestamp corresponding to the transmission of the previous packet that was sent to the client or peer. This transmit timestamp can be captured in any software or hardware component involved in the transmission of the packet. Both servers and clients/peers are required to keep some state specific to the interleaved mode.

このドキュメントでは、インターリーブクライアント/サーバーモード、インターリーブ対称モード、およびインターリーブブロードキャストモードについて説明します。これらのモードでは、サーバーは、クライアントまたはピアに送信された以前のパケットの送信に対応する送信タイムスタンプを含むパケットを送信します。この送信タイムスタンプは、パケットの送信に関与する任意のソフトウェアまたはハードウェアコンポーネントでキャプチャできます。インターリーブモードに固有の状態を保つために、サーバーとクライアント/ピアの両方が必要です。

An NTPv4 implementation that supports the interleaved client/server and interleaved broadcast modes interoperates with NTPv4 implementations without this capability. A peer using the interleaved symmetric mode does not fully interoperate with a peer that does not support it. The mode needs to be configured specifically for each symmetric association.

インターリーブクライアント/サーバーをサポートし、インターリーブしたブロードキャストモードをサポートするNTPV4実装は、この機能なしでNTPV4実装と相互運用します。インターリーブした対称モードを使用するピアは、それをサポートしていないピアと完全に相互運用しません。モードは、各対称アソシエーションに特異的に構成する必要があります。

The interleaved modes do not change the NTP packet header format and do not use new extension fields. The negotiation is implicit. The protocol is extended with new values that can be assigned to the origin and transmit timestamps. Servers and peers check the origin timestamp to detect requests conforming to the interleaved mode. A response can only be valid in one mode. If a client or peer that does not support the interleaved mode received a response conforming to the interleaved mode, it would be rejected as bogus.

インターリーブモードは、NTPパケットヘッダー形式を変更せず、新しい拡張フィールドを使用しません。交渉は暗黙的です。プロトコルは、起源に割り当てられ、タイムスタンプを送信できる新しい値で拡張されます。サーバーとピアは、オリジンタイムスタンプをチェックして、インターリーブモードに準拠したリクエストを検出します。応答は、1つのモードでのみ有効です。インターリーブモードをサポートしていないクライアントまたはピアが、インターリーブモードに準拠した応答を受け取った場合、偽物として拒否されます。

An explicit negotiation would require a new extension field. RFC 5905 [RFC5905] does not specify how servers should handle requests with an unknown extension field. The original use of extension fields was authentication with Autokey [RFC5906], which cannot be negotiated. Some existing implementations do not respond to requests with unknown extension fields. This behavior would prevent clients from reliably detecting support for the interleaved mode.

明示的な交渉には、新しい拡張フィールドが必要です。RFC 5905 [RFC5905]は、未知の拡張機能フィールドでサーバーがリクエストを処理する方法を指定していません。拡張フィールドの当初の使用は、Autokey [RFC5906]を使用した認証でしたが、これは交渉できません。一部の既存の実装では、未知の拡張フィールドのリクエストに応答しません。この動作により、クライアントはインターリーブモードのサポートを確実に検出できなくなります。

Requests and responses cannot always be formed in the interleaved mode. It cannot be used exclusively. Servers, clients, and peers that support the interleaved mode need to also support the basic mode.

インターリーブモードで常にリクエストと応答を形成することはできません。排他的に使用することはできません。インターリーブモードをサポートするサーバー、クライアント、およびピアは、基本モードもサポートする必要があります。

This document assumes familiarity with RFC 5905 [RFC5905].

このドキュメントは、RFC 5905 [RFC5905]に精通しています。

1.1. Requirements Language
1.1. 要件言語

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

このドキュメント内のキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、および「OPTIONAL」は、ここに示すようにすべて大文字で表示されている場合にのみ、BCP 14 [RFC2119] [RFC8174] で説明されているように解釈されます。

2. Interleaved Client/Server Mode
2. インターリーブクライアント/サーバーモード

The interleaved client/server mode is similar to the basic client/ server mode. The difference between the two modes is in the values saved to the origin and transmit timestamp fields.

インターリーブクライアント/サーバーモードは、基本的なクライアント/サーバーモードに似ています。2つのモードの違いは、原点に保存され、タイムスタンプフィールドを送信する値にあります。

The origin timestamp is a cookie that is used to detect that a received packet is a response to the last packet sent in the other direction of the association. It is a copy of one of the timestamps from the packet to which it is responding, or zero if it is not a response. Servers following RFC 5905 [RFC5905] ignore the origin timestamp in client requests. A server response that does not have a matching origin timestamp is considered bogus.

Origin Timestampは、受信したパケットが関連付けの反対方向に送信された最後のパケットへの応答であることを検出するために使用されるCookieです。これは、それが応答しているパケットからのタイムスタンプの1つのコピー、または応答ではない場合はゼロです。RFC 5905 [RFC5905]に続くサーバーは、クライアントリクエストのオリジンタイムスタンプを無視します。一致する原点タイムスタンプがないサーバーの応答は、偽物と見なされます。

A client request in the basic mode has an origin timestamp equal to the transmit timestamp from the last valid server response, or the origin timestamp is zero (which indicates the first request of the association). A server response in the basic mode has an origin timestamp equal to the transmit timestamp from the client request. The transmit timestamp in the response corresponds to the transmission of the response in which the timestamp is contained.

基本モードのクライアント要求には、最後の有効なサーバー応答からの送信タイムスタンプに等しいオリジンタイムスタンプがあります。または、Origin Timestampはゼロです(これは関連付けの最初の要求を示します)。基本モードのサーバー応答には、クライアントリクエストからの送信タイムスタンプに等しいオリジンタイムスタンプがあります。応答の送信タイムスタンプは、タイムスタンプが含まれている応答の伝達に対応しています。

A client request in the interleaved mode has an origin timestamp equal to the receive timestamp from the last valid server response. A server response in the interleaved mode has an origin timestamp equal to the receive timestamp from the client request. The transmit timestamp in the response corresponds to the transmission of the previous response that had the receive timestamp equal to the origin timestamp from the request.

インターリーブモードのクライアント要求には、最後の有効なサーバー応答からの受信タイムスタンプに等しいオリジンタイムスタンプがあります。インターリーブモードのサーバー応答には、クライアントリクエストからの受信タイムスタンプに等しいオリジンタイムスタンプがあります。応答の送信タイムスタンプは、リクエストからの起源タイムスタンプに等しい受信タイムスタンプを持っていた以前の応答の送信に対応しています。

A server that supports the interleaved mode needs to save pairs of local receive and transmit timestamps. The server SHOULD discard old timestamps to limit the amount of memory used for the interleaved mode, e.g., by using a fixed-length queue and dropping old timestamps as new timestamps are saved. The server MAY separate the timestamps by IP addresses, but it SHOULD NOT separate them by port numbers to support clients that change their port between requests, as recommended in RFC 9109 [RFC9109].

インターリーブモードをサポートするサーバーは、ローカルの受信および送信タイムスタンプのペアを保存する必要があります。サーバーは、古いタイムスタンプを破棄して、インターリーブモードに使用されるメモリの量を制限する必要があります。たとえば、固定長のキューを使用して、新しいタイムスタンプが保存されると古いタイムスタンプを削除することにより。サーバーは、IPアドレスでタイムスタンプを分離する場合がありますが、RFC 9109 [RFC9109]で推奨されるように、リクエスト間でポートを変更するクライアントをサポートするためにポート番号でそれらを分離するべきではありません。

The server MAY restrict the interleaved mode to specific IP addresses and/or authenticated clients.

サーバーは、インターリーブモードを特定のIPアドレスおよび/または認証されたクライアントに制限する場合があります。

Both servers and clients that support the interleaved mode MUST NOT send a packet that has a transmit timestamp equal to the receive timestamp in order to reliably detect whether received packets conform to the interleaved mode. One way to ensure this behavior is to increment the transmit timestamp by 1 unit (i.e., about 1/4 of a nanosecond) if the two timestamps are equal, or a new timestamp can be generated.

インターリーブモードをサポートするサーバーとクライアントの両方が、受信されたパケットがインターリーブモードに適合するかどうかを確実に検出するために、受信タイムスタンプに等しい送信タイムスタンプを持つパケットを送信してはなりません。この動作を確保する1つの方法は、2つのタイムスタンプが等しい場合、または新しいタイムスタンプを生成できる場合、1ユニット(つまり、ナノ秒の約1/4)単位(つまり、ナノ秒の約1/4)を増やすことです。

The transmit and receive timestamps in server responses need to be unique to prevent two different clients from sending requests with the same origin timestamp and the server responding in the interleaved mode with an incorrect transmit timestamp. If the timestamps are not guaranteed to be monotonically increasing, the server SHOULD check that the transmit and receive timestamps are not already saved as a receive timestamp of a previous request (from the same IP address if the server separates timestamps by addresses), and generate a new timestamp if necessary, to prevent an incorrect interleaved response later.

サーバーの応答での送信および受信は、2つの異なるクライアントが同じOrigin Timestampを使用してリクエストを送信しないようにする必要があります。タイムスタンプが単調に増加することが保証されていない場合、サーバーは、サーバーが以前の要求の受信タイムスタンプとして送信および受信タイムスタンプがまだ保存されていないことを確認する必要があります(サーバーがアドレスでタイムスタンプを分離する場合、同じIPアドレスから)、必要に応じて新しいタイムスタンプを生成し、後に誤った応答を防ぐために新しいタイムスタンプを生成します。

When the server receives a request from a client, it MUST NOT respond in the interleaved mode unless the following two conditions are met:

サーバーがクライアントからリクエストを受信した場合、次の2つの条件が満たされない限り、インターリーブモードで応答しないでください。

1. The request does not have a receive timestamp equal to the transmit timestamp.

1. リクエストには、送信タイムスタンプに等しい受信タイムスタンプがありません。

2. The origin timestamp from the request matches the local receive timestamp of a previous request that the server has saved (for the IP address if it separates timestamps by addresses).

2. リクエストからのOrigin Timestameは、サーバーが保存した以前の要求のローカル受信タイムスタンプと一致します(アドレスでタイムスタンプを分離する場合はIPアドレスの場合)。

A response in the interleaved mode MUST contain the transmit timestamp of the response that contained the receive timestamp matching the origin timestamp from the request. The server can drop the timestamps after sending the response. The receive timestamp MUST NOT be used again to detect a request conforming to the interleaved mode.

インターリーブモードでの応答には、リクエストからのオリジンタイムスタンプを一致させる受信タイムスタンプを含む応答の送信タイムスタンプを含める必要があります。サーバーは、応答を送信した後にタイムスタンプをドロップできます。受信タイムスタンプは、インターリーブモードに準拠した要求を検出するために再度使用してはなりません。

If the conditions are not met (i.e., the request is not detected to conform to the interleaved mode), the server MUST NOT respond in the interleaved mode. If it responds, it MUST be in the basic mode. In any case, the server SHOULD save the new receive and transmit timestamps to be able to respond in the interleaved mode to the next request from the client.

条件が満たされていない場合(つまり、リクエストがインターリーブモードに準拠するように検出されない)、サーバーはインターリーブモードで応答してはなりません。それが応答する場合、それは基本モードでなければなりません。いずれにせよ、サーバーは新しい受信を保存し、タイムスタンプを送信して、インターリーブモードでクライアントからの次の要求に応答できるようにする必要があります。

The first request from a client is always in the basic mode, and so is the server response. It has a zero origin timestamp and zero receive timestamp. Only when the client receives a valid response from the server will it be able to send a request in the interleaved mode.

クライアントからの最初のリクエストは常に基本モードであり、サーバーの応答もあります。ゼロ起源のタイムスタンプがあり、ゼロ受信タイムスタンプがあります。クライアントがサーバーから有効な応答を受信した場合にのみ、インターリーブモードでリクエストを送信できます。

The protocol recovers from packet loss. When a client request or server response is lost, the client will use the same origin timestamp in the next request. The server can respond in the interleaved mode if it still has the timestamps corresponding to the origin timestamp. If the server already responded to the timestamp in the interleaved mode or it had to drop the timestamps for other reasons, it will respond in the basic mode and save new timestamps, which will enable an interleaved response to the subsequent request. The client SHOULD limit the number of requests in the interleaved mode between server responses to prevent the processing of very old timestamps in cases where a large number of consecutive requests are lost.

プロトコルはパケットの損失から回復します。クライアントのリクエストまたはサーバーの応答が失われると、クライアントは次のリクエストで同じOriginタイムスタンプを使用します。サーバーは、オリジンタイムスタンプに対応するタイムスタンプがまだある場合、インターリーブモードで応答できます。サーバーが既にインターリーブモードでタイムスタンプに応答した場合、または他の理由でタイムスタンプをドロップする必要がある場合、基本モードで応答し、新しいタイムスタンプを保存します。クライアントは、サーバーの応答間のインターリーブモードのリクエスト数を制限して、多数の連続したリクエストが失われる場合に非常に古いタイムスタンプの処理を防ぐ必要があります。

An example of packets in a client/server exchange using the interleaved mode is shown in Figure 1. The packets in the basic and interleaved modes are indicated with B and I, respectively. The timestamps t1~, t3~, and t11~ point to the same transmissions as t1, t3, and t11, but they may be less accurate. The first exchange is in the basic mode followed by a second exchange in the interleaved mode. For the third exchange, the client request is in the interleaved mode, but the server response is in the basic mode, because the server did not have the pair of timestamps t6 and t7 (e.g., they were dropped to save timestamps for other clients using the interleaved mode).

インターリーブモードを使用したクライアント/サーバー交換のパケットの例を図1に示します。基本モードとインターリーブモードのパケットは、それぞれBとIで示されています。タイムスタンプT1〜、T3〜、およびT11〜は、T1、T3、およびT11と同じトランスミッションを指しますが、精度が低い場合があります。最初の交換は基本モードに続いて、インターリーブモードで2回目の交換が行われます。3回目の交換の場合、クライアント要求はインターリーブモードですが、サーバーの応答は基本モードにあります。これは、サーバーにタイムスタンプT6とT7のペアがないためです(たとえば、インターリーブモードを使用して他のクライアントのタイムスタンプを保存するためにドロップされました)。

               t2   t3               t6   t7              t10  t11
   Server -----+----+----------------+----+----------------+----+-----
              /      \              /      \              /      \
             /        \            /        \            /        \
   Client --+----------+----------+----------+----------+----------+--
            t1         t4         t5         t8         t9        t12

   Mode     B         B           I         I           I         B
          +----+    +----+      +----+    +----+      +----+    +----+
   Origin | 0  |    | t1~|      | t2 |    | t4 |      | t6 |    | t5 |
   Rx     | 0  |    | t2 |      | t4 |    | t6 |      | t8 |    |t10 |
   Tx     | t1~|    | t3~|      | t1 |    | t3 |      | t5 |    |t11~|
          +----+    +----+      +----+    +----+      +----+    +----+
        

Figure 1: Packet Timestamps in Interleaved Client/Server Mode

図1:インターリーブクライアント/サーバーモードのパケットタイムスタンプ

When the client receives a response from the server, it performs the tests described in RFC 5905 [RFC5905]. Two of the tests are modified for the interleaved mode:

クライアントがサーバーから応答を受信すると、RFC 5905 [RFC5905]で説明されているテストを実行します。2つのテストは、インターリーブモードのために変更されます。

1. The check for duplicate packets compares both receive and transmit timestamps in order to not drop a valid response in the interleaved mode if it follows a response in the basic mode and they contain the same transmit timestamp.

1. 重複パケットのチェックは、基本モードの応答に従い、同じ送信タイムスタンプを含む場合、インターリーブモードで有効な応答をドロップしないように、タイムスタンプを受信と送信の両方を比較します。

2. The check for bogus packets compares the origin timestamp with both transmit and receive timestamps from the request. If the origin timestamp is equal to the transmit timestamp, the response is in the basic mode. If the origin timestamp is equal to the receive timestamp, the response is in the interleaved mode.

2. 偽のパケットのチェックは、オリジンのタイムスタンプと、リクエストからタイムスタンプを送信および受信することの両方と比較します。起源のタイムスタンプが送信タイムスタンプに等しい場合、応答は基本モードにあります。起源のタイムスタンプが受信タイムスタンプに等しい場合、応答はインターリーブモードにあります。

The client SHOULD NOT update its NTP state when an invalid response is received, so that the timestamps that will be needed to complete a measurement when the subsequent response in the interleaved mode is received will not be lost.

クライアントは、無効な応答が受信されたときにNTP状態を更新しないでください。そうすれば、インターリーブモードでの後続の応答が受信されたときに測定を完了するために必要なタイムスタンプが失われません。

If the packet passed the tests and conforms to the interleaved mode, the client can compute the offset and delay using the formulas from RFC 5905 [RFC5905] and one of two different sets of timestamps. The first set is RECOMMENDED for clients that filter measurements based on the delay. The corresponding timestamps from Figure 1 are written in parentheses.

パケットがテストに合格し、インターリーブモードに準拠した場合、クライアントは、RFC 5905 [RFC5905]と2つの異なるタイムスタンプセットの1つの式を使用してオフセットと遅延を計算できます。最初のセットは、遅延に基づいて測定値をフィルタリングするクライアントに推奨されます。図1の対応するタイムスタンプは、括弧内に記述されています。

* T1 - local transmit timestamp of the previous request (t1)

* T1-前のリクエストのローカル送信タイムスタンプ(T1)

* T2 - remote receive timestamp from the previous response (t2)

* T2-前の応答からリモート受信タイムスタンプ(T2)

* T3 - remote transmit timestamp from the latest response (t3)

* T3-最新の応答(T3)からのリモート送信タイムスタンプ

* T4 - local receive timestamp of the previous response (t4)

* T4-以前の応答のローカル受信タイムスタンプ(T4)

The second set gives a more accurate measurement of the current offset, but the delay is much more sensitive to a frequency error between the server and client due to a much longer interval between T1 and T4.

2番目のセットは、現在のオフセットのより正確な測定を提供しますが、T1とT4の間の間隔がはるかに長いため、サーバーとクライアントの間の周波数エラーに対して遅延ははるかに敏感です。

* T1 - local transmit timestamp of the latest request (t5)

* T1-最新リクエストのローカル送信タイムスタンプ(T5)

* T2 - remote receive timestamp from the latest response (t6)

* T2-最新の応答(T6)からリモート受信タイムスタンプ

* T3 - remote transmit timestamp from the latest response (t3)

* T3-最新の応答(T3)からのリモート送信タイムスタンプ

* T4 - local receive timestamp of the previous response (t4)

* T4-以前の応答のローカル受信タイムスタンプ(T4)

Clients MAY filter measurements based on the mode. The maximum number of dropped measurements in the basic mode SHOULD be limited in cases where the server does not support, or is not able to respond in, the interleaved mode. Clients that filter measurements based on the delay will implicitly prefer measurements in the interleaved mode over the basic mode, because they have a shorter delay due to a more accurate transmit timestamp (T3).

クライアントは、モードに基づいて測定値をフィルタリングできます。基本モードでの測定の最大数は、サーバーがインターリーブモードをサポートしていない、または応答できない場合に制限する必要があります。遅延に基づいて測定をフィルタリングするクライアントは、より正確な送信タイムスタンプ(T3)により短い遅延があるため、基本モードでインターリーブモードで測定を暗黙的に好むでしょう。

The server MAY limit the saving of the receive and transmit timestamps to requests that have an origin timestamp specific to the interleaved mode in order to not waste resources on clients using the basic mode. Such an optimization will delay the first interleaved response of the server to a client by one exchange.

サーバーは、基本モードを使用してクライアントにリソースを無駄にしないように、受信してタイムスタンプをインターリーブモードに固有のオリジンタイムスタンプを持つリクエストに送信することを制限する場合があります。このような最適化は、1つの交換により、クライアントへのサーバーの最初のインターリーブ応答を遅らせます。

A check for a non-zero origin timestamp works with NTP clients that always set the timestamp to zero. From the server's point of view, such clients start a new association with each request.

ゼロ以外のオリジンタイムスタンプのチェックは、常にタイムスタンプをゼロに設定するNTPクライアントと連携します。サーバーの観点から、そのようなクライアントは各リクエストと新しい関連性を開始します。

To avoid searching the saved receive timestamps for non-zero origin timestamps from requests conforming to the basic mode, the server can encode in low-order bits of the receive and transmit timestamps below the precision of the clock a flag indicating whether the timestamp is a receive timestamp. If the server receives a request with a non-zero origin timestamp that does not indicate that it is a receive timestamp of the server, the request does not conform to the interleaved mode, and it is not necessary to perform the search and/ or save the new receive and transmit timestamps.

保存されたゼロの起源のタイムスタンプを検索しないようにするために、基本モードに準拠しているリクエストからのゼロのオリジンのタイムスタンプのタイムスタンプは、クロックの正確さの下位にタイムスタンプの低次ビットでエンコードし、タイムスタンプが受信タイムスタンプであるかどうかを示すフラグをエンコードできます。サーバーがサーバーの受信タイムスタンプであることを示さないゼロ以外のオリジンタイムスタンプでリクエストを受信した場合、リクエストはインターリーブモードに準拠しておらず、検索を実行したり、新しい受信と送信を保存したりする必要はありません。

3. Interleaved Symmetric Mode
3. インターリーブ対称モード

The interleaved symmetric mode uses the same principles as the interleaved client/server mode. A packet in the interleaved symmetric mode has a transmit timestamp that corresponds to the transmission of the previous packet sent to the peer and an origin timestamp equal to the receive timestamp from the last packet received from the peer.

インターリーブした対称モードは、インターリーブクライアント/サーバーモードと同じ原理を使用します。インターリーブ対称モードのパケットには、ピアに送信された以前のパケットの送信に対応する送信タイムスタンプと、ピアから受信した最後のパケットからの受信タイムスタンプに等しいオリジンタイムスタンプがあります。

To enable synchronization in both directions of a symmetric association, both peers need to support the interleaved mode. For this reason, it SHOULD be disabled by default and enabled with an option in the configuration of the active side of the association.

対称的な関連付けの両方向で同期を可能にするには、両方のピアがインターリーブモードをサポートする必要があります。このため、デフォルトで無効にし、協会のアクティブ側の構成にオプションを使用して有効にする必要があります。

In order to prevent a peer from matching transmit timestamps with incorrect packets when its transmissions do not alternate with transmissions of its peer (e.g., they use different polling intervals) and one or more previous packets were lost, the use of the interleaved mode in symmetric associations requires additional restrictions.

ピアがピアの送信と交互に交互にならない場合(例えば、異なるポーリング間隔を使用する)、1つ以上の以前のパケットが失われた場合、ピアがタイムスタンプを誤ったパケットで送信するのを一致させるのを防ぐために、対称的な関連付けでインターリーブモードの使用には追加の制限が必要です。

Peers that have an association need to count valid packets received between their transmissions to determine in which mode a packet should be formed. A valid packet in this context is a packet that passed all NTP tests for duplicate, replayed, bogus, and unauthenticated packets. Other received packets may update the NTP state to allow the (re)initialization of the association, but they do not change the selection of the mode.

関連性のあるピアは、送信間で受信した有効なパケットをカウントして、どのモードAパケットを形成するかを決定する必要があります。このコンテキストでの有効なパケットは、すべてのNTPテストに合格したパケット、再生、再生、偽物、および認定されていないパケットを渡すことです。他の受信パケットは、NTP状態を更新して、関連付けの(再)初期化を許可する場合がありますが、モードの選択は変更されません。

A Peer A MUST NOT send a Peer B a packet in the interleaved mode unless all of the following conditions are met:

ピアAは、次のすべての条件が満たされない限り、ピアBにインターリーブモードでパケットを送信してはなりません。

1. Peer A has an active association with Peer B that was specified with the option enabling the interleaved mode, OR Peer A received at least one valid packet in the interleaved mode from Peer B.

1. ピアAは、インターリーブモードを有効にするオプションで指定されたピアBとのアクティブな関連性を持っています。

2. Peer A did not send a packet to Peer B since the time that it received the last valid packet from Peer B.

2. ピアAは、ピアBから最後の有効なパケットを受け取った時以来、ピアBにパケットを送信しませんでした

3. The previous packet that Peer A sent to Peer B was the only response to a packet received from Peer B.

3. ピアAがピアBに送信された以前のパケットは、ピアBから受け取ったパケットに対する唯一の応答でした。

The first condition is needed for compatibility with implementations that do not support, or are not configured for, the interleaved mode. The other conditions prevent a missing response from causing a mismatch between the remote transmit timestamp (T2) and local receive timestamp (T3), which would cause a large error in the measured offset and delay.

最初の条件は、インターリーブモードをサポートしていない、または構成されていない実装との互換性に必要です。他の条件により、失われた応答がリモート送信タイムスタンプ(T2)とローカル受信タイムスタンプ(T3)との間に不一致を引き起こすことができなくなり、測定されたオフセットと遅延に大きなエラーが発生します。

An example of packets exchanged in a symmetric association is shown in Figure 2. The minimum polling interval of Peer A is twice as long as the maximum polling interval of Peer B. The first packet sent by each peer is in the basic mode. The second and third packets sent by Peer A are in the interleaved mode. The second packet sent by Peer B is in the interleaved mode, but subsequent packets sent by Peer B are in the basic mode, because multiple responses are sent for each request.

対称的な関連付けで交換されたパケットの例を図2に示します。ピアAの最小ポーリング間隔は、ピアBの最大投票間隔の2倍の長さです。各ピアが送信する最初のパケットは基本モードです。Peer Aが送信した2番目と3番目のパケットは、インターリーブモードです。ピアBから送信された2番目のパケットはインターリーブモードですが、リクエストごとに複数の応答が送信されるため、ピアBから送信された後続のパケットは基本モードです。

               t2 t3       t6          t8 t9      t12         t14 t15
   Peer A -----+--+--------+-----------+--+--------+-----------+--+----
              /    \      /           /    \      /           /    \
             /      \    /           /      \    /           /      \
   Peer B --+--------+--+-----------+--------+--+-----------+--------+-
            t1       t4 t5          t7      t10 t11        t13      t16

   Mode     B      B      I         B      I      B         B      I
          +----+ +----+ +----+    +----+ +----+ +----+    +----+ +----+
   Origin | 0  | | t1~| | t2 |    | t3~| | t4 | | t3 |    | t3 | |t10 |
   Rx     | 0  | | t2 | | t4 |    | t4 | | t8 | |t10 |    |t10 | |t14 |
   Tx     | t1~| | t3~| | t1 |    | t7~| | t3 | |t11~|    |t13~| | t9 |
          +----+ +----+ +----+    +----+ +----+ +----+    +----+ +----+
        

Figure 2: Packet Timestamps in Interleaved Symmetric Mode

図2:インターリーブ対称モードのパケットタイムスタンプ

If Peer A has no association with Peer B and it responds with symmetric passive packets, it does not need to count the packets in order to meet the restrictions, because each request has at most one response. The processing of the requests can be implemented in the same way as a server handling requests in the interleaved client/ server mode.

ピアAにはピアBとの関連がなく、対称パッシブパケットで応答する場合、各リクエストには最大1つの応答があるため、制限を満たすためにパケットをカウントする必要はありません。リクエストの処理は、インターリーブクライアント/サーバーモードのサーバー処理要求と同じ方法で実装できます。

The peers can compute the offset and delay using one of the two sets of timestamps specified in Section 2. They can switch between the sets to minimize the interval between T1 and T4 in order to reduce the error in the measured delay.

ピアは、セクション2で指定されたタイムスタンプの2セットのいずれかを使用してオフセットを計算し、遅延することができます。セットを切り替えて、測定された遅延のエラーを減らすためにT1とT4の間隔を最小化できます。

4. Interleaved Broadcast Mode
4. インターリーブブロードキャストモード

A packet in the interleaved broadcast mode contains two transmit timestamps. One corresponds to the packet itself and is saved in the transmit timestamp field. The other corresponds to the previous packet and is saved in the origin timestamp field. The packet is compatible with the basic mode, which uses a zero origin timestamp.

インターリーブブロードキャストモードのパケットには、2つの送信タイムスタンプが含まれています。1つはパケット自体に対応し、送信タイムスタンプフィールドに保存されます。もう1つは前のパケットに対応し、Origin Timestampフィールドに保存されます。パケットは、ゼロのオリジンタイムスタンプを使用する基本モードと互換性があります。

An example of packets sent in the broadcast mode is shown in Figure 3.

ブロードキャストモードで送信されたパケットの例を図3に示します。

                  t1           t3           t5           t7
   Server   ------+------------+------------+------------+---------
                   \            \            \            \
                    \            \            \            \
   Client   ---------+------------+------------+------------+------
                     t2           t4           t6           t8

   Mode            B            I            I            I
                 +----+       +----+       +----+       +----+
   Origin        | 0  |       | t1 |       | t3 |       | t5 |
   Rx            | 0  |       | 0  |       | 0  |       | 0  |
   Tx            | t1~|       | t3~|       | t5~|       | t7~|
                 +----+       +----+       +----+       +----+
        

Figure 3: Packet Timestamps in Interleaved Broadcast Mode

図3:インターリーブ放送モードのパケットタイムスタンプ

A client that does not support the interleaved mode ignores the origin timestamp and processes all packets as if they were in the basic mode.

インターリーブモードをサポートしていないクライアントは、オリジンのタイムスタンプを無視し、すべてのパケットが基本モードにあるかのように処理します。

A client that supports the interleaved mode MUST check if the origin timestamp is not zero to detect packets conforming to the interleaved mode. The client SHOULD also compare the origin timestamp with the transmit timestamp from the previous packet to detect lost packets. If the difference is larger than a specified maximum (e.g., 1 second), the packet SHOULD NOT be used for synchronization in the interleaved mode to avoid a large error in the measurement.

インターリーブモードをサポートするクライアントは、インターリーブモードに適合するパケットを検出するために、Origin Timestampがゼロでないかどうかを確認する必要があります。また、クライアントは、紛失したパケットを検出するために、以前のパケットからのOrigin Timestampと送信タイムスタンプを比較する必要があります。差が指定された最大値(1秒など)よりも大きい場合、測定の大きなエラーを回避するために、インターリーブモードでの同期にパケットを使用しないでください。

The client computes the offset using the origin timestamp from the received packet and the local receive timestamp of the previous packet. If the client needs to measure the network delay, it SHOULD use the interleaved client/server mode. If it used the basic client/ server mode or symmetric mode, the less accurate measurement of the delay would also impact the accuracy of the offset measured in the interleaved broadcast mode.

クライアントは、受信したパケットと以前のパケットのローカル受信タイムスタンプからのオリジンタイムスタンプを使用してオフセットを計算します。クライアントがネットワークの遅延を測定する必要がある場合、インターリーブクライアント/サーバーモードを使用する必要があります。基本的なクライアント/サーバーモードまたは対称モードを使用した場合、遅延の精度の低い測定は、インターリーブブロードキャストモードで測定されたオフセットの精度にも影響します。

5. Impact of Implementation Errors
5. 実装エラーの影響

The interleaved modes make NTP more complex and more sensitive to implementation errors. Some errors that do not cause any problems between implementations supporting only the basic mode can cause an occasional missing or corrupted measurement when one or both sides support the interleaved mode. This section describes the impact of what could possibly be the most likely errors in the most commonly used mode -- client/server.

インターリーブモードにより、NTPは実装エラーに対してより複雑で敏感になります。基本モードのみをサポートする実装間で問題を引き起こさないいくつかのエラーは、片側または両側がインターリーブモードをサポートする場合、時折欠落または破損した測定を引き起こす可能性があります。このセクションでは、最も一般的に使用されるモードであるクライアント/サーバーで最も可能性の高いエラーである可能性があるものの影響について説明します。

If a client that does not support the interleaved mode sets the origin timestamp to values other than the transmit timestamp from the last valid server response, or zero, the origin timestamp can match a receive timestamp of a previous server response (possibly to a different client) and cause an unexpected interleaved response. The client is expected to drop the response as bogus due to having a wrong origin timestamp. If it did not check for bogus responses, it would get a corrupted measurement, possibly with a large error in the offset and delay. It would also be vulnerable to off-path attacks.

インターリーブモードをサポートしていないクライアントが、最後の有効なサーバー応答またはゼロからの送信タイムスタンプ以外の値にOrigin Timestampを設定する場合、Origin Timestampは以前のサーバー応答の受信タイムスタンプ(おそらく別のクライアントに対する)と一致し、予期しないインターリーブ応答を引き起こすことができます。クライアントは、原点のタイムスタンプが間違っているため、偽物として応答をドロップすることが期待されています。偽の応答をチェックしなかった場合、オフセットと遅延に大きなエラーが発生する場合、破損した測定値が得られます。また、オフパス攻撃に対しても脆弱です。

The worst-case scenario for this failure would be a client that specifically sets the origin timestamp to the server's receive timestamp, i.e., the client accidentally implemented the interleaved mode, but it does not accept interleaved responses. This client would still be able to synchronize its clock. It would drop interleaved responses as bogus and set the origin timestamp to the receive timestamp from the last valid response in the basic mode. As servers are required to not respond twice to the same origin timestamp in the interleaved mode, at least every other response would be in the basic mode and accepted by the client.

この失敗の最悪のシナリオは、サーバーの受信タイムスタンプにOrigin Timestampを特別に設定するクライアントです。つまり、クライアントは誤ってインターリーブモードを実装しましたが、インターリーブの応答を受け入れません。このクライアントは、時計を同期することができます。それは偽物としてインターリーブされた応答をドロップし、基本モードでの最後の有効な応答からOrigin Timestameを受信タイムスタンプに設定します。サーバーは、インターリーブモードで同じオリジンタイムスタンプに2回応答しないように必要であるため、少なくとも他のすべての応答は基本モードで、クライアントが受け入れます。

A missing or corrupted measurement can also be caused by problems on the server side. A server that does not ensure that the receive and transmit timestamps in its responses are unique in a sufficiently long interval can misinterpret requests formed correctly in the basic mode as interleaved and respond in the interleaved mode. The response would be dropped by the client as bogus.

測定の欠落または破損は、サーバー側の問題によって引き起こされる可能性があります。応答のタイムスタンプを受信して送信することを保証しないサーバーは、十分に長い間隔で一意であることが、基本モードでインターリーブとして正しく形成され、インターリーブモードで応答するリクエストを誤って解釈できます。応答は、クライアントによって偽物として削除されます。

A duplicated server receive timestamp can cause an expected interleaved response to contain a transmit timestamp that does not correspond to the transmission of the previous response from which the client copied the receive timestamp to the origin timestamp in the request, but a different response that contained the same receive timestamp. The response would be accepted by the client with a small error in the transmit timestamp equal to the difference between the transmit timestamps of the two different responses. As the requests corresponding to the two different responses were received at the same time (according to the server's clock), the two transmissions would be expected to be close to each other and the difference between them would be comparable to the error a basic response normally has in its transmit timestamp.

重複したサーバーの受信タイムスタンプは、予想されるインターリーブ対応を引き起こし、クライアントがリクエストで受信タイムスタンプをオリジンタイムスタンプにコピーした以前の応答の送信に対応しない送信タイムスタンプを含む可能性がありますが、同じ受信タイムスタンプを含む異なる応答です。応答は、2つの異なる応答の送信タイムスタンプ間の違いに等しい送信タイムスタンプに小さなエラーがあるクライアントによって受け入れられます。2つの異なる応答に対応するリクエストが同時に受信されたため(サーバーのクロックによると)、2つの送信は互いに近くになると予想され、それらの間の違いは、通常の送信タイムスタンプに基本的な応答があるエラーに匹敵します。

6. Security Considerations
6. セキュリティに関する考慮事項

The security considerations for time protocols in general are discussed in RFC 7384 [RFC7384]. Security considerations specific to NTP are discussed in RFC 5905 [RFC5905].

一般的な時間プロトコルのセキュリティ上の考慮事項については、RFC 7384 [RFC7384]で説明しています。NTPに固有のセキュリティ上の考慮事項は、RFC 5905 [RFC5905]で説明されています。

Security issues that apply to the basic modes discussed in RFC 5905 [RFC5905] also apply to the interleaved modes. These issues are described in "The Security of NTP's Datagram Protocol" [SECNTP].

RFC 5905 [RFC5905]で説明されている基本モードに適用されるセキュリティの問題も、インターリーブモードに適用されます。これらの問題は、「NTPのデータグラムプロトコルのセキュリティ」[SECNTP]で説明されています。

Clients and peers SHOULD NOT leak the receive timestamp in packets sent to other peers or clients (e.g., as a reference timestamp) to prevent off-path attackers from easily getting the origin timestamp needed to make a valid response in the interleaved mode.

クライアントとピアは、オフパス攻撃者がインターリーブモードで有効な応答を行うために必要なオリジンタイムスタンプを簡単に取得できないように、他のピアまたはクライアントに送信されたパケットの受信タイムスタンプを漏らしてはなりません。

Clients using the interleaved mode SHOULD randomize all bits of receive and transmit timestamps in their requests (i.e., provide a precision of 2^32 seconds) to make it more difficult for off-path attackers to guess the origin timestamp in the server response.

インターリーブモードを使用しているクライアントは、リクエストでタイムスタンプのすべてのビットをランダム化および送信する必要があります(つまり、2^32秒の精度を提供します)。

Unlike in the basic client/server mode, clients using the interleaved mode cannot set the origin timestamp in their requests to zero (i.e., reset the NTP association with every request) to make it more difficult to track them as they move between networks.

基本的なクライアント/サーバーモードとは異なり、インターリーブモードを使用するクライアントは、ネットワーク間を移動するときにそれらを追跡することをより困難にするために、リクエストでオリジンタイムスタンプをゼロに設定することができません(つまり、すべての要求とNTP関連をリセットすることはできません)。

Attackers can force the server to drop its timestamps in order to prevent clients from getting an interleaved response. They can send a large number of requests, send requests with a spoofed source address, or replay an authenticated request if the interleaved mode is enabled only for authenticated clients. Clients MUST NOT rely on servers to be able to respond in the interleaved mode.

攻撃者は、クライアントがインターリーブの反応を得るのを防ぐために、サーバーにタイムスタンプをドロップさせることができます。多数のリクエストを送信したり、スプーフィングされたソースアドレスでリクエストを送信したり、認証されたクライアントに対してインターリーブモードが有効になっている場合、認証されたリクエストを再生できます。クライアントは、インターリーブモードで応答できるようにサーバーに依存してはなりません。

Protecting symmetric associations in the interleaved mode against replay attacks is even more difficult than in the basic mode. In both modes, the NTP state needs to be protected between the reception of the last non-replayed response and transmission of the next request in order for the request to contain the origin timestamp expected by the peer. The difference is in the timestamps needed to complete a measurement. In the basic mode, only one valid response is needed at a time and it is used as soon as it is received, but the interleaved mode needs two consecutive valid responses. The NTP state needs to be protected at all times, so that the timestamps that are needed to complete the measurement when the second response is received will not be lost.

リプレイ攻撃に対するインターリーブモードで対称的な関連性を保護することは、基本モードよりもさらに困難です。両方のモードで、NTP状態は、ピアが予想されるオリジンタイムスタンプを封じ込めるために、最後の非表現応答の受容と次の要求の送信の間に保護する必要があります。違いは、測定を完了するために必要なタイムスタンプにあります。基本モードでは、一度に1つの有効な応答のみが必要であり、受信するとすぐに使用されますが、インターリーブモードには2つの連続した有効な応答が必要です。NTP状態は常に保護する必要があります。そのため、2番目の応答が受信されたときに測定を完了するために必要なタイムスタンプは失われません。

7. IANA Considerations
7. IANAの考慮事項

This document has no IANA actions.

このドキュメントにはIANAアクションがありません。

8. References
8. 参考文献
8.1. Normative References
8.1. 引用文献
   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.
        
   [RFC5905]  Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
              "Network Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
              <https://www.rfc-editor.org/info/rfc5905>.
        
   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.
        
8.2. Informative References
8.2. 参考引用
   [RFC5906]  Haberman, B., Ed. and D. Mills, "Network Time Protocol
              Version 4: Autokey Specification", RFC 5906,
              DOI 10.17487/RFC5906, June 2010,
              <https://www.rfc-editor.org/info/rfc5906>.
        
   [RFC7384]  Mizrahi, T., "Security Requirements of Time Protocols in
              Packet Switched Networks", RFC 7384, DOI 10.17487/RFC7384,
              October 2014, <https://www.rfc-editor.org/info/rfc7384>.
        
   [RFC9109]  Gont, F., Gont, G., and M. Lichvar, "Network Time Protocol
              Version 4: Port Randomization", RFC 9109,
              DOI 10.17487/RFC9109, August 2021,
              <https://www.rfc-editor.org/info/rfc9109>.
        
   [SECNTP]   Malhotra, A., Van Gundy, M., Varia, M., Kennedy, H.,
              Gardner, J., and S. Goldberg, "The Security of NTP's
              Datagram Protocol", Cryptology ePrint Archive, Paper
              2016/1006, 2016, <https://eprint.iacr.org/2016/1006>.
        
Acknowledgements
謝辞

The interleaved modes described in this document are based on the implementation written by David Mills in the NTP project (https://www.ntp.org). The specification of the broadcast mode is based purely on this implementation. The specification of the symmetric mode has some modifications. The client/server mode is specified as a new mode compatible with the symmetric mode. It is a simplified special case of the symmetric mode, analogously to how the basic client/server mode is a special case of the basic symmetric mode.

このドキュメントで説明されているインターリーブモードは、NTPプロジェクト(https://www.ntp.org)でDavid Millsによって書かれた実装に基づいています。ブロードキャストモードの仕様は、純粋にこの実装に基づいています。対称モードの仕様には、いくつかの変更があります。クライアント/サーバーモードは、対称モードと互換性のある新しいモードとして指定されています。これは、基本的なクライアント/サーバーモードが基本的な対称モードの特別なケースであると同様に、対称モードの単純化された特殊なケースです。

The authors would like to thank Doug Arnold, Roman Danyliw, Reese Enghardt, Daniel Franke, Benjamin Kaduk, Erik Kline, Catherine Meadows, Tal Mizrahi, Steven Sommars, Harlan Stenn, Kristof Teichel, and Gunter Van de Velde for their useful comments and suggestions.

著者は、ダグ・アーノルド、ローマン・ダニリウ、リース・エンガルト、ダニエル・フランケ、ベンジャミン・カドゥク、エリック・クライン、キャサリン・メドウズ、タル・ミズラヒ、スティーブン・ソマーズ、ハーラン・ステン、クリストフ・テイチェル、グンター・ヴァン・デ・ベルデが有用なコメントと提案に感謝します。

Authors' Addresses
著者のアドレス
   Miroslav Lichvar
   Red Hat
   Purkynova 115
   612 00 Brno
   Czech Republic
   Email: mlichvar@redhat.com
        
   Aanchal Malhotra
   Boston University
   111 Cummington St
   Boston, MA 02215
   United States of America
   Email: aanchal4@bu.edu