[要約] RFC 7600は、IPv4残存展開をIPv6を介して行うための状態を持たない解決策（4rd）についての規格です。この規格の目的は、IPv4アドレスの枯渇を解決するために、IPv6ネットワーク上でIPv4サービスを提供する方法を提案することです。
Internet Engineering Task Force (IETF) R. Despres
Request for Comments: 7600 RD-IPtech
Category: Experimental S. Jiang, Ed.
ISSN: 2070-1721 Huawei Technologies Co., Ltd
R. Penno
Cisco Systems, Inc.
Y. Lee
Comcast
G. Chen
China Mobile
M. Chen
BBIX, Inc.
July 2015
IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)
IPv6によるIPv4残りの展開-ステートレスソリューション（第4）
Abstract
概要
This document specifies a stateless solution for service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers. The solution's distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end. Each customer can be assigned one public IPv4 address, several public IPv4 addresses, or a shared address with a restricted port set.
このドキュメントは、サービスプロバイダーがIPv6のみのネットワークドメインを段階的に展開しながら、顧客にIPv4サービスを提供するためのステートレスソリューションを指定します。ソリューションの特徴的な特性は、TCP / UDP IPv4パケットがドメイントラバーサル中に有効なTCP / UDP IPv6パケットであり、IPv4フラグメンテーションルールが完全にエンドツーエンドで保持されることです。各顧客には、1つのパブリックIPv4アドレス、複数のパブリックIPv4アドレス、または制限されたポートが設定された共有アドレスを割り当てることができます。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントはInternet Standards Trackの仕様ではありません。試験、実験、評価のために公開されています。
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（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7600.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7600で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................4
2. Terminology .....................................................5
3. The 4rd Model ...................................................7
4. Protocol Specifications .........................................9
4.1. NAT44 on CE ................................................9
4.2. Mapping Rules and Other Domain Parameters .................10
4.3. Reversible Packet Translations at Domain Entries
and Exits .................................................11
4.4. Address Mapping from CE IPv6 Prefixes to 4rd IPv4
Prefixes ..................................................17
4.5. Address Mapping from 4rd IPv4 Addresses to 4rd
IPv6 Addresses ............................................19
4.6. Fragmentation Processing ..................................23
4.6.1. Fragmentation at Domain Entry ......................23
4.6.2. Ports of Fragments Addressed to
Shared-Address CEs .................................24
4.6.3. Packet Identifications from Shared-Address CEs .....26
4.7. TOS and Traffic Class Processing ..........................26
4.8. Tunnel-Generated ICMPv6 Error Messages ....................27
4.9. Provisioning 4rd Parameters to CEs ........................27
5. Security Considerations ........................................30
6. IANA Considerations ............................................31
7. Relationship with Previous Works ...............................31
8. References .....................................................33
8.1. Normative References ......................................33
8.2. Informative References ....................................34
Appendix A. Textual Representation of Mapping Rules ...............37
Appendix B. Configuring Multiple Mapping Rules ....................37
Appendix C. Adding Shared IPv4 Addresses to an IPv6 Network .......39
C.1. With CEs within CPEs .......................................39
C.2. With Some CEs behind Third-Party Router CPEs ..............41
Appendix D. Replacing Dual-Stack Routing with IPv6-Only Routing ...42
Appendix E. Adding IPv6 and 4rd Service to a Net-10 Network .......43
Acknowledgements ..................................................44
Authors' Addresses ................................................44
For service providers to progressively deploy IPv6-only network domains while still offering IPv4 service to customers, the need for a stateless solution, i.e., one where no per-customer state is needed in IPv4-IPv6 gateway nodes of the provider, has been discussed in [Solutions-4v6]. This document specifies one such solution, named "4rd" for IPv4 Residual Deployment. Its distinctive properties are that TCP/UDP IPv4 packets are valid TCP/UDP IPv6 packets during domain traversal and that IPv4 fragmentation rules are fully preserved end to end.
サービスプロバイダーがIPv6のみのネットワークドメインを段階的に展開しながら、顧客にIPv4サービスを提供するために、ステートレスソリューション、つまりプロバイダーのIPv4-IPv6ゲートウェイノードで顧客ごとの状態が必要ないソリューションの必要性が議論されました[Solutions-4v6]。このドキュメントでは、IPv4残余配備の「4rd」という名前のそのようなソリューションを1つ指定します。その特徴的な特性は、TCP / UDP IPv4パケットがドメイントラバーサル中に有効なTCP / UDP IPv6パケットであり、IPv4フラグメンテーションルールがエンドツーエンドで完全に保持されることです。
Using this solution, IPv4 packets are transparently tunneled across IPv6 networks (the reverse of IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) [RFC5969], in which IPv6 packets are statelessly tunneled across IPv4 networks).
このソリューションを使用すると、IPv4パケットはIPv6ネットワーク間で透過的にトンネリングされます（IPv6パケットがIPv4ネットワーク間でステートレスにトンネリングされる、IPv4インフラストラクチャ（6rd）でのIPv6迅速展開（RFC5969）の逆）。
While IPv6 headers are too long to be mapped into IPv4 headers (which is why 6rd requires encapsulation of full IPv6 packets in IPv4 packets), IPv4 headers can be reversibly translated into IPv6 headers in such a way that, during IPv6 domain traversal, UDP packets having checksums and TCP packets are valid IPv6 packets. IPv6-only middleboxes that perform deep packet inspection can operate on them, in particular for port inspection and web caches.
IPv6ヘッダーは長すぎてIPv4ヘッダーにマップできません（そのため、6rdではIPv4パケット内の完全なIPv6パケットのカプセル化が必要です）、IPv4ヘッダーは、IPv6ドメイントラバーサル中にUDPパケットが可逆的に変換されるようにIPv6ヘッダーに変換できますチェックサムとTCPパケットを持つことは、有効なIPv6パケットです。ディープパケットインスペクションを実行するIPv6のみのミドルボックスは、特にポートインスペクションとWebキャッシュに対して、それらに対して動作できます。
In order to deal with the IPv4 address shortage, customers can be assigned shared public IPv4 addresses with statically assigned restricted port sets. As such, it is a particular application of the Address plus Port (A+P) approach [RFC6346].
IPv4アドレスの不足に対処するために、静的に割り当てられた制限付きポートセットを使用して、共有パブリックIPv4アドレスを割り当てることができます。そのため、これはアドレスとポート（A + P）アプローチ[RFC6346]の特定のアプリケーションです。
Deploying 4rd in networks that have enough public IPv4 addresses, customer sites can also be assigned full public IPv4 addresses. 4rd also supports scenarios where a set of public IPv4 addresses are assigned to customer sites.
十分なパブリックIPv4アドレスを持つネットワークに4rdを展開すると、顧客サイトに完全なパブリックIPv4アドレスを割り当てることもできます。 4rdは、一連のパブリックIPv4アドレスが顧客サイトに割り当てられるシナリオもサポートします。
The design of 4rd builds on a number of previous proposals made for IPv4-via-IPv6 transition technologies (Section 7).
4rdの設計は、IPv4-via-IPv6移行テクノロジに対して作成された以前の多くの提案に基づいています（セクション7）。
In some use cases, IPv4-only applications of 4rd-capable customer nodes can also work with stateful NAT64s [RFC6146], provided these are upgraded to support 4rd tunnels in addition to their IP/ICMP translation [RFC6145]. The advantage is then a more complete IPv4 transparency than with double translation.
一部のユースケースでは、4番目の対応の顧客ノードのIPv4のみのアプリケーションは、IP / ICMP変換[RFC6145]に加えて4rdトンネルをサポートするようにアップグレードされている場合、ステートフルNAT64 [RFC6146]でも動作します。この場合の利点は、二重変換よりも完全なIPv4透過性です。
How the 4rd model fits in the Internet architecture is summarized in Section 3. The protocol specifications are detailed in Section 4. Sections 5 and 6 deal with security considerations and IANA considerations, respectively. Previous proposals that influenced this specification are listed in Section 7. A few typical 4rd use cases are presented in Appendices A, B, C, D, and E.
4番目のモデルがインターネットアーキテクチャにどのように適合するかは、セクション3にまとめられています。プロトコルの仕様はセクション4で詳しく説明されています。セクション5と6は、それぞれセキュリティの考慮事項とIANAの考慮事項を扱います。この仕様に影響を与えた以前の提案はセクション7にリストされています。いくつかの典型的な第4のユースケースが付録A、B、C、D、およびEに示されています。
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]で説明されているように解釈されます。
ISP: Internet Service Provider. In this document, the service it offers can be DSL, fiber-optics, cable, or mobile. The ISP can also be a private-network operator.
ISP：Internet Service Provider。このドキュメントでは、DSL、光ファイバー、ケーブル、モバイルなどのサービスを提供しています。 ISPは、プライベートネットワークオペレーターになることもできます。
4rd (IPv4 Residual Deployment): An extension of the IPv4 service where public IPv4 addresses can be statically shared among several customer sites, each one being assigned an exclusive port set. This service is supported across IPv6-routing domains.
4番目（IPv4残りの展開）：IPv4サービスの拡張で、パブリックIPv4アドレスを複数の顧客サイト間で静的に共有でき、それぞれに専用ポートセットが割り当てられます。このサービスは、IPv6ルーティングドメイン全体でサポートされています。
4rd domain (or Domain): An ISP-operated IPv6 network across which 4rd is supported according to the present specification.
第4ドメイン（またはドメイン）：ISPが運用するIPv6ネットワークで、現在の仕様に従って第4ドメインがサポートされています。
Tunnel packet: An IPv6 packet that transparently conveys an IPv4 packet across a 4rd domain. Its header has enough information to reconstitute the IPv4 header at Domain exit. Its payload is the original IPv4 payload.
トンネルパケット：第4ドメインを介してIPv4パケットを透過的に伝達するIPv6パケット。そのヘッダーには、ドメイン出口でIPv4ヘッダーを再構成するのに十分な情報があります。そのペイロードは元のIPv4ペイロードです。
CE (Customer Edge): A customer-side tunnel endpoint. It can be in a node that is a host, a router, or both.
CE（カスタマーエッジ）：カスタマー側のトンネルエンドポイント。これは、ホスト、ルーター、またはその両方であるノード内にあります。
BR (Border Relay): An ISP-side tunnel endpoint. Because its operation is stateless (neither per CE nor per session state), it can be replicated in as many nodes as needed for scalability.
BR（ボーダーリレー）：ISP側のトンネルエンドポイント。その動作はステートレス（CEごとでもセッション状態でもない）であるため、スケーラビリティに必要な数のノードに複製できます。
4rd IPv6 address: IPv6 address used as the destination of a Tunnel packet sent to a CE or a BR.
4番目のIPv6アドレス：CEまたはBRに送信されるトンネルパケットの宛先として使用されるIPv6アドレス。
NAT64+: An ISP NAT64 [RFC6146] that is upgraded to support 4rd tunneling when IPv6 addresses it deals with are 4rd IPv6 addresses.
NAT64 +：処理するIPv6アドレスが4番目のIPv6アドレスである場合に4番目のトンネリングをサポートするようにアップグレードされたISP NAT64 [RFC6146]。
4rd IPv4 address: A public IPv4 address or, in the case of a shared public IPv4 address, a public transport address (public IPv4 address plus port number).
4番目のIPv4アドレス：パブリックIPv4アドレス、または共有パブリックIPv4アドレスの場合はパブリックトランスポートアドレス（パブリックIPv4アドレスとポート番号）。
PSID (Port-Set Identifier): A flexible-length field that algorithmically identifies a port set.
PSID（Port-Set Identifier）：ポートセットをアルゴリズムで識別する可変長フィールド。
4rd IPv4 prefix: A flexible-length prefix that may be a public IPv4 prefix, a public IPv4 address, or a public IPv4 address followed by a PSID.
4番目のIPv4プレフィックス：パブリックIPv4プレフィックス、パブリックIPv4アドレス、またはPSIDが後に続くパブリックIPv4アドレスの場合がある、可変長のプレフィックス。
Mapping rule: A set of parameters that are used by BRs and CEs to derive 4rd IPv6 addresses from 4rd IPv4 addresses. Mapping rules are also used by each CE to derive a 4rd IPv4 prefix from an IPv6 prefix that has been delegated to it.
マッピングルール：BRとCEが4番目のIPv4アドレスから4番目のIPv6アドレスを導出するために使用する一連のパラメーター。マッピングルールは、委任されたIPv6プレフィックスから4番目のIPv4プレフィックスを取得するために各CEでも使用されます。
EA bits (Embedded Address bits): Bits that are the same in a 4rd IPv4 address and in the 4rd IPv6 address derived from it.
EAビット（Embedded Addressビット）：4番目のIPv4アドレスとそれから派生した4番目のIPv6アドレスで同じであるビット。
BR Mapping rule: The Mapping rule that is applicable to off-domain IPv4 addresses (addresses reachable via BRs). It can also apply to some or all CE-assigned IPv4 addresses.
BRマッピングルール：ドメイン外のIPv4アドレス（BR経由で到達可能なアドレス）に適用できるマッピングルール。また、CEが割り当てたIPv4アドレスの一部またはすべてに適用できます。
CE Mapping rule: A Mapping rule that is applicable only to CE-assigned IPv4 addresses (shared or not).
CEマッピングルール：CEが割り当てたIPv4アドレス（共有または非共有）にのみ適用されるマッピングルール。
NAT64+ Mapping rule: The Mapping rule that is applicable to IPv4 addresses reachable via a NAT64+.
NAT64 +マッピングルール：NAT64 +経由で到達可能なIPv4アドレスに適用できるマッピングルール。
CNP (Checksum Neutrality Preserver): A field of 4rd IPv6 addresses that ensures that TCP-like checksums do not change when IPv4 addresses are replaced with 4rd IPv6 addresses.
CNP（チェックサム中立性プリサーバー）：IPv4アドレスが4番目のIPv6アドレスに置き換えられたときに、TCPのようなチェックサムが変更されないようにする4番目のIPv6アドレスのフィールド。
4rd Tag: A 16-bit tag whose value allows 4rd CEs, BRs, and NAT64+s to distinguish 4rd IPv6 addresses from other IPv6 addresses.
4rdタグ：4ビットのCE、BR、およびNAT64 +が4番目のIPv6アドレスを他のIPv6アドレスと区別できるようにする16ビットのタグ。
4rd Domain
+-----------------------------+
| IPv6 routing |
| Enforced ingress filtering | +----------
... | | |
| +------+
Customer site | |BR(s) | IPv4
+------------+ | BR IPv6 prefix --> |and/or| Internet
| dual-stack | | |N4T64+|
| +--+ | +------+
| |CE+-+ <-- a CE IPv6 prefix | |
| +--+ | | +----------
| | | |
+------------+ | <--IPv4 tunnels--> +------------
=> Derived | (Mesh or hub-and-spoke |
4rd IPv4 prefix| topologies) | IPv6
| | Internet
... | |
| +------------
+-----------------------------+
<== one or several Mapping rules
(e.g., announced to CEs in stateless DHCPv6)
Figure 1: The 4rd Model in the Internet Architecture
図1：インターネットアーキテクチャの4番目のモデル
How the 4rd model fits in the Internet architecture is represented in Figure 1.
4番目のモデルがインターネットアーキテクチャにどのように適合するかを図1に示します。
A 4rd domain is an IPv6 network that includes one or several 4rd BRs or NAT64+s at its border with the public IPv4 Internet and that can advertise its IPv4-IPv6 Mapping rule(s) to CEs according to Section 4.9.
4番目のドメインは、パブリックIPv4インターネットとの境界に1つまたは複数の4番目のBRまたはNAT64 +を含み、セクション4.9に従ってIPv4 IPv6マッピングルールをCEにアドバタイズできるIPv6ネットワークです。
BRs of a 4rd Domain are all identical as far as 4rd is concerned. In a 4rd CE, the IPv4 packets that need to reach a BR will be transformed (as detailed in Section 4.3) into IPv6 packets that have the same anycast IPv6 prefix, which is the 80-bit BR prefix, in their destination addresses. They are then routed to any of the BRs. The 80-bit BR IPv6 prefix is an arbitrarily chosen /64 prefix from the IPv6 address space of the network operator and appended with 0x0300 (16-bit 4rd Tag; see R-9 in Section 4.5).
4rdドメインのBRは、4rdに関する限りすべて同じです。 4番目のCEでは、BRに到達する必要のあるIPv4パケットは、（セクション4.3で説明するように）宛先アドレスに同じエニーキャストIPv6プレフィックス（80ビットのBRプレフィックス）を持つIPv6パケットに変換されます。その後、それらはいずれかのBRにルーティングされます。 80ビットBR IPv6プレフィックスは、ネットワークオペレーターのIPv6アドレス空間から任意に選択された/ 64プレフィックスであり、0x0300（16ビットの4番目のタグ。セクション4.5のR-9を参照）が付加されます。
Using the Mapping rule that applies, each CE derives its 4rd IPv4 prefix from its delegated IPv6 prefix, or one of them if it has several; see Section 4.4 for details. If the obtained IPv4 prefix has more than 32 bits, the assigned IPv4 address is shared among several CEs. Bits beyond the first 32 specify a set of ports whose use is reserved for the CE.
適用されるマッピングルールを使用して、各CEは委任されたIPv6プレフィックスから4番目のIPv4プレフィックスを導出します。詳細については、4.4項を参照してください。取得したIPv4プレフィックスが32ビットを超える場合、割り当てられたIPv4アドレスは複数のCE間で共有されます。最初の32ビットを超えるビットは、CE用に予約されているポートのセットを指定します。
IPv4 traffic is automatically tunneled across the Domain, in either mesh topology or hub-and-spoke topology [RFC4925]. By default, IPv4 traffic between two CEs follows a direct IPv6 route between them (mesh topology). If the ISP configures the hub-and-spoke option, each IPv4 packet from one CE to another is routed via a BR.
IPv4トラフィックは、メッシュトポロジまたはハブアンドスポークトポロジ[RFC4925]のいずれかで、ドメイン全体で自動的にトンネリングされます。デフォルトでは、2つのCE間のIPv4トラフィックは、それらの間の直接IPv6ルートに従います（メッシュトポロジ）。 ISPがハブアンドスポークオプションを構成する場合、あるCEから別のCEへの各IPv4パケットはBRを介してルーティングされます。
During Domain traversal, each tunneled TCP/UDP IPv4 packet looks like a valid TCP/UDP IPv6 packet. Thus, TCP/UDP access control lists that apply to IPv6, and possibly some other functions using deep packet inspection, also apply to IPv4.
ドメイントラバーサル中、トンネリングされた各TCP / UDP IPv4パケットは、有効なTCP / UDP IPv6パケットのように見えます。したがって、IPv6に適用されるTCP / UDPアクセスコントロールリスト、およびディープパケットインスペクションを使用する他のいくつかの機能は、IPv4にも適用されます。
In order for IPv4 anti-spoofing protection in CEs and BRs to remain effective when combined with 4rd tunneling, ingress filtering [RFC3704] has to be in effect in IPv6 (see R-12 and Section 5).
CEとBRのIPv4アンチスプーフィング保護を第4トンネリングと組み合わせたときに有効なままにするには、イングレスフィルタリング[RFC3704]がIPv6で有効になっている必要があります（R-12およびセクション5を参照）。
If an ISP wishes to support dynamic IPv4 address sharing in addition to or in place of 4rd stateless address sharing, it can do so by means of a stateful NAT64. By upgrading this NAT to add support for 4rd tunnels, which makes it a NAT64+, CEs that are assigned no static IPv4 space can benefit from complete IPv4 transparency between the CE and the NAT64. (Without this NAT64 upgrade, IPv4 traffic is translated to IPv6 and back to IPv4, during which time the DF = MF = 1 combination for IPv4, as recommended for host fragmentation in Section 8 of [RFC4821], is lost.)
ISPが4番目のステートレスアドレス共有に加えて、またはその代わりに動的IPv4アドレス共有をサポートすることを望む場合、ステートフルNAT64を使用してそれを行うことができます。このNATをアップグレードして4番目のトンネルのサポートを追加し、NAT64 +にすることで、静的IPv4スペースが割り当てられていないCEは、CEとNAT64間の完全なIPv4透過性から恩恵を受けることができます。 （このNAT64アップグレードがない場合、IPv4トラフィックはIPv6に変換されてからIPv4に戻されます。その間、[RFC4821]のセクション8のホストフラグメンテーションで推奨されているように、IPv4のDF = MF = 1の組み合わせは失われます）。
IPv4 packets are kept unchanged by Domain traversal, except that:
IPv4パケットは、以下を除いて、ドメイントラバーサルによって変更されずに保持されます。
o The IPv4 Time To Live (TTL), unless it is 1 or 255 at Domain entry, decreases during Domain traversal by the number of traversed routers. This is acceptable because it is undetectable end to end and also because TTL values that can be used with some protocols to test the adjacency of communicating routers are preserved [RFC4271] [RFC5082]. The effect on the traceroute utility, which uses TTL expiry to discover routers of end-to-end paths, is noted in Section 4.3.
o IPv4 Time To Live（TTL）は、ドメインエントリで1または255でない限り、通過したルーターの数だけドメインの走査中に減少します。これはエンドツーエンドで検出できないため、また、一部のプロトコルで通信ルーターの隣接関係をテストするために使用できるTTL値が保持されるため、これは許容されます[RFC4271] [RFC5082]。 TTLの有効期限を使用してエンドツーエンドパスのルーターを検出するtracerouteユーティリティへの影響については、セクション4.3で説明しています。
o IPv4 packets whose lengths are <= 68 octets always have their "Don't Fragment" (DF) flags set to 1 at Domain exit even if they had DF = 0 at Domain entry. This is acceptable because these packets are too short to be fragmented [RFC791] and so their DF bits have no meaning. Besides, both [RFC1191] and [RFC4821] recommend that sources always set DF to 1.
o 長さが68オクテット以下のIPv4パケットは、ドメインエントリでDF = 0であったとしても、ドメイン出口で常に「Do n't Fragment」（DF）フラグが1に設定されています。これらのパケットはフラグメント化するには短すぎるため[RFC791]、DFビットは意味がないため、これは許容されます。さらに、[RFC1191]と[RFC4821]はどちらも、ソースが常にDFを1に設定することを推奨しています。
o Unless the Tunnel Traffic Class option applies to a Domain (Section 4.2), IPv4 packets may have their Type of Service (TOS) fields modified after Domain traversal (Section 4.7).
o トンネルトラフィッククラスオプションがドメイン（セクション4.2）に適用されない限り、IPv4パケットのドメイントラバーサル（セクション4.7）の後で、サービスタイプ（TOS）フィールドが変更されることがあります。
This section describes detailed 4rd protocol specifications. They are mainly organized by functions. As a brief summary:
このセクションでは、詳細な第4プロトコル仕様について説明します。それらは主に機能別に編成されています。簡単な要約として：
o A 4rd CE MUST follow R-1, R-2, R-3, R-4, R-6, R-7, R-8, R-9, R-10, R-11, R-12, R-13, R-14, R-16, R-17, R-18, R-19, R-20, R-21, R-22, R-23, R-24, R-25, R-26, and R-27.
o 4番目のCEは、R-1、R-2、R-3、R-4、R-6、R-7、R-8、R-9、R-10、R-11、R-12、Rに続く必要があります。 -13、R-14、R-16、R-17、R-18、R-19、R-20、R-21、R-22、R-23、R-24、R-25、R-26 、R-27。
o A 4rd BR MUST follow R-2, R-3, R-4, R-5, R-6, R-9, R-12, R-13, R-14, R-15, R-19, R-20, R-21, R-22, and R-24.
o 4番目のBRは、R-2、R-3、R-4、R-5、R-6、R-9、R-12、R-13、R-14、R-15、R-19、Rに続く必要があります。 -20、R-21、R-22、およびR-24。
R-1: A CE node that is assigned a shared public IPv4 address MUST include a NAT44 [RFC3022]. This NAT44 MUST only use external ports that are in the CE-assigned port set.
R-1：共有パブリックIPv4アドレスが割り当てられたCEノードには、NAT44 [RFC3022]を含める必要があります。このNAT44は、CEが割り当てたポートセットにある外部ポートのみを使用する必要があります。
NOTE: This specification only concerns IPv4 communication between IPv4-capable endpoints. For communication between IPv4-only endpoints and IPv6-only remote endpoints, the "Bump-in-the-Host" (BIH) specification [RFC6535] can be used. It can coexist in a node with the CE function, including scenarios where the IPv4-only function is a NAT44 [RFC3022].
注：この仕様は、IPv4対応エンドポイント間のIPv4通信のみに関係します。 IPv4のみのエンドポイントとIPv6のみのリモートエンドポイント間の通信では、「Bump-in-the-Host」（BIH）仕様[RFC6535]を使用できます。 IPv4のみの機能がNAT44 [RFC3022]であるシナリオを含め、CE機能を持つノードで共存できます。
R-2: CEs and BRs MUST be configured with the following Domain parameters:
R-2：CEとBRは、次のドメインパラメータで構成する必要があります。
A. One or several Mapping rules, each one comprising the following:
A. 1つまたは複数のマッピングルール。各ルールには次のものが含まれます。
1. Rule IPv4 prefix
1. ルールIPv4プレフィックス
2. EA-bits length
2. EAビット長
3. Rule IPv6 prefix
3. ルールIPv6プレフィックス
4. Well-Known Ports (WKPs) authorized (OPTIONAL)
4. 既知のポート（WKP）が承認されました（オプション）
B. Domain Path MTU (PMTU)
B.ドメインパスMTU（PMTU）
C. Hub-and-spoke topology (Yes or No)
C.ハブアンドスポークトポロジ（はいまたはいいえ）
D. Tunnel Traffic Class (OPTIONAL)
D.トンネルトラフィッククラス（オプション）
"Rule IPv4 prefix" is used to find, by a longest match, which Mapping rule applies to a 4rd IPv4 address (Section 4.5). A Mapping rule whose Rule IPv4 prefix is longer than /0 is a CE Mapping rule. BR and NAT64+ Mapping rules, which must apply to all off-domain IPv4 addresses, have /0 as their Rule IPv4 prefixes.
「ルールIPv4プレフィックス」は、最長一致によって、マッピングルールが4番目のIPv4アドレスに適用されることを見つけるために使用されます（セクション4.5）。 Rule IPv4プレフィックスが/ 0より長いマッピングルールは、CEマッピングルールです。 BRおよびNAT64 +マッピングルールは、ドメイン外のすべてのIPv4アドレスに適用する必要があり、ルールIPv4プレフィックスとして/ 0を持っています。
"EA-bits length" is the number of bits that are common to 4rd IPv4 addresses and 4rd IPv6 addresses derived from them. In a CE Mapping rule, it is also the number of bits that are common to a CE-delegated IPv6 prefix and the 4rd IPv4 prefix derived from it. BR and NAT64+ Mapping rules have EA-bits lengths equal to 32.
「EAビット長」は、4番目のIPv4アドレスとそれらから派生した4番目のIPv6アドレスに共通のビット数です。 CEマッピングルールでは、CE委任されたIPv6プレフィックスとそこから派生した4番目のIPv4プレフィックスに共通のビット数でもあります。 BRおよびNAT64 +マッピングルールのEAビット長は32です。
"Rule IPv6 prefix" is the prefix that is used as a substitute for the Rule IPv4 prefix when a 4rd IPv6 address is derived from a 4rd IPv4 address (Section 4.5). In a BR Mapping rule or a NAT64+ Mapping rule, it MUST be a /80 prefix whose bits 64-79 are the 4rd Tag.
「ルールIPv6プレフィックス」は、4番目のIPv6アドレスが4番目のIPv4アドレスから派生したときに、ルールIPv4プレフィックスの代わりに使用されるプレフィックスです（セクション4.5）。 BRマッピングルールまたはNAT64 +マッピングルールでは、ビット64〜79が4番目のタグである/ 80プレフィックスである必要があります。
"WKPs authorized" may be set for Mapping rules that assign shared IPv4 addresses to CEs. (These rules are those whose length of the Rule IPv4 prefix plus the EA-bits length exceeds 32.) If set, well-known ports may be assigned to some CEs having particular IPv6 prefixes. If not set, fairness is privileged: all IPv6 prefixes concerned with the Mapping rule have port sets having identical values (no port set includes any of the well-known ports).
共有IPv4アドレスをCEに割り当てるマッピングルールに「許可されたWKP」を設定できます。 （これらのルールは、ルールIPv4プレフィックスとEAビットの長さの合計が32を超えるものです。）設定すると、特定のIPv6プレフィックスを持つ一部のCEに既知のポートが割り当てられる場合があります。設定されていない場合、公平性が優先されます。マッピングルールに関連するすべてのIPv6プレフィックスには、同じ値を持つポートセットがあります（どのポートセットにも既知のポートは含まれません）。
"Domain PMTU" is the IPv6 Path MTU that the ISP can guarantee for all of its IPv6 paths between CEs and between BRs and CEs. It MUST be at least 1280 octets [RFC2460].
「ドメインPMTU」は、ISPがCE間およびBRとCE間のすべてのIPv6パスに対して保証できるIPv6パスMTUです。少なくとも1280オクテットである必要があります[RFC2460]。
"Hub-and-spoke topology", if set to Yes, requires CEs to tunnel all IPv4 packets via BRs. If set to No, CE-to-CE packets take the same routes as native IPv6 packets between the same CEs (mesh topology).
「ハブアンドスポークトポロジ」を「はい」に設定した場合、CEはBR経由ですべてのIPv4パケットをトンネリングする必要があります。 [いいえ]に設定すると、CE-to-CEパケットは、同じCE（メッシュトポロジ）間のネイティブIPv6パケットと同じルートを使用します。
"Tunnel Traffic Class", if provided, is the IPv6 traffic class that BRs and CEs MUST set in Tunnel packets. In this case, evolutions of the IPv6 traffic class that may occur during Domain traversal are not reflected in TOS fields of IPv4 packets at Domain exit (Section 4.7).
「トンネルトラフィッククラス」は、提供される場合、BRおよびCEがトンネルパケットに設定する必要があるIPv6トラフィッククラスです。この場合、ドメイントラバーサル中に発生する可能性のあるIPv6トラフィッククラスの進化は、ドメイン出口のIPv4パケットのTOSフィールドには反映されません（セクション4.7）。
R-3: Domain-entry nodes that receive IPv4 packets with IPv4 options MUST discard these packets and return ICMPv4 error messages to signal IPv4-option incompatibility (Type = 12, Code = 0, Pointer = 20) [RFC792]. This limitation is acceptable because there are a lot of firewalls in the current IPv4 Internet that also filter IPv4 packets with IPv4 options.
R-3：IPv4オプション付きのIPv4パケットを受信するドメインエントリノードは、これらのパケットを破棄し、ICMPv4エラーメッセージを返してIPv4オプションの非互換性を通知する必要があります（タイプ= 12、コード= 0、ポインター= 20）[RFC792]。現在のIPv4インターネットには、IPv4オプションでIPv4パケットをフィルタリングするファイアウォールが多数あるため、この制限は受け入れられます。
R-4: Domain-entry nodes that receive IPv4 packets without IPv4 options MUST convert them to Tunnel packets, with or without IPv6 fragment headers, depending on what is needed to ensure IPv4 transparency (Figure 2). Domain-exit nodes MUST convert them back to IPv4 packets.
R-4：IPv4オプションなしでIPv4パケットを受信するドメインエントリノードは、IPv4透過性を確保するために必要なものに応じて、IPv6フラグメントヘッダーの有無にかかわらず、それらをトンネルパケットに変換する必要があります（図2）。ドメイン出口ノードは、IPv4パケットに戻す必要があります。
An IPv6 fragmentation header MUST be included at tunnel entry (Figure 2) if and only if one or several of the following conditions hold:
IPv6フラグメンテーションヘッダーは、次の条件の1つまたは複数が該当する場合に限り、トンネルエントリ（図2）に含める必要があります。
* The Tunnel Traffic Class option applies to the Domain.
* トンネルトラフィッククラスオプションはドメインに適用されます。
* TTL = 1 OR TTL = 255.
* TTL = 1またはTTL = 255。
* The IPv4 packet is already fragmented, or may be fragmented later on, i.e., if MF = 1 OR offset > 0 OR (total length > 68 AND DF = 0).
* IPv4パケットはすでにフラグメント化されているか、後でフラグメント化される可能性があります。つまり、MF = 1 ORオフセット> 0 OR（全長> 68 AND DF = 0）の場合です。
In order to optimize cases where fragmentation headers are unnecessary, the NAT44 of a CE that has one SHOULD send packets with TTL = 254.
フラグメンテーションヘッダーが不要な場合を最適化するために、1つのCEのNAT44は、TTL = 254のパケットを送信する必要があります。
R-5: In Domains whose chosen topology is hub-and-spoke, BRs that receive 4rd IPv6 packets whose embedded destination IPv4 addresses match a CE Mapping rule MUST do the equivalent of reversibly translating their headers to IPv4 and then reversibly translate them back to IPv6 as though packets would be entering the Domain.
R-5：選択されたトポロジがハブアンドスポークであるドメインでは、埋め込み宛先IPv4アドレスがCEマッピングルールに一致する4番目のIPv6パケットを受信するBRは、ヘッダーをIPv4に可逆的に変換し、次にそれらをパケットがドメインに入るかのようにIPv6。
(A) Without IPv6 fragment header
IPv4 packet Tunnel packet
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : | IPv6 Header | 40
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
(B) With IPv6 fragment header
Tunnel packet
: +--------------------+
IPv4 packet : | IPv6 Header | 40
+--------------------+ : : +--------------------+
20| IPv4 Header | : <==> : |IPv6 Fragment Header| 8
+--------------------+ : : +--------------------+
| IP Payload | <==> | IP Payload |
| | Layer 4 | |
+--------------------+ unchanged +--------------------+
Figure 2: Reversible Packet Translation
図2：可逆パケット変換
R-6: Values to be set in IPv6 header fields at Domain entry are detailed in Table 1 (no fragment header) and Table 2 (with fragment header). Those to be set in IPv4 header fields at Domain exit are detailed in Table 3 (no fragment header) and Table 4 (with fragment header).
R-6：ドメインエントリのIPv6ヘッダーフィールドに設定する値の詳細については、表1（フラグメントヘッダーなし）および表2（フラグメントヘッダーあり）を参照してください。ドメイン出口でIPv4ヘッダーフィールドに設定されるものについては、表3（フラグメントヘッダーなし）および表4（フラグメントヘッダーあり）で詳しく説明しています。
To convey IPv4 header information that has no equivalent in IPv6, some ad hoc fields are placed in IPv6 flow labels and in Identification fields of IPv6 fragment headers, as detailed in Figure 3.
図3に示すように、IPv6に対応するものがないIPv4ヘッダー情報を伝えるために、一部のアドホックフィールドがIPv6フローラベルとIPv6フラグメントヘッダーの識別フィールドに配置されます。
|0 |4 19|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Addr_Prot_Cksm |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
IPv6 Flow Label
0 1 2 |8 |16 31|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|.|.|.| 0 | IPv4_TOS | IPv4_ID |
/-+-\-\-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ \ TTL_255 IPv6 Identification Field
IPv4_DF TTL_1 (in fragment header if needed)
Figure 3: 4rd Identification Fields of IPv6 Fragment Headers
図3：IPv6フラグメントヘッダーの4番目の識別フィールド
+---------------------+----------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+---------------------+----------------------------------------+
| Version | 6 |
| Traffic Class | TOS |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 20 |
| Next header | Protocol |
| Hop limit | Time to Live |
| Source address | See Section 4.5 |
| Destination address | See Section 4.5 |
+---------------------+----------------------------------------+
Table 1: IPv4-to-IPv6 Reversible Header Translation (without Fragment Header)
表1：IPv4からIPv6へのリバーシブルヘッダー変換（フラグメントヘッダーなし）
+-----------------+----------------------------------------------+
| IPv6 Field | Value (fields from IPv4 header) |
+-----------------+----------------------------------------------+
| Version | 6 |
| Traffic Class | TOS OR Tunnel Traffic Class (Section 4.7) |
| Addr_Prot_Cksm | Sum of addresses and Protocol (Note 1) |
| Payload length | Total length - 12 |
| Next header | 44 (fragment header) |
| Hop limit | IF Time to Live = 1 or 255 THEN 254 |
| | ELSE Time to Live (Note 2) |
| Source address | See Section 4.5 |
| Dest. address | See Section 4.5 |
| 2nd next header | Protocol |
| Fragment offset | IPv4 fragment offset |
| M | More Fragments flag (MF) |
| IPv4_DF | Don't Fragment flag (DF) |
| TTL_1 | IF Time to Live = 1 THEN 1 ELSE 0 (Note 2) |
| TTL_255 | IF Time to Live = 255 THEN 1 ELSE 0 (Note 2) |
| IPv4_TOS | Type of Service (TOS) |
| IPv4_ID | Identification |
+-----------------+----------------------------------------------+
Table 2: IPv4-to-IPv6 Reversible Header Translation (with Fragment Header)
表2：IPv4からIPv6へのリバーシブルヘッダー変換（フラグメントヘッダーを使用）
+-----------------+------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------+------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class |
| Total length | Payload length + 20 |
| Identification | 0 |
| DF | 1 |
| MF | 0 |
| Fragment offset | 0 |
| Time to Live | Hop count |
| Protocol | Next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Dest. address | Bits 80-111 of destination address |
+-----------------+------------------------------------+
Table 3: IPv6-to-IPv4 Reversible Header Translation (without Fragment Header)
表3：IPv6-to-IPv4リバーシブルヘッダー変換（フラグメントヘッダーなし）
+-----------------------+-----------------------------------------+
| IPv4 Field | Value (fields from IPv6 header) |
+-----------------------+-----------------------------------------+
| Version | 4 |
| Header length | 5 |
| TOS | Traffic Class OR IPv4_TOS (Section 4.7) |
| Total length | Payload length + 12 |
| Identification | IPv4_ID |
| DF | IPv4_DF |
| MF | M |
| Fragment offset | Fragment offset |
| Time to Live (Note 2) | IF TTL_255 = 1 THEN 255 |
| | ELSEIF TTL_1 = 1 THEN 1 |
| | ELSE hop count |
| Protocol | 2nd next header |
| Header checksum | Computed as per [RFC791] (Note 3) |
| Source address | Bits 80-111 of source address |
| Destination address | Bits 80-111 of destination address |
+-----------------------+-----------------------------------------+
Table 4: IPv6-to-IPv4 Reversible Header Translation (with Fragment Header)
表4：IPv6-to-IPv4リバーシブルヘッダー変換（フラグメントヘッダー付き）
NOTE 1: The need to save in the IPv6 header a checksum of both IPv4 addresses and the IPv4 protocol field results from the following facts: (1) header checksums, present in IPv4 but not in IPv6, protect addresses or protocol integrity; (2) in IPv4, ICMP messages and null-checksum UDP datagrams depend on this protection because, unlike other datagrams, they have no other address-and-protocol integrity protection. The sum MUST be performed in ordinary two's complement arithmetic.
注1：IPv6ヘッダーにIPv4アドレスとIPv4プロトコルフィールドの両方のチェックサムを保存する必要性は、次の事実から生じます。（1）ヘッダーチェックサムはIPv4には存在するがIPv6には存在せず、アドレスまたはプロトコルの整合性を保護します。 （2）IPv4では、ICMPメッセージとnull-checksum UDPデータグラムは他のデータグラムとは異なり、他のアドレスとプロトコルの整合性保護がないため、この保護に依存しています。合計は、通常の2の補数演算で実行する必要があります。
IP-layer Packet length is another field covered by the IPv4 header checksum. It is not included in the saved checksum because (1) doing so would have conflicted with [RFC6437] (flow labels must be the same in all packets of each flow); (2) ICMPv4 messages have good enough protection with their own checksums; (3) the UDP length field provides to null-checksum UDP datagrams the same level of protection after Domain traversal as without Domain traversal (consistency between IP-layer and UDP-layer lengths can be checked).
IP層のパケット長は、IPv4ヘッダーチェックサムの対象となるもう1つのフィールドです。 （1）実行すると[RFC6437]と競合するため、保存されたチェックサムには含まれません（フローラベルは各フローのすべてのパケットで同じでなければなりません）。 （2）ICMPv4メッセージは、独自のチェックサムで十分に保護されています。 （3）UDP長さフィールドは、ドメイントラバーサルなしの場合と同じレベルの保護をnullチェックサムUDPデータグラムに提供します（IP層とUDP層の長さの一貫性をチェックできます）。
NOTE 2: TTL treatment has been chosen to permit adjacency tests between two IPv4 nodes situated at both ends of a 4rd tunnel. TTL values to be preserved for this are TTL = 255 and TTL = 1. For other values, TTL decreases between two IPv4 nodes as though the traversed IPv6 routers were IPv4 routers.
注2：TTL処理は、4番目のトンネルの両端にある2つのIPv4ノード間の隣接テストを許可するために選択されています。このために保持されるTTL値は、TTL = 255およびTTL = 1です。他の値の場合、通過したIPv6ルーターがIPv4ルーターであるかのように、TTLは2つのIPv4ノード間で減少します。
The effect of this TTL treatment on IPv4 traceroute is specific: (1) the number of routers of the end-to-end path includes traversed IPv6 routers; (2) IPv6 routers of a Domain are listed after IPv4 routers of Domain entry and exit; (3) the IPv4 address shown for an IPv6 router is the IPv6-only dummy IPv4 address (Section 4.8); (4) the response time indicated for an IPv6 router is that of the next router.
このTTL処理によるIPv4 tracerouteへの影響は固有です。（1）エンドツーエンドパスのルーターの数には、通過するIPv6ルーターが含まれます。 （2）ドメインのIPv6ルーターは、ドメインのIPv4ルーターの出入り後にリストされます。 （3）IPv6ルーターに表示されるIPv4アドレスは、IPv6のみのダミーIPv4アドレスです（セクション4.8）。 （4）IPv6ルーターに示されている応答時間は、次のルーターの応答時間です。
NOTE 3: Provided the sum of obtained IPv4 addresses and protocol matches Addr_Prot_Cksm. If not, the packet MUST be silently discarded.
注3：取得したIPv4アドレスとプロトコル一致の合計がAddr_Prot_Cksmに提供されました。そうでなければ、パケットは静かに捨てられなければなりません。
+--------------------------------------+
| CE IPv6 prefix |
+--------------------------+-----------+
: Longest match : :
: with a Rule IPv6 prefix : :
: || : EA-bits :
: \/ : length :
+--------------------------+ | :
| Rule IPv6 prefix |<----'---->:
+--------------------------+ :
|| : :
\/ : :
+-----------------+-----------+
|Rule IPv4 prefix | EA bits |
+-----------------+-----------+
: :
+-----------------------------+
| CE 4rd IPv4 prefix |
+-----------------------------+
________/ \_________ :
/ \ :
: ____:________________/ \__
: / : \
: <= 32 : : > 32 :
+----------------+ +-----------------+----+
|IPv4 prfx or add| OR | IPv4 address |PSID|
+----------------+ +-----------------+----+
: 32 : || :
\/
(by default) (If WKPs authorized)
: : : :
+---+----+---------+ +----+-------------+
Ports in |> 0|PSID|any value| OR |PSID| any value |
the CE port set +---+----+---------+ +----+-------------+
: 4 : 12 : : 16 :
Figure 4: From CE IPv6 Prefix to 4rd IPv4 Address and Port Set
図4：CE IPv6プレフィックスから4番目のIPv4アドレスおよびポートセットへ
R-7: A CE whose delegated IPv6 prefix matches the Rule IPv6 prefix of one or several Mapping rules MUST select the CE Mapping rule for which the match is the longest. It then derives its 4rd IPv4 prefix as shown in Figure 4: (1) The CE replaces the Rule IPv6 prefix with the Rule IPv4 prefix. The result is the CE 4rd IPv4 prefix. (2) If this CE 4rd IPv4 prefix has less than 32 bits, the CE takes it as its assigned IPv4 prefix. If it has exactly 32 bits, the CE takes it as its IPv4 address. If it has more than 32 bits, the CE MUST take the first 32 bits as its shared public IPv4 address and bits beyond the first 32 as its Port-Set identifier (PSID). Ports of its restricted port set are by default those that have any non-zero value in their first 4 bits (the PSID offset), followed by the PSID, and followed by any values in remaining bits. If the WKP authorized option applies to the Mapping rule, there is no 4-bit offset before the PSID so that all ports can be assigned.
R-7：委任されたIPv6プレフィックスが1つまたは複数のマッピングルールのルールIPv6プレフィックスと一致するCEは、一致が最も長いCEマッピングルールを選択する必要があります。次に、図4に示すように、4番目のIPv4プレフィックスを導出します。（1）CEは、ルールIPv6プレフィックスをルールIPv4プレフィックスに置き換えます。結果はCE 4rd IPv4プレフィックスです。 （2）このCE 4rd IPv4プレフィックスが32ビット未満の場合、CEはそれを割り当てられたIPv4プレフィックスとして使用します。正確に32ビットである場合、CEはそれをIPv4アドレスとして使用します。 32ビットを超える場合、CEは最初の32ビットを共有パブリックIPv4アドレスとして、最初の32ビットを超えるビットをポートセット識別子（PSID）として使用する必要があります。制限付きポートセットのポートは、デフォルトでは、最初の4ビット（PSIDオフセット）にゼロ以外の値があり、その後にPSIDが続き、残りのビットに値があります。 WKP承認オプションがマッピングルールに適用される場合、すべてのポートを割り当てることができるように、PSIDの前に4ビットのオフセットはありません。
NOTE: The choice of the default PSID position in port fields has been guided by the following objectives: (1) for fairness, avoid having any of the well-known ports 0-1023 in the port set specified by any PSID value; (2) for compatibility with RTP/ RTCP [RFC4961], include in each port set pairs of consecutive ports; (3) in order to facilitate operation and training, have the PSID at a fixed position in port fields; (4) in order to facilitate documentation in hexadecimal notation, and to facilitate maintenance, have this position nibble-aligned. Ports that are excluded from assignment to CEs are 0-4095, instead of just 0-1023, in a trade-off to favor nibble alignment of PSIDs and overall simplicity.
注：ポートフィールドでのデフォルトのPSID位置の選択は、次の目的に基づいて行われました。（1）公平性のため、PSID値で指定されたポートセットに既知のポート0〜1023を含めないでください。 （2）RTP / RTCP [RFC4961]との互換性のために、連続するポートの各ポートセットのペアに含めます。 （3）操作とトレーニングを容易にするために、PSIDをポートフィールドの固定位置に配置します。 （4）16進表記での文書化を容易にし、保守を容易にするために、この位置をニブルに揃えます。 CEへの割り当てから除外されるポートは、PSIDのニブルアライメントと全体的な単純さを優先するトレードオフで、0-1023ではなく0-4095です。
R-8: A CE whose delegated IPv6 prefix has its longest match with the Rule IPv6 prefix of the BR Mapping rule MUST take as its IPv4 address the 32 bits that, in the delegated IPv6 prefix, follow this Rule IPv6 prefix. If this is the case while the hub-and-spoke option applies to the Domain, or if the Rule IPv6 prefix is not a /80, there is a configuration error in the Domain. An implementation-dependent administrative action MAY be taken.
R-8：委任されたIPv6プレフィックスがBRマッピングルールのルールIPv6プレフィックスと最長一致するCEは、そのIPv4アドレスとして、委任されたIPv6プレフィックスでこのルールIPv6プレフィックスに従う32ビットを使用する必要があります。ハブアンドスポークオプションがドメインに適用されている場合、またはルールIPv6プレフィックスが/ 80でない場合は、ドメインに設定エラーがあります。実装に依存する管理アクションがとられる場合があります。
A CE whose delegated IPv6 prefix does not match the Rule IPv6 prefix of either any CE Mapping rule or the BR Mapping rule, and is in a Domain that has a NAT64+ Mapping rule, MUST be noted as having the unspecified IPv4 address.
委任されたIPv6プレフィックスがCEマッピングルールまたはBRマッピングルールのいずれかのルールIPv6プレフィックスと一致せず、NAT64 +マッピングルールを持つドメインに属しているCEは、未指定のIPv4アドレスを持っていることに注意する必要があります。
: 32 : : 16 : \
+----------------------------+ +---------------+ |
| IPv4 address | |Port_or_ICMP_ID| | Shared-address
+----------------------------+ +---+------+----+ | case
: Longest match : : 4 : PSID : | (PSID length
: with a Rule IPv4 prefix : :length: | of the rule > 0)
: || : : : | with WKPs
: \/ : : : | not authorized
+----------------+-----------+ +------+ | (PSID offset = 4)
|Rule IPv4 prefix|IPv4 suffix| | PSID | |
+----------------+-----------+ +------+ |
: || \_______ \____ | | |
: \/ \ \| / |
+--------------------------+--------+-----+ /
| Rule IPv6 prefix | EA bits |
+--------------------------+--------------+
: :
+-----------------------------------------+
| IPv6 prefix |
+-----------------------------------------+
:\_______________________________ / \
: ___________________\______/ \_______________
: / \ \
: / (CE Mapping rule) \ (BR Mapping rule) \
: <= 64 : : 112 :
+----------+---+---+------+---+ +--------------+---+------+---+
|CE v6 prfx| 0 |tag|v4 add|CNP| |BR IPv6 prefix|tag|v4 add|CNP|
+----------+-|-+---+------+---+ +--------------+---+------+---+
: <= 64 : | :16 : 32 :16 : : 64 :16 : 32 :16 :
|
Padding to /64
Figure 5: From 4rd IPv4 Address to 4rd IPv6 Address
図5：4番目のIPv4アドレスから4番目のIPv6アドレスへ
R-9: BRs, and CEs that are assigned public IPv4 addresses, shared or not, MUST derive 4rd IPv6 addresses from 4rd IPv4 addresses via the steps below or their functional equivalent (Figure 5 details the shared public IPv4 address case):
R-9：パブリックIPv4アドレスが割り当てられているかどうかにかかわらず、BRおよびCEは、以下の手順または同等の機能を介して、4番目のIPv4アドレスから4番目のIPv6アドレスを導出する必要があります（図5は、共有パブリックIPv4アドレスの場合の詳細です）。
NOTE: The rules for forming 4rd-specific Interface Identifiers (IIDs) are to obey [RFC7136]:
注：第4固有のインターフェース識別子（IID）を形成するためのルールは、[RFC7136]に従います。
"Specifications of other forms of 64-bit IIDs MUST specify how all 64 bits are set."
「他の形式の64ビットIIDの仕様では、すべての64ビットの設定方法を指定する必要があります。」
and
そして
"the whole IID value MUST be viewed as an opaque bit string by third parties, except possibly in the local context."
「すべてのIID値は、おそらくローカルコンテキストを除いて、サードパーティによって不透明なビット文字列と見なされなければなりません。」
(1) If hub-and-spoke topology does not apply to the Domain, or if it applies but the IPv6 address to be derived is a source address from a CE or a destination address from a BR, find the CE Mapping rule whose Rule IPv4 prefix has the longest match with the IPv4 address.
（1）ハブアンドスポークトポロジがドメインに適用されない場合、または適用されても、派生するIPv6アドレスがCEからの送信元アドレスまたはBRからの宛先アドレスである場合は、そのルールを持つCEマッピングルールを見つけます。 IPv4プレフィックスは、IPv4アドレスと最も長く一致します。
If no Mapping rule is thus obtained, take the BR Mapping rule.
このようにしてマッピングルールが取得されない場合は、BRマッピングルールを使用します。
If the obtained Mapping rule assigns IPv4 prefixes to CEs, i.e., if the length of the Rule IPv4 prefix plus EA-bits length is 32 - k, with k >= 0, delete the last k bits of the IPv4 address.
取得したマッピングルールがIPv4プレフィックスをCEに割り当てる場合、つまり、ルールIPv4プレフィックスとEAビットの長さの合計が32-kで、k> = 0の場合、IPv4アドレスの最後のkビットを削除します。
Otherwise, if the length of the Rule IPv4 prefix plus the EA-bits length is 32 + k, with k > 0, take k as the PSID length and append to the IPv4 address the PSID copied from bits p to p+3 of the Port_or_ICMP_ID field where (1) p, the PSID offset, is 4 by default and 0 if the WKPs authorized option applies to the rule; (2) the Port_or_ICMP_ID field is in bits of the IP payload that depend on whether the address is source or destination, on whether the packet is ICMP or not, and, if it is ICMP, whether it is an error message or an Echo message. This field is:
それ以外の場合、ルールIPv4プレフィックスとEAビットの長さの合計が32 + kで、k> 0の場合、PSIDの長さとしてkを取り、IPv4アドレスに、ビットpからp + 3にコピーされたPSID Port_or_ICMP_IDフィールド。ここで、（1）p、PSIDオフセットは、デフォルトで4であり、WKPs許可オプションがルールに適用される場合は0です。 （2）Port_or_ICMP_IDフィールドはIPペイロードのビット内にあり、アドレスが送信元か宛先か、パケットがICMPかどうか、ICMPの場合はエラーメッセージかエコーメッセージかによって異なります。 。このフィールドは次のとおりです。
a. If the packet Protocol is not ICMP, the port field associated with the address (bits 0-15 for a source address and bits 16-31 for a destination address).
a. パケットプロトコルがICMPでない場合、アドレスに関連付けられたポートフィールド（送信元アドレスのビット0〜15および宛先アドレスのビット16〜31）。
b. If the packet is an ICMPv4 Echo or Echo reply message, the ICMPv4 Identification field (bits 32-47).
b. パケットがICMPv4エコーまたはエコー応答メッセージの場合、ICMPv4識別フィールド（ビット32-47）。
c. If the packet is an ICMPv4 error message, the port field associated with the address in the returned packet header (bits 240-255 for a source address and bits 224-239 for a destination address).
c. パケットがICMPv4エラーメッセージの場合、返されるパケットヘッダーのアドレスに関連付けられたポートフィールド（送信元アドレスのビット240〜255および宛先アドレスのビット224〜239）。
NOTE 1: Using Identification fields of ICMP messages as port fields permits the exchange of Echo requests and Echo replies between shared-address CEs and IPv4 hosts having exclusive IPv4 addresses. Echo exchanges between two shared-address CEs remain impossible, but this is a limitation inherent in address sharing (one reason among many to use IPv6).
注1：ICMPメッセージの識別フィールドをポートフィールドとして使用すると、共有アドレスCEと専用IPv4アドレスを持つIPv4ホスト間でのエコー要求とエコー応答の交換が可能になります。 2つの共有アドレスCE間のエコー交換は依然として不可能ですが、これはアドレス共有に固有の制限です（IPv6を使用する多くの理由の1つ）。
NOTE 2: When the PSID is taken in the port fields of the IPv4 payload, implementation is kept independent from any particular Layer 4 protocol having such port fields by not checking that the protocol is indeed one that has such port fields. A packet may consequently go, in the case of a source mistake, from a BR to a shared-address CE with a protocol that is not supported by this CE. In this case, the CE NAT44 returns an ICMPv4 "protocol unreachable" error message. The IPv4 source is thus appropriately informed of its mistake.
注2：PSIDがIPv4ペイロードのポートフィールドで取得される場合、プロトコルが実際にそのようなポートフィールドを持つものであるかどうかをチェックしないことにより、そのようなポートフィールドを持つ特定のレイヤー4プロトコルから独立して実装が維持されます。その結果、ソースミスの場合、パケットは、BRからこのCEでサポートされていないプロトコルを使用する共有アドレスCEに送信される可能性があります。この場合、CE NAT44はICMPv4 "プロトコル到達不能"エラーメッセージを返します。したがって、IPv4ソースには、その誤りが適切に通知されます。
(2) In the result, replace the Rule IPv4 prefix with the Rule IPv6 prefix.
（2）結果で、ルールIPv4プレフィックスをルールIPv6プレフィックスに置き換えます。
(3) If the result is shorter than a /64, append to the result a null padding up to 64 bits, followed by the 4rd Tag (0x0300), and followed by the IPv4 address.
（3）結果が/ 64より短い場合は、結果に64ビットまでのヌルパディングを追加し、その後に4番目のタグ（0x0300）、IPv4アドレスを追加します。
NOTE: The 4rd Tag is a 4rd-specific mark. Its function is to ensure that 4rd IPv6 addresses are recognizable by CEs without any interference with the choice of subnet prefixes in CE sites. (These choices may have been done before 4rd is enabled.)
注：4番目のタグは4番目に固有のマークです。その機能は、CEサイトでのサブネットプレフィックスの選択に干渉することなく、4番目のIPv6アドレスをCEが認識できるようにすることです。 （これらの選択は、4rdが有効になる前に行われた可能性があります。）
For this, the 4rd Tag has its "u" and "g" bits [RFC4291] both set to 1, so that they maximally differ from these existing IPv6 address schemas. So far, u = g = 1 has not been used in any IPv6 addressing architecture.
このため、4番目のタグの "u"および "g"ビット[RFC4291]はどちらも1に設定されているため、これらの既存のIPv6アドレススキーマとは最大限に異なります。これまでのところ、u = g = 1はどのIPv6アドレッシングアーキテクチャでも使用されていません。
With the 4rd Tag, IPv6 packets can be routed to the 4rd function within a CE node based on a /80 prefix that no native IPv6 address can contain.
4番目のタグを使用すると、ネイティブIPv6アドレスに含めることができない/ 80プレフィックスに基づいて、CEノード内の4番目の機能にIPv6パケットをルーティングできます。
(4) Add to the result a Checksum Neutrality Preserver (CNP). Its value, in one's complement arithmetic, is the opposite of the sum of 16-bit fields of the IPv6 address other than the IPv4 address and the CNP themselves (i.e., five consecutive fields in address bits 0-79).
（4）結果にチェックサム中立性プリサーバー（CNP）を追加します。その値は、1の補数演算で、IPv4アドレスとCNP自体以外のIPv6アドレスの16ビットフィールドの合計（つまり、アドレスビット0〜79の5つの連続したフィールド）の反対です。
NOTE: The CNP guarantees that Tunnel packets are valid IPv6 packets for all Layer 4 protocols that use the same checksum algorithm as TCP. This guarantee does not depend on where the checksum fields of these protocols are placed in IP payloads. (Today, such protocols are UDP [RFC768], TCP [RFC793], UDP-Lite [RFC3828], and the Datagram Congestion Control Protocol (DCCP) [RFC5595]. Should new ones be specified, BRs will support them without needing an update.)
注：CNPは、トンネルパケットが、TCPと同じチェックサムアルゴリズムを使用するすべてのレイヤー4プロトコルで有効なIPv6パケットであることを保証します。この保証は、これらのプロトコルのチェックサムフィールドがIPペイロードのどこに配置されるかに依存しません。 （今日、そのようなプロトコルはUDP [RFC768]、TCP [RFC793]、UDP-Lite [RFC3828]、およびデータグラム輻輳制御プロトコル（DCCP）[RFC5595]です。新しいプロトコルが指定された場合、BRは更新を必要とせずにそれらをサポートします。）
R-10: A 4rd-capable CE SHOULD, and a 4rd-enabled CE MUST, always prohibit all addresses that use its advertised prefix and have an IID starting with 0x0300 (4rd Tag), by using Duplicate Address Detection [RFC4862].
R-10：4番目の対応CEと4番目の対応CEは、アドバタイズされたプレフィックスを使用し、重複アドレス検出[RFC4862]を使用して、0x0300（4番目のタグ）で始まるIIDを持つすべてのアドレスを常に禁止する必要があります。
R-11: A CE that is assigned the unspecified IPv4 address (see Section 4.4) MUST use, for packets tunneled between itself and the Domain NAT64+, addresses as detailed in Figure 6: part (a) for its IPv6 source, and part (b) as IPv6 destinations that depend on IPv4 destinations. A NAT64+, being NAT64 conforming [RFC6146], MUST accept IPv6 packets whose destination conforms to Figure 6(b) (4rd Tag instead of "u" and 0x00 octets). In its Binding Information Base, it MUST remember whether a mapping was created with a "u" or 4rd-tag destination. In the IPv4-to-IPv6 direction, it MUST use 4rd tunneling, with source address conforming to Figure 6(b), when using a mapping that was created with a 4rd-tag destination.
R-11：未指定のIPv4アドレス（セクション4.4を参照）が割り当てられたCEは、それ自体とドメインNAT64 +の間でトンネリングされたパケットに対して、図6で詳述されているアドレスを使用する必要があります：IPv6ソースのパート（a）、およびパート（ b）IPv4宛先に依存するIPv6宛先として。 NAT64 +は、NAT64準拠[RFC6146]であり、宛先が図6（b）に準拠するIPv6パケットを受け入れる必要があります（「u」と0x00オクテットの代わりに4番目のタグ）。バインディング情報ベースでは、マッピングが「u」または4番目のタグの宛先で作成されたかどうかを記憶する必要があります。 IPv4からIPv6への方向では、4番目のタグの宛先で作成されたマッピングを使用する場合、送信元アドレスは図6（b）に準拠した4番目のトンネリングを使用する必要があります。
+---------------------+---------+-------+-------------+------+
(a) | CE IPv6 prefix | 0 |4rd Tag| 0 | CNP |
+---------------------+---------+-------+-------------+------+
: <= 64 : >= 0 : 16 : 32 : 16 :
4rd IPv6 address of a CE having no public IPv4 address
<----------- Rule IPv6 prefix --------->:
+-------------------------------+-------+-------------+------+
(b) | NAT64+ IPv6 prefix |4rd Tag|IPv4 address | CNP |
+-------------------------------+-------+-------------+------+
: 64 : 16 : 32 : 16 :
4rd IPv6 address of a host reachable via a NAT64+
Figure 6: Rules for CE and NAT64+
図6：CEおよびNAT64 +のルール
R-12: For anti-spoofing protection, CEs and BRs MUST check that the IPv6 source address of each received Tunnel packet is that which, according to R-9, is derived from the source 4rd IPv4 address. For this, the IPv4 address used to obtain the source 4rd IPv4 address is that embedded in the IPv6 source address (in its bits 80-111). (This verification is needed because IPv6 ingress filtering [RFC3704] applies only to IPv6 prefixes, without any guarantee that Tunnel packets are built as specified in R-9.)
R-12：スプーフィング対策として、CEとBRは、受信した各トンネルパケットのIPv6送信元アドレスが、R-9によると、送信元の4番目のIPv4アドレスから派生したものであることを確認する必要があります。このため、ソース4番目のIPv4アドレスを取得するために使用されるIPv4アドレスは、IPv6ソースアドレス（ビット80〜111）に埋め込まれているアドレスです。 （IPv6イングレスフィルタリング[RFC3704]はIPv6プレフィックスにのみ適用されるため、この検証が必要です。R-9で指定されているようにトンネルパケットが構築される保証はありません。）
R-13: For additional protection against packet corruption at a link layer that might be undetected at this layer during Domain traversal, CEs and BRs SHOULD verify that source and destination IPv6 addresses have not been modified. This can be done by checking that they remain checksum neutral (see the Note above regarding the CNP).
R-13：ドメイントラバーサル中にこのレイヤーで検出されない可能性があるリンクレイヤーでのパケット破損に対する追加の保護のために、CEとBRは、送信元と宛先のIPv6アドレスが変更されていないことを確認する必要があります。これは、チェックサムがニュートラルであることを確認することで実行できます（CNPに関する上記の注を参照）。
R-14: If an IPv4 packet enters a CE or BR with a size such that the derived Tunnel packet would be longer than the Domain PMTU, the packet has to be either discarded or fragmented. The Domain-entry node MUST discard it if the packet has DF = 1, with an ICMP error message returned to the source. It MUST fragment it otherwise, with the payload of each fragment not exceeding PMTU - 48. The first fragment has its offset equal to the received offset. Subsequent fragments have offsets increased by the lengths of the payloads of previous fragments. Functionally, fragmentation is supposed to be done in IPv4 before applying reversible header translation to each fragment; see Section 4.3.
R-14：派生したトンネルパケットがドメインPMTUよりも長くなるようなサイズのIPv4パケットがCEまたはBRに入る場合、パケットは破棄またはフラグメント化する必要があります。パケットにDF = 1が含まれている場合、ドメインエントリノードはそれを破棄する必要があり、ソースにICMPエラーメッセージが返されます。それ以外の場合はフラグメント化し、各フラグメントのペイロードはPMTU-48を超えないようにする必要があります。最初のフラグメントのオフセットは、受信したオフセットと同じです。後続のフラグメントには、前のフラグメントのペイロードの長さだけオフセットが増加しています。機能的には、フラグメント化は、各フラグメントにリバーシブルヘッダー変換を適用する前にIPv4で行われることになっています。セクション4.3を参照してください。
Because ports are available only in the first fragments of IPv4 fragmented packets, a BR needs a mechanism to send to the right shared-address CEs all fragments of fragmented packets.
ポートはIPv4フラグメントパケットの最初のフラグメントでのみ使用できるため、BRでは、フラグメント化されたパケットのすべてのフラグメントを正しい共有アドレスCEに送信するメカニズムが必要です。
For this, a BR MAY systematically reassemble fragmented IPv4 packets before tunneling them. But this consumes large memory space, creates opportunities for denial-of-service-attacks, and can significantly increase forwarding delays. This is the reason for the following requirement:
このため、BRは、フラグメント化されたIPv4パケットをトンネリングする前に、体系的に再構成できます（MAY）。しかし、これは大量のメモリ空間を消費し、サービス拒否攻撃の機会を生み出し、転送遅延を大幅に増加させる可能性があります。これが、次の要件の理由です。
R-15: BRs SHOULD support an algorithm whereby received IPv4 packets can be forwarded on the fly. The following is an example of such an algorithm:
R-15：BRは、受信したIPv4パケットをオンザフライで転送できるアルゴリズムをサポートする必要があります（SHOULD）。以下は、そのようなアルゴリズムの例です。
(1) At BR initialization, if at least one CE Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR initializes an empty "IPv4 packet table" whose entries have the following items:
（1）BRの初期化時に、少なくとも1つのCEマッピングルールが1つ以上の共有パブリックIPv4アドレスを処理する場合（つまり、ルールIPv4プレフィックスの長さ+ EAビット長> 32）、BRは空の「IPv4パケットテーブル」を初期化しますエントリには次の項目があります。
- IPv4 source
- IPv4ソース
- IPv4 destination
- IPv4宛先
- IPv4 identification
- IPv4識別
- Destination port
- 宛先ポート
(2) When the BR receives an IPv4 packet whose matching Mapping rule deals with one or more shared public IPv4 addresses (i.e., length of Rule IPv4 prefix + EA-bits length > 32), the BR searches the table for an entry whose IPv4 source, IPv4 destination, and IPv4 identification are those of the received packet. The BR then performs actions as detailed in Table 5, depending on which conditions hold.
（2）BRが、一致するマッピングルールが1つ以上の共有パブリックIPv4アドレスを処理するIPv4パケットを受信すると（つまり、ルールIPv4プレフィックスの長さ+ EAビット長> 32）、BRはIPv4のエントリをテーブルで検索します送信元、IPv4宛先、およびIPv4識別は、受信パケットのそれらです。次に、BRは、保持されている条件に応じて、表5で詳細に説明されているアクションを実行します。
+-----------------------------+---+---+---+---+---+---+---+---+
| - CONDITIONS - | | | | | | | | |
| First Fragment (offset = 0) | Y | Y | Y | Y | N | N | N | N |
| Last fragment (MF = 0) | Y | Y | N | N | Y | Y | N | N |
| An entry has been found | Y | N | Y | N | Y | N | Y | N |
| ------------------------- | | | | | | | | |
| - RESULTING ACTIONS - | | | | | | | | |
| Create a new entry | - | - | - | X | - | - | - | - |
| Use port of the entry | - | - | - | - | X | - | X | - |
| Update port of the entry | - | - | X | - | - | - | - | - |
| Delete the entry | X | - | - | - | X | - | - | - |
| Forward the packet | X | X | X | X | X | - | X | - |
+-----------------------------+---+---+---+---+---+---+---+---+
Table 5: BR Actions
表5：BRアクション
(3) The BR performs garbage collection for table entries that remain unchanged for longer than some limit. This limit, which is normally longer than the maximum time normally needed to reassemble a packet, is not critical. It should not, however, be longer than 15 seconds [RFC791].
（3）BRは、一定の制限より長く変更されないままであるテーブルエントリのガベージコレクションを実行します。通常、パケットを再構成するために必要な最大時間より長いこの制限は、重要ではありません。ただし、15秒より長くすべきではありません[RFC791]。
R-16: For the above algorithm to be effective, CEs that are assigned shared public IPv4 addresses MUST NOT interleave fragments of several fragmented packets.
R-16：上記のアルゴリズムを有効にするには、共有パブリックIPv4アドレスが割り当てられているCEは、いくつかの断片化されたパケットのフラグメントをインターリーブしてはなりません（MUST NOT）。
R-17: CEs that are assigned IPv4 prefixes and are in nodes that route public IPv4 addresses rather than only using NAT44s MUST have the same behavior as that described just above for BRs.
R-17：NAT44だけを使用するのではなく、IPv4プレフィックスが割り当てられ、パブリックIPv4アドレスをルーティングするノードにあるCEは、BRについて上記で説明したのと同じ動作をする必要があります。
When packets go from CEs that share the same IPv4 address to a common destination, a precaution is needed to guarantee that packet identifications set by sources are different. Otherwise, packet reassembly at the destination could be confused because it is based only on source IPv4 address and Identification. The probability of such confusing situations may in theory be very low, but a safe solution is needed in order to avoid creating new attack opportunities.
パケットが同じIPv4アドレスを共有するCEから共通の宛先に送信される場合、送信元によって設定されたパケットIDが異なることを保証するための予防措置が必要です。そうしないと、宛先でのパケットの再構成は、送信元IPv4アドレスと識別のみに基づいているため、混乱する可能性があります。このような混乱する状況の確率は理論的には非常に低いかもしれませんが、新しい攻撃の機会を生み出さないようにするには、安全なソリューションが必要です。
R-18: A CE that is assigned a shared public IPv4 address MUST only use packet identifications that have the CE PSID in their bits 0 to PSID length - 1.
R-18：共有パブリックIPv4アドレスが割り当てられたCEは、ビット0からPSIDの長さ-1にCE PSIDを持つパケット識別のみを使用する必要があります。
R-19: A BR or a CE that receives a packet from a shared-address CE MUST check that bits 0 to PSID length - 1 of their packet identifications are equal to the PSID found in the source 4rd IPv4 address.
R-19：共有アドレスCEからパケットを受信するBRまたはCEは、ビット0からPSIDの長さ-1のパケットIDがソース4番目のIPv4アドレスにあるPSIDと等しいことを確認する必要があります。
IPv4 TOS and IPv6 traffic class have the same semantic, that of the differentiated services field, or DS field, specified in [RFC2474] and [RFC6040]. Their first 6 bits contain a differentiated services codepoint (DSCP), and their last 2 bits can convey explicit congestion notifications (ECNs), which both may evolve during Domain traversal. [RFC2983] discusses how the DSCP can be handled by tunnel endpoints. The Tunnel Traffic Class option provides permission to ignore DS-field evolutions occurring during Domain traversal, if the desired behavior is that of generic tunnels conforming to [RFC2473].
IPv4 TOSおよびIPv6トラフィッククラスは、[RFC2474]および[RFC6040]で指定された、差別化サービスフィールドまたはDSフィールドと同じ意味を持っています。最初の6ビットにはDiffServコードポイント（DSCP）が含まれ、最後の2ビットには明示的な輻輳通知（ECN）を伝えることができます。ECNはどちらもドメイントラバーサル中に進化する可能性があります。 [RFC2983]では、DSCPをトンネルエンドポイントで処理する方法について説明しています。 [RFC2473]に準拠した一般的なトンネルの動作が望ましい場合、トンネルトラフィッククラスオプションは、ドメイントラバーサル中に発生するDSフィールドの進化を無視する権限を提供します。
R-20: Unless the Tunnel Traffic Class option is configured for the Domain, BRs and CEs MUST copy the IPv4 TOS into the IPv6 traffic class at Domain entry and copy back the IPv6 traffic class into the IPv4 TOS at Domain exit.
R-20：ドメインにトンネルトラフィッククラスオプションが設定されていない限り、BRとCEはIPv4 TOSをドメインエントリでIPv6トラフィッククラスにコピーし、IPv6トラフィッククラスをドメイン出口でIPv4 TOSにコピーする必要があります。
R-21: If the Tunnel Traffic Class option is configured for a Domain, BRs and CEs MUST at Domain entry take the configured Tunnel Traffic Class as the IPv6 traffic class and copy the received IPv4 TOS into the IPv4_TOS of the fragment header (Figure 3). At Domain exit, they MUST copy back the IPv4_TOS of the fragment header into the IPv4 TOS.
R-21：ドメインにトンネルトラフィッククラスオプションが構成されている場合、ドメインエントリのBRおよびCEは、構成されたトンネルトラフィッククラスをIPv6トラフィッククラスとして受け取り、受信したIPv4 TOSをフラグメントヘッダーのIPv4_TOSにコピーする必要があります（図3 ）。ドメインの出口では、フラグメントヘッダーのIPv4_TOSをIPv4 TOSにコピーして戻す必要があります。
If a Tunnel packet is discarded on its way across a 4rd domain because of an unreachable destination, an ICMPv6 error message is returned to the IPv6 source. For the IPv4 source of the discarded packet to be informed of packet loss, the ICMPv6 message has to be converted into an ICMPv4 message.
宛先に到達できないためにトンネルパケットが4番目のドメインを経由する途中で破棄されると、ICMPv6エラーメッセージがIPv6送信元に返されます。破棄されたパケットのIPv4ソースにパケット損失を通知するには、ICMPv6メッセージをICMPv4メッセージに変換する必要があります。
R-22: If a CE or BR receives an ICMPv6 error message [RFC4443], it MUST synthesize an ICMPv4 error packet [RFC792]. This packet MUST contain the first 8 octets of the discarded packet's IP payload. The reserved IPv4 dummy address (192.0.0.8/32; see Section 6) MUST be used as its source address.
R-22：CEまたはBRがICMPv6エラーメッセージ[RFC4443]を受信した場合、ICMPv4エラーパケット[RFC792]を合成する必要があります。このパケットには、破棄されたパケットのIPペイロードの最初の8オクテットが含まれている必要があります。予約済みのIPv4ダミーアドレス（192.0.0.8/32、セクション6を参照）をソースアドレスとして使用する必要があります。
As described in [RFC6145], ICMPv6 Type = 1 and Code = 0 (Destination Unreachable, No route to destination) MUST be translated into ICMPv4 Type = 3 and Code = 0 (Destination Unreachable, Net unreachable), and ICMPv6 Type = 3 and Code = 0 (Time Exceeded, Hop limit exceeded in transit) MUST be translated into ICMPv4 Type = 11 and Code = 0 (Time Exceeded, time to live exceeded in transit).
[RFC6145]で説明されているように、ICMPv6 Type = 1およびCode = 0（Destination Unreachable、No route to destination）は、ICMPv4 Type = 3およびCode = 0（Destination Unreachable、Net unreachable）およびICMPv6 Type = 3およびコード= 0（超過時間、転送中のホップ制限を超過）は、ICMPv4タイプ= 11およびコード= 0（超過時間、送信中の超過時間）に変換する必要があります。
Domain parameters listed in Section 4.2 are subject to the following constraints:
セクション4.2に記載されているドメインパラメータには、次の制約があります。
R-23: Each Domain MUST have a BR Mapping rule and/or a NAT64+ Mapping rule. The BR Mapping rule is only used by CEs that are assigned public IPv4 addresses, shared or not. The NAT64+ Mapping rule is only used by CEs that are assigned the unspecified IPv4 address (Section 4.4) and therefore need an ISP NAT64 to reach IPv4 destinations.
R-23：各ドメインには、BRマッピングルールまたはNAT64 +マッピングルールが必要です。 BRマッピングルールは、パブリックIPv4アドレスが割り当てられているか、割り当てられていないCEによってのみ使用されます。 NAT64 +マッピングルールは、未指定のIPv4アドレス（セクション4.4）が割り当てられているCEでのみ使用されるため、IPv4宛先に到達するにはISP NAT64が必要です。
R-24: Each CE and each BR MUST support up to 32 Mapping rules.
R-24：各CEおよび各BRは、最大32のマッピングルールをサポートする必要があります。
Support for up to 32 Mapping rules ensures that independently acquired CEs and BR nodes can always interwork.
最大32のマッピングルールのサポートにより、独立して取得されたCEとBRノードが常に相互に連携できることが保証されます。
ISPs that need Mapping rules for more IPv4 prefixes than this number SHOULD split their networks into multiple Domains. Communication between these domains can be done in IPv4 or by some other implementation-dependent, but equivalent, means.
この数より多いIPv4プレフィックスのマッピングルールが必要なISPは、ネットワークを複数のドメインに分割する必要があります（SHOULD）。これらのドメイン間の通信は、IPv4で、または他の実装に依存するが同等の手段で実行できます。
R-25: For mesh topologies, where CE-CE paths don't go via BRs, all Mapping rules of the Domain MUST be sent to all CEs. For hub-and-spoke topologies, where all CE-CE paths go via BRs, each CE MAY be sent only the BR Mapping rule of the Domain plus, if different, the CE Mapping rule that applies to its CE IPv6 prefix.
R-25：CE-CEパスがBRを経由しないメッシュトポロジの場合、ドメインのすべてのマッピングルールをすべてのCEに送信する必要があります。すべてのCE-CEパスがBRを経由するハブアンドスポークトポロジの場合、各CEには、ドメインのBRマッピングルールと、異なる場合は、そのCE IPv6プレフィックスに適用されるCEマッピングルールのみを送信できます（MAY）。
R-26: In a Domain where the chosen topology is hub-and-spoke, all CEs MUST have IPv6 prefixes that match a CE Mapping rule. (Otherwise, packets sent to CEs whose IPv6 prefixes would match only the BR Mapping rule would, with longest-match selected routes, be routed directly to these CEs. This would be contrary to the hub-and-spoke requirement.)
R-26：選択したトポロジがハブアンドスポークであるドメインでは、すべてのCEに、CEマッピングルールと一致するIPv6プレフィックスが必要です。 （それ以外の場合、IPv6プレフィックスがBRマッピングルールのみに一致するCEに送信されるパケットは、選択された最長ルートで、これらのCEに直接ルーティングされます。これは、ハブアンドスポークの要件に反します。）
R-27: CEs MUST be able to acquire parameters of 4rd domains (Section 4.2) in DHCPv6 [RFC3315]. Formats of DHCPv6 options to be used are detailed in Figures 7, 8, and 9, with field values specified after each figure.
R-27：CEはDHCPv6 [RFC3315]の4番目のドメイン（セクション4.2）のパラメーターを取得できなければなりません（MUST）。使用されるDHCPv6オプションのフォーマットについては、図7、8、および9で詳しく説明されており、各図の後にフィールド値が指定されています。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| encapsulated 4rd rule options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: DHCPv6 Option for 4rd
図7：4番目のDHCPv6オプション
o option code: 97, OPTION_4RD (see Section 6)
o オプションコード：97、OPTION_4RD（セクション6を参照）
o option-length: the length of encapsulated options, in octets o encapsulated 4rd rule options: The OPTION_4RD DHCPv6 option contains at least one encapsulated OPTION_4RD_MAP_RULE option and a maximum of one encapsulated OPTION_4RD_NON_MAP_RULE option. Since DHCP servers normally send whatever options the operator configures, operators are advised to configure these options appropriately. DHCP servers MAY check to see that the configuration follows these rules and notify the operator in an implementation-dependent manner if the settings for these options aren't valid. The length of encapsulated options is in octets.
o option-length：カプセル化されたオプションの長さ（オクテット単位）oカプセル化された4番目のルールオプション：OPTION_4RD DHCPv6オプションには、少なくとも1つのカプセル化されたOPTION_4RD_MAP_RULEオプションと最大1つのカプセル化されたOPTION_4RD_NON_MAP_RULEオプションが含まれます。 DHCPサーバーは通常、オペレーターが構成するオプションを送信するため、オペレーターはこれらのオプションを適切に構成することをお勧めします。 DHCPサーバーは、構成がこれらのルールに従っていることを確認し、これらのオプションの設定が有効でない場合は、実装に依存する方法でオペレーターに通知する場合があります。カプセル化されたオプションの長さはオクテットです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option = OPTION_4RD_MAP_RULE | option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| prefix4-len | prefix6-len | ea-len |W| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| rule-ipv4-prefix |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| rule-ipv6-prefix |
+ +
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Encapsulated Option for Mapping-Rule Parameters
図8：マッピングルールパラメータのカプセル化オプション
o option code: 98, encapsulated OPTION_4RD_MAP_RULE option (see Section 6)
o オプションコード：98、カプセル化されたOPTION_4RD_MAP_RULEオプション（セクション6を参照）
o option-length: 20
o オプションの長さ：20
o prefix4-len: number of bits of the Rule IPv4 prefix
o prefix4-len：ルールIPv4プレフィックスのビット数
o prefix6-len: number of bits of the Rule IPv6 prefix
o prefix6-len：ルールIPv6プレフィックスのビット数
o ea-len: EA-bits length
o ea-len：EAビット長
o W: WKP authorized, = 1 if set
o W：WKP承認済み、設定されている場合は1
o rule-ipv4-prefix: Rule IPv4 prefix, left-aligned
o rule-ipv4-prefix：ルールIPv4プレフィックス、左揃え
o rule-ipv6-prefix: Rule IPv6 prefix, left-aligned
o rule-ipv6-prefix：ルールIPv6プレフィックス、左揃え
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|option =OPTION_4RD_NON_MAP_RULE| option-length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|H| 0 |T| traffic-class | domain-pmtu |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Encapsulated Option for Non-Mapping-Rule Parameters of 4rd Domains
図9：4番目のドメインの非マッピングルールパラメーターのカプセル化オプション
o option code: 99, encapsulated OPTION_4RD_NON_MAP_RULE option (see Section 6)
o オプションコード：99、カプセル化されたOPTION_4RD_NON_MAP_RULEオプション（セクション6を参照）
o option-length: 4
o オプションの長さ：4
o H: Hub-and-spoke topology (= 1 if Yes)
o H：ハブアンドスポークトポロジ（=はいの場合は1）
o T: Traffic Class flag (= 1 if a Tunnel Traffic Class is provided)
o T：トラフィッククラスフラグ（=トンネルトラフィッククラスが提供されている場合は1）
o traffic-class: Tunnel Traffic Class
o traffic-class：トンネルトラフィッククラス
o domain-pmtu: Domain PMTU (at least 1280 octets)
o domain-pmtu：ドメインPMTU（少なくとも1280オクテット）
Means other than DHCPv6 that may prove useful to provide 4rd parameters to CEs are off-scope for this document. The same or similar parameter formats would, however, be recommended to facilitate training and operation.
DHCPv6以外の手段で、CEに4番目のパラメータを提供するのに役立つことがわかっている場合、このドキュメントでは対象外です。ただし、トレーニングや操作を容易にするために、同じまたは類似のパラメーター形式が推奨されます。
Spoofing attacks
なりすまし攻撃
With IPv6 ingress filtering in effect in the Domain [RFC3704], as required in Section 3 (Figure 1 in particular), and with consistency checks between 4rd IPv4 and IPv6 addresses (Section 4.5), no spoofing opportunity in IPv4 is introduced by 4rd: being able to use as source IPv6 address only one that has been allocated to him, a customer can only provide as source 4rd IPv4 address that which derives this IPv6 address according to Section 4.5, i.e., one that his ISP has allocated to him.
ドメイン[RFC3704]でIPv6イングレスフィルタリングが有効になり、セクション3（特に図1）で必要とされ、4番目のIPv4アドレスとIPv6アドレス間の整合性チェック（セクション4.5）により、IPv4でのなりすましの機会が4rdによって導入されません。割り当てられた1つのIPv6アドレスのみをソースIPv6アドレスとして使用できるため、顧客は、セクション4.5に従ってこのIPv6アドレスを導出するソース4番目のIPv4アドレス、つまりISPが彼に割り当てたアドレスのみを提供できます。
Routing loop attacks
ルーティングループ攻撃
Routing loop attacks that may exist in some "automatic tunneling" scenarios are documented in [RFC6324]. No opportunities for routing loop attacks have been identified with 4rd.
いくつかの「自動トンネリング」シナリオに存在する可能性のあるルーティングループ攻撃は、[RFC6324]で文書化されています。ルーティングループ攻撃の機会は4rdで確認されていません。
Fragmentation-related attacks
断片化関連の攻撃
As discussed in Section 4.6, each BR of a Domain that assigns shared public IPv4 addresses should maintain a dynamic table of fragmented packets that go to these shared-address CEs.
セクション4.6で説明したように、共有パブリックIPv4アドレスを割り当てるドメインの各BRは、これらの共有アドレスCEに送信される断片化されたパケットの動的テーブルを維持する必要があります。
This leaves BRs vulnerable to denial-of-service attacks from hosts that would send very large numbers of first fragments and would never send last fragments having the same packet identifications. This vulnerability is inherent in IPv4 address sharing, be it static or dynamic. Compared to what it is with algorithms that reassemble IPv4 packets in BRs, it is, however, significantly mitigated by the algorithm provided in Section 4.6.2, as that algorithm uses much less memory space.
これにより、非常に多数の最初のフラグメントを送信し、同じパケットIDを持つ最後のフラグメントを送信しないホストからのサービス拒否攻撃に対してBRが脆弱になります。この脆弱性は、静的または動的にかかわらず、IPv4アドレス共有に固有です。ただし、BRでIPv4パケットを再構成するアルゴリズムとは異なり、4.6.2で提供されているアルゴリズムによって大幅に軽減されます。これは、アルゴリズムが使用するメモリ領域がはるかに少ないためです。
IANA has allocated the following:
IANAは以下を割り当てました。
o Encapsulated options OPTION_4RD (97), OPTION_4RD_MAP_RULE (98), and OPTION_4RD_NON_MAP_RULE (99). These options have been recorded in the option code space of the "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)" registry. See Section 4.9 of this document and Section 24.3 of [RFC3315]).
o カプセル化されたオプションOPTION_4RD（97）、OPTION_4RD_MAP_RULE（98）、およびOPTION_4RD_NON_MAP_RULE（99）。これらのオプションは、「IPv6の動的ホスト構成プロトコル（DHCPv6）」レジストリのオプションコードスペースに記録されています。このドキュメントのセクション4.9と[RFC3315]のセクション24.3をご覧ください）。
Value | Description | Reference
-----------+-------------------------+---------------
97 | OPTION_4RD | this document
98 | OPTION_4RD_MAP_RULE | this document
99 | OPTION_4RD_NON_MAP_RULE | this document
o Reserved IPv4 address 192.0.0.8/32 to be used as the "IPv4 dummy address" (Section 4.8).
o 「IPv4ダミーアドレス」として使用される予約済みIPv4アドレス192.0.0.8/32（セクション4.8）。
The present specification has been influenced by many previous IETF drafts, in particular those accessible at <http://tools.ietf.org/html/draft-xxxx>, where "xxxx" refers to the following (listed in order, by date of their first versions):
現在の仕様は、以前の多くのIETFドラフト、特に<http://tools.ietf.org/html/draft-xxxx>でアクセス可能なIETFドラフトに影響を受けています。ここで、「xxxx」は以下を指します（日付順にリストされています）彼らの最初のバージョンの）：
o bagnulo-behave-nat64 (2008-06-10)
o bagnulo-behave-nat64（2008年6月10日）
o xli-behave-ivi (2008-07-06)
o xli-behave-ivi（2008年7月6日）
o despres-sam-scenarios (2008-09-28)
o despres-sam-scenarios（2008-09-28）
o boucadair-port-range (2008-10-23) o ymbk-aplusp (2008-10-27)
お ぼうかだいｒーぽｒｔーらんげ （２００８ー１０ー２３） お ｙｍｂｋーあｐぅｓｐ （２００８ー１０ー２７）
o xli-behave-divi (2009-10-19)
o Xli-Behve-DV（2009年10月14日）
o thaler-port-restricted-ip-issues (2010-02-28)
o thaler-port-restricted-ip-issues（2010年2月28日）
o cui-softwire-host-4over6 (2010-07-06)
o cui-softwire-host-4over6（2010-07-06）
o dec-stateless-4v6 (2011-03-05)
o dec-stateless-4v6（2011-03-05）
o matsushima-v6ops-transition-experience (2011-03-07)
o matsushima-v6ops-transition-experience（2011-03-07）
o despres-intarea-4rd (2011-03-07)
o despres-intarea-4rd（2011-03-07）
o deng-aplusp-experiment-results (2011-03-07)
o アパルーサの実験結果を待つ（2011-03-07）
o operators-softwire-stateless-4v6-motivation (2011-05-05)
o オペレーター-softwire-stateless-4v6-motivation（2011-05-05）
o xli-behave-divi-pd (2011-07-04)
o xli-behave-divi-pd（2011年7月4日）
o murakami-softwire-4rd (2011-07-04)
o むらかみーそｆとぃれー４ｒｄ （２０１１ー０７ー０４）
o murakami-softwire-4v6-translation (2011-07-04)
o 村上ーそｆとぃれー４Ｖ６ーｔ欄ｓァ地温 （２０１１ー０７ー０４）
o despres-softwire-4rd-addmapping (2011-08-19)
o despres-softwire-4rd-addmapping（2011-08-19）
o boucadair-softwire-stateless-requirements (2011-09-08)
o boucadair-softwire-stateless-requirements（2011-09-08）
o chen-softwire-4v6-add-format (2011-10-12)
o chen-softwire-4v6-add-format（2011-10-12）
o mawatari-softwire-464xlat (2011-10-16)
o まわたりーそｆとぃれー４６４ｘぁｔ （２０１１ー１０ー１６）
o mdt-softwire-map-dhcp-option (2011-10-24)
o mdt-softwire-map-dhcp-option（2011-10-24）
o mdt-softwire-mapping-address-and-port (2011-10-24)
o mdt-softwire-mapping-address-and-port（2011-10-24）
o mdt-softwire-map-translation (2012-01-10)
o mdt-softwire-map-translation（2012-01-10）
o mdt-softwire-map-encapsulation (2012-01-27)
o mdt-softwire-map-encapsulation（2012-01-27）
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、DOI 10.17487 / RFC0791、1981年9月、<http://www.rfc-editor.org/info/rfc791>。
[RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, DOI 10.17487/RFC0792, September 1981, <http://www.rfc-editor.org/info/rfc792>.
[RFC792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、DOI 10.17487 / RFC0792、1981年9月、<http://www.rfc-editor.org/info/rfc792>。
[RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, DOI 10.17487/RFC0793, September 1981, <http://www.rfc-editor.org/info/rfc793>.
[RFC793] Postel、J。、「Transmission Control Protocol」、STD 7、RFC 793、DOI 10.17487 / RFC0793、1981年9月、<http://www.rfc-editor.org/info/rfc793>。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、DOI 10.17487 / RFC2460、1998年12月、<http://www.rfc-editor.org/info/ rfc2460>。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, DOI 10.17487/RFC2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474] Nichols、K.、Blake、S.、Baker、F。、およびD. Black、「IPv4およびIPv6ヘッダーのDiffServフィールド（DSフィールド）の定義」、RFC 2474、DOI 10.17487 / RFC2474、 1998年12月、<http://www.rfc-editor.org/info/rfc2474>。
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, DOI 10.17487/RFC2983, October 2000, <http://www.rfc-editor.org/info/rfc2983>.
[RFC2983] Black、D。、「Differentiated Services and Tunnels」、RFC 2983、DOI 10.17487 / RFC2983、2000年10月、<http://www.rfc-editor.org/info/rfc2983>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, <http://www.rfc-editor.org/info/rfc4291>.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、DOI 10.17487 / RFC4291、2006年2月、<http://www.rfc-editor.org/info/rfc4291>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, DOI 10.17487/RFC4443, March 2006, <http://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、DOI 10.17487 / RFC4443、3月2006、<http://www.rfc-editor.org/info/rfc4443>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T。、およびT. Jinmei、「IPv6 Stateless Address Autoconfiguration」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<http://www.rfc-editor.org/info / rfc4862>。
[RFC4925] Li, X., Ed., Dawkins, S., Ed., Ward, D., Ed., and A. Durand, Ed., "Softwire Problem Statement", RFC 4925, DOI 10.17487/RFC4925, July 2007, <http://www.rfc-editor.org/info/rfc4925>.
[RFC4925] Li、X、編、Dawkins、S、編、Ward、D、編、A。Durand、編、「Softwire Problem Statement」、RFC 4925、DOI 10.17487 / RFC4925、7月2007、<http://www.rfc-editor.org/info/rfc4925>。
[RFC5082] Gill, V., Heasley, J., Meyer, D., Savola, P., Ed., and C. Pignataro, "The Generalized TTL Security Mechanism (GTSM)", RFC 5082, DOI 10.17487/RFC5082, October 2007, <http://www.rfc-editor.org/info/rfc5082>.
[RFC5082] Gill、V.、Heasley、J.、Meyer、D.、Savola、P.、Ed。、およびC. Pignataro、「一般化されたTTLセキュリティメカニズム（GTSM）」、RFC 5082、DOI 10.17487 / RFC5082、 2007年10月、<http://www.rfc-editor.org/info/rfc5082>。
[RFC6040] Briscoe, B., "Tunnelling of Explicit Congestion Notification", RFC 6040, DOI 10.17487/RFC6040, November 2010, <http://www.rfc-editor.org/info/rfc6040>.
[RFC6040] Briscoe、B。、「Tunnelling of Explicit Congestion Notification」、RFC 6040、DOI 10.17487 / RFC6040、2010年11月、<http://www.rfc-editor.org/info/rfc6040>。
[NAT444] Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., and H. Ashida, "NAT444", Work in Progress, draft-shirasaki-nat444-06, July 2012.
「なＴ４４４」 やまがた、 い。、 しらさき、 Ｙ。、 なかがわ、 あ。、 やまぐち、 Ｊ。、 あんｄ Ｈ。 あしだ、 ”なＴ４４４”、 をｒｋ いん Ｐろｇれっｓ、 ｄらｆｔーしらさきーなｔ４４４ー０６、 じゅｌｙ ２０１２。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768] Postel、J。、「User Datagram Protocol」、STD 6、RFC 768、DOI 10.17487 / RFC0768、1980年8月、<http://www.rfc-editor.org/info/rfc768>。
[RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, DOI 10.17487/RFC1191, November 1990, <http://www.rfc-editor.org/info/rfc1191>.
[RFC1191] Mogul、J。およびS. Deering、「Path MTU discovery」、RFC 1191、DOI 10.17487 / RFC1191、1990年11月、<http://www.rfc-editor.org/info/rfc1191>。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、DOI 10.17487 / RFC1918、1996年2月、<http://www.rfc-editor.org/info/rfc1918>。
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473, December 1998, <http://www.rfc-editor.org/info/rfc2473>.
[RFC2473] Conta、A。およびS. Deering、「Generic Packet Tunneling in IPv6 Specification」、RFC 2473、DOI 10.17487 / RFC2473、1998年12月、<http://www.rfc-editor.org/info/rfc2473>。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, DOI 10.17487/RFC3022, January 2001, <http://www.rfc-editor.org/info/rfc3022>.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、DOI 10.17487 / RFC3022、2001年1月、<http://www.rfc-editor.org/info/ rfc3022>。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, DOI 10.17487/RFC3704, March 2004, <http://www.rfc-editor.org/info/rfc3704>.
[RFC3704]ベイカー、F。およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、DOI 10.17487 / RFC3704、2004年3月、<http://www.rfc-editor.org/info/rfc3704 >。
[RFC3828] Larzon, L-A., Degermark, M., Pink, S., Jonsson, L-E., Ed., and G. Fairhurst, Ed., "The Lightweight User Datagram Protocol (UDP-Lite)", RFC 3828, DOI 10.17487/RFC3828, July 2004, <http://www.rfc-editor.org/info/rfc3828>.
[RFC3828] Larzon、LA。、Degermark、M.、Pink、S.、Jonsson、LE。、Ed。、and G. Fairhurst、Ed。、 "The Lightweight User Datagram Protocol（UDP-Lite）"、RFC 3828、 DOI 10.17487 / RFC3828、2004年7月、<http://www.rfc-editor.org/info/rfc3828>。
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271] Rekhter、Y。、編、Li、T。、編、S。Hares、編、「A Border Gateway Protocol 4（BGP-4）」、RFC 4271、DOI 10.17487 / RFC4271、2006年1月、<http://www.rfc-editor.org/info/rfc4271>。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, DOI 10.17487/RFC4821, March 2007, <http://www.rfc-editor.org/info/rfc4821>.
[RFC4821] Mathis、M。およびJ. Heffner、「Packetization Layer Path MTU Discovery」、RFC 4821、DOI 10.17487 / RFC4821、2007年3月、<http://www.rfc-editor.org/info/rfc4821>。
[RFC4961] Wing, D., "Symmetric RTP / RTP Control Protocol (RTCP)", BCP 131, RFC 4961, DOI 10.17487/RFC4961, July 2007, <http://www.rfc-editor.org/info/rfc4961>.
[RFC4961]ウィング、D。、「対称RTP / RTP制御プロトコル（RTCP）」、BCP 131、RFC 4961、DOI 10.17487 / RFC4961、2007年7月、<http://www.rfc-editor.org/info/rfc4961 >。
[RFC5595] Fairhurst, G., "The Datagram Congestion Control Protocol (DCCP) Service Codes", RFC 5595, DOI 10.17487/RFC5595, September 2009, <http://www.rfc-editor.org/info/rfc5595>.
[RFC5595] Fairhurst、G。、「The Datagram Congestion Control Protocol（DCCP）Service Codes」、RFC 5595、DOI 10.17487 / RFC5595、2009年9月、<http://www.rfc-editor.org/info/rfc5595>。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, DOI 10.17487/RFC5969, August 2010, <http://www.rfc-editor.org/info/rfc5969>.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructure on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、DOI 10.17487 / RFC5969、2010年8月、<http：//www.rfc-editor。 org / info / rfc5969>。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, DOI 10.17487/RFC6145, April 2011, <http://www.rfc-editor.org/info/rfc6145>.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、DOI 10.17487 / RFC6145、2011年4月、<http://www.rfc-editor.org/ info / rfc6145>。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, DOI 10.17487/RFC6146, April 2011, <http://www.rfc-editor.org/info/rfc6146>.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、DOI 10.17487 / RFC6146、2011年4月、<http： //www.rfc-editor.org/info/rfc6146>。
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, DOI 10.17487/RFC6324, August 2011, <http://www.rfc-editor.org/info/rfc6324>.
[RFC6324] G.とF. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題の説明と提案された軽減策」、RFC 6324、DOI 10.17487 / RFC6324、2011年8月、<http：//www.rfc-editor。 org / info / rfc6324>。
[RFC6346] Bush, R., Ed., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, DOI 10.17487/ RFC6346, August 2011, <http://www.rfc-editor.org/info/rfc6346>.
[RFC6346]ブッシュ、R。、編、「IPv4アドレス不足に対するアドレスとポート（A + P）のアプローチ」、RFC 6346、DOI 10.17487 / RFC6346、2011年8月、<http：//www.rfc-editor .org / info / rfc6346>。
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, "IPv6 Flow Label Specification", RFC 6437, DOI 10.17487/RFC6437, November 2011, <http://www.rfc-editor.org/info/rfc6437>.
[RFC6437] Amante、S.、Carpenter、B.、Jiang、S。、およびJ. Rajahalme、「IPv6 Flow Label Specification」、RFC 6437、DOI 10.17487 / RFC6437、2011年11月、<http：//www.rfc- editor.org/info/rfc6437>。
[RFC6535] Huang, B., Deng, H., and T. Savolainen, "Dual-Stack Hosts Using "Bump-in-the-Host" (BIH)", RFC 6535, DOI 10.17487/RFC6535, February 2012, <http://www.rfc-editor.org/info/rfc6535>.
[RFC6535] Huang、B.、Deng、H。、およびT. Savolainen、「Bump-in-the-Host（BIH）を使用したデュアルスタックホスト」、RFC 6535、DOI 10.17487 / RFC6535、2012年2月、< http://www.rfc-editor.org/info/rfc6535>。
[RFC6887] Wing, D., Ed., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, DOI 10.17487/RFC6887, April 2013, <http://www.rfc-editor.org/info/rfc6887>.
[RFC6887] Wing、D.、Ed。、Cheshire、S.、Boucadair、M.、Penno、R.、and P. Selkirk、 "Port Control Protocol（PCP）"、RFC 6887、DOI 10.17487 / RFC6887、April 2013 、<http://www.rfc-editor.org/info/rfc6887>。
[RFC7136] Carpenter, B. and S. Jiang, "Significance of IPv6 Interface Identifiers", RFC 7136, DOI 10.17487/RFC7136, February 2014, <http://www.rfc-editor.org/info/rfc7136>.
[RFC7136] Carpenter、B。およびS. Jiang、「Significance of IPv6 Interface Identifiers」、RFC 7136、DOI 10.17487 / RFC7136、2014年2月、<http://www.rfc-editor.org/info/rfc7136>。
[Solutions-4v6] Boucadair, M., Ed., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", Work in Progress, draft-ietf-softwire-stateless-4v6-motivation-05, November 2012.
[Solutions-4v6] Boucadair、M.、Ed。、Matsushima、S.、Lee、Y.、Bonness、O.、Borges、I.、and G. Chen、 "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions "、作業中、draft-ietf-softwire-stateless-4v6-motivation-05、2012年11月。
In the sections that follow, each Mapping rule will be represented as follows, using 0bXXX to represent binary number XXX; square brackets ("[ ]") indicate optional items:
以降のセクションでは、各マッピングルールは次のように表され、0bXXXを使用して2進数XXXを表します。大括弧（ "[]"）はオプションの項目を示します。
{Rule IPv4 prefix, EA-bits length, Rule IPv6 prefix [, WKPs authorized]}
{ルールIPv4プレフィックス、EAビット長、ルールIPv6プレフィックス[、承認されたWKP]}
EXAMPLES:
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
a BR Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34}
a CE Mapping rule
{0.0.0.0/0, 32, 2001:db8:0:1::/80}
a NAT64+ Mapping rule
{198.16.0.0/14, 22, 2001:db8:4000::/34, Yes}
a CE Mapping rule
and hub-and-spoke topology
As far as Mapping rules are concerned, the simplest deployment model is that in which the Domain has only one rule (the BR Mapping rule). To assign an IPv4 address to a CE in this model, an IPv6 /112 is assigned to it, comprising the BR /64 prefix, the 4rd Tag, and the IPv4 address. However, this model has the following limitations: (1) shared IPv4 addresses are not supported; (2) IPv6 prefixes used for 4rd are too long to also be used for native IPv6 addresses; (3) if the IPv4 address space of the ISP is split with many disjoint IPv4 prefixes, the IPv6 routing plan must be as complex as an IPv4 routing plan based on these prefixes.
マッピングルールに関する限り、最も単純な展開モデルは、ドメインに1つのルール（BRマッピングルール）しかないモデルです。このモデルのCEにIPv4アドレスを割り当てるために、BR / 64プレフィックス、4番目のタグ、およびIPv4アドレスで構成されるIPv6 / 112がCEに割り当てられます。ただし、このモデルには次の制限があります。（1）共有IPv4アドレスはサポートされていません。 （2）4番目に使用されるIPv6プレフィックスは長すぎるため、ネイティブIPv6アドレスにも使用できません。 （3）ISPのIPv4アドレススペースが多数のばらばらのIPv4プレフィックスで分割されている場合、IPv6ルーティングプランは、これらのプレフィックスに基づくIPv4ルーティングプランと同じくらい複雑でなければなりません。
With more Mapping rules, CE prefixes used for 4rd can be those used for native IPv6. How to choose CE Mapping rules for a particular deployment does not need to be standardized.
より多くのマッピングルールにより、4番目に使用されるCEプレフィックスは、ネイティブIPv6に使用されるものにすることができます。特定の展開用にCEマッピングルールを選択する方法は、標準化する必要はありません。
The following is only a particular pragmatic approach that can be used for various deployment scenarios. It is applied in some of the use cases that follow.
以下は、さまざまな展開シナリオに使用できる特定の実用的なアプローチのみです。これは、以下のいくつかの使用例に適用されます。
(1) Select a "Common_IPv6_prefix" that will appear at the beginning of all 4rd CE IPv6 prefixes.
（1）すべての4rd CE IPv6プレフィックスの先頭に表示される「Common_IPv6_prefix」を選択します。
(2) Choose all IPv4 prefixes to be used, and assign one of them to each CE Mapping rule i.
（2）使用するすべてのIPv4プレフィックスを選択し、それらの1つを各CEマッピングルールに割り当てます。
(3) For each CE Mapping rule i, do the following:
（3）各CEマッピングルールiについて、以下を実行します。
A. Choose the length of its Rule IPv6 prefix (possibly the same for all CE Mapping rules).
A.ルールIPv6プレフィックスの長さを選択します（おそらくすべてのCEマッピングルールで同じです）。
B. Determine its PSID_length(i). A CE Mapping rule that assigns shared addresses with a sharing ratio of 2^Ki has PSID_length = Ki. A CE Mapping rule that assigns IPv4 prefixes of length L < 32 is considered to have a negative PSID_length (PSID_length = L - 32).
B.そのPSID_length（i）を決定します。 2 ^ Kiの共有比率で共有アドレスを割り当てるCEマッピングルールには、PSID_length = Kiがあります。長さL <32のIPv4プレフィックスを割り当てるCEマッピングルールは、負のPSID_length（PSID_length = L-32）を持つと見なされます。
C. Derive EA-bits length(i) = 32 - L(Rule IPv4 prefix(i)) + PSID_length(i).
C. EAビット長（i）= 32-L（ルールIPv4プレフィックス（i））+ PSID_length（i）を導出します。
D. Derive the length of Rule_code(i), the prefix to be appended to the common prefix to get the Rule IPv6 prefix of rule i:
D.ルールiのルールIPv6プレフィックスを取得するために共通のプレフィックスに追加されるプレフィックス、Rule_code（i）の長さを導出します。
L(Rule_code(i)) = L(CE IPv6 prefix(i))
- L(Common_IPv6_prefix)
- (32 - L(Rule IPv4 prefix(i)))
- PSID_length(i)
E. Derive Rule_code(i) with the following constraints: (1) its length is L(Rule_code(i)); (2) it does not overlap with any of the previously obtained Rule_codes (for instance, 010 and 01011 do overlap, while 00, 011, and 010 do not); (3) it has the lowest possible value as a fractional binary number (for instance, 0100 < 10 < 11011 < 111). Thus, rules whose Rule_code lengths are 4, 3, 5, and 2 give Rule_codes 0000, 001, 00010, and 01.
E.次の制約付きでRule_code（i）を導出します。（1）長さはL（Rule_code（i））; （2）以前に取得したRule_codeと重複しない（たとえば、010と01011は重複するが、00、011、および010は重複しない）。 （3）小数値2進数として可能な最小の値（たとえば、0100 <10 <11011 <111）。したがって、Rule_codeの長さが4、3、5、および2であるルールは、Rule_codeを0000、001、00001、および01にします。
F. Take Rule IPv6 prefix(i) = the Common_IPv6_prefix followed by Rule_code(i).
F. Rule IPv6 prefix（i）= Common_IPv6_prefixの後にRule_code（i）を実行します。
:<--------------------- L(CE IPv6 prefix(i)) --------------------->:
: :
: 32 - L(Rule IPv4 prefix(i)) PSID_length(i):
: \ | :
: :<---------'--------><--'-->:
: : || :
: : \/ :
: :<------->:<--- EA-bits length(i) --->:
: L(Rule_code(i))
: : :
+----------------------------+---------+
| Common_IPv6_prefix |Rule_code|
| | (i) |
+----------------------------+---------+
:<------ L(Rule IPv6 prefix(i)) ------>:
Figure 10: Diagram of One Pragmatic Approach
図10：1つの実用的なアプローチの図
Here, we consider an ISP that offers IPv6-only service to up to 2^20 customers. Each customer is delegated a /56, starting with common prefix 2001:db8:0::/36. The ISP wants to add public IPv4 service for customers that are 4rd capable. It prefers to do so with stateless operation in its nodes but has significantly fewer IPv4 addresses than IPv6 addresses, so a sharing ratio is necessary.
ここでは、最大2 ^ 20の顧客にIPv6のみのサービスを提供するISPを検討します。各顧客には、共通のプレフィックス2001：db8：0 :: / 36で始まる/ 56が委任されています。 ISPは、4番目に対応している顧客向けにパブリックIPv4サービスを追加したいと考えています。ノードでのステートレス操作でそうすることを好みますが、IPv6アドレスよりもIPv4アドレスが大幅に少ないため、共有比率が必要です。
The only IPv4 prefixes it can use are 192.8.0.0/15, 192.4.0.0/16, 192.2.0.0/16, and 192.1.0.0/16 (neither overlapping nor aggregatable). This gives 2^(32 - 15) + 3 * 2^(32 - 16) IPv4 addresses, i.e., 2^18 + 2^16. For the 2^20 customers to have the same sharing ratio, the number of IPv4 addresses to be shared has to be a power of 2. The ISP can therefore give up using one of its /16s, say the last one. (Whether or not it could be motivated to return it to its Internet Registry is off-scope for this document.) The sharing ratio to apply is then 2^20 / 2^18 = 2^2 = 4, giving a PSID length of 2.
使用できる唯一のIPv4プレフィックスは、192.8.0.0 / 15、192.4.0.0 / 16、192.2.0.0 / 16、および192.1.0.0/16です（重複も集約もできません）。これにより、2 ^（32-15）+ 3 * 2 ^（32-16）のIPv4アドレス、つまり2 ^ 18 + 2 ^ 16が得られます。 2 ^ 20の顧客が同じ共有比率を持つためには、共有されるIPv4アドレスの数は2の累乗でなければなりません。したがって、ISPは、/ 16の1つ、たとえば最後のものを使用することをあきらめることができます。 （インターネットレジストリに戻す動機があるかどうかにかかわらず、このドキュメントでは対象外です。）適用する共有比率は2 ^ 20/2 ^ 18 = 2 ^ 2 = 4であり、PSIDの長さは2。
Applying the principles of Appendix B with L(Common_IPv6_prefix) = 36, L(PSID) = 2 for all rules, and L(CE IPv6 prefix(i)) = 56 for all rules, Rule_codes and Rule IPv6 prefixes are as follows:
付録Bの原則を適用して、L（Common_IPv6_prefix）= 36、L（PSID）= 2をすべてのルールに適用し、L（CE IPv6 prefix（i））= 56をすべてのルールに適用すると、Rule_codesとRule IPv6プレフィックスは次のようになります。
+--------------+--------+-----------+-----------+-------------------+
| CE Rule IPv4 | EA | Rule-Code | Code | CE Rule IPv6 |
| prefix | bits | length | (binary) | prefix |
| | length | | | |
+--------------+--------+-----------+-----------+-------------------+
| 192.8.0.0/15 | 19 | 1 | 0 | 2001:db8:0::/37 |
| 192.4.0.0/16 | 18 | 2 | 10 | 2001:db8:800::/38 |
| 192.2.0.0/16 | 18 | 2 | 11 | 2001:db8:c00::/38 |
+--------------+--------+-----------+-----------+-------------------+
Mapping rules are then the following:
マッピングルールは次のとおりです。
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
The CE whose IPv6 prefix is, for example, 2001:db8:0bbb:bb00::/56 derives its IPv4 address and its port set as follows (Section 4.4):
IPv6プレフィックスがたとえば2001：db8：0bbb：bb00 :: / 56であるCEは、IPv4アドレスとポートセットを次のように導出します（セクション4.4）。
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
Rule IPv6 prefix(i): 2001:0db8:0800::/38 (longest match)
EA-bits length(i) : 18
EA bits : 0b11 1011 1011 1011 1011
Rule IPv4 prefix(i): 0b1100 0000 0000 0100 (192.4.0.0/16)
IPv4 address : 0b1100 0000 0000 0100 1110 1110 1110 1110
: 192.4.238.238
PSID : 0b11
Ports : 0bYYYY 11XX XXXX XXXX
with YYYY > 0, and X...X any value
An IPv4 packet sent to address 192.4.238.238 and port 7777 is tunneled to the IPv6 address obtained as follows (Section 4.5):
アドレス192.4.238.238およびポート7777に送信されたIPv4パケットは、次のように取得されたIPv6アドレスにトンネルされます（セクション4.5）。
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/56
IPv6 address : 2001:0db8:0bbb:bb00:300:c004:eeee:YYYY
with YYYY = the computed CNP
We now consider an ISP that has the same need as the ISP described in the previous section, except that (1) instead of using only its own IPv6 infrastructure, it uses that of a third-party provider and (2) some of its customers use this provider's Customer Premises Equipment (CPEs) so that they can use specific services offered by the provider. In these CPEs, a non-zero index is used to route IPv6 packets to the physical port to which CEs are attached, say 0x2. Each such CPE delegates to the CE nodes the customer-site IPv6 prefix followed by this index.
ここでは、前のセクションで説明したISPと同じニーズを持つISPについて検討します。ただし、（1）独自のIPv6インフラストラクチャのみを使用するのではなく、サードパーティプロバイダーのインフラストラクチャと（2）一部の顧客このプロバイダーの顧客宅内機器（CPE）を使用して、プロバイダーが提供する特定のサービスを使用できるようにします。これらのCPEでは、ゼロ以外のインデックスを使用して、IPv6パケットをCEが接続されている物理ポート（0x2など）にルーティングします。そのような各CPEは、CEノードに、顧客サイトのIPv6プレフィックスとそれに続くこのインデックスを委任します。
The ISP is supposed to have the same IPv4 prefixes as those in the previous use case -- 192.8.0.0/15, 192.4.0.0/16, and 192.2.0.0/16 -- and to use the same Common_IPv6_prefix, 2001:db8:0::/36.
ISPは、前の使用例と同じIPv4プレフィックス（192.8.0.0/15、192.4.0.0/16、および192.2.0.0/16）を持ち、同じCommon_IPv6_prefix、2001：db8を使用することになっています。 0 :: / 36。
We also assume that only a minority of customers use third-party CPEs, so that it is sufficient to use only one of the two /16s for them.
また、少数の顧客のみがサードパーティのCPEを使用していると想定しているため、2つの/ 16のうちの1つだけを使用すれば十分です。
Mapping rules are then (see Appendix C.1):
マッピングルールは次のとおりです（付録C.1を参照）：
{192.8.0.0/15, 19, 2001:0db8:0000::/37}
{192.4.0.0/16, 18, 2001:0db8:0800::/38}
{192.2.0.0/16, 18, 2001:0db8:0c00::/38}
{0.0.0.0/0, 32, 2001:0db8:0000:0001:300::/80}
CEs that are behind third-party CPEs derive their own IPv4 addresses and port sets as described in Appendix C.1.
サードパーティのCPEの背後にあるCEは、付録C.1で説明されているように、独自のIPv4アドレスとポートセットを取得します。
In a BR, and also in a CE if the topology is mesh, the IPv6 address that is derived from IPv4 address 192.4.238.238 and port 7777 is obtained as described in the previous section, except for the last two steps, which are modified as follows:
BR、およびトポロジーがメッシュの場合はCEでも、前のセクションで説明したように、IPv4アドレス192.4.238.238およびポート7777から派生したIPv6アドレスが取得されますが、最後の2つのステップは次のように変更されます。続く：
IPv4 address : 192.4.238.238 (0xc004 eeee)
: 0b1100 0000 0000 0100 1110 1110 1110 1110
Rule IPv4 prefix(i): 192.4.0.0/16 (longest match)
: 0b1100 0000 0000 0100
IPv4 suffix(i) : 0b1110 1110 1110 1110
EA-bits length(i) : 18
PSID length(i) : 2 (= 16 + 18 - 32)
Port field : 0b 0001 1110 0110 0001 (7777)
PSID : 0b11
Rule IPv6 prefix(i): 2001:0db8:0800::/38
CE IPv6 prefix : 2001:0db8:0bbb:bb00::/60
IPv6 address : 2001:0db8:0bbb:bb00:300:192.4.238.238:YYYY
with YYYY = the computed CNP
In this use case, we consider an ISP that offers IPv4 service with public addresses individually assigned to its customers. It also offers IPv6 service, as it has deployed dual-stack routing. Because it provides its own CPEs to customers, it can upgrade all of its CPEs to support 4rd. It wishes to take advantage of this capability to replace dual-stack routing with IPv6-only routing, without changing any IPv4 address or IPv6 prefix.
この使用例では、顧客に個別に割り当てられたパブリックアドレスでIPv4サービスを提供するISPを検討します。また、デュアルスタックルーティングを導入しているため、IPv6サービスも提供しています。独自のCPEを顧客に提供するため、すべてのCPEをアップグレードして4rdをサポートできます。この機能を利用して、IPv4アドレスやIPv6プレフィックスを変更せずに、デュアルスタックルーティングをIPv6のみのルーティングに置き換えたいと考えています。
For this, the ISP can use the single-rule model described at the beginning of Appendix B. If the prefix routed to BRs is chosen to start with 2001:db8:0:1::/64, this rule is:
このため、ISPは付録Bの冒頭で説明した単一ルールモデルを使用できます。BRにルーティングされるプレフィックスが2001：db8：0：1 :: / 64で始まるように選択されている場合、このルールは次のようになります。
{0.0.0.0/0, 32, 2001:db8:0:1:300::/80}
All that is needed in the network before disabling IPv4 routing is the following:
IPv4ルーティングを無効にする前にネットワークで必要なことは次のとおりです。
o In all routers, where there is an IPv4 route toward x.x.x.x/n, add a parallel route toward 2001:db8:0:1:300:x.x.x.x::/(80+n).
o x.x.x.x / nへのIPv4ルートがあるすべてのルーターで、2001：db8：0：1：300：x.x.x.x :: /（80 + n）へのパラレルルートを追加します。
o Where IPv4 address x.x.x.x was assigned to a CPE, now delegate IPv6 prefix 2001:db8:0:1:300:x.x.x.x::/112.
o IPv4アドレスx.x.x.xがCPEに割り当てられていた場合、IPv6プレフィックス2001：db8：0：1：300：x.x.x.x :: / 112を委任するようになりました。
NOTE: In parallel with this deployment, or after it, shared IPv4 addresses can be assigned to IPv6 customers. It is sufficient that IPv4 prefixes used for this be different from those used for exclusive-address assignments. Under this constraint, Mapping rules can be set up according to the same principles as those described in Appendix C.
注：この展開と並行して、またはその後で、共有IPv4アドレスをIPv6ユーザーに割り当てることができます。これに使用されるIPv4プレフィックスは、排他アドレス割り当てに使用されるプレフィックスと異なっていれば十分です。この制約の下で、付録Cで説明されているのと同じ原則に従ってマッピングルールを設定できます。
In this use case, we consider an ISP that has only deployed IPv4, possibly because some of its network devices are not yet IPv6 capable. Because it did not have enough IPv4 addresses, it has assigned private IPv4 addresses [RFC1918] to customers, say 10.x.x.x. It thus supports up to 2^24 customers (a "Net-10" network, using the NAT444 model [NAT444]).
この使用例では、おそらく一部のネットワークデバイスがまだIPv6に対応していない可能性があるため、IPv4のみを展開しているISPを検討します。十分なIPv4アドレスがなかったため、プライベートIPv4アドレス[RFC1918]を顧客に割り当てました。たとえば、10.x.x.xです。したがって、最大2 ^ 24の顧客をサポートします（NAT444モデル[NAT444]を使用した「Net-10」ネットワーク）。
Now, it wishes to offer IPv6 service without further delay, using 6rd [RFC5969]. It also wishes to offer incoming IPv4 connectivity to its customers with a simpler solution than that provided by the Port Control Protocol (PCP) [RFC6887].
現在、6rd [RFC5969]を使用して、それ以上遅延することなくIPv6サービスを提供したいと考えています。また、ポート制御プロトコル（PCP）[RFC6887]によって提供されるものよりも簡単なソリューションで、着信IPv4接続を顧客に提供したいと考えています。
This appendix describes an example that adds IPv6 (using 6rd) and 4rd services to the "Net-10" private IPv4 network.
この付録では、IPv6（6rdを使用）および4rdサービスを「Net-10」プライベートIPv4ネットワークに追加する例について説明します。
The IPv6 prefix to be used for 6rd is supposed to be 2001:db8::/32, and the public IPv4 prefix to be used for shared addresses is supposed to be 198.16.0.0/16 (0xc610). The resulting sharing ratio is 2^24 / 2^(32 - 16) = 256, giving a PSID length of 8.
6番目に使用されるIPv6プレフィックスは2001：db8 :: / 32であり、共有アドレスに使用されるパブリックIPv4プレフィックスは198.16.0.0/16（0xc610）であると想定されています。結果の共有比率は2 ^ 24/2 ^（32-16）= 256であり、PSIDの長さは8になります。
The ISP installs one or several BRs at its border to the public IPv4 Internet. They support 6rd, and 4rd above it. The BR prefix /64 is supposed to be that which is derived from IPv4 address 10.0.0.1 (i.e., 2001:db8:0:100:/64).
ISPは、境界にパブリックIPv4インターネットへの1つまたは複数のBRをインストールします。それらは6番目と4番目をサポートします。 BRプレフィックス/ 64は、IPv4アドレス10.0.0.1（つまり、2001：db8：0：100：/ 64）から派生したものであると想定されています。
In accordance with [RFC5969], 6rd BRs are configured with the following parameters: IPv4MaskLen = 8; 6rdPrefix = 2001:db8::/32; 6rdBRIPv4Address = 192.168.0.1 (0xc0a80001).
[RFC5969]に従って、6番目のBRは次のパラメーターで構成されます。IPv4MaskLen = 8; 6rdPrefix = 2001：db8 :: / 32; 6rdBRIPv4Address = 192.168.0.1（0xc0a80001）。
4rd Mapping rules are then the following:
4番目のマッピングルールは次のとおりです。
{198.16.0.0/16, 24, 2001:db8:0:0:300::/80}
{0.0.0.0/0, 32, 2001:db8:0:100:300:/80,}
Any customer device that supports 4rd in addition to 6rd can then use its assigned shared IPv4 address with 240 assigned ports.
6rdに加えて4rdをサポートする顧客デバイスは、割り当てられた共有IPv4アドレスを240の割り当てられたポートで使用できます。
If its NAT44 supports port forwarding to provide incoming IPv4 connectivity (statically, or dynamically with Universal Plug and Play (UPnP) and/or the NAT Port Mapping Protocol (NAT-PMP)), it can use it with ports of the assigned port set (a possibility that does not exist in Net-10 networks without 4rd/6rd).
NAT44がポート転送をサポートして着信IPv4接続を提供する場合（静的または動的にユニバーサルプラグアンドプレイ（UPnP）および/またはNATポートマッピングプロトコル（NAT-PMP）を使用）、割り当てられたポートセットのポートで使用できます。 （4rd / 6rdがないNet-10ネットワークには存在しない可能性があります）。
Acknowledgements
謝辞
This specification has benefited over several years from independent proposals, questions, comments, constructive suggestions, and useful criticisms from numerous IETF contributors. The authors would like to express recognition of all of these contributors, and especially the following, in alphabetical order by their first names: Behcet Sarikaya, Bing Liu, Brian Carpenter, Cameron Byrne, Congxiao Bao, Dan Wing, Derek Atkins, Erik Kline, Francis Dupont, Gabor Bajko, Hui Deng, Jacni Quin (who was an active coauthor of some earlier versions of this specification), James Huang, Jan Zorz, Jari Arkko, Kathleen Moriarty, Laurent Toutain, Leaf Yeh, Lorenzo Colitti, Marcello Bagnulo, Mark Townsley, Mohamed Boucadair, Nejc Skoberne, Olaf Maennel, Ole Troan, Olivier Vautrin, Peng Wu, Qiong Sun, Rajiv Asati, Ralph Droms, Randy Bush, Satoru Matsushima, Simon Perreault, Stuart Cheshire, Suresh Krishnan, Ted Lemon, Teemu Savolainen, Tetsuya Murakami, Tina Tsou, Tomek Mrugalski, Washam Fan, Wojciech Dec, Xiaohong Deng, Xing Li, and Yu Fu.
この仕様は、独立した提案、質問、コメント、建設的な提案、および多くのIETF寄稿者からの有用な批判から数年にわたって恩恵を受けてきました。著者は、これらすべての寄稿者、特に次の寄稿者の認識を、名のアルファベット順に並べました：Behcet Sarikaya、Bing Liu、Brian Carpenter、Cameron Byrne、Congxiao Bao、Dan Wing、Derek Atkins、Erik Kline、 Francis Dupont、Gabor Bajko、Hui Deng、Jacni Quin（この仕様の以前のバージョンのアクティブな共著者でした）、James Huang、Jan Zorz、Jari Arkko、Kathleen Moriarty、Laurent Toutain、Leaf Yeh、Lorenzo Colitti、Marcello Bagnulo、マークタウンズリー、モハメドブーカデア、ネイクスコベルネ、オラフメンネル、オレトローン、オリヴィエヴォウトリン、ペンウー、キオンサン、ラジブアサティ、ラルフドロムス、ランディブッシュ、松島悟、サイモンペロール、スチュアートチェシャー、シュレシュクリシュナン、テッドレモン、テッドレモン、村上哲也、Tina Tsou、Tomek Mrugalski、Washam Fan、Wojciech Dec、Xiaohong Deng、Xing Li、Yu Fu。
Authors' Addresses
著者のアドレス
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France
Remi Despres RD-IPtech 3 rue du President Wilson Levallois France
Email: despres.remi@laposte.net
Sheng Jiang (editor) Huawei Technologies Co., Ltd Q14, Huawei Campus, No. 156 BeiQing Road Hai-Dian District, Beijing 100095 China
S横江（編集者）hu Aはテクノロジー株式会社Q14、hu Aはキャンパス、第156 B eh Qing道路H艾-Dイアン地区、北京100095中国
Email: jiangsheng@huawei.com Reinaldo Penno Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States
メール：jiangsheng@huawei.com Reinaldo Penno Cisco Systems、Inc. 170 West Tasman Drive San Jose、CA 95134 United States
Email: repenno@cisco.com
Yiu Lee Comcast One Comcast Center Philadelphia, PA 19103 United States
Yiu Lee Comcast One Comcast Centerフィラデルフィア、PA 19103アメリカ合衆国
Email: yiu_lee@cable.comcast.com
Gang Chen China Mobile 29, Jinrong Avenue Xicheng District, Beijing 100033 China
ギャングチェンチャイナモバイル29、ジンロンアベニューXイチェン地区、北京100033中国
Email: phdgang@gmail.com, chengang@chinamobile.com
Maoke Chen (a.k.a. Noriyuki Arai) BBIX, Inc. Tokyo Shiodome Building, Higashi-Shimbashi 1-9-1 Minato-ku, Tokyo 105-7310 Japan
まおけ ちぇん （あ。ｋ。あ。 のりゆき あらい） っびＸ、 いんｃ。 ときょ しおどめ ぶいｌぢんｇ、 ひがしーしｍばし １ー９ー１ みなとーく、 ときょ １０５ー７３１０ じゃぱん
Email: maoke@bbix.net