RFC 7915 - IP/ICMP Translation Algorithm 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc7915
タイトル : RFC 7915 - IP / ICMP変換アルゴリズム
翻訳編集 : 自動生成

[要約] RFC 7915は、IPv4とIPv6間のIP/ICMPパケット変換アルゴリズムを提供するものであり、IPv6ネットワークでIPv4トラフィックをサポートするためのガイドラインを提供します。目的は、IPv4とIPv6の相互運用性を向上させ、ネットワークの移行を容易にすることです。

Internet Engineering Task Force (IETF)                            C. Bao
Request for Comments: 7915                                         X. Li
Obsoletes: 6145                        CERNET Center/Tsinghua University
Category: Standards Track                                       F. Baker
ISSN: 2070-1721                                            Cisco Systems
                                                             T. Anderson
                                                          Redpill Linpro
                                                                 F. Gont
                                                     Huawei Technologies
                                                               June 2016

IP/ICMP Translation Algorithm

IP / ICMP変換アルゴリズム

Abstract

概要

This document describes the Stateless IP/ICMP Translation Algorithm (SIIT), which translates between IPv4 and IPv6 packet headers (including ICMP headers). This document obsoletes RFC 6145.

このドキュメントでは、IPv4とIPv6のパケットヘッダー（ICMPヘッダーを含む）の間で変換するステートレスIP / ICMP変換アルゴリズム（SIIT）について説明します。このドキュメントはRFC 6145を廃止します。

Status of This Memo

本文書の状態

This is an Internet Standards Track document.

これはInternet Standards Trackドキュメントです。

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841.

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

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

著作権表示

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 and Motivation . . . . . . . . . . . . . . . . .   3
     1.1.  IPv4-IPv6 Translation Model . . . . . . . . . . . . . . .   3
     1.2.  Applicability and Limitations . . . . . . . . . . . . . .   3
     1.3.  Stateless vs. Stateful Mode . . . . . . . . . . . . . . .   4
     1.4.  Path MTU Discovery and Fragmentation  . . . . . . . . . .   5
   2.  Changes from RFC 6145 . . . . . . . . . . . . . . . . . . . .   5
   3.  Conventions . . . . . . . . . . . . . . . . . . . . . . . . .   5
   4.  Translating from IPv4 to IPv6 . . . . . . . . . . . . . . . .   6
     4.1.  Translating IPv4 Headers into IPv6 Headers  . . . . . . .   7
     4.2.  Translating ICMPv4 Headers into ICMPv6 Headers  . . . . .   9
     4.3.  Translating ICMPv4 Error Messages into ICMPv6 . . . . . .  13
     4.4.  Generation of ICMPv4 Error Message  . . . . . . . . . . .  14
     4.5.  Transport-Layer Header Translation  . . . . . . . . . . .  14
     4.6.  Knowing When to Translate . . . . . . . . . . . . . . . .  15
   5.  Translating from IPv6 to IPv4 . . . . . . . . . . . . . . . .  15
     5.1.  Translating IPv6 Headers into IPv4 Headers  . . . . . . .  17
       5.1.1.  IPv6 Fragment Processing  . . . . . . . . . . . . . .  19
     5.2.  Translating ICMPv6 Headers into ICMPv4 Headers  . . . . .  19
     5.3.  Translating ICMPv6 Error Messages into ICMPv4 . . . . . .  22
     5.4.  Generation of ICMPv6 Error Messages . . . . . . . . . . .  23
     5.5.  Transport-Layer Header Translation  . . . . . . . . . . .  23
     5.6.  Knowing When to Translate . . . . . . . . . . . . . . . .  24
   6.  Mapping of IP Addresses . . . . . . . . . . . . . . . . . . .  24
   7.  Special Considerations for ICMPv6 Packet Too Big  . . . . . .  24
   8.  Security Considerations . . . . . . . . . . . . . . . . . . .  24
   9.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  25
     9.1.  Normative References  . . . . . . . . . . . . . . . . . .  25
     9.2.  Informative References  . . . . . . . . . . . . . . . . .  27
   Appendix A.  Stateless Translation Workflow Example . . . . . . .  30
     A.1.  H6 Establishes Communication with H4  . . . . . . . . . .  30
     A.2.  H4 Establishes Communication with H6  . . . . . . . . . .  32
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  33
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  33

1. Introduction and Motivation

1. 紹介と動機

This document obsoletes [RFC6145].

このドキュメントは廃止されました[RFC6145]。

Readers of this document are expected to have read and understood the framework described in [RFC6144]. Implementations of this IPv4/IPv6 translation specification MUST support one or more address mapping algorithms, which are defined in Section 6.

このドキュメントの読者は、[RFC6144]で説明されているフレームワークを読んで理解していることが期待されます。このIPv4 / IPv6変換仕様の実装は、セクション6で定義されている1つ以上のアドレスマッピングアルゴリズムをサポートする必要があります。

1.1. IPv4-IPv6 Translation Model

1.1. IPv4-IPv6変換モデル

The translation model consists of two or more network domains connected by one or more IP/ICMP translators (XLATs) as shown in Figure 1.

変換モデルは、図1に示すように、1つ以上のIP / ICMPトランスレータ（XLAT）で接続された2つ以上のネットワークドメインで構成されています。

               ---------          ---------
             //        \\       //         \\
           /             +----+              \
          |              |XLAT|               | XLAT: IP/ICMP
          |   IPv4       +----+   IPv6        |       Translator
          |   Domain     |    |   Domain      |
          |              |    |               |
           \             |    |              /
            \\         //      \\          //
               --------          ---------

Figure 1: IPv4-IPv6 Translation Model

図1：IPv4-IPv6変換モデル

The scenarios of the translation model are discussed in [RFC6144].

翻訳モデルのシナリオは[RFC6144]で議論されています。

1.2. Applicability and Limitations

1.2. 適用性と制限

This document specifies the translation algorithms between IPv4 packets and IPv6 packets.

このドキュメントでは、IPv4パケットとIPv6パケット間の変換アルゴリズムを指定します。

As with [RFC6145], the translating function specified in this document does not translate any IPv4 options, and it does not translate IPv6 extension headers except the Fragment Header.

[RFC6145]と同様に、このドキュメントで指定されている変換機能はIPv4オプションを変換せず、フラグメントヘッダー以外のIPv6拡張ヘッダーを変換しません。

The issues and algorithms in the translation of datagrams containing TCP segments are described in [RFC5382].

TCPセグメントを含むデータグラムの変換における問題とアルゴリズムは、[RFC5382]で説明されています。

Fragmented IPv4 UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero) are not of significant use on the Internet, and in general will not be translated by the IP/ICMP translator (Section 4.5). However, when the translator is configured to forward the packet without a UDP checksum, the fragmented IPv4 UDP packets will be translated.

UDPチェックサムを含まない（つまり、UDPチェックサムフィールドが0である）断片化されたIPv4 UDPパケットは、インターネットではあまり使用されず、一般にIP / ICMPトランスレータによって変換されません（セクション4.5）。ただし、トランスレーターがUDPチェックサムなしでパケットを転送するように構成されている場合、フラグメント化されたIPv4 UDPパケットは変換されます。

Fragmented ICMP/ICMPv6 packets will not be translated by IP/ICMP translators.

断片化されたICMP / ICMPv6パケットは、IP / ICMPトランスレータによって変換されません。

The IP/ICMP header translation specified in this document is consistent with requirements of multicast IP/ICMP headers. However, IPv4 multicast addresses [RFC5771] cannot be mapped to IPv6 multicast addresses [RFC3307] based on the unicast mapping rule [RFC6052]. An example of experiments of the multicast address mapping can be found in [RFC6219].

このドキュメントで指定されているIP / ICMPヘッダー変換は、マルチキャストIP / ICMPヘッダーの要件と一致しています。ただし、IPv4マルチキャストアドレス[RFC5771]は、ユニキャストマッピングルール[RFC6052]に基づいてIPv6マルチキャストアドレス[RFC3307]にマッピングできません。マルチキャストアドレスマッピングの実験の例は、[RFC6219]にあります。

1.3. Stateless vs. Stateful Mode

1.3. ステートレスモードとステートフルモード

An IP/ICMP translator has two possible modes of operation: stateless and stateful [RFC6144]. In both cases, we assume that a system (a node or an application) that has an IPv4 address but not an IPv6 address is communicating with a system that has an IPv6 address but no IPv4 address, or that the two systems do not have contiguous routing connectivity, or they might have contiguous routing connectivity but are interacting via masking addresses (i.e., hairpinning) [RFC4787], and hence are forced to have their communications translated.

IP / ICMPトランスレータには、ステートレスとステートフルの2つの動作モードがあります[RFC6144]。どちらの場合も、IPv4アドレスはあるがIPv6アドレスはないシステム（ノードまたはアプリケーション）は、IPv6アドレスはあるがIPv4アドレスがないシステムと通信している、または2つのシステムが連続していないと想定しています。ルーティング接続、またはそれらは隣接するルーティング接続を持っている可能性がありますが、マスキングアドレス（つまり、ヘアピニング）[RFC4787]を介して相互作用しているため、通信を変換する必要があります。

In the stateless mode, an IP/ICMP translator will convert IPv4 addresses to IPv6 and vice versa solely based on the configuration of the stateless IP/ICMP translator and information contained within the packet being translated. For example, for the default behavior defined in [RFC6052], a specific IPv6 address range will represent IPv4 systems (IPv4-converted addresses), and the IPv6 systems have addresses (IPv4-translatable addresses) that can be algorithmically mapped to a subset of the service provider's IPv4 addresses. Other stateless translation algorithms are defined in Section 6. The stateless translator does not keep any dynamic session or binding state, thus there is no requirement that the packets in a single session or flow traverse a single translator.

ステートレスモードでは、IP / ICMPトランスレータは、ステートレスIP / ICMPトランスレータの構成と変換されるパケット内に含まれる情報のみに基づいて、IPv4アドレスをIPv6に、またはその逆に変換します。たとえば、[RFC6052]で定義されたデフォルトの動作の場合、特定のIPv6アドレス範囲はIPv4システム（IPv4変換アドレス）を表し、IPv6システムにはアドレス（IPv4変換可能アドレス）があり、アルゴリズムのサブセットにマッピングできます。サービスプロバイダーのIPv4アドレス。その他のステートレス変換アルゴリズムはセクション6で定義されています。ステートレストランスレーターは動的セッションまたはバインディング状態を保持しないため、単一のセッションまたはフローのパケットが単一のトランスレーターを通過する必要はありません。

In the stateful mode, a specific IPv6 address range (consisting of IPv4-converted IPv6 addresses) will typically represent IPv4 systems. The IPv6 nodes may use any IPv6 addresses [RFC4291] except in that range. A stateful IP/ICMP translator continuously maintains a dynamic translation table containing bindings between the IPv4 and IPv6 addresses, and likely also the Layer-4 identifiers, that are used in the translated packets. The exact address translations of any given packet thus become dependent on how packets belonging to the same session or flow have been translated. For this reason, stateful translation generally requires that all packets belonging to a single flow must traverse the same translator.

ステートフルモードでは、特定のIPv6アドレス範囲（IPv4に変換されたIPv6アドレスで構成される）は通常、IPv4システムを表します。 IPv6ノードは、その範囲を除き、任意のIPv6アドレス[RFC4291]を使用できます。ステートフルIP / ICMPトランスレータは、IPv4アドレスとIPv6アドレスの間のバインディングを含む動的変換テーブルを維持し、変換されたパケットで使用されるレイヤ4識別子も維持する可能性があります。したがって、特定のパケットの正確なアドレス変換は、同じセッションまたはフローに属するパケットがどのように変換されたかに依存します。このため、ステートフル変換では、通常、単一のフローに属するすべてのパケットが同じトランスレータを通過する必要があります。

In order to be able to successfully translate a packet from IPv4 to IPv6 or vice versa, the translator must implement an address mapping algorithm. This document does not specify any such algorithms, instead these are referenced from Section 6.

パケットをIPv4からIPv6またはその逆に正常に変換できるようにするには、トランスレーターがアドレスマッピングアルゴリズムを実装する必要があります。このドキュメントでは、そのようなアルゴリズムを指定していませんが、セクション6から参照されています。

1.4. Path MTU Discovery and Fragmentation

1.4. パスMTUディスカバリーとフラグメンテーション

