表 1 今月扱った RFC インターネット全般 RFC 一覧 : RFC2800 ~ 2899 RFC2899 STD 39 の、、歴史的 " への変更要求 RFC 3109 3GPP と IETF の標準化における協調 RFC3113 3GPP2 と IETF の標準化における協調 RFC3131 IPv6 6t04 リレールータ用ェニーキャスト・プレフィックス RFC3068 IPv6 近ド架索における j 竧架索孑虧長 RFC3122 IPv6-to-IPv4 トランスポート層リレー・トランスレータ RFC3142 SLP IPv6 用 SLP の変更 RFC3111 MPLS BGP4 でのラベル情報伝達 RFC3107 OSPF スタブルータ通知 RFC3137 DNS DNS における RSA/SHAI SIG と RSA KEY RFC3110 アドレスプレフィックス・リスト用の DNS RR 形式 RFC3123 DNSSEC 技術の場犬に関する - 聳義事録 RFC3130 中融奏管璢懾 RFC3124 区分化サービス (Diff-Serv) PHB 識別コード RFC3140 ATM ATM べンチマークのガ侖 RFC3116 PILC リンク性能低下の緩和を目的とする性能名止プロキシー RFC3135 RTP MP3 音声用の対損生の高い RTP ペイロード形式 RFC3119 DHCP RFC3118 DHCP メッセージの認証 本ミ面言 RFC3132 潜伏モードのホスト警告 ()P Paging) 問題について マルチキャスト 233 / 8 の拡リ黒档て RFC3138 性能言わ則関連 範囲に移動した際に、通イ計目手となる基地局の変化を意識 することなく利用できるようにする機能である。 RFC3133 TerminoIogy for Frame ReIay Benchmarking ローミング機能を利用する際、ユーサーの移動前後の 2 フレームリレー性能言則に関する用語 つの基地局か 1 司じ糸目織によって管理されている場合には認 fo. 、」 . Dunn 他 証や課金の間題は生しないが、管理する糸励ゞ異なる場合 フレームリレーの性能計測に関する用語を規定してい はそれぞれの系目織におけるユーサーの認証や課金、すなわ る。、、広報 " として 2001 年 6 月に公開された。 ち AAA が間題となるケースがある。 フレームリレーの性能言測に関連する用語については、 RFC3141 では、 CDMA2000 における AAA に関す ネットワーク柤凾イ言用機器に関する規定 ( RFC1242 ) 、 る要求事項をまとめている。とくに、伝糸勺な PPP およ ネットワーク相互接続用機器に関する規定 ( RFC1944 ) 、 びモバイル IP サービスを提供しているサーヒ、ス・プロバ LAN スイッチング機器に関する規定 ( RFC2285 ) が存在 イダ凋でのローミング樹冓を対象としている。 する。 182 UNIX MAGAZINE 2001.9

