メインコンテンツへジャンプする

JPNICはインターネットの円滑な運営を支えるための組織です

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは? JPNIC WHOIS Gateway
WHOIS検索 サイト内検索
===================================
   __
    /P▲          ◆ JPNIC News & Views vol.159【定期号】2004.3.15 ◆
  _/NIC
===================================

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

本号は2月末から3月上旬にかけて行われたインターネット関連海外会議の最新
情報盛りだくさんでお届けします。

まずは、2004年2月29日~3月4日に韓国・ソウルで開催された第59回IETFを特
集で。もう一つは、3月2日~6日にかけて行われたICANNローマ会議の速報。ど
ちらもお見逃しなく!

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 目次
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

【 1 】特集 「第59回IETF報告」
         1. 全体会議報告
         2. IPv6関連WG報告
         3. DNS関連WG報告
         4. セキュリティ関連WG報告
【 2 】トピックス
         1. ICANNローマ会議速報
【 3 】News & Views Column 「社会インフラとしてのインターネット」
         JPNIC IRR専門家チームメンバー/日本テレコム(株)
         松本順一氏
【 4 】インターネット用語1分解説 「正引き/逆引きとは」
【 5 】統計資料
         1. JPドメイン名
         2. IPアドレス
         3. 会員数
         4. 指定事業者数
【 6 】イベントカレンダー


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 1 】特集 「第59回IETF報告」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

……………………………………………………………………………………………
1. 全体会議報告
                                                JPNIC 技術部  上野晶久
……………………………………………………………………………………………

2004年2月29日~3月4日に韓国・ソウルにて第59回IETF(*1)会議が開催されま
した。今回のIETF会議では全会議数が90余りと、前回(米国・ミネアポリス)
に比べ会議の数こそ減少しましたが、参加者は1,255名と前回を上回り、イン
ターネット技術標準化活動に対する関心の高さをうかがい知ることができまし
た。
 
全体会議は2部で構成され、3月3日には各組織の現状報告を中心とした
Business Meeting、最終日となる4日にはIETFの将来的な運営、管理体制を検
討するPlanning Meetingが開催され活発な議論が行われました。

(*1) IETF:Internet Engineering Task Force
           http://www.nic.ad.jp/ja/basics/terms/ietf.html


◆IETF Business Meeting

IETF Business MeetingではRFC-editor、IANA(*2)、IESG(*3)、およびIAB(*4)
から現状報告がなされました。
 
RFC editorレポートでは、RFC-Errataページが改善され外部ページから直接
該当するErrata項目へリンクを張ることが可能となったこと、および新たな
著作権、知的所有権に関する記述がすべてのRFCに付加されたことが報告され
ました。

  http://ftp.rfc-editor.org/in-notes/IETFreports/mar04-report.ppt

IAB Chiarリポートでは、ISOC評議会メンバー選出の候補者として以下の5名が
登録されていると報告がありました。

  Avri Doria氏、江崎 浩氏、Erik Huizer氏、James Seng氏、Paul Wilson氏

今後のメンバー選出スケジュールについては以下のURLをご参照ください。

  http://www.iab.org/documents/docs/2004-02-07-isoc-bot-candidates.html

(*2) IANA:Internet Assigned Numbers Authority
           http://www.nic.ad.jp/ja/tech/glos-ij.html#02-IANA
(*3) IESG:Internet Engineering Steering Group
           http://www.nic.ad.jp/ja/basics/terms/iesg.html
(*4) IAB:Internet Architecture Board
          http://www.nic.ad.jp/ja/basics/terms/iab.html

 
◆IETF Planning Meeting

Planning Meetingでは、最初にEric Nordmark氏よりマルチホーム化したネッ
トワークの問題点を解決するための提案がなされました。現在はIPアドレスが
IdentifierおよびLocatorとして二つ役割を担っていますが、トランスポート
層とネットワーク層の間に中間層を新たに設け、IdentifierとLocatorを分離
させることでマルチホーム化したネットワークに拡張性を持たせようというも
のです。この提案には多くのコメントが寄せられましたが、その実現可能性に
ついて懐疑的な意見が多く聞かれました。

