Microsoft Windows Server 2003 TCP/IP 実装詳細

トピック

	はじめに
	機能
	アーキテクチャ モデル
	NDIS インターフェイス
	プロトコル スタックのコア コンポーネントと TDI インターフェイス
	ネットワーク アプリケーション インターフェイス
	重要なクライアント サービスとスタック コンポーネント
	付録 A: TCP/IP 構成パラメータ
	付録 B: NetBIOS over TCP/IP の構成パラメータ
	付録 C: Windows Sockets および DNS のレジストリ パラメータ
	付録 D: 攻撃に対する TCP/IP の応答のチューニング
	付録 E: Daytime Service の応答文字列の書式
	まとめ

はじめに

Microsoft では、各種プラットフォームの戦略的エンタプライズ ネットワーク転送プロトコルとして TCP/IP を採用しています。Microsoft では、1990 年代初めに、Microsoft ネットワークのスケーラビリティを大幅に向上する TCP/IP スタックおよびサービスの作成を目指す意欲的なプロジェクトを開始しました。その結果、MicrosoftR Windows NTR 3.5 (以下 Windows NT 3.5) オペレーティング システムには、完全に新設計の TCP/IP スタックが搭載されることになりました。このスタックは、業界標準の TCP/IP プロトコルを 32 ビットで実装した移植可能な高パフォーマンス スタックです。Windows NT のコード ベースを基盤とする Windows がバージョンを重ねるたびに、このスタックのパフォーマンス、セキュリティ、および信頼性を強化する新しい機能とサービスが追加されてきています。

この TCP/IP スタックは、以下の項目に重点を置いて設計されています。

このホワイト ペーパーでは、Windows Server 2003 の TCP/IP プロトコル スイートについて詳しく解説します。このホワイト ペーパーでは、重要な概念をネットワーク トレースで具体的に示しています。これらのトレースの収集と書式設定には、Microsoft Systems Management Server 製品に含まれているソフトウェア ベースのプロトコル トレースおよび分析用ツールである Microsoft Network Monitor を使用しています。Windows 2000 Server および Windows Server 2003 には、ネットワーク モニタの機能縮小版が付属しています。Systems Management Server 版のネットワーク モニタでは、アダプタをプロミスカス モード (promiscuous mode) で使用するとネットワーク上のすべてのフレームをキャプチャできますが、Windows 2000 Server/Windows Server 2003 版の Network Monitor では、インストール先のコンピュータで通常検出できるフレームのみキャプチャできます。また、リモート ネットワーク モニタ エージェントへの接続もサポートされていません。

ページのトップへ

機能

概要

Windows Server 2003 の TCP/IP は、大規模な企業内ネットワーク、政府機関ネットワーク、パブリック ネットワークに対する Microsoft システムの統合を容易にし、それらのネットワーク上での運用のセキュリティを確保できるように設計されています。Windows Server 2003 の TCP/IP プロトコルは既定の設定でインストールされ、以前のバージョンの Windows とは異なり、アンインストールできません。ただし、netsh interface ip reset コマンドを使うと、TCP/IP 構成を既定の状態に戻すことができます。

標準機能のサポート

Windows Server 2003 の TCP/IP では、以下の標準機能をサポートしています。

パフォーマンスの強化

さらに、Windows Server 2003 の TCP/IP では、パフォーマンスが以下のように強化されています。

利用可能なサービス

Windows Server 2003 オペレーティング システムには、以下の TCP/IP 関連サービスが用意されています。

Windows Server 2003 の TCP/IP の新機能

Windows Server 2003 の TCP/IP には、以下の新機能と改良が加えられています。

下の表は、各オペレーティング システム版の Microsoft TCP/IP にどの機能が実装されているかを参考用に示しています。このドキュメントでは、この後、これらの機能について詳細に説明します。

表 1 Windows TCP/IP の各バージョンの機能比較表

N = なし、Y = あり、D = 既定では無効

Windows Server 2003 の TCP/IP でサポートされているインターネット RFC

RFC (Requests for Comments) は、レポート、プロトコルの提案、インターネット コミュニティによって使用されているプロトコル規格などの一連のドキュメントです。RFC は、http://www.ietf.org/rfc.html から入手できます。

表 2 Windows Server 2003 の TCP/IP でサポートされている RFC

ページのトップへ

アーキテクチャ モデル

概要

Microsoft TCP/IP Suite は、"コア プロトコル要素"、"サービス"、およびそれらの間の "インターフェイス" で構成されます。TDI (Transport Driver Interface) と NDIS (Network Device Interface Specification) は、一般に公開されており、その仕様を Microsoft から入手できます¹。さらに、ユーザー モード アプリケーションで使用できる、より高レベルのインターフェイスもいくつか用意されています。最も多用されるのは、Windows Sockets、リモート プロシージャ コール (RPC)、および NetBIOS の 3 つです。

図 1: Windows Server 2003 の TCP/IP のアーキテクチャモデル

IP パケットの送受信

ソースから IP パケットが送信されると、以下のコンポーネントによって、パケットが順に分析または変更されます。

Windows Server 2003 が稼動しているルーターから IP パケットが転送されると、以下のコンポーネントによって、パケットが順に分析または変更されます。

転送する IP パケットが受信されると、以下のコンポーネントによって、パケットが順に分析または変更されます。

ローカル ホストを宛先とする IP パケットが受信されると、以下のコンポーネントによって、パケットが順に分析または変更されます。

ここでは、Windows Server 2003 に用意されているコンポーネントについてのみ説明しています。Windows Sockets のレイヤ サービス プロバイダや NDIS 中間ミニポート ドライバは含まれていません。

プラグ アンド プレイ

Windows Server 2003 では、プラグ アンド プレイがサポートされています。プラグ アンド プレイには、以下のような機能があります。

プラグ アンド プレイ操作は、プラグ アンド プレイ ハードウェアを必要としません。上記の最初の 2 項目は、プラグ アンド プレイ ハードウェアのほかに、従来型のハードウェアにも可能な限り適用します。検出方法が特別であったり、異常に時間がかかるなどの理由で従来型デバイスをうまく検出できない場合もあります。

プラグ アンド プレイ サポートがプロトコル スタックに及ぼす最も大きな影響は、ネットワーク インターフェイスが任意の時点でロードまたはアンロードされる可能性があるという点です。Windows Server 2003 の TCP/IP および関連コンポーネントは、プラグ アンド プレイに対応しています。

ページのトップへ

NDIS インターフェイス

Microsoft ネットワーク プロトコルでは、ネットワーク カード ドライバとの間の通信に NDIS (Network Device Interface Specification) を使用します。OSI モデル リンク レイヤ機能の多くは、プロトコル スタック内に実装されています。これにより、ネットワーク カード ドライバの開発が大幅に単純化されます。

NDIS (3.1 〜 5.1)

NDIS 3.1 では、プロトコル モジュールが raw パケットをネットワーク デバイス経由で送信できるようにし、ネットワーク デバイスが着信パケットを受信したときに同じモジュールに通知できるようにするための基本的なサービスをサポートしています。

NDIS 4.0 では、NDIS 3.1 に対し、以下の新機能が追加されています。

NDIS 5.0 では、NDIS 4.0 で定義されているすべての機能のほかに、以下の拡張機能が追加されています。

