ネットワーク タイム プロトコル

ネットワーク タイム プロトコル

国際標準	RFC  5905
開発者	デビッド・L・ミルズ、ハーラン・ステン、ネットワークタイム財団
紹介された	1985年; 39年前 （1985年）

ネットワーク タイム プロトコル( NTP ) は、パケット交換型の可変遅延データ ネットワーク上のコンピュータ システム間のクロック同期のためのネットワーク プロトコルです。1985 年より前から運用されている NTP は、現在使用されている最も古いインターネット プロトコルの 1 つです。NTP は、デラウェア大学のDavid L. Millsによって設計されました。

NTP は、参加しているコンピュータを協定世界時(UTC)から数ミリ秒以内に同期することを目的としています。 ^{[1] : 3}これは、正確なタイムサーバーを選択するために、 Marzullo のアルゴリズムの修正版である交差アルゴリズムを使用し、変動するネットワーク遅延の影響を軽減するように設計されています。NTP は通常、パブリックインターネット上で数十ミリ秒以内に時間を維持でき、理想的な条件下ではローカルエリアネットワークで 1 ミリ秒以上の精度を達成できます。非対称ルートとネットワークの輻輳により、100 ミリ秒以上の誤差が発生する可能性があります。^{[2] [3]}

このプロトコルは通常、クライアント・サーバー・モデルの観点から説明されますが、両方のピアが相手を潜在的な時間ソースと見なすピアツーピア関係でも簡単に使用できます。 ^{[1] : 20}実装は、ポート番号123でユーザーデータグラムプロトコル(UDP)を使用してタイムスタンプを送受信します。 ^{[4] [5] : 16}また、ブロードキャストまたはマルチキャストを使用することもできます。この場合、クライアントは、最初の往復の調整交換の後、受動的に時間の更新をリッスンします。^{[3] NTP は、迫っている}うるう秒調整の警告を提供しますが、ローカルタイムゾーンや夏時間に関する情報は送信されません。^{[2] [3]}

現在のプロトコルはバージョン4（NTPv4）^[5]であり、バージョン3と下位互換性があります。^[6]

1979年、ニューヨークで開催された全米コンピュータ会議で、大西洋を横断する衛星ネットワーク上で稼働するインターネットサービスのおそらく最初の公開デモンストレーションで、ネットワーク時刻同期テクノロジが使用されました。このテクノロジは後に1981年のインターネット エンジニアリング ノート (IEN) 173 ^[18]で説明され、そこから公開プロトコルが開発され、RFC  778 に文書化されました。このテクノロジは、Hello ルーティング プロトコルの一部として最初にローカル エリア ネットワークに導入され、ネットワーク プロトタイピングで使用される実験的なオペレーティング システムであるFuzzball ルーターに実装され、長年にわたって稼働しました。

関連するネットワークツールは当時も今も利用可能である。イベントの時刻を記録するためのDaytimeプロトコルとTimeプロトコル、 ICMP タイムスタンプメッセージ、IP タイムスタンプオプション ( RFC  781) などがある。NTP のデータ分析とクロック規律アルゴリズムはないものの、より完全な同期システムには、選出アルゴリズムを使用してすべてのクライアントにサーバーを割り当てる Unix デーモンtimedがある^{。 [19]}と、 NTP ストラタムモデルに似たサーバーの階層を使用するDigital Time Synchronization Service (DTSS) がある。

1985 年に、NTP バージョン 0 (NTPv0) が Fuzzball と Unix の両方に実装され、NTP パケット ヘッダーと往復遅延およびオフセットの計算 (NTPv4 にも引き継がれています) がRFC  958 に文書化されました。当時利用可能なコンピュータとネットワークは比較的低速でしたが、大西洋をまたぐリンクでは通常 100ミリ秒を超える精度が得られ、イーサネットネットワークでは数十ミリ秒の精度が得られました。

1988年、NTPv1プロトコルのより完全な仕様と関連アルゴリズムがRFC 1059で公開されました。これは、 RFC  956 に記載されている実験結果とクロックフィルタアルゴリズムに基づいており、クライアントサーバーモードとピアツーピアモードを説明した最初のバージョンでした。1991年、NTPv1のアーキテクチャ、プロトコル、アルゴリズムは、 IEEE Transactions on CommunicationsにDavid L. Millsが論文を発表したことで、より広いエンジニアリングコミュニティの注目を集めました。^[20]

