iptables -A INPUT —i $DMZ_INTERFACE —j ULOG --ulog-nlgroup 1 ——ulog—prefix # # # # 内部ネットワークからファイアウォールが受信したバケットのフィルタリング # # すべて許可する iptables -A INPUT —i $LAN_INTERFACE —j ACCEPT # # FORWARD チェーンの設定 ( テフォルト拒否 ) # # # ( サーバーへの接続は許可するが、外向きの接続は許可しない ) # # # インターネット←→ DMZ 間のフィルタリング 特集 0 xen [ 3 ] "droped packet —s $LAN—ADDR \ # # Web サーバー iptables iptables # # SSH サーバー iptables iptables -A FORWARD —d 192. 168. 128 . 2 -A FORWARD —s 192 . 168 . 128 . 2 -A FORWARD —d 192 . 168 . 129 . 2 -A FORWARD —s 192 . 168 . 129 . 2 ー ー 1 ー 1 ー 1 ー 1 $LAN_INTERFACE ー 0 $DMZ_INTERFACE -p tcp ——dport 80 ! —state NEW, ESTABLISHED —j LOGACCEPT state $DMZ_INTERFACE ー 0 $LAN_INTERFACE -p tcp ——sport 80 \ —d $LAN-ADDR —m state -state ESTABLISHED -j LOGACCEPT $LAN_INTERFACE ー 0 $DMZ_INTERFACE -p tcp —-dport 22 ! -s $LAN_ADDR \ —state NEW , ESTABLISHED -j LOGACCEPT state $DMZ_INTERFACE ー 0 $LAN_INTERFACE -p tcp --sport 22 \ —d $LAN-ADDR —m state —state ESTABLISHED —j LOGACCEPT # # # DMZ LAN 間のフィルタリング # # LAN → DMZ はデフォルト許可、逆方向は許可しない -p udp ——sport 53 —s 192.168.0.1 —j LOGACCEPT -p udp ——dport 53 —d 192 .168 . 0.1 —j LOGACCEPT # # DNS を許可する iptables -A FORWARD —i $LAN-INTERFACE ー 0 $DMZ-INTERFACE \ iptables —A FORWARD —i $LAN—INTERFACE ー 0 $DMZ—INTERFACE \ iptables —A FORWARD —i $DMZ—INTERFACE ー 0 $LAN—INTERFACE \ iptables —A FORWARD -i $DMZ-INTERFACE ー 0 $LAN-INTERFACE ¯p tcp ——dport 22 \ # # DMZ から 192 .168 . 0 . 10 への SSH のみ許可 —state ESTABLISHED , RELATED —j LOGACCEPT —d $LAN—ADDR -m state iptables —A FORWARD -i $DMZ-INTERFACE ー 0 $LAN-INTERFACE \ —state NEW , ESTABLISHED —j LOGACCEPT —s $LAN—ADDR -m state —s 192. 168.129.2 -d 192 .168 . 0 . 10 —m state # # # その他はすべて拒否 # # 拒否したバケットのログをとる iptables —A FORWARD -j ULOG —-ulog-nlgroup 1 # # バケットの転送を開始する ech0 1 > /proc/sys/net/ipv4/ip-forward UN 工 X MAGAZINE 2005. 12 exit 0 —state NEW, ESTABLISHED —j LOGACCEPT —ulog-prefix "droped packet " 45

