IANA機能の監督権限の移管について

最終更新日　2016年11月25日

2016年10月1日、 IANA機能の監督権限が米国政府(商務省電気情報通信局(National Telecommunications and Information Administration, NTIA))からマルチステークホルダーからなるコミュニティへ移管されました。このWebページでは、IANA機能の監督権限の移管に関心を持った方が、現状またはこれまでの状況を理解する上で必要な情報をご紹介します。

IANAとは
IANA機能を取り巻く歴史
IANA機能とは
移管前の体制
移管後の体制
移管が実現するまでの道のり

IANAとは

IANA (Internet Assigned Numbers Authority)は、インターネットにおける以下の三つの重要資源管理を担っています。

DNSルートゾーン運営に関する(ドメイン名含む)管理(.arpa, .intセカンドレベル、およびIDN tablesの管理も含む)
番号資源(IPアドレス、AS番号)の分配
プロトコルパラメーター(プロトコルナンバー、DNSリソースレコードタイプ、HTTPステータスコード、BGPメッセージタイプなど)の割り当て

IANAは当初、南カリフォルニア大学情報科学研究所(ISI)のJon Postel教授が中心となって始めたプロジェクトグループでしたが、 ICANNが1998年に設立されてからは、ICANNが米国政府から委託を受けて運営する機能の名称となっていました。 2016年10月1日からは、米国政府の委託はなくなり、それまでより強化されたインターネットコミュニティによるガバナンスに基づき運営されています。

IANA機能を取り巻く歴史

インターネットにとって重要な資源の管理の担っているIANA機能が長らく米国政府の管理下となっていたことは、インターネットの発展およびICANNの歴史と密接な関係があります。

ICANNの設立前

IANA機能は、南カリフォルニア大学のジョン・ポステル氏を中心に、米国政府の援助も受けつつも基本的に技術者や研究者のボランティアで運営されていたグループが担っていました。

1993年からは米国政府機関である全米科学財団(NSF)がIANAの活動の一部に対して資金援助を行い、拡大し続けるインターネットに対応しようとしました。この資金援助は、インターネットレジストリ機能などの登録管理と情報提供業務を請け負う業者をNSFが公募し、選定された業者に対してNSFが委託料を支払うという形態を取り、レジストリ機能についてはネットワークソリューションズ社(NSI)(現ベリサイン社)が選定されました。その後、インターネットの利用が拡大し、商用化が進むにつれて、NSIの独占への批判、gTLDの増加へのニーズ等、 IANA機能およびレジストリ機能の運営にさまざまな課題が挙げられ、インターネット資源の世界規模での調整をどのように行えばよいかが問題となりました。

ICANNの設立

それに対応する上での検討の過程で、当初は100を越える世界中のインターネット関連団体により連署され、新gTLD承認のプロセス等を規定したgTLD-MoUに基づき、 gTLDに関する管理体制を構築しようとしますが、米国政府は「インターネットの名前およびアドレスの技術的管理の改善についての提案」(通称グリーンペーパー)(1998年1月)でそのインターネットに対する特別な地位を主張し、一旦ストップがかけられます。

それに対して、数多くの批判を浴びた結果、米政府による投資の下成立したという主張は曲げなかったものの、グローバルにあらゆる関係者が関与し、インターネットの伝統を尊重したボトムアップな運営を行う新たな民間非営利法人に、インターネット資源とDNSの管理を委ねるというプランを、米国政府が示します。この新法人がICANNです。

その際、米国政府は「インターネットの名前およびアドレスの管理」(1998年6月：通称「ホワイトペーパー」)等で以下の姿勢を示しています。

民間がリーダーシップを担うようにするための移行作業については米国に責任がある
米国政府との契約でドメイン名空間の管理責任を新法人が負うとするとともに、それまでのIANA機能やそれを担う職員の所在地から、新法人の米国での設立を推奨

参考

IANA機能とは

IANAは、以下三つの、インターネットにおける重要資源に関わる機能を担っています。

ドメイン名
番号資源
プロトコルパラメーター

以下、各機能を紹介します。それぞれの機能を維持する上では、NTIAのみならず、機能に応じて異なる関係者が関わっています。各IANA機能と関係者間の関連は、「移管後の体制」セクションをご覧ください。

ドメイン名

IANAは、ドメイン名に関わる業務をいくつか行っています。このうち、トップレベルドメイン名(TLD)全般に関わる業務としては、 TLDの委任状況の管理を行っています。すなわち、TLDの追加、変更、削除のステータスを管理し、委任されている全TLDの一覧と、それぞれのTLDの運営者の連絡先を含めた一覧をIANAが管理し、公開しています。

