ToS（Type of Service）

インターネットはそれ自身、特定のアプリケーションあるいはユーザーに関するパスを最適化する直接的な情報を持たないため、IP プロトコルがひとつの特別なパケットに関して、重要であるという重みをかけるかについて、インターネット層にヒントを伝えるための上位層プロトコル用の基盤を与えます。  この基盤は、"Type of Service" 基盤、略して "TOS" 基盤です。

TOS 基盤は、IP データグラムヘッダ内の「Type of Service」オクテットの特徴のひとつです。 「Type of Service」オクテットは、3つのフィールドから成ります。 最初の3ビット(0, 1, 2)は最初のフィールドに"Precedence"とラベル付けされ、データグラムの優先度の重要性を示します。 2番目のフィールドは、"TOS"とラベル付けされ、ネットワークがどのようにスループット、遅延、信頼度およびコスト間のトレードオフを行うかを示します。最後のフィールドは、上部に "MBZ("must be zero"の意) とラベル付けされますが、現在、未使用となっています。 データグラムの発信元は、このフィールドをゼロに設定します(当該ビットを利用するインターネット プロトコル検証に参加しない場合)。  ルーター、およびデータの受信者は、このフィールド値を無視します。このフィールドはフラグメンテーション上にコピーされます。

TOS フィールドの仕様

TOS フィールドの値の書式(バイナリー数として表示)：

              
TOS フィールドで使われている値は、"TOS values"として参照され、IP パケットのTOS フィールドの値は、"requested TOS" として参照されます。  TOS フィールド値 0000 は、"default TOS"として参照されます。 この仕様により、ToS 値は一群のビット数ではなく整数であると再定義されるため、2つのToS値の論理的OR を計算することはもはや重要ではありません。  例えば、要求されたToSが1110 であるパケットに関する、ある低遅延パスを選択することは、ルーターにとっては深刻なエラーになります。それは単に当該ルーターが前の"遅延ビット"が設定されたと述べていることによります。

上記に挙げた5つの他の値の意味は定義されていませんが、これらは完全に正当な TOS 値であり、ホストとルーターは決して、これらの使用を排除してはなりません。 デフォルト TOS だけが特別です。 ホストあるいはルーターはToS値間でいかなる区別もつける必要はありません。

例えば、ToSフィールドを1000(最小遅延)に設定することは、データグラムによって取られるパスにおいて、ユーザーが"遅いと考える遅延"が発生すると保証するわけではありません。  ネットワークはパス遅延に関する、それの(しばしば不完全な)情報に基づいて、利用可能な低遅延パスを選択しようと試みます。  ネットワークはデータグラムを破棄しません。その理由は単にネットワークは利用可能なパスの遅延が"高過ぎる"と信じているためです。利用可能なパスの遅延は、(実際、ネットワーク マネージャーがルーティング メトリクスの創造的な利用を通じてこの振る舞いを乗り込えることができますが、これは次に述べるように強くはお薦めできません。すなわち、ToSフィールドを設定することは、それが利用可能でないときサービスを拒否するよりはむしろ、それが利用可能であるときより良いサービスを提供することを目的としています。)

ルーティングにおけるToSフィールドの利用

ホストとルーターの両方とも、宛先へデータグラムを運ぶ適切なパスを選択するとき、データグラムのToSフィールド値を考える必要があります。本セクションで、そのようにするための機構を議論します。

ひとつのパケットのToS値が実際にある特定のルーティング ドメイン内で採用されるパスに影響を与えるかどうかは、ルーティング ドメインのネットワーク マネージャーによりなされる選択によります。  多くのルーティング ドメインで、パスはデータグラムの中のToSフィールドに基づいてルーターが異なるパスを選択する理由がないという性質において 十分に一様です。 そのようなルーチンドメイン内部では、ネットワークマネージャーは、default (0000) TOS に関するルーターを定義することによってのみ、ルーティングデータベースアップデータとルーティングプロトコルアップデートのサイズを制限する方針を選ぶ可能性があります。

ホストもルーターも、TOS がローカルルーチンドメインでのルーティングに影響を及ぼすかどうかのいかなる明確な知識も持つべきではありません。

固有の制限:

全ての固有な制限の中で最も重要なのは、TOS 基盤が厳密にアドバイザ的機構であるということです。 これは、サービス保証を要求するためには適切な機構ではありません。その理由は2つあります。

• パケットの扱い方、ルーティングの仕方を決定する際、全てのネットワークでToSフィールド値を考えるわけではありません。部分的には、これは転送の問題です。つまり、あるネットワークは、この仕様を先んずる施設を使う際、ある(恐らく長い)期間があります。  長い期間でさえ、多くのネットワークは、ToSフィールド値を考慮することでより良いサービスを提供することはできないでしょう。  例えば、
  内部接続されたLAN の一様な集合から成るネットワークを通過する最良のパスは、 恐らく任意の可能なToS値に関して同一です。  そのようなネットワークの内部では、パケットをフォワードする際にToSフィールド値を考慮する必要のある余分な仕事をするルーターやルーティング プロトコルが必要となるのはあまり意味がないでしょう。
  
