[要約] RFC 6319は、追加のプライベートIPv4アドレススペースの指定に関連する問題を議論しています。このRFCの目的は、既存のプライベート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
追加のプライベートIPv4アドレススペースの指定に関連する問題
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によって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補者ではありません。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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6319で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
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 Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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
[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.
[RFC1918]は、プライベートネットワークで使用するための3ブロックのIPv4アドレス型スペースを脇に置きます：192.168.0.0/16、172.16.0.0/12および10.0.0.0/8。これらのブロックは、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）の展開は、アドレススペースが重複するとさまざまなタイプの深刻な問題を引き起こすこともよく理解されています。この時点で、さまざまな問題やそれぞれのトレードオフの可能性について明確な合意はありません。
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サービスプロバイダーです。最初の2つのカテゴリの場合、[RFC1918]に予約されている完全なアドレススペースは、単一の組織で使用される傾向があります。プライベートインターネットとVPNサービスプロバイダーの場合、複数の独立して管理され、運用されているネットワークがあり、住所の衝突を回避するのが難しいです。
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または複数の層を使用することが可能です。より詳細な分析は[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アドレスが識別されたときに参照されるシステムを特定するために関与する追加された複雑さです。
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].
別のオプションは、複数のインターフェイスで1つのアドレスを共有し、場合によってはサブスクライバーを共有することです。このモデルは、アドレスの割り当てのログに使用される古典的なモデルを破壊し、[clayton]で説明されているように、[ford]でより完全に議論され、[ds-lite]で文書化されているように、重大なリスクと追加の負担を作成します。
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]に取っておいてくださいが、単一のルーティングドメインの操作を継続する必要があるプライベートアドレススペースを使い果たした場合、多くのオプションが利用可能です。これらについては、次のセクションで説明します。
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]はそのような場合の1つを作成します。
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]で定義されているアドレスは確率的にユニークですが、プライベートインターネットのネットワークオペレーターとVPNサービスを提供するユーザーは、アルゴリズムによって生成される非ユニークに割り当てられたグローバルIDの可能性が非常に低いため、それらを使用したくない場合があります。また、プライベートインターネットの場合、インターネットの継続的な成長をサポートするために、新しいネットワークプロトコルの導入を調整することは非常に困難です。
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 [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]。他の場合には、リースが配置される場合があります。このアプローチは、転送またはリースに十分なアドレススペースが利用可能になり、非常に大きなネットワークがこれらの転送のコストを支払うことができる場合に非常に大きなネットワークのオペレーターにとってのみ実行可能です。この方法で利用可能なアドレススペースがどれだけ、いつ利用可能になるか、どれだけの費用がかかるかを知ることはできません。ただし、大きな隣接するブロックで利用できるようになる可能性は低く、これはかなりの数の小さなプレフィックスがオペレーターのサイズを膨らませるため、オペレーターのネットワーク管理の負担に追加されるでしょう。IPv6ルーティングテーブル。これらの理由により、アドレス転送は多くの大規模なネットワークオペレーターに魅力的ではない提案になります。両当事者が適切な期間に同意できない場合、一部の組織にとってリースは魅力的ではないかもしれません。また、貸手は、追加のIPv4アドレススペースに対する予期せぬニーズを心配するかもしれません。
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]。
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.
RIRSのポリシーにより、ネットワークオペレーターは、内部ネットワークで使用するための一意のIPアドレスを受け取ることができます。さらに、ネットワークオペレーターは、[RFC1918]に取っておいてください。それにもかかわらず、ネットワークオペレーターは、ネットワークのプライベートエリアの一意のIPv4アドレスを要求するために自然に阻害されます。この方法でアドレスを使用することは、新しいインターネットユーザー接続で使用できないことを意味するためです。
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ユニキャスト /8が割り当てられているポイントに近づくと、ネットワークオペレーターが一意のアドレス空間の大きなブロックを取得することがより困難になる可能性があります。いくつかのRIRには、最後の /8 [RIR-Policy-Final-8]から割り当てる方法に関するポリシーがすでにあり、ネットワークオペレーター[Max-Alloc]が利用できる最大割り当てサイズを削減するか、または減少させるポリシーディスカッションがあります。RIRが[より短い期間]を割り当てることができる必要性の期間。
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]はこの目的のために3 /8を予約することを提案しましたが、2009年に[Davies]は単一 /10で十分であることを示唆しました。特定のプレフィックスの長さのコンセンサスも、十分なものを決定するための合意された根拠もないようです。この問題は、拡大するネットワークの継続的に変化するニーズによって悪化しています。
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]で提案され、多くの異なるユーザーが使用することが知られています。これらには、股関節LSIS [RFC4423]、[Wiana]、[anonet]などを使用するネットワークが含まれます。この方法で他のいくつかのIPv4 /8が使用されていることを示唆する逸話[Vegoda]および研究[Wessels]の証拠があります。また、これらの /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 /8は月に約1回割り当てられますが、ネットワークオペレーターがフィルター構成を変更するのが遅いため、使用するのは簡単ではありません。これは、フィルターがタイムリーに変更されていない人々に通知するために、長期にわたる啓発キャンペーン[Cymru] [Lewis]とアクティブな仕事[Ripe-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.
既存のユニキャストスペースをプライベートアドレススペースとして再定義する際の別の考慮事項は、単一のクラスのユーザーがスペースがそれらに固有のままであることを期待できることです。これは、新しいプライベートアドレス範囲を使用するISPが、顧客が独自のネットワーク内でそのアドレス範囲を既に使用していないことを期待できないことを意味します。
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.
それにもかかわらず、このアプローチは、適切な精査なしに非公式の新しいプライベートアドレス範囲を作成する可能性があります。
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アドレスが必要になります。単一のネットワークが1年でIPv4 /8全体を消費できる可能性があります。このドキュメントが書かれている時点では、24の未割り当てIPv4 /8Sしかありません。そのため、利用可能なIPv4アドレススペースに大きな凹みを作るために多くのそのような要求は必要ありません。[Potaroo]は、IPv4アドレスの消費の分析を提供し、IANAおよびRIRプールが完全に割り当てられる日付をプロジェクトにします。
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）を再指定する提案もありました。[ウィルソン]は、[フラー]がスコープを提案しない一方で、個人的にスコープする必要があることを示唆しています。どちらの提案も、既存の展開された機器が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ネットワークを展開する方が簡単かもしれません。
This document has no security implications.
このドキュメントにはセキュリティの意味はありません。
[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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、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. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[CLAYTON] Clayton, R., "Practical mobile Internet access traceability", January 2010, <http://www.lightbluetouchpaper.org/ 2010/01/13/practical-mobile-internet-access-traceability/>.
[Clayton] Clayton、R。、「実用的なモバイルインターネットアクセストレーサビリティ」、2010年1月、<http://www.lightbluetouchpaper.org/ 2010/01/13/practical-mobile-internet-ccess-traceability/>。
[CYMRU] Greene, B., "The Bogon Reference", <http://www.team-cymru.org/Services/Bogons/>.
[Cymru] Greene、B。、「The Bogon Reference」、<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] Davies、G。and C. Liljenstolpe、「移行中の非紛争の再利用可能なIPv4アドレスブロック」、2009年11月、進行中の作業。
[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] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4 Exhotion後のデュアルスタックLiteブロードバンド展開」、2010年8月の作業。
[FASTWEB] Aina, A., "41/8 announcement", May 2006, <http://www.afnog.org/archives/2006-May/002117.html>.
[FastWeb] Aina、A。、 "41/8 Ancounted"、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] Ford、M.、Boucadair、M.、Durand、A.、Levis、P。、およびP. Roberts、「IPアドレス共有の問題」、2010年3月の作業。
[FULLER] Fuller, V., Lear, E., and D. Meyer, "Reclassifying 240/4 as usable unicast address space", Work in Progress, March 2008.
[Fuller] Fuller、V.、Lear、E。、およびD. Meyer、「240/4を使用可能なユニキャストアドレススペースとして再分類」、2008年3月、進行中の作業。
[HAIN] Hain, T., "Expanded Address Allocation for Private Internets", Work in Progress, January 2005.
[Hain] 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/>.
[Lewis] Lewis、J。、「このシステムは、69/8アドレススペースのテスト目的でセットアップされています」、2003年3月<http://69box.atlantic.net/>。
[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。and J. Martin、「Prop-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] Dickson、B。、「1/8および27/8 Apnicに割り当てられた」、2010年1月、<http://mailman.nanog.org/ pipermail/nanog/2010-january/017451.html>。
[POTAROO] Huston, G., "IPv4 Address Report", <http://www.potaroo.net/tools/ipv4/index.html>.
[Potaroo] Huston、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。and B. Carpenter、「DepRemating Site Local Addresses」、RFC 3879、2004年9月。
[RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol (HIP) Architecture", RFC 4423, May 2006.
[RFC4423] Moskowitz、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-Policy-overview-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アドレススペースの使用」、<http://www.nro.net/ rir-comparative-policy-overview/ rir-compalative-policy-overview-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.、O'Reilly、N.、Titley、N.、およびR. Bush、「Ripe Policy Proposal 2009-03」、2009年4月、<http://www.ripe.net/RIPE/ポリシー/提案/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>.
[Wessels] Wessels、D。、「DITL 2008データでの未割り合止の住所スペース使用の証拠を検索する」、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.
[ウィルソン]ウィルソン、P。、マイケルソン、G。、およびG.ヒューストン、「将来の使用」から「プライベート使用」への240/4の再指定、2008年9月、作業進行中。
[anoNet] anoNet, "anoNet: Cooperative Chaos".
[Anonet] Anonet、「Anonet：Cooperative Chaos」。
[ripe-351] Karrenberg, D., "De-Bogonising New Address Blocks", October 2005, <http://www.ripe.net/ripe/docs/ripe-351>.
[Ripe-351] Karrenberg、D。、「新しいアドレスブロックの解体」、2005年10月、<http://www.ripe.net/ripe/docs/ripe-351>。
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.
著者は、この文書の初期の議論と、マリア・ブラックモア、アレックス・ブライ、マット・フォード、トーマス・ナルテン、リカルド・パタラの改善について、ロン・ボニカ、ミシェル・コットン、リー・ハワード、バーバラ・ローズマンに感謝したいと思います。
Authors' Addresses
著者のアドレス
Marla Azinger Frontier Communications Corporation Vancouver, WA United States of America
マーラアジンガーフロンティアコミュニケーションコーポレーションバンクーバー、ワシントンアメリカ合衆国アメリカ
EMail: 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 Admiralty Way、Suite 330 Marina Del Rey、CA 90292アメリカ合衆国アメリカ
Phone: +1-310-823-9358
EMail: leo.vegoda@icann.org
URI: http://www.iana.org/