Provided by: manpages-ja_0.5.0.0.20060115-1_all bug

SYSCTL

       IP        プロトコルでは、いくつかのグローバルオプションを       sysctl
       を通して設定することがでい襦  これらの   sysctl   にアクセスするには、
       /proc/sys/net/ipv4/*                                 ファイルを読み書-
       する方法と、インターフェースに対して   sysctl(2)   を用いる方法がある。
       Boolean     と書かれた変数は整数値をとり、    0    以外の値    ("true")
       は対応するオプションが邑、          0           値           ("false")
       は無効、であることを意味する。

       ip_always_defrag (Boolean)
              [2.2.13   で新規登場。以前のバージョンのカーネルでは、この機能は
              コンパイル時に                           CONFIG_IP_ALWAYS_DEFRAG
              オプションによって制御されていた;      このファイルは      2.4.x
              以降では存在しない]

              このブール値のフラグが邑になっている (0 以外になっている)  と、
              到着したフラグメント            (IP           パケットの一部で、
              発信元と発信先の間のどこかのホストで、そのパケットが        大-
              すぎると判断され、分割された場合に生じる)
              は、たとえフォワードされる場合であっても          処理前に再構成
              (デフラグメント) される。

              ファイアウォールがローカル側のネットワークに唯一のリンクを持っている
              場合や、透過プロクシの場合に限って邑にすべい任△襦
              通常のルーターやホストでは絶対に邑にしないように。
              さもないとフラグメントが別のリンクを経由して伝わる場合に、
              通信のフラグメント化がでい覆なってしまう。
              またデフラグメント化はメモリと CPU 時間のコストが非常に大いぁ

              これはマスカレードや透過プロクシが設定されると、
              不思議な仕組みによって自動的に邑になる。

       ip_autoconfig
              まだ欺劼靴討い覆ぁ

       ip_default_ttl (integer; default: 64)
              送出されるパケットの  time-to-live  値のデフォルトをセットする。
              これは                                                    IP_TTL
              オプションを用いれば、パケットごとに変えることもでい襦

       ip_dynaddr (Boolean; default: disabled)
              動的ソケットアドレスと、インターフェースアドレスが変更された際の
              マスカレードエントリの再書すみを邑にする。
              ダイアルアップインターフェースで、                            IP
              アドレスが変更される場合に便利である。

       ip_forward (Boolean; default: disabled)
              IP    forwarding    を邑にするかどうかのブール値フラグ。     IP
              forwarding するかどうかはインターフェースごとにも設定でい襦

       ip_local_port_range
              ソケットに割り当てられているデフォルトのローカルポートの範囲を定める
              二つの整数を与える。割り当ては   1   番目の番号から始まり、    2
              番目の番号で終わる。
              これらはマスカレードで用いられているポートと重なってはならない
              (その場合も取り扱われるが)。
              ファイアウォールのパケットフィルターが「利用中のローカルポート」
              について何らかの仮定をしている場合には、
              番号を勝手に決めてしまうと問題が起い襪もしれない。            1
              番目の番号は少なくとも        1024        より大いすべい任△襦
              良く使われるポートとの衝突を避けたり、ファイアウォールの問題を
              回避したければ、 4096 よりも大いするほうが良いだろう。

       ip_no_pmtu_disc (Boolean; default: disabled)
              邑になっていると、デフォルトで  TCP  ソケットに対する  Path MTU
              Discoverty    を行わない。    Path    MTU     Discovery     は、
              正しく設定されていない     (ICMP     パケットを全てドロップする)
              ファイアウォールや、    (point-to-point    リンクで双方の    MTU
              が一致していない場合など)
              正しく設定されていないインターフェースが経路上に存在すると失敗してしまう。
              Path      MTU     Discovery     をグローバルに無効にするよりは、
              壊れているルータを直すほうが良い。    Path     MTU     Discovery
              を無効にするとネットワークのコストが                        大-
              くなってしまうからである。

       ip_nonlocal_bind (Boolean; default: disabled)
              セットされていれば、プロセスが自分以外の  IP  アドレスを  bind()
              で-
              るようになる。これはかなり便利だが、うまく動かないアプリケーションもある。

       ip6frag_time (integer; default 30)
              IPv6 フラグメントをメモリに保持しておく時間 (秒単位)。

       ip6frag_secret_interval (integer; default 600)
              IPv6  フラグメントの hash secret の生成間隔 (hash secret の寿命)
              (秒単位)

       ipfrag_high_thresh (integer), ipfrag_low_thresh (integer)
              ゥ紂璽ぅ鵐阿気譴討い IP  フラグメントの量が  ipfrag_high_thresh
              に達すると、ゥ紂爾瞭睛討                      ipfrag_low_thresh
              にまで切り捨てられる。それぞれの大い気
              バイト単位で表す整数値が入っている。

       neigh/*
              arp(7) を見よ。

IOCTL

       socket(7) に欺劼気譴討い ioctl は、 すべて ip にも適用される。

       ファイアウォール関係の設定に関する     ioctl     については    ipchains
       パッケージの ipfw(4) に欺劼気譴討い襦

       ジェネリックデバイスのパラメータを設定する       ioctl       については
       netdevice(7) に欺劼気譴討い襦

意
       SO_BROADCAST    オプションの利用には、くれぐれも注意すること。   これは
       Linux             では特権操作ではない。             不注意なブロード-
       ャストを行うと、ネットワークは簡単に過負荷状態になる。
       新しいアプリケーションプロトコルには、ブロードゥ礇好箸任呂覆  マルチ-
       ャストグループを用いるほうがよい。 ブロードゥ礇好箸録箴されない。

       他の    BSD    のソケット実装では、    IP_RCVDSTADDRIP_RECVIF
       といったソケットオプションがサポートされており、
       宛先アドレスや受信データグラムのインターフェースが取得でい襪茲Δ
       なっていることもある。   Linux   で同じことをやらせるには、より一般的な
       IP_PKTINFO が使える。

       いくつかの          BSD          のソケット実装では          IP_RECVTTL
       オプションも提供されているが、タイプ                         IP_RECVTTL
       の補助メッセージは受信パケットとともに渡される。      これは      Linux
       で使われている IP_TTL オプションとは異なる動作である。

       SOL_IP           ソケットオプションレベルは移植世ない。            BSD
       ベースのプロトコルスタックでは IPPROTO_IP レベルが使用されている。

ー
       ENOTCONN
              接続されていないソケットに対して、
              接続状態でしか定義されていない操作を行おうとした。

       EINVAL 不正な引た瑤渡された。送信操作において、              blackhole
              ルートに送信しようとするとこのエラーが起こることがある。

       EMSGSIZE
              データグラムが path MTU よりも大い、フラグメント化もでい覆ぁ

       EACCES 必要な権限のないユーザーが操作を実行しようとした。
              以下のような場合が考えられる:                       SO_BROADCAST
              フラグを設定していない状態でブロードゥ礇好肇▲疋譽垢
              パケットを送ろうとした。                                prohibit
              なルートを通してパケットを送ろうとした。           CAP_NET_ADMIN
              がなく、実効ユーザー      ID       が       0       でもないのに
              ファイアウォールの設定を変更しようとした。  CAP_NET_BIND_SERVICE
              権限がなく、実効ユーザー     ID      が      0      でもないのに
              特権ポートにバインドしようとした。

       EADDRINUSE
              既に使われているアドレスにバインドしようとした。

       ENOPROTOOPTEOPNOTSUPP
              不正なソケットオプションが渡された。

       EPERM  高い優先度を設定したり、設定を変更したり、要求されたプロセスや
              プロセスグループにシグナルを送ったりするのに必要な権限を、
              ユーザーが持っていない。

       EADDRNOTAVAIL
              存在しないソケットが要求された。または要求された
              ソースアドレスがローカルでない。

       EAGAIN 非ブロッゥ鵐哀愁吋奪箸紡个靴謄屮蹈奪する操作を行った。

       ESOCKTNOSUPPORT
              ソケットが未設定であるか、知らないソケットタイプが要求された。

       EISCONN
              connect(2) が、既に接続済みのソケットに対して呼ばれた。

       EALREADY
              非ブロッゥ鵐哀愁吋奪箸紡个垢訐楝柿犧遒既に実行中である。

       ECONNABORTED
              accept(2) の最中に接続がクローズされた。

       EPIPE  接続が先方から期待していなかったやり方で
              クローズあるいはシャットダウンされた。

       ENOENT パケットが全く到着していないソケットに対して          SIOCGSTAMP
              が呼ばれた。

       EHOSTUNREACH
              宛先アドレスにマッチする邑なエントリがルーティングテーブルに
              存在しない。このエラーはリモートルータからの、
              あるいはローカルルーティングテーブルへの                    ICMP
              メッセージによって引さこされることがある。

       ENODEV ネットワークデバイスがない。または IP を送る機能がない。

       ENOPKG カーネルサブシステムが設定されていない。

       ENOBUFS, ENOMEM
              空ぅ瓮皀蠅造蠅覆ぁ
              このエラーは、メモリアロケーションがソケットバッファの      大-
              さによって制限されていることを意味しているのが通常であるが、
              100% そうだというわけではない。

       他のエラーが上層のプロトコルによって生じるかもしれない。        tcp(7),
       raw(7), udp(7), socket(7).  などを参照のこと。

ン
       IP_MTU,  IP_MTU_DISCOVER,  IP_PKTINFO,  IP_RECVERR,  IP_ROUTER_ALERT は
       Linux 2.2 で新しく導入されたオプションである。  またこれは  Linux  固-
       であり、移植世鮃洋犬靴織廛蹈哀薀爐任 用いるべい任呂覆ぁ

       struct  ip_mreqn  は  Linux  2.2  で登場した。  Linux  2.0  は  ip_mreq
       しかサポートしていない。

       sysctl 群は Linux 2.2 で導入された。

∪
       Linux 2.0 との互換世里燭瓩法 obsolete な socket(PF_INET,  SOCK_PACKET,
       protocol)         という書式でも        packet(7)        をオープンで-
       るようになっているが、これはお勧めでい覆ぁ今後は     socket(PF_PACKET,
       SOCK_RAW,                 protocol)                を代わりに用いるべ-
       である。主な違いは、ジェネリックなリンク層用の              sockaddr_ll
       アドレス構造体が、古い                                     sockaddr_pkt
       に変わって用いられるようになったことである。

グ
       エラーの値が全く首尾一貫していない。

       IP   固佑離ぅ鵐拭璽侫А璽好プションを指定するための   ioctl   と   ARP
       テーブルのことが欺劼気譴討い覆ぁ

       glibc  のバージョンによっては in_pktinfo の定義を忘れているものがある。
       現時点でのとりあえずの対策としては、この                            man
       ページにある定義をプログラム中に コピーすることである。

       recvmsg(2)          で         msg_nameMSG_ERRQUEUE
       を入れて元宛先アドレスを受信する方法は                              2.2
       カーネルの一部でうまく動かない。

目
       recvmsg(2),  sendmsg(2),  ipfw(4), capabilities(7), netlink(7), raw(7),
       socket(7), tcp(7), udp(7)

       RFC 791: オリジナルの IP の仕様
       RFC 1122: IPv4 ホストの必要条件
       RFC 1812: IPv4 ルータの必要条件