Windows Server 2003 の NDIS 5.1 は、以下のように強化されています。

Windows Server 2003 ファミリには、リモート NDIS も組み込まれています。リモート NDIS では、サードパーティ製ドライバをインストールしなくても、USB 接続のネットワーク デバイスをサポートすることが可能です。ネットワーク デバイスとの通信に必要なドライバは、Microsoft から提供しています。このため、ドライバの設計やテストに不備がある場合に発生しがちなシステム障害の可能性が軽減されており、インストールも容易です。

NDIS 5.1 およびリモート NDIS の詳細については、『Windows Server 2003 DDK』および以下の Web ページを参照してください。

NDIS では、システムから電源レベルの変更が要求されたときにネットワーク アダプタの電源を遮断できます。この要求は、ユーザーが発行する場合とシステムが発行する場合があります。たとえば、ユーザーがコンピュータを明示的にスリープ モードにすることもあれば、キーボードやマウスが一定時間使用されていない場合にシステムが電源レベルの変更を要求することもあります。さらに、ネットワーク インターフェイス カード (NIC) には、ネットワーク ケーブルが切断されたときに電源の遮断要求を発行する機能を持つものがあります。この場合、ケーブルがネットワーク デバイス自体から切断されたのではなく、ネットワーク上の物理的な配線作業の結果として切断が発生する可能性があるため、システムは構成可能な待ち時間が経過した後で電源を遮断します。

NDIS 電源管理のポリシーは、ネットワークの活動状況に基づくものではありません。つまり、NIC の電源を遮断できるのは、すべてのネットワーク コンポーネントが遮断要求を受け付ける場合だけです。ネットワーク上にアクティブなセッションやオープン中のファイルが存在する場合は、コンポーネントが電源遮断要求を拒否する可能性があります。

また、ネットワーク イベントに基づいてコンピュータを低電源状態から解除することも可能です。ウェークアップ信号は、以下のイベントに対して発生させることができます。

ドライバの初期化時、NDIS は、ミニポートの機能を照会して、Magic packet、パターン マッチ、リンク変更ウェークアップなどがサポートされているかどうかを確認し、さらに、各ウェークアップ方法で要求される最も低い電源状態を確認します。この後で、ネットワーク プロトコルがミニポートの機能を照会します。実行時には、プロトコルが "Enable Wakeup"、"Set Packet Pattern"、"Remove Packet Pattern" などのオブジェクト識別子 (OID) を使用してウェークアップのポリシーを設定します。

現時点では、Microsoft のプロトコル スタックのうち、ネットワーク電源管理をサポートしているのは TCP/IP だけです。ミニポートの初期化時には、以下のパケット パターンが登録されます。

NDIS 準拠のドライバは、多数のベンダから、さまざまな NIC で利用できるものが提供されています。NDIS インターフェイスでは、異なる種類の複数のプロトコル ドライバを単一の NIC ドライバにバインドでき、また、単一のプロトコルを複数の NIC ドライバにバインドできます。これを実現するための多重化メカニズムが NDIS 仕様に記述されています。バインドは、[ネットワーク接続] フォルダから詳細設定として表示または変更できます。

Windows Server 2003 の TCP/IP でサポートされているメディアの種類は、以下のとおりです。

リンク レイヤの機能

リンク レイヤ機能は、ネットワーク インターフェイス カードおよびドライバの組み合わせと低レベル プロトコル スタック ドライバの間で分割されます。ネットワーク カードおよびドライバの組み合わせによるフィルタは、各フレームの宛先メディア アクセス制御 (MAC) アドレスに基づきます。

通常、ハードウェアでは、着信フレームのうち、以下の宛先アドレスのいずれかが含まれているフレーム以外のフレームは、フィルタ処理の結果、すべて無視されます。

この最初のフィルタ処理決定はハードウェアによって行われるので、NIC ではフィルタ基準に一致しないフレームがすべて破棄されます。これらのフレームに対しては、CPU での処理が発生しません。ハードウェア フィルタの基準を満たすフレーム (ブロードキャストを含む) は、ハードウェア割り込みを通じて NIC ドライバに渡されます²。NIC ドライバは、コンピュータ上で動作するソフトウェアなので、これらのフレームを処理するために CPU 時間が消費されます。NIC ドライバは、インターフェイス カードからフレームをシステム メモリに取り込みます。その後で、適切なバインド済みトランスポート ドライバにフレームが示されます (渡されます)。このプロセスは、NDIS 5.1 仕様に詳細に記述されています。

フレームは、すべてのバインドされているトランスポート ドライバに対して、バインドの順に渡されます。

パケットが単一または複数のネットワーク内を移動するとき、そのパケットをメディア上に置いた NIC のアドレスが常に発信元 MAC (メディア アクセス制御) アドレスとなり、そのパケットをメディアから取得しようとしている NIC のアドレスが常に宛先 MAC アドレスとなります。このため、ルーティングされたネットワークでは、ネットワーク レイヤ デバイス (ルーターまたはレイヤ 3 スイッチ) を通じてホップを通過するたびに、発信元と宛先の MAC アドレスが変更されます。

Maximum Transmission Unit (MTU)

各種類のメディアでは、フレームが特定の最大フレーム サイズ以内に制限されます。リンク レイヤは、この MTU を発見し、前述のプロトコルに報告する責任を持ちます。プロトコル スタックは、NDIS ドライバにローカル MTU を照会することがあります。インターフェイスの MTU に関する情報は、TCP など、上位レイヤのプロトコルで各メディアのパケット サイズを自動的に最適化するときに使用されます。詳細については、後の「伝送制御プロトコル (TCP)」の「Path Maximum Transmission Unit (PMTU) 探索」を参照してください。

ATM ドライバなどの NIC で LAN エミュレーション モードを使用している場合は、その種類のメディアに対して期待されるよりも高い MTU をドライバが報告することがあります。たとえば、イーサネットをエミュレートしているドライバが MTU を 9180 バイトと報告することがあります。Windows Server 2003 の TCP/IP では、現在のメディアの種類で通常期待される MTU を超過している場合でも、アダプタが報告した MTU サイズをそのまま受け入れて使用します。

現在のメディアの種類で期待されるサイズよりも小さい MTU がプロトコル スタックに報告されることがあります。たとえば、イーサネット上の QoS に 802.1p 標準を使用すると、リンク レイヤ ヘッダーが大きいため、報告される MTU が 4 バイト小さくなることがよくあります。実際にこれが生じるかどうかは、ハードウェアに依存します。

ページのトップへ

プロトコル スタックのコア コンポーネントと TDI インターフェイス

図 1 で NDIS インターフェイスと TDI インターフェイスの間に示されているのがプロトコル スタックのコア コンポーネントです。これらのコンポーネントは、Windows Server 2003 の Tcpip.sys ドライバに実装されています。TCP/IP スタックは、TDI インターフェイスおよび NDIS インターフェイスを通じてアクセスできます。Winsock2 インターフェイスでも、プロトコル スタックへの直接アクセスが可能です。

Address Resolution Protocol (ARP)

ARP は、発信パケットに対して、IP アドレスを MAC アドレスに解決します。それぞれの発信データグラムをフレームにカプセル化するときに、発信元および宛先の MAC アドレスを追加する必要があります。ARP は、各フレームの宛先 MAC アドレスを判別する責任を持ちます。

