ホームへ戻る

RFC-2030 の翻訳のつもりです。下手な日本語訳です。もし可能ならば、アプリケーションソフトの開発などに、お役立て下さい。誤訳の指摘、アドバイス、その他は、こちらまでお寄せください。

      Network Working Group                                           D. Mills 
      Request for Comments: 2030                        University of Delaware 
      Obsoletes: 1769                                             October 1996
      Category: Informational

IPv4、IPv6、OSIに適合した簡易ネットワーク時刻プロトコル(SNTP)バージョン4

この文書の位置付け
この文書は、インターネットコミュニティへの情報を提供する。この文書は、いかなる種類のインターネット標準も規定しない。この文書の再配布に制限はない。

概要

この文書では、簡易ネットワーク時刻プロトコル(SNTP)バージョン4について、記述されている。このプロトコルは、インターネット上でコンピュータの時計同士を同期させるために使用される、ネットワーク時刻プロトコル(NTP)の改訂版である。SNTPは、RFC-1305に記述されている完全なNTPの実装という究極のパフォーマンスが不要であるか、または、必要であることが正当化されない場合に使用され得るものである。SNTPバージョン4が、現行及びそれ以前のプロトコルバージョンのNTPやSNTPとともに動作する場合、SNTPバージョン4はNTPの仕様やすでに知られている実装に対する修正を一切必要としない。それよりもむしろ、RFC-868に記述されているUDP/TIMEプロトコルのような、正確で、信頼性のある予想機能を持った、単純で、状態のない遠隔手続き型呼び出し(RPC)モードの中で動作できる、NTPの確固とした設計仕様の説明を必要としている。

SNTPバージョン4における、以前のバージョンのNTP、SNTPからの唯一の重要なプロトコル仕様の変更は、インターネットプロトコルバージョン6(IPv6) [DEE96]とOSI[COL94]のアドレス定義に適応させるように、ヘッダ解釈が修正されたことである。しかしながら、SNTPバージョン4は、基礎にあるバージョン3のモデルに対する一定の任意的な拡張をふくんでいる。つまり、エニーキャストモードの実装と、マルチキャストモードと、エニーキャストモードのために特別に設計された認証手順の実装を含むことになる。エニーキャストモードについての拡張は、この文書で記述されているが、認証手順についての拡張は、後に発行されるもう一つ他の文書において記述されるであろう。最終的な仕様書が発行されるまでの期間においては、これらの拡張機能は、暫定的なものであると考えられるべきである。

この文書において、SNTPバージョン3を説明した、RFC-1769は廃止される。その目的は、以前の文書における明らかな矛盾点を訂正することと、現行のNTPバージョン3(IPv4)と、提案されている(IPv6、OSI)のためのヘッダフォーマットとプロトコル動作方法を明らかにすることである。これらの事柄は、SNTPにも使用されるものである。SNTPの実装には、NTPバージョン3の仕様書であるRFC-1305の運用知識は必要ではない。

1. 導入

RFC-1305[MIL92]で説明されているネットワーク時刻プロトコル(NTP)バージョン3は、グローバルなインターネット上で、コンピュータの時計同士を同期させるために、広く使われている。そのプロトコルは、各国の標準時や一定の周波数で提供されているサービスにアクセスをして、時刻同期サブネットを構築し、サブネット参加のコンピュータ同士で内蔵時計を調節するという包括的なメカニズムを提供する。今日のインターネットのほとんどの場所では、NTPは、1-50ミリ秒の精度で提供されており、それは、同期源とネットワーク経路の特性に依存している。

RFC-1305は、NTPバージョン3のプロトコルマシンについて、発生する事象、状態、送受信機能、動作という見地から説明し、加えて、時刻計測の品質を改善し、欠陥のある可能性のある同期源とそうでない同期源の間で生じる問題を緩衝させるアルゴリズム設計についてもまた説明している。今日のインターネットの主要な部分同士をつなぐネットワーク経路を通じて、数ミリ秒以下といった高い精度を達成するために、これらの複雑なアルゴリズム、またはそれらと機能的に同等なものが必要である。しかしながら、多くの場合、およそ1秒の有意な分数の精度で、充分である。そのような場合に、時刻プロトコル[POS83]のような、より単純なプロトコルが使われてきた。これらのプロトコルは通常、クライアントが日時を要求し、サーバーがクライアントに対して、数秒後、いくつかの既定の参照事象を応答するという、RPC交信を含んでいる。

