RFC 6888 - Common Requirements for Carrier-Grade NATs (CGNs) 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc6888
タイトル : RFC 6888 - キャリアグレードNAT（CGN）の一般的な要件
翻訳編集 : 自動生成

[要約] RFC 6888は、キャリアグレードNAT（CGN）の共通要件に関する規格であり、大規模なネットワーク環境でのNATの効果的な運用を目指しています。このRFCの目的は、CGNの設計と実装に関するガイドラインを提供し、インターネットの持続的な成長とIPv4アドレス枯渇の問題に対処することです。

Internet Engineering Task Force (IETF)                 S. Perreault, Ed.
Request for Comments: 6888                                      Viagenie
BCP: 127                                                     I. Yamagata
Updates: 4787                                                S. Miyakawa
Category: Best Current Practice                       NTT Communications
ISSN: 2070-1721                                              A. Nakagawa
                                          Japan Internet Exchange (JPIX)
                                                               H. Ashida
                                                           Cisco Systems
                                                              April 2013

Common Requirements for Carrier-Grade NATs (CGNs)

キャリアグレードNAT（CGN）の一般的な要件

Abstract

概要

This document defines common requirements for Carrier-Grade NATs (CGNs). It updates RFC 4787.

このドキュメントでは、キャリアグレードのNAT（CGN）の一般的な要件を定義しています。 RFC 4787を更新します。

Status of This Memo

本文書の状態

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/rfc6888.

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

著作権表示

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. Terminology  . . . . . . . . . . . . . . . . . . . . . . . .  3
   3. Requirements for CGNs  . . . . . . . . . . . . . . . . . . .  4
   4. Logging  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
   5. Port Allocation Scheme . . . . . . . . . . . . . . . . . . . 11
   6. Deployment Considerations  . . . . . . . . . . . . . . . . . 11
   7. Security Considerations  . . . . . . . . . . . . . . . . . . 12
   8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12
   9. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
      9.1. Normative References  . . . . . . . . . . . . . . . . . 12
      9.2. Informative Reference . . . . . . . . . . . . . . . . . 13

1. Introduction

1. はじめに

With the shortage of IPv4 addresses, it is expected that more Internet Service Providers (ISPs) may want to provide a service where a public IPv4 address would be shared by many subscribers. Each subscriber is assigned a private address, and a Network Address Translator (NAT) [RFC2663] situated in the ISP's network translates the traffic between private and public addresses. When a second IPv4 NAT is located at the customer edge, this results in two layers of NAT.

IPv4アドレスが不足しているため、より多くのインターネットサービスプロバイダー（ISP）が、パブリックIPv4アドレスが多くの加入者によって共有されるサービスを提供することを望む可能性があります。各加入者にはプライベートアドレスが割り当てられ、ISPのネットワーク内にあるネットワークアドレス変換（NAT）[RFC2663]はプライベートアドレスとパブリックアドレス間のトラフィックを変換します。 2番目のIPv4 NATがカスタマーエッジにある場合、NATの2つの層になります。

This service can conceivably be offered alongside others, such as IPv6 services or regular IPv4 service assigning public addresses to subscribers. Some ISPs started offering such a service long before there was a shortage of IPv4 addresses, showing that there are driving forces other than the shortage of IPv4 addresses. One approach to CGN deployment is described in [RFC6264].

このサービスは、IPv6サービスや、加入者にパブリックアドレスを割り当てる通常のIPv4サービスなど、他のサービスと一緒に提供できると考えられます。一部のISPは、IPv4アドレスが不足するずっと前にそのようなサービスの提供を開始し、IPv4アドレスの不足以外に原動力があることを示しています。 CGN展開への1つのアプローチは、[RFC6264]で説明されています。

This document describes behavior that is required of those multi-subscriber NATs for interoperability. It is not an IETF endorsement of CGNs or a real specification for CGNs; rather, it is just a minimal set of requirements that will increase the likelihood of applications working across CGNs.

このドキュメントでは、相互運用性のためにこれらのマルチサブスクライバNATに必要な動作について説明します。これは、CGNのIETF推奨またはCGNの実際の仕様ではありません。むしろ、アプリケーションがCGN間で動作する可能性を高めるのは、最小限の要件のセットにすぎません。

Because subscribers do not receive unique IPv4 addresses, Carrier-Grade NATs introduce substantial limitations in communications between subscribers and with the rest of the Internet. In particular, it is considerably more involved to establish proxy functionality at the border between internal and external realms. Some applications may require substantial enhancements, while some others may not function at all in such an environment. Please see "Issues with IP Address Sharing" [RFC6269] for details.

加入者は一意のIPv4アドレスを受信しないため、キャリアグレードのNATは、加入者間および残りのインターネットとの通信に実質的な制限をもたらします。特に、内部レルムと外部レルムの境界でプロキシ機能を確立することは、かなり複雑です。一部のアプリケーションは大幅な拡張を必要とする場合がありますが、そのような環境ではまったく機能しないアプリケーションもあります。詳細については、「IPアドレス共有の問題」[RFC6269]を参照してください。

This document builds upon previous works describing requirements for generic NATs [RFC4787][RFC5382][RFC5508]. These documents, and their updates if any, still apply in this context. What follows are additional requirements, to be satisfied on top of previous ones.

このドキュメントは、ジェネリックNAT [RFC4787] [RFC5382] [RFC5508]の要件を説明する以前の作品に基づいています。これらのドキュメント、および更新がある場合は、このコンテキストにも適用されます。以下は、以前の要件に加えて満たされる追加の要件です。

2. Terminology

2. 用語

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 [RFC2119].

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

Readers are expected to be familiar with "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP" [RFC4787] and the terms defined there. The following additional term is used in this document:

読者は、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」[RFC4787]とそこで定義されている用語に精通している必要があります。このドキュメントでは、次の追加用語が使用されています。

Carrier-Grade NAT (CGN): A NAT-based [RFC2663] logical function used to share the same IPv4 address among several subscribers. A CGN is not managed by the subscribers.

キャリアグレードNAT（CGN）：複数のサブスクライバー間で同じIPv4アドレスを共有するために使用されるNATベースの[RFC2663]論理機能。 CGNは加入者によって管理されません。

Note that the term "carrier-grade" has nothing to do with the quality of the NAT; that is left to discretion of implementers. Rather, it is to be understood as a topological qualifier: the NAT is placed in an ISP's network and translates the traffic of potentially many subscribers. Subscribers have limited or no control over the CGN, whereas they typically have full control over a NAT placed on their premises.

「キャリアグレード」という用語は、NATの品質とは関係がないことに注意してください。それは実装者の裁量に任されています。むしろ、それはトポロジー修飾子として理解されるべきです。NATはISPのネットワークに配置され、潜在的に多くの加入者のトラフィックを変換します。サブスクライバーは、CGNに対する制御が制限されているか、制御されていませんが、通常、構内に配置されたNATを完全に制御できます。

Note also that the CGN described in this document is IPv4-only. IPv6 address translation is not considered.

このドキュメントで説明するCGNはIPv4のみであることにも注意してください。 IPv6アドレス変換は考慮されません。

However, the scenario in which the IPv4-only CGN logical function is used may include IPv6 elements. For example, Dual-Stack Lite (DS-Lite) [RFC6333] uses an IPv4-only CGN logical function in a scenario making use of IPv6 encapsulation. Therefore, this document would also apply to the CGN part of DS-Lite.

ただし、IPv4のみのCGN論理関数が使用されるシナリオには、IPv6要素が含まれる場合があります。たとえば、Dual-Stack Lite（DS-Lite）[RFC6333]は、IPv6カプセル化を利用するシナリオでIPv4のみのCGN論理関数を使用します。したがって、このドキュメントはDS-LiteのCGN部分にも適用されます。

Figure 1 summarizes a common network topology in which a CGN operates.

図1は、CGNが動作する一般的なネットワークトポロジをまとめたものです。

                                   .
                                   :
                                   |       Internet
                   ............... | ...................
                                   |       ISP network
                   External pool:  |
                   192.0.2.1/26    |
                               ++------++  External realm
                   ........... |  CGN   |...............
                               ++------++  Internal realm
                        10.0.0.1 |    |
                                 |    |
                                 |    |    ISP network
                   ............. | .. | ................
                                 |    |  Customer premises
                      10.0.0.100 |    | 10.0.0.101
                         ++------++  ++------++
                         |  CPE1  |  |  CPE2  |  etc.
                         ++------++  ++------++

(IP addresses are only for example purposes)

（IPアドレスは例示のみを目的としています）

Figure 1: CGN Network Topology

図1：CGNネットワークトポロジ

Another possible topology is one for hotspots, where there is no customer premise or customer premises equipment (CPE), but where a CGN serves a bunch of customers who don't trust each other; hence, fairness is an issue. One important difference with the previous topology is the absence of a second layer of NAT. This, however, has no impact on CGN requirements since they are driven by fairness and robustness in the service provided to customers, which applies in both cases.

別の可能なトポロジは、顧客の構内または顧客の構内機器（CPE）がないホットスポット用のトポロジですが、CGNは互いに信頼していない多数の顧客にサービスを提供します。したがって、公平性が問題になります。以前のトポロジとの重要な違いの1つは、NATの第2層がないことです。ただし、CGN要件は顧客に提供されるサービスの公平性と堅牢性によって左右されるため、どちらの場合にも適用されます。

3. Requirements for CGNs

3. CGNの要件

What follows is a list of requirements for CGNs. They are in addition to those found in other documents such as [RFC4787], [RFC5382], and [RFC5508].

以下は、CGNの要件のリストです。これらは、[RFC4787]、[RFC5382]、[RFC5508]などの他のドキュメントにあるものに追加されます。

REQ-1: If a CGN forwards packets containing a given transport protocol, then it MUST fulfill that transport protocol's behavioral requirements. Current applicable documents are as follows:

REQ-1：CGNが特定のトランスポートプロトコルを含むパケットを転送する場合、そのトランスポートプロトコルの動作要件を満たさなければなりません（MUST）。現在該当するドキュメントは次のとおりです。

a. "NAT Behavioral Requirements for Unicast UDP" [RFC4787] b. "Network Address Translation (NAT) Behavioral Requirements for TCP" [RFC5382]

a。「ユニキャストUDPのNAT動作要件」[RFC4787] b。「TCPのネットワークアドレス変換（NAT）動作要件」[RFC5382]

c. "NAT Behavioral Requirements for ICMP" [RFC5508]

c. 「ICMPのNAT動作要件」[RFC5508]

d. "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol (DCCP)" [RFC5597]

d. 「ネットワークアドレス変換（NAT）データグラム輻輳制御プロトコル（DCCP）の動作要件」[RFC5597]

Any future NAT behavioral requirements documents for IPv4 transport protocols will impose additional requirements for CGNs on top of those stated here.

IPv4トランスポートプロトコルの将来のNAT動作要件ドキュメントでは、ここに記載されているものに加えて、CGNに追加の要件が課されます。

Justification: It is crucial for CGNs to maximize the set of applications that can function properly across them. The IETF has documented the best current practices for UDP, TCP, ICMP, and DCCP.