ARP は、すべての発信 IP データグラム上の次ホップ IP アドレスを、フレームの送信に使用される NIC の ARP キャッシュと比較します。一致するエントリが存在すれば、キャッシュから MAC アドレスを取得します。一致するエントリが存在しなければ、ARP がローカル サブネット上で ARP 要求フレームをブロードキャストし、IP アドレスの所有者が MAC アドレスを示して応答するように要求します。パケットがルーターを通じて送信される場合は、近隣に存在する別のルーターのアドレスが次ホップ アドレスとなり、ARP は、最終的な宛先ホストの MAC アドレスではなく、次ホップ ルーターの MAC アドレスを解決します。ARP 応答が受信されると、ARP キャッシュが新しい情報で更新され、リンク レイヤでのパケット アドレスの指定に使用されます。

ARP キャッシュ

ARP ユーティリティを使うと、ARP キャッシュ内のエントリを表示、追加、または削除できます。例を下に示します。動的なエントリはキャッシュから自動削除されますが、手動で追加したエントリは静的なエントリとなり、キャッシュから自動削除されません。詳細については、後の「ARP キャッシュのエージング」を参照してください。

次の例では、arp コマンドを使って ARP キャッシュを表示しています。

C:\>arp -a 
Interface: 157.60.137.88 --- 0x10003 
  Internet Address      Physical Address      Type 
  157.60.136.1          00-0a-42-b0-54-0a     dynamic 
  157.60.137.0          00-b0-d0-e9-41-43     dynamic 
Interface: 10.0.0.3 --- 0x10004 
  Internet Address      Physical Address      Type 
  10.0.0.1              08-00-2b-c4-25-b6     dynamic

ここでは、複数の NIC を持つマルチホーム コンピュータの場合の例を示しています。インターフェイスごとに ARP キャッシュが 1 つずつ存在します。

次の例では、IP アドレスが 10.0.0.32 で、NIC アドレスが 00-60-8C-0E-6C-6A のホストの 2 番目のインターフェイスの ARP キャッシュに静的なエントリを追加するために arp -s コマンドを使用しています。

C:\>arp -s 10.0.0.32 00-60-8c-0e-6c-6a 10.0.0.3 
C:\>arp -a 
Interface: 157.60.137.88 --- 0x10003 
  Internet Address      Physical Address      Type 
  157.60.136.1          00-0a-42-b0-54-0a     dynamic 
  157.60.137.0          00-b0-d0-e9-41-43     dynamic 
Interface: 10.0.0.3 --- 0x10004 
  Internet Address      Physical Address      Type 
  10.0.0.1              08-00-2b-c4-25-b6     dynamic 
  10.0.0.32             00-60-8c-0e-6c-6a     static

ARP キャッシュのエージング

Windows Server 2003 では、ARP キャッシュのサイズがシステムのニーズに応じて自動調整されます。エントリがどの発信データグラムにも使用されないまま 2 分が経過すると、そのエントリは ARP キャッシュから削除されます。現在参照中のエントリは、10 分後に ARP キャッシュから削除されます。手動で追加したエントリは、キャッシュから自動削除されません。「付録 A」で述べているレジストリ パラメータ ArpCacheLife を使うと、エージングをより詳細に制御できます。

次の例では、arp -d コマンドを使ってキャッシュからエントリを削除しています。

C:\>arp -d 10.0.0.32 
C:\>arp -a 
Interface: 157.60.137.88 --- 0x10003 
  Internet Address      Physical Address      Type 
  157.60.136.1          00-0a-42-b0-54-0a     dynamic 
  157.60.137.0          00-b0-d0-e9-41-43     dynamic 
Interface: 10.0.0.3 --- 0x10004 
  Internet Address      Physical Address      Type 
  10.0.0.1              08-00-2b-c4-25-b6     dynamic

ARP では、指定された宛先アドレスに対して発信 IP データグラムを 1 つだけキューに入れます。この IP アドレスが MAC アドレスに解決されます。ユーザー データグラム プロトコル (UDP) に基づくアプリケーションから単一の宛先アドレスに対して複数の IP データグラムが連続して送信された場合は、既存の ARP キャッシュ エントリがなければ、一部のデータグラムが破棄される可能性があります。アプリケーション側で、パケットのストリームを送信する前に Iphlpapi.dll の SendArp() ルーチンを呼び出して ARP キャッシュ エントリを確立しておくと、この問題を回避できます。IP ヘルパ API の詳細については、「[INFO] IP ヘルパ API による Win32 アプリケーションへのネットワーク構成や統計情報の追加」または MSDN を参照してください。

Internet Protocol (IP)

TCP/IP スタックでは、IP を使用してパケットをソートし、配信を行います。このレイヤでは、それぞれの着信パケットおよび発信パケットを "データグラム" として扱います。各 IP データグラムは、発信元の IP アドレスと宛先の IP アドレスを持ちます。MAC アドレスとは異なり、パケットがインターネットワークを通じて転送されている間、データグラム内に格納されている IP アドレスは変化しません。以降の節では、IP レイヤの機能について説明します。

ルーティング

"ルーティング" は、IP の基本的機能の 1 つです。IP は、上層の UDP および TCP からデータグラムを受け取り、また下層の NIC からもデータグラムを受け取ります。各データグラムには、発信元と宛先の IP アドレスが付加されています。IP は、各データグラムの宛先アドレスを調べ、ローカルに維持されているルート テーブルと比較して、どのように処理するかを決定します。各データグラムは、以下の 3 つの方法のいずれかで処理されます。

ルート テーブルには、4 種類の異なるルートが維持されます。

IP では、以下のプロセスを通じて、IP データグラムの転送に使用する単一のルートを決定します。

コマンド プロンプトからルート テーブルを表示するには、route print コマンドを次のように使用します。

C:\>route print 
IPv4 Route Table 
=========================================================================== 
Interface List 
0x1 ........................... MS TCP Loopback interface 
0x10002 ...00 53 45 00 00 00 ...... WAN (PPP/SLIP) Interface 
0x10003 ...00 04 5a 56 10 06 ...... Linksys LNE100TX Fast Ethernet 
                                    Adapter(LNE100TX v4) 
=========================================================================== 
=========================================================================== 
Active Routes: 
Network Destination        Netmask          Gateway       Interface  Metric 
          0.0.0.0          0.0.0.0     157.60.136.1    157.60.137.88     20 
     157.60.136.0    255.255.252.0    157.60.137.88    157.60.137.88     20 
    157.60.137.88  255.255.255.255        127.0.0.1        127.0.0.1     20 
   157.60.255.255  255.255.255.255    157.60.137.88    157.60.137.88     20 
        127.0.0.0        255.0.0.0        127.0.0.1        127.0.0.1      1 
        224.0.0.0        240.0.0.0    157.60.137.88    157.60.137.88     20 
  255.255.255.255  255.255.255.255    157.60.137.88    157.60.137.88      1 
Default Gateway:      157.60.136.1 
=========================================================================== 
Persistent Routes: 
  None

IPv6 プロトコルがインストールされている場合は、route print コマンドの出力に IPv6 ルートも示されます。

