RFC1918 日本語訳

1918 Address Allocation for Private Internets. Y. Rekhter, B.Moskowitz, D. Karrenberg, G. J. de Groot, E. Lear. February 1996. (Format: TXT=22270 bytes) (Obsoletes RFC1627, RFC1597) (Also BCP0005) (Status: BEST CURRENT PRACTICE)

Network Working Group                                         Y. Rekhter
Request for Comments: 1918                                 Cisco Systems
Obsoletes: 1627, 1597                                       B. Moskowitz
BCP: 5                                                    Chrysler Corp.
Category: Best Current Practice                            D. Karrenberg
                                                                RIPE NCC
                                                          G. J. de Groot
                                                                RIPE NCC
                                                                 E. Lear
                                                  Silicon Graphics, Inc.
                                                           February 1996

Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1918 シスコシステムズは以下を時代遅れにします。 1627、1597B.マスコウィッツBCP: 5クライスラー社のCategory: 最も良いCurrent PracticeのdeグルートRIPE NCC E.リアシリコングラフィックスD.Karrenberg RIPE NCC G.J.1996年2月

                Address Allocation for Private Internets


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

1. Introduction

1. 序論

   For the purposes of this document, an enterprise is an entity
   autonomously operating a network using TCP/IP and in particular
   determining the addressing plan and address assignments within that


   This document describes address allocation for private internets. The
   allocation permits full network layer connectivity among all hosts
   inside an enterprise as well as among all public hosts of different
   enterprises. The cost of using private internet address space is the
   potentially costly effort to renumber hosts and networks between
   public and private.

このドキュメントは個人的なインターネットのためのアドレス配分について説明します。 配分は企業の中のすべてのホストの中と、そして、異なった企業のすべての公共のホストの中で完全なネットワーク層の接続性を可能にします。 個人的なインターネットアドレス空間を使用する費用は公共で個人的であることの間でホストとネットワークに番号を付け替えさせるのが潜在的に高価である取り組みです。

2. Motivation

2. 動機

   With the proliferation of TCP/IP technology worldwide, including
   outside the Internet itself, an increasing number of non-connected
   enterprises use this technology and its addressing capabilities for
   sole intra-enterprise communications, without any intention to ever
   directly connect to other enterprises or the Internet itself.


   The Internet has grown beyond anyone's expectations. Sustained
   exponential growth continues to introduce new challenges.  One
   challenge is a concern within the community that globally unique
   address space will be exhausted. A separate and far more pressing
   concern is that the amount of routing overhead will grow beyond the

インターネットはだれの期待もを超えて発展しました。 持続している急激な増加は、新しい挑戦を導入し続けています。 1つの挑戦がグローバルにユニークなアドレス空間が消耗するという共同体の中の関心です。 Aは分離します、そして、はるかに多くの差し迫った関心事はルーティングオーバーヘッドの量が余るようになるということです。

Rekhter, et al           Best Current Practice                  [Page 1]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[1ページ]RFC1918のAddress Allocation

   capabilities of Internet Service Providers. Efforts are in progress
   within the community to find long term solutions to both of these
   problems. Meanwhile it is necessary to revisit address allocation
   procedures, and their impact on the Internet routing system.

インターネットサービスプロバイダの能力。 これらの問題の両方に長期ソリューションを見つけるために、共同体の中に進行中には取り組みがあります。その間、インターネット・ルーティングシステムの上でアドレス配分手順、およびそれらの影響を再訪させるのが必要です。

   To contain growth of routing overhead, an Internet Provider obtains a
   block of address space from an address registry, and then assigns to
   its customers addresses from within that block based on each customer
   requirement. The result of this process is that routes to many
   customers will be aggregated together, and will appear to other
   providers as a single route [RFC1518], [RFC1519].  In order for route
   aggregation to be effective, Internet providers encourage customers
   joining their network to use the provider's block, and thus renumber
   their computers. Such encouragement may become a requirement in the