続いてAdvisory CommitteeよりIETF管理体制の改変を目的したInternet-Draft 
(以下I-D)の紹介がありました。この提案は、IETFの運用管理に特化した組
織となるAG(Administrative Group)を新設することでIETF活動の一層の効率
化を図るというものです。今後この提案内容を引き続き検討していくというこ
とでした。

  http://www.ietf.org/internet-drafts/draft-daigle-adminrest-00.txt

最後に、Advisory CommitteeよりIETFが担うべき役割について明文化したI-D 
の紹介がありました。さらに内容を精査し、次回の第60回IETF Meeting(米国・
サンディエゴ)までにRFCとして発行する意向があるということでした。

  http://www.ietf.org/internet-drafts/draft-alvestrand-ietf-mission-00.txt


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

本セクションでは、IPv6関連のトピックスを扱っている主なワーキンググルー
プ(以下WG)での議論内容について紹介いたします。


◆IPv6 WG(IP version 6 WG)

IPv6 WGでは、IPv6コア技術の標準化を進めており、3月2日の午後2コマを使っ
て議論が実施されました。今回はミーティング時間を有効に使うため、従来ミー
ティング時間のはじめにチェアが報告をしていたIPv6 WGで標準化を進めてい
る各文書のステータスは、Webでの事前紹介となりました(WGでのコメント反
映済のリストが下記URLにあります)。

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

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

・IPv6 Node Requirement文書に関する議論
・IPv6近隣探索(RFC2461)、アドレス自動設定(RFC2462)等、IPv6ベースス
  ペックRFCのドキュメント改訂
・Optimistic DAD(簡易重複アドレス検出)に関する議論

などです。

前回まで議論が続いていた、サイトローカルアドレスの廃止、および新規のロー
カルアドレスである一意ローカルユニキャストアドレス標準に関しては、RFC 
化に向けて順調に進んでおり、今回特に議論はありませんでした。

IPv6 Node Requirement文書は、IPv6ホストやルータが実装するべき共通IPv6 
機能を定義するものです。大きな問題としてセキュリティ技術の扱い(サポー
トするべきIKE(Internet Key Exchange)のバージョンや暗号化アルゴリズム
の種類など)は、IPsec WGで議論すべきであるため、セキュリティの章は分離
すべきである、参照するべき機能はドラフト段階のものを含むべきではない等
の議論があり、文書の見直し、セキュリティ関連WG等との調整を実施すること
になりました。

ドキュメントの改訂では、ほぼ問題は収束しつつありますが、現在の文書が成
立した後に標準化されている新規技術をどう取り込むかや、他の文書との関連
等が指摘され、問題点の解決に向けて議論が進んでいます。

今回、Optimistic DAD(簡易重複アドレス検出)に関して、時間を少々長くと
り議論されました。IPv6には、アドレスの衝突を検出する重複アドレス検出
(Duplicate Address Detection/DAD)という機能を標準で実装することが求
められていますが、このDADには時間がかかるため、アドレス衝突の可能性が
低い場合に限り(IEEE EUI-64インタフェースIDの利用が確実である場合や十
分に良い乱数を利用できる場合など)、動作の一部を省略してDADが速く終わ
るようにしようというものです。近隣探索機能をセキュアにすることを検討し
ているSEND WGとの関係や、後方互換性が議論され、今後、IPv6 WGのWGドラフ
トとして標準化を進めていくことになりました。

全体として特に大きな問題はなく、標準化が順調に進んでいるという印象を受
けました。

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

□59th IETF IPv6 WGのアジェンダ
  http://www.ietf.org/ietf/04mar/ipv6.txt


◆DNSOP WG(Domain Name System Operations WG)

DNSOP WGは3月1日の午後に実施されました。もともとのプログラムでは、2日
の午後に、もう1コマ予定されていましたが、議論が順調に進み、2コマ目はキャ
ンセルとなりました(チェアがセッションはじめに使用したプレゼン資料が
http://www.1-4-5.net/~dmm/IETF/IETF59/DNSOP/agenda/ に掲載されています
のでご参照ください)。

前回、前々回と長く議論され、結論が出ていなかったIPv6ネットワークでの
DNSサーバアドレスの取得方法(DNS探索)に関してですが、このまま議論が長
く続くことを避けるため、今一度問題点をクリアにして、それぞれの手法の特
徴や運用上の問題等を取りまとめた文書を次回のIETFまでに(8月にSan Diego 
で予定されています)RFC化する、という目標がたてられ、今回数人のチーム
を構成し、文書化を進めることになっています。