NTPは、さまざまなネットワーク遅延とジッタ特性の中で、さまざまな能力をもつクライアント及びサーバーにより利用できるように設計されている。今日のインターネットNTP同期サブネット上の、ほとんどのユーザーは、NTPの任意的機能やアルゴリズムをすべて装備したソフトウェアパッケージを使っており、それらは、比較的複雑な、常駐アプリケーションである。(参照 http://www.eecis.udel.edu/~ntp)そのようなソフトウェアは、パーソナルコンピュータからスーパーコンピュータまでの幅広いハードウェアプラットフォームに対して移植されてきたが、その容量と複雑さは、多くのアプリケーションには、不適当なものである。したがって、あまり厳格な精度を必要としない場合に適切と思われる、より単純なソフトウェアを使った、代替的なアクセス手法を探究することは有意義である。

この文書では、簡易ネットワーク時刻プロトコル(SNTP)バージョン4について記述している。SNTPバージョン4は、現在インターネット上で公開され、配置されているNTPバージョン3あるいは、現在開発中のNTPバージョン4を使用したサーバーやクライアントに、より単純化されたアクセス方法を提供するものである。典型的なアクセス手法は、UDP/TIMEプロトコルと同様であり、実際、パーソナルコンピュータについていえば、SNTPを動作するようにUDP/TIMEクライアントの実装を改良することは容易に可能なことであるなはずだ。さらに、SNTPは、電波時計と統合したようなものも含め、専用のサーバー形態で動作するようにも設計されている。注意深い設計と、そのシステムのさまざまな内部遅延の制御は、専門に設計されているので、実用的であり、それにより、およそ数ミリ秒単位の精度の時刻を配送することが可能である。

SNTPバージョン4は、提案中のNTPバージョン4のクライアントやサーバーと同様に、すでに存在している、NTPとSNTPバージョン3の、クライアント及びサーバーと共存出来るように設計されている。NTP、SNTPの現行のバージョンと、旧バージョンが同時に運用される場合、SNTPバージョン4は、その現在稼動中の、または、NTP、SNTPバージョン4のために特別に実装されようとしているプロトコル及び実装に対する修正対応を必要としない。NTP、SNTPサーバーにとって、NTP、SNTPクライアントは、区別できない。同様に、NTP、SNTPクライアントは、NTP、SNTPサーバーを区別できない。NTPサーバーが、非対称モードで動作するように、SNTPサーバーは、状態がなく、非常に多くのクライアントにサービスを提供することが出来る。しかしながら、ほとんどのNTPクライアントと異なり、SNTPクライアントは、通常、たった一つのサーバーとともに動作する。NTP、SNTPバージョン3のサーバーは、ユニキャストモードとマルチキャストモードで動作できる。加えて、SNTPバージョン4のクライアントとサーバーは、エニーキャストモードでの動作という拡張を実装できる。

SNTPは、時刻同期サブネットの末端でのみ使用されることが強く推奨されている。SNTPクライアントは、サブネットの(最もルート階層から離れた)階層の末端、すなわち、NTPまたは、SNTPクライアントが時刻同期のために、もう一つ他のSNTPクライアントに依存するということがない配置構成ででのみ運用されるべきである。SNTPサーバーは、サブネットのルート階層(階層1)、すなわち、信頼性の高い電波時計、モデム時計サービス以外に、有効な他の同期源がないという配置構成でのみ運用されるべきである。通常、1次サーバーに求められる信頼性の完全度は、冗長な同期源、複数の異なるサブネット経路、NTP機能を完全実装した技巧的なアルゴリズムを使うことによってのみ、受容されるものである。このことは、複数の電波時計又はモデム時計、他の1次サーバーへのバックアップ経路を同期源として使用する中で、1次同期源自体までの繰り返しを生じさせ、全ての同期源が誤作動したり、多くの同期源が誤った時刻を配送するということになるはずである。したがって、1次サーバーでNTPよりも、SNTPを利用することは、慎重に考慮されるべきである。

この文書の重要な要点は、NTPバージョン4の、あるヘッダフィールドの再解釈である。これは、IPv6や、OSIのアドレスへの対応と、マルチキャストサービスのために特別に設計された任意のエニーキャスト拡張仕様を提供するものである。これらの付随的なものは、将来、別の文書として明らかにされる予定である、提案中のNTPバージョン4の仕様に関連している。現行のNTPバージョン3と提案中のバージョン4における、ヘッダフォーマットの唯一の違いは、4オクテットの参照識別子フィールドの解釈である。それは、主に、同期ループを検出し、それを回避するために用いられているものである。バージョン3と、バージョン4の1次サーバー(階層1)において、このフィールドは、この文書の後方で定義されている、アスキー形式の4文字参照識別子を含んでいる。バージョン3の2次サーバーとクライアントにおいては、このフィールドには、同期源のIPv4の32ビットアドレスが含まれている。バージョン4の2次サーバーとクライアントでは、このフィールドには、同期源から受信した、最新の送信タイムスタンプの下位32ビットが含まれている。

OSIの場合は、非接続転送サービス(CLTS)が使用される[ISO86]。それぞれのSNTPパケットは、T-UNITDATA要求の最初のTS-USERDATAパラメータとして送信される。そのヘッダは、パケットごとに、UDPを使用して転送されるTPDUの中にカプセル化される[DOB91]。[FUR94]から推測されるような、OSIの上位層において運用されるNTPは、かなり精度を落とす可能性があるので、推奨できない。この文書で定義されているヘッダフォーマットを使用すれば、異なるプロトコルファミリーのサーバーとクライアント間の相互通信は、原理的には可能であるが、現実的には困難なので、これは推奨できない。

これ以降、このように字下げを行っている段落は、正式なプロトコル仕様としては必要とされないが、プロトコルの実装として、実装しておくとよいと考えられる情報を含んでいる。

2.動作モードとアドレス

SNTPバージョン4は、ユニキャスト(1対1)、マルチキャスト(1対多)、エニーキャスト(多対1)モードで動作する。ユニキャストクライアントは、そのユニキャストアドレスで、使用するサーバーにリクエストを送信し、時刻、さらに、任意の項目として、往復遅延、サーバーとの相対的なローカル時計の差を計算する事を可能にする応答を期待する。マルチキャストサーバーは、指定されたIPv4や、IPv6のローカルブロードキャストアドレスや、マルチキャストグループアドレスに定期的に自発的にメッセージを送り、そして、通常、クライアントからのリクエストを必要としない。マルチキャストクライアントは、このマルチキャストアドレスを監視し、通常は、リクエストを送信しない。エニーキャストクライアントは、使用するIPv4又はIPv6のローカルブロードキャストアドレス又は、マルチキャストグループアドレスへリクエストを送信する。そして、一つあるいはそれ以上のエニーキャストサーバーが、サーバー固有のユニキャストアドレスを使い、応答する。クライアントは、最初に受信したサーバーを使用するサーバーとして決定し、以後、ユニキャストモードで動作を続ける。

マルチキャストサーバーは、自発的にマルチキャストメッセージを送信すると同時に、クライアントのユニキャストリクエストにも応答すべきである。マルチキャストクライアントは、サーバーとクライアント間のネットワーク伝播遅延を測定するために、ユニキャストリクエストを送信した上で、マルチキャストモードとして動作を開始する可能性がある。

ユニキャストモードでは、クライアントとサーバーの、両端のシステムアドレスは、通常のIPv4、IPv6、OSIの規約に従って、割り当てられる。マルチキャストモードでは、サーバーは、指定されたローカルブロードキャストアドレス又はマルチキャストグループアドレスを使用する。IPローカルブロードキャストアドレスは、その範囲が単一のIPサブネットに制限されている。なぜなら、ルーターが、IPブロードキャストデータグラムを、通過させないからである。一方、IPマルチキャストグループアドレスは、その範囲が、全インターネットに拡張される可能性がある。その範囲の割り当て、パケットルーティング、及び、マルチキャストグループ化の手順は、この文書の範囲外で考慮され、決定されることである。IPv4のために、IANAは、NTPのためにマルチキャストグループアドレス224.0.0.1を割り当てた。そのアドレスは、マルチキャストサーバーとエニーキャストクライアントにより、使用される。IPv6とOSIのためのNTPマルチキャストは、まだ、決定されていない。

マルチキャストクライアントは、使用するローカルブロードキャストアドレスまたは、マルチキャストグループアドレスを監視する。ローカルブロードキャストアドレスの場合、それ以上の規定は必要ない。IPマルチキャストアドレスの場合、マルチキャストクライアントと、エニーキャストサーバーは、インターネットグループ管理プロトコル(IGMP) [DEE89]を、実装しなくてはならない。それは、ローカルルーターが、マルチキャストグループに参加し、IANAにより割り当てられたIPv4、IPv6のマルチキャストグループアドレスへ、メッセージを中継するためである。IPアドレスの規定と、IGMP以外については、ローカルブロードキャストアドレスまたはマルチキャストグループアドレスのいずれかを持つ、サーバーまたはクライアントの動作に、それぞれ違いはない。

マルチキャストメッセージのIPヘッダの中にある、生存期間(TTL)フィールドを、合理的な値に調節することは、重要なことである。それは、この(、あるいは、その他の)マルチキャストサービスにより、使用されるネットワークリソースに、歯止めをかけるためである。これにより、一定の範囲のマルチキャストクライアントだけが、マルチキャストサーバーのメッセージを受信できる。サービスに協力できる一定の範囲のエニーキャストサーバーのみが、クライアントのリクエストに応答する。使用されるべき適切な値を決定する、巧みな処理の原理は、この文書の範囲を超えている。

エニーキャストモードは、サービスに協力できる一連のサーバーのアドレス持って使用されるように設計されており、その場合、クライアントは、そのアドレスを前もって知らない状態にある。エニーキャストクライアントは、まず、下に示すように、使用するローカルブロードキャストまたは、マルチキャストグループアドレスに対して、リクエストを送信する。この目的のために、IANAにより割り当てられたNTPマルチキャストグループアドレスが使用される。一つ、あるいは、それ以上のエニーキャストサーバーが、使用するローカルブロードキャストアドレスやマルチキャストグループアドレスを監視している。それぞれのエニーキャストサーバーは、リクエストを受信すると、発信源のクライアントに対して、ユニキャストレスポンスメッセージを送信する。その後、クライアントは、最初に受信したサーバーのメッセージをもとに、そのサーバーを使用するサーバーとして決定し、以後ユニキャストモードで動作を継続する。そのサーバーからのメッセージの後に続く、その他のサーバーからレスポンスメッセージは、無視される。

ここで述べられているようなSNTPの場合、SNTPマルチキャストクライアントは、インターネット上のどこか他の場所において、規定外動作をする、または、動作不良となっている、SNTP、NTPマルチキャストサーバーによって混乱させられるという、非常に現実に起こりうる弱点があるのである。なぜなら、現在、全てのこのようなサーバーが、IANAにより割り当てられた同じIPv4のマルチキャストグループアドレスを使用しているからである。必要な場合に用意されているサーバーのソースアドレスに基づくアクセスコントロールは、クライアントが、使用するサーバーをすでに知って、信用しているサーバーを限定して選択するために用いられ得るものである。RFC-1305に定義されている、暗号認証手順の用法は、任意実装である。しかしながら、実装者は、この手順への拡張が、NTPマルチキャストモードとエニーキャストモードのために、特別に設計されたものであるということを知ることになるはずである。

SNTPの仕様書としては、必要不可欠ではないが、IPブロードキャストアドレスは、主として、フル仕様のNTPサーバーと、それに依存する多数のSNTPマルチキャストクライアントが、同じサブネット上に存在する、IPサブネット及びLANセグメントにおいて用いられることになっている。一方、IPマルチキャストグループアドレスは、パケット生存期間が、それぞれのサービスドメインについて、巧みに処理されるということが明確な場合にのみ、用いられることになっている。

NTPバージョン3において、参照識別子は、しばしば、管理目的のために、同期サブネットをルート階層(1次サーバー)までさかのぼるために使われてきた。NTPバージョン4においては、この仕様は、有効ではない。なぜなら、アドレスが32ビット以上であるからだ。しかしながら、そのプロトコル設計の意図することは、ループを検知し、それを回避する方法を提供することにあった。同じパケットで、IPv4送信先アドレスと、このフィールドの内容を比較することで、通信相手は、ループの可能性を検出できた。NTPバージョン4のサーバーは、同じパケットで、同じことを、開始タイムスタンプの下位32ビットと、このフィールドの内容を比較することにより実現できる。この方法では、少し、誤警報の可能性があるが、誤警報の発生率は、送信タイムスタンプの使用されない下位ビットを乱数数列にすることで小さくできる。

3. NTP タイムスタンプフォーマット

SNTPは、RFC-1305と、その前のバージョンの同文書において記述されている、標準NTPタイムスタンプフォーマットを使用している。標準的なインターネットの慣例に従って、NTPデータは、左端の上位が0で始まるビッグエンディアン形式のビット数列で表された整数又は固定小数点数として規定されている。特に、他の方法がないならば、全ての数字は符号無しで、ビット0を先頭に、暗黙的な0で、全てのフィールドが埋められていてもよい。

NTPタイムスタンプは、大切なデータであり、実際、このプロトコルの主要な目的を表すものであるので、特別なタイムスタンプフォーマットが確立された。NTPタイムスタンプは、64ビット符号無し固定小数点数として表現されており、このタイムスタンプは、1900年1月1日0時との相対的な差を秒単位で表している。整数部分は、最初の上位32ビット、小数点以下は、下位32ビットとなっている。小数部分については、あまり重要でない下位ビットは、0に設定される。

システム的な丸め誤差を防止し、かつ、ループ検出と再送検出(後述)の手段として、タイムスタンプのあまり重要でない下位ビットは、偏りのないビット数列の乱数で埋めることを推奨する。これをする方法の一つとしては、64ビットワード型の乱数ビット数列を発生させ、タイムスタンプの有意ビットの数と等しいビット数だけ、幾何学的に右シフトを実行し、それから、その結果を、その対象タイムスタンプに加えるという方法がある。

このフォーマットは、便利な倍精度算術と、UDP/TIME表現(秒単位)への変換を可能にした。しかし、ミリ秒単位で表現されるICMPタイムスタンプメッセージ表現への変換は複雑になった。表現できる最大値は、4294967295秒であり、およそ200ピコ秒の精度を持つ。それは、最も風変わりな要求に対してさえ、充分なはずである。

                        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で埋められる)     |
 
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