Due to the different sizes of the IPv4 and IPv6 header, which are 20+ octets and 40 octets respectively, handling the maximum packet size is critical for the operation of the IPv4/IPv6 translator. There are three mechanisms to handle this issue: path MTU discovery (PMTUD), fragmentation, and transport-layer negotiation such as the TCP Maximum Segment Size (MSS) option [RFC6691]. Note that the translator MUST behave as a router, i.e., the translator MUST send a Packet Too Big error message or fragment the packet when the packet size exceeds the MTU of the next-hop interface.

IPv4ヘッダーとIPv6ヘッダーのサイズはそれぞれ20+オクテットと40オクテットであるため、最大パケットサイズの処理は、IPv4 / IPv6トランスレーターの操作にとって重要です。この問題を処理するメカニズムは3つあります。パスMTU検出（PMTUD）、断片化、およびTCP最大セグメントサイズ（MSS）オプション[RFC6691]などのトランスポート層ネゴシエーションです。トランスレータはルーターとして動作する必要があることに注意してください。つまり、トランスレータは、パケットサイズがネクストホップインターフェイスのMTUを超えたときに、Packet Too Bigエラーメッセージを送信するか、パケットをフラグメント化する必要があります。

Don't Fragment, ICMP Packet Too Big, and packet fragmentation are discussed in Sections 4 and 5 of this document. The reassembling of fragmented packets in the stateful translator is discussed in [RFC6146], since it requires state maintenance in the translator.

断片化しない、ICMPパケットが大きすぎる、およびパケットの断片化については、このドキュメントのセクション4および5で説明します。ステートフルトランスレータでのフラグメント化されたパケットの再構成については、トランスレータでの状態維持が必要なため、[RFC6146]で説明されています。

2. Changes from RFC 6145

2. RFC 6145からの変更点

The changes from RFC 6145 are the following:

RFC 6145からの変更点は次のとおりです。

1. Inserted the notes about IPv6 extension header handling: [Err3059], [Err3060], [Err3061], and [Err4090].

1. IPv6拡張ヘッダーの処理に関するメモを挿入しました：[Err3059]、[Err3060]、[Err3061]、および[Err4090]。

2. Deprecated the algorithm that generates the IPv6 atomic fragments, as a result of the analysis in [ATOMIC] and the specification in [IPv6].

2. [ATOMIC]での分析と[IPv6]での仕様の結果として、IPv6アトミックフラグメントを生成するアルゴリズムを非推奨にしました。

3. Inserted the notes for stateless source address mapping for ICMPv6 packets [RFC6791].

3. ICMPv6パケットのステートレス送信元アドレスマッピングに関するメモを挿入しました[RFC6791]。

4. Supported new address mapping algorithms and moved the discussion of these algorithms to Section 6.

4. 新しいアドレスマッピングアルゴリズムをサポートし、これらのアルゴリズムの説明をセクション6に移動しました。

3. Conventions

3. 規約

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]で説明されているように解釈されます。

4. Translating from IPv4 to IPv6

4. IPv4からIPv6への変換

When an IP/ICMP translator receives an IPv4 datagram addressed to a destination towards the IPv6 domain, it translates the IPv4 header of that packet into an IPv6 header. The original IPv4 header on the packet is removed and replaced by an IPv6 header, and the transport checksum is updated as needed, if that transport is supported by the translator. The data portion of the packet is left unchanged. The IP/ICMP translator then forwards the packet based on the IPv6 destination address.

IP / ICMPトランスレータは、宛先に宛てられたIPv4データグラムをIPv6ドメインに受信すると、そのパケットのIPv4ヘッダーをIPv6ヘッダーに変換します。パケットの元のIPv4ヘッダーは削除され、IPv6ヘッダーに置き換えられます。トランスポートがトランスレーターでサポートされている場合、トランスポートチェックサムは必要に応じて更新されます。パケットのデータ部分は変更されません。次に、IP / ICMPトランスレータは、IPv6宛先アドレスに基づいてパケットを転送します。

              +-------------+                 +-------------+
              |    IPv4     |                 |    IPv6     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |  Transport- |                 |  Fragment   |
              |   Layer     |      ===>       |   Header    |
              |   Header    |                 | (if needed) |
              +-------------+                 +-------------+
              |             |                 |  Transport- |
              ~    Data     ~                 |   Layer     |
              |             |                 |   Header    |
              +-------------+                 +-------------+
                                              |             |
                                              ~    Data     ~
                                              |             |
                                              +-------------+

Figure 2: IPv4-to-IPv6 Translation

図2：IPv4-to-IPv6変換

Path MTU discovery is mandatory in IPv6, but it is optional in IPv4. IPv6 routers never fragment a packet -- only the sender can do fragmentation.

パスMTUディスカバリーはIPv6では必須ですが、IPv4ではオプションです。 IPv6ルーターがパケットを断片化することはありません。断片化を実行できるのは送信者だけです。

When an IPv4 node performs path MTU discovery (by setting the Don't Fragment (DF) bit in the header), path MTU discovery can operate end-to-end, i.e., across the translator. In this case, either IPv4 or IPv6 routers (including the translator) might send back ICMP Packet Too Big messages to the sender. When the IPv6 routers send these ICMPv6 errors, they will pass through a translator that will translate the ICMPv6 error to a form that the IPv4 sender can understand. As a result, an IPv6 Fragment Header is only included if the IPv4 packet is already fragmented.

IPv4ノードがパスMTUディスカバリーを実行するとき（ヘッダーにDo n't Fragment（DF）ビットを設定することにより）、パスMTUディスカバリーはエンドツーエンドで、つまりトランスレーター全体で動作できます。この場合、IPv4またはIPv6ルーター（トランスレーターを含む）がICMPパケットが大きすぎるメッセージを送信者に送り返す可能性があります。 IPv6ルーターがこれらのICMPv6エラーを送信すると、ICMPv6エラーをIPv4送信者が理解できる形式に変換するトランスレーターを通過します。その結果、IPv6フラグメントヘッダーは、IPv4パケットがすでにフラグメント化されている場合にのみ含まれます。

However, when the IPv4 sender does not set the DF bit, the translator MUST ensure that the packet does not exceed the path MTU on the IPv6 side. This is done by fragmenting the IPv4 packet (with Fragment Headers) so that it fits in 1280-byte IPv6 packets, since that is the minimum IPv6 MTU. The IPv6 Fragment Header has been shown to cause operational difficulties in practice due to limited firewall fragmentation support, etc. In an environment where the network owned/operated by the same entity that owns/operates the translator, the translator MUST provide a configuration function for the network administrator to adjust the threshold of the minimum IPv6 MTU to a value that reflects the real value of the minimum IPv6 MTU in the network (greater than 1280 bytes). This will help reduce the chance of including the Fragment Header in the packets.

ただし、IPv4送信者がDFビットを設定しない場合、トランスレータは、パケットがIPv6側のパスMTUを超えないようにする必要があります。これは、IPv4パケット（フラグメントヘッダー付き）をフラグメント化して、1280バイトのIPv6パケットに収まるようにします。これは、IPv6 MTUが最小であるためです。 IPv6フラグメントヘッダーは、制限されたファイアウォールフラグメンテーションサポートなどにより、実際には操作上の問題を引き起こすことが示されています。トランスレーターを所有/操作するのと同じエンティティが所有/操作するネットワークでは、トランスレーターは設定機能を提供する必要があります。ネットワーク管理者は、最小IPv6 MTUのしきい値を、ネットワーク内の最小IPv6 MTUの実際の値（1280バイトを超える）を反映する値に調整します。これにより、フラグメントヘッダーがパケットに含まれる可能性が低くなります。

When the IPv4 sender does not set the DF bit, the translator MUST NOT include the Fragment Header for the non-fragmented IPv6 packets.

IPv4送信者がDFビットを設定しない場合、トランスレータは、フラグメント化されていないIPv6パケットのフラグメントヘッダーを含めてはなりません（MUST NOT）。

The rules in Section 4.1 ensure that when packets are fragmented, either by the sender or by IPv4 routers, the low-order 16 bits of the fragment identification are carried end-to-end, ensuring that packets are correctly reassembled.

セクション4.1のルールにより、送信者またはIPv4ルーターのいずれかによってパケットがフラグメント化されるときに、フラグメントIDの下位16ビットがエンドツーエンドで伝送され、パケットが正しく再構築されることが保証されます。

Other than the special rules for handling fragments and path MTU discovery, the actual translation of the packet header consists of a simple translation as defined below. Note that ICMPv4 packets require special handling in order to translate the content of ICMPv4 error messages and also to add the ICMPv6 pseudo-header checksum.

フラグメントとパスMTUディスカバリーを処理するための特別なルール以外に、パケットヘッダーの実際の変換は、以下に定義するような単純な変換で構成されます。 ICMPv4パケットは、ICMPv4エラーメッセージの内容を変換し、ICMPv6疑似ヘッダーチェックサムを追加するために、特別な処理を必要とすることに注意してください。

The translator SHOULD make sure that the packets belonging to the same flow leave the translator in the same order in which they arrived.

トランスレータは、同じフローに属するパケットが到着したのと同じ順序でトランスレータを出るようにする必要があります。

4.1. Translating IPv4 Headers into IPv6 Headers

4.1. IPv4ヘッダーをIPv6ヘッダーに変換する

If the DF flag is not set and the IPv4 packet will result in an IPv6 packet larger than a user-defined length (hereinafter referred to as "lowest-ipv6-mtu", and which defaults to 1280 bytes), the packet SHOULD be fragmented so that the resulting IPv6 packet (with Fragment Header added to each fragment) will be less than or equal to lowest-ipv6-mtu, For example, if the packet is fragmented prior to the translation, the IPv4 packets should be fragmented so that their length, excluding the IPv4 header, is at most 1232 bytes (1280 minus 40 for the IPv6 header and 8 for the Fragment Header). The translator MUST provide a configuration function for the network administrator to adjust the threshold of the minimum IPv6 MTU to a value greater than 1280 bytes if the real value of the minimum IPv6 MTU in the network is known to the administrator. The resulting fragments are then translated independently using the logic described below.

DFフラグが設定されておらず、IPv4パケットによってIPv6パケットがユーザー定義の長さ（以下、「最低ipv6-mtu」と呼ばれ、デフォルトでは1280バイト）を超える場合、パケットはフラグメント化する必要があります（SHOULD）その結果、（各フラグメントにフラグメントヘッダーが追加された）IPv6パケットは、lowest-ipv6-mtu以下になります。たとえば、変換前にパケットがフラグメント化されている場合、IPv4パケットはフラグメント化され、 IPv4ヘッダーを除く長さは、最大1232バイトです（IPv6ヘッダーの場合は1280マイナス40、フラグメントヘッダーの場合は8）。トランスレータは、ネットワーク内の最小IPv6 MTUの実際の値が管理者に知られている場合、ネットワーク管理者が最小IPv6 MTUのしきい値を1280バイトより大きい値に調整するための構成機能を提供する必要があります。結果のフラグメントは、次に説明するロジックを使用して個別に変換されます。

If the DF bit is set and the MTU of the next-hop interface is less than the total length value of the IPv4 packet plus 20, the translator MUST send an ICMPv4 "Fragmentation Needed" error message to the IPv4 source address.

DFビットが設定されており、ネクストホップインターフェイスのMTUがIPv4パケットの合計値に20を足した値よりも小さい場合、トランスレータはICMPv4 "Fragmentation Needed"エラーメッセージをIPv4送信元アドレスに送信する必要があります。

The IPv6 header fields are set as follows:

IPv6ヘッダーフィールドは次のように設定されます。

Version: 6

バージョン：6

Traffic Class: By default, copied from the IP Type Of Service (TOS) octet. According to [RFC2474], the semantics of the bits are identical in IPv4 and IPv6. However, in some IPv4 environments these fields might be used with the old semantics of "Type Of Service and Precedence". An implementation of a translator SHOULD support an administratively configurable option to ignore the IPv4 TOS and always set the IPv6 traffic class (TC) to zero. In addition, if the translator is at an administrative boundary, the filtering and update considerations of [RFC2475] may be applicable.

トラフィッククラス：デフォルトでは、IP Type Of Service（TOS）オクテットからコピーされます。 [RFC2474]によれば、ビットのセマンティクスはIPv4とIPv6で同一です。ただし、一部のIPv4環境では、これらのフィールドは「サービスの種類と優先順位」の古いセマンティクスで使用される場合があります。トランスレータの実装は、IPv4 TOSを無視し、IPv6トラフィッククラス（TC）を常にゼロに設定するための管理上構成可能なオプションをサポートする必要があります（SHOULD）。さらに、トランスレータが管理境界にある場合、[RFC2475]のフィルタリングおよび更新の考慮事項が適用される場合があります。

Flow Label: 0 (all zero bits)

フローラベル：0（すべてゼロのビット）

Payload Length: Total length value from the IPv4 header, minus the size of the IPv4 header and IPv4 options, if present.

ペイロード長：IPv4ヘッダーからの全長の長さの値から、存在する場合はIPv4ヘッダーとIPv4オプションのサイズを引いた値。

Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58); otherwise, the protocol field MUST be copied from the IPv4 header.