リスト 1 iptables の言又疋 # ! /bin/sh PATH=/sbin: /bin: /usr/bin: /usr/sbin # LAN インターフェイスの名前 # DMZ インターフェイスの名前 # # ポリシーの初期設定 DMZ_INTERFACE="vif + " LAN_INTERFACE=" eth0" # # 変数の定義 LAN_MASK= ( /sbin/ifconfig $LAN-INTERFACE ー # LAN インターフェイスのアドレス # # すでに設定されているルールを消去する echo 0 > /proc/sys/net/ipv4/ip—forward # # 以下の設定を実行しているあいだはバケットの転送を停止する LAN_ADDR=$LAN_X/$LAN_MASK LAN—X= 'netstat —rn ー grep $LAN—INTERFACE ー grep $LAN-MASK ー cut —e d ( iptables iptables iptables iptables iptables iptables —F —t nat —X LOGACCEPT -P INPUT DROP -P OUTPUT ACCEPT -P FORWARD DROP # # ループバック・インターフェイスの入出力を許可する iptables -A INPUT —i 10 —j ACCEPT iptables -A OUTPUT ー 0 10 —j ACCEPT # # # 「外部 /LAN → DMZ 」のコネクションのログをとる iptables -A LOGACCEPT -p udp —-dport 53 -j ACCEPT iptables -A LOGACCEPT -p icmp ——icmp—type echo-request —j ACCEPT # # PING と DNS のログはとらない iptables ¯N LOGACCEPT # # 接続の記録と ACCEPT をおこなうチェーン # # # 「 DMZ → —j ULOG # # INPUT チェーンの設定 ( テフォルト拒否 ) iptables —A LOGACCEPT —i $LAN—INTERFACE ー 0 —j ULOG ——ulog—nlgroup 1 ——ulog—prefix LAN 」のコネクションのログをとる iptables -A LOGACCEPT -i $DMZ—INTERFACE ー 0 $LAN—INTERFACE -ulog—nlgroup 1 —-ulog-prefix iptables -A LOGACCEPT -j ACCEPT $DMZ_INTERFACE accept incoming "accept outgoing # # # # DMZ ネットワークから受信したバケットのフィルタリング 44 # # すべて拒否する —m state connection —m state connection —state NEW \ —state NEW \ UNIX MAGAZINE 2005 . 12

