今月は、巧で記事を読み書きする際に役立つ情報につ いて紹介します。 ・ URL Map about fj. * 巧に関してます読んでおくとよいニュースグループと して、 . lst-readme があります。ここに以下のような 記事か才齬奇されました。 Subject: V001i0007 : URL Map about 斤 * ( 1 / 1 ) Message-ID. く 1997 」 u131.102812.7456@merope.opus. or.j p 〉 From. adachi@csi.ses.co.jp (Adachi 」 unichi) これには「私家阪巧 . * を歩くための地図」というタイト ルカ咐いています。以下にその記事の内容を紹介します。 ・文書や FAQ はくある質間とその回答 ) 集か投稿され ュースグループ 巧 . archives. answers : FAQ 集 巧 . archives. documents : - 各不重こ書 : 巧 . archives. misc : その他 巧 . archives. d : 言墟龠の場 ・コンピュータ関連の用語集 http://www.fwi.uva.nl/-mes/jargon/ ・ネットワーク上でのエチケットや用語集 http://www.edu/ipa ・ go ・ jp/mirrors/togane-ghs/ net i quette/ ・電子メールに関するヒント集 http://www.ed.kanazawa-u.ac ・ jp/-iwasaki/ Tips/ ・ NetNews に関する FAQ http://www.threeweb.ad.jp/-kats/NN/ FAQ. shtml ・巧についての各種情報 http://www.cs.orst.edu/-takikawm/fj/ whatisfj. html ・日本のメーリングリストに関する↑帯に http://www2j.meshnet ・ or. jprodajima/ml/ ML-in-JP/ みるく UNIX MAGAZINE 1997.10 ・巧の記事の検索 http://mitsuko.jaist ・ ac. jp/fj/ ・ NetNews の記財素 : http://www.dejanews.com ・ RFC ( インターネットに関する規格文書 ) http://www.csl.sony.co.jp/rfc/ http://www.barrier-free.co.jp/a2z/r/RFCJ/ ・ RFC の解説 http://www.imasy.or ・ jp/ -masaka/ link. html#inet-rfc ・ RFC の日本言矗尺 http://www.barrier-free.co.jp/a2z/r/RFCJ/ 顔文字 ( フェイスマーク ) http://www.etl.go.jp/People/harigaya/doc/ kao. html ・漢字コードに関する情報 http://www.kudpc.kyoto-u.ac.jp/-yasuoka/ kanjibukuro/japan. html http://turbine.kuee.kyoto-u.ac.jp/FAQ/ kanji-code. html ・ Microsoft の lnternet Mail/News の成疋 http://www.microsoft.co.jp/pss/tdoc/doc/ MaiINews/iaj5217. htrn http://www.three-a ・ co ・ jp/-asada/msin http://www.cup.com/negi/msin.html これ以外にも、 4 冊の書籍か紹介されています。 ・今月の話題から ( 1997 年 8 月 20 日現在 ) Newsgroups: 月 . news. usage . questionsfJ,fj. news. mlSC Subject: words world ー beta 0.9 ( 17 Aug 1997 ) 巧関連の用語の一覧とその解説です。多くの用語が収 録されているわけではないのですが、疑問に思ったとき のとっかかりにはよいと思います。 Newsgroups: 月 . os. bsd. freebsd Subject: The install kernel on 2.2.2R doesn't b00t. これまで FreeBSD 2.1.6- R カ力いていた PC に 2.2.2 ー R をインストールしようとしたのですが、インス トール用カーネルがパニックを起こしてしまい、プート できません、周辺機器を交換したりポート類を抜いてみ 119