次のヘッダー：ICMPv4（1）の場合、ICMPv6（58）に変更されます。それ以外の場合、プロトコルフィールドはIPv4ヘッダーからコピーする必要があります。

Hop Limit: The hop limit is derived from the TTL value in the IPv4 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv4 TTL (before the translation) or the IPv6 Hop Limit (after the translation). As part of decrementing the TTL or Hop Limit, the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error.

ホップ制限：ホップ制限は、IPv4ヘッダーのTTL値から導出されます。トランスレータはルーターであるため、パケットの転送の一部として、IPv4 TTL（変換前）またはIPv6ホップ制限（変換後）のいずれかを減らす必要があります。 TTLまたはホップ制限のデクリメントの一環として、トランスレーター（ルーターとして）はゼロをチェックし、ICMPv4 "TTL Exceeded"またはICMPv6 "Hop Limit Exceeded"エラーを送信する必要があります。

Source Address: Mapped to an IPv6 address based on the algorithms presented in Section 6.

送信元アドレス：セクション6で提示されたアルゴリズムに基づいてIPv6アドレスにマッピングされます。

If the translator gets an illegal source address (e.g., 0.0.0.0, 127.0.0.1, etc.), the translator SHOULD silently discard the packet (as discussed in Section 5.3.7 of [RFC1812]). Note when translating ICMPv4 Error Messages into ICMPv6, the "illegal" source address will be translated for the purpose of trouble shooting.

トランスレータが不正なソースアドレス（0.0.0.0、127.0.0.1など）を取得した場合、トランスレータはパケットをサイレントに破棄する必要があります（[RFC1812]のセクション5.3.7で説明されています）。 ICMPv4エラーメッセージをICMPv6に変換する場合、「不正な」送信元アドレスはトラブルシューティングの目的で変換されます。

Destination Address: Mapped to an IPv6 address based on the algorithms presented in Section 6.

宛先アドレス：セクション6で提示されたアルゴリズムに基づいてIPv6アドレスにマッピングされます。

If any IPv4 options are present in the IPv4 packet, they MUST be ignored and the packet translated normally; there is no attempt to translate the options. However, if an unexpired source route option is present, then the packet MUST instead be discarded, and an ICMPv4 "Destination Unreachable, Source Route Failed" (Type 3, Code 5) error message SHOULD be returned to the sender.

IPv4パケットにIPv4オプションが存在する場合は、それらを無視して、パケットを正常に変換する必要があります。オプションを翻訳する試みはありません。ただし、有効期限が切れていないソースルートオプションが存在する場合は、代わりにパケットを破棄する必要があり、ICMPv4 "Destination Unreachable、Source Route Failed"（Type 3、Code 5）エラーメッセージを送信者に返す必要があります。

If there is a need to add a Fragment Header (the packet is a fragment or the DF bit is not set and the packet size is greater than the minimum IPv6 MTU in the network set by the translator configuration function), the header fields are set as above with the following exceptions:

フラグメントヘッダーを追加する必要がある場合（パケットがフラグメントであるか、DFビットが設定されておらず、パケットサイズがトランスレーター構成関数によって設定されたネットワークの最小IPv6 MTUより大きい場合）、ヘッダーフィールドが設定されます。上記と同じですが、次の例外があります。

IPv6 fields:

IPv6フィールド：

Payload Length: Total length value from the IPv4 header, plus 8 for the Fragment Header, minus the size of the IPv4 header and IPv4 options, if present.

ペイロードの長さ：IPv4ヘッダーの合計の長さの値、フラグメントヘッダーの8から、IPv4ヘッダーとIPv4オプション（存在する場合）のサイズを引いた値。

Next Header: Fragment Header (44).

次のヘッダー：フラグメントヘッダー（44）。

Fragment Header fields:

フラグメントヘッダーフィールド：

Next Header: For ICMPv4 (1), it is changed to ICMPv6 (58); otherwise, the protocol field MUST be copied from the IPv4 header.

Fragment Offset: Fragment Offset copied from the IPv4 header.

フラグメントオフセット：IPv4ヘッダーからコピーされたフラグメントオフセット。

M flag: More Fragments bit copied from the IPv4 header.

Mフラグ：IPv4ヘッダーからコピーされたその他のフラグメントビット。

Identification: The low-order 16 bits copied from the Identification field in the IPv4 header. The high-order 16 bits set to zero.

識別：IPv4ヘッダーの識別フィールドからコピーされた下位16ビット。ゼロに設定された上位16ビット。

4.2. Translating ICMPv4 Headers into ICMPv6 Headers

4.2. ICMPv4ヘッダーをICMPv6ヘッダーに変換する

All ICMPv4 messages that are to be translated require that the ICMPv6 checksum field be calculated as part of the translation since ICMPv6, unlike ICMPv4, has a pseudo-header checksum just like UDP and TCP.

ICMPv6は、ICMPv4とは異なり、UDPやTCPと同様に疑似ヘッダーチェックサムを持っているため、変換されるすべてのICMPv4メッセージでは、変換の一部としてICMPv6チェックサムフィールドを計算する必要があります。

In addition, all ICMPv4 packets MUST have the Type translated and, for ICMPv4 error messages, the included IP header also MUST be translated.

さらに、すべてのICMPv4パケットはTypeを変換する必要があり、ICMPv4エラーメッセージの場合、含まれるIPヘッダーも変換する必要があります。

The actions needed to translate various ICMPv4 messages are as follows:

さまざまなICMPv4メッセージを変換するために必要なアクションは次のとおりです。

ICMPv4 query messages:

ICMPv4クエリメッセージ：

Echo and Echo Reply (Type 8 and Type 0): Adjust the Type values to 128 and 129, respectively, and adjust the ICMP checksum both to take the type change into account and to include the ICMPv6 pseudo-header.

エコーおよびエコー応答（タイプ8およびタイプ0）：タイプの値をそれぞれ128および129に調整し、ICMPチェックサムを調整して、タイプの変更を考慮し、ICMPv6疑似ヘッダーを含めます。

Information Request/Reply (Type 15 and Type 16): Obsoleted in ICMPv6. Silently drop.

情報要求/応答（タイプ15およびタイプ16）：ICMPv6で廃止。静かに落とす。

Timestamp and Timestamp Reply (Type 13 and Type 14): Obsoleted in ICMPv6. Silently drop.

タイムスタンプとタイムスタンプ応答（タイプ13およびタイプ14）：ICMPv6で廃止されました。静かに落とす。

Address Mask Request/Reply (Type 17 and Type 18): Obsoleted in ICMPv6. Silently drop.

アドレスマスク要求/応答（タイプ17およびタイプ18）：ICMPv6で廃止されました。静かに落とす。

ICMP Router Advertisement (Type 9): Single-hop message. Silently drop.

ICMPルーターアドバタイズ（タイプ9）：シングルホップメッセージ。静かに落とす。

ICMP Router Solicitation (Type 10): Single-hop message. Silently drop.

ICMPルーター要請（タイプ10）：シングルホップメッセージ。静かに落とす。

Unknown ICMPv4 types: Silently drop.

不明なICMPv4タイプ：静かにドロップします。

IGMP messages: While the Multicast Listener Discovery (MLD) messages specified in [RFC2710], [RFC3590], and [RFC3810] are the logical IPv6 counterparts for the IPv4 IGMP messages, all the "normal" IGMP messages are single-hop messages and SHOULD be silently dropped by the translator. Other IGMP messages might be used by multicast routing protocols and, since it would be a configuration error to try to have router adjacencies across IP/ICMP translators, those packets SHOULD also be silently dropped.

IGMPメッセージ：[RFC2710]、[RFC3590]、および[RFC3810]で指定されたマルチキャストリスナーディスカバリ（MLD）メッセージは、IPv4 IGMPメッセージの論理IPv6の対応物ですが、すべての「通常の」IGMPメッセージはシングルホップメッセージであり、翻訳者が黙って落としてください。他のIGMPメッセージはマルチキャストルーティングプロトコルによって使用される可能性があり、IP / ICMPトランスレータ間でルータの隣接関係を確立しようとすると構成エラーになるため、これらのパケットも警告なしにドロップする必要があります。

ICMPv4 error messages:

ICMPv4エラーメッセージ：

Destination Unreachable (Type 3): Translate the Code as described below, set the Type to 1, and adjust the ICMP checksum both to take the type/code change into account and to include the ICMPv6 pseudo-header.

Destination Unreachable（Type 3）：コードを以下のように変換し、Typeを1に設定し、ICMPチェックサムを調整して、タイプ/コードの変更を考慮し、ICMPv6疑似ヘッダーを含めます。

Translate the Code as follows:

次のようにコードを翻訳します。

Code 0, 1 (Net Unreachable, Host Unreachable): Set the Code to 0 (No route to destination).

コード0、1（Net Unreachable、Host Unreachable）：コードを0（宛先へのルートなし）に設定します。

Code 2 (Protocol Unreachable): Translate to an ICMPv6 Parameter Problem (Type 4, Code 1) and make the Pointer point to the IPv6 Next Header field.

コード2（プロトコル到達不能）：ICMPv6パラメーター問題（タイプ4、コード1）に変換し、ポインターがIPv6次ヘッダーフィールドを指すようにします。

Code 3 (Port Unreachable): Set the Code to 4 (Port unreachable).

コード3（ポート到達不能）：コードを4（ポート到達不能）に設定します。

Code 4 (Fragmentation Needed and DF was Set): Translate to an ICMPv6 Packet Too Big message (Type 2) with Code set to 0. The MTU field MUST be adjusted for the difference between the IPv4 and IPv6 header sizes, but MUST NOT be set to a value smaller than the minimum IPv6 MTU (1280 bytes). That is, it should be set to

コード4（フラグメンテーションが必要で、DFが設定されている）：コードを0に設定して、ICMPv6パケットが大きすぎるメッセージ（タイプ2）に変換します。MTUフィールドは、IPv4とIPv6のヘッダーサイズの違いに合わせて調整する必要がありますが、最小IPv6 MTU（1280バイト）より小さい値に設定します。つまり、次のように設定する必要があります

maximum(1280, minimum((MTU value in the Packet Too Big Message) + 20, MTU_of_IPv6_nexthop, (MTU_of_IPv4_nexthop) + 20)).

maximum（1280、minimum（（Packet Too Big MessageのMTU値）+ 20、MTU_of_IPv6_nexthop、（MTU_of_IPv4_nexthop）+ 20））。

Note that if the IPv4 router set the MTU field to zero, i.e., the router does not implement [RFC1191], then the translator MUST use the plateau values specified in [RFC1191] to determine a likely path MTU and include that path MTU in the ICMPv6 packet. (Use the greatest plateau value that is less than the returned Total Length field, but that is larger than or equal to 1280.)

IPv4ルーターがMTUフィールドをゼロに設定した場合、つまりルーターが[RFC1191]を実装していない場合、トランスレーターは[RFC1191]で指定されたプラトー値を使用して、可能性のあるパスMTUを決定し、そのパスMTUをICMPv6パケット。（返された[全長]フィールドよりも小さいが、1280以上の最大のプラトー値を使用します。）

4.3. Translating ICMPv4 Error Messages into ICMPv6

4.3. ICMPv4エラーメッセージのICMPv6への変換

There are some differences between the ICMPv4 and the ICMPv6 error message formats as detailed above. The ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except the TTL value of the inner IPv4/IPv6 packet). If the translation of this "packet in error" changes the length of the datagram, the Total Length field in the outer IPv6 header MUST be updated.

上記のように、ICMPv4とICMPv6のエラーメッセージ形式にはいくつかの違いがあります。エラーのあるパケットを含むICMPエラーメッセージは、通常のIPパケットと同様に変換する必要があります（内部IPv4 / IPv6パケットのTTL値を除く）。この「エラーのあるパケット」の変換によってデータグラムの長さが変更される場合は、外部IPv6ヘッダーのTotal Lengthフィールドを更新する必要があります。

              +-------------+                 +-------------+
              |    IPv4     |                 |    IPv6     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |   ICMPv4    |                 |   ICMPv6    |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |    IPv4     |      ===>       |    IPv6     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |   Partial   |                 |   Partial   |
              |  Transport- |                 |  Transport- |
              |   Layer     |                 |   Layer     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+

