RFC ダイジェストー 現在の実装 会義の名前空間はチャンネルと呼はれる単位でグループ 現在孑商されている間題点 化さ会議の参加者はチャンネルごとにグループ化され ・セキュリティに関する考察 る。チャンネルは参加者の要求によって重加勺に作成され、 IRC 網全域 ( 場合によっては一緇 ; ) に伝般される。参カ睹 について言言龠している。 は IRC クライアントを利用して任意の IRC サーバー 接続する。 RFC2812 lnternet Relay Chat: Client Protocol インターネット・リレーチャット . クライアント・プロ IRC 網の基本通信モードはチャンネルを単位とした会 トコ丿レ 議であるが、ポイント・ツー・ポイント型、プロードキャ fo. 、 C. KaIt ( RFC1459 更新 ) スト型の通信もサポートしている。 RFC2810 では、これ らの通信モードに関する言墟侖もおこなわれている。 RFC2810 で定義された IRC クライアントの言田を規 また、 IRC て利用する、、 IRC プロトコル " の提供する 定している。、、広報 " として 2000 年 4 月に公開された。 サービスも規定している。以下に RFC2810 で規定して RFC1459 を更新している。 いるサービスを示す。 IRC に参加するには、 IRC クライアントを利用して IRC 網に接続する。 IRC クライアントは IRC サーバーを ・クライアントの位置検索 利用することで、他の IRC クライアントと自由に通信が ・メッセージの中継 おこなえる。 IRC サーバーの機能を利用すれは、 IRC ク ・チャンネルの提供と管理 ライアントは IRC 網上で 1 対 1 、 1 対多の通信ができる。 RFC2810 は、 IRC フロトコルの言岩田な仕様について RFC2810 では、 IRC クライアントが IRC サーバー は規定していない。 との通信に利用する IRC クライアント・プロトコルを規 定している。具 f 勺には、 RFC2811 lnternet Relay Chat: Channel Management インターネット・リレーチャットチャンネルの管理 サーバーへの接続 旧 fo. 、 C. Kalt ( RFC1459 更新 ) ・チャンネル作 RFC2810 で規定されている IRC のチャンネルによる ・メッセージの送信 参加者のグループ化手法の詳細を定義している。、、広報 " ・サーノヾーへの間合せ として 2000 年 4 月に公開された。 RFC1459 を更新して ・サービスの間合迂 いる。 ・参カ睹の問合迂 IRC ではチャンネルを利用することで、 IRC 網に接続 ・その他 しているクライアントをグルーフ。化できる。これにより、 の頁目について言墟龠している。 IRC では複数の会義を並行して開催できる。 また、現在の実装や孑商されている間題点についても考 チャンネルはクライアントからの要求によりサーバー上 察している。 て加勺に作成さクライアントか管理する。これにより、 RFC2812 には IESG からのコメントが付加されてい 複数のチャンネルのう州攵管理を実現する。 る。概要を以下に示す。 RFC2811 は、 IRC のチャンネルについて、 「 IRC プロトコルではクライアントどうしによるデータ ・チャンネルの特徴 の送受信も可能である。メールなどの他の通信イ懾と同様 ・チャンネルの状態 に、受信したデータをどう処理するかよく考えなけれはな ・チャンネルの管理法 らない。 IRC プロトコルのセキュリティに関するより詳し い情報は、 http://www.irchelp.org/irchelp/security/ を規定している。 で得られる」 また、 二一口 155 UNIX MAGAZINE 2000.7
ダイヤルアッフ鮟続で L2TP プロトコルによって強制 トンネルを確立する手法と、 RADIUS によるトンネルの 管理を規定している。 された。 、、広報 " として 2000 年 4 月に公開 現在のインターネットでは、セキュリティなどのさま ざまな理由でトンネリング接続か利用されている。ダイヤ ルアップでインターネットに接続する際も、トンネリング による接続が必要な場合が多い。 ーヨ殳に、トンネリングの不頁としては、 任意トンネリング : 利用者の意でトンネルを確立する 強制トンネリンク : 利用者の意とは無関係に自重加勺にト ンネルを確立する がある。 RFC2809 では、ダイヤルアッフ。接続で L2TP プロ トコルを利用して強制トンネリングをおこなうための手法 と、その実装について論している。ダイヤルアップ接続の 利用者管理にひろく用いられている RADIUS を組み合わ せることで、トンネル確立時の正などのトンネル管理を 統合する手法を提案している。これにより、トンネルを確 立する際のオ冓が簡略化できる。 RFC2809 では、トンネルを実際に確立するサー ( トンネルネットワーク・サーバー ) を両端に設置し、 RA- DIUS か艨動しているアクセスサーバーと組み合わせる方 について言侖している。扱われている認証方法を以 - ドに ・利用者識別子 ( ューザー (D) の扱い ・ RADIUS を利用したトンネル確立時の認証 / 切断 ・強制トンネルの確立去と RADIUS の有効性 式を提案している。この方式を偂醍として、 ・アクセスサーバーによる認証 ー認証データがアクセスサーバーにある場合 - 認証データを RADIUS リプライ・フォワー グによって取得する場合 ・トンネルネットワーク・サ→ヾーによる認証 ・両方のサーバーを利用した認証 、デ、イン RFC2809 ではトンネリング・プロトコルとして L2TP だけを扱い、他のトンネリング・プロトコルはヌ寸象として 154 いなし、。 RTP 関連 UNIX MAGAZINE 2000.7 ネルを特定できる。 は接続しているサーバーにかかわらす単一の名前でチャン に情報を交換し、名前空間を統 - ーする。そのため、参カ睹 間を形成できる。 IRC 網に存在する IRC サーバーは互い ン・レベルて豸虫自の網を形成することで、大莫な会議空 システムである。複数の IRC サーバーがアプリケーショ を効率的にグルーフイヒできる分散型モデルを採用した会議 の基本アーキテクチャを規定している。 IRC は、利用者 ている文字べースのリアルタイムチャット・システム IRC RFC2810 は、現在のインターネットでひろく利用され のシステムが各不是案されている。 リアルタイム性などがあり、それぞれの要求を満たすため としては、参加者の管理方法、対象となるデータの種類、 にはさまざまなものがある。会義システムをう嶽頁する孑票 インターネットを利用して会義システムを実現するガ去 に新たに公開された。 1459 でも規定されているが、山も匠の実装を反映するため 年 4 月に公開された。 IRC は 1993 年に公開された RFC 基本アーキテクチャを規定している。、、広報 " として 2000 文字べースのリアルタイム会議システムである IRC の 旧 fo. 、 C. KaIt ( RFC1459 更新 ) インターネット・リレーチャット : アーキテクチャ RFC2810 lnternet Relay Chat: Architecture IRC ( インターネット・チャット ) 関連 ド形式を定義している。 ルで用いられる冗長符号イ彡式を収容する RTP ペイロー する特性を提供するために、 ITU-T T. 140 でのフロトコ れる。 RFC2793 では、これらのテキスト形式対話に対応 はごく小さいものだが、遅延なく伝達されることか要求さ らの打鍵か音声認識によりおこなわれる。入力のバンド幅 義されている。テキスト形式対話の入力は、キーポードか テキスト形式の対話については ITU-T の T. 140 で定 、、標準化 , 、、ク是唱 " である。 2000 年 5 月に公開された。 めの RTP ペイロード形式を定義している。現在の状態は テキストによる対話をおこなうセッションを伝達するた PS. 、 G. Hellstrom テキスト形式文囎舌用の RTP ペイロード RFC2793 RTP Payload for Text Conversation
RFC2814 では、 IEEE802 形式のネットワークにお いて RSVP べースの流入管理をおこなうためのシグナ リング手法およひフ。ロトコルとして SBM を提案してい る。 SBM は、 IEEE802 ネットワークと RSVP など のインターネット層での管理機構の対応を定義している。 RFC2814 では、とくに RSVP に対・応するホスト、ルー 夕、リンク層機器 ( スイッチ、プリッジ ) を用いて RSVP のデータフローを扱うための運用去に着目しており、そ れらを利用するプロトコルとして SBM を定義している。 Int-Serv と IEEE802 の対応関係は RFC2815 ~ 2816 で定義されている。あわせて参照してほしい。 RFC2815 lntegrated Service Mappings on IEEE 802 Networks 旧 EE802 ネットワークでの糸発合サービス・マッピンク PS. 、 M. Seaman 他 IEEE802. ID MAC プリッジ ( スイッチ ) などで接続 されている IEEE802 ネットワーク・セグメントで I ⅲー Serv を利用するための技術間の対応関係を定義している。 現在の状態は、、標準化への提唱 " である。 2000 年 5 月に 公開された。 IEEE802 形式のネットワーク、とくに IEEE802. ID- 1990 や IEEE802. ID ー 1998 に準処したスイッチ機器で は、スイッチ内で異なる待ち行列の処理ができる。また、 IEEE802. IQ では、 IEEE802 形式 Ethernet/802.3 で トラフィック・クラス識別子を伝達する長をおこなって いる。このように山近の IEEE802 ネットワークでは、ト ラフィックごとに異なる処理やクラスに関するシグナリン グが可能である。 RFC2815 は、 IEEE802 技術で実現さ れる負荷制御およびサービスの保証に関連する機能と、統 合サーピスの機能Ⅲ」の対係を定義している。 RFC2816 A Framework for lntegrated Services Over Shared and Switched IEEE 802 LAN Technologies 型 / スイッチ型旧 EE802 LAN 技術による統合サービ 旧 fo. 、 A. Ghanwani 他 ス用のフレームワーク UNIX MAGAZINE 2000.7 公開された。 ムワークを定義している。、、広報 " として 2000 年 5 月に ネットワークにおいて、 Int-Serv を適用するためのフレー IEEE802 ネットワークのような共有型 / スイッチ型の RFC ダイジェストー ついて論している。 を提供する際に考慮すべき問題点を明らかにし、それらに ネットワークの QoS 関連技術を利用して、統合サーピス べている。とくに 2 層を形成する技術である IEEE802 おけるさまざまな状況での統合サービスの利用について述 RFC2816 では、共有型 / スイッチ型のネットワークに 8. 実装に関する恥頁 7.4. Q 。 S シグナリング 7.3. 流入管理 7.2. スイッチモデル 7.1. 工ンドステーション・モテフレ 7. ネットワーク内のバンド幅マネージャーのモデル 6.2. 実装に関する言兪 : 集中型とう気型の上は交 6.1. コンホーネント 6. 基本アーキテクチャ 5. 要求事項と到達目標 内容を紹介するために目次の一緇 ; を以下に示す。 8.7. 受信側の混在に関する間題 8.6. 異なる予約形式に関する間題 8.5. 入力ユーザー優先度の上書き 8.4. 管理下にない集約フローの再腕づけ 8.3. サーピスとリンク層優先度の対応 8.2. 待ち行列管理 8.1. スイッチク用ヨ生 ットワークの場合 9.5. 半二重スイッチ型および共有型のテマンド優先度ネ ネットワーク 9.4. 半二重スイッチ型ネットワークとトークンリング・ 9.3. 半二重スイッチ型ネットワークの場合 9.2. 共有モデル Ethernet ネットワークの場合 9.1. 全二重スイッチ型ネットワークの場合 9. ネットワーク・トボロジー別シナリオ 153 fo. 、 B. Aboba 他 RADIUS を利用した L2TP 強制トンネリング実装 neling via RADIUS RFC2809 lmplementation of L2TP Compulsory Tun- VPN/ トンネリング関連 11. まとめ 10. 正当化