RFC2008 日本語訳

2008 Implications of Various Address Allocation Policies for InternetRouting. Y. Rekhter, T. Li. October 1996. (Format: TXT=34717 bytes) (Also BCP0007) (Status: BEST CURRENT PRACTICE)
プログラムでの自動翻訳です。
RFC一覧
英語原文

Network Working Group                                      Y. Rekhter
Request for Comments: 2008                                      T. Li
BCP: 7                                                  Cisco Systems
Category: Best Current Practice                          October 1996

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 2008T.李BCP: 7シスコシステムズカテゴリ: 最も良い現在の練習1996年10月

              Implications of Various Address Allocation
                     Policies for Internet Routing

インターネットルート設定のための様々なアドレス配分方針の含意

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を改良に指定します。 このメモの分配は無制限です。

IESG Note:

IESGは以下に注意します。

   The addressing constraints described in this document are largely the
   result of the interaction of existing router technology, address
   assignment, and architectural history.  After extensive review and
   discussion, the authors of this document, the IETF working group that
   reviewed it, and the IESG have concluded that there are no other
   currently deployable technologies available to overcome these
   limitations.  In the event that routing or router technology develops
   to the point that adequate routing aggregation can be achieved by
   other means or that routers can deal with larger routing and more
   dynamic tables, it may be appropriate to review these constraints.

本書では説明されたアドレシング規制は主に既存のルータ技術、アドレス課題、および建築の歴史の相互作用の結果です。 大量のレビューと議論の後に、このドキュメントの作者、それを見直したIETFワーキンググループ、およびIESGは、これらの限界を克服するために利用可能な他のどんな現在配備可能な技術もないと結論を下しました。 ルーティングかルータ技術が他の手段で適切なルーティング集合を実現できるか、またはルータが、より大きいルーティングと、よりダイナミックなテーブルに対処できるというポイントに発達する場合、これらの規制を見直すのは適切であるかもしれません。

1 Abstract

1つの要約

   IP unicast address allocation and management are essential
   operational functions for the Public Internet. The exact policies for
   IP unicast address allocation and management continue to be the
   subject of many discussions. Such discussions cannot be pursued in a
   vacuum - the participants must understand the technical issues and
   implications associated with various address allocation and
   management policies.

IPユニキャストアドレス配分と管理はPublicインターネットへの不可欠の操作上の機能です。 IPユニキャストアドレス配分と管理のための正確な方針はずっと多くの議論の対象です。 真空でそのような議論を追求できません--関係者は様々なアドレス配分と管理方針に関連している専門的な問題と含意を理解しなければなりません。

   The purpose of this document is to articulate certain relevant
   fundamental technical issues that must be considered in formulating
   unicast address allocation and management policies for the Public
   Internet, and to provide recommendations with respect to these
   policies.

このドキュメントの目的は、ユニキャストアドレス配分と経営政策をPublicインターネットに定式化する際に考えなければならないある関連基本的な専門的な問題について明確に話して、これらの方針に関して推薦を提供することです。

   The major focus of this document is on two possible policies,
   "address ownership" and "address lending," and the technical
   implications of these policies for the Public Internet.  For the
   organizations that could provide reachability to a sufficiently large

このドキュメントの主要な焦点がPublicインターネットへのこれらの方針の2つの可能な方針、「アドレス所有権」、「アドレスの貸すこと」、および技術的な含意にあります。 可到達性をaに十分大きい状態で提供できた組織のために

Rekhter & Li             Best Current Practice                  [Page 1]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[1ページ]RFC2008 1996年10月

   fraction of the total destinations in the Internet, and could express
   such reachability through a single IP address prefix the document
   suggests to use the "address ownership" policy. However, applying the
   "address ownership" policy to every individual site or organization
   that connects to the Internet results in a non-scalable routing.

インターネットの総目的地の部分、ドキュメントが「アドレス所有権」方針を使用するために示すただ一つのIPアドレス接頭語を通した急行そのような可到達性はそうすることができました。 しかしながら、インターネットに接続するあらゆる個々のサイトか組織に「アドレス所有権」方針を適用すると、非スケーラブルなルーティングはもたらされます。

   Consequently, this document also recomments that the "address
   lending" policy should be formally added to the set of address
   allocation policies in the Public Internet. The document also
   recommends that organizations that do not provide a sufficient degree
   of routing information aggregation, but wish to obtain access to the
   Internet routing services should be strongly encouraged to use this
   policy to gain access to the services.

その結果このドキュメント、セットに追加されて、「アドレスの貸す」方針が正式にそうであるべきであるPublicインターネットのアドレス配分方針の「再-コメント」も。 十分な度のルーティング情報集合を提供しない組織をそれに推薦しますが、また、ドキュメントは、サービスへのアクセスを得るために使用するサービスが強く奨励されるべきであるインターネット・ルーティングへのアクセスを得るという願望にこの方針を推薦します。

2 On the intrinsic value of IP addresses

2 IPアドレスの実態価値に関して

   Syntactically, the set of IPv4 unicast addresses is the (finite) set
   of integers in the range 0x00000000 - 0xDFFFFFFF. IP addresses are
   used for Network Layer (IP) routing. An IP address is the sole piece
   of information about the node injected into the routing system.

シンタクス上、IPv4ユニキャストアドレスのセットは範囲0x00000000の(有限)のセットの整数です--0xDFFFFFFF。 IPアドレスはNetwork Layer(IP)ルーティングに使用されます。 IPアドレスはルーティングシステムに注がれたノードの情報のソール・ピースです。

   The notable semantics of an IP unicast address is its ability to
   interact with the Public Internet routing service and thereby
   exchange data with the remainder of the Internet. In other words, for
   the Public Internet, it is the reachability of an IP address that
   gives it an intrinsic value. Observe, however, that IP addresses are
   used outside of the Public Internet. This document does not cover the
   value of addresses in other than the Public Internet context.

IPユニキャストアドレスの注目に値する意味論はインターネットの残りでPublicインターネット・ルーティングサービスと対話して、その結果交換データと対話するその性能です。 言い換えれば、Publicインターネットに、それは実態価値をそれに与えるIPアドレスの可到達性です。 しかしながら、IPアドレスがPublicインターネットの外で使用されるのを観測してください。 このドキュメントはPublicインターネット文脈以外の中のアドレスの値をカバーしていません。

   The above implies that in the Public Internet it is the service
   environment (the Internet) and its continued operation, including its
   routing system, which gives an IP address its intrinsic value, rather
   than the inverse. Consequently, if the Public Internet routing system
   ceases to be operational, the service disappears, and the addresses
   cease to have any functional value in the Internet. At this point,
   for the Public Internet, all address allocation and management
   policies, including existing policies, are rendered meaningless.

上記は、それがPublicインターネットでは、サービス環境(インターネット)とその継続運転であることを含意します、ルーティングシステム(逆よりむしろ実態価値をIPアドレスに与える)を含んでいて。 その結果、Publicインターネット・ルーティングシステムが、操作上であることをやめるなら、サービスは見えなくなります、そして、アドレスはインターネットにどんな機能値も持っているのをやめます。 ここに、Publicインターネットにおいて、既存の方針を含むすべてのアドレス配分と経営政策が無意味に表されます。

3 Hierarchical routing and its implication on address allocation

3 アドレス配分での階層型ルーティングとその含意

   Hierarchical routing [Kleinrock 77] is a mechanism that improves the
   scaling properties of a routing system. It is the only proven
   mechanism for scaling routing to the current size of the Internet.

