Internet Engineering Task Force (IETF)                           J. Weil
Request for Comments: 6598                             Time Warner Cable
BCP: 153                                                    V. Kuarsingh
Updates: 5735                                      Rogers Communications
Category: Best Current Practice                                C. Donley
ISSN: 2070-1721                                                CableLabs
                                                         C. Liljenstolpe
                                                           Telstra Corp.
                                                              M. Azinger
                                                 Frontier Communications
                                                              April 2012
        

IANA-Reserved IPv4 Prefix for Shared Address Space

共有アドレススペースのIANA予約IPv4プレフィックス

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space to accommodate the needs of Carrier-Grade NAT (CGN) devices. It is anticipated that Service Providers will use this Shared Address Space to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

このドキュメントでは、キャリアグレードのNAT（CGN）デバイスのニーズに対応するために、共有アドレススペースとして使用されるIPv4 / 10アドレスブロックの割り当てを要求しています。サービスプロバイダーは、この共有アドレススペースを使用して、CGNデバイスを顧客宅内機器（CPE）に接続するインターフェイスに番号を付けることが予想されます。

Shared Address Space is distinct from RFC 1918 private address space because it is intended for use on Service Provider networks. However, it may be used in a manner similar to RFC 1918 private address space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces. Details are provided in the text of this document.

共有アドレススペースは、サービスプロバイダーネットワークでの使用を目的としているため、RFC 1918プライベートアドレススペースとは異なります。ただし、アドレスが2つの異なるインターフェイスで同一である場合に、ルーターインターフェイス間でアドレス変換を実行できるルーティング機器のRFC 1918プライベートアドレススペースと同様の方法で使用できます。詳細は、このドキュメントの本文に記載されています。

This document details the allocation of an additional special-use IPv4 address block and updates RFC 5735.

このドキュメントでは、追加の特殊用途IPv4アドレスブロックの割り当てについて詳しく説明し、RFC 5735を更新しています。

This memo documents an Internet Best Current Practice.

このメモは、インターネットの現在のベストプラクティスを文書化したものです。

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). Further information on BCPs is available in Section 2 of RFC 5741.

このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 BCPの詳細については、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/rfc6598.

このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http://www.rfc-editor.org/info/rfc6598で入手できます。

A number of operators have expressed a need for the special-purpose IPv4 address allocation described by this document. During deliberations, the IETF community demonstrated very rough consensus in favor of the allocation.

多くのオペレーターが、このドキュメントで説明されている専用のIPv4アドレス割り当ての必要性を表明しています。審議中に、IETFコミュニティは割り当てに賛成する非常に大まかなコンセンサスを示しました。

While operational expedients, including the special-purpose address allocation described in this document, may help solve a short-term operational problem, the IESG and the IETF remain committed to the deployment of IPv6.

このドキュメントで説明されている専用アドレスの割り当てを含む運用上の便宜は、短期的な運用上の問題の解決に役立つ可能性がありますが、IESGとIETFはIPv6の展開に専念し続けます。

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に記載されているように保証なしで提供されます。

   1. Introduction ....................................................3
   2. Requirements Language ...........................................3
   3. Alternatives to Shared Address Space ............................3
   4. Use of Shared CGN Space .........................................4
   5. Risk ............................................................5
      5.1. Analysis ...................................................5
      5.2. Empirical Data .............................................6
   6. Security Considerations .........................................7
   7. IANA Considerations .............................................8
   8. References ......................................................8
      8.1. Normative References .......................................8
      8.2. Informative References .....................................9
   Appendix A. Acknowledgments .......................................10
        

IPv4 address space is nearly exhausted. However, ISPs must continue to support IPv4 growth until IPv6 is fully deployed. To that end, many ISPs will deploy a Carrier-Grade NAT (CGN) device, such as that described in [RFC6264]. Because CGNs are used on networks where public address space is expected, and currently available private address space causes operational issues when used in this context, ISPs require a new IPv4 /10 address block. This address block will be called the "Shared Address Space" and will be used to number the interfaces that connect CGN devices to Customer Premises Equipment (CPE).

