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

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

ロゴ:JPNIC

WHOIS 検索 サイト内検索 WHOISとは？ ｜ JPNIC WHOIS Gateway

よく検索されるキーワード

IPv6 DNS HTTP WHOIS BGP IPv4 ドメイン名とは IPアドレス FQDN インターネット
ロゴ:JPNIC
WHOIS検索 サイト内検索

よく検索されるキーワード

"Toward a Statement of the ICANN Mission"
翻訳文

(社)日本ネットワークインフォメーションセンター
最終更新 2002年 4月 9日

この文書は2002年3月7日に公開された
http://www.icann.org/general/toward-mission-statement-07mar02.htm
を翻訳したものです。

ICANNの使命に関して

公開：2002年3月 7日
改訂：2002年3月10日

　注：ICANN改革についての議論が進行する中、 ICANNの使命についても目を向けることは有益です。 ICANNの使命とは何なのか、そして、 ICANNは何に向かって進んでいくのかについての合意がない限り、 ICANNの構造や手続について合意に達することは困難です。

　今日まで、 ICANNの使命が技術的調整のみに限定されていたわけではないということは、 極めて明らかです。 明白な例を挙げると、競争の促進は技術的目標ではありませんが、 ICANN設立当初から、その使命の重要な部分を占めてきています。 とは言うものの、ICANNの使命は無制限なものとはなり得ません。 使命の境界についての同意がなければ、 ICANNは焦点を見失う危険を冒すことになります。 したがって、 インターネットのネーミングとアドレス割り振りシステムとして適切に機能するために、 どのような種類のグローバルな調整活動が必要とされているか、 もしくは極めて望ましいかということについて、 共通の一般的理解を形成することが、 そしてそれが正当にICANNの使命に含まれることが、 現在行なわれているICANN改革の取り組みにおいて、 重要な要素となるのです。

　この文書は、 ICANNが今日行なっている最も重要な諸活動について列挙することで、 そういった議論を開始するきっかけを与えようというものです。 これは、完全なリストとして作成されたものでもなければ、 ある特定の機構あるいは使命を擁護するために作成されたものでもなく、 単に現状を記述したものです。 これからICANNが進んでいく上で（もしあるとすれば）どのような変更（追加もしくは削除）を行なうことが適切か、また、 議論の結果出された境界をどうすれば最大限明確に示すことができるかといった実質的討論を、 現状を記したこの文書によって促進することができるよう願っています。 それは翻って、 ICANNがその使命を効果的に遂行するための最適な構造や手続に関する改革の本質についてのコミュニティでの議論に対して大きな貢献となるでしょう。

ICANNの活動について

スタッフ作成ドラフト：Ver.1.1、2002年3月10日

概要

　The Internet Corporation for Assigned Names and Numbers (ICANN) は、インターネットのネーミング、アドレス割り振り、 プロトコル・パラメーターの割り当ての各システムの調整をその責務としています。 これらのシステムは、インターネットとそのユーザーの利益のために、 グローバルで一意の、 そして普遍的に相互運用性のある識別子を可能なものとしています。

　これらのシステムは、高度に分散化されています。 世界中の何百ものレジストリやレジストラ、その他の組織が、 インターネットのネーミングとアドレス割り振りサービスを提供する上で、 重要な役割を果たしています。 ICANNの最大の関心事は、 これらの非常に堅固なサービスの安定性です。

　インターネットの識別子を一意に割り当てるシステムの総合調整役として、 ICANNの役割には、それが限定的に定義されているとはいえ、 運用機能とポリシー策定機能の両方が含まれています。

運用業務

