3    ネットワーク機能

この章では,さまざまなネットワーク機能を実現する Tru64 UNIX の構成要素について説明します。 次の各トピックについて説明します。

3.1    インターネット・プロトコル

TCP/IPは,それぞれが異なるサービスを提供する種々のプロトコルをサポートしています。 これらのプロトコルを使用すると,ネットワーク・ハードウェアに依存せずにネットワーク通信を行うことができます。 TCP/IPプロトコル (図 3-1) は,次の 3 つのグループから構成されています。

アプリケーション・プログラムは,ストリームまたはデータ・ブロックの形でメッセージを UDP および TCP の伝送プロトコルに送信します。 これらのプロトコルはアプリケーションからデータを受信し,パケットに分割し,伝送ヘッダを追加し,そのパケットを次のプロトコル層であるインターネット層に伝送します。

インターネット層は,パケットをIPデータグラム内に入れ,データグラム・ヘッダを付与し,データグラムを送信先ホストに直接送るかあるいは他のゲートウエイに送るか決定した後,ネットワーク・インタフェース層にこのデータグラムを渡します。 ネットワーク・インタフェース層は,IPデータグラムを受け取り,ネットワーク上の特定のハードウェアにフレームとして伝送します。

ネットワークが受信したフレームは,プロトコル層を逆方向に通過します。 データがアプリケーション・レベルに戻る間に,個々の層で対応する各ヘッダ情報が取り除かれます。 フレームは,ネットワーク・インタフェース層 (たとえば Ethernet アダプタ) によって受信されます。 ネットワーク・インタフェース層では物理層ヘッダが取り除かれ,データグラムがインターネット層に送信されます。 インターネット層では,インターネット・プロトコルが IP ヘッダを取り除き,パケットをトランスポート層に送信します。 トランスポート層では,TCP ヘッダまたは UDP ヘッダが取り除かれ,アプリケーション層へデータを送信します。

図 3-1:  TCP/IP プロトコル

3.1.1    アプリケーション・レベルのプロトコル

アプリケーションが別のホスト上のアプリケーションにデータを送信する必要がある場合,それらのアプリケーションは,トランスポート層のプロトコルに情報を送信して,情報伝達のための準備を行います。 このようなプロトコルには,DNS,EGP,BGP,RIP,OSPF,FTP,NFS,TELNET,TFTP,FINGER,SMTP,SNMP などがあります。

3.1.1.1    DNS プロトコル

DNS (Domain Name Service) を使用すると,ドメイン内の 1 つまたは複数のホストを,ドメイン内の各ホストに対するネーム・サーバとして動作させることができます。 DNS は UDP または TCP プロトコルの上で動作し,他のドメインから独立してローカル・ネットワーク内でホスト名を割り当てることができます。 DNS で使用するプロトコルとしては UDP の方が適していますが,UDP からの応答が切り捨てられる場合は TCP を使用できます。

DNS についての詳細は,3.5.1 項を参照してください。

3.1.1.2    ルーティング・プロトコル

ルーティング・プロトコルによって,内部および外部の LAN 上のシステム間でルーティング情報を共用することができます。 幾分時代後れになった EGP (外部ゲートウェイ・プロトコル) に加えて,Tru64 UNIX では,BGP (ボーダ・ゲートウェイ・プロトコル) と,RIP (ルーティング情報プロトコル) および OSPF (Open Shortest Path First Protocol) の両方を,NextHop Technologies 社の gated V4.0.6 ルーティング・デーモンの一部として提供します。 gated についての詳細は 3.4.6 項 を参照してください。

外部ゲートウェイ・プロトコル (EGP)

EGP (Exterior Gateway Protocol) は,独立したシステムの外部ゲートウェイが,他の独立したシステム上の外部ゲートウェイとルーティング情報を共有できるようにします。

ここでいう独立したシステムとは,1 人の管理者が責任を負うネットワークおよびゲートウェイからなる 1 つのグループです。 各ゲートウェイが同一の独立システム内にある場合,それらを内部ゲートウェイと呼び,各ゲートウェイが複数の独立システムにまたがって存在する場合,それらを外部ゲートウェイと呼びます。 EGP を使用してルーティング情報を交換するゲートウェイの集合を,EGP ピア (近隣ゲートウェイ) と呼びます。 独立システムの各ゲートウェイは,EGP を使用して EGP ピアにルーティング情報を提供します。

EGP は,次のような方法で外部ゲートウェイがシステム間のリモート通信を提供できるようにします。

EGP は,そのゲートウェイの独立システム内にある,完全にルーティング可能な送信先ネットワークだけを外部ゲートウェイに公示するよう,外部ゲートウェイを制限します。 このため,EGP を使用する外部ゲートウェイはEGPピアに情報を渡しますが,その EGP ピアに関するルーティング情報の公示は行いません。

EGP は,他のプロトコルからのルーティング更新メッセージに含まれる距離メトリックは解釈しません。 EGP は,距離フィールドを使用して,パスが存在するかどうかを指定します。 値が 255 の場合は,ネットワークが到達不可能であることを示します。 2 つのルートが共に単一の独立システム内に含まれていない場合,この値は,2 つのルートのうち短い方を計算するために使用することはできません。 このため,EGP をルーティング・アルゴリズムとして使用することはできません。 したがって,外部ゲートウェイから任意のネットワークへの経路は 1 つだけになります。

EGP ルートは,/etc/gated.conf ファイル内で前もって定義されています。 これは,ルーティング情報プロトコル (RIP) の場合とは対照的です。 RIP は,動的にルートを再構成するインターネット・ネットワークの独立システム内で使用できます。 EGPは,IP を基準プロトコルとして想定しています。 詳細については, gated(8)を参照してください。

ボーダ・ゲートウェイ・プロトコル (BGP)

BGP (Border Gateway Protocol) は,複数のトランジット・オートノーマス・システム間,あるいはトランジット・オートノーマス・システムとスタブ・オートノーマス・システム間でルーティング情報を交換するための外部ルーティング・プロトコルです。 BGP は,EGP よりも多機能,柔軟,かつ少ない帯域幅で動作します。 たとえば,BGP は,各ルートについての情報をより多く提供するためにパス属性を使用し,自由なトポロジによるルーティング・ループを防ぐために,ルートをトラバースした各オートノーマス・システムの AS 番号など,十分な情報を提供するための AS (Autonomous System) パスをメンテナンスします。

EGP と同じように,BGP は内部セッションおよび外部セッションの両方をサポートします。 外部ピアから受け取ったルートがパスの起点でそのピアの AS 番号を持つことを保証するために,外部ピアにルートを送ると,BGP はローカル AS 番号を AS パスの前に付加します。

内部の近隣ピアから受け取ったルートは,通常,AS パスに付加されたローカル AS 番号を持たず,起点となる内部近隣ピアが外部ピアからルートを受け取ったときにそのルートが持つのと同じ AS パスを持ちます。 パスに AS 番号を持たないルートを内部の近隣ピアから受け取ることがあります。 これは,受け取ったルートが 自身の AS の内部ビアであることを示しています。

Tru64 UNIX による BGP の実装では,バージョン 2,3,および 4 という 3 種類のバージョンの BGP プロトコルをサポートしています。 BGP バージョン 2 および 3 は,機能の面で類似しています。 これらのバージョンは,クラス化されたネットワーク経路だけを送信し,その AS パスは AS 番号の単純な配列です。 BGP バージョン 4 は,十分に一般的なアドレスおよびマスクの経路を送信し,その AS パスは,異なる経路を統合した結果を表す,一定の構造を持っています。

ルーティング情報プロトコル RIP

RIP (Routing Information Protocol) は,ディスタンス・ベクトルあるいはローカル・ネットワークのための Bellman-Ford ルーティング・プロトコルのインプリメンテーションで,Tru64 UNIX では,NextHop Technologies 社の gated デーモンで提供しています。 RIP は,ルータをアクティブ・ルータとパッシブ・ルータに分類します。 アクティブ・ルータは他のルータにそれらのルートを公表しますが,パッシブ・ルータはルートの公表は行わず,受け取った公表データを基にそれらのルートを更新します。 典型的には,ルータはアクティブ・モードで RIP を実行し,ホストはパッシブ・モードを使用します。

アクティブ・モードで RIP を実行しているルータは,アップデート情報を規定の間隔でブロードキャストします。 各アップデート情報には,IP ネットワーク・アドレスとネットワークとの距離を表す値で構成された情報が含まれています。 RIP は,デスティネーションとの距離をホップ数で測ります。 ソースからデスティネーションの間のホップ数は,パスに沿ってデータグラムが通過するゲートウェイの数を表します。

