[要約] 要約：RFC 6752は、インターネットでのプライベートIPアドレッシングに関する問題を議論しています。 目的：このRFCの目的は、プライベートIPアドレッシングの問題を理解し、解決策を提案することです。
Internet Engineering Task Force (IETF) A. Kirkham
Request for Comments: 6752 Palo Alto Networks
Category: Informational September 2012
ISSN: 2070-1721
Issues with Private IP Addressing in the Internet
インターネットでのプライベートIPアドレスの問題
Abstract
概要
The purpose of this document is to provide a discussion of the potential problems of using private, RFC 1918, or non-globally routable addressing within the core of a Service Provider (SP) network. The discussion focuses on link addresses and, to a small extent, loopback addresses. While many of the issues are well recognised within the ISP community, there appears to be no document that collectively describes the issues.
このドキュメントの目的は、サービスプロバイダー（SP）ネットワークのコア内でプライベート、RFC 1918、または非グローバルにルーティング可能なアドレッシングを使用することの潜在的な問題について説明することです。ここでは、リンクアドレスと、ある程度はループバックアドレスに焦点を当てています。問題の多くはISPコミュニティ内でよく認識されていますが、問題をまとめて説明するドキュメントはないようです。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
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（Internet Engineering Task Force）の製品です。これは、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/rfc6752.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6752で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 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文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Conservation of Address Space ...................................3
3. Effects on Traceroute ...........................................3
4. Effects on Path MTU Discovery ...................................6
5. Unexpected Interactions with Some NAT Implementations ...........7
6. Interactions with Edge Anti-Spoofing Techniques .................9
7. Peering Using Loopbacks .........................................9
8. DNS Interaction .................................................9
9. Operational and Troubleshooting Issues .........................10
10. Security Considerations .......................................10
11. Alternate Approaches to Core Network Security .................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
Appendix A. Acknowledgments ......................................14
In the mid to late 1990s, some Internet Service Providers (ISPs) adopted the practice of utilising private (or non-globally unique) [RFC1918] IP addresses for the infrastructure links and in some cases the loopback interfaces within their networks. The reasons for this approach centered on conservation of address space (i.e., scarcity of public IPv4 address space) and security of the core network (also known as core hiding).
1990年代半ばから後半にかけて、一部のインターネットサービスプロバイダー（ISP）は、インフラストラクチャリンク、および場合によってはネットワーク内のループバックインターフェイスにプライベート（またはグローバルに一意ではない）[RFC1918] IPアドレスを使用する方法を採用しました。このアプローチの理由は、アドレス空間の節約（つまり、パブリックIPv4アドレス空間の不足）とコアネットワークのセキュリティ（コア非表示とも呼ばれます）に集中していました。
However, a number of technical and operational issues occurred as a result of using private (or non-globally unique) IP addresses, and virtually all these ISPs moved away from the practice. Tier 1 ISPs are considered the benchmark of the industry and as of the time of writing, there is no known tier 1 ISP that utilises the practice of private addressing within their core network.
ただし、プライベート（またはグローバルに一意ではない）IPアドレスを使用した結果として、多くの技術的および運用上の問題が発生し、事実上これらすべてのISPはプラクティスから離れました。 Tier 1 ISPは業界のベンチマークと見なされており、執筆時点では、コアネットワーク内でプライベートアドレス指定の手法を利用する既知のTier 1 ISPはありません。
The following sections will discuss the various issues associated with deploying private [RFC1918] IP addresses within ISP core networks.
次のセクションでは、ISPコアネットワーク内にプライベート[RFC1918] IPアドレスを展開することに関連するさまざまな問題について説明します。
The intent of this document is not to suggest that private IP addresses can not be used with the core of an SP network, as some providers use this practice and operate successfully. The intent is to outline the potential issues or effects of such a practice.
このドキュメントの目的は、SPネットワークのコアでプライベートIPアドレスを使用できないことを示唆することではありません。これは、一部のプロバイダーがこの方法を使用して正常に動作しているためです。その意図は、そのような慣行の潜在的な問題または影響を概説することです。
Note: The practice of ISPs using "squat" address space (also known as "stolen" space) has many of the same, plus some additional, issues (or effects) as that of using private IP address space within core networks. The term "squat IP address space" refers to the practice of an ISP using address space for its own infrastructure/core network addressing that has been officially allocated by an RIR (Regional Internet Registry) to another provider, but that provider is not currently using or advertising within the Internet. Squat addressing is not discussed further in this document. It is simply noted as an associated issue.
注：「スクワット」アドレススペース（「盗まれた」スペースとも呼ばれます）を使用するISPのプラクティスには、コアネットワーク内でプライベートIPアドレススペースを使用する場合と同じ問題に加えて、いくつかの追加の問題（または影響）があります。 「スクワットIPアドレススペース」という用語は、RIR（Regional Internet Registry）によって別のプロバイダーに正式に割り当てられた独自のインフラストラクチャ/コアネットワークアドレス指定にアドレススペースを使用するISPの慣行を指しますが、そのプロバイダーは現在使用していませんまたはインターネット内の広告。スクワットアドレッシングについては、このドキュメントではこれ以上説明しません。これは単に関連する問題として記載されています。
One of the original intents for the use of private IP addressing within an ISP core was the conservation of IP address space. When an ISP is allocated a block of public IP addresses (from an RIR), this address block was traditionally split in order to dedicate some portion for infrastructure use (i.e., for the core network) and the other portion for customer (subscriber) or other address pool use. Typically, the number of infrastructure addresses needed is relatively small in comparison to the total address count. So unless the ISP was only granted a small public block, dedicating some portion to infrastructure links and loopback addresses (/32) is rarely a large enough issue to outweigh the problems that are potentially caused when private address space is used.
ISPコア内でプライベートIPアドレッシングを使用する当初の目的の1つは、IPアドレス空間の節約でした。 ISPに（RIRからの）パブリックIPアドレスのブロックが割り当てられると、このアドレスブロックは伝統的に分割され、インフラストラクチャの使用（つまり、コアネットワーク）と、顧客（サブスクライバー）のその他の部分に割り当てられます。他のアドレスプールの使用。通常、必要なインフラストラクチャアドレスの数は、アドレスの総数に比べて比較的少ないです。そのため、ISPに小さなパブリックブロックしか付与されていない場合を除き、インフラストラクチャリンクとループバックアドレス（/ 32）に専念することは、プライベートアドレススペースが使用されている場合に発生する可能性がある問題を上回るほど大きな問題になることはめったにありません。
Additionally, specifications and equipment capability improvements now allow for the use of /31 subnets [RFC3021] for link addresses in place of the original /30 subnets -- further minimising the impact of dedicating public addresses to infrastructure links by only using two (2) IP addresses per point-to-point link versus four (4), respectively.
さらに、仕様と機器機能の改善により、元の/ 30サブネットの代わりに/ 31サブネット[RFC3021]をリンクアドレスに使用できるようになりました。インフラストラクチャリンクにパブリックアドレスを2つだけ使用することによる影響をさらに最小化ポイントツーポイントリンクごとのIPアドレスとそれぞれ4つのIPアドレス。
The use of private addressing as a conservation technique within an Internet Service Provider (ISP) core can cause a number of technical and operational issues or effects. The main effects are described below.
インターネットサービスプロバイダー（ISP）コア内の保護手法としてプライベートアドレス指定を使用すると、技術的および運用上の多くの問題または影響が生じる可能性があります。主な効果は次のとおりです。
The single biggest effect caused by the use of private addressing [RFC1918] within an Internet core is the fact that it can disrupt the operation of traceroute in some situations. This section provides some examples of the issues that can occur.
インターネットコア内でプライベートアドレス指定[RFC1918]を使用することによる最大の影響は、状況によってはtracerouteの動作を妨害する可能性があることです。このセクションでは、発生する可能性のある問題の例をいくつか示します。
A first example illustrates the situation where the traceroute crosses an Autonomous System (AS) boundary, and one of the networks has utilised private addressing. The following simple network is used to show the effects.
最初の例は、tracerouteが自律システム（AS）境界を越え、ネットワークの1つがプライベートアドレス指定を利用している状況を示しています。次の簡単なネットワークを使用して、効果を示します。
AS64496 EBGP AS64497
IBGP Mesh <---------------> IBGP Mesh
R1 Pool - R6 Pool -
203.0.113.0/26 203.0.113.64/26
198.51.100.8/30
198.51.100.4/30
10.1.1.0/30 10.1.1.4/30 198.51.100.0/30
.9 .10
.1 .2 .5 .6 ------------ .6 .5 .2 .1
R1-----------R2-----------R3--| |--R4----------R5----------R6
R1 Loopback: 10.1.1.101 R4 Loopback: 198.51.100.103
R2 Loopback: 10.1.1.102 R5 Loopback: 198.51.100.102
R3 Loopback: 10.1.1.103 R6 Loopback: 198.51.100.101
Using this example, performing the traceroute from AS64497 to AS64496, we can see the private addresses of the infrastructure links in AS64496 are returned.
この例を使用して、AS64497からAS64496へのtracerouteを実行すると、AS64496のインフラストラクチャリンクのプライベートアドレスが返されることがわかります。
R6#traceroute 203.0.113.1 Type escape sequence to abort. Tracing the route to 203.0.113.1
R6＃traceroute 203.0.113.1エスケープシーケンスを入力して中止します。 203.0.113.1へのルートの追跡
1 198.51.100.2 40 msec 20 msec 32 msec 2 198.51.100.6 16 msec 20 msec 20 msec 3 198.51.100.9 20 msec 20 msec 32 msec 4 10.1.1.5 20 msec 20 msec 20 msec 5 10.1.1.1 20 msec 20 msec 20 msec R6#
1 198.51.100.2 40ミリ秒20ミリ秒32ミリ秒2 198.51.100.6 16ミリ秒20ミリ秒20ミリ秒3 198.51.100.9 20ミリ秒20ミリ秒32ミリ秒4 10.1.1.5 20ミリ秒20ミリ秒20ミリ秒5 10.1.1.1 20ミリ秒20ミリ秒20ミリ秒R6＃
This effect in itself is often not a problem. However, if anti-spoofing controls are applied at network perimeters, then responses returned from hops with private IP addresses will be dropped. Anti-spoofing refers to a security control where traffic with an invalid source address is discarded. Anti-spoofing is further described in [BCP38] and [BCP84]. Additionally, any [RFC1918] filtering mechanism, such as those employed in most firewalls and many other network devices can cause the same effect.
この効果自体はしばしば問題ではありません。ただし、スプーフィング対策の制御がネットワークの境界で適用される場合、プライベートIPアドレスを持つホップから返される応答はドロップされます。スプーフィング対策とは、無効な送信元アドレスを持つトラフィックが破棄されるセキュリティ制御を指します。スプーフィング対策については、[BCP38]と[BCP84]でさらに説明されています。さらに、ほとんどのファイアウォールや他の多くのネットワークデバイスで採用されているような[RFC1918]フィルタリングメカニズムが同じ効果を引き起こす可能性があります。
The effects are illustrated in a second example below. The same network as in example 1 is used, but with the addition of anti-spoofing deployed at the ingress of R4 on the R3-R4 interface (IP Address 198.51.100.10).
効果は、下の2番目の例に示されています。例1と同じネットワークが使用されていますが、R3-R4インターフェイス（IPアドレス198.51.100.10）のR4の入口に配置されたスプーフィング対策が追加されています。
R6#traceroute 203.0.113.1
R6＃traceroute 203.0.113.1
Type escape sequence to abort. Tracing the route to 203.0.113.1
エスケープシーケンスを入力して中止します。 203.0.113.1へのルートの追跡
1 198.51.100.2 24 msec 20 msec 20 msec
2 198.51.100.6 20 msec 52 msec 44 msec
3 198.51.100.9 44 msec 20 msec 32 msec
4 * * *
5 * * *
6 * * *
7 * * *
8 * * *
9 * * *
10 * * *
11 * * *
12 * * *
In a third example, a similar effect is caused. If a traceroute is initiated from a router with a private (source) IP address, located in AS64496 and the destination is outside of the ISP's AS (AS64497), then in this situation, the traceroute will fail completely beyond the AS boundary.
3番目の例では、同様の効果が発生します。 AS64496にあるプライベート（ソース）IPアドレスを持つルーターからtracerouteが開始され、宛先がISPのAS（AS64497）の外部にある場合、この状況では、tracerouteはAS境界を超えて完全に失敗します。
R1# traceroute 203.0.113.65 Type escape sequence to abort. Tracing the route to 203.0.113.65
R1＃traceroute 203.0.113.65エスケープシーケンスを入力して中止します。 203.0.113.65へのルートの追跡
1 10.1.1.2 20 msec 20 msec 20 msec
2 10.1.1.6 52 msec 24 msec 40 msec
3 * * *
4 * * *
5 * * *
6 * * *
R1#
While it is completely unreasonable to expect a packet with a private source address to be successfully returned in a typical SP environment, the case is included to show the effect as it can have implications for troubleshooting. This case will be referenced in a later section.
プライベートの送信元アドレスを持つパケットが通常のSP環境で正常に返されることを期待することは完全に不合理ですが、トラブルシューティングに影響を与える可能性があるため、その効果を示すためにケースが含まれています。このケースは、後のセクションで参照されます。
In a complex topology, with multiple paths and exit points, the provider will lose its ability to trace paths originating within its own AS, through its network, to destinations within other ASes. Such a situation could be a severe troubleshooting impediment.
複数のパスと出口点がある複雑なトポロジでは、プロバイダーは、自身のAS内で発生し、ネットワークを介して他のAS内の宛先までのパスを追跡する機能を失います。このような状況は、深刻なトラブルシューティングの障害になる可能性があります。
For completeness, a fourth example is included to show that a successful traceroute can be achieved by specifying a public source address as the source address of the traceroute. Such an approach can be used in many operational situations if the router initiating the traceroute has at least one public address configured. However, the approach is more cumbersome.
完全を期すために、4番目の例は、tracerouteのソースアドレスとしてパブリックソースアドレスを指定することにより、tracerouteが成功することを示しています。 tracerouteを開始するルーターに少なくとも1つのパブリックアドレスが構成されている場合、このようなアプローチは多くの運用状況で使用できます。ただし、このアプローチはより面倒です。
R1#traceroute Protocol [ip]: Target IP address: 203.0.113.65 Source address: 203.0.113.1 Numeric display [n]: Timeout in seconds [3]: Probe count [3]: Minimum Time to Live [1]: Maximum Time to Live [30]: 10 Port Number [33434]: Loose, Strict, Record, Timestamp, Verbose[none]: Type escape sequence to abort. Tracing the route to 203.0.113.65
R1＃tracerouteプロトコル[ip]：ターゲットIPアドレス：203.0.113.65ソースアドレス：203.0.113.1数値表示[n]：秒単位のタイムアウト[3]：プローブ数[3]：最小存続時間[1]：最大時間to Live [30]：10ポート番号[33434]：Loose、Strict、Record、Timestamp、Verbose [none]：エスケープシーケンスを入力して中止します。 203.0.113.65へのルートの追跡
1 10.1.1.2 0 msec 4 msec 0 msec 2 10.1.1.6 0 msec 4 msec 0 msec 3 198.51.100.10 [AS 64497] 0 msec 4 msec 0 msec 4 198.51.100.5 [AS 64497] 0 msec 0 msec 4 msec 5 198.51.100.1 [AS 64497] 0 msec 0 msec 4 msec R1#
1 10.1.1.2 0ミリ秒4ミリ秒0ミリ秒2 10.1.1.6 0ミリ秒4ミリ秒0ミリ秒3 198.51.100.10 [AS 64497] 0ミリ秒4ミリ秒0ミリ秒4 198.51.100.5 [AS 64497] 0ミリ秒0ミリ秒4ミリ秒5 198.51 .100.1 [AS 64497] 0ミリ秒0ミリ秒4ミリ秒R1＃
It should be noted that some solutions to this problem have been proposed in [RFC5837], which provides extensions to ICMP to allow the identification of interfaces and their components by any combination of the following: ifIndex, IPv4 address, IPv6 address, name, and MTU. However, at the time of this writing, little or no deployment was known to be in place.
[RFC5837]でこの問題に対するいくつかの解決策が提案されていることに注意してください。これは、ICMPへの拡張を提供し、ifIndex、IPv4アドレス、IPv6アドレス、名前、およびMTU。ただし、この記事の執筆時点では、展開が行われていることはほとんどまたはまったく知られていませんでした。
The Path MTU Discovery (PMTUD) process was designed to allow hosts to make an accurate assessment of the maximum packet size that can be sent across a path without fragmentation. Path MTU Discovery is utilised by IPv4 [RFC1191], IPv6 [RFC1981], and some tunnelling protocols such as Generic Routing Encapsulation (GRE) and IPsec.
パスMTUディスカバリー（PMTUD）プロセスは、ホストがフラグメント化せずにパスを介して送信できる最大パケットサイズを正確に評価できるように設計されています。パスMTUディスカバリーは、IPv4 [RFC1191]、IPv6 [RFC1981]、およびGeneric Routing Encapsulation（GRE）やIPsecなどの一部のトンネリングプロトコルで使用されます。
The PMTUD mechanism requires that an intermediate router can reply to the source address of an IP packet with an ICMP reply that uses the router's interface address. If the router's interface address is a private IP address, then this ICMP reply packet may be discarded due to unicast reverse path forwarding (uRPF) or ingress filtering, thereby causing the PMTUD mechanism to fail. If the PMTUD mechanism fails, this will cause transmission of data between the two hosts to fail silently due to the traffic being black-holed. As a result, the potential for application-level issues may be created.
PMTUDメカニズムでは、中間ルーターがIPパケットのソースアドレスに、ルーターのインターフェイスアドレスを使用するICMP応答で応答できる必要があります。ルーターのインターフェースアドレスがプライベートIPアドレスの場合、ユニキャストリバースパスフォワーディング（uRPF）または入力フィルタリングが原因で、このICMP応答パケットが破棄され、PMTUDメカニズムが失敗する可能性があります。 PMTUDメカニズムが失敗すると、トラフィックがブラックホール化されるため、2つのホスト間のデータ転送がサイレントに失敗します。その結果、アプリケーションレベルの問題が発生する可能性があります。
Private addressing is legitimately used within many enterprise, corporate, or government networks for internal network addressing. When users on the inside of the network require Internet access, they will typically connect through a perimeter router, firewall, or network proxy that provides Network Address Translation (NAT) or Network Address Port Translation (NAPT) services to a public interface.
プライベートアドレス指定は、多くの企業、企業、または政府のネットワーク内で内部ネットワークアドレス指定のために合法的に使用されています。ネットワーク内部のユーザーがインターネットアクセスを必要とする場合、通常は、境界ルーター、ファイアウォール、またはネットワークアドレス変換（NAT）またはネットワークアドレスポート変換（NAPT）サービスをパブリックインターフェイスに提供するネットワークプロキシを介して接続します。
Scarcity of public IPv4 addresses is forcing many service providers to make use of NAT. CGN (Carrier-Grade NAT) will enable service providers to assign private [RFC1918] IPv4 addresses to their customers rather than public, globally unique IPv4 addresses. NAT444 will make use of a double NAT process.
パブリックIPv4アドレスが不足しているため、多くのサービスプロバイダーはNATを利用する必要があります。 CGN（Carrier-Grade NAT）により、サービスプロバイダーは、グローバルに一意のパブリックIPv4アドレスではなく、プライベート[RFC1918] IPv4アドレスを顧客に割り当てることができます。 NAT444はダブルNATプロセスを利用します。
Unpredictable or confusing interactions could occur if traffic such as traceroute, PMTUD, and possibly other applications were launched from the NAT IPv4 'inside address', and it passed over the same address range in the public IP core. While such a situation would be unlikely to occur if the NAT pools and the private infrastructure addressing were under the same administration, such a situation could occur in the more typical situation of a NATed corporate network connecting to an ISP. For example, say 10.1.1.0/24 is used to internally number the corporate network. A traceroute or PMTUD request is initiated inside the corporate network from say 10.1.1.1. The packet passes through a NAT (or NAPT) gateway, then over an ISP core numbered from the same range. When the responses are delivered back to the originator, the returned packets from the privately addressed part of the ISP core could have an identical source and destination address of 10.1.1.1.
traceroute、PMTUD、および場合によっては他のアプリケーションなどのトラフィックがNAT IPv4の「内部アドレス」から起動され、パブリックIPコアの同じアドレス範囲を通過した場合、予測不能または混乱する相互作用が発生する可能性があります。 NATプールとプライベートインフラストラクチャアドレッシングが同じ管理下にある場合、このような状況は起こりそうにありませんが、このような状況は、ISPに接続するNATされた企業ネットワークのより一般的な状況で発生する可能性があります。たとえば、企業ネットワークに内部的に番号を付けるために10.1.1.0/24が使用されているとします。 tracerouteまたはPMTUD要求は、たとえば10.1.1.1から企業ネットワーク内で開始されます。パケットはNAT（またはNAPT）ゲートウェイを通過し、次に同じ範囲から番号が付けられたISPコアを通過します。応答が発信者に返送されると、ISPコアのプライベートアドレス指定部分から返されたパケットは、10.1.1.1の同一の送信元アドレスと宛先アドレスを持つことができます。
NAT Pool - 203.0.113.0/24
NATプール-203.0.113.0/24
10.1.1.0/30 10.1.1.0/30 198.51.100.0/30
198.51.100.12/30 198.51.100.4/30
.1 .2 .14 .13 .1 .2 .6 .5 .2 .1
R1-----------R2-----------R3---------------R4----------R5----------R6
NAT
R6 Loopback:
198.51.100.100
R1#traceroute 198.51.100.100
R1＃traceroute 198.51.100.100
Type escape sequence to abort. Tracing the route to 198.51.100.100
エスケープシーケンスを入力して中止します。 198.51.100.100へのルートの追跡
1 10.1.1.2 0 msec 0 msec 0 msec 2 198.51.100.13 0 msec 4 msec 0 msec 3 10.1.1.2 0 msec 4 msec 0 msec <<<< 4 198.51.100.5 4 msec 0 msec 4 msec 5 198.51.100.1 0 msec 0 msec 0 msec R1#
1 10.1.1.2 0ミリ秒0ミリ秒0ミリ秒2 198.51.100.13 0ミリ秒4ミリ秒0ミリ秒3 10.1.1.2 0ミリ秒4ミリ秒0ミリ秒<<<< 4 198.51.100.5 4ミリ秒0ミリ秒4ミリ秒5 198.51.100.1 0ミリ秒0ミリ秒0ミリ秒R1＃
This duplicate address space scenario has the potential to cause confusion among operational staff, thereby making it more difficult to successfully debug networking problems.
この重複したアドレススペースのシナリオは、運用スタッフ間で混乱を引き起こす可能性があり、それによってネットワークの問題を正常にデバッグすることがより困難になります。
Certainly a scenario where the same [RFC1918] address space becomes utilised on both the inside and outside interfaces of a NAT/NAPT device can be problematic. For example, the same private address range is assigned by both the administrator of a corporate network and its ISP. Some applications discover the outside address of their local Customer Premises Equipment (CPE) to determine if that address is reserved for special use. Application behaviour may then be based on this determination. "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] provides further analysis of this situation.
確かに、同じ[RFC1918]アドレススペースがNAT / NAPTデバイスの内部と外部の両方のインターフェイスで利用されるようになるシナリオでは、問題が発生する可能性があります。たとえば、同じプライベートアドレス範囲が、企業ネットワークの管理者とそのISPの両方によって割り当てられています。一部のアプリケーションは、ローカルの顧客宅内機器（CPE）の外部アドレスを検出して、そのアドレスが特別な使用のために予約されているかどうかを判断します。アプリケーションの動作は、この決定に基づく場合があります。 「共有アドレス空間用のIANA予約IPv4プレフィックス」[RFC6598]は、この状況の詳細な分析を提供します。
To address this scenario and others, "IANA-Reserved IPv4 Prefix for Shared Address Space" [RFC6598] allocated a dedicated /10 address block for the purpose of Shared CGN (Carrier Grade NAT) Address Space: 100.64.0.0/10. The purpose of Shared CGN Address Space is to number CPE (Customer Premise Equipment) interfaces that connect to CGN devices. As explained in [RFC6598], [RFC1918] addressing has issues when used in this deployment scenario.
このシナリオやその他の問題に対処するために、「共有アドレススペースのIANA予約IPv4プレフィックス」[RFC6598]は、共有CGN（キャリアグレードNAT）アドレススペースの目的で専用の/ 10アドレスブロックを割り当てました：100.64.0.0/10。共有CGNアドレススペースの目的は、CGNデバイスに接続するCPE（顧客宅内機器）インターフェイスに番号を付けることです。 [RFC6598]で説明されているように、[RFC1918]アドレッシングは、この展開シナリオで使用すると問題があります。
Denial-of-Service (DOS) attacks and Distributed Denial-of-Service (DDoS) attacks can make use of spoofed source IP addresses in an attempt to obfuscate the source of an attack. Network Ingress Filtering [RFC2827] strongly recommends that providers of Internet connectivity implement filtering to prevent packets using source addresses outside of their legitimately assigned and advertised prefix ranges. Such filtering should also prevent packets with private source addresses from egressing the AS.
サービス拒否（DOS）攻撃および分散サービス拒否（DDoS）攻撃は、攻撃の送信元を難読化しようとして、偽装された送信元IPアドレスを利用する可能性があります。 Network Ingress Filtering [RFC2827]は、インターネット接続のプロバイダーがフィルタリングを実装して、正当に割り当てられアドバタイズされたプレフィックス範囲外の送信元アドレスを使用するパケットを防ぐことを強く推奨します。このようなフィルタリングは、プライベート送信元アドレスを持つパケットがASから出て行くことも防ぎます。
Best security practices for ISPs also strongly recommend that packets with illegitimate source addresses should be dropped at the AS perimeter. Illegitimate source addresses includes private [RFC1918] IP addresses, addresses within the provider's assigned prefix ranges, and bogons (legitimate but unassigned IP addresses). Additionally, packets with private IP destination addresses should also be dropped at the AS perimeter.
ISPの最良のセキュリティプラクティスでは、不正な送信元アドレスを持つパケットをAS境界でドロップすることを強くお勧めします。不正な送信元アドレスには、プライベート[RFC1918] IPアドレス、プロバイダーに割り当てられたプレフィックスの範囲内のアドレス、およびbogon（正当だが未割り当てのIPアドレス）が含まれます。さらに、プライベートIP宛先アドレスを持つパケットもAS境界でドロップする必要があります。
If such filtering is properly deployed, then traffic either sourced from or destined for privately addressed portions of the network should be dropped, hence the negative consequences on traceroute, PMTUD, and regular ping-type traffic.
このようなフィルタリングが適切に展開されている場合、ネットワークのプライベートアドレス指定された部分から送信された、または宛先が指定されたトラフィックがドロップされるため、traceroute、PMTUD、および通常のpingタイプのトラフィックに悪影響が生じます。
Some ISPs use the loopback addresses of Autonomous System Border Routers (ASBRs) for peering, in particular, where multiple connections or exchange points exist between the two ISPs. Such a technique is used by some ISPs as the foundation of fine-grained traffic engineering and load balancing through the combination of IGP metrics and multi-hop BGP. When private or non-globally reachable addresses are used as loopback addresses, this technique is either not possible or considerably more complex to implement.
一部のISPは、特に2つのISP間に複数の接続または交換ポイントが存在するピアリングに自律システム境界ルーター（ASBR）のループバックアドレスを使用します。このような手法は、一部のISPで、IGPメトリックとマルチホップBGPの組み合わせによるきめ細かなトラフィックエンジニアリングとロードバランシングの基盤として使用されています。プライベートアドレスまたはグローバルに到達できないアドレスがループバックアドレスとして使用される場合、この手法は実装できないか、実装がかなり複雑になります。
Many ISPs utilise their DNS to perform both forward and reverse resolution for infrastructure devices and infrastructure addresses. With a privately numbered core, the ISP itself will still have the capability to perform name resolution of its own infrastructure. However, others outside of the autonomous system will not have this capability. At best, they will get a number of unidentified [RFC1918] IP addresses returned from a traceroute.
多くのISPはDNSを利用して、インフラストラクチャデバイスとインフラストラクチャアドレスの順方向と逆方向の両方の解決を実行します。プライベートに番号が付けられたコアにより、ISP自体は独自のインフラストラクチャの名前解決を実行する機能を引き続き備えています。ただし、自律システム外の他のユーザーにはこの機能はありません。せいぜい、それらはtracerouteから返された多くの未確認の[RFC1918] IPアドレスを取得します。
It is also worth noting that in some cases, the reverse resolution requests may leak outside of the AS. Such a situation can add load to public DNS servers. Further information on this problem is documented in "AS112 Nameserver Operations" [RFC6304].
また、場合によっては、逆解決要求がASの外部に漏れることもあります。このような状況では、パブリックDNSサーバーに負荷がかかる可能性があります。この問題の詳細については、「AS112ネームサーバー操作」[RFC6304]に記載されています。
Previous sections of this document have noted issues relating to network operations and troubleshooting. In particular, when private IP addressing within an ISP core is used, the ability to easily troubleshoot across the AS boundary may be limited. In some cases, this may be a serious troubleshooting impediment. In other cases, it may be solved through the use of alternative troubleshooting techniques.
このドキュメントの前のセクションでは、ネットワークの操作とトラブルシューティングに関連する問題について説明しました。特に、ISPコア内のプライベートIPアドレッシングを使用する場合、AS境界を越えて簡単にトラブルシューティングを行う機能が制限される場合があります。場合によっては、これは深刻なトラブルシューティングの妨げになることがあります。他の場合では、別のトラブルシューティング手法を使用することで解決できる場合があります。
The key point is that the flexibility of initiating an outbound ping or traceroute from a privately numbered section of the network is lost. In a complex topology, with multiple paths and exit points from the AS, the provider may be restricted in its ability to trace paths through the network to other ASes. Such a situation could be a severe troubleshooting impediment.
重要な点は、ネットワークのプライベートに番号付けされたセクションからアウトバウンドpingまたはtracerouteを開始する柔軟性が失われることです。複数のパスとASからの出口点がある複雑なトポロジでは、プロバイダーは、ネットワークを介して他のASへのパスを追跡する機能が制限される場合があります。このような状況は、深刻なトラブルシューティングの障害になる可能性があります。
For users outside of the AS, the loss of the ability to use a traceroute for troubleshooting is very often a serious issue. As soon as many of these people see a row of "* * *" in a traceroute they often incorrectly assume that a large part of the network is down or inaccessible (e.g., behind a firewall). Operational experience in many large providers has shown that significant confusion can result.
ASの外部のユーザーにとって、トラブルシューティングにtracerouteを使用する機能が失われることは、しばしば深刻な問題です。これらの人々の多くがtracerouteで "* * *"の行を見るとすぐに、ネットワークの大部分がダウンしているか、またはアクセスできない（ファイアウォールの背後など）と誤って想定することがよくあります。多くの大規模プロバイダーでの運用経験は、大きな混乱が生じる可能性があることを示しています。
With respect to [RFC1918] IP addresses applied as loopbacks, in this world of acquisitions, if an operator needed to merge two networks, each using the same private IP ranges, then the operator would likely need to renumber one of the two networks. In addition, assume an operator needed to compare information such as NetFlow / IP Flow Information Export (IPFIX) or syslog, between two networks using the same private IP ranges. There would likely be an issue as the unique ID in the collector is, in most cases, the source IP address of the UDP export, i.e., the loopback address.
[RFC1918]ループバックとして適用されたIPアドレスに関して、この買収の世界では、事業者が2つのネットワークをマージする必要があり、それぞれが同じプライベートIP範囲を使用している場合、事業者は2つのネットワークの1つを再番号付けする必要があります。さらに、同じプライベートIP範囲を使用する2つのネットワーク間で、NetFlow / IPフロー情報エクスポート（IPFIX）またはsyslogなどの情報を比較する必要があるオペレーターを想定します。コレクター内の一意のIDは、ほとんどの場合、UDPエクスポートのソースIPアドレス、つまりループバックアドレスであるため、問題が発生する可能性があります。
One of the arguments often put forward for the use of private addressing within an ISP is an improvement in the network security. It has been argued that if private addressing is used within the core, the network infrastructure becomes unreachable from outside the provider's autonomous system, hence protecting the infrastructure. There is legitimacy to this argument. Certainly, if the core is privately numbered and unreachable, it potentially provides a level of isolation in addition to what can be achieved with other techniques, such as infrastructure Access Control Lists (ACLs), on their own. This is especially true in the event of an ACL misconfiguration, something that does commonly occur as the result of human error.
ISP内でプライベートアドレッシングを使用することでしばしば提起される議論の1つは、ネットワークセキュリティの改善です。コア内でプライベートアドレッシングを使用すると、ネットワークインフラストラクチャがプロバイダーの自律システムの外部から到達できなくなり、インフラストラクチャが保護されると主張されてきました。この議論には正当性があります。確かに、コアにプライベートな番号が付けられていて到達できない場合は、インフラストラクチャのアクセス制御リスト（ACL）などの他の手法を単独で使用して達成できることに加えて、ある程度の分離が提供される可能性があります。これは、ACLの設定ミスが発生した場合に特に当てはまります。これは通常、人為的エラーの結果として発生します。
There are three key security gaps that exist in a privately addressed IP core.
プライベートアドレスのIPコアには、3つの主要なセキュリティギャップがあります。
1. The approach does not protect against reflection attacks if edge anti-spoofing is not deployed. For example, if a packet with a spoofed source address corresponding to the network's infrastructure address range is sent to a host (or other device) attached to the network, that host will send its response directly to the infrastructure address. If such an attack was performed across a large number of hosts, then a successful large-scale DoS attack on the infrastructure could be achieved. This is not to say that a publicly numbered core will protect from the same attack; it won't. The key point is that a reflection attack does get around the apparent security offered in a privately addressed core.
1. エッジスプーフィングが導入されていない場合、このアプローチはリフレクション攻撃から保護しません。たとえば、ネットワークのインフラストラクチャアドレス範囲に対応する送信元アドレスが偽装されたパケットがネットワークに接続されているホスト（または他のデバイス）に送信される場合、そのホストはその応答をインフラストラクチャアドレスに直接送信します。このような攻撃が多数のホストにわたって実行された場合、インフラストラクチャに対する大規模なDoS攻撃が成功する可能性があります。これは、公に番号が付けられたコアが同じ攻撃から保護すると言っているのではありません。それはしません。重要な点は、リフレクション攻撃は、プライベートにアドレス指定されたコアで提供される見かけ上のセキュリティを回避することです。
2. Even if anti-spoofing is deployed at the AS boundary, the border routers will potentially carry routing information for the privately addressed network infrastructure. This can mean that packets with spoofed addresses, corresponding to the private infrastructure addressing, may be considered legitimate by edge anti-spoofing techniques (such as Unicast Reverse Path Forwarding - Loose Mode) and forwarded. To avoid this situation, an edge anti-spoofing algorithm (such as Unicast Reverse Path Forwarding - Strict Mode) would be required. Strict approaches can be problematic in some environments or where asymmetric traffic paths exist.
2. スプーフィング対策がAS境界に配置されている場合でも、境界ルーターは、プライベートアドレスのネットワークインフラストラクチャのルーティング情報を運ぶ可能性があります。これは、プライベートインフラストラクチャアドレッシングに対応する、スプーフィングされたアドレスを持つパケットが、エッジスプーフィング防止技術（ユニキャストリバースパス転送-ルーズモードなど）によって正当と見なされ、転送されることを意味します。この状況を回避するには、エッジスプーフィング防止アルゴリズム（ユニキャストリバースパス転送-厳密モードなど）が必要になります。一部の環境や非対称のトラフィックパスが存在する環境では、厳密なアプローチが問題になることがあります。
3. The approach on its own does not protect the network infrastructure from directly connected customers (i.e., within the same AS). Unless other security controls, such as access control lists (ACLs), are deployed at the ingress point of the network, customer devices will normally be able to reach, and potentially attack, both core and edge infrastructure devices.
3. アプローチ自体は、直接接続された顧客（つまり、同じAS内）からネットワークインフラストラクチャを保護しません。アクセスコントロールリスト（ACL）などの他のセキュリティコントロールがネットワークの入口に配置されていない限り、顧客のデバイスは通常、コアインフラストラクチャデバイスとエッジインフラストラクチャデバイスの両方に到達でき、攻撃する可能性があります。
Today, hardware-based ACLs, which have minimal to no performance impact, are now widespread. Applying an ACL at the AS perimeter to prevent access to the network core may be a far simpler approach and provide comparable protection to using private addressing; such a technique is known as an infrastructure ACL (iACL).
現在、ハードウェアベースのACLは、パフォーマンスへの影響が最小限からまったくないもので、現在広く普及しています。 ASの境界でACLを適用してネットワークコアへのアクセスを防止することは、はるかに簡単なアプローチであり、プライベートアドレスの使用と同等の保護を提供します。このような手法は、インフラストラクチャACL（iACL）として知られています。
In concept, iACLs provide filtering at the edge network, which allows traffic to cross the network core but not to terminate on infrastructure addresses within the core. Proper iACL deployment will normally allow required network management traffic to be passed, such that traceroutes and PMTUD can still operate successfully. For an iACL deployment to be practical, the core network needs to have been addressed with a relatively small number of contiguous address blocks. For this reason, the technique may or may not be practical.
概念的には、iACLはエッジネットワークでフィルタリングを提供します。これにより、トラフィックはネットワークコアを通過できますが、コア内のインフラストラクチャアドレスで終端することはできません。適切なiACL展開では、通常、必要なネットワーク管理トラフィックを通過させることができるため、tracerouteとPMTUDは引き続き正常に動作できます。 iACLの配置を実用的にするには、コアネットワークが比較的少数の連続したアドレスブロックで処理されている必要があります。このため、この手法は実用的である場合とそうでない場合があります。
A second approach to preventing external access to the core is IS-IS core hiding. This technique makes use of a fundamental property of the IS-IS protocol, which allows link addresses to be removed from the routing table while still allowing loopback addresses to be resolved as next hops for BGP. The technique prevents parties outside the AS from being able to route to infrastructure addresses, while still allowing traceroutes to operate successfully. IS-IS core hiding does not have the same practical requirement for the core to be addressed from a small number of contiguous address blocks as with iACLs. From an operational and troubleshooting perspective, care must be taken to ensure that pings and traceroutes are using source and destination addresses that exist in the routing tables of all routers in the path, i.e., not hidden link addresses.
コアへの外部アクセスを防ぐための2番目のアプローチは、IS-ISコアの非表示です。この手法はIS-ISプロトコルの基本的な特性を利用しており、ループバックアドレスをBGPのネクストホップとして解決しながら、リンクアドレスをルーティングテーブルから削除できます。この手法は、ASの外部の関係者がインフラストラクチャアドレスにルーティングできないようにする一方で、tracerouteが正常に動作できるようにします。 IS-ISコアの隠蔽には、コアがiACLの場合のように少数の連続したアドレスブロックからアドレス指定されるという実際的な要件はありません。運用とトラブルシューティングの観点から、pingとtracerouteがパス内のすべてのルーターのルーティングテーブルに存在する送信元アドレスと宛先アドレス、つまり非表示のリンクアドレスを使用していないことを確認する必要があります。
A third approach is the use of either an MPLS-based IP VPN or an MPLS-based IP Core where the 'P' routers (or Label Switch Routers) do not carry global routing information. As the core 'P' routers (or Label Switch Routers) are only switching labeled traffic, they are effectively not reachable from outside of the MPLS domain. The 'P' routers can optionally be hidden so that they do not appear in a traceroute. While this approach isolates the 'P' routers from directed attacks, it does not protect the edge routers ('PE' routers or Label Edge Routers (LERs)). Obviously, there are numerous other engineering considerations in such an approach; we simply note it as an option.
3番目のアプローチは、MPLSベースのIP VPNまたはMPLSベースのIPコアのいずれかを使用することです。この場合、「P」ルーター（またはラベルスイッチルーター）はグローバルルーティング情報を伝送しません。コア 'P'ルーター（またはラベルスイッチルーター）はラベル付けされたトラフィックのみをスイッチングするため、MPLSドメインの外部からは事実上到達できません。 「P」ルーターは、オプションで非表示にして、tracerouteに表示されないようにすることができます。このアプローチは「P」ルーターを直接攻撃から隔離しますが、エッジルーター（「PE」ルーターまたはラベルエッジルーター（LER））を保護しません。明らかに、そのようなアプローチには他にも数多くのエンジニアリング上の考慮事項があります。オプションとしてそれを単に注記します。
These techniques may not be suitable for every network. However, there are many circumstances where they can be used successfully without the associated effects of privately addressing the core.
これらの手法は、すべてのネットワークに適しているとは限りません。ただし、コアをプライベートにアドレス指定するという関連する影響なしに、それらを正常に使用できる多くの状況があります。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", May 2000.
[BCP38]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IPソースアドレススプーフィングを使用するサービス拒否攻撃を阻止する」、2000年5月。
[BCP84] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", March 2004.
[BCP84]ベイカー、F。およびP.サボラ、「マルチホームネットワークのイングレスフィルタリング」、2004年3月。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、1990年11月。
[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、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996.
[RFC1981] McCann、J.、Deering、S。、およびJ. Mogul、「IPバージョン6のパスMTUディスカバリ」、RFC 1981、1996年8月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月。
[RFC3021] Retana, A., White, R., Fuller, V., and D. McPherson, "Using 31-Bit Prefixes on IPv4 Point-to-Point Links", RFC 3021, December 2000.
[RFC3021] Retana、A.、White、R.、Fuller、V。、およびD. McPherson、「IPv4ポイントツーポイントリンクでの31ビットプレフィックスの使用」、RFC 3021、2000年12月。
[RFC5837] Atlas, A., Bonica, R., Pignataro, C., Shen, N., and JR. Rivers, "Extending ICMP for Interface and Next-Hop Identification", RFC 5837, April 2010.
[RFC5837] Atlas、A.、Bonica、R.、Pignataro、C.、Shen、N.、JR。 Rivers、「Interface and Next-Hop IdentificationのためのICMPの拡張」、RFC 5837、2010年4月。
[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.
[RFC6304] Abley、J。およびW. Maton、「AS112 Nameserver Operations」、RFC 6304、2011年7月。
[RFC6598] Weil, J., Kuarsingh, V., Donley, C., Liljenstolpe, C., and M. Azinger, "IANA-Reserved IPv4 Prefix for Shared Address Space", BCP 153, RFC 6598, April 2012.
[RFC6598] Weil、J.、Kuarsingh、V.、Donley、C.、Liljenstolpe、C。、およびM. Azinger、「IANA-Reserved IPv4 Prefix for Shared Address Space」、BCP 153、RFC 6598、2012年4月。
The author would like to thank the following people for their input and review: Dan Wing (Cisco Systems), Roland Dobbins (Arbor Networks), Philip Smith (APNIC), Barry Greene (ISC), Anton Ivanov (kot-begemot.co.uk), Ryan Mcdowell (Cisco Systems), Russ White (Cisco Systems), Gregg Schudel (Cisco Systems), Michael Behringer (Cisco Systems), Stephan Millet (Cisco Systems), Tom Petch (BT Connect), Wes George (Time Warner Cable), and Nick Hilliard (INEX).
著者は、以下の人々の意見とレビューに感謝します：Dan Wing（Cisco Systems）、Roland Dobbins（Arbor Networks）、Philip Smith（APNIC）、Barry Greene（ISC）、Anton Ivanov（kot-begemot.co。 uk）、Ryan Mcdowell（Cisco Systems）、Russ White（Cisco Systems）、Gregg Schudel（Cisco Systems）、Michael Behringer（Cisco Systems）、Stephan Millet（Cisco Systems）、Tom Petch（BT Connect）、Wes George（Time Warnerケーブル）、およびニックヒリアード（INEX）。
The author would also like to acknowledge the use of a variety of NANOG mail archives as references.
作者は、参照としてさまざまなNANOGメールアーカイブの使用を認めたいと思います。
Author's Address
著者のアドレス
Anthony Kirkham Palo Alto Networks Level 32, 101 Miller St North Sydney, New South Wales 2060 Australia
Anthony Kirkham Palo Alto Networks Level 32、101 Miller St North Sydney、New South Wales 2060 Australia
Phone: +61 7 33530902
EMail: tkirkham@paloaltonetworks.com