図 32 IPv6 を、プロトコル " として追加 おストルするネットワクコンポーネントの種類を衂ックしてください ネットワーりエ旅ーネントび衾択。 - フロトコル 説明 サース 團りライアント プロトコルは、コンビュータ問の信に使用される言語です。 図 33 ネットワークプロトコルから IPv6 を尺 ネットワーりプロト』効択 1 ーん勗インストール贐に咼芻このコンポ ー 0 ロ にい ) t 、 ネットワーりモこタドライバ NWLiN IPX/SPX/NetBIOS 互換トランスポートプロトコル NetBEUI ロコル DLC プロトコル AppIeTa k ロコ外 ネットワークプロトコル OK 。住旦」 UNIX MAGAZINE 2001.5 応になります。 などがインストールされ、 telnet や ftp なども IPv6 対 報が分かります。このはかに、 ping6. exe 、 tracert6. exe ンドでは各インターフェイスにおける IPv6 のアドレス情 さっそく試してみましよう。たとえば、 ipv6. exe コマ これで、インストール竹業は終りです。 タックがインストールされているかを石忍しましよう。 ールは完了です。図 34 のように、 IPv6 プロトコル・ス col " お尺し、 [OK] ボタンをクリックすオ L はインスト こで Microsoft IPv6 Proto- 示されます ( 図 33 ) 。 4. すると、、、ネットワークプロトコルの〕尺 " の画面カ俵 タンをクリックします ( 図 32 ) 。 類 " を訊かれるので、、、プロトコル " を選び、 [ 追加 ] ポ 3. インストールする、、ネットワークコンポーネントの種 トール ] ボタンをクリックします ( 図 31 ) 。 2. ネットワーク・アタフ。タのプロバティを開き、 [ インス IPv6 を利用できるようにしています。 タ ( いわゆる fxp0) の、、ローカルエリア接続 " に対し、 図 30 では、 lntel ー 82558 べースのネットワーク・アタフ アタフ。タでも使用できました ) 。 ないと書かれています ( 私は 802.11b のネットワーク・ 図 34 IPv6 プロトコル・スタックのインストールが完了 ( 再 起動は不要 ) ローカルエリア続のプロバティ - 。蜀露朝暑蠎鬚、 全般ー チェックマクがオンになっているコンポーネントがこの接続で使用されて ( , はす 0 : 構成 0 い引 82558 ー b ed lntegrated Et げ with Wake on LAN* 続の方法 : MicrosoftIPv6 P 「 0 c 引 、インターネットプロトコル (TOP/IP) マ ま Mlcrosoft ネットワーり用ファイルとプリンタ共有 @l 團 Microsoft ネットワ・一ク用りライアント プロテ , 印。ー マ続時にタスクバーにアイコンを表示する interconnected ーれ′ k ま Pr0t000 い h 飜 0 ⅵ s com れ untc 沁 n ら 0 「 OSS diverse TOP/IP v s 朝 16. 計旧冊乂ト ge 冊慥 t い嫐 s 朝 1 ofthe internet 説明 朝朝Ⅱ 0 検素山お皿入、り当雇歴 ; 朝 0 図 36 IPv6 じゃないので、踊らないかめ 図 35 かめが桶る ! ノん ww. 炻 m 釭にレ プしました。多くのコミュニティでメーリングリストが運 IPv6 に関する情報源を日本と海外に分けてリストアッ りません ( 図 36 ) 。 を見ることができます。 IPv4 で接続した場合、かめは踊 plorer で開くと IPv6 で接続され、「踊るかめ」 ( 図 35 ) KAME プロジェクトの Web ページを lnternet Ex- て、接続ネットワークが IPv6 に対応している場合には、 lnternet Explorer も IPv6 に対応します。したがっ Pr0Ject is a joint e 幵 0 杙 ofseuen companies in Japan ifyou g な to ド新日・ロ . yo い ! ab にわ、発内 ! ! 旦 ! 匹 : ー區皇 KAME Project ー -- -- ・一 v6 関連の情報源 55

現在の状態は、、標準化への提唱 " である。 2001 年 1 月に 公開された。 汎用識別子とユーサー間シグナリングは、 ATM ネット ワークにおけるエンドッーエンドの利用者間で識別子を交 換するための樹冓である。前者は Q. 2941.1 、 Q. 2941.2 、 Q. 2931 、 Q. 2971 、後者は Q. 2957 、 Q. 2971 Annex D 、 Q. 2931 、 Q. 2971 て規定されている。いずれも網の接続や 障害に関する情報をはしめ、網管理に必要なさまざまな情 報を伝達することができる。汎用識別子とユーサー間シグ ナリングは、 B-ISDN ( 広帯域 ISDN) でのシグナリング では同等の機能を提供するが、目的が異なるため処理ガ去 などは同一ではない。 RFC3033 では、これらのシグナリングオ冓を用いて、 IP アドレス、 MPLS VCID 、 RSVP メッセージなどを 通知するためのフレームワークとメッセージ・フォーマッ トを規定している。 RFC3034 Use of Label Switching on Frame Relay Net- works Specification フレームリレーを用いたラベル・スイッチング士様 PS. 、 A. Conta 他 フレームリレー・ネットワークを利用して MPLS ネッ トワークを構築するための各種イ士様を定義している。現在 の状態は、、標準化への提唱 " である。 2001 年 1 月に公開 された。 RFC3031 て提案されている MPLS のアーキテクチャ には、利用可能な下位層の媒体としてフレームリレーカ まれている。 RFC3034 は、 MPLS におけるフレームリ レーの利用について RFC3031 よりも言岩田に検討してい る。 RFC3031 でも MPLS におけるフレームリレーの扱 いは触れられているが、あくまでフレームリレーも視野に 入れているという程度にとどまり、フレームリレー特有の 処理については規定されていない。 RFC3034 では、フレームリレー・ネットワークを利 用して MPLS ネットワークを構築する際に必喫な各種機 能のマッピンク 1 係を規定している。おもにフレームリレ ・ネットワークで利用される識別子である DLCI から MPLS ラベルへのマッピングや、 LSP の確立などか規定 されている。 RFC3035 MPLS using LDP and ATM VC Switching UNIX MAGAZINE 2001.5 日 FC ダイジェストー・ LDP および ATM VC スイッチングを用いた MPLS PS. 、 B. Davie 他 ATM ルータにおける MPLS 処理のイ士様を提案してい る。現在の状態は、、標準化への提唱 " である。 2001 年 1 月に公開された。 前述の MPLS のアーキテクチャ ( RFC3031 ) には、利 用可能なード位層の媒体として ATM も含まれている。しか しこれもフレームリレーと同程度の扱いであり、 ATM の セルに対するラベルの付加や、ラベルの配布の言岩田につい ては十分に述べられていない。 RFC3035 は、 MPLS に おける ATM の利用について RFC3031 よりも詳細に検 討している。 RFC3035 では MPLS の ATM サポートに焦点を当て て言磊義しているものの、やはりラベル配布や各要素技術の 詳細にまで言及しているわけではない。とはいえ、 MPLS の ATM サポートのフレームワークとなる議論がまとめ られているので、 MPLS における ATM サポートの概要 を知るのに役立つだろう。 RFC3036 LDP Specification LDP 士様 PS. 、 L. Andersson 他 MPLS のシグナリング・プロトコルである LDP (La- bel Distribution Protocol) の仕様を提案している。現 在の状態は、、標準化への提唱 " である。 2001 年 1 月に公 開された。 RFC3031 て提案されている MPLS のアーキテクチャ は、 FEC (Forwarding Equivalence Class : 同一転送 クラス ) にマッピングされたラベルを配布する、、ラベル配 布フロトコル " と、配布されたラベルマッピングを用いて バケットを転送する、、バケット転送オ対冓 " に分けられる。 RFC3036 では、ラベル配布プロトコルの一種として LDP を提案している。 LDP は第 3 層の経路制御にも とづきラベルマッピングを配布するためのプロトコルであ る。 RFC3036 では、 LDP のさまざまな処理の言田につ いて解説し、重メッセージを定義している。 なお、、、 LDP" は具ー勺なプロトコルを孑尉 - 言葉である が、、、ラベル配布フロトコル (label distribution proto- col 厂はプロトコルのカテゴリーを抽象的に示すための言 葉として用いられているケースも少なくない。 MPLS に 159

表 6 36 34 28 27 26 24 19 活発に活動している IETF 分科会覧 ( 1 ) 過去 6 カ月間 ( 2000 / 7 / 16 ~ 2001 / 1 / 15 ) mpls: Multiprotocol Label Switching pkix: Public-Key lnfrastruc- ture ( X. 509 ) avt: Audio/Video Transport idn: lnternationalized Do- main 介ぐ a Ⅱ dnsext: DNS Extensions smime: S/MIME Mail Se- curity sigtran: Signaling Transport sip Session lnitiation Pro- t 0C01 beep: Blocks ExtensibIe Ex- change motocol dhc: Dynamic Host Configu- ration rpp: lnternet Printing Prot0- col 17 16 14 13 11 過去 3 カ月間 ( 2000 / 10 / 16 ~ 2001 / 1 / 15 ) sip. Session lnitiation Pro- tocol smime: S/MIME Mail Se- curity mpls: Multiprotocol Label S wit ching sigtran. Signaling Transport dnsext: DNS Extensions idn: lnternationalized DO- main ↑、 a Ⅱ le pkix: Public-Key lnfrastruc- ture ( X. 509 ) avt: Audio/Video Transport ospf: Open Shortest Path First IGP 同数のう斗会が多数のため割愛 5 4 3 過去 1 カ月間 ( 2000 / 12 / 16 ~ 2001 / 1 / 15 ) beep. Blocks ExtensibIe Ex- change Protocol secsh: Secure Shell idn: lnternationalized Do- main Name ips: IP Storage sming: Next Generation Structure of Management ln- formation syslog: Security lssues in Network Event Logging 同数のう斗会が多数のため割愛 SECSH 分科会 期間中には、 SECSH に関連する個人名義のインターネッ ーネット・ドラフトを簡単に紹介する。なお、今回の対象 対象とした期間中に SECSH 分利会が公開したインタ 活動内容としている。 議論しており、 SSH プロトコルの標準化の推進をおもな 的としている。現在では SSH プロトコルに焦点を当てて 全 ( セキュア ) な通信を提供する技術の開発と標準化を目 SECSH う斗会はセキュリティ・エリアの分科会で、安 SheII) う斗会を紹介することにした。 げたう斗会の除外などを考慮した結果、 SECSH (Secure されたインターネット・ドラフトの本数やすでにとりあ 今回は対象期間が 3 カ月間のため、この期間中に公開 SSH プロトコルのアーキテクチャを提案し、 SSH プロ SSH プロトコル・アーキテクチャ SSH Protocol Architecture [draft-ietf-secsh-architecture-07 txt] ト・ドラフトは公開されなかった。 178 トコルに里する文書囎羊で使われる用語を定義している。 [draft-ietf-secsh-connect-09 txt] SSH Connection Protocol SSH コネクション・プロトコル SSH コネクション・プロトコルを提案している。この プロトコルは、安全なログイン、異なるマシン上でのコマ ンドの隔実行、 TCP/IP コネクションの転送、 X11 コ ネクションの転送などの機能を提供する。 [draft-ietf-secsh-filexfer-OO txt] SSH File Transfer Protocol SSH ファイル車医プロトコル SSH ファイル転送フ。ロトコルを提案している。このプ ロトコルは、暗号化されたデータストリーム上でのファイ ル転送機能を提供する。 [draft-ietf-secsh-transport-09. txt] SSH Transport Layer Protocol SSH トランスポート層プロトコル UNIX MAGAZINE 2001.5

表 2 今月扱った RFC ( 続き ) DNS RFC3071 RTP 鏈 RFC3047 TCP RFC3042 DHCP RFC3062 RFC 3045 LDAP RFC 3081 RFC 3080 BEEP 鏈 RFC3074 RFC3046 DNS ( RFC1591 ) およびドメインの不頁に関する意見 ITU-T 勧告 G. 722.1 用の RTP ペイロード形式 送信匍韵による TCP の損失復旧機能の強化 LDAP の刻長パスワード変甦巣作 LDAP ルート DSE におけるべンダー情報の褓内 BEEP コアプロトコルの TCP へのマッピング BEEP のコアプロトコル DHC 負荷う靖攵アルゴリズム DHCP 中継工ージェント情報オプション セキュリティ RFC3029 インターネット X. 509 公開鍵インフラストラクチャ : DVCS プロトコル RFC3039 インターネット X. 509 公巒建インフラストラクチャにおける認斉み証明囓フ。ロファイル RFC3058 CMS での IDEA 暗号化アルゴリズムの使用 電子メール RFC3028 電子メール・フィルタリング言語「 Sieve 」 MIME RFC3023 XML メディアタイプ WW 、 RFC3040 インターネットでの Web の複製およびキャッシュのう頁 URI/URL TN3270E サービス位置およびサービス・バランシング オプジェクト識別子の URN 名前空間 ISSN-URN 名前空間での ISSN の URN としての使用 Network SoIutions の PIN : イ固 . 人や糸設用の URN 名前空間 RFC3043 RFC3044 RFC3061 SLP RFC3049 RFC3059 インターネットー RFC3050 RFC3054 RFC3055 RFC 3064 そ也 RFC3018 RFC3057 ISDN Q. 921 ューザー芯レイヤ UMSP のイ土様 MGCP て利用される CAS パッケージ PINT サーピス・アーキテクチャ用 MIB Megaco IP 電話メディアゲートウェイ・アプリケー SIP 用 CGI SLP 用の属リストの孑虧長 を定義している。現在の状態は、、標準化へ窈是唱 " である。 IUA (ISDN Q. 921 ユーザー通芯 ) レイヤプロトコル PS. 、 K Morneault 他 ISDN Q. 921 ユーサーレイヤ RFC3057 ISDN Q. 921-User Adaptation Layer き、 RFC3018 では TCP と UDP をとりあげている。 データ交換には各種トランスポート層サービスを使用で 176 ションのフ。ロファイル 2001 年 2 月に公開された。 IUA レイヤプロトコルは、 IP 上で SCTP ( ストリーム 制御伝送プロトコル ) を使用して ISDN Q. 921 ューサー メッセージを j するためのプロトコルである。 Q. 921 は ISDN の D チャネル ( ューサー・メッセー ジ酉占逶などに使われる ) に関する ITU 規格で、 Q. 921 ユ ーサーとは Q. 921 を利用する上位レイヤのプロトコルを UNIX MAGAZINE 2001.5

層に該当する枠組みとして捉えることができる。これまで は、各アプリケーションがセッション層やプレゼンテー ション層までを独自に管理することが多かった。しかし BEEP を用いることで、各アプリケーションはセッショ ン層やプレゼンテーション層の独自プロトコルを策定する 必要がなくなり、アプリケーション間通信のセッション の管理や符号化手法の統一か容易にできるようになる。 BEEP は、アプリケーションによって交換されるメッ セージの符号化形式を規定しているコアプロトコルと、ア プリケーション間の接続を実現するコネクションの 2 つ の部分から構成されている。 BEEP のコアプロトコル部 はアプリケーション間で用いられる実際のコネクション の実装には依存しないため、アプリケーション間のコネク ションを提供するさまざまな実装に適用できる構造となっ ている。 RFC3080 では、おもに前者のコアプロトコル部のイ兼 を提案している。後者については、 RFC3081 で BEEP コアプロトコルを TCP に適用した例について言龠してい るので、あわせて読むとよいだろう。 BEEP の特徴を以下に示す。 ・コネクション上でのイ課的な、、チャネル " の導入 ・テキスト・メッセージとバイナリ・メッセージのサポート 単一のトランスポート・コネクション上での仮想的な複 数チャネルのサポート RFC3081 Mapping the BEEP Core onto TCP BEEP コアプロトコルの TCP へのマッピンク PS. 、 M. Rose BEEP コアプロトコルの TCP へのマッピングを提案 している。現在の状態は、標準化へ窈是唱 " である。 2001 年 3 月に公開された。 RFC3080 で提案されている BEEP のコアプロトコル を TCP に適用した例について言籀侖している。おもな内容 は、 BEEP を TCP に適用した場合のセッション管理方 法とメッセージ交換ガ去である。 LDAP 関連 RFC3045 Storing Vendorlnformation in the LDAP root DSE LDAP ルート DSE におけるべンダー情報の格納 UNIX MAGAZINE 2001.5 RFC ダイジェストー・ fo. 、、 M. Meredith 169 ス外の認証情報の更新に使用する。 LDAP クライアント スワード変更要求 " を規定し、ディレクトリ・データベー RFC3062 の欟冓では、 LDAP の拡張要求として、、パ 定している。 リ・データベース外の言旧青報も同時に更新する手法を規 RFC3062 では、 LDAP のパスワード変更でディレクト ース外の認証清報は更新されないという問題が発生する。 更などの操作をおこなっても、ディレクトリ・データベ の場合、ディレクトリ・データベース内でパスワード変 ス外の認証清報を組み合わせて利用することが多い。こ な認証を必要とする場合は、ディレクトリ・データベー データベース内に存在していると仮定する。しかし高度 LDAP を利用した認証では、認証情幸師ゞディレクトリ・ へ窈是唱 " として 2001 年 2 月に公開された。 利用する際のパスワード変更法を規定している。、、標準化 LDAP 認証機構とそれ以外の認証機構を組み合わせて PS. 、 K. Zeilenga LDAP の広張パスワード変更操イ乍 tion RFC3062 LDAP Password Modify Extended Opera- 通知や検出に使用してはならないとされる。 報は表示や青幸財是供を目的とするもので、サーバー持生の のバージョンを通知する。これらの属性中に保持される情 ダー名、後者は現在インストールしているべンダーコード DSE 内で使用でき、前者は当該 LDAP サーバーのべン ている。 RFC3045 で定義している LDAP 属性はルート ト DSE からサーバーの独自データを検出すると定義され RFC2251 の 3.4 節では、 LDAP クライアントはルー ・ vendorVersion ・ veIIdorName 以下の 2 不頁を規定している。 情報をサーバーで扱うための DSE 用 LDAP 属性として することになっている。 RFC3045 では、べンダーの独自 義されているデータを取得する際に、ルート DSE を検索 LDAP では、クライアントがサーバーごとに独自に定 る。、、広報 " として 2001 年 1 月に公開された。 工ントリ ) に使用される LDAPWI 生を 2 不頁定義してい べンダーの独自情轤凾知用のルート DSE (DSA 独自

能匪か高くなる。送信制約アルゴリズムは、 TCP ; 尺通 知 (SACK) 樹冓と一緒でも、単独でも使用できる。 DHCP 関連 RFC3046 DHCP Relay Agent lnformation Option DHCP 中継工ージェント情報オプション PS. 、 M. Patrick DHCP (Dynamic Host Configuration Protocol) バケットに挿入される中継工ージェント情報オプション の拡張を定義している。現在の状態は、、標準化への提唱 " である。 2001 年 1 月に公開された。 描丘の一殳向け高速インターネット技術では LAN イン ターフェイスによる接続形態が用いら DHCP を利用 してユーサー側機器のアドレスを設定する場合がある。し かし、 DHCP はこのような大規模な利用においてセキュ リテイや対規模性能などに関する間題も多い。 そこで RFC3046 では、 RFC2132 を孑劇長して中継工 ージェント情報オプションを規定している。このオプシ ョンは DHCP の対規模性能を高めることを目的としてお り、中継工ージェントが DHCP メッセージを中継する際 に、 DHCP サーバーに自分の情報を伝達するために利用 される。 DHCP サーバーはこの情報に応じて、提供する パラメータ ( IP アドレスなど ) を切り替えることが可能と なる。中継オプションは中継サーバーと DHCP サーバー 間でのみ利用され、ユーサー側には蔽されるため、下位 互換生も系旧寺される仕組みになっている。 RFC3074 DHC Load Balancing Algorithm DHC 負荷分散アルゴリスム PS. 、 B. Vo レ他 複数の DHCP サーバーを使って負荷分散を実現する アルゴリズムを規定している。、、標準化への提唱 " として 2001 年 2 月に公開された。 現在、 DHCP は IP アドレスの重加勺設定の手段として ひろく利用されている。しかし DHCP では、 1 セグメン ト上のサーバーがつねに 1 台に限られるため、リクエスト か増加するとサーバーの負荷が非常に高くなってしまう。 RFC3074 ではこの問題を鮹夬するため、複数の DHCP サーバーを利用した負荷分散の : 滝見力法を定義している。 効率のよい負荷分散を実現するためには、複数のサー バーがクライアントをほは伺数すっ受け持っことか望まし 168 い。 RFC3074 で定義しているアルゴリズムでは、クライ アントの MAC アドレスのハッシュ値を利用してこれを 実現する。この方式では、任意の MAC アドレスから生 成されるノ、ツシュ値の集合を分割し、各サーバーに割り当 てる。サーバーは、自分に割り当てられたハッシュ値に対 応する MAC アドレスにのみサーピスを提供する。 このアルゴリズムを利用しているネットワークでは、サ ーバーの故障時に DHCP サービスを受けられないホス トが発生するため、ハッシュ値か割り当てられていない MAC アドレスからのリクエストに対して一 -- 一定時間待った あとで応答を返す仕組みも規定されている。これにより、 サーバーが旅した場合でもサーピスを継続して提供でき る。 RFC3074 ではハッシュ値を求める式も明確に規定し ており、異なる実装間での相々漣用性もイ正している。ま た、この方式は既存の DHCP クライアントを変更せすに 採用できる。 BEEP 関連 RFC3080 The Blocks Extensible Exchange ProtocoI Core BEEP のコアプロトコル PS. 、 M. Rose アプリケーション間通信プロトコルの構築を容易にする ための汎用的なフレームワークである BEEP のコアプロ トコルを提案している。現在の状態は、、標準化への提唱 " である。 2001 年 3 月に公開された。 インターネット上ではさまざまなアプリケーションが 用いられており、各アプリケーションごとに独自の通信プ ロトコルが必要な場合もある。しかし、アプリケーション ごとにプロトコルを一から作りなおすのは労力の浪費であ る。そのためー殳には、すでに実装されている種々のプロ トコルの上にアプリケーション独自のプロトコルを実装す ることが多い。ところがこれまでの経験から、コネクショ ン指向 / 非同期型のプロトコルの需要が高いことが分かっ てきた そこで RFC3080 では、コネクション指向 / 非同期型の アプリケーション間プロトコルを容易に構築できるフレー ムワークとして BEEP を提案している。 BEEP は OSI の 7 層モデルにおけるセッション層、プレゼンテーション UNIX MAGAZINE 2001.5

的としたものではない。 RFC3050 では、 HTTP と SIP のそれぞれにおける CGI のモデルを示し、その相違点、 SIP における CGI の概要と詳細、用言韶 ) 定義について述べている。 RFC3054 Megaco 旧 Phone Media Gateway Applica- tion Profile Megaco 旧舌メディアゲートウェイ・アプリケーショ ンのプロファイル fo. 、 P. Blatherwick 他 インターネット電話や同種の機器用の Megaco/H. 248 プロトコルのアプリケーションである Megaco IP 電話 メディア・ゲートウェイを定義している。 ) 舞 lå" として 2001 年 1 月に公開された。 Megaco IP 電話メディア・ゲートウェイは Megaco/ H. 248 プロトコルが制御するメディア・ゲートウェイで あり、メディアゲートウェイ・コントローラ内にアプリ ケーション制餌牋能をもつ。 RFC3054 では、このようなエンドユーサー用機器で高 度な共通操作生と設引・効率性を得るための一貫したアーキ テクチャによるアフローチ、端末とパッケージの組合せ、 プロトコルのフロファイルについて言当している。 RFC3055 Management lnformation Base for the PINT Services Architecture 円 NT サービス・アーキテクチャ用 M 旧 PS. 、 M. Krishnaswamy 他 PINT (PSTN/Internet INTerworking) サーヒ、ス・ アーキテクチャ用の MIB を規定している。現在の状態は 、、標準化への提唱 " である。 2001 年 2 月に公開された。 PINT サービスとは、インターネットを用いて PSTN ( 一般公衆電話網 ) 通信を扱うサービスおよびアプリケー ション君 ) 総称である。 PINT のアーキテクチャ・モデル は RFC2458 で説明されている。 RFC3055 では、 PINT サービスを扱うための MIB オ プジェクトを規定している。 RFC3064 MGCP CAS Packages MGCP で禾」用される CAS パッケージ fo. 、 B. Foster MGCP (Media Gateway Control Protocol) でチ ャネルごとのシグナリングを受け持っ CAS (Channel 174 Associated Signaling) を規定している。、、広報 " として 2001 年 2 月に公開された。 MGCP ( RFC2705 ) は VoIP (Voice over (P) ゲー トウェイを制御するためのプロトコルである。 MGCP で はチャネルのシグナリングを CAS と呼はれる機構で実現 しているか : シグナリング手法はメディアによって異なる ため、多数のメディアを統一的に扱うには CAS にさまざ まなシグナリング機能が必要となる。 単一の CAS でこれらをすべて実現するのは効率が悪 いため、 CAS を、℃ AS パッケージ " と呼はれる単位に 分割して各メディアに対応させる構造カ甘采用されている。 MGCP の利用者は、通イ訓に必要な CAS パッケージを 尺することで目的とするシグナリングを実現できる。 RFC3064 は、 CAS ノヾッケージのうち、 MS 、 DT 、 BL 、 DO 、 MD 、 MO の 6 つを扱っている。各パッケー ジが対応するシグナリンクを以下に示す。 O パッケージ : FGD オペレータ・サービス MD ノヾッケージ : FGD-EANA および FGD-EAIN ジ : DTMF/DP 基本 PBX ージ : DTMF/DP ( 基本 PBX を除く ) MS ノ、ツケーン : PBX DID/DOD BL ノヾッケー DT ノヾッケ ・ DO ノヾッケーゾ : アナログ FXO UNIX MAGAZINE 2001.5 達が用いられることが多い。 TCP/IP などで確立されたチャネノい E でのメッセージ伝 結合て言 t 算するモデルが主充であり、計算機間の通信には た分散計算などが活発におこなわれている。現在は粗な る。去も匠は、インターネット上で複数の計算機を利用し インターネットは膨大な数の計算機から構成されてい ている。、、実馬剱勺 " として 2000 年 12 月に公開された。 ルである UMSP ( 統合メモリ空間プロトコル ) を提案し 遠隔ノードのメモリを直接アクセスするためのプロトコ Exp. 、 A. Bogdanov UMSP の仕様 tion RFC3018 Unified Memory Space Protocol Specifica- その他 シグナルの処理ガ去を詳細に規定している。 RFC3064 は上記の各パッケージについて、イベントや