たとえば,ルータに直接接続されているネットワークまでのホップ数は 1 です。 別のゲートウェイを介して到達できるネットワークまでのホップ数は 2 です。 2 つのゲートウェイを介して到達できるネットワークまでのホップ数は 3 です。 RIP は,最もホップ数が少ないパスを選択します。

もちろん,ネットワーク間のパスをホップ数で計算すると,常に最適な結果になるとは限りません。 たとえば,3 つの Ethernet 接続部分を通過するホップ数 3 のパスの方が,2 つの低速度シリアル回線を通過するホップ数 2 のパスよりも速い場合があります。 ネットワークとシリアル回線の転送速度の違いを補正するために,管理者は,低速のリンクに対してホップ数の多いパスを公表するようにRIP ルータを構成することができます。

RIPng (Routing Information Protocol for IPv6)

RIPng (Routing Information Protocol for IPv6) は,ルーティング情報プロトコル (RIP) をベースとしています。 RIPng により,IPv6 ベースのネットワークにおける経路の計算のための情報を,ルータ間で交換することができます。 Tru64 UNIX では,RIPng は ip6rtrd デーモンで提供しています。 ip6rtrd デーモンは,アクティブ・モードのみサポートしており,IPv6 ルータの機能を果たしている Tru64 UNIX ノード上でのみ実行されます。 Tru64 UNIX IPv6 ホストは,nd6hostd デーモンを実行します。

OSPF (Open Shortest Path First)

OSPF (Open Shortest Path First) ルーティング・プロトコルは,最短の第 1 パスか,または単一の自律型システムにあるルータ間にルーティング情報を配布するリンク状態内部ゲートウェイ・プロトコルです。 多数のルータがある複雑なネットワークに適するように,OSPF は,単一の宛先に送られるパケットが 2 個以上のネットワーク・インタフェースによって同時に送信できるようにする等価マルチパス・ルーティングを実現します。

リンク状態プロトコルは,すべてのルータのリンク情報に関する公開情報を集めた AS 全体のトポロジを記述したデータベースを各ルータが保守するよう指示します。 各ルータは,そのルータで使用できるインタフェースおよび到達可能な近隣ルータなどのローカル状態情報をAS 全体に配布します。 最低 2 つのルータが接続されている各マルチアクセス・ネットワークは,指定ルータとバックアップ・ルータを持っています。 指定ルータは,リンク状態公開情報をマルチアクセス・ネットワークに流すとともに,その他の特別な責任を持っています。 指定ルータの概念によって,マルチアクセス・ネットワークで必要となる隣接ルータの数を減らせます。

OSPF はネットワークをエリアにグループ化します。 エリア間で受け渡しされるルーティング情報は抽象化され,結果としてルーティング・トラフィックの顕著な低減が望めます。 OSPF は 4 つのタイプのルートを使用します。 4 つのタイプとは,優先する順に示すと次のようになります。

エリア内のパスには,同一のエリア内部の宛先が付いており,エリア間のパスには,外部の AS への宛先が付いています。

OSPF にタイプ 1 としてインポートされるルートは,外部メトリックスが OSPF メトリックスと直接比較できる EGP からのルートであると考えられます。 ルーティングが決定されると,OSPF はAS 境界ルータへの外部コストを外部メトリックに追加します。

タイプ 2 ASE は,メトリックスが OSPF メトリックスと比較できない EGP に対して使用されます。 この場合,AS 境界ルータへの内部 OSPF コストのみがルーティングの決定に使用されます。

各ルータは,ルータ自身をルート (root) とする最短パス・ツリーをトポロジ・データベースから作成します。 この最短パス・ツリーは,AS における各デスティネーションへのルートを規定します。 このツリーの葉として表されるのは,外部から引き出されるルーティング情報です。 リンク状態公開情報のフォーマットは,外部ソースから取得された情報と内部ルータから取得された情報を識別するため,ルートのソースあるいは信頼性にあいまいさは含んでいません。 EGP あるいは BGPなど,外部から取得したルーティング情報は,オートノーマス・システム全体に透過的に渡され,OSPF 内部から得られたデータとは別に保管されます。 オートノーマス・システムの境界上のルータ間で追加情報の受け渡しが可能になるように,各外部ルートには,公開ルータによって標識を付けることができます。

3.1.1.3    ファイル転送プロトコル (FTP)

FTP (File Transfer Protocol) を使用すると,ホスト間でファイルを転送することができます。 FTP は,リモート・ディレクトリの表示,現在のリモート・ディレクトリの変更,リモート・ディレクトリの作成および削除,複数ファイルの転送などの機能を提供します。 FTP は,ユーザおよびアカウント・パスワードを外部ホストへ渡すことによって,転送の際のセキュリティを保証します。 FTP により,ユーザ指向の対話的セッションが可能になります。

FTP は,信頼性の高いストリーム転送 (TCP/IP) を使用してファイルを転送し,TELNET 型接続を使用してコマンドおよびその応答を転送します。 FTP は,ASCII,IMAGE,Local-8 などの,基本的なファイル・フォーマットを認識します。 TCP/IP は,ftp ユーザ・コマンドと ftpd サーバ・コマンドで FTP を実現します。

3.1.1.4    UDP トランスポート上のネットワーク・ファイル・システム・プロトコル

ネットワーク・ファイル・システム (NFS) は,標準の UNIX システム・コールによるファイルへのアクセスを提供します。 NFS を使用することにより,各プログラムがネットワーク経由でファイルにアクセスすることができます。 NFS は UDP トランスポート層を使用するので,データグラムの損失に対する対処が必要になります。 NFS は,適切な時間内に応答がない場合,要求を再転送することによりこの問題に対処します。

この場合,要求によっては問題なくサーバで再実行されますが,たとえばファイル削除要求でその要求に対する応答が損失した場合,要求を再実行するとエラーが発生します。 この場合 2 回目の要求が実行されると,ファイルが存在しないためにサーバはエラーを返します。 NFS サーバは,そのような応答を保持しておき,繰り返し要求がある場合はその応答を再転送します。

このプロトコルは,サーバが他の状態情報を必要としないように設計されています。 また,サーバ・デーモンの複数のコピーを実行することによりサーバの性能を向上させることが可能です。 さらに,クライアントあるいはサーバに特別なコードがなくても,サーバのクラュシュが許容されます。

NFS についての詳細は,4.6 節を参照してください。

3.1.1.5    TCP トランスポート上のネットワーク・ファイル・システム・プロトコル

Tru64 UNIX は,TCP 経由での NFS をサポートします。 LAN においては UDPの方が依然好まれるかもしれませんが,広域エリア,過密エリア,あるいは損失の見られるネットワークにおけるNFS に対しては,TCP の方がよりすぐれた性能が得られます。

UDP コード・パスに対して行われたいくつかの性能の最適化処理を維持するために,別々のスレッドが使用されます。 nfsiod デーモンは,複数のプロセスへ枝分かれする代りにカーネル・スレッドを新しく作成するように変更されています。 各 nfsiod スレッドは,UDP あるいは TCP マウントを処理できるので,nfsiod コマンドには 1 つの引数が指定できます。

NFS についての詳細は,4.6 節 を参照してください。

3.1.1.6    TELNET プロトコル

TELNET プロトコルは,端末デバイスと端末指向プロセスが互いに接続をするための標準的な方法を提供します。 TELNET は,ユーザがリモート・ホストにログインするための端末エミュレーション・プログラムで使用されます。 また,端末間通信やプロセス間通信にも使用することができます。

TCP/IPは,telnet ユーザ・コマンドと telnetd サーバ・コマンドで TELNET を実現します。

3.1.1.7    簡易ファイル転送プロトコル (TFTP)

TFTP (Trivial File Transfer Protocol) を使用すると,外部ホストのファイルに対して読み取り/書き込みを行うができます。 FTP と同様に,TFTP はファイルを8ビットの NETASCII 文字または 8 ビットのバイナリ・データとして転送することができます。 TFTP が FTP と異なる点は,外部ホストでディレクトリの表示および変更ができないこと,および,パスワード保護などのセキュリティのための機能がないことです。 通常は,公用ディレクトリにおけるデータの書き込みおよび検索が可能です。

TCP/IP は,tftp ユーザ・コマンドと tftpd サーバ・コマンドでTFTPを実現します。

3.1.1.8    FINGER プロトコル

FINGER プロトコルは,finger コマンドと fingerd デーモン間のインタフェースを提供するアプリケーション・レベルのインターネット・プロトコルです。 fingerd デーモンは,指定されたリモート・ホストに現在ログインしているユーザの情報を返します。 特定のホストでユーザを指定して finger コマンドを実行すると,そのユーザについての情報を得ることができます。 FINGER プロトコルは,リモート・ホストと要求側ホストの両方に存在している必要があります。 FINGER は,TCP プロトコルを使用します。

