Network Working Group G. Van de Velde
Request for Comments: 4864 T. Hain
Category: Informational R. Droms
Cisco Systems
B. Carpenter
IBM
E. Klein
Tel Aviv University
May 2007
Local Network Protection for IPv6
Status of This Memo
このメモのステータス
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
Abstract
抽象
Although there are many perceived benefits to Network Address Translation (NAT), its primary benefit of "amplifying" available address space is not needed in IPv6. In addition to NAT's many serious disadvantages, there is a perception that other benefits exist, such as a variety of management and security attributes that could be useful for an Internet Protocol site. IPv6 was designed with the intention of making NAT unnecessary, and this document shows how Local Network Protection (LNP) using IPv6 can provide the same or more benefits without the need for address translation.
ネットワークアドレス変換（NAT）には多くの知覚のメリットがありますが、利用可能なアドレス空間を「増幅する」のその主な利点は、IPv6で必要とされません。 NATの多くの重大な欠点に加えて、他の利点は、インターネット・プロトコル・サイトのために有用である可能性管理とセキュリティ属性の様々なとして、存在するという認識があります。 IPv6がNATは不要との意図で設計されており、この文書は、IPv6を使用してローカルネットワーク保護（LNP）は、アドレス変換を必要とせずに、同じまたはそれ以上の利益を提供することができる方法を示していました。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Perceived Benefits of NAT and Its Impact on IPv4 . . . . . . . 6
2.1. Simple Gateway between Internet and Private Network . . . 6
2.2. Simple Security Due to Stateful Filter Implementation . . 6
2.3. User/Application Tracking . . . . . . . . . . . . . . . . 7
2.4. Privacy and Topology Hiding . . . . . . . . . . . . . . . 8
2.5. Independent Control of Addressing in a Private Network . . 9
2.6. Global Address Pool Conservation . . . . . . . . . . . . . 9
2.7. Multihoming and Renumbering with NAT . . . . . . . . . . . 10
3. Description of the IPv6 Tools . . . . . . . . . . . . . . . . 11
3.1. Privacy Addresses (RFC 3041) . . . . . . . . . . . . . . . 11
3.2. Unique Local Addresses . . . . . . . . . . . . . . . . . . 12
3.3. DHCPv6 Prefix Delegation . . . . . . . . . . . . . . . . . 13
3.4. Untraceable IPv6 Addresses . . . . . . . . . . . . . . . . 13
4. Using IPv6 Technology to Provide the Market Perceived
Benefits of NAT . . . . . . . . . . . . . . . . . . . . . . . 14
4.1. Simple Gateway between Internet and Internal Network . . . 14
4.2. IPv6 and Simple Security . . . . . . . . . . . . . . . . . 15
4.3. User/Application Tracking . . . . . . . . . . . . . . . . 17
4.4. Privacy and Topology Hiding Using IPv6 . . . . . . . . . . 17
4.5. Independent Control of Addressing in a Private Network . . 20
4.6. Global Address Pool Conservation . . . . . . . . . . . . . 21
4.7. Multihoming and Renumbering . . . . . . . . . . . . . . . 21
5. Case Studies . . . . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Medium/Large Private Networks . . . . . . . . . . . . . . 22
5.2. Small Private Networks . . . . . . . . . . . . . . . . . . 24
5.3. Single User Connection . . . . . . . . . . . . . . . . . . 25
5.4. ISP/Carrier Customer Networks . . . . . . . . . . . . . . 26
6. IPv6 Gap Analysis . . . . . . . . . . . . . . . . . . . . . . 27
6.1. Simple Security . . . . . . . . . . . . . . . . . . . . . 27
6.2. Subnet Topology Masking . . . . . . . . . . . . . . . . . 28
6.3. Minimal Traceability of Privacy Addresses . . . . . . . . 28
6.4. Site Multihoming . . . . . . . . . . . . . . . . . . . . . 28
7. Security Considerations . . . . . . . . . . . . . . . . . . . 29
8. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 29
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 29
10. Informative References . . . . . . . . . . . . . . . . . . . . 30
Appendix A. Additional Benefits Due to Native IPv6 and
Universal Unique Addressing . . . . . . . . . . . . . 32
A.1. Universal Any-to-Any Connectivity . . . . . . . . . . . . 32
A.2. Auto-Configuration . . . . . . . . . . . . . . . . . . . . 32
A.3. Native Multicast Services . . . . . . . . . . . . . . . . 33
A.4. Increased Security Protection . . . . . . . . . . . . . . 33
A.5. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 34
A.6. Merging Networks . . . . . . . . . . . . . . . . . . . . . 34
There have been periodic claims that IPv6 will require a Network Address Translation (NAT), because network administrators use NAT to meet a variety of needs when using IPv4 and those needs will also have to be met when using IPv6. Although there are many perceived benefits to NAT, its primary benefit of "amplifying" available address space is not needed in IPv6. The serious disadvantages and impact on applications by ambiguous address space and Network Address Translation [1] [5] have been well documented [4] [6], so there will not be much additional discussion here. However, given its wide deployment NAT undoubtedly has some perceived benefits, though the bulk of those using it have not evaluated the technical trade-offs. Indeed, it is often claimed that some connectivity and security concerns can only be solved by using a NAT device, without any mention of the negative impacts on applications. This is amplified through the widespread sharing of vendor best practice documents and sample configurations that do not differentiate the translation function of address expansion from the state function of limiting connectivity.
ネットワーク管理者は、IPv4を使用する場合のさまざまなニーズを満たすためにNATを使用して、IPv6を使用している場合、それらのニーズも満たされなければならないので、IPv6がネットワークアドレス変換（NAT）が必要になります定期的な主張がありました。 NATには多くの知覚のメリットがありますが、利用可能なアドレス空間を「増幅する」のその主な利点は、IPv6で必要とされません。曖昧なアドレス空間とネットワークアドレス変換によって、アプリケーション上の重大な欠点と影響[1]〜[5]も報告されている[4] [6]、ので、ここで多くの追加的な議論がされません。それを使用して、それらの大部分は技術的なトレードオフを評価されていないにもかかわらずしかし、その広い展開与えられたNATは、間違いなく、いくつかの知覚の利点があります。確かに、多くの場合、いくつかの接続とセキュリティ上の懸念がアプリケーションのみにマイナスの影響の一切の言及せず、NATデバイスを使用することによって解決することができると主張しています。これは、接続を制限する状態関数からアドレス拡張の翻訳機能を区別していないベンダーのベストプラクティスドキュメントおよびコンフィギュレーションの広範な共有によって増幅されます。
This document describes the uses of a NAT device in an IPv4 environment that are regularly cited as 'solutions' for perceived problems. It then shows how the goals of the network manager can be met in an IPv6 network without using the header modification feature of NAT. It should be noted that this document is 'informational', as it discusses approaches that will work to accomplish the goals of the network manager. It is specifically not a Best Current Practice (BCP) that is recommending any one approach or a manual on how to configure a network.
この文書では、定期的に、知覚の問題のためのソリューション」として引用されているIPv4環境にNATデバイスの使用法を説明します。これは、ネットワーク管理者の目標はNATのヘッダ変更機能を使用せずにIPv6ネットワークに満たすことができる方法を示しています。ネットワーク管理者の目標を達成するために働くだろうなアプローチを説明し、この文書は、「情報」であることに留意すべきです。これは、特に任意の一つのアプローチやネットワークの設定方法のマニュアルを推奨している最も良いCurrent Practice（BCP）ではありません。
As far as security and privacy are concerned, this document considers how to mitigate a number of threats. Some are obviously external, such as having a hacker or a worm-infected machine outside trying to penetrate and attack the local network. Some are local, such as a disgruntled employee disrupting business operations or the unintentional negligence of a user downloading some malware, which then proceeds to attack from within. Some may be inherent in the device hardware ("embedded"), such as having some firmware in a domestic appliance "call home" to its manufacturer without the user's consent.
限り、セキュリティとプライバシーを懸念しているとして、この文書は、脅威の数を軽減する方法を考えています。いくつかは、そのような浸透してローカルネットワークを攻撃しようとしている外部のハッカーやワームに感染したマシンを持って、明らかに外部にあります。いくつかは、このような事業運営や、その後の内部からの攻撃に進み、いくつかのマルウェアをダウンロードするユーザーの意図しない過失を乱す不満を持つ従業員として、ローカルです。いくつかは、ユーザーの同意なしにそのメーカーの国内アプライアンス「コール・ホーム」でのいくつかのファームウェアを持つものとして、（「埋め込まれた」）デバイスのハードウェアに固有のかもしれません。
Another consideration discussed is the view that NAT can be used to fulfill the goals of a security policy. On the one hand, NAT does satisfy some policy goals, such as topology hiding; at the same time it defeats others, such as the ability to produce an end-to-end audit trail at network level. That said, there are artifacts of NAT devices that do provide some value.
議論もう1つの考慮事項は、NATは、セキュリティポリシーの目標を達成するために使用することができ図です。一方では、NATは、このようなトポロジ隠蔽など、いくつかの政策目標を満たすん。同時に、それは、ネットワークレベルでのエンドツーエンドの監査証跡を生成する能力のような他のものを、敗北します。それは言った、いくつかの値を提供しないNATデバイスのアーティファクトがあります。
1. The need to establish state before anything gets through from outside to inside solves one set of problems.
1.何が外側から内側に通じ取得する前の状態を確立する必要性は、問題の1セットを解決します。
2. The expiration of state to stop receiving any packets when finished with a flow solves a set of problems.
2.フローを終了したときに任意のパケットの受信を停止する状態の有効期限は、問題のセットを解決します。
3. The ability for nodes to appear to be attached at the edge of the network solves a set of problems.
前記ノードは、ネットワークのエッジに取り付けられるように表示するための能力は問題のセットを解決します。
4. The ability to have addresses that are not publicly routed solves yet another set (mostly changes where the state is and scale requirements for the first one).
4.公的にルーティングされていないアドレスを有する能力は、さらに別のセット（ほとんどの状態は変化し、第1のスケール要件）を解きます。
This document describes several techniques that may be combined in an IPv6 deployment to protect the integrity of its network architecture. It will focus on the 'how to accomplish a goal' perspective, leaving most of the 'why that goal is useful' perspective for other documents. These techniques, known collectively as Local Network Protection (LNP), retain the concept of a well-defined boundary between "inside" and "outside" the private network, while allowing firewalling, topology hiding, and privacy. LNP will achieve these security goals without address translation while regaining the ability for arbitrary any-to-any connectivity.
この文書では、そのネットワークアーキテクチャの整合性を保護するためのIPv6展開で組み合わせることができるいくつかの手法について説明します。これは、他の文書に「そのゴールが有用である理由の視点のほとんどを残し、「目標を達成する方法の視点に焦点を当てます。ファイアウォール、トポロジ隠蔽、およびプライバシーを可能にしながら、ローカルネットワーク保護（LNP）と総称されるこれらの技術は、「内部」及び「外部」のプライベートネットワークとの間の明確に定義された境界の概念を保持します。任意の任意の-to-anyの接続のための能力を取り戻しながら、LNPは、アドレス変換せずにこれらのセキュリティ目標を達成します。
IPv6 Local Network Protection can be summarized in the following table. It presents the marketed benefits of IPv4+NAT with a cross-reference of how those are delivered in both the IPv4 and IPv6 environments.
IPv6のローカルネットワークの保護は、以下の表にまとめることができます。これは、これらは、IPv4とIPv6の両方の環境で配信されているかの相互参照したIPv4 + NATの販売利益を提示します。
Goal IPv4 IPv6
+------------------+-----------------------+-----------------------+
| Simple Gateway | DHCP - single | DHCP-PD - arbitrary |
| as default router| address upstream | length customer |
| and address pool | DHCP - limited | prefix upstream |
| manager | number of individual | SLAAC via RA |
| | devices downstream | downstream |
| | see Section 2.1 | see Section 4.1 |
+------------------|-----------------------|-----------------------+
| Simple Security | Filtering side | Explicit Context |
| | effect due to lack | Based Access Control |
| | of translation state | (Reflexive ACL) |
| | see Section 2.2 | see Section 4.2 |
+------------------|-----------------------|-----------------------+
| Local Usage | NAT state table | Address uniqueness |
| Tracking | | |
| | see Section 2.3 | see Section 4.3 |
+------------------|-----------------------|-----------------------+
| End-System | NAT transforms | Temporary use |
| Privacy | device ID bits in | privacy addresses |
| | the address | |
| | see Section 2.4 | see Section 4.4 |
+------------------|-----------------------|-----------------------+
| Topology Hiding | NAT transforms | Untraceable addresses|
| | subnet bits in the | using IGP host routes|
| | address | /or MIPv6 tunnels |
| | see Section 2.4 | see Section 4.4 |
+------------------|-----------------------|-----------------------+
| Addressing | RFC 1918 | RFC 3177 & 4193 |
| Autonomy | see Section 2.5 | see Section 4.5 |
+------------------|-----------------------|-----------------------+
| Global Address | RFC 1918 | 17*10^18 subnets |
| Pool | << 2^48 application | 3.4*10^38 addresses |
| Conservation | end points | full port list / addr |
| | topology restricted | unrestricted topology |
| | see Section 2.6 | see Section 4.6 |
+------------------|-----------------------|-----------------------+
| Renumbering and | Address translation | Preferred lifetime |
| Multihoming | at border | per prefix & multiple|
| | | addresses per |
| | | interface |
| | see Section 2.7 | see Section 4.7 |
+------------------+-----------------------+-----------------------+
This document first identifies the perceived benefits of NAT in more detail, and then shows how IPv6 LNP can provide each of them. It concludes with an IPv6 LNP case study and a gap analysis of standards work that remains to be done for an optimal LNP solution.
この文書では、最初に、より詳細にNATの知覚の利点を識別し、その後、IPv6のLNPは、それらのそれぞれを提供する方法を示しています。これは、IPv6 LNPのケーススタディと最適LNPソリューションのために行われるように残っている標準作業のギャップ分析と結論します。
This section provides insight into the generally perceived benefits of the use of IPv4 NAT. The goal of this description is not to analyze these benefits or the accuracy of the perception (detailed discussions in [4]), but to describe the deployment requirements and set a context for the later descriptions of the IPv6 approaches for dealing with those requirements.
このセクションでは、IPv4 NATの使用の一般的認知メリットへの洞察を提供します。この説明の目的は、これらの利点や知覚の精度が、展開の要件を記述するとIPv6の後の説明のためのコンテキストを設定することは、これらの要件に対処するためのアプローチ（[4]で詳細な議論を）分析することではありません。
A NAT device can connect a private network with addresses allocated from any part of the space (ambiguous [1]or global registered and unregistered addresses) towards the Internet, though extra effort is needed when the same range exists on both sides of the NAT. The address space of the private network can be built from globally unique addresses, from ambiguous address space, or from both simultaneously. In the simple case of private use addresses, without needing specific configuration the NAT device enables access between the client side of a distributed client-server application in the private network and the server side located in the public Internet.
同じ範囲のNATの両側に存在するときに余分な努力が必要とされているがNATデバイスは、インターネットに向かって空間（曖昧[1]またはグローバル登録未登録のアドレス）のいずれかの部分から割り当てられたアドレスとプライベートネットワークに接続することができます。プライベートネットワークのアドレス空間が同時に曖昧なアドレス空間から、あるいはその両方から、グローバルに一意なアドレスから構築することができます。私的使用のアドレスのような単純なケースでは、特定の構成を必要とせずにNATデバイスは、プライベートネットワーク内の分散型クライアントサーバーアプリケーションのクライアント側と公共のインターネットにあるサーバ側との間のアクセスを可能にします。
Wide-scale deployments have shown that using NAT to act as a simple gateway attaching a private IPv4 network to the Internet is simple and practical for the non-technical end user. Frequently, a simple user interface or even a default configuration is sufficient for configuring both device and application access rights.
大規模な展開では、インターネットにプライベートIPv4ネットワークを取り付ける簡単なゲートウェイとして機能するようにNATを使用すると、非技術的なエンドユーザーのためのシンプルで実用的であることを示しています。しばしば、シンプルなユーザーインターフェース、あるいはデフォルトの設定では、両方のデバイスとアプリケーションへのアクセス権を設定するために十分です。
This simplicity comes at a price, as the resulting topology puts restrictions on applications. The NAT simplicity works well when the applications are limited to a client/server model with the server deployed on the public side of the NAT. For peer-to-peer, multi-party, or servers deployed on the private side of the NAT, helper technologies must also be deployed. These helper technologies are frequently complex to develop and manage, creating a hidden cost to this 'simple gateway'.
結果のトポロジはアプリケーションに制限を置くように、このシンプルさは、代償します。アプリケーションはNATのパブリック側に配置されたサーバとのクライアント/サーバモデルに限定されているとき、NATシンプルさがうまく動作します。ピア・ツー・ピア、マルチパーティ、またはNATのプライベート側に展開されたサーバーの場合は、ヘルパーの技術も展開する必要があります。これらのヘルパーの技術は、この「簡単なゲートウェイ」に隠されたコストを作成し、開発し、管理することが頻繁に複雑です。
It is frequently believed that through its session-oriented operation, NAT puts in an extra barrier to keep the private network protected from outside influences. Since a NAT device typically keeps state only for individual sessions, attackers, worms, etc., cannot exploit this state to attack a specific host on any other port. However, in the port overload case of Network Address Port Translation (NAPT) attacking all active ports will impact a potentially wide number of hosts. This benefit may be partially real; however, experienced hackers are well aware of NAT devices and are very familiar with private address space, and they have devised methods of attack (such as trojan horses) that readily penetrate NAT boundaries. While the stateful filtering offered by NAT offers a measure of protection against a variety of straightforward network attacks, it does not protect against all attacks despite being presented as a one-size-fits-all answer.
頻繁にセッション指向の操作を通じて、NATは外部の影響から保護されたプライベートネットワークを維持するために、余分なバリアを入れていると考えられます。 NATデバイスは、典型的には、個々のセッションなど、攻撃、ワーム、のみの状態を維持しているため、他のポート上の特定のホストを攻撃するために、この状態を悪用することはできません。しかし、ネットワークのポート過負荷の場合にはすべてのアクティブポートはホストの潜在的に広い数に影響を与える攻撃ポート変換（NAPT）をアドレス。この利点は、部分的に本当であってもよく、しかし、経験豊富なハッカーは、NATデバイスをよく知っており、プライベートアドレス空間に非常に精通している、と彼らは容易にNAT境界を貫く（例えばトロイの木馬など）、攻撃の方法を考案しました。 NATが提供するステートフルなフィルタリングが簡単なネットワークのさまざまな攻撃に対する保護の措置を提供していますが、それはフリーサイズ答えとして提示されているにもかかわらず、すべての攻撃を防ぐことはできません。
The act of translating address bits within the header does not provide security in itself. For example, consider a configuration with static NAT and all inbound ports translating to a single machine. In such a scenario, the security risk for that machine is identical to the case with no NAT device in the communication path, as any connection to the public address will be delivered to the mapped target.
ヘッダ内のアドレスビットを変換する行為自体のセキュリティを提供しません。例えば、スタティックNATおよび単一のマシンに変換するすべての着信ポートを備えた構成を考えます。パブリックアドレスへの接続がマッピングされたターゲットに配信されるようなシナリオでは、そのマシンのセキュリティリスクは、通信パスにNATデバイスの場合と同じです。
The perceived security of NAT comes from the lack of pre-established or permanent mapping state. This is often used as a 'better than nothing' level of protection because it doesn't require complex management to filter out unwanted traffic. Dynamically establishing state in response to internal requests reduces the threat of unexpected external connections to internal devices, and this level of protection would also be available from a basic firewall. (A basic firewall, supporting clients accessing public side servers, would improve on that level of protection by avoiding the problem of state persisting as different clients use the same private side address over time.) This role, often marketed as a firewall, is really an arbitrary artifact, while a real firewall often offers explicit and more comprehensive management controls.
NATの知覚セキュリティは、事前に確立されたか、永久的なマッピング状態の欠如から来ています。それは、不要なトラフィックをフィルタリングするために複雑な管理を必要としないため、これは多くの場合、保護の「何もないよりはまし」レベルとして使用されています。動的内部の要求に応じて、状態を確立することは、内部デバイスへの予期せぬ外部接続の脅威を減少させ、そしてこのレベルの保護は、基本的なファイアウォールから利用できるようになります。 （基本的なファイアウォール、公共側のサーバにアクセスするクライアントをサポートし、さまざまなクライアントが時間をかけて同じプライベート側のアドレスを使用して持続する状態の問題を回避することにより、保護の水準に改善するだろう。）この役割を、多くの場合、ファイアウォールとして販売、実際にあります任意のアーティファクト、本当のファイアウォールは、多くの場合、明示的な、より包括的な管理統制をご用意しています。
In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case, the NAT actually adds management complexity compared to the simple router discussed in Section 2.1. In situations where two or more devices need to host the same application or otherwise use the same public port, this complexity shifts from difficult to impossible.
いくつかのケースでは、（国内のユーザーを含む）NAT事業者は、ローカルなマルチプレイヤーゲームなどのアプリケーションやWebサーバへの外部アクセスを許可するように、非常に複雑なポートマッピング規則を設定する義務を負うことができます。この場合、NATは、実際には2.1節で述べたシンプルなルータに比べて管理の複雑さを追加します。二つ以上のデバイスが同じアプリケーションをホストするか、そうでない場合は、同じパブリックポートを使用する必要がある状況では、この複雑さは、困難から不可能に移行します。
One usage of NAT is for the local network administrator to track user and application traffic. Although NATs create temporary state for active sessions, in general they provide limited capabilities for the administrator of the NAT to gather information about who in the private network is requesting access to which Internet location. This is done by periodically logging the network address translation details of the private and the public addresses from the NAT device's state database.
NATの一つの使用は、ユーザーとアプリケーションのトラフィックを追跡するために、ローカルネットワーク管理者のためです。 NATのは、アクティブなセッションのために一時的な状態を作成しますが、一般的に彼らは、インターネットの場所へのアクセスを要求しているプライベートネットワーク内の誰についての情報を収集するためにNATの管理者のための限られた機能を提供します。これは、定期的にNATデバイスの状態データベースからプライベートとパブリックアドレスのネットワークアドレス変換の詳細をロギングすることで行われます。
The subsequent checking of this database is not always a simple task, especially if Port Address Translation is used. It also has an unstated assumption that the administrative instance has a mapping between a private IPv4-address and a network element or user at all times, or the administrator has a time-correlated list of the address/port mappings.
このデータベースのその後のチェックは、ポートアドレス変換が使用されている場合は特に、常に簡単な作業ではありません。また、行政のインスタンスは常にプライベートIPv4アドレスおよびネットワーク要素や、ユーザー間のマッピングを持っている、または管理者がアドレス/ポートマッピングの時間相関リストを持っていることを暗黙の前提があります。
One goal of 'topology hiding' is to prevent external entities from making a correlation between the topological location of devices on the local network. The ability of NAT to provide Internet access to a large community of users by the use of a single (or a few) globally routable IPv4 address(es) offers a simple mechanism to hide the internal topology of a network. In this scenario, the large community will be represented in the Internet by a single (or a few) IPv4 address(es).
「トポロジ隠蔽」の1つの目標は、ローカルネットワーク上のデバイスの位相的な位置との相関関係を作るから外部エンティティを防ぐためです。単一（または少数の）グローバルにルーティング可能なIPv4アドレス（複数可）を使用して、ユーザーの大規模なコミュニティへのインターネットアクセスを提供するために、NATの能力は、ネットワークの内部トポロジを隠すための簡単なメカニズムを提供しています。このシナリオでは、大規模なコミュニティは、単一の（または少数）のIPv4アドレス（複数可）で、インターネットに代表されます。
By using NAT, a system appears to the Internet as if it originated inside the NAT box itself; i.e., the IPv4 address that appears on the Internet is only sufficient to identify the NAT so all internal nodes appear to exist at the demarcation edge. When concealed behind a NAT, it is impossible to tell from the outside which member of a family, which customer of an Internet cafe, or which employee of a company generated or received a particular packet. Thus, although NATs do nothing to provide application level privacy, they do prevent the external tracking and profiling of individual systems by means of their IP addresses, usually known as 'device profiling'.
それは、NATボックス自体の内部で発信しているかのようNATを使用することにより、システムがインターネットに表示されます。即ち、インターネット上で表示されるIPv4アドレスがので、すべての内部ノードは、境界エッジに存在するように見えるNATを識別するだけで十分です。 NATの背後に隠された場合、どのメンバーの家族の外に、インターネットカフェの顧客、またはその会社の従業員が生成したり、特定のパケットを受信から伝えることは不可能です。 NATのは、アプリケーション・レベルのプライバシーを提供するために何もしないが、このように、彼らは通常、「デバイスプロファイル」として知られているIPアドレスの手段によって外部の追跡および個々のシステムのプロファイリングを防止します。
There is a similarity with privacy based on application level proxies. When using an application level gateway for browsing the web for example, the 'privacy' of a web user can be provided by masking the true identity of the original web user towards the outside world (although the details of what is -- or is not -- logged at the NAT/proxy will be different).
アプリケーションレベルのプロキシに基づいて、プライバシーとの類似性があります。例えばウェブを閲覧するためのアプリケーションレベルゲートウェイを使用する場合は、Webユーザの「プライバシー」は何であるかの詳細が、（外の世界に向けたオリジナルのWebユーザーの本当のアイデンティティをマスキングすることによって提供することができます - かではありません - NATで記録/プロキシ）が異なることになります。
Some network managers prefer to hide as much as possible of their internal network topology from outsiders as a useful precaution to mitigate scanning attacks. Mostly, this is achieved by blocking "traceroute", etc., though NAT entirely hides the internal subnet topology. Scanning is a particular concern in IPv4 networks because the subnet size is small enough that once the topology is known, it is easy to find all the hosts, then start scanning them for vulnerable ports. Once a list of available devices has been mapped, a port-scan on these IP addresses can be performed. Scanning works by tracking which ports do not receive unreachable errors from either the firewall or host. With the list of open ports, an attacker can optimize the time needed for a successful attack by correlating it with known vulnerabilities to reduce the number of attempts. For example, FTP usually runs on port 21, and HTTP usually runs on port 80. Any vulnerable open ports could be used for access to an end-system to command it to start initiating attacks on others.
一部のネットワーク管理者は、スキャン攻撃を軽減するために便利な予防措置として、部外者から自分の内部ネットワークトポロジのできるだけ多くを隠すことを好みます。ほとんどの場合、これは、NATは完全に内部サブネットトポロジーを隠しても、など、「トレースルート」をブロックすることにより達成されます。サブネットサイズは、トポロジが知られたら、脆弱なポートのためにそれらのスキャンを開始、その後、すべてのホストを見つけるのは簡単であることを十分に小さいので、スキャンはIPv4ネットワークでは特に問題です。使用可能なデバイスのリストがマッピングされたら、これらのIPアドレスのポートスキャンを実行することができます。スキャンは、ポートがファイアウォールまたはホストのいずれかから到達不能エラーを受信しません追跡することによって動作します。開いているポートのリストを使用すると、攻撃者は、試行回数を減らすために既知の脆弱性とそれを相関させることにより、攻撃が成功するために必要な時間を最適化することができます。たとえば、FTPは、通常はポート21上で実行され、HTTPは通常、任意の脆弱開いているポートが他の人への攻撃を開始する開始することを命令するエンドシステムへのアクセスに使用することができ、ポート80上で実行されます。
Many private IPv4 networks make use of the address space defined in RFC 1918 to enlarge the available addressing space for their private network, and at the same time reduce their need for globally routable addresses. This type of local control of address resources allows a sufficiently large pool for a clean and hierarchical addressing structure in the local network.
多くのプライベートIPv4ネットワークは、RFC 1918で定義されたアドレス空間の使用は彼らのプライベートネットワークで利用可能なアドレス空間を拡大すると同時に、グローバルにルーティング可能なアドレスのための彼らの必要性を減らすために作ります。アドレスリソースのローカル制御のこのタイプは、ローカルネットワークにきれいで、階層的なアドレス指定の構造のための十分な大きさのプールを可能にします。
Another benefit is the ability to change providers with minimal operational difficulty due to the usage of independent addresses on a majority of the network infrastructure. Changing the addresses on the public side of the NAT avoids the administrative challenge of changing every device in the network.
もう一つの利点は、ネットワークインフラの大部分に独立したアドレスの使用を最小限に抑え、動作困難でプロバイダを変更する機能です。 NATのパブリック側のアドレスを変更すると、ネットワーク内のすべてのデバイスを変更する行政課題を回避することができます。
Section 2.7 describes some disadvantages that appear if independent networks using ambiguous addresses [1] have to be merged.
2.7節は、あいまいなアドレスを使用して独立したネットワークは、[1]マージする必要がある場合に表示され、いくつかの欠点を説明します。
While the widespread use of IPv4+NAT has reduced the potential consumption rate, the ongoing depletion of the IPv4 address range has already taken the remaining pool of unallocated IPv4 addresses well below 20%. While mathematical models based on historical IPv4 prefix consumption periodically attempt to predict the future exhaustion date of the IPv4 address pool, a possible result of this continuous resource consumption is that the administrative overhead for acquiring globally unique IPv4 addresses will at some point increase noticeably due to tightening allocation policies.
IPv4の+ NATの広範な使用は、潜在的な消費率を低減したが、IPv4アドレス範囲の継続的な枯渇は既に未割り当てのIPv4の残りのプールはウェル20％未満に対処取りました。歴史のIPv4プレフィックスの消費量に基づいて数学モデルは、定期的にIPv4アドレスプールの将来の枯渇時期を予測しようが、この連続したリソース消費の可能な結果があることに起因して著しくいくつかのポイントの増加で、グローバルにユニークなIPv4アドレス意志を取得するための管理オーバーヘッド割り当てポリシーを締めます。
In response to the increasing administrative overhead, many Internet Service Providers (ISPs) have already resorted to the ambiguous addresses defined in RFC 1918 behind a NAT for the various services they provide as well as connections for their end customers. This happens even though the private use address space is strictly limited in size. Some deployments have already outgrown that space and have begun cascading NAT to continue expanding, though this practice eventually breaks down over routing ambiguity. Additionally, while we are unlikely to know the full extent of the practice (because it is hidden behind a NAT), service providers have been known to announce previously unallocated public space to their customers (to avoid the problems associated with the same address space appearing on both sides), only to find that once that space was formally allocated and being publicly announced, their customers couldn't reach the registered networks.
増加管理オーバーヘッドを受けて、多くのインターネット・サービス・プロバイダ（ISP）は、すでにあいまいな彼らが提供する様々なサービスのためのNATの背後にあるRFC 1918で定義されたアドレスだけでなく、そのエンドユーザーの接続に頼ってきました。これは、私的使用のアドレス空間が厳しくサイズに制限されていても発生します。いくつかの展開は、すでにそのスペースを手狭にしていると、このような行為は、最終的には、ルーティングのあいまいさの上にブレークダウンしても、引き続き拡大するNATをカスケード接続し始めています。私たちは練習の全範囲を（それがNATの背後に隠されているので）知っている可能性は低いながらさらに、サービスプロバイダは、（表示されて同じアドレス空間に関連する問題を回避するために、顧客に事前に割り当てられていない公共空間を発表することが知られています）両側に、それだけでスペースが正式に割り当てられたと公表された後、顧客が登録されたネットワークに到達できなかったことを見つけるために。
The number of and types of applications that can be deployed by these ISPs and their customers are restricted by the ability to overload the port range on the public side of the most public NAT in the path. The limit of this approach is something substantially less than 2^48 possible active *application* endpoints (approximately [2^32 minus 2^29] * [2* 2^16 minus well-known port space]), as distinct from addressable devices each with its own application endpoint range. Those who advocate layering of NAT frequently forget to mention that there are topology restrictions placed on the applications. Forced into this limiting situation, such customers can rightly claim that despite the optimistic predictions of mathematical models, the global pool of IPv4 addresses is effectively already exhausted.
数と、これらのISPとその顧客によって展開することができるアプリケーションの種類は、パスの中で最も公共NATのパブリック側のポート範囲をオーバーロードする能力によって制限されています。このアプローチの限界は、実質的により少ない2 ^ 48の可能なアクティブ・アプリケーション・エンドポイント（約[2 ^ 32マイナス2 ^ 29] * [2 * 2 ^ 16マイナス周知ポートスペース]）、アドレス可能とは異なるようなものです独自のアプリケーション・エンドポイントの範囲を持つデバイスそれぞれ。 NATのレイヤーを提唱する者は、頻繁にアプリケーションに配置され、トポロジーの制限があることを言及するのを忘れています。この制限状況に追い込ま、こうした顧客は当然数学モデルの楽観的な予測にもかかわらず、IPv4アドレスのグローバルプールはすでに効果的に消耗していると主張することができます。
Allowing a network to be multihomed and renumbering a network are quite different functions. However, these are argued together as reasons for using NAT, because making a network multihomed is often a transitional state required as part of network renumbering, and NAT interacts with both in the same way.
ネットワークがマルチホームできるように、ネットワークをリナンバリングは全く異なる機能です。マルチホームネットワークを作ることは、多くの場合、ネットワークのリナンバリングの一部として必要な過渡的な状態であり、NATは両方と同じように相互作用しているためしかし、これらは、NATを使用する理由として一緒に論じています。
For enterprise networks, it is highly desirable to provide resiliency and load-balancing to be connected to more than one Internet Service Provider (ISP) and to be able to change ISPs at will. This means that a site must be able to operate under more than one Classless Inter-Domain Routing (CIDR) prefix [18] and/or readily change its CIDR prefix. Unfortunately, IPv4 was not designed to facilitate either of these maneuvers. However, if a site is connected to its ISPs via NAT boxes, only those boxes need to deal with multihoming and renumbering issues.
企業ネットワークのために、それは弾力性とを提供することが強く望まれているロードバランシング複数のインターネットサービスプロバイダ（ISP）に接続されると意志でのISPを変更できるようにします。これは、サイトが複数のクラスレスドメイン間ルーティング（CIDR）の接頭辞[18]および/または容易に変更そのCIDRプレフィックスの下で動作することができなければならないことを意味します。残念ながら、IPv4のは、これらの操作のいずれかを容易にするように設計されていません。サイトはNATボックスを介して、そのISPに接続している場合は、のみボックスはマルチホーミングとリナンバリング問題に対処する必要があります。
Similarly, if two enterprise IPv4 networks need to be merged and RFC 1918 addresses are used, there is a high probability of address overlaps. In those situations, it may well be that installing a NAT box between them will avoid the need to renumber one or both. For any enterprise, this can be a short-term financial saving and allows more time to renumber the network components. The long-term solution is a single network without usage of NAT to avoid the ongoing operational complexity of overlapping addresses.
2つのエンタープライズのIPv4ネットワークをマージするとRFC 1918のアドレスを使用する必要がある場合は同様に、アドレス重複の可能性が高いです。それらの状況では、それは十分にそれらの間のNATボックスを設置することは、一方または両方の番号を変更する必要性を回避することかもしれません。あらゆる企業にとって、これは短期的な財政省可能とネットワークコンポーネントの番号を変更するために多くの時間を可能にすることができます。長期的な解決策は、アドレスの重複の継続的な運用の複雑さを避けるために、NATの使用せずに単一のネットワークです。
The addition of an extra NAT as a solution may be sufficient for some networks; however, when the merging networks were already using address translation it will create major problems due to administrative difficulties of overlapping address spaces in the merged networks.
溶液として余分なNATの添加は、いくつかのネットワークのために十分であり得ます。しかし、時にマージのネットワークはすでにそれがマージされたネットワークでのアドレス空間の重複行政困難に起因する重大な問題を作成するアドレス変換を使用していました。
This section describes several features that can be used as part of the LNP solution to replace the protection features associated with IPv4 NAT.
このセクションでは、IPv4 NATに関連した保護機能を置き換えるためにLNPソリューションの一部として使用することができますいくつかの機能について説明します。
The reader must clearly distinguish between features of IPv6 that were fully defined when this document was drafted and those that were potential features that still required more work to define them. The latter are summarized later in the 'Gap Analysis' section of this document. However, we do not distinguish in this document between fully defined features of IPv6 and those that were already widely implemented at the time of writing.
読者は明らかに完全にこの文書が起草された時に定義されており、まだそれらを定義するために多くの作業を必要と潜在的な機能だったものられたのIPv6の機能を区別しなければなりません。後者は、このドキュメントの「ギャップ分析」セクションの後半で要約されています。しかし、我々は完全に定義されたIPv6の機能や、すでに広く執筆の時点で実施されたものとの間に、このドキュメントでは区別しません。
There are situations where it is desirable to prevent device profiling, for example, by web sites that are accessed from the device as it moves around the Internet. IPv6 privacy addresses were defined to provide that capability. IPv6 addresses consist of a routing prefix, a subnet-id (SID) part, and an interface identifier (IID) part. As originally defined, IPv6 stateless address auto-configuration (SLAAC) will typically embed the IEEE Link Identifier of the interface as the IID part, though this practice facilitates tracking and profiling of a device through the consistent IID. RFC 3041 [7] describes an extension to SLAAC to enhance device privacy. Use of the privacy address extension causes nodes to generate global-scope addresses from interface identifiers that change over time, consistent with system administrator policy. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the effect of reducing the attack profile of a device, as it is not directly attackable once it stops answering at the temporary use address.
インターネットの周りに移動すると、デバイスからアクセスされたウェブサイトによって、例えば、デバイスプロファイリングを防止することが望ましい状況があります。 IPv6のプライバシーアドレスがその機能を提供するために定義されていました。 IPv6アドレスは、ルーティングプレフィックス、サブネットID（SID）部分、およびインタフェース識別子（IID）部分から成ります。元々定義されているようにこのような行為が一致IIDを介してデバイスのトラッキングとプロファイリングを容易にするが、IPv6ステートレスアドレス自動設定（SLAAC）は、典型的には、IIDの一部としてインターフェースのIEEEリンク識別子を埋め込むことであろう。 RFC 3041 [7]は、デバイスのプライバシーを強化するためにSLAACの拡張について説明します。プライバシーのアドレス拡張を使用すると、ノードは、システム管理者の方針と整合時間の経過とともに変化するインタフェース識別子からグローバルスコープのアドレスを発生させます。経時的な（したがって、グローバルスコープのアドレスがそれから生成された）インタフェース識別子を変更すると、異なるトランザクションに使用されるアドレスは、実際には同じノードに対応する場合に同定する盗聴者や他の情報収集のためにそれをより困難にします。それは一時的な使用のアドレスに応答を停止したら、それは直接攻撃可能ではないとして、プライバシーアドレスの比較的短い有効期間はまた、デバイスの攻撃プロファイルを減少させる効果を有します。
While the primary implementation and source of randomized RFC 3041 addresses are expected to be from end-systems running stateless auto-configuration, there is nothing that prevents a Dynamic Host Configuration Protocol (DHCP) server from running the RFC 3041 algorithm for any new IEEE identifier it hears in a request, then remembering that for future queries. This would allow using them in DNS for registered services since the assumption of a DHCP server-based deployment would be a persistent value that minimizes DNS churn. A DHCP-based deployment would also allow for local policy to periodically change the entire collection of end-device addresses while maintaining some degree of central knowledge and control over which addresses should be in use at any point in time.
ランダム化されたRFCの主な実装とソースが3041個のアドレスがステートレス自動設定を実行しているエンドシステムからなることが予想されますが、すべての新しいIEEE識別子のためのRFC 3041のアルゴリズムを実行しているから、DHCP（Dynamic Host Configuration Protocol）サーバを防ぐものはありませんそれは、将来のクエリのためにそれを思い出して、要求に聞きます。 DHCPサーバーベースの展開の前提は、DNSの解約を最小限に永続値になりますので、これは登録されたサービスのためにDNSでそれらを使用できるようになります。 DHCPベースの展開は、中央知識と、任意の時点で使用中であるべきアドレスの制御をある程度維持しながら、ローカルポリシーは、定期的にエンドデバイスアドレスのコレクション全体を変更することを可能にするであろう。
Randomizing the IID, as defined in RFC 3041, is effectively a sparse allocation technique that only precludes tracking of the lower 64 bits of the IPv6 address. Masking of the subnet ID will require additional approaches as discussed below in Section 3.4. Additional considerations are discussed in [19].
IIDをランダム化、RFC 3041で定義されるように、効果的にのみIPv6アドレスの下位64ビットのトラッキングを妨げるスパース割り当て技術です。 3.4節で以下に説明するように、サブネットIDのマスキングは、追加的なアプローチが必要になります。その他の考慮事項は、[19]で議論されています。
Achieving the goal of autonomy, that many perceive as a value of NAT, is required for local network and application services stability during periods of intermittent connectivity or moving between one or more providers. Such autonomy in a single routing prefix environment would lead to massive expansion of the global routing tables (as seen in IPv4), so IPv6 provides for simultaneous use of multiple prefixes. The Unique Local Address (ULA) prefix [17] has been set aside for use in local communications. The ULA prefix for any network is routable over a locally defined collection of routers. These prefixes are not intended to be routed on the public global Internet as large-scale inter-domain distribution of routes for ULA prefixes would have a negative impact on global route aggregation.
多くはNATの値として認識することを、自律性の目標を達成するため、断続的な接続の期間中、ローカルネットワークおよびアプリケーション・サービスの安定性のために必要な1つのまたは複数のプロバイダ間で移動されます。 IPv6は複数のプレフィックスの同時使用を提供するように、単一のルーティングプレフィックス環境におけるそのような自律性は、（IPv4のに見られるように）グローバルルーティングテーブルの大規模な拡大につながります。ユニークローカルアドレス（ULA）接頭辞[17]はローカル通信での使用のために確保されています。任意のネットワークのためのULAプリフィックスをルータのローカルに定義されたコレクションのルーティング可能です。これらのプレフィックスは、グローバルルート集約に負の影響を有するであろうULAプリフィックスのための経路の大規模なドメイン間ディストリビューションとして公共のグローバルインターネット上でルーティングすることを意図するものではありません。
ULAs have the following characteristics:
ULAsは、次の特性があります。
o For all practical purposes, a globally unique prefix
すべての実用的な目的のために、O、グローバルに一意の接頭辞
* allows networks to be combined or privately interconnected without creating address conflicts or requiring renumbering of interfaces using these prefixes, and
*ネットワークがアドレスの競合を作成したり、これらのプレフィックスを使用して、インタフェースのリナンバリングを必要とすることなく、組み合わせまたは個人に相互接続されることを可能にする、及び
* if accidentally leaked outside of a network via routing or DNS, is highly unlikely that there will be a conflict with any other addresses.
誤ってルーティングやDNSを介してネットワークの外に漏れた場合*、任意の他のアドレスと競合が発生する可能性はほとんどありません。
o They are ISP independent and can be used for communications inside of a network without having any permanent or only intermittent Internet connectivity.
Oそれらは独立ISPであり、任意の永久的または断続のみインターネット接続を有することなく、ネットワーク内の通信のために使用することができます。
o They have a well-known prefix to allow for easy filtering at network boundaries preventing leakage of routes and packets that should remain local.
O彼らは地元の残るべきルートやパケットの漏洩を防止するネットワークの境界でフィルタリングが容易を可能にするために、よく知られている接頭辞を持っています。
o In practice, applications may treat these addresses like global-scope addresses, but address selection algorithms may need to distinguish between ULAs and ordinary global-scope unicast addresses to ensure stability. The policy table defined in [11] is one way to bias this selection, by giving higher preference to FC00::/7 over 2001::/3. Mixing the two kinds of addresses may lead to undeliverable packets during times of instability, but that mixing is not likely to happen when the rules of RFC 3484 are followed.
O実際には、アプリケーションは、グローバルスコープのアドレスのようなこれらのアドレスを扱うことができるが、アドレス選択アルゴリズムは、安定性を確保するULAs通常のグローバルスコープユニキャストアドレスを区別する必要があるかもしれません。 [11]で定義されたポリシーテーブル2001 :: / 3上FC00 :: / 7より高い優先度を与えることによって、バイアスに一方向この選択です。アドレスの二種類を混合して不安定な時期に配信不能パケットをもたらすが、その混合は、RFC 3484のルールに従っている場合に発生する可能性がないことができます。
o ULAs have no intrinsic security properties. However, they have the useful property that their routing scope is limited by default within an administrative boundary. Their usage is suggested at several points in this document, as a matter of administrative convenience.
O ULAsには固有のセキュリティプロパティを持っていません。しかし、彼らは彼らのルーティング範囲が行政境界内にデフォルトで制限された有用な性質を持っています。その使用法は、行政利便性の問題として、この文書に記載されているいくつかの点で示唆されました。
One of the functions of a simple gateway is managing the local use address range. The Prefix Delegation (DHCP-PD) options [12] provide a mechanism for automated delegation of IPv6 prefixes using the DHCP [10]. This mechanism (DHCP-PD) is intended for delegating a long-lived prefix from a delegating router (possibly incorporating a DHCPv6 server) to a requesting router, possibly across an administrative boundary, where the delegating router does not require knowledge about the topology of the links in the network to which the prefixes will be assigned.
簡単なゲートウェイの機能の一つは、ローカル使用アドレス範囲を管理しています。プレフィックス委任（DHCP-PD）オプション[12] DHCP [10]を使用して、IPv6プレフィックスの自動委譲するためのメカニズムを提供します。このメカニズム（DHCP-PD）は、おそらく委譲ルータはのトポロジーに関する知識を必要としない管理境界にまたがって、要求元のルータに（おそらくDHCPv6サーバを組み込んでいる）委任ルータから長寿命のプレフィックスを委任するためのものですプレフィックスが割り当て先となるネットワーク内のリンク。
The main goal of untraceable IPv6 addresses is to create an apparently amorphous network infrastructure, as seen from external networks, to protect the local infrastructure from malicious outside influences and from mapping of any correlation between the network activities of multiple devices from external networks. When using untraceable IPv6 addresses, it could be that two apparently sequential addresses are allocated to devices on very different parts of the local network instead of belonging to devices adjacent to each other on the same subnet.
追跡不可能なIPv6アドレスの主な目標は、悪意のある外部の影響から、外部ネットワークから複数のデバイスのネットワーク活動との間の相関関係のマッピングから地域のインフラを保護するために、外部ネットワークから見て、明らかにアモルファスネットワークインフラストラクチャを作成することです。追跡不可能なIPv6アドレスを使用する場合、これは、2つの明らかに連続したアドレスではなく、同じサブネット上の互いに隣接装置に属するローカルネットワークの非常に異なる部分上のデバイスに割り当てられていることとすることができます。
Since IPv6 addresses will not be in short supply even within a single /64 (or shorter) prefix, it is possible to generate them effectively at random when untraceability is required. They will be globally routable IPv6 addresses under the site's prefix, which can be randomly and independently assigned to IPv6 devices. The random assignment is intended to mislead the outside world about the structure of the local network. In particular, the subnet structure may be invisible in the address. Thus, a flat routing mechanism will be needed within the site. The local routers need to maintain a correlation between the topological location of the device and the untraceable IPv6 address. For smaller deployments, this correlation could be done by generating IPv6 host route entries, or for larger ones by utilizing an indirection device such as a Mobile IPv6 Home Agent. Additional details are in Section 4.7.
IPv6アドレスが1つでも/ 64（または短い）プレフィックス内供給不足になりませんので、アントレーサビリティが要求されたときにランダムにそれらを効果的に生成することが可能です。彼らは、ランダムにかつ独立にIPv6デバイスに割り当てることができ、サイトの接頭辞、下グローバルにルーティング可能なIPv6アドレスになります。ランダムな割り当ては、ローカルネットワークの構造について、外の世界を欺くことを意図しています。特に、サブネット構造は、アドレスに不可視であってもよいです。このように、フラットなルーティングメカニズムは、サイト内で必要とされるであろう。ローカルルータは、デバイスの位相的な位置および追跡不可能なIPv6アドレスとの間の相関関係を維持する必要があります。小さい展開では、この相関関係は、IPv6ホストルートエントリを生成することによって、以上のもののために、このようなモバイルIPv6ホームエージェントとして間接装置を利用することによって行うことができます。その他の詳細は、セクション4.7です。
4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT
4. NATの市場知覚の利点を提供するIPv6の技術を使用しました
The facilities in IPv6 described in Section 3 can be used to provide the protection perceived to be associated with IPv4 NAT. This section gives some examples of how IPv6 can be used securely.
セクション3に記載のIPv6の施設は、IPv4 NATに関連することが知覚保護を提供するために使用することができます。このセクションでは、IPv6を安全に使用することができる方法のいくつかの例を示します。
As a simple gateway, the device manages both packet routing and local address management. A basic IPv6 router should have a default configuration to advertise inside the site a locally generated random ULA prefix, independently from the state of any external connectivity. This would allow local nodes in a topology more complex than a single link to communicate amongst themselves independent of the state of a global connection. If the network happened to concatenate with another local network, the randomness in ULA creation is highly unlikely to result in address collisions.
単純なゲートウェイとして、デバイスは、パケットルーティングおよびローカルアドレスの管理の両方を管理します。基本的なIPv6ルータは、独立して、任意の外部接続の状態から、サイト内でローカルに生成されたランダムなULAプリフィックスを宣伝したい場合は、デフォルトの設定が必要です。これは、グローバルな接続の状態とは無関係に、それ自体で通信するための単一のリンクより、トポロジ内のローカル・ノードは、より複雑なことが可能になります。ネットワークは別のローカルネットワークと連結する起こった場合は、ULAの作成中にランダム性は、アドレスの衝突が発生する可能性はほとんどありません。
With external connectivity, the simple gateway should use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet that follow the policy table in RFC 3484 will always use the global IPv6 addresses derived from this prefix delegation. It should be noted that the address selection policy table should be configured to prefer the ULA prefix range over the DHCP-PD prefix range when the goal is to keep local communications stable during periods of transient external connectivity.
外部接続と、単純なゲートウェイは、グローバルなインターネットに接続するときに使用するためのサービスプロバイダから経路プレフィックスを取得するためにDHCP-PDを使用すべきです。 RFC 3484でポリシーテーブルをたどるグローバルなインターネット上の他のノードを含むエンドシステムの接続は、常にこのプレフィックス委任由来グローバルIPv6アドレスを使用します。目標は、過渡外部接続の期間中に安定したローカル通信を維持することであるとき、アドレス選択ポリシーテーブルは、DHCP-PDプレフィックス範囲にわたって、ULAプリフィックス範囲を好むように設定する必要があることに注意すべきです。
In the very simple case, there is no explicit routing protocol on either side of the gateway, and a single default route is used internally pointing out to the global Internet. A slightly more complex case might involve local internal routing protocols, but with the entire local network sharing a common global prefix there would still not be a need for an external routing protocol as the service provider could install a route for the prefix delegated via DHCP-PD pointing toward the connecting link.
非常に単純なケースでは、ゲートウェイのいずれかの側に明示的なルーティングプロトコルが存在しない、単一のデフォルトルートは、内部グローバルインターネットに指摘使用されます。もう少し複雑な場合は、ローカルの内部ルーティングプロトコルを伴うかもしれませんが、一般的なグローバルプレフィックスを共有して全体のローカルネットワークでまだDHCP-経由委任プレフィックスのルートをインストールすることができ、サービスプロバイダなどの外部ルーティングプロトコルの必要性はないだろう連結リンクに向いPD。
The vulnerability of an IPv6 host directly connected to the Internet is similar to that of an IPv4 host. The use of firewalls and Intrusion Detection Systems (IDSs) is recommended for those that want boundary protection in addition to host defenses. A proxy may be used for certain applications, but with the caveat that the end-to-end transparency is broken. However, with IPv6, the following protections are available without the use of NAT while maintaining end-to-end reachability:
インターネットに直接接続されたIPv6ホストの脆弱性は、IPv4ホストと同様です。ファイアウォールや侵入検知システム（IDS;侵入）の使用は防衛をホストするために加えて、境界の保護をしたいもののために推奨されます。プロキシは、特定の用途のために、しかし、エンドツーエンドの透明性が破壊されていることを警告と共に使用することができます。エンドツーエンドの到達可能性を維持しながら、しかし、IPv6で、次の保護は、NATを使用せずに使用できます。
1. Short lifetimes on privacy extension suffixes reduce the attack profile since the node will not respond to the address once its lifetime becomes invalid.
その寿命が無効になると、ノードがアドレスに応答しませんので、プライバシーの拡張接尾辞1.短い寿命は攻撃プロファイルを減らします。
2. IP security (IPsec) is often cited as the reason for improved security because it is a mandatory service for IPv6 implementations. Broader availability does not by itself improve security because its use is still regulated by the availability of a key infrastructure. IPsec functions to authenticate the correspondent, prevent session hijacking, prevent content tampering, and optionally mask the packet contents. While IPsec is commonly available in some IPv4 implementations and with extensions can support NAT traversals, NAT support has limitations and does not work in all situations. The use of IPsec with NATs requires an additional UDP encapsulation and keepalive overhead [13]. In the IPv4/NAT environment, the usage of IPsec has been largely limited to edge-to-edge Virtual Private Network (VPN) deployments. The potential for end-to-end IPsec use is significantly enhanced when NAT is removed from the network, as connections can be initiated from either end. It should be noted that encrypted IPsec traffic will bypass content-aware firewalls, which is presumed to be acceptable for parties with whom the site has established a security association.
これは、IPv6の実装のために必須のサービスであるため、前記IPセキュリティ（IPsec）は、多くの場合、セキュリティの向上の理由として挙げられます。その使用はまだ鍵インフラストラクチャの可用性によって規制されるため、より広範な可用性は、それ自体でセキュリティを向上しません。 IPsecの機能は、特派員を認証セッションハイジャックを防ぐため、コンテンツ改ざんを防止するため、必要に応じてパケットの内容をマスクします。 IPsecはNATトラバーサルをサポートすることができ、いくつかのIPv4実装でと拡張子を持つ一般に入手可能ですが、NATのサポートには制限があり、すべての状況では動作しません。 NATとのIPsecの使用は[13]追加のUDPカプセル化とキープアライブオーバーヘッドを必要とします。 IPv4の/ NAT環境では、IPsecのの使用は、主に端から端まで仮想プライベートネットワーク（VPN）の展開に限定されてきました。 NATがネットワークから削除されたときに接続がいずれかの末端から開始することができるよう、エンドツーエンドのIPsec使用の可能性は大きく、強化されています。暗号化されたIPsecトラフィックは、サイトがセキュリティアソシエーションを確立している人とのパーティーのために許容可能であると推定されているコンテンツアウェアファイアウォールをバイパスすることに留意すべきです。
3. The size of the address space of a typical subnet (64 bits of IID) will make a complete subnet ping sweep usually significantly harder and more expensive than for IPv4 [20]. Reducing the security threat of port scans on identified nodes requires sparse distribution within the subnet to minimize the probability of scans finding adjacent nodes. This scanning protection will be nullified if IIDs are configured in any structured groupings within the IID space. Provided that IIDs are essentially randomly distributed across the available space, address scanning-based attacks will effectively fail. This protection exists if the attacker has no direct access to the specific subnet and therefore is trying to scan it remotely. If an attacker has local access, then he could use Neighbor Discovery (ND) [3] and ping6 to the link-scope multicast ff02::1 to detect the IEEE-based address of local neighbors, then apply the global prefix to those to simplify its search (of course, a locally connected attacker has many scanning options with IPv4 as well).
3.一般的なサブネット（IIDの64ビット）のアドレス空間のサイズは、通常、著しく困難とIPv4 [20]のためのより高価な完全なサブネットのpingスイープを行います。識別されたノード上のポートスキャンのセキュリティ上の脅威を低減することは、隣接ノードを発見するスキャンの確率を最小にするためにサブネット内の疎な分布を必要とします。 IIDをはIID空間内の任意の構造化されたグループで構成されている場合、このスキャン保護が無効になります。 IIDを、本質的にはランダムに利用可能なスペースに分散していると仮定すると、アドレス走査ベースの攻撃が効果的に失敗します。攻撃者が特定のサブネットへの直接アクセスを持っていないため、リモートでスキャンしようとしている場合は、この保護が存在します。攻撃者がローカルのアクセス権を持っている場合は、その後、彼は近隣探索（ND）を使用することができます[3]とするping6リンク範囲マルチキャストFF02 :: 1に地元の隣人のIEEEベースのアドレスを検出するために、その後のものにグローバルプレフィックスを適用その検索を単純化する（もちろん、ローカルに接続された攻撃者は、同様のIPv4と多くのスキャンオプションを有しています）。
Assuming the network administrator is aware of [20] the increased size of the IPv6 address will make topology probing much harder, and almost impossible for IPv6 devices. The intention of topology probing is to identify a selection of the available hosts inside an enterprise. This mostly starts with a ping sweep. Since the IPv6 subnets are 64 bits worth of address space, this means that an attacker has to simply send out an unrealistic number of pings to map the network, and virus/worm propagation will be thwarted in the process. At full-rate full-duplex 40 Gbps (400 times the typical 100 Mbps LAN, and 13,000 times the typical DSL/cable access link), it takes over 5,000 years to scan the entirety of a single 64-bit subnet.
ネットワーク管理者と仮定すると認識している[20] IPv6アドレスの増加サイズは、トポロジがはるかに困難探査、およびIPv6デバイスのためにほとんど不可能になります。プロービングトポロジーの目的は、企業内の利用可能なホストの選択を識別することです。これは主にpingスイープを開始します。 IPv6のサブネットは、アドレス空間の価値が64ビットであるので、これは、攻撃者が簡単にネットワークをマッピングするためにpingの非現実的な数を送信するために持っていることを意味し、ウイルス/ワームの増殖は、プロセスに阻止されます。フルレート全二重40 Gbpsの（400倍の典型的な100 MbpsのLAN、および13,000回の典型的なDSL /ケーブルアクセスリンク）で、それは単一の64ビットのサブネット全体をスキャンするために5000年以上もかかります。
IPv4 NAT was not developed as a security mechanism. Despite marketing messages to the contrary, it is not a security mechanism, and hence it will offer some security holes while many people assume their network is secure due to the usage of NAT. IPv6 security best practices will avoid this kind of illusory security, but can only address the same threats if correctly configured firewalls and IDSs are used at the perimeter.
IPv4のNATは、セキュリティ・メカニズムとして開発されていませんでした。逆にメッセージをマーケティングにもかかわらず、それは、セキュリティ・メカニズムではなく、多くの人々が彼らのネットワークが原因NATの使用に安全であると仮定している間、したがってそれはいくつかのセキュリティホールを提供します。 IPv6のセキュリティのベストプラクティスは、幻想セキュリティのこの種のを回避できますが、正しく構成され、ファイアウォールやIDSをが境界で使用されている場合のみ、同じ脅威に対処することができます。
It must be noted that even a firewall doesn't fully secure a network. Many attacks come from inside or are at a layer higher than the firewall can protect against. In the final analysis, every system has to be responsible for its own security, and every process running on a system has to be robust in the face of challenges like stack overflows, etc. What a firewall does is prevent a network administration from having to carry unauthorized traffic, and in so doing reduce the probability of certain kinds of attacks across the protected boundary.
それも、ファイアウォールが完全にネットワークを保護しないことに注意しなければなりません。多くの攻撃は保護でき、内側から来るかファイアウォールより高い層です。最終的な分析では、すべてのシステムは、独自のセキュリティを担うことがあり、システム上で実行中のすべてのプロセスは、スタックオーバーフローのような課題に直面して堅牢でなければならない、など何ファイアウォールがないことになるからネットワーク管理を防ぐことです不正なトラフィックを伝送し、そうすることで保護された境界を越えて攻撃の特定の種類の確率を減らします。
To implement simple security for IPv6 in, for example, a DSL or cable modem-connected home network, the broadband gateway/router should be equipped with stateful firewall capabilities. These should provide a default configuration where incoming traffic is limited to return traffic resulting from outgoing packets (sometimes known as reflective session state). There should also be an easy interface that allows users to create inbound 'pinholes' for specific purposes such as online gaming.
例えば、DSLまたはケーブルモデムに接続されたホームネットワークでIPv6の簡単なセキュリティを実装するには、ブロードバンドゲートウェイ/ルータは、ステートフルファイアウォール機能を装備する必要があります。これらは、着信トラフィックが（時々反射セッション状態として知られる）発信パケットから生じるトラフィックを返すように制限されているデフォルト設定を提供しなければなりません。また、ユーザーは、オンラインゲームなどの特定の目的のためにインバウンド「ピンホール」を作成することを可能にする簡単なインターフェースがあるはずです。
Administrators and the designers of configuration interfaces for simple IPv6 firewalls need to provide a means of documenting the security caveats that arise from a given set of configuration rules so that users (who are normally oblivious to such things) can be made aware of the risks. As rules are improved iteratively, the goal will be to make use of the IPv6 Internet more secure without increasing the perceived complexity for users who just want to accomplish a task.
管理者は、簡単なIPv6のファイアウォールのコンフィギュレーション・インターフェースの設計者は、（通常はそのようなことを忘れている）ユーザーがリスクを知ることができるように構成ルールの特定のセットから発生するセキュリティ上の注意事項を文書化する手段を提供する必要があります。ルールは反復的に改善されているとおり、目標は単にタスクを達成したいユーザーのための知覚の複雑さを増大させることなく、IPv6インターネットの使用をより安全にすることになります。
IPv6 enables the collection of information about data flows. Because all addresses used for Internet and intra-/inter-site communication are unique, it is possible for an enterprise or ISP to get very detailed information on any communication exchange between two or more devices. Unless privacy addresses [7] are in use, this enhances the capability of data-flow tracking for security audits compared with IPv4 NAT, because in IPv6 a flow between a sender and receiver will always be uniquely identified due to the unique IPv6 source and destination addresses.
IPv6は、データフローに関する情報の収集を可能にします。インターネットやイントラ/サイト間の通信に使用されるすべてのアドレスが一意であるため、企業やISPが二つ以上のデバイス間の任意の通信交換に非常に詳細な情報を入手することが可能です。プライバシーアドレス[7]に使用されている場合を除きIPv6では送信側と受信側との間の流れが常に一意に識別されるので、これは、一意のIPv6送信元および宛先に、IPv4のNATと比べてセキュリティ監査のトラッキングデータフローの能力を増強しますアドレス。
At the same time, this tracking is per address. In environments where the goal is tracking back to the user, additional external information will be necessary correlating a user with an address. In the case of short-lifetime privacy address usage, this external information will need to be based on more stable information such as the layer 2 media address.
同時に、この追跡はアドレスごとです。目標は、バックユーザに追跡している環境では、付加的な外部情報は、アドレスをユーザに関連付けることが必要であろう。短寿命プライバシーアドレスの使用の場合には、この外部情報は、レイヤ2メディア・アドレスとしてより安定した情報に基づいてする必要があります。
Partial host privacy is achieved in IPv6 using RFC 3041 pseudo-random privacy addresses [7] which are generated as required, so that a session can use an address that is valid only for a limited time. This only allows such a session to be traced back to the subnet that originates it, but not immediately to the actual host, where IPv4 NAT is only traceable to the most public NAT interface.
部分的なホストのプライバシーは、必要に応じて、セッションが限られた時間のために有効なアドレスを使用できるように、[7]、生成されたRFC 3041擬似ランダムプライバシーアドレスを用いてIPv6では達成されます。これは、そのようなセッションがなく、すぐにIPv4のNATは、ほとんどのパブリックNATインターフェイスにのみトレーサブルである実際のホストに、戻ってそれを発信するサブネットにトレースすることを可能にします。
Due to the large IPv6 address space available, there is plenty of freedom to randomize subnet allocations. By doing this, it is possible to reduce the correlation between a subnet and its location. When doing both subnet and IID randomization, a casual snooper won't be able to deduce much about the network's topology. The obtaining of a single address will tell the snooper very little about other addresses. This is different from IPv4 where address space limitations cause this not to be true. In most usage cases, this concept should be sufficient for address privacy and topology hiding, with the cost being a more complex internal routing configuration.
、利用可能な大規模なIPv6アドレス空間に、サブネットの割り当てをランダム化する自由がたくさんあります。こうすることで、サブネットとその場所の間の相関を低減することが可能です。サブネットとIIDのランダム化の両方を行う場合、カジュアルな詮索は、ネットワークのトポロジーについて多くを推測することはできません。単一のアドレスを取得すると、他のアドレスについてはほとんど盗聴を教えてくれます。これは、アドレス空間の制約が真ではないことが、この原因をIPv4から異なっています。ほとんどの利用例では、この概念は、コストがより複雑な内部ルーティング設定された状態で、アドレスのプライバシーおよびトポロジ隠蔽のために十分なものでなければなりません。
As discussed in Section 3.1, there are multiple parts to the IPv6 address, and different techniques to manage privacy for each which may be combined to protect the entire address. In the case where a network administrator wishes to fully isolate the internal IPv6 topology, and the majority of its internal use addresses, one option is to run all internal traffic using Unique Local Addresses (ULAs). By definition, this prefix block is not to be advertised in the public routing system, so without a routing path external traffic will never reach the site. For the set of hosts that do in fact need to interact externally, by using multiple IPv6 prefixes (ULAs and one or more global addresses) all of the internal nodes that do not need external connectivity, and the internally used addresses of those that do, will be masked from the outside. The policy table defined in [11] provides a mechanism to bias the selection process when multiple prefixes are in use such that the ULA would be preferred when the correspondent is also local.
セクション3.1で述べたように、全体のアドレスを保護するために組み合わせることができるそれぞれのプライバシーを管理するためのIPv6アドレスへの複数の部分、及び異なる技術があります。ネットワーク管理者は、完全に内部のIPv6トポロジ、およびその内部使用のアドレスの大部分を分離したい場合には、一つの選択肢は、ユニークローカルアドレス（ULAs）を使用して、すべての内部トラフィックを実行することです。外部トラフィックがサイトに到達することはありませんルーティングパスを含まないので、定義によると、この接頭辞ブロックは、公共のルーティングシステムで広告されるべきではありません。実際には複数のIPv6プレフィックス（ULAsと1つの以上のグローバルアドレス）外部接続を必要としない内部ノードのすべて、とやるものの内部で使用されるアドレスを使用して、外部に対話する必要がないホストのセットについて、外部からマスクされます。 [11]で定義されたポリシーテーブルをバイアスするために複数のプレフィックスは、対応もローカルである場合ULAが好ましいであろうように、使用されている選択プロセスを機構を提供します。
There are other scenarios for the extreme situation when a network manager also wishes to fully conceal the internal IPv6 topology. In these cases, the goal in replacing the IPv4 NAT approach is to make all of the topology hidden nodes appear from the outside to logically exist at the edge of the network, just as they would when behind a NAT. This figure shows the relationship between the logical subnets and the topology masking router discussed in the bullet points that follow.
ネットワーク管理者は、完全に内部のIPv6トポロジーを隠したいとき、極端な状況のため、他のシナリオがあります。これらのケースでは、IPv4のNATのアプローチを置き換えることで目標は、ちょうどその時、NATの背後にある彼らと同じように、トポロジー隠されたすべてのノードがには、論理的にネットワークのエッジに存在する外部から見えるようにすることです。この図は、論理サブネットと追従箇条書きで説明したトポロジマスキングルータとの関係を示しています。
Internet
|
\
|
+------------------+
| topology |-+-+-+-+-+-+-+-+--
| masking | Logical subnets
| router |-+-+-+-+-+-+-+-+--
+------------------+ for topology
| hidden nodes
|
Real internal -------------+-
topology | |
| -+----------
-----------+--------+
|
|
|
o One approach uses explicit host routes in the Interior Gateway Protocol (IGP) to remove the external correlation between physical topology attachment point and end-to-end IPv6 address. In the figure above the hosts would be allocated prefixes from one or more logical subnets, and would inject host routes into the IGP to internally identify their real attachment point. This solution does however show severe scalability issues and requires hosts to securely participate in the IGP, as well as have the firewall block all external to internal traceroutes for the logical subnet. The specific limitations are dependent on the IGP protocol, the physical topology, and the stability of the system. In any case, the approach should be limited to uses with substantially fewer than the maximum number of routes that the IGP can support (generally between 5,000 and 50,000 total entries including subnet routes). Hosts should also listen to the IGP for duplicate use before finalizing an interface address assignment as the duplicate address detection will only check for use on the attached segment, not the logical subnet.
O一つのアプローチは、物理トポロジー接続ポイントとエンド・ツー・エンドのIPv6アドレスと外部の相関を除去するためにインテリアゲートウェイプロトコル（IGP）に明示的なホストルートを使用します。ホスト上の図では、1つまたは複数の論理サブネットのプレフィックスを割り当てられる、及び内部それらの実際のアタッチメントポイントを識別するためにIGPにホストルートを注入することになります。しかしながら、この解決策は深刻なスケーラビリティの問題を示し、しっかりIGPに参加するホストを必要とするだけでなく、論理サブネットの内部のtracerouteへのすべての外部ファイアウォールのブロックを持っていません。具体的な制限は、IGPプロトコル、物理トポロジ、およびシステムの安定性に依存しています。いずれの場合においても、このアプローチは、IGPが（サブネット経路を含む一般の間で5,000と50,000の合計エントリ）をサポートすることができる経路の最大数よりも実質的に少ないとの使用に限定されるべきです。ホストはまた、唯一の接続されたセグメントではなく、論理サブネット上で使用するためにチェックする重複アドレス検出などのインタフェースアドレスの割り当てを完了する前に、重複使用のためのIGPに耳を傾ける必要があります。
o Another technical approach to fully hide the internal topology is use of a tunneling mechanism. Mobile IPv6 without route optimization is one approach for using an automated tunnel, as it always starts in tunnel mode via the Home Agent (HA). In this deployment model, the application perceived addresses of the nodes are routed via the edge HA acting as the topology masking router (above). This indirection method truly masks the internal topology, as from outside the local network all nodes with global access appear to share the prefix of one or more logical subnets attached to the HA rather than their real attachment point. Note that in this usage context, the HA is replacing the NAT function at the edge of the network, so concerns about additional latency for routing through a tunnel to the HA do not apply because it is effectively on the same path that the NAT traffic would have taken. Duplicate address detection is handled as a normal process of the HA binding update. While turning off all binding updates with the correspondent node would appear to be necessary to prevent leakage of topology information, that approach would also force all internal traffic using the home address to route via the HA tunnel, which may be undesirable. A more efficient method would be to allow internal route optimizations while dropping outbound binding update messages at the firewall. Another approach for the internal traffic would be to use the policy table of RFC 3484 to bias a ULA prefix as preferred internally, leaving the logical subnet Home Address external for use. The downside to a Mobile IPv6-based solution is that it requires a Home Agent in the network and the configuration of a security association with the HA for each hidden node, and it consumes some amount of bandwidth for tunnel overhead.
O完全に内部トポロジーを隠蔽するための別の技術的なアプローチは、トンネリングメカニズムを使用することです。それは常にホームエージェント（HA）を経由してトンネルモードで起動するようルート最適化なしのモバイルIPv6は、自動化されたトンネルを使用するための一つのアプローチです。この展開モデルでは、ノードのアプリケーション知覚アドレスがエッジトポロジーマスキングルータとして動作するHA（上）を介してルーティングされます。この間接方法が本当にマスク内部トポロジは、ローカルネットワークの外部からのようグローバルアクセス権を持つすべてのノードは、HAよりもむしろ彼らの本当の取付点に取り付けられた1つのまたは複数の論理サブネットのプレフィックスを共有するように見えます。それはNATトラフィックがあろうと、同じパス上に効果的であるため、HAへのトンネルを介してルーティングするための追加のレイテンシ懸念が適用されないので、この使用状況において、HAは、ネットワークのエッジでNAT機能を交換していることに注意してください撮影してきました。重複アドレス検出は、HAバインディング更新の正常プロセスとして扱われます。コレスポンデントノードとのすべてのバインディング更新をオフにすると、トポロジ情報の漏洩を防止するために必要であるように思われるが、そのアプローチは、望ましくない場合があるHAトンネルを介してルーティングするホームアドレスを使用して、すべての内部トラフィックを強制することになります。より効率的な方法は、ファイアウォールでアウトバウンドバインディング更新メッセージを滴下しながら内部ルート最適化を可能にするであろう。内部トラフィックのための別のアプローチは、使用するために外部の論理サブネットのホームアドレスを残して、内部的に好ましいとバイアスにULAプリフィックスをRFC 3484のポリシーテーブルを使用することです。モバイルIPv6ベースのソリューションの欠点は、それがネットワークと各隠れノードのHAとのセキュリティ関連の構成においてホーム・エージェントが必要であり、それはトンネルのオーバーヘッドのために帯域幅の一部を消費することです。
o Another method (where the layer 2 topology allows) uses a virtual LAN approach to logically attach the devices to one or more subnets on the edge router. This approach leads the end nodes to believe they actually share a common segment. The downside of this approach is that all internal traffic would be directed over suboptimal paths via the edge router, as well as the complexity of managing a distributed logical LAN.
O（レイヤ2トポロジーが可能）別の方法は、論理的にエッジルータ上の1つのまたは複数のサブネットにデバイスを接続するために、仮想LANのアプローチを使用します。このアプローチは、彼らが実際に共通セグメントを共有信じるようにエンドノードをリードしています。このアプローチの欠点は、すべての内部トラフィックは、エッジルータ、ならびに分散論理LAN管理の複雑さを介して次善のパスを介して向けられることです。
One issue to be aware of is that subnet scope multicast will not work for the logical hidden subnets, except in the VLAN case. While a limited scope multicast to a collection of nodes that are arbitrarily scattered makes no technical sense, care should be exercised to avoid deploying applications that expect limited scope multicast in conjunction with topology hiding.
注意すべき1つの問題は、そのサブネットのスコープのマルチキャストVLANの場合を除いて、論理的な隠されたサブネットのために動作しませんです。任意に散在しているノードのコレクションに制限された範囲のマルチキャストは、技術的な意味を成しませんが、ケアは、トポロジ隠蔽と一緒に限られた範囲のマルチキャストを期待するアプリケーションを展開避けるために行使されなければなりません。
Another issue that this document will not define is the mechanism for a topology hidden node to learn its logical subnet. While manual configuration would clearly be sufficient, DHCP could be used for address assignment, with the recipient node discovering it is in a hidden mode when the attached subnet prefix doesn't match the one assigned.
この文書は定義されないであろうもう一つの問題は、その論理サブネットを学ぶためのトポロジー隠されたノードのためのメカニズムです。手動設定は明らかに十分であろうが添付サブネットプレフィックスが割り当てられたものと一致しないときにそれを発見し、受信者のノードが非表示モードになっていると、DHCPは、アドレス割り当てのために使用することができます。
IPv6 provides for autonomy in local use addresses through ULAs. At the same time, IPv6 simplifies simultaneous use of multiple addresses per interface so that an IPv6 NAT is not required between the ULA and the public Internet because nodes that need access to the public Internet will have a global use address as well. When using IPv6, the need to ask for more address space will become far less likely due to the increased size of the subnets, along with an allocation policy that recognizes that table fragmentation is also an important consideration. While global IPv6 allocation policy is managed through the Regional Internet Registries (RIRs), it is expected that they will continue with derivatives of [8] for the foreseeable future so the number of subnet prefixes available to an organization should not be a limitation that would create an artificial demand for NAT.
IPv6はULAsを介してローカル使用アドレスに自律性のために用意されています。公共のインターネットへのアクセスを必要とするノードは、同様のグローバル使用のアドレスを持っていますので、IPv6のNATは、ULAと公衆インターネットとの間で必要とされないように、同時に、IPv6は、インターフェイスごとに複数のアドレスの同時使用を簡素化します。 IPv6を使用する場合は、より多くのアドレス空間をお願いする必要がテーブルの断片化も重要な考慮事項であることを認識して割り当てポリシーと一緒に、はるかに少ない可能性が高いため、サブネットのサイズの増加になります。グローバルIPv6割り当てポリシーは地域インターネットレジストリ（のRIR）によって管理されているが、組織が利用可能なサブネット・プレフィックスの数は、その希望限定すべきではないので、彼らは当面[8]の誘導体を継続することが予想されますNATのための人工的な需要を創出。
Ongoing subnet address maintenance may become simpler when IPv6 technology is utilized. Under IPv4 address space policy restrictions, each subnet must be optimized, so one has to look periodically into the number of hosts on a segment and the subnet size allocated to the segment and rebalance. For example, an enterprise today may have a mix of IPv4 /28 - /23 size subnets, and may shrink/grow these as its network user base changes. For IPv6, all subnets have /64 prefixes, which will reduce the operational and configuration overhead.
IPv6技術を利用した場合の継続的なサブネットアドレスのメンテナンスが簡単になることがあります。一つのセグメントに割り当てられたセグメントとサブネットサイズ上のホストの数に定期的に見て再調整しなければならないので、IPv4アドレス空間ポリシーの制約の下で、各サブネットは、最適化されなければなりません。例えば、企業今日では、IPv4 / 28の混合有していてもよい - / 23サイズのサブネットを、および/またはこれらは、そのネットワークのユーザーベースが変化するにつれて成長縮小できます。 IPv6の場合、すべてのサブネットは、運用およびコンフィギュレーションのオーバーヘッドを削減します/ 64プレフィックスを、持っています。
IPv6 provides sufficient space to completely avoid the need for overlapping address space. Since allocations in IPv6 are based on subnets rather than hosts, a reasonable way to look at the pool is that there are about 17*10^18 unique subnet values where sparse allocation practice within those provides for new opportunities such as SEcure Neighbor Discovery (SEND) [15]. As previously discussed, the serious disadvantages of ambiguous address space have been well documented, and with sufficient space there is no need to continue the increasingly aggressive conservation practices that are necessary with IPv4. While IPv6 allocation policies and ISP business practice will continue to evolve, the recommendations in RFC 3177 are based on the technical potential of the vast IPv6 address space. That document demonstrates that there is no resource limitation that will require the adoption of the IPv4 workaround of ambiguous space behind a NAT. As an example of the direct contrast, many expansion-oriented IPv6 deployment scenarios result in multiple IPv6 addresses per device, as opposed to the constriction of IPv4 scenarios where multiple devices are forced to share a scarce global address through a NAT.
IPv6は完全なアドレス空間の重複の必要性を回避するために十分なスペースを提供します。 IPv6における割り当てがサブネットではなく、ホストに基づいているので、プールを見て合理的な方法は、それらの内のスパース割り当て練習は、セキュア近隣探索などの新しい機会を提供し、約17×10 ^ 18の一意のサブネット値（SENDがあることです）[15]。前述したように、あいまいなアドレス空間の重大な欠点は、十分に文書化されており、十分なスペースではIPv4で必要な、ますます積極的な保全の実践を継続する必要はありません。 IPv6の割り当て方針やISPのビジネス慣行は進化し続けますが、RFC 3177の推奨事項は、広大なIPv6アドレス空間の技術的可能性に基づいています。その文書には、NATの背後に曖昧な空間のIPv4の回避策の導入が必要になります何のリソース制限がないことを示しています。複数のデバイスがNATを介し乏しいグローバルアドレスを共有するように強制されたIPv4シナリオの狭窄とは対照的に正反対の一例として、多くの拡張指向IPv6の展開シナリオは、デバイスごとに複数のIPv6アドレスをもたらします。
IPv6 was designed to allow sites and hosts to run with several simultaneous CIDR-allocated prefixes, and thus with several simultaneous ISPs. An address selection mechanism [11] is specified so that hosts will behave consistently when several addresses are simultaneously valid. The fundamental difficulty that IPv4 has in regard to multiple addresses therefore does not apply to IPv6. IPv6 sites can and do run today with multiple ISPs active, and the processes for adding, removing, and renumbering active prefixes at a site have been documented in [16] and [21]. However, multihoming and renumbering remain technically challenging even with IPv6 with regards to session continuity across multihoming events or interactions with ingress filtering (see the Gap Analysis below).
IPv6が同時に複数のISPでこれサイトとホストが複数の同時CIDR-割り当てられたプレフィックスを使用して実行できるように設計された、とされました。複数のアドレスが同時に有効であるとき、ホストが一貫振る舞うように、アドレス選択機構[11]は指定されています。 IPv4のは、複数のアドレスに関して持っている根本的な難しさは、そのためのIPv6には適用されません。 IPv6サイトのことができ、アクティブな複数のISPと今日を実行してください、そして、追加、削除、およびサイトでアクティブなプレフィックスをリナンバリングするためのプロセスは、[16]と[21]に記載されています。しかし、マルチホーミングとリナンバリングは、イングレスフィルタリング（以下ギャップ分析を参照）イベントまたは相互作用をマルチホーミング横切ってセッションの継続に関してもIPv6で技術的に困難なままです。
The IPv6 address space allocated by the ISP will be dependent upon the connecting service provider. This will likely result in a renumbering effort when the network changes between service providers. When changing ISPs or ISPs readjust their addressing pool, DHCP-PD [12] can be used as an almost zero-touch external mechanism for prefix change in conjunction with a ULA prefix for internal connection stability. With appropriate management of the lifetime values and overlap of the external prefixes, a smooth make-before-break transition is possible as existing communications will continue on the old prefix as long as it remains valid, while any new communications will use the new prefix.
ISPによって割り当てられたIPv6アドレス空間は、接続サービスプロバイダに依存するであろう。これは、おそらくリナンバリングの努力になりますときに、サービス・プロバイダー間のネットワークの変更。変更ISPやISPが彼らのアドレッシングプール、DHCP-PDを再調整するとき[12]内部接続安定性のためのULAプリフィックスと一緒にプレフィックス変更のためにほぼゼロタッチ外部機構として使用することができます。ライフタイム値と外部プレフィックスの重複の適切な管理によって、スムーズなメイク・ビフォア・ブレークの移行は、既存の通信があればどのような新しい通信が新しい接頭辞を使用する一方、それは、有効なままで、古いプレフィックスに継続するよう可能です。
In presenting these case studies, we have chosen to consider categories of networks divided first according to their function either as carrier/ISP networks or end user (such as enterprise) networks with the latter category broken down according to the number of connected end hosts. For each category of networks, we can use IPv6 Local Network Protection to achieve a secure and flexible infrastructure, which provides an enhanced network functionality in comparison with the usage of address translation.
これらのケーススタディを提示では、我々は、（企業など）、それらの機能キャリア/ ISPネットワークとして、またはエンドユーザのいずれかに応じて第1分割ネットワークの種類接続されたエンドホストの数に応じて分解後者のカテゴリを持つネットワークを検討することを選択しました。ネットワークの各カテゴリについては、我々はアドレス変換の使用と比較して強化されたネットワーク機能を提供し、安全で柔軟なインフラストラクチャを実現するためのIPv6ローカルネットワーク保護を使用することができます。
o Medium/Large Private Networks (typically >10 connections)
Oミディアム/ラージ・プライベート・ネットワーク（通常は> 10の接続）
o Small Private Networks (typically 1 to 10 connections)
O小さなプライベートネットワーク（通常は1〜10の接続）
o Single User Connection (typically 1 connection)
Oシングルユーザ接続（通常は1つの接続）
o ISP/Carrier Customer Networks
O ISP /キャリア顧客ネットワーク
The majority of private enterprise, academic, research, or government networks fall into this category. Many of these networks have one or more exit points to the Internet. Though these organizations have sufficient resources to acquire addressing independence when using IPv4, there are several reasons why they might choose to use NAT in such a network. For the ISP, there is no need to import the IPv4 address range from the remote end-customer, which facilitates IPv4 route summarization. The customer can use a larger IPv4 address range (probably with less administrative overhead) by the use of RFC 1918 and NAT. The customer also reduces the overhead in changing to a new ISP, because the addresses assigned to devices behind the NAT do not need to be changed when the customer is assigned a different address by a new ISP. By using address translation in IPv4, one avoids the expensive process of network renumbering. Finally, the customer can provide privacy for its hosts and the topology of its internal network if the internal addresses are mapped through NAT.
民間企業、学術、研究、または政府のネットワークの大半はこのカテゴリーに入ります。これらのネットワークの多くは、インターネットへの1つのまたは複数の出口点を持っています。これらの組織は、IPv4を使用する場合に対処する独立性を獲得するのに十分なリソースを持っていますが、彼らはそのようなネットワークでNATを使用することを選択するかもしれないいくつかの理由があります。 ISPは、IPv4ルート集約を容易にリモートエンド顧客からIPv4アドレス範囲をインポートする必要がありません。顧客は、RFC 1918およびNATを使用することによって（おそらく少ない管理オーバーヘッドで）大きなIPv4アドレスの範囲を使用することができます。顧客は新しいISPによって異なるアドレスが割り当てられているとき、NATの背後にあるデバイスに割り当てられたアドレスを変更する必要がないため、顧客はまた、新しいISPに変更することでオーバーヘッドを軽減します。 IPv4のアドレス変換を使用することによって、ネットワークのリナンバリングの高価なプロセスを回避することができます。内部アドレスがNATを通じてマッピングされている場合は最後に、顧客は、そのホストとその内部ネットワークのトポロジのプライバシーを提供することができます。
It is expected that there will be enough IPv6 addresses available for all networks and appliances for the foreseeable future. The basic IPv6 address range an ISP allocates for a private network is large enough (currently /48) for most of the medium and large enterprises, while for the very large private enterprise networks address ranges can be concatenated. The goal of this assignment mechanism is to decrease the total amount of entries in the public Internet routing table. A single /48 allocation provides an enterprise network with 65,536 different /64 subnet prefixes.
予見可能な将来のためにすべてのネットワークや家電製品に利用可能な十分なIPv6アドレスが存在するであろうことが期待されます。非常に大規模な民間企業のネットワークのためのアドレス範囲を連結することができるがISPがプライベートネットワークに割り当てる基本的なIPv6アドレス範囲は、中規模および大企業のほとんどの（現在/ 48）に十分な大きさです。この割り当て機構の目標は、公共のインターネットルーティングテーブル内のエントリの合計量を減少させることです。単一/ 48割り当ては65,536異なる/ 64サブネット・プレフィックスを有する企業ネットワークを提供します。
To mask the identity of a user on a network of this type, the usage of IPv6 privacy extensions may be advised. This technique is useful when an external element wants to track and collect all information sent and received by a certain host with a known IPv6 address. Privacy extensions add a random time-limited factor to the host part of an IPv6 address and will make it very hard for an external element to keep correlating the IPv6 address to a specific host on the inside network. The usage of IPv6 privacy extensions does not mask the internal network structure of an enterprise network.
このタイプのネットワーク上のユーザーの身元を隠すために、IPv6のプライバシーの拡張機能の使用方法を助言することができます。外部要素が知られているIPv6アドレスを持つ特定のホストによって送信され、受信したすべての情報を追跡し、収集したい場合に便利です。プライバシーの拡張機能は、IPv6アドレスのホスト部分にランダムな期間限定の要因を追加して、外部の要素は、内部ネットワーク上の特定のホストにIPv6アドレスを関連付ける維持するために非常に懸命にそれを行います。 IPv6のプライバシーの拡張機能の使用方法は、企業ネットワークの内部ネットワーク構造を隠していません。
When there is a need to mask the internal structure towards the external IPv6 Internet, then some form of 'untraceable' addresses may be used. These addresses will appear to exist at the external edge of the network, and may be assigned to those hosts for which topology masking is required or that want to reach the IPv6 Internet or other external networks. The technology to assign these addresses to the hosts could be based on DHCPv6 or static configuration. To complement the 'Untraceable' addresses, it is necessary to have at least awareness of the IPv6 address location when routing an IPv6 packet through the internal network. This could be achieved by 'host based route-injection' in the local network infrastructure. This route-injection could be done based on /128 host-routes to each device that wants to connect to the Internet using an untraceable address. This will provide the most dynamic masking, but will have a scalability limitation, as an IGP is typically not designed to carry many thousands of IPv6 prefixes. A large enterprise may have thousands of hosts willing to connect to the Internet.
外部のIPv6インターネットへの内部構造をマスクする必要がある場合には、その後、「追跡不可能な」アドレスのいくつかのフォームを使用することができます。これらのアドレスは、ネットワークの外部エッジに存在するように表示され、トポロジのマスキングが必要とされるか、それがIPv6インターネットなどの外部ネットワークに到達したいそれらのホストに割り当ててもよいです。ホストにこれらのアドレスを割り当てるための技術は、DHCPv6のか、静的な構成に基づくことができます。 「ブラックサイト」アドレスを補完するために、内部ネットワークを介してIPv6パケットをルーティングするときにIPv6アドレス位置の少なくとも意識を持っていることが必要です。これは、ローカルネットワークインフラストラクチャの「ホストベースのルート・インジェクション」によって達成することができました。この経路噴射は追跡不可能なアドレスを使用してインターネットに接続したい各デバイスへ/ 128ホスト・ルートに基づいて行うことができます。 IGPは、一般的にIPv6プレフィックスの何千を運ぶために設計されていませんので、これは、最もダイナミックマスキングを提供しますが、スケーラビリティの制限があります。大企業は、インターネットに接続して喜んでホストの数千人を有することができます。
An alternative for larger deployments is to leverage the tunneling aspect of MIPv6 even for non-mobile devices. With the logical subnet being allocated as attached to the edge Home Agent, the real attachment and internal topology are masked from the outside. Dropping outbound binding updates at the firewall is also necessary to avoid leaking the attachment information.
大規模な導入のための代替であっても非モバイルデバイス用のMIPv6のトンネリング側面を活用することです。エッジホームエージェントに取り付けられるような論理サブネットが割り当てられると、実際のアタッチメント内部トポロジーは、外部からマスクされます。ファイアウォールでアウトバウンドバインディングアップデートを削除すると、添付ファイルの情報漏洩を避けるためにも必要です。
Less flexible masking could be to have time-based IPv6 prefixes per link or subnet. This may reduce the amount of route entries in the IGP by a significant factor, but has as a trade-off that masking is time and subnet based, which will complicate auditing systems. The dynamic allocation of 'Untraceable' addresses can also limit the IPv6 access between local and external hosts to those local hosts being authorized for this capability.
あまり柔軟なマスキングは、リンクまたはサブネットごとの時間ベースのIPv6プレフィックスを持っている可能性があります。これは重要な因子によってIGPにルートエントリの量を低減するが、トレードオフマスキング基づく時間とサブネットであると、監査システムを複雑れるように有することができます。また、それらのローカルホストのローカルおよび外部のホスト間のIPv6アクセスを制限することができる「ブラックサイト」アドレスの動的割り当ては、この機能のために認可されています。
The use of permanent ULA addresses on a site provides the benefit that even if an enterprise changes its ISP, the renumbering will only affect those devices that have a wish to connect beyond the site. Internal servers and services would not change their allocated IPv6 ULA address, and the service would remain available even during global address renumbering.
サイトは企業がそのISPを変更しても利益をもたらす上で永久ULAの使用は対処し、リナンバリングは唯一のサイトを超えて接続する願いを持って、それらのデバイスに影響を与えます。内部サーバーおよびサービスは、割り当てられたIPv6 ULAアドレスを変更しないだろう、とサービスでもグローバルアドレスリナンバリングの際に使用可能な状態でしょう。
Also known as SOHO (Small Office/Home Office) networks, this category describes those networks that have few routers in the topology and usually have a single network egress point. Typically, these networks:
また、SOHO（スモールオフィス/ホームオフィス）ネットワークとして知られ、このカテゴリーは、トポロジ内のいくつかのルータを持っており、通常、単一のネットワーク出力ポイントを持っているこれらのネットワークについて説明します。一般的に、これらのネットワーク：
o are connected via either a dial-up connection or broadband access,
Oダイヤルアップ接続やブロードバンドアクセスのいずれかを介して接続されています、
o don't have dedicated Network Operation Center (NOC), and
Oネットワークオペレーションセンター（NOC）を捧げていない、と
o today, typically use NAT as the cheapest available solution for connectivity and address management
O今日、一般的に接続し、アドレス管理のための最も安い利用できるソリューションとして、NATを使用
In most cases, the received global IPv4 prefix is not fixed over time and is too long (very often a /32 giving just a single address) to provide every node in the private network with a unique, globally usable address. Fixing either of those issues typically adds an administrative overhead for address management to the user. This category may even be limited to receiving ambiguous IPv4 addresses from the service provider based on RFC 1918. An ISP will typically pass along the higher administration cost attached to larger address blocks, or IPv4 prefixes that are static over time, due to the larger public address pool each of those requires.
ほとんどの場合、受信グローバルIPv4プレフィックスは、時間をかけて固定されていないとのユニークな、世界的に利用可能なアドレスとプライベートネットワーク内のすべてのノードを提供するために、（1つだけアドレスを与える非常に頻繁/ 32）が長すぎます。通常、これらの問題のいずれかを固定することで、ユーザーにアドレス管理のための管理オーバーヘッドが追加されます。このカテゴリにもアンISPは、典型的に起因し、より大きな公共のために、より高い大きなアドレスブロックに取り付けられ、管理コスト、または時間をかけて静的であるIPv4プレフィクスに沿って通過するRFC 1918に基づいて、サービスプロバイダからあいまいなIPv4アドレスを受信することに制限されてもよいですこれらの各アドレスプールが必要です。
As a direct response to explicit charges per public address, most of this category has deployed NAPT (port demultiplexing NAT) to minimize the number of addresses in use. Unfortunately, this also limits the Internet capability of the equipment to being mainly a receiver of Internet data (client), and it makes it quite hard for the equipment to become a worldwide Internet server (HTTP, FTP, etc.) due to the stateful operation of the NAT equipment. Even when there is sufficient technical knowledge to manage the NAT to enable external access to a server, only one server can be mapped per protocol/port number per address, and then only when the address from the ISP is publicly routed. When there is an upstream NAT providing private address space to the ISP side of the private NAT, additional negotiation with the ISP will be necessary to provide an inbound mapping, if that is even possible.
パブリックアドレスごとに明示的な費用への直接の応答として、このカテゴリのほとんどは、使用中のアドレスの数を最小限に抑えるためにNAPT（NATを逆多重化ポート）を導入しました。残念ながら、これはまた、主にインターネットデータの受信機（クライアント）であることに機器のインターネット機能を制限し、それが原因ステートフルに世界中のインターネットサーバー（などHTTP、FTP、）になるために機器のための非常に困難になりますNAT機器の動作。サーバーへの外部アクセスを可能にするためにNATを管理するのに十分な技術的知識があっても、一つだけのサーバは、アドレスごとに、プロトコル/ポート番号ごとにマッピングすることができ、その後、ISPからのアドレスが公にルーティングされている場合のみ。プライベートNATのISP側にプライベートアドレス空間を提供する上流のNATがある場合は、ISPとの追加交渉はそれでも可能である場合、インバウンドマッピングを提供する必要があります。
When deploying IPv6 LNP in this environment, there are two approaches possible with respect to IPv6 addressing.
この環境でのIPv6 LNPを展開する場合、IPv6アドレスに関して可能な2つの方法があります。
o DHCPv6 Prefix-Delegation (PD)
O DHCPv6のプレフィックス委譲（PD）
o ISP provides a static IPv6 address range
O ISPは、静的IPv6アドレス範囲を提供します
For the DHCPv6-PD solution, a dynamic address allocation approach is chosen. By means of the enhanced DHCPv6 protocol, it is possible to have the ISP push down an IPv6 prefix range automatically towards the small private network and populate all interfaces in that small private network dynamically. This reduces the burden for administrative overhead because everything happens automatically.
DHCPv6の-PD溶液のために、動的アドレス割当アプローチが選択されます。強化されたDHCPv6プロトコルによって、ISPが小さなプライベートネットワークに向けて自動的にIPv6プレフィックス範囲を押し下げており、動的にその小さなプライベートネットワーク内のすべてのインターフェイスを移入することが可能です。すべてが自動的に行われるので、これは管理オーバーヘッドのための負担を軽減します。
For the static configuration, the mechanisms used could be the same as for the medium/large enterprises. Typically, the need for masking the topology will not be of high priority for these users, and the usage of IPv6 privacy extensions could be sufficient.
静的構成のために、使用されるメカニズムは、中/大企業の場合と同じであってもよいです。一般的に、これらのユーザーのために高い優先度ではありませんトポロジーをマスキングする必要性、およびIPv6のプライバシーの拡張機能の使用量は十分である可能性があります。
For both alternatives, the ISP has the unrestricted capability for summarization of its RIR-allocated IPv6 prefix, while the small private network administrator has all flexibility in using the received IPv6 prefix to its advantage because it will be of sufficient size to allow all the local nodes to have a public address and full range of ports available whenever necessary.
それはすべてのローカル可能にするのに十分な大きさのものであろうので、小さなプライベートネットワーク管理者はその利点に受信したIPv6プレフィックスを使用して、すべての柔軟性を持っていながら、両方の代替のために、ISPは、そのRIRに割り当てられたIPv6プレフィックスの要約のための無制限の能力を持っていますノードは、必要なときはいつでも利用可能なポートのパブリックアドレスおよび完全な範囲を持っています。
While a full prefix is expected to be the primary deployment model, there may be cases where the ISP provides a single IPv6 address for use on a single piece of equipment (PC, PDA, etc.). This is expected to be rare, though, because in the IPv6 world the assumption is that there is an unrestricted availability of a large amount of globally routable and unique address space. If scarcity was the motivation with IPv4 to provide RFC 1918 addresses, in this environment the ISP will not be motivated to allocate private addresses to the single user connection because there are enough global addresses available at essentially the same cost. Also, it will be likely that the single device wants to mask its identity to the called party or its attack profile over a shorter time than the life of the ISP attachment, so it will need to enable IPv6 privacy extensions. In turn, this leads to the need for a minimum allocation of a /64 prefix rather than a single address.
フルプレフィックスが主展開モデルであることが予想される一方で、ISPは、一つの機器（PC、PDAなど）の上で使用するための単一のIPv6アドレスを提供する場合があります。これは、IPv6の世界では仮定がグローバルにルーティング可能な、ユニークなアドレス空間の大量の無制限の利用可能性があるということですので、しかし、稀であることが予想されます。希少性はRFC 1918のアドレスを提供するためのIPv4との動機だった場合は、この環境でISPは本質的に同じコストで利用可能な十分なグローバルアドレスがあるので、単一のユーザ接続にプライベートアドレスを割り当てることが動機されることはありません。また、単一のデバイスが被呼者またはISPの添付ファイルの寿命よりも短い時間をかけてその攻撃プロファイルにその身元を隠すために望んでいることを可能性が高くなりますので、それは、IPv6プライバシー拡張を有効にする必要があります。ターンでは、これは/ 64プレフィックスの最小割り当てではなく、単一のアドレスの必要性につながります。
This group identifies the users that are connected via a single IPv4 address and use a single piece of equipment (PC, PDA, etc.). This user may get an ambiguous IPv4 address (frequently imposed by the ISP) from the service provider that is based on RFC 1918. If
このグループは、単一のIPv4アドレスを介して接続され、機器の単一片（PC、PDA、等）を使用しているユーザを識別する。このユーザーは、場合RFC 1918に基づいてサービスプロバイダから（しばしばISPによって課される）あいまいなIPv4アドレスを取得してもよいです
ambiguous addressing is utilized, the service provider will execute NAT on the allocated IPv4 address for global Internet connectivity. This also limits the Internet capability of the equipment to being mainly a receiver of Internet data, and it makes it quite hard for the equipment to become a worldwide Internet server (HTTP, FTP, etc.) due to the stateful operation of the NAT equipment.
利用されているアドレス指定のあいまいな、サービスプロバイダは、グローバルなインターネット接続のために割り当てられたIPv4アドレスのNATを実行します。また、これは主にインターネットデータの受信機であることに機器のインターネット機能を制限し、機器が原因NAT機器のステートフルな動作に世界中のインターネットサーバー（HTTP、FTPなど）になることは非常に難しいことになります。
When using IPv6 LNP, this group will identify the users that are connected via a single IPv6 address and use a single piece of equipment (PC, PDA, etc.).
IPv6 LNPを使用する場合、このグループは、単一のIPv6アドレスを介して接続されているユーザを識別し、機器の単一片（PC、PDAなど）を使用します。
In the IPv6 world, the assumption is that there is unrestricted availability of a large amount of globally routable and unique IPv6 addresses. The ISP will not be motivated to allocate private addresses to the single user connection because he has enough global addresses available, if scarcity was the motivation with IPv4 to provide RFC 1918 addresses. If the single user wants to mask his identity, he may choose to enable IPv6 privacy extensions.
IPv6の世界では、仮定は、グローバルにルーティング可能なユニークなIPv6アドレスの大量の無制限の利用可能性があるということです。彼は利用できる十分なグローバルアドレスを持っているので、希少性がRFC 1918のアドレスを提供するために、IPv4の持つ動機だった場合、ISPは、単一のユーザーの接続にプライベートアドレスを割り当てることが動機されることはありません。 1人のユーザーが自分の身元を隠すために望んでいるなら、彼は、IPv6プライバシー拡張を可能にすることもできます。
This group refers to the actual service providers that are providing the IP access and transport services. They tend to have three separate IP domains that they support:
このグループには、IPアクセス及び輸送サービスを提供している実際のサービス提供者を指します。彼らはサポートして3つの別々のIPドメインを持っている傾向があります。
o For the first, they fall into the medium/large private networks category (above) for their own internal networks, LANs, etc.
など独自の内部ネットワーク、LANの、のための最初のためにoが、彼らはメディアに落ちる/大規模なプライベートネットワークカテゴリ（上）
o The second is the Operations address domain, which addresses their backbone and access switches, and other hardware. This address domain is separate from the other address domains for engineering reasons as well as simplicity in managing the security of the backbone.
二O操作アドレス彼らのバックボーンとアクセススイッチに対処し、ドメイン、およびその他のハードウェアです。このアドレスドメインは、バックボーンのセキュリティを管理する上で、エンジニアリング上の理由から他のアドレスのドメインから別のと同様にシンプルです。
o The third is the IP addresses (single or blocks) that they assign to customers. These can be registered addresses (usually given to category 5.1 and 5.2 and sometimes 5.3) or can be from a pool of RFC 1918 addresses used with IPv4 NAT for single user connections. Therefore they can actually have two different NAT domains that are not connected (internal LAN and single user customers).
O第三は、彼らが顧客に割り当てることをIPアドレス（単一またはブロック）です。これらは、登録されたアドレス（通常カテゴリ5.1と5.2に与えられ、時には5.3）であり得るか、または単一ユーザ接続のIPv4 NATと共に使用RFC 1918のアドレスのプールからであってもよいです。したがって、彼らは実際に接続されていない2個の異なるNATドメイン（社内LANとシングルユーザー顧客）を持つことができます。
When IPv6 LNP is utilized in these three domains, then for the first category it will be possible to use the same solutions as described in Section 5.1. The second domain of the ISP/carrier is the Operations network. This environment tends to be a closed environment, and consequently communication can be done based on ULAs. However, in this environment, stable IPv6 Provider Independent addresses can be used. This would give a solid and scalable configuration with respect to a local IPv6 address plan. By the usage of proper network edge filters, outside access to the closed environment can be avoided. The third is the IPv6 addresses that ISP/carrier network assign to customers. These will typically be assigned with prefix lengths terminating on nibble boundaries to be consistent with the DNS PTR records. As scarcity of IPv6 addresses is not a concern, it will be possible for the ISP to provide globally routable IPv6 prefixes without a requirement for address translation. An ISP may for commercial reasons still decide to restrict the capabilities of the end users by other means like traffic and/or route filtering, etc.
IPv6のLNPは、これら三つのドメインで利用される場合、最初のカテゴリのためには、セクション5.1に記載したのと同じ溶液を使用することが可能となります。 ISP /キャリアの第二のドメインは、Operationsネットワークです。この環境は、閉鎖環境である傾向があり、その結果、通信がULAsに基づいて行うことができます。しかし、このような環境では、安定したIPv6プロバイダ独立アドレスを使用することができます。これは、ローカルIPv6アドレス計画に関して、固体とスケーラブルな構成を与えるだろう。適切なネットワークエッジフィルタの使用によって、閉鎖された環境への外部からのアクセスを回避することができます。第三は、IPv6は、ISP /キャリアネットワークは、顧客に割り当てることをアドレスです。これらは、典型的には、DNS PTRレコードと一致するように、プレフィックス長がニブル境界で終了して割り当てられます。 IPv6アドレスの不足が問題にならないようISPは、アドレス変換を必要とせずにグローバルにルーティング可能なIPv6プレフィックスを提供することが可能になります。 ISPは、商業的な理由は、まだ等のトラフィックおよび/またはルートフィルタリング、などの他の手段によって、エンドユーザーの能力を制限するように決定することができるため
If the carrier network is a mobile provider, then IPv6 is encouraged in comparison with the combination of IPv4+NAT for Third Generation Partnership Project (3GPP)-attached devices. In Section 2.3 of RFC 3314, 'Recommendations for IPv6 in 3GPP Standards' [9], it is found that the IPv6 WG recommends that one or more /64 prefixes should be assigned to each primary Protocol Data Packet (PDP) context. This will allow sufficient address space for a 3GPP-attached node to allocate privacy addresses and/or route to a multi-link subnet, and it will discourage the use of NAT within 3GPP-attached devices.
キャリアネットワークがモバイルプロバイダであれば、IPv6は、第3世代パートナーシップ・プロジェクト（3GPP）-attachedデバイスのIPv4 + NATの組み合わせと比較して奨励されています。 RFC 3314のセクション2.3で、「3GPP規格におけるIPv6のための推奨事項」[9]、IPv6 WGは、1つまたは複数の/ 64プレフィックスが各主要プロトコル・データ・パケット（PDP）コンテキストに割り当てられるべきであることをお勧めしていることがわかります。これは、プライバシーアドレス及び/又はマルチリンクサブネットへのルートを割り当てる3GPPに接続されたノードのために十分なアドレス空間を可能にするであろう、そしてそれは、3GPP接続デバイス内でNATを使用することを妨げるであろう。
Like IPv4 and any major standards effort, IPv6 standardization work continues as deployments are ongoing. This section discusses several topics for which additional standardization, or documentation of best practice, is required to fully realize the benefits or provide optimizations when deploying LNP. From a standardization perspective, there is no obstacle to immediate deployment of the LNP approach in many scenarios, though product implementations may lag behind the standardization efforts. That said, the list below identifies additional work that should be undertaken to cover the missing scenarios.
展開が進行中であるとして、IPv4およびすべての主要な標準化努力と同様に、IPv6の標準化作業が続行されます。このセクションでは、追加の標準化、またはベストプラクティスのドキュメントは、完全な利益を実現するか、LNPを展開する際の最適化を提供するために必要とされるいくつかのトピックについて説明します。製品の実装は、標準化活動より遅れるかもしれませんが、標準化の観点からは、多くのシナリオでLNPアプローチの即時展開に支障はありません。それは、以下のリストは、不足しているシナリオをカバーするために行われるべき追加作業を識別し、言いました。
Firewall traversal by dynamic pinhole management requires further study. Several partial solutions exist including Interactive Connectivity Establishment (ICE) [23], and Universal Plug and Play (UPNP) [24]. Alternative approaches are looking to define service provider mediated pinhole management, where things like voice call signaling could dynamically establish pinholes based on predefined authentication rules. The basic security provided by a stateful firewall will require some degree of default configuration and automation to mask the technical complexity from a consumer who merely wants a secure environment with working applications. There is no reason a stateful IPv6 firewall product cannot be shipped with default protection that is equal to or better than that offered by today's IPv4/NAT products.
ダイナミックなピンホール経営陣によるファイアウォールトラバーサルは、さらなる研究が必要です。いくつかの部分的な解決策は、インタラクティブ接続確立（ICE）[23]、およびユニバーサルプラグアンドプレイ（UPnP）[24]などが存在します。別のアプローチは、音声通話シグナリングのようなものを動的に事前に定義された認証ルールに基づいて、ピンホールを確立することができるサービスプロバイダ仲介ピンホール経営を定義しようとしています。ステートフルファイアウォールによって提供される基本的なセキュリティは、単に作業アプリケーションとの安全な環境を望んでいる消費者からの技術的な複雑さを隠蔽するために、デフォルトの設定と自動化をある程度必要になります。ステートフルIPv6ファイアウォール製品と同じか、今日のIPv4 / NATの製品で提供されるものよりも優れているデフォルトの保護に同梱することができない理由はありません。
There really is no functional standards gap here as a centrally assigned pool of addresses in combination with host routes in the IGP is an effective way to mask topology for smaller deployments. If necessary, a best practice document could be developed describing the interaction between DHCP and various IGPs that would in effect define Untraceable Addresses.
IGPでホストルートとの組み合わせでアドレスの一元割り当てられたプールが小規模な展開のためのトポロジーをマスクする効果的な方法であるとして、実際には機能的な基準ギャップがここにありません。必要に応じて、ベストプラクティス文書は、DHCPや効果にブラックサイトのアドレスを定義し、各種のIGPの間の相互作用を記述する開発することができます。
As an alternative for larger deployments, there is no gap in the HA tunneling approach when firewalls are configured to block outbound binding update messages. A border Home Agent using internal tunneling to the logical mobile (potentially rack mounted) node can completely mask all internal topology, while avoiding the strain from a large number of host routes in the IGP. Some optimization work could be done in Mobile IP to define a policy message where a mobile node would learn from the Home Agent that it should not try to inform its correspondent about route optimization and thereby expose its real location. This optimization, which reduces the load on the firewall, would result in less optimal internal traffic routing as that would also transit the HA unless ULAs were used internally. Trade-offs for this optimization work should be investigated in the IETF.
ファイアウォールはアウトバウンドバインディング更新メッセージをブロックするように構成されているときに大規模な展開のための代替として、HAトンネルアプローチには隙間が存在しません。論理モバイル内部トンネリングを使用して境界ホームエージェント（潜在的に取り付けられたラック）IGPにおけるホストルートの多数の歪みを回避しつつ、ノードは完全に、すべての内部トポロジをマスクすることができます。一部の最適化作業は、モバイルノードがルート最適化についてその対応を通知しようとし、それによってその実際の場所を公開してはならないことをホームエージェントから学ぶでしょうポリシーのメッセージを定義するために、モバイルIPで行うことができます。 ULAsが内部的に使用された場合を除き、ファイアウォールの負荷を軽減し、この最適化は、その考えもトランジットHAとしてはあまり最適な内部トラフィックのルーティングにつながります。この最適化作業のためのトレードオフは、IETFで調査する必要があります。
Privacy addresses [7] may certainly be used to limit the traceability of external traffic flows back to specific hosts, but lacking a topology masking component above they would still reveal the subnet address bits. For complete privacy, a best practice document describing the combination of privacy addresses and topology masking may be required. This work remains to be done and should be pursued by the IETF.
プライバシーアドレス[7]確かに外部トラフィックの追跡可能性を制限するために使用することができるバック特定のホストに流れ、それらは依然としてサブネットアドレスビットを明らかにするであろう上方トポロジーマスキング成分を欠いています。完全なプライバシーのために、プライバシーアドレスとトポロジマスキングの組み合わせを記述したベストプラクティスの文書が必要になることがあります。この作業は行う必要が残り、IETFによって追求されなければなりません。
This complex problem has never been completely solved for IPv4, which is exactly why NAT has been used as a partial solution. For IPv6, after several years of work, the IETF has converged on an architectural approach intended with service restoration as initial aim [22]. When this document was drafted, the IETF was actively defining the details of this approach to the multihoming problem. The approach appears to be most suitable for small and medium sites, though it will conflict with existing firewall state procedures. At this time, there are also active discussions in the address registries investigating the possibility of assigning provider-independent address space. Their challenge is finding a reasonable metric for limiting the number of organizations that would qualify for a global routing entry. Additional work appears to be necessary to satisfy the entire range of requirements.
この複雑な問題は完全にNATが部分的な解決策として使用されてきた理由を正確されているIPv4のために解決されていません。 IPv6の場合、仕事の数年後に、IETFは、初期の目的としてサービスの復旧を目的とする建築アプローチ[22]に収束しました。この文書が起草されたときに、IETFは、積極的にマルチホーミングの問題に対するこのアプローチの詳細を定義しました。アプローチは、既存のファイアウォールの状態手順と競合するものの、中小のサイトのために最も適しているように思われます。このとき、プロバイダに依存しないアドレス空間の割り当ての可能性を調査アドレスレジストリでの活発な議論もあります。彼らの挑戦は、グローバルルーティングエントリの対象となり組織の数を制限するための合理的なメトリックを見つけることです。追加の作業は必要条件の全範囲を満足する必要があるように思われます。
While issues that are potentially security related are discussed throughout the document, the approaches herein do not introduce any new security concerns. IPv4 NAT has been widely sold as a security tool, and suppliers have been implementing address translation functionality in their firewalls, though the true impact of NATs on security has been previously documented in [2] and [4].
潜在的なセキュリティ関連している問題は、文書を通して議論されていますが、アプローチは、ここにどんな新しい安全保障上の懸念を導入していません。セキュリティ上のNATの真の影響は、以前に記載したが、IPv4のNATが広くセキュリティツールとして販売されており、供給業者は、それらのファイアウォールのアドレス変換機能を実装されている[2]と[4]。
This document defines IPv6 approaches that collectively achieve the goals of the network manager without the negative impact on applications or security that are inherent in a NAT approach. While Section 6 identifies additional optimization work, to the degree that these techniques improve a network manager's ability to explicitly audit or control access, and thereby manage the overall attack exposure of local resources, they act to improve local network security.
この文書では、集合的にNATアプローチに固有のアプリケーションやセキュリティに悪影響を与えることなく、ネットワーク管理の目標を達成するためのIPv6アプローチを定義します。第6節は、これらの技術は、明示的にアクセスを監査または制御するために、ネットワーク管理者の能力を向上させる程度に、追加の最適化作業を識別し、それによって、地域資源の全体的な攻撃のリスクを管理しながら、彼らは、ローカルネットワークのセキュリティを向上させるように作用します。
This document has described a number of techniques that may be combined on an IPv6 site to protect the integrity of its network architecture. These techniques, known collectively as Local Network Protection, retain the concept of a well-defined boundary between "inside" and "outside" the private network and allow firewalling, topology hiding, and privacy. However, because they preserve address transparency where it is needed, they achieve these goals without the disadvantage of address translation. Thus, Local Network Protection in IPv6 can provide the benefits of IPv4 Network Address Translation without the corresponding disadvantages.
この文書では、そのネットワークアーキテクチャの整合性を保護するためにIPv6サイト上で組み合わせることができる多くの技術が記載されています。ローカルネットワーク保護と総称されるこれらの技術は、「内部」と「外部」との間に明確に定義された境界の概念を保持プライベートネットワークやファイアウォール、トポロジ隠蔽、およびプライバシーを可能にします。それが必要とされるところ、彼らはアドレスの透明性を維持するためしかし、彼らは、アドレス変換の欠点なしにこれらの目標を達成します。このように、IPv6におけるローカルネットワークの保護には、対応する欠点がないのIPv4ネットワークアドレス変換の利益を提供することができます。
The document has also identified a few ongoing IETF work items that are needed to realize 100% of the benefits of LNP.
文書はまた、LNPの恩恵を100％実現するために必要とされているいくつかの継続的なIETFの作業項目を特定しました。
Christian Huitema has contributed during the initial round table to discuss the scope and goal of the document, while the European Union IST 6NET project acted as a catalyst for the work documented in this note. Editorial comments and contributions have been received from: Fred Templin, Chao Luo, Pekka Savola, Tim Chown, Jeroen Massar, Salman Asadullah, Patrick Grossetete, Fred Baker, Jim Bound, Mark
欧州連合IST 6NETプロジェクトは、このノートに記載の作業のための触媒を務めながら、クリスチャンのHuitemaは、ドキュメントのスコープと目標を議論するために、最初のラウンドテーブルの間に貢献してきました。フレッド・テンプリン、チャオ羅、ペッカSavola、ティムのchown、イェルーンMassar、サルマンAsadullah、パトリックGrossetete、フレッド・ベイカー、ジムバウンド、マーク：社説のコメントと貢献から受信されています
Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, Elwyn Davies, Daniel Senie, Soininen Jonne, Kurt Erik Lindqvist, Cullen Jennings, and other members of the v6ops WG and IESG.
スミス、アラン・デュラン、ジョン・スペンス、クリスチャンのHuitema、マーク・スミス、エルウィン・デイヴィス、ダニエルSenie、Soininen Jonne、クルト・エリックLindqvist、カレン・ジェニングス、そしてv6ops WGとIESGの他のメンバー。
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[1] Rekhter、Y.、モスコウィッツ、R.、Karrenberg、D.、グルート、G.、およびE.リア、 "個人的なインターネットのための配分"、BCP 5、RFC 1918、1996年2月を。
[2] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
[2] Srisuresh、P.とM.ホールドレッジ、 "IPネットワークアドレス変換（NAT）用語と考慮事項"、RFC 2663、1999年8月。
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3] Narten氏、T.、Nordmarkと、E.、およびW.シンプソン、 "IPバージョン6（IPv6）のための近隣探索"、RFC 2461、1998年12月。
[4] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[4]ハイン、T.、 "NATの建築的意味"、RFC 2993、2000年11月。
[5] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[5] Srisuresh、P.とK. Egevang、 "伝統的なIPネットワークアドレス変換（NAT繁体字）"、RFC 3022、2001年1月。
[6] Holdrege, M. and P. Srisuresh, "Protocol Complications with the IP Network Address Translator", RFC 3027, January 2001.
[6]ホールドレッジ、M.とP. Srisuresh、 "IPネットワークアドレス変換とプロトコルの合併症"、RFC 3027、2001年1月。
[7] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[7] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[8] IAB and IESG, "IAB/IESG Recommendations on IPv6 Address Allocations to Sites", RFC 3177, September 2001.
[8] IABとIESG、 "サイトへのIPv6アドレスの割り当てにIAB / IESG勧告"、RFC 3177、2001年9月。
[9] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[9]、RFC 3314、2002年9月ワッサーマン、M.、 "第三世代パートナーシッププロジェクト（3GPP）規格におけるIPv6のための推奨事項"。
[10] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[10] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニー、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[11] Draves、R.、RFC 3484 "インターネットプロトコルバージョン6（IPv6）のデフォルトのアドレス選択"、2003年2月。
[12] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, December 2003.
[12] Troan、O.とR. Droms、RFC 3633、2003年12月 "動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション"。
[13] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[13] Huttunen、A.、Swander、B.、ボルペ、V.、DiBurro、L.、及びM.ステンバーグ、 "IPsecのESPパケットのUDPカプセル化"、RFC 3948、2005年1月。
[14] Savola, P. and B. Haberman, "Embedding the Rendezvous Point (RP) Address in an IPv6 Multicast Address", RFC 3956, November 2004.
[14] Savola、P.とB.ハーバーマン、 "IPv6マルチキャストアドレスでのランデブーポイント（RP）アドレスを埋め込み"、RFC 3956、2004年11月。
[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[15] Arkko、J.、ケンプ、J.、Zill、B.、およびP. Nikander、 "セキュア近隣探索（SEND）"、RFC 3971、2005年3月。
[16] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[16]ベーカー、F.、リア、E.、およびR. Droms、 "フラグ日なしIPv6ネットワークをリナンバリングするための手順"、RFC 4192、2005年9月。
[17] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[17] HindenとR.とB.ハーバーマン、 "ユニークローカルIPv6ユニキャストアドレス"、RFC 4193、2005年10月。
[18] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[18]フラー、V.およびT.李、 "クラスレスドメイン間ルーティング（CIDR）：インターネットアドレスの割り当てと集計プラン"、BCP 122、RFC 4632、2006年8月。
[19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Work in Progress, June 2004.
[19]デュポン、F.およびP. Savola、 "有害と考えられRFC 3041"、進歩、2004年6月での作業。
[20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Work in Progress, October 2005.
[20]のchown、T.、 "TCP / UDPポートスキャンのためのIPv6への影響"、進歩、2005年10月に作業。
[21] Chown, T., Tompson, M., Ford, A., and S. Venaas, "Things to think about when Renumbering an IPv6 network", Work in Progress, September 2006.
[21]のchown、T.、トンプソン、M.、フォード、A.、およびS. Venaas、進歩、2006年9月の作業 "IPv6ネットワークのリナンバリング時に考えること"。
[22] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", Work in Progress, July 2005.
[22]ヒューストン、G.進歩、2005年7月、仕事、「レベル3シムを使用してサイトマルチホーミングの建築解説」。
[23] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Methodology for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", Work in Progress, October 2006.
[23]ローゼンバーグ、J.、「インタラクティブ接続確立（ICE）：オファー/回答プロトコルのためのネットワークアドレス変換（NAT）トラバーサルのための方法論」、進歩、2006年10月に作業。
[24] "Universal Plug and Play Web Site", July 2005, <http://www.upnp.org/>.
[24] "ユニバーサルプラグアンドプレイのWebサイト"、2005年7月、<http://www.upnp.org/>。
Appendix A. Additional Benefits Due to Native IPv6 and Universal Unique Addressing
ネイティブIPv6と汎用一意に起因付録A.追加の利点は、アドレッシング
The users of native IPv6 technology and globally unique IPv6 addresses have the potential to make use of the enhanced IPv6 capabilities, in addition to the benefits offered by the IPv4 technology.
ネイティブのIPv6技術のユーザーとグローバルに一意のIPv6アドレスは、IPv4の技術によって提供される利点に加えて、強化されたIPv6機能を利用する可能性を秘めています。
A.1. Universal Any-to-Any Connectivity
A.1。ユニバーサルどれ-to-anyの接続
One of the original design points of the Internet was any-to-any connectivity. The dramatic growth of Internet-connected systems coupled with the limited address space of the IPv4 protocol spawned address conservation techniques. NAT was introduced as a tool to reduce demand on the limited IPv4 address pool, but the side effect of the NAT technology was to remove the any-to-any connectivity capability. By removing the need for address conservation (and therefore NAT), IPv6 returns the any-to-any connectivity model and removes the limitations on application developers. With the freedom to innovate unconstrained by NAT traversal efforts, developers will be able to focus on new advanced network services (i.e., peer-to-peer applications, IPv6-embedded IPsec communication between two communicating devices, instant messaging, Internet telephony, etc.) rather than focusing on discovering and traversing the increasingly complex NAT environment.
インターネットのオリジナルデザインのポイントの一つは、任意の-to-anyの接続でした。 IPv4プロトコルの限られたアドレス空間と結合されたインターネット接続システムの劇的な成長は、アドレス保全技術を生み出しました。 NATは、制限されたIPv4アドレスプールの需要を減らすためのツールとして導入されましたが、NAT技術の副作用はどの-to-anyの接続機能を削除することでした。 （したがって、およびNAT）アドレスの保全の必要性を除去することにより、IPv6はどの-to-anyの接続モデルを返し、アプリケーション開発者に制限を削除します。 NATトラバーサルの努力にとらわれない革新する自由で、開発者は新しい高度なネットワークサービス（すなわち、ピア・ツー・ピアアプリケーション、2つの通信デバイス間のIPv6-埋め込まれたIPsec通信、インスタントメッセージング、インターネット電話などに注力することができるようになります）むしろ、ますます複雑NAT環境を発見し、横断に焦点を当てたよりも。
It will also allow application and service developers to rethink the security model involved with any-to-any connectivity, as the current edge firewall solution in IPv4 may not be sufficient for any-to-any service models.
また、IPv4では現在のエッジファイアウォールソリューションがどの-to-anyのサービスモデルのために十分ではない可能性があるとして、アプリケーションとサービスの開発者は、任意の-to-anyの接続に関わるセキュリティモデルを再考することができます。
A.2. Auto-Configuration
A.2。自動設定
IPv6 offers a scalable approach to minimizing human interaction and device configuration. IPv4 implementations require touching each end system to indicate the use of DHCP vs. a static address and management of a server with the pool size large enough for the potential number of connected devices. Alternatively, IPv6 uses an indication from the router to instruct the end systems to use DHCP or the stateless auto-configuration approach supporting a virtually limitless number of devices on the subnet. This minimizes the number of systems that require human interaction as well as improves consistency between all the systems on a subnet. In the case that there is no router to provide this indication, an address for use only on the local link will be derived from the interface media layer address.
IPv6は、人間の相互作用とデバイス構成を最小限にスケーラブルなアプローチを提供しています。 IPv4の実装では、接続されたデバイスの潜在的な数のために十分な大きさのプール・サイズとサーバの静的アドレスと管理対DHCPの使用を示すために、各エンドシステムに触れる必要とします。あるいは、IPv6はDHCPまたはサブネット上のデバイスの実質的に無限数の支持ステートレス自動設定方法を使用するエンド・システムに指示するルータからの指示を使用します。これは、人間の相互作用だけでなく、サブネット上のすべてのシステム間の一貫性を向上させることを必要とするシステムの数を最小限に抑えることができます。この指示を提供するために何ルータが存在しないと場合にのみ、ローカルリンク上の使用のためのアドレスは、インタフェース媒体層アドレスから導出されます。
A.3. Native Multicast Services
A.3。ネイティブマルチキャストサービス
Multicast services in IPv4 were severely restricted by the limited address space available to use for group assignments and an implicit locally defined range for group membership. IPv6 multicast corrects this situation by embedding explicit scope indications as well as expanding to 4 billion groups per scope. In the source-specific multicast case, this is further expanded to 4 billion groups per scope per subnet by embedding the 64 bits of subnet identifier into the multicast address.
IPv4のマルチキャストサービスがひどくグループの割り当てのために使用するために利用できる限られたアドレス空間とグループメンバーシップのための暗黙のローカルに定義された範囲で制限されました。 IPv6マルチキャストは、明示的なスコープの表示を埋め込むだけでなく、範囲あたり40億個のグループに拡大することにより、この状況を修正します。ソース固有マルチキャストの場合、これはさらに、マルチキャストアドレスにサブネット識別子の64ビットを埋め込むことによって、サブネットごと範囲あたり40億個のグループに拡張されます。
IPv6 allows also for innovative usage of the IPv6 address length and makes it possible to embed the multicast Rendezvous Point (RP) [14] directly in the IPv6 multicast address when using Any-Source Multicast (ASM). This is not possible with the limited size of the IPv4 address. This approach also simplifies the multicast model considerably, making it easier to understand and deploy.
IPv6は、IPv6アドレスの長さの革新的な使用のためにも可能にし、任意-ソースマルチキャスト（ASM）を使用する場合、IPv6マルチキャストアドレスに直接マルチキャストランデブーポイント（RP）[14]を埋め込むことが可能となります。これは、IPv4アドレスの制限されたサイズでは不可能です。このアプローチは、それが簡単に理解し、展開すること、かなりマルチキャストモデルを簡素化します。
A.4. Increased Security Protection
A.4。セキュリティ強化の保護
The security protection offered by native IPv6 technology is more advanced than IPv4 technology. There are various transport mechanisms enhanced to allow a network to operate more securely with less performance impact:
ネイティブのIPv6技術によって提供されるセキュリティ保護は、IPv4の技術よりも進んでいます。ネットワークが少なく、パフォーマンスへの影響をより安全に動作することを可能にするために強化され、さまざまなトランスポート・メカニズムがあります。
o IPv6 has the IPsec technology directly embedded into the IPv6 protocol. This allows for simpler peer-to-peer authentication and encryption, once a simple key/trust management model is developed, while the usage of some other less secure mechanisms is avoided (e.g., MD5 password hash for neighbor authentication).
O IPv6は直接IPv6プロトコルに組み込まれたIPsec技術を持っています。他のいくつかの安全性の低いメカニズムの使用を回避しつつ、これは単純なピア・ツー・ピアの認証と暗号化が可能になり、一度簡単なキー/信用管理モデルは、開発された（例えば、ネイバー認証のためにMD5パスワードハッシュ）。
o While a firewall is specifically designed to disallow applications based on local policy, it does not interfere with those that are allowed. This is a security improvement over NAT, where the work-arounds to enable applications allowed by local policy are effectively architected man-in-the-middle attacks on the packets, which precludes end-to-end auditing or IP level identification.
ファイアウォールは、具体的に、ローカルポリシーに基づいてアプリケーションを許可しないように設計されていますが、O、それは許可されているものを妨げることはありません。これは、エンドツーエンドの監査またはIPレベルの識別を妨げるパケットのman-in-the-middle攻撃ローカルポリシーによって許可されたアプリケーションを有効にする回避策が効果的に設計されているNAT、上のセキュリティの改善、です。
o All flows on the Internet will be better traceable due to a unique and globally routable source and destination IPv6 address. This may facilitate an easier methodology for back-tracing Denial of Service (DoS) attacks and avoid illegal access to network resources by simpler traffic filtering.
O、インターネット上のすべてのフローが原因ユニークかつグローバルにルーティング可能な送信元と宛先のIPv6アドレスに良くトレーサブルになります。これは、サービス拒否（DoS）攻撃のバックトレース拒否のためのより容易な方法論を容易にし、シンプルなトラフィックフィルタリングにより、ネットワークリソースへの不正アクセスを回避することができます。
o The usage of private address space in IPv6 is now provided by Unique Local Addresses, which will avoid conflict situations when merging networks and securing the internal communication on a local network infrastructure due to simpler traffic filtering policy.
oをIPv6でのプライベートアドレス空間の使用量は、現在のネットワークを融合し、より単純なトラフィックフィルタリングポリシーのために、ローカル・ネットワーク・インフラストラクチャ上の内部通信を確保する際に、競合状況を避けることができますユニークローカルアドレスによって提供されます。
o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source-routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source route header.
oをネットワークインフラストラクチャ上でソースルーティングを可能にする技術は、中間ネットワークデバイスの処理能力に影響を与えることなく、関数にこの機能を許可するように強化されました。ソースルーティングに影響を受ける唯一のデバイスは、ソースと宛先ノードと中間ソースルートノードであろう。 IPv4を使用する場合、すべての中間デバイスがソースルートヘッダに見なければならなかったため、この衝撃挙動は、異なっています。
A.5. Mobility
A.5。可動性
Anytime, anywhere, universal access requires MIPv6 services in support of mobile nodes. While a Home Agent is required for initial connection establishment in either protocol version, IPv6 mobile nodes are able to optimize the path between them using the MIPv6 option header, while IPv4 mobile nodes are required to triangle route all packets. In general terms, this will minimize the network resources used and maximize the quality of the communication.
いつでも、どこでも、ユニバーサル・アクセスは、モバイルノードのサポートにMIPv6のサービスを必要とします。ホームエージェントは、プロトコルバージョンのいずれかで初期接続確立のために必要とされている間のIPv4モバイルノードが三角形のルートすべてのパケットに必要とされているが、IPv6の移動ノードは、MIPv6のオプションヘッダを使用してそれらの間の経路を最適化することができます。一般的に言えば、これは、使用するネットワークリソースを最小限に抑え、通信の品質を最大化します。
A.6. Merging Networks
A.6。ネットワークのマージ
When two IPv4 networks want to merge, it is not guaranteed that both networks are using different address ranges on some parts of the network infrastructure due to the usage of RFC 1918 private addressing. This potential overlap in address space may complicate a merging of two and more networks dramatically due to the additional IPv4 renumbering effort, i.e., when the first network has a service running (NTP, DNS, DHCP, HTTP, etc.) that needs to be accessed by the second merging network. Similar address conflicts can happen when two network devices from these merging networks want to communicate.
2つのIPv4ネットワークをマージしたい場合は、両方のネットワークアドレッシングによる民間RFC 1918の使用にネットワークインフラストラクチャの一部に異なるアドレス範囲を使用していることを保証するものではありません。アドレス空間のこの潜在的な重複が原因第1のネットワークがあることが必要である（NTP、DNS、DHCP、HTTPなど）を実行しているサービスがあり、追加のIPv4のリナンバリングの努力、すなわち、に劇的に2と複数のネットワークの融合を複雑にする可能性があります第二合流ネットワークによってアクセス。これらのマージネットワークから2つのネットワークデバイスが通信したい場合にも、同様のアドレスの競合が発生する可能性があります。
With the usage of IPv6, the addressing overlap will not exist because of the existence of the Unique Local Address usage for private and local addressing.
IPv6のの使用によって、アドレッシングの重複があるため、民間や地域のアドレッシングのためのユニークローカルアドレスの使用の有無に存在しません。
Authors' Addresses
著者のアドレス
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
ギュンター・ヴァン・デ・ヴェルデシスコシステムズKleetlaan図6aディーゲム1831ベルギー
Phone: +32 2704 5473 EMail: gunter@cisco.com
電話：+32 2704 5473 Eメール：gunter@cisco.com
Tony Hain Cisco Systems 500 108th Ave. NE Bellevue, Wa. USA
トニーハインシスコシステムズ500第108アベニュー。 NEベルビュー、ワシントン州。米国
EMail: alh-ietf@tndh.net
メールアドレス：alh-ietf@tndh.net
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ラルフDromsシスコシステムズ1414年マサチューセッツアベニューボックスボロー、MA 01719 USA
EMail: rdroms@cisco.com
メールアドレス：rdroms@cisco.com
Brian Carpenter IBM 8 Chemin de Blandonnet 1214 Vernier, CH
ブライアン・カーペンターIBM 8シュマン・デ・Blandonnet 1214バーニア、CH
EMail: brc@zurich.ibm.com
メールアドレス：brc@zurich.ibm.com
Eric Klein Tel Aviv University Tel Aviv, Israel
エリック・クラインテルアビブ大学テルアビブ、イスラエル
EMail: ericlklein.ipv6@gmail.com
メールアドレス：ericlklein.ipv6@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（C）IETFトラスト（2007）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットSOCIETY、（もしあれば）を後援し、IETF TRUST ANDインターネットエンジニアリングタスクフォース放棄ALLに設けられています。保証は、明示または黙示、この情報の利用および特定目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証がこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。