RFC4943 日本語訳
4943 IPv6 Neighbor Discovery On-Link Assumption Considered Harmful. S.Roy, A. Durand, J. Paugh. September 2007. (Format: TXT=16719 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group S. Roy
Request for Comments: 4943 Sun Microsystems, Inc.
Category: Informational A. Durand
Comcast
J. Paugh
Nominum, Inc.
September 2007
コメントを求めるワーキンググループS.ロイ要求をネットワークでつないでください: 4943年のサン・マイクロシステムズ・インクカテゴリ: 情報のA.ジュランドコムキャストJ.Paugh Nominum Inc.2007年9月
IPv6 Neighbor Discovery On-Link Assumption Considered Harmful
リンクにおける有害であると考えられたIPv6隣人発見仮定
Status of This Memo
このメモの状態
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Abstract
要約
This document describes the historical and background information behind the removal of the "on-link assumption" from the conceptual host sending algorithm defined in Neighbor Discovery for IP Version 6 (IPv6). According to the algorithm as originally described, when a host's default router list is empty, the host assumes that all destinations are on-link. This is particularly problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity (e.g., no default router). This document describes how making this assumption causes problems and how these problems outweigh the benefits of this part of the conceptual sending algorithm.
このドキュメントは「リンクにおける仮定」の取り外しの後ろでIPバージョン6(IPv6)のためにNeighborディスカバリーで定義された概念的なホスト送付アルゴリズムから歴史的、そして、バックグラウンド情報について説明します。 ホストのデフォルトルータリストが空であるときに、元々説明されているとしてのアルゴリズムによると、ホストは、すべての目的地がリンクであると仮定します。 これはオフリンクIPv6の接続性(例えば、デフォルトルータがない)を持っていないIPv6できるノードで特に問題が多いです。 このドキュメントは、この仮定をするのがどのように問題を起こすか、そして、これらの問題がどのように概念的な送付アルゴリズムのこの部分の利益より重いかを説明します。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Background on the On-link Assumption . . . . . . . . . . . . . 2
3. Problems . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3.1. First Rule of Destination Address Selection . . . . . . . . 3
3.2. Delays Associated with Address Resolution . . . . . . . . . 3
3.3. Multi-interface Ambiguity . . . . . . . . . . . . . . . . . 4
3.4. Security-Related Issues . . . . . . . . . . . . . . . . . . 4
4. Changes to RFC 2461 . . . . . . . . . . . . . . . . . . . . . . 5
5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
6. Normative References . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 リンクの上の前提. . . . . . . . . . . . . 2 3でのバックグラウンド。 問題. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3.1。 目的地アドレス選択. . . . . . . . 3 3.2の最初の規則。 アドレス解決. . . . . . . . . 3 3.3に関連している遅れ。 マルチインタフェースのあいまいさ. . . . . . . . . . . . . . . . . 4 3.4。 安全保障関連問題. . . . . . . . . . . . . . . . . . 4 4。 RFC2461.5 5への変化。 セキュリティ問題. . . . . . . . . . . . . . . . . . . . 5 6。 標準の参照. . . . . . . . . . . . . . . . . . . . . 6付録A.承認. . . . . . . . . . . . . . . . . . . 7
Roy, et al. Informational [Page 1] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[1ページ]のRFC4943仮定
1. Introduction
1. 序論
Neighbor Discovery for IPv6 [RFC4861] defines a conceptual sending algorithm for hosts. The version of the algorithm described in [RFC2461] states that if a host's default router list is empty, then the host assumes that all destinations are on-link. This memo documents the removal of this assumption in the updated Neighbor Discovery specification [RFC4861] and describes the reasons why this assumption was removed.
IPv6[RFC4861]のための隣人ディスカバリーはホストのために概念的な送付アルゴリズムを定義します。 [RFC2461]で説明されたアルゴリズムのバージョンは、ホストのデフォルトルータリストが空であるならホストが、すべての目的地がリンクであると仮定すると述べます。 このメモは、アップデートされたNeighborディスカバリー仕様[RFC4861]に基づく、この仮定の取り外しを記録して、この仮定が取り除かれた理由について説明します。
This assumption is problematic with IPv6-capable nodes that do not have off-link IPv6 connectivity. This is typical when systems that have IPv6 enabled on their network interfaces (either on by default or administratively configured that way) are attached to networks that have no IPv6 services such as off-link routing. Such systems will resolve DNS names to AAAA and A records, and they may attempt to connect to unreachable IPv6 off-link nodes.
この仮定はオフリンクIPv6の接続性を持っていないIPv6できるノードで問題が多いです。 それらのネットワーク・インターフェース(どちらかそのようにデフォルトでか行政上構成されているところの)でIPv6を有効にするシステムがオフリンクルーティングなどのIPv6サービスを全く持っていないネットワークに取り付けられるとき、これは典型的です。 そのようなシステムはAAAAとA記録にDNS名を決議するでしょう、そして、それらは手の届かないIPv6オフリンクノードに接続するのを試みるかもしれません。
The on-link assumption creates problems for destination address selection as defined in [RFC3484], and it adds connection delays associated with unnecessary address resolution and neighbor unreachability detection. The behavior associated with the assumption is undefined on multi-interface nodes and has some subtle security implications. All of these issues are discussed in this document.
リンクにおける仮定は目的地アドレス選択のために[RFC3484]で定義されるように問題を生じさせます、そして、それは不要なアドレス解決と隣人「非-可到達性」検出に関連している接続遅れを加えます。 仮定に関連している振舞いは、マルチインタフェースノードで未定義であり、いくつかの微妙なセキュリティ意味を持っています。 本書ではこれらの問題のすべてについて議論します。
2. Background on the On-link Assumption
2. リンクの上の前提でのバックグラウンド
This part of Neighbor Discovery's [RFC2461] conceptual sending algorithm was created to facilitate communication on a single link between systems configured with different global prefixes in the absence of an IPv6 router. For example, consider the case where two systems on separate links are manually configured with global addresses and are then plugged in back-to-back. They can still communicate with each other via their global addresses because they'll correctly assume that each is on-link.
Neighborディスカバリー[RFC2461]の概念的な送付アルゴリズムのこの部分は、IPv6ルータがないとき異なったグローバルな接頭語によって構成されたシステムの間の単一のリンクに関するコミュニケーションを容易にするために作成されました。 例えば、次に、別々のリンクの上の2台のシステムはグローバルなアドレスによって手動で構成されて、あるこの件が支持する後部のプラグを差し込んだと考えてください。 それぞれがリンクであると正しく仮定するので、彼らは自分達のグローバルなアドレスでまだ互いにコミュニケートできます。
Without the on-link assumption, the above scenario wouldn't work, and the systems would need to be configured to share a common prefix such as the link-local prefix. On the other hand, the on-link assumption introduces several problems to various parts of the networking stack described in Section 3. As such, this document points out that the problems introduced by the on-link assumption outweigh the benefit that the assumption lends to this scenario. It is more beneficial to the end user to remove the on-link assumption from Neighbor Discovery and declare this scenario illegitimate (or a misconfiguration).
リンクにおける仮定がなければ、上のシナリオは働いていないでしょう、そして、システムはリンクローカルの接頭語などの一般的な接頭語を共有するために構成される必要があるでしょう。 他方では、リンクにおける仮定はセクション3で説明されたネットワークスタックの様々な一部にいくつかの問題を紹介します。 そういうものとして、このドキュメントは、リンクにおける仮定で紹介された問題が仮定がこのシナリオに貸す利益より重いと指摘します。 エンドユーザには、Neighborディスカバリーからリンクにおける仮定を取り除いて、このシナリオが違法であると(または、misconfiguration)宣言するのは、より有益です。
Roy, et al. Informational [Page 2] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[2ページ]のRFC4943仮定
3. Problems
3. 問題
The on-link assumption causes the following problems.
リンクにおける仮定は以下の問題を引き起こします。
3.1. First Rule of Destination Address Selection
3.1. 目的地アドレス選択の最初の規則
Default Address Selection for IPv6 [RFC3484] defines a destination address selection algorithm that takes an unordered list of destination addresses as input and produces a sorted list of destination addresses as output. The algorithm consists of destination address sorting rules, the first of which is "Avoid unusable destinations". The idea behind this rule is to place unreachable destinations at the end of the sorted list so that applications will be least likely to try to communicate with those addresses first.
IPv6[RFC3484]のためのデフォルトAddress Selectionは入力されるように送付先アドレスの順不同のリストを取って、出力されるように送付先アドレスの分類されたリストを作り出す目的地アドレス選択アルゴリズムを定義します。 アルゴリズムは目的地アドレスソーティング規則から成ります。その1番目は「使用不可能な目的地を避けてください」です。 この規則の後ろの考えはアプリケーションが最初にそれらのアドレスで最も交信しようとしそうにないように分類されたリストの終わりに手の届かない目的地を置くことです。
The on-link assumption could potentially cause false positives when attempting unreachability determination for this rule. On a network where there is no IPv6 router (all off-link IPv6 destinations are unreachable), the on-link assumption states that destinations are assumed to be on-link. An implementation could interpret that as, if the default router list is empty, then all destinations are reachable on-link. This may cause the rule to prefer an unreachable IPv6 destination over a reachable IPv4 destination.
この規則のための「非-可到達性」決断を試みるとき、リンクにおける仮定は潜在的に無病誤診を引き起こす場合がありました。 IPv6ルータが全くない(すべてのオフリンクIPv6の目的地が手が届きません)ネットワークでは、リンクにおける仮定は、目的地がリンクであると思われると述べます。 実装は、次に、デフォルトルータリストが空であるなら、すべての目的地が届いているオンリンクであるので、それを解釈するかもしれません。 これで、規則は届いているIPv4の目的地より手の届かないIPv6の目的地を好むかもしれません。
3.2. Delays Associated with Address Resolution
3.2. アドレス解決に関連している遅れ
Users expect that applications quickly connect to a given destination regardless of the number of IP addresses assigned to that destination. If a destination name resolves to multiple addresses and the application attempts to communicate to each address until one succeeds, this process shouldn't take an unreasonable amount of time. It is therefore important that the system quickly determine if IPv6 destinations are unreachable so that the application can try other destinations when those IPv6 destinations are unreachable.
ユーザは、アプリケーションがその目的地に割り当てられたIPアドレスの数にかかわらずすぐに与えられた目的地に接続すると予想します。 目的地名が1つが成功するまで各アドレスに交信する試みを複数のアドレスとアプリケーションに決議するなら、このプロセスは無理な時かかるはずがありません。 したがって、システムが、それらのIPv6の目的地が手が届かないときに、アプリケーションが他の目的地を試みることができるくらいIPv6の目的地が手が届かないかどうかすぐに決定するのは、重要です。
For an IPv6-enabled host deployed on a network that has no IPv6 routers, the result of the on-link assumption is that link-layer address resolution must be performed on all IPv6 addresses to which the host sends packets. The application will not receive acknowledgment of the unreachability of destinations that are not on- link until at least address resolution has failed, which is no less than 3 seconds (MAX_MULTICAST_SOLICIT * RETRANS_TIMER). This is greatly amplified by transport protocol delays. For example, [RFC1122] Section 4.2.3.5 requires that TCP retransmit for at least 3 minutes before aborting the connection attempt.
IPv6ルータを全く持っていないネットワークで配布されたIPv6によって可能にされたホストにとって、リンクにおける仮定の結果はホストがパケットを送るすべてのIPv6アドレスにリンクレイヤアドレス解決を実行しなければならないということです。 アプリケーションはオンでない目的地では少なくともアドレス解決までのリンク(ノーである)が失敗したという3秒(マックス_MULTICAST_SOLICIT*RETRANS_TIMER)未満の「非-可到達性」の承認を受けないでしょう。 これはトランスポート・プロトコル遅れによって大いに増幅されます。 セクション4.2 例えば接続試みを中止する前にTCPが少なくとも3分間再送する.5が必要とする[RFC1122].3。
Roy, et al. Informational [Page 3] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[3ページ]のRFC4943仮定
When the application has a large list of off-link unreachable IPv6 addresses followed by at least one reachable IPv4 address, the delay associated with Neighbor Unreachability Detection (NUD) of each IPv6 address before successful communication with the IPv4 address is unacceptable.
少なくとも1つの届いているIPv4アドレスがアプリケーションでオフリンクの手の届かないIPv6アドレスの大きいリストのあとに続くとき、IPv4アドレスとのうまくいっているコミュニケーションの前のそれぞれのIPv6アドレスのNeighbor Unreachability Detection(NUD)に関連している遅れは容認できません。
3.3. Multi-interface Ambiguity
3.3. マルチインタフェースのあいまいさ
There is no defined way to implement this aspect of the sending algorithm on a node that is attached to multiple links. Specifically, a problem arises when a node is faced with sending a packet to an IPv6 destination address to which it has no route, and the sending node is attached to multiple links. With the on-link assumption, this node assumes that the destination is on-link, but on which link? From an implementor's point of view, there are three ways to handle sending an IPv6 packet to a destination in the face of the on-link assumption on a multi-interface node:
複数のリンクに添付されるノードの上で送付アルゴリズムのこの局面を実装する定義された方法が全くありません。 ノードはそれがルートを全く持っていないIPv6送付先アドレスにパケットを送るのに面していて、送付ノードが複数のリンクに添付されるとき、明確に、問題は起こります。 リンクの上に仮定がある状態で、目的地がリンクであると仮定しますが、どれがリンクされるかに関してこのノードはそうしますか? 作成者の観点から、ハンドルへのマルチインタフェースノードにおけるリンクにおける仮定に直面してIPv6パケットを目的地に送る3つの方法が来ています:
1. Attempt to send the packet on a single link (either
administratively pre-defined or using some algorithm).
1. 単一のリンクの上のパケットを送るのを試みてください(行政上事前に定義されるか、または何らかのアルゴリズムを使用して)。
2. Attempt to send the packet on every link.
2. あらゆるリンクの上のパケットを送るのを試みてください。
3. Drop the packet.
3. パケットを下げてください。
If the destination is indeed on-link, the first option might not succeed since the wrong link could be picked. The second option might succeed in reaching the destination but is more complex to implement and isn't guaranteed to pick the correct destination. For example, there could be more than one node configured with the same address, each reachable through a different link. The address by itself does not disambiguate which destination the sender actually wanted to reach, so attempting to send the packet to every link is not guaranteed to reach the anticipated destination. The third option, dropping the packet, is equivalent to not making the on-link assumption at all. In other words, if there is no route to the destination, don't attempt to send the packet. An implementation that behaves this way would require an administrator to configure routes to the destination in order to have reachability to the destination, thus eliminating the ambiguity.
目的地が本当にリンクであるなら、第1の選択は、間違ったリンクを選ぶことができたので、成功しないかもしれません。 2番目のオプションは、目的地に達するのに成功するかもしれませんが、実装するために、より複雑であり、正しい目的地を選ぶために保証されません。 例えば、同じアドレスで構成されて、異なったリンクを通してそれぞれ届いている1つ以上のノードがあるかもしれません。 それ自体でアドレスが送付者が実際に範囲に欲しかったどの目的地のあいまいさを除かないかので、あらゆるリンクにパケットを送るのを試みるのは予期された目的地に達するように保証されません。 パケットを下げて、3番目のオプションは全くリンクにおける仮定をしないのに同等です。 言い換えれば、目的地へのルートが全くなければ、パケットを送るのを試みないでください。 それがこのように振る舞わせる実装は、目的地に可到達性を持つために管理者がルートを目的地に構成するのを必要とするでしょう、その結果、あいまいさを排除します。
3.4. Security-Related Issues
3.4. 安全保障関連問題
The on-link assumption discussed here introduces a security vulnerability to the Neighbor Discovery protocol described in Section 4.2.2 of IPv6 Neighbor Discovery Trust Models and Threats [RFC3756] titled "Default router is 'killed'". There is a threat that a host's router can be maliciously killed in order to cause the host to start
リンクにおけるここで議論した仮定は「デフォルトルータは'殺される」と題をつけられたIPv6 NeighborディスカバリーTrust Modelsと.2セクション4.2Threats[RFC3756]で説明されたNeighborディスカバリープロトコルにセキュリティの脆弱性を紹介します。 そこでは、ホストのルータが陰湿にそうであることができる脅威が、ホストが始めることを引き起こすために殺されますか?
Roy, et al. Informational [Page 4] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[4ページ]のRFC4943仮定
sending all packets on-link. The attacker can then spoof off-link nodes by sending packets on the same link as the host. The vulnerability is discussed in detail in [RFC3756].
オンリンクをすべてのパケットに送ります。 そして、攻撃者は、オフリンクがノードであるとホストと同じリンクにパケットを送ることによって、偽造することができます。 [RFC3756]で詳細に脆弱性について議論します。
Another security-related side-effect of the on-link assumption has to do with virtual private networks (VPNs). It has been observed that some commercially available VPN software solutions that don't support IPv6 send IPv6 packets to the local media in the clear (their security policy doesn't simply drop IPv6 packets). Consider a scenario where a system has a single Ethernet interface with VPN software that encrypts and encapsulates certain packets. The system attempts to send a packet to an IPv6 destination that it obtained by doing a DNS lookup, and the packet ends up going in the clear to the local media. A malicious third party could then spoof the destination on-link.
リンクにおける仮定の別のセキュリティ関連の副作用は仮想私設網(VPNs)と関係があります。 IPv6をサポートしないいくつかの商業的に利用可能なVPNソフトウェアソリューションが明確の地元マスコミへのパケットをIPv6に送るのが(それらの安全保障政策はIPv6パケットを絶対に下げません)観測されました。 システムが、あるパケットを暗号化して、カプセルに入れるVPNソフトウェアとの単一のイーサネットインタフェースを持っているシナリオを考えてください。 システムは、それがDNSルックアップをすることによって得たIPv6の目的地にパケットを送るのを試みます、そして、パケットは結局、地元マスコミへの明確に入ります。 そして、悪意がある第三者は、目的地がオンリンクであると偽造することができました。
4. Changes to RFC 2461
4. RFC2461への変化
The following changes have been made to the Neighbor Discovery specification between [RFC2461] and [RFC4861]:
以下の変更を[RFC2461]と[RFC4861]の間のNeighborディスカバリー仕様にしました:
The last sentence of the second paragraph of Section 5.2
("Conceptual Sending Algorithm") was removed. This sentence was,
"If the Default Router List is empty, the sender assumes that the
destination is on-link."
セクション5.2(「概念的な送付アルゴリズム」)の第2パラグラフに関する最後の文は取り除かれました。 この文は「Default Router Listが空であるなら、送付者は、目的地がリンクであると仮定する」ということでした。
Bullet item 3) in Section 6.3.6 ("Default Router Selection") was
removed. The item read, "If the Default Router List is empty,
assume that all destinations are on-link as specified in Section
5.2."
弾丸の品目3) セクション6.3.6では、(「デフォルトルータ選択」)を取り除きました。 項目は、「Default Router Listが空であるなら、すべての目的地がセクション5.2で指定されるようにリンクであると仮定してください。」と読みました。
APPENDIX A was modified to remove on-link assumption related text
in bullet item 1) under the discussion on what happens when a
multihomed host fails to receive Router Advertisements.
APPENDIX Aは、弾丸の品目1)の議論している「マルチ-家へ帰」っているホストがRouter Advertisementsを受け取らないと何が起こるかに関する仮定が関係づけたオンリンクテキストを取り除くように変更されました。
The result of these changes is that destinations are considered unreachable when there is no routing information for that destination (through a default router or otherwise). Instead of attempting link- layer address resolution when sending to such a destination, a node should send an ICMPv6 Destination Unreachable message (code 0 - no route to destination) message up the stack.
これらの変化の結果はその目的地(デフォルトルータかそうでないことを通した)のためのルーティング情報が全くないとき、目的地が手が届かないと考えられるということです。 そのような目的地に発信するときリンク層のアドレス解決を試みることの代わりに、ノードはICMPv6 Destination Unreachableメッセージ(コード0--目的地へのルートがない)メッセージをスタックに送るはずです。
5. Security Considerations
5. セキュリティ問題
The removal of the on-link assumption from Neighbor Discovery addresses all of the security-related vulnerabilities of the protocol as described in Section 3.4.
Neighborディスカバリーからのリンクにおける仮定の取り外しはセクション3.4で説明されるようにプロトコルのセキュリティ関連の脆弱性のすべてを扱います。
Roy, et al. Informational [Page 5] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[5ページ]のRFC4943仮定
6. Normative References
6. 引用規格
[RFC1122] Braden, R., "Requirements for Internet Hosts -
Communication Layers", STD 3, RFC 1122, October 1989.
[RFC1122]ブレーデン、R.、「インターネットのためのホスト--コミュニケーションが層にされるという要件」、STD3、RFC1122、10月1989日
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor
Discovery for IP Version 6 (IPv6)", RFC 2461,
December 1998.
[RFC2461]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[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月。
[RFC3756] Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756,
May 2004.
[RFC3756] Nikander、P.、ケンフ、J.、およびE.Nordmark、「IPv6隣人発見(ノースダコタ)信頼モデルと脅威」(RFC3756)は2004がそうするかもしれません。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007.
[RFC4861] Narten、T.、Nordmark、E.、シンプソン、W.、およびH.ソリマン、「IPバージョン6のための隣人ディスカバリー(IPv6)」、RFC4861(2007年9月)。
Roy, et al. Informational [Page 6] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[6ページ]のRFC4943仮定
Appendix A. Acknowledgments
付録A.承認
The authors gratefully acknowledge the contributions of Jim Bound, Spencer Dawkins, Tony Hain, Mika Liljeberg, Erik Nordmark, Pekka Savola, and Ronald van der Pol.
作者は感謝してジムBound、スペンサー・ダウキンズ、トニー・ハイン、ミカLiljeberg、エリックNordmark、ペッカSavola、およびロナルドバンder Polの貢献を承諾します。
Authors' Addresses
作者のアドレス
Sebastien Roy Sun Microsystems, Inc. 1 Network Drive UBUR02-212 Burlington, MA 01803
セバスチアンロイサン・マイクロシステムズ・インク1ネットワークドライブUBUR02-212バーリントン、MA 01803
EMail: sebastien.roy@sun.com
メール: sebastien.roy@sun.com
Alain Durand Comcast 1500 Market Street Philadelphia, PA 19102
通りフィラデルフィア、アランジュランドコムキャスト1500市場PA 19102
EMail: alain_durand@cable.comcast.com
メール: alain_durand@cable.comcast.com
James Paugh Nominum, Inc. 2385 Bay Road Redwood City, CA 94063
Roadレッドウッドシティー、ジェームスPaugh Nominum Inc.2385Bayカリフォルニア 94063
EMail: jim.paugh@nominum.com
メール: jim.paugh@nominum.com
Roy, et al. Informational [Page 7] RFC 4943 On-Link Assumption Harmful September 2007
ロイ、他 リンクにおける2007年9月に有害な情報[7ページ]のRFC4943仮定
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれた情報はその人が代理をするか、または(もしあれば)後援される組織、インターネットの振興発展を目的とする組織、「そのままで」という基礎と貢献者の上で提供していて、IETFはそして、インターネット・エンジニアリング・タスク・フォースがすべての保証を放棄すると信じます、急行である、または暗示していて、他を含んでいて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるということであるかいずれが市場性か特定目的への適合性の黙示的な保証です。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf-ipr@ietf.org のIETFに情報を扱ってください。
Roy, et al. Informational [Page 8]
ロイ、他 情報[8ページ]
一覧
スポンサーリンク