3.1.1.9    シンプル・メール転送プロトコル (SMTP)

SMTP (Simple Mail Transfer Protocol) は,インターネットに接続されているマシン間でメールを交換するための標準です。 このプロトコルは,電子メールを交換するために 2 つのホスト間で送信する制御メッセージのフォーマットを指定します。

名前が示すように,SMTP のしくみと用途は単純です。 SMTP は,信頼性の高い効率的なメール転送システムを提供します。 SMTP はメール・インタフェースを指定しません。

3.1.1.10    シンプル・ネットワーク管理プロトコル (SNMP)

SNMP (Simple Network Management Protocol) は,ネットワーク管理情報を交換するための,インターネット標準プロトコルです。 SNMP エージェントは,管理情報ベース (MIB) にアクセスすることによって,ローカルあるいはリモートのネットワーク・マネージャに情報を提供します。 SNMP エージェントの構成,セキュリティ,クラスタ・サポート,およびサポートする RFC については, snmpd(8) を参照してください。

Tru64 UNIX は,業界標準 (IETF RFC) の MIB と HP 独自の MIB の両方をサポートします。 詳細は 3.4.5 項 を参照してください。 HP 独自の MIB 仕様は,/usr/share/sysman/mibs ディレクトリに置かれています。

MIB サポートを提供するデーモンは,/usr/sbin/os_mibs/usr/sbin/srvSystem_mib/usr/sbin/svrMgt_mib/usr/sbin/cpq_mibs,および /usr/sbin/clu_mibs です。

Tru64 UNIX には,SNMP MIB データに Web ベース・インタフェースでアクセスするための HP Insight Manager が含まれています。 HP Insight Manager については 2.6.1 項 を参照してください。

拡張可能 SNMP プログラミング・インタフェースについての詳細は,3.3.6 項 を参照してください。

3.1.1.11    POP3

POP3 (Post Office Protocol) は Qualcomm 社のクライアント/サーバ・プロトコルで,ユーザはこれを使用して電子メールをメール・サーバからリモート・クライアントにダウンロードすることができます。 メッセージがサーバに配信された後,ユーザがサーバに接続して,メッセージをクライアント・マシン (Windows,MacOS,UNIX,あるいはその他のオペレーティング・システムを実行しているデスクトップまたはラップトップ・コンピュータ) にダウンロードします。 それ以降,すべてのメッセージは,クライアント・マシンおよび環境でローカルに処理されます。 これは,ISP (インターネット・サービス・プロバイダ) が今日,顧客に電子メール・サービスを提供するために広く使用しているプロトコルです。 詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。

Tru64 UNIX は,POP3 Version 3.0.2 をサポートしています。 このプロトコルは,RFC 1939 で定義されています。

3.1.1.12    IMAP4

IMAP4 (Internet Message Access Protocol) は,クライアント/サーバ・プロトコルで,カーネギー・メロン大学の Cyrus IMAP4 Revision 1 サーバをベースとしており,メール・クライアントは,これによりサーバ上のメール・メッセージにアクセスすることができます。 IMAP4 を使用して,ユーザはサーバにログインすることなく,自分のメール・フォルダにアクセスし,内容をリモートに操作できます。 クライアントはこのプロトコルを使用して,メール・フォルダの作成,削除,名前の変更,新しいメッセージのチェックと古いメッセージの削除,および選択したメッセージのローカル表示が行えます。 加えて,ユーザはメッセージを属性によって選択したり,RFC 822 および MIME 形式でメッセージを解析したりすることができます。 詳細については,『ネットワーク管理ガイド:サービス編』を参照してください。

Tru64 UNIX は,IMAP4 Version 1.6.24 をサポートします。 このプロトコルは,RFC 2060 で定義されています。

3.1.1.13    RSVP

RSVP (Resource ReSerVation Protocol) は,RFC 2205 で定義されているインターネット・ネットワーク層です。 これは,ネットワーク帯域幅管理コンポーネントの 1 つで,特定のアプリケーション・データ・ストリーム,またはフロー (シンプレックス・ユニキャストまたはマルチキャスト) に対する quality-of-service 要求をネットワーク経由で送受信できるようなメカニズムを提供します。 要求が受け入れられると,特定の量のネットワーク帯域幅がフロー用に確保されます。

ビデオや音声について,省略時のベスト・エフォート配信が受け付けられない場合,アプリケーションは RAPI (RSVP API) を使用して拡張 quality-of-service を要求します。 アプリケーションが要求できる quality-of-service のタイプは,Internet Integrated Services (RFC 1633 および RFC 2210) で定義されています。

Tru64 UNIX における RSVP は,FDDI と Ethernet インタフェース,およびユニキャストとマルチキャストのデータ・フローをサポートします。 詳細については,『ネットワーク・プログラミング・ガイド』 を参照してください。

3.1.2    トランスポート・レベルのプロトコル

TCP/IP のトランスポート・レベルのプロトコル (UDP と TCP) は,アプリケーション・プログラムが他のアプリケーション・プログラムと通信できるようにします。 ユーザ・データグラム・プロトコル (UDP) と伝送制御プロトコル (TCP) は,インターネット・ホスト間の接続を行うトランスポート・レベルの基本的なプロトコルです。 アプリケーションがメッセージをトランスポート層に送信する場合には,UDP と TCP は,メッセージを複数のパケットに分割し,送信先アドレスを含むパケット・ヘッダを付加した後,それらのパケットをネットワーク層に送信します。

UDP を使用してデータグラム接続を行い,TCP を使用してストリーム接続を行うプロトコルやアプリケーションもあります。 UDP と TCP は,ソケット・インタフェースにより実現されます。

3.1.2.1    ユーザ・データグラム・プロトコル (UDP)

UDP (User Datagram Protocol) は,インターネット・ホスト上のアプリケーションと通信するデータグラムを使用します。 UDP は,正の整数で識別されるマシン内の抽象的な送信先を示す送信先プロトコル・ポートを使用して,ホスト上の複数の送信先の 1 つにメッセージを送信します。 プロトコル・ポートは,受信側ホスト上のアプリケーションがメッセージを検索し終わるまで,受信したメッセージをキューに保持します。

UDP は,インターネット・プロトコルによってデータグラムを送信し,IP と同じコネクションレス型のメッセージ送信機能を提供します。 UDP は,データグラム転送や二重化の保護については保証しませんが,メッセージのソース・ポート番号およびデスティネーション・ポート番号を送信者が指定できるようにし,また,データとヘッダ両方のチェックサムを計算します。 これら 2 つの機能によって,アプリケーション間におけるメッセージの正確な送受信が保証されます。

3.1.2.2    伝送制御プロトコル (TCP)

伝送制御プロトコル (TCP) は,インターネット・ホスト間で,信頼性の高いデータ・ストリーム引き渡しを提供します。 UDP と同様に,TCP は基準プロトコルである IP を使用してデータグラムを伝送し,処理ポート間でのデータグラムの連続的なブロック伝送をサポートします。 TCP が UDP と異なる点は,信頼性の高いメッセージ転送を提供することです。 TCP は,損傷,損失,および二重アクセスなしに,送信順に受信プロセスにデータを引き渡すことを保証します。 このように TCP では伝送の信頼性が保証されているため,アプリケーション・プログラム内に通信保護機能を用意する必要はありません。

TCP および UDP は共に,他のホストのアプリケーションとの間でプログラムがメッセージを送受信できるようにします。 また,メッセージの送信先を識別するために,ローカル・ホスト上のプロトコル・ポートを使用します。 TCP 再送タイムアウト値は,往復時間に基づいて,個々の接続ごとに動的に決定されます。

TCP には次のような特徴があります。

3.1.3    インターネット・ネットワーク・レベルのプロトコル

インターネットのネットワーク・レベルのプロトコル (IP,ARP,ICMP) は,コンピュータ間の通信を処理します。 これらのプロトコルによって,転送要求の送受信が行われるとともに,ネットワーク・レベルでの制御が行われます。

3.1.3.1    IPv4

IPv4 (Internet Protocol Version 4) は,ネットワーク・レベルの主要なプロトコルであり,インターネット経由で送信されるデータの形式を定めたものです。 また,IPv4 はパケット処理とエラー処理についても指定しています。

IP は,個々のパケットを独立して扱うコネクションレス型であり,引き渡しあるいはパケットの到着順序を保証しないため信頼性は低くなります。

