[要約] RFC 7051は、ホストがNAT64プレフィックスを学習するための解決策提案の分析を行ったものです。その目的は、IPv6ネットワークとIPv4ネットワークの間での通信を可能にするために、ホストがNAT64プレフィックスを効果的に学習できる方法を提供することです。
Internet Engineering Task Force (IETF) J. Korhonen, Ed.
Request for Comments: 7051 Broadcom
Category: Informational T. Savolainen, Ed.
ISSN: 2070-1721 Nokia
November 2013
Analysis of Solution Proposals for Hosts to Learn NAT64 Prefix
ホストがNAT64プレフィックスを学習するためのソリューション提案の分析
Abstract
概要
Hosts and applications may benefit from learning if an IPv6 address is synthesized and if NAT64 and DNS64 are present in a network. This document analyzes all proposed solutions (known at the time of writing) for communicating whether the synthesis is taking place, what address format was used, and what IPv6 prefix was used by the NAT64 and DNS64. These solutions enable both NAT64 avoidance and local IPv6 address synthesis. The document concludes by recommending the standardization of the approach based on heuristic discovery.
ホストとアプリケーションは、IPv6アドレスが合成されているかどうか、およびネットワークにNAT64とDNS64が存在するかどうかを学習することで恩恵を受ける場合があります。このドキュメントでは、合成が行われているかどうか、どのアドレス形式が使用されたか、NAT64およびDNS64でどのIPv6プレフィックスが使用されたかを伝達するために提案されたすべてのソリューション（執筆時点で既知）を分析します。これらのソリューションにより、NAT64回避とローカルIPv6アドレス合成の両方が可能になります。このドキュメントは、ヒューリスティックな発見に基づくアプローチの標準化を推奨することで締めくくられています。
Status of This Memo
本文書の状態
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントはInternet Standards Trackの仕様ではありません。情報提供を目的として公開されています。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。 IESGによって承認されたすべてのドキュメントが、あらゆるレベルのインターネット標準の候補になるわけではありません。 RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7051.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7051で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2013 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Issues ..........................................................5
4. Background ......................................................6
5. Proposed Solutions to Learn about Synthesis and
Network-Specific Prefix .........................................7
5.1. DNS Query for a Well-Known Name ............................7
5.1.1. Solution Description ................................7
5.1.2. Analysis and Discussion .............................7
5.1.3. Summary .............................................8
5.2. EDNS0 Option Indicating AAAA Record Synthesis and Format ...8
5.2.1. Solution Description ................................8
5.2.2. Analysis and Discussion .............................9
5.2.3. Summary ............................................10
5.3. EDNS0 Flags Indicating AAAA Record Synthesis and Format ...10
5.3.1. Solution Description ...............................10
5.3.2. Analysis and Discussion ............................10
5.3.3. Summary ............................................11
5.4. DNS Resource Record for IPv4-Embedded IPv6 Address ........11
5.4.1. Solution Description ...............................11
5.4.2. Analysis and Discussion ............................12
5.4.3. Summary ............................................12
5.5. Learning the IPv6 Prefix of a Network's NAT64 Using DNS ...13
5.5.1. Solution Description ...............................13
5.5.2. Analysis and Discussion ............................13
5.5.3. Summary ............................................14
5.6. Learning the IPv6 Prefix of a Network's NAT64
Using DHCPv6 ..............................................14
5.6.1. Solution Description ...............................14
5.6.2. Analysis and Discussion ............................15
5.6.3. Summary ............................................15
5.7. Learning the IPv6 Prefix of a Network's NAT64
Using Router ..............................................16
5.7.1. Solution Description ...............................16
5.7.2. Analysis and Discussion ............................16
5.7.3. Summary ............................................17
5.8. Using Application-Layer Protocols such as STUN ............17
5.8.1. Solution Description ...............................17
5.8.2. Analysis and Discussion ............................17
5.8.3. Summary ............................................19
5.9. Learning the IPv6 Prefix of a Network's NAT64
Using Access-Technology-Specific Methods ..................19
5.9.1. Solution Description ...............................19
5.9.2. Analysis and Discussion ............................19
5.9.3. Summary ............................................20
6. Conclusion .....................................................20
7. Security Considerations ........................................21
8. Contributors ...................................................22
9. Acknowledgements ...............................................22
10. References ....................................................22
10.1. Normative References .....................................22
10.2. Informative References ...................................23
Hosts and applications may benefit from learning if an IPv6 address is synthesized, which would mean that a NAT64 is used to reach the IPv4 network or Internet. There are two issues that can be addressed with solutions that allow hosts and applications to learn the Network-Specific Prefix (NSP) [RFC6052] used by the NAT64 [RFC6146] and the DNS64 [RFC6147] devices.
ホストとアプリケーションは、IPv6アドレスが合成されている場合、NAT64がIPv4ネットワークまたはインターネットに到達するために使用されているかどうかを学習することで恩恵を受ける可能性があります。ホストとアプリケーションがNAT64 [RFC6146]およびDNS64 [RFC6147]デバイスで使用されるネットワーク固有のプレフィックス（NSP）[RFC6052]を学習できるようにするソリューションで対処できる2つの問題があります。
The first issue is finding out whether a particular address is synthetic and therefore learning the presence of a NAT64. For example, a dual-stack host with IPv4 connectivity could use this information to bypass NAT64 and use native IPv4 transport for destinations that are reachable through IPv4. We will refer this as 'Issue #1' throughout the document.
最初の問題は、特定のアドレスが合成であるかどうかを調べ、NAT64の存在を知ることです。たとえば、IPv4接続のデュアルスタックホストは、この情報を使用してNAT64をバイパスし、IPv4経由で到達可能な宛先にネイティブIPv4トランスポートを使用できます。ドキュメント全体でこれを「問題＃1」と呼びます。
The second issue is finding out how to construct from an IPv4 address an IPv6 address that will be routable to/by the NAT64. This is useful when IPv4 literals can be found in the payload of some protocol or applications do not use DNS to resolve names to addresses but know the IPv4 address of the destination by some other means. We will refer this as 'Issue #2' throughout the document.
2番目の問題は、IPv4アドレスから、NAT64との間でルーティング可能なIPv6アドレスを構築する方法を見つけることです。これは、一部のプロトコルのペイロードでIPv4リテラルが見つかるか、アプリケーションがDNSを使用して名前をアドレスに解決しないが、他の手段で宛先のIPv4アドレスを知っている場合に役立ちます。ドキュメント全体でこれを「問題＃2」と呼びます。
Additionally, three other issues have to be considered by a solution addressing the first two issues: whether DNS is required ('Issue #3'), whether a solution supports changing NSP ('Issue #4'), and whether multiple NSPs are supported (either of the same or different length) for load-balancing purposes ('Issue #5').
さらに、最初の2つの問題に対処するソリューションでは、他に3つの問題を考慮する必要があります。DNSが必要か（「問題＃3」）、ソリューションがNSPの変更をサポートしているか（「問題＃4」）、および複数のNSPがサポートされているかどうか（同じまたは異なる長さのいずれか）負荷分散の目的（ 'Issue＃5'）。
This document analyzes all proposed solutions known at the time of writing for communicating if the synthesis is taking place, used address format, and the IPv6 prefix used by the NAT64 and DNS64. Based on the analysis we conclude whether the issue of learning the Network-Specific Prefix is worth solving and what would be the recommended solution(s) in that case.
このドキュメントでは、合成が行われている場合に通信するために作成時に知られていたすべての提案されたソリューションを分析し、アドレス形式を使用し、NAT64およびDNS64で使用されるIPv6プレフィックスを使用します。分析に基づいて、ネットワーク固有のプレフィックスの学習の問題が解決する価値があるかどうか、およびその場合に推奨される解決策は何かを結論付けます。
Address Synthesis
アドレス合成
Address synthesis is a mechanism, in the context of this document, where an IPv4 address is represented as an IPv6 address understood by a NAT64 device. The synthesized IPv6 address is formed by embedding an IPv4 address as-is into an IPv6 address prefixed with an NSP/WKP. It is assumed that the 'unused' suffix bits of the synthesized address are set to zero as described in Section 2.2 of [RFC6052].
アドレス合成は、このドキュメントのコンテキストでは、IPv4アドレスがNAT64デバイスによって理解されるIPv6アドレスとして表されるメカニズムです。合成されたIPv6アドレスは、IPv4アドレスをそのままNSP / WKPで始まるIPv6アドレスに埋め込むことによって形成されます。 [RFC6052]のセクション2.2で説明されているように、合成アドレスの「未使用」サフィックスビットはゼロに設定されていると想定されています。
DNS64
DNS64
DNS extensions for network address translation from IPv6 clients to IPv4 servers: A network entity that synthesizes IPv6 addresses and AAAA records out of IPv4 addresses and A records, hence making IPv4 namespaces visible in the IPv6 namespace. DNS64 uses NSP and/or WKP in the synthesis process.
IPv6クライアントからIPv4サーバーへのネットワークアドレス変換のためのDNS拡張機能：IPv4アドレスとAレコードからIPv6アドレスとAAAAレコードを合成するネットワークエンティティ。したがって、IPv4名前空間がIPv6名前空間に表示されます。 DNS64は、合成プロセスでNSPまたはWKP、あるいはその両方を使用します。
NAT64
NAT64
Network Address and protocol Translation mechanism for translating IPv6 packets to IPv4 packets and vice versa: A network entity that a host or an application may want to either avoid or utilize. IPv6 packets that hosts sent to addresses in the NSP and/or WKP are routed to NAT64.
IPv6パケットをIPv4パケットに、またはその逆に変換するためのネットワークアドレスおよびプロトコル変換メカニズム：ホストまたはアプリケーションが回避または利用したいネットワークエンティティ。ホストがNSPまたはWKP、あるいはその両方のアドレスに送信したIPv6パケットは、NAT64にルーティングされます。
NSP
NSP
Network-Specific Prefix: A prefix chosen by a network administrator for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace.
ネットワーク固有のプレフィックス：IPv6名前空間でIPv4アドレスを提示するためにNAT64 / DNS64のネットワーク管理者が選択したプレフィックス。
WKP
WKP
Well-Known Prefix: A prefix (64:ff9b::/96) chosen by IETF and configured by a network administrator for NAT64/DNS64 to present IPv4 addresses in the IPv6 namespace.
Well-Known Prefix：IETFによって選択され、ネットワーク管理者がNAT64 / DNS64に対してIPv6名前空間でIPv4アドレスを提示するように構成したプレフィックス（64：ff9b :: / 96）。
This document analyzes different solutions with a focus on the following five issues:
このドキュメントでは、次の5つの問題に焦点を当てて、さまざまなソリューションを分析します。
Issue #1
第1号
The problem of distinguishing between synthesized and real IPv6 addresses, which allows a host to learn the presence of a NAT64 in the network.
ホストがネットワーク内のNAT64の存在を学習できるようにする、合成されたIPv6アドレスと実際のIPv6アドレスを区別する問題。
Issue #2
第2号
The problem of learning the NSP used by the access network and needed for local IPv6 address synthesis.
アクセスネットワークで使用され、ローカルIPv6アドレス合成に必要なNSPを学習する際の問題。
Issue #3
第3号
The problem of learning the NSP or WKP used by the access network by a host not implementing DNS (hence, applications are unable to use DNS to learn the prefix).
DNSを実装していないホストがアクセスネットワークで使用するNSPまたはWKPを学習する問題（したがって、アプリケーションはDNSを使用してプレフィックスを学習できません）。
Issue #4
第4号
The problem of supporting changing NSP. The NSP learned by the host may become stale for multiple reasons. For example, the host might move to a new network that uses a different NSP, thus making the previously learned NSP stale. Also, the NSP used in the network may be changed due administrative reasons, thus again making the previously learned NSP stale.
NSPの変更をサポートする際の問題。ホストによって学習されたNSPは、いくつかの理由で古くなる可能性があります。たとえば、ホストが別のNSPを使用する新しいネットワークに移動し、以前に学習したNSPが古くなる可能性があります。また、ネットワークで使用されるNSPは管理上の理由により変更される可能性があり、以前に学習したNSPが古くなります。
Issue #5
第5号
The problem of supporting multiple NSPs. A network may be configured with multiple NSPs for address synthesis. For example, for load-balancing purposes, each NAT64 device in the same network could be assigned their own NSP. It should be noted that learning a single NSP is enough for an end host to successfully perform local IPv6 address synthesis, but to avoid NAT64, the end host needs to learn all NSPs used by the access network.
複数のNSPをサポートする際の問題。ネットワークは、アドレス合成のために複数のNSPで構成できます。たとえば、負荷分散の目的で、同じネットワーク内の各NAT64デバイスに独自のNSPを割り当てることができます。エンドホストがローカルIPv6アドレス合成を正常に実行するには、単一のNSPを学習するだけで十分ですが、NAT64を回避するには、エンドホストがアクセスネットワークで使用されるすべてのNSPを学習する必要があることに注意してください。
Certain applications, operating in protocol translation scenarios, can benefit from knowing the IPv6 prefix used by a local NAT64 of the attached access network. This applies to Scenario 1 ("IPv6 network to IPv4 Internet"), Scenario 5 ("An IPv6 network to an IPv4 network"), and Scenario 7 ("The IPv6 Internet to the IPv4 Internet") in the IPv4/IPv6 translation framework document [RFC6144]. Scenario 3 ("The IPv6 Internet to an IPv4 network") is not considered applicable herein as in that case, a NAT64 is located at the front of a remote IPv4 network, and a host in IPv6 Internet can benefit very little from learning the NSP IPv6 prefix used by the remote NAT64. The NAT64 prefix can be either a Network-Specific Prefix (NSP) or the Well-Known Prefix (WKP). Below is (an incomplete) list of various use cases where it is beneficial for a host or an application to know the presence of a NAT64 and the NSP/WKP:
プロトコル変換シナリオで動作する特定のアプリケーションは、接続されたアクセスネットワークのローカルNAT64によって使用されるIPv6プレフィックスを知ることから利益を得ることができます。これは、IPv4 / IPv6変換フレームワークのシナリオ1（「IPv6ネットワークからIPv4インターネットへ」）、シナリオ5（「IPv6ネットワークからIPv4ネットワークへ」）、およびシナリオ7（「IPv6インターネットからIPv4インターネットへ」）に適用されます。ドキュメント[RFC6144]。シナリオ3（「IPv6インターネットからIPv4ネットワークへ」）は、NAT64がリモートIPv4ネットワークの前面にあり、IPv6インターネットのホストがNSPを学習してもほとんどメリットがないため、ここでは適用可能とは見なされません。リモートNAT64で使用されるIPv6プレフィックス。 NAT64プレフィックスは、ネットワーク固有のプレフィックス（NSP）または既知のプレフィックス（WKP）のいずれかです。以下は、ホストまたはアプリケーションがNAT64とNSP / WKPの存在を知ることが有益であるさまざまな使用例の（不完全な）リストです。
o Host-based DNSSEC validation. As is documented in DNS64 [RFC6147], Section 5.5, Point 3, synthetic AAAA records cannot be successfully validated in a host. In order to utilize NAT64, a security-aware and validating host has to perform the DNS64 function locally, and hence, it has to be able to learn WKP or proper NSP.
o ホストベースのDNSSEC検証。 DNS64 [RFC6147]のセクション5.5、ポイント3に記載されているように、合成AAAAレコードはホストで正常に検証できません。 NAT64を利用するには、セキュリティを認識して検証するホストがDNS64機能をローカルで実行する必要があるため、WKPまたは適切なNSPを学習できる必要があります。
o Protocols that use IPv4 literals. In IPv6-only access, native IPv4 connections cannot be created. If a network has NAT64, it is possible to synthesize an IPv6 address by combining the IPv4 literal and the IPv6 prefix used by NAT64. The synthesized IPv6 address can then be used to create an IPv6 connection.
o IPv4リテラルを使用するプロトコル。 IPv6のみのアクセスでは、ネイティブIPv4接続を作成できません。ネットワークにNAT64がある場合、NAT64で使用されるIPv4リテラルとIPv6プレフィックスを組み合わせることにより、IPv6アドレスを合成できます。合成されたIPv6アドレスを使用して、IPv6接続を作成できます。
o Multicast translation [MCAST-TRANSLATOR] [V4V6MC-FRAMEWORK].
o マルチキャスト変換[MCAST-TRANSLATOR] [V4V6MC-FRAMEWORK]。
o URI schemes with host IPv4 address literals rather than domain names (e.g., http://192.0.2.1, ftp://192.0.2.1, imap://192.0.2.1, ipp://192.0.2.1). A host can synthesize an IPv6 address out of the literal in the URI and use IPv6 to create a connection through NAT64.
o ドメイン名ではなくホストIPv4アドレスリテラルを使用したURIスキーム（例：http：//192.0.2.1、ftp：//192.0.2.1、imap：//192.0.2.1、ipp：//192.0.2.1）。ホストは、URIのリテラルからIPv6アドレスを合成し、IPv6を使用してNAT64経由の接続を作成できます。
o Updating the host's [RFC6724] preference table to prefer native prefixes over translated prefixes. This is useful as applications are more likely able to traverse through NAT44 than NAT64.
o ホストの[RFC6724]設定テーブルを更新して、変換されたプレフィックスよりもネイティブプレフィックスを優先します。アプリケーションはNAT64よりもNAT44を通過する可能性が高いため、これは便利です。
DNS64 cannot serve applications that are not using DNS or that obtain referral as an IPv4 literal address. One example application is the Session Description Protocol (SDP) [RFC4566], as used by the Real Time Streaming Protocol (RTSP) [RFC2326] and the Session Initiation Protocol (SIP) [RFC3261]. Other example applications include web browsers, as IPv4 address literals are still encountered in web pages and URLs. Some of these applications could still work through NAT64, provided they were able to create locally valid IPv6 presentations of peers' IPv4 addresses.
DNS64は、DNSを使用していない、または紹介をIPv4リテラルアドレスとして取得するアプリケーションを処理できません。アプリケーションの1つの例は、リアルタイムストリーミングプロトコル（RTSP）[RFC2326]およびセッション開始プロトコル（SIP）[RFC3261]で使用されているセッション記述プロトコル（SDP）[RFC4566]です。他のサンプルアプリケーションには、WebページやURLでIPv4アドレスリテラルが引き続き検出されるため、Webブラウザーが含まれます。これらのアプリケーションの一部は、ピアのIPv4アドレスのローカルで有効なIPv6プレゼンテーションを作成できれば、NAT64でも機能します。
It is a known issue that passing IP address referrals often fails in today's Internet [REFERRAL-PS]. Synthesizing IPv6 addresses does not necessarily make the situation any better as the synthesized addresses utilizing NSP are not distinguishable from public IPv6 addresses for the referral receiver. However, the situation is not really any different from the current Internet as using public addresses does not really guarantee reachability (for example, due to firewalls). A node 'A' behind NAT64 may detect it is talking to a node 'B' through NAT64, in which case the node 'A' may want to avoid passing its IPv6 address as a referral to the node 'B'. The node 'B' on the IPv4 side of the NAT64 should not see the IPv6 address of a node 'A' from the IPv6 side of NAT64, and hence the node 'B' should not be able to pass IPv6 address referral to a node 'C'. Passing IPv4 presentation of the IPv6 address of the host 'A' to the node 'C' is bound to similar problems as passing a public IPv4 address of a host behind NAT44 as a referral. This analysis focuses on detecting NAT64 presence from the IPv6 side of NAT64.
今日のインターネット[REFERRAL-PS]でIPアドレスの参照を渡すと失敗することがよくあることは、既知の問題です。 IPv6アドレスを合成しても、NSPを使用して合成されたアドレスは、参照レシーバーのパブリックIPv6アドレスと区別できないため、必ずしも状況が良くなるわけではありません。ただし、パブリックアドレスを使用しても実際には到達可能性が保証されないため（ファイアウォールなどにより）、状況は現在のインターネットと実際には何も変わりません。 NAT64の背後にあるノード「A」は、NAT64を介してノード「B」と通信していることを検出する場合があります。その場合、ノード「A」は、ノード「B」への参照としてIPv6アドレスを渡さないようにすることができます。 NAT64のIPv4側のノード 'B'は、NAT64のIPv6側からノード 'A'のIPv6アドレスを認識できません。したがって、ノード 'B'は、ノードにIPv6アドレス参照を渡すことができません。 「C」。ホスト 'A'のIPv6アドレスのIPv4プレゼンテーションをノード 'C'に渡すと、参照としてNAT44の背後にあるホストのパブリックIPv4アドレスを渡す場合と同様の問題が発生します。この分析は、NAT64のIPv6側からのNAT64プレゼンスの検出に焦点を当てています。
5. Proposed Solutions to Learn about Synthesis and Network-Specific Prefix
5. 合成とネットワーク固有のプレフィックスについて学習するための提案されたソリューション
Section 3 of [RFC7050] describes a host behavior for discovering the presence of a DNS64 server and a NAT64 device, and heuristics for discovering the used NSP. A host requiring information for local IPv6 address synthesis or for NAT64 avoidance sends a DNS query for a AAAA record of a Well-Known IPv4-only Fully Qualified Domain Name (FQDN). If a host receives a negative reply, it knows that no DNS64 and NAT64 are in the network.
[RFC7050]のセクション3では、DNS64サーバーとNAT64デバイスの存在を発見するためのホストの動作と、使用されているNSPを発見するためのヒューリスティックについて説明します。ローカルIPv6アドレス合成またはNAT64回避の情報を必要とするホストは、既知のIPv4のみの完全修飾ドメイン名（FQDN）のAAAAレコードのDNSクエリを送信します。ホストが否定応答を受信した場合、ホストはネットワークにDNS64とNAT64がないことを認識しています。
If a host receives a AAAA reply, it knows the network must be utilizing IPv6 address synthesis. After receiving a synthesized AAAA resource record, the host may examine the received IPv6 address and use heuristics, such as "subtracting" the known IPv4 address out of synthesized IPv6 address, to find out the NSP.
ホストがAAAA応答を受信した場合、ホストはネットワークがIPv6アドレス合成を利用している必要があることを認識しています。合成されたAAAAリソースレコードを受信した後、ホストは受信したIPv6アドレスを調べ、合成されたIPv6アドレスから既知のIPv4アドレスを「減算」するなどのヒューリスティックを使用して、NSPを見つけることができます。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1 and #2.
+ 問題＃1および＃2を解決するために使用できます。
+ Solves Issue #4 via the lifetime of the DNS record.
+ DNSレコードの有効期間を通じて問題＃4を解決します。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response. Can find multiple address formats.
+ 複数の合成AAAAレコードが応答に含まれている場合、問題＃5を部分的に解決できます。複数のアドレス形式を見つけることができます。
+ Does not necessarily require any standards effort.
+ 必ずしも標準的な作業は必要ありません。
+ Does not require host stack or resolver changes. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.
+ ホストスタックやリゾルバーの変更は必要ありません。必要なすべてのロジックとヒューリスティックは、発生するアドレス合成について学習することに関心のあるアプリケーションに実装できます。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ このソリューションは、「レガシー」ホストおよびサーバーの観点からは下位互換性があります。
+ Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
+ 合成と使用されるNSPについて学習することに関心のあるホストまたはアプリケーションは、いつでも、たとえばホストが新しいネットワークに接続するたびに、積極的に「発見」を行うことができます。
+ Does not require explicit support from the network using NAT64.
+ NAT64を使用するネットワークからの明示的なサポートは必要ありません。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires hosting of a DNS resource record for the Well-Known Name.
- 既知の名前のDNSリソースレコードのホスティングが必要です。
- Does not provide a solution for Issue #3.
- 問題＃3の解決策は提供されません。
- This method is only able to find one NSP even if a network is utilizing multiple NSPs (Issue #5) (unless DNS64 includes multiple synthetic AAAA records in response).
- この方法では、ネットワークが複数のNSPを利用している場合でも（問題＃5）（DNS64に応答で複数の合成AAAAレコードが含まれていない限り）、1つのNSPしか見つけることができません。
This is the only approach that can be deployed without explicit support from the network or the host. This approach could also complement explicit methods and be used as a fallback approach when explicit methods are not supported by an access network.
これは、ネットワークまたはホストからの明示的なサポートなしで展開できる唯一のアプローチです。このアプローチは、明示的なメソッドを補完し、明示的なメソッドがアクセスネットワークでサポートされていない場合のフォールバックアプローチとしても使用できます。
[SYNTH-FLAG-2011] defined a new Extension Mechanisms for DNS (EDNS0) option [RFC2671] that contained 3 flag bits (called SY-bits). The EDNS0 option served as an implicit indication of the presence of a DNS64 server and NAT64 device. The EDNS0 option SY-bit values other than '000' and '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record.
[SYNTH-FLAG-2011]は、3つのフラグビット（SYビットと呼ばれる）を含むDNS（EDNS0）オプション[RFC2671]の新しい拡張メカニズムを定義しました。 EDNS0オプションは、DNS64サーバーとNAT64デバイスの存在を暗黙的に示します。 EDNS0オプションの「000」および「111」以外のSYビット値は、NSPプレフィックス長を明示的に伝えました。 DNS64サーバーのみが、合成されたAAAAリソースレコードにEDNS0オプションと必要なSYビットの組み合わせを挿入できました。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.
+ 問題＃1を解決するために使用でき、問題＃2を明示的に解決するように設計されています。
+ Solves Issue #4 via the lifetime of the DNS record.
+ DNSレコードの有効期間を通じて問題＃4を解決します。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use same format.
+ 複数の合成AAAAレコードが応答に含まれ、すべてが同じ形式を使用する場合、問題＃5を部分的に解決できます。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ このソリューションは、「レガシー」ホストおよびサーバーの観点からは下位互換性があります。
+ Even if the solution is bundled with DNS queries and responses, a standardization of a new DNS record type is not required; rather, just defining a new EDNS0 option is needed.
+ ソリューションがDNSクエリと応答にバンドルされている場合でも、新しいDNSレコードタイプの標準化は必要ありません。むしろ、新しいEDNS0オプションを定義するだけで十分です。
+ EDNS0 option implementation requires changes only to DNS64 servers.
+ EDNS0オプションの実装では、DNS64サーバーのみを変更する必要があります。
+ Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.
+ EDNS0オプションはDNS64サーバーによって応答に自動的に追加されるため、追加のプロビジョニングや管理は必要ありません。
+ Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.
+ EDNS0ロジックはDNS64サーバー内で処理できるため、グローバルDNSインフラストラクチャに対する追加のクエリは必要ありません。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires end hosts to support EDNS0 extension mechanisms [RFC6891].
- エンドホストがEDNS0拡張メカニズムをサポートする必要があります[RFC6891]。
- Requires host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.
- ホストリゾルバーの変更とホストリゾルバーAPIへのメカニズム/追加（またはフラグ、ヒントなど）を使用して、アドレスが合成されていること、およびNSPプレフィックス長とは何かをクエリアプリケーションに通知します。
- Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.
- 合成された応答にEDNS0オプションを含めるには、DNS64サーバーを変更する必要があります。
- Does not provide a solution for Issue #3.
- 問題＃3の解決策は提供されません。
- EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0- capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between.
-EDNS0フラグとオプションは通常、ホップバイホップのみであり、EDNS0対応のDNS64がエンドホストが最初に通信するDNSサーバーでない限り、これらのアプローチの適用範囲を厳しく制限します。オプションは、その間のすべてのDNSプロキシとサーバーを通じて存続します。
The solution based on the EDNS0 option works by extending the existing EDNS0 resource record. Although the solution has host resolver and DNS64 server impacts, the changes are limited to those entities (end host, applications) that are interested in learning the presence of NAT64 and the used NAT64 prefix. The provisioning and management overhead is minimal, if not non-existent, as the EDNS0 options are synthesized in a DNS64 server in a same manner as the synthesized AAAA resource records. Moreover, EDNS0 does not induce any load to DNS servers because no new RRType query is defined.
EDNS0オプションに基づくソリューションは、既存のEDNS0リソースレコードを拡張することで機能します。ソリューションにはホストリゾルバーとDNS64サーバーへの影響がありますが、変更は、NAT64の存在と使用されるNAT64プレフィックスの学習に関心のあるエンティティ（エンドホスト、アプリケーション）に限定されます。 EDNS0オプションは合成されたAAAAリソースレコードと同じ方法でDNS64サーバーで合成されるため、プロビジョニングと管理のオーバーヘッドは存在しなくても最小限です。さらに、新しいRRTypeクエリが定義されていないため、EDNS0はDNSサーバーに負荷をかけません。
[SYNTH-FLAG-2010] defined 3 new flag bits (called SY-bits) in the EDNS0 OPT [RFC2671] header that served as an implicit indication of the presence of a DNS64 server and NAT64 device. SY-bit values other than '000' or '111' explicitly told the NSP prefix length. Only the DNS64 server could insert the EDNS0 option and the required SY-bits combination into the synthesized AAAA resource record.
[SYNTH-FLAG-2010]は、DNS64サーバーとNAT64デバイスの存在を暗黙的に示すEDNS0 OPT [RFC2671]ヘッダーに3つの新しいフラグビット（SYビットと呼ばれる）を定義しました。 「000」または「111」以外のSYビット値は、NSPプレフィックス長を明示的に伝えました。 DNS64サーバーのみが、合成されたAAAAリソースレコードにEDNS0オプションと必要なSYビットの組み合わせを挿入できました。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issue #1 and is designed to explicitly solve Issue #2.
+ 問題＃1を解決するために使用でき、問題＃2を明示的に解決するように設計されています。
+ Solves Issue #4 via the lifetime of the DNS record.
+ DNSレコードの有効期間を通じて問題＃4を解決します。
+ Can partially solve Issue #5 if multiple synthetic AAAA records are included in the response and all use same format.
+ 複数の合成AAAAレコードが応答に含まれ、すべてが同じ形式を使用する場合、問題＃5を部分的に解決できます。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ このソリューションは、「レガシー」ホストおよびサーバーの観点からは下位互換性があります。
+ EDNS0 option implementation requires changes only to DNS64 servers.
+ EDNS0オプションの実装では、DNS64サーバーのみを変更する必要があります。
+ Does not require additional provisioning or management as the EDNS0 option is added automatically by the DNS64 server to the responses.
+ EDNS0オプションはDNS64サーバーによって応答に自動的に追加されるため、追加のプロビジョニングや管理は必要ありません。
+ Does not involve additional queries towards the global DNS infrastructure as EDNS0 logic can be handled within the DNS64 server.
+ EDNS0ロジックはDNS64サーバー内で処理できるため、グローバルDNSインフラストラクチャに対する追加のクエリは必要ありません。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires end hosts to support EDNS0 extension mechanisms [RFC6891].
- エンドホストがEDNS0拡張メカニズムをサポートする必要があります[RFC6891]。
- Consumes scarce flag bits from the EDNS0 OPT header.
- EDNS0 OPTヘッダーから希少なフラグビットを消費します。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length.
- ホストリゾルバーの変更と、ホストリゾルバーAPI（またはフラグ、ヒントなど）へのメカニズム/追加が必要です。アドレスが合成されていること、およびNSPプレフィックス長が何であるかをクエリアプリケーションに通知します。
- Requires a modification to DNS64 servers to include the EDNS0 option to the synthesized responses.
- 合成された応答にEDNS0オプションを含めるには、DNS64サーバーを変更する必要があります。
- Does not provide a solution for Issue #3.
- 問題＃3の解決策は提供されません。
- EDNS0 flags and options are typically hop-by-hop only, severely limiting the applicability of these approaches, unless the EDNS0- capable DNS64 is the first DNS server the end host talks to, as it is otherwise not possible to guarantee that the EDNS0 option survives through all DNS proxies and servers in between.
- EDNS0のフラグとオプションは通常、ホップバイホップのみであり、EDNS0対応のDNS64がエンドホストが最初に通信するDNSサーバーでない限り、これらのアプローチの適用性が大幅に制限されます。すべてのDNSプロキシとその間のサーバーを通じて存続します。
This option is included here for the sake of completeness. The consumption of three bits of the limited EDNS0 OPT space can be considered unfavorable and hence is unlikely to be accepted.
このオプションは、完全を期すためにここに含まれています。制限されたEDNS0 OPTスペースの3ビットの消費は、好ましくないと考えることができるため、受け入れられる可能性はほとんどありません。
[DNS-A64] proposed a new DNS resource record (A64) that would be a record dedicated to storing a single IPv4-embedded IPv6 address [RFC6052]. Use of a dedicated resource record would allow a host to distinguish between real IPv6 addresses and synthesized IPv6 addresses. The solution requires the host to send a query for an A64 record. A positive answer with an A64 record informs the requesting host that the resolved address is not a native address but an IPv4- embedded IPv6 address. This would ease the local policies to prefer direct communications (i.e., avoid using IPv4-embedded IPv6 addresses when a native IPv6 address or a native IPv4 address is available). Applications may be notified via new or modified API.
[DNS-A64]は、単一のIPv4埋め込みIPv6アドレス[RFC6052]の保存専用のレコードとなる新しいDNSリソースレコード（A64）を提案しました。専用リソースレコードを使用すると、ホストは実際のIPv6アドレスと合成されたIPv6アドレスを区別できます。このソリューションでは、ホストがA64レコードのクエリを送信する必要があります。 A64レコードの肯定応答は、解決されたアドレスがネイティブアドレスではなくIPv4組み込みIPv6アドレスであることを要求しているホストに通知します。これにより、ローカルポリシーが直接通信を優先するようになります（つまり、ネイティブIPv6アドレスまたはネイティブIPv4アドレスが使用可能な場合は、IPv4埋め込みIPv6アドレスの使用を避けます）。アプリケーションは、新しいAPIまたは変更されたAPIを介して通知される場合があります。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1 and #5.
+ 問題＃1および＃5を解決するために使用できます。
+ Solves Issue #4 via the lifetime of the DNS record.
+ DNSレコードの有効期間を通じて問題＃4を解決します。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ このソリューションは、「レガシー」ホストおよびサーバーの観点からは下位互換性があります。
+ Synthesized addresses can be used in authoritative DNS servers.
+ 合成されたアドレスは、信頼できるDNSサーバーで使用できます。
+ Maintains the reliability of the DNS model (i.e., a synthesized IPv6 address is presented as such and not as a native IPv6 address).
+ DNSモデルの信頼性を維持します（つまり、合成されたIPv6アドレスは、ネイティブIPv6アドレスとしてではなく、そのように提示されます）。
+ When both IPv4-converted and native IPv6 addresses are configured for the same QNAME, native addresses are preferred.
+ IPv4変換とネイティブIPv6アドレスの両方が同じQNAMEに構成されている場合、ネイティブアドレスが優先されます。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Does not address Issues #2 or #3 in any way.
- 問題＃2または＃3にはまったく対応していません。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized.
- ホストリゾルバAPIへのホストリゾルバの変更とメカニズム/追加（またはフラグ、ヒントなど）を使用して、アドレスが合成されていることをクエリアプリケーションに通知する必要があります。
- Requires standardization of a new DNS resource record type (A64) and the implementation of it in both resolvers and servers.
- 新しいDNSリソースレコードタイプ（A64）の標準化と、リゾルバーとサーバーの両方での実装が必要です。
- Requires a coordinated deployment between different flavors of DNS servers within the provider to work deterministically.
- 確定的に機能するには、プロバイダー内のさまざまな種類のDNSサーバー間での調整された展開が必要です。
- Additional load on the DNS servers (3 queries -- A64, AAAA, and A -- may be issued by a dual-stack host).
- DNSサーバーに追加の負荷（3つのクエリ-A64、AAAA、およびA-がデュアルスタックホストによって発行される場合があります）。
- Does not help to identify synthesized IPv6 addresses if the session does not involve any DNS queries.
- セッションにDNSクエリが含まれていない場合は、合成されたIPv6アドレスの識別に役立ちません。
While the proposed solution delivers explicit information about address synthesis taking place, solving the Issue #1, standardization of a new DNS record type might turn out to be too overwhelming a task as a solution for a temporary transition phase. Defining a new record type increases the load towards the DNS server as the host issues parallel A64, AAAA, and A queries.
提案されたソリューションは、発生しているアドレス合成に関する明確な情報を提供しますが、問題＃1を解決するために、新しいDNSレコードタイプの標準化は、一時的な移行フェーズのソリューションとしてタスクを圧倒しすぎる場合があります。新しいレコードタイプを定義すると、ホストが並列のA64、AAAA、およびAクエリを発行するため、DNSサーバーへの負荷が増加します。
[LEARN-PREFIX] proposed two DNS-based methods for discovering the presence of a DNS64 server and a NAT64 device. It also proposed a mechanism for discovering the used NSP.
[LEARN-PREFIX]は、DNS64サーバーとNAT64デバイスの存在を発見するための2つのDNSベースの方法を提案しました。また、使用されたNSPを発見するためのメカニズムも提案しました。
First, the document proposed that a host may learn the presence of a DNS64 server and a NAT64 device by receiving a TXT resource record with a well-known string (which the document proposes to be reserved by IANA) followed by the NAT64 unicast IPv6 address and the prefix length. The DNS64 server would add the TXT resource record into the DNS response.
まず、このドキュメントでは、ホストが既知の文字列（このドキュメントではIANAによって予約されることを提案している）を含むTXTリソースレコードと、それに続くNAT64ユニキャストIPv6アドレスを受信することで、DNS64サーバーとNAT64デバイスの存在を学習することを提案していますおよびプレフィックス長。 DNS64サーバーは、TXTリソースレコードをDNS応答に追加します。
Second, the document proposed specifying a new URI-Enabled NAPTR (U-NAPTR) [RFC4848] application to discover the NAT64's IPv6 prefix and length. The input domain name is exactly the same as would be used for a reverse DNS lookup, derived from the host's IPv6 in the ".ip6.arpa." tree. The host doing the U-NAPTR queries may need multiple queries until the host finds the provisioned domain name with the correct prefix length. The response to a successful U-NAPTR query contains the unicast IPv6 address and the prefix length of the NAT64 device.
次に、このドキュメントでは、NAT64のIPv6プレフィックスと長さを検出するために、新しいURI対応NAPTR（U-NAPTR）[RFC4848]アプリケーションを指定することを提案しました。入力ドメイン名は、「。ip6.arpa」内のホストのIPv6から派生した、逆DNSルックアップに使用されるものとまったく同じです。木。 U-NAPTRクエリを実行するホストは、ホストが正しいプレフィックス長でプロビジョニングされたドメイン名を見つけるまで、複数のクエリが必要になる場合があります。成功したU-NAPTRクエリへの応答には、ユニキャストIPv6アドレスとNAT64デバイスのプレフィックス長が含まれています。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1 and #2.
+ 問題＃1および＃2を解決するために使用できます。
+ Solves Issue #4 via the lifetime of the DNS record.
+ DNSレコードの有効期間を通じて問題＃4を解決します。
+ Does not require host stack or resolver changes if the required logic and heuristics are implemented in applications that are interested in learning about address synthesis taking place.
+ 必要なロジックとヒューリスティックが、発生しているアドレス合成について学習することに関心のあるアプリケーションに実装されている場合、ホストスタックやリゾルバーの変更は必要ありません。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires standardization of a Well-Known Name by IANA for the TXT resource record and/or standardization of a new U-NAPTR application.
- TXTリソースレコードのIANAによる既知の名前の標準化および/または新しいU-NAPTRアプリケーションの標準化が必要です。
- Requires a host resolver changes and mechanism/additions to the host resolver API (or flags, hints, etc.) to deliver a note to the querying application that the address is synthesized and what is the NSP prefix length. However, it is possible that the U-NAPTR application logic is completely implemented by the application itself as noted in the PROs list.
-アドレスが合成されていることとNSPプレフィックス長とは何かをクエリアプリケーションに通知するために、ホストリゾルバーの変更とホストリゾルバーAPIへのメカニズム/追加（またはフラグ、ヒントなど）が必要です。ただし、PROリストに記載されているように、U-NAPTRアプリケーションロジックがアプリケーション自体によって完全に実装されている可能性があります。
- The U-NAPTR prefix-learning method may entail multiple queries.
- U-NAPTRプレフィックス学習方式では、複数のクエリが必要になる場合があります。
- The U-NAPTR prefix-learning method requires provisioning of NSPs in the ".ip6.arpa." tree.
- U-NAPTRプレフィックス学習方式では、「。ip6.arpa」にNSPをプロビジョニングする必要があります。木。
- RFC5507 [RFC5507] specifically recommends against reusing TXT resource records to expand DNS.
- RFC5507 [RFC5507]は、TXTリソースレコードを再利用してDNSを拡張しないことを特に推奨しています。
- Requires configuration on the access network's DNS servers.
- アクセスネットワークのDNSサーバーでの構成が必要です。
- Does not provide a solution for Issue #3.
- 問題＃3の解決策は提供されません。
Note: If the TXT record includes multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注：TXTレコードに複数のNSPが含まれている場合、問題＃5も解決できますが、グループとしてのノードが異なるNSPを選択する場合にのみ、負荷分散がサポートされます。これは明確ではないため、この項目はまだPROまたはCONにリストされていません。
The implementation of this solution requires some changes to the applications and resolvers in a similar fashion as in solutions in Sections 5.2, 5.3, and 5.4. Unlike the other DNS-based approaches, the U-NAPTR-based solution also requires provisioning information into the ".ip6.arpa." tree, which is no longer entirely internal to the provider hosting the NAT64/DNS64 service.
このソリューションの実装では、セクション5.2、5.3、および5.4のソリューションと同様の方法で、アプリケーションとリゾルバーにいくつかの変更が必要です。他のDNSベースのアプローチとは異なり、U-NAPTRベースのソリューションでは、「。ip6.arpa」へのプロビジョニング情報も必要です。ツリーは、NAT64 / DNS64サービスをホストするプロバイダーの内部に完全に存在しなくなりました。
The iterative approach of learning the NAT64 prefix in an U-NAPTR-based solution may result in multiple DNS queries, which can be considered more complex and inefficient compared to other DNS-based solutions.
U-NAPTRベースのソリューションでNAT64プレフィックスを学習する反復的なアプローチでは、複数のDNSクエリが発生する可能性があり、他のDNSベースのソリューションと比較してより複雑で非効率的であると考えることができます。
Two individual IETF documents specified DHCPv6-based approaches.
2つの個別のIETFドキュメントがDHCPv6ベースのアプローチを指定しました。
[LEARN-PREFIX] described a new DHCPv6 [RFC3315] option (OPTION_AFT_PREFIX_DHCP) that would contain the IPv6 unicast prefix, IPv6 Any-Source Multicast (ASM) prefix, and IPv6 Source-Specific Multicast (SSM) prefix (and their lengths) for the NAT64.
[LEARN-PREFIX]は、IPv6ユニキャストプレフィックス、IPv6 Any-Source Multicast（ASM）プレフィックス、およびIPv6 Source-Specific Multicast（SSM）プレフィックス（およびその長さ）を含む新しいDHCPv6 [RFC3315]オプション（OPTION_AFT_PREFIX_DHCP）について説明しましたNAT64。
[DHCPV6-SHARED-ADDRESS] proposed a DHCPv6 option that could be used to communicate to a requesting host the prefix used for building IPv4-converted IPv6 addresses together with the format type and therefore also the used address synthesis algorithm. Provisioning the format type is required so as to be correctly handled by the NAT64-enabled devices deployed in a given domain.
[DHCPV6-SHARED-ADDRESS]は、IPv4変換されたIPv6アドレスの構築に使用されるプレフィックスとフォーマットタイプ、および使用されるアドレス合成アルゴリズムを要求ホストに通信するために使用できるDHCPv6オプションを提案しました。特定のドメインに展開されたNAT64対応デバイスで正しく処理されるように、フォーマットタイプのプロビジョニングが必要です。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1, #2, #3, and #4 via the lifetime of the DHCPv6 information.
+ DHCPv6情報のライフタイムを介して問題＃1、＃2、＃3、および＃4を解決するために使用できます。
+ Does not involve the DNS system. Therefore, applications that would not normally initiate any DNS queries can still learn the NAT64 prefix.
+ DNSシステムは含まれません。したがって、通常はDNSクエリを開始しないアプリケーションでも、NAT64プレフィックスを学習できます。
+ DHCPv6 is designed to provide various kinds of configuration information in a centrally managed fashion.
+ DHCPv6は、集中管理された方法でさまざまな種類の構成情報を提供するように設計されています。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Change of NSP requires change to the DHCPv6 configuration.
- NSPを変更するには、DHCPv6構成を変更する必要があります。
- Requires at least stateless DHCPv6 client on hosts.
- ホスト上に少なくともステートレスDHCPv6クライアントが必要です。
- Requires support on DHCPv6 clients, which is not trivial in all operating systems.
- DHCPv6クライアントのサポートが必要です。これは、すべてのオペレーティングシステムで簡単なことではありません。
- The DHCPv6-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- DHCPv6ベースのソリューションには、NAT64 / DNS64の展開の一部ではない、またはNAT64 / DNS64によって引き起こされる問題を認識していないネットワーク側ノードでの変更と管理が含まれます。
- A new DHCPv6 option is required along with the corresponding changes to both DHCPv6 clients and servers.
- DHCPv6クライアントとサーバーの両方に対する対応する変更とともに、新しいDHCPv6オプションが必要です。
Note: If DHCPv6 would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注：DHCPv6に複数のNSPが含まれる場合、問題＃5も解決できますが、グループとしてのノードが異なるNSPを選択する場合にのみ、負荷分散がサポートされます。これは明確ではないため、この項目はまだPROまたはCONにリストされていません。
The DHCPv6-based solution would be a good solution as it hooks into the general IP configuration phase, allows easy updates when configuration information changes, and does not involve DNS in general. Use of DHCPv6 requires configuration changes on DHCPv6 clients and servers and, in some cases, may also require implementation changes. Furthermore, it is not obvious that all devices that need translation services would implement stateless DHCPv6. For example, cellular Third Generation Partnership Project (3GPP) networks do not mandate hosts or networks to implement or deploy DHCPv6.
DHCPv6ベースのソリューションは、一般的なIP構成フェーズにフックし、構成情報が変更されたときに簡単に更新でき、一般にDNSを必要としないため、優れたソリューションです。 DHCPv6を使用するには、DHCPv6クライアントとサーバーの構成を変更する必要があり、場合によっては実装の変更も必要になることがあります。さらに、変換サービスを必要とするすべてのデバイスがステートレスDHCPv6を実装することは明らかではありません。たとえば、セルラー第3世代パートナーシッププロジェクト（3GPP）ネットワークは、ホストまたはネットワークにDHCPv6の実装または展開を要求しません。
5.7. Learning the IPv6 Prefix of a Network's NAT64 Using Router Advertisements
5.7. ルーター通知を使用したネットワークのNAT64のIPv6プレフィックスの学習
Revision three of [LEARN-PREFIX] described a new Router Advertisement (RA) [RFC4861] option (OPTION_AFT_PREFIX_RA) that would contain the IPv6 unicast prefix, IPv6 ASM prefix, and IPv6 SSM prefix (and their lengths) for the NAT64. The RA option is essentially the same as for DHCPv6, discussed in Section 5.6.
[LEARN-PREFIX]のリビジョン3では、NAT64のIPv6ユニキャストプレフィックス、IPv6 ASMプレフィックス、IPv6 SSMプレフィックス（およびその長さ）を含む新しいルーターアドバタイズ（RA）[RFC4861]オプション（OPTION_AFT_PREFIX_RA）について説明しました。 RAオプションは、セクション5.6で説明するDHCPv6の場合と基本的に同じです。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1, #2, and #3.
+ 問題＃1、＃2、および＃3を解決するために使用できます。
+ Can solve Issue #4 if lifetime information can be communicated.
+ ライフタイム情報を伝達できれば、問題＃4を解決できます。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires configuration and management of all access routers to emit correct information in the RA. This could, for example, be accomplished somehow by piggybacking on top of routing protocols (which would then require enhancements to routing protocols).
- RAで正しい情報を送信するには、すべてのアクセスルータの設定と管理が必要です。これは、たとえば、ルーティングプロトコルの上にピギーバックすることで何らかの形で実現できます（ルーティングプロトコルの拡張が必要になります）。
- In some operating systems, it may not be trivial to transfer information obtained in the RA to upper layers.
- 一部のオペレーティングシステムでは、RAで取得した情報を上位層に転送するのは簡単ではない場合があります。
- Requires changes to the host operating system's IP stack.
- ホストオペレーティングシステムのIPスタックを変更する必要があります。
- An NSP change requires changes to the access router configuration.
- NSPを変更するには、アクセスルータの設定を変更する必要があります。
- Requires standardization of a new option to the Router Advertisement, which is generally an unfavored approach.
- ルーターアドバタイズメントに対する新しいオプションの標準化が必要です。これは、一般的には好まれないアプローチです。
- The RA-based solution involves changes and management on network-side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- RAベースのソリューションには、NAT64 / DNS64の展開の一部ではない、またはNAT64 / DNS64によって引き起こされる問題を認識していないネットワーク側ノードの変更と管理が含まれます。
Note: If the RA would include multiple NSPs, Issue #5 could be solved as well, but only if nodes as a group would select different NSPs, hence supporting load balancing. As this is not clear, this item is not yet listed under PROs or CONs.
注：RAに複数のNSPが含まれる場合、問題＃5も解決できますが、グループとしてのノードが異なるNSPを選択する場合にのみ、負荷分散がサポートされます。これは明確ではないため、この項目はまだPROまたはCONにリストされていません。
The RA-based solution would be a good solution as it hooks into the general IP configuration phase, allows easy updates when configuration information changes, and does not involve DNS in general. However, generally introducing any changes to the Neighbor Discovery Protocol that are not absolutely necessary are unfavored due to the impact on both the network-side node and end host IP stack implementations.
RAベースのソリューションは、一般的なIP構成フェーズにフックし、構成情報が変更されたときに簡単に更新できるため、一般的にDNSを必要としないため、優れたソリューションです。ただし、ネットワーク側のノードとエンドホストのIPスタック実装の両方に影響があるため、通常、絶対に必要ではない変更を近隣探索プロトコルに導入することは好ましくありません。
Compared to the DHCPv6 equivalent solution in Section 5.6, the management overhead is greater with the RA-based solution. With the DHCPv6-based solution, the management can be centralized to a few DHCPv6 servers compared to the RA-based solution where each access router is supposed to be configured with the same information.
セクション5.6のDHCPv6と同等のソリューションと比較して、RAベースのソリューションでは管理オーバーヘッドが大きくなります。 DHCPv6ベースのソリューションでは、各アクセスルーターが同じ情報で構成されているはずのRAベースのソリューションと比較して、管理を少数のDHCPv6サーバーに集中化できます。
Application-layer protocols, such as Session Traversal Utilities for NAT (STUN) [RFC5389], that define methods for endpoints to learn their external IP addresses could be used for NAT64 and NSP discovery. This document focuses on STUN, but the protocol could be something else as well.
NATのセッショントラバーサルユーティリティ（STUN）[RFC5389]などのアプリケーション層プロトコルは、エンドポイントが外部IPアドレスを学習する方法を定義しており、NAT64とNSPの検出に使用できます。このドキュメントはSTUNに焦点を当てていますが、プロトコルは他の何かかもしれません。
A host must first use DNS to discover IPv6 representations of STUN servers' IPv4 addresses, because the host has no way to directly use IPv4 addresses to contact STUN servers.
ホストは最初にDNSを使用してSTUNサーバーのIPv4アドレスのIPv6表現を検出する必要があります。これは、ホストが直接IPv4アドレスを使用してSTUNサーバーに接続する方法がないためです。
After learning the IPv6 address of a STUN server, the STUN client sends a request to the STUN server containing a new 'SENDING-TO' attribute that tells the server the IPv6 address to which the client sent the request. In a reply, the server includes another new attribute called 'RECEIVED-AS', which contains the server's IP address on which the request arrived. After receiving the reply, the client compares the 'SENDING-TO' and 'RECEIVED-AS' attributes to find out an NSP candidate.
STUNサーバーのIPv6アドレスを学習した後、STUNクライアントは、クライアントが要求を送信したIPv6アドレスをサーバーに通知する新しい「SENDING-TO」属性を含む要求をSTUNサーバーに送信します。応答では、サーバーには、「RECEIVED-AS」と呼ばれる別の新しい属性が含まれます。これには、要求が到着したサーバーのIPアドレスが含まれます。応答を受信した後、クライアントは「SENDING-TO」属性と「RECEIVED-AS」属性を比較して、NSP候補を見つけます。
This solution is relatively similar to the one described in Section 5.1, but instead of using DNS, it uses STUN to get input for heuristic algorithms.
このソリューションは、セクション5.1で説明したものと比較的似ていますが、DNSを使用する代わりに、STUNを使用してヒューリスティックアルゴリズムの入力を取得します。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1 and #2.
+ 問題＃1および＃2を解決するために使用できます。
+ Does not require host changes or supportive protocols such as DNS or DHCPv6. All required logic and heuristics can be implemented in applications that are interested in learning about address synthesis taking place.
+ ホストの変更やDNSやDHCPv6などのサポートプロトコルは必要ありません。必要なすべてのロジックとヒューリスティックは、発生するアドレス合成について学習することに関心のあるアプリケーションに実装できます。
+ The solution is backward compatible from the point of view of 'legacy' hosts and servers.
+ このソリューションは、「レガシー」ホストおよびサーバーの観点からは下位互換性があります。
+ Hosts or applications interested in learning about synthesis and the used NSP can do the "discovery" proactively at any time, for example, every time the host attaches to a new network.
+ 合成と使用されるNSPについて学習することに関心のあるホストまたはアプリケーションは、いつでも、たとえばホストが新しいネットワークに接続するたびに、積極的に「発見」を行うことができます。
+ Does not require explicit support from the network using NAT64.
+ NAT64を使用するネットワークからの明示的なサポートは必要ありません。
+ Can possibly be bundled to existing STUN message exchanges as new attributes, and hence, a client can learn its external IPv4 address and an NSP/WKP with the same exchange.
+ 新しい属性として既存のSTUNメッセージ交換にバンドルされる可能性があるため、クライアントは同じ交換で外部IPv4アドレスとNSP / WKPを学習できます。
+ Can be used to confirm the heuristics by synthesizing the IPv6 address of another STUN server or by synthesizing the IPv6 address of first STUN server after the host has heuristically determined NSP using the method in Section 5.1, i.e., the connectivity test could be done with STUN.
+ 別のSTUNサーバーのIPv6アドレスを合成することにより、またはセクション5.1の方法を使用してホストがNSPをヒューリスティックに決定した後、最初のSTUNサーバーのIPv6アドレスを合成することにより、ヒューリスティックを確認するために使用できます。つまり、接続テストはSTUNで実行できます。 。
+ The true IPv4 destination address is used in NSP determination instead of the IPv4 address received from DNS. This may increase reliability.
+ DNSから受信したIPv4アドレスの代わりに、真のIPv4宛先アドレスがNSPの決定に使用されます。これにより、信頼性が向上する場合があります。
+ The same STUN improvement could also be used to reveal NAT66 on the data path, if the 'RECEIVED-AS' would contain a different IPv6 address from 'SENDING-TO'.
+ 「RECEIVED-AS」に「SENDING-TO」とは異なるIPv6アドレスが含まれる場合、同じSTUNの改善を使用して、データパス上のNAT66を明らかにすることもできます。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires a server on the network to respond to the queries.
- クエリに応答するには、ネットワーク上のサーバーが必要です。
- Requires standardization if done as an extension to STUN.
- STUNの拡張として行う場合は、標準化が必要です。
- The solution involves changes and management on network side nodes that are not really part of the NAT64/DNS64 deployment or aware of issues caused by NAT64/DNS64.
- ソリューションには、実際にはNAT64 / DNS64の展開の一部ではない、またはNAT64 / DNS64によって引き起こされる問題を認識していないネットワーク側ノードでの変更と管理が含まれます。
- Does not solve Issue #3 if the STUN server's synthetic IPv6 address is provisioned via DNS.
- STUNサーバーの合成IPv6アドレスがDNS経由でプロビジョニングされている場合、問題＃3は解決されません。
- Does not solve Issue #4 as the STUN server would not be aware of the learned NSP's validity time.
- STUNサーバーは学習したNSPの有効期間を認識しないため、問題＃4は解決しません。
- Does not solve Issue #5 as the STUN server would not be aware of multiple NSP prefixes.
- STUNサーバーは複数のNSPプレフィックスを認識しないため、問題＃5は解決しません。
- Heavyweight solution especially if an application does not otherwise support STUN.
- 特にアプリケーションが他の方法でSTUNをサポートしていない場合のヘビーウェイトソリューション。
An approach based on STUN or a similar protocol is a second way to solve the problem without explicit access-network support. The heuristics for NSP discovery would still be in the client; however, the result may be more reliable as an actual IPv4 destination address is compared to the IPv6 address used in sending. The additional benefit of STUN is that the client learns its public IPv4 address with the same message exchange. STUN could also be used as the connectivity test tool if the client would first heuristically determine NSP out of DNS as described in Section 5.1, synthesize the IPv6 representation of the STUN server's IPv4 address, and then test connectivity to the STUN server.
STUNまたは同様のプロトコルに基づくアプローチは、明示的なアクセスネットワークサポートなしで問題を解決する2番目の方法です。 NSPディスカバリーのヒューリスティックは依然としてクライアントにあります。ただし、実際のIPv4宛先アドレスが送信に使用されるIPv6アドレスと比較されるため、結果はより信頼できる可能性があります。 STUNの追加の利点は、クライアントが同じメッセージ交換でパブリックIPv4アドレスを学習することです。クライアントがセクション5.1で説明されているようにDNSからNSPを最初に発見的に決定し、STUNサーバーのIPv4アドレスのIPv6表現を合成してから、STUNサーバーへの接続をテストする場合、STUNは接続テストツールとしても使用できます。
As an additional benefit, the STUN improvement could be used for NAT66 discovery.
追加の利点として、STUNの改善をNAT66の発見に使用できます。
5.9. Learning the IPv6 Prefix of a Network's NAT64 Using Access-Technology-Specific Methods
5.9. アクセス技術固有の方法を使用したネットワークのNAT64のIPv6プレフィックスの学習
Several link layers on different access systems have attachment time signaling protocols for negotiating various parameters that are used later on with the established link-layer connection. Examples of such include the 3GPP Non-Access-Stratum (NAS) signaling protocol [NAS.24.301] among other link layers and tunneling solutions. There, using NAS signaling it could be possible to list all NSPs with their respective prefix lengths in generic protocol configuration option containers during the network access establishment. The lack of NSPs in protocol configuration option containers would be an implicit indication that there is no NAT64 present in the network.
異なるアクセスシステム上のいくつかのリンク層には、確立されたリンク層接続で後で使用されるさまざまなパラメーターをネゴシエートするための接続時間信号プロトコルがあります。そのような例には、他のリンク層やトンネリングソリューションの中でも特に、3GPP Non-Access-Stratum（NAS）シグナリングプロトコル[NAS.24.301]が含まれます。そこでは、NASシグナリングを使用して、ネットワークアクセスの確立時に、すべてのNSPをそれぞれのプレフィックス長とともに一般的なプロトコル構成オプションコンテナーにリストすることが可能です。プロトコル構成オプションコンテナーにNSPがないことは、ネットワークにNAT64が存在しないことを暗黙的に示しています。
The PROs of the proposal are listed below:
提案のPROは次のとおりです。
+ Can be used to solve Issues #1, #2, #3, and #5.
+ 問題＃1、＃2、＃3、および＃5を解決するために使用できます。
+ Can solve Issue #4 if lifetime information is also communicated.
+ ライフタイム情報も伝達されれば、問題＃4を解決できます。
The CONs of the proposal are listed below:
提案のCONは以下のとおりです。
- Requires configuration and management of all access routers/ gateways to emit correct information in "link/lower-layer" signaling. If NAT64 functionality is implemented into the access router/gateway that terminates the generic protocol configuration exchange, then the configuration management can be automated.
- 「リンク/下位層」シグナリングで正しい情報を発信するには、すべてのアクセスルータ/ゲートウェイの構成と管理が必要です。 NAT64機能が、一般的なプロトコル構成交換を終了するアクセスルーター/ゲートウェイに実装されている場合、構成管理を自動化できます。
- In some operating systems, it may not be trivial to transfer information obtained in "link/lower layers" to upper layers.
- 一部のオペレーティングシステムでは、「リンク/下位層」で取得した情報を上位層に転送するのは簡単なことではありません。
- An NSP change may require changes to the access router/gateway configuration.
- NSPを変更するには、アクセスルータ/ゲートウェイの設定を変更する必要がある場合があります。
- Requires standardization of a new configuration parameter exchange/container for each access system of interest. The proposed solution is indeed specific to each access technology.
- 対象となる各アクセスシステムに対して、新しい構成パラメータ交換/コンテナの標準化が必要です。提案されたソリューションは、実際には各アクセス技術に固有のものです。
The solution based on access technology would be a good solution as it hooks into general network access establishment phase, allows easy updates when configuration information changes, and does not involve DNS in general. However, generally introducing any changes to the link/lower layers is a long and slow process, and changes would need to be done for all access technologies/systems that are used with NAT64.
アクセステクノロジーに基づくソリューションは、一般的なネットワークアクセス確立フェーズにフックし、構成情報が変更されたときに簡単に更新できるため、一般的にDNSを必要としないため、優れたソリューションです。ただし、一般にリンク/下位層への変更の導入は長くて遅いプロセスであり、NAT64で使用されるすべてのアクセステクノロジー/システムに対して変更を行う必要があります。
Compared to the RA-equivalent solution in Section 5.7, the management overhead is equivalent or even less than the RA-based solution.
セクション5.7のRAと同等のソリューションと比較すると、管理オーバーヘッドはRAベースのソリューションと同等か、それよりも小さくなっています。
Our conclusion is to recommend publishing the Well-Known DNS Name heuristic discovery-based method as a Standards Track IETF document for applications and host implementors to implement as-is.
私たちの結論は、既知のDNS名のヒューリスティックな発見に基づく方法を、アプリケーションとホストの実装者がそのまま実装するためのStandards Track IETFドキュメントとして公開することを推奨することです。
As a general principle, we prefer to have as minimal a solution as possible, avoid impacts to entities not otherwise involved in the protocol translation scheme, minimize host impact, and require minimal to no operational effort on the network side.
一般的な原則として、可能な限り最小限のソリューションを使用し、プロトコル変換スキームに関与しないエンティティへの影響を回避し、ホストへの影響を最小限に抑え、ネットワーク側での操作の労力を最小限に抑えることが望まれます。
Of the different issues, we give the most weight to Issues #1 and #2. We do not give much weight to Issue #3, as cases where hosts need to synthesize IPv6 addresses but do not have DNS available seem rare to us. Even if an application does not otherwise utilize DNS, it ought to be able to trigger a simple DNS query to find out WKP/NSP. Issue #4 is handled by the majority of solutions, and Issue #5 is considered to be mostly insignificant as even if individual hosts would use only one NSP at a time, different hosts would be using different NSPs, hence supporting load-balancing targets. Only one of the discussed solutions, see Section 5.6, supports learning of possible new or indicating support for multiple algorithms for address synthesis other than the one described in [RFC6052].
さまざまな問題のうち、問題＃1と＃2に最も重点を置いています。ホストがIPv6アドレスを合成する必要があるが、DNSを利用できない場合はまれにしか思えないため、問題＃3にはあまり重点を置きません。アプリケーションがDNSを利用しない場合でも、単純なDNSクエリをトリガーしてWKP / NSPを見つけることができるはずです。問題＃4は大多数のソリューションで処理されます。問題＃5は、個々のホストが一度に1つのNSPのみを使用する場合でも、異なるホストが異なるNSPを使用するため、負荷分散ターゲットをサポートするため、ほとんど問題ないと見なされます。議論されたソリューションの1つだけが、セクション5.6を参照して、[RFC6052]で説明されているもの以外のアドレス合成のための複数のアルゴリズムの可能な新しいまたは指示サポートの学習をサポートします。
The DNS64 entity has to be configured with WKP/NSP in order for it to do synthesis; hence, using DNS also for delivering the synthesis information sounds logical. The fact that the synthesis information fate-shares the information received in the DNS response is a valuable attribute and reduces the possible distribution of stale prefix information. However, having all DNS64 servers support explicit WKP/NSP discovery (ENDS0, A64, and DNS SRV record approaches) is difficult to arrange. The U-NAPTR-based approach would require provisioning information into the ".ip6.arpa." tree, which would not be entirely internal for the provider. Use of DHCPv6 would involve additional trouble configuring DHCPv6 servers and ensuring DHCPv6 clients are in place; it would also involve ensuring that the NAT64 and DHCPv6 (and possibly even some DNS64 servers) are all in sync. RA-based mechanisms are operationally expensive as configuration would have to be placed and maintained in the access routers. Furthermore, both DHCPv6 and RA-based mechanisms involve entities that do not otherwise need to be aware of protocol translation (they only need to know DNS server addresses). Finally, regarding the use of STUN, a host does not need to implement STUN whereas DNS is, in practice, required anyway. Also, the STUN protocol would need to be changed on both the host and network side to support the discovery of NAT64 and WKP/NSP.
DNS64エンティティを合成するには、WKP / NSPで構成する必要があります。したがって、合成情報の配信にもDNSを使用することは理にかなっています。合成情報がDNS応答で受信した情報を運命共有するという事実は貴重な属性であり、古いプレフィックス情報の可能な配布を減らします。ただし、すべてのDNS64サーバーが明示的なWKP / NSP検出（ENDS0、A64、およびDNS SRVレコードアプローチ）をサポートするようにすることは、調整が困難です。 U-NAPTRベースのアプローチでは、「。ip6.arpa」へのプロビジョニング情報が必要になります。ツリーは、プロバイダーにとって完全に内部的なものではありません。 DHCPv6を使用すると、DHCPv6サーバーを構成し、DHCPv6クライアントが適切に配置されていることを確認するための追加の問題が発生します。また、NAT64とDHCPv6（場合によっては一部のDNS64サーバーも）がすべて同期していることを確認する必要があります。 RAベースのメカニズムは、設定をアクセスルータに配置して維持する必要があるため、運用コストが高くなります。さらに、DHCPv6とRAベースの両方のメカニズムには、プロトコル変換を意識する必要のないエンティティが含まれます（DNSサーバーのアドレスのみを知る必要があります）。最後に、STUNの使用に関して、ホストはSTUNを実装する必要はありませんが、実際にはDNSが必要です。また、NAT64とWKP / NSPの検出をサポートするには、ホスト側とネットワーク側の両方でSTUNプロトコルを変更する必要があります。
The security considerations are essentially similar to those described in DNS64 [RFC6147]. The document also talks about man-in-the-middle and denial-of-service attacks caused by forging of information required for IPv6 synthesis from corresponding IPv4 addresses. Forgery of information required for IPv6 address synthesis may allow an attacker to insert itself as a middle man or to perform a denial-of-service attack. The DHCPv6 and RA-based approaches are vulnerable to forgery as the attacker may send forged RAs or act as a rogue DHCPv6 server (unless DHCPv6 authentication [RFC3315] or Secure Neighbor Discovery (SEND) [RFC3971] are used). If the attacker is already able to modify and forge DNS responses (flags, addresses of known IPv4-only servers, records, etc.), ability to influence local address synthesis is likely of low additional value. Also, a DNS-based mechanism is only as secure as the method used to configure the DNS server's IP addresses on the host. Therefore, if, for example, the host cannot trust DHCPv6, it cannot trust the DNS server learned via DHCPv6 either, unless the host has a way to authenticate all DNS responses (e.g., via DNSSEC [RFC4033]).
セキュリティに関する考慮事項は、本質的にDNS64 [RFC6147]で説明されているものと同様です。また、対応するIPv4アドレスからのIPv6合成に必要な情報の偽造によって引き起こされる中間者攻撃およびサービス拒否攻撃についても説明します。 IPv6アドレス合成に必要な情報の偽造により、攻撃者は自身を仲介者として挿入したり、サービス拒否攻撃を実行したりする可能性があります。 DHCPv6およびRAベースのアプローチは、攻撃者が偽造RAを送信したり、不正なDHCPv6サーバーとして機能したりする可能性があるため、偽造に対して脆弱です（DHCPv6認証[RFC3315]またはSecure Neighbor Discovery（SEND）[RFC3971]が使用されている場合を除く）。攻撃者が既にDNS応答（フラグ、既知のIPv4専用サーバーのアドレス、レコードなど）を変更および偽造できる場合、ローカルアドレス合成に影響を与える能力は、付加価値が低い可能性があります。また、DNSベースのメカニズムは、ホスト上でDNSサーバーのIPアドレスを構成するために使用される方法と同じくらい安全です。したがって、たとえば、ホストがDHCPv6を信頼できない場合、ホストがすべてのDNS応答を認証する方法（DNSSEC [RFC4033]など）を備えている場合を除き、ホストはDHCPv6を介して学習したDNSサーバーも信頼できません。
The following individual contributed text to this document.
次の個人がこのドキュメントにテキストを寄稿しました。
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair France Telecom Rennes、35000 France
EMail: mohamed.boucadair@orange-ftgroup.com
The authors would like to thank Dan Wing and Christian Huitema, especially for the STUN idea and for their valuable comments and discussions.
著者は、特にSTUNのアイデアと貴重なコメントと議論について、Dan WingとChristian Huitemaに感謝します。
Jouni Korhonen would like to specifically thank Nokia Siemens Networks as he completed the majority of this document while employed there.
Jouni Korhonenは、Nokia Siemens Networksに雇用されている間にこのドキュメントの大部分を完成させたため、Nokia Siemens Networksに特に感謝したいと思います。
[RFC2326] Schulzrinne, H., Rao, A., and R. Lanphier, "Real Time Streaming Protocol (RTSP)", RFC 2326, April 1998.
[RFC2326] Schulzrinne、H.、Rao、A。、およびR. Lanphier、「Real Time Streaming Protocol（RTSP）」、RFC 2326、1998年4月。
[RFC2671] Vixie, P., "Extension Mechanisms for DNS (EDNS0)", RFC 2671, August 1999.
[RFC2671] Vixie、P。、「DNSの拡張メカニズム（EDNS0）」、RFC 2671、1999年8月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：セッション開始プロトコル」 、RFC 3261、2002年6月。
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC3315] Droms、R.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315、July 2003 。
[RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", RFC 4566, July 2006.
[RFC4566] Handley、M.、Jacobson、V。、およびC. Perkins、「SDP：Session Description Protocol」、RFC 4566、2006年7月。
[RFC4848] Daigle, L., "Domain-Based Application Service Location Using URIs and the Dynamic Delegation Discovery Service (DDDS)", RFC 4848, April 2007.
[RFC4848] Daigle、L。、「URIと動的委任発見サービス（DDDS）を使用したドメインベースのアプリケーションサービスロケーション」、RFC 4848、2007年4月。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W。、およびH. Soliman、「Neighbor Discovery for IP version 6（IPv6）」、RFC 4861、2007年9月。
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008.
[RFC5389] Rosenberg、J.、Mahy、R.、Matthews、P。、およびD. Wing、「NAT用セッショントラバーサルユーティリティ（STUN）」、RFC 5389、2008年10月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052] Bao、C.、Huitema、C.、Bagnulo、M.、Boucadair、M。、およびX. Li、「IPv4 / IPv6トランスレータのIPv6アドレッシング」、RFC 6052、2010年10月。
[RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
[RFC6146] Bagnulo、M.、Matthews、P。、およびI. van Beijnum、「Stateful NAT64：Network Address and Protocol Translation to IPv6 Clients to IPv4 Servers」、RFC 6146、2011年4月。
[RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
[RFC6147] Bagnulo、M.、Sullivan、A.、Matthews、P.、I。van Beijnum、「DNS64：DNS Extensions for Network Address Translation to IPv4 Servers to IPv4 Servers」、RFC 6147、2011年4月。
[RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012.
[RFC6724] Thaler、D.、Draves、R.、Matsumoto、A。、およびT. Chown、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 6724、2012年9月。
[RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 7050, November 2013.
[RFC7050] Savolainen、T.、Korhonen、J。、およびD. Wing、「IPv6アドレス合成に使用されるIPv6プレフィックスの発見」、RFC 7050、2013年11月。
[DHCPV6-SHARED-ADDRESS] Boucadair, M., Levis, P., Grimault, J., Savolainen, T., and G. Bajko, "Dynamic Host Configuration Protocol (DHCPv6) Options for Shared IP Addresses Solutions", Work in Progress, December 2009.
[DHCPV6-SHARED-ADDRESS] Boucadair、M.、Levis、P.、Grimault、J.、Savolainen、T.、and G. Bajko、 "Dynamic Host Configuration Protocol（DHCPv6）Options for Shared IP Addresses Solutions"、Work in進捗状況、2009年12月。
[DNS-A64] Boucadair, M. and E. Burgey, "A64: DNS Resource Record for IPv4-Embedded IPv6 Address", Work in Progress, September 2010.
[DNS-A64] Boucadair、M。およびE. Burgey、「A64：DNS Resource Record for IPv4-Embedded IPv6 Address」、Work in Progress、2010年9月。
[LEARN-PREFIX] Wing, D., "Learning the IPv6 Prefix of a Network's IPv6/ IPv4 Translator", Work in Progress, October 2009.
[LEARN-PREFIX] Wing、D。、「Learning the IPv6 Prefix of a Network's IPv6 / IPv4 Translator」、Work in Progress、2009年10月。
[MCAST-TRANSLATOR] Venaas, S., Asaeda, H., SUZUKI, S., and T. Fujisaki, "An IPv4 - IPv6 multicast translator", Work in Progress, December 2010.
[MCAST-TRANSLATOR] Venaas、S.、Asaeda、H.、SUZUKI、S.、and T. Fujisaki、 "An IPv4-IPv6 multicast translation"、Work in Progress、2010年12月。
[NAS.24.301] 3GPP, "Non-Access-Stratum (NAS) protocol for Evolved Packet System (EPS)", 3GPP TS 24.301 8.8.0, December 2010, <http://www.3gpp.org/ftp/Specs/html-info/24301.htm>.
[NAS.24.301] 3GPP、「進化したパケットシステム（EPS）の非アクセス層（NAS）プロトコル」、3GPP TS 24.301 8.8.0、2010年12月、<http://www.3gpp.org/ftp/Specs /html-info/24301.htm>。
[REFERRAL-PS] Carpenter, B., Jiang, S., and Z. Cao, "Problem Statement for Referral", Work in Progress, February 2011.
[REFERRAL-PS] Carpenter、B.、Jiang、S.、Z。Cao、「紹介の問題声明」、進行中の作業、2011年2月。
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3971] Arkko、J.、Kempf、J.、Zill、B。、およびP. Nikander、「SEcure Neighbor Discovery（SEND）」、RFC 3971、2005年3月。
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, "DNS Security Introduction and Requirements", RFC 4033, March 2005.
[RFC4033] Arends、R.、Austein、R.、Larson、M.、Massey、D。、およびS. Rose、「DNSセキュリティの概要と要件」、RFC 4033、2005年3月。
[RFC5507] IAB, Faltstrom, P., Austein, R., and P. Koch, "Design Choices When Expanding the DNS", RFC 5507, April 2009.
[RFC5507] IAB、Faltstrom、P.、Austein、R。、およびP. Koch、「DNSを拡張するときの設計上の選択」、RFC 5507、2009年4月。
[RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
[RFC6144] Baker、F.、Li、X.、Bao、C。、およびK. Yin、「Framework for IPv4 / IPv6 Translation」、RFC 6144、2011年4月。
[RFC6891] Damas, J., Graff, M., and P. Vixie, "Extension Mechanisms for DNS (EDNS(0))", STD 75, RFC 6891, April 2013.
[RFC6891] Damas、J.、Graff、M。、およびP. Vixie、「DNSの拡張メカニズム（EDNS（0））」、STD 75、RFC 6891、2013年4月。
[SYNTH-FLAG-2010] Korhonen, J. and T. Savolainen, "EDNS0 Option for Indicating AAAA Record Synthesis and Format", Work in Progress, July 2010.
[SYNTH-FLAG-2010] Korhonen、J。およびT. Savolainen、「AAAAレコードの合成とフォーマットを示すEDNS0オプション」、Work in Progress、2010年7月。
[SYNTH-FLAG-2011] Korhonen, J. and T. Savolainen, "EDNS0 Option for Indicating AAAA Record Synthesis and Format", Work in Progress, February 2011.
[SYNTH-FLAG-2011] Korhonen、J。およびT. Savolainen、「AAAAレコードの合成とフォーマットを示すEDNS0オプション」、進行中の作業、2011年2月。
[V4V6MC-FRAMEWORK] Venaas, S., Li, X., and C. Bao, "Framework for IPv4/IPv6 Multicast Translation", Work in Progress, June 2011.
[V4V6MC-FRAMEWORK] Venaas、S.、Li、X。、およびC. Bao、「Framework for IPv4 / IPv6 Multicast Translation」、Work in Progress、2011年6月。
Authors' Addresses
著者のアドレス
Jouni Korhonen (editor) Broadcom Porkkalankatu 24 FIN-00180 Helsinki Finland
Jouni Korhonen（編集者）Broadcom Porkkalankatu 24 FIN-00180ヘルシンキフィンランド
EMail: jouni.nospam@gmail.com
Teemu Savolainen (editor) Nokia Hermiankatu 12 D FI-33720 Tampere Finland
Teemu Savolainen（編集者）Nokia Hermiankatu 12 D FI-33720タンペレフィンランド
EMail: teemu.savolainen@nokia.com