RFC 6319 - Issues Associated with Designating Additional Private IPv4 Address Space 日本語訳

URL : https://tools.ietf.org/html/rfc6319
タイトル : RFC 6319 - 追加のプライベートIPv4アドレス空間の指定に関連する問題
翻訳編集 : 自動生成

Internet Engineering Task Force (IETF)                        M. Azinger
Request for Comments: 6319                       Frontier Communications
Category: Informational                                      Corporation
ISSN: 2070-1721                                                L. Vegoda
                                                                   ICANN
                                                               July 2011

                         Issues Associated with
           Designating Additional Private IPv4 Address Space

Abstract

抽象

When a private network or internetwork grows very large, it is sometimes not possible to address all interfaces using private IPv4 address space because there are not enough addresses. This document describes the problems faced by those networks, the available options, and the issues involved in assigning a new block of private IPv4 address space.

プライベートネットワークまたはインターネットワークは非常に大きくなると、十分なアドレスがないので、プライベートIPv4アドレス空間を使用して、すべてのインターフェイスに対応できない場合があります。この文書では、これらのネットワークが直面する問題、利用可能なオプション、およびプライベートIPv4アドレス空間の新しいブロックを割り当てるに関わる問題について説明します。

While this informational document does not make a recommendation for action, it documents the issues surrounding the various options that have been considered.

この情報のドキュメントは、行動のための勧告を行うわけではありませんが、それは考慮されているさまざまなオプションを取り巻く問題に関して説明しています。

Status of This Memo

このメモのステータス

This document is not an Internet Standards Track specification; it is published for informational purposes.

このドキュメントはインターネット標準化過程仕様ではありません。それは、情報提供の目的のために公開されています。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.

このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 IESGによって承認されていないすべての文書がインターネットStandardのどんなレベルの候補です。 RFC 5741のセクション2を参照してください。

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6319.

このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6319で取得することができます。

著作権表示

著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

この文書では、BCP 78と、この文書の発行日に有効なIETFドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  Large Networks . . . . . . . . . . . . . . . . . . . . . . . .  3
   3.  Non-Unique Addresses . . . . . . . . . . . . . . . . . . . . .  3
     3.1.  Subscriber Use Network Address Translation . . . . . . . .  3
     3.2.  Carrier-Grade Network Address Translation  . . . . . . . .  4
   4.  Available Options  . . . . . . . . . . . . . . . . . . . . . .  4
     4.1.  IPv6 Options . . . . . . . . . . . . . . . . . . . . . . .  4
       4.1.1.  Unique Globally Scoped IPv6 Unicast Addresses  . . . .  4
       4.1.2.  Unique Local IPv6 Unicast Addresses  . . . . . . . . .  5
     4.2.  IPv4 Options . . . . . . . . . . . . . . . . . . . . . . .  5
       4.2.1.  Address Transfers or Leases from Organizations
               with Available Address Space . . . . . . . . . . . . .  5
       4.2.2.  Using Unannounced Address Space Allocated to
               Another Organization . . . . . . . . . . . . . . . . .  5
       4.2.3.  Unique IPv4 Space Registered by an RIR . . . . . . . .  6
   5.  Options and Consequences for Defining New Private Use Space  .  6
     5.1.  Redefining Existing Unicast Space as Private Address
           Space  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     5.2.  Unique IPv4 Space Shared by a Group of Operators . . . . .  7
     5.3.  Potential Consequences of Not Redefining Existing
           Unicast Space as Private Address Space . . . . . . . . . .  8
     5.4.  Redefining Future Use Space as Unicast Address Space . . .  8
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  8
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Normative References . . . . . . . . . . . . . . . . . . .  9
     7.2.  Informative References . . . . . . . . . . . . . . . . . .  9
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 12

1. Introduction

1. はじめに

[RFC1918] sets aside three blocks of IPv4 address space for use in private networks: 192.168.0.0/16, 172.16.0.0/12 and 10.0.0.0/8. These blocks can be used simultaneously in multiple, separately managed networks without registration or coordination with IANA or any Internet registry. Very large networks can find that they need to number more device interfaces than there are available addresses in these three ranges. It has occasionally been suggested that additional private IPv4 address space should be reserved for use by these networks. Although such an action might address some of the needs for these very large network operators, it is not without consequences, particularly as we near the date when the IANA free pool will be fully allocated.

192.168.0.0/16、172.16.0.0/12と10.0.0.0/8：[RFC1918]はさておき、プライベートネットワークで使用するためのIPv4アドレス空間の三つのブロックを設定します。これらのブロックは、IANAまたはインターネットレジストリに登録または調整することなく、複数、個別に管理ネットワークに同時に使用することができます。非常に大規模なネットワークでは、彼らはこれらの3つの範囲で利用可能なアドレスよりも多くのデバイス・インターフェースに番号を付ける必要があることを見つけることができます。時折、追加のプライベートIPv4アドレス空間は、これらのネットワークで使用するために予約されなければならないことが示唆されています。そのような行動は、これらの非常に大規模なネットワークオペレータのためのニーズのいくつかを解決かもしれませんが、それはIANA空きプールが完全に割り当てられます日付の近くに、特に私たちのように、影響がないわけではありません。

