RFC1930 日本語訳

Network Working Group                                       J. Hawkinson
Request for Comments: 1930                                    BBN Planet
BCP: 6                                                          T. Bates
Category: Best Current Practice                                      MCI
                                                              March 1996

Hawkinsonがコメントのために要求するワーキンググループJ.をネットワークでつないでください: 1930BBN惑星BCP: 6T.ベイツカテゴリ: 1996年の最も良い現在の練習MCI行進

          Guidelines for creation, selection, and registration
                      of an Autonomous System (AS)

Autonomous Systemの創造、選択、および登録のためのガイドライン(AS)

Status of this Memo

このMemoの状態

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

このドキュメントはインターネット共同体、要求議論、および提案のためのインターネットBest Current Practicesを改良に指定します。 このメモの分配は無制限です。

Abstract

要約

   This memo discusses when it is appropriate to register and utilize an
   Autonomous System (AS), and lists criteria for such.  ASes are the
   unit of routing policy in the modern world of exterior routing, and
   are specifically applicable to protocols like EGP (Exterior Gateway
   Protocol, now at historical status; see [EGP]), BGP (Border Gateway
   Protocol, the current de facto standard for inter-AS routing; see
   [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
   Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
   It should be noted that the IDRP equivalent of an AS is the RDI, or
   Routing Domain Identifier.

このメモは、Autonomous System(AS)を登録して、利用するのがいつ適切であるかと議論して、そのようなものの評価基準を記載します。 ASesは外のルーティングの現代の世界のルーティング方針のユニットであり、明確にEGP(現在、歴史的な状態の外のゲートウェイプロトコル; [EGP]を見る)、BGP(ゲートウェイプロトコルに接してください、相互ASルーティングのための現在のデファクトスタンダード; [BGP-4]を見る)、およびIDRPのようなプロトコルに適切です(OSI Inter-ドメインルート設定プロトコル; [IDRP]を見てください)。BGPが時代遅れになるとき、インターネットは採用するとプロトコルに予想されます。 ASのIDRP同等物がRDI、またはルート設定Domain Identifierであることに注意されるべきです。

Table of Contents

目次

   1. Introduction ............................................    2
   2. Motivation ..............................................    2
   3. Definitions .............................................    2
   4. Common errors in allocating ASes ........................    5
   5. Criteria for the decision -- do I need an AS?  ..........    5
   5.1 Sample Cases ...........................................    6
   5.2 Other Factors ..........................................    7
   6. Speculation .............................................    7
   7. One prefix, one origin AS ...............................    8
   8. IGP issues ..............................................    8
   9. AS Space exhaustion .....................................    8
   10. Reserved AS Numbers ....................................    9
   11. Security Considerations ................................    9
   12. Acknowledgments ........................................    9
   13. References .............................................    9
   14. Authors' Addresses .....................................   10

1. 序論… 2 2. 動機… 2 3. 定義… 2 4. ASesを割り当てることにおける一般的な誤り… 5 5. 決定の評価基準--私はASを必要としますか? .......... 5 5.1 ケースを抽出してください… 6 5.2 他の要素… 7 6. 思惑… 7 7. 1つの接頭語、1つの起源のAS… 8 8. IGP問題… 8 9. AS Space疲労困憊… 8 10. 数として、予約されます… 9 11. セキュリティ問題… 9 12. 承認… 9 13. 参照… 9 14. 作者のアドレス… 10

Hawkinson & Bates        Best Current Practice                  [Page 1]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[1ページ]RFC1930Guidelines

1. Introduction

1. 序論

   This memo discusses when it is appropriate to register and utilize an
   Autonomous System (AS), and lists criteria for such.  ASes are the
   unit of routing policy in the modern world of exterior routing, and
   are specifically applicable to protocols like EGP (Exterior Gateway
   Protocol, now at historical status; see [EGP]), BGP (Border Gateway
   Protocol, the current de facto standard for inter-AS routing; see
   [BGP-4]), and IDRP (The OSI Inter-Domain Routing Protocol, which the
   Internet is expected to adopt when BGP becomes obsolete; see [IDRP]).
   It should be noted that the IDRP equivalent of an AS is the RDI, or
   Routing Domain Identifier.

このメモは、Autonomous System(AS)を登録して、利用するのがいつ適切であるかと議論して、そのようなものの評価基準を記載します。 ASesは外のルーティングの現代の世界のルーティング方針のユニットであり、明確にEGP(現在、歴史的な状態の外のゲートウェイプロトコル; [EGP]を見る)、BGP(ゲートウェイプロトコルに接してください、相互ASルーティングのための現在のデファクトスタンダード; [BGP-4]を見る)、およびIDRPのようなプロトコルに適切です(OSI Inter-ドメインルート設定プロトコル; [IDRP]を見てください)。BGPが時代遅れになるとき、インターネットは採用するとプロトコルに予想されます。 ASのIDRP同等物がRDI、またはルート設定Domain Identifierであることに注意されるべきです。

2. Motivation

2. 動機

   This memo is aimed at network operators and service providers who
   need to understand under what circumstances they should make use of
   an AS.  It is expected that the reader is familiar with routing
   protocols and will be someone who configures and operates Internet
   networks.  Unfortunately, there is a great deal of confusion in how
   ASes should be used today; this memo attempts to clear up some of
   this confusion, as well as acting as a simple guide to today's
   exterior routing.

このメモはそれらがどんな状況でASを利用するべきであるかを理解する必要があるネットワーク・オペレータとサービスプロバイダーを対象にします。 読者がルーティング・プロトコルに詳しく、インターネット網を構成して、経営するだれかになると予想されます。 残念ながら、ASesが今日どう使用されるべきであるかの大きな混乱があります。 このメモは、簡単なガイドとして今日の外のルーティングに務めることと同様にこの何らかの混乱を解決するのを試みます。

3. Definitions

3. 定義

   This document refers to the term "prefix" throughout. In the current
   classless Internet (see [CIDR]), a block of class A, B, or C networks
   may be referred to by merely a prefix and a mask, so long as such a
   block of networks begins and ends on a power-of-two boundary. For
   example, the networks:

このドキュメントはあらゆる点で「接頭語」という用語を参照します。 現在の階級のないインターネット([CIDR]を見る)では、1ブロックのクラスA、B、またはCネットワークが単に接頭語とマスクによって示されるかもしれません、1ブロックのそのようなネットワークが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/24 192.168.1.0/24 192.168.2.0/24 192.168.3.0/24

   can be simply referred to as:

単に以下に言及できます。

        192.168.0.0/22

192.168.0.0/22

   The term "prefix" as it is used here is equivalent to "CIDR block",
   and in simple terms may be thought of as a group of one or more
   networks. We use the term "network" to mean classful network, or "A,
   B, C network".

それがここで使用されているので、「接頭語」という用語は、「CIDRブロック」に同等であり、1つ以上のネットワークのグループとして簡単に言えば考えられるかもしれません。 私たちは、ネットワーク、または「A、B、Cネットワーク」をclassfulすることを意味するのに「ネットワーク」という用語を使用します。

   The definition of AS has been unclear and ambiguous for some time.
   [BGP-4] states:

ASの定義は、しばらく不明瞭であって、あいまいです。 [BGP-4]州:

Hawkinson & Bates        Best Current Practice                  [Page 2]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[2ページ]RFC1930Guidelines

      The classic definition of an Autonomous System is a set of routers
      under a single technical administration, using an interior gateway
      protocol and common metrics to route packets within the AS, and
      using an exterior gateway protocol to route packets to other ASes.
      Since this classic definition was developed, it has become common
      for a single AS to use several interior gateway protocols and
      sometimes several sets of metrics within an AS.  The use of the
      term Autonomous System here stresses the fact that, even when
      multiple IGPs and metrics are used, the administration of an AS
      appears to other ASes to have a single coherent interior routing
      plan and presents a consistent picture of what networks are
      reachable through it.

Autonomous Systemの古典的な定義はただ一つの技術的な管理の下で、1セットのルータです、ASの中でパケットを発送するのに内部のゲートウェイプロトコルと一般的な測定基準を使用して、他のASesにパケットを発送するのに外のゲートウェイプロトコルを使用して。 この古典的な定義が開発されて以来、独身のASがASの中でいくつかの内部のゲートウェイプロトコルと時々数セットの測定基準を使用するのは一般的になっています。 ここでのAutonomous Systemという用語の使用は、ただ一つの論理的な内部のルーティングプランを持つために、複数のIGPsと測定基準が使用されてさえいるとき、ASの管理が他のASesにおいて現れるという事実を強調して、どんなネットワークがそれを通して届いているかに関する一貫した絵を提示します。

   To rephrase succinctly:

簡潔に言い直すために:

      An AS is a connected group of one or more IP prefixes run by one
      or more network operators which has a SINGLE and CLEARLY DEFINED
      routing policy.

ASは1人の接続グループですより多くのIP接頭語が1時までに走るか、または以上が、方針を発送しながら、オペレータのどれにSINGLEがあるか、そして、CLEARLY DEFINEDをネットワークでつなぎます。

   Routing policy here is defined as how routing decisions are made in
   the Internet today.  It is the exchange of routing information
   between ASes that is subject to routing policies. Consider the case
   of two ASes, X and Y exchanging routing information:

ここのルート設定方針は今日インターネットでどうルーティング決定をするかと定義されます。 それはルーティング方針を受けることがあるASesの間のルーティング情報の交換です。 ルーティング情報を交換して、2ASes、X、およびYに関するケースを考えてください:

                NET1 ......  ASX  <--->  ASY  ....... NET2

NET1… ASX<。--->ASY… NET2

   ASX knows how to reach a prefix called NET1.  It does not matter
   whether NET1 belongs to ASX or to some other AS which exchanges
   routing information with ASX, either directly or indirectly; we just
   assume that ASX knows how to direct packets towards NET1.  Likewise
   ASY knows how to reach NET2.

ASXはNET1と呼ばれる接頭語に達する方法を知っています。 NET1がASX、または、ルーティング情報をASXと交換するある他のASに属するかどうかは直接か間接的に重要ではありません。 私たちは、ASXがNET1にパケットを向ける方法を知っているとただ思います。 同様にASYはNET2に達する方法を知っています。

   In order for traffic from NET2 to NET1 to flow between ASX and ASY,
   ASX has to announce NET1 to ASY using an exterior routing protocol;
   this means that ASX is willing to accept traffic directed to NET1
   from ASY. Policy comes into play when ASX decides to announce NET1 to
   ASY.

NET2からNET1までの交通がASXとASYの間を流れるように、ASXは外のルーティング・プロトコルを使用することでNET1をASYに発表しなければなりません。 これは、ASXが、ASYからNET1に向けられた交通を受け入れても構わないと思っていることを意味します。 ASXが、NET1をASYに発表すると決めると、方針はプレーに入ります。

   For traffic to flow, ASY has to accept this routing information and
   use it.  It is ASY's privilege to either use or disregard the
   information that it receives from ASX about NET1's reachability. ASY
   might decide not to use this information if it does not want to send
   traffic to NET1 at all or if it considers another route more
   appropriate to reach NET1.

ASYは、交通が流れるのに、このルーティング情報を受け入れて、それを使用しなければなりません。 NET1の可到達性に関してASXから受信するという情報を使用するか、または無視するのが、ASYの特権です。 ASYは、全くNET1に交通を送りたがっていないか、または別のルートがNET1に達するのが、より適切であると考えるならこの情報を使用しないと決めるかもしれません。

   In order for traffic in the direction of NET1 to flow between ASX and
   ASY, ASX must announce that route to ASY and ASY must accept it from
   ASX:

NET1の向きに交通がASXとASYの間を流れるように、ASXはそのルートをASYに発表しなければなりません、そして、ASYはASXからそれを受け入れなければなりません:

Hawkinson & Bates        Best Current Practice                  [Page 3]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[3ページ]RFC1930Guidelines

                    resulting packet flow towards NET1
                  <<===================================
                                    |
                                    |
                     announce NET1  |  accept NET1
                    --------------> + ------------->
                                    |
                        AS X        |    AS Y
                                    |
                     <------------- + <--------------
                       accept NET2  |  announce NET2
                                    |
                                    |
                   resulting packet flow towards NET2
                   ===================================>>

NET1<<に向かった結果として起こるパケット流動=================================== | | NET1を発表してください。| NET1を受け入れてください。-------------->+------------->| Xとして| Yとして| <、-、-、-、-、-、-、-、-、-、-、-、-- + <。-------------- NET2を受け入れてください。| NET2を発表してください。| | NET2に向かった結果として起こるパケット流動===================================>>。

   Ideally, though seldom practically, the announcement and acceptance
   policies of ASX and ASY are symmetrical.

ASXとASYの発表と承認方針はめったに理想的に実際に対称がではありませんが。

   In order for traffic towards NET2 to flow, announcement and
   acceptance of NET2 must be in place (mirror image of NET1). For
   almost all applications connectivity in just one direction is not
   useful at all.

NET2に向かった交通が流れるように、NET2の発表と承認は適所(NET1の鏡像)にあるに違いありません。 ほとんどすべてのアプリケーションには、まさしく一方向への接続性は全く役に立ちません。

   It should be noted that, in more complex topologies than this
   example, traffic from NET1 to NET2 may not necessarily take the same
   path as traffic from NET2 to NET1; this is called asymmetrical
   routing.  Asymmetrical routing is not inherently bad, but can often
   cause performance problems for higher level protocols, such as TCP,
   and should be used with caution and only when necessary. However,
   assymetric routing may be a requirement for mobile hosts and
   inherently asymmetric siutation, such a satelite download and a modem
   upload connection.

NET1からNET2までの交通が必ずこの例より複雑なtopologiesでNET2からNET1までの交通と同じ経路を取るかもしれないというわけではないことに注意されるべきです。 これは非対称的なルーティングと呼ばれます。 非対称的なルーティングは本来悪くはありません、TCPなどの、より高い平らなプロトコルのためにしばしば性能問題を引き起こす場合があって、慎重に使用されるべきであり、必要であるときにだけ。 しかしながら、assymetricルーティングは本来のモバイルホスト、非対称のsiutation、そのようなsateliteダウンロード、およびモデムアップロード接続のための要件であるかもしれません。

   Policies are not configured for each prefix separately but for groups
   of prefixes.  These groups of prefixes are ASes.

接頭語のグループがなければ、方針は各接頭語のために別々に構成されません。 接頭語のこれらのグループはASesです。

   An AS has a globally unique number (sometimes referred to as an ASN,
   or Autonomous System Number) associated with it; this number is used
   in both the exchange of exterior routing information (between
   neighboring ASes), and as an identifier of the AS itself.

ASには、それに関連しているグローバルにユニークな数(時々ASN、またはAutonomous System Numberと呼ばれる)があります。 情報(隣接しているASesの間の)を発送して、外部の交換がAS自身に関する識別子として使用されて、この数は両方で使用されます。

   In routing terms, an AS will normally use one or more interior
   gateway protocols (IGPs) when exchanging reachability information
   within its own AS. See "IGP Issues".

それ自身のASの中で可到達性情報を交換するとき、ルーティング用語で、通常、ASは1つ以上の内部のゲートウェイプロトコル(IGPs)を使用するでしょう。 「IGP問題」を見てください。

Hawkinson & Bates        Best Current Practice                  [Page 4]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[4ページ]RFC1930Guidelines

4. Common errors in allocating ASes

4. ASesを割り当てることにおける一般的な誤り

   The term AS is often confused or even misused as a convenient way of
   grouping together a set of prefixes which belong under the same
   administrative umbrella, even if within that group of prefixes there
   are various different routing policies. Without exception, an AS must
   have only one routing policy.

ASという用語は、しばしば混乱するか、または同じ管理かさに属す接頭語のセットを一緒に分類する便利な方法として誤用さえされます、接頭語のそのグループの中に様々な異なったルーティング方針があっても。 例外がなければ、ASには、1つのルーティング方針しかあってはいけません。

   It is essential that careful consideration and coordination be
   applied during the creation of an AS. Using an AS merely for the sake
   of having an AS is to be avoided, as is the worst-case scenario of
   one AS per classful network (the IDEAL situation is to have one
   prefix, containing many longer prefixes, per AS). This may mean that
   some re-engineering may be required in order to apply the criteria
   and guidelines for creation and allocation of an AS that we list
   below; nevertheless, doing so is probably the only way to implement
   the desired routing policy.

熟慮とコーディネートがASの創造の間適用されるのは、不可欠です。 単にASを持つ目的にASを使用するのは避けられることになっています、1classfulあたりのASがネットワークでつなぐ1つの最悪の事態のシナリオのように(IDEAL状況が1つの接頭語を持つことです、多くの、より長い接頭語を含んでいて、AS単位で)。 これは、何らかのリエンジニアリングが私たちが以下に記載するASの創造と配分のための評価基準とガイドラインを適用するのに必要であるかもしれないことを意味するかもしれません。 それにもかかわらず、そうするのは、たぶん必要なルーティング政策を実施する唯一の方法です。

   If you are currently engineering an AS, careful thought should be
   taken to register appropriately sized CIDR blocks with your
   registration authority in order to minimize the number of advertised
   prefixes from your AS.  In the perfect world that number can, and
   should, be as low as one.

あなたが現在ASを設計しているなら、あなたのASから広告を出している接頭語の数を最小にするために適切に大きさで分けられたCIDRブロックをあなたの登録局に登録するために考慮を取るべきです。 理想の世界では、その数は、下位であることができ、1と同じくらい下位であるべきです。

   Some router implementations use an AS number as a form of tagging to
   identify interior as well as exterior routing processes.  This tag
   does not need to be unique unless routing information is indeed
   exchanged with other ASes. See "IGP Issues".

いくつかのルータ実現が、内部の、そして、外のルーティングの過程を特定するのにタグ付けのフォームとしてAS番号を使用します。 ルーティング情報が本当に他のASesと共に交換されない場合、このタグは特有である必要はありません。 「IGP問題」を見てください。

5. Criteria for the decision -- do I need an AS?

5. 決定の評価基準--私はASを必要としますか?

   *    Exchange of external routing information

* 外部のルーティング情報の交換

        An AS must be used for exchanging external routing information
        with other ASes through an exterior routing protocol. The cur-
        rent recommended exterior routing protocol is BGP, the Border
        Gateway Protocol. However, the exchange of external routing
        information alone does not constitute the need for an AS. See
        "Sample Cases" below.

外のルーティング・プロトコルを通して外部のルーティング情報を他のASesと交換するのにASを使用しなければなりません。 外のルーティング・プロトコルが推薦された野良犬使用料はBGP、ボーダ・ゲイトウェイ・プロトコルです。 しかしながら、外部のルーティング情報だけの交換はASの必要性を構成しません。 以下の「サンプルケース」を見てください。

   *    Many prefixes, one AS

* 多くの接頭語、1AS

        As a general rule, one should try to place as many prefixes as
        possible within a given AS, provided all of them conform to the
        same routing policy.

概して、与えられたASの中でできるだけ多くの接頭語を置こうとするべきです、彼らが皆、同じルーティング方針に従うなら。

Hawkinson & Bates        Best Current Practice                  [Page 5]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[5ページ]RFC1930Guidelines

   *    Unique routing policy

* ユニークなルーティング方針

        An AS is only needed when you have a routing policy which is
        different from that of your border gateway peers. Here routing
        policy refers to how the rest of the Internet makes routing
        decisions based on information from your AS. See "Sample
        Cases" below to see exactly when this criteria will apply.

あなたにあなたの境界ゲートウェイ同輩のものと異なったルーティング方針があると、ASが必要であるだけです。 ここに、ルーティング方針はインターネットの残りがルーティングをあなたのASから情報に基づく決定にどうするかに言及します。 以下の「サンプルケース」を見て、ちょうどこれであるときに、評価基準が適用されることを確認してください。

5.1 Sample Cases

5.1 サンプルケース

   *    Single-homed site, single prefix

* シングル家へ帰る、サイト、ただ一つの接頭語

        A separate AS is not needed; the prefix should be placed in an
        AS of the provider. The site's prefix has exactly the same rout-
        ing policy as the other customers of the site's service
        provider, and there is no need to make any distinction in rout-
        ing information.

別々のASは必要ではありません。 接頭語はプロバイダーのASに置かれるべきです。 サイトの接頭語には、まさにサイトのサービスプロバイダーの他の顧客と同じ総崩れするing方針があります、そして、総崩れするingのどんな区別も情報にする必要は全くありません。

        This idea may at first seem slightly alien to some, but it high-
        lights the clear distinction in the use of the AS number as a
        representation of routing policy as opposed to some form of
        administrative use.

この考えは初めにいくつかにわずかに異質に見えるかもしれなくて、唯一のそれはいくつかと対照的にルーティング方針の表現としてのAS番号の使用における明らかな区別が形成する管理使用の高いライトです。

        In some situations, a single site, or piece of a site, may find
        it necessary to have a policy different from that of its
        provider, or the rest of the site. In such an instance, a sepa-
        rate AS must be created for the affected prefixes. This situa-
        tion is rare and should almost never happen. Very few stub sites
        require different routing policies than their parents. Because
        the AS is the unit of policy, however, this sometimes occurs.

いくつかの状況で、ただ一つのサイト、またはサイトの断片によって、プロバイダーのもの、またはサイトの残りと異なった方針を持つのが必要であることがわかるかもしれません。 そのような例では、影響を受ける接頭語のためにsepaレートASを作成しなければなりません。 このsitua- tionはまれであり、ほとんど起こるはずがありません。 ほんのわずかなスタッブサイトは彼らの両親と異なったルーティング方針を必要とします。 ASが方針のユニットであるので、しかしながら、これは時々起こります。

   *    Single-homed site, multiple prefixes

* シングル家へ帰る、サイト、複数の接頭語

        Again, a separate AS is not needed; the prefixes should be
        placed in an AS of the site's provider.

一方、別々のASは必要ではありません。 接頭語はサイトのプロバイダーのASに置かれるべきです。

   *    Multi-homed site

* マルチ、家へ帰り、サイト

        Here multi-homed is taken to mean a prefix or group of prefixes
        which connects to more than one service provider (i.e. more than
        one AS with its own routing policy). It does not mean a network
        multi-homed running an IGP for the purposes of resilience.

ここ、マルチ、家へ帰り、1つ以上のサービスプロバイダー(すなわち、それ自身のルーティング方針がある1AS)に接続する接頭語の接頭語かグループを意味するために、取ります。 ネットワークを意味しない、マルチ、家へ帰り、弾力の目的のためにIGPを走らせます。

        An AS is required; the site's prefixes should be part of a
        single AS, distinct from the ASes of its service providers.
        This allows the customer the ability to have a different repre-
        sentation of policy and preference among the different service
        providers.

ASが必要です。 サイトの接頭語はサービスプロバイダーのASesと異なった独身のASの一部であるべきです。 これは異なったサービスプロバイダーの中に方針と好みの異なったrepre- sentationを持つ能力を顧客に許容します。

Hawkinson & Bates        Best Current Practice                  [Page 6]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[6ページ]RFC1930Guidelines

        This is ALMOST THE ONLY case where a network operator should
        create its own AS number. In this case, the site should ensure
        that it has the necessary facilities to run appropriate routing
        protocols, such as BGP4.

これはネットワーク・オペレータがそれ自身のAS番号を作成するべきであるALMOST THE ONLYそうです。 この場合、サイトは、適切なルーティング・プロトコルを走らせるために必要な施設を持っているのを確実にするべきです、BGP4などのように。

5.2 Other factors

5.2 他の要素

   *    Topology

* トポロジー

        Routing policy decisions such as geography, AUP (Acceptable Use
        Policy) compliance and network topology can influence decisions
        of AS creation. However, all too often these are done without
        consideration of whether or not an AS is needed in terms of
        adding additional information for routing policy decisions by
        the rest of the Internet. Careful consideration should be taken
        when basing AS creation on these type of criteria.

地理学や、AUP(許容できるUse Policy)コンプライアンスやネットワーク形態などのルート設定政策決定はAS創造の決定に影響を及ぼすことができます。 しかしながら、ASがインターネットの残りでルーティング政策決定のための追加情報を加えることに関して無償で必要であるかどうかについてあまりにも頻繁のこれらをします。 AS創造をこれらのタイプの評価基準に基礎づけるとき、熟慮を取るべきです。

   *    Transition / "future-proofing"

* 変遷/「未来を検査します」。

        Often a site will be connected to a single service provider but
        has plans to connect to another at some point in the future.
        This is not enough of a reason to create an AS before you really
        need it.  The AS number space is finite and the limited amount
        of re-engineering needed when you connect to another service
        provider should be considered as a natural step in transition.

サイトは、しばしば、ただ一つのサービスプロバイダーに関連づけられますが、将来、何らかのポイントに別のものに接続する計画を持ちます。 これはあなたが本当にそれを必要とする前にASを作成する理由に十分ではありません。 AS数のスペースは有限です、そして、あなたが別のサービスプロバイダーに接続すると必要であるリエンジニアリングの数量限定は変遷における生まれながらのステップであるとみなされるべきです。

   *    History

* 歴史

        AS number application forms have historically made no reference
        to routing policy. All too often ASes have been created purely
        because it was seen as "part of the process" of connecting to
        the Internet. The document should be used as a reference from
        future application forms to show clearly when an AS is needed.

AS数の申込み書はルーティング方針について歴史的に言及しました。 それがインターネットに接続するのについて「過程の一部」が見られたので、あまりにも頻繁に、ASesは純粋に作成されました。 ドキュメントは、ASがいつ必要であるかを明確に示すのに将来の申込み書からの参照として使用されるべきです。

6. Speculation

6. 思惑

   1) If provider A and provider B have a large presence in a
   geographical area (or other routing domain), and many customers are
   multi-homed between them, it makes sense for all of those customers
   to be placed within the same AS. However, it is noted that case
   should only be looked at if practical to do so and fully coordinated
   between customers and service providers involved.

1) プロバイダーAとプロバイダーBが地理的な領域(または、他の経路ドメイン)に大きい存在を持つか、そして、多くの顧客がそうである、マルチ、家へ帰り、彼らの間では、すべてのために、同じASの中に置かれるのはそれらの顧客を理解できます。 しかしながら、ケースがそうするために実用的であるなら調べられて、顧客とかかわるサービスプロバイダーの間で完全に調整されるだけであるべきであることに注意されます。

   2) Sites should not be forced to place themselves in a separate AS
   just so that someone else (externally) can make AS-based policy
   decisions. Nevertheless, it may occasionally be necessary to split
   up an AS or a prefix into two ASes for policy reasons. Those making

