[要約] RFC 4864は、IPv6のローカルネットワーク保護に関するガイドラインです。その目的は、IPv6ネットワーク内のホストとネットワークのセキュリティを向上させることです。
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
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）The IETF Trust（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]によるアプリケーションへの重大な欠点と影響は十分に文書化されているため、ここではそれほど多くの議論はありません。ただし、その幅広い展開を考えると、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ネットワークでどのように満たすことができるかを示します。ネットワークマネージャーの目標を達成するために機能するアプローチについて議論するため、このドキュメントは「情報的」であることに注意する必要があります。特に、ネットワークの構成方法に関する1つのアプローチまたはマニュアルを推奨するのは、特に最良の現在のプラクティス（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.
3. ネットワークの端でノードが接続されているように見える機能は、一連の問題を解決します。
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. 公開されていないアドレスを持つ機能は、さらに別のセットを解決します（主に状態が変更され、最初のセットの要件を拡大します）。
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）として知られているこれらの手法は、プライベートネットワークの「内部」と「外側」の間の明確に定義された境界の概念を保持しながら、ファイアウォール、トポロジーの隠れ、プライバシーを許可します。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 NATの市場化された利点を、IPv4環境とIPv6環境の両方でどのように配信するかについて相互参照します。
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.
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アプローチの後の説明のコンテキストを設定することです。
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デバイスは、プライベートネットワークを、スペースの任意の部分（曖昧な[1]またはグローバル登録アドレスおよび未登録のアドレス）から割り当てられたアドレスをインターネットに接続できますが、NATの両側に同じ範囲が存在する場合は追加の労力が必要です。プライベートネットワークのアドレススペースは、曖昧なアドレス空間から、または同時に、グローバルに一意のアドレスから構築できます。プライベート使用アドレスの単純なケースでは、特定の構成を必要とせずに、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.
幅広い展開により、NATを使用してプライベートIPv4ネットワークをインターネットに接続するシンプルなゲートウェイとして機能することは、非技術的なエンドユーザーにとってシンプルで実用的であることが示されています。多くの場合、シンプルなユーザーインターフェイスまたはデフォルトの構成でさえ、デバイスとアプリケーションの両方のアクセス権を構成するのに十分です。
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.
ヘッダー内のアドレスビットを翻訳する行為は、それ自体がセキュリティを提供しません。たとえば、Static 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で説明した単純なルーターと比較して、管理の複雑さを追加します。2つ以上のデバイスが同じアプリケーションをホストするか、そうでなければ同じパブリックポートを使用する必要がある状況では、この複雑さは困難なものから不可能に移行します。
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の1つの使用法は、ローカルネットワーク管理者がユーザーとアプリケーションのトラフィックを追跡することです。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-Addressとネットワーク要素またはユーザーの間のマッピングがあるか、管理者がアドレス/ポートマッピングの時間相関リストを持っているということのない仮定がありません。
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つは、外部のエンティティがローカルネットワーク上のデバイスのトポロジカル位置間に相関関係を築くことを防ぐことです。NATが、グローバルにルーティング可能な単一の（または少数の）IPv4アドレス（ES）を使用することにより、ユーザーの大規模なコミュニティにインターネットアクセスを提供する機能は、ネットワークの内部トポロジを隠す簡単なメカニズムを提供します。このシナリオでは、大規模なコミュニティは、単一の（または少数の）IPv4アドレス（ES）によってインターネットで表されます。
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ユーザーの「プライバシー」は、元の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.
一部のネットワークマネージャーは、スキャン攻撃を緩和するための有用な予防策として、部外者からの内部ネットワークトポロジの可能な限り隠すことを好みます。主に、これは「Traceroute」などをブロックすることで達成されますが、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.
もう1つの利点は、ネットワークインフラストラクチャの大部分で独立したアドレスを使用するため、プロバイダーを最小限の運用上の難しさで変更する能力です。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.
たとえば、デバイスからインターネットを移動するときにアクセスされるWebサイトなど、デバイスプロファイリングを防ぐことが望ましい状況があります。IPv6プライバシーアドレスは、その機能を提供するために定義されました。IPv6アドレスは、ルーティングプレフィックス、サブネットID（SID）パーツ、およびインターフェイス識別子（IID）パーツで構成されています。当初定義されているように、IPv6 StatelessアドレスAuto Configuration（SLAAC）は、通常、インターフェイスのIEEEリンク識別子をIID部分として埋め込みますが、この慣行は一貫したIIDを介したデバイスの追跡とプロファイリングを容易にします。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 IDIFIERのRFC 3041アルゴリズムを実行するダイナミックホスト構成プロトコル（DHCP）サーバーを妨げるものは何もありません。リクエストで聞き、将来のクエリのためにそれを覚えています。これにより、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].
RFC 3041で定義されているように、IIDをランダム化することは、事実上、IPv6アドレスの低い64ビットの追跡のみを排除するスパース割り当て手法です。サブネットIDのマスキングには、セクション3.4で説明するように、追加のアプローチが必要です。追加の考慮事項は[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つ以上のプロバイダー間の移動中のローカルネットワークおよびアプリケーションサービスの安定性に必要です。単一のルーティングプレフィックス環境でのこのような自律性は、グローバルルーティングテーブルの大規模な拡張につながるため（IPv4に見られるように）、IPv6は複数のプレフィックスの同時使用を提供します。一意のローカルアドレス（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年よりもFC00 ::/7よりも高い優先権を与えることにより、この選択にバイアスする1つの方法です。2種類のアドレスを混合すると、不安定な時期には配信不可能なパケットが発生する可能性がありますが、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.
単純なゲートウェイの機能の1つは、ローカル使用アドレス範囲を管理することです。プレフィックス委任（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アドレスは、単一 /64（または短い）プレフィックス内であっても不足していないため、不トレース性が必要な場合にランダムに効果的に生成することができます。これらは、サイトのプレフィックスの下でグローバルにルーティング可能なIPv6アドレスとなり、IPv6デバイスにランダムかつ独立して割り当てることができます。ランダムな割り当ては、ローカルネットワークの構造について外の世界を誤解させることを目的としています。特に、サブネット構造はアドレスでは見えない場合があります。したがって、サイト内でフラットルーティングメカニズムが必要になります。ローカルルーターは、デバイスのトポロジカル位置と実行不可能なIPv6アドレスとの間の相関を維持する必要があります。小規模な展開の場合、この相関は、IPv6ホストルートエントリを生成することで、またはモバイルIPv6ホームエージェントなどの間接デバイスを使用することで大きな相関を行うことができます。追加の詳細はセクション4.7にあります。
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.
外部接続を使用すると、Simple Gatewayは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.
2. IPv6の実装のための必須サービスであるため、セキュリティが改善される理由として、IPセキュリティ（IPSEC）がしばしば引用されます。より広い可用性は、主要なインフラストラクチャの可用性によって依然としてその使用が規制されているため、セキュリティを改善するものではありません。IPSECは、特派員を認証し、セッションのハイジャックを防ぎ、コンテンツの改ざんを防ぎ、オプションでパケットのコンテンツをマスクする機能を機能させます。IPSECは一般に一部のIPv4実装で利用可能であり、拡張機能を使用するとNATトラバーサルがサポートできますが、NATサポートには制限があり、すべての状況では機能しません。NATを使用したIPSECを使用するには、追加のUDPカプセル化とキープライブオーバーヘッドが必要です[13]。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. 典型的なサブネット（64ビットのIID）のアドレススペースのサイズは、通常、IPv4よりも完全に硬く、より高価になります[20]。識別されたノードでのポートスキャンのセキュリティ脅威を減らすには、隣接するノードを見つけるスキャンの確率を最小限に抑えるために、サブネット内のまばらな分布が必要です。IIDがIIDスペース内の構造化されたグループで構成されている場合、このスキャン保護は無効になります。IIDが利用可能なスペース全体に本質的にランダムに分散されている場合、アドレススキャンベースの攻撃は事実上失敗します。この保護は、攻撃者が特定のサブネットに直接アクセスできず、したがってリモートでスキャンしようとしている場合に存在します。攻撃者がローカルアクセスを持っている場合、彼はNeighbor Discovery（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（典型的な100 Mbps LANの400倍、典型的なDSL/ケーブルアクセスリンクの13,000倍）では、1つの64ビットサブネット全体をスキャンするのに5、000年以上かかります。
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が2つ以上のデバイス間の通信交換に関する非常に詳細な情報を取得することができます。プライバシーアドレス[7]が使用されていない限り、IPv6 NATと比較してセキュリティ監査のデータフロー追跡の機能が強化されます。これは、IPv6では送信者とレシーバー間のフローが常に一意のIPv6ソースと宛先のために一意に識別されるためアドレス。
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.
IPv6では、RFC 3041擬似ランダムプライバシーアドレス[7]を使用して、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ランダム化の両方を実行する場合、カジュアルなスヌーパーはネットワークのトポロジについて多くを推測することができません。単一のアドレスを取得すると、Snooperに他のアドレスについてほとんどわかりません。これは、アドレススペースの制限によりこれが真でないようにする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トポロジを完全に分離したい場合、およびその内部使用アドレスの大部分については、一意のローカルアドレス（ULA）を使用してすべての内部トラフィックを実行することです。定義上、このプレフィックスブロックはパブリックルーティングシステムで宣伝されるべきではないため、ルーティングパスがなければ外部トラフィックはサイトに到達しません。複数の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 1つのアプローチでは、インテリアゲートウェイプロトコル（IGP）の明示的なホストルートを使用して、物理トポロジのアタッチメントポイントとエンドツーエンドのIPv6アドレスとの外部相関を削除します。上の図では、ホストは1つ以上の論理サブネットから接頭辞を割り当てられ、ホストルートをIGPに注入して、実際のアタッチメントポイントを内部的に識別します。ただし、このソリューションは深刻なスケーラビリティの問題を示しており、ホストがIGPに安全に参加する必要があり、ファイアウォールブロックはすべての外部外部トレーサーの外部から論理サブネットをブロックする必要があります。特定の制限は、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 内部トポロジーを完全に隠すためのもう1つの技術的アプローチは、トンネルメカニズムの使用です。ルート最適化のないモバイルIPv6は、ホームエージェント（HA）を介して常にトンネルモードで開始されるため、自動トンネルを使用するための1つのアプローチです。この展開モデルでは、ノードのアプリケーション知覚アドレスは、トポロジーマスキングルーター（上記）として機能するエッジHAを介してルーティングされます。この間接的な方法は、ローカルネットワークの外側からのすべてのノードが、実際のアタッチメントポイントではなくHAに接続されている1つ以上の論理サブネットのプレフィックスを共有するように見えるため、内部トポロジを真にマスクします。この使用状況のコンテキストでは、HAはネットワークの端でNAT関数を置き換えているため、トンネルを介してHAへのルーティングの追加の遅延に関する懸念は、NATトラフィックがそうする同じ経路に効果的に適用されないことに注意してください。取った。複製アドレスの検出は、HAバインディングアップデートの通常のプロセスとして処理されます。特派員ノードを使用したすべてのバインディングアップデートをオフにしている間、トポロジー情報の漏れを防ぐために必要であると思われますが、そのアプローチは、ホームアドレスを使用してすべての内部トラフィックをHAトンネルを介してルーティングするように強制します。より効率的な方法は、ファイアウォールでアウトバウンドバインディングアップデートメッセージを削除しながら、内部ルートの最適化を許可することです。内部トラフィックのもう1つのアプローチは、RFC 3484のポリシーテーブルを使用して内部的に優先されるULAプレフィックスをバイアスし、論理サブネットのホームアドレスを外部に使用することです。モバイル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トポロジが許可する場合）は、仮想LANアプローチを使用して、デバイスをエッジルーターの1つ以上のサブネットに論理的に取り付けます。このアプローチにより、エンドノードが実際に共通のセグメントを共有していると信じるようになります。このアプローチの欠点は、すべての内部トラフィックが、エッジルーターを介して最適ではないパスを介して向けられ、分布した論理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の場合を除き、Subnet Scope Multicastが論理的な隠されたサブネットでは機能しないことです。任意に散在するノードのコレクションへの限られたスコープマルチキャストは技術的な意味がありませんが、トポロジーの隠れと組み合わせて限られたスコープマルチキャストを期待するアプリケーションの展開を避けるために注意する必要があります。
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はインターフェイスごとに複数のアドレスを同時に使用するため、Public Internetへのアクセスが必要なノードにもグローバルな使用アドレスがあるため、ULAとパブリックインターネットの間にIPv6 NATが必要ないように、IPv6はインターフェイスごとに複数のアドレスを単純化します。IPv6を使用する場合、サブネットのサイズが増加するため、より多くのアドレススペースを要求する必要性は、テーブルの断片化も重要な考慮事項であることを認識する割り当てポリシーとともに、はるかに少なくなります。グローバルIPv6割り当てポリシーは地域のインターネットレジストリ（RIRS）を通じて管理されていますが、近い将来[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ユニークなサブネット値があることです（送信）[15]。前述のように、あいまいなアドレス空間の重大な欠点は十分に文書化されており、十分なスペースがあるため、IPv4で必要なますます積極的な保全慣行を継続する必要はありません。IPv6の割り当てポリシーとISPのビジネス慣行は進化し続けますが、RFC 3177の推奨事項は、広大なIPv6アドレス空間の技術的可能性に基づいています。その文書は、NATの背後にある曖昧なスペースのIPv4回避策を採用する必要があるリソース制限がないことを示しています。直接的なコントラストの例として、多くの拡張指向のIPv6展開シナリオは、複数のデバイスがNATを介して希少なグローバルアドレスを共有することを余儀なくされるIPv4シナリオの収縮とは対照的に、デバイスごとに複数の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は、サイトとホストがいくつかの同時CIDRに割り当てられたプレフィックスで実行できるように設計されており、したがっていくつかの同時ISPで。アドレス選択メカニズム[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ネットワークまたはエンドユーザー（エンタープライズなど）ネットワークのいずれかとして、ネットワークのカテゴリが最初に分割されたことを検討することを選択しました。ネットワークの各カテゴリについて、IPv6ローカルネットワーク保護を使用して、アドレス変換の使用と比較して強化されたネットワーク機能を提供する安全で柔軟なインフラストラクチャを実現できます。
o Medium/Large Private Networks (typically >10 connections)
o 中/大規模なプライベートネットワーク（通常、10の接続を> 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アドレスが利用可能になることが期待されています。基本的なIPv6アドレスの範囲は、プライベートネットワークにISP割り当てが十分に大きく（現在 /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.
このタイプのネットワーク上のユーザーのIDをマスクするには、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.
サイトでの永続的なULAアドレスを使用すると、エンタープライズがISPを変更したとしても、変更はサイトを越えて接続したいデバイスのみに影響するという利点を提供します。内部サーバーとサービスは、割り当てられた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（Small Office/Home Office）ネットワークとしても知られているこのカテゴリは、トポロジにルーターがほとんどなく、通常単一のネットワーク出口点を持つネットワークを説明しています。通常、これらのネットワーク：
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つのアドレスのみを与えます）。プライベートネットワーク内のすべてのノードにユニークでグローバルに使用可能なアドレスを提供します。これらの問題のいずれかを修正すると、通常、アドレス管理のための管理オーバーヘッドがユーザーに追加されます。このカテゴリは、RFC 1918に基づいてサービスプロバイダーから曖昧なIPv4アドレスを受信することに限定される場合があります。ISPは通常、より大きなアドレスブロックに添付されたより高い管理コスト、またはより大きなパブリックのために時間の経過とともに静的な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（ポートDemultiplexing NAT）を展開しました。残念ながら、これにより、機器のインターネット機能が主にインターネットデータ（クライアント）の受信機に制限されており、ステートフルのため、機器が世界的なインターネットサーバー（HTTP、FTPなど）になることを非常に困難にします。NAT機器の操作。サーバーへの外部アクセスを有効にするためにNATを管理するのに十分な技術的知識がある場合でも、アドレスごとにプロトコル/ポート番号ごとに1つのサーバーをマッピングできます。その後、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.
両方の代替案について、ISPはRIRに割り当てられたIPv6プレフィックスを要約するための無制限の機能を備えていますが、小規模なプライベートネットワーク管理者は、受信した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プライバシー拡張機能を有効にする必要があります。次に、これにより、単一のアドレスではなく、A /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 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アドレスを介して接続されているユーザーを識別し、単一の機器（PC、PDAなど）を使用します。このユーザーは、RFC 1918に基づくサービスプロバイダーから曖昧なIPv4アドレス（ISPによって頻繁に課される）を取得する場合があります。あいまいなアドレス指定が利用される場合、サービスプロバイダーはグローバルインターネット接続のために割り当てられた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アドレスの無制限の可用性があるという仮定があります。ISPは、RFC 1918アドレスを提供するIPv4の動機であった場合、彼が十分なグローバルアドレスを利用できるため、単一のユーザー接続にプライベートアドレスを割り当てるように動機付けられません。単一のユーザーが自分の身元をマスクしたい場合、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.
o 1つ目は、独自の内部ネットワーク、LANなどについて、中/大規模なプライベートネットワークカテゴリ（上記）に分類されます。
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 2つ目は、バックボーンとアクセススイッチ、およびその他のハードウェアをアドレス指定する操作アドレスドメインです。このアドレスドメインは、エンジニアリング上の理由とバックボーンのセキュリティを管理する際のシンプルさのために、他のアドレスドメインとは別のものです。
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 3番目は、顧客に割り当てる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.
これら3つのドメインでIPv6 LNPが利用される場合、最初のカテゴリでは、セクション5.1で説明されているのと同じソリューションを使用することが可能になります。ISP/キャリアの2番目のドメインはオペレーションネットワークです。この環境は閉鎖環境である傾向があるため、ULASに基づいてコミュニケーションを行うことができます。ただし、この環境では、安定したIPv6プロバイダーに独立したアドレスを使用できます。これにより、ローカルIPv6アドレスプランに関して、しっかりしたスケーラブルな構成が得られます。適切なネットワークエッジフィルターの使用により、閉じた環境への外部アクセスは回避できます。3番目は、ISP/キャリアネットワークが顧客に割り当てるIPv6アドレスです。これらは通常、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）の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でいくつかの最適化作業を行うことができ、モバイルノードがホームエージェントからルートの最適化について通信員に通知しようとしないことを学習し、それによって実際の場所を公開することを定義できます。ファイアウォールの負荷を削減するこの最適化は、ULAが内部で使用されない限り、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.
この複雑な問題は、IPv4に対して完全に解決されたことはありません。これが、NATが部分的なソリューションとして使用されている理由です。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].
セキュリティに関連する可能性のある問題はドキュメント全体で議論されていますが、ここでのアプローチでは、新しいセキュリティの懸念は導入されません。IPV4 NATはセキュリティツールとして広く販売されており、サプライヤーはファイアウォールに住所変換機能を実装していますが、セキュリティに対する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 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.
Christian Huitemaは、最初のラウンドテーブルで文書の範囲と目標について議論するために貢献しましたが、欧州連合IST 6NETプロジェクトは、このメモに記録されている作業の触媒として機能しました。編集上のコメントと貢献は、フレッド・テンプリン、チャオ・ルオ、ペッカ・サヴォラ、ティム・チャウン、ジェロエン・マサール、サルマン・アサドゥラ、パトリック・グロセテテ、フレッド・ベイカー、ジム・バウンド、マーク・スミス、アラン・デュランド、ジョン・スペンス、クリスチャン・フイートマから受け取られました。、エルウィン・デイビス、ダニエル・セニー、ソイニネン・ジョンヌ、カート・エリック・リンドクヴィスト、カレン・ジェニングス、および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.、Moskowitz、R.、Karrenberg、D.、Groot、G。、およびE. Lear、「Private Internetsのアドレス割り当て」、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. Holdrege、「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. Simpson、「IPバージョン6の近隣発見（IPv6）」、RFC 2461、1998年12月。
[4] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[4] Hain、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] Holdrege、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のステートレスアドレスAutoconfigurationのプライバシー拡張」、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] Wasserman、M。、「第3世代パートナーシッププロジェクト（3GPP）規格におけるIPv6の推奨」、RFC 3314、2002年9月。
[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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「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。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、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、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、2003年12月。
[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.、Volpe、V.、Diburro、L。、およびM. Stenberg、「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. Haberman、「IPv6マルチキャストアドレスにRendezvous Point（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.、Kempf、J.、Zill、B。、およびP. Nikander、「Secure Neighbor Discovery（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] Baker、F.、Lear、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。and B. Haberman、「ユニークなローカル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] Fuller、V。およびT. Li、「クラスレス間ドメインルーティング（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.サボラ、「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.、Tompson、M.、Ford、A。、およびS. Venaas、「IPv6ネットワークを変更するときに考えるべきこと」、2006年9月、進行中の作業。
[22] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", Work in Progress, July 2005.
[22] Huston、G。、「レベル3シムを使用したサイトのマルチホミングに関する建築の解説」、2005年7月の作業。
[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] Rosenberg、J。、「Interactive Connectivity Indecivity（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
付録A. ネイティブIPv6とユニバーサルユニークなアドレス指定による追加の利点
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機能を利用する可能性があります。
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.
インターネットの元の設計ポイントの1つは、接続性とは何かでした。IPv4プロトコルの限られたアドレス空間と組み合わせたインターネット接続システムの劇的な成長により、アドレス保存技術が生まれました。NATは、限られたIPv4アドレスプールの需要を減らすためのツールとして導入されましたが、NATテクノロジーの副作用は、任意の接続機能を削除することでした。アドレス保全（したがってNAT）の必要性を削除することにより、IPv6は任意の接続モデルを返し、アプリケーション開発者の制限を削除します。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の現在のエッジファイアウォールソリューションでは、いかなるサービスモデルにも十分ではないため、アプリケーションおよびサービス開発者は、任意の接続性に関係するセキュリティモデルを再考することができます。
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またはStateless Auto Configurationアプローチを使用するように最終システムに指示します。これにより、人間の相互作用を必要とするシステムの数が最小限に抑えられ、サブネット上のすべてのシステム間の一貫性が向上します。この表示を提供するルーターがない場合、ローカルリンクでのみ使用するアドレスは、インターフェイスメディアレイヤーアドレスから導き出されます。
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）を使用する場合、Multicast Rendezvous Point（RP）[14]をIPv6マルチキャストアドレスに直接埋め込むことができます。これは、IPv4アドレスのサイズが限られている場合は不可能です。また、このアプローチはマルチキャストモデルを大幅に簡素化し、理解して展開しやすくなります。
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レベルの識別を排除する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が使用される場合、この衝撃動作は異なります。その後、すべての中間デバイスがソースルートヘッダーを調べなければならなかったためです。
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サービスが必要です。いずれかのプロトコルバージョンでの初期接続の確立にはホームエージェントが必要ですが、IPv6モバイルノードはMIPV6オプションヘッダーを使用してそれらの間のパスを最適化することができ、IPv4モバイルノードはすべてのパケットを三角形にルーティングする必要があります。一般的に、これにより、使用されるネットワークリソースが最小限に抑えられ、通信の品質が最大化されます。
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プライベートアドレス指定の使用により、両方のネットワークがネットワークインフラストラクチャの一部で異なるアドレス範囲を使用していることは保証されていません。アドレス空間でのこの潜在的な重複は、追加のIPv4の変更努力により、つまり、最初のネットワークがサービスを実行している場合（NTP、DNS、DHCP、HTTPなど）、2つ以上のネットワークのマージを劇的に複雑にする可能性があります。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
Gunter Van de Velde Cisco Systems de Kleetlaan 6a Diegem 1831ベルギー
Phone: +32 2704 5473
EMail: gunter@cisco.com
Tony Hain Cisco Systems 500 108th Ave. NE Bellevue, Wa. USA
Tony Hain Cisco Systems 500 108th Ave. Ne Bellevue、WA。アメリカ合衆国
EMail: alh-ietf@tndh.net
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
EMail: rdroms@cisco.com
Brian Carpenter IBM 8 Chemin de Blandonnet 1214 Vernier, CH
ブライアンカーペンターIBM 8 Chemin de Blandonnet 1214 Vernier、Ch
EMail: brc@zurich.ibm.com
Eric Klein Tel Aviv University Tel Aviv, Israel
エリック・クライン・テル・アヴィヴ大学テル・アヴィブ、イスラエル
EMail: ericlklein.ipv6@gmail.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The IETF Trust (2007).
著作権（c）The IETF Trust（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供され、貢献者、彼/彼女が代表する組織（もしあれば）、インターネット協会、IETFトラスト、インターネットエンジニアリングタスクフォースがすべてを否認します。明示的または黙示的な保証。ここでの情報の使用は、特定の目的に対する商品性または適合性の権利または暗黙の保証を侵害しないという保証を含むがこれらに限定されない。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。