1989年にRFC 1119が発行され、NTPv2を状態マシン で定義し、その動作を記述する疑似コードが付属しました。このRFCでは管理プロトコルと暗号化認証方式が導入され、これらはアルゴリズムの大部分とともにNTPv4にも引き継がれました。しかし、NTPv2の設計はDTSSコミュニティから形式的な正確さに欠けると批判され、クロック選択手順はNTPv3以降ではMarzulloのアルゴリズムを組み込むように変更されました。^[21]

1992 年、RFC  1305 で NTPv3 が定義されました。RFC には、参照クロックから最終クライアントまでのすべてのエラー ソースの分析が含まれており、複数の候補が一致しないように見える場合に、最適なサーバーを選択するのに役立つメトリックの計算が可能になりました。ブロードキャスト モードが導入されました。

その後、新機能が追加され、アルゴリズムの改良が行われたため、新しいプロトコルバージョンが必要であることが明らかになりました。^[22] 2010年に、 NTPv4の仕様案を含むRFC 5905が公開されました。 ^{[23]ミルズが}デラウェア大学を退職した後、リファレンス実装は現在、ハーラン・ステンが率いるオープンソースプロジェクトとして維持されています。 ^{[24] [25]} IANA側では、ntp（ネットワークタイムプロトコル）作業グループが提案されたドラフトのレビューを担当しています。^[26]

このプロトコルはNTPv4から大幅に進歩しました。^[23] 2022年現在^[update]、プロトコルの更新を説明する3つのRFC文書が公開されていますが、^{[5] NTS（} RFC  8915）などの多数の周辺標準は含まれていません。 ^[26]ミルズは彼のページで「NTPv5」の計画について言及していましたが、公開されることはありませんでした。 [ ^23] chronyのM. Lichvarによって「NTPv5」と呼ばれる無関係なドラフトが2020年に開始され、セキュリティ、精度、スケーリングの変更が含まれています。^[27]

NTP が古いタイムプロトコルの使用に取って代わったにもかかわらず、一部のユースケースでは完全なプロトコルが複雑すぎると感じられました。1992 年に、このニッチを埋めるためにシンプルネットワークタイムプロトコル( SNTP ) が定義されました。SNTPv3 標準では、長期間の状態の保存が不要な NTPv3 の使用方法が説明されています。トポロジは基本的にタイムプロトコルと同じになり、サーバーは 1 つだけ使用されます。 ^[10] 1996 年に、SNTP は当時開発中だった NTPv4 の一部の機能を備えたSNTPv4 ^[12]に更新されました。SNTPv4 の現在のバージョンは、2010 年にメインの NTPv4 標準に統合されました。 ^[5] SNTP は新しいプロトコルを定義していないため、NTP と完全に相互運用可能です。^{[28] : §14}ただし、単純なアルゴリズムでは時間の精度が低下するため、SNTP ソースから時間を同期することはお勧めできません。^[13]

NTP は、階層的で半階層化されたタイム ソース システムを使用します。この階層の各レベルはストラタムと呼ばれ、最上位の参照クロックに対して 0 から始まる番号が割り当てられます。ストラタムnサーバーに同期されたサーバーは、ストラタムn + 1 で実行されます。この番号は参照クロックからの距離を表し、階層内での循環的な依存関係を防ぐために使用されます。ストラタムは必ずしも品質や信頼性を示すものではありません。ストラタム 3 のタイム ソースが他のストラタム 2 のタイム ソースよりも高品質であることはよくあります。^[a]ストラタム 0、1、2、3 の簡単な説明を次に示します。

階層0

これらは、原子時計、GNSS（GPSを含む）やその他の電波時計、またはPTP同期時計などの高精度の計時デバイスです。 ^{[29]これらは、接続されたコンピュータで}割り込みとタイムスタンプをトリガーする非常に正確な毎秒パルス信号を生成します。ストラタム0デバイスは、リファレンスクロックとも呼ばれます。NTPサーバーは、ストラタム0として自分自身をアドバタイズすることはできません。NTPパケットでストラタムフィールドが0に設定されている場合は、未指定のストラタムを示します。^[30]

層 1