Fastest, FIexbiIity, Reliability ー旦ー吐 JCS ディスクアレイ 3U Tower RGM-IU (Ultra16() SCSI ) RVAL ( U ra320 SCSI) 0 ゅー 3 第準物最大搭載可能容量 2.24TB 巨 32 。 500GBX6 1 年間無償オンサイトサービス標準 RVALE-2U 3U RVAL-3U (UItra320 SCSI (UItra320 SCSI ) ロセ、、 32 CSI ス ーヒス MII)I)%M: l.26TB ~ 2.24TB (RAID 0 構成時 ) ■対応 RA Ⅱ ) レベル : 0 コ . 0 + 乢 3.5 ■対応ネットワーク転送プロトコル : TCP/IP, AppIeTalk ■対応ネットワークファイル転送プロトコル :CIFS/SMB (Windows) 、 FS 、 , 2.0. v3.0 ( U 、 IX/Linux/FreeBSD ). 、 CP ( 、 0 、℃ II Net W 代 ) 、 AFP ( Macintosh ) •.Network lnterface: Gigabit Ethernet ( 標準ーポート . オプションで追加可能 )I()/IO()Base-TX ーポート ・オンライン RAII) 工クスパンション対応 ・最大 4 アレイセット 8 スライスまでの論理ドライプを MB 単位の容量で作成可能 ・ケース : 3U Rackmount Type NF ( W435mm 日 3mm I)638mm ) ・一年間無償全国出張オンサイトサーピス (Y 1 617 , 000 ( 税込 ) ( 、℃、 F にⅡ月 2()GB x Ⅱ (72(H)rpm) I.68TB ¥ 1 , 596 , 000 ( 税込 ) ・日 DD 、容量 : TÄ)GB—I.()TB BCache Mernory:128MB(e:: 準 ) ~ 最大引 2MB •RAII) Levels: 0. 0 + 3 , 5 日 DD 容量 : 720GB ~ 3. ()TB •Transfer R e MB/s Cache Memory に 8M B ・ Power Supply Capacity: 2 測 W 電源 R AI D Levels: 0. l.() + 乢 3 , 5 , JBOD ・ ln r 信 : Ultra16() : TransferRate: 320MB/s *ize: W449mm x 日 44mm x I)5&)mm Power SuppIy : 2 測 W Redundant ※ UNIX, WindowsNT/ Mac OS に対応 ※ WindowsNT4.0/2(M川/XP/2(X)3, ※ディスク容量は R DO で使用時の容量です。 UNIX/Linux. Solaris,MacOS 等に対応 ※ディスク容量は RA Ⅲ 0 使用時の容です。 VCRGM16004-lU VCRGM2.5(H)4-lU 160GB x 4 基 (25()GB 、 6 5TB (5()()GB 、 6 : ) 3. OTB 250GB x 4 基 (72(H)rpm) 640GB (7200rpm) I.OT B ¥ 396 , 900 ( 税込 ) ¥ 354 , 900 ( 税込 ) ¥ 378 , 400 ( 税込 ) ¥ 533 , 400 ( 税込 ) RVNMU-4U(Ultra320 SCSI) ・ 11 れ el の 3 幻レ 0 プロセッサ搭載 ■ l-ll)l)ff{å: 最大 6.4TB ( 4()()GB x ) ■ Cache Memory: に 8MB ( 標準 ) ~ 最大一 GB ・ RAII) Levels: 0 は .0 十 3.5 ■ TransferRate: 32()MB/s ・ lnterface: Ultr 320 SCSI ・ Size:W:483mm H:175mm I):583mm ・ Power Supply Capacity : 淑 ) ()W x2 十一 Redundant ※ Windows 、 T4.0 / 2 似用 / XP. U 、一 X/Lin ux. Mac()S 等に対応 6 ~ ドー ※ディスク容量は RA Ⅲ 0 使用時の容量です。 VCRVNMU250()16P-4U (25()GB x 基 ) 4. OTB VCRVNMF25()()16P-4U(FC モデル )(2 測 GB x 基 ) 4. ()TB ¥ 858 , 900 ( 税込 ) ¥ 963 , 900 ( 税込 ) VCRVNMU16()()16P ・ 4U(160GB x 16 基 ) 2. TB VCRVNMF16()()16P ・ 4U()C モデル )( Ⅲ石 B x 基 ) 2. TB ¥ 806 , 400 ( 税込 ) ¥ 911 , 400 ( 税込 ) JCS Vintage シリーズはその経験と技術力に裏付けられた、製品自体の高い信頼性と サポートの質の高さが評価されて、灯分野の主要な企業をはしめ各省庁・各大学への圧倒的な納入実績を誇ります セ、、 ・ lnterface: Ultra32() SCSI 」℃ S ディスクアレイ W 新 t キャンペーン実新中 ! 圧倒的な高速性と高信頼性を実現した新世代ディスクアレイ登場 ! ! Ultra320 SCSI モデル / ファイバーチャネルモデル ・高速性 - 従来機種 ( 自社製 / 他社製 ) と比較して 20 % 以上の高速化を実現 ・高信頼性 - 最新 RAID テクノロジ RAID 6 をサポート ・大容量 , ハイ・コストパフォーマンス - 8. OTB 125.8 万円 ! 2TB 51.8 万円 ! ( 価格は税別表示です。 ) 2U R VAL-2U (UItra320 SCSI ) 2U 8 基 ) = ・ ス ・ te ド 3 幻レ 0 プロセッサ鞳載 ⅳド 3 幻レ 0 プロセッサ搭載 lntel ・ 3 レ 0 プロセッサ搭載 ・ HDD#ht: 最大 8. OTB ( 員石 B x ) HDI)8ht: 最大 6. OTB ( (H)GB x 肥 ) HDI)B 量 : 最大 4. OTB ( 5(H)GB x 8 ) ・ Cache Memory: 肥 8MB ( 標準 )~ 最大 IGB Cache Memory: に 8MB ( 標準 )~ 最大 IGB Cache Memory: 128MB ( 標準 )~ 最大 IGB ・ RAID Levels: 0.1.0 + 乢 3 を 5 を 6 RAID Levels: 0.1.0 + 1,3.5.6 RAID Levels: 0.1.0 十 1,3 , 5.6 ・ TransferRate: 320MB/s TransferRate: 3 M B/s TransferRate: 320MB/s ■ Host lnterface: Ult ロ 3 : / Fibre Channel Host lnterface: Ultra320 SCSI / Fibre Channel Host lnterface: Ultra320 SCSI / Fibre Channel ■ Size:W:448mm 日ヨ 32mm I):470mm Size:448mm H:88mm D:480mm Size:448mm H:88mm D:480mm ■ Power Supply Capacity : 4 ) W x2 Redundant Power SuppIy Capacity : 3 測 W x2 Redundant Power SuppIy Capacity: 3 ) W x2 Redundant ※ Windows 、 T4.0/2(HWXP,UNIX/Linux. Mac()S 等に対応 ※ Windows 、 T4.0 / レ XP. U 、一 X / L ⅲ ux , MacOS 等に対応 ※ Windows 、T4.0/2供用/XP. UNIX/Linux,Mac()S 等ー こ対応 ※ディスク容量は RA Ⅲ 0 使用時の容量です。 ※ディスク容量は RA Ⅱ ) 0 使用時の容量です。 ※ディスク容量は RA Ⅲ 0 使用時の容量です。 VCRV AL2 飄Ⅱ 3U VCRVAL 期月 6-311 VCRVAL5(ÅÅ)12-2U VCRVAL25M)12-2U VCRVALE250()8-2U VCRVALEMHH)8-2U 2 石 BX (7N)rpm) 4TB M)(KGBX (72(H)rpm) 8. OTB 2 石 B x に ( 72 側「 pm ) 3. OTB 5(K)GB x に ( 7 当用「 pm ) 6. OTB 250GBX8 (72(H)rpm) 2TB (H)GB x 8 ( 7 川「 pm ) 4. OTB ¥ 829 , 500 ( 税込 ) ¥ 1 , 320 , 900 ( 税込 ) ¥ 732 , 900 ( 税込 ) ¥ 1 , 026 , 900 ( 税込 ) ¥ 543 , 900 ( 税込 ) ¥ 771 , 150 ( 税込 ) VCRVAIAM12/FC-2U VCRVAL2MHJ 12/FC-2U VCRVALMHÅ) 16/FC-3U VCRVALE2M)8/FC-2U VCRVAI„HK)16/FC-3U VCRVALFÄH)8/FC-2U ( FC モデル ) ( FC モデル ) ( FC モデル ) ( FC モデル ) ( FC モデル ) ( FC モデル ) %(K;BX に ( 7 次用「 pm ) 3. OTB に 6. OTB 川 (72(H)rpm) 8. OTB (M)GB x 8(72(H)rpm) 2TB 250GBX 16 (72(H)rpm) •ITB (H)GB x 8 (72(Å)rpm) 4. OTB ¥ 816 , 900 ( 税込 ) ¥ 1 , 121 , 400 ( 税込 ) ¥ 1 , 404 , 900 ( 税込 ) ¥ 659 , 400 ( 税込 ) ¥ 934 , 500 ( 税込 ) ¥ 855 , 750 ( 税込 ) ・最新情報 http 〃 www.jcsn.co.jp/ 〒 1 1 0-0008 東京都台東区池之端 2-6-5 JCS ビル intel premler ・この広告に掲載されている商品の価格及び仕様は予告なく変更する場合がございますのでご了承ください。

