RFC - みる会図書館

1. UNIX MAGAZINE 2000年2月号

RFC ダイジェストーの表 1 今月扱った RFC IP イ元ー RFC2728 テレピ信号の VBI を利用した IP 伝送 RFC2734 IEEE1394 上の IPv4 マルチキャスト RFC2729 大規模マルチキャスト・アプリケーション用の通信に関する要求事項のう頁 RFC2730 マルチキャスト・アドレス重加勺クライアント割当てプロトコル URL/URN RFC2717 URL スキーム名の当求手続き RFC2718 新規 URL スキーム定義のためのガイドラインメタデータ RFC2731 Dublin Core メタデータの HTML における言当力 1 去プリンタ用ジョフ監視 MIB 鏈 RFC2707 ジョフ監視 . MIB 第 1 版 RFC2708 ジョフ監視 MIB 用のジョフ般入プロトコルへのマッピングに関する推奨頁 1. プリンタジョブの状況と進捗の監視 2. ジョブを進める前の資源要求の獲得 3. ジョブを処理するための資源消費量の尉見 4. ジョフ院了時の資源履歴の収集 RFC2707 の冒頭には、「 IESG Note (IESG による見解 ) 」カ寸加されている。内容を以下に示す。「この MIB モジュールは MIB 的な例に従わない管理情報に関するスキームを用いており、列的な MIB になっている。 IESG は、この文書での言己を、あくまでも今後 MIB を言 1 する際のヨ列として扱うことを勧告する。、、プリンタ分科会 " は業界のコンソーシアムで、 IETF のうト会ではない。 IETF ではこの分科会を標準イ士様規定団体とは考えていない。この文書は、商用利用されているこの MIB の情報を、インターネット・コミュニティに提供するために公開された。本 RFC の公開は、この MIB についてなん引焉正を付加するものではない」 RFC2708 」 ob Submission Protocol Mapping Recom- UNIX MAGAZINE 2000.2 らかのジョフ轂入プロトコルをサポートしているデバイス RFC2707 で定義されているジョブ監視 MIB は、なん 1999 年 11 月に公開された。ピングに関する推奨頁を提案している。、、広報 " としてジョブ監視 MIB 用のジョブ投入プロトコルへのマッ fo. 、 R. Bergman グに関する推頁ジョフ監視 M 旧用のジョブ投入プロトコルへのマッピン mendations for the 」 ob Monitoring M 旧やサ→ヾーに実装されることを仮定している。しかし、・ NetWare NPRINTER/RPRINTER ・ NetWare PSERVER ・ PostScript ・ PJL (Printer Job Language) ・ NDPS (Novell Distributed Print Service) ・ DPA (Document Printing Application ・ IPDS (lntelligent Printer Data Stream) ・ IPP (lnternet Printing ProtocoI) ・ AppleTaIk プロトコル・ LPR/LPD プロトコル的には、以下に小すプロトコルとシステムを扱っている。 ( ジョブの投入に関する識別子など ) を定義している。具体トコルやシステムについて、マッピングに関する要求事項 RFC2708 では、ひろく利用されているジョフ才殳入プロマッピングする一勺な方式が必になると考えられる。プロトコルのジョブ投 . 入情報をジョフ監視 MIB の形式にれらのジョフ般入プロトコルは多種多様であるため、各種今回扱った RFC を表 1 にまとめる。次回は 1999 年まとめ ( うお・ようしろう、おがしわ・のぶお、おおた・さとしを紹介する。 12 月中旬から 2000 年 1 月中旬にかけて公開された RFC 143 北陸先立斗学オ支術大完大学 )

2. UNIX MAGAZINE 2000年2月号

・スキームの構文と意味を、、、 Informational"RFC または、、 Standard Track"RFC として公開しなけれはならない。たいていは Standard Track RFC であることか要求される。 lnformational RFC は既存のスキームを公開するときなどには利用されない。また、 lnfor- mational RFC として公開されたものが、 Standard Track RFC として書き直されることもありうる。・ IETF カ畴斤規に登録する URL スキームによって新たなセキュリティ上の問題が生しないようにするため、セキュリティに関する考察は必須である。 ( ハイフン ) を使用してはならない。・スキーム名に・新しい URL スキーム名は RFC2396 での定義に合致していなけれはならない。・ URL スキーム名の所有者は IETF 自体になる。 RFC2717 では IETF の管理下にないツリーについても言及している。このツリーについては IETF ツリーほどの厳密さは要求されないが、おおむね IETF の登録に関する手順に処することか望ましいとされている。 IETF ツリー以外の新しい最 - E 位レベル登録ツリーは、そのツリーを必要とするコミュニテイからの要求にもとづき IESG によって作成される。新しいツリーが作成されるのは、そのコミュニティの要求に適した既存のツリーがない場合のみである。これらのツリーにどの稍隻の登金ゞされるかや、管理が IETF 以外の主体に委ねられるかなどはその点では未定である。 RFC2717 では、そのうえで、 IETF ツリーへの新規登録用テンプレートか規定されている。このテンプレートを記述する際には、スキームの文法を規定するためのガイドラインである RFC2718 を参照することカ甘隹奨される。 RFC2718 GuideIines for new URL Schemes 新規 URL スキーム定ためのガイドライン旧 fo. 、 L. Masinter 他新規の URL スキームを定義する際の注意点について論している。、、広報 " として 1999 年 11 月に公開された。新規の URL スキームの定義にあたって、 RFC2718 で孑商されている留意点を以下に示す。・既存のスキームとの互換生異なる名前空間に対する明確な対応づけ・ネットワーク・プロトコルとの関連づけ UNIX MAGAZINE 2000.2 SC 翡たのしい UNIX IJN Ⅸへの招待坂本文著本体し 845 円 LJNIX をっと″たのしく学べる入門書 QJNIX MAGAZINE 」里載当初力、ら好評の田 NIX への招待」を単行本化。 UNIX の根底にある文化や流儀をまじえつつ再構成、大幅加筆。ワークステーションの急速な普及によって UNIX の習得が急務と言われ見在、まさに必言 ) 1 冊。続・たのしい IJN Ⅸ シェルへの招待坂本文著本体し 845 円「 LJN Ⅸへの招待」単行本第 2 弾シェルは UNIX の世界のいわば「裏方さん」。その動きや仕組みを知れば、 UNIX がいっそう楽しく、便利にイ屯えるようになる。本書は、ひろく使われている C シェルを中心に、シェルの使い方から仕組みまて、をう、りやすく解前巻とともに入門者必携の 1 冊。ハッピー・ネットワーキング新入生のためのインターネット入門山本和彦著本体し 456 円豊富な実例で学ぶインターネット世界各地の二百数ート万台ものコンヒ。ュータを結ぶ巨大なネットワーク、インターネット。利用て、き・阯竟にありながら使い方が分からずに著している人たちを対象に、 UNIX 上の Emacs を使ったメールやニュースの読み書き、ファイル申幻医の仕組みなど *efi 文書タ里システムラ・テックレスト・ランポート著、エドガー・クック、倉沢良一監訳、大治、小暮博道、藤浦はる美訳本体 2 , 18 円使いやすさと豊富な機能を備えたマクロ・バッケジい TEX は、もっとも進歩した組版システムといわれる X の実用性をさらに高め、使いやすくしたマクロ・パッケージ。これを利用すれば、複ょ数式すらユーザー自身の手て、自在にレイアウトて、きる。開発者の手による見書の決定版。 S LJ N システム管理下山智明、城谷洋司共著本体 6.796 円 SunOS 4 ココ (SPARC system 、 Sun3) 対応 TFS 、 RFS の機能のほか、マニュアルて、は見つけにくい dump 時のパラメータやテープの不頁、オートマウントの設定を詳説。さらにシステムにトラブルが生じた際の対処方法、メモリ UNIX やミニルートの使い方など、システム管理に必要な情報を満 Life with LJNIX IJN Ⅸを愛するすべての人にドン・ライプ、サンディ・レスラ共著、坂本文監訳、福夋博訳本体 2. 引 3 円だれも知らなかった IJNIX の魅力の世界 UNIX の歴史的背景や社会動向とともに、 UNIX の技術面や市場面、今後の展望などを幅広く解説。また UNIX 人名辞典、アングラ情報、名言などの貴重なデータや一風変わった情報を満載、 UNIX ューザーに新しいネ甅予を提供する好言勿。「 00t から / へのメッセージ高野豊著本体し 553 円人とコンビュータを観察するスーバーユーサーの目日本に UNIX が導入されたばかりの頃、管理者を任された著者の苦闘し験をつづる。著者が、今日まて、めぐりあったさまざまなェヒ。ソードを紹介。夋に富む告白談と、飽くなき探求心の物語は、システム管理者に限らず多くのユーザーの共感平ぶだろう。 ※表示価格には消費税は含まれません。ルート株式会社アスキー〒 151-8024 東京都渋谷区代々木 4-33-10 株式会社アスキー出版営業部電話 ( 03 ) 535 ト田 94 141

3. UNIX MAGAZINE 2000年2月号

RFC ダイジェスト宇夫陽次朗、小柏伸夫、太田悟史この号が皆さんのお手許に届いているということは、 Y2K 問題は無事に乗りきれたということだろうか。インターネットも最初の千年紀 ( の境界 ) を越えたことになる ( といっても、、、本来は " 次の千年紀の始まりは 2001 年からであるが、なぜか世間では今年からとなっているので、ここはあえてそういうことにしておこう ) 。最初の千年紀 ( の最後の約 30 年 ) のインターネットは、 development と deployment の期間であった。つまり、人類が手にした唯一の広域な、、 Inter-Network" という概念の実装を創出し、広めていく歴史であったといえる。特筆すべき点は、その歴史のなか侖されてきた大半の事柄が RFC や他の文書として現存していることである。新たな千年紀 ( 本当は来年から ) に入ったインターネットはどう変化していくのだろうか。近い将来においては、現在 IETF て滸侖や研究が重ねられているさまざまなトピックの実用化の歴史になるだろう。現在の IETF では、、インターネットの高品質化 / 高速化 " に関するトピックが数多く言侖されている。 Intserv/Diffserv などの QoS/CoS 技術や MPLS などの高速イ支術、さまざまな帯域管璢支術や輻輳制御肢術の多くは、近い将来に実際のインターネットでひろく利用されることになるだろう。長期的なネアて考えることも重要である。概勺にいえば、、、インターネットがインターネットであること " にはごくわすかな制約恥頁しかない。したがって、ゆっくりと、だカ蔀寉実に、その性質は現在とは異なる、、何か " に変貌していくと考えられる。続く千年紀におけるインターネットの発展について考えることは、新たな千年紀の幕開け ( と 20 世紀最後の年 ) にふさわしい話題であろう。 RFC を追いかける日々にふと疲れたときに、すこしだけ遠い将来に思いを馳せてみる 138 のはどうだろうか ? 今回の RFC UNIX MAGAZINE 2000.2 おもな信号の流れは以下のようになる。 Correction) カリ用されている。 NABTS と IP のあいだには FEC (Forward Error タグラム形式を定義している。伝送工ラーを防ぐためにの伝送方式で用いるレイヤ構成と、各種プロトコルのデーータグラムを送る方法を定義している。具体的には、 Standard : 北米基本テレテキスト標準 ) を使って IP デ一舟勺な NABTS (North American Basic Teletext RFC2728 では、 VBI によるデータ通信方式としてでもさまざまなデータ通信方式カ甘是案されている。号の隙間ともいえる VBI を利用するものが多く、これま効である。テレビ信号を用いたデータ通信には、テレピ信数のユーサーに単方向の情報伝達をおこなう手段として有テレピ信号は広い範囲にわたって利用可能な関本で、多 posed Standard) " である。 1999 年 11 月に公開された。法を定義している。現在の状態は、、標準化への提唱 (Pro- 直帰線消去期間 ) を利用して IP バケットを伝送する方テレピ信号の VBI (Vertical Blanking lnterval : 垂 PS. 、 R. Panabaker 他テレビ信号の VBI を利用した旧イ元医 Blanking lnterval of a Television Signal RFC2728 The Transmission 0 日 P Over the Vertical IP イ云送関連開された RFC である。今回扱うのは、 1999 年 11 月中旬から 12 月中旬に公

4. UNIX MAGAZINE 2000年2月号

図 1 IPVBI のレイヤアプリケーション UDP S 凵 P 形式カプセル化 FEC NABTS NTSC など CATV/ 電波などピデオ信号→ NABTS → FEC →シリアルデータ・ストリーム→フレーミング・プロトコル→圧縮形式 UDP/IP ヘッダ→アプリケーションレイ成を図 1 に示す。 RFC2734 旧 v4 overlEEE 1394 旧 EE1394 上の旧 v4 PS. 、 P. 」 ohansson 高速シリアルバスである IEEE1394 仕様を用いた IP 伝送を定義している。現在の状態は、、標準化への提唱 " である。 1999 年 12 月に公開された。 IEEE1394 は、高速シリアルバスとしてさまざまな用途か想定されている。とくに、ホーム・ネットワーク橳課などにおける汎用高速伝各として期待されている。このような用途では、 IPv4 データグラムの伝送は必須機能となる。そこで RFC2734 では、 IEEE1394 ー 1995 の仕様にのっとって IPv4 データグラムを伝送する一漣のシステムを定義している。おもな内容を以下に示す。・ IEEE1394 のセマンティクスにもとづいたデータの取・フォーッ UNIX MAGAZINE 2000.2 トへのカプセル化 —IP データグラムの IEEE1394 フレームーアドレス・マッピング —IP データグラムを扱うために必な操作扱い RFC ダイジェストーの・シリアルバスに特有なプロトコル群れぞれのアプリケーションか暗黙裡に要求している頁を具ー勺には、通イ髜罸生を示すパラメータを定義して、そクリストとして利用することも想定されている。アプリケーション自体や関連プロトコルの言 1 時のチェッを寉化することによって、その結果をマルチキャスト・することを目的としている。アプリケーションごとの要求では共通部分を定義し、最低限の概要を理解できるように LSMA の内容は多岐にわたっているため、 RFC2729 て、その通イ謝讚生を分類するためのガ去を提案している。チキャスト通信をおこなう各種のアプリケーションについするさまざまな孑票が必喫になる。 RFC2729 では、マル大規模アプリケーションをう頁するためには、分類に関月に公開された。している。、、広報 (lnformational)" として 1999 年 12 用いられる通信に関する要求を分類するためのガ去を提案大規模マルチキャスト・アプリケーション (LSMA) で fo. 、 P. BagnaII 他る要求頁の分類大規模マルチキャスト・アプリケーション用の言に関す for Large-scale Multicast AppIications RFC2729 Taxonomy of Communication Requirements マルチキャスト関連ー MCAP : マルチキャスト・チャネル割当てプロトコルー 1394ARP : IEEE1394 用のアドレス角夬フ。ロトコルー構成要素の信頼性に関する項目ーノヾケットロス・信頼生明示できるようになっている。・川印判罸生・日判り特性ー実時間性、同期性、バースト性、る特性セッションーセッションの管理に関する項目ジッタなどに関すーセッション・トボロジーに関する項目・ディレクトリの特性・セキュリティ特性 139

5. UNIX MAGAZINE 2000年2月号

図 2 DubIin Core メタデータの HTML における記述例・フォーマットく html> く head> く title> A Dirge く link rel href く content = く content く meta name content く met name content く met name content く /title> 'schema . DC" "http ://purl.org/DC/e1ements/1.0 / " > "DC . Tit1e" "A Dirge"> "DC . Creator" "SheIIey, Percy Bysshe"> "text/html"> "DC . Format" " 1820 " > "DC . Date" "DC. Type" プロトコルと勵里づけされないスキーム・データリソースと里づけされないスキー・文字工ンコーディング・操作の定義ムこ数年、スキーム名の後ろに、、 / / " を付加する例がいくつかみられる。「 Uniform Resource ldentifiers (URI) : Generic Syntax 」 ( RFC2396 ) では、、、 / / " はスキームか楷層的な構造をもっことを示す場合に用いると定義している。スキームが階層的な橢匿をもたない場合に、 / / " をスキーム名の後ろに付加することは、スキームの不正な定義であり、避けるべきである。 URL および URI は RFC2396 で、新規の URL スキームの登録手順は RFC2717 でそれぞれ定義されている 9 メタデータ関連 142 で言当するガ去について具イ勺に説明している。 RFC2731 では、以下に示すエレメントを HTML 4.0 するために用いられる。に記し、リソースのタイトルや著者名などの属性 &f 尉寺メントは、 HTML や XML などで表現されたリソース内メントの集合である。 Dublin Core メタデータの各エレタイトルや著者名などの属性を言己するメタデータのエレ RFC2413 で定義される Dublin Core は、リソースのて 1999 年 12 月に公開された。 4.0 で記述する方法について説明している。、広報 " とし Dublin Core のメタデータの各エレメントを HTML fo. 、」 . Kunze Dublin Core メタデータの HTML における記述方法 RFC2731 Encoding Dublin Core Metadata in HTML "DC. Language" く met a name content = く /head> く body> く pre> Rough wind , that moanest loud Grief t00 sad for song; Wi1d wind, when su11en cloud Kne11s a11 the night 10 Ⅱ g ; Sad storm, whose tears vain, Bare woods , whose branches strain , Deep caves and dreary main , Wai1 , for the world' s wrong ! く /pre> く /body> く /html> Publisher : リソースの発彳丁者の名前 Description . コンテンツの机要 Subject : コンテンツのトピックまたはキーワード Creator : コンテンツイ友者の名前 Title : リソースの名称 Contributor : Creator 以、タトのコンテンツイ及名 - の名則 Relation コ里するリソース Language : コンテンツをロ当する言 Source : リソースの情幸原 ldentifier : リソースの筬別子 Format : 物理的または電子的なデー Type : リソースの分類 Date : リソースが作成された日時タ Rights : 著イ料の帰属 Coverage : コンテンツの直用 ul 用 Dublin Core メタデータの HTML での言当列を図 2 以下の点を目的としている。て言妬されている。プリンタとプリンタサーバーに実装さジョブ監視 MIB は、プリンタでの利用のみを考慮しに公開された。監視 MIB を定義している。、、広報 " として 1999 年 11 月プリンタのジョフ監視を目的とした MIB であるジョブ fo. 、 R Bergman 他ジョフ監視 M 旧第 1 版 RFC2707 」 ob Monitoring M 旧ー VI. 0 プリンタ用ジョブ監視 MIB 関連 UNIX MAGAZINE 2000.2

6. UNIX MAGAZINE 2000年2月号

訒証の強度、タンパープルーフ、 DoS 攻撃に対する川じ、強度などにかかわる搨生群課金に関する特生それそ、れの分業頁目は、以下に示す内容で構成される。・注、意事項アプリケーション例適用範囲 ( ストリーム / セッション / ユーサー単位など ) ・厳密な要求条件項目の意味についての説明・型によるう嶽頁 140 ・ノヾーーシンヨン一を含む。ヘッダには以下の情報が含まれる。り、固定長のヘッダと可変長のオプション・フィールドる。 MADCAP メッセージは UDP データグラムであードキャストで送信され、返答はユニキャストで送られ MADCAP サーバーに向けてユニキャストもしくはプロクライアントからのアドレス割当て要求は、 1 つ以上のライアント・サーバー型で構築されている。 MADCAP MADCAP は DHCP をもとにしたプロトコルで、クチャの一にだが、独立して用いることもできる。論されているマルチキャスト・アドレス割当てアーキテクの MAA (Multicast Address Allocation) う斗会で言義の割当てを受けるために用いるプロトコルである。 IETF ト・アドレス割当てサーバーからマルチキャスト・アドレス RFC2730 で定義される MADCAP は、マルチキャスもに青勺な設定に頼っているのか現伏である。ャスト・アドレスに必要な情報を折衝する欟冓はなく、お法カ球められるようになってきた。現在のところマルチキプリケーションで用いられるアドレスを簡単に設定する方マルチキャストか普及するにっマルチキャスト・ア準化への提唱 " である。 1999 年 12 月に公開された。トコル (MADCAP) を定義している。現在の状態は、、標マルチキャスト・アドレス重加勺クライアント割当てプロ PS. 、 S. Hanna 他コ ) レマルチキャスト・アドレス動的クライアント割当てプロト tion Protocol (MADCAP) RFC2730 Multicast Address Dynamic Client AIIoca- ・メッセージ型 (msgtype) ・アドレス・ファミリー (addrfamily) ・処理識別子 (xid) さらに、マルチキャスト・アドレスの一イ勺貸出しを実現するために、リース識別子、リース時間、開女都間などのオプションか設けられている。 URL/URN 関連 RFC2717 Registration Procedures for URL Scheme Names URL スキーム名の登録手続き BCP. 、 R. Petke 他 ( 別 BCP 35 ) IETF カ壻理する URL スキーム名ツリーに対する登録手続きを紹介している。ン点での最良のガ去 (Best Current Practice)" として 1999 年 11 月に公開された。 BCP シリーズ (BCP 35 ) としても公開されている。 RFC2396 では、 URL (Uniform Resource Locator) にスキーム ( リソースにアクセスするための去 ) を指定する文字列を含めることになっている。指定に用いる文字列を、、スキーム名 " と呼び、ツリー構造にもとづいて管理される。スキーム名ツリーに新しいスキームを追加する際には、なんらかのルールが必要である。スキーム名を登録するツリー構造は 1 つだけでは足りないと考えられており、将来的に複数のツリー構造か導入されると思われる。 RFC2717 では、 IETF か可有・管理しているスキーム名ツリーに対して規定されている点での管理手法を紹介している。この管理手法は IETF 以外の他のツリーを管理するうえでの参考としても重要であるため、 RFC2717 は BCP シリーズとなっている。 IETF か管理する UR 、 L スキーム名ツリーに新しいスキーム名を登録するには、以下の条件を満たす必要がある。・明文化された検討および認証プロセスを経る。その際適用されるアプリケーションへの通öl 生を示すことか望ましい。また、実装やサポートなどの結果として、そのスキームの有用性の実証を要求される場合もある。・新しい URL スキーム名を導入するには、ます I-D (Internet-Draft) として公開しなければならない。すくなくとも 4 週間以 E の公開需義期間が設定されることになる。この I-D は IESG によって審査される。 UNIX MAGAZINE 2000.2

7. UNIX MAGAZINE 2000年2月号

連載 /Network Technology—O 図 6 齠以 Ethernet を用いた ADSL ネットワーク旧、 A 日 P Ethernet ファイアウォール旧、 ARP 擬似 Ethernet AAL5 ( RFC1483 ) ATM Redback ルータ擬似 Ethernet の機能 1. 上位層から宛先 MAC アドレスとバケットを受信、 Ethernet フレームにして下位層に送出 2. 下位層から受信した Ethernet フレームから Ethernet ヘッダを取り除き上位層に送出図 7 隣の IP アドレスに traceroute してみる traceroute t0 192.168.1.11 ( 192.168.1.11 ) , 30 hops max, 40 byte packets 1 192. 168 . 1 .254 79.953 ms 30.922 ms 45.442 ms 2 192. 168 . 1 . 11 63.625 ms 26.417 ms 26.263 ms 図 8 隣の IP アドレスに traceroute した tcpdump の結果 15 : 03 : 05.339269 who-has 192 . 168 . 1 . 11 tell 192. 168.1. 10 arp 15 : 03 : 05.369269 arp reply 192.168.1.11 is—at 0 : 10 : 67 : 0 : 22 : 10 . 11.33435 : udp 12 [ttl 1 ] 15 : 03 : 05.369269 192 . 168. 1 .10.34673 > 192. 168. 1 15 : 03 : 05 .389269 209.233.31 .254 > 192. 168. 1 . 10 : ICmp : time exceeded in—transit . 11 .33436 : udp 12 [ttl 1 ] 15 : 03 : 05.469269 192 . 168. 1 . 10 .34673 > 192. 168. 1 15 : 03 : 05.489269 209.233.31 .254 > 192. 168. 1 . 10 : icmp : time exceeded in—transit .11.33437 : udp 12 [ttl 1 ] 192.168.1.10.34673 > 192. 168. 1 15 : 03 : 05 .499269 15 : 03 : 05 . 519269 209.233.31 . 254 > 192 . 168. 1 . 10 : icmp : time exceeded in—transit 15 : 03 : 05 .549269 192.168.1.10.34673 > 192.168.1.11.33438 : udp 12 192. 168. 1 . 11 > 192. 168. 1 192.168.1.11 udp port 33438 unreachable 15 : 03 : 05.619269 . 10 : lcmp : 15 : 03 : 05.639269 192.168.1.10.34673. > 192.168.1.11.33439 : udp 12 15 : 03 : 05 .669269 192. 168. 1 . 11 > 192. 168. 1 . 10 : 192.168.1.11 udp port 33439 unreachable ICmp : 15 : 03 : 05.689269 192.168.1.10.34673 > 192.168.1.11.33440 : udp 12 15 : 03 : 05.719269 192.168.1.11 udp port 33440 unreachable 192. 168. 1 . 11 > 192. 168. 1 . 10 : ICmp : レスは 1 個だけです。考えてみると、加入者線 1 本ごと似 Ethernet は単一 Ethernet インターフェイスをエミレートするだけなので実装はきわめて簡単です。 LAN 工に 1 個のクラス C を割り当てているのに、そのなかの 1 ミュレーションとは異なり、複数のサーバーも必ありまつのアドレスしか使えないというのはきわめて無駄な構成です。そこで、ためしに私に割り当てられている IP アドせん。レスの隣の IP アドレス ( 192.168.1.11 ) に traceroute RFC14838 は、各種のネットワーク層プロトコルをしてみました。このときの結果を図 7 に、また tcpdump ATM の AAL5 に encapsulate する際の規格で、 Ether- の結果を図 8 に示します。 net フレームを AAL5 に encapsulate する規格も含まれ図 7 およひ図 8 から以下のことカ紛かります。ています。さら 0 = 調 ~ ると、 = 0 会社 0 ~ ータ 0 = おもしろ 0 、機 1. IP アドレス 192.168.1.11 への ARP リクエストに対をもっていることが分かりました。さきに述べたとおりし、同一サプネットに属するにもかかわらす、 IP アド PacBeII の ADSL サービスでは、各 ADSL インターレス 192.168.1.11 ではなくデフォルトルータ (MAC フェイスに対してクラス C のネットワークが 1 個すっ割アドレス 0 : 10 : 67 : 0 : 22 : 10 ) が ARP リクエストに応えり当てられます。ただし、使用できるグローバル IP アドている。すなわち、デフォルトルータは proxy ARP サーバーとして動いている。 8 現在は RFC2684 てき換えられています。 Ethernet AAL5 ( 日 FC1483 ) ATM ADSL ATU-R (ADSL モデム ) ATM ATM PHY ATM PHY ATM スイッチ ATM ATM PHY ADSL DSLAM 42 UNIX MAGÄZINE 2000.2

8. UNIX MAGAZINE 2000年2月号

ht://Dig でキャッシュの検索をおこなうには、事前に以下の 2 つの作業をしておく必要があります。 1. 曖昧語、同義語データベースの構築 ( 最初の 1 度だけ ) 2. 検索データベースの作成 ( 必要に応して ) wwwoffle のインストール時に、この 2 つの作業を自動化するスクリプトがスプール・ディレクトリにコピーされています。ます、曖昧語、同義語データベースを作ります。 # cd /var/spool/wvwoffle/html/htdig/script # sh wwwoffle—htfuzzy このスクリプトは、 ht://Dig を使う前に 1 度だけ実行します。次に、検索データベースを作成します。検索データベースは、データベース作成スクリプトを実行した時点でのキャッシュの内容をもとに作られます。ですから、ある程度キャッシュの内容か変更されたら、データベースを再構築しなけれはなりません。検索データベース作成スクリプトは 3 つあります。一からデータベースを構築するスクリプト (wwwoffle-htdig- full) 、差分を追加するスクリプト (wwwoffle-htdig- incr) 、前回のオンラインモード時にアクセスしたページを追加するスクリプト (wwwoffle-htdig-lasttime) で連載 / IJN Ⅸ知恵袋ー 0 ます。データベースが作成できたら、検索ページて検索しキャッシュの大きさにもよりますが、上交的長くかかりデータベースの作成に要する時間は、計算機の能力や # sh wwwoffle—htdig—full /var/spool/wwwoffle/html/htdig/script す。これらを、場合に応じて実行します。 # cd UNIX MAGAZINE 2000.2 かです。 Long を選ぶと、検索結果へのリンクとページのす。検索結果の表示方式は、、 Long" と、、 Short" のいすれか 1 つが含まれているべージを探す場合は Any を選びま索キーすべてが含まれるべージを探す場合は AII を、どれ本館きの不頁は、、 A 『と、、 Any" の 2 不頁てす。入力した検索キーを入力するためのエディット・ポックスがあります。検索ー、←ジには、検索の不頁、検索結果の表示方式、検 ( 図 14 ) 。ある、℃ ache Search " リンクからたどることができますてみましよう。本ページは、、、ようこそ " ページの上に図 14 ht://Dig によるべージアックマーク場所 : 新 ttp : / ハ oca 耻 ost 地 ) / htdig / s 師せ . h 1 フ守′関連サイト lvtMdPig WWWOFFLE Search Thissearchwillallowyoutosearchthecontentsofallthecacheddæumentsonthis Search; I 図 15 結果」 WWWOFFLEserver. 田℃ h 、にブックマーク 4 ーーー場所い : / / loc : 氛 0 / を / ht 記ダ ( h ? 第 e ツ守関連サイド Sea1 ℃ h results for 'ascii' Refinesearch: 第い Search D00 Ⅱ me れ 1 ー 100f 割 matches. M02 ±'sindieatea bettermatch ・ WELCOMETO ASCII CORPORATIC)N±±±± ( None 可け沱の・し、 d & し 'eret 伏盟 d ⅲ艤叩 of れ止 ) 要約が、 Short を選ぶと検索結果 , 、、のリンクのみが一覧表示されます。図 15 に検索結果の例を示します。この検索プログラムが日本語を扱えないのは残念です。 ☆ 日本では、電言斗金か高額であることが常識となっています。そもそも、電言辞ヨ - 金の問題がなけれは、ダイヤルアップは流行らないでしようし、 www。 ffle のようなツフトウェアも求められることはなかったでしよう。 wwwoffle は英国産のソフトウェアです。英国人も日本人と同様に、ダイヤルアップ接続で若労しているのでしようか。いすれにせよ、インターネット接続は常日罸妾続への道を着実に歩んでいます。いっか、接続していることが当り前のときがくるまで、 wwwoffe は財布の強い味方になってくれるでしよう。 ( しま・けいいちシャーフつ [ 文献 ] [ 1 ] R. Fielding, J. Gettys, J. Mogul, H. Frystyk, L. Masinter, P. Leach and T. Berners-Lee, 〃リ〃 e e ェ t 、 0 れ s / Protocol ー HTTP/I コ , RFC2616 , June 1999 [ 2 ] T. Berners-Lee, R. Fielding and H. Frystyk, 〃 e ル tect 石れれ寸 Protocol ー HTTP/I.0, RFC1945 , May 1996 57

9. UNIX MAGAZINE 2000年2月号

UN Ⅸ便利帖・・・・・・宮下健輔放射線検知器 RFC ダイジェスト・・・・・・宇夫陽次朗、小柏伸夫、太田慴史サイバー関西プロジェクト・・・・・・下條真司 NGI プロジェクトインターフェイスの街角・・・増井俊之 LensBar プライバシー保護のためのエージェント Mark S. Ackerman and し 0 「「 ie Faith Cranor 暗号の政台学・・・••paul E. P 「 octo 「 and Christian Byrnes 1 12 138 144 150 127 132 1 News CoIumn ワークステーションのおと・・・・・・坂下秀 86 NetNews 便り・・・・・・みるく BooksheIf 1 19 125 UNIX MAGAZINE 0 [. 15 # 2 2 年 2 月号 ( 通巻 160 号 ) 2 年 2 月 1 日発行発行所・株式会社アスキー〒 151-8024 東京都渋谷区代々木 4-33-10 電話 03-5351-8111 ・発行人 / 戸島國雄・編集人 / 土屋信明・編集長 / 大久保譲治・ Edit0 Network Address: unxmag@ascii.* ・ jp ・編集 / 川崎通紀岸竜次久保田考長谷川光広・出版営業部長 / 松本浩・出版営業担当 / 三田秀雄井上大介藤本典子・出版広告担当 / 山本理一郎佐々木智子杉本玲子・製作購買担当 / 稲垣勢津子禁転載◎ 2000 ASCii Corpo 「 a 朝 on 1070002 印刷 / 東京書籍印刷株式会社 Printed in Japan MateriaI from Performance Computlng and WEB Techmques in this issue is published in cooperation with MiIIer Freeman,Inc. , U. S. A. , 1998 , 1999. AII rights reserved

10. UNIX MAGAZINE 2000年2月号

連載 /Network TechnoIogy—O 図 5 tcpdump による ARP'€ケットのダンフ果 15 : 28 : 39.129429 arp who—has 192 .168.1.254 tell 192.168.1.10 15 : 28 : 39.159414 arp reply 192.168.1.254 is-at 0 : 10 : 67 : 0 : 22 : 10 ADSL モテム vs ADSL ルータ UNIX MAG AZINE 2000.2 を入れるだけで、モデム自体の設定は必要ありません。わめて重要てす。 ADSL モデムであれは、電源スイッチ者側での設定をできるだけ簡略化するのは、コスト面できり詳しくない人にもひろくサーピスを提信ける場合、加入要カ三じるからでしよう。言 t 算機やネットワークにあまく ADSL ルータでは、加入者側でルータの言置をする必はなく ADSL モデムを用いています。これは、おそら PacBell の ADSL サーピスでは、 ADSL ルータで 0 : 10 : 67 : 0 : 22 : 10 ということになります。 DSLAM を経由これによれば、デフォルトルータの MAC アドレスはトのダンフ。結果を示します。アドレスを 192.168.1.10 とします。図 5 に ARP バケッアドレスを 192.168.1.254 、私のファイアウォールの IP ことにしましたーでは、仮にデフォルトルータの IP 動かしながらデフォルトルータに対して ping を実行するみつかりませんでした。そこで、とりあえす tcpdump を文献をひととおりあたりましたが、図 4 のような資料しかてるんやろ " ということでした。 IPoverADSL に関する問に思ったのは、、、いったいどうやって ARP を解決し私が PacBeII の ADSL サーピスを使い始めてます疑 point 接続なので、その必要はありません ) 。うか。 IP over PPP は ARP を通しません (point-to- ストは、どのようにして ISP ルータと通信するのでしょこの場合、加入者側ネットワークに接続されているホ通知されます。は ISP ルータの IP アドレスがデフォルトルータとして用できるグローバル IP アドレスは 1 個だけ ) 、加入者にカ」り当てられ ( ただし、もっとも安いサービスでは、使各 ADSL インターフェイスにクラス C のネットワークあります。たとえば、 PacBeII の ADSL サービスでは、側のネットワークに対するデフォルトルータになる必要が ATU-R が ADSL モデムの場合、 ISP ルータかカ日入者レスの設定も不要です。ので、 unnumbered インターフェイスを使えば IP アド ISP ルータのインターフェイスは point-to-point 接続なしたデフォルトルータのインターフェイスは ATM ですから、どうやら ATM インターフェイス ( あるいは (C) に MAC アドレスカリり当てられているようです。最初はデフォルトルータは Cisco の製品かなと漠然と考えていたのです力ゞ、 0 : 10 : 67 という OUI (Organizational Unique Identifier)4 は明らかに Cisco のものではありません 5 そこで IEEE の Web ページ 6 で 0 : 10 : 67 という OUI をもつ会社を検索したところ、私の ADSL モデムがつながっているデフォルトルータは Redback Networks という会社の製品であることが分かりました。さっそく Red- back Networks の web ページ 7 を見ると、詳しい技術内容は書いてありませんでしたが、 encapsulation proto- col として RFC1483 、、 bridged"ATM に対応しているとありました [ 4 ] 。この言当を見て、「このルータ、 ATM インターフェイスに鬮以 Ethernet " を実装してるんや」と気がつきました。公式な書類を見たわけではないのて想像の域を出ませんが、 Redback Networks のルータは図 6 のようにして ADSL モデムに対応しているようです。以 Ethernet という言葉は私の造語ですが、以下のような機能をもつ非 Ethernet 機器を指します。 1. 下位層から受信した Ethernet フレームが自分宛のものであるかをチェックし、そうであれは・ Ethernet ヘッダを取り除いてフレームを上位層に渡す。 2. 上位層からバケットおよび宛先 MAC アドレスを受け取り、 Ethernet ヘッダをバケットの麪頁に付けて下位層に送出する。すなわち、孑以 Ethernet は Ethernet の物理層および CSMA/CD の機能はありませんが、 Ethernet フレームを扱うことができる機器といえます。その大莫なー - イ列が ATM の LAN 工ミュレーションです。 LAN 工ミュレーションは Ethernet におけるプロードキャスト・ドメイン本をエミュレートしますが、 Redback Networks ク月疑 41 7 http://www.rback.com/ 6 http://standards.ieee.org/regauth/oui/ 5 Cisco Systems の OUI は 0 : 0 : ()c です。す。こ、べンダーコード " とも呼はれます。 4 MAC アドレスの上位 3 オクテットで、そグ職器を作った会社を示しま