Figure 4: IPv4-to-IPv6 ICMP Error Translation

図4：IPv4-to-IPv6 ICMPエラー変換

The translation of the inner IP header can be done by invoking the function that translated the outer IP headers. This process MUST stop at the first embedded header and drop the packet if it contains more embedded headers.

内部IPヘッダーの変換は、外部IPヘッダーを変換した関数を呼び出すことによって実行できます。このプロセスは、最初の埋め込みヘッダーで停止し、さらに埋め込みヘッダーが含まれている場合はパケットをドロップする必要があります。

4.4. Generation of ICMPv4 Error Message

4.4. ICMPv4エラーメッセージの生成

If the IPv4 packet is discarded, then the translator SHOULD be able to send back an ICMPv4 error message to the original sender of the packet, unless the discarded packet is itself an ICMPv4 error message. The ICMPv4 message, if sent, has a Type of 3 (Destination Unreachable) and a Code of 13 (Communication Administratively Prohibited), unless otherwise specified in this document or in [RFC6146]. The translator SHOULD allow an administrator to configure whether the ICMPv4 error messages are sent, rate-limited, or not sent.

IPv4パケットが破棄される場合、破棄されたパケット自体がICMPv4エラーメッセージでない限り、トランスレータはICMPv4エラーメッセージをパケットの元の送信者に返信できる必要があります（SHOULD）。 ICMPv4メッセージが送信される場合、このドキュメントまたは[RFC6146]で特に指定されていない限り、タイプ3（宛先到達不能）およびコード13（通信管理上禁止）が含まれます。トランスレータは、ICMPv4エラーメッセージを送信するか、レート制限するか、または送信しないかを管理者が設定できるようにする必要があります（SHOULD）。

4.5. Transport-Layer Header Translation

4.5. トランスポート層ヘッダー変換

If the address translation algorithm is not checksum neutral (see Section 4.1 of [RFC6052]), the recalculation and updating of the transport-layer headers that contain pseudo-headers need to be performed. Translators MUST do this for TCP and ICMP packets and for UDP packets that contain a UDP checksum (i.e., the UDP checksum field is not zero).

アドレス変換アルゴリズムがチェックサムニュートラルでない場合（[RFC6052]のセクション4.1を参照）、疑似ヘッダーを含むトランスポート層ヘッダーの再計算と更新を実行する必要があります。トランスレータは、TCPおよびICMPパケット、およびUDPチェックサムを含むUDPパケット（つまり、UDPチェックサムフィールドがゼロではない）に対してこれを実行する必要があります。

For UDP packets that do not contain a UDP checksum (i.e., the UDP checksum field is zero), the translator SHOULD provide a configuration function to allow: 1. Dropping the packet and generating a system management event that specifies at least the IP addresses and port numbers of the packet.

UDPチェックサムを含まない（つまり、UDPチェックサムフィールドがゼロである）UDPパケットの場合、トランスレータは、以下を可能にする構成機能を提供する必要があります。1.パケットをドロップし、少なくともIPアドレスを指定するシステム管理イベントを生成し、パケットのポート番号。

2. Calculating an IPv6 checksum and forwarding the packet (which has performance implications).

2. IPv6チェックサムを計算し、パケットを転送します（パフォーマンスに影響があります）。

A stateless translator cannot compute the UDP checksum of fragmented packets, so when a stateless translator receives the first fragment of a fragmented UDP IPv4 packet and the checksum field is zero, the translator SHOULD drop the packet and generate a system management event that specifies at least the IP addresses and port numbers in the packet.

ステートレストランスレーターはフラグメント化されたパケットのUDPチェックサムを計算できないため、ステートレストランスレーターがフラグメント化されたUDP IPv4パケットの最初のフラグメントを受信し、チェックサムフィールドがゼロの場合、トランスレーターはパケットをドロップし、少なくとも指定するシステム管理イベントを生成する必要があります（SHOULD）。パケットのIPアドレスとポート番号。

For a stateful translator, the handling of fragmented UDP IPv4 packets with a zero checksum is discussed in [RFC6146], Section 3.4.

ステートフルトランスレータの場合、チェックサムがゼロのフラグメント化されたUDP IPv4パケットの処理については、[RFC6146]のセクション3.4で説明しています。

Other transport protocols (e.g., the Datagram Congestion Control Protocol (DCCP)) are OPTIONAL to support. In order to ease debugging and troubleshooting, translators MUST forward all transport protocols as described in the "Next Header" step of Section 4.1.

その他のトランスポートプロトコル（データグラム輻輳制御プロトコル（DCCP）など）は、サポートするオプションです。デバッグとトラブルシューティングを容易にするために、トランスレータは、セクション4.1の「次のヘッダー」ステップで説明されているように、すべてのトランスポートプロトコルを転送する必要があります。

4.6. Knowing When to Translate

4.6. 翻訳するタイミングを知る

If the IP/ICMP translator also provides a normal forwarding function, and the destination IPv4 address is reachable by a more specific route without translation, the translator MUST forward it without translating it. Otherwise, when an IP/ICMP translator receives an IPv4 datagram addressed to an IPv4 destination representing a host in the IPv6 domain, the packet MUST be translated to IPv6.

IP / ICMPトランスレータも通常の転送機能を提供し、宛先IPv4アドレスが変換なしでより特定のルートによって到達可能な場合、トランスレータはそれを変換せずに転送する必要があります。そうでない場合、IP / ICMPトランスレータがIPv6ドメイン内のホストを表すIPv4宛先にアドレス指定されたIPv4データグラムを受信すると、パケットはIPv6に変換される必要があります。

5. Translating from IPv6 to IPv4

5. IPv6からIPv4への変換

When an IP/ICMP translator receives an IPv6 datagram addressed to a destination towards the IPv4 domain, it translates the IPv6 header of the received IPv6 packet into an IPv4 header. The original IPv6 header on the packet is removed and replaced by an IPv4 header. Since the ICMPv6 [RFC4443], TCP [RFC793], UDP [RFC768], and DCCP [RFC4340] headers contain checksums that cover the IP header, if the address mapping algorithm is not checksum neutral, the checksum MUST be evaluated before translation and the ICMP and transport-layer headers MUST be updated. The data portion of the packet is left unchanged. The IP/ICMP translator then forwards the packet based on the IPv4 destination address.

IP / ICMPトランスレータは、IPv4ドメインへの宛先にアドレス指定されたIPv6データグラムを受信すると、受信したIPv6パケットのIPv6ヘッダーをIPv4ヘッダーに変換します。パケットの元のIPv6ヘッダーは削除され、IPv4ヘッダーに置き換えられます。 ICMPv6 [RFC4443]、TCP [RFC793]、UDP [RFC768]、およびDCCP [RFC4340]ヘッダーにはIPヘッダーをカバーするチェックサムが含まれているため、アドレスマッピングアルゴリズムがチェックサムニュートラルでない場合、変換前にチェックサムを評価し、 ICMPおよびトランスポート層ヘッダーを更新する必要があります。パケットのデータ部分は変更されません。次に、IP / ICMPトランスレータは、IPv4宛先アドレスに基づいてパケットを転送します。

              +-------------+                 +-------------+
              |    IPv6     |                 |    IPv4     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |  Fragment   |                 |  Transport  |
              |   Header    |      ===>       |   Layer     |
              |(if present) |                 |   Header    |
              +-------------+                 +-------------+
              |  Transport  |                 |             |
              |   Layer     |                 ~    Data     ~
              |   Header    |                 |             |
              +-------------+                 +-------------+
              |             |
              ~    Data     ~
              |             |
              +-------------+

Figure 5: IPv6-to-IPv4 Translation

図5：IPv6-to-IPv4変換

There are some differences between IPv6 and IPv4 (in the areas of fragmentation and the minimum link MTU) that affect the translation. An IPv6 link has to have an MTU of 1280 bytes or greater. The corresponding limit for IPv4 is 68 bytes. Path MTU discovery across a translator relies on ICMP Packet Too Big messages being received and processed by IPv6 hosts.

IPv6とIPv4の間には、（フラグメンテーションと最小リンクMTUの領域で）変換に影響するいくつかの違いがあります。 IPv6リンクには、1280バイト以上のMTUが必要です。 IPv4の対応する制限は68バイトです。トランスレータ全体のパスMTUディスカバリは、IPv6ホストによって受信および処理されるICMPパケットが大きすぎるメッセージに依存しています。

The difference in the minimum MTUs of IPv4 and IPv6 is accommodated as follows:

IPv4とIPv6の最小MTUの違いは、次のように調整されます。

o When translating an ICMPv4 "Fragmentation Needed" packet, the indicated MTU in the resulting ICMPv6 "Packet Too Big" will never be set to a value lower than 1280. This ensures that the IPv6 nodes will never have to encounter or handle Path MTU values lower than the minimum IPv6 link MTU of 1280. See Section 4.2.

o ICMPv4「断片化が必要」パケットを変換するとき、結果のICMPv6「パケットが大きすぎます」で示されているMTUが1280未満の値に設定されることはありません。これにより、IPv6ノードがパスMTU値に遭遇したり、処理したりする必要がなくなります。 1280の最小IPv6リンクMTUよりも大きい。セクション4.2を参照。

o When the resulting IPv4 packet is smaller than or equal to 1260 bytes, the translator MUST send the packet with a cleared Don't Fragment bit. Otherwise, the packet MUST be sent with the Don't Fragment bit set. See Section 5.1.

o 結果のIPv4パケットが1260バイト以下の場合、トランスレータは、Do n't Fragmentビットがクリアされたパケットを送信する必要があります。それ以外の場合、パケットはDo n't Fragmentビットを設定して送信する必要があります。セクション5.1を参照してください。

This approach allows Path MTU Discovery to operate end-to-end for paths whose MTU are not smaller than the minimum IPv6 MTU of 1280 (which corresponds to an MTU of 1260 in the IPv4 domain). On paths that have IPv4 links with MTU < 1260, the IPv4 router(s) connected to those links will fragment the packets in accordance with Section 2.3 of [RFC791].

このアプローチにより、パスMTUディスカバリーは、MTUが最小IPv6 MTUの1280（IPv4ドメインの1260のMTUに対応する）より小さくないパスに対してエンドツーエンドで動作することができます。 MTUが1260未満のIPv4リンクを持つパスでは、それらのリンクに接続されたIPv4ルーターは、[RFC791]のセクション2.3に従ってパケットをフラグメント化します。

Other than the special rules for handling fragments and path MTU discovery, the actual translation of the packet header consists of a simple translation as defined below. Note that ICMPv6 packets require special handling in order to translate the contents of ICMPv6 error messages and also to remove the ICMPv6 pseudo-header checksum.

フラグメントとパスMTUディスカバリーを処理するための特別なルール以外に、パケットヘッダーの実際の変換は、以下に定義するような単純な変換で構成されます。 ICMPv6エラーメッセージの内容を変換し、ICMPv6疑似ヘッダーチェックサムを削除するには、ICMPv6パケットに特別な処理が必要であることに注意してください。

The translator SHOULD make sure that the packets belonging to the same flow leave the translator in the same order in which they arrived.

トランスレータは、同じフローに属するパケットが到着したのと同じ順序でトランスレータを出るようにする必要があります。

5.1. Translating IPv6 Headers into IPv4 Headers

5.1. IPv6ヘッダーをIPv4ヘッダーに変換する

If there is no IPv6 Fragment Header, the IPv4 header fields are set as follows:

IPv6フラグメントヘッダーがない場合、IPv4ヘッダーフィールドは次のように設定されます。

Version: 4

バージョン：4

Internet Header Length: 5 (no IPv4 options)

インターネットヘッダー長：5（IPv4オプションなし）

Type of Service (TOS) Octet: By default, copied from the IPv6 Traffic Class (all 8 bits). According to [RFC2474], the semantics of the bits are identical in IPv4 and IPv6. However, in some IPv4 environments, these bits might be used with the old semantics of "Type Of Service and Precedence". An implementation of a translator SHOULD provide the ability to ignore the IPv6 traffic class and always set the IPv4 TOS Octet to a specified value. In addition, if the translator is at an administrative boundary, the filtering and update considerations of [RFC2475] may be applicable.