　運用業務の範囲では、ICANNスタッフは、 以下を含め様々な日常業務を行なっています。

  1. DNSルートゾーンファイルの維持
  2. 地域インターネット・レジストリへのIPv4、IPv6アドレス最上位ブロック、及び、AS番号の割り振り
  3. 120以上のプロトコルポート番号及びパラメーター番号のレジストリの維持
  4. DNSルートゾーンファイルに含まれるトップレベルドメイン・レジストリに関する情報のオンラインデータベースによる公開
  5. 13の権威あるDNSルートネームサーバーのうちの1つを運用、及び、DNSルートネームサーバー・システム全体の調整
  6. InterNICウェブサイトの公開、及び、関連業務
  7. .intレジストリの運営
  8. プライベートアドレス空間などの、共有／専門のIPアドレス空間の維持
  9. 逆引き名前空間のトップレベルにおける管理
  10. .arpaや古いインフラ関連の.intゾーンなどの特定の専門レジストリのDNS実装の管理

　さらに、ICANNスタッフは、 分野別トップレベルドメイン（gTLD）に関し、 以下を含めた一連の日常管理業務やポリシー業務を行なっています。

  1. 競争的なレジストラの認定
  2. 統一ドメイン名紛争処理方針（UDRP）運用の監督
  3. 登録に関する苦情の処理
  4. レジストリ契約及びレジストラ契約の監視と履行
  5. データエスクロー・プログラムの実施

　国コードトップレベルドメイン（ccTLD）レジストリに対しては、 ICANNスタッフは、委任・再委任の要請、及び、 ルートゾーンファイルに設定されるTLDネームサーバーの変更について、 対応、調査、処理を行なっています。

セキュリティ

　ICANNは、 機能するDNSを構成するインフラストラクチャの各部分のセキュリティに関し、 ポリシー調整を行なう責務を負っています。 この活動は、最近、 セキュリティと安定性に関する常設委員会が設置されたことに反映されています。 さらにICANNは、その運用業務に関し、 運用上のセキュリティに対する責務を負っています。 そして、DNSに関わるすべての人々が、 セキュリティと安定性の問題について、 継続的かつ真剣に注目を払うよう、促進・奨励に努めています。 また、ある一部の責任ある関係者達によって必要な作業が遂行されることを確実なものとするよう努めています。

ポリシー策定

　ポリシー策定業務の範囲では、ICANNは、 各運用業務に関するポリシーの策定・実施に対し、責任があります。 ICANNのポリシー策定の役割は、 各業務によりその性質や範囲が異なります。

　例えば、IPアドレスとAS番号割り振りの分野では、 ICANNの責務の範囲はグローバルなアドレス管理ポリシーに限定されます。 ローカルポリシーについては、各地域インターネット・レジストリか、 あるいはより下位のインターネット・レジストリによって決定されます。 国コードトップレベルドメイン・レジストリ（ccTLDs）に対するICANNのポリシーの役割も、 同様にグローバルポリシーの調整に限定され、ICANNは、 各地域インターネットコミュニティが、 それぞれのレジストリレベルのポリシー（登録要件、価格、紛争処理、 地域コミュニティによる参加とポリシー決定の仕組みなど）を策定するという責務を尊重します。 プロトコル番号の分野では、ICANNは、Internet Engineering Task Force (IETF)の指示に従い、IANAレジストリを運用しています。

　それに対して、.com、.net、.org、.info、.name、.bizといった、 グローバルなトップレベルドメイン・レジストリ（gTLDs）については、 レジストリレベルのポリシー策定にあたって、 より直接的かつ重要な役割を果たしています。 ICANNは事実上、gTLDレジストリにとっての、 グローバルなインターネットコミュニティのオープンなポリシー策定フォーラムとしての機能を果たしています。

　1998年発表のホワイトペーパーの中に具体的に書かれている通り、 米国政府からの最初の指示によると、 ICANNがポリシー策定を行なう際には、 技術面以外の一連の原則に従うこととされていました。 つまり、安定性の維持、競争の促進、 インターネットの機能上・地理上の多様性を反映する民間セクターによるボトムアップ的な参加の仕組みが使えるところではそれに基づくこと、 （gTLDレジストリのための）効率的な紛争処理手段の策定、そして、 （全レジストリに対しての）運用管理に対するアカウンタビリティ（説明責任）の助長です。