RFC ダイジェストー朝 表 1 今月扱った RFC インターネット RFC3026 RFC3066 QoS 車 RFC3052 MPLS 勵車 RFC3031 RFC3032 RFC3033 RFC3034 RFC3035 RFC3036 RFC3037 RFC3038 RFC3063 NAT RFC2993 RFC3022 RFC3027 IPv4 RFC3021 RFC3051 RFC3019 RFC3041 RFC3053 RFC3056 IPv6 ENUM についての IETF/ISOC への ; 糸各 言蕋筬別用のタグ サービス管理アーキテクチャに関する論点と概観 MPLS のアーキテクチャ MPLS ラベルスタックの符号化 Q. 2941 汎用識別イ・の情報フィールドとプロトコル識別子および Q. 2957 ューサー間シグナ リングにおける IP 情報の割当て フレームリレーを用いたラベル・スイッチングのイ士様 LDP および ATM VC スイッチングを用いた MPLS LDP の f±, 様 LDP の適用性 LDP による ATM リンク上での VCID 通知 MPLS ル、・ - ーフ方止オ冓 NAT のアーキテクチャに関する言侖 伝糸勺な IP ネットワーク・アドレス変換 IP ネットワーク・アドレス変換のプロトコルへの景 IPv4 のポイント・ツー・ポイント孑売における 31 ビット長プレフィックスの利用 IPv6 におけるステートレス自動設定財冓のプライバシー長 IPv6 の MLD プロトコル用 MIB ITU-T V. 44 バケット方式を使用した IP ペイロード日引 IPv4 ネットワークを経由した IPv6 ドメイン間接続 IPv6 トンネルプローカ 移本 IP RFC3024 移重川本 IP 用逆トンネリング ( 改訒 1 測 RFC3025 べンダーパ目織独自の移重川本 IP 長 マルチキャスト RFC3048 1 対多のバルクデータ中幻逶用の咼信頼マルチキャスト・ RFC3065 BGP における自律システム連合 VLAN RFC3069 効率的な IP アドレス割当てのための VLAN 集約 トンネリンク RFC3070 フレームリレーー E の L2TP UMSP の目的は遠隔言 t 算機のメモリ空間を直接扱うこ とで、セッション層とプレゼンテーション層にまたがる ネットワーク接繒旨向プロトコルである。専用プロセッサ をもっ単純なテパイスから一ヨ勺なコンヒュータやコンピ ータ群までの、さまざまな不頁のシステムで実装できる ように言気されている。 具一勺には、仮想的に 128 ビット長のメモリ空間を構 成し、その上に複数の計算機のメモリ領域をマップする。 UNIX MAGAZINE 2001.5 トランスポート構築プロック を実行するシステムや、オペレーティング・システムをも にもとづくシステムを想定しているが、プロセッサコード ポート対象として仮想コードを実行する仮想機器 (VM) せすに使えるように言されている。 UMSP は主要なサ るだけで、そのメモリの内容かま際にどこにあるかを気に 128 ビットのアドレスを指定して、メモリをアクセス " す UMSP を用いるアプリケーション / ユーサーは、たんに たない叫屯なテパイスでも使用可能である。 175

「すべての携帯電言劼ゞ IP をしゃべるようになったらどう なるか」 「アジアや、アフリカなど、これからインターネットか成 長する或がどんどんつながったらどうなるか」 と考えていくと、 IPv4 では限界を感しすにはいられませ ん。また、 NAT はインターネットでもっとも重視されて いる、 ・ 1 対 1 の通信モデル に反しています。 Napster や Gnutella などの peer-to- peer 通信の爆発的な普及を考えると、 IP アドレスに缶齣 がある IPv4 では幸せな生活は送れないでしよう。 日本でも、グローバルな固定 IP アドレスはそうそう簡 単にはもらえません。描丘整いつつある安価な常日妾続サ ーヒ、スに加入しても、ほとんどの場合は DHCP などによ る重加勺なアドレスの割当てしか受けられません。 「グローバルな固定アドレスをください」 と申し込んでも、割り当てられるのは 1 個だけだったり、 8 個 ( / 28 ) もらえても割高だったりと、なかなか思うよ うにはいきません。そんな体験を通して、アドレスの扱い に不岡を感じたことがある人も多いのではないでしようか ( ただし、本質的なドロ地は違うところにあります ) 。 IPv6 では、アドレス空間が 128 ビットに拡張されて います。つまり約 3.4 x 1038 個、より正確にいえば、 340282366920938463463374607431768211456 という、、とんでもない数 " になります。 さらに、アドレスの増加にともなって経路管理の負担が 増えないように、糸各の集繃生を考慮した構造になってい ます。アドレスのステートレスな設定など、管理者の負担 を減らす工夫もされています。 IPv6 は、アドレスの拡張以外に次のような機能を標準 でもっています。 ・セキュリティ機能の強化 ・移本通信 ・マルチキャスト つまり、 IPv6 は、 IPv4 の矢可斤を改善し、長所は継承 するという姿勢で研究開発されたプロトコルといえます。 IPv4 ヘッダ ( 図 5 ) と IPv6 ヘッダ ( 図 6 ) をくらべてみ UNIX MAGAZINE 2001.5 ましよう。一目瞭然ですが、不要な部分か削除されてシン プルな構造になっています。 このように素晴らしい IPv6 ですが、 IPv4 から IPv6 への移行にかかるコストが大きいため、移行は進んではい るもののまだまだーイ勺というところまではいっていない のカ躾情です。 移行の原動力となるのは、皆さんの IPv6 を利用したい というニーズです。この特集をとおして、皆さんが IPv6 を丘に感して使い始め、さらには IPv6 普及への牽引力 になっていただけれはと思います。 IPv6 で遊ぶには、当然のことながら IPv6 対応のノー ドが必要です。 、、ノード " という用語力咄てきましたが、この特集では以 下のように使い分けることにします。 IPv6 て涌信する機器 IPv6 バケットのルーティングをおこなう機器 ・ホスト ルータ以タ ) すべてのノード FreeBSD や NetBSD 、 OpenBSD などの BSD 系 のプラットホームでは、 IPv6 プロトコル・スタックの 研究開発プロジェクト KAME が開発したコードカ陬り 込まれています。 FreeBSD では RELEASE-4.0 以降、 NetBSD では RELEASE-I. 5 以降、 OpenBSD では RELEASE-2.7 以降のノヾージョンはデフォルトで IPv6 に対応しています。 Windows NT 4.0 や 2000 ( NT5.0 ) では、 Microsoft Research が開発、公開している IPv6 プロトコル・スタッ クを使えば IPv6 カリ用できます。 Linux にも IPv6 プロトコル・スタックがあり、その 元成度を高めるための USAGI プロジェクト 7 が進められ ています。 Li Ⅲ派の人はぜひ使ってみましよう。 各ネットワーク・べンダーも IPv6 のサポートを表明し ており、 IPv6 を使うための素地は整ってきています。 伊 v6 で遊ぶには 7 http://www.Iinux-ipv6.org/ 39