その他、現在WGに提案されているドキュメントが再整理され、IPv6関連では

・IPv6利用環境でDNSを利用する際の運用上の考慮点をまとめたドラフトがRFC
  化に向けてWG Last Call
・IPv6のAAAA資源レコードの問い合わせに対して、不正な応答をするDNSの実
  装が存在し、通信を阻害することがある問題を記したドラフトがRFC化に向
  け進展
・IPv6のDNS逆引きについて、現状、逆引きが認証に利用されることがあり、
  円滑な通信実現に対して問題を引き起こしていることに対する分析と対策を
  記した文書が失効していたものを復活

という議論がありました。

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

□59th IETF DNSOP WGのアジェンダ
  http://www.ietf.org/ietf/04mar/dnsop.txt


◆v6OPS WG(IPv6 Operations WG)

v6OPS WGは3月1日午後と4日午後に、2コマ開催されました。今回、多くの時間
を使い、IPv6への移行技術として標準化が続けられているトンネリング技術に
関して、

・Opportunisticトンネリング(6to4(*5)やTeredo(*6)など)
・Zero-configuredトンネリング(ISATAP(*7)など)

という分類をし、使い方や今後の進め方や、方式自体の是非の議論が実施され
ました。利用シーンとして、プロバイダがIPv6を提供していない場合や、NAT 
の後ろ側のネットワークにIPv6接続性を提供する企業等でコストをかけずに
IPv6を利用可能にする等を想定しています。

また、IPv6の特長を有効活用するためのセキュリティモデルの提案が2件実施
されています。従来のIPv4型ファイアウォールによるネットワーク防御モデル
では、end-to-end通信が阻害されてしまう、IPsecの利用が困難である、といっ
た問題があり、IPv6の特徴を生かすことができません。これに対し、ファイア
ウォールを分散させて配置する、検疫をして通信を許可する、といった手法を
使ってはどうか、という提案がなされました。後者の方式に関しては、欧州の
IPv6ネットワークにて類似のモデルを使用した実験を行うことを考えていると
いう情報があり、共同して実際に実験をして進めてみる、ということになりま
した。

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

□59th IETF v6OPS WGのアジェンダ
  http://www.ietf.org/ietf/04mar/v6ops.txt

(*5) 6to4:http://www.nic.ad.jp/ja/tech/glos-ah.html#01-6to4
(*6) Teredo:http://www.nic.ad.jp/ja/tech/glos-kz.html#03-teredo
(*7) ISATAP:Intra-Site Automatic Tunnel Addressing Protocol
             http://www.nic.ad.jp/ja/tech/glos-ij.html#02-isatap


◆MULTI6 WG(Site Multihoming in IPv6 WG)

IPv6インターネットに特化したマルチホーム手法を検討するMULTI6 WGは3日の
午前中に開催されました。今回のミーティングで、マルチホーム手法の新規募
集は打ち切り、提案のあったマルチホーム手法をもとにIPv6でのマルチホーミ
ング手法に関する分析を実施し、今後の方向性を明確にすることになっていま
す。新規の提案としておよそ30件ほどのドラフトが寄せられ、ミーティング中
に9件が紹介されています。

また、Geoff Huston氏より、現在提案されている案の整理として、IPv6ホーミ
ング方式アーキテクチャの分析についてのプレゼンテーションがありました。
現在提案されている案は、

・プロトコルスタック間に新たに階層を設ける(ホストの識別子を扱う階層)
・トランスポート層やIP層を改変する
・ホストやルータの動作(パケットフォワーディングの動作など)を変更する
・それ以外(IPv4方式をIPv6へマッピング)

に分類されること、それぞれに共通する課題があることが報告されています。
次回のIETFまでに分析文書を完成し、それをベースにマルチホーミング手法の
標準化を進めることになっています(文書の議論を実施するために中間ミーティ
ングを開催することも予定されています)。

マルチホーミングの問題に関してはIETF全体会議でも取り上げられ、その問題
点や現状の解決案の状況が報告されており、今後の標準化の動向が注目されま
す。
 
□MULTI6 WG
  http://www.ietf.org/html.charters/multi6-charter.html

□59th IETF MULTI6 WGのアジェンダ
  http://www.ietf.org/ietf/04mar/multi6.txt