IPv4アドレス空間がほぼ使い果たされています。ただし、IPv6が完全に展開されるまで、ISPはIPv4の成長をサポートし続ける必要があります。そのために、多くのISPは[RFC6264]で説明されているようなキャリアグレードNAT（CGN）デバイスを配備します。 CGNはパブリックアドレススペースが予想されるネットワークで使用され、現在利用可能なプライベートアドレススペースがこのコンテキストで使用されると運用上の問題を引き起こすため、ISPには新しいIPv4 / 10アドレスブロックが必要です。このアドレスブロックは「共有アドレススペース」と呼ばれ、CGNデバイスを顧客宅内機器（CPE）に接続するインターフェイスに番号を付けるために使用されます。

Shared Address Space is similar to [RFC1918] private address space in that it is not globally routable address space and can be used by multiple pieces of equipment. However, Shared Address Space has limitations in its use that the current [RFC1918] private address space does not have. In particular, Shared Address Space can only be used in Service Provider networks or on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

共有アドレススペースは、グローバルにルーティング可能なアドレススペースではなく、複数の機器で使用できるという点で[RFC1918]プライベートアドレススペースに似ています。ただし、共有アドレススペースの使用には、現在の[RFC1918]プライベートアドレススペースにはない制限があります。特に、共有アドレススペースは、サービスプロバイダーネットワーク、またはアドレスが2つの異なるインターフェイスで同一である場合に、ルーターインターフェイス間でアドレス変換を実行できるルーティング機器でのみ使用できます。

This document requests the allocation of an IPv4 /10 address block to be used as Shared Address Space. In conversations with many ISPs, a /10 is the smallest block that will allow them to deploy CGNs on a regional basis without requiring nested CGNs. For instance, as described in [ISP-SHARED-ADDR], a /10 is sufficient to service Points of Presence in the Tokyo area.

このドキュメントは、共有アドレススペースとして使用されるIPv4 / 10アドレスブロックの割り当てを要求します。多くのISPとの会話では、/ 10は、ネストされたCGNを必要とせずに地域ベースでCGNを展開できる最小のブロックです。たとえば、[ISP-SHARED-ADDR]で説明されているように、東京エリアのPoint of Presenceにサービスを提供するには/ 10で十分です。

This document details the allocation of an additional special-use IPv4 address block and updates [RFC5735].

このドキュメントでは、追加の特殊用途IPv4アドレスブロックの割り当てと更新について詳しく説明します[RFC5735]。

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119].

このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"MAY"、および "OPTIONAL" は、RFC 2119 [RFC2119] で説明されているように解釈されるものとします。

The interfaces that connect CGN devices to CPE might conceivably be numbered from any of the following address spaces:

CGNデバイスをCPEに接続するインターフェイスには、次のアドレススペースから番号が付けられていると考えられます。

o legitimately assigned globally unique address space

o 正当に割り当てられたグローバルに一意のアドレス空間

o usurped globally unique address space (i.e., squat space) o [RFC1918] space

oグローバルに一意のアドレス空間（つまり、スクワット空間）を奪われたo [RFC1918]空間

o Shared Address Space

o 共有アドレス空間

A Service Provider can number the interfaces in question from legitimately assigned globally unique address space. While this solution poses the fewest problems, it is impractical because globally unique IPv4 address space is in short supply. While the Regional Internet Registries (RIRs) have enough address space to allocate a single /10 to be shared by all Service Providers, they do not have enough address space to make a unique assignment to each Service Provider.

サービスプロバイダーは、合法的に割り当てられたグローバルに一意のアドレススペースから問題のインターフェイスに番号を付けることができます。このソリューションがもたらす問題はほとんどありませんが、グローバルに一意のIPv4アドレス空間が不足しているため、実用的ではありません。リージョナルインターネットレジストリ（RIR）には、すべてのサービスプロバイダーで共有される単一の/ 10を割り当てるのに十分なアドレススペースがありますが、各サービスプロバイダーに一意の割り当てを行うのに十分なアドレススペースがありません。

Service Providers MUST NOT number the interfaces in question from usurped globally unique address space (i.e., squat space). If a Service Provider leaks advertisements for squat space into the global Internet, the legitimate holders of that address space may be adversely impacted, as would those wishing to communicate with them. Even if the Service Provider did not leak advertisements for squat space, the Service Provider and its subscribers might lose connectivity to the legitimate holders of that address space.

