RFC5220 日本語訳
5220 Problem Statement for Default Address Selection in Multi-PrefixEnvironments: Operational Issues of RFC 3484 Default Rules. A.Matsumoto, T. Fujisaki, R. Hiromi, K. Kanayama. July 2008. (Format: TXT=33661 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
RFC一覧
英語原文
Network Working Group A. Matsumoto
Request for Comments: 5220 T. Fujisaki
Category: Informational NTT
R. Hiromi
Intec Netcore
K. Kanayama
INTEC Systems
July 2008
コメントを求めるワーキンググループA.松本の要求をネットワークでつないでください: 5220年のT.藤崎カテゴリ: 情報のNTTのNetcore K.KanayamaインテックシステムR.広見インテック2008年7月
Problem Statement for Default Address Selection in Multi-Prefix
Environments: Operational Issues of RFC 3484 Default Rules
マルチ接頭語環境におけるデフォルトアドレス選択のための問題声明: RFC3484省略時の解釈の操作上の問題
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
A single physical link can have multiple prefixes assigned to it. In that environment, end hosts might have multiple IP addresses and be required to use them selectively. RFC 3484 defines default source and destination address selection rules and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons. In some environments where multiple prefixes are assigned on a single physical link, the host using the default address selection rules will experience some trouble in communication. This document describes the possible problems that end hosts could encounter in an environment with multiple prefixes.
単一の物理的なリンクで、複数の接頭語をそれに割り当てることができます。 その環境で、終わりのホストは、複数のIPアドレスを持って、選択的にそれらを使用しなければならないかもしれません。 RFC3484はデフォルトソースと目的地アドレス選択規則を定義して、さまざまなOSsで実装されます。 しかし、それはいくつかの理由に操作上使用できないくらい難しいです。 複数の接頭語が単一の物理的なリンクに割り当てられるいくつかの環境で、デフォルトアドレス選択規則を使用しているホストはコミュニケーションにおける問題を経験するでしょう。 このドキュメントは終わりのホストが複数の接頭語で環境で遭遇できた起こりうる問題について説明します。
Matsumoto, et al. Informational [Page 1] RFC 5220 Address Selection PS July 2008
松本、他 情報[1ページ]のRFC5220は、選択PS7月が2008であると扱います。
Table of Contents
目次
1. Introduction ....................................................2
1.1. Scope of This Document .....................................3
2. Problem Statement ...............................................4
2.1. Source Address Selection ...................................4
2.1.1. Multiple Routers on a Single Interface ..............4
2.1.2. Ingress Filtering Problem ...........................5
2.1.3. Half-Closed Network Problem .........................6
2.1.4. Combined Use of Global and ULA ......................7
2.1.5. Site Renumbering ....................................8
2.1.6. Multicast Source Address Selection ..................9
2.1.7. Temporary Address Selection .........................9
2.2. Destination Address Selection .............................10
2.2.1. IPv4 or IPv6 Prioritization ........................10
2.2.2. ULA and IPv4 Dual-Stack Environment ................11
2.2.3. ULA or Global Prioritization .......................12
3. Conclusion .....................................................13
4. Security Considerations ........................................14
5. Normative References ...........................................14
1. 序論…2 1.1. このドキュメントの範囲…3 2. 問題声明…4 2.1. ソースアドレス選択…4 2.1.1. シングルに関する複数のルータが連結します…4 2.1.2. イングレスフィルタリング問題…5 2.1.3. 半開きなネットワーク問題…6 2.1.4. グローバルの使用とULAを結合します…7 2.1.5. サイトの番号を付け替えること…8 2.1.6. マルチキャストソースアドレス選択…9 2.1.7. 仮の住所選択…9 2.2. 目的地アドレス選択…10 2.2.1. IPv4かIPv6優先順位づけ…10 2.2.2. ULAとIPv4デュアルスタック環境…11 2.2.3. ULAかグローバルな優先順位づけ…12 3. 結論…13 4. セキュリティ問題…14 5. 標準の参照…14
1. Introduction
1. 序論
In IPv6, a single physical link can have multiple prefixes assigned to it. In such cases, an end host may have multiple IP addresses assigned to an interface on that link. In the IPv4-IPv6 dual-stack environment or in a site connected to both a Unique Local Address (ULA) [RFC4193] and globally routable networks, an end host typically has multiple IP addresses. These are examples of the networks that we focus on in this document. In such an environment, an end host may encounter some communication troubles.
IPv6では、単一の物理的なリンクで、複数の接頭語をそれに割り当てることができます。 そのような場合、終わりのホストはそのリンクで複数のIPアドレスをインタフェースに割り当てさせるかもしれません。 IPv4-IPv6デュアルスタック環境かUnique Local Address(ULA)[RFC4193]とグローバルに発送可能なネットワークの両方につなげられたサイトでは、終わりのホストは複数のIPアドレスを通常持っています。 これらは私たちが本書では焦点を合わせるネットワークに関する例です。 そのような環境で、終わりのホストはいくつかのコミュニケーション問題に遭遇するかもしれません。
Inappropriate source address selection at the end host causes unexpected asymmetric routing, filtering by a router, or discarding of packets because there is no route to the host.
終わりのホストの不適当なソースアドレス選択は予期していなかった非対称のルーティングを引き起こします、ホストへのルートが全くないので、パケットがルータでフィルターにかけるか、または捨てられて。
Considering a multi-prefix environment, destination address selection is also important for correct or better communication establishment.
また、マルチ接頭語が環境であると考える場合、正しいか、より良いコミュニケーション設立に、目的地アドレス選択も重要です。
RFC 3484 [RFC3484] defines default source and destination address selection algorithms and is implemented in a variety of OSs. But, it has been too difficult to use operationally for several reasons, such as lack of an autoconfiguration method. There are some problematic cases where the hosts using the default address selection rules encounter communication troubles.
RFC3484[RFC3484]はデフォルトソースと目的地アドレス選択アルゴリズムを定義して、さまざまなOSsで実装されます。 しかし、それは自動構成メソッドの不足などのいくつかの理由に操作上使用できないくらい難しいです。 いくつかの問題の多いケースがデフォルトアドレス選択規則を使用しているホストがコミュニケーション問題に遭遇するところにあります。
This document describes the possibilities of incorrect address selection that lead to dropping packets and communication failure.
このドキュメントはパケットと通信障害を下げるのに通じる不正確なアドレス選択の可能性について説明します。
Matsumoto, et al. Informational [Page 2] RFC 5220 Address Selection PS July 2008
松本、他 情報[2ページ]のRFC5220は、選択PS7月が2008であると扱います。
1.1. Scope of This Document
1.1. このドキュメントの範囲
As other mechanisms already exist, the multi-homing techniques for achieving redundancy are basically out of our scope.
他のメカニズムが既に存在するとき、達成冗長のためのマルチホーミングのテクニックは基本的に存在しています。私たちの範囲から。
We focus on an end-site network environment and unmanaged hosts in such an environment. This is because address selection behavior at these kinds of hosts is difficult to manipulate, owing to the users' lack of knowledge, hosts' location, or massiveness of the hosts.
私たちはそのような環境で端サイトネットワーク環境と非管理されたホストに焦点を合わせます。 これはこれらの種類のホストのアドレス選択の振舞いは操るのが難しいホストのユーザの知識不足、ホストの位置、または膨大のためにあります。
The scope of this document is to sort out problematic cases related to address selection. It includes problems that can be solved in the framework of RFC 3484 and problems that cannot. For the latter, RFC 3484 might be modified to meet their needs, or another address selection solution might be necessary. For the former, an additional mechanism that mitigates the operational difficulty might be necessary.
このドキュメントの範囲はアドレス選択に関連する問題の多いケースを整理することになっています。 それはRFC3484のフレームワークで解決できる問題とそうすることができない問題を含んでいます。 後者において、RFC3484が彼らの需要を満たすように変更されるかもしれませんか、または別のアドレス選択対策が必要であるかもしれません。 前者に、操作上の困難を緩和する追加メカニズムが必要であるかもしれません。
This document also includes simple solution analysis for each problematic case. This analysis basically just focuses on whether or not the case can be solved in the framework of RFC 3484. If not, some possible solutions are described. Even if a case can be solved in the framework of RFC 3484, as mentioned above, it does not necessarily mean that there is no operational difficulty. For example, in the environment stated above, it is not a feasible solution to configure each host's policy table by hand. So, for such a solution, the difficulty of configuration is yet another common problem.
また、このドキュメントはそれぞれの問題の多いケースのための簡単なソリューション分析を含んでいます。 この分析は基本的にただRFC3484のフレームワークでケースを解決できるかどうかに集中します。 そうでなければ、いくつかの可能なソリューションが説明されます。 RFC3484のフレームワークでケースを解決できても、以上のように、それは、必ずどんな操作上の困難もないことを意味するというわけではありません。 例えば、上に述べられた環境で、手で各ホストの方針テーブルを構成するのは、可能なソリューションではありません。 それで、そのようなソリューションのために、構成の困難はさらに別の共有する問題です。
Matsumoto, et al. Informational [Page 3] RFC 5220 Address Selection PS July 2008
松本、他 情報[3ページ]のRFC5220は、選択PS7月が2008であると扱います。
2. Problem Statement
2. 問題声明
2.1. Source Address Selection
2.1. ソースアドレス選択
2.1.1. Multiple Routers on a Single Interface
2.1.1. 単一のインタフェースの複数のルータ
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
+-----+---+ +----+----+
| Router1 | | Router2 |
+-------+-+ +-+-------+
| |
2001:db8:1000:1::/64 | | 2001:db8:8000:1::/64
| |
-----+-+-----+------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
================== | インターネット| ================== | | 2001:db8:1000:、:/36 | | 2001:db8:8000:、:/36 +----+-+ +-+----+ | ISP1| | ISP2| +----+-+ +-+----+ | | 2001:db8:1000:、:、:/48 | | 2001:db8:8000:、:/48 +-----+---+ +----+----+ | Router1| | Router2| +-------+-+ +-+-------+ | | 2001 : db8:1000:1:、:/64 | | 2001 : db8:8000:1:、:/64 | | -----+-+-----+------ | +-+----+2001: db8:1000:1:、:100 | ホスト| 2001 : db8:8000:1:、:100 +------+
Figure 1
図1
Generally speaking, there is no interaction between next-hop determination and address selection. In this example, when a host starts a new connection and sends a packet via Router1, the host does not necessarily choose address 2001:db8:1000:1::100 given by Router1 as the source address. This causes the same problem as described in the next section, "Ingress Filtering Problem".
概して、次のホップ決断とアドレス選択との相互作用が全くありません。 ホストが新しい接続を始めて、Router1を通してパケットを送るとき、この例では、ホストは必ずアドレス2001: db8を選ぶというわけではありません:、1000:1、:、:100 ソースアドレスとしてRouter1によって与えられています。 これは次のセクションで説明される同じ問題、「問題をフィルターにかけるイングレス」を引き起こします。
Solution analysis:
As this case depends on next-hop selection, controlling the
address selection behavior at the Host alone doesn't solve the
entire problem. One possible solution for this case is adopting
source-address-based routing at Router1 and Router2. Another
solution may be using static routing at Router1, Router2, and the
Host, and using the corresponding static address selection policy
at the Host.
ソリューション分析: 本件が次のホップ選択によるとき、Hostで単独でアドレス選択の振舞いを制御するのは全体の問題を解決しません。 1つの可能なソリューションがこのような場合Router1とRouter2にソースアドレスベースのルーティングを採用しています。 他の解決法は、Router1、Router2、およびHostでスタティックルーティングを使用して、Hostで対応する静的なアドレス選択方針を使用しているかもしれません。
Matsumoto, et al. Informational [Page 4] RFC 5220 Address Selection PS July 2008
松本、他 情報[4ページ]のRFC5220は、選択PS7月が2008であると扱います。
2.1.2. Ingress Filtering Problem
2.1.2. 問題をフィルターにかけるイングレス
==================
| Internet |
==================
| |
2001:db8:1000::/36 | | 2001:db8:8000::/36
+----+-+ +-+----+
| ISP1 | | ISP2 |
+----+-+ +-+----+
| |
2001:db8:1000:::/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+-+----+ 2001:db8:1000:1::100
| Host | 2001:db8:8000:1::100
+------+
================== | インターネット| ================== | | 2001:db8:1000:、:/36 | | 2001:db8:8000:、:/36 +----+-+ +-+----+ | ISP1| | ISP2| +----+-+ +-+----+ | | 2001:db8:1000:、:、:/48 | | 2001:db8:8000:、:/48 ++-------++ | ルータ| +----+----+ | 2001 : db8:1000:1:、:/64 | 2001 : db8:8000:1:、:/64 ------+---+---------- | +-+----+2001: db8:1000:1:、:100 | ホスト| 2001 : db8:8000:1:、:100 +------+
Figure 2
図2
When a relatively small site, which we call a "customer network", is attached to two upstream ISPs, each ISP delegates a network address block, which is usually /48, and a host has multiple IPv6 addresses.
比較的小さいサイト(私たちは「顧客ネットワーク」と呼ぶ)は2つの上流のISPに添付されて、各ISPはネットワーク・アドレスが妨げる代表です、通常、/48であるもの、ホストが複数のIPv6アドレスを持っているとき。
When the source address of an outgoing packet is not the one that is delegated by an upstream ISP, there is a possibility that the packet will be dropped at the ISP by its ingress filter. Ingress filtering is becoming more popular among ISPs to mitigate the damage of denial-of-service (DoS) attacks.
出発しているパケットのソースアドレスが上流のISPによって代表として派遣されるものでないときに、パケットがイングレスフィルタによってISPで下げられる可能性があります。 イングレスフィルタリングは、サービスの否定(DoS)攻撃の損害を緩和するためにISPの中で、よりポピュラーになっています。
In this example, when the router chooses the default route to ISP2 and the host chooses 2001:db8:1000:1::100 as the source address for packets sent to a host (2001:db8:2000::1) somewhere on the Internet, the packets may be dropped at ISP2 because of ingress filtering.
ルータがISP2とホストへのルートが2001を選ぶデフォルト: db8を選ぶこの例で:、1000:1、:、:100 パケットのためのソースアドレスがインターネットのどこかでホスト(2001:db8:2000: : 1)に発信したなら、パケットはイングレスフィルタリングのためにISP2で下げられるかもしれません。
Solution analysis:
One possible solution for this case is adopting source-address-
based routing at the Router. Another solution may be using static
routing at the Router, and using the corresponding static address
selection policy at the Host.
ソリューション分析: 1つの可能なソリューションがこのような場合Routerにソースアドレスによるベースのルーティングを採用しています。 他の解決法は、Routerでスタティックルーティングを使用して、Hostで対応する静的なアドレス選択方針を使用しているかもしれません。
Matsumoto, et al. Informational [Page 5] RFC 5220 Address Selection PS July 2008
松本、他 情報[5ページ]のRFC5220は、選択PS7月が2008であると扱います。
2.1.3. Half-Closed Network Problem
2.1.3. 半開きなネットワーク問題
You can see a second typical source address selection problem in a multi-homed site with global half-closed connectivity, as shown in the figure below. In this case, Host-A is in a multi-homed network and has two IPv6 addresses, one delegated from each of the upstream ISPs. Note that ISP2 is a closed network and does not have connectivity to the Internet.
あなたがaに第2の典型的なソースアドレス選択問題を認めることができる、マルチ、家へ帰り、以下の図に示されるようなグローバルな半開きな接続性があるサイト。 この場合、Host-Aがaにある、マルチ、家へ帰り、2つのIPv6アドレス(それぞれの上流のISPから代表として派遣されたもの)をネットワークでつないで、持っています。 ISP2が閉じているネットワークであり、インターネットに接続性を持っていないことに注意してください。
+--------+
| Host-C | 2001:db8:a000::1
+-----+--+
|
============== +--------+
| Internet | | Host-B | 2001:db8:8000::1
============== +--------+
| |
2001:db8:1000:/36 | | 2001:db8:8000::/36
+----+-+ +-+---++
| ISP1 | | ISP2 | (Closed Network/VPN tunnel)
+----+-+ +-+----+
| |
2001:db8:1000:/48 | | 2001:db8:8000::/48
++-------++
| Router |
+----+----+
| 2001:db8:1000:1::/64
| 2001:db8:8000:1::/64
------+---+----------
|
+--+-----+ 2001:db8:1000:1::100
| Host-A | 2001:db8:8000:1::100
+--------+
+--------+ | Cを接待します。| 2001:db8:a000:、:1 +-----+--+ | ============== +--------+ | インターネット| | Bを接待します。| 2001:db8:8000:、:1 ============== +--------+ | | 2001:db8:1000: /36| | 2001:db8:8000:、:/36 +----+-+ +-+---++ | ISP1| | ISP2| (閉じているNetwork/VPNトンネル) +----+-+ +-+----+ | | 2001:db8:1000: /48| | 2001:db8:8000:、:/48 ++-------++ | ルータ| +----+----+ | 2001 : db8:1000:1:、:/64 | 2001 : db8:8000:1:、:/64 ------+---+---------- | +--+-----+2001: db8:1000:1:、:100 | Aを接待します。| 2001 : db8:8000:1:、:100 +--------+
Figure 3
図3
You do not need two physical network connections here. The connection from the Router to ISP2 can be a logical link over ISP1 and the Internet.
あなたはここで2つの物理ネットワーク接続を必要としません。 RouterからISP2までの接続はISP1とインターネットの上の論理的なリンクであるかもしれません。
When Host-A starts the connection to Host-B in ISP2, the source address of a packet that has been sent will be the one delegated from ISP2 (that is, 2001:db8:8000:1::100) because of rule 8 (longest matching prefix) in RFC 3484.
Host-AがISP2で接続をHost-Bに始めるとき、送られたパケットのソースアドレスはISP2から代表として派遣されたものになるでしょう。(それがそう、2001: db8: 8000:1 : : 100) RFC3484の規則8(最も長い合っている接頭語)のために。
Host-C is located somewhere on the Internet and has IPv6 address 2001:db8:a000::1. When Host-A sends a packet to Host-C, the longest matching algorithm chooses 2001:db8:8000:1::100 for the source
ホストCは、インターネットのどこかに位置していて、IPv6アドレス2001:db8:a000を持っています:、:1. Host-Aがアルゴリズムが2001を選ぶ最も長いマッチング: Host-C、db8にパケットを送るときの以下のこと、8000:1、:、:100 ソースに
Matsumoto, et al. Informational [Page 6] RFC 5220 Address Selection PS July 2008
松本、他 情報[6ページ]のRFC5220は、選択PS7月が2008であると扱います。
address. In this case, the packet goes through ISP1 and may be filtered by ISP1's ingress filter. Even if the packet is not filtered by ISP1, a return packet from Host-C cannot possibly be delivered to Host-A because the return packet is destined for 2001: db8:8000:1::100, which is closed from the Internet.
アドレス。 この場合、パケットは、ISP1を通って、ISP1のイングレスフィルタによってフィルターにかけられるかもしれません。 パケットがISP1によってフィルターにかけられないでも、リターンパケットが2001年のために運命づけられているので、Host-CからのリターンパケットをHost-Aに提供できません: db8:8000:1:、:100 インターネットから閉じられる。
The important point is that each host chooses a correct source address for a given destination address. To solve this kind of network-policy-based address selection problem, it is likely that delivering additional information to a node provides a better solution than using algorithms that are local to the node.
重要なポイントは各ホストが与えられた送付先アドレスのための正しいソースアドレスを選ぶということです。 この種類のネットワーク方針ベースのアドレス選択問題を解決するために、追加情報をノードに提供すると、ノードにローカルであることのアルゴリズムを使用するより良い解決法は提供されそうです。
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into Host-A's
RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、Host-AのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
2.1.4. Combined Use of Global and ULA
2.1.4. グローバルの結合した使用とULA
============
| Internet |
============
|
|
+----+----+
| ISP |
+----+----+
|
2001:db8:a::/48 |
+----+----+
| Router |
+-+-----+-+
| | 2001:db8:a:100::/64
fd01:2:3:200:/64 | | fd01:2:3:100:/64
-----+--+- -+--+----
| |
fd01:2:3:200::101 | | 2001:db8:a:100::100
+----+----+ +-+----+ fd01:2:3:100::100
| Printer | | Host |
+---------+ +------+
============ | インターネット| ============ | | +----+----+ | ISP| +----+----+ | 2001:db8:a:、:/48 | +----+----+ | ルータ| +-+-----+-+ | | 2001: db8: 1:100:、:/64fd01:2:3:200:/64| | fd01:2:3:100:/64-----+--+- -+--+---- | | fd01: 2:3:200:、:101 | | 2001: db8: 1:100:、:100 +----+----+ +-+----+ fd01: 2:3:100:、:100 | プリンタ| | ホスト| +---------+ +------+
Figure 4
図4
As RFC 4864 [RFC4864] describes, using a ULA may be beneficial in some scenarios. If the ULA is used for internal communication, packets with the ULA need to be filtered at the Router.
RFC4864[RFC4864]が説明するように、ULAを使用するのはいくつかのシナリオで有益であるかもしれません。 ULAが内部のコミュニケーションに使用されるなら、ULAがあるパケットは、Routerでフィルターにかけられる必要があります。
Matsumoto, et al. Informational [Page 7] RFC 5220 Address Selection PS July 2008
松本、他 情報[7ページ]のRFC5220は、選択PS7月が2008であると扱います。
This case does not presently create an address selection problem because of the dissimilarity between the ULA and the global unicast address. The longest matching rule of RFC 3484 chooses the correct address for both intra-site and extra-site communication.
本件は現在、相違点でULAとグローバルなユニキャストアドレスの間にアドレス選択問題を生じさせません。 RFC3484の最も長い合っている規則はイントラサイトと付加的なサイトコミュニケーションの両方のための正しいアドレスを選びます。
In the future, however, there is a possibility that the longest matching rule will not be able to choose the correct address anymore. That is the moment when the assignment of those global unicast addresses starts, where the first bit is 1. In RFC 4291 [RFC4291], almost all address spaces of IPv6, including those whose first bit is 1, are assigned as global unicast addresses.
しかしながら、将来、最も長い合っている規則がそれ以上正しいアドレスを選ぶことができない可能性があります。 それらのグローバルなユニキャストアドレスの課題(最初のビットは1である)が始まるとき、それは瞬間です。 RFC4291[RFC4291]では、最初のビットが1であるものを含むIPv6のほとんどすべてのアドレス空間がグローバルなユニキャストアドレスとして割り当てられます。
Namely, when we start to assign a part of the address block 8000::/1 as the global unicast address and that part is used somewhere in the Internet, the longest matching rule ceases to function properly for the people trying to connect to the servers with those addresses.
私たちがすなわち、あて先ブロック8000の案配a部分に以下を始めると:グローバルなユニキャストアドレスとそれが離れているとき、/1はインターネットでは、最も長い合っている規則がそれらのアドレスでサーバに接続しようとする人々のために変調を来すところで使用されます。
For example, when the destination host has an IPv6 address 8000::1, and the originating host has 2001:db8:a:100::100 and fd01:2:3:100::100, the source address will be fd01:2:3:100::100, because the longest matching bit length is 0 for 2001:db8:a:100::100 and 1 for fd01:2:3:100::100, respectively.
例えば、あて先ホストがIPv6を持っているときには、8000を扱ってください:、:1、送信元ホストには: db8: : 100あたり2001がある、:、:fd01: 100と2:3:100:、:100 ソースアドレスは: fd01: 2:3が100であったならそうするでしょう:、:100 最も長いマッチングに噛み付いたので、長さは: db8: : 100あたりの2001年の0です:、:fd01: 2:3:100の間の100と1:、:100 それぞれ。
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into the
Host's RFC 3484 policy table can solve this problem. Another
solution is to modify RFC 3484 and define ULA's scope smaller than
the global scope.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、HostのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。 他の解決法は、グローバルな範囲より小さくRFC3484を変更して、ULAの範囲を定義することです。
2.1.5. Site Renumbering
2.1.5. サイトの番号を付け替えること
RFC 4192 [RFC4192] describes a recommended procedure for renumbering a network from one prefix to another. An autoconfigured address has a lifetime, so by stopping advertisement of the old prefix, the autoconfigured address is eventually invalidated.
RFC4192[RFC4192]はネットワークに1つの接頭語から別の接頭語まで番号を付け替えさせるためのお勧めの手順について説明します。 自動構成されたアドレスには寿命があるので、古い接頭語の広告を止めることによって、自動構成されたアドレスが結局、無効にされます。
However, invalidating the old prefix takes a long time. You cannot stop routing to the old prefix as long as the old prefix is not removed from the host. This can be a tough issue for ISP network administrators.
しかしながら、古い接頭語を無効にするのは長くかかっています。 あなたは、古い接頭語がホストから取り除かれない限り、古い接頭語に掘るのを止めることができません。 これはISPネットワーク管理者のための難しい問題であるかもしれません。
There is a technique of advertising the prefix with the preferred lifetime zero; however, RFC 4862 [RFC4862], Section 5.5.4, does not absolutely prohibit the use of a deprecated address for a new outgoing connection due to limitations on the capabilities of applications.
都合のよい生涯ゼロで接頭語の広告を出すテクニックがあります。 しかしながら、RFC4862[RFC4862](セクション5.5.4)はアプリケーションの能力で推奨しないアドレスの制限による新しい外向的な接続の使用を絶対に禁止しません。
Matsumoto, et al. Informational [Page 8] RFC 5220 Address Selection PS July 2008
松本、他 情報[8ページ]のRFC5220は、選択PS7月が2008であると扱います。
+-----+---+
| Router |
+----+----+
| 2001:db8:b::/64 (new)
| 2001:db8:a::/64 (old)
------+---+----------
|
+--+---+ 2001:db8:b::100 (new)
| Host | 2001:db8:a::100 (old)
+------+
+-----+---+ | ルータ| +----+----+ | 2001:db8:b:、:/64(新しい)| 2001:db8:a:、:/64(古い)------+---+---------- | +--+---+ 2001:db8:b:、:100(新しい)| ホスト| 2001:db8:a:、:100 (古い)+------+
Figure 5
図5
Solution analysis:
This problem can be mitigated in the RFC 3484 framework. For
example, configuring some address selection policies into the
Host's RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を緩和できます。 例えば、HostのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
2.1.6. Multicast Source Address Selection
2.1.6. マルチキャストソースアドレス選択
This case is an example of site-local or global unicast prioritization. When you send a multicast packet across site borders, the source address of the multicast packet should be a globally routable address. The longest matching algorithm, however, selects a ULA if the sending host has both a ULA and a Global Unicast Address.
本件はサイト地方の、または、グローバルなユニキャスト優先順位づけに関する例です。 あなたがサイト境界の向こう側にマルチキャストパケットを送るとき、マルチキャストパケットのソースアドレスはグローバルに発送可能なアドレスであるべきです。 しかしながら、送付ホストにULAとGlobal Unicast Addressの両方があるなら、最も長い合っているアルゴリズムはULAを選択します。
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into the
sending host's RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、送付ホストのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
2.1.7. Temporary Address Selection
2.1.7. 仮の住所選択
RFC 3041 [RFC3041] defines a Temporary Address. The usage of a Temporary Address has both pros and cons. It is good for viewing web pages or communicating with the general public, but it is bad for a service that uses address-based authentication and for logging purposes.
RFC3041[RFC3041]はTemporary Addressを定義します。 Temporary Addressの使用法には、プロとまやかしの両方があります。 ウェブページを見るか、または一般とコミュニケートするのに良いのですが、それはアドレスベースの認証を使用するサービスと伐採目的のために悪いです。
If you could turn the temporary address on and off, that would be better. If you could switch its usage per service (destination address), that would also be better. The same situation can be found when using an HA (home address) and a CoA (care-of address) in a Mobile IPv6 [RFC3775] network.
あなたが断続的に仮の住所をターンできるなら、それは、より良いでしょうに。 また、あなたがサービス(送付先アドレス)あたりの用法を切り換えることができるなら、それも、より良いでしょうに。 HA(ホームアドレス)とCoAを使用するとき、同じ状況を見つけることができる、(注意、-、アドレス) モバイルIPv6[RFC3775]ネットワークで。
Matsumoto, et al. Informational [Page 9] RFC 5220 Address Selection PS July 2008
松本、他 情報[9ページ]のRFC5220は、選択PS7月が2008であると扱います。
Section 6 ("Future Work") of RFC 3041 discusses that an API extension
might be necessary to achieve a better address selection mechanism
with finer granularity.
API拡大が必要であるかもしれないRFC3041の(「今後の活動」)が議論するセクション6は、よりすばらしい粒状で、より良いアドレス選択メカニズムを達成します。
Solution analysis:
This problem cannot be solved in the RFC 3484 framework. A
possible solution is to make applications to select desirable
addresses by using the IPv6 Socket API for Source Address
Selection defined in RFC 5014 [RFC5014].
ソリューション分析: RFC3484フレームワークでこの問題を解決できません。 可能なソリューションは選択するアプリケーションをSource Address SelectionにIPv6 Socket APIを使用するのによるアドレスがRFC5014で[RFC5014]を定義したのが望ましくすることです。
2.2. Destination Address Selection
2.2. 目的地アドレス選択
2.2.1. IPv4 or IPv6 Prioritization
2.2.1. IPv4かIPv6優先順位づけ
The default policy table gives IPv6 addresses higher precedence than IPv4 addresses. There seem to be many cases, however, where network administrators want to control the address selection policy of end hosts so that it is the other way around.
デフォルト方針テーブルはIPv4アドレスより高い優先権をIPv6アドレスに与えます。 しかしながら、ネットワーク管理者が終わりのホストのアドレス選択方針を制御したがっているところで多くのケースがあるように思えるので、それは逆です。
Matsumoto, et al. Informational [Page 10] RFC 5220 Address Selection PS July 2008
松本、他 情報[10ページ]のRFC5220は、選択PS7月が2008であると扱います。
+---------+
| Tunnel |
| Service |
+--+---++-+
| ||
| ||
===========||==
| Internet || |
===========||==
| ||
192.0.2.0/24 | ||
+----+-+ ||
| ISP | ||
+----+-+ ||
| ||
IPv4 (Native) | || IPv6 (Tunnel)
192.0.2.0/26 | ||
++-----++-+
| Router |
+----+----+
| 2001:db8:a:1::/64
| 192.0.2.0/28
|
------+---+----------
|
+-+----+ 2001:db8:a:1::100
| Host | 192.0.2.2
+------+
+---------+ | トンネル| | サービス| +--+---++-+ | || | || ===========||== | インターネット|| | ===========||== | || 192.0.2.0/24 | || +----+-+ || | ISP| || +----+-+ || | || IPv4(ネイティブの)| || IPv6(トンネル)192.0.2.0/、26| || ++-----++-+ | ルータ| +----+----+ | 2001: db8: 1:1:、:/64 | 192.0.2.0/28 | ------+---+---------- | +-+----+ : db8: : 1あたり2001:、:100 | ホスト| 192.0.2.2 +------+
Figure 6
図6
In the figure above, a site has native IPv4 and tunneled IPv6 connectivity. Therefore, the administrator may want to set a higher priority for using IPv4 than for using IPv6 because the quality of the tunnel network seems to be worse than that of the native transport.
図では、上では、サイトがネイティブのIPv4とトンネルを堀られたIPv6の接続性を持っています。 したがって、管理者はトンネルネットワークの品質がネイティブの輸送のものより悪いように思えるのでIPv6を使用するのでIPv4を使用するのにさらに高い優先度を設定したがっているかもしれません。
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into the
Host's RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、HostのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
2.2.2. ULA and IPv4 Dual-Stack Environment
2.2.2. ULAとIPv4デュアルスタック環境
This is a special form of IPv4 and IPv6 prioritization. When an enterprise has IPv4 Internet connectivity but does not yet have IPv6 Internet connectivity, and the enterprise wants to provide site-local IPv6 connectivity, a ULA is the best choice for site-local IPv6
これは、特別なフォームのIPv4とIPv6優先順位づけです。 企業には、IPv4インターネットの接続性を持っていますが、IPv6インターネットの接続性はまだなくて、企業がサイトローカルのIPv6の接続性を提供したがっているとき、ULAはサイト地方のIPv6に、最も良い選択です。
Matsumoto, et al. Informational [Page 11] RFC 5220 Address Selection PS July 2008
松本、他 情報[11ページ]のRFC5220は、選択PS7月が2008であると扱います。
connectivity. Each employee host will have both an IPv4 global or private address and a ULA. Here, when this host tries to connect to Host-B that has registered both A and AAAA records in the DNS, the host will choose AAAA as the destination address and the ULA for the source address. This will clearly result in a connection failure.
接続性。 それぞれの従業員のホストには、IPv4のグローバルであるか個人的なアドレスとULAの両方があるでしょう。 このホストがDNSのAとAAAA記録の両方を登録したHost-Bに接続しようとするとき、ここで、ホストは送付先アドレスとソースアドレスのためのULAとしてAAAAを選ぶでしょう。 これは明確に接続失敗をもたらすでしょう。
+--------+
| Host-B | AAAA = 2001:db8::80
+-----+--+ A = 192.0.2.1
|
============
| Internet |
============
| no IPv6 connectivity
+----+----+
| Router |
+----+----+
|
| fd01:2:3::/48 (ULA)
| 192.0.2.128/25
++--------+
| Router |
+----+----+
| fd01:2:3:4::/64 (ULA)
| 192.0.2.240/28
------+---+----------
|
+-+------+ fd01:2:3:4::100 (ULA)
| Host-A | 192.0.2.245
+--------+
+--------+ | Bを接待します。| AAAA=2001: db8:、:80 +-----+--+A=192.0.2.1| ============ | インターネット| ============ | IPv6の接続性がありません+。----+----+ | ルータ| +----+----+ | | fd01:2:3:、:/48(ULA)| 192.0.2.128/25 ++--------+ | ルータ| +----+----+ | fd01: 2:3:4:、:/64(ULA)| 192.0.2.240/28 ------+---+---------- | +-+------+ fd01: 2:3:4:、:100 (ULA)| Aを接待します。| 192.0.2.245 +--------+
Figure 7
図7
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into Host-A's
RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、Host-AのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
2.2.3. ULA or Global Prioritization
2.2.3. ULAかグローバルな優先順位づけ
Differentiating services by the client's source address is very common. IP-address-based authentication is a typical example of this. Another typical example is a web service that has pages for the public and internal pages for employees or involved parties. Yet another example is DNS zone splitting.
クライアントのソースアドレスでサービスを差別化するのは非常に一般的です。 IPアドレスベースの認証はこの典型的な例です。 別の典型的な例は従業員か関係者のための公共の、そして、内部のページ単位でページがあるウェブサービスです。 さらに別の例はDNSゾーンの分かれることです。
Matsumoto, et al. Informational [Page 12] RFC 5220 Address Selection PS July 2008
松本、他 情報[12ページ]のRFC5220は、選択PS7月が2008であると扱います。
However, a ULA and an IPv6 global address both have global scope, and RFC 3484 default rules do not specify which address should be given priority. This point makes IPv6 implementation of address-based service differentiation a bit harder.
しかしながら、ULAとIPv6グローバルアドレスには、グローバルな範囲があります、そして、3484の省略時の解釈がするRFCはどのアドレスが優先するべきであるかを指定しません。 このポイントで、アドレスベースのサービス分化のIPv6実装は少し困難になります。
+--------+
| Host-B |
+-+--|---+
| |
===========|==
| Internet | |
===========|==
| |
| |
+----+-+ +-->+------+
| ISP +------+ DNS | 2001:db8:a::80
+----+-+ +-->+------+ fc12:3456:789a::80
| |
2001:db8:a::/48 | |
fc12:3456:789a::/48 | |
+----+----|+
| Router ||
+---+-----|+
| | 2001:db8:a:100::/64
| | fc12:3456:789a:100::/64
--+-+---|-----
| |
+-+---|--+ 2001:db8:a:100::100
| Host-A | fc12:3456:789a:100::100
+--------+
+--------+ | Bを接待します。| +-+--|---+ | | ===========|== | インターネット| | ===========|== | | | | +----+++-->+------+ | ISP+------+ DNS| 2001:db8:a:、:80 +----+++-->+------+fc12:3456:789a:、:80 | | 2001:db8:a:、:/48 | | fc12:3456:789a:、:/48 | | +----+----|+ | ルータ|| +---+-----|+ | | 2001: db8: 1:100:、:/64 | | fc12:3456:789a: 100:、:/64 --+-+---|----- | | +-+---|--+ : db8: : 100あたり2001:、:100 | Aを接待します。| fc12:3456:789a: 100:、:100 +--------+
Figure 8
エイト環
Solution analysis:
This problem can be solved in the RFC 3484 framework. For
example, configuring some address selection policies into Host-A's
RFC 3484 policy table can solve this problem.
ソリューション分析: RFC3484フレームワークでこの問題を解決できます。 例えば、Host-AのRFC3484方針テーブルにいくつかのアドレス選択方針を構成すると、この問題を解決できます。
3. Conclusion
3. 結論
We have covered problems related to destination or source address selection. These problems have their roots in the situation where end hosts have multiple IP addresses. In this situation, every end host must choose an appropriate destination and source address; this choice cannot be achieved only by routers.
私たちは目的地に関連する問題かソースアドレス選択をカバーしました。 これらの問題は終わりのホストが複数のIPアドレスを持っている状況でそれらのルーツを持っています。 この状況で、すべての終わりのホストが適切な目的地とソースアドレスを選ばなければなりません。 ルータだけはこの選択を達成できません。
Matsumoto, et al. Informational [Page 13] RFC 5220 Address Selection PS July 2008
松本、他 情報[13ページ]のRFC5220は、選択PS7月が2008であると扱います。
It should be noted that end hosts must be informed about routing policies of their upstream networks for appropriate address selection. A site administrator must consider every possible address false-selection problem and take countermeasures beforehand.
終わりのホストは適切なアドレス選択のためのそれらの上流のネットワークのルーティング方針に関して知識があるに違いないことに注意されるべきです。 サイトの管理者は、あらゆる可能なアドレス誤った選択問題を考えて、あらかじめ、対抗策を取らなければなりません。
4. Security Considerations
4. セキュリティ問題
When an intermediate router performs policy routing (e.g., source- address-based routing), inappropriate address selection causes unexpected routing. For example, in the network described in Section 2.1.3, when Host-A uses a default address selection policy and chooses an inappropriate address, a packet sent to a VPN can be delivered to a location via the Internet. This issue can lead to packet eavesdropping or session hijack. However, sending the packet back to the correct path from the attacker to the node is not easy, so these two risks are not serious.
中間的ルータが方針ルーティング(例えば、ソースアドレスベースのルーティング)を実行するとき、不適当なアドレス選択は予期していなかったルーティングを引き起こします。 例えば、Host-Aがデフォルトアドレス選択方針を使用して、不適当なアドレスを選ぶときセクション2.1.3で説明されたネットワークでは、インターネットを通してVPNに送られたパケットは位置に提供できます。 この問題はパケット盗聴かセッションハイジャックに導くことができます。 しかしながら、攻撃者からノードまで正しい経路にパケットを送り返すのが簡単でないので、これらの2つのリスクは重大ではありません。
As documented in the Security Considerations section of RFC 3484, address selection algorithms expose a potential privacy concern. When a malicious host can make a target host perform address selection (for example, by sending an anycast or multicast packet), the malicious host can get knowledge of multiple addresses attached to the target host. In a case like Section 2.1.4, if an attacker can make the Host to send a multicast packet and the Host performs the default address selection algorithm, the attacker may be able to determine the ULAs attached to the host.
RFC3484のSecurity Considerations部で記録されるように、アドレス選択アルゴリズムは、潜在的プライバシーが関心であると暴露します。 悪意があるホストが目標ホストにアドレス選択(例えばanycastかマルチキャストパケットを送ることによって)を実行させることができるなら、悪意があるホストは複数のアドレスに関する知識を目標ホストに愛着させることができます。 セクション2.1.4のような場合では、攻撃者がマルチキャストパケットを送るためにHostを作ることができて、Hostがデフォルトアドレス選択アルゴリズムを実行するなら、攻撃者はホストに愛着しているULAsを決定できるかもしれません。
These security risks have roots in inappropriate address selection. Therefore, if a countermeasure is taken, and hosts always select an appropriate address that is suitable to a site's network structure and routing, these risks can be avoided.
これらのセキュリティリスクは不適当なアドレス選択でルーツを持っています。 したがって、対策を取って、ホストがいつもサイトのネットワーク構造とルーティングに適した適切なアドレスを選択するなら、これらの危険を避けることができます。
5. Normative References
5. 引用規格
[RFC3041] Narten, T. and R. Draves, "Privacy Extensions for
Stateless Address Autoconfiguration in IPv6", RFC 3041,
January 2001.
[RFC3041] NartenとT.とR.Draves、「IPv6"での状態がないアドレス自動構成のためのプライバシー拡大、RFC3041、2001年1月。」
[RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003.
[RFC3484]Draves、R.、「インターネットプロトコルバージョン6(IPv6)のためのデフォルトAddress Selection」、RFC3484、2003年2月。
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC3775] ジョンソンとD.とパーキンス、C.とJ.Arkko、「IPv6"、RFC3775、2004年6月の移動性サポート。」
[RFC4192] Baker, F., Lear, E., and R. Droms, "Procedures for
Renumbering an IPv6 Network without a Flag Day", RFC 4192,
September 2005.
[RFC4192] ベイカー、F.、リア、E.、およびR.Droms、「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」、RFC4192(2005年9月)。
Matsumoto, et al. Informational [Page 14] RFC 5220 Address Selection PS July 2008
松本、他 情報[14ページ]のRFC5220は、選択PS7月が2008であると扱います。
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, October 2005.
[RFC4193] HindenとR.とB.ハーバーマン、「ユニークなローカルのIPv6ユニキャストアドレス」、RFC4193、2005年10月。
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006.
[RFC4291] HindenとR.とS.デアリング、「IPバージョン6アドレッシング体系」、RFC4291、2006年2月。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007.
[RFC4862] トムソンとS.とNarten、T.とT.Jinmei、「IPv6の状態がないアドレス自動構成」、RFC4862、2007年9月。
[RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and
E. Klein, "Local Network Protection for IPv6", RFC 4864,
May 2007.
[RFC4864] バン・デ・ベルデとG.とハインとT.とDromsとR.とCarpenter、B.とE.クライン、「IPv6"、RFC4864、2007年5月のための企業内情報通信網保護。」
[RFC5014] Nordmark, E., Chakrabarti, S., and J. Laganier, "IPv6
Socket API for Source Address Selection", RFC 5014,
September 2007.
[RFC5014] Nordmark、E.、Chakrabarti、S.、およびJ.Laganier、「ソースアドレス選択のためのIPv6ソケットAPI」、RFC5014、2007年9月。
Matsumoto, et al. Informational [Page 15] RFC 5220 Address Selection PS July 2008
松本、他 情報[15ページ]のRFC5220は、選択PS7月が2008であると扱います。
Authors' Addresses
作者のアドレス
Arifumi Matsumoto NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
pfの研究室の美土里町の3 9-11テロのArifumi松本NTT武蔵野市、日本東京180-8585
Phone: +81 422 59 3334 EMail: arifumi@nttv6.net
以下に電話をしてください。 +81 422 59 3334はメールされます: arifumi@nttv6.net
Tomohiro Fujisaki NTT PF Lab Midori-Cho 3-9-11 Musashino-shi, Tokyo 180-8585 Japan
pfの研究室の美土里町の3 9-11テロの智宏藤崎NTT武蔵野市、日本東京180-8585
Phone: +81 422 59 7351 EMail: fujisaki@nttv6.net
以下に電話をしてください。 +81 422 59 7351はメールされます: fujisaki@nttv6.net
Ruri Hiromi Intec Netcore, Inc. Shinsuna 1-3-3 Koto-ku, Tokyo 136-0075 Japan
Ruri広見インテックNetcore Inc.Shinsuna1-3-3江東区、日本東京136-0075
Phone: +81 3 5665 5069 EMail: hiromi@inetcore.com
以下に電話をしてください。 +81 3 5665 5069はメールされます: hiromi@inetcore.com
Ken-ichi Kanayama INTEC Systems Institute, Inc. Shimoshin-machi 5-33 Toyama-shi, Toyama 930-0804 Japan
健一KanayamaインテックSystemsはInc.Shimoshin-machi5-33富山市、日本富山930-0804を設けます。
Phone: +81 76 444 8088 EMail: kanayama_kenichi@intec-si.co.jp
以下に電話をしてください。 +81 76 444 8088はメールされます: kanayama_kenichi@intec-si.co.jp
Matsumoto, et al. Informational [Page 16] RFC 5220 Address Selection PS July 2008
松本、他 情報[16ページ]のRFC5220は、選択PS7月が2008であると扱います。
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2008).
IETFが信じる著作権(C)(2008)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Matsumoto, et al. Informational [Page 17]
松本、他 情報[17ページ]
一覧
スポンサーリンク