The overall conclusion is that allocating additional address space to be used as private address space has severe problems and would, for instance, impact any software or configuration that has built-in assumptions about private address space. However, it is also well understood that cascading Network Address Translation (NAT) deployments in the existing private address space will cause different types of severe problems when address spaces overlap. At this point, there is no clear agreement of the likelihood of various problems or the respective trade-offs.

全体的な結論は、プライベートアドレス空間は、深刻な問題を抱えていると、例えば、内蔵されたプライベートアドレス空間に関する仮定任意のソフトウェアや設定に影響を与えるように、追加のアドレス空間の割り当てが使用されるということです。しかし、また、同様のアドレス空間が重なった場合、既存のプライベートアドレス空間でのカスケードネットワークアドレス変換（NAT）の導入は、深刻な問題のさまざまな種類を引き起こすであろうことが理解されます。この時点では、様々な問題やそれぞれのトレードオフの可能性の明確な合意はありません。

2. Large Networks

2.大規模ネットワーク

The main categories of very large networks using private address space are: cable operators, wireless (cell phone) operators, private internets, and VPN service providers. In the case of the first two categories, the complete address space reserved in [RFC1918] tends to be used by a single organization. In the case of private internets and VPN service providers, there are multiple independently managed and operated networks and the difficulty is in avoiding address clashes.

プライベートアドレス空間を使用して非常に大規模なネットワークの主なカテゴリは次のとおりです。ケーブル事業者、無線（携帯電話）事業者、民間のインターネット、およびVPNサービスプロバイダー。最初の二つのカテゴリーの場合には、[RFC1918]に確保完全なアドレス空間は、単一の組織によって使用される傾向にあります。民間のインターネットおよびVPNサービスプロバイダの場合は、複数の独立して管理・運営ネットワークが含まれていると難易度は、アドレスの衝突を避けることです。

3. Non-Unique Addresses

3.非固有のアドレス

3.1. Subscriber Use Network Address Translation

3.1. 加入者の使用ネットワークアドレス変換

The address space set aside in [RFC1918] is a finite resource that can be used to provide limited Internet access via NAT. A discussion of the advantages and disadvantages of NATs is outside the scope of this document, but an analysis of the advantages, disadvantages, and architectural implications can be found in [RFC2993]. Nonetheless, it must be acknowledged that NAT is adequate in some situations and not in others. For instance, it might technically be feasible to use NAT or even multiple layers of NAT within the networks operated by residential users or corporations where only limited Internet access is required. A more detailed analysis can be found in [RFC3022]. Where true peer-to-peer communication is needed or where services or applications do not work properly behind NAT, globally unique address space is required. In other cases, NAT traversal techniques facilitate peer-to-peer like communication for devices behind NATs.

[RFC1918]で確保されたアドレス空間は、NATを経由して制限されたインターネットアクセスを提供するために使用することができる有限の資源です。 NATの長所と短所の説明は、この文書の範囲外であるが、利点、欠点、および建築影響の分析は、[RFC2993]に見出すことができます。それにもかかわらず、NATは、いくつかの状況ではなく、他で十分であることを確認する必要があります。例えば、技術的に限られたインターネットアクセスが必要とされる住宅のユーザーや企業が運営するネットワーク内でNATやNATのも、複数の層を使用することは可能かもしれません。より詳細な分析は、[RFC3022]に見出すことができます。真のピア・ツー・ピア通信が必要な場合や、サービスやアプリケーションがNATの背後正しく動作しない場合は、グローバルに一意なアドレス空間が必要です。他の場合には、NATトラバーサル技法は、ピア・ツー・ピアNATの背後にあるデバイスのための通信等を容易にします。

In many cases, it is possible to use multiple layers of NAT to re-use parts of the address space defined in [RFC1918]. It is not always possible to rely on Customer Premises Equipment (CPE) devices using any particular range, however. In some cases, this means that unorthodox workarounds including assigning CPE devices unallocated address space or address space allocated to other network operators are feasible. In other cases, organizations choose to operate multiple separate routing domains to allow them to re-use the same private address ranges in multiple contexts. One consequence of this is the added complexity involved in identifying which system is referred to when an IP address is identified in a log or management system.

多くの場合、[RFC1918]で定義されたアドレス空間の一部を再利用するためにNATの複数の層を使用することが可能です。しかし、任意の特定の範囲を使用して、顧客宅内機器（CPE）のデバイスに依存することは必ずしも可能ではありません。いくつかの場合において、これは、他のネットワーク事業者に割り当てられた割り当てCPEデバイス割り当てられていないアドレス空間またはアドレス空間を含む非正統的な回避策が可能であることを意味します。他の例では、組織は、彼らがために複数のコンテキストで同じプライベートアドレス範囲を再利用できるようにするために、複数の別々のルーティングドメインを運用することを選択しました。これの1つの結果は、IPアドレスがログまたは管理システムで識別されたときに参照されるシステムの識別に関与する追加の複雑さです。

