RFC4864 日本語訳
4864 Local Network Protection for IPv6. G. Van de Velde, T. Hain, R.Droms, B. Carpenter, E. Klein. May 2007. (Format: TXT=95448 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
Commentsのために作業部会G.バン・デ・ベルデRequestをネットワークでつないでください: 4864年のT.ハインカテゴリ: 情報のR.のIBM E.クラインテルアビブ大学DromsシスコシステムズB.大工2007年5月
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).
IETFが信じる著作権(C)(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.
Network Address Translationへの利益であると知覚された多く(NAT)がありますが、利用可能なアドレス空間の「増幅」である主要便益はIPv6で必要ではありません。 NATの多くの重大な損失に加えて知覚はいます。諸手当はインターネットプロトコルサイトの役に立つかもしれないさまざまな管理やセキュリティー属性のように存在しています。 IPv6はNATを不要にするという意志で設計されました、そして、このドキュメントはIPv6を使用するLocal Network Protection(LNP)がアドレス変換の必要性なしで同じくらいか、より多くの利益をどう提供できるかを示しています。
Van de Velde, et al. Informational [Page 1] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[1ページ]のRFC4864企業内情報通信網保護
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
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 NATの利益とIPv4. . . . . . . 6 2.1の上のその影響であると知覚されます。 インターネットと私設のネットワーク. . . 6 2.2の間の簡単なゲートウェイ。 Statefulによる簡単なセキュリティは実装. . 6 2.3をフィルターにかけます。 ユーザ/アプリケーション追跡. . . . . . . . . . . . . . . . 7 2.4。 .82.5を隠すプライバシーとトポロジー。 私設のネットワーク. . 9 2.6における、アドレシングの独立制御。 グローバルアドレスプール保護. . . . . . . . . . . . . 9 2.7。 マルチホーミングとNAT. . . . . . . . . . . 10 3で番号を付け替えること。 IPv6ツール. . . . . . . . . . . . . . . . 11 3.1の記述。 プライバシーは、(RFC3041)が.113.2であると扱います。 ユニークなローカルのアドレス. . . . . . . . . . . . . . . . . . 12 3.3。 DHCPv6は委譲. . . . . . . . . . . . . . . . . 13 3.4を前に置きます。 追跡不可能なIPv6は.134を扱います。 市場を供給するIPv6技術を使用すると、NAT. . . . . . . . . . . . . . . . . . . . . . . 14 4.1の利益は知覚されました。 インターネットと内部のネットワーク. . . 14 4.2の間の簡単なゲートウェイ。 IPv6と簡単なセキュリティ. . . . . . . . . . . . . . . . . 15 4.3。 ユーザ/アプリケーション追跡. . . . . . . . . . . . . . . . 17 4.4。 IPv6. . . . . . . . . . 17 4.5を使用することで隠れるプライバシーとトポロジー。 私設のネットワーク. . 20 4.6における、アドレシングの独立制御。 グローバルアドレスプール保護. . . . . . . . . . . . . 21 4.7。 マルチホーミングと番号を付け替え. . . . . . . . . . . . . . . 21 5ること。 ケーススタディ. . . . . . . . . . . . . . . . . . . . . . . . . 22 5.1。 中型の、または、大きい私設のネットワーク. . . . . . . . . . . . . . 22 5.2。 小さい私設のネットワーク. . . . . . . . . . . . . . . . . . 24 5.3。 シングルユーザー接続. . . . . . . . . . . . . . . . . . 25 5.4。 ISP/キャリヤー顧客ネットワーク. . . . . . . . . . . . . . 26 6。 IPv6ギャップ分析. . . . . . . . . . . . . . . . . . . . . . 27 6.1。 簡単なセキュリティ. . . . . . . . . . . . . . . . . . . . . 27 6.2。 サブネットトポロジーマスキング. . . . . . . . . . . . . . . . . 28 6.3。 プライバシーの最小量の追随性は.286.4を扱います。 サイトマルチホーミング. . . . . . . . . . . . . . . . . . . . . 28 7。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 29 8。 結論. . . . . . . . . . . . . . . . . . . . . . . . . . 29 9。 承認. . . . . . . . . . . . . . . . . . . . . . . 29 10。 有益な参照. . . . . . . . . . . . . . . . . . . . 30付録A.付加的な利益はネイティブのIPv6と普遍的なユニークなアドレシング. . . . . . . . . . . . . 32A.1がそうします。 普遍的ないずれへのいずれのも接続性. . . . . . . . . . . . 32A.2。 自動構成. . . . . . . . . . . . . . . . . . . . 32A.3。 ネイティブのマルチキャストサービス. . . . . . . . . . . . . . . . 33A.4。 機密保持. . . . . . . . . . . . . . 33A.5を増強しました。 移動性. . . . . . . . . . . . . . . . . . . . . . . . . 34A.6。 ネットワーク. . . . . . . . . . . . . . . . . . . . . 34を合併します。
Van de Velde, et al. Informational [Page 2] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[2ページ]のRFC4864企業内情報通信網保護
1. Introduction
1. 序論
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.
IPv6がNetwork Address Translation(NAT)を必要とするという周期的なクレームがありました、ネットワーク管理者がまた、IPv6を使用するときIPv4を使用して、それらの需要が満たされなければならないとき、さまざまな需要を満たすのにNATを使用するので。 NATへの多くの知覚された利益がありますが、利用可能なアドレス空間の「増幅」である主要便益はIPv6で必要ではありません。 あいまいなアドレス空間とNetwork Address Translation[1][5]によるアプリケーションでの重大な損失と影響がよく記録された[4][6]であるので、追加議論がここにあまりないでしょう。 しかしながら、考えて、確かに広い展開NATで利益であるといくつかを知覚します、それを使用するものの嵩は技術的なトレードオフを評価していませんが。 本当に、しばしばNATデバイスを使用することによって何らかの接続性と安全上の配慮を解決できるだけであると主張されます、アプリケーションについての負の衝撃の少しも言及なしで。 これは接続性を制限する州の機能とアドレス拡張の翻訳機能を区別しないベンダーの最も良い練習用文書とサンプル構成の広範囲の共有で増幅されます。
This document describes the uses of a NAT device in an IPv4 environment that are regularly cited as 'solutions' for perceived problems. It then shows how the goals of the network manager can be met in an IPv6 network without using the header modification feature of NAT. It should be noted that this document is 'informational', as it discusses approaches that will work to accomplish the goals of the network manager. It is specifically not a Best Current Practice (BCP) that is recommending any one approach or a manual on how to configure a network.
このドキュメントはIPv4環境における、'ソリューション'が知覚された問題によって定期的に挙げられるNATデバイスの用途について説明します。次に、それはNATのヘッダー変更機能を使用しないでIPv6ネットワークでどうネットワークマネージャの目標を達成されることができるかを示しています。 このドキュメントが'情報であること'に注意されるべきです、ネットワークマネージャの目標を達成するために働いているアプローチについて議論するとき。 どうネットワークを構成するかのどんなアプローチかマニュアルも推薦するのは、明確にBest Current Practice(BCP)ではありません。
As far as security and privacy are concerned, this document considers how to mitigate a number of threats. Some are obviously external, such as having a hacker or a worm-infected machine outside trying to penetrate and attack the local network. Some are local, such as a disgruntled employee disrupting business operations or the unintentional negligence of a user downloading some malware, which then proceeds to attack from within. Some may be inherent in the device hardware ("embedded"), such as having some firmware in a domestic appliance "call home" to its manufacturer without the user's consent.
セキュリティとプライバシーに関する限り、このドキュメントは多くの脅威を緩和する方法を考えます。 或るものは明らかに外部です、企業内情報通信網を理解して、攻撃しようとする外にハッカーかワームで感染したマシンを持っているのなどように。 或るものは地方です、営業活動を中断する不満を抱いた従業員やあるマルウェアをダウンロードするユーザの意図的でない怠慢などのように。(次に、それは、中から攻撃しかけます)。 或るものはデバイスハードウェアに固有であるかもしれません(「埋め込まれた」)、屋内電気器具の何らかのファームウェアがユーザの同意なしでメーカーに「ホームと呼ぶこと」を持っているのなどように。
Another consideration discussed is the view that NAT can be used to fulfill the goals of a security policy. On the one hand, NAT does satisfy some policy goals, such as topology hiding; at the same time it defeats others, such as the ability to produce an end-to-end audit trail at network level. That said, there are artifacts of NAT devices that do provide some value.
議論した別の考慮は安全保障政策の目標を実現させるのにNATを使用できるという意見です。 一方では、NATはトポロジー隠れることなどのいくつかの方針目標を満たします。 同時に、それはネットワークレベルで終わりから端への監査証跡を生産する能力などの他のものを破ります。 それは言って、何らかの値を提供するNATデバイスの人工物があります。
Van de Velde, et al. Informational [Page 3] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[3ページ]のRFC4864企業内情報通信網保護
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. 流れで終わっているとどんなパケットも受けるのを止める状態の満了は1セットの問題を解決します。
3. The ability for nodes to appear to be attached at the edge of the network solves a set of problems.
3. ノードがネットワークの縁で付けられているように見える能力は1セットの問題を解決します。
4. The ability to have addresses that are not publicly routed solves yet another set (mostly changes where the state is and scale requirements for the first one).
4. 公的に発送されないアドレスを持つ能力はさらにもう1セット(状態がどこにあるか、そして、最初のもののためのスケール要件をほとんど変える)を解決します。
This document describes several techniques that may be combined in an IPv6 deployment to protect the integrity of its network architecture. It will focus on the 'how to accomplish a goal' perspective, leaving most of the 'why that goal is useful' perspective for other documents. These techniques, known collectively as Local Network Protection (LNP), retain the concept of a well-defined boundary between "inside" and "outside" the private network, while allowing firewalling, topology hiding, and privacy. LNP will achieve these security goals without address translation while regaining the ability for arbitrary any-to-any connectivity.
このドキュメントはネットワークアーキテクチャの保全を保護するためにIPv6展開で結合されるかもしれないいくつかのテクニックについて説明します。 それは'どう目標を達成する'見解に焦点を合わせるでしょう、他のドキュメントのために'その目標が役に立つ理由'の大部分を見解に残して。 Local Network Protection(LNP)として一括して知られているこれらのテクニックはfirewalling、トポロジー隠れること、およびプライバシーを許容している間、“inside"と個人的がネットワークでつなぐ「外部」の間で明確な境界の概念を保有します。 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 Local Network Protectionをまとめることができます。 それはものがIPv4とIPv6環境の両方でどう提供されるかに関する十字参照でIPv4+NATの売り出された利益を提示します。
Van de Velde, et al. Informational [Page 4] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[4ページ]のRFC4864企業内情報通信網保護
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 | +------------------+-----------------------+-----------------------+
目標IPv4 IPv6+------------------+-----------------------+-----------------------+ | 簡単なゲートウェイ| DHCP--シングル| DHCP-PD--、任意| | デフォルトルータとして| アドレス上流| 長さの顧客| | そして、プールを扱ってください。| DHCP--制限されます。| 接頭語上流| | マネージャ| 個人の数| RAを通したSLAAC| | | デバイス川下| 川下| | | セクション2.1を見てください。| セクション4.1を見てください。| +------------------|-----------------------|-----------------------+ | 簡単なセキュリティ| フィルタリング側| 明白な文脈| | | 不足による効果| ベースのアクセスコントロール| | | 翻訳状態について| (再帰のACL) | | | セクション2.2を見てください。| セクション4.2を見てください。| +------------------|-----------------------|-----------------------+ | ローカルの用法| NATステートテーブル| アドレスのユニークさ| | 追跡| | | | | セクション2.3を見てください。| セクション4.3を見てください。| +------------------|-----------------------|-----------------------+ | エンドシステム| NATは変形します。| 一時的な使用| | プライバシー| 中のデバイスIDビット| プライバシーアドレス| | | アドレス| | | | セクション2.4を見てください。| セクション4.4を見てください。| +------------------|-----------------------|-----------------------+ | トポロジー隠れること| NATは変形します。| 追跡不可能なアドレス| | | 中のサブネットビット| IGPホストルートを使用します。| | | アドレス| /かMIPv6トンネル| | | セクション2.4を見てください。| セクション4.4を見てください。| +------------------|-----------------------|-----------------------+ | アドレシング| RFC1918| RFC3177と4193| | 自治| セクション2.5を見てください。| セクション4.5を見てください。| +------------------|-----------------------|-----------------------+ | グローバルアドレス| RFC1918| 17 *10^18サブネット| | プール| <<2^48アプリケーション| 3.4 *10^38アドレス| | 保護| エンドポイント| 完全な左舷傾斜/addr| | | 制限されたトポロジー| 無制限なトポロジー| | | セクション2.6を見てください。| セクション4.6を見てください。| +------------------|-----------------------|-----------------------+ | そして番号を付け替える。| アドレス変換| 都合のよい生涯| | マルチホーミング| 境界で| 接頭語と倍数単位で| | | | アドレス| | | | インタフェース| | | セクション2.7を見てください。| セクション4.7を見てください。| +------------------+-----------------------+-----------------------+
Van de Velde, et al. Informational [Page 5] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[5ページ]のRFC4864企業内情報通信網保護
This document first identifies the perceived benefits of NAT in more detail, and then shows how IPv6 LNP can provide each of them. It concludes with an IPv6 LNP case study and a gap analysis of standards work that remains to be done for an optimal LNP solution.
このドキュメントは、最初にさらに詳細にNATの知覚された利益を特定して、次に、IPv6 LNPがどうそれぞれのそれらを提供できるかを示しています。 それは、最適のLNPソリューションのためにするために残っている標準化作業のIPv6 LNPケーススタディとギャップ分析で締めくくります。
2. Perceived Benefits of NAT and Its Impact on IPv4
2. NATの利益とIPv4の上のその影響であると知覚されます。
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.
このセクションはIPv4NATの使用の一般に、知覚された恩恵に関する洞察を提供します。 この記述の目標は知覚のこれらの利益か精度を分析しないことです。(しかし、それらの要件に対処するためのIPv6アプローチの後の記述に展開要件について説明して、文脈を設定するために[4])で議論を詳しく述べました。
2.1. Simple Gateway between Internet and Private Network
2.1. インターネットと私設のネットワークの間の簡単なゲートウェイ
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.
広いスケール展開は、非技術系のエンドユーザにとって、私設のIPv4ネットワークをインターネットに付ける簡単なゲートウェイが簡単であって、実用的であるときに行動するのにNATを使用することでそれを示しました。 頻繁に、簡単なユーザーインタフェースかデフォルト設定さえデバイスとアプリケーションアクセス権の両方を構成するのに十分です。
This simplicity comes at a price, as the resulting topology puts restrictions on applications. The NAT simplicity works well when the applications are limited to a client/server model with the server deployed on the public side of the NAT. For peer-to-peer, multi- party, or servers deployed on the private side of the NAT, helper technologies must also be deployed. These helper technologies are frequently complex to develop and manage, creating a hidden cost to this 'simple gateway'.
結果として起こるトポロジーがアプリケーションのときに制限するようにこの簡単さは犠牲をともないます。 サーバがNAT公共側で配布されている状態でアプリケーションがクライアント/サーバモデルに制限されるとき、NATの簡単さはうまくいきます。 また、ピアツーピア、マルチパーティー、またはNAT個人的側で展開されたサーバにおいて、アシスタント技術を配布しなければなりません。 この'簡単なゲートウェイ'への隠された費用を作成して、これらのアシスタント技術は、開発して、管理するために頻繁に複雑です。
2.2. Simple Security Due to Stateful Filter Implementation
2.2. Statefulフィルター実現による簡単なセキュリティ
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.,
頻繁にセッション指向の操作で、NATが影響の外から私設のネットワークに保護し続けるために付加的なバリアを入れると信じられています。 以来、NATデバイスは個々のセッション、攻撃者、ワームなどのためだけに状態を通常維持します。
Van de Velde, et al. Informational [Page 6] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[6ページ]のRFC4864企業内情報通信網保護
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.
いかなる他のポートの上でも特定のホストを攻撃するのにこの状態を利用できません。 しかしながら、Network Address Port Translation(NAPT)攻撃のポートオーバーロード場合では、すべての動作中のポートが潜在的に広い数のホストに影響を与えるでしょう。 この利益は部分的に本当であるかもしれません。 しかしながら、経験豊富なハッカーは、NATデバイスをよく意識していて、プライベート・アドレススペースに非常に詳しいです、そして、彼らは容易にNAT境界を理解する攻撃(trojan馬などの)のメソッドを工夫しました。 NATによって提供されたstatefulフィルタリングがさまざまな簡単なネットワーク攻撃に対する保護の手段を提供している間、フリーサイズの答えとして提示されますが、それはすべての攻撃から守るというわけではありません。
The act of translating address bits within the header does not provide security in itself. For example, consider a configuration with static NAT and all inbound ports translating to a single machine. In such a scenario, the security risk for that machine is identical to the case with no NAT device in the communication path, as any connection to the public address will be delivered to the mapped target.
ヘッダーの中にアドレスビットを翻訳する行為は本来セキュリティを提供しません。 例えば、静的なNATとすべての本国行きのポートが単一マシンに翻訳されている状態で、構成を考えてください。 そのようなシナリオでは、そのマシンのためのセキュリティリスクは通信路がNATデバイスなしでケースと同じです、場内放送とのどんな接続も写像している目標に提供されるとき。
The perceived security of NAT comes from the lack of pre-established or permanent mapping state. This is often used as a 'better than nothing' level of protection because it doesn't require complex management to filter out unwanted traffic. Dynamically establishing state in response to internal requests reduces the threat of unexpected external connections to internal devices, and this level of protection would also be available from a basic firewall. (A basic firewall, supporting clients accessing public side servers, would improve on that level of protection by avoiding the problem of state persisting as different clients use the same private side address over time.) This role, often marketed as a firewall, is really an arbitrary artifact, while a real firewall often offers explicit and more comprehensive management controls.
NATの知覚されたセキュリティはプレ確立したか永久的なマッピング状態の不足から来ます。 求められていないトラフィックを無視するのが複雑な管理を必要としないので、これは'ないよりまし'のレベルの保護としてしばしば使用されます。 ダイナミックに内部の要求に対応して状態を設置すると、予期していなかった外部の接続の内部のデバイスへの脅威は抑えられます、そして、また、このレベルの保護も基本的なファイアウォールから利用可能でしょう。 (公共のサイドサーバにアクセスするクライアントをサポートして、基本的なファイアウォールは問題を避けることによって、異なったクライアントが時間がたつにつれて同じ個人的なサイドアドレスを使用しながら持続する状態にそのレベルの保護を改良するでしょう。) このファイアウォールとしてしばしば売り出された役割は本当に任意の人工物です、本当のファイアウォールがしばしば明白でより包括的なマネジメント・コントロールを提供しますが。
In some cases, NAT operators (including domestic users) may be obliged to configure quite complex port mapping rules to allow external access to local applications such as a multi-player game or web servers. In this case, the NAT actually adds management complexity compared to the simple router discussed in Section 2.1. In situations where two or more devices need to host the same application or otherwise use the same public port, this complexity shifts from difficult to impossible.
いくつかの場合、NATオペレータ(国内のユーザを含んでいます)がマルチプレーヤーゲームかウェブサーバーなどの局所塗布への外部のアクセスを許すためにかなり複雑なポート配置規則を構成するのが強いられるかもしれません。 この場合、セクション2.1で議論した簡単なルータと比べて、NATは実際に管理の複雑さを加えます。 2台以上のデバイスが同じアプリケーションを主催するか、またはそうでなければ、同じ公共のポートを使用する必要がある状況で、この複雑さは難しいのから不可能になるまで移行します。
2.3. User/Application Tracking
2.3. ユーザ/アプリケーション追跡
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
NATの1つの用法は企業内情報通信網の管理者がユーザとアプリケーショントラフィックを追跡することです。 NATsは活発なセッションのために一時的な状態を創設しますが、一般に、それらは限られた能力を提供します。
Van de Velde, et al. Informational [Page 7] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[7ページ]のRFC4864企業内情報通信網保護
administrator of the NAT to gather information about who in the private network is requesting access to which Internet location. This is done by periodically logging the network address translation details of the private and the public addresses from the NAT device's state database.
だれが私設のネットワークでどのインターネット位置への要求アクセスであるかに関して情報を収集するNATの管理者。 定期的は、NATデバイスの州のデータベースからの個人的なアドレスと公共のアドレスのネットワーク・アドレス翻訳の詳細を登録しながら、これをします。
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.
特にPort Address Translationが使用されているなら、このデータベースのその後の照合はいつも簡単な仕事であるというわけではありません。 また、それには、管理インスタンスが個人的なIPv4-アドレスとネットワーク要素かユーザの間にいつもマッピングを持っているという非論述された仮定があるか、または管理者にアドレス/ポートマッピングの時間で関連しているリストがあります。
2.4. Privacy and Topology Hiding
2.4. プライバシーとトポロジー隠れること
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がaの使用でユーザの大きい共同体へのインターネット・アクセスを提供する能力はアドレス(es)がネットワークの内部のトポロジーを隠すのが簡単であるメカニズムを提供するroutable IPv4をグローバルに選抜します(または、いくつか)。 このシナリオでは、ただ一つ(または、いくつか)の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の後ろで隠すと、外部からファミリーのどのメンバー、インターネットカフェのどの顧客、またはどの会社員が特定のパケットを生成したか、または受けたかを言うのは不可能です。 したがって、NATsはアプリケーションレベルプライバシーを提供するようなことを何もしませんが、彼らは通常、'デバイスプロフィール'として知られているそれらの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).
アプリケーションレベルプロキシに基づくプライバシーがある類似性があります。 例えばウェブをブラウズするのにアプリケーションレベルゲートウェイを使用するとき、オリジナルのウェブユーザーの本当のアイデンティティに外の世界に向かってマスクをかけることによって、ウェブユーザーの'プライバシー'を提供できます(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
いくつかのネットワークマネージャが、攻撃をスキャンしながら、それらの内部のネットワーク形態が緩和する役に立つ注意として部外者からできるだけ隠れるのを好みます。 ほとんど、これは、NATが内部サブネットトポロジーを完全に隠しますが、「トレースルート」などを妨げることによって、達成されます。 サブネットサイズが一度、トポロジーが知られているほど小さいので、スキャンはIPv4ネットワークの特別の関心です、それ
Van de Velde, et al. Informational [Page 8] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[8ページ]のRFC4864企業内情報通信網保護
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.
すべてのホストを見つけるのが簡単であり、被害を受け易いポートに彼らをスキャンするのはその時、始まります。 利用可能なデバイスのリストがいったん写像されると、これらのIPアドレスにおけるポート・スキャンを実行できます。 どのポートを追跡するかによるスキャン作品はファイアウォールかホストから手の届かない誤りを受けません。 開港のリストで、攻撃者は、試みの数を減少させるために知られている脆弱性でそれを関連させることによって、うまくいっている攻撃に必要である時間を最適化できます。 例えば、通常、FTPはポート21で走ります、そして、通常、HTTPはポート80で走ります。 エンドシステムへのアクセスが、他のものに対する攻撃を開始し始めると命令するのにどんな被害を受け易い開港も使用できました。
2.5. Independent Control of Addressing in a Private Network
2.5. 私設のネットワークにおける、アドレシングの独立制御
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ネットワークがそれらの私設のネットワークのために利用可能なアドレシングスペースを拡大して、同時に彼らのグローバルに発送可能なアドレスの必要性を減少させるためにRFC1918で定義されたアドレス空間を利用します。 このタイプのアドレスリソースの現場制御は企業内情報通信網で清潔で階層的なアドレシング構造への十分大きいプールを許容します。
Another benefit is the ability to change providers with minimal operational difficulty due to the usage of independent addresses on a majority of the network infrastructure. Changing the addresses on the public side of the NAT avoids the administrative challenge of changing every device in the network.
別の利益は最小量の操作上の困難に従ってネットワークインフラの大部分に関する独立しているアドレスの用法のためプロバイダーを変える能力です。 NAT公共側でアドレスを変えると、ネットワークにおけるあらゆるデバイスを変える管理挑戦は避けられます。
Section 2.7 describes some disadvantages that appear if independent networks using ambiguous addresses [1] have to be merged.
セクション2.7はあいまいなアドレス[1]を使用する独立しているネットワークが合併されなければならないなら現れるいくつかの損失について説明します。
2.6. Global Address Pool Conservation
2.6. グローバルアドレスプール保護
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アドレスの範囲の進行中の減少は既にはるかに20%未満のunallocated IPv4アドレスの残っているプールがかかりました。 定期的に歴史的な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
増加する管理オーバーヘッドに対応して、多くのインターネットサービスプロバイダ(ISP)が既にそれらが彼らの末端顧客のための接続と同様に提供する様々なサービスのためにNATの後ろでRFC1918で定義されたあいまいなアドレスに訴えました。 私用アドレス空間はサイズが厳密に制限されますが、これは起こります。 いくつかの展開が、そのスペースより既に大きくなって、この習慣ですが、広がり続けるためにNATをどっと落させ始めました。
Van de Velde, et al. Informational [Page 9] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[9ページ]のRFC4864企業内情報通信網保護
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.
結局、中断はルーティングのあいまいさの上にダウンします。 さらに、私たちが習慣の完全な範囲を知るとはありそうもない間(それが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*2^16])より実質的にこのアプローチの限界が何かであること少ないもの、それぞれアドレス可能なデバイスとそれ自身のアプリケーション終点の範囲について異なるとして。 層にすると提唱するNATの人は、頻繁にアプリケーションに関して課されるトポロジー制限があると言及するのを忘れます。 状況を制限しながらこれに強制されて、そのような顧客は、数学的モデルの楽観的な予言にもかかわらず、事実上、IPv4アドレスのグローバルなプールが既に消耗していると正しく主張できます。
2.7. Multihoming and Renumbering with NAT
2.7. マルチホーミングとNATで番号を付け替えること。
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.
企業網には、1つ以上のインターネットサービスプロバイダ(ISP)に関連づけられて、ISPを自由自在に変えることができるように弾性と負荷分散を提供するのは非常に望ましいです。 これは、1つ以上のClassless Inter-ドメインルート設定(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ネットワークが、合併される必要があって、RFC1918アドレスが使用されているなら、アドレスオーバラップの高い確率があります。 たぶん、それらの状況で、NAT箱をそれらの間にインストールすると1か両方に番号を付け替えさせる必要性が避けられるということでしょう。 どんな企業に関してはも、これは、短期的な財政的な節約であることができ、ネットワーク要素に番号を付け替えさせるより多くの時間を許容します。 長期的な解決法はアドレスを重ね合わせる進行中の操作上の複雑さを避けるNATの用法がなければただ一つのネットワークです。
Van de Velde, et al. Informational [Page 10] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[10ページ]のRFC4864企業内情報通信網保護
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の追加はいくつかのネットワークに十分であるかもしれません。 しかしながら、合併しているネットワークが既にアドレス変換を使用していたとき、合併しているネットワークでアドレス空間を重ね合わせるという管理困難のため、それは大した問題を作成するでしょう。
3. Description of the IPv6 Tools
3. IPv6ツールの記述
This section describes several features that can be used as part of the LNP solution to replace the protection features associated with IPv4 NAT.
このセクションは、IPv4NATに関連している保護機能を取り替えるために、使用できるいくつかの特徴を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とそれらを定義するためにまだより多くの仕事を必要としていた潜在的特徴であったそれらの特徴を見分けなければなりません。 後者は後でこのドキュメントの'ギャップAnalysis'セクションでまとめられます。 しかしながら、私たちは本書では既に広くこれを書いている時点で実装されたIPv6とものの完全に定義された特徴を見分けません。
3.1. Privacy Addresses (RFC 3041)
3.1. プライバシーアドレス(RFC3041)
There are situations where it is desirable to prevent device profiling, for example, by web sites that are accessed from the device as it moves around the Internet. IPv6 privacy addresses were defined to provide that capability. IPv6 addresses consist of a routing prefix, a subnet-id (SID) part, and an interface identifier (IID) part. As originally defined, IPv6 stateless address auto- configuration (SLAAC) will typically embed the IEEE Link Identifier of the interface as the IID part, though this practice facilitates tracking and profiling of a device through the consistent IID. RFC 3041 [7] describes an extension to SLAAC to enhance device privacy. Use of the privacy address extension causes nodes to generate global- scope addresses from interface identifiers that change over time, consistent with system administrator policy. Changing the interface identifier (thus the global-scope addresses generated from it) over time makes it more difficult for eavesdroppers and other information collectors to identify when addresses used in different transactions actually correspond to the same node. A relatively short valid lifetime for the privacy address also has the effect of reducing the attack profile of a device, as it is not directly attackable once it stops answering at the temporary use address.
状況がデバイスプロフィールを防ぐのが例えば望ましいところにあります、インターネットの周りで移行するときデバイスからアクセスされるウェブサイトのそばで。 IPv6プライバシーアドレスは、その能力を提供するために定義されました。 IPv6アドレスはルーティング接頭語、サブネットイド(SID)一部、およびインタフェース識別子(IID)部分から成ります。 元々定義されるように、IIDが離れているとき、IPv6の状態がないアドレス自動構成(SLAAC)はインタフェースのIEEE Link Identifierを通常埋め込むでしょう、この習慣が一貫したIIDを通したデバイスの追跡とプロフィールを容易にしますが。 RFC3041[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
ランダマイズされたRFC3041アドレスのプライマリ実装と源が状態がない自動構成を実行しながらエンドシステムからあると予想されますが、何もDynamic Host Configuration Protocol(DHCP)サーバがそれが要求で聞くどんな新しいIEEE識別子のためにも3041年のRFCアルゴリズムを実行するのを防ぐものがありません、そして
Van de Velde, et al. Informational [Page 11] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[11ページ]のRFC4864企業内情報通信網保護
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.
今後の質問のためにそれを覚えています。 これで、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].
事実上、RFC3041で定義されるようにIIDをランダマイズするのは、IPv6アドレスの低級64ビットの跡をつけるのを排除するだけであるまばらな配分のテクニックです。 サブネットIDのマスキングはセクション3.4で以下で議論するように追加アプローチを必要とするでしょう。 [19]で追加問題について議論します。
3.2. Unique Local Addresses
3.2. ユニークなローカルのアドレス
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は複数の接頭語の同時の使用に備えます。 Unique Local Address(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独立者であり、ネットワークのコミュニケーション内部に使用できます。
Van de Velde, et al. Informational [Page 12] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[12ページ]のRFC4864企業内情報通信網保護
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]で定義された方針テーブルは、より高い優先をFC00に与えることによってこの選択に偏ることにおいて一方通行です:、:/7、2001以上:、:/3. 2種類のアドレスを混合するのは不安定性の倍の間「非-提出物」パケットに通じるかもしれませんが、RFC3484の規則が従われているとき、その混合は起こりそうにはありません。
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には、どんな本質的なセキュリティの特性もありません。 それらのルーティング範囲は役に立つ土地ですが、デフォルトで管理境界の中で制限されて、しかしながら、彼らは持っています。 それらの用法は管理便利の問題として数ポイントで本書では示されます。
3.3. DHCPv6 Prefix Delegation
3.3. DHCPv6接頭語委譲
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つは地方の使用が範囲を扱う管理です。 Prefix Delegation(DHCP-PD)オプション[12]は、DHCP[10]を使用することでIPv6接頭語の自動化された委譲にメカニズムを提供します。 このメカニズム(DHCP-PD)は代表として派遣するルータ(ことによると、DHCPv6サーバを取り入れる)から要求ルータまで長い送られた接頭語を代表として派遣するために意図します、ことによると管理境界の向こう側に代表として派遣するルータが接頭語が配属されるネットワークでリンクのトポロジーに関する知識が必要でない。
3.4. Untraceable IPv6 Addresses
3.4. 追跡不可能なIPv6アドレス
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
供給不足のシングル/64の中で同等の、そして、(より短い)の接頭語にはIPv6アドレスがないので、「非-追随性」が必要であるときに、有効に無作為にそれらを生成するのは可能です。 それらはグローバルに、routable IPv6がサイトのものの下で接頭語を扱うということであるだろう、どれがあることができますか?
Van de Velde, et al. Informational [Page 13] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[13ページ]のRFC4864企業内情報通信網保護
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デバイスに割り当てられます。 無作為の課題が企業内情報通信網の構造に関して外の世界をミスリードすることを意図します。 サブネット構造はアドレスで特に、目に見えないかもしれません。 したがって、平坦なルーティングメカニズムがサイトの中で必要でしょう。 ローカルルータは、デバイスの位相的な位置と追跡不可能なIPv6アドレスの間の相関関係を維持する必要があります。 より小さい展開において、ホストルートエントリーをIPv6に生成するか、またはモバイルIPv6ホームのエージェントなどの間接指定デバイスを利用するのによる、より大きいもののためにこの相関関係ができました。 追加詳細がセクション4.7にあります。
4. Using IPv6 Technology to Provide the Market Perceived Benefits of NAT
4. NATの利益であると知覚された市場を供給するIPv6技術を使用します。
The facilities in IPv6 described in Section 3 can be used to provide the protection perceived to be associated with IPv4 NAT. This section gives some examples of how IPv6 can be used securely.
関連していると知覚された保護にIPv4NATを提供するのにセクション3で説明されたIPv6の施設を使用できます。 このセクションはどうしっかりとIPv6を使用できるかに関するいくつかの例を出します。
4.1. Simple Gateway between Internet and Internal Network
4.1. インターネットと内部のネットワークの間の簡単なゲートウェイ
As a simple gateway, the device manages both packet routing and local address management. A basic IPv6 router should have a default configuration to advertise inside the site a locally generated random ULA prefix, independently from the state of any external connectivity. This would allow local nodes in a topology more complex than a single link to communicate amongst themselves independent of the state of a global connection. If the network happened to concatenate with another local network, the randomness in ULA creation is highly unlikely to result in address collisions.
簡単なゲートウェイとして、デバイスはパケットルーティングとローカルアドレス管理の両方を経営しています。 基本的なIPv6ルータには、サイトの中にどんな外部の接続性の状態からも局所的に生成している無作為のULA接頭語の独自に広告を出すデフォルト設定があるべきです。 これはトポロジーにグローバルな接続の状態の如何にかかわらず自分たちの中で伝える単一のリンクより複雑な状態でローカルのノードを許容するでしょう。 ネットワークが起こったなら、別のものと共に企業内情報通信網、ULAの偶発性を連結するように、作成はアドレス衝突を非常にもたらしそうにはありません。
With external connectivity, the simple gateway should use DHCP-PD to acquire a routing prefix from the service provider for use when connecting to the global Internet. End-system connections involving other nodes on the global Internet that follow the policy table in RFC 3484 will always use the global IPv6 addresses derived from this prefix delegation. It should be noted that the address selection policy table should be configured to prefer the ULA prefix range over the DHCP-PD prefix range when the goal is to keep local communications stable during periods of transient external connectivity.
外部の接続性と共に、簡単なゲートウェイは、接続するときの使用のためのサービスプロバイダーから世界的なインターネットまでルーティング接頭語を習得するのにDHCP-PDを使用するはずです。 世界的なインターネットのRFC3484で方針テーブルに続く他のノードにかかわるエンドシステム接続がいつもこの接頭語委譲から得られたグローバルな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
非常に簡単な場合には、どんな明白なルーティング・プロトコルもゲートウェイのどちらの側面にもありません、そして、ただ一つのデフォルトルートは内部的に世界的なインターネットへの外に指すのにおいて使用されています。 わずかに複雑なケースはローカルの内部のルーティング・プロトコルにかかわるかもしれませんが、全体の企業内情報通信網が共有されている状態で、一般的なグローバルな接頭語はそこでかかわるでしょう。
Van de Velde, et al. Informational [Page 14] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[14ページ]のRFC4864企業内情報通信網保護
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を通して代表として派遣された接頭語のためにルートをインストールできたので、まだそうしていないのは、外部のルーティング・プロトコルの必要性です。
4.2. IPv6 and Simple Security
4.2. IPv6と簡単なセキュリティ
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ホストのものと同様です。 ファイアウォールとIntrusion Detection Systems(IDSs)の使用はホストディフェンスに加えた境界保護を必要とするもののために推薦されます。 プロキシは、あるアプリケーションに使用されますが、終わりから終わりへの透明がある警告で調教されるかもしれません。 しかしながら、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サポートは、制限を持っていて、すべての状況で働いていません。 NATsとのIPsecの使用は追加UDPカプセル化とkeepaliveオーバーヘッド[13]を必要とします。 IPv4/NAT環境で、IPsecの使用法は縁から縁へのVirtual兵士のNetwork(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
3. 典型的なサブネット(IIDの64ビット)のアドレス空間のサイズで、完全なサブネットピングはIPv4より通常かなり困難で高価な[20]を掃くでしょう。 特定されたノードにおけるポート・スキャンの軍事的脅威を抑えるのは、サブネットの中のまばらな分配がスキャンが隣接しているノードに当たるという確率を最小にするのを必要とします。 IIDsがIIDスペースの中のどんな構造化された組分けでも構成されると、このスキャン保護は無効にされるでしょう。 IIDsが利用可能なスペース、アドレスの向こう側に本質的には手当たりしだいに分配されれば
Van de Velde, et al. Informational [Page 15] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[15ページ]のRFC4864企業内情報通信網保護
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).
事実上、スキャンベースの攻撃は失敗するでしょう。 攻撃者が特定のサブネットに直接アクセスを全く持たないで、したがって、それを離れてスキャンしようとしているなら、この保護は存在しています。 攻撃者に地方のアクセスがあるなら、彼はNeighborディスカバリー(ノースダコタ)の[3]とping6をリンク範囲マルチキャストff02に使用するかもしれません:、:地元の隣人のIEEEベースのアドレスを検出して、次に検索を簡素化するためにグローバルな接頭語をそれらに適用する(もちろん、局所的に接続された攻撃者には、また、IPv4との多くのスキャンオプションがあります)1。
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デバイスにほとんど不可能になるでしょう。 トポロジーが調べられるという意志は企業の中で手があいているホストの品揃えを特定することです。 これはピング一掃からほとんど始まります。 IPv6サブネットがアドレス空間、攻撃者が単に非現実的な数のネットワークを写像するピング、およびウイルス/ワーム伝播を出すために持っているこの手段の価値がそうする64ビットであるので、プロセスで邪魔されてください。 全額料金全二重40Gbps(典型的な100Mbpsの典型的なDSL/ケーブルアクセスリンクのLAN、および1万3000倍の400倍)では、ただ一つの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.
IPv4NATはセキュリティー対策として開発されませんでした。 それと反対なマーケティングメッセージにもかかわらず、それはセキュリティー対策ではありません、そして、したがって、多くの人々が、彼らのネットワークがNATの用法のために安全であると仮定している間、いくつかのセキュリティーホールを提供するでしょう。 IPv6のセキュリティの最も良い習慣は、この種類の非現実的なセキュリティを避けますが、正しく構成されたファイアウォールとIDSsが周辺で使用される場合にだけ、同じ脅威を扱うことができます。
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.
IPv6のために例えば、DSLかケーブルモデムコネクテッドホームネットワークで簡単なセキュリティを実装するために、広帯域のゲートウェイ/ルータはstatefulファイアウォール能力を備えるべきです。 これらは入って来るトラフィックが出発しているパケット(反射的なセッション状態として時々知られている)から生じるトラフィックを返すために制限されるところにデフォルト設定を提供するべきです。 また、ユーザが特定の目的でオンラインゲームなどの本国行きの'ピンホール'を作成できる簡単なインタフェースがあるべきです。
Van de Velde, et al. Informational [Page 16] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[16ページ]のRFC4864企業内情報通信網保護
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インターネットを利用することでしょう。
4.3. User/Application Tracking
4.3. ユーザ/アプリケーション追跡
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]が使用中でない場合、これはデータフローがセキュリティ監査のためにIPv4NATと比べて追跡される能力を高めます、送付者と受信機の間の流れがユニークな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つのメディアが扱う層などの、より安定した情報に基づく必要があるでしょう。
4.4. Privacy and Topology Hiding Using IPv6
4.4. IPv6を使用することで隠れるプライバシーとトポロジー
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で必要に応じて作られるRFC3041擬似ランダムプライバシーアドレス[7]を使用することで達成されます、セッションが限られた時間だけ有効なアドレスを使用できるように。 これは、そのようなセッションがそれを溯源するサブネットにたどって戻されるのを許容しますが、すぐ実際のホストに許容するだけであるというわけではありません、IPv4NATが単に最も公共のNATインタフェースに起因しているところで。
Due to the large IPv6 address space available, there is plenty of freedom to randomize subnet allocations. By doing this, it is possible to reduce the correlation between a subnet and its location. When doing both subnet and IID randomization, a casual snooper won't be able to deduce much about the network's topology. The obtaining of a single address will tell the snooper very little about other addresses. This is different from IPv4 where address space limitations cause this not to be true. In most usage cases, this concept should be sufficient for address privacy and topology hiding, with the cost being a more complex internal routing configuration.
利用可能な大きいIPv6アドレス空間のために、サブネット配分をランダマイズする多くの自由があります。 そうすれば、サブネットとその位置の間の相関関係を減少させるのは可能です。 サブネットとIID無作為化の両方をするとき、カジュアルな詮索好きはネットワークのトポロジーに関して多くを推論できないでしょう。 ただ一つのアドレスの入手は他のアドレスに関して非常に少ししか詮索好きについて話さないでしょう。 これはアドレス空間制限がこれが本当でないことを引き起こすIPv4と異なっています。 ほとんどの用法場合では、この概念は、より複雑な内部のルーティング設定である費用で隠れるアドレスプライバシーとトポロジーに十分であるべきです。
Van de Velde, et al. Informational [Page 17] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[17ページ]のRFC4864企業内情報通信網保護
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トポロジー、および大部分を完全に隔離したがっている内部の使用が扱う場合では、1つのオプションはUnique Local Addresses(ULAs)を使用することですべての国内取引を実行することです。 定義上、この接頭語ブロックが公共のルーティングシステムに広告を出さないことであるので、ルーティング経路がなければ、域外交通はサイトに決して達しないでしょう。 外部の接続性を必要としない内部のノードのすべて、および内部的に使用されたそうするそれらのアドレスは外部から事実上、複数のIPv6接頭語(ULAsと1つ以上のグローバルなアドレス)を使用することによって外部的に相互作用する必要があるホストのセットにおいて、仮面になるでしょう。 [11]で定義された方針テーブルは、複数の接頭語がまた、通信員も地元であるときに、ULAが好まれるくらい使用中であるときに、選択プロセスに偏るためにメカニズムを提供します。
There are other scenarios for the extreme situation when a network manager also wishes to fully conceal the internal IPv6 topology. In these cases, the goal in replacing the IPv4 NAT approach is to make all of the topology hidden nodes appear from the outside to logically exist at the edge of the network, just as they would when behind a NAT. This figure shows the relationship between the logical subnets and the topology masking router discussed in the bullet points that follow.
また、ネットワークマネージャが内部のIPv6トポロジーを完全に隠したがっているとき、極端な状況のための他のシナリオがあります。 これらの場合では、IPv4NATアプローチを取り替えることにおける目標はトポロジーの隠されたノードのすべてをネットワークの縁に論理的に存在するように外部から現れさせることです、NATの後ろにあるとき、ちょうどそうするように。 この図は従う弾丸ポイントで議論した論理的なサブネットとトポロジーマスキングルータとの関係を示しています。
Internet | \ | +------------------+ | topology |-+-+-+-+-+-+-+-+-- | masking | Logical subnets | router |-+-+-+-+-+-+-+-+-- +------------------+ for topology | hidden nodes | Real internal -------------+- topology | | | -+---------- -----------+--------+ | | |
Internet | \ | +------------------+ | topology |-+-+-+-+-+-+-+-+-- | masking | Logical subnets | router |-+-+-+-+-+-+-+-+-- +------------------+ for topology | hidden nodes | Real internal -------------+- topology | | | -+---------- -----------+--------+ | | |
Van de Velde, et al. Informational [Page 18] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 18] RFC 4864 Local Network Protection for IPv6 May 2007
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 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 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 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.
Van de Velde, et al. Informational [Page 19] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 19] RFC 4864 Local Network Protection for IPv6 May 2007
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 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.
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.
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.
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.
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.
4.5. Independent Control of Addressing in a Private Network
4.5. Independent Control of Addressing in a Private Network
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 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.
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.
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.
Van de Velde, et al. Informational [Page 20] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 20] RFC 4864 Local Network Protection for IPv6 May 2007
4.6. Global Address Pool Conservation
4.6. Global Address Pool Conservation
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 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.
4.7. Multihoming and Renumbering
4.7. Multihoming and Renumbering
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 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).
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.
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.
Van de Velde, et al. Informational [Page 21] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 21] RFC 4864 Local Network Protection for IPv6 May 2007
5. Case Studies
5. Case Studies
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.
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.
o Medium/Large Private Networks (typically >10 connections)
o Medium/Large Private Networks (typically >10 connections)
o Small Private Networks (typically 1 to 10 connections)
o Small Private Networks (typically 1 to 10 connections)
o Single User Connection (typically 1 connection)
o Single User Connection (typically 1 connection)
o ISP/Carrier Customer Networks
o ISP/Carrier Customer Networks
5.1. Medium/Large Private Networks
5.1. Medium/Large Private Networks
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.
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.
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.
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.
Van de Velde, et al. Informational [Page 22] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 22] RFC 4864 Local Network Protection for IPv6 May 2007
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.
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.
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.
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.
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.
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.
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.
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.
Van de Velde, et al. Informational [Page 23] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 23] RFC 4864 Local Network Protection for IPv6 May 2007
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.
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.
5.2. Small Private Networks
5.2. Small Private Networks
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:
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:
o are connected via either a dial-up connection or broadband access,
o are connected via either a dial-up connection or broadband access,
o don't have dedicated Network Operation Center (NOC), and
o don't have dedicated Network Operation Center (NOC), and
o today, typically use NAT as the cheapest available solution for connectivity and address management
o today, typically use NAT as the cheapest available solution for connectivity and address management
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.
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.
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.
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.
Van de Velde, et al. Informational [Page 24] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 24] RFC 4864 Local Network Protection for IPv6 May 2007
When deploying IPv6 LNP in this environment, there are two approaches possible with respect to IPv6 addressing.
When deploying IPv6 LNP in this environment, there are two approaches possible with respect to IPv6 addressing.
o DHCPv6 Prefix-Delegation (PD)
o DHCPv6 Prefix-Delegation (PD)
o ISP provides a static IPv6 address range
o ISP provides a static IPv6 address range
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.
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.
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.
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.
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.
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.
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.
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.
5.3. Single User Connection
5.3. Single User Connection
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
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
Van de Velde, et al. Informational [Page 25] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 25] RFC 4864 Local Network Protection for IPv6 May 2007
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.
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.
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.).
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.).
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.
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.
5.4. ISP/Carrier Customer Networks
5.4. ISP/Carrier Customer Networks
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:
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:
o For the first, they fall into the medium/large private networks category (above) for their own internal networks, LANs, etc.
o For the first, they fall into the medium/large private networks category (above) for their own internal networks, LANs, etc.
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 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 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 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).
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
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
Van de Velde, et al. Informational [Page 26] RFC 4864 Local Network Protection for IPv6 May 2007
Van de Velde, et al. Informational [Page 26] RFC 4864 Local Network Protection for IPv6 May 2007
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.
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.
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はThird Generation Partnership Project(3GPP)の付属デバイスのためにIPv4+NATの組み合わせとの比較で奨励されます。 RFC3314のセクション2.3、'3GPP StandardsのIPv6のための推薦'[9]では、IPv6 WGが、1以上/64の接頭語がそれぞれのプライマリプロトコルData Packet(PDP)文脈に割り当てられるべきであることを勧めるのが見つけられます。 これは3GPPが添付のノードがプライバシーアドレスを割り当てることができるくらいのアドレス空間、そして/または、ルートをマルチリンクサブネットに許容するでしょう、そして、それは3GPPが付属しているデバイスの中にNATの使用に水をさしているでしょう。
6. IPv6 Gap Analysis
6. IPv6ギャップ分析
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アプローチの即座の展開への障害が全くありません、製品実装は標準化取り組みに後れを取るかもしれませんが。 それが言われていて、以下のリストはなくなったシナリオをカバーするために引き受けられるべきである追加仕事を特定します。
6.1. Simple Security
6.1. 簡単なセキュリティ
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
ダイナミックなピンホール管理によるファイアウォール縦断はさらなる研究を必要とします。 Interactive Connectivity特権階級(ICE)[23]、およびUniversal Plug and Play(UPNP)[24]を含んでいて、いくつかの部分的解決が存在しています。 代替的アプローチは、サービスプロバイダーの調停されたピンホール管理を定義するために見ています。(そこでは、音声通話シグナリングのようなものがダイナミックに事前に定義された認証規則に基づくピンホールを確立できました)。 statefulファイアウォールによって提供された基本的なセキュリティは、単に働くアプリケーションがある安全な環境が欲しい消費者から技術的な複雑さにマスクをかけるためにいくらかのデフォルト設定とオートメーションを必要とするでしょう。 stateful IPv6ファイアウォール製品を出荷できない理由が全くありません。
Van de Velde, et al. Informational [Page 27] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[27ページ]のRFC4864企業内情報通信網保護
default protection that is equal to or better than that offered by today's IPv4/NAT products.
今日のIPv4/NAT製品によって提供されたそれより等しいか、または良いデフォルト保護。
6.2. Subnet Topology Masking
6.2. サブネットトポロジーマスキング
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のアドレスの中心に割り当てられたプールが、より小さい展開のためにトポロジーにマスクをかける効果的な方法であるので、本当にここにありません。 必要なら、事実上、Untraceable Addressesを定義するDHCPと様々なIGPsとの相互作用について説明しながら、最も良い練習用文書を開発できました。
As an alternative for larger deployments, there is no gap in the HA tunneling approach when firewalls are configured to block outbound binding update messages. A border Home Agent using internal tunneling to the logical mobile (potentially rack mounted) node can completely mask all internal topology, while avoiding the strain from a large number of host routes in the IGP. Some optimization work could be done in Mobile IP to define a policy message where a mobile node would learn from the Home Agent that it should not try to inform its correspondent about route optimization and thereby expose its real location. This optimization, which reduces the load on the firewall, would result in less optimal internal traffic routing as that would also transit the HA unless ULAs were used internally. Trade-offs for this optimization work should be investigated in the IETF.
ファイアウォールが外国行きの拘束力があるアップデートメッセージを妨げるために構成されるとき、より大きい展開のための代替手段として、HAトンネリングアプローチにはギャップが全くありません。 (潜在的に、ラックは上がりました)論理的なモバイルノードに内部のトンネリングを使用している境界ホームのエージェントはIGPの多くのホストルートからの緊張を避けている間、すべての内部のトポロジーに完全にマスクをかけることができます。 モバイルノードがホームのエージェントから経路最適化に関して通信員に知らせて、その結果、本当の位置を暴露しようとするべきでないことを学ぶ方針メッセージを定義するためにモバイルIPでいくらかの最適化仕事ができました。 また、ULAsが内部的に使用されない場合それがHAを通過するのに従って、この最適化(ファイアウォールで負荷を減少させる)はそれほど最適でない国内取引ルーティングをもたらすでしょう。 この最適化仕事のためのトレードオフはIETFで調査されるべきです。
6.3. Minimal Traceability of Privacy Addresses
6.3. プライバシーアドレスの最小量の追随性
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によって追求されるはずです。
6.4. Site Multihoming
6.4. サイトマルチホーミング
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
この複雑な問題はIPv4のために完全に一度も解決されたことがありません(ちょうどNATが部分的解決として使用された理由です)。 IPv6に関しては、数年の仕事の後に、IETFは初期目標[22]としてサービス復旧で意図する建築アプローチに集まりました。 このドキュメントが作成されたとき、IETFは活発にマルチホーミング問題へのこのアプローチの詳細を定義していました。 アプローチは小さくて中型のサイトに最も適しているように見えます、既存のファイアウォール州の手順と衝突するでしょうが。 また、このとき、アドレスには活発な議論があります。
Van de Velde, et al. Informational [Page 28] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[28ページ]のRFC4864企業内情報通信網保護
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.
プロバイダーの独立しているアドレス空間を割り当てる可能性を調査する登録。 彼らの挑戦によって、グローバルなルーティングエントリーへの資格を得る組織の数を制限するのにおいて、妥当なaがメートル法であることがわかっています。 追加仕事は全体の範囲の要件を満たすのに必要であるように見えます。
7. Security Considerations
7. セキュリティ問題
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].
ドキュメント中で潜在的に関係づけられたセキュリティである問題について議論している間、アプローチはここにどんな新しい安全上の配慮も導入しません。 セキュリティツールとして広くIPv4NATを販売しました、そして、供給者は彼らのファイアウォールでアドレス変換が機能性であると実装しています、セキュリティのNATsの本当の影響が以前に、[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.
このドキュメントはアプリケーションへの負の衝撃なしでネットワークマネージャの目標をまとめて実現するIPv6アプローチかNATアプローチに固有のセキュリティを定義します。 セクション6が追加最適化仕事を特定して、明らかに監査するネットワークマネージャの性能かコントロールがこれらのテクニックが改良する度合いにローカル資源の総合的な攻撃暴露にアクセスして、その結果、管理している間、それらは、企業内情報通信網セキュリティを向上させるために行動します。
8. Conclusion
8. 結論
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サイトで結合されるかもしれない多くのテクニックについて説明しました。 Local Network Protectionとして一括して知られているこれらのテクニックは“inside"と個人的がfirewalling、トポロジー隠れること、およびプライバシーをネットワークでつないで、許容する「外部」の間で明確な境界の概念を保有します。 しかしながら、それが必要であるところにアドレス透明を保存するので、彼らはアドレス変換の不都合なしでこれらの目標を達成します。 したがって、IPv6のLocal Network Protectionは対応する損失なしでIPv4 Network Address Translationの利益を提供できます。
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仕事の品目を特定しました。
9. Acknowledgements
9. 承認
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
クリスチャンのHuitemaはドキュメントの範囲と目標について議論するために初期の円卓の間、貢献しています、ヨーロッパ連合IST 6NETプロジェクトはこの注意に記録された仕事のために触媒として働きましたが。 以下から編集のコメントと貢献を受けました。 フレッド・テンプリン、チャオ・羅、ペッカSavola、ティムChown、ジョロエンMassar、サルマンAsadullah、パトリックGrossetete、フレッド・ベイカー、ジムBound、マーク
Van de Velde, et al. Informational [Page 29] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[29ページ]のRFC4864企業内情報通信網保護
Smith, Alain Durand, John Spence, Christian Huitema, Mark Smith, Elwyn Davies, Daniel Senie, Soininen Jonne, Kurt Erik Lindqvist, Cullen Jennings, and other members of the v6ops WG and IESG.
スミス、アラン・ジュランド、ジョン・スペンス、クリスチャンのHuitema、マーク・スミス、Elwynデイヴィース、ダニエルSenie、Soininen Jonne、カート・エリック・リンクヴィスト、v6ops WGとIESGのCullenジョニングスの、そして、他のメンバー。
10. Informative References
10. 有益な参照
[1] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996.
[1]RekhterとY.とマスコウィッツとR.とKarrenbergとD.とグルート、G.とE.リア、「個人的なインターネットのためのアドレス配分」BCP5、RFC1918(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)用語と問題をネットワークでつなぐ」RFC2663、1999年8月。
[3] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[3]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[4] Hain, T., "Architectural Implications of NAT", RFC 2993, November 2000.
[4] ハイン、T.、「NATの建築含意」、RFC2993、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)」、RFC3022、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ネットワークアドレス変換機構とのプロトコル複雑さ」、RFC3027、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"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、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推薦」、RFC3177、2001年9月。
[9] Wasserman, M., "Recommendations for IPv6 in Third Generation Partnership Project (3GPP) Standards", RFC 3314, September 2002.
[9] ワッサーマン、M.、「第三世代パートナーシッププロジェクト(3GPP)規格におけるIPv6のための推薦」、RFC3314、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.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[11] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[11]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、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、「Dynamic Host Configuration Protocol(DHCP)バージョン6インチIPv6 Prefix Options、RFC3633、2003年12月。」
Van de Velde, et al. Informational [Page 30] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[30ページ]のRFC4864企業内情報通信網保護
[13] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 3948, January 2005.
[13]HuttunenとA.とSwanderとB.とボルペとV.とDiBurro、L.とM.Stenberg、「IPsec超能力パケットのUDPカプセル化」RFC3948(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.ハーバーマン、「ランデブーポイント(RP)を埋め込んで、IPv6でマルチキャストアドレスを扱ってください」、RFC3956、2004年11月。
[15] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
[15]ArkkoとJ.とケンフとJ.とZill、B.とP.Nikander、「安全な隣人発見(発信する)」、RFC3971、2005年3月。
[16] Baker, F., Lear, E., and R. Droms, "Procedures for Renumbering an IPv6 Network without a Flag Day", RFC 4192, September 2005.
[16] ベイカー、F.、リア、E.、およびR.Droms、「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
[17] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005.
[17]HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[18] Fuller, V. and T. Li, "Classless Inter-domain Routing (CIDR): The Internet Address Assignment and Aggregation Plan", BCP 122, RFC 4632, August 2006.
[18] フラーとV.とT.李、「以下を掘る(CIDR)階級のない相互ドメイン」 「インターネットアドレス課題と集合は計画している」BCP122、RFC4632、2006年8月。
[19] Dupont, F. and P. Savola, "RFC 3041 Considered Harmful", Work in Progress, June 2004.
[19] 「有害であると考えられたRFC3041」というデュポン、F.、およびP.Savolaは進歩、2004年6月に働いています。
[20] Chown, T., "IPv6 Implications for TCP/UDP Port Scanning", Work in Progress, October 2005.
[20] T.、「TCP/UDPポートスキャンのためのIPv6含意」というChownは進歩、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.とフォード、A.とS.Venaas、「いつ頃にRenumberingがIPv6ネットワークであると考えるかもの」Work、Progress(2006年9月)
[22] Huston, G., "Architectural Commentary on Site Multi-homing using a Level 3 Shim", Work in Progress, July 2005.
[22] ヒューストン、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] ローゼンバーグ、J.、「対話的な接続性設立(氷):」 「申し出/答えプロトコルのためのネットワークアドレス変換機構(NAT)縦断のための方法論」、処理中の作業、2006年10月。
[24] "Universal Plug and Play Web Site", July 2005, <http://www.upnp.org/>.
[24] 「普遍的なPlug and Playウェブサイト」、2005年7月、<http://www.upnp.org/>。
Van de Velde, et al. Informational [Page 31] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[31ページ]のRFC4864企業内情報通信網保護
Appendix A. Additional Benefits Due to Native IPv6 and Universal Unique Addressing
ネイティブのIPv6と普遍的なユニークなアドレシングによる付録A.付加的な利益
The users of native IPv6 technology and globally unique IPv6 addresses have the potential to make use of the enhanced IPv6 capabilities, in addition to the benefits offered by the IPv4 technology.
固有のIPv6技術とグローバルにユニークなIPv6アドレスのユーザには、高められたIPv6能力を利用する可能性があります、IPv4技術で提供された利益に加えて。
A.1. Universal Any-to-Any Connectivity
A.1。 普遍的ないずれへのいずれのも接続性
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プロトコルの限られたアドレス空間に結びつけられたインターネットで接続されたシステムの劇的な成長はアドレス保護のテクニックを生じさせました。 限られたIPv4アドレスプールで需要を抑えるためにツールとしてNATを導入しましたが、NAT技術の副作用は接続性のいずれへのいずれも能力を取り除くことになっていました。 アドレス保護(そして、したがって、NAT)の必要性を取り除くことによって、IPv6は接続性のいずれへのいずれもモデルを返して、アプリケーション開発者の上で制限を取り除きます。 NAT縦断取り組みで自由な状態で革新する自由で、ますます複雑なNAT環境を発見して、横断するのは焦点を合わせるより開発者がむしろ新しい高度なネットワーク・サービス(すなわち、ピアツーピアアプリケーション、2台の交信デバイスのIPv6によって埋め込まれたIPsecコミュニケーション、インスタントメッセージング、インターネット電話など)に焦点を合わせることができるでしょう。
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の現在の縁のファイアウォールソリューションがサービスのいずれへのいずれもモデルに十分でないときに。
A.2. Auto-Configuration
A.2。 自動構成
IPv6 offers a scalable approach to minimizing human interaction and device configuration. IPv4 implementations require touching each end system to indicate the use of DHCP vs. a static address and management of a server with the pool size large enough for the potential number of connected devices. Alternatively, IPv6 uses an indication from the router to instruct the end systems to use DHCP or the stateless auto-configuration approach supporting a virtually limitless number of devices on the subnet. This minimizes the number of systems that require human interaction as well as improves consistency between all the systems on a subnet. In the case that there is no router to provide this indication, an address for use only on the local link will be derived from the interface media layer address.
IPv6は人間の交流とデバイス構成を最小にすることへのスケーラブルなアプローチを提供します。 IPv4実装は、接続デバイスの潜在的数には、十分大きいプール・サイズでDHCP対静的なアドレスの使用とサーバの管理を示すためにそれぞれのエンドシステムに触れるのを必要とします。 あるいはまた、IPv6は、DHCPかサブネットで実際には限のない数のデバイスを支える状態がない自動構成アプローチを使用するようエンドシステムに命令するのにルータから指示を使用します。 これは、人間の交流を必要とするシステムの数を最小にして、サブネットのすべてのシステムの間の一貫性を改良します。 この指示を提供するためにルータが全くなくて、メディア層が扱うインタフェースから地方のリンクだけにおける使用のためのアドレスを得るでしょう。
Van de Velde, et al. Informational [Page 32] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[32ページ]のRFC4864企業内情報通信網保護
A.3. Native Multicast Services
A.3。 ネイティブのマルチキャストサービス
Multicast services in IPv4 were severely restricted by the limited address space available to use for group assignments and an implicit locally defined range for group membership. IPv6 multicast corrects this situation by embedding explicit scope indications as well as expanding to 4 billion groups per scope. In the source-specific multicast case, this is further expanded to 4 billion groups per scope per subnet by embedding the 64 bits of subnet identifier into the multicast address.
IPv4でのマルチキャストサービスはグループ会員資格のためにグループ課題に使用するために利用可能な限られたアドレス空間と暗黙の局所的に定義された範囲によって厳しく制限されました。 IPv6マルチキャストは、明白な範囲指摘を埋め込んで、1範囲あたり40億のグループに広がることによって、この状況を修正します。 ソース特有のマルチキャスト場合では、これは、さらに1範囲あたり40億のグループにサブネット単位で広げられます64ビットのサブネット識別子をマルチキャストアドレスに埋め込むことによって。
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はAny-ソースMulticast(ASM)を使用するときまた、IPv6アドレスの長さの革新的な用法を考慮して、マルチキャストRendezvous Point(RP)[14]を直接IPv6マルチキャストアドレスに埋め込むのを可能にします。 これはIPv4アドレスの限られたサイズで可能ではありません。 また、分かって、展開するのをより簡単にして、このアプローチはマルチキャストモデルをかなり簡素化します。
A.4. Increased Security Protection
A.4。 増強された機密保持
The security protection offered by native IPv6 technology is more advanced than IPv4 technology. There are various transport mechanisms enhanced to allow a network to operate more securely with less performance impact:
固有のIPv6技術で提供された機密保持はIPv4技術より高度です。 ネットワークが、より少ない性能影響で、よりしっかりと作動するのを許容するために高められた様々な移送機構があります:
o IPv6 has the IPsec technology directly embedded into the IPv6 protocol. This allows for simpler peer-to-peer authentication and encryption, once a simple key/trust management model is developed, while the usage of some other less secure mechanisms is avoided (e.g., MD5 password hash for neighbor authentication).
o IPv6はIPsec技術をIPv6プロトコルに直接埋め込ませます。 これは、より簡単なピアツーピア認証と暗号化を考慮します、簡単なキー/信頼マネジメント・モデルがいったん開発されていると、ある他のそれほど安全でないメカニズムの使用法は避けられますが(例えば、隣人認証のための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 ファイアウォールがローカルの方針に基づくアプリケーションを禁じるように明確に設計されている間、それは許容されているものを妨げません。 これはNATの上のセキュリティ改良です、パケット、どれが終わりから終わりへの監査を排除するか、そして、またはIPの平らな識別のときにローカルの方針で許容されたアプリケーションを可能にする仕事aroundsが事実上、architectedされた介入者攻撃であるところで。
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)攻撃をバックトレースするために、より簡単な方法論を容易にして、より簡単なトラフィックフィルタリングでネットワーク資源への不法なアクセスを避けるかもしれません。
Van de Velde, et al. Informational [Page 33] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[33ページ]のRFC4864企業内情報通信網保護
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のプライベート・アドレススペースの用法は現在、Unique Local Addressesによって提供されます。(より簡単なトラフィックのため方針をフィルターにかけながら企業内情報通信網インフラストラクチャでネットワークを合併して、内部のコミュニケーションを保証するとき、Unique Local Addressesは闘争状況を避けるでしょう)。
o The technology to enable source-routing on a network infrastructure has been enhanced to allow this feature to function, without impacting the processing power of intermediate network devices. The only devices impacted with the source- routing will be the source and destination node and the intermediate source-routed nodes. This impact behavior is different if IPv4 is used, because then all intermediate devices would have had to look into the source route header.
o ネットワークインフラでソースルーティングを可能にする技術は機能するこの特徴を許容するために高められました、中間ネットワークデバイスの処理能力に影響を与えないで。 ソースルーティングで影響を与えられた唯一のデバイスが、ソースと目的地ノードになるでしょう、そして、中間介在物はノードをソースで発送しました。 IPv4が使用されているなら、この影響の振舞いは異なっています、次に、すべての中間的デバイスが送信元経路ヘッダーを調べなければならなかったでしょう、したがって。
A.5. Mobility
A.5。 移動性
Anytime, anywhere, universal access requires MIPv6 services in support of mobile nodes. While a Home Agent is required for initial connection establishment in either protocol version, IPv6 mobile nodes are able to optimize the path between them using the MIPv6 option header, while IPv4 mobile nodes are required to triangle route all packets. In general terms, this will minimize the network resources used and maximize the quality of the communication.
いつでも、どこでも、普遍的なアクセスはモバイルノードを支持してMIPv6サービスを必要とします。 ホームのエージェントがどちらかのプロトコルバージョンへの初期のコネクション確立に必要ですが、IPv6のモバイルノードはMIPv6オプションヘッダーを使用することでそれらの間の経路を最適化できて、IPv4のモバイルノードが三角形に必要である間、すべてのパケットを発送してください。 あいまいな言葉で、これは、使用されるネットワーク資源を最小にして、コミュニケーションの品質を最大にするでしょう。
A.6. Merging Networks
A.6。 ネットワークを合併します。
When two IPv4 networks want to merge, it is not guaranteed that both networks are using different address ranges on some parts of the network infrastructure due to the usage of RFC 1918 private addressing. This potential overlap in address space may complicate a merging of two and more networks dramatically due to the additional IPv4 renumbering effort, i.e., when the first network has a service running (NTP, DNS, DHCP, HTTP, etc.) that needs to be accessed by the second merging network. Similar address conflicts can happen when two network devices from these merging networks want to communicate.
2つのIPv4ネットワークが合併したい場合、両方のネットワークがRFC1918の個人的なアドレシングの用法のためネットワークインフラのいくつかの部分の上の異なったアドレスの範囲を使用しているのが保証されません。 アドレス空間におけるこの潜在的オーバラップは取り組みに番号を付け替えさせる追加IPv4のため2と、より多くのネットワークの合併を劇的に複雑にするかもしれません、すなわち、最初のネットワークにネットワークを合併しながら秒によってアクセスされる必要がある(NTP、DNS、DHCP、HTTPなど)を実行するサービスがあるとき。 ネットワークを合併するこれらからの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の使用法で、アドレシングオーバラップは個人的でローカルのアドレシングのためのUnique Local Address用法の存在のために存在しないでしょう。
Van de Velde, et al. Informational [Page 34] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[34ページ]のRFC4864企業内情報通信網保護
Authors' Addresses
作者のアドレス
Gunter Van de Velde Cisco Systems De Kleetlaan 6a Diegem 1831 Belgium
Gunterバン・デ・ベルデシスコシステムズDe Kleetlaan 6a Diegem1831ベルギー
Phone: +32 2704 5473 EMail: gunter@cisco.com
以下に電話をしてください。 +32 2704 5473はメールされます: gunter@cisco.com
Tony Hain Cisco Systems 500 108th Ave. NE Bellevue, Wa. USA
トニーハインシスコシステムズ500第108Ave。 NEベルビュー、Wa。 米国
EMail: alh-ietf@tndh.net
メール: alh-ietf@tndh.net
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
ラルフDromsシスコシステムズ1414マサチューセッツ通りBoxborough、MA01719米国
EMail: rdroms@cisco.com
メール: rdroms@cisco.com
Brian Carpenter IBM 8 Chemin de Blandonnet 1214 Vernier, CH
ブライアンCarpenter IBM8Chemin de Blandonnet1214Vernier、CH
EMail: brc@zurich.ibm.com
メール: brc@zurich.ibm.com
Eric Klein Tel Aviv University Tel Aviv, Israel
エリッククラインテルアビブ大学テルアビブ(イスラエル)
EMail: ericlklein.ipv6@gmail.com
メール: ericlklein.ipv6@gmail.com
Van de Velde, et al. Informational [Page 35] RFC 4864 Local Network Protection for IPv6 May 2007
ヴァンデヴェルデ、他 IPv6 May 2007のための情報[35ページ]のRFC4864企業内情報通信網保護
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Van de Velde, et al. Informational [Page 36]
ヴァンデヴェルデ、他 情報[36ページ]
一覧
スポンサーリンク