--------- PR ---------------------------------------------------------
━ MEXインターネット接続サービス━━━━━━━━━━━━━━━━
　 ～インターネット接続MPLSアクセス、EoMPLS終端・接続～ 
　　 全国同一料金にてセキュアで高品質な
　　　　　　　　 インターネットコネクティビティを提供します
   サービスURL→ http://www.mex.ad.jp  メディアエクスチェンジ(株)
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
----------------------------------------------------------------------
---------- PR --------------------------------------------------------
 不┃正┃侵┃入┃の┃実┃態┃と┃具┃体┃的┃対┃策┃
 ━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛━┛
日時：2005年2月3日(木)～4日(金) http://www.nic.ad.jp/security-seminar/
場所：大手町サンケイプラザ(東京)    詳細・お申し込みはこちらから！
                             JPNIC・JPCERT/CCセキュリティセミナー2004
----------------------------------------------------------------------
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲          ◆ JPNIC News & Views vol.222【臨時号】2004.12.8 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.222 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2004年11月7日～12日の6日間にわたり米国・ワシントンD.C.で開催された、第
61回IETFのレポートをお届けします。インターネット技術に関する最新動向満
載ですので、どうぞじっくりご覧ください。

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第61回IETF報告
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

……………………………………………………………………………………………
1. 全体会議報告
                                                 JPNIC 技術部 木村泰司
……………………………………………………………………………………………

◆概要

2004年11月7日(日)～2004年11月12日(金)、米国のワシントンD.C.にある
Hilton Washingtonホテルで、第61回IETFが開催されました。IETFはインター
ネットにおけるプロトコルの標準化を行うミーティングです。普段はMLで議論
を行っていますが、1年に3回オフラインのミーティングで提案ドキュメントに
ついての議論を行ったり、コンセンサスの確認を取ったりしています。

今回の参加者数は、26ヶ国から1314名と前回よりも参加国数、登録者数、共に
少ない状況でした。国別の参加者数は、米国、日本、韓国、ドイツ、フランス
の順となっており、日本からの参加者は全体の1割以上を占めていました。国
際的な技術標準化の活動の場でこれほど多くの日本人が参加していることは大
変素晴らしいことだと思います。


◆ Plenary（全体会議）

今回のIETFでは、通常2回に分けて行われるPlenary（全体会議）が1回にまと
めて行われました。RFCの発行前の編集を行っているRFC Editorからは、2001 
年には月に20程度の文書の編集依頼が来ていたが、2003年以降は平均28に増
加していることやXMLを使った原稿が増えていること、新しいWord用のテンプ
レート(*1)に対するコメントを募集していることなどが発表されていました。
IANAからは、コード番号やパラメータといったIANAの判断が関連する
Internet-Draft（以下、I-D）の状況を見られるWebページの紹介がありました。
http://www.iana.org/reporting-and-stats/で見られます。

IESG(*2)からはエリアディレクターによるI-Dの処理状況で、第60回までの増
加傾向から一転し、第61回IETFまでの間はドキュメントの処理（レビュー）依
頼件数が減少したことなどが発表されました。IAB(*3)からは第60回IETFで説
明があったIETFの運営構造の再編成(*4) についての現状報告がありました。
ISOCの活動としてIABやIESGをサポートし、またIETF運営の費用管理を行なう、
IASA（IETF Administrative Support Activity）モデルについてのRFC（BCP）
(*5)が作られるようです。

次回の第62回IETFは米国のミネアポリスで2005年3月6日～3月11日に開かれる
予定です。また第63回IETFはフランスのパリで、2005年7月31日～8月5日に開
かれる予定です。

(*1) RFC Templates and Info. （Joe Touch氏のページの一部）
　   http://www.isi.edu/touch/tools/
(*2) IESG: http://www.nic.ad.jp/ja/basics/terms/iesg.html
(*3) IAB: http://www.nic.ad.jp/ja/tech/glos-ij.html
          http://www.nic.ad.jp/ja/basics/terms/iab.html
(*4) IETF AdminRest Homepage
     http://www.alvestrand.no/ietf/adminrest/
