|
この文書はJPNIC公開文書であり、著作権は日本ネットワークインフォ メーションセンター(JPNIC)が保持しています。JPNIC公開文書は誰でも 送付手数料のみの負担でJPNICから入手できます。また、この著作権 表示を入れるかぎり、誰でも自由に転載・複製・再配布を行なって構 いません。 〒101-0047 東京都 千代田区 内神田2-3-4 国際興業神田ビル6F |
"APNIC End User Internet Address Request Form" 翻訳文
(ftp://ftp.nic.ad.jp/jpnic/translation/apnic-074-j.txt)
（社）日本ネットワークインフォメーションセンター
最終更新 1999年 4月 28日
この文書は
http://ftp.apnic.net/apnic/archive/apnic-074.txt
を翻訳したものです。実際に使用できる申請書ではありません。JPNICはこの
翻訳を参考のために提供しますが、その品質に責任を負いません。
------------------------------------------------------------------------
APNIC-074
=========
APNIC End User Internet Address Request Form(APNICエンドユーザ用インター
ネットアドレス申請書)
1998年8月発行
この書式は、自己の内部使用を目的としてアドレス空間を要求する組織が使用
するためのものである。内部使用とは、内部ネットワーク(通常パブリックア
クセスが可能なもの)を介して直接的に接続された、たとえば支社、子会社、
部門間などでの使用を指す。貴組織が、無関係の外部組織にアドレス空間をサ
ブデリゲートすることを予定している場合は、インターネットサービスが商業
目的で使用されるかどうかの明確な定義ができないため、貴組織はアドレス割
り振りを目的とするインターネットサービスプロバイダとみなされる。外部組
織へのアドレス空間のサブデリゲートを予定している場合は、"APNIC
Internet Service Provider Internet Address Request
Form"を使用されたい
(ftp://ftp.apnic.net/apnic/docs/isp-address-requestを参照)。貴組織が、
APNICが認定したサービスプロバイダコンフェデレーションである場合は、
"Confederation
Internet Address Request
Form"を使用されたい
(ftp://ftp.apnic.net/apnic/docs/confed-address-requestを参照)。
この申請書の記入方法については、書式の末尾の説明をお読みいただきたい。
この書式はコンピュータで処理されるため、フィールド名または#[で始まる行
を変更すると、不測のエラーが返される恐れがあり、その場合申請は処理され
ないので、注意が必要である。
この書式への記入を終えたら、Eメールで下記にお送りいただきたい。
hostmaster@apnic.net
あるいは、活字印刷の英語で記入した書式をファックスで下記にお送りいただ
きたい(ただし、できればファックス利用は避けていただきたい)。
+61-7-3367-0482
あるいは、活字印刷の英語で記入した書式を郵便で下記にお送りいただきたい
(これは最後の手段としてご利用いただきたい)。
Asia Pacific Network Information Centre
Level 1, 33 Park Road
P. O. Box 2131
Milton, QLD 4064
Australia
この書式について質問があるときは、hostmaster@apnic.netにEメールを送る
か(最も望ましい方法)、上記の電話番号にファックスを送るか、上記の宛先に
郵便を送るか、または、東部オーストラリア標準時の午前9時から午後5時まで
の間に電話(+61-7-3367-0490)により照会されたい。ただし、電話によるアド
レス要求は受け付けていない。
Eメールによる要求の処理には最大1週間、その他の形式での要求の処理には最
大1ヶ月の余裕を見ていただきたい。
注:
申請書には、この表題部分およびこの書式の末尾の説明は含めないようにされたい。
- - - - - - - - - - - - - 切り取り線 - - - - - - - - - - - - - - -
#[NETWORK TEMPLATE V:4.0]#
netname:
descr:
descr:
country:
admin-c:
tech-c:
remarks:
changed:
mnt-by:
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
remarks:
changed:
mnt-by:
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person:
address:
address:
country:
phone:
fax-no:
e-mail:
nic-hdl:
remarks:
changed:
mnt-by:
source: APNIC
#[END USER TECHNICAL TEMPLATE V:1.0]#
acct-name:
host-bits:
connectivity:
conn-provider:
all-0s-subnets:
all-1s-subnets:
supernets:
subnets:
network-plan:
network-plan:
old-network:
old-network:
#[TEMPLATES END]#
Explanation why you cannot obtain addresses from your service provider:
Additional Comments:
- - - - - - - - - - - - - - 切り取り線 - - - - - - - - - - - - - - - - -
1. この書式の記入方法
----------------------------------------
以下、APNIC End User Internet Address Request Formの記入方法について説
明する。下記に挙げるタグの属性を正しく記入することはきわめて重要である。
記入洩れがあると、サービスの遅延が生じ、要求したIPアドレスの提供が遅れ
ることがある。
END USER TECHNICAL TEMPLATEに記入された情報は極秘扱いとして保護する。
したがって、セキュリティ上の理由によりこれらのフィールドを空白のままと
することは認められない。この点に関する詳しい説明については、
hostmaster@apnic.netに照会されたい。
NETWORKおよびPERSONテンプレートに記入された情報は、whois.apnic.netに対
するWHOISまたはその他のメカニズムにより、インターネット上で利用できる
情報となる。これらの情報は、インターネットの操作に関連した問題を診断し
解決することを目的として、インターネットコミュニティに提供される。これ
以外の目的にこれらの情報をAPNIC Pty Ltd.の許諾なく利用することを、厳重
に禁止する。
APNICへの申請はコンピュータで処理されるので、申請書はプレーンASCIIで記
入しなければならない。デコードをまったく必要とせずに読める形式になって
いない限り、MIMEコードの使用は認められない。特に、BASE64エンコードテク
ニックは決して使用しないよう注意されたい。さらに、たとえばテンプレート
内でテキストの位置調整や行間へのブランク行の挿入など、申請書の書式に手
を加えることはいっさいしないようにしていただきたい。自動構文解析システ
ムは上記の書式からの著しい逸脱には対応できないので、これらの条件が満た
されていないと構文エラーが返されることがある。下記に、記入済みの書式の
例を掲げる。
すでに述べたように、この書式に関する質問や意見があるときは、いつでも
hostmaster@apnic.netにご連絡いただきたい。
2. End User Internet Address RequestのNetworkテンプレートの記入方法
-------------------------------------------------------------
NETNAME:
このネットワークを表す、短くてしかも意味のある記述的な名前を記入する。
NETNAMEは、インターネットレジストリの整合性チェックなど、主として管理
目的に使用される。ネットワーク名は、最大25文字の大文字の英数字のみを使
用して、単一のワードで表現しなければならない。ネットワーク名には、ネッ
トワークが割り当てられる組織に関連のある名前を使用することが望ましい。
ネットワーク名はドメイン名とは関係がないので、FOO.COMなどのドメイン名
は使用しないようにされたい。各NETWORKテンプレートにつき必ずNETNAMEタグ
が1つ必要である。
例:
netname: TBIT
DESCR:
貴組織をAPNICデータベース内の他の組織と区別できる十分な詳細情報を示す、
組織に関する短い記述(住所を含む)を記入する。たとえば、"descr:Computer
Center"などの記述では不十分である。組織記述には、'The best maker of
bars in Foo'(Fooにおける最高のバールメーカ)といった宣伝的表現を含めて
はならない。また、DESCRは5行以内に収めるようにされたい。このタグは、す
べてのNETWORKテンプレートに記入する必要がある。
例:
descr: Terabit Labs Inc.
descr: Network Bugs Feeding Facility
descr: Northtown
COUNTRY:
アドレス空間を要求する組織に該当する2文字のISO
3166国別コードを記入する。国名または3文字のISO
3166国別コードを使用してはならない。所属する国のISO
3166コードが分からないときは、下記にアクセスして、 APNICが提供するISO
3166コードの表を参照されたい。
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
国際的なネットワークの場合は単一の国のみを記入することは困難な場合があ
るものと考えられるが、その場合は、管理連絡窓口の所在場所を基準として最
も適切と思われる国を選んでいただきたい。このタグはすべてのNETWORKテン
プレートに記入する必要があり、1テンプレートにつき1つの国のみを記入する
ものとする。
例:
country: JP
ADMIN-C:
ネットワークに関する管理連絡窓口となる担当者のAPNIC NICハンドルを記入
する(現時点では他のレジストリからのNICハンドルは受け入れられない
)。APNIC NICハンドルを持っていない場合は、後述の「APNIC NICハンドルの
取得」の項を参照されたい。管理連絡窓口は、ネットワークの事務所に物理的
に存在している人物でなければならず、また、すべてのNETWORKテンプレート
についてADMIN-C タグが少なくとも1つは必要である。
例:
admin-c: JD1-AP
TECH-C:
ネットワークに関する技術連絡窓口となる担当者のAPNIC NICハンドルを記入
する(現時点では他のレジストリからのNICハンドルは受け入れられない
)。APNIC NICハンドルを持っていない場合は、後述の「APNIC NICハンドルの
取得」の項を参照されたい。技術連絡窓口は、ネットワークの事務所に物理的
に存在している必要はないが、ネットワークの日常の運営に責任を負う人物で
あることが必要とされる。すべてのNETWORKテンプレートにつき少なくとも1つ
のTECH-Cタグが必要である。
例:
tech-c: MS4-AP
REMARKS:
注釈属性には、他のどの属性の項にも該当しない、このアドレス空間について
の注釈情報をすべて記入する。複数の行を使用できるが、データベースのユー
ザに特別な情報を提供することのみを目的とし、必要最小限の範囲で使用して
いただきたい。
例:
remarks: will be returned to NIC 19950101
CHANGED:
このテンプレートを記入している人のEメールアドレスと、YYYYMMDD形式の現
在の日付を記入する(YYYYは年、MMは月、DDは日で、空白桁にはすべて0を記入)。
これが新しいプロバイダブロックを要求する申請である場合は、各NETWORKテ
ンプレートにつき必ずCHANGEDタグが1つ必要である。
例:
changed: johndoe@terabit.na 19950225
MNT-BY:
該当する保守担当者IDを記入する。保守担当者IDは、MNT-BYフィールドにより
プロテクトされたオブジェクトを誰がアップデートできるかについて、ある程
度の認可権限を持つ。保守担当者IDを持っていない場合は、このフィールドは
ブランクのままにしてもよい。その場合は、デフォルトの保守担当者ID(認証
プロテクションの機能を持たないもの)が作成される。あるいは、APNIC
Maintainer Object Request書式を使用して、保守担当者IDを請求することも
できる。この書式は下記より入手できる。
ftp://ftp.apnic.net/apnic/docs/maintainer-request
MNT-BYタグの数は、1つのNETWORKテンプレートにつき0個でも1個以上でもさし
つかえないが、指定する保守担当者オブジェクトはAPNICレジストレーション
データベースにすでに存在しているものでなければならない。
例:
mnt-by: MAINT-FOO-AP
SOURCE:
情報のソース。APNIC書式の場合、これは常にAPNICである。これはデータベー
ス内の必須情報なので、最初から書式に記入されている。
例:
source: APNIC
3. End User Internet Address RequestのPersonテンプレートの記入方法
------------------------------------------------------------
PERSON:
このテンプレートで指名する人の氏名を記入する。'Dr'、'Prof.'、'Sir'など
の肩書きや敬称は使用せず、必ずフルネームを記入していただきたい(頭文字
は不可)。氏名は、その人が書簡の宛名等で通常表記される形式を使用するも
のとする (たとえば、姓が先で名が後か、名が先で姓が後かなどは、所属する
国の習慣に従う)。PERSONテンプレートにはPERSONフィールドが1つだけ必要で
ある。
例:
person: John E Doe
ADDRESS:
国際郵便に使用する完全な住所を記入する(ただし、国名は下記のCOUNTRYフィー
ルドに記入するので不要)。住所の各構成部分にそれぞれ1行ずつ使用するもの
とする。
例:
address: Terabit Labs Inc.
address: Industrial Estate North
address: North Perpendicular Road 12
address: NL-1234 Northtown
COUNTRY:
連絡担当者に該当する2文字のISO 3166国別コードを記入する。国名または3文
字のISO 3166国別コードを使用してはならない。担当者の住所に該当するISO
3166コードが分からないときは、下記にアクセスして、APNICが提供するISO
3166コードのリストを参照されたい。
ftp://ftp.apnic.net/apnic/docs/iso-3166.txt
COUNTRYタグはすべてのPERSONテンプレートに記入する必要があり、1テンプレー
トにつき1つの国だけを記入するものとする。
例:
country: JP
PHONE:
このテンプレートで指定する人の職場の電話番号を、貴国における国際電話番
号表記に従って記入する(ただし、国際電話回線への接続の際に必要なプレフィッ
クスは付けない)。国際電話によるダイヤル番号の一部として必要とされる場
合を除き、市外局番/市内局番には先行ゼロを付加しない。電話番号の形式は
次のとおりである。
+<国別番号>-<市外/市内局番>-<交換局番号>-<加入者番号>
内線番号が必要な場合は、"ext <内線番号>"を付加する。ext 以外の略称('x'
等)を内線番号の表記に使用してはならない。電話番号は複数あればその方が
望ましい。その場合、各電話番号にそれぞれ1行を使用し、該当担当者にとっ
て便宜性の高いものから低いものへの順に記入する。
例:
phone: +81-20-1233-4676
phone: +81-20-1233-4677 ext 4711
FAX-NO:
該当担当者のファックス番号を、貴国における国際電話番号表記に従って記入
する(ただし、国際電話回線への接続の際に必要なプレフィックスは付けない)。
国際電話によるダイヤル番号の一部として必要とされる場合を除き、市外局番
/市内局番には先行ゼロを付加しない。ファックス番号の形式は次のとおりで
ある。
+<国別番号>-<市外/市内局番>-<交換局番号>-<加入者番号>
複数のファックス番号があればその方が望ましい。その場合、各ファックス番
号にそれぞれ1行を使用し、便宜性の高いものから低いものへの順に記入する。
該当担当者用のファックス番号がない場合は、このフィールドはブランクのま
までよい。
例:
fax-no: +81-20-1233-4678
E-MAIL:
該当担当者の電子メールアドレスを記入する。電子メールアドレスは、インター
ネットを介して到達できる、完全修飾ドメイン名付きの有効なRFC-822アドレ
スでなければならない。インターネットを介して到達可能なEメール接続機能
がない場合は、このフィールドはブランクのままにする。複数のEメールアド
レスを記入してもよい。その場合は、各アドレスにそれぞれ1行を使用し、最
も便宜性の高いものから低いものへの順に記入する。
例:
e-mail: johndoe@terabit.na
NIC-HDL:
NICハンドルは、インターネットレジストリデータベース内で同名の人々を区
別するための固有な識別子である。NICハンドルはレジストリにより割り当て
られる。現在ハンドルを持っていない場合、ハンドルの作成はしないでいただ
きたい。後述する「APNIC NICハンドルの取得」の項に示す手続きをとれば、
ハンドルは自動的に生成される。APNIC NICハンドルを持ってはいるが、それ
を覚えていないという場合は、このフィールドはブランクのままにし、申請書
のADDITIONAL COMMENTSのセクションにその旨を記入されたい。他のレジスト
リ(たとえばInterNIC)から割り当てられたNICハンドルを持っている場合は、
後述する自動生成ハンドルを使用して、とりあえず完全な形のPERSONテンプレー
トを作成していただきたい。現在、各地域レジストリはこの種の情報を共有す
る方法を模索しているが、まだソリューションを実現するに至っていない。
例:
nic-hdl: JD401-AP
REMARKS:
注釈属性には、他のどの属性の項にも該当しない、この担当者についての注釈
情報をすべて記入する。複数の行を使用できるが、データベースのユーザに特
別な情報を提供することのみを目的とし、必要最小限の範囲で使用していただ
きたい。
例:
remarks: pager can be accessed by <e-mail>-pager
CHANGED:
このテンプレートを記入している人のEメールアドレスと、YYYYMMDD形式の現
在の日付を記入する(YYYYは年、MMは月、DDは日で、空白桁にはすべて0を記入)。
これが新規のPERSONオブジェクトである場合は、各PERSONテンプレートにつき
必ずCHANGEDタグが1つ必要である。
例:
changed: johndoe@terabit.na 19960501
MNT-BY:
APNICが割り振る保守担当者IDを入力する。保守担当者IDは、MNT-BYフィール
ドによりプロテクトされたオブジェクトを誰がアップデートできるかについて、
ある程度の認可権限を持つ。保守担当者IDを持っていない場合は、このフィー
ルドはブランクのままにしてもよい。その場合は、デフォルトの保守担当者
ID(認証プロテクションの機能を持たないもの)が作成される。あるいは、
APNIC Maintainer Object Request書式を使用して、保守担当者IDを請求する
こともできる。この書式は下記より入手できる。
ftp://ftp.apnic.net/apnic/docs/maintainer-request
MNT-BYタグの数は、1つのNETWORKテンプレートにつき0個でも1個以上でもさし
つかえないが、指定する保守担当者オブジェクトはAPNIC登録データベースに
すでに存在しているものでなければならない。
例:
mnt-by: MAINT-FOO-AP
SOURCE:
情報のソース。APNIC書式の場合、これは常にAPNICである。これはデータベー
ス内の必須情報なので、最初から書式に記入されている。
例:
source: APNIC
4. End User Internet Address RequestのTechnicalテンプレートの記入方法
------------------------------------------------------
このセクションには、当方で貴組織の申請の妥当性を判断するために必要な情
報を記入する。したがって、ここに記入された情報は極秘情報として扱われ、
一般からのアクセスが可能ないかなるデータベースにも入れられることはない。
ACCT-NAME:
貴組織のAPNICアカウント名を入力する。アカウント名がなく、APNICのメンバ
となることを望む場合は、下記にアクセスし、"APNIC Membership
Application"書式を参照されたい。
ftp://ftp.apnic.net/apnic/docs/membership-application
APNICのメンバになることを望まない場合は、下記にアクセスし、"APNIC
Non-Member Resource Request Application"書式を参照されたい。
ftp://ftp.apnic.net/apnic/docs/non-member-application
いかなる場合も、アカウントフィールドに記入がない限りアドレス要求は受理
されない。メンバの場合も非メンバの場合も、APNICが料金の支払を確認して
からでなければ、申請は処理されないので注意されたい。
例:
acct-name: APNIC-AP
HOST-BITS:
2年後に必要と予測されるアドレス空間の量を、ホストアドレス空間のビット
数で記入する。ホスト数、ホストアドレス数、ネットワーク数、Class Cの数、
ブロック数のいずれでもない。たとえば、HOST-BITS: 7を要求したとすれば、
2**7 (128)個のホストアドレスが可能になることを意味する(ただし、通常、
エンドホスト割り当ての場合は全桁0および全桁1のホストアドレスは使用でき
ないので、7ビットの場合の最大ホスト数は126となる)。要求するホストビッ
ト数を決める際には、下記のガイドラインを目安にするとよい。
必要数
1ホストアドレス -> 1ホストアドレスビット(/32、1個)
2ホストアドレス -> 2ホストアドレスビット(/30、1個)
3～6ホストアドレス -> 3ホストアドレスビット(/29、1個)
7～14ホストアドレス -> 4ホストアドレスビット(/28、1個)
15～30ホストアドレス -> 5ホストアドレスビット(/27、1個)
31～62ホストアドレス -> 6ホストアドレスビット (/26、1個)
63～126ホストアドレス -> 7ホストアドレスビット(/25、1個)
127～254ホストアドレス -> 8ホストアドレスビット(/24、1個)
255～510ホストアドレス -> 9ホストアドレスビット(/23、1個)
511～1022ホストアドレス -> 10ホストアドレスビット (/22、1個)
1023～2046ホストアドレス -> 11ホストアドレスビット(/21、1個)
2047～4094ホストアドレス -> 12ホストアドレスビット(/20、1個)
4095～8190ホストアドレス -> 13ホストアドレスビット(/19、1個)
8191～16382ホストアドレス -> 14ホストアドレスビット(/18、1個)
16383～32766ホストアドレス -> 15ホストアドレスビット(/17、1個)
32767～65534ホストアドレス -> 16ホストアドレスビット(/16、1個)
要求する量が大きいと提出の必要なドキュメントの量が多くなり、要求量が小
さい場合はアドレス空間の割り当てをサービスプロバイダに委託することにな
るので、注意されたい。
例:
host-bits: 9
CONNECTIVITY:
貴組織のネットワークがどのようにインターネットに接続するのかを記入する。
このフィールドに記入できる値は、PEERING-POINT、SERVICE-PROVIDER、OTHER、
またはNONEのいずれかである。PEERING-POINTは、3つ以上のサービスプロバイ
ダが共通の第2層インフラストラクチャを共有しているニュートラルなインター
ネット相互接続点を使用して、トラフィックを交換することを意味する。
PEERING-POINT接続の例としては、米国のMAE-West、香港のHKIXなどがある。
SERVICE-PROVIDERは、インターネット接続サービスを提供する組織を利用する
ことを意味する。SERVICE-PROVIDER接続の例としては、MCI、UUNetなどがある。
OTHERは、ピア接続点もサービスプロバイダも利用しないことを示す。この場
合は、どのような手段によってインターネットへの接続を行うかを、
ADDITIONAL COMMENTSセクションに記入する必要がある。NONEは、グローバル
インターネットに接続する意志がないことを示す。この場合は、なぜ限定グロー
バルアドレスを必要とするのか、およびなぜ RFC 1918に指定されているプラ
イベートアドレスを使用できないのかを、ADDITIONAL COMMENTSセクションに
詳細に記入されたい。複数の接続手段を利用することを予定している場合は、
1行に1つずつ、すべての接続手段を列記していただきたい。
例:
connectivity: PEERING-POINT
CONN-PROVIDER:
インターネットへの接続手段をネットワークに提供する組織の名前を記入する。
PEERING-POINT接続の場合は、ピア接続点の名前を記入する。ネットワークが
接続するピア接続点が複数ある場合は、必要数のCONN-PROVIDER行を使用する。
接続手段としてSERVICE-PROVIDERを指定した場合は、必要数の CONN-PROVIDER
行を使用して、インターネットサービスを提供するすべての組織の名前を列記
する。接続手段としてOTHERを指定した場合は、接続を確保するために使用す
る手段を示す情報を記入する。NONEを選択した場合は、このフィールドはブラ
ンクのままでよい。
例:
conn-provider: MAE-West
ALL-0S-SUBNETS:
全桁0のサブネットをサポートできる場合はYES、そうでない場合はNOを記入す
る。NOを記入した場合は、申請書の末尾の"Additional Comments"セクション
にその説明を記入されたい。主要なルータベンダは、すべて全桁0のサブネッ
トをサポートできるという点に注意されたい(ただし、デフォルト構成をその
ように変更しなければならない場合もある)。
例:
all-0s-subnets: YES
ALL-1S-SUBNETS:
全桁1のサブネットをサポートできる場合はYES、そうでない場合はNOを記入す
る。NOを記入した場合は、申請書の末尾の"Additional Comments"セクション
にその説明を記入されたい。主要なルータベンダは、すべて全桁1のサブネッ
トをサポートできるという点に注意されたい(ただし、デフォルト構成をその
ように変更しなければならない場合もある)。例:
all-1s-subnets: YES
SUPERNETS:
スーパーネット化をサポートできる場合、つまり複数の隣接するネットワーク
を統合して単一のルートとして提供できる場合はYES、そうでない場合はNOを
記入する。NOを記入した場合は、申請書の末尾の"Additional Comments"セク
ションにその説明を記入されたい。
例:
supernets: YES
SUBNETS:
サブネット化をサポートできる場合、つまり単一のルーティンOプレフィック
スの個々の部分を別々にルーティングできる場合はYES、そうでない場合はNO
を記入する。NOを記入した場合は、申請書の末尾の"Additional Comments"セ
クションにその説明を記入されたい。注: APNICでは、貴組織がサブネットを
使用することを前提としている。これをしない場合は、追加のアドレス空間を
請求するときに正当な理由が必要とされる。
例:
subnets: YES
NETWORK-PLAN:
このフィールドには、割り振られたアドレス空間を以後24ヶ月間にどのように
使用するかを記入する。NETWORK-PLANフィールドの形式は次のとおりである。
network-plan: address mask connect max hinit/h1yr/h2yr remark
上記において:
address -
ネットワークの始めをオフセットにより示す小数点付き10進数形式。たとえ
ば、マスク255.255.255.0の場合、0.0.1.0は第2/24を示す(マスク
255.255.255.0の場合の第1/24は0.0.0.0)。mask -
小数点付き10進数形式で表わしたネットワークのネットマスク。たとえば、
255.255.255.240
connect -
ネットワークをインターネットに接続しない場合は'NO'、パートタイム接続
(たとえばダイヤルアップ接続など)の場合は'PART'、その他の場合(たとえば
「ping可能」な場合など)は'YES'
max -
ネットワーク上で使用可能なホストアドレスの最大数。全桁0のホストパート
および全桁1のブロードキャストアドレスがあるので、必ず最大数から2を引い
た値を記入されたい。
hinit -
初期時点で予定されているか、または現在インストールされているデバイス数。
h1yr - 1年後に予定されているデバイス数。
h2yr - 2年後に予定されているデバイス数。
remark - ネットワークに関する注釈。
NETWORK-PLANフィールドは必要に応じいくつでも使用して、将来のネットワー
ク計画をできるだけ正確に記入する。NETWORK-PLANフィールドは、ネットワー
ク用のアドレス空間の必要量を実証するためのものである。デバイスの見積り
数には、グローバルに固有なIP番号を必要とするすべてのデバイス(PC、ワー
クステーション、サーバ、プリンタ、ルータなど)が含まれていることを確認
する必要がある。ネットワークの実際のレイアウトを示すために、各サブネッ
トワークごとに同じ行を複写することは避け、必ず有効なネットワーク番号お
よび関連のネットワークマスクを指定されたい。
例:
network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 HQ support group
network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 HQ customer svc
old-network:
すでに割り振り済みのアドレス空間の利用効率を高めるために、APNICは、貴
組織に割り振り済みのアドレスの使用状況を知る必要がある。アドレス割り振
りにおいて「組織」というのは、外部ソースのプライベートネットワーク、つ
まり「イントラネット」も含めて内部的に接続される、貴社の全部分(ネット
ワークの地理的位置や会社名の違いに関係なく、親会社、子会社、支社などを
含む)を意味する。貴組織が過去にアドレス空間を取得している場合は、割り
振られている実際のネットワーク数と各ネットワーク上のデバイス数を、次の
形式で記入していただきたい。
old-network: address mask connect devices remark
上記において:
address -
使用されている実際のネットワークアドレスを使用して小数点付き10進数で
表わしたネットワーク番号
mask - 小数点付き10進数形式で表わしたネットワークのネットマスク。
例: 255.255.255.240
connect -
ネットワークをインターネットに接続しない場合は'NO'、パートタイム接続
(たとえばダイヤルアップ接続など)の場合は'PART'、その他の場合(たとえば
「ping可能」な場合など)は'YES'
devices - ネットワークに接続されているデバイス数
remark - ネットワークに関する注釈
過去に貴組織にネットワークが割り振られていない場合は、このフィールドは
ブランクのままにする。
例:
old-network: 202.5.10.0 255.255.255.0 YES 220 R&D Division
old-network: 202.5.11.0 255.255.255.128 YES 104 Marketing
old-network: 202.5.11.128 255.255.255.128 YES 112 Sales
EXPLANTION WHY YOU CANNOT OBTAIN ADDRESSES FROM YOUR SERVICE PROVIDER:
サービスプロバイダからアドレスを取得できない理由を詳しく記入する。この
説明がない場合は、申請書は受理されずに返却される。APNICは、すべての組
織に対し、極力インターネットサービスプロバイダからアドレスを取得するよ
う強く奨励する。詳細については、「補足注意事項」を参照されたい。
ADDITIONAL COMMENTS:
このセクションには、申請の正当性を主張するために役立つと思われるその他
の任意の詳細情報を記入できる。特に、ネットワークトポロジーを表す図表や、
アドレス空間利用およびサブネット計画の根拠を示す詳しい説明があれば、
APNICにおいて何らかの疑問点が生じたとしても、貴組織のネットワークに関
する必要条件を理解しやすくなるため、それだけ早期に要求が処理されること
になる。上記のCONNECTIVITYフィールドに"NONE"を指定した場合は、RFC-1918
プライベートネットワークを使用できない理由を詳細に示す説明を記入された
い。
5. 補足注意事項
-------------------
5.1 エンドユーザアドレス空間の取得に関する妥当な見解
結論から言えば、APNICは、組織に対し、APNICまたは他の非プロバイダレジス
トリから、プロバイダから独立したアドレス空間を取得することは極力避ける
よう強く勧奨する。インターネットが現在の速度で成長を続けるためには、イ
ンターネットアドレスを階層的に割り振ることが必要である。そうすることで、
アドレス体系情報を隠すことが可能になり、グローバルに周知する必要がなく
なる(階層的アドレス体系の一例として電話システムがある。イタリアの電話
交換台は、日本の特定の電話番号に到達する方法を知っているわけではなく、
交換台に直接接続していない番号の到達するための交換局に達する方法を知っ
ているだけである。交換局は、他国の交換局の所在場所等を知っている国際幹
線システムに到達する方法を知っている。)階層的アドレス体系を実装するに
は、ネットワークのトポロジーに対応するような形でアドレスを割り当てる必
要がある。インターネットにおいては、インターネットサービスプロバイダが
ネットワークトポロジーを定義するので、インターネットが将来拡大するとす
れば、そのアドレスはインターネットサービスプロバイダが割り当てる必要が
ある。このようにすれば、グローバルルーティングシステムは、個々のインター
ネットサービスプロバイダに到達する方法だけ知っていればよいことになる。
現在、グローバルルーティングシステムが公示しているネットワーク数は
50,000を超えている。このレベルで、インターネットはすでに破綻の危機に瀕
している。この破綻の徴候として、ルータのメモリ不足現象が発生している
(その結果、ルータは、クラッシュ、リブート、復帰、再度メモリ不足、クラッ
シュの繰り返しが発生する)。あるいは、これら50,000個のネットワークとそ
のサイトのそれぞれに到達する方法を計算するために、CPUの能力の限界を超
えることもある(ネットワークがダウンしたり復帰したりするたびに、そのネッ
トワーク上のすべてのサイトに到達する方法の再計算が必要になる。これに、
上記で述べたメモリの問題が加わって事態は一層深刻になる。)これらの問題
は、最終的にはインターネットの該当部分が到達不能になるという状況をもた
らす。
サービスプロバイダブロック以外のブロックから割り振られたアドレスを使用
するサイトが1つインターネットに加わった場合、それはそのサイトをグロー
バルルーティングテーブルに追加しなければならないことを意味する。現在、
大規模なサービスプロバイダの間では、各自のカスタマを保護し、各自のネッ
トワークの機能性を確保することを目的として(多くのサイトはインターネッ
ト自体には関心がなく、支社との連絡用などにインターネットを利用すること
が多いため)、ブロック外のネットワーク公示を無視したり、サービスプロバ
イダブロック外のカスタマからのネットワークの受け入れを拒否したりしよう
とする動きが広がってきている。一般に、アドレスブロックでアドレス指定で
きるホスト数が少ないほど、無視される可能性も強くなる。アクセス拒否は全
世界の随所で随時発生する恐れがあり、その結果、貴組織を無視するネットワー
ク、または貴組織を無視するネットワークを介して接続されているネットワー
ク上のどこにも到達できなくなるという点に注意する必要がある。
この問題を打破するために、各レジストリは、アドレス空間を要求するサイト
に対し、サービスプロバイダからアドレス空間を取得するよう強く勧奨してい
る。一般にサービスプロバイダブロックは規模が大きいので、無視されること
はない。貴組織がまだサービスプロバイダを1つも選定していない場合、APNIC
は、該当地域内にあるAPNIC登録のサービスプロバイダの少なくとも1つが、貴
組織のプロバイダ独立ネットワークブロックを受け入れる意志があることを示
す証拠の提出を求める。ただし、APNICからアドレス空間の割り振りを受けた
場合、現在においても将来においても、そのアドレス空間のルーティング可能
性にまったく保証がないことを明確に認識する必要がある。
ほとんどのインターネットユーザにとって関心の的は、インターネットの機能
が継続的に確保され、可能な限り多くの場所にアクセスできることにあるので、
レジストリは、サイトに対し、サービスプロバイダからアドレスを取得するこ
と、そして、サービスプロバイダを変更するときはそれらのアドレスを返還す
ることを、強く勧奨している。
5.2 「非接続」ネットワークおよびRFC 1918
現在の割り当てガイドラインは、アドレス空間を効率的に利用することを要求
している。アドレス空間を要求しているネットワークを、セキュリティその他
の理由によりインターネットに接続する予定がない場合、または管理上の便宜
を確保するためにアドレス空間のリザーブを望んでいる場合は、貴組織のネッ
トワーク (またはその一部) にとってはRFC 1918の方が適切ではないかという
ことを検討していただきたい。RFC 1918には、予測できる将来においてインター
ネットに接続する予定のないネットワーク用としてIPアドレス空間を要求する
場合に従うべき方針と手続きに関する重要な情報が収められている。ただし、
RFC 1918プライベートネットワークの利用については、少々論議の余地がある。
貴組織の場合にこれらのRFCが適用可能かどうかについて疑問がある場合は、
APNICに連絡していただきたい。
5.3 追加のアドレス空間を要求する場合のその他のヒント
組織が追加のネットワーク番号を必要とする場合は、その組織がすでに保有し
ているアドレス空間の利用状況に関する情報を申請書に記入する必要がある。
この情報には、実際に使用しているIPネットワーク番号と未使用の番号、実際
にインストールされているサブネット数、それらに接続しているホスト、およ
び、新規の要求の根拠を実証するその他の組織的情報を含める必要がある。以
前に割り当てられたネットワーク番号に関するこれらのデータは、IPアドレス
空間の利用状況に関するグローバルな監視のための不可欠な情報であり、レジ
ストリの運用に対するフィードバックでもある。この情報を要求する目的は、
要約すれば次の点にある。
- 使用可能なアドレス空間を適正に使用していることを確認するため
- 可能な限り連続したアドレスブロックを1つのものとして割り当てるため
(これによりルーティング情報を集約することができる)
この目的のためには、真に必要なネットワーク要件を適正に見積ることが必要
であり、また、単に当面の必要姓またはネットワークの特定部分のみに限定さ
れない計画が望まれる。
5.4 「クラスB」ネットワーク番号に関するその他のヒント
「クラスB」ネットワークアドレスの割り振り基準はきわめて厳密な烽フであ
る。これは、これらのネットワーク番号が世界的に不足していることに原因が
ある。したがって、ローカルレジストリおよびAPNICは、「クラスB」のネット
ワークアドレスに対するすべての要求を、厳密に審査する必要がある。結果と
して、「クラスB」の要求の割り振り処理には時間がかかることになる。組織
が、最初の要求の際に可能な最大限の情報を提供し、APNICが追加情報の要求
を必要とせずに決定を行うことができれば、申請の処理に要する期間を短縮で
きる。ホストの見積り数については、従業員数、地理的分布、ホストのタイプ
など、ネットワークおよび組織に関するその他のデータによって根拠を明らか
にする必要がある。見積り数の根拠が明確であるほど、当方における「クラス
B」アドレス割り振りの妥当性を判断することが容易になる。
APNICでは、十分なホスト数に加えて、隣接する複数の「クラスC」ネットワー
クを使用するだけでは貴組織のネットワークを設計できないということも確認
する必要がある。貴組織のネットワークが多数の物理ネットワークから成り、
各ネットワークのホスト数が比較的少ない場合は、クラスCネットワークのサ
ブネット化を検討する必要がある。多数のサブネットワークがあるというだけ
では、クラスBネットワーク番号の割り振りを正当化する十分な理由とは言え
ない。APNICでは、エンジニアリングに関する多くの決定が、管理上の便宜に
基づくものであることを認識している。残念ながら、現在残されているクラス
Bアドレス空間は、こういった事情を考慮するには余りに少なすぎる。一連の
クラスCネットワーク番号を使用してもネットワークを設計できない理由の説
明が明確であるほど、クラスBネットワークアドレスの割り振りの妥当性を確
認することが容易になる。
複数のクラスBネットワーク番号を要求する場合は、上記で述べたすべての条
件がさらに厳しく適用される。複数のクラスBネットワーク番号を割り当てる
のは、貴組織のローカルレジストリ、APNIC、さらに場合によってはIANAが、
上記で述べた基準に照らして明白に正当であると確信した場合のみである。
6. APNIC NICハンドルの取得
--------------------------------
PERSONテンプレートに記入する場合、またはAPNIC登録データベース内の他オ
ブジェクト内の人物を参照したい場合は、APNIC NICハンドル('nic-hdl:')を
使用する必要がある。NICハンドルは個々の人物に付随している固有な識別子
で、同名の人が複数いる場合の参照用として使用できる。APNIC NICハンドル
を取得するには、NIC-HDLフィールドに次のように記入する。
nic-hdl: AUTO-1
(最後の文字は、アルファベットの'l'ではなく数字の'1'である。これにより、
データベースソフトウェアは、指定された人の頭文字に基づき、APNICハンド
ルを導き出し作成する。たとえば、次のpersonオブジェクトを提出したとする
(これと同じものをそのまま提出してはならない)。
person: David Conrad
address: Asia Pacific Network Information Centre
address:Level 1, 33 Park Road
address:P. O. Box 2131
address:Milton, QLD 4064
country:AU
[...]
nic-hdl:AUTO-1
[...]
この場合、データベースソフトウェアは次の形式のNICハンドルを生成する。
DC###-AP
上記において、###は、DCで始まるAPNIC
NICハンドルが固有なものとみなされる次の使用可能番号である。
上記の代わりに、ハンドルのプレフィックスに使用する頭文字の生成をデータ
ベースソフトウェアに任せずに、特定の頭文字を指定することもできる。たと
えば次のようにNIC-HDLを指定する。
nic-hdl: AUTO-1<initials>
上記の<initials>('<'と'>'は不要)は4文字以内とする。データベースソフト
ウェアはこれらの頭文字を使用してハンドルを作成する。たとえば次のように
なる。
person: David Conrad
address: Asia Pacific Network Information Centre
address:Level 1, 33 Park Road
address:P. O. Box 2131
address:Milton, QLD 4064
country: AU
[...]
nic-hdl:AUTO-1RC
[...]
この場合、データベースソフトウェアは次の形式のNICハンドルを生成する。
RC###-AP
上記において、###は、RCで始まるAPNIC
NICハンドルが固有なものとみなされる次の使用可能番号である。
他のオブジェクト内の同じアップデートメッセージで、同じ識別子(AUTO-1ま
たはAUTO-1<initials>)を参照として使用することができる。その場合は、デー
タベースソフトウェアは、新たに割り当てられたNICハンドルをそのオブジェ
クトに入れる。他の番号(たとえば、AUTO-2)を使用して、さらに多くのperson
オブジェクトおよび該当の人物を参照するオブジェクトを、1つのEメールメッ
セージの中でアップデートすることもできる。たとえば次のようになる。
[...]
admin-c: AUTO-1
tech-c: AUTO-2
[...]
person: David Conrad
[...]
nic-hdl: AUTO-1
[...]
person: Yoshiko Chong
[...]
nic-hdl: AUTO-2
[...]
この場合、2つの新しいハンドルが作成される。1つはDC###-APの形式で、これ
はADMIN-CフィールドおよびDavid ConradのNIC-HDLフィールドに入れられる。
もう1つはYC###-APの形式で、これはTECH-CフィールドとYoshiko Chongの
NIC-HDLフィールドに入れられる。
7. 例
----------
#[NETWORK TEMPLATE V:4.0]#
netname: EXAMPLE-AP
descr: エンドユーザ申請書の記入例。
descr: これをそのままAPNICに送ってはならない。
country: JP
admin-c: DC1-AP
tech-c: YF1-AP
changed: davidc@apnic.net 19960501
mnt-by: MAINT-APNIC-AP
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person: David R Conrad
address: Asia Pacific Network Information Centre
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
phone: +61-7-3367-0490
fax-no: +61-7-3367-0482
e-mail: davidc@apnic.net
nic-hdl: DC1-AP
changed: davidc@apnic.net 19960401
mnt-by: MAINT-APNIC-AP
source: APNIC
#[PERSON TEMPLATE V:4.0]#
person: Yoshiko O Chong Fong
address: Asia Pacific Network Information Centre
address: Level 1, 33 Park Road
address: P. O. Box 2131
address: Milton, QLD 4064
country: AU
phone: +61-7-3367-0490
fax-no: +61-7-3367-0482
e-mail: yoshiko@apnic.net
nic-hdl: YF1-AP
changed: davidc@apnic.net 19960401
mnt-by: MAINT-APNIC-AP
source: APNIC
#[END USER TECHNICAL TEMPLATE V:1.0]#
acct-name: APNIC-AP
host-bits:8
connectivity: SERVICE-PROVIDR
conn-provider: SuperNetworks, Inc.
all-0s-subnets: YES
all-1s-subnets: YES
supernets:YES
subnets: YES
network-plan: 0.0.0.0 255.255.255.0 YES 4/84/107 hardware lab
network-plan: 0.0.0.128 255.255.255.128 YES 0/0/126 R&D net
old-network: 202.12.28.0 255.255.255.252 YES 2 point-to-point link
old-network: 202.12.28.4 255.255.255.252 NO 0 unused
old-network: 202.12.28.8 255.255.255.248 YES 6 marketing dept.
old-network: 202.12.28.16 255.255.255.240 YES 14 sales dept.
old-network: 202.12.28.32 255.255.255.224 YES 27 allocation dept.
old-network: 202.12.28.64 255.255.255.192 YES 55 recovery dept.
old-network: 202.12.28.128 255.255.255.192 YES 47 service segment
old-network: 202.12.28.224 255.255.255.192 NO 38 accounting dept.
#[TEMPLATES END]#
Explanation why you cannot obtain addresses from your service provider:
We run a root domain server, thus we must have addresses that do not need to
be renumbered in the event of a change of Internet service providers. We
have obtained agreements from all major transit providers (available on
request) to propagate our long prefix network.
Additional Comments:
We will be using BFR routers running BGP-4 to peer with our service
provider. We will also be using OSPF to manage our internal
infrastructure.
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
8. 推薦図書
----------------------
RFC 1466 E. Gerich, "Guidelines for Management of IP Address Space",
5/26/93, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1466.txt
RFC 1517 R. Hinden, "Applicability Statement for the Implementation of
Classless Inter-Domain Routing (CIDR), 9/24/93, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1517.txt
RFC 1518 Y. Rehkter, T. Li, "An Architecture for IP Address Allocation
with CIDR", 9/24/93, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1518.txt
RFC 1519 V. Fuller, T. Li, J. Yu, K. Varadhan, "Classless Inter-Domain
Routing (CIDR): an Address Assignment and Aggregation Strategy",
9/24/93, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1519.txt
RFC 1744 G. Huston, "Observations on the Management of the Internet
Address Space", 12/23/94, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1744.txt
RFC 1814 E. Gerich, "Unique Addresses are Good", 6/22/95, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1814.txt
RFC 1817 Y. Rehkter, "CIDR and Classfull Routing", 8/4/95, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1817.txt
RFC 1879 B. Manning, "Class A Subnet Experiment Results and
Recommendations", 1/15/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1879.txt
RFC 1878 T. Pummill, B. Manning, "Variable Length Subnet Table For IPv4",
12/26/95, URL: ftp://ftp.apnic.net/ietf/rfc/rfc1878.txt
RFC 1900 B. Carpenter, Y. Rehkter, "Renumbering Needs Work", 2/28/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1900.txt
RFC 1916 H. Berkowitz, P. Ferguson, W. Leland, P. Nesser, "Enterprise
Renumbering: Experience and Information Solicitation", 2/28/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1916.txt
RFC 1917 P. Nesser, "An Appeal to the Internet Community to Return Unused
IP
Networks (Prefixes) to the IANA", 2/29/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc1917.txt
RFC 1918 Y. Rehkter, R. Moskowitz, D. Karrenberg, G. de Groot, E. Lear,
"Address Allocation for Private Internets", 2/29/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc1918.txt
RFC 2008 Y. Rehkter, T. Li, "Implications of Various Address Allocation
Policies for Internet Routing", 10/14/96, URL:
ftp://ftp.apnic.net/ietf/rfc/rfc2008.txt
RFC 2036 G. Huston, "Observations on the use of Components of the
Class A Address Space within the Internet, 10/30/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc2036.txt
RFC 2050 K. Hubbard, M. Kosters, D. Conrad, D. Karrenberg, J. Postel,
"Internet Registry IP Allocation Guidelines", 11/6/96,
URL: ftp://ftp.apnic.net/ietf/rfc/rfc2050.txt
isp-address-request APNIC Staff, "Internet Service Provider Internet
Address Request Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/
docs/isp-address-request
confed-address-request APNIC Staff, "Confederation Internet Address Request
Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/
confed-address-request
上記の資料はすべて、APNICのドキュメントストアにおいて、該当URLに示され
ているディレクトリから入手できる。APNICドキュメントストアには次の方法
でアクセスできる。
1. ホストftp.apnic.netから匿名FTPを利用
ftpアプリケーション(通常単に'ftp'と呼ばれる)を使用し、自分のEメールア
ドレスをパスワードとして使用してホストftp.apnic.netに接続する。RFCの場
合は、「ディレクトリ変更」コマンド(一般に'cd')を使用して、'/ietf/rfc'
に変更する。APNICドキュメントの場合は、'/apnic/docs'に変更する。次に
「取得」コマンド(一般に'get')を使用して、ファイルを検索する。
2. APNIC FTP EメールゲートウェイからEメールを利用
メッセージのボディに標準UNIX 'ftp'コマンドを入れたEメールを、
'ftpmail@postoffice.apnic.net'に送ることができる。詳しいヘルプが必要な
場合は、メッセージボディに'help'と入れて、Eメールメッセージを'
ftpmail@postoffice.apnic.net'に送る。結果はメールで送り返される。
Eメール接続手段を持たない組織が「推薦図書」のコピーを望む場合は、APNIC
またはそのローカルレジストリまたは国別レジストリに連絡して、必要な資料
の郵便による送付を要請する必要がある。ハードコピーバージョンの資料の送
付には料金が必要になることがあるので了解いただきたい。
9. 謝辞
-------------------
本書の大部分は、ヨーロッパレジストリRIPE-NCC
<ncc@ripe.net>のスタッフが作成した文書からとったものである。