RFC ダイジェストー① 表 1 今月紹介した RFC GKMP RFC2093 グループ理プロトコル (GKMP) のイ士様 RFC2094 グループ理プロトコル (GKMP) のアーキテクチャ URI/URL/URN 鏈 RFC2168 DNS を利用した URI 角夬 RFC2169 HTTP を URN 鮹夬に利用する際の一 - 一搬的な取決め MAPOS 鏈 RFC2171 RFC2172 RFC2173 RFC2174 RFC 2175 RFC 2176 DNS RFC2181 RFC2182 MAPOS : SONET/SDH を介した並列アクセス・プロトコル第 1 版 MAPOS 第 1 版 : 割当て済みナンバー MAPOS 第 1 版長 : ノードスイッチ・プロトコル MAPOS 第 1 版拡張 : スイッチッースイッチ・プロトコル 16 ビットアドレス方式による MAPOS : MAPOS 16 MAPOS を介した IPv4 伝送第 1 版 DNS のイ士様の町寉化 セカンダリ DNS サーバーの j 尺と管理 IMAP RFC2177 IMAP4 IDLE コマンド RFC2180 IMAP4 におけるメールポックスへの並列アクセス 各種プロトコル / そ也 RFC2165 RFC2167 RFC 2170 RFC 2178 RFC 2179 サービスロケーション・プロトコル RWHOIS プロトコル第 1.5 版 アプリケーション要求型 IP over ATM (AREQUIPA) OSPF 第 2 版 トレードショーにおけるネットワーク・セキュリティ NetWorld 十 lnterop (N 十 I) などをはしめとするトレ ードショーにおけるネットワークのセキュリティの「苻早 去について述べている。、、広報 " として公開されている。 ー殳に、多くのシステム管理者やトレードショーの関係 者はトレードショーにおけるネットワークのセキュリティ を甘くみる傾向がある。 たしかに、オフィスのシステムにくらべてトレードショ ーのシステムは攻撃されることは少ない。しかし、トレー ドショーのシステムは展小内容やショー全体のイベント に大きな景をおよはすことがあるので、すくなくともオ フィスのシステムと同等に扱うべきであろう。 あまたのインターネット・セキュリティ関連の籍と は異なり、 RFC2179 では見落とされやすい部分や実行さ れると重大な問題のある攻撃を受けるのを減らす簡単な方 法のチェックリストを提小するというアプローチをとって いる。 N 十 I の NOC (Network Operation Center) チーム によって書かれているため、経験にもとづいたカ夋に富む 内容となっている。複数の参加者をネットワークに接続す UNIX MAGAZINE 1997.10 る展示会などの関係者は一読するとよいだろう。 ( うお・ようじろうはを先立物斗 ! 物支術大凝完大学 ) は、 RFC 全体の各について説明する予定である。 ため、来月はあまり公開されないかもしれない。その場合 月初旬にミュンヘンで IETF ミーティングが開催された の開催前にぐっと増え、その後は減少する傾向にある。 8 RFC を紹介する。 RFC の公開は、 IETF ミーティング 次号では、 8 月中旬から 9 月中旬にかけて公開された 今回扱った RFC を表 1 にまとめる。 まとめ 109