3.2. Carrier-Grade Network Address Translation

3.2. キャリアグレードのネットワーク・アドレス変換

Another option is to share one address across multiple interfaces and in some cases, subscribers. This model breaks the classical model used for logging address assignments and creates significant risks and additional burdens, as described in [CLAYTON] and more fully discussed in [FORD], and as documented in [DS-LITE].

別のオプションは、複数のインターフェースと、いくつかの例では、加入者全体で一つのアドレスを共有することです。このモデルは、ロギングアドレスの割り当てに使用する古典的モデルを破壊し、[CLAYTON]で説明し、より完全[FORD]で説明したように、重大なリスクや追加的な負担を作成し、[DS-LITE]で文書化されているよう。

4. Available Options

4.利用可能なオプション

When a network operator has exhausted the private address space set aside in [RFC1918] but needs to continue operating a single routing domain, a number of options are available. These are described in the following sections.

ネットワークオペレータは、[RFC1918]に取っておくのプライベートアドレス空間を使い果たしたが、単一のルーティングドメインを動作を継続する必要がいる場合には、多くのオプションが用意されています。これらは以下のセクションで説明されています。

4.1. IPv6 Options

4.1. IPv6のオプション

4.1.1. Unique Globally Scoped IPv6 Unicast Addresses

4.1.1. ユニークなグローバルスコープのIPv6ユニキャストアドレス

Using unique, globally scoped IPv6 unicast addresses is the best permanent solution as it removes any concerns about address scarcity within the next few decades. Implementing IPv6 is a major endeavor for service providers with millions of consumers and is likely to take considerable effort and time. In some cases, implementing a new network protocol on a very large network takes more time than is available, based on network growth and the proportion of private space that has already been used. In these cases, there is a call for additional private address space that can be shared by all network operators. [DAVIES] makes one such case.

それは今後数十年内のアドレス不足についての懸念を取り除くようユニークな、グローバルスコープのIPv6ユニキャストアドレスを使用すると、最高の恒久的な解決策です。実装IPv6は、消費者の何百万人と、サービスプロバイダのための主要な試みであると、かなりの労力と時間がかかる可能性があります。いくつかのケースでは、非常に大規模なネットワーク上の新しいネットワークプロトコルを実装すると、ネットワークの成長と、既に使用されているプライベートな空間の割合に基づいて、利用可能であるよりも多くの時間がかかります。これらのケースでは、すべてのネットワーク事業者で共有することができ、追加のプライベートアドレス空間のための呼び出しがあります。【DAVIES】一そのようなケースを行います。

4.1.2. Unique Local IPv6 Unicast Addresses

4.1.2. ユニークローカルIPv6ユニキャストアドレス

Using the unique, local IPv6 unicast addresses defined in [RFC4193] is another approach and does not require coordination with an Internet registry. Although the addresses defined in [RFC4193] are probabilistically unique, network operators on private internets and those providing VPN services might not want to use them because there is a very low probability of non-unique locally assigned global IDs being generated by the algorithm. Also, in the case of private internets, it can be very challenging to coordinate the introduction of a new network protocol to support the internet's continued growth.

[RFC4193]で定義されたユニークな、ローカルIPv6ユニキャストアドレスを使用すると、別のアプローチで、インターネットレジストリとの調整を必要としません。 [RFC4193]で定義されたアドレスは確率ユニークですがアルゴリズムによって生成された非ユニークローカルに割り当てられたグローバルIDの非常に低い確率があるので、民間のインターネットおよびVPNサービスを提供するこれらのネットワークオペレータは、それらを使用したくない場合があります。また、民間のインターネットの場合には、インターネットの継続的な成長をサポートするための新しいネットワークプロトコルの導入を調整することは非常に挑戦することができます。

4.2. IPv4 Options

4.2. IPv4のオプション

4.2.1. Address Transfers or Leases from Organizations with Available Address Space

4.2.1. 利用可能なアドレス空間を持つ組織からのアドレス転送またはリース

The Regional Internet Registry (RIR) communities have recently been developing policies to allow organizations with available address space to transfer such designated space to other organizations [Section 1.3.2 Transfer of Custodianship"">RIR-POLICY]. In other cases, leases might be arranged. This approach is only viable for operators of very large networks if enough address space is made available for transfer or lease and if the very large networks are able to pay the costs of these transfers. It is not possible to know how much address space will become available in this way, when it will be available, and how much it will cost. However, it is unlikely to become available in large contiguous blocks, and this would add to the network management burden for the operator as a significant number of small prefixes would inflate the size of the operators routing table at a time when it is also adding an IPv6 routing table. These reasons will make address transfers a less attractive proposition to many large network operators. Leases might not be attractive to some organizations if both parties cannot agree to a suitable length of time. Also, the lessor might worry about its own unanticipated needs for additional IPv4 address space.