サービスプロバイダーは、奪われたグローバルに一意のアドレススペース（つまり、スクワットスペース）から問題のインターフェイスに番号を付けてはなりません（MUST NOT）。サービスプロバイダーがスクワットスペースのアドバタイズをグローバルインターネットに漏らした場合、そのアドレススペースの正当な所有者は、それらとの通信を希望する人と同様に、悪影響を受ける可能性があります。サービスプロバイダーがスクワットスペースのアドバタイズをリークしなかった場合でも、サービスプロバイダーとそのサブスクライバーは、そのアドレススペースの正当な所有者への接続を失う可能性があります。

A Service Provider can number the interfaces in question from [RFC1918] space if at least one of the following conditions is true:

次の条件の少なくとも1つが当てはまる場合、サービスプロバイダーは[RFC1918]空間から問題のインターフェイスに番号を付けることができます。

o The Service Provider knows that the CPE/NAT works correctly when the same [RFC1918] address block is used on both its inside and outside interfaces.

o サービスプロバイダーは、同じ[RFC1918]アドレスブロックが内部インターフェイスと外部インターフェイスの両方で使用されている場合にCPE/NATが正しく機能することを認識しています。

o The Service Provider knows that the [RFC1918] address block that it uses to number interfaces between the CGN and CPE is not used on the subscriber side of the CPE.

o サービスプロバイダーは、CGNとCPE間のインターフェイスに番号を付けるために使用する[RFC1918]アドレスブロックが、CPEのサブスクライバー側では使用されないことを認識しています。

Unless at least one of the conditions above is true, the Service Provider cannot safely use [RFC1918] address space and must resort to Shared Address Space. This is typically the case in an unmanaged service, where subscribers provide their own CPE and number their own internal network.

上記の条件の少なくとも1つが当てはまらない限り、サービスプロバイダーは[RFC1918]アドレススペースを安全に使用できず、共有アドレススペースに頼る必要があります。これは通常、加入者が独自のCPEを提供し、独自の内部ネットワークに番号を付ける管理されていないサービスの場合です。

Shared Address Space is IPv4 address space designated for Service Provider use with the purpose of facilitating CGN deployment. Also, Shared Address Space can be used as additional non-globally routable space on routing equipment that is able to do address translation across router interfaces when the addresses are identical on two different interfaces.

共有アドレススペースは、CGNの展開を容易にする目的でサービスプロバイダーが使用するために指定されたIPv4アドレススペースです。また、共有アドレススペースは、2つの異なるインターフェイスでアドレスが同一である場合に、ルーターインターフェイス間でアドレス変換を実行できるルーティング機器の追加の非グローバルルーティング可能なスペースとして使用できます。

Devices MUST be capable of performing address translation when identical Shared Address Space ranges are used on two different interfaces.

同一の共有アドレススペース範囲が2つの異なるインターフェイスで使用されている場合、デバイスはアドレス変換を実行できる必要があります。

Packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links. One exception to this paragraph's proscription is in the case of business relationships, such as hosted CGN services.

共有アドレススペースの送信元または宛先アドレスを持つパケットは、サービスプロバイダーの境界を越えて転送してはなりません。サービスプロバイダーは、入力リンクでそのようなパケットをフィルタリングする必要があります。この段落の禁止事項の1つの例外は、ホストされたCGNサービスなどのビジネス関係の場合です。

When running a single DNS infrastructure, Service Providers MUST NOT include Shared Address Space in zone files. When running a split DNS infrastructure, Service Providers MUST NOT include Shared Address Space in external-facing zone files.

単一のDNSインフラストラクチャを実行している場合、サービスプロバイダーはゾーンファイルに共有アドレススペースを含めてはなりません。分割DNSインフラストラクチャを実行する場合、サービスプロバイダーは、外部アドレスゾーンファイルに共有アドレススペースを含めてはなりません（MUST NOT）。

Reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure. DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers. This is done to avoid having to set up something similar to AS112.net for [RFC1918] private address space that a host has incorrectly sent for a DNS that reverse-maps queries on the public Internet [RFC6304].

共有アドレススペースアドレスの逆引きDNSクエリは、グローバルDNSインフラストラクチャに転送してはいけません。 DNSプロバイダーは、共有アドレススペースの要求をフィルターして、再帰的なネームサーバーでDNSクエリを逆にする必要があります（SHOULD）。これは、パブリックインターネット[RFC6304]でクエリを逆マッピングするDNSに対してホストが誤って送信した[RFC1918]プライベートアドレススペースに対してAS112.netのようなものをセットアップする必要を回避するために行われます。