RFC2169 は RFC2168 とセットになっている。ます RFC2168 とそこて示されている参考文献にあたったうえ て利用するとよいだろう。 MAPOS 関連 RFC2171 MAPOS ー MuItiple Access Protocol over SONET/SDH Version 1 MAPOS : SONET/SDH を介した並列アクセス・プロト コル第 1 版 旧 fo. 、 K. Murakami 他 RFC2172 MAPOS Version 1 Assigned Numbers MAPOS 第 1 版・割当て済みナンパー 旧 fo. 、 M. Maruyama 他 RFC2173 A MAPOS version 1 Extension ー Node 旧 fo. 、 K. Murakami 他 MAPOS 第 1 版拡張スイッチッースイッチ・プロトコ Switch Protocol RFC2174 A MAPOS version 1 旧 fo. 、 K. Murakami 他 MAPOS 第 1 版拡張 . ノードスイッチ・プロトコル Switch Protocol ExtenSlon ー Switch- RFC2175 MAPOS 16 ー Multiple Access Protocol over SONET/SDH with 16 Bit Addressing 16 ビットアドレス方式による MAPOS : MAPOS 16 旧 fo. 、 K. Murakami 他 RFC2176 旧 v4 over MAPOS Version 1 MAPOS を介した旧 v4 伝送第 1 版 旧 fo. 、 K. Murakami 他 いすれも MAPOS (Multiple Access Protocol over SONET/SDH) 里の RFC であり、すべて、、広報 (ln- formational)" として公開されている。それぞれ、 RFC2171 : MAPOS の基本フ。ロトコル RFC2172 : MAPOS て利用されているパラメータ君 ) 定義 RFC2173 : MAPOS ノードへの自動アドレス割当てを おこなうための、、ノードスイッチ・プロトコル " の定義 UNIX MAGAZINE 1997.10 RFC ダイジェストー① RFC2174:SONET のスイッチ・ネットワーク中におけ る経路制御をおこなうための、、スイッチッースイッチ・ プロトコル " の定義 RFC2175 :MAPOS のアドレス長を 16 ピットにする 刻長である MAPOS 16 RFC2176 : MAPOS を利用して IPv4 を伝送するため のフレーミングとカフ。セル化 について述べている。 SONET/SDH (Synchronous Optical Network/ Synchronous Digital Hierarchy : 同期式光ネットワー ク / 同期式デジタル・ヒ工ラルキー ) は、放送クオリティの 伝送システムで用いられる光ファイバーを使用した基本イ ンターフェイスを定義している。 SONET/SDH は ITU- T 標準プロトコルで、電話のキャリアのあいだではひろく 開発が進んでいる。 MAPOS は、 SONET/SDH 上に HDLC (High- Level Data Link Control) フレームを伝する手法で ある。名前のとおり、ポイントツーポイント・リンクを 利用した複数の並列アクセスがおこなえるため、 LAN か ら WAN に至る広い間用に適用可能である。 MAPOS に よって、 SONET/SDH 回線を伝送メディアとして利用 する並列アクセス、プロードキャスト、マルチキャストな どカ俐用可能なスイッチ LAN 竟を : 見できる。 DNS 関連 RFC2181 Clarifications to the DNS Specification. DNS 士様の日軅化 PS. 、 R. 日 z 他 ( RFC1034 、 RFC1035 、 RFC1123 更新 ) これまで RFC1034 ~ 1035 、 RFC1123 などで定義さ れてきた DNS のイ士様のなかで、問題点として孑商された 部分を町寉にし、対策を提案している。現在の状態は、、標 準イク是唱 (Proposed Standard)" である。 RFC2181 で第侖されているのは以下の 8 つの分野で ある。 ・マルチホーム・サーバーの IP バケットのヘッダアドレ スの利用法 ・同一の名前、クラス、タイプをもつレコードの TTLs ゾーンのうリの正しい扱い方 (Time-To-Lives : 生伽判ゆ 105

RFC タイジェスト 宇夫陽次朗 インターネットに関連する事柄を詩・ヾていると、かなら す目にする言葉として「 RFC 」がある。 RFC (Request For Comments) は、インターネットにおけるさまざま な、、決まり " や、、しきたり " 、、、お知らせ " を文書化したも のである。 すなわち、、、「インターネット」を定義する文群 " と 言い換えることもできるだろう。現在、 2200 弱の RFC 文書か公開されており、継読的に増加している。里載で は毎月、約 1 カ月のあいだに新しく公開された RFC を紹 介していく。それぞれの内容や、公開された背景をまとめ ることで、インターネットの動向や刻ヒの方向性を擱む助 けになればと考えている。 本連載は、 lnternetworking 誌から移転してきたもの である。 RFC 本の概略については過去の連載でも触れ ているのて参考にしてはしい。といっても、掲載劼ミ変更 されたこともあり、今彳斤しい情報を交えながら褪邪各的な 話題もとりあげる予定である。 今回扱うのは、 1997 年 6 月中旬から 8 月中旬に公開さ れた RFC である。 GKMP 関連 RFC2093 Group Key Management Protocol(GKMP) Specification グループ里プロトコル (GKMP) 士様 Exp. 、 H. Harney 他 RFC2094 Group Key Management protocoI(GKMP) Architecture 今回の RFC 102 グループ鍵里プロトコル (GKMP) のアーキテクチャ Exp. 、 H. Harney 他 いすれも GKMP (Group Key Management pro- tocol : グループ健管理プロトコル ) の基本 RFC である。 RFC2093 は GKMP の仕様定義を、 RFC2094 はアー キテクチャについてそれぞれ記述している。、、経験 (Ex- perimental)" として公開されている。 インターネットにおいて安全な通信をおこなうために は、通信内容窈号化カ陏効である。ーヨ殳に、情報の暗号 化に際しては、通信をおこなう人 ( たち ) にしか分からな い、秘密 " がなんらかのかたちで用いられる場合が多い。 このような秘密を、通常は、、鍵 ( もしくは暗号鍵 ) " と呼 ぶ。暗号を使ううえて大きな問題となるのは、その鍵の扱 い方である。 鍵の配布方式はさまざまだが、も匠までは昔からのイ充 的な手法が主充だった。すなわち、戦中に軍で用いられ ていたような、、紙に印刷された暗号鍵の表を配布して、そ の内容から得られる情報を解読に利用する " 去と本質的 には変わらないものである。 協建管理アルゴリズムは、 2 点間でペアとなる鍵を生 成できる力法である。これは、多くの通信の安全を礪呆で きる高速かっ信頼性の高い鍵管理方式だが、 2 点間で 1 対 となる鍵セットしか生成できないため、複数の相手どうし で通信するような用途には利用できない。 そこで、 RFC2093 、 2094 では、インターネットでの 多点間通信における安全性石呆に利用できる、多対の暗号 鍵確立およひ鍵の再生成プロトコルとして GKMP を提 案している。 RFC2093 では、グルーフイヒされた対 - 称鍵の生成と通信 要素間での鍵交換方式について述べている。 GKMP の特 UNIX MAGAZINE 1997 ユ 0

連載 UNIX Communication Notes—O なる。したがって、この空間を近い将来使いきってしまう とは予測しにくい。 データグラムのヘッタ購造も大蝠に変史された。基本的 に叫屯なヘッタ構造を採用し、さらに、充実した拡張機能 を提供するためのオプションヘッダが用意された。すべて のデータグラムに付けられる IPv6 ヘッダはごく単純な ものとし、プロトコル処理の効率化を図っている。 IPv6 ヘッダでは、 FIowIabeI と呼はれる情幸ゞ用意された。 れを上手に利用すれは、処理の高速化が見できると思わ れる。 セキュリティ機能に関する強化は、 IPng の大きな緻 の 1 つである。基本的には、 IPSEC で標準化された ESP を利用する。さらに、ホスト言盟 E のための樹冓も用意され る。ネットワーク層レベルで必喫とされるセキュリティ機 能は、すべて組み込まれたといってよい。 IPv6 の現状 世界各地で私極的に開発が進められた結果、現在では IPv6 竟を構築できるまでになった。インターネットで 、 6bone" と呼はれる IPv6 のイ反想的な実験ネットワ は、 ークか構築さオ L 、 IPv6 の開発を隹する竟として利用 されている。いろいろなところで進められている IPv6 の 本は々は妾続生についても、 UNH/IOL (University of New Hampsher, lnter-()perability test Lab) を中心として テストをおこなっている。このような努力が結実し、多 くのプラットホームでの IPv6 の実装がかなりの段階に まできている。ルータなどのネットワーク機器について も、 IPv6 の実装が進んでいる。 1997 年 6 月に開催された NetWorld 十 lnterop 97 Tokyo では、数多くのべンダー が IPv6 SSD (Solutions Showcase Demonstrations に参加し、 IPv6 の相々鮟続のデモをおこなった。 それでは、一・般の大学や企業が現在の IPv4 の環境か らいますぐに IPv6 に移行すべきかというと、学点で は、、 NO " である。さまざまなプラットホームでの IPv6 のプロトコルの実装自体はおおむね終了しているが、 IPv6 の根本に深くかかわる経路制御などの実装と運用技術の確 立にはまだ時間が必要と思われるからである。したがっ て、 IPv6 の開発に携わる系騰哉を除けば、 IPv6 竟への 移行にあまりメリットはない。もっとも、ルータなどの製 品でもかなりのペースで実装が進められているので、 1998 44 年には移行のための準備に着手してもいいだろう。とりあ えすは、 IPv6 をベースとした小規模な竟を細織内に作 り、運用技術の習得と既存のネットワークからの移行功法 を考えるところから始めるべきであろう。 今回は、 IPv6 カ鯛発されるまでの歴史を簡単に振り返 ってみた。次回は、 IPv6 についてもうすこし詳しく紹介 する。 ( やまぐち・すぐる奈良先端科 : 物支術大凝完大学 ) [ 赭文献 ] [ 1 ] D. Cheriton, VMTP: 梔 7 、 s 観 e Message TT 、佖れ s 佖 c 0 れ ProtocoI ー ProtocoI S 〃 ec ca 0 れ , RFC1045 , Feb. 1988 [ 2 ] S. Deering, Host E e れ s 乞 0 れ s 扣 7 、 IP 石↓履 c 佖 s れ 9 , RFCI 112 , Aug. 1989 [ 3 ] R. Branden, L. Zhang, S. Berson, S. Herzog and S. Jamin, 月 eso 盟℃ e eSet 、レ観れ Protocol ( S レ P. 丿 レ・ s れ 7 F 社れ c 0 れ S ec 亜 c 佖 0 れ , draft-ietf-rsvp- spec-16. txt, Jun. 1997 [ 4 ] ST2 Working Group, んロ肥 t Strearn ProtocoI レ、 - s れ 2 (ST2) Protocol S ec 亜 c 観れ一 Version ST2+, RFC1819 , Aug. 1995 [ 5 ] R. Atkinson, IP E れ c 佖〃 s 祠 0 れ 9 Secunty P 佖ツ 0 佖 d (ESP), RFC1827 , Aug. 1995 [ 6 ] A. Aziz, T. Markson and H. PrafuIIchandra, SimpIe Ke イ 0 れ ageme れ Fo 震 / れ 7 れ e P 0t0C0 な , draft-ietf- ipsec-skip-07. txt [ 7 ] D. Maughan, M. SchertIer, M. Schneider and J. rlhlrner, / れ te ロ肥め Securzty Assoc 乞観れれ d Key ーのト 佖 geme れこ Pr0tocol (ISAKMP), version 8 , draft-ietf- ipsec-isakmp-08. txt [ 8 ] R. Droms, D れ佖 m 乞 c 〃 0 Co れ五 9 社川 0 れ PT 、 0 C04 RFC2131 , Mar. 1997 [ 9 ] S. Deering, R. Hinden, lnternet Protocol, レ er 0 れ 6 は P の S 〃 ec c 佖 0 れ , RFC1883 , Dec. 1995 ☆ UNIX MAGAZINE 1997.10

・ SOA レコードに関係する 3 つの話題と SOA レコード の使用法 ・ TTL の正確な定義 の利用に適した特を備えていることや、去も匠は企業向け か期待される。とくに、 IMAP は企業内ネットワークで IMAP に対応したソフトウェアも増えてきており、今後 だが、 POP の欠点とされる部分を確実に解決している。 POP (Post Office Protocol) よりも後発のプロトコル IMAP (lnternet Message Access ProtocoI) は IMAP 関連 サーバーの管理についても述べている。 ーバーが置かれるのは適切かという話題や、セカンダリ・ するガ去について言侖している。 1 つのゾーンに複数のサ 理的、論理的な場所を用いてセカンダリ・サーバーを尺 RFC2182 では、ゾーンごとにそれぞれのサーバーの物 となるものも多い。 適切なセカンダリ・サーバーを尺していないことが原因 しかし、 DNS の管理の際に発生する間題点のなかには、 DNS ではゾーンごとに複数のサーバーが必要である。 tice)" として公開されている。 ている。点での最良の方 ~ 去 (Best Current Prac- セカンダリ DNS サーバーの選択と操作について述べ BCP. 、 R. E レ他 ( RFC1034 、 RFC1035 、 RFC1123 更 セカンダリ DNS サーパーのと里 DNS Servers RFC2182 Selection and Operation of Secondary 仕様では用いられていなかったものである。 つは、すでに正しい料力は定義されていたが、いくつかの かったため、 RFC2181 中で定義されている。残りの 2 最初の 6 つについては、正しい挙動が定義されていな ・正しい DNS ラベルの作成法 つし ) て ・カノニカル名 / 権威付け ( オーサライズ ) された名前に ・ TC ( トランケーテッド ) ヘッダビットの使用について ・ソフトウェアカイ合されるようになったことか 106 RFC2177 lMAP4 IDLE command ら、いっきに利用か増える可能性もあるだろう。 lMAP4 IDLE コマンド PS. 、 B. Leiba IMAP4 (IMAP ノヾージョン 4 ) における IDLE コマ ン刻長について定義している。現在の状態は、、標準化へ の提唱 " である。 IMAP4 ( RFC2060 ) は高機能な電子メール用のクラ イアント・サーバー型プロトコルである。クライアントは サーバー上にある電子メールを取得するだけでなく、サー 。ー上に存在するメールポックス内のメールを操作するこ ともできる。 現在の IMAP クライアントにない機能のなかて要望が 強いものとして、 「新しいメールがメールポックスに酉占医されたときやメー ルポックス中のメールか削除された場合の即時通知オ冓」 か挙げられる。つまり、選択しているメールポックスの挙 動を監視し、変更か加えられた場合にその内容を通知する 機能の実現力まれている。 このような新しくメールカ哂当されたことを即座に反映 させるガ去はいくつかある。たとえは、 POP のクライア ントのように短い間隔でサーバーに問い合わせ続ける方 法が挙げられる。しかし、この方法はサー ノヾーへの馮太 なアクセスが多くなるのでよい解決策ではない。そこで、 RFC2177 では、 「 IMAP サーバーからクライアントにその旨を通知する 去」 を採用し、 IMAP4 への孑虧長コマンドとして IDLE を定 義している。 この方式では、クライアントから IMAP サー 対して IDLE コマンドが発行されると、クライアントか ら、、 DONE " が送られるまで、サーバーは〕尺されている メールポックスの変化を継続的に通知し続ける。 たとえば、以下のようなやりとりがおこなわれる ( 、、 C " で始まる行はクライアントからサーバーへ送られる文字 列、 S て始まる行はサーバーからクライアントへ送られ る文字列とする ) 。 C : S : S : S : A001 SELECT INBOX ←メールポックスを選択 * FLAGS (De1eted Seen) * 3 EXISTS * 0 RECENT UNIX MAGAZINE 1997.10