• TOS 機構は、アプリケーションに、それが求めるサービスレベルを定量化させるほど十分に強力なわけではありません。 例えば、あるアプリケーションは、ネットワークがスループットを最大にするパスを選択するという要求をするために、TOS フィールドを使う可能性がありますが、それが、1秒当たりの特別なキロバイト数あるいはメガバイト数を必要とする、あるいは希望すると言うために、この機構を使うことはできません。
  ネットワークは、アプリケーションが何を要求するかを知ることはできないので、ネットワークが、利用可能な"高スループット"パスがないという理由で最大スループットを要求したパケットを廃棄することを決定することは適切ではありません。

TCP フラグ

6つのフラグがあります。 - 緊急ポインターフラグ、ACK(=acknowledgement)フラグ、Push フラグ、RST(=reset)フラグ、SYN(=synchronisation)フラグおよび FIN(=finished) フラグ。

緊急ポインターフラグは、'urgent'として、受信データを識別します。 識別されたセグメントは、全ての投入データが処理されるまで待つことなしに、高重要度を割り当てられることで、迅速に処理されます。 ACK フラグは、パケット受信成功を通知するために使うことができます。- 通知は、受信されたパケット毎に行うか、受信されたn番目のパケット毎に行うことができます。 Push フラグは、データに要求される重要度を割り当てるために使うことができ、送信元あるいは宛先で処理されます。 Push フラグを使う場合、正しいデータセグメントハンドリングがなされるという事実に注意を払う必要があります。 また、接続の2つのノードで適切な重要度が設定される必要があります。

現在の接続を対象としていないセグメントが到達したときに、RST フラグを使うことができます。 例えば、リモートシステムがあるホストに対して接続を確立するためにパケットを送ったとすると、そのホストによって当該サービスがサポートされていない場合、そのホストはリクエストを拒否して、接続をリセットすることを示す RST フラグを設定することができます。

 

SYN ホスト 1 ---------------------> ホスト 2                SYN,ACK ホスト 1 <--------------------- ホスト 2                    ACK ホスト 1---------------------＞ ホスト 2    接続が確立されています。

 

 

                

TCP フラグオプション中の5番目のフラグ- SYN フラグは、TCP 通信にて頻繁に使われるフラグです。 - SYN フラグは、上に示したように2つのホスト間の典型的な 3ウェイハンドシェイクを確立する際に、最初に送信されます。ホスト1 は、プロトコルとして TCP を使い、ホスト2 とのコンタクトを確立する必要があります。 3ウェイハンドシェイクの途中では、2つのSYN フラグが送信されます。 接続が設定され、2つのホスト間でデータが送信されると、より多くの SYN フラグが送受信されます。

利用可能な、6番目にして最後のフラグは、FIN フラグであり、接続の間で最後のパケットが交換されるときに現れます。 ホストは、接続を閉じるために FIN フラグを送信する際、リモートホストが接続を閉じるまでデータを受信し続ける可能性があります。 典型的な切断を以下に示します。 TCP は、全2重通信接続なので、データフローの2つの向きがあります。

  

FIN,ACK ホスト 1 ---------------------＞ ホスト 2                  ACK ホスト 1 <-------------------- ホスト 2               FIN,ACK ホスト 1---------------------＞ ホスト 2                  ACK ホスト 1 ---------------------> ホスト 2               データ転送

          

 

         

データ転送が完了した後、ホスト1は、ホスト2に対して設定されたFIN、ACKフラグの付いたパケットを送信します。 このアクションにより、ホスト1 は、前のデータストリームを認識し、同時にこの接続を終了する TCP 終了アクションを初期化しています。 ホスト1 のアプリケーションが、これ以上のデータを受信しなくなると、接続は閉じられます。 ホスト1 の接続終了リクエストに応答してホスト2 も通知を送り返します。これが終わった後、ホスト2 は、接続を終了するために自身のFIN、ACK フラグを送信します。 最後にホスト1 は、以前にホスト2が行ったリクエストを認識し、これで接続が閉じられます。

TCPおよびワーム :

典型的には、ワームは帯域全体を止めてしまうことはありませんが、時々ランダムにシングルホスト接続を開こうとします。  あるものは、TCP フラグおよびICMP トラッキングを使うことができます。 攻撃者が、使われていない宛先IP アドレスに対して、TCP 接続を開こうとする際、TCP のSYN フラグが設定されます。 接続に成功した場合は、累積したTCP フラグの SYNおよびACK があります。接続に失敗した場合は、SYN フラグを持ったフローだけがあります。 当該ネットワークおよび送信元外での各送信元IP アドレスに関する不成功接続数に基づき、攻撃者を追跡することができます - つまり、接続を試みた回数が最も多い対象になります。 攻撃者がUDP プロトコルを使っていて、ネットワーク全体を止めてしまっている場合には、度を越えた数のICMP メッセージが生成されます。