プロバイダは、ルーティングオーバーヘッドの成長を含むように、アドレス登録から1ブロックのアドレス空間を得て、次に、各顧客の要求に基づくそのブロックを中から顧客アドレスに割り当てます。 このプロセスの結果は多くの顧客へのルートが一緒に集められて、ただ一つのルート[RFC1518][RFC1519]として他のプロバイダーに現れるということです。 ルート集合が有効であるように、プロバイダは、彼らのネットワークに加わる顧客がプロバイダーのブロックを使用して、その結果、彼らのコンピュータに番号を付け替えさせるよう奨励します。 そのような奨励は将来、要件になるかもしれません。

   With the current size of the Internet and its growth rate it is no
   longer realistic to assume that by virtue of acquiring globally
   unique IP addresses out of an Internet registry an organization that
   acquires such addresses would have Internet-wide IP connectivity once
   the organization gets connected to the Internet. To the contrary, it
   is quite likely that when the organization would connect to the
   Internet to achieve Internet-wide IP connectivity the organization
   would need to change IP addresses (renumber) all of its public hosts
   (hosts that require Internet-wide IP connectivity), regardless of
   whether the addresses used by the organization initially were
   globally unique or not.

インターネットの現在のサイズとその成長率で、組織がいったんインターネットに関連づけられるとインターネット登録からグローバルにユニークなIPアドレスを習得することによってそのようなアドレスを習得する組織がインターネット全体のIPの接続性を持っていると仮定するのはもう現実的ではありません。 それと反対に、組織が組織がIPを変えるために必要とするインターネット全体のIPの接続性を達成するためにインターネットに接続するだろうというとき、それが公共のホスト(インターネット全体のIPの接続性を必要とするホスト)のすべてを扱うのは(番号を付け替えます)、かなりありそうです、初めは組織によって使用されたアドレスがグローバルにユニークであったかどうかにかかわらず。

   It has been typical to assign globally unique addresses to all hosts
   that use TCP/IP. In order to extend the life of the IPv4 address
   space, address registries are requiring more justification than ever
   before, making it harder for organizations to acquire additional
   address space [RFC1466].

TCP/IPを使用するすべてのホストにグローバルにユニークなアドレスを割り当てるのは典型的です。 IPv4アドレス空間の寿命を伸ばすために、アドレス登録はこれまで以上多くの正当化を必要としています、組織が追加アドレス空間[RFC1466]を取得するのをより困難にして。

   Hosts within enterprises that use IP can be partitioned into three


      Category 1: hosts that do not require access to hosts in other
                  enterprises or the Internet at large; hosts within
                  this category may use IP addresses that are
                  unambiguous within an enterprise, but may be
                  ambiguous between enterprises.

カテゴリ1: 他の企業でホストへのアクセスを必要としないホストか全体のインターネット。 このカテゴリの中のホストは、企業の中で明白なIPアドレスを使用するかもしれませんが、企業の間であいまいであるかもしれません。

      Category 2: hosts that need access to a limited set of outside
                  services (e.g., E-mail, FTP, netnews, remote login)
                  which can be handled by mediating gateways (e.g.,
                  application layer gateways). For many hosts in this
                  category an unrestricted external access (provided

カテゴリ2: ゲートウェイ(例えば、応用層ゲートウェイ)を調停することによって扱うことができる限られたセットの外のサービス(例えば、メール、FTP、ネットニュース、リモート・ログイン)へのアクセスを必要とするホスト。 無制限な外部がアクセスするこのカテゴリにおける多くのホスト、(

Rekhter, et al           Best Current Practice                  [Page 2]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[2ページ]RFC1918のAddress Allocation

                  via IP connectivity) may be unnecessary and even
                  undesirable for privacy/security reasons. Just like
                  hosts within the first category, such hosts may use
                  IP addresses that are unambiguous within an
                  enterprise, but may be ambiguous between

を通してIPの接続性) 不要であって、プライバシー/セキュリティ理由で望ましくなくさえあるかもしれません。 まさしく最初のカテゴリの中のホストのように、そのようなホストは、企業の中で明白なIPアドレスを使用するかもしれませんが、企業の間であいまいであるかもしれません。

      Category 3: hosts that need network layer access outside the
                  enterprise (provided via IP connectivity); hosts in
                  the last category require IP addresses that are
                  globally unambiguous.

カテゴリ3: 企業(IPの接続性で、提供する)の外でネットワーク層アクセスを必要とするホスト。 最後のカテゴリにおけるホストはグローバルに明白なIPアドレスを必要とします。

   We will refer to the hosts in the first and second categories as
   "private".  We will refer to the hosts in the third category as

私たちは1番目と2番目のカテゴリで「個人的である」とホストを呼ぶつもりです。 私たちは3番目のカテゴリで「公衆」とホストを呼ぶつもりです。

   Many applications require connectivity only within one enterprise and
   do not need external (outside the enterprise) connectivity for the
   majority of internal hosts. In larger enterprises it is often easy to
   identify a substantial number of hosts using TCP/IP that do not need
   network layer connectivity outside the enterprise.

