[要約] RFC 6751は、IPv4からIPv4へのNATを使用する場合に、ネイティブIPv6をサポートするためのガイドラインです。その目的は、IPv6の導入を促進し、IPv4アドレス枯渇の問題を解決することです。
Independent Submission R. Despres, Ed.
Request for Comments: 6751 RD-IPtech
Category: Experimental B. Carpenter
ISSN: 2070-1721 Univ. of Auckland
D. Wing
Cisco
S. Jiang
Huawei Technologies Co., Ltd.
October 2012
Native IPv6 behind IPv4-to-IPv4 NAT Customer Premises Equipment (6a44)
IPv4-to-IPv4 NAT顧客宅内機器の背後にあるネイティブIPv6（6a44）
Abstract
概要
In customer sites having IPv4-only Customer Premises Equipment (CPE), Teredo (RFC 4380, RFC 5991, RFC 6081) provides last-resort IPv6 connectivity. However, because it is designed to work without the involvement of Internet Service Providers, it has significant limitations (connectivity between IPv6 native addresses and Teredo addresses is uncertain; connectivity between Teredo addresses fails for some combinations of NAT types). 6a44 is a complementary solution that, being based on ISP cooperation, avoids these limitations. At the beginning of 6a44 IPv6 addresses, it replaces the Teredo well-known prefix, present at the beginning of Teredo IPv6 addresses, with network-specific /48 prefixes assigned by local ISPs (an evolution similar to that from 6to4 to 6rd (IPv6 Rapid Deployment on IPv4 Infrastructures)). The specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used.
IPv4のみの顧客宅内機器（CPE）を持つ顧客サイトでは、Teredo（RFC 4380、RFC 5991、RFC 6081）は、最後の手段としてIPv6接続を提供します。ただし、インターネットサービスプロバイダーの関与なしに機能するように設計されているため、重要な制限があります（IPv6ネイティブアドレスとTeredoアドレス間の接続は不確実です。NATタイプの一部の組み合わせでは、Teredoアドレス間の接続が失敗します）。 6a44は、ISPの協力に基づいてこれらの制限を回避する補完的なソリューションです。 6a44 IPv6アドレスの先頭では、Teredo IPv6アドレスの先頭に存在するTeredoウェルノウンプレフィックスを、ローカルISPによって割り当てられたネットワーク固有の/ 48プレフィックスで置き換えます（6to4から6rd（IPv6 Rapid 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 is a contribution to the RFC Series, independently of any other RFC stream. The RFC Editor has chosen to publish this document at its discretion and makes no statement about its value for implementation or deployment. Documents approved for publication by the RFC Editor are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントでは、インターネットコミュニティの実験プロトコルを定義します。これは、他のRFCストリームとは無関係に、RFCシリーズへの貢献です。 RFCエディターは、このドキュメントを独自の裁量で公開することを選択し、実装または展開に対するその価値については何も述べていません。 RFC Editorによって公開が承認されたドキュメントは、どのレベルのインターネット標準の候補にもなりません。 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/rfc6751.
このドキュメントの現在のステータス、エラッタ、フィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6751で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。
Table of Contents
目次
1. Introduction ....................................................3
2. Requirements Language ...........................................5
3. Definitions .....................................................5
4. Design Goals, Requirements, and Model of Operation ..............7
4.1. Hypotheses about NAT Behavior ..............................7
4.2. Native IPv6 Connectivity for Unmanaged Hosts behind
NAT44s .....................................................7
4.3. Operational Requirements ...................................8
4.4. Model of Operation .........................................9
5. 6a44 Addresses .................................................12
6. Specification of Clients and Relays ............................14
6.1. Packet Formats ............................................14
6.2. IPv6 Packet Encapsulations ................................14
6.3. 6a44 Bubbles ..............................................14
6.4. MTU Considerations ........................................16
6.5. 6a44 Client Specification .................................16
6.5.1. Tunnel Maintenance .................................16
6.5.2. Client Transmission ................................19
6.5.3. Client Reception ...................................20
6.6. 6a44 Relay Specification ..................................23
6.6.1. Relay Reception in IPv6 ............................23
6.6.2. Relay Reception in IPv4 ............................24
6.7. Implementation of Automatic Sunset ........................26
7. Security Considerations ........................................26
8. IANA Considerations ............................................30
9. Acknowledgments ................................................30
10. References ....................................................30
10.1. Normative References .....................................30
10.2. Informative References ...................................31
Although most Customer Premises Equipment (CPE) should soon be dual-stack capable, a large installed base of IPv4-only CPEs is likely to remain for several years. Their operation is based on IPv4-to-IPv4 NATs (NAT44s). Also, due to the IPv4 address shortage, more and more Internet Service Providers (ISPs), and more and more mobile operators, will assign private IPv4 addresses ([RFC1918]) to their customers (the [NAT444] model). For rapid and extensive use of IPv6 [RFC2460], there is therefore a need for IPv6 connectivity behind NAT44s, including those of the [NAT444] model.
ほとんどのCustomer Premises Equipment（CPE）はまもなくデュアルスタック対応になるはずですが、IPv4のみのCPEの大規模なインストールベースは数年間残る可能性があります。それらの動作はIPv4-to-IPv4 NAT（NAT44）に基づいています。また、IPv4アドレスの不足により、ますます多くのインターネットサービスプロバイダー（ISP）、およびますます多くのモバイルオペレーターが、プライベートIPv4アドレス（[RFC1918]）を顧客（[NAT444]モデル）に割り当てます。したがって、IPv6 [RFC2460]を迅速かつ広範囲に使用するには、[NAT444]モデルの接続を含めて、NAT44の背後にIPv6接続が必要です。
At the moment, there are two tunneling techniques specified for IPv6 connectivity behind NAT44s:
現時点では、NAT44の背後にあるIPv6接続用に指定された2つのトンネリング技術があります。
o Configured tunnels. These involve tunnel brokers with which users must register [RFC3053]. Well-known examples include deployments of the Hexago tool, and the SixXS collaboration, which are suitable for IPv6 early trials. However, this approach is not adequate for mass deployment: it imposes the restriction that even if two hosts are in the same customer site, IPv6 packets between them must transit via tunnel servers, which may be far away.
o 構成済みトンネル。これらには、ユーザーが登録する必要があるトンネルブローカーが含まれます[RFC3053]。よく知られている例としては、Hexagoツールの導入、SixXSコラボレーションなどがあり、IPv6の初期の試験に適しています。ただし、このアプローチは、大規模な展開には適切ではありません。2つのホストが同じ顧客サイトにある場合でも、それらの間のIPv6パケットは、遠く離れているトンネルサーバーを経由する必要があるという制限があります。
o Automatic Teredo tunnels [RFC4380] [RFC5991]. Teredo is specified as a last-resort solution that, due to its objective to work without local ISP involvement, has the following limitations:
o 自動Teredoトンネル[RFC4380] [RFC5991]。 Teredoは、ローカルのISPの関与なしに機能するという目的のために、次の制限がある最後の手段として指定されています。
* Connectivity between IPv6 native addresses and Teredo addresses is uncertain. (As explained in [RFC4380] Section 8.3, this connectivity depends on paths being available from all IPv6 native addresses to some Teredo relays. ISPs lack sufficient motivations to ensure it.)
* IPv6ネイティブアドレスとTeredoアドレス間の接続は不確実です。 （[RFC4380]セクション8.3で説明されているように、この接続は、すべてのIPv6ネイティブアドレスから一部のTeredoリレーへのパスが利用できるかどうかに依存します。ISPには、それを保証する十分な動機がありません。）
* Between two Teredo addresses, IPv6 connectivity fails for some combinations of NAT44 types ([RFC6081] Section 3).
* 2つのTeredoアドレス間で、NAT44タイプの一部の組み合わせでIPv6接続が失敗します（[RFC6081]セクション3）。
* According to [RFC4380] Section 5.2, each Teredo host has to be configured with the IPv4 address of a Teredo server (a constraint that can, however, be avoided in some implementations).
* [RFC4380]セクション5.2によれば、各TeredoホストはTeredoサーバーのIPv4アドレスで構成する必要があります（ただし、一部の実装では回避できる制約があります）。
6a44 is designed to avoid Teredo limitations: with 6a44, ISPs can participate in the solution. The approach for this is similar to the approach that permitted 6rd [RFC5569] [RFC5969] to avoid the limitations of 6to4 [RFC3056] [RFC3068]: at the beginning of IPv6 addresses, the Teredo well-known prefix is replaced by network-specific prefixes assigned by local ISPs.
6a44はTeredoの制限を回避するように設計されています。6a44では、ISPがソリューションに参加できます。これに対するアプローチは、6to4 [RFC3056] [RFC3068]の制限を回避するために6番目の[RFC5569] [RFC5969]を許可したアプローチに似ています。IPv6アドレスの先頭で、Teredoの既知のプレフィックスがネットワーク固有のものに置き換えられますローカルISPによって割り当てられたプレフィックス。
This document is organized as follows: terms used in the document are defined in Section 3; design goals and model of operation are presented in Section 4; Section 5 describes the format of 6a44 IPv6 addresses; Section 6 specifies in detail the behaviors of 6a44 clients and 6a44 relays; security and IANA considerations are covered in Sections 7 and 8, respectively.
このドキュメントは次のように構成されています。ドキュメントで使用される用語はセクション3で定義されています。設計目標と運用モデルについては、セクション4で説明します。セクション5では、6a44 IPv6アドレスの形式について説明します。セクション6では、6a44クライアントと6a44リレーの動作を詳細に指定しています。セキュリティとIANAの考慮事項は、それぞれセクション7と8で説明されています。
This specification is expected to be complete enough for running code to be independently written and the solution to be incrementally deployed and used. Its status is Experimental rather than Standards Track, to reflect uncertainty as to which major Internet players may be willing to support it.
この仕様は、実行中のコードを個別に記述し、ソリューションを段階的に展開して使用するのに十分な完成度が期待されています。そのステータスは、スタンダードトラックではなく試験的なものであり、主要なインターネットプレーヤーがサポートする意思があるかどうかの不確実性を反映しています。
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]で説明されているように解釈されます。
The following definitions are used in this document:
このドキュメントでは、次の定義が使用されています。
MAJOR NEW DEFINITIONS
主要な新しい定義
6a44 ISP network: An IPv4-capable ISP network that supports at least one 6a44 relay. Additional conditions are that it assigns individual IPv4 addresses to its customer sites (global or private), that it supports ingress filtering [RFC2827], and that its path MTUs are at least 1308 octets.
6a44 ISPネットワーク：少なくとも1つの6a44リレーをサポートするIPv4対応のISPネットワーク。追加の条件は、個々のIPv4アドレスを顧客サイト（グローバルまたはプライベート）に割り当て、入力フィルタリング[RFC2827]をサポートし、そのパスMTUが少なくとも1308オクテットであることです。
6a44 relay: A node that supports the 6a44 relay function defined in this document and that has interfaces to an IPv6-capable upstream network and to an IPv4-capable downstream network.
6a44リレー：このドキュメントで定義されている6a44リレー機能をサポートし、IPv6対応のアップストリームネットワークとIPv4対応のダウンストリームネットワークへのインターフェースを持つノード。
6a44 client: A host that supports the 6a44 client function defined in this document and has no means other than 6a44 to have an IPv6 native address.
6a44クライアント：このドキュメントで定義されている6a44クライアント機能をサポートし、6a44以外にIPv6ネイティブアドレスを持つ手段がないホスト。
6a44 tunnel: A tunnel established and maintained between a 6a44 client and 6a44 relays of its ISP network.
6a44トンネル：ISPネットワークの6a44クライアントと6a44リレーの間に確立および維持されるトンネル。
6a44 bubble: A UDP/IPv4 packet sent from a 6a44 client to the 6a44-relay address, or vice versa, and having a UDP payload that cannot be confused with an IPv6 packet. In the client-to-relay direction, it is a request for a response bubble. In the relay-to-client direction, it conveys the up-to-date IPv6 prefix of the client.
6a44バブル：6a44クライアントから6a44-relayアドレスに、またはその逆に送信され、IPv6パケットと混同されないUDPペイロードを持つUDP / IPv4パケット。クライアントからリレーへの方向では、これは応答バブルの要求です。リレーからクライアントへの方向では、クライアントの最新のIPv6プレフィックスを伝えます。
SECONDARY NEW DEFINITIONS
二次的な新しい定義
(This list is for reference and can be skipped by readers familiar with the usual terminology.)
（このリストは参照用であり、通常の用語に精通している読者はスキップできます。）
6a44 service: The service offered by a 6a44 ISP network to its 6a44 clients.
6a44サービス：6a44 ISPネットワークが6a44クライアントに提供するサービス。
6a44-client IPv6 address: The IPv6 address of a 6a44 client. It is composed of the client IPv6 prefix, received from a 6a44 relay, followed by the client local IPv4 address.
6a44クライアントのIPv6アドレス：6a44クライアントのIPv6アドレス。これは、6a44リレーから受信したクライアントIPv6プレフィックスと、それに続くクライアントローカルIPv4アドレスで構成されます。
6a44-client IPv6 prefix: For a 6a44 client, the IPv6 prefix (/96) composed of the IPv6 prefix of the local 6a44 network (/48) followed by the UDP/IPv4 mapped address of the client (32 + 16 bits).
6a44-クライアントIPv6プレフィックス：6a44クライアントの場合、IPv6プレフィックス（/ 96）は、ローカル6a44ネットワーク（/ 48）のIPv6プレフィックスと、それに続くクライアントのUDP / IPv4マップアドレス（32 + 16ビット）で構成されます。
6a44-client UDP/IPv4 mapped address: For a 6a44 client, the external UDP/IPv4 address that, in the CPE NAT44 of the site, is that of its 6a44 tunnel.
6a44-クライアントUDP / IPv4マップアドレス：6a44クライアントの場合、サイトのCPE NAT44で、その6a44トンネルのアドレスである外部UDP / IPv4アドレス。
6a44-client UDP/IPv4 local address: For a 6a44 client, the combination of its local IPv4 address and the 6a44 port.
6a44-クライアントUDP / IPv4ローカルアドレス：6a44クライアントの場合、そのローカルIPv4アドレスと6a44ポートの組み合わせ。
6a44 port: UDP port 1027, reserved by IANA for 6a44 (see Section 8).
6a44ポート：UDPポート1027。6a44用にIANAによって予約されています（セクション8を参照）。
6a44-relay UDP/IPv4 address: The UDP/IPv4 address composed of the 6a44-relay anycast address and the 6a44 port.
6a44-relay UDP / IPv4アドレス：6a44-relayエニーキャストアドレスと6a44ポートで構成されるUDP / IPv4アドレス。
6a44-relay anycast address: IPv4 anycast address 192.88.99.2, reserved by IANA for 6a44 (see Section 8).
6a44-relayエニーキャストアドレス：IANAによって6a44用に予約されているIPv4エニーキャストアドレス192.88.99.2（セクション8を参照）。
6a44-network IPv6 prefix: An IPv6 /48 prefix assigned by an ISP to a 6a44 network.
6a44ネットワークIPv6プレフィックス：ISPによって6a44ネットワークに割り当てられたIPv6 / 48プレフィックス。
USUAL DEFINITIONS
通常の定義
(This list is for reference and can be skipped by readers familiar with the usual terminology.)
（このリストは参照用であり、通常の用語に精通している読者はスキップできます。）
Upstream direction: For a network border node, the direction toward the Internet core.
上流方向：ネットワーク境界ノードの場合、インターネットコアに向かう方向。
Downstream direction: For a network border node, the direction toward end-user nodes (opposite to the upstream direction).
ダウンストリーム方向：ネットワーク境界ノードの場合、エンドユーザーノードに向かう方向（アップストリーム方向の反対）。
IPv4 private address: An address that starts with one of the three [RFC1918] prefixes (10/8, 172.16/12, or 192.168/16).
IPv4プライベートアドレス：3つの[RFC1918]プレフィックス（10 / 8、172.16 / 12、または192.168 / 16）のいずれかで始まるアドレス。
IPv6 native address: An IPv6 global unicast address that starts with an aggregatable prefix assigned to an ISP.
IPv6ネイティブアドレス：ISPに割り当てられた集約可能なプレフィックスで始まるIPv6グローバルユニキャストアドレス。
UDP/IPv4 address: The combination of an IPv4 address and a UDP port.
UDP / IPv4アドレス：IPv4アドレスとUDPポートの組み合わせ。
UDP/IPv4 packet: A UDP datagram contained in an IPv4 packet.
UDP / IPv4パケット：IPv4パケットに含まれるUDPデータグラム。
IPv6/UDP/IPv4 packet: An IPv6 packet contained in a UDP/IPv4 packet.
IPv6 / UDP / IPv4パケット：UDP / IPv4パケットに含まれるIPv6パケット。
6a44 is designed to work with NAT44 behaviors identified in Section 3 of [RFC6081]. In particular, it has to work with endpoint-dependent mappings as well as with endpoint-independent mappings, including cases where there are dynamic changes from one mode to the other.
6a44は、[RFC6081]のセクション3で識別されたNAT44動作で動作するように設計されています。特に、エンドポイントに依存するマッピングだけでなく、あるモードから別のモードに動的に変更される場合を含め、エンドポイントに依存しないマッピングでも機能する必要があります。
The only assumption is that, after a mapping has been established in the NAT44, it is maintained as long as it is reused at least once, in each direction, every 30 seconds.
唯一の前提は、NAT44でマッピングが確立された後、30秒ごとに少なくとも1回、各方向で再利用される限り、マッピングが維持されることです。
NOTE: 30 seconds is the value used for the same mapping-maintenance purpose in Teredo [RFC4380] and in SIP [RFC5626].
注：30秒は、Teredo [RFC4380]とSIP [RFC5626]で同じマッピング保守目的に使用される値です。
The objective remains that, as soon as possible, CPEs and ISPs support IPv6 native prefixes. 6a44 is therefore designed only as a temporary solution for hosts to obtain IPv6 native addresses in sites whose CPEs are not IPv6 capable yet.
目標は、CPEとISPがIPv6ネイティブプレフィックスをできるだけ早くサポートすることです。したがって、6a44は、CPEがまだIPv6に対応していないサイトでホストがIPv6ネイティブアドレスを取得するための一時的なソリューションとしてのみ設計されています。
As noted in Section 1, IPv6 native addresses obtainable with configured tunnels have important limitations. However, compared to 6a44 addresses, they have the advantage of remaining unchanged in the case of NAT44 reset. 6a44 therefore remains the last-resort solution for IPv6 native addresses in unmanaged hosts of IPv4-only-CPE sites, while configured tunnels may still be preferred for some managed hosts if reported limitations of configured tunnels are judged to be acceptable. As their scopes are different, the two solutions can usefully coexist.
セクション1で述べたように、構成済みトンネルで取得できるIPv6ネイティブアドレスには、重要な制限があります。ただし、6a44アドレスと比較して、NAT44リセットの場合は変更されないという利点があります。したがって、6a44は、IPv4のみのCPEサイトの非管理対象ホストにおけるIPv6ネイティブアドレスの最後の手段としてのソリューションですが、構成済みトンネルの報告された制限が許容可能であると判断された場合、一部の管理対象ホストには構成済みトンネルが優先される場合があります。スコープが異なるため、2つのソリューションは共存できます。
Note that Teredo remains a last-resort solution for hosts to have IPv6 addresses where IPv6 native addresses cannot be made available (and where Teredo limitations are judged to be acceptable).
Teredoは、IPv6ネイティブアドレスを使用可能にできない場合（およびTeredoの制限が許容できると判断された場合）にホストがIPv6アドレスを持つための最後の手段であることに注意してください。
Operational requirements of 6a44 include the following:
6a44の運用要件は次のとおりです。
Robust IPv6 connectivity: A node having a 6a44 address must have paths across the Internet to and from all IPv6 native addresses that are not subject to voluntary firewall filtering.
堅牢なIPv6接続：6a44アドレスを持つノードには、自発的なファイアウォールフィルタリングの対象ではないすべてのIPv6ネイティブアドレスとの間のインターネット経由のパスが必要です。
Intra-site path efficiency: Packets exchanged between 6a44 clients that are behind the same CPE NAT44 must not have to traverse it. If these clients have IPv4 connectivity using their private IPv4 addresses, they must also have IPv6 connectivity using their 6a44 addresses.
サイト内パス効率：同じCPE NAT44の背後にある6a44クライアント間で交換されるパケットは、それを通過する必要はありません。これらのクライアントがプライベートIPv4アドレスを使用してIPv4接続を持っている場合は、6a44アドレスを使用してIPv6接続も持っている必要があります。
Plug-and-play operation of 6a44 clients: In order to obtain a 6a44 address from its local ISP, a 6a44 client must need no parameter configuration.
6a44クライアントのプラグアンドプレイ操作：ローカルISPから6a44アドレスを取得するために、6a44クライアントはパラメーター構成を必要としません。
Scalability of ISP functions: For the solution to be easily scalable, ISP-supported functions have to be completely stateless.
ISP関数のスケーラビリティ：ソリューションを簡単にスケーラブルにするには、ISPがサポートする関数を完全にステートレスにする必要があります。
Anti-spoofing protection: Where address anti-spoofing is ensured in IPv4 with ingress filtering [RFC2827] [RFC3704], IPv6 addresses must benefit from the same degree of anti-spoofing protection.
アンチスプーフィング保護：IPv4でイングレスフィルタリング[RFC2827] [RFC3704]を使用してアドレスアンチスプーフィングが保証されている場合、IPv6アドレスは同じ程度のアンチスプーフィング保護の恩恵を受ける必要があります。
Overall operational simplicity: To paraphrase what Antoine de Saint-Exupery said in [TheTool], "it seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove".
全体的な操作の簡素化：[TheTool]でAntoine de Saint-Exuperyが言ったことを言い換えると、「完璧なものは、追加するものがないときではなく、削除するものがないとき」です。
Incremental deployability: Hosts and ISP networks must be able to become 6a44 capable independently of each other. IPv6 must be operational where both are available, and there must be no perceptible effect where they are not both available.
段階的な導入可能性：ホストとISPネットワークは、互いに独立して6a44対応になる必要があります。 IPv6は、両方が利用可能な場合に動作可能でなければならず、両方が利用できない場合には目に見える影響があってはなりません。
Operation of 6a44 involves two types of nodes: 6a44 clients and 6a44 relays. Figure 1 shows the two applicability scenarios:
6a44の操作には、6a44クライアントと6a44リレーの2種類のノードが含まれます。図1は、2つの適用シナリオを示しています。
o In the first one, IPv4 addresses assigned to customer sites are global IPv4.
o 最初の例では、顧客サイトに割り当てられたIPv4アドレスはグローバルIPv4です。
o In the second one, they are private IPv4 addresses (the [NAT444] model, where ISPs operate one or several NAT44s, also called Carrier-Grade NATs (CGNs)).
o 2つ目は、プライベートIPv4アドレスです（[NAT444]モデルでは、ISPが1つまたは複数のNAT44を操作します。これは、キャリアグレードNAT（CGN）とも呼ばれます）。
(A) GLOBAL IPv4 ISP NETWORK
+------------------+
6a44 customer network(s) |GLOBAL IPv4 | Upstream
+-----------+ ---| MTU >= 1308 +--- IPv4 network
---| Private | | ingress filtering| (<== no route
+----+ | IPv4 +-----+ | IPv6 optional | to 6a44 relays)
| |-----| |NAT44|----+ |
+----+ | +-----+ | +-------------+
6a44 ---|MTU >= 1308| | --+6a44 relay(s)|--- Upstream
client(s) | no | ---| +-------------+ IPv6 network
|native IPv6| | |
+-----------+ +------------------+
(B) PRIVATE IPv4 ISP NETWORK
+------------------+
|PRIVATE IPv4 |
| as above |
---| |
| +--------------+
| --+ ISP NAT44(s) |--- Upstream
as above ----+ +--------------+ IPv4 network
| |
| +--------------+
---| --+6a44 relay(s) |--- Upstream
| +--------------+ IPv6 network
| |
+------------------+
Figure 1: 6a44 Applicability Scenarios
図1：6a44の適用シナリオ
In both configurations, the ISP network may also assign IPv6 prefixes to customer sites:
どちらの構成でも、ISPネットワークはIPv6プレフィックスを顧客サイトに割り当てる場合があります。
o If customer sites are only assigned IPv4 addresses (IPv6 prefix available neither natively nor with any tunnel), 6a44 applies not only to sites whose CPEs are IPv4-only capable but also to those whose CPEs are dual-stack capable.
o カスタマーサイトにIPv4アドレスのみが割り当てられている場合（IPv6プレフィックスはネイティブでもトンネルでも使用できません）、6a44はCPEがIPv4のみに対応しているサイトだけでなく、CPEがデュアルスタック対応であるサイトにも適用されます。
o If customer sites are assigned both IPv4 addresses and IPv6 prefixes, 6a44 only applies to sites whose CPEs are IPv4-only capable.
o カスタマーサイトにIPv4アドレスとIPv6プレフィックスの両方が割り当てられている場合、6a44は、CPEがIPv4のみに対応しているサイトにのみ適用されます。
Figure 2 illustrates paths of IPv6 packets between a 6a44 client, A, and various possible locations of remote hosts (E in the same site, F in another 6a44 site of the same ISP, G in a non-6a44 IPv6 site of the same ISP, D in an IPv6 site of another ISP). Between 6a44 clients of a same site, IPv6 packets are encapsulated in IPv4 packets. Those between 6a44 clients and 6a44 relays are encapsulated in UDP/IPv4 packets.
図2は、6a44クライアントAと、リモートホストのさまざまな可能な場所（同じサイトのE、同じISPの別の6a44サイトのF、同じISPの非6a44 IPv6サイトのG）間のIPv6パケットのパスを示しています。 、D（別のISPのIPv6サイト）。同じサイトの6a44クライアント間で、IPv6パケットはIPv4パケットにカプセル化されます。 6a44クライアントと6a44リレー間のパケットは、UDP / IPv4パケットにカプセル化されます。
6a44 operates as follows (details in Section 6):
6a44は次のように動作します（詳細はセクション6を参照）。
1. A 6a44 client starts operation by sending a 6a44 bubble to the 6a44-relay UDP/IPv4 address.
1. 6a44クライアントは、6a44バブルを6a44-relay UDP / IPv4アドレスに送信することで動作を開始します。
2. When a 6a44 relay receives a bubble from one of its 6a44 clients, it returns to this client a bubble containing the IPv6 prefix of this client.
2. 6a44リレーは、その6a44クライアントの1つからバブルを受信すると、このクライアントに、このクライアントのIPv6プレフィックスを含むバブルを返します。
3. When a 6a44 client receives a bubble from a 6a44 relay, it updates (or confirms) its 6a44 address. It is an update if the client has no IPv6 address yet or if, due to a CPE reset, this address has changed. After receiving a bubble, a client is ready to start, or to continue, IPv6 operation.
3. 6a44クライアントが6a44リレーからバブルを受信すると、6a44アドレスを更新（または確認）します。クライアントにIPv6アドレスがまだない場合、またはCPEのリセットによりこのアドレスが変更された場合、これは更新です。バブルを受信した後、クライアントはIPv6オペレーションを開始または続行する準備が整います。
4. When a 6a44 client having a 6a44 address has an IPv6 packet to send whose destination IS in the same customer site, it encapsulates it in an IPv4 packet whose destination is found in the IPv6 destination address. It then sends the resulting IPv6/ IPv4 packet.
4. 6a44アドレスを持つ6a44クライアントが送信するIPv6パケットを持ち、その宛先が同じカスタマーサイトにある場合、宛先がIPv6宛先アドレスにあるIPv4パケットにそれをカプセル化します。次に、結果のIPv6 / IPv4パケットを送信します。
5. When a 6a44 client receives a valid IPv6/IPv4 packet from a 6a44 client of the same site, it decapsulates the IPv6 packet and submits it to further IPv6 processing.
5. 6a44クライアントは、同じサイトの6a44クライアントから有効なIPv6 / IPv4パケットを受信すると、IPv6パケットのカプセル化を解除し、それをさらにIPv6処理に送信します。
6. When a 6a44 client having a 6a44 address has an IPv6 packet to send whose destination IS NOT in the same customer site, it encapsulates the packet in a UDP/IPv4 packet whose destination is the 6a44-relay UDP/IPv4 address. It then sends the IPv6/UDP/ IPv4 packet.
6. 6a44アドレスを持つ6a44クライアントが送信するIPv6パケットを持ち、その宛先が同じカスタマーサイトにない場合、宛先が6a44-relay UDP / IPv4アドレスであるUDP / IPv4パケットにパケットをカプセル化します。次に、IPv6 / UDP / IPv4パケットを送信します。
7. When a 6a44 relay receives via its IPv4 interface a valid IPv6/ UDP/IPv4 packet whose destination IS one of its 6a44 clients, it forwards the contained IPv6 packet in a modified IPv6/UDP/IPv4 packet. The UDP/IPv4 destination of this packet is found in the IPv6 destination address.
7. 6a44リレーは、IPv4インターフェースを介して、その宛先が6a44クライアントの1つである有効なIPv6 / UDP / IPv4パケットを受信すると、含まれているIPv6パケットを変更されたIPv6 / UDP / IPv4パケットで転送します。このパケットのUDP / IPv4宛先は、IPv6宛先アドレスにあります。
8. When a 6a44 client receives a valid IPv6/UDP/IPv4 packet from a 6a44 relay, it decapsulates the IPv6 packet and submits it to further IPv6 processing.
8. 6a44クライアントは、6a44リレーから有効なIPv6 / UDP / IPv4パケットを受信すると、IPv6パケットのカプセル化を解除し、それをさらにIPv6処理に送信します。
9. When a 6a44 relay receives via its IPv4 interface a valid IPv6/ UDP/IPv4 packet whose IPv6 destination IS NOT one of its 6a44 clients, it decapsulates the IPv6 packet and sends it via its IPv6 interface.
9. 6a44リレーは、IPv6宛先がその6a44クライアントの1つではない有効なIPv6 / UDP / IPv4パケットをIPv4インターフェース経由で受信すると、IPv6パケットのカプセル化を解除し、IPv6インターフェース経由で送信します。
10. When a 6a44 relay receives via its IPv6 interface a valid IPv6 packet whose destination is one of its 6a44 clients, it encapsulates the packet in a UDP/IPv4 packet whose destination is the UDP/IPv4 address found in the IPv6 destination address. It then sends the resulting IPv6/UDP/IPv4 packet via its IPv4 interface.
10. 6a44リレーは、6a44クライアントの1つを宛先とする有効なIPv6パケットをIPv6インターフェース経由で受信すると、IPv6宛先アドレスにあるUDP / IPv4アドレスを宛先とするUDP / IPv4パケットにパケットをカプセル化します。次に、結果のIPv6 / UDP / IPv4パケットをIPv4インターフェース経由で送信します。
11. To maintain the NAT44 mapping of its 6a44 tunnel, and to quickly detect the need to change its 6a44 address in case of NAT44 reset, a 6a44 client from time to time sends a bubble to the 6a44-relay address (see Section 6.5.1).
11. 6a44トンネルのNAT44マッピングを維持し、NAT44リセットの場合に6a44アドレスを変更する必要性をすばやく検出するために、6a44クライアントは6a44リレーアドレスにバブルを送信します（6.5.1を参照）。 。
12. When a 6a44 relay receives via its IPv4 interface an IPv6/UDP/ IPv4 packet whose IPv6 and UDP/IPv4 source addresses are not consistent, it discards the invalid packet and returns a bubble to the UDP/IPv4 source address. (This permits the 6a44 client at this address to update its IPv6 address.)
12. 6a44リレーは、IPv6とUDP / IPv4の送信元アドレスが一致しないIPv6 / UDP / IPv4パケットをIPv4インターフェース経由で受信すると、無効なパケットを破棄し、UDP / IPv4送信元アドレスにバブルを返します。 （これにより、このアドレスの6a44クライアントはIPv6アドレスを更新できます。）
CUSTOMER +-------------------------+
SITES | ISP NETWORK |
+---------+ +----------------+ |
| | |6a44 ISP NETWORK| | GLOBAL
| | | | | INTERNET
HOSTS | IPv6/UDP/IPv4 +---------+ | HOST
+-+ | +-----+ | B| 6a44 |C/48| IPv6 +-+
|A|---|--.---|NAT44|----|----------.---------.----|--- - - - ---|D|
+-+ | \ +-----+ | /| relay(s)|\ | +-+
+-+ | / | | ' +---------+ ' |
|E|---|--' | | | | | |
+-+ IPv6/IPv4 | | | | | |
+---------+ | | | | |
| | | | |
+---------+ | | | | |
| IPv6/UDP/IPv4 . | | |
+-+ | +-----+ | / | | |
|F|---|------|NAT44|----|------' | | |
+-+ | +-----+ | | | |
| | +----------------+ | |
+---------+ | . |
+-+ | / |
|G|---- - - - - - - ----|--------------------' |
+-+ IPv6 | |
+-------------------------+
IPv6 PATHS A-D: D is IPv6 of another ISP A-E: E is a 6a44 client in the same site A-F: F is a 6a44 client in another site of the same ISP A-G: G is IPv6 of the same ISP, other than 6a44
IPv6パスA-D：Dは別のISPのIPv6 A-E：Eは同じサイトの6a44クライアントA-F：Fは同じISPの別のサイトの6a44クライアントA-G：Gは6a44以外の同じISPのIPv6
Figure 2: IPv6 Paths between 6a44 Hosts and Remote Hosts
図2：6a44ホストとリモートホスト間のIPv6パス
The 6a44 IPv6 address an ISP assigns to a host must contain all pieces of information needed to reach it from other IPv6 addresses. These pieces are described below and illustrated in Figure 3:
ISPがホストに割り当てる6a44 IPv6アドレスには、他のIPv6アドレスからホストに到達するために必要なすべての情報が含まれている必要があります。これらの要素を以下に説明し、図3に示します。
o the 6a44-network IPv6 prefix C (a /48 the ISP has assigned to its 6a44 relays);
o 6a44ネットワークのIPv6プレフィックスC（ISPが6a44リレーに割り当てた/ 48）。
o the customer-site IPv4 address N (either global IPv4 or, if the ISP uses a [NAT444] model, private IPv4);
o 顧客サイトのIPv4アドレスN（グローバルIPv4、またはISPが[NAT444]モデルを使用している場合はプライベートIPv4）。
o the mapped port Z of the 6a44 tunnel (i.e., the external port assigned by the NAT44 to the tunnel that the client maintains between its UDP/IPv4 local address A:W and the 6a44-relay UDP/IPv4 address B:W);
o 6a44トンネルのマッピングされたポートZ（つまり、クライアントがUDP / IPv4ローカルアドレスA：Wと6a44リレーUDP / IPv4アドレスB：Wの間で維持するトンネルにNAT44によって割り当てられた外部ポート）
o the client local IPv4 address A (i.e., the private IPv4 address assigned to the client in its customer site; it is needed for intra-site IPv6 connectivity).
o クライアントのローカルIPv4アドレスA（つまり、顧客サイトでクライアントに割り当てられたプライベートIPv4アドレス。サイト内IPv6接続に必要です）。
Customer network ISP network
+--------------+ +------------------+
Client |IPv4 CPE |IPv4 |
+----+ | +-----+ | +----------+
| ^ |-----| |NAT44|----+ |6a44 relay|---- IPv6
+-|-^+ | +-----+ | +----------+^
| | | ^ | ^ | ^ | |
| | +----------|---+ | +---------|--------+ |
| | | ^ | | |
| | >0/0| | |N/32< | |
| | | | |
| | Mapping | |
| | <a:w>-<N:Z> (*) | |
| | | |
| |A:W< >B:W| |
| |
IPv6 |C.N.Z.A/128< |C/48<
(*) With NAT44(s) between client and CPE, a:w may differ from A:W
|0 47|48 79|80 95|96 127|
+-------+-------+-------+-------+-------+-------+-------+-------+
| 6a44-network | Customer-site |Tunnel | 6a44-client |
| IPv6 prefix | IPv4 address |mapped | local IPv4 |
| (C) | (N) |port(Z)| address (A) |
+-------+-------+-------+-------+-------+-------+-------+-------+
6a44-client
<-- UDP/IPv4 address -->
<------------ 6a44-client IPv6 prefix --------->
<---------------- 6a44-client IPv6 address --------------------->
Figure 3: Host-Address Construction
図3：ホストアドレスの構成
NOTE: 6a44 addresses are not guaranteed to comply with the rule listed in [RFC4291], according to which bits 64-127 of aggregatable unicast addresses have to be in Modified-EUI-64 Interface Identifier (IID) format. However, these bits within the 6a44 addresses are interpreted only where 6a44 addresses are processed, i.e., in 6a44 relays and clients. No operational problem is therefore foreseen. Besides, because it is a purely transitional tool, it shouldn't prevent any "development of future technology that can take advantage of interface identifiers with universal scope" (the purpose of this format, as expressed in [RFC4291].
注：6a44アドレスは、[RFC4291]にリストされているルールに準拠しているとは限りません。集約可能なユニキャストアドレスのビット64〜127は、Modified-EUI-64 Interface Identifier（IID）形式である必要があります。ただし、6a44アドレス内のこれらのビットは、6a44アドレスが処理される場所、つまり6a44リレーとクライアントでのみ解釈されます。したがって、運用上の問題は予想されません。さらに、それは純粋に移行ツールであるため、「ユニバーサルスコープのインターフェイス識別子を利用できる将来の技術の開発」（このフォーマットの目的、[RFC4291]で表現されているとおり）を妨げるべきではありません。
For NAT44 traversal, an IPv6 packet transmitted from a 6a44 client to a 6a44 relay, or vice versa, is encapsulated in a UDP/IP packet whose source and destination addresses are those of the two endpoints (A:W and B:W in the notations of Figure 3). The IPv4 packet is that of a complete datagram (its more-fragment bit is set to 0, its offset is set to 0, and its datagram identification may be set to 0). The UDP checksum is set to 0 (there is no need for an additional layer of checksum protection). The length of the IPv6 packet SHOULD NOT exceed 1280 octets (see Section 6.4).
NAT44トラバーサルの場合、6a44クライアントから6a44リレーに、またはその逆に送信されるIPv6パケットは、送信元アドレスと宛先アドレスが2つのエンドポイント（A：WおよびB：Wのアドレス）であるUDP / IPパケットにカプセル化されます。図3の表記）。 IPv4パケットは完全なデータグラムのパケットです（そのフラグメントビットは0に設定され、オフセットは0に設定され、データグラムIDは0に設定される場合があります）。 UDPチェックサムは0に設定されています（チェックサム保護の追加レイヤーは必要ありません）。 IPv6パケットの長さは1280オクテットを超えてはなりません（SHOULD NOT）（セクション6.4を参照）。
Octets: |0 |20 |28 |68 |
+----------+---+-------------------+-------//-----+
| IPv4 |UDP| IPv6 header | IPv6 payload |
+----------+---+-------------------+-------//-----+
An IPv6 packet transmitted from a 6a44 client to another 6a44 client of the same site is encapsulated in an IPv4 packet whose source and destination addresses are the private IPv4 addresses of the two hosts. The IPv4 packet is that of a complete datagram (its more-fragment bit is set to 0, its offset is set to 0, and its datagram identification may be set to 0). The size of the IPv6 packet SHOULD NOT exceed 1280 octets (see Section 6.4).
6a44クライアントから同じサイトの別の6a44クライアントに送信されるIPv6パケットは、送信元アドレスと宛先アドレスが2つのホストのプライベートIPv4アドレスであるIPv4パケットにカプセル化されます。 IPv4パケットは完全なデータグラムのパケットです（そのフラグメントビットは0に設定され、オフセットは0に設定され、データグラムIDは0に設定される場合があります）。 IPv6パケットのサイズは1280オクテットを超えてはなりません（SHOULD NOT）（セクション6.4を参照）。
Octets: |0 |20 |60 |
+----------+-------------------+-------//-----+
| IPv4 | IPv6 header | IPv6 payload |
+----------+-------------------+-------//-----+
A "bubble" is a UDP/IPv4 packet whose UDP payload is comprised of a "6a44-client IPv6 prefix" field and a "Bubble ID" field and whose UDP checksum is set to 0. Having no UDP checksum protection in bubbles is a simplification that is acceptable because bubble contents are regularly updated and non-critical (a client accepting a corrupted IPv6 prefix never leads to any IPv6 packet being accepted by any wrong destination).
「バブル」は、UDPペイロードが「6a44クライアントIPv6プレフィックス」フィールドと「バブルID」フィールドで構成され、UDPチェックサムが0に設定されているUDP / IPv4パケットです。バブル内にUDPチェックサム保護がないと、バブルの内容は定期的に更新され、重要ではないため、許容できる簡略化（破損したIPv6プレフィックスを受け入れるクライアントが、誤った宛先によってIPv6パケットが受け入れられることは決してありません）。
"6a44-client IPv6 prefix" field
. from a 6a44 client = 0 (also denoted by ::/96)
. from a 6a44 relay = 6a44-client IPv6 prefix
|
Octets: |0 |20 |28| |40 |48
+----------+---+--|-+---+
| IPv4 |UDP| . | . |
+----------+---+----+-|-+
|
"Bubble ID" field
. from a 6a44 client: a client-selected value
. from a 6a44 relay:
- in a response bubble, copy of the received Bubble ID
- in an error-signaling bubble, 0
Figure 4: 6a44 Bubble Format
図4：6a44バブル形式
In a bubble from a 6a44 client to a 6a44 relay, the "6a44-client IPv6 prefix" field is only reserved space for the response and is set to 0. In a bubble from a 6a44 relay to a 6a44 client, this field contains the IPv6 prefix of the client, left-justified.
6a44クライアントから6a44リレーへのバブルでは、「6a44-client IPv6 prefix」フィールドは応答用に予約されているスペースであり、0に設定されています。6a44リレーから6a44クライアントへのバブルでは、このフィールドにはクライアントのIPv6プレフィックス、左揃え。
In a bubble from a 6a44 client to a 6a44 relay, the "Bubble ID" field contains a randomly chosen value, renewed under the circumstances defined in Section 6.5.1. In a bubble from a 6a44 relay to a 6a44 client, if the bubble is a response to a bubble received from the client, the field contains the value found in the received bubble; if the bubble is a reaction to a received IPv6/UDP/IPv4 packet whose IPv6 and UDP/IPv4 sources are inconsistent (i.e., not conforming to R44-2 condition (3) in Section 6.6.2), the field is set to 0. The purpose of this field is to protect against 6a44-relay spoofing attacks (see Section 7).
6a44クライアントから6a44リレーへのバブルでは、「バブルID」フィールドにランダムに選択された値が含まれ、6.5.1項で定義された状況で更新されます。 6a44リレーから6a44クライアントへのバブルでは、バブルがクライアントから受信したバブルへの応答である場合、フィールドには受信したバブルで見つかった値が含まれます。バブルが受信したIPv6 / UDP / IPv4パケットへの反応であり、そのIPv6とUDP / IPv4の送信元が一致しない場合（つまり、6.6.2のR44-2条件（3）に準拠していない場合）、フィールドは0に設定されますこのフィールドの目的は、6a44リレースプーフィング攻撃から保護することです（セクション7を参照）。
In order to preserve forward compatibility with any extension of bubble formats -- should one prove useful in the future -- 6a44 clients and 6a44 relays MUST be configured to receive bubbles whose UDP payload lengths are longer than 20 octets (up to that of an IPv6- packet header since, as detailed in Sections 6.5.3 and 6.6.2, bubbles are recognized by the fact that their lengths are shorter than that of tunneled IPv6 packets).
バブル形式の任意の拡張との上位互換性を維持するために、将来的に有用であることが判明した場合、6a44クライアントと6a44リレーは、UDPペイロード長が20オクテットより長い（IPv6のそれまで）バブルを受信するように構成する必要があります-セクション6.5.3および6.6.2で詳述されているように、バブルはその長さがトンネル化されたIPv6パケットの長さよりも短いという事実によって認識されるため、パケットヘッダー。
Reassembly of a fragmented IPv4 datagram necessitates that its identifier be remembered from reception of the first fragment to reception of the last one, and necessitates a timeout protection against packet losses. If such stateful IP-layer processing would be necessary for 6a44, it would make it more complex than needed, would introduce a vulnerability to denial-of-service attacks, and would impose the restriction that all fragments of a fragmented IPv4 datagram go to the same relay. This last point would be a constraint on how load balancing may be performed between multiple 6a44 relays, and would therefore be detrimental to scalability.
フラグメント化されたIPv4データグラムの再構成では、最初のフラグメントの受信から最後のフラグメントの受信までその識別子を記憶する必要があり、パケット損失に対するタイムアウト保護が必要です。 6a44にこのようなステートフルIPレイヤー処理が必要な場合、必要以上に複雑になり、サービス拒否攻撃に対する脆弱性が導入され、フラグメント化されたIPv4データグラムのすべてのフラグメントが同じリレー。この最後のポイントは、複数の6a44リレー間でロードバランシングを実行する方法の制約となるため、スケーラビリティに悪影響を及ぼします。
For 6a44 processing to remain completely stateless, IPv4 packets containing encapsulated IPv6 packets must never be fragmented (DF always set to 1). For this requirement to be met, the following apply:
6a44処理を完全にステートレスに保つには、カプセル化されたIPv6パケットを含むIPv4パケットをフラグメント化しないでください（DFは常に1に設定されています）。この要件を満たすには、以下が適用されます。
o In customer sites, 6a44 clients MUST have IPv4 link MTUs that support encapsulated IPv6 packets of lengths up to 1280 octets, i.e., for IPv6/UDP/IPv4 packets that traverse the CPE, link MTUs of at least 1280+20+8=1308 octets. (This condition is in general satisfied.)
o 顧客サイトでは、6a44クライアントは、最大1280オクテットのカプセル化されたIPv6パケットをサポートするIPv4リンクMTUを持つ必要があります。つまり、CPEを通過するIPv6 / UDP / IPv4パケットの場合、少なくとも1280 + 20 + 8 = 1308オクテットのリンクMTU 。 （この条件は一般に満たされています。）
o For the same reason, 6a44 ISP networks must have IPv4 path MTUs of at least 1308 octets. (This condition is in general satisfied.)
o 同じ理由で、6a44 ISPネットワークには、少なくとも1308オクテットのIPv4パスMTUが必要です。 （この条件は一般に満たされています。）
o 6a44 clients SHOULD limit the size of IPv6 packets they transmit to 1280 octets.
o 6a44クライアントは、送信するIPv6パケットのサイズを1280オクテットに制限する必要があります（SHOULD）。
o 6a44 relays SHOULD set their IPv6 MTU to 1280. (If a relay receives an IPv6 packet longer than this MTU via its IPv6 upstream interface, it MUST return an ICMPv6 Packet Too Big error message.) Typical ISP networks have path MTUs that would permit IPv6 MTUs of 6a44 devices to be longer than 1280 octets, but accepting 1280 octets is a precaution that guarantees against problems with customer sites that may have internal path MTUs smaller than those supported by their ISP networks.
o 6a44リレーは、IPv6 MTUを1280に設定する必要があります（リレーがIPv6アップストリームインターフェイスを介してこのMTUよりも長いIPv6パケットを受信した場合、ICMPv6パケットが大きすぎるというエラーメッセージを返す必要があります）。一般的なISPネットワークには、IPv6を許可するパスMTUがあります6a44デバイスのMTUは1280オクテットより長くする必要がありますが、1280オクテットを受け入れることは、ISPネットワークでサポートされているものよりも小さい内部パスMTUを持つ可能性のある顧客サイトの問題を保証する予防策です。
For a 6a44-client IPv6 address to remain valid, the port mapping of the 6a44 tunnel MUST be maintained in the CPE NAT44.
6a44クライアントのIPv6アドレスを有効に保つには、6a44トンネルのポートマッピングをCPE NAT44で維持する必要があります。
For this, the 6a44 client SHOULD apply the equivalent of the following TM-x rules, as illustrated in Figure 5.
このため、6a44クライアントは、図5に示すように、以下のTM-xルールと同等のものを適用する必要があります（SHOULD）。
TM-1 At initialization, a timer value T1 is randomly chosen in the recommended range of 1 to 1.5 seconds, and the "6a44 disabled" state is entered. (Randomness of this value is a precaution to avoid the following scenario: if many hosts happened to be re-initialized at the same time, the bubble traffic resulting from the following rules would be synchronized.)
TM-1初期化時に、タイマー値T1が1〜1.5秒の推奨範囲でランダムに選択され、「6a44無効」状態になります。 （この値のランダム性は、次のシナリオを回避するための予防策です。多くのホストが同時に再初期化された場合、以下のルールに起因するバブルトラフィックが同期されます。）
TM-2 In the "6a44-disabled" state, if it appears that the interface has no IPv6 native address BUT has a private IPv4 address, then (1) the Attempt count (a local variable) is set to 1; (2) a new Bubble ID (another local variable) is randomly chosen (it is not critical how random this new value is, as explained in Section 7); (3) a bubble is sent with this Bubble ID; (4) the "Bubble sent" state is entered with the timer set to T1.
TM-2「6a44-disabled」状態で、インターフェイスにIPv6ネイティブアドレスがないように見えますが、プライベートIPv4アドレスがあります。（1）試行回数（ローカル変数）は1に設定されます。 （2）新しいバブルID（別のローカル変数）がランダムに選択されます（セクション7で説明するように、この新しい値がどれだけランダムであるかは重要ではありません）。 （3）このバブルIDでバブルが送信されます。 （4）タイマーがT1に設定された状態で、「バブル送信」状態になります。
TM-3 In the "Bubble sent" state, if the timer expires AND the Attempt count is less than 4, then (1) the Attempt count is increased by 1; (2) a new bubble is sent with the current Bubble ID; (3) the "Bubble sent" state is re-entered with the timer reset to T1.
TM-3「バブル送信」状態で、タイマーが切れ、かつ試行回数が4未満の場合、（1）試行回数が1増加します。 （2）新しいバブルが現在のバブルIDで送信されます。 （3）タイマーがT1にリセットされ、「バブル送信」状態に再び入ります。
TM-4 In the "Bubble sent" state, if a bubble is received, then (1) the 6a44-client IPv6 address is set to the received 6a44-client IPv6 prefix followed by the host local IPv4 address; (2) the "Bubble received" state is entered with the timer set to T2, whose recommended value is 30 seconds minus 4 times T1.
TM-4「Bubble sent」状態で、バブルを受信すると、（1）6a44-client IPv6アドレスが、受信した6a44-client IPv6プレフィックスに設定され、その後にホストのローカルIPv4アドレスが続きます。 （2）タイマーをT2に設定して「バブル受信」状態に入ります。推奨値は30秒からT1の4倍を引いた値です。
TM-5 In the "Bubble sent" state, if timer T1 expires AND the Attempt count is equal to 4, then the "No 6a44 relay" state is entered with the timer set to T3, whose recommended value is 30 minutes.
TM-5「バブル送信」状態で、タイマーT1が満了し、試行回数が4に等しい場合、タイマーがT3に設定された「6a44リレーなし」状態になり、推奨値は30分です。
TM-6 In the "Bubble sent" state, OR the "Bubble received" state, OR the "No 6a44 relay" state, if an IPv6 native address is obtained by some other means, OR if the private IPv4 address of the host is no longer valid, then (1) the timer is disarmed; (2) the "6a44 disabled" state is entered.
TM-6「バブル送信」状態、「バブル受信」状態、または「6a44リレーなし」状態で、IPv6ネイティブアドレスが他の手段で取得されている場合、またはホストのプライベートIPv4アドレスが有効ではなくなった場合、（1）タイマーが解除されます。 （2）「6a44無効」状態になります。
TM-7 In the "Bubble received" state, if timer T2 expires, then (1) the Attempt count is reset to 1; (2) a new Bubble ID is randomly chosen; (3) a bubble is sent with this Bubble ID; (4) the "Bubble sent" state is entered with the timer set to T1.
TM-7「バブル受信」状態で、タイマーT2が満了すると、（1）試行カウントが1にリセットされます。 （2）新しいバブルIDがランダムに選択されます。 （3）このバブルIDでバブルが送信されます。 （4）タイマーがT1に設定された状態で、「バブル送信」状態になります。
TM-8 In the "Bubble received" state, if a bubble is received, then the timer is reset to T2. (NOTE: Since a bubble is received by a 6a44 client either in response to a bubble it has sent or in reaction to a packet it has sent with inconsistent IPv6 and UDP/IPv4 source addresses, receiving a bubble is a sign that the tunnel mapping reported in the received bubble prefix has recently been used in BOTH directions, a condition required by some NAT44s to maintain their mappings.)
TM-8「バブル受信」状態で、バブルを受信すると、タイマーがT2にリセットされます。 （注：バブルは、送信したバブルへの応答として、またはIPv6とUDP / IPv4のソースアドレスに一貫性のない送信したパケットへの反応として、6a44クライアントによって受信されるため、バブルの受信は、トンネルマッピングの兆候です受信したバブルプレフィックスで報告されたは最近、双方向で使用されています。これは、一部のNAT44がマッピングを維持するために必要な条件です。
TM-9 In the "No 6a44 relay" state, if the timer expires, then (1) the Attempt count is reset to 1; (2) a new Bubble ID is randomly chosen; (3) a bubble is sent with this Bubble ID; (4) the "Bubble sent" state is entered with the timer set to T1.
TM-9「6a44リレーなし」状態で、タイマーが期限切れになると、（1）試行回数が1にリセットされます。 （2）新しいバブルIDがランダムに選択されます。 （3）このバブルIDでバブルが送信されます。 （4）タイマーがT1に設定された状態で、「バブル送信」状態になります。
Initialization
________v________
/ \
| "6a44 disabled" |------------<-----------------+
\_________________/ ^
v no v6-add AND v4-add ^
+--------->--------------v ^
^ +--------------v--------------+ ^
^ | Reset the Attempt count | ^
^ | Renew the Bubble ID | ^
^ +--------------+--------------+ ^
^ +----->-------------v ^
^ ^ +--------------v--------------+ ^
^ ^ | Send a bubble | ^
^ ^ +--------------v--------------+ ^
^ ^ ________v________ ^
^ ^ Timer T1 / \ 4 attempts without answer ^
^ +----<-----| "Bubble sent" |-------->----------------+ ^
^ (1 to 1.5 s)\_________________/ v ^
^ v \ v6-add OR no v4-add v ^
^ Bubble received v +-----------------------------+
^ v-----------------<-----------+ v ^
^ _________v_________ ^ v ^
^ Timer T2 / \Bubble received ^ v ^
+----------<---| "Bubble received" |-------->----------+ v ^
^ (30 s - 4*T1)\___________________/ v ^
^ \ v6-add OR no v4-add v ^
^ +------->--------------------+
^ v ^
^ +----------------------------------+ ^
^ _______v________ ^
^ Timer T3 / \ v6-add OR no v4-add ^
+-----------<----| "No 6a44 relay" |----->-----------------------+
(30 min) \_________________/
Figure 5: Tunnel Maintenance Algorithm
図5：トンネルメンテナンスアルゴリズム
A 6a44 client transmits packets according to the following CT-x rules. In figures that illustrate these rules, symbols used in Section 5 are reused; packets are represented as a succession of significant fields separated by commas, with sources preceding destinations as usual; != means "different from".
6a44クライアントは、次のCT-xルールに従ってパケットを送信します。これらの規則を示す図では、セクション5で使用されている記号が再利用されています。パケットは、コンマで区切られた一連の重要なフィールドとして表され、送信元は通常どおり宛先の前にあります。 ！=は「と異なる」を意味します。
CT-1 BUBBLE SENT BY A 6a44 CLIENT
6a44クライアントから送信されたCT-1バブル
(IPv4, A, B, UDP[W, W, ::/96, <current Bubble ID>])
|
+-------+--------+ |
| | 6a44 | |
| | client +------>---------- >B:W
| |function|A:W< UDP/IPv4
+-------+--------+
Host
Bubbles are transmitted from time to time. Conditions of their transmission are specified in Section 6.5.1, and their format is specified in Section 6.3.
泡は時々送信されます。それらの送信の条件はセクション6.5.1で指定されており、それらのフォーマットはセクション6.3で指定されています。
CT-2 IPv6/IPv4 PACKET SENT TO A HOST OF THE SAME SITE
CT-2 IPv6 / IPv4パケットが同じサイトのホストに送信されました
[IPv6, <C.N.Z.A>, <C.N..E>,...]
|
| (IPv4, A, A2, IP-in-IP[encapsulated packet])
| |
+----|--+--------+ |
| | | 6a44 | |
| -->--+ client +------>------ >A2
| IPv6 |function|<A IPv4
+-------+--------+
Host
If an IPv6 packet is submitted for transmission with ALL the following conditions satisfied, the 6a44 client MUST encapsulate the IPv6 packet in an IPv4 packet whose protocol is set to IP in IP (protocol = 41) and whose IPv4 destination is copied from the last 32 bits of the IPv6 destination: (1) the IPv6 source address is the 6a44-client IPv6 address; (2) the IPv6 destination is a 6a44 address of the same site (it has the same 80 bits as the 6a44-client IPv6 address); (3) either the IPv6 packet does not exceed 1280 octets, or it is longer but it does not exceed the IPv4 link MTU minus 20 octets and the IPv4 destination address starts with the IPv4 link prefix.
IPv6パケットが送信のために送信され、次のすべての条件を満たす場合、6a44クライアントは、プロトコルがIP in IP（プロトコル= 41）に設定され、IPv4宛先が最後の32からコピーされたIPv4パケットにIPv6パケットをカプセル化する必要がありますIPv6宛先のビット：（1）IPv6送信元アドレスは6a44クライアントIPv6アドレスです。 （2）IPv6宛先は同じサイトの6a44アドレスです（6a44クライアントのIPv6アドレスと同じ80ビットです）。 （3）IPv6パケットが1280オクテットを超えないか、それより長いが、IPv4リンクMTU-20オクテットを超えず、IPv4宛先アドレスがIPv4リンクプレフィックスで始まる。
CT-3 IPv6/UDP/IPv4 PACKET TO A HOST OF ANOTHER SITE
他のサイトのホストへのCT-3 IPv6 / UDP / IPv4パケット
[IPv6, <C.N.Z.A>, X != <C.N...>, ...]
|
| (IPv4, B, A, UDP(W, W, [encapsulated packet])
| |
+----|--+--------+ |
| | | 6a44 | |
| -->--+ client +------>---------- >B:W
| IPv6 |function|A:W< UDP/IPv4
+-------+--------+
Host
If an IPv6 packet is submitted for transmission and ALL the following conditions are satisfied, the IPv6 packet MUST be encapsulated in a UDP/IPv4 packet whose destination is the 6a44-relay anycast address and whose source and destination ports are both the 6a44 port: (1) the source address is the local 6a44-client IPv6 address; (2) the destination is not a 6a44 address of the same site (its first 80 bits differ from those of the 6a44-client IPv6 address); (3) the IPv6 packet does not exceed 1280 octets.
IPv6パケットが送信のために送信され、次のすべての条件を満たす場合、IPv6パケットは、宛先が6a44リレーエニーキャストアドレスであり、送信元ポートと宛先ポートが両方とも6a44ポートであるUDP / IPv4パケットにカプセル化する必要があります（ 1）ソースアドレスはローカルの6a44クライアントIPv6アドレスです。 （2）宛先が同じサイトの6a44アドレスではない（最初の80ビットが6a44クライアントIPv6アドレスのアドレスと異なる）。 （3）IPv6パケットが1280オクテットを超えない。
CT-4 IPv6 PACKET THAT DOESN'T CONCERN 6a44
6a44に関係のないCT-4 IPv6パケット
If an IPv6 packet is submitted to the 6a44 client function for transmission with an IPv6 source address that is not the 6a44-client IPv6 address, the packet does not concern 6a44. It MUST be left for any other IPv6 transmission function that may apply (the source address can be a link-local address or a Unique Local Address (ULA) [RFC4193]).
IPv6パケットが6a44クライアント機能に送信され、6a44クライアントIPv6アドレスではないIPv6送信元アドレスで送信される場合、パケットは6a44に関係しません。適用される可能性のある他のIPv6送信機能のために残しておく必要があります（送信元アドレスは、リンクローカルアドレスまたは一意のローカルアドレス（ULA）[RFC4193]にすることができます）。
Upon reception of an IPv4 packet, a 6a44 client applies the following CR-x rules:
IPv4パケットを受信すると、6a44クライアントは次のCR-xルールを適用します。
CR-1 BUBBLE RECEIVED FROM A 6a44 RELAY
6a44リレーから受け取ったCR-1バブル
(IPv4, B, A, UDP(W, W, [<C.N.Z>, <current Bubble ID>])
|
+-------+--------+ |
| | 6a44 | |
| | client +------<---------- <B:W
| | |A:W< UDP/IPv4
+-------+--------+
Host
(updates C.N.Z)
If ALL the following conditions are satisfied (i.e., the packet is a 6a44 bubble from a 6a44 relay), the 6a44-client IPv6 address MUST be updated using the received IPv6 prefix C.N.Z: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) both ports of the UDP datagram are the 6a44 port, and the payload length is enough to contain a 6a44-client IPv6 prefix and a Bubble ID but shorter than an IPv6-packet header (protocol = 17, UDP payload length = at least 20 octets and less than 40 octets); (3) the received Bubble ID matches the current value of the Bubble-ID local variable.
以下のすべての条件が満たされている場合（つまり、パケットが6a44リレーからの6a44バブルである場合）、6a44クライアントIPv6アドレスは、受信したIPv6プレフィックスCNZを使用して更新する必要があります：（1）IPv4パケットには完全なUDPデータグラム（プロトコル= 17、オフセット= 0、フラグメントビット= 0）; （2）UDPデータグラムの両方のポートは6a44ポートであり、ペイロード長は6a44クライアントIPv6プレフィックスとバブルIDを含むのに十分ですが、IPv6-packetヘッダーより短い（プロトコル= 17、UDPペイロード長= at 20オクテット以上40オクテット未満）。 （3）受信したBubble IDは、Bubble-IDローカル変数の現在の値と一致します。
CR-2 IPv6/IPv4 PACKET FROM A HOST OF THE SAME SITE
同じサイトのホストからのCR-2 IPv6 / IPv4パケット
(IPv4, E, A, IP-in-IP, [IPv6, <C.N..A2>, <C.N.Z.A>, ...])
|
[decapsulated packet] |
| |
+----|--+--------+ |
| | | 6a44 | |
| --<--+ client +------<------ <A2
| IPv6 | |A< IPv4
+-------+--------+
Host
If ALL the following conditions are satisfied (i.e., the packet comes from a 6a44 client of the same site), the 6a44 client MUST decapsulate the inner packet and treat it as a received IPv6 packet: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) both ports of the UDP datagram are the 6a44 port, and the UDP payload is an IPv6 packet (UDP length of at least 40 octets, version = 6); (3) the IPv6 source address is one of the same site (the first 80 bits match those of the 6a44-client IPv6 address; (4) its last 32 bits are equal to the IPv4 source address; (5) the IPv6 destination address is the 6a44-client IPv6 address.
次の条件がすべて満たされた場合（つまり、パケットが同じサイトの6a44クライアントから送信された場合）、6a44クライアントは内部パケットのカプセル化を解除し、受信したIPv6パケットとして扱う必要があります。（1）IPv4パケットには完全なUDPが含まれるデータグラム（プロトコル= 17、オフセット= 0、フラグメントビット= 0）; （2）UDPデータグラムの両方のポートは6a44ポートであり、UDPペイロードはIPv6パケット（少なくとも40オクテットのUDP長、バージョン= 6）です。 （3）IPv6送信元アドレスが同じサイトの1つである（最初の80ビットが6a44クライアントIPv6アドレスのビットと一致する;（4）最後の32ビットがIPv4送信元アドレスと等しい;（5）IPv6宛先アドレス6a44クライアントのIPv6アドレスです。
CR-3 IPv6/UDP/IPv4 PACKET FROM A HOST OF ANOTHER SITE
別のサイトのホストからのCR-3 IPv6 / UDP / IPv4パケット
(IPv4, B, A, UDP(W, W, [IPv6, X, <C.N.Z.A>,...])
|
[decapsulated packet] |
| |
+----|--+--------+ |
| | | 6a44 | |
| --<--+ client +------<---------- <B:W
| IPv6 | |A:W< UDP/IPv4
+-------+--------+
Host
If ALL the following conditions are satisfied (i.e., the packet has been relayed by a 6a44 relay), the 6a44 client MUST decapsulate the inner packet and treat it as a received IPv6 packet: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length of at least 40 octets, version = 6); (3) the UDP/IPv4 source address is the 6a44-relay UDP/IPv4 address; (4) the IPv6 destination address is the 6a44-client IPv6 address.
以下のすべての条件が満たされた場合（つまり、パケットが6a44リレーによってリレーされた場合）、6a44クライアントは内部パケットのカプセル化を解除し、受信したIPv6パケットとして扱う必要があります。プロトコル= 17、オフセット= 0、フラグメントビット= 0）; （2）UDPペイロードはIPv6パケットです（長さが少なくとも40オクテット、バージョン= 6）。 （3）UDP / IPv4ソースアドレスは6a44-relay UDP / IPv4アドレスです。 （4）IPv6宛先アドレスは6a44クライアントIPv6アドレスです。
CR-4 RECEIVED ICMPv4 ERROR MESSAGE CONCERNING A 6a44 PACKET
6a44パケットに関するCR-4受信ICMPv4エラーメッセージ
If the 6a44 client receives an IPv4 error message [RFC0792] that concerns a discarded 6a44 packet (i.e., if the copied header of the discarded packet is that of a transmitted packet according to CT-2 or CT-3), it SHOULD translate it into an ICMPv6 error message [RFC4443] and then treat it as a received IPv6 packet. Translation of Type and Code conversions between IPv4 and IPv6 is described in Section 4.2 of [RFC6145], under "ICMPv4 error messages".
6a44クライアントが、破棄された6a44パケットに関するIPv4エラーメッセージ[RFC0792]を受信した場合（つまり、破棄されたパケットのコピーされたヘッダーがCT-2またはCT-3に従って送信されたパケットのヘッダーである場合）、それを変換する必要があります（SHOULD） ICMPv6エラーメッセージ[RFC4443]に変換し、受信したIPv6パケットとして扱います。 IPv4とIPv6間のタイプおよびコード変換の変換については、[RFC6145]のセクション4.2の「ICMPv4エラーメッセージ」で説明しています。
CR-5 RECEIVED IPv4 PACKET OTHER THAN 6a44
CR-5が6a44以外のIPv4パケットを受信
If ANY one or more of the following conditions are verified, the received IPv4 packet does not concern 6a44 and MUST therefore be left for any other IPv4 reception function that may apply: (1) the IPv4 payload is neither UDP nor IPv6 (protocol = neither 17 nor 41, or protocol = 41 and IP version in the payload is not = 6); (2) the IPv4 packet is an IP-datagram fragment other than the first one (offset > 0); (3) the IPv4 packet contains the first or unique fragment of a UDP datagram (protocol = 17, offset = 0), with neither port equal to the 6a44 port.
次の条件の1つ以上が確認された場合、受信したIPv4パケットは6a44に関係しないため、適用される可能性のある他のIPv4受信機能に任せる必要があります。（1）IPv4ペイロードがUDPでもIPv6でもない（プロトコル=どちらでもない） 17または41、またはプロトコル= 41で、ペイロードのIPバージョンが= 6ではない）; （2）IPv4パケットは、最初のもの（オフセット> 0）以外のIPデータグラムフラグメントです。 （3）IPv4パケットには、UDPデータグラムの最初のフラグメントまたは一意のフラグメント（プロトコル= 17、オフセット= 0）が含まれており、どちらのポートも6a44ポートと同じではありません。
Upon reception of a packet via its IPv6 interface with a destination address starting with the 6a44-network IPv6 prefix, a 6a44 relay MUST apply the following RR6-x rules:
6a44ネットワークのIPv6プレフィックスで始まる宛先アドレスを持つIPv6インターフェースを介してパケットを受信すると、6a44リレーは次のRR6-xルールを適用する必要があります。
RR6-1 VALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK
RR6-1 6a44 ISPネットワーク外からの有効なIPv6パケット
[IPv6, (X != <C...> AND != <Teredo(IPv4=B)>), <C.<N != B>.Z...>,...]
|
(IPv4, B, N, UDP(W, Z, |
[encapsulated packet])) |
| |
| +--------+ |
| >B:W | 6a44 |C/48< |
N:Z< ---<--------| relay |-------<---- C.N.Z...<
IPv4 | | IPv6
+--------+
If ALL the following conditions are satisfied, the IPv6 packet MUST be encapsulated in a UDP/IPv4 packet whose UDP/IPv4 destination is copied from bits 48 to 95 of the IPv6 destination address: (1) the IPv6 source address is not that of a 6a44 client of the ISP (it does not start with the 6a44-network IPv6 prefix); (2) the IPv6 source address is not a Teredo address whose embedded UDP/IPv4 address is the 6a44-relay anycast address; (3) the customer-site IPv4 address embedded in the 6a44 destination address is not the 6a44-relay anycast address; (4) the packet has at most 1280 octets.
以下のすべての条件が満たされる場合、IPv6パケットは、UDP / IPv4宛先がIPv6宛先アドレスのビット48から95にコピーされるUDP / IPv4パケットにカプセル化される必要があります。（1）IPv6送信元アドレスは、 ISPの6a44クライアント（6a44ネットワークのIPv6プレフィックスで始まりません）。 （2）IPv6送信元アドレスは、埋め込まれたUDP / IPv4アドレスが6a44リレーエニーキャストアドレスであるTeredoアドレスではありません。 （3）6a44宛先アドレスに埋め込まれた顧客サイトのIPv4アドレスは、6a44-relayエニーキャストアドレスではありません。 （4）パケットは最大1280オクテットです。
RR6-2 INVALID IPv6 PACKET FROM OUTSIDE THE 6a44 ISP NETWORK
RR6-2 6a44 ISPネットワーク外からの無効なIPv6パケット
If ANY one or more of the following conditions are satisfied, the IPv6 packet MUST be discarded: (1) the packet has more than 1280 octets (in this case, an ICMPv6 Packet Too Big error message MUST be returned to the source); (2) the customer-site IPv4 address embedded in the IPv6 destination address is the 6a44-relay anycast address; (3) the IPv6 source address is a Teredo address whose embedded IPv4 address is the 6a44-relay anycast address.
次の条件の1つ以上が満たされている場合、IPv6パケットは破棄する必要があります。（1）パケットが1280オクテットを超えている（この場合、ICMPv6パケットが大きすぎるというエラーメッセージがソースに返される必要があります）。 （2）IPv6宛先アドレスに埋め込まれた顧客サイトのIPv4アドレスは、6a44リレーエニーキャストアドレスです。 （3）IPv6送信元アドレスは、埋め込まれたIPv4アドレスが6a44リレーエニーキャストアドレスであるTeredoアドレスです。
Upon reception via its IPv4 downstream interface of an IPv4 packet that contains a complete IP datagram (fragment offset = 0 and more-fragment bit = 0) and that contains a UDP datagram whose UDP/ IPv4 destination is the 6a44-relay UDP/IPv4 address, a 6a44 relay MUST apply the following rules:
完全なIPデータグラム（フラグメントオフセット= 0およびmore-フラグメントビット= 0）を含み、UDP / IPv4宛先が6a44-relay UDP / IPv4アドレスであるUDPデータグラムを含むIPv4パケットのIPv4ダウンストリームインターフェイスを介して受信、6a44リレーは次のルールを適用する必要があります。
RR4-1 BUBBLE FROM 6a44 CLIENT
6a44クライアントからのRR4-1バブル
(IPv4, N, B, UDP(Z, W, [::/96, Bubble ID]))
|
IPv4 | +--------+
------->----| |
>B:W| 6a44 |
| relay |
N:Z< -------<----| |
IPv4 | +--------+
|
|
(IPv4, B, N, UDP(W, Z, [<C.N.Z>, Bubble ID]))
If the following condition is satisfied, the 6a44 relay MUST return to the source a bubble derived from the bubble it just received by permuting its UDP/IPv4 source and destination, and by putting in its 6a44-client-IPv6-prefix field the received UDP/IPv4 source address: the UDP payload is a bubble, i.e., has at least 20 octets and less than 40 octets.
次の条件が満たされている場合、6a44リレーは、UDP / IPv4の送信元と宛先を並べ替え、受信したUDPを6a44-client-IPv6-prefixフィールドに入力することで、受信したバブルから派生したバブルをソースに返す必要があります。 / IPv4送信元アドレス：UDPペイロードはバブルです。つまり、20オクテット以上40オクテット未満です。
RR4-2 IPv6 PACKET FROM A 6a44 CLIENT TO ANOTHER 6a44 CLIENT
6a44クライアントから別の6a44クライアントへのRR4-2 IPv6パケット
(IPv4, N1, B, UDP(Z1, W, [IPv6, <C.N1.Z1...>, <C.N2.Z2...>, ...]))
|
IPv4 | +--------+
------->----| |
>B:W| 6a44 |
| relay |
| |
N2.Z2< -------<----| |
IPv4 | +--------+
| 6a44 relay
|
(IPv4, B, N2, UDP(W, Z2, [encapsulated packet]))
If ALL the following conditions are satisfied, the 6a44 relay MUST return back via its downstream IPv4 interface an IPv6/ UDP/IPv4 packet containing the same encapsulated packet, having its UDP/IPv4 destination set to the UDP/IPv4 address found in the 6a44 destination address, and having its UDP/IPv4 source set to the 6a44-relay UDP/IPv4 address: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length of at least 40 octets, version = 6); (3) the IPv6 source address starts with the 6a44-network IPv6 prefix followed by the UDP/IPv4 source address of the received packet; (4) the IPv6 destination address starts with the 6a44-network IPv6 prefix.
次の条件がすべて満たされている場合、6a44リレーは、ダウンストリームIPv4インターフェースを介して、同じカプセル化されたパケットを含むIPv6 / UDP / IPv4パケットを返し、UDP / IPv4宛先が6a44宛先で見つかったUDP / IPv4アドレスに設定されている必要がありますアドレス、およびそのUDP / IPv4ソースが6a44-relay UDP / IPv4アドレスに設定されている場合：（1）IPv4パケットには完全なUDPデータグラムが含まれています（プロトコル= 17、オフセット= 0、フラグメントビット= 0）。 （2）UDPペイロードはIPv6パケットです（長さが少なくとも40オクテット、バージョン= 6）。 （3）IPv6送信元アドレスは6a44ネットワークのIPv6プレフィックスで始まり、その後に受信パケットのUDP / IPv4送信元アドレスが続きます。 （4）IPv6宛先アドレスは、6a44ネットワークのIPv6プレフィックスで始まります。
RR4-3 IPv6 PACKET FROM A 6a44 CLIENT TO A NON-6a44 CLIENT
6a44クライアントから6a44以外のクライアントへのRR4-3 IPv6パケット
(IPv4, N, B, UDP(Z, W, [IPv6, <C.N.Z...>,
| (X != <C...> AND != <Teredo(IPv4=B)), ...]))
|
| [decapsulated packet]
| |
| +--------+ |
| B:W>| 6a44 | |
>B:W --->----------| relay |------->---- >
IPv4 | | IPv6
+--------+
If ALL the following conditions are satisfied, the 6a44 relay MUST decapsulate the IPv6 packet and forward it via the IPv6 interface: (1) the IPv4 packet contains a complete UDP datagram (protocol = 17, offset = 0, more-fragment bit = 0); (2) the UDP payload is an IPv6 packet (length of at least 40 octets, version = 6); (3) the IPv6 source address starts with the 6a44-network IPv6 prefix followed by the UDP/IPv4 source address of the received packet; (4) the IPv6 destination address does not start with the 6a44-network IPv6 prefix and is not a Teredo address whose embedded IPv4 address is the 6a44-relay anycast address.
次の条件がすべて満たされている場合、6a44リレーはIPv6パケットのカプセル化を解除し、IPv6インターフェースを介して転送する必要があります。 ）; （2）UDPペイロードはIPv6パケットです（長さが少なくとも40オクテット、バージョン= 6）。 （3）IPv6送信元アドレスは6a44ネットワークのIPv6プレフィックスで始まり、その後に受信パケットのUDP / IPv4送信元アドレスが続きます。 （4）IPv6宛先アドレスは、6a44ネットワークのIPv6プレフィックスで始まっておらず、埋め込まれたIPv4アドレスが6a44リレーエニーキャストアドレスであるTeredoアドレスではありません。
RR4-4 RECEIVED ICMPv4 ERROR MESSAGE CONCERNING A 6a44 PACKET
6a44パケットに関するRR4-4受信ICMPv4エラーメッセージ
If the 6a44 relay receives an IPv4 error message [RFC0792] that concerns a discarded 6a44 packet (i.e., if the copied header of the discarded packet is that of a transmitted packet according to RR6-1 or RR4-2), it SHOULD translate it into an ICMPv6 error message [RFC4443] and then treat it as a received IPv6 packet. Translation of Type and Code conversions between IPv4 and IPv6 is described in Section 4.2 of [RFC6145], under "ICMPv4 error messages".
6a44リレーが、破棄された6a44パケットに関するIPv4エラーメッセージ[RFC0792]を受信した場合（つまり、破棄されたパケットのコピーされたヘッダーがRR6-1またはRR4-2に従って送信されたパケットのヘッダーである場合）、それを変換する必要があります（SHOULD） ICMPv6エラーメッセージ[RFC4443]に変換し、受信したIPv6パケットとして扱います。 IPv4とIPv6間のタイプおよびコード変換の変換については、[RFC6145]のセクション4.2の「ICMPv4エラーメッセージ」で説明しています。
RR4-5 INVALID IPv6/UDP/IPv4 PACKET
RR4-5無効なIPv6 / UDP / IPv4パケット
For ANY other case, the 6a44 relay MUST discard the packet.
それ以外の場合、6a44リレーはパケットを破棄する必要があります。
6a44 is designed as an interim transition mechanism, not to be used any longer than strictly necessary. Its sole purpose is to accelerate availability of IPv6 native addresses where, for any reason, CPEs cannot quickly be replaced, or where, for any reason, ISP networks cannot quickly support dual-stack routing or 6rd.
6a44は暫定的な移行メカニズムとして設計されており、厳密に必要な期間を超えて使用されることはありません。その唯一の目的は、何らかの理由でCPEをすばやく置き換えることができない場合、または何らかの理由でISPネットワークがデュアルスタックルーティングまたは6番目を迅速にサポートできない場合に、IPv6ネイティブアドレスの可用性を加速することです。
A 6a44-capable ISP can first have an increase in its 6a44 traffic as more and more hosts behind IPv4-only CPEs support the 6a44 client function, but it should later have a decrease in this traffic as more and more CPEs operate in dual stack.
IPv4のみのCPEの背後にあるホストが6a44クライアント機能をサポートするにつれて、6a44対応のISPは最初に6a44トラフィックを増やすことができますが、デュアルスタックで動作するCPEが増えるにつれて、このトラフィックが減少するはずです。
When this traffic becomes sufficiently negligible, the ISP may, after due prior notice, discontinue 6a44-relay operation. This terminates its sunset procedure.
このトラフィックが無視できる程度になると、ISPは、事前の通知により6a44-relayオペレーションを中止する場合があります。これにより、サンセット手順が終了します。
In a host that obtains an IPv6 native address by some means other than 6a44, the effect of having the 6a44 function in its protocol stack is inexistent. OS providers may therefore keep this function in their code for many years. When it becomes clear that the number of users of this function has become negligible, they can delete it from later releases. This terminates their sunset procedure.
6a44以外の手段でIPv6ネイティブアドレスを取得するホストでは、プロトコルスタックに6a44機能を持たせることによる影響はありません。したがって、OSプロバイダーは、この機能をコードに何年も保持する可能性があります。この機能のユーザー数がごくわずかになったことが判明した場合は、今後のリリースから削除できます。これにより、サンセット手順が終了します。
Incoming reachability:
着信到達可能性：
Hosts that acquire 6a44 addresses become reachable from the Internet in IPv6 while they remain unreachable in IPv4 at their private IPv4 addresses.
6a44アドレスを取得したホストは、IPv6でインターネットから到達可能になりますが、IPv4ではプライベートIPv4アドレスでは到達不能のままです。
For ordinary use, this should not introduce a perceptible new security risk for two reasons: (1) hosts can, without IPv6, use NAT44 hole-punching techniques such as Interactive Connectivity Establishment (ICE) [RFC5245] to receive incoming connections; (2) by default, modern operating systems that support IPv6 have their own protections against incoming connections.
通常の使用では、これは2つの理由で知覚可能な新しいセキュリティリスクをもたらすべきではありません。（1）ホストは、IPv6なしで、インタラクティブ接続確立（ICE）[RFC5245]などのNAT44ホールパンチングテクニックを使用して着信接続を受信できます。 （2）デフォルトでは、IPv6をサポートする最新のオペレーティングシステムには、着信接続に対する独自の保護機能があります。
If 6a44 reachability across an ordinary NAT44 nevertheless has to be barred, this can be done by configuring its port-forwarding function with the 6a44 port bound to any internal address that is not assigned to any host. Thus, no bubble from a 6a44 relay can reach any 6a44-capable host, and this is sufficient to prevent hosts from using 6a44.
それでも通常のNAT44を介した6a44の到達可能性を禁止する必要がある場合、これは、ホストに割り当てられていない任意の内部アドレスにバインドされた6a44ポートでポート転送機能を構成することで実行できます。したがって、6a44リレーからのバブルは6a44対応のホストに到達できません。これは、ホストが6a44を使用しないようにするのに十分です。
For more sophisticated uses with managed firewalls, default configurations generally specify that packets that are not explicitly authorized are discarded. Thus, 6a44 can be used only if the 6a44 port is deliberately opened to incoming traffic.
マネージドファイアウォールをより高度に使用するために、デフォルトの構成では、明示的に許可されていないパケットは破棄されるように指定されています。したがって、6a44は、6a44ポートが意図的に着信トラフィックに対して開かれている場合にのみ使用できます。
Subscriber authentication:
サブスクライバー認証：
Any authentication that applies to an IPv4 address extends its effect to 6a44 addresses that are derived from it.
IPv4アドレスに適用されるすべての認証は、その効果を、そこから派生した6a44アドレスにまで拡大します。
Host-address spoofing:
ホストアドレスのなりすまし：
With ingress filtering required in 6a44 ISP networks, and with the address checks specified in Section 6, no new IPv6 address-spoofing vulnerability is introduced by 6a44.
6a44 ISPネットワークで入力フィルタリングが必要であり、セクション6で指定されているアドレスチェックを使用すると、6a44による新しいIPv6アドレススプーフィングの脆弱性は導入されません。
Address-and-port scanning:
アドレスとポートのスキャン：
To mitigate the (limited) risk of a malicious user trying to scan IPv4 address/port pairs to reach a host, Teredo addresses contain 12 random bits [RFC5991]. 6a44 addresses have no random bits but contain local IPv4 addresses of clients. Since possible values of these addresses are not deterministically known from outside customer sites and are in ranges that can be configured in typical NAT44s, some protection against address and port scanning is thus achieved. This protection may be less effective than that achieved with random bits but is in any case better for 6a44 IPv6 addresses than for IPv4 addresses alone.
悪意のあるユーザーがIPv4アドレス/ポートのペアをスキャンしてホストに到達しようとする（限定的な）リスクを軽減するために、Teredoアドレスには12のランダムビットが含まれています[RFC5991]。 6a44アドレスにはランダムビットはありませんが、クライアントのローカルIPv4アドレスが含まれています。これらのアドレスの可能な値は外部の顧客サイトから確定的に知られておらず、通常のNAT44で構成できる範囲にあるため、アドレスとポートのスキャンに対するある程度の保護が実現されます。この保護は、ランダムビットを使用した場合よりも効果が低い可能性がありますが、IPv4アドレスのみの場合よりも、6a44 IPv6アドレスの場合の方が優れています。
Denial of service:
サービス拒否：
Provided 6a44 relays are provisioned with enough processing power, which is facilitated by their being completely stateless, 6a44 introduces no denial-of-service vulnerabilities of its own.
6a44リレーに十分な処理能力がプロビジョニングされている場合、それらは完全にステートレスであるため、6a44自体にサービス拒否の脆弱性はありません。
Routing loops:
ルーティングループ：
A risk of routing-loop attacks has been identified in [RFC6324]. Without taking precautions, it applies to some combinations of automatic-tunnel mechanisms such as 6to4, the Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6rd, and Teredo. This risk does not exist with 6a44 for the following reasons:
ルーティングループ攻撃のリスクは[RFC6324]で確認されています。予防策を講じずに、6to4、Intra-Site Automatic Tunnel Addressing Protocol（ISATAP）、6rd、Teredoなどの自動トンネルメカニズムのいくつかの組み合わせに適用されます。このリスクは、次の理由により、6a44では存在しません。
1. When a packet enters a 6a44 relay via its IPv6 interface, the following apply:
1. パケットがIPv6インターフェース経由で6a44リレーに入ると、次のようになります。
+ An IPv6/UDP/IPv4 packet cannot be sent to another 6a44 relay because its IPv4 destination would have to be a 6a44-relay IPv4 address. This is prevented by rule RR6-1 of Section 6.6.1.
+ IPv6 / UDP / IPv4パケットは、そのIPv4宛先が6a44リレーIPv4アドレスである必要があるため、別の6a44リレーに送信できません。これは、セクション6.6.1のルールRR6-1によって防止されます。
+ If an IPv6/UDP/IPv4 packet is sent to the address of a 6to4 relay, 6rd relay, or ISATAP relay, it will be discarded there because these relays don't accept UDP/IPv4 packets.
+ IPv6 / UDP / IPv4パケットが6to4リレー、6rdリレー、またはISATAPリレーのアドレスに送信されると、これらのリレーはUDP / IPv4パケットを受け入れないため、そこで破棄されます。
+ If an IPv6/UDP/IPv4 packet is sent to a Teredo relay, it will be discarded there because (1) Teredo relays check that the IPv4 address that is embedded in the IPv6 source address of a received IPv6/IPv4 packet matches the IPv4 source address of the encapsulating packet (Section 5.4.2 of [RFC4380]); (2) encapsulating packets sent by 6a44 relays have the 6a44-relay anycast address as the IPv4 source address; (3) a 6a44 relay forwards a received IPv6 packet as an IPv6/UDP/IPv4 packet only if its IPv6 source address is not a Teredo address whose embedded IPv4 address is the 6a44-relay IPv4 address.
+ IPv6 / UDP / IPv4パケットがTeredoリレーに送信されると、そこで破棄されます。これは、（1）Teredoリレーが、受信したIPv6 / IPv4パケットのIPv6ソースアドレスに埋め込まれているIPv4アドレスがIPv4ソースと一致することを確認するためです。カプセル化パケットのアドレス（[RFC4380]のセクション5.4.2）。 （2）6a44リレーによって送信されたカプセル化パケットには、IPv4送信元アドレスとして6a44-relayエニーキャストアドレスがあります。 （3）6a44リレーは、IPv6送信元アドレスが、埋め込まれたIPv4アドレスが6a44リレーIPv4アドレスであるTeredoアドレスでない場合にのみ、受信したIPv6パケットをIPv6 / UDP / IPv4パケットとして転送します。
2. When a packet enters a 6a44 relay via its IPv4 interface, the following apply:
2. パケットがIPv4インターフェース経由で6a44リレーに入ると、次のようになります。
+ The received packet cannot come from another 6a44 relay (as just explained, 6rd relays do not send IPv6/UDP/IPv4 packets to other 6a44 relays).
+ 受信したパケットは、別の6a44リレーから来ることはできません（説明したように、6番目のリレーはIPv6 / UDP / IPv4パケットを他の6a44リレーに送信しません）。
+ If the IPv4 packet comes from a 6to4 relay, a 6rd relay, or an ISATAP relay, its IPv6 encapsulated packet cannot be forwarded (the received packet is IPv6/IPv4 instead of being IPv6/UDP/IPv4, as required by rules RR4-2 and RR4-3 of Section 6.6.2).
+ IPv4パケットが6to4リレー、6rdリレー、またはISATAPリレーからのものである場合、そのIPv6カプセル化パケットは転送できません（受信パケットは、ルールRR4-2で要求されているように、IPv6 / UDP / IPv4ではなくIPv6 / IPv4です。およびセクション6.6.2のRR4-3）。
+ If the received packet is an IPv6/UDP/IPv4 packet coming from a Teredo relay, this packet cannot have been sent to the Teredo relay by a 6a44 relay: (1) in order to reach the 6a44 relay, the IPv6 destination of the IPv6 encapsulated packet must be a Teredo address whose embedded IPv4 address is the 6a44-relay anycast address (Section 5.4.1 of [RFC4380]); (2) a 6a44 relay does not forward via its IPv6 interface an IPv6 packet whose destination is a Teredo address whose embedded IPv4 address is the 6a44-relay anycast address (rule RR4-3 of Section 6.6.2).
+受信したパケットがTeredoリレーからのIPv6 / UDP / IPv4パケットである場合、このパケットは6a44リレーによってTeredoリレーに送信できませんでした：（1）6a44リレーに到達するために、IPv6宛先IPv6カプセル化パケットは、埋め込まれたIPv4アドレスが6a44リレーエニーキャストアドレスであるTeredoアドレスである必要があります（[RFC4380]のセクション5.4.1）。 （2）6a44リレーは、埋め込みIPv4アドレスが6a44-relayエニーキャストアドレスであるTeredoアドレスを宛先とするIPv6パケットをIPv6インターフェース経由で転送しません（セクション6.6.2のルールRR4-3）。
6a44-relay spoofing:
6a44-relayスプーフィング：
In a 6a44 network, no node can spoof a 6a44 relay because ingress filtering prevents any 6a44-relay anycast address from being spoofed.
6a44ネットワークでは、入力フィルタリングが6a44リレーのエニーキャストアドレスのなりすましを防ぐため、ノードは6a44リレーを偽装できません。
In a network that does not support ingress filtering (and therefore is not a 6a44 network), the following apply:
入力フィルタリングをサポートしないネットワーク（したがって、6a44ネットワークではない）では、次のことが適用されます。
* 6a44 packets sent by 6a44-capable hosts are discarded in the IPv4 backbone because their IPv4 destination, the 6a44-relay anycast address, does not start with any ISP-assigned prefix.
* 6a44対応ホストから送信された6a44パケットは、IPv4宛先である6a44-relayエニーキャストアドレスがISPが割り当てたプレフィックスで始まっていないため、IPv4バックボーンで破棄されます。
* If an attacker tries to send to a 6a44-capable host a fake relay-to-client bubble, the probability that it would be accepted by its destination is negligible. It would require that all the following conditions be simultaneously satisfied:
* 攻撃者が6a44対応ホストに偽のリレーからクライアントへのバブルを送信しようとした場合、宛先によって受け入れられる可能性はごくわずかです。以下のすべての条件が同時に満たされる必要があります。
+ The UDP/IPv4 destination set by the attacker must reach a NAT44 node in which it is the external mapping of a 6a44 tunnel established by a 6a44-capable host.
+ 攻撃者によって設定されたUDP / IPv4宛先は、6a44対応ホストによって確立された6a44トンネルの外部マッピングであるNAT44ノードに到達する必要があります。
+ This host must be in the "Bubble sent" state -- the only one in which it listens to bubbles when its ISP is not 6a44 capable. This state is taken only for a few seconds every 30 minutes (rule TM-5 of Section 6.5.1).
+ このホストは「Bubble sent」状態である必要があります。ISPが6a44に対応していないときに、このホストがバブルをリッスンする唯一のホストです。この状態は、30分ごとに数秒間のみ発生します（6.5.1のルールTM-5）。
+ This host accepts the bubble only if its Bubble ID has the right value -- an extremely unlikely possibility with a 64-bit randomly chosen Bubble ID (see Section 6.5.1).
+ このホストは、そのバブルIDに適切な値がある場合にのみバブルを受け入れます。これは、64ビットのランダムに選択されたバブルIDでの可能性は非常に低い（セクション6.5.1を参照）。
* If a 6a44-capable host -- despite this scenario being very unlikely -- accepts a fake bubble, the effect is that it wrongly believes, for about 30 seconds, that it has an assigned public IPv6 address. All IPv6 packets it then sends with this address as the source cannot be accepted by any destination (no relay will forward them, and no host of the same site will accept them). The consequences of this scenario would therefore not impair security.
* 6a44対応ホストが（このシナリオが非常にありそうもないのに）偽のバブルを受け入れる場合、その影響は、割り当てられたパブリックIPv6アドレスがあると約30秒間誤って信じることです。送信元はどの宛先にも受け入れられないため、このアドレスで送信するすべてのIPv6パケット（リレーはそれらを転送せず、同じサイトのホストはそれらを受け入れません）。したがって、このシナリオの結果がセキュリティを損なうことはありません。
IANA has assigned the following:
IANAは以下を割り当てました。
1. IPv4 address 192.88.99.2 as the 6a44-relay anycast address (B in this document).
1. 6a44リレーエニーキャストアドレスとしてIPv4アドレス192.88.99.2（このドキュメントのB）。
2. UDP port 1027 as the 6a44 port (W in this document).
2. 6a44ポートとしてUDPポート1027（このドキュメントではW）。
The choice of 192.88.99.2 as the 6a44 IPv4 anycast address doesn't conflict with any existing IETF specification because
6a44 IPv4エニーキャストアドレスとして192.88.99.2を選択しても、既存のIETF仕様と競合しません。
o it starts with the 6to4 prefix 192.88.99.0/24 [RFC3068].
o 6to4プレフィックス192.88.99.0/24 [RFC3068]で始まります。
o it differs from the only currently assigned address that starts with this prefix (the anycast address of 6to4 relays -- 192.88.99.1 [RFC3068].
o このプレフィックスで始まる現在割り当てられている唯一のアドレスとは異なります（6to4リレーのエニーキャストアドレス-192.88.99.1 [RFC3068]。
This choice is made to permit implementations of 6a44 relays in physical nodes that are independent from any 6to4 relay or, if found to be more optimum, in nodes in which 6to4 relays and 6a44 relays are collocated.
この選択は、6to4リレーから独立した物理ノードでの6a44リレーの実装を許可するために行われます。より最適であると判明した場合は、6to4リレーと6a44リレーが同じ場所にあるノードで実装できます。
This specification, whose origin is a convergence effort based on two independent proposals -- [6rd+] and [SAMPLE] -- has benefited from various suggestions. Comments have been received during this process, in particular from Dave Thaler, Fred Templin, Ole Troan, Olivier Vautrin, Pascal Thubert, Washam Fan, and Yu Lee. The authors wish to thank them, and all others, for their useful contributions. Special recognition is due to Dave Thaler and John Mann. Their detailed reviews led to a few useful modifications and editorial improvements.
この仕様は、2つの独立した提案（[6rd +]と[SAMPLE]）に基づく収束作業を起源としていますが、さまざまな提案から恩恵を受けています。このプロセス中に、特にデイブターラー、フレッドテンプリン、オレトローン、オリヴィエヴォトリン、パスカルチューバート、ワシャムファン、ユーリーからコメントが寄せられました。著者たちは、彼らおよび他のすべての人々の有益な貢献に感謝したいと思います。特別な表彰はデイブ・ターラーとジョン・マンによるものです。彼らの詳細なレビューは、いくつかの有用な修正と編集上の改善につながりました。
[RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981.
[RFC0792] Postel、J。、「インターネット制御メッセージプロトコル」、STD 5、RFC 792、1981年9月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[RFC4291] Hinden、R。およびS. Deering、「IPバージョン6アドレッシングアーキテクチャ」、RFC 4291、2006年2月。
[6rd+] Despres, R., "Rapid Deployment of Native IPv6 Behind IPv4 NATs (6rd+)", Work in Progress, July 2010.
[6rd +] Despres、R。、「IPv4 NATの背後にあるネイティブIPv6の迅速な展開（6rd +）」、作業中、2010年7月。
[NAT444] Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., and H. Ashida, "NAT444 addressing models", Work in Progress, July 2012.
[NAT444]山口純、白崎裕、宮川晋、中川明、芦田浩、「NAT444アドレッシングモデル」、Work in Progress、2012年7月。
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[RFC1918] Rekhter、Y.、Moskowitz、B.、Karrenberg、D.、de Groot、G。、およびE. Lear、「プライベートインターネットのアドレス割り当て」、BCP 5、RFC 1918、1996年2月。
[RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[RFC2827]ファーガソン、P。およびD.セニー、「ネットワーク入力フィルタリング：IP送信元アドレスのスプーフィングを採用するサービス拒否攻撃の打破」、BCP 38、RFC 2827、2000年5月。
[RFC3053] Durand, A., Fasano, P., Guardini, I., and D. Lento, "IPv6 Tunnel Broker", RFC 3053, January 2001.
[RFC3053] Durand、A.、Fasano、P.、Guardini、I。、およびD. Lento、「IPv6 Tunnel Broker」、RFC 3053、2001年1月。
[RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains via IPv4 Clouds", RFC 3056, February 2001.
[RFC3056]カーペンター、B。およびK.ムーア、「IPv4クラウドを介したIPv6ドメインの接続」、RFC 3056、2001年2月。
[RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", RFC 3068, June 2001.
[RFC3068] Huitema、C。、「Antocast Prefix for 6to4 Relay Routers」、RFC 3068、2001年6月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]ベイカー、F。、およびP.サボラ、「マルチホームネットワークの入力フィルタリング」、BCP 84、RFC 3704、2004年3月。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[RFC4193] Hinden、R。およびB. Haberman、「Unique Local IPv6 Unicast Addresses」、RFC 4193、2005年10月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：Tunneling IPv6 over UDP through Network Address Translations（NATs）」、RFC 4380、2006年2月。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 4443, March 2006.
[RFC4443] Conta、A.、Deering、S。、およびM. Gupta、編、「インターネットプロトコルバージョン6（IPv6）仕様のためのインターネット制御メッセージプロトコル（ICMPv6）」、RFC 4443、2006年3月。
[RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010.
[RFC5245] Rosenberg、J。、「Interactive Connectivity Establishment（ICE）：A Protocol for Network Address Translator（NAT）Traversal for Offer / Answer Protocols」、RFC 5245、2010年4月。
[RFC5569] Despres, R., "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd)", RFC 5569, January 2010.
[RFC5569] Despres、R。、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）」、RFC 5569、2010年1月。
[RFC5626] Jennings, C., Ed., Mahy, R., Ed., and F. Audet, Ed., "Managing Client-Initiated Connections in the Session Initiation Protocol (SIP)", RFC 5626, October 2009.
[RFC5626] Jennings、C.、Ed。、Mahy、R.、Ed。、およびF. Audet、Ed。、「Managing Client-Initiated Connections in the Session Initiation Protocol（SIP）」、RFC 5626、2009年10月。
[RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 Infrastructures (6rd) -- Protocol Specification", RFC 5969, August 2010.
[RFC5969] Townsley、W.およびO. Troan、「IPv4 Infrastructures on IPv4 Infrastructures（6rd）-Protocol Specification」、RFC 5969、2010年8月。
[RFC5991] Thaler, D., Krishnan, S., and J. Hoagland, "Teredo Security Updates", RFC 5991, September 2010.
[RFC5991]ターラーD.、クリシュナンS.、J。ホアグランド、「Teredoセキュリティアップデート」、RFC 5991、2010年9月。
[RFC6081] Thaler, D., "Teredo Extensions", RFC 6081, January 2011.
[RFC6081] Thaler、D。、「Teredo Extensions」、RFC 6081、2011年1月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145] Li、X.、Bao、C。、およびF. Baker、「IP / ICMP変換アルゴリズム」、RFC 6145、2011年4月。
[RFC6324] Nakibly, G. and F. Templin, "Routing Loop Attack Using IPv6 Automatic Tunnels: Problem Statement and Proposed Mitigations", RFC 6324, August 2011.
[RFC6324]たぶん、G。およびF. Templin、「IPv6自動トンネルを使用したルーティングループ攻撃：問題の記述と提案された軽減策」、RFC 6324、2011年8月。
[SAMPLE] Carpenter, B. and S. Jiang, "Legacy NAT Traversal for IPv6: Simple Address Mapping for Premises Legacy Equipment (SAMPLE)", Work in Progress, June 2010.
[サンプル] Carpenter、B。およびS. Jiang、「IPv6のレガシーNATトラバーサル：構内レガシー機器（SAMPLE）のシンプルなアドレスマッピング」、作業中、2010年6月。
[TheTool] de Saint-Exupery, A., "Wind, Sand and Stars", Chapter III (The Tool), 1939.
[TheTool] de Saint-Exupery、A.、 "Wind、Sand and Stars"、Chapter III（The Tool）、1939。
Authors' Addresses
著者のアドレス
Remi Despres (editor) 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
Brian Carpenter University of Auckland Department of Computer Science PB 92019 Auckland 1142 New Zealand
ブライアンカーペンターオークランド大学コンピュータサイエンス学部PB 92019オークランド1142ニュージーランド
EMail: brian.e.carpenter@gmail.com
Dan Wing Cisco Systems, Inc. 170 West Tasman Drive San Jose, California 95134 USA
Dan Wing Cisco Systems、Inc. 170 West Tasman Drive San Jose、California 95134 USA
EMail: dwing@cisco.com
Sheng Jiang Huawei Technologies Co., Ltd. Q14, Huawei Campus - No. 156 Beiqing Road Hai-Dian District, Beijing 100095 P.R. China
S横江hu Aはテクノロジー株式会社です。Q14、hu Aはキャンパス番号です。156be iblueroad H艾-Dイアン地区、北京100095 P.R.中国
EMail: jiangsheng@huawei.com