IP は,ネットワーク・インタフェース・レベルのプロトコルにインタフェースを提供します。 物理的に接続されたネットワークでは,情報はヘッダとデータという形態で転送されます。 IP は,シーケンス情報や制御情報の他に,ソース・ホストのアドレスを含むインターネット・データグラムを使用します。

発信パケットの先頭には IP ヘッダが自動的に付けられますが,より高レベルのプロトコルに送信される前に IP ヘッダは削除されます。 IP は,インターネット・ネットワーク内にあるホストに対して,地球規模でアドレスを指定することができます。

ただし,IP は,送信側ホスト,受信側ホスト,中間ホストからの肯定応答を要求しないため,信頼性の高い通信機能ではありません。

IP パケットの全長は,個々のインタフェースごとに独立して構成することができます。 あるインタフェースにとって大きすぎるパケットは,複数のより小さいパケット (断片) に分割できます。 元のパケットは送信先で断片から再構成されます。

IPv4 マルチキャスティング

Tru64 UNIX は,RFC 1112 に記述されている,LAN における IPv4 マルチキャスティングをサポートします。 また,Tru64 UNIX は,Version 3.5 の IPv4 マルチキャスト・カーネルおよび Version 3.6 の DVMRP (Distance Vector Multicast Routing Protocol) の mrouted インプリメンテーションをサポートしています。

IPv4 ブロードキャスティングとは違い,IPv4 マルチキャスティングの場合,パケットを受け取るように構成されているクライアントによってのみ,パケットをネットワークから取り出すことができます。 パケットはハードウェア・レベルで受け入れたり拒否したりするため,処理のためのオーバヘッドが減少します。 IPv4 マルチキャスティングの場合,アプリケーションが同一データを複数の送信先へ送信するのに別々のパケットを使用する必要がないため,ネットワーク帯域幅をあまり消費しません。 IPv4 マルチキャスティングでは,1 つのパケットですべてのホストへ送信を行います。

このため,IPv4 マルチキャスティングは,ビデオ会議アプリケーションや株式取引相場に関するアプリケーションのように,情報が更新されるたびに最新情報を送信するようなアプリケーションに対して有効です。

IPv4 マルチキャスティングのコードはパブリック・ドメインのものを使用し,すべての Ethernet および FDDI アダプタがサポートされています。

3.1.3.2    IPv6

IPv6 (Internet Protocol Version 6) は,新しいネットワーク・レベル・プロトコルで,インターネット上で送信されるデータの形式を定めたものです。 また,IPv6 はパケット処理とエラー処理の仕様も定めています。

IPv6 は次のようなネットワーク・インタフェースでサポートされています。

Neighbor Discovery

同じリンク上にある IPv6 ノードが Neighbor Discovery を使用すると,お互いの存在を知り,相互のリンク層アドレスを特定し,ルータを探し,さらにアクティブな近隣ノードまでの経路に関する到達可能性情報を保持することができます。

ノード (ホストおよびルータ) は,Neighbor Discovery プロトコルを使用して,接続されているリンク上に存在することがわかっている近隣ノードのリンク層アドレスを特定したり,無効になったキャッシュの値を速やかに消去します。 ホストは,パケットの転送を行う用意のある近隣ルータを探す際にも Neighbor Discovery プロトコルを使用します。 また,ノードは,近隣ノードのうちどれが到達可能でどれが到達不可能かを積極的に把握したり,リンク層アドレスの変更を検出するために,このプロトコルを使用することもあります。

Multicast Listener Discovery

Multicast Listener Discovery (MLD) によって,IPv6 ルータは,自分が直接接続されているリンク上にあるマルチキャスト・リスナ (マルチキャスト・パケットの受信を希望するノード) の存在,およびそれらの近隣ノードが具体的にはどのようなマルチキャスト・アドレスを必要としているかを知ることができます。 その情報が,ルータが使用しているマルチキャスト・ルーティング・プロトコルに提供され,その結果,受信を希望するノードの存在するすべてのリンクにマルチキャスト・パケットが確実に引き渡されます。

ICMPv6

ICMPv6 (Internet Control Message Protocol Version 6) は,IPv6 のすべての実装に必要な構成要素です。 ICMPv6 は,IPv6 のエラー・メッセージおよび制御メッセージを処理します。

ICMPv6 の機能は次のとおりです。

ICMPv6 は,通信環境の問題に関するフィードバックを行いますが,IPv6 の信頼性を高めるものではありません。 つまり,ICMPv6 は,IPv6 パケットが確実に引き渡されることを保証するものではありません。 また,IPv6 パケットが引き渡されなかった場合や正しく引き渡されなかった場合に,ICMPv6 メッセージを送信元のホストに戻すことを保証するものでもありません。

Mobile IPv6

IPv6 は,拡張ヘッダ構造,アドレス自動構成,セキュリティ (IPsec),トンネリングなどの機能によって機動性を確保するように設計されています。 Mobile IPv6 はこれらの機能の上に構築され,IP アドレスの変更を伴わないでモバイル・ノードをあるリンク・ポイントから別のリンク・ポイントへ移動するための操作を定義します。 これにより,モバイル・ノードが別のネットワーク上にあっても,パケットをそのモバイル・ノードに対して送受信することができます。

Mobile IPv6 の実装は Mobility Support in IPv6 をベースにしており,次の機能をサポートします。

Mobile IPv6 の計画,構成,監視については,『ネットワーク管理ガイド:接続編』を参照してください。

IPv6 をサポートするコマンドおよびデーモン

次のコマンドおよびデーモンは,IPv6 と IPV4 の両方の環境で動作するように修正されています。

/sbin/dump /sbin/ifconfig /sbin/init.d/inet /sbin/init.d/route
/sbin/named /sbin/ping /sbin/restore /sbin/route
/usr/bin/finger /usr/bin/ftp /usr/bin/nrdist /usr/bin/rcp
/usr/bin/rdist /usr/bin/rdistd /usr/bin/telnet /usr/sbin/dump
/usr/sbin/ftpd /usr/sbin/ifconfig /usr/sbin/inetd /usr/sbin/named
/usr/sbin/nd6hostd /usr/sbin/netstat /usr/sbin/ping /usr/sbin/pppd
/usr/sbin/rcinet /usr/sbin/rdump /usr/sbin/restore /usr/sbin/rexecd
/usr/sbin/rlogind /usr/sbin/route /usr/sbin/rrestore /usr/sbin/rshd
/usr/sbin/rsvpd /usr/sbin/rwhod /usr/sbin/tcpdump /usr/sbin/telnetd
/usr/sbin/traceroute      

3.1.3.3    IPsec (Internet Protocol Security)

IPsec (Internet Protocol Security) は,IPv4 (Internet Protocol Version 4) および IPv6 (Internet Protocol Version 6) のための,相互運用可能で高品質の暗号に基づくセキュリティを提供するセキュリティ・フレームワークです。

次のようなセキュリティ・サービスを提供します。

これらのサービスは Internet Protocol (IP) 層で提供され,IP およびより上位のプロトコルで保護機能を提供します。

IP をネットワーク層のプロトコルとして使用するほとんどのシステムでは,データグラムは常に他人の目に触れるオープンな形で伝達され受信されます。 プライベートなネットワークであれば,このことは大きな問題にはなりません。 しかし,パブリックなネットワークにおいては,重大なセキュリティ問題になる可能性があります。 アプリケーションによっては,SOCKS,SSL (Secure Socket Layer),Secure HTTP (S-HTTP),Secure Mail (S-MIME) など,独自のセキュリティ機能を提供することによりこの問題を解決するものもあります。 IPsec は,インターネットおよびイントラネットを流れるすべてのデータを保護することが可能です。

この実装では,次のような IPv4 および IPv6 に対する完全な IPsec プロトコルをサポートします。

IPsec の構成と IPsec に関する問題の解決については『ネットワーク管理ガイド:接続編』を参照してください。

3.1.3.4    アドレス解決プロトコル (ARP)

アドレス解決プロトコル (ARP) は,32 ビットの IPv4 アドレスを,Ethernet および FDDI リンクで使用される 48 ビットのハードウェア・アドレスにマップします。 シリアル・ライン・インタフェース・プロトコル (SLIP),Point-to-Point プロトコル (PPP) はハードウェア・アドレスを持たないため,ARP はこれらのプロトコルに対してはアドレス変換を行いません。

ARP は,ローカル・エリア・ネットワーク上で IPv4 アドレスを動的にトレースしてハードウェア・アドレスを見つけます。 このトレースの結果はマップと呼ばれます。 マップされた情報は,マッピング・テーブルに格納されます。 TCP/IP は,ARP を使用してマッピング・テーブルの情報を収集し配布します。

