表 2 今月紹介した RFC MIME RFC2183 インターネット・メッセージを介したプレゼンテーション情報の伝達・ ールド . Content-Disposition ヘッダフィ RFC2184 MIME ノ、ラメータ値および匐 : 号イし吾孑劇長 : 文字集合、言語、継続 インターネット・キャッシュプロトコル (ICP) 第 2 版 RFC2186 ・ ICP 第 2 版の利用法 RFC2187 IMAP IMAP URL 体系 RFC2192 IMAP4 のメールポックスの回送機 : RFC2193 単純なチャレンジーレスポンスによる IMAP/POP の認正 (AUTH) 拡張について RFC2195 その他 インターネットにおけるホワイトページ・サービスの需要について RFC2148 IPv6 への移行・の観点からみた糸各制御 RFC2185 AT&T/Neda による ESRO (Efficient Short Remote Operations) フロトコルイ様第 1.2 版 RFC2188 H. 263 ビデオストリーム用の RTP ペイロード・フォーマット RFC2190 VENUS : 刻長性の高い非ユニキャスト・サーヒ、ス RFC2191 群を利用できるように MARS モデルを拡張するもので RFC2022 て提唱されている MARS モデルは、 ATM を介した LIS (Logical IP Subnet : 言紲里 IP サプネット ) ある。 仮想自勺なプロトコルといっても、もちろん将来的には標 間で IP マルチキャストをおこなう方法として、 IP マルチ 準として制定されることを目的としているのはいうまでも キャスト・ノヾケットの転送に Point-to-MuItipoint SVC (Switched Virtual Connection : スイッチドイ反想コネ ない。 クション ) を利用する手法を提案している。 MARS では、 LIS 間のマルチキャスト中幻医はマルチキャスト・ルータに よっておこなわれる。この転送は RFC1577 で定義され ている CIassical IP over ATM モデルが LIS 間のユニ キャスト・トラフィックの転送にルータを利用する手法と はは 1 司しである。 NHRP (NBMA Next Hop Resolution Protocol : NBMA 次ホッフ解決フロトコル ) 2 は、 IP ルータをバイ パスする転習各の探索およひ管理のためのプロトコルで ある。 NHRP 的なオ冓をマルチキャストでも利用できる ようにしたいという要望は多いが、 IP マルチキャスト・ サーヒ、スは IP ュニキャスト・サービスとくらべて複雑で あるため難しい。このような機能を実現するための力法や 考え方にはさまざまなものがあり、どの去がよいかにつ いてはいまだに言侖の彳せ也が多い。 そこで、目的を実現するには何を検討し考察しなけれ はならないのかを具体的に考えるために、 RFC2191 で は仮想的なプロトコルとして VENUS を提案している。 VENUS は、複数のサプネットから構成されるクラスタ 2 見在、規翻リ定中である。 I-D (draft-ietf-rolc-nhrp-ll. txt 以ーい を参 ! のこと。 まとめ 今回扱った RFC を表 2 にまとめる。 次号では、 9 月中旬から 10 月中旬にかけて公開された RFC を紹介する。 RFC の読み方についても、引き続き 見明する予定である。 ( うお・ようしろうびを先端科 : 物麪付大完大学 ) 二二ロ 94 UNIX MAGAZINE 1997.11

連載 /NET WORTH—O 表 2 NFS のトラブルシューティング・ツール ツール名 リモートホストの RPC サーピスを詩ヾる rpcinfo 公開されているファイルシステムを表小する showmount ネットワーク・バケットのキャプチャおよひプロトコル・アナライサ SIIOOP ネットワーク・バケットのキャプチャおよひフ。ロトコル・アナライサ tcpdump ティリティとプロトコル・アナライサである。さいわいに テムは、さらに呼出しを続ける。 FTP/NCD のサーバー は、再送を 3 回繰り返したあと、応答を返さなくなるが、 も、大部分の UNIX システムには、ルートユーサーが使 SoIaris マシンは、 3 回目以降もさらに呼出しを続け、応答 える tcpdump や snoop に似たなんらかのツールが入っ ている。 snoop ユーティリティは、 Solaris 2. x に含まれ がなければマウントに失敗する。これは、 Solaris と FTP InterDrive Server の両方のバグである。 ていて、 NFS プロトコルや関係ある RPC プロトコルの 角斤に優れている。 tcpdump ユーティリティは、 DIG- lntergraph の Disk Share は、 Windows NT 用の ITAL UNIX や大部分の BSD 系 UNIX システムに入っ NFS サーバーのなかで、唯一期待どおりに Solaris 2.5 と 重川した製品だった。また Disk Share は、 NFS version ている。 tcpdump のソースコードは、 ftp://ee.lbl.gov/ 3 に対応して 0 、る唯一 0 NT NFS サー , 、一であり : TCP から入手できる。 を使うと大きなバケットサイズ (64KB まで ) で言丿曲しや NT NFS サーバーの欠点 書込みの要求・応答をおこなうこともできる。 Esker 、 Sun Microsystems 、 WRQ などいくつかの これらの NFS サーノヾーを使って明らかになった、その べンダーは、 Windows NT 用に新たな NFS サーバーを 他の欠点や間題点を挙げておこう。 開発している。山も広 Open Group は、 NFS のスペック を記した『 X/Open lnternetworking: XNFS, Version Frontier の SuperNFS は、サー ・マ不一ジャー を起動し、ファイルの公開やユーサー名と UID の対応 3 』を出版した。この本では、 NFS version 2 と version 表の設定をおこなうと問題が生した。 Hummingbird の 3 の両方についてⅱ当されており、 lnformational RFC Maestro は、読出し専用でファイルシステムを公開した についても触れられている。この本の真価は、 NFS のサ ーピスモデルとその補助フロトコルである mount 、 lock ときだけ SoIaris からマウントできた。 manager 、 status monitor について」べていることにあ NetManage の NFS サーバーでは、アクセス ( 読み書 る。これについて言当されている本ははかに存在しない。 き両方または読出し専用 ) の制御をおこなえない。ルート の UID が NT Administrator に対応つ、けられたときだ け、 SoIaris からマウントできた。ファイルサイズは正し く表示されるが、ディレクトリ・サイズ (UNIX の du コ マンドで分かる ) は、実際の半分の大きさか表示された。 FTP Software から出ている InterDrive NFS Server (NCD にライセンスされている ) は、読出し専用のファ イルシステムへのアクセスを制限することができない。こ れらの製品のトラブル・シューティングがもっとも大変 だった。 Solaris 2.5 は、 NFS version 2 でファイルを マウントする際、少々間題のある RPC 呼出しをおこな う。 Solaris は、マウント用のファイルハンドルを得たあ 「 NFS On NT 」 UNIX REVIEW 1997 年 6 月号より とで、どの NT サーバーでも対応していない NFS-ACL サーバーを呼び出す。 FTP/NCD NFS サーバーがこの ◎ 1997 , UNIX REVIEW (). S. A. ) RPC サーバーは利用できないと応答すると、 Solaris シス ☆ べンダーからパッチおよびノヾグフィックスされた製品 を入手したら、性能を中心に再度 Windows NT の NFS サーバーについて述べよう。それでは次回まで、間題の多 い W ⅲ d 。 ws の面倒をしつかりみてあげよう。 ・ M. Steven Baker 州の建物のエネルギー管理をおこなうオレゴン州エネルギー省勤務。 programmer's JournalJ のノび扁集者であり、 rExtending DOS の著者の 1 人でもある。 148 UNIX MAGAZINE 1997 ユ 1

ートーの 連載 FreeBSD ノ 写真 2 高速シリアルポード NAT dial on demand のノ、ツチのうえにさらに NAT 機 能を追加したものが、佐藤淳一さんの WWW ページ (http://www.jp.freebsd.org/-junichi/) に公開され ている。以下、 NAT についても簡単にみておこう。 NAT (Network Address Translatoro RFC1631 ) は、 IP の ネットワークでアドレスを付け替える仕組みのことであ る。 NAT そのものは、 PPP にかぎらす利用できるが、 こでは PPP の場合に限定して説明する。 らかしめリストしておいて、バケットの中身の IP アドレ PPP で ISP にダイヤルアップ IP 接続する場合、通常 スまで書き換えて利用可能にしているものが多い。 インターネットにアクセスできるのは PPP 接続している NAT と同様のものとして、 IP masquerade という用 マシン ( これを A とする ) だけで、手前の LAN のはか 語もある。基本的には NAT の - 一種と考えてよいだろう。 のホスト (B とする ) からは直接アクセスできない。この NAT は、 RFC ではごく基本的な機能しか規定されてい ようなホストからインターネットを利用するには、 proxy ない。そこで、機能を追加したものを NAT と区別して IP を用意する去などがあるが、アプリケーションごとの対 masquerade と呼ぶ人もいる。しかし、 NAT の実装には 応になるので柔車層生に欠けるきらいがある。 たいてい、いろいろな機能が追加されているので、現実的 どうしてこのようなことか起こるかというと、こちら側 には区別してもあまり意床がない。このはか、メーカーに の LAN にバケットを送るための情報がインターネットに よっては NAT の変種にさまざまな名前を付けて呼んでい は通知されないからである。そのため、インターネット上 る場合がある。 のホストから B ( ンヾケットを届けることができす、 B か 高速シリアルポード らのネットワーク接続が成立しない。一方、 A は ISP の ネットワーク・アドレスをもらっているために、 A から ISDN は 1 回線あたり 64Kbps の通信か可能であるが、 ならインターネット妾続できるわけである。 MP (PPP Multilink Protoc010 RFC1990 ) で 2 本ま NAT では、 B からインターネットへ送られるバケッ とめて 128Kbps として利用できる TA か増えてきてい トに含まれる IP アドレスを A のアドレス (ISP からも る。さらに BAP (PPP Bandwidth Allocation Pro- らったもの ) に、ポートの番号を A で使われていない適 tocolo RFC2125 ) により、接続に利用するチャネル数を 当なポート番号に付け替えてインターネットに送る。刊替 自重加勺に埔成できるものもある。いすれも、接続相手が対 えの内容はテープルに保存しておく。 応していることが必要である。 逆に、インターネットから A に送られてきたバケット AT 互換機の通常のシリアルポートは通信速度の上限が は、ポートの番号をテープルと照合する。 B からのバケッ 115.2Kbps なので、 ISDN 回線を 2 本利用する場合は転 トの書換えに使ったポートであることカ吩かると、バケッ 選度が追いつかない。このような場合は特別な高速シリ トの宛先の IP アドレスを B のアドレスに書き換えて B アルポードが必要になる。 に送る。このようにして、本来インターネットか利用でき 現在数種類が市販されている ( 写真 2 ) が、どれも ない環境からもアクセスが可能になる。 FreeBSD ではサポートされていない。前述の佐藤さん のページには、高速シリアルカードを利用するためのパ NAT は便利だが、プロトコルのなかには NAT 経由で ッチがいくつか公開されている。現在、これを統合して は利用できないものもある。本来は不要な IP アドレスを FreeBSD の配布に組み込むための乍業が進行中とのこと バケットのヘッダだけでなく、中身にも入れて送信するよ なのて期待したい。 うなプロトコル (FTP など ) がこれに該当する。 NAT 対 シリアル・インターフェイスか第された当時は、高速 応のソフトウェアのなかには、こういったフロトコルをあ - 川田 154 UNIX MAGAZINE 1997.11

ここだわる 皿極めたい ソフト技術者 「面白い会社ですね」とよく言われます。 至って真面目な会社ですが 「快社生活」を送る社員は知っています。 「就社」でなく「就職」する会社。 それがトウール社です。 私たちは 産業用のアプリケーション・ソフトウェアを開発、製造、 販売する会社です。競争力を保持するため、ニつのセ グメントを大切にしています。 1 ) 社内ネットワーク開発環境の整備 2 ) 工ンドユーザとの強力な技術開発バートナーシップ コア技術はデータベース、ネットワーク、画像処理、リア ルタイム OS 、 EDAetc. です。 具体的には ・半導体メーカーの内製 CAD ソフトの受託開発 ・自社開発論理波形工デイタ WAVES の開発、販売 ・ネットワーク画像ファイリングシステムの開発 ・リアルタイム 0 号による、システム開発 ・マルチメディア・コンテンツの制作 etc. このような仕事をやっています。 ・会社概要 【設立い 970 年 4 月【資本金】 2 冊 0 万円 【従業員数】 44 人【売上高】 5 億 30 開万円 ( 8 年実績 ) ・募集要項 【資格】 35 歳位迄のソフト開発経験者【給与】経験・能力を考慮の上、 当社規程により優遇します。当社は能力・実績主義給与体系を採用し ています。年収モデル : SE30 歳専門卒 / 640 万円以上 ( 固定月収 40 万円 ) 【待遇】昇給年一回、賞与年 2 回、交通費全額支給、社会保 険完備、各種制度充実しています。クラブ活動 ( テニス・ゴルフ ) 、従業 員持株制度、リフレッシュ休暇制度 ( 勤続 10 年で特別休暇 5 日と報奨 金 50 万円支給 ) 、住宅借入金利子補給制度、 90 年度企業ゆとり度診 断で通産大臣賞を受賞しています。 【勤務地】中目黒【勤務時間】フレックスタイム制 ( コア川 : ~ : oo ) 標準労働時間 7 時間【休日休暇】完全週休 2 日制 ( 土・日 ) 、祝日、 年末年始・夏期・有給・慶弔・特別・誕生日休暇。 【応募】電話連絡の上、履歴書 ( 写真添付 ) 、職歴書を持参ください。 【交通】東横線中目黒駅より徒歩一分。 ・問い合わせ先 管理部採用担当 / 内田・高橋 電話 ( 03 ) 5723- 別 46 E-mail Saiyou@tooI.co.jp くホームページ U Ⅲ ) http://www.sun.co.jp/smi.jp/www-catalyst/tool/ 株式会社トウール社 〒 153 東京都目黒区上目黒 3-3 ー 14 TEL ( 03 ) 5723-8123 資料請求 No ℃ OB 147 UNIX MAGAZINE 1997.11 ノ、 連載 /NET WORTH—O ツールは、ネットワーク・バケットをキャプチャするユー NFS のトラブル・シューティングでもっとも価値のある ストを調べる showmount がある。 ルシステムやプリンタ、およびそれらにアクセスできるホ mount デーモンに問い合わせて、公開されているファイ ほかの役に立つツールとして、 NFS サーバー上の RPC としていたが、 mount は相変わらす拒否されていた。 く UDP の 111 番ポートで portmapper に接続しよう た。 Solaris と DEC NFS の mount コマンドは、運よ 続を試みており、それが Omni-NFS での失敗の原因だっ UNIX 版の rpcinfo はます TCP の 111 番ポートに接 コル・アナライサを使った結果、 Solaris と DIGITAL ーバーでは、 rpcinfo による情報収集に失敗した。プロト サーバーを調べることである。 XLink の Omni-NFS サ info を使って NT NFS サーノヾー上で動いている RPC NFS のトラブル・シューティングの第 1 段階は、 rpc- 使用されるポート番号を表示する ) 。 べてくれる ( プログラム番号、バージョン、プロトコル、 し、そのホストで動いているすべての RPC サーバーを調 ティリティは、あるホストマシンの portmapper に接続 使われているプログラム番号の一覧がある。 rpcinfo ユー テムの /etc/rpc ファイルには、 Sun か割り当ててひろく しているポート番号か登録される。大部分の UNIX シス 番号、プロトコル (TCP や UDP が一勺 ) 、使おうと の RPC プロトコルに割り当てられた番号 ) 、バージョン が UNIX システムで動きだすと、プログラム番号 ( 特定 べる。 mountd 、 nfsd 、 nlockmgr などの RPC サーノヾー RPC プロトコルカ硬う TCP や UDP のポート番号を調 を呼び出し、リモートマシンで動いているこれらのほかの ルは portmapper ( つねに 111 番ポートで動いている ) ロトコルを動かさなけれはならない。これらのフロトコ (lock マネージャー ) 、 NFS 本体などいくつかの関連プ ばれている ) 、 mountd (mount デーモン ) 、 nlockmgr で portmapper 仕も匠のノヾージョンは RPCBind と呼 NFS でファイルを共有するには、 NFS サーバー上 ー製品に含まれているものもある。 て利用可能であり、 NT NFS のクライアント製品やサー 役立つツールの一覧を挙げる。これらは、 UNIX システム なった。表 2 に、 NFS のトラブル・シューティングに ル・シューティングに役立つツールを探さざるをえなく 盛しています