4.4.2. 削窰斉みメッセージを含む COPY を許可し うるサーバー 各種プロトコル / その他 RFC2165 Service Location Protocol サービスロケーション・プロトコル PS. 、」 . Veizades 他 サービスロケーション・プロトコルの信嶽を定義してい る。現在の状態は、、標準化へク片是唱 " である。 現状では、インターネット・アプリケーションを利用 する前にはネットワークのさまざまな設定をおこなう 必喫がある。アプリケーションからネットワーク・サーピ スを利用する場合には、ユーザーから明勺に提示される ホスト名 ( アドレス ) を利用するようになっている。 サーヒ、スロケーション・プロトコルは、このようなユー ザーが明示的に定義しなければならない情報を重加勺に設定 するために、ネットワーク中に存する各種サービスの位 置の検出し尺をおこなうためのイ督はみを定義している。 サーピスロケーション・プロトコルを利用する場合、サ ーピスを提供する側では、「それがどのようなサーピスな のか」を含んだかたちてサービス名の決定と提供をおこな う必要がある。 サーピスロケーション・プロトコルはインターネット全 体における解決をおこなうシステムではなく、サービスを 共有する企業内ネットワークなどに限定しており、企業内 ネットワークを意識しているようである。 RFC2167 Referral Whois (RWhois) Protocol VI. 5 RWHOIS プロトコル第 1.5 版 fo. 、 S. WiIIiamson 他 ( RFC1714 置キ奐 ) RWHOIS (ReferraI Whois) プロトコル第 1.5 版に ついて述べている。、、広報 " として公開されている。 RWHOIS は、検索およびディレクトリ情報の一崧ア管理 を実現するクライアント・サーバー型の分散システムであ る。 RFC2167 では、 RWHOIS で用いられるディレク トリ自体のアーキテクチャおよびディレクトリアクセス・ プロトコルの双方について定義している。 RWHOIS プロ トコル定義部分では、クライアント・サーバー間の通信規 約を規定している。 RWHOIS クライアントによるサー ー上の情報検索や更新方法、サーバーおよびクライアント 上における情報解釈方法について言及している。アーキテ 108 クチャ定義部分では、 RWHOIS の思想的背景を解説し、 RWHOIS プロトコルやディレクトリ構造の設思想につ いて触れている。 RFC2170 AppIication REQuested Ⅲ over ATM (AREQUIPA) アプリケーション要求型旧 over ATM (AREQUIPA) fo. 、 W. Almesberger 他 AREQUIPA (Application REQuested IP over ATM) について述べている。、、広報 " として公開されて いる。 AREQUIPA は ATM (Asynchronous Transfer Mode) に接続されており、 ATM 網でエンドッーエンド の IP over ATM 接続が可能なホストにおいて、アプリ ケーションからの要求に応してそのアプリケーションに対 する専有的利用を許可するガ去である。これによって要求 したアプリケーションは、 ATM か本来もっている QoS (quality of service) の保証性能を享受できるとしている。 AREQUIPA で採用されている方式を使う利点は、 NHRP や RSVP のように ATM 網内のスイッチやレー タに対する変更か必要なく、この方式を利用するホストだ けに実装す川まよいことである。 RFC2170 では、 IPv4 および IPv6 カ鍾川しているホ ストへの AREQUIPA の実装について言侖している。実 例として、 AREQUIPA を利用した WWW アプリケー ションが Q 。 S ー焉正されたドキュメント酉占をおこなえる ことを示している。セキュリティにも言及している。 RFC2178 OSPF Version 2 OSPF 第 2 版 PS. 、」 . Moy ( RFC1583 置換 ) OSPF (Open Shortest path First) の仕様を定義し ている。現在の状態は、、標準化への提唱 " である。 OSPF は IGP (lnterior Gateway protocol : 内部向 けゲートウェイ・プロトコル ) に分類される TCP/IP にお ける経路制笹ロ。ロトコル、つまり単一 AS (Autonomous system) 内の経路制御で用いられるプロトコルである。 OSPF 自体の角見は、糸各制御に関する他の文献に譲る。 RFC2179 Network Security For Trade Shows. トレードショーにおけるネットワーク・セキュリティ fo. 、 A. Gwinn UNIX MAGAZINE 1997.10

