RFC ダイジェストー 表 1 今月扱った RFC インターネット全般 RFC3339 RFC3356 MPLS RFC3353 L2TP RFC3355 RFC3371 IPv6 RFC3306 RFC3307 TCP 鏈 RFC3360 DNS RFC3363 RFC3364 インターネットにおける日付と日リ : タイムスタンプ IETF と ITU-T 標準化セクタ間の共同研究ガイドライン MPLS 工竟における IP マルチキャストの概要 ATM AAL5 を介した L2TP L2TP 用 MIB ユニキャストプレフィックス・べースの IPv6 マルチキャスト・アドレス IPv6 マルチキャスト・アドレスの割当てガイドライン DNS での IPv6 サポートに関するトレードオフ DNS における IPv6 アドレス表現 不適切な TCP リセットの有害羅に関する考察 CNRP ( →殳名解決プロトコル ) RFC3367 RFC3345 RFC3358 RFC3359 IOTP RFC3354 経路制ー CNRP : ー引殳名鮹夬プロトコル BGP における永続的な糸幇川大態 ISIS のチェックサム・オプション ISIS における予斉み TLV コードボイント IOTP 第 2 版の要求事項 APEX ( アプリケーション間交鏈 RFC3340 APEX コア RFC3341 APEX アクセスサーピス RFC3342 APEX オプション・ノヾーティノ、ツクノヾート 2 インターネット FAX 関連 フレームワークク是示、メッセージへッダの定義、実例に 構について論している。具体的には、言目標の町寉化 3297 では、 RFC2532 で必要となるコンテンツの折衝機 ジング・サーピスは RFC2532 で規定されている。 RFC 電子メールを利用した FAX 、音声、その他のメッセー 公開された。 現在の状態は、、標準化への提唱 " である。 2002 年 7 月に ジング・サーピス用のコンテンツ孑斤衝樹冓を規定している。 電子メールを利用した FAX 、音声、その他のメッセー PS. 、 G. Klyne 他 ツ折衝 電子メールによるメッセージング・サービス用のコンテン based on Email RFC3297 Content Negotiation for Messaging Services UNIX MAGAZINE 2002.11 よる角見をおこなっている。 RFC3362 Real-time Facsimile ( T. 38 ) ー image/t38 MIME Sub-type Registration 実時間 FAX (T 38 ) : Ⅶ ME サプタイプ image/t38 の登 PS. 、 G. Parsons ITU 勧告 T. 38 の MIME サプタイプとして image/ t38 を定義している。現在の状態は、、標準化への提唱 " で ある。 2002 年 8 月に公開された。 ITU 勧告 T. 38 は、実時間での FAX 転送などを規定 した文書である。 RFC3362 では、行号化に T. 38 を用い た MIME サプタイプとして image/t38 を定義している。 これは SDP (Session Description Protocol) て利用さ れる。 IP 電話関連 RFC3298 Service in the Public Switched Telephone Network/lntelligent Network (PSTN/IN) Requesting 179

表 2 今月扱った RFC ( 続き ) BEEP 車 RFC3349 計則鏈 RFC3357 第幻 RFC3366 各 IETF うト会で開発中のプロファイル群を識別するための一卍判くワ。レフィックス リンク層設言者一、、のアドバイス : リンク ARQ 片方賴失パターンサンプル詩基準 電子メール鏈 RFC3348 IMAP4 : 子メールポックス刻長 URI/URL RFC3305 W3C/IETF URI 立案グループによる報告 : URI 、 LDAP RFC3296 LDAP ディレクトリにおける名前付き彳遭属参照 SIP 鏈 URL 、 URN に関する町寉化と推奨事項 RFC3351 聴害者および言語章書者のサポートに関する SIP のユーサーー要求事項 RFC3361 SIP サーノヾーのための DHCP オフション Midcom ( ミドルポックスう言 ) RFC3303 Midcom アーキテクチャおよびフレームワーク RFC3304 Midcom プロトコル要求イ土様 インターネット RFC3297 電子メールによるメッセージング・サービス用のコンテンツ折衝 RFC3362 : 知寺 FAX ( T. 38 ) : MIME サプタイプ image/t38 の夸当求 IP ー RFC3298 SPIRITS プロトコルの要求事工頁 セキュリティ RFC3369 CMS : 暗号メッセージ文法 RFC3370 CMS のアルゴリズム InTernet Service (SPIRITS) ProtocoI Requirements SPIRITS プロトコル求事項 旧 fo. 、 I. Faynberg 他 SPIRITS プロトコルに対する要求事項と、 SPIRITS 分科会における SPIRITS シグナリング・プロトコルに関 する合意をまとめている。、、広報 " として 2002 年 8 月に 公開された。 SPIRITS とは、公衆電話網 (PSTN) からの平をサ ポートし、 PSTN とインターネットの相互接続を可能に するための機構である。 IETF では、これまでインター ネットから PSTN に接続するための機構として PINT (PSTN/Internet lnterworking) について言義言侖を進めて きた。 RFC3298 では、 PSTN からインターネットへの 接続をサポートするために、 SPIRITS に対する一的な 要求事項のほか、 IN ( インテリジェント・ネットワーク ) 、 無線 IN 、 PINT 、イベント通知のそれぞれに関する要求 180 事項などについてまとめている。 セキュリティ関連 RFC3369 Cryptographic Message Syntax (CMS) CMS : 暗号メッセージ文法 PS. 、 R. Housley ( RFC2630 、 RFC3211 更新 ) 電イ署名、ダイジェスト、認証などに用いられる CMS ( 暙号メッセージ去 ) を定義している。現在の状態は、、標 準化への提唱 " である。 RFC2630 、 RFC3211 を更新す る RFC として 2002 年 8 月に公開された。 CMS は、 PKCS # 7 第 1.5 版 ( RFC2313 ) から派生 したデータイ用の暗号イ本系である。メッセージ内容に 対する電イ署名、認証、暗号化などに利用される。 RFC3361 での CMS 定義への変史点を以下にまとめ ・ RFC3211 で規定されたパスワードを用いた鍵冓の追 加 ・新しい里欟冓をサポートするための拡張欟冓の追加 る。 UNIX MAGAZINE 2002.11

現在ひろく利用されているファイアウォールの多くカ坏 適切な TCP コネクションのリセットをおこなっている 現状について論している。点での最良のガ去 (Best Current Practice)" として 2002 年 8 月に公開された。 BCP シリーズ (BCP 60 ) としても公開されている。 TCP バケットのヘッタ部分には数頁のフラグ用のフ ィールドか規定されており、これらは TCP コネクション の確立や破棄に利用されている。これらのフィールドのう ち、リセットフラグが設定された TCP バケットは、存 在しないはずの旧い TCP コネクションを切断するため に使われる。 RFC3168 ではリセットフラグの利用上の制 限を日Ⅲ寉に規定しているが、現在ひろく普及しているファ イアウォールやロードバランサーの多くは、 RFC3168 の 規定よりも厳密な条件で TCP バケットを判定し、不適 切と判断した TCP コネクションをリセットしてしまう という挙動を示す。このような実装は、一見、、送信は厳密 に、受信は寛容に " という原則に従っているようにみえる が、、、仕様の変更に対する通öl 生の確保 " という原則には 合致せす、新たなプロトコルやアプリケーションの発展を 阻害するおそれがあるため注意する必喫がある。 RFC3360 では、具イ列として予糸斉み (reserved) フ ィールドと ECN フィールドを挙げ、ファイアウォール やロードバランサーなどの、、ミドルポックス " のバケット 中幻逶機能はどうあるべきかについて言磊義している。 DNS 関連 RFC3363 Representing lnternet ProtocoI version 6 (lPv6) Addresses in the Domain Name System (DNS) DNS における旧 v6 アドレス表現 fo. 、 R. Bush 他 ( RFC2673 、 RFC2874 更新 ) IPv6 アドレスを DNS て級うガ去についての言墟龠をま とめている。、広報 " として 2002 年 8 月に公開された。 RFC2673 、 RFC2874 を更新している。 DNS で IPv6 アドレスを扱うガ去としては、 A6 (RFC 2874 ) と AAAA ( RFC1886 ) の 2 つか検討されてきた。 しかし、複数の方式があることで混乱が生し、 IETF メ ーリングリストや第 51 回 IETF 総会の BOF などで議 論が重ねられた。 RFC3363 はその言侖をまとめ、 RFC として公開するものである。また、ピットラベルおよび DNAME RR についても言及している。 UNIX MAGAZINE 2002.11 RFC ダイジェストー 言籀侖の結果、ン鄲芋点での IPv6 の普及には AAAA 方 式のはうか望ましい " ということになり、 A6 およびビッ トラベルの仕様は、、標準化への提唱 " から、、経験的 (Ex- perimental)" に変更された。 RFC3364 Tradeoffs in Domain Name System (DNS) Support forlnternet Protocol version 6 ( 旧 v6 ) DNS での旧 v6 サポートに関するトレードオフ fo. 、 R. Austein ( RFC2673 、 RFC2874 更新 ) DNS で IPv6 をサポートするための各不耐支術の上師交と 検討結果をまとめている。、、広報 " として 2002 年 8 月に 公開された。 RFC2673 、 RFC2874 を更新している。 IETF では、 DNS での IPv6 サポートにおいてど の方式を選択するかの言侖が続けられてきた。その結果 は RFC3363 でまとめられたが、議論の過程を記録した RFC も必要と考えられる。そこで RFC3364 では、 A6 、 AAAA 、ヒ、ツトラベル、 DNAME RR について技行勺 な上交や言侖の結果をまとめている。 CNRP ( 一般名解決プロトコル ) 関連 RFC3367 Common Name Resolution ProtocoI (CNRP) CNRP →殳名解決プロトコル PS. 、 N. Popp 他 商標や会社名などの、、一般名 (common name)" か らなんらかの情報を解決するためのプロトコルである CNRP (Common Name Resolution ProtocoI : ー殳 名解決プロトコル ) を規定している。現在の状態は、、標準 化への提唱 " である。 2002 年 8 月に公開された。 計算機関連分野などでは、さまざまな資源を URI な どて指定する場面も多くみられるようになったが、それは ごく一部の分野に限られており、一ヨ勺な事物の名前から URI に変換できる場面はほとんどないのか朋大である。 CNRP は、商標や本の名前などの、、一般名 " をもとに 情報空間内の資源を角夬するために言されたプロトコル である。 CNRP はクライアント・サーバー型のプロトコルで、ク ライアントからサーバー / 邸月合を送るとサーバーから応 答カされるというかたちで通信をおこなう。 CNRP の 間合および応答は XML 形式で規定されており、多言 語、複区答などがサポートされる。 173

RFC ダイシェスト 宇夫陽次朗、小柏伸夫 今回扱うのは、 2002 年 7 月中旬から 9 月中旬に公開さ れた RFC である。 インターネット全般 RFC3339 Date and Time on thelnternet: Timestamps インターネットにおける日付と時刻 : タイムスタンプ PS. 、 G. Klyne 他 インターネット上で日付や時刻を表現するための標準 的な記法を規定している。現在の状態は、、標準化への提唱 (Proposed Standard)" である。 2002 年 7 月に公開さ ーー 0 日付や時 = 刻情報は、多くのインターネット・プロトコル においてさまざまな場面で利用される一殳的な値である。 しかし、その記去は標準化されておらず、各種プロトコル 間の相磨妾続生を考慮するうえで間題になることが多い。 そこで RFC3339 では、インターネット上で日付や時 刻を表現するためのオ剽純勺な去として、 IS086011 にも とづく記法を規定している。 RFC3356 lnternet Engineering Task Force and lnter- nationalTelecommunication Union - Telecommuruca- tions Standardization Sector Collaboration Guidelines IETF と ITU-T 標準化セクタ間の共同研究ガイドライン fo. 、 G. Fishman 他 ( RFC2436 置換 ) 標準イ士様策定にかかわる ITU-T と ISOC/IETF の 協同イ乍業における指針を規定している。、、広報 (lnforma- lnformation 1 "Data elements and interchange formats interchange ー Representation of dates and times ” ISO 8601 : 1988 ( E ) , June 1988 今回の RFC UNIX MAGAZINE 2002.11 tional)" として 2002 年 8 月に公開された。 RFC2436 を 置き換えている。 これまで、 ITU-T と ISOC/IETF の共同研究につい ては RFC2436 で規定されていた。 RFC3356 は、 RFC 2436 の公開後に発生したさまざまな変更点を反映したも のである。共同研究の対象や進め方をはしめーの マッピングや、標準文書の共有法などを規定している。 RFC3356 は、 2001 年 11 月 30 日に承認された ITU- T の A シリーズ勧告の補遺として公開されたものを RFC シリーズとして公開するものである。 MPLS 関連 RFC3353 Overview of 旧 Multicast in a Multi-Proto- col Label Switching (MPLS) Environment MPLS 王竟における旧マルチキャスト C)fBÆ要 fo. 、 D. Ooms 他 MPLS (Multi-Protocol LabeI Switching) 環境で IP マルチキャストを利用するために鮹夬しなけれはなら ないさまざまな間題を提示している。、、広報 " として 2002 年 8 月に公開された。 MPLS における IP 通信については、ユニキャストを 中心に言侖が進めらマルチキャストは将来的な題と されてきた。これまで、 IP マルチキャストに分類される マルチキャスト技術としては、経路制御とバケット医が 相互に依存しつつ複雑に勵里するものや、特定規模のネッ トワーク・ドメインを想定したものなどカ甘是案されている。 しかし、これらの技術を MPLS てサポートするには、解 決すべき間題が山積しているのか現伏である。 RFC3353 では、ドメイン間マルチキャスト経路制御は 対象外とし、 MPLS におけるドメイン内マルチキャスト 171