(*5) BCP: Best Current Practice
     インターネットの運用方法について、論点やコンセンサス事項を示した
     り、IETFの運用プロセスを示したりする種類のRFCのこと。RFCには他に
     Informational（情報）、Experimental（実験的）、Historical（歴史的） 
     という種類がある。
     http://www.nic.ad.jp/ja/newsletter/No24/090.html


……………………………………………………………………………………………
2. IPv6関連WG報告
                                    JPNIC IPアドレス検討委員会メンバー
                                     NTT情報流通プラットフォーム研究所
                                                              藤崎智宏
……………………………………………………………………………………………

本セクションでは、IPv6関連トピックスとしてIPv6、v6ops、Multi6のワーキ
ンググループ（以下、WG）の動きについて報告します。

◆IPv6（IP version 6）WG

IPv6の基本スペックなど、コア部分の標準化を進めているIPv6 WGのミーティ
ングは、11月11日(木)午前に1コマ開催されました。前回に比べ、アジェンダ
自体はそれほど多くはありませんでしたが、大きめの部屋に溢れそうな参加者
を集め、活発な議論が実施されました。

今回話し合われた主なトピックスは、

・既存RFCのドキュメント更改
  - プライバシーアドレス（RFC3041） ： PS -> DS に向けた議論
  - アドレス自動設定（RFC2462）： DS文書の改訂
・ルータ選択機構についての議論
・Multi6 WGの状況報告
・始点アドレス選択ポリシーの配布機構に関する提案

などです。

ミーティングのはじめに、チェアよりIPv6 WGで扱っている各文書について、
ステータスの報告がありました。IPv6 WGのWGドキュメントについては、

http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html

に非常に良くまとまっていますので、是非ご参照下さい。

既存RFCのドキュメント更改に関しては2件、ミーティングで話し合われました。
いわゆるテンポラリアドレス（プライバシーを保護するために、IPv6アドレス
の下位64ビットをランダムに構成する方法）を定義したRFC3041は、現在、PS 
（Proposed Standard）状態ですが、これをDS（Draft Standard）にするため
の検討が進んでおり、プライバシーアドレスをデフォルトで利用するようにす
るかどうか、現在別途検討が進んでいるユニークローカルアドレスの場合にも
プライバシーアドレスをつけるか、などが議論されました。IPv6のベーススペッ
クの一つである、RFC2462の改訂に関しては、エリアディレクターからのコメ
ントを検討し、別途改訂が進行中であるRFC2461との関連を整理すること、前
回のミーティングでも話題になりましたアドレス自動設定を制御するM/Oフラ
グの仕様明確化などを現在のドラフトに盛り込み、RFC化を進めることとなっ
ています。

その他、WGとして取り組んでいるルータ選択ドラフトに関する議論（複数のルー
タが存在する場合に、ルータの優先度の指定、経路情報の伝達をする機構）で
すが、経路情報の有効期限や経路の振れに関する問題等が議論され、ルータの
有効時間を経路情報にも利用する等を文書に反映し、RFC化を進めることにな
りました。また、IPv6では一つのインタフェースに複数のIPv6アドレスが付加
されることがありますが、通信の際に適切なアドレスを選択する手法について
の提案がありました。こちらは、ルータ選択機構との関連を整理し、議論を継
続することになっています。

□IPv6 WG
  http://www.ietf.org/html.charters/ipv6-charter.html
  http://playground.sun.com/pub/ipng/html/ipng-main.html

□第61回 IETF IPv6 WG ミーティングのアジェンダ
  http://www.ietf.org/ietf/04nov/ipv6.txt


◆v6ops（IPv6 Operations）WG

IPv4とIPv6の共存技術／移行技術、及びIPv6デプロイメントを進めるv6ops WG 
ミーティングは、11月10日(水)午前中に1コマ開催されました。前回のミーティ
ングでも予告があったとおり、v6ops WGの今後の進め方が大きな議論となりま
した。