地域インターネットレジストリ（RIR）のコミュニティは最近、利用可能なアドレス空間を持つ組織が他の組織[セクション「> RIR-POLICY」後見人の1.3.2転送]に、このような指定されたスペースを転送できるようにするための政策を開発してきました。他の例では、リースが配置されることがあります。十分なアドレス空間が移転またはリースのために利用可能にされた場合、非常に大規模なネットワークは、これらの転送の費用を支払うことができれば、このアプローチは非常に大規模なネットワークの運営のためにのみ実行可能です。利用できるようになりますと、このような方法で利用できるようになりますどのくらいのアドレススペース知ることは不可能であり、それはどのくらいの費用がかかります。しかし、大きな連続ブロックで利用可能になることはほとんどありません、そしてこれはまた、追加された時点で、オペレータ・ルーティング・テーブルのサイズを膨張させるであろう小さなプレフィックスのかなりの数として、オペレータのネットワーク管理負担に追加しますIPv6ルーティングテーブル。これらの理由は、アドレス転送多くの大規模なネットワークオペレータにあまり魅力的な提案になります。両当事者は、適切な長さの時間に同意できない場合、リースは、いくつかの組織に魅力的ではないかもしれません。また、賃貸人は、追加のIPv4アドレス空間のために、独自の不測のニーズを心配かもしれません。

4.2.2. Using Unannounced Address Space Allocated to Another Organization

4.2.2. 別の組織に割り当てられた未発表のアドレス空間を使用します

Some network operators have considered using IP address space that is allocated to another organization but is not publicly visible in BGP routing tables. This option is very strongly discouraged as the fact that an address block is not visible from one view does not mean that it is not visible from another. Furthermore, address usage tends to leak beyond private network borders in e-mail headers, DNS queries, traceroute output and other ways. The ambiguity this causes is problematic for multiple organizations. This issue is discussed in [RFC3879], Section 2.3.

いくつかのネットワークオペレータは、別の組織に割り当てられたが、BGPルーティングテーブルに公には表示されませんIPアドレス空間を使用して検討しました。このオプションは非常に強く、アドレスブロックは、それが他から見えないことを意味するものではありませんつのビューから表示されていないという事実として推奨されません。また、アドレスの使用量は、電子メールのヘッダ、DNSクエリ、tracerouteの出力や他の方法でプライベートネットワーク国境を越えて漏洩する傾向があります。これが原因と曖昧さは、複数の組織にとって問題です。この問題は、[RFC3879]、セクション2.3で説明されています。

It is also possible that the registrant of the address block might want to increase its visibility to other networks in the future, causing problems for anyone using it unofficially. In some cases, there might also be legal risks involved in using address space officially allocated to another organization.

アドレスブロックの登録者が非公式にそれを使用する人のための問題を引き起こして、将来的に他のネットワークへの視認性を高めるために必要かもしれないことも可能です。いくつかのケースでは、また正式に別の組織に割り当てられたアドレス空間の使用に関連する法的リスクがあるかもしれません。

Where this has happened in the past, it has caused operational problems [FASTWEB].

これは、過去に起こった場合は、それが動作上の問題[FASTWEB]を引き起こしています。

4.2.3. Unique IPv4 Space Registered by an RIR

4.2.3. RIRが登録ユニークIPv4のスペース

RIRs' policies allow network operators to receive unique IP addresses for use on internal networks. Further, network operators are not required to have already exhausted the private address space set aside in [RFC1918]. Nonetheless, network operators are naturally disinclined to request unique IPv4 addresses for the private areas of their networks, as using addresses in this way means they are not available for use by new Internet user connections.

RIRのポリシーは、ネットワーク事業者は、内部ネットワーク上で使用するための固有のIPアドレスを受け取ることができます。さらに、ネットワークオペレータは、すでに[RFC1918]に取っておくプライベートアドレス空間を使い果たしてしまったする必要はありません。彼らは新しいインターネットユーザ接続では使用できませんを意味し、このようにアドレスを使用してそれにもかかわらず、ネットワーク事業者は、自社のネットワークのプライベートエリアに一意のIPv4アドレスを要求する自然disinclinedです。

It is likely to become more difficult for network operators to obtain large blocks of unique address space as we approach the point where all IPv4 unicast /8s have been allocated. Several RIRs already have policies about how to allocate from their last /8 [RIR-POLICY-FINAL-8], and there have been policy discussions that would reduce the maximum allocation size available to network operators [MAX-ALLOC] or would reduce the period of need for which the RIR can allocate [SHORTER-PERIODS].

我々は、すべてのIPv4ユニキャスト/ 8Sが割り当てられている点に近づくと、ネットワークオペレータは、固有のアドレス空間の大きなブロックを取得することがより困難になる可能性があります。いくつかのRIRは、すでに彼らの最後の/ 8 [RIR-POLICY-FINAL-8]から割り当てる方法についてのポリシーを持っているし、ネットワークオペレータが利用可能な最大割り当てサイズ[MAX-ALLOC]を削減するか、減少するであろう政策議論が行われていますRIRは、[短期間]割り当てることができるための必要性の期間。

