RFC4966 日本語訳
4966 Reasons to Move the Network Address Translator - ProtocolTranslator (NAT-PT) to Historic Status. C. Aoun, E. Davies. July 2007. (Format: TXT=60284 bytes) (Obsoletes RFC2766) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Aoun
Request for Comments: 4966 Energize Urnet
Obsoletes: 2766 E. Davies
Category: Informational Folly Consulting
July 2007
Aounがコメントのために要求するワーキンググループC.をネットワークでつないでください: 4966は通電します。Urnetは以下を時代遅れにします。 2766年のE.デイヴィースカテゴリ: 2007年7月に相談する情報の愚かさ
Reasons to Move the Network Address Translator - Protocol Translator
(NAT-PT) to Historic Status
ネットワークアドレス変換機構を動かす理由--歴史的な状態へのプロトコル翻訳者(太平洋標準時のNAT)
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).
IETFが信じる著作権(C)(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.
このドキュメントはNetwork Address Translatorによって実装される特定のフォームのIPv6-IPv4プロトコル変換メカニズムの問題について議論します--RFC2766で定義されたプロトコルTranslator(太平洋標準時のNAT)。 汎用の変遷メカニズムがもう望ましくないので、これらの問題は十分重大なそんなに推薦しているRFC2766です、そして、このドキュメントはIETFがProposed StandardからHistoric状態までRFC2766に分類し直すはずであることを勧めます。
Aoun & Davies Informational [Page 1] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[1ページ]のRFC4966NATは2007年7月に分析を発行します。
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 DNS-ALG. . . . . . . . . . . . . . . . 7 2.1に関係ない問題。 IPアドレス. . . . . . . 7 2.2を埋め込むプロトコルの問題。 太平洋標準時のNAPTリダイレクション問題. . . . . . . . . . . . . . . . 8 2.3。 状態を縛る太平洋標準時のNATが.82.4を腐食します。 両立しない意味論. . . . 9 2.5を通した情報の損失。 太平洋標準時のNATと断片化. . . . . . . . . . . . . . . . . 10 2.6。 SCTPとマルチホーミング. . . . . . . 11 2.7との太平洋標準時のNAT相互作用。 MIPv6. . . . . . 12 2.8のためのプロキシ通信員ノードとしての太平洋標準時のNAT。 太平洋標準時のNATとマルチキャスト. . . . . . . . . . . . . . . . . . . 12 3。 DNS-ALG. . . . . . . . . . . 13 3.1の使用で悪化させられた問題。 太平洋標準時のNAT.133.2によって含意されたネットワーク形態規制。 スケーラビリティと失敗の単一のポイントは.143.3に関係があります。 アドレス固執. . . . . . . . . 15 3.4の不足の問題。 DoSはメモリとアドレス/ポートプール. . . . . . . 16 4で攻撃します。 問題は直接DNS-ALG. . . . . . . . . . 16 4.1の使用に関連しました。 Dual-スタックEnd-ホスト.164.2があるCommunicatingであるときにはSelection Issuesを扱ってください。 翻訳されたRRの非グローバルな正当性は.184.3を記録します。 質問. . . 19 4.4への応答の不適当な翻訳。 DNS-ALGとマルチ扱われたノード. . . . . . . . . . . . 19 4.5。 DNSセキュリティ能力. . 19 5の展開の制限。 IPv6アプリケーション開発. . . . . . . . . . . . 20 6のときに、影響を与えてください。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 20 7。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 21 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 22 9。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 22 9.1。 引用規格. . . . . . . . . . . . . . . . . . . 22 9.2。 有益な参照. . . . . . . . . . . . . . . . . . 23
Aoun & Davies Informational [Page 2] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[2ページ]のRFC4966NATは2007年7月に分析を発行します。
1. Introduction
1. 序論
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.
Network Address Translator--プロトコルTranslator(太平洋標準時のNAT)ドキュメント[RFC2766]はIPv4を支えるだけであるノードがIPv6を支えるだけであるノードとコミュニケートするのを許容するように設計された1セットのネットワーク層変換メカニズムを定義します、インターネットでのIPv6の使用への変遷の間。
[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、およびNetwork Address Port Translatorを指定します--プロトコルTranslator(太平洋標準時のNAPT)。(また、不十分なIPv4アドレスの、より大きい経済を考慮して、そのTranslatorは輸送識別子を翻訳します)。 プロトコル変換は、[RFC2765]で定義されたStateless IP/ICMP Translation Algorithm(SIIT)を使用することで実行されます。 以下の議論では、資格がなくて、議論は基本的な太平洋標準時のナットと太平洋標準時のNAPTの両方に適用されます。そこでは、「太平洋標準時のNAT」という期間が使用されています。 ポイントが基本的なアドレスだけ翻訳者に適用されると、「基本的な太平洋標準時のNAT」は使用されるでしょう。
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の問題を提起しました。 このドキュメントは、これらの問題をまとめて、他のいくつかの問題に伝統的なIPv4 NATsから及んだことに注意して、ほかの場所で議論していないいくつかの追加設定を特定するでしょう。 問題への提案された解決は言及されます、そして、仕様への変化のどんな結果として起こる必要性も特定されます。
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には、NATは進行中の能力と考えられますが、それがグローバルにユニークなIPv4アドレスの限られた有用性の周りで働くのに必要であり、IPv6のための変遷メカニズムとして異なった状態がいます。 そういうものとして、IPv6アプリケーションの開発を抑制するべきでないか、太平洋標準時のNATは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を推薦するのが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の改訂されて、ことによると制限されたバージョンが適当なソリューションであるかもしれないシナリオがまだあるかもしれません。 それに従って、このドキュメントは、IETFがProposed StandardからHistoric状態までRFC2766に分類し直すはずであることを勧めます。
Aoun & Davies Informational [Page 3] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[3ページ]のRFC4966NATは2007年7月に分析を発行します。
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に関連する以下のドキュメントがこのドキュメントを作成している間、再検討されています:
o Network Address Translation - Protocol Translation (NAT-PT)
[RFC2766]
o ネットワーク・アドレス翻訳--プロトコル変換(太平洋標準時のNAT)[RFC2766]
o Stateless IP/ICMP Translation Algorithm (SIIT) [RFC2765]
o 状態がないIP/ICMP変換アルゴリズム(SIIT)[RFC2765]
o NAT-PT Applicability Statement [NATP-APP]
o 太平洋標準時のNAT適用性証明[NATP-装置]
o Issues with NAT-PT DNS ALG (Application Layer Gateway) in RFC 2766
[DNS-ALG-ISSUES]
o RFC2766の太平洋標準時のNAT DNS ALG(応用層ゲートウェイ)の問題[DNS-ALG-問題]
o NAT-PT DNS ALG Solutions [DNS-ALG-SOL]
o 太平洋標準時のNAT DNS ALGソリューション[DNS-ALG-ソ]
o NAT-PT Security Considerations [NATPT-SEC]
o 太平洋標準時のNATセキュリティ問題[NATPT-SEC]
o Issues when Translating between IPv4 and IPv6 [TRANS-ISSUES]
o IPv4とIPv6の間でいつTranslatingを発行するか。[移-問題]
o IPv6-IPv4 Translation Mechanism for SIP-Based Services in Third
Generation Partnership Project (3GPP) Networks [3GPP-TRANS]
o 第三世代パートナーシッププロジェクト(3GPP)ネットワークにおける一口ベースのサービスのためのIPv6-IPv4変換メカニズム[3GPP、-、移-、]
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におけるモバイルIPサポートのための問題[NATPT-暴徒]
o An IPv6-IPv4 Multicast Translator based on Internet Group
Management Protocol / Multicast Listener Discovery (IGMP/MLD)
Proxying (mtp) [MTP]
o インターネットGroup Managementプロトコル/マルチキャストListenerディスカバリー(IGMP/MLD)Proxying(mtp)に基づくIPv6-IPv4 Multicast Translator[MTP]
o An IPv4-IPv6 Multicast Gateway [MCASTGW]
o IPv4-IPv6マルチキャストゲートウェイ[MCASTGW]
o Scalable mNAT-PT Solution [MUL-NATPT]
o スケーラブルな太平洋標準時のmNATソリューション[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.
問題の議論を含むドキュメントの大部分がRFCsになりそうにないドキュメントであるので、問題は引用規格の必要性を避けるためにここへまとめられます。
Some additional issues can be inferred from corresponding issues known to exist in 'traditional' IPv4 NATs. The following documents are relevant:
'伝統的な'IPv4 NATsに存在するのが知られている対応する問題からいくつかの追加設定を推論できます。 以下のドキュメントは関連しています:
Aoun & Davies Informational [Page 4] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[4ページ]のRFC4966NATは2007年7月に分析を発行します。
o Protocol Complications with the IP Network Address Translator
[RFC3027]
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(本書ではDNS-ALGと呼ばれる)のためのApplication Layerゲートウェイ(ALG)が仕様の不可欠の、そして、義務的な部分であるかどうかあります。 あいまいさは主に適用性部(セクション8)の最初のセクションから起こります。(部は太平洋標準時のNATの'簡単な'使用が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との相互作用から起こるので、これは重要です。 しかしながら、[RFC2766]の詳細検査は'簡単な'ケースが解決されていなくて、DNS-ALGが不在のときどうしたらアドレス変換の情報をホストに渡すことができたかが不明瞭であることを示します。 したがって、このドキュメントは、DNS-ALGが太平洋標準時のNATの不可欠の部分であると仮定します。 それに従って、全体の仕様のための問題であると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への代替手段として発生する場合、すべてのIPv6-IPv4翻訳者に関連しているジェネリック問題は覚えておかれるべきです。
Issues raised with IPv6-IPv4 translators in general and NAT-PT in particular can be categorized as follows:
以下の通り一般に、IPv6-IPv4翻訳者と共に提起された問題と特に太平洋標準時のNATを分類できます:
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が複数のIPv6ホストのために翻訳している状況における特定のトランスポート層プロトコルの上で築き上げられないプロトコルのための再直接のトラフィックへの無能。
* Requirement for applications to use keepalive mechanisms to
workaround connectivity issues caused by premature NAT-PT state
timeout.
* アプリケーションが時期尚早な太平洋標準時のNAT州のタイムアウトによって引き起こされた回避策接続性問題にkeepaliveメカニズムを使用するという要件。
Aoun & Davies Informational [Page 5] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[5ページ]のRFC4966NATは2007年7月に分析を発行します。
* 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翻訳者で追加状態、そして/または、パケット再建に必要です。
* 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が通信員ノードのためのプロキシとして務めるのが必要です。
* NAT-PT not being able to handle multicast traffic.
* マルチキャストトラフィックを扱うことができない太平洋標準時のNAT。
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 [RFC2766]で定義されるようにDNS-ALGの使用から生じている、したがって太平洋標準時のNATに特定の問題:
* 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.
* Aへの応答の不適当な翻訳はIPv6からノードについて質問します。
Aoun & Davies Informational [Page 6] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[6ページ]のRFC4966NATは2007年7月に分析を発行します。
* 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はIPv6のさらなる開発へのアプリケーション開発者のために太平洋標準時のNATを配布する結果と太平洋標準時のNAT(または、どんなフォームの一般に、配布しているIPv6-IPv4翻訳者も)の長期効果を調べます。
The terminology used in this document is defined in [RFC2663], [RFC2766], and [RFC3314].
本書では使用される用語は[RFC2663]、[RFC2766]、および[RFC3314]で定義されます。
2. Issues Unrelated to an DNS-ALG
2. DNS-ALGに関係ない問題
2.1. Issues with Protocols Embedding IP Addresses
2.1. IPアドレスを埋め込むプロトコルの問題
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 NATs([RFC2663]と[RFC3027]のセクション8を見る)への作業によって、数値IPアドレスをそれらのペイロードに埋め込むプロトコルの多人数のクラスが、NATsを終えることができませんし、アシスタントとしての特定のALGsがアドレスに沿ってペイロードを翻訳して、翻訳を移植するのを必要とすることができないのが、よく知られています。 同じセットのプロトコルは太平洋標準時のNATを通り抜けることができません。 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.
また、NATとの認証と暗号化に関連して、[RFC2663]のセクション2と3で提起された問題も太平洋標準時のNATに適切です。
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設備がそれぞれの関連プロトコルのための論理を含んでいるのを必要とします。 彼らの足並みをそろえるためにALGsの絶え間なくて連携しているアップデートを必要として、これらのプロトコルの大部分は絶え間なく発展しています。
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が関連プロトコルの1つのcolocated 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
可能な回避策は、認証、そして/または、暗号化を提供するのに使用されるセキュリティ協会へのパーティーであるので太平洋標準時のNATを当てにします。 太平洋標準時のNATはその時、暗号を意識しているでしょう。
Aoun & Davies Informational [Page 7] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[7ページ]のRFC4966NATは2007年7月に分析を発行します。
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.
アルゴリズムとキーは以前はよくトラフィックを保証していました。 次に、それは、パケットを変更して、再機密保護するかもしれません。 これは、確かに、ネットワーク操作を複雑にして、追加ポイントのセキュリティの脆弱性を提供するでしょう。
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カプセル化が使用されていない場合、交通機関では、太平洋標準時のNATでセキュリティ協会を終えないで、IPsec[RFC3498]、輸送にIPsec AH(認証Header)を使用するトラフィック、トンネルモード、およびIPsecに関して、超能力(Securityが有効搭載量であるとカプセル化する)は太平洋標準時のNATを通して運ぶことができません、それらの暗号の保全保護の用法のため。
A related issue with DNS security is discussed in Section 4.5.
セクション4.5でDNSセキュリティの関連する問題について議論します。
2.2. NAPT-PT Redirection Issues
2.2. 太平洋標準時のNAPTリダイレクション問題
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がそれの1つが実際にことであるRSVPとNATsに特定の問題について論ずる、 より多くのジェネリック問題、すべてに関しては、翻訳者を移植してください。 数人の終わりホストが単一の太平洋標準時のNAPT箱を使用しているとき、何も太平洋標準時のNAPTが正しい結合を特定するのに使用するものがないので、トランスポート層ポートナンバーと同様の逆多重化能力を持っていないプロトコルは太平洋標準時のNAPT(そして、いかなる他のポート翻訳者も)を終えることができないかもしれません。
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.
輸送ポートが目に見えないところで(代替のデマルチプレクサとしてSecurity Parameter Index(SPI)を使用するのは可能であるかもしれませんが)問題感情IPsecのこのタイプはパケットを暗号化しました、そして、RSVPなどのプロトコルはTCPやUDPのように議定書を作ります。(RSVPは標準のトランスポート層を使用するより直接IPデータグラムでむしろ運ばれます)。 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).
逆多重化問題を解決するのにいくつかの臨時の回避策を使用できました、これらのソリューションがどんなに多くの場合何処にも記録されないでも(非決定論的で望ましくない振舞いに通じることができました)(例えば、そのような回避策はしばしば特定のネットワークtopologiesなどを仮定します、正しく機能するように; 仮定が展開で迎えられないなら、回避策は予想されるように働かないかもしれません)。
This issue is closely related to the fragmentation issue described in Section 2.5.
この問題は密接にセクション2.5で説明された断片化問題に関連します。
2.3. NAT-PT Binding State Decay
2.3. 太平洋標準時のNATの拘束力がある州の腐敗
NAT-PT will generally use dynamically created bindings to reduce the need for IPv4 addresses both for basic NAT-PT and NAPT-PT. Both
一般に、太平洋標準時のNATは、基本的な太平洋標準時のNATと太平洋標準時のNAPTのためのIPv4アドレスの必要性を減少させるのにダイナミックに作成された結合を使用するでしょう。 両方
Aoun & Davies Informational [Page 8] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[8ページ]のRFC4966NATは2007年7月に分析を発行します。
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と太平洋標準時のNAPTはアドレスを管理するのに軟性国家メカニズムを使用します、そして、太平洋標準時のNAPTの場合では、ポートプールはダイナミックに作成されたアドレス結合に使用されます。 これで、クライアントが、結合はもう必要でないとそれとなくか明らかに合図する必要でない、すべてのタイプの太平洋標準時のNAT箱が自主的に作動します。 どのような場合でも、軟性国家タイムアウトがなければ、ネットワークとアプリケーション非信頼性は漏出に必然的に通じるでしょう、結局アドレスかポートプール疲労困憊を引き起こして。
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の半面からもう片方にパケットを送らなければなりません(方向は太平洋標準時のNAT仕様で指定されません)。 パケットを全く適切な方向に送らないと、太平洋標準時のNAT結合をリフレッシュしないでしょう、そして、アプリケーション接続は失意になるでしょう。 したがって、すべてのアプリケーションが、長い活動していない期間、レガシーシステムには、可能でないかもしれないkeepaliveメカニズムを組み込むことによって彼らの太平洋標準時のNAT結合を維持する必要があります。
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]はタイムアウトを選ぶ方法を結合に指定しません。 伝統的なNATsのために[RFC2663]で議論するように、適当な値を選択するのは、発見的教授法の問題です、そして、アプリケーション期待で調整するのは不可能であるかもしれません。
2.4. Loss of Information through Incompatible Semantics
2.4. 両立しない意味論を通した情報の損失
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は[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
o [NATP-APP]のセクション2.2で説明されるように、同等物が全くいくつかのICMP(v4)メッセージのためのIPv6にありません、他のもの(著しく'パラメタProblem'メッセージ)には、意味論は同等ではありませんが。 そのようなメッセージに関する翻訳は情報の損失を出すかもしれません。 しかしながら、エラーメッセージが任意のパケットでというよりむしろ太平洋標準時のNATによって翻訳されたパケットに関連するので、この問題はそれほど厳しくないかもしれません。 太平洋標準時のNATがそうなら
Aoun & Davies Informational [Page 9] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[9ページ]のRFC4966NATは2007年7月に分析を発行します。
functioning correctly, there is, for example, no reason why IPv6
packets with unusual extension headers or options should be
generated.
正しく機能して、例えば、珍しい拡張ヘッダーかオプションがある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.
関連する件はDifferentiated Services Code Point(DSCP)の伝播に関係があります。 パケットを翻訳するとき、太平洋標準時のNATとSIITは単にDSCP分野をコピーします。 それに従って、IPv4とIPv6ドメインには同じコード・ポイント同等なPer-ホップBehaviorsがなければならないに違いない、さもなければ、ドメインの間のDSCPを翻訳するために、代替の手段は適所にあるに違いありません。
2.5. NAT-PT and Fragmentation
2.5. 太平洋標準時のNATと断片化
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]で言及されるように、純真なポート翻訳者はパケット断片を翻訳できません、1番目を除いて、断片化しているパケットから、その後の断片がポートナンバー情報を含んでいないので。
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を横断するどんなトラフィックのためにも断片化を許すことができないことを意味します。 1つの試みられた回避策がパケットのすべての断片が太平洋標準時のNAPTを通過するまで最初の断片から得られた状態を維持する太平洋標準時のNAPT情報を必要とします。 断片misorderingが後の断片の後の太平洋標準時のNAPTに現れる最初の断片に通じるかもしれないので、これは完全解ではありません。 その結果、太平洋標準時のNAPTには、1日以前受け取られた断片を翻訳するのに必要である情報がないでしょう。
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は、輸送ポートナンバーを含まない脆い最初の断片を受けないように検査される必要があります。 そのようなパケットが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箱も横断するとき、追加関心は起こります。 [RFC2766]で説明されるように、太平洋標準時のNATは翻訳されたIPv6パケットに必要であるチェックサムについて計算できるように、全体のパケットを再建しなければなりません。 これはパケットへの重要な遅れをもたらすことができます、特にそれがトランスミッションの前にIPv6側で再断片化されなければならないなら。
Aoun & Davies Informational [Page 10] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[10ページ]のRFC4966NATは2007年7月に分析を発行します。
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箱がunchecksummed IPv4 UDPパケットのために、それらがそうしなければならない同じようにすべての入って来る断片化しているパケット(IPv4とIPv6方向からの)を組み立て直すなら、これは第1の問題への解決でしょうに。 潜在的遅れ問題は別として、出発しているパケットが再断片化されなければならないなら、リソース費用は無視できないでしょう。 どのような場合でも、断片化は、太平洋標準時のNATが余分なメモリーとCPUリソースを消費することを意味するでしょう、太平洋標準時のNATをよりスケーラブルでなくさえして(セクション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箱の中のパケット再アセンブリは様々な断片関連のセキュリティー攻撃の可能性を開けます。 これらの或るものはIPv4のために特定された攻撃に類似しています。 特定では、潜在的に再建バッファを積みすぎて、多量のCPUリソースを消費するだろう最後の終わっている断片なしで多くの小さい破片を送ることに基づいた関心はDoS攻撃です。
2.6. NAT-PT Interaction with SCTP and Multihoming
2.6. SCTPとマルチホーミングとの太平洋標準時のNAT相互作用
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プロトコル(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.
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.
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.
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.
Aoun & Davies Informational [Page 11] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 11] RFC 4966 NAT-PT Issues Analysis July 2007
SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1.
SCTP running through NAT-PT in a multihomed environment is also incompatible with IPsec as described in Section 2.1.
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6
2.7. NAT-PT as a Proxy Correspondent Node for MIPv6
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.
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.
This can be resolved in two ways:
This can be resolved in two ways:
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 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 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 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.
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.
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.
2.8. NAT-PT and Multicast
2.8. NAT-PT and Multicast
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] 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.
Aoun & Davies Informational [Page 12] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 12] RFC 4966 NAT-PT Issues Analysis July 2007
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.
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.
[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] 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.
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.
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.
3. Issues Exacerbated by the Use of DNS-ALG
3. Issues Exacerbated by the Use of DNS-ALG
3.1. Network Topology Constraints Implied by NAT-PT
3.1. Network Topology Constraints Implied by 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.
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.
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.
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.
These constraints are described in more detail in [DNS-ALG-ISSUES].
These constraints are described in more detail in [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] proposes a solution for flows initiated from the IPv6 domain, but it appears that this solution still has issues.
Aoun & Davies Informational [Page 13] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 13] RFC 4966 NAT-PT Issues Analysis July 2007
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
3.2. Scalability and Single Point of Failure Concerns
3.2. Scalability and Single Point of Failure Concerns
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
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
Aoun & Davies Informational [Page 14] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 14] RFC 4966 NAT-PT Issues Analysis July 2007
point of failure in the network. The addition of the DNS-ALG in NAT-PT further increases the scalability concerns.
point of failure in the network. The addition of the DNS-ALG in NAT-PT further increases the scalability concerns.
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].
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].
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.
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.
3.3. Issues with Lack of Address Persistence
3.3. Issues with Lack of Address Persistence
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.
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.
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.
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.
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.
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.
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.
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.
Aoun & Davies Informational [Page 15] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 15] RFC 4966 NAT-PT Issues Analysis July 2007
3.4. DoS Attacks on Memory and Address/Port Pools
3.4. DoS Attacks on Memory and Address/Port Pools
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).
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).
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.
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.
[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] 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.
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.
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. Issues Directly Related to Use of DNS-ALG
4. Issues Directly Related to Use of DNS-ALG
4.1. Address Selection Issues when Communicating with Dual-Stack End-
Hosts
4.1. Address Selection Issues when Communicating with Dual-Stack End- Hosts
[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] 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.
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
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
Aoun & Davies Informational [Page 16] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 16] RFC 4966 NAT-PT Issues Analysis July 2007
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.
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.
[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] 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:
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 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:
* 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.
* 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.
* 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.
* 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.
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 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.
There is, however, still an issue with the proposed solution:
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 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.
Aoun & Davies Informational [Page 17] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 17] RFC 4966 NAT-PT Issues Analysis July 2007
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).
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).
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.
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.
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.
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.
4.2. Non-Global Validity of Translated RR Records
4.2. Non-Global Validity of Translated RR Records
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.
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.
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.
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.
Aoun & Davies Informational [Page 18] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 18] RFC 4966 NAT-PT Issues Analysis July 2007
4.3. Inappropriate Translation of Responses to A Queries
4.3. Inappropriate Translation of Responses to A Queries
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.
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.
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.
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.
4.4. DNS-ALG and Multi-Addressed Nodes
4.4. DNS-ALG and Multi-Addressed Nodes
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.
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.
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.
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.
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.
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.
4.5. Limitations on Deployment of DNS Security Capabilities
4.5. Limitations on Deployment of DNS Security Capabilities
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] 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].
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.
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.
Aoun & Davies Informational [Page 19] RFC 4966 NAT-PT Issues Analysis July 2007
Aoun & Davies Informational [Page 19] RFC 4966 NAT-PT Issues Analysis July 2007
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.
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.
5. Impact on IPv6 Application Development
5. Impact on IPv6 Application Development
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
6. Security Considerations
6. Security Considerations
This document summarizes security issues related to the NAT-PT [RFC2766] specification. Security issues are discussed in various sections:
このドキュメントは太平洋標準時のNAT[RFC2766]仕様に関連する安全保障問題をまとめます。 様々なセクションで安全保障問題について議論します:
Aoun & Davies Informational [Page 20] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[20ページ]のRFC4966NATは2007年7月に分析を発行します。
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.
o セクション2.1はIPsec AH(輸送とトンネルモード)とIPsec超能力交通機関が太平洋標準時のNATによってどう壊されるかを(IPsec UDPカプセル化がいつでないかが[RFC3498]を使用しました)論じます、そして、一般に、認証と暗号化は太平洋標準時のNATと両立しないです。
o Section 2.5 discusses possible fragmentation related security
attacks on NAT-PT.
o セクション2.5は関連するセキュリティが太平洋標準時のNATで攻撃する可能な断片化について論じます。
o Section 2.8 discusses security issues related to multicast
addresses and NAT-PT.
o セクション2.8はマルチキャストアドレスに関連する安全保障問題と太平洋標準時のNATについて論じます。
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 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がなぜDNSSEC[RFC4033]と両立しないか、そして、太平洋標準時のNATの展開がどのようにDNSSECの展開を抑制するかもしれないかを論じます。
7. Conclusion
7. 結論
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の多くの重要な問題について議論しました。 展開見解から、現在、3GPPネットワークは太平洋標準時のNATが3GPP IPv6変遷分析[RFC4215]で議論するようにIPv6だけホストとIPv4だけホストとのコミュニケーションを許容するために潜在的メカニズムとして考えられる唯一の'標準化された'シナリオです。 しかし、RFC4215は太平洋標準時のNATのジェネリックフォームを使用するべきでなくて、厳しい条件のもとで変更されたフォームを使用するだけであるべきであることを勧めます。 そのうえ、それは多くの警告と3GPPに特定の安全保障問題を記録します。 さらに、太平洋標準時のNATは他の目的のために何らかの限られた用法を見ました。
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と同一視された問題のいくつかがソリューションを持っているように見えますが、提案されたソリューションの多くが、既存の仕様に重要な変更を必要として、おそらく操作上の複雑さを増強するでしょう。 これらのソリューションが適用されたとしても、私たちは太平洋標準時のNATがまだ重要で、分解できない問題を持っていて、適用性を制限したように見えるのを示しました。 セクション5で説明されたIPv6アプリケーションの開発の潜在的規制は特に望ましくありません。 太平洋標準時のNATへの代替手段が太平洋標準時のNATがソリューションとして示された事情をカバーするために存在するように見えます、3GPPシナリオにおけるアプリケーションプロキシの使用などのように[RFC4215]
However, it is clear that in some circumstances an IPv6-IPv4 protocol translation solution may be a useful transitional solution,
しかしながら、IPv6-IPv4プロトコル変換解決がいくつかの事情では、役に立つ過渡的なソリューションであることは明確です。
Aoun & Davies Informational [Page 21] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[21ページ]のRFC4966NATは2007年7月に分析を発行します。
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.
特に翻訳者があらかじめ決定しないさまざまなプロトコルのためのトラフィックに対処する必要はないより強制的な状況で。 したがって、特定の状況における使用のために、より限られたフォームの太平洋標準時のNATを定義できたのは可能です。
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 RFC2766は、それの可能性を制限するので、不適当に配布されながら、Historic状態に動かされます。
8. Acknowledgments
8. 承認
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の適用性に建てられます: セクション1で参照されたドキュメントの作者の仕事はこのドキュメントを作成する際に非常に役に立っています。 特定の感謝はドキュメントの急速で徹底的なレビューのためのペッカSavolaのためです。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[RFC2765] Nordmark, E., "Stateless IP/ICMP Translation
Algorithm (SIIT)", RFC 2765, February 2000.
[RFC2765] Nordmark、E.、「状態がないIP/ICMP変換アルゴリズム(SIIT)」、RFC2765、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)について議定書の中で述べてください」、RFC2766、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)用語と問題をネットワークでつなぐ」RFC2663、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ネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、2001年1月。
[RFC3314] Wasserman, M., "Recommendations for IPv6 in Third
Generation Partnership Project (3GPP) Standards",
RFC 3314, September 2002.
[RFC3314]ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、2002年9月。
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484,
February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
Aoun & Davies Informational [Page 22] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[22ページ]のRFC4966NATは2007年7月に分析を発行します。
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, November 1987.
[RFC1035]Mockapetris、P.、「ドメイン名--、実装と仕様、」、STD13、RFC1035、11月1987日
[RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294,
April 2006.
[RFC4294] Loughney、J.、「IPv6ノード要件」、RFC4294、2006年4月。
[RFC4215] Wiljakka, J., "Analysis on IPv6 Transition in Third
Generation Partnership Project (3GPP) Networks",
RFC 4215, October 2005.
[RFC4215] Wiljakka、J.、「第三世代パートナーシッププロジェクト(3GPP)ネットワークにおけるIPv6変遷の分析」、RFC4215、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.、ラーソン、M.、マッシー、D.、およびS.ローズ、「DNSセキュリティ序論と要件」(RFC4033)は2005を行進させます。
9.2. Informative References
9.2. 有益な参照
[RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security
Considerations for IP Fragment Filtering",
RFC 1858, October 1995.
1995年10月の[RFC1858]ZiembaとG.とリード、D.とP.Traina、「IP断片フィルタリングのためのセキュリティ問題」RFC1858。
[RFC3128] Miller, I., "Protection Against a Variant of the
Tiny Fragment Attack (RFC 1858)", RFC 3128,
June 2001.
[RFC3128]ミラー、I.、「小さい断片攻撃の異形に対する保護、(RFC1858)、」、RFC3128、6月2001日
[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.、K.の、そして、鋭いMorneault、C.、Schwarzbauer、H.、テイラー、T.、Rytina、I.、カッラ、M.、チャン、L.、および「ストリーム制御伝動プロトコル」、RFC2960(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.サッチャー、「同期式光通信網(Sonet)の直線的な自動保護の切り換え(APS)アーキテクチャのための管理オブジェクトの定義」、RFC3498(2003年3月)。
[NATP-APP] Satapati, S., "NAT-PT Applicability", Work
in Progress, October 2003.
S.、「太平洋標準時のNATの適用性」という[NATP-装置]Satapatiは進歩、2003年10月に働いています。
[DNS-ALG-ISSUES] Durand, A., "Issues with NAT-PT DNS ALG in
RFC2766", Work in Progress, February 2002.
「RFC2766の太平洋標準時のNAT DNS ALGの問題」という[DNS-ALG-問題]ジュランド、A.は進歩、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ソリューション」、Progress、2002年7月のWork。
[NATPT-MOB] Shin, M. and J. Lee, "Considerations for Mobility
Support in NAT-PT", Work in Progress, July 2005.
「太平洋標準時のNATにおける移動性サポートのための問題」という[NATPT-暴徒]の向こうずね、M.、およびJ.リーは進歩、2005年7月に動きます。
Aoun & Davies Informational [Page 23] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[23ページ]のRFC4966NATは2007年7月に分析を発行します。
[NATPT-SEC] Okazaki, S. and A. Desai, "NAT-PT Security
Considerations", Work in Progress, June 2003.
「太平洋標準時のNATセキュリティ問題」という[NATPT-SEC]の岡崎、S.、およびA.デセイは進歩、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.Sivakumarは「Progress、2003年1月にIPv4とIPv6"、Workの間で翻訳しながら、いつを発行します」。
[3GPP-TRANS] Malki, K., "IPv6-IPv4 Translation mechanism for
SIP-based services in Third Generation Partnership
Project (3GPP) Networks", Work in Progress,
December 2003.
「Third Generation Partnership Project(3GPP)でのSIPベースのサービスのためのIPv6-IPv4 Translationメカニズムはネットワークでつなぐ」[3GPP-TRANS]Malki、K.、Progress(2003年12月)のWork。
[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.野崎、「IPv6/IPv4 Multicast Translatorは(mtp)をIGMP/MLD Proxyingに基礎づけました」、ProgressのWork、2003年2月。
[MCASTGW] Venaas, S., "An IPv4 - IPv6 multicast gateway",
Work in Progress, February 2003.
[MCASTGW]Venaas、S.、「IPv4--、IPv6マルチキャストゲートウェイ、」、Progress、2月2003日のWork
[MUL-NATPT] Park, S., "Scalable mNAT-PT Solution", Work
in Progress, May 2003.
[MUL-NATPT]は駐車して、S.、「スケーラブルな太平洋標準時のmNATソリューション」が進歩、2003年5月に働いています。
Authors' Addresses
作者のアドレス
Cedric Aoun Energize Urnet Paris France
セドリックAounはUrnetパリフランスに通電します。
EMail: ietf@energizeurnet.com
メール: ietf@energizeurnet.com
Elwyn B. Davies Folly Consulting Soham, Cambs UK
Soham、Cambsイギリスに相談するElwyn B.デイヴィースの愚かさ
Phone: +44 7889 488 335 EMail: elwynd@dial.pipex.com
以下に電話をしてください。 +44 7889 488 335はメールされます: elwynd@dial.pipex.com
Aoun & Davies Informational [Page 24] RFC 4966 NAT-PT Issues Analysis July 2007
太平洋標準時のAounとデイヴィース情報[24ページ]のRFC4966NATは2007年7月に分析を発行します。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(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.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Aoun & Davies Informational [Page 25]
AounとデイヴィースInformationalです。[25ページ]
一覧
スポンサーリンク