従来より、v6ops WGでは、IPv6移行技術（主に、IPv4ネットワークを利用して
IPv6接続を実施する技術）と、IPv6ネットワークへの移行技術を並行して扱っ
て来ましたが、そもそもIETFにおけるオペレーションエリアのWGであるv6ops 
ではプロトコルの標準化が主目的ではないこと、また、IPv6ネットワークの普
及がある程度進んできたことにより、セキュリティなど取り扱うべき項目が増
えてきたことから、移行技術を扱うWGを別途設けることになりました。新たな
WGはトンネルベースの移行技術を扱うWGとして定義されており、設立に向けた
準備を急ぎ実施することで合意が得られています。

この議論に多くの時間を使ったため、議題にあがっていた幾つかの項目は駆け
足で概要紹介、簡単な議論となりました。その主な内容は以下の通りです。

・移行技術として標準化されたRFC2766（NAT-PT）は、Experimental（実験的
  プロトコル）として利用しない方向にすることとなりました。
・今日のブロードバンドインターネットにおいてIPv6/IPv4を共存させるため
  の検討ドラフトですが、更にレビューをした上で、WGとして扱うことにする
  か否かの判断をすることになりました。

概要のみでしたが興味深いところとして、WIDEプロジェクトよりIPv6 FIXプロ
ジェクトに関する報告がありました。これは、IPv6が普及し始めたことにより、
幾つかの不具合が実際に報告されており、普及を阻害しないようにするために
も早急な対処をしていこう、というものです。このプロジェクトについては、
以下のURLに概要が掲載されており、Internet Week 2004のBoF「IPv6 Fix BoF～
デュアルスタックサクサクブラウジング～」でもその概要が紹介されました。

 http://v6fix.net

□v6ops WG
  http://www.ietf.org/html.charters/v6ops-charter.html
  http://www.6bone.net/v6ops/

□第61回 IETF v6ops WG のアジェンダ
  http://www.ietf.org/ietf/04nov/v6ops.txt


◆Multi6（Site Multihoming in IPv6）WG

IPv6インターネットで利用可能なマルチホーム手法の検討・標準化を目的とし
ているMULTI6 WGは、11月8日(月)の午前中及び11月10日(水)の午後の2コマ開
催されました。

ミーティングでは、まずはじめにWGの四つのドラフト文書
  ・マルチホーミングの主にセキュリティの観点からの脅威をまとめた文書
  ・IPv4でのマルチホーミング手法の整理を実施した文書
  ・マルチホーミングを実施する際に考慮すべき点を整理した文書
  ・IPv6におけるマルチホーミング手法を体系的に整理した文書
について、ほぼ完成に近づいたことの報告があり、WGからのコメントを募集後、
RFC化を進めることになりました。

その後、WGでデザインチームを組織して検討していたマルチホームの解法につ
いての紹介、議論がありました。Multi6 WGとして、IPアドレスのホスト識別
子としての機能と、インターネット上の場所を示す場所指定機能を分離するこ
とでマルチホーミングを実現すること、そのために、IP層とトランスポート層
の間に、上位層で利用するホスト識別子と、IPアドレスをマッピングする層を
設けることを基本設計とすることに決定しました。

マルチホーミング手法の基本設計が終わったことで、Multi6 WG自体は終了し、
プロトコル詳細を設計／標準化するWGを別途設立することになっています。

□Multi6 WG
  http://www.ietf.org/html.charters/multi6-charter.html

□第61回 IETF Multi6 WG のアジェンダ
  http://www.ietf.org/ietf/04nov/multi6.txt


……………………………………………………………………………………………
3. DNS関連WG報告
                             JPNIC DNS運用健全化タスクフォースメンバー
                                             東京大学 情報基盤センター
                                                              関谷勇司
……………………………………………………………………………………………

DNS関連のWGの中から、DNSOPとDNSEXTのWGでの議論の動向について報告します。

◆DNSOP（Domain Name System Operations）WG

DNSOP WGでは2時間のBoFが開催されました。今回のBoFでは、新たな話題とい
うものは少なく、I-Dの状況報告に大半の時間が費やされました。

