IPv4 関連 Ⅲネットワーク・アドレス変換のプロトコルへの影響 fo. 、 M. Holdrege 他 RFC3021 Using 31-Bit Prefixes on IPv4 P0int-t0- NAT の利用により通イ訂カ作に支章をきたすアプリケー Point Links ションについてまとめている。、、広報 " として 2001 年 1 旧 v4 のホイント・ツー・ポイント接続における 31 ビッ 月に公開された。 ト長プレフィックスの利用 NAT の利用により動作しなくなるアプリケーション PS. 、 A. Retana 他 や、 NAT と併用した場合にアプリケーション層ゲートウ IPv4 のアドレス空間を効率よく利用するために、ポイ ェイを利用しなければ満足な動作をしないアプリケーショ ント・ツー・ポイント接続において 31 ピット長フレフィ ンか、存在する。 RFC3027 は、このようなアプリケーショ ックスを用いる手法を規定している。現在の状態は、、標準 ンの一イ難勺な特徴を述べ、 NAT を利用するとまったく動 化ー、、の提唱 " である。 2000 年 12 月に公開された。 作しないもの、アプリケーション層ゲートウェイを利用す IPv4 のアドレスはすでにオ曷しかけている。対策とし ることで動作するもの、 NAT の利用を想定して言 fr され ては NAT の利用や IPv6 への移行か挙げられるが、それ ているものについて、具ー列を挙げて角見している。 らか不可能な場合も多い。このような場合は極力、既存の ーヨ殳に、以下のような特徴をもつアプリケーションは途 IPv4 のアドレス空間を効率よく利用しなくてはならない。 中に NAT 樹冓が入ると動作しない。 そこで、 RFC3021 は 2 台のノードのみからなるホイン ト・ツー・ポイント接続ーヒで 31 ビット長プレフィックス ・ペイロード内に IP アドレスに関する・にをイ尉寺する。 を利用する手法を規定している。 複数のセッションを利用する。 従来の方式で扱える IPv4 のプレフィックスは、最高で ・ピアツーピア・モデル。 30 ピット長である。これは、 IPv4 ではホスト部のビット ・つねに同一のアドレスを利用する必要がある。 がすべて 0 のアドレスをネットワーク・アドレス、ホス ・多数のグローバル・アドレスを必要とする。 ト部のビットがすべて 1 のアドレスをネットワーク指定 上言び丿汐 ) アプリケーションでも、 IP'S ケットのフラ プロードキャスト・アドレスとして規定しているため、 31 グメンテーションが発生すると NAT を利用できない場合 ビット長プレフィックスを利用するとホスト用のアドレス がある。このような特徴をもつものとしては、 がなくなってしまうからである。 RFC3021 では、この問題を解決するための手段とし ・ IPsec および IKE を利用するアプリケーション て、プレフィックスが 31 ピットの場合に限り、ホスト部 ・ Kerberos 4 / 5 を利用するアプリケーション ・ X ウインドウ・システムおよび xterm/telnet のビットがすべて 1 や 0 でもホスト用のアドレスとして 扱うことを提案している。これにより、従来ポイントツー ・ rsh/rlogin ポイント・リンクでは最低 4 つのアドレスか消費されてい などか挙げられる。 たのが、 2 つのアドレスですむようになる。 アプリケーション層ゲートウェイを利用することにより 副作用としてネットワーク指定プロードキャストを利用 NAT の景グを回避できるものには、 する通信か不可能となるが、プレフィックスを含めすべて ・ FTP のビットが 1 である限定プロードキャスト・アドレスに ・ RSVP を利用するアプリケーション より代用できるため問題はない。 ・ SMTP を利用するアプリケーション RFC3051 Payload Compression Using ITU-T V. 44 ・ SIP を利用するアプリケーション Packet Method ・ RealAudio ITU-T V. 44 バケット方式を使用した旧ペイロード圧縮 ・ H. 323 を利用するアプリケー ション 旧 fo. 、」 . Heath 他 ・ SNMP を利用するアプリケー ン・ヨン ITU-T 勧告 V. 44 に言されているデータ日孫宿アルゴ リズムにもとづく IP ペイロード ) 宿方式を定義している。 などがある。 162 UNIX MAGAZINE 2001.5