上のルート テーブルの対象となっているコンピュータは、クラス A IP アドレス 157.60.137.88、サブネット マスク 255.255.252.0、およびデフォルト ゲートウェイ 157.60.136.1 を持ちます。このテーブルには、以下のエントリが含まれています。

"Default Gateway" は、現在アクティブになっているデフォルト ゲートウェイを示しています。この情報は、複数のデフォルト ゲートウェイが構成されている場合に役立ちます。

このホストでは、パケットが 157.60.138.49 に送信される場合には、ローカル サブネット ルート (マスク 255.255.255.0 付きのサブネット 157.60.136.0) が一致度の最も高いルートとなります。パケットは、IP アドレス 157.60.137.88 が割り当てられているローカル インターフェイスを経由して送信されます。パケットが 10.200.1.1 に送信される場合には、既定のルートが一致度の最も高いルートとなります。この場合、パケットは 157.60.136.1 のデフォルト ゲートウェイに転送されます。

ルート テーブルは、ほとんどの場合、自動的に維持されます。ホストの初期化時には、ローカル ネットワーク、ループバック、マルチキャスト、および構成済みデフォルト ゲートウェイのエントリが追加されます。IP レイヤが検出したその他のルートがテーブルに追加されている場合もあります。たとえば、ホストのデフォルト ゲートウェイがホストに対して、特定のネットワーク、サブネット、またはホストへのより良いルートを示す場合があります。このとき使用される ICMP プロトコルについては、後で述べます。route コマンドやルーティング プロトコルを使用してルートを手動で追加する場合もあります。route コマンドに「-p」 スイッチを付けると、恒久ルートを指定できます。恒久ルート (固定ルート) は、レジストリの HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters \PersistentRoutes キーに登録されます。

Windows Server 2003 の TCP/IP には、新しい構成オプションとして Automatic metric が用意されており、インターフェイス ベースのルーティング メトリックおよびデフォルト ゲートウェイのルーティング メトリックを構成できます。インターフェイスに対する自動メトリック構成が有効化されている場合は、インターフェイスの速度 (ビット レート) に基づいて、インターフェイス構成に関連付けられているルート (サブネット ルートやホスト ルートなど) のメトリックが決定されます。速度が高いほど、メトリックが小さくなります。たとえば、10 Mbps Ethernet インターフェイスに関連付けられているルートではメトリックが 30 になり、100 Mbps Ethernet インターフェイスに関連付けられているルートではメトリックが 20 になります。デフォルト ゲートウェイに対する自動メトリック構成が有効化されている場合は、インターフェイスに割り当てられている既定ルートのメトリックが決定されます。これも、インターフェイスの速度に基づきます。既定の設定では、インターフェイス メトリックと既定ルートのどちらについても自動メトリック構成が有効化されています。自動メトリック構成を変更するには、[ネットワーク接続] フォルダから、接続の TCP/IP プロトコルの詳細な構成プロパティにアクセスします。

ベース メトリックとデフォルト ゲートウェイのリストを DHCP サーバーから提供することもできます。DHCP サーバーが提供するベース メトリックが 100 で、リストに 3 つのデフォルト ゲートウェイが含まれている場合には、それらのゲートウェイのメトリックは、それぞれ 100、101、および 102 として構成されます。DHCP によって提供されるベース メトリックは、静的に構成されたデフォルト ゲートウェイには適用されません。

Windows ベースのシステムは、既定ではルーターとして動作せず、インターフェイス間で IP データグラムを転送することはありません。Windows Server 2003 には、ルーティングとリモート アクセス サービスが用意されており、このサービスを有効にして構成すると、RIP および OSPF を使用する動的 IP ルーティング サービスを提供できます。Windows XP Professional では、サイレント RIP もサポートされています。

同じ物理ネットワーク上で複数の論理サブネットを稼動させている場合は、次のコマンドを使うと、IP がすべてのサブネットをローカルとして扱ようになります (すべての宛先はローカル リンク上)。

route add 0.0.0.0 MASK 0.0.0.0 < ローカル IP アドレス >

これにより、非ローカル サブネットを宛先とするパケットをルーターに送信せずに、ローカル メディアに直接転送することができます。ローカル インターフェイスをデフォルト ゲートウェイとして指定できます。この機能は、1 つの物理ネットワーク上で複数のクラス C ネットワークを稼動させており、外部へのルーターを使用していない場合や、プロキシ ARP 環境を構築している場合に役立ちます。

重複している IP アドレスの検出

重複している IP アドレスの検出は、重要な機能の 1 つです。スタックを最初に初期化したときや、新しい IP アドレスを追加したときには、無償 ARP 要求がローカル ホストの IP アドレスに対してブロードキャストされます。送信する ARP の数は、「付録 A」で述べているレジストリ パラメータ "ArpRetryCount" (既定値 3) によって制御されます。これらの ARP のいずれかに対してほかのホストが応答する場合は、その IP アドレスが既に使用されていることになります。単一の手動構成されたアドレスを持つインターフェイスであれば、この場合でも Windows ベースのコンピュータは起動しますが、アドレスが競合しているインターフェイスは無効化されます。このとき、システム ログ エントリが生成され、エラー メッセージが表示されます。アドレスを定義しているホストも Windows ベースのコンピュータである場合は、そのコンピュータ上でもシステム ログ エントリが生成され、エラー メッセージが表示されます。ほかのコンピュータの ARP キャッシュを更新できるように、アドレスが競合しているコンピュータからほかの ARP が再ブロードキャストされ、ほかのコンピュータの ARP キャッシュの値が復元されます。

重複する IP アドレスを使用しているコンピュータは、ネットワークに接続されていないときには、そのまま起動でき、競合が検出されることはありません。しかし、そのコンピュータをネットワークに接続した後で、そのコンピュータから最初にほかの IP アドレスに対する ARP 要求を送信した場合、アドレスの競合先のコンピュータで Windows NT コードベースに基づくバージョンの Windows が稼動していれば、競合先のコンピュータで競合が検出されます。競合を検出したコンピュータには、エラー メッセージが表示され、システム ログにイベントの詳細情報が記録されます。競合が検出された場合のイベント ログ エントリのサンプルを次に示します。

The system detected an address conflict for IP address 10.199.40.123 
with the system having network hardware address 00:DD:01:0F:7A:B5. 
Network operations on this system may be disrupted as a result.

DHCP が有効になっているクライアントでは、IP アドレスの競合が検出されたときに DHCP サーバーに DHCPDecline メッセージを送信し、TCP/IP プロトコルを無効化せずに、DHCP サーバーに対して新しいアドレスを要求し、さらに、競合しているアドレスに不正アドレスのマークを付けるように要求します。

マルチホーミング

複数の IP アドレスを持つように構成されたコンピュータは、"マルチホーム" システムと呼ばれます。マルチホームは、以下の 3 通りの方法でサポートされています。

マルチホーム ホストから送信する IP データグラムは、宛先への転送に最も適したインターフェイスに渡されます。したがって、データグラムにマルチホーム ホストのいずれかのインターフェイスの発信元 IP アドレスが格納されていても、別のインターフェイスがそのデータグラムをメディア上に置くことがあります。フレーム上の発信元 MAC アドレスは、そのフレームを実際にメディアに転送したインターフェイスのアドレスですが、発信元 IP アドレスは、送信アプリケーションがそのフレームの送信に使用した IP アドレスです。この IP アドレスは、送信インターフェイスに割り当てられているものとは限りません。