APEX ( アプリケーション間交換 ) 関連 RFC3340 The AppIication Exchange Core APEX コア PS. 、 M. Rose 他 アプリケーション層で実現される拡張可能な非い垬月メッ セージリレーオである APEX ( アプリケーション間交 換 ) のコア部分を規定している。現在の状態は、、標準化へ 窈是唱 " である。 2002 年 7 月に公開された。 APEX は、 RFC3080 で規定されている拡張可能な汎 用アプリケーション間トランスポート・プロトコルである BEEP (The Blocks Extensible Exchange Protocol) をベースとした、アプリケーション間の非同期慂信のフレ ームワークである。 APEX の各通信は BEEP のプロファ イルとして規定される。 APEX を利用することで、 IM ( インスタント・メッセ ージ ) のような非同期のアプリケーション層通信をおこな うアプリケーションをサポートする汎用的なフレームワー クが実現できる。 RFC3340 は、 APEX アプリケーションの下部層とな る APEX コアを規定している。 APEX コアは APEX フ レームワークにおいて最善努力 (best effort) 型のデータ グラム・サービスを実現する部分で、他の APEX アプリ ケーションに対しもっとも基本的な機能を提供している。 RFC3340 では、 APEX のフレームワーク、 APEX コ アの BEEP プロファイルおよび DTD を規定している。 RFC3341 The Application Exchange (APEX) Access Service APEX アクセスサービス PS. 、 M. Rose 他 APEX を実現するための要素である、、 APEX アクセ スサービス " を規定している。現在の状態は、、標準化への 唱 " である。 2002 年 7 月に公開された。 APEX アクセスサーピスは、 APEX フレームワークに おいてデータの提供および取得に関する要求や応答を規定 する要素である。 RFC3341 では、 APEX アクセスサー ピスのプロトコルおよび BEEP プロファイル、 DTD を 規定している。 RFC3342 The Application Exchange (APEX) Option Party Pack, Part Deux! UNIX MAGAZINE 2002.11 RFC ダイジェストー@ APEX オプション・パーテイバックパート 2 PS. 、 E. Dixon 他 175 、、損失間隔 (loss distance)" 、、損失期間 (loss period)" RFC2680 の計測基準から派生した 2 つの計測基準 fo. 、 R. Koodli 他 片方向パターンサンカレ聲準 RFC3357 One-way Loss Pattern SampIe Metrics 則関連 レフィックス " を規定している。 中のプロファイルを IANA に当求するためのツ -- 印判勺プ RFC3349 では、まだ標準イし茴程に乗せられていない策定 段階のプロファイルを識別するためのガ去はない。そこで よって登録される URI を使っておこなわれるが、策定 ワークである。 BEEP のプロファイル識別は IANA に プリケーション間トランスポート・プロトコルのフレーム BEEP は RFC3080 て規定された、拡張可能な汎用ア としても公開されている。 て 2002 年 7 月に公開された。 BCP シリーズ (BCP 59 ) てについて規定している。ン鄲芋点での最良の方法 " とし BEEP プロファイルの一勺なプレフィックスの割当 BCP. 、 M. Rose ( 別称 BCP 59 ) の一時的プレフィックス 各 IETF 分科会て開発中のプロファイル群を識別するため lnternet Engineering Task Force under Development by the Working Groups of the RFC3349 A Transient Prefix for ldentifying Profiles BEEP 関連 ・ dataHopping ・ hoId4Endpoint ・ dataTiming ・ attachOverride 規定している。 ュの挙動を変更するためのオプションとして以下の 4 つを RFC3342 では、 APEX のデフォルトのリレーメッシ 2002 年 7 月に公開された。 ック ) ている。現在の状態は、、標準化への提唱 " である。 APEX における各種オプションをまとめ ( パーテイバ

RFC ダイジェストー 表 3 インターネット・ドラフトの出典別分類 ( 2002 年 8 月 15 日 ) 出典 過去 6 カ月ミ琺 3 カ月過去 1 カ月 ・ Attribute Certificate Transfer ( 属す臨正明書伝送 ) 第 2 版窈助日 ・ CMS のプロトコル定義とアルゴリズム定義の分離 RFC2630 および RFC3211 との下位圧換性は糸財寺さ れている。 RFC2630 に含まれていた暗号アルゴリズムに 関する部分は、次に紹介する RFC3370 に移された。 RFC3370 Cryptographic Message Syntax (CMS) AI- gorithms CMS のアルゴリスム PS. 、 R. Housley ( RFC2630 、 RFC3211 更新 ) CMS で暗号アルゴリズムを使う場合の慣例を定義し ている。現在の状態は、、標準化への提唱 " である。 RFC 2630 、 RFC3211 を更新する RFC として 2002 年 8 月 に公開された。 RFC3370 は RFC2630 の 12 章の部分を置き換える 文書である。 CMS 定義の残りの部分は RFC3369 にう黐隹 された。 今回扱った RFC を表 1 ~ 2 にまとめる。 インターネット・ドラフト公開速報 今回はおもに、 2002 年 7 月 16 日 ~ 9 月 15 日に公開 されたインターネット・ドラフトについてまとめる。 2002 年 8 月 15 日および 2002 年 9 月 15 日を起点と して、それぞれ、、過去 1 カ月 " 、、過去 3 カ月 " 、、過去 6 カ 月 " の期間に公開されたインターネット・ドラフトの総数 と、それらの出典別分類を表 3 および表 4 に示す。多い 月には 500 本程度、少ない月には 100 本程度公開される ことを考慮すると、 7 月 16 日 ~ 9 月 15 日に公開された 置■第■ー■■ さきほどと同様に 2002 年 8 月 15 日および 2002 年 まとめる。 して、分利会別のインターネット・ドラフトの公け羽大況を IETF の各分利会ごとの活動の、、活発さ " を示す孑票と 活動が活発な分科会 本数はオ剽細勺だったことが分かる。 UNIX MAGAZINE 2002.11 、、過去 6 カ月 " の期間に公開されたインターネット・ドラ 9 月 15 日を起点として、、、過去 1 カ月 " 、、過去 3 カ月 " IETF 分科会 個人名義 公開数の合計 1 , 199 1 , 438 2 , 637 586 691 1 , 277 142 133 275 表 4 インターネット・ドラフトの出典別分類 ( 2002 年 9 月 15 日 ) 出典 過去 6 カ月過去 3 カ月過去 1 カ月 IETF 分科会 個人名義 数の合計 1 , 014 1 , 187 2 , 201 540 614 1 , 154 121 124 245 フトについて、それぞれ公開数の上位から 10 位程度まで 集計した結果を表 5 およひ表 6 に示す。 IETF 工リア / 分科会別の公開状況 IETF の全分利会をエリアごとに分類し、 2002 年 8 月 15 日および 2002 年 9 月 15 日を起点とした過去 1 カ月 間に公開された本数を集計した。その結果を表 7 ~ 10 に CRISP 分科会 今回の対象期間中にもっとも多くのインターネット・ド ラフトを公開したのは CRISP (Cross Registry lnfor- mation Service Protocol) ・分科 - 会であった。 CRISP う斗会はアプリケーション・エリアのう斗会で、 ドメイン名や IP アドレスといった整合生を保つ必要のあ る情報の検索などを目的としたプロトコル (CRISP) の標 準化に関する言侖をおこなっている。 今回対象とした期間中に CRISP 分利会が公開したイ ンターネット・ドラフトを簡単に紹介する。 [draft-ietf-crisp-iris-core-OO txt] lnternet Registry lnformation Service ( 旧 ) インターネット・レジストリ情報サービス インターネット・レジストリの情報サーピスを目的とし たクライアント・サーバー型のプロトコルとして IRIS を 提案している。 [draft-ietf-crisp-iris-beep-OO. txt] Using the lnternet Registry lnformation Service 0R5 ) over the Blocks ExtensibIe Exchange Proto- BEEP 上での旧の利用 coI(BEEP) 181