2) サイトは、ただ他の誰かが(外部的に)ASベースの政策決定をすることができるように、やむを得ず別々のASに自分たちを置くべきではありません。 それにもかかわらず、ASを分けるのが時折必要であるかもしれないか、または方針のための2ASesへの接頭語は推論します。 それらの作成

Hawkinson & Bates        Best Current Practice                  [Page 7]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[7ページ]RFC1930Guidelines

   external policy may request the network operators make such AS
   changes, but the final decision is up to those network operators
   who manage the prefixes in question, as well as the ASes containing
   them. This is, of course, a trade off -- it will not always be
   possible to implement all desired routing policies.

対外政策は、ネットワーク・オペレータがそのようなASを変化にするよう要求するかもしれませんが、最終決定は問題の接頭語を管理するネットワーク・オペレータまで達しています、彼らを含むASesと同様に。 これはもちろん下に取り引きです--いつも、すべての必要なルーティング政策を実施するのは可能であるというわけではないでしょう。

7. One prefix, one origin AS

7. 1つの接頭語、1つの起源のAS

   Generally, a prefix can should belong to only one AS. This is a
   direct consequence of the fact that at each point in the Internet
   there can be exactly one routing policy for traffic destined to each
   prefix. In the case of an prefix which is used in neighbor peering
   between two ASes, a conscious decision should be made as to which AS
   this prefix actually resides in.