これらは、接続されたストラタム0デバイスと数マイクロ秒以内にシステム時刻が同期されているコンピュータです。ストラタム1サーバーは、健全性チェックとバックアップのために他のストラタム1サーバーとピアリングする場合があります。^[31]これらはプライマリタイムサーバーとも呼ばれます。^{[2] [3]}

層2

これらは、ネットワーク経由で Stratum 1 サーバーに同期されるコンピューターです。多くの場合、Stratum 2 コンピューターは複数の Stratum 1 サーバーにクエリを実行します。Stratum 2 コンピューターは、他の Stratum 2 コンピューターとピアリングして、ピア グループ内のすべてのデバイスに、より安定した堅牢な時間を提供することもできます。

層3

これらは、Stratum 2 サーバーに同期されたコンピューターです。ピアリングとデータ サンプリングには Stratum 2 と同じアルゴリズムが採用されており、それ自体が Stratum 4 コンピューターのサーバーとして機能するなど、さまざまな機能を備えています。

ストラタムの上限は15です。ストラタム16はデバイスが同期されていないことを示すために使用されます。各コンピュータのNTPアルゴリズムは、ベルマンフォード最短パススパニングツリーを構築するために相互作用し、すべてのクライアントのストラタム1サーバーへの累積ラウンドトリップ遅延を最小限に抑えます。^{[1] ：20}

プロトコルは、stratum に加えて、参照識別子 (refid) に基づいて各サーバーの同期ソースを識別することができます。

ストラタム2以下のサーバーの場合、refidは上流タイムサーバーのIPアドレスをエンコードした形式です。IPv4の場合、これは単に32ビットのアドレスです。IPv6の場合、これはソースアドレスのMD5ハッシュの最初の32ビットになります。refidは、タイミングループを第一に検出して防止するために使用されます。^[5]

キス・オ・デス（KoD）パケットの場合、refidフィールドにはステータスワードが入ります。これは、サーバーが休止できるようにクライアントにリクエストの送信を停止するように指示するものです。^[5]例としては、INIT（初期化）、STEP（ステップ時間の変更）、RATE（クライアントのリクエストが速すぎる）などがあります。^[33]プログラム出力では、パケットで送信されなかったコードを使用してエラーを示すこともあります。たとえば、ネットワークの切断を示すXFACなどです。^[32]

IANAはrefidソース名とKoDコードのレジストリを管理しています。非公式の割り当てがまだ存在する可能性があります。^[34]

NTP が使用する64 ビットのバイナリ固定小数点タイムスタンプは、32 ビットの秒部分と 32 ビットの小数秒部分で構成されており、2 ^{32秒 (136 年) ごとに}ロールオーバーする時間スケールと、2 ⁻³²秒 (233 ピコ秒)の理論的な解像度を提供します。NTP は 1900 年 1 月 1 日をエポックとして使用します。したがって、最初のロールオーバーは 2036 年 2 月 7 日に発生します。^{[35] [36]}

NTPv4 では、128 ビットの日付形式が導入されています。64 ビットが秒、64 ビットが小数秒です。この形式の最も重要な 32 ビットは、ほとんどの場合にロールオーバーの曖昧さを解決する紀元番号です。^[37]ミルズによると、「小数部の 64 ビット値は、光子が光速で電子を通過するのにかかる時間を解決するのに十分です。64 ビットの秒値は、宇宙が暗くなるまで明確な時間表現を提供するのに十分です。」^{[38] [b]}

典型的なNTPクライアントは、1つ以上のNTPサーバーを定期的にポーリングします。クライアントは、時間オフセットと往復遅延を計算する必要があります。時間オフセットθは、2つのクロック間の絶対時間の差が正または負（クライアント時間>サーバー時間）です。これは次のように定義されます。

$${\displaystyle \theta ={\frac {(t_{1}-t_{0})+(t_{2}-t_{3})}{2}},}$$ そして 往復遅延δは $${\displaystyle \delta ={(t_{3}-t_{0})-(t_{2}-t_{1})},}$$

• t _{0 は}クライアントのリクエストパケット送信のタイムスタンプです。
• t _1はリクエストパケット受信時のサーバーのタイムスタンプです。
• t _2は、応答パケットの送信時のサーバーのタイムスタンプであり、
• t _3はクライアントの応答パケット受信のタイムスタンプである。^{[1] : 19}