　これらの原則は、必然的に、やや一般的であり、 ICANNのポリシー策定の使命について、正確な境界を規定する上で、 混乱や意見の相違を引き起こしてきています。 このため、急速に変化するインターネットの性質にうまく対応するために必要な柔軟性を考慮した上で、これらの境界を、 可能な限り詳細に記述し直すべきだという提案も出てきました。 このような取り組みは、 ICANNとインターネットコミュニティ全体の両方に対して有益な指針を生み出す限りにおいては、 現在行なわれているICANN改革の議論にとって、 間違いなく役立つものとなるでしょう。

　用語注：上記の運用業務のほとんどは、これまでの歴史において、 Internet Assigned Numbers Authority (IANA)の名の下で行われてきました。 IANAは、南カリフォルニア大学の情報科学研究所（ISI）の1チームによって運営されていましたが、その機能は、 IETFと米国政府の2つからの指示に基づいて遂行されていました。 ICANNは現在、米国政府との契約とIETFとの覚書に従い、 IANAのすべての機能に対して責任を負っています。 従って、IANAは一連の機能のことを意味し、ICANNは、 グローバルなインターネットコミュニティの利益のためにIANA機能を遂行するよう、 米国政府とIETFそれぞれから指名された組織を意味する、 ということに留意する必要があります。

　以下の項では、ICANNの責務と活動について、 より詳細に説明していきます。

I.名前

　運用レベルでは、 ICANNのインターネットのネーミングに関する責務は、 DNSルートゾーンファイルと、 DNSルートネームサーバー・システムの2つの機能を中心としています。

A.DNSルートゾーンファイル

　DNSルートゾーンファイルは、 権威ある公共のDNSに置かれるすべてのトップレベルドメイン（現在は259TLD）のリストから構成され、 そこには各TLDにとって権威のあるプライマリおよびセカンダリネームサーバーの名前とIPアドレスが並べられます。 IANA機能の一部として、ICANNは、 DNSルートゾーンファイルの内容を決める責任を負っています。 これは、 認められたTLDと各TLDのネームサーバーのリストを維持・更新することを意味します。 ICANNはまた、13の権威あるルートネームサーバーによってこのファイルの内容を一般に伝播させることの責任も負っています。

　ルートゾーンファイルに関するポリシー業務は、 それを維持するために必要な3つの基本的運用業務に該当します。 つまり、TLDの委任、TLDの再委任、 そしてTLDネームサーバーの変更です。 これらの業務に対するICANNの責任範囲は、 分野別TLD（gTLD）と国コードTLD（ccTLD）とで異なり、 また、正式なレジストリ契約の条件によっても違ってきます。

　現在のICANNと米国政府との関係の下では、TLDの委任、再委任、 ネームサーバー変更の要請すべてにおいて、 最終的に米国政府の承認が必要となります。 従って、今のところ、これに関するICANNの役割は、 DNSルートゾーンファイルの運用管理責任を持つ米国商務省に対し、 その変更を勧告することに限定されています。

1.gTLDの委任

　「委任」という用語は、DNSに新しいTLDを追加することを指します。 狭義の技術用語では、新しいTLDが、 その権威あるネームサーバーの名前とIPアドレスとともに、 DNSルートゾーンファイルに追加されることを意味します。 新しいgTLDの追加は、 米国政府のホワイトペーパーによって具体的に課せられたポリシー目標の1つです。 ICANNは2000年11月に、第一のグループとして、 7つの多様な新gTLD（.info、.biz、.name、.pro、.aero、.museum、.coop）を、 コンセプトの検証としてDNSに追加するべく選定しました。

　新gTLDの委任に必要なポリシー業務としては、申請募集の準備、 選定基準の定義、この基準に照らした上での申請の審査、 一般もしくは専門家から寄せられた意見の分析、 レジストリおよびレジストリ運用業者の選定、 レジストリ契約の交渉（必要に応じ、 レジストリポリシーについての書類調査を含む。 レジストリポリシーとは、料金、レジストラ間競争、紛争処理、 データエスクロー、Whoisサービスなどについてのもの。）があります。