一般に、接頭語缶はあるASだけに属すはずです。 これはまさに各接頭語に運命づけられた交通のためのそこのインターネットの各ポイントの1つのルーティング方針であるかもしれない事実の直接の結果です。 2ASesの間をじっと見ている隣人で使用される接頭語の場合では、この接頭語が実際にどのASに関して存するかという意識的な決定をするべきです。

   With the introduction of aggregation it should be noted that a prefix
   may be represented as residing in more than one AS, however, this is
   very much the exception rather than the rule. This happens when
   aggregating using the AS_SET attribute in BGP, wherein the concept of
   origin is lost. In some cases the origin AS is lost altogether if
   there is a less specific aggregate announcement setting the
   ATOMIC_AGGREGATE attribute.

集合の導入で、接頭語が1ASに住んでいるとして表されるかもしれないことに注意されるべきであり、しかしながら、これはたいへん規則よりむしろ例外です。 起源の概念が無くなるBGPでAS_SET属性を使用するのに集めるとき、これは起こります。 いくつかの場合、ATOMIC_AGGREGATEが結果と考えるそれほど特定でない集合発表設定があれば、起源ASは全体でなくされています。

8. IGP Issues

8. IGP問題

   As stated above, many router vendors require an identifier for
   tagging their IGP processes. However, this tag does not need to be
   globally unique. In practice this information is never seen by
   exterior routing protocols. If already running an exterior routing
   protocol, it is perfectly reasonable to use your AS number as an IGP
   tag; if you do not, choosing from the private use range is also
   acceptable (see "Reserved AS Numbers"). Merely running an IGP is not
   grounds for registration of an AS number.