RFC3367 では、 CNRP の位置付けや目的を説明した RFC3358 では、これらのデータユニットで利用可能な うえで、 CNRP のプロトコル仕様、 CNRP 問合およ チェックサム・オプション TLV を定義している。具ー純勺 び応答の XML DTD を規定している。 には、チェックサム・オプション TLV の形式、各デー タュニットにおけるこの TLV の使い方、署名の計算との 経路制御関連 里などを規定している。 RFC3345 Border Gateway Protocol(BGP) Persistent RFC3359 Reserved Type, Length and Value (TLV) Route Oscillation Condition Codepoints in lntermediate System tO lntermediate BGP における永糸強勺な経謝辰大態 System fo. 、 D. McPherson 他 ISIS における予約済み T Ⅳコードボイント BGP における経各の振重力 (route oscillation) 状態の 旧 fo. 、 T Przygienda 2 つの主要な発生原因をまとめ、糸響各の振重丿獻態を回避し ISIS で利用されている TLV をまとめている。、、広 やすいネットワークの言 t 方釗について論じている。、、広 として 2002 年 8 月に公開された。 報 " として 2002 年 8 月に公開された。 ISIS については、 OSI の規定以外に RFC でも各種の BGP は EGP の一種で、ドメイン間での糸各制御を 拡張カ醍案されており、 TLV もそれぞれの文書で個別に 目的としたプロトコルである。 BGP は、 AS (Autono- 定義されている。 RFC3359 では、 TLV の値の衝突の回 mous System) 間で糸各を交換する E-BGP と、 E-BGP 避を目的として、これまでに定義された ISIS の TLV の で交換した糸各を AS 内の BGP ルータ間で交換する I- 値を表にまとめている。 BGP から構成される。 I-BGP では、ドメイン内のすべ ISIS の TLV は ISO や SIF 、 IETF によって提案さ ての BGP ルータで経路を交換する必要があるが、これら れているもので、 RFC3359 は TLV の値の標準もしくは をすべて相互に接続すると生に乏しくなってしま 認可ではない点に注意してほしい。 う。 BGP では、この間題を解決するための去として、 IOTP 関連 、、ルート・リフレクション " と、、 AS コンフェデレーショ ン " の 2 つか導入されている。 RFC3354 lnternet Open Trading Protocol Version 2 RFC3345 では、これらのガ去に起因する 2 不鶤頁の経 Requirements 路の振動の発生プロセスについて岩田に述べたうえで、こ IOTP 第 2 版の要求藝頁 のような糸響各の振動の発生を回避しやすいネットワークの 旧 fo. 、 D. EastIake 他 言方釗について言義している。 IOTP (lnternet Open Trading Protocol : インター ネット公開取引プロトコル ) の第 2 版の要求事項をまとめ RFC3358 Optional Checksums in lntermediate Sys- ている。、、広報 " として 2002 年 8 月に公開された。 tem to lntermediate System (ISIS) 旧のチェックサム・オプション IOTP はインターネット上での商取引のためのフレー fo. 、 R. KoodIi 他 ムワークであり、第 1 版は RFC2801 で規定されている。 IOTP 第 1 版ではメッセージの符号化に XML を利用 ISIS (lntermediate System to lntermediate Sys- しているが、第 1 版の標準化が進められていたころには tem) のチェックサム・オプション TLV (Type, Length and Value) を定義している。、、広報 " として 2002 年 8 XML における署名の標準が規定されていなかったため、 RFC2802 で IOTP での利用を目的とした XML 署名方 月に公開された。 法を定義していた。しかし、 2002 年 3 月に RFC3275 と ISIS は IGP の一種で、 ISP などにおけるドメイン内 して XML における署名に関する標準か規定されたため、 糸各制御に用いられている。 ISIS では、データュニット RFC3354 では第 1 版の機能に加えて RFC3275 に処 の一部である CSNP (Complete Sequence Numbers した署名をサポートした IOTP 第 2 版を提案し、その要 Protocol) および PSNP (Partial Sequence Numbers Protocol) のチェックサムは提供されていなかった。 求事項をまとめている。 174 UNIX MAGAZINE 2002.11