階層型ルーティング[クラインロック77]はルーティングシステムのスケーリング特性を改良するメカニズムです。 それは、インターネットの現在のサイズにルーティングについて合わせて調整するための唯一の立証されたメカニズムです。

   Hierarchical routing requires that addresses be assigned to reflect
   the actual network topology. Hierarchical routing works by taking the
   set of addresses covered by a portion of the topology, and generating
   a single routing advertisement (route) for the entire set. Further,

階層型ルーティングは、アドレスが実際のネットワーク形態を反映するために割り当てられるのを必要とします。 階層型ルーティングは、トポロジーの部分でカバーされたアドレスのセットを要して、全体のセットのためにただ一つのルーティング広告(ルート)を作ることによって、利きます。 さらに

Rekhter & Li             Best Current Practice                  [Page 2]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[2ページ]RFC2008 1996年10月

   hierarchical routing allows this to be done recursively: multiple
   advertisements (routes) can be combined into a single advertisement
   (route). By exercising this recursion, the amount of information
   necessary to provide routing can be decreased substantially.

階層型ルーティングで、これは再帰的にします: ただ一つの広告(ルート)に多ページ広告(ルート)を結合できます。 この再帰を運動させることによって、ルーティングを提供するのに必要な情報量はかなり減少できます。

   A common example of hierarchical routing is the phone network, where
   country codes, area codes, exchanges, and finally subscriber lines
   are different levels in the hierarchy. In the phone network, a switch
   need not keep detailed routing information about every possible
   subscriber in a distant area code. Instead, the switch usually knows
   one routing entry for the entire area code.

階層型ルーティングの一般的な例は電話ネットワークです。(そこでは、国名略号、市外局番、交換、および最終的に加入者線が階層構造の異なったレベルです)。 電話ネットワークでは、スイッチは遠方の市外局番ですべての可能な加入者の詳細なルーティング情報を保つ必要はありません。 代わりに、通常、スイッチは全体の市外局番で1つのルーティングエントリーを知っています。

   Notice that the effect on scaling is dramatic. If we look at the
   space complexity of the different schemes, the switch that knows
   about every subscriber in the world needs O(n) space for n worldwide
   subscribers.  Now consider the case of hierarchical routing. We can
   break n down into the number of subscribers in the local area (l),
   the other exchanges in the area code (e), the other area codes in the
   local country code (a) and other country codes (c). Using this
   notation, hierarchical routing has space complexity O(l + e + a + c).
   Notice that each of these factors is much, much less than n, and
   grows very slowly, if at all. This implies that a phone switch can be
   built today that has some hope of not running out of space when it is
   deployed.

スケーリングへの効果が劇的であるのに注意してください。 私たちが異なった計画の空間的コストを見るなら、世界ですべての加入者に関して知っているスイッチはn世界的な加入者にO(n)スペースを必要とします。 今度は、階層型ルーティングに関するケースを考えてください。 私たちは局部(l)の加入者の数、市外局番(e)における他の交換、地方の国名略号(a)と他の国名略号(c)における他の市外局番にnを分解できます。 この記法を使用して、階層型ルーティングには空間的コストO(l+e+a+c)があります。 それぞれのこれらの要素が非常にゆっくりせいぜいたくさんはるかにnであり、成長するのに注意してください。 これは、今日それが配備されるときスペースを使い果たさないという何らかの望みを持っている電話スイッチを組立てることができるのを含意します。

   The fundamental property of hierarchical routing that makes this
   scalability possible is the ability to form abstractions: here, the
   ability to group subscribers into exchanges, area codes and country
   codes. Further, such abstractions must provide useful information for
   the ability to do routing. Some abstractions, such as the group of
   users with green phones, are not useful when it comes time to route a
   call.

このスケーラビリティを可能にする階層型ルーティングの基本財産は抽象化を形成する能力です: ここ、加入者を交換、市外局番、および国名略号に分類する能力。 さらに、そのような抽象化はルーティングをする能力のための役に立つ情報を提供しなければなりません。 呼び出しを発送するのが調節しに来るとき、緑色の電話があるユーザー層などのいくつかの抽象化は役に立ちません。

   Since the information that the routing system really needs is the
   location of the address within the topology, for hierarchical
   routing, the useful abstraction must capture the topological location
   of an address within the network. In principle this could be
   accomplished in one of two ways.  Either (a) constrain the topology
   (and allowed topology changes) to match address assignment. Or, (b)
   avoid constraints on the topology (and topology changes), but require
   that as the topology changes, an entity's address change as well. The
   process of changing an entity's address is known as "renumbering."

ルーティングシステムが本当に必要とする情報がトポロジーの中のアドレスの位置であるので、階層型ルーティングのために、役に立つ抽象化はネットワークの中でアドレスの位相的な位置を捕らえなければなりません。 原則として、2つの方法の1つでこれを達成できました。 (a)は、トポロジー(そして、トポロジー変化を許容する)がアドレス課題に合っているのを抑制します。 (b) または、トポロジー(そして、トポロジー変化)で規制を避けてくださいが、トポロジーが変化するとき、それを必要としてください、また、実体のアドレス変化。 実体のアドレスを変える過程は「番号を付け替える」として知られています。

Rekhter & Li             Best Current Practice                  [Page 3]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[3ページ]RFC2008 1996年10月

4 Scaling the Internet routing system

4 インターネット・ルーティングシステムをスケーリングすること。

   The enormous growth of the Public Internet places a heavy load on the
   Internet routing system. Before the introduction of CIDR the growth
   rate had doubled the size of the routing table roughly every nine
   months. Capacity of computer technology doubles roughly every 24
   months. Even if we could double the capacities of the routers in the
   Internet every 24 months, inevitably the size of the routing tables
   is going to exceed the limit of the routers. Therefore, to preserve
   uninterrupted continuous growth of the Public Internet, deploying
   mechanisms that contain the growth rate of the routing information is
   essential.

Publicインターネットの莫大な成長はインターネット・ルーティングシステムに重量物を置きます。 CIDRの導入の前に、成長率は9カ月毎におよそ経路指定テーブルのサイズを倍にしました。 コンピュータ技術の容量は24カ月毎におよそ倍増します。 私たちがインターネットで24カ月毎、必然的にルータの能力を倍にすることができても、経路指定テーブルのサイズはルータの限界を超えているでしょう。 したがって、Publicインターネットのとぎれない絶え間ない成長を保存するためにルーティング情報の成長率を含むメカニズムを配備するのは不可欠です。

   Lacking mechanisms to contain the growth rate of the routing
   information, the growth of the Internet would have to be either
   limited or frozen, or the Internet routing system would become
   overloaded. The result of overloading routing is that the routing
   subsystem will fail: either equipment (routers) could not maintain
   enough routes to insure global connectivity, or providers will simply
   exclude certain routes to insure that other routes provide
   connectivity to particular sites. This document assumes that neither
   of the outcomes mentioned in this paragraph is acceptable.