注意すべきことは、1968年のどこかで(2147483648秒で)最上位ビット(整数部のビット0)が、1となり、64ビットフィールドは、2036年のどこか(4294967296秒で)オーバーフローを起こす。もし、NTPや、SNTPが2036年でも使用されているならば、1900年との相対的な時間なのか、2036年との相対的な時間なのか(あるいは、他の136の倍数にあたる年との相対時間なのか)ということを特定するために、いくつかの外部的な手段が必要となるだろう。136年おきに64ビットフィールドが0になるとき、今後無視される200ピコ秒間が一つ存在する。これは、規約によって、無効であるか又は有効でないタイムスタンプとして、解釈される。

NTPタイムスタンプフォーマットは、ここ17年間使用され続けてきたので、今から40年後にタイムスタンプフィールドがオーバーフローするときでも、使われているという可能性がある。ビット0が1になる1968年以前のNTPタイムスタンプを利用しつづけることは、不適切であるので、NTPタイムスタンプの有効期間を延長する簡便な方法として、次のような規約を使用する方法がある。もし、ビット0が1のときは、協定標準時は、1968-2036の範囲にあり、協定標準時は、協定標準時1900年1月1日の0時0分0秒から計算される。もし、ビット0が0のときは、時間は、2036-2104の範囲にあり、協定標準時は、協定標準時2036年2月7日6時28分16秒 から計算される。注意すべきことは、その対応関係を計算するとき、2000年が閏年でないことに注意することである。また、閏秒は計算では考慮されないということにも注意すべきである。