連載 /Cyber Kansai P「0 」 ect— リスト 1 BB の API / / ソース・デスティネーションホストと帯域、時間、予約開始までの時間を指定して予約する / / 予約が成功した場合は予約 ID が返る。予約に失敗すると 0 が返る public static int doReservation(String srcHost, String srcMask, String dstHost , String dstMask , int contentsServiceUnitId, int bandwidth, long timeOffset , / / 予約 ID を指定して予約をキャンセルする public static VOid cance1Reservation(int reservation 工 d) / / ソース・デスティネーションホストと時間、予約開始までの時間を指定し、 / / 予約可能な最大帯域の問合せをおこなう int srcPort , int dstPort , long timeDuration) public static int getTrafficSpec (String srcHost , String srcMask, int srcPort , String dstHost , String dstMask, int dstPort , int contentsServiceUnitId, 10 Ⅱ g timeOffset , 10 Ⅱ g timeDuration) / / ソース・デスティネーションホストと時間、帯域を指定し、 / / もっとも早い予約開始可能な時間の問合せをおこなう public static long getTimeCondition(String srcHost , String srcMask, int srcPort , String dstHost , String dstMask, int dstPort , int contentsServiceUnitId, int bandwidth , 10 Ⅱ g timeDuration) ます。電話をかける際に通言刮寺間を予測し、その時間ぶん の帯域を確保するのは非現実的です。かといって、時間制 限を設けずに帯域を確保するのも呼損率 1 を無意味に上げ る点でよくありません。利用者に提供するサーピスの矼ヒ とサービス側の資源活用という、相反する 2 つの面のト レードオフを探る間題になります 2 。 BB を利用するアプリケーションの実装 BB を利用するアプリケーションは、 BB によって提供 される Java API を呼び出します。その実装について簡 単に説明します。 今回の実験でアプリケーションが使用した API は、リ スト 1 に挙げた 4 つです。 getTrafficSpec() と getTimeCondition() は、実際 に予約する前にどのような予約が・可能か、 BB に帯域の空 きを間い合わせる API です。これらは doReservation( を呼び出して予約する前に、その予約の可否を石忍するた めにも利用します。また、希望するや帯域が予約でき ない場合に代替案を探すときにも使えます。 今回の実験では、この 4 つの API を以下のように組み 1 話し中などの理由によって通話 ( 呼 ) カ甘巨否され、サービスカ授けられな い害リ - 合。 2 現実には課金を含めた偂醍て利用者と交わす SLA の本はみのなかて解 決するのも 1 つの力法です。 UNIX MAGAZINE 2001.5 合わせて使用し、必要寸・分な機能か得られることを確認し ました。 アプリケーションは、ますコンテンツの配信前に get- TrafficSpec() を用いて、帯域の空きが予約しようとする 帯域より大きいかを石忍します。空きが - ト分にあれは、予 約が可能なので doReservation() を呼び出して予約を完 成させます。空きが不足している場合は帯域予約かて、きな いため、どの程度の帯域までなら予約可能かを利用者に通 知します。同時に、帯域をどうしても必要とする利用者の ことも考慮し、 getTimeCondition() を呼び出して、ど のくらい待てば必要な帯域が予約できるかも通知するよう にしました。利用者は、この 2 つの代替案 ( 予約する帯域 を減らすか、空きが発生するまで待っ ) のいすれかお尺 して再度予約します。 doReservation() でおこなった予 約は、予約 ID とともに RDB に予約実績として言当求され るため、不要になったら canceIReservation() を呼び出 して取り消すことができます。 実験結果 今回の実証実験では、ニュース配信マネージャーを利用 しながら、目標に掲げた BB の基イ幾能の検証や API の 評価などをおこないました。ニュース配信マネージャーで 191

は LDAP サーバーにパスワード変更要求を発行すること PS. 、 S. Santesson 他 で、ディレクトリ・データベースタ ) パスワードも正しく インターネットの X. 509 公開鍵インフラストラクチャ 変更できる。パスワード変更要求には、 てイ吏用される、、認定済み証明書 (Qualified Certificate)' 用のフロファイルを定義している。現在の状態は、、標準化 ・ユーザー識別子 への提唱 " である。 2001 年 1 月に公開された。 ・旧パスワード 、、認定済み証明書 " とは、ある規格に確実に適合する証明 新パスワード 書で、実在の人間に対してのみ発行される。認定済み証明 かオ褓内される。要求以前にパスワードが設定されている場 書のフォーマットと文法は RFC2459 で定義されている。 合は、パスワードの変更にさきだって旧パスワードでの認 RFC3039 は、 RFC2459 の定義にもとづく証明書の一殳 証がおこなわれる。変更が成功したかどうかの石忍は、サ 的なフロファイルを定義している。特定の範囲で使用され ーバーからのン以ワード変更 " として送られる。 るセマンティクスやポリシーを定義しているわけではない RFC3062 ではパスワード変更操作の要求およひ靤答に ここで定義されている情報のセマンティクスについ ので、 ついて規定しているだけなので、別途セキュリティ対策 てはそれぞれのシステムで豸虫自に定義する必がある。 が必要である。この拡彌巣作をおこなう場合には、 TLS RFC3039 では、証明書中の 2 つのフィールドと 5 つ (Transport LaJ ℃ r Security) などのセキュリティー呆護 の拡張を規定している。証明書フィールドは、 技術の利用が必須である。 ・ subject ( サプジェクト ) セキュリティ関連 ・ issuer ( 発行者 ) RFC3029 lnternet X 509 Public Key lnfrastructure で、刻長は、 Data Validation and Certification Server Protocols インターネット X. 509 公開鍵インフラストラクチャ ・サプジェクト・ディレクトリ属性 DVCS プロトコル 証明書ポリシー Exp. 、 C. Adams 他 鍵の取扱い DVCS ( データ有効目鹸証・認証サーバー ) と、 DVCS ・生物学的データオ内用のプライベート拡張 を用いるためのプロトコルについて論している。、、実験 ・認定済み証明書に関する状態↑褓内用のプライベート拡張 的 " として 2001 年 2 月に公開された。 である。さらに、イ寸録で、 DVCS は PKI を構成する要素の 1 つで、イ言頼匪のある 非孑色サーピスを構築する際の要素としてイ吏用できる、、信 プライベート拡張でイ吏われている ASN. 1 の定義 頼される第三者 (TTP)" である。 PKI 中の DVCS は、 属性についての注記 署名された文書の有効生、公開新正明書、データの所有ま 証明書の例 たは存在の評価に責任を負っている。 DVCS プロトコル を 1 求しているので、実際のプロファイルを作成する際に で作成される評価はデータ有効生証明書 (DVC) と呼は 役立つだろう。 れる。 RFC3029 では、署名の有効期限の延長や、公開新正明 RFC3058 Use of the IDEA Encryption Algorithm in 書の状態に関する DVCS への間合せといった DVCS プ CMS CMS での IDEA 暗号化アルゴリズム吏用 ロトコルの使用例を提示している。 旧 fo. 、 S. Teiwes 他 RFC3039 lnternet X. 509 Public Key lnfrastructure CMS ( RFC2630 ) および S/MIME ( RFC2632 ) で Qualified Certificates Profile IDEA アルゴリズムを利用する去を規定している。、、広 インターネット X. 509 公開鍵インフラストラクチャにお 報 " として 2001 年 2 月に公開された。 ける認定斉み証明書プロファイル 170 UNIX MAGAZINE 2001.5