まず最初に、DNSSEC(*6)の運用に関する情報をまとめたI-Dである、
draft-ietf-dnsop-dnssec-operational-practicesに関する報告が行われまし
た。DNSSECの最新仕様に準拠するよう改訂され、Working GroupのLast Callに
むけて動いているようです。また、DNSSECにて使用されるzone署名鍵の更新に
関するI-Dである、draft-ietf-dnsop-key-rollover-requirementsの状況報告
もなされました。Working Group Last Callをしてもいいのではないかという
意見もありましたが、まだ鍵更新に関する事象を網羅できているわけではない
ので、もう少し更新が必要だろうという意見に落ち着きました。なお、今回の
IETFと併設してDNSSEC WorkShopも開催されていたようで、DNSSECの運用にお
ける問題点の共有がなされていたようです。

次に、IPv6におけるDNS設定の問題点を述べたdraft-ietf-dnsop-ipv6-dns-
issuesの状況報告がなされていました。DNSのzoneにAAAA recordを追加する場
合の注意点や、DNSサーバのIPv6トランスポートを有効にする際の注意点等、
DNSをIPv6対応にして運用する際に注意すべき点について書かれたI-Dです。

今回唯一の新たな話題であったのが、draft-fujiwara-dnsop-bad-dns-authに
関する報告でした。この発表では、IPv6やDNSSECの普及によって、DNSの名前
解決のためにやりとりされるパケットが増大するため、TCPやEDNS0(*7)による
名前解決が必要になるという指摘がされました。この際、TCPは管理者の設定
ミスによってフィルタされている場合があるという問題点を指摘しており、ま
たEDNS0では、取り扱えるバッファサイズの上限を越えると結局UDPフラグメン
トが発生してしまう、という問題点も指摘されました。会場にて、このI-Dを
WG I-Dとして議論を続けていくことが合意されました。

□DNSOP WG 
  http://www.ietf.org/html.charters/dnsop-charter.html

(*6) DNSSEC：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-DNSSEC
(*7) EDNS0：http://www.nic.ad.jp/ja/tech/glos-ah.html#01-EDNSO


◆DNSEXT（DNS Extensions）WG

DNSEXT WGでも、2時間のBoFが開催されました。やはり話題の中心は、DNSSEC 
に関するI-Dでした。その中で、一番時間を割いて行われた議論は、NSEC(*8)
RR（以下、RR）に関する議論でした。これは、DNSSECにてzone中にあるRRの
存在を保証することによって、あるRRがzone中に存在しないことを確認するた
めに利用されるRRで、偽のDNS応答に対する防御を行うための仕組みの一つで
す。しかし、現在の仕様のままでは、NSEC RRをたどっていくことによって、
zone中に存在するすべてのRRがばれてしまう仕様となっています。これをセ
キュリティ的に問題視する人が多いため、現在の仕様のままではDNSSEC導入の
障害となる、という指摘が以前からなされていました。そのため、NSECの仕様
を改善しようという議論が行われました。いくつかの候補が出ており、それぞ
れの候補に対して、利点、欠点等が示され、解決しなければならない課題が示
されました。どの案もまだ議論の途中であるため、結論は出ていません。引き
続き議論が行われることとなりました。

他にも、draft-kolkman-dnsext-dnssec-in-band-rolloverや
draft-laurie-dnssec-key-distribution、個人名で出されているDNSSECに関す
るI-Dについて、報告がなされました。DNSSEC以外の話題としては、Sender
Policy Framework（SPF）という機構についての発表がありました。これはDNS 
に新しいRRを登録して、この新しいRRがzoneに登録されているホストからのメー
ルしか受け付けないようにすることによって、SPAMを防ごうとする仕組みです。
これはまだ原案段階といった感じであり、I-Dも発行されていません。全体と
して、やはりDNSSECの議論に終始した、という感じでした。

□DNSEXT WG
  http://www.ietf.org/html.charters/dnsext-charter.html

(*8)NSEC：http://www.nic.ad.jp/ja/tech/glos-kz.html#03-NSEC


……………………………………………………………………………………………
4. セキュリティ関連WG報告
                                                 JPNIC 技術部 木村泰司
……………………………………………………………………………………………

2004年12月現在、セキュリティ・エリアのWGは23あります。IETFで議論されて
いるプロトコルの主旨や性質は多種多様なので、このように多数のWGがある状
況です。WGは年単位で見ると流動的で、時間が経つと様相が変わってきます。

