[要約] RFC 6296は、IPv6-to-IPv6ネットワークプレフィックス変換に関する標準仕様です。その目的は、IPv6ネットワークのアドレス変換を実現し、異なるネットワークプレフィックスを持つIPv6ネットワーク間の通信を可能にすることです。
Internet Engineering Task Force (IETF) M. Wasserman
Request for Comments: 6296 Painless Security
Category: Experimental F. Baker
ISSN: 2070-1721 Cisco Systems
June 2011
IPv6-to-IPv6 Network Prefix Translation
IPv6-to-IPv6ネットワークプレフィックス翻訳
Abstract
概要
This document describes a stateless, transport-agnostic IPv6-to-IPv6 Network Prefix Translation (NPTv6) function that provides the address-independence benefit associated with IPv4-to-IPv4 NAT (NAPT44) and provides a 1:1 relationship between addresses in the "inside" and "outside" prefixes, preserving end-to-end reachability at the network layer.
このドキュメントでは、IPv4-to-IPv4 NAT（NAPT44）に関連するアドレス依存性利益を提供するステートレス、トランスポート - Agnostic IPv6からIPv6へのプレフィックスへのプレフィックスへのプレフィックスへのプレフィックスのプレフィックスのプレフィックスのプレフィックスへのプレフィックスのプレフィックスへのプレフィックスのプレフィックスのプレフィックスのプレフィックスのプレフィックスへのプレフィックスの翻訳（NPTV6）関数が記述されています。ネットワーク層でのエンドツーエンドの到達可能性を保つ、「内側」および「外側」の接頭辞。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
この文書はインターネット標準のトラック仕様ではありません。検査、実験的実施、評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
この文書は、インターネットコミュニティの実験的プロトコルを定義しています。この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。IESGによって承認されたすべての文書がすべてのレベルのインターネット規格の候補者であるわけではありません。RFC 5741のセクション2を参照してください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6296.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc6296で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（C）2011 IETFの信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、この文書の公開日に有効なIETF文書（http://trustee.ietf.org/License-Info）に関するBCP 78およびIETF信頼の法的規定を受けています。この文書に関してあなたの権利と制限を説明するので、これらの文書を慎重に見直してください。この文書から抽出されたコードコンポーネントには、信頼法の法的規定のセクション4。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. What is Address Independence? . . . . . . . . . . . . . . 4
1.2. NPTv6 Applicability . . . . . . . . . . . . . . . . . . . 5
1.3. Requirements Terminology . . . . . . . . . . . . . . . . . 7
2. NPTv6 Overview . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. NPTv6: The Simplest Case . . . . . . . . . . . . . . . . . 7
2.2. NPTv6 between Peer Networks . . . . . . . . . . . . . . . 8
2.3. NPTv6 Redundancy and Load Sharing . . . . . . . . . . . . 9
2.4. NPTv6 Multihoming . . . . . . . . . . . . . . . . . . . . 9
2.5. Mapping with No Per-Flow State . . . . . . . . . . . . . . 10
2.6. Checksum-Neutral Mapping . . . . . . . . . . . . . . . . . 10
3. NPTv6 Algorithmic Specification . . . . . . . . . . . . . . . 11
3.1. NPTv6 Configuration Calculations . . . . . . . . . . . . . 11
3.2. NPTv6 Translation, Internal Network to External Network . 12
3.3. NPTv6 Translation, External Network to Internal Network . 12
3.4. NPTv6 with a /48 or Shorter Prefix . . . . . . . . . . . . 12
3.5. NPTv6 with a /49 or Longer Prefix . . . . . . . . . . . . 13
3.6. /48 Prefix Mapping Example . . . . . . . . . . . . . . . . 13
3.7. Address Mapping for Longer Prefixes . . . . . . . . . . . 14
4. Implications of Network Address Translator Behavioral
Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 15
4.1. Prefix Configuration and Generation . . . . . . . . . . . 15
4.2. Subnet Numbering . . . . . . . . . . . . . . . . . . . . . 15
4.3. NAT Behavioral Requirements . . . . . . . . . . . . . . . 15
5. Implications for Applications . . . . . . . . . . . . . . . . 16
5.1. Recommendation for Network Planners Considering Use of
NPTv6 Translation . . . . . . . . . . . . . . . . . . . . 17
5.2. Recommendations for Application Writers . . . . . . . . . 18
5.3. Recommendation for Future Work . . . . . . . . . . . . . . 18
6. A Note on Port Mapping . . . . . . . . . . . . . . . . . . . . 18
7. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Normative References . . . . . . . . . . . . . . . . . . . 20
9.2. Informative References . . . . . . . . . . . . . . . . . . 20
Appendix A. Why GSE? . . . . . . . . . . . . . . . . . . . . . . 23
Appendix B. Verification Code . . . . . . . . . . . . . . . . . . 25
This document describes a stateless IPv6-to-IPv6 Network Prefix Translation (NPTv6) function, designed to provide address independence to the edge network. It is transport-agnostic with respect to transports that do not checksum the IP header, such as SCTP, and to transports that use the TCP/UDP/DCCP (Datagram Congestion Control Protocol) pseudo-header and checksum [RFC1071].
この文書では、エッジネットワークにアドレス独立を提供するように設計されたステートレスIPv6からIPv6ネットワークプレフィックスへのプレフィックスプレフィックスのプレフィックスプレフィックスへのアクセス（NPTV6）機能について説明します。SCTPなどのIPヘッダーをチェックしないトランスポート、およびTCP / UDP / DCCP（データグラム輻輳制御プロトコル）疑似ヘッダーとチェックサム[RFC1071]を搬送するトランスポートに関するトランスポートが不具合です。
For reasons discussed in [RFC2993] and Section 5, the IETF does not recommend the use of Network Address Translation technology for IPv6. Where translation is implemented, however, this specification provides a mechanism that has fewer architectural problems than merely implementing a traditional stateful Network Address Translator in an IPv6 environment. It also provides a useful alternative to the complexities and costs imposed by multihoming using provider-independent addressing and the routing and network management issues of overlaid ISP address space. Some problems remain, however. The reader should consider the alternatives suggested in [RFC4864] and the considerations of [RFC5902] for improved approaches.
[RFC2993]とセクション5で説明した理由で、IETFはIPv6のネットワークアドレス変換テクノロジを使用することをお勧めしません。ただし、翻訳が実装されている場合、この仕様は、IPv6環境で従来のステートフルネットワークアドレストランスレータを単に実装するだけではないアーキテクチャ上の問題を除いたメカニズムを提供します。それはまた、プロバイダに依存しないアドレス指定およびオーバーレイされたISPアドレス空間のルーティングおよびネットワーク管理の問題を使用したマルチホームによって課される複雑さおよび費用に代わる役に立つ代替手段を提供する。しかし、いくつかの問題は残ります。リーダーは[RFC4864]で提案された代替案と、改善されたアプローチのための[RFC5902]の考慮事項を考慮する必要があります。
The stateless approach described in this document has several ramifications:
この文書に記載されているステートレスアプローチには、いくつかの影響があります。
o Any security benefit that NAPT44 might offer is not present in NPTv6, necessitating the use of a firewall to obtain those benefits if desired. An example of such a firewall is described in [RFC6092].
o NAPT44が提供する可能性があるセキュリティ上の利点は、NPTV6には存在しないため、必要に応じてこれらの利点を得るためにファイアウォールの使用を必要とします。そのようなファイアウォールの例は[RFC6092]に記載されている。
o End-to-end reachability is preserved, although the address used "inside" the edge network differs from the address used "outside" the edge network. This has implications for application referrals and other uses of Internet layer addresses.
o エンドツーエンドの到達可能性は保持されますが、エッジネットワークはエッジネットワークの「外側」のアドレスとは異なります。これは、アプリケーションの紹介やインターネット層アドレスのその他の用途に影響を与えます。
o If there are multiple identically configured prefix translators between two networks, there is no need for them to exchange dynamic state, as there is no dynamic state -- the algorithmic translation will be identical across each of them. The network can therefore asymmetrically route, load share, and fail-over among them without issue.
o 2つのネットワーク間に複数の同一の構成の接頭辞翻訳者がある場合、動的状態がないため、動的状態を交換する必要はありません。したがって、ネットワークは、問題なくそれらの間で非対称的にルーティング、ロードシェア、およびフェイルオーバーを使用することができます。
o Since translation is 1:1 at the network layer, there is no need to modify port numbers or other transport parameters.
o 翻訳はネットワーク層で1：1であるため、ポート番号や他のトランスポートパラメータを変更する必要はありません。
o TCP sessions that authenticate peers using the TCP Authentication Option [RFC5925] cannot have their addresses translated, as the addresses are used in the calculation of the Message Authentication Code. This consideration applies in general to any UNilateral Self-Address Fixing (UNSAF) [RFC3424] Protocol, which the IAB recommends against the deployment of in an environment that changes Internet addresses.
o TCP認証オプション[RFC5925]を使用してピアを認証するTCPセッションは、メッセージ認証コードの計算でアドレスが使用されるため、アドレスが変換できません。この考慮事項は、一般に、任意の一方的な自己アドレス固定（UNSAF）[RFC3424]プロトコルに適用されます。これは、IABがインターネットアドレスを変更する環境内の展開に対して推奨されます。
o Applications using the Internet Key Exchange Protocol Version 2 (IKEv2) [RFC5996] should, at least in theory, detect the presence of the translator; while no NAT traversal solution is required, [RFC5996] would require such sessions to use UDP.
o インターネット鍵交換プロトコルバージョン2（IKEV2）[RFC5996]を使用するアプリケーションは、少なくとも理論上、翻訳者の存在を検出する必要があります。NATトラバーサルソリューションは必要ありませんが、[RFC5996]はUDPを使用するようなセッションを必要とします。
For the purposes of this document, IPv6 address independence consists of the following set of properties:
この文書の目的のために、IPv6アドレスの独立性は次の一連のプロパティで構成されています。
From the perspective of the edge network:
エッジネットワークの観点から：
* The IPv6 addresses used inside the local network (for interfaces, access lists, and logs) do not need to be renumbered if the global prefix(es) assigned for use by the edge network are changed.
* ローカルネットワーク内で使用されているIPv6アドレス（インターフェイス、アクセスリスト、およびログ）は、エッジネットワークでの使用に割り当てられたグローバルプレフィックスが変更された場合に番号を変更する必要はありません。
* The IPv6 addresses used inside the edge network (for interfaces, access lists, and logs) or within other upstream networks (such as when multihoming) do not need to be renumbered when a site adds, drops, or changes upstream networks.
* エッジネットワーク内で（インターフェイス、アクセスリスト、およびログ用）または他のアップストリームネットワーク内で使用されているIPv6アドレス（マルチホームを実行するときなど）は、サイトが追加、ドロップ、または変更されたときに変更される必要はありません。
* It is not necessary for an administration to convince an upstream network to route its internal IPv6 prefixes or for it to advertise prefixes derived from other upstream networks into it.
* 管理者がアップストリームネットワークをその内部IPv6プレフィックスをルーティングして他のアップストリームネットワークから派生したプレフィックスをアドバタイズするように納得させる必要はありません。
* Unless it wants to optimize routing between multiple upstream networks in the process of multihoming, there is no need for a BGP exchange with the upstream network.
* マルチホームのプロセスで複数のアップストリームネットワーク間のルーティングを最適化したいのでない限り、アップストリームネットワークとのBGP交換を必要としない。
From the perspective of the upstream network:
アップストリームネットワークの観点から：
* IPv6 addresses used by the edge network are guaranteed to have a provider-allocated prefix, eliminating the need and concern for BCP 38 [RFC2827] ingress filtering and the advertisement of customer-specific prefixes.
* エッジネットワークによって使用されるIPv6アドレスは、プロバイダ割り当てられたプレフィックスを持つことが保証されており、BCP 38 [RFC2827]入力フィルタリングと顧客固有のプレフィックスの広告の必要性と懸念を排除することが保証されています。
Thus, address independence has ramifications for the edge network, networks it directly connects with (especially its upstream networks), and the Internet as a whole. The desire for address independence has been a primary driver for IPv4 NAT deployment in medium- to large-sized enterprise networks, including NAT deployments in enterprises that have plenty of IPv4 provider-independent address space (from IPv4 "swamp space"). It has also been a driver for edge networks to become members of Regional Internet Registry (RIR) communities, seeking to obtain BGP Autonomous System Numbers and provider-independent prefixes, and as a result has been one of the drivers of the explosion of the IPv4 route table. Service providers have stated that the lack of address independence from their customers has been a negative incentive to deployment, due to the impact of customer routing expected in their networks.
したがって、アドレスの独立性は、エッジネットワーク、直接接続されているネットワーク、およびインターネット全体としてのネットワークの影響を与えます。アドレス独立性の要望は、完全なIPv4プロバイダに依存しないアドレス空間を持つEnterpriseのNAT展開を含む、中から大型のエンタープライズネットワークにおけるIPv4 NAT展開のためのプライマリドライバです（IPv4 "Swamp Space"）。また、BGP自律システム番号とプロバイダに依存しないプレフィックスを入手しようとしている、地域インターネットレジストリ（RIR）コミュニティのメンバーになるためのエッジネットワークのドライバもあり、その結果としてIPv4の爆発のドライバの1つがありました。ルートテーブルサービスプロバイダーは、顧客からのアドレス独立の欠如が、ネットワークでの顧客ルーティングが予想される影響により、展開に対する否定的なインセンティブであると述べています。
The Local Network Protection [RFC4864] document discusses a related concept called "Address Autonomy" as a benefit of NAPT44. [RFC4864] indicates that address autonomy can be achieved by the simultaneous use of global addresses on all nodes within a site that need external connectivity and Unique Local Addresses (ULAs) [RFC4193] for all internal communication. However, this solution fails to meet the requirement for address independence, because if an ISP renumbering event occurs, all of the hosts, routers, DHCP servers, Access Control Lists (ACLs), firewalls, and other internal systems that are configured with global addresses from the ISP will need to be renumbered before global connectivity is fully restored.
ローカルネットワーク保護[RFC4864]ドキュメントでは、NAPT44の利点として「アドレス自律」という関連概念について説明します。[RFC4864]は、すべての内部通信に対して外部接続と固有のローカルアドレス（ULAS）[RFC4193]を必要とするサイト内のすべてのノードのグローバルアドレスを同時に使用できるようにして、アドレス自律性が実現できることを示します。ただし、ISPの番号変更イベントが発生した場合、すべてのホスト、ルータ、DHCPサーバー、アクセスコントロールリスト（ACL）、ファイアウォール、およびグローバルアドレスで構成されているその他の内部システムなど、このソリューションはアドレスの独立性の要件を満たしていません。Global Connectivityが完全に復元される前にISPから番号を付け直す必要があります。
The use of IPv6 provider-independent (PI) addresses has also been suggested as a means to fulfill the address-independence requirement. However, this solution requires that an enterprise qualify to receive a PI assignment and persuade its ISP to install specific routes for the enterprise's PI addresses. There are a number of practical issues with this approach, especially if there is a desire to route to a number of geographically and topologically diverse sites, which can sometimes involve coordinating with several ISPs to route portions of a single PI prefix. These problems have caused numerous enterprises with plenty of IPv4 swamp space to choose to use IPv4 NAT for part, or substantially all, of their internal network instead of using their provider-independent address space.
IPv6プロバイダーに依存しない（PI）アドレスを使用することも、アドレス独立要件を満たす手段として提案されています。ただし、このソリューションでは、EnterpriseがPIの割り当てを受信し、ISPをPRESUADEに対象とし、企業のPIアドレスの特定のルートをインストールすることが必要です。特に多数の地理的および位相的に多様なサイトをルーティングすることが望まれている場合には、このアプローチにはいくつかの実用的な問題があります。これにより、単一のPIプレフィックスの一部を配線することがある複数のISPとの調整が含まれます。これらの問題は、プロバイダに依存しないアドレス空間を使用するのではなく、IPv4 NAT、または実質的に全部のIPv4 NATを使用することを選択するために、たくさんのIPv4湿地スペースを備えた多数の企業が増加しました。
NPTv6 provides a simple and compelling solution to meet the address-independence requirement in IPv6. The address-independence benefit stems directly from the translation function of the network prefix translator. To avoid as many of the issues associated with NAPT44 as possible, NPTv6 is defined to include a two-way, checksum-neutral, algorithmic translation function, and nothing else.
NPTV6は、IPv6のアドレス独立要件を満たすためのシンプルで説得力のある解決策を提供します。アドレス依存性給付は、ネットワークプレフィックストランスレータの翻訳機能から直接発生します。できるだけNAPT44に関連する多くの問題を回避するために、NPTV6は、双方向、チェックサムニュートラル、アルゴリズム変換関数を含むように定義されています。
The fact that NPTv6 does not map ports and is checksum-neutral avoids the need for an NPTv6 Translator to rewrite transport layer headers. This makes it feasible to deploy new or improved transport layer protocols without upgrading NPTv6 Translators. Similarly, since NPTv6 does not rewrite transport layer headers, NPTv6 will not interfere with encryption of the full IP payload in many cases.
NPTv6がポートをマッピングしないという事実とCheckSum-Neutralであるという事実は、NPTv6トランスレータがトランスポートレイヤヘッダーを書き換える必要がありません。これにより、NPTV6トランスレータをアップグレードせずに、新規または改善されたトランスポート層プロトコルを展開することができます。同様に、NPTV6はトランスポートレイヤヘッダーを書き換えないため、NPTV6は多くの場合、フルIPペイロードの暗号化を妨げません。
The default NPTv6 address-mapping mechanism is purely algorithmic, so NPTv6 translators do not need to maintain per-node or per-connection state, allowing deployment of more robust and adaptive networks than can be deployed using NAPT44. Since the default NPTv6 mapping can be performed in either direction, it does not interfere with inbound connection establishment, thus allowing internal nodes to participate in direct Peer-to-Peer applications without the application layer overhead one finds in many IPv4 Peer-to-Peer applications.
デフォルトのNPTV6アドレスマッピングメカニズムは純粋にアルゴリズムであるため、NPTV6トランスレータはノードごとまたは接続ごとの状態を維持する必要はありません。これにより、NAPT44を使用してデプロイできます。デフォルトのNPTV6マッピングはどちらの方向に実行できますので、インバウンド接続確立を妨げません。したがって、内部ノードはアプリケーションレイヤのオーバーヘッドを使用せずに直接ピアツーピアアプリケーションに参加できるようになります。アプリケーション
Although NPTv6 compares favorably to NAPT44 in several ways, it does not eliminate all of the architectural problems associated with IPv4 NAT, as described in [RFC2993]. NPTv6 involves modifying IP headers in transit, so it is not compatible with security mechanisms, such as the IPsec Authentication Header, that provide integrity protection for the IP header. NPTv6 may interfere with the use of application protocols that transmit IP addresses in the application-specific portion of the IP datagram. These applications currently require Application Layer Gateways (ALGs) to work correctly through NAPT44 devices, and similar ALGs may be required for these applications to work through NPTv6 Translators. The use of separate internal and external prefixes creates complexity for DNS deployment, due to the desire for internal nodes to communicate with other internal nodes using internal addresses, while external nodes need to obtain external addresses to communicate with the same nodes. This frequently results in the deployment of "split DNS", which may add complexity to network configuration.
NPTV6はいくつかの方法でNAPT44に有利に比較されますが、[RFC2993]で説明されているように、IPv4 NATに関連するすべてのアーキテクチャ上の問題を排除しません。 NPTV6は、輸送中のIPヘッダーの変更を含み、そのため、IPSec認証ヘッダーなどのセキュリティメカニズムと互換性がありません。これは、IPヘッダーの整合性保護を提供します。 NPTV6は、IPデータグラムのアプリケーション固有部分にIPアドレスを送信するアプリケーションプロトコルの使用を妨げる可能性があります。これらのアプリケーションは現在、アプリケーションレイヤゲートウェイ（ALG）がNAPT44デバイスを介して正しく機能することを要求し、これらのアプリケーションにはNPTV6トランスレータを介して機能する必要があります。内部ノードと内部アドレスを使用して他の内部ノードと通信するという要望のため、別々の内部プレフィックスと外部プレフィックスの使用は、内部アドレスを使用して他の内部ノードと通信するという要望により、DNS展開に複雑さを生み出しますが、外部ノードは同じノードと通信するための外部アドレスを取得する必要があります。これは頻繁に「分割DNS」の展開をもたらし、これはネットワーク構成に複雑さを追加する可能性があります。
The choice of address within the edge network bears consideration. One could use a ULA, which maximizes address independence. That could also be considered a misuse of the ULA; if the expectation is that a ULA prevents access to a system from outside the range of the ULA, NPTv6 overrides that. On the other hand, the administration is aware that it has made that choice and could deploy a second ULA for the purpose of privacy if it desired; the only prefix that will be translated is one that has an NPTv6 Translator configured to translate to or from it. Also, using any other global-scope address format makes one either obtain a PI prefix or be at the mercy of the agency from which it was allocated.
エッジネットワーク内のアドレスの選択は考慮されます。アドレスの独立性を最大化するULAを使用することができます。それはURAの誤用と見なすこともできます。ULAがULAの範囲外のシステムへのアクセスを防止すると期待がある場合、NPTV6はそれをオーバーライドします。一方、管理は、それがその選択をして、プライバシーを目的として2番目のULAを展開することができることを知っています。翻訳される唯一のプレフィックスは、それから翻訳するように設定されたNPTV6トランスレータを持つものです。また、他のグローバルスコープアドレスフォーマットを使用すると、PIプレフィックスを入手するか、それが割り当てられた機関の慈悲にあってください。
There are significant technical impacts associated with the deployment of any prefix translation mechanism, including NPTv6, and we strongly encourage anyone who is considering the implementation or deployment of NPTv6 to read [RFC4864] and [RFC5902], and to carefully consider the alternatives described in that document, some of which may cause fewer problems than NPTv6.
NPTV6を含むプレフィックス翻訳メカニズムの展開に関連する重要な技術的影響があり、[RFC4864]と[RFC5902]を読み取るためにNPTV6の実装や展開を検討している人は強く奨励されています。その文書は、そのうちのいくつかはNPTv6よりも少ない問題を引き起こす可能性があります。
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]で説明されているように解釈されます。
NPTv6 may be implemented in an IPv6 router to map one IPv6 address prefix to another IPv6 prefix as each IPv6 datagram transits the router. A router that implements an NPTv6 prefix translation function is referred to as an NPTv6 Translator.
NPTV6はIPv6ルータに実装されて、各IPv6データグラムがルータを遷移するように、あるIPv6アドレスプレフィックスを別のIPv6プレフィックスにマッピングできます。NPTV6プレフィックス変換機能を実装するルータは、NPTV6トランスレータと呼ばれます。
In its simplest form, an NPTv6 Translator interconnects two network links, one of which is an "internal" network link attached to a leaf network within a single administrative domain and the other of which is an "external" network with connectivity to the global Internet. All of the hosts on the internal network will use addresses from a single, locally routed prefix, and those addresses will be translated to/from addresses in a globally routable prefix as IP datagrams transit the NPTv6 Translator. The lengths of these two prefixes will be functionally the same; if they differ, the longer of the two will limit the ability to use subnets in the shorter.
その最も簡単な形式では、NPTV6トランスレータは2つのネットワークリンクを相互接続し、その1つは単一の管理ドメイン内でリーフネットワークに接続されている「内部」ネットワークリンクであり、その他はグローバルインターネットへの接続性を持つ「外部」ネットワークです。。内部ネットワーク上のすべてのホストは、単一のローカルにルーティングされたプレフィックスからアドレスを使用し、IPデータグラムがNPTV6トランスレータを転送するため、グローバルにルーティング可能なプレフィックス内のアドレスに変換されます。これら2つの接頭辞の長さは機能的に同じです。それらが異なる場合、2つのうちより長いほど、短いサブネットを使用する機能が制限されます。
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
|
|
+-------------+
| NPTv6 |
| Translator |
+-------------+
|
|
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 1: A Simple Translator
図1：簡単な翻訳者
Figure 1 shows an NPTv6 Translator attached to two networks. In this example, the internal network uses IPv6 Unique Local Addresses (ULAs) [RFC4193] to represent the internal IPv6 nodes, and the external network uses globally routable IPv6 addresses to represent the same nodes.
図1は、2つのネットワークに接続されているNPTV6トランスレータを示しています。この例では、内部ネットワークはIPv6固有のローカルアドレス（ULAS）[RFC4193]を使用して内部IPv6ノードを表し、外部ネットワークは同じノードを表すためにグローバルにルーティング可能なIPv6アドレスを使用します。
When an NPTv6 Translator forwards datagrams in the "outbound" direction, from the internal network to the external network, NPTv6 overwrites the IPv6 source prefix (in the IPv6 header) with a corresponding external prefix. When datagrams are forwarded in the "inbound" direction, from the external network to the internal network, the IPv6 destination prefix is overwritten with a corresponding internal prefix. Using the prefixes shown in the diagram above, as an IP datagram passes through the NPTv6 Translator in the outbound direction, the source prefix (FD01:0203:0405:/48) will be overwritten with the external prefix (2001:0DB8:0001:/48). In an inbound datagram, the destination prefix (2001:0DB8:0001:/48) will be overwritten with the internal prefix (FD01:0203:0405:/48). In both cases, it is the local IPv6 prefix that is overwritten; the remote IPv6 prefix remains unchanged. Nodes on the internal network are said to be "behind" the NPTv6 Translator.
NPTV6トランスレータが「アウトバウンド」方向にデータグラムを内部ネットワークから外部ネットワークに転送すると、NPTV6は（IPv6ヘッダー内の）対応する外部プレフィックスを使用してIPv6のソースプレフィックスを上書きします。データグラムが「インバウンド」方向に転送されると、外部ネットワークから内部ネットワークへのIPv6の宛先プレフィックスが対応する内部プレフィックスで上書きされます。上記の図に示すプレフィックスを使用すると、IPデータグラムが発信方向にNPTV6トランスレータを通過すると、ソースプレフィックス（FD01：0203：0405：/ 48）が外部プレフィックスで上書きされます（2001：0db8：0001：/ 48）インバウンドデータグラムでは、宛先プレフィックス（2001：0DB8：0001：/ 48）が内部プレフィックスで上書きされます（FD01：0203：0405：/ 48）。どちらの場合も、上書きされるローカルIPv6プレフィックスです。リモートIPv6プレフィックスは変更されません。内部ネットワーク上のノードは、NPTV6トランスレータの「後ろ」と言われています。
NPTv6 can also be used between two private networks. In these cases, both networks may use ULA prefixes, with each subnet in one network mapped into a corresponding subnet in the other network, and vice versa. Or, each network may use ULA prefixes for internal addressing and global unicast addresses on the other network.
NPTV6は2つのプライベートネットワーク間でも使用できます。このような場合、両方のネットワークはURAプレフィックスを使用し、各サブネットは1つのネットワーク内の他のネットワーク内の対応するサブネットにマッピングされ、その逆も同様です。あるいは、各ネットワークは、他のネットワーク上の内部アドレッシングとグローバルユニキャストアドレスのためにULAプレフィックスを使用することがあります。
Internal Prefix = FD01:4444:5555:/48
--------------------------------------
V | External Prefix
V | 2001:0DB8:6666:/48
V +---------+ ^
V | NPTv6 | ^
V | Device | ^
V +---------+ ^
External Prefix | ^
2001:0DB8:0001:/48 | ^
--------------------------------------
Internal Prefix = FD01:0203:0405:/48
Figure 2: Flow of Information in Translation
図2：翻訳における情報の流れ
In some cases, more than one NPTv6 Translator may be attached to a network, as shown in Figure 3. In such cases, NPTv6 Translators are configured with the same internal and external prefixes. Since there is only one translation, even though there are multiple translators, they map only one external address (prefix and Interface Identifier (IID)) to the internal address.
場合によっては、図3に示すように、複数のNPTV6トランスレータをネットワークに接続することができます。そのような場合、NPTV6トランスレータは同じ内部プレフィックスと外部プレフィックスで構成されています。複数の翻訳者がある場合でも、翻訳が1つしかありませんので、内部アドレスに1つの外部アドレス（プレフィックスとインターフェイス識別子（IID））のみをマッピングします。
External Network: Prefix = 2001:0DB8:0001:/48
--------------------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 3: Parallel Translators
図3：並列翻訳者
External Network #1: External Network #2:
Prefix = 2001:0DB8:0001:/48 Prefix = 2001:0DB8:5555:/48
--------------------------- --------------------------
| |
| |
+-------------+ +-------------+
| NPTv6 | | NPTv6 |
| Translator | | Translator |
| #1 | | #2 |
+-------------+ +-------------+
| |
| |
--------------------------------------
Internal Network: Prefix = FD01:0203:0405:/48
Figure 4: Parallel Translators with Different Upstream Networks
図4：異なるアップストリームネットワークを持つ並列翻訳者
When multihoming, NPTv6 Translators are attached to an internal network, as shown in Figure 4, but are connected to different external networks. In such cases, NPTv6 Translators are configured with the same internal prefix but different external prefixes. Since there are multiple translations, they map multiple external addresses (prefix and IID) to the common internal address. A system within the edge network is unable to determine which external address it is using apart from services such as Session Traversal Utilities for NAT (STUN) [RFC5389].
マルチホーム化の場合、図4に示すように、NPTV6トランスレータは内部ネットワークに接続されていますが、異なる外部ネットワークに接続されています。そのような場合、NPTV6トランスレータは同じ内部プレフィックスではなく異なる外部プレフィックスで構成されています。複数の翻訳があるため、複数の外部アドレス（プレフィックスとIID）を共通の内部アドレスにマッピングします。Edge Network内のシステムは、NAT（STUN）[RFC5389]のセッショントラバーサルユーティリティなどのサービスとは別に使用している外部アドレスを決定できません。
Multihoming in this sense has one negative feature as compared with multihoming with a provider-independent address: when routes change between NPTv6 Translators, the translated prefix can change since the upstream network changes. This causes sessions and referrals dependent on it to fail as well. This is not expected to be a major issue, however, in networks where routing is generally stable.
この意味でのマルチホームは、プロバイダに依存しないアドレスを使用したマルチホームと比較して1つのマイナス機能を持っています.NPTv6トランスレータ間でルートが変更されると、アップストリームネットワークが変更されるため、翻訳されたプレフィックスが変わります。これにより、セッションと紹介が失敗するように依存します。ただし、ルーティングが一般的に安定できるネットワークでは、これは大きな問題ではありません。
When NPTv6 is used as described in this document, no per-node or per-flow state is maintained in the NPTv6 Translator. Both inbound and outbound datagrams are translated algorithmically, using only information found in the IPv6 header. Due to this property, NPTv6's two-way, algorithmic address mapping can support both outbound and inbound connection establishment without the need for maintenance of mapping state or for state-priming or rendezvous mechanisms. This is a significant improvement over NAPT44 devices, but it also has significant security implications, which are described in Section 7.
この文書に記載されているようにNPTv6を使用すると、NPTV6トランスレータにノードごとまたはフローごとの状態は維持されません。IPv6ヘッダーにある情報のみを使用して、インバウンドデータグラムとアウトバウンドデータグラムの両方がアルゴリズム的に変換されます。このプロパティのために、NPTV6の双方向のアルゴリズムアドレスマッピングは、マッピング状態のメンテナンスや状態プライミングメカニズムのメンテナンスを必要とせずに、アウトバウンドとインバウンド接続確立の両方をサポートできます。これはNAPT44デバイスを超える重大な改善ですが、セクション7で説明されている大幅なセキュリティへの影響もあります。
When a change is made to one of the IP header fields in the IPv6 pseudo-header checksum (such as one of the IP addresses), the checksum field in the transport layer header may become invalid. Fortunately, an incremental change in the area covered by the Internet standard checksum [RFC1071] will result in a well-defined change to the checksum value [RFC1624]. So, a checksum change caused by modifying part of the area covered by the checksum can be corrected by making a complementary change to a different 16-bit field covered by the same checksum.
IPv6疑似ヘッダーチェックサム（IPアドレスの1つなど）のいずれかのIPヘッダーフィールドに変更が加えられたら、トランスポート層ヘッダーのチェックサムフィールドが無効になる可能性があります。幸いなことに、インターネット標準チェックサム[RFC1071]でカバーされている領域の増分変化は、チェックサム値[RFC1624]に明確に定義された変更をもたらします。したがって、チェックサムでカバーされている領域の一部を変更することによって引き起こされるチェックサム変更は、同じチェックサムでカバーされている別の16ビットフィールドに相補的な変更を加えることによって修正できます。
The NPTv6 mapping mechanisms described in this document are checksum-neutral, which means that they result in IP headers that will generate the same IPv6 pseudo-header checksum when the checksum is calculated using the standard Internet checksum algorithm [RFC1071]. Any changes that are made during translation of the IPv6 prefix are offset by changes to other parts of the IPv6 address. This results in transport layers that use the Internet checksum (such as TCP and UDP) calculating the same IPv6 pseudo-header checksum for both the internal and external forms of the same datagram, which avoids the need for the NPTv6 Translator to modify those transport layer headers to correct the checksum value.
この文書に記載されているNPTV6マッピングメカニズムはCheckSum-Neutralです。これは、標準のインターネットチェックサムアルゴリズム[RFC1071]を使用してチェックサムが計算されたときに同じIPv6疑似ヘッダーチェックサムを生成するIPヘッダーをもたらすことを意味します。IPv6プレフィックスの変換中に行われる変更は、IPv6アドレスの他の部分への変更によってオフセットされます。これにより、インターネットチェックサム（TCPやUDPなど）を使用するトランスポート層が同じデータグラムの内部形式と外部形式の両方に同じIPv6疑似ヘッダーチェックサムを計算します。これにより、NPTV6トランスレータがそれらのトランスポート層を変更する必要があります。チェックサム値を修正するヘッダー。
The outgoing checksum correction is achieved by making a change to a 16-bit section of the source address that is not used for routing in the external network. Due to the nature of checksum arithmetic, when the corresponding correction is applied to the same bits of destination address of the inbound packet, the Destination Address (DA) is returned to the correct internal value.
外部ネットワーク内のルーティングに使用されていないソースアドレスの16ビットセクションを変更することによって、発信チェックサム補正は達成される。チェックサム演算の性質上、対応する補正が着信パケットの宛先アドレスの同じビットに適用されると、宛先アドレス（DA）が正しい内部値に返される。
As noted in Section 4.2, this mapping results in an edge network using a /48 external prefix to be unable to use subnet 0xFFFF.
セクション4.2で述べたように、このマッピングは、/ 48外部プレフィックスを使用してエッジネットワークを使用してサブネット0xFFFFを使用できません。
The [RFC4291] IPv6 Address is reproduced for clarity in Figure 5.
[RFC4291] IPv6アドレスは、図5の明確にするために再生されます。
0 15 16 31 32 47 48 63 64 79 80 95 96 111 112 127
+-------+-------+-------+-------+-------+-------+-------+-------+
| Routing Prefix | Subnet| Interface Identifier (IID) |
+-------+-------+-------+-------+-------+-------+-------+-------+
Figure 5: Enumeration of the IPv6 Address [RFC4291]
図5：IPv6アドレスの列挙[RFC4291]
When an NPTv6 Translation function is configured, it is configured with
NPTV6変換関数が設定されている場合は、
o one or more "internal" interfaces with their "internal" routing domain prefixes, and
o 1つ以上の「内部」ルーティングドメインプレフィックスを使用すると、
o one or more "external" interfaces with their "external" routing domain prefixes.
o 1つ以上の「外部」ルーティングドメインプレフィックスを使用した1つ以上のインターフェイス。
In the simple case, there is one of each. If a single router provides NPTv6 translation services between a multiplicity of domains (as might be true when multihoming), each internal/external pair must be thought of as a separate NPTv6 Translator from the perspective of this specification.
シンプルな場合は、それぞれがあります。単一のルータが多数のドメイン間でNPTV6翻訳サービスを提供する場合（マルチホーム時にTRUGになる可能性があるように）、各内部/外部ペアは、この仕様の観点から別のNPTV6トランスレータと考える必要があります。
When an NPTv6 Translator is configured, the translation function first ensures that the internal and external prefixes are the same length, extending the shorter of the two with zeroes if necessary. These two prefixes will be used in the prefix translation function described in Sections 3.2 and 3.3.
NPTV6トランスレータが設定されている場合、変換関数は最初に内部プレフィックスと外部の接頭辞が同じ長さであることを確認し、必要に応じて2つの短い2つを短くします。これら2つの接頭辞は、セクション3.2と3.3に記載されているプレフィックス変換機能で使用されます。
They are then zero-extended to /64 for the purposes of a calculation. The translation function calculates the one's complement sum of the 16-bit words of the /64 external prefix and the /64 internal prefix. It then calculates the difference between these values: internal minus external. This value, called the "adjustment", is effectively constant for the lifetime of the NPTv6 Translator configuration and is used in per-datagram processing.
その後、計算の目的で/ 64にゼロ拡張されます。translation関数は、/ 64外部接頭辞の16ビットワードと/ 64内部プレフィックスの16ビットワードの補数合計を計算します。その後、これらの値の差を計算します。内部の外部。「調整」と呼ばれるこの値は、NPTV6トランスレータ構成の寿命に対して効果的に一定であり、データグラム毎の処理で使用されます。
When a datagram passes through the NPTv6 Translator from an internal to an external network, its IPv6 Source Address is either changed in two ways or results in the datagram being discarded:
データグラムがNPTv6トランスレータを内部ネットワークから外部ネットワークに通過すると、IPv6の送信元アドレスは2つの方法で変更されます。
o If the internal subnet number has no mapping, such as being 0xFFFF or simply not mapped, discard the datagram. This SHOULD result in an ICMP Destination Unreachable.
o 内部サブネット番号に0xFFFFまたは単にマッピングされていないなど、マッピングがない場合は、データグラムを破棄します。これにより、ICMPの宛先が到達不能になるはずです。
o The internal prefix is overwritten with the external prefix, in effect subtracting the difference between the two checksums (the adjustment) from the pseudo-header's checksum, and
o 内部プレフィックスは外部プレフィックスで上書きされ、疑似ヘッダーのチェックサムからの2つのチェックサム（調整）の差を差し引いて、
o A 16-bit word of the address has the adjustment added to it using one's complement arithmetic. If the result is 0xFFFF, it is overwritten as zero. The choice of word is as specified in Sections 3.4 or 3.5 as appropriate.
o アドレスの16ビットワードには、補数演算を使用して調整が追加されています。結果が0xFFFFの場合は、ゼロとして上書きされます。単語の選択は、必要に応じてセクション3.4または3.5で指定されています。
When a datagram passes through the NPTv6 Translator from an external to an internal network, its IPv6 Destination Address is changed in two ways:
データグラムが外部ネットワークにNPTv6トランスレータを通過すると、IPv6宛先アドレスは2つの方法で変更されます。
o The external prefix is overwritten with the internal prefix, in effect adding the difference between the two checksums (the adjustment) to the pseudo-header's checksum, and
o 外部接頭辞は内部接頭辞で上書きされ、疑似ヘッダーのチェックサムへの2つのチェックサム（調整）の差を追加し、
o A 16-bit word of the address has the adjustment subtracted from it (bitwise inverted and added to it) using one's complement arithmetic. If the result is 0xFFFF, it is overwritten as zero. The choice of word is as specified in Section 3.4 or Section 3.5 as appropriate.
o アドレスの16ビットワードには、補数演算を使用して、調整がIT（ビットごとに反転して追加）されています。結果が0xFFFFの場合は、ゼロとして上書きされます。単語の選択は、必要に応じてセクション3.4またはセクション3.5で指定されています。
When an NPTv6 Translator is configured with internal and external prefixes that are 48 bits in length (a /48) or shorter, the adjustment MUST be added to or subtracted from bits 48..63 of the address.
長さ（A / 48）または短い内部および外部プレフィックスでNPTV6トランスレータが設定されている場合は、アドレスのビット48..63に調整を追加または減算する必要があります。
This mapping results in no modification of the Interface Identifier (IID), which is held in the lower half of the IPv6 address, so it will not interfere with future protocols that may use unique IIDs for node identification.
このマッピングにより、IPv6アドレスの下半分に保持されているインターフェイス識別子（IID）を変更することはできませんので、ノード識別に固有のIIDを使用する可能性がある将来のプロトコルを妨害しません。
NPTv6 Translator implementations MUST implement the /48 mapping.
NPTV6トランスレータの実装は/ 48マッピングを実装する必要があります。
When an NPTv6 Translator is configured with internal and external prefixes that are longer than 48 bits in length (such as a /52, /56, or /60), the adjustment must be added to or subtracted from one of the words in bits 64..79, 80..95, 96..111, or 112..127 of the address. While the choice of word is immaterial as long as it is consistent, these words MUST be inspected in that sequence and the first that is not initially 0xFFFF chosen, for consistency's sake.
NPTv6トランスレータが48ビットより長い内部および外部プレフィックスで設定されている場合（A / 52、/ 56、または/ 60など）、ビット64の単語の1つに調整を追加または減算する必要があります。.. 79,80..95,96..111、または112..127。単語の選択は不具合ではないが、これらの単語はそのシーケンスで検査されなければならず、最初に整合性のために0xFFFFが選択されていなければならない。
NPTv6 Translator implementations SHOULD implement the mapping for longer prefixes.
NPTV6トランスレータの実装は、より長いプレフィックスのマッピングを実装する必要があります。
For the network shown in Figure 1, the Internal Prefix is FD01:0203: 0405:/48, and the External Prefix is 2001:0DB8:0001:/48.
図1に示すネットワークでは、内部プレフィックスはFD01：0203：0405：/ 48、外部プレフィックスは2001：0db8：0001：/ 48です。
If a node with internal address FD01:0203:0405:0001::1234 sends an outbound datagram through the NPTv6 Translator, the resulting external address will be 2001:0DB8:0001:D550::1234. The resulting address is obtained by calculating the checksum of both the internal and external 48-bit prefixes, subtracting the internal prefix from the external prefix using one's complement arithmetic to calculate the "adjustment", and adding the adjustment to the 16-bit subnet field (in this case, 0x0001).
内部アドレスを持つノードFD01：0203：0405 :: 1234 NPTV6トランスレータを介してアウトバウンドデータグラムを送信すると、結果の外部アドレスは2001：0db8：0001：D550 :: 1234になります。結果のアドレスは、内部48ビットプレフィックスと外部の両方のプレフィックスのチェックサムを計算し、「調整」を計算し、16ビットサブネットフィールドへの調整を追加するために、外部プレフィックスから内部プレフィックスを差し引いて、外部接頭辞から内部プレフィックスを減算します。（この場合、0x0001）。
To show the work:
作業を表示するには
The one's complement checksum of FD01:0203:0405 is 0xFCF5. The one's complement checksum of 2001:0DB8:0001 is 0xD245. Using one's complement arithmetic, 0xD245 - 0xFCF5 = 0xD54F. The subnet in the original datagram is 0x0001. Using one's complement arithmetic, 0x0001 + 0xD54F = 0xD550. Since 0xD550 != 0xFFFF, it is not changed to 0x0000.
FD01の補数チェックサム：0203：0405は0xFCF5です。2001年の補数チェックサム：0db8：0001は0xD245です。補数算術演算を使用して、0xD245 - 0xFCF5 = 0xD54Fを使用します。元のデータグラムのサブネットは0x0001です。補数算術演算を使用して、0x0001 0xD54F = 0xD550。0xD550！= 0xFFFF以降、0x0000に変更されません。
So, the value 0xD550 is written in the 16-bit subnet area, resulting in a mapped external address of 2001:0DB8:0001:D550::1234.
したがって、値0xD550は16ビットサブネット領域に書き込まれ、2001：0db8：0001：D550 :: 1234のマッピングされた外部アドレスが得られます。
When a response datagram is received, it will contain the destination address 2001:0DB8:0001:D550::0001, which will be mapped back to FD01: 0203:0405:0001::1234 using the inverse mapping algorithm.
応答データグラムが受信されると、宛先アドレス2001：0db8：0001：D550 :: 0001：D550 :: 0001が含まれます。これは、逆マッピングアルゴリズムを使用して、FD01：0203：0001 :: 1234にバックされます。
In this case, the difference between the two prefixes will be calculated as follows:
この場合、2つの接頭辞の差は次のように計算されます。
Using one's complement arithmetic, 0xFCF5 - 0xD245 = 0x2AB0. The subnet in the original datagram = 0xD550. Using one's complement arithmetic, 0xD550 + 0x2AB0 = 0x0001. Since 0x0001 != 0xFFFF, it is not changed to 0x0000.
補数算術演算を使用して、0xFCF5 - 0xD245 = 0x2AB0。元のデータグラム= 0xD550のサブネット。補数算術演算を使用して、0xD550 0x2AB0 = 0x0001。0x0001！= 0xFFFF以来、0x0000に変更されません。
So the value 0x0001 is written into the subnet field, and the internal value of the subnet field is properly restored.
そのため、値0x0001がサブネットフィールドに書き込まれ、サブネットフィールドの内部値が正しく復元されます。
If the prefix being mapped is longer than 48 bits, the algorithm is slightly more complex. A common case will be that the internal and external prefixes are of different lengths. In such a case, the shorter prefix is zero-extended to the length of the longer as described in Section 3.1 for the purposes of overwriting the prefix. Then, they are both zero-extended to 64 bits to facilitate one's complement arithmetic. The "adjustment" is calculated using those 64-bit prefixes.
マッピングされているプレフィックスが48ビットより長い場合、アルゴリズムはもう少し複雑です。一般的なケースは、内部プレフィックスと外部の接頭辞が長さが異なるということです。そのような場合、プレフィックスを上書きする目的で、より短い接頭辞はセクション3.1に記載されているように長さの長さまでゼロ拡張されます。その後、それらは両方とも、補数演算を容易にするために64ビットにゼロ拡張されています。「調整」は、それらの64ビットの接頭辞を使用して計算されます。
For example, if the internal prefix is a /48 ULA and the external prefix is a /56 provider-allocated prefix, the ULA becomes a /56 with zeros in bits 48..55. For purposes of one's complement arithmetic, they are then both zero-extended to 64 bits. A side effect of this is that a subset of the subnets possible in the shorter prefix is untranslatable. While the security value of this is debatable, the administration may choose to use them for subnets that it knows need no external accessibility.
たとえば、内部プレフィックスが/ 48 ULAで、外部プレフィックスが/ 56プロバイダ割り当てられた接頭辞の場合、ULAはゼロがビット48..55でA / 56になります。補数演算の目的のために、それらは両方とも64ビットにゼロ拡張されます。この副作用は、より短い接頭辞で可能なサブネットのサブセットが翻訳不可能であることです。これのセキュリティ値は議論可能ですが、管理者は、外部のアクセシビリティが必要な場合はサブネットに使用することを選択できます。
We then find the first word in the IID that does not have the value 0xFFFF, trying bits 64..79, and then 80..95, 96..111, and finally 112..127. We perform the same calculation (with the same proof of correctness) as in Section 3.6 but apply it to that word.
その後、VITS 64..79、次に80..95,96..111、そして最後に112..127、そして最後に110.127を試してみるIIDの最初の単語を見つけました。セクション3.6のように同じ計算（同じ正当性の証明）を実行しますが、その単語に適用されます。
Although any 16-bit portion of an IPv6 IID could contain 0xFFFF, an IID of all-ones is a reserved anycast identifier that should not be used on the network [RFC2526]. If an NPTv6 Translator discovers a datagram with an IID of all-zeros while performing address mapping, that datagram MUST be dropped, and an ICMPv6 Parameter Problem error SHOULD be generated [RFC4443].
IPv6 IIDの16ビット部分には0xFFFFを含めることができますが、すべてのIDのIIDはネットワーク上で使用しないでください[RFC2526]では、予約されていない識別識別子です。NPTV6トランスレータがアドレスマッピングを実行しながらALL-ZEROSのIIDを使用してデータグラムを検出した場合、そのデータグラムはドロップされなければならず、ICMPv6パラメータ問題エラーが発生する必要があります[RFC4443]。
Note: This mechanism does involve modification of the IID; it may not be compatible with future mechanisms that use unique IIDs for node identification.
注：このメカニズムはIIDの修正を含みます。ノード識別に固有のIIDを使用する将来のメカニズムと互換性がありません。
NPTv6 Translators MUST support manual configuration of internal and external prefixes and MUST NOT place any restrictions on those prefixes except that they be valid IPv6 unicast prefixes as described in [RFC4291]. They MAY also support random generation of ULA addresses on command. Since the most common place anticipated for the implementation of an NPTv6 Translator is a Customer Premises Equipment (CPE) router, the reader is urged to consider the requirements of [RFC6204].
NPTV6トランスレータは、内部プレフィックスと外部プレフィックスの手動設定をサポートし、[RFC4291]に記載されているように、それらが有効なIPv6ユニキャストプレフィックスであることを除いて、それらのプレフィックスに制限を配置してはいけません。それらは、コマンド上のランダムな生成のULAアドレスをサポートしてもよい。NPTV6トランスレータの実装に予想される最も一般的な場所は、顧客宅内機器（CPE）ルーターであるため、リーダーは[RFC6204]の要件を考慮して促されます。
For reasons detailed in Appendix B, a network using NPTv6 Translation and a /48 external prefix MUST NOT use the value 0xFFFF to designate a subnet that it expects to be translated.
付録Bに詳述されている理由で、NPTv6変換とA / 48外部接頭辞を使用したネットワークは、翻訳される予定のサブネットを指定するために0xFFFFを使用しないでください。
NPTv6 Translators MUST support hairpinning behavior, as defined in the NAT Behavioral Requirements for UDP document [RFC4787]. This means that when an NPTv6 Translator receives a datagram on the internal interface that has a destination address that matches the site's external prefix, it will translate the datagram and forward it internally. This allows internal nodes to reach other internal nodes using their external, global addresses when necessary.
NPTV6トランスレータは、UDPドキュメントのNAT動作要件[RFC4787]で定義されているように、ヘアピンの動作をサポートしている必要があります。つまり、NPTV6トランスレータがサイトの外部プレフィックスと一致する宛先アドレスを持つ内部インターフェイスでデータグラムを受信した場合、データグラムを内部的に転送します。これにより、内部ノードは、必要に応じて、外部のグローバルアドレスを使用して他の内部ノードに到達できます。
Conceptually, the datagram leaves the domain (is translated as described in Section 3.2) and returns (is again translated as described in Section 3.3). As a result, the datagram exchange will be through the NPTv6 Translator in both directions for the lifetime of the session. The alternative would be to require the NPTv6 Translator to drop the datagram, forcing the sender to use the correct internal prefix for its peer. Performing only the external-to-internal translation results in the datagram being sent from the untranslated internal address of the source to the translated and therefore internal address of its peer, which would enable the session to bypass the NPTv6 Translator for future datagrams. It would also mean that the original sender would be unlikely to recognize the response when it arrived.
概念的には、データグラムはドメインを残して（セクション3.2の説明に従って変換されます）、戻り値（セクション3.3で説明されているように翻訳されます）。その結果、データグラム交換は、セッションの有効期間の両方向のNPTV6トランスレータを介して行われます。この代わりに、NPTv6トランスレータがデータグラムをドロップするようにデータグラムをドロップする必要があるため、送信者に正しい内部プレフィックスを使用するようにします。外部から内部への変換のみを実行すると、ソースの非翻訳内部アドレスから翻訳されていない内部アドレスからその翻訳されたそのピアの内部アドレスに送信されます。これにより、セッションが将来のデータグラムにNPTV6トランスレータを迂回することができます。また、元の送信者が到着したときに応答を認識する可能性が低いことも意味します。
Because NPTv6 does not perform port mapping and uses a one-to-one, reversible-mapping algorithm, none of the other NAT behavioral requirements apply to NPTv6.
NPTV6はポートマッピングを実行していないため、1対1のリバーシブルマッピングアルゴリズムを使用しているため、NPTV6に適用されません。
NPTv6 Translation does not create several of the problems known to exist with other kinds of NATs as discussed in [RFC2993]. In particular, NPTv6 Translation is stateless, so a "reset" or brief outage of an NPTv6 Translator does not break connections that traverse the translation function, and if multiple NPTv6 Translators exist between the same two networks, the load can shift or be dynamically load shared among them. Also, an NPTv6 Translator does not aggregate traffic for several hosts/interfaces behind a fewer number of external addresses, so there is no inherent expectation for an NPTv6 Translator to block new inbound flows from external hosts and no issue with a filter or blacklist associated with one prefix within the domain affecting another. A firewall can, of course, be used in conjunction with an NPTv6 Translator; this would allow the network administrator more flexibility to specify security policy than would be possible with a traditional NAT.
NPTv6翻訳は、[RFC2993]で説明したように他の種類のNATと存在することが知られているいくつかの問題を生み出していません。特に、NPTV6翻訳はステートレスであるため、NPTV6トランスレータの「リセット」または短時間の停止は、翻訳機能をトラバースする接続を壊しません。それらの間で共有されています。また、NPTV6トランスレータは、いくつかのhosts /インターフェイスの数を数個の外部アドレスの背後にある場合のトラフィックを集約しません。そのため、NPTv6トランスレータには、外部ホストからの新しい受信フローをブロックし、フィルタまたはブラックリストに関連付けられていません。別のドメイン内の1つのプレフィックス。ファイアウォールは、もちろん、NPTV6トランスレータと組み合わせて使用することができます。これにより、ネットワーク管理者は、従来のNATで可能ながらセキュリティポリシーを指定することができます。
However, NPTv6 Translation does create difficulties for some kinds of applications. Some examples include:
ただし、NPTV6翻訳はある種のアプリケーションにとって困難を生み出しています。いくつかの例は次のとおりです。
o An application instance "behind" an NPTv6 Translator will see a different address for its connections than its peers "outside" the NPTv6 Translator.
o NPTV6トランスレータの「後部」のアプリケーションインスタンスは、NPTV6トランスレータの「外側」のピアよりも異なるアドレスを表示します。
o An application instance "outside" an NPTv6 Translator will see a different address for its connections than any peer "inside" an NPTv6 Translator.
o アプリケーションインスタンス「外部」NPTV6トランスレータは、その接続に異なるアドレスを表示します。
o An application instance wishing to establish communication with a peer "behind" an NPTv6 Translator may need to use a different address to reach that peer depending on whether the instance is behind the same NPTv6 Translator or external to it. Since an NPTv6 Translator implements hairpinning (Section 4.3), it suffices for applications to always use their external addresses. However, this creates inefficiencies in the local network and may also complicate implementation of the NPTv6 Translator. [RFC3484] also would prefer the private address in such a case in order to reduce those inefficiencies.
o インスタンスが同じNPTv6トランスレータの背後にあるか、またはその外部のものに応じて、ITV6トランスレータのピアと通信を確立することを望むアプリケーションインスタンスは、そのピアに到達するために異なるアドレスを使用する必要があるかもしれません。NPTV6トランスレータはヘアピニングを実装しているので（セクション4.3）、アプリケーションは常に外部アドレスを使用するのに十分です。ただし、これはローカルネットワークに非効率性を生み出し、NPTv6トランスレータの実装も複雑になる可能性があります。[RFC3484]また、それらの非効率性を低下させるためにそのような場合のプライベートアドレスを好むであろう。
o An application instance that moves from a realm "behind" an NPTv6 Translator to a realm that is "outside" the network, or vice versa, may find that it is no longer able to reach its peers at the same addresses it was previously able to use.
o NPTV6トランスレータのレルムからネットワークの「外側」、またはその逆のレルムに移動するアプリケーションインスタンスは、以前にできるのと同じアドレスでそのピアに到達できなくなることがわかります。使用する。
o An application instance that is intermittently communicating with a peer that moves from behind an NPTv6 Translator to "outside" of it, or vice versa, may find that it is no longer able to reach that peer at the same address that it had previously used.
o NPTV6トランスレータの後ろからITの「外側」に移動するピアと断続的に通信しているアプリケーションインスタンスは、以前に使用されたのと同じアドレスでそのピアに到達できなくなることがわかります。
Many, but not all, of the applications that are adversely affected by NPTv6 Translation are those that do "referrals" -- where an application instance passes its own addresses, and/or addresses of its peers, to other peers. (Some believe referrals are inherently undesirable; others believe that they are necessary in some circumstances. A discussion of the merits of referrals, or lack thereof, is beyond the scope of this document.)
NPTv6翻訳の影響を悪影響されるアプリケーションの多くではありませんが、アプリケーションインスタンスがその独自のアドレス、および/またはそのピアのアドレスを他のピアに渡すものです。（紹介は本質的に望ましくありません。他の人は、状況によっては彼らが必要であると信じています。紹介のメリット、またはその欠如についての議論はこの文書の範囲を超えています。）
To some extent, the incidence of these difficulties can be reduced by DNS hacks that attempt to expose addresses "behind" an NPTv6 Translator only to hosts that are also behind the same NPTv6 Translator and perhaps to also expose only the "internal" addresses of hosts behind the NPTv6 Translator to other hosts behind the same NPTv6 Translator. However, this cannot be a complete solution. A full discussion of these issues is out of scope for this document, but briefly: (a) reliance on DNS to solve this problem depends on hosts always making queries from DNS servers in the same realm as they are (or on DNS interception proxies, which create their own problems) and on mobile hosts/applications not caching those results; (b) reliance on DNS to solve this problem depends on network administrators on all networks using such applications to reliably and accurately maintain current DNS entries for every host using those applications; and (c) reliance on DNS to solve this problem depends on applications always using DNS names, even though they often must run in environments where DNS names are not reliably maintained for every host. Other issues are that there is often no single distinguished name for a host and no reliable way for a host to determine what DNS names are associated with it and which names are appropriate to use in which contexts.
ある程度まで、これらの困難の発生率は、同じNPTV6翻訳者の背後にあるホストにのみ「後ろ」アドレスを「後ろ」のアドレスを公開しようとすることができ、おそらくホストの「内部の」アドレスのみを公開することを試みることができます。 NPTV6翻訳者と同じNPTV6翻訳者の背後にある他のホストへの背後にある。ただし、これは完全な解決策になることはできません。これらの問題についての詳しい説明はこの文書の範囲外ですが、簡単に説明します。（a）この問題を解決するためのDNSへの依存は、常にDNSサーバーからのクエリを同じレルム（またはDNS遮断プロキシで）のクエリを作成することによって異なります。それは彼ら自身の問題を生み出し、そしてモバイルホスト/アプリケーションでそれらの結果をキャッシュしていません。 （b）この問題を解決するためのDNSへの依存この問題は、そのようなアプリケーションを使用してすべてのネットワーク上のネットワーク管理者によって異なります。これらのアプリケーションを使用してすべてのホストの現在のDNSエントリを正確に維持します。 （c）この問題を解決するためのDNSへの信頼は、常にDNS名を使用しても、DNS名がすべてのホストに対して確実に維持されていない環境で実行する必要がありますが、常にDNS名を使用しているアプリケーションによって異なります。その他の問題は、ホストに単一の識別名がないことが多く、ホストがそれに関連付けられているものとどの名前がどの名前に関連しているのか、どのコンテキストで使用するのに適しているかを判断することはできません。
5.1. Recommendation for Network Planners Considering Use of NPTv6 Translation
5.1. NPTV6翻訳の使用を考慮したネットワークプランナーの推奨事項
In light of the above, network planners considering the use of NPTv6 translation should carefully consider the kinds of applications that they will need to run in the future and determine whether the address-stability and provider-independence benefits are consistent with their application requirements.
上記に照らして、NPTV6翻訳の使用を考慮したネットワークプランナーは、将来実行する必要があるアプリケーションの種類を慎重に検討し、アドレス安定性とプロバイダに依存しない利益がそれらのアプリケーション要件と一致しているかどうかを判断する必要があります。
Several mechanisms (e.g., STUN [RFC5389], Traversal Using Relays around NAT (TURN) [RFC5766], and Interactive Connectivity Establishment (ICE) [RFC5245]) have been used with traditional IPv4 NAT to circumvent some of the limitations of such devices. Similar mechanisms could also be applied to circumvent some of the issues with an NPTv6 Translator. However, all of these require the assistance of an external server or a function co-located with the translator that can tell an "internal" host what its "external" addresses are.
いくつかのメカニズム（例えば、STUN [RFC5389]、NAT（ターン）[RFC5766]、およびインタラクティブ接続確立（ICE）[RFC5245]）を使用して、そのようなデバイスのいくつかの制限を回避するために従来のIPv4 NATと共に使用されてきました。NPTV6トランスレータに関する問題のいくつかを回避するためにも同様のメカニズムを適用することができます。ただし、これらのすべては、「内部」ホストに「外部」アドレスがあるのかを「内部」ホストに指示できる、外部サーバーまたは翻訳者と同じ機能を支援する必要があります。
It might be desirable to define a general mechanism that would allow hosts within a translation domain to determine their external addresses and/or request that inbound traffic be permitted. If such a mechanism were to be defined, it would ideally be general enough to also accommodate other types of NAT likely to be encountered by IPV6 applications, in particular IPv4/IPv6 Translation [RFC6144] [RFC6147] [RFC6145] [RFC6146] [RFC6052]. For this and other reasons, such a mechanism is beyond the scope of this document.
翻訳ドメイン内のホストがそれらの外部アドレスを決定することを可能にする一般的なメカニズムを定義し、そのインバウンドトラフィックを許可することを要求することが望ましいかもしれません。そのようなメカニズムが定義された場合、それは理想的にはIPv6アプリケーション、特にIPv4 / IPv6翻訳によって遭遇する可能性がある他の種類のNATにも対応するのに十分なほど一般的なものであろう[RFC6147] [RFC6146] [RFC6052]。この理由や他の理由で、そのようなメカニズムはこの文書の範囲を超えています。
In addition to overwriting IP addresses when datagrams are forwarded, NAPT44 devices overwrite the source port number in outbound traffic and the destination port number in inbound traffic. This mechanism is called "port mapping".
データグラムが転送されたときにIPアドレスを上書きすることに加えて、NAPT44デバイスは送信トラフィック内の送信元ポート番号と宛先ポート番号を着信トラフィックで上書きします。このメカニズムは「ポートマッピング」と呼ばれます。
The major benefit of port mapping is that it allows multiple computers to share a single IPv4 address. A large number of internal IPv4 addresses (typically from one of the [RFC1918] private address spaces) can be mapped into a single external, globally routable IPv4 address, with the local port number used to identify which internal node should receive each inbound datagram. This address-amplification feature is not generally foreseen as a necessity at this time.
ポートマッピングの主な利点は、複数のコンピュータが単一のIPv4アドレスを共有できることです。多数の内部IPv4アドレス（通常は[RFC1918]プライベートアドレススペースの1つから）を単一の外部グローバルにルーティング可能なIPv4アドレスにマッピングできます。ローカルポート番号は、どの内部ノードに各インバウンドデータグラムを受信する必要があるかを識別できます。このアドレス増幅機能は、このとき必要に応じて予測されていない。
Since port mapping requires rewriting a portion of the transport layer header, it requires NAPT44 devices to be aware of all of the transport protocols that they forward, thus stifling the development of new and improved transport protocols and preventing the use of IPsec encryption. Modifying the transport layer header is incompatible with security mechanisms that encrypt the full IP payload and restricts the NAPT44 to forwarding transport layers that use weak checksum algorithms that are easily recalculated in routers.
ポートマッピングはトランスポートレイヤヘッダの一部を書き換える必要があるため、NAPT44デバイスが転送されたすべてのトランスポートプロトコルを認識する必要があり、したがって新規および改善されたトランスポートプロトコルの開発を抑制し、IPSec暗号化の使用を防止します。トランスポートレイヤヘッダーの変更は、完全なIPペイロードを暗号化し、ルータで簡単に再計算される弱いチェックサムアルゴリズムを使用する転送トランスポート層にNAPT44を転送するセキュリティメカニズムと互換性がありません。
Since there is significant detriment caused by modifying transport layer headers and very little, if any, benefit to the use of port mapping in IPv6, NPTv6 Translators that comply with this specification MUST NOT perform port mapping.
トランスポートレイヤヘッダーを変更し、非常に少ない場合は、IPv6でのポートマッピングの使用に恩恵を受けることによって引き起こされます。この仕様に準拠したNPTV6トランスレータは、ポートマッピングを実行してはなりません。
When NPTv6 is deployed using either of the two-way, algorithmic mappings defined in this document, it allows direct inbound connections to internal nodes. While this can be viewed as a benefit of NPTv6 versus NAPT44, it does open internal nodes to attacks that would be more difficult in a NAPT44 network. From a security standpoint, although this situation is not substantially worse than running IPv6 with no NAT, some enterprises may assume that an NPTv6 Translator will offer similar protection to a NAPT44 device.
このドキュメントで定義されている双方向のアルゴリズムマッピングのいずれかを使用してNPTv6がデプロイされている場合は、内部ノードへの直接のインバウンド接続を可能にします。これはNAPT44とNAPT44の利点として表示されることができますが、NAPT44ネットワークではより困難な攻撃に内部ノードを開きます。セキュリティの観点からは、この状況はNATのないIPv6を実行するよりも実質的に悪化していませんが、NPTV6トランスレータがNAPT44デバイスに同様の保護を提供すると想定することがあります。
The port mapping mechanism in NAPT44 implementations requires that state be created in both directions. This has lead to an industry-wide perception that NAT functionality is the same as a stateful firewall. It is not. The translation function of the NAT only creates dynamic state in one direction and has no policy. For this reason, it is RECOMMENDED that NPTv6 Translators also implement firewall functionality such as described in [RFC6092], with appropriate configuration options including turning it on or off.
NAPT44実装のポートマッピングメカニズムには、状態を両方向に作成する必要があります。これは、NAT機能がステートフルファイアウォールと同じであるという業界全体の認識につながりました。そうではない。NATの翻訳機能は、一方向に動的な状態を作成し、ポリシーはありません。このため、NPTV6トランスレータは[RFC6092]で説明されているようなファイアウォール機能を実装することをお勧めします。
When [RFC4864] talks about randomizing the subnet identifier, the idea is to make it harder for worms to guess a valid subnet identifier at an advertised network prefix. This should not be interpreted as endorsing concealment of the subnet identifier behind the obfuscating function of a translator such as NPTv6. [RFC4864] specifically talks about how to obtain the desired properties of concealment without using a translator. Topology hiding when using NAT is often ineffective in environments where the topology is visible in application layer messaging protocols such as DNS, SIP, SMTP, etc. If the information were not available through the application layer, [RFC2993] would not be valid.
[RFC4864]がサブネット識別子をランダム化することについて話している場合、アイデアはワームがアドバタイズされたネットワークプレフィックスで有効なサブネット識別子を推測するのを難しくすることです。これは、NPTV6などの翻訳者の難読化機能の背後にあるサブネット識別子の承認隠蔽として解釈されるべきではありません。[RFC4864]は、翻訳者を使用せずに隠蔽の望ましい特性を得る方法について述べる。Topology SIDing NATは、DNS、SIP、SMTPなどのアプリケーションレイヤメッセージングプロトコルに表示されている環境では、トポロジが無効になっています。情報がアプリケーションレイヤを介して利用できない場合は、[RFC2993]は有効ではありません。
Due to the potential interactions with IKEv2/IPsec NAT traversal, it would be valuable to test interactions of NPTv6 with various aspects of current-day IKEv2/IPsec NAT traversal.
IKEv2 / IPSec NATトラバーサルとの潜在的な相互作用のために、NPTV6と現在のIKEV2 / IPsec NATトラバーサルのさまざまな側面との相互作用をテストするのに価値があります。
The checksum-neutral algorithmic address mapping described in this document is based on email written by Iljtsch van Beijnum.
この文書に記載されているチェックサム - 中立アルゴリズムアドレスマッピングは、ILJTSCH VAN Beijnumによって書かれた電子メールに基づいています。
The following people provided advice or review comments that substantially improved this document: Allison Mankin, Christian Huitema, Dave Thaler, Ed Jankiewicz, Eric Kline, Iljtsch van Beijnum, Jari Arkko, Keith Moore, Mark Townsley, Merike Kaeo, Ralph Droms, Remi Despres, Steve Blake, and Tony Hain.
以下の人は、この文書を大幅に改善したアドバイスやレビューのコメントを提供しました。アリソンマンキン、クリスチャンハイマ、Dave Thaler、Ed Jankiewicz、Eric Kline、Iljtsch van Beijnum、Jari Arkko、Keith Moore、Mark Townsley、Ralph Droms、Remi Despres、Steve Blake、Tony Hain。
[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月。
[RFC2526] Johnson, D. and S. Deering, "Reserved IPv6 Subnet Anycast Addresses", RFC 2526, March 1999.
[RFC2526] Johnson、D.およびS.Theering、 "Reserved IPv6サブネットAnycast Addresses"、RFC 2526、1999年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R.およびB.B.B.B. Haberman、「ユニークなローカルIPv6ユニキャストアドレス」、RFC 4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
【RFC4291】2006年2月、RFC4291。
[RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Theering、S.、およびM.Gupta、インターネットプロトコルバージョン6（IPv6）仕様のICMPv6（ICMPv6）、RFC 4443、2006年3月。
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007.
[RFC4787] Audet、F.およびC. Jennings、「ユニキャストUDPのネットワークアドレス翻訳（NAT）行動要件」、BCP 127、RFC 4787、2007年1月。
[GSE] O'Dell, M., "GSE - An Alternate Addressing Architecture for IPv6", Work in Progress, February 1997.
[GSE] O'Dell、M.、「GSE - IPv6の代替アドレッシングアーキテクチャ」、1997年2月の進行中の働き。
[NIST] NIST, "Draft NIST Framework and Roadmap for Smart Grid Interoperability Standards, Release 1.0", September 2009.
[NIST] NIST、「Smart Grid Interoperability Standards for Smart Grid Interoperability Standards Draft Draft Draft Draft Framework、Release 1.0」、2009年9月。
[RFC1071] Braden, R., Borman, D., Partridge, C., and W. Plummer, "Computing the Internet checksum", RFC 1071, September 1988.
[RFC1071] Braden、R.、Borman、D.、Partridge、C、およびW. Plummer、「インターネットチェックサムのコンピューティング」、RFC 1071、1988年9月。
[RFC1624] Rijsinghani, A., "Computation of the Internet Checksum via Incremental Update", RFC 1624, May 1994.
[RFC1624] Rijsinghani、A。、「インクリメンタル更新によるインターネットチェックサムの計算」、RFC 1624、1994年5月。
[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月。
[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] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否攻撃の破損」、BCP 38、RFC 2827、2000年5月。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T.、「NATの建築の意味」、2000年11月、RFC 2993。
[RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral Self-Address Fixing (UNSAF) Across Network Address Translation", RFC 3424, November 2002.
[RFC3424] Daigle、L.およびIab、2002年11月、RFC 3424、RFC 3424、RFC3424。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] Van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B.、E.Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J.、「インタラクティブ接続確立（氷）：募集/回答プロトコルのためのネットワークアドレス翻訳者（NAT）トラバースのためのプロトコル。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P.、およびD. Wing、「Nat（Stun）のセッショントラバーサルユーティリティ」、RFC 5389、2008年10月。
[RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)", RFC 5766, April 2010.
[RFC5766] Mahy、R.、Matthews、P.、J.Rosenberg、「NAT（ターン）周辺のリレーを使用したトラバーサル：2010年4月2010年4月、RFC 5766。
[RFC5902] Thaler, D., Zhang, L., and G. Lebovitz, "IAB Thoughts on IPv6 Network Address Translation", RFC 5902, July 2010.
[RFC5902] Thaler、D.、Zhang、L.、G.Lebovitz、「IABの考え」、「IAB想いIPv6ネットワークアドレス翻訳について」、RFC 5902、2010年7月。
[RFC5925] Touch, J., Mankin, A., and R. Bonica, "The TCP Authentication Option", RFC 5925, June 2010.
[RFC5925] Touch、J.、Mankin、A.、R. Bonica、 "TCP認証オプション"、RFC 5925、2010年6月。
[RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010.
[RFC5996] Kaufman、C.、Hoffman、P.、NIR、Y.、およびP.Eronen、「インターネットキー交換プロトコルバージョン2（IKEV2）」、RFC 5996、2010年9月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] BAO、C、Huitema、C、Bagnulo、M.、Boucadair、M.、およびX.Li、「IPv6 / IPv6翻訳者のIPv6アドレッシング」、RFC 6052、2010年10月。
[RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service", RFC 6092, January 2011.
[RFC6092] Woodyatt、J。、「顧客宅内機器の推奨単純なセキュリティ機能（顧客宅内機器（リゾジデートIPv6インターネットサービスを提供するためのCPE）の簡単なセキュリティ機能」、RFC 6092、2011年1月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X、Bao、C、K。Yin、「IPv4 / IPv6翻訳のためのフレームワーク」、RFC 6144、2011年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、BaO、C、およびF. Baker、「IP / ICMP翻訳アルゴリズム」、RFC 6145、2011年4月。
[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：IPv6クライアントからIPv4サーバーへのネットワークアドレスとプロトコル翻訳"、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、およびI. Van Beijnum、「DNS64：IPv6クライアントからIPv4サーバーへのネットワークアドレス翻訳のためのDNS拡張」、RFC 6147、2011年4月。
[RFC6204] Singh, H., Beebee, W., Donley, C., Stark, B., and O. Troan, "Basic Requirements for IPv6 Customer Edge Routers", RFC 6204, April 2011.
[RFC6204] Singh、H.、Beebee、W.、Donley、C.、Stark、B.、およびO. Troan、「IPv6カスタマーエッジルータの基本要件」、RFC 6204、2011年4月。
Appendix A. Why GSE?
付録A.なぜGSE？
For the purpose of this discussion, let us oversimplify the Internet's structure by distinguishing between two broad classes of networks: transit and edge. A "transit network", in this context, is a network that provides connectivity services to other networks. Its Autonomous System (AS) number may show up in a non-final position in BGP AS paths, or in the case of mobile and residential broadband networks, it may offer network services to smaller networks that cannot justify RIR membership. An "edge network", in contrast, is any network that is not a transit network; it is the ultimate customer, and while it provides internal connectivity for its own use, it is a consumer of transit services in other respects. In terms of routing, a network in the transit domain generally needs some way to make choices about how it routes to other networks; an edge network is generally quite satisfied with a simple default route.
この議論の目的のために、輸送とエッジの2つの幅広いクラスを区別することによってインターネットの構造を単純化しましょう。このコンテキストでは、「トランジットネットワーク」は、他のネットワークへの接続サービスを提供するネットワークです。その自律システム（AS）番号は、経路としてBGPの非最終位置に現れることがあり、モバイルおよび住宅のブロードバンドネットワークの場合には、RIRメンバーシップを正当化できない小型ネットワークにネットワークサービスを提供することができます。対照的に、「エッジネットワーク」は、トランジットネットワークではないネットワークです。それは究極の顧客です、そしてそれはそれ自身の利用のための内部接続を提供している間、それは他の点でトランジットサービスの消費者です。ルーティングの面では、トランジットドメイン内のネットワークは一般に、他のネットワークへのどのようにルートするかについての選択をするための何らかの方法を必要とします。エッジネットワークは一般に単純なデフォルトルートにかなり満足しています。
The [GSE] proposal, and as a result this proposal (which is similar to GSE in most respects and inspired by it), responds directly to current concerns in the RIR communities. Edge networks are used to an environment in IPv4 in which their addressing is disjoint from that of their upstream transit networks; it is either provider independent, or a network prefix translator makes their external address distinct from their internal address, and they like the distinction. In IPv6, there is a mantra that edge network addresses should be derived from their upstream, and if they have multiple upstreams, edge networks are expected to design their networks to use all of those prefixes equivalently. They see this as unnecessary and unwanted operational complexity and, as a result, are pushing very hard in the RIR communities for provider-independent addressing.
[GSE]提案、そしてその結果、この提案（これはほとんどの点でGSEと似ており、それに触発されている）は、RIRコミュニティの現在の懸念に直接対応します。エッジネットワークは、それらのアドレス指定がそれらの上流のトランジットネットワークのそれとが互いに素であるIPv4内の環境に使用されます。それはプロバイダーに依存しないか、ネットワークプレフィックストランスレータはそれらの内部アドレスと異なる外部アドレスを区別し、それらは区別のようなものです。IPv6では、エッジネットワークアドレスがそれらの上流から導出されるべきであるマントラがあり、それらが複数のアップストリームを持つ場合、エッジネットワークはそれらのネットワークを同等に使用するために彼らのネットワークを設計することが期待されています。彼らはこれを不必要で望ましくない運用的な複雑さとして見て、その結果、プロバイダに依存しないアドレッシングのためのRIRコミュニティで非常に困難になります。
Widespread use of provider-independent addressing has a natural and perhaps unavoidable side effect that is likely to be very expensive in the long term. With widespread PI addressing, the routing table will enumerate the networks at the edge of the transit domain, the edge networks, rather than enumerate the transit domain. Per the BGP Update Report of 17 December 2010, there are currently over 36,000 Autonomous Systems being advertised in BGP, of which over 15,000 advertise only one prefix. There are in the neighborhood of 5000 ASs that show up in a non-final position in AS paths, and perhaps another 5000 networks whose AS numbers are terminal in more than one AS path. In other words, we have prefixes for some 36,000 transit and edge networks in the route table now, many of which arguably need an Autonomous System number only for multihoming. The vast majority of networks (2/3) having the tools necessary to multihome are not visibly doing so and would be well served by any solution that gives them address independence without the overhead of RIR membership and BGP routing.
プロバイダに依存しないアドレス指定の広範な使用は、長期的には非常に高価である可能性が高い自然でありやむを得ない副作用を持っています。 WideDread PIアドレス指定では、ルーティングテーブルは、トランジットドメインを列挙するのではなく、トランストドメインのエッジでネットワークを列挙します。 2010年12月17日のBGP更新報告書で、現在15,000以上のプレフィックスしか広告しているBGPで宣伝されている36,000以上の自律システムがあります。 5000 ASSの近傍には、パスとして、最終的なポジションで表示されていない位置があり、おそらく数字として1つ以上の端末であるもう1つの5000ネットワークがあります。言い換えれば、我々は今ルートテーブル内の約36,000の輸送とエッジネットワークの接頭辞を持っています。その多くは、マルチホームのためだけに自律システム番号を必要としています。マルチホームに必要なツールを持つネットワークの大多数（2/3）は、視覚的には視覚的に実行されておらず、RIRメンバーシップとBGPルーティングのオーバーヘッドなしに独立性に対処する任意のソリューションによってよく提供されます。
Current growth estimates suggest that we could easily see that be on the order of 10,000,000 within fifteen years. Tens of thousands of entries in the route table are very survivable; while our protocols and computers will likely do quite well with tens of millions of routes, the heat produced and power consumed by those routers, and the inevitable impact on the cost of those routers, is not a good outcome. To avoid having a massive and unscalable route table, we need to find a way that is politically acceptable and returns us to enumerating the transit domain, not the edge.
現在の成長推定値は、15年以内に10,000,000程度であることを簡単に見ることができることを示唆しています。ルートテーブル内の数万のエントリは非常に存続可能です。私たちのプロトコルとコンピュータは、数十百万の経路、それらのルータによって生産され、消費された電力、およびそれらのルータのコストへの避けられない影響では、あった熱がよく、そしてそれらのルーターのコストへの不可避的な影響はありません。大規模でスキャン可能なルートテーブルを持つことを避けるためには、政治的に許容される方法を見つける必要があり、エッジではなくトランジットドメインの列挙を返す必要があります。
There have been a number of proposals. As described, Shim6 moves the complexity to the edge, and the edge is rebelling. Geographic addressing in essence forces ISPs to "own" geographic territory from a routing perspective, as otherwise there is no clue in the address as to what network a datagram should be delivered to in order to reach it. Metropolitan Addressing can imply regulatory authority and, even if it is implemented using internet exchange consortia, visits a great deal of complexity on the transit networks that directly serve the edge. The one that is likely to be most acceptable is any proposal that enables an edge network to be operationally independent of its upstreams, with no obligation to renumber when it adds, drops, or changes ISPs, and with no additional burden placed either on the ISP or the edge network as a result. From an application perspective, an additional operational requirement in the words of the Roadmap for the Smart Grid [NIST] is that
提案がいくつかありました。説明したように、Shim6は複雑さをエッジに移動させ、エッジは反転しています。本質的なアドレス指定は、ルーティングの観点からの地理的領域を「自身」していることを強制的に配信するために、それに到達するためにデータグラムを配信する必要があるのかに関しては、アドレスに手がかりがない。メトロポリタンのアドレッシングは規制当局を意味することがあり、たとえそれがインターネット交換コンソーシアを使用して実施されていても、直接エッジを提供するトランジットネットワーク上で大きな複雑さを訪問することができます。最も許容できるものは、エッジネットワークがその上流に独立していることを可能にする提案は、ISPを追加、ドロップ、または変更する義務は、ISP上に追加の負担をかけないでください。またはその結果としてのエッジネットワーク。アプリケーションの観点からは、スマートグリッド[NIST]のためのロードマップの単語の追加の運用要件です。
"...the network should provide the capability to enable an application in a particular domain to communicate with an application in any other domain over the information network, with proper management control as to who and where applications can be inter-connected."
「...ネットワークは、特定のドメイン内のアプリケーションが、情報ネットワークを介して他のドメイン内のアプリケーションと通信する機能を提供し、適切な管理制御を使用して、アプリケーションと相互接続することができる。」
In other words, the structure of the network should allow for and enable appropriate access control, but the structure of the network should not inherently limit access.
言い換えれば、ネットワークの構造は適切なアクセス制御を可能にして有効にする必要がありますが、ネットワークの構造は本質的にアクセスを制限してはなりません。
The GSE model, by statelessly translating the prefix between an edge network and its upstream transit network, accomplishes that with a minimum of fuss and bother. Stated in the simplest terms, it enables the edge network to behave as if it has a provider-independent prefix from a multihoming and renumbering perspective without the overhead of RIR membership or maintenance of BGP connectivity, and it enables the transit networks to aggressively aggregate what are from their perspective provider-allocated customer prefixes, to maintain a rational-sized routing table.
GSEモデルは、エッジネットワークとその上流のトランジットネットワークとの間の接頭辞を無限に変換することによって、最小限のFUSSと煩わしさでそれを達成します。最も簡単な用語で述べて、それは、RIRのメンバーシップまたはBGP接続の保守のオーバーヘッドなしに、それがマルチホームおよび番号を付け直すことなくプロバイダに依存しないプレフィックスを持っているかのようにエッジネットワークを動作させることができ、それはトランジットネットワークが何を積極的に集約することを可能にします。プロバイダ割り当て済みの顧客プレフィックスからのもので、合理的サイズのルーティングテーブルを維持します。
This non-normative appendix is presented as a proof of concept; it is in no sense optimized. For example, one's complement arithmetic is implemented in portable subroutines, where operational implementations might use one's complement arithmetic instructions through a pragma; such implementations probably need to explicitly force 0xFFFF to 0x0000, as the instruction will not. The original purpose of the code was to verify whether or not it was necessary to suppress 0xFFFF by overwriting with zero and whether predicted issues with subnet numbering were real.
この非規範的付録は、概念の証明として提示されています。それは意味がありません最適化されていません。たとえば、1の補数演算はポータブルサブルーチンで実装されています。そこでは、運用実装はプラグマを通して補数演算命令を使用することができます。そのような実装は、命令がそうでないので、おそらく0xFFFFを0x0000に明示的に強制する必要がある。コードの元の目的は、ゼロで上書きすることによって0xFFFFを抑制する必要があるかどうかを検証することでした。
The point is to
ポイントは
o demonstrate that if one or the other representation of zero is not used in the word in which the checksum is updated, the program maps inner and outer addresses in a manner that is, mathematically, 1:1 and onto (each inner address maps to a unique outer address, and that outer address maps back to exactly the same inner address), and
o チェックサムが更新される単語でゼロの1つまたは他の表現が使用されていない場合、プログラムは、数学的に、1：1および上にある方法で内側アドレスと外側アドレスをマッピングすることを示している（各インナーアドレスはAにマップされます。ユニークな外部アドレス、およびその外側のアドレスはまったく同じ内部アドレスに戻ります）、
o give guidance on the suppression of 0xFFFF checksums.
o 0xFFFFチェックサムの抑制に関するガイダンスを与えます。
In short, in one's complement arithmetic, x-x=0 but will take the negative representation of zero. If 0xFFFF results are forced to the value 0x0000, as is recommended in [RFC1071], the word the checksum is adjusted in cannot be initially 0xFFFF, as on the return it will be forced to 0. If 0xFFFF results are not forced to the value 0x0000 as is recommended in [RFC1071], the word the checksum is adjusted in cannot be initially 0, as on the return it will be calculated as 0+(~0) = 0xFFFF. We chose to follow [RFC1071]'s recommendations, which implies a requirement to not use 0xFFFF as a subnet number in networks with a /48 external prefix.
要するに、自分の補数算術演算では、x-x = 0であるが、ゼロの負の表現を取ります。[RFC1071]で0x0000の値が0x0000に強制されている場合、チェックサムが最初に調整されているWORDは最初は0xFFFFになることはできません.0xFFFFの結果が値に強制されていない場合0x0000 [RFC1071]で推奨されているように、チェックサムが最初に調整されていないWORDは0（~0）= 0xFFFFとして計算されます。私たちは[RFC1071]の勧告をフォローすることを選択しました。
/*
* Copyright (c) 2011 IETF Trust and the persons identified as
* authors of the code. All rights reserved.
*
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
*
* - Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
*
* - Redistributions in binary form must reproduce the above
* copyright notice, this list of conditions and the following
* disclaimer in the documentation and/or other materials provided
* with the distribution.
*
* - Neither the name of Internet Society, IETF or IETF Trust, nor
* the names of specific contributors, may be used to endorse or
* promote products derived from this software without specific
* prior written permission.
*
* THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
* CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
* INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
* MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
* DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS
* BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
* EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
* TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE,
* DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
* ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
* OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
#include "stdio.h"
#include "assert.h"
/*
* program to verify the NPTv6 algorithm
*
* argument:
* Perform negative zero suppression: boolean
*
* method:
* We specify an internal and an external prefix. The prefix
* length is presumed to be the common length of both and, for
* this, is a /48. We perform the three algorithms specified.
* The "datagram" address is in effect the source address
* internal->external and the destination address
* external->internal.
*/
unsigned short inner_init[] = {
0xFD01, 0x0203, 0x0405, 1, 2, 3, 4, 5};
unsigned short outer_init[] = {
0x2001, 0x0db8, 0x0001, 1, 2, 3, 4, 5};
unsigned short inner[8];
unsigned short datagram[8];
unsigned char checksum[65536] = {0};
unsigned short outer[8];
unsigned short adjustment;
unsigned short suppress;
/*
* One's complement sum.
* return number1 + number2
*/
unsigned short
add1(number1, number2)
unsigned short number1;
unsigned short number2;
{
unsigned int result;
result = number1;
result += number2;
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* One's complement difference
* return number1 - number2
*/
unsigned short
sub1(number1, number2)
unsigned short number1;
unsigned short number2;
{
return add1(number1, ~number2);
}
/*
* return one's complement sum of an array of numbers
*/
unsigned short
sum1(numbers, count)
unsigned short *numbers;
int count;
{
unsigned int result;
符号なしINTの結果
result = *numbers++;
while (--count > 0) {
result += *numbers++;
}
if (suppress) {
while (0xFFFF <= result) {
result = result + 1 - 0x10000;
}
} else {
while (0xFFFF < result) {
result = result + 1 - 0x10000;
}
}
return result;
}
/*
* NPTv6 initialization: Section 3.1 assuming Section 3.4
*
* Create the /48, a source address in internal format, and a
* source address in external format. Calculate the adjustment
* if one /48 is overwritten with the other.
*/
void
nptv6_initialization(subnet)
unsigned short subnet;
{
int i;
unsigned short inner48;
unsigned short outer48;
/* Initialize the internal and external prefixes. */
for (i = 0; i < 8; i++) {
inner[i] = inner_init[i];
outer[i] = outer_init[i];
}
inner[3] = subnet;
outer[3] = subnet;
/* Calculate the checksum adjustment. */
inner48 = sum1(inner, 3);
outer48 = sum1(outer, 3);
adjustment = sub1(inner48, outer48);
}
/*
* NPTv6 datagram from edge to transit: Section 3.2 assuming
* Section 3.4
*
* Overwrite the prefix in the source address with the outer
* prefix and adjust the checksum.
*/
void
nptv6_inner_to_outer()
{
int i;
/* Let's get the source address into the datagram. */
for (i = 0; i < 8; i++) {
datagram[i] = inner[i];
}
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = outer[i];
}
/* Adjust the checksum. */
datagram[3] = add1(datagram[3], adjustment);
}
/*
* NPTv6 datagram from transit to edge: Section 3.3 assuming
* Section 3.4
*
* Overwrite the prefix in the destination address with the
* inner prefix and adjust the checksum.
*/
void
nptv6_outer_to_inner()
{
int i;
/* Overwrite the prefix with the outer prefix. */
for (i = 0; i < 3; i++) {
datagram[i] = inner[i];
}
/* Adjust the checksum. */
datagram[3] = sub1(datagram[3], adjustment);
}
/*
* Main program
*/
main(argc, argv)
int argc;
char **argv;
{
unsigned subnet;
int i;
if (argc < 2) {
fprintf(stderr, "usage: nptv6 supression\n");
assert(0);
}
suppress = atoi(argv[1]);
assert(suppress <= 1);
for (subnet = 0; subnet < 0x10000; subnet++) {
/* Section 3.1: initialize the system */
nptv6_initialization(subnet);
/* Section 3.2: take a datagram from inside to outside */
nptv6_inner_to_outer();
/* The resulting checksum value should be unique. */
if (checksum[subnet]) {
printf("inner->outer duplicated checksum: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8), datagram[0], datagram[1],
datagram[2], datagram[3], datagram[4],
datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
checksum[subnet] = 1;
チェックサム[サブネット] = 1。
/*
* The resulting checksum should be the same as the inner
* address's checksum.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("inner->outer incorrect: "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
inner[0], inner[1], inner[2], inner[3],
inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8),
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8));
}
/* Section 3.3: take a datagram from outside to inside */
nptv6_outer_to_inner();
/*
* The returning datagram should have the same checksum it
* left with.
*/
if (sum1(datagram, 8) != sum1(inner, 8)) {
printf("outer->inner checksum incorrect: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x(%x) "
"inner: %x:%x:%x:%x:%x:%x:%x:%x(%x)\n",
datagram[0], datagram[1], datagram[2], datagram[3],
datagram[4], datagram[5], datagram[6], datagram[7],
sum1(datagram, 8), inner[0], inner[1], inner[2],
inner[3], inner[4], inner[5], inner[6], inner[7],
sum1(inner, 8));
}
/*
* And every octet should calculate back to the same inner
* value.
*/
for (i = 0; i < 8; i++) {
if (inner[i] != datagram[i]) {
printf("outer->inner different: "
"calculated: %x:%x:%x:%x:%x:%x:%x:%x "
"inner: %x:%x:%x:%x:%x:%x:%x:%x\n",
datagram[0], datagram[1], datagram[2],
datagram[3], datagram[4], datagram[5],
datagram[6], datagram[7], inner[0], inner[1],
inner[2], inner[3], inner[4], inner[5],
inner[6], inner[7]);
break;
}
}
}
}
Authors' Addresses
著者の住所
Margaret Wasserman Painless Security North Andover, MA 01845 USA
マーガレットWassermanの痛みのないセキュリティNorth Andover、Ma 01845 USA
Phone: +1 781 405 7464
EMail: mrw@painless-security.com
URI: http://www.painless-security.com
Fred Baker Cisco Systems Santa Barbara, California 93117 USA
フレッドベイカーシスコシステムズサンタバーバラ、カリフォルニア州93117 USA
Phone: +1-408-526-4257
EMail: fred@cisco.com