図 12 STREAMS 図 13 STREAMS のスタック ユーザー空間 カーネル空間 ユーザー空間 カーネル空間 stream head STREAMS ドライバ ムおよび STREAMS ドライバは、、 stream" と呼ばれ る双方向の通信チャネルで結ばれる。一般に、ユーザ ・プログラム側を、、上流 " 、ドライバ側を、、下流 " と呼 ぶ。ユーザー・プログラムとじかに接している部分 ( カ ーネル空間とユーザー空間の境目 ) が最上流で、ここが stream head" である。また、 stream の最下流には STREAMS ドライバがある ( 図 12 ) 。 おもしろいのは、 stream head とドライバのあいだに 、、 STREAMS モジュール " を押し込めることだ。たと えば、シリアルポートのさきに端末カ甘妾続されている場 合には、 ldterm (7M) と ttcompat ( 7 ) という 2 つ のモジュールが入っている。さらに、ホストマシンの日 本語文字コードが EUC で端末側が Shift-JIS であれ ば、文字コード変換モジュール jconvs (7M) を入れる ことで日本語が正しく扱えるようになる ( 図 13 ) 。ネッ トワークプロトコル・スタックも同じように実装できる。 ドライバの上に ip(7P) モジュールを入れれば、 IP で の通信が可能になる。 このように、変換などのロジックは各モジュール内に隠 蔽される。そして、、、プロトコル・スタック " を構築する には、必要なモジュールを文字どおりスタック (stack : 積み重ねる ) するだけでよい。 また、 STREAMS には、、多重化ドライバ " というもの がある。これは通信チャネルの多重化を実現する仮想ド ライバで、上位、下位ともに複数の stream を接続し、 メッセージ奐をおこなうことができる ( 図 14 ) 。これ を利用すれば、ファイアウォールのフィルタ・モジュー ルなどが実装できる。 可変長メッセージを使ったデータ交換 データは、メッセージ・プロックに格納されてモジュー ル間を往き来する。つまり、たんなるバイトストリーム とは違って、データに論理的な区切りを含めることがで 90 stream head ttcompat(7M) Idterm(7M) jconvs(7M) tty ドライバ STREAMS モジュー丿レ STREAMS ドライバ きる。メッセージのデータ長は可変で、各モジュールで 変換などの謝奐えが可能である。プロトコル・モジュー ルであれば、ヘッダとチェックサム・コードの追加と除 去をするだろうし、暗号化モジュールならデータの暗号 化と復号ができる。 ・フロー制御機能をもつメッセージキュー 各モジュールには、 stream ごとにメッセージを受け付 ける入口が 2 つある ( 下流向けと上流向け ) が、 メッセージキューがある。このキューの状態はほかのモ ジュールから確認できるので、事実ー E 、モジュール間で フロー制御が可能になる。また、内部制御メッセージな どはフロー制御の対象から外すこともできる。 STREAMS フレームワークにおいて、ネットワーク・ デバイスドライノヾは STREAMS ドライバに位置づけられ る。また、 STREAMS ドライバはデバイスノードを作成 するが、 こからデータを生のままやりとりするのではな く、、、 DLPI (Data Link Provider Interface)"4 という インターフェイスを使う。 DLPI は、通信サービスを提供 する側 (Ethernet ドライバなど ) と、そのサービスを利用 する側 ( ユーザー・プログラムや ip モジュールなど ) との あいだのプロトコルであり、さまざまな通信形態を考慮し たものである。だが、すべての通信形態について説明する 4 http://www.opengroup ・ org/pubs/catalog/c811. htm UNIX MAGAZINE 2005 . 12