ここでは、セキュリティ・エリアの概況をお伝えすると共に、第61回IETFで注
目したセキュリティ関連のWGやBoFの活動を報告します。

◆セキュリティ・エリアの概況

セキュリティ・エリアのWGは、TLS(*9)やIPsec(*10)といった基本となる暗号
通信プロトコルの標準化の他に、暗号鍵や認証情報の扱い方としてのプロトコ
ルの標準化を行うWGや、開発や利用の指針となる仕様としてのプロトコルを標
準化するWGなどがあります。

セキュリティ・エリアのWGを大きく分けると、IPsec、PKI(*11)、
Kerberos(*12)、それからインシデント情報に関連したWGがそれぞれ複数あり、
あとは個別の仕組みのプロトコルに取り組んでいるWGがいくつかある、という
状況です。IPsecに関連したWGはIPSEC、IPSECKEY、IPSP、MOBIKE、PKI4IPSEが
挙げられます。PKIに関連したWGには、PKIXの他に、PKIを利用してそれぞれ
のサービスを実現するためのプロトコルを扱うLTANSやSMIMEがあります。最近
作られたWGの中でも活発なPKI4IPSEは、IPsecの利用しやすくするため、VPN 
といった利用条件を決め、PKIの併用方法(プロファイル)の標準化を検討する
のを主な目標としたWGです。

近年のセキュリティ・エリアでは、セキュリティの為の基本的なプロトコルの
標準化よりも、それらを活用して、いかにサービスとして動かしていくか、と
いう主旨をターゲットにしたWGが活発に活動しています。今回のIETFで開かれ
たEasyCert BoFは、より実践的な知見を集めて、PKIを簡単に使えるようにし
ようという主旨のBoFであり、最近の動向を象徴した活動だと言えます。
一覧は以下URLでご覧いただけます。

□Active IETF Working Groups - Security Area
  http://www.ietf.org/html.charters/wg-dir.html#Security%20Area


◆セキュリティに関連したWGとBoF

今回はPKIX、EasyCert BoFについて報告致します。

▼PKIX（Public-Key Infrastructure）WG

PKIX WGは11月10日(水)の午後1時から行われました。参加者は60名程でした。

はじめにドキュメントステータスの確認が行われました。今回のIETFまでに、
RFC3874"A 224-bit One-way Hash Function: SHA-224"が発行されました。以
下の三つのI-DはIESGによって承認され、RFC Editorの編集待ちの状態にあり
ます。

- "Additional Algorithms and Identifiers for RSA Cryptography"
- "Internet X.509 Public Key Infrastructure -- Certificate Management
   Protocol（CMP）"
- "Internet X.509 Public Key Infrastructure Permanent Identifier"

"Internet X.509 Public Key Infrastructure:Certification Path Building" 
を始めとする6つのI-Dがエリアディレクターによるフォローかコメントを待っ
ている状態です。"Simple Certificate Validation Protocol "（SCVP）の第
16版はWG Last Callがかけられました。

今回のセッションではSCVPの16版(draft-ietf-pkix-scvp-16.txt)、RFC3280の
改良、CRL（Certificate Revocation List）の発行者を特定するための拡張
フィールド（AIA: Authority Information Access）、CRLの検証ルール、証明
書とCRLを格納するLDAPのスキーマ、簡易版のOCSP、ECCアルゴリズム識別子な
ど、多くのプレゼンテーションが行われました。大きな動きのあった、SCVPと
CRLの拡張フィールドについて紹介します。

SCVPの16版は、CA証明書のフルサポートを始め、様々な機能追加や文書の変更
がありました。基本的な記述作業は一段落したようです。

CRL発行者を特定する仕組みの必要性は、MLで必要性が指摘されたものです。
今回の提案は認証局と鍵を特定できるよう、AIAに識別の為の値をいれること
です。

リエゾンによるプレゼンテーションは、韓国KISAのBaehyo Park氏によって
"User Interface Requirements for PKIX"と題して行われました。証明書を
扱うGUIの要件について紹介するため、SSL/TLSに加えてオンライン取引に使用
するといったデモが行われました。