RFC ダイジェストー 表 2 今月扱った RFC ( 続き ) IP 新舌 RFC3136 SDP RFC3108 LDAP 鏈 RFC3112 HTTP RFC3143 URN RFC3120 RFC3121 セキュリティ SPIRITS アーキテクチャ ATM べアラ接続における SDP の使用に関する規約 LDAP 認レヾスワード・スキーマ HTTP プロキシー / キャッシュに関する既知の間題 XML. org 用 URN 名前空間 OASIS 用 URN 名前空間 RFC3128 RFC3129 RFC3127 RFC3141 4 覇ま則車 RFC3133 RFC3134 運用車 RFC3139 断片イび攵撃に対する防笹険 KINK に関する要求事項 AAA ( え正・認可・課金 ) 鏈 認証・認可・課金 : プロトコルの語面 CDMA2000 無線データ通信の AAA に関する要求事項 フレームリレー性能言則に関する用語 ATM ABR 性育・測に関する用語 IP べース・ネットワークの設定管理に関する要求事項 RFC3133 ではこれらに加えて、フレームリレー技術お よびシグナリングに特化した用語をまとめている。 RFC3134 Terminology for ATM ABR Benchmarking 旧 fo. 、」 . Dunn 他 ATM ABR 性能言則に関する用語 UNIX MAGAZINE 2001.9 旧 fo. 、 L. Sanchez 他 旧べース・ネットワークの設定褌里に関する要求藝頁 ment of lP-based Networks RFC3139 Requirements for Configuration Manage- 運用関連 ATM 機器の生能評価に関する用語をまとめている。 RFC3134 はこれらに加えて、 ABR 型伝送をおこなう する用語 ( RFC2761 ) か有する。 キャストに関する規定 ( RFC2544 ) 、 ATM 性能引側に関 スイッチング機器に関する規定 ( RFC2285 ) 、 IP マルチ ワーク相互通信用機器に関する規定 ( RFC1242 ) 、 LAN ATM の性能計測に関連する用語については、ネット 年 6 月に公開された。 計測に関する用語を規定している。、、広報 " として 2001 ABR (Available Bit Rate) を扱う ATM 機器の性能 個々の機器自体の設定ではなく、ネットワーク全体を 意識した IP べース・ネットワークの設疋管理モテフレを示 し、そのモデルの要求事項をまとめている。、、広報 " とし て 2001 年 6 月に公開された。 インターネットは、ルータやスイッチなどのノードで 複雑に構成されており、各ネットワークの管理ドメインで は、ネットワークの管理ポリシーに従ってそれそれの機器 の設定を通切におこなわなければならない。これまでは、 各ネットワーク管理ドメインにおいては、管理するネット ワークの管理ポリシーを人間カ甘当屋し、それを個々の機器 の具ー勺な設定に反映させていた。しかし大規模なネット ワークの場合、このような手法では対応しきれない可能生 がある。機器の拠章や設定ミスなどに対応する際に、ネッ トワークの管理ポリシーを人間が各機器の設定に反映する 作業のコストは、ネットワークの規模に応して高くなる傾 向がある。 そこで RFC3139 では、管理ドメインにおける管理ポ リシーにもとづいてネットワーク全体を意識した抽象設定 を生成し、それを各機器の設定にマッピングしていくとい う言殳定管理モデルを提案している。 RFC3139 では、従来 の機器ごとにおこなう設定を、、デバイスレベル成疋 " 、提 183

RFC ダイジェスト 35 宇夫陽次朗、小柏伸夫、小川彩子 今回の RFC 今回扱うのは、 2001 年 5 月中句から 7 月中旬に公開さ れた RFC である。 インターネット全般 RFC2899 Request for Comments Summary RFC Numbers 2800 ー 2899 RFC 一覧 . RFC2800 ~ 2899 fo. 、 S. Ginoza RFC2800 ~ 2899 の概要の一覧である。、、広報 (lnfor- mational)" として 2001 年 5 月に公開された。 各 RFC の番号、著者、タイトル、公開年月と褪各がま とめられている。 RFC3109 Request to Move STD 39 to Historic Status STD 39 の歴史的への変更要求 fo. 、 R. Braden 他 Standard シリーズ (STD 39 ) として公開されている BBN レポート 1822 の状態を、、標準 (Standard)" から 、、歴史的 (Historic)" に変更する理由を述べている。、、広 報 " として 2001 年 5 月に公開された。 BBN レポート 1822 「ホストと IMP の相互接続の定 義」 (STD 39 ) は 1968 年に ARPAnet で採用された標 準であり、すでに使われていない。そのため、文書の状態 を、、歴史的 " に変更することが妥当とされる。 この結果、すでに STD 39 の状態は変更されている。 RFC3113 3GPP-lETF Standardization Collaboration 3GPP と IETF の票準化における協調 fo. 、 K. Rosenbrock 他 174 3GPP (3rd Generation Partnership Project) と IETF 間の標準化に関する共同研究について述べている。 、、広報 " として 2001 年 6 月に公開された。 3GPP は第 3 世代の移本通信システムの標準化プロ ジェクトであり、移重川本通信用の通信方式やプロトコルな どを規定している。 すでに移重川凾イ言システムと計算機ネットワークは切り 離すことかできないほど翩妾にかかわっており、それらの 標準化をおこなう糸である 3GPP と IETF は協調して 活動していくことか望ましい。 そこで RFC3113 では、既存のインターネット・システ ムやテパイス、プロトコルのあいだで高い相カ漣用性か得 られやすい技術イ ) 開発を目的として、 3GPP と IETF で共同研究を立ち上げる際の基礎となる原則およびガイド ラインを記している。 RFC3131 3GPP2-lETF Standardization Collaboration 3GPP2 と IETF の標準化における協調 fo. 、 S. Bradner 他 3GPP2 (3rd Generation Partnership Project2) と IETF 間の標準化に関する共同研究について述べている。 、、広報 " として 2001 年 6 月に公開された。 3GPP2 と IETF で共同研究を立ち上げる際の基礎 となる原則およびガイドラインを記述している。内容は、 3GPP と IETF の協調について扱った RFC3113 とほ ほ 1 司じである。 IPv6 関連 RFC3068 An Anycast Prefix for 6t04 ReIay Routers 6t 。 4 リレールータ用ェニーキャスト・プレフィックス PS. 、 C. Huitema UNIX MAGAZINE 2001.9