オフセットの式を導出するには、要求パケット と応答パケットについて、 θ を解くと時間オフセットの定義が得られることに注意してください。 $${\displaystyle t_{0}+\theta +\delta /2=t_{1}}$$$${\displaystyle t_{3}+\theta -\delta /2=t_{2}}$$

θとδの値はフィルターに通され、統計分析（「緩和」）にかけられます。外れ値は破棄され、残りの 3 つの候補から時間オフセットの推定値が導出されます。次に、クロック周波数が調整され、オフセットが徐々に減少し（「規律」）、フィードバック ループが作成されます。^{[1] : 20}

正確な同期は、クライアントとサーバー間の着信ルートと発信ルートの両方が対称的な公称遅延を持つ場合に達成されます。ルートに共通の公称遅延がない場合、前方と後方の移動時間の差の半分の系統的バイアスが存在します。非対称性を測定するためにいくつかのアプローチが提案されていますが^[39]、実用的な実装の中ではchronyだけが1つを組み込んでいるようです。^{[40] [41]}

NTPリファレンス実装は、プロトコルとともに 20 年以上にわたって継続的に開発されてきました。新機能が追加されても、下位互換性は維持されてきました。この実装には、特にクロックを規律するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用するサーバーと同期すると誤動作する可能性があります。このソフトウェアは、パーソナル コンピューターを含むほぼすべてのコンピューティング プラットフォームに移植されています。Unixではntpdと呼ばれるデーモンとして、Windows ではサービスとして実行されます。リファレンス クロックがサポートされており、そのオフセットはリモート サーバーと同じ方法でフィルター処理および分析されますが、通常はより頻繁にポーリングされます。^{[1] : 15–19}この実装は 2017 年に監査され、14 件の潜在的なセキュリティ問題が見つかりました。^[42]

Windows 2000以降のすべてのMicrosoft Windowsバージョンには、コンピュータの時計をNTPサーバーに同期する機能を備えた Windowsタイムサービス（W32Time）^{[43]が含まれています。}

W32TimeはもともとKerberosバージョン5認証プロトコルの目的で実装されました。このプロトコルでは、リプレイ攻撃を防ぐために正しい値から5分以内の時間を要求していました。Windows 2000 Server（およびWindows XP）のネットワークタイムサーバーはNTP規律同期を実装しておらず、NTP/SNTP補正によるローカル規律同期のみを実装しています。^[44]

Windows Server 2003およびWindows Vista以降、W32TimeのNTPプロバイダーはNTPv3の重要なサブセットと互換性を持つようになりました。^[45] Microsoftは、W32Timeは1秒の精度で時刻同期を確実に維持できないと述べています。^[46]より高い精度が必要な場合は、Microsoftは新しいバージョンのWindowsまたは別のNTP実装を使用することを推奨しています。^[47]

Windows 10バージョン1607およびWindows Server 2016以降では、W32Timeは特定の動作条件下で1秒、50ミリ秒、または1ミリ秒の時間精度に達するように構成できます。^{[48] [46] [49]}

2004年、OpenBSDのHenning Brauerは、セキュリティを重視し、権限を分離した設計を取り入れたNTPv3/SNTPv4 ^{[50]実装である}OpenNTPDを発表しました。これは、OpenBSDユーザーのよりシンプルで一般的なニーズに焦点を当てていますが、既存のNTPサーバーとの互換性を保ちながら、いくつかのプロトコルセキュリティの改善も含まれています。コードベースがシンプルになったことで、このユースケースでは不必要であると見なされた精度が犠牲になっています。^[51]ポータブルバージョンは、Linuxパッケージリポジトリで入手できます。

NTPsec は、体系的にセキュリティが強化されたリファレンス実装のフォークです。フォークポイントは 2015 年 6 月で、2014 年の一連の侵害に対応して行われました。^[52]最初の製品リリースは 2017 年 10 月に出荷されました。^[53]安全でない機能の削除、旧式のハードウェアのサポートの削除、旧式の Unix バリアントのサポートの削除により、NTPsec は元のコードベースの 75% を削減することができ、残りの監査が容易になりました。^[54] 2017 年のコード監査では、元のリファレンス実装には存在しなかった 2 つを含む 8 つのセキュリティ問題が見つかりました。ただし、NTPsec はリファレンス実装に残っていた他の 8 つの問題に悩まされることはありませんでした。^[55]

