訳者注:この翻訳は参考訳です。翻訳内容は完全に *無保証* です。私は英語のスペシャリストでもなければ、ネットワークのスペシャリストでもありません。また、技術的な用語に関しても一般的に用いられているものとは限りません。この翻訳を使用したことにより被ったいかなる不利益に対しても訳者は一切責任を負いません。実際の使用の際には、必ず原文を参照してください。なお、原文の段落があまりにも長いと感じたので、段落は適当に分けられており、原文とは一致していません。

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

IPv4・IPv6・OSI用簡易ネットワーク時刻プロトコル(SNTP)Version 4

Simple Network Time Protocol(SNTP) Version 4
for IPv4, IPv6 and OSI

この文書の位置づけ

 この文書はインターネットコミュニティーのための情報を提供します。このメモはインターネットの標準規格を提供するものではありません。この文書の再配布に制限はありません(訳注:この翻訳も再配布して構いませんが、一番最初の注意書きは書き換えないこと)。

概要

 このメモは簡易ネットワーク時刻プロトコル(Simple Network Time Protocol - SNTP)Version 4について説明しています。SNTPはNTPをインターネット上でコンピューターの時計を同期させるために使用されるNTPを多少簡単にしたものです。SNTPはRFC-1305で説明されている完全なNTPの実装の究極の能力が必要ない場合、あるいはなんらかの理由がある場合に使用されます。現在の、あるいは以前のバージョンのNTPあるいはSNTPと共に動作する場合に、SNTP Version 4はNTPの仕様あるいは既に知られている実装の変更を必要としませんが、単純で、RFC-868で説明されているUDP/TIMEプロトコルと同様の正確さと高い信頼性を持つ状態定義のない(statless)リモート手続き呼び出し(remote-procedure call - RPC)モードによる動作を可能にする、NTPの設計の特色のclarification(訳注:私の能力では訳せませんでした。以下原文:

When operating with current and previous NTP and SNTP versions, SNTP Version 4 involves no changes to the NTP specification or known implementations, but rather a clarification of certain design features of NTP which allow operation in a simple, stateless remote-procedure call (RPC) mode with accuracy and reliability expectations similar to the UDP/TIME protocol described in RFC-868.)

 ただ一つ、以前のNTPとSNTPからのSNTP Version 4の重要な変更点は、ヘッダの実装方法がインターネットプロトコルVersion 6(IPv6)[DEE96]とOSI[COL94]アドレス方法を収容できるようになった事です。しかし、SNTP Version 4はエニーキャストモードと、マルチキャストおよびエニーキャストモード用の認証機構を含んだ、基本的なVersion 3のモデルの任意な(optional)拡張を含んでいます。エニーキャストモードの拡張はこの文書で説明されていますが、認証機構の拡張はこれ以降に発行する、他の文書で説明される予定です。決定版の仕様が発行されるまでこれらの拡張は暫定的なものと考えられます。

 このメモはSNTP Version 3を説明しているRFC-1769をobsoleteします(訳注:RFC-1769を過去のものとする、という意味。RFCではobsoleteをよく動詞として使っているが、辞書を引くと形容詞の意味しか載ってない (^-^; )。その目的は、以前の文書にあった明らかな矛盾を訂正し、ヘッダーの形式と、現在のNTP Version 3(IPv4)及び、SNTPとしても使用されている、提案されている(proposed)NTP Version 4(IPv6とOSI)のプロトコルの動作をはっきりさせる事にあります。RFC-1305 NTP Version 3仕様の知識はSNTPの実装には必要ありません。

1. 序説

 RFC-1305[MIL92]で規定されているネットワーク時刻プロトコル(NTP)Version 3は、インターネットの中でコンピューターの時計を同期するために広範に使用されています。NTPは標準時(national time)と周波数disseminationサービスへアクセスするための 分かりやすい機構を示し、サブネットピアとして関係している時刻同期サブネットとローカル時計を組織化することができます。今日、インターネットのいろいろな場所で、同期源やネットワーク経路にもよりますが、NTPは1-50m秒の精度(の時刻源)を提供しています。

 RFC-1305はイベント・状態・遷移機能と挙動(transition functions and actions)、それに加えて時刻を保つ精度と向上させるための、そして同期源の中に間違ったものがあった場合に、それを緩衝するための、巧みなアルゴリズムという見地から、NTP Version 3プロトコルマシンを規定しています。今日のインターネットの主な部分に渡る経路を経ても数ミリ秒の精度を保つために、複雑なアルゴリズム、あるいはそれと機能的に同等なものが必要になります。しかし、多くの場合は精度は0.1秒程度(訳注:思いっきり意訳です。in the order of significant fractions of a second)で十分でしょう。 このような場合には、時刻プロトコル[POS83](訳注:巻末参考文献の[POS83]を参照のこと)のようなもっと単純なプロトコルが使われています。これらのプロトコルはクライアントが時刻を要求し、サーバーが既知の基準点からの経過時間を返すところで、通常RPC交換(RPC exchange)を伴います。

 NTPはいろいろな能力のクライアントとサーバーを、広い範囲の遅延とジッタ特性を持ったネットワーク越しに使うために設計されています。今日のインターネットNTP同期サブネットのほとんどのユーザーは、完全なNTPのオプションとアルゴリズムを含んだソフトウェアパッケージを使っていると思いますが、それらは比較的複雑で、リアルタイムに動くアプリケーションです(http://www.eecis.udel.edu/~ntpを参照のこと)。このソフトウェアはパーソナルコンピューターからスーパーコンピューターまで、いろいろなハードウェア用に移植されてきたので、その本当の大きさと複雑さは多くの用途には適当ではないでしょう。従って、あまり厳重な精度を要求しない場合に適した、より単純なソフトウェアを使用した、代わりのアクセス戦略を探すことは有用な事でしょう。

 この文書は簡易ネットワーク時刻プロトコル(SNTP)Version 4を説明しています。SNTP Version 4は、現在定義されインターネットに展開されているNTP Version 3や、現在開発中のNTP Version 4を使用しているサーバーとクライアントのための、単純化したアクセス戦略です。アクセスの規範はUDP/TIMEプロトコルと同じで、実際、パーソナルコンピューターについて言うと、クライアントでSNTPを用いて動作させるのは比較的簡単です(訳注:ちょっと意訳)。しかも、SNTPは内蔵された電波時計を含む献身的なサーバー設定で動作させることも念頭に置いて設計されています。注意深い設計とシステムのいろいろな遅延の制御と共に用いれば、マイクロ秒の精度の時刻を提供することも可能でしょう(訳注:ちょっと省略)。

 SNTP Version 4は既存のNTPやSNTP Version 3クライアントやサーバーと共存するように設計されており、同様に提案中のVersion 4クライアントやサーバーとも共存するように設計されています。現在もしくは以前のバージョンのNTPあるいはSNTPと共に動作する場合、SNTP Version 4は、現在動作中、あるいはNTP・SNTP Version 4としてはっきりと実装されそうなプロトコルあるいは実装の変更を必要としません(訳注:かなり直訳。つまり、SNTP ver 4は、既存のプロトコルに影響を与えない、ということだろう)。

 NTPあるいはSNTPサーバーは、NTPとSNTPクライアントを区別できません。NTPあるいはSNTPクライアントは、NTPとSNTPサーバーを区別できません。対称でないモードで動作しているNTPサーバーのように、SNTPサーバーは状態がなく、多くの数のクライアントをサポートできます。しかし、多くのNTPクライアントとは異なり、SNTPクライアントは通常一つのサーバーとしか動作できません。NTP/SNTP Version 3サーバーはユニキャストモードとマルチ安とモードで動作できます。さらに、SNTP Version 4クライアントとサーバーはエニーキャストモードで動作する拡張(された)機能を実装できます。

 SNTPは同期サブネットの末端でのみ使用される事を強く推奨します。SNTPクライアントはサブネットの末葉(最大の階級)としてのみ動作すべきです。また、NTPあるいはSNTPクライアントは同期を他のSNTPクライアントに依存してはいけません。SNTPサーバーはサブネットのルート(階級1)としてのみ動作すべきで、信頼性の高い電波時計やモデムによるサービス以外の同期源で動作すべきではありません。

 通常一次サーバーに期待される完全な信頼性は、冗長性のある同期源、いろいろなサブネット経路と完全なNTPの技巧的なアルゴリズムの実装を使う事によってのみ可能です。これは一次同期源それ自身についても、複数の電波時計やモデムサービスによる同期源や、他の一次サーバーへのバックアップ経路 should すべての同期源が落ちたり、多数の誤った時刻の配信(訳注:この途中に「ぽこ」っと入ったshouldの意味が分からない)という形で拡張(適用?)されます。従って、NTPではなくてSNTPを一次サーバーとして使用することは、注意深く考えてみる必要があります。

 この文書における重要な規定は、IPv6とOSIアドレッシングと、実装は任意ですが、マルチキャストサービスのために設計されたエニーキャスト拡張を提供する、正しいNTP Versino 4ヘッダー領域の再解釈です。これらの追加項目は、この文書とは独立に規定される、現在提案中のNTP Version 4の仕様と関連しています。

 現在のNTP Version 3と提案中のNTP Version 4ヘッダ形式の間の違いはただ一つで、主に同期のループ(堂々巡り)を検出し防ぐために使用される、4オクテット(訳注:4バイト)の基準ID領域だけが異なります。Version 3とVersion 4の一次(階級1)サーバーでは、この領域はこの文書で後に述べる、4文字のASCII基準IDになります。Version 3の従属サーバーとクライアントは、同期源を示す32ビットのIPv4アドレスになっています。Version 4従属サーバーとクライアントでは、同期源から直前に受信した送信タイムスタンプの下位32ビットになっています。

 OSIではコネクションレストランスポートサービス(CLTS)が使われます[ISO86]。各SNTPパケットはT-UNIDATA要求プリミティブのtht TSユーザーデータパラメータとして送信されます(訳注:OSIってよく分からないのだけど、このthtってtheのミスタイプ科 も?)。代わりに、ヘッダーは、UDP[DOB91]を使って送受されるTPDUによってカプセル化されても構いません。NTP[FUR94]から推察されるようなOSIスタックの上位層で運用される事は、非常に精度が落ちてしまうので勧められません。この文書で定義されているヘッダ形式では、実際には困難と思われますが、原則として複数のプロトコルファミリーのサーバーとクライアントを相互に動作させること(interwork)が可能です。

 以降、このように字下げされている段落は、正式なプロトコル仕様には必要ではないが、プロトコルを実装する際に実施するとよいと思われる事を述べています。

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

 SNTP Version 4はユニキャスト(一対一)・マルチキャスト(一対多)・あるいはエニーキャスト(多対一)のモードで動作します。ユニキャストクライアントはユニキャストアドレスで指定されたサーバーへリクエストを送り、時刻と、もしあれば往復にかかった遅延と自マシンとサーバーの時刻の差を決定できる応答を期待します。

 マルチキャストサーバーは定期的に、指定されたIPv4・IPv6のローカルブロードキャストアドレスあるいはマルチキャストグループアドレスに、他からの依頼がなくてもメッセージを送り、通常クライアントからの要求を期待しません。マルチキャストクライアントはこのアドレスを監視しており、通常、要求は送信しません。

 エニーキャストクライアントは指定されたIPv4あるいはIPv6のローカルブロードキャストアドレス、あるいはマルチキャストグループアドレスに要求を送ります。一つ、もしくは複数のエニーキャストサーバーがそれぞれユニキャストアドレスで応答します。クライアントは一番最初に受信した応答を使用し、その後、ユニキャストモードで動作を続けます。

 マルチキャストサーバーは、他からの依頼のないマルチキャストメッセージと同様に、クライアントのユニキャストリクエストに対しても応答すべきです。マルチキャストクライアントはサーバーとクライアントの間のネットワーク伝達遅延を決定するためにユニキャストリクエストを送信し、マルチキャストモードで動作を続ける事ができます。

 ユニキャストモードでは、通常のIPv4・IPv6、あるいはOSIの規約によるclient and server end-system addressが割り当てられています。マルチキャストモードでは、サーバーは指定されたローカルブロードキャストアドレスあるいはマルチキャストグループアドレスを使用します。IPローカルブロードキャストアドレスは、ルーターがIPブロードキャストデータグラムを伝達しないため、一つのIPサブネットに範囲が制限されています。

 それに対して、IPマルチキャストグループアドレスは潜在的には全インターネットに拡張された範囲で利用できます。範囲の決定(scoping)、ルーティング、group membership proceduresについてはこの文書の目的ではありませんので割愛します(直訳:この文書を超えた考察によって決定されます)。IPv4については、IANA(訳注:Internet Assigned Numbers Authority)が244.0.1.1をNTP用のマルチキャストグループアドレスとして割り当てており、マルチキャストサーバーあるいはエニーキャストクライアントのどちらでも使用されます。IPv6とOSIについてはまだ決定されていません。

 マルチキャストクライアントは指定されたローカルブロードキャストあるいはマルチキャストグループアドレスを監視しています。ローカルブロードキャストアドレスの場合には、それ以外の準備は必要ありません。

 IPマルチキャストアドレスの場合には、マルチキャストクライアントとエニーキャストサーバーは、ローカルルーターがマルチキャストグループに加わり、IANAによって割り当てられたIPv4あるいはIPv6マルチキャストグループにメッセージを伝えるために、インターネットグループ管理プロトコル(訳注:Internet Group Management Protocol: IGMP, [DEE89])を実装しなければなりません。

 IPアドレス規約あるいはIGMP以外の場合には、ローカルブロードキャストアドレスあるいはマルチキャストグループアドレスを用いた場合のサーバーとクライアントの動作に違いはありません。

 マルチキャストメッセージのIPヘッダーの中にある残存時間(訳注:time-to-live: TTL)フィールドを妥当な値に修正する事は、この(あるいは他の)マルチキャストサービスが使用するネットワーク資源を制限するために重要です。スコープ内にあるマルチキャストクライアントだけがマルチキャストサーバーメッセージを受信するようになるでしょう。スコープ内にある協調して動作しているエニーキャストサーバーがクライアントの要求に応答するようになるでしょう。利用されるべき完璧な値を決定する技術的な原理については、この文書の目的ではありません(訳注:ので割愛します)。

 エニーキャストモードは、協調動作するサーバー群と共に使用するために設計されています。そして、クライアントはサーバーのアドレスを事前に知りません。エニーキャストクライアントは以下で説明する指定されたローカルブロードキャストあるいはマルチキャストグループアドレスに要求を送ります。この目的には、IANAによってアサインされたNTPマルチキャストグループアドレスが使用されます。

 一つ、あるいは複数のエニーキャストサーバーが指定されたローカルブロードキャストアドレスあるいはマルチキャストグループアドレスを監視しています。要求を受け取ったエニーキャストサーバーは、それぞれがユニキャスト応答メッセージを要求を送信したクライアントに送信します。クライアントはこれらのメッセージのうちの最初のメッセージを使用(binds)し、ユニキャストモードで動作を続けます。最初のメッセージの後に続く、他のエニーキャストサーバーからの応答は無視されます。

 ここで規定されているSNTPの場合、現在すべてのサーバーがIANAからアサインされた同じIPv4マルチキャストグループアドレスを使用しているため、インターネット中に、間違った動作や好ましくない動作をするSNTPあるいはNTPマルチキャストサーバーがあると、SNTPマルチキャストクライアントは簡単に混乱してしまいます。

 必要ならば、クライアントが知っている、信頼できるサーバーだけを選択するために、サーバーの送信元(source)アドレスを使用したアクセス制御が使用できます。RFC-1305で定義されている暗号による認証機構の使用は任意です。しかし、実装する人は、この機構を用いた拡張がNTPマルチキャスト・エニーキャストモードに対して計画されていると考えてください(直訳:助言されるべきでしょう)。

 SNTPの仕様には含まれていませんが、IPブロードキャストアドレスは、主としてIPサブネット内、あるいは同じサブネット上にあるいくつかの従属的なSNTPマルチキャストクライアントと共に完全な機能を持ったNTPサーバーを含むLANセグメントで使用する事を意図しています。一方、IPマルチキャストグループアドレスはTTL(Time-to-Live)がそれぞれのサービスドメインできちんと管理されているような場合にのみ使用されます。

 NTP Version 3では、管理を目的として、基準IDは時刻同期サブネットをルート(一次サーバー)に向かってさかのぼるためにしばしは使われていました。NTP Version 4では、アドレスが32ビットよりも長くなってしまった(訳注:IPv6)ため、この機能は有効ではありません。

 しかし、プロトコルを設計した時に意図したのは、ループを検出し、防ぐ方法を提供する事でした。ピアーはこの領域の内容を、同一パケット内のIPv4目的地アドレスと比較する事で、ループの可能性があることを決定することができます。

 NTP Version 4サーバーは、この領域の内容を、同じパケットの基点(originate)タイムスタンプの下位32ビットと比較することによって、同じ目的を果たせます。この方法は誤検出の可能性がわずかにありますが、送信タイムスタンプの使用されていない下位ビットを乱数で埋めることで、誤検出の頻度を可能な限り小さくすることができます。

3. NTPタイムスタンプ形式

 SNTPはRFC-1305、あるいはそれ以前の文書で説明されている標準的なNTPタイムスタンプ形式を使用します。通常のインターネットの習慣に従って、NTPのデータはビッグエンディアン(訳注:最上位桁が最初に来る形式)の、左側もしくは上位のビット番号が0から始まる整数、あるいは固定小数点で表現されます。特に断りがない限り(訳注:他の方法が指定されない限り)、すべての値(quantity=量)は無符号であり、ビット0より前は暗黙的に0で全フィールド幅を埋めます(訳注:要するに隙間は0で埋めろ、という事か?)。

 NTPタイムスタンプは大事なデータで、実際に、このプロトコルの根幹をなしているので、特別なタイムスタンプ形式が作成されました。NTPタイムスタンプは64ビットの無符号固定小数点数により、1900年1月1日0時(訳注:どこにも書いてないようだが、もちろんこれはUTC)からの秒数で表現されます。整数部は最初の32ビットで、小数部は後ろの32ビットです。小数部においては、重要でない下位ビットは0にする事ができます。

 システム的な丸め誤差を防ぐ、あるいはループや応答の検出をするために、タイムスタンプの重要でない下位ビットを乱数や偏りのないビット列で埋めるとよいでしょう。例えば、64ビットワードの乱数ビット列を生成し、タイムスタンプの必要なビット数分だけ算術右シフトを実行し、元のタイムスタンプに足す方法があります。

 この形式は倍精度演算(multiple-precision arithmetic)やUDP/TIME形式との変換は比較的簡単に行えますが、ICMPタイムスタンプメッセージ形式はmSec単位なので、この形式に変換するのは面倒です。最大値は4,294,967,295秒をだいたい100ピコ秒(訳注:ピコ=10の-12乗、よって、100ピコ秒=10の-10乗秒)の精度で表現でき、これはもっとエキゾチックな要求(訳注:どんなんや)に対しても十分でしょう。

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
Seconds
Seconds Fraction (0-padded)

 1968年のどこか(2,147,483,648秒)で最上位ビット(整数部のビット0(訳注:多くのCPU内での表現と違って、最上位ビットがビット0であることに注意))が1になっており、2036年のどこか(4,294,967,296秒)で64ビットのフィールドがオーバーフローする事に注意してください。NTPあるいはSNTPは2036年まで使われるでしょうから、1900年からの時間なのか、あるいは2036年からの時間なのか(あるいは、以後の136年毎からの時間なのか)を決定するための適当な手段が必要になります。136年に一度、64ビットが全部0になったとき、これは規約によれば無効あるいは有効でない(invalid or unavailable)タイムスタンプとなるので、200ピコ秒の間無視されるべき期間が存在します。

 NTPタイムスタンプ形式は17年間使用されてきています。あと40年で秒領域がオーバーフローしますが、それ以上使われ続ける可能性があります。1968年以前にNTPタイムスタンプのビット0がセットされる事はおそらく適当でないので、NTPタイムスタンプを今後も使えるようにするための便利な方法は、次のようになるでしょう。

 もし、ビット0(訳注:MSB)がセットされていたら、1968年〜2036年の間にあって、時刻は1900年1月1日0:00UTCから計算します。もし、ビット0が0ならば、時刻は2036年〜2104年の間で、2036年2月7日6時28分16秒UTCから計算します。対応関係を計算する時には、2000年は閏年ではなく(訳注:閏年だと思うが。上の数値を計算してみると、2000年はちゃんと閏年で計算されている)、閏秒は計算しない事に注意してください。

(訳注:閏秒とは、地球の自転周期とUTCとの対応関係を調整するために挿入・削除される1秒で、閏秒が適用されるとすれば1/1と7/1の午前0時の直前と決まっているが、地球の自転周期になるべく合致するように原子時が定められているので、そんなに頻繁に入るわけではない。また、地球の自転周期がそれほど安定していないため、必ず一定の間隔で入るとは限らない。したがって、あらかじめ計算しておく事は不可能である。)

4. NTPメッセージ形式

 NTPとSNTPはどちらもUDP(User Datagram Protocol [POS80])を利用していて、UDPはIP(Internet Protocol [DAR81])を利用しています。IPとUDPのヘッダの構造は公開されている仕様書に説明されていますので、ここでは詳しくは説明しません。NTPに割り当てられたUDPポート番号は123で、UDPヘッダ中で送信元ポートとしても、送信先ポートとしても使用されます。残りのUDPヘッダ領域については、上述の仕様書に書かれている通りです。

 NTP/SNTP Version 4メッセージは以下のようになっており、IP・UDPヘッダーの後に続いています(訳注:要するに普通にrecvfromなどで受信すると得られる部分)。この形式はリファレンスID領域の内容を除いて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 Stratum Poll Precision
Root Delay
Root Dispersion
Reference Identifier

Reference Timestamp (64)


Originate Timestamp (64)


Receive Timestamp (64)


Transmit Timestamp (64)

Key Identifier (optional) (32)


Message Digest (optional) (128)


 次の説で説明するように、SNTPではこれらのほとんどの領域はあらかじめ決められたデータで初期化します。以下にそれぞれの領域について簡単に説明します。

閏秒指示子(Leap Indicator, LI)

 これは2ビットのコードで、閏秒の挿入・削除が今日の最後の分(minute)に起こる事を示す警告です。ビット0と1はそれぞれ次のようになっています。

(訳注:多分この意味であっていると思うが・・・)

LI 意味
00 0 警告なし
01 1 最後の分は61秒
10 2 最後の分は59秒
11 3 警報(時計が同期していません)

バージョン番号(Version Number, VN)

 これはNTP/SNTPバージョン番号を示す3ビットの整数です。バージョン番号が3ならばVersion 3(IPv4のみ)を示し、4ならばVersion 4(IPv4・IPv6およびOSI)を示します。もし、IPv4・IPv6およびOSIを区別する必要がある場合は、カプセル化している(encapsulateing)情報(訳注:IPヘッダなどの事か?)を調べる必要があります。

モード(Mode)

 これはモードを示す3ビットの整数です。数値の意味を以下に示します。

Mode意味
0予約済み)
1対称能動(symmetric active)
2対称受動(symmetric passive)
3クライアント
4サーバー
5ブロードキャスト
6NTP制御メッセージ用に予約
7それ以外の用途のために予約(reserved for private use)

 ユニキャストおよびエニーキャストモードでは、クライアントはこのフィールドを3(クライアント)にセットした要求を送り、サーバーは4(サーバー)にセットした応答を返します。マルチキャストモードではサーバーはこのフィールドを5(ブロードキャスト)にセットします。

階級(Stratum)

 これはローカル時計の階級レベルを示す8ビットの無符号整数です。意味を以下に示します。

Stratum意味
0規定なし、あるいは有効でない(unspecified or unavailable)
1一次基準源(電波時計など)
2-15従属的な基準(secondary reference) (NTPやSNTP経由)
16-255予約済み

ポーリング間隔(Poll Interval)

(訳注:ポール=チェックしに行くこと)

 これは二つの連続するメッセージ間の最大の間隔(maximum interval・・・訳注:これ以上の頻度で送ってはいけない、というようにも見える)を示す8ビットの符号付き整数で、秒を最も近い2のべき数で表現します(訳注:64秒なら64=2の6乗なので、6になる)。この領域に現れることのできる数値は現在4(16秒)から14(16284秒・・・訳注:16384でしょう、これは)の間です。しかし、多くのアプリケーションはこのうちの6(64秒)から10(1024秒)だけを使います。

精度(Precision)

 これはローカル時計の精度を示す8ビットの符号付き整数で、秒をもっとも近い2のべき乗を用いてあらわします。この領域に通常現れる値は-6(mains-frequency clocks)から-20(マイクロ秒単位の時計・・・ある種のワークステーションに見られます)です。

ルート遅延(Root Delay)

 これは一次基準源までの往復の遅延の合計を、32ビットの符号付き固定小数点数を用いて秒単位であらわしたもので、ビット15と16の間に小数点があります。この変数は相対時間もしくは周波数変位かによって、正にも負にもなることに注意してください。この領域に現れる数値は通常数ミリ秒の負の値から数百ミリ秒を示す正の数になります。

ルート分散(Root Dispersion)

 この数値は一次基準源との相対的な名目上の誤差を示す32ビットの無符号固定小数点数で、小数点がビット15と16の間にあります。秒で表現します。この領域に現れる数値は通常0から数百ミリ秒の間です。

基準ID(Reference Identifier)

 これは特定の基準源を識別する32ビットのビット列です。NTP Version 3あるいは4の階層0(未定義)あるいは階層1(一次基準源)のサーバーでは、これは4文字のASCII文字列で、左側に詰められ、後ろには0を入れ、32ビットにします。

 NTP Version 3の従属的なサーバーでは、これは基準源の32ビットIPv4アドレスになります。NTP Version 4の従属的なサーバーでは、これは基準源の最終送信タイムスタンプの下位32ビットになります。NTP一次基準源(階層1)サーバーはこの領域を以下のリストによって外部基準源を識別するコードセットしなければなりません。もし、外部基準源が以下のどれかの場合には、そのコードを使用します。基準源のコードがない場合には、適当にcontriveされます。

Code外部基準源
LOCL 外部の同期手段を使用せず、校正されていないローカル時計を一次基準源としてサブネット用に使用している
PPS 個々の国の基準で校正されている原子時計あるいは他の1秒1パルスの基準源
ACTS NISTダイヤルアップモデムサービス
USNO USNOモデムサービス
PTB PTB(ドイツ)モデムサービス
TDF Allouis(フランス)ラジオ164kHz
DCF Mainflingen(ドイツ)ラジオ77.5kHz
MSF Rugby(イギリス)ラジオ60kHz
WWV Ft. Collins(アメリカ)ラジオ2.5, 5, 10, 15, 20MHz
WWVB Boulder(アメリカ)ラジオ60kHz
WWVH Kaui Hawaii(アメリカ)ラジオ2.5, 5, 10, 15MHz
CHU Ottawa(カナダ)ラジオ3330, 7335, 14670kHz
LORC LORAN-C無線航行システム
OMEG OMEGA無線航行システム
GPS 全地球測地サービス(訳注:だったっけ? 要するにGPS)
GOES Geostationary Orbit Environment Satellite (訳注:(^-^??
訳注:日本にも筑波に基準局があったと思います。あと、有名なのはJJY、でしょうか。

基準タイムスタンプ(Reference Timestamp)

 これはローカル時計が最後にセット、あるいは修正された時刻で、64ビットタイムスタンプ形式で表現します。

基点タイムスタンプ(Originate Timestamp)

 これはクライアントがサーバーに要求を出した時刻で、64ビットタイムスタンプ形式で表現します。

受信タイムスタンプ(Receive Timestamp)

 これはサーバーに要求が届いた時刻で、64ビットタイムスタンプ形式で表現します。

送信タイムスタンプ(Transmit Timestamp)

 これはサーバーがクライアントに対し応答データを出した時刻で、64ビットタイムスタンプ形式で表現します。

認証識別子(Authenticator)(オプション)

 NTP認証機構が組み込まれている場合、キー識別子とメッセージダイジェスト領域は、付録CのRFC-1305で定義されているメッセージ認証コード(MAC)情報が入ります。

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

 SNTPクライアントはマルチキャストモード、ユニキャストモード、あるいはエニーキャストモードのいずれかで動作できます。マルチキャストモードでは、クライアントは要求を送らず、指定されたマルチキャストサーバーからのブロードキャスト(モード5)を待ちます。ユニキャストモードでは、クライアントは要求(モード3)を指定されたユニキャストサーバーに送り、サーバーからの応答を期待します。

 エニーキャストモードでは、クライアントは応答を指定されたローカルブロードキャストもしくはマルチキャストグループアドレスに送り、一つもしくは複数のエニーキャストサーバーからの応答(モード4)を期待します。クライアントは最初に受信した応答を、以降のユニキャスト動作に用いるサーバーを特定するために使用します。それ以降のサーバーからの(重複した)応答、あるいは他のサーバーからの応答は無視されます。

 要求アドレスの選択方法以外は、エニーキャストとユニキャストクライアントの動作は同じです。要求は通常64秒から1024秒の間隔で送信され、送信間隔はクライアントの時計の周波数耐性(訳注:周波数の安定性みたいなものでしょう)と要求される精度に依存します。

 ユニキャストもしくはエニーキャストクライアントはNTPメッセージヘッダーを初期化し、要求をサーバーに送信し、応答の送信タイムスタンプ領域から時刻を取り出します。この目的には、先に示したすべてのNTPヘッダー領域は、最初のオクテット(訳注:8ビット分=バイトの事です)と(必要ならば)送信タイムスタンプ領域以外を、0にセットします。最初のオクテットは、LIを0(警告なし)に、モードを3(クライアント)にセットします。

 VN領域はNTP/SNTPサーバーに適合するようにしなければなりません。しかし、Version 4サーバーは以前のバージョンも受け付けてくれるでしょう。Version 3(RFC-1305)やVersion 2(RFC-1119)サーバーはVersion 1(RFC-1059)を含めた以前のバージョンをすべて受け付けます。Version 0(RFC-959)はもう他のバージョンではサポートされないことに注意してください。

 おそらく4つすべてのバージョンのNTPとSNTPサーバーがインターネット上で相互に運用され続けるでしょうから、SNTPバージョン4クライアントで使用されるバージョンには最新の注意が必要です。クライアントは、最大の精度と信頼性のために、選んだサーバーでサポートされている事が分かっている最新のバージョンを使用することを推奨します。

 SNTPクライアントで使用されているヘッダー領域は変更されていないので、SNTPバージョン4クライアントは以前のすべてのバージョンのNTP・SNTPサーバーと共に運用することができます。バージョン4サーバーはリクエストと同じバージョンで応答することを要求されます。したがって、要求中のVN領域は、応答のバージョンを指定することになります。

 クライアントの実装に必要な事ではありませんが、ユニキャストとエニーキャストモードでは要求中の送信タイムスタンプを、クライアントの時刻をNTPタイムスタンプ形式にしたものに設定することを強く推奨します。これは、サーバーとクライアントの間の伝達遅延を単純な計算で決定することを可能にし、ローカル時計をサーバーに対し、通常数10ミリ秒の精度で合わせる事を可能にします。さらに、特定のサーバーの要求に対し、サーバーの応答が実際に正しい応答かどうかを検証し、再送を防ぐ簡単な方法を提供します。マルチキャストモードでは、NTP認証機構を使用しない限り、クライアントは伝達遅延を決定するための情報や、サーバーが有効かどうかを判断する情報は得られません。

 往復の遅延 d とサーバーからのローカル時計の誤差 t を計算するには、クライアントは要求中の送信タイムスタンプを、クライアントの時計の時刻をNTPタイムスタンプ形式で設定します。サーバーはこの領域を応答中の基点(originate)タイムスタンプにコピーし、受信タイムスタンプと送信タイムスタンプに、サーバー時計の時刻をNTPタイムスタンプ形式で設定します。

 サーバーの応答を受信したら、クライアントは目的地(Destination)タイムスタンプ変数を、クライアントの時計で受信した時刻を求め、NTPタイムスタンプ形式として決定します(訳注:要するに、受信した時刻を目的地タイムスタンプとする、という意味。NTPタイムスタンプに変換しておくと後の計算が楽になる)。次の表に4つのタイムスタンプをまとめておきます。

タイムスタンプの名前 記号 生成された時刻
Originate Timestam T1 クライアントによって要求が送信された時刻
Receive Timestamp T2 サーバーによって要求が受信された時刻
Transmit Timestamp T3 サーバーによって応答が送信された時刻
Destination Timestamp T4 クライアントによって応答が受信された時刻

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

d = (T4 - T1) - (T2 - T3)

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

 ユニキャスト・エニーキャスト・マルチキャストモードでのSNTPクライアントの動作を次の表にまとめておきます。推奨されるエラーチェックは、表中の応答あるいはマルチキャストの列に書いてあります。メッセージは以下に示されたすべての領域の値がそれぞれの値の範囲に収まっている場合にのみ、有効だと考えなければなりません。一つあるいは複数の「無視(ignore)」と書かれた領域に無効な値が入っているメッセージを信頼のおけるものとするかどうかは、実装者の裁量にまかされています。

Field Name Unicast/Anycast Multicast
Request Reply
LI 0 0-2 0-2
VN 1-4 copied from request 1-4
Mode 3 4 5
Stratum 0 1-14 1-14
Poll 0 ignore ignore
Precision 0 ignore ignore
Root Delay 0 ignore ignore
Root Dispersion 0 ignore ignore
Reference Identifier 0 ignore ignore
Reference Timestamp 0 ignore ignore
Originate Timestamp 0 (本文参照) ignore
Receive Timestamp 0 (本文参照) ignore
Transmit Timestamp (本文参照) nonzero nonzero
Authenticator optional optional optional

6. SNTPサーバーの動作

 同じ、もしくは以前のバージョンのNTP・NTPクライアントと共に動作しているSNTP Version 4サーバーは、いずれの場合でも非持続状態を保持します(retains no persistent state.)。SNTPサーバーは通常、冗長なピアや多様なネットワーク経路をサポートするための完全なNPTアルゴリズムを実装していないので、SNTPサーバーは信頼のおける電波時計やモデムのような外部同期源と接続して動作すべきです。この場合、サーバーは常に一次基準源(階級1)として動作します。

 SNTPサーバーはユニキャストモード・エニーキャストモード・マルチキャストモード、あるいはこれらのモードを組み合わせて動作することができます。ユニキャストモードとエニーキャストモードでは、サーバーは要求(モード3)を受け取り、NTPヘッダーのしかるべき領域を変更し、応答(モード4)を送り返します。おそらく、要求を受信した時のバッファと同じバッファが応答の送信にも使えるでしょう。

 エニーキャストモードでは、サーバーは特定のローカルブロードキャストあるいはIANAによって割り当てられたマルチキャストグループアドレスを監視していますが、応答ではサーバー自信のユニキャストアドレスを応答中の送信元アドレスとして使用します。応答するアドレス以外は、エニーキャストサーバーとユニキャストサーバーの動作は同じです。マルチキャストメッセージは通常、64秒から1024秒のポール間隔で送信され、これはクライアントの時計の周波数耐性と要求される精度に依存します。

 ユニキャストモードとエニーキャストモードでは、要求のVNとPoll領域はそのまま応答にコピーします。もし、要求のモード領域が3(クライアント)の場合には、応答では4(サーバー)にセットします。それ以外の場合は、NTP仕様に適合するよう、2(対称受動)にセットします。こうすることで、最適ではない方法で(possibly suboptimal ways)対称能動(モード1)と設定されたクライアントと共に動作できるようになります。

 マルチキャスト(無要求)モードでは、VN領域は4に、モード領域は5(ブロードキャスト)に、そして、ポール領域はポール間隔を2のログをとり、それに一番誓い整数に設定します。

 もし、サーバーがマルチキャストモードをサポートするのならば、ユニキャストーモードもサポートする事を強く望みます。こうする事で、マルチキャストクライアントは、マルチキャストモードだけを使う通常の動作に先立ってクライアントサーバーによる通信を使用し、伝達遅延を計算する事ができます。プロトコルの仕様で禁止してはいませんが、同時にマルチキャストモードとエニーキャストモードを動作させる事はあまり利点がないでしょう。

 ユニキャストモードとエニーキャストモードでは、無線時計に正常に同期していない場合に、サーバーは応答しても応答しなくても構いません。しかし、好ましい動作は応答する事、です。こうする事で、同期しているかどうかに関わらず、そのサーバーに到達できるかどうかが決定できます。マルチキャストモードでは、サーバーは正常に基準時計と同期している時にのみブロードキャストを送るべきです。

 NTPヘッダーの残りの領域は次のように設定します。サーバーが無線時計やその他の一次基準源に正常に同期している場合は、LIは0にセットし、階級は1(一次サーバー)にセットします。もし、そうでなければ(同期していなければ)、階級は0に、LIは3に設定します。

 精度はローカル時計の最大の読み出し誤差を反映するように設定します。通常、NTPタイムスタンプの小数点よりも右の、意味のあるビット数にマイナスを付けたものになります(訳注:つまり、NTPタイムスタンプが小数以下20ビットの精度を持っていれば-20になり、これはつまり2の-20乗の精度があるという意味だから、1マイクロ秒の精度に相当する)。

 ルート遅延とルート分散は一次サーバーでは0にします。ルート分散は無線時計自身の予想される最大の誤差に設定することもできます。基準IDは5節の表に示された、一次基準源を示すように設定します。

 タイムスタンプ領域は次のように設定します。サーバーが同期してない、あるいは立ち上がった直後には、すべてのタイムスタンプは0に設定します。同期している場合には、基準タイムスタンプは電波時計やモデムを使用して最後に時計を校正した時刻をセットします。

 ユニキャストモードあるいはエニーキャストモードでは、受信タイムスタンプと送信タイムスタンプはメッセージが送信される時刻に設定し、基点(Originate)タイムスタンプは要求の送信タイムスタンプを変更せずにそのままコピーします(訳注:ということは、送受信で同じバッファを共有する場合、送信タイムスタンプより前に基点タイムスタンプを設定しなければいけない、ということになる。じゃないと上書きしちゃうから)。この領域はNTPクライアントが再送を防ぐために使用するために、正確にコピーする事はとても重要な事です。

 マルチキャストモードでは、基点タイムスタンプと受信タイムスタンプは0にし、送信タイムスタンプはメッセージが送信される時刻に設定します。次の表にこれらの動作の概要をまとめておきます。

Field Name Unicast/Anycast Multicast
Request Reply
LI ignore 0 or 3 0 or 3
VN 1-4 copied from request 4
Mode 3 2 or 4 5
Stratum ignore 1 1
Poll ignore copied from request log2 poll interval
Precision ignore -log2 server significant bits -log2 server significant bits
Root Delay ignore 0 0
Root Dispersion ignore 0 0
Reference Identifier ignore source ident source ident
Reference Timestamp ignore time of last radio update time of last radio update
Originate Timestamp ignore copied from transmit timestamp 0
Receive Timestamp ignore time of day 0
Transmit Timestamp (本文参照) time of day time of day
Authenticator optional optional optional

 多くのクライアントには、サーバーが最初に立ち上がった時や、一次基準源が使用できない間に送ってくる無効なタイムスタンプを許す寛容性があります(訳注:そういうタイムスタンプを送っても変な動作はしない、という事か?)。

 もっとも重要なのは、問題を抱えているサーバーはLIを3に設定し、同期していない事を明示する事です。LIが3になっている場合、クライアントは、他の領域の内容に関わらず、サーバーのメッセージを捨てなければなりません。

7. 設定と管理

 SNTPサーバー・クライアントの最初の設定は、ファイルシステムが有効になっていれば、設定ファイルを使用して行う事ができます。ファイルシステムが有効になっていなければ、シリアルポートを使用して行う事もできます。

 NTPとSNTP Version 4サーバーおよびクライアントの運用中の管理は、SNMP(訳注:Simple Network Management Protocol)を使用して実行される事を意図しており、後に発行されたMIB(訳注:Management Information Base)にも適合しています。 通常、SNTPサーバー・クライアントは、IPアドレスとサブネットマスク、あるいはあるいはOSI NSAP(?)アドレスを指定する以外は、サイト定義の設定がほとんど、あるいはまったくない状態で動作する事が期待されます。

 ユニキャストクライアントにはサーバー名あるいはアドレスを指定しなければなりません。もし、サーバー名が使用された場合、アドレスはいくつかのDNSサーバーのうちの一つが指定されていなければなりません(訳注:この部分ちょっと意味不明)。マルチキャストサーバーとエニーキャストクライアントはTTLとローカルブロードキャストもしくはマルチキャストグループアドレスが指定されていなければなりません。

 エニーキャストサーバーとマルチキャストクライアントは、アクセスコントロールのためのアドレスマスクの組み合わせのリストを用いて動作すべきで、これにより、アドレスマスクによって指定されたクライアントとサーバーだけが信頼できるホストとして使用されます。これらのサーバーとクライアントはIGMPプロトコルをインプリメントし、ローカルアドレスあるいはマルチキャストグループアドレスが指定されていなければなりません。暗号化認証のための設定データについては、ここでは割愛します。

 SNTPクライアントが、IPアドレスとサブネットマスク、あるいはOSI NSAPアドレス以外の事前の設定なしに自動的にサーバーを発見・選択する方法がいくつかあります。すべての機能を持ったNTPサーバーを含むIPサブネットあるいはLANセグメントでは、クライアントはローカルブロードキャストアドレスを用いたマルチキャストモードで設定を行う事ができます。マルチキャストグループアドレスを使用しているサーバーでも同じような方法を用いる事ができます。どちらの場合でも、アクセス制御リストを用意する事は、信頼できるホストだけがローカル時計を設定することを保証するためのよい方法です。

 ネットワークの伝達遅延が無視できないような、大きなネットワークでは、他の方法が使用できるでしょう。クライアントは開始時および動作開始後に使用していたユニキャストモードサーバーが返事をしなくなった場合に、エニーキャストモードに設定されます。次に、クライアントは最初に応答を受信できたサーバーを使用し、ユニキャストモードで動作を続けます。このモードでは、伝達遅延を自動的に補償してローカル時計を調整する事ができます。

 さらに別の方法がマルチキャストサービスが使用できないネットワークで使用できるでしょう。DNSにtime.domain.netのような一般的なCNAME(訳注:Canonical Name=サーバーに割り当てられる別名)と、同じドメイン中のNTPサーバー用のアドレスレコードリストを設定しておきます。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