INET(4)

名称
inet - インターネットプロトコルファミリ

書式
#include <sys/types.h> #include <netinet/in.h>

解説
インターネットプロトコルファミリは Internet Protocol (IP) トランスポート層の上に位置し、インターネットアドレスフォーマットを 利用するプロトコル群です。 インターネットファミリは、 SOCK_STREAM, SOCK_DGRAM および SOCK_RAW ソケットタイプのためのプロトコルのサポートを提供します。 SOCK_RAW インタフェースは IP プロトコルへのアクセスを提供します。

アドレッシング
インターネットアドレスは 4 バイトの大きさであり、 ネットワーク標準フォーマットで格納されています ( VAX では、ワード、バイトの順序を逆にしたものです)。 インクルードファイル <netinet/in.h> では、このアドレスを 区分された共用体として定義しています。

インターネットプロトコルファミリに結合されたソケットは、次の アドレッシング構造体を利用します。

    struct sockaddr_in {
    	u_char	sin_len;
    	u_char	sin_family;
    	u_short	sin_port;
    	struct	in_addr sin_addr;
    	char	sin_zero[8];
    };

到着メッセージに対する “ワイルドカード” マッチングの効果を得る場合、 INADDR_ANY ローカルアドレスを用いて、 ソケットを生成することができます。 connect(2) あるいは sendto(2) の呼び出しで与えるアドレスとして、 “このホスト” を意味するために、 INADDR_ANY を与えても構いません。 もし最初からネットワークがブロードキャストをサポートするように設定 されていれば、 特別のアドレスである INADDR_BROADCAST が、プライマリネットワーク上のブロードキャストアドレスを表す略記として 許されています。

プロトコル
インターネットプロトコルファミリは、 IP ネットワークプロトコル、 インターネットコントロールメッセージプロトコル (ICMP) 、インターネットグループマネジメントプロトコル (IGMP) 、トランスミッションコントロールプロトコル (TCP) 、およびユーザデータグラムプロトコル (UDP) からなります。 TCP は SOCK_STREAM アブストラクションをサポートするために使われ、 UDP は SOCK_DGRAM アブストラクションをサポートするために使われます。 IP に対する raw インタフェースが、 SOCK_RAW タイプのインターネットソケットを生成することにより 利用可能です。 ICMP メッセージプロトコルが raw ソケットからアクセス可能です。

32 ビットのインターネットアドレスはネットワーク部とホスト部の 両方を含んでいます。 しかしながら、アドレスに対して直接検査することは推奨されません。 どうしてもアドレスをその 2 つの部分に分割する必要のあるプログラムの ために、次の ioctl(2) コマンドがインターネットドメインのデータグラムソケット向けに 提供されています。 それらは SIOCIFADDR コマンド ( intro(4) を参照 ) と同じ形式を持ちます。

SIOCSIFNETMASK
    インタフェースのネットワークマスクを設定します。 ネットワークマスクはアドレスのネットワーク部を定義します。 もしそれがアドレスタイプが示すよりも多いアドレスを含むなら、 サブネットが使われています。

SIOCGIFNETMASK
    インタフェースのネットワークマスクを得ます。

ルーティング
インターネットプロトコルの現在の実装は、トランザクション TCP (Transaction TCP) および経路の MTU 検出 (Path MTU Discovery) に必要なある種のエンドツーエンド情報に対する強力な キャッシングを提供するために、ルーティングテーブルに対する いくつかの調整を含んでいます。 次に示す変更が最も重要です :

1.  RTF_CLONING フラグ付きあるいはマルチキャストの終点宛 以外の IP 経路は RTF_PRCLONING フラグが強制的に立てられます (これは “プロトコルクローニング” と呼ばれます。)

2.  ある IP 経路への最後の参照が欠落している場合、 その経路が、そのような経路をコピーすることにより生成されたかどうかが 検査されます。 もしそうであれば、 RTF_PROTO3 フラグが立てられ、net.inet.ip.rtexpire 秒以内に消去されるように 無効化のためのタイマが初期化されます。 そのような経路が再び参照されると、フラグとタイマはリセットされます。