また、TLDの追加、変更または削除をルートDNSに反映する上では、ルートゾーンファイルの更新が必要です。 IANAは、新規のTLDの追加および既存のTLDの変更・削除時に、TLDレジストリからの申請を受け、当該TLDに関するゾーンファイルの更新申請の審査を行っています。なお、ルートゾーンファイルの更新・管理はベリサイン社が行っているため、IANA自身はその更新は行いません。図を交えた説明は「移管後の体制」セクションの「ルートゾーンファイル管理」をご覧ください。

その他の、IANAが関わっているドメイン名に関する業務は以下の通りです。

.intおよび.arpaのTLDの運用
国際化ドメイン名(IDN)として認められる文字列の一覧の管理・公開
DNSSECにおけるルート鍵署名鍵(Root Key Signing Key)の管理
特別用途ドメイン名の予約

参考：IANAにおけるドメイン名に関する対応

番号資源

IPアドレス・AS番号の源泉管理、および、各RIRからの申請に基づき、これらの番号資源のRIRへの分配を行っています。また、マルチキャストやプライベート用のアドレス等、 RFCで定義された特別用途のIPアドレスおよびAS番号は、その用途のために番号資源空間を予約します。

IANAによるIPv4アドレス、IPv6アドレス、およびAS番号の分配管理の状況は、一覧として公開されています。

参考：IANAによる番号資源の管理

プロトコルパラメーター

提案中のものも含み、 IETFのインターネット標準で定められるプロトコルパラメーター(オペレーションコード、ポート番号、オブジェクト識別子、プロトコル番号)に対して、必要な番号を割り当て、登録を行っています。

プロトコルパラメーターの割り当て番号はIANAが管理し、一覧として公開されています。

参考：IANAにより割り当てられたプロトコルパラメーター

ルートゾーン管理

IANAはルートDNSゾーンに関して、TLDレジストリから変更要求を受け付けた上でルートDNSサーバーに変更が反映されるよう管理を行っています。

参考：IANAにおけるルートゾーン管理

移管前の体制

全体概要

ICANNとNTIAとの契約により、NTIAからICANNに対してIANA機能を無償にて業務委託していました。

IANA機能旧委託者：NTIA

2016年9月30日までは、米国商務省情報通信局(NTIA)が民間非営利法人であるICANNに対して、 IANA機能の運営を委託する形をとっていました。つまり、NTIAはIANA機能の「委託者」、ICANNはその「運営者」でした。その際ICANNはNTIAに対して、IANA機能が、全体として、適切に運営されていることを説明する責任がありました。さらに、移管前はIANAが審査したTLDレジストリからの申請内容を、ルートゾーンファイルに反映する上では、NTIAの承認が必要でした。ただし、実質的には手続き上の事務的な承認であり、内容の可否を判断するものではないとしていました。

ICANNとNTIA間でIANA機能に関して結ばれた契約には、米国政府とのIANA機能遂行に関する契約(IANA契約)がありました。同契約は同年9月30日に失効しました。

参考：NTIAによるIANA契約終了通知文書

ドメイン名：関係者：TLDレジストリ、GNSO、ccNSO、ICANN、NTIA

NTIAがICANNとの契約に基づき監督を行っており、そのため、ICANNからは定期的に報告書が提出されていました。 IANA(運営している組織としてはICANN)は、委任されているTLDの一覧を管理・公開しています。 TLDの追加、変更、削除が決定されると、その結果をIANAが公開しているTLDの一覧に反映するとともにルートゾーンに反映します(後述)。この作業における直接の関係者は、TLDレジストリ(gTLDレジストリおよびccTLDレジストリ)となります。

番号資源関係者：RIR、ASO、ICANN、NTIA

このIANA機能におけるサービス関係者はRIRです。RIRはIPアドレスおよびAS番号の分配を受ける上で、 IANAに申請を行います。こちらも、NTIAがICANNとの契約に基づき監督を行っていました。

プロトコルパラメーター：関係者：IAB、IETF、ICANN、NTIA

プロトコルパラメーターの割り当てにおいて、IANAに対応を促す上での、最終的な責任を担っている関係者はIABです。 IANAはIETFで提案中のものも含め、インターネット標準に関わるプロトコルパラメーターの割り当てと登録を行います。プロトコルパラメーターの割り当てを行う上で、内容の確認が必要な場合、 IANAは、IETFのManagement CommitteeであるIESGに確認を行いますが、 IANAとIESG間で意見が分かれた場合、最終的な判断は、IETFの監督(Oversight)を行う立場であるIABが行います。これらの役割と手順は、RFC 2860で定義されています。さらに、こちらもNTIAがICANNとの契約に基づき監督を行っていました。関係者間の契約は、2000年に締結されたIETFとICANN間のIANAの技術的業務に関する覚書、その追補、およびICANN-NTIA間のIANA契約となります。

参考：ICANN主要文書