Because CGN service requires non-overlapping address space on each side of the home NAT and CGN, entities using Shared Address Space for purposes other than for CGN service, as described in this document, are likely to experience problems implementing or connecting to CGN service at such time as they exhaust their supply of public IPv4 addresses.

CGNサービスはホームNATとCGNの両側で重複しないアドレススペースを必要とするため、このドキュメントで説明されているように、CGNサービス以外の目的で共有アドレススペースを使用するエンティティは、CGNサービスの実装または接続で問題が発生する可能性がありますパブリックIPv4アドレスの供給を使い果たしたときなど。

Some existing applications discover the outside address of their local CPE, determine whether the address is reserved for special use, and behave differently based on that determination. If a new IPv4 address block is reserved for special use and that block is used to number CPE outside interfaces, some of the above-mentioned applications may fail.

一部の既存のアプリケーションは、ローカルCPEの外部アドレスを検出し、アドレスが特別な使用のために予約されているかどうかを判断し、その判断に基づいて異なる動作をします。新しいIPv4アドレスブロックが特別な用途のために予約されており、そのブロックがCPE外部インターフェイスの番号付けに使用されている場合、上記のアプリケーションの一部が失敗する可能性があります。

For example, assume that an application requires its peer (or some other device) to initiate an incoming connection directly with its CPE's outside address. That application discovers the outside address of its CPE and determines whether that address is reserved for special use. If the address is reserved for special use, the application rightly concludes that the address is not reachable from the global Internet and behaves in one manner. If the address is not reserved for special use, the application assumes that the address is reachable from the global Internet and behaves in another manner.

たとえば、アプリケーションがピア（または他のデバイス）に、CPEの外部アドレスと直接着信接続を開始する必要があると仮定します。そのアプリケーションは、CPEの外部アドレスを検出し、そのアドレスが特別な使用のために予約されているかどうかを判断します。アドレスが特別な用途のために予約されている場合、アプリケーションはそのアドレスがグローバルインターネットから到達可能ではなく、1つの方法で動作すると正しく結論付けます。アドレスが特別な用途のために予約されていない場合、アプリケーションはそのアドレスがグローバルインターネットから到達可能であると見なし、別の方法で動作します。

While the assumption that a non-special-use address is reachable from the global Internet is generally safe, it is not always true (e.g., when the CPE outside interface is numbered from globally unique address space but that address is not advertised to the global Internet as when it is behind a CGN). Such an assumption could cause certain applications to behave incorrectly in those cases.

特別な用途を持たないアドレスにグローバルインターネットから到達可能であるという仮定は一般に安全ですが、常にそうであるとは限りません（たとえば、CPE外部インターフェイスにグローバルに一意のアドレス空間から番号が付けられているが、そのアドレスがグローバルにアドバタイズされていない場合） CGNの背後にあるときのようなインターネット）。このような仮定により、特定のアプリケーションがそれらの場合に正しく動作しない可能性があります。

The primary motivation for the allocation of Shared Address Space is as address space for CGNs; the use and impact of CGNs has been previously described in [RFC6269] and [NAT444-IMPACTS]. Some of the services adversely impacted by CGNs are as follows:

共有アドレス空間の割り当ての主な動機は、CGNのアドレス空間としてです。 CGNの使用と影響は、以前に[RFC6269]と[NAT444-IMPACTS]で説明されています。 CGNによって悪影響を受けるサービスの一部は次のとおりです。

1. Console gaming -- some games fail when two subscribers using the same outside public IPv4 address try to connect to each other.

1. コンソールゲーム-一部のゲームは、同じ外部パブリックIPv4アドレスを使用する2人のサブスクライバーが相互に接続しようとすると失敗します。

2. Video streaming -- performance is impacted when using one of several popular video-streaming technologies to deliver multiple video streams to users behind particular CPE routers.

2. ビデオストリーミング-いくつかの一般的なビデオストリーミングテクノロジーの1つを使用して、特定のCPEルーターの背後にいるユーザーに複数のビデオストリームを配信すると、パフォーマンスが影響を受けます。

