この文書はJPNIC公開文書であり、著作権は日本ネットワークインフォ メーションセンター(JPNIC)が保持しています。JPNIC公開文書は誰でも 送付手数料のみの負担でJPNICから入手できます。また、この著作権表示を入れるかぎり、誰でも自由に転載・複製・再配布を行なって構 いません。
〒101-0047 東京都 千代田区 内神田2-3-4 国際興業神田ビル6F
"Guidelines for creation, selection, and registration
of an Autonomous System (AS)(RFC1930)" 翻訳文
（社）日本ネットワークインフォメーションセンター
最終更新 1999年 4月 28日
この文書は
http://www.ietf.org/rfc/rfc1930.txt
を翻訳したものです。JPNICはこの翻訳を参考のために提供しますが、その
品質に責任を負いません。
------------------------------------------------------------------------
Network Working Group J. Hawkinson
Request for Comments: 1930 BBN Planet
BCP: 6 T. Bates
Category: Best Current Practice MCI
March 1996
ASの作成、選択、登録に関するガイドライン
この文書の主旨
本ドキュメントは、インターネットコミュニティのための「現行インターネットにお
ける最善の対策」を提示し、その改善を目的とする論議と提案を求めるものである。
この文書の配布についての制約はまったくない。
要約
この文書では、どのような場合にASの登録と利用を適当と認めるかについて考察し、
これについての基準を提示する。ASは、最近の外部ルーティングの世界におけるルー
ティングポリシーの単位であり、主として、EGP、BGP、IDRPなどのプロトコルに適用
される。EGP( Exterior Gateway Protocol:外部ゲートウェイプロトコル)は過去のプ
ロトコルであり([EGP]を参照)、BGP(Border Gateway Protocol:ボーダーゲートウェ
イプロトコル)は現在のAS間ルーティングにおける事実上の標準であり([BGP-4]を参
照)、IDRP(OSI Inter-Domain Routing Protocol:ドメイン間ルーティングプロトコ
ル)は、BGPが廃止されるときにインターネットで採用されるものと予測されている
([IDRP]を参照)。IDRPにおいて ASに相当するものは、RDI(Routing Domain
Identifier:ルーティングドメインID)であるという点に注意されたい。
目次
1. 序 ...................................................... 2
2. 対象と目的 .............................................. 2
3. 定義 .................................................... 2
4. ASの割り振りにおける一般的な誤り ........................ 5
5. 決定の基準 -- 確かにASが必要か? ......................... 5
5.1 サンプルケース ......................................... 6
5.2 その他の要因 .......................................... 7
6. 考察 .................................................... 7
7. 1つのプレフィックス、1つの起点AS ........................ 8
8. IGPについて ............................................. 8
9. AS空間の枯渇 ............................................ 8
10. リザーブされているAS番号 ............................... 9
11. セキュリティに関する考慮事項 ........................... 9
12. 謝辞 ................................................... 9
13. 参考文献 ............................................... 9
14. 執筆者とその住所 ....................................... 10
Hawkinson & Bates 現時点における最善の対策 [ページ1]
RFC 1930 ASの作成に関するガイドライン 1996年3月
1. 序
この文書では、どのような場合にASの登録と利用と適当と認めるかについて考察し、
これについての基準を提示する。ASは、最近の外部ルーティングの世界におけるルー
ティングポリシーの単位であり、主として、EGP、BGP、IDRPなどのプロトコルに適用
される。EGP( Exterior Gateway Protocol:外部ゲートウェイプロトコル)は過去のプ
ロトコルであり([EGP]を参照)、BGP(Border Gateway Protocol:ボーダーゲートウェ
イプロトコル)は現在のAS間ルーティングにおける事実上の標準であり([BGP-4]を参
照)、IDRP(OSI Inter-Domain Routing Protocol:ドメイン間ルーティングプロトコ
ル)は、BGPが廃止されるときにインターネットで採用されるものと予測されている
([IDRP]を参照)。IDRPにおいて ASに相当するものは、RDI(Routing Domain
Identifier:ルーティングドメインID)であるという点に注意されたい。
2. 対象と目的
この文書は、どのような状況下でASを利用すべきかを理解する必要のあるネットワー
ク運営組織およびサービスプロバイダを対象としている。読者として想定されるの
は、各種ルーティングプロトコルに精通し、インターネットネットワークの構成と運
営に従事する人である。不幸なことに、現時点では、ASをどのように使用すべきかに
ついての見解に大きな混乱が見られる。この文書は、今日の外部ルーティングに関す
る単純なガイドとしての役割を果たすと同時に、この種の混乱をある程度解消するこ
とを目指している。
3. 定義
本ドキュメントの全体にわたり、「プレフィックス」という用語が使われている。現
在のクラスレスインターネット([CIDR]を参照)においては、クラスA、B、またはCの
ネットワークのブロックが、2の累乗に相当する境界で始まりかつ終わっていれば、
そのブロックは単にプレフィックスおよびマスクのみにより参照されることがある。
たとえば次のようなネットワークがあるとする。
192.168.0.0/24
192.168.1.0/24
192.168.2.0/24
192.168.3.0/24
これらのネットワークは、単に次の形式で参照することができる。
192.168.0.0/22
ここで使われている「プレフィックス」という用語は「CIDRブロック」と同義であ
り、簡単に言えば、これは1つまたは複数のネットワークのグループと考えることが
できる。ここで「ネットワーク」というのは、クラスフルネットワーク、つまり
「A、B、Cネットワーク」を意味する。
ASの定義は、これまで不明確かつ不明瞭であった。[BGP-4]では次のように記述され
ている。
Hawkinson & Bates 現時点における最善の対策 [ページ2]
RFC 1930 ASの作成に関するガイドライン 1996年3月
伝統的な定義によれば、AS(Autonomous System)とは、単一の技術的管理の下にある
一組のルータであって、内部ゲートウェイプロトコルおよび共通の重み付けに従って
そのAS内でパケットをルーティングし、外部ゲートウェイプロトコルを使用して他の
ASにパケットをルーティングするものである。この伝統的な定義が作られて以来、単
一のASにおいて複数の内部ゲートウェイプロトコルや時には複数の組み合わせの重み
付けを使用することが一般的になってきた。
。ここで使用するASという用語の語義では、あるASが複数のIGPおよび重み付けを使
用している場合であっても、他のASからは単一の一貫した内部ルーティングプランを
持っているように見え、そのASを介してどのネットワークに到達できるかについての
一貫性のある概念を提示するということに重点が置かれる。
これを要約すれば次のような意味になる。
ASとは、「単一」の「明確に定義された」ルーティングポリシーを持つ1つまたは複
数のネットワーク運営組織が運営する、相互に接続された1つまたは複数のIPプレ
フィックスのグループである。
ここでは、ルーティングポリシーとは、今日のインターネットにおいてルーティング
決定をどのように行うかの定義である。これは、AS相互間でのルーティングポリシー
に従ったルーティング情報の交換を意味する。たとえば、XおよびYという2つのASが
ルーティング情報を交換し合う場合を考えてみよう。
NET1 ...... ASX <---> ASY ....... NET2
ASXは、NET1と呼ばれるプレフィックスに到達する方法を知っている。この場合、
NET1がASXに属しているのか、それともASXと直接的または間接的にルーティング情報
を交換する他のASに属しているのかは関係ない。単に、ASXがNET1パケットを送る方
法を知っているということを想定するだけである。同様に、ASYはNET2に到達する方
法を知っている。
NET2からNET1へのトラフィックがASXとASYの間を流れるためには、ASXは、外部ルー
ティングプロトコルを使用して、NET1をASYに対して広報する必要がある。これは、
ASXが、ASYからNET1に宛てたトラフィックを受け入れる用意があることを意味する。
ASXがASYに対してNET1を広報することを決定した時点で、ポリシーが効力を発揮す
る。
トラフィックが流れるためには、ASYはこのルーティング情報を受け入れて使用する
必要がある。NET1への到達可能性についてASXから受け取った情報を使用するか無視
するかは、ASYの自由である。ASYがこの情報を無視するのは、NET1にトラフィックを
送る必要がまったくない場合や、NET1に到達するには他の経路の方が適切と判断した
場合である。
NET1を宛先とするトラフィックがASXとASYの間を流れるためには、ASXがその経路を
ASYに広報し、ASYがASXからそれを受諾しなければならない。
Hawkinson & Bates 現時点における最善の対策 [ページ3]
RFC 1930 ASの作成に関するガイドライン 1996年3月
NET1を宛先とする結果のパケットフロー
<<===================================
|
|
NET1の広報 | NET1の受諾
--------------> + ------------->
|
AS X | AS Y
|
<------------- + <--------------
NET2の受諾 | NET2の広報
|
|
NET2を宛先とする結果のパケットフロー
===================================>>
実際にはほとんど考えられないが、理論上は、ASXおよびASYの広報ポリシーと受諾ポ
リシーは対称の形になる。
NET2に向かうトラフィックが流れるには、NET2の広報と受諾が行われなければならな
い(これはNET1の鏡像の形をとる)。ほとんどすべてのアプリケーションにとって、1
方向のみの接続ではまったく役に立たない。
この例より複雑なトポロジーでは、NET1からNET2へのトラフィックは、必ずしもNET2
からNET1へのトラフィックと同じ経路をとるわけではないという点に注意する必要が
ある。これは非対称ルーティングと呼ばれている。非対称ルーティング自体は本質的
に欠点があるわけではないが、TCPなどの高レベルプロトコルではしばしばパフォー
マンス上の問題の原因となるので、必要な場合に限り細心の注意を払いながら使用す
ることが重要と言える。しかし、モバイルホストの場合、および、衛星ダウンロード
とモデムアップロード接続のように本質的に非対称の状況の場合は、非対称ルーティ
ングが必要になることがある。
ポリシーは、各プレフィックスごとに別々に構成されるのではなく、プレフィックス
のグループごとに構成される。このプレフィックスのグループがASである。
ASには、世界規模で固有な番号(しばしばASNまたはAS番号と呼ばれる)が付けられ
る。この番号は、外部ルーティング情報の交換(隣接AS相互間の)のため、およびAS自
体の識別子として使用される。
ルーティングの観点から見た場合、ASは、そのASの内部で到達可能性情報を交換する
ときに、通常1つまたは複数の内部ゲートウェイプロトコル(IGP)を使用する。「IGP
について」の項を参照されたい。
Hawkinson & Bates 現時点における最善の対策 [ページ4]
RFC 1930 ASの作成に関するガイドライン 1996年3月
4. ASの割り当てにおける一般的な誤り
ASという用語は、同一の管理の傘下にある一組のプレフィックスをグループ化する簡
便な手段の意味と混同され誤用されることがしばしばあり、そのプレフィックスグ
ループ内にいくつかの異なるルーティングポリシーが存在してもよいと誤解されがち
である。しかし、例外なく、1つのASはただ1つのルーティングポリシーを持つもので
なければならない。
ASの作成に当たってには、入念な検討と調整が必要である。単にASを持つためにASを
使用することは避けなければならない。最悪のケースは、1つのクラスフルネット
ワークにつき1つのASが存在するという状況である(理想的なのは、1つのASにつき、
多数の長いプレフィックスを含む1つのプレフィックスだけが存在するという状況で
ある)。これは、場合によっては、ASの作成と割り振りについて下記に挙げる基準と
ガイドラインを満たすために何らかのリエンジニアリングが必要になることを意味す
る。しかも、そうすることが、必要なルーティングポリシーを実装するための唯一の
手段である場合もある。
現在ASの設計に従事している場合は、そのASから広報するプレフィックスの数を最小
限に抑えるために、登録機関に適切なサイズのCIDRブロックを登録するように、十分
な配慮と検討を加える必要がある。完璧な形としては、プレフィックスの数は1つに
することが可能であり、またそうすべきである。
ルータの実装によっては、外部ルーティングプロセスに加えて、内部ルーティングプ
ロセスを識別するためのタグ付けの一形式としてもAS番号が使用されることがある。
このタグは、ルーティング情報を他のASとの間で実際に交換する場合でない限り、固
有のものである必要はない。「IGPについて」の項を参照されたい。
5. 決定の基準 -- 確かにASが必要か?
* 外部ルーティング情報の交換
外部ルーティングプロトコルを介して他のASとの間で外部ルーティング情報を交換す
るには、ASを使用しなければならない。現時点での推奨される外部ルーティングプロ
トコルは、BGP(Border GatewayProtocol:ボーダーゲートウェイプロトコル)である。
しかし、ASが必要とされる理由は、外部ルーティング情報の交換だけではない。下記
の「サンプルケース」の項を参照されたい。
* 多数のプレフィックスを1つのASに
一般原則としては、同じルーティングポリシーに準拠しているものであれば、できる
だけ多数のプレフィックスを1つのASとしてまとめるのが妥当である。
Hawkinson & Bates 現時点における最善の対策 [ページ5]
RFC 1930 ASの作成に関するガイドライン 1996年3月
* 固有なルーティングポリシー
ASが必要になるのは、自身が、ボーダーゲートウェイピアとは異なるルーティングポ
リシーを持つ場合だけである。ここでルーティングポリシーというのは、自己のASか
らの情報に基づき、インターネットのその他の部分でどのようにルーティング決定が
行われるかを示す。この基準がどのようなときに適用されるかを正確に知るには、下
記の「サンプルケース」の項を参照されたい。
5.1 サンプルケース
* シングルホームシングルホームサイト、単一プレフィックス
この場合は、独立したASは必要ない。このプレフィックスはプロバイダのASに含める
のがよい。このサイトのプレフィックスは、このサイトのサービスプロバイダの他の
カスタマとまったく同じルーティングポリシーを持つので、ルーティング情報を相互
間で区別する必要はない。
この考え方は、一部の人に対しては最初は少々違和感を与えるだろうが、しかし、1
つのルーティングポリシーを標榜するものとしてのAS番号の使用と、何らかの管理を
目的とするASの利用形態との相違を明確に表している。
状況によっては、単一のサイト、またはサイトの一部が、そのサイトのプロバイダ、
またはサイトのその他の部分とは異なるポリシーを持つことが必要になる場合もあ
る。その場合は、該当のプレフィックスのための独立したASを作成しなければならな
い。しかし、このような状況はまれであり、ほとんど発生しないものと考えられる。
部分サイトがそれぞれの親とは異なるルーティングを必要とすることはきわめて少な
い。しかし、ASはポリシーの単位なので、このような状況が発生することもときには
ある。
* シングルホームサイト、複数プレフィックス
この場合も、独立したASは必要ない。このプレフィックスはサイトのプロバイダのAS
に含めるのがよい。
* マルチホームサイト
ここで言うマルチホームとは、複数のサービスプロバイダ(つまり、それぞれ独自の
ルーティングポリシーを持つ複数のAS)に接続する1つまたは1グループのプレフィッ
クスを意味する。弾力性を目的としてIGPを実行するマルチホーム接続のネットワー
クを意味するのではない。
この場合はASが必要である。つまり、このサイトのプレフィックスを、サービスプロ
バイダの他のASから分離して、単独のASに含めるようにする。これにより、カスタマ
は、各種のサービスプロバイダ間で独立したポリシーと優先順位の概念を持つことが
できる。
Hawkinson & Bates 現時点における最善の対策 [ページ6]
RFC 1930 ASの作成に関するガイドライン 1996年3月
これが、ネットワーク運営組織が独自のAS番号を作成すべき「ほとんど唯一」の場合
である。この場合は、サイトは、適切なプロトコル(たとえばBGP4)を実行するために
必要な機能を備えていることを確認する必要がある。
5.2 その他の要因
* トポロジー
ASの作成に対しては、地理、AUP (Acceptable Use Policy)への準拠、およびネット
ワークトポロジーなどの、ルーティングポリシーに関する決定事項が影響を与えるこ
とが考えられる。しかし、ルーティングポリシー決定に関する補足情報を追加すると
いう観点からインターネットの他の部分がそのASを必要としているかどうか、という
点を考慮に入れずにこのような観点に基づいてASの作成が決定される例があまりに多
い。この種の基準に基づいてASを作成するときは、十分な検討を加える必要がある。
* 移行/「将来への備え」
1つのサイトが単一のサービスプロバイダへの接続を予定しているが、将来のどこか
の時点で別のプロバイダに接続することも計画しているという場合がしばしばある。
これは、真に必要になる前にASを作成するという正当な理由にはならない。AS番号空
間には限りがあるので、別のサービスプロバイダに接続するときにある程度のリエン
ジニアリングが必要となるのは、移行における当然の過程の 1つと考えるべきであ
る。
* 歴史
従来、AS番号申請書式ではルーティングポリシーには言及していない。これまでは、
単にインターネットへの接続の「プロセスの一部」とみなされるという理由だけで、
ASが作成された例があまりに多かった。将来の申請書においては、本ドキュメントを
参考にして、どのような場合に ASが必要かを明記することが必要と考えられる。
6. 考察
1) プロバイダAおよびプロバイダBが、1つの地理的空間(または他のルーティングド
メイン)の中で大きな地位を占めており、多数のカスタマが両者の間でマルチホーム
接続している場合は、それらのカスタマのすべてを同じASに含めることには意義があ
ると考えられる。ただし、これを検討するのは、そうすることに実利的な価値がある
と考えられる場合のみとし、その場合は関連のカスタマとサービスプロバイダとの間
で十分に調整を計るべきであることを忘れてはならない。
2) いかなるサイトも、他のいずれかのサイト(外部の)がASベースのポリシー決定を
行えるようにするという目的のために、独立したASへ強制的に組み込まれることが
あってはならない。しかし、場合によっては、ポリシー上の理由により、1つのASま
たはプレフィックスを2つのASに分割しなければならないこともあり得る。
Hawkinson & Bates 現時点における最善の対策 [ページ7]
RFC 1930 ASの作成に関するガイドライン 1996年3月
外部ポリシーを作成する組織は、ネットワーク運営組織に対しこの種のAS変更を行う
よう要求できるが、最終決定を行うのは、問題のプレフィックスを含むAS、およびそ
れらのプレフィックスを管理するネットワーク運営組織である。もちろん、これには
相互背反性があり、望まれているすべてのルーティングポリシーを常に実装できると
は限らない。
7. 1つのプレフィックス、1つの起点AS
原則として、1つのプレフィックスは1つのASのみに所属すべきである。インターネッ
ト内の各ポイントにおいては、特定のプレフィックスを宛先とするトラフィックにつ
いてはただ1つのルーティングポリシーしか存在し得ないという事実を考えれば、こ
れは当然の帰結と言える。あるプレフィックスが、隣接する2つのAS間のピアリング
のために使用される場合は、そのプレフィックスが実際にどちらのASに所属するかに
ついての明確な決定が必要とされる。
アグリゲーションの観点から見れば、プレフィックスは複数のASの所属するものとも
考えることができるが、しかしこれは、原則から逸脱した極端な例外と言うべきであ
ろう。この例外状況が生じるのは、BGP内でAS_SET属性を使用してアグリゲートする
場合、つまり起点の概念が消滅する場合である。ときには、ATOMIC_AGGREGATE属性を
設定する固有性の低いアグリゲートが行なわれる広報がある場合にも、起点ASのの概
念がまったく失われることがある。
8. IGPについて
上記で述べたように、多くのルータベンダは、各自のIGPプロセスにタグ付けするた
めの識別子を必要とする。しかし、このタグは世界規模で固有なものである必要はな
い。事実、外部ルーティングプロトコルによりこの情報が読まれることはない。すで
に外部ルーティングプロトコルを実行している場合は、もちろん自己の AS番号をIGP
タグとして使用するのが、最も妥当な処置である。そうでない場合は、プライベート
使用範囲からタグを選んで使用してもさしつかえない (「リザーブされているAS番
号」を参照）。単にIGPを実行しているだけでは、AS番号を登録する根拠にはならな
い。
BGP4の登場に伴い、クラスレス経路を使用できるIGPの使用が必要になってきてい
る。この種のIGPの例としては、OSPF [OSPF]およびISIS [ISIS]がある。
9. AS空間の枯渇
AS番号空間は有限量のアドレス空間である。AS番号は現在16ビット整数と定義されて
いるので、固有なAS番号の個数は 65535である。本ドキュメント作成の時点では、す
でに約5,100個のASが割り振られており、グローバルインターネットにおいて、600個
弱のASに対するルーティングが実際に行われている。この増加を引き続き監視してい
く必要があることは明らかである。しかし、上記で提言した基準が順守されている限
り、AS空間がただちに枯渇する危険はない。この問題が現実になる前に、IDRPが運用
されるようになると予測される。IDRPには、RDIのサイズに関する固定的な限界はな
い。
Hawkinson & Bates 現時点における最善の対策 [ページ8]
RFC 1930 ASの作成に関するガイドライン 1996年3月
10. リザーブされているAS番号
Internet Assigned Numbers Authority (IANA)は、下記のAS番号のブロックを、プラ
イベート使用(グローバルインターネット上で広報されない)のためのものとしてリ
ザーブしている。
64512～65535
11. セキュリティに関する考慮事項
ASの選択については、セキュリティに関する考慮事項はほとんどない。
AS番号と所有者のマッピングは公開知識であり(WHOISで公開)、この情報を変更しよ
うとしたとしても、インターネット上でIPトラフィックのルーティングを行おうとす
る人々の間に混乱を生じさせるだけである。
12. 謝辞
本ドキュメントは、その大半の部分を[RIPE-109]を基礎として作成したものであり、
その内容を広くRIPEコミュニティ以外にも周知することを意図するものである。
[RIPE-109]なくしては本ドキュメントが世に出ることはなかったであろう。
13. 参考文献
[RIPE-109]
Bates, T., Lord, A., "Autonomous System Number Application Form & Supporting
Notes", RIPE 109, RIPE NCC, 1 March 1994.
URL: ftp://ftp.ripe.net/ripe/docs/ripe-109.txt.
[BGP-4]
Rekhter, Y. and T. Li, "A Border Gateway Protocol 4 (BGP-4)", RFC 1654, T.J.
Watson Research Center, cisco Systems, July 1994.
[EGP]
Mills, D., "Exterior Gateway Protocol Formal Specifications", STD 18, RFC
904, International Telegraph and Telephone Co., April 1984.
[IDRP]
Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol (IDRP)", ISO/IEC
10747, Work In Progress, October 1993.
[CIDR]
Fuller, V., T. Li, J. Yu, and K. Varadhan, "Classless Inter-Domain Routing
(CIDR): an Address Assignment and Aggregation Strategy", RFC 1519, BARRnet,
cisco, MERIT, OARnet, September 1993.
Hawkinson & Bates Best Current Practice [Page 9]
RFC 1930 Guidelines for creation of an AS March 1996
[OSPF]
Moy, J., "OSPF Version 2", RFC 1583, March 1994.
[ISIS]
Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Multi- Protocol
Environments", RFC 1195, Digital Equipment Corporation, December 1990.
14. 執筆者とその住所
John Hawkinson
BBN Planet Corporation
150 CambridgePark Drive
Cambridge, MA 02139
Phone: +1 617 873 3180
EMail: jhawk@bbnplanet.com
Tony Bates
MCI
2100 Reston Parkway
Reston, VA 22094
Phone: +1 703 715 7521
EMail: Tony.Bates@mci.net
Hawkinson & Bates Best Current Practice [Page 10]
