Loading article…
 | |
| 国際規格 | RFC 5905 |
|---|---|
| 開発元 | デビッド・L・ミルズ、ハーラン・ステン、ネットワーク・タイム・ファウンデーション |
| 紹介された | 1985年 （1985年） |
ネットワークタイムプロトコル（NTP）は、パケット交換方式の可変遅延データネットワーク上でコンピュータシステム間の時刻同期を行うためのネットワークプロトコルです。1985年以前から運用されているNTPは、現在も使用されているインターネットプロトコルの中で最も古いものの1つです。NTPは、デラウェア大学のデイビッド・L・ミルズによって設計されました。
NTP は、参加しているコンピュータを協定世界時(UTC)から数ミリ秒以内の精度で同期させることを目的としています。 [ 1 ] : 3 NTPは、正確なタイム サーバーを選択するためにMarzullo アルゴリズムの修正版である交差アルゴリズムを使用し、ネットワーク遅延の変動の影響を軽減するように設計されています。NTP は通常、パブリックインターネット上で数十ミリ秒以内の精度で時間を維持でき、理想的な条件下ではローカル エリア ネットワークで 1 ミリ秒未満の精度を達成できます。非対称ルートやネットワークの混雑により、100ミリ秒以上の誤差が生じる可能性があります。 [ 2 ] [ 3 ]
このプロトコルは通常クライアント・サーバーモデルで説明されますが、ピアツーピア関係でも同様に使用できます。ピアツーピア関係では、両方のピアが相手を潜在的な時刻ソースとみなします。[ 1 ] : 20実装では、ユーザーデータグラムプロトコル(UDP)を使用してタイムスタンプを送受信します。サービスは通常ポート番号123 で動作し、一部のモードでは両側がこのポート番号を使用します。[ 4 ] [ 5 ] : 16また、ブロードキャストまたはマルチキャストを使用することもできます。この場合、クライアントは最初のラウンドトリップのキャリブレーション交換の後、時刻の更新をパッシブに受信します。[ 3 ] NTP は、迫りくるうるう秒の調整に関する警告を提供しますが、ローカルタイムゾーンや夏時間に関する情報は送信されません。[ 2 ] [ 3 ]
一般的なNTPクライアントは、1つ以上のNTPサーバーを定期的にポーリングします。クライアントは、時刻オフセットと往復遅延を計算する必要があります。時刻オフセットθは、2つのクロック間の絶対時刻の正または負（クライアント時刻 > サーバー時刻）の差です。これは次のように定義されます。
往復遅延δは どこ
オフセットの式を導出するには、要求パケットの場合、 応答パケットについては、 θ について解くと、時間オフセットの定義が得られる。
θとδの値はフィルタを通過し、統計分析（「緩和」）にかけられます。外れ値は破棄され、残りの3つの候補から時間オフセットの推定値が導き出されます。その後、クロック周波数が調整され、オフセットが徐々に減少します（「規律」） 。これによりフィードバックループが形成されます。[ 1 ]： 20
クライアントとサーバー間の受信ルートと送信ルートの両方の公称遅延が対称である場合に、正確な同期が実現されます。ルートに共通の公称遅延がない場合、順方向と逆方向の移動時間の差の半分に相当する系統的なバイアスが存在します。非対称性を測定するために多くの手法が提案されていますが、[ 7 ]実用的な実装の中では、chrony だけがその手法を取り入れているようです。[ 8 ] [ 9 ]
1979年、ニューヨークで開催された全米コンピュータ会議において、大西洋横断衛星ネットワーク上で動作するインターネットサービスの、おそらく最初の公開デモンストレーションで、ネットワーク時刻同期技術が使用されました。この技術は後に1981年のインターネット技術ノート（IEN）173 [ 21 ]で説明され、そこからRFC 778に文書化された公開プロトコルが開発されました。この技術は、Helloルーティングプロトコルの一部としてローカルエリアネットワークに初めて導入され、ネットワークプロトタイピングに使用される実験的なオペレーティングシステムであるFuzzballルーターに実装され、そこで長年にわたって動作しました。
当時も今も、関連するネットワークツールは他にもあります。イベントの時刻を記録するためのDaytimeおよびTimeプロトコル、 ICMP タイムスタンプメッセージ、および IP タイムスタンプ オプション ( RFC 781 ) などです。NTP のデータ分析やクロック同期アルゴリズムは備えていませんが、より完全な同期システムとしては、選挙アルゴリズムを使用してすべてのクライアントにサーバーを割り当てるUnixデーモンtimed [ 22 ]や、 NTP の階層モデルに似たサーバーの階層を使用するDigital Time Synchronization Service (DTSS) などがあります。
1985年、NTPバージョン0（NTPv0）がFuzzballとUnixの両方に実装され、NTPパケットヘッダー、往復遅延、オフセットの計算方法（これらはNTPv4にも引き継がれている）がRFC 958に文書化された。当時利用可能だったコンピュータやネットワークは比較的低速であったにもかかわらず、大西洋を横断するリンクでは通常100ミリ秒以下の精度が得られ、イーサネットネットワークでは数十ミリ秒の精度が得られた。
1988 年、関連アルゴリズムを含む NTPv1 プロトコルのより完全な仕様がRFC 1059で公開されました。これはRFC 956で文書化された実験結果とクロックフィルタアルゴリズムに基づいており、クライアント/サーバモードとピアツーピアモードを記述した最初のバージョンでした。1991 年、 David L. MillsによるIEEE Transactions on Communications の記事の公開により、NTPv1 のアーキテクチャ、プロトコル、およびアルゴリズムがより広範なエンジニアリングコミュニティの注目を集めました。[ 23 ]
1989年にRFC 1119が公開され、ステートマシンを用いてNTPv2が定義され、その動作を擬似コードで記述した。このRFCでは、管理プロトコルと暗号認証方式が導入され、これらはアルゴリズムの大部分とともにNTPv4にも引き継がれた。しかし、NTPv2の設計はDTSSコミュニティから形式的な正しさに欠けると批判され、クロック選択手順はNTPv3以降ではMarzulloのアルゴリズムを取り入れるように変更された。[ 24 ]
1992年、RFC 1305でNTPv3が定義されました。このRFCでは、基準クロックから最終クライアントに至るまでのすべてのエラー要因の分析が含まれており、複数の候補サーバー間で意見の相違が見られる場合に、最適なサーバーを選択するのに役立つ指標を算出できるようになりました。また、ブロードキャストモードが導入されました。
その後数年間、新機能が追加され、アルゴリズムが改良されるにつれて、新しいプロトコル バージョンが必要であることが明らかになりました。[ 25 ] 2010 年に、NTPv4 の仕様案を含むRFC 5905が公開されました。 [ 26 ]ミルズがデラウェア大学を退職した後、リファレンス実装は現在、ハーラン・ステンが率いるオープンソースプロジェクトとして維持されています。 [ 27 ] [ 28 ] IANA側では、ntp (ネットワーク タイムプロトコル) 作業グループが提案されたドラフトのレビューを担当しています。[ 29 ]
NTPv4以降、プロトコルは大幅に進歩した。[ 26 ] 2022年現在プロトコルの更新を記述した 3 つの RFC 文書が公開されており、[ 18 ] [ 19 ] [ 20 ]ネットワーク タイム セキュリティなどの多数の周辺標準[ 29 ]は含まれていません。 [ 30 ]ミルズは自身のページで「NTPv5」の計画について言及していましたが、公開されることはありませんでした。[ 26 ] chronyの M. Lichvar による「NTPv5」と呼ばれる無関係のドラフトが2020 年に開始され、セキュリティ、精度、スケーリングの変更が含まれています。[ 31 ]
NTP が従来のタイム プロトコルに取って代わったものの、一部のユース ケースでは完全なプロトコルが複雑すぎると感じられました。1992 年に、このニッチを埋めるために、シンプル ネットワーク タイム プロトコル( SNTP ) が定義されました。SNTPv3 標準では、長期間にわたって状態を保存する必要がない NTPv3 の使用方法が規定されています。使用されるサーバーは 1 つだけなので、トポロジーは基本的にタイム プロトコルと同じになります。 [ 13 ] 1996 年に、SNTP は当時開発中だった NTPv4 のいくつかの機能を備えた SNTPv4 に更新されました。 [ 15 ] SNTPv4 は 2010 年に主要な NTPv4 標準に統合されました。[ 5 ]
SNTP は新しいプロトコルを定義していないため、NTP と完全に相互運用可能です[ 32 ] : §14。NTP と同じパケット形式とポートを使用するため、NTP サーバーとの互換性が確保されます。ただし、クライアント/サーバーには、ネットワークジッタのフィルタリング、クロック ドリフトの分析、複数の時間ソースの相互参照に必要な複雑なアルゴリズムがありません。そのため、完全な NTP アプリケーション スタックのオーバーヘッドなしに「十分な」時間が必要なIoTデバイスや基本的なハードウェアに適しています。 [ 5 ]
SNTPクライアントは通常、単一のサーバーに問い合わせて受信した時刻をローカルクロックに直接適用することで動作します。しかし、単純なアルゴリズムでは精度が低い時刻しか得られないため、SNTPソースから時刻を同期することは推奨されません。ただし、RFC 5905では、完全なオンワイヤプロトコルの追加的な複雑さは最小限であるため、単純なクライアントであっても完全な実装が推奨されると指摘されています。[ 5 ]
NTP は、階層的で半階層的な時刻ソースシステムを使用します。この階層の各レベルはストラタムと呼ばれ、最上位の基準クロックに対してゼロから始まる番号が割り当てられます。ストラタムnサーバーに同期されたサーバーは、ストラタムn + 1で動作します。この番号は基準クロックからの距離を表し、階層内の循環依存を防ぐために使用されます。ストラタムは必ずしも品質や信頼性を示すものではありません。ストラタム 2 の時刻ソースよりも高品質のストラタム 3 の時刻ソースが見つかることはよくあります。[ a ]ストラタ 0、1、2、3 の簡単な説明を以下に示します。
ストラタムの上限は15です。ストラタム16は、デバイスが同期されていないことを示すために使用されます。各コンピュータ上のNTPアルゴリズムは相互に作用してベルマン・フォード最短経路スパニングツリーを構築し、すべてのクライアントからストラタム1のサーバへの累積往復遅延を最小化します。[ 1 ] : 20
ストラタムに加えて、このプロトコルは参照識別子（refid）によって各サーバーの同期ソースを識別することができる。
ストラタム 2 およびそれ以下のサーバーの場合、refid はアップストリーム タイム サーバーの IP アドレスをエンコードした形式です。 IPv4 の場合は、これは単に 32 ビット アドレスです。 IPv6 の場合は、ソース アドレスの MD5 ハッシュの最初の 32 ビットになります。 refid は、タイミング ループを第一段階で検出および防止するために使用されます。[ 5 ]
refid フィールドは、kiss-o'-death (KoD) パケットの場合、サーバーが休めるようにクライアントにリクエストの送信を停止するように指示するステータス ワードで埋められます。[ 5 ]例としては、INIT (初期化)、STEP (ステップ時間の変更)、RATE (クライアントのリクエストが速すぎる) などがあります。[ 38 ]プログラムの出力では、ネットワーク切断を示す XFAC など、パケットで送信されないコードを使用してエラーを示す場合もあります。[ 35 ]
IANAはrefidソース名とKoDコードのレジストリを維持している。非公式な割り当てがまだ存在する可能性がある。[ 39 ]
ntpqのNTP 管理プロトコルユーティリティを使用して、ストラタム 1 タイムサーバーの状態を照会し、クライアントの正常な動作を確認します。NTPリファレンス実装は、プロトコルとともに 20 年以上にわたって継続的に開発されてきました。新しい機能が追加されるにつれて、後方互換性が維持されてきました。特にクロックを制御するためのいくつかの繊細なアルゴリズムが含まれており、異なるアルゴリズムを使用するサーバーと同期すると誤動作する可能性があります。このソフトウェアは、パーソナル コンピュータを含むほぼすべてのコンピューティング プラットフォームに移植されています。Unixではntpdと呼ばれるデーモンとして、Windows ではサービスとして実行されます。リファレンス クロックがサポートされており、そのオフセットはリモート サーバーと同じ方法でフィルタリングおよび分析されますが、通常はより頻繁にポーリングされます。[ 1 ] : 15–19この実装は 2017 年に監査され、14 の潜在的なセキュリティ問題が発見されました。[ 40 ]
Windows 2000以降のすべてのMicrosoft Windowsバージョンには、コンピュータの時計をNTPサーバーと同期する機能を持つWindowsタイムサービス（W32Time）[ 41 ]が含まれています。
W32Time は元々、リプレイ攻撃を防ぐために時刻が正しい値から 5 分以内である必要があったKerberosバージョン 5 認証プロトコルの目的で実装されました。Windows 2000 Server (および Windows XP) のネットワーク タイム サーバーは、NTP による同期を実装しておらず、NTP/SNTP による補正を伴うローカル同期のみを実装しています。[ 42 ]
Windows Server 2003およびWindows Vista以降、W32Time の NTP プロバイダーは、NTPv3 の重要なサブセットと互換性を持つようになりました。[ 43 ] Microsoft は、W32Time が 1 秒の精度で時刻同期を確実に維持できないと述べています。[ 44 ]より高い精度が必要な場合は、Microsoft は、より新しいバージョンの Windows または別の NTP 実装を使用することを推奨しています。[ 45 ]
Windows 10バージョン 1607 およびWindows Server 2016以降では、W32Time は 特定の動作条件下で1 秒、50 ミリ秒、または 1 ミリ秒の時間精度に達するように構成できます。 [ 46 ] [ 44 ] [ 47 ]
2004年、OpenBSDのヘニング・ブラウアーは、セキュリティに重点を置き、特権分離設計を取り入れたNTPv3/SNTPv4 [ 48 ]実装であるOpenNTPDを発表しました。これはOpenBSDユーザーのより単純な一般的なニーズに特化していますが、既存のNTPサーバーとの互換性を維持しながら、プロトコルのセキュリティもいくつか改善されています。よりシンプルなコードベースは、このユースケースでは不要とみなされる精度を犠牲にしています。[ 49 ]ポータブル版はLinuxパッケージリポジトリで入手可能です。
NTPsec は、体系的にセキュリティ強化されたリファレンス実装のフォークです。フォークのポイントは 2015 年 6 月で、2014 年の一連の侵害への対応でした。[ 50 ]最初の製品版リリースは 2017 年 10 月に出荷されました。[ 51 ]安全でない機能の削除、旧式のハードウェアのサポートの削除、旧式の Unix バリアントのサポートの削除により、NTPsec は元のコードベースの 75% を削減することができ、残りの部分の監査が容易になりました。[ 52 ] 2017 年のコードの監査では、8 つのセキュリティ問題が見つかりましたが、そのうち 2 つは元のリファレンス実装には存在しなかったものでしたが、NTPsec はリファレンス実装に残っていた他の 8 つの問題には影響を受けませんでした。[ 53 ]
chrony は、主にRed Hatがスポンサーとなっている独立した NTP 実装であり、Red Hat は自社のディストリビューションでデフォルトの時刻プログラムとしてこれを使用しています。[ 54 ] chronyはゼロから書き直されているため、コードベースがシンプルで、セキュリティが向上し[ 55 ]、リソース消費も少なくなっています。[ 56 ]しかし、精度を犠牲にすることなく、多くの場合、リファレンス ntpd よりも高速かつ正確に同期します。不安定でスリープモードになったり、インターネットへの接続が断続的になったりする通常のコンピュータにも十分対応できます。また、より不安定な環境である仮想マシン向けにも設計されています。[ 57 ]
chrony は、ごく少数のインシデントしかなく、「信頼できる」と評価されています。[ 58 ]ネットワークアダプタのハードウェアタイムスタンプを使用することで、LAN 接続の精度を向上させることができます。[ 8 ]ネットワークタイムセキュリティ (NTS) のサポートはバージョン 4.0 で追加されました。[ 59 ] chrony はGNU General Public License バージョン 2の下で利用可能で、1997 年にRichard Curnowによって作成され、現在はMiroslav Lichvarによってメンテナンスされています。[ 56 ]
ntpd-rs は、メモリセーフなインターネット インフラストラクチャの構築を目的としたインターネット セキュリティ リサーチ グループ ( ISRG) の Prossimo イニシアチブの一環として設立された、セキュリティに重点を置いた NTP プロトコルの実装です。ntpd-rs は、NTP 実装に必要なリアルタイム コンピューティング機能に加えてメモリ安全性の保証を提供するRust プログラミング言語で実装されています。ntpd-rs は、 Let's Encryptなどのセキュリティに敏感な非営利認証局で使用されています。[ 60 ] NTS のサポートが利用可能です。[ 61 ] ntpd-rs は、高精度時刻プロトコルの実装である「statime」も含まれる「Pendulum」プロジェクトの一部です。両プロジェクトは、ApacheおよびMITソフトウェア ライセンスの下で利用可能です。
閏秒イベントの当日、ntpd は設定ファイル、接続された参照クロック、またはリモートサーバーのいずれかから通知を受け取ります。イベント中は NTP クロックは実際に停止しますが、時間が厳密に増加しているように見える必要があるため、システム時刻を照会するプロセスは、イベントの順序を維持するために、システムをわずかに増加させます。負の閏秒が必要になった場合は、23:59:58、00:00:00 のシーケンスで削除され、23:59:59 はスキップされます。[ 67 ]
リープスミアリングと呼ばれる別の実装では、UTC 時間の正午から正午までの 24 時間以内に閏秒を段階的に導入します。この実装は、Google (社内および公開 NTP サーバーの両方)、Amazon AWS、[ 68 ]、および Facebook [ 69 ]で使用されています。chronyはsmoothtimeおよびleapsecmode構成で leap smear をサポートしていますが、leap smear は非標準であり、混在するとクライアントの計算が狂うため、このような使用は公開 NTP プールと混在させてはいけません。[ 70 ]
システム時刻の調整は一般的に特権操作であるため、NTP コードの一部または全部は、そのコア機能をサポートするために何らかの特権で実行する必要があります。 NTP コードベースのリファレンス実装では、他のセキュリティ上の問題はほとんど特定されていませんが、任意のコード実行やサービス拒否攻撃など、2009 年に発生した問題は重大な懸念事項でした。[ 71 ] [ 72 ]プロトコルは、その歴史を通じて改訂とレビューを受けてきました。リファレンス実装のコードベースは、数年にわたり複数のソースからセキュリティ監査を受けています。[ 73 ]
スタックバッファオーバーフローの脆弱性が発見され、2014年に修正されました。[ 74 ] Appleはこの脆弱性を非常に懸念し、初めて自動更新機能を使用しました。[ 75 ]ルートユーザーの認証情報で実行されるリファレンス実装を使用するシステムでは、無制限のアクセスが可能になる可能性がありました。OpenNTPDなどの他の実装は、コードベースが小さく、特権分離などの他の緩和策を採用しているため、この欠陥の影響を受けません。[ 76 ]
Linux FoundationのCore Infrastructure Initiativeのために実施された3つのNTP実装の2017年のセキュリティ監査では、セキュリティの観点から、NTP [ 77 ] [ 78 ]とNTPsec [ 79 ]の両方がchrony [ 80 ]よりも問題が多いことが示唆されました。[ 81 ]
NTP サーバーは、認証のためにパケットが暗号署名されていない限り、中間者攻撃に対して脆弱です。 [ 82 ]関連する計算オーバーヘッドにより、特にサービス拒否攻撃中は、ビジー状態のサーバーではこれが非現実的になる可能性があります。[ 83 ]中間者攻撃によるNTP メッセージのなりすましは、クライアント コンピュータの時計を変更したり、暗号鍵の有効期限の回避に基づくさまざまな攻撃を可能にするために使用できます。 [ 84 ]偽の NTP メッセージの影響を受けることが確認されているサービスには、TLS、DNSSEC、さまざまなキャッシュ スキーム (DNS キャッシュなど)、ボーダー ゲートウェイ プロトコル(BGP)、ビットコイン、およびさまざまな永続ログイン スキームなどがあります。[ 85 ] [ 86 ]
NTP は分散型サービス拒否攻撃に利用されています。[ 87 ] [ 88 ]小さなクエリが NTP サーバーに送信され、その応答IP アドレスはターゲット アドレスに偽装されます。DNS増幅攻撃と同様に、サーバーははるかに大きな応答を返すため、攻撃者はターゲットに送信されるデータ量を大幅に増やすことができます。攻撃への参加を回避するには、NTP サーバー ソフトウェアをアップグレードするか、サーバーを外部クエリを無視するように構成することができます。[ 89 ]
NTP自体には、サーバーをクライアントに対して認証する機能が含まれています。NTPv3は対称鍵モードをサポートしていますが、これは中間者攻撃（MITM）に対しては役に立ちません。IPSecから採用されたNTPv4の「autokey」と呼ばれる公開鍵システムは、有用な認証機能を提供しますが、[ 82 ]ビジー状態のサーバーには実用的ではありません。[ 83 ]また、autokeyには後にいくつかの設計上の欠陥があることが判明しましたが、[ 90 ]メッセージ認証コードの変更を除いて、修正は公表されていません。[ 19 ] Autokeyはもはや使用すべきではありません。[ 91 ]
ネットワーク タイム セキュリティ(NTS) は、 TLSとAEADを備えた NTPv4 のセキュア バージョンです。[ 92 ]以前の試みからの主な改善点は、別の「鍵確立」サーバーが、一度だけ実行すれば済む重い非対称暗号化を処理することです。サーバーがダウンしても、以前のユーザーは中間者攻撃を恐れることなく時刻を取得できます。[ 30 ] NTS は、 CloudflareやNetnodなど、いくつかの NTP サーバーでサポートされています。[ 93 ] [ 94 ] chrony、NTPsec、ntpd-rsで有効にできます。 [ 95 ]
Microsoft は、 MS-SNTP と呼ばれるWindows ドメインIDを使用して NTPv3/SNTPv4 パケットを認証するアプローチも持っています。 [ 96 ]このシステムは、ドメイン接続にsambaを使用して、リファレンス ntpd および chrony に実装されています。 [ 97 ]
NTPで使用される64ビットバイナリ固定小数点タイムスタンプは、秒を表す32ビット部分と小数秒を表す32ビット部分で構成されており、2 32秒（136年）ごとにロールオーバーする時間スケールと、2 −32秒（233ピコ秒）の理論上の分解能を提供します。NTPは1900年1月1日をエポックとして使用します。したがって、最初のロールオーバーは2036年2月7日に発生します。[ 98 ] [ 99 ]
NTPv4 では 128 ビットの日付形式が導入されています。秒に 64 ビット、小数秒に 64 ビットです。ただし、標準では時代は「 NTP によって直接生成することはできず、またその必要もない」と規定されているため、128 ビット形式は送信されません。[ 100 ]この形式の最上位 32 ビットは時代番号であり、ほとんどの場合、ロールオーバーの曖昧さを解消します。[ 101 ]ミルズによれば、「小数部の 64 ビット値は、光速で電子を通過する光子にかかる時間を決定するのに十分です。秒の 64 ビット値は、宇宙が暗くなるまで曖昧さのない時間表現を提供するのに十分です。」[ 102 ] [ b ]
DHCPv4を使用すると、クライアントは初期ネットワーク設定の一環として時刻ソースを自動的に取得できます。これは、手動設定なしで動的な時刻同期を確保するために、管理ネットワークで一般的に使用されています。
RFC 2132 [ 103 ]は、NTP サーバーのアドレスをクライアントに配布するための専用の DHCPv4 オプションを定義しています。
「ネットワークタイムプロトコルサーバー」オプションには、クライアントが利用可能なNTPサーバーを識別するIPv4アドレスのリストが含まれます。サーバーは優先順位の高い順にリスト化することで、クライアントが最も適切なソースを選択できるようになります。
42|2|192.0.2.1|192.0.2.2ネットワークタイムプロトコル（NTP）は、システムクロックを協定世界時（UTC）に同期させる役割を担いますが、ローカルタイムゾーン情報は配信しません。タイムゾーンの設定は、オペレーティングシステムレベルで別途処理されます。
これは、携帯電話ネットワークのようにデバイスが出入りするネットワークで特に役立ちます。デバイス上で直接定義する必要性を減らします。
これらのオプションはRFC 4833 [ 104 ]で定義されており、 IPv4 ( DHCPv4 ) とIPv6 ( DHCPv6 )の両方のDHCP に適用されます。
以下のDHCPv4オプションが定義されています。
どちらのオプションも可変長の文字列を含み、ヌル終端されていません。
このオプションは、POSIX 環境変数形式 (IEEE 1003.1 で規定) を使用したタイムゾーン定義を運びますがTZ、文字列はコロン ( :) で始まってはなりません。
例：
EST5EDT4,M3.2.0/02:00,M11.1.0/02:00これは以下を説明するものです。
このオプションを有効にするには、クライアントがタイムゾーンデータベースのローカルコピーを既に持っている必要があります。クライアントが指定された名前を認識する場合は、POSIX文字列よりもこのオプションを優先する必要があります。名前が不明な場合は、このオプションは無視する必要があります。
このオプションには、 IANAタイムゾーンデータベースからのゾーン名が含まれます。例:
Europe/Oslo
RFC 4833では、異なるオプションコードを持つDHCPv6の同等のオプションが定義されています。
セマンティクスと文字列形式はDHCPv4で使用されているものと同一です。DHCPv4とDHCPv6のプロトコルの違いにより、バイナリエンコーディングのみが異なります。
NTPは絶対時刻（UTC）のみを配信し、ローカルタイムゾーンや夏時間に関する情報は含まれていません。DHCPタイムゾーンオプションはNTPを補完し、クライアントが時計の同期後にローカルタイムの表示を自動的に構成できるようにします。
一般的な導入事例では：
この分離によりNTPはシンプルさを保ち、地域固有の政治的・法的時間規則を時刻同期プロトコルに組み込むことを回避する。
このディレクティブは、指定されたネットワークインターフェイスとの間で送受信されるNTPパケットのハードウェアタイムスタンプを有効にします。
クロック選択手順は、2つのソート/破棄ステップのうち最初のステップを削除し、Marzulloによって最初に提案され、後にデジタル時刻サービスに組み込まれたアルゴリズムに置き換えるように変更されました。これらの変更は、NTPの通常の動作やさまざまなバージョンとの互換性に大きな影響を与えるものではありませんが、正当性に関する正式な声明の基礎となります。
NTP のサブセットである Simple Network Time Protocol (SNTPv4) に準拠するプライマリ サーバーとクライアントは、緩和アルゴリズムを実装する必要はありません。完全に開発された NTPv4 の実装は、複数のアップストリーム サーバーと複数のダウンストリーム サーバーを持つサーバーを対象としています。これらの考慮事項を除けば、NTP および SNTP サーバーとクライアントは完全に相互運用可能であり、混在させることができます。
のプログラムはNTPデーモンと組み合わせて使用できます。NIC上のPTPクロックはptp4lによって同期され、chronydまたはntpdによってシステムクロックの同期のための基準クロックとして使用されます。
-death (KoD) パケット、ntpq および ntpmon のビルボード表示の参照識別子フィールド、およびログ メッセージで使用されます。
これは、RFC 5905 で説明されているシンプル ネットワーク タイム プロトコル バージョン 4 と、RFC 1305 で説明されているネットワーク タイム プロトコル バージョン 3 を実装しています。
{{cite web}}: CS1メンテナンス: アーカイブサービスは非推奨になりました (リンク)Hat Enterprise Linux 7.0（現在はRed Hat Enterprise Linux 6.8）以降、chronyパッケージを介してより汎用性の高いNTP実装も提供されています。
要するに、Chrony NTPソフトウェアは堅牢で信頼できるものと言える。
このソフトウェアは、Linux、FreeBSD、NetBSD、macOS、Solaris でサポートされています。
8 月に 11 日間のリモート テストに耐えたということは、Chrony が堅牢で強く、セキュリティを念頭に置いて開発されていることを意味します。
、bookworm の Debian では systemd-timesyncd がデフォルトの NTP デーモンになったのですが、これは少し驚きです。
と sntp の組み合わせにより、ntpdate の機能が実装されるようになりました。sntp に関する残りの問題がいくつか解決され次第
、
ntpdate プログラムは廃止されます。
{{cite report}}: CS1 maint: url-status (リンク)