ルーティング情報の成長率を含むメカニズムを欠いていて、インターネットの成長が、限られているか、凍らなければならないでしょう、またはインターネット・ルーティングシステムは積みすぎられるようになるでしょう。 ルーティングを積みすぎるという結果はルーティングサブシステムが失敗するということです: 設備(ルータ)がグローバルな接続性を保障できるくらいのルートを維持できませんでしたか、またはプロバイダーは、他のルートが特定のサイトに接続性を提供するのを保障するために単にある一定のルートを除くでしょう。 このドキュメントは、このパラグラフで言及された結果のどちらも許容できないと仮定します。

   Classless Inter-Domain Routing (CIDR) [RFC1518, RFC1519] has been
   deployed since late 1992 in the Public Internet as the primary
   mechanism to contain the growth rate of the routing information -
   without CIDR the Internet routing system would have already
   collapsed. For example, in October 1995, within AlterNet (one of the
   major Internet Service Providers) there were 3194 routes. Thanks to
   aggregation, AlterNet advertised only 799 routes to the rest of the
   Internet - a saving of 2395 routes (75%) [Partan 95]. In October 1995
   the Internet Routing Registry (IRR) contained 61,430 unique prefixes
   listed, not counting prefixes marked as withdrawn (or 65,191 prefixes
   with prefixes marked as withdrawn). That is roughly a lower bound
   since many prefixes are not registered in the IRR. CIDR aggregation
   resulted in less than 30,000 routes in the default-free part of the
   Internet routing system [Villamizar 95].

1992年後半以来階級のないInter-ドメインルート設定(CIDR)[RFC1518、RFC1519]は、インターネット・ルーティングシステムが既に潰したCIDRなしでルーティング情報の成長率を含むように一次機構としてPublicインターネットで配備されています。 例えば、1995年10月に、AlterNet(主要なインターネットサービスプロバイダの1つ)の中に、3194のルートがありました。 集合のおかげで、AlterNetはインターネットの残りに799のルートだけの広告を出しました--2395のルート(75%)[Partan95]の節約。 6万1430のインターネットルート設定Registry(IRR)の含まれたユニークな接頭語が記載しました、引き下がるようにマークされた接頭語(または、引き下がるようにマークされた接頭語がある6万5191の接頭語)を数えないで1995年10月に。 多くの接頭語がIRRに登録されないので、それはおよそ下界です。 CIDR集合はインターネット・ルーティングシステム[Villamizar95]の無デフォルトの部分の3万未満のルートをもたらしました。

   CIDR is an example of the application of hierarchical routing in the
   Public Internet, where subnets, subscribers, and finally providers
   are some possible levels in the hierarchy. For example, a router
   within a site need not keep detailed routing information about every
   possible host in that site. Instead, the router maintains routing
   information on a per subnet basis. Likewise, a router within a
   provider need not keep detailed routing information about individual
   subnets within its subscribers. Instead, the router could maintain
   routing information on a per subscriber basis. Moreover, a router
   within a provider need not keep detailed routing information about

CIDRはPublicインターネットでの階層型ルーティングの適用に関する例です。(そこでは、サブネット、加入者、および最終的にプロバイダーが階層構造のいくつかの可能なレベルです)。 例えば、サイトの中のルータはそのサイトのすべての可能なホストの詳細なルーティング情報を保つ必要はありません。 代わりに、ルータはサブネット基礎あたりのaのルーティング情報を保守します。 同様に、プロバイダーの中のルータは加入者の中に個々のサブネットの詳細なルーティング情報を保つ必要はありません。 代わりに、ルータは加入者基礎あたりのaのルーティング情報を保守するかもしれません。 そのうえ、プロバイダーの中のルータは詳細なルーティング情報を置く必要はありません。

Rekhter & Li             Best Current Practice                  [Page 4]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[4ページ]RFC2008 1996年10月

   stub (single home) subscribers of other providers by maintaining
   routing information on a per provider basis.

プロバイダー基礎あたりのaのルーティング情報を保守することによって、他のプロバイダーの加入者を引き抜いてください(ただ一つの家)。

   Because of pre-CIDR address allocation, many routes in the Internet
   are not suitable for hierarchical aggregation. Moreover, unconnected
   sites with pre-CIDR address allocations exist. If these sites connect
   to the Internet at some point in the future, the routes to these
   sites are unlikely to be suitable for hierarchical aggregation. Also,
   when a site uses addresses obtain from its provider, but then later
   switches to a different provider (while continuing to use the same
   addresses), the route to the site may no longer be suitable for
   hierarchical aggregation.

プレCIDRアドレス配分のために、インターネットの多くのルートは階層的な集合に適していません。 そのうえ、プレCIDRアドレス配分がある無関係のサイトは存在しています。 これらのサイトが将来何らかのポイントのインターネットに接続するなら、これらのサイトへのルートは階層的な集合に適させそうにはありません。 また、プロバイダーから得ますが、サイトがいつアドレスを使用するかは後で異なったプロバイダーに切り替わって(同じアドレスを使用し続けている間)、サイトへのルートはもう階層的な集合に適していないかもしれません。

   Hierarchical routing requires that aggregation boundaries for the
   addressing information be formed along some hierarchy. As a result,
   many exceptions will be injected into the routing system in the
   future, besides those exceptions that currently exist. Each exception
   added to the routing system deters the scalability of the routing
   system. The exact number of exceptions that can be tolerated is
   dependent on the technology used to support routing. Unbridled growth
   in the number of such exceptions will cause the routing system to
   collapse.

階層型ルーティングは、アドレス指定情報のための集合境界が何らかの階層構造に沿って形成されるのを必要とします。 その結果、多くの例外が将来ルーティングシステムに注がれるでしょう、現在存在するそれらの例外以外に。 ルーティングシステムに追加された各例外はルーティングシステムのスケーラビリティを思いとどまらせます。 許容できる例外のはっきりした数は掘るのを支持するのに使用される技術に依存しています。 そのような例外の数における放逸な成長で、ルーティングシステムは崩れるでしょう。

5 Address allocation and management policies

5 アドレス配分と経営政策

   IP address allocation and management policy is a complex,
   multifaceted issue. It covers a broad range of issues, such as who
   formulates the policies, who executes the policies, what is the role
   of various registries, what is the role of various organizations
   (e.g., ISOC, IAB, IESG, IETF, IEPG, various government bodies, etc.),
   the participation of end users in requesting addresses, and so on.
   Address allocation and management and the scalability of the routing
   system are interrelated - only certain address allocation and
   management policies yield scalable routing. The Internet routing
   system is subject to both technological and fundamental constraints.
   These constraints restrict the choices of address allocation policies
   that are practical.

IPアドレス配分と経営政策は複雑で、多才な問題です。 それは広範囲な問題をカバーしています、だれが方針、だれが方針、様々な登録の役割、様々な組織の役割であること(例えば、ISOC、IAB、IESG、IETF、IEPG、様々な政府機関省庁など)であることを実行するか、またアドレスを要求することへのエンドユーザの参加などを定式化するのなどように。 ルーティングシステムのアドレス配分、管理、およびスケーラビリティは相関的です--あるアドレス配分と経営政策だけがスケーラブルなルーティングをもたらします。 インターネット・ルーティングシステムは技術的なものと同様に基本的な規制を受けることがあります。 これらの規制は実用的なアドレス配分方針の選択を制限します。

5.1 The "address ownership" allocation policy and its implications on
   the Public Internet

5.1 「アドレス所有権」配分方針とPublicインターネットでのその含意

   "Address ownership" is one possible address allocation and management
   policy. The "address ownership" policy means that part of the address
   space, once allocated to an organization, remains allocated to the
   organization as long as that organization wants it. Further, that
   portion of the address space would not be allocated to any other
   organization.  Often, such addresses are called "portable." It was
   assumed that if an organization acquires its addresses via the

「アドレス所有権」は、1つの可能なアドレス配分と経営政策です。 「アドレス所有権」方針は、アドレス空間の一度組織に割り当てられた部分がその組織がそれが欲しい限り、組織に割り当てたままで残っていることを意味します。 さらに、アドレス空間のその部分はいかなる他の組織にも割り当てられないでしょう。 しばしば、そのようなアドレスは「携帯用である」と呼ばれます。 を通してそれが組織であるならアドレスを習得すると思われた。