　新TLDがスタートした後、ICANNは、レジストリ契約の監視と履行、 データエスクロー要件の実施、そしてほとんどの場合、 レジストラ認定プログラムの管理について責務を負うことになります。

2.gTLDの再委任

　「再委任」という用語は、 あるgTLDのスポンサ組織あるいは管理者を、 別のスポンサ組織あるいは管理者へ変更することを指します。 新たなgTLDが創設されると、 以下のいずれかの場合に再委任の可能性が生じることになります。 つまり、 (a)スポンサ組織あるいは管理者が、 自らレジストリ業務の放棄を選択した場合、 (b)スポンサ組織あるいは管理者が、 ICANNとのレジストリ契約に違反した場合、 そして、(c)現行のレジストリ契約期間が終了した場合です。

　例えば、.org TLDのレジストリ契約では、 現在の運用者への委任期間が2002年12月31日までに終了するということを要求しています。 従ってICANNは、 先に述べたような委任手続と同様の基本要素を網羅した、 再委任手続を行なわなければなりません。

3.gTLDネームサーバーの変更

　TLDレジストリは、場合によって、 1つかそれ以上の既存のTLDネームサーバーを変更することがあります。 例えば、gTLDネームサーバーをあるISPから別のISPへ変更することがあるかもしれませんし、あるいは、 新たなネームサーバーを追加する、 もしくは既存のネームサーバーを交換することによって、 名前解決の機能全体を改善させるという決定をするかもしれません。 こういった変更は、IANAへの変更要請を伴い、続いて、 所定のレジストリ契約の条件やそれに関連する技術的な考慮点に従って検証と実行の手続が進められます。

4.gTLD契約の監視、履行、実施

　ICANNは、競争的レジストラの認定や、 データエスクロー・プログラムの実施、そして、 統一ドメイン名紛争処理方針（UDRP）の管理などを含む運用業務と合わせて、 gTLDレジストリ契約の監視と履行に対して責任があります。 登録認定とデータエスクローのための正式契約が存在する場合は、 ICANNに預託されたレジストリデータが完全であり、 正しい技術書式において作成されたものであるかを検証するなど、 関連する運用業務を行なうことに加え、 それらの契約の監視と履行も行なわなければなりません。

　監視と履行の一環として、ICANNスタッフは、 レジストリやレジストラについての苦情処理を行っています。 このようにして契約の中に具体的に書かれているポリシーが適正に実行されることを確実にしようとしています （例えば、レジストラは無料でオンライン問い合わせができるWhoisサービスを提供するという要件など。 このWhoisサービスは、 gTLDドメイン名登録者の連絡先情報を提供）。

　ICANNは、gTLDに適用される紛争処理方針の管理について、 いくつかの関連業務を行なっています。 ICANNはこれらのgTLDと、統一ドメイン名紛争処理方針（UDRP）、 サンライズポリシー、そしてチャーター実施の仕組みなどについて、 書面による契約を結んでいます。 例えばUDRPは、 不正で悪意のあるサイバースクワッティングの申し立てを処理するために、 義務的で非拘束的で裁判外の比較的安価なシステムを提供しています。 ICANNの責務には、紛争処理機関の認定や、 審理手続に関するマスターデータベースの維持なども含まれます。

5.国際化ドメイン名

　インターネットが世界のより広い範囲で利用できるようになり、 英語を話さない人々による利用が増加するにつれて、 機能する国際化ドメイン名のシステムに対するニーズも増加しています。 これは、技術面とポリシー面の両方の問題を抱えています。 技術面の問題は極めて複雑であり、このためIETFでは、 実用可能な技術の標準を確立すべく、熱心な活動が行なわれています。 ポリシー面の問題も同様に複雑であり、その複雑さについては、 ICANNウェブサイトに掲載されているICANN国際化ドメイン名委員会による報告書に例示されている通りです。

6.ccTLDの委任