5. Options and Consequences for Defining New Private Use Space

新しい私用空間を形成するため5.オプションと帰結

5.1. Redefining Existing Unicast Space as Private Address Space

5.1. プライベートアドレス空間として既存のユニキャスト・スペースの再定義

It is possible to re-designate a portion of the current global unicast IPv4 address space as private unicast address space. Doing this could benefit a number of operators of large networks for the short period before they complete their IPv6 roll-out. However, this benefit incurs a cost by reducing the pool of global unicast addresses available to users in general.

これは、プライベートユニキャストアドレス空間として現在のグローバルユニキャストIPv4アドレス空間の再指定部分することが可能です。彼らはIPv6のロールアウトを完了する前にこれを行うと、短い期間のための大規模なネットワークのオペレータの数を利益を得ることができます。しかし、この利点は、一般のユーザーに利用可能なグローバルユニキャストアドレスのプールを減らすことによってコストが発生します。

When discussing re-designating a portion of the current global unicast IPv4 address space as private unicast address space, it is important to consider how much space would be used and for how long it would be sufficient. Not all of the large networks making full use of the space defined in [RFC1918] would have their needs met with a single /8. In 2005, [HAIN] suggested reserving three /8s for this purpose, while in 2009 [DAVIES] suggested a single /10 would be sufficient. There does not seem to be a consensus for a particular prefix length nor an agreed basis for deciding what is sufficient. The problem is exacerbated by the continually changing needs of ever expanding networks.