233 / 8 の拡張割当て fo. 、 D. Meyer UNIX MAGAZINE 2001.9 関係を定義している。 るものかを述べ、そのために必要な要素とそれらの要素の RFC3136 では、 SPIRITS がどのような機能を提供す する調佐結果か報告されている。 おり、過去に RFC2995 で SPIRITS 型のサービスに関 おもに IETF の SPIRITS 分科 - 会て活動力けられて のサーピスを提供する。 インターネット呼番号通知、インターネット電話など ンターネット・コールウェイティング ( キャッチホン ) 、 おける電話型通信を統合するためのアーキテクチャで、イ SPIRITS は PSTN ( 一般公彡得罔 ) とインターネットに 開された。 クチャを規定している。、、広報 " として 2001 年 6 月に公 InTernet Services) サービスを提供するためのアーキテ SPIRITS (Services ⅲ the PSTN/IN Requesting 旧 fo. 、 L. Slutsman 他 SPIRITS アーキテクチャ RFC3136 The SPIRITS Architecture IP 電話関連 255 である。 生成される EGLOP 空間は 233.252.0.0 ~ 233.255.255. して参照できるようにすることを規定している。この結果 65535 ) を用いて生成されるアドレス空間を EGLOP と RFC1930 で定義されたプライベート AS 空間 ( 64512 ~ そこで、 RFC3138 では RFC2770 の規定を拡張し、 た間題点も孑商されている。 利用者が AS 番号を取得できない場合には使えないといっ としていた。しかし、 8 ピットの空間が小さすぎる場合や、 た値を表現し、下位 8 ビットを各 AS が利用できる空間 24 ビット目の 16 ビットを使って AS 番号から生成され GLOP を提案している。 GLOP はアドレス空間の 9 ~ 233 / 8 を静的に割り当てる方式として、 AS 番号を用いる RFC2770 では、 Class D アドレス空間の一部である された。 当てを規定している。、、広報 " として 2001 年 6 月に公開 レス割当てを拡張した EGLOP (Extended GLOP) 割 RFC2770 で提案さ運用もされている GLOP アド RFC ダイジェストー SDP 関連 179 6 月に公開された。 ける既知の間題をまとめている。、、広報 " として 2001 年 WWW のプロキシーおよびキャッシュ・サーバーにお 旧 fo. 、 I. Cooper 他 HTTP プロキシー / キャッシュに関するロの問題 RFC3143 Known HTTP Proxy/Caching Problems HTTP 関連 るスキーマを規定している。 より強固な認証方式として、、、 authPassword" を使用す そこで、 RFC3112 では一方向ハッシュ関数を用いた るため、セキュリティ上の間題がある。 意されている。この方式は認証に平文パスワードを利用す ポートするために、 userPassword という属生タイプが用 LDAP ディレクトリでユーサー / パスワード認証をサ れた。 いて述べている。、、広報 " として 2001 年 5 月に公開さ LDAP での認証用属性タイプ、、 authPassword" につ fo. 、 K. Zeilenga LDAP 認証パスワード・スキーマ RFC3112 LDAP Authentication Password Schema LDAP 関連 まとめている。 を用いた通信を SDP て表現する際に必要となるルールを するための VPI/VCI などの表現機構といった、 ATM RFC3108 では、 ATM の AAL や ATM 接続を言当 したプロトコルで、 RFC2327 で定義されている。 SDP は通信や機器の制御などに利用されることを想定 2001 年 5 月に公開された。 規定している。現在の状態は、、標準化への提唱 " である。 ( セッション言当プロトコル ) で表現するためのルールを ATM べアラおよび AAL1/2/5 を用いた接続を SDP PS. 、 R Kumar 他 ATM べアラ接続における SDP 吏用に関する規約 tlons scription Protocol (SDP) for ATM Bearer Connec- RFC3108 Conventions for the use of the Session De-