3. Peer-to-peer -- some peer-to-peer applications cannot seed content due to the inability to open incoming ports through the CGN. Likewise, some SIP client implementations cannot receive incoming calls unless they first initiate outgoing traffic or open an incoming port through the CGN using the Port Control Protocol (PCP) [PCP-BASE] or a similar mechanism.

3. ピアツーピア-CGNを介して着信ポートを開くことができないため、一部のピアツーピアアプリケーションはコンテンツをシードできません。同様に、一部のSIPクライアント実装は、最初に発信トラフィックを開始するか、ポート制御プロトコル（PCP）[PCP-BASE]または同様のメカニズムを使用してCGNを通じて着信ポートを開かない限り、着信コールを受信できません。

4. Geo-location -- geo-location systems identify the location of the CGN server, not the end host.

4. 地理位置情報-地理位置情報システムは、エンドホストではなく、CGNサーバーの場所を識別します。

5. Simultaneous logins -- some websites (particularly banking and social-networking websites) restrict the number of simultaneous logins per outside public IPv4 address.

5. 同時ログイン-一部のWebサイト（特に銀行やソーシャルネットワーキングのWebサイト）では、外部パブリックIPv4アドレスごとの同時ログイン数が制限されています。

6. 6to4 -- 6to4 requires globally reachable addresses and will not work in networks that employ addresses with limited topological span, such as those employing CGNs.

6. 6to4-6to4はグローバルに到達可能なアドレスを必要とし、CGNを使用するアドレスなど、トポロジスパンが制限されたアドレスを使用するネットワークでは機能しません。

Based on testing documented in [NAT444-IMPACTS], the CGN impacts on items 1-5 above are comparable regardless of whether globally unique, Shared Address Space, or [RFC1918] addresses are used. There is, however, a difference between the three alternatives in the treatment of 6to4.

[NAT444-IMPACTS]で文書化されているテストに基づいて、グローバルに一意のアドレス、共有アドレススペース、または[RFC1918]アドレスが使用されているかどうかに関係なく、上記の1〜5に対するCGNの影響は同等です。ただし、6to4の処理では3つの選択肢の間に違いがあります。

As described in [RFC6343], CPE routers do not attempt to initialize 6to4 tunnels when they are configured with [RFC1918] or [RFC5735] WAN addresses. When configured with globally unique or Shared Address Space addresses, such devices may attempt to initiate 6to4, which would fail. Service Providers can mitigate this issue using 6to4 Provider Managed Tunnels [6to4-PMT] or blocking the route to 192.88.99.1 and generating an IPv4 'destination unreachable' message [RFC6343]. When the address range is well-defined, as with Shared Address Space, CPE router vendors can include Shared Address Space in their list of special-use addresses (e.g., [RFC5735]) and treat Shared Address Space similarly to [RFC1918] space. When the CGN-CPE address range is not well-defined, as in the case of globally unique space, it will be more difficult for CPE router vendors to mitigate this issue.

[RFC6343]で説明されているように、CPEルーターは、[RFC1918]または[RFC5735] WANアドレスで構成されている場合、6to4トンネルを初期化しようとしません。グローバルに一意のアドレスまたは共有アドレススペースアドレスで構成されている場合、そのようなデバイスは6to4を開始しようとする場合があり、失敗します。サービスプロバイダーは、6to4プロバイダー管理トンネル[6to4-PMT]を使用するか、192.88.99.1へのルートをブロックして、IPv4の「宛先に到達できない」メッセージ[RFC6343]を生成して、この問題を軽減できます。共有アドレススペースのようにアドレス範囲が明確に定義されている場合、CPEルーターベンダーは、特別な用途のアドレス（[RFC5735]など）のリストに共有アドレススペースを含め、[RFC1918]スペースと同様に共有アドレススペースを扱うことができます。 CGN-CPEアドレス範囲が明確に定義されていない場合、グローバルに一意のスペースの場合のように、CPEルーターベンダーがこの問題を軽減することはより困難になります。

Thus, when comparing the use of [RFC1918] and Shared Address Space, Shared Address Space poses an additional impact on 6to4 connectivity, which can be mitigated by Service Provider or CPE router vendor action. On the other hand, the use of [RFC1918] address space poses more of a challenge vis-a-vis Shared Address Space when the subscriber and Service Provider use overlapping [RFC1918] space, which will be outside the Service Provider's control in the case of unmanaged service. Service Providers have indicated that it is more challenging to mitigate the possibility of overlapping [RFC1918] address space on both sides of the CPE router than it is to mitigate the 6to4 impacts of Shared Address Space.

