[要約] RFC 3736は、IPv6における状態を持たない動的ホスト構成プロトコル（DHCP）サービスに関する規格です。このRFCの目的は、IPv6ネットワークでのホストの自動設定とアドレス割り当てを効率的に行うための方法を提供することです。
Network Working Group R. Droms
Request for Comments: 3736 Cisco Systems
Category: Standards Track April 2004
Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6
IPv6のステートレス動的ホスト構成プロトコル（DHCP）サービス
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.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状況については、「Internet Official Protocol Standards」（STD 1）の現在の版を参照してください。このメモの分布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット社会（2004）。全著作権所有。
Abstract
概要
Stateless Dynamic Host Configuration Protocol service for IPv6 (DHCPv6) is used by nodes to obtain configuration information, such as the addresses of DNS recursive name servers, that does not require the maintenance of any dynamic state for individual clients. A node that uses stateless DHCP must have obtained its IPv6 addresses through some other mechanism, typically stateless address autoconfiguration. This document explains which parts of RFC 3315 must be implemented in each of the different kinds of DHCP agents so that agent can support stateless DHCP.
IPv6（DHCPv6）のステートレスダイナミックホスト構成プロトコルサービスは、DNS再帰ネームサーバーのアドレスなどの構成情報を取得するためにノードによって使用されます。これは、個々のクライアントのダイナミック状態のメンテナンスを必要としません。ステートレスDHCPを使用するノードは、他のメカニズム、通常はステートレスアドレスの自動設定を介してIPv6アドレスを取得している必要があります。この文書では、エージェントがステートレスDHCPをサポートできるように、RFC 3315のどの部分を異なる種類のDHCPエージェントに実装する必要があるかについて説明します。
Nodes that have obtained IPv6 addresses through some other mechanism, such as stateless address autoconfiguration [6] or manual configuration, can use stateless DHCP to obtain other configuration information such as a list of DNS recursive name servers or SIP servers. A stateless DHCP server provides only configuration information to nodes and does not perform any address assignment. Such a server is called "stateless" because it need not maintain any dynamic state for individual clients.
ステートレスアドレス自動設定[6]または手動構成など、他のメカニズムを介してIPv6アドレスを取得したノードは、ステートレスDHCPを使用して、DNS再帰ネームサーバーまたはSIPサーバーのリストなどの他の構成情報を取得できます。ステートレスDHCPサーバーはノードに構成情報のみを提供し、アドレス割り当てを実行しません。そのようなサーバーは、個々のクライアントに対して動的な状態を維持する必要がないため、「ステートレス」と呼ばれます。
While the DHCP specification [1] defines more than 10 protocol messages and 20 options, only a subset of those messages and options are required for stateless DHCP service. This document explains which messages and options defined in RFC 3315 are required for stateless DHCP service. The intended use of the document is to guide the interoperable implementation of clients and servers that use stateless DHCP service.
DHCP仕様[1]は10個以上のプロトコルメッセージと20オプションを定義しているが、ステートレスDHCPサービスにはそれらのメッセージとオプションのサブセットのみが必要です。この文書では、RFC 3315で定義されているメッセージとオプションがステートレスDHCPサービスに必要なのかを説明しています。文書の意図された用途は、ステートレスDHCPサービスを使用するクライアントとサーバーの相互運用可能な実装を導くことです。
The operation of relay agents is the same for stateless and stateful DHCP service. The operation of relay agents is described in the DHCP specification.
リレーエージェントの操作は、ステートレスおよびステートフルDHCPサービスで同じです。リレーエージェントの動作はDHCP仕様に記載されています。
Section 4 of this document lists the sections of the DHCP document that an implementor should read for an overview of the DHCP specification and the basic requirements of a DHCP service. Section 5 lists the specific messages and options that are specifically required for stateless DHCP service. Section 6 describes how stateless and stateful DHCP servers interact to provide service to clients that require address assignment and clients that require only stateless service.
このドキュメントのセクション4は、DHCPの指定の概要とDHCPサービスの基本的な要件を読み取るべきDHCP文書のセクションを示しています。セクション5に、ステートレスDHCPサービスに特に必要な特定のメッセージとオプションを示します。セクション6は、ステートレスおよびステートフルDHCPサーバーが、ステートレスサービスのみを必要とするアドレス割り当ておよびクライアントを必要とするクライアントにサービスを提供する方法を説明しています。
Throughout this document, "DHCP" refers to DHCP for IPv6.
この文書を通して、「DHCP」はIPv6のDHCPを指す。
This document uses the terminology defined in RFC 2460 [2], the DHCP specification [1], and the DHCP DNS configuration options specification [3].
このドキュメントでは、RFC 2460 [2]、DHCP仕様[1]、およびDHCP DNS構成オプション仕様[3]で定義されている用語を使用しています[3]。
"Stateless DHCP" refers to the use of DHCP to provide configuration information to clients that does not require the server to maintain dynamic state about the DHCP clients.
「ステートレスDHCP」とは、DHCPクライアントに関する動的な状態を維持する必要がないクライアントに構成情報を提供するためのDHCPの使用を指します。
This document assumes that a node using stateless DHCP configuration is not using DHCP for address assignment, and that a node has determined at least a link-local address as described in section 5.3 of RFC 2461 [4].
このドキュメントは、ステートレスDHCP設定を使用したノードがアドレス割り当てにDHCPを使用していないこと、およびRFC 2461 [4]のセクション5.3で説明されているようにノードが少なくともリンクローカルアドレスを決定していることを前提としています。
To obtain configuration parameters through stateless DHCP, a node uses the DHCP Information-request message. DHCP servers respond to the node's message with a Reply message that carries configuration parameters for the node. The Reply message from the server can carry configuration information, such as a list of DNS recursive name servers [3] and SIP servers [5].
ステートレスDHCPを介して設定パラメータを取得するために、ノードはDHCP情報要求メッセージを使用します。DHCPサーバーは、ノードの構成パラメータを搭載した返信メッセージを使用して、ノードのメッセージに応答します。サーバからの返信メッセージは、DNS再帰名サーバ[3]およびSIPサーバのリストなどの構成情報を運ぶことができる[5]。
This document does not apply to the function of DHCP relay agents as described in RFC 3315. A network element can provide both DHCP server and DHCP relay service. For example, a network element can provide stateless DHCP service to hosts requesting stateless DHCP service, while relaying messages from hosts requesting address assignment through DHCP to another DHCP server.
この文書は、RFC 3315に記載されているようなDHCPリレーエージェントの機能には適用されません。ネットワーク要素はDHCPサーバーとDHCPリレーサービスの両方を提供できます。たとえば、ネットワーク要素はステートレスDHCPサービスをステートレスDHCPサービスに提供することができます。
Several sections of the DHCP specification provide background information or define parts of the specification that are common to all implementations:
DHCP仕様のいくつかのセクションは、バックグラウンド情報を提供するか、すべての実装に共通の仕様の一部を定義します。
1-4: give an introduction to DHCP and an overview of DHCP message flows
1-4：DHCPの紹介とDHCPメッセージフローの概要
5: defines constants used throughout the protocol specification
5：プロトコル仕様を通して使用される定数を定義します
6, 7: illustrate the format of DHCP messages
6,7：DHCPメッセージのフォーマットを説明する
8: describes the representation of Domain Names
8：ドメイン名の表現について説明します
9: defines the "DHCP unique identifier" (DUID)
9：「DHCP固有識別子」（DUID）を定義します
13-16: describe DHCP message transmission, retransmission, and validation
13-16：DHCPメッセージ送信、再送信、および検証を説明する
21: describes authentication for DHCP
21：DHCPの認証について説明します
The client indicates that it is requesting configuration information by sending an Information-request message that includes an Option Request option specifying the options that it wishes to receive from the DHCP server. For example, if the client is attempting to obtain a list of DNS recursive name servers, it identifies the DNS Recursive Name Server option in the Information-request message. The server determines the appropriate configuration parameters for the client based on its configuration policies and responds with a Reply message containing the requested parameters. In this example, the server would respond with DNS configuration parameters.
クライアントは、DHCPサーバから受信したいオプションを指定するオプション要求オプションを含む情報要求メッセージを送信することによって構成情報を要求していることを示しています。たとえば、クライアントがDNS再帰ネームサーバーのリストを取得しようとしている場合は、情報要求メッセージのDNS再帰名サーバーオプションを識別します。サーバーは、その構成ポリシーに基づいてクライアントの適切な設定パラメータを決定し、要求されたパラメータを含む応答メッセージで応答します。この例では、サーバーはDNS構成パラメーターで応答します。
As described in section 18.1.5 of RFC 3315, a node may include a Client Identifier option in the Information-request message to identify itself to a server, because the server administrator may want to customize the server's response to each node, based on the node's identity.
RFC3315のセクション18.1.5に記載されているように、サーバ管理者は、サーバ管理者が各ノードに対するサーバの応答をカスタマイズすることができるので、情報要求メッセージ内のクライアント識別子オプションを含み得る。ノードのアイデンティティ
RFC 3315 does not define any mechanisms through which the time at which a host uses an Information-request message to obtain updated configuration parameters can be controlled. The DHC WG has undertaken the development of such a mechanism or mechanisms which will be published as Standards-track RFC(s).
RFC3315は、ホストが情報要求メッセージを使用して更新された構成パラメータを取得する時間が制御されるメカニズムを定義しない。DHC WGは、標準トラックRFCとして公開されるそのようなメカニズムまたはメカニズムの開発を行った。
RFC 3315 also does not provide any guidance about when a host might use an Information-request message to obtain updated configuration parameters when the host has moved to a new link. The DHC WG is reviewing a related document, "Detection of Network Attachment (DNA) in IPv4" [8], which describes how a host using IPv4 can determine when to use DHCPv4. Either the DHC WG or a WG formed from the DNA BOF will undertake development of a similar document for IPv6.
RFC 3315はまた、ホストが新しいリンクに移動したときに更新された構成パラメータを取得するためにホストが情報要求メッセージを使用することができるときについてのガイダンスも提供しない。DHC WGは関連文書を検討しています。「IPv4のネットワーク添付ファイルの検出（DNA）の検出（IPv4のDNA）の検出[8]。これは、IPv4を使用しているホストがいつ使用するかを決定する方法を説明します。DNA BOFから形成されたDHC WGまたはWGのいずれかは、IPv6についても同様の文書の開発を行う。
Clients and servers implement the following messages for stateless DHCP service; the section numbers in this list refer to the DHCP specification:
クライアントとサーバーは、ステートレスDHCPサービスに次のメッセージを実装しています。このリストのセクション番号はDHCP仕様を参照しています。
Information-request: sent by a DHCP client to a server to request configuration parameters (sections 18.1.5 and 18.2.5)
情報要求：設定パラメータを要求するためにDHCPクライアントによってサーバーに送信されます（セクション18.1.5と18.2.5）
Reply: sent by a DHCP server to a client containing configuration parameters (sections 18.2.6 and 18.2.8)
返信：構成パラメータを含むクライアントにDHCPサーバーによって送信されます（セクション18.2.6と18.2.8）
In addition, servers and relay agents implement the following messages for stateless DHCP service; the section numbers in this list refer to the DHCP specification:
さらに、サーバーとリレーエージェントは、ステートレスDHCPサービスに次のメッセージを実装しています。このリストのセクション番号はDHCP仕様を参照しています。
Relay-forward: sent by a DHCP relay agent to carry the client message to a server (section 15.13)
リレーフォワード：クライアントメッセージをサーバーに運ぶためにDHCPリレーエージェントによって送信されました（セクション15.13）
Relay-reply: sent by a DHCP server to carry a response message to the relay agent (section 15.14)
Relay-Reply：リレーエージェントに応答メッセージを伝送するためにDHCPサーバーによって送信されました（セクション15.14）
Clients and servers implement the following options for stateless DHCP service; the section numbers in this list refer to the DHCP specification:
クライアントとサーバーは、ステートレスDHCPサービスに次のオプションを実装しています。このリストのセクション番号はDHCP仕様を参照しています。
Option Request: specifies the configuration information that the client is requesting from the server (section 22.7)
オプション要求：クライアントがサーバーから要求している構成情報を指定します（セクション22.7）。
Status Code: used to indicate completion status or other status information (section 22.13)
ステータスコード：完了状況またはその他のステータス情報を示すために使用されます（セクション22.13）
Server Identifier: used to identify the server responding to a client request (section 22.3)
サーバー識別子：クライアント要求に応答するサーバーを識別するために使用されます（セクション22.3）
Servers and relay agents implement the following options for stateless DHCP service; the section numbers in this list refer to the DHCP specification:
サーバーとリレーエージェントは、ステートレスDHCPサービスに次のオプションを実行します。このリストのセクション番号はDHCP仕様を参照しています。
Client message: sent by a DHCP relay agent in a Relay-forward message to carry the client message to a server (section 20)
クライアントメッセージ：クライアントメッセージをサーバーに運ぶために、リレー転送メッセージのDHCPリレーエージェントによって送信されます（セクション20）。
Server message: sent by a DHCP server in a Relay-reply message to carry a response message to the relay agent (section 20)
サーバーメッセージ：Relay-Replyメッセージ内のDHCPサーバーによって送信され、リレーエージェントへの応答メッセージが実行されます（セクション20）。
Interface-ID: sent by the DHCP relay agent and returned by the server to identify the interface to be used when forwarding a message to the client (section 22.18)
interface-id：DHCPリレーエージェントによって送信され、サーバーから返されて、メッセージをクライアントに転送するときに使用されるインタフェースを識別するために（セクション22.18）
Clients and servers use the following options to pass configuration information to clients; note that other options for configuration information may be specified in future Internet Standards:
クライアントとサーバーは、コンフィギュレーション情報をクライアントに渡すために次のオプションを使用します。構成情報の他のオプションは、将来のインターネット規格で指定できます。
DNS Recursive Name Servers: specifies the DNS recursive name servers [7] the client uses for name resolution; see "DNS Configuration options for DHCPv6" [3]
DNS再帰名サーバ：DNS再帰ネームサーバ[7]クライアントが名前解決に使用する[7]を指定します。「DHCPv6のDNS設定オプション」を参照してください[3]
DNS search list: specifies the domain names to be searched during name resolution; see "DNS Configuration options for DHCPv6" [3]
DNS検索リスト：名前解決中に検索するドメイン名を指定します。「DHCPv6のDNS設定オプション」を参照してください[3]
SIP Servers: specifies the SIP servers the client uses to obtain a list of domain names of IPv6 addresses that can be mapped to one or more SIP outbound proxy servers [5]
SIPサーバ：1つ以上のSIPアウトバウンドプロキシサーバにマッピングできるIPv6アドレスのドメイン名のリストを取得するためにクライアントが使用するSIPサーバを指定します[5]
Clients and servers may implement the following options for stateless DHCP service; the section numbers in this list refer to the DHCP specification:
クライアントとサーバーは、ステートレスDHCPサービスに次のオプションを実行できます。このリストのセクション番号はDHCP仕様を参照しています。
Preference: sent by a DHCP server to indicate the preference level for the server (section 22.8)
環境設定：サーバーの環境設定レベルを示すためにDHCPサーバーによって送信されます（セクション22.8）
Elapsed time: sent by a DHCP client to indicate the time since the client began the DHCP configuration process (section 22.9)
経過時間：クライアントがDHCP構成プロセスを開始してからの時間を示すためにDHCPクライアントによって送信されました（セクション22.9）
User Class: sent by a DHCP client to give additional information to the server for selecting configuration parameters for the client (section 22.15)
ユーザークラス：クライアントの設定パラメータを選択するためにサーバーに追加情報を提供するためにDHCPクライアントによって送信されます（セクション22.15）。
Vendor Class: sent by a DHCP client to give additional information about the client vendor and hardware to the server for selecting configuration parameters for the client (section 22.16)
ベンダークラス：クライアントの設定パラメータを選択するためにクライアントベンダーとハードウェアに関する追加情報をサーバーに提供するためにDHCPクライアントによって送信されます（セクション22.16）。
Vendor-specific Information: used to pass information to clients in options defined by vendors (section 22.17)
ベンダー固有の情報：ベンダーによって定義されたオプションのクライアントに情報を渡すために使用されます（セクション22.17）
Client Identifier: sent by a DHCP client to identify itself (section 22.2). Clients are not required to send this option; servers send the option back if included in a message from a client
クライアント識別子：それ自身を識別するためにDHCPクライアントによって送信されます（セクション22.2）。クライアントはこのオプションを送信する必要はありません。クライアントからのメッセージに含まれている場合、サーバーはオプションを返します。
Authentication: used to provide authentication of DHCP messages (section 21)
認証：DHCPメッセージの認証を提供するために使用されます（セクション21）
In some networks, there may be both clients that are using stateless address autoconfiguration and DHCP for DNS configuration and clients that are using DHCP for stateful address configuration. Depending on the deployment and configuration of relay agents, DHCP servers that are intended only for stateless configuration may receive messages from clients that are performing stateful address configuration.
一部のネットワークでは、ステートレスアドレスの自動設定を使用しているクライアントは、DHCPを使用しているDNS構成およびDHCPの両方がステートフルアドレス設定に使用されている可能性があります。リレーエージェントの展開と設定に応じて、ステートレス構成に対してのみ意図されているDHCPサーバーは、ステートフルアドレス構成を実行しているクライアントからメッセージを受信できます。
A DHCP server that is only able to provide stateless configuration information through an Information-request/Reply message exchange discards any other DHCP messages it receives. Specifically, the server discards any messages other than Information-Request or Relay-forward it receives, and the server does not participate in any stateful address configuration message exchanges. If there are other DHCP servers that are configured to provide stateful address assignment, one of those servers will provide the address assignment.
情報要求/返信メッセージ交換を通じてステートレス構成情報を提供できるDHCPサーバーは、受信した他のDHCPメッセージを破棄します。具体的には、サーバは情報要求または受信した情報要求または中継フォワード以外のメッセージを破棄し、サーバはステートフルアドレス設定メッセージの交換に参加しない。ステートフルアドレス割り当てを提供するように構成されている他のDHCPサーバがある場合、それらのサーバのうちの1つはアドレス割り当てを提供します。
Stateless DHCP service is a proper subset of the DHCP service described in the DHCP specification, RFC 3315 [1]. Therefore, stateless DHCP service introduces no additional security considerations beyond those discussed in sections 21, 22.11, and 23 of the DHCP specification [1].
ステートレスDHCPサービスは、DHCP仕様RFC 3315 [1]に記載されているDHCPサービスの適切なサブセットです。したがって、ステートレスDHCPサービスは、DHCP仕様書のセクション21,22.11、および23で説明されているものを超えて、追加のセキュリティ上の考慮事項を紹介しません[1]。
Configuration information provided to a node through stateless DHCP service may be used to mount spoofing, man-in-the-middle, denial-of-service, and other attacks. These attacks are described in more detail in the specifications for each of the options that carry configuration information. Authenticated DHCP, as described in sections 21 and 22.11 of the DHCP specification [1], can be used to avoid attacks mounted through the stateless DHCP service.
ステートレスDHCPサービスを介してノードに提供される構成情報を使用して、スプーフィング、マン、中間、サービス拒否、およびその他の攻撃を実装するために使用されます。これらの攻撃は、構成情報を搬送する各オプションの仕様に詳しく説明されています。DHCP仕様書のセクション21および22.11で説明されている認証されたDHCP [1]は、ステートレスDHCPサービスを介してマウントされた攻撃を回避するために使用できます。
Jim Bound, Ted Lemon, and Bernie Volz reviewed this document and contributed editorial suggestions. Thanks to Peter Barany, Tim Chown, Christian Huitema, Tatuya Jinmei, Pekka Savola, and Juha Wiljakka for their review and comments.
Jim Bound、Ted Lemon、およびBernie Volzはこの文書を検討し、社説の貢献を貢献しました。Peter Barany、Tim Chown、Christian Huitema、Tatuya Jinmei、Pekka Savola、Juha Wiljakka、レビューやコメントおかげでおかげでお願いいたします。
[1] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[1] DROM、R.、ED。、境界、volz、B.、Lemon、T.、Perkins、C、M. Carney、「IPv6の動的ホスト構成プロトコル（DHCPv6）」、RFC 3315、2003年7月。
[2] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[2] 1998年12月、S.およびR.hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460。
[3] Droms, R., Ed., "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, December 2003.
[3] 2003年12月、RFC 3646、RFC 3646、RFC 3646、RFC 3646、RFC 3646。
[4] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[4] Narten、T.、Nordmark、E.およびW.Simpson、「IPバージョン6の隣接発見（IPv6）」、RFC 2461、1998年12月。
[5] Schulzrinne, H. and B. Volz, "Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol (SIP) Servers", RFC 3319, July 2003.
[5] Schulzrinne、H.およびB. Volz、「Dynamic Host Configuration Protocol（DHCPv6）のセッション開始プロトコル（SIP）サーバ」、RFC 3319、2003年7月。
[6] Thomson, S. and T. Narten, "IPv6 Stateless Address Autoconfiguration", RFC 2462, December 1998.
[6] Thomson、S.およびT.Narten、「IPv6ステートレスアドレス自動設定」、RFC 2462、1998年12月。
[7] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[7] Mockapetris、P.、「ドメイン名 - コンセプトと施設」、STD 13、RFC 1034、1987年11月。
[8] Aboba, B., "Detection of Network Attachment (DNA) in IPv4", Work in Progress.
[8] Aboba、B.、「IPv4におけるネットワークアタッチメントの検出」、進行中の作業。
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough, MA 01719 USA
Ralph Droms Cisco Systems 1414 Massachusetts Avenue Boxborough、MA 01719 USA
Phone: +1 978 497 4733
EMail: rdroms@cisco.com
Copyright (C) The Internet Society (2004). 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.
著作権（C）インターネット社会（2004）。この文書は、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は、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事務局へのIETF事務局と利用可能なライセンスの保証のコピー、またはこの仕様書の実装者や利用者による一般的なライセンスまたは許可を得るための試みの結果を得ることができます。IETFオンラインIPRリポジトリからhttp://www.ietf.org/ipr。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、著作権、特許または特許出願、またはこの規格を実装することが要求される可能性がある技術をカバーする可能性のある他の独自の権利を注意を及ぼすように興味のある当事者を勧めます。ietf-ipr@ietf.orgのIETFに情報を宛先に宛ててください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディタ機能のための資金は、現在インターネット社会によって提供されています。