日 FC ダイジェストー 開している。、、広報 " として 2001 年 6 月に公開された。 区分化サービス (Diff-Serv) では、トラフィックを構成 するバケット群の挙動を小す矼念として PHB (Per Hop RFC3130 では、 DNSSEC という技術のコンセプトを 明確にしたうえで、各研究グルーフ。の大および目標を報 Behavior: ホッフごとの ~ カ ) を導入している。通常、 IP ノヾケットでは、 PHB は IP ヘッダ内の DSCP (Diff-Serv 告している。さらに Code Point) フィールドを用いて表現されるが、 DSCP 研究活動の分類およひ不足している分野 フィールドの長さは 6 ビットしか確保されておらす、 DNSSEC に関する質間とその回答 く少数の PHB 群しか識別できない。そのため現在では、 各技術の標準化の進捗状況 運用ルールとしてオ剽勺な PHB 集合を DSCP の清報を の出席者 用いて切り替える場合がある。しかし、ローカルで PHB などか記されている。 集合の内容と DSCP とのマッピングに関するコンセン サスを確立できれは、この制約にかかわらす別の組合迂の 輻輳回避関連 PHB 集合を利用した運用が - 可能となるはすである。 RFC3124 The Congestion Manager そのような運用をおこなう際には、 PHB のマッピング 車奏里冓 を扱うプロトコルのメッセージ内て特定の PHB を一意に PS. 、 H. Balakrishnan 他 識男ける方法が必要である。また、単一の PHB だけでな 工ンドシステムで動作する輻輳の管理機構として CM く、複数の PHB をまとめて扱う場合も考慮しなければな (Congestion Manager) を提案している。現在の状態は らない。 、、オ剽售化へ窈是唱 " である。 2001 年 6 月に公開された。 RFC3140 では、プロトコルのメッセージ内で PHB を インターネットにおける輻輳の制御は、インターネッ 表現し、かっ PHB を一意に識別できる 16 ビット長符号 トを動作させるうえできわめて重要な間題であり、かっ根 化を規定している。 16 ピットの PHB 集合空間の下位 1 本的な鮹夬がはなはだ困難な間題として扱われてきた。 ビットを、、、ローカル・コンセンサス " を示すビットとして れまでにも中獅奏の制御はさまざまな観点から言義されてお 利用し、 PHB のセマンティクスを切り替えることで、通 り、、、できるかぎり輻輳の発生を抑える " 機能が実装され 常の Diff-Serv での PHB および独自に規定された PHB たプロトコルなどもある。 を表現できる。 RFC3124 では、エンドシステムで重川乍し、アプリケー RFC3140 では、 RFC2836 て考慮されていなかった ションやプロトコルを間わす動胙する輻輳管理欟懾として クラスセレクタ・コードボイントの記述を追加している。 CM を提案し、以下の点について論している。 さらに、 PHB スケジューリング・クラスに関する説明が 明確化されている。 ・ CM のコンセプトおよびフレームワーク ・ CM の API ATM 関連 ・ CM の内部機構 RFC3116 Methodology for ATM Benchmarking ・ CM を用いた中融奏制御の例 ATM べンチマークの方法論 区分化サービス (Diff-Serv) 関連 fo. 、」 . Dunn 他 ATM のべンチマークにイ吏用されるテストについて定義 RFC3140 Per Hop Behavior ldentification Codes している。、、広報 " として 2001 年 6 月に公開された。 P H B リコード PS. 、 D. Black 他 ( RFC2836 置換 ) スイッチング・デバイスにもとづく ATM の生能に関す る特徴を調べるためのテストにはさまざまなものがある。 利用する PHB コード群を指定するための符号化手法と RFC3116 では、これらのべンチマークをとるためのテス 識別用のコードである PHB id を定義している。現在の トについて説明、定義している。これは、 RFC2544 にお 状態は、、標準化への提唱 " である。 RFC2836 を置き換え けるべンチマークガ去論の定義、および RFC2761 にお る RFC として 2001 年 6 月に公開された。 177 UNIX MAGAZINE 2001.9