正当化：CGNが正しく機能できるアプリケーションのセットを最大化することはCGNにとって重要です。 IETFは、UDP、TCP、ICMP、およびDCCPの現在のベストプラクティスを文書化しています。

REQ-2: A CGN MUST have a default "IP address pooling" behavior of "Paired" (as defined in Section 4.1 of [RFC4787]). A CGN MAY provide a mechanism for administrators to change this behavior on an application protocol basis.

REQ-2：CGNには、[ペア]のデフォルトの[IPアドレスプーリング]動作が必要です（[RFC4787]のセクション4.1で定義）。 CGNは、管理者がアプリケーションプロトコルベースでこの動作を変更するためのメカニズムを提供する場合があります。

* When multiple overlapping internal IP address ranges share the same external IP address pool (e.g., DS-Lite [RFC6333]), the "IP address pooling" behavior applies to mappings between external IP addresses and internal subscribers rather than between external and internal IP addresses.

* 複数の重複する内部IPアドレス範囲が同じ外部IPアドレスプール（DS-Lite [RFC6333]など）を共有する場合、「IPアドレスプーリング」の動作は、外部IPアドレスと内部IPアドレスの間ではなく、外部IPアドレスと内部サブスクライバー間のマッピングに適用されます。

Justification: This stronger form of REQ-2 from [RFC4787] is justified by the stronger need for not breaking applications that depend on the external address remaining constant.

正当化：[RFC4787]からのこのより強力な形式のREQ-2は、外部アドレスが一定のままであることに依存するアプリケーションを壊さないという強い必要性によって正当化されます。

Note that this requirement applies regardless of the transport protocol. In other words, a CGN must use the same external IP address mapping for all sessions associated with the same internal IP address, be they TCP, UDP, ICMP, something else, or a mix of different protocols.

この要件は、トランスポートプロトコルに関係なく適用されることに注意してください。つまり、CGNは、TCP、UDP、ICMP、その他、または異なるプロトコルの組み合わせなど、同じ内部IPアドレスに関連付けられたすべてのセッションに同じ外部IPアドレスマッピングを使用する必要があります。

The justification for allowing other behaviors is to allow the administrator to save external addresses and ports for application protocols that are known to work fine with other behaviors in practice. However, the default behavior MUST be "Paired".

他の動作を許可する理由は、管理者が実際に他の動作で正常に動作することがわかっているアプリケーションプロトコルの外部アドレスとポートを保存できるようにすることです。ただし、デフォルトの動作は「ペア」である必要があります。

REQ-3: The CGN function SHOULD NOT have any limitations on the size or the contiguity of the external address pool. In particular, the CGN function MUST be configurable with contiguous or non-contiguous external IPv4 address ranges.

REQ-3：CGN関数は、外部アドレスプールのサイズまたは連続性に制限があってはなりません（SHOULD NOT）。特に、CGN関数は、連続または非連続の外部IPv4アドレス範囲で構成可能でなければなりません。

Justification: Given the increasing rarity of IPv4 addresses, it is becoming harder for an operator to provide large contiguous address pools to CGNs. Additionally, operational flexibility may require non-contiguous address pools for reasons such as differentiated services, routing management, etc.

正当化：IPv4アドレスの希少性が高まっていることを考えると、オペレーターがCGNに大きな連続したアドレスプールを提供することは困難になっています。さらに、運用の柔軟性には、差別化されたサービス、ルーティング管理などの理由により、不連続なアドレスプールが必要になる場合があります。

The reason for having SHOULD instead of MUST is to account for limitations imposed by available resources as well as constraints imposed for security reasons.

「MUST」の代わりに「SHOULD」を使用する理由は、利用可能なリソースによって課される制限と、セキュリティ上の理由によって課される制約を説明するためです。

REQ-4: A CGN MUST support limiting the number of external ports (or, equivalently, "identifiers" for ICMP) that are assigned per subscriber.

REQ-4：CGNは、サブスクライバーごとに割り当てられる外部ポート（または、ICMPの「識別子」）の数の制限をサポートする必要があります。

a. Per-subscriber limits MUST be configurable by the CGN administrator.

a. サブスクライバーごとの制限は、CGN管理者が構成可能でなければなりません。

b. Per-subscriber limits MAY be configurable independently per transport protocol.

b. サブスクライバーごとの制限は、トランスポートプロトコルごとに個別に構成できます。