Type of Service（TOS）Octet：デフォルトでは、IPv6トラフィッククラス（すべて8ビット）からコピーされます。 [RFC2474]によれば、ビットのセマンティクスはIPv4とIPv6で同一です。ただし、一部のIPv4環境では、これらのビットは「サービスの種類と優先順位」の古いセマンティクスで使用される場合があります。トランスレータの実装は、IPv6トラフィッククラスを無視し、常にIPv4 TOSオクテットを指定された値に設定する機能を提供する必要があります（SHOULD）。さらに、トランスレータが管理境界にある場合、[RFC2475]のフィルタリングおよび更新の考慮事項が適用される場合があります。

Total Length: Payload length value from the IPv6 header, plus the size of the IPv4 header.

全長：IPv6ヘッダーからのペイロードの長さの値と、IPv4ヘッダーのサイズ。

Identification: Set according to a Fragment Identification generator at the translator.

識別：トランスレーターのフラグメント識別ジェネレーターに従って設定します。

Flags: The More Fragments flag is set to zero. The Don't Fragment (DF) flag is set as follows: If the size of the translated IPv4 packet is less than or equal to 1260 bytes, it is set to zero; otherwise, it is set to one.

フラグ：More Fragmentsフラグはゼロに設定されます。フラグメント禁止（DF）フラグは次のように設定されます。変換されたIPv4パケットのサイズが1260バイト以下の場合、ゼロに設定されます。それ以外の場合は、1に設定されます。

Fragment Offset: All zeros.

フラグメントオフセット：すべてゼロ。

Time to Live: Time to Live is derived from the Hop Limit value in the IPv6 header. Since the translator is a router, as part of forwarding the packet it needs to decrement either the IPv6 Hop Limit (before the translation) or the IPv4 TTL (after the translation). As part of decrementing the TTL or Hop Limit, the translator (as any router) MUST check for zero and send the ICMPv4 "TTL Exceeded" or ICMPv6 "Hop Limit Exceeded" error.

存続時間：存続時間は、IPv6ヘッダーのホップ制限値から導出されます。トランスレータはルーターであるため、パケットの転送の一部として、IPv6ホップ制限（変換前）またはIPv4 TTL（変換後）のいずれかを減らす必要があります。 TTLまたはホップ制限のデクリメントの一環として、トランスレーター（ルーターとして）はゼロをチェックし、ICMPv4 "TTL Exceeded"またはICMPv6 "Hop Limit Exceeded"エラーを送信する必要があります。

Protocol: The IPv6-Frag (44) header is handled as discussed in Section 5.1.1. ICMPv6 (58) is changed to ICMPv4 (1), and the payload is translated as discussed in Section 5.2. The IPv6 headers HOPOPT (0), IPv6-Route (43), and IPv6-Opts (60) are skipped over during processing as they have no meaning in IPv4. For the first 'next header' that does not match one of the cases above, its Next Header value (which contains the transport protocol number) is copied to the protocol field in the IPv4 header. This means that all transport protocols are translated.

プロトコル：IPv6-Frag（44）ヘッダーは、セクション5.1.1で説明されているように処理されます。 ICMPv6（58）はICMPv4（1）に変更され、ペイロードはセクション5.2で説明されているように変換されます。 IPv6ヘッダーHOPOPT（0）、IPv6-Route（43）、およびIPv6-Opts（60）は、IPv4では意味がないため、処理中にスキップされます。上記のいずれのケースとも一致しない最初の「次のヘッダー」については、その次のヘッダー値（トランスポートプロトコル番号を含む）がIPv4ヘッダーのプロトコルフィールドにコピーされます。つまり、すべてのトランスポートプロトコルが変換されます。

Note: Some translated protocols will fail at the receiver for various reasons: some are known to fail when translated (e.g., IPsec Authentication Header (51)), and others will fail checksum validation if the address translation is not checksum neutral [RFC6052] and the translator does not update the transport protocol's checksum (because the translator doesn't support recalculating the checksum for that transport protocol; see Section 5.5).

注：変換されたプロトコルには、さまざまな理由で受信側で失敗するものがあります。変換時に失敗することがわかっているもの（IPsec認証ヘッダー（51）など）と、アドレス変換がチェックサムニュートラルでない場合（RFC6052）およびトランスレータはトランスポートプロトコルのチェックサムを更新しません（トランスレータはそのトランスポートプロトコルのチェックサムの再計算をサポートしていないため、セクション5.5を参照してください）。

Header Checksum: Computed once the IPv4 header has been created.

ヘッダーチェックサム：IPv4ヘッダーが作成されると計算されます。

Source Address: Mapped to an IPv4 address based on the algorithms presented in Section 6.

送信元アドレス：セクション6で提示されたアルゴリズムに基づいてIPv4アドレスにマッピングされます。

If the translator gets an illegal source address (e.g., ::1, etc.), the translator SHOULD silently drop the packet.

トランスレータが不正なソースアドレス（例::: 1など）を取得した場合、トランスレータはパケットをサイレントにドロップする必要があります（SHOULD）。

Destination Address: Mapped to an IPv4 address based on the algorithms presented in Section 6.

宛先アドレス：セクション6で提示されたアルゴリズムに基づいてIPv4アドレスにマッピングされます。

If any of an IPv6 Hop-by-Hop Options header, Destination Options header, or Routing header with the Segments Left field equal to zero are present in the IPv6 packet, those IPv6 extension headers MUST be ignored (i.e., there is no attempt to translate the extension headers) and the packet translated normally. However, the Total Length field and the Protocol field are adjusted to "skip" these extension headers.

IPv6ホップバイホップオプションヘッダー、宛先オプションヘッダー、またはゼロに等しい左セグメントセグメントを持つルーティングヘッダーのいずれかがIPv6パケットに存在する場合、それらのIPv6拡張ヘッダーは無視する必要があります（つまり、拡張ヘッダーを変換します）、パケットは通常に変換されます。ただし、全長フィールドとプロトコルフィールドは、これらの拡張ヘッダーを「スキップ」するように調整されています。

If a Routing header with a non-zero Segments Left field is present, then the packet MUST NOT be translated, and an ICMPv6 "parameter problem/erroneous header field encountered" (Type 4, Code 0) error message, with the Pointer field indicating the first byte of the Segments Left field, SHOULD be returned to the sender.

ゼロ以外のセグメントの左フィールドを持つルーティングヘッダーが存在する場合、パケットは変換してはならず、ICMPv6「パラメータの問題/エラーのあるヘッダーフィールドが検出されました」（タイプ4、コード0）エラーメッセージ、ポインタフィールドが示すSegments Leftフィールドの最初のバイト。送信者に返される必要があります（SHOULD）。

5.1.1. IPv6 Fragment Processing

5.1.1. IPv6フラグメント処理

If the IPv6 packet contains a Fragment Header, the header fields are set as above with the following exceptions:

IPv6パケットにフラグメントヘッダーが含まれている場合、ヘッダーフィールドは上記のように設定されますが、次の例外があります。

Total Length: If the Next Header field of the Fragment Header is an extension header (except ESP, but including the Authentication Header (AH)), then the packet SHOULD be dropped and logged. For other cases, the Total Length MUST be set to Payload Length value from IPv6 header, minus the length of the extension headers up to the Fragmentation Header, minus 8 for the Fragment Header, plus the size of the IPv4 header.

全長：フラグメントヘッダーの次のヘッダーフィールドが拡張ヘッダー（ESPを除くが、認証ヘッダー（AH）を含む）の場合、パケットをドロップしてログに記録する必要があります（SHOULD）。その他の場合、Total Lengthは、IPv6ヘッダーからのペイロード長の値から、フラグメンテーションヘッダーまでの拡張ヘッダーの長さを差し引いた値から、フラグメントヘッダーの8を引いた値、およびIPv4ヘッダーのサイズに設定する必要があります。

Identification: Copied from the low-order 16 bits in the Identification field in the Fragment Header.

識別：フラグメントヘッダーの識別フィールドの下位16ビットからコピーされます。

Flags: The IPv4 More Fragments (MF) flag is copied from the M flag in the IPv6 Fragment Header. The IPv4 Don't Fragment (DF) flag is cleared (set to zero), allowing this packet to be further fragmented by IPv4 routers.

フラグ：IPv4 More Fragments（MF）フラグは、IPv6 FragmentヘッダーのMフラグからコピーされます。 IPv4 Do n't Fragment（DF）フラグがクリア（ゼロに設定）されているため、このパケットをIPv4ルーターでさらにフラグメント化できます。

Fragment Offset: If the Next Header field of the Fragment Header is not an extension header (except ESP), then Fragment Offset MUST be copied from the Fragment Offset field of the IPv6 Fragment Header. If the Next Header field of the Fragment Header is an extension header (except ESP), then the packet SHOULD be dropped and logged.

フラグメントオフセット：フラグメントヘッダーの次のヘッダーフィールドが拡張ヘッダーでない場合（ESPを除く）、フラグメントオフセットはIPv6フラグメントヘッダーのフラグメントオフセットフィールドからコピーする必要があります。フラグメントヘッダーの次のヘッダーフィールドが拡張ヘッダー（ESPを除く）の場合、パケットはドロップされてログに記録される必要があります（SHOULD）。

Protocol: For ICMPv6 (58), it is changed to ICMPv4 (1); otherwise, extension headers are skipped, and the Next Header field is copied from the last IPv6 header.

プロトコル：ICMPv6（58）の場合、ICMPv4（1）に変更されます。それ以外の場合、拡張ヘッダーはスキップされ、次のヘッダーフィールドは最後のIPv6ヘッダーからコピーされます。

If an IPv6 packet that is smaller than or equal to 1280 bytes results (after translation) in an IPv4 packet that is larger than the MTU of the next-hop interface, then the translator MUST perform IPv4 fragmentation on that packet such that it can be transferred over the constricting link.

1280バイト以下のIPv6パケットの結果（変換後）がネクストホップインターフェイスのMTUより大きいIPv4パケットになる場合、トランスレータはそのパケットに対してIPv4フラグメンテーションを実行して、収縮リンクを介して転送されます。

5.2. Translating ICMPv6 Headers into ICMPv4 Headers

5.2. ICMPv6ヘッダーをICMPv4ヘッダーに変換する

If a non-checksum-neutral translation address is being used, ICMPv6 messages MUST have their ICMPv4 checksum field be updated as part of the translation since ICMPv6 (unlike ICMPv4) includes a pseudo-header in the checksum just like UDP and TCP.

非チェックサムニュートラル変換アドレスが使用されている場合、ICMPv6（ICMPv4とは異なります）はUDPおよびTCPと同様にチェックサムに疑似ヘッダーを含むため、ICMPv6メッセージは変換の一部としてICMPv4チェックサムフィールドを更新する必要があります。

In addition, all ICMP packets MUST have the Type translated and, for ICMP error messages, the included IP header MUST also be translated.

さらに、すべてのICMPパケットはTypeを変換する必要があり、ICMPエラーメッセージの場合、含まれるIPヘッダーも変換する必要があります。

The actions needed to translate various ICMPv6 messages are:

さまざまなICMPv6メッセージを変換するために必要なアクションは次のとおりです。

ICMPv6 informational messages:

ICMPv6情報メッセージ：

Echo Request and Echo Reply (Type 128 and 129): Adjust the Type values to 8 and 0, respectively, and adjust the ICMP checksum both to take the type change into account and to exclude the ICMPv6 pseudo-header.

エコー要求とエコー応答（タイプ128と129）：タイプ値をそれぞれ8と0に調整し、ICMPチェックサムを調整して、タイプの変更を考慮し、ICMPv6疑似ヘッダーを除外します。

MLD Multicast Listener Query/Report/Done (Type 130, 131, 132): Single-hop message. Silently drop.

MLDマルチキャストリスナークエリ/レポート/完了（タイプ130、131、132）：シングルホップメッセージ。静かに落とす。

Neighbor Discover messages (Type 133 through 137): Single-hop message. Silently drop.

近隣探索メッセージ（タイプ133から137）：シングルホップメッセージ。静かに落とす。

Unknown informational messages: Silently drop.

不明な情報メッセージ：静かにドロップします。

ICMPv6 error messages:

ICMPv6エラーメッセージ：

Destination Unreachable (Type 1) Set the Type to 3, and adjust the ICMP checksum both to take the type/code change into account and to exclude the ICMPv6 pseudo-header.

Destination Unreachable（Type 1）Typeを3に設定し、ICMPチェックサムを調整して、タイプ/コードの変更を考慮し、ICMPv6疑似ヘッダーを除外します。

Translate the Code as follows:

次のようにコードを翻訳します。

Code 0 (No route to destination): Set the Code to 1 (Host unreachable).

コード0（宛先へのルートなし）：コードを1（ホスト到達不能）に設定します。

