RFC4076 日本語訳
4076 Renumbering Requirements for Stateless Dynamic Host ConfigurationProtocol for IPv6 (DHCPv6). T. Chown, S. Venaas, A. Vijayabhaskar. May 2005. (Format: TXT=15745 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group T. Chown
Request for Comments: 4076 University of Southampton
Category: Informational S. Venaas
UNINETT
A. Vijayabhaskar
Cisco Systems (India) Private Limited
May 2005
Chownがコメントのために要求するワーキンググループT.をネットワークでつないでください: 4076年のサウサンプトン大学カテゴリ: 株式会社2005年5月に個人的な情報のS.Venaas UNINETT A.Vijayabhaskarシスコシステムズ(インド)
Renumbering Requirements for Stateless
Dynamic Host Configuration Protocol for IPv6 (DHCPv6)
IPv6のために状態がないダイナミックなホスト構成プロトコルのための要件に番号を付け替えさせます。(DHCPv6)
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.
このメモはインターネットコミュニティのための情報を提供します。 それはどんな種類のインターネット標準も指定しません。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
Abstract
要約
IPv6 hosts using Stateless Address Autoconfiguration are able to configure their IPv6 address and default router settings automatically. However, further settings are not available. If these hosts wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) could be used. This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks. However, hosts using this combination currently have no means by which to be informed of changes in stateless DHCPv6 option settings; e.g., the addition of a new NTP server address, a change in DNS search paths, or full site renumbering. This document is presented as a problem statement from which a solution should be proposed in a subsequent document.
Stateless Address Autoconfigurationを使用しているIPv6ホストは自動的に彼らのIPv6アドレスとデフォルトルータ設定を構成できます。 しかしながら、さらなる設定は利用可能ではありません。 これらのホストが自動的に彼らのDNS、NTP、または他の特定の設定を構成したいと思うなら、IPv6(DHCPv6)のためのDynamic Host Configuration Protocolの状態がない異形は使用されるかもしれません。 IPv6ネットワークにStateless Address Autoconfigurationと状態がないDHCPv6のこの組み合わせを全く一般的に使用できました。 しかしながら、現在この組み合わせを使用しているホストが状態がないDHCPv6オプション設定の変化について知らされる手段を全く持っていません。 例えば、新しいNTPサーバアドレス、DNS検索経路の変化、または完全なサイトの番号を付け替えることの追加。 このドキュメントはソリューションがその後のドキュメントで提案されるべきである問題声明として提示されます。
Chown, et al. Informational [Page 1] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[1ページ]のRFC4076の番号を付け替えること
Table of Contents
目次
1. Introduction ...................................................2
2. Problem Statement ..............................................3
3. Renumbering Scenarios ..........................................3
3.1. Site Renumbering .........................................4
3.2. Changes to a DHCPv6-assigned Setting .....................4
4. Renumbering Requirements .......................................4
5. Considerations in Choosing a Solution ..........................4
6. Solution Space .................................................5
7. Summary ........................................................5
8. Security Considerations ........................................6
9. Acknowledgements ...............................................6
10. References .....................................................6
10.1. Normative References .....................................6
10.2. Informative References ...................................6
1. 序論…2 2. 問題声明…3 3. シナリオに番号を付け替えさせます…3 3.1. サイトの番号を付け替えること…4 3.2. DHCPv6によって割り当てられた設定への変化…4 4. 要件に番号を付け替えさせます…4 5. ソリューションを選ぶことにおける問題…4 6. ソリューションスペース…5 7. 概要…5 8. セキュリティ問題…6 9. 承認…6 10. 参照…6 10.1. 標準の参照…6 10.2. 有益な参照…6
1. Introduction
1. 序論
IPv6 hosts using Stateless Address Autoconfiguration [2] are able to configure their IPv6 address and default router settings automatically. Although Stateless Address Autoconfiguration for IPv6 allows automatic configuration of these settings, it does not provide a mechanism for additional non IP-address settings to be configured automatically.
Stateless Address Autoconfiguration[2]を使用しているIPv6ホストは自動的に彼らのIPv6アドレスとデフォルトルータ設定を構成できます。 IPv6のためのStateless Address Autoconfigurationはこれらの設定の自動構成を許しますが、それは、追加非IPのアドレス設定が自動的に構成されるためにメカニズムを提供しません。
The full version of the Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [3] is designed to provide both stateful address assignment to IPv6 hosts, as well as additional (non IP-address) configuration including DNS, NTP, and other specific settings. A full stateful DHCPv6 server allocates the addresses and maintains the clients' bindings to keep track of client leases.
IPv6(DHCPv6)[3]のためのDynamic Host Configuration Protocolの完全版は、IPv6ホストへのstatefulアドレス課題と追加している(非IPのアドレス)構成の含めの両方にDNS、NTP、および他の特定の設定を提供するように設計されています。 完全なstateful DHCPv6サーバは、クライアントリースの動向をおさえるためにアドレスを割り当てて、クライアントの結合を維持します。
If hosts using Stateless Address Autoconfiguration for IPv6 wish to configure their DNS, NTP, or other specific settings automatically, the stateless variant [4] of DHCPv6 could be used. This variant is more lightweight. It does not do address assignment; instead, it only provides additional configuration parameters, such as DNS resolver addresses. It does not maintain dynamic state about the information assigned to clients, and therefore there is no need to maintain dynamic per-client state on the server.
IPv6にStateless Address Autoconfigurationを使用しているホストが自動的に彼らのDNS、NTP、または他の特定の設定を構成したいと思うなら、DHCPv6の状態がない異形[4]は使用されるかもしれません。 この異形は、より軽量です。 それはアドレス課題をしません。 代わりに、それはDNSレゾルバアドレスなどの追加設定パラメータを提供するだけです。 それはクライアントに割り当てられた情報に関して動態を維持しません、そして、したがって、サーバでダイナミックな属国を維持する必要は全くありません。
This combination of Stateless Address Autoconfiguration and stateless DHCPv6 could be used quite commonly in IPv6 networks.
IPv6ネットワークにStateless Address Autoconfigurationと状態がないDHCPv6のこの組み合わせを全く一般的に使用できました。
Chown, et al. Informational [Page 2] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[2ページ]のRFC4076の番号を付け替えること
2. Problem Statement
2. 問題声明
A problem, however, lies in the ability, or lack of ability, of clients using this combination to be informed of (or to deduce) changes in DHCPv6-assigned settings.
問題、しかしながら、知らされるこの組み合わせを使用している(推論するために)クライアント能力における偽り、または能力の不足がDHCPv6によって割り当てられた設定で変化します。
While a DHCPv6 server unicasts Reconfigure messages to individual clients to trigger them to initiate Information-request/reply configuration exchanges to update their configuration settings, the stateless variant of DHCPv6 cannot use the Reconfigure mechanism because it does not maintain a list of IP addresses (leases) to send the unicast messages to. Note that in DHCPv6, Reconfigure messages must be unicast; multicast is not allowed.
個々のクライアントへのDHCPv6サーバユニキャストReconfigureメッセージである間、ユニキャストメッセージを送るIPアドレス(リース)のリストを維持しないので、それらの構成設定をアップデートするために開始情報要求/回答構成交換に彼らの引き金となるのに、DHCPv6の状態がない異形はReconfigureメカニズムを使用できません。 ReconfigureメッセージがDHCPv6では、ユニキャストであるに違いないことに注意してください。 マルチキャストは許容されていません。
Thus, events including the following cannot be handled:
したがって、以下を含むイベントは扱うことができません:
o Full site renumbering
o 完全なサイトの番号を付け替えること
o DNS server change of address
o DNSサーバ住所の変更
o NTP server change of address
o NTPサーバ住所の変更
o A change in DNS search paths
o DNS検索経路の変化
It would be highly desirable that a host using the combination of Stateless Address Autoconfiguration and stateless DHCPv6 could handle a renumbering or reconfiguration event, whether planned or unplanned by the network administrator.
Stateless Address Autoconfigurationと状態がないDHCPv6の組み合わせを使用しているホストが番号を付け替えるか再構成イベントを扱うことができたのは、非常に望ましいでしょう、ネットワーク管理者で計画されているか、または無計画であることにかかわらず。
Note that the scope of the problem could extend beyond Stateless DHCPv6, since only IP address options have a lifetime; i.e., there is no mechanism even in the full DHCPv6 that "expires" old information or otherwise forces a client to recheck that new/updated information is available. However, with full DHCPv6, a node may learn of updates to non-address options when renewing its address lease.
IPアドレスオプションだけには寿命があるので、問題の範囲がStateless DHCPv6を超えて広がることができたことに注意してください。 すなわち、メカニズムが全く旧情報を「吐き出す」か、またはそうでなければクライアントが新しいかアップデートされた情報が利用可能であることをやむを得ず再確認する完全なDHCPv6にさえありません。 しかしながら、アドレスリースを更新するとき、完全なDHCPv6と共に、ノードは非アドレスオプションにアップデートを知るかもしれません。
3. Renumbering Scenarios
3. シナリオに番号を付け替えさせます。
There are two main scenarios for changes to DHCPv6-assigned settings that would require the client to initiate an Information-request/ reply exchange to update the configuration.
クライアントが構成をアップデートするために情報要求/回答交換を起こすのを必要とするDHCPv6によって割り当てられた設定への変化のための2つの主なシナリオがあります。
Chown, et al. Informational [Page 3] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[3ページ]のRFC4076の番号を付け替えること
3.1. Site Renumbering
3.1. サイトの番号を付け替えること
One of the fundamental principles of IPv6 is that sites receive their IPv6 address allocations from an ISP using provider-assigned (PA) address space. There is currently no provider-independent (PI) address space in IPv6. Therefore, a site changing its ISP must renumber its network. Any such site renumbering will require hosts to reconfigure both their own address and default router settings and their stateless DHCPv6-assigned settings.
IPv6の原理の1つはサイトがISPからプロバイダーで割り当てられた(PA)アドレス空間を使用することで彼らのIPv6アドレス配分を受けるということです。 どんなプロバイダーから独立している(PI)アドレス空間も現在、IPv6にありません。 したがって、ISPを変えるサイトはネットワークに番号を付け替えさせなければなりません。 どんなそのようなサイトの番号を付け替えるのが、ホストがそれら自身のアドレスとデフォルトルータ設定とそれらの状態がないDHCPv6によって割り当てられた設定の両方を再構成するのを必要とするでしょう。
3.2. Changes to a DHCPv6-assigned Setting
3.2. DHCPv6によって割り当てられた設定への変化
An administrator may need to change one or more stateless DHCPv6-assigned settings; e.g., an NTP server, DNS server, or the DNS search path. This may be required if a new, additional DNS server is brought online and is moved to a new network (prefix), or if an existing server is decommissioned or known to be unavailable.
管理者は、1つ以上の状態がないDHCPv6によって割り当てられた設定を変える必要があるかもしれません。 例えば、NTPサーバ、DNSサーバ、またはDNSが経路を捜します。 既存のサーバが新しくて、追加しているDNSサーバがオンラインでもたらされていて、新しいネットワーク(接頭語)に動かされるか、使用を中止されるか、または入手できないのを知られるなら、これが必要であるかもしれません。
4. Renumbering Requirements
4. 要件に番号を付け替えさせます。
Ideally, any of the above scenarios should be handled automatically by the hosts on the network. For this to be realised, a method is required whereby the hosts are informed that they should request new stateless DHCPv6-assigned setting information.
理想的に、上のシナリオのいずれもネットワークのホストによって自動的に扱われるべきです。 これがわかるように、ホストに彼らが新しい状態がないDHCPv6によって割り当てられた設定情報を要求するべきであると知らされるメソッドが必要です。
The solution to the problem may depend on whether the renumbering or configuration change is planned or unplanned, from the perspective of the network administrator. There is already work underway toward understanding the planned renumbering [5] scenario for IPv6 networks. However, there is currently no mechanism in stateless DHCPv6 for handling planned renumbering events.
問題への解決は番号を付け替えるか構成変更が計画されますかそれとも無計画であるかよるかもしれません、ネットワーク管理者の見解から。 既に、IPv6ネットワークのために計画された番号を付け替える[5]シナリオを理解しているに向かって進行中の仕事があります。 しかしながら、メカニズムが全く現在、イベントに番号を付け替えさせながら計画されていた取り扱いのための状態がないDHCPv6にありません。
5. Considerations in Choosing a Solution
5. ソリューションを選ぶことにおける問題
A number of considerations could be listed for a desirable solution:
望ましいソリューションのために多くの問題を記載できました:
o The solution should support planned renumbering; it is desirable
that it also supports unplanned renumbering.
o ソリューションは計画された番号を付け替えることをサポートするべきです。 また、無計画な番号を付け替えることをサポートするのは、望ましいです。
o Security is important. No new security concerns should be
introduced to Stateless DHCPv6 by the solution.
o セキュリティは重要です。 ソリューションはどんな新しい安全上の配慮もStateless DHCPv6に紹介するべきではありません。
o It must be possible to update options, even if the network is not
renumbered.
o ネットワークが番号を付け替えられないでも、オプションをアップデートするのは可能であるに違いありません。
o It is desirable to maintain the "stateless" property; i.e., no
per-client state should need to be kept in the server.
o 「状態がない」特性を維持するのは望ましいです。 すなわち、どんな属国も、サーバで保たれる必要があるべきではありません。
Chown, et al. Informational [Page 4] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[4ページ]のRFC4076の番号を付け替えること
6. Solution Space
6. ソリューションスペース
Solutions should be designed and presented in a separate document. An initial brief set of candidate solutions might include the following:
ソリューションは、別々のドキュメントに設計されていて、提示されるべきです。 初期の簡潔なセットの候補ソリューションは以下を含むかもしれません:
o Add a Reconfigure message mechanism that would work in the
stateless DHCPv6 environment. This could enable planned or
unplanned events, but may require a multicast mechanism in order
to be realised.
o 状態がないDHCPv6環境で動作するReconfigureメッセージメカニズムを加えてください。 これは、計画されたか無計画なイベントを可能にすることができましたが、わかるためにマルチキャストメカニズムを必要とするかもしれません。
o Convey a valid lifetime timer to clients for stateless DHCPv6-
assigned settings. This could primarily enable planned events,
but with a small time-out it could handle unplanned events to some
extent at the expense of the additional request traffic. The
selection of recommended lifetime values/ranges would be the
subject of future work.
o 状態がない設定が割り当てられたDHCPv6のために有効な生涯タイマをクライアントまで運んでください。 これは主として計画されたイベントを可能にするかもしれませんが、小さいタイムアウトで、それは追加要求トラフィックを犠牲にして無計画なイベントをある程度扱うかもしれません。 お勧めの生涯値/範囲の品揃えは今後の活動の対象でしょう。
o Use some form of Router Advertisement (RA) [1] as a hint to
request new stateless DHCPv6-assigned settings. Using only an
observed new RA prefix as a hint to re-request settings would not
handle changes that are purely to NTP, DNS, or other options.
Other possible means of detection of network (re)attachment could
also be used as cues (e.g., see Goals of Detecting Network
Attachment (DNA) in IPv6 [6]).
o ヒントとして何らかのフォームのRouter Advertisement(RA)[1]を使用して、新しい状態がないDHCPv6によって割り当てられた設定を要求してください。 設定を再要求するのにヒントとして観測された新しいRA接頭語だけを使用するのは純粋なNTP、DNS、または別の選択肢にはある変化を扱わないでしょう。 また、手がかりとしてネットワーク(re)付属の検出の他の可能な手段を使用できました。(例えば、IPv6[6])のDetecting Network Attachment(DNA)のGoalsを見てください。
o Change the semantics of the 'O' flag in RAs [2] so that toggling
its value may trigger an Information-request message.
o [2] 値を切り換えるのが情報要求メッセージの引き金となることができるように、RAsの'O'旗の意味論を変えてください。
There will also be conditions under which a client should send an Information-request, such as reconnection to a link. Recommendations for these cases are outside the scope of this document, but we expect ongoing work in the DNA WG (as scoped in Goals of Detecting Network Attachment (DNA) in IPv6 [6]) to yield recommendations.
また、クライアントがリンクへの再接続などの情報要求を送るべきである状態があるでしょう。 このドキュメントの範囲の外にこれらのケースのための推薦がありますが、私たちはDNA WGで進行中の仕事を予想します。(推薦をもたらすためにIPv6[6])でDetecting Network Attachment(DNA)のGoalsで見られるように。
7. Summary
7. 概要
This document presents a problem statement for how IPv6 hosts that use the combination of Stateless Address Autoconfiguration and stateless DHCPv6 may be informed of renumbering events or other changes to the settings that they originally learned through stateless DHCPv6. A short list of candidate solutions is presented, which the authors hope will be expanded upon in subsequent documents.
このドキュメントは、イベントか設定への他の変化に番号を付け替えさせるのについて彼らが元々状態がないDHCPv6を通して学んだとどうStateless Address Autoconfigurationと状態がないDHCPv6の組み合わせを使用するIPv6ホストを知らすことができるように問題声明を提示するか。 候補ソリューションの短いリスト(広げられます作者がその後のドキュメントで望んでいる)は提示されます。
Chown, et al. Informational [Page 5] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[5ページ]のRFC4076の番号を付け替えること
8. Security Considerations
8. セキュリティ問題
There are no security considerations in this problem statement per se. However, whatever mechanism is designed or chosen to address this problem should avoid introducing new security concerns for (stateless) DHCPv6.
この問題声明にはセキュリティ問題が全くそういうものとしてありません。 しかしながら、このその問題を訴えるために設計されているか、または選ばれているどんなメカニズムも、(状態がない)のDHCPv6のために新しい安全上の配慮を導入するのを避けるはずです。
The issues of maintaining appropriate security through a renumbering event are outside the scope of this document (if specific servers within the network are being added or removed, firewall configurations and ACLs, for example, will need to reflect this). However, this is an important area for further work.
このドキュメントの範囲の外に番号を付け替えるイベントを通して適切なセキュリティを維持する問題があります(ネットワークの中の特定のサーバを加えるか、または取り除いていると、例えば、ファイアウォール構成とACLsは、これを反映する必要があるでしょう)。 しかしながら、これはさらなる仕事のための重要な領域です。
9. Acknowledgements
9. 承認
The authors would like to thank Ralph Droms, Bernie Volz, and other individuals on the DHC mail list for their comments on this document, as well as colleagues on the 6NET project. We also thank the review comments, particularly those from Thomas Narten.
作者はこのドキュメントの彼らのコメントのためのDHCメール・リストでラルフDroms、バーニー・フォルツ、および他の個人に感謝したがっています、6NETプロジェクトの同僚と同様に。 また、私たちはトーマスNartenからのレビューコメント、特にそれらに感謝します。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[1] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.
[1]Narten、T.、Nordmark、E.、およびW.シンプソン、「IPバージョン6(IPv6)のための隣人発見」、RFC2461、1998年12月。
[2] Thomson, S. and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC 2462, December 1998.
[2] トムソンとS.とT.Narten、「IPv6の状態がないアドレス自動構成」、RFC2462、1998年12月。
[3] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M.
Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)",
RFC 3315, July 2003.
[3] Droms(R.)はバウンドしています、J.、フォルツ、B.、レモン、パーキンス、C.とM.カーニー、「IPv6(DHCPv6)のためのダイナミックなホスト構成プロトコル」RFC3315、T.、2003年7月。
[4] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP)
Service for IPv6", RFC 3736, April 2004.
[4]Droms、R.「(DHCP)がIPv6"、RFC3736年のために修理する状態がないダイナミックなホスト構成プロトコル、2004年4月」。
10.2. Informative References
10.2. 有益な参照
[5] Baker, F., Lear, E. and R. Droms, "Procedures for Renumbering an
IPv6 Network without a Flag Day", Work in Progress, July 2004.
[5] 「国旗制定記念日なしでIPv6ネットワークに番号を付け替えさせるための手順」というベイカー、F.、リア、E.、およびR.Dromsは進行中(2004年7月)で働いています。
[6] Choi, J., "Goals of Detecting Network Attachment (DNA) in IPv6",
Work in Progress, October 2004.
[6] チェ、J.、「検出の目標は2004年10月にIPv6"での付属(DNA)、処理中の作業をネットワークでつなぎます」。
Chown, et al. Informational [Page 6] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[6ページ]のRFC4076の番号を付け替えること
Authors' Addresses
作者のアドレス
Tim Chown University of Southampton School of Electronics and Computer Science Southampton, Hampshire SO17 1BJ United Kingdom
エレクトロニクスのティムChownサウサンプトン大学学校とコンピュータサイエンスサウサンプトン、ハンプシャーSO17 1BJイギリス
EMail: tjc@ecs.soton.ac.uk
メール: tjc@ecs.soton.ac.uk
Stig Venaas UNINETT Trondheim NO 7465 Norway
スティVenaas UNINETTトロンヘイムNO7465ノルウェー
EMail: venaas@uninett.no
メール: venaas@uninett.no
Vijayabhaskar A Kalusivalingam Cisco Systems (India) Private Limited 9, Brunton Road Bangalore 560025 India
VijayabhaskarのA Kalusivalingamのシスコシステムズ(インド)私設の株式会社9、Brunton道路Bangalore560025インド
EMail: vibhaska@cisco.com
メール: vibhaska@cisco.com
Chown, et al. Informational [Page 7] RFC 4076 Renumbering for Stateless DHCPv6 May 2005
Chown、他 状態がないDHCPv6 May 2005のための情報[7ページ]のRFC4076の番号を付け替えること
Full Copyright Statement
完全な著作権宣言文
Copyright (C) The Internet Society (2005).
Copyright(C)インターネット協会(2005)。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
Intellectual Property
知的所有権
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFはどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf- ipr@ietf.org.
IETFはこの規格を実装するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を扱ってください。
Acknowledgement
承認
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。
Chown, et al. Informational [Page 8]
Chown、他 情報[8ページ]
一覧
スポンサーリンク