多くのアプリケーションは、1つの企業だけの中で接続性を必要として、外部(企業の外の)の接続性を内部のホストの大部分に必要としません。 より大きい企業では、かなりの数のホストを特定するのは企業の外でネットワーク層の接続性を必要としないTCP/IPを使用するのにおいてしばしば簡単です。

   Some examples, where external connectivity might not be required,


         - A large airport which has its arrival/departure displays
           individually addressable via TCP/IP. It is very unlikely
           that these displays need to be directly accessible from
           other networks.

- 到着/出発を持っている大きい空港はTCP/IPで個別にアドレス可能な状態で表示します。 これらのディスプレイが、他のネットワークから直接アクセスしやすい必要があるのは、非常にありそうもないです。

         - Large organizations like banks and retail chains are
           switching to TCP/IP for their internal communication. Large
           numbers of local workstations like cash registers, money
           machines, and equipment at clerical positions rarely need
           to have such connectivity.

- 銀行と小売り店チェーンのような大きな組織はそれらの内部のコミュニケーションのためにTCP/IPに切り替わっています。 レジ、金儲けマシン、および事務員の立場での設備のような多くのローカルワークステーションはめったにそのような接続性を必要としません。

         - For security reasons, many enterprises use application
           layer gateways to connect their internal network to the
           Internet.  The internal network usually does not have
           direct access to the Internet, thus only one or more
           gateways are visible from the Internet. In this case, the
           internal network can use non-unique IP network numbers.

- 安全保障上の理由で、多くの企業が、それらの内部のネットワークをインターネットに接続するのに応用層ゲートウェイを使用します。 通常、内部のネットワークはインターネットにダイレクトに近づく手段を持っていません、その結果、複数のゲートウェイだけがインターネットから目に見えます。 この場合、内部のネットワークは非ユニークなIPネットワーク・ナンバーを使用できます。

         - Interfaces of routers on an internal network usually do not
           need to be directly accessible from outside the enterprise.

- 通常、内部のネットワークのルータのインタフェースは企業の外から直接アクセスしやすい必要はありません。

Rekhter, et al           Best Current Practice                  [Page 3]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[3ページ]RFC1918のAddress Allocation

3. Private Address Space

3. プライベート・アドレススペース

   The Internet Assigned Numbers Authority (IANA) has reserved the
   following three blocks of the IP address space for private internets:

インターネットAssigned民数記Authority(IANA)は個人的なインターネットのためのIPアドレス空間の以下の3ブロックを予約しました:        -  (10/8 prefix)      -  (172.16/12 prefix)     - (192.168/16 prefix)、--10.255 .255 .255 (10/8接頭語) 172.16 .0 .0--172.31 .255 .255 (172.16/12接頭語) 192.168 .0 .0--192.168、.255、.255(192.168/16接頭語)

   We will refer to the first block as "24-bit block", the second as
   "20-bit block", and to the third as "16-bit" block. Note that (in
   pre-CIDR notation) the first block is nothing but a single class A
   network number, while the second block is a set of 16 contiguous
   class B network numbers, and third block is a set of 256 contiguous
   class C network numbers.

私たちは「24ビットのブロック」としての最初のブロック、「20ビットのブロック」と、3番目への2番目を「16ビット」のブロックと呼ぶつもりです。 (プレCIDR記法による)の最初のブロックがただただ一つのクラスAネットワーク・ナンバーであることに注意してください、2番目のブロックは1セットの16の隣接のクラスBネットワーク・ナンバーです、そして、3番目のブロックは1セットの256の隣接のクラスCネットワーク・ナンバーですが。

   An enterprise that decides to use IP addresses out of the address
   space defined in this document can do so without any coordination
   with IANA or an Internet registry. The address space can thus be used
   by many enterprises. Addresses within this private address space will
   only be unique within the enterprise, or the set of enterprises which
   choose to cooperate over this space so they may communicate with each
   other in their own private internet.

本書では定義されたアドレス空間からIPアドレスを使用すると決める企業がIANAかインターネット登録で少しもコーディネートなしでそうできます。 その結果、多くの企業がアドレス空間を使用できます。 このプライベート・アドレススペースの中のアドレスが企業、またはこのスペースの上で協力するのを選ぶ企業のセットの中でユニークになるだけであるので、彼らはそれら自身の個人的なインターネットで互いにコミュニケートするかもしれません。

   As before, any enterprise that needs globally unique address space is
   required to obtain such addresses from an Internet registry. An
   enterprise that requests IP addresses for its external connectivity
   will never be assigned addresses from the blocks defined above.

