[要約] RFC 4193は、IPv6ユニークローカルユニキャストアドレスに関する仕様を定めたものであり、グローバルに一意なプライベート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
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
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使用法、およびサイト内のローカル通信に使用する方法に関するガイドラインなどの使用に関する考慮事項を定義します。
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].
「必須」、「そうしない」、「必須」、「必要」、「「しない」、「そうでない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、[RFC2119]に記載されているように解釈される。
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は、この文書に関するコメントと提案について。
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.
プレフィックスFC00 ::/7プレフィックスは、ローカル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.
グローバル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].
[addarch]で定義されているインターフェイスID 64ビットインターフェイスID。
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アドレススペースを不必要に使用しすぎないこととの間には、直接的なトレードオフがあります。特定のフィールドの長さを評価する合理的な方法は、それを93億[Popul]の2050年の世界人口と1人あたりの /48の接頭辞の数と比較することです。さまざまなプレフィックスの選択肢を次の表に示します。
Prefix Global ID Number of Prefixes % of IPv6 Length /48 Prefixes per Person Address Space
プレフィックスグローバルIDプレフィックス数IPv6長さ /48プレフィックスの1人あたりのプレフィックスアドレススペース
/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ビットを含む）をもたらすA /7プレフィックスが良い選択であると考えています。多数の割り当て（つまり、2.2兆）を提供し、同時にIPv6アドレス総合スペースの0.8％未満を使用します。このスペースが使い果たされる可能性は低いです。これ以上が必要な場合は、この目的のために追加のIPv6アドレススペースを割り当てることができます。
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アドレスが動作し、同じように扱われます。
The local assignments are self-generated and do not need any central coordination or assignment, but have an extremely high probability of being unique.
地元の課題は自己生成されており、中心的な調整や割り当ては必要ありませんが、ユニークである可能性が非常に高いです。
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アドレススペースの重複、またはそのようなネットワーク間でモバイルをホストするネットワークなど、多くのシナリオを考慮する場合、特に有用なプロパティです。
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) グローバル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 ::/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になります。
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を使用して、任意の特定のネットワークでは、合計でそのような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を使用して、小規模から中程度の量のサイト間通信を計画するサイトに適しています。
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も参照）。また、サイトロカルとは異なり、サイトはこれらのプレフィックスを複数持って使用し、同時にそれらを使用する場合があります。
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ホストまたはルーターの通常のルーティングおよび転送機能を変更する必要はありません。これらは、構成および運用上の使用ガイドラインです。
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.
リンク状態IGPSの場合、IPv6ローカルアドレスのプレフィックスを使用しているサイトを1つのIGPドメインまたは領域内に含めることが提案されています。単一のリンク状態領域またはドメインにIPv6ローカルアドレスプレフィックスを含めることにより、プレフィックスの分布を制御できます。
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.
複数のサイトをマージする場合、これらのプレフィックスで作成されたアドレスは、すべてのアドレスが一意である可能性が高いため、名前を変更する必要はほとんどありません。特定の各プレフィックスのルートは、以前に別々のサイト間でルーティングが正しく機能するように構成する必要があります。
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.
インターネット全体の自律システム間のピアリングの配置を維持するルーターは、特に構成されていない限り、サイトボーダールーターの推奨事項に従う必要があります。
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レコードをグローバルDNSに追加することに関する懸念の1つは、接頭辞が一意であるという完全な保証の欠如に起因します。同じローカルに割り当てられたIPv6ローカルアドレスが、両方とも異なるコンテンツで権威あると主張する2つの異なる組織で使用される可能性があります。このシナリオでは、対応するローカルに割り当てられたIPv6ローカルアドレスを持つ最も近いホストへの接続試行がある可能性があります。これにより、接続のタイムアウト、ICMP宛先の到達不可能なメッセージによって示される接続障害、または間違ったホストへの接続が成功する可能性があります。この懸念により、これらのアドレスに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 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ローカルアドレスのリバース（アドレスから名前へ）クエリは、IP6.ARPAゾーンの権威ある名前サーバーに対してそのようなクエリが作成する負荷のため、グローバルDNSの名前サーバーに送信してはなりません。この形式のクエリ負荷は、ローカルに割り当てられたローカル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を返すことは、実際には正解です。
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アドレスが構成されているサイトで使用されることが予想されることに注意してください。
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 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アドレスAutoconfiguration [addauto]、DHCPv6 [DHCP6]、または手動）。それらは、IPv6 Link-Localアドレスが意図的に構成されていない限り、表示または使用されない方法で自動的に作成されません。
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プレフィックスを宣伝するようにルーターを構成する必要があります。ノードが別のノードのローカル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アドレスのみをautoconfigureするためにデバイスのスイッチが必要になります。
- 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アドレスを取得する場合があります。
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は確実に機能し、翻訳を必要とせずに機能します。彼らは、個々のサイトが変更または合併された場合、彼らが引き続き働くという追加のプロパティを持っています。
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全体に懸念が提起されました。これは、サイトがグローバルにルーティングされたプロバイダーに依存しないアドレスとしてローカルアドレスを使用しようとする場合があります。このセクションでは、ローカルアドレスをグローバルにルーティングされたプロバイダーに依存しないアドレスとして使用することが適切である理由について説明します。
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.
したがって、宛先アドレスがIPv6ローカルアドレスであるパケットは、BGPなどの使用されている広い領域ルーティングプロトコルによって対応する /48プレフィックスが運ばれた場合にのみ、広い領域でルーティングできます。これは、ルーティングプロトコルのテーブルサイズと収束時間を制限するために、長いプレフィックスが多くの短いプレフィックスに集約されるという運用上の仮定に違反します。ネットワークが通常のIPv6アドレス[ADDARCH]とIPv6ローカルアドレスの両方を使用する場合、これらのタイプのアドレスは、最も重要なビット以降とは異なるため、互いに集約しません。どちらも、ランダムなビットパターンのため、IPv6ローカルアドレスは互いに集約されません。これは、現在既知の広い領域ルーティングテクノロジーを使用して、IPv6ローカルアドレスのプレフィックスを一般的に使用しようとするために非常に重要な運用上のペナルティがあることを意味します。
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でデフォルトのルールが使用されていないことを確認する必要があります。
- 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）があるため、単一のローカルアドレスプレフィックスは、最大の組織だけが使用するのに十分なアドレススペースを提供しません。
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を介してサイトの外に誤って漏れた場合、他のアドレスと矛盾はありません。
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が非常に低い確率があります。このリスクは、すべての実用的な目的で無視できますが、住所のプレフィックスを衝突する理論的リスクにつながります。
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アドレスでは、IPSECを含むアドレスベースのセキュリティメカニズムが端から端までVPN接続を越えて可能になります。
The IANA has assigned the FC00::/7 prefix to "Unique Local Unicast".
IANAは、FC00 ::/7プレフィックスを「一意のローカルユニキャスト」に割り当てました。
[ADDARCH] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[Addarch] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アーキテクチャのアドレス指定」、RFC 3513、2003年4月。
[FIPS] "Federal Information Processing Standards Publication", (FIPS PUB) 180-1, Secure Hash Standard, 17 April 1995.
[FIPS]「Federal Information Processards Standards Publication」、（FIPS Pub）180-1、Secure Hash Standard、1995年4月17日。
[GLOBAL] Hinden, R., Deering, S., and E. Nordmark, "IPv6 Global Unicast Address Format", RFC 3587, August 2003.
[Global] Hinden、R.、Deering、S。、およびE. Nordmark、「IPv6 Global Unicastアドレス形式」、RFC 3587、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] Conta、A。およびS. Deering、「インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPV6）」、RFC 2463、1998年12月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPv6] Deering、S。and R. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[NTP] Mills, D., "Network Time Protocol (Version 3) Specification, Implementation and Analysis", RFC 1305, March 1992.
[NTP] Mills、D。、「ネットワークタイムプロトコル（バージョン3）仕様、実装および分析」、RFC 1305、1992年3月。
[RANDOM] Eastlake, D., 3rd, Schiller, J., and S. Crocker, "Randomness Requirements for Security", BCP 106, RFC 4086, June 2005.
[ランダム] Eastlake、D.、3rd、Schiller、J。、およびS. Crocker、「セキュリティのランダム性要件」、BCP 106、RFC 4086、2005年6月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[SHA1] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm 1 (SHA1)", RFC 3174, September 2001.
[SHA1] EastLake 3rd、D。およびP. Jones、「US Secure Hash Algorithm 1（SHA1）」、RFC 3174、2001年9月。
[ADDAUTO] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[Addauto] Thomson、S。and T. Narten、「IPv6 Stateless Address Autoconfiguration」、RFC 2462、1998年12月。
[ADDSEL] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
[Addsel] Draves、R。、「インターネットプロトコルバージョン6（IPv6）のデフォルトアドレス選択」、RFC 3484、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.、Bound、J.、Volz、B.、Lemon、T.、Perkins、C。、およびM. Carney、「IPv6の動的ホスト構成プロトコル」、RFC 3315、2003年7月。
[POPUL] Population Reference Bureau, "World Population Data Sheet of the Population Reference Bureau 2002", August 2002.
[Popul]人口参照局、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.、Frederick、R。、およびV. Jacobson、「RTP：リアルタイムアプリケーション用の輸送プロトコル」、STD 64、RFC 3550、2003年7月。
Authors' Addresses
著者のアドレス
Robert M. Hinden Nokia 313 Fairchild Drive Mountain View, CA 94043 USA
ロバートM.ヒンデンノキア313フェアチャイルドドライブマウンテンビュー、カリフォルニア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
ブライアンハーバーマンジョンズホプキンス大学応用物理学ラボ11100ジョンズホプキンスロードローレル、メリーランド20723アメリカ
Phone: +1 443 778 1319
EMail: brian@innovationslab.net
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2005).
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.
この文書は、BCP 78に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY 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.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、この文書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスがどの程度であるかについての使用に関連すると主張する可能性があるという立場はありません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。RFCドキュメントの権利に関する手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要な技術をカバーする可能性のあるその他の独自の権利を注意深く招待するよう招待しています。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。