4.NTPメッセージフォーマット

NTPとSNTPは両者とも、ユーザーデータグラムプロトコル(UDP)[POS80]クライアントであり、UDPはそれ自身がインターネットプロトコル(IP)[DAR81]のクライアントである。IPとUDPのヘッダ構造は、列挙した仕様書に記述されており、ここで改めて詳述することはない。NTPに割り当てられたUDPポート番号は、123番で、それは、UDPヘッダの中の送信元ポートと、送信先ポートの両方で使われるべきである。残りのUDPヘッダフィールドは、その仕様書で記述されているように、設定されるべきである。

下は、NTP/SNTPバージョン4のメッセージフォーマットを表したものである。このメッセージは、IPヘッダ、UDPヘッダに続くものである。このフォーマットは、参照識別子フィールドの内容以外は、RFC1305で記述されているものと同一である。ヘッダフィールドは、下のように定義される。

                          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 |     階層      |ポーリング間隔 |     精度      |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                          ルート遅延                           |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                          ルート拡散                           |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                          参照識別子                           |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                                                               |
   
      |                   参照タイムスタンプ (64)                     |
   
      |                                                               |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                                                               |
   
      |                   開始タイムスタンプ (64)                     |
   
      |                                                               |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                                                               |
   
      |                    受信タイムスタンプ (64)                    |
   
      |                                                               |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                                                               |
   
      |                    送信タイムスタンプ (64)                    |
   
      |                                                               |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                    鍵識別子 (任意) (32)                       |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   
      |                                                               |
   
      |                                                               |
   
      |                 メッセージダイジェスト (任意) (128)           |
   
      |                                                               |
   
      |                                                               |
   
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

次の段落で記述されているように、SNTPでは、これらフィールドのほとんどは、前もって規定されたデータにより初期化される。完全性のために、それぞれのフィールドの機能は、下のように簡潔に要約される。

閏秒指示子 (LI): これは、その日の最後の1分において、差し迫った閏秒を挿入・削除することを警告する2ビットコードである。ビット0と、ビット1によってそれぞれあらわされ、下のようにコード化されている。

      LI       値        意味
    
      -------------------------------------------------------
    
      00       0         警告無し
    
      01       1         最後の1分が61秒
    
      10       2         最後の1分が59秒
    
      11       3         警告状態(時計が同期していない)

バージョン番号 (VN): これは、3ビットの整数で、NTP/SNTPバージョン番号を示している。このバージョン番号は、バージョン3(IPv4のみ)では、3、バージョン4(IPv4、IPv6、OSI)では、4となっている。IPv4、IPv6、OSIを識別する必要があるならば、カプセル化されたパケットの内容を、詳しく調べなくてはならない。

モード: これは、モードを示す3ビットの整数である。値は、下のように定義されている。

      モード   意味
    
      ------------------------------------
    
      0        予約
    
      1        対称能動
    
      2        対称受動
    
      3        クライアント
    
      4        サーバー
    
      5        ブロードキャスト
    
      6        NTP制御メッセージのため予約
    
      7        私的使用のため予約