プライベートユニキャストアドレス空間として、現在のグローバルユニキャストIPv4アドレス空間の再指定部分を議論するとき、使用され、それが十分であろうどのくらいのためにされるだろうどのくらいのスペースを考慮することが重要です。ない[RFC1918]で定義された空間を最大限に活用し、大規模ネットワークのすべてのニーズを単一の/ 8と会っています。 2005年に、[HAIN]は2009年に[DAVIESが単一/ 10で十分であろう示唆している間、この目的のための3 / 8Sを予約を示唆しました。特定のプレフィックス長でも十分であるかを決定するための合意の基礎についてのコンセンサスがあるように思えません。問題は、これまでのネットワークの拡大を継続的に変化するニーズによって悪化します。

A further consideration is which of the currently unallocated IPv4 unicast /8 blocks should be used for this purpose. Using address space that is known to be used unofficially is tempting. For instance, 1.0.0.0/8, which was unallocated until January 2010, was proposed in [HAIN] and is known to be used by a number of different users. These include networks making use of HIP LSIs [RFC4423], [WIANA], [anoNet], and others. There is anecdotal [VEGODA] and research [WESSELS] evidence to suggest that several other IPv4 /8s are used in this fashion. Also there have been discussions [NANOG] about some sections of these /8's being carved out and filtered, therefore unofficially enabling the use of these sections for private use.

さらに考慮すべきことは、この目的のために使用されるべき現在未割り当てのIPv4ユニキャスト/ 8ブロックのどれです。非公式に使用されることが知られているアドレス空間を使用することは魅力的です。例えば、2010年1月までの未割り当てた1.0.0.0/8は、[HAIN]で提案された、異なるユーザーの数によって使用されることが知られています。これらは、HIPのLSI [RFC4423]、[WIANA]、[anoNet]を利用してネットワーク、及びその他を含みます。 [VEGODA]逸話や他のいくつかのIPv4 / 8Sは、この方法で使用されていることを示唆する研究[ウェッセル]証拠があります。また、そのため非公式私的使用のためのこれらのセクションの使用を可能にするこれらの/ 8のを切り出して、濾過されているいくつかのセクションについての議論[NANOG]、がありました。

Although new IPv4 /8s are allocated approximately once a month, they are not easy to bring into use because network operators are slow to change their filter configurations. This is despite long-running awareness campaigns [CYMRU] [LEWIS] and active work [ripe-351] to notify people whose filters are not changed in a timely fashion. Updating code that recognizes private address space in deployed software and infrastructure systems is likely to be far more difficult as many systems have these ranges hard-coded and cannot be quickly changed with a new configuration file.

新しいのIPv4 / 8Sは月に約一回割り当てられているが、それらは、ネットワーク事業者は、フィルタの設定を変更するのが遅いので、使用に持ち込むことは容易ではありません。これは、そのフィルタをタイムリーに変更されていない人に通知するために長時間実行啓発キャンペーン[CYMRU] [LEWIS]とアクティブな作業[熟し-351]にもかかわらず、です。展開のソフトウェアおよびインフラシステムにプライベートアドレス空間を認識し、コードを更新すると、はるかに困難な多くのシステムがこれらの範囲は、ハードコードされているとすぐに新しい設定ファイルを変更することはできませんようになりそうです。

Another consideration when redefining existing unicast space as private address space is that no single class of user can expect the space to stay unique to them. This means that an ISP using a new private address range cannot expect its customers not to already be using that address range within their own networks.

プライベートアドレス空間として、既存のユニキャストのスペースを再定義するもう1つの考慮事項は、利用者の単一のクラスには、スペースがそれらに特有の滞在を期待することはできないということです。これは、新しいプライベートアドレスの範囲を使用して、ISPは、すでに自分のネットワーク内でそのアドレスの範囲を使用してはならない顧客を期待できないことを意味します。

5.2. Unique IPv4 Space Shared by a Group of Operators

5.2. ユニークIPv4のスペースは、オペレータのグループで共有します

Where a group of networks find themselves in a position where they each need a large amount of IPv4 address space from an RIR in addition to that defined in [RFC1918], they might cooperatively agree to all use the same address space to number their networks. The clear benefit to this approach is that it significantly reduces the potential demand on the pool of unallocated IPv4 address space. However, the issues discussed in Sections 4.2.2 and 5.3 are of concern here, particularly the possibility that one operator might decide to use the address space to number customer connections, rather than private infrastructure.

ネットワークのグループは、彼らそれぞれが[RFC1918]で定義されていることに加えて、RIRからIPv4アドレス空間を大量に必要とする立場に自分自身を見つける場合には、それらが連携して、すべての彼らのネットワークに番号を同じアドレス空間を使用することに同意することがあります。このアプローチの明確な利点は、それが大幅に未割り当てのIPv4アドレス空間のプールに対する潜在的な需要を減少させることです。しかし、セクション4.2.2と5.3で議論された問題は、ここでの関心の1事業者ではなく、民間のインフラよりも、数の顧客の接続にアドレス空間を使用することを決定した可能性があることを特に可能性があります。

Nonetheless, this approach has the potential to create an unofficial new private address range without proper scrutiny.

それにもかかわらず、このアプローチは適切な精査せずに非公式新しいプライベートアドレスの範囲を作成する可能性を秘めています。

5.3. Potential Consequences of Not Redefining Existing Unicast Space as Private Address Space

5.3. プライベートアドレス空間として既存のユニキャストスペースを再定義しない潜在的な影響

If additional private address space is not defined and the large network operators affected by this problem are not able to solve their problems with IPv6 address space or by segmenting their networks into multiple routing domains, those networks will need unique IPv4 addresses. It is possible and even likely that a single network could consume a whole IPv4 /8 in a year. At the time this document is being written, there are just 24 unallocated IPv4 /8s, so it would not take many such requests to make a major dent in the available IPv4 address space. [POTAROO] provides an analysis of IPv4 address consumption and projects the date on which the IANA and RIR pools will be fully allocated.

追加のプライベートアドレス空間が定義されていないと、この問題の影響を受けて大規模なネットワークオペレータは、IPv6アドレス空間または複数のルーティングドメインに自社のネットワークをセグメント化することにより、彼らの問題を解決することができませんされている場合は、これらのネットワークは、ユニークなIPv4アドレスが必要になります。単一のネットワークは、年に全体のIPv4 / 8を消費する可能性があってもそうです。それが可能なIPv4アドレス空間に大きな凹みを作るために多くのそのような要求を取ることはないので、この文書が書かれている時には、ちょうど24未割り当てのIPv4 / 8Sは、あります。【POTAROO】IPv4アドレス消費の分析を提供し、IANAとRIRプールが完全に割り当てられる日付を投影します。

5.4. Redefining Future Use Space as Unicast Address Space

5.4. ユニキャストアドレス空間として、将来の使用スペースの再定義

There have also been proposals to re-designate the former Class E space (240.0.0.0/4) as unicast address space. [WILSON] suggests that it should be privately scoped while [FULLER] does not propose a scope. Both proposals note that existing deployed equipment may not be able to use addresses from 240.0.0.0/4. Potential users would need to be sure of the status of the equipment on their network and the networks with which they intend to communicate.

また、ユニキャストアドレス空間としてかつてのクラスEスペース（240.0.0.0/4）を再指定するための提案がなされてきました。【WILSON]は[FULLER]は範囲を提案しないが、それは個人スコープされるべきであることを示唆しています。どちらの提案が展開機器を既存の240.0.0.0/4からアドレスを使用することができないかもしれないことに注意してください。潜在的なユーザーは、ネットワーク上の機器と、それらが通信する予定でネットワークの状態を確認する必要があります。

It is not immediately clear how useful 240.0.0.0/4 could be in practice. While [FULLER] documents the status of several popular desktop and server operating systems, the status of the most widely deployed routers and switches is less clear, and it is possible that 240.0.0.0/4 might only be useful in very large, new green field deployments where full control of all deployed systems is available. However, in such cases it might well be easier to deploy an IPv6 network.

240.0.0.0/4は実際には可能性がどのように役に立つことはすぐに明らかではありません。 [FULLER]は、いくつかの一般的なデスクトップおよびサーバーオペレーティングシステムの状態を文書化しながら、最も広く導入されているルータやスイッチの状態があまり明確であり、240.0.0.0/4だけ緑新、非常に大規模で有用であるかもしれないことは可能ですデプロイされたすべてのシステムの完全な制御が可能ですフィールドの展開。しかし、そのような場合にはそれもIPv6ネットワークを展開する方が簡単かもしれません。