RFC ダイジェストー・ 表 3 1 月 15 日までに公開されたインターネット・ドラフトの 出典別分類 指す。 UNIX MAGAZINE 2001.5 ・ 2001 年 2 月 15 日を起点とした集言結果 ・ 2001 年 1 月 15 日を起点とした集計結果 きたが、今回は例タ勺に過去 3 カ月間を対象として、 てまとめる。これまでは過去 1 カ月間を対象として扱って 日のあいだに公開されたインターネット・ドラフトについ 今回はおもに 2000 年 12 月 16 日から 2001 年 3 月 15 インターネット・ドラフト公開速報 今回扱った RFC を表 1 ~ 2 にまとめる。 の 3 不頁のシグナリングをサポートしている。 ・バックアッフ。用の D チャネルを備えた NFAS ・ NFAS ( 非ファシリティ関連シグナリング ) ・ FAS ( ファシリティ ( 機器 ) 関連シグナリンクつ IUA レイヤプロトコルでは、 ルである。 Q. 921 ューザー・メッセージの酉当こ適した j 曲芯モジュー IUA レイヤプロトコルは上記の基準を満たし、 ISDN ・ SG と MGC 間の重加勺連合の管理 ・ SG および MGC 上のレイヤ管理モジュール間の通信 ・ Q. 921 および Q. 931 境界基本要素の伝送 いる必要がある。 ISDN のシグナル配送樹冓は以下の要素をサポートして ルが IUA レイヤプロトコルである。 しなければならない。このために定義された i モジュー のアーキテクチャを援用してシグナリンク冲云送をサポート ザー・メッセージ酉占医が必喫である。そのため、 RFC2719 ラ ) 間でのシグナリンク酒当ムつまり ISDN Q. 921 ユー ウェイ ) と MGC ( メディアゲートウェイ・コントロー ISDN は SCN の一種で、 SG ( シグナリング・ゲート SCTP を j 芯させるためのモジュールを使う。 トコルに加え、各アプリケーション・プロトコルごとに る。このアーキテクチャは IP 、 SCTP の 2 不頁のプロ におけるシグナリンク転送用アーキテクチャを定義してい RFC2719 は、 SCN ( スイッチ型回路ネットワーク ) 出典 IETF 分科会 個人名義 数の合計 過去 6 カ月ミ琺 3 カ月過去 1 カ月 875 1 , 024 1 , 899 473 588 1 , 061 96 105 201 表 4 2 月 15 日までに公開されたインターネット・ドラフトの 出典別分類 出典 IETF ろ斗会 個人名義 公開数の合計 過去 6 カ月ミ琺 3 カ月過去 1 カ月 809 952 1 , 761 465 561 1 , 026 149 159 308 表 5 3 月 15 日までに公開されたインターネット・ドラフトの 出典別分類 出典 IETF 分科会 個人名義 数の合計 を紹介する。 を起点として、 過去 6 カ月ミ 3 カ月過去 1 カ月 1 052 1 , 224 2 , 276 576 623 1 , 199 331 359 690 ・ 2001 年 3 月 15 日を起点とした集言結果 、、過去 1 カ月 " 、、過去 3 カ月 " 、、過去 6 カ 2001 年 1 月 15 日、 2 月 15 日、 3 月 15 日のそれぞれ 177 された本数を集計した。その結果を表 9 ~ 14 に示す。 15 日、 2 月 15 日、 3 月 15 日を起点とした期間中に公開 IETF の全分科会をエリアごとに分類し、 2001 年 1 月 IETF 工リア / 分科会別の公開状況 それぞれ表 6 ~ 8 に示す。 ついて、公開数の上位から 10 位程度まで集計した結果を 6 カ月 " の期間に公開されたインターネット・ドラフトに 15 日を起点として、、、過去 1 カ月 " 、、過去 3 カ月 " 、、過去 さきほどと同様に 2001 年 1 月 15 日、 2 月 15 日、 3 月 活動が活発な分科会 ターネット・ドラフトが公開された。 3 月 15 日の期間には、これを大きく上回る 690 本のイン であった。しかし、今回対象とした 2001 年 2 月 16 日 ~ 開されたインターネット・ドラフトの数は最大でも 594 本 ト・ドラフト公開速報を開始して以来、各対象期間中に公 と、それらの出典別分類を表 3 ~ 5 に示す。インターネッ 月 " の期間に公開されたインターネット・ドラフトの総数