上に述べられているように、多くのルータ業者が彼らのIGPの過程にタグ付けをするための識別子を必要とします。 しかしながら、このタグはグローバルに特有である必要はありません。 実際には、この情報は外のルーティング・プロトコルによって決して見られません。 外のルーティング・プロトコルを既に走らせるなら、IGPタグとしてあなたのAS番号を使用するのは完全に妥当です。 また、あなたがそうしないなら、私用範囲から選ぶのも許容できます(「数として、予約されていた」状態で、見てください)。 IGPを単に走らせるのは、AS番号の登録の根拠ではありません。

   With the advent of BGP4 it becomes necessary to use an IGP that can
   carry classless routes. Examples include OSPF [OSPF] and ISIS [ISIS].

BGP4の到来に従って、階級のないルートを運ぶことができるIGPを使用するのは必要になります。 例はOSPF[OSPF]とイシス[イシス]を含んでいます。

9. AS Space exhaustion

9. AS Space疲労困憊

   The AS number space is a finite amount of address space. It is
   currently defined as a 16 bit integer and hence limited to 65535
   unique AS numbers. At the time of writing some 5,100 ASes have been
   allocated and a little under 600 ASes are actively routed in the
   global Internet. It is clear that this growth needs to be continually
   monitored. However, if the criteria applied above are adhered to,
   then there is no immediate danger of AS space exhaustion. It is
   expected that IDRP will be deployed before this becomes an issue.
   IDRP does not have a fixed limit on the size of an RDI.