MPLS 関連 RFC3107 Carrying LabeIInformation in BGP-4 BGP4 でのラベル情報イ室 PS. 、 Y. Rekhter 他 ラベルマッピング情報を BGP メッセージに添付して 送信するガ去を定義している。現在の状態は、、標準化への 提唱 " である。 2001 年 5 月に公開された。 BGP4 の更新メッセージに相乗り (piggyback) して MPLS のラベルマッピング情報を伝達する方法を規定し ている。 BGP を用いて糸響各制御がおこなわれているドメインで は、経路の変更時に BGP 更新メッセージカイ云達される。 MPLS ドメインが第 3 層糸響各制徊職構の情報をマッピ ングして重川乍するモードの場合、経路の変更をラベル情報 に反映させなければならない。 BGP とラベル配布欟冓が それぞれ独立して動作している場合は、各ノードにおける 経路変更を検出したうえでラベル配布プロトコル (LDP) による処理が必要となる。しかし、 BGP のみを利用して 経路交換をしている場合には、 BGP のセマンティクスで 扱われている糸糾青報だけを処理すればよいので冗長であ る。 そこで RFC3107 では、 BGP4 のマルチプロトコル拡 張機能 ( RFC2858 ) を利用して、 MPLS ラベルを経路情 報と同時に伝土するオ降を規定している。 RFC3137 OSPF Stub Router Advertisement OSPF スタフルータ通知 fo. 、 A. Retana 他 OSPF のスタブルータによる、、トラフィックの転送が できない " 、、性能か下がりつつある " といった情報の通知 ガ去を提案している。、、広報 " として 2001 年 6 月に公開 された。 OSPF では、ルータが自身の、、バケット転送性能の低 下 " を他のルータに通知したほうがよいケースがある。具 イ勺には、 CPU 負荷か高い場合や、経路情報を↑内する 十分なメモリ領域がない場合などか挙げられる。 RFC3137 では、このような、、中幻当生能か下がりつつあ る " という情報を通知する方法を提案し、従来の OSPF ルータとの下イ立換性についても言及している。 176 DNS 関連 RFC3110 RSA/SHA-I SIGs and RSA KEYs in the DO- main Name System (DNS) DNS における RSA/SHAI SIG と RSA KEY PS. 、 D. EastIake 3rd ( RFC2537 置キ奐 ) DNS SIG RR (Resource Record : 資源レコード ) に RSA/SHAI 署名をオ褓内するガ去を定義している。現在の 状態は、、標準化への提唱 " である。 RFC2537 を置き換え る RFC として 2001 年 5 月に公開された。 RFC2537 では RSA 鍵と RSA/MD5 署名をオ褓内する ガ去か規定されているが、利用している MD5 ハッシュ・ アルゴリズムに弱点が発見されており、すでにより強力な SHAI アルゴリズムか発されている。 そこで、 RFC3110 では RFC2537 での定義を更新し、 SHAI を利用する場合について規定している。この変更で はハッシュ・アルゴリズムを置換するだけであり、少ない 労力でより強力な暗号化方式を利用できるとされている。 RFC3123 A DNS RR Type for Lists of Address Pre- fixes (APL RR) アドレスプレフィックス・リスト用の DNS RR 形式 Exp. 、 P. Koch アドレスプレフィックス・リスト用の DNS RR 形式 、、 APL" を定義している。、、実験的 (Experimental)" と して 2001 年 6 月に公開された。 DNS はアドレス鮹夬以外に、分散した名前空間を提供 すみ冓としても利用できる。 DNS カ甘是供するさまざま な情報は RR として定義されている。旧い BIND では ゾーンデータのアクセス制御を、アドレスレンジを指定す る TXT RR を用いて規定したため、セキュリティ上の 間題カ甘商されていた。 そこで RFC3123 では、その代わりとしてアドレス・プ レフィックスを表現する RR 形式である APL を提案し ている。 RFC3130 Notes from the State-Of-The-Technology. DNSSEC DNSSEC 技術の現状に関する会言第義事録 旧 fo. 、 E. Lewis 第 49 回 IETF 総会と並行して開催された、 DNSSEC (DNS セキュリティ拡彌の開発者による会議の言求を公 UNIX MAGAZINE 2001.9