NETWORKTECHNOLOGY 2 図 2 ATM ルータの動作 テータリンク層 tO Ethernet Ethernet フレーム ネットワーク ( 旧 ) 層ー ↑ next hop が Ethernet 上にある場合 ノレーティング ネ、 , トワーク ( 旧 ) 層ー AAL 層 ATM 層 next hop が ATM cloud にある場合 旧テータグラム segmentation reassembly ATM 物理層 PDU : プロトコルデータ・ユニット 26 1 従来の非 ATM LAN を Legacy LAN という場合があります。 工ッジデバイスは通信を開始する前に、工ッジデバイス間 ATM はコネクション指向の通信プロトコルであるため、 す。 フェイスを NNI (Network Network lnterface) といいま UNI (User Network lnterface) 、スイッチ間のインター なお、工ッジデバイスとスイッチ間のインターフェイスを に送出します ( 図 2 ) 。 一度バケットをセル化 (segmentation) して ATM cloud の先の場合 ( たとえばホスト 1 → RI →ホスト 2 ) 、もう 5. 経路制御の結果、そのバケットの宛先が ATM cloud の場合はバケットをそちらに転送します ( 図 2 ) 。 4. 経路制御の結果、そのバケットの宛先が Legacy LAN 3. バケットに戻したあと、経路制御をおこないます。 ットに戻します (reassembly)o 2. ATM cloud から受信したセルはすべていったんバケ ル化して ATM cloud に送出します (segmentation)o 送する場合は、 Legacy LAN から受信したバケットをセ 先 ( たとえばホスト 1 ) にあるネットワークにバケットを転 1. Ethernet などの非 ATM LANI から ATM cloud の にデータ通信用のコネクションを確立する必要があります 2 。 コネクションには、管理者が手動でコネクションを張る PVC (Permanent Virtual Connection) と、必要に応じ て動的にコネクションが張られる SVC (Switched Virtu- al Connection) があります。 SVC を張るのに用いられる プロトコルをシグナリング・プロトコルといいます。 UNI 、 NNI のそれぞれで用いられるシグナリング・プロトコルもま た、 UNI 、 NNI と呼ばれます。今回と次回は UNI につ いて解説します。 2 1 対 1 のコネクションを point - to - point コネクション、 1 対多のコネクシ ョンを point-to-multipoint コネクションといいます。 工ッジデバイスと ATM cloud ATM ルータ、 ATM ブリッジ、 ATM インターフェイス をもつホストは ATM 工ッジデバイス ( 端点デバイス ) と 呼ばれます。この名前は、これらのデバイスが " つに ATM スイッチによるネットワークの末端に存在する " と ころからきています ( 図 D 。工ッジデバイスに対して、 ATM スイッチによるネットワーク ( 図 1 中の円内 ) は "ATM cloud (ATM 雲 ) " と呼ばれます。 UNIX MAGAZINE 1997 ユ 1

連載 UNIX Communication Notes 表 2 プロトコル番号とヘッダタイプの定義 値 0 0 1 2 2 3 4 5 6 17 29 43 44 45 51 52 59 60 80 88 89 255 キーワード ICMP IGMP ICMP GGP IP ST TCP UDP ISO-TP4 IDRP AH ESP ISO-IP IGRP OSPF ヘッダタイプ reserved ) Hop-by-hop options Encapsulating Security PayIoad header Authentication Header lnterdomain Routing Protoc01 Fragment Header Routing Header ISO Transport Protocol Class 4 User Datagram Protocol Transmission Control Protocol St ream Protocol IP ⅲ IP (IPv4 encapsulation Gateway-to-Gateway Protoc01 lnternet ControI Message Protocol lnternet Group Management Protocol lnternet Control Message Protocol reserved ) Open Shortest Path First IGRP ISO CLNP Destination Options header No next header IPv4 の拡張機能力鞄える問題は、一ものように ・オプション使用時の性能劣化 ・オプション領域の短さに起因する孑鳳生の低さ の 2 つに集約できる。これへの対応として、 IPv6 ではオ プション機能の実現のために比、、ツダという欟冓を導入 し、拡張生を高めて処理生能の低下を防ぐ構造とした。 拡張ヘッダの順番 図 3 に示したように、拡リを、ツダは、 IPv6 ヘッダとペ イロードとのあいだに入れられる。複数の拡リ、ツダカ咐 けられることもある。そして、 IPv6 ヘッダと拡リ、ツダ に用意された次へッダ・フィールドによって、次に↑絲勺 されているヘッダを指しバす構造になっている。拡リ、ツ ダの最後の次へッダ・フィールドは、一 E 位層プロトコル である TCP ヘッダを指すようになっている。このため、 IPv6 ヘッダおよび拡リッダの次へッダ・フィールド には、 IPv6 の拡張ヘッダの番号か、 TCP や UDP と いった上位層プロトコルのプロトコル番号を成疋する。そ こで、 IPv6 の拡リを、ツダ番号は、既存のプロトコル番号 と衝突しないように定義された俵 2 ) 。 UNIX MAGAZINE 1997.11 IPv4 IPv6 IPv4 IPv4 IPv6 IPv4 IPv6 IPv6 IPv6 IPv6 19 ・ルーティング・ヘッダ (Routing Header) tions Header) ホップごとのオプション・ヘッダ (Hop-by-hop op- 現在のところ、 IPv6 の才髦、ツダは次の 6 不鶤頁である。 不頁 ダの無駄な評価を避けることができる。 ヘッダを評価する必要はない。この樹冓により、拡リッ くてもよい次へッダ・フィールドがあれは、それ以降の の順番カ義されているため、処理モジュールを起動しな ルを起重丿ける必要があるかどうかを判断する。刻ッダ ダ・フィールドを参照し、次の才を、ツダの処理モジュー ノードで拡リを、ツダを調襾するときは、ヘッダ内の次へッ そこで、拡張ヘッダの付加の順番が定義された。中継 での処理効率の劣化か防げる。 ればならない拡リを、ツダがまとめられていれば中継ノード 処理が必要とされるものだけである。さらに、処理しなけ れるわけではない。終点ホストと中継ノードで扱うのは、 すべてか終点ホストと糸糾 : の任意の中継ノードで処理さ IPv6 の拡リッダは始点ホストで設定されるが、その

・編集ー E の変史 である。 UNIX MAGAZINE 1997.11 でキャッシュがイ尉寺している URL についての情報を交 バー間で用いられるプロトコルである。隣接キャッシュ間 る ) で利用されているインターネット・キャッシュサー は Hervest や squid という名則で知られるシステムであ ICP は、 WWW のキャッシュ・システム ( 有名なの 年 9 月 5 日に公開されている。 ている。双方とも、、広報 (lnformational)" として 1997 ICP (lnternet Cache Protocol) の第 2 版について述べ WWW のキャッシュ・システム間プロトコルである 旧 fo. 、 D. Wessels ICP 第 2 版の利用法 (ICP), version 2 RFC2187 Application oflnternet Cache Protocol fo. 、 D. Wessels インターネット・キャッシュプロトコル (ICP) 第 2 版 RFC2186 lnternet Cache ProtocoI (ICP), version 2 、、Ⅵ石関連 ている。 を、文字集合と同様に明示できるようにする才長も含まれ また、 RFC2047 で定義されている符号イ韶 ) 表小言語 値の継読樹冓 3. ヘッダラインの折返しに対・応するための長いパラメータ 2. 表示するために利用すべき言言韶 1. US-ASCII 以、タ ) 文字集合の孑 対して、以下の刻長を加えるための手法を提案している。 イプおよび RFC2183 における拡張パラメータイ直機構に RFC2184 は、 RFC2045 で定義されているメディアタ 月 11 日に公開された。 る。現在の状態はゞ、標準化への提唱 " である。 1997 年 9 MIME のパラメータ値と符号化語の拡張を定義してい PS. 、 N. Freed ( RFC2045 更新 ) 語、継続 MIME パラメータ値およひ詩号化語拡張 . 文字集合、言 Continuations Word Extensions: Character Sets, Languages, and RFC2184 MIME Parameter Value and Encoded RFC ダイジェストー② IMAP RFC2192 IMAP URL Scheme IMAP URL 体系 PS. 、 C. Newman IMAP (lnternet Message Access ProtocoI) サー ーに関する資源を URL 表記にマッピングするための体 系について述べている。現在の状態は、、標準化への提唱 " である。 1997 年 9 月 11 日に公開された。 IMAP は適隔地にあるメッセージにアクセスするため の咼機能なプロトコルである。個人的なメッセージや共有 メッセージだけでなく、公開されているメーリングリスト のアーカイプへのアクセスに対しても優れた機能を提供す ることかできる。 RFC2192 ではこのようなさまざまな用途を見越して、 適隔地にある IMAP サーバーのリソースを URL として 表記する方法について述べている。これは、次に紹介する RFC2193 で他の IMAP サーバーを指定するためにも利 用されている。 RFC2193 lMAP4 Mailbox Referrals lMAP4 のメールポックスの回送冓 PS. 、 M. Gahrns IMAP4 のメールポックスの回送機構を提案している。 現在の状態は、、標準化 , 、ク是唱 " である。 1997 年 9 月 12 日に公開された。 多数のユーサーやメッセージ、およびたくさんの分散 した IMAP4 サーバーがある場合、 1 つの組織中でも複 数のサーバー間でメッセージを伝達したいことがある。た とえは、管理者は利用者の個人メールポックスを他の共有 リモートサーバユ上に置く代わりに、ローカルの IMAP4 サーバー上に置くことを j 尺するかもしれない。この種の 設疋は、すべてのデータを集約することがネットワークの 換し、要求されたオプジェクトの取得先を決定するために 利用される。 RFC2186 では ICP 第 2 版のフォーマットだけを述 べており、 WWW キャッシュへの適用については次の RFC2187 て扱う構成になっている。 フォーマットの詳細については RFC 本文を参照して ほしい。 89

NETWORKTECHNOLOGY 2 す。工ンコーディングは BCD です。 ・ E. 164 E. 164 は ISDN 番号 ( 電話番号を含む ) です。ェンコ ーディングは BCD です。 DSP (Domain Specific Part) DSP は HO-DSP (High Order DSP) 、 ESI (End sys- tem ldentifier) 、 SEL (SeIector) からなります。 ・ HO-DSP HO - DSP は IDP で指定された機関によって割り当てら れるアドレスで、 RFC1237 で規定される階層化が可能 です。階層の境界は可変です。Ⅱ () - DSP の階層情報 は NNI における ATM スイッチ間の経路で用いられま す。 NNI については回を改めて説明します。 ・ ESI 経路ドメイン内で ATM 工ッジデバイスを識別するため に用いられる識別子です。その ATM デバイスの MAC アドレスが用いられます。 ・ SEL SEL は UNI 、 NNI におけるシグナリングでは用いられ ません。 LAN などの上位層で、 LEC (LAN Emula- tion C ⅱ ent ) などのプロトコルの実体を識別するために用 いられます。 なお、 IDP および HO - DSP は合わせてネットワーク・プ レフィックス (network pre ⅱ x ) と呼ばれます。 アドレスの登録 (ILM り ATM ネットワークにおいては、工ッジデバイスはネット ワーク・プレフィックスの情報をもっていません。工ッジデ ノヾイスは、起動時に自分が接続されている ATM スイッチ からネットワーク・プレフィックスを取得し、自分の MAC アドレスを SEL に設定することにより ATM アドレスを生成 します。また、自分の MAC アドレスを ATM スイッチに 登録します。これにより、 ATM スイッチはどの ATM ア ドレスをもつ工ッジデバイスと接続されているかを知ること ができます。この ATM アドレスの登録には lnterim Local Management lnterface (ILMI) というプロトコルが 用いられます 3 。 ILMI は AAL5 上に実装された SNMP です。 SNMP 3 version 4.0 から、 lntegrated Local Management lnterface という 名前に変わりました。 というと IP の UDP 上の実装が有名で、 IP 層がないのに SNMP が使えるのかと疑問に思うかもしれませんが、 SNMP 自体は上位層に依存しないプロトコルです。 ILMI の送受信では VPI/VCI として VPI=() 、 VC1=16 というチャネルが、 AAL として AAL5 が固定的に用いら れます。 ILMI を用いた ATM アドレスの登録の手順を図 4 に示 します。 1. 図 4 において、 ATM スイッチおよび工ッジデバイスは 物理ポートのリンクが切れた状態からリンクアップ (link u p ) を検出すると、アドレステープルを初期化して SNMP ColdStartTrap メッセージを送信します。 2. その後、 ATM スイッチおよび工ッジデバイスは互いの アドレステープルが空であることを確認するために Get - Next Request メッセージを工ッジデバイスに送信しま す。 3. ATM スイッチは、工ッジデバイスからの SNMP Re- sponse (valid) メッセージによりエッジデバイスのアドレス テープルが空であることを確認すると、自分のネットワー ク・プレフィックスを SNMP SetRequest メッセージに入 れて工ッジデバイスに送信します。 BCD (Binary-Coded Decimal) BCD は 2 進化 1 0 進数と訳され、 ] O 進数を 4 ビット の 2 進数で表す表記法です。通常の 2 進数では、 1 OOI の次は 1 01 0 ですが、 BCD では OOOI OOOO となりま す。 0 1 ワ 3 00 -4 " 0 「 / 8 -0 1 ワ 1 っ 0 -4 一 0 、 6 冖 / binary 0000 0000 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0000 1010 0000 1011 0000 1100 0000 1101 0000 1110 00001111 0001 0000 0001 0001 BCD 0000 0000 0000 0001 0000 0010 0000 0011 0000 0100 0000 0101 0000 0110 0000 0111 0000 1000 0000 1001 0001 0000 0001 0001 0001 0010 0001 0011 0001 0100 0001 0101 0001 0110 0001 0111 28 UNIX MAGAZINE 1997 ユ 1

連載 UNIX Communication Notes—O 図 3 次へッタ・フィールドによるヘッダのチェイン (a) 旧 v6 H eader Next Header = TCP 旧 v6 Header Next Header = Extension TCP Header + Data Extension Header TCP Header + Data Next Header = TCP う慴リ処理もおこなわれる。経路 MTU よりも大きな IP ット ( 正確には 65 , 535 オクテット ) だが、拡張ヘッダ フィールドで表現できるべイロード長は 64 キロオクテ ペイロード長フィールドは 16 ビットなので、この クテット ) を減したものになる。 IP データグラムの全長から単純に IPv6 ヘッダの長さ ( 40 オ ヘッダの長さも含まれる。したがって、ペイロード長の定義は、 拡張ヘッダが使われている場合、ペイロード長には拡張 意 1 ルドには 100 がセットされる。 120 がセットされる。一方、 IPv6 のペイロード長フィー ダは 20 オクテットなので、バケット長フィールドには ると、 IPv4 の場合は IP オプションがなければ IP ヘッ データ領域に 100 オクテットのデータかオ褓内されたとす をオクテット単位で表す。たとえは、 IP データグラムの ルドは、 IP データグラムのうち、 IPv6 ヘッダを除く長さ ものであった。これに対し、 IPv6 のペイロード長フィー 含む IP データグラム全体の長さをオクテット単位で表す IPv4 におけるバケット長フィールドは、 IP ヘッダも ペイロード長 その定義 ( 意味 ) も次のように変更された。 れぞれペイロード長、次へッダ、ホップリミットと改称さ ロトコルタイフ。、 TTL の各フィールドは、 IPv6 ではそ さきはど述べたように、 IPv4 におけるバケット長、プ フィールドの再定義 にの処理の諞田は後する ) 。 ホストでの再構成処理のために拡リを、ツダが付けられる グメントにうリし、そのフラグメントの識別およひ終点 データグラムを送る場合には、始点ホストで複数のフラ の、、 Jumbo Payload Option" を利用すれば、 長い IP データグラムも扱える。 16 これより 次へッダ IPv4 でのプロトコルタイプ・フィーノレドには、上位層 のプロトコル番号がセットされていた。この機能は、 IPv6 では次へッダ・フィールドで実現されているが、その構造 はまったく異なる。 IPv6 の次へッダ・フィールドは、そ の次にくるヘッダの不鶤頁を表す。 たとえは、図 3- ( a ) のように、 IP データグラムのデータ 領域に TCP バケットかオ内されている場合、 IP データ グラムの構造を : 麪頁から見ていくと、 IPv6 ヘッダの次に TCP ヘッダかオ褓内さその次に TCP セグメントデー タがある。このとき、 IPv6 ヘッダの次へッダ・フィール ドには、 TCP ヘッダを表す、、 6 " という値かオ褓内される。 一方、従来の IP オプションの機能を使うときは、図 3- ( b ) のように、う巨頁から IPv6 ヘッダ、孑比ッ久 TCP バケットの順にデータか並ぶ。このとき、 TCP?S ケット の直前にある才ッダの次へッダ・フィールドには TCP ヘッダを表す、、 6 " という値かオ内される。そして、最初の IPv6 ヘッダの次へッダ・フィールドには、拡リ、ツダ の不鶤頁を表す値かオ翻タされる。 このように、次へッダ・フィールドはヘッダの並びを 順番に表す樹冓だが、最終的には上位層プロトコルのヘッ ダを表す値がこのフィールドに絲タされるため、上位層プ ロトコルを表すことができる。 ホップリミット IPv4 での TTL フィールドの機能は、 IPv6 ではホッ プリミット・フィールドで実現されている。 始点ホストでは、このフィールドになんらかの値を設定 する。 IP データグラムを中継するゲートウェイでは、 刎直を 1 すっ減らしていき、経路途中でこのフィールドの 値が 0 になると、その IP データグラムは破棄される。 れは、現在おこなわれている IPv4 の TTL フィールドに ついての処理と同じである。それでは、なせ名前を変更し UNIX MAGAZINE 1997.11