マルチホーム コンピュータの NIC がディスジョイント ネットワーク (プライベート アドレスとインターネットを使用しているプライベート ネットワークのように、互いに独立しており、互いを認識しない複数のネットワーク) に接続されている場合は、ルーティング上の問題が生じることがあります。このような場合は、プライベート ネットワークへの静的なルートを設定することがしばしば必要になります。

2 つのディスジョイント ネットワークに接続するマルチホーム コンピュータを構成するときは、規模が大きく、ルートを限定しにくい方のネットワーク (つまり、ほとんどの宛先が既定ルートに要約されるネットワーク) に接続されているインターフェイスに対してデフォルト ゲートウェイを設定するのが最善の方法になります。そのうえで、静的ルートを追加するか、またはルーティング プロトコルを使用して、規模が小さく、ルートを限定しやすい方のネットワークに対する接続を設定します。各ネットワークに異なるデフォルト ゲートウェイを構成すると、動作上の問題が生じたり、接続が失われる可能性があるので、このような構成は避けてください。

名前の登録、解決、およびマルチホーム コンピュータにおける発信データグラム用の NIC の選択の詳細については、後の「伝送制御プロトコル (TCP)」、「NetBIOS over TCP/IP」、および「Windows Sockets」を参照してください。

クラスレス ドメイン間ルーティング (CIDR)

RFC 1518 および 1519 に記載されている CIDR は、IP アドレスの割り当てと管理のプロセスからアドレス クラスの概念を取り除いたものです。CIDR では、事前定義された既知の境界の代わりに、ネットワーク プレフィックスで定義されたアドレスを割り当てることで、利用可能な名前空間の利用効率を向上します。ネットワーク プレフィックスでは、アドレスのうち、固定する部分を定義します。たとえば、ISP から企業クライアントに対して、10.57.1.128/25 のようなネットワーク プレフィックスが割り当てられます。このプレフィックスでは、最初の 25 ビットが固定されており、最後の 7 ビットはアドレスの割り当てに使用できます。これは、128 アドレスのブロックをローカルに使用できることを意味し、上位 25 ビットがアドレスのネットワーク識別子部になります。従来型のクラスによる割り当て方式では、w.0.0.0/8、w.x.0.0/16、w.x.y.0/24 のようになります。これらが再利用されるときには、クラスレスの CIDR 技法により再割り当てされます。

初期の CIDR は、クラス方式のインストール ベースに対して、クラス C 名前空間の各部を要約するように実装されていました。このプロセスは、"スーパーネット化" と呼ばれます。スーパーネット化を使うと、複数のネットワーク ID を 1 つのプレフィックスに統合できます。たとえば、131.107.4.0、131.107.5.0、131.107.6.0、および 131.107.7.0 の各ネットワーク ID は、ネットワーク ID 131.107.4.0 の中で、サブネット マスク 255.255.252.0 を使って 131.107.4.0/22 に要約することができます。次に例を示します。

NET     131.107.4.0   (1100 0111.1100 0111.0000 0100.0000 0000) 
NET     131.107.5.0   (1100 0111.1100 0111.0000 0101.0000 0000) 
NET     131.107.6.0   (1100 0111.1100 0111.0000 0110.0000 0000) 
NET     131.107.7.0   (1100 0111.1100 0111.0000 0111.0000 0000) 
MASK  255.255.252.0   (1111 1111.1111 1111.1111 1100.0000 0000)

上記の 4 つのネットワーク ID の間では、上位 22 ビットが共通しています。

ルーティングの決定時には、サブネット マスクによってカバーされているビットだけが使用されるので、これらのアドレスはいずれも同じルーティング対象ネットワークの一部とみなされます。この場合、使用中のどのルーターでも CIDR がサポートされている必要があります。特別な構成が必要になることがあります。

Windows Server 2003 の TCP/IP では、RFC 1878 に記載されている 0 および 1 のサブネットをサポートしています。

IP マルチキャスト

IP マルチキャストは、クライアントが同じネットワーク セグメント上に存在していなくても、クライアントに効率的なマルチキャスト サービスを提供できるようにするために使用されます。Windows Sockets アプリケーションをマルチキャスト グループに所属させると、ワイド エリア会議への参加などが可能になります。

Windows Server 2003 の TCP/IP は、RFC 1112 にレベル 2 (送受信) で準拠しています。サブネット上のマルチキャスト メンバシップの追跡には、IGMP プロトコルが使用されます。IGMP については、後で述べます。

IP over ATM

Windows Server 2003 では、IP over ATM をサポートしています。RFC 1577 (およびそれを補足する RFC) では、Classical IP over ATM (CLIP) と呼ばれる IP over ATM ネットワークの基本動作が定義されています。これは、論理 IP サブネット (LIS) を定義するものです。LIS は、互いに直接通信できる IP ホストの集合です。異なる LIS に所属する 2 つのホストは、両方のサブネットのメンバになっている IP ルーターを通じてのみ互いに通信できます。Windows Server 2003 では、ブロードキャスト対応の ATM LANエミュレーション (LANE) もサポートされています。

ATM アドレス解決

ATM ネットワークは非ブロードキャストなので、イーサネットやトークン リングで使われるような ARP ブロードキャストは適しておらず、専用のアドレス解決プロトコル (ARP) サーバーを使用して、IP アドレスから ATM アドレスへの解決を実現します。

論理 IP サブネット (LIS) 内のステーションのいずれか 1 つが ARP サーバーとして指定され、このステーションに ARP サーバー ソフトウェアがロードされます。ARP サーバーのサービスを使用するステーションは、"ARP クライアント" と呼ばれます。LIS 内のすべての IP ステーションが ARP クライアントになります。各 ARP クライアントは、ARP サーバーの ATM アドレスで構成されます。ARP クライアントは、起動時に ARP サーバーへの ATM 接続を確立し、クライアントの IP アドレスと ATM アドレスを格納したパケットをサーバーに送信します。ARP サーバーは、IP アドレスから ATM アドレスへのマッピングのテーブルを構築します。あるクライアントが IP パケットをほかのクライアントに送信するときには、宛先クライアントの ATM アドレスは不明で、IP アドレスだけがわかっています。発信元のクライアントは、ARP サーバーに宛先クライアントの ATM アドレスを照会します。クライアントは、目的の ATM アドレスが含まれている応答を受信すると、ターゲット クライアントとの間に ATM 接続を直接確立し、その接続を通じて IP パケットを送信します。

サーバーへの接続を含め、ATM 接続が非アクティブになると、クライアントは接続をクローズします。すべてのクライアントは、自分の IP アドレスおよび ATM アドレスの最新情報を定期的にサーバーから取得します。この更新は、既定では、15 分おきに行われます。一定時間 (既定では 20 分) が経過しても更新されていないエントリは、サーバーによって削除されます。ATM ARP クライアントと ARP サーバーは、どちらも調整可能なレジストリ パラメータをいくつかサポートしています。詳細については、「付録 A」を参照してください。

Internet Control Message Protocol (ICMP)

ICMP は、RFC 792 で規定されている保守プロトコルです。通常は、IP レイヤの一部とみなされます。ICMP メッセージは、IP データグラム内にカプセル化されるので、インターネットワーク全体にわたってルーティングできます。Windows Server 2003 の TCP/IP では、以下の目的で ICMP を使用します。