　ICANNは、国コードTLDについては、ccTLDの委任、ccTLDの再委任、 ccTLDネームサーバー変更といったDNSゾーンファイルの管理業務、 および、ccTLDレジストリ契約の履行（契約が完了した場合）に対して責任があります。 ccTLDに対するICANNのポリシーについてはICP-1に記述されています。 ICP-1は、TLDの構造と委任についてのIANAの基本的な原則と方針を記した1994年発行の文書であるRFC1591を現行の運用内容に更新したものです。

　「国コードTLD」という用語は、 このカテゴリーにおける2文字のTLDのいくつかが国を表すものではないため、 実際は若干誤った名称となっています。 具体的には、 この用語はISO3166-1表に基づき作られたTLDのことを指しています。 ISO3166-1表は、国および地理的に区別可能な領域に、 それぞれ2文字と3文字のユニークな略語を割り当てた国際標準化機構（ISO）によるリストです。 より正確な用語にするなら、「地域別TLD」となるでしょう。 なぜなら、この種類のTLDは、 明確な地理的単位に関連づけて定義されているからです。 ISO3166-1表は、 世界の銀行システムや金融市場における通貨の略称から、 自動車の後部に取り付ける生産国を示すステッカーに至るまで、 さまざまな用途に広く使われています。 ICANNは、ある地理的領域の国が存在するかどうかという点と、 もし存在するのであれば、 そのTLDラベルとしてどのような2文字コードが使われるべきかという点についての判断をISO3166-1表で行っています。 この標準に従うことによって、ICANN自身は、 どれが国でありどれが国でないか （もしくは、どれが地理的に区別可能な領域であり、 どれがそうでないか）を判断する立場に立たないようにし、 この問題については、 政治的に認められた専門機関に任せるようにしています。

　今日までに、245のccTLDが委任されており、 まだ委任されていないコードを2つ残すのみとなっています。 従って、現時点では、ICANNのccTLD委任に対する責務については、 わずかな日常業務が必要とされるのみです。 現在まだ委任されていないコードは、 ISO3166維持管理機関によって将来追加される新たなコードも含めて、 ICP-1およびRFC1591に規定されている条件に基づき、 委任可能な状態です。 これらの文書では、新たにccTLD管理者として申請する者は、 技術能力や、 サービス対象となる国もしくは領域の地域インターネット・コミュニティからの支持、 そして、ccTLDのコンセプトの中心を成すコミュニティへのサービスと信任を受ける者としての責務を引き受けるとの公約を提示証明することが必要とされています。

7.ccTLDの再委任

　ccTLD委任の問題よりもはるかに一般的な問題は、 既に委任を受けたccTLDレジストリからの、 ICANNへの再委任の要請です。 再委任要請は、委任要請と同様の基本条件に基づいて判断され、 技術能力や、地域インターネット・コミュニティからの支持、そして、 ccTLDとして信任を受けた者の本来の職責である、 基本的な公共サービスの責務を引き受けるという公約に焦点が当てられます。

　ICANNスタッフがccTLDの再委任要請を処理する際には、 その理由が明白でない場合もあり、 多大な労力が必要とされます。 場合によっては、 現在のccTLD管理者からの全面的な支持を得た上で要請がなされることもありますが、 より多くの場合、現在のccTLD管理者が知らないままに、 もしくは、現在の管理者が公然と反対している状態で要請が提出されています。 あらゆる要請も、ICANNが公開している基準に沿って、 調査および評価されなければなりません。 ICANNは、ICP-1に基づき、 一般的に現在のccTLD管理者からの協力があった場合にのみ、 再委任を行なっています。 現在の管理者が再委任要請に反対する場合には、 IANAのポリシーに基づき、 両者が相互に合意できる解決策が見つかるまで、 地域インターネット・コミュニティと共に、 両者が協力的な対話を行なうよう要求します。 解決困難な紛争が生じる場合か、 もしくは現在の管理者によって技術的障害が繰り返される場合にのみ、 IANAによって不随意的な再委任が行なわれます。