◆その他

今回、会場ホテルでのIPv6機器の展示、およびNCA(*8)/MIC(*9)のIPv6関連展
示見学ツアーがありました。

ホテルでは、IPv6ライブビデオストリーミングシステムや、SIP電話、IPv6対
応Webカメラ等の展示があり、IPv6対応の機器が実際に動作していることを体
感できました。NCAでは同様の展示に加え、IPv6への移行システムや遠隔監視
システム、情報家電などの展示が行われていました。MICのツアーは、
Ubiquitus Dreamと名付けられた展示ホールの見学でした。展示ホール自体は
まだオープン前で、工事があちこちで行われている状態でしたが、展示物はほ
とんど動作しており、来るべきRFID(*10)や各種情報家電、センサーを組み合
わせたユビキタス社会を、喫茶店、家庭、病院、学校、スーパーを模擬したセッ
トの中で体感できるようになっていました。個々の要素技術自体に特に目新し
いものはありませんでしたが、各コンポーネントがが組み合わさって実社会に
マッピングされているものを一カ所で連続的に体感できるため、非常に印象的
でした。

(*8) NCA:National Computerization Agency
          韓国電算院。コンピュータ技術、通信技術の普及政策を担当
(*9) MIC:Ministry of Information and Communication
          韓国情報通信部。韓国の情報化政策に関する主管官庁
(*10) RFID:Radio Frequency IDentification
            http://www.nic.ad.jp/ja/tech/glos-kz.html#03-RFID


……………………………………………………………………………………………
3. DNS関連WG報告
                                                JPNIC 技術部  上野晶久
……………………………………………………………………………………………

DNS関連WGのミーティングより、ENUM WGについて報告します。


◆ENUM WG(Telephone Number Mapping WG)

ENUM WGでは、まず最初にRFC発行待ちとなっているRFC2916bisの現状報告が
IESGメンバーであるAllison Mankin氏より行われました。「現在はIANAでの処
理を待っている状態だが、IESGからIANAへ審査を依頼しているI-Dは
RFC2916bisだけではないため、RFC発行までにはまだ多少の時間がかかるであ
ろう」とのことでした。

続いて各国のENUMトライアルの現状報告が行われました。日本からも(株)日本
レジストリサービスの藤原和典氏によるETJP(ENUM Traial Japan)の活動報
告が行われ、その中で指摘されていた「RFC2916bisとDDDS RFCs
(RFC3401-3404)の両義性」は会場内でも大きな反響を呼びました。藤原氏が
指摘された問題点は、Lawrence Conroy氏がすでにその他の問題点をまとめて
文書化したI-Dに付加され、正式にENUM WGで採用されることとなりました。

□藤原氏のプレゼンテーション資料
  http://member.wide.ad.jp/~fujiwara/enum/ietf59enum-impl.pdf

□Conroy氏のインターネットドラフト
  http://www.ietf.org/internet-drafts/draft-conroy-enum-experiences-01.txt


……………………………………………………………………………………………
4. セキュリティ関連WG報告
                        JPNIC CAとアプリケーション専門家チームメンバー
                                       富士ゼロックス株式会社 稲田 龍
……………………………………………………………………………………………

ここ数年、セキュリティの確保はインターネットにとって大きな課題となって
おり、各社はさまざまな対策・提案を行ってきました。IETFは、標準化を推進
する立場で活動し、多くのプロトコルに関してセキュリティ面での強化を行っ
ています。

具体的に言えば、ここ数年にわたり初日にはSecurity Tutorialが開催され、
インターネット・プロトコルに対して必要とされるセキュリティ要件に関して
の講義がなされています(後述)。さらに、I-D、RFCに関しては“Security
Consideration”の項目が必須となるなど、インターネットの標準化に関して
セキュリティは必須の要件となっています。

今回のIETFでも、新たにMOBIKE、OPSEC(*11)などの新しいWG・BoFが開催され
インターネットを自由にかつ安全に利用するための提案がなされています。

また、Security AreaのDirectorであるRussell Housley、Steven Bellovinの
両氏は、積極的に多くのWGに参加しコメントを出しセキュリティの重要さを説
いています。非公式にも多くの人間に会い、さまざまな分野に関してセキュリ
ティを推し進めています。