ICMP ROUTER DISCOVERY

Windows Server 2003 の TCP/IP では、RFC 1256 で規定されているルーター探索を実行できます。このルーター探索では、ホストが、手動または DHCP で構成されたデフォルト ゲートウェイを使用せずに、自分のサブネット上のルーターを動的に発見できます。プライマリ ルーターに障害が発生したり、ネットワーク管理者がルーターの設定を変更したときには、ホストはバックアップ ルーターに自動的に切り替えることができます。

ルーター探索をサポートしているホストは、初期化時に全システム IP マルチキャスト グループ (224.0.0.1) に参加し、ルーターがそのグループに送信するルーター アドバタイズをリッスンします。また、ホストは、インターフェイスが構成中の遅延を避けるために初期化されたときに、すべてのシステムの IP マルチキャスト アドレス (224.0.0.2) に対してルーター要請メッセージを送信することもできます。Windows Server 2003 の TCP/IP では、約 600 ミリ秒間隔で 3 つまでの要請メッセージが送信されます。

Windows Server 2003 では、ルーター探索の使用をレジストリ パラメータ "PerformRouterDiscovery" および "SolicitationAddressBCast" で制御します。既定では、DHCP によって制御されます。"SolicitationAddressBCast" を 1 に設定すると、RFC 1256 で規定されているマルチキャストではなく、ブロードキャストによってルーター要請が送信されます。

ルート テーブルの維持

Windows ベースのコンピュータの初期化時には、通常、ルート テーブルにはごく少数のエントリだけが格納されます。これらのエントリのうち、1 つはデフォルト ゲートウェイを指定するものです。データグラムの宛先 IP アドレスに適したルートがルート テーブルに含まれていなければ、そのデータグラムはデフォルト ゲートウェイに送信されます。しかし、ルーター間ではネットワーク トポロジに関する情報が共有されているので、特定のアドレスへのより適切なルートをデフォルト ゲートウェイが判断できることがあります。この場合、より適切なパスを与えることのできるデータグラムを受け取ったルーターは、そのデータグラムを通常どおり転送します。そのうえで、"ICMP リダイレクト" メッセージを使用して、より適切なルートを送信元に通知します。これらのメッセージでは、主に、特定の宛先アドレスに対するリダイレクトが指定されます。Windows ベースのコンピュータが ICMP リダイレクトを受信すると、その ICMP リダイレクトが現在のルートの第 1 ホップ ゲートウェイから送信されたものかどうかを確認し、そのゲートウェイが直接接続されたネットワーク上に存在するかどうかを確認するための妥当性チェックが行われます。これらを確認できた場合は、その宛先 IP アドレスに対して、有効期間 10 分のホスト ルートがルート テーブルに追加されます。ICMP リダイレクトが現在のルートの第 1 ホップ ゲートウェイから送信されたものでない場合や、ゲートウェイが直接接続されたネットワーク上に存在していない場合には、ICMP リダイレクトは無視されます。

Path Maximum Transmission Unit (PMTU) 探索

TCP では、Path Maximum Transmission Unit (PMTU) 探索を採用しています。詳細については、後の「伝送制御プロトコル (TCP)」で述べますが、このメカニズムは ICMP の "Destination Unreachable" メッセージに依存しています。

ICMP を使った問題診断

ICMP エコー要求を IP アドレスに送信し、ICMP エコー応答を待機するには、コマンド ライン ユーティリティ "ping" を使用します。ping は、受信した応答の数と、要求を送信してから応答を受信するまでに経過した時間を報告します。ping ユーティリティには、豊富なオプションがあります。

"tracert" は、利用価値の高いルートトレース ユーティリティです。tracert は、ICMP エコー要求を IP アドレスに送信しながら、IP ヘッダー内の Time to Live (TTL) フィールドを 1 から順に増分し、返された ICMP エラーを分析します。引き続き送信される各エコー要求は、TTL フィールドが 0 になり、転送しようとしているルーターが ICMP の Time Exceeded-TTL Exceeded in Transit エラー メッセージを返す前に、ネットワーク内で 1 ホップ先に進む必要があります。tracert は、パス内のルーターのうち、これらのエラー メッセージを返したルーターを順に示すリストを出力します。このリストには、各ルーターの近い側のインターフェイスの名前と IP アドレスが含まれます。各 IP アドレスに対する DNS 逆照会を禁止する -d スイッチを使用すると、IP アドレスだけが報告されます。次に示す例では、ポイントツーポイント プロトコル (PPP) でダイヤルインしたコンピュータからシアトルのインターネット プロバイダを通じて www.whitehouse.gov に至るまでのルートを tracert で調べています。

C:\>tracert www.whitehouse.gov 
Tracing route to www.whitehouse.gov [128.102.252.1] 
over a maximum of 30 hops: 
 1  300 ms  281 ms  280 ms roto.seanet.com [199.181.164.100] 
 2  300 ms  301 ms  310 ms sl-stk-1-S12-T1.sprintlink.net [144.228.192.65] 
 3  300 ms  311 ms  320 ms sl-stk-5-F0/0.sprintlink.net [144.228.40.5] 
 4  380 ms  311 ms  340 ms icm-fix-w-H2/0-T3.icp.net [144.228.10.22] 
 5  310 ms  301 ms  320 ms arc-nas-gw.arc.nasa.gov [192.203.230.3] 
 6  300 ms  321 ms  320 ms n254-ed-cisco7010.arc.nasa.gov [128.102.64.254] 
 7  360 ms  361 ms  371 ms www.whitehouse.gov [128.102.252.1]

pathping は、ping の機能と tracert の機能を組み合わせて、新しい機能をいくつか追加したコマンド ライン ユーティリティです。pathping は、tracert のトレース機能を提供すると共に、設定された時間が経過するまで、ルート上の各ホップを繰り返し ping し、ホップごとの遅延時間とパケット損失を表示します。これらの情報は、パス内に損失の大きいリンクやルーターが存在するかどうかを確認するのに役立ちます。

インターネット プロトコル セキュリティ (IPSec)

Windows Server 2003 では、インターネット プロトコル セキュリティ (IPSec) がサポートされています。IPSec の機能と実装は非常に複雑です。ここでは概要についてのみ述べます。詳細については、一連の RFC やインターネット ドラフトおよびほかの Microsoft ホワイト ペーパーを参照してください。IPSec では、暗号化に基づくセキュリティにより、データ整合性、データ オリジンの認証、再生保護、データの機密性、および制限付きトラフィック フローの機密性を実現しています。IPSec は IP レイヤに用意されているので、IPSec のサービスはスタック内の上位レイヤ プロトコルで利用でき、また既存アプリケーションでも透過的に利用できます。