c. Additionally, it is RECOMMENDED that the CGN include administrator-adjustable thresholds to prevent a single subscriber from consuming excessive CPU resources from the CGN (e.g., rate-limit the subscriber's creation of new mappings).

c. さらに、CGNに管理者が調整可能なしきい値を含めて、単一のサブスクライバーがCGNからの過剰なCPUリソースを消費しないようにすることをお勧めします（たとえば、サブスクライバーによる新しいマッピングの作成をレート制限します）。

Justification: A CGN can be considered a network resource that is shared by competing subscribers. Limiting the number of external ports assigned to each subscriber mitigates the denial-of-service (DoS) attack that a subscriber could launch against other subscribers through the CGN in order to get a larger share of the resource. It ensures fairness among subscribers. Limiting the rate of allocation mitigates a similar attack where the CPU is the resource being targeted instead of port numbers. However, this requirement is not a MUST because it is very hard to explicitly call out all CPU-consuming events.

正当化：CGNは、競合する加入者が共有するネットワークリソースと考えることができます。各サブスクライバーに割り当てられた外部ポートの数を制限すると、リソースのより大きな共有を取得するために、サブスクライバーがCGNを介して他のサブスクライバーに対して起動できるサービス拒否（DoS）攻撃が軽減されます。加入者間の公平性を保証します。割り当て率を制限すると、ポート番号の代わりにCPUが対象のリソースである同様の攻撃が緩和されます。ただし、CPUを消費するすべてのイベントを明示的に呼び出すことは非常に難しいため、この要件は必須ではありません。

REQ-5: A CGN SHOULD support limiting the amount of state memory allocated per mapping and per subscriber. This may include limiting the number of sessions, the number of filters, etc., depending on the NAT implementation.

REQ-5：CGNは、マッピングごとおよびサブスクライバーごとに割り当てられる状態メモリの量を制限することをサポートする必要があります（SHOULD）。これには、NAT実装に応じて、セッション数、フィルター数などの制限が含まれる場合があります。

a. Limits SHOULD be configurable by the CGN administrator.

a. 制限は、CGN管理者が構成できる必要があります（SHOULD）。

b. Additionally, it SHOULD be possible to limit the rate at which memory-consuming state elements are allocated.

b. さらに、メモリを消費する状態要素が割り当てられるレートを制限することが可能であるべきです（SHOULD）。

Justification: A NAT needs to keep track of TCP sessions associated with each mapping. This state consumes resources for which, in the case of a CGN, subscribers may compete. It is necessary to ensure that each subscriber has access to a fair share of the CGN's resources. Limiting the rate of allocation is intended to prevent CPU resource exhaustion. Item "B" is at the SHOULD level to account for the fact that means other than rate limiting may be used to attain the same goal.

根拠：NATは、各マッピングに関連付けられたTCPセッションを追跡する必要があります。この状態は、CGNの場合、加入者が競合する可能性のあるリソースを消費します。各サブスクライバーがCGNのリソースの公平なシェアにアクセスできるようにする必要があります。割り当て率の制限は、CPUリソースの枯渇を防ぐことを目的としています。アイテム「B」は、レート制限以外の手段を使用して同じ目標を達成できることを説明するために、SHOULDレベルにあります。

REQ-6: It MUST be possible to administratively turn off translation for specific destination addresses and/or ports.

REQ-6：特定の宛先アドレスやポートの変換を管理上オフにできる必要があります。

Justification: It is common for a CGN administrator to provide access for subscribers to servers installed in the ISP's network in the external realm. When such a server is able to reach the internal realm via normal routing (which is entirely controlled by the ISP), translation is unneeded. In that case, the CGN may forward packets without modification, thus acting like a plain router. This may represent an important efficiency gain.

正当性：CGN管理者が外部レルムのISPのネットワークにインストールされたサーバーへの加入者にアクセスを提供することは一般的です。このようなサーバーが通常のルーティング（ISPによって完全に制御される）を介して内部レルムに到達できる場合、変換は不要です。その場合、CGNは変更なしでパケットを転送するため、通常のルーターのように動作します。これは、重要な効率向上を表す場合があります。

Figure 2 illustrates this use-case.

図2は、この使用例を示しています。

                  X1:x1            X1':x1'            X2:x2
                  +---+from X1:x1  +---+from X1:x1    +---+
                  | C |  to X2:x2  |   |  to X2:x2    | S |
                  | l |>>>>>>>>>>>>| C |>>>>>>>>>>>>>>| e |
                  | i |            | G |              | r |
                  | e |<<<<<<<<<<<<| N |<<<<<<<<<<<<<<| v |
                  | n |from X2:x2  |   |from X2:x2    | e |
                  | t |  to X1:x1  |   |  to X1:x1    | r |
                  +---+            +---+              +---+

Figure 2: CGN Pass-Through

図2：CGNパススルー

REQ-7: It is RECOMMENDED that a CGN use an "endpoint-independent filtering" behavior (as defined in Section 5 of [RFC4787]). If it is known that "Address-Dependent Filtering" does not cause the application-layer protocol to break (how to determine this is out of scope for this document), then it MAY be used instead.

REQ-7：CGNが（[RFC4787]のセクション5で定義されている）「エンドポイントに依存しないフィルタリング」動作を使用することをお勧めします。「アドレス依存フィルタリング」がアプリケーション層プロトコルを中断させないことがわかっている場合（これがこのドキュメントの範囲外であると判断する方法）、代わりにそれを使用できます（MAY）。

Justification: This is a stronger form of REQ-8 from [RFC4787]. This is based on the observation that some games and peer-to-peer applications require EIF for the NAT traversal to work. In the context of a CGN, it is important to minimize application breakage.

正当化：これは、[RFC4787]のREQ-8のより強力な形式です。これは、一部のゲームおよびピアツーピアアプリケーションが、NATトラバーサルが機能するためにEIFを必要とするという観察に基づいています。 CGNのコンテキストでは、アプリケーションの破損を最小限に抑えることが重要です。

REQ-8: Once an external port is deallocated, it SHOULD NOT be reallocated to a new mapping until at least 120 seconds have passed, with the exceptions being:

REQ-8：外部ポートが割り当て解除されると、次の例外を除いて、少なくとも120秒が経過するまで、新しいマッピングに再割り当てしないでください。

a. If the CGN tracks TCP sessions (e.g., with a state machine, as in Section 3.5.2.2 of [RFC6146]), TCP ports MAY be reused immediately.

a. CGNがTCPセッションを追跡する場合（例：[RFC6146]のセクション3.5.2.2のように、ステートマシンを使用）、TCPポートはすぐに再利用できます（MAY）。

b. If external ports are statically assigned to internal addresses (e.g., address X with port range 1000-1999 is assigned to subscriber A, 2000-2999 to subscriber B, etc.), and the assignment remains constant across state loss, then ports MAY be reused immediately.

b. 外部ポートが内部アドレスに静的に割り当てられており（たとえば、ポート範囲1000-1999のアドレスXがサブスクライバーAに割り当てられ、2000-2999がサブスクライバーBに割り当てられているなど）、割り当ては状態損失全体で一定のままである場合、ポートはすぐに再利用。

c. If the allocated external ports used address-dependent or address-and-port-dependent filtering before state loss, they MAY be reused immediately.

c. 割り当てられた外部ポートが状態損失の前にアドレス依存またはアドレスとポート依存のフィルタリングを使用した場合、それらはすぐに再利用できます。

The length of time and the maximum number of ports in this state MUST be configurable by the CGN administrator.

この状態での時間の長さとポートの最大数は、CGN管理者が構成可能でなければなりません。

Justification: This is necessary in order to prevent collisions between old and new mappings and sessions. It ensures that all established sessions are broken instead of redirected to a different peer.

正当化：これは、古いマッピングと新しいマッピングおよびセッション間の衝突を防ぐために必要です。これにより、別のピアにリダイレクトされる代わりに、確立されたすべてのセッションが確実に切断されます。

The exceptions are for cases where reusing a port immediately does not create a possibility that packets would be redirected to the wrong peer. One can imagine other exceptions where mapping collisions are avoided, thus justifying the SHOULD level for this requirement.

例外は、ポートを再利用してもすぐにパケットが間違ったピアにリダイレクトされる可能性が生じない場合です。マッピングの衝突が回避される他の例外を想像して、この要件のレベルを正当化する必要があります。

The 120 seconds value corresponds to the Maximum Segment Lifetime (MSL) from [RFC0793].

120秒の値は、[RFC0793]の最大セグメント寿命（MSL）に対応しています。

Note that this requirement also applies to the case when a CGN loses state (due to a crash, reboot, failover to a cold standby, etc.). In that case, ports that were in use at the time of state loss SHOULD NOT be reallocated until at least 120 seconds have passed.

この要件は、CGNが状態を失った場合（クラッシュ、再起動、コールドスタンバイへのフェイルオーバーなど）にも適用されることに注意してください。その場合、状態が失われたときに使用されていたポートは、少なくとも120秒が経過するまで再割り当てしないでください。

REQ-9: A CGN MUST implement a protocol giving subscribers explicit control over NAT mappings. That protocol SHOULD be the Port Control Protocol [RFC6887].

REQ-9：CGNは、NATマッピングをサブスクライバーに明示的に制御させるプロトコルを実装する必要があります。そのプロトコルはポート制御プロトコル[RFC6887]であるべきです（SHOULD）。

Justification: Allowing subscribers to manipulate the NAT state table with PCP greatly increases the likelihood that applications will function properly.

正当化：サブスクライバーがPCPを使用してNAT状態テーブルを操作できるようにすると、アプリケーションが正しく機能する可能性が大幅に高まります。

A study of PCP-less CGN impacts can be found in [NAT444]. Another study considering the effects of PCP on a peer-to-peer file sharing protocol can be found in [BITTORRENT].

PCPなしのCGNの影響に関する研究は、[NAT444]にあります。 PCPがピアツーピアのファイル共有プロトコルに及ぼす影響を検討する別の研究は、[BITTORRENT]にあります。

REQ-10: CGN implementers SHOULD make their equipment manageable. Standards-based management using standards such as "Definitions of Managed Objects for NAT" [RFC4008] is RECOMMENDED.

REQ-10：CGNの実装者は、機器を管理しやすくする必要があります（SHOULD）。「NATの管理対象オブジェクトの定義」[RFC4008]などの標準を使用した標準ベースの管理が推奨されます。

Justification: It is anticipated that CGNs will be primarily deployed in ISP networks where the need for management is critical. This requirement is at the SHOULD level to account for the fact that some CGN operators may not need management functionality.

正当化：CGNは、主に管理の必要性が重要であるISPネットワークに展開されることが予想されます。この要件は、一部のCGNオペレーターが管理機能を必要としない場合があることを考慮して、SHOULDレベルにあります。

Note also that there are efforts within the IETF toward creating a MIB tailored for CGNs (e.g., [NAT-MIB]).

また、IETF内では、CGNに合わせて調整されたMIB（[NAT-MIB]など）を作成する取り組みも行われています。

REQ-11: When a CGN is unable to create a dynamic mapping due to resource constraints or administrative restrictions (i.e., quotas):

REQ-11：リソースの制約または管理上の制限（つまり、割り当て）が原因でCGNが動的マッピングを作成できない場合：

a. it MUST drop the original packet;

a. 元のパケットをドロップする必要があります。

b. it SHOULD send an ICMP Destination Unreachable message with code 1 (Host Unreachable) to the sender;

b. コード1（Host Unreachable）のICMP Destination Unreachableメッセージを送信者に送信する必要があります。

c. it SHOULD send a notification (e.g., SNMP trap) towards a management system (if configured to do so); and

c. 管理システムに向けて通知（SNMPトラップなど）を送信する必要があります（設定されている場合）。そして

d. it MUST NOT delete existing mappings in order to "make room" for the new one. (This only applies to normal CGN behavior, not to manual operator intervention.)

d. 新しいマッピングのために「スペースを空ける」ために、既存のマッピングを削除してはなりません。（これは通常のCGN動作にのみ適用され、オペレーターの手動介入には適用されません。）

Justification: This is a slightly different form of REQ-8 from [RFC5508]. Code 1 is preferred to code 13 because it is listed as a "soft error" in [RFC1122], which is important because we don't want TCP stacks to abort the connection attempt in this case. See [RFC5461] for details on TCP's reaction to soft errors.

正当化：これは、[RFC5508]とは少し異なるREQ-8の形式です。コード1はコード13よりも優先されます。これは、[RFC1122]に「ソフトエラー」としてリストされているためです。この場合、TCPスタックが接続試行を中止しないようにするため、これは重要です。ソフトエラーに対するTCPの反応の詳細については、[RFC5461]を参照してください。

Sending ICMP errors and SNMP traps may be rate-limited for security reasons, which is why requirements B and C are SHOULDs, not MUSTs.

ICMPエラーとSNMPトラップの送信は、セキュリティ上の理由からレートが制限される場合があります。そのため、要件BとCは必須ではなく、SHOULDです。

Applications generally handle connection establishment failure better than established connection failure. This is why dropping the packet initiating the new connection is preferred over deleting existing mappings. See also the rationale in Section 6 of [RFC5508].

アプリケーションは通常、確立された接続障害よりも接続確立障害を適切に処理します。これが、既存のマッピングを削除するよりも、新しい接続を開始するパケットをドロップする方が望ましい理由です。 [RFC5508]のセクション6の根拠もご覧ください。

4. Logging

4. ロギング

It may be necessary for CGN administrators to be able to identify a subscriber based on external IPv4 address, port, and timestamp in order to deal with abuse. When multiple subscribers share a single external address, the source address and port that are visible at the destination host have been translated from the ones originated by the subscriber.

CGN管理者は、悪用に対処するために、外部IPv4アドレス、ポート、およびタイムスタンプに基づいてサブスクライバーを識別できる必要がある場合があります。複数のサブスクライバが単一の外部アドレスを共有する場合、宛先ホストで表示される送信元アドレスとポートは、サブスクライバが発信したものから変換されています。

In order to be able to do this, the CGN would need to log the following information for each mapping created (this list is for informational purposes only and does not constitute a requirement):

これを実行できるようにするために、CGNは作成されたマッピングごとに次の情報をログに記録する必要があります（このリストは情報提供のみを目的としており、要件ではありません）。

o transport protocol

o トランスポートプロトコル

o subscriber identifier (e.g., internal source address or tunnel endpoint identifier)

o サブスクライバーID（例：内部ソースアドレスまたはトンネルエンドポイントID）

o external source address

o 外部ソースアドレス

o external source port

o 外部ソースポート

o timestamp

o タイムスタンプ

By "subscriber identifier" we mean information that uniquely identifies a subscriber. For example, in a traditional NAT scenario, the internal source address would be sufficient. In the case of DS-Lite, many subscribers share the same internal address and the subscriber identifier is the tunnel endpoint identifier (i.e., the B4's IPv6 address).

「加入者識別子」とは、加入者を一意に識別する情報を意味します。たとえば、従来のNATシナリオでは、内部送信元アドレスで十分です。 DS-Liteの場合、多くのサブスクライバーは同じ内部アドレスを共有し、サブスクライバー識別子はトンネルエンドポイント識別子（つまり、B4のIPv6アドレス）です。

A disadvantage of logging mappings is that CGNs under heavy usage may produce large amounts of logs, which may require large storage volume.

ロギングマッピングの不利な点は、CGNを頻繁に使用すると、大量のログが生成され、大量のストレージボリュームが必要になる可能性があることです。

REQ-12: A CGN SHOULD NOT log destination addresses or ports unless required to do so for administrative reasons.

REQ-12：管理上の理由で必要でない限り、CGNは宛先アドレスまたはポートをログに記録しないでください。

Justification: Destination logging at the CGN creates privacy issues. Furthermore, readers should be aware of logging recommendations for Internet-facing servers [RFC6302]. With compliant servers, the destination address and port do not need to be logged by the CGN. This can help reduce the amount of logging.

正当化：CGNでの宛先ロギングはプライバシーの問題を引き起こします。さらに、読者はインターネットに面するサーバーの推奨されるロギング[RFC6302]に注意する必要があります。準拠サーバーでは、宛先アドレスとポートをCGNで記録する必要はありません。これにより、ログの量を減らすことができます。

This requirement is at the SHOULD level to account for the fact that there may be other reasons for logging destination addresses or ports. One such reason might be that the remote server is not following [RFC6302].

この要件は、宛先アドレスまたはポートをログに記録する他の理由がある可能性があるという事実を説明するためにSHOULDレベルにあります。そのような理由の1つは、リモートサーバーが[RFC6302]に従っていないことです。

5. Port Allocation Scheme

5. ポート割り当てスキーム

A CGN's port allocation scheme is subject to three competing requirements:

CGNのポート割り当てスキームには、3つの競合する要件があります。

REQ-13: A CGN's port allocation scheme SHOULD maximize port utilization.

REQ-13：CGNのポート割り当てスキームは、ポート使用率を最大化する必要があります（SHOULD）。

Justification: External ports are one of the resources being shared by a CGN. Efficient management of that resource directly impacts the quality of a subscriber's Internet connection.

正当化：外部ポートは、CGNによって共有されるリソースの1つです。そのリソースの効率的な管理は、加入者のインターネット接続の品質に直接影響します。

Some schemes are very efficient in their port utilization. In that sense, they have good scaling properties (nothing is wasted). Others will systematically waste ports.

一部のスキームは、ポートの利用効率が非常に高くなっています。その意味で、それらには優れたスケーリングプロパティがあります（何も無駄になりません）。他のものは、計画的にポートを浪費します。

REQ-14: A CGN's port allocation scheme SHOULD minimize log volume.

REQ-14：CGNのポート割り当てスキームは、ログボリュームを最小化する必要があります（SHOULD）。

Justification: Huge log volumes can be problematic to CGN operators.

正当化：巨大なログボリュームは、CGNオペレーターにとって問題になる可能性があります。

Some schemes create one log entry per mapping. Others allow multiple mappings to generate a single log entry, which sometimes can be expressed very compactly. With some schemes, the logging frequency can approach that of DHCP servers.

一部のスキームでは、マッピングごとに1つのログエントリが作成されます。他の方法では、複数のマッピングで単一のログエントリを生成できます。これは、非常にコンパクトに表現できる場合があります。一部のスキームでは、ログの頻度がDHCPサーバーの頻度に近づくことがあります。

REQ-15: A CGN's port allocation scheme SHOULD make it hard for attackers to guess port numbers.

REQ-15：CGNのポート割り当てスキームは、攻撃者がポート番号を推測することを困難にする必要があります（SHOULD）。

Justification: Easily guessed port numbers put subscribers at risk of the attacks described in [RFC6056].

正当化：容易に推測されるポート番号は、[RFC6056]で説明されている攻撃のリスクに加入者を置きます。

Some schemes provide very good security in that ports numbers are not easily guessed. Others provide poor security to subscribers.

一部のスキームでは、ポート番号を簡単に推測できないため、非常に優れたセキュリティが提供されます。その他は、加入者に不十分なセキュリティを提供します。

A CGN implementation's choice of port allocation scheme optimizes to satisfy one requirement at the expense of another. Therefore, these are soft requirements (SHOULD as opposed to MUST).

CGN実装のポート割り当て方式の選択は、別のコストを犠牲にして1つの要件を満たすように最適化されます。したがって、これらはソフト要件です（MUSTとは対照的にSHOULD）。

6. Deployment Considerations

6. 導入に関する考慮事項

Several issues are encountered when CGNs are used [RFC6269]. There is current work in the IETF toward alleviating some of these issues. For example, see [NAT-REVEAL].

CGNを使用すると、いくつかの問題が発生します[RFC6269]。 IETFには、これらの問題のいくつかを緩和するための現在の取り組みがあります。たとえば、[NAT-REVEAL]を参照してください。

7. Security Considerations

7. セキュリティに関する考慮事項

If a malicious subscriber can spoof another subscriber's CPE, it may cause a DoS to that subscriber by creating mappings up to the allowed limit. An ISP can prevent this with ingress filtering, as described in [RFC2827].

悪意のあるサブスクライバーが別のサブスクライバーのCPEを偽装できる場合、許可された制限までのマッピングを作成することにより、そのサブスクライバーにDoSを引き起こす可能性があります。 [RFC2827]で説明されているように、ISPはこれをイングレスフィルタリングで防ぐことができます。

This document recommends endpoint-independent filtering (EIF) as the default filtering behavior for CGNs. EIF has security considerations that are discussed in [RFC4787].

このドキュメントでは、CGNのデフォルトのフィルタリング動作として、エンドポイントに依存しないフィルタリング（EIF）を推奨しています。 EIFには、[RFC4787]で説明されているセキュリティに関する考慮事項があります。

NATs sometimes perform fragment reassembly. CGNs would do so at presumably high data rates. Therefore, the reader should be familiar with the potential security issues described in [RFC4963].

NATはフラグメント再構成を実行することがあります。 CGNはおそらく高いデータレートでそうします。したがって、読者は[RFC4963]で説明されている潜在的なセキュリティ問題に精通している必要があります。

8. Acknowledgements

8. 謝辞

Thanks for the input and review by Alexey Melnikov, Arifumi Matsumoto, Barry Leiba, Benson Schliesser, Dai Kuwabara, Dan Wing, Dave Thaler, David Harrington, Francis Dupont, Jean-Francois Tremblay, Joe Touch, Lars Eggert, Kousuke Shishikura, Mohamed Boucadair, Martin Stiemerling, Meng Wei, Nejc Skoberne, Pete Resnick, Reinaldo Penno, Ron Bonica, Sam Hartman, Sean Turner, Senthil Sivakumar, Stephen Farrell, Stewart Bryant, Takanori Mizuguchi, Takeshi Tomochika, Tina Tsou, Tomohiro Fujisaki, Tomohiro Nishitani, Tomoya Yoshida, Wes George, Wesley Eddy, and Yasuhiro Shirasaki.

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

[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月。

[RFC4008] Rohit, R., Srisuresh, P., Raghunarayan, R., Pai, N., and C. Wang, "Definitions of Managed Objects for Network Address Translators (NAT)", RFC 4008, March 2005.

[RFC4008] Rohit、R.、Srisuresh、P.、Raghunarayan、R.、Pai、N。、およびC. Wang、「Definions of Managed Objects for Network Address Translators（NAT）」、RFC 4008、2005年3月。

[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.

[RFC4787]オーデットF.およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、2007年1月。

[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008.

[RFC5382] Guha、S.、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「NAT Behavioral Requirements for TCP」、BCP 142、RFC 5382、2008年10月。

[RFC5508] Srisuresh, P., Ford, B., Sivakumar, S., and S. Guha, "NAT Behavioral Requirements for ICMP", BCP 148, RFC 5508, April 2009.

[RFC5508] Srisuresh、P.、Ford、B.、Sivakumar、S。、およびS. Guha、「NAT Behavioral Requirements for ICMP」、BCP 148、RFC 5508、2009年4月。

[RFC5597] Denis-Courmont, R., "Network Address Translation (NAT) Behavioral Requirements for the Datagram Congestion Control Protocol", BCP 150, RFC 5597, September 2009.

[RFC5597] Denis-Courmont、R。、「データグラム輻輳制御プロトコルのネットワークアドレス変換（NAT）動作要件」、BCP 150、RFC 5597、2009年9月。

[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013.

[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、April 2013。

9.2. Informative Reference

9.2. 参考情報

[RFC0793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, September 1981.

[RFC0793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、1981年9月。

[RFC1122] Braden, R., "Requirements for Internet Hosts - Communication Layers", STD 3, RFC 1122, October 1989.

[RFC1122] Braden、R。、「インターネットホストの要件-通信層」、STD 3、RFC 1122、1989年10月。

[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.

[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス変換（NAT）の用語と考慮事項」、RFC 2663、1999年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月。

[RFC4963] Heffner, J., Mathis, M., and B. Chandler, "IPv4 Reassembly Errors at High Data Rates", RFC 4963, July 2007.

[RFC4963] Heffner、J.、Matis、M。、およびB. Chandler、「高データレートでのIPv4再構成エラー」、RFC 4963、2007年7月。

[RFC5461] Gont, F., "TCP's Reaction to Soft Errors", RFC 5461, February 2009.

[RFC 5461]フォント、OF。、「ソフトエラーに対するTCPの反応」、RFC 5461、2009年2月。

[RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport-Protocol Port Randomization", BCP 156, RFC 6056, January 2011.

[RFC6056] Larsen、M。およびF. Gont、「Recommendations for Transport-Protocol Port Randomization」、BCP 156、RFC 6056、2011年1月。

[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.

[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。

[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。、およびB. Carpenter、「IPv6移行のための増分キャリアグレードNAT（CGN）」、RFC 6264、2011年6月。

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

[RFC6269]フォード、M。、ブーカデア、M。、デュランド、A。、リーバイス、P。、およびP.ロバーツ、「IPアドレスの共有に関する問題」、RFC 6269、2011年6月。

[RFC6302] Durand, A., Gashinsky, I., Lee, D., and S. Sheppard, "Logging Recommendations for Internet-Facing Servers", BCP 162, RFC 6302, June 2011.

[RFC6302] Durand、A.、Gashinsky、I.、Lee、D。、およびS. Sheppard、「インターネットに面したサーバーのロギングに関する推奨事項」、BCP 162、RFC 6302、2011年6月。

[RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual-Stack Lite Broadband Deployments Following IPv4 Exhaustion", RFC 6333, August 2011.

[RFC6333] Durand、A.、Droms、R.、Woodyatt、J。、およびY. Lee、「IPv4枯渇後のデュアルスタックLiteブロードバンド展開」、RFC 6333、2011年8月。

[NAT-MIB] Perreault, S., Tsou, T., and S. Sivakumar, "Additional Managed Objects for Network Address Translators (NAT)", Work in Progress, February 2013.

[NAT-MIB] Perreault、S.、Tsou、T。、およびS. Sivakumar、「ネットワークアドレストランスレータ（NAT）の追加管理オブジェクト」、作業中、2013年2月。

[NAT-REVEAL] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Solution Candidates to Reveal a Host Identifier (HOST_ID) in Shared Address Deployments", Work in Progress, April 2013.

[NAT-REVEAL] Boucadair、M.、Touch、J.、Levis、P。、およびR. Penno、「Analysis of Solution Candidates to Hide a Host Identifier（HOST_ID）in Shared Address Deployments」、Work in Progress、2013年4月。

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

[NAT444] Donley、C.、Ed。、Howard、L.、Kuarsingh、V.、Berg、J.、and J. Doshi、 "Assessing the Impact of Carrier-Grade NAT on Network Applications"、Work in Progress、April 2013。

[BITTORRENT] Boucadair, M., Zheng, T., Deng, X., and J. Queiroz, "Behavior of BitTorrent service in PCP-enabled networks with Address Sharing", Work in Progress, May 2012.

[BITTORRENT] Boucadair、M.、Zheng、T.、Deng、X。、およびJ. Queiroz、「Behavior of BitTorrent service in PCP-enabled networks with Address Sharing」、Work in Progress、2012年5月。

Authors' Addresses

著者のアドレス

Simon Perreault (editor) Viagenie 246 Aberdeen Quebec, QC G1R 2E1 Canada

Simon Perreault（editor）Viagenie 246 Aberdeen Quebec、QC G1R 2E1 Canada

   Phone: +1 418 656 9254
   EMail: simon.perreault@viagenie.ca
   URI:   http://www.viagenie.ca

Ikuhei Yamagata NTT Communications Corporation Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan

いくへいやまがたんっｔこっむにかちおんｓこｒぽらちおんＧらんぱｒｋとうぇｒ１７Ｆ、３ー４ー１しばうら、みなとーくときょ１０８ー８１１８じゃぱん

   Phone: +81 50 3812 4704
   EMail: ikuhei@nttv6.jp

Shin Miyakawa NTT Communications Corporation Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku Tokyo 108-8118 Japan

しんみやかわんっｔこっむにかちおんｓこｒぽらちおんＧらんぱｒｋとうぇｒ１７Ｆ、３ー４ー１しばうら、みなとーくときょ１０８ー８１１８じゃぱん

   Phone: +81 50 3812 4695
   EMail: miyakawa@nttv6.jp

Akira Nakagawa Japan Internet Exchange Co., Ltd. (JPIX) Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku Tokyo 100-0004 Japan

あきらなかがわじゃぱんいんてｒねｔえｘちゃんげこ。、Ｌｔｄ。（ＪぴＸ）おてまちぶいｌぢんｇ２１Ｆ、１ー８ー１おてまち、ちよだーくときょ１００ー０００４じゃぱん

   Phone: +81 90 9242 2717
   EMail: a-nakagawa@jpix.ad.jp

Hiroyuki Ashida Cisco Systems Midtown Tower, 9-7-1, Akasaka Minato-Ku, Tokyo 107-6227 Japan

ひろゆきあしだしｓこＳｙｓてｍｓみｄとｗんとうぇｒ、９ー７ー１、あかさかみなとーく、ときょ１０７ー６２２７じゃぱん

   EMail: hiashida@cisco.com