ルートゾーン管理：関係者：ICANN、NTIA、ベリサイン社

TLDレジストリからのルートゾーンに関する登録情報はIANAが受け付け、変更内容をNTIAが確認・承認した上でベリサイン社がゾーンファイルを更新し、各ルートサーバーに配布しています。このうち、ベリサイン社が行う業務については、NTIAとベリサイン社との覚書により規定されていました。 ICANNはこの部分には直接関与していないため、IANA契約による監督の対象ではありませんでした。関係者間の契約は、NTIAとベリサイン社との協力覚書、およびNTIA-ICANN間のIANA契約になります。

移管後の体制

移管後の監督体制を示した図

以下の図の通り、NTIAが外れて、各資源ごとにコミュニティの代表からなる評価委員会などが監督する体制となりました。

IETF (Internet Engineering Task Force): インターネットの技術標準を策定する任意団体です。
　参考：IETFとは
IAB (Internet Architecture Board): インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団です。 ISOCの技術理事会(Technical Advisory Group)としても機能しています。
　参考：IABとは
PTI (Public Technical Identifiers): IANA機能を担う目的で設立されたICANNの非営利子会社。
　参考：PTIとは
CSC (Customer Standing Committee): IANA機能のドメイン名部分のサービスレベルを評価するために設立された委員会です。メンバーはccNSOとGNSOのレジストリ部会(RySG)から推薦されたメンバー各2名からなり、他にGNSOのレジストリ部会以外、At-Large諮問委員会(ALAC)、ルートサーバーシステム諮問委員会(RSSAC)、セキュリティと安定性に関する諮問委員会(SSAC)、政府諮問委員会(GAC)、およびPTIから各1名のリエゾンが加わっています。
IFR (IANA Function Review): IANA機能のドメイン名部分のサービスレベル以外を評価するためのチームです。 ICANN-PTI間の契約書には、PTIが外部サービスを利用して評価を行うこと、となっています。
RIR (Regional Internet Registry、地域インターネットレジストリ): 世界5地域の各地域内のIPアドレス・AS番号の割り当て業務を行うレジストリです。

ドメイン名に関する機能

移管後は、ICANNとPTI間のIANA名前機能に関する契約に基づき、CSCが監督をすることになります。

番号資源機能

移管後は五つのRIRとICANNとの間で締結したサービスレベル合意(SLA)に基づき、実績を評価するIANA番号サービス評価委員会(IANA Numbering Services Review Committee)が評価をすることになります。

プロトコルパラメーター機能

移管後は、 ICANNとInternet Society (ISOC)【IETFは法人でないため、ISOCがIETFに代わり契約主体となっています】との間で締結されている覚書に基づき、 IETFコミュニティとICANNの両者がIANA業務を監督することになります。

ルートゾーンファイル管理

ICANNとベリサイン社が契約を結び、ベリサイン社は移管前と同様、ルートDNSゾーンファイルの保守を行いますが、米国政府による承認プロセスはなくなりました。

ICANNとベリサイン社との契約(Root Zone Maintainer Agreement, RZMA)
NTIAとベリサイン社との協力覚書への追補(追補33, 34)：IANA契約と違い、覚書は存続していますが、追補により、本契約に基づくベリサイン社のルートゾーン管理義務を免除しているので実質RZMAに移行したと言えます。

移管が実現するまでの道のり

NTIAによる提案募集

2014年3月、米国商務省情報通信局(NTIA)よりIANA機能の監督権限を移管する意向が発表されるとともに、 ICANNに対して移行計画を立案するためにグローバルなステークホルダーとの検討を開始するよう依頼しました。

NTIAの代表者は、移管の話は新しいものではなく、米国政府はICANN設立当初から、監督権限を民間へ移管する意向があり、 2014年3月14日発表時点が適切なタイミングであると判断して発表に至ったことを表明しています。

ICANNとNTIAが、ICANN設立時に締結した米国商務省とICANNとの間の覚書でも、以下に示す通り、そのような位置づけが記されています。

背景(A. Background)：

1997年7月1日、米国大統領は商務省に対して、競争および国際的な参加を促進するよう、DNSの管理の民営化を指示。

これに対して、商務省は、安定性、競争、ボトムアップによる調整と代表の原則に基づき、米国政府から非営利組織に、現在の米国政府によるDNSの管理を、当該組織に移管するよう契約を締結したことを、1998年6月5日に発表。

目的(B. Purpose)：

民間セクターへのDNS管理を移管する上で、商務省は、DNSの技術的な管理という重要な責任を、当該民間セクターが担う能力および資源があるとの確信が持てることを求める。

これらの保証を確保するため、本覚書の当事者は、ここで定義するDNSプロジェクトを共同で行う。