ユニキャスト、エニーキャストモードにおいて、クライアントは、リクエスト時にこのフィールドを3(クライアント)に設定する。サーバーは、応答でこのフィールドに4(サーバー)を設定する。マルチキャストモードでは、サーバーは、このフィールドを5(ブロードキャスト)に設定する。

階層: これは、8ビット符号無しの整数で、ローカル時計の階層レベルを示している。値は下のように定義されている。

      階層     意味
    
      ----------------------------------------------
    
      0        不明または、有効でない階級
    
      1        1次参照(電波時計などの時刻を参照している)
    
      2-15     2次参照(NTP、SNTPを経由して時刻を参照している)
    
      16-255   予約

ポーリング間隔: これは、8ビットの符号付き整数で、連続するメッセージの最大間隔を表している。秒単位で、最も近い2のべき乗で表される.このフィールドに現れる値は、現在のところ、4(16秒)から14(16284秒)である。しかしながら、ほとんどのアプリケーションは、6(64秒)から10(1024秒)という、副次的な範囲のみを使用している。

精度: これは、8ビット符号付き整数で、ローカル時計の精度を示している。秒単位で、最も近い2のべき乗で表される。このフィールドに、通常現れる値は、-6といった、コンセントの周波数の時計で使用されるものから、-20といった、一部のワークステーションにあるようなマイクロ秒時計で使用されるものまでの範囲にある。

ルート遅延: これは、32ビットの符号付き固定小数点数で、1次参照源までの往復遅延の合計を示している。小数点がビット15と16の間にある秒単位で表される。注意すべきことは、この変数は、相対時間と周波数変位によって、正の値や負の値の両方をとりうるものである。
このフィールドに現れる値は、通常、数ミリ秒の負の値から、数百ミリ秒の正の値までの範囲にある。

ルート分散: これは、32ビット符号無しの固定小数点数であり、1次参照源との名目的な相対誤差を示しており、ビット15とビット16の間に小数点がある秒単位で表される。通常、このフィールドに現れる値は、0から、数百ミリ秒の範囲にある。

参照識別子: これは、固有の参照源を確認するための32ビットのビット列である。NTPバージョン3または、バージョン4の場合、階層0(不明)、階層1(1次)のサーバーにおいては、これは、4文字アスキー文字列であり、左寄せで、残りは0で埋められる。NTPバージョン3の2次サーバーでは、これは、32ビットの参照源のIPv4アドレスである。NTPバージョン4の2次サーバーでは、これは、参照源の最新の送信タイムスタンプの下位32ビットである。NTP1次(階層1)のサーバーは、このフィールドを下のリストに従って、外部参照源を識別するコードに設定するべきである。もし、外部参照源が、それらのリストの一つであるならば、関連したコードが使われるはずである。リストにあげられなかった参照源のコードは、適切に、考案されうる。

      コード   外部参照源
    
      ----------------------------------------------------------------
    
      LOCL     同期のための外部的な手段のないサブネットで、1次参照として利用される、
               外部の時計を計測しないローカル時計
    
      PPS      各国で標準時のために個別に測定されている原子時計又は、他の秒単位の振動源
    
      ACTS     NIST ダイアルアップ モデムサービス
    
      USNO     USNO モデムサービス
    
      PTB      PTB (Germany) モデムサービス
    
      TDF      Allouis (France) ラジオ 164 kHz
    
      DCF      Mainflingen (Germany) ラジオ 77.5 kHz
    
      MSF      Rugby (UK) ラジオ 60 kHz
    
      WWV      Ft. Collins (US) ラジオ 2.5、 5、 10、 15、 20 MHz
    
      WWVB     Boulder (US) ラジオ 60 kHz
    
      WWVH     Kaui Hawaii (US) ラジオ 2.5、 5、 10、 15 MHz
    
      CHU      Ottawa (Canada) ラジオ 3330、 7335、 14670 kHz
    
      LORC     LORAN-C 無線航行システム
    
      OMEG     OMEGA 無線航行システム
    
      GPS      全地球無線測位システム
    
      GOES     静止軌道周回衛星

参照タイムスタンプ: これは、ローカル時計が最後に設定あるいは、修正された時刻であり、64ビットタイムスタンプフォーマットで表される。

開始タイムスタンプ: これは、クライアントからサーバーへリクエストが発信された時間であり、64ビットタイムスタンプフォーマットで表される。

受信タイムスタンプ: これは、サーバーへリクエストが到着した時間を示している。64ビットタイムスタンプフォーマットで表される。

送信タイムスタンプ: これは、サーバーからクライアントに応答が発信された時間である。64ビットタイムスタンプフォーマットで表される。

認証識別子 (任意): NTP認証手順が実装されるとき、そのキー識別子と、メッセージ概要フィールドは、RFC-1305の付録Cに定義されているメッセージ認証コード(MAC)情報を含んでいる。

5. SNTP クライアントの動作

SNTPクライアントは、マルチキャストモード、ユニキャストモード、エニーキャストモードで動作できる。マルチキャストモードでは、クライアントは、リクエストを送信せずに使用するマルチキャストサーバーからのブロードキャスト(モード5)を待つ。ユニキャストモードでは、クライアントは、使用するユニキャストサーバーへリクエスト(モード3)を送信し、サーバーからの応答(モード4)を期待する。エニーキャストモードでは、クライアントは、使用するローカルブロードキャストアドレス、マルチキャストグループアドレスへリクエスト(モード3)を送信し、1あるいはそれ以上のエニーキャストサーバーからの応答(モード4)を期待する。クライアントは、その後のユニキャスト動作のために、最初に受信した応答を使用して特定のサーバーを確認する。残りのこのサーバーの(重複の)応答または、他のサーバーの応答は無視される。そのリクエストによるアドレスの選択以外は、エニーキャストクライアントとユニキャストクライアントの動作は、同一である。リクエストは、通常、64秒から1024秒間隔で送信される。リクエストは、クライアントの時計の周波数耐性と必要とされる精度に依存している。