WGチェアのTim氏によると、LDAPスキーマ関連のドキュメントやRFC3279/3280
の改良は2005年の春までに完了させる予定だそうです。PKIX WGのクローズに
向け、ラストスパートをかけている様子です。

□PKIX WG
  http://www.ietf.org/html.charters/pkix-charter.html

▼Easycert（Easy-to-Use Certificates）BoF

Easycert BoFは、前回のIETFのセキュリティ・エリア会議（SAAG）で挙がった
"PKIの利用が広まらない状況を踏まえて実践的な議論を進めるべき"という指
摘を受け、エリアディレクターのSteve Bellovin氏、Russ Housley氏がチェア
となって開かれました。180名近い参加者がいて、会場の部屋は超満員の様子
です。

このBoFの主旨は、PKIの成功した導入事例から使いやすさの要素を洗い出し、
その上でIETFとしてできる活動を明らかにする、というものです。BoFでは、
マサチューセッツ工科大学（MIT）とJohnson&Johnの事例が紹介されました。
いずれの事例紹介でも話題になったのは、失効方法（CRLを使っているか）と
証明書管理モデルの妥当性です。どの事例でも、証明書は基本的に認証用に用
いており、CRLに頼らず、サービスシステム側で認証用のデータベースを持っ
ていました。米国防総省（DoD: Department of Defence）で発行されたCRLは
40メガバイトにもなったという話も挙がっていました。

これらの事例紹介に対し、会場から出る意見は多く、活発に議論が行われま
した。PKIを簡単にする観点については、ISPが証明書を発行してはどうか、
PKIはフォーマットが複雑なのが問題、といった意見が出ました。

IETFとしてできる活動については、色々な場面で使えるような認証のブートス
トラッピング（初期立ち上げ）のプロトコルを標準化してはどうか、といった
意見が出てました。この他に認証時にどのクライアント証明書を使うべきなの
か戸惑う、といった意見があり、TLS WGへのフィードバックになるといったコ
メントが返されていました。しかしIETFでできる活動の方向性を見出すまでの
議論には発展しませんでした。

今後はより多くの事例を集め、PKIのガイドブックとなるInformational RFCを
作ることを目指す、ということになりました。この作業はIABのEric氏が担当
することになりました。

Easycertは、MLでの議論も平行して行われています。Easycert MLについては
"Easycert -- Easy-to-Use Certificates"をご覧下さい。

□Easycert - Easy-to-Use Certificates
  https://www.machshav.com/mailman/listinfo.cgi/easycert


◆その他

今回のIETFのセキュリティエリア会議（SAAG）で、Steven Bellovin氏がエリ
アディレクターを引退することが発表されました。後任には、MITのSam
Hartman氏が着任することになりました。

IETFはプロトコルの標準化を目的とする活動ですが、議論の中で運用面／利用
面の意見が重要なフィードバックとなります。特にPKIの議論に関して、利用
経験のある日本の方が標準化活動に参加することで、RFCに知見を盛り込み、
利用性向上を図る活動の牽引力になるのではと思いました。

(*9)  TLS: http://www.nic.ad.jp/ja/tech/glos-kz.html#03-tls
(*10) IPsec: http://www.nic.ad.jp/ja/tech/glos-ij.html#IPsec
(*11) PKI: http://www.nic.ad.jp/ja/tech/glos-kz.html#03-PKI
(*12) Kerberos:
      マサチューセッツ工科大学（MIT）のAthenaプロジェクトで開発された
      認証システム。telnetやftpを始め、複数のプロトコルに対して共通の
      認証と暗号化の機能を提供する。

     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             http://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  :::::  http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::  http://www.nic.ad.jp/member/(PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
 JPNIC News & Views vol.222 【臨時号】 

 ＠ 発行         社団法人 日本ネットワークインフォメーションセンター
                 101-0047 東京都千代田区内神田2-3-4 国際興業神田ビル6F 
 ＠ 問い合わせ先   jpnic-news@nic.ad.jp 
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
登録・削除・変更   http://www.nic.ad.jp/ja/mailmagazine/


■■◆                          ＠ Japan Network Information Center 
■■◆                                     ＠  http://www.nic.ad.jp/ 
■■

Copyright(C), 2004 Japan Network Information Center