特集 UN Ⅸデバイスドライバ [ 2 ] 図 11 net-device 構本 ( 一部 ) struct net_device / * P0inters to interface service routines . #define HAVE_SET_MAC_ADDR i nt i nt i nt #define HAVE_MULTICAST void i nt int #define HAVE_PRIVATE_IOCTL (*open) (struct net—device *dev) ; (*stop) (struct net_device *dev) ; (*hard—start—xmit) (struct sk—buff *skb, struct net—device *dev) ; (*set_multicast_list) (struct net_device *dev) ; (*set—mac—address) (struct net—device *dev, void *addr) ; (*do_ioctl) (struct net_device *dev, struct ifreq *ifr, int cmd) ; ったりして、混乱に輪をかける。最大の問題は、内部イン ターフェイスのドキュメントが皆無であり、 net-device 構 造体のなかでドライバが触ってよい部分とそうでない部分 を見分けるのカ攤しいことだ。 Ethernet で TCP/IP をサポートすることに限定すれ ば、実例か豆量たし、比較的分かりやすいだろう。以降は、 ヾは目れ当ーをヾ これに沿って話を進めていく。 Ethernet ドライバは、自身カ報う各デバイスごとに net -device 構造体を 1 つ作成する。図 11 に net-device の一 部を示す。 この図のドライバの動作において、デバイスの起動と停 止、バケット送信、およびデバイス・パラメータ設定の ェントリポイントが定義されているのが分かるだろうか。 open カゞデバイスの起動、 stop が停 1 ヒ、 hard-start-xmit がバケット送信、そして do-ioctl がパラメータ設疋であ る。このほかに、、、 Ethernet らしい " タスクのエントリポ イントもある。図の例では、 set-multicast 」 ist はマルチ キャスト受信リストの設疋、 set-mac-address はインター フェイスの MAC アドレスを設定する際に呼び出される工 ントリポイントである。 そして、 netif-rx() カーネル関数を用いて受信バケット をカーネルに引き渡す。 $LINUX/include/linux/net- device. h に下記のプロトタイプ宣言があり、関数本体は $LINUX/net/core/dev. c で定義されている。 netif—rx(struct sk—buff *skb) ; extern ドライノヾは、受信バケットごとに sk-buff 構造体を用意 UNIX MAGAZINE 2005. 12 し、バケットを各内したあとで netif-rx() 関数を呼び出せ ばよい 3 この項では、 Linux のネットワーク I/O 抽象化モデル のごく一部をみてきた。読者によって、舌足らずで技術的 な詰めが甘いとか、これだけでも食傷気味だ、といったよ うに評価が分かれるだろう。 とりあえずここでは、 ・入出力データを活用するユーザーは決められたかたちで 待ち受けている ・そのかたちには複数の種類がある ・ドライバは、対象とするユーザーに適したかたちでサー ビスを提供しなければならない ということを、頭に入れてもらえればと思う。 Solaris ネットワークの I/O 抽象イヒモデル Solaris のネットワーク I/O 抽象化モデルは、 Linux の それとはかなり異なる。さきに述べたとおり、 SoIaris で は、 SVR4 譲りの STREAMS という汎用的なメッセー ジ・パッシング機構を実装している。 STREAMS には以 下のような特徴がある。 ・プロトコル・スタックなどの実現に適したモジュール構 STREAMS の機構においては、ユーザー・プログラ 3 Linux カーネル 2.4 のどこかで netif-receive-skb() というインター フェイスカ噺設されたが、これを利用しているドライノヾはまだ少ない。 89