能匪か高くなる。送信制約アルゴリズムは、 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

田淵責昭、末永洋樹、宮地利幸 Linux 関連のソフトウェアの更新情報をお届けする。 *Linux ティストリビューション Vine Linux 2.1.5 Project Vine は Vine Linux 2.1.5 を公開した。 内容は以下のとおりである。 ・ VineLinux2.1 の updates ( セキュリティ、ノヾグフィ —OpenSSH 2.5.1P2 へのアッフデート —Apache 1.3.19 へのアップデート —postfix 、 ProFTPd のアッフ。デート —XFree86 cvs 版パッチを適用 ーカーネノレ 2.2.17 から 2.2.18 へ ・ . パッケージのアッフデート ックス ) を適用 152 利用 ・ Transrneta 製 Crusoe フロセッサの電源管理イ冓の ・ ACPI による柔軟な電源管理 おりである。 Transmeta によれは、 Midori Linux の特徴は次のと forge. net/) でおこなわれる。 変も自山である。開発は、 SourceForge (http://source イセンスは GPL で、誰でもソースコードを入手でき改 Linux は系Ⅲムみ機器用の Linux べースの環境である。ラ com/) が、、 Midori Linux" の 0 版を公開した。 Midori 3 月 13 日に、 Transmeta (http://www.transmeta. Midori Linux 0 版公開 レードなどは確認されていない。 以降のバージョンだけで、 2.1 から 2.1.5 へのアップグ を用いたアップグレードが可能なのは Vine Linux 2.1.5 もアップグレードか容易になる。ただし、 apt for rpm apt と同等の機能をもつ apt の RPM 版で、従来より か採り入れられた。これは、 Debian GNU/Linux の ノ、ツケージ管理システムとして、新たに apt for rpm ・ FIash ROM を利用したファイルシステムのサポート ・ RAM ディスクのサポート ・ Flash ROM からの起動のサポート ・ディスクレス・オペレーションのサポート ・スクリプト言語により言己されたⅲ it のサポート ・ Web べースの成疋のサポート UNIX MAGAZINE 2001.5 た。構成は以下のとおりである。 MandrakeSoft は、 Linux-Mandrake 8.00 を発表し Linux-Mandrake 8.0 卩 るそうである。 なお、、、 Midori" という名称は日本言韶 ) 、、緑 " に由来す での利用は勧めないと述べている。 meta では糸Ⅲムみ機器での利用を前提としているため PC め、 PC 上て動かすことも原理的には可能だが、 Trans- IA32 アーキテクチャをターゲット環境としているた 成も容易である。 実行イメージを作成する機能もあり、実行イメージの作 のパッケージを自重加勺にコンパイルして組込み機器用の る。 Midori Linux には、 Linux カーネルと MLZ 形式 独自のライプラリや GUI システムを開発することもでき での開発は容易におこなえる。もちろん、目的に合わせて れており、 Linux での開絲釜験があれば Midori Linux れている glibc や X ウインドウ・システムなども含ま ジには、現在、デスクトッフ。用の Linux で一イ勺に使わ カーネルのソースなども含め 60 不鶤頁になる。パッケー 現在、 Transmeta から提供されているパッケージは ジを開発し、独自の組込み機器用の工竟カ購築できる。 このため、特殊な工韆竟でなくても容易に MLZ パッケー キュメント類を tar. gz 形式でアーカイプしたものである。 パイル手順を記述した、、 build " スクリプト、その他のド ル時の環境設定をおこなう、、 CONFIG" ファイル、コン MLZ 形式とは、 tar. gz 形式のソースコード、コンパイ 、 MLZ 形式 " のパッケージが多数用意されている。 て 2.4.0- test12 または 2.4.0 か利用できる。このはかに 現在の去肄〒版である 1.0.0 ー betal では、カーネルとし 上での重川が可能となる。 か使用できる。これにより、比較的小さな Flash ROM ノレシステム cramfs (compressed memory filesystem FIash ROM を利用する場合、一疇幾能をもつファイ

; こ ; こ当“こほれ話 1 月号 ~ 4 月号の特集で、 VMware を利用した UNIX と Windows の融合について、いろいろな控その実現 ガ去を紹介しました。思いのはか好評 ( ? ) だったようで、 いろいろな方からご意見をいただきました。 私自身は、 ( 多少の偏りはあったとはいえ ) まっとうに 書いたつもりだったのですが、 「あそこまて書くわけ ? 」 としばしは次っ込まれました。 zebra 系の方からは、 「いきなり zebra で経路制御ですか・ と半は呆れられてしまいました。 一方、指導教官の S 先生からは、 Windows を使い始 めた私に対して、 「日和ったな、大冫 となかなカい切れ味のグーパンチが入る始末です。 たしかに、 1 年ほど前の私は、 「 Windows なんて使うんしゃねーよ」 と四方八方でうそぶいていました。これでは、チョキで突 かれても 15 おかしくありません。 「まっ、 UNIX を愛してることに変わりはないんだから、 いいしゃないですか」 と言い逃れてはいます。しかし、学内や出張先などで ( 目 変わらず VMware について、 「ねえ、こうするにはどうした らいいの ? 」 「ねえねえ竟、みせてよ」 などという質間をよく受けます。 どうやら、 4 回の特集で は書き足りなかったようです。 ということで、 VMware の番タ扁として、これまでに 寄せられた質間への回答や Tips などを書くことにしまし 15 これらの言葉の言タ ) 憲未 ( 石裏カ ) は「パー卩く」 < 「グーで殴る」 < 「チョキで ( 目を ) 突く」という関係にあります。 丘いただいた質問のなかから、いくつか選んで紹介し ましよう。 802.11b のフリッジモードで吏用 ホスト OS が Windows 2000 、ゲスト OS が Net- BSD や FreeBSD の場合、プリッジモードで 802.11b 無泉インターフェイスを利用しようとすると、バケットの 受信はできても送信はできない状態になります。これは、 VMware で送受信を扱うことかて、きても、 802.11b の規 格上、送信はそのネットワーク・アタブタの MAC アド レスをもったものにしか許されていないからです。 現在のところ、 VMware 上では 802.11b 経由で IPv6 を使用することはできません。 プリッジモードで使用するネットワーク・アダ プタを切り替えたい プリッジモードで使用するネットワーク・アタフ。タは、 VMware のインストール時に決定されます。インストー ル後にこれを変更したいときは、次のようにします。 1. スタートメニューから、、ファイル名を指定して実行 " お尺し、 VMware をインストールしたディレク トリの Programs 以下にある vnetconfig. exe コマン ドを、引数、、一 s -ib VMnetX' を付けて実行する。た とえは、 VMnetO ( 通常は VMnet0) のプリッジする ネットワーク・アダブタを変更する場合には、 C:\>"c: \Program Fi1es\VMware\Programs\vnetcon fig ・ exe" —s —ib VMnet0 とする。 2. ネットワーク・アタブタの変更ダイアログ ( 画面 1 ) が 表示されるので、希望するインターフェイスを指定して [OK] ボタンをクリックする。 57 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 独自

上の例では core だけが、、 0 " となっていますが、その他 は最大の制限値のままです。これらの数値の未は、 limit コマンドの出力と上交するとよく分かります。 FreeBSD% limit cput ime filesize datasize stacksize coredumpsize memoryuse descriptors memorylocked maxpr 0 C FreeBSD% unlimited unlimited 524288 kbytes 65536 kbytes 0 kbytes unlimited 1064 unlimited 531 なお、 csh の limit コマンドに—h オフションを付けて 実行すると制限の最大値か表示されるため、佑端のカラム の値と等しくなります。 status 最後の status ファイルは、対象となるプロセスの状態 を示すものです。内容はテキスト形式なので、そのまま表 示できます。 FreeBSD% cat /proc/curproc/status cat 286 223 286 223 5 , 0 ctty 983977086 , 464076 0 , 17367 0 , 34734 nochan 1000 1000 0 , 0 , 0 , 5 FreeBSD% 表示されている情報のなかには、意床がよく分からない ものもあります。各カラムは左から順に、コマンド名、フ ロセス ID 、親プロセス ID 、プロセスグループ ID 、セ ッション lD 、制徊碍 } 末の major,minor 番号、プロセス フラグのリスト、プロセス開始時刻、プロセスの使用した ューサー日翻爿、プロセスの使用したシステム時間、ウェイ トチャンネル・メッセージ、実効ユーサー ID 、実ュー サー ID 、実グループ ID と実効グループ ID て始まるグ ループ ID のリスト、 jail を利用している場合のホスト名 を表しています (jail については後主します ) 。 プロセスフラグとしては、 ctty と sldr があります。制 御端末がある場合は ctty か設定さオ L 、該当するプロセス がセッション・リーダーである場合は sldr か設定されま す。両者とも設定されるときは、カンマで区切って並べま す。どちらのフラグも設定されないときは、 "noflags" と 出力されます。 すこし分かりにくいのはプロセスの開始時刻でしよう。 プロセスの開始時刻は UNIX における起点、すなわち UNIX MAGAZINE 2001.5 プログラミング・テクニック / 1970 年 1 月 1 日の午前 0 時を基售にした秒単位の直で 表現されています。カンマの後ろはマイクロ秒単位の端数 です。人間が見ることを前提にする場合には、これらの数 109 procfs の利用 いるディレクトリ /proc を参照し、そのなかから数値で このように、 procfs ファイルシステムをマウントして PROCS='1s /proc ー grep [ 0 ー 9 ] * $ , ー sort -n' 手します。 最初に、実行中のプロセスのプロセス ID のリストを入 どを用いて、簡易版 ps コマンドを作成します ( 図 1 ) 。 しよう。すでに説明した status ファイルや cmdline な マンドに似た働きをするシェル・スクリプトを作ってみま こで、これらのフア・イルを利用する例として、 ps コ てひととおり説明を終えたことになります。 こまでで、 procfs で用意されているファイルについ いる場合には、その jail 用のホスト名か表示されます。 ん。このように、 jail を用いた環境でフ。ロセスを実行して の内側のプロセスが外側の部分を変更することはできませ のシステムを 2 つの異なるシステムのように動かし、 jail ムであるかのように動かすことができる仕組みです。 1 つ ルシステムの一緇 ; にコピーし、そのなかだけで別のシステ 用いられます。 jail とは、ファイルシステム本をファイ 最後の項目は、システムが jail を利用している場合に ID か列挙されています。 効グルーフ ID で、その後ろにプロセスのほかのグループ 構成されていますが、う頁は実グループ ID 、 2 番目が実 を表しています。カンマで区切られたいくつかの題直から 後ろから 2 つ目の項目のリストはプロセスのグルーフ 11 時 58 分を表すことが分かります。 さきはどの例に出てきた直は、 2001 年 3 月 7 日午後 FreeBSD% 2001 年 3 月 7 日水曜日 23 時 58 分 06 秒 JST FreeBSD% date ーて 983977086 示されます。 け、引数として秒数を指定すると、その秒か表す日日俵 マンドが使えます。 date コマンドに一 r オプションを付 の形式に変換したはうがよいでしよう。変換には date コ 値をそのまま表示すると分かりづらいので、一勺な日時

表 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

、広報 " として 2001 年 1 月に公開された。 ITU-T 勧告 V. 44 の Annex B ( B. 1 節 ) では、ノヾケッ ト・ネットワーク上での V. 44 の実装である V. 44 バケ ット方式を規定している。 V. 44 バケット方式は、 LZJH データ圧縮アルゴリズムを利用したバケット圧系宿アルゴリ ズムである。 RFC3051 では、 RFC2393 で規定されている IP ペイ ロード圧縮プログラム (IPComp) で V. 44 バケット方式 を利用した損失のない IP ペイロード ) 石宿方式を定義して いる。 IPv6 関連 RFC3019 旧 Version 6 Managementlnformation Base for The Multicast Listener Discovery Protocol v6 の MLD プロトコル用 M 旧 PS. 、 B. Haberman 他 IPv6 の MLD ( マルチキャスト耳朝乂者探索 ) プロトコ ルの状態を監視するための MIB を規定している。現在の 状態は、、標準化への提唱 " である。 2001 年 1 月に公開さ れた。 MLD は ICMPv6 のサププロトコルで、直接接続され たリンクにおける近接ノード中の耳朝者を各ルータか検出 するために利用される。 RFC3019 では、 SNMP を利用 して MLD を扱うための MIB を規定している。 RFC3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 旧 v6 におけるステートレス自動設定機構のプライバシー 拡張 PS. 、 T. Narten 他 IPv6 のステートレス自動設定オ冓にフライバシーー隻 機構を導入する長を規定している。現在の状態は、、標準 イヒ、窈是唱 " である。 2001 年 1 月に公開された。 IPv6 にはアドレスの自動設定オ冓として、ステートフ ル自動設定オ冓とステートレス自動設定財冓の 2 不頁があ る。前者は DHCP などのアドレス設定用のプロトコルを 利用し、後者はネットワーク・インターフェイスに設定さ れている IEEEåü別子 (MAC アドレス ) を利用する。 ステートレス自動設定機構では、アドレスの一部に IEEE 識別子を用いる。これは、 IEEE 識別子が全世界 で一意であることを利用し、このオ冓によって設定したア UNIX MAGAZINE 2001.5 RFC ダイジェストー・ 163 めの仕組みとして、 IPv6 トンネルプローカを規定してい IPv4 を利用した IPv6 トンネルを自重加勺に設定するた fo. 、 A. Durand 他 lPv6 トンネルフローカ RFC3053 v6 Tunnel Broker レスを用いても間題は生しない。 かプロトコル・スタック内部に存在するため、一判勺アド TCP を利用したセッションでは、セッションの状態 定するとしている。 ケーションで一日勺アドレスを利用するための API を策 はアプリケーション層で対応し、将来的には UDP アプリ で通信できなくなる。 RFC3041 では、この問題について て、 UDP により長時間通信するアプリケーションは途中 はセッションの有無を判断できないためである。したがっ アプリケーションカ甘当屋しており、プロトコル・スタック UDP を利用したセッションでは、セッションの状態は れにより、 UDP の通信に間題が発生する可能性がある。 信しているセッションの有無を判断する必要がある。 この手法では、期限切れの一日判勺アドレスを利用して通 くなる。 することになり、ホストの物↓軸勺存雀を一意に識別できな 樹冓を利用しているホストの送信元アドレスはつねに変化 なった時点で削除される。これにより、プライバシー保護 ドレスは、そのアドレスを利用しているセッションがなく するセッションでは利用できない。期限が切れた一日勺ア は既存のセッションでのみ利用可能であり、新たに開始 定時間ごとに再設定される。期限が切れた一日判勺アドレス いる。ー判勺アドレスには有期限か轂けられており、 は、バケットの送信元アドレスとして一日判勺アドレスを用 プライバシー保護機構を利用した通信をおこなう場合 レスを一イ判勺アドレスと呼ぶ。 乱数を用いたアドレスも設定する。この乱数を用いたアド 自動設定の際に、 IEEE 識別子を用いるアドレスに加え、 拡張を規定している。具イ純勺にはアドレスのステートレス ス自動設疋オにプライバシー保護イ冓を導入するための そこで RFC3041 では、 IPv6 のアドレスのステートレ なる。 か特定できてしまうため、プライバシーの面からは欠点と レスの重複は容易に避けられる反面、ホストの物理的存在 ドレスも全世界で一意とするためである。これによりアド