いる。現在の状態は、、標準化への提唱 (Proposed Stan- dard)" である。 RFC2414 を置き換え、 RFC2581 を更 新する RFC として 2002 年 10 月に公開された。 RFC 2414 は、実験的 (Experimental)" として公開されたが、 この文書から標準茴程に乗ることになった。 RFC3390 では、 TCP のネノ祺月ウインドウサイズの上限 を、最大セグメントサイズ (MSS) を担售とした、 min (4*MSS, max (2*MSS, 4380 bytes)) という計算式で表される値に拡大することを提案してい る。この式によ川ま、初期ウインドウサイズの上限は、 ・ MSS が 1 , 095 ノヾイト飛茴なら MSS の 4 倍 PS. 、 B. Cain 他 ( RFC2236 置換 ) IGM P 第 3 版 Sion 3 RFC3376 lnternet Group Management Protocol, Ver- マルチキャスト関連 うに刻長した場合の利点と欠点を論している。 となる。 RFC3390 では、匆期ウインドウサイズをこのよ ・そのあいだなら 4 , 380 バイト ・ MSS が 2 , 190 バイトより大きければ MSS の 2 倍 UNIX MAGAZINE 2003.2 最大 25.5 秒から 53 分に延びた。これにより、きわめ ・問合迂メッセージ中の最大 ) 芯答時 = 間カ甘旨数時間になり、 間隔 " を含めるようにした。 バケットに、、頑健性 (Robustness) 変数 " と、、間合せ ・間合当則では、間合当先との同期をとるために、問合を きるように変更した。 ・ IP サーピス・インターフェイスを始点リストに対応で IGMPv3 の状態として定義した。 ・ IGMPv1 および IGMPv2 システムとの相圧接続性を から、、グループ十始点リスト " による管理とした。 状態の管理について、 IGMPv2 での、、グループのみ " ものである。以下に IGMPv2 からの変点を列挙する。 IGMPv3 は、 IGMPv2 に始点フィルタ機能を加えた える RFC として 2002 年 10 月に公開された。 の状態は、、標準化への提唱 " である。 RFC2236 を置き換 である IGMP 第 3 版 (IGMPv3) を規定している。現在 IP マルチキャスト醋罔を構築するためのプロトコル RFC ダイジェストー⑩ て多数のシステムがつながったリンクでも利用できる。 ・頑健生を高めるため、ホストか状態変更メッセージを再 送するようになった。 ・今後の拡張を考慮して、、拡張データ領域 " が定義され ・レイヤ 2 スイッチの、、 s Ⅱ 00P ⅲ g " を支援するために 224.0.0.22 にレホートバケットを送るようになった。 ・少ないバケットで完全な現閃青報を送るために、レポー トバケットに複数のグループレコードを埋め込めるよう になった。 167 ゴリズムをさまざまな下位システムに適用するケースを想 ROHC 分科会で規定されている頑健なヘッダⅡ第アル fo. 、 K. Svanbro ライン 頑健な RTP/UDP/IP ヘッダ圧縮における下イガイド UDP/IP Header Compression RFC3409 Lower Layer Guidelines for Robust RTP/ 性モード ) にゼロバイト ) 宿対応を付加している。 定されている。 RFC3408 では、双方向 R-mode ( 高信頼 /UDP/RTP 用の LLA プロファイルは RFC3242 で規 日をおこなうための仕組みである。 ROHC における IP づくプロファイルを規定することで、より効率的なヘッダ LLA プロファイルとは、利用する下位層の持性にもと である。 2002 年 12 月に公開された。 モードを規定している。現在の状態は、、標準化への提唱 " タ 1 石宿 ) の LLA ( リンク層補助 ) プロファイルに新たな ROHC (RObust Header Compression : 頑健なヘッ PS. 、 Z. Liu 他 用のゼロバイト・サポート ROHC の拡張 LLA プロファイルにおける双方向 R-mode bust Header Compression (ROHC) Profile Mode (R-mode) in Extended Link-Layer Assisted RO- RFC3408 Zero-byte Support for Bidirectional ReIiabIe ROHC 関連 れているが、頑健匪の観点から再定義されている。 カ畴斤しくなった。このフラグは IGMPv2 でも規定さ ・間合メッセージ中の、、ルータ側処理孑印制 ( S ) " フラグ ストでの削除はおこなわないようになった。 ・実装の簡田翻ヒおよび明示的なメンバー」毆亦のために、ホ

ためのプロトコル作成についてはさらに言墟龠が必要として いる。 RFC3426 General ArchitecturaI and PoIicy Consider- ations アーキテクチャおよびポリシー一般に関する考察 fo. 、 S. FIoyd IETF コミュニティ全般における、ネットワーク・ア ーキテクチャやポリシーに関する疑問と回答をまとめてい る。、広報 " として 2002 年 11 月に公開された。 IETF では幅広いインターネット関連の仕様を策定し ているが、標準化やプロトコルの作成に際しては、ネット ワーク・アーキテクチャとポリシーに関する一勺なコン センサスを形成しておくのか望ましいと考えられる。 そこで RFC3426 では、インターネット全般に関する IETF コミュニティ全体のコンセンサスを形成するために 必要な情報の共有を目的として、、、よくある疑問 " に対す る回答を提示している。いくつかのトピックについては、 言侖に対するコメントやケーススタデイも紹介している。 RFC3439 Some lnternet Architectural Guidelines and Philosophy インターネット・アーキテクチャに関するガイドラインお よひ源理 fo. 、 R. Bush 他 ( RFC1958 更新 ) インターネット・アーキテクチャに関するガイドライン と原理を提示している。、、広報 " として 2002 年 12 月に 公開された。 RFC1958 を更新している。 過去に言侖、検討、発表されてきたさまざまなインター ネット・アーキテクチャ里のトピックのうち、今後も維 持していくべきだと考えられるものをまとめている。イン ターネット技術の根底にある、、単純生 " という原則をベー スとしたきわめて幅広い分野に関する考え方を示している ので、なんらかのかたちでインターネットにかかわりをも つ人は一読しておくとよいだろう。 以下に目次を示す。 1. 序論 2. 大規模システムと、、屯イ tJ 京則 ' 2.1 工ンドッーエンドに関する言籀龠と単純性 2.2 非キ彡およびネットワークの複雑さ 2.2.1 増幅原則 5.2.4 電源 5.2.5 密度 166 3. レイヤ化の有害性に関する考察 2.4 複雑さによるコストの上昇 2.3 音声通信における複雑さの教訓 2.2.2 結合原則 3.5 副次的効果 3.4 レイヤ化の曜殳 3.3 IP のトランスポート効率の怖 1- E 3.2 高機能の有害生 3.1 最商化の有害性 4.1 制御層 ; 叫秀の回避 4. 、、汎用的連携機能 " の回避 モデルの具現化 3.6 IP での EOSL (Everything Over Some Layer) 5. バケット vs. 回線交換 : 根本的な相違 5.2 PS は CS より単純か ? り有効か ? 5.1 PS ( バケット交換 ) は本質的に CS ( 回線交換 ) よ 柔生 Qos 5.2.6 固定コスト vs. 変動コスト 5.2.3 ハードウェアの複雑さ 5.2.2 マクロな操作の複雑さ ソフトウェア / ファームウェアの複雑さ 5.2.8 5.2.7 5.2.1 用コスト ) 成の試み 5.3.1 HBHI ( ホップごとの独立性 ) と OPEX ( 運 5.3 里性による複雑さ 9. まとめ 8.1 サービス配布糸習各 8. アーキテクチャ、コンポーネント比例の ~ 却リ 7. 、、 ; リな信頼生 " の神話 6. 、過剰なイ合 " の神話 TCP 関連 UNIX MAGAZINE 2003.2 ら 2 ~ 4 セグメント ( 約 4KB) に才劇長することを提案して TCP の初期ウインドウ長を、現在の 1 セグメントか PS. 、 M. Allman 他 ( RFC2414 置換 ) ( RFC2581 更新 ) TCP 初期ウインドウ窈広張 RFC3390 lncreasing TCP's lnitial Window

RFC ダイジェスト 宇夫陽次朗、小柏伸夫 今回の RFC UNIX MAGAZIN E 2003.2 ・標準化への提唱 (Proposed Standard) 段階のプロ 標準化への草稿 (Draft Standard) 段階のプロトコ ・ RFC シリーズの標準 (Standard) プロトコル ・ STD シリーズ 態にある RFC 群のリスト 3. 技術仕様の見伏 : 以下に示す標準イし茴程のいすれかの状 び入手ガ去の紹介 IANA 、 RFC Editor) の叫各先と、 RFC の配布およ 2. 連絡先 : 標準化にかかわる組織 (IAB 、 IETF 、 IRTF 、 1 第各 : この文書か扱っている内容の褪腰 とめた索引文書である。以下に、内容を目次側こ紹介する。 標準プロトコルと標準僊過程にあるプロトコルの一覧をま RFC3300 (STD 1 ) は、公開点でのインターネット 1 ) としても公開されている。 して 2002 年 11 月に公開された。 STD シリーズ (STD (Standard)" である。 RFC3000 を置き換える RFC と の状態に関する 1 辭長を共している。現在の状態は、、標準 なかで、 IETF か扱っている標準イし茴程のプロトコル群 現在のインターネットで利用されているプロトコルの Std. 、」 . Reynolds 他 ( RFC3000 置換 ) ( 別称 . STD 1 ) インターネット公式プロトコル標準 RFC3300 lnternet 0 幵 icial Protocol Standards インターネット全般 開された RFC である。 今回扱うのは、 2002 年 10 月中旬から 12 月中旬に公 トコノレ ・ BCP シリーズ 実験的 (Experimental) として公開されているプロ トコノレ 歴史的 (Historic) として公開されているプロトコル 4. セキュリティに関する考察 5. 編集者の ; 当各先 6. 著イ表示の全文 本来 STDI は 100 番ごとに発行されることになってい るが、 RFC3300 の公開時点で RFC3100 と RFC3200 は発行されていない。 RFC3000 の公開は 2001 年 11 月 だから、ほは、、、年間 RFC " となってしまっている。 RFC3424 IAB Considerations for UNiIateraI Self-Ad- dress Fixing (UNSAF) Across Network Address Trans- lation IAB による NAT を経由した UNSAF に関する考察 fo. 、 L. Daigle 他 NAT ( ネットワーク・アドレス変換 ) を経由する場合 に、 UNSAF (UNilateral Self-Address Fixing) 技術を 利用して通イ目手を石忍するガ去に関する IAB での言侖 をまとめている。、、広報 (lnformational)" として 2002 年 11 月に公開された。 通信端点間で NAT をおこなう機器を経由した場合、端 点どうしではアドレスによる相手の石忍はできない。この 問題に対処するために、 UNSAF と呼はれる技術か数多く 提案されている。これは、ポートやプロトコルなどから隠 蔽されている端点を石忍 / 擱則する技術である。 RFC3424 では、 IAB による UNSAF に関する議論 をまとめ、この技術はま麒月的には有効だが、 UNSAF の 165