図 2 rfc-index のヘッダ部分 ( 従来の形式 ) タイトル。 RFC I NDEX ← 09 / 19 / 1997 ←最終更新日 RFC ダイジェストー② このファイルが rfc ー index であることを示す This fi1e contains citations for a11 RFCS in reverse numeric order . RFC (Obs01etes RFC####) (Pages=##) (Format=. txt or Authors NUM STD "Tit1e of RFC" citations appear in this format : (Updates RFC####) ・ ps) lssue date . ( このファイル中にはすべての RFC が逆順に列挙されている。各項目の体裁は次のようになっている ) ファイルサイズを示す。テキスト形式の場合は、、 TXT" 、 PostScript 形式の場合は、、 PS" となる。形式を示す文字 列に続いて、、 = ファイルサイズ " か当される。 Obsoletes と Obsoleted by 、 Updates と Updated by は互いに対となる表記である。 RFC-YYY が過去の RFC-XXX の内容を完全に置き換えるときには RFC- YYY に (Obsoletes XXX) 、 RFC-XXX に (Obso- leted by YYY) と表記される。置き換えるのではなく 内容を更新したり追加するときは、 ObsoIetes の代わり に tJpdates を利用する。複数の番号か列記されることも ある。 RFC 番号とは別に FYI シリーズや STD シリーズの 番号が付加されるときもあり、その場合は FYI 、 STD 、 RTR などの項目が表記されるにれらについては連載の なかで頂次説明する予定である ) 。 実際の項目を参照しながら、各 RFC がどのように rfc- index 中に記載されているかを説明する。 UNIX MAGAZINE 1997.11 ということか読み取れる。 10 , 468 バイト長。 RFC2095 を置き換えている である。公開されたのは 1997 年 9 月。テキスト形式で る IMAP/POP 認証 (AUTH) 拡張」についての RFC によって言当された「単純なチャレンジーレスポンスによ RFC2195 番は J. Klensin 、 R. Catoe 、 P. Krumviede ーヒ記からは、 TXT = 10468 bytes) (Obs01etes RFC2095 ) P. Krumviede. September 1997. (Format : Cha11enge/Response . J. K1ensin , R. Catoe , 2195 IMAP/POP AUTHorize Extension for Simp1e 前述したように、新しい rfc-index は従来の形式とくら べて情報量が少ないので不便である。とくに、 RFC の現 在の状態に関する項目がないので困ることが多いように思 える。じつは、従来の形式に似た index ファイルも用意 されている。これは、 RFC が置かれているディレクトリ ではなく、 IETF (lnternet Engineering Task Force) 関連のファイルか置かれているディレクトリにある。ファ イル名は lrfc-index. txt" である。 ds. internic. net をき ちんとミラーしているサイトであれば、 IETF の情報 は RFC が置かれているディレクトリの隣にあるはすで ある。 こちらの形式の index ファイル ( 図 2 ) の読み方も解説 しておく。使い分けて活用するとよいだろう。 ヘッダ中のガイド部分を分かりやすく書き直すと、 RFC 番号状態著者リスト , "RFC のタイトル " 公開日 . (Pages=R-- ジ数 ) (Format=. txt または . ps) (FYI [FYI 番号 ] ) (STD [STD 番号 ] ) (RTR [RTR 番号 ] ) (Obs01etes 置換された RFC 番号 ) (Updates 更新された RFC 番号 ) となる。上記の例では省略されているが、 Obsoletes と Obsoleted by 、 Updates と Updated by については rfc-index と同しである点に注意してほしい。 Format に 関する記載は省略されることが多いようだ。 さきほどと同様に、実際の項目を参照しながら各 RFC がどのように rfc-index 中に記載されているかを説明す る。 2200 S " INTERNET OFFICIAL PROTOCOL J . Poste1, STANDARDS" , 06 / 12 / 1997. (Pages=39) (Obs01etes RFC2000 ) (STD 1 ) 87
図 1 rfc-index のヘッダ部分 ( 現在の形式 ) 9 / 19 / 1997 ←最終史新日 This fi1e contains citations fO て a11 RFCS in reverse numeric order . RFC citations appear in this format : ( このファイル中にはすべての RFC が逆順に列挙されている。各項目の体裁は次のようになっている ) # # # # Tit1e of RFC . Author 1 , Author 2 , Author 3 . lssue date . (Format: ASCII) (Obs01etes xxx) (Obs01eted by xxx) (Updates xxx) (Updated by xxx) (AISO FYI # # # # ) Key tO citations : # # # # is the RFC number . 表 1 RFC の入手先 使用プロトコル URL ftp://ftp.dit.co ・ jp/pub/RFC/ ftp://ftp.iij ・ ad ・ jp/pub/RFC/ ftp://ftp.kuins.kyoto-u.ac.jp/pub/RFC/ ftp://ftp.tohoku.ac.jp/pub/doc/RFC/ ftp://ftp2.fujixerox ・ co ・ jp/pub/RFC/ ftp://ftp.elelab.nsc ・ co ・ jp/pub/RFC/ ftp://ftp.jaist.ac ・ jp/pub/ds-internic/rfc/ ftp://ftp.iis.u-tokyo.ac.jp/RFC/ ftp://ftp.join.ad.jp/pub/doc/RFC/ http://www.internic.net/ds/dspglintdoc.html WWW http://www.csl.sony・ co. jp/rfc/ //rfc-wais. dit. co. jp:210/rfc/ WAIS wa1S.• RFC インデックス RFC がどこにあるかが分かったところで、根本的には なんの解決にもならないことは、「とりあえすサーバーに アクセスしてみた」人なら身に染みて理解していることだ ろう。 現在、 RFC 文書は 2 , 200 程度が公開されている。原 則として公開順 1 に番号が付けられており、ファイル名 も番号に応じて、、 rfcXXXX. txt" もしくは、、 rfcXXXX. ps " となっているので、ファイル名から内容を知ることは できない。 そこで、ファイル名と内容の対イ系を示すための情報 として、 RFC の内容 ( タイトルなど ) と番号の対応か記 述されている、、 rfc-index. txt" というファイル ( 以下 rfc- index と表記する ) が RFC と同じディレクトリ内に置か れている。 rfc-index は人間か読める形式で当されてお 1 すれることも多い。 FTP り、にあたってク芋別な文法丿は存在しない。 rfc-index の内容を説明しよう。ただし、注意してほし いのだが、これから解説する rfc-index の体裁は変化する 可能がある。先日 ( 8 月上旬だったと思う ) も、言当曲内 容が大塩に変化した。 RFC の数か増えたため、個々の 報を減らしたからだが、すいぶん情報量か減少した。また、 機械自勺に内容を解釈するのがたいへん難しい形式となって しまった。 現在の形式の rfc-index の冒頭部分を図 1 に示す。 はじめの文章に続いて、記載されている内容についての 簡単なガイドか記されている。この部分をへッダと呼ぶ。 ヘッダの書式は、 腫 C 番号 RFC のタイトル . 著者 1 , 著者 2 , 著者 3 . 公開日 . (Format : 文字列 ) (Obs01etes xxx) (()bsoleted by xxx) (Updates xxx) (Updated by xxx) (A1so FYI # # # # ) のようになっている。 Format はその RFC の記「彡式と 86 UNIX MAGAZINE 1997.11
MIME 関連 からは、 RFC2200 番は J. Postel によって言当された「インタ RFC2183 Communicating Presentation lnformation ーネット公式プロトコル標準」についての RFC である。 in lnternet Messages: The Content-Disposition RFC の状態は、、 Standard ( 標準 ) " であり STD シリー Header Field ズの 1 番である。公開されたのは 1997 年 6 月 12 日。全 インターネット・メッセージを介したプレゼンテーション 1 青報璉 Content-Disposition ヘッタフィールド 体で 39 ページ。 RFC2000 を置き換えている PS. 、 R. Troost 他 ( RFC1806 更新 ) ということか読み耳せしる。 MIME 為絲勺 ( RFC2045 ~ 2049 ) に適合する形式でフ その他の検索方法 レゼンテーション情報を伝達するを提案している。現 在の状態は、、標準化への提唱 (Proposed standard)" で RFC インデックスは頻繁に更新されるため、新しい情 ある。 1997 年 9 月 11 日に公開された。 報を求める場合は便利だが、 RFC 番号順に並んでいるだ けなので、必要な↑帯にを探すにはが必要である。 MIME 工ンティティ ( メッセージ (message) もし くはボデイバート (body part)) のオプションとして、 rfc-index 以外のインデックス情報としては、前項の例 Content-Disposition' ヘッダフィールドを定義してい でもとりあげた「 INTERNET OFFICIAL PROTO- る。 COL STANDARDS 」という RFC がある ( ) 京石奇執筆 点の去斤版は RFC2200 ) 。これは、 J. Postel が定期的 こでのプレゼンテーションとは、伝達された文書の に編集し、公開されているものである。 見え方を示している。たとえは、現在はマルチパート形式 この RFC は STD シリーズの 1 番となっており、 で複数の文書や映像を送ったときに、その文書群をどの RFC そのものについての詳細な説明や、去も匠の RFC 全 ように表小すればよいのかという情報は存在しない。そこ 体の変史点、インターネット上でのプロトコルを規定して で、「ある文書にはこの絵を同時に見せる」といった情報 いる RFC の表などが含まれている。 を MIME のフレーム中に埋め込むことにより送り手の意 ほかにも、 WAIS を使って検索する去がある。 図を反映させる機溝として、このヘッダフィールドが定義 されている。 //rfc-wais. dit. co. jp:210/rfc/ W&IIS: ただし、ここで定義されているのはフレゼンテーション では、 AND 、 NOT キーワードによる条件検索や、 f00 * の材哦に関する規定ではなく、プレゼンテーション情報伝 のような不完全な単語ク月旨定でも検索可能である。たとえ 達のフレームワークの規定のみである。伝送されたプレゼ ば、「 MIME について書かれた RFC 」や「 OSPF の拡 ンテーション・情幸長の扱いは MUA (Mail User Agent) に 張についての RFC 」を探したい場合などに利用してみる ーイ壬されている。 とよいだろう。同様に、 WWW での検索サーピスを提供 このヘッダフィールド中には 2 つの値が定義される。ポ しているところもいくつかある。 ディノヾートの通常の 1 次フ。レゼンテーションと、ファイ http://www.csl.sony・ co ・ jp/rfc/ ルをメールで転送するための機能である。将来ははかのさ に検索サーバーがあるので、キーワード検索には役に立つ まざまな値と、これらの値を拡張するための手続きカ綻義 だろう。 される予定である。 来月は、 RFC の状態とその変化について説明する予定 RFC2183 は、、経験 (Experimental)" として公開され である。 ていた RFC1806 の改訂版である。変更点は、 ・ボデイバートでのファイル中幻のための新パラメータの 導入 ・非 ASCII 文字および長いパラメータ値処理のための仕 今回の RFC 今回扱うのは、 1997 年 8 月中旬から 9 月中旬に公開さ れた RFC である。 88 UNIX MAGAZINE 1997 ユ 1
表 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
RFC ダイジェスト 宇夫陽次朗 先日、知人に「 UNIX MAGAZINE に RFC の話 を書くのは変だよね」と言われた。たしかに、、、 UNIX" と、、 RFC " には直接的な関連はないように思われる。「う ーん、そうだねえ。でも、実際ュニマガではす一つとネ 先月予告したとおり、 RFC の読み方を数回に分けて解 ットワーク関連の話がたくさん書かれているし、いまでも 見する。今回は、、 RFC の探し方 " を中心に いくつかの そうだよね」と答えたのだが、彼はどうも釈然としないよ トピックについて説明していく。 RFC の入手 パーソナル・コンピュータもネットワークに接続され るようになった昨今、 UNIX が、、ネットワーク " や、、イ 前号ではいきなり RFC の紹介から始まったため、戸 「とりあえず RFC ンターネット " の主たる友要素だった日罸にはすでに過ぎ 惑った読者が多かったかもしれない。 を読んでみよう」と思ったとしてもリ勿を見つけることが 去ってしまったのだろうか。 できなければ始まらないので、 現在では、ユーザーか直孑欝盟 1 三することの多いマシンの ( おそらく ) 9 割がたは非 UNIX 系の OS となっていると 「 RFC およびその関連文書はどこにあるのか ? 」 田われる。したがって、 1 澗ではそういう印象が強いだろ というところから説明していこう。 うし、今後もその傾向に拍車がかかるであろうことは認め RFC のマスター・アーカイプは、 ざるをえない。 ftp://ds.internic.net/rfc/ しかしながら、それでは自己否定になりそうなので、ち ょっと知恵を絞ってみた。世清がどうなっているかは別に という FTP サーバーである。この内容は世界各地のさ して、 UNIX とネットワークの関係について考えてみよ まざまなミラーサーバー ( 同じ内容芋しているサー う。すると、「 UNIX はネットワークそのものであるとい ー ) でミラーされている。 FTP のはかにも WWW や う考え方もできるかもしれない」という気がしないでもな WAIS (Wide Area lnformation Servers) 、電子メー い。その考えをさらに進めて、「 UNIX を使っているかぎ ルで入手することができる。 り、ネットワークと切っても切れない関係にあることはた このように、ネットワーク上には多数の取得方法が存 しかである」と言うこともできるかもしれない ( ちょっと 在するので、 1 次配布元である ds. internic. net からでは 苦しいかな・・ なく、最寄りのサーバーから入手するようにじ掛けてはし というあたりで個人的にはなんとな <* 断等したし、疑間 い。日本国内の主要なサイトを表 1 に示す。これ以外に を投げかけた知人も煙に巻かれたようで、そオ LJ 丿まに追究 も多くの場所に置かれているので、学オ交や会社などに所属 してこなかった。 している場合は管理者や詳しい人に訊いてみるとよいだろ う。自分の所属しているサイトでもミラーしているかもし それでは、煙に巻かれた人もまた断等できない人も頭を れない。 切り替えて、 RFC の話題に移ることにしよう。 RFC の読み方 11 二ロ 85 UNIX MAGAZINE 1997.11
・編集ー 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
バンド幅やディスク資源の点から効率的とはいえない場合 によくみられる。 メールポックス回送イ椒こよって、クライアントは分散 した IMAP4 サーバー群に存在するメールポックスに効 率よくアクセスできるようになる。 回送機構の接続方式は 2 不頁ある。 1 つは一種のプロキ シーであり、もう一方はサーバー名を知らせてクライアン トか接続するサーバー自体を切り替えるものである。回送 イ懾は一種のプロキシー手法を利用することで効率的な処 理カ新」・能である。ローカル IMAP4 サー ーはクライア ントの代わりにリモートサーバーと接続してデータを受け 取り、それをクライアント , 云送する。また、回送オの クライアントからリモートサーバーへの一耐妾続は、バン ド幅をより有効に利用でき、かっリモートサーバーからの 言 E の際にクライアントに扮する必要がないという利点が ある。 RFC2195 IMAP/POP AUTHorize Extension for Sim- ple Challenge Response 単純なチャレンジーレスポンスによる IMAP/POP の認 証 (AUTH) 拡張について PS. 、」 . Klensin 他 ( RFC2095 置キ奐 ) IMAP および POP の認証機構の拡張機能として、チ ャレンジ - レスポンス方式を利用した AUTH 拡張を提案 している。現在の状態は、、標準化への提唱 " である。 1997 年 9 月 10 日に公開された。 IMAP て利用するための認証オ冓は、 RFC1731 で数 多く定義されている。しかし、これらはすべてネットワー ク中に平文を伝送する方式であったため、チャレンジーレ スポンス方式の認証機構を定義している。 これは RFC2095 を置き換えるために公開されている が、変更点は参照していた鍵付き MD5 の定義が I-D (ln- ternet Draft) から RFC 化されたことに対応する部分だ けである。 その他 その他の RFC をまとめる。 RFC2148 Deployment of the lnternet White Pages Service インターネットにおけるホワイトページ・サービス要 90 について BCP. 、 H. Alvestrand インターネットにおける糸Ⅱ織や個人のアドレス情報 ( い わゆるホワイトページ・サービス ) への需要について論し ている。現時 . 点での最良の方 ~ 去 (Best Current Prac- tice)" として公開されており、 BCP シリーズの番号は 15 である。 1997 年 9 月 10 日に公開された。 インターネットはユーサー間の情報交換やコミュニケー ションに利用されている。しかし、このようなことができ るのはユーサーか相手のアドレスを知りえた場合だけであ る。したがって、インターネットで人びとや組織に関連す る ( インターネットなどの ) アドレス情報を提供するなん らかのホワイトページ・サービスを利用することは有用で あろう。具一勺には、ディレクトリ・サービスなどか挙げ られる。 そこで、 RFC2148 では「インターネット・ホワイト ページサービス ( 以下 IWPS と表記する ) 」を山も丘の経 験、プロトコル、製品、手続きを利用して活用する去を 述べている。 RFC1943 として公開されている「 Building an X. 500 Directory Service ⅲ the US ( 米は」における X. 500 ディレクトリ・サービスの構築 ) 」によると、利用者が自 分でイ求する集中型のホワイトページ・サーピスは情嗣則乂 集を管理できす、そのうえ旧い情報か集約されてしまうこ とがある。 したがって、 IWPS を構築する際にもっとも重要なの は、分散 ( もしくはローカル ) データベースを基盤とし、 各データベースはそれぞれが実際に管理可能な IWPS 情 報をイ早することである。具ー勺には、系哉に特化した情 報や、インターネットサーピス・プロバイダとそのユー サーの清報などを挙げることができる。 X. 500 はインターネットでもっとも普及しているディ レクトリサーピス・プロトコルで、本で 3 000 畆 150 万人におよ次に普及しているのが wh 。 is 十十である。 これらは IWPS 情幸ユ外の情報もやりとりするが、 では IWPS に関連することのみを扱う。 本文中の第 1 章では、 RFC2148 中にあるインターネッ ト上の組織に対する要求がまとめられている。よい例だと 思うので、その要約を以下に小す。 UNIX MAGAZINE 1997.11
1. 各糸Ⅱ織は公的な E-maiI アドレスと、その斜に属する インターネット・ユーサーに関する他のアドレス情報を 公開すべきである。 2. 個人情報の公表に関して法律ー E の制限がある国が多い。 このようなケースにあてはまる場合、糾織はこの点につ いて触れるべきである。 3. 現状の情報の公開に関しては、 X. 500 のデータ構造お よび名前付け規約を利用することか望ましい。糸はそ れ以外のデータ構造 ( たとえは whois 十十 ) でも情報を 公開することか望ましい。 4. 組以ま LDAP (Light-weight Directory Access ProtocoI) クライアントのための公開情報を用意すべき である。 5. これらの情報を得る際に課金することは避けるべきであ る。 さらに、他の集団に関しても以下のような要求か示され ている。 1. E-mail べンダーは LDAP 探索機能を製品に付加すべ きである。組込み機能でもよいし、変換機能によって提 か望ましい。 しくは自分のサイトで青報を提供できるようにすること らの情報のための機器サービス窈是供や業者の斡旋、 してこれらの要望に関する手助けをすべきである。これ 2. インターネットサービス・プロバイダは小さな細織に対 供してもかまわない。 も UNIX MAGAZINE 1997.11 anisrns for IPv6 Hosts and Routers 」で定義されてい RFC1933 として公開されている「 Transition Mecl ト 9 日に公開された。 している。、、広報 " として公開されている。 1997 年 9 月 IPv4 から IPv6 への移行という観点から経各制御を論 旧 fo. 、 R. Callon 旧 v6 へのラ俿見点からみた糸懿 RFC2185 Routing Aspects 0 日 Pv6 Transition してみるとよいだろう。 ー E 記の理由や田について興未のある人は、本文を参照 きである。 名前空間中に存在させて、名前解決が可能なようにすべ 3. あらゆる関連団体は、これらを世界の主要な X. 500 の 日 FC ダイジェストー② るプロトコルを基本に言侖を進めている。この文書で述べ られている手法は、 RFC1933 の内容に沿ったものとなっ ている。この RFC を読む前に、 RFC1933 を工早してお くことカ甘隹奨される。はかにも Ngtrans 分科 - 会での言侖 か含まれている。 IPv4 から IPv6 への移行期間中には、 IPv6 のシステ ムは既存の IPv4 システムと共存しなけれはならない。 のように、 2 不鶤頁のインターネットワーキング・プロトコ ノい竟か 1 司居している状態では、糸習紐財冓も同じよう に IPv4 および IPv6 の双方の方式か利用されることに なる。 当初、 IPv6 に対応したドメインは、大域的には IPv6 対応のインターネット・インフラストラクチャを直孑欝第山 せすに、 IPv4 の糸齧各制御しかできない領域を介して通信 する場合が多かった。このような混在工韆竟での勺糸習各制 御ができるようになるにしたがい、各地に散在する IPv6 の糸習各制御カゞ可能な領域間で、 IPv6 によるネットワーク 層の接続情報を広域的に伝達するオが必要になってきて いる。 また、いすれ訪れる IPv4 から IPv6 への移行期には、 IPv4 の糸齧各制御しか利用できない領域間の IPv4 バケッ トを IPv6 によるインフラストラクチャ経由で伝達するた めに、同様な手法を用いることが可能であろう。 このような移行の際の糸各制御に関連する話題として、 以下を挙げることができる。 1. IPv4 バケットの糸翻膽卩 2. IPv6 バケットの経路制御 (a)IPv6 本来のアドレスを利用している IPv6 バケット ( b ) IPv4 互換のアドレスを利用している IPv6 バケット 3. 手動で設疋された勺トンネルのオペレーション 4. 自動力プセル化のオペレーション (a) カフセル化の場所 (b) カフ。セルイゞおこなわれた場合の経路制御刎焉正 といった基本欟冓が必要となる。 3. 自動力プセル化の経路漏洩のサポート 2. ポイントツーポイント・トンネルの手動設定 1.2 つの IP 層間の糸習各言算 」「記の目的を達成するためには、 91
ートーの 連載 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
UNIX Communication Notes 山口英 カーネルを読もう ( 15 ) 旧 v6 ( 1 ) 前回は、現在もひろく利用されている IPv4 の問題点 と、それに代わるべく開発された IPv6 (IPng) の概要を 説明した。今月は、 IPv6 標準を規定した RFC1883 [ 1 ] を 中心として、その機能の言岩田をみていく。 IPv6 の実装が進み、さらに 6bone による実験運用が活 発におこなわれた結果、早くも RFC1883 で定義された標準 を改定する動きが出てきた。 IPv6 の標準化竹喋を進めている IETF の IPNG WG では、 1997 年 7 月に IPv6 のイ士様第 2 版 [ 2 ] を作成し、従来の標準に変史を加えている。以降では、 原則として RFC1883 に沿って解説するが、必喫に応して仕 様第 2 版で改定された部分にも言及する。 前回も述べたように、 IPv6 のおもな特徴は、 ・よりシンプルなヘッダ構造 ・ 128 ピットのアドレス空間 ・オフション機能の長 ・ Flow Label ・セキュリティ機能の強化 ・ Plug & Play の 6 つである。 IPv6 ヘッタ バケット交換プロトコルの機能を理解するには、次の 2 14 いていかなる処理をおこなうか。 ・バケットを交換するノードでは、ヘッダの情報にもとづ 収められているか。 各バケットにイ寸加されるヘッダには、どのような情報が つの点か重要である。 ます、 IPv6 ヘッダの構造とその未からみていこう。 IPv6 ヘッダは、図 1 のような構造になっている。 覧のとおり、以下の 8 つの情報しかオ翻されていない。 ・ノヾージョン番号 (Version : 4 ビット ) 終点ホストアドレス (Destination Address : 128 ビ 始点ホストアドレス (Source Address : 128 ビット ) ・ホッフリミット (Hop Limit : 8 ビット ) 次へッダ (Next Header : 8 ビット ) ペイロード長 (Payload Length : 16 ヒ、ツト ) ・ Flow Label ( 28 ビット ) プライオリティ (Priority:4E ット ) UNIX MAGAZINE 1997.11 vice) 、 ldentification 、 Flags 、フラグメント・オフセッ さらに、 IPv4 のヘッダ長 (IHL) 、 ToS (Type of Ser- については、あとで詳しく説明する。 になった。これらの再定義されたフィールドの意味や構造 ションは、 IPv6 ではまったく異なる構造で表現すること となり、その意味も大きく変わった。 IPv4 での IP オプ が、それぞれペイロード長、次へッ久ホップリミット プロトコルタイフ (Protocol) 、 TTL (Time To Live) IPv6 では、 IPv4 での / ヾケット長 (Total Length) 、 をイ褓内する。 このフィールドに↑褓内していたが、 IPv6 では 6 ( 0110 ) は、従来どおりの使い方をする。 IPv4 では 4 ( 0100 ) を ン番号 (Version)" だけである。このフィールドについて ち、 IPv6 でもそのまま残っているのはう頁の、、バージョ わめて単純である。 IPv4 で使われていたフィールドのう だが、 IPv6 のヘッダ構造は IPv4 のそれとくらべるとき 上交のために、 IPv4 ヘッダを図 2 に示す。一目瞭然