[要約] RFC 5902は、IPv6ネットワークアドレス変換に関するIABの考えをまとめたものであり、IPv6 NATの利点と課題を議論しています。目的は、IPv6 NATの実装と使用に関する指針を提供し、IPv6ネットワークの設計者や運営者に役立つ情報を提供することです。
Internet Architecture Board (IAB) D. Thaler
Request for Comments: 5902 L. Zhang
Category: Informational G. Lebovitz
ISSN: 2070-1721 July 2010
IAB Thoughts on IPv6 Network Address Translation
IPv6ネットワークアドレスの変換に関するIABの考え
Abstract
概要
There has been much recent discussion on the topic of whether the IETF should develop standards for IPv6 Network Address Translators (NATs). This document articulates the architectural issues raised by IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the IAB's thoughts on the current open issues and the solution space.
IETFがIPv6ネットワークアドレス翻訳者（NAT）の標準を開発すべきかどうかのトピックに関する最近の議論がありました。このドキュメントは、IPv6 NAT、IPv6 NATを持つことの長所と短所によって提起されたアーキテクチャの問題を明確にし、現在のオープンな問題とソリューション空間に関するIABの考えを提供します。
Status of This Memo
本文書の位置付け
This document is not an Internet Standards Track specification; it is published for informational purposes.
このドキュメントは、インターネット標準の追跡仕様ではありません。情報目的で公開されています。
This document is a product of the Internet Architecture Board (IAB) and represents information that the IAB has deemed valuable to provide for permanent record. Documents approved for publication by the IAB are not a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
このドキュメントは、インターネットアーキテクチャボード（IAB）の製品であり、IABが永続的な記録を提供する価値があるとみなした情報を表しています。IABによって公開されることが承認された文書は、インターネット標準のレベルの候補者ではありません。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/rfc5902.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、http：//www.rfc-editor.org/info/rfc5902で取得できます。
Copyright Notice
著作権表示
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2010 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. What is the problem? . . . . . . . . . . . . . . . . . . . . . 3
2.1. Avoiding Renumbering . . . . . . . . . . . . . . . . . . . 3
2.2. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 4
2.3. Homogenous Edge Network Configurations . . . . . . . . . . 4
2.4. Network Obfuscation . . . . . . . . . . . . . . . . . . . 5
2.4.1. Hiding Hosts . . . . . . . . . . . . . . . . . . . . . 5
2.4.2. Topology Hiding . . . . . . . . . . . . . . . . . . . 8
2.4.3. Summary Regarding NAT as a Tool for Network
Obfuscation . . . . . . . . . . . . . . . . . . . . . 8
2.5. Simple Security . . . . . . . . . . . . . . . . . . . . . 9
2.6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 9
3. Architectural Considerations of IPv6 NAT . . . . . . . . . . . 9
4. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1. Discussion . . . . . . . . . . . . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
6. IAB Members at the Time of Approval . . . . . . . . . . . . . 13
7. Informative References . . . . . . . . . . . . . . . . . . . . 14
In the past, the IAB has published a number of documents relating to Internet transparency and the end-to-end principle, and other IETF documents have also touched on these issues as well. These documents articulate the general principles on which the Internet architecture is based, as well as the core values that the Internet community seeks to protect going forward. Most recently, RFC 4924 [RFC4924] reaffirms these principles and provides a review of the various documents in this area.
過去に、IABは、インターネットの透明性とエンドツーエンドの原則に関する多くのドキュメントを公開しており、他のIETFドキュメントもこれらの問題にも触れています。これらの文書は、インターネットアーキテクチャの基礎となる一般原則と、インターネットコミュニティが今後保護しようとするコアバリューを明確にしています。最近では、RFC 4924 [RFC4924]はこれらの原則を再確認し、この分野のさまざまな文書のレビューを提供します。
Facing imminent IPv4 address space exhaustion, recently there have been increased efforts in IPv6 deployment. However, since late 2008 there have also been increased discussions about whether the IETF should standardize network address translation within IPv6. People who are against standardizing IPv6 NAT argue that there is no fundamental need for IPv6 NAT, and that as IPv6 continues to roll out, the Internet should converge towards reinstallation of the end-to-end reachability that has been a key factor in the Internet's success. On the other hand, people who are for IPv6 NAT believe that NAT vendors would provide IPv6 NAT implementations anyway as NAT can be a solution to a number of problems, and that the IETF should avoid repeating the same mistake as with IPv4 NAT, where the lack of protocol standards led to different IPv4 NAT implementations, making NAT traversal difficult.
差し迫ったIPv4に直面して、スペースの疲労を解決し、最近、IPv6の展開の取り組みが増加しています。ただし、2008年後半以来、IETFがIPv6内のネットワークアドレス変換を標準化する必要があるかどうかについての議論も増加しています。IPv6 NATの標準化に反対している人々は、IPv6 NATの根本的な必要性はなく、IPv6が展開し続けるにつれて、インターネットはインターネットの重要な要因であるエンドツーエンドの到達可能性の再インストールに向けて収束する必要があると主張します。成功。一方、IPv6 NATを対象としている人は、NATベンダーがとにかくIPv6 NATの実装を提供すると信じています。NATは多くの問題の解決策となり、IETFはIPv4 NATと同じ間違いを繰り返すことを避ける必要があります。プロトコル標準の欠如は、異なるIPv4 NAT実装につながり、NATトラバーサルを困難にしました。
An earlier effort, [RFC4864], provides a discussion of the real or perceived benefits of NAT and suggests alternatives for most of them, with the intent of showing that NAT is not required to get the desired benefits. However, it also identifies several gaps remaining to be filled.
以前の努力[RFC4864]は、NATの実質的または知覚された利点についての議論を提供し、それらのほとんどの代替案を示唆しており、NATが望ましい利点を得る必要がないことを示す意図を示しています。ただし、残っているいくつかのギャップが埋められていることも識別されます。
This document provides the IAB's current thoughts on this debate. We believe that the issue at hand must be viewed from an overall architectural standpoint in order to fully assess the pros and cons of IPv6 NAT on the global Internet and its future development.
このドキュメントは、この議論に関するIABの現在の考えを提供します。目前の問題は、グローバルなインターネット上のIPv6 NATの長所と短所とその将来の開発を完全に評価するために、全体的なアーキテクチャの観点から見なければならないと考えています。
The discussions on the desire for IPv6 NAT can be summarized as follows. Network address translation is viewed as a solution to achieve a number of desired properties for individual networks: avoiding renumbering, facilitating multihoming, making configurations homogenous, hiding internal network details, and providing simple security.
IPv6 NATの欲求に関する議論は、次のように要約できます。ネットワークアドレスの変換は、個々のネットワークの多くの望ましいプロパティを達成するためのソリューションと見なされています。名前変更の回避、マルチホームの促進、構成の均一になり、内部ネットワークの詳細を隠し、簡単なセキュリティを提供します。
As discussed in [RFC4864], Section 2.5, the ability to change service providers with minimal operational difficulty is an important requirement in many networks. However, renumbering is still quite painful today, as discussed in [RFC5887]. Currently it requires reconfiguring devices that deal with IP addresses or prefixes, including DNS servers, DHCP servers, firewalls, IPsec policies, and potentially many other systems such as intrusion detection systems, inventory management systems, patch management systems, etc.
[RFC4864]、セクション2.5で説明したように、多くのネットワークでは、運用上の難易度を最小限に抑えるサービスプロバイダーを変更する機能が重要な要件です。ただし、[RFC5887]で説明したように、今日でも変更は非常に苦痛です。現在、DNSサーバー、DHCPサーバー、ファイアウォール、IPSECポリシー、侵入検知システム、在庫管理システム、パッチ管理システムなどの他の多くのシステムなど、IPアドレスまたはプレフィックスを扱うデバイスの再構成が必要です。
In practice today, renumbering does not seem to be a significant problem in consumer networks, such as home networks, where addresses or prefixes are typically obtained through DHCP and are rarely manually configured in any component. However, in managed networks, renumbering can be a serious problem.
今日の実際には、住所や接頭辞が通常DHCPを介して取得され、どのコンポーネントでも手動で構成されることはほとんどないホームネットワークなど、消費者ネットワークでは変更が重要ではないようです。ただし、管理されたネットワークでは、非難は深刻な問題になる可能性があります。
We also note that many, if not most, large enterprise networks avoid the renumbering problem by using provider-independent (PI) IP address blocks. The use of PI addresses is inherent in today's Internet operations. However, in smaller managed networks that cannot get provider-independent IP address blocks, renumbering remains a serious issue. Regional Internet Registries (RIRs) constantly receive requests for PI address blocks; one main reason that they hesitate in assigning PI address blocks to all users is the concern about the PI addresses' impact on the routing system scalability.
また、プロバイダーに依存しない（PI）IPアドレスブロックを使用することにより、ほとんどではないにしても、多くの大規模なエンタープライズネットワークが変更の問題を回避することに注意してください。PIアドレスの使用は、今日のインターネット運用に固有のものです。ただし、プロバイダーに依存しないIPアドレスブロックを取得できない小規模な管理ネットワークでは、改修は依然として深刻な問題です。地域のインターネットレジストリ（RIRS）は、PIアドレスブロックのリクエストを常に受け取ります。PIアドレスブロックをすべてのユーザーに割り当てるのをためらう主な理由の1つは、ルーティングシステムのスケーラビリティに対するPIアドレスの影響に関する懸念です。
Another important requirement in many networks is site multihoming. A multihomed site essentially requires that its IP prefixes be present in the global routing table to achieve the desired reliability in its Internet connectivity as well as load balancing. In today's practice, multihomed sites with PI addresses announce their PI prefixes to the global routing system; multihomed sites with provider-allocated (PA) addresses also announce the PA prefix they obtained from one service provider to the global routing system through another service provider, effectively disabling provider-based prefix aggregation. This practice makes the global routing table scale linearly with the number of multihomed user networks.
多くのネットワークにおけるもう1つの重要な要件は、サイトマルチホームです。マルチホームサイトでは、本質的に、IPプレフィックスがグローバルルーティングテーブルに存在することを要求して、インターネット接続とロードバランシングで望ましい信頼性を実現します。今日の練習では、PIアドレスを備えたマルチホームサイトは、グローバルルーティングシステムへのPIプレフィックスを発表します。プロバイダーに割り当てられた（PA）アドレスを備えたマルチホームサイトは、別のサービスプロバイダーを介して、あるサービスプロバイダーからグローバルルーティングシステムに取得したPAプレフィックスを発表し、プロバイダーベースのプレフィックス集約を効果的に無効にします。このプラクティスにより、グローバルルーティングテーブルは、マルチホームユーザーネットワークの数と直線的にスケールを拡大します。
This issue was identified in [RFC4864], Section 6.4. Unfortunately, no solution except NAT has been deployed today that can insulate the global routing system from the growing number of multihomed sites, where a multihomed site simply assigns multiple IPv4 addresses (one from each of its service providers) to its exit router, which is an IPv4 NAT box. Using address translation to facilitate multihoming support has one unique advantage: there is no impact on the routing system scalability, as the NAT box simply takes one address from each service provider, and the multihomed site does not inject its own routes into the system. Intuitively, it also seems straightforward to roll the same solution into multihoming support in the IPv6 deployment. However, one should keep in mind that this approach brings all the drawbacks of putting a site behind a NAT box, including the loss of reachability to the servers behind the NAT box.
この問題は、[RFC4864]、セクション6.4で特定されました。残念ながら、Multihomedサイトが複数のIPv4アドレス（サービスプロバイダーのそれぞれから1つ）を出口ルーターに単純に割り当てる単純なマルチホームサイトからグローバルなルーティングシステムを隔離できるNAT以外のソリューションは本日展開されていません。IPv4 NATボックス。住所変換を使用してマルチホームサポートを容易にすることには1つの独自の利点があります。NATボックスは各サービスプロバイダーから1つのアドレスを取得するだけで、マルチホームサイトが独自のルートをシステムに注入しないため、ルーティングシステムのスケーラビリティに影響はありません。直感的には、同じソリューションをIPv6展開でマルチホームサポートにロールインすることも簡単に思えます。ただし、このアプローチは、NATボックスの後ろのサーバーへの到達可能性の損失など、NATボックスの後ろにサイトを置くというすべての欠点をもたらすことに留意する必要があります。
It is also important to point out that a multihomed site announcing its own prefix(es) achieves two important benefits that NAT-based multihoming support does not provide. First, end-to-end communications can be preserved in face of connectivity failures of individual service providers, as long as the site remains connected through at least one operational service provider. Second, announcing one's prefixes also gives a multihomed site the ability to perform traffic engineering and load balancing.
また、独自のプレフィックス（ES）を発表するマルチホームサイトが、NATベースのマルチホームサポートが提供していない2つの重要な利点を達成することを指摘することも重要です。まず、少なくとも1つの運用サービスプロバイダーを介してサイトが接続されたままである限り、個々のサービスプロバイダーの接続障害に直面してエンドツーエンドの通信を保存できます。第二に、自分のプレフィックスを発表することで、マルチホームのサイトにトラフィックエンジニアリングと負荷分散を実行する機能が提供されます。
Service providers supporting residential customers need to minimize support costs (e.g., help desk calls). Often a key factor in minimizing support costs is ensuring customers have homogenous configurations, including the addressing architecture. Today, when IPv4 NATs are provided by a service provider, all customers get the same address space on their home networks, and hence the home gateway always has the same address. From a customer-support perspective, this perhaps represents the most important property of NAT usage today.
住宅の顧客をサポートするサービスプロバイダーは、サポートコストを最小限に抑える必要があります（ヘルプデスクコールなど）。多くの場合、サポートコストを最小限に抑える重要な要素は、アドレス指定アーキテクチャを含む均一な構成を顧客に保証することです。今日、IPv4 NATがサービスプロバイダーによって提供されると、すべての顧客がホームネットワークで同じアドレススペースを取得するため、ホームゲートウェイには常に同じアドレスがあります。顧客サポートの観点から見ると、これはおそらく今日のNAT使用量の最も重要な特性を表しています。
In IPv6, link-local addresses can be used to ensure that all home gateways have the same address, and to provide homogenous addresses to any other devices supported by the service provider. Unlike IPv4, having a globally unique address does not prevent the use of a homogenous address within the subnet. It is only in the case of multi-subnet customers that IPv6 NAT would provide some homogeneity that wouldn't be provided by link-local addresses. For multi-subnet customers (e.g., a customer using a wireless access point behind the service provider router/modem), service providers today might only discuss problems (for IPv4 or IPv6) from computers connected directly to the service provider router.
IPv6では、リンクローカルアドレスを使用して、すべてのホームゲートウェイが同じアドレスを持っていることを確認し、サービスプロバイダーがサポートする他のデバイスに均質なアドレスを提供することができます。IPv4とは異なり、グローバルに一意のアドレスを持つことは、サブネット内の均質なアドレスの使用を妨げません。Multi-SubNetの顧客の場合にのみ、IPv6 NATがLink-Localアドレスによって提供されない均一性を提供します。マルチサブネットの顧客（たとえば、サービスプロバイダールーター/モデムの背後にあるワイヤレスアクセスポイントを使用している顧客）の場合、サービスプロバイダーは今日、サービスプロバイダールーターに直接接続されたコンピューターの問題（IPv4またはIPv6の場合）のみを議論することができます。
It is currently unknown whether IPv6 link-local addresses provide sufficient homogeneity to minimize help desk calls. If they do not, providers might still desire IPv6 NATs in the residential gateways they provide.
IPv6 Link-Localアドレスがヘルプデスクコールを最小限に抑えるのに十分な均一性を提供するかどうかは現在不明です。そうでない場合、プロバイダーは、提供する住宅用ゲートウェイでIPv6 NATを希望する場合があります。
Most network administrators want to hide the details of the computing resources, information infrastructure, and communications networks within their borders. This desire is rooted in the basic security principle that an organization's assets are for its sole use and all information about those assets, their operation, and the methods and tactics of their use are proprietary secrets. Some organizations use their information and communication technologies as a competitive advantage in their industries. It is a generally held belief that measures must be taken to protect those secrets. The first layer of protection of those secrets is preventing access to the secrets or knowledge about the secrets whenever possible. It is understandable why network administrators would want to keep the details about the hosts on their network, as well as the network infrastructure itself, private. They believe that NAT helps achieve this goal.
ほとんどのネットワーク管理者は、コンピューティングリソース、情報インフラストラクチャ、およびコミュニケーションネットワークの詳細を境界内に隠したいと考えています。この欲求は、組織の資産が唯一の使用であり、それらの資産、その運用、およびその使用の方法と戦術に関するすべての情報が独自の秘密であるという基本的なセキュリティ原則に根ざしています。一部の組織は、情報通信技術を業界で競争上の優位性として使用しています。これらの秘密を保護するためには、対策を講じなければならないというのは一般的に保持されている信念です。これらの秘密の保護の最初の層は、可能な限り秘密に関する秘密や知識へのアクセスを妨げることです。ネットワーク管理者がネットワーク上のホストの詳細と、ネットワークインフラストラクチャ自体、プライベートを保持したい理由は理解できます。彼らは、NATがこの目標を達成するのに役立つと信じています。
As a specific measure of network obfuscation, network administrators wish to keep secret any and all information about the computer systems residing within their network boundaries. Such computer systems include workstations, laptops, servers, function-specific end-points (e.g., printers, scanners, IP telephones, point-of-sale machines, building door access-control devices), and such. They want to prevent an external entity from counting the number of hosts on the network. They also want to prevent host fingerprinting, i.e., gaining information about the constitution, contents, or function of a host. For example, they want to hide the role of a host, as whether it is a user workstation, a finance server, a source code build server, or a printer. A second element of host-fingerprinting prevention is to hide details that could aid an attacker in compromising the host. Such details might include the type of operating system, its version number, any patches it may or may not have, the make and model of the device hardware, any application software packages loaded, those version numbers and patches, and so on. With such information about hosts, an attacker can launch a more focused, targeted attack. Operators want to stop both host counting and host fingerprinting.
ネットワークの難読化の特定の尺度として、ネットワーク管理者は、ネットワークの境界内にあるコンピューターシステムに関するすべての情報を秘密にしたいと考えています。このようなコンピューターシステムには、ワークステーション、ラップトップ、サーバー、機能固有のエンドポイント（プリンター、スキャナー、IP電話、ポイントオブセールマシン、建物のアクセス制御デバイスなど）などが含まれます。彼らは、外部エンティティがネットワーク上のホストの数をカウントできないようにしたいと考えています。彼らはまた、ホストのフィンガープリント、つまり、ホストの憲法、内容、または機能に関する情報を得るのを防ぎたいと考えています。たとえば、ユーザーワークステーション、ファイナンスサーバー、ソースコードビルドサーバー、またはプリンターなど、ホストの役割を非表示にしたいと考えています。ホストフィンガープリント予防の2番目の要素は、攻撃者がホストを損なうのを助ける可能性のある詳細を隠すことです。このような詳細には、オペレーティングシステムの種類、そのバージョン番号、持っていないパッチまたはないパッチ、デバイスハードウェアのメーカーとモデル、ロードされたアプリケーションソフトウェアパッケージ、それらのバージョン番号とパッチなどが含まれます。ホストに関するそのような情報を使用すると、攻撃者は、より焦点を絞ったターゲットを絞った攻撃を開始できます。オペレーターは、ホストカウントとホストのフィンガープリントの両方を停止したいと考えています。
Where host counting is a concern, it is worth pointing out some of the challenges in preventing it. [Bellovin] showed how one can successfully count the number of hosts behind a certain type of simple NAT box. More complex NAT deployments, e.g., ones employing Network Address Port Translators (NAPTs) with a pool of public addresses that are randomly bound to internal hosts dynamically upon receipt of any new connection, and do so without persistency across connections from the same host are more successful in preventing host counting. However, the more complex the NAT deployment, the less likely that complex connection types like the Session Initiation Protocol (SIP) [RFC3261] and the Stream Control Transmission Protocol (SCTP) [RFC4960] will be able to successfully traverse the NAT. This observation follows the age-old axiom for networked computer systems: for every unit of security you gain, you give up a unit of convenience, and for every unit of convenience you hope to gain, you must give up a unit of security.
ホストカウントが懸念事項である場合、それを防ぐ際の課題のいくつかを指摘する価値があります。[Bellovin]は、特定のタイプの単純なNATボックスの背後にあるホストの数をうまくカウントする方法を示しました。より複雑なNAT展開、たとえば、新しい接続の受領時に内部ホストにランダムにバインドされているパブリックアドレスのプールを備えたネットワークアドレスポート翻訳者（NAPTS）を採用しているNAT展開（NAPTS）は、同じホストからの接続全体で持続性がなくても、ホストカウントの防止に成功しました。ただし、NATの展開が複雑なほど、セッション開始プロトコル（SIP）[RFC3261]やストリーム制御伝送プロトコル（SCTP）[RFC4960]などの複雑な接続タイプがNATを正常にトラバースする可能性が低くなります。この観察結果は、ネットワーク化されたコンピューターシステムの昔ながらの公理に従います。あなたが得るセキュリティのすべての単位について、あなたは利便性の単位をあきらめ、あなたが得たいと思うすべての利便性の単位について、あなたはセキュリティの単位をあきらめなければなりません。
If fields such as fragment ID, TCP initial sequence number, or ephemeral port number are chosen in a predictable fashion (e.g., sequentially), then an attacker may correlate packets or connections coming from the same host.
フラグメントID、TCP初期シーケンス番号、またははかないポート番号などのフィールドが予測可能な方法で選択されている場合（たとえば、順次）、攻撃者は同じホストから来るパケットまたは接続を相関させることができます。
To prevent counting hosts by counting addresses, one might be tempted to use a separate IP address for each transport-layer connection. Such an approach introduces other architectural problems, however. Within the host's subnet, various devices including switches, routers, and even the host's own hardware interface often have a limited amount of state available before causing communication that uses a large number of addresses to suffer significant performance problems. In addition, if an attacker can somehow determine an average number of connections per host, the attacker can still estimate the number of hosts based on the number of connections observed. Hence, such an approach can adversely affect legitimate communication at all times, simply to raise the bar for an attacker.
アドレスをカウントしてホストをカウントするのを防ぐために、各輸送層接続に別のIPアドレスを使用するように誘惑される場合があります。ただし、このようなアプローチは、他の建築上の問題をもたらします。ホストのサブネット内では、スイッチ、ルーター、さらにはホスト独自のハードウェアインターフェイスを含むさまざまなデバイスが、多くのアドレスを使用して重大なパフォーマンスの問題に苦しむ通信を引き起こす前に、利用可能な状態が限られていることがよくあります。さらに、攻撃者がホストあたりの接続の平均数を何らかの形で決定できる場合、攻撃者は観測された接続の数に基づいてホストの数を推定できます。したがって、このようなアプローチは、単に攻撃者のためにバーを上げるために、常に正当なコミュニケーションに悪影響を与える可能性があります。
Where host fingerprinting is concerned, even a complex NAT cannot prevent fingerprinting completely. The way that different hosts respond to different requests and sequences of events will indicate consistently the type of a host that it is, its OS, version number, and sometimes applications installed, etc. Products exist that do this for network administrators as a service, as part of a vulnerability assessment.
ホストの指紋に関する場合、複雑なNATでさえ、フィンガープリントを完全に防ぐことはできません。さまざまなホストが異なる要求と一連のイベントに応答する方法は、ホストのタイプ、OS、バージョン番号、および時にはインストールされたアプリケーションなどを一貫して示しています。脆弱性評価の一環として。
These scanning tools initiate connections of various types across a range of possible IP addresses reachable through that network. They observe what returns, and then send follow-up messages accordingly until they "fingerprint" the host thoroughly. When run as part of a network assessment process, these tools are normally run from the inside of the network, behind the NAT. If such a tool is set outside a network boundary (as part of an external vulnerability assessment or penetration test) along the path of packets, and is passively observing and recording connection exchanges, over time it can fingerprint hosts only if it has a means of determining which externally viewed connections are originating from the same internal host. If the NATing is simple and static, and each host's internal address is always mapped to the same external address and vice versa, the tool has 100% success fingerprinting the host. With the internal hosts mapped to their external IP addresses and fingerprinted, the attacker can launch targeted attacks into those hosts, or reliably attempt to hijack those hosts' connections. If the NAT uses a single external IP, or a pool of dynamically assigned IP addresses for each host, but does so in a deterministic and predictable way, then the operation of fingerprinting is more complex, but quite achievable.
これらのスキャンツールは、そのネットワークを介して到達可能なさまざまなIPアドレスにわたってさまざまなタイプの接続を開始します。彼らは、何が戻っているかを観察し、それに応じてフォローアップメッセージを送信して、ホストを徹底的に「指紋」します。ネットワーク評価プロセスの一部として実行されると、これらのツールは通常、ネットワークの内側から、NATの後ろから実行されます。このようなツールがパケットのパスに沿ってネットワーク境界（外部脆弱性評価または侵入テストの一部として）の外側に設定され、接続交換を受動的に観察および記録している場合、時間の経過とともに、手段がある場合にのみ指紋を採取できます。どの外部で表示されている接続が同じ内部ホストから発生しているかを決定します。ネートがシンプルで静的であり、各ホストの内部アドレスが常に同じ外部アドレスにマッピングされ、その逆の場合、ツールはホストを指紋に100％成功します。内部ホストが外部IPアドレスにマッピングされ、フィンガープリントされた場合、攻撃者はそれらのホストにターゲット攻撃を開始したり、それらのホストの接続を確実にハイジャックしようとします。NATが単一の外部IP、または各ホストに動的に割り当てられたIPアドレスのプールを使用しているが、決定論的で予測可能な方法でそれを行う場合、フィンガープリントの操作はより複雑ですが、非常に達成可能です。
If the NAT uses dynamically assigned addresses, with short-term persistency, but no externally learnable determinism, then the problem gets harder for the attacker. The observer may be able to fingerprint a host during the lifetime of a particular IP address mapping, and across connections, but once that IP mapping is terminated, the observer doesn't immediately know which new mapping will be that same host. After much observation and correlation, the attacker could sometimes determine if an observed new connection in flight is from a familiar host. With that information, and a good set of man-in-the-middle attack tools, the attacker could attempt to compromise the host by hijacking a new connection of adequately long duration. If temporal persistency is not deployed on the NAT, then this tactic becomes almost impossible. As the difficulty and cost of the attack increases, the number of attackers attempting to employ it decreases. And certainly the attacker would not be able to initiate a connection toward a host for which the attacker does not know the current IP address binding. So, the attacker is limited to hijacking observed connections thought to be from a familiar host, or to blindly initiating attacks on connections in flight. This is why network administrators appreciate complex NATs' ability to deter host counting and fingerprinting, but such deterrence comes at a cost of host reachability.
NATが短期的な持続性で動的に割り当てられたアドレスを使用しているが、外部的に学習できる決定論がない場合、攻撃者にとって問題はより難しくなります。オブザーバーは、特定のIPアドレスマッピングの生涯および接続全体でホストを指紋することができる場合がありますが、そのIPマッピングが終了すると、オブザーバーはどの新しいマッピングが同じホストになるかをすぐに知りません。多くの観察と相関の後、攻撃者は、観察された新しい接続が馴染みのあるホストからのものであるかどうかを時々判断することができます。その情報と、中間の攻撃ツールの良いセットにより、攻撃者は、適切に長い期間の新しいつながりをハイジャックすることでホストを妥協しようとすることができました。一時的な持続性がNATに展開されない場合、この戦術はほとんど不可能になります。攻撃の難易度とコストが増加すると、それを採用しようとする攻撃者の数が減少します。そして確かに、攻撃者は、攻撃者が現在のIPアドレスのバインディングを知らないホストへの接続を開始できないでしょう。したがって、攻撃者は、おなじみのホストからのものであると考えられる観察された接続のハイジャック、または飛行中の接続に対する攻撃を盲目的に開始することに限定されます。これが、ネットワーク管理者がホストのカウントとフィンガープリントを阻止する複雑なNATの能力を高く評価する理由ですが、そのような抑止はホストの到達可能性のコストでもたらされます。
It is perceived that a network operator may want to hide the details of the network topology, the size of the network, the identities of the internal routers, and the interconnection among the routers. This desire has been discussed in [RFC4864], Sections 4.4 and 6.2.
ネットワークオペレーターは、ネットワークトポロジの詳細、ネットワークのサイズ、内部ルーターのアイデンティティ、およびルーター間の相互接続を非表示にしたいと考えられています。この欲求は、[RFC4864]、セクション4.4および6.2で議論されています。
However, the success of topology hiding is dependent upon the complexity, dynamism, and pervasiveness of bindings the NAT employs (all of which were described above). The more complex, the more the topology will be hidden, but the less likely that complex connection types will successfully traverse the NAT barrier. Thus, the trade-off is reachability across applications.
ただし、トポロジー隠蔽の成功は、NATが採用するバインディングの複雑さ、ダイナミズム、および普及に依存しています（これらはすべて上記で説明されていました）。複雑になればなるほど、トポロジーは隠されますが、複雑な接続タイプがNATバリアを正常に通過する可能性は低くなります。したがって、トレードオフはアプリケーション全体の到達可能性です。
Even if one can hide the actual addresses of internal hosts through address translation, this does not necessarily prove sufficient to hide internal topology. It may be possible to infer some aspects of topological information from passively observing packets. For example, based on packet timing, delay measurements, the Hop Limit field, or other fields in the packet header, one could infer the relative distance between multiple hosts. Once an observed session is believed to match a previously fingerprinted host, that host's distance from the NAT device may be learned, but not its exact location or particular internal subnet.
アドレス変換を通じて内部ホストの実際のアドレスを隠すことができたとしても、これは必ずしも内部トポロジを隠すのに十分であるとは限りません。受動的に観察するパケットからトポロジー情報のいくつかの側面を推測することが可能かもしれません。たとえば、パケットのタイミング、遅延測定、ホップ制限フィールド、またはパケットヘッダーの他のフィールドに基づいて、複数のホスト間の相対距離を推測できます。観察されたセッションが以前にフィンガープリントされたホストと一致すると考えられると、そのホストのNATデバイスからの距離は学習できますが、正確な場所や特定の内部サブネットは学習できません。
Host fingerprinting is required in order to do a thorough distance mapping. An attacker might then use message contents to lump certain types of devices into logical clusters, and take educated guesses at attacks. This is not, however, a thorough mapping. Some NATs change the TTL hop counts, much like an application-layer proxy would, while others don't; this is an administrative setting on more advanced NATs. The simpler and more static the NAT, the more possible this is. The more complex and dynamic and non-persistent the NAT bindings, the more difficult.
徹底的な距離マッピングを行うには、ホストフィンガープリントが必要です。その後、攻撃者はメッセージコンテンツを使用して、特定の種類のデバイスを論理クラスターにまとめ、攻撃で教育を受けた推測を行うことがあります。ただし、これは徹底的なマッピングではありません。一部のNATは、アプリケーション層プロキシがそうであるように、TTLホップカウントを変更しますが、他のNATはそうではありません。これは、より高度なNATの管理設定です。NATをよりシンプルで静的にするほど、これは可能性が高くなります。Nat Bindingsがより複雑で動的で非密接になればなるほど、より困難になります。
The degree of obfuscation a NAT can achieve will be a function of its complexity as measured by:
NATが達成できる難読化の程度は、次のように測定されるその複雑さの関数です。
o The use of one-to-many NAPT mappings;
o 1対多くのナップマッピングの使用。
o The randomness over time of the mappings from internal to external IP addresses, i.e., non-deterministic mappings from an outsider's perspective;
o 内部から外部IPアドレスから外部IPアドレス、つまり、部外者の観点からの非決定的マッピングのマッピングの時間の経過に伴うランダム性。
o The lack of persistence of mappings, i.e., the shortness of mapping lifetimes and not using the same mapping repeatedly;
o マッピングの持続性の欠如、つまり、同じマッピングを繰り返し使用していないマッピング寿命の短さ。
o The use of re-writing in IP header fields such as TTL.
o TTLなどのIPヘッダーフィールドでの書き換えの使用。
However, deployers be warned: as obfuscation increases, host reachability decreases. Mechanisms such as STUN [RFC5389] and Teredo [RFC4380] fail with the more complex NAT mechanisms.
ただし、展開者は警告されます。難読化が増加すると、ホストの到達可能性が低下します。Stun [RFC5389]やTeredo [RFC4380]などのメカニズムは、より複雑なNATメカニズムで失敗します。
It is commonly perceived that a NAT box provides one level of protection because external hosts cannot directly initiate communication with hosts behind a NAT. However, one should not confuse NAT boxes with firewalls. As discussed in [RFC4864], Section 2.2, the act of translation does not provide security in itself. The stateful filtering function can provide the same level of protection without requiring a translation function. For further discussion, see [RFC4864], Section 4.2.
外部ホストはNATの背後にあるホストとの通信を直接開始できないため、NATボックスは1つのレベルの保護を提供すると一般に認識されています。ただし、NATボックスをファイアウォールと混同しないでください。[RFC4864]、セクション2.2で説明したように、翻訳行為はそれ自体でセキュリティを提供しません。ステートフルなフィルタリング関数は、翻訳関数を必要とせずに同じレベルの保護を提供できます。詳細については、[RFC4864]、セクション4.2を参照してください。
At present, the primary benefits one may receive from deploying NAT appear to be avoiding renumbering, facilitating multihoming without impacting routing scalability, and making edge consumer network configurations homogenous.
現在、NATの展開から得られる主な利点は、変更を回避し、ルーティングのスケーラビリティに影響を与えずにマルチホームを促進し、エッジコンシューマネットワークの構成を均質にすることを避けているようです。
Network obfuscation (host hiding, both counting and fingerprinting prevention, and topology hiding) may well be achieved with more complex NATs, but at the cost of losing some reachability and application success. Again, when it comes to security, this is often the case: to gain security one must give up some measure of convenience.
ネットワークの難読化（ホストの隠れ、カウントとフィンガープリントの両方の予防、およびトポロジーの両方）は、より複雑なNATで達成される可能性がありますが、到達可能性とアプリケーションの成功を失う犠牲を払うことができます。繰り返しになりますが、セキュリティに関しては、これがよくあることです。セキュリティを獲得するには、ある程度の利便性を放棄する必要があります。
First, it is important to distinguish between the effects of a NAT box vs. the effects of a firewall. A firewall is intended to prevent unwanted traffic [RFC4948] without impacting wanted traffic, whereas a NAT box also interferes with wanted traffic. In the remainder of this section, the term "reachability" is used with respect to wanted traffic.
まず、NATボックスの効果とファイアウォールの影響を区別することが重要です。ファイアウォールは、必要なトラフィックに影響を与えることなく、不要なトラフィック[RFC4948]を防ぐことを目的としていますが、NATボックスは必要なトラフィックを妨害します。このセクションの残りの部分では、「到達可能性」という用語は、必要なトラフィックに関して使用されます。
The discussions on IPv6 NAT often refer to the wide deployment of IPv4 NAT, where people have both identified tangible benefits and gained operational experience. However, the discussions so far seem mostly focused on the potential benefits that IPv6 NAT may, or may not, bring. Little attention has been paid to the bigger picture, as we elaborate below.
IPv6 NATに関する議論は、多くの場合、IPv4 NATの幅広い展開を指します。そこでは、人々が有形の利点を特定し、運用経験を積むことができます。ただし、これまでの議論は、IPv6 NATがもたらす可能性がある、またはもたらさない可能性のある潜在的な利点に主に焦点を合わせているようです。以下に詳しく説明しているように、全体像にはほとんど注意が払われていません。
When considering the benefits that IPv6 NAT may bring to a site that deploys it, we must not overlook a bigger question: if one site deploys IPv6 NAT, what is the potential impact it brings to the rest of the Internet that does not do IPv6 NAT? By "the rest of the Internet", we mean the Internet community that develops, deploys, and uses end-to-end applications and protocols and hence is affected by any loss of transparency (see [RFC2993] and [RFC4924] for further discussion). This important question does not seem to have been addressed, or addressed adequately.
IPv6 NATがそれを展開するサイトにもたらすメリットを考慮するとき、私たちはより大きな質問を見落としてはなりません：1つのサイトがIPv6 NATを展開する場合、IPv6NATを実行しないインターネットの残りの部分にもたらす潜在的な影響は何ですか？「インターネットの残りの部分」とは、エンドツーエンドのアプリケーションとプロトコルを開発、展開、および使用するインターネットコミュニティを意味するため、さらなる議論のために透明性の損失の影響を受けます（[RFC2993]および[RFC4924]を参照してください。）。この重要な質問は、対処されたものではなく、適切に対処されていないようです。
We believe that the discussions on IPv6 NAT should be put in the context of the overall Internet architecture. The foremost question is not how many benefits one may derive from using IPv6 NAT, but more fundamentally, whether a significant portion of parties on the Internet are willing to deploy IPv6 NAT, and hence whether we want to make IP address translation a permanent building block in the Internet architecture.
IPv6 NATに関する議論は、インターネットアーキテクチャ全体のコンテキストに置かれるべきであると考えています。一番の質問は、IPv6 NATを使用することから得られる利点の数ではなく、より根本的に、インターネット上の当事者のかなりの部分がIPv6 NATを展開する意思があるかどうか、したがって、IPアドレス翻訳を永続的なビルディングブロックにしたいかどうかです。インターネットアーキテクチャで。
One may argue that the answers to the above questions depend on whether we can find adequate solutions to the renumbering, site multihoming, and edge network configuration problems, and whether the solutions provide transparency or not. If transparency is not provided, making NAT a permanent building block in the Internet would represent a fundamental architectural change.
上記の質問に対する回答は、変更、サイトのマルチホーム、およびエッジネットワーク構成の問題に対する適切な解決策を見つけることができるかどうか、およびソリューションが透明性を提供するかどうかにかかっていると主張するかもしれません。透明性が提供されていない場合、NATをインターネット内の永続的なビルディングブロックにすることは、基本的なアーキテクチャの変化を表します。
It is desirable that IPv6 users and applications be able to reach each other directly without having to worry about address translation boxes between the two ends. IPv6 application developers in general should be able to program based on the assumption of end-to-end reachability (of wanted traffic), without having to address the issue of traversing NAT boxes. For example, referrals and multi-party conversations are straightforward with end-to-end addressing, but vastly complicated in the presence of address translation. Similarly, network administrators should be able to run their networks without the added complexity of NATs, which can bring not only the cost of additional boxes, but also increased difficulties in network monitoring and problem debugging.
IPv6ユーザーとアプリケーションは、両端の間の翻訳ボックスのアドレスボックスを心配することなく、互いに直接届くことができることが望ましいです。一般に、IPv6アプリケーション開発者は、NATボックスの移動の問題に対処することなく、エンドツーエンドの到達可能性（必要なトラフィックの）の仮定に基づいてプログラムできる必要があります。たとえば、紹介とマルチパーティの会話は、エンドツーエンドのアドレス指定で簡単ですが、住所変換の存在下では非常に複雑です。同様に、ネットワーク管理者は、NATの複雑さを追加せずにネットワークを実行できる必要があります。これにより、追加のボックスのコストだけでなく、ネットワーク監視と問題のデバッグの困難が増えます。
Given the diversity of the Internet user populations and the diversity in today's operational practice, it is conceivable that some parties may have a strong desire to deploy IPv6 NAT, and the Internet should accommodate different views that lead to different practices (i.e., some using IPv6 NAT, others not).
インターネットユーザー集団の多様性と今日の運用慣行における多様性を考えると、一部の当事者はIPv6 NATを展開したいという強い欲求を持っている可能性があり、インターネットはさまざまなプラクティスにつながるさまざまな見解に対応する必要があると考えられます（つまり、IPv6を使用しているものもあります。ナット、他ではない）。
If we accept the view that some, but not all, parties want IPv6 NAT, then the real debate should not be on what benefits IPv6 NAT may bring to the parties who deploy it. It is undeniable that network address translation can bring certain benefits to its users. However, the real challenge we should address is how to design IPv6 NAT in such a way that it can hide its impact within some localized scope. If IPv6 NAT design can achieve this goal, then the Internet as a whole can strive for (reinstalling) the end-to-end reachability model.
すべてではないが、一部の政党がIPv6 NATを望んでいるという見解を受け入れた場合、実際の議論は、IPv6 NATがそれを展開する当事者にもたらすメリットがあるものではないはずです。ネットワークアドレスの変換がユーザーに特定の利点をもたらすことができることは否定できません。ただし、私たちが対処すべき本当の課題は、IPv6 NATをいくつかのローカライズされた範囲内でその影響を隠す方法で設計する方法です。IPv6 NAT設計がこの目標を達成できる場合、インターネット全体は、エンドツーエンドの到達可能性モデルを努力することができます。
From an end-to-end perspective, the solution space for renumbering and multihoming can be broadly divided into three classes:
エンドツーエンドの観点から見ると、変更とマルチホミングのためのソリューションスペースは、3つのクラスに大幅に分割できます。
1. Endpoints get a stable, globally reachable address: In this class of solutions, end sites use provider-independent addressing and hence endpoints are unaffected by changing service providers. For this to be a complete solution, provider-independent addressing must be available to all managed networks (i.e., all networks that use manual configuration of addresses or prefixes in any type of system). However, in today's practice, assigning provider-independent addresses to all networks, including small ones, raises concerns with the scalability of the global routing system. This is an area of ongoing research and experimentation. In practice, network administrators have also been developing short-term approaches to resolve today's gap between the continued routing table growth and limitations in existing router capacity [NANOG].
1. エンドポイントは、安定したグローバルに到達可能なアドレスを取得します。このクラスのソリューションでは、エンドサイトではプロバイダーに依存しないアドレス指定を使用するため、エンドポイントはサービスプロバイダーの変更によって影響を受けません。これを完全なソリューションにするには、プロバイダーに依存しないアドレス指定をすべてのマネージャーネットワーク（つまり、あらゆるタイプのシステム内のアドレスまたはプレフィックスの手動構成を使用するすべてのネットワーク）が利用できる必要があります。ただし、今日の実践では、プロバイダーに依存しないアドレスを小さなネットワークに割り当てることは、小さなネットワークを含むすべてのネットワークに、グローバルルーティングシステムのスケーラビリティに関する懸念を引き起こします。これは、進行中の研究と実験の分野です。実際には、ネットワーク管理者は、継続的なルーティングテーブルの成長と既存のルーター容量の制限との間の今日のギャップを解決するための短期的なアプローチも開発しています[Nanog]。
2. Endpoints get a stable but non-globally-routable address on physical interfaces but a dynamic, globally routable address inside a tunnel: In this class of solutions, hosts use locally-scoped (and hence provider-independent) addresses for communication within the site using their physical interfaces. As a result, managed systems such as routers, DHCP servers, etc., all see stable addresses. Tunneling from the host to some infrastructure device is then used to communicate externally. Tunneling provides the host with globally routable addresses that may change, but address changes are constrained to systems that operate over or beyond the tunnel, including DNS servers and applications. These systems, however, are the ones that often can already deal with changes today using mechanisms such as DNS dynamic update. However, if endpoints and the tunnel infrastructure devices are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved.
2. エンドポイントは、物理インターフェイスで安定しているがglob的にルート可能でないアドレスを取得しますが、トンネル内の動的でグローバルにルーティング可能なアドレスを取得します。このクラスのソリューションでは、ホストをホストします。それらの物理的なインターフェイス。その結果、ルーター、DHCPサーバーなどの管理されたシステムはすべて、安定したアドレスを参照してください。ホストからいくつかのインフラストラクチャデバイスへのトンネリングを使用して、外部から通信します。トンネリングは、変化する可能性のあるグローバルにルーティング可能なアドレスをホストに提供しますが、アドレスの変更は、DNSサーバーやアプリケーションを含むトンネルを超えて動作するシステムに制約されます。ただし、これらのシステムは、DNSダイナミックアップデートなどのメカニズムを使用して、今日の変更にすでに対処できることが多いシステムです。ただし、エンドポイントとトンネルインフラストラクチャデバイスがさまざまな組織が所有している場合、関連するインセンティブと調整の問題によりソリューションは段階的に展開するのが困難です。
3. Endpoints get a stable address that gets translated in the network: In this class of solutions, end sites use non-globally-routable addresses within the site, and translate them to globally routable addresses somewhere in the network. In general, this causes the loss of end-to-end transparency, which is the subject of [RFC4924] and the documents it surveys. If the translation is reversible, and the translation is indeed reversed by the time it reaches the other end of communication, then end-to-end transparency can be provided. However, if the two translators involved are owned by different organizations, then solutions are harder to incrementally deploy due to the incentive and coordination issues involved.
3. エンドポイントは、ネットワークで翻訳される安定したアドレスを取得します。このクラスのソリューションでは、エンドサイトではサイト内の非グロバリに普及可能なアドレスを使用し、ネットワーク内のどこかにグローバルにルーティング可能なアドレスに翻訳します。一般に、これにより、エンドツーエンドの透明性が失われます。これは[RFC4924]の主題であり、文書の調査を行います。翻訳が可逆的であり、翻訳が実際に通信の反対側に達するまでに逆転する場合、エンドツーエンドの透明度を提供できます。ただし、関係する2人の翻訳者がさまざまな組織が所有している場合、関連するインセンティブと調整の問題のためにソリューションは段階的に展開するのが困難です。
Concerning routing scalability, although there is no immediate danger, routing scalability has been a longtime concern in operational communities, and an effective and deployable solution must be found. We observe that the question at hand is not about whether some parties can run NAT, but rather, whether the Internet as a whole would be willing to rely on NAT to curtail the routing scalability problem, and whether we have investigated all the potential impacts of doing so to understand its cost on the overall architecture. If effective solutions can be deployed in time to allow assigning provider-independent IPv6 addresses to all user communities, the Internet can avoid the complexity and fragility and other unforeseen problems introduced by NAT.
ルーティングのスケーラビリティに関しては、即時の危険はありませんが、ルーティングスケーラビリティは運用コミュニティで長年の懸念であり、効果的で展開可能なソリューションを見つける必要があります。手元の質問は、一部の当事者がNATを実行できるかどうかではなく、インターネット全体がルーティングスケーラビリティの問題を削減するためにNATに頼る意思があるかどうか、そして私たちがのすべての潜在的な影響を調査したかどうかについて観察します。全体的なアーキテクチャのコストを理解するためにそうしています。プロバイダーに依存しないIPv6アドレスをすべてのユーザーコミュニティに割り当てることができるように、効果的なソリューションを時間内に展開できる場合、インターネットはNATによって導入された複雑さと脆弱性、その他の予期しない問題を回避できます。
As [RFC4924] states:
[rfc4924]が次のように述べています。
A network that does not filter or transform the data that it carries may be said to be "transparent" or "oblivious" to the content of packets. Networks that provide oblivious transport enable the deployment of new services without requiring changes to the core. It is this flexibility that is perhaps both the Internet's most essential characteristic as well as one of the most important contributors to its success.
それが運ぶデータをフィルタリングまたは変換しないネットワークは、パケットのコンテンツに対して「透明」または「忘れられない」と言えるかもしれません。忘却の輸送を提供するネットワークは、コアの変更を必要とせずに新しいサービスの展開を可能にします。この柔軟性は、おそらくインターネットの最も重要な特徴であり、その成功の最も重要な貢献者の1つであることです。
We believe that providing end-to-end transparency, as defined above, is key to the success of the Internet. While some fields of traffic (e.g., Hop Limit) are defined to be mutable, transparency requires that fields not defined as such arrive un-transformed. Currently, the source and destination addresses are defined as immutable fields, and are used as such by many protocols and applications.
上記で定義されているように、エンドツーエンドの透明性を提供することがインターネットの成功の鍵であると考えています。一部のトラフィックフィールド（ホップ制限など）は可変性があると定義されていますが、透明性には、そのように定義されていないフィールドが変容せずに到着する必要があります。現在、ソースおよび宛先アドレスは不変のフィールドとして定義されており、多くのプロトコルとアプリケーションによって使用されています。
Each of the three classes of solution can be defined in a way that preserves end-to-end transparency.
ソリューションの3つのクラスのそれぞれは、エンドツーエンドの透明性を保持する方法で定義できます。
While we do not consider IPv6 NATs to be desirable, we understand that some deployment of them is likely unless workable solutions to avoiding renumbering, facilitating multihoming without adversely impacting routing scalability, and homogeneity are generally recognized as useful and appropriate.
IPv6 NATは望ましいとは考えていませんが、変更を避け、ルーティングのスケーラビリティに悪影響を与えることなくマルチホミングを促進するための実行可能な解決策がない限り、それらの展開は可能性が高いことを理解しています。
As such, we strongly encourage the community to consider end-to-end transparency as a requirement when proposing any solution, whether it be based on tunneling or translation or some other technique. Solutions can then be compared based on other aspects such as scalability and ease of deployment.
そのため、トンネリングや翻訳、その他の手法に基づいているかどうかにかかわらず、ソリューションを提案する際に、エンドツーエンドの透明性を要件として考慮することをコミュニティに強く奨励しています。その後、ソリューションは、スケーラビリティや展開の容易さなど、他の側面に基づいて比較できます。
Section 2 discusses potential privacy concerns as part of the Host Counting and Topology Hiding problems.
セクション2では、ホストカウントの一部としての潜在的なプライバシーの懸念とトポロジーの隠れ問題について説明します。
Marcelo Bagnulo Gonzalo Camarillo Stuart Cheshire Vijay Gill Russ Housley John Klensin Olaf Kolkman Gregory Lebovitz Andrew Malis Danny McPherson David Oran Jon Peterson Dave Thaler
マルセロ・バグヌロ・ゴンザロ・カマリロ・スチュアート・チェシャー・ギル・ギル・ラス・ヒューズリー・ジョン・クレンシン・オラフ・コルクマン・グレゴリー・レボヴィッツ・アンドリュー・マリス・ダニー・マクファーソン・デイビッド・オラン・ジョン・ピーターソン・デイブ・サラー
[Bellovin] Bellovin, S., "A Technique for Counting NATted Hosts", Proc. Second Internet Measurement Workshop, November 2002, <http://www.cs.columbia.edu/~smb/papers/fnat.pdf>.
[Bellovin] Bellovin、S。、「Natted Hostsをカウントするためのテクニック」、Proc。2番目のインターネット測定ワークショップ、2002年11月、<http://www.cs.columbia.edu/~smb/papers/fnat.pdf>。
[NANOG] "Extending the Life of Layer 3 Switches in a 256k+ Route World", NANOG 44, October 2008, <http://www.nanog.org/ meetings/nanog44/presentations/Monday/ Roisman_lightning.pdf>.
[Nanog]「256Kルートワールドのレイヤー3スイッチの寿命を延ばす」、Nanog 44、2008年10月、<http://www.nanog.org/ Meetings/nanog44/Presentations/Monday/Roisman_lighting.pdf>。
[RFC2993] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[RFC2993] Hain、T。、「Natの建築的意味」、RFC 2993、2000年11月。
[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：SESSION INTIANIATION Protocol」、RFC 3261、2002年6月。
[RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through Network Address Translations (NATs)", RFC 4380, February 2006.
[RFC4380] Huitema、C。、「Teredo：ネットワークアドレス翻訳（NAT）を介してUDPを介したIPv6のトンネル」、RFC 4380、2006年2月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and E. Klein, "Local Network Protection for IPv6", RFC 4864, May 2007.
[RFC4864] van de Velde、G.、Hain、T.、Droms、R.、Carpenter、B。、およびE. Klein、「IPv6のローカルネットワーク保護」、RFC 4864、2007年5月。
[RFC4924] Aboba, B. and E. Davies, "Reflections on Internet Transparency", RFC 4924, July 2007.
[RFC4924] Aboba、B。およびE. Davies、「インターネット透明性に関する反省」、RFC 4924、2007年7月。
[RFC4948] Andersson, L., Davies, E., and L. Zhang, "Report from the IAB workshop on Unwanted Traffic March 9-10, 2006", RFC 4948, August 2007.
[RFC4948] Andersson、L.、Davies、E。、およびL. Zhang、「2006年3月9〜10日、不要なトラフィックに関するIABワークショップの報告」、RFC 4948、2007年8月。
[RFC4960] Stewart, R., "Stream Control Transmission Protocol", RFC 4960, September 2007.
[RFC4960] Stewart、R。、「Stream Control Transmission Protocol」、RFC 4960、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月。
[RFC5887] Carpenter, B., Atkinson, R., and H. Flinck, "Renumbering Still Needs Work", RFC 5887, May 2010.
[RFC5887] Carpenter、B.、Atkinson、R。、およびH. Flinck、「Nemumberingまだ仕事が必要」、RFC 5887、2010年5月。
Authors' Addresses
著者のアドレス
Dave Thaler Microsoft Corporation One Microsoft Way Redmond, WA 98052 USA
Dave Thaler Microsoft Corporation One Microsoft Way Redmond、WA 98052 USA
Phone: +1 425 703 8835
EMail: dthaler@microsoft.com
Lixia Zhang UCLA Computer Science Department 3713 Boelter Hall Los Angeles, CA 90095 USA
Lixia Zhang UCLA Computer Science Department 3713 Boelter Hall Los Angeles、CA 90095 USA
Phone: +1 310 825 2695
EMail: lixia@cs.ucla.edu
Gregory Lebovitz Juniper Networks, Inc. 1194 North Mathilda Ave. Sunnyvale, CA 94089 USA
Gregory Lebovitz Juniper Networks、Inc。1194 North Mathilda Ave. Sunnyvale、CA 94089 USA
EMail: gregory.ietf@gmail.com
Internet Architecture Board
インターネットアーキテクチャボード
EMail: iab@iab.org