RFC4193 日本語訳
4193 Unique Local IPv6 Unicast Addresses. R. Hinden, B. Haberman. October 2005. (Format: TXT=35908 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group R. Hinden
Request for Comments: 4193 Nokia
Category: Standards Track B. Haberman
JHU-APL
October 2005
Hindenがコメントのために要求するワーキンググループR.をネットワークでつないでください: 4193年のノキアカテゴリ: 標準化過程B.ハーバーマンJHU-APL2005年10月
Unique Local IPv6 Unicast Addresses
ユニークなローカルのIPv6ユニキャストアドレス
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications, usually inside of a site. These addresses are not expected to be routable on the global Internet.
このドキュメントはグローバルにユニークであり、ローカルのコミュニケーションのために意図するIPv6ユニキャストアドレス形式、通常サイトの内部を定義します。 これらのアドレスが世界的なインターネットで発送可能でないと予想されます。
Table of Contents
目次
1. Introduction ....................................................2
2. Acknowledgements ................................................3
3. Local IPv6 Unicast Addresses ....................................3
3.1. Format .....................................................3
3.1.1. Background ..........................................4
3.2. Global ID ..................................................4
3.2.1. Locally Assigned Global IDs .........................5
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm ...5
3.2.3. Analysis of the Uniqueness of Global IDs ............6
3.3. Scope Definition ...........................................6
4. Operational Guidelines ..........................................7
4.1. Routing ....................................................7
4.2. Renumbering and Site Merging ...............................7
4.3. Site Border Router and Firewall Packet Filtering ...........8
4.4. DNS Issues .................................................8
4.5. Application and Higher Level Protocol Issues ...............9
4.6. Use of Local IPv6 Addresses for Local Communication ........9
4.7. Use of Local IPv6 Addresses with VPNs .....................10
1. 序論…2 2. 承認…3 3. ローカルのIPv6ユニキャストアドレス…3 3.1. 形式…3 3.1.1. バックグラウンド…4 3.2. グローバルなID…4 3.2.1. 局所的に、グローバルなIDを割り当てます…5 3.2.2. 擬似ランダムのグローバルなIDアルゴリズムのためにコードを抽出してください…5 3.2.3. グローバルなIDのユニークさの分析…6 3.3. 範囲定義…6 4. 運用指針…7 4.1. ルート設定…7 4.2. 番号を付け替えるのとサイト合併…7 4.3. サイト境界ルータとファイアウォールパケットフィルタリング…8 4.4. DNS問題…8 4.5. アプリケーションと、より高いレベルは問題について議定書の中で述べます…9 4.6. ローカルのIPv6アドレスのローカルのコミュニケーションの使用…9 4.7. VPNsとのローカルのIPv6アドレスの使用…10
Hinden & Haberman Standards Track [Page 1] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[1ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
5. Global Routing Considerations ..................................11
5.1. From the Standpoint of the Internet .......................11
5.2. From the Standpoint of a Site .............................11
6. Advantages and Disadvantages ...................................12
6.1. Advantages ................................................12
6.2. Disadvantages .............................................13
7. Security Considerations ........................................13
8. IANA Considerations ............................................13
9. References .....................................................13
9.1. Normative References ......................................13
9.2. Informative References ....................................14
5. グローバルなルート設定問題…11 5.1. インターネットの見地から…11 5.2. サイトの見地から…11 6. 利点と損失…12 6.1. 利点…12 6.2. 損失…13 7. セキュリティ問題…13 8. IANA問題…13 9. 参照…13 9.1. 標準の参照…13 9.2. 有益な参照…14
1. Introduction
1. 序論
This document defines an IPv6 unicast address format that is globally unique and is intended for local communications [IPV6]. These addresses are called Unique Local IPv6 Unicast Addresses and are abbreviated in this document as Local IPv6 addresses. They are not expected to be routable on the global Internet. They are routable inside of a more limited area such as a site. They may also be routed between a limited set of sites.
このドキュメントは、グローバルにユニークなIPv6ユニキャストアドレス形式を定義して、ローカルのコミュニケーション[IPV6]のために意図します。 これらのアドレスは、Unique Local IPv6 Unicast Addressesと呼ばれて、本書ではLocal IPv6アドレスが簡略化されています。 それらが世界的なインターネットで発送可能でないと予想されます。 それらはサイトなどの、より限られた領域の発送可能内部です。 また、それらは限られたセットのサイトの間に発送されるかもしれません。
Local IPv6 unicast addresses have the following characteristics:
ローカルのIPv6ユニキャストアドレスには、以下の特性があります:
- Globally unique prefix (with high probability of uniqueness).
- グローバルにユニークな接頭語(ユニークさの高い確率がある)。
- Well-known prefix to allow for easy filtering at site
boundaries.
- サイト境界の簡単なフィルタリングのために許容するよく知られる接頭語。
- Allow sites to be combined or privately interconnected without
creating any address conflicts or requiring renumbering of
interfaces that use these prefixes.
- どんなアドレス闘争も引き起こすか、またはこれらの接頭語を使用するインタフェースが番号を付け替える必要でない、サイトに結合されるか、または個人的にインタコネクトさせられてください。
- Internet Service Provider independent and can be used for
communications inside of a site without having any permanent or
intermittent Internet connectivity.
- インターネットサービスプロバイダ独立者、サイトのコミュニケーション内部に中古の、または、どんなパーマも持っていなくて間欠のインターネットの接続性はそうであることができます。
- If accidentally leaked outside of a site via routing or DNS,
there is no conflict with any other addresses.
- ルーティングかDNSを通して偶然サイトの外に漏らされるなら、いかなる他のアドレスとの闘争も全くありません。
- In practice, applications may treat these addresses like global
scoped addresses.
- 実際には、アプリケーションはグローバルな見られたアドレスのようにこれらのアドレスを扱うかもしれません。
This document defines the format of Local IPv6 addresses, how to allocate them, and usage considerations including routing, site border routers, DNS, application support, VPN usage, and guidelines for how to use for local communication inside a site.
このドキュメントはどう地方のコミュニケーション内部にどうサイトを使用するかためにはルーティング、サイト境界ルータ、DNS、アプリケーションサポート、VPN用法、およびガイドラインを含む問題をそれら、および用法に割り当てるかというLocal IPv6アドレスの書式を定義します。
Hinden & Haberman Standards Track [Page 2] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[2ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[RFC2119]で説明されるように本書では解釈されることであるべきですか?
2. Acknowledgements
2. 承認
The underlying idea of creating Local IPv6 addresses described in this document has been proposed a number of times by a variety of people. The authors of this document do not claim exclusive credit. Credit goes to Brian Carpenter, Christian Huitema, Aidan Williams, Andrew White, Charlie Perkins, and many others. The authors would also like to thank Brian Carpenter, Charlie Perkins, Harald Alvestrand, Keith Moore, Margaret Wasserman, Shannon Behrens, Alan Beard, Hans Kruse, Geoff Huston, Pekka Savola, Christian Huitema, Tim Chown, Steve Bellovin, Alex Zinin, Tony Hain, Bill Fenner, Sam Hartman, and Elwyn Davies for their comments and suggestions on this document.
本書では説明されたLocal IPv6アドレスを作成するという基本的な考えはさまざまな人々によって幾度か提案されました。 このドキュメントの作者は排他的なクレジットを要求しません。 クレジットはブライアンCarpenter、クリスチャンのHuitema、アイダン・ウィリアムズ、アンドリュー・ホワイト、チャーリー・パーキンス、および多くの他のもののものになります。 また、作者はこのドキュメントの上に彼らのコメントと提案についてブライアンCarpenter、チャーリー・パーキンス、ハラルドAlvestrand、キース・ムーア、マーガレット・ワッサーマン、シャノンBehrens、アランBeard、ハンス・クルーゼ、ジェフ・ヒューストン、ペッカSavola、クリスチャンのHuitema、ティムChown、スティーブBellovin、アレックス・ジニン、トニー・ハイン、ビル・フェナー、サム・ハートマン、およびElwynデイヴィースに感謝したがっています。
3. Local IPv6 Unicast Addresses
3. ローカルのIPv6ユニキャストアドレス
3.1. Format
3.1. 形式
The Local IPv6 addresses are created using a pseudo-randomly allocated global ID. They have the following format:
Local IPv6アドレスがaを使用することで作成される、疑似である、無作為である、割り当てられたグローバルなID。 彼らには、以下の形式があります:
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
| 7ビット|1| 40ビット| 16ビット| 64ビット| +--------+-+------------+-----------+----------------------------+ | 接頭語|L| グローバルなID| サブネットID| インタフェースID| +--------+-+------------+-----------+----------------------------+
Where:
どこ:
Prefix FC00::/7 prefix to identify Local IPv6 unicast
addresses.
FC00を前に置いてください:、:7がLocal IPv6ユニキャストアドレスを特定するために前に置く/。
L Set to 1 if the prefix is locally assigned.
Set to 0 may be defined in the future. See
Section 3.2 for additional information.
接頭語が局所的に割り当てられるなら、Lは1にセットしました。 0へのセットは将来、定義されるかもしれません。 追加情報に関してセクション3.2を見てください。
Global ID 40-bit global identifier used to create a
globally unique prefix. See Section 3.2 for
additional information.
グローバルなID40ビットのグローバルな識別子は以前はよくグローバルにユニークな接頭語を作成していました。 追加情報に関してセクション3.2を見てください。
Subnet ID 16-bit Subnet ID is an identifier of a subnet
within the site.
サブネットのIDの16ビットのSubnet IDはサイトの中のサブネットに関する識別子です。
Interface ID 64-bit Interface ID as defined in [ADDARCH].
[ADDARCH]で定義されるようにIDの64ビットのInterface IDを連結してください。
Hinden & Haberman Standards Track [Page 3] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[3ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
3.1.1. Background
3.1.1. バックグラウンド
There were a range of choices available when choosing the size of the prefix and Global ID field length. There is a direct tradeoff between having a Global ID field large enough to support foreseeable future growth and not using too much of the IPv6 address space needlessly. A reasonable way of evaluating a specific field length is to compare it to a projected 2050 world population of 9.3 billion [POPUL] and the number of resulting /48 prefixes per person. A range of prefix choices is shown in the following table:
接頭語とGlobal IDフィールド長のサイズを選ぶとき、利用可能なさまざまな選択がありました。 Global ID分野を予見できる今後の成長をサポートすることができるくらい大きくして、不必要にIPv6アドレス空間のあまりに多くを使用しないとき、直接見返りがあります。 特定のフィールド長を評価する合理的な方法は2050年の93億[POPUL]の映し出された世界人口と1人あたり結果になる/48の接頭語の数とそれを比較することです。 さまざまな接頭語選択が以下のテーブルに示されます:
Prefix Global ID Number of Prefixes % of IPv6
Length /48 Prefixes per Person Address Space
IPv6長さ/48の%が人のアドレス空間単位で前に置く接頭語のグローバルなID番号を前に置いてください。
/11 37 137,438,953,472 15 0.049%
/10 38 274,877,906,944 30 0.098%
/9 39 549,755,813,888 59 0.195%
/8 40 1,099,511,627,776 118 0.391%
/7 41 2,199,023,255,552 236 0.781%
/6 42 4,398,046,511,104 473 1.563%
/11 37 137,438,953,472 15 0.049% /10 38 274,877,906,944 30 0.098% /9 39 549,755,813,888 59 0.195% /8 40 1,099,511,627,776 118 0.391% /7 41 2,199,023,255,552 236 0.781% /6 42 4,398,046,511,104 473 1.563%
A very high utilization ratio of these allocations can be assumed because the Global ID field does not require internal structure, and there is no reason to be able to aggregate the prefixes.
Global ID分野が内部の構造を必要としないで、また接頭語に集めることができる理由が全くないので、これらの配分の非常に高い利用率を想定できます。
The authors believe that a /7 prefix resulting in a 41-bit Global ID space (including the L bit) is a good choice. It provides for a large number of assignments (i.e., 2.2 trillion) and at the same time uses less than .8% of the total IPv6 address space. It is unlikely that this space will be exhausted. If more than this were to be needed, then additional IPv6 address space could be allocated for this purpose.
作者は、41ビットのGlobal IDスペース(Lビットを含んでいる)をもたらす/7接頭語が良い選択であると信じています。 それは、多くの課題(すなわち、2兆2000億)に備えて、同時に、総IPv6アドレス空間の.8%未満を使用します。 このスペースが消耗するのは、ありそうもないです。 このために追加しているこれが必要であることになっていたより多くならIPv6アドレス空間を割り当てることができました。
3.2. Global ID
3.2. グローバルなID
The allocation of Global IDs is pseudo-random [RANDOM]. They MUST NOT be assigned sequentially or with well-known numbers. This is to ensure that there is not any relationship between allocations and to help clarify that these prefixes are not intended to be routed globally. Specifically, these prefixes are not designed to aggregate.
Global IDの配分は擬似ランダム[RANDOM]です。 連続するかよく知られる数でそれらを割り当ててはいけません。 これが配分の間には、少しの関係もないのを保証するためのものであり、それをはっきりさせるのを助けるために、これらの接頭語がグローバルに発送されることを意図しません。 明確に、これらの接頭語は、集めるように設計されていません。
This document defines a specific local method to allocate Global IDs, indicated by setting the L bit to 1. Another method, indicated by clearing the L bit, may be defined later. Apart from the allocation method, all Local IPv6 addresses behave and are treated identically.
このドキュメントはLビットを1に設定することによって示されたIDをGlobalに割り当てる特定のローカルのメソッドを定義します。 Lビットをきれいにすることによって示された別のメソッドは後で定義されるかもしれません。 配分方法は別として、すべてのLocal IPv6アドレスが、振る舞って、同様に扱われます。
Hinden & Haberman Standards Track [Page 4] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[4ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
The local assignments are self-generated and do not need any central coordination or assignment, but have an extremely high probability of being unique.
ローカルの課題は、自己を発生させていて、どんな主要なコーディネートや課題も必要としませんが、ユニークであるという非常に高い確率を持ってください。
3.2.1. Locally Assigned Global IDs
3.2.1. 局所的に割り当てられたグローバルなID
Locally assigned Global IDs MUST be generated with a pseudo-random algorithm consistent with [RANDOM]. Section 3.2.2 describes a suggested algorithm. It is important that all sites generating Global IDs use a functionally similar algorithm to ensure there is a high probability of uniqueness.
[RANDOM]と一致した擬似ランダムアルゴリズムで局所的に割り当てられたGlobal IDを生成しなければなりません。 セクション3.2 .2 提案されたアルゴリズムを説明します。 GlobalにIDを生成するすべてのサイトがユニークさの高い確率があるのを保証するのに機能上同様のアルゴリズムを使用するのは、重要です。
The use of a pseudo-random algorithm to generate Global IDs in the locally assigned prefix gives an assurance that any network numbered using such a prefix is highly unlikely to have that address space clash with any other network that has another locally assigned prefix allocated to it. This is a particularly useful property when considering a number of scenarios including networks that merge, overlapping VPN address space, or hosts mobile between such networks.
局所的に割り当てられた接頭語のGlobal IDであると生成する擬似ランダムアルゴリズムの使用はそのような接頭語を使用することで付番されたどんなネットワークも別の局所的に割り当てられた接頭語をそれに割り当てさせるいかなる他のネットワークとのそのアドレス空間衝突も非常に持っていそうにないという保証を与えます。 合併するネットワークを含む多くのシナリオを考えるとき、これは特に役に立つ特性です、そのようなネットワークの間のモバイルのVPNアドレス空間、またはホストを重ね合わせて。
3.2.2. Sample Code for Pseudo-Random Global ID Algorithm
3.2.2. 擬似ランダムのグローバルなIDアルゴリズムのためのサンプルコード
The algorithm described below is intended to be used for locally assigned Global IDs. In each case the resulting global ID will be used in the appropriate prefix as defined in Section 3.2.
局所的に割り当てられたGlobal IDに以下で説明されたアルゴリズムが使用されることを意図します。 その都度結果として起こるグローバルなIDはセクション3.2で定義されるように適切な接頭語に使用されるでしょう。
1) Obtain the current time of day in 64-bit NTP format [NTP].
1) 64ビットのNTP形式[NTP]で現在の時刻を得てください。
2) Obtain an EUI-64 identifier from the system running this
algorithm. If an EUI-64 does not exist, one can be created from
a 48-bit MAC address as specified in [ADDARCH]. If an EUI-64
cannot be obtained or created, a suitably unique identifier,
local to the node, should be used (e.g., system serial number).
2) このアルゴリズムを実行するシステムからEUI-64識別子を得てください。 EUI-64が存在していないなら、[ADDARCH]の指定されるとしての48ビットのMACアドレスから1つを作成できます。 EUI-64を入手できませんし、作成できないなら、適当にユニークなノードにローカルであることの識別子を使用するべきです(例えば、システム・シリアル番号)。
3) Concatenate the time of day with the system-specific identifier
in order to create a key.
3) キーを作成するためにシステム特有の識別子で時刻を連結してください。
4) Compute an SHA-1 digest on the key as specified in [FIPS, SHA1];
the resulting value is 160 bits.
4) [FIPS、SHA1]の指定されるとしてのキーに関するSHA-1ダイジェストを計算してください。 結果として起こる値は160ビットです。
5) Use the least significant 40 bits as the Global ID.
5) Global IDとして最も重要でない40ビットを使用してください。
6) Concatenate FC00::/7, the L bit set to 1, and the 40-bit Global
ID to create a Local IPv6 address prefix.
6) FC00を連結してください:、:Local IPv6アドレス接頭語を作成する/7、1に設定されたLビット、および40ビットのGlobal ID。
This algorithm will result in a Global ID that is reasonably unique and can be used to create a locally assigned Local IPv6 address prefix.
このアルゴリズムは、合理的にユニークなGlobal IDをもたらして、局所的に割り当てられたLocal IPv6アドレス接頭語を作成するのに使用できます。
Hinden & Haberman Standards Track [Page 5] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[5ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
3.2.3. Analysis of the Uniqueness of Global IDs
3.2.3. グローバルなIDのユニークさの分析
The selection of a pseudo random Global ID is similar to the selection of an SSRC identifier in RTP/RTCP defined in Section 8.1 of [RTP]. This analysis is adapted from that document.
疑似無作為のGlobal IDの選択は[RTP]のセクション8.1で定義されたRTP/RTCPでのSSRC識別子の選択と同様です。 この分析はそのドキュメントから適合させられます。
Since Global IDs are chosen randomly (and independently), it is possible that separate networks have chosen the same Global ID. For any given network, with one or more random Global IDs, that has inter-connections to other such networks, having a total of N such IDs, the probability that two or more of these IDs will collide can be approximated using the formula:
Global IDが手当たりしだいに(独自である)選ばれているので、別々のネットワークが同じGlobal IDを選んだのは、可能です。 1か、より無作為のGlobal IDがあるそのような合計N IDを持っていて、他のそのようなネットワークには相互接続があるどんな与えられたネットワークにおいても、公式を使用することでこれらの2つ以上のIDが衝突するという確率に近似できます:
P = 1 - exp(-N**2 / 2**(L+1))
P=1--exp(-N**2 / 2**(L+1))
where P is the probability of collision, N is the number of interconnected Global IDs, and L is the length of the Global ID.
Pが衝突確率であるところでは、NはインタコネクトされたGlobal IDの数です、そして、LはGlobal IDの長さです。
The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field.
以下のテーブルは、さまざまな接続のために40ビットのGlobal ID分野を使用することで衝突の確率を示しています。
Connections Probability of Collision
コネクションズ衝突確率
2 1.81*10^-12
10 4.54*10^-11
100 4.54*10^-09
1000 4.54*10^-07
10000 4.54*10^-05
2 1.81*10^-12 10 4.54*10^-11 100 4.54*10^-09 1000 4.54*10^-07 10000 4.54*10^-05
Based on this analysis, the uniqueness of locally generated Global IDs is adequate for sites planning a small to moderate amount of inter-site communication using locally generated Global IDs.
この分析に基づいて、局所的に生成しているGlobal IDを使用することで相互サイトコミュニケーションの量を加減するために小さいaを計画しているサイトに、局所的に生成しているGlobal IDのユニークさは適切です。
3.3. Scope Definition
3.3. 範囲定義
By default, the scope of these addresses is global. That is, they are not limited by ambiguity like the site-local addresses defined in [ADDARCH]. Rather, these prefixes are globally unique, and as such, their applicability is greater than site-local addresses. Their limitation is in the routability of the prefixes, which is limited to a site and any explicit routing agreements with other sites to propagate them (also see Section 4.1). Also, unlike site-locals, a site may have more than one of these prefixes and use them at the same time.
デフォルトで、これらのアドレスの範囲はグローバルです。 すなわち、それらは[ADDARCH]で定義されたサイトローカルのアドレスのようにあいまいさによって制限されません。 むしろ、これらの接頭語がグローバルにユニークであり、そういうものとして、彼らの適用性はサイトローカルのアドレスよりすばらしいです。 彼らの制限が接頭語のroutabilityにあります(また、セクション4.1を見てください)。(routabilityは、それらを伝播するために他のサイトとのサイトとどんな明白なルーティング協定にも制限されます)。 また、サイトは、サイトローカルと異なって、これらの接頭語の1つ以上を持って、同時に、それらを使用するかもしれません。
Hinden & Haberman Standards Track [Page 6] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[6ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
4. Operational Guidelines
4. 運用指針
The guidelines in this section do not require any change to the normal routing and forwarding functionality in an IPv6 host or router. These are configuration and operational usage guidelines.
このセクションのガイドラインは正常なルーティングと機能性を転送することへのIPv6ホストかルータにおける少しの変化も必要としません。 これらは、構成と操作上の用法ガイドラインです。
4.1. Routing
4.1. ルート設定
Local IPv6 addresses are designed to be routed inside of a site in the same manner as other types of unicast addresses. They can be carried in any IPv6 routing protocol without any change.
ローカルのIPv6アドレスは、他のタイプのユニキャストアドレスと同じ方法によるサイトの発送された内部になるように設計されています。 少しも変化なしでどんなIPv6ルーティング・プロトコルでもそれらを運ぶことができます。
It is expected that they would share the same Subnet IDs with provider-based global unicast addresses, if they were being used concurrently [GLOBAL].
彼らがプロバイダーベースのグローバルなユニキャストアドレスと同じSubnet IDを共有すると予想されます、それらが同時に[GLOBAL]使用されていたなら。
The default behavior of exterior routing protocol sessions between administrative routing regions must be to ignore receipt of and not advertise prefixes in the FC00::/7 block. A network operator may specifically configure prefixes longer than FC00::/7 for inter-site communication.
管理ルーティング領域の間の外のルーティング・プロトコルセッションのデフォルトの振舞いは、FC00に領収書を無視して、接頭語の広告を出してはいけないことです:、:7が妨げる/。 オペレータが明確に構成するかもしれないネットワークはFC00より長い間、以下を前に置きます:相互サイトコミュニケーションのための/7。
If BGP is being used at the site border with an ISP, the default BGP configuration must filter out any Local IPv6 address prefixes, both incoming and outgoing. It must be set both to keep any Local IPv6 address prefixes from being advertised outside of the site as well as to keep these prefixes from being learned from another site. The exception to this is if there are specific /48 or longer routes created for one or more Local IPv6 prefixes.
BGPがISPとのサイト境界で使用されているなら、デフォルトBGP構成はどんなLocal IPv6アドレス接頭語も無視しなければなりません、ともに送受信しています。 どんなLocal IPv6アドレス接頭語もサイトの外に広告を出すのを妨げて、これらの接頭語が別のサイトから学習されるのを妨げるのは、セットの両方であるに違いありません。 これへの例外は、特定の/48があるか、そして、1つ以上のLocal IPv6接頭語のために作成されたより長いルートです。
For link-state IGPs, it is suggested that a site utilizing IPv6 local address prefixes be contained within one IGP domain or area. By containing an IPv6 local address prefix to a single link-state area or domain, the distribution of prefixes can be controlled.
リンク州のIGPsに関しては、IPv6ローカルアドレス接頭語を利用するサイトが1つのIGPドメインか領域の中に保管されていることが提案されます。 ただ一つのリンク州の領域かドメインにIPv6ローカルアドレス接頭語を含むことによって、接頭語の分配を制御できます。
4.2. Renumbering and Site Merging
4.2. 番号を付け替えるのとサイト合併
The use of Local IPv6 addresses in a site results in making communication that uses these addresses independent of renumbering a site's provider-based global addresses.
Local IPv6の使用はサイトでサイトのプロバイダーベースのグローバルなアドレスに番号を付け替えさせることの如何にかかわらずこれらを使用するコミュニケーションをアドレスにする際に結果を扱います。
When merging multiple sites, the addresses created with these prefixes are unlikely to need to be renumbered because all of the addresses have a high probability of being unique. Routes for each specific prefix would have to be configured to allow routing to work correctly between the formerly separate sites.
複数のサイトを合併するとき、これらの接頭語で作成されたアドレスは、アドレスのすべてにはユニークであるという高い確率があるので番号を付け替えられる必要がありそうにはありません。 それぞれの特定の接頭語のためのルートは、ルーティングが以前別々のサイトの間で正しく働くのを許容するために構成されなければならないでしょう。
Hinden & Haberman Standards Track [Page 7] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[7ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
4.3. Site Border Router and Firewall Packet Filtering
4.3. サイト境界ルータとファイアウォールパケットフィルタリング
While no serious harm will be done if packets with these addresses are sent outside of a site via a default route, it is recommended that routers be configured by default to keep any packets with Local IPv6 addresses from leaking outside of the site and to keep any site prefixes from being advertised outside of their site.
デフォルトルートでこれらのアドレスがあるパケットをサイトの外に送ると、どんな重大な害も加えないでしょうが、ルータがサイトの外に漏出からLocal IPv6アドレスがあるどんなパケットも控えて、どんなサイト接頭語もそれらのサイトの外に広告を出すのを妨げるためにデフォルトで構成されるのは、お勧めです。
Site border routers and firewalls should be configured to not forward any packets with Local IPv6 source or destination addresses outside of the site, unless they have been explicitly configured with routing information about specific /48 or longer Local IPv6 prefixes. This will ensure that packets with Local IPv6 destination addresses will not be forwarded outside of the site via a default route. The default behavior of these devices should be to install a "reject" route for these prefixes. Site border routers should respond with the appropriate ICMPv6 Destination Unreachable message to inform the source that the packet was not forwarded. [ICMPV6]. This feedback is important to avoid transport protocol timeouts.
サイト境界ルータとファイアウォールはLocal IPv6ソースか送付先アドレスがあるどんなパケットもサイトの外に送らないように構成されるべきです、それらが特定の/48か、より長いLocal IPv6接頭語のルーティング情報によって明らかに構成されていないなら。 これは、Local IPv6送付先アドレスがあるパケットがデフォルトルートでサイトの外に送られないのを確実にするでしょう。 これらのデバイスのデフォルト働きはこれらの接頭語のために「廃棄物」ルートをインストールすることであるべきです。 サイト境界ルータはパケットが進められなかったことをソースに知らせる適切なICMPv6 Destination Unreachableメッセージで応じるべきです。 [ICMPV6。] このフィードバックは、トランスポート・プロトコルタイムアウトを避けるために重要です。
Routers that maintain peering arrangements between Autonomous Systems throughout the Internet should obey the recommendations for site border routers, unless configured otherwise.
インターネット中でAutonomous Systemsの間のじっと見るアレンジメントを維持するルータはサイト境界ルータのための推薦に従うべきです、別の方法で構成されない場合。
4.4. DNS Issues
4.4. DNS問題
At the present time, AAAA and PTR records for locally assigned local IPv6 addresses are not recommended to be installed in the global DNS.
現在では、局所的に割り当てられたローカルのIPv6アドレスのためのAAAAとPTR記録によってグローバルなDNSにインストールされることは勧められません。
For background on this recommendation, one of the concerns about adding AAAA and PTR records to the global DNS for locally assigned Local IPv6 addresses stems from the lack of complete assurance that the prefixes are unique. There is a small possibility that the same locally assigned IPv6 Local addresses will be used by two different organizations both claiming to be authoritative with different contents. In this scenario, it is likely there will be a connection attempt to the closest host with the corresponding locally assigned IPv6 Local address. This may result in connection timeouts, connection failures indicated by ICMP Destination Unreachable messages, or successful connections to the wrong host. Due to this concern, adding AAAA records for these addresses to the global DNS is thought to be unwise.
この推薦でのバックグラウンドのために、局所的に割り当てられたLocal IPv6のためにAAAAとPTR記録をグローバルなDNSに加えることに関する心配の1つは接頭語がユニークであるという完全な保証の不足から軸を扱います。 異なったコンテンツによって正式であると主張しながら同じ局所的に割り当てられたIPv6 Localアドレスが組織の2つの異なった両方によって使用される小さい可能性があります。 このシナリオでは、最も近いホストへの接続試みが局所的に割り当てられた対応するIPv6 Localアドレスと共にあるのは、ありそうです。 これは接続タイムアウト、失敗がICMP Destination Unreachableメッセージで示した接続、または間違ったホストとのうまくいっている接続をもたらすかもしれません。 この関心のため、これらのアドレスのためのAAAA記録をグローバルなDNSに加えるのが賢明でないと考えられます。
Reverse (address-to-name) queries for locally assigned IPv6 Local addresses MUST NOT be sent to name servers for the global DNS, due to the load that such queries would create for the authoritative name servers for the ip6.arpa zone. This form of query load is not specific to locally assigned Local IPv6 addresses; any current form
グローバルなDNSのために局所的に割り当てられたIPv6 Localアドレスのための逆(命名するアドレス)の質問をネームサーバに送ってはいけません、そのような質問が正式のネームサーバのためにip6.arpaゾーンに作成する負荷のため。 このフォームの質問荷重は局所的に割り当てられたLocal IPv6アドレスに特定ではありません。 どんな現在のフォーム
Hinden & Haberman Standards Track [Page 8] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[8ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
of local addressing creates additional load of this kind, due to reverse queries leaking out of the site. However, since allowing such queries to escape from the site serves no useful purpose, there is no good reason to make the existing load problems worse.
地方では、アドレシングがサイトから漏れる逆の質問のためこの種類の追加荷重を作成します。 しかしながら、そのような質問がサイトサーブからどんな役に立つ目的からも逃げないのを許容して以来、既存の負荷問題をより悪くするように、もっともな理由は全くありません。
The recommended way to avoid sending such queries to nameservers for the global DNS is for recursive name server implementations to act as if they were authoritative for an empty d.f.ip6.arpa zone and return RCODE 3 for any such query. Implementations that choose this strategy should allow it to be overridden, but returning an RCODE 3 response for such queries should be the default, both because this will reduce the query load problem and also because, if the site administrator has not set up the reverse tree corresponding to the locally assigned IPv6 Local addresses in use, returning RCODE 3 is in fact the correct answer.
グローバルなDNSのためにそのような質問をネームサーバに送るのを避けるお勧めの方法は、再帰的なネームサーバ実装がまるで人影のないd.f.ip6.arpaゾーンに、それらが正式であるかのように行動して、どんなそのような質問のためにもRCODE3を返すことです。 この戦略を選ぶ実装は、それがくつがえされるのを許容するべきですが、そのような質問のためのRCODE3応答を返すのは、デフォルトであるべきです、これが質問負荷問題をともに減少させて、事実上、サイトの管理者が局所的に割り当てられたIPv6 Localアドレスに使用中に対応する逆の木にセットしていないなら、戻っているRCODE3がまた、正解であるので。
4.5. Application and Higher Level Protocol Issues
4.5. アプリケーションと、より高いレベルは問題について議定書の中で述べます。
Application and other higher level protocols can treat Local IPv6 addresses in the same manner as other types of global unicast addresses. No special handling is required. This type of address may not be reachable, but that is no different from other types of IPv6 global unicast address. Applications need to be able to handle multiple addresses that may or may not be reachable at any point in time. In most cases, this complexity should be hidden in APIs.
アプリケーションと他の、より高い平らなプロトコルは他のタイプのグローバルなユニキャストアドレスとして同じ方法によるLocal IPv6アドレスを扱うことができます。 どんな特別な取り扱いも必要ではありません。 このタイプのアドレスは届かないかもしれませんが、それは他のタイプのIPv6のグローバルなユニキャストアドレスと異なっていません。 アプリケーションは、複数の時間内に任意な点で届くかもしれないアドレスを扱うことができる必要があります。 多くの場合、この複雑さはAPIに隠されるべきです。
From a host's perspective, the difference between Local IPv6 and other types of global unicast addresses shows up as different reachability and could be handled by default in that way. In some cases, it is better for nodes and applications to treat them differently from global unicast addresses. A starting point might be to give them preference over global unicast, but fall back to global unicast if a particular destination is found to be unreachable. Much of this behavior can be controlled by how they are allocated to nodes and put into the DNS. However, it is useful if a host can have both types of addresses and use them appropriately.
ホストの見解から、Local IPv6と他のタイプのグローバルなユニキャストアドレスの違いは、異なった可到達性として現れて、デフォルトでそのように扱われるかもしれません。 いくつかの場合、ノードとアプリケーションはそれらをグローバルなユニキャストアドレスと異なって扱うほうがよいです。 出発点がグローバルなユニキャストの上で優先をそれらに与えることであるかもしれませんが、特定の目的地が手が届かないのがわかっているなら、グローバルなユニキャストへ後ろへ下がってください。 どうそれらをノードに割り当てて、DNSに入れるかによってこの振舞いの多くを制御できます。 しかしながら、ホストが適切に両方のタイプのアドレスを持って、それらを使用できるなら、役に立ちます。
Note that the address selection mechanisms of [ADDSEL], and in particular the policy override mechanism replacing default address selection, are expected to be used on a site where Local IPv6 addresses are configured.
Local IPv6アドレスが構成されるサイトで[ADDSEL]のアドレス選択メカニズム、および特にデフォルトアドレス選択を取り替える方針オーバーライドメカニズムが使用されると予想されることに注意してください。
4.6. Use of Local IPv6 Addresses for Local Communication
4.6. ローカルのIPv6アドレスのローカルのコミュニケーションの使用
Local IPv6 addresses, like global scope unicast addresses, are only assigned to nodes if their use has been enabled (via IPv6 address autoconfiguration [ADDAUTO], DHCPv6 [DHCP6], or manually). They are
グローバルな範囲ユニキャストアドレスのように、彼らの使用が可能にされた場合にだけ(IPv6を通して、手動で、自動構成[ADDAUTO]、DHCPv6[DHCP6]を扱ってください)、ローカルのIPv6アドレスはノードに割り当てられます。 それらはそうです。
Hinden & Haberman Standards Track [Page 9] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[9ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
not created automatically in the way that IPv6 link-local addresses are and will not appear or be used unless they are purposely configured.
それらがわざわざ構成されないと、自動的にIPv6のリンクローカルのアドレスがそうである方法で作成されないで、また現れるか、または使用されないでしょう。
In order for hosts to autoconfigure Local IPv6 addresses, routers have to be configured to advertise Local IPv6 /64 prefixes in router advertisements, or a DHCPv6 server must have been configured to assign them. In order for a node to learn the Local IPv6 address of another node, the Local IPv6 address must have been installed in a naming system (e.g., DNS, proprietary naming system, etc.) For these reasons, controlling their usage in a site is straightforward.
ルータがルータ通知におけるLocal IPv6 /64接頭語の広告を出すために構成されなければならない、ホストがLocal IPv6アドレスを自動構成する命令では、さもなければ、DHCPv6サーバは、それらを割り当てるために構成されたに違いありません。 ノードが別のノードのLocal IPv6アドレスを学ぶように、Local IPv6アドレスは命名システム(例えば、DNS、独占命名システムなど)にインストールされたに違いありません。 これらの理由で、サイトのそれらの用法を制御するのは簡単です。
To limit the use of Local IPv6 addresses the following guidelines apply:
Local IPv6アドレスの使用を制限するために、以下のガイドラインは申し込まれます:
- Nodes that are to only be reachable inside of a site: The local
DNS should be configured to only include the Local IPv6
addresses of these nodes. Nodes with only Local IPv6 addresses
must not be installed in the global DNS.
- 中で届くだけであることになっているサイトのノード: 地方のDNSは、これらのノードのLocal IPv6アドレスを含むだけであるように構成されるべきです。 Local IPv6アドレスだけがあるノードをグローバルなDNSにインストールしてはいけません。
- Nodes that are to be limited to only communicate with other
nodes in the site: These nodes should be set to only
autoconfigure Local IPv6 addresses via [ADDAUTO] or to only
receive Local IPv6 addresses via [DHCP6]. Note: For the case
where both global and Local IPv6 prefixes are being advertised
on a subnet, this will require a switch in the devices to only
autoconfigure Local IPv6 addresses.
- 唯一に制限されることになっているノードはサイトで他のノードとコミュニケートします: [ADDAUTO]を通してLocal IPv6アドレスを自動構成するだけであるか、またはこれらのノードが[DHCP6]を通して単にLocal IPv6アドレスを受け取るように設定されるべきです。 以下に注意してください。 ともにグローバル、そして、Local IPv6接頭語がサブネットの広告に掲載されているケースのために、これはLocal IPv6アドレスを自動構成するだけであるデバイスでスイッチを必要とするでしょう。
- Nodes that are to be reachable from inside of the site and from
outside of the site: The DNS should be configured to include
the global addresses of these nodes. The local DNS may be
configured to also include the Local IPv6 addresses of these
nodes.
- サイトの内部とサイトの外部から届くことになっているノード: DNSは、これらのノードのグローバルなアドレスを含むように構成されるべきです。 地方のDNSは、また、これらのノードのLocal IPv6アドレスを含むように構成されるかもしれません。
- Nodes that can communicate with other nodes inside of the site
and outside of the site: These nodes should autoconfigure global
addresses via [ADDAUTO] or receive global address via [DHCP6].
They may also obtain Local IPv6 addresses via the same
mechanisms.
- 中で他のノードとコミュニケートできるサイトのノードとサイトの外部: これらのノードは、[ADDAUTO]を通してグローバルなアドレスを自動構成するはずであるか、または[DHCP6]を通してグローバルアドレスを受けるはずです。 また、彼らは同じメカニズムでLocal IPv6アドレスを得るかもしれません。
4.7. Use of Local IPv6 Addresses with VPNs
4.7. VPNsとのローカルのIPv6アドレスの使用
Local IPv6 addresses can be used for inter-site Virtual Private Networks (VPN) if appropriate routes are set up. Because the addresses are unique, these VPNs will work reliably and without the need for translation. They have the additional property that they will continue to work if the individual sites are renumbered or merged.
適切なルートがセットアップされるなら、相互サイトVirtual兵士のNetworks(VPN)にローカルのIPv6アドレスを使用できます。 アドレスがユニークであるので、これらのVPNsは確かと翻訳の必要性なしで働くでしょう。 彼らには、個々のサイトが番号を付け替えられるか、または合併されているなら、働き続けている追加特性があります。
Hinden & Haberman Standards Track [Page 10] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[10ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
5. Global Routing Considerations
5. グローバルなルート設定問題
Section 4.1 provides operational guidelines that forbid default routing of local addresses between sites. Concerns were raised to the IPv6 working group and to the IETF as a whole that sites may attempt to use local addresses as globally routed provider- independent addresses. This section describes why using local addresses as globally-routed provider-independent addresses is unadvisable.
セクション4.1はローカルのアドレスのルーティングをデフォルトに禁じる運用指針をサイトの間に提供します。 関心はIPv6ワーキンググループに高められました、そして、全体でサイトが使用するのを試みるかもしれないIETFに、ローカルのアドレスはプロバイダーの独立しているアドレスを同じくらいグローバルに発送しました。 このセクションは、グローバルに発送されたプロバイダーから独立しているアドレスとしてローカルのアドレスを使用するのがなぜ賢明でないかを説明します。
5.1. From the Standpoint of the Internet
5.1. インターネットの見地から
There is a mismatch between the structure of IPv6 local addresses and the normal IPv6 wide area routing model. The /48 prefix of an IPv6 local addresses fits nowhere in the normal hierarchy of IPv6 unicast addresses. Normal IPv6 unicast addresses can be routed hierarchically down to physical subnet (link) level and only have to be flat-routed on the physical subnet. IPv6 local addresses would have to be flat-routed even over the wide area Internet.
IPv6のローカルのアドレスの構造と普通のIPv6広い領域ルーティングモデルの間には、ミスマッチがあります。 IPv6のローカルのアドレスの/48接頭語はIPv6ユニキャストアドレスの正常な階層構造でどこにも合いません。 正常なIPv6ユニキャストアドレスは、階層的に物理的なサブネット(リンク)レベルまで発送できて、物理的なサブネットで平坦に発送されているだけでよいです。 IPv6のローカルのアドレスは広い領域にわたってさえアパートで発送されたインターネットでなければならないでしょう。
Thus, packets whose destination address is an IPv6 local address could be routed over the wide area only if the corresponding /48 prefix were carried by the wide area routing protocol in use, such as BGP. This contravenes the operational assumption that long prefixes will be aggregated into many fewer short prefixes, to limit the table size and convergence time of the routing protocol. If a network uses both normal IPv6 addresses [ADDARCH] and IPv6 local addresses, these types of addresses will certainly not aggregate with each other, since they differ from the most significant bit onwards. Neither will IPv6 local addresses aggregate with each other, due to their random bit patterns. This means that there would be a very significant operational penalty for attempting to use IPv6 local address prefixes generically with currently known wide area routing technology.
したがって、対応/48接頭語が使用中の広い領域ルーティング・プロトコルによって運ばれる場合にだけ、送付先アドレスがIPv6ローカルアドレスであるパケットを広い領域にわたって発送できるでしょうに、BGPなどのように。 これは長い接頭語がテーブル・サイズとルーティング・プロトコルの集合時間を制限するために多くの、より少ない短い接頭語に集められるという操作上の仮定に違反します。 ネットワークが正常なIPv6アドレス[ADDARCH]とIPv6のローカルのアドレスの両方を使用すると、確かに、これらのタイプのアドレスは互いと共に集められないでしょう、前方へ最も重要なビットと異なっているので。 それらの無作為のビット・パターンによる互いに伴う集合のIPv6ローカルのアドレスもそうしないでしょう。 これは、現在知られている広い領域ルーティング技術で一般的にIPv6ローカルアドレス接頭語を使用するのを試みるための非常に重要な操作上の刑罰があることを意味します。
5.2. From the Standpoint of a Site
5.2. サイトの見地から
There are a number of design factors in IPv6 local addresses that reduce the likelihood that IPv6 local addresses will be used as arbitrary global unicast addresses. These include:
IPv6のローカルのアドレスが任意のグローバルなユニキャストアドレスとして使用されるという見込みを減少させるIPv6のローカルのアドレスには多くの設計要素があります。 これらは:
- The default rules to filter packets and routes make it very
difficult to use IPv6 local addresses for arbitrary use across
the Internet. For a site to use them as general purpose unicast
addresses, it would have to make sure that the default rules
were not being used by all other sites and intermediate ISPs
used for their current and future communication.
- パケットとルートをフィルターにかける省略時の解釈で、任意の使用にインターネットの向こう側にIPv6のローカルのアドレスを使用するのは非常に難しくなります。 サイトが汎用のユニキャストアドレスとしてそれらを使用するように、省略時の解釈がそれらの現在の、そして、将来のコミュニケーションに使用される他のすべてのサイトと中間的ISPによって使用されていなかったのは確実にされなければならないでしょう。
Hinden & Haberman Standards Track [Page 11] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[11ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
- They are not mathematically guaranteed to be unique and are not
registered in public databases. Collisions, while highly
unlikely, are possible and a collision can compromise the
integrity of the communications. The lack of public
registration creates operational problems.
- それらは、特有になるように数学的に保証されないで、また公共のデータベースに登録されません。 非常にありそうもないのですが、衝突は可能です、そして、衝突はコミュニケーションの保全に感染することができます。 公共の登録の不足は運転上の問題を作成します。
- The addresses are allocated randomly. If a site had multiple
prefixes that it wanted to be used globally, the cost of
advertising them would be very high because they could not be
aggregated.
- 手当たりしだいにアドレスを割り当てます。 サイトにそれがグローバルに使用されたがっていた複数の接頭語があるなら、それらの広告を出す費用は、それらを集めることができなかったので、非常に高いでしょうに。
- They have a long prefix (i.e., /48) so a single local address
prefix doesn't provide enough address space to be used
exclusively by the largest organizations.
- 彼らには長い接頭語(すなわち、/48)があるので、ただ一つのローカルアドレス接頭語は排他的に最も大きい組織が使用できるくらいのアドレス空間を提供しません。
6. Advantages and Disadvantages
6. 利点と損失
6.1. Advantages
6.1. 利点
This approach has the following advantages:
このアプローチには、以下の利点があります:
- Provides Local IPv6 prefixes that can be used independently of
any provider-based IPv6 unicast address allocations. This is
useful for sites not always connected to the Internet or sites
that wish to have a distinct prefix that can be used to localize
traffic inside of the site.
- どんなプロバイダーベースのIPv6ユニキャストアドレス配分の如何にかかわらず使用できる接頭語をLocal IPv6に供給します。 これはいつもインターネットにつなげられたというわけではないサイトか中でトラフィックをローカライズするのに使用できるサイトの異なった接頭語を持ちたがっているサイトの役に立ちます。
- Applications can treat these addresses in an identical manner as
any other type of global IPv6 unicast addresses.
- アプリケーションはいかなる他のタイプのグローバルなIPv6ユニキャストアドレスとしても同じ方法によるこれらのアドレスを扱うことができます。
- Sites can be merged without any renumbering of the Local IPv6
addresses.
- Local IPv6アドレスの少しも番号を付け替えるのなしでサイトを合併できます。
- Sites can change their provider-based IPv6 unicast address
without disrupting any communication that uses Local IPv6
addresses.
- Local IPv6アドレスを使用するどんな通信システムも遮断しないで、サイトはそれらのプロバイダーベースのIPv6ユニキャストアドレスを変えることができます。
- Well-known prefix that allows for easy filtering at site
boundary.
- サイト境界で簡単なフィルタリングを考慮するよく知られる接頭語。
- Can be used for inter-site VPNs.
- 相互サイトVPNsに使用できます。
- If accidently leaked outside of a site via routing or DNS, there
is no conflict with any other addresses.
- ルーティングかDNSを通して事故にサイトの外に漏らされるなら、いかなる他のアドレスとの闘争も全くありません。
Hinden & Haberman Standards Track [Page 12] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[12ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
6.2. Disadvantages
6.2. 不都合
This approach has the following disadvantages:
このアプローチには、以下の損失があります:
- Not possible to route Local IPv6 prefixes on the global Internet
with current routing technology. Consequentially, it is
necessary to have the default behavior of site border routers to
filter these addresses.
- 世界的なインターネットで現在のルーティング技術でLocal IPv6接頭語を発送するのにおいて、可能ではありません。 結果的に、これらのアドレスをフィルターにかけるサイト境界ルータのデフォルトの振舞いを持つのが必要です。
- There is a very low probability of non-unique locally assigned
Global IDs being generated by the algorithm in Section 3.2.3.
This risk can be ignored for all practical purposes, but it
leads to a theoretical risk of clashing address prefixes.
- セクション3.2.3にはアルゴリズムで生成される局所的に割り当てられた非ユニークなGlobal IDの非常に低い確率があります。 実際上はこの危険を無視できますが、それはアドレスが前に置く衝突の理論上のリスクに通じます。
7. Security Considerations
7. セキュリティ問題
Local IPv6 addresses do not provide any inherent security to the nodes that use them. They may be used with filters at site boundaries to keep Local IPv6 traffic inside of the site, but this is no more or less secure than filtering any other type of global IPv6 unicast addresses.
ローカルのIPv6アドレスは少しの固有のセキュリティもそれらを使用するノードに提供しません。 それらはLocal IPv6トラフィックがサイトの内部であることを保つのにサイト境界のフィルタと共に使用されるかもしれませんが、これは、いかなる他のタイプのグローバルなIPv6ユニキャストアドレスもフィルターにかけるほど多くでない、または、より安全ではありません。
Local IPv6 addresses do allow for address-based security mechanisms, including IPsec, across end to end VPN connections.
VPN接続を終わらせるために終わりの向こう側にIPsecを含んでいて、ローカルのIPv6アドレスはアドレスベースのセキュリティー対策を考慮します。
8. IANA Considerations
8. IANA問題
The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
IANAはFC00を割り当てました:、:「ユニークな地方のユニキャスト」への/7接頭語。
9. References
9. 参照
9.1. Normative References
9.1. 引用規格
[ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6
(IPv6) Addressing Architecture", RFC 3513, April 2003.
[ADDARCH]HindenとR.とS.デアリング、「インターネットプロトコルバージョン6(IPv6)アドレッシング体系」、RFC3513、2003年4月。
[FIPS] "Federal Information Processing Standards Publication",
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[FIPS]「連邦政府の情報処理規格公表」((FIPSパブ)180-1)はハッシュ規格、1995年4月17日を確保します。
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[グローバルな] HindenとR.とデアリング、S.とE.Nordmark、「IPv6のグローバルなユニキャストアドレス形式」、RFC3587、2003年8月。
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
[ICMPV6] コンタ、A.、およびS.デアリング、「インターネットへのインターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます」、RFC2463、1998年12月。
Hinden & Haberman Standards Track [Page 13] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[13ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[IPV6]デアリング、S.とR.Hinden、「インターネットプロトコル、バージョン6(IPv6)仕様」、RFC2460、12月1998日
[NTP] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[NTP] 工場、D.、「ネットワーク時間は仕様、実装、および分析について議定書の中で述べ(バージョン3)」RFC1305、1992年3月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
イーストレークとD.と3番目、シラー、J.とS.クロッカー、「セキュリティのための偶発性要件」[無作為]のBCP106、2005年6月のRFC4086。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
[SHA1]イーストレーク3番目とD.とP.ジョーンズ、「米国安全なハッシュアルゴリズム1(SHA1)」、RFC3174 2001年9月。
9.2. Informative References
9.2. 有益な参照
[ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ADDAUTO] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[ADDSEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[ADDSEL]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[DHCP6] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and
M. Carney, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", RFC 3315, July 2003.
[DHCP6]Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[POPUL] Population Reference Bureau, "World Population Data Sheet
of the Population Reference Bureau 2002", August 2002.
[POPUL]人口参照事務局、「人口参照事務局2002の世界人口公的医薬品情報」2002年8月。
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
[RTP] Schulzrinne、H.、Casner、S.、フレディリック、R.、およびV.ジェーコブソン、「RTP:」 「リアルタイムのアプリケーションのためのトランスポート・プロトコル」、STD64、RFC3550、2003年7月。
Hinden & Haberman Standards Track [Page 14] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[14ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
Authors' Addresses
作者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM.Hindenノキア313フェアチャイルド・Driveカリフォルニア94043マウンテンビュー(米国)
Phone: +1 650 625-2004 EMail: bob.hinden@nokia.com
以下に電話をしてください。 +1 650 625-2004 メールしてください: bob.hinden@nokia.com
Brian Haberman Johns Hopkins University Applied Physics Lab 11100 Johns Hopkins Road Laurel, MD 20723 USA
ブライアンハーバーマンジョーンズ・ホプキンス大学応用物理学研究室11100のジョーンズ・ホプキン・Road MD20723ローレル(米国)
Phone: +1 443 778 1319 EMail: brian@innovationslab.net
以下に電話をしてください。 +1 1319年の443 778メール: brian@innovationslab.net
Hinden & Haberman Standards Track [Page 15] RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Hindenとハーバーマン標準化過程[15ページ]RFC4193のユニークな地方のIPv6ユニキャストは、10月が2005であると扱います。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
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 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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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機能のための基金は現在、インターネット協会によって提供されます。
Hinden & Haberman Standards Track [Page 16]
Hindenとハーバーマン標準化過程[16ページ]
一覧
スポンサーリンク