Rekhter & Li             Best Current Practice                  [Page 5]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[5ページ]RFC2008 1996年10月

   "address ownership" policy, the organization would be able to use
   these addresses to gain access to the Internet routing services,
   regardless of where the organization connects to the Internet.

「アドレス所有権」方針、組織は組織が接続するところにかかわらずインターネット・ルーティングサービスへのアクセスにインターネットを獲得するのにこれらのアドレスを使用できるでしょう。

   While it has never been explicitly stated that various Internet
   Registries use the "address ownership" allocation policy, it has
   always been assumed (and practiced).

明らかに様々なインターネットRegistriesが「アドレス所有権」配分方針を使用すると一度も述べられていたことがありませんが、それはいつも想定されていました(そして、練習されます)。

   To understand the implications of the "address ownership" policy
   ("portable" addresses) on the scalability of the Internet routing
   system, one must observe that:

インターネット・ルーティングシステムのスケーラビリティで「アドレス所有権」方針の含意(「携帯用」のアドレス)を理解するために、以下のことを観測しなければなりません。

     (a) By definition, address ownership assumes that addresses, once
     assigned, fall under the control of the assignee. It is the
     assignee that decides when to relinquish the ownership (although
     the decision could be influenced by various factors).
     Specifically, the assignee is not required (but may be influenced)
     to relinquish the ownership as the connectivity of the assignee to
     the Internet changes.

(a) 定義上、アドレス所有権は、一度割り当てられたアドレスが指定代理人のコントロールの下で下がると仮定します。 それはいつ所有権を放棄するかを決める指定代理人(様々な要素で決定に影響を及ぼすことができましたが)です。 明確に、インターネットへの指定代理人の接続性が変化するとき、指定代理人は所有権を放棄する必要はありません(しかし、影響を及ぼされるかもしれません)。

     (b) By definition, hierarchical routing assumes that addresses
     reflect the network topology as much as possible.

(b) 定義上、階層型ルーティングは、アドレスがネットワーク形態をできるだけ反映すると仮定します。

   Therefore, the only presently known practical way to satisfy both
   scalable hierarchical routing and address ownership for everyone is
   to assume that the topology (or at least certain pieces of it) will
   be permanently fixed. Given the distributed, decentralized, largely
   unregulated, and global (international) nature of the Internet,
   constraining the Internet topology (or even certain parts of it) may
   have broad technical, social, economical, and political implications.
   To date, little is known of what these implications are; even less is
   known whether these implications would be acceptable (feasible) in
   practice. Therefore, at least for now, we have to support an Internet
   with an unconstrained topology (and unconstrained topological
   changes).

したがって、スケーラブルな階層型ルーティングと皆のためのアドレス所有権の両方を満たす唯一の現在知られている実用的な方法はトポロジー(または、少なくともある片のそれ)が永久に修理されると仮定することです。 分配されて、分散していて、主に調節されないで、グローバルな(国際的な)インターネットの性質、技術的で、社会的で、経済的にトポロジー(または、それのある部分さえ)が広くするかもしれないインターネットを抑制して、および政治的な影響を与えます。 これまで、これらの含意が何であるかが少ししか知られていません。 これらの含意が実際には許容できるだろう(可能な)か否かに関係なく、以下さえ知られています。 したがって、少なくとも当分、私たちは自由なトポロジー(そして、自由な位相的な変化)でインターネットを支持しなければなりません。

   Since the Internet does not constrain its topology (or allowed
   topology changes), we can either have address ownership for everyone
   or a routable Internet, but not both, or we need to develop and
   deploy new mechanisms (e.g., by decoupling the address owned by the
   end users from those used by the Internet routing, and provide
   mechanisms to translate between the two). In the absence of new
   mechanisms, if we have address ownership ("portable" addresses) for
   everyone, then the routing overhead will lead to a breakdown of the
   routing system resulting in a fragmented (partitioned) Internet.
   Alternately, we can have a routable Internet, but without address
    ownership ("portable" addresses) for everyone.

インターネットがトポロジー(または、トポロジー変化を許容する)を抑制しないので、私たちが皆のためのアドレス所有権か発送可能インターネットを持っていますが、ともに持つことができませんし、私たちは、新しいメカニズム(インターネットのそばで例えば、それらからエンドユーザによって所有されていたアドレスの衝撃を吸収することによってルーティングを使用して、2つの間で翻訳するためにメカニズムを提供する)を開発して、配備する必要があります。 新しいメカニズムがないとき、私たちに皆のためのアドレス所有権(「携帯用」のアドレス)があるなら、ルーティングオーバーヘッドは断片化している(仕切られる)インターネットをもたらすルーティングシステムの故障につながるでしょう。 交互に、発送可能インターネットを持っていますが、私たちは皆のためのアドレス所有権(「携帯用」のアドレス)なしでそうすることができます。

Rekhter & Li             Best Current Practice                  [Page 6]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[6ページ]RFC2008 1996年10月

5.2 The "address lending" allocation policy and its implications for the
   Public Internet

5.2 「アドレスの貸す」配分方針とPublicインターネットへのその含意

   Recently, especially since the arrival of CIDR, some subscribers and
   providers have followed a model in which address space is not owned
   (not portable), but is bound to the topology. This model suggests an
   address allocation and management policy that differs from the
   "address ownership" policy. The following describes a policy, called
   "address lending," that provides a better match (as compared to the
   "address ownership" policy) to the model.

最近、特にCIDRの到着以来、どのアドレス空間がトポロジーに所有されていませんが(携帯用でない)、制限されているかでいくつかの加入者とプロバイダーがモデルについて来ています。 このモデルは「アドレス所有権」方針と異なっているアドレス配分と経営政策を勧めます。 以下は、より良いマッチ(「アドレス所有権」方針と比べて)をモデルに供給する「アドレスの貸すこと」と呼ばれる方針を説明します。

   An "address lending" policy means that an organization gets its
   addresses on a "loan" basis. For the length of the loan, the lender
   cannot lend the addresses to any other borrower. Assignments and
   allocations based on the "address lending" policy should explicitly
   include the conditions of the loan. Such conditions must specify that
   allocations are returned if the borrower is no longer contractually
   bound to the lender, and the lender can no longer provide aggregation
   for the allocation. If a loan ends, the organization can no longer
   use the borrowed addresses, and therefore must get new addresses and
   renumber to use them. The "address lending" policy does not constrain
   how the new addresses could be acquired.

「アドレスの貸す」方針は、組織が「ローン」ベースに関するアドレスを得ることを意味します。 ローンの長さのために、貸し手はいかなる他の借り手にもアドレスを与えることができません。 「アドレスの貸す」方針に基づく課題と配分は明らかにローンの状態を含むべきです。 借り手がもう貸し手に契約上縛られないなら、そのような状態は、配分が返されると指定しなければなりません、そして、貸し手はもう配分に集合を前提とすることができません。 ローンが終わるなら、したがって、組織は、もう借りられたアドレスを使用できないで、新しいアドレスを得て、使用にそれらに番号を付け替えさせなければなりません。 「アドレスの貸す」方針はどう新しいアドレスを習得できたかを抑制しません。

   This document expects that the "address lending" policy would be used
   primarily by Internet Registries associated with providers; however,
   this document does not preclude the use of the "address lending"
   policy by an Internet Registry that is not associated with a
   provider.