chrony は、主にRed Hatがスポンサーとなっている独立した NTP 実装で、同社のディストリビューションではデフォルトのタイム プログラムとして使用されています。^[56]ゼロから作成された chrony は、よりシンプルなコードベースで、セキュリティが向上し、 ^[57]リソース消費が少なくなっています。^[58]ただし、精度に妥協はなく、多くの状況でリファレンスの ntpd よりも高速かつ優れた同期を実現します。不安定でスリープ モードになったり、インターネットへの接続が断続的になる一般的なコンピューターにも十分対応できます。また、より不安定な環境である仮想マシン向けにも設計されています。^[59]

Chrony は、ほんの数件の事故しか発生していないことから、「信頼できる」と評価されています。^[60]ネットワーク アダプタのハードウェア タイムスタンプを使用することで、LAN 接続の精度を向上させることができます。 ^[40]ネットワーク タイム セキュリティ (NTS) のサポートはバージョン 4.0 で追加されました。^[61] chrony はGNU General Public License バージョン 2で利用可能で、1997 年に Richard Curnow によって作成され、現在は Miroslav Lichvar によって保守されています。^[58]

ntpd-rs は、NTP プロトコルのセキュリティ重視の実装であり、メモリ安全なインターネット インフラストラクチャの作成を目的とした Prossimo イニシアチブの一環としてInternet Security Research Groupによって開発されました。ntpd -rs は、NTP 実装に必要なリアルタイム コンピューティング機能に加えて、メモリの安全性を保証するプログラミング言語で実装されています。ntpd-rs は、 Lets Encrypt非営利認証局などのセキュリティに敏感な環境で使用されています。^{[62] ntpd-rs は、} Precision Time Protocol実装「statime」も含まれる「Pendulum」プロジェクトの一部です。両方のプロジェクトは、 ApacheおよびMITソフトウェア ライセンス の下で利用できます。

• Ntimedは2014年にFreeBSDのPoul-Henning Kampによって開始され、2015年に放棄されました。 ^[63]実装はLinux Foundationによって後援されました。 ^[64]
• systemd-timesyncdは、 systemdに組み込まれているSNTPクライアントです。これは、バージョン「bookworm」 ^{[65]以降の}Debianと、下流のUbuntuで使用されています。

うるう秒イベント当日、ntpd は設定ファイル、接続された参照クロック、またはリモート サーバーから通知を受け取ります。イベント中は NTP クロックは実際には停止しますが、時間は厳密に増加しているように見える必要があるという要件のため、システム時間を照会するプロセスは、イベントの順序を維持しながら、わずかな量ずつ増加させます。負のうるう秒が必要になった場合は、23:59:59 をスキップして、23:59:58、00:00:00 のシーケンスで削除されます。^[66]

代替の実装は、うるう秒をUTC時間の正午から正午までの24時間の間に段階的に導入するというもので、リープスミアリングと呼ばれます。この実装は、Google（社内およびパブリックNTPサーバーの両方）、Amazon AWS、^[67]、Facebookで使用されています。^{[68] Chronyは、} smoothtimeおよびleapsecmode構成でうるう秒をサポートしていますが、このような使用は、うるう秒が非標準であり、混在するとクライアントの計算が狂うため、パブリックNTPプールと混在して使用しないでください。^[69]

システム時間の調整は一般に特権操作であるため、NTP コードの一部またはすべてを何らかの権限で実行して、コア機能をサポートする必要があります。NTP コードベースのリファレンス実装では、他のセキュリティ上の問題がいくつか特定されていますが、2009 年に発生した問題^{[どれですか? ]}は大きな懸念を引き起こしました。^{[70] [71]}このプロトコルは、その歴史を通じて改訂とレビューが行われてきました。リファレンス実装のコードベースは、数年にわたって複数のソースからのセキュリティ監査を受けています。^[72]

スタックバッファオーバーフローの脆弱性が発見され、2014年に修正されました。^[73] Appleはこの脆弱性を非常に懸念し、初めて自動更新機能を使用しました。^[74]ルートユーザーの資格情報で実行されているリファレンス実装を使用しているシステムでは、これにより無制限のアクセスが許可される可能性があります。OpenNTPDなどの他の実装は、コードベースが小さく、権限の分離などの他の緩和策を採用しているため、この欠陥の影響を受けません。^[75]

