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）IETFトラスト（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を推奨することであることを十分に深刻であるRFC 2766.に定義されたプロトコル変換（NAT-PT） - この文書では、ネットワークアドレス変換によって実装のIPv6-IPv4のプロトコル変換機構の具体的な形態の問題について説明しもはや望ましい、と本書は、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を指定し、ネットワークポート翻訳住所 - また、乏しいIPv4アドレスの大きい経済を考慮して、トランスポート識別子を変換するプロトコル変換（NAPT-PT）、。プロトコル変換は、[RFC2765]で定義されたステートレスIP / ICMP翻訳アルゴリズム（SIIT）を用いて行われます。用語「NAT-PTは、」修飾されていない使用されている以下の議論では、議論は、基本的なNAT-PTとNAPT-PTの両方に適用されます。ポイントは基本アドレスのみの翻訳者に適用された場合、「基本的な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.
この文書では、一般的なようRFC2766]で説明したように、それは望ましくないNAT-PTを推薦する作り、技術的および運用の困難は、これらの問題、IPv6ネットワーク（第5節参照）の開発に特に将来の制約から生じた結論を描きます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
パケット翻訳の[RFC2766]フォームは、一般的に適用できないが、いくつかの状況では、IPv4のみをサポートできるノードがIPv6のみをサポートすることができるノードと通信する必要がある可能性があります。これはいくつかの種類の変換メカニズムを必要とします。これは、より良いアプリケーションレベルのプロキシまたはトランスポート・レイヤ・トランスレータによって行うことができるが、依然としてNAT-PTの改訂、おそらく制限バージョンは適切な溶液とすることができるシナリオが存在してもよいです。したがって、このドキュメントはIETFのに歴史的状態に標準化提案からRFC 2766を再分類すべきであることをお勧めします
avoid it from being used in inappropriate scenarios while any replacement is developed.
任意の交換が開発されている間、不適切なシナリオで使用されるのを避けます。
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]
RFC 2766でNAT-PT DNS ALG（アプリケーション層ゲートウェイ）の問題O [DNS-ALG-課題】
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 NATPTセキュリティの考慮事項[NATPT-SEC]
o Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
O問題IPv4とIPv6との間で変換するとき、[TRANS-課題】
o IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
第三世代パートナーシッププロジェクト（3GPP）ネットワーク[3GPP-TRANS]でSIPベースサービスのためのOのIPv6-IPv4の翻訳機構
o Analysis on IPv6 Transition in 3GPP Networks [RFC4215]
3GPPネットワークにおけるIPv6移行の解析[RFC4215] O
o Considerations for Mobile IP Support in NAT-PT [NATPT-MOB]
NATPTにおけるモバイルIPのサポートのためのOの考慮事項[NATPT-MOB]
o An IPv6-IPv4 Multicast Translator based on Internet Group Management Protocol / Multicast Listener Discovery (IGMP/MLD) Proxying (mtp) [MTP]
Oインターネットグループ管理プロトコルに基づいたIPv6-IPv4マルチキャスト翻訳/マルチキャストリスナ発見（IGMP / MLD）プロキシ（MTP）[MTP]
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の中に存在することが知られている対応の問題から推測することができます。以下の文書は関連しています：IPネットワークアドレス変換[RFC3027]とOプロトコルの合併症
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.
DNS用のアプリケーション層ゲートウェイ（ALG）は（本書ではDNS-ALGと呼ぶ）仕様の積分及び必須の部分であるかどうかについて[RFC2766]の一部の曖昧さがあります。曖昧さは、NAT-PTの「シンプル」の使用は、DNS-ALGの使用を避けることができることを意味すると思わ適用セクション（セクション8）、の最初のセクションから主に発生します。
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:
次のように一般、特にNAT-PTでのIPv6-IPv4のトランスレータで提起された問題を分類できます。
o Issues that are independent of the use of a DNS-ALG and are, therefore, applicable to any form of an IPv6-IPv4 translator:
DNS-ALGの使用とは無関係であり、したがって、IPv6をIPv4トランスレータの任意の形式に適用可能であるOの問題：
* 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.
*時期尚早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:
DNS-ALGの使用によって悪化し、また、そのため、IPv6をIPv4トランスレータの任意の形式に適用可能であるOの問題：
* 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]:
DNS-ALGの使用から生じると[RFC2766]で定義されるように、従って、NAT-PTに固有の問題（O）
* 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のセキュリティ機能の制限DNS-ALGを使用。
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節では、アプリケーション開発者およびIPv6の更なる発展にNAT-PT（または、一般的に展開されたIPv6-IPv4トランスレータの任意の形式）の長期的な効果のためにNAT-PTを展開の結果を調べます。
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.
よくどちらかの彼らのペイロードに数値のIPアドレスを埋め込むプロトコルの大きなクラスがNATを介して動作または変換するために、ヘルパーなどの特定のALGを必要としないことをIPv4のNATの上の仕事（[RFC2663]と[RFC3027]のセクション8を参照）から知られていますアドレスとポートの翻訳に沿ってペイロード。プロトコルの同じセットは、NAT-PTを通過することができません。 IPv6とIPv4アドレスの長さが異なるので、そのパケットは、同様にパケットの内容が変更されるように長さに問題が悪化します。 [RFC2766]はFTP ALGの記述の一部として結果を説明しています。同様の回避策は、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.
セクション2と3に提起された問題[RFC2663]、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.
ALGのスイートを実装する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は、関連するプロトコルのいずれかの共存ALGが含まれていると仮定すると、ALGは、埋め込まれた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.
UDPカプセル化は、IPsecの[RFC3498]、輸送およびトンネルモードのIPsec AH（認証ヘッダ）を使用してトラフィック、およびIPsec ESP（カプセル化セキュリティペイロード）のために使用されていない限り、トランスポートモードでは、終了せずにNAT-PTを介して行うことができません暗号完全性保護のその使用に起因するNAT-PTのセキュリティアソシエーション、。
A related issue with DNS security is discussed in Section 4.5.
DNSのセキュリティと関連する問題は、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.
[RFC3027]のセクション4.2は、実際には、すべてのポート翻訳者のためのより一般的な問題であり、そのうちの一つRSVPに特有の問題とNATのを、説明します。複数のエンドホストは、のために何もないので、多重分離機能と類似するトランスポート層のポート番号がNAPT-PT（および他のポートの翻訳者）を介して動作することができない可能性が持っていないプロトコルを単一NAPT-PTボックスを使用している場合NAPT-PTは、正しい結合を識別するために使用します。
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暗号化されたトランスポート・ポートが表示されていないパケット（代替デマルチプレクサとしてセキュリティパラメータインデックス（SPI）を使用することも可能かもしれませんが）、そのようなIPデータグラムに直接運ばれるRSVP、などのプロトコルに影響しますむしろ、そのようなTCPやUDPなどの標準的なトランスポート層プロトコルを使用するよりも。フロー識別子とトラフィック仕様のポートのフィールドはオプションであるため、RSVPの場合、IPv6ドメインへのIPv4ドメインから行くパケットは、必ずしも適切な分離フィールドを運ぶことはありません。
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は、一般的にIPv4の両方の基本的なNAT-PTとNAPT-PTのアドレスの必要性を減らすために、動的に作成されたバインディングを使用します。基本的な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拡張ヘッダは、IPv4での同等物を定義することができていないIPプロトコルスイートと新しいヘッダーに将来の改善のための柔軟性を提供します。実際には、このようなルーティングヘッダおよびモビリティ機能拡張など、いくつかの既存の拡張機能は、翻訳ではありません。
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.
これは、一般的には、断片化は、NAPT-PTを通過するすべてのトラフィックに対して許可することができない、ということを意味します。一つ未遂の回避策は、パケットのすべてのフラグメントが、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の現在の仕様は、重複断片の影響を最小限に抑えるために、フラグメント化不能（トランスポートのポート番号が含まれていない）の一部または（2）再構築ルールを運ぶ必要性を超えて（1）任意の最小パケットサイズを強制しません。したがって、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ボックスは、それらがunchecksummedたIPv4 UDPパケットのために持っているのと同じ方法で、すべての着信フラグメントパケットを（IPv4とIPv6の両方の方向から）再組み立てた場合、これが最初の問題に対する解決策であろう。発信パケットを再断片化しなければならない場合に、リソースのコストは、潜在的な遅延の問題から離れてかなりのだろう。いずれの場合も、断片化は、NAT-PTは、NAT-PTはさらに少ないスケーラブル作り、余分なメモリとCPUリソースを消費することを意味します（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のために特定の攻撃に類似しています。特に懸念されるの潜在的な復興・バッファをオーバーロードし、CPUリソースを大量に消費することになる、終端最後のフラグメントせずに小さな断片を大量に送ることに基づいてDoS攻撃です。
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.
ストリーム制御伝送プロトコル（SCTP）[RFC2960]はSIITが指定されてから標準化されたトランスポート・プロトコルです。 SCTPパケットを変換するときに同様の技術を使用することができ、SIITは、明示的にSCTPの翻訳をカバーしていませんが、SCTPはUDPとTCPが行うのと同じように、トランスポートのポート番号を使用しています。
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を介して実行すると、NAT-PT環境でSCTPを使用すると、効果的にSCTPのマルチホーミングの利点を無効にします。 「家」のそれぞれに関連する別のNAT-PTボックスとマルチホームネットワークを実行しているの結果は十分に検討されていないが、生じることになる1つの問題は、4.4節に記述されています。パケットペイロードの変更を処理するために - 実際にはトランスポート層ゲートウェイ - SCTPは、関連する「ALG」が必要になります。それはその状態が必要であることが判明した場合、状態はマルチホーム環境の中で、いくつかのNAT-PTボックスに分散して同期する必要があります。
SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1.
2.1節で説明したようにマルチホーム環境でNAT-PTを流れるSCTPはまた、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]で説明したように、IPv4ドメインにモバイルIPv6（MIPv6の）制御メッセージを伝播することは不可能です。 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追加の機能は、それがバインディングを持っているすべてのIPv4ノードのプロキシ通信相手ノードとして機能することを可能にするNAT-PTで実施することができます。この方式は、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.
IPv6の側のみのIPv4側にIGMPおよびMLDを含む基本的なメカニズムは、[MTP]「IGMP / MLDプロキシ（MTP）に基づいたIPv6-IPv4マルチキャスト翻訳」に記載されています。 「 - IPv6マルチキャストゲートウェイのIPv4」[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がマルチキャストアドレスのバインディングを作成するに偽装することができれば[NATPT-SEC]は乗法反射攻撃の可能性を識別する。この攻撃は、ルータが送信元アドレスフィールド内のマルチキャストアドレスを持つパケットを転送してはならないので、マウントすることは非常に難しいだろう。しかし、それは単純に実装さDNS-ALGは、[RFC2766]はこれらの応答内のアドレスの種類のチェックの必要性を言及していないので、偽装された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の反対側のフロー先と通信するために必要なマッピングアドレスを提供するために、NAT-PTでDNS-ALGに依存しています。 IPv4のドメインまたはIPv6ドメインで開始フローに使用されるかどうか、NAT-PTは、関連する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.
含意はNAT-PTボックスにもDNS-ALGがIPv6上で行われたすべてのDNS要求を検討することができるようにサイトのデフォルト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プレフィックス（[RFC2766]を参照）を使用してIPv6アドレスを介してアクセスし、IPv4のドメイン内のDNSサーバーの使用を必要とします。このサーバへのクエリは、必ずしもNAT-PTを通過します。デュアルスタックホストは、通常のIPv6アドレスを介してアクセスする別のDNSサーバを使用します。これは、ドメインのデフォルトのIPv6ゲートウェイにするNAT-PTボックスの必要性を取り除きます。
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サーバーを使用する必要があることを示唆しています。ネイティブIPv6アドレスを持つホストに関連する要求はまた、NAT-PT DNS-ALGを使用しますので、これはNAT-PTのリソースに高価です。
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のみのクライアントがIPv6経由でネイティブにアクセスするNAT-PTとサーバ（複数可）を介してアクセスサーバの両方を含む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のPREFIXを持つ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アドレスを持っているだろうことをお勧めします。ここでもIPv6ドメインから開始されたフローのために提起されたのと同じ問題が生じ、各クエリの正しいDNSサーバーを選択する決定的な方法はありません。
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の機能と操作の複雑さに追加されていない状態の同期化を、必要としています。そのような溶液は、[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-PTのにセキュリティ攻撃のための魅力的な標的となります。
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拡張プロトコル、またはセクションで説明したすべての問題を有している拡張ALG（いずれかを必要とします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は、アドレス（またはポート）プールからメモリリソース、ならびに（NAPT-PTが使用される場合、またはポート）アドレスを消費各々が、動的NATバインディングを作成することができます。アドレスとポートのプールに関連付けられている資源の枯渇につながる基本的なNATPTとNAPT-PTの[RFC2766]と[NATPT-SEC]サービスの可能性を議論拒否（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-課題】において同定攻撃は動的バインディングを作成するために、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.
理想的な緩和ソリューションは、プロトコル変換を必要とするエンドホストの認証と承認が行われるまで、動的に作成されたバインドを許可しないことであろう。これは、適切なセキュリティインフラストラクチャは、ネットワーク運用の複雑さを増大させ、認証と認可をサポートするための場所であることが必要であろう。
4.1. Address Selection Issues when Communicating with Dual-Stack End-Hosts
4.1. デュアルスタックエンドホストと通信するときの選択の問題に対処
[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-の問題]アドレス選択に関してNAT-PT DNS-ALGの問題について説明します。 [RFC2766]で指定されるように、DNS-ALGはAAAAのDNSクエリを行ったIPv6ホストに、二つの可能なソースからのAAAAリソースレコード（RR）を返します。
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 RRの中でネイティブのIPv6アドレス（複数可）と翻訳されたIPv4アドレス（複数可）の両方を返します。追加情報がなければ、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:
DNSのAAAAクエリがNAT-PT DNS-ALGを通過すると、O、NAT-PTは変わらないのIPv4ドメインのDNSサーバーにクエリを転送しますが、IPv4トランスポートを使用します。以下の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としてクエリ送信しません。
* 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アドレスを返す場合、ALGは、バインディングを作成し、それがIPv6ホストに送り返す対応するAAAAレコードを、合成します。
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応答の結果を転送します。したがって、一つのソースからのみのAAAA RRは代わりに[RFC2766]で指定されたように、2つの提供され、それはデュアルスタックのために最も適切なアドレスを含むか、または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 ALGを通過していないクエリの可能性が高いです。並行して2つのクエリを送信し、AAAAは、1つまたは複数のアドレスを返す場合、クエリの結果を無視することにより、応答時間を短縮することが可能です。しかし、第二は、まだ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 PREFIX [RFC2766]を使用し、それを低い選択優先度を割り当てることができるようになるであろう。このソリューションは、自動NAT-PTのPREFIXの設定と同様に、アドレス選択ポリシー内での統合が必要です。この自動設定を統合する最も簡単な方法は、（場合にホストまたは動的ホスト構成プロトコルベンダーオプションをサポートしていませんでしたし、NAT-PTのPREFIXオプションの標準化作業を避けるためのIPv6（DHCPv6の）サーバー用）コンフィギュレーションファイルのダウンロードを通じてだろう。このソリューションは、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の問題を解決します。アプリケーションは、IPv6アドレスがDNS-ALGは、「本当の」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を介した通信のためにのみ使用可能であるため、NAT-PTによって翻訳されたRRレコードがこれらのセマンティクスに違反します。
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の側に要求を誘導した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を通過したクエリに関する最小状態を維持するために、したがってクエリならびにAAAAクエリに正しく応答するように修正することができます。
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].
セキュアDNS（DNSSEC）[RFC4033]はDNS応答を認証するために、公開鍵暗号署名を使用しています。 DNS-ALGは、（部分的に）[RFC2766]のセクション7.5に記載されているように署名を無効になる両方向にNAT-PTを横断する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.
その結果、アプリケーションのいくつかのクラス（例えば、ピア・ツー・ピア）IPv6が使用されているかどうかについての前提に構築することができる、特殊なカプセル化、注意結合寿命に、キープアライブの提供など、NATトラバーサルを管理するために特別な措置を必要としますか、ではありません。開発者は、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-PTを通過するときに、NATのないIPv6環境を想定しているアプリケーションが破損する可能性があります。これは十分に悪いですが、一時的な転移「の援助」であると思われるものを回避するために特別な機能を含めるために、開発者が必要とすることはさらに悪くなります。最後に、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]仕様に関連したセキュリティ上の問題をまとめたもの。 （IPsecのUDPカプセル化は[RFC3498]を使用しない場合）にIPsec AH（トランスポートとトンネルモード）およびIPsec ESPトランスポートモードがNAT-PTによって破壊されている方法を第2.1節で説明Oおよび認証および暗号化は、一般にセキュリティ上の問題は、様々なセクションに記載されています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.
NAT-PTは、セキュリティ攻撃のための魅力的な結びつきであるO 3.3節のハイライト。
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ネットワークは、現在、NAT-PTは、IPv6のみのホストと3GPP IPv6移行解析で説明したようにIPv4のみのホスト[RFC4215との間の通信を可能にする潜在的なメカニズムとして想定されているだけ「標準化」のシナリオであります]。しかし、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アプリケーションの開発に潜在的な制約は特に望ましくありません。そのような3GPPシナリオにおいてアプリケーションプロキシを使用する[RFC4215]として、NAT-PTの代替は、NAT-PTは、解決策として提案されている状況をカバーするために存在することが明らか
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
IETFは、もはやインターネットで一般的なのIPv4-IPv6移行機構としてのその使用を示唆してO、及び
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節で言及した文書の作者の作品は、この文書を作成する上で極めて有用でした。特定のおかげで、文書の迅速かつ徹底的な見直しのためのペッカSavolaに起因するものです。
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmarkと、E.、 "ステートレス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.ホールドレッジ、 "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]ホールドレッジ、M.とP. Srisuresh、RFC 3027、2001年1月 "IPネットワークアドレス変換とプロトコル合併症"。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、RFC 3314、2002年9月、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための提言"。
[RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、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.、RFC 4215、2005年10月、 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるIPv6移行に関する分析"。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033]アレンズ、R.、Austeinと、R.、ラーソン、M.、マッシー、D.、およびS.ローズ、 "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.、リード、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]、RFC 3128、2001年6月・ミラー、I.、 "タイニーフラグメント攻撃（RFC 1858）のバリアントに対する保護"。
[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]スチュワート、R.、謝、Q.、Morneault、K.、シャープ、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カラ、M.、チャン、L.、およびV 。パクソン、 "ストリーム制御伝送プロトコル"、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.
[RFC3498] Kuhfeld、J.、ジョンソン、J.、およびM.サッチャー、RFC 3498、2003年3月 "同期光ネットワーク（SONET）リニア自動保護スイッチング（APS）アーキテクチャのための管理オブジェクトの定義"。
[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]デュラン、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.とS. Satapati、 "NAT-PT DNS ALGソリューション"、進歩、2002年7月に作業。
[NATPT-MOB] Shin, M. and J. Lee, "Considerations for Mobility Support in NAT-PT", Work in Progress, July 2005.
[NATPT-MOB]新、M.とJ.リー、 "NATPTにおけるモビリティサポートのための注意事項"、進歩、2005年7月に作業。
[NATPT-SEC] Okazaki, S. and A. Desai, "NAT-PT Security Considerations", Work in Progress, June 2003.
[NATPT-SEC]岡崎、S.およびA.デサイ、 "NATPTセキュリティに関する考慮事項"、進歩、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]ポル、R.、Satapati、S.、およびS.シバクマー、 "問題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.
、進歩、2003年12月の作業[3GPP-TRANS] Malki、K.、 "第三世代パートナーシッププロジェクト（3GPP）ネットワークにおけるSIPベースのサービスのIPv6-IPv4の翻訳機構"。
[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]土屋、K.、樋口、H.、沢田、S.、およびS.野崎、進歩、2003年2月ワーク "IGMP / MLDプロキシ（MTP）に基づいたIPv6 / IPv4マルチキャストトランスレータ"。
[MCASTGW] Venaas, S., "An IPv4 - IPv6 multicast gateway", Work in Progress, February 2003.
【MCASTGW] Venaas、S.は、 - 進歩、2003年2月、作業の "IPv4からIPv6ゲートウェイマルチキャスト"。
[MUL-NATPT] Park, S., "Scalable mNAT-PT Solution", Work in Progress, May 2003.
[MUL-NATPT]パーク、S.、 "スケーラブルmNAT-PTソリューション"、進歩、2003年5月での作業。
Authors' Addresses
著者のアドレス
Cedric Aoun Energize Urnet Paris France
セドリックアウンエネルギー充填Urnetパリフランス
EMail: ietf@energizeurnet.com
メールアドレス：ietf@energizeurnet.com
Elwyn B. Davies Folly Consulting Soham, Cambs UK
エルウィンB.デイヴィスフォリーコンサルティングソーハム、Cambsの英
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
電話：+44 7889 488 335 Eメール：elwynd@dial.pipex.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。