経路制笹サポートに焦点を当てて、これらの間題の概要 を提示している。さらに、 MPLS を用いた IP マルチキャ ストにおける QoS (Quality of Service) や TE (Traffic Engineering) についても言義している。 L2TP 関連 RFC3355 Layer Two TunnelIing Protocol(L2TP) Over ATM Adaptation Layer 5 (AAL5) ATM AAL5 を介した L2TP PS. 、 D. Eastlake 他 ATM の AAL5 接続において L2TP ( 第 2 層トンネリ ング・プロトコル ) を利用するためのガ去を規定している。 現在の状態は、、標準化への提唱 " である。 2002 年 8 月に 公開された。 L2TP は、ネットワーク構成技術にかかわりなく PPP トラフィックをトンネリングするための汎用的な技術であ る。 RFC2661 では、第 2 層としておもに ISDN/PSTN べースの HDLC フレーミング・ネットワークを扱ってい る。 RFC3355 では、それに加えて ATM AAL5 フレー ミングによる接続を規定している。 RFC3371 Layer Two Tunneling Protocol' L2TP' Management lnformation Base L2TP 用 M 旧 PS. 、 E. Caves 他 L2TP 用の MIB を規定している。現在の状態は、、標 準化へ窈是唱 " である。 2002 年 8 月に公開された。 RFC3371 は、 L2TP によるネットワーク接続インター フェイスを SNMP て扱うための MIB を規定している。 PS. 、 B. Haberman 他 スト・アドレス ユニキャストプレフィックス・べースのⅢ v6 マルチキャ d resses RFC3306 Unicast-Prefix-based IPv6 関連 lPv6 Multicast Ad- 172 である。 2002 年 8 月に公開された。 の拡張を提案している。現在の状態は、、標準化への提唱 " くマルチキャスト・アドレスを利用できるようにするため チャにおいて、ユニキャスト・プレフィックスにもとづ IPv6 のマルチキャストアドレッシング・アーキテク IPv6 のアドレッシング・アーキテクチャは RFC2373 ー で規定されている。 RFC2373 で定義された IPv6 マルチ キャスト・アドレスのフォーマットは、 16 ビットのアド レス識別子、フラ久スコープ情報に続いて、 112 ビット のグルーフ識別子を指定する形式になっている。この形式 のマルチキャスト・アドレスにはグルーフ哉別子しか含ま れていないため、実際のアドレスを割り振るには別のプロ トコルが必要となる可能生か高い。 そこで RFC3306 では、 112 ビットのグルーフ常設別子 空間に、 64 ビットのネットワーク・プレフィックスと 32 ビ ットのグルーフ第筬別子を含める構造を提案している。この 形式では、 RFC2373 でのマルチキャスト・アドレス形式 のフラグの 2 ビット目を立てるため、 FF3x: ( x はスコー フ . 別子 ) で始まるアドレスか利用されることになる。 RFC3307 Allocation Guidelines forlPv6 Multicast Ad- d resses v6 マルチキャスト・アドレスの割当てガイドライン PS. 、 B. Haberman IPv6 マルチキャスト・アドレスの割当てに関するガ イドラインを規定している。現在の状態は、、標準化へク是 唱 " である。 2002 年 8 月に公開された。 IPv6 マルチキャスト・アドレスには、恒 . ク朝勺なものと 重加勺なものがある。個々のマルチキャスト・アドレスは多 対多間の通信における識別子として働くため、なんらかの ガ去で通信をおこなうグループにアドレスを割り振る必要 がある。 RFC3307 では、 IPv6 マルチキャスト・アドレスの衝 突の可能性を減らすために、該当アドレスの割当てをおこ なうすべての機関 ( など ) で守るべきガイドラインを規定 している。 RFC3307 は IP 層のアドレスだけでなく、 IP 層アドレスの一部もしくはすべてを MAC 層アドレスに 符号化するようなメディアを用いたリンク層も対象として いる。 TCP 関連 RFC3360 lnappropriate TCP Resets Considered Harmful 不適切な TCP リセットの有害性に関する考察 BCP. 、 S. FIoyd ( 別称 BCP 60 ) UNIX MAGAZINE 2002 ユ 1