このドキュメントは、「アドレスの貸す」方針が主としてプロバイダーに関連しているインターネットRegistriesによって使用されると予想します。 しかしながら、このドキュメントはプロバイダーに関連づけられないインターネットRegistryによる「アドレスの貸す」方針の使用を排除しません。

   This document expects that when the "address lending" policy is used
   by an Internet Registry associated with a provider, the provider is
   responsible for arranging aggregation of these addresses to a degree
   that is sufficient to achieve Internet-wide IP connectivity.

このドキュメントは、「アドレスの貸す」方針がプロバイダーに関連しているインターネットRegistryによって使用されるとき、プロバイダーがインターネット全体のIPの接続性を達成するために十分な1度にこれらのアドレスの集合をアレンジするのに原因となると予想します。

   This document expects that when the "address lending" policy is used
   by an Internet Registry associated with a provider, the terms and
   conditions of the loan would be coupled to the service agreement
   between the provider and the subscribers. That is, if the subscriber
   moves to another provider, the loan would be canceled.

このドキュメントは、「アドレスの貸す」方針がプロバイダーに関連しているインターネットRegistryによって使用されるとき、ローンに関する条件がプロバイダーと加入者とのサービス契約と結合されると予想します。 すなわち、加入者が別のプロバイダーに移るなら、ローンは中止されるでしょう。

Rekhter & Li             Best Current Practice                  [Page 7]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[7ページ]RFC2008 1996年10月

   To reduce disruptions when a subscriber changes its providers, this
   document strongly recommends that the terms and conditions of the
   loan should include provision for a grace period. This provision
   would allow a subscriber that disconnects from its provider a certain
   grace period after the disconnection. During this grace period, the
   borrower (the subscriber) may continue to use the addresses obtained
   under the loan. This document recommends a grace period of at least
   30 days. Further, to contain the routing information overhead, this
   document suggests that a grace period be no longer than six months.

加入者がプロバイダーを変えるときの分裂を抑えるために、このドキュメントは、ローンに関する条件が据置期間の間支給を含むべきであることを強く勧めます。 この支給は断線の後にプロバイダーからある据置期間を外す加入者を許容するでしょう。 この据置期間の間、借り手(加入者)は、ローンで得られたアドレスを使用し続けるかもしれません。 このドキュメントは少なくとも30日間の据置期間を推薦します。 さらに、ルーティング情報オーバーヘッドを含むように、このドキュメントは、6カ月より据置期間がもうであると示唆します。

   To understand the scalability implications of the "address lending"
   policy, observe that if a subscriber borrows its addresses from its
   provider's block, then the provider can advertise a single address
   prefix. This reduces the routing information that needs to be carried
   by the Internet routing system (for more information, see Section
   5.3.1 of RFC1518). As the subscriber changes its provider, the loan
   from the old provider would be returned, and the loan from the new
   provider would be established. As a result, the subscriber would
   renumber to the new addresses. Once the subscriber renumbers into the
   new provider's existing blocks, no new routes need to be introduced
   into the routing system.

「アドレスの貸す」方針のスケーラビリティ含意を理解するには、加入者がプロバイダーのブロックからアドレスを借りるならプロバイダーがただ一つのアドレス接頭語の広告を出すことができるのを観測してください。 これはインターネット・ルーティングシステムによって運ばれる必要があるルーティング情報を減らします(詳しい情報に関して、.1セクション5.3RFC1518を見てください)。 加入者がプロバイダーを変えるとき、古いプロバイダーからのローンは返されるでしょう、そして、新しいプロバイダーからのローンは確立されるでしょう。 その結果、加入者は新しさにアドレスに番号を付け替えさせるでしょう。 加入者が新しいプロバイダーの存在にブロックにいったん番号を付け替えさせると、どんな新しいルートも、ルーティングシステムに導入される必要がありません。

   Therefore, the "address lending" policy, if applied appropriately, is
   consistent with the constraints on address allocation policies
   imposed by hierarchical routing, and thus promotes a scalable routing
   system.  Thus, the "address lending" policy, if applied
   appropriately, could play an important role in enabling the
   continuous uninterrupted growth of the Internet.

したがって、「アドレスの貸す」方針は、適切に適用されるなら階層型ルーティングで課されたアドレス配分方針における規制と一致していて、その結果、スケーラブルなルーティングシステムを促進します。 したがって、適切に適用されるなら、「アドレスの貸す」方針はインターネットの連続したとぎれない成長を可能にする際に重要な役割を果たすかもしれません。

   To be able to scale routing in other parts of the hierarchy, the
   "lending" policy may also be applied hierarchically, so that
   addresses may in turn be lent to other organizations. The implication
   here is that the end of a single loan may have effects on
   organizations that have recursively borrowed parts of the address
   space from the main allocation. In this case, the exact effects are
   difficult to determine a priori.

また、階層構造の他の部分でルーティングをスケーリングできるように、「貸す」方針は階層的に適用されるかもしれません、順番に他の組織にアドレスを与えることができるように。 ただ一つのローンの端は主な配分からアドレス空間の部品を再帰的に借りた組織で手答えがあるかもしれないという含意がここにあります。 この場合、正確な効果は先験的に決定するのが難しいです。

5.3 In the absence of an explicit "address lending" policy

5.3 明白な「アドレスの貸す」方針がないとき

   Organizations connecting to the Internet should be aware that even if
   their current provider, and the provider they switch to in the future
   do not require renumbering, renumbering may still be needed to
   achieve Internet-wide IP connectivity. For example, an organization
   may now receive Internet service from some provider and allocate its
   addresses out of the CIDR block associated with the provider. Later
   the organization may switch to another provider. The previous
   provider may still be willing to allow the organization to retain
   part of the provider's CIDR block, and accept a more specific prefix

インターネットに接続する組織はそれらが将来に切り換えるそれらの現在のプロバイダー、およびプロバイダーがそうしないでも番号を付け替えるのを必要にしてください、番号を付け替えることがインターネット全体のIPの接続性を達成するのにまだ必要であってもよいことを意識しているべきです。 例えば、組織は、現在、何らかのプロバイダーからインターネットのサービスを受けて、プロバイダーに関連しているCIDRブロックからアドレスを割り当てるかもしれません。 その後、組織は別のプロバイダーに切り替わるかもしれません。 前のプロバイダーは、組織がプロバイダーのCIDRブロックの一部を保有して、より特定の接頭語を受け入れるのを許容しても構わないとまだ思っているかもしれません。

Rekhter & Li             Best Current Practice                  [Page 8]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[8ページ]RFC2008 1996年10月

   for that organization from the new provider. Likewise, the new
   provider may be willing to accept that organization without
   renumbering and advertise the more specific prefix (that covers
   destinations within the organization) to the rest of the Internet.
   However, if one or more other providers exist, that are unwilling or
   unable to accept the longer prefix advertised by the new provider,
   then the organization would not have IP connectivity to part of the
   Internet. Among the possible solutions open to the organization may
   be either to renumber, or for others to acquire connectivity to
   providers that are willing and able to accept the prefix.

新しいプロバイダーからのその組織のために。 同様に、新しいプロバイダーは、インターネットの残りに番号を付け替えるのなしでその組織を受け入れる、より特定の接頭語の広告を出しても(それは組織の中で目的地を覆っています)構わないと思っているかもしれません。 しかしながら、他の1つ以上のプロバイダーが存在しているなら、それが不本意であるか、または新しいプロバイダーによって広告に掲載されたより長い接頭語を受け入れることができない、そして、組織はインターネットの一部にIPの接続性を持っていないでしょう。 番号を付け替えるか、または望んでいる、できるプロバイダーに接続性を取得する他のもの受け入れるのにおいて可能である、組織に開かれている解決策がどちらかであるかもしれないことを接頭語。

   The above shows that the absence of an explicit "address lending"
   policy from a current provider in no way ensures that renumbering
   will not be required in the future when changing providers.
   Organizations should be aware of this fact should they encounter a
   provider making claims to the contrary.