マッピング・テーブル はカーネルによって保守されるため,ユーザやアプリケーションは ARP を直接使用することはできません。 アプリケーションがインターネット・パケットをインタフェース・ドライバの 1 つに送信する場合,送信されたドライバは適切なアドレス・マッピングを要求します。 マッピングがマッピング・テーブルにない場合には,ARP ブロードキャスト・パケットが,要求しているインタフェース・ドライバを通じてローカル・エリア・ネットワーク上の各ホストに送信されます。

ARP をサポートしている任意のホストが ARP 要求パケットを受け取ると,要求側システムの IPv4 およびハードウェア・アドレスを確認し,必要があればマッピング・テーブルを更新します。 受信側ホストの IPv4 アドレスが要求されているアドレスと一致しない場合,このホストは要求されているパケットを無視します。 IPv4 アドレスが一致する場合,受信側ホストは,要求側システムに応答パケットを送信します。 要求側システムは,新しいマッピングを格納し,次の IPv4 パケットの送信に使用します。

多くの他のプロトコルとは異なり,ARPパケットには決まった形式のヘッダはありません。 ARP のメッセージは,さまざまなネットワーク環境で使用できるように設計されています。

3.1.3.5    インターネット制御メッセージ・プロトコル (ICMP)

インターネット制御メッセージ・プロトコル (ICMP) は,すべての IPv4 実装に必要となります。 ICMP は,IPv4 のエラー・メッセージおよび制御メッセージを処理します。

ICMP の機能は,次のとおりです。

ICMP は,通信環境の問題に関するフィードバックを行いますが,IPv4 の信頼性を高めるものではありません。 すなわち,ICMP は,IPv4 パケットを正しく引き渡すことを保証するものではありません。 また,IPv4 パケットが引き渡されなかった場合や正しく引き渡されなかった場合に,ICMP メッセージをソース・ホストに戻すことを保証するものでもありません。

ICMP メッセージは,次のような場合に送信されます。

3.2    ネットワーク・インタフェース層

Tru64 UNIX は,次のネットワークへのインタフェースを提供します。

3.2.1    ATM

Tru64 UNIX は,155.5 Mb/s の ATM (Asynchronous Transfer Mode) ネットワークで PCI マシンをサポートします。 また,622 Mb の ATM ネットワークをサポートするための PCI アダプタもあります。 ATM ネットワークは,従来のパケット・スイッチ・ネットワークとは異なり,音声,映像,データなどの異なる種類のトラフィックを同時に転送できる,コネクション・ベースの,高速度,セル・スイッチ・ネットワークです。 ATM は,閉ざされたレイテンシと専用の帯域幅を必要とするトラフィックに対して予測サービスを提供します。 また,ATM はデータリンク層から物理インタフェースを切り離すため,1 MB/s 〜 10 GB/s の非常に多様な物理インタフェースで 同じセルおよびパケット・フォーマットが使用できます。

Tru64 UNIX の ATM の実装は,パーマネント・バーチャル・サーキット・サポート,ポイント・ツー・ポイント接続のための ATM Forum UNI 3.0 および 3.1 シグナリングを通したスイッチ・バーチャル・サーキット・サポート,動的なネットワーク・アドレス登録のための ATM Forum ILMI (Interim Local Management Interface),クラシカル IP (RFC 1577RFC 1483 および RFC 1626 で定義),および,ATM 経由での LAN エミュレータ (ATM Forum Version 1 標準で定義) で構成されます。 ATM の詳細については,『Asynchronous Transfer Mode』および『ネットワーク管理ガイド:接続編』を参照してください。

3.2.2    Ethernet ネットワーク

Tru64 UNIX は,10 MB/s の Ethernet ネットワークをサポートします。

物理レベルおよび IP レベルにおいて,Tru64 UNIX は,最大 10 MB/s,MTU (最大転送ユニット) 1500 バイトで Ethernet ネットワークをサポートします。

IP レベルでの省略時の MTU は,最大 10 MB/s で 1500 バイトです。 この値は,ifconfig コマンドを使用して減少させることができます。

Ethernet 標準に準拠するよう,Tru64 UNIX は常に最小パケット・サイズ 60 バイトを保証します。

3.2.3    Fast Ethernet ネットワーク

Tru64 UNIX は,100 MB/s の Fast Ethernet (IEEE 802.3 100Base-TX) ネットワークを全二重および半二重でサポートします。

物理レベルおよび IP レベルでの MTU サイズは,通常の 10 MB/s Ethernet の場合と同じです。

3.2.4    Gigabit Ethernet ネットワーク

Tru64 UNIX は,1000 MB/s の Gigabit Ethernet (IEEE 802.3z 1000Base-T) ネットワークをサポートします。 また,同期式/非同期式の Pause Frame Flow 制御 (X-on/X-off),および Jumbo フレーム の互換性をサポートします。

物理レベルおよび IP レベルにおける MTU のサイズは,標準の Ethernet と同じですが,この値は,ifconfig コマンドを使用して変更することができます。

3.2.5    FDDI ネットワーク

Tru64 UNIX は,すべての Alpha ハードウェア・プラットフォームで,RFC 1042RFC 1188 に準拠する 100 MB/s FDDI ネットワークをサポートします。

Tru64 UNIX は,物理レベルにおいて,最大 100MB/s,MTU (最大転送ユニット) 4500 バイトで FDDI ネットワークをサポートします。 IP レベルでは,最大 100MB/s で MTU 4352 バイトです。

IP レベルでの省略時の MTU は,最大 100 MB/秒 で 4352 バイトです。 この値は,ifconfig コマンドを使用して減少させることができます。

3.2.6    トークン・リング・ネットワーク

Tru64 UNIX は,RFC 1042 に準拠した 4 MB/s および 16 MB/s のトークン・リング・ネットワークおよびソース・ルーティングをサポートします。

Tru64 UNIX は,物理レベルにおいて,4 MB/s で MTU (最大転送ユニット) が最大 4472 バイト,16 MB/s で最大 17800 バイトのトークン・リングをサポートします。 IP レベルでは,4 MB/s の MTU が最大 4092 バイト,16 MB/s で最大 8188 バイトです。

IP レベルにおける省略時の MTU は,4 MB/s でも 16 MB/s でも常に 4092 ですが,この値は,ifconfig コマンドを使用して変更することができます。

3.2.7    シリアル・ライン IP (SLIP) および 圧縮シリアル・ライン IP (CSLIP)

Tru64 UNIX はシリアル・ラインに対して IP を完全にサポートしているので,ファイルあるいは NFS マウントしたファイル・システムを電話回線を通して転送することができます。 CSLIP slattach コマンドでヘッダを圧縮して,転送効率を向上できます。

SLIP/CSLIP のコードは,OSF/1 V1.0 のものです。 ただし,OSF/1 は CSLIP の機能にアクセスするための方法を提供していないので,HP は slattach コマンドを修正して,CSLIP ヘアクセスする機能を追加しています。

3.2.8    PPP (Point-to-Point Protocol)

PPP (Point-to-Point protocol) は,シリアル・ポイント・ツー・ポイント・リンクでの データグラム転送の手段を提供します。 SLIP とは違い,PPP は,標準カプセル化機能,異なるネットワーク層プロトコルでの同時多重通信,HDLC フレーム・チェック・シーケンスによるエラー検出,非 8 ビット透過電話機および交換機のための HDLC エスケープ機能,IP アドレスのダイナミック・ネゴシエーション機能をサポートします。

また,SLIP が clist tty ドライバのみをサポートするのに対して,PPP は,LAN 経由のリモート・ログインはもちろん,STREAMS clist と STREAMS ベース tty ドライバの 両方をサポートします。

PPP コードは,パブリック・ドメインのものを使用しており,このページの脚注の著作権情報に示された団体が貢献した内容も含まれています [脚注 1] 。 PPP コードのセクションの一部は,RSA Data Security 社の MD5 Message-Digest Algorithm に基づいています。

Tru64 UNIX は,PPP Version 2.3.1 をサポートします (RFC 1661)。

PPP の詳細については,『ネットワーク管理ガイド:接続編 』, pppd(8)pppstats(8) および chat(8) を参照してください。

3.2.9    多重アダプタのサポート

Tru64 UNIX では,1 つのシステムが同じサブネットに,複数のアクティブなネットワーク・アダプタを持つことができます。 たとえば,IP アドレス 192.24.156.20 で tu0 を構成し,IP アドレス 192.24.156.21 で tu1 を構成して,両方が同じネットマスクを持つといった場合です。

