RFC1597 日本語訳
1597 Address Allocation for Private Internets. Y. Rekhter, B.Moskowitz, D. Karrenberg, G. de Groot. March 1994. (Format: TXT=17430 bytes) (Obsoleted by RFC1918) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group Y. Rekhter Request for Comments: 1597 T.J. Watson Research Center, IBM Corp. Category: Informational B. Moskowitz Chrysler Corp. D. Karrenberg RIPE NCC G. de Groot RIPE NCC March 1994
Rekhterがコメントのために要求するワーキンググループY.をネットワークでつないでください: 1597 T.J.ワトソン研究所、IBM社のカテゴリ: 1994年の情報のB.のNCCのG.deグルートのRIPE NCCマスコウィッツのクライスラーの社のD.Karrenberg RIPE行進
Address Allocation for Private Internets
個人的なインターネットのためのアドレス配分
Status of this Memo
このMemoの状態
This memo provides information for the Internet community. This memo does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 このメモはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
1. Introduction
1. 序論
This RFC describes methods to preserve IP address space by not allocating globally unique IP addresses to hosts private to an enterprise while still permitting full network layer connectivity between all hosts inside an enterprise as well as between all public hosts of different enterprises. The authors hope, that using these methods, significant savings can be made on allocating IP address space.
このRFCはまだ企業の中のすべてのホストと異なった企業のすべての公共のホストの間の完全なネットワーク層の接続性を可能にしている間、グローバルにユニークなIPアドレスを企業に個人的なホストに割り当てないことによってIPアドレス空間を保存するメソッドを説明します。 それがこれらのメソッドを使用して、作者は望んでいて、IPアドレス空間を割り当てるとき、重要な貯蓄は作ることができます。
For the purposes of this memo, an enterprise is an entity autonomously operating a network using TCP/IP and in particular determining the addressing plan and address assignments within that network.
このメモの目的のために、企業はTCP/IPを使用することで自主的にネットワークを経営していて、そのネットワークの中でアドレシングプランとアドレス課題を特に決定する実体です。
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.
世界中のインターネットの外にそれ自体を含むTCP/IP技術の増殖で、増加する数の非接続された企業が唯一のイントラ企業コミュニケーションにこの技術とそのアドレス指定能力を使用します、今までに直接他の企業かインターネット自体に接続するという少しも意志なしで。
The current practice is to assign globally unique addresses to all hosts that use TCP/IP. There is a growing concern that the finite IP address space might become exhausted. Therefore, the guidelines for assigning IP address space have been tightened in recent years [1]. These rules are often more conservative than enterprises would like, in order to implement and operate their networks.
現在の習慣はTCP/IPを使用するすべてのホストにグローバルにユニークなアドレスを割り当てることになっています。 有限IPアドレス空間が疲れ果てるようになるかもしれないという増加している関心があります。 したがって、IPアドレス空間を割り当てるためのガイドラインは近年[1]きびしくされました。 これらの規則は、それらのネットワークを実装して、経営するために企業が好きであるだろうというよりもしばしば保守的です。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 1] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[1ページ]RFC1597Address Allocation
Hosts within enterprises that use IP can be partitioned into three categories:
IPを使用する企業の中のホストを3つのカテゴリに仕切ることができます:
- hosts that do not require access to hosts in other enterprises or the Internet at large;
- 他の企業でホストへのアクセスを必要としないホストか全体のインターネット。
- hosts that need access to a limited set of outside services (e.g., E-mail, FTP, netnews, remote login) which can be handled by application layer gateways;
- アプリケーションで扱うことができる限られたセットの外のサービス(例えば、メール、FTP、ネットニュース、リモート・ログイン)へのアクセスを必要とするホストがゲートウェイを層にします。
- hosts that need network layer access outside the enterprise (provided via IP connectivity);
- 企業(IPの接続性で、提供する)の外でネットワーク層アクセスを必要とするホスト。
- hosts within the first category may use IP addresses that are unambiguous within an enterprise, but may be ambiguous between enterprises.
- 最初のカテゴリの中のホストは、企業の中で明白なIPアドレスを使用するかもしれませんが、企業の間であいまいであるかもしれません。
For many hosts in the second category an unrestricted external access (provided 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 enterprises.
2番目のカテゴリにおける多くのホストにとって、無制限な外部のアクセス(IPの接続性で、提供する)は、不要であって、プライバシー/セキュリティ理由で望ましくなくさえあるかもしれません。 まさしく最初のカテゴリの中のホストのように、そのようなホストは、企業の中で明白なIPアドレスを使用するかもしれませんが、企業の間であいまいであるかもしれません。
Only hosts in the last category require IP addresses that are globally unambiguous.
最後のカテゴリにおけるホストだけがグローバルに明白なIPアドレスを必要とします。
Many applications require connectivity only within one enterprise and do not even need external 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, are:
外部の接続性は必要でないかもしれないところでいくつかの例が以下の通りです。
- 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 organisations 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に切り替わっています。 レジ、金儲けマシン、および事務員の立場での設備のような多くのローカルワークステーションはめったにそのような接続性を必要としません。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 2] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[2ページ]RFC1597Address Allocation
- For security reasons, many enterprises use application layer gateways (e.g., firewalls) 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 firewall hosts are visible from the Internet. In this case, the internal network can use non-unique IP numbers.
- 安全保障上の理由で、多くの企業が、それらの内部のネットワークをインターネットに接続するのに、応用層ゲートウェイ(例えば、ファイアウォール)を使用します。 通常、内部のネットワークはインターネットにダイレクトに近づく手段を持っていません、その結果、1人以上のファイアウォールホストだけがインターネットから目に見えます。 この場合、内部のネットワークは非ユニークなIP番号を使用できます。
- If two enterprises communicate over their own private link, usually only a very limited set of hosts is mutually reachable from the other enterprise over this link. Only those hosts need globally unique IP numbers.
- 2つの企業がそれら自身の個人的なリンクの上に交信するなら、通常、非常に限られたセットのホストだけがこのリンクの上のもう片方の企業から互いに届いています。 それらのホストだけがグローバルにユニークなIP番号を必要とします。
- Interfaces of routers on an internal network usually do not need to be directly accessible from outside the enterprise.
- 通常、内部のネットワークのルータのインタフェースは企業の外から直接アクセスしやすい必要はありません。
3. Private Address Space
3. プライベート・アドレススペース
The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks:
インターネットAssigned民数記Authority(IANA)は私設のネットワークのためのIPアドレス空間の以下の3ブロックを予約しました:
10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
10.0.0.0 - 10.255.255.255 172.16.0.0 - 172.31.255.255 192.168.0.0 - 192.168.255.255
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 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 255 contiguous class C network numbers.
私たちが「24ビットのブロック」、秒と最初のブロックを呼ぶために望んでいる、「20ビットは、妨げて、「16ビット」としての3日妨げます」。 最初のブロックがただただ一つのクラスAネットワーク・ナンバーであることに注意してください、2番目のブロックは1セットの16の隣接のクラスBネットワーク・ナンバーです、そして、3番目のブロックは1セットの255の隣接のクラス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.
本書では定義されたアドレス空間から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. Such hosts will be called private hosts, and 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 external host. While not having external network
プライベート・アドレススペースを使用するために、企業は、どのホストが企業の外ですぐにネットワーク層の接続性を必要としないかを決定する必要があります。 そのようなホストは、個人的なホストと呼ばれて、上で定義されたプライベート・アドレススペースを使用するでしょう。 個人的なホストは公立のものと同様に私設の企業の中の他のすべてのホストとコミュニケートできます。 しかしながら、彼らはどんな外部のホストにもIPの接続性を持つことができません。 どんな有の外部のネットワークもゆったり過ごさないでください。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 3] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[3ページ]RFC1597Address Allocation
layer connectivity private hosts can still have access to external services via application layer relays.
応用層リレーで層の接続性個人的なホストはまだ外部サービスに近づく手段を持つことができます。
All other hosts will be called 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 external public hosts. Public hosts do not have connectivity to private hosts of other enterprises.
他のすべてのホストが、公共であると呼ばれて、インターネットRegistryによって割り当てられたグローバルにユニークなアドレス空間を使用するでしょう。 公共のホストは、企業の中で他のホストと公共であって、かつ個人的にコミュニケートできて、外部の公共のホストにIPの接続性を持つことができます。 公共のホストは他の企業の個人的なホストに接続性を持っていません。
Moving a host from private to public or vice versa involves a change of IP address.
個人的であるのから公衆まで逆もまた同様にホストを動かすと、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 between 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. When such an enterprise later connects to the Internet, it could potentially create very
インターネットが既に遭遇したさまざまな理由で、IANAからこのスペースを割り当てさせないで、それが間でないのに持っている企業がインターネットに接続した状況はホストにIPアドレス空間を使用しました。 いくつかの場合、このアドレス空間は既に他の企業に配属されました。 そのような企業が後でインターネットに接続するとき、潜在的に接続できた、まさしくそのである、作成します。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 4] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[4ページ]RFC1597Address Allocation
serious problems, as IP routing cannot provide correct operations in presence of ambiguous addressing. Using private address space provides a safe choice for such enterprises, avoiding clashes once outside connectivity is needed.
深刻な問題であり、IPとして、ルーティングはあいまいなアドレシングの存在に正しい操作を提供できません。 プライベート・アドレススペースを使用すると、外の接続性がいったん必要であると衝突を避けて、安全な選択はそのような企業に提供されます。
One could argue that the potential need for renumbering represents a significant drawback of using the addresses out of the block allocated for private internets. However, we need to observe that the need is only "potential", since many hosts may never move into the third category, and an enterprise may never decide to interconnect (at IP level) with another enterprise.
1つは、番号を付け替えることの潜在的必要性が個人的なインターネットのために割り当てられたブロックからアドレスを使用する重要な欠点を表すと主張するかもしれません。 しかしながら、私たちは、必要性が「潜在的であるだけである」と述べる必要があります、多くのホストが3番目のカテゴリに決して移行しないかもしれなくて、また企業が、別の企業と共に内部連絡する(IPレベルで)と決して決めないかもしれないので。
But even if renumbering has to happen, we have to observe that with Classless Inter-Domain Routing (CIDR) an enterprise that is connected to the Internet may be encouraged to renumber its public hosts, as it changes its Network Service Providers. Thus renumbering is likely to happen more often in the future, regardless of whether an enterprise does or does not use the addresses out of the block allocated for private networks. Tools to facilitate renumbering (e.g., DHCP) would certainly make it less of a concern.
しかし、番号を付け替えることが起きるべくして起きても、私たちは、Classless Inter-ドメインルート設定(CIDR)で、インターネットに接続される計画が公共のホストに番号を付け替えさせるよう奨励されるかもしれないのを観測しなければなりません、Network Service Providersを変えるとき。 したがって、番号を付け替えるのは将来よりしばしば起こりそうです、企業がするか、または私設のネットワークのために割り当てられたブロックからアドレスを使用しないことにかかわらず。 確かに、(例えば、DHCP)に番号を付け替えさせるのを容易にするツールで、それは関心で、より少なくなるでしょう。
Also observe that the clear division of public and private hosts and the resulting need to renumber makes uncontrolled outside connectivity more difficult, so to some extend the need to renumber could be viewed as an advantage.
また、利点として公共の、そして、個人的なホストの明確な分割と接続性の外で非制御の造により難しい状態で番号を付け替えさせるので番号を付け替えさせる必要性をいくつかに申し上げる結果として起こる必要性を見なすことができたのを観測してください。
5. Operational Considerations
5. 操作上の問題
A recommended 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 connectivity.
お勧めの戦略は、最初に、ネットワークの個人的な部分を設計して、すべての内部のリンクにプライベート・アドレススペースを使用することです。 次に、必要である位置で公共のサブネットを計画してください、そして、外部の接続性を設計してください。
This design is not fixed permanently. If a number of hosts require to change status later this can be accomplished by renumbering only the hosts involved and installing another physical subnet if required.
このデザインは永久に、修理されていません。 多くのホストが、後で状態を変えるのを必要とするなら、必要なら、かかわって、別の物理的なサブネットをインストールしているホストだけに番号を付け替えさせることによって、これを達成できます。
If a suitable subnetting scheme can be designed and is supported by the equipment concerned, it is advisable to use the 24-bit block of private address space and make an addressing plan with a good growth path. If subnetting is a problem, the 16-bit class C block, which consists of 255 contiguous class C network numbers, can be used.
適当なサブネッティング体系が設計できて、関する設備によってサポートされるなら、プライベート・アドレススペースの24ビットのブロックを使用して、良い成長経路でアドレシングプランを立てるのは賢明です。 サブネッティングが問題であるなら、16ビットのクラスCブロック(255の隣接のクラスCネットワーク・ナンバーから成る)を使用できます。
Using multiple IP (sub)nets on the same physical medium has many pitfalls. We recommend to avoid it unless the operational problems are well understood and it is proven that all equipment supports this properly.
同じ物理的な媒体の上の複数のIP(潜水艦)ネットを使用するのにおいて、多くの落とし穴があります。 運転上の問題がよく理解されて、すべての設備が適切にこれをサポートすると立証されない場合、私たちは、それを避けることを勧めます。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 5] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[5ページ]RFC1597Address Allocation
Moving a single host between private and public status will involve a change of address and in most cases physical connectivity. In locations where such changes can be foreseen (machine rooms etc.) it may be advisable to configure separate physical media for public and private subnets to facilitate such changes.
独身のホストを個人的で公共の状態の間に動かすと、住所の変更と多くの場合物理的な接続性はかかわるでしょう。 そのような変化について見通すことができる位置(マシン部屋など)では、公共の、そして、個人的なサブネットがそのような変化を容易にするように別々の物理的なメディアを構成するのが賢明であるかもしれません。
Changing the status of all hosts on a whole (sub)network can be done easily and without disruption for the enterprise network as a whole. Consequently it is advisable to group hosts whose connectivity needs might undergo similar changes in the future on their own subnets.
全体の(潜水艦)ネットワークのすべてのホストの状態を変えるのが容易にして全体で企業網のための分裂なしであることができます。 その結果、接続性の必要性が将来それら自身のサブネットで同様の変化をするかもしれないホストを分類するのは賢明です。
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.
外部のネットワークに企業を接続するルータがパケットとルーティング情報漏出を防ぐためにリンクの両端で適切なパケットとルーティングフィルタでセットアップされることが強く勧められます。 また、企業は、プライベート・アドレススペースへのルートが企業の外に示されるなら起こることができるあいまいなルーティング状況から我が身をかばうためにインバウンド・ルーティング情報からどんな私設のネットワークもフィルターにかけるべきです。
Groups of organisations which foresee a big need for mutual communication can consider forming an enterprise by designing a common addressing plan supported by the necessary organisational arrangements like a registry.
相互交信の大きい必要性について見通す機構のグループは、登録のように必要なorganisationalアレンジメントでサポートされた一般的なアドレシングプランを設計することによって企業を形成すると考えることができます。
If two sites of the same enterprise need to be connected using an external service provider, they can consider using an IP tunnel to prevent packet leaks form the private network.
同じ企業の2つのサイトが、外部サービスプロバイダーを使用することで接続される必要があるなら、それらは、防ぐIPトンネルを使用して、パケット漏出が私設のネットワークを形成すると考えることができます。
A possible approach to avoid leaking of DNS RRs is to run two nameservers, one external server authoritative for all globally unique IP addresses of the enterprise and one internal nameserver authoritative for all IP addresses of the enterprise, both public and private. In order to ensure consistency both these servers should be configured from the same data of which the external nameserver only receives a filtered version.
DNS RRsを漏れさせるのを避ける可能なアプローチは企業のすべてのIPアドレスに正式で、かつ公共で、かつ個人的に2つのネームサーバ、企業のすべてのグローバルにユニークなIPアドレスに、正式の1つの外部のサーバ、および1つの内部のネームサーバを実行することです。 一貫性があることを保証するために、これらのサーバの両方が外部のネームサーバがフィルターにかけることのバージョンを受けるだけであるのと同じデータから構成されるべきです。
The resolvers on all internal hosts, both public and private, query only the internal nameserver. The external server resolves queries from resolvers outside the enterprise and is linked into the global DNS. The internal server forwards all queries for information outside the enterprise to the external nameserver, so all internal hosts can access the global DNS. This ensures that information about private hosts does not reach resolvers and nameservers outside the enterprise.
すべての内部のホストの上の公共の、そして、かつ個人的なレゾルバは、内部のネームサーバだけについて質問します。外部のサーバは、企業の外でレゾルバから質問を決議して、グローバルなDNSにリンクされます。 内部のサーバが外部のネームサーバへの企業の外に情報のためのすべての質問を送るので、すべての内部のホストがグローバルなDNSにアクセスできます。 これは、個人的なホストの情報が企業の外でレゾルバとネームサーバに届かないのを確実にします。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 6] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[6ページ]RFC1597Address Allocation
6. References
6. 参照
[1] Gerich, E., "Guidelines for Management of IP Address Space", RFC 1466, Merit Network, Inc., May 1993.
[1] Gerich(E.、「IP管理アドレス空間のためのガイドライン」、RFC1466)はネットワークInc.、1993年5月に値します。
7. Security Considerations
7. セキュリティ問題
While using private address space can improve security, it is not a substitute for dedicated security measures.
プライベート・アドレスを使用している間、スペースはセキュリティを向上させることができて、それはひたむきな安全策の代用品ではありません。
8. Conclusion
8. 結論
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.
説明された体系が多い場合、大企業はグローバルにユニークなIPアドレス空間からのアドレスの比較的わずかなブロックだけを必要とするでしょう。 事実上、IPアドレス空間の生涯を伸すグローバルにユニークなアドレス空間の保護による大きい利益におけるインターネット。 企業は比較的大きいプライベート・アドレススペースによって提供された増強された柔軟性の利益を得ます。
9. Acknowledgments
9. 承認
We would like to thank Tony Bates (RIPE NCC), Jordan Becker (ANS), Hans-Werner Braun (SDSC), Ross Callon (Wellfleet), John Curran (NEARNET), Vince Fuller (Barrnet), Tony Li (cisco Systems), Anne Lord (RIPE NCC), Milo Medin (NSI), Marten Terpstra (RIPE NCC), and Geza Turchanyi (RIPE NCC) for their review and constructive comments.
彼らのレビューと建設的なコメントについてトニー・ベイツ(RIPE NCC)、ジョーダン・ベッカー(ANS)、ハンス-ヴェルナーBraun(SDSC)、ロスCallon(Wellfleet)、ジョン・カラン(NEARNET)、ビンス・フラー(Barrnet)、トニー・李(コクチマスSystems)、アン主(RIPE NCC)、ミロ・メディン(NSI)、Martenテルプストラ(RIPE NCC)、およびゲザTurchanyi(RIPE NCC)に感謝申し上げます。
Rekhter, Moskowitz, Karrenberg & de Groot [Page 7] RFC 1597 Address Allocation for Private Internets March 1994
兵士のInternets March1994のためのRekhter、マスコウィッツ、Karrenberg、およびdeグルート[7ページ]RFC1597Address Allocation
10. Authors' Addresses
10. 作者のアドレス
Yakov Rekhter T.J. Watson Research Center, IBM Corp. P.O. Box 218 Yorktown Heights, NY, 10598
ヤコフRekhter T.J.ワトソン研究所、IBM社の私書箱218ヨークタウンの高さ、ニューヨーク 10598
Phone: +1 914 945 3896 Fax: +1 914 945 2141 EMail: yakov@watson.ibm.com
以下に電話をしてください。 +1 914 945、3896Fax: +1 2141年の914 945メール: yakov@watson.ibm.com
Robert G Moskowitz Chrysler Corporation CIMS: 424-73-00 25999 Lawrence Ave Center Line, MI 48015
ロバートGマスコウィッツクライスラー社のCIMS: 424-73-00 25999 MI ローレンスAveセンタライン、48015
Phone: +1 810 758 8212 Fax: +1 810 758 8173 EMail: 3858921@mcimail.com
以下に電話をしてください。 +1 810 758、8212Fax: +1 8173年の810 758メール: 3858921@mcimail.com
Daniel Karrenberg RIPE Network Coordination Centre Kruislaan 409 1098 SJ Amsterdam, the Netherlands
ダニエルKarrenbergの熟しているネットワークコーディネートセンターKruislaan409 1098SJアムステルダム(オランダ)
Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: Daniel.Karrenberg@ripe.net
以下に電話をしてください。 +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
ヘールトジャンdeグルートRIPE Network Coordination Centre Kruislaan409 1098SJアムステルダム(オランダ)
Phone: +31 20 592 5065 Fax: +31 20 592 5090 EMail: GeertJan.deGroot@ripe.net
以下に電話をしてください。 +31 20 592 5065Fax: +31 20 592 5090はメールされます: GeertJan.deGroot@ripe.net
Rekhter, Moskowitz, Karrenberg & de Groot [Page 8]
Rekhter、マスコウィッツ、Karrenberg、およびdeグルート[8ページ]
一覧
スポンサーリンク