AS数のスペースは限られた額のアドレス空間です。 それは、現在、16ビットの整数と定義されて、したがって、65535のユニークなAS番号に制限されます。 これを書いている時点でおよそ5,100ASesを割り当てました、そして、世界的なインターネットで活発に少しの600ASesを発送します。 この成長が、絶えずモニターされる必要があるのは、明確です。 しかしながら、上に適用された評価基準が固く守られるなら、AS宇宙疲労困憊というどんな即座の危険もありません。 これが問題になる前にIDRPが配備されると予想されます。 IDRPはRDIのサイズに固定限界を持っていません。

Hawkinson & Bates        Best Current Practice                  [Page 8]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[8ページ]RFC1930Guidelines

10. Reserved AS Numbers

10. 数として、予約されます。

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following block of AS numbers for private use (not to be advertised
   on the global Internet):

インターネットAssigned民数記Authority(IANA)は私的使用目的で(世界的なインターネットに広告を出さない)AS番号の以下のブロックを予約しました:

                           64512 through 65535

64512〜65535

11. Security Considerations

11. セキュリティ問題

   There are few security concerns regarding the selection of ASes.

ASesの品揃えに関して安全上の配慮がほとんどありません。

   AS number to owner mappings are public knowledge (in WHOIS), and
   attempting to change that would serve only to confuse those people
   attempting to route IP traffic on the Internet.