接続確立時には,カーネルは接続数が最小のインタフェースを選択します。 この接続バランシング効果により,サブネットごとにネットワーク・アダプタが 1 つあるシステムよりもスループットが大きくなります。 多重アダプタ・サポートの構成については,『ネットワーク管理ガイド:接続編』を参照してください。

3.2.10    リンク・アグリゲーション

リンク・アグリゲーション (トランキングともいう) を使用すると,管理者は複数の物理 Ethernet ネットワーク・インタフェース・カード (NIC) を結合し,単一の論理リンクを作成することができます (上位層のソフトウェアには,このリンク・アグリゲーション・グループが 1 つの論理インタフェースに見えます)。 この単一の論理リンクによるデータのトラフィックは,インタフェースが 1 つの場合よりも高速です。 これは,リンク・アグリゲーション・グループを構成しているすべての物理ポートにトラフィックが分散されるためです。

リンク・アグリゲーションを使用すると,次の機能を利用できます。

リンク・アグリゲーション・グループ仮想インタフェースは,サーバ間およびサーバとスイッチ間のポイント・ツー・ポイント接続に使用できます。

リンク・アグリゲーションの構成については,『ネットワーク管理ガイド:接続編 』, lag(7),および lagconfig(8) を参照してください。

3.2.11    NetRAIN

NetRAIN (Redundant Array of Independent Network adapters) は,ネットワーク接続の物理的損失を検出すると,動作状態にあるネットワーク・インタフェースにネットワーク・トラフィックを自動的に切り換えます。

NetRAIN 仮想インタフェースは,同じ LAN セグメント上の複数のインタフェースを 1 つのインタフェースとして構成します。 物理インタフェースのうち,常に 1 つがアクティブで,その他はアイドル状態です。 アイドル状態のインタフェースも含め,すべてのインタフェースが絶えず監視され,それぞれのインタフェース上をトラフィックが流れることが保証されます。

アクティブ・インタフェースがネットワーク接続に失敗した場合,またはネットワーク接続を失った場合,NetRAIN はネットワーク・トラフィックを次に利用可能な動作中のインタフェースに切り換えます。 前に使用したインタフェースのコンテキスト (たとえば,ハードウェア・アドレスやマルチキャスト・アドレス) はすべて維持されます。 実際のフェールオーバ時間は,ネットワーク構成と運用に応じて調整可能です。

Tru64 UNIX は,Ethernet,FDDI,および ATM のコントローラをサポートします。

NetRAIN 構成についての詳細は,『ネットワーク管理ガイド 』, nr(7) および ifconfig(8) リファレンス・ページを参照してください。

3.2.12    仮想ローカル・エリア・ネットワーク

仮想ローカル・エリア・ネットワーク (VLAN) は,物理ネットワーク上に複数の論理的なネットワークを構築するための機能です。 VLAN は,タグ・フレームと呼ばれる特別な Ethernet フレームに含まれる VLAN ID によって認識されます。 このタグ付きのフォーマットは,IEEE 802.1q 標準で定義されています。

各 VLAN は,それぞれが物理的に別のネットワークであるかのように機能します。 ブロードキャスト・トラフィックを含め,特定の VLAN で発生したすべてのトラフィックは,その VLAN 内の他のリンクのみへ転送されます。 詳細は,Version 5.1B の『リリース・ノート』, vlan(7) および vlanconfig(8) リファレンス・ページを参照してください。

3.3    アプリケーション・プログラミング・インタフェース

ネットワーク・プログラミング環境には,アプリケーション,カーネル,およびドライバの開発者が,ネットワーク・アプリケーションを作成したり,ネットワーク・プロトコルを実装するための,プログラミング・インタフェースが含まれます。 さらに,アプリケーションがデータの処理および伝送に必要とする,カーネル・レベルのリソースも含まれます。 これには,ライブラリ,データ構造体,ヘッダ・ファイル,トランスポート・プロトコルなどがあります。

次のセクションでは,サポートされているアプリケーションのプログラミング・インタフェースについて,簡単に説明しています。

これらのネットワーク・プログラミング環境についての詳細は,『ネットワーク・プログラミング・ガイド』 を参照してください。

3.3.1    X/Open トランスポート・インタフェース (XTI)

X/Open トランスポート・インタフェース (XTI) は,トランスポート・プロバイダに依存しない,トランスポート層アプリケーション・インタフェースを定義します。 つまり,XTI に合わせて作成されたアプリケーションは,伝送制御プロトコル (TCP) やユーザ・データグラム・プロトコル (UDP) などの,さまざまなトランスポート・プロバイダで実行できます。 どのトランスポート・プロバイダを使用するかはアプリケーションが指定します。

図 3-2 は,XTI と,STREAMS フレームワークおよびソケット・フレームワークとのやりとりを示しています。

図 3-2:  XTI,STREAMS,およびソケット間の相互関係

アプリケーションによって指定されたトランスポート・プロバイダに応じて,次のいずれかのパスをデータが流れます。

3.3.2    ソケット

ソケットは,業界標準プログラミング・インタフェースです。 Tru64 UNIX では,ソケットは,TCP,UDP,IP,ARP,ICMP,SLIP などのインターネット・プロトコルへのインタフェースです。 Tru64 UNIX は,4.3BSD (省略時の設定),4.4BSD,XNS5.0,XNS4.0,および POSIX 1003.1g Draft 6.6 インタフェースをサポートします。

ソケット・フレームワークは,一連のシステム・コール,ライブラリ・コール,ヘッダ・ファイル,およびデータ構造体で構成されています。 アプリケーションは,ソケット・システム・コールを通じて,ネットワーク・プロトコルにアクセスできます。 また,ソケット・ライブラリ・コールを使用して,ネットワーク情報を操作することもできます。 たとえば,getservent ライブラリ・コールはサービス名をサービス番号にマップし,htonl ライブラリ・コールは着信データのバイト順をローカル・システムのアーキテクチャに適したものに変換します。

ソケットの場合,ユーザ空間のアプリケーションは,適切なソケット・システム・コールにデータを引き渡し,次に,ソケット・システム・コールが,そのデータをネットワーク層に引き渡します。 最後に,ネットワーク層が ifnet層を通して,BSDドライバにデータを引き渡します。 BSDドライバはネットワークとのデータのやりとりを行います。

ソケットについての詳細は,『ネットワーク・プログラミング・ガイド』,『X/Open CAE Specification, Networking Services (XNS), Issue 5』,『X/Open CAE Specification, Networking Services, Issue 4 (XNS4.0); Protocol Independent Interfaces (POSIX 1003.1g Draft 6.6, Section 5)』および netintro(7) リファレンス・ページを参照してください。

3.3.3    STREAMS

STREAMS フレームワークはソケットの代替機能を提供します。 この STREAMS インタフェースは,ネットワーク・プロトコルからデバイス・ドライバまであらゆるものを実装するのに使用される,システム・コール,カーネル・ルーチン,およびカーネル・ユーティリティから構成されています。 ユーザ空間のアプリケーションは,opencloseputmsggetmsg,および ioctlなどのシステム・コールを使用して,STREAMS フレームワークのカーネル部分に アクセスします。

Tru64 UNIX は,OSF/1 V1.2 からのコードをベースに System V Release 4.0 STREAMS をサポートしており,STREAMS tty インタフェースのサポートを提供しています ( Tru64 UNIX は,CLIST あるいは Berkeley ベースの tty インタフェースも引き続きサポートします)。 STREAMS についての詳細は,『ネットワーク・プログラミング・ガイド』を参照してください。

3.3.4    ソケットと STREAMS の相互作用

Tru64 UNIXでは,BSD ベースの TCP/IP を使用するプログラムが STREAMS ベースのドライバにアクセスできるよう,ifnet STREAMSモジュールを提供します。 このモジュールにより,STREAMS ベースのプロトコル・スタックを使用するプログラムが BSD ベースのドライバにアクセスできるように,Data Link Bridge (DLB) 擬似ドライバが提供されます。

3.3.5    データ・リンク・プロバイダ・インタフェース (DLPI)

DLPIは,OSI 参照モデルのデータ・リンク層にマップするカーネル・レベルのインタフェースです。 DLPIを使用すると,ユーザは データ・リンク・プロバイダの特性について特別な知識を持つ必要が なくなるため,特定の通信媒体に依存することなくこれらの特性を実現できます。 DLPI は,データ・リンク・サービスを使用あるいは提供する STREAMS モジュールを主なターゲットとしている カーネル・レベルのインタフェースです。

Tru64 UNIX では,DLPI インタフェースの一部分のみがサポートされます。 詳細については,『ネットワーク・プログラミング・ガイド』を参照してください。

3.3.6    拡張可能 SNMP インタフェース (eSNMP)

