+-----------------------------------------------------------------------+ | JPNIC公開文書著作権表示 (Copyright notice of JPNIC open documents) | | | | この文書はJPNIC公開文書であり、著作権は日本ネットワークインフォ | | メーションセンター(JPNIC)が保持しています。JPNIC公開文書は誰でも | | 送付手数料のみの負担でJPNICから入手できます。また、この著作権 | | 表示を入れるかぎり、誰でも自由に転載・複製・再配布を行なって構 | | いません。 | | 〒101-0052 東京都千代田区神田小川町1-2 風雲堂ビル1F | | （社）日本ネットワークインフォメーションセンター | +-----------------------------------------------------------------------+ "APNIC Internet Service Provider Internet Address Request Form" 翻訳文 (ftp://ftp.nic.ad.jp/jpnic/translation/apnic-065-j.txt) （社）日本ネットワークインフォメーションセンター 最終更新 1999年 4月 28日 この文書は http://ftp.apnic.net/apnic/archive/apnic-065.txt を翻訳したものです。実際に使用できる申請書ではありません。JPNICはこの 翻訳を参考のために提供しますが、その品質に責任を負いません。 ------------------------------------------------------------------------ APNIC-065 ========= APNIC Internet Service Provider Internet Address Request Form(APNICインターネットサービスプロバイダ用インターネットアドレス申請書) 1998年8月発行 この書式は、組織がその組織とは無関係の外部組織にインターネット接続サー ビスを提供するに伴い、その外部組織にサブデリゲートされるアドレス空間を 要求するために使用する。内部組織(子会社や支社など)へのサブデリゲートを 行う場合は、"End User Internet Address Request Form"を使用されたい (ftp://ftp.apnic.net/apnic/docs/end-user-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 Center 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:5.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 #[ISP TECHNICAL TEMPLATE V:4.0]# acct-name: connectivity: conn-provider: all-0s-subnets: all-1s-subnets: supernets: subnets: portable: cust-network: cust-network: infrastructure: infrastructure: network-plan: network-plan: #[TEMPLATES END]# Explanation why you cannot obtain addresses from your service provider: Additional Comments: - - - - - - - - - - - - - - 切り取り線 - - - - - - - - - - - - - - - - - 1. この書式の記入方法 ---------------------------------------- 以下、APNIC Internet Service Provider Internet Address Request Formの記入方法について説明する。下記に挙げるタグの属性を正しく記入す ることはきわめて重要である。記入洩れがあると、サービスの遅延が生じ、要 求したIPアドレスの提供が遅れることがある。 ISP TECHNICAL TEMPLATEに記入された情報は極秘扱いとして保護する。したがって、セキュ リティ上の理由によりこれらのフィールドを空白のままとすることは認められ ない。この点に関する詳しい説明については、hostmaster@apnic.netに照会さ れたい。 NETWORKおよびPERSONテンプレートに記入された情報は、whois.apnic.netに対 するWHOISまたはその他のメカニズムにより、インターネット上で利用できる 情報となる。これらの情報は、インターネットの操作に関連した問題を診断し 解決することを目的として、インターネットコミュニティに提供される。これ 以外の目的にこれらの情報をAPNIC Pty Ltd.の許諾なく利用することを、厳重に禁止する。 APNICへの申請はコンピュータで処理されるので、申請書はプレーンASCIIで記 入しなければならない。デコードをまったく必要とせずに読める形式になって いない限り、MIMEコードの使用は認められない。特に、BASE64エンコードテク ニックは決して使用しないよう注意されたい。さらに、たとえばテンプレート 内でテキストの位置調整や行間へのブランク行の挿入など、申請書の書式に手 を加えることはいっさいしないようにしていただきたい。自動構文解析システ ムは上記の書式からの著しい逸脱には対応できないので、これらの条件が満た されていないと構文エラーが返されることがある。下記に、記入済みの書式の 例を掲げる。 すでに述べたように、この書式に関する質問や意見があるときは、いつでも hostmaster@apnic.netにご連絡いただきたい。 2. ISP Internet Address RequestのNetworkテンプレートの記入方法 -------------------------------------------------------- NETNAME: このネットワークを表す、短くてしかも意味のある記述的な名前を記入する。 NETNAMEは、インターネットレジストリの整合性チェックなど、主として管理 目的に使用される。ネットワーク名は、最大25文字の大文字の英数字のみを使 用して、単一のワードで表現しなければならない。ネットワーク名には、ネッ トワークが割り当てられる組織に関連のある名前を使用することが望ましい。 ネットワーク名はドメイン名とは関係がないので、FOO.COMなどのドメイン名 は使用しないようにされたい。各NETWORKテンプレートにつき必ずNETNAMEタグ が1つ必要である。 例: netname: TBIT DESCR: 貴組織をAPNICデータベース内の他の組織と区別できる十分な詳細情報を示す、 組織に関する短い記述(住所を含む)を記入する。たとえば、"descr:Computer Center"などの記述では不十分である。組織記述には、"The best internet provider 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 国際的なネットワークの場合は単一の国のみを記入することは困難な場合があ るものと考えられるが、その場合は、管理連絡窓口の所在場所を基準として最 も適切と思われる国を選んでいただきたい。COUNTRYタグはすべてのNETWORKテ ンプレートに記入する必要があり、それぞれ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: 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 3. ISP 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 -pager CHANGED: このテンプレートを記入している人のEメールアドレスと、YYYYMMDD形式の現 在の日付を記入する(YYYYは年、MMは月、DDは日で、空白桁にはすべて0を記入)。 これが新規のPERSONオブジェクトである場合は、各PERSONテンプレートにつき 必ずCHANGEDタグが1つ必要である。 例: changed: johndoe@terabit.na 19950225 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つの要求テンプレートにつき0個でも1個以上でもさしつ かえないが、指定するMAINTAINERオブジェクトはAPNIC登録データベースにす でに存在しているものでなければならない。 例: mnt-by: MAINT-FOO-AP SOURCE: 情報のソース。APNIC書式の場合、これは常にAPNICである。これはデータベー ス内の必須情報なので、最初から書式に記入されている。 例: source: APNIC 4. ISP 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 CONNECTIVITY: 貴組織のネットワークがどのようにインターネットに接続するのかを記入する。 このフィールドに記入できる値は、PEERING-POINT、SERVICE-PROVIDER、また はOTHERのいずれかである。PEERING-POINTは、3つ以上のサービスプロバイダ が共通の第2層インフラストラクチャを共有しているニュートラルなインター ネット相互接続点を使用して、トラフィックを交換することを意味する。 PEERING-POINT相互接続の例としては、米国のMAE-West、香港のHKIXなどがあ る。SERVICE-PROVIDERは、インターネット接続サービスを提供する組織を利用 することを意味する。SERVICE-PROVIDER接続の例としては、MCI、UUNetなどが ある。OTHERは、ピア接続点もサービスプロバイダも利用しないことを示す。 この場合は、どのような手段によってインターネットへの接続を行うかを、 ADDITIONAL COMMENTSセクションに記入する必要がある。複数の接続手段を利 用することを予定している場合は、1行に1つずつ、すべての接続手段を列記し ていただきたい。 例: connectivity: PEERING-POINT CONN-PROVIDER: インターネットへの接続手段をネットワークに提供する組織の名前を記入する。 PEERING-POINT接続の場合は、ピア接続点の名前を記入する。ネットワークが 接続するピア接続点が複数ある場合は、必要数のCONN-PROVIDER行を使用する。 接続手段としてSERVICE-PROVIDERを指定した場合は、必要数の CONN-PROVIDER 行を使用して、インターネットサービスを提供するすべての組織の名前を列記 する。接続手段としてOTHERを指定した場合は、接続を確保するために使用す る手段を示す情報を記入する。 例: 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: サブネット化をサポートできる場合、つまり単一のルーティングプレフィック スの個々の部分を別々にルーティングできる場合はYES、そうでない場合はNO を記入する。NOを記入した場合は、申請書の末尾の"Additional Comments"セ クションにその説明を記入されたい。注: APNICでは、各ISPが、自己に割り振 られているプレフィックスのサブネットを、カスタマへの割り当て用に使用す ることを前提としている。これをしない場合は、追加のアドレス空間を請求す るときに正当な理由が必要とされる。 例: subnets: YES PORTABLE: カスタマが別のプロバイダに移籍するときに、割り当てられているアドレスを そのまま保持できるようにする場合、つまり割り当てたアドレスをプロバイダ 間でポータブルにする場合は、この属性にYESを指定する。そうでない場合は NOを指定する。現在、インターネットルーティングシステムでは各種の限界が 生じているため、ポータブルなアドレス空間の使用は極力避けるよう強く要請 する。ただし、カスタマに対し、接続契約の終了時にアドレス空間を返還すべ きことを明示的に言明していない組織は、ポータブルなアドレス空間を割り当 てているものとみなされる。詳細については、「補足注意事項」を参照された い。 例: portable: NO CUST-NETWORK: CUST-NETWORKフィールドには、貴組織が過去においてカスタマに対して行った 割り当てに関する情報の要約を記入する。過去にネットワークを割り振ったこ とがない場合は、このフィールドはブランクのままにしておく。すでにカスタ マに対しネットワークを割り当てている場合は、それらのネットワークに関す る再割り当て情報を次の形式で記入する必要がある。 cust-network: netname address mask hinit/h1yr/h2yr sinit/s1yr/s2yr date 上記において: netname - 貴組織が割り当て、APNICデータベースに入っている名前(注: この名前は貴組織が自由に決定できるが、ネットワークを割り当てる対象組 織に関連した名前を使用することが望ましい)。 address - 割り当てたネットワークのスターティングアドレス mask - 割り当てたネットワークのサブネットマスク。小数点付き10進数形式を使用 (たとえば、255.255.248.0) hinit - 初期の見積りデバイス数 h1yr - 1年後の見積りデバイス数 h2yr - 2年後の見積りデバイス数 sinit - 初期の見積りサブネット数 s1yr - 1年後の見積りサブネット数 s2yr - 2年後の見積りサブネット数 date - 割り当てが発生した日付(YYYYMMDD形式) APNICでは、過去の割り当ての履歴に基づいて将来の割り振りを行うので、こ のフィールドは正しく記入することが非常に重要である。APNICは、 CUST-NETWORKフィールドの情報を元にして、貴組織のアドレス割り当てのパター ンを確認する。CUST-NETWORKフィールドのnetname部分は、APNICデータベース 内の再割り当てのNAETNAMEフィールドと正確に一致するように、細心の注意を 払って記入していただきたい。さもないと、APNICは、記載されているネット ワークが再割り当てされていないものとみなす。CUST-NETWORKフィールドは、 貴組織がAPNIC割り振りのアドレスを使用して割り当てたしたすべてのネット ワークを記述するのに必要な数だけ使用する。非CIDR方式で割り当てたネット ワークがある場合(たとえば、サブネットを記述できる単一のサブネットマス クがない場合)は、複数のCUST-NETWORKフィールドを使用してCIDR方式での割 り当てを記述する。その場合は、必要に応じてフィールドごとにネットワーク 名を繰り返し記入する。 注: CUST-NETWORKにより記述したアドレス数と、INFRASTRUCTURE(下記を参照)に より記述したアドレス数の合計が、貴組織のネットワークですでに利用されて いるアドレス空間の合計量とみなされる。 例: cust-network: FOO-AP 202.12.28.0 255.255.255.128 10/15/80 1/1/2 19960501 cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100 2/3/4 19960515 INFRASTRUCTURE: INFRASTRUCTUREフィールドには、貴組織のネットワークインフラストラクチャ 用として現在使用しているアドレス、つまり、まだカスタマに割り当てておら ず、APNICデータベースおよび上記のCUST-NETWORKフィールドのどちらにも含 まれていないアドレスの要約を記入する。INFRASTRUCTUREフィールドの形式は 次のとおりである。 infrastructure: address mask connect max hinit/h6mo/h1yr remark 上記において: ネットワーク内で割り当てられているネットワークの始めを示す小数点付き 10進数。例: 202.12.28.192 mask - 小数点付き10進数形式で表わしたネットワークのネットマスク。例: 255.255.255.240 connect - ネットワークをインターネットに接続しない場合は'NO'、パートタイム接続 (たとえばダイヤルアップ接続ネットワークなど)の場合は 'PART'、その他の場合(たとえばいつでも「ping可能」な場合など)は'YES' max - ネットワーク上で使用可能なホストアドレスの最大数。全桁0のホストパート および全桁1のブロードキャストアドレスがあるので、必ず最大数から2を引い た値を記入されたい。 hinit - 初期時点で予定されているか、または現在インストールされているデバイス数。 h6mo - 6ヶ月後に予定されているデバイス数。 h1yr- 1年後に予定されているデバイス数。 remark - ネットワークに関する注釈。 INFRASTRUCTUREフィールドは必要に応じていくつでも使用して、貴組織の内部 インフラストラクチャを正確に記入する。INFRASTRUCTUREフィールドで、まだ 使用していないネットワークを記述してはならない。インフラストラクチャを 非CIDR境界上で運用してきている場合(たとえば、サブネットを記述できる単 一のサブネットマスクがない場合)は、複数の INFRASTRUCTUREフィールドを使 用して、CIDR方式でインフラストラクチャを記述する(255.255.255.255マスク の使用による単一ホストの定義を含む)。デバイスの見積り数には、グローバ ルに固有なIP番号を必要とするすべてのデバイス(PC、ワークステーション、 サーバ、プリンタ、ルータなど)が含まれていることを確認する必要がある。 ネットワークの実際のレイアウトを示すために、各サブネットワークごとに同 じ行を複写することは避け、必ず有効なネットワーク番号および関連のネット ワークマスクを指定されたい。各サブネットについてIPアドレスをどのように 運用するかについては、できるだけ具体的に記入されたい。 注: CUST-NETWORK(上記を参照)により記述したアドレス数と、INFRASTRUCTUREに より記述したアドレス数の合計が、貴組織のネットワークですでに利用されて いるアドレス空間の合計量とみなされるCUST-NETWORKとINFRASTRUCTUREのどち らにも記述されていないアドレス空間は、未使用のものとみなされる。 例: infrastructure: 202.12.28.0 255.255.255.192 YES 62 12/24/48 servers infrastructure: 202.12.28.64 255.255.255.192 PART 62 30/40/50 dialup ports infrastructure: 202.12.28.128 255.255.255.128 NO 126 60/100/110 admin NETWORK-PLAN: このフィールドには、APNICから割り振られたアドレス空間を以後12ヶ月間に どのように使用するかを記入する。NETWORK-PLANフィールドの形式は次のとお りである。 network-plan: address mask connect max hinit/h6mo/h1yr 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 - 初期時点で予定されているか、または現在インストールされているデバイス数。 h6mo - 6ヶ月後に予定されているデバイス数。 h1yr - 1年後に予定されているデバイス数。 remark - ネットワークに関する注釈。 NETWORK-PLANフィールドは必要に応じいくつでも使用して、将来のネットワー ク計画をできるだけ正確に記入する。NETWORK-PLANフィールドは、内部インフ ラストラクチャ用の追加のアドレス空間の必要性(上記のINFRASTRUCTUREフィー ルドで指定した量を超えて必要な量)、およびカスタマネットワーク用の追加 のアドレス空間の必要性を記入するためのものである。内部インフラストラク チャ用のデバイスの見積り数には、グローバルに固有な IP番号を必要とする すべてのデバイス(PC、ワークステーション、サーバ、プリンタ、ルータなど) が含まれていることを確認する必要がある。ネットワークの実際のレイアウト を示すために、各サブネットワークごとに同じ行を複写することは避け、必ず 有効なネットワーク番号および関連のネットワークマスクを指定されたい。 カスタマネットワークについては、貴組織に割り当てられたアドレス空間の一 部(場合によっては全部)が、カスタマへの割り当て用としてプールされること が予期される。したがって、アドレスがカスタマに割り当てられることを指定 する必要はない。 注: NETWORK-PLANフィールドは、この要求に対してどれだけのアドレス空間を割 り振るべきかを判断する根拠の1つとなる。アドレス空間をどのように使用す るかを正確に記述することが、誤解を避けるための重要な要素である。 例: network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc EXPLANTION WHY YOU CANNOT OBTAIN ADDRESSES FROM YOUR SERVICE PROVIDER: サービスプロバイダからアドレスを取得できない理由を詳しく記入する。この 説明がない場合は、申請書は受理されずに返却される。APNICは、すべての組 織に対し、極力インターネットサービスプロバイダからアドレスを取得するよ う強く奨励する。詳細については、「補足注意事項」を参照されたい。 ADDITIONAL COMMENTS: このセクションには、申請の正当性を主張するために役立つと思われるその他 の任意の詳細情報を記入できる。特に、ネットワークトポロジーを表す図表や、 アドレス空間利用およびサブネット計画の根拠を示す詳しい説明があれば、 APNICにおいて何らかの疑問点が生じたとしても、貴組織のネットワークに関 する必要条件を理解しやすくなるため、それだけ早期に要求が処理されること になる。 5. ISP IP Address Request Formに関する補足注意事項 ----------------------------------------------- この書式は、APNICが貴組織の要求を審査するために必要な情報を記入するた めのものである。特に、ISP TECHNICAL TEMPLATEの情報は、貴組織がこれまで アドレス空間をどのように利用し、今後どのように利用することを計画してい るかを、 APNICが理解するための基礎となる。ISP TECHNICAL TEMPLATEには次 の情報を含める必要がある。 - インターネットへの接続方法(CONNNECTIVITYおよびCONN-PROVIDER) - ネットワークのルーティング特性(ALL-0S-SUBNETS、ALL-1S-SUBNETS、 SUPERNETS、SUBNETS、PORTABLE) - 既に割り当てられているアドレス空間のこれまでの利用状況 (CUST-NETWORK、INFRASTRUCTURE) - 新規に割り振られるアドレス空間の今後の利用計画(NETWORK-PLAN) ただし、ここで提供された情報は、審査プロセスの出発点にすぎないという点 に注意する必要がある。APNICは、貴組織におけるこれまでのネットワークの 運用状況および今度の運用計画について、さらに詳しい情報を要求することが ある。"ADDITIONAL COMMENTS"に詳細な情報が提供されていれば、APNICが貴組 織の要件を理解しやすくなり、したがって割り振りプロセスも早期に進捗する。 5.1 プロバイダベースのアドレス体系 インターネットが現在の速度で成長を続けるためには、インターネットアドレ スを階層的に割り振ることが必要である。そうすることで、アドレス体系情報 を隠すことが可能になり、グローバルに周知する必要がなくなる(階層的アド レス体系の一例として電話システムがある。イタリアの電話交換台は、日本の 特定の電話番号に到達する方法を知っているわけではなく、交換台に直接接続 していない番号に到達するための交換局に達する方法を知っているだけである。 交換局は、他国の交換局の所在場所等を知っている国際幹線システムに到達す る方法を知っている。) 階層的アドレス体系を実装するには、ネットワークのトポロジーに対応するよ うな形でアドレスを割り当てる必要がある。インターネットにおいては、イン ターネットサービスプロバイダがネットワークトポロジーを定義するので、イ ンターネットが将来拡大するとすれば、そのアドレスはインターネットサービ スプロバイダが割り当てる必要がある。このようにすれば、グローバルルーティ ングシステムは、個々のインターネットサービスに到達する方法だけ知ってい ればよいことになる。 現在、グローバルルーティングシステムが公示しているネットワーク数は 50,000を超えている。このレベルで、インターネットはすでに破綻の危機に 瀕している。この破綻の徴候として、ルータのメモリ不足現象が発生している (その結果、ルータでは、クラッシュ、リブート、復帰、再度メモリ不足、ク ラッシュの繰り返しが発生する)。あるいは、これら50,000個のネットワーク とそのサイトのそれぞれに到達する方法を計算するために、CPUの能力の限界 を超えることもある(ネットワークがダウンしたり復帰したりするたびに、そ のネットワーク上のすべてのサイトに到達する方法の再計算が必要になる。こ れに、上記で述べたメモリの問題が加わって事態は一層深刻になる。)これら の問題は、最終的にはインターネットの該当部分が到達不能になるという状況 をもたらす。 サービスプロバイダブロック以外のブロックから割り振られたアドレスを使用 するサイトが1つインターネットに加わった場合、それはそのサイトをグロー バルルーティングテーブルに追加しなければならないことを意味する。現在、 一部のISP(特に米国内の大規模な通過プロバイダ)の間では、各自のカスタマ を保護し、各自のネットワークの機能性を確保することを目的として(多くの サイトはインターネット自体には関心がなく、支社との連絡用などにインター ネットを仮想プライベートネットワークとして利用することが多いため)、ブ ロック外のネットワーク公示を無視する動きが広がってきている。一般に、貴 組織およびそのカスタマのアドレスブロックでアドレス指定できるホスト数が 少ないほど、無視される可能性も強くなる。ネットワーク無視は全世界の随所 で随時発生する恐れがあり、その結果、貴g織を無視するネットワーク上のど こにも到達できなくなる(そして、その種のネットワークから貴組織への到達 もできなくなる)という点に注意する必要がある。 このルーティングシステムのオーバーフローの問題を打破するために、各レジ ストリは、アドレス空間を要求するサイトに対し、サービスプロバイダからア ドレス空間を取得するよう強く勧奨している。一般にサービスプロバイダブロッ クは規模が大きいので、他のプロバイダから無視されることはない。カスタマ は、サービスプロバイダを変更したときは、各自にマシンを新規のサービスプ ロバイダのアドレス空間にリナンバするのが妥当である。さもないと、旧アド レスはグローバルルーティングテーブルに到達することが必要になる。リナン バが必ずしも簡単な作業ではないことは確かだが、最近のTCP/IPの実装は、 DHCPまたはBOOTPなどの動的IPアドレス割り当てテクノロジーをサポートして いるか、またはこれらのテクノロジーに付随している。これらのテクノロジー では、一般にカスタマが変更する必要があるのは、動的IPアドレスサーバ、 DNS、およびルータだけなので、ホストのリナンバに関連した作業は大幅に軽 減される。リナンバおよびリナンバテクノロジーの詳細については、IETFの PIER (Procedures for Internet/Enterprise Renumbering) Working Groupの アーカイブを参照されたい。そのためのサーチエンジンにアクセスするには、 下記のURLを参照されたい。 http://www.rfc-editor.org/rfc.html このURLで"Renumbering"をサーチすればよい。これにより、この作業グループ が作成したいくつかのrfcドキュメントを読むことができる。 ほとんどのインターネットユーザの関心の的は、インターネットの機能が継続 的に確保され、可能な限り多くの場所にアクセスできることにあるので、レジ ストリは、サイト(ISPと非ISPの両方を含む)に対し、サービスプロバイダから アドレスを取得すること、そして、サービスプロバイダを変更するときはそれ らのアドレスを返還することを、強く勧奨している。レジストリからアドレス 空間を割り振られた場合、割り振られたプレフィックスのサイズに関係なく、 そのアドレス空間がインターネット上でルーティングされる保証はまったくな いということを、最大限に強調する必要がある。 さらに、APNICは、ISPに対しては、ISPの標準接続契約書の中に、加入者が接 続契約の終了時にアドレスをISPに返還することを義務付ける条項を盛り込む よう強く勧奨する。この条項がない場合は、APNICは、カスタマに割り当てら れたアドレス空間がカスタマの自由裁量に任されている、つまり、カスタマが プロバイダを変更するときにアドレス空間をそのまま保有できるものとみなす。 このような行為はグローバルルーティングテーブルに打撃を与えることになる ので、回避すべきである。 このような手順を踏むことにより、インターネットは現在の成長速度を維持し ながら、カスタマが期待するグローバル接続を引き続き提供することができる。 5.2 APNICの割り振り手続き サービスプロバイダからの初めての申請に対しては、APNICは、そのサービス プロバイダの内部インフラストラクチャおよび初期のカスタマ用として使用す るブロックを割り振る。通常、APNICは、ISPからの初めての申請があった時点 で、そのISPのホスト要件が/19を必要としているかどうかに関係なく、/19を1 つ割り振る。そのISPのインフラストラクチャを維持するのに1つの/19だけで は不十分な場合は、APNICは、そのISPの実装に関する詳細な計画の提出を求め る。ただし、正当性を実証する十分な根拠が提示された場合は、まれにではあ るが例外を認めることがある。ISPが初期割り振りを使い果たした場合は、必 要に応じて追加の空間を取得できるが、その空間は同じ連続するブロックとは 限らない。 ネットワークに関する問題の診断と解決を支援するために、APNICはインター ネットにAPNIC登録データベースを提供している。このデータベースが有益で あるためには、常に最新の状態に維持する必要がある。したがって、ISPは、 カスタマにネットワークアドレスを割り当てるたびに、下記に定義されている 手続きによりAPNICデータベースを更新しなければならない。 ftp://ftp.apnic.net/apnic/docs/database-update-info この更新は、カスタマへのアドレスを割り当てた後で可及的速やかに行うもの とする。ISPのカスタマイズに関する最新の登録情報を提供するほかに、APNIC は、このデータベースおよびデータベース更新率を、ISPの成長率を計る手段 として使用する。割り当てを行ったときにISPがデータベースを更新しないと、 APNICは、ISPの成長率を判断する手段が得られないことになる。 ISPは、APNICが最初に割り振った空間の80%を消費した時点で、再度 Internet Service Provider IP Address Request Form(本書式)を提出して、追加の空 間を要求するのが妥当である。さらに、ISPが保有する使用可能な空間を超え る空間を単一のカスタマが消費することが予定されている場合も、ISPは追加 空間を要求する必要がある (ISPは、そのようなカスタマをAPNICに転送しては ならない。その場合は、 APNICはそのカスタマをISPに送還するだけである)。 新たな申請を行う際には、ISPは、CUST-NETWORKフィールドに記入してあるこ と、および、その内容がISPが受理したカスタマ要求を正確に反映しているこ とを確認する必要がある。APNICは、CUST-NETWORKフィールドに記入されてい る情報とAPNICデータベース内の情報を検討し、追加の空間を割り振る。新た な割り振りのサイズは、カスタマに割り当てているアドレス空間の利用度、お よびAPNIC登録データベース更新の適時性および正確さの程度によって決まる。 申請書により提示された情報およびAPNIC登録データベースが所定の条件を満 たしていれば、APNICは、通常現行の割り振りの2倍の追加空間を割り振る。最 終的な目標は、3〜6ヶ月の期間カスタマの要求を満たすに十分なだけのアドレ ス空間を、ISPに提供することにある。したがって、実際に割り振られるアド レス空間の量は、ISPの消費率に基づいて動的に決定される。 この割り振り方式では、必ずしも要求および割り振りの業務が最も効率的な形 では推進されず、たとえば、最初はISPがきわめて頻繁にAPNICに接触しなけれ ばならないなどの欠点もあるが、逆に、アドレス空間の浪費を比較的少なく抑 えながら、ISPが最終的に妥当なアドレス自足のレベルに到達できるような手 段を提供するという利点がある。 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 Center 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 上記の('<'と'>'は不要)は4文字以内とする。データベースソフト ウェアはこれらの頭文字を使用してハンドルを作成する。たとえば次のように する。 person: David Conrad address: Asia Pacific Network Information Center 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)を参照として使用することができる。その場合は、デー タベースソフトウェアは、新たに割り当てられた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: An example of a completed ISP application form descr: Please don't send this verbatim to 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 Center 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 Center 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 #[ISP TECHNICAL TEMPLATE V:3.0]# acct-name:APNIC-AP connectivity: PEERING-POINT conn-provider: MAE-West all-0s-subnets: YES all-1s-subnets: YES supernets:YES subnets: YES portable: NO cust-network: FOO-AP 202.12.28.0 255.255.255.128 10/45/110 1/1/2 19960301 cust-network: BAR-AP 202.12.28.128 255.255.255.128 60/70/100 2/3/4 19960315 infrastructure: 202.12.29.0 255.255.255.192 YES 62 12/24/48 servers infrastructure: 202.12.29.64 255.255.255.192 PART 62 30/40/50 dialup ports infrastructure: 202.12.29.128 255.255.255.128 NO 126 60/100/110 admin network-plan: 0.0.0.0 255.255.255.240 YES 14 1/5/11 support group network-plan: 0.0.0.16 255.255.255.240 YES 14 4/8/8 customer svc network-plan: 0.0.0.32 255.255.255.240 YES 14 10/10/10 int. dial up network-plan: 0.0.0.48 255.255.255.240 NO 14 2/10/12 admin network-plan: 0.0.0.64 255.255.255.224 YES 30 10/20/30 servers network-plan: 0.0.0.96 255.255.255.252 YES 2 2/2/2 branch x -> HQ network-plan: 0.0.0.100 255.255.255.252 YES 2 2/2/2 branch y -> HQ network-plan: 0.0.0.104 255.255.255.252 YES 2 2/2/2 branch z -> HQ network-plan: 0.0.0.108 255.255.255.252 YES 2 2/2/2 R&D -> HQ network-plan: 0.0.0.112 255.255.255.252 YES 2 2/2/2 emp. a -> HQ network-plan: 0.0.0.116 255.255.255.252 YES 2 2/2/2 emp. b -> HQ network-plan: 0.0.0.120 255.255.255.252 YES 2 2/2/2 emp. c -> HQ network-plan: 0.0.0.124 255.255.255.252 YES 2 2/2/2 emp. d -> HQ network-plan: 0.0.0.128 255.255.255.128 YES 126 1/64/126 Blech City POP network-plan: 0.0.1.0 255.255.255.0 YES 254 0/128/254 Blahville POP #[TEMPLATES END]# Explanation why you cannot obtain addresses from your service provider: We will be multi-homed as we are connecting to a connection point, peering with a variety of service providers and defaulting to none. Additional Comments: The following is the EXAMPLE network topology. --- +-----+ +----------+ / \ | DNS |--------+-------| Router 1 |-----+ F |---> Terminal Server +-----+ | +----------+ | D | | | | D |---> Router +----------+ | | | I | | 10 port | | V | |---> Router | Internal |---+ (ISDN Backup) | D | | Terminal | | | M |---> Router | Server | | +----------+ | Z | +----------+ |-------| Router 2 |-----+ | | +----------+ \ / +------+ | | --- | FS 1 |-------+ | +------+ | V +------+ | (OC48 to connection point) | FS 2 |-------+ +------+ | | +---------+--------+--------+ | | | | +------+ +------+ +------+ +------+ | WS 1 | | WS 2 | | WS 3 | | WS 4 | +------+ +------+ +------+ +------+ We will be using BFR routers running BGP-4 to peer with service providers at the MAE-West connection point. We will also be using OSPF to manage our internal infrastructure and static routing to our customers where possible. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 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 end-user-address-request APNIC Staff, "End User Internet Address Request Form", 7/25/98 URL: ftp://ftp.apnic.net/apnic/docs/end-user-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 のスタッフが作成した文書からとったものである。