Linux FoundationのCore Infrastructure Initiativeの委託により2017年に実施された3つのNTP実装のセキュリティ監査では、セキュリティの観点からNTP ^{[76] [77]}とNTPsec ^{[78]はどちらもChrony [79]}よりも問題があることが示唆されました。^[80]

NTP サーバーは、認証のためにパケットが暗号署名されていない限り、中間者攻撃の影響を受けやすい。 ^[81]計算オーバーヘッドにより、特にサービス拒否攻撃の際には、混雑したサーバーではこれが非現実的になる可能性がある。^[82]中間者攻撃によるNTP メッセージのなりすましは、クライアント コンピューターの時計を変更するために使用され、暗号キーの有効期限のバイパスに基づくさまざまな攻撃を可能にする。 ^[83]特定されている偽の NTP メッセージの影響を受けるサービスには、TLS、DNSSEC、さまざまなキャッシュ スキーム (DNS キャッシュなど)、Border Gateway Protocol (BGP)、Bitcoin ^[要出典]、およびいくつかの永続ログイン スキームがある。^{[84] [85]}

NTPは分散型サービス拒否攻撃に使用されています。^{[86] [87]} NTPサーバーに小さなクエリが送信され、返信IPアドレスがターゲットアドレスに偽装されます。DNS増幅攻撃と同様に、サーバーははるかに大きな応答で応答し、攻撃者はターゲットに送信されるデータの量を大幅に増やすことができます。攻撃への参加を回避するには、NTPサーバーソフトウェアをアップグレードするか、サーバーを外部クエリを無視するように構成することができます。^[88]

NTP 自体には、クライアントに対するサーバの認証のサポートが含まれています。NTPv3 は対称キーモードをサポートしていますが、これは MITM に対しては役に立ちません。IPSecから適応された NTPv4 の「autokey」と呼ばれる公開キーシステムは、便利な認証を提供しますが、^[81]ビジー状態のサーバには実用的ではありません。 ^[82] Autokey は後にいくつかの設計上の欠陥があることも判明しましたが、^[89]メッセージ認証コードの変更を除いて修正は公開されていません。^[16] Autokey はもう使用しないでください。^[90]

ネットワークタイムセキュリティ（NTS）は、 TLSとAEADを備えたNTPv4の安全なバージョンです。^[91]以前の試みに対する主な改善点は、別の「鍵確立」サーバーが重い非対称暗号化を処理し、それが一度だけ実行されることです。サーバーがダウンしても、以前のユーザーはMITMを恐れることなく時間を取得できます。^{[92] NTSは現在、} Cloudflareを含むいくつかのタイムサーバーでサポートされています。 ^{[93] [94]} NTPSecとchronyでサポートされています。^[95]

マイクロソフトは、 WindowsドメインIDを使用してNTPv3/SNTPv4パケットを認証するアプローチも採用しており、MS-SNTPと呼ばれています。^[96]このシステムは、ドメイン接続にsambaを使用して、リファレンスntpdとchronyに実装されています。 ^[97]

• アラン分散 – クロックと発振器の周波数安定性の尺度
• 時計ネットワーク – 同じ時間を表示するように自動的に同期される時計のセット
• 国際原子時 – 原子時計に基づく時間基準
• IRIG タイムコード – 時間情報を転送するための標準フォーマット
• ニッツ
• NTP プール – 時刻同期を提供するネットワーク コンピュータの動的なコレクション
• Ntpdate  – コンピュータの時間を同期するコンピュータ プログラム
• 高精度時間プロトコル – ネットワーク時間同期プロトコル

• ネットワーク タイム プロトコル バージョン 4 ( NTPv4) の管理オブジェクトの定義。doi : 10.17487/ RFC5907。RFC 5907 。
• DHCPv6 のネットワークタイムプロトコル (NTP) サーバー オプション。doi : 10.17487/ RFC5908。RFC 5908 。

• 公式サイト
• 公式 Stratum ワンタイム サーバー リスト
• IETF NTPワーキンググループ
• Microsoft Windows の正確な時間ガイドなど
• 時間とNTPの論文
• NTP 調査 2005
• ntpd と互換性のある現在の NIST うるう秒ファイル
• David L. Mills、「NTP タイムの簡潔な歴史: インターネット タイムキーパーの告白」(PDF) 、 2021 年 2 月 7 日取得