S : * OK [UIDVALIDITY 1 ] S : A001 OK SELECT completed C: A002 IDLE ← IDLE コマンドの発行 S: + idling ( 新しいメールが届くまで待っ ) S : * 4 EXISTS ←新しいメールが届いたことを通知 C: DONE ← IDLE コマンドの終了 この例からも分かるように、 IDLE コマンドはネット ワークに負荷をかけることなく前述の目的を達成できるよ うに言 t されている。 RFC2180 lMAP4 MuIti-Accessed MaiIbox Practice IMAP4 におけるメールポックスへの並列アクセス 旧 fo. 、 M. Gahrns IMAP4 におけるメールポックスへの並列アクセスにつ いて述べている。、、広報 " として公開されている。 現在の IMAP のイ兼では、クライアント・サ→ヾー間 の通信の際に、同し操作をおこなったとしてもかならすし も同一の結果を得ること呆証されていない。 例として、複数のクライアントが 1 つのメールポック スに同時にアクセスし、あるクライアントがメールポック スを削除した場合を考える。このような操作に対するサー バーの挙動はサーバ ーごとに定義されるポリシーや実装の 差異によって変化してしまう。たとえは、そ作を容認 するサーバーもあれは、なんらかの制限をおこなうように なっているサーバーも存在する。 このようにさまざまなサーバーの実装によって重川乍が異 なると、そのための対処をクライアント側でおこなわなけ れはならないので、クライアントの負荷カ吠きくなってし まう。したがって、メールポックスへの並列アクセスに対 する相坊用性の保証が必喫と考えられる。 RFC2180 で述べられている内容は既存の IMAP サー バーの挙動や IMAP メーリングリストによる言龠にもと づくものであり、大半は RFC2060 に定義されていると おりである。また、 IMAP4 における挙動を決定しようと いうものではなく、さまざまなケースを糸忙的に述べるも のにすぎない。 RFC2180 に当されている言龠の各を 以下に示す 1. 概略 2. 本 RFC における用語について 3. 並列アクセス時のメールポックスの削除 / 改名 3.1. 失敗を返すサー UNIX MAGAZINE 1997.10 RFC ダイジェストー① 3.2. 削除可能だが、メールポックスにアクセスしている クライアントがあるかぎり情報尉寺するサー 3.3. 削除 / 改名ともに可能だが、 BYE を送ることで他 の全クライアントとの通信を終了するサーバー 3.4. 単純にメールポックスの名前を変更することて改名 をおこなうサー 4. 並列アクセス時のメールポックス内のメッセージの削除 4.1. 削除されたメッセージの取彳 4.1.1. 削除可能だが、 EXPUNGE ( 削除済み通知 ) を他のクライアントに通知するまでは FETCH ( 取得 ) コマンドのために情報をイ : 苻早するサー 4.1.2. 削除可能で、 FETCH コマンドに対しては未 削除のメッセージだけを返答するサー 4.1.3. 削除可能で、 FECTH コマンドへの返答は削 除されてしまったメッセージに対しては、、 NIL FETCH Responses" を、その他は通常と同じ 挙動を示すサーバー 4.1.4. 削除を禁止することで、このような状況を起こ さないサーバー 4.2. 削除されたメッセージの保存 (STORE) 4.2.1. サフィックスに、、 . SILENT " が付いており、 未削除のメッセージの保存か完了した場合、サ ーは OK を返すべきである 4.2.2. サフィックスに、、 . SILENT " が付けられす、 かっ削除されたメッセージだけが参照された場 合、サーバーは NO を返すべきである 4.2.3. サフィックスに、、 . SILENT " が付けられす、 かっ削除済み / 未削除の双方が参照された場合、 サーバーはフラグをセットしてから、未削除の メッセージに対する返答をおこなってもよい 4.2.4. サフィックスに、、 . SILENT " が付けられす、 かっ削除済み / 未削除の双方が参照された場合、 サーバーはフラグをセットせすに NO を返して もよい 4.3. 削除されたメッセージに対する検索 4.4. 削除されたメッセージの複写 4.4.1. 削除済みメッセージを含む COPY を禁止し うるサー 107