ユニキャストクライアント又は、エニーキャストクライアントは、NTPメッセージヘッダを初期化し、サーバーへリクエストを送信し、その応答の送信タイムスタンプフィールドから日時を割り出す。この目的のため、上にあるようなNTPヘッダフィールドは、最初の1オクテットと(任意の)送信タイムスタンプフィールド以外は全て0に設定されうる。最初の1オクテットでは、閏秒指示子フィールドは0(警告無し)に設定され、モードフィールドは、3(クライアント)に設定される。バージョン番号フィールドは、NTP、SNTPサーバーのバージョン番号に一致しなくてはならない。しかしながら、バージョン4のサーバーは、また、以前のバージョンを受け入れなくてはならない。バージョン3(RFC-1305)とバージョン2(RFC-1119)のサーバーは、バージョン1(RFC-1059)を含む全ての前のバージョンを、すでに受け入れている。バージョン0(RFC-959)はもはや、他のいずれのバージョンによっても、サポートされないことには注意すべきである。

インターネット上で内部動作している全ての4つのバージョンのNTP、SNTPサーバーが、おそらく、存在しつづける予定なので、SNTPバージョン4のクライアントによって使われるバージョンには、注意深い考慮がなされるべきである。クライアントは、最も高い精度と信頼性のために、選択したサーバーによってサポートされていると判明している最新のバージョンを使用することを推奨するということが推奨される。SNTPバージョン4クライアントは、全ての前のバージョンのNTP、SNTPサーバーとともに内部動作する。これは、SNTPクライアントにより使用されるヘッダフィールドが、変更されていないためである。バージョン4サーバーには、リクエストと同じバージョンの応答が必要とされるので、そのリクエストのバージョン番号フィールドは、応答のバージョンもまた規定する。

仕様に準拠したクライアントの実装としては、必要ないことではあるが、ユニキャストモードとエニーキャストモードでは、リクエスト中の送信タイムスタンプには、クライアントの時計の日時が、NTPタイムスタンプフォーマットで、設定されることが高く推奨される。これは、サーバーとクライアント間の伝播遅延を計測し、一般的に、サーバーと相対して数十ミリ秒以内の範囲でローカル時計を修正するための単純な計算を可能にする。加えて、これは、サーバーの応答が、実際に、特定のクライアントの要求に対する正しい応答であるということを証明し、間違った応答の繰り返しを防ぐ単純な手法を提供する。マルチキャストモードでは、クライアントは、もし、NTP認証手順が使われることがなければ、伝播遅延を計算する、あるいは、サーバーの正当性を決定するための情報が一切ない。

往復遅延dや、サーバーとの相対的なローカル時計の差tを計算するために、クライアントは、要求時に、送信タイムスタンプをNTPタイムスタンプフォーマットで、クライアント時計の時刻に設定するサーバーは、応答時に、このフィールドを開始タイムスタンプにコピーする。そして、NTPタイムスタンプフォーマットにで、受信タイムスタンプと送信タイムスタンプをサーバーの時計の日時に設定する。

サーバーの応答を受信したとき、クライアントは、NTPタイムスタンプフォーマットで、クライアントの時計における到着時刻を、終了タイムスタンプ変数に設定する。下の表は、4つのタイムスタンプの要約である。

タイムスタンプ名        ID   いつ生成されるか
 
      ------------------------------------------------------------
 
      開始タイムスタンプ      T1   クライアントにより要求が送信された時刻
 
      受信タイムスタンプ      T2   サーバーにより要求が受信された時刻
 
      送信タイムスタンプ      T3   サーバーにより応答が送信された時刻
 
      終了タイムスタンプ      T4   クライアントにより応答が受信された時刻

往復遅延d、ローカル時計の誤差tは次のように定義される。

d = (T4 - T1) - (T2 - T3)     t = ((T2 - T1) + (T3 - T4)) / 2.

下の表は、ユニキャストモード、エニーキャストモード、マルチキャストモードにおける、SNTPクライアントの動作の要約である。推奨されるエラーチェックは、表中の応答の列とマルチキャストの列に見られる。メッセージは、全てのフィールドがそれぞれの範囲に値が収まっているときのみ、有効と考えられるべきである。メッセージを有効であるかどうか考えるとき、1あるいはそれ以上の「無視」と書かれたフィールドが無効な値を含んでいる場合に、そのメッセージを信用するかどうかということは、自由裁量の実装である。

フィールド名            ユニ/エニーキャスト      マルチキャスト
 
                              リクエスト 応答
 
      ----------------------------------------------------------
 
      閏秒指示子              0          0-2           0-2
 
      バージョン番号          1-4        リクエストか  1-4
 
                                         らコピー
 
      モード                  3          4             5
 
      階層                    0          1-14          1-14
 
      ポーリング間隔          0          無視          無視
 
      精度                    0          無視          無視
 
      ルート遅延              0          無視          無視
 
      ルート分散              0          無視          無視
 
      参照識別子              0          無視          無視
 
      参照タイムスタンプ      0          無視          無視
 
      開始タイムスタンプ      0          (本文参照)    無視
 
      受信タイムスタンプ      0          (本文参照)    無視
 
      送信タイムスタンプ      (本文参照) 非0値        非0値
 
      認証識別子              任意       任意          任意
 

6. SNTP サーバーの動作

SNTPバージョン4のサーバーは、同バージョン及び、それ以前のバージョンのNTP、SNTPクライアントとともに動作し、非接続状態を維持する。SNTPサーバーは、通常、過大なクライアントや、さまざまな種類のネットワーク経路をサポートすることを意図したNTPの完全なアルゴリズムを実装してはいないので、SNTPサーバーは、信頼できる電波時計や電話モデムといった外部同期源を伴って運用されるべきである。この場合、サーバーは、常に1次サーバー(階層1)として動作する。