従来と同様、グローバルにユニークなアドレス空間を必要とする企業が、インターネット登録からそのようなアドレスを得るのに必要です。 外部の接続性のためのIPアドレスを要求する企業は上で定義されたブロックから割り当てられたアドレスに決してならないでしょう。

   In order to use private address space, an enterprise needs to
   determine which hosts do not need to have network layer connectivity
   outside the enterprise in the foreseeable future and thus could be
   classified as private. Such hosts will use the private address space
   defined above.  Private hosts can communicate with all other hosts
   inside the enterprise, both public and private. However, they cannot
   have IP connectivity to any host outside of the enterprise. While not
   having external (outside of the enterprise) IP connectivity private
   hosts can still have access to external services via mediating
   gateways (e.g., application layer gateways).

プライベート・アドレススペースを使用するために、企業は、どのホストを企業の外ですぐにネットワーク層の接続性を必要として、その結果、個人的であるとして分類できなかったかを決定する必要があります。 そのようなホストは上で定義されたプライベート・アドレススペースを使用するでしょう。 個人的なホストは公立のものと同様に私設の企業の中の他のすべてのホストとコミュニケートできます。 しかしながら、彼らは企業の外にどんなホストにもIPの接続性を持つことができません。 外部(企業の外)のIPを持っていない間、ゲートウェイ(例えば、応用層ゲートウェイ)を調停することを通して接続性の個人的なホストはまだ外部サービスに近づく手段を持つことができます。

   All other hosts will be public and will use globally unique address
   space assigned by an Internet Registry. Public hosts can communicate
   with other hosts inside the enterprise both public and private and
   can have IP connectivity to public hosts outside the enterprise.
   Public hosts do not have connectivity to private hosts of other

他のすべてのホストが、公共であり、インターネットRegistryによって割り当てられたグローバルにユニークなアドレス空間を使用するでしょう。 公共のホストは、企業の中で他のホストと公共であって、かつ個人的にコミュニケートできて、企業の外に公共のホストにIPの接続性を持つことができます。 公共のホストは他の企業の個人的なホストに接続性を持っていません。

Rekhter, et al           Best Current Practice                  [Page 4]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[4ページ]RFC1918のAddress Allocation

   Moving a host from private to public or vice versa involves a change
   of IP address, changes to the appropriate DNS entries, and changes to
   configuration files on other hosts that reference the host by IP


   Because private addresses have no global meaning, routing information
   about private networks shall not be propagated on inter-enterprise
   links, and packets with private source or destination addresses
   should not be forwarded across such links. Routers in networks not
   using private address space, especially those of Internet service
   providers, are expected to be configured to reject (filter out)
   routing information about private networks. If such a router receives
   such information the rejection shall not be treated as a routing
   protocol error.

プライベート・アドレスにはどんなグローバルな意味もないので、相互企業リンクの上に私設のネットワークのルーティング情報を伝播しないものとします、そして、そのようなリンクの向こう側に個人的なソースか送付先アドレスがあるパケットを進めるべきではありません。 私設のネットワークのルーティング情報を拒絶する(無視する)ためにプライベート・アドレススペースを使用しないネットワークにおけるルータ(特にインターネット接続サービス業者のもの)が構成されると予想されます。 そのようなルータがそのような情報を受け取るなら、ルーティング・プロトコル誤りとして拒絶を扱わないものとします。

   Indirect references to such addresses should be contained within the
   enterprise. Prominent examples of such references are DNS Resource
   Records and other information referring to internal private
   addresses. In particular, Internet service providers should take
   measures to prevent such leakage.

そのようなアドレスの間接的な言及は企業の中に含まれるべきです。 そのような参照の際立った例は、内部のプライベート・アドレスを示すDNS Resource Recordsと他の情報です。 特に、インターネット接続サービス業者はそのような漏出を防ぐ対策を実施するべきです。

4. Advantages and Disadvantages of Using Private Address Space

4. プライベート・アドレススペースを使用する利点と損失

   The obvious advantage of using private address space for the Internet
   at large is to conserve the globally unique address space by not
   using it where global uniqueness is not required.


   Enterprises themselves also enjoy a number of benefits from their
   usage of private address space: They gain a lot of flexibility in
   network design by having more address space at their disposal than
   they could obtain from the globally unique pool. This enables
   operationally and administratively convenient addressing schemes as
   well as easier growth paths.