所有者マッピングへのAS番号は公知(WHOISの)です、そして、それを変えるのを試みるのがインターネットにおけるIP交通を発送するのを試みるそれらの人々を単に混乱させるのに役立つでしょう。

12. Acknowledgments

12. 承認

   This document is largely based on [RIPE-109], and is intended to have
   a wider scope than purely the RIPE community; this document would not
   exist without [RIPE-109].

このドキュメントが[RIPE-109]に主に基づいていて、より広い範囲を持っていることを意図する、純粋にRIPE共同体。 このドキュメントは[RIPE-109]なしで存在していないでしょう。

13. References

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.

[熟している109] ベイツ、T.、主、A.、「自律システム数の申込み書と支持している注意」、熟している109、熟しているNCC、1994年3月1日。 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.

[BGP-4] RekhterとY.とT.李、「ボーダ・ゲイトウェイ・プロトコル4(BGP-4)」、RFC1654、T.J.ワトソン研究所、コクチマスSystems(1994年7月)。

   [EGP]
        Mills, D., "Exterior Gateway Protocol Formal Specifications",
        STD 18, RFC 904, International Telegraph and Telephone Co.,
        April 1984.

[EGP] 工場とD.と「外のゲートウェイプロトコル形式仕様」とSTD18とRFC904と国際電報と電話社、1984年4月。

   [IDRP]
        Kunzinger, C., Editor, "OSI Inter-Domain Routing Protocol
        (IDRP)", ISO/IEC 10747, Work In Progress, October 1993.