Code 1 (Communication with destination administratively prohibited): Set the Code to 10 (Communication with destination host administratively prohibited).

コード1（宛先との通信は管理上禁止）：コードを10（宛先ホストとの通信は管理上禁止）に設定します。

Code 2 (Beyond scope of source address): Set the Code to 1 (Host unreachable). Note that this error is very unlikely since an IPv4-translatable source address is typically considered to have global scope.

コード2（送信元アドレスの範囲を超える）：コードを1（ホスト到達不能）に設定します。 IPv4で変換可能な送信元アドレスは通常グローバルスコープを持つと見なされるため、このエラーはほとんど発生しないことに注意してください。

Code 3 (Address unreachable): Set the Code to 1 (Host unreachable).

コード3（アドレス到達不能）：コードを1（ホスト到達不能）に設定します。

Code 4 (Port unreachable): Set the Code to 3 (Port unreachable).

コード4（ポート到達不能）：コードを3（ポート到達不能）に設定します。

Other Code values: Silently drop.

その他のコード値：静かに低下します。

Packet Too Big (Type 2): Translate to an ICMPv4 Destination Unreachable (Type 3) with Code 4, and adjust the ICMPv4 checksum both to take the type change into account and to exclude the ICMPv6 pseudo-header. The MTU field MUST be adjusted for the difference between the IPv4 and IPv6 header sizes, taking into account whether or not the packet in error includes a Fragment Header, i.e., minimum((MTU value in the Packet Too Big Message)-20, MTU_of_IPv4_nexthop, (MTU_of_IPv6_nexthop)-20).

パケットが大きすぎます（タイプ2）：コード4でICMPv4宛先到達不能（タイプ3）に変換し、ICMPv4チェックサムを調整して、タイプの変更を考慮し、ICMPv6疑似ヘッダーを除外します。 MTUフィールドは、エラーのあるパケットにフラグメントヘッダーが含まれているかどうかを考慮して、IPv4とIPv6のヘッダーサイズの違いに合わせて調整する必要があります。つまり、minimum（（Packet Too Big MessageのMTU値）-20、MTU_of_IPv4_nexthop 、（MTU_of_IPv6_nexthop）-20）。

5.3. Translating ICMPv6 Error Messages into ICMPv4

5.3. ICMPv6エラーメッセージのICMPv4への変換

There are some differences between the ICMPv4 and the ICMPv6 error message formats as detailed above. The ICMP error messages containing the packet in error MUST be translated just like a normal IP packet (except that the TTL/Hop Limit value of the inner IPv4/IPv6 packet are not decremented). The translation of this "packet in error" is likely to change the length of the datagram; thus, the Total Length field in the outer IPv4 header MUST be updated.

上記のように、ICMPv4とICMPv6のエラーメッセージ形式にはいくつかの違いがあります。エラーのあるパケットを含むICMPエラーメッセージは、通常のIPパケットと同じように変換する必要があります（ただし、内部IPv4 / IPv6パケットのTTL /ホップ制限値が減分されない点が異なります）。この「エラーのあるパケット」の変換により、データグラムの長さが変わる可能性があります。したがって、外部IPv4ヘッダーのTotal Lengthフィールドを更新する必要があります。

              +-------------+                 +-------------+
              |    IPv6     |                 |    IPv4     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |   ICMPv6    |                 |   ICMPv4    |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |    IPv6     |      ===>       |    IPv4     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+
              |   Partial   |                 |   Partial   |
              |  Transport- |                 |  Transport- |
              |   Layer     |                 |   Layer     |
              |   Header    |                 |   Header    |
              +-------------+                 +-------------+

Figure 7: IPv6-to-IPv4 ICMP Error Translation

図7：IPv6-to-IPv4 ICMPエラー変換

5.4. Generation of ICMPv6 Error Messages

5.4. ICMPv6エラーメッセージの生成

If the IPv6 packet is discarded, then the translator SHOULD send back an ICMPv6 error message to the original sender of the packet, unless the discarded packet is itself an ICMPv6 message.

IPv6パケットが破棄された場合、破棄されたパケット自体がICMPv6メッセージでない限り、トランスレータはICMPv6エラーメッセージをパケットの元の送信者に送信する必要があります（SHOULD）。

The ICMPv6 message MUST have Type 1 (Destination Unreachable) and Code 1 (Communication with destination administratively prohibited), unless otherwise specified in this document or [RFC6146]. The translator SHOULD allow an administrator to configure whether the ICMPv6 error messages are sent, rate-limited, or not sent.

このドキュメントまたは[RFC6146]で特に指定されていない限り、ICMPv6メッセージには、タイプ1（宛先到達不能）およびコード1（管理上禁止された宛先との通信）が必要です。トランスレータは、管理者がICMPv6エラーメッセージを送信するか、レート制限するか、送信しないかを構成できるようにする必要があります（SHOULD）。

5.5. Transport-Layer Header Translation

5.5. トランスポート層ヘッダー変換

アドレス変換アルゴリズムがチェックサムニュートラルでない場合（[RFC6052]のセクション4.1を参照）、疑似ヘッダーを含むトランスポート層ヘッダーの再計算と更新を実行する必要があります。トランスレータは、TCP、UDP、およびICMPに対してこれを行う必要があります。

Other transport protocols (e.g., DCCP) are OPTIONAL to support. In order to ease debugging and troubleshooting, translators MUST forward all transport protocols as described in the "Protocol" step of Section 5.1.

他のトランスポートプロトコル（DCCPなど）はオプションでサポートされます。デバッグとトラブルシューティングを容易にするために、トランスレータは、セクション5.1の「プロトコル」ステップで説明されているように、すべてのトランスポートプロトコルを転送する必要があります。

5.6. Knowing When to Translate

5.6. 翻訳するタイミングを知る

If the IP/ICMP translator also provides a normal forwarding function, and the destination address is reachable by a more specific route without translation, the router MUST forward it without translating it. When an IP/ICMP translator receives an IPv6 datagram addressed to an IPv6 address representing a host in the IPv4 domain, the IPv6 packet MUST be translated to IPv4.

IP / ICMPトランスレータが通常の転送機能も提供し、宛先アドレスが変換なしでより具体的なルートによって到達可能な場合、ルータはそれを変換せずに転送する必要があります。 IP / ICMPトランスレータが、IPv4ドメイン内のホストを表すIPv6アドレスにアドレス指定されたIPv6データグラムを受信した場合、IPv6パケットはIPv4に変換される必要があります。

6. Mapping of IP Addresses

6. IPアドレスのマッピング

The translator MUST support the stateless address mapping algorithm defined in [RFC6052], which is the default behavior. A workflow example is shown in Appendix A of this document. Note that [RFC7136] updates [RFC4291], which allows the use of unicast addresses without u-bit, as long as they're not derived from an IEEE MAC-layer address. Therefore, the address mapping algorithm defined in [RFC6219] also complies with the IPv6 address architecture.

トランスレータは、[RFC6052]で定義されているステートレスアドレスマッピングアルゴリズムをサポートする必要があります。これはデフォルトの動作です。ワークフローの例は、このドキュメントの付録Aに示されています。 [RFC7136]は[RFC4291]を更新することに注意してください。これにより、IEEE MAC層アドレスから派生していない限り、uビットなしでユニキャストアドレスを使用できます。したがって、[RFC6219]で定義されているアドレスマッピングアルゴリズムもIPv6アドレスアーキテクチャに準拠しています。

The stateless translator SHOULD support the explicit address mapping algorithm defined in [RFC7757].

ステートレストランスレータは、[RFC7757]で定義されている明示的なアドレスマッピングアルゴリズムをサポートする必要があります（SHOULD）。

The stateless translator SHOULD support [RFC6791] for handling ICMP/ ICMPv6 packets.

ステートレストランスレータは、ICMP / ICMPv6パケットを処理するために[RFC6791]をサポートする必要があります（SHOULD）。

Implementations may support both stateless and stateful translation modes (e.g., Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers (NAT64) [RFC6146]).

実装は、ステートレスとステートフルの両方の変換モードをサポートする場合があります（たとえば、IPv6クライアントからIPv4サーバー（NAT64）へのネットワークアドレスおよびプロトコル変換[RFC6146]）。

Implementations may support stateless NAT64 function, e.g., MAP-T Customer Edge (CE) or MAP-T Border Relay (BR) [RFC7599].

実装は、ステートレスNAT64機能、たとえばMAP-Tカスタマーエッジ（CE）またはMAP-Tボーダーリレー（BR）[RFC7599]をサポートする場合があります。

7. Special Considerations for ICMPv6 Packet Too Big

7. ICMPv6パケットが大きすぎる場合の特別な考慮事項

A number of studies [ATOMIC] indicate that it not unusual for networks to drop ICMPv6 Packet Too Big error messages. Such packet drops will result in PMTUD black holes [RFC2923], which can only be overcome with Packetization Layer Path MTU Discovery (PLPMTUD) [RFC4821].

多くの調査[ATOMIC]は、ネットワークがICMPv6 Packet Too Bigエラーメッセージをドロップすることは珍しいことではないことを示しています。このようなパケットドロップは、PMTUDブラックホール[RFC2923]を引き起こします。これは、Packetization Layer Path MTU Discovery（PLPMTUD）[RFC4821]でのみ克服できます。

8. Security Considerations

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

The use of stateless IP/ICMP translators does not introduce any new security issues beyond the security issues that are already present in the IPv4 and IPv6 protocols and in the routing protocols that are used to make the packets reach the translator.

ステートレスIP / ICMPトランスレータを使用しても、IPv4およびIPv6プロトコルと、パケットをトランスレータに到達させるために使用されるルーティングプロトコルにすでに存在するセキュリティ問題以外に、新しいセキュリティ問題は発生しません。

There are potential issues that might arise by deriving an IPv4 address from an IPv6 address -- particularly addresses like broadcast or loopback addresses and the non-IPv4-translatable IPv6 addresses, etc. [RFC6052] addresses these issues.

IPv6アドレスからIPv4アドレスを取得することによって発生する可能性のある問題があります。特に、ブロードキャストアドレスやループバックアドレス、IPv4で変換できないIPv6アドレスなどのアドレスです。[RFC6052]はこれらの問題に対処しています。

The IPsec Authentication Header [RFC4302] cannot be used for NAT44 or NAT64.

IPsec認証ヘッダー[RFC4302]は、NAT44またはNAT64には使用できません。

As with the network address translation of IPv4 to IPv4, packets with tunnel mode Encapsulating Security Payload (ESP) can be translated since tunnel mode ESP does not depend on header fields prior to the ESP header. Similarly, transport mode ESP will fail with IPv6-to-IPv4 translation unless checksum-neutral addresses are used. In both cases, the IPsec ESP endpoints will normally detect the presence of the translator and encapsulate ESP in UDP packets [RFC3948].

IPv4からIPv4へのネットワークアドレス変換と同様に、トンネルモードのESPはESPヘッダーの前のヘッダーフィールドに依存しないため、トンネルモードのカプセル化セキュリティペイロード（ESP）のパケットを変換できます。同様に、トランスポートモードESPは、チェックサムニュートラルアドレスが使用されない限り、IPv6-to-IPv4変換で失敗します。どちらの場合も、IPsec ESPエンドポイントは通常、トランスレータの存在を検出し、ESPをUDPパケットにカプセル化します[RFC3948]。

9. References

9. 参考文献

9.1. Normative References

9.1. 引用文献

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

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

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

[RFC1812] Baker, F., Ed., "Requirements for IP Version 4 Routers", RFC 1812, DOI 10.17487/RFC1812, June 1995, <http://www.rfc-editor.org/info/rfc1812>.

[RFC1812]ベイカー、F。、編、「IPバージョン4ルーターの要件」、RFC 1812、DOI 10.17487 / RFC1812、1995年6月、<http://www.rfc-editor.org/info/rfc1812>。

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

[RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, DOI 10.17487/RFC3948, January 2005, <http://www.rfc-editor.org/info/rfc3948>.

[RFC3948] Huttunen、A.、Swander、B.、Volpe、V.、DiBurro、L。、およびM. Stenberg、「IPsec ESPパケットのUDPカプセル化」、RFC 3948、DOI 10.17487 / RFC3948、2005年1月、<http ：//www.rfc-editor.org/info/rfc3948>。

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

[RFC4340] Kohler, E., Handley, M., and S. Floyd, "Datagram Congestion Control Protocol (DCCP)", RFC 4340, DOI 10.17487/RFC4340, March 2006, <http://www.rfc-editor.org/info/rfc4340>.

[RFC4340] Kohler、E.、Handley、M。、およびS. Floyd、「Datagram Congestion Control Protocol（DCCP）」、RFC 4340、DOI 10.17487 / RFC4340、2006年3月、<http：//www.rfc-editor。 org / info / rfc4340>。

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

[RFC4884] Bonica, R., Gan, D., Tappan, D., and C. Pignataro, "Extended ICMP to Support Multi-Part Messages", RFC 4884, DOI 10.17487/RFC4884, April 2007, <http://www.rfc-editor.org/info/rfc4884>.

[RFC4884] Bonica、R.、Gan、D.、Tappan、D。、およびC. Pignataro、「マルチパートメッセージをサポートするための拡張ICMP」、RFC 4884、DOI 10.17487 / RFC4884、2007年4月、<http：// www.rfc-editor.org/info/rfc4884>。

[RFC5382] Guha, S., Ed., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, DOI 10.17487/RFC5382, October 2008, <http://www.rfc-editor.org/info/rfc5382>.

[RFC5382] Guha、S。、編、Biswas、K.、Ford、B.、Sivakumar、S。、およびP. Srisuresh、「TCPのNAT動作要件」、BCP 142、RFC 5382、DOI 10.17487 / RFC5382、 2008年10月、<http://www.rfc-editor.org/info/rfc5382>。

[RFC5771] Cotton, M., Vegoda, L., and D. Meyer, "IANA Guidelines for IPv4 Multicast Address Assignments", BCP 51, RFC 5771, DOI 10.17487/RFC5771, March 2010, <http://www.rfc-editor.org/info/rfc5771>.

[RFC5771]コットン、M。、ベゴダ、L。、およびD.マイヤー、「IPv4マルチキャストアドレス割り当てのIANAガイドライン」、BCP 51、RFC 5771、DOI 10.17487 / RFC5771、2010年3月、<http：//www.rfc -editor.org/info/rfc5771>。

[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, DOI 10.17487/RFC6052, October 2010, <http://www.rfc-editor.org/info/rfc6052>.

[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、DOI 10.17487 / RFC6052、2010年10月、< http://www.rfc-editor.org/info/rfc6052>。

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

[RFC6791] Li, X., Bao, C., Wing, D., Vaithianathan, R., and G. Huston, "Stateless Source Address Mapping for ICMPv6 Packets", RFC 6791, DOI 10.17487/RFC6791, November 2012, <http://www.rfc-editor.org/info/rfc6791>.

[RFC6791] Li、X.、Bao、C.、Wing、D.、Vaithianathan、R。、およびG. Huston、「ICMPv6パケットのステートレスソースアドレスマッピング」、RFC 6791、DOI 10.17487 / RFC6791、2012年11月、< http://www.rfc-editor.org/info/rfc6791>。

[RFC7757] Anderson, T. and A. Leiva Popper, "Explicit Address Mappings for Stateless IP/ICMP Translation", RFC 7757, DOI 10.17487/RFC7757, February 2016, <http://www.rfc-editor.org/info/rfc7757>.

[RFC7757]アンダーソン、T。およびA.リーバポッパー、「ステートレスIP / ICMP変換のための明示的なアドレスマッピング」、RFC 7757、DOI 10.17487 / RFC7757、2016年2月、<http://www.rfc-editor.org/info / rfc7757>。

9.2. Informative References

9.2. 参考引用

[ATOMIC] Gont, F., LIU, S., and T. Anderson, "Generation of IPv6 Atomic Fragments Considered Harmful", Work in Progress, draft-ietf-6man-deprecate-atomfrag-generation-06, April 2016.

[ATOMIC] Gont、F.、LIU、S。、およびT. Anderson、「Generation of IPv6 Atomic Fragments考慮される有害」、Work in Progress、draft-ietf-6man-deprecate-atomfrag-generation-06、2016年4月。

[Err3059] RFC Errata, Erratum ID 3059, RFC 6145.

[Err3059] RFC Errata、Erratum ID 3059、RFC 6145。

[Err3060] RFC Errata, Erratum ID 3060, RFC 6145.

[Err3060] RFC Errata、Erratum ID 3060、RFC 6145。

[Err3061] RFC Errata, Erratum ID 3061, RFC 6145.

[Err3061] RFC Errata、Erratum ID 3061、RFC 6145。

[Err4090] RFC Errata, Erratum ID 4090, RFC 6145.

[Err4090] RFC Errata、Erratum ID 4090、RFC 6145。

[IPv6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", Work in Progress, draft-ietf-6man-rfc2460bis-04, March 2016.

[IPv6] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、進行中の作業、draft-ietf-6man-rfc2460bis-04、2016年3月。

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

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

[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Services", RFC 2475, DOI 10.17487/RFC2475, December 1998, <http://www.rfc-editor.org/info/rfc2475>.

[RFC2475] Blake、S.、Black、D.、Carlson、M.、Davies、E.、Wang、Z.、and W. Weiss、 "An Architecture for Differentiated Services"、RFC 2475、DOI 10.17487 / RFC2475、December 1998、<http://www.rfc-editor.org/info/rfc2475>。

[RFC2710] Deering, S., Fenner, W., and B. Haberman, "Multicast Listener Discovery (MLD) for IPv6", RFC 2710, DOI 10.17487/RFC2710, October 1999, <http://www.rfc-editor.org/info/rfc2710>.

[RFC2710] Deering、S.、Fenner、W。、およびB. Haberman、「IPv6のマルチキャストリスナーディスカバリ（MLD）」、RFC 2710、DOI 10.17487 / RFC2710、1999年10月、<http：//www.rfc-editor .org / info / rfc2710>。

[RFC2923] Lahey, K., "TCP Problems with Path MTU Discovery", RFC 2923, DOI 10.17487/RFC2923, September 2000, <http://www.rfc-editor.org/info/rfc2923>.

[RFC2923] Lahey、K。、「Path MTU Discoveryに関するTCPの問題」、RFC 2923、DOI 10.17487 / RFC2923、2000年9月、<http://www.rfc-editor.org/info/rfc2923>。

[RFC3307] Haberman, B., "Allocation Guidelines for IPv6 Multicast Addresses", RFC 3307, DOI 10.17487/RFC3307, August 2002, <http://www.rfc-editor.org/info/rfc3307>.

[RFC3307] Haberman、B。、「IPv6マルチキャストアドレスの割り当てガイドライン」、RFC 3307、DOI 10.17487 / RFC3307、2002年8月、<http://www.rfc-editor.org/info/rfc3307>。

[RFC3590] Haberman, B., "Source Address Selection for the Multicast Listener Discovery (MLD) Protocol", RFC 3590, DOI 10.17487/RFC3590, September 2003, <http://www.rfc-editor.org/info/rfc3590>.

[RFC3590] Haberman、B。、「Multicast Listener Discovery（MLD）Protocolのソースアドレス選択」、RFC 3590、DOI 10.17487 / RFC3590、2003年9月、<http://www.rfc-editor.org/info/rfc3590 >。

[RFC3810] Vida, R., Ed. and L. Costa, Ed., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, DOI 10.17487/RFC3810, June 2004, <http://www.rfc-editor.org/info/rfc3810>.

[RFC3810] Vida、R.、Ed。 L.コスタ編、「IPv6のマルチキャストリスナーディスカバリバージョン2（MLDv2）」、RFC 3810、DOI 10.17487 / RFC3810、2004年6月、<http://www.rfc-editor.org/info/rfc3810>。

[RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix Reserved for Documentation", RFC 3849, DOI 10.17487/RFC3849, July 2004, <http://www.rfc-editor.org/info/rfc3849>.

[RFC3849] Huston、G.、Lord、A。、およびP. Smith、「ドキュメント用に予約されたIPv6アドレスプレフィックス」、RFC 3849、DOI 10.17487 / RFC3849、2004年7月、<http://www.rfc-editor.org / info / rfc3849>。

[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, DOI 10.17487/RFC4302, December 2005, <http://www.rfc-editor.org/info/rfc4302>.

[RFC4302]ケント、S。、「IP認証ヘッダー」、RFC 4302、DOI 10.17487 / RFC4302、2005年12月、<http://www.rfc-editor.org/info/rfc4302>。

[RFC4787] Audet, F., Ed. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, DOI 10.17487/RFC4787, January 2007, <http://www.rfc-editor.org/info/rfc4787>.

[RFC4787]オーデ、F、エド。およびC.ジェニングス、「ユニキャストUDPのネットワークアドレス変換（NAT）動作要件」、BCP 127、RFC 4787、DOI 10.17487 / RFC4787、2007年1月、<http://www.rfc-editor.org/info/rfc4787> 。

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

[RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks Reserved for Documentation", RFC 5737, DOI 10.17487/RFC5737, January 2010, <http://www.rfc-editor.org/info/rfc5737>.

[RFC5737] Arkko、J.、Cotton、M。、およびL. Vegoda、「ドキュメント用に予約されたIPv4アドレスブロック」、RFC 5737、DOI 10.17487 / RFC5737、2010年1月、<http://www.rfc-editor.org / info / rfc5737>。

[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, DOI 10.17487/RFC6144, April 2011, <http://www.rfc-editor.org/info/rfc6144>.

[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「IPv4 / IPv6変換のフレームワーク」、RFC 6144、DOI 10.17487 / RFC6144、2011年4月、<http：// www。 rfc-editor.org/info/rfc6144>。

[RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The China Education and Research Network (CERNET) IVI Translation Design and Deployment for the IPv4/IPv6 Coexistence and Transition", RFC 6219, DOI 10.17487/RFC6219, May 2011, <http://www.rfc-editor.org/info/rfc6219>.

[RFC6219] Li、X.、Bao、C.、Chen、M.、Zhang、H.、J。Wu、「The China Education and Research Network（CERNET）IVI Translation Design and Deployment for the IPv4 / IPv6 Coexistence and移行」、RFC 6219、DOI 10.17487 / RFC6219、2011年5月、<http://www.rfc-editor.org/info/rfc6219>。

[RFC6691] Borman, D., "TCP Options and Maximum Segment Size (MSS)", RFC 6691, DOI 10.17487/RFC6691, July 2012, <http://www.rfc-editor.org/info/rfc6691>.

[RFC6691] Borman、D。、「TCPオプションと最大セグメントサイズ（MSS）」、RFC 6691、DOI 10.17487 / RFC6691、2012年7月、<http://www.rfc-editor.org/info/rfc6691>。

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

[RFC7599] Li, X., Bao, C., Dec, W., Ed., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", RFC 7599, DOI 10.17487/RFC7599, July 2015, <http://www.rfc-editor.org/info/rfc7599>.

[RFC7599] Li、X.、Bao、C.、Dec、W.、Ed。、Troan、O.、Matsushima S.、T。Murakami、「変換を使用したアドレスとポートのマッピング（MAP-T）」、RFC 7599、DOI 10.17487 / RFC7599、2015年7月、<http://www.rfc-editor.org/info/rfc7599>。

Appendix A. Stateless Translation Workflow Example

付録A.ステートレス変換ワークフローの例

A stateless translation workflow example is depicted in the following figure. The documentation address blocks 2001:db8::/32 [RFC3849], 192.0.2.0/24, and 198.51.100.0/24 [RFC5737] are used in this example.

ステートレス翻訳ワークフローの例を次の図に示します。この例では、ドキュメントアドレスブロック2001：db8 :: / 32 [RFC3849]、192.0.2.0 / 24、および198.51.100.0/24 [RFC5737]が使用されています。

            +--------------+                   +--------------+
            | IPv4 network |                   | IPv6 network |
            |              |     +-------+     |              |
            |   +----+     |-----| XLAT  |---- |  +----+      |
            |   | H4 |-----|     +-------+     |--| H6 |      |
            |   +----+     |                   |  +----+      |
            +--------------+                   +--------------+

Figure 8: Stateless Translation Workflow

図8：ステートレス翻訳ワークフロー

A translator (XLAT) connects the IPv6 network to the IPv4 network. This XLAT uses the Network-Specific Prefix (NSP) 2001:db8:100::/40 defined in [RFC6052] to represent IPv4 addresses in the IPv6 address space (IPv4-converted addresses) and to represent IPv6 addresses (IPv4-translatable addresses) in the IPv4 address space. In this example, 192.0.2.0/24 is the IPv4 block of the corresponding IPv4-translatable addresses.

トランスレータ（XLAT）は、IPv6ネットワークをIPv4ネットワークに接続します。このXLATは、[RFC6052]で定義されているネットワーク固有の接頭辞（NSP）2001：db8：100 :: / 40を使用して、IPv6アドレス空間（IPv4変換アドレス）でIPv4アドレスを表し、IPv6アドレス（IPv4-translatableアドレス）を表します）IPv4アドレス空間。この例では、192.0.2.0 / 24は、対応するIPv4変換可能アドレスのIPv4ブロックです。

Based on the address mapping rule, the IPv6 node H6 has an IPv4-translatable IPv6 address 2001:db8:1c0:2:21:: (address mapping from 192.0.2.33). The IPv4 node H4 has IPv4 address 198.51.100.2.

アドレスマッピングルールに基づいて、IPv6ノードH6はIPv4で変換可能なIPv6アドレス2001：db8：1c0：2：21 ::（192.0.2.33からのアドレスマッピング）を持っています。 IPv4ノードH4のIPv4アドレスは198.51.100.2です。

The IPv6 routing is configured in such a way that the IPv6 packets addressed to a destination address in 2001:db8:100::/40 are routed to the IPv6 interface of the XLAT.

IPv6ルーティングは、2001：db8：100 :: / 40の宛先アドレスにアドレス指定されたIPv6パケットがXLATのIPv6インターフェイスにルーティングされるように構成されています。

The IPv4 routing is configured in such a way that the IPv4 packets addressed to a destination address in 192.0.2.0/24 are routed to the IPv4 interface of the XLAT.

IPv4ルーティングは、192.0.2.0 / 24の宛先アドレスにアドレス指定されたIPv4パケットがXLATのIPv4インターフェイスにルーティングされるように構成されています。

A.1. H6 Establishes Communication with H4

A.1. H6はH4との通信を確立します

The steps by which H6 establishes communication with H4 are:

H6がH4との通信を確立する手順は次のとおりです。

1. H6 performs the destination address mapping, so the IPv4-converted address 2001:db8:1c6:3364:2:: is formed from 198.51.100.2 based on the address mapping algorithm [RFC6052].

1. H6は宛先アドレスマッピングを実行するため、IPv4変換されたアドレス2001：db8：1c6：3364：2 ::は、アドレスマッピングアルゴリズム[RFC6052]に基づいて198.51.100.2から形成されます。

2. H6 sends a packet to H4. The packet is sent from a source address 2001:db8:1c0:2:21:: to a destination address 2001:db8:1c6:3364:2::.

2. H6はH4にパケットを送信します。パケットは、送信元アドレス2001：db8：1c0：2：21 ::から宛先アドレス2001：db8：1c6：3364：2 ::に送信されます。

3. The packet is routed to the IPv6 interface of the XLAT (since IPv6 routing is configured that way).

3. パケットはXLATのIPv6インターフェースにルーティングされます（IPv6ルーティングがそのように構成されているため）。

4. The XLAT receives the packet and performs the following actions:

4. XLATはパケットを受信し、次のアクションを実行します。

* The XLAT translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm defined in this document.

* XLATは、このドキュメントで定義されているIP / ICMP変換アルゴリズムを使用して、IPv6ヘッダーをIPv4ヘッダーに変換します。

* The XLAT includes 192.0.2.33 as the source address in the packet and 198.51.100.2 as the destination address in the packet. Note that 192.0.2.33 and 198.51.100.2 are extracted directly from the source IPv6 address 2001:db8:1c0:2:21:: (IPv4-translatable address) and destination IPv6 address 2001:db8:1c6:3364:2:: (IPv4-converted address) of the received IPv6 packet that is being translated.

* XLATには、パケット内の送信元アドレスとして192.0.2.33が含まれ、パケット内の宛先アドレスとして198.51.100.2が含まれています。 192.0.2.33および198.51.100.2は、ソースIPv6アドレス2001：db8：1c0：2：21 ::（IPv4-translatable address）および宛先IPv6アドレス2001：db8：1c6：3364：2 ::（変換されている受信IPv6パケットのIPv4変換アドレス）。

5. The XLAT sends the translated packet out of its IPv4 interface, and the packet arrives at H4.

5. XLATは変換されたパケットをIPv4インターフェイスから送信し、パケットはH4に到着します。

6. H4 node responds by sending a packet with destination address 192.0.2.33 and source address 198.51.100.2.

6. H4ノードは、宛先アドレス192.0.2.33および送信元アドレス198.51.100.2のパケットを送信して応答します。

7. The packet is routed to the IPv4 interface of the XLAT (since IPv4 routing is configured that way). The XLAT performs the following operations:

7. パケットはXLATのIPv4インターフェースにルーティングされます（IPv4ルーティングがそのように構成されているため）。 XLATは次の操作を実行します。

* The XLAT translates the IPv4 header into an IPv6 header using the IP/ICMP Translation Algorithm defined in this document.

* XLATは、このドキュメントで定義されているIP / ICMP変換アルゴリズムを使用して、IPv4ヘッダーをIPv6ヘッダーに変換します。

* The XLAT includes 2001:db8:1c0:2:21:: as the destination address in the packet and 2001:db8:1c6:3364:2:: as the source address in the packet. Note that 2001:db8:1c0:2:21:: and 2001:db8:1c6:3364:2:: are formed directly from the destination IPv4 address 192.0.2.33 and the source IPv4 address 198.51.100.2 of the received IPv4 packet that is being translated.

* XLATには、パケットの宛先アドレスとして2001：db8：1c0：2：21 ::が含まれ、パケットの送信元アドレスとして2001：db8：1c6：3364：2 ::が含まれています。 2001：db8：1c0：2：21 ::および2001：db8：1c6：3364：2 ::は、受信したIPv4パケットの宛先IPv4アドレス192.0.2.33およびソースIPv4アドレス198.51.100.2から直接形成されることに注意してください。翻訳中です。

8. The translated packet is sent out of the IPv6 interface to H6.

8. 変換されたパケットは、IPv6インターフェイスからH6に送信されます。

The packet exchange between H6 and H4 continues until the session is finished.

H6とH4の間のパケット交換は、セッションが終了するまで続きます。

A.2. H4 Establishes Communication with H6

A.2. H4はH6との通信を確立します

The steps by which H4 establishes communication with H6 are:

H4がH6との通信を確立する手順は次のとおりです。

1. H4 performs the destination address mapping, so 192.0.2.33 is formed from the IPv4-translatable address 2001:db8:1c0:2:21:: based on the address mapping algorithm [RFC6052].

1. H4は宛先アドレスマッピングを実行するため、アドレスマッピングアルゴリズム[RFC6052]に基づいて、IPv4変換可能アドレス2001：db8：1c0：2：21 ::から192.0.2.33が形成されます。

2. H4 sends a packet to H6. The packet is sent from a source address 198.51.100.2 to a destination address 192.0.2.33.

2. H4はH6にパケットを送信します。パケットは、送信元アドレス198.51.100.2から宛先アドレス192.0.2.33に送信されます。

3. The packet is routed to the IPv4 interface of the XLAT (since IPv4 routing is configured that way).

3. パケットはXLATのIPv4インターフェースにルーティングされます（IPv4ルーティングがそのように構成されているため）。

4. The XLAT receives the packet and performs the following actions:

4. XLATはパケットを受信し、次のアクションを実行します。

* The XLAT translates the IPv4 header into an IPv6 header using the IP/ICMP Translation Algorithm defined in this document.

* XLATは、このドキュメントで定義されているIP / ICMP変換アルゴリズムを使用して、IPv4ヘッダーをIPv6ヘッダーに変換します。

* The XLAT includes 2001:db8:1c6:3364:2:: as the source address in the packet and 2001:db8:1c0:2:21:: as the destination address in the packet. Note that 2001:db8:1c6:3364:2:: (IPv4-converted address) and 2001:db8:1c0:2:21:: (IPv4-translatable address) are obtained directly from the source IPv4 address 198.51.100.2 and destination IPv4 address 192.0.2.33 of the received IPv4 packet that is being translated.

* XLATには、パケットの送信元アドレスとして2001：db8：1c6：3364：2 ::が含まれ、パケットの宛先アドレスとして2001：db8：1c0：2：21 ::が含まれています。 2001：db8：1c6：3364：2 ::（IPv4-converted address）および2001：db8：1c0：2：21 ::（IPv4-translatable address）は、ソースIPv4アドレス198.51.100.2および宛先から直接取得されることに注意してください変換されている受信IPv4パケットのIPv4アドレス192.0.2.33。

5. The XLAT sends the translated packet out its IPv6 interface, and the packet arrives at H6.

5. XLATは、変換されたパケットをIPv6インターフェイスから送信し、パケットはH6に到着します。

6. H6 node responds by sending a packet with destination address 2001:db8:1c6:3364:2:: and source address 2001:db8:1c0:2:21::.

6. H6ノードは、宛先アドレス2001：db8：1c6：3364：2 ::および送信元アドレス2001：db8：1c0：2：21 ::でパケットを送信することによって応答します。

7. The packet is routed to the IPv6 interface of the XLAT (since IPv6 routing is configured that way). The XLAT performs the following operations:

7. パケットはXLATのIPv6インターフェースにルーティングされます（IPv6ルーティングがそのように構成されているため）。 XLATは次の操作を実行します。

* The XLAT translates the IPv6 header into an IPv4 header using the IP/ICMP Translation Algorithm defined in this document.

* XLATは、このドキュメントで定義されているIP / ICMP変換アルゴリズムを使用して、IPv6ヘッダーをIPv4ヘッダーに変換します。

* The XLAT includes 198.51.100.2 as the destination address in the packet and 192.0.2.33 as the source address in the packet. Note that 198.51.100.2 and 192.0.2.33 are formed directly from the destination IPv6 address 2001:db8:1c6:3364:2:: and source IPv6 address 2001:db8:1c0:2:21:: of the received IPv6 packet that is being translated.

* XLATには、パケットの宛先アドレスとして198.51.100.2が含まれ、パケットの送信元アドレスとして192.0.2.33が含まれています。 198.51.100.2および192.0.2.33は、受信したIPv6パケットの宛先IPv6アドレス2001：db8：1c6：3364：2 ::およびソースIPv6アドレス2001：db8：1c0：2：21 ::から直接形成されることに注意してください。翻訳中です。

8. The translated packet is sent out the IPv4 interface to H4.

8. 変換されたパケットは、IPv4インターフェイスからH4に送信されます。

The packet exchange between H4 and H6 continues until the session is finished.

H4とH6の間のパケット交換は、セッションが終了するまで続きます。

Acknowledgements

謝辞

Gandhar Gokhale, Wesley Eddy, and Fernando Gont submitted and handled the errata reports on [RFC6145]. Fernando Gont, Will (Shucheng) Liu, and Tore Anderson provided the security analysis and the suggestions for updates concerning atomic fragments. In addition, Tore Anderson and Alberto Leiva provided the proposal of the Explicit Address Mapping (EAM) algorithm.

Gandhar Gokhale、Wesley Eddy、およびFernando Gontは、[RFC6145]に関するエラッタレポートを提出して処理しました。 Fernando Gont、Will（Shucheng）Liu、およびTore Andersonは、セキュリティ分析と、アトミックフラグメントに関する更新の提案を提供しました。さらに、Tore AndersonとAlberto Leivaは、Explicit Address Mapping（EAM）アルゴリズムの提案を提供しました。

Authors' Addresses

著者のアドレス

Congxiao Bao CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China

Congxiao Bao CERNETセンター/清華大学本館北京100084中国本館225号室

   Phone: +86 10-62785983
   Email: congxiao@cernet.edu.cn

Xing Li CERNET Center/Tsinghua University Room 225, Main Building, Tsinghua University Beijing 100084 China

Xing Li CERNETセンター/清華大学本館225号室北京100084中国清華大学

   Phone: +86 10-62785983
   Email: xing@cernet.edu.cn

Fred Baker Cisco Systems Santa Barbara, California 93117 United States

Fred Baker Cisco Systemsサンタバーバラ、カリフォルニア93117アメリカ合衆国

Phone: +1-408-526-4257 Email: fred@cisco.com Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway

電話：+ 1-408-526-4257メール：fred@cisco.com Tore Anderson Redpill Linpro Vitaminveien 1A 0485 Oslo Norway

   Phone: +47 959 31 212
   Email: tore@redpill-linpro.com
   URI:   http://www.redpill-linpro.com

Fernando Gont Huawei Technologies Evaristo Carriego 2644 Haedo, Provincia de Buenos Aires 1706 Argentina

Fernando Gont Huawei Technologies Evaristo Carriego 2644ブエノスアイレス州ハエド1706アルゼンチン

   Phone: +54 11 4650 8472
   Email: fgont@si6networks.com
   URI:   http://www.si6networks.com