6. Security Considerations

6.セキュリティの考慮事項

This document has no security implications.

この文書にはセキュリティの意味を持っていません。

7. References

7.参考

7.1. Normative References

7.1. 引用規格

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.

[RFC1918] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月。

[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.

[RFC2993]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。

[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.

[RFC3022] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。

[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.

[RFC4193] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。

7.2. Informative References

7.2. 参考文献

[CLAYTON] Clayton, R., "Practical mobile Internet access traceability", January 2010, <http://www.lightbluetouchpaper.org/ 2010/01/13/practical-mobile-internet-access-traceability/>.

[CLAYTON]クレイトン、R.、 "実用的なモバイルインターネットアクセスのトレーサビリティ"、2010年1月、<http://www.lightbluetouchpaper.org/ 2010/01/13 /実用的なモバイル・インターネット・アクセス・トレーサビリティ/>。

[CYMRU] Greene, B., "The Bogon Reference", <http://www.team-cymru.org/Services/Bogons/>.

【CYMRU】グリーン、B.、 "Bogonリファレンス"、<http://www.team-cymru.org/Services/Bogons/>。

[DAVIES] Davies, G. and C. Liljenstolpe, "Transitional non-conflicting reusable IPv4 address block", Work in Progress, November 2009.

[DAVIES]デイヴィス、G.とC. Liljenstolpe進歩、2009年11月、 "暫定競合しない、再利用可能なIPv4アドレスブロック" を、作業。

[DS-LITE] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", Work in Progress, August 2010.

[DS-LITE]デュラン、A.、Droms、R.、Woodyatt、J.、およびY.リー、 "デュアルスタックLiteのブロードバンドの展開に続いてIPv4の枯渇"、進歩、2010年8月での作業。

[FASTWEB] Aina, A., "41/8 announcement", May 2006, <http://www.afnog.org/archives/2006-May/002117.html>.

[FASTWEB]アイナ、A.、 "8分の41の発表"、2006年5月、<http://www.afnog.org/archives/2006-May/002117.html>。

[FORD] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", Work in Progress, March 2010.

[FORD]フォード、M.、Boucadair、M.、デュラン、A.、リーバイス、P.、およびP.ロバーツ、進歩、2010年3月、作業 "IPアドレス共有の問題"。

[FULLER] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 as usable unicast address space", Work in Progress, March 2008.

[FULLER]フラー、V.、リア、E.、およびD.マイヤー、 "再分類4分の240として利用可能なユニキャストアドレス空間"、進歩、2008年3月での作業。

[HAIN] Hain, T., "Expanded Address Allocation for Private Internets", Work in Progress, January 2005.

[HAIN]ハイン、T.、 "個人的なインターネットのための拡張アドレスの割り当て"、進歩、2005年1月での作業。

[LEWIS] Lewis, J., "This system has been setup for testing purposes for 69/8 address space", March 2003, <http://69box.atlantic.net/>.

、<http://69box.atlantic.net/>、2003年3月、[LEWIS]ルイス、J. "このシステムは、8分の69アドレス空間のためのテストのために設定されています"。

[MAX-ALLOC] Spenceley, J. and J. Martin, "prop-070: Maximum IPv4 allocation size", January 2009, <http://www.apnic.net/policy/proposals/prop-070>.

[MAX-ALLOC] Spenceley、J.およびJ.マーチン、 "プロパ070：最大のIPv4割り当てサイズ" 2009年1月、<http://www.apnic.net/policy/proposals/prop-070>。

[NANOG] Dickson, B., "1/8 and 27/8 allocated to APNIC", January 2010, <http://mailman.nanog.org/ pipermail/nanog/2010-January/017451.html>.

【NANOG】ディクソン、B.、 "APNICに割り当て1/8および8分の27" 2010年1月、<http://mailman.nanog.org/ pipermail / NANOG / 2010年1月/ 017451.html>。

[POTAROO] Huston, G., "IPv4 Address Report", <http://www.potaroo.net/tools/ipv4/index.html>.

[POTAROO]ヒューストン、G.、 "IPv4アドレス報告書"、<http://www.potaroo.net/tools/ipv4/index.html>。

[RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004.

[RFC3879]のHuitema、C.およびB.大工、 "卑下サイトローカルアドレス"、RFC 3879、2004年9月。

[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.

[RFC4423]モスコウィッツ、R.とP. Nikander、 "ホストアイデンティティプロトコル（HIP）アーキテクチャ"、RFC 4423、2006年5月。

[RIR-POLICY] Number Resource Organization, "RIR Comparative Policy Overview, October 2009, Section 1.3.2 Transfer of Custodianship", <http://www.nro.net/rir-comparative-policy-overview/ rir-comparative-policy-overview-2009-03#1-3-2>.

[RIR-POLICY]ナンバー資源機構、 "RIR比較ポリシーの概要、2009年10月、後見人のセクション1.3.2転送"、<http://www.nro.net/rir-comparative-policy-overview/ RIR-comparative-ポリシーの概要-2009-03＃1-3-2>。

[RIR-POLICY-FINAL-8] Number Resource Organization, "RIR Comparative Policy Overview, October 2009, 2.6. Use of Final Unallocated IPv4 Address Space", October 2009, <http://www.nro.net/ rir-comparative-policy-overview/ rir-comparative-policy-overview-2009-03>.

[RIR-POLICY-FINAL-8]ナンバーリソース機関は、 "RIR比較ポリシーの概要、2009年10月、2.6。最終的な未割り当てのIPv4アドレス空間の利用"、2009年10月、<http://www.nro.net/ RIR-比較-policy-概要/ RIR-比較・ポリシーの概要-2009-03>。

[SHORTER-PERIODS] Karrenberg, D., O'Reilly, N., Titley, N., and R. Bush, "RIPE Policy Proposal 2009-03", April 2009, <http://www.ripe.net/ripe/policies/ proposals/2009-03>.

[SHORTER-PERIODS] Karrenberg、D.、オライリー、N.、Titley、N.、およびR.ブッシュ大統領、 "RIPE政策提言2009-03"、2009年4月、<http://www.ripe.net/熟し/ポリシー/提案/ 2009-03>。

[VEGODA] Vegoda, L., "Awkward /8 Assignments", September 2007, <http://www.cisco.com/web/about/ac123/ac147/ archived_issues/ipj_10-3/103_awkward.html>.

[VEGODA] Vegoda、L.、 "厄介/ 8の割り当て"、2007年9月、<http://www.cisco.com/web/about/ac123/ac147/ archived_issues / ipj_10-3 / 103_awkward.html>。

[WESSELS] Wessels, D., "Searching for Evidence of Unallocated Address Space Usage in DITL 2008 Data", June 2008, <https://www.dns-oarc.net/files/dnsops-2008/ Wessels-Unused-space.pdf>.

「DITL 2008年に未割り当てアドレス空間の使用の証拠の検索データ」[ウェッセル]ウェッセル、D.、2008年6月、<https://www.dns-oarc.net/files/dnsops-2008/ウェッセル・未使用空間.PDF>。

[WIANA] WIANA, "The Wireless Internet Assigned Numbers Authority", <http://www.wiana.org/>.

[WIANA] WIANA、 "ワイヤレスインターネットが割り当て番号機関"、<http://www.wiana.org/>。

[WILSON] Wilson, P., Michaelson, G., and G. Huston, "Redesignation of 240/4 from "Future Use" to "Private Use"", Work in Progress, September 2008.

[WILSON]ウィルソン、P.、マイケルソン、G.、およびG.ヒューストン、将来の使用「から4分の240の再指定『』に『私用』」、進歩、2008年9月の作業。

[anoNet] anoNet, "anoNet: Cooperative Chaos".

[タイヤ]疲れて、「疲れ：共同手術rativeカオス」。

[ripe-351] Karrenberg, D., "De-Bogonising New Address Blocks", October 2005, <http://www.ripe.net/ripe/docs/ripe-351>.

[熟し-351] Karrenberg、D.、 "デ・Bogonising新アドレスブロック"、2005年10月、<http://www.ripe.net/ripe/docs/ripe-351>。

Appendix A. Acknowledgments

付録A.謝辞

The authors would like to thank Ron Bonica, Michelle Cotton, Lee Howard, and Barbara Roseman for their assistance in early discussions of this document and to Maria Blackmore, Alex Bligh, Mat Ford, Thomas Narten, and Ricardo Patara for suggested improvements.

著者は、提案の改善については、このドキュメントの初期の議論にとマリア・ブラックモア、アレックス・ブライ、マットフォード、トーマスNarten氏、そしてリカルドパタラへの支援のためにロンBonica、ミシェル・コットン、リー・ハワード、そしてバーバラ・ローズマンに感謝したいと思います。

Authors' Addresses

著者のアドレス

Marla Azinger Frontier Communications Corporation Vancouver, WA United States of America

マーラAzingerフロンティアコミュニケーションズ株式会社バンクーバー、アメリカのワシントン州米国

EMail: marla.azinger@ftr.com URI: http://www.frontiercorp.com/

電子メール：marla.azinger@ftr.com URI：http://www.frontiercorp.com/

Leo Vegoda Internet Corporation for Assigned Names and Numbers 4676 Admiralty Way, Suite 330 Marina del Rey, CA 90292 United States of America

アメリカの割り当てられた名前と番号4676アドミラルティ・ウェイのためのレオVegodaインターネット株式会社、スイート330マリナ・デル・レイ、CA 90292米国

Phone: +1-310-823-9358 EMail: leo.vegoda@icann.org URI: http://www.iana.org/

電話：+ 1-310-823-9358 Eメール：leo.vegoda@icann.org URI：http://www.iana.org/