Tru64 UNIX は,Tru64 UNIX ホスト・システム上で ユーザ作成のプログラムを分散 SNMP エージェントとして機能させることができるアプリケーション層API である eSNMP (extensible SNMP)をサポートします。

ユーザ・プログラム (サブエージェント) は,SNMP MIB オブジェクトを eSNMP マスタ・エージェント /usr/sbin/snmpd に動的に登録することができ,これによって,これらのオブジェクトに対する SNMP プロトコル操作を処理することができます。

協調関係にあるプロセス間での MIB オブケクトの分散は,SNMP アプリケーション対して透過的です。 アプリケーションは,SNMP RFC で指定されている標準トランスポート・ エンドポイントを使用して,すべての MIB オブジェクトにアクセスできます。 eSNMP API (libesnmp.so) は,snmpd との通信に RFC 2741 (AgentX) を使用します。 下位互換性を維持するためのこの変更により,サブエージェントが RFC 2741 に準拠した SNMP エージェントとやりとりすることが可能になっています。

eSNMP 開発ツールは,オプションのプログラミング・サブセット (PMR) に含まれています。 詳細については,『ネットワーク・プログラミング・ガイド』を参照してください。

3.4    ネットワーク管理ソフトウェア

Tru64 UNIX では,さまざまなネットワーク管理ソフトウェアをサポートします。 以降の各項で,これらのソフトウェアについて説明します。

3.4.1    ネットワーク・コマンドおよびユーティリティ

Tru64 UNIX は,OSF/1 V1.2 に含まれている fingerftprdumprdistroutedgatedtelnettftp などのネットワーク・コマンドをサポートしています。 bootpd 機能が,joind デーモンに組み込まれおり,DHCP あるいは BOOTP プロトコルを使用してクライアントを構成することができます。

また,Tru64 UNIX は,inetd デーモンによって起動される次に示す ONC (Open Network Computing) Version4.2 の ユーティリティ・プログラムをサポートします。

3.4.2    Ethernet パケット・フィルタおよびパケット・フィルタ・アプリケーション

Ethernet パケット・フィルタは,ユーザ定義のネットワーク・プロトコルを含むパケットの受信および送信機能とともに,ネットワーク・パケット・ヘッダのデマルチプレクサ機能を提供するソフトウェア・ドライバ・インタフェースです。 フィルタ固有のネットワーク・プロトコルに対して使用する場合,このパケット・フィルタは Ethernet モニタとしても機能します。

注意

Ethernet パケット・フィルタはオプションのカーネル・サブシステムですので,実行中のカーネルにパケット・フィルタが構成されていない場合は,パケット・フィルタ・カーネル・ルーチンの呼び出しを行うアプリケーション・プログラムは正しく動作しません。 詳細については, packetfilter(7)を参照してください。

Tru64 UNIX は,次のパケット・フィルタ・アプリケーションをサポートします。

3.4.3    DHCP

Tru64 UNIX は,DHCP サーバが IP アドレスをクライアントに割り当てるためのクライアント/サーバ・フレームワークである JOIN Systems 社の JOIN Server Version 4.1 をベースにした DHCP (Dynamic Host Configuration Protocol) をサポートします。 DHCP サーバは,BIND サーバの名前あるいは省略時のルータなどの構成情報をクライアントに提供します。

新しいシステムを初めてブートすると,DHCP サーバがユニークな IP アドレスをシステムに割り当てます。 たとえば,そのシステムを同一 LAN 上の別の場所 (異なるサブネット) に移動した場合,DHCP サーバは,そのサブネットに合った新しい IP アドレスを,必要に応じて最初のブート時に,システムに割り当てます。

このように,DHCP (図 3-3) を使用すると IPアドレスの割り当てに関して頭を悩ます必要がなくなります。 DHCP は IP アドレスを自動的に割り当てるため,システム管理者の介入が不要になります。

図 3-3:  DHCP 構成

DHCP の詳細については,『ネットワーク管理ガイド:接続編』および dhcp(7)を参照してください。

3.4.4    インターネット・ブート・プロトコル・デーモン (bootpd)

インターネット・ブート・プロトコル・デーモン bootpd は,RFC 951RFC 1542 および RFC 2132 で定義されているように インターネット・ブート・プロトコル (BOOTP) サーバをインプリメントします。

BOOTP は拡張可能な UDP/IP ベースのプロトコルで,ユーザの介入なしで,ブート・ホストが自分自身を動的に構成することを可能にします。 BOOTP プロトコルは,IP アドレスをホストに割り当て,サーバからダウンロード可能なブート・プログラムを含むファイルを利用可能にし,そのサーバのアドレスを提供し,さらに存在する場合はインターネット・ゲートウェイのアドレスを提供します。

DHCP と同じように,BOOTP プロトコルはネットワーク・アドレスの集中管理を可能にします。

joind デーモンは,bootpd の機能を提供し,DHCP サービスも提供します。

3.4.5    SNMP エージェント

Tru64 UNIX の SNMP エージェントは,ネットワーク管理に利用する次のような多数の管理情報にアクセスすることができます。

eSNMP エージェントにより,Tru64 UNIX ホスト上で管理情報ベース (MIB) の動的な追加が可能です。

マスタ・エージェント,API,ベース・オペレーティング・システムの MIB サポートは,すべて標準のネットワーク・サブセット (CLINET) に含まれています。

eSNMP 開発者ツールは,オプションのプログラミング・サブセット (PGMR) に含まれています。

3.4.6    gated デーモン

gated デーモンを使用すると,複数のネットワーク・インタフェースを持つホストを RIP,OSPF,EGP,BGP などの種々の IP プルプトコルを扱う IP ルータとして機能させることができます。 Tru64 UNIX は,次の項目をサポートする,NextHop Technologies 社の GateD Release 3.5 gated デーモンをサポートします。

gated デーモンについての詳細は, gated(8)gated.conf(4)gated.control(4)gated.proto(4),および gated_intro(7) リファレンス・ページを参照してください。

3.4.7    screend デーモン

screend デーモンはゲートウェイ・スクリーン機能とともに使用され,システムが IP ゲートウェイとして動作している場合に IP パケットを転送するかあるいは拒否するかを決定します。

ゲートウェイ・パケット・スクリーン機能によって,システム管理者は,ゲートウェイとして動作する Tru64 UNIX システムで,どのパケットを転送するかあるいは転送を拒否するかを制御することができます。 このため,ゲートウェイ・パケット・スクリーン機能をネットワーク・セキュリティ・ポリシの一部として使用することができます。

この機能は,カーネル常駐メカニズムとユーザ・レベルのデーモン /usr/sbin/screend で構成されます。 パケットを転送する用意ができたら,カーネル・メカニズムはそのパケットのヘッダをデーモンへ送ります。 screend デーモンはそのヘッダをチェックし,/etc/screend.conf 構成ファイルで定義されているルールに従って,パケットを転送するか拒否するかをカーネルに知らせます。

不適当な構成あるいは潜在的なセキュティリ上の問題をネットワーク管理者が見つけることができるように,これらの決定のすべてあるいは一部を記録することもできます。

3.4.8    UUCP

Tru64 UNIX は,HoneyDanBerバージョンの UUCP (UNIX-to-UNIX Copy Program) をサポートします。 UUCP は UNIX システム間の通信をサポートするための一連のプログラムです。 UUCP は,2 つの UNIX システム間でバッチによるエラーのないファイル転送およびリモート・コマンドの実行を行うことができます。 UUCP は,低速で低コストの通信リンクを通して電子メール,ネットワーク・ニュース,パブリック・ドメイン・ソフトウェアを転送する場合に最も一般的に使用されています。

UUCP は,2 つのシステム間の直接接続のみをサポートします。 電子ニュースおよび電子メールの配信は,第三者による転送に依存しています。 ネットワークに接続されたサイトのほとんどは,メールおよびニュースの配信のために別のサイトにファイルを中継することに積極的です。 UUCP ネットワークの継続的運用は,遠距離の直通ダイヤル・ネットワークおよび閑散時の長距離レートに依存しています。 UUCP についての詳細は, uucp_setup(8)を参照してください。

3.4.9    ローカル・エリア・トランスポート (LAT)

LAT (Local Area Transport) は,ローカル・エリア・ネットワーク (LAN) 上のホスト・コンピュータと,ターミナル・サーバに接続されている端末,PC,プリンタ,モデム,およびその他のデバイスとの通信をサポートするプロトコルです。 LAT ソフトウェアは,ホストがサービス・ノードとして動作するのに必要な機能を提供するため,サーバ・ユーザが接続要求を行うことができます。 また,サーバ・ポートヘの接続開始,アプリケーション・ポートの指定,リモート・デバイスへのアクセスをホスト・アプリケーションが行うこともできます。 LAT ドライバは STREAMS ベースで,4000 ユーザまでサポートしています。 理論上の上限は 5000 ユーザです。