分科会である。メンバーには IETF の専門家も含まれて いる。 RFC3305 は、 URI 関連分野で W3C および IETF が 標準化を進めるにあたって必要になると思われる事項を勧 告したものである。 ます、 URI や URN に関する解釈を規定したうえで、 現在の標準イし茴程における混乱を孑商し、 URI スキーム や URN 名前空間の登録にかかわる事項について言及し ている。さらに、 W3C/IETF URI 立案グループとして、 ・舸変の標準化や RFC の更新、 IANA の登録について勧 告している。 LDAP 関連 RFC3296 Named Subordinate References in Light- weight Directory Access Protocol(LDAP) Directories LDAP ティレクトリにおける名前付き従属参照 PS. 、 K. Zeilenga LDAP ディレクトリでの名前付き従属参照の管理およ び表現に用いるプロトコル要素とスキーマの詳細を規定し ている。現在の状態は、、標準化への提唱 " である。 2002 年 7 月に公開された。 RFC3296 では、従属参照情報に用いられる名前付きの 参照オプジェクトを管理するための参照オプジェクト・ク ラスおよび参照属性タイプを定義し、具イ勺なシナリオに もとづく利用例を示している。プロトコルの文法規約やセ マンティクスについては論していない。 SIP 関連 RFC3351 User Requirements fo 「 the Session lnitia- tion P 「 0t0C0 S Ⅲ ) in Support of Deaf, Hard of Hear- ing and Speech-impaired lndividuals 聴覚障害者および言語障害者のサポートに関する SIP の ューサー要求藝頁 旧 fo. 、 N. CharIton 他 SIP ( セッション開始プロトコル ) を用いて音声以タ ) ガ去で意思、の疎通を図ることを目的としたセッション窈寉 立に関する要求事項をまとめている。、、広報 " として 2002 年 8 月に公開された。 SIP はこれまで音声通話用のセッションの確立を目的 の 1 っとして言墟侖されてきた。しかしながら、音声通言甜ご けでは聴覚章害者や言言章害者など、音声による意鬯、の疎 UNIX MAGAZINE 2002.11 RFC ダイジェストー トに関する要求事項を、以下のフレームワークに沿ってま では、 SIP における聴覚障害者や言言章害者などのサポー シーなど、幅広い問題を考慮する必要がある。 RFC3351 るインターフェイスの種別の通去、ユーサーのプライバ には、異なるメディアの柤変換、ユーサーかイ吏用してい ればならない。これらのインターフェイスをサポートする さまざまなユーサー・インターフェイスをサポートしなけ だけでなくテキスト・ストリームや央像を用いた手話など、 ケーションを可能にすべきである。そのため、 SIP は音声 みならす、テキスト・ストリームや手話も含めたコミュニ 通が困難な人びとのサポートは十分とはいえない。音声の 情報の機密生 ・資源管理 全体言 1 ・ ・インテリジェントなメディア・ゲートウェイ ・ユーザーに関する情報 接続確立の容易性 とめている。 そのうえで、異なる複数のユーサー・インターフェイス 3361 では、このようなケースにおいて SIP プロキシー ノヾ ーを利用しなければならないというケースがある。 RFC 置し、クライアント・ホストはそれらのプロキシー・サー イン内部では外部向けの SIP プロキシー・サーバーを設 一方、 SIP の利用形態の 1 っとして、特定の管理ドメ クライアントに通知するために利用される。 いるネームサーバーの IP アドレスなどの情報を、重加勺に ホストの IP アドレスや、その管理ドメインで用いられて 第勺におこなうためのプロトコルである。クライアント・ DHCP は、クライアント・ホストのネットワーク設定を 月に公開された。 いる。現在の状態は、、標準イヒの提唱 " である。 2002 年 8 トに重加勺に言するための DHCP オプションを規定して SIP プロキシー・サーバーの IP アドレスをクライアン PS. 、 H. Schulzrinne SIP サーパーのための DHCP オプション col(SIP) Servers (DHCP-for-lPv4) Option for Session lnitiation Proto- RFC3361 Dynamic Host Configuration ProtocoI を含むさまざまなセッションについて考察している。 177