SNTPサーバーは、ユニキャストモード、エニーキャストモード、マルチキャストモード、または、これらのモードの組み合わせで動作できる。ユニキャストモードとエニーキャストモードでは、サーバーはリクエスト(モード3)を受信し、NTPヘッダフィールドの特定のフィールドを変更し、できるだけ、リクエストと同じメッセージバッファを使用し、応答(モード4)する。エニーキャストモードでは、サーバーは使用するローカルブロードキャストアドレスまたは、IANAによって割り当てられたマルチキャストグループアドレスを監視し、応答時の送信元アドレスフィールドには、サーバー自身のユニキャストアドレスを使用する。応答時のアドレス選択以外では、エニーキャストサーバーとユニキャストサーバーの動作は同一である。マルチキャストメッセージは通常、64秒から、1024秒のポーリング間隔で送信され、それは、予想されるクライアント時計の周波数耐性及び必要とされる精度に依存している。

ユニキャストモードとエニーキャストモードでは、リクエスト中のバージョン番号と、ポーリング間隔フィールドは、そのまま応答にコピーされる。もし、リクエスト中のモードフィールドが、3(クライアント)であれば、応答では、それは4(サーバー)に設定される。そうでない場合は、NTPの仕様書に従い、このフィールドは、2(対称受動)に設定される。これにより、対称能動(モード1)で設定されたクライアントが、たとえ、最適でない可能性のある方法で設定されているとしても、内部動作は成功する。マルチキャスト(要求無しの)モードでは、バージョンフィールドは、4に設定され、モードフィールドは5(ブロードキャスト)に設定される。ポーリングフィールドは、ポーリング間隔の2の対数に最も近い整数に設定される。

もしサーバーがマルチキャストモードをサポートしているならば、そのサーバーは、ユニキャストモードもまたサポートするということが非常に望ましいことであるということに注意するべきである。これは、マルチキャストモードだけを使用して恒常的動作の前に行われる、クライアントとサーバーのパケット交換を使って、マルチキャストクライアントが行う伝播遅延の計算を可能にするためである。もし、サーバーがエニーキャストモードをサポートしていれば、必ず、ユニキャストモードをサポートしていなければならない。プロトコルの仕様書は、禁じていないことではあるが、マルチキャストモードとエニーキャストモードを同時に動作させる大きな利点があるようには見えない。

ユニキャストモードとエニーキャストモードでは、サーバーは、もし、正しく動作している電波時計に、同期していない場合、応答を返すかもしれないし、返さないかもしれない。しかし、どちらかといえば、応答するという選択が望ましい。なぜなら、これが、同期しているかどうかという状態にかかわらず、パケットが到達できているのかということを知ることを可能にさせるからである。マルチキャストモードでは、サーバーは、正常に動作している参照時計に同期している場合にのみ、ブロードキャストを送信する。

残りのNTPヘッダフィールドは、以下のような方法で設定される。もし、サーバーが電波時計や他の1次参照源に同期し、正常に動作している場合、閏秒指示子は、0に設定され、階層フィールドは、1(1次サーバー)に設定される。もしそうでないならば、階層フィールドは0に設定され、閏秒指示子は、3に設定される。精度フィールドは、ローカル時計の最大読み込み誤差を反映して設定されるべきである。実際起こりうる、全ての場合を想定して、それは、NTPタイムスタンプフォーマットの小数点より右側の有用なビット数を負の数に変換して計算される。ルート遅延、ルート分散フィールドは、1次サーバーでは0として設定される。任意ではあるが、ルート分散フィールドは、電波時計それ自身の、予期される最大誤差に等しくなる値に設定されることもある。参照識別子は、1次参照源を示すために設定され、この文書の第5章の表のように指定されている。

タイムスタンプフィールドは、下のように設定される。もし、サーバーが、同期してない又は、初めて起動したときは、全てのタイムスタンプフィールドは、0に設定される。同期している場合は、参照タイムスタンプは、電波時計や、モデムから受け取った最終更新時刻に設定される。ユニキャストモードとエニーキャストモードでは、受信タイムスタンプフィールドと送信タイムスタンプフィールドは、メッセージが送信された日時に設定され、開始タイムスタンプフィールドには、リクエストメッセージの送信タイムスタンプフィールドの内容が、そのままコピーされる。このフィールドが完全にコピーされることは重要なことである。なぜなら、NTPクライアントは、これを、メッセージ再送防止に使用しているからである。マルチキャストモードでは、開始タイムスタンプフィールドと、受信タイムスタンプフィールドは、0に設定され、送信タイムスタンプフィールドは、メッセージが送信された日時に設定される。下の表は、これら動作の要約である。

フィールド名            ユニ/エニーキャスト      マルチキャスト
 
                              リクエスト 応答
 
      ----------------------------------------------------------
 
      閏秒指示子              無視       0 or 3        0 or 3
 
      バージョン番号          1-4        リクエストか  4
 
                                         らコピー
 
      モード                  3          2 or 4        5
 
      階層                    無視       1             1
 
      ポーリング間隔          無視       リクエストか  ポーリング間隔
 
                                         らコピー      の2の対数
 
      精度                    無視       訳文参照      訳文参照
 
      ルート遅延              無視       0             0
 
      ルート分散              無視       0             0
 
      参照識別子              無視       参照源識別    参照源識別
 
                                         コード        コード
 
      参照タイムスタンプ      無視       電波時計で    電波時計で
 
                                         最終更新した  最終更新した
 
                                         時間          時間
 
      開始タイムスタンプ      無視       送信タイム    0
 
                                         スタンプから
 
                                         コピー
 
      受信タイムスタンプ      無視       日時          0
 
      送信タイムスタンプ      (本文参照) 日時          日時
 
      認証識別子              任意       任意          任意