　すべての再委任要請に対し、IANAポリシーは、 利害関係者や関係機関（政府も含むが政府に限ることなく）からの意見を求め、 地域インターネット・コミュニティの見解について審査を行ないます。 この調査および審査業務は、極度にスタッフに集中するため、 再委任要請の手続の大幅な遅れにつながることがあります。 ICANNは主要な再委任について、その要請内容や背景、調査の結果、 そして結論について記述したIANA報告書を発表します。

8.ccTLDネームサーバーの変更

　ICANNは、 ccTLDネームサーバー変更の要請を処理する責務を負っています。 再委任要請の場合と同様に、TLDネームサーバーの変更には、 驚くほどのスタッフの時間とリソースが必要となります。 ccTLD管理者が、 DNSルートゾーンファイルに設定されている権威あるプライマリもしくはセカンダリネームサーバーのうち、 1つあるいはそれ以上を変更したい場合は、 常にネームサーバー変更テンプレートをICANNに提出しなければなりません。 ICANNは、その要請が完全なものであるかを点検し、その変更要請が、 TLDネームサーバーについての公開された標準に一致しているということを確実にします。 公開された標準には、 一ヶ所の障害によってすべてが機能不全となる可能性を最小限に抑えるために、 セカンダリをインターネット上に分散配置するという要件などがあります。 それから、その要請が、 ccTLDの無断の乗っ取りや内密での再委任にあたるものではないことを確認するために、 ICANNは、委任された事務連絡担当者および技術連絡担当者と共に、 要請の検証を行ないます。 要請が検証されると、ICANNは、 新しいネームサーバーが適切に機能しているかのテストを行ない、 当該ccTLDの更新されたネームサーバー情報を含む形で、 DNSルートゾーンファイルの内容を伝播させるようにします。

9.IANA TLDデータベース

　ICANNは、 各ccTLDおよびgTLDレジストリの連絡担当者情報が記載されているオンラインIANAデータベースを維持管理しています。 IANAデータベースには、 スポンサ組織（当該ccTLDの指定された「受託者」）の身元情報や、 委任された事務連絡担当者および技術連絡担当者の名前、住所、 電子メールアドレス、電話番号、ファックス番号、そして、 ドメイン名登録関連情報のためのURLも記載されています。 IANA TLDデータベースは、オンラインのウェブ・インデックスや、 43番ポートまたは80番ポートのWhois問い合わせで利用することができます。 ICANNは、ICP-1やRFC1591に記載されているIANA手続に違反するような、 無断の乗っ取りや内密での再委任を防止するために、 このデータベース情報の変更要請については、 慎重に調査・検証を行ないます。

B.DNSルートネームサーバー・システム

　ICANNは、 DNSルートネームサーバー・システムが安定的に機能するよう調整する責務を負っています。 DNS問い合わせの最上位での解決について、DNSは、 13台の地理的に分散配置されたルートネームサーバー（これらはアルファベットの文字により識別）に依存しています。 12人のルートネームサーバー運用者がおり、大学、軍の機関、 民間企業、非営利組織（ICANNのような）と多岐にわたっています。 ルートネームサーバー運用者全員が独立したボランティアであり、 そのサービスに対して、外部から一切の報酬を受け取っていません。 ICANNは、このシステムの全般的調整に対して責任があり、 それには、 運用や事故の対応に関する日常のコミュニケーションも含まれます。 ルートネームサーバー運用者と外部から招かれた専門家によって構成されるルートサーバーシステム諮問委員会（RSSAC）を通して、 ICANNは、例えばルートネームサーバー運用者の分散化、配置場所、 アイデンティティといった事柄に関するポリシーの策定および実施に対しても、 責任を負っています。

　ルートネームサーバー運用者との協力関係のもと、ICANNは、 DNSルートネームサーバーの全面的改良を目的とした研究、測定、 実験計画にも参加しています。 例えば、計画および実装実験が完了した時点で、 ICANNはプライマリ機能に特化したルートネームサーバーを運用することになります。 これは著しいセキュリティの改善であり、これによって、 公共のDNS問い合わせの処理も行ない、かつ、 権威あるルートゾーンファイルの提供も行なう1台のマシンに、 他のルートネームサーバーが依存する必要性をなくすることになります。