システムで IPSec を使用すると、セキュリティ プロトコルを選択したり、サービスに使用するアルゴリズムを決定したり、各セキュリティ関係の暗号化キーを確立および維持したりすることができます。IPSec では、ホスト間のパス、セキュリティ ゲートウェイ間のパス、またはホストとセキュリティ ゲートウェイの間のパスを保護することができます。利用可能なサービスのうち、トラフィックに必要なサービスを構成するには、IPSec ポリシーを使います。IPSec ポリシーは、コンピュータ上でローカルに構成できるほか、Active Directory・サービスを使用し、グループ ポリシー メカニズムを通じて割り当てることもできます。Active Directory を使用している場合、ホストが起動時にポリシーの割り当てを検出してポリシーを取得します。その後、ホストは、ポリシーの更新を定期的にチェックします。IPSec ポリシーでは、コンピュータ間の信頼関係を指定します。IPSec では、証明書、Kerberos、仮共有キーのいずれによる認証も可能です。Kerberos に基づく Windows Server 2003 ドメイン信頼関係を使うのが最も簡単です。

IP レイヤで処理される各 IP データグラムは、セキュリティ ポリシーで指定された一連のフィルタと比較されます。セキュリティ ポリシーは、ドメインに所属しているコンピュータに対して管理者が保守します。IP では、データグラムに対して、以下のいずれかの処理を行います。

IPSec ポリシーには、1 つまたは複数のルールが含まれます。各ルールでは、フィルタ、フィルタ処理、認証方法、トンネル設定、および接続の種類を指定します。たとえば、2 つのスタンドアロン コンピュータの間で IPSec を使用するように構成すると、セキュリティで保護されたサーバー ポリシーをアクティブにできます。2 つのコンピュータが同じドメインまたは信頼される側のドメインのメンバになっていない場合は、セキュリティで保護されたサーバーで証明書または仮共有キーを使用し、以下の方法で信頼関係を構成する必要があります。

ポリシーを構成し終えると、フィルタに一致するトラフィックが IPSec のサービスを使用するようになります。IP トラフィック (この場合は、ping のように単純なものも含む) があるホストから別のホストにリダイレクトされると、インターネット キー交換サービス (IKE) を通じて、UDP ポート 500 から短い交信が行われ、セキュリティ アソシエーション (SA) が確立されます。この後、トラフィックのフローが開始します。このように IPSec が有効になった 2 つのホストの間で TCP 接続を設定する場合のネットワーク トレースの例を下に示します。SA の確立後もネットワーク モニタで確認できるのは、IP データグラムのうち、暗号化されていない MAC ヘッダーおよび IP ヘッダーだけです。

Source IP      Dest IP       Prot  Description 
192.168.10.47  10.197.14.91  UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 216 (0xD8) 
10.197.14.91   192.168.10.47 UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 216 (0xD8) 
192.168.10.47  10.197.14.91  UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 128 (0x80) 
10.197.14.91   192.168.10.47 UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 128 (0x80) 
192.168.10.47  10.197.14.91  UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 76 (0x4C) 
10.197.14.91   192.168.10.47 UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 76 (0x4C) 
192.168.10.47  10.197.14.91  UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 212 (0xD4) 
10.197.14.91   192.168.10.47 UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 172 (0xAC) 
192.168.10.47  10.197.14.91  UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 84 (0x54) 
10.197.14.91   192.168.10.47 UDP   Src Port: ISAKMP, (500); Dst Port: ISAKMP 
(500); Length = 92 (0x5C) 
192.168.10.47  10.197.14.91  IP    ID = 0xC906; Proto = 0x32; Len: 96 
10.197.14.91   192.168.10.47 IP    ID = 0xA202; Proto = 0x32; Len: 96 
192.168.10.47  10.197.14.91  IP    ID = 0xCA06; Proto = 0x32; Len: 88

SA の確立後に送信された IP データグラムをオープンしても、そのデータグラムの実際の内容 (TCP SYN や接続要求など) に関する情報はごくわずかしか見ることができません。パケットのうち、明確な部分は、イーサネット ヘッダーと IP ヘッダーだけです。この場合は、TCP ヘッダーさえも暗号化されており、ESP が使用されている場合はネットワーク モニタでも解析できません。

Src IP         Dest IP        Protoc  Description 
=================================================== 
192.168.10.47  10.197.14.91   IP      ID = 0xC906; Proto = 0x32; 
                                      Len: 96 
+ FRAME: Base frame properties 
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet Protocol 
  IP: ID = 0xC906; Proto = 0x32; Len: 96 
      IP: Version = 4 (0x4) 
      IP: Header Length = 20 (0x14) 
      IP: Precedence = Routine 
      IP: Type of Service = Normal Service 
      IP: Total Length = 96 (0x60) 
      IP: Identification = 51462 (0xC906) 
    + IP: Flags Summary = 2 (0x2) 
      IP: Fragment Offset = 0 (0x0) bytes 
      IP: Time to Live = 128 (0x80) 
      IP: Protocol = 0x32 
      IP: Checksum = 0xD55A 
      IP: Source Address = 192.168.10.47 
      IP: Destination Address = 10.197.14.91 
      IP: Data: Number of data bytes remaining = 76 (0x004C)

セキュリティで保護されたサーバー ポリシーを使用すると、IPSec を認識しない宛先や、同じ信頼される側のグループに属していない宛先に対しても、その他の種類のトラフィックの送信がすべて制限されます。Secure Initiator ポリシーには、サーバーに最も適切な設定値が含まれています。トラフィック セキュリティが試行されますが、クライアントが IPSec を認識しない場合は、ネゴシエーションが取り消され、クリア テキスト パケットが送信されます。

データの暗号化に IPSec を使用している場合は、暗号化のオーバーヘッドによりネットワーク全体のパフォーマンスが低下します。このオーバーヘッドの影響を軽減するには、暗号化専用のハードウェア デバイスを用意することができます。NDIS 5.1 では、タスク オフロードがサポートされているので、暗号化ハードウェアを NIC に搭載することは技術的に可能です。IPSec ハードウェア オフロードをサポートする NIC は、多数のベンダから供給されています。

IPSec は、パブリック ネットワーク トラフィックと機密性が要求される企業や政府機関の内部トラフィックのどちらの保護についても、今後の普及が見込まれます。機密情報の保存や提供に使用される特定のサーバーについては、IPSec のセキュリティで保護されたサーバー ("secure server") ポリシーを適用する展開方法が一般的になる可能性もあります。

Internet Group Management Protocol (IGMP)

Windows Server 2003 の TCP/IP には、RFC 1112、2236、および 3376で規定されている IP マルチキャストおよび IGMP Version 1 〜 3 に対するレベル 2 (完全) サポートが組み込まれています。ここでは、IP マルチキャストの要点を把握しやすいように、RFC 1112 の記述を引用して示します。以下のように記述されています。

IP マルチキャスト用の IP/ARP 拡張機能

IP マルチキャストをサポートするために、ホスト上では別のルートが定義されます。このルートは、既定で追加されます。このルートでは、データグラムをマルチキャスト ホスト グループに送信する場合に、データグラムをデフォルト ゲートウェイに転送せずに、ローカル インターフェイス カードを通じてホスト グループの IP アドレスに送信するように指定します。このルートの例を次に示します。なお、このルートを表示するには、"route print" コマンドを使います。

Network Address  Netmask    Gateway Address  Interface     Metric 
224.0.0.0        240.0.0.0  157.60.137.88    157.60.137.88     20

IP マルチキャスト アドレスは、224.0.0.0 〜 239.255.255.255 のクラス D 範囲 (224.0.0.0/4) から得られているので、識別が容易です。これらの IP アドレスは、いずれも上位ビットが 1110 になっています。