[IDRP]Kunzinger(C.、エディタ、「OSI相互ドメインルーティング・プロトコル(IDRP)」ISO/IEC10747)は進歩、1993年10月に働いています。

   [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.

[CIDR] フラー、V.、T.李、J.ユー、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 「Address AssignmentとAggregation Strategy」、RFC1519、BARRnet、コクチマス、MERIT、OARnet、9月1993日

Hawkinson & Bates        Best Current Practice                  [Page 9]

RFC 1930            Guidelines for creation of an AS          March 1996

AS行進1996の創造のためのHawkinsonとベイツBest Current Practice[9ページ]RFC1930Guidelines

   [OSPF]
        Moy, J., "OSPF Version 2", RFC 1583, March 1994.

[OSPF]Moy、J.、「OSPF、バージョン2インチ、RFC1583、1994インチ年3月。

   [ISIS]
        Callon, R., "Use of OSI IS-IS for Routing in TCP/IP and Multi-
        Protocol Environments", RFC 1195, Digital Equipment
        Corporation, December 1990.

[イシス]Callon、R.、「OSIの使用、-、TCP/IPにおけるルート設定とマルチプロトコル環境、」、RFC1195、ディジタルイクイップメント社(1990年12月)

14. Authors' Addresses

14. 作者のアドレス

   John Hawkinson
   BBN Planet Corporation
   150 CambridgePark Drive
   Cambridge, MA 02139

ジョンHawkinson BBN惑星社150のCambridgePark Driveケンブリッジ、MA 02139

   Phone:  +1 617 873 3180
   EMail: jhawk@bbnplanet.com

以下に電話をしてください。 +1 3180年の617 873メール: jhawk@bbnplanet.com

   Tony Bates
   MCI
   2100 Reston Parkway
   Reston, VA 22094

トニーベイツMCI2100レストンParkwayレストン、ヴァージニア 22094

   Phone: +1 703 715 7521
   EMail: Tony.Bates@mci.net

以下に電話をしてください。 +1 7521年の703 715メール: Tony.Bates@mci.net

Hawkinson & Bates        Best Current Practice                 [Page 10]

HawkinsonとベイツBest現在の習慣[10ページ]