表 1 lynx のおもなキー操作 キ スペース ( + ) ↓ (TAB) → ( リターン ) 機能 画面を下にスクロール 画面を上にスクロール 次のハイバーリンクへカーソルを移動 前のハイバーリンクへカーソルを移動 ハイバーリンクをたどる 1 つ則のページに戻る ヘルフ画面を表示 lynx の終了 ( 石忍あり ) 強匍了 ( 石忍なし ) 住内のキーでも同し操作が可育 ちゃうか。開けてびつくり玉手箱、てなもんや。 か想像がつかへんっていうのも、けっこうおもろいんと monkey : どこまて割りきるかやな。でも、どんな科理 ないとどんなお料理か想像しにくいもの。 : はったらかしになってた PC が、この半年で ☆ monkey : ちょっとワクワクするけど、やつばり不安の あつぶる : しゃあ、阜晩は lynx で選んだお料理にしよ monkey はうが・ っと。 UNIX MAGAZINE 1997.10 回でおしまいです。 monkey 君の家のように、マシンが HomeLAN を構築する話から始まったこ窈与集も、今 monkey : いえ、なんでもありません・・ あっぷる : なんか言った ? monkey : umpc よ、お互い大変ゃなあ。 もっと充実させるためにもね。 あつぶる : もちろん。、、おうち " と、、おうちの LAN " を、 ん働け " って言ってる ? monkey : それって、もしかして、わしに、、じゃんじゃ といけないんだから。 て、 applepc のためにじゃんしゃん働いてもらわない あっぷる : そりやそうよ、 umpc には長生きしてもらっ monkey : あつぶるちゃんにしては、えらくしおらしい るわ。 用価値があるって、ちょっぴり分かったような安仂ゞす あつぶる : そうねえ。古くなった PC にもそれなりの利 ーまで成長したもんや。 よっこ おうちでらんラン LAN 第 6 回 Wide Web プラウサ編 ( 2 ) 」、 UNIX MAGAZINE 1995 [ 10 ] 岡山聖彦、片山喜章「 UNIX の道具箱 ( 13 ) ー WorId ber 1994 ル 7 、 rn Resource ん oc 0 ” ( U 月ん去 RFC1738 , Decem- [ 9 ] T. Berners-Lee, L. Masinter and M. McCahill, Uni- 号、 8 月号 を使おう ( 1 ) ~ ( 2 ) 」、 UNIX MAGAZINE 1995 年 6 月 [ 8 ] 岡山聖彦・片山喜章「 UNIX の道具箱 ( 10 ) ~ ( 11 ) ー Mew 書こうよ UNIX 」、 UNIX MAGAZINE 1997 年 3 月号 [ 7 ] 岡山聖彦・片山喜章「モーレッ UNIX 教室 ( 10 ) ーお手紙 CT e ロ佖佖れ d ExampIes, RFC2049 , December 1996 MaiI Extensions (MIME) Par ・ t Five: Co れ / ・ ma れ ce [ 6 ] N. Freed and N. Borenstein, れ↓比ゆ ut ァ ose / れれ なこ ra 厖 0 れ Procedures, RFC 2048 , January 1997 んロ肥 MaiI 月 e れ s を 0 れ s (MIME) P のイ Fo 盟、 : 月 eg ー [ 5 ] N. Freed, J. Klensin and J. Postel, イ t ゆ盟ァ ose 和 7 ・ル 0 れ - 員 SC 〃・ Text, RFC2047 , December 1996 れ s れ s 丿 P のイ T ん 7 ℃ e : Message 〃 eader 、 Eætensions [ 4 ] K. Moore, MIME い石襯ゆ盟ァ ose lnternet Mail Ex- RFC2046 , December 1996 MaiI 月厩 e れ s れ s (MIME) P 礰イ Two: 市佖 Types, [ 3 ] N. Freed and N. Borenstein, イれゆ ut ア ose / れ tet 、れ己 7 れ et Message Bodies, RFC2045 , December 1996 MaiI Ea;tensions い一 / 1'1 イ E 丿 P 礰イ 0 れ e : Fo ロれ . 観可 / ル [ 2 ] N. Freed and N. Borenstein, れぇ〃ゆ盟ア ose / れ ter ・れ et 1982 0 工ス P. 員ん ter れ屋 Te:rt Messages, RFC822, August [ 1 ] David H. Crocker (rev. ), S れ da F の・ The F07 、 rn 観 [ 赭文献 ] 奈良先立胼斗学オ支術大完大学 ) ( おかやま・きよひこ、かたやま・よしあき monkey& あっぷる : それでは皆さん、また来年 ( ん ? ) 。 ればさいわいです。 ンカ鯤在するような Home LAN を作る際のヒントにな しかし、これから皆さんが UNIX と Windows 95 マシ 実用的とは思えないようなものがあったかもしれません。 この特集て紹介したトピックのなかには、かならすしも りも便利に感しることができるでしよう。 でファイルを共有するだけで、それぞれを独立して使うよ ワークです。凝ったことをしなくても、ネットワーク経山 たった 2 台しかなくても、それをつなけは立派なネット 年 11 月号 37