したがって、[RFC1918]と共有アドレススペースの使用を比較すると、共有アドレススペースは6to4接続に追加の影響を与えます。これは、サービスプロバイダーまたはCPEルーターベンダーのアクションによって軽減できます。一方、[RFC1918]アドレススペースを使用すると、サブスクライバーとサービスプロバイダーが重複する[RFC1918]スペースを使用する場合、共有アドレススペースに対してより多くの課題が発生します。この場合、サービスプロバイダーの制御範囲外になります。管理されていないサービスの。サービスプロバイダーは、CPEルーターの両側で[RFC1918]アドレススペースが重複する可能性を軽減することは、共有アドレススペースの6to4への影響を軽減することよりも難しいことを示しています。

Similar to other [RFC5735] special-use IPv4 addresses, Shared Address Space does not directly raise security issues. However, the Internet does not inherently protect against abuse of these addresses. Attacks have been mounted that depend on the unexpected use of similar special-use addresses. Network operators are encouraged to review this document and determine what security policies should be associated with this address block within their specific operating environments. They should consider including Shared Address Space in Ingress Filter lists [RFC3704], unless their Internet service incorporates a CGN.

他の[RFC5735]特殊用途IPv4アドレスと同様に、共有アドレススペースは直接セキュリティ問題を引き起こしません。ただし、インターネットは本質的にこれらのアドレスの乱用から保護しません。同様の特殊用途アドレスの予期しない使用に依存する攻撃が行われています。ネットワークオペレーターは、このドキュメントを確認し、特定の運用環境内でこのアドレスブロックに関連付ける必要のあるセキュリティポリシーを決定することをお勧めします。インターネットサービスにCGNが組み込まれていない限り、入力フィルターリストに共有アドレススペースを含めることを検討する必要があります[RFC3704]。

To mitigate potential misuse of Shared Address Space, except where required for hosted CGN service or a similar business relationship,

ホストされたCGNサービスまたは同様のビジネス関係に必要な場合を除き、共有アドレススペースの誤用の可能性を軽減するため、

o routing information about Shared Address Space networks MUST NOT be propagated across Service Provider boundaries. Service Providers MUST filter incoming advertisements regarding Shared Address Space.

o 共有アドレススペースネットワークに関するルーティング情報は、サービスプロバイダーの境界を越えて伝播してはなりません。サービスプロバイダーは、共有アドレススペースに関する着信広告をフィルタリングする必要があります。

o packets with Shared Address Space source or destination addresses MUST NOT be forwarded across Service Provider boundaries. Service Providers MUST filter such packets on ingress links.

o 共有アドレススペースの送信元または宛先アドレスを持つパケットは、サービスプロバイダーの境界を越えて転送してはなりません。サービスプロバイダーは、入力リンクでそのようなパケットをフィルタリングする必要があります。

o Service Providers MUST NOT include Shared Address Space in external-facing DNS zone files.

o サービスプロバイダーは、外部向けDNSゾーンファイルに共有アドレススペースを含めてはなりません。

o reverse DNS queries for Shared Address Space addresses MUST NOT be forwarded to the global DNS infrastructure.

o 共有アドレススペースアドレスに対する逆DNSクエリは、グローバルDNSインフラストラクチャに転送してはなりません。

o DNS Providers SHOULD filter requests for Shared Address Space reverse DNS queries on recursive nameservers.

o DNSプロバイダーは、共有アドレススペースの要求をフィルターして、再帰的なネームサーバーでDNSクエリを逆にする必要があります（SHOULD）。

IANA has recorded the allocation of an IPv4 /10 for use as Shared Address Space.

IANAは、共有アドレススペースとして使用するためのIPv4 / 10の割り当てを記録しています。

The Shared Address Space address range is 100.64.0.0/10.

共有アドレススペースのアドレス範囲は100.64.0.0/10です。

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

[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, G., and E. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119] Bradner, S.、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。

[RFC5735] Cotton, M. and L. Vegoda, "Special Use IPv4 Addresses", BCP 153, RFC 5735, January 2010.