第 2 層関連 RFC3366 Advice to link designers on link Automatic Repeat reQuest (ARQ) リンク層言者へのアドバイス . リンク ARQ BCP. 、 G. Fairhurst 他 ( 別称 . BCP 62 ) リンク層言 1 者に、、リンク ARQ ( 自動反復要求 ) " 技術 を広めるための文書である。、、現時点での最良のガ去 " と して 2002 年 8 月に公開された。 BCP シリーズ (BCP 62 ) としても公開されている。 リンク ARQ は、通イ叔こ受信側のデバイスがエラー を検出すると自重加勺に再送を要求する手法で、モデムなど でひろく利用されている技術 (LAPM など ) である。 ARQ は通イ謝支術の世界では一ヨ勺な技術だが、その上 位層として TCP/IP などのインターネット・プロトコル を利用する場合には、それぞれの持性を考慮しなけれは通 信生能の劣化の原因となる可能性がある。しかし、 ARQ を利用した第 2 層技術において TCP/IP などのインター ネット・プロトコルをサポートする際に考慮すべき点を論 した参考文献は少ない。 そこで RFC3366 では、インターネット・プロトコル のサポートを検討しているか : インターネット・アーキテ クチャにあまり精通していなかったり、リンク層の言 t に よってそのリンク上のインターネット・トラフィックの 性能や効率が景受けるような場面に直面しているリン ク層言者やリンク技術の実装者へのアドバイスをまとめ ている。 おもな内容は、さまざまな ARQ 技術の実現方法、イ ンターネット技術と ARQ との関連について考慮すべき 頁、その応用である。 を規定している。、、広報 " として 2002 年 8 月に公開さ れた。 RFC3357 では、 IPPM フレームワークにもとづい た片方向損失パターンサンプルの計測基準として、 RFC 2680 の規定に加えて、 Type-P-One-Way-Loss-Distance-Stream ・ Type-P-One-Way-Loss-Period-Stream を定義している。 176 電子メール関連 RFC3348 The lnternet Message Action Protocol (lMAP4) Child Mailbox Extension IMAP4 : 子メールポックス拡張 fo. 、 M. Gahrns 他 IMAP4 (lnternet Message Action Protocol Ver- sion 4 ) に対する、、子メールポックス拡張 " を規定してい る。、、広報 " として 2002 年 7 月に公開された。 IMAP4 は適隔メッセージ蓄積を扱うために言された プロトコルである。 POP3 のように単純なメール取得フ。ロ トコルとして利用できるだけでなく、接続 / 切断モデルの 双方をサポートしているため、遠隔地にあるメールポック スを妾クライアントから扱うこともできる。また、遠隔 サーバーでのメッセージ処理などのオ冓も規定している。 RFC3348 では、 IMAP4 に対する、、子メールポック ス (CHILDREN) 拡張 " を規定している。これは LIST コマンドの拡張で、 LIST コマンドで出力されるメール ポックスのリストに対し、各メールポックスの下に別の メールポックス ( 子メールポックス ) か存在するかどうか を、、 \HasChiIdren" および、、 \HasNoChiIdren" フラグ て表現できるようにするものである。 子メールポックス拡張はすでに各種の IMAP サーバー で実装されており、 RFC3348 はそれを RFC として参照 できるようにするために公開された。 URI/URL 関連 RFC3305 Report from the 」 oint W3C/lETF URI PIanning lnterest Group. Uniform Resource ldentifiers (URls), URLs, and Uniform Resource Names (URNs): Clarifications and Recommendations W3C/lETF URI 竢グループによる報告 URIS URL 、 URN に関する明確化と推奨事項 旧 fo. 、 M. MeaIIing 他 W3C/IETF の URI 立案グループによる URI および URL 、 URN の標準化に関する推奨事項を規定している。 、、広報 " として 2002 年 8 月に公開された。 W3C URI 立案グルーフ (W3C URI PIannning ln- terest Group) は、 W3C における URI 関連の作業の評 価およひ驃準化を目的として 2000 年 10 月に結成された UNIX MAGAZINE 2002.11