RFC1858 では、インターネット・ファイアウォール へのさまざまな攻撃について説明し、その対策を提案して いる。しかし、 RFC1858 で提案された、、間接方法 (ln- direct Method)" は、、、断片化攻撃 (Tiny Fragment Attack)" と、、断片重複化攻撃 (OverIapping Fragment Attack)" を組み合わせた攻撃に対する十分な対応策とは なっていない。 そこで RFC3128 では、 この組 : 合迂攻撃についての角見 ・組 . 合を攻撃に対して間接ガ去では不一ト分な理由の説明 ・新たな対策の提案 をおこなっている。 RFC1858 で提案されている対応策は先頭断片 (first 旧 fo. 、 M. Thomas KINK に関する要求頁 gotiation of Keys RFC3129 Requirements for Kerberized lnternet Ne- バケットの拒否も必須だとしている。 れに加えて RFC3128 では、ヘッダか不完全な、、 FO = 1 " fragment) 、すなわち、、 FO = 0 " バケットの拒否だが、 UNIX MAGAZINE 2001.9 プロトコルか満たすべき要求事項をまとめている。 ber 。 s オ冓を使用する利点について説明し、さらに KINK あることか望ましい。 RFC3129 では、 IPsec 導入に Ker- 構の対規模性能を活力るようなーヨ勺な鍵プロトコルで プロトコル、すなわち KINK プロトコルは、 Kerberos 機 と系旧寺をおこなうプロトコルの作成を目指している。この beros 認証機構を用い、公開鍵を使わすに IPsec の確立 KINK 分科会では、このうち第 2 の方式である Ker- よるセキュリティ機構 2. 信頼できる第三者による柤反認証と鍵マテリアル配布に 1. 共通の秘密鍵を用いた IP ペイロード暗号化および認証 してきた。これらは大きく 2 不頁に分類できる。 キュリティを確立、系旧寺するためのプロトコルを多数定義 IETF の IPsec 分科会では、レイヤ 3 上で暗号化セ いる。、、広報 " として 2001 年 6 月に公開された。 of Keys) 分科会の目標に関する説明と要求事項を述べて IETF の KINK (Kerberized lnternet Negotiation RFC ダイジェストー AAA ( 認証・認可・課金 ) 関連 RFC3127 Authentication, Authorization, and Ac- counting. Protocol Evaluation 認証・認可・課金 . プロトコルの言面 旧 fo. 、 D. Mitton 他 ューサーがある基地局の通イ前囲から、別の基地局の通信 ように、ローミングという機能が用いられている。これは、 ューサーか基地局間を移動してもシームレスに通信できる ラップトップ PC などの移重川本の無線データ通信では、 れた。 項をまとめている。、、広報 " として 2001 年 6 月に公開さ CDMA2000 無線データ通信の AAA に関する要求事 fo. 、 T. Hiller 他 CDMA2000 無線テータ通信の AAA に関する要求頁 for AAA RFC3141 CDMA2000 Wireless Data Requirements 言平価が変わる可能生もある。 いるので、今後の刻長や評価基準の見直しなどによっては が、評価はおおよそ間違っていないだろう」と明記されて 制約により当初期侍されていたものはど完成度は高くない ただし、 RFC3127 の冒頭では、「本 RFC は、時間的 Diameter および COPS か高く調面される結果となった。 る評価をまとめ、各プロトコルの上交評価を示しており、 ている。また、結論として、上記の各プロトコルに対す 各プロトコルについて、 AAA への応用の可能性を評価し の要求事項と評価基準をまとめ、過去に提案された上記の の長などカ甘是案されてきた。 RFC3127 では、 AAA へ ・ COPS ・ 1 ) 1a111et er ・ Radius 十十 ・ SNMP して、 これまで、 AAA への応用の可能性があるプロトコルと 6 月に公開された。 AAA への応用を評価している。、、広報 " として 2001 年 価基準をまとめ、これまでに提案された各種プロトコルの counting : 認証・認可・課金 ) に関連するプロトコルの評 AAA (Authentication, Authorization, and Ac- 181

工 PureFTPd おおっかまさひと の 3 FTP&いうもの UNIX MAGAZINE 2001.9 ンテンツ中幻幻こ使われるぐらいだろう。 ができるという点で ISP の WWW サーバーなどへのコ ることを目的とした anonymous FTP サーバーや、認証 れなくなっている。イ芋定多数に多量のファイルを提供す 性が悪いなどの古くさいところがあるので、しだいに使わ が言気 t された日にのこともあり、ファイアウォールとの相 コルは、 FTP ではなく HTTP だろう。 FTP は、それ 現在、ファイル配布にもっともよく使われているプロト は 1985 年 10 月 1 日である。 現在の FTP の標準はこれを見直した RFC959 で、公開 を利用する現行の形式の FTP を初めて定義したものだ。 よって定義されたものがもとになっている。これは、 TCP 現在の FTP は、 1980 年 6 月 1 日公開の RFC765 に 歳上だ。 定義された。公開は 1973 年 2 月 16 日で、やはり私より 414 、 RFC430 を経て、 FTP は公式に RFC454 として 送プロトコルか立義されている。その後 RFC385 、 RFC ( インターネットのもとになったもの ) でのホスト間の転 1972 年 7 月 8 日の RFC354 になって、 ARPANET い時代のものである。 な話だが、私より歳上だ ーまでは、 TCP/IP すらな には、すでにその仕様らしきものカ咄てきている。個人的 1971 年 4 月 10 日である。同じ年に公開された RFC172 col 」に最初にその名か現れる。タイムスタンプはなんと だ。 RFC をみると、 RFC114 の「 File Transfer Proto- ん古い。なんといってもインターネットの誕生より古いの FTP というプロトコルとソフトウェアの歴史はたいへ 去も丘は HTTP を使ってファイルを操作する WebDAV といったプロトコルか策定され、その実装も出てきてい る。コンテンツのアップロードなどにはこちらがおもに使 われることになるだろう。 FTP がその役目を終えるのも、 そう遠い未来ではないようだ。 このような状況て新たに開発される FTP ソフトウェア は少ないかと言われれは、けしてそんなことはない。今回 は、そのなかでもとくに新しい FTP サーバーを紹介する。 PureFTPd?K 今回紹介するのは、たいへんシンプルでコンパクトな FTP サーバー PureFTPd である。現在も活発に開発 が進められているごく新しい FTP サーバーだ。 setfs- uid(2)l などをもつ山も丘の Linux 向けに書かれているが、 *BSD などでも動作する。以下のような曷緻をもってい ・ ls を内蔵 ・ chroot オ幾育皀 ・帯域制御腰能 ・バーチャルホスト機能 ・ IPv6 に対応 ・さまざまな認証方式 (LDAP 、 PAM) に対応 FTP サーバーのデファクト・スタンダードの wu-ftpd や、丘人気のある ProFTPD にくらベオ L ばいくぶんシ ンフ。ルだが、定がたいへん簡単なうえに咼速、咼機能で ある。まさにこの連載にふさわしい ( ? ) FTP サーバーと 1 ファイルシステムにアクセスする際の UID をセットするシステムコー る。 67

WWW サーバーとクライアント間に介在するキャッシ ュやプロキシーは、大規模「生能や速度を向 . 上させるために ひろく利用されている。 しかし、実際には仕様およひま装上の間題があり、芋 点でもいくつかか認識されている。そこで RFC3143 で は、これらの間題を解決するための言墟侖や研究の佖止を目 的として、間題を明示している。 RFC3143 で扱っている間題を以下に示す。 ・イ策ーヒの問題 —Vary header is underspecified and/or mislead- —CIient Chaining Loses Valuable Length Meta- Data ・アーキテクチャ上の間題 —lnterception proxies break client cache direc- tives —lnterception proxies prevent introduction Of new HTTP methods —lnterception proxies break lP address-based authentication RFC3143 ではこれらの間題について、それぞれ以下の ers for files that contain CR ー Some servers send bad Content-Length head- —User agent/proxy failover ・実装ー E の間題 alization of content —Caching proxy meshes can break HTTP seri- —ICP Performance networks ー Caching proxy peer selection in heterogeneous 情報を示している。 ・間題の呼称 間題の領域 ()l 生能、 間題の説明 ・その間題の重生 セキュリティ、その他 ) ・ネットワークやシステムへの景グ ・参考頁 間題の識別力法 ・ ( あれは ) 鮹夬力法 180 ・回避方法 ・参考文献 ・間合せ先 URN 関連 RFC3120 A URN Namespace for XML. org XML. org 用 URN 名前空間 旧 fo. 、 K. Best 他 仕様朿定機関の OASIS (Organization for the Ad- vancement 0f Structured lnformation Standards) に よって定義され、 XML. org て提供される名前をもつ永続 的な資源を示す URN 名前空間用識別子、、 xmlorg" を規 定している。、、広報 " として 2001 年 6 月に公開された。 XML. org レジストリは、 XML スキーマや DTD 群、 スタイルシートなどを提供している。 RFC3120 では、 れらを利用する際に個々の資源を指定するための URN 名 前空間識別イ・、、 xmlorg" を規定している。 RFC3121 A URN Namespace for OASIS OASIS 用 URN 名前空間 fo. 、 K. Best 他 OASIS によって作成された各種のイ」を示す URN 名 前空間用識別子 "oasis" を規定している。、、広報 " として 2001 年 6 月に公開された。 OASIS では、仕様書、作業中のドラフト、技術文書、 スキーマ、スタイルシートといったさまざまな文書を公開 している。 OASIS ではこれらの文書を示す、グローバル で永続的、かっロケーションに依存しない名前空間を必要 としている。そこで RFC3121 では、 OASIS が公開して いる文書を示すための URN 名前空間用識別子 "oasis を規定している。 セキュリティ関連 RFC3128 Protection Against a Variant Of the Tiny Fragment Attack (RFC 1858 ) 断片化攻撃に対する防御策 fo. 、 I. MiIIer ( RFC1858 更新 ) 断片化攻撃の一種とその対策について説明している。 、、広報 " として 2001 年 6 月に公開された。 RFC1858 を 史新している。 UNIX MAGAZINE 2001.9