: UN Ⅸデバイスドライバ [ 2 ] UNIX におけるデバイス 特集 佐島隆博 前回は、 、、デバイスドライバとは何か " という問いに対 はない。新しいインターフェイスの公開後も、旧いもののサポー トがしばらく継続される。私の経 0 も、 Solaris 8 で作成した する 1 つの答を駆け足でみてきた。デバイスとその接糸研彡 ドライバが、再コンパイルのみで Solaris 9 や Solaris 10 で問 態、カーネル内でのみえ方、ドライバによる制御、入出力デ 題なく動作することが多い。 ータのやりとりなどの要素をかいつまんで説明したが、、、基 本概念の共有 " が目的だったこともあり、やや抽象的すぎた 、デバイス " の定義 かもしれない。 ーヨ殳的には、デバイスとは入出力装置のことである。た 今回は、デバイスが UNIX システムで具体的にどのよう しかに、マウス、キーポード、グラフィック・ディスプレイ、 に表れ、使われているのかを実例を挙げてみていく。まず 外部記億、ネットワーク・インターフェイスなど、実在す は、ユーザー側の視からみたデバイスというものがカー る大半のデバイスはデータ入出力装置だ。ただし、 UNIX ネル内でどのような未をもつのかを解説し、続いて、ド システムではそのかぎりではなく、 ライバとカーネル間のインターフェイス (Driver-Kernel ・機能を、、データ入出力 " という概念に抽象化できるもの lnterface) について述べる。 なら、なんでもデバイスとなりうる とりあげる例 のである。なかには、 /dev/null のような実体のないデバ イス ( 仮想デバイス ) もある。有形無形にかかわらす、すべ 世の中で、、 UNIX" と一言で束ねられている OS に共通 てのデバイスには対応するドライバが必要だ。 しているのは、 POSIX 仕様で定められている上位層イン ドライバには、 2 つの役目がある。 1 つはデバイス・ハ ターフェイスだけであり、カーネル自体の実装や内部イン ードウェアの制御、もう 1 つはデバイスの機能をカーネル ターフェイスはそれぞれに異なっている。この特集では、 やユーザーが活用できるようにすることである。後者につ Linux と SoIaris を、それぞれフリーと商用の UNIX の いては、カーネルカ誤定しているいくつかの、、 I/O 抽象化 例としてとりあげる。文中に示すソースコードは、 Linux モデル " にあてはめなければならない。 I/O 抽象化モデル 2.6.13.4 と SoIaris 10 用のドライバから抜粋したもので とは、たとえば、デバイスに対する open ( 2 ) と close(2) ある。また、とくに断らないかぎり、コマンド出力は X86 が叮能で、 ioctl ( 2 ) によってデバイスのパラメータを設疋 版 Fedora core 2 と SPARC 版 Solaris 10 のものであ し、 read(2) と write(2) で 1 オクテット単位のデータ る。、、 $LINUX" という表記は、 Linux カーネルのソース 奐ができる、というような定義のことである。この例が、 ツリーのトップ・ディレクトリを示す。 シリアルポートのようなキャラクタ・デバイスに適用でき ることカ吩かるだろうか。 さすか用 OS というべきか、 Solaris のドライバ用インタ 要するに、ドライバしだいでユーザーからのデバイスの ーフェイスは、その多くが公開されている。これらのインターフ 見え方カ畯わるということだ。 Solaris では、ほばすべて ェイス定義はメーカーによりサポートされ、頻繁に変更されること 81 UNIX MAGAZINE 2005. 12