3.  10 分に 1 回、あるいはカーネルのルーティングテーブルに期限切れ直前の 経路が存在するとすぐにカーネルタイムアウトが実行され、 期限切れの経路を削除します。

キャッシュされている経路が大きくなり過ぎた場合、 net.inet.ip.rtexpire の値を変更するための 動的な処理が実行されます。 期限切れ消去の実行後に、net.inet.ip.rtmaxcache より多い数の経路が参照されないまま残っている場合、 rtexpire が 3/4 にされ、これより長い期限をもつ すべての経路の期限が調整されます。 最小の rtexpire 値 (net.inet.ip.rtminexpire) の指定および この削減を 10 分に 1 回おきに起こるように制限することにより、 このプロセスの効果はいくらか小さくなります。

何らかの外部プロセスが、 プロトコルクローンで作られた経路の オリジナルの経路を削除した場合、 「子の経路」は削除されます。 (実際のところ、これは、プロトコル要求クローニングをサポートする ルーティングコードにおける一般的なメカニズムです。)

プロトコルクローニングにより生成されたのではない経路を管理する 試みは行なわれません。 それらは静的であり、 外部のルーティングプロセスや、あるいは リンク層 (たとえば イーサネットにおける ARP) の管理下にあると想定されます。

ある種のネットワーク活動だけが、このメカニズムを用いて経路のクローニング を行ないます。 特にある宛先を持ち、長い間継続する経路の参照を自分自身でキャッシュ するプロトコル ( TCP や UDP のような ) は、このメカニズムを起動するきっかけとなります。 一方、ローカルに生成されたものであれフォワードされたものであれ、 生の IP パケットだと、このメカニズムは起動しません。

MIB 変数
sysctl(3) MTB の net.inet ブランチには、多くの 変数が実装されています。 トランスポートプロトコルによりサポートされる変数 (各々のマニュアルページを参照してください) に加え、次の一般的な変数が定義されています。

IPCTL_FORWARDING
    (ip.forwarding) ブール値: IP パケットのフォワーディングを可能にする / 抑制する (デフォルトではカーネル設定オプション GATEWAY によります)。

IPCTL_SENDREDIRECTS
    (ip.redirect) ブール値: フォワードできない IP パケットについて ICMP リダイレクトを送出する / 送出しない (デフォルトは真)。

IPCTL_DEFTTL
    (ip.ttl) 整数値: 外に出ていく IP パケットのデフォルトの生存時間。

IPCTL_SOURCEROUTE
    (ip.sourceroute) ブール値: 始点経路制御された IP パケットのフォワードを 可能にする / 抑制する (デフォルトは偽)。

IPCTL_RTEXPIRE
    (ip.rtexpire) 整数値: プロトコルクローンされた IP 経路の、最後の参照が終了した後の秒単位の 生存時間 (デフォルトは 1 時間)。 上記のように、この値は動的に変化します。

IPCTL_RTMINEXPIRE
    (ip.rtminexpire) 整数値: ip.rtexpire の最小値 (デフォルトは 10 秒)。 この値はユーザによる変更に対しては効果がなく、上記のような動的調整に 限られています。

IPCTL_RTMAXCACHE
    (ip.rtmaxcache) 整数値: キャッシュされ、かつ参照されず、かつプロトコル クローンされた経路の、動的な調整を開始するトリガレベル (デフォルトは 128)。

関連項目
ioctl(2), socket(2), sysctl(3), icmp(4), igmp(4), intro(4), ip(4), tcp(4), ttcp(4), udp(4) An Introductory 4.3 BSD Interprocess Communication Tutorial, PS1, 7. An Advanced 4.3 BSD Interprocess Communication Tutorial, PS1, 8.

警告
インターネットプロトコルのサポートは、インターネットプロトコルの 発展に従属しています。ユーザは現在の実装の詳細に依存してはならず、 むしろエクスポートされたサービスに依存すべきです。

歴史
inet プロトコルインタフェースは 4.2BSD で登場しました。 “プロトコルクローニング” のコードは FreeBSD 2.1 で登場しました。