UTF-8 encoded Translated into Japanese language by Yuuki OKANO. 日本語訳 陸野 優樹 Email: marimo@wdic.org 開始 2001年12月12日 / translation 12 December 2001 翻訳 2004年12月07日 / translation 07 December 2004 修正 2006年12月09日 / correction 09 December 2006 日本語に訳された文書に関する著作権は訳者に帰属します。 著作権についてはオリジナルに従います。 配布についてはオリジナルと同様に無制限です。 内容は不定期に更新されます。 この文書は rfc2030 を訳者(marimo@wdic.org)が個人的な好奇心で適当に翻 訳したものです。したがって、翻訳の正確さなどは全く保証いたしません。誤 訳や根本的な勘違いなどが多く含まれていると思います。正確な情報が必要な 場合は英語原文も合わせてお読みください。誤字・誤訳など翻訳内容について の指摘は、いつでも歓迎します。 Network Working Group D. Mills Request for Comments: 2030 University of Delaware Obsoletes: 1769 October 1996 Category: Informational シンプルネットワークタイムプロトコル (SNTP) バージョン 4 IPv4, IPv6 及び OSI 用 このメモの位置づけ このメモは情報をインターネットコミュニティに提供する。このメモは、 いかなる種類のインターネット標準も規定しない。このメモの配布は無制限 である。 要約 このメモによりシンプルネットワークタイムプロトコル(SNTP)バージョン4 が説明される。それは、インターネットのコンピュータクロックを同期させ るために使用される、ネットワークタイムプロトコル(NTP)の改造版である。 SNTPは、RFC-1305において説明された完全なNTP実装の究極の性能と信頼性が 必要ではない時に使われうる。現在、そして過去のNTPやSNTPバージョンによ り動作しているとき、SNTPバージョン4は、NTP仕様、及び既知の実装に変更を 包含しない。しかし、むしろ、正確度を持つシンプルなステートレスなリモー トプロシージャコール(RPC)モードにおいてオペレーションを可能にするNTPの ある設計機能の詳細説明、及び、UDP/TIMEプロトコルと類似した信頼性の予測 は、RFC-868において述べた。 NTPとSNTPの以前のバージョンとSNTPバージョン4の唯一の重要な変更点は、 インターネットプロトコルバージョン6(IPv6) [DEE96] とOSI [COL94] アド レッシングを適応させるための、ヘッダの解釈である。しかし、SNTPバージョ ン4は、基本的なバージョン 3モデルへのある任意の拡張、特にマルチキャス トとエニーキャストモードのために設計されたエニーキャストモード及び認証 スキームを含んでいる。この文書においてエニーキャストモード拡張が説明さ れると同時に、認証スキームの拡張は、後で述べられる別の文書において説明 されている。最終的な仕様書が載せられるまでは、これらの拡張は、仮である と考えられるべきである。 このメモにより、SNTPバージョン3が説明されるRFC-1769が廃棄される。そ の目的は、前のドキュメントの矛盾を訂正し、そして現在のNTPバージョン3 (IPv4)と提案されたNTPバージョン4(IPv6とOSI)のためのヘッダフォーマット 及びプロトコル操作を明確化することである。これは、SNTPのために同様に使 われる。NTPバージョン3仕様RFC-1305のワーキングナリッジはSNTPの実装には 必須ではない。 1. 序論 RFC-1305 [MIL92] において規定されたネットワークタイムプロトコル(NTP) バージョン3は、グローバルなインターネットにて、コンピュータクロックを 同期させるために広く使用される。それは、国時間と周期的配布サービスへの アクセスの包括的なメカニズムが、時刻同期化サブネットを組織化し、そし て、ローカルな時計をそれぞれ参加しているサブネット集団で調節することを 規定する。今日のインターネットのほとんどの場所では、NTPは1～50msの精度 を提供し、同期源とネットワーク経路の特徴に依存する。 RFC-1305は、イベント、状態、遷移機能、そして動作に関しNTPバージョン3 プロトコルマシンを指定し、そして更に、計時品質を高めるために、アルゴリ ズムを設計し、そしていくらかの同期化ソース(それらのうちのいくらかが不 完全かもしれない)の間で緩和する。今日、これらの繁雑なアルゴリズム、ま たはそれらの機能的な同等品のインターネットの主要な部分を測定している経 路上で低ミリ秒の精度を達成することが必要である。しかし多くの場合、1秒 未満のオーダにおける正確性は許容される。そのような場合において、タイム プロトコル [POS83] などのような、より簡単プロトコルは、この目的のため に使われた。これらのプロトコルは、クライアントが日の時間を要求するRPC 交換を通常包含し、そしてサーバは、ある既知の参照エポックからの経過秒で それを返す。 NTPは、広範囲の様々な能力により、そして様々なネットワーク遅延とジッ タ特性の上でクライアントとサーバによって使用されるように設計されてい る。今日のインターネットNTP同期化サブネットの大部分のユーザーは、 比較 的複合的なリアルタイムアプリケーションであるNTPオプション及びアルゴリ ズムであるの十分なスイートを含むソフトウェアパッケージを使う (http://www.eecis.udel.edu/~ntp を参照のこと)。そのソフトウェアがパー ソナルコンピュータからスーパーコンピュータに及ぶ多種多様なハードウェア プラットフォームに接続され、同時にそのサイズと複雑さは、殆どのアプリ ケーションに適していない。そこで、それほど厳密ではない精度予想に適切 な、比較的簡単なソフトウェアを使い、代わりのアクセス戦略を探究すること が有益である。 このドキュメントは、今規定されるNTPバージョン3を使うサーバ、及びクラ イアントのための単純化されたアクセス手段であり、そして現在開発中である NTPバージョン4と同様に、インターネットに配置されるSimple Network Time Protocol(SNTP)バージョン4について述べる。アクセス方法論はUDP/TIME プロトコルと同一で、実際にSNTPを用いて動くため、UDP/TIMEクライアントの 実装、パーソナルコンピュータのための意見を反映させることは、容易なはず である。さらに、SNTPは、統合された電波時計を含む専門のサーバコンフィ ギュレーションにおいて動作するように設計されている。専用の設計において 実用的であるシステムにおける様々な待ち時間の注意深い設計、及びコント ロールに関し、マイクロ秒のオーダに正確な時間を届けることは、可能であ る。 SNTPバージョン4は、提案されたバージョン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サーバは、サブネットの、そして信頼できるラジオまたはモデム 時間サービスを以外の他の同期化源が利用できない構成におけるルート(第一 階層)のみでも動作できるべきである。プライマリサーバで通常予期される充 分な信頼性は、完全なNTP実装の冗長性、多様なサブネット経路、ならびに精 密に作られたアルゴリズムを用いるだけで可能である。これは、多重ラジオま たはモデムソースそしてバックアップパスという形で、全てのソースが故障ま たは大多数は間違った時間を引き渡すだろう他のプライマリサーバを拡張す る。従って、プライマリサーバにおけるNTPというよりもむしろSNTPの使用 は、慎重に考慮されるべきである。 この文書での重要な提言は、マルチキャストサービスのために明確にデザイ ンされたIPv6およびOSIアドレス指定およびオプションのエニーキャスト拡張 に備える一定のNTPバージョン4ヘッダフィールドの再解釈である。これらの追 加は、提案されたNTPバージョン4仕様と連携しており、それは個別の文書とし て提供されるだろう。現在のバージョン3および提案されたバージョン4のヘッ ダフォーマットの間の唯一の差異は、主として同期化ループを検出して回避す るために使われる、4オクテットの照会先識別子フィールドの解釈である。 バージョン3およびバージョン4つのプライマリ(第一階層)サーバにおいてこの フィールドは、この文書の後で定義される4文字のASCII照会先識別子を含む。 バージョン3のセカンダリサーバとクライアントにおいては、同期化源の32 ビットIPv4アドレスを含む。バージョン4のセカンダリサーバとクライアント においては、同期化源から受け取った最終転送タイムスタンプを含む。 OSIについて、非コネクション輸送サービス(CLTS)は、用いられる[ISO86]。 各SNTPパケットは、T-UNITDATA要求要素のTS-Userdataパラメータとして送ら れる。交互に、そのヘッダは、 UDP[DOB91]を用いて転送されるTPDUでカプセ ル化できる。[FUR94]から推定されるかのような、OSIスタックの上部のレイ ヤーでNTPが操作されることは、精度の重大な低下となるため推奨されない。 この文書において定義されたヘッダーフォーマットにより、それは、実用面で の問題で推奨されないものの、一つのプロトコルファミリーと別のもののサー バーとクライアントの間で相互に働くことは、可能として原則である。 これ以降、このように字下がりになった節は、正式のプロトコル仕様に よって必要とされない情報を含む。しかし、プロトコル実装において良 い慣習を考察した。 2. 動作モードとアドレッシング SNTPバージョン4は、ユニキャスト(ポイントtoポイント)、マルチキャスト (マルチポイントtoポイント)、またはエニーキャスト(ポイントtoマルチポイ ント)モードにおいて動作する。ユニキャストクライアントは、示されたサー バへの要求をそのユニキャストアドレスに送り、そして、それが時間、及び 随意に、往復の遅延、そして、ローカルなクロックがサーバと比較して相殺し たことを決定し得る応答を予期する。マルチキャストサーバは、嘆願されない メッセージを、明示されたIPv4、IPv6ローカルブロードキャストアドレス、ま たはマルチキャストグループアドレスに周期的に送り、通常、クライアントか らの要求には期待しない。このアドレスにおいてマルチキャストクライアント が聞き、通常は要求を送らない。エニーキャストクライアントは、要求を、明 示されたIPv4、IPv6ローカルブロードキャストアドレス、またはマルチキャス トグループアドレスに送る。1台以上のエニーキャストサーバがそれらの個々 のユニキャストアドレスによって応答する。そのクライアントは、受け取られ る最初のものにバインドし、そして、ユニキャストモードにおいてオペレー ションを続ける。 懇請されないマルチキャストメッセージを送るだけでなく、マルチキャ ストサーバはクライアントユニキャスト要求に反応するべきである。マ ルチキャストクライアントは、サーバとクライアントの間のネットワー ク信号伝播時間を決定し、それから、オペレーションをマルチキャスト モードに留まらせるために、ユニキャスト要求を送ることができる。 ユニキャストモード、クライアントおよびサーバのエンドシステムアドレス において、通常のIPv4、IPv6、またはOSI協定に従うことが割り当てられる。 マルチキャストモードにおいて、サーバは、明示されたローカルなブロード キャストアドレスまたはマルチキャストグループアドレスを使う。ルータが IPブロードキャストデータグラムを増殖させないので、 IPローカルなブロー ドキャストアドレスには、1つのIPサブネットに制限されたスコープがある。 一方では、IPマルチキャストグループアドレスは、インターネット全体のス コープ(機会)を拡張しうる潜在性を持っている。スコーピング、ルーティン グ、およびグループメンバーシップ手続は、この文書の有効範囲を越えた考察 事項によって決定される。IPv4のために、IANAはマルチキャストグループアド レス224.0.1.1をNTPに割り当て、それはマルチキャストサーバとエニーキャス トクライアントにより用いられる。IPv6および OSI用のNTPマルチキャストア ドレスは、今は決定されていない。 マルチキャストクライアントは、明示されたローカルなブロードキャストア ドレスまたはマルチキャストグループアドレスにおいて受信する。ローカルな ブロードキャストアドレスの場合は、それ以上の用意は不要である。IPマルチ キャストアドレスの場合は、マルチキャストクライアントとエニーキャスト サーバは、ローカルなルータが、IANAにより割り当てられたIPv4またはIPv6マ ルチキャストグループアドレスにマルチキャストグループとリレーメッセージ に参加するよう、インターネットグループ管理プロトコル(IGMP)[DEE89]を実 装しなければならない。IPアドレッシングの慣習とIGMPを除いて、ローカルな ブロードキャストアドレスまたはマルチキャストグループアドレスは、それを 持つサーバやクライアントの動作について一切違いはない。 この、そしてあらゆる他のマルチキャストサービスによって使われるネ ットワーク資源を制限するために、適正な値にマルチキャストメッセー ジのIPヘッダにおける生存時間(TTL)フィールドを調整することは、重要 である。有効範囲のマルチキャストクライアントのみが、マルチキャス トサーバメッセージを受け取るだろう。有効範囲の協力エニーキャスト サーバだけがクライアント要求に応答する。用いられるだろう適切な値 を決定する設計原理については、このドキュメントの有効範囲を越えて いる。 エニーキャストモードは、前もってアドレスがクライアントにより知られて いない協力サーバのセットで用いられるために設計される。エニーキャストク ライアントは、下記のように、要求を、明示されたローカルなブロードキャス トまたはマルチキャストグループアドレスに送る。この目的のために、IANAに より割り当てられたNTPマルチキャストグループアドレスが用いられる。明示 されたローカルなブロードキャストアドレスまたはマルチキャストグループア ドレスにおいて、一台以上のエニーキャストサーバが受けとる。各エニーキャ ストサーバは、要求を受け取るとすぐに、ユニキャスト返答メッセージを、発 信元クライアントに送る。そのクライアントは、その時、受け取られた最初の そのようなメッセージに拘束力があり、そして、ユニキャストモードにおいて オペレーションを続ける。 SNTPの場合、ここに明示されるように非常に現実的な脆弱性があるた め、不正を働くか、または、現在すべてのそのようなサーバがIANAによ り割り当てられた同じIPv4マルチキャストグループアドレスを使うこと に起因して、インターネットの他の場所で敵意を持っているSNTPまたは NTPマルチキャストサーバによって、粉砕されうる。サーバ発信元アドレ スに基づくアクセス制御は、クライアントについてそれに既知で、信頼 された明示されたサーバだけを選択するために必要に応じて使用でき る。RFC-1305において定義された暗号法の認証スキームの使用はオプ ションである; しかし、実装者は、このスキームへの拡張が特にNTPマル チキャストとエニーキャストモードのために計画されることを通知され るべきである。SNTP仕様に必須でない間、第一に十分に機能的なNTPサー バを、同じサブネットの多くの従属するSNTPマルチキャストクライアン トに含めているIPサブネットとLANセグメントでIPブロードキャストアド レスが使われることは意図されている一方、IPマルチキャストグループ アドレスは、個々のサービスドメインのためにTTLが明確に設計される場 合にのみ使われる。 NTPバージョン3において、照会先識別子は、同期サブネット管理のルー ト(プライマリサーバ)を知るためにしばしば用いられた。NTPバージョン 4では、32ビットよりアドレスが長いので、この機能は入手不可能であ る。しかしながら、プロトコル設計における意図は、ループを検出し、 回避する方法を提供することだった。ピア(同輩端末)は、ループがこの フィールドの内容を同じパケットのIPv4終点アドレスと比較することに より可能であると決定することができた。NTPバージョン4サーバは、こ のフィールドの内容を下位32ビットの同じパケットにおける始発タイム スタンプと比較することによって同じことを遂行できる。このスキーム には僅かに誤報が発生する可能性があるが、誤報率は、転送タイムスタ ンプの下位未使用ビットをランダム化することによって最小化できる。 3. NTP タイムスタンプ フォーマット SNTPは、 RFC-1305において示された標準のNTPタイムスタンプフォーマッ ト、及び、そのドキュメントの前のバージョンを使う。標準のインターネット 慣例に従うため、NTPデータは指定される整数または固定小数点数としてビッ グエンディアンに含められたビットにより、左の0回から、または上位ポジ ションから開始する。指定されなければ、すべての量は符号無しで、暗示され ている0の先行ビット0を持つ充分なフィールド幅を占めるだろう。 NTPタイムスタンプが抱かれたデータであり、そして実際、プロトコルの主 産物を表わすので、特別なタイムスタンプフォーマットが確立された。NTPタ イムスタンプは、1900年1月1日の0hを基準とする経過秒の64ビットの固定小数 点数として表現される。整数部分は最初の32ビット、最後の32ビットは小数部 分である。小数部分において、重要でない下位オーダーは0に設定できる。 ランダムで公平なビット列により、タイムスタンプの重要でない下位 オーダービットを満たし、体系的な丸めエラーを避け、およびループ検 出とリプレイ検出が得策である(下記参照)。これをする一つの方法は、 64ビットワードで任意のビット列を生成することである。タイムスタン プの符号ビットの番号と等しいビットの算術右シフトを実行し、その結 果をオリジナルなタイムスタンプに追加する このフォーマットは、便利な複数の精度計算と変換をUDP/TIME表現(秒)に与 えるけれども、ミリ秒にあるICMPタイムスタンプメッセージ表現への変換を複 雑にする。表現され得る最大の数は、約200ピコ秒の精度によって、 4,294,967,295秒である。それは、最もエキゾチックな要求さえにも十分であ るはずである。 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年(2,147,483,648秒)に、最上位ビットが設定されて、 2036年(4,294,967,296秒)に64ビットフィールドがあふれる。もし2036年にNTP またはSNTPが使用されるならば、いくつかの外部の方法が、2036年(と136年の 他の倍数)と比較し、1900年と時間と比較して時間を緩和するために必要であ ろう。そのため136年ごとに1つの200ピコ秒間、64ビットフィールドが、協定 によって無効または利用できないタイムスタンプと解釈される0となる時が存 在する。 NTPタイムスタンプフォーマットが最近の17年間使用されているので、 それは、秒フィールドがあふれる現在から40年後も使用中であり続ける 。たぶん、ビット0が1968年に設定される前にNTPタイムスタンプをアー カイブすることが不適当なので、NTPタイムスタンプの耐用年数を拡張す るための便利な方法が、以下の規定である: もしビット0が設定されてい たら、UTC時間は範囲1968～2036にあり、UTC時間は1900年1月1日に 0h 0m 0s UTCから計算される。もしビット0が設定されていなければ、時 間は範囲2036～2104にあり、UTC時間は2036年2月7日6h 28m 16s UTCから 計算される。計算の際、 2000年がうるう年ではないことに注意せよ。閏 秒が計算においてカウントされないことに同じく注意せよ。 4. NTP メッセージ フォーマット NTPとSNTPは、それ自身がインターネットプロトコル(IP) [DAR81]のクライ アントであるユーザーデータグラムプロトコル(UDP) [POS80] のクライアント である。IPとUDPヘッダの構造は、引用された指定文書において説明されるの で、ここで詳細は述べない。NTPに割り当てられたUDPポート番号は123であ り、それはUDPヘッダのソースポートと宛先ポートフィールドで使われるべき である。残留UDPヘッダフィールドは指定において説明されるように設定され るべきである。 下記は、IPとUDPヘッダに続いているNTP/SNTPバージョン4メッセージフォー マットの記述である。このフォーマットは、照会先識別子フィールドの内容を 除き、RFC-1305において説明されたものと同一である。ヘッダフィールドは次 の通り定義される: 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 | 階層 | Poll | 正確性 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルート遅延 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ルート分散 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 照会先識別子 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 照会先タイムスタンプ (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 始発タイムスタンプ (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 受信タイムスタンプ (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | 転送タイムスタンプ (64) | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | キー識別子(オプショナル) (32) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | | | | メッセージダイジェスト (オプショナル) (128) | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 次のセクションで説明されるように、SNTPでは、これらのフィールドの殆ど は、あらかじめ指定されたデータを初期設定する。詳細については、下記で簡 単に、個々のフィールドの機能が要約されている。 閏秒指示 (LI): これは、現在の日の最後の分に、それぞれ次の通りコード 化されたビット0とビット1によって挿入/削除されることで、差し迫った閏 秒の警告をする2ビットコードである: LI 値 意味 ------------------------------------------------------- 00 0 無警告 01 1 最後の分は61秒である 10 2 最後の分は59秒である 11 3 警報条件 (クロックが同期していない) バージョン番号 (VN): これは、NTP/SNTPバージョン番号を示す3ビット整数 である。バージョン番号は、3がバージョン3(IPv4専用)で、4がバージョン4 (IPv4、IPv6およびOSI)である。必要に応じて、IPv4とIPv6とOSIを区別する ために、カプセル化されたコンテクストを検査しなければならない。 モード (Mode): これは、次の通り定義された値によってモードを示してい る3ビット整数である: Mode 意味 ------------------------------------ 0 予約 1 対称 アクティブ 2 対称 パッシブ 3 クライアント 4 サーバ 5 ブロードキャスト 6 NTP制御メッセージ用の予約 7 私的利用のための予約 ユニキャストとエニーキャストモードにおいて、クライアントは要求におい てこのフィールドを3(クライアント)に設定し、サーバはそれを返答の4 (サーバ)に設定する。マルチキャストモードにおいては、サーバはこの フィールドを5(ブロードキャスト)に設定する。 階層 (Stratum): これは、次の通り定義された値によってローカルなクロッ クの層レベルを示す、8ビット符号なし整数である: 階層 意味 ---------------------------------------------- 0 不特定か、または利用できない 1 主要な参照 (例えば電波時計) 2-15 副次的な参照 (NTPまたはSNTP経由) 16-255 予約 Poll Interval: これは、2の2乗に最も近い数秒で、連続したメッセージ間 の最大の間を示す8ビット符号付き整数である。このフィールドに出せる値 は、4(16秒)から14(16284秒 [訳注]2^14は正しくは16384である)まで変動す る; しかし、殆どのアプリケーションは、6(64秒)から10(1024秒)までの部 分範囲のみを使う。 正確性 (Precision): これは、2の2乗に最も近い数秒で、ローカルなクロッ クの精度を示す8ビット符号付き整数である。このフィールドに通常現われ うる値は、主要な原子時計のための-6から、幾つかのワークステーションの ための-20まで変動する。 ルート 遅延 (Root Delay): これは、ビット15と16の間の小数点を持つ数秒 で、主要な参照ソースに全体の往復遅延を示している32ビット符号付き固定 小数点数である。相対的な時間と頻度オフセットに依存し、この変数は正と 負の値を呈することに注意すること。普通このフィールドに出る値 は、数ミリ秒の負数から正の数百ミリ秒まで変動する。 ルート 分散 (Root Dispersion): これは、ビット15と16の間に小数点を持 つ数秒で、主要な参照ソースと関連する名目のエラーを示している32ビット 符号なし固定小数点数である。普通このフィールドに出る値は、0から数百 ミリ秒まで変動する。 照会先 識別子 (Reference Identifier): これは、特定の参照ソースを識別 する32ビットのビット列である。NTPバージョン3、バージョン4 stratum-0 (不特定)、またはstratum-1(主要)サーバについて、これは4文字ASCII文字 列であり、左寄せで0パディングして32ビットに正規化する。NTPバージョン 3のセカンダリ(副次的)サーバでは、これは参照元の32ビットIPv4アドレス である。NTPバージョン4のセカンダリ(副次的)サーバでは、これは、最新の 参照元のタイムスタンプの下位32ビットである。NTP主要(層1)サーバは、こ のフィールドを、次のリストに従って外部参照ソースを識別しているコード に設定するべきである。もし外部参照がリストの一つなら、関連したコード が使われべきである。リストに無いソースのためのコードは適切に考案され うる。 コード 外部参照源 ----------------------------------------------------------------- LOCL 同期化の外部の方法の無いサブネットのための一次参照として 使われる、目盛りを決められないローカルなクロック PPS 原子時計または他の国家規格に則り目盛り設定されたパルス時 計源 ACTS NISTダイアルアップモデムサービス USNO USNOモデムサービス PTB PTB(ドイツ)モデムサービス TDF Allouis(フランス) 無線 164 kHz DCF Mainflingen (ドイツ) 無線 77.5 kHz MSF Rugby (イギリス) 無線 60 kHz WWV Ft. Collins (米国) 無線 2.5, 5, 10, 15, 20 MHz WWVB Boulder (米国) 無線 60 kHz WWVH Kaui Hawaii (米国) 無線 2.5, 5, 10, 15 MHz CHU Ottawa (カナダ) 無線 3330, 7335, 14670 kHz LORC ロラン-C(LORAN-C) 無線航行システム OMEG オメガ(OMEGA) 無線航行システム GPS 汎地球測位システム (訳注: 原文では ～Service だったが、 誤記であろうか?) GOES 静止軌道環境衛星 (訳注: アメリカの気象衛星. 日本でいう ところのひまわりみたいなもの) 照会先 タイムスタンプ (Reference Timestamp): これは、ローカルなクロ ックが、64ビットタイムスタンプフォーマットで設定されたか、または訂正 された最後の時刻である。 始発 タイムスタンプ (Originate Timestamp): これは、クライアントから サーバに、要求が出発した64ビットタイムスタンプフォーマットでの時刻で ある。受信 タイムスタンプ (Receive Timestamp): これは、要求がサーバ に到達した64ビットタイムスタンプフォーマットの時刻である。 転送 タイムスタンプ (Transmit Timestamp): これは、サーバからクライア ントへ返答が出発した64ビットタイムスタンプフォーマットでの時刻であ る。 認証識別子 (Authenticator) (オプショナル): NTP認証計画が実装される場 合には、キー識別子とメッセージダイジェストフィールドが、RFC-1305の付 録Cにおいて定義されたメッセージ認証コード(MAC)情報を含んでいる。 5. SNTP クライアント オペレーション マルチキャストモード、ユニキャストモード、またはエニーキャストモード において、SNTPクライアントが動作するだろう。マルチキャストモードでは、 クライアントは要求は送らず、明示されたマルチキャストサーバからブロード キャスト(モード5)を待つ。ユニキャストモードでは、クライアントは、要求 (モード3)を、明示されたユニキャストサーバに送り、そのサーバからの返答 (モード4)を期待する。エニーキャストモードでは、クライアントは要求(モー ド3)を明示されたローカルなブロードキャストまたはマルチキャストグループ アドレスに送り、1つ以上のエニーキャストサーバからの返答(モード4)を期待 する。クライアントは、次のユニキャストオペレーションのための特定のサー バを設立するため、受け取った最初の返答を使う。このサーバ(複製)またはど のような他のサーバからの以降の返答は無視する。要求のアドレスの選択を除 き、エニーキャストとユニキャストクライアントのオペレーションは同一であ る。要求は普通、64秒から1024秒までの間隔によって送られ、クライアントク ロックおよび必要な精度の頻度寛容に依存する。 ユニキャストまたはエニーキャストクライアントは、NTPメッセージヘッダ を初期設定し、要求をサーバに送り、返信された転送タイムスタンプ (Transmit Timestamp)から時刻を得る。この目的のために、前述のNTPヘッダ フィールドの全ては、最初のオクテットおよび(オプションの)転送 タイムス タンプフィールド(Transmit Timestamp)を除いて0に設定できる。最初のオク テットでは、閏秒指示フィールドは0(無警告)に設定され、モードフィールド は3(クライアント)に設定される。VNフィールドはNTP/SNTPサーバのバージョ ン番号と合致しているにちがいない; しかし、バージョン4サーバは前のバー ジョンにも適応する。バージョン3(RFC-1305)およびバージョン2(RFC-1119) サーバは、すでに、バージョン1を含むすべての前のバージョンに適応してい る(RFC-1059)。もうバージョン0(RFC-959)がどのような他のバージョンによっ てもサポートされないことに注意すること。 それ以来、恐らくインターネットで相互運用されている合計4つのバージョ ンのNTPとSNTPサーバであり続ける。慎重な考慮は、SNTPバージョン4クライア ントにより使われたバージョンに与えられるべきである。クライアントは、最 も高い精度と信頼性から選ばれたサーバによってサポートされると知られてい る最新のバージョンを使うことが推奨される。SNTPクライアントにより使われ るヘッダフィールドは変更が無いので、SNTPバージョン4クライアントはすべ ての前のバージョンNTPとSNTPサーバによって相互運用できる。バージョン4 サーバは、要求と同じバージョンにおいて答えるために必要である。従って、 要求のVNフィールドは返信のバージョンも指定する。 対応クライアント実装で必要ではない間、ユニキャストとエニーキャストモ ードにおいて、それはクライアントクロックに従い要求を送るタイムスタンプ が時刻に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クライアントオペレーションを要約する。推奨されるエラー チェックはテーブルの返信とマルチキャストカラムに示される。もし示された すべてのフィールドがそれぞれの範囲の値を含んでいるならば、メッセージは 有効であると考えられるべきである。フィールドのマークされた "ignore" (無効)の1つ以上が無効の値を抑制するなら、メッセージを信じるかどうかは 実装依存である。 フィールド名 ユニキャスト/エニーキャスト マルチキャスト 要求 返信 ------------------------------------------------------------- 閏秒指示 0 0-2 0-2 バージョン番号 1-4 要求と同じ 1-4 Mode 3 4 5 階層 0 1-14 1-14 Poll 0 無効 無効 正確性 0 無効 無効 ルート遅延 0 無効 無効 ルート分散 0 無効 無効 照会先識別子 0 無効 無効 照会先タイムスタンプ 0 無効 無効 始発タイムスタンプ 0 (本文参照) 無効 受信タイムスタンプ 0 (本文参照) 無効 転送タイムスタンプ (本文参照) 非ゼロ 非ゼロ 認証識別子 オプション オプション オプション 6. SNTP サーバ オペレーション 同じまたは過去のバージョンのNTPまたはSNTPクライアントによって動作し ているSNTPバージョン4サーバは、持続的な状態を保有しない。SNTPサーバが 冗長なピア(同輩端末)および種々なネットワークパスをサポートすることを意 図しているNTPアルゴリズムの完全なセットを通常実行しないので、SNTPサー バは、信頼できるラジオクロック、または電話モデムのような外部の同期化源 だけと連携して操作されるべきである。この場合、それは、常時プライマリ (第一階層)サーバとして動作する。 SNTPサーバは、ユニキャストモード、エニーキャストモード、マルチキャス トモード、またはどのような組み合わせにおいても、SNTPサーバは動作するこ とができる。ユニキャストとエニーキャストモードにおいて、サーバは要求 (モード3)を受け取り、NTPヘッダにおいて一定のフィールドを修正し、そして おそらくは要求と同じメッセージバッファを使って返答(モード4)を送る。エ ニーキャストモードにおいて、サーバは、IANAにより割り当てられた明示され たローカルなブロードキャストまたはマルチキャストグループアドレスにおい て受け取られるが、返答の発信元アドレスフィールドでは自身のユニキャスト アドレスを用いる。返答のアドレスの選択を除いて、エニーキャストとユニ キャストサーバのオペレーションは同一である。マルチキャストメッセージは 通常、64秒から1024秒までの投票間隔によって送られて、クライアントクロッ クおよび必要精度の予期される頻度寛容に依存する。 ユニキャストとエニーキャストモードにおいて、要求のVNとPollフィールド は、返答にそっくりそのままコピーされる。もし要求のモードフィールドが3 (クライアント)であるなら、それは返答の4(サーバ)に設定される; さもなけ れば、このフィールドは、NTP指定に対応するために、2(対称パッシブ)に設定 される。これは、仮に恐らく事前の最適化で設定されても、首尾よく相互運用 するために対称アクティブ(モード1)で、中で設定されたクライアントを許容 する。マルチキャスト(嘆願されない)モードにおいて、VNフィールドは4に設 定されて、モードフィールドは5(ブロードキャスト)に設定されて、Poll フィールドは、投票間隔の最も近い整数base-2対数に設定される。 もしサーバがマルチキャストモードをサポートするなら、それがユニ キャストモードもサポートすることが非常に望ましいことに注意せよ。 これは、そのように潜在的なマルチキャストクライアントがマルチキャ スト方法のみ使う規則的なオペレーションの前にクライアント/サーバ交 換を用いる伝播遅延を計算し得ることである。もしサーバがエニーキャ ストモードをサポートするならば、それはユニキャストモードもサポー トしなければならない。プロトコル仕様はそれを禁じないが、マルチ キャストとエニーキャストモードを同時に操作することは、大きな利点 とはならないだろう。 ユニキャストとエニーキャストモードにおいて、サーバは、もし正しく動作 中の電波時計に同期しないなら、反応しないか、または反応してはならないか もしれません。しかし、同期状態を問わず、これが到達性の決定を可能とする ので、好まれたオプションは反応する必要がある。マルチキャストモードにお いては、サーバは、正しく稼働している参照クロックに同期するならば、ブ ロードキャストを送る。 NTPヘッダの残留フィールドは以下の方法で設定される。サーバがラジオク ロックや他の主要な参照源および正確な動作に同期すると思われるならば、閏 秒指示フィールドは0に設定され、階層フィールドは1に設定される(プライマ リサーバ); さもなくば、階層フィールドは0に設定され、閏秒指示フィールド は3に設定される。正確性フィールドは、ローカルなクロックの最大の目盛り 誤差を反映するように設定される。すべての実用的な事例のために、それは最 小意ビット値の反転として小数点の右にNTPタイムスタンプフォーマットで計 算される。ルート遅延とルート分散フィールドは、プライマリサーバのための 0に設定される; オプションで、ルート分散フィールドは、ラジオクロック自身 の最大の予期される誤差と一致する値に設定できる。照会先識別子は、この文 書のセクション5のテーブルにおいて示されるように、主要な参照源を明示する ために設定される。 タイムスタンプフィールドは次の通り設定される。もしサーバが未同期であ るか、または最初に現われたものならば、すべてのタイムスタンプフィールド は0に設定される。もし同期するならば、照会先タイムスタンプは、最後の アップデートがラジオクロックまたはモデムから受け取られた時間に設定され る。ユニキャストとエニーキャストモードにおいて、受信タイムスタンプと転 送タイムスタンプフィールドは、メッセージが送られる時刻に設定される。そ して、始発タイムスタンプフィールドは、要求の転送タイムスタンプフィール ドから変更無く複写される。このフィールドがそっくりそのままコピーされる ことは、NTPクライアントがそれを使用することでリプレイを避けられるた め、重要である。マルチキャストモードにおいて、始発タイムスタンプと受信 タイムスタンプフィールドは、0に設定され、転送タイムスタンプフィールド は、メッセージが送られる時刻に設定される。下記のテーブルはこれらの動作 を要約する。 フィールド名 ユニキャスト/エニーキャスト マルチキャスト 要求 返信 ------------------------------------------------------------- 閏秒指示 無効 0または3 0または3 バージョン番号 1-4 要求と同じ 4 Mode 3 2または4 5 階層 無効 1 1 Poll 無効 要求と同じ log2 poll間隔 正確性 無効 -log2サーバ -log2サーバ 最上位ビット 最上位ビット ルート遅延 無効 0 0 ルート分散 無効 0 0 照会先識別子 無効 元のまま 元のまま 照会先タイムスタンプ 無効 最終更新時刻 最終更新時刻 始発タイムスタンプ 無効 要求と同じ 0 受信タイムスタンプ 無効 現時刻 0 転送タイムスタンプ (本文参照) 現時刻 現時刻 認証識別子 オプション オプション オプション 最初に発生するであろう、もしくは一次参照源が動作不能である期間中の無 効のタイムスタンプを許容するための大部分のクライアントの側には、いくら かの許容度がある。不健康なサーバの最も重要なインジケータは閏秒指示 フィールドであり、それにおいて、値3が、未同期であった条件を示す。この 値が表示される時は、クライアントは他のフィールドの内容を問わずサーバ メッセージを処分すべきである。 7. コンフィギュレーションと管理 もしファイルシステムが入手可能ならコンフィギュレーションファイル、さ くなくばシリアルポートを使って、SNTPサーバとクライアントのための初期の セットアップがされうる。後述のように、NTPおよびSNTPバージョン4のサーバ とクライアントの稼働中の管理がSNMPおよび適当なMIBを用いて行なわれると いうことが望まれる。通常、SNTPサーバ及びクライアントは、殆どIPアドレス やサブネットマスク、もしくは OSI NSAPアドレスを指定することを除いて、 特定の構成なしで動くことが期待されている。 ユニキャストクライアントは、明示されたサーバ名またはアドレスが提供さ れなければならない。もしサーバ名が使われるなら、より多くのDNSサーバの うちの一つのアドレスが提供されなければならない。マルチキャストサーバと エニーキャストクライアントは、TTLおよびローカルなブロードキャストまた はマルチキャストグループアドレスが提供されなければならない。エニーキャ ストサーバとマルチキャストクライアントは、信頼されたと知られているそれ らのクライアントまたはサーバだけが使われるように、アクセス制御のための アドレスマスクペアのリストによって設定できる。これらのサーバとクライア ントは、IGMPプロトコルを実装し、その上、ローカルなブロードキャストまた はマルチキャストグループアドレスが提供されなければならない。暗号法の認 証のためのコンフィギュレーションデータは、この文書の範囲を越えている。 IPアドレスとサブネットマスクまたはOSI NSAPアドレスを除いて、初期設定 されていない状態で自動的なサーバ発見と選択をSNTPクライアントに提供する いくつかのシナリオがある。十分に機能的なNTPサーバを含むIPサブネットま たはLANセグメントのために、クライアントは、マルチキャストモードのた め、ローカルなブロードキャストアドレスを使って設定できる。同じアプロー チは、マルチキャストグループアドレスを使う他のサーバによっても使われう る。双方のケースにおいて、アクセス制御リストの供給は、ただ信用された ソースを保証することがローカルなクロックをセットするために使われうる良 い方法である。重要なネットワーク伝播遅延を持つ拡張ネットワークに適当な 別のシナリオにおいて、現在選ばれたユニキャスト源が聞かれなかった時に は、クライアントは、エニーキャストモードののために、初期のスタートアッ プ、およびある期間の後において、設定できる。定義されたプロトコルに従っ て、そのクライアントは、聞かれた最初の応答に拘束力があり、そして、ユニ キャストモードにおいてオペレーションを続ける。このモードにおいて、ロー カルな時計は、伝播遅延を補償するために、自動的に調節されうる。 あらゆるネットワークあるいはマルチキャストサービスが利用可能ではな い、適当なまた別のシナリオにおいて、DNSは共通のCNAMEによって設定でき、 同じドメインのNTPサーバのためにtime.domain.net、およびアドレスのリスト のように記録する。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