[要約] 要約： RFC 4966は、NAT-PTを歴史的なステータスに移行する理由を提供しています。目的： 1. NAT-PTの問題と制約を明確にする。 2. IPv6への移行において、NAT-PTの使用を推奨しないことを強調する。 3. NAT-PTの歴史的なステータスへの移行を促進する。
Network Working Group C. Aoun
Request for Comments: 4966 Energize Urnet
Obsoletes: 2766 E. Davies
Category: Informational Folly Consulting
July 2007
Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status
ネットワークアドレス翻訳者を移動する理由 - プロトコル翻訳者（NAT -PT）は歴史的なステータスになります
Status of This Memo
本文書の位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
Abstract
概要
This document discusses issues with the specific form of IPv6-IPv4 protocol translation mechanism implemented by the Network Address Translator - Protocol Translator (NAT-PT) defined in RFC 2766. These issues are sufficiently serious that recommending RFC 2766 as a general purpose transition mechanism is no longer desirable, and this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status.
このドキュメントでは、RFC 2766で定義されているネットワークアドレス翻訳者 - プロトコル翻訳者（NAT-PT）によって実装されたIPv6-IPV4プロトコル翻訳メカニズムの特定の形式に関する問題について説明します。これらの問題は、RFC 2766を汎用遷移メカニズムとして推奨するほど深刻です。もはや望ましくありません。このドキュメントでは、IETFがRFC 2766を提案された標準から歴史的ステータスに再分類することを推奨しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Issues Unrelated to an DNS-ALG . . . . . . . . . . . . . . . . 7
2.1. Issues with Protocols Embedding IP Addresses . . . . . . . 7
2.2. NAPT-PT Redirection Issues . . . . . . . . . . . . . . . . 8
2.3. NAT-PT Binding State Decay . . . . . . . . . . . . . . . . 8
2.4. Loss of Information through Incompatible Semantics . . . . 9
2.5. NAT-PT and Fragmentation . . . . . . . . . . . . . . . . . 10
2.6. NAT-PT Interaction with SCTP and Multihoming . . . . . . . 11
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6 . . . . . . 12
2.8. NAT-PT and Multicast . . . . . . . . . . . . . . . . . . . 12
3. Issues Exacerbated by the Use of DNS-ALG . . . . . . . . . . . 13
3.1. Network Topology Constraints Implied by NAT-PT . . . . . . 13
3.2. Scalability and Single Point of Failure Concerns . . . . . 14
3.3. Issues with Lack of Address Persistence . . . . . . . . . 15
3.4. DoS Attacks on Memory and Address/Port Pools . . . . . . . 16
4. Issues Directly Related to Use of DNS-ALG . . . . . . . . . . 16
4.1. Address Selection Issues when Communicating with
Dual-Stack End-Hosts . . . . . . . . . . . . . . . . . . . 16
4.2. Non-Global Validity of Translated RR Records . . . . . . . 18
4.3. Inappropriate Translation of Responses to A Queries . . . 19
4.4. DNS-ALG and Multi-Addressed Nodes . . . . . . . . . . . . 19
4.5. Limitations on Deployment of DNS Security Capabilities . . 19
5. Impact on IPv6 Application Development . . . . . . . . . . . . 20
6. Security Considerations . . . . . . . . . . . . . . . . . . . 20
7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 22
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22
9.1. Normative References . . . . . . . . . . . . . . . . . . . 22
9.2. Informative References . . . . . . . . . . . . . . . . . . 23
The Network Address Translator - Protocol Translator (NAT-PT) document [RFC2766] defines a set of network-layer translation mechanisms designed to allow nodes that only support IPv4 to communicate with nodes that only support IPv6, during the transition to the use of IPv6 in the Internet.
ネットワークアドレス翻訳者 - プロトコル翻訳者（NAT-PT）ドキュメント[RFC2766]は、IPv6の使用中にIPv6のみをサポートするノードのみをサポートするノードと通信するIPv4のみと通信できるように設計されたネットワーク層翻訳メカニズムのセットを定義します。インタネットの中には。
[RFC2766] specifies the basic NAT-PT, in which only addresses are translated, and the Network Address Port Translator - Protocol Translator (NAPT-PT), which also translates transport identifiers, allowing for greater economy of scarce IPv4 addresses. Protocol translation is performed using the Stateless IP/ICMP Translation Algorithm (SIIT) defined in [RFC2765]. In the following discussion, where the term "NAT-PT" is used unqualified, the discussion applies to both basic NAT-PT and NAPT-PT. "Basic NAT-PT" will be used if points apply to the basic address-only translator.
[RFC2766]は、アドレスのみが翻訳される基本NAT-PTと、ネットワークアドレスポート翻訳者 - プロトコル翻訳者（NAPT-PT）を指定します。プロトコル翻訳は、[RFC2765]で定義されたStateless IP/ICMP翻訳アルゴリズム（SIIT）を使用して実行されます。「NAT-PT」という用語が資格のないものを使用している場合、以下の議論では、議論は基本的なNAT-PTとNAPT-PTの両方に適用されます。基本的なアドレスのみの翻訳者にポイントが適用される場合、「Basic Nat-PT」が使用されます。
A number of previous documents have raised issues with NAT-PT. This document will summarize these issues, note several other issues carried over from traditional IPv4 NATs, and identify some additional issues that have not been discussed elsewhere. Proposed solutions to the issues are mentioned and any resulting need for changes to the specification is identified.
多くの以前の文書がNAT-PTの問題を提起しています。このドキュメントでは、これらの問題を要約し、従来のIPv4 NATから引き継がれた他のいくつかの問題に注意し、他の場所で議論されていないいくつかの追加の問題を特定します。問題に対する提案された解決策が言及されており、その結果、仕様の変更の必要性が特定されています。
Whereas NAT is seen as an ongoing capability that is needed to work around the limited availability of globally unique IPv4 addresses, NAT-PT has a different status as a transition mechanism for IPv6. As such, NAT-PT should not be allowed to constrain the development of IPv6 applications or impose limitations on future developments of IPv6.
NATは、グローバルに一意のIPv4アドレスの限られた可用性を回避するために必要な継続的な機能と見なされますが、NAT-PTはIPv6の遷移メカニズムとして異なるステータスを持っています。そのため、NAT-PTは、IPv6アプリケーションの開発を制約したり、IPv6の将来の開発に制限を課したりすることを許可されるべきではありません。
This document draws the conclusion that the technical and operational difficulties resulting from these issues, especially the possible future constraints on the development of IPv6 networks (see Section 5), make it undesirable to recommend NAT-PT as described in [RFC2766] as a general purpose transition mechanism for intercommunication between IPv6 networks and IPv4 networks.
このドキュメントは、これらの問題、特にIPv6ネットワークの開発に関する将来の制約の可能性に起因する技術的および運用上の困難（セクション5を参照）は、[RFC2766]に記載されているようにNAT-PTを推奨することを望ましくないという結論を導き出します。IPv6ネットワークとIPv4ネットワーク間の相互コミュニケーションのための目的遷移メカニズム。
Although the [RFC2766] form of packet translation is not generally applicable, it is likely that in some circumstances a node that can only support IPv4 will need to communicate with a node that can only support IPv6; this needs a translation mechanism of some kind. Although this may be better carried out by an application-level proxy or transport-layer translator, there may still be scenarios in which a revised, possibly restricted version of NAT-PT can be a suitable solution; accordingly, this document recommends that the IETF should reclassify RFC 2766 from Proposed Standard to Historic status to avoid it from being used in inappropriate scenarios while any replacement is developed.
[RFC2766]のパケット変換の形式は一般に適用できませんが、状況によっては、IPv4のみをサポートできるノードがIPv6のみをサポートできるノードと通信する必要がある可能性があります。これには、ある種の翻訳メカニズムが必要です。これは、アプリケーションレベルのプロキシまたは輸送層翻訳者によってより適切に実行される可能性がありますが、NAT-PTの改訂された、おそらく制限付きバージョンが適切なソリューションになるシナリオがまだある場合があります。したがって、このドキュメントでは、IETFがRFC 2766を提案された基準から歴史的ステータスに再分類することを推奨しています。
The following documents relating directly to NAT-PT have been reviewed while drafting this document:
NAT-PTに直接関連する以下のドキュメントは、このドキュメントの起草中にレビューされています。
o Network Address Translation - Protocol Translation (NAT-PT) [RFC2766]
o ネットワークアドレス変換 - プロトコル翻訳（NAT -PT）[RFC2766]
o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
o ステートレスIP/ICMP翻訳アルゴリズム（SIIT）[RFC2765]
o NAT-PT Applicability Statement [NATP-APP]
o NAT-PTアプリケーションステートメント[NATP-APP]
o Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766 [DNS-ALG-ISSUES]
o RFC 2766のNAT-PTDNSアルグ（アプリケーションレイヤーゲートウェイ）の問題[DNS-Alg-Issues]
o NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
o nat-pt dns algソリューション[dns-alg-sol]
o NAT-PT Security Considerations [NATPT-SEC]
o NAT-PTセキュリティ上の考慮事項[NATPT-SEC]
o Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
o IPv4とIPv6の間で翻訳する際の問題[トランス問題]
o IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
o 第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるSIPベースのサービスのIPv6-IPV4翻訳メカニズム[3GPP-Trans]
o Analysis on IPv6 Transition in 3GPP Networks [RFC4215]
o 3GPPネットワークでのIPv6遷移に関する分析[RFC4215]
o Considerations for Mobile IP Support in NAT-PT [NATPT-MOB]
o NAT-PT [NATPT-MOB]でのモバイルIPサポートの考慮事項
o An IPv6-IPv4 Multicast Translator based on Internet Group Management Protocol / Multicast Listener Discovery (IGMP/MLD) Proxying (mtp) [MTP]
o インターネットグループ管理プロトコル /マルチキャストリスナーディスカバリー（IGMP / MLD）プロキシ（MTP）[MTP]に基づくIPv6-IPV4マルチキャスト翻訳者
o An IPv4-IPv6 Multicast Gateway [MCASTGW]
o IPv4-IPV6マルチキャストゲートウェイ[MCASTGW]
o Scalable mNAT-PT Solution [MUL-NATPT]
o スケーラブルなmnat-ptソリューション[mul-natpt]
Because the majority of the documents containing discussions of the issues are documents that are unlikely to become RFCs, the issues are summarized here to avoid the need for normative references.
問題の議論を含む文書の大部分は、RFCになる可能性が低いドキュメントであるため、規範的な参照の必要性を回避するために問題はここにまとめられています。
Some additional issues can be inferred from corresponding issues known to exist in 'traditional' IPv4 NATs. The following documents are relevant: o Protocol Complications with the IP Network Address Translator [RFC3027]
「従来の」IPv4 NATに存在することが知られている対応する問題から、いくつかの追加の問題を推測できます。次のドキュメントが関連しています：o IPネットワークアドレス翻訳者とのプロトコルの合併症[RFC3027]
o IP Network Address Translator (NAT) Terminology and Considerations [RFC2663]
o IPネットワークアドレス翻訳者（NAT）の用語と考慮事項[RFC2663]
There is some ambiguity in [RFC2766] about whether the Application Layer Gateway (ALG) for DNS (referred to as DNS-ALG in this document) is an integral and mandatory part of the specification. The ambiguity arises mainly from the first section of the applicability section (Section 8), which appears to imply that 'simple' use of NAT-PT could avoid the use of the DNS-ALG.
[RFC2766]には、DNSのアプリケーションレイヤーゲートウェイ（ALG）（このドキュメントではDNS-ALGと呼ばれる）が仕様の不可欠かつ必須の部分であるかどうかについて、ある程度のあいまいさがあります。あいまいさは、主に適用可能性セクション（セクション8）の最初のセクションから生じます。これは、NAT-PTの「単純な」使用がDNS-Algの使用を回避できることを暗示しているようです。
This is important because a number of the major issues arise from the interactions between DNS and NAT-PT. However, detailed inspection of [RFC2766] shows that the 'simple' case has not been worked out and it is unclear how information about the address translation could be passed to the hosts in the absence of the DNS-ALG. Therefore, this document assumes that the DNS-ALG is an integral part of NAT-PT; accordingly, issues with the DNS-ALG must be considered as issues for the whole specification.
これは重要です。これは、DNSとNAT-PTの相互作用から多くの主要な問題が発生するためです。ただし、[RFC2766]の詳細な検査により、「単純な」ケースが解決されていないことが示されており、DNS-ALGがない場合に住所変換に関する情報をホストにどのように渡すことができるかは不明です。したがって、このドキュメントは、DNS-AlgがNAT-PTの不可欠な部分であると想定しています。したがって、DNS-ALGの問題は、仕様全体の問題と見なされる必要があります。
Note that issues not specifically related to the use of the DNS-ALG will apply to any network-layer translation scheme, including any based on the SIIT algorithm [RFC2765]. In the event that new forms of a translator are developed as alternatives to NAT-PT, the generic issues relevant to all IPv6-IPv4 translators should be borne in mind.
DNS-Algの使用に特に関連していない問題は、SIITアルゴリズム[RFC2765]に基づく任意の任意のネットワーク層翻訳スキームに適用されることに注意してください。翻訳者の新しい形式がNAT-PTの代替として開発された場合、すべてのIPv6-IPV4翻訳者に関連する一般的な問題を念頭に置いておく必要があります。
Issues raised with IPv6-IPv4 translators in general and NAT-PT in particular can be categorized as follows:
一般的にIPv6-IPV4翻訳者と特にNAT-PTで提起された問題は、次のように分類できます。
o Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of an IPv6-IPv4 translator:
o DNS-ALGの使用とは無関係であるため、IPv6-IPV4翻訳者のあらゆる形態に適用される問題：
* Disruption of all protocols that embed IP addresses (and/or ports) in packet payloads or apply integrity mechanisms using IP addresses (and ports).
* パケットペイロードにIPアドレス（および/またはポート）を埋め込むすべてのプロトコルの破壊またはIPアドレス（およびポート）を使用して整合性メカニズムを適用します。
* Inability to redirect traffic for protocols that lack demultiplexing capabilities or are not built on top of specific transport-layer protocols in situations where one NAPT-PT is translating for multiple IPv6 hosts.
* 1つのNAPT-PTが複数のIPv6ホスト用に翻訳している状況では、非複数の能力を欠いている、または特定の輸送層プロトコルの上に構築されていないプロトコルのトラフィックをリダイレクトできません。
* Requirement for applications to use keepalive mechanisms to workaround connectivity issues caused by premature NAT-PT state timeout.
* Keepaliveメカニズムを使用するためのアプリケーションの要件は、未熟なNAT-PT状態のタイムアウトによって引き起こされる回避策の問題になります。
* Loss of information due to incompatible semantics between IPv4 and IPv6 versions of headers and protocols.
* ヘッダーとプロトコルのIPv4バージョンとIPv6バージョンの間の互換性のないセマンティクスによる情報の喪失。
* Need for additional state and/or packet reconstruction in NAPT-PT translators dealing with packet fragmentation.
* パケットの断片化を扱うNAPT-PT翻訳者の追加の状態および/またはパケット再建が必要です。
* Interaction with SCTP and multihoming.
* SCTPとマルチホミングとの相互作用。
* Need for NAT-PT to act as proxy for correspondent node when IPv6 node is mobile, with consequent restrictions on mobility.
* IPv6ノードがモバイルである場合、NAT-PTが特派員ノードのプロキシとして機能する必要があり、その結果、モビリティが制限されます。
* NAT-PT not being able to handle multicast traffic.
* NAT-PTは、マルチキャストトラフィックを処理できません。
o Issues that are exacerbated by the use of a DNS-ALG and are, therefore, also applicable to any form of an IPv6-IPv4 translator:
o DNS-Algの使用によって悪化し、したがって、あらゆる形態のIPv6-IPV4翻訳者にも適用される問題：
* Constraints on network topology.
* ネットワークトポロジの制約。
* Scalability concerns together with introduction of a single point of failure and a security attack nexus.
* スケーラビリティは、単一の障害ポイントとセキュリティ攻撃のネクサスの導入とともに関係しています。
* Lack of address mapping persistence: Some applications require address retention between sessions. The user traffic will be disrupted if a different mapping is used. The use of the DNS-ALG to create address mappings with limited lifetimes means that applications must start using the address shortly after the mapping is created, as well as keep it alive once they start using it.
* 住所マッピングの持続性の欠如：一部のアプリケーションでは、セッション間のアドレス保持が必要です。異なるマッピングが使用されると、ユーザートラフィックが破壊されます。DNS-Algを使用して、寿命が限られているアドレスマッピングを作成することは、マッピングが作成された直後にアプリケーションを使用してアドレスの使用を開始する必要があることを意味し、使用を開始したら生存し続ける必要があります。
* Creation of a DoS (Denial of Service) threat relating to exhaustion of memory and address/port pool resources on the translator.
* 翻訳者の記憶と住所/ポートプールのリソースの疲労に関するDOS（サービスの拒否）脅威の作成。
o Issues that result from the use of a DNS-ALG and are, therefore, specific to NAT-PT as defined in [RFC2766]:
o したがって、DNS-Algの使用に起因する問題であり、したがって、[RFC2766]で定義されているNAT-PTに固有です。
* Address selection issues when either the internal or external hosts implement both IPv4 and IPv6.
* アドレス選択の問題内部ホストまたは外部ホストがIPv4とIPv6の両方を実装する場合。
* Restricted validity of translated DNS records: a translated record may be forwarded to an application that cannot use it.
* 翻訳されたDNSレコードの制限された有効性：翻訳されたレコードは、使用できないアプリケーションに転送される場合があります。
* Inappropriate translation of responses to A queries from IPv6 nodes.
* IPv6ノードからのクエリへの応答の不適切な翻訳。
* Address selection issues and resource consumption in a DNS-ALG with multi-addressed nodes.
* マルチアドレスノードを備えたDNS-ALGの選択の問題とリソース消費をアドレスします。
* Limitations on DNS security capabilities when using a DNS-ALG.
* DNS-Algを使用する場合のDNSセキュリティ機能の制限。
Section 2, Section 3 and Section 4 discuss these groups of issues. Section 5 examines the consequences of deploying NAT-PT for application developers and the long term effects of NAT-PT (or any form of generally deployed IPv6-IPv4 translator) on the further development of IPv6.
セクション2、セクション3、およびセクション4は、これらの問題のグループについて説明します。セクション5では、アプリケーション開発者にNAT-PTを展開した結果と、IPv6のさらなる開発に対するNAT-PT（または一般的に展開されたIPv6-IPV4翻訳者のあらゆる形式）の長期的な影響を調べます。
The terminology used in this document is defined in [RFC2663], [RFC2766], and [RFC3314].
このドキュメントで使用されている用語は、[RFC2663]、[RFC2766]、および[RFC3314]で定義されています。
It is well known from work on IPv4 NATs (see Section 8 of [RFC2663] and [RFC3027]) that the large class of protocols that embed numeric IP addresses in their payloads either cannot work through NATs or require specific ALGs as helpers to translate the payloads in line with the address and port translations. The same set of protocols cannot pass through NAT-PT. The problem is exacerbated because the IPv6 and IPv4 addresses are of different lengths, so that packet lengths as well as packet contents are altered. [RFC2766] describes the consequences as part of the description of the FTP ALG. Similar workarounds are needed for all protocols with embedded IP addresses that run over TCP transports.
IPv4 NAT（[RFC2663]および[RFC3027]のセクション8を参照）の作業からよく知られています。ペイロードに数値IPアドレスを埋め込むプロトコルの大規模なクラスのプロトコルは、NATを介して動作できないか、ヘルパーとして特定のアルグを必要として、ヘルパーとして特定のアルグを必要とします。アドレスとポートの翻訳に沿ったペイロード。同じ一連のプロトコルがNAT-PTを通過できません。IPv6とIPv4のアドレスが長さが異なるため、問題は悪化しています。そのため、パケットの長さとパケットコンテンツが変更されます。[RFC2766]は、FTPアルグの説明の一部として結果を説明しています。TCPトランスポートを介して実行される埋め込まれたIPアドレスを備えたすべてのプロトコルには、同様の回避策が必要です。
The issues raised in Sections 2 and 3 of [RFC2663], relating to the authentication and encryption with NAT, are also applicable to NAT-PT.
[RFC2663]のセクション2および3で提起された問題は、NATとの認証と暗号化に関連して、NAT-PTにも適用できます。
Implementing a suite of ALGs requires that NAT-PT equipment includes the logic for each of the relevant protocols. Most of these protocols are continuously evolving, requiring continual and coordinated updates of the ALGs to keep them in step.
一連のALGSを実装するには、NAT-PT機器に関連する各プロトコルのロジックが含まれることが必要です。これらのプロトコルのほとんどは継続的に進化しているため、ALGの継続的かつ調整された更新が必要です。
Assuming that the NAT-PT contains a colocated ALG for one of the relevant protocols, the ALG could replace the embedded IP addresses and ports. However, this replacement can only happen if no cryptographic integrity mechanism is used and the protocol messages are sent in the clear (i.e., not encrypted).
NAT-PTに関連するプロトコルの1つにコロッケートされたアルグが含まれていると仮定すると、アルグは埋め込まれたIPアドレスとポートを置き換えることができます。ただし、この置換は、暗号化の整合性メカニズムが使用されず、プロトコルメッセージがクリア（つまり、暗号化されていない）で送信された場合にのみ発生します。
A possible workaround relies on the NAT-PT being party to the security association used to provide authentication and/or encryption. NAT-PT would then be aware of the cryptographic algorithms and keys used to secure the traffic. It could then modify and re-secure the packets; this would certainly complicate network operations and provide additional points of security vulnerability.
可能性のある回避策は、認証および/または暗号化を提供するために使用されるセキュリティ協会の当事者であるNAT-PTに依存しています。その後、NAT-PTは、トラフィックを保護するために使用される暗号化アルゴリズムとキーを認識します。その後、パケットを変更して再セキュアできます。これは確かにネットワーク操作を複雑にし、セキュリティの脆弱性の追加ポイントを提供します。
Unless UDP encapsulation is used for IPsec [RFC3498], traffic using IPsec AH (Authentication Header), in transport and tunnel mode, and IPsec ESP (Encapsulating Security Payload), in transport mode, is unable to be carried through NAT-PT without terminating the security associations on the NAT-PT, due to their usage of cryptographic integrity protection.
IPSEC [RFC3498]にUDPカプセル化が使用されない限り、IPSEC AH（認証ヘッダー）、輸送およびトンネルモード、およびIPSEC ESP（セキュリティペイロードのカプセル化）を使用して、トランスポートモードでは、NAT-PTを介して終了せずに運ぶことができません。暗号化の整合性保護の使用により、NAT-PTのセキュリティ協会。
A related issue with DNS security is discussed in Section 4.5.
Section 4.2 of [RFC3027] discusses problems specific to RSVP and NATs, one of which is actually a more generic problem for all port translators. When several end-hosts are using a single NAPT-PT box, protocols that do not have a demultiplexing capability similar to transport-layer port numbers may be unable to work through NAPT-PT (and any other port translator) because there is nothing for NAPT-PT to use to identify the correct binding.
This type of issue affects IPsec encrypted packets where the transport port is not visible (although it might be possible to use the Security Parameter Index (SPI) as an alternative demultiplexer), and protocols, such as RSVP, which are carried directly in IP datagrams rather than using a standard transport-layer protocol such as TCP or UDP. In the case of RSVP, packets going from the IPv4 domain to the IPv6 domain do not necessarily carry a suitable demultiplexing field, because the port fields in the flow identifier and traffic specifications are optional.
このタイプの問題は、トランスポートポートが表示されないIPSEC暗号化されたパケットに影響します（ただし、IPデータグラムに直接運ばれるRSVPなどのプロトコルは、代替Demultiplexerとしてセキュリティパラメーターインデックス（SPI）を使用することが可能かもしれません）TCPやUDPなどの標準の輸送層プロトコルを使用するのではなく。RSVPの場合、フロー識別子とトラフィック仕様のポートフィールドがオプションであるため、IPv4ドメインからIPv6ドメインに移動するパケットは必ずしも適切な非複数のフィールドを搭載しているわけではありません。
Several ad hoc workarounds could be used to solve the demultiplexing issues, however in most cases these solutions are not documented anywhere, which could lead to non-deterministic and undesirable behavior (for example, such workarounds often assume particular network topologies, etc., in order to function correctly; if the assumptions are not met in a deployment, the workaround may not work as expected).
いくつかのアドホックな回避策を使用して、脱調の問題を解決することができますが、ほとんどの場合、これらのソリューションはどこにも文書化されていないため、非決定的で望ましくない動作につながる可能性があります（たとえば、そのような回避策は、特定のネットワークトポロジなどを仮定することが多いことがよくあります。正しく機能するため。展開で仮定が満たされない場合、回避策は予想どおりに機能しない場合があります）。
This issue is closely related to the fragmentation issue described in Section 2.5.
この問題は、セクション2.5で説明されている断片化の問題に密接に関連しています。
NAT-PT will generally use dynamically created bindings to reduce the need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both basic NAT-PT and NAPT-PT use soft state mechanisms to manage the address and, in the case of NAPT-PT, port pools are used for dynamically created address bindings. This allows all types of NAT-PT boxes to operate autonomously without requiring clients to signal, either implicitly or explicitly, that a binding is no longer required. In any case, without soft state timeouts, network and application unreliability would inevitably lead to leaks, eventually causing address or port pool exhaustion.
NAT-PTは通常、動的に作成されたバインディングを使用して、基本的なNAT-PTとNAPT-PTの両方のIPv4アドレスの必要性を減らします。基本的なNAT-PTとNAPT-PTの両方がソフト状態メカニズムを使用してアドレスを管理します。NAPT-PTの場合、ポートプールは動的に作成されたアドレスバインディングに使用されます。これにより、すべてのタイプのNAT-PTボックスが、クライアントが暗黙的または明示的に信号を送ることを要求することなく、バインディングが不要になったことを自律的に動作させることができます。いずれにせよ、ソフト状態のタイムアウトがなければ、ネットワークとアプリケーションの信頼性は必然的に漏れにつながり、最終的にはアドレスまたはポートプールの枯渇を引き起こします。
For a dynamic binding to persist for longer than the soft state timeout, packets must be sent periodically from one side of the NAT-PT to the other (the direction is not specified by the NAT-PT specification). If no packets are sent in the proper direction, the NAT-PT binding will not be refreshed and the application connection will be broken. Hence, all applications need to maintain their NAT-PT bindings during long idle periods by incorporating a keepalive mechanism, which may not be possible for legacy systems.
動的バインディングがソフト状態のタイムアウトよりも長く持続するには、パケットをNAT-PTの片側から他方に定期的に送信する必要があります（方向はNAT-PT仕様では指定されていません）。適切な方向にパケットが送信されない場合、NAT-PTバインディングは更新されず、アプリケーション接続が破損します。したがって、すべてのアプリケーションは、レガシーシステムでは不可能なキープライブメカニズムを組み込むことにより、長いアイドル期間中にNAT-PTバインディングを維持する必要があります。
Also, [RFC2766] does not specify how to choose timeouts for bindings. As discussed in [RFC2663] for traditional NATs, selecting suitable values is a matter of heuristics, and coordinating with application expectations may be impossible.
また、[RFC2766]は、バインディングのタイムアウトを選択する方法を指定していません。従来のNATについて[RFC2663]で説明したように、適切な値を選択することはヒューリスティックの問題であり、アプリケーションの期待との調整は不可能かもしれません。
NAT-PT reuses the SIIT header and protocol translations defined in [RFC2765]. Mismatches in semantics between IPv4 and IPv6 versions can lead to loss of information when packets are translated. Three issues arising from this are:
NAT-PTは、[RFC2765]で定義されているSIITヘッダーとプロトコル翻訳を再利用します。IPv4バージョンとIPv6バージョンの間のセマンティクスの不一致は、パケットが翻訳されると情報の損失につながる可能性があります。これから生じる3つの問題は次のとおりです。
o There is no equivalent in IPv4 for the flow label field of the IPv6 header. Hence, any special treatment of packets based on flow label patterns cannot be propagated into the IPv4 domain.
o IPv6ヘッダーのフローラベルフィールドには、IPv4に相当するものはありません。したがって、フローラベルパターンに基づくパケットの特別な処理は、IPv4ドメインに伝播することはできません。
o IPv6 extension headers provide flexibility for future improvements in the IP protocol suite and new headers that do not have equivalents in IPv4 may be defined. In practice, some existing extensions such as routing headers and mobility extensions are not translatable.
o IPv6エクステンションヘッダーは、IPプロトコルスイートの将来の改善に柔軟性を提供し、IPv4に同等のものを持たない新しいヘッダーが定義される場合があります。実際には、ルーティングヘッダーやモビリティエクステンションなどの既存の拡張機能は翻訳できません。
o As described in Section 2.2 of [NATP-APP], there are no equivalents in IPv6 for some ICMP(v4) messages, while for others (notably the 'Parameter Problem' messages) the semantics are not equivalent. Translation of such messages may lead to the loss of information. However, this issue may not be very severe because the error messages relate to packets that have been translated by NAT-PT rather than by arbitrary packets. If the NAT-PT is functioning correctly, there is, for example, no reason why IPv6 packets with unusual extension headers or options should be generated.
o [NATP-APP]のセクション2.2で説明されているように、一部のICMP（V4）メッセージにはIPv6に等価物はありませんが、他のメッセージ（特に「パラメーター問題」メッセージ）については、セマンティクスは同等ではありません。そのようなメッセージの翻訳は、情報の喪失につながる可能性があります。ただし、エラーメッセージは任意のパケットではなくNAT-PTによって翻訳されたパケットに関連しているため、この問題はそれほど深刻ではないかもしれません。NAT-PTが正しく機能している場合、例えば、異常な拡張ヘッダーまたはオプションを備えたIPv6パケットを生成する理由はありません。
Loss of information in any of these cases could be a constraint to certain applications.
これらの場合の情報の損失は、特定のアプリケーションに対する制約となる可能性があります。
A related matter concerns the propagation of the Differentiated Services Code Point (DSCP). NAT-PT and SIIT simply copy the DSCP field when translating packets. Accordingly, the IPv4 and IPv6 domains must have equivalent Per-Hop Behaviors for the same code point, or alternative means must be in place to translate the DSCP between domains.
関連する問題は、差別化されたサービスコードポイント（DSCP）の伝播に関するものです。NAT-PTとSIITは、パケットを翻訳するときにDSCPフィールドをコピーするだけです。したがって、IPv4ドメインとIPv6ドメインは、同じコードポイントに対して同等のホップごとの動作を持つ必要があります。または、DSCPをドメイン間で翻訳するためには、代替手段を整える必要があります。
As mentioned in [RFC3027], simple port translators are unable to translate packet fragments, other than the first, from a fragmented packet, because subsequent fragments do not contain the port number information.
[RFC3027]で述べたように、単純なポート翻訳者は、断片化されたパケットから最初のパケットフラグメント以外のパケットフラグメントを翻訳することができません。後続のフラグメントにはポート番号情報が含まれていないためです。
This means that, in general, fragmentation cannot be allowed for any traffic that traverses a NAPT-PT. One attempted workaround requires the NAPT-PT to maintain state information derived from the first fragment until all fragments of the packet have transited the NAPT-PT. This is not a complete solution because fragment misordering could lead to the first fragment appearing at the NAPT-PT after later fragments. Consequently, the NAPT-PT would not have the information needed to translate the fragments received before the first.
これは、一般に、ナプトPTを横断するトラフィックに断片化を許可できないことを意味します。回避策の1つでは、パケットのすべてのフラグメントがNAPT-PTを通過するまで、最初のフラグメントから派生した状態情報を維持するためにNAPT-PTが必要です。これは完全な解決策ではありません。これは、フラグメントの誤用が、後の断片の後にNapt-PTに最初のフラグメントが現れる可能性があるためです。したがって、NAPT-PTには、最初の断片を翻訳するために必要な情報がありません。
Although it would not be expected in normal operation, NAPT-PT needs to be proofed against receiving short first fragments that don't contain the transport port numbers. Note that such packets are a problem for many forms of stateful packet inspection applied to IPv6 packets. The current specifications of IPv6 do not mandate (1) any minimum packet size beyond the need to carry the unfragmentable part (which doesn't include the transport port numbers) or (2) reassembly rules to minimize the effects of overlapping fragments. Thus, IPv6 is open to the sort of attacks described in [RFC1858] and [RFC3128].
通常の動作では予想されませんが、NAPT-PTは、輸送ポート番号を含まない短い最初のフラグメントを受け取ることに対して証明する必要があります。このようなパケットは、IPv6パケットに適用される多くの形式のステートフルパケット検査の問題であることに注意してください。IPv6の現在の仕様は、（1）重複するフラグメントの影響を最小限に抑えるために、フラージュ不可能な部分（輸送ポート番号は含まれない）または（2）再組み立てルールを運ぶ必要性を超えた最小パケットサイズを義務付けていません。したがって、IPv6は[RFC1858]および[RFC3128]で説明されている種類の攻撃に対して開かれています。
An additional concern arises when a fragmented IPv4 UDP packet, which does not have a transport-layer checksum, traverses any type of NAT-PT box. As described in [RFC2766], the NAT-PT has to reconstruct the whole packet so that it can calculate the checksum needed for the translated IPv6 packet. This can result in a significant delay to the packet, especially if it has to be re-fragmented before transmission on the IPv6 side.
輸送層チェックサムがない断片化されたIPv4 UDPパケットが、あらゆるタイプのNAT-PTボックスを横断する場合、追加の懸念が生じます。[RFC2766]で説明されているように、NAT-PTはパケット全体を再構築して、翻訳されたIPv6パケットに必要なチェックサムを計算できるようにする必要があります。これにより、特にIPv6側に送信する前に再編成する必要がある場合は、パケットが大幅に遅れる可能性があります。
If NAT-PT boxes reassembled all incoming fragmented packets (both from the IPv4 and IPv6 directions) in the same way they have to for unchecksummed IPv4 UDP packets, this would be a solution to the first problem. The resource cost would be considerable apart from the potential delay problem if the outgoing packet has to be re-fragmented. In any case, fragmentation would mean that the NAT-PT would consume extra memory and CPU resources, making the NAT-PT even less scalable (see Section 3.2).
NAT-PTボックスが、すべての断片化されたパケット（IPv4およびIPv6の方向からの両方）を再構築した場合、Unchecummed IPv4 UDPパケットに対して必要な方法で、これは最初の問題の解決策になります。リソースコストは、発信パケットを再燃させる必要がある場合、潜在的な遅延問題とは別にかなりのものです。いずれにせよ、断片化は、NAT-PTが追加のメモリとCPUリソースを消費し、NAT-PTのスケーラブルをさらに低下させることを意味します（セクション3.2を参照）。
Packet reassembly in a NAT-PT box also opens up the possibility of various fragment-related security attacks. Some of these are analogous to attacks identified for IPv4. Of particular concern is a DoS attack based on sending large numbers of small fragments without a terminating last fragment, which would potentially overload the reconstruction buffers and consume large amounts of CPU resources.
NAT-PTボックスのパケットの再組み立ては、さまざまなフラグメント関連のセキュリティ攻撃の可能性も開きます。これらのいくつかは、IPv4で特定された攻撃に類似しています。特に懸念されるのは、最後のフラグメントを終了することなく多数の小さなフラグメントを送信することに基づくDOS攻撃です。これにより、再構成バッファーに過負荷になり、大量のCPUリソースが消費されます。
The Stream Control Transmission Protocol (SCTP) [RFC2960] is a transport protocol, which has been standardized since SIIT was specified. SIIT does not explicitly cover the translation of SCTP, but SCTP uses transport port numbers in the same way that UDP and TCP do, so similar techniques can be used when translating SCTP packets.
Stream Control Transmission Protocol（SCTP）[RFC2960]は、SIITが指定されてから標準化されている輸送プロトコルです。SIITはSCTPの翻訳を明示的にカバーしていませんが、SCTPはUDPとTCPと同じ方法でトランスポートポート番号を使用するため、SCTPパケットを翻訳するときに同様の手法を使用できます。
However, SCTP also supports multihoming. During connection setup, SCTP control packets carry embedded addresses that would have to be translated. This would also require that the types of the options fields in the SCTP control packets be changed with consequent changes to packet length; the transport checksum would also have to be recalculated. The ramifications of multihoming as it might interact with NAT-PT have not been fully explored. Because of the 'chunked' nature of data transfer, it does not appear that that state would have to be maintained to relate packets transmitted using the different IP addresses associated with the connection.
ただし、SCTPはマルチホミングもサポートしています。接続セットアップ中、SCTP制御パケットは、翻訳する必要がある埋め込みアドレスを持ちます。また、これには、SCTP制御パケットのオプションフィールドのタイプを変更する必要があります。輸送チェックサムも再計算する必要があります。NAT-PTと相互作用する可能性のあるマルチホームの影響は完全には検討されていません。データ転送の「チャンク」の性質のため、接続に関連付けられた異なるIPアドレスを使用して送信されたパケットを関連付けるために、その状態を維持する必要があるとは思われません。
Even if these technical issues can be overcome, using SCTP in a NAT-PT environment may effectively nullify the multihoming advantages of SCTP if all the connections run through the same NAT-PT. The consequences of running a multihomed network with separate NAT-PT boxes associated with each of the 'homes' have not been fully explored, but one issue that will arise is described in Section 4.4. SCTP will need an associated "ALG" -- actually a Transport Layer Gateway -- to handle the packet payload modifications. If it turns out that that state is required, the state would have to be distributed and synchronized across several NAT-PT boxes in a multihomed environment.
これらの技術的な問題を克服できる場合でも、NAT-PT環境でSCTPを使用すると、すべての接続が同じNAT-PTを通過する場合、SCTPのマルチホームの利点を効果的に無効にする可能性があります。それぞれの「家」に関連付けられた個別のNAT-PTボックスを使用してマルチホームネットワークを実行した結果は完全には検討されていませんが、発生する1つの問題については、セクション4.4で説明しています。SCTPには、パケットペイロードの変更を処理するために、関連する「アルグ」（実際にはトランスポートレイヤーゲートウェイ）が必要です。その状態が必要であることが判明した場合、状態は、マルチホーム環境のいくつかのNAT-PTボックスに分散して同期する必要があります。
SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1.
マルチホーム環境でNAT-PTを実行するSCTPは、セクション2.1で説明されているように、IPSECとも互換性がありません。
As discussed in [NATPT-MOB], it is not possible to propagate Mobile IPv6 (MIPv6) control messages into the IPv4 domain. According to the IPv6 Node Requirements [RFC4294], IPv6 nodes should normally be prepared to support the route optimization mechanisms needed in a correspondent node. If communications from an IPv6 mobile node are traversing a NAT-PT, the destination IPv4 node will certainly not be able to support the correspondent node features needed for route optimization.
[Natpt-Mob]で説明したように、モバイルIPv6（MIPV6）をIPv4ドメインに制御するメッセージを伝播することはできません。IPv6ノード要件[RFC4294]によると、通常、IPv6ノードは、特派員ノードで必要なルート最適化メカニズムをサポートするために準備する必要があります。IPv6モバイルノードからの通信がNAT-PTを通過している場合、宛先IPv4ノードは、ルートの最適化に必要な特派員ノード機能を確実にサポートできません。
This can be resolved in two ways:
これは2つの方法で解決できます。
o The NAT-PT can discard messages and headers relating to changes of care-of addresses, including reverse routing checks. Communications with the mobile node will continue through the home agent without route optimization. This is clearly sub-optimal, but communication should remain possible.
o NAT-PTは、逆ルーティングチェックを含む、住所のケアの変更に関連するメッセージとヘッダーを破棄できます。モバイルノードとの通信は、ルートの最適化なしにホームエージェントを介して継続します。これは明らかに最適ですが、コミュニケーションは引き続き可能です。
o Additional functionality could be implemented in the NAT-PT to allow it to function as a proxy correspondent node for all IPv4 nodes for which it has bindings. This scheme adds considerably to the complexity of NAT-PT. Depending on the routability of the IPv6 PREFIX used for translated IPv4 addresses, it may also limit the extent of mobility of the mobile node: all communications to the IPv4 destination have to go through the same NAT-PT, even if the mobile node moves to a network that does not have direct IPv6 connectivity with the NAT-PT.
o NAT-PTに追加の機能を実装して、バインディングを持つすべてのIPv4ノードのプロキシ特派員ノードとして機能できるようにすることができます。このスキームは、NAT-PTの複雑さをかなり追加します。翻訳されたIPv4アドレスに使用されるIPv6プレフィックスのルーチャ性に応じて、モバイルノードのモビリティのモビリティの範囲を制限する場合があります。IPv4宛先へのすべての通信は、モバイルノードが移動しても同じNAT-PTを通過する必要があります。NAT-PTとの直接IPv6接続を持たないネットワーク。
In both cases, the existing NAT-PT specification would need to be extended to deal with IPv6 mobile nodes, and neither is a fully satisfactory solution.
どちらの場合も、既存のNAT-PT仕様をIPv6モバイルノードに対処するために拡張する必要があり、どちらも完全に満足のいくソリューションではありません。
SIIT [RFC2765] cannot handle the translation of multicast packets and NAT-PT does not discuss a way to map multicast addresses between IPv4 and IPv6. Some separate work has been done to provide an alternative mechanism to handle multicast. This work uses a separate gateway that understands some or all of the relevant multicast control and routing protocols in each domain. It has not yet been carried through into standards.
SIIT [RFC2765]はマルチキャストパケットの翻訳を処理できず、NAT-PTはIPv4とIPv6の間でマルチキャストアドレスをマッピングする方法を議論していません。マルチキャストを処理するための代替メカニズムを提供するために、いくつかの別々の作業が行われました。この作業では、各ドメインの関連するマルチキャスト制御およびルーティングプロトコルの一部またはすべてを理解する別のゲートウェイを使用します。それはまだ基準に伝えられていません。
A basic mechanism, which involves only IGMP on the IPv4 side and MLD on the IPv6 side, is described in 'An IPv6-IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)' [MTP]. A more comprehensive approach, which includes proxying of the multicast routing protocols, is described in 'An IPv4 - IPv6 multicast gateway' [MCASTGW]. Both approaches have several of the issues described in this section, notably issues with embedded addresses.
IPv4側のIGMPとIPv6側のMLDのみを含む基本的なメカニズムは、IGMP/MLDプロキシ（MTP）[MTP]に基づくIPv6-IPV4マルチキャスト翻訳者に記載されています。マルチキャストルーティングプロトコルのプロキシを含む、より包括的なアプローチは、「IPv4 -IPv6マルチキャストゲートウェイ」[MCASTGW]で説明されています。両方のアプローチには、このセクションで説明されているいくつかの問題、特に埋め込まれたアドレスの問題があります。
[NATPT-SEC] identifies the possibility of a multiplicative reflection attack if the NAT-PT can be spoofed into creating a binding for a multicast address. This attack would be very hard to mount because routers should not forward packets with multicast addresses in the source address field. However, it highlights the possibility that a naively implemented DNS-ALG could create such bindings from spoofed DNS responses since [RFC2766] does not mention the need for checks on the types of addresses in these responses.
[NATPT-SEC] NAT-PTをスプーフィングしてマルチキャストアドレスのバインディングを作成できる場合、乗法反射攻撃の可能性を特定します。ルーターは、ソースアドレスフィールドにマルチキャストアドレスを備えたパケットを転送しないでください。この攻撃は非常に困難です。ただし、[RFC2766]がこれらの応答のアドレスの種類のチェックの必要性について言及していないため、素朴に実装されたDNS-ALGがスプーフィングされたDNS応答からこのようなバインディングを作成できる可能性を強調しています。
The issues for NAT-PT and multicast reflect the fact that NAT-PT is at best a partial solution. Completing the translation solution to cater for multicast traffic is likely to carry a similar set of issues to the current unicast NAT-PT and may open up significant additional security risks.
NAT-PTとマルチキャストの問題は、NAT-PTがせいぜい部分的な解決策であるという事実を反映しています。マルチキャストトラフィックに対応するための翻訳ソリューションを完了すると、現在のユニキャストNAT-PTに同様の問題が発生する可能性が高く、重大な追加のセキュリティリスクが開かれる可能性があります。
Traffic flow initiators in a NAT-PT environment are dependent on the DNS-ALG in the NAT-PT to provide the mapped address needed to communicate with the flow destination on the other side of the NAT-PT. Whether used for flows initiated in the IPv4 domain or the IPv6 domain, the NAT-PT has to be on the path taken by the DNS query sent by the flow initiator to the relevant DNS server; otherwise, the DNS query will not be modified and the response type will not be appropriate.
NAT-PT環境のトラフィックフローイニシエーターは、NAT-PTのDNS-ALGに依存して、NAT-PTの反対側のフロー宛先と通信するために必要なマップアドレスを提供します。IPv4ドメインまたはIPv6ドメインで開始されたフローに使用されるかどうかにかかわらず、NAT-PTは、Flowイニシエーターから関連するDNSサーバーに送信されたDNSクエリによって取られたパス上にある必要があります。それ以外の場合、DNSクエリは変更されず、応答タイプは適切ではありません。
The implication is that the NAT-PT box also has to be the default IPv6 router for the site so that the DNS-ALG is able to examine all DNS requests made over IPv6. On sites with both IPv6 and dual-stack nodes, this will result in all traffic flowing through the NAT-PT with consequent scalability concerns.
意味は、DNS-AlgがIPv6を介して作成されたすべてのDNS要求を調べることができるように、サイトのNAT-PTボックスもデフォルトのIPv6ルーターでなければならないことです。IPv6ノードとデュアルスタックノードの両方を備えたサイトでは、結果としてスケーラビリティの懸念が伴うNAT-PTを介してすべてのトラフィックが流れるようになります。
These constraints are described in more detail in [DNS-ALG-ISSUES].
これらの制約については、[DNS-Alg-Issues]でより詳細に説明されています。
[DNS-ALG-SOL] proposes a solution for flows initiated from the IPv6 domain, but it appears that this solution still has issues.
[DNS-ALG-SOL]は、IPv6ドメインから開始されたフローのソリューションを提案していますが、このソリューションにはまだ問題があるようです。
For IPv6-only clients, the solution requires the use of a DNS server in the IPv4 domain, accessed via an IPv6 address which uses the NAT-PT PREFIX (see [RFC2766]). Queries to this server would necessarily pass through the NAT-PT. Dual-stack hosts would use a separate DNS server accessed through a normal IPv6 address. This removes the need for the NAT-PT box to be the default IPv6 gateway for the domain.
IPv6のみのクライアントの場合、ソリューションでは、NAT-PTプレフィックスを使用するIPv6アドレスを介してアクセスされるIPv4ドメインでDNSサーバーを使用する必要があります（[RFC2766]を参照）。このサーバーのクエリは、必然的にNAT-PTを通過します。デュアルスタックホストは、通常のIPv6アドレスを介してアクセスされる個別のDNSサーバーを使用します。これにより、NAT-PTボックスがドメインのデフォルトのIPv6ゲートウェイになる必要がなくなります。
The primary proposal suggests that the IPv6-only clients should use this DNS server for all queries. This is expensive on NAT-PT resources because requests relating to hosts with native IPv6 addresses would also use the NAT-PT DNS-ALG.
主な提案は、IPv6のみのクライアントがすべてのクエリにこのDNSサーバーを使用する必要があることを示唆しています。これは、Nat-PTリソースでは高価です。これは、ネイティブIPv6アドレスを持つホストに関連するリクエストもNAT-PT DNS-Algを使用するためです。
The alternate suggestion to reduce this burden appears to be flawed: if IPv6-only clients are provided with a list of DNS servers including both the server accessed via NAT-PT and server(s) accessed natively via IPv6, the proposal suggests that the client could avoid using NAT-PT for hosts that have native IPv6 addresses.
この負担を軽減するための代替提案には欠陥があるように見えます。IPv6のみのクライアントに、NAT-PTを介してアクセスされるサーバーとIPv6を介してネイティブにアクセスされるサーバーの両方を含むDNSサーバーのリストが提供されている場合、提案はクライアントがクライアントが示唆しています。ネイティブIPv6アドレスを持つホストにNAT-PTを使用することを避けることができます。
Unfortunately, for the alternate suggestion, there is no a priori way in which the initiator can decide which DNS server to use for a particular query. In the event that the initiator makes the wrong choice, the DNS query will return an empty list rather than failing to respond. With standard DNS logic, the initiator will not try alternative DNS servers because it has received a response. This means that the solution would consist of always using DNS servers having the NAT-PT PREFIX. This imposes the burden of always requiring the DNS RR (Resource Record) [RFC1035] translation.
残念ながら、代替の提案のために、イニシエーターが特定のクエリに使用するDNSサーバーを決定できるアプリオリの方法はありません。イニシエーターが間違った選択をした場合、DNSクエリは応答に失敗するのではなく、空のリストを返します。標準のDNSロジックを使用すると、イニシエーターは応答を受け取ったため、代替DNSサーバーを試しません。これは、ソリューションが常にNAT-PTプレフィックスを持つDNSサーバーを使用することで構成されることを意味します。これは、常にDNS RR（リソースレコード）[RFC1035]翻訳を必要とする負担を課します。
For flows initiated from the IPv4 network, the proposal recommends that the advertised DNS servers for the IPv6 network would have the IPv4 address of the NAT-PT. Again there is no deterministic way to choose the correct DNS server for each query resulting in the same issues as were raised for flows initiated from the IPv6 domain.
IPv4ネットワークから開始されたフローの場合、提案は、IPv6ネットワークの広告されたDNSサーバーにNAT-PTのIPv4アドレスを持つことを推奨しています。繰り返しますが、各クエリに対して正しいDNSサーバーを選択する決定論的な方法はありません。その結果、IPv6ドメインから開始されたフローのために提起されたのと同じ問題が発生しました。
Although the engineering workaround, just described, provides a partial solution to the topology constraints issue, it mandates that DNS queries and responses should still go through a NAT-PT even if there would normally be no reason to do so. This mandatory passage through the NAT-PT for all DNS requests will exacerbate the other DNS-related issues discussed in Section 3.4 and Section 4.1.
記述されたばかりのエンジニアリングの回避策は、トポロジの制約の問題に対する部分的な解決策を提供しますが、通常はそうする理由がない場合でも、DNSクエリと応答がNAT-PTを通過することを義務付けています。すべてのDNS要求のNAT-PTを通過するこの必須の通過は、セクション3.4およびセクション4.1で説明した他のDNS関連の問題を悪化させます。
As with traditional NAT, NAT-PT is a bottleneck in the network with significant scalability concerns. Furthermore, the anchoring of flows to a particular NAT-PT makes the NAT-PT a potential single point of failure in the network. The addition of the DNS-ALG in NAT-PT further increases the scalability concerns.
従来のNATと同様に、NAT-PTはネットワーク内のボトルネックであり、重要なスケーラビリティの懸念があります。さらに、特定のNAT-PTへのフローの固定により、NAT-PTはネットワーク内の潜在的な単一の障害点になります。NAT-PTにDNS-ALGを追加すると、スケーラビリティの懸念がさらに高まります。
Solutions to both problems have been envisaged using collections of cooperating NAT-PT boxes, but such solutions require coordination and state synchronization, which has not yet been standardized and again adds to the functional and operational complexity of NAT-PT. One such solution is described in [MUL-NATPT].
両方の問題の解決策は、協力するNAT-PTボックスのコレクションを使用して想定されていますが、そのようなソリューションには調整と状態の同期が必要です。これはまだ標準化されておらず、NAT-PTの機能的および運用上の複雑さを再生します。そのようなソリューションの1つは[Mul-natpt]で説明されています。
As with traditional NAT, the concentration of flows through NAT-PT and the legitimate modification of packets in the NAT-PT make NAT-PTs enticing targets for security attacks.
従来のNATと同様に、NAT-PTを介した流れの濃度とNAT-PTのパケットの合法的な変更により、NAT-PTSはセキュリティ攻撃のためにターゲットを誘惑します。
Using the DNS-ALG to create address bindings requires that the translated address returned by the DNS query is used for communications before the NAT-PT binding state is timed out (see Section 2.3). Applications will not normally be aware of this constraint, which may be different from the existing lifetime of DNS query responses. This could lead to "difficult to diagnose" problems with applications.
DNS-ALGを使用してアドレスバインディングを作成するには、DNSクエリによって返される翻訳されたアドレスがNAT-PTバインド状態がタイムアウトする前に通信に使用される必要があります（セクション2.3を参照）。アプリケーションは通常、この制約を認識しません。これは、DNSクエリ応答の既存の寿命とは異なる場合があります。これにより、アプリケーションに関する「診断が困難」の問題につながる可能性があります。
Additionally, the DNS-ALG needs to determine the initial lifetime of bindings that it creates. As noted in Section 2.3, this may need to be determined heuristically. The DNS-ALG does not know which protocol the mapping is to be used for, and so needs another way to determine the initial lifetime. This could be tied to the DNS response lifetime, but that might open up additional DoS attack possibilities if very long binding lifetimes are allowed. Also, the lifetime should be adjusted once the NAT-PT determines which protocol is being used with the binding.
さらに、DNS-Algは、作成するバインディングの初期寿命を決定する必要があります。セクション2.3で述べたように、これはヒューリスティックに決定する必要がある場合があります。DNS-Algは、どのプロトコルが使用されるかを知らないため、初期寿命を決定するための別の方法が必要です。これは、DNS応答の寿命に結び付けられる可能性がありますが、非常に長いバインド寿命が許可されている場合、追加のDOS攻撃の可能性を開く可能性があります。また、NAT-PTがどのプロトコルがバインディングで使用されているかを決定したら、寿命を調整する必要があります。
As with traditional NATs (see Section 2.5 of [RFC3027]), NAT-PT will most likely break applications that require address mapping to be retained across contiguous sessions. These applications require the IPv4 to IPv6 address mapping to be retained between sessions so the same mapped address may be reused for subsequent session interactions. NAT-PT cannot know this requirement and may reassign the previously used mapped address to different hosts between sessions.
従来のNAT（[RFC3027]のセクション2.5を参照）と同様に、NAT-PTは、隣接するセッション全体でアドレスマッピングを保持する必要があるアプリケーションを破壊する可能性が最も高くなります。これらのアプリケーションでは、IPv4からIPv6アドレスマッピングをセッション間で保持する必要があります。そのため、同じマッピングされたアドレスが後続のセッションインタラクションのために再利用される可能性があります。NAT-PTはこの要件を知ることができず、以前に使用したマップされたアドレスをセッション間で異なるホストに再割り当てする場合があります。
Trying to keep NAT-PT from discarding an address mapping would require either a NAT-PT extension protocol that would allow the application to request the NAT-PT device to retain the mappings, or an extended ALG (which has all the issues discussed in Section 2.1) that can interact with NAT-PT to keep the address mapping from being discarded after a session.
NAT-PTがアドレスマッピングを破棄しないようにしようとするには、アプリケーションがNAT-PTデバイスにマッピングの保持を要求できるNAT-PT拡張プロトコルまたは拡張アルグ（セクションで説明されているすべての問題があります。2.1）それは、セッション後にアドレスマッピングが破棄されないようにNAT-PTと対話できます。
As discussed in Section 2.3, a NAT-PT may create dynamic NAT bindings, each of which consumes memory resources as well as an address (or port if NAPT-PT is used) from an address (or port) pool. A number of documents, including [RFC2766] and [NATPT-SEC] discuss the possible denial of service (DoS) attacks on basic NAT-PT and NAPT-PT that would result in a resource depletion associated with address and port pools. NAT-PT does not specify any authentication mechanisms; thus, an attacker may be able to create spurious bindings by spoofing addresses in packets sent through NAT-PT. The attack is more damaging if the attacker is able to spoof protocols with long binding timeouts (typically used for TCP).
セクション2.3で説明したように、NAT-PTは動的なNATバインディングを作成する場合があり、それぞれがアドレス（またはポート）プールからメモリリソースとアドレス（またはNAPT-PTが使用されている場合はポート）を消費します。[RFC2766]や[NatPT-Sec]を含む多くのドキュメントは、アドレスプールとポートプールに関連するリソースの枯渇をもたらす基本的なNAT-PTおよびNAPT-PTに対するサービス拒否（DOS）攻撃について議論します。NAT-PTは、認証メカニズムを指定していません。したがって、攻撃者は、NAT-PTを介して送信されたパケットにスプーフィングアドレスを作成することにより、スプリアスなバインディングを作成できる場合があります。攻撃者が長いバインディングタイムアウト（通常はTCPに使用される）でプロトコルをスプーフィングできる場合、攻撃はより損害を与えます。
The use of the DNS-ALG in NAT-PT introduces another vulnerability that can result in resource depletion. The attack identified in [DNS-ALG-ISSUES] exploits the use of DNS queries traversing NAT-PT to create dynamic bindings. Every time a DNS query is sent through the NAT-PT, the NAT-PT may create a new basic NAT-PT or NAPT-PT binding without any end-host authentication or authorization mechanisms. This behavior could lead to a serious DoS attack on both memory and address or port pools. Address spoofing is not required for this attack to be successful.
NAT-PTでDNS-ALGを使用すると、リソースの枯渇をもたらす可能性のある別の脆弱性が導入されます。[DNS-Alg-Issues]で特定された攻撃は、NAT-PTを通過するDNSクエリの使用を活用して動的バインディングを作成します。DNSクエリがNAT-PTを介して送信されるたびに、NAT-PTは、エンドホスト認証または承認メカニズムなしに、新しい基本NAT-PTまたはNAPT-PTバインディングを作成する場合があります。この動作は、メモリとアドレスプールまたはポートプールの両方に深刻なDOS攻撃につながる可能性があります。この攻撃を成功させるには、アドレススプーフィングは必要ありません。
[DNS-ALG-SOL] proposes to mitigate the DoS attack by using Access Control Lists (ACLs) and static binds, which increases the operational cost and may not always be practical.
[DNS-ALG-SOL]は、アクセス制御リスト（ACL）と静的バインドを使用してDOS攻撃を軽減することを提案します。これにより、運用コストが増加し、常に実用的ではない場合があります。
The ideal mitigation solution would be to disallow dynamically created binds until authentication and authorization of the end-host needing the protocol translation has been carried out. This would require that the proper security infrastructure be in place to support the authentication and authorization, which increases the network operational complexity.
理想的な緩和ソリューションは、プロトコルの翻訳が必要なエンドホストの認証と承認が実行されるまで、動的に作成されたバインドを許可することです。これには、認証と承認をサポートするために適切なセキュリティインフラストラクチャが整備され、ネットワークの運用の複雑さが向上する必要があります。
[DNS-ALG-ISSUES] discusses NAT-PT DNS-ALG issues with regard to address selection. As specified in [RFC2766], the DNS-ALG returns AAAA Resource Records (RRs) from two possible sources, to the IPv6 host that has made an AAAA DNS query.
[DNS-Alg-Issues]アドレス選択に関するNAT-PT DNS-ALGの問題について説明します。[RFC2766]で指定されているように、DNS-ALGは、AAAAリソースレコード（RRS）を2つの可能なソースから、AAAA DNSクエリを作成したIPv6ホストに戻します。
If the query relates to a dual-stack host, the query will return both the native IPv6 address(es) and the translated IPv4 address(es) in AAAA RRs. Without additional information, the IPv6 host address selection may pick a translated IPv4 address instead of selecting the more appropriate native IPv6 address. Under some circumstances, the address selection algorithms [RFC3484] will always prefer the translated address over the native IPv6 address; this is obviously undesirable.
クエリがデュアルスタックホストに関連する場合、クエリはAAAA RRSのネイティブIPv6アドレス（ES）と翻訳されたIPv4アドレス（ES）の両方を返します。追加情報がなければ、IPv6ホストアドレスの選択は、より適切なネイティブIPv6アドレスを選択する代わりに、翻訳されたIPv4アドレスを選択する場合があります。状況によっては、アドレス選択アルゴリズム[RFC3484]は、常にネイティブIPv6アドレスよりも翻訳されたアドレスを好みます。これは明らかに望ましくありません。
[DNS-ALG-SOL] proposes a solution that involves modification to the NAT-PT specification intended to return only the most appropriate address(es) to an IPv6 capable host as described below:
[DNS-ALG-SOL]は、以下に説明するように、最も適切なアドレスのみをIPv6対応ホストに返すことを目的としたNAT-PT仕様の変更を伴うソリューションを提案します。
o When a DNS AAAA query traverses the NAT-PT DNS-ALG, the NAT-PT will forward the query to the DNS server in the IPv4 domain unchanged, but using IPv4 transport. The following two results can occur:
o DNS AAAAクエリがNAT-PT DNS-ALGを通過すると、NAT-PTはIPv4ドメインのIPv4トランスポートを使用して、IPv4ドメインのDNSサーバーにクエリを転送します。次の2つの結果が発生する可能性があります。
* If the authoritative DNS server has one or more AAAA records, it returns them. The DNS-ALG then forwards this response to the IPv6 host and does not send an A query as the standard NAT-PT would do.
* 権威あるDNSサーバーに1つ以上のAAAAレコードがある場合、それらを返します。次に、DNS-Algはこの応答をIPv6ホストに転送し、標準のNAT-PTが行うようにAクエリを送信しません。
* Otherwise, if the DNS server does not understand the AAAA query or has no AAAA entry for the host, it will return an error. The NAT-PT DNS-ALG will intercept the error or empty return and send an A query for the same host. If this query returns an IPv4 address, the ALG creates a binding and synthesizes a corresponding AAAA record, which it sends back to the IPv6 host.
* それ以外の場合、DNSサーバーがAAAAクエリを理解していない場合、またはホストのAAAAエントリがない場合、エラーが返されます。NAT-PT DNS-Algは、エラーまたは空の返品を傍受し、同じホストのクエリを送信します。このクエリがIPv4アドレスを返す場合、アルグはバインディングを作成し、対応するAAAAレコードを合成し、IPv6ホストに送り返します。
o The NAT-PT thus forwards the result of the first successful DNS response back to the end-host or an error if neither succeeds. Consequently, only AAAA RRs from one source will be provided instead of two as specified in [RFC2766], and it will contain the most appropriate address for a dual-stack or IPv6-only querier.
o したがって、NAT-PTは、最初に成功したDNS応答の結果をエンドホストに戻すか、どちらも成功しなかった場合に転送します。したがって、[RFC2766]で指定されている2つではなく、1つのソースからのAAAA RRのみが提供され、デュアルスタックまたはIPv6のみのクエリエに最適なアドレスが含まれます。
There is, however, still an issue with the proposed solution:
ただし、提案されたソリューションにはまだ問題があります。
o The DNS client may timeout the query if it doesn't receive a response in time. This is more likely than for queries not passing through a DNS ALG because the NAT-PT may have to make two separate, sequential queries of which the client is not aware. It may be possible to reduce the response time by sending the two queries in parallel and ignoring the result of the A query if the AAAA returns one or more addresses. However, it is still necessary to delay after receiving the first response to determine if a second is coming, which may still trigger the DNS client timeout.
o DNSクライアントは、時間内に応答を受信しない場合、クエリをタイムアウトする場合があります。これは、NAT-PTがクライアントが認識していない2つの別々のシーケンシャルクエリを作成する必要がある場合があるため、DNSアルグを通過しないクエリよりも可能性が高くなります。AAAAが1つ以上のアドレスを返す場合、2つのクエリを並行して2つのクエリを送信し、Aクエリの結果を無視することにより、応答時間を短縮することが可能かもしれません。ただし、最初の応答を受け取った後も遅延して、2番目の応答が来ているかどうかを判断する必要があります。これにより、DNSクライアントのタイムアウトが引き起こされる場合があります。
Unfortunately, the two queries cannot be combined in a single DNS request (all known DNS servers only process a single DNS query per request message because of difficulties expressing authoritativeness for arbitrary combinations of requests).
残念ながら、2つのクエリを単一のDNSリクエストで結合することはできません（すべての既知のDNSサーバーは、リクエストの任意の組み合わせの権威性を表現するのが難しいため、リクエストメッセージごとに単一のDNSクエリのみを処理します）。
An alternative solution would be to allow the IPv6 host to use the NAT-PT PREFIX [RFC2766] within its address selection policies and to assign it a low selection priority. This solution requires an automatic configuration of the NAT-PT PREFIX as well as its integration within the address selection policies. The simplest way to integrate this automatic configuration would be through a configuration file download (in case the host or Dynamic Host Configuration Protocol for IPv6 (DHCPv6) server did not support vendor options and to avoid a standardization effort on the NAT-PT PREFIX option). This solution does not require any modification to the NAT-PT specification.
別のソリューションは、IPv6ホストがアドレス選択ポリシー内でNAT-PTプレフィックス[RFC2766]を使用し、選択の優先度が低いことを許可することです。このソリューションには、NAT-PTプレフィックスの自動構成と、アドレス選択ポリシー内での統合が必要です。この自動構成を統合する最も簡単な方法は、構成ファイルのダウンロードを使用することです（IPv6（DHCPV6）サーバーのホストまたはダイナミックホスト構成プロトコルがベンダーオプションをサポートせず、NAT-PTプレフィックスオプションの標準化の取り組みを回避した場合）。このソリューションでは、NAT-PT仕様の変更は必要ありません。
Neither of these solutions resolves a second issue related to address selection that is identified in [DNS-ALG-ISSUES]. Applications have no way of knowing that the IPv6 address returned from the DNS-ALG is not a 'real' IPv6 address, but a translated IPv4 address. The application may therefore, be led to believe that it has end-to-end IPv6 connectivity with the destination. As a result, the application may use IPv6-specific options that are not supported by NAT-PT. This issue is closely related to the issue described in Section 4.2 and the discussion in Section 5.
これらのソリューションのいずれも、[DNS-Alg-Issues]で特定されたアドレス選択に関連する2番目の問題を解決しません。アプリケーションには、DNS-ALGから返されたIPv6アドレスが「実際の」IPv6アドレスではなく、翻訳されたIPv4アドレスであることを知る方法はありません。したがって、アプリケーションは、宛先とのエンドツーエンドのIPv6接続があると信じるように導かれる場合があります。その結果、アプリケーションはNAT-PTによってサポートされていないIPv6固有のオプションを使用する場合があります。この問題は、セクション4.2で説明されている問題とセクション5の議論に密接に関連しています。
Some applications propagate information records retrieved from DNS to other applications. The published semantics of DNS imply that the results will be consistent to any user for the duration of the attached lifetime. RR records translated by NAT-PT violate these semantics because the retrieved addresses are only usable for communications through the translating NAT-PT.
一部のアプリケーションは、DNSから他のアプリケーションに取得された情報レコードを伝播します。DNSの公開されたセマンティクスは、結果が添付の寿命の期間中、任意のユーザーに一貫していることを意味します。NAT-PTによって翻訳されたRRレコードは、取得したアドレスが翻訳されたNAT-PTを介した通信のみで使用できるため、これらのセマンティクスに違反します。
Applications that pass on retrieved DNS records to other applications will generally assume that they can rely on the passed on addresses to be usable by the receiving application. This may not be the case if the receiving application is on another node, especially if it is not in the domain served by the NAT-PT that generated the translation.
取得したDNSレコードを他のアプリケーションに渡すアプリケーションは、一般に、受信アプリケーションによって使用できるように渡されたアドレスに頼ることができると仮定します。これは、受信アプリケーションが別のノード上にある場合、特に翻訳を生成したNAT-PTが提供するドメインにない場合はそうではありません。
Some applications running on dual-stack nodes may wish to query the IPv4 address of a destination. If the resulting A query passes through the NAT-PT DNS-ALG, the DNS-ALG will translate the response inappropriately into a AAAA record using a translated address. This happens because the DNS-ALG specified in [RFC2766] operates statelessly and hence has no memory of the IPv6 query that induced the A request on the IPv4 side. The default action is to translate the response.
デュアルスタックノードで実行されている一部のアプリケーションでは、宛先のIPv4アドレスを照会する場合があります。結果のクエリがNAT-PT DNS-ALGを通過する場合、DNS-ALGは、翻訳されたアドレスを使用して応答をAAAAレコードに不適切に変換します。これは、[RFC2766]で指定されたDNS-ALGがステートレスに動作し、IPv4側のA要求を誘導するIPv6クエリのメモリがないために発生します。デフォルトのアクションは、応答を変換することです。
The specification of NAT-PT could be modified to maintain a minimal state about queries passed through the DNS-ALG, and hence to respond correctly to A queries as well as AAAA queries.
NAT-PTの仕様は、DNS-ALGを通過したクエリに関する最小限の状態を維持するために変更できます。
Many IPv6 nodes, especially in multihomed situations but also in single homed deployments, can expect to have multiple global addresses. The same may be true for multihomed IPv4 nodes. Responses to DNS queries for these nodes will normally contain all these addresses. Since the DNS-ALG in the NAT-PT has no knowledge which of the addresses can or will be used by the application issuing the query, it is obliged to translate all of them.
多くのIPv6ノードは、特にマルチホームの状況では、単一の家庭用展開でも、複数のグローバルアドレスがあると予想できます。マルチホームのIPv4ノードにも同じことが言えます。これらのノードのDNSクエリへの応答には、通常、これらすべてのアドレスが含まれます。NAT-PTのDNS-Algには、クエリを発行するアプリケーションで使用できる、または使用できるアドレスのどれが知らないため、それらすべてを翻訳する義務があります。
This could be a significant drain on resources in both basic NAT-PT and NAPT-PT, as bindings will have to be created for each address.
これは、基本的なNAT-PTとNAPT-PTの両方のリソースの大幅な排出である可能性があります。これは、各アドレスに対してバインディングを作成する必要があるためです。
When using SCTP in a multihomed network, the problem is exacerbated if multiple NAT-PTs translate multiple addresses. Also, it is not clear that SCTP will actually look up all the destination IP addresses via DNS, so that bindings may not be in place when packets arrive.
マルチホームネットワークでSCTPを使用する場合、複数のNAT-PTSが複数のアドレスを翻訳する場合、問題は悪化します。また、SCTPが実際にDNSを介してすべての宛先IPアドレスを検索することは明らかではないため、パケットが到着したときにバインディングが整っていない可能性があります。
Secure DNS (DNSSEC) [RFC4033] uses public key cryptographic signing to authenticate DNS responses. The DNS-ALG modifies DNS query responses traversing the NAT-PT in both directions, which would invalidate the signatures as (partially) described in Section 7.5 of [RFC2766].
Secure DNS（DNSSEC）[RFC4033]は、公開キー暗号署名を使用してDNS応答を認証します。DNS-ALGは、[RFC2766]のセクション7.5で説明されているように（部分的に）署名を無効にするDNSクエリ応答を両方向に移動するDNSクエリ応答を変更します。
Workarounds have been proposed, such as making the DNS-ALG behave like a secure DNS server. This would need to be done separately for both the IPv6 and IPv4 domains. This is operationally very complex and there is a risk that the server could be mistaken for a conventional DNS server. The NAT-PT specification would have to be altered to implement any such workaround.
DNS-Algを安全なDNSサーバーのように動作させるなど、回避策が提案されています。これは、IPv6ドメインとIPv4ドメインの両方に対して個別に行う必要があります。これは動作的に非常に複雑であり、サーバーが従来のDNSサーバーと間違えられる可能性があるというリスクがあります。このような回避策を実装するには、NAT-PT仕様を変更する必要があります。
Hence, DNSSEC is not deployable in domains that use NAT-PT as currently specified. Widespread deployment of NAT-PT would become a serious obstacle to the large scale deployment of DNSSEC.
したがって、DNSSECは、現在指定されているNAT-PTを使用するドメインに展開できません。NAT-PTの広範な展開は、DNSSECの大規模な展開に対する深刻な障害となるでしょう。
One of the major design goals for IPv6 is to restore the end-to-end transparency of the Internet. Therefore, because IPv6 may be expected to remove the need for NATs and similar impediments to transparency, developers creating applications to work with IPv6 may be tempted to assume that the complex expedients that might have been needed to make the application work in a 'NATted' IPv4 environment are not required.
IPv6の主要な設計目標の1つは、インターネットのエンドツーエンドの透明性を回復することです。したがって、IPv6はNATの必要性と透明性に対する同様の障害を排除することが期待される可能性があるため、IPv6で動作するためのアプリケーションを作成する開発者は、アプリケーションを「NATTED」で機能させるために必要な複雑な手段が必要だった可能性があると仮定するように誘惑される場合があります。IPv4環境は必要ありません。
Consequently, some classes of applications (e.g., peer-to-peer) that would need special measures to manage NAT traversal, including special encapsulations, attention to binding lifetime, and provision of keepalives, may build in assumptions on whether IPv6 is being used or not. Developers would also like to exploit additional capabilities of IPv6 not available in IPv4.
その結果、特別なカプセル、拘束寿命への注意、Keepaliveの提供など、NATトラバーサルを管理するための特別な手段が必要ないくつかのクラスのアプリケーション（例：ピアツーピア）は、IPv6が使用されているかどうかについての仮定で構築される可能性があります。いいえ。また、開発者は、IPv4で使用できないIPv6の追加機能を活用したいと考えています。
NAT-PT as specified in [RFC2766] is intended to work autonomously and be transparent to applications. Therefore, there is no way for application developers to discover that a path contains a NAT-PT.
[RFC2766]で指定されているNAT-PTは、自律的に動作し、アプリケーションに透明性を持つことを目的としています。したがって、アプリケーション開発者がパスにNAT-PTが含まれていることを発見する方法はありません。
If NAT-PT is deployed, applications that have assumed a NAT-free IPv6 environment may break when the traffic passes through a NAT-PT. This is bad enough, but requiring developers to include special capabilities to work around what is supposed to be a temporary transition 'aid' is even worse. Finally, deployment of NAT-PT is likely to inhibit the development and use of additional IPv6 capabilities enabled by the flexible extension header system in IPv6 packets.
NAT-PTが展開されている場合、NATのないIPv6環境を想定しているアプリケーションは、トラフィックがNAT-PTを通過すると壊れる可能性があります。これは十分に悪いことですが、開発者が一時的な移行「援助」と思われるものを回避するための特別な機能を含めることを要求することはさらに悪いことです。最後に、NAT-PTの展開は、IPv6パケットの柔軟な拡張ヘッダーシステムによって有効な追加のIPv6機能の開発と使用を阻害する可能性があります。
Some of these deleterious effects could possibly be alleviated if applications could discover the presence of NAT-PT boxes on paths in use, allowing the applications to take steps to workaround the problems. However, requiring applications to incorporate extra code to workaround problems with a transition aid still seems to be a very bad idea: the behavior of the application in native IPv6 and NAT-PT environments would be likely to be significantly different.
これらの有害な効果のいくつかは、アプリケーションが使用中のパス上のNAT-PTボックスの存在を発見し、アプリケーションが問題を回避するための措置を講じることができる場合、おそらく緩和される可能性があります。ただし、遷移援助で回避策に追加のコードを組み込むためにアプリケーションを要求することは、依然として非常に悪い考えのようです。ネイティブIPv6およびNAT-PT環境でのアプリケーションの動作は、大きく異なる可能性があります。
This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections: o Section 2.1 discusses how IPsec AH (transport and tunnel mode) and IPsec ESP transport mode are broken by NAT-PT (when IPsec UDP encapsulation is not used [RFC3498]) and authentication and encryption are generally incompatible with NAT-PT.
このドキュメントは、NAT-PT [RFC2766]仕様に関連するセキュリティ問題を要約しています。セキュリティの問題については、さまざまなセクションで説明します。Oセクション2.1では、IPSEC AH（輸送およびトンネルモード）とIPSEC ESP輸送モードがNAT-PTによってどのように壊れるかについて説明します（IPSEC UDPカプセル化が使用されない場合[RFC3498]）、および認証と暗号化は一般的にNAT-PTと互換性がありません。
o Section 2.5 discusses possible fragmentation related security attacks on NAT-PT.
o セクション2.5では、NAT-PTに対する断片化に関連する可能性のあるセキュリティ攻撃について説明します。
o Section 2.8 discusses security issues related to multicast addresses and NAT-PT.
o セクション2.8では、マルチキャストアドレスとNAT-PTに関連するセキュリティの問題について説明します。
o Section 3.3 highlights that NAT-PT is an enticing nexus for security attacks.
o セクション3.3は、NAT-PTがセキュリティ攻撃の魅力的なネクサスであることを強調しています。
o Section 3.4 discusses possible NAT-PT DoS attacks on both memory and address/port pools.
o セクション3.4では、メモリプールとアドレス/ポートプールの両方に対するNAT-PT DOS攻撃の可能性について説明します。
o Section 4.5 discusses why NAT-PT is incompatible with DNSSEC [RFC4033] and how deployment of NAT-PT may inhibit deployment of DNSSEC.
o セクション4.5では、NAT-PTがDNSSEC [RFC4033]と互換性がある理由と、NAT-PTの展開がDNSSECの展開をどのように阻害するかについて説明します。
This document has discussed a number of significant issues with NAT-PT as defined in [RFC2766]. From a deployment perspective, 3GPP networks are currently the only 'standardised' scenario where NAT-PT is envisaged as a potential mechanism to allow communication between an IPv6-only host and an IPv4-only host as discussed in the 3GPP IPv6 transition analysis [RFC4215]. But RFC 4215 recommends that the generic form of NAT-PT should not be used and that modified forms should only be used under strict conditions. Moreover, it documents a number of caveats and security issues specific to 3GPP. In addition, NAT-PT has seen some limited usage for other purposes.
このドキュメントでは、[RFC2766]で定義されているNAT-PTに関する多くの重要な問題について説明しています。展開の観点から、3GPPネットワークは現在、3GPP IPv6遷移分析[RFC42155で説明されているように、IPv6のみのホストとIPv4のみのホスト間の通信を可能にする潜在的なメカニズムとしてNAT-PTが想定される唯一の「標準化された」シナリオです。]。ただし、RFC 4215は、NAT-PTの一般的な形式を使用しないでください。また、修正されたフォームは厳密な条件下でのみ使用することを推奨しています。さらに、3GPPに固有の多くの警告とセキュリティの問題を文書化します。さらに、NAT-PTは、他の目的のためにいくつかの限られた使用法を見てきました。
Although some of the issues identified with NAT-PT appear to have solutions, many of the solutions proposed require significant alterations to the existing specification and would likely increase operational complexity. Even if these solutions were applied, we have shown that NAT-PT still has significant, irresolvable issues and appears to have limited applicability. The potential constraints on the development of IPv6 applications described in Section 5 are particularly undesirable. It appears that alternatives to NAT-PT exist to cover the circumstances where NAT-PT has been suggested as a solution, such as the use of application proxies in 3GPP scenarios [RFC4215]
NAT-PTで特定された問題のいくつかは解決策を持っているように見えますが、提案されているソリューションの多くは、既存の仕様に大幅な変更を必要とし、運用上の複雑さを高める可能性があります。これらのソリューションが適用されたとしても、Nat-PTは依然として重要な、解決可能な問題を抱えており、適用性が限られているように見えることを示しました。セクション5で説明されているIPv6アプリケーションの開発に対する潜在的な制約は、特に望ましくありません。NAT-PTの代替品は、3GPPシナリオでのアプリケーションプロキシの使用など、NAT-PTが解決策として提案されている状況をカバーするために存在するようです[RFC4215]
However, it is clear that in some circumstances an IPv6-IPv4 protocol translation solution may be a useful transitional solution, particularly in more constrained situations where the translator is not required to deal with traffic for a wide variety of protocols that are not determined in advance. Therefore, it is possible that a more limited form of NAT-PT could be defined for use in specific situations.
ただし、状況によっては、IPv6-IPV4プロトコル翻訳ソリューションが、特に翻訳者が事前に決定されないさまざまなプロトコルのトラフィックに対処する必要がない、より制約された状況で、有用な移行ソリューションである可能性があることは明らかです。。したがって、特定の状況で使用するために、より限られた形式のNAT-PTを定義できる可能性があります。
Accordingly, we recommend that:
したがって、次のことをお勧めします。
o the IETF no longer suggest its usage as a general IPv4-IPv6 transition mechanism in the Internet, and
o IETFは、インターネットでの一般的なIPv4-IPv6遷移メカニズムとしての使用をもはや提案していません。
o RFC 2766 is moved to Historic status to limit the possibility of it being deployed inappropriately.
o RFC 2766は、不適切に展開される可能性を制限するために、歴史的なステータスに移動されます。
This work builds on a large body of existing work examining the issues and applicability of NAT-PT: the work of the authors of the documents referred to in Section 1 has been extremely useful in creating this document. Particular thanks are due to Pekka Savola for rapid and thorough review of the document.
この作業は、NAT-PTの問題と適用性を調べる既存の既存の作業の大部分に基づいています。セクション1で言及されているドキュメントの著者の作業は、このドキュメントの作成に非常に役立ちました。文書を迅速かつ徹底的にレビューしてくれたPekka Savolaに感謝します。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E。、「Stateless IP/ICMP翻訳アルゴリズム（SIIT）」、RFC 2765、2000年2月。
[RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000.
[RFC2766] Tsirtsis、G。およびP. Srisuresh、「ネットワークアドレス翻訳 - プロトコル翻訳（NAT -PT）」、RFC 2766、2000年2月。
[RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[RFC2663] Srisuresh、P。およびM. Holdrege、「IPネットワークアドレス翻訳者（NAT）用語と考慮事項」、RFC 2663、1999年8月。
[RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[RFC3027] Holdrege、M。およびP. Srisuresh、「IPネットワークアドレス翻訳者とのプロトコルの合併症」、RFC 3027、2001年1月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314] Wasserman、M。、「第三世代パートナーシッププロジェクト（3GPP）標準におけるIPv6の推奨」、RFC 3314、2002年9月。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、2003年2月。
[RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[RFC1035] Mockapetris、P。、「ドメイン名 - 実装と仕様」、STD 13、RFC 1035、1987年11月。
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, April 2006.
[RFC4294] Loughney、J。、「IPv6ノード要件」、RFC 4294、2006年4月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third Generation Partnership Project (3GPP) Networks", RFC 4215, October 2005.
[RFC4215] Wiljakka、J。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6遷移に関する分析」、RFC 4215、2005年10月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの紹介と要件」、RFC 4033、2005年3月。
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security Considerations for IP Fragment Filtering", RFC 1858, October 1995.
[RFC1858] Ziemba、G.、Reed、D。、およびP. Traina、「IPフラグメントフィルタリングのセキュリティ上の考慮事項」、RFC 1858、1995年10月。
[RFC3128] Miller, I., "Protection Against a Variant of the Tiny Fragment Attack (RFC 1858)", RFC 3128, June 2001.
[RFC3128] Miller、I。、「小さなフラグメント攻撃のバリアントに対する保護（RFC 1858）」、RFC 3128、2001年6月。
[RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., Zhang, L., and V. Paxson, "Stream Control Transmission Protocol", RFC 2960, October 2000.
[RFC2960] Stewart、R.、Xie、Q.、Morneault、K.、Sharp、C.、Schwarzbauer、H.、Taylor、T.、Rytina、I.、Kalla、M.、Zhang、L。、およびV。Paxson、「Stream Control Transmission Protocol」、RFC 2960、2000年10月。
[RFC3498] Kuhfeld, J., Johnson, J., and M. Thatcher, "Definitions of Managed Objects for Synchronous Optical Network (SONET) Linear Automatic Protection Switching (APS) Architectures", RFC 3498, March 2003.
[NATP-APP] Satapati, S., "NAT-PT Applicability", Work in Progress, October 2003.
[NATP-APP] Satapati、S。、「NAT-PTアプリケーション」、2003年10月、進行中の作業。
[DNS-ALG-ISSUES] Durand, A., "Issues with NAT-PT DNS ALG in RFC2766", Work in Progress, February 2002.
[DNS-Alg-Issues] Durand、A。、「RFC2766のNAT-PT DNS ALGの問題」、2002年2月、進行中の作業。
[DNS-ALG-SOL] Hallingby, P. and S. Satapati, "NAT-PT DNS ALG solutions", Work in Progress, July 2002.
[DNS-ALG-SOL] Hallingby、P。and S. Satapati、「Nat-PT DNS ALG Solutions」、2002年7月、進行中の作業。
[NATPT-MOB] Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", Work in Progress, July 2005.
[Natpt-Mob] Shin、M。およびJ. Lee、「Nat-PTのモビリティサポートの考慮事項」、2005年7月の作業。
[NATPT-SEC] Okazaki, S. and A. Desai, "NAT-PT Security Considerations", Work in Progress, June 2003.
[Natpt-Sec] Okazaki、S。およびA. Desai、「Nat-PTセキュリティ考慮事項」、2003年6月、進行中の作業。
[TRANS-ISSUES] Pol, R., Satapati, S., and S. Sivakumar, "Issues when translating between IPv4 and IPv6", Work in Progress, January 2003.
[Trans-Issues] Pol、R.、Satapati、S。、およびS. Sivakumar、「IPv4とIPv6の間で翻訳する際の問題」、2003年1月、進行中の作業。
[3GPP-TRANS] Malki, K., "IPv6-IPv4 Translation mechanism for SIP-based services in Third Generation Partnership Project (3GPP) Networks", Work in Progress, December 2003.
[3GPP-Trans] Malki、K。、「第3世代パートナーシッププロジェクト（3GPP）ネットワークにおけるSIPベースのサービスのIPv6-IPV4翻訳メカニズム」、2003年12月、進行中の作業。
[MTP] Tsuchiya, K., Higuchi, H., Sawada, S., and S. Nozaki, "An IPv6/IPv4 Multicast Translator based on IGMP/MLD Proxying (mtp)", Work in Progress, February 2003.
[MTP] Tsuchiya、K.、Higuchi、H.、Sawada、S。、およびS. nozaki、「IGMP/MLD Proxying（MTP）に基づくIPv6/IPv4マルチキャスト翻訳者」、2003年2月の作業。
[MCASTGW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in Progress, February 2003.
[mcastgw] venaas、S。、「IPv4 -IPv6マルチキャストゲートウェイ」、2003年2月の作業進行中。
[MUL-NATPT] Park, S., "Scalable mNAT-PT Solution", Work in Progress, May 2003.
Authors' Addresses
著者のアドレス
Cedric Aoun Energize Urnet Paris France
セドリック・アウンは、ウルネット・パリ・フランスを活性化します
EMail: ietf@energizeurnet.com
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Elwyn B. Davies Folly Consulting Soham、Cambs UK
Phone: +44 7889 488 335
EMail: elwynd@dial.pipex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。