(*11) OPSEC:Operational Security Requirements 
             http://www.ietf.org/ietf/04mar/opsec.txt


◆Security Tutorial

Security Tutorialは2月29日に開催され、参加者は300名程度で満席となりま
した。

SUN Microsystems社のRedia Perlman女史が説明を行いました。Redia女史は、
ARP(*12)の開発者としても知られている人物でIETFの長老(女性に対して長老
とは失礼かもしれませんが)の1人でもあります。

インターネットでなぜセキュリティが重要であるかに関しての解説に始まり、
技術的なコンセプト、守るための個別の技術なども分かりやすく説明し、さら
に暗号技術に関しても詳細に述べていました。
 
暗号に関しては、「勝手に暗号を作るべきではなく、きちんとレビューを受け
たものを使うのが望ましい」というコメントを残していました。セキュリティ
プロトコルは大変難しいので、全部自分でやるのではなく、複数の人間が共同
して行うことが重要とも述べていました。

Security Tutorialで使用されたPowerPoint文書は以下のURLをご参照ください。
 
  http://sec.ietf.org/ietfsectut0304a.ppt

(*12) ARP:Address Resolution Protocol 
           TCP/IPプロトコルにおいて、IPアドレスからEthernetアドレスを
           求めるためのプロトコル


◆ MOBIKE WG(IKEv2 Mobility and Multihoming WG)

MOBIKE WGは3月1日に開催されました。本WGではIPsecで利用されるIKEv2のコ
アプロトコルとは独立に、モバイルでの必要性が高い、ローミングやマルチホー
ミングを検討しています。参加者の関心も非常に高く、200名程度の参加を集
めました。

セッションでは、以下の二つのドラフト説明が行われました。

・Address Management for IKE version 2

モバイル環境で重要となるアドレス管理をIKEに追加する提案であり、I-Dとな
りました。IKEv2でのアドレス管理は、NAT traversalで提案されていますが、
モバイルで問題となる、IPv6でのNAT対応やマルチホーミング対応を補完する
ための別提案としています。

・Design of the MOBIKE protocol

MOBIKEの設計に関する説明で、前回の第58回IETFにおけるBoFでの意見を受け
た修正案の説明です。前回、IKEv2のオプションを使用できることを指摘され
たため、IKEv2を最大限に利用するように変更しました。

□MOBIKE WG
  http://www.ietf.org/html.charters/mobike-charter.html


◆PKI4IPSEC WG(Profiling Use of PKI in IPSEC WG)

PKI4IPSEC WGは3月1日に開催され、参加者は200名ほどでした。

IPsecは、過去5年間以上にわたって標準化が行われてきました。同じ期間、
X.509(*13)証明書の利用についても定められてきました。しかし、証明書を利
用するIPsecの採用事例はほとんどありません。その理由の一つは、X.509証明
書のIPsecにおける利用についての明解な文書の欠如です。また、IPsecシステ
ムについて、証明書の入手等、証明書に関するライフサイクル運用について単
純かつ明解に規定された方法論の欠如も理由と言えます。

今回のIETFでは、WGとしてのチャーターが以下のURL掲載の内容に決まったこ
との報告と、現行のdraft-ietf-ipsec-pki-profile-04.txtに関しての議論が
行われました。

□PKI4IPSEC WG
  http://www.ietf.org/html.charters/pki4ipsec-charter.html

(*13) X.509:ITU Recommendation X.509
             http://www.nic.ad.jp/ja/tech/glos-kz.html#03-x.509


◆PKIX WG(Public-Key Infrastructure (X.509) WG)

PKIX WGは3月1日に開催され、49名が参加しました。チェアの1人であるTim
Polk氏が脊椎捻挫のため出席せず、BBNのStephen Kent氏がミーティングを仕
切っていました。

WGのミーティングは通常の通りにドキュメントステータスより始まり、粛々と
議題をこなし議論としては低調なものとなりました。しかしながら、内容とし
てはQualified CertificateのRFC化が進み、Proxy CertificateはRFC化が決ま
るなど多くの面で進展が見られました。米国外でのIETFであるため多くの常連
となるメンバーが出席しない状況であり、オフラインでのミーティングは低調
な印象を受けましたが、WGとしてのミッションは確実に消化しつつあるように
感じました。