DNSプロジェクトにおいて、本覚書の当事者は、DNS機能の管理を、米国政府から非営利の民間セクターに移管する段階で必要な仕組み、方法、手続きを共同で設計、策定し、試験を行う。

試験が成功し、完了する際、DNSプロジェクトに基づき設計・策定された仕組み、方法および手続きへ移管する。

この発表を受け、さまざまなフォーラムで移管後のIANA機能の監督権限のあり方について議論が進められました。

NTIAが提示した移管の条件

マルチステークホルダーにより、直接の利害のない立場の組織・個人を含め、あらゆる関係者の賛同が得られている提案であること、政府主導および政府間機関に移管する案は受け付けないことが、NTIAから条件として示されました。

なお、2014年3月のNTIAの発表は、あくまでIANA機能における米国政府の監督権限を移管する意向を発表したものであり、 IANA機能におけるその他の変更を求めてはいませんでした。

移管のタイムライン

2014年3月	NTIAがIANA機能に関する監督権限を手放す意向を表明
2014年7月	IANA監督権限移管調整グループ(ICG)設立。移管後体制の提案策定に向けた検討を開始
2015年10月	ICGが移管後体制の検討を完了
2016年3月	ICANNの説明責任強化に関する検討が完了。移管後体制と併せて統合提案としてNTIAに提出
2016年6月	NTIAが移管後体制の提案に対する審査報告書を公開
2016年8月	ICANNが移管実施準備に関する進捗報告書をNTIAに提出
2016年8月	NTIAが移管実施に向けたIANA契約終了の意向を発表
2016年10月	IANA監督権限の移管実施

IANA監督権限移管提案の検討

IANA監督権限移管提案を検討するため、 IANA監督権限移管調整グループ(IANA Stewardship Coordination Group, ICG)が2014年7月に設立されました。 ICGは、13のコミュニティを代表する30名のメンバーからなります。 2014年9月にICGは三つの資源コミュニティ(ドメイン名、番号資源、プロトコルパラメーター)それぞれに移管提案を依頼しました。

番号資源とプロトコルパラメーターコミュニティからの提案は、 ICGが設定した締め切りの2015年1月15日までに提出されました。ドメイン名コミュニティからの提案は、多岐にわたる関係者の間での意見集約に時間が掛かったため、完成が2015年6月までずれ込みました。そのため、2015年9月30日のIANA契約満了日までに移管実施の準備が整うめどが立たなくなり、 IANA契約は2016年9月30日まで1年間延長されることになりました。最終的にICGが三つの資源コミュニティからの提案の統合を完了したのは2015年10月となりました。

ICGは提出された提案の調整と統合を行った上で、 ICANN説明責任強化に関する検討結果(次項)を待って、両者を併せて2016年3月にICANNに提出しました。 ICANNでは、理事会による承認を経た上で、最終的に提案をNTIAへ提出しました。

参考：IANA監督権限移管提案

ICANN説明責任強化に関する検討

ドメイン名コミュニティにおける移管提案に関する議論の中で、コミュニティメンバーからICANN自身の説明責任機構を整備する必要があるとの声が高まり、 NTIAもIANA機能の安定的な運用のためには、その運営母体のICANNが、NTIAの監督権限移管後も十分に説明責任を果たすことを示す必要があるとして、説明責任機構整備に関する提案も移管後体制提案に含めるように求めました。

ICANNはこれに関してICANN説明責任強化に関するコミュニティ間横断作業部会(CCWG-Accountability)を組成し、検討を進めました。 CCWGによるICANN説明責任強化に関する提案は2016年3月までに完成し、 ICANNに提出され理事会の承認を受けました。

参考：JPNIC Blog「コミュニティがより参画できるICANNへ～ICANNの説明責任強化に向けた検討～」

提案の実装

ICGによるIANA監督権限移管統合提案、およびCCWGによるICANN説明責任強化提案のNTIAへの提出を受けてなされた、提案の実装項目の概要は以下の通りです。実装は移管までにすべて完了しました。

トラック1：ルートゾーン管理

ルートゾーン管理システム(RZMS)更新および並行テスト実施
ルートゾーン管理覚書(RZMA)作成・締結

トラック2：監督権限移管関連

ドメイン名コミュニティ向け期待サービスレベル(SLEs)作成
番号コミュニティ向けサービスレベル合意(SLAs)作成
IETF-ICANN覚書追補
ルートゾーンの進展に関する評価委員会(RZERC)設立
Public Technical Identifiers (PTI)設立
- 設立定款・定款改定、その他ガバナンス関連文書作成、業務委託契約書作成
- ドメイン名関連サービス合意書作成
Customer Standing Committee (CSC)設立
IANA知的財産権(IPR)のIETF Trustへの移管（IETF TrustによるIANA IPR移管ページ）
IANA運営エスカレーションプロセスの整備