|
この文書はJPNIC公開文書であり、著作権は日本ネットワークインフォ メーションセンター(JPNIC)が保持しています。JPNIC公開文書は誰でも 送付手数料のみの負担でJPNICから入手できます。また、この著作権 表示を入れるかぎり、誰でも自由に転載・複製・再配布を行なって構 いません。 〒101-0047 東京都 千代田区 内神田2-3-4 国際興業神田ビル6F |
"European Internet Registry Policies and Procedures" 翻訳文
(ftp://ftp.nic.ad.jp/jpnic/translation/ripe185-j.txt)
（社）日本ネットワークインフォメーションセンター
最終更新 1999 年 4 月 28 日
この文書は
http://www.ripe.net/docs/ripe-185.html
を翻訳したものです。JPNICはこの翻訳を参考のために提供しますが、その
品質に責任を負いません。
------------------------------------------------------------------------
ヨーロッパインターネットレジストリのポリシーおよび諸手続き(European Internet
Registry Policies and Procedures)
RIPEローカルインターネットレジストリワーキンググループ(RIPE Local Internet
Registry Working Group)
____________________________________________________
ヨーロッパインターネットレジストリ
ポリシーおよび諸手続き
RIPEローカルインターネットレジストリワーキンググループ
ドキュメントID: ripe-185
発行日: 1998年10月26日
破棄: ripe-104、ripe-105、ripe-136、ripe-140、ripe-159
要約
IPアドレス空間の分配は、「RFC 1466 [Gerich93a]」に記述されている階層体
系に従って行われる。ヨーロッパおよびその周囲の地域においては、IANAが、
地域インターネットレジストリとして活動するRIPE NCCにアドレス空間を割り
振る。RIPE NCCはローカルインターネットレジストリ(IR)にアドレス空間を割
り振り、ローカルIRはエンドユーザにアドレス空間を割り当てる。本ドキュメ
ントでは、アドレス空間管理においてローカルIRが従う必要のあるポリシーお
よび手続きについて説明する。さらに、RIPE NCCはアドレス空間管理に関連し
た作業を簡素化するためにIRが利用できるさまざまのサービスを提供する。
1. 対象範囲
本ドキュメントでは、世界的な規模で固有なインターネットアドレス空間の分
配にあたるヨーロッパインターネットレジストリシステムと、その運営につい
て説明する。特に、アドレス空間の分配に適用される規則とガイドラインに重
点を置く。本ドキュメントで述べる規則は、RIPE NCCを介して割り振られ割り
当てられるすべてのアドレス空間に対して拘束力を持つ。
本ドキュメントでは、プライベートインターネットアドレス空間およびマルチ
キャストアドレス空間については言及しない。また、ローカルIRにおけるヨー
ロッパガイドラインへの条項の追加についても言及しない。本ドキュメントで
は、グローバルなインターネットレジストリシステムの概要は紹介するが、他
の地域レジストリで採用されている割り振りおよび割り当ての規則には触れな
い。
____________________________________________________
ripe-185.txt Page 1
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
本ドキュメントは、RIPE Local Internet Registry (LIR) Working
Group(RIPEローカルインターネットレジストリワーキンググループ)が、下記
のメンバーから成る編集委員会の助力を得て作成したものである。
P. Caslav RIPE NCC
S. Dolderer DE NIC
D. Karrenberg RIPE NCC
M. Kuehne RIPE NCC
M. Norris HEANET
C. Orange RIPE NCC
W. Woeber ACONET
J. Zsako Banknet
H.P. Holen Schibsted Nett
1.1. 概説
本ドキュメントの主要部は8つのセクションから成っており、それぞれの内容
は以下のとおりである。
セクション2「インターネットアドレス空間とインターネットレジストリシス
テム」では、IPアドレス空間のタイプとそれぞれの目的を定義する。アドレス
を割り当てるときに適用すべき目標について説明し、目標達成のために使用す
るインターネットレジストリシステムの階層的性格の概要を紹介する。また、
プロバイダ集約アドレス空間とプロバイダ独立アドレス空間の重要な相違点も
示す。
セクション3「アドレス空間の割り当て手続き」では、ヨーロッパのIPレジス
トリがユーザにIPアドレスを割り当てる際に必要な手続きについて説明する。
まず、各種のの必要な情報要素について詳しく述べるが、中でもドキュメンテー
ションの重要性が強調される。次に、評価の基準と標準を示す。最後に、各種
のアドレス空間の実際の割り当てと、それに付随してレジストリが行うべき手
続きを説明する。
セクション4「割り振りの規則とガイドライン」では、RIPE NCCが、どのよう
な方法で効率的かつ公正にIPアドレス空間をレジストリに割り振るか、そして、
この種の割り振りの状況と性質がRIPEデータベース内でどのように公開される
かについて説明する。
セクション5「DNSとリバースアドレスマッピング」では、クラスレスアドレス
の逆引きを提供する際のRIPE NCCの役割を定義し、レジストリが、自己が割り
当てたアドレス空間の従属的なクラスレスアドレスの逆引きを管理する方法に
ついて説明する。
____________________________________________________
ripe-185.txt Page 2
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
セクション6「ローカルインターネットレジストリの運営」では、本ドキュ
メントで概説するポリシーの統一的な実装を促進するためにRIPE NCCが提供す
るさまざまのサービスを紹介し、IP登録サービスに関連してローカルIRがとる
手続きの概略を示す。
セクション7「AS番号割り当てのポリシーと手続き」では、ヨーロッパのIPレ
ジストリがAS番号を要求するときにとる手続きについて説明する。
セクション8「ドメイン間(外部)ルーティングに関する考慮事項」では、ドメ
イン間ルーティングに関する各種の事項(たとえば、ルーティング情報の発信、
ルーティング告知の伝搬、経路の集約とデータベースへの登録など)、および
本ドキュメントで説明するアドレス空間の分配に関するポリシーを定義する上
での各事項の役割について解説する。
本ドキュメントで使用している重要な用語の意味を示す「用語集」も収めてある。
____________________________________________________
ripe-185.txt Page 3
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
2. インターネットアドレス空間とインターネットレジストリシステム
2.1. IPアドレスのタイプ
本ドキュメントで取り扱うIPアドレスは、IPv4プロトコルで使用される32ビッ
トバイナリ番号である。IPアドレスには主要なタイプが3つある。
グローバルアドレス
グローバルIPアドレスは、インターネットアドレス空間を形成する。グローバ
ルアドレスは、セクション2.2で述べる目標に従って、世界的規模で固有なも
のとして割り当てられる。このアドレス空間の第1の目的は、インターネット
上でIPv4を使用して通信できるようにすることにある。第2の目的は、相互接
続されたプライベートインターネット同士で、IPv4を使用して通信できるよう
にすることにある。現時点では、プロバイダ独立(PI)アドレスおよびプロバイ
ダ集約(PA)アドレスという２種類のグローバルアドレスが、明確に区別されて
いる。その詳細については、セクション2.4を参照されたい。PIおよびPAアド
レス空間に関する詳細情報は、「ripe-127
[Karrenberg95a]」にも収められている。
プライベートアドレス
一部のアドレス範囲は、IPを使用するプライベートネットワークの運営用とし
て確保されている。これらのアドレスは、登録または調整を必要とせずに、誰
でも各自のプライベートネットワーク内で使用することができる。この種のア
ドレスを使用しているホストには、インターネットから到達することはできな
い。プライベートアドレス空間の詳細な説明については、「RFC
1918 [Rekhter96b]」を参照されたい。
特別リザーブアドレス
マルチキャストなどのアプリケーション用にリザーブされているアドレス範囲
がいくつかある。これらのアドレスについては、別のドキュメント(たとえば、
「RFC 1112 [Deering89a]」)で説明されており、本ドキュメントの説明対象で
はない。
____________________________________________________
ripe-185.txt Page 4
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
2.2. グローバルアドレス空間の分配の目標
本ドキュメントの以下の部分では、主として、前のセクションで述べたグロー
バルアドレス空間の管理に重点を置くことにする。インターネットアドレスの
各割り当てにおいては、次の制約条件が確実に満たされていることが必要であ
る。
固有性
グローバルアドレスは世界的な規模で固有なものでなければならない。
これは、インターネット上の各ホストが固有なものとして識別されるようにす
るための、絶対的な必須条件である。
グローバルアドレス空間を割り当てる際には、固有性という条件に加えて、下
記の3つの目標を念頭に置く必要がある。
集約
ルーティング情報の集約を可能にするために、階層方式によりグローバルアド
レスを分配する。これは、インターネットルーティングの適切な運用を確保す
るために必要である。この目標は「ルーティング可能性(Routability)」とも
呼ばれる。
節約
グローバルアドレス空間を使用してネットワークを運営するエンドユーザの必
要量に応じて、アドレス空間を公正に分配する。グローバルアドレス空間資源
の寿命を最大限に延ばすには、必要量に応じてアドレスを分配し、エンドユー
ザのもとでアドレス空間の浪費が発生するのを避けなければならない。
登録
アドレス空間の割り振りと割り当てを文書化したパブリックレジストリを準備
する。これは、固有性を確保するため、およびインターネットにおけるすべて
のレベルでのトラブルシューティングが可能な情報を提供するために必要であ
る。
上記の目標を達成することは、インターネットコミュニティ全体の利益にもつ
ながる。「節約」と「集約」はしばしば相反する目標となるので、この点に留
意しながら、各割り当てを入念に評価することが必要である。
____________________________________________________
ripe-185.txt Page 5
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
さらに、上記の目標は、ときとして、個々のエンドユーザまたはインターネッ
トサービスプロバイダの利益に反する場合がある。したがって、個々のケース
について細心の分析と査定を行い、適切な折衷案を見出すことが必要である。
本ドキュメントで紹介する規則とガイドラインは、インターネットレジストリ
およびエンドユーザが、それぞれ最善の折衷案を模索する際の参考として利用
することを目的としている。
____________________________________________________
ripe-185.txt Page 6
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
2.3. インターネットレジストリシステム
インターネットレジストリシステムは、セクション2.2で述べた目標を達成す
るために設立されたものである。このシステムは、階層的に編成されたインター
ネットレジストリ(IR)で構成されている。通常、エンドユーザにはローカルIR
がアドレス空間を割り当てる。このアドレス空間は、地域IRがローカルIRに割
り振ったアドレス空間の中から割り当てられる。エンドユーザとは、割り当て
られたアドレス空間を使用するネットワークを運営する組織である。ただし、
エンドユーザの代理機関として働くコンサルタント(要求者)が、アドレス空間
を要求することもできる。ローカルIRは、通常、インターネットサービスプロ
バイダ(ISP)により運営される。ローカルIRには、エンドユーザに割り当てる
ためのアドレス空間が割り振られている。割り当てられたアドレス空間は、ネッ
トワークの運営のために実際に使用されるものである。これに対しト、割り振
られたアドレス空間は、将来エンドユーザに割り当てる目的でIRが保有するも
のである。節約と集約の両方の目標を達成するために、アドレス空間の割り振
りを保有できるのはIRのみとなっている。
IANA
IANA(Internet Assigned Numbers Authority)は、インターネットで使用され
るすべての番号空間を管理する権限を持っている。これにはIPアドレス空間も
含まれる。IANAは、地域IRに対して、それぞれの確認された必要量に従ってグ
ローバルアドレス空間を割り当てる。
地域IR
地域IRは、たとえば大陸などのような広範囲の地勢学的な地域で業務を行う。
現時点では3つの地域IRが設立されている。北米を対象とするARIN、アジア太
平洋地域を対象とするAPNIC、そして、ヨーロッパとその周辺地域を対象とす
るRIPE NCCである。この3つが地球上の全地域をカバーしているわけではない
ので、各地域IRは、それぞれの中心サービス地域の周囲の地域に対してもサー
ビスを提供している。地域IRの数はできるだけ少ない方が望ましい。
地域IRは、IANAの管理下に設立される。地域IRの設立には、該当地域のインター
ネットコミュニティの合意を必要とする。特に、該当地域に属する各種ISPが
この設立プロセスに参加することが妥当である。地域IRには、対象地域内のロー
カルIR間の調整を計り、それらのローカルIRを代表する責任がある。
____________________________________________________
ripe-185.txt Page 7
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ローカルIR
ローカルIRは、地域IRの管理下に設立される。ローカルIRは通常ISPにより運
営され、そのサービスの対象には、そのISPのカスタマのほか、大規模ISPを介
してインターネットに接続する小規模ISPのカスタマも含まれる。ほかに、大
規模な多国籍企業などのような組織も、ローカルIRとしての業務を運営するこ
とができる。
本ドキュメントの大半の部分は、割り当てプロセスにおけるローカルIRの責務
に重点を置いている。場合によっては、アドレス空間を割り当てるローカルIR
を運営するのが、接続を提供するISPとは別の組織であることがある。その場
合、割り当てられたアドレス空間に関する管理情報を保持するのは、接続を提
供するISPではなく、割り当てを行うIRの責任であるという点に注意する必要
がある。さらに、アドレス割り振りを保有することができるのもIRだけである。
エンドユーザ
厳密に言えば、エンドユーザはIRシステムの一部ではない。ただし、エンドユー
ザは、上記で述べた目標の達成という点で重要な役割を果たす。たとえば、節
約目標を達成するには、エンドユーザは、ネットワーク計画を立てる際に、ア
ドレス空間の使用量を最小限に抑える努力をする必要がある。そのために、エ
ンドユーザは、アドレス体系および運用計画をIRに提出するほか、割り当て決
定のためにIRが必要とするその他の情報も提供しなければならない。また、集
約目標を達成するには、エンドユーザは適切なローカルIRを選定するよう要求
される。エンドユーザは、ISPを変更した場合に、各自のネットワーク内のア
ドレスの変更が必要になることがあるという点に留意しなければならない。最
後に、エンドユーザは、各自に割り当てられているアドレス空間に関する登録
データを提供し、かつ更新しなければならない。
要求者
インターネットレジストリシステムにおいて重要な役割を果たす上記の各種組
織に加えて、エンドユーザに代わってネットワークをセットアップし管理する
コンサルタントが介在することがしばしばある。この種のコンサルタントとし
ては、たとえば、エンドユーザに代わって実際にアドレス空間要求をIRに提出
する人などが考えられる。RIPE NCCでは、エンドユーザの組織に雇用されてい
るか、それとも単にアドレス空間の要求についてその組織の代理を勤めるかに
関係なく、エンドユーザを代表して要求を提出する者を要求者と呼ぶ。
____________________________________________________
ripe-185.txt Page 8
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ヨーロッパのIRシステム
ヨーロッパでは、インターネットレジストリシステム階層は、上位から順に、
IANA、RIPE NCC、およびローカルIRの各エンティティにより構成されている。
2.4. プロバイダ独立アドレスとプロバイダ集約アドレス
プロバイダ集約アドレス空間
インターネットサービスプロバイダが運営するローカルIRには、プロバイダ集
約(PA)アドレス空間が割り振られ、ローカルIRはこのアドレス空間を各自のエ
ンドユーザに割り当てる。そのとき、1つのISPの多くのエンドユーザに関する
ルーティング情報が、そのISPのルーティングドメインの境界上に集約される
ように配慮される。これは、ドメイン間ルーティングシステム(プロバイダ間)
における経路の数および状態変更の数を、妥当なレベルに維持できるようにす
るためである。比較的少数の集約経路を伝搬する場合、ドメイン間ルーティン
グシステムの全域にわたって各ユーザーの個々の経路を伝搬する場合に比べて、
コストを大幅に低く抑えることができる。
エンドユーザがサービスプロバイダを変更した場合は、そのエンドユーザの
PAアドレス空間を付け替えることが必要になる。その場合、そのエンドユーザ
の組織内のすべてのホストおよびルータの再編成が必要になる。エンドユーザ
は、新たなアドレス空間割り当てを取得し、前に割り当てられていたアドレス
空間を返還する必要がある。アドレス空間が適切に返還されるようにするため
に、ローカルIRとエンドユーザの間に、明確な(できれば契約に基づく)合意が
必要とされる。この契約では、プロバイダがエンドユーザにインターネット接
続を提供しなくなった時点、またはその後短期間に、アドレス空間の割り当て
が無効になることを明記することが望ましい。
この種の協定の目的は、ドメイン間ルーティングシステムに対する負荷を最小
限に抑えることにある。エンドユーザが、新たなサービスプロバイダに接続し
ながら、前のサービスプロバイダから取得したPAアドレスを使用し続けたとす
れば、そのエンドユーザのルーティング情報は集約できないため、ドメイン間
ルーティングシステム内で個別に伝搬しなければならなくなる。
プロバイダ独立アドレス空間
PAアドレス空間とは逆に、PIアドレス空間は、最初の割り当て時の基準を満た
している限り、ユーザに割り当てたままにすることができる。
____________________________________________________
ripe-185.txt Page 9
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
割り当ての期間は、特定のプロバイダのサービスを使用しているかどうかによ
り拘束されない。PIアドレス空間の明白な利点は、ユーザがサービスプロバイ
ダを変更しても、そのユーザのホストおよびルータの構成を変更する必要がな
いという点にある。しかし、PIアドレスは、集約を利用できないためルーティ
ングの費用が高くなる。初期のインターネットアドレス空間割り当ては、すべ
てプロバイダ独立型であった。また、ローカルIRが行う多くの割り当ても、正
式にはプロバイダ独立型である。これは、ISPとエンドユーザとの間に、サー
ビスの終了時に割り当てが打ち切られるという事前の合意がないからである。
割り当ての有効性
最初の割り当てのもとになっている基準が満たされている限り、どの種類のア
ドレス空間の割り当ても有効である。特定の目的のために割り当てが行われ、
その目的が消滅したときは、割り当ては無効になる。割り当ての根拠となって
いる情報が無効になったときは、その割り当ても無効になる。
____________________________________________________
ripe-185.txt Page 10
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
3. アドレス空間の割り当て手続き
3.1. 概要
このセクションでは、ローカルIRがユーザにアドレス空間を割り当てるときに
必要な手続きについて説明する。最初に、ユーザからどのような情報を収集す
るかについて述べる。この情報収集の目的は2つある。第1に、集約目標および
節約目標の観点から、アドレス割り当ての決定を行うための情報が必要である。
第2に、登録を目的とした情報が必要である。
次に、適切な割り当てを行うためにこの情報をどのように評価すべきかについ
て説明し、割り当ての決定にとって重要な役割を果たすその他の考慮事項を示
す。最後に、割り当てプロセスで行う手続きを紹介する。
割り当てプロセスの個々の要素の説明に入る前に、収集すべき情報を決定する
ための一般的な背景情報とポリシー、および必要な手続きについて説明してお
く。
エンドユーザは、IRから割り当てられたアドレス空間を使用して、アドレス空
間要求の中で記述した特定のネットワークを運営する。IRは、割り当ての有効
期間内は、他のエンドユーザに同じアドレス空間が割り当てられることのない
ことを保証する。割り当ての元になった基準が有効である限り、割り当ても有
効である。
節約目標を達成するために、エンドユーザはアドレス空間を備蓄することを認
められていない。IPアドレス空間要求の評価は、現在のアドレス空間利用状況
テンプレートおよび次のセクションで説明するアドレス体系計画に記述されて
いる、今後24ヶ月間についてのドキュメンテーションに基づいて行う。割り当
てるアドレス空間の量は、このドキュメンテーションに照らして妥当と認めら
れるものでなければならない。つまり、現在の要求を満たすために、過去に割
り当てられているアドレス空間を可能な限り利用すべきである。割り当てられ
たアドレス空間を使い果たしてしまった組織は、自己のネットワークの新たな
成長予測に基づき、追加のアドレス空間を要求することができる。
____________________________________________________
ripe-185.txt Page 11
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
3.2. ドキュメンテーション
適切な割り当て決定を行うためには、アドレス空間を要求するエンドユーザの
組織、アドレス体系に関する要件、ネットワークインフラストラクチャ、現在
のアドレス空間の利用状況、および将来の計画に関する情報を収集する必要が
ある。この情報は割り当てプロセスに不可欠のものであり、IRが正式に必要と
するものである。場合によっては、割り当て決定を行うためにさらに追加情報
が必要になることがある。ローカルIRは、要求の処理を進める前に、必要な情
報がすべて揃っていることを確認する必要がある。
必要な情報を収集するための手段として、RIPE NCCでは、一連の書式とその記
入方法の説明を提供している。できるだけこれらの書式(または該当地域の言
語に翻訳したもの)を使用することが望ましいが、ローカルIRが自己の割り当
て枠の範囲内の要求に関する情報を収集するときは、自己の裁量により適切と
認められる形で情報を収集し管理することもできる。ただし、収集するドキュ
メンテーションには、現在のアドレス空間の利用状況に関する上記と同種の情
報、および、新たに要求するアドレスの使用方法に関する何らかのアドレス体
系計画が含まれていることが妥当と考えられる。また、各サブネット内でアド
レスをどのような目的に使用するかについても、ドキュメンテーションの中で
明らかにする必要がある。RIPE NCCがこのドキュメンテーションの閲覧を要求
したときは、英語バージョンを提供していただきたい。
ただし、NCCによる評価を必要とする要求は、英語の"European IP Address
Space Request Form"(ヨーロッパIPアドレス空間要求書式)の現行バージョン
(現在は「ripe-141: [Caslav96a]」)を提出しなければならない。各カスタマ
ごとに要求書式を提出する必要がある。その中で、どのエンドユーザにアドレ
ス空間を割り当てるのかを明記しなければならない。たとえば、カスタマA、B、
Cといった総称的な表記による要求は認められない。RIPE NCCが要求するその
他のドキュメンテーションも、すべて英語で記載されていることが必要である
という点に注意されたい。
割り当てを行うローカルIRは、割り当てプロセスで収集した情報を永久保存し、
地域レジストリの要求に応じてただちに提供できるようにしておかなければな
らない。ローカルIRは、エンドユーザのプライバシーを保護する義務がある。
セクション3.2.1.5に指定するデータはレジストリデータベース内で公開され
るが、その他の情報については厳重に機密を保持しなければならない。ローカ
ルIRは、エンドユーザによる明示的な要請なくして、IANAまたは地域レジスト
リの責任者以外の者に情報を提供してはならない。
____________________________________________________
ripe-185.txt Page 12
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
以下のサブセクションでは、収集すべき個々のデータと、その収集が必要な
理由について概説する。
3.2.1. 必要な情報
アドレス空間の割り当てを要求する場合には、各要求ごとに下記の情報を添付
する必要がある。これらのデータは、アドレスを適正に割り当てるため、およ
び割り当ての全体的な概要を把握するために不可欠のものである。セクション
3.2.1.2に指定する情報を除き、情報はすべて現在要求しているアドレス空間
に関するものである。
3.2.1.1. 組織の概要
ユーザのアドレス空間の必要量を適切に査定するには、アドレスが割り当てら
れる組織の構造と、組織のどの部門がアドレスを利用するかを把握することが
重要である。
たとえば、次のような状況を考えてみていただきたい。ベルギーに本社があり、
さまざまな部門を持つ自転車メーカーがあるとする。これらの部門には、フロ
ントフォーク部門や変速装置部門などのように、特定の自転車部品を専門に扱
う部門もある。また、販売部門や開発部門などのような一般的な部門もある。
この種の企業においては、販売、開発、製造などの部門は最高経営陣に直属し、
変速装置、チェーン、ペダル、フロントフォークといった小部門は製造部門の
下部組織になっていることが多い。このような企業からアドレス空間の要求が
出された場合、RIPE NCCとしては、割り当てられたアドレスを組織のどの部門
が利用するのかを知る必要がある。たとえば、製造部に、すべての自転車部品
製造課で使用するためのアドレス空間が割り当てられたとする。その後間もな
く、チェーン製造課がアドレス空間を要求した場合に、RIPE NCCでは、チェー
ン製造課のニーズを満たすアドレス空間が、この組織にすでに割り当てられて
いるという事実を認識していることが必要である。販売部門が数ヶ国に営業グ
ループを持っている場合も、これに似た状況が生じる可能性がある。その場合、
本部が要求しているアドレスがアントワープやマドリードでも使用されること
になるかどうかを知ることが必要になる。RIPE NCCでは、組織の2つの部分に
より同じサブネット用の割り当てが行われるのを回避することを望んでいる。
____________________________________________________
ripe-185.txt Page 13
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
_____________________________________________________
販売部門が分散している場合は、集約の観点から適正な割り当てを行うため
に、その事実も知らされることが必要である。
割り当てを行う責任者は、組織の概要、およびその中での要求者の役割が分か
らない限り、この状況を認識することはできない。したがって、組織の構造の
概要に関する情報の提供を受けることが重要である。これには、親会社、子会
社、および連絡担当者に関する詳細情報が含まれる。
上記の自転車メーカーの場合、チェーン製造課を代表する誰かが、ベルギーの
組織構造に関する総合情報、および製造部、販売部、開発部の連絡担当者に関
する総合情報を用意することも可能と考える人もいるかも知れない。RIPE NCC
では、このような人が、販売部門内の構造に関する情報、たとえばローマのオ
フィスを誰が管理しているかといった情報を提供するものとは予期していない。
組織自体が自己のアドレス空間の管理を行い、組織全体を代表する1人の人物
がすべての要求を行うようにすれば、割り当てプロセスが大幅に簡素化される
ことは明らかである。
連絡担当者
要求の処理を容易にするためには、要求を行う人、およびアドレス空間が割り
当てられる組織の誰かに関する連絡情報が必要である。この情報は、要求者連
絡テンプレートおよびユーザ連絡テンプレートに入力する必要がある。これら
のテンプレートには、氏名、組織、国、電話、ファックス番号、およびEメー
ルのフィールドが含まれている。各テンプレートで、該当の担当者の氏名をフ
ルネームで指定する必要がある。組織はこの担当者が所属する組織であり、国
はこの担当者のオフィスが属している国である。電話番号およびファックス番
号には、国を表すプレフィックスを「+コード」の形式で含める。または、担
当者にインターネットを介したEメールでの連絡が可能な場合は、Eメールアド
レスも記入する。
連絡担当者情報を収集するのは、単にアドレス空間要求の事務処理を促進する
ためである。この情報には、後日RIPEデータベースに入力されることになる人
に関するデータが含まれていてもいなくてもよい。
____________________________________________________
ripe-185.txt Page 14
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
3.2.1.2. 現在の割り当て空間の利用状況
アドレス空間割り当てにおける節約目標を達成するには、新たなアドレス空間
を割り当てる前に、過去に該当ユーザに対して割り当てられているアドレス空
間に関する情報を把握していることが必要である。つまり、アドレス空間が現
在どのように利用されているかについての詳細情報が必要とされる。RIPE NCC
では、この情報を使用することにより、すでに割り当て済みのアドレスを運用
することによってユーザのニーズを満たすことができる場合に、新たなアドレ
ス空間の割り当てを防ぐことができる。
したがって、組織にすでに割り当てられている各アドレスセットについて報告
を受ける必要がある。これらのアドレスの現在の利用状況を、下記に示すよう
な表の形式で表すことが必要である。ユーザのネットワーク内の物理的に独立
した個々のサブネットについて、1つずつエントリを設ける必要がある。サブ
ネットが物理的に別個のものとみなされるのは、それぞれの間にIPルータが存
在する場合である。下記の表では、各行に、エンドユーザの組織内の1つのサ
ブネットを表すエントリが含まれている。
Addresses Used
Prefix Subnet Mask Size Current 1yr 2yr Description
193.1.193.0 255.255.255.192 64 28 34 50 Derailer LAN
193.1.193.64 255.255.255.224 32 10 12 25 Chain (dynamic
dial-up)
193.1.193.96 255.255.255.224 32 8 13 27 Front Fork LAN
193.1.193.128 255.255.255.128 128 57 100 114 Main Office
(routers, servers, & office LAN)
193.1.194.0 255.255.255.0 256 132 170 210 Frame LAN
193.1.195.0 255.255.254.0 512 317 350 380 Assembly LAN &
dynamic dial-up)
1024 549 679 806 Totals
上記の表の各エントリには、サブネット内のアドレス空間の現在の利用状況と
今後の利用予測を示すフィールドが含まれている。以下これらのフィールドに
ついて説明する。Description(記述)フィールドでは、ユーザの組織内でのサ
ブネットの役割を、簡潔でしかも意味のある表現で記述する。"Location 1"
(事業所1)、"Location 2"(事業所2)といったあいまいな表現は避けていただき
たい。上記の例では、各種の自転車部品を表す語句を使用している。この情報
とサイズ情報を併せて分析することにより、組織内のネットワーク構造をかな
り明確に洞察することができる。
さらに、サブネットで現在使用されているネットワークインターフェイスの数、
および1年後と2年後の予測必要数も記入する必要がある。
____________________________________________________
ripe-185.txt Page 15
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
これらの数値は、サブネットエントリのCurrent(現在)、1yr(1年後)、2yr(2
年後)の各フィールドに記入する。これらの数値には、ホスト用、ルータ用、
ゲートウェイ用、ターミナルコンセントレータ用、プリンタ用、および、1つ
以上のネットワークインターフェイスを必要とするその他のマシン用など、使
用するすべてのネットワークインターフェイスの数を含める。これらのフィー
ルドには、使用アドレスの合計数を示す累算値を記入するものとする。(たと
えば、Front Fork(フロントフォーク)サブネットで現在8個のアドレスを使用
しており、1年後にさらに5個を追加することを計画しているのであれば、
Addresses Used(使用アドレス数)の1yrフィールドにはその合計の13を記入す
る)。
Size(サイズ)フィールドには、サブネットのサイズを指定する。これによって、
サブネットに含めることができるネットワークインターフェイスの最大数が決
まる。これは2の累乗数でなければならず、当然のことながら2yrフィールドに
指定する数と同じかそれより大きいのが普通である。それより小さいとすれば、
それはアドレス要求を提出する動機となっている場合か、または要求者の計画
に誤りがある場合である。
Subnet
Mask(サブネットマスク)フィールドはその名の示すとおりである。最後に、
Prefix(プレフィックス)フィールドには、このサブネット用のアドレスが、割
り当てられているアドレス空間の中のどの位置で始まっているかを示す起点を
記入する。
例に示したように、表には、現在使用されていない割り当て済みアドレス空間
についても項目を設けて記入する必要がある。
3.2.1.3. 要求の概要
要求の概要は、要求の規模についての概念を手早く把握するために使用される。
要求を処理するIRは、この情報に基づいて、割り当て要求の性質を即時に理解
することができる。収集すべき情報は次のとおりである。
要求のサイズ: IRが要求の規模を即時に把握できるようにするために、
network overview(ネットワーク概要)書式のrequest-size(要求サイズ)フィー
ルドに、要求するインターネットアドレスの合計数を指定する必要がある。
request-sizeが512であるとすれば、ユーザは512個のインターネットアドレス
を要求していることになる。クラスレスドメイン間ルーティング(Classless
Inter-Domain Routing:CIDR)を使用するには、ユーザは2つのクラスCネットワー
クを持っていることが必要である。クラスレスアドレス体系が使用されるため、
要求のサイズは256より小さくてもよく、クラス境界の間(たとえば、32、288、
384)でもよい。CIDRの詳細については、「RFC 1519 [Fuller93a]」および
「RFC 1518 [Rekhter93a]」を参照されたい。
____________________________________________________
ripe-185.txt Page 16
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
使用するアドレス数:
要求者のネットワークの構造の概要を知るには、各種の時点で実際に使用さ
れるインターネットアドレスの数を知る必要がある。この数はネットワークへ
のインターフェイスの数に該当する。
network overview書式のaddresses-immediate(即時アドレス数)、
addresses-year-1(1年目アドレス数)、およびaddresses-year-2(2年目アドレ
ス数)フィールドに、割り当ての直後、12ヶ月以内、および24ヶ月以内にそれ
ぞれ、要求したネットワークアドレス数のうちのいくつを使用するかを記入す
る。current usage(現在の利用状況)テンプレートの場合と同様に、これらの
フィールドには、新たに追加するアドレス数ではなく、各時点で必要になる累
計アドレス数を指定する。また、これらの数値は、具体的かつ厳密な計画に基
づいて算出した、実際に必要なアドレス数でなければならない。
サブネットの数: 実際には、エンドユーザは、要求するアドレスを組織内の1
つまたは複数のサブネット内で運用することを望む。要求するアドレスを使用
する物理的に独立したサブネットがいくつになるかは、適正な割り当てを行う
上で重要な要素である。この数および使用するアドレス数から、要求者が描い
ているネットワークインフラストラクチャ構想の全体像を把握することができ
る。network overview書式のsubnets-immediate(即時サブネット数)、
subnets-year-1(1年目サブネット数)、およびsubnets-year-2(2年目サブネッ
ト数)フィールドに、それぞれ、要求者のネットワーク計画において、即時、
12ヶ月以内、および24ヶ月以内に実装するサブネット数を指定する。
インターネット接続:
アドレス空間を割り当てる前に、IPアドレスを要求しているエンドユーザが
すでにインターネットに接続しているかどうかを知る必要がある。すでに接続
している場合は、このユーザにとって適切といえるアドレス空間の選択は、現
在どのプロバイダが接続を提供しているかによって異なる。ユーザがまだイン
ターネットに接続していないが、今後接続することを計画している場合は、そ
れも考慮に入れる必要がある。グローバルアドレス空間の分配における節約目
標と集約目標を満たすには、この情報が重要である。ユーザの現在の接続およ
び予定されている接続は、network overview書式の inet-connect(インターネッ
ト接続)フィールドに指定する。
____________________________________________________
ripe-185.txt Page 17
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
国: 最後に、アドレスがどの国(1つまたは複数)で使用されるかを、ISO 3166
に規定されたの2文字のコードで指定する。この指定には、network overview
書式のcountry-net(国)フィールドを使用する。該当のISO 3166コードが分か
らない場合は、国の正式名称を記入する。
プライベートアドレス空間:
プライベートアドレスを使用することは、節約目標を達成する上で役に立つ。
したがって、ユーザに対しては常に、プライベートアドレスが有効な選択肢の
1つであることを知らせることが重要である。特に、すべてのホストでインター
ネットへのネットワーク層アクセスが必要なわけではない場合は、プライベー
トアドレス空間を利用できる。プライベートアドレス空間がユーザのニーズを
満たす場合でも、ユーザがそれを使用する義務はないが、その可能性を検討し
てみることは重要である。要求者が、ユーザのネットワークにとってプライベー
トアドレスが適当かどうかを指示した場合は、network overview書式の
private-considered(プライベート検討済み)フィールドにチェックマークを記
入する。
要求拒否:
ユーザの組織の1つが過去において割り当て要求を拒否されたことがある場合
は、いつどのIRが拒否したのかを知ることは有用な要素である。どのようなケー
スであっても、要求が拒否された事実とその理由を知ることは有益である。こ
の情報は、network overview書式のrequest-refused(要求拒否)フィールドに
記入する。
PI要求:
ユーザがプロバイダ独立アドレス空間を要求した場合は、その要求を処理す
るローカルIRは特別の手順をとる必要がある。PIアドレス空間に対する要求の
場合は、network overview書式の PI-requested(PI要求)フィールドにチェッ
クマークを記入する。通常、PIアドレス空間はLIRが保有する割り振りから割
り当てられるのではなく、RIPE NCCが、そのために確保しているアドレス範囲
から割り当てる。
返還するアドレス空間:
ユーザが新しい割り当てと引き替えにアドレス空間を返還する場合は、RIPE
NCCにその旨知らせる必要がある。この情報は、network overview書式の
address-space-returned(返還するアドレス空間)フィールドに指定する。この
フィールドには、返還するアドレスの範囲、返還の日付、および、アドレスの
返還先のISPを指定する。
____________________________________________________
ripe-185.txt Page 18
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
3.2.1.4. アドレス体系計画
要求されたアドレス空間の割り当ての妥当性を査定するには、アドレス体系計
画が必要である。これにより、要求されたアドレス空間の利用予定に関する詳
細情報が得られる。現在のアドレス空間利用状況と同様に、アドレス体系計画
も、各サブネットを指定した表形式で表す。
わずかな例外はあるが、次の表のエントリは、現在のアドレス空間利用状況の
表と同じである。
Relative Addresses Used
Prefix# Subnet Mask Size Immediate 1yr 2yr Description
0.0.0.0 255.255.255.192 64 8 16 60 Systems Group
(back-bone, dynamic dial-up)
0.0.0.64 255.255.255.224 32 17 22 26 Engineering LAN
0.0.0.96 255.255.255.224 32 12 17 20 Manufacturing LAN
0.0.0.128 255.255.255.224 32 10 15 27 Sales LAN
0.0.0.160 255.255.255.240 16 5 9 12 Management LAN
0.0.0.176 255.255.255.240 16 7 8 13 Finance LAN
192 59 87 158 Totals
サブネット内でただちに必要とされるネットワークインターフェイスの数と、
今後12ヶ月および24ヶ月以内に必要になることが予測される数を指定する必要
がある。これらの数は、サブネットエントリのImmediate(即時)、1yr(1年目)、
および2yr(2年目)フィールドに入力する。これらのフィールドには、各期間に
使用する合計アドレス数の累計値を記入するものとする。
Relative Prefix(相対プレフィックス)フィールドには、このサブネット用の
アドレスが、割り当てられるアドレス空間のどの位置で始まるかを指定する。
最初のサブネットの相対位置は常に0.0.0.0である。以後の各サブネットにつ
いては、それぞれの直前のサブネットのSize(サイズ)フィールドに指定されて
いる合計ホスト数に応じて、開始位置を選択する。
アドレス空間を節約するために、サブネットの開始位置は、アクセス空間内の
空き部分を最小限にするような形で選択することが必要である。上記の例では、
Sizeフィールドの値の大きいものから順に行を並べている。一般に、この方式
を用いることにより、サブネット間のむだなアドレス空間を抑制することがで
きる。有効なアドレス空間要求のサイズは、アドレス計画で指定されているサ
ブネットのサイズの総和となる。
____________________________________________________
ripe-185.txt Page 19
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
現在の評価基準では、アドレス体系はクラスレスであるものと想定される。
これは、任意の長さのすべての可能なプレフィックスを使用できることを意味
する。技術上の制約があって特定のアドレス範囲が使用できない場合、または
最適なサブネットサイズが選択できない場合は、その制約を明確に記載する必
要がある。この記載事項には、制約の厳密な性質、制約の原因となっているハー
ドウェアまたはソフトウェアの構造、モデル、およびバージョン、ネットワー
ク内でのその正確な位置を含める。一般に、クラスフルアドレス体系が大量の
アドレス空間を浪費する原因となる場合は、要求は認可されない。
3.2.1.5. データベース情報
登録のためには、アドレス空間を必要とする組織に関する情報が必要である。
また、アドレスの要求および管理に従事する担当者に関する情報も必要である。
同一人物が複数の職責を担当することがあるので、一部の情報は重複する場合
がある。しかし、各職責をそれぞれ異なる人が担当することもあるので、すべ
ての情報を完全に記入する必要がある。下記に挙げるデータは割り当てを処理
するローカルLRが収集すべきものであり、レジストリデータベースに格納され
る。レジストリデータベースに格納された時点で、これらのデータは公開され
ることになる。個々の割り当ておよび個々のカスタマは、別々にデータベース
に登録する必要がある。RIPE
NCCデータベースの詳細については、「ripe-157 [Magee97a]」を参照されたい。
組織:
RIPEデータベースを維持するために、アドレスを使用する予定の組織に関す
る情報を提供する必要がある。そのためにはNetworkテンプレートを使用する。
inetnum(インターネット番号)フィールド(これはブランクのままでもよい)は、
データベースにIPアドレス番号を入力するために使用される。RIPEデータベー
ス内でこの割り当てを識別しやすくするために、netname(ネット名)フィール
ドには、簡潔でしかも意味のある名前を記入する必要がある。割り当てられた
アドレスを使用する組織の簡単な記述も必要である。この情報は、Networkテ
ンプレートの1つまたは複数のdescr(記述)フィールドを使って指定する。
____________________________________________________
ripe-185.txt Page 20
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
たとえば、割り当てたアドレスをCatatonic State大学の神経外科部門が使
用することになるとすれば、その部門名と大学名を2つのdescrフィールドに分
けて記入する。country(国)フィールドには、ISO 3166に規定された国コード
を指定する。コードが分からないときは、正式な国名を使用してもよい。
admin-cフィールドとtech-cフィールドには、それぞれ、管理連絡担当者およ
び技術連絡担当者のIRハンドル(NICハンドル)を記入する。admin-cフィールド
に指定する管理責任者は、ネットワークのサイトに物理的に存在している者で
なければならない。この責任者は、ネットワークに関する技術的な知識を持っ
ていなくてもよい。tech-cフィールドに指定する技術責任者は、サイトに配置
されているサポート要員でも、組織に依頼されてネットワークの保守に従事す
るコンサルタントでもよい。いずれの場合も、複数の人を指定することができ
る。tech-cフィールドには、person(人物)オブジェクトの代わりにrole(職責)
オブジェクトを指定してもよい。各連絡担当者を指定するには、NICハンドル
を使用する必要がある。これは、データベース内に各担当者についてそれぞれ
固有のエントリが作成されるようにするためである。データベース内に該当の
担当者のエントリがない場合は、要求により固有のNICハンドルを取得するこ
とができる。NICハンドルの取得方法については、「ripe-157 [Magee97a]」を
参照されたい。担当者が、すでにARINデータベース内にNICハンドルおよび
personオブジェクトを持っている場合は、RIPEデータベース内でも同じNICハ
ンドルを使用することができる。
割り当てられたアドレス空間のタイプは、inetnumオブジェクトのstatus属性
に、"ASSIGNED PA"または"ASSIGNED PI"のいずれかとして登録しなければなら
ない。セキュリティ上の目的により、notify(通知先)フィールドには、データ
ベースオブジェクトに変更が加えられたときに通知を受けるEメールアドレス
を記入し、mnt-by(保守担当者)フィールドでは、オブジェクトに対する変更権
限のある人を指定したmaintainer(保守担当者)オブジェクトを参照することが
できる。
担当者データ:
割り当て要求に従事する各担当者について、完全な担当者データが必要であ
る。このデータを省略できるのは、該当担当者に関する最新情報がすでにRIPE
データベースに格納されている場合のみである。データベース内にエントリを
持つ担当者について新たなデータが提出された場合は、提出と同時にそれがアッ
プデートデータとみなされ、現行の担当者データはその新データで上書きされ
る。省略またはアップデート以外の場合は、Personテンプレートで以下のデー
タを指定する必要がある。person(担当者)フィールドには、担当者名をフルネー
ムで指定する。完全な郵便宛先住所を、複数のaddress(住所)フィールドを使っ
て指定する。
____________________________________________________
ripe-185.txt Page 21
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
phone(電話番号)フィールドには、担当者が職場にいるときの連絡に使用で
きる国際電話番号を記入し、fax-no(ファックス番号)フィールドにはその担当
者のファックス番号を入力する。もちろん、この担当者をデータベース内で固
有に識別できるように、担当者のNICハンドルをnic-hdl(NICハンドル)フィー
ルドに入力する必要がある。networkテンプレートの場合と同様に、notifyフィー
ルドには、データベースオブジェクトに変更が加えられたときに通知を受ける
Eメールアドレスを記入し、mnt-byフィールドでは、オブジェクトに対する変
更権限のある人を指定したmaintainerオブジェクトを参照することができる。
提出情報
NetworkテンプレートとPersonテンプレートのどちらにも、これらのエントリ
をレジストリデータベースに提出する人を識別するためのスペースが設けられ
ている。提出者のEメールアドレスを、テンプレート提出の日付と共に、
changed(変更)フィールドに記入する必要がある。これは最初に割り当てが行
われた日付を示すものなので、後日テンプレートがアップデートされた場合は、
元のchangedフィールドを残しておく(そして新たなフィールドを追加する)よ
うにする。
同様に、source(ソース)フィールドは、割り当てが行われた後で要求者情報が
どのレジストリデータベース内にあるかを指定するために使用する。この場合、
この割り当ての要求者情報はRIPEデータベースに格納されるので、ここには
RIPEを指定する。
3.2.2. 追加情報
割り当て要求の査定に際しては、常に以下の追加情報が役に立つ。場合によっ
ては、IRは、評価プロセスの一環としてこれらのデータの提供を求めることが
ある。
運用計画:
たとえば、インターネットへのアクセス手段を望み、アドレスの即時必要数
を4,000個と見込んでいる新規加入企業があるとする。この場合、そのユーザ
に対して運用計画の提出が求められる。この計画には、要求したアドレスを使
用することになるイベントのリストと、各イベントが発生する日付を含める必
要がある。これは、ユーザにどの程度の現実性があるかを判断し、適格と認め
た場合に、ユーザの計画に従って割り当てプロセスの手順を設定するために使
用される。
____________________________________________________
ripe-185.txt Page 22
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
トポロジーマップ:
「百聞は一見に如かず」ということわざは、ネットワークの場合にもよくあ
てはまる。要求元の組織における現在および計画されているネットワークイン
フラストラクチャのトポロジーマップがあれば、ネットワーク構造を明確に把
握することができる。この種のマップを利用できる場合がしばしばあり、これ
をアドレス体系計画および現在のアドレス空間利用状況と組み合わせて使用す
れば、きわめて有用な情報が得られる。このマップは、ポストスクリプトドキュ
メントまたはファックスにより送付することができる。ファックスには、要求
のチケット番号(セクション6.3を参照)を記載していただきたい。
特殊事情:
ときには、ユーザが旧型のシステムや特殊目的のハードウェアを使用してい
るため、クラスレスアドレス体系に基づく割り当てを利用できない場合がある。
その場合は、問題の原因となっている特定のハードウェアまたはソフトウェア
に関する情報を、ユーザから収集する必要がある。さらに、ユーザが問題のハー
ドウェアまたはソフトウェアを今後いつまで使う予定かを知ることも重要であ
る。
検証情報:
ネットワークに関する実質的な経験を持たないユーザを対象とする処理を行
う場合は、ユーザの計画が現実的な計画に基づくものかどうかを判断すること
が難しい場合がある。その場合は、ネットワークの計画と管理に対するユーザ
の理解度を示す情報を入手するのが有益である。そのためには、まず、ユーザ
がアドレス体系計画における各種見積りをどの程度正確と考えているか、およ
びそれらの見積りをどのように導き出したのかを尋ねるのがよい。対応するネー
ム空間計画も、ユーザの計画の緻密さを計る尺度となる。
3.3. 評価
上記の情報を収集し終えたら、次に、セクション1で述べた節約目標および集
約目標を念頭に置きながら、適正な割り当てを決定する必要がある。各要求に
ついて、現在の割り当てガイドラインを考慮に入れながら、個別に評価プロセ
スを進める必要がある。レジストリは、割り当てを行ったり、それをRIPE NCC
に送って認可を求める前に、必ずエンドユーザが記入した要求を評価する必要
がある。
上記のドキュメンテーションが揃ったら、IPアドレスの割り当てが妥当かどう
かを判断し、妥当と認めた場合は、割り当ての量とタイプを決定する必要があ
る。このプロセスにおいては、アドレス空間の備蓄を防止するためのIRの配慮
が重要である。アドレス空間の節約のためには、クラスレスアドレス体系を使
用することが望ましい。
____________________________________________________
ripe-185.txt Page 23
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
同時に、適正なルーティングを可能にするには、集約を念頭においた戦略的
な決定を行う必要がある。これらの事項は、このセクションで述べる評価プロ
セスにおける動機づけの重要な要素となる。
評価手順
1. 現在のアドレス空間利用状況:
まず、要求者から提供された現在のアドレス空間利用状況と、IRが入手可能
なその他の情報とを比較することから着手するのが妥当である。現在のアドレ
ス空間利用状況を検証した後で、要求されたIPアドレスを、すでにユーザに割
り当てられているアドレスからまかなえるかどうかをチェックする必要がある。
2. ネットワークの概要:
次に、Network Overviewに指定された要求のサイズを、即時使用のアドレス
数、および要求時以降2年以内の使用予定アドレス数と比較する。これによっ
て、アドレス利用率、つまり要求されたアドレス空間に対する使用予定数の割
合を評価する。特別の事情がない限り、割り当てられたアドレス空間に対して、
即時利用の率が25%で、1年後の利用率が50%に達するのが妥当と言える。
3. プライベートアドレス空間:
このネットワークにとってプライベートアドレス空間が妥当と考えられる場
合は、ユーザがこの選択肢の存在を認識した上で、敢えてこの選択肢を排除す
る決定をしたことを確認する必要がある。さらに、プライベートアドレス空間
を使用すれば、自由裁量によりさらに多くのアドレス空間を利用できるという
ことも、ユーザによく理解させることが必要である。
4. 極小企業(Very Small Enterprise:VSE):
ホスト数が少ない(現時点で24未満)のエンドユーザを、その組織自体の規模
に関係なく、極小企業(VSE)と呼ぶ。VSE用のアドレス空間は、クラスレス方式
で割り当てるのが妥当である。すべてのアドレス空間要求の場合と同様に、必
要量を超えるアドレス空間の割り当てを避けるよう注意する必要がある。VSE
に対するすべての割り当ては、データベースに個別に登録しなければならない。
インターネットへの接続を意図していないVSEには、グローバルアドレス空間
を割り当てる代わりに、プライベートアドレス空間の利用を勧奨する。特に、
将来のインターネット接続を容易にする目的でPI空間を要求するVSEに対して
は、この方法を強く勧奨することが望まれる。この種の企業には、VSEにとっ
ては一般に、後日リナンバに必要となる労力が最小限ですむということを周知
すべきである。
____________________________________________________
ripe-185.txt Page 24
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
5. アドレス体系計画:
アドレス体系計画の評価に際しては、まず、即時使用、1年目使用、および2
年目使用のアドレス数の各合計値が、要求概要に指定されている数値に一致し
ていることを確認する。次にネットワークマスクの妥当性をチェックして、サ
ブネットのサイズから見て適正かどうかを判断する。場合によっては、ユーザ
が指定するものとは異なるサブネットマスクを使用することで、アドレス空間
を節約できることがある。その場合は、より適切なネットワークマスクを使用
したアドレス体系計画を提出するよう、ユーザに要請する。
原則として、サブネット用として要求されたアドレス数(サイズ)と、使用予定
数との間に大きな差があってはならない。要求者が、水増しの多いアドレス体
系によりネットワーク管理が大幅に簡素化される旨を主張したとしても、この
原則は変わらない。
6. 追加情報:
運用計画が提供されている場合は、アドレス体系計画を検討して、両者の間
に矛盾がないことを確認する。同様に、トポロジーマップがある場合はそれも
点検して、アドレス体系計画との間に一貫性があることを確認する。現在のア
ドレス空間利用状況およびアドレス体系計画の妥当性をチェックするために利
用できるすべての情報を活用するべきである。
7. アドレスのリザーブ:
割り当ては、アドレス体系計画および現在のアドレス空間利用状況に指定さ
れている現実的な予測のみを根拠として行うべきである。エンドユーザは、長
期の計画に基づいてアドレスをリザーブすることは認められない。これはアド
レス空間の断片化を招くからである。長期にわたるリザーブをしても、ユーザ
のニーズから見て多すぎたり不足したりする結果になることが多く、一般に効
果は薄い。
8. 静的ダイヤルアップ:
使用可能なIPv4アドレス空間の自由プールには制限があるため、ダイヤルアッ
プユーUに対する静的IPアドレス割り当て(たとえば1カスタマに1アドレス)の
使用は、極力避けるべきである。静的アドレス体系の使用によって管理のいく
つかの局面が簡素化されるという事実はあるが、現在の未割り当てのIPv4アド
レス空間の消費率から見て、単に管理の容易さを理由にこの種のアドレスの割
り当てを容認する余裕はない。静的IPアドレス割り当ての利用を検討している
組織は、可能な限り動的割り当て技術の利用を検討し実装することが望ましい。
この目的のための割り振りが実際に行われるとすれば、割り振りおよび検証の
ための特別な手続きが適用されることになる。詳細については、RIPE NCCに照
会されたい。
____________________________________________________
ripe-185.txt Page 25
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
9. 仮想ホスト:
ときには、同じインターフェイスおよび物理ネットワーク上で、1つのホスト
に複数のIPアドレスが割り当てられることがある。これは、しばしば、HTTPな
どの高水準プロトコルの欠点を補うために利用される。上記で述べたのと同じ
理由により、この目的のための大規模な割り当てもできるだけ避けるべきであ
る。現在RIPE NCCでは、URLのホストの役割を担うHTTPバージョンが広く普及
した時点で、アドレスを返還するかまたは他の目的に再利用することを条件と
して、仮想WWWサーバ用のアドレス空間の割り当てを認めている。この目的の
ための割り振りまたは割り当てが実際に行われるとすれば、割り振りおよび検
証のための特別な手続きが適用されることになる。詳細については、RIPE NCC
に照会されたい。
3.4. 割り当て手続き
次に、アドレス空間を割り当てるための実際の手続きについて説明する。ここ
では、これまでのサブセクションの内容に従って、すでに情報の収集とその評
価を終えていることを前提として説明を進める。このサブセクションで述べる
手続きは、検討している要求に対するアドレス空間を割り当てるためのもので
ある。
3.4.1. 割り振りの範囲内での割り当て
IRは、アドレス空間要求がある程度の量のアドレス空間の割り当てに値すると
認定した場合は、実際に割り当てるアドレスのセットを選択しなければならな
い。割り当てを行うローカルIRに割り振られているアドレス空間の範囲の中か
らアドレスを割り当てる場合は、割り振られている空間の断片化を防ぐための
配慮が必要である。特に、割り当てるアドレス空間の各セットは、CIDR(ビッ
ト)の境界から始まるようにすることが重要である。これは、割り当てるアド
レスの各範囲の開始アドレスが、その範囲のサイズで割り切れなければならな
いことを意味する。これは、アドレス空間割り当てにおける集約目標の達成に
役立つ。
要求は、いくつかの小さいアドレス空間範囲によって満たすことも、単一の大
きい範囲によって満たすこともできる。たとえば、要求を満たすのに384個の
アドレスで十分であり、1つの物理サブネットで使用される数が256個を超える
ことはないという場合は、/23の代わりに/24と/25を1つずつ割り当てるように
すれば、/25を1つ節約して他のユーザ用に残しておくことができる。このよう
な場合、ローカルIRは、節約目標の趣旨に従い、単一の大きい範囲ではなく複
数のアドレス範囲を割り当てることが望ましい。
____________________________________________________
ripe-185.txt Page 26
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
当然のことながら、この方法で節約できるアドレス空間の量が増えるにつれ
て、必要な労力も増加する。
ローカルIRは、割り当ての決定を行うに際し、いつでもRIPE NCCに助言を求め
ることができる。ただし、ローカルIRに割り振られているアドレス空間のブロッ
クの中から割り当てを行う場合であっても、RIPE NCCの承認を得なければなら
ないこともある。特に、割り当てのサイズが、該当のローカルIRに認められて
いる割り当ての規模を超えている場合は、事前にRIPE NCCの承認を得る必要が
ある。ローカルIRが事前承認なしで行うことのできる割り当てのサイズは、そ
のローカルIRの割り当て枠によって決まる。割り当て枠については、セクショ
ン3.6で説明する。
ローカルIRに割り振られている範囲以外からアドレスを割り当てる必要がある
場合は、該当のアドレス空間が割り振られているIRが割り当ての選択を行う。
通常、これは地域レジストリである。
3.4.2. PA空間とPI空間
アドレス空間の量を決定する基準、および登録に関する要件は、PAおよびPIの
どちらのアドレス空間の場合も同じである。たとえば、PAまたはPIのいずれの
アドレス空間の割り当ての場合も、256個未満のアドレス数で要求を満たせる
のであれば、/24より長いプレフィックスを持つ割り当てを行うことができる。
ローカルIRは、どのタイプのアドレス空間を割り当てるかをユーザに明示しな
ければならない。PAアドレス空間の割り当ての場合は、アドレス空間割り当て
の期限を明記した明確な契約が必要とされる。また、絶対的な必須条件ではな
いが、PI空間の割り当てについても、契約を取り交わすことを強く勧奨する。
集約の観点から見れば、PA空間の割り当てには明らかな利点があるので、IRは
可能な限りPA空間の利用を勧めることが望ましい。したがって、エンドユーザ
の事情から見て十分と認められる場合は、極力 PA空間の利用をユーザに勧奨
していただきたい。
PA空間を使用した場合の結果とPI空間を使用した場合の結果を、必ず明確にエ
ンドユーザに伝えなければならない。特に、PA空間を利用した場合の影響をエ
ンドユーザが確実に理解できるようにするために、割り当てを行うIRは、PA空
間を要求する各ユーザに対し、以下のような警告を与えることが必要である。
____________________________________________________
ripe-185.txt Page 27
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
このアドレス空間の割り当ては、最初の割り当てのもとになった基準が満た
されており、かつ、貴社とISP XXXXとの間のサービス契約の期限が切れていな
い間に限り有効とみなされる。ISP XXXXは、契約の終了時または契約期間の満
了後は、アドレス空間を他のユーザに再割り当てする権利を保有する。アドレ
ス空間割り当てが無効となったときは、貴社においては、このアドレス空間を
使用しているすべての装置のアドレスの再構成が必要になることがある。この
再構成が必要なのは、当該装置のアドレスの世界的規模での固有性を引き続き
必要とする場合に限られる。一部のインターネットサービスでは、世界的規模
で固有なアドレスは不要なことを認識しなくてはいけない。たとえば、NAT(ネッ
トワークアドレストランスレータ)またはアプリケーション層のゲートウェイ/
ファイアウォールを介してアクセスできるサービスの場合、アクセスマシンが
世界的に固有なアドレスを持っている必要はない。
もちろん、PI空間を使用した場合の結果も、エンドユーザに対して明確に示さ
なければならない。そのためには、PI空間を要求する各ユーザに対し、次のよ
うな警告を与える。
このアドレス空間の割り当ては、最初の割り当てのもとになった基準が満たさ
れている間に限り有効である。PIアドレス空間の割り当ては、インターネット
のすべての部分へのルーティングが可能であることを暗黙に示すものではない。
ユーザは、PIアドレスのルーティングに関して割り増し料金の支払いが必要に
なることがある(PAアドレスの場合はその必要はない)。場合によっては、イン
ターネットのほとんどの部分において、比較的少量のPI空間のルーティングが
不可能になることがある。PIアドレスを使用するときは、有力なサービスプロ
バイダに接触し、サービスの可能性と価格に関する情報を入手することが望ま
しい。
割り当てを行うIRは、割り当てたアドレス空間のタイプを、RIPEデータベース
のinetnumオブジェクトのstatus属性に登録する必要がある。この属性には次
のいずれかの値を指定できる。
____________________________________________________
ripe-185.txt Page 28
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ASSIGNED PA
これは、エンドユーザに割り当てたPAアドレス空間の場合に使用する。
ASSIGNED PI
これは、エンドユーザに割り当てたPIアドレス空間の場合に使用する。
新規のアドレス空間割り当てについては、RIPEデータベース内にPAまたはPIの
いずれかを指定する必要がある。さらに、旧割り当ての登録の質を改善するた
めに、IRは、レジストリデータベース内の過去の割り当てについても、PAまた
はPIのいずれかのマークを付けることが望まれる。割り当てられたアドレス空
間についてstatus属性にタイプが明記されていない場合は、それはPI空間と見
なされる。したがって、PA空間の場合はその旨明記することが必要とされる。
通常、ローカルIRには一定範囲のPA空間が割り振られ、IRはその中から割り当
てを行うことができる。エンドユーザが、IRが割り当てることのできないタイ
プのアドレス空間(一般にPI)を要求した場合は、IRは、その要求を満たすこと
のできるレジストリ(通常はRIPE NCC地域レジストリ)に、そのエンドユーザを
紹介する必要がある。ローカルIRに割り振られていないアドレス空間の割り当
てをカスタマが要求しているときに、ローカルIRがその取得を補佐することを
望む場合は、該当サービスを提供するIRをサポートする必要がある。たとえば、
この種のローカルIRは、エンドユーザが適正な要求ドキュメントを用意し、割
り当てを行うIRが必要とする背景情報を準備する際の手助けをするものとする。
もちろん、ローカルIRは、割り当てを行うことができるローカルIRにユーザを
紹介することができる。
特定タイプのアドレス空間(前記の場合と同様に主としてPI)の大量割り当てを
行うことが少ないローカルIRは、この種のアドレス空間要求に応えるための割
り振りを保有している必要はない。この種のアドレス空間は、必要に応じて
RIPE NCCから取得できる。一般に、この種の割り当てには集約性はない。
3.5. IPアドレスの交換
過去に割り当てられたアドレス空間は、実質的には集約されているが、正式に
はPAタイプのものではない。正式には、割り当ての目的と有効期限に関する契
約がない限り、PAタイプのアドレス空間とは言えない。
____________________________________________________
ripe-185.txt Page 29
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
したがって、ローカルIRは、サービスの終了時に、PA以外のアドレス空間の
解放をエンドユーザに要請することが望ましい。同様に、エンドユーザが新た
なローカルIRに移籍してインターネットサービスを取得する場合は、その新規
ローカルIRは、ユーザに対し、保有している非PAアドレス空間を解放した上で、
新たな割り当てを要求するよう要請することが望ましい(これは、新規のロー
カルIRにとっても労力を費やすに値するプロセスのはずである)。将来におけ
る非PA空間の使用を最小限に抑えるために、IRは、正規の契約を締結して、非
集約アドレス空間を正式にPAアドレス空間に移行していくことが望ましい。
IPネットワークにおけるホストのナンバリングおよびリナンバリングの手続き
はますます容易になってきてはいるが、エンドユーザにリナンバを要請まは強
制することは、依然として問題を引き起こす可能性がある。リナンバは、通常、
エンドユーザにとっても、またはISPおよびローカルIRにとっても、相当量の
時間と労力が要求される。場合によっては、アドレス空間割り当ての付け替え
付け替えが不可欠のこともあり、その場合に備えて、ローカルIRはいつでもカ
スタマをサポートできる態勢を整えておくことが必要である。さらに、これよ
りもっと一般的かつきわめて重要なケースとして、歴史的理由によりこれまで
ランダムに割り当てられてきて、他のPA割り当てに集約することのできないPI
アドレス空間の、自発的付け替え付け替えという問題がある。この種の付け替
え付け替えは、ルーティングテーブルの成長を抑え、インターネット全体の保
守性を維持するための、重要な役割を担っている。リナンバプロセスは決して
簡単作業ではないので、インターネットレジストリシステム全体が、可能な限
りこのプロセスを支援することが必要である。
エンドユーザが、ネットワークの個々のサービスまたは部分を新たなアドレス
空間に移行する間は、混乱が生じることが考えられる。多くの場合、移行期間
中は、複数のISPに接続することが必要になる場合があり、ときには、旧範囲
と新範囲の両方のアドレスを、並行して管理し使用しなければならないことも
ある。ロジスティックスの重複を最小限に抑えると同時に、集約と節約の目標
を達成するには、この期間をできるだけ短くすることが重要である。
IPアドレス空間の付け替え手続き
一般に、アドレス空間の付け替えは1対1のベースで行う。前に割り当てられて
いるPI空間と付け替えるPA空間を割り当てることができるのは、最初の割り当
て時の基準がまだ満たされており、しかも、付け替え対象のアドレス空間が現
在エンドユーザのネットワークで使用されている場合である。
____________________________________________________
ripe-185.txt Page 30
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
元の割り当てのうちの大きな部分(50%または4096個を超えるアドレス)が使
用されていない場合のみ、エンドユーザは、通常のドキュメンテーションを新
規レジストリに提出する必要がある。要求のこの部分は、追加アドレスの割り
当てを求める他の要求と同じように処理される。
標準のアドレス空間割り当て要求書式を使って、付け替え対象のアドレス空間
(個々のアドレス範囲および合計サイズ)を正しく文書化する必要がある。RIPE
NCCの枠組の中で設立されたローカルIRが割り振ったアドレス空間の場合は、
ドキュメンテーションのコピーが、付け替え対象のアドレス空間を割り当てた
レジストリ(1つまたは複数)に転送される。新たにアドレス空間の割り当てを
行う前に、それまで割り当てられていた旧アドレスを元のレジストリに返還す
るまで、または最終的な再割り当てのために地域レジストリに返還するまでの
最大期限に関する合意(契約が望ましい)に達する必要がある。リナンバが完了
した後は、変更に合わせてデータベースをアップデートする必要がある。
大量のアドレス(/20以上)を付け替える場合は、目的とする付け替えについて、
および並行割り当ての最大期限に関する合意について、地域IRに知らせる必要
がある。複雑なケースでは、地域IRは、アドレス空間の付け替えを管理するプ
ロセスを指導することができる。
一般に、エンドユーザが新規アドレスへの移行を完了するまでに、3ヶ月間の
猶予を認めるものとする。RFC 2008 "Implications of Various Address
Allocation Policies for Internet Routing"[Rekhter96a]では、最低30日間、
最大6ヶ月間の猶予期間を推奨している。例外的なケースにおいて、エンドユー
ザが6ヶ月を超えて新旧両方の割り当ての保有を望む場合は、要求された期間
についてRIPE NCCの承認を得る必要がある。
ローカルIR以外から割り当てられたアドレスの場合、またはアドレスを割り当
てたIRがその後業務を停止した場合は、地域IRが元のレジストリに代わって処
理を行う。
____________________________________________________
ripe-185.txt Page 31
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
3.5.1. マルチホームユーザ
エンドユーザは、複数のサービスプロバイダからの接続の取得を望む場合があ
る。その場合は、ユーザのネットワークの複数の部分をサポートするために、
複数のIRからアドレス空間割り当てを取得することが必要になる。一般に、ユー
ザが複数のIRからアドレス空間およびサービスを取得しようとしても、まった
く問題はない。このようなユーザのネットワークはマルチホームネットワーク
と呼ばれる。
ユーザはマルチホーム接続が可能なので、IRは、ユーザからのアドレス空間要
求と、セクション3.2.1.2で述べた現在のアドレス空間利用状況を、特に入念
に検討する必要がある。そして、ユーザが、同じ目的のために異なるIRから複
数の割り当てを取得しようとしているのではないことを、確認する必要がある。
さらに、類似のアドレス空間要求が、他のIRにおいて正当な理由で拒否された
事実がないことも確認しなければならない。
3.6. RIPEデータベースのアップデート
割り当てに関連したオブジェクトをRIPEデータベースに登録することにより、
アドレス空間の利用状況の追跡が可能になるほか、運用上の連絡およびアドレ
ス割り振りに関する調査が簡単になる。これらの活動は、インターネットの効
率的な維持のための不可欠のものである。
データベースへのオブジェクトの登録は、割り当てを行う上での最後の必須ス
テップである。このステップにより割り当てが確定され、割り当てに関する公
開情報が、その情報を求める誰にでも利用できるようになる。したがって、こ
のステップを実施する前に、割り当ておよびすべての関連データが正しいこと
を、入念に確認する必要がある。割り当てがレジストリの割り当て枠(次のセ
クションを参照)を超過する場合は、LIRは、その割り当てをデータベースに登
録する前に、RIPE NCCに承認を求めなければならない。
Networkテンプレートでユーザの組織について収集した情報(セクション
3.2.1.5を参照)に基づいて、inetnumデータベースオブジェクトが作成される。
inetnumオブジェクトには、ユーザに割り当てたアドレスの範囲も入力する。
これは、ドットクワッド表記(ピリオドで区切った4部分構成の表記)で指定す
る。たとえば、ある組織に、1024個のネットワークアドレス用として/22アド
レスセットを1つ割り当てるとすれば、範囲は、193.1.192.0～193.1.195.255
のようになる。さらに、前記で述べたように、inetnumオブジェクトのstatus
フィールドには、割り当てたアドレスがPIかPAかも指定する。
____________________________________________________
ripe-185.txt Page 32
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
RIPEデータベース内ですでに細心のオブジェクトが使用可能になっている場
合を除き、inetnumオブジェクトに加えて、inetnumオブジェクトのtech-cおよ
びadmin-cオブジェクトに指定した各担当者についてのpersonオブジェクトも
入力する必要がある。personオブジェクトにはNICハンドルを指定する。
入力した情報は、元の割り当てが有効な限りデータベース内に残される。アド
レス空間が返還された場合は、割り当てを行ったレジストリは、旧エントリを
データベースから削除しなければならない。
割り当てを行うIRが、割り当てプロセスで収集した情報を将来の参照用として
正しく格納すれば、上記で述べたオブジェクトの入力によって、割り当てプロ
セスは完了する。これで、IRは、割り当てたアドレス範囲およびその利用に関
するその他のデータを、エンドユーザに提供することができる。
3.7. 割り当て枠
ローカルIRのスタッフは、上記の説明に従って、アドレス空間割り当てのため
の手続きをとり、割り当てサイズを決定するための評価基準を適用する必要が
ある。手続き自体は簡単である。しかし、新しい状況に対して評価基準を適用
することは、必ずしも容易ではない。
節約、集約、および登録の目標が達成されるようにするには、割り当て基準お
よび手続きが適正に適用されていることを確認する必要がある。そのためには、
一般に、経験の浅いローカルIRに対しては、割り当てプロセスにおける最大限
のサポートが必要である。ただし、経験を積んだローカル IRは、RIPE NCCの
助言を必要とせずにほとんどの割り当てを行うことができる。大量割り当ての
場合は、利用可能アドレス空間に対する影響が大きいため、常に事前の承認が
必要とされる。
このような各種のレベルのサポートを実現するために、RIPE NCCは、各ローカ
ル IRに対し割り当て枠を設定する。割り当て枠とは、ローカルIRが、RIPE
NCCから事前に承認を受けずにエンドユーザに割り当てることができる最大ア
ドレス数である。この数は/nnの表記で表される。したがって、割り当て枠が
/23であるローカルIRは、最大512個のアドレスを、RIPE NCCの事前承認なしで
エンドユーザに割り当てることができる。ローカルIRのスタッフが経験を積む
につれて、枠のサイズも拡大される。
____________________________________________________
ripe-185.txt Page 33
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ローカルIRの割り当て枠を超えるアドレス空間の割り当ては、RIPE NCCから
明示的な承認を得るまでは、正式には無効である。この承認がない限り、割り
当てたアドレス空間は使用できない。これは、後日、インターネットアドレス
に関する固有性の要件に対する違反が生じる恐れがあるからである。
割り当て枠は、個々の割り当てだけではなく、12ヶ月間における同じエンドユー
ザに対する複数の割り当ての合計に対しても適用される。ローカルIRが、12ヶ
月間に同じ組織に対して複数の割り当てを行う場合は、割り当てるアドレスの
総量が、そのローカルIRの割り当て枠を超えることはできない。この規則は、
レジストリが自己のネットワーク用に使用するアドレス空間にも適用される。
この枠を超えるアドレス空間の割り当てについては、必ずRIPE NCCの事前承認
が必要である。
通常、新規レジストリの割り当て枠は0である。これは、いかなる割り当ても、
RIPE NCCの事前承認がない限り無効であることを意味する。
ローカルIRのスタッフが割り当て手続きに慣れてくれば、割り当て枠を大きく
することができる。一般に、レジストリが提出する要求のサイズに合わせて、
枠が拡大される。たとえば、レジストリが、/25以下の要求をいくつか提出し、
それらの要求について特に問題がなければ、RIPE NCCは、割り当て枠を/25に
拡大する。この時点で、そのローカルIRスタッフは、RIPE NCCからの事前承認
なしに、最大128個のアドレスを割り当てることができるようになる。割り当
て枠の拡大要求をローカルIRから受け取った場合は、RIPE NCCは、そのローカ
ルIRの熟練度に基づいてその是非を評価する。この評価の根拠としては、RIPE
NCCに提出された割り当て申請書類が正しく記入されているかどうか、アドレ
ス空間要求の評価における判断が優れているかどうか、過去の割り当てが適切
に登録されているかどうか、そして、比較的大きい割り当ての処理に関するロー
カルIRの経験の程度が挙げられる。現在、ローカルIRに対する割り当て枠の最
大サイズは/19である。したがって、8192個を超えるアドレスの割り当てには、
RIPE NCCの承認が必要である。
確立されたローカルIRは、新たなスタッフに対し、本ドキュメントに記述され
ているポリシーおよび手続きに従ってアドレス空間割り当ての処理を行えるよ
う、トレーニングを施す責任を負うものとする。
____________________________________________________
ripe-185.txt Page 34
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ときには、十分に確立されたローカルIRにおいても、経験を積んだレジスト
リのスタッフに時間的制約があり、それが原因でトレーニングが十分に実施で
きないため、新規のスタッフメンバーが割り当てに関する適正なトレーニング
を受けないうちに判定や手続きにあたり、その両面で誤りを犯す可能性がある。
RIPE NCCがこのようなエラーに気付いたときは、ローカルIRにその旨通知する。
同じ誤りが繰り返される場合は、大量のアドレス空間の割り当てにおいて新規
スタッフによる過誤が生じるのを防ぐために、ローカルIRの割り当て枠を縮小
することがある。その場合も、上記の基準に従って割り当て枠を増やすことが
できる。
____________________________________________________
ripe-185.txt Page 35
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
4. 割り振りの規則とガイドライン
セクション3では、エンドユーザにどのアドレスを割り当てるかを決定するプ
ロセスも含めて、アドレス空間要求を処理する手続きについて説明した。ほと
んどの場合、アドレス空間は、割り当てのためにローカルIRに割り当てられて
いる範囲から選択される。当然のことながら、要求を満たすアドレスを選択す
るには、ローカルIRはその元になる一定範囲のアドレス空間を保有していなけ
ればならない。割り当てる必要のあるタイプの十分なアドレス空間を保有して
いない場合は、ローカルIRは、追加割り振りの要求をRIPE NCCに提出すること
ができる。
この需要を満たすために、RIPE NCCはローカルIRが一定範囲のアドレスを使用
できるようにする。このアドレス範囲を割り振りと呼ぶ。1つのレジストリが、
「オープン状態」の(つまり割り当て率が80%に達していない)/16割り振りを複
数保有することはできない。ヨーロッパでは、RIPE NCCがアドレス空間を割り
振ることを認められている唯一のIRである。ローカルIRは、自己への割り振り
の一部を他の組織に再割り振りすることはできない。また、RIPE NCCの事前承
認なくして、ローカルIR相互間で割り振られたアドレス空間を交換し合うこと
も認められない。
場合によっては、ローカルIRは、自身ではローカルIRを運営していない他の
IPサービスプロバイダのカスタマに対して、アドレス空間の割り当てを行う。
当然のことながら、ローカルIRは、合意に基づき他のサービスプロバイダのス
タッフの関与を認めた場合であっても、自己の割り振りからのすべての割り当
てに責任を負うものとする。エンドユーザの要求の処理については、相手方の
IPサービスプロバイダのスタッフの参画が可能であり、またそれが望ましいこ
とではあるが、地域レジストリは、ローカルIRと他のサービスプロバイダが登
録プロセスにおける共同責任に関する契約を取り交わすことを認めていないの
で、その種の契約は厳に避けていただきたい。
ある時点で、IPサービスプロバイダが、既存のローカルIRからアドレス空間を
取得するのをやめて、自身でローカルIRを設立することを決めた場合は、以後
そのサービスプロバイダが行う割り当てには、RIPE NCCがそのプロバイダに割
り振るアドレス空間を当てるものとする。さらに、そのISPのカスタマが通過
プロバイダの割り振りから取得して使用していたアドレス空間は、できるだけ
速やかに通過プロバイダに返還し、同ISPに割り振られたアドレス空間からエ
ンドユーザに対して新たな割り当てを行うものとする。
____________________________________________________
ripe-185.txt Page 36
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
以下のサブセクションでは、ローカルIRが割り振りを取得する方法、および
割り振られたアドレス空間を管理する方法について説明する。
4.1. スロースタートメカニズム
結果的に未割り当てのままになってしまうような大きなアドレス空間のブロッ
クを割り振るのを防ぐために、RIPE NCCでは、割り振りについてスロースター
トの概念を導入している。このアイデアは、割り当てられる率に応じてローカ
ルIRにアドレス空間を割り振るというものである。個々のアドレス空間割り振
りの最小サイズは/19(8192アドレス)で、最大サイズは/16(65536アドレス)で
ある。特定のローカルIRに対する割り振りのサイズは、そのIRが、これまでに
割り振られたアドレス空間をエンドユーザに割り当てた率のみを根拠として決
定される。
スロースタートメカニズムは、すべてのローカルIRにとって一貫性のある公正
な割り振りポリシーを実現するためのものである。このメカニズムは、セクショ
ン3.6で述べた割り当て枠のメカニズムに似ているが、実現するポリシーが異
なる。割り当て枠は、要求の評価と割り当ての処理を行うレジストリのスタッ
フの熟練度によって決まるが、割り振りのサイズの追加は、該当のローカルIR
の割り当て率のみによって決まる。割り振りを行うことができるのは、RIPE
NCCだけであるという点に注意されたい。レジストリは、他のISPまたはカスタ
マに対して、割り振りまたは2次割り振りを行うことはできない。レジストリ
が行うことができるのは割り当てだけである。
4.2. 最初の割り振り
新規のローカルIRが運営を開始する時点では、そのローカルIRにはまだアドレ
ス空間は割り振られていない。最初の割り振りは、通常、そのローカルIRから
の最初の割り当て要求をRIPE NCCが受け取った時点で、自動的に行われる。新
規IRについては、アドレス割り当てを行う率に関するデータがまったくないの
で、最初の割り振りのサイズは常に/19(8192アドレス)である。
ローカルIRが実施できる割り当てのサイズは、割り振られている空間の量によっ
て決まるのではないということを忘れないでいただきたい。セクション3の終
わりに述べたように、新規のローカルIRは、自己の割り当て枠が拡大されるま
での間は、各割り当てについてRIPE NCCの承認を得なければならない。
____________________________________________________
ripe-185.txt Page 37
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
4.3. 追加割り振り
ローカルIRは、必要に応じて追加割り振りを取得することができる。RIPE NCC
に追加割り振りを要求する必要があるのは、現在割り振られているアドレス空
間のほとんど(約80パーセント)を使い果たしてしまったとき、または、1つの
割り当てに必要とされるアドレス数が多すぎて、割り振られているアドレス空
間だけでは要求を満たすことができない場合である。「使い果たす」という言
葉は割り振りが実際の割り当てに使われたことを意味するのであり、リザーブ
は勘定に入れない。現在の割り当てを超えて成長することが予測されるカスタ
マがある場合は、レジストリは、割り振られたアドレス空間の一部をそれらの
カスタマ用として留保(つまり「リザーブ」)することができるが、自己の割り
振りを使い果たし、アドレス空間が不足する状態が生じた場合は、「リザーブ」
したブロックを他のカスタマに提供するために再利用しなければならない。
RIPE NCCでは、割り振り要求を評価する際に、「リザーブ」したブロックをを
フリーアドレス空間とみなす。
新たな割り振りを取得するには、ローカルIRは、前回の割り振り以降に行った
すべての割り当てのリストを含む要求を、RIPE NCCに提出しなければならない
(ただし、RIPE NCCは、80%使用の条件を満たしていることを確認するために、
それ以前の割り振りも含めて、過去の割り振りをすべてチェックする)。
RIPE NCCは、この情報をチェックし、データベースに登録されている割り当て
と比較検討した結果、新たな割り振りの必要性を判定するために、追加の情報
(一部の割り当てに関するドキュメンテーションなど)を求めることがある。要
求と共に提供された情報を検討した結果、新たな割り振りが必要と認められた
場合は、追加のアドレス空間が割り振られる。
残念ながら、割り振りを行うに際しては、集約目標と節約目標の間に背反が生
じる。集約性を高めるために、RIPE NCCはローカルIRに連続したアドレス範囲
を割り振ることを目指している。しかし、同時にアドレス空間の節約も考慮に
入れなければならないので、これは常に可能とは限らない。したがって、レジ
ストリに対する新規の割り振りは、過去の割り振りに連続したものになること
は期待できない。RIPE NCCは、常に集約目標を推進し、したがって連続した空
間を割り振ることを目指してはいるが、いかなる場合も、同じローカルIRに対
する複数の割り振りがそれぞれ以前の割り振りに連続した集約的なものになる
保証はまったくないというのが、RIPE NCCのポリシーである。
____________________________________________________
ripe-185.txt Page 38
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
4.4. 割り振りの登録
NCCは、inetnumオブジェクトを使用して割り振りをRIPEデータベースに登録す
る。データベースには、割り振られたアドレス空間の範囲とそのタイプと共に、
ローカルIRに関する情報(割り当てを受けるエンドユーザに関する情報に似た
もの)が格納される。アドレスの範囲はドットクワッド表記でinetnumフィール
ドに格納され、タイプは次のいずれかの値としてstatusフィールドに格納され
る。
ALLOCATED PA
このアドレス空間はIRに割り振られたもので、このアドレス空間からの割り当
てはすべてプロバイダに集約される。これは、ローカルIRの場合の最も一般的
な割り振りタイプである。
ALLOCATED PI
このアドレス空間はIRに割り振られたもので、このアドレス空間からの割り当
てはすべてプロバイダから独立したものとなる。
ALLOCATED UNSPECIFIED
このアドレス空間はIRに割り振られたもので、このアドレス空間からの割り当
ては、プロバイダ集約型にもプロバイダ独立型にもなる。このタイプの割り振
りは廃止されており、将来の割り振りには適用されない。古い割り振りにはま
だPA割り当てとPI割り当ての両方に使用されてきたものが残っており、その種
の割り振りにはこのタイプが与えられる。
これらのオブジェクトの保守はRIPE NCCが行う。階層的認可によって権限を与
えられている場合は、その権限を使用して、allocationオブジェクトの「下」
にinetnumオブジェクトを作成することができる。
____________________________________________________
ripe-185.txt Page 39
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
5. DNSとリバースアドレスマッピング
ftp、Eメール、およびtelnetなどのアプリケーションでは、ユーザは、インター
ネットホストを"ns.ripe.net"のようなドメイン名で指定することができる。
この表記により、ホストのフルネームが階層方式で決定される。上記の例の場
合、netはシステム内のトップレベルトップレベルドメインの1つ、ripeは net
ドメイン内で定義されているサブドメインの名前、そして、nsは "ripe.net"
ドメイン内のホストの名前である。この階層はUNIXファイ泣Vステムに似たも
ので、これによってインターネット上の各ホストを固有なものとして命名する
ことができる。
しかし、アプリケーションが特定の宛先にIPパケットを送信するためには、そ
の宛先のIPアドレスが分かっていなければならない。ホストの記号名が上記の
ドメイン名表記法で指定されていれば、分散階層ディレクトリサービスの1つ
であるドメインネームシステム(Domain Name System:DNS)を使用して、そのホ
ストのIPアドレスを取得することができる。これとは逆に、IPアドレスからド
メイン名を割り出すプロシージャをリバースアドレスマッピングと呼ぶ。この
セクションではこれについて説明する。
リバースアドレスマッピングはDNSの特定アプリケーションの1つにすぎないの
で、まずDNSについて簡単に紹介する。DNSの詳細説明は、[Albitz94a]に収め
てある。このセクションでは、RIPE NCCが割り振るアドレス空間に適用できる
リバースアドレスマッピングを行うプロシージャを理解するために必要な基礎
知識を提供する。
5.1. フォワード名前マッピング
DNSはクライアント/サーバシステムの1つである。ドメインネームサーバで適
正にデータが管理されていれば、使用されている各グローバルIPアドレスには、
厳密に1つのドメイン名が関連付けられている。特定のドメイン名に対応する
IPアドレスは、リゾルバと共に抽出することができる。リゾルバの働きは以下
に示すとおりである。あるマシンが、記号名で表されたホストのIPアドレスを
必要とし、そのアドレスをローカルで取得できない場合は、リゾルバを使用し
て、まずドメイン名が調べられ、次に、それに対応するIPアドレスがどのネー
ムサーバから得られるかが判別される。次に、リゾルバは該当のネームサーバ
に要求を送り、そのネームサーバは、求められているIPアドレスか、または、
詳細情報を提供できるサーバのアドレスを返す。後者の場合は、リゾルバは、
その新たなサーバに同じ要求を送る。そして、目的のIPアドレスが見つかるま
で(またはホストが未知のものであることが判明するまで)、この操作が繰り返
される。このプロシージャをフォワードマッピングまたはレゾリューションと
呼ぶ。
____________________________________________________
ripe-185.txt Page 40
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
当然のことながら、あるホストをDNSにより識別できるためには、そのホス
トがどれかのサーバに登録されていなければならない。名前登録に関する責任
は階層形式になっている。DNSネーム空間に関する責任を持つ組織は、そのネー
ム空間のサブセットの管理を、自己の下部組織の代表者にデリゲートする。上
記の例で言えば、トップレベルトップレベルドメインであるnetを管理するの
は InterNICである。InterNICはRIPE NCCの代表者にサブドメインripeをデリ
ゲートし、RIPE NCCでは、自己のネットワーク内のホストの1つにnsという名
前を与えている。ripe.net用のネームサーバの中でnsという名前が適正に指定
されると、ドメイン名ns.ripe.netを使用して、IP番号が193.0.0.193であるイ
ンターネットホストを見つけることができるようになる。
各ドメイン名のサフィックスは最高レベルドメイン(TLD)を表し、そのドメイ
ンを管理する権限はIANAによりデリゲートされる。通常、これはISO 3166の2
文字の国コードで、たとえば、オランダなら"nl"、フランスなら"fr"、米国な
ら"us"である。これらのコードは、各国固有のTLDとしてIANAによりデリゲー
トされている。(唯一の例外はドメイン".uk"で、これは、実際のISOコードが
"gb"であるグレートブリテンにデリゲートされている)。各国固有のTLDの管理
は、その国内に常駐する代表者にデリゲートされる。ある国固有のTLDに関す
る責任がまだデリゲートされていない場合は、その国の在住者がそのTLDを管
理する許可をIANAに求めることができる。そして、「RFC 1591[Postel94a]」
のガイドラインが満たされており、デリゲートの可能性を告知してからある程
度の短い期間内に異議が提起されない限り、TLDの管理責任はその要求者にデ
リゲートされる。
DNSが実装された初期には、少数の「総称的」な3文字のコードがTLDとして定
義されていた。これらのドメインはInterNICにより管理されており、米国内で
は現在も広く使用されている。従来、各種組織は、各自の主要業務に基づいて
TLDを選択してきている。たとえば、一般に、学術機関は"edu"、軍事組織は
"mil"、そして企業は"com"で終わる名前を使用している。
デリゲートのポリシーを決めるのは、デリゲートの対象となるドメインの管理
に責任を持つ組織である。たとえば、"edu"で終わる第2レベルドメイン名のデ
リゲートに関するポリシーは、InterNICが決定する。しかし、第3レベルドメ
イン名に関するデリゲートのポリシーを決めるのは、それに対応する第2レベ
ルドメイン名がデリゲートされている組織である。
____________________________________________________
ripe-185.txt Page 41
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
たとえば、Catatonic State Universityの代表者は、"cat.edu"の下位にあ
るサブドメインのデリゲートについて責任を負う。原則として、DNSドメイン
管理者が適用するデリゲートポリシーは、「RFC 1591[Postel94a]」に規定さ
れているガイドラインを満たしていることが望ましい。
ドメイン名をIPアドレスにマップするとき、関連のドメインに関する責任者が
管理するネームサーバは、名前解析のための十分な情報を提供する必要がある。
たとえば、"bite.dog.cat.edu"という名前のホストのIPアドレスを求める要求
が出されたとする。この場合、TLD "edu"におけるすべてのデリゲートについ
て責任を負うのは InterNICなので、この要求はまずInterNICのネームサーバ
に渡される。ドメイン"cat.edu"がCatatonic State Universityのネームサー
バにデリゲートされているとすれば、InterNICのネームサーバは、おそらく、
同大学のネームサーバにこの要求を送り、そのネームサーバは該当部門のネー
ムサーバに要求を渡す。すべてのネームサーバファイルが整っていれば、その
部門のネームサーバは、問題のドメイン名に該当するIPアドレスを提供するこ
とができるはずである。
これは、ネームレゾリューションがどのように行われるかを示す簡単な例であ
る。この例では、DNSを最適化するために使用される、キャッシングおよびそ
の他の代替手段は無視している。しかし、レゾリューションプロセスにおいて、
どの組織がどの情報を提供する責任があるかについての実際の図式は、これで
十分に分かる。
5.2. リバースアドレスデリゲートとリバースマッピング
特定のドメイン名を持つホストのIP番号の取得が必要になるのと同様に、それ
とは逆の操作を行うこと、つまり、特定のIPアドレスに対応するドメイン名の
取得が必要になることもしばしばある。たとえば、ある種のインターネットア
プリケーションおよび一部の診断サービスで行われる単純な認可チェックでは、
アドレスに対応する完全修飾ドメイン名が必要になる。与えられたIPアドレス
からそれに対応するドメイン名を取得するプロシージャを、リバースマッピン
グと呼ぶ。
DNSでは、これを可能にするために、"in-addr.arpa"("inverse addresses in
the Arpanet"を表す歴史的略称)という擬似ドメインが定義されている。アド
レス空間の割り振りと割り当てを行うのはIRなので、このドメイン内でのデリ
ゲートはIRが行う。たとえば、193/8における割り振りと割り当ての責任を負
うのはRIPE NCCなので、ドメイン"193.in-addr.arpa"はRIPE NCCにデリゲート
されている。
____________________________________________________
ripe-185.txt Page 42
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
RIPE NCCは、ドメイン"193.in-addr.arpa"の中の各名前に対応するアドレス
空間が割り振られ、割り当てられた後は、それらの名前に関する権限をデリゲー
トする。
193.3.20.100というドットクワッド表記のIP アドレスがあり、それに対応す
るドメイン名が必要になったとする。その場合、まず、アドレスコンポーネン
トを逆の順序に並べ替え、その後に".in- addr.arpa"というサフィックスを付
けて、擬似ドメイン名"100.20.3.193.inaddr.arpa"が生成される。次に、この
名前を使用して、リバースマッピングによりIPアドレスに対応するドメイン名
が検索される。擬似ドメイン内にこの名前が生成された後は、技術的には、リ
バースマッピングメカニズムはフォワードマッピングメカニズムと同じである。
フォワードマッピングおよびリバースマッピングに使用するメカニズムは同じ
であるが、ドメイン階層の権限が異なる。特に、総称TLDおよび各国固有TLDに
おけるデリゲートは前のセクションで述べた組織構造に従うが、擬似ドメイン
"in-addr.arpa"におけるデリゲートは、対応するアドレス空間の割り振りと割
り当てに責任を負う組織が担当する。
クラスレスアドレスの逆引きという言葉は、擬似ドメイン"inaddr.arpa"の中
でのIPアドレス名のデリゲートを指す。
たとえば、RIPE NCCには逆ドメイン名"193.in-addr.arpa"がクラスレスアドレ
スの逆引きされており、したがって、RIPE NCCには、193/8の範囲内で割り当
てられているIPアドレスに対応するドメイン名に到達するための情報を提供す
る責任がある。ここで注意する必要があるのは、擬似ドメイン内でのアドレス
名のクラスレスアドレスの逆引きは、アドレス空間の割り振りまたは割り当て
の時点で、自動的に発生するものではないということである。つまり、RIPE
NCCが管理するアドレス空間からのいかなる割り振りおよび割り当ての場合も、
クラスレスアドレスの逆引きは、RIPE NCCに対して明示的に出された要求に対
する応答として発生するだけである。もちろん、これは、IPアドレスからドメ
イン名への変換にリバースマッピングを使用する場合の前提条件である。
上記で述べたように、擬似ドメイン名は、IPアドレスに対応させて、ドットク
ワッド表記で生成される。そのためには、クラスレスアドレスの逆引きがオク
テットの境界上で発生する必要がある。たとえば、RIPE NCCが、Eye-Peaとい
う名前のローカルIRに、193.1.0/17という/17を1つ割り振るとする。
____________________________________________________
ripe-185.txt Page 43
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
この場合、Eye-Peaは、逆ドメイン"1.193.in-addr.arpa"に対応するアドレ
ス空間の1つのサブセットについて責任を負うだけなので、Eye-Peaに対しては、
"1.193.in-addr.arpa"という名前のクラスレスアドレスの逆引きは行われない。
したがって、RIPE NCCは、依然として、逆ドメイン名"1.193.in-addr.arpa"お
よびその下位にあるすべてのクラスレスアドレスの逆引きについて責任を負う。
これに対して、Aye-QueueというローカルIRに対して、たとえば193.2/16とい
う/16を1つ割り振ったとする。この場合は、Aye-Queueは193.2.0.0～
193.2.255.255のアドレス範囲内のすべての割り当てについて責任を負うので、
要求に応じて、ゾーン"2.193.in-addr.arpa"をAye-Queueにクラスレスアドレ
スの逆引きすることができる。したがって、Aye-Queueには、193.2.0.0～
193.2.255.255の範囲内のアドレスに関するリバースドメイン名情報を指すポ
インタを提供することが要求される。要求が認められれば、Aye-Queueは、
"2.193.in-addr.arpa"ゾーンに対する権限を持つことになるという点に注意さ
れたい。
この場合、Aye-Queueは、本ドキュメントのセクション3に示した手続きに従っ
て、たとえばOrganiserという名前の組織に、/24(たとえば193.2.40.0～
193.2.40.255)を割り当てることができる。したがって、Aye-Queueは
"40.2.193.in-addr.arpa"についてクラスレスアドレスの逆引きを行って、
193.2.40.0～193.2.40.255の範囲内のアドレスに対応するドメイン名に対する
要求が、Organiserに転送されるようにすることができる。
ここで注意しなければならないのは、クラスレススキームの場合、アドレス空
間の割り振りおよび割り当てはオクテットの境界上以外で行うことができるが、
クラスレスアドレスの逆引きはオクテットの境界上で発生しなければならない
ということである。これは、リバースドメイン名が、IPアドレスのドットクワッ
ド表記で指定されるからである。これは、オクテットCIDR境界上以外で発生す
る割り振りおよび割り当ての場合、少々異なるデリゲートストラテジーが必要
になることを意味する。これについては次のセクションで説明する。ただし、
基本的なシステムには変わりはない。
RIPE NCCはローカルIRと協力しながら、クラスレスアドレスの逆引きが正しく
行われるようにするための活動を推進する。これにより、リバースマッピング
を使用して、RIPE NCCが管理する範囲内の IPアドレスに対応するドメイン名
を検索することができる。この活動における両者の役割については、以下のサ
ブセクションで説明する。
____________________________________________________
ripe-185.txt Page 44
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
5.3. ローカルIRとクラスレスアドレスの逆引き
ローカルIRは、自分が割り当てるアドレス空間についてのクラスレスアドレス
の逆引きを取得すると、サービス対象のエンドユーザに対して、IP番号をドメ
イン名にマップするサービスを効率的に提供することができる。このセクショ
ンでは、クラスレスアドレスの逆引きを取得する方法について説明する。
最初に、逆アドレスドメイン名ゾーンに対する権限に付随する責任について説
明する。次に、CIDRアドレス空間の割り振りおよび割り当てが行われたときの、
リバースアドレスデータベースの適切な配布と保守について述べる。さらに、
クラスレスアドレスの逆引きを取得するための手続きを説明する。最後に、PA
アドレス空間とPIアドレス空間の割り当てに関するローカルIRに関連した事項
について考察する。
5.3.1. 責任
ドメイン名ゾーン(たとえば"cat.edu")のデリゲートの前に、そのゾーンに対
する権限がデリゲートされる人または組織は、そのゾーンから派生するドメイ
ン名をサポートするために必要ないくつかの主要サービスを提供することに同
意する。DNSが、IPアドレスからドメイン名への正確なマッピングを提供する
必要がある場合は、クラスレスアドレスの逆引きについても同様の同意が必要
である。
リバースドメインゾーンがローカルIRにデリゲートされる場合は、そのゾーン
に関するDNS構成ファイルを適切に構築するために、十分な注意を払う必要が
ある。「RFC 1537[Beertema93a]」に、陥りやすい過誤と、それを回避するた
めのヒントが紹介されている。
各ゾーンについて、不利な条件下でデータベースの信頼性を高めるために、セ
カンダリサーバをセットアップする必要がある。プライマリサーバが使用不能
になったときに、セカンダリサーバに到達できる可能性を高くするためには、
セカンダリサーバは、プライマリサーバとは物理的に異なるサブネット上にな
ければならない。ローカルIRに対する/16の割り振りに対応するクラスレスア
ドレスの逆引きの場合は、RIPE NCCは追加のセカンダリサーバを1つ提供する。
これは、必要なセカンダリサーバの代わりとなるものではなく、実質的なデリ
ゲートの信頼性をさらに高めるためのものである。ローカルIR、およびリバー
スドメイン名を管理するその他の組織にとっては、相互にセカンダリサービス
を提供し合うのが通例である。
____________________________________________________
ripe-185.txt Page 45
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
トップレベルトップレベルドメインネームサーバの場合に必要とされるよう
に、プライマリおよびセカンダリのどちらのリバースドメインネームサーバも、
インターネットから直接到達できることが必要である。
あるローカルIRにリバースドメイン名ゾーンに対する権限が与えられた場合、
そのIRは、そのゾーン内における以降のクラスレスアドレスの逆引きについて
責任を負う。したがって、そのローカルIRは、権限がデリゲートされる組織が、
該当ゾーンについてこのセクションに述べる要件を満たしていることを確認し
なければならない。リバースドメインネームシステムの適正な処理を確実に行
うためにRIPE NCCが提供するサービスについては、セクション5.4で述べる。
ローカルIRは、その内容を参考にしながら、クラスレスアドレスの逆引きを与
えるエンドユーザに対するサービスを提供する必要がある。
5.3.2. CIDRとクラスレスアドレスの逆引き
上記で述べたように、伝統的なクラス(オクテット)の境界ではなく、CIDRの境
界上で割り振りおよび割り当てを行うためには、クラスレスアドレスの逆引き
スキームについても若干の変更が必要とされる。基本的には、オクテット境界
以外で割り振りまたは割り当てを行う場合、対応するリバースドメインゾーン
に対する権限はデリゲートしてはならず、アドレス空間の割り振りまたは割り
当てを行うIRが保持していなければならない。
5.3.2.1. 割り振りとクラスレスアドレスの逆引き
あるローカルIRに対して/16より小さい割り振りが与えられた場合(たとえば、
前記の例でEye-Peaに対し193.1.0/17が割り振られた場合)、193.in-addr.arpa
の直下のサブドメインについての権限は付与できない。これは、対応するアド
レス空間のサブセットが別のローカルIRに割り振られることがあるからである。
193/8アドレス範囲内の/16より小さい単一の割り振りの場合、RIPE NCCは、
193.in-addr.arpaの直下のサブドメインに対する権限を保持し、対応するアド
レス空間要求の割り当て後に、要求に応じてクラスレスアドレスの逆引きが行
われる。当然のことながら、RIPE NCCが管理するいかなる/8アドレス空間割り
振りに対応するクラスレスアドレスの逆引きについても、この原則が適用され
る。
ある時点で、たまたまブロックの残りの部分(この例では193.1.128/17)が
Eye-Peaに割り振られたとすれば、1.193.in-addr.arpaのクラスレスアドレス
の逆引きに対する要求(ドメインデータベースオブジェクトが付随したもの)を
提出することができる。
____________________________________________________
ripe-185.txt Page 46
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ローカルIRにクラスレスアドレスの逆引きが与えられた場合、RIPE NCCは、
すべての関連データと、クラスレスアドレスの逆引きの対象ゾーンに関する責
任を、そのローカルIRに転送する。この例では、1.193.in-addr.arpaが
Eye-Peaにデリゲートされたとすれば、そのドメインからの過去および将来の
すべてのデリゲートがEye-Peaの権限下のものとなる。
これに対して、最初から/16がローカルIRに割り振られた場合について考えて
みる。たとえば、前記の例で、Aye-Queueに193.2/16が割り振られたとする。
この場合、Aye-Queue(割り振りを受けるローカルIR)は、193.in-addr.arpaの
サブドメイン(この例では2.193.in-addr.arpa)に対する権限をただちに要求す
ることができる。Aye-Queueは、リバースドメイン名2.193.in-addr.arpaに対
応するすべてのアドレス空間に関する責任を負うので、Aye-Queueにクラスレ
スアドレスの逆引きを付与することができる。
5.3.2.2. 割り当てとクラスレスアドレスの逆引き
クラスレスアドレスの逆引きに言及するとき、アドレス空間割り当ての2つの
カテゴリーを区別して考えることができる。それは、整数個の/24を含む割り
当てと、そうではない割り当てである。まず後者について説明する。
まず、/16のフル割り振りを保有するレジストリが行う割り当てについて考え
てみよう。再び前記の例において、Aye-Queueに193.2/16が割り振られており、
2.193.in-addr.arpaに対するクラスレスアドレスの逆引きを保持しているもの
とする。Aye-Queueは、193.2.0/26の中の64個のアドレスを、エンドユーザ(た
とえば Use-IQ)に割り当てる。上記の例に示した、Eye-Peaに/17を割り振った
場合に適用されたと同じ理由により、0.2.193.in-addr.arpaに対応するアドレ
ス空間の一部は他のエンドユーザに割り当てられる可能性があるので、Use-IQ
は0.2.193.in-addr.arpaについてのクラスレスアドレスの逆引きを取得するこ
とはできない。
この問題を解決するためには、Aye-Queueは、0.2.193.in-addr.arpaを自分自
身にデリゲートし、Use-IQ、および対応するアドレス空間が割り当てられる他
のすべてのエンドユーザについて、IPアドレス対ドメイン名の情報を保持する
ことができる。もちろん、このような同一組織へのデリゲートは必須条件では
ないが、複数ドメインの管理に役立つことがある。この手続きについては、
Eidnes98aで詳しく説明してある。ローカルIRは、自分が割り当てるアドレス
空間に関するクラスレスアドレスの逆引きを自身に与える場合は、RIPEデータ
ベースにdomainオブジェクトを提出して、そのクラスレスアドレスの逆引きを
登録する必要がある。
____________________________________________________
ripe-185.txt Page 47
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
Eye-Peaが、自分に割り振られている193.1.0/17アドレス空間から、同様の
割り当てを行うとする。この場合、Eye-Peaが、エンドユーザ(たとえば
Use-IP)に193.1.0.0/26を割り当てるとすると、上記と同じ問題が生じる。し
かも、Eye-Peaは、1.193.in-addr.arpaに対する権限を持っていないので、
0.1.193.in-addr.arpaを自身にデリゲートすることはできない。この方法をと
らずに、Eye-Peaは、対応する/24アドレス空間から少なくとも1つの割り当て
が行われた後で、要求により0.1.193.in-addr.arpaについてのクラスレスアド
レスの逆引きを取得することができる。クラスレスアドレスの逆引きを取得す
るために手続きについては、下記のセクション
5.3.3および5.5で概略を述べる。
もちろん、Use-IQが整数個の/24を割り当てられている場合も考えられる。た
とえば、193.2.0.0～193.2.2.255の範囲内の768個のアドレスが割り当てられ
ているとする。この場合、Aye-Queueは、Use-IQに対して
{0,1,2}.2.193.in-addr.arpaのクラスレスアドレスの逆引きを行うことができ
る。Aye-Queueが、クラスレスアドレスの逆引きを行うためにとる手続き、お
よびエンドユーザに提供すべきサービスについては、セクション5.4および5.5
で説明する。
では、Eye-Peaが、193.1.0.0～193.1.0.255の範囲内の256個のアドレスを
Use-IPに割り当てるとしよう。この場合、Use-IPは、対応するアドレス空間
から割り当てられるアドレスを持つ唯一のエンドユーザとなるので、Eye-Pea
はリバースドメイン 0.1.193.in-addr.arpaを管理する必要はない。このよう
な場合は、Eye-Peaとしては、エンドユーザがRIPE NCCに対しクラスレスアド
レスの逆引きを要求する(domainオブジェクトを使用する)のをサポートし、必
要に応じてセカンダリデータベースおよびその他のサービスを提供するのが妥
当である。詳細については次のセクションを参照されたい。
要約すれば、/24より小さい割り当てが行われた後で、ローカルIRは、自身に
割り当てられているアドレス空間がサブセットとして含まれている/24全体に
対応するリバースドメインについて、クラスレスアドレスの逆引きを取得する
ことが妥当と考えられる。その場合、ローカルIRは、エンド・[ザから提供さ
れるIPアドレス対ドメイン名の対応付け情報を反映したリバースマッピングエ
ントリを保守する必要がある。オクテットCIDR境界上以外で割り振りおよび割
り当てが行われた場合の、逆マッピングの管理については、[Eidnes98a]に詳
しい説明がある。
クラスレスアドレスの逆引きの手続きの概要が一目で分かるように、下記に、
エンドユーザ用とローカルIR用に分けて2つの表を示す。
____________________________________________________
ripe-185.txt Page 48
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
エンドユーザの場合:
+-------------------------------------+
| 割り振りサイズ |
+-------------------------------------+
| /16 </16 |
|割り当て >=/24 LIR NCC |
|サイズ </24 LIR LIR |
+-------------------------------------+
LIR = ユーザがローカルIRからのデリゲートを要求する。
NCC = ユーザがRIPE NCCからのデリゲートの要求をLIRに依頼する。
ローカルIRの場合:
+-------------------------------------+
| 割り振りサイズ |
+-------------------------------------+
| /16 </16 |
|割り当て >=/24 DF FR |
|サイズ </24 ML RR |
+-------------------------------------+
DF = さらにデリゲートする。
FR = 要求をRIPE NCCに転送する。
ML = ローカルに維持する。
RR = RIPE NCCからのデリゲートを要求し、ローカルに維持する。
5.3.3. クラスレスアドレスの逆引きの取得
ここでは、ローカルIRが、RIPE NCCからのクラスレスアドレスの逆引きを要求
するときに進める手続きについて説明する。前のセクションで述べたように、
ローカルIRは、/16についてはその割り振りの後で、また/24については、そこ
から1つ以上の割り当てが行われた後で、それに対する権限を取得することが
できる。どちらの場合の手続きもよく似ている。しかし、このセクションでは
/16のクラスレスアドレスの逆引きについて必要な手順についてのみ説明し、
/24の場合の手続きについてはセクション5.5で説明する。対象のアドレス空間
に対応するリバースドメイン名ゾーンに対する権限を取得するには、次の手順
に従う。
1. デリゲート要求の対象となるゾーンについてのDNS構成ファイルを構成する。
____________________________________________________
ripe-185.txt Page 49
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
「RFC 1537 [Beertema93a]」の内容に従い、RIPE NCCの権限下にあるドメイ
ンの直接サブドメイン(たとえば193.in-addr.arpa)の場合は、下記の設定が最
も望ましい。
Refresh = 8 時間(28800秒)
Retry = 2時間(7200秒)
Expire = 7日(604800秒)
Time To Live = 1日(86400秒)
接続が不安定な場合は、Retry(再試行)レベルをもっと低くすることを勧める。
2.
プライマリサーバおよびセカンダリサーバに構成ファイルをインストールす
る。ネームサーバが、193.0.0/23(RIPE NCCアドレス範囲)からのゾーン転送が
可能なものであることを確認する。
3.
RIPEデータベースドメインオブジェクト用として必要な情報を収集する。
domainフィールドには、要求するドメインの名前(たとえば
"0.194.in-addr.arpa")を入力する。1つまたは複数のdescrフィールドを使っ
て、問題のゾーンを保守する組織の記述を入力する。admin-c、tech-c、およ
びzone-cフィールドには、それぞれ、プライマリサーバのサイトにおける管理
責任者、同サイトの技術サポート責任者、およびゾーンに対する権限責任者を
指定する。nserverフィールド(最低3つは必要)には、プライマリ、セカンダリ、
および RIPE NCCリバースネームサーバのドメイン名を指定する。最後に、す
べてのRAIPEデータベースオブジェクトについて、changed sourceフィールド
を使用して、それぞれ、要求を行う人のEメールアドレス、およびデータベー
スソース"RIPE"を指定する。
たとえば、あるローカルIRに対し、カスタマへの割り当て用として 194.0.0.0～
194.0.255.255が割り振られているとすれば、そのIRは次のようなdomainオブ
ジェクトを提出する。
domain: 0.194.in-addr.arpa
descr: Our organisation allocation
admin-c: JLC2-RIPE
tech-c: PC111-RIPE
zone-c: JLC2-RIPE
nserver: ns.someserver.net
nserver: ns.otherserver.net
nserver: ns.ripe.net
changed: email@address.net 960731
source: RIPE
____________________________________________________
ripe-185.txt Page 50
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ネームサーバの1つは、ns.ripe.netでなければならないという点に注意され
たい。
domainオブジェクトは、クラスレスアドレスの逆引きを要求する前に、RIPEデー
タベースに入力しておかなければならない。
4.
クラスレスアドレスの逆引きの要求を<auto-inaddr@ripe.net>に提出する。
このステップでは、セクション5.3.1で述べた要件を満たしていることが必要
とされる。要求対象のゾーンの上位ゾーンに関するゾーンファイルエントリと
共に、上記のdomainオブジェクトを要求に含める必要がある。たとえば、
1.193.in-addr.arpaについてクラスレスアドレスの逆引きを要求する場合は、
193.in-addr.arpaについての関連ゾーンファイルエントリを含め、
2.2.193.in-addr.arpaについてクラスレスアドレスの逆引きを要求する場合は、
2.193.in-addr.arpaについてのゾーンファイルエントリを含める。(これは、
<auto-inaddr@ripe.net>に対する1つの要求である)。
下記に述べるように、RIPE NCCはプライマリサーバおよびセカンダリサーバが
適切に働くかどうかをテストする。要求を出したローカルIRに対し、要求の対
象となっているリバースドメイン名ゾーンに対応するアドレス空間が割り振ら
れており、サーバが適正に働いていれば、デリゲート要求は認可される。次の
セクションでは、RIPE NCCが提供するサービスについて説明する。
5.3.4. PA/PI割り当ての副次効果
エンドユーザには、リバースマッピングサービスに対する権利がある。あるサー
ビスプロバイダに対してクラスレスアドレスの逆引きされているゾーンからの
非PAアドレス空間を持つエンドユーザは、そのアドレス空間を保有しながら、
他のプロバイダから接続サービスを取得することができる。このアドレス空間
は最初のローカルIRのクラスレスアドレスの逆引きゾーンに含まれるので、そ
のIRは、エンドユーザに割り当てられているアドレス空間に関するリバースマッ
ピングサービスを、引き続き提供する必要がある。さらに、ローカルIRは、他
のエンドユーザに適用するのと同じ条件でこのサービスを提供しなければなら
ない(たとえば、すべてのエンドユーザに等しく適用される場合を除き、この
サービスについての極度に高額な料金は認められない)。
PAアドレスの場合は、契約を伴う合意により、リバースマッピングサービスの
提供が、割り当ての有効期限内に厳密に制限される。
____________________________________________________
ripe-185.txt Page 51
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
これは、割り当てを行うローカルIRとそのカスタマにとって、非PAアドレス
空間をPAアドレス空間に変換することが最大の利益をもたらすということの
明白な理由の1つである。
5.4. クラスレスアドレスの逆引きに関するRIPE NCCのサービス
RIPE NCCは、193/8またはIANAより割り振られたその他の/8から、ローカル IR
にアドレス空間を割り振るので、そのアドレス空間に対応するクラスレスアド
レスの逆引きについて責任を負う。したがって、RIPE NCCが割り振ったアドレ
ス空間から割り当てられたアドレス空間に関するリバースマッピングを解析す
る要求は、RIPE NCCに送る必要がある。あるアドレスについてリバースマッピ
ングが必要になったときに、そのアドレスの発端となっている地域IRが分から
ない場合は、RIPE NCCに要求を送ることができる。該当のアドレス空間が他の
地域レジストリのどれかから割り振られているものである場合は、そのレジス
トリに関する詳細な連絡情報が返される。当然のことだが、割り振られても
(/16の場合)、割り当てられ登録されても(/24の場合)いないIPアドレスの場合
は、リバースマッピングを行うことはできない。
193.in-addr.arpa、194.in-addr.arpa、195.in-addr.arpa、62.in-addr.arpa、
または212.in-addr.arpaの直下のサブドメインのクラスレスアドレスの逆引き
に関する要求を受け取ると、RIPE NCCは、まず、対応するすべてのアドレス空
間が要求元のIRに割り振られているかどうかをチェックする。要求が/24に対
するものである場合は、該当アドレス空間の一部またはすべてが割り当て済み
かどうかがチェックされる。必要な割り振り(割り当て)が行われていれば、次
のサービスが行われる。
1.
domainオブジェクトに指定されているプライマリサーバおよびセカンダリサー
バへのアクセスがテストされる。
2.
対応するアドレス空間の中のすでに登録済みのリバースゾーンに関するデー
タが、新たに定義するリバースゾーンファイルに含めるために、要求元の組織
に転送される。(クラスレスアドレスの逆引きが行われる場合は、過去のデリ
ゲートに関する責任も要求元の組織に転送される)。
3.
要求と共に提供された情報を使用して、リバースドメインネームサーバがテ
ストされる。
/16クラスレスアドレスの逆引きの場合は、次の2つの作業も行われる。
4. クラスレスアドレスの逆引き要求を認可する場合は、RIPE NCCは、
ns.ripe.net上にリバースドメイン用のセカンダリサーバをセットアップし、
ローカルIRに通知する。
____________________________________________________
ripe-185.txt Page 52
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
5.
クラスレスアドレスの逆引きが行われた後で、デリゲートしたゾーンに対応
するアドレス空間のクラスレスアドレスの逆引きを求めるためにRIPE NCCに出
された要求が、リバースゾーン構成ファイルのSOA RRフィールドに指定されて
いるメールボックスと、domainオブジェクトのzone-cフィールドに指定されて
いる担当者に転送される。
現在RIPE NCCでは、クラスレスアドレスの逆引きに関するすべての要求が、自
動プロシージャにより処理されるようになっている。要求に関する上記で述べ
たゾーン情報は、<auto-inaddr@ripe.net>メールボックスに受信された時点で、
自動的にチェックされる。自動ロボットがこのチェックの一環としてゾーン転
送を行うので、193.0.0/23(RIPE NCCのアドレス範囲)からのゾーン転送が可能
であることを確認していただきたい。ゾーンが適正にセットアップされていて、
すべてが整っていれば、要求は認可される(ときには、RIPE NCCのスタッフメ
ンバーが手動で追加の査定を行った後になることもある)。
この手続きの詳細については、http://www.ripe.net/inaddrを参照されたい。
クラスレスアドレスの逆引きを要求方法を示すチェックリスト式のガイドと、
その他の情報が収められている。
クラスレスアドレスの逆引きを取得したローカルIRは、自己のエンドユーザに
割り当てられているIPアドレスに関するリバースマッピングサービスを管理す
ることができる。これにより、エンドユーザは、IPアドレXにしかアクセスで
きないネットワーク上のホストからも、迅速かつ容易に識別できるようになる。
データベースは分散性を備えているため、データベースが効率的に働くかどう
かは、すべてのゾーンの正しい管理にかかっている。まれな例ではあるが、デ
リゲートされたゾーンを管理している組織が、必要なサービスを正しく実施で
きないと判明することもある。RIPE NCCがデリゲートしたゾーンの管理につい
ての苦情が何度も発生するような場合は、RIPE NCCは、効率的かつ正確なリバー
スマッピングを確保するための最終的な手段として、デリゲートを取り消すこ
ともある。
5.5. エンドユーザに対するクラスレスアドレスの逆引き
ここまでは、ローカルIRへのゾーンのクラスレスアドレスの逆引きを中心とす
る手続きについて説明してきた。DNSにより配布されるデータの信頼性は、デー
タソースへの距離が短いほど高まるので、エンドユーザに対しても、割り当て
られる各/24ごとにゾーンのクラスレスアドレスの逆引きを与えることができ
る。
____________________________________________________
ripe-185.txt Page 53
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
この文脈では、/22割り当ては単に複数の/24割り当てにすぎないので、複数の
クラスレスアドレスの逆引きが要求されることになる。
エンドユーザが、ローカルIRに割り振られているアドレス空間の中から自己に
割り当てられたアドレス空間(1つまたは複数の/24)に対応するクラスレスアド
レスの逆引きを要求する際には、常にローカルIRがそのサポートを行うべきで
ある。エンドユーザに対し、クラスレスアドレスの逆引きを取得するための手
段と、それに伴う責任を知らせることが必要である。
基本的には、エンドユーザに対するクラスレスアドレスの逆引きの場合も、ロー
カル IRの場合と同じ基準が適用される。特定のゾーンに対する権限を要求す
るエンドユーザは、セクション5.3.1に述べた責任を果たすことに同意しなけ
ればならない。手続きについては、セクション5.3.3で述べた内容とは若干の
相違がある。エンドユーザは、クラスレスアドレスの逆引きおよびそれに関連
した手続きに対する責任を負うが、ローカルIRは、従来の慣習通り、エンドユー
ザが各自のアドレス空間に関するクラスレスアドレスの逆引きを取得し維持す
るためのサポートを提供する必要がある。たとえば、クラスレスアドレスの逆
引き用のセカンダリサーバを提供することは、割り当てを行うローカルIRの日
常的な業務の1つである。
Eye-PeaのようなローカルIRが、/19、/18、または/17アドレス範囲の割り振り
を保有している場合は、クラスレスアドレスの逆引きは、そのローカルIRでは
なくRIPE NCCが行わなければならない。その場合、割り当てられる個々の/24
ごとにdomainデータベースオブジェクトをRIPEデータベースに提出し、要求を
<auto-inaddr@ripe.net>に送らなければならない。下記にdomainオブジェクト
の例を示す。
1つの/24が複数の小規模なカスタマに分配される場合は、その/24全体につい
て1つのdomainオブジェクトを、データベースおよび <auto-inaddr@ripe.net>
に送るものとする。
たとえば、ローカルIRが、カスタマAに194.0.0.0～194.0.0.127を割り当て、
カスタマBに194.0.0.128～194.0.0.255を割り当てたとすれば、下記の例に示
すような単一のdomainオブジェクトを、<auto-inaddr@ripe.net>に提出する必
要がある(詳細については、[Eidnes98a]を参照されたい)。ローカルIRは、/24
の全体が割り当てで埋まるまで待たずに、クラスレスアドレスの逆引きを要求
することができる。
domain: 0.0.194.in-addr.arpa
descr: our company
admin-c: JLC2-RIPE
____________________________________________________
ripe-185.txt Page 54
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
tech-c: PC111-RIPE
zone-c: JLC2-RIPE
nserver: ns.someserver.net
nserver: ns.otherserver.net
changed: email@address.net 990731
source: RIPE
ここにリストするネームサーバの1つとして、ns.ripe.netを指定することのな
いよう注意されたい。
RIPE NCCがアドレス空間のクラスレスアドレスの逆引きを行うのは、必ず、そ
のアドレス空間がエンドユーザに割り当てられてからであるという点に注意さ
れたい(ただし、/16の割り振りの場合を除く)。レジストリに割り振られては
いるが、まだエンドユーザに割り当てられていないアドレス空間については、
RIPE NCCはクラスレスアドレスの逆引きを行わない。また、RIPE NCCの承認を
得ずにレジストリの割り当て枠を超えて割り当てられたアドレス空間について
も、RIPE NCCはクラスレスアドレスの逆引きを行わない。したがって、クラス
レスアドレスの逆引きを要求するには、その前にデータベース内で割り当ての
inetnumオブジェクトをアップデートすることも必要である。その場合、割り
当てがPI(プロバイダ独立)かPA(プロバイダ集約)かが、statusフィールドに指
定されていなければならない。
RIPE NCCは、RIPEデータベース内に見つからないアドレス空間のクラスレスア
ドレスの逆引きは行わないので、ローカルIRは、まず、domainオブジェクトに
より<auto-dbm@ripe.net>のRIPEデータベースをアップデートする必要がある。
<auto-inaddr@ripe.net>にクラスレスアドレスの逆引き要求を送るときは、E
メールの件名行でキーワードを使用して、チェックプロセスを制御することが
できる。これについては、極力LONGACKキーワードを使用することを勧める。
これを使用すると、可能な限り最も長い出力が送り返される。その他のキーワー
ドには、HELP、CHANGE、TESTがある。HELPの場合は、本ドキュメントのこの章
が送り返される。CHANGEは、既存のクラスレスアドレスの逆引きを変更する場
合に使用する。TESTを使用した場合は、実際の要求は出されずに、既存のデリ
ゲートのテストが行われるだけである。
特殊な要求、RIPE NCCゾーンファイル内のクラスレスアドレスの逆引きされた
アドレス空間の削除、バグレポート、コメント、または、人間による介入など
について情報が必要なときは、ローカルIRは<inaddr@ripe.net>に連絡するこ
とができる。
Aye-Queueのように/16割り振りを保有しているローカルIRは、自己に対してク
ラスレスアドレスの逆引きを与えることもできるが、RIPEデータベースに
domainオブジェクトを提出して、割り当てのクラスレスアドレスの逆引きを登
録することが望ましい。
____________________________________________________
ripe-185.txt Page 55
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
いずれの場合も、ローカルIRは、RIPE NCCが提供するのと同様のサービスを
実施し、要求されたデリゲートが適正なものであり、正しく管理されているこ
と確認することが望ましい。たとえば、割り当てられたアドレス空間は要求さ
れたゾーンに対応していなければならず、プライマリサーバおよびセカンダリ
サーバについては、到達可能であることと適正に構成されていることを確認す
るテストが必要である。
____________________________________________________
ripe-185.txt Page 56
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
6. ローカルインターネットレジストリの運営
ローカルインターネットレジストリ(ローカルIR)は、エンドユーザに対するア
ドレス空間の割り当ての大半を処理する。ほとんどのローカルIRは、インター
ネットサービスプロバイダ(ISP)により運営され、ISPのカスタマに対してIP登
録サービスを提供する。
このセクションでは、本ドキュメントで概説するポリシーの統一的な実装を容
易にするために、RIPE NCCが提供するさまざまのサービスについて説明する。
また、ポリシーをRIPE NCCのサービス対象地域全体に公正かつ公平な方法で適
用するためにローカルIRが従うべき、IP登録サービスの関連手続きについても
概説する。
6.1. RIPE NCC登録サービス
RIPE NCCは、料金納入者のローカルIRに対して、一定範囲の登録サービスを提
供している。これらのサービスの大多数については、本ドキュメントの別の章
に説明がある。
これらのサービスに関連する要求および照会は、ほとんどすべてEメールを通
じて取り扱う。各種の要求および照会を取り扱うための、一連の役割メールボッ
クスが利用可能になっている。メールボックスには、RIPE NCCのスタッフが常
時サービスに当たるものと、自動処理により受け付けるものがある。NCCスタッ
フの個人的なメールボックスを使用して要求の処理が行われることはない。郵
便による要求や照会は、可能な限り避けていただきたい。文書として形を残す
ためおよび誤解を避けるために、電話による連絡の後ではEメールによる確認
が必要である。<ncc@ripe.net>は、一般的な照会および要求を受け付ける汎用
メールボックスとして利用できるが、特定の要求の申請を受け付けるメールボッ
クスがほかにもいろいろある。「自動」メールボックスはすべて自動処理され、
担当者が読むことはない。この種のメールボックスは、個別の特定タスクを行
うためのものなので、特殊なメッセージや情報を入れても、それがNCCのスタッ
フの目に触れることはない。RIPE NCCのメールボックスには次のものがある。
<hostmaster@ripe.net>
これは、登録サービス用のメールボックスであり、ローカルIRとRIPE NCCと
を結ぶ主要インタフェースである。IPアドレス空間およびAS番号の割り振り要
求および割り当て要求は、ここに提出する。IPアドレスに関連する要求および
AS番号の要求に関してRIPE NCCに送るすべての通信は、このアドレス宛にEメー
ルで送信する必要がある。ただし、IPアドレス要求に関連する情報のうち、ネッ
トワークトポロジーおよびその他のドキュメント等、ハードコピーでのみ提供
可能な情報は、ファックスで送信することができる。
____________________________________________________
ripe-185.txt Page 57
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ファックスで送信するドキュメントには、件名行またはメッセージのどこか
に、要求のチケット番号を入れておく必要がある。PostScriptで使用可能なド
キュメントは、ファックスでなくEメールで送信してもよい。
<auto-dbm@ripe.net>
これは、RIPEネットワーク管理データベースに対するアップデートの要求を
取り扱う自動メールボックスである。このメールボックスは、要求を分析し、
認可に関するチェックを行い、要求された実際のアップデートを行うロボット
である。
<ripe-dbm@ripe.net>
RIPEネットワーク管理データベースに関する質問および要求のうち、担当者
の対応を必要とするものは、このメールボックスに送信されたい。
<auto-inaddr@ripe.net>
このメールボックスは、in-addr.arpaドメイン(IPアドレスからホスト名への
リバースマッピングのために使用されるドメイン)におけるDNSデリゲートの要
求を取り扱うロボットである。要求されたデリゲートの対象になっているDNS
サーバが適正にセットアップされているかどうか調べるため、各要求の分析と
技術面のチェックが行われる。すべてのチェックに合格すると、要求は
<inaddr@ripe.net>に転送される。
<inaddr@ripe.net>
自動ツールによるチェックに合格した各デリゲート要求に対する追加の手動
チェックが行われる。要求に従ってNCC DNS構成がアップデートされる。通常
とは異なる要求、およびクラスレスアドレスの逆引きに関する一般的質問も、
このメールボックスに提出できる。
<training@ripe.net>
開催が予定されているローカルIR研修コースについての質問は、このアカウ
ントに送信していただきたい。同様に、研修参加希望者もこのアドレスにEメー
ルを送って登録されたい。
<billing@ripe.net>
これは、請求書の送付、および請求書に関連する質問の受け付けと回答を取
り扱う役割アカウントである。
<ncc@ripe.net>
一般的な照会は、この役割アカウントに送信されたい。特定の質問または要
求をどの役割アカウントに提出すればいいか確信がない場合は、このメールボッ
クスを利用できる。照会に対しては、回答を送るか、または必要に応じて適切
と思われる他の役割ボックスまたは特定のスタッフメンバーに転送する。
<new-lir@ripe.net>
このメールボックスは、新規レジストリの設定を取り扱う。詳細については
下記を参照されたい。
____________________________________________________
ripe-185.txt Page 58
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ローカルIRのリスト
RIPE NCCは、そのサービス地域内のすべてのローカルIRのリストを維持してい
る。このリストには、各レジストリに関する一連の情報が含まれている。この
情報の一部は、他のレジストリおよびアドレス空間ユーザが参照できるように
公開されている。各ローカルIRの公開データは次のサイトで入手できる。
http://www.ripe.net/lir/registries/indices/index.html
6.2. 新規レジストリの設立
ローカルIRの設立は、本ドキュメントおよび関連ドキュメントに定義されてい
る関連の規則およびガイドラインを了解していることを確認し、それらの規則
およびガイドラインに従うことを確約することを明記した要求を、RIPE NCCに
提出した後で行われる。新規レジストリの設立プロセスについては、
"Guidelines for Setting up a Local Internet Registry"(現在は「ripe-160
[Caslav98a]」)で詳細に説明されている。
6.3. メーリングリスト
RIPE NCCは、ローカルレジストリにとっての関心対象となる一連のメーリング
リストを保持している。メーリングリストには、LIRにとって加入必須のもの
がある。つまり、各レジストリは少なくとも1つのEメールアドレスを加入させ
る必要があり、代わりのアドレスを提示しない限り、そのEメールアドレスを
削除することはできない。
<local-ir@ripe.net>
レジストリの運営に関する問題は、すべてここで論議する。開催予定のロー
カルIR研修コースの発表、およびその他の、すべてのローカルIRにとっての関
心事項は、このリストに投稿される。このリストはモデレータ(司会)が管理す
るクローズドリストで、料金納入者のローカルレジストリに対してのみオープ
ンされる。このメーリングリストは加入必須である。各レジストリは、少なく
とも1つのEメールアドレスをこのメーリングリストに加入させる必要がある。
加入したEメールアドレスを別のアドレスに変更する場合は、
<hostmaster@ripe.net>に連絡されたい。
<lir-wg@ripe.net>
これは、ローカルIRワーキンググループのメーリングリストで、誰でも参加
できる。このリストにはモデレータはいない。ローカルIRのポリシーおよび登
録サービスに関する一般的なディスカッションも、このリストに含まれる。こ
のメーリングリストはオプションであるが、RIPE NCCでは、ここで行われるディ
スカッションに常に注目していることを各レジストリに強く勧奨する。レジス
トリがこのリストに参加するには、<majordomo@ripe.net>に要求を送る必要が
ある。
____________________________________________________
ripe-185.txt Page 59
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
<ncc-co@terena.nl>
これは、RIPE NCC Contributors Committee(RIPE NCC料金納入者委員会)のメー
リングリストである。NCCの運営に関する正式な問題はすべてここで論議する。
たとえば、RIPE NCCの活動計画や予算に関する事項は、常にここに記入され、
ここで論議される。このメーリングリストも加入必須である。各レジストリは、
少なくとも1つのEメールアドレスをこのメーリングリストに加入させる必要が
ある。加入したEメールアドレスを別のアドレスに変更する場合は、
<hostmaster@ripe.net>に連絡されたい。
<lst-provs@ripe.net>
これは、RIPE NCCが受信したインターネットサービスに対する要求を配布する
ために使用されるメーリングリストである。このメーリングリストはオプショ
ンであるが、ローカルIRに対してのみオープンされている。加入または脱退の
手続きについては、<hostmaster@ripe.net>に連絡されたい。
上記の各リストは、重要な発表や運営上の情報を通知するために使用される。
各レジストリで少なくとも1人の担当者が、これらのリストを常にチェックし、
リストに送られる情報を読んでいることが前提とされる。
新規参入のレジストリでは、スタッフメンバーの中の少なくとも1人がローカ
ルIR研修コースに参加することを強く勧奨する。これは1日の研修で、ヨーロッ
パにおけるインターネットアドレス空間の割り当てと登録手続きの概要を説明
する。RIPEデータベースに登録されている情報の照会と利用の方法についても
説明する。NCCでは、開催予定のコースをローカルIRメーリングリストに発表
する。
6.4. レジストリの運営
このセクションでは、ローカルIRの運営時に従うべきさまざまの慣例について
概説する。多くは、現在に至るまでの歴史の中で、RIPEコミュニティのローカ
ルIR相互の総意により確立されたものである。ローカルIRは、確立済みの慣例
に従うものとし、その変更を提案する場合は<local-ir@ripe.net>メーリング
リストでディスカッションを開始し、ローカルIRワーキンググループに積極的
に参加するものとする。
記録の保持
ローカルIRには、すべてのレジストリ活動に関する適正な記録を保持する義務
がある。各ローカルIRは、IPアドレス空間の割り当て要求を申請する過程でカ
スタマから収集した情報をすべて保管しておく必要がある。
____________________________________________________
ripe-185.txt Page 60
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
このデータは、同じカスタマに関する後続の要求を評価する場合、地域レジ
ストリによる監査を行う場合、および割り当てに関して起こり得る疑問を解決
する場合に必要となる。この記録には、次のものが含まれる。
o 要求のオリジナル書類
o すべてのサポートドキュメンテーション
o 要求に関連してレジストリとカスタマの間で交わされたすべての通信
o 割り当ての決定。これには次のものを含む。
o 通常と異なる決定がある場合には、その裏付けとなる理由
o 決定の責任者
各イベントの発生日時および責任者を記録の中に明記しておく必要がある。情
報の交換を促進するために、ドキュメントを電子化していつでもアクセスでき
る状態で保存することを勧奨する。この情報はどれも、RIPE NCCから要求があっ
た場合には英語で提出できるようにしておく必要がある。
外部的な品質保証
アドレス空間の節約と登録および経路情報の集約に関し、一貫性のある公正な
割り当て基準の適用を促進するために、RIPE NCCは、レジストリデータの整合
性検査およびレジストリの監査の活動を開始した。レジストリが割り当て基準
に従っていること、およびデータベースに割り当てを正しく入力していること
を確認するために、RIPE NCCはレジストリに連絡して特定の要求またはデータ
ベース項目についてのドキュメンテーションまたは詳細情報の提出を求める場
合がある。問題を発見した場合、NCCはレジストリと協力して問題の是正に当
たり、レジストリの割り当て枠を縮小するなどの措置をとることもある。この
活動については、"RIPE NCC Consistency & Auditing Activity" (現在は
「ripe-170 [Caslav97a]」)で詳細に説明されている。
レジストリID
<hostmaster@ripe.net>に送信するすべてのメッセージには、レジストリIDを
含める必要がある。レジストリIDは、レジストリを識別するために使用される。
有効なIDを含む各要求に対しては、サービスを受けられるかどうか、およびチ
ケット番号(下記を参照)を示す確認の応答が返される。
____________________________________________________
ripe-185.txt Page 61
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
料金納入者委員会(詳細はripe-132 [Kuehne95a]を参照)が設定したポリシー
に従い、RIPE NCCは、料金納入者のみにサービスを提供する。料金納入者のロー
カルIRから受けた要求は、受け付け順に処理される。納入が遅れているローカ
ルIRからの要求は、支払い状況が是正されるまで、サービスの対象とはみなさ
れない。有効なレジストリIDが含まれていない要求は、取り扱いの対象とはな
らない。可能な場合には、該当のメッセージのRFC822ヘッダ行にIDを含めるよ
うにされたい。推奨する形式は次のとおりである。
X-NCC-RegID: nn.example
RFC822ヘッダの変更が不能な場合は、この行をメッセージ本分に含めてもさし
つかえない。レジストリIDは小文字で入力する必要があることに注意されたい
(IDでは、大文字小文字が区別される)。詳細については、「ripe-183
[Karrenberg94a]」を参照されたい。
チケットシステム
RIPE NCCでは、<hostmas-ter@ripe.net>に送られた個々の要求の履歴を追跡す
るために、チケットシステムを採用している。この役割アカウントに要求を提
出すると、その要求に割り当てられたチケット番号が通知される。同じ要求に
関連する後続のすべてのメッセージには、このチケット番号を明記する必要が
ある。チケット番号は、要求の処理が完了するまで有効である。個々の新しい
要求に対して、新しいチケット番号が与えられる。つまり、ローカルIRは同じ
メッセージの中に2つの要求を入れて送信してはならないということである。
さらに、チケット番号は特定の要求に関連付けられているので、同じ番号を再
使用してはならない。詳細については、「ripe-183 [Karrenberg94a]」を参照
されたい。レジストリは、下記のRIPE NCC Web サイトで、各自のチケットの
状況をチェックすることができる。
http://www.ripe.net/cgi-bin/rttquery
配信ロボット
RIPE NCCは、自動ロボットを使用して<hostmaster@ripe.net>に送られたすべ
てのメッセージを配信し、IPアドレス空間要求の構文チェックを行っている。
このロボットとの対話に関するヘルプが必要な場合は、下記のRIPE NCC Web
サイトを参照されたい。
http://www.ripe.net/lir/services/status.html
____________________________________________________
ripe-185.txt Page 62
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
連絡担当者
各ローカルIRは、連絡時の窓口となる担当者のリストをRIPE NCCに提出する必
要がある。連絡担当者は、ローカルIRを代表してアドレス空間とAS番号の要求
を提出する者でなければならない。連絡担当者に関する情報は、常に最新の状
態に保つ必要がある。通常、アドレス空間およびAS番号の要求が受理されるの
は、ローカルIRを代表する連絡担当者として登録されているレジストリスタッ
フメンバからその要求が提出された場合に限られる。
機密性
登録の過程でレジストリが収集した情報は、厳重な機密扱いニしなければなら
ない。この情報は、登録目的のみに使用するものとする。この情報は、上位の
レジストリまたはIANAからの要求に基づき、それらの上位レジストリまたは
IANA(あるいはその両者)のみに転送するものとする。エンドユーザからの書面
により明示された要求がない限り、この情報を上記以外の相手に転送してはな
らない。
ローカルIRポリシーの公開
ローカルIRの中核業務は、IPアドレスを割り当てることである。IPアドレスは
インターネット接続には不可欠なものではあるが、それ自体に価値があるもの
ではない。IPアドレスの割り当てに際しては、十分な検討に基づいて量を決定
し、集約のために最善の努力を払い、異なるISP間での公平を期する必要があ
る。この目標を達成する上で最良の保証となるものは、ローカルIRのポリシー
についての「完全な知識」を市場が持っているということである。したがって、
各ローカルIRは、レジストリの運営に関する各自のポリシーを公開する必要が
ある。ローカルIRはRIPE NCCにポリシーを登録し、RIPE NCCがそれらのポリシー
を公開する。公開する情報には、少なくとも下記の事項が含まれていなければ
ならない。
1) サービス対象のコミュニティ
ローカルIRは、サービス対象のコミュニティに関する簡潔な説明を提供する。
これは、次のような説明で十分である。"We serve customers of <foo>
company, an ISP with mostly <bar> type customers based in countries NN
AA BB and CC."(<foo>社のカスタマに対してサービスを提供している。<foo>
社は、NN AA、BB、およびCCの各国をベースに、主として<bar>タイプのカスタ
マを擁するISPである。)レジストリは、自社から他のサービスを購入しないカ
スタマに対してもIPアドレス空間登録サービスを提供するかどうかも明示する
必要がある。
2) 課金ポリシー
ローカルIRは、その課金ポリシーを公開する必要がある。このポリシーは
「ripe-152 [Norris96a]」で、次のように定義されている。「アドレス空間は、
内在価値を持たない有限の資源であり、直接費用をそれに帰することはできな
い。
____________________________________________________
ripe-185.txt Page 63
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
レジストリは、アドレス空間自体に内在価値があるものとして課金すること
はできないが、アドレス空間の管理および技術サービスに対しては課金できる。
レジストリは、提供するサービスの運用手続きと詳細、および適用する条件
(適用する料金基準がある場合はそれも含む)を公開しなければならない。」
3) 割り当ての条件
レジストリは、プロバイダ集約アドレス空間とプロバイダ独立アドレス空間に
関するポリシー、およびそれに適用する条件を公開する必要がある。
6.5. レジストリの所有権の変更
ローカルインターネットレジストリの所有権が(買収または他社との合併によ
り)変更された場合は、RIPE NCCに所有権の変更を連絡する必要がある。ケー
スに応じて、RIPE NCCは新しい所有者からの新規サービス契約を要求すること
がある。また、要求を送信する連絡担当者がすべて変更になった場合は、新し
い連絡担当者がRIPE NCCの手続きとポリシーに基づき最新の状態になるまで、
NCCは割り当て枠を引き下げることがある。
レジストリは、他の既存のレジストリに経営権が引き継がれたり、合併される
ことがある。このような場合も同様に、RIPE NCCに通知する必要がある。当事
者である両レジストリは、どちらか一方のレジストリが閉鎖する場合に割り振
りをどうするかについて、NCCと協議する必要がある。RIPE NCCとの事前協議
なくして、レジストリから別のレジストリまたはレジストリ以外の組織に、割
り振りを譲渡することはできない。1つのレジストリが複数の「オープン状態」
の(つまり使用率が80%未満の)割り振りを受けることはできないので、必ずし
もすべての割り振りを譲渡できるとは限らない。この問題については、
<hostmaster@ripe.net>に連絡して協議されたい。
6.6. レジストリの閉鎖
ローカルインターネットレジストリは、レジストリとしての運営を停止するこ
とを決定することができる。レジストリがいったん閉鎖し、後日再オープンす
ることを決定した場合は、新規レジストリの設立に必要な正式の手続きを最初
からすべてとり直す必要がある。
レジストリは、閉鎖を決定したら、未決済のIPアドレス空間要求を直ちに停止
し、カスタマにローカルIRのリストを紹介する必要がある。これにより、カス
タマに後日リナンバが必要になる事態を防止できる。このリストは次のサイト
で参照できる。
____________________________________________________
ripe-185.txt Page 64
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
http://www.ripe.net/lir/registries/indices/index.html
閉鎖レジストリは、これ以上、自己のアドレス空間割り振りから割り当てを行
うことはできない。
ローカルIRとしての運営を停止するには、レジストリは次の3つの手順に従う。
1)
RIPE NCCに、レジストリを正式に閉鎖するための要求を文書により送り、未割
り当てのアドレス空間を返還する意志をその文書に明記する。この要求および
後続のすべての通信は、<hostmaster@ripe.net>宛に送信する。レジストリは、
正式に閉鎖要求を出すまでは、サービスに対する課金の請求対象となる。
2)
ローカルIRとして運営している間に割り当てたIPアドレス空間に関するすべ
てのドキュメンテーションをNCCに提供する。レジストリが提供する必要があ
るのは、RIPE NCCがそのレジストリに割り振ったアドレス空間に関するドキュ
メンテーションのみである。レジストリは、他の既存レジストリに割り振りを
譲渡できる場合がある。その場合は、すべての割り当てに関するドキュメンテー
ションを相手のレジストリに提供する。ただし、このような譲渡ができるのは、
RIPE NCCが同意した場合のみである。
3)
閉鎖するレジストリは、その全割り振りから割り当てたすべてのアドレス空
間の総合計をNCCに提出する必要がある。また、RIPE NCCが割り振ったアドレ
ス空間に関して、RIPEデータベースの内容が最新データになっていることも確
認しなければならない。レジストリは、RIPE NCCがそのレジストリに割り振り、
現在割り当てられていないすべてのアドレス空間のリストを、NCCに提出する
必要がある。未割り当てのアドレスは、NCCに返還され、IP空間のパブリック
プールに戻されるものとする。パブリックプール内のIP空間は必要に応じて
RIPE NCCが割り当てることができる。
レジストリが、ローカルIRとしては閉鎖するが、その後もISPとしてカスタマ
にインターネット接続の提供を続ける場合は、カスタマはすでに割り当てられ
ているアドレス空間をそのまま継続して使用することができる。閉鎖したレジ
ストリが行った割り当ては、その割り当ての根拠となった元の基準が有効であ
る限り、有効なままである。
____________________________________________________
ripe-185.txt Page 65
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
割り当て済みのアドレス空間を用いたインターネット接続を、レジストリが
カスタマに以後提供しない場合は、リナンバの時点で割り当て済みのアドレス
空間がユーザから回収される。ローカルIRには、リナンバに関してカスタマを
支援する責任がある。
6.6.1. RIPE NCCによるレジストリの閉鎖
レジストリが請求金額をRIPE NCCに対して支払うことを停止したり、相当の期
間NCCからの連絡が不能になったりした場合、RIPE NCCは、そのレジストリの
閉鎖を決定することがある。また、IANAまたはRIPE NCCコミュニティにより設
定されたポリシーに違反する行為がローカルIRにあり、二度以上の警告を重ね
てもその違反が続く場合は、RIPE NCCはそのローカルIRを閉鎖することがある。
RIPE NCCは、閉鎖を通知するメッセージをローカルIRに送る。その場合は、当
該レジストリは、割り振られたアドレス空間に関するドキュメンテーションを
RIPE NCCに提出し、上記に概要を示したレジストリの閉鎖に関するその他の手
続きに従わなければならない。
レジストリがRIPE NCCに適正なドキュメントを提出しない場合は、IPアドレス
空間のパブリックプールに返還すべきアドレス空間を、RIPE NCCが決定するこ
とができる。
____________________________________________________
ripe-185.txt Page 66
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
7. AS番号割り当てのポリシーと手続き
ASは、1つまたは複数のネットワーク運営組織が運営するIPネットワークのグ
ループであり、単一の明確に定義されたルーティングポリシーを持っている。
各ASにはそれぞれ固有な番号が付いている。この番号は、外部ルーティング情
報(つまりAS相互間のネットワーク到達可能性に関する情報)を交換する際に、
ASの識別子として使用される。AS間のルーティング情報の交換には、BGP(RFC
1771 [Rekhter95a])などの外部ルーティングプロトコルが使用される。
通常、ASは内部ゲートウェイプロトコルを使用して、内部ネットワーク上でルー
ティング情報を交換する。
ASという用語は、同じ管理体制下に入る一組のネットワークをグループ化する
便利な方法であると誤解されることがしばしばある。しかし、複数のルーティ
ングポリシーが存在するネットワークグループ内では、ASも複数存在する。一
方、ある一組のネットワークが別の一組と同じルーティングポリシーを持って
いれば、両方の組のネットワークは、管理構造に関係なくすべて同じASの下に
組み入れられる。したがって、1つのASの中のすべてのネットワークは、当然
のことながら1つのルーティングポリシーを共有することになる。
グローバルなルーティングの複雑さを軽減するために、新規AS番号は、新しい
ルーティングポリシーが必要になった場合にのみ作成する。同一組織の傘下に
ない一組のネットワーク間で同じAS番号を共有するには、各種のネットワーク
管理組織間での特別な調整が必要な場合がある。場合によっては、何らかのレ
ベルのネットワークのリエンジニアリングが必要となる。しかし、おそらく、
これが必要なルーティングポリシーを実装するための唯一の方法であろう。詳
細については、「RFC 1930 [Hawkinson96a]」を参照されたい。
7.1. AS番号の取得
RIPE NCCは、RIPE NCCのサービス対象となる地域にあるASに対して、AS番号を
割り当てる。IPアドレス要求については、RIPE NCCは、RIPE NCCに料金を納入
しているローカルIRからのAS番号要求のみを受け付ける。書式の提出先は
<hostmaster@ripe.net>である。
____________________________________________________
ripe-185.txt Page 67
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
AS番号を入手する方法として、RIPE NCCは、IPアドレス要求の提出に使用す
るものと似た書式を用意している。この書式は、aut-num(AS番号)オブジェク
トテンプレート、 technical(テクニカル)テンプレート、mntner(保守担当者)
テンプレート、および1つまたは複数のperson(担当者)テンプレートの4つの部
分で構成されている。この書式には、求められている情報をすべて記入する必
要がある。NCCは、計画されているルーティングポリシーを理解し、AS番号が
確かに必要かどうかを決定するために、追加情報の提出を求める場合がある。
テンプレートに記入された情報は、データベースに入力され、パブリックアク
セスが可能になる。各テンプレートについて、以下に詳しく説明する。
aut-numオブジェクト
aut-numオブジェクトテンプレートは、AS番号を申請する組織について説明し、
連絡担当者を指定するためのテンプレートである。
aut-numオブジェクトには、必須フィールドとして、aut-num(AS番号)、descr
(記述)、 admin-c(管理連絡窓口)、tech-c(技術連絡窓口)、および mnt-by(保
守担当者)の各フィールドがある。aut-numフィールドは、割り当てられる番号
を示す。admin-cおよびtech-cには、担当者のNICハンドルを記入する。
mnt-by(maintain by:保守担当者)属性は、オブジェクトを変更する権限を与え
られている人々を記述した、データベース内のmntner(保守担当者)オブジェク
トを参照する属性である。
mntnerオブジェクト
mntner(保守担当者)オブジェクトは、データベース内の各aut-numオブジェク
トについて1つずつ必要である。このオブジェクトは、aut-num情報に対するアッ
プデートを送る宛先を指定する。mntnerオブジェクトをまだデータベースに登
録していない場合は、AS番号要求と併せてこのオブジェクトもお送りいただき
たい。
mntnerオブジェクトテンプレートには、必須フィールドとして、mntner(保守
担当者)、descr(記述)、admin-c(管理担当窓口)、tech-c(技術担当窓口)、
auth(権限)、upd-to(アップデート)、mnt-by(#+(保守担当者)保守担当者)、
notify(通知先)、changed(変更)、およびsource(ソース)の各フィールドがあ
る。mntnerオブジェクトの詳細については、「ripe-120 [Karrenberg94b]」を
参照されたい。
____________________________________________________
ripe-185.txt Page 68
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
personオブジェクト
AS番号要求の処理と、ASが運営を開始したときに起こり得るルーティングに関
連する問題のデバッグを容易にするために、各aut-numオブジェクトに連絡担
当者(admin-cおよびtech-c)を登録する必要がある。すでにデータベースに入
力済みでない限り、管理連絡窓口と技術連絡窓口のためのpersonテンプレート
が必要である。管理連絡窓口は、AS番号を要求する企業に物理的に存在してい
る必要がある。
personテンプレートには、person(担当者)、address(住所)、phone(電話番号)、
fax-no(ファックス番号)、nic-hdl(NICハンドル)、およびe-mail(Eメール)の
各フィールドがある。各テンプレートに、該当担当者の名前をフルネームで記
載する必要がある。電話番号およびファックス番号には国コードプレフィック
スを「+コード」の形式で含め、担当者にインターネット経由のEメールで連絡
可能な場合は、完全なEメールアドレスも指定する。
技術的詳細
現在の割り当てガイドラインでは、AS番号の割り当てを受けるためにはネット
ワークがマルチホーム接続されていることが必要である。AS番号を申請する場
合、レジストリは、AS番号を必要とするASのルーティングポリシーを提出する。
ポリシーは、aut-numオブジェクトの一部として、次の属性の中で定義される。
as-inの複数のフィールド(隣接する複数のASから受け入れるルーティング情報
の記述)、as-outの複数のフィールド(他のASピアに送るために生成されるルー
ティング情報の記述)、デフォルトの1つまたは複数のフィールド(デフォルト
のルーティングを行う方法の指示)。
評価と割り当て
完成した書式は、RIPE NCCのホストマスタメールボックスに送信する。すると、
RIPE NCCは、書式の内容を評価し、AS番号が真に必要かどうかを判定する。AS
番号を割り当てた場合は、NCCはすべての関連情報をデータベースに入力し、
ローカルIRにその割り当てを通知する。
____________________________________________________
ripe-185.txt Page 69
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
7.2. AS番号の返還
もう使用しないAS番号を持っている組織は、<hostmas-ter@ripe.net>にメッセー
ジを送って、そのAS番号をAS番号のパブリックプールに返還することができる。
返還されたAS番号は、RIPE NCCが別のASに割り当てるために再使用することが
できる。
____________________________________________________
ripe-185.txt Page 70
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
8. ドメイン間(外部)ルーティングに関する考慮事項
アドレス空間の割り振り/割り当てポリシーは、外部ルーティングに関する考
慮事項に密接な関係がある。事実、ルーティングに関する問題は、本ドキュメ
ントで説明してきたアドレス空間の分配に関するポリシーを定義する上で、重
要な役割を演じてきた。特に、アドレス空間の割り振りと割り当てに関する決
定は、割り当てられたIP番号のルーティング可能性を促進し、インターネット
全体のルーティングの複雑さを最小限にする方向で行う必要がある。これが、
アドレス空間割り振り/割り当てポリシーにおいて集約が中心的役割を果たす
重要な理由である。
インターネット上の各ホストは例外なく、たとえ規模が小さくても、特定の宛
先アドレスに向けられたパケットをどこに送信すればよいかを示すルーティン
グテーブルを備えている。このセクションでは、経路告知をどのように利用し
てルーティングテーブルを作成するのか、およびテーブルの規模を小さく抑え
る上で集約がどのような役割を果たしているのかについて説明する。また、グ
ローバルルーティングポリシーを管理するためのルーティングレジストリの使
用、およびISP間でのルーティングポリシーの整合性を調べるために使用でき
るいくつかのツールについても説明する。
ISPは、<routing-wg@ripe.net>、<eof@ripe.net>、<cidrd@iepg.org>などの関
係グループで行われているディスカッションに常に注目していていただきたい。
始めの2つのグループに関する情報は、メッセージ本文に"list"と記したEメー
ルを<majordomo@ripe.net>に送ることによって入手することができる。最後の
グループについては、Eメールの宛先は<cidrd-request@iepg.org>である。
8.1. ルーティング情報の発信
エンドユーザにネットワークで使用するためのアドレス空間を割り当てたら、
そのネットワーク上のマシンがインターネット上の他のマシンと通信するため
の何らかの手段を提供する必要がある。つまり、これらのホスト宛のパケット
をどこに送信できるかを、インターネットの他のシステムに何らかの方法で告
知する必要がある。
このプロセスはルーティング情報の発信と呼ばれ、インターネット上の他のシ
ステムはこの情報を使用して、該当のアドレス空間を使用するホストにアクセ
スすることができる。
実際上は、この告知はルーティングプロトコルを通じて行われる。ASは、そこ
に到達するためのルーティングに使用するアドレスのセットを告知することに
より、1つまたは複数の近隣ASと相互接続する。
____________________________________________________
ripe-185.txt Page 71
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
この情報を交換するためにASが使用する最も一般的なルーティングプロトコ
ルは、「RFC 1771 [Rekhter95a]」に定義されているように、BGPである。特定
のルーティングハードウェアを構成する方法の詳細については、
[Nuss-bacher96a]を参照されたい。
もちろん、ISPが発信できるのは、そのISPに割り振られているグローバルアド
レス空間、またはそのISPが接続を提供しているカスタマに割り当てられたグ
ローバルアドレス空間用の経路のみである。プライベートアドレス空間の経路
を告知してはならない。経路を告知する前に、必ずRIPEデータベースに照会し
て、関連のアドレス空間の割り振りまたは割り当てを確認する必要がある。
可能な場合には、ISPはその割り振り全体にわたるCIDR経路を発信するものと
する。ISPは、是非とも必要な場合でない限り、CIDR経路より特定性の高い経
路を発信してはならない。ネットワークがマルチホーム接続のものでない場合
は、関連のアドレス空間へと導く告知が複数ある場合は、構成エラーである可
能性が高い。
8.2. ルーティング告知の伝搬
ASは、経路の起点となるほか、他のASから受け取った経路を近隣ASに伝搬する。
正常に処理が進めば、この伝搬により、アドレスをインターネットに告知した
任意の2つのホスト間での通信が可能になる。インターネット全体がスムーズ
に稼働する状態を維持するために、経路を伝搬するISPはいくつかの確立済み
の原則に従って運営する必要がある。
1)
経路を伝搬するのは、関連アドレス空間がいずれかの地域レジストリのデー
タベースに正規に登録されている場合のみとする。
2)
経路を伝搬する場合、全体の接続性が確保されるように注意しなければなら
ない。他のISPの接続性を制限するようなルーティングポリシーは避けなけれ
ばならない。
3)
ISPが実装しているルーティングポリシーによって、伝搬されるかまたは受け
入れられるプレフィックスの長さが制限される場合は、常に、関連アドレス空
間の割り振りの最小サイズに従ったプレフィックスを持つ経路が使用できるよ
うにする必要がある。RIPE NCCが分配するアドレス空間(193/8、194/8、およ
び195/8)の場合は、最小割り振りは/19が1個である。したがって、このプレフィッ
クス長をこの範囲のアドレスについて受け入れるルーティングポリシーならど
れでも、RIPE NCCのサービス地域の関連ホストのための接続を可能にできる。
____________________________________________________
ripe-185.txt Page 72
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ルーティングポリシーは、少なくとも/19プレフィックスを伝搬するもので
ない限り、関連ホストおよびその他のインターネット上の多数のホストにとっ
て接続上の問題が起きる原因になる可能性がある。
ISPは、ルーティングポリシーを定義する場合にRIPEデータベースを利用する
ことができる。RIPEデータベースには、有効な割り振りと割り当て、およびア
ドレス空間のタイプ(PI/PA)についての情報が入っている。
8.3. 集約
ISPは、内部ルーティングと外部ルーティングを明確に区別してネットワーク
をエンジニアリングすることが重要である。インターネットの中央ルータでは、
(不必要な)ルーティング情報とルーティングアップデートにより発生するルー
タ上の負荷が大きくなり、結果的にネットワーク障害へと導くものとなること
が知られている。
グローバルインターネットとの安定した接続を達成する手段の1つは、経路を
できるだけ集約することである。ほとんどの場合、カスタマネットワークへの
さらに細かい特定経路を設定する必要はない。
しかし、接続の提供先のカスタマが使用しているアドレス空間が、貴社の割り
振り空間から割り当てたものでない場合は、カスタマのネットワークをリナン
バしてPAアドレス空間を使用するようにすることを強く勧奨する。この種のネッ
トワークに特定の告知を必要とせずにアクセスできるのは、上記の方法をとっ
た場合だけである。これは、PIアドレス空間を使用するカスタマについても、
別のISPから割り当てられたPAアドレス空間を使用するカスタマについてもあ
てはまる。前者の場合は、PIアドレスが真に必要で ることはほとんどない。
後者の場合は、アドレス空間がPAであるという事実は、ISPの変更時にリナン
バすることにカスタマが同意していることを意味する。
8.4. RIPEデータベースへの経路の登録
経路を発信する場合は、その経路をルーティングレジストリに正しく文書化す
ることが必要である。これは、「ripe-181[Bates94a]」の記述に従って経路オ
ブジェクトをRIPEデータベースに提出することによって行う。
各経路はASが発信し、経路オブジェクトの起点属性は、ASのルーティングポリ
シーを記述したAS番号(aut-num)オブジェクトにリンクする。
____________________________________________________
ripe-185.txt Page 73
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
ルーティングポリシーの決定プロセスおよびトラブルシューティングのプロ
セスでルーティングレジストリ内の情報を使用する、多くの便利なツールがあ
る。その一部を簡単に紹介しておく。
prtraceroute
所定のホストに到達するまでのパケットの経路をトレースする。途中の各ルー
タごとにそのルータが所属するASの番号を表示し、経路とルーティングレジス
トリに格納されているルーティングポリシーとの関係も示す。
prpath
任意の2つの指定宛先間でルーティングレジストリに従って取り得るパスをす
べて印刷する。
prcheck
aut-numオブジェクトの構文と有効性をチェックする。
ルーティングレジストリに関する詳しいチュートリアルは、[Bates94b]に収めてある。
____________________________________________________
ripe-185.txt Page 74
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
9. 用語集
このセクションでは、本ドキュメントで使用した用語のうち重要なものについ
て、ごく簡単に説明する。
割り振り(Allocation)
一般に、上位のIRが下位のIRにアドレス空間を割り振る。下位のIRは、割り振
られたアドレス空間を保有し、エンドユーザへの割り振りまたは割り当てのた
めに使用する。
割り当て(Assignment)
IRは、エンドユーザにアドレス空間を割り当てる。エンドユーザはそのアドレ
ス空間を運用ネットワーク内で使用する。
クラスレスアドレス体系(Classless Addressing)
これまでは、IPアドレスはクラスA、クラスB、クラスCというネットワーク番
号形式を使用して割り当てられていた。CIDR(classless inter-domain
routing)の登場により、このクラスを固定した制限はもう無効になった。
____________________________________________________
ripe-185.txt Page 75
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
アドレス空間の割り振りおよび割り当ては、現在、ビット境界に基づいて行
われている。次の表はその状況を示している。
+----------------------------------------------+
|addrs bits pref class mask |
+----------------------------------------------+
| 1 0 /32 255.255.255.255 |
| 2 1 /31 255.255.255.254 |
| 4 2 /30 255.255.255.252 |
| 8 3 /29 255.255.255.248 |
| 16 4 /28 255.255.255.240 |
| 32 5 /27 255.255.255.224 |
| 64 6 /26 255.255.255.192 |
| 128 7 /25 255.255.255.128 |
| 256 8 /24 1C 255.255.255 |
| 512 9 /23 2C 255.255.254 |
| 1K 10 /22 4C 255.255.252 |
| 2K 11 /21 8C 255.255.248 |
| 4K 12 /20 16C 255.255.240 |
| 8K 13 /19 32C 255.255.224 |
| 16K 14 /18 64C 255.255.192 |
| 32K 15 /17 128C 255.255.128 |
| 64K 16 /16 1B 255.255 |
| 128K 17 /15 2B 255.254 |
| 256K 18 /14 4B 255.252 |
| 512K 19 /13 8B 255.248 |
| 1M 20 /12 16B 255.240 |
| 2M 21 /11 32B 255.224 |
| 4M 22 /10 64B 255.192 |
| 8M 23 /9 128B 255.128 |
| 16M 24 /8 1A 255 |
| 32M 25 /7 2A 254 |
| 64M 26 /6 4A 252 |
| 128M 27 /5 8A 248 |
| 256M 28 /4 16A 240 |
| 512M 29 /3 32A 224 |
|1024M 30 /2 64A 192 |
+----------------------------------------------+
'bits'
アドレス空間の割り振り/割り当てサイズをビット単位で表したもの。
'addrs'
使用可能なアドレス数。全ビットが同じ(全桁0または全桁1)であるホスト部分
は予約されているので、アドレス可能なホストの数は、通常、この値から2を
引いた数であることに注意されたい。
____________________________________________________
ripe-185.txt Page 76
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
'pref'
このアドレス空間をカバーする経路プレフィックスの長さ。これは、割り振り
/割り当てのサイズを示すために使用される場合がある。
'class'
クラスフルネットワーク番号の場合の、アドレス空間のサイズ。
'mask'
ドットクワッド表記で経路プレフィックスを定義する、ネットワークマスク。
本ドキュメント全体を通じて、割り振りおよび割り当てのサイズは「アドレス
空間のビット数」で表し、必要な場合には経路プレフィックスの長さを括弧に
入れて付記してある。
____________________________________________________
ripe-185.txt Page 77
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
参考文献
Albitz94a.
Paul Albitz and Cricket Liu, DNS and BIND, O'Reilly & Associates, Inc.,
Sebastopol, CA (1994).
Bates94a.
T. Bates, E. Gerich, L. Joncheray, JM. Jouanigot, D. Karrenberg, M.
Terpstra, and J. Yu, Representation of IP Routing Policies in a Routing
Registry, ripe-181 (10/1994).
Bates94b.
T. Bates, D. Karrenberg, and M. Terpstra, The PRIDE Guide (10/1994).
Beertema93a.
P. Beertema, Common DNS Data File Configuration Errors, RFC 1537 (10/1993).
Caslav97a.
P. Caslav and J. Crain, RIPE NCC Consistency & Auditing Activity, ripe-170
(12/1997).
Caslav96a.
P. Caslav, M. Kuehne, and C. Orange, European IP Address Space Request Form,
ripe-141 (09/1996).
Caslav98a.
P. Caslav and M. Muit, Guidelines for Setting up a Local Internet Registry,
ripe-160 (04/1998).
Deering89a.
S. Deering, Host Extensions for IP Multicasting, RFC 1112 (08/1989).
Eidnes98a.
H. Eidnes, G. de Groot, and P. Vixie, Classless in-addr.arpa delegation, RFC
2317 (03/1998).
Fuller93a.
V. Fuller, T. Li, J. Yu, and K. Varadham, Classless Inter-Domain Routing
(CIDR): an Address Assignment and Aggregation Strategy, RFC 1519 (09/1993).
Gerich93a.
E. Gerich, Guidelines for Management of IP Address Space, RFC 1466
(05/1993).
____________________________________________________
ripe-185.txt Page 78
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
Hawkinson96a.
J. Hawkinson and T. Bates, Guidelines for creation, selection, and
registration of an Autonomous System, RFC 1930 (03/1996).
Karrenberg94a.
D. Karrenberg, RIPE NCC Request Tracking and Ticketing, ripe-183 (03/1994).
Karrenberg95a.
D. Karrenberg, Provider Independent vs Provider Aggregatable Address Space,
ripe-127 (06/1995).
Karrenberg94b.
D. Karrenberg and M. Terpstra, Authorisation and Notification of Changes in
the RIPE Database, ripe-120 (10/1994).
Kuehne95a.
M. Kuehne and D. Karrenberg, 2nd Meeting of the RIPE NCC Contributors
Committee Minutes, ripe-132 (10/1995).
Magee97a.
A. M. R. Magee, RIPE NCC Database Documentation, ripe-157 (05/1997).
Norris96a.
M. Norris, Charging by Local Internet Registries, ripe-152 (04/1996).
Nussbacher96a.
H. Nussbacher, The CIDR FAQ, http://www.ibm.net.il/~hank/cidr.html
(05/1996).
Postel94a.
J. Postel, Domain Name System Structure and Delegation, RFC 1591 (03/1994).
Rekhter93a.
Y. Rekhter and T. Li, An Architecture for IP Address Allocation with CIDR,
RFC 1518 (09/1993).
Rekhter95a.
Y. Rekhter and T. Li, A Border Gateway Protocol 4 (BGP-4), RFC 1771
(03/1995).
Rekhter96a.
Y. Rekhter and T. Li, Implications of Various Address Allocation Policies
for Internet Routing, RFC 2008 (08/1996).
____________________________________________________
ripe-185.txt Page 79
European Internet Registry Policies and Procedures
RIPE Local Internet Registry Working Group
____________________________________________________
Rekhter96b.
Y. Rekhter, R. Moskowitz, D. Karrenberg, G. de Groot, and E. Lear, Address
Allocation for Private Internets, RFC 1918 (02/1996).
____________________________________________________
ripe-185.txt Page 80