また、IESGからの要請によりPKIX WGは終息のフェイズにあります。今後はPKI 
のインターネットでの応用範囲を広げるべくさまざまなBoF・WGが開かれると
考えられます。例えば、IPsecでのPKIの応用とプロファイルの策定を意図した
PKI4IPSECもその一例です。PKI4IPSECは前回の第58回IETFではBoFとして開催
されましたが、今回はWGとして開催されました。

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


◆LTANS WG(Long-Term Archive and Notary Services WG)

LTANS WGは3月4日に開催され、40名程度が参加しました。

LTANS-WGは、セキュアなデータのアーカイブと公証サービスのためのデータ構
造とプロトコルを決めることを目的とするWGであり、前回の第58回IETFにて設
立されました。

現状二つのI-Dが提案されていますが、まだStandard TrackのRFCはありません。
セッションでは、これらのI-D(Requiments/Evidence Record Syntax)に関し
ての議論が行なわれました。
 
□LTANS WG
  http://www.ietf.org/html.charters/ltans-charter.html


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 2 】トピックス
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

……………………………………………………………………………………………
1. ICANNローマ会議速報
                                      JPNIC ドメイン名事業部  入交尚子
……………………………………………………………………………………………

2004年3月2日から6日まで、古都ローマにてICANN会議が開催されました。以下
では、最終日に行われた理事会での決議事項の中から主なものをご紹介します。


◆VeriSignによるWait Listing Service(WLS)導入提案

Wait Listing Service(WLS)とは、VeriSignが以前から導入を提案している
ドメイン名の予約サービスのことで、希望する.com/.netドメイン名が既に他
者によって登録されている場合、レジストラを通して予約を行うことで、その
ドメイン名が削除され次第直ちに登録できるようにするというものです。

ドメイン名の予約については、すでに複数のレジストラがそれぞれ個別のサー
ビスを提供していますが、レジストラレベルで提供される予約サービスの場合、
レジストリによって削除され、誰もが登録可能なオープンな状態になったドメ
イン名を各レジストラが競って獲得しようとするため、顧客は一つのレジスト
ラを通してドメイン名の予約をしたとしても、確実にそのドメイン名を入手で
きる保証はありません。

一方、VeriSignが提案するWLSは、レジストリレベルで単一の予約リストを管
理するため、複数のレジストラ間で予約が重複するという事態が発生せず、顧
客は100%の確率で予約したドメイン名を入手できるようになります。

しかし、こうしたサービスがレジストリレベルで導入されると、健全な競争環
境が阻害され、レジストリによる不当な独占状態を招くとして、複数のレジス
トラやリセラがWLS導入への反対運動を起こしており、一部では訴訟も発生し
ています。

ICANNでは、こうしたコミュニティの反応も考慮の上、2002年8月に条件付きで
WLSの導入を承認しましたが、以降、この条件の中身についてICANNとVeriSign 
との間で交渉が繰り返され、これまで未解決の状態が続いていました。

今回のローマ会議では、2日間にわたるPublic Forumで、WLSに関して賛成・反
対の表明を行うレジストラが続出し、また、会場ロビーで「WLS反対」のステッ
カーを参加者に配布するグループも見受けられるなど、この問題についての関
心の高さがうかがえました。

最終日の理事会では、ICANN-VeriSign間での最終的な交渉結果が承認され、今
後は、WLSの実施に向けて、.com/.netレジストリ契約改定の承認を米国商務省
に対して要請することになります。


◆国コードドメイン名支持組織(ccNSO)の結成

ICANN改革の議論の結果、新たに設立されることになった国コードドメイン名
支持組織(ccNSO)は、30名のccTLD管理者(世界5地域それぞれから4名以上)
が参加した時点で結成されるという規定により、その結成にまで至っていませ
んでした。

2004年3月1日、これまでccNSO結成に向けて活動してきたccNSO立ち上げグルー
プより、30名を超えるccTLD管理者の参加をもってccNSOが結成された旨の発表
があったことから、今回の理事会でccNSO結成の承認が決議されました。

ccNSOでは、これよりccNSO評議会メンバーの選出に取り組むことになり、次回
7月のクアラルンプール会議までに作業を終えることが期待されています。


◆.netの後継レジストリ指名プロセスの開始

現在、ICANNとVeriSignとの間で締結されている.netレジストリ契約の有効期
限が2005年6月30日で終了することから、ICANNは、契約終了の1年前(2004年6
月30日)までに.netの後継レジストリを指名する必要があります。