[RFC5735] Cotton, M. and L. Vegoda、「特別な用途のIPv4アドレス」、BCP 153、RFC 5735、2010年1月。

[6to4-PMT] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin, "6to4 Provider Managed Tunnels", Work in Progress, February 2012.

[6to4-PMT] Kuarsingh, V., Ed., Lee, Y., and O. Vautrin、「6to4 Provider Managed Tunnels」、Work in Progress、2012年2月。

[ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida, "ISP Shared Address", Work in Progress, January 2012.

[ISP-SHARED-ADDR] Yamagata, I., Miyakawa, S., Nakagawa, A., Yamaguchi, J., and H. Ashida、「ISP共有アドレス」、2012年1月、作業中。

[NAT444-IMPACTS] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi, "Assessing the Impact of Carrier-Grade NAT on Network Applications", Work in Progress, November 2011.

[NAT444-IMPACTS] Donley, C., Howard, L., Kuarsingh, V., Berg, J., and J. Doshi、「Assessing Carrier-Grade NAT of Network Applications on Network Applications」、Work in Progress、2011年11月。

[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", Work in Progress, March 2012.

[PCP-BASE] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol（PCP）"、Work in Progress、2012年3月。

[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.

[RFC3704] Baker, F. and P. Savola、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。

[RFC6264] Jiang, S., Guo, D., and B. Carpenter, "An Incremental Carrier-Grade NAT (CGN) for IPv6 Transition", RFC 6264, June 2011.

[RFC6264] Jiang, S., Guo, D., and B. Carpenter、「IPv6移行のための増分キャリアグレードNAT（CGN）」、RFC 6264、2011年6月。

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011.

[RFC6269] Ford, M., Ed., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing"、RFC 6269、June 2011。

[RFC6304] Abley, J. and W. Maton, "AS112 Nameserver Operations", RFC 6304, July 2011.

[RFC6304] Abley, J. and W. Maton、「AS112 Nameserver Operations」、RFC 6304、2011年7月。

[RFC6343] Carpenter, B., "Advisory Guidelines for 6to4 Deployment", RFC 6343, August 2011.

[RFC6343] Carpenter, B.、「6to4展開に関する勧告ガイドライン」、RFC 6343、2011年8月。

Thanks to the following people (in alphabetical order) for their guidance and feedback:

ガイダンスとフィードバックを提供してくれた以下の人々（アルファベット順）に感謝します。

Stan Barber John Brzozowski Isaiah Connell Greg Davies Owen DeLong Kirk Erichsen Wes George Chris Grundemann Tony Hain Philip Matthews John Pomeroy Barbara Stark Jean-Francois Tremblay Leo Vegoda Steven Wright Ikuhei Yamagata

スタンバーバージョンブルゾゾフスキーイザヤコネルグレッグデイビスオーウェンデロングカークエリクセンウェスジョージクリスグルンデマントニーハインフィリップマシューズジョンポメロイバーバラスタークジャンフランソワトランブレレオベゴダスティーブンライト山形郁平

Authors' Addresses

著者のアドレス

Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon, VA 20171 USA

Jason Weil Time Warner Cable 13820 Sunrise Valley Drive Herndon、VA 20171 USA

   EMail: jason.weil@twcable.com
        

Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton, ON L6T 0C1 Canada

Victor Kuarsingh Rogers Communications 8200 Dixie Road Brampton、ON L6T 0C1 Canada

   EMail: victor.kuarsingh@gmail.com
        

Chris Donley CableLabs 858 Coal Creek Circle Louisville, CO 80027 USA

Chris Donley CableLabs 858 Coal Creek Circle Louisville、CO 80027 USA

   EMail: c.donley@cablelabs.com
        

Christopher Liljenstolpe Telstra Corp. 7/242 Exhibition Street Melbourne, VIC 316 Australia

Christopher Liljenstolpe Telstra Corp. 7/242 Exhibition Streetメルボルン、VIC 316オーストラリア

   Phone: +61 3 8647 6389
   EMail: cdl@asgaard.org
        

Marla Azinger Frontier Communications Vancouver, WA USA

マーラアジンガーフロンティアコミュニケーションズバンクーバー、米国

   Phone: +1.360.513.2293
   EMail: marla.azinger@frontiercorp.com