Tru64 UNIX では,LAT は SVR4 および BSD 型の両方のターミナル・デバイスをサポートしています。 必須のシリアル・ターミナル・デバイスとシリアル・ターミナル・オプションは,LAT として 同じBSD tty ネームスペースを共用します。 このことは,ユーザがシリアル・ラインにスペシャル・ファイルを割り当てた場合,これらのスペシャル・ファイルが原因で,構成できる BSD LAT デバイスの数が少なくなることを意味します。

LAT についての詳細は, lat_intro(7) および『ネットワーク管理ガイド:接続編』を参照してください。

3.4.10    ネットワーク・インタフェースの監視

niffconfig コマンドは,1 つあるいは複数のネットワーク・インタフェースの接続の喪失を監視するために必要な処理を行います。 このコマンドで,インタフェースがどの程度早期に,接続喪失の疑いあるいは喪失を宣言するかを指定するためのタイミング・パラメータを扱うことができます。

インタフェースの監視を開始すると,カーネル TMT (トラフィック監視スレッド) が監視対象のインタフェースの接続を確認し,必要に応じて,ネットワーク・インタフェース障害デーモン (niffd) に知らせます。 このデーモンは,動作していないと分類されたネットワーク・インタフェースに対してトラフィックを生成します。 niffd デーモンの目的は,インタフェース・パケット・カウンタを増加させて,そのインタフェースが正しく機能していることを示すことです。

詳細は,『ネットワーク管理ガイド:接続編』および niffconfig(8)niffd(8)nifftmt(7) リファレンス・ページを参照してください。

3.5    ネーミング・サービス

Tru64 UNIX は,次の分散ネーミング・サービスをサポートします。

/usr/lib/libc.so のライブラリ・ルーチン を使用すると,DNS,NIS,およびローカルな /etc ファイルに対して透過的にアクセスできます。 ネーミング・サービス構成ファイル /etc/svc.conf により,特定のデータベースに対して,どのネーミング・サービスをどの順序で照会するかを指示します。

Tru64 UNIX では,NIS 分散環境を DNS 分散環境に変更したり,両方のサービスを同じ環境で実行したりすることができます。 DNS および NIS の両ソース・ファイルはともに /etc 形式のファイルであることが可能なため,BSD (Berkeley Software Distribution) のソース・エリアは,シンボリック・リンクを使用して両方のサービスで共用することができます。

3.5.1    ドメイン・ネーム・サービス

ドメイン・ネーム・サービス (DNS) は,未知のホスト名とインターネット・プロトコル (IP) アドレスを検索するためのメカニズムです。

Tru64 UNIX における DNS の実装は,Internet Software Consortium によってサポートされている BIND (Berkeley Internet Name Domain) サービスをベースにしています。 BIND サービスは,クライアント・システムが DNS サーバからホスト名とアドレスを取得できるというクライアント/サーバ・モデルになっています。

この階層型ネーミング・システムでは,named デーモンによって保守されるローカルの名前解決データベースを使用して,名前解決ルーチンがインターネット上の名前とアドレスの解決を行うことができます。 ホストが要求した名前がローカルのデータベースにない場合は,名前解決ルーチン,またはローカルの名前付きデーモンがリモートの DNS ネーム・サーバに対して照会を行います。

Tru64 UNIX は BIND Version 8.2.2 (RFC 1034 および RFC 1035 に基づいた) をサポートしており,以下の機能が含まれています。

DNS を使用して,ローカルの /etc/host ファイルあるいは NIS で提供されるホスト・テーブルのマッピング情報を置き換える,あるいは補足することができます。 他のすべての分散データベース・アプリケーションに対して NIS を使用すべきではありません。

DNS 環境,DNS の計画と構成,DNS の管理の詳細については,『ネットワーク管理ガイド:サービス編』,『BIND Configuration File Guide』 および bind_intro(7) リファレンス・ページを参照してください。

3.5.2    ネットワーク情報サービス (NIS)

NIS (Network Information Service)は,関係するホストが共通なシステムおよびネットワーク・ファイルへのアクセスを共用するための分散ネーミング・サービスです。 NIS では,システム管理者はこれらの共用ファイルを 1 つのシステムで管理できます。

NIS は,ゲートウェイがインターネットから NIS プロトコルへの外部アクセスを許可しない,安全な環境で使用してください。

3.6    タイム・サービス

Tru64 UNIX は,次のタイム・サービスをサポートします。

NTP は極めて精度の高いクロックを基準にするため,TSP より正確な時刻を提供します。 一方 TSP は,ネットワーク・ホスト時刻の平均値を基準にして時刻を同期化します。 ご使用のシステムがインターネット上になく高精度のタイム・サーバへアクセスしない場合には,TSP を使用するのが適切です。 それ以外の場合は,NTP を使用するのが適切です。

3.6.1    ネットワーク・タイム・プロトコル (NTP)

NTP (Network Time Protocol) は,インターネットのような広域通信網およびローカル・エリア・ネットワークの両方のホストに対して,正確で信頼性の高い,同期化された時刻を提供します。 特に NTP は極めて精度の高いクロックをトレースして同期化することが可能で,時刻が不正確なクロックを基準にして同期化することを避けることができます。

NTP を実行している各ホストは,現在の時刻の推定値を照会するデータグラムの交換を定期的に繰り返します。 パケットが往復する時間を調べることによって,ホストは一方の遅延を推定することができます (往復時間は両方向でほぼ同じという前提です)。 一方向の遅延時間を測定し,NTP パケットで返されるタイムスタンプを調べることにより,自身のクロックと照会したホストのクロックとの時間の誤差を計算します。

ホストは一定の期間に複数回リモート・ホストを照会し,複数のサンプル結果をディジタル・フィルタリング・アルゴリズムに送ります。 このアルゴリズムは,ひとつのサンプルによって得られる以上に高精度な,遅延時間,クロック・オフセット,クロックの安定性に関する推定値を導き出します。

NTP メッセージには時刻ソースの精度と信頼性についての情報も含まれています。 NTP ホストは,公的機関が送信している時報信号の受信機などの精度の高い時刻ソースに直接接続されています。 このようなホストは,第 1 層サーバと呼ばれます。 他のすべての NTP ホストは,時刻を同期するために参照したホストの層番号より 1 つ大きな番号を層番号として使用します。 たとえば,第 1 層サーバに同期を取るホストは,第 2 層ホストになります。 層の決定は自動的に行われ,ホストの層はその接続によって変更することがあります。

NTP を使用するホストは,どのホストが最も正確と思われる時刻を提供しているかをさまざまな情報から判断します。 この情報には,ディジタル・フィルタリング・アルゴリズムの出力,および照会するホストの層番号が含まれます。 他のホストとの通信によって,NTP ホストはクロック時刻の正確でないホストを検出し,長期間通信ができないホストに対しても同期を取ることが可能です。

実際に NTP は,数千マイルに及ぶ広域通信網上でも数十ミリ秒単位でのクロックの同期化を行うことができます。

Tru64 UNIX は,NTP Version 4 をサポートしています。

NTP プロトコルは,RFC 1305 に記述されています。 詳細は,『ネットワーク・プログラミング・ガイド 』, ntp_intro(7),および ntp_conf(4) を参照してください。

3.6.2    時刻同期化プロトコル (TSP)

TSP (Time Synchronization Protocol) は,/usr/sbin/timed デーモンによって使用されるプロトコルです。 単純なアプリケーションによって,Ethernet などのブロードキャスト・ネットワーク上の TSP サーバは,周期的に TSP パケットを送信します。 ネットワークのホストは,TSP を実行しているホストのうちの 1 つをマスタ・ホストとして選択します。

マスタ・ホストは,以降のプロトコルに関する処理を,障害が発生して新しいマスタ・ホストが選択されるまでの間制御します。 マスタ・ホストは他のホストから時刻を集計し,報告されたすべての時刻の平均値を計算した後,マスタ・ホスト自身のクロックをこの平均値に設定し,他のホストのクロックをこの平均値に同期させます。

TSP は,すべての関連ホストの時刻を迅速に同期化します。 ただし TSP は,正確と思われるソースまで時刻の追跡を行いませんので,系統的なエラーを修正することはできません。 クロックに大きな誤差があったリ,ホストの時間設定が正しく行われなかった場合,マスタによって計算され分配された平均時刻に対して大きな影響を及ぼす可能性があります。