path: root/ja_JP.eucJP/man/man4/netintro.4

.\" Copyright (c) 1983, 1990, 1991, 1993
.\"     The Regents of the University of California.  All rights reserved.
.\"
.\" Redistribution and use in source and binary forms, with or without
.\" modification, are permitted provided that the following conditions
.\" are met:
.\" 1. Redistributions of source code must retain the above copyright
.\"    notice, this list of conditions and the following disclaimer.
.\" 2. Redistributions in binary form must reproduce the above copyright
.\"    notice, this list of conditions and the following disclaimer in the
.\"    documentation and/or other materials provided with the distribution.
.\" 3. All advertising materials mentioning features or use of this software
.\"    must display the following acknowledgement:
.\"     This product includes software developed by the University of
.\"     California, Berkeley and its contributors.
.\" 4. Neither the name of the University nor the names of its contributors
.\"    may be used to endorse or promote products derived from this software
.\"    without specific prior written permission.
.\"
.\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND
.\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
.\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
.\" ARE DISCLAIMED.  IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE
.\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
.\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
.\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
.\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
.\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
.\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
.\" SUCH DAMAGE.
.\"
.\"     @(#)netintro.4  8.2 (Berkeley) 11/30/93
.\"     %Id: netintro.4,v 1.8 1997/03/19 19:47:38 bde Exp %
.\"
.\" $FreeBSD$
.Dd November 30, 1993
.Dt NETINTRO 4
.Os BSD 4.2
.Sh 名称
.Nm networking
.Nd ネットワーク機構の紹介
.Sh 書式
.Fd #include <sys/types.h>
.Fd #include <sys/time.h>
.Fd #include <sys/socket.h>
.Fd #include <net/if.h>
.Fd #include <net/route.h>
.Sh 説明
このセクションでは、本システムで利用可能なネットワーク機構について
の一般的な紹介を行っています。セクション 4 のこの部分のドキュメントは
3 つの領域に分かれます。
.Em プロトコルファミリ
(ドメイン)、
.Em プロトコル、
そして
.Em ネットワークインタフェース
です。
.Pp
ネットワークプロトコルは、すべて特定の
.Em プロトコルファミリ
と関連づけられています。
プロトコルファミリは、プロトコルが特定のネットワーク環境下で
機能できるようにするため、プロトコルの実装に対しての基本的な
サービスを提供します。これらのサービスはパケットの分割および
統合、ルーティング、アドレッシング、そして基本的な転送なども
含まれるでしょう。現在のプロトコルの実装ではサポートされていません
が、プロトコルファミリは、複数のアドレッシング方法を提供
するかもしれません。プロトコルファミリには、通常各
.Xr socket 2
タイプに 1 つずつというように、多数のプロトコルが含まれています。
プロトコルファミリは、すべてのソケットタイプをサポートする必要は
ありません。プロトコルファミリには、同一のソケットアブストラクションをサポート
するために、複数のプロトコルが含まれることがあります。
.Pp
プロトコルは、
.Xr socket 2
で詳しく決められたソケットアブストラクションの 1 つをサポートします。
特定のプロトコルには、適切なプロトコルファミリとタイプのソケットを
作成するか、ソケットを作成する際に明示的にそのプロトコルを要求
することによってアクセスすることができます。プロトコルは、通常
1 種類のアドレスフォーマットのみを受け取ります。通常、そのアドレス
フォーマットは、プロトコルファミリとネットワークアーキテクチャの
デザインに必要なアドレッシング構造体を用いて定義されています。
ある基本的なソケットアブストラクションのセマンティクスは、
プロトコルに特有のものです。
プロトコルはすべてそれぞれに特有のソケットタイプについての基本モデル
をサポートするようになっています。しかし、さらに、そのメカニズムに対して、
標準的ではない機構や拡張機能を提供することもあります。例えば、
.Dv SOCK_STREAM
をサポートするプロトコルが、各帯域外 (out-of-band) メッセージにつき
1 バイト以上の帯域外メッセージを送信することができます。
.Pp
ネットワークインタフェースは、デバイスインタフェースと似ています。
ネットワークインタフェースは、ネットワークサブシステムの最下位層
を構成します。これは、実際の送信用ハードウェアと相互に影響します。
ネットワークインタフェースは、
1 つ以上のプロトコルファミリやアドレスフォーマットをサポート可能です。
各ネットワークインタフェースのエントリの書式 (SYNOPSIS) のセクション
には、
.Xr config 8
プログラムにシステムの詳細を提供する際に使われる、関連ドライバの
仕様の例があります。
診断 (DIAGNOSTICS) のセクションのメッセージ一覧は、
デバイスを操作中に起こるエラーに起因して、コンソールやシステムエラーログ
.Pa /var/log/messages
(
.Xr syslogd 8
を参照) 中に出力されるものです。
.Sh プロトコル
本システムでは、現在、インターネットプロトコル、Xerox Network Systems(tm)
プロトコル、そして
.Tn ISO OSI
プロトコルのいくつかがサポートされています。
ソケットの raw インタフェースがインターネットの
.Tn IP
プロトコル層、
Xerox
.Tn NS
の
.Tn IDP
プロトコルに対して提供されています。
各プロトコルファミリのサポートに関するさらなる情報が必要な場合は、
しかるべきマニュアルページを調べてみてください。
.Sh アドレッシング
各プロトコルファミリと関連付けられているのが、アドレスフォーマットです。
ネットワークアドレスは、すべて以下に示す sockaddr と呼ばれる一般的な
構造体と結びついています。しかし、各プロトコルは、より洗練された特有の
構造体を使うように強制しています。一般的には、変数名を変えるといったこと
です。このことについては、上で述べたプロトコルファミリのマニュアルページで
議論されています。
.Bd -literal -offset indent
    struct sockaddr {
        u_char  sa_len;
        u_char  sa_family;
        char    sa_data[14];
};
.Ed
.Pp
.Ar sa_len
フィールドには、この構造体全体の長さが入ります。この長さは 16 バイトを
超えるかもしれません。
次に示す
.Ar sa_family
用のアドレス値は、システム側で既知なものです
(将来実装されるかもしれないフォーマットも加えて、ここで定義しています)。
.Bd -literal
#define    AF_UNIX      1    /* ローカルホスト (パイプ、ポート) */
#define    AF_INET      2    /* インターネット: UDP, TCP など */
#define    AF_NS        6    /* Xerox NS プロトコル */
#define    AF_CCITT     10   /* CCITT プロトコル、X.25 など */
#define    AF_HYLINK    15   /* NSC ハイパーチャネル */
#define    AF_ISO       18   /* ISO プロトコル */
.Ed
.Sh ルーティング
.Tn UNIX
では、パケットのルーティング機構がいくつか提供されています。
カーネルは、ルーティング情報データベースを管理しています。
このデータベースは、パケットを転送するときに適切なネットワークインタフェース
を選ぶ際に使用されます。
.Pp
ユーザプロセス (あるいは、複数の相互に協調し合ったプロセス) は、
特別な種類のソケットを通してメッセージを送ることで、
このデータベースを管理しています。
この方法が、以前のリリースで使われていた固定長の
.Xr ioctl 2
に取って代わりました。
.Pp
この機構については、
.Xr route 4
に説明があります。
.Sh インタフェース
システム内の各ネットワークインタフェースは、メッセージの送受信に
使われるパスに対応しています。ネットワークインタフェースは、通常、
関連のあるハードウェアデバイスを持っています。しかし、
.Xr lo 4
のようなループバックインタフェースはハードウェアデバイスを持っていません。
.Pp
次の
.Xr ioctl 2
コールは、ネットワークインタフェースを操作するのに使われます。
.Fn ioctl
関数は、所望のドメインのソケット (特に
.Dv SOCK_DGRAM
型) 上で実行します。以前のリリースでサポートされていたリクエストの多くは、
パラメータに
.Ar ifreq
構造体を取っていました。この構造体は、次の形式です
.Bd -literal
struct  ifreq {
#define    IFNAMSIZ    16
    char    ifr_name[IFNAMSIZ];        /* if 名であり、例えば "en0" */
    union {
        struct    sockaddr ifru_addr;
        struct    sockaddr ifru_dstaddr;
        struct    sockaddr ifru_broadaddr;
        short     ifru_flags;
        int       ifru_metric;
        int       ifru_mtu;
        int       ifru_phys;
        caddr_t   ifru_data;
    } ifr_ifru;
#define ifr_addr      ifr_ifru.ifru_addr    /* アドレス */
#define ifr_dstaddr   ifr_ifru.ifru_dstaddr /* p-to-p リンクのもう一方の終端 */
#define ifr_broadaddr ifr_ifru.ifru_broadaddr /* ブロードキャストアドレス*/
#define ifr_flags     ifr_ifru.ifru_flags   /* フラグ */
#define ifr_metric    ifr_ifru.ifru_metric  /* メトリック */
#define ifr_mtu       ifr_ifru.ifru_mtu     /* mtu */
#define ifr_phys      ifr_ifru.ifru_phys    /* 物理的な線 */
#define ifr_data      ifr_ifru.ifru_data    /* インタフェースが使用 */
};
.Ed
.Pp
現在では非推奨のシステムコールは次の通りです。
.Bl -tag -width SIOCGIFBRDADDR
.It Dv SIOCSIFADDR
プロトコルファミリ用のインタフェースアドレスを設定します。
アドレスの割り当てに続いて、
インタフェース用の ``初期化'' ルーチンが呼ばれます。
.It Dv SIOCSIFDSTADDR
プロトコルファミリおよびインタフェース用の、
point to point アドレスを設定します。
.It Dv SIOCSIFBRDADDR
プロトコルファミリおよびインタフェース用の、
ブロードキャストアドレスを設定します。
.El
.Pp
アドレスを取得するための
.Fn ioctl
リクエストと、
アドレス以外のデータを設定したり検索したりするためのリクエストについては、
今でも完全にサポートしており、
.Ar ifreq
構造体を使用しています。
.Bl -tag -width SIOCGIFBRDADDR
.It Dv SIOCGIFADDR
プロトコルファミリ用の、インタフェースアドレスを取得します。
.It Dv SIOCGIFDSTADDR
プロトコルファミリおよびインタフェース用の、
point to point アドレスを取得します。
.It Dv SIOCGIFBRDADDR
プロトコルファミリおよびインタフェース用の、
ブロードキャストアドレスを取得します。
.It Dv SIOCSIFFLAGS
インタフェースフラグのフィールドをセットします。もし、インタフェースが動作
していないという印 (down) がつけられたら、
現在そのインタフェースを通してパケットを
ルーティングしているすべてのプロセスは通知を受けます。
インタフェースによっては、新たに入ってくるパケットをもう受け取らないように
するためにリセットするものがあります。再び動作しているという印 (up)
がつけられたら、
インタフェースは再初期化されます。
.It Dv SIOCGIFFLAGS
インタフェースフラグを取得します。
.It Dv SIOCSIFMETRIC
インタフェースのルーティングメトリックを設定します。
このメトリックは、ユーザレベルのルータのみで使用されます。
.It Dv SIOCGIFMETRIC
インタフェースメトリックを取得します。
.El
.Pp
新しい構造体を使用するリクエストは 2 つあります。
.Bl -tag -width SIOCGIFBRDADDR
.It Dv SIOCAIFADDR
プロトコルによっては、
単一のインタフェースに対して複数のアドレスを関連付けられるものがあります。
このリクエストは、新たなアドレスを追加する
手段を提供します (あるいは、アドレスファミリ用のデフォルトアドレスが
指定されていれば、プライマリアドレスの特徴を変更します)。
終点アドレス、ブロードキャストアドレスあるいはネットワークマスクを
設定するために別々のシステムコールを作るのではなく
(現在では、複数のプロトコルで必要不可欠な特徴です)、
これらの 3 つのものを同時に指定するために別々の構造体を用います
(下記参照)。
各ファミリ専用に、この構造体を少し手直ししたバージョンを使用することも
あるでしょう (各 sockaddr 構造体をファミリ特有のものに置きかえるなど)。
sockaddr 構造体自身がデフォルトの大きさよりも大きい場合には、
.Fn ioctl
のところで述べたように、
.Fn ioctl
識別子自体を全体が入るように変更する必要があります。
.It Dv SIOCDIFADDR
このリクエストは、インタフェースに関連付けられたリストから、
指定したアドレスを削除します。このリクエストは
.Ar if_aliasreq
構造体も使用することにより、
複数のネットワークマスクや終点アドレスを
プロトコルが許可することも可能にします。
また、デフォルトアドレスを指定することは、
このアドレスファミリに属するもののうちで、
このソケットを最初に開いたときの
最初のインタフェースアドレスを削除することを意味するという約束事を、
このリクエストは採用しています。
.It Dv SIOCGIFCONF
インタフェースの設定リストを取得します。このリクエストは
値と結果の両用のパラメータ (value-result parameter) として
.Ar ifconf
構造体を取ります (下記参照)。
.Ar ifc_len
フィールドには、最初に、
.Ar ifc_buf
で指し示されたバッファの大きさをセットしておかなくてはなりません。
戻るときに、このフィールドには設定リストのバイト単位の大きさが
入ります。
.El
.Bd -literal
/*
* SIOCAIFCONF で使用される構造体
*/
struct ifaliasreq {
        char    ifra_name[IFNAMSIZ];   /* if 名であり、例えば "en0" */
        struct  sockaddr        ifra_addr;
        struct  sockaddr        ifra_broadaddr;
        struct  sockaddr        ifra_mask;
};
.Ed
.Pp
.Bd -literal
/*
* SIOCGIFCONF リクエストで使用される構造体。
* マシンのインタフェースの設定を検索するのに使用されます
* (アクセス可能なネットワークをすべて分かっておかなくてはならない
* プログラムに有用です)。
*/
struct ifconf {
    int   ifc_len;              /* 関連バッファの大きさ */
    union {
        caddr_t    ifcu_buf;
        struct     ifreq *ifcu_req;
    } ifc_ifcu;
#define ifc_buf ifc_ifcu.ifcu_buf /* バッファアドレス */
#define ifc_req ifc_ifcu.ifcu_req /* 返される構造体の配列 */
};
.Ed
.Sh 関連項目
.Xr ioctl 2 ,
.Xr socket 2 ,
.Xr intro 4 ,
.Xr config 8 ,
.Xr routed 8
.Sh 歴史
.Nm netintro
マニュアルは、
.Bx 4.3 tahoe
で出現しました。