将来プロバイダーを変えるとき、現在のプロバイダーからの明白な「アドレスの貸す」方針の欠如がその番号を付け替えることを決して確実にしない上のショーは必要でないでしょう。 それと反対にクレームをするプロバイダーに遭遇するなら、組織はこの事実を知っているべきです。

6 Recommendations

6つの推薦

   Observe that the goal of hierarchical routing in the Internet is not
   to reduce the total amount of routing information in the Internet to
   the theoretically possible minimum, but just to contain the volume of
   routing information within the limits of technology,
   price/performance, and human factors.  Therefore, organizations that
   could provide reachability to a sufficiently large fraction of the
   total destinations in the Internet and could express such
   reachability through a single IP address prefix could expect that a
   route with this prefix will be maintained throughout the default-free
   part of the Internet routing system, regardless of where they connect
   to the Internet.  Therefore, using the "address ownership" policy
   when allocating addresses to such organizations is a reasonable
   choice.  Within such organizations this document suggests the use of
   the "address lending" policy.

インターネットの階層型ルーティングの目標がインターネットでルーティング情報の総量を理論的に可能な最小限に減少させるのではなく、まさしく技術、価格対性能比、および人間の要素の限界の中にルーティング情報のボリュームを含むことであることを観測してください。 したがって、インターネットで総目的地の十分大きい部分に可到達性を提供できて、ただ一つのIPアドレス接頭語を通してそのような可到達性を言い表すことができた組織は、この接頭語があるルートが無デフォルトの部分中で維持されて、どこにかかわらずシステムを発送するインターネットではインターネットに接続するということであると予想できました。 したがって、そのような組織にアドレスを割り当てるとき「アドレス所有権」方針を使用するのは、正当な選択です。 そのような組織の中では、このドキュメントは「アドレスの貸す」方針の使用を示します。

   For all other organizations that expect Internet-wide IP
   connectivity, the reachability information they inject into the
   Internet routing system should be subject to hierarchical
   aggregation. For such organizations, allocating addresses based on
   the "address ownership" policy makes hierarchical aggregation
   difficult, if not impossible. This, in turn, has a very detrimental
   effect on the Internet routing system. To prevent the collapse of the
   Internet routing system, for such organizations, this document
   recommends using the "address lending" policy. Consequently, when
   such an organization first connects to the Public Internet or changes
   its topological attachment to the Public Internet, the organization
   eventually needs to renumber. Renumbering allows the organization to
   withdraw any exceptional prefixes that the organization would
   otherwise inject into the Internet routing system. This applies to

インターネット全体のIPの接続性を予想する他のすべての組織において、それらがインターネット・ルーティングシステムを注ぐ可到達性情報は階層的な集合を受けることがあるべきです。 そのような組織のために、「アドレス所有権」方針に基づくアドレスを割り当てるのに、階層的な集合は難しいか、または不可能になります。 これは順番に非常に有害な影響をインターネット・ルーティングシステムに与えます。 そのような組織のインターネット・ルーティングシステムの崩壊を防ぐために、このドキュメントは、「アドレスの貸す」方針を使用することを勧めます。 そのような組織が最初にその結果PublicインターネットかPublicインターネット、組織への位相的な付属が結局番号を付け替える必要がある変化に接続するとき。 番号を付け替えることで、組織はそうでなければ組織がインターネット・ルーティングシステムに注入するどんな例外的な接頭語も引き下がらせることができます。 これは、申し込みます。

Rekhter & Li             Best Current Practice                  [Page 9]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[9ページ]RFC2008 1996年10月

   the case where the organization takes its addresses out of its direct
   provider's block and the organization changes its direct provider.
   This may also apply to the case where the organization takes its
   addresses out of its indirect provider's block, and the organization
   changes its indirect provider, or the organization's direct provider
   changes its provider.

組織がダイレクトプロバイダーのブロックと組織からアドレスを取り出すこの件はダイレクトプロバイダーを変えます。 また、これが組織が間接的なプロバイダーのブロックからアドレスを取り出すケース、および組織変化に間接的なプロバイダーを適用するかもしれませんか、または組織のダイレクトプロバイダーはプロバイダーを変えます。

   Carrying routing information has a cost associated with it. This
   cost, at some point, may be passed back in full to the organizations
   that inject the routing information. Aggregation of addressing
   information (via CIDR) could reduce the cost, as it allows an
   increase in the number of destinations covered by a single route.
   Organizations whose addresses are allocated based on the "address
   ownership" policy (and thus may not be suitable for aggregation)
   should be prepared to absorb the cost completely on their own.

ルーティング情報を運ぶのにおいて、それに関連している費用があります。 何らかのポイントでは、この費用はルーティング情報を注入する組織にすべて戻されるかもしれません。 アドレス指定情報(CIDRを通した)の集合は生産費を切り下げることができました、ただ一つのルートでカバーされた目的地の数の増加を許容するとき。 アドレスが「アドレス所有権」方針(そして、その結果、集合に適しないかもしれない)に基づいて割り当てられる組織は完全に一人で費用を吸収するように準備されるべきです。

   Observe that neither the "address ownership," nor the "address
   lending" policy, by itself, is sufficient to guarantee Internet-wide
   IP connectivity. Therefore, we recommend that sites with addresses
   allocated based on either policy should consult their providers about
   the reachability scope that could be achieved with these addresses,
   and associated costs that result from using these addresses.

「アドレス所有権」も「アドレスの貸す」方針もインターネット全体のIPの接続性を保証するためにそれ自体で十分でないことを観測してください。 したがって、私たちは、アドレスのどちらかの方針に基づいた割り当てでのサイトはこれらのアドレスで達成できた可到達性範囲に関してそれらのプロバイダーに相談して、これらのアドレスを使用するのから結果として生じる関連コストに相談するべきであることを勧めます。

   If an organization doesn't require Internet-wide IP connectivity,
   then address allocation for the organization could be done based on
   the "address ownership" policy. Here, the organization may still
   maintain limited IP connectivity (e.g., with all the subscribers of
   its direct provider) by limiting the distribution scope of its
   routing information to its direct provider. Connectivity to the rest
   of the Internet can be handled by mediating gateways (e.g.,
   application layer gateways, Network Address Translators (NATs)). Note
   that use of mediating gateways eliminates the need for renumbering,
   and avoids burdening the Internet routing system with non-
   aggregatable addressing information; however they have other
   drawbacks which may prove awkward in certain situations.

組織がインターネット全体のIPの接続性を必要としないなら、「アドレス所有権」方針に基づいて組織のためのアドレス配分をするかもしれません。 ここで、組織は、ルーティング情報の分配範囲をダイレクトプロバイダーに制限することによって、まだ、限られたIPの接続性(例えば、ダイレクトプロバイダーのすべての加入者がいる)を維持しているかもしれません。 ゲートウェイ(例えば、応用層ゲートウェイ、Network Address Translators(NATs))を調停することによって、インターネットの残りへの接続性を扱うことができます。 仲介ゲートウェイの使用が、番号を付け替えることの必要性を排除して、非「集合-可能」なアドレス指定情報でインターネット・ルーティングシステムを負担するのを避けることに注意してください。 しかしながら、彼らには、ある状況で無器用であると判明するかもしれない他の欠点があります。

   Both renumbering (due to the "address lending" policy), and non-
   aggregated routing information (due to the "address ownership"
   policy), and the use of mediating gateways result in some costs.
   Therefore, an organization needs to analyze its own connectivity
   requirements carefully and compare the tradeoffs associated with
   addresses acquired via either policy vs. having connectivity via
   mediating gateways (possibly augmented by limited IP connectivity)
   using addresses acquired via "address ownership." To reduce the cost
   of renumbering, organizations should be strongly encouraged to deploy
   tools that simplify renumbering (e.g., Dynamic Host Configuration
   Protocol [RFC 1541]). Use of the DNS should be strongly encouraged.