NETWORKTECHNOLOGY 2 UNI ATM アドレス 通信するためには、通信をおこなう各デバイスをなんら かの方法で区別することが必要です。 Ethernet では MAC アドレスを用いて各ホストを区別しています。 ATM では、各 ATM デバイスを区別するために ATM アドレス を用います。 パプリック ATM ネットワークにおいては、 ISDN ( 電話 ) 番号である E. 164 が ATM アドレスとして用いられますが、 ATM LAN では ATM Forum の定めた 3 種類を ATM アドレスとして用います ( 図 3 ) 。 関を指定します。 IDP は以下の 2 つのフィールドをもって 3 種類の ATM アドレスは、いすれも以下に示す構造を います。 もっています。 ・ AFI (Authority Format ldentifier) IDP (lnitial Domain Part) DCC (Data Country Code) 、 ICD (lnternational DSP (Domain Specific part ) の値を割り当てる管理機 Code Designator) 、 E. 164 番号の割当て機関を示しま す。 AFI の長さは 1 オクテット、エンコーディングは BCD 図 3 ATM LAN の ATM アドレス (Binary Coded Decimal) です。現在、以下のコード DCC ATM Format が定義されています。 Network Prefix IDI および DSP のフォーマット AFI 39 DCC ATM フォーマット ICD ATM フォーマット 47 E. 164ATM フォーマット 45 ・ DCC (Data Country Code) DCC にはアドレスが登録された国を指定します。 DCC のコードには IS03166 に記載されているものを使用しま す。工ンコーディングは BCD です。 ・ ICD (lnternational Code Designator) ICD はアドレスを登録した国際機関を示します。 ICD は British Standards lnstitute によって管理されていま NNI の定義 本文では NNI を " スイッチ間のインターフェイス " と 説明しましたが、厳密には正確ではありません。厳密に は「 NNI プロトコルを用いる 2 つの ATM スイッチ間の物 理的、論理的リンク」です。というのは、図 ] のプライ べート ATM ネットワークとバブリック ATM ネットワーク を接続するスイッチのように、 ATM スイッチ間のプロトコ ルに UNI を用いる場合もあるからです。つまり、「 NNI はつねに ATM スイッチ間で用いられる」という命題は真 ですが、「 ATM スイッチ間で用いられるプロトコルはす べて NNI である」という命題はつねに真であるとはかき りません。 F DCC ESI HO-DSP ℃ D ATM Format Network Prefix F ICD ESI HO-DSP ・・旧い E. 164 ATM Format Netwo 「 k Prefix ATM アドレスと NSAP アドレス ATM アドレスは OSI で用いられる NSAP (Netwo 「 k Se 「 vice Access P0int ) アドレスと同様の構造をもって います。このため ATM アドレスは NSAP アドレスと呼ば れることがありますが、これは誤用です。 ATM アドレス は NSAP アドレスではありません。 ESI HO-DSP E. 164 ・・ IDP ・ 27 UNIX MAGAZINE 1997.11