また、エンタープライズ自体はそれらのプライベート・アドレススペースの用法から多くの利益を持っています: 彼らは彼らの自由におけるそれらより多くのアドレス空間を持っているのによるデザインがグローバルにユニークなプールから得ることができたネットワークで多くの柔軟性を獲得します。 これは操作上と行政上体系を扱うことで便利でより簡単な成長経路を可能にします。

   For a variety of reasons the Internet has already encountered
   situations where an enterprise that has not been connected to the
   Internet had used IP address space for its hosts without getting this
   space assigned from the IANA. In some cases this address space had
   been already assigned to other enterprises. If such an enterprise
   would later connects to the Internet, this could potentially create
   very serious problems, as IP routing cannot provide correct
   operations in presence of ambiguous addressing. Although in principle
   Internet Service Providers should guard against such mistakes through
   the use of route filters, this does not always happen in practice.
   Using private address space provides a safe choice for such
   enterprises, avoiding clashes once outside connectivity is needed.

さまざまな理由で、インターネットは既に、インターネットに接続されない企業がホストにIANAからこのスペースを割り当てさせないでIPアドレス空間を使用した状況に遭遇しました。 いくつかの場合、このアドレス空間は既に他の企業に配属されました。 企業が後でそうするそのようなものがインターネットに接続するなら、これは非常に重大な問題を潜在的に生じさせるかもしれません、IPルーティングがあいまいなアドレシングの存在に正しい操作を提供できないとき。 インターネットサービスプロバイダは原則としてルートフィルタの使用によるそのような誤りに用心するべきですが、これは実際にはいつも起こるというわけではありません。 プライベート・アドレススペースを使用すると、外の接続性がいったん必要であると衝突を避けて、安全な選択はそのような企業に提供されます。

Rekhter, et al           Best Current Practice                  [Page 5]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[5ページ]RFC1918のAddress Allocation

   A major drawback to the use of private address space is that it may
   actually reduce an enterprise's flexibility to access the Internet.
   Once one commits to using a private address, one is committing to
   renumber part or all of an enterprise, should one decide to provide
   IP connectivity between that part (or all of the enterprise) and the
   Internet.  Usually the cost of renumbering can be measured by
   counting the number of hosts that have to transition from private to
   public. As was discussed earlier, however, even if a network uses
   globally unique addresses, it may still have to renumber in order to
   acquire Internet-wide IP connectivity.

プライベート・アドレススペースの使用への主要な欠点はインターネットにアクセスするために実際に企業の柔軟性を減少させるかもしれないということです。 人がいったんプライベート・アドレスを使用するのに公約すると、人は企業の部分かすべてに番号を付け替えさせるために公約しています、その部分(または、企業のすべて)とインターネットの間にIPの接続性を提供すると決めるなら。 通常、個人的であるのから公衆までの変遷までそうしたホストの数を数えることによって、番号を付け替えることの費用を測定できます。 それはしかしながら、ネットワークがグローバルにユニークなアドレスを使用してもより早く議論したように議論しました。まだ、インターネット全体のIPの接続性を取得するために番号を付け替えなければなりません。

   Another drawback to the use of private address space is that it may
   require renumbering when merging several private internets into a
   single private internet. If we review the examples we list in Section
   2, we note that companies tend to merge. If such companies prior to
   the merge maintained their uncoordinated internets using private
   address space, then if after the merge these private internets would
   be combined into a single private internet, some addresses within the
   combined private internet may not be unique. As a result, hosts with
   these addresses would need to be renumbered.

プライベート・アドレススペースの使用への別の欠点はいくつかの個人的なインターネットをただ一つの個人的なインターネットに合併するとき、番号を付け替えるのが必要であるかもしれないということです。 私たちがセクション2にリストアップする例を再検討するなら、私たちは、会社が、合併する傾向があることに注意します。 マージの前のそのような会社がプライベート・アドレススペースを使用することでそれらの非調整されたインターネットを維持したなら、これらの個人的なインターネットがマージの後にただ一つの個人的なインターネットに結合されるなら、結合した個人的なインターネットの中のいくつかのアドレスはユニークでないかもしれません。 その結果、これらのアドレスをもっているホストは、番号を付け替えられる必要があるでしょう。

   The cost of renumbering may well be mitigated by development and
   deployment of tools that facilitate renumbering (e.g.  Dynamic Host
   Configuration Protocol (DHCP)). When deciding whether to use private
   addresses, we recommend to inquire computer and software vendors
   about availability of such tools.  A separate IETF effort (PIER
   Working Group) is pursuing full documentation of the requirements and
   procedures for renumbering.