番号を付け替えるのであっ(「アドレスの貸す」方針による)て、非集められたルーティング情報(「アドレス所有権」方針による)と仲介ゲートウェイの使用の両方がいくつかのコストをもたらします。 したがって、組織は、「アドレス所有権」を通して習得されたアドレスを使用することでゲートウェイ(ことによると限られたIPの接続性によって増大される)を調停することを通して接続性を持っていることに対して、慎重にそれ自身の接続性要件を分析して、どちらの方針でも習得するアドレスに関連している見返りを比較する必要があります。 番号を付け替えることのコストを削減するために、組織が番号を付け替えること(例えば、Dynamic Host Configuration Protocol[RFC1541])を簡素化するツールを配布するよう強く奨励されるべきです。 DNSの使用は強く奨励されるべきです。

Rekhter & Li             Best Current Practice                 [Page 10]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[10ページ]RFC2008 1996年10月

7 Summary

7概要

   Any address allocation and management policy for IP addresses used
   for Internet connectivity must take into account its impact on the
   scalability of the Public Internet routing system. Among all of the
   possible address allocation and management policies only the ones
   that yield a scalable routing system are feasible. All other policies
   are self-destructive in nature, as they lead to a collapse of the
   Internet routing system, and therefore to the fragmentation
   (partitioning) of the Public Internet.

インターネットの接続性に使用されるIPアドレスのためのどんなアドレス配分と経営政策もPublicインターネット・ルーティングシステムのスケーラビリティで影響を考慮に入れなければなりません。 可能なアドレス配分と経営政策のすべてだけ中では、スケーラブルなルーティングシステムをもたらすものは可能です。 他のすべての方針が自己したがって、自然と、インターネット・ルーティングシステムの崩壊に通じて、Publicインターネットの断片化(仕切り)に破壊的です。

   Within the context of the current Public Internet, address allocation
   and management policies that assume unrestricted address ownership
   have an extremely negative impact on the scalability of the Internet
   routing system. Such policies are almost certain to exhaust the
   scalability of the Internet routing system well before we approach
   the exhaustion of the IPv4 address space and before we can make
   effective use of the IPv6 address space. Given the Internet's growth
   rate and current technology, the notion that everyone can own address
   space and receive Internet-wide routing services, despite where they
   connect to the Internet, is currently technically infeasible.
   Therefore, this document makes two recommendations. First, the
   "address lending" policy should be formally added to the set of
   address allocation policies in the Public Internet. Second,
   organizations that do not provide a sufficient degree of routing
   information aggregation to obtain access to the Internet routing
   services should be strongly encouraged to use this policy to gain
   access to the services.

現在のPublicインターネットの文脈の中では、無制限なアドレス所有権を引き受けるアドレス配分と経営政策がインターネット・ルーティングシステムのスケーラビリティに非常に否定的な影響力を持っています。 そのような方針は私たちがIPv4アドレス空間の疲労困憊にアプローチする前と私たちがIPv6アドレス空間をうまく利用することができる前にインターネット・ルーティングシステムのスケーラビリティをよく消耗させるのはほとんど確かです。 インターネットの成長率と現在の技術を考えて、皆がアドレス空間を所有して、それらがインターネットに接続するところにもかかわらず、インターネット全体のルーティングサービスを受けることができるという概念は現在、技術的に実行不可能です。 したがって、このドキュメントは2つの推薦状をします。 まず最初に、「アドレスの貸す」方針はPublicインターネットで正式にアドレス配分方針のセットに追加されるべきです。 2番目に、インターネット・ルーティングサービスへのアクセスを得るために十分な度合いのルーティング情報集合を提供しない組織がサービスへのアクセスを得るのにこの方針を使用するよう強く奨励されるべきです。

   Since the current IPv6 address allocation architecture is based on
   CIDR, recommendations presented in this document apply to IPv6
   address allocation and management policies as well.

現在のIPv6アドレス配分アーキテクチャがCIDRに基づいているので、本書では提示された推薦はIPv6アドレス配分とまた、経営政策に適用されます。

8 Security Considerations

8 セキュリティ問題

   Renumbering a site has several possible implications on the security
   policies of both the site itself and sites that regularly communicate
   with the renumbering sites.

サイトに番号を付け替えさせると、いくつかの関与の可能性がサイト自体と定期的に番号を付け替えるサイトで交信するサイトの両方の安全保障政策に持たれています。

   Many sites currently use "firewall" systems to provide coarse-grained
   access control from external networks, such as The Internet, to their
   internal systems.  Such firewalls might include access control
   decisions based on the claimed source address of packets arriving at
   such firewall systems.  When the firewall policy relates to packets
   arriving on the firewall from inside the site, then that firewall
   will need to be reconfigured at the same time that the site itself
   renumbers.  When the firewall policy relates to packets arriving at
   the firewall from outside the site, then such firewalls will need to

多くのサイトが現在外部のネットワークから下品なアクセスコントロールを提供するのに「ファイアウォール」システムを使用します、インターネットなどのように、それらの内部のシステムに。そのようなファイアウォールはそのようなファイアウォールシステムに到着するパケットの要求されたソースアドレスに基づくアクセス制御決定を含むかもしれません。ファイアウォール方針がファイアウォールの上にサイトの中から到着するパケットに関連すると、次に、そのファイアウォールは、サイト自体が番号を付け替えさせるのと同時に再構成される必要があるでしょう。 ファイアウォール方針がサイトの外からファイアウォールに到着するパケットに関連すると、そのようなファイアウォールは、関連するでしょう。

Rekhter & Li             Best Current Practice                 [Page 11]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[11ページ]RFC2008 1996年10月

   be reconfigured whenever an outside site that is granted any access
   inside the site through the firewall is renumbered.

外のどんなアクセスもファイアウォールを通してサイトに承諾されるサイトが番号を付け替えられるときはいつも、再構成されてください。

   It is highly inadvisable to rely upon unauthenticated source or
   destination IP addresses for security policy decisions. [Bellovin89]
   IP address spoofing is not difficult with widely available systems,
   such as personal computers.  A better approach would probably involve
   the use of IP Security techniques, such as the IP Authentication
   Header [RFC-1826] or IP Encapsulating Security Payload [RFC-1827], at
   the firewall so that the firewall can rely on cryptographic
   techniques for identification when making its security policy
   decisions.

安全保障政策決定のために非認証されたソースか送付先IPアドレスを当てにするのは非常に勧められないです。 [Bellovin89]IPアドレススプーフィングはパーソナルコンピュータなどの広く利用可能なシステムによって難しくはありません。 より良いアプローチは、安全保障政策決定をするとき、ファイアウォールが識別のための暗号のテクニックを当てにすることができるように、たぶんIP Authentication HeaderなどのIP Securityのテクニック[RFC-1826]かファイアウォールのIP Encapsulating Security有効搭載量[RFC-1827]の使用にかかわるでしょう。

   It is strongly desirable that authentication be present in any
   mechanism used to renumber IP nodes.  A renumbering mechanism that
   lacks authentication could be used by an adversary to renumber
   systems that should not have been renumbered, for example.

認証がIPノードに番号を付け替えさせるのに使用されるどんなメカニズムにも存在しているのは、強く望ましいです。 敵は、例えば番号を付け替えられるべきでなかったシステムに番号を付け替えさせるのに認証を欠いている番号を付け替えるメカニズムを使用できました。

   There may be other security considerations that are not covered in
   this document.

本書ではカバーされていない他のセキュリティ問題があるかもしれません。

9 Acknowledgments

9つの承認

   This document borrows heavily from various postings on various
   mailing lists. Special thanks to Noel Chiappa, Dennis Ferguson, Eric
   Fleischman, Geoff Huston, and Jon Postel whose postings were used in
   this document.

このドキュメントは様々なメーリングリストで様々な任命から大いに借ります。 任命が本書では使用されたクリスマスChiappa、デニスファーガソン、エリック・フライシュマン、ジェフ・ヒューストン、およびジョン・ポステルへの特別な感謝。

   Most of the Section 5.3 was contributed by Curtis Villamizar.  The
   Security section was contributed by Ran Atkinson.

セクション5.3の大部分はカーティスVillamizarによって寄付されました。 Security部はRanアトキンソンによって寄付されました。

   Many thanks to Scott Bradner, Randy Bush, Brian Carpenter, Noel
   Chiappa, David Conrad, John Curran, Sean Doran, Dorian Kim, Thomas
   Narten, Andrew Partan, Dave Piscitello, Simon Poole, Curtis
   Villamizar, and Nicolas Williams for their review, comments, and
   contributions to this document.

彼らのレビュー、コメント、およびこのドキュメントへの貢献のためにスコット・ブラドナー、ランディ・ブッシュ、ブライアンCarpenter、クリスマスChiappa、デヴィッド・コンラッド、ジョン・カラン、ショーン・ドラン、ドリアン・キム、トーマスNarten、アンドリューPartan、デーヴPiscitello、サイモン・プール、カーティスVillamizar、およびニコラス・ウィリアムズをありがとうございます。

   Finally, we like to thank all the members of the CIDR Working Group
   for their review and comments.

最終的に、私たちは、彼らのレビューとコメントについてCIDR作業部会のすべてのメンバーに感謝するのが好きです。

Rekhter & Li             Best Current Practice                 [Page 12]

RFC 2008                                                    October 1996

Rekhterと李最も良い現在の習慣[12ページ]RFC2008 1996年10月

9 References

9つの参照箇所

   [Bellovin89] Bellovin, S., "Security Problems in the TCP/IP Protocol
   Suite", ACM Computer Communications Review, Vol. 19, No. 2, March
   1989.

[Bellovin89] Bellovin、S.、「TCP/IPプロトコル群の警備上の問題」とACMコンピュータコミュニケーションは、Vol.19、1989年3月No.日2に見直します。

   [Kleinrock 77] Kleinrock, L., and K. Farouk, K., "Hierarchical
   Routing for Large Networks," Computer Networks 1 (1977), North-
   Holland Publishing Company.

[クラインロック77] クラインロック、L.とK.ファルーク、K.、「大きいネットワークのための階層型ルーティング」コンピュータネットワーク1(1977)、北部オランダ出版社。

   [Partan 95] Partan, A., private communications, October 1995.

[Partan95] Partan、A.、私信、1995年10月。

   [RFC 1541] Droms, R., "Dynamic Host Configuration Protocol", October
   1993.

[RFC1541] Droms、R.、「ダイナミックなホスト構成プロトコル」、1993年10月。

   [RFC 1519] Fuller, V., Li, T., Yu, J., and K. Varadhan, "Classless
   Inter-Domain Routing (CIDR): an Address Assignment and Aggregation
   Strategy", September 1993.

[RFC1519] フラー、V.、李、T.、ユー、J.、およびK.Varadhan、「以下を掘る(CIDR)階級のない相互ドメイン」 1993年9月の「アドレス課題と集合戦略」

   [RFC 1518] Rekhter, Y., and T. Li, "An Architecture for IP Address
   Allocation with CIDR", September 1993.

[RFC1518] Rekhter、Y.、およびT.李、「CIDRとのIPアドレス配分のためのアーキテクチャ」、1993年9月。

   [RFC 1825] Atkinson, R., "IP Security Architecture", RFC 1825, August
   1995.

[RFC1825] アトキンソン、R.、「IPセキュリティー体系」、RFC1825、1995年8月。

   [RFC 1826] Atkinson, R., "IP Authentication Header (AH), RFC 1826,
   August 1995.

[RFC1826] アトキンソン、R.、「IP認証ヘッダー(ああ)、RFC1826、1995年8月。」

   [RFC 1827] Atkinson, R., "IP Encapsulating Security Payload (ESP)",
   RFC 1827, August 1995.

[RFC1827] アトキンソン、R.、「セキュリティが有効搭載量(超能力)であるとカプセル化するIP」、RFC1827、1995年8月。

   [Villamizar 95] Villamizar, C., private communications, October 1995.

[Villamizar95] Villamizar、C.、私信、1995年10月。

10 Authors' Addresses

10人の作者のアドレス

      Yakov Rekhter
      cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134
      Phone: (914) 528-0090
      EMail: yakov@cisco.com

ヤコフRekhterコクチマスSystems Inc.170タスマンサンノゼ博士(カリフォルニア)95134電話: (914) 528-0090 メールしてください: yakov@cisco.com

      Tony Li
      cisco Systems, Inc.
      170 Tasman Dr.
      San Jose, CA 95134
      Phone: (408) 526-8186
      EMail: tli@cisco.com

トニー李コクチマスSystems Inc.170タスマンサンノゼ博士(カリフォルニア)95134電話: (408) 526-8186 メールしてください: tli@cisco.com

Rekhter & Li             Best Current Practice                 [Page 13]

Rekhterと李Best現在の習慣[13ページ]

一覧

 RFC 1〜100  RFC 1401〜1500  RFC 2801〜2900  RFC 4201〜4300 
 RFC 101〜200  RFC 1501〜1600  RFC 2901〜3000  RFC 4301〜4400 
 RFC 201〜300  RFC 1601〜1700  RFC 3001〜3100  RFC 4401〜4500 
 RFC 301〜400  RFC 1701〜1800  RFC 3101〜3200  RFC 4501〜4600 
 RFC 401〜500  RFC 1801〜1900  RFC 3201〜3300  RFC 4601〜4700 
 RFC 501〜600  RFC 1901〜2000  RFC 3301〜3400  RFC 4701〜4800 
 RFC 601〜700  RFC 2001〜2100  RFC 3401〜3500  RFC 4801〜4900 
 RFC 701〜800  RFC 2101〜2200  RFC 3501〜3600  RFC 4901〜5000 
 RFC 801〜900  RFC 2201〜2300  RFC 3601〜3700  RFC 5001〜5100 
 RFC 901〜1000  RFC 2301〜2400  RFC 3701〜3800  RFC 5101〜5200 
 RFC 1001〜1100  RFC 2401〜2500  RFC 3801〜3900  RFC 5201〜5300 
 RFC 1101〜1200  RFC 2501〜2600  RFC 3901〜4000  RFC 5301〜5400 
 RFC 1201〜1300  RFC 2601〜2700  RFC 4001〜4100  RFC 5401〜5500 
 RFC 1301〜1400  RFC 2701〜2800  RFC 4101〜4200 

スポンサーリンク

RAIDの種類

ホームページ製作・web系アプリ系の製作案件募集中です。

上に戻る