C.L ルートネームサーバー

　ICANNは、 13台の権威あるDNSルートネームサーバーのうちの1台であるLルートネームサーバーの運用者です。 この責務ついては現在完全に遂行しており、必要となる技術スタッフ、 ハードウェア、帯域幅を維持するために、 相当量のリソースの割り当てを行っています。

D.InterNICサービス

　ICANNは、 InterNICのサービスマークにより指定されている一連のインターネットサービスに対して責任があります。 これらのサービスには、 www.internic.net のウェブサイトも含まれており、 認定レジストラのリストや、紛争処理についてのQ&Aといった、 gTLDレジストリに関する情報提供を行なっています。

E..intレジストリ

　ICANNは現在、国際条約に基づき設立された組織向けの、 .int TLDのレジストリを運営しています。 .intレジストリは、歴史的に、 .ip6.intといった国際的なインターネットインフラストラクチャ関連向けにも使用されており、 .ip6.intは一時は、 IPv6アドレスの逆引き委任ツリーの場所として指定されていました。 ICANNは、IETFとの協力のもと、 インフラストラクチャ関連のドメインを、 .intからより適切なTLDへと移行させるよう取り組んでいます。 例えば新たな.ip6.arpaなどがそうです。

II.アドレス

　ICANNは、 認知されている地域インターネット・レジストリ（RIR）に対し、 IPv4およびIPv6アドレスの最上位ブロックと、 自律システム（AS）番号ブロックの、 グローバルな割り振りを行なう責任があります。 これを受けて各RIRは、それぞれの特定の地域内で、 ISPや他のローカルインターネット・レジストリに対し、 より小規模なブロックの割り振りを行ないます。 現在は、3つのRIR（APNIC、ARIN、RIPE NCC）が存在していますが、 近い将来には、2つのRIR（LACNICとAfriNIC）が追加される見込みです。 IPv4アドレスとAS番号ブロックの割り振りにおいて、ICANNは、 RIRからの要請を慎重に検討します。 その際には、アドレス温存の必要性と、 それを必要とする者すべてが利用できるようにするという原則との間でバランスを取るよう設計された責任ある管理者のポリシーを適用しています。 ICANNはさらに、DNS逆引き委任ツリーの上位レベルに対する責任や、 プライベートアドレス空間などの一連の共通／専用アドレス空間の維持に対する責任も負っています。

　ICANNのアドレス支持組織（ASO）を通じ、また、 地域インターネット・レジストリとの緊密な協力関係のもとで、 ICANNは、IPアドレスとAS番号割り振りのための、 グローバルなアドレスポリシーを策定する責務を負っています。

III.プロトコル

　ICANNは、 プロトコルポート番号とパラメーター番号やその他のプロトコル識別子についての120を超えるレジストリの作成、維持、配布を行なっています。 ICANNは、覚書を通して、Internet Engineering Task Force（IETF）から、 この一連のIANA機能を遂行するよう指名されています。 ICANNスタッフは、Internet Engineering Steering Group（IESG）からの指導を受けながら、 IETFからの指示およびRFCシリーズの記述に従い、 業務を行っています。

　さらにICANNは、.arpaや、 従来からの技術的な.intドメインなどの、 いくつかのインターネット・インフラストラクチャ関連のレジストリに対し、 そのDNS実装を維持管理する責務を負っています。

参考文献

　以下は、完全なものではありませんが、 ICANNの運用上およびポリシー決定上の責務を規定した文書の参照リストです。

＜一般＞
＜名前＞
＜IPアドレスと自律システム（AS）番号＞
＜プロトコル番号＞

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

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

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

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

メールマガジン(JPNIC News & Views)登録

パスワードが記載された確認メールが発送されます。 確認メールが届かない場合は、 ご入力いただいたメールアドレスが
誤っていた可能性がありますので、 再度ご登録手続きを行ってください。

ロゴ:JPNIC

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