上が見込めるのでマルチキャストを活用するようになって いる。 URI/URL/URN 関連 RFC2168 ResoIution of Uniform Resource fiers using the Domain Name System DNS を禾堋した U 解決 Exp. 、 R. DanieI 他 ldenti- DNS (Domain Name System) を利用した URI (Uniform Resource ldentifiers) 角夬について述べてお り、、、経験 " として公開されている。 URL (Uniform Resource Locator) は WWW の 本疉をなしており、昨今ではそれ以外にもさまざまなイン ターネット技術に必須のものとなっているにもかかわら す、きわめて脆弱であるといわれている。最大の問題は、 URL か特定のホストの特定のファイルを指し示すもので あること、つまり場所に依存しすぎている点である。 URL を一度決定して情報を提示するようになると、変更を周知 するシステムか、存在しないため、容易には変更できない。 また、場所そのものを指し示しているため、複数サー をネットワーク的に異なる場所 , 己置して耐拠尉生を高め ることや、ユーサーからの距離に応じて配布する内容を決 定するために複数の複製を作成 / 配置することもままなら ないのか現状である ( そのための特別な機械やプロトコル はいくつか存在するが、オ剽勺なものではない ) 。 これらの欠点を解決するために、 URL に付加する要 素として URNs (Uniform Resource Names) か提 案されている。 URN 解決システムの仕様書では RDS (Resolver Discovery Service : リゾノレ甘架索サーヒ、ス ) という概念カ甘是示され、 URI からドメイン名への変換ル ールを提供するシステムか解説されている。これは、新し い DNS のリソースレコードである NAPTR (Naming Authority PoinTeR : 名前付けオーソリティ・ポインタ ) を利用する方式である。 この方式を用いて変換ルールを変更すれは、 URI て示 されるリソースを得るために通信するホストか変更可能と なるので、前述の問題点を鮹夬することはもとより、より 柔軟に URL を利用できるようになる。 RFC2168 では DNS の NAPTR-RR の記述能力に ついて言及し、豊富な言己西列とともに角見している。標準 104 化の過程にはない RFC だが、技頑勺な方向性やユーザー の必喫性の観点からは今後の展開か期待される。 RFC2169 A Trivial Convention for using HTTP in URN Resolution HTTP を URN 解決に利用する際の→殳的な夬め Exp. 、 R. DanieI HTTP を URN 角夬に利用する際の一ヨ勺な取夬めに ついて述べている。、、経験 " として公開されている。 URN-WG (URN ワーキング・グルーフ ) は、永続的 で場所に依存しない名前でネットワーク中のリソースを扱 える去と、そのような名前から実際のリソースを検索す る去に関する言侖をおこなっている。 現在、 URNÄÅ℃はそのための欟冓として NAPTR を 提案している。 NAPTR は、クライアントが、、リゾルバ (resolver)" と呼はれるデータベースを発見するための仕 組みである。リゾノレヾは、 URN により識別されるリソー スの場戸丿 i& 履歴情報、リソース自体尉寺する。 NAPTR では、 URI 解決に利用するための新しいリ ソースレコードとして、 DNS にサーピス (services) フ ィールドを定義している。このレコードは、リゾルバか利 用する、、解決プロトコル " と、リゾルバカ甘是供する、解決 サーピス " に関する情報を提供する。 NAPTR 仕様では、解決サービスとして N2L (URN から URL への変換 ) や N2R (URN から名前のあるリ ソースへの変換 ) などを挙げている。解決プロトコルとし ては、 Z3950 、 THTTP 、 RCDS 、 HDL 、 RWHOIS の 利用について言及されており、これらは今後も増大すると 思われる。 RFC2169 では、これらの解決プロトコルの 1 つであ る THTTP (Trivial HTTP) の仕様を記述している。 THTTP は、解決サーピス要求とその回答を、 HTTP 1.0 および 1.1 の要求 / 回答に変換するための簡単な手法 を定義している。 THTTP は、既存の HTTP サーバー に容易に URN 解決欟冓をイ寸加できるような簡単な実装の 実現を目的として言 t されている。 2 番目の目的としては、 URN 解決プロトコル仕様その ものの手本になることか挙げられている。他の角夬プロト コルを利用できるまでにはまた時間がかかることが予想さ れるため、ます THTTP のイを作成して参照できるよ うにしてある。 UNIX MAGAZINE 1997.10