今回の理事会決議により、後継レジストリ指名のためのプロセスが事務総長に
よって開始されることになりました。

                  ◇              ◇              ◇

なお、ICANNローマ会議については、「第9回ICANN報告会」にて詳細を報告い
たします。日程等は追ってJPNICのWebページ等でご連絡しますので、ご興味の
ある方はぜひご参加ください。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 3 】News & Views Column 「社会インフラとしてのインターネット」
                                         JPNIC IRR専門家チームメンバー
                                                      日本テレコム(株)
                                                              松本順一
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

私が学生時代(1996年くらい)、大学で初めてインターネットというものを知
りました。まだアナログ回線でのダイアルアップ形式で、定額電話としてNTT 
のテレホーダイサービスが始まったころです。夜11時少し前からパソコンの前
に座り、加入者数より明らかに少ないダイアルアップ先に何度も繋がるまで電
話をかけていたものです。

当時はインターネットといえばつながらない、突然切れる、何をするにも時間
がかかる、さらにお金もかかる……と散々な状況でした。利用者も、好奇心旺
盛な人やゲーム好きな人、学術系の人等、少し偏った人々だったと感じていま
す。そんなインターネットもブロードバンド時代に突入し、すっかり市民権を
得ました。もう「うちに帰ってインターネットする」とみんなに言っても恥ず
かしくありません。老若男女、どの世代にもある程度浸透しているようになり
ました。

インターネットは「一般家庭で情報を得る・発信するメディア」と考えた場合、
同様の物は何があるでしょう。新聞、ラジオ、テレビ、ビデオ、電話ですよね。
これらすべてがインターネットの上で実現されようとしています。新聞は毎朝
必ず店頭に並んでいます。電話は、火事や救急の際にも利用され、日本全国ほ
とんどの地域で提供される信頼性・完成度の高い社会インフラです。テレビは
受信地域やアンテナの方向により画質が落ちたりもします。ラジオも同様です。
これらがすべてインターネット上で実現される時……どのレベルの品質が求め
られるのでしょうか?

以前から、日本の物は精密で正確、高品質というイメージがありました。第二
次世界大戦中、ムッソリーニがドイツに行き「電車の到着時間が正確なことに
驚いた」そうですが、精密・正確なものが当然でない文化の人にとっては、正
確であることは驚きに値するようです。日本の場合、ドイツ同様正確が当然の
文化なので、もちろんきっちりとこだわりを持った高品質の物が求められるで
しょう。「常に使えて当然」「綺麗に見れて当然」「安全が確保されていて当
然」「簡単に使えて当然」と考える方が多いと思っています。インターネット
もそうなるでしょう。

ですが、インターネットのインフラはまだその域には完全には達していません。
元々限られた人々が始め、それがなし崩し的に(という表現が適切か判りませ
んが)広がったものであるインターネットは、そのような設計思想を持ちませ
んでした。電話やテレビを提供する装置に比べインターネットを提供する機器
の安定性は不十分ですし、安定性を確保するプロトコルも改良されているとは
言え5年前から大きくは変わりません。また、それを運用する立場の人も急激
な要求レベルの変化に戸惑いを感じている方が多いでしょう。

「そもそもすべてをインターネットで提供することが正しいの?」という疑問
もあります。ですが、今インターネットが社会のインフラとして日本で定着し
ようとする大きな波が来ているのかもしれません。私はインターネット社会の
一員として、またサービス提供者の立場からも「安全で高品質なインターネッ
ト」が普及し、その上でさまざまなサービスが高いレベルで利用されるように
なれば良いと考え、また努力していきたいと考えています。


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 4 】インターネット用語1分解説  「正引き/逆引きとは」
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

DNS(*1)の主なサービスはホスト名(ドメイン名)とIPアドレスを対応づける
ことです。DNSを用いて、www.nic.ad.jpのように表されるホスト名から、
202.12.30.144のように表されるIPアドレスを解決することを正引きと呼んで
います。インターネットに接続されているコンピュータ同士は、IPアドレスを
使って通信をしていますが、この正引きの仕組みによって、ユーザはIPアドレ
スを意識することなく、より覚えやすいホスト名によって、インターネット上
の各サービスを利用することができます。