最初に起動したとき又は1次同期源が動作していない期間に起こりうる、無効なタイムスタンプを許容する、多くのクライアントは、それ自身の責任において、いくらかの許容範囲を持つ場合がある。最も重要な動作不良のサーバーを見分けるための指示子は、閏秒指示子フィールドである。そのフィールドの値が3であれば、同期していない状態にあることを示す。この値が現れたら、クライアントは、他のフィールドの内容にかかわらず、サーバーのメッセージを破棄すべきである。

7. 構成と管理

SNTPのサーバーとSNTPクライアントの初期設定は、もしファイルシステムが有効であれば、設定ファイルを使用して成され得る。そうでない場合は、シリアルポートを使用する。NTP、SNTPバージョン4のサーバーとクライアントのサービス中の管理は、SNMPと、後に発行される、適当なMIBを使用し、成し遂げるという予定になっている。通常、SNTPサーバーとSNTPクライアントは、IPアドレスとサブネットマスク、又はOSIのNSAPアドレス以外には、サイトに特化した設定がほとんどあるいは全くない状態で動作することが期待されている。

ユニキャストクライアントは、使用するサーバー名、アドレスを提供されなくてはならない。もし、サーバー名が使用されるときは、さらに、1つ以上のDNSサーバーのアドレスが提供されなくてはならない。マルチキャストサーバーとエニーキャストクライアントは、TTLと、ローカルブロードキャストアドレス又はマルチキャストグループアドレスが提供されなくてはならない。エニーキャストサーバーとマルチキャストクライアントは、アクセス制御のために、アドレスマスクのペアーリストを設定されるかもしれない。これは、信用できると考えられているクライアントやサーバーを利用するためである。これらのサーバーやクライアントは、IGMPプロトコルを実装していなくてはならない。そして、ローカルブロードキャストアドレスやマルチキャストグループアドレスもまた提供されていなくてはならない。暗号認証のための設定データは、この文書の範囲を超えている。

IPアドレスとサブネットマスクまたは、OSIのNSAPアドレス以外の方法で、事前設定なしに、SNTPクライアントが、自動的にサーバーを発見、選択することを可能にするいくつかのシナリオがある。NTPの完全な機能を実装したNTPサーバーが存在する、IPサブネット又はLANセグメントでは、ローカルブロードキャストアドレスを使用した、マルチキャストモードをクライアントが構成する可能性がある。同じアプローチが、マルチキャストグループアドレスを使用した他のサーバーを用いて可能になる。どちらの場合でも、アクセス制御リストを準備することは、良い方法である。これは、信用ある同期源だけが、ローカル時計を設定するのに使用されるということを保証するためである。

重大なネットワーク伝播遅延のある拡張されたネットワークに適した、もう一つのシナリオでは、クライアントは、初期起動時、そして、これまで選択されていたユニキャスト同期源との交信が途絶えた場合に、エニーキャストモードとなりうる。定義されたプロトコルにしたがって、クライアントは、最初の応答受信で使用するサーバーを決定し、以後ユニキャストモードで動作を続ける。このモードでは、ローカル時計は、自動的に、伝播遅延を考慮して調節される。

どのネットワークにも、マルチキャストサービスが有効でない所にも適用できるもっと他のシナリオとしては、time.domain.netのような、共通CNAMEと、同じドメインにあるNTPサーバーのアドレス記録リストを利用して、DNSが設定されるということである。time.domain.netの名前解決をし、そのリストを獲得した上で、クライアントは、ランダムにサーバーを選択し、そのサーバーとユニキャストモードで動作をはじめる。この主題には、多くの種類がある可能性がある。

8. 謝辞

Jeff Learmanは、このプロトコルのOSIモデルの開発に貢献した。
Ajit Thyagarajanは、貴重な提案と監修を提供した。

9. 参照

[COL94] Colella, R., R. Callon, E. Gardner, Y. Rekhter, "Guidelines
for OSI NSAP allocation in the Internet", RFC 1629, NIST, May 1994.

[DAR81] Postel, J., "Internet Protocol", STD 5, RFC 791,
USC Information Sciences Institute, September 1981.

[DEE89] Deering, S., "Host extensions for IP multicasting", STD 5,
RFC 1112, Stanford University, August 1989.

[DEE96] Deering, S., R. Hinden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC 1883, Xerox and Ipsilon, January 1996.

[DOB91] Dobbins, K, W. Haggerty, C. Shue, "OSI connectionless
transport services on top of UDP - Version: 1", RFC 1240, Open
Software Foundation, June 1991.

[EAS95] Eastlake, D., 3rd., and C. Kaufman, "Domain Name System
Security Extensions", Work in Progress.

[FUR94] Furniss, P., "Octet sequences for upper-layer OSI to support
basic communications applications", RFC 1698, Consultant,
October 1994.

[HIN96] Hinden, R., and S. Deering, "IP Version 6 addressing
Architecture", RFC 1884, Ipsilon and Xerox, January 1996.

[ISO86] International Standards 8602 - Information Processing Systems
- OSI: Connectionless Transport Protocol Specification. International
Standards Organization, December 1986.

[MIL92] Mills, D., "Network Time Protocol (Version 3) specification,
implementation and analysis", RFC 1305, University of Delaware,
March 1992.

[PAR93] Partridge, C., T. Mendez and W. Milliken, "Host anycasting
service", RFC 1546, Bolt Beranek Newman, November 1993.

[POS80] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
USC Information Sciences Institute, August 1980.

[POS83] Postel, J., "Time Protocol", STD 26, RFC 868,
USC Information Sciences Institute, May 1983.

セキュリティに関する考慮
この文書では、セキュリティ問題は検討されていない。

著者の住所
David L. Mills
Electrical Engineering Department
University of Delaware
Newark, DE 19716
Phone: (302) 831-8247

訳文: 津田 学

ホームへ戻る