ける ATM べンチマーク用語の定義に従っている。また、 DHCP ( 重加勺ホスト設定プロトコル ) における認証オプ ションを規定している。現在の状態は、、標準化への提唱 ' べンチマーク報告用の形式についても説明している。 である。 2001 年 6 月に公開された。 PILC 関連 DHCP は、 IPv4 ホストのアドレス設定などを外部か ら与えるためにひろく利用されている。しかし、現在の RFC3135 Performance Enhancing ProxiesIntended to DHCP 仕様にはホストを認証する手段がほとんどなく、 Mitigate Link-Related Degradations リンク性肯氏下の緩和を目的とする性能向上プロキシー ホストおよびサーバーの認証を求める声が多い。 fo. 、」 . Border 他 そこで、 RFC3118 では、 リンク特生を補完して TCP 性能を高める PEP ( 生能 ・サーバーがクライアントを認証する樹冓 向ーヒプロキシー ) に関する調査結果をまとめている。、、広 ・クライアントがサーバーからのメッセージを認証する機 報 " として 2001 年 6 月に公開された。 構 インターネットではさまざまな不頁のリンク技術が用い を提供するためのフレームワークを規定している。 られており、それぞれ性能や特利用コストなどが異な る。なかでも衛星リンク、無線 WAN 、無線 LAN など 移動体通イ言関連 のリンクは一殳の有線リンクと上交してレイテンシや信頼 性に関する性能力觝く、これらを利用する場合にはなんら RFC3132 Dormant Mode Host Alerting ("IP Pag- ing ) ProbIem Statement かの匪能補完技術が必要となる。 ラ大モードのホスト警告 ()P Paging) 問題について RFC3135 では、現在インターネットにおいて研究およ 旧 fo. 、」 . Kempf び実験、実装がおこなわれている PEP 技術についてまと 移重川本通信における潜伏モード (Dormant Mode) の めている。ます PEP のイ立置づけを定義したあと、 PEP の IP paging 間題に関する言磊義をまとめている。、、広報 " と 基本原理、 PEP の動作哥対冓、 PEP がおよはす景グ厰 PEP して 2001 年 6 月に公開された。 の利用例などについて説明している。 移動体通信では、移重川をの到選生の確保カ吠きな間題 RTP 関連 であり、移重川本の位置管理手法に関する義か盛んにおこ なわれている。 RFC3119 A More Loss-Tolerant RTP Payload Format 大モードとは、無絲泉通信においてモニタリングするチ for MP3 Audio MP3 音声用の対損失性の高い RTP ペイロード形式 ャネル数を減らすことで、移重川本が受信する IP トラフィ PS. 、 R. Finlayson ックの量を削減するモードである。潜伏モードの利点とし ては、移動「桓 ) 言算資源とネットワークにかかる負荷の軽 MPEG 1 , 2 Layer3 Audio (MP3) を伝送する RTP 減か挙げられる。 ペイロード形式を規定している。現在の状態は、、標準化へ RFC3132 では、 IP Paging と呼ばれる移動体通信に の提唱 " である。 2001 年 6 月に公開された。 おける位置管理欟冓の一部を利用することにより、潜伏モ MP3 を RTP て伝送するためのペイロード形式は、過 ードでの移動体の位置管理手法を提案している。さらに、 去にも RFC2550 で規定されていた。 RFC3119 では、 IETF の seamoby う斗会における ~ 替伏モードの IP Pag- RFC2550 よりもバケット損失に対する生か高いペイロ ing に関する言缶義をまとめている。 RFC3132 では、 IP ード形式を規定している。 paging を移動体の位置管理の鮹夬手法の 1 っとして位置 DHCP 関連 づけ、他の鮹寒手法の可能陸も夋している。 RFC3118 Authentication for DHCP Messages マルチキャスト関連 DHCP メッセージの認証 RFC3138 Extended Assignments in 233 / 8 PS. 、 R. Droms 他 178 UNIX MAGAZINE 2001.9