一意のローカルIPv6ユニキャストアドレス
英文を機械翻訳で日本語訳としています。日本語訳が正しくないことが考えられますので原文をメインとし、参考程度にご利用ください。
日本語訳
Network Working Group R. Hinden
Request for Comments: 4193 Nokia
Category: Standards Track B. Haberman
JHU-APL
October 2005
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.
このドキュメントは、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。 このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。 このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2005).
Copyright（C）The Internet Society（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
Hinden & Haberman Standards Track [Page 1]
RFC 4193 Unique Local IPv6 Unicast Addresses October 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
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. VPNでのローカルIPv6アドレスの使用..................... 10
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ユニキャストアドレス形式を定義しています。 これらのアドレスは一意のローカルIPv6ユニキャストアドレスと呼ばれ、このドキュメントではローカル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.
このドキュメントでは、ローカルIPv6アドレスの形式、アドレスの割り当て方法、ルーティング、サイト境界ルーター、DNS、アプリケーションサポート、VPNの使用法、サイト内のローカル通信に使用する方法のガイドラインなどの使用上の考慮事項を定義します。
Hinden & Haberman Standards Track [Page 2] RFC 4193 Unique Local IPv6 Unicast Addresses October 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」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [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.
このドキュメントで説明されているローカルIPv6アドレスを作成する基本的なアイデアは、さまざまな人々から何度も提案されています。 このドキュメントの作成者は、独占的なクレジットを主張しません。 クレジットは、ブライアンカーペンター、クリスチャンウイテマ、エイダンウィリアムズ、アンドリューホワイト、チャーリーパーキンス、その他多数に支払われます。 著者は、ブライアン・カーペンター、チャーリー・パーキンス、ハラルド・アルヴェストランド、キース・ムーア、マーガレット・ワッサーマン、シャノン・ベーレンス、アラン・ビアード、ハンス・クルーゼ、ジェフ・ヒューストン、ペッカ・サヴォラ、クリスチャン・ウイテマ、ティム・チョウン、スティーブ・ベロビン、アレックス・ジニン、トニーにも感謝します Hain、Bill Fenner、Sam Hartman、およびElwyn Daviesは、このドキュメントに対するコメントと提案を提供してくれました。
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:
ローカルIPv6アドレスは、疑似ランダムに割り当てられたグローバルIDを使用して作成されます。 それらの形式は次のとおりです。
| 7 bits |1| 40 bits | 16 bits | 64 bits |
+--------+-+------------+-----------+----------------------------+
| Prefix |L| Global ID | Subnet ID | Interface ID |
+--------+-+------------+-----------+----------------------------+
Where:
どこ：
Prefix FC00::/7 prefix to identify Local IPv6 unicast
addresses.
接頭辞 ローカルIPv6ユニキャストアドレスを識別する
FC00 :: / 7プレフィックス。
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.
グローバルID グローバルに一意のプレフィックスを作成するために
使用される40ビットのグローバル識別子。
詳細については、セクション3.2を参照してください。
Subnet ID 16-bit Subnet ID is an identifier of a subnet
within the site.
サブネットID 16ビットのサブネットIDは、サイト内のサブネットの
識別子です。
Interface ID 64-bit Interface ID as defined in [ADDARCH].
インターフェースID [ADDARCH]で定義されている64ビットのインターフェースID。
Hinden & Haberman Standards Track [Page 3] RFC 4193 Unique Local IPv6 Unicast Addresses October 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:
接頭辞のサイズとグローバルIDフィールドの長さを選択するときに利用できる選択肢の範囲がありました。 予測可能な将来の成長をサポートするのに十分な大きさのグローバルIDフィールドを持つことと、不必要にIPv6アドレス空間を使いすぎないことの間には直接的なトレードオフがあります。 特定のフィールド長を評価する合理的な方法は、予測された2050年の世界人口93億[POPUL]と、1人あたりの/ 48プレフィックスの数を比較することです。 次の表に、プレフィックスの選択肢の範囲を示します。
Prefix Global ID Number of Prefixes % of IPv6
Length /48 Prefixes per Person Address Space
/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.
グローバル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ビットのグローバルIDスペース（Lビットを含む）となる/ 7プレフィックスが適切な選択であると考えています。 これは、多数の割り当て（つまり、2.2兆）を提供し、同時にIPv6アドレス空間全体の0.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.
グローバルIDの割り当ては、疑似ランダム[ランダム]です。 それらは、順番に、または既知の番号で割り当ててはなりません。 これは、割り当て間に関係がないことを確認し、これらのプレフィックスがグローバルにルーティングされることを意図していないことを明確にするのに役立ちます。 具体的には、これらのプレフィックスは集約するようには設計されていません。
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を割り当てる特定のローカルメソッドを定義します。 Lビットをクリアすることで示される別の方法は、後で定義できます。 割り当て方法を除いて、すべてのローカルIPv6アドレスは動作し、同じように扱われます。
Hinden & Haberman Standards Track [Page 4] RFC 4193 Unique Local IPv6 Unicast Addresses October 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.
ローカルに割り当てられたグローバルIDは、[ランダム]と一貫性のある疑似ランダムアルゴリズムで生成する必要があります。 セクション3.2.2では、推奨されるアルゴリズムについて説明します。 グローバル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.
ローカルに割り当てられたプレフィックスでグローバル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.
以下で説明するアルゴリズムは、ローカルに割り当てられたグローバル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アドレスから作成できます。 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）最下位の40ビットをグローバルIDとして使用します。
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 :: / 7を連結し、Lビットを1に、40ビットのグローバルIDを連結して、ローカルIPv6アドレスプレフィックスを作成します。
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.
このアルゴリズムは、適度に一意であり、ローカルに割り当てられたローカルIPv6アドレスプレフィックスを作成するために使用できるグローバルIDになります。
Hinden & Haberman Standards Track [Page 5] RFC 4193 Unique Local IPv6 Unicast Addresses October 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.
擬似ランダムグローバル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:
グローバルIDはランダムに（そして独立して）選択されるため、別のネットワークが同じグローバルIDを選択した可能性があります。 1つ以上のランダムなグローバルIDを持ち、他のそのようなネットワークへの相互接続があり、合計N個のそのようなIDを持つ任意の特定のネットワークについて、これらのIDの2つ以上が衝突する確率は、次の式を使用して概算できます。
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は相互接続されたグローバルIDの数、LはグローバルIDの長さです。
The following table shows the probability of a collision for a range of connections using a 40-bit Global ID field.
次の表は、40ビットのグローバル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
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.
この分析に基づいて、ローカルで生成されたグローバルIDの一意性は、ローカルで生成されたグローバル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]で定義されているサイトローカルアドレスのようなあいまいさによって制限されることはありません。 むしろ、これらのプレフィックスはグローバルに一意であるため、その適用範囲はサイトローカルアドレスよりも優れています。 それらの制限は、プレフィックスのルーティング可能性にあります。これは、サイトと、それらを伝播するための他のサイトとの明示的なルーティング合意に限定されます（セクション4.1も参照）。 また、サイトローカルとは異なり、サイトにはこれらのプレフィックスが複数あり、それらを同時に使用する場合があります。
Hinden & Haberman Standards Track [Page 6] RFC 4193 Unique Local IPv6 Unicast Addresses October 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].
それらが同時に使用されている場合、それらはプロバイダーベースのグローバルユニキャストアドレスと同じサブネットIDを共有することが期待されます[グローバル]。
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構成では、着信と発信の両方のローカルIPv6アドレスプレフィックスを除外する必要があります。 ローカルIPv6アドレスプレフィックスがサイト外にアドバタイズされないようにするとともに、これらのプレフィックスが別のサイトから学習されないようにするためにも設定する必要があります。 これの例外は、1つまたは複数のローカルIPv6プレフィックスに対して特定の/ 48以上のルートが作成されている場合です。
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.
リンクステートIGPの場合、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.
サイトでローカル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 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.
これらのアドレスを持つパケットがデフォルトルートを介してサイトの外部に送信される場合、深刻な害は発生しませんが、ローカル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.
特定の/ 48以上のローカルIPv6プレフィックスに関するルーティング情報で明示的に構成されていない限り、サイト境界ルーターとファイアウォールは、サイトの外部のローカルIPv6送信元または宛先アドレスを持つパケットを転送しないように構成する必要があります。 これにより、ローカルIPv6宛先アドレスを持つパケットが、デフォルトルートを介してサイト外に転送されなくなります。 これらのデバイスのデフォルトの動作では、これらのプレフィックスに「拒否」ルートをインストールする必要があります。 サイト境界ルーターは、適切なICMPv6宛先到達不能メッセージで応答して、パケットが転送されなかったことをソースに通知する必要があります。 [ICMPV6]。 このフィードバックは、トランスポートプロトコルのタイムアウトを回避するために重要です。
Routers that maintain peering arrangements between Autonomous Systems throughout the Internet should obey the recommendations for site border routers, unless configured otherwise.
インターネット全体で自律システム間のピアリング配置を維持するルーターは、特に構成されていない限り、サイト境界ルーターの推奨事項に従う必要があります。
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.
この推奨事項の背景として、ローカルに割り当てられたローカルIPv6アドレスのグローバルDNSにAAAAおよびPTRレコードを追加することに関する懸念の1つは、プレフィックスが一意であるという完全な保証の欠如に起因します。 ローカルで割り当てられた同じIPv6ローカルアドレスが、異なる内容で信頼できると主張する2つの異なる組織によって使用される可能性はわずかです。 このシナリオでは、対応するローカルに割り当てられたIPv6ローカルアドレスを持つ最も近いホストへの接続試行が行われる可能性があります。 これにより、接続タイムアウト、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 Hinden & Haberman Standards Track [Page 8] RFC 4193 Unique Local IPv6 Unicast Addresses October 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.
ローカルに割り当てられたIPv6ローカルアドレスに対するリバース（アドレスから名前）クエリは、グローバルDNSのネームサーバーに送信してはなりません（ip6.arpaゾーンの権限のあるネームサーバーに対して負荷がかかるため）。 この形式のクエリ負荷は、ローカルに割り当てられたローカルIPv6アドレスに固有のものではありません。 ローカルアドレッシングの現在の形式では、逆のクエリがサイトからリークするため、この種の追加の負荷が発生します。 ただし、このようなクエリをサイトからエスケープできるようにすることには意味がないため、既存の読み込みの問題を悪化させる正当な理由はありません。
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ゾーンに対して権限があるかのように動作し、そのようなクエリに対してRCODE 3を返すことです。 この戦略を選択する実装では、オーバーライドを許可する必要がありますが、このようなクエリに対してRCODE 3応答を返すことをデフォルトにする必要があります。これにより、クエリの負荷の問題が軽減され、サイト管理者がリバースツリーを設定していない場合も同様です。 使用中のローカルに割り当てられたIPv6ローカルアドレスに対応し、実際にはRCODE 3を返すことが正しい答えです。
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.
アプリケーションおよびその他の上位レベルのプロトコルは、ローカル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.
ホストの観点から見ると、ローカル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.
[ADDSEL]のアドレス選択メカニズム、特にデフォルトのアドレス選択に代わるポリシーオーバーライドメカニズムは、ローカルIPv6アドレスが構成されているサイトで使用されることが想定されていることに注意してください。
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 Hinden & Haberman Standards Track [Page 9] RFC 4193 Unique Local IPv6 Unicast Addresses October 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アドレスは、それらの使用が有効になっている場合にのみノードに割り当てられます（IPv6アドレス自動構成[ADDAUTO]、DHCPv6 [DHCP6]、または手動で）。 それらは、意図的に構成されていない限り、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.
ホストがローカルIPv6アドレスを自動構成するには、ルーターアドバタイズメントでローカルIPv6 / 64プレフィックスをアドバタイズするようにルーターを構成するか、DHCPv6サーバーを構成してそれらを割り当てる必要があります。 ノードが別のノードのローカルIPv6アドレスを学習するためには、ローカルIPv6アドレスがネーミングシステム（DNS、独自のネーミングシステムなど）にインストールされている必要があります。 これらの理由により、サイトでの使用の制御は簡単です。
To limit the use of Local IPv6 addresses the following guidelines apply:
ローカル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は、これらのノードのローカルIPv6アドレスのみを含むように構成する必要があります。 ローカル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]によるローカルIPv6アドレスの自動構成のみ、または[DHCP6]によるローカルIPv6アドレスの受信のみに設定する必要があります。 注：グローバルIPv6とローカルIPv6の両方のプレフィックスがサブネットでアドバタイズされている場合、これにはデバイスのスイッチでローカル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は、これらのノードのローカル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]を介してグローバルアドレスを受信する必要があります。 また、同じメカニズムでローカルIPv6アドレスを取得する場合もあります。
4.7. Use of Local IPv6 Addresses with VPNs
4.7。 VPNでのローカル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.
適切なルートが設定されている場合、ローカルIPv6アドレスをサイト間仮想プライベートネットワーク（VPN）に使用できます。 アドレスは一意であるため、これらのVPNは確実に機能し、変換の必要はありません。 それらには、個々のサイトが再番号付けまたはマージされた場合に引き続き機能するという追加のプロパティがあります。
Hinden & Haberman Standards Track [Page 10] RFC 4193 Unique Local IPv6 Unicast Addresses October 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プレフィックスがBGPなどの使用中の広域ルーティングプロトコルによって運ばれた場合にのみ、宛先アドレスがIPv6ローカルアドレスであるパケットを広域にルーティングできます。 これは、長いプレフィックスがはるかに少ない短いプレフィックスに集約され、ルーティングプロトコルのテーブルサイズと収束時間を制限するという運用上の前提に反します。 ネットワークが通常の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
- 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ユニキャストアドレス割り当てとは無関係に使用できるローカル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.
ローカルIPv6アドレスの番号を付け直すことなく、サイトを結合できます。
- Sites can change their provider-based IPv6 unicast address
without disrupting any communication that uses Local IPv6
addresses.
サイトは、ローカルIPv6アドレスを使用する通信を中断することなく、プロバイダーベースのIPv6ユニキャストアドレスを変更できます。
- Well-known prefix that allows for easy filtering at site
boundary.
サイト境界でのフィルタリングを容易にする既知のプレフィックス。
- Can be used for inter-site VPNs.
サイト間VPNに使用できます。
- 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 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.
現在のルーティングテクノロジーでは、グローバルインターネット上のローカル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のアルゴリズムによって生成される、一意でないローカルに割り当てられたグローバル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アドレスは、それらを使用するノードに固有のセキュリティを提供しません。 サイト境界でフィルターと組み合わせて使用して、サイト内のローカルIPv6トラフィックを維持できますが、これは、他のタイプのグローバルIPv6ユニキャストアドレスをフィルターするよりも多かれ少なかれ安全です。
Local IPv6 addresses do allow for address-based security mechanisms, including IPsec, across end to end VPN connections.
ローカルIPv6アドレスは、エンドツーエンドVPN接続全体で、IPsecを含むアドレスベースのセキュリティメカニズムを可能にします。
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.
[FIPS] "Federal Information Processing Standards Publication",
(FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global
Unicast Address Format", RFC 3587, August 2003.
[ICMPV6] Conta, A. and S. Deering, "Internet Control Message
Protocol (ICMPv6) for the Internet Protocol Version 6
(IPv6) Specification", RFC 2463, December 1998.
Hinden & Haberman Standards Track [Page 13]
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[NTP] Mills, D., "Network Time Protocol (Version 3)
Specification, Implementation and Analysis", RFC 1305,
March 1992.
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker,
"Randomness Requirements for Security", BCP 106, RFC 4086,
June 2005.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1
(SHA1)", RFC 3174, September 2001.
9.2. Informative References
9.2。 参考情報
[ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[ADDSEL] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[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.
[POPUL] Population Reference Bureau, "World Population Data Sheet
of the Population Reference Bureau 2002", August 2002.
[RTP] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003.
Hinden & Haberman Standards Track [Page 14]
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Authors' Addresses
Robert M. Hinden
Nokia
313 Fairchild Drive
Mountain View, CA 94043
USA
Phone: +1 650 625-2004
EMail: bob.hinden@nokia.com
Brian Haberman
Johns Hopkins University
Applied Physics Lab
11100 Johns Hopkins Road
Laurel, MD 20723
USA
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Hinden & Haberman Standards Track [Page 15]
RFC 4193 Unique Local IPv6 Unicast Addresses October 2005
Full Copyright Statement
Copyright (C) The Internet Society (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.
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.
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.
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.
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.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
Hinden & Haberman Standards Track [Page 16]