連載 / Ⅲ v6 の実装ー 0 図 4 メッセージの始点アドレスと終点アドレスび忍 869 870 871 872 873 874 875 883 884 885 mbu = mip6—bu—Iist—find—home—registration(&hif—>hif_bu_Iist , if if &ip6—>ip6-dst) ; (mbu = NULL) { error = EINVAL; goto freeit ; ( ! IN6_ARE_ADDR_EQUAL (&mbu—>mbu_paddr , &ip6->ip6_src) ) { error = EINVAL ; goto freeit ; ( (caddr—t) ip6 + off) ; 833 行目で、 ip6 変数に IPv6 バケットの先頭アドレ スを設定します。そして、 835 行目の IP6-EXTHDR- CHECK() でメッセージ全体が連続メモリ領域に配置さ れているかどうかを確認します。連続メモリ領域に格納さ れていない場合、メッセージの内部情報にポインタ経由で アクセスできなくなります。 IP6-EXTHDR-CHECK() のなかで検証に失敗したら、 EINVAL 工ラーが返されて 関数を終了します。 848 849 850 851 852 853 / * find mip6—ha instance . * / mha = mip6—ha—1ist—f ind—withaddr ( &mip6-ha—1ist , &ip6—>ip6-src) ; if (mha = = NULL) { error = EINVAL ; goto freeit ; 860 } 856 行目の hif-list-find-withhaddr() は、引数として 渡されたホームアドレスに関連するホームネットワーク・ インターフェイスへのポインタを返します。移動ノードが 送信した要求メッセージの始点アドレスは、移動ノードの ホームアドレスに設疋されていました。よって、対応する 応答メッセージの終点アドレスは、そのホームアドレスで あるはずです。もし、応答メッセージの終点アドレスに指 定されているホームアドレスに対応するホームネットワー ク・インターフェイスがなければ、そのホームアドレスは 不正なアドレスとみなせます。 862 / * sanity check. * / if (hif—>hif_location ! = 863 864 865 866 HIF_LOCATION_FOREIGN) { / * MPA is processed 0 Ⅱ ly we are foreign. * / error = EINVAL; goto freeit ; 849 行目の mip6-ha 」 ist-find-withaddr() は、引数と して指定されたアドレスが、移動ノードが知っているホー ム・エージェントのものかどうかを調べ、そうであればホ ーム・エージェント情報を十帑内している構造体 (mip6-ha 構造体 ) へのポインタを返します。移動ノードは、そもそ も自分が登録しているホーム・エージェントにモバイル・ プレフィックス要求メッセージを送信したのですから、そ の応答として返送されてくるモバイル・プレフィックス応 答メッセージの始点アドレスは、移動ノードのホーム・エ ージェントのアドレスになるはすです。対応するホーム・ 工ージェント情報がみつからなければ、受信したバケット は不正なバケットとみなせます。 855 856 857 858 859 / * find relevant hif interface . * / hif = hif_list-find-withhaddr( &ip6->ip6-dst) ; if (hif = = NULL) { error = EINVAL ; goto freeit ; UNIX MAGAZINE 2005. 12 867 } 863 ~ 867 行目は、出先ネットワーク以外でモバイル・ プレフィックス応答メッセージを受信したときの処理です。 出先ネットワーク以外 ( すなわち、ホーム・ネットワーク ) での応答メッセージの受信はエラーとして処理されます。 869 ~ 885 行目 ( 図 4 ) は、受信したモバイル・プレフ イックス応答メッセージの始点アドレスと終点アドレスの 組が正しいかどうかを調べています。モバイル・プレフ イックス要求メッセージは、移動ノードが登録しているホ ーム・エージェント宛に送られます。その応答となるメッ セージも、登録先のホーム・エージェントから返送されて こなければなりません。 869 行目の mip6-bu-list-find- home-registration() で、応答メッセージの終点アドレス ( 移動ノードのホームアドレス ) に対応する対応付け更新エ ントリを検索します。さらに、検索されたエントリに設定 97