正引きとは反対に、202.12.30.144で表されるIPアドレスから、www.nic.ad.jp
というホスト名を解決することを逆引きと呼びます。逆引きは、正引きとの組
み合わせによってデータ送信者の識別の正確性を高める働きをもっています。

(*1) DNS:Domain Name System
          http://www.nic.ad.jp/ja/basics/beginners/dns.html


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 5 】統計資料
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

1. JPドメイン名

o 登録ドメイン数(2003年10月~2004年3月) 
-------------------------------------------------------------------------------
日付|JP AD  AC    CO    GO   OR    NE    GR   ED   LG  GEO   GA    GJ   TOTAL
-------------------------------------------------------------------------------
10/1|0 321 3012 245805 815 17813 17536 9813 4262 1292 4217 187040 45615 537541
11/1|0 321 3020 246664 812 17932 17482 9771 4293 1595 4229 192147 45588 543854
12/1|0 319 3026 247784 810 18040 17469 9752 4312 1781 4238 196777 45485 549793
 1/1|0 318 3035 248923 813 18160 17441 9709 4332 2228 4234 199698 45402 554293
 2/1|0 316 3044 250295 814 18269 17448 9659 4343 2611 4245 204166 45374 560584
 3/1|0 316 3051 251543 821 18405 17433 9614 4358 2824 4260 209103 45286 567014
-------------------------------------------------------------------------------

 GA:汎用ドメイン名 ASCII(英数字)
 GJ:汎用ドメイン名 日本語 


2.IPアドレス

o APNICからの割り振り/返却ホスト数(2003年9月~2004年2月)
 ---------------------------------------
  月 | 割り振り |   返却   | 現在の総量 
 ---------------------------------------
   9 |   851968 |        0 |   25493504
  10 |   851968 |        0 |   26345472
  11 |   786432 |        0 |   27131904
  12 |   851968 |        0 |   27983872
   1 |   589824 |        0 |   28573696
   2 |   655360 |        0 |   29229056
 ---------------------------------------

□統計情報に関する詳細は → http://www.nic.ad.jp/ja/stat/


3.会員数  ※2004年3月11日 現在

 --------------------
  会員分類 | 会員数 |
 --------------------
  S会員    |      4 |
  A会員    |      2 |
  B会員    |      8 |
  C会員    |      4 |
  D会員    |    206 |
  個人推薦 |     48 |
  賛助会員 |     46 |
 --------------------
  合計     |    318 |
 --------------------

□会員についての詳細は → http://www.nic.ad.jp/ja/member/list/


4. 指定事業者数  ※2004年3月10日 現在

  IPアドレス管理指定事業者数          366


━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
【 6 】イベントカレンダー 
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

  2004.3.22(月)              第12回IPアドレス管理指定事業者連絡会
                             (東京、大手町サンケイプラザ) 
  2004.3.29(月)              第45回臨時理事会 
  2004.3.29(月)~4.1(木)     LACNIC VI (Montevideo, Uruguay)
  --------------------------------------------------------------------
  2004.4.12(月)~14(水)      Global IPv6 Summit in China 2004 
                             (Beijing, China) 
  2004.4.18(日)~21(水)      ARIN XIII (Vancouver, BC, Canada) 
  2004.4                     第9回ICANN報告会 (予定)
  --------------------------------------------------------------------
  2004.5.3(月)~7(金)        RIPE 48 (Amsterdam, Netherlands) 
  2004.5.10(月)~14(金)      INET/IGC 2004 (Barcelona, Spain) 
  2004.5.14(金)              第46回通常理事会

___________________________________
 ■■■■■ JPNICの活動はJPNIC会員によって支えられています ■■■■■
  :::::  会員リスト  :::::   http://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト ::::   http://www.nic.ad.jp/member/(PASSWORD有)
 ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄
===================================
 JPNIC News & Views vol.159 【定期号】 

 @ 発行         社団法人 日本ネットワークインフォメーションセンター
                 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

このページを評価してください

このWebページは役に立ちましたか?
よろしければ回答の理由をご記入ください

それ以外にも、ページの改良点等がございましたら自由にご記入ください。

回答が必要な場合は、お問い合わせ先をご利用ください。

ロゴ:JPNIC

Copyright© 1996-2024 Japan Network Information Center. All Rights Reserved.