ローカル インターフェイスを使ってパケットをホスト グループに送信するには、IP アドレスをメディア アクセス制御アドレスに解決する必要があります。RFC 1112 には、以下の記述があります。

たとえば、マルチキャスト アドレス 225.0.0.5 を宛先とするデータグラムは、(イーサネット) MAC アドレス 01-00-5E-00-00-05 に送信されます。この MAC アドレスは、01-00-5E を 225.0.0.5 の下位 23 ビット (00-00-05) と結合したものです。

複数のホスト グループ アドレスが同じイーサネット マルチキャストにマッピングされる可能性があるので、どのローカル アプリケーションも関与を持たないホスト グループに対するハンドアップ マルチキャストがインターフェイスに示されることがあります。これらの付加的なマルチキャストは、TCP/IP プロトコルによって破棄されます。

Windows Sockets に対するマルチキャスト拡張機能

現時点では、インターネット プロトコル マルチキャストは、タイプが SOCK_DGRAM および SOCK_RAW の AF_INET ソケット上でのみサポートされています。既定では、IP マルチキャスト データグラムは、Time to Live (TTL) 値を 1 に設定した状態で送信されます。アプリケーションから TTL を指定するには、setsockopt() 関数を使用します。一般に、マルチキャスト ルーターでは、データグラムをどこまで転送するかを判断するのに TTL しきい値が使用されます。これらの TTL しきい値は、以下のように定義されています。

Windows コンポーネントによるマルチキャストおよび IGMP の使用

Windows Server 2003 コンポーネントには、IP マルチキャスト トラフィックを使用するものがあります。たとえば、ルーター探索には、既定でマルチキャストが使用されます。WINS サーバーでは、レプリケーション パートナーの検索時にマルチキャストが使用されます。Windows Server 2003 のルーティングとリモート アクセス サービスでは、マルチキャスト転送がサポートされており、インターフェイスの動作モードを IGMP ルーター モードまたは IGMP プロキシ モードに設定することが可能です。

Transmission Control Protocol (TCP)

TCP は、接続に基づいた、信頼性の高いバイト ストリーム サービスをアプリケーションに提供します。Microsoft ネットワークでは、ログオン、ファイルとプリンタの共有、ドメイン コントローラ間での情報のレプリケーション、ブラウズ リストの転送などの一般的な機能に TCP を使用します。ただし、TCP は、1 対 1 の通信にしか使用できません。

TCP では、ネットワーク障害が未検出のままになる可能性を減らすために、各セグメントの TCP ヘッダーとペイロードの両方にチェックサムを使用します。NDIS 5.1 では、タスク オフロードをサポートしています。Windows Server 2003 の TCP/IP では、NIC ドライバ側でチェックサムがサポートされている場合には、NIC に TCP チェックサム計算を処理させることが可能です。スループットが非常に高い環境では、チェックサム計算をハードウェアで実行すると、パフォーマンスが向上します。

さらに、Windows Server 2003 の TCP/IP は、過去数年間にわたって被害が報告されてきたさまざまな攻撃に対抗できるように強化されており、今後の攻撃にも可能な限り対抗できるように Microsoft 社内のセキュリティ レビューを受けてきています。たとえば、初期シーケンス番号アルゴリズムは、ISN がランダムな増分で増加するように変更されています。これには、システム起動時に 2,048 ビットのランダム キーで初期化される RC4 ベースの乱数生成機能が使用されています。

TCP 受信ウィンドウサイズの計算とウィンドウ スケーリング (RFC 1323)

TCP 受信ウィンドウのサイズは、接続上で同時にバッファに格納できる受信データの量 (バイト数) です。送信ホストが受信ホストからの肯定応答とウィンドウ更新を待機する前に送信できるデータは、この量に制限されます。Windows Server 2003 の TCP/IP スタックは、ほとんどの環境でセルフ チューニングが可能なように設計されており、以前のバージョンよりも既定ウィンドウ サイズが大きくなっています。受信ウィンドウのサイズはハードコーディングされておらず、接続のセットアップ中にネゴシエートされた最大セグメント サイズ (MSS) の均等な増分に調整されます。受信ウィンドウを MSS の均等な増分に一致させることで、一括データ転送中にフルサイズ TCP セグメントが使用される割合が高くなっています。

Windows Server 2003 では、アドバタイズした TCP 受信ウィンドウの既定サイズは、以下の要因に依存します。なお、これらの要因は優先度の高い順に示してあります。

10 Mbps および 100 Mbps イーサネットの場合、ウィンドウのサイズは通常、17,520 バイト (17 KB) になります。これは、1,460 バイトのセグメント 12 個分まで切り上げたものです。受信ウィンドウのサイズを特定の値に設定するには、以下の 2 通りの方法があります。

Windows Server 2003 の TCP/IP では、高帯域幅、高遅延のネットワークにおけるパフォーマンスを向上するために、RFC 1323 で規定されているスケーラブル ウィンドウがサポートされています。この RFC には、接続の確立時に TCP がウィンドウ サイズのスケーリング率をネゴシエートできるようにすることで、スケーラブル ウィンドウをサポートする方法が詳細に規定されています。この方法では、実際の受信ウィンドウ サイズを 1 GB まで確保できます。RFC 1323 のセクション 2.2 には、以下の記述があります。

スケーラブル ウィンドウをサポートしている 2 つのコンピュータによって確立された接続のネットワーク トレースを読むときは、TCP ヘッダー内にアドバタイズされているウィンドウ サイズを、ネゴシエートされたスケール率でスケーリングする必要があることに注意してください。次に示すネットワーク モニタ キャプチャでは、接続確立パケット (3 方向ハンドシェイク パケット) にスケール率が含まれています。

***************************************************************** 
Src Addr   Dst Addr  Protocol  Description 
10.0.0.1   10.0.0.9  TCP       ....S., len:0, seq:725163-725163, 
                               ack:0, win:65535, src:1217 dst:139 
+ FRAME: Base frame properties 
+ ETHERNET: ETYPE = 0x0800 : Protocol = IP:  DOD Internet 
                                             Protocol 
+ IP: ID = 0xB908; Proto = TCP; Len: 64 
  TCP: ....S., len:0, seq:725163-725163, ack:0, win:65535, 
               src:1217  dst:139 (NBT Session) 
      TCP: Source Port = 0x04C1 
      TCP: Destination Port = NETBIOS Session Service 
      TCP: Sequence Number = 725163 (0xB10AB) 
      TCP: Acknowledgement Number = 0 (0x0) 
      TCP: Data Offset = 44 (0x2C) 
      TCP: Reserved = 0 (0x0000) 
    + TCP: Flags = 0x02 : ....S. 
      TCP: Window = 65535 (0xFFFF) 
      TCP: Checksum = 0x8565 
      TCP: Urgent Pointer = 0 (0x0) 
      TCP: Options 
        + TCP: Maximum Segment Size Option 
          TCP: Option Nop = 1 (0x1) 
          TCP: Window Scale Option 
              TCP: Option Type = Window Scale 
              TCP: Option Length = 3 (0x3) 
              TCP: Window Scale = 5 (0x5) 
          TCP: Option Nop = 1 (0x1) 
          TCP: Option Nop = 1 (0x1) 
        + TCP: Timestamps Option 
          TCP: Opt