番号を付け替えることの費用はたぶん(例えば、Dynamic Host Configuration Protocol(DHCP))に番号を付け替えさせるのを容易にするツールの開発と展開で緩和されるでしょう。 プライベート・アドレスを使用するかどうか決めるとき、私たちは、そのようなツールの有用性に関してコンピュータとソフトウェアベンダーについて問い合わせることを勧めます。 別々のIETF取り組み(PIER作業部会)は番号を付け替える要件と手順の追求している完全なドキュメンテーションです。

5. Operational Considerations

5. 操作上の問題

   One possible strategy is to design the private part of the network
   first and use private address space for all internal links. Then plan
   public subnets at the locations needed and design the external

1つの可能な戦略は、最初に、ネットワークの個人的な部分を設計して、すべての内部のリンクにプライベート・アドレススペースを使用することです。 次に、必要である位置で公共のサブネットを計画してください、そして、外部の接続性を設計してください。

   This design does not need to be fixed permanently. If a group of one
   or more hosts requires to change their status (from private to public
   or vice versa) later, this can be accomplished by renumbering only
   the hosts involved, and changing physical connectivity, if needed. In
   locations where such changes can be foreseen (machine rooms, etc.),
   it is advisable to configure separate physical media for public and
   private subnets to facilitate such changes.  In order to avoid major
   network disruptions, it is advisable to group hosts with similar
   connectivity needs on their own subnets.

永久に、このデザインは修理される必要はありません。 または、1人以上のホストのグループが彼らの状態を変化に必要とする、(個人的であるのから公衆、逆もまた同様に)、後でかかわって、物理的な接続性を変えるホストだけに番号を付け替えさせることによって、これを達成できます、必要であるなら。 そのような変化について見通すことができる位置(マシン部屋など)では、公共の、そして、個人的なサブネットがそのような変化を容易にするように別々の物理的なメディアを構成するのが賢明です。 主要なネットワーク分裂を避けるために、それら自身のサブネットに関する同様の接続性の必要性をもっているホストを分類するのは賢明です。

Rekhter, et al           Best Current Practice                  [Page 6]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[6ページ]RFC1918のAddress Allocation

   If a suitable subnetting scheme can be designed and is supported by
   the equipment concerned, it is advisable to use the 24-bit block
   (class A network) of private address space and make an addressing
   plan with a good growth path. If subnetting is a problem, the 16-bit
   block (class C networks), or the 20-bit block (class B networks) of
   private address space can be used.

適当なサブネッティング体系が設計できて、関する設備によってサポートされるなら、プライベート・アドレススペースの24ビットのブロック(クラスAネットワーク)を使用して、良い成長経路でアドレシングプランを立てるのは賢明です。 サブネッティングが問題であるなら、16ビットのブロック(クラスCネットワーク)、または20ビットのブロック(クラスBネットワーク)のプライベート・アドレススペースを使用できます。

   One might be tempted to have both public and private addresses on the
   same physical medium. While this is possible, there are pitfalls to
   such a design (note that the pitfalls have nothing to do with the use
   of private addresses, but are due to the presence of multiple IP
   subnets on a common Data Link subnetwork).  We advise caution when
   proceeding in this area.

1つには公共のものと同じ物理的な媒体に関する同様に個人的なアドレスがあるように誘惑されるかもしれません。 これは可能ですが、そのようなデザイン(落とし穴がプライベート・アドレスの使用と関係ないことに注意しますが、一般的なData Linkサブネットワークの上の複数のIPサブネットの存在のために、ある)への落とし穴があります。 この領域で続くとき、私たちは警告を教えます。

   It is strongly recommended that routers which connect enterprises to
   external networks are set up with appropriate packet and routing
   filters at both ends of the link in order to prevent packet and
   routing information leakage. An enterprise should also filter any
   private networks from inbound routing information in order to protect
   itself from ambiguous routing situations which can occur if routes to
   the private address space point outside the enterprise.

外部のネットワークに企業を接続するルータがパケットとルーティング情報漏出を防ぐためにリンクの両端で適切なパケットとルーティングフィルタでセットアップされることが強く勧められます。 また、企業は、プライベート・アドレススペースへのルートが企業の外に示されるなら起こることができるあいまいなルーティング状況から我が身をかばうためにインバウンド・ルーティング情報からどんな私設のネットワークもフィルターにかけるべきです。

   It is possible for two sites, who both coordinate their private
   address space, to communicate with each other over a public network.
   To do so they must use some method of encapsulation at their borders
   to a public network, thus keeping their private addresses private.

2つのサイトに、公衆通信回線の上で互いにコミュニケートするのは可能です。(ともに、サイトはそれらのプライベート・アドレススペースを調整します)。 そうするのに、彼らは自分達の境界でカプセル化の何らかのメソッドを公衆通信回線に使用しなければなりません、その結果、それらのプライベート・アドレスを個人的に保管します。

   If two (or more) organizations follow the address allocation
   specified in this document and then later wish to establish IP
   connectivity with each other, then there is a risk that address
   uniqueness would be violated.  To minimize the risk it is strongly
   recommended that an organization using private IP addresses choose
   randomly from the reserved pool of private addresses, when allocating
   sub-blocks for its internal allocation.

2つ(さらに)の組織は違反されていた状態で本書では指定されたアドレス配分に続いて、次に、次に互いと共にIPの接続性を確立するというアドレスのユニークさがリスクであるだろうというのにもかかわらずの、ある後の願望に続くなら。 内部の配分のためのサブブロックを割り当てるとき、危険を最小にするために、プライベートIPアドレスを使用する組織がプライベート・アドレスの予約されたプールから手当たりしだいに選ばれることが強く勧められます。

   If an enterprise uses the private address space, or a mix of private
   and public address spaces, then DNS clients outside of the enterprise
   should not see addresses in the private address space used by the
   enterprise, since these addresses would be ambiguous.  One way to
   ensure this is to run two authority servers for each DNS zone
   containing both publically and privately addressed hosts.  One server
   would be visible from the public address space and would contain only
   the subset of the enterprise's addresses which were reachable using
   public addresses.  The other server would be reachable only from the
   private network and would contain the full set of data, including the
   private addresses and whatever public addresses are reachable the
   private network.  In order to ensure consistency, both servers should
   be configured from the same data of which the publically visible zone

企業がプライベート・アドレススペース、または個人的で公共のアドレス空間のミックスを使用するなら、企業の外部がアドレスを見るべきでないこれらのアドレス以来プライベート・アドレススペースが企業で使用したDNSクライアントはあいまいでしょう。 これを確実にする1つの方法はホストであるとpublicallyと個人的に扱われた両方を含むそれぞれのDNSゾーンあたり2つの権威サーバを実行することです。 1つのサーバが、場内放送スペースから目に見えて、企業の場内放送を使用することで届いているアドレスの部分集合だけを含んでいるでしょう。 もう片方のサーバは、単に私設のネットワークから届いて、データのフルセットを含んでいるでしょう、個人的がプライベート・アドレスとどんな届いている場内放送もネットワークでつないでも包含して。 一貫性があることを保証するために、両方のサーバは目に見えるpublicallyが帯状になるのと同じデータから構成されるべきです。

Rekhter, et al           Best Current Practice                  [Page 7]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[7ページ]RFC1918のAddress Allocation

   only contains a filtered version. There is certain degree of
   additional complexity associated with providing these capabilities.

フィルターにかけることのバージョンを含むだけです。 これらの能力を提供すると関連している追加複雑さのある度合いがあります。

6. Security Considerations

6. セキュリティ問題

   Security issues are not addressed in this memo.


7. Conclusion

7. 結論

   With the described scheme many large enterprises will need only a
   relatively small block of addresses from the globally unique IP
   address space. The Internet at large benefits through conservation of
   globally unique address space which will effectively lengthen the
   lifetime of the IP address space. The enterprises benefit from the
   increased flexibility provided by a relatively large private address
   space. However, use of private addressing requires that an
   organization renumber part or all of its enterprise network, as its
   connectivity requirements change over time.

説明された体系が多い場合、大企業はグローバルにユニークなIPアドレス空間からのアドレスの比較的わずかなブロックだけを必要とするでしょう。 事実上、IPアドレス空間の生涯を伸すグローバルにユニークなアドレス空間の保護による大きい利益におけるインターネット。 企業は比較的大きいプライベート・アドレススペースによって提供された増強された柔軟性の利益を得ます。 しかしながら、個人的なアドレシングの使用は、組織が企業網の部分かすべてに番号を付け替えさせるのを必要とします、接続性要件が時間がたつにつれて変化するとき。

8. Acknowledgments

8. 承認

   We would like to thank Tony Bates (MCI), Jordan Becker (ANS), Hans-
   Werner Braun (SDSC), Ross Callon (BayNetworks), John Curran (BBN
   Planet), Vince Fuller (BBN Planet), Tony Li (cisco Systems), Anne
   Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (BayNetworks),
   Geza Turchanyi (RIPE NCC), Christophe Wolfhugel (Pasteur Institute),
   Andy Linton (connect.com.au), Brian Carpenter (CERN), Randy Bush
   (PSG), Erik Fair (Apple Computer), Dave Crocker (Brandenburg
   Consulting), Tom Kessler (SGI), Dave Piscitello (Core Competence),
   Matt Crawford (FNAL), Michael Patton (BBN), and Paul Vixie (Internet
   Software Consortium) for their review and constructive comments.

トニー・ベイツ(MCI)に感謝申し上げます、ハンスヴェルナーBraun(SDSC)、ジョーダン・ベッカー(ANS)、ロスCallon(BayNetworks)、ジョン・カラン(BBN Planet)、ビンス・フラー(BBN Planet)、トニー・李(コクチマスSystems)、アン主(RIPE NCC)、ミロ・メディン(NSI)、Martenテルプストラ(BayNetworks)、ゲザTurchanyi(RIPE NCC)、クリストフWolfhugel(パストゥール研究所); 彼らのレビューと建設的なコメントのためのアンディLinton(connect.com.au)、ブライアンCarpenter(CERN)、ランディ・ブッシュ(PSG)、エリックFair(アップル・コンピューター)、デーヴ・クロッカー(ブランデンブルクConsulting)、トム・ケスラー(SGI)、デーヴPiscitello(コアCompetence)、マット・クロフォード(FNAL)、マイケル・パットン(BBN)、およびポールVixie(インターネットSoftware Consortium)。

9. References

9. 参照

   [RFC1466] Gerich, E., "Guidelines for Management of IP Address
       Space", RFC 1466, Merit Network, Inc., May 1993.


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

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

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

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

Rekhter, et al           Best Current Practice                  [Page 8]

RFC 1918        Address Allocation for Private Internets   February 1996

Rekhter、兵士のInternets1996年2月のための他Best Current Practice[8ページ]RFC1918のAddress Allocation

10. Authors' Addresses

10. 作者のアドレス

   Yakov Rekhter
   Cisco systems
   170 West Tasman Drive
   San Jose, CA, USA
   Phone: +1 914 528 0090
   Fax: +1 408 526-4952
   EMail: yakov@cisco.com

ヤコフRekhterシスコシステム170の西タスマンDriveサンノゼ(カリフォルニア)(米国)Phone: +1 914 528、0090Fax: +1 408 526-4952 メールしてください: yakov@cisco.com

   Robert G Moskowitz
   Chrysler Corporation
   CIMS: 424-73-00
   25999 Lawrence Ave
   Center Line, MI 48015
   Phone: +1 810 758 8212
   Fax: +1 810 758 8173
   EMail: rgm3@is.chrysler.com

ロバートGマスコウィッツクライスラー社のCIMS: 424-73-00 25999 ローレンスAveは線、マイル48015電話を中心に置きます: +1 810 758、8212Fax: +1 8173年の810 758メール: rgm3@is.chrysler.com

   Daniel Karrenberg
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: Daniel.Karrenberg@ripe.net

SJアムステルダム(オランダ)が電話をするダニエルKarrenbergの熟しているネットワークコーディネートセンターKruislaan409 1098: +31 20 592 5065Fax: +31 20 592 5090はメールされます: Daniel.Karrenberg@ripe.net

   Geert Jan de Groot
   RIPE Network Coordination Centre
   Kruislaan 409
   1098 SJ Amsterdam, the Netherlands
   Phone: +31 20 592 5065
   Fax: +31 20 592 5090
   EMail: GeertJan.deGroot@ripe.net

ヘールトジャンdeグルートRIPE Network Coordination Centre Kruislaan409 1098SJアムステルダム(オランダ)電話: +31 20 592 5065Fax: +31 20 592 5090はメールされます: GeertJan.deGroot@ripe.net

   Eliot Lear
   Mail Stop 15-730
   Silicon Graphics, Inc.
   2011 N. Shoreline Blvd.
   Mountain View, CA 94043-1389
   Phone: +1 415 960 1980
   Fax:   +1 415 961 9584
   EMail: lear@sgi.com

エリオットリア・メール停止15-730シリコングラフィックス2011N.海岸線Blvd. マウンテンビュー、カリフォルニア94043-1389は以下に電話をします。 +1 415 960、1980Fax: +1 9584年の415 961メール: lear@sgi.com

Rekhter, et al           Best Current Practice                  [Page 9]

Rekhter、他のBest Current Practice[9ページ]



 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