Inter-Client Exchange (ICE) Protocol(日本語試訳)

  様々なプロトコル -- 存在するもの、開発中のもの、仮想のもの -- について話し合う中で、複数のプロトコルに共通する要素が多数存在することが分かった。大抵のプロトコルには認証、版の交渉(version negotiation)、接続設定、接続切断を行うための仕組みが要る。また、交信し合う二者の間で複数のプロトコルを同時に用いなければならないこともある。例えば、二者の間に関係を確立しようとすると、セッション管理機構のプロトコルや、データ転送、入力先の交渉、コマンド通知のプロトコルを同時に運用することが必要になるであろう。これらは論理構造の上では別々のプロトコルであるが、実装にあたっては能う限り多くの部品を共用するのが望ましい。

  信頼に足る、バイトストリーム伝送の接続に基いて、種々のプロトコルを構築する。そのための汎用な枠組みを定めるのが Inter-Client Exchange(ICE)プロトコルである。このプロトコルでは次に挙げる作業のための基礎機構が規定される。接続の設定・切断、認証の実行、使用するプロトコルの版の交渉、エラーの報告である。ICE 接続の中で用いられるプロトコルを、ここでは下位プロトコル(subprotocol)と呼ぶことにする。ICE プロトコルにおいて、各下位プロトコルは自前の版交渉、認証、エラー報告を行うことが可能である。加えて、ICE では、交信する二者が複数の異なる下位プロトコルを用いている場合、そうした下位プロトコル群は同一の伝送層(transport layer)の接続を共同で使用できる。

  交信を行おうとする二者は、ICE 外部の何らかの機構を通じて、互いの存在を知らせ合い、ICE の下位プロトコルの一つを使って通信することを取り決める(訳註:附録 B:ICE X ランデヴ・プロトコル参考)。ICE は、この交渉の内に開始方(originating party)と応答方(answering party)の区別が存在することを前提に作られている。また、この最初の交渉においては、開始方に対して応答方の名前もしくはアドレスが知らされなければならない。交信者双方が互いの存在を知らせ合うために用いる機構には、X セレクション機構、環境変数、共有ファイルなどがある。

  開始方はまず、通信を試みようとする相手との間に、生きた ICE 接続が存在するか否かを調べる。もし有れば、既存の接続を再利用し、直ちに下位プロトコルの設定に進む。既存の ICE 接続が存在しなければ、開始方にて応答方への伝送接続(transport connection)を開き、ICE 接続の設定を始める。

  ICE 接続の設定は主に三つの部分から成る。バイト順(byte order)に関する情報の交換、認証、接続情報の交換の三つである。双方から送り出される最初のメッセージは ByteOrder メッセージであり、これは、このメッセージの送信者が以後の送信メッセージにおいて如何なるバイト順を使用する予定なのかを伝えるものである。次いで、開始方から ConnectionSetup メッセージを送信する。ConnectionSetup メッセージによって、開始方自身の情報(開発者名(vendor name)と版番号(release number))、開始方が対応している ICE の版の番号一覧、並びに開始方が受け付けている認証方式の一覧を通知する。認証は必須ではない。認証不要であれば、応答方が ConnectionReply メッセージを返信して自身の情報を伝えたところで、接続設定は完了する。

  接続設定中に認証を行う場合、応答方は ConnectionReply メッセージではなく AuthenticationRequired メッセージで応じる。その後、認証作業が完了するまで両者は AuthenticationReply メッセージと AuthenticationNextPhase メッセージを交換し合う。最後に応答方から ConnectionReply メッセージを送信することで認証が完了する。

  ICE 接続が確立すると(あるいは既存の接続が再び利用されるようになると)、開始方の ProtocolSetup メッセージの送信を以て、下位プロトコルの交渉が始まる。このメッセージは、両者が使用することに合意した下位プロトコルの名前と、開始方がその下位プロトコルに割り当てた ICE の主たる命令コード(major opcode)とを伝えるものである。接続の認証とは別に、下位プロトコルの認証を行うこともできる。下位プロトコルの認証も必須ではない。下位プロトコルの認証が不要な場合、応答方は ProtocolReply メッセージを返す。このメッセージによって、応答方が先の下位プロトコルに割り当てた ICE 主命令コードを通知する。

  各下位プロトコルの認証は、それぞれ別々に行われる。何故かというと、必要とされる安全基準が各者で異なり得るからである。ある下位プロトコルに対して認証が行われる場合、認証は応答方がこのプロトコルに関する ProtocolReply メッセージを発する前の段階で実施される。その際、接続の認証と同じように、当下位プロトコルに関して AuthenticationRequired、AuthenticationReply、AuthenticationNextPhase メッセージを使用する。下位プロトコルの認証が終わって初めて応答方から ProtocolReply メッセージを送信する。

  下位プロトコルの設定と認証を済ませると、両者はその下位プロトコルで定義されたメッセージを用いて通信できるようになる。どのメッセージにも二つの命令コードが振られている。即ち、主たる命令コード(major opcode、主命令コード)と従たる命令コード(minor opcode、従命令コード)である。両者は ProtocolSetup と ProtocolReply メッセージで決定された主命令コードを用いて各メッセージを送信する。両者が用いる主命令コードは通常、一致しない。一つの下位プロトコルに対して、両者は共に二つの主命令コードを管理する必要がある。メッセージを送信するときに使う主命令コードと、受信するメッセージが保持しているはずの主命令コードである。従命令コードの値と意味は個々の下位プロトコルで定義する。

  各下位プロトコルには、当の下位プロトコルを終了させることを意味するメッセージが一つ以上存在する。終了作業が一方向の通知で完了するのか、交渉を経て実行されるのかはそれぞれの下位プロトコルで定める。下位プロトコルを終了すると、その主命令コードは使えなくなる。命令コードが ProtocolSetup によって再設定されるまで、この下位プロトコルでメッセージを送信するべきではない。

  ICE には、交信中の下位プロトコルが一つもなくなった時に、接続切断の交渉を行う手続きが存在する。どちらか一方において交信中の下位プロトコルが存在しないと判断された時は、この方から WantToClose メッセージを送信することができる。他の一方は、接続の切断に同意する場合、単にそうすれば良い。しかし、この他の一方において、接続を繋いだままにしておきたいと思われた時は、NoClose メッセージを返信してその希望を伝えることも可能である。

  接続の開始方が必ずしも下位プロトコル設定手続きの開始方と同じではないことに注意する。例として A 方が B 方に接続を図る場合を考える。A 方が ConnectionSetup メッセージを発し、B 方が ConnectionReply メッセージで応えたとする。(簡単にするためここでは認証の段階を省く。)一般的には、A 方が ProtocolSetup メッセージをも発し、B 方から ProtocolReply が返されるものである。しかし、一旦接続が確立すれば、どちらの側から下位プロトコルの交渉を始めてもよいことになっている。この例を続けると、B 方にて、A 方と通信するために自分の方から下位プロトコルを設定する必要がある、と判断されることもあり得る。その時は B 方が ProtocolSetup メッセージを発し、A 方からの ProtocolReply を待つことになる。

  ICE メッセージでは様々な型のデータを使用する。バイト順(byte order)は最初の接続メッセージのやり取りで決める。通常、データは送信者のバイト順で送り出されるので、受信者側で適切に並び替える必要がある。64-bit 機に対応するため、ICE メッセージの長さは詰め物をして8バイトの倍数に合わせる。全てのメッセージの中の各欄も自づから16、32、64ビットの境界に揃うようになっている。次の計算式は、E バイトのデータを次の b の倍数の境界に合わせるにあたって、必要とされる詰め物のバイト数を表す。

  同一方向に送受信されるメッセージの全てに、表に出ない通し番号が振られている。この通し番号は 1 から始まり、当該接続の中で一意である(global to the connection)。それぞれのプロトコル毎に独立の通し番号が保持される訳ではない。

  同一の主命令コードを持つメッセージは(即ち同一プロトコルのメッセージは)、受信方によって順番通りに返答されなければならない(返答が必要であれば)。異なるプロトコルに基づくメッセージは任意の順で返答してよい。

  全てのプロトコルの従命令コード 0 はエラーの報告に用いる。要請(request)一つにつき、一つしかエラーを生成できない。相手方からの要請を処理している最中に複数のエラーが発生した場合、どのエラーを返すかは実装次第である。

Error

  このメッセージはエラーを報告するために送信するものであり、どのプロトコルに基づくメッセージに対しても応答として使用できる。プロトコルの主命令コード空間は、いづれも Error メッセージを備えている。全てのプロトコルの従命令コード 0 番がそれである。エラーを起こしたメッセージの従命令コードは、そのメッセージの通し番号とともに、報告される。重症度(severity)は、エラーメッセージの送り手がエラーの同定後、どのように振る舞うのかを表す。CanContinue は、エラーを出した当のプロトコルに基づく更なるメッセージについて、送り手が受け入れるつもりであることを示す。FatalToProcotol は、送り手が、エラーを出した当のプロトコルのメッセージはこれ以上受け付けないけれども、他のプロトコルのメッセージは受け入れられることを示す。FatalToConnection は、送り手が当の接続において、如何なるプロトコルの如何なるメッセージもこれ以上受け付けないことを示す。一般エラーと ICE エラー(主命令コード 0)を発する際、エラー毎に指定できる重症度が決まっているので、送り手はその条件に従う必要がある。一般エラークラスと ICE エラークラスを見よ。class ではエラーが属するクラスを指定する。各プロトコルが種々のクラスを独自に定めるので、プロトコルが異なれば class の数値の意味も変わってくる。エラーの values が存在する場合、その値と型は当該プロトコルの具体的なエラークラスに従って変化する。

  ICE 制御命令コードの一つ一つを以下で説明する。殆どのメッセージには、上で説明したもの以外の付加情報が入っている。付加情報はメッセージヘッダの後ろに加えられ、それを踏まえてメッセージ長が計算される。

  これ以降のメッセージの説明における「Expected errors」とは、平常運転中に起り得るエラーのことである。他のエラー(特に BadMajor、BadMinor、BadState、BadLength、BadValue、ProtocolDuplicate そして MajorOpcodeDuplicate)も起きる可能性はあるが、これらは通常、エラーを発行した当事者側において深刻な実装不備があることを意味している。

ByteOrder

  交信の両当事者は、エラーも含む他の全てのメッセージより先に、このメッセージを送信しなければならない。このメッセージには、本メッセージの送信方が以後のメッセージにおいて使用するバイト順を記す。

ConnectionSetup

  接続の開始方(「connect()」を実行した方)は、このメッセージを第二のメッセージとして送信しなければならない(ByteOrder による立ち上げに次いで)。

  versions 欄には、本メッセージの送信方が使用可能なプロトコルの版番号を、優先度に関して降順に並べる。この文書は主たる版番号 1、従たる版番号 0 である。(訳註:???)

  must-authenticate が True であれば、開始方が認証作業を要求しているということである。受理方は認証方式を決定し、それに基いて認証を実行しなければならない。must-authenticate が True の場合、有効な返答は AuthenticationRequired だけである。

  must-authenticate が False であれば、受理方は認証の方法を選ぶか、ホスト・アドレスに基づく(host-address-based)認証方式を使うか、もしくは認証を省くことができる。must-authenticate が False の時には、ConnectionReply と AuthenticationRequired の二つが返答たり得る。ホスト・アドレスに基づく認証方式を用いる場合、AuthenticationRejected エラーと AuthenticationFailed エラーが起こり得る。

  Authentication-protocol-names には、送り手側で実行したいと考えている認証プロトコルを列挙する(must-authenticate が False のとき、この欄は null(空)でもよい)。must-authenticate が True であれば、送り手は相互認証を許す方式しか提示しないものと考えられる。

  vendor には、使用している ICE 実装の開発者名が入る。

  release には、使用している ICE 実装の版の識別子が入る。

AuthenticationRequired

  このメッセージは ConnectionSetup メッセージと ProtocolSetup メッセージに対する返答として送信される。認証が行われることと、どの認証方式を使用するのかとを伝える。

  認証プロトコルは番号で指定する。この番号は ConnectionSetup や ProtocolSetupで提示されたプロトコル名の配列の要素番号であり、先頭要素の番号は 0 番である。認証プロトコル固有のデータで必要なものも一緒に送信する。

AuthenticationReply

  このメッセージは AuthenticationRequired メッセージと AuthenticationNextPhase メッセージに対する返答として送信される。採用した認証プロトコルに則った認証データを伝達するのが役目である。

  このメッセージを送信するのは現交渉の開始方 — 即ち、ConnectionSetup メッセージもしくは ProtocolSetup メッセージを送信した方であるという点に注意する。

  AuthenticationNextPhase によって、認証を完了するには更なる作業が必要である旨を伝える。認証が完了した時は、当の認証の互礼(authentication handshake)が ConnectionSetup の結果であれば ConnectionReply が、ProtocolSetup の結果であれば ProtocolReply が AuthenticationReply に対する返答となる。

AuthenticationNextPhase

  このメッセージは AuthenticationReply メッセージに対する返答として送信されるものであり、使用中の認証プロトコルに則った認証データを伝える。

ConnectionReply

  このメッセージは ConnectionSetup メッセージもしくは AuthenticationReply メッセージに対する返答として送信されるものであり、認証の互礼(authentication handshake)が完了したことを伝える。

  version-index には版番号の配列の要素番号が入る。この配列は ConnectionSetup メッセージで提示されたもので、先頭要素の番号は 0 番である。この欄を通じて、両者が接続の終了まで遵うことになる ICE プロトコルの版を定める。

  vendor には使用中の ICE 実装の開発者名が入る。

  release には使用中の ICE 実装の版の識別子が入る。

ProtocolSetup

  このメッセージを使って、プロトコルの交渉を開始し、同プロトコル固有の認証方式を相手方に提示する。

  protocol-name には、このメッセージの送信側が使用したいと思っているプロトコルの名前を記す。

  major-opcode には、このメッセージの送信方が自身の送り出すメッセージの中で用いることになる主命令コードを記す。

  versions には、このメッセージの送信側が使用したいと思っている版の番号を、優先度に関して降順に並べる。

  vendor と release には識別子として働く文字列を記す。この識別子文字列の意味は目下交渉中のプロトコルで規定される。

  must-authenticate が True であれば、開始方が認証作業を要求しているということである。受理方は認証方式を決定し、それに基いて認証を実行しなければならない。must-authenticate が True の場合、有効な返答は AuthenticationRequired だけである。

  must-authenticate が False であれば、受理方は認証の方法を選ぶか、ホスト・アドレスに基づく(host-address-based)認証方式を使うか、もしくは認証を省くことができる。must-authenticate が False の時には、ProtocolReply と AuthenticationRequired の二つが返答たり得る。ホスト・アドレスに基づく認証方式を用いる場合、AuthenticationRejected エラーと AuthenticationFailed エラーが起こり得る。

  Authentication-protocol-names には、送り手側で実行したいと考えている認証プロトコルを列挙する(must-authenticate が False のとき、この欄は null(空)でもよい)。must-authenticate が True であれば、送り手は相互認証を許す方式しか提示しないものと考えられる。

ProtocolReply

  このメッセージは ProtocolSetup メッセージもしくは AuthenticationReply メッセージに対する返答として送信されるものであり、認証の互礼(authentication handshake)が完了したことを伝える。

  major-opcode には、このメッセージの送信方が自身の送り出すメッセージの中で用いることになる主命令コードを記す。

  version-index には版番号の配列の要素番号が入る。この配列は ProtocolSetup メッセージで提示されたもので、先頭要素の番号は 0 番である。この欄を通じて、両者が接続の終了まで遵うことになるプロトコルの版を定める。

  vendor と release には識別子として働く文字列を記す。この識別子文字列の意味は目下交渉中のプロトコルで規定される。

Ping

  このメッセージを用いて、接続が今なお機能しているかを検査する。

PingReply

  このメッセージは Ping メッセージに対する返信であり、接続が今なお機能していることを知らせる。

WantToClose

  このメッセージを用いて接続終了作業の端緒を開く。メッセージの送信方においては、各プロトコル固有の手続きによって、運用中のプロトコルが残っていないと判断されている。この要求を受けて四つの展開が考えられる。

  状態遷移表にも関連情報が載っている。

NoClose

  このメッセージは WantToClose メッセージに対する返答として送信されるものであり、返答方にとって現時点での接続の切断が望ましくない旨を伝える。このメッセージの受信方は接続を断つべきではない。後ほど、どちらの側からでも WantToClose に始まる手続きを提起することができる。

  以下は接続開始方の状態遷移表である。

  以下は接続受理方の最上層の状態遷移である。

  以下は、制御用下位プロトコルの始めの接続確立部分に続く、全者共通の最上層状態遷移である。

  以下は接続終了時の状態遷移である。

  下記のメッセージ符号表において、最左列に書いてあるのは使用するバイト数である。二列目に書かれているのは型(値が変化する場合)か、もしくは実際の値である。三列目は値の説明である(変数の名前等)。メッセージの受信者は unused(未使用)あるいは pad(詰め物)と称されたバイト列を無視しなければならない。

  この文書では主たる版番号 1、従たる版番号 0 の ICE プロトコルの符号表を載せている。(訳註:???)

  LISTof<type> は <type> 型のデータを詰め物無しで複数個並べたものを表す。配列された同型データの個数はメッセージ中のどこかに明記しなければならない。

Error
     1     CARD8         major-opcode
     1     0             Error
     2     CARD16        class(エラークラス)
     4     (n+p)/8+1     length
     1     CARD8         offending-minor-opcode
     1                   severity(重症度):
           0               CanContinue
           1               FatalToProtocol
           2               FatalToConnection
     2                   unused
     4     CARD32        sequence number of erroneous message
                                (エラーがあったメッセージの通し番号)
     n     <varies>     value(s)
     p                   pad, p = pad(n,8)

ByteOrder
     1     0     ICE
     1     1     ByteOrder
     1           byte-order:
           0        LSBfirst(最下位バイトが先)
           1        MSBfirst(最上位バイトが先)
     1           unused
     4     0     length

ConnectionSetup
     1     0                   ICE
     1     2                   ConnectionSetup
     1     CARD8               Number of versions offered
                                      (提示された版の数)
     1     CARD8               Number of authentication protocol names offered
                                      (提示された認証プロトコルの名前の数)
     4     (i+j+k+m+p)/8+1     length
     1     BOOL                must-authenticate
     7                         unused
     i     STRING              vendor
     j     STRING              release
     k     LISTofSTRING        authentication-protocol-names
                                        (認証プロトコル名の配列)
     m     LISTofVERSION       version-list
                                          (版の識別名の配列)
     p                         unused, p = pad(i+j+k+m,8)

AuthenticationRequired
     1     0             ICE
     1     3             AuthenticationRequired
     1     CARD8         authentication-protocol-index
                               (認証プロトコル名の配列の要素番号)
     1                   unused
     4     (n+p)/8+1     length
     2     n             length of authentication data
     6          unused
     n     <varies>     data
     p                   unused, p = pad(n,8)

AuthenticationReply
     1     0             ICE
     1     4             AuthenticationReply
     2                   unused
     4     (n+p)/8+1     length
     2     n             length of authentication data
     6                   unused
     n     <varies>     data
     p                   unused, p = pad(n,8)

AuthenticationNextPhase
     1     0             ICE
     1     5             AuthenticationNextPhase
     2                   unused
     4     (n+p)/8+1     length
     2     n             length of authentication data
     6                   unused
     n     <varies>     data
     p                   unused, p = pad(n,8)

ConnectionReply
     1     0             ICE
     1     6             ConnectionReply
     1     CARD8         version-index
                               (版識別名の配列の要素番号)
     1                   unused
     4     (i+j+p)/8     length
     i     STRING        vendor
     j     STRING        release
     p                   unused, p = pad(i+j,8)

ProtocolSetup
     1     0                     ICE
     1     7                     ProtocolSetup
     1     CARD8                 major-opcode
     1     BOOL                  must-authenticate
     4     (i+j+k+m+n+p)/8+1     length
     1     CARD8                 Number of versions offered
                                        (提示された版の数)
     1     CARD8                 Number of authentication protocol names offered
                                        (提示された認証プロトコルの名前の数)
     6                           unused
     i     STRING                protocol-name
     j     STRING                vendor
     k     STRING                release
     m     LISTofSTRING          authentication-protocol-names
                                           (認証プロトコル名の配列)
     n     LISTofVERSION         version-list
                                            (版の識別名の配列)
     p                           unused, p = pad(i+j+k+m+n,8)

ProtocolReply
     1     0             ICE
     1     8             ProtocolReply
     1     CARD8         version-index(版識別名の配列の要素番号)
     1     CARD8         major-opcode
     4     (i+j+p)/8     length
     i     STRING        vendor(意味は下位プロトコルで定義)
     j     STRING        release(意味は下位プロトコルで定義)
     p                   unused, p = pad(i+j, 8)

Ping
     1     0     ICE
     1     9     Ping
     2     0     unused
     4     0     length

PingReply
     1     0     ICE
     1     10    PingReply
     2     0     unused
     4     0     length

WantToClose
     1     0     ICE
     1     11    WantToClose
     2     0     unused
     4     0     length

NoClose
     1     0     ICE
     1     12    NoClose
     2     0     unused
     4     0     length