Network Working Group B. Volz
Request for Comments: 4704 Cisco Systems, Inc.
Category: Standards Track October 2006
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option
IPv6の（DHCPv6の）クライアント完全修飾ドメイン名（FQDN）オプションのための動的ホスト構成プロトコル
Status of This Memo
このメモのステータス
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
Abstract
抽象
This document specifies a new Dynamic Host Configuration Protocol for IPv6 (DHCPv6) option that can be used to exchange information about a DHCPv6 client's Fully Qualified Domain Name (FQDN) and about responsibility for updating DNS resource records (RRs) related to the client's address assignments.
このドキュメントでは、クライアントのアドレス割り当てに関連したIPv6のための新たな動的ホスト構成プロトコルDHCPv6クライアントの完全修飾ドメイン名（FQDN）程度とDNSリソースレコードを更新するための責任についての情報を交換するために使用することができます（DHCPv6の）オプション（RRS）を指定します。
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................3
3. Models of Operation .............................................3
4. The DHCPv6 Client FQDN Option ...................................4
4.1. The Flags Field ............................................5
4.2. The Domain Name Field ......................................6
5. DHCPv6 Client Behavior ..........................................7
5.1. Client Desires to Update AAAA RRs ..........................7
5.2. Client Desires Server to Do DNS Updates ....................7
5.3. Client Desires No Server DNS Updates .......................7
5.4. Domain Name and DNS Update Issues ..........................8
6. DHCPv6 Server Behavior ..........................................9
6.1. When to Perform DNS Updates ................................9
7. DNS RR TTLs ....................................................10
8. DNS Update Conflicts ...........................................11
9. IANA Considerations ............................................11
10. Security Considerations .......................................12
11. Acknowledgements ..............................................12
12. References ....................................................13
12.1. Normative References .....................................13
12.2. Informative References ...................................13
DNS ([2], [3]) maintains (among other things) the information about mapping between hosts' Fully Qualified Domain Names (FQDNs) [10] and IPv6 addresses assigned to the hosts. The information is maintained in two types of Resource Records (RRs): AAAA and PTR [12]. The DNS update specification [4] describes a mechanism that enables DNS information to be updated over a network.
DNS（[2]、[3]）は（とりわけ）ホストに割り当てられたホストの完全修飾ドメイン名（FQDN）[10]とIPv6アドレス間のマッピングに関する情報を維持します。 AAAAとPTR [12]：情報は、リソースレコード（RR）の二種類に維持されます。 DNS更新仕様[4]はDNS情報がネットワークを介して更新されることを可能にするメカニズムを説明しています。
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) [5] provides a mechanism by which a host (a DHCPv6 client) can acquire certain configuration information, along with its stateful IPv6 address(es). This document specifies a new DHCPv6 option, the Client FQDN option, which can be used by DHCPv6 clients and servers to exchange information about the client's fully qualified domain name and about who has the responsibility for updating the DNS with the associated AAAA and PTR RRs.
IPv6用動的ホスト構成プロトコル（DHCPv6の）は、[5]ホスト（DHCPv6クライアント）がそのステートフルIPv6アドレス（複数可）と一緒に、特定の構成情報を取得することができるメカニズムを提供します。この文書では、クライアントの完全修飾ドメイン名程度と関連するAAAA RRとPTR RRとDNSを更新する責任を負っている人についての情報を交換するためのDHCPv6クライアントとサーバで使用できる新しいDHCPv6のオプション、クライアントFQDNオプションを指定します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[1]に記載のように解釈されます。
Familiarity with the DNS Update protocol [4] and with DHCPv6 and its terminology, as defined in [5], is assumed.
DNS更新プロトコルに精通している[4]とDHCPv6およびその用語に、[5]、想定されるで定義した通りです。
When a DHCPv6 client acquires an address, a site's administrator may desire that the AAAA RR for the client's FQDN and the PTR RR for the acquired address be updated. Therefore, two separate DNS update transactions may occur. Acquiring an address via DHCPv6 involves two entities: a DHCPv6 client and a DHCPv6 server. In principle, each of these entities could perform none, one, or both of the DNS update transactions. However, in practice, not all permutations make sense. The DHCPv6 Client FQDN option is primarily intended to operate in the following two cases:
DHCPv6クライアントがアドレスを取得すると、サイトの管理者が取得したアドレスのために、クライアントのFQDNのためのAAAA RRとPTR RRが更新されることを望むかもしれません。したがって、2つの別々のDNS更新のトランザクションが発生する可能性があります。 DHCPv6クライアントとDHCPv6サーバ：DHCPv6の経由アドレスを取得するには2つのエンティティが含まれます。原則として、これらの各エンティティはどれも、1、またはDNSの更新トランザクションの両方を行うことができませんでした。しかし、実際には、すべての順列は意味を成しません。 DHCPv6のクライアントFQDNオプションは、主に以下の2つの場合で動作するように意図されています。
1. DHCPv6 client updates the AAAA RR; DHCPv6 server updates the PTR RR.
1. DHCPv6クライアントは、AAAA RRを更新します。 DHCPv6サーバはPTR RRを更新します。
The only difference between these two cases is whether the FQDN-to-IPv6-address mapping is updated by a DHCPv6 client or by a DHCPv6 server. The IPv6-address-to-FQDN mapping is updated by a DHCPv6 server in both cases.
これら2例の唯一の違いは、FQDNからIPv6アドレスへのマッピングは、DHCPv6クライアントによって、またはDHCPv6サーバによって更新されているかどうかです。 IPv6のアドレス・ツー・FQDNマッピングは両方のケースでは、DHCPv6サーバによって更新されます。
The reason these two are important, while others are unlikely, has to do with authority over the respective DNS domain names. A DHCPv6 client may be given authority over mapping its own AAAA RRs, or that authority may be restricted to a server to prevent the client from listing arbitrary addresses or associating its addresses with arbitrary domain names. In all cases, the only reasonable place for the authority over the PTR RRs associated with the address is in the DHCPv6 server that allocates the address.
他の人がそうしている間、これら二つは、重要な理由は、それぞれのDNSドメイン名に対する権限に関係しています。 DHCPv6クライアントは、独自のAAAA RRをマッピングする上で権限を与えられてもよいし、その権威は任意のアドレスをリストアップしたり、任意のドメイン名とそのアドレスを関連付けることからクライアントを防ぐために、サーバーに制限することができます。すべての場合において、アドレスに関連付けられたPTR RRを超える権威のための唯一の合理的な場所は、アドレスを割り当てDHCPv6サーバです。
Note: A third case is supported in which the client requests that the server perform no updates. However, this case is presumed to be rare because of the authority issues.
注意：第三の場合は、クライアントは、サーバが何のアップデートを実行しないことを要求するサポートされています。しかし、このような場合があるため、権限の問題で稀であると推定されます。
In any case, whether a site permits all, some, or no DHCPv6 servers and clients to perform DNS updates into the zones that it controls is entirely a matter of local administrative policy. This document does not require any specific administrative policy and does not propose one. The range of possible policies is very broad, from sites where only the DHCPv6 servers have been given credentials that the DNS servers will accept, to sites where each individual DHCPv6 client has been configured with credentials that allow the client to modify its own domain name. Compliant implementations MAY support some or all of these possibilities. Furthermore, this specification applies only to DHCPv6 client and server processes: it does not apply to other processes that initiate DNS updates.
サイトはすべて許可するかどうかをどのような場合には、それが制御するゾーンにDNSアップデートを実行するには、いくつか、または全くのDHCPv6サーバとクライアントは、完全にローカル管理ポリシーの問題です。このドキュメントは、特定の管理ポリシーを必要とせず、1を提案していません。可能な政策の範囲が唯一のDHCPv6サーバは、DNSサーバが受け入れる資格情報を与えられているサイトから、個々のDHCPv6クライアントは、クライアントが独自のドメイン名を変更できるように資格情報を使用して構成されているサイトに、非常に広いです。標準に準拠した実装は、これらの可能性の一部またはすべてをサポートするかもしれません。さらに、この仕様はDHCPv6クライアントとサーバプロセスに適用されます：それはDNSの更新を開始し、他のプロセスには適用されません。
This document describes a new DHCPv6 option that a client can use to convey all or part of its domain name to a DHCPv6 server. Site-specific policy determines whether or not DHCPv6 servers use the names that clients offer, and what DHCPv6 servers do in cases where clients do not supply domain names.
この文書では、クライアントがDHCPv6サーバにそのドメイン名のすべてまたは一部を伝えるために使用できる新しいDHCPv6のオプションについて説明します。サイト固有のポリシーのDHCPv6サーバは、クライアントが提供する名前を使用、とDHCPv6サーバは、クライアントがドメイン名を提供しない場合に何をしたか否かを判断します。
To update the IPv6-address-to-FQDN mapping, a DHCPv6 server needs to know the FQDN of the client for the addresses for the client's IA_NA bindings. To allow the client to convey its FQDN to the server, this document defines a new DHCPv6 option called "Client FQDN". The Client FQDN option also contains Flags that DHCPv6 clients and servers use to negotiate who does which updates.
IPv6のアドレス・ツー・FQDNのマッピングを更新するには、DHCPv6サーバは、クライアントのIA_NAバインディングのアドレスに対して、クライアントのFQDNを知る必要があります。クライアントがサーバにそのFQDNを伝えるためにできるようにするには、この文書では、「クライアントのFQDN」と呼ばれる新しいDHCPv6のオプションを定義します。クライアントFQDNオプションは、DHCPv6クライアントとサーバがどの更新を行います誰が交渉するために使用するフラグが含まれています。
The code for this option is 39. Its minimum length is 1 octet.
このオプションのコードは39、最小の長さは1つのオクテットです。
The format of the DHCPv6 Client FQDN option is shown below:
DHCPv6のクライアントFQDNオプションのフォーマットを以下に示します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_FQDN | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| flags | |
+-+-+-+-+-+-+-+-+ |
. .
. domain-name .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_CLIENT_FQDN (39)
オプションコードOPTION_CLIENT_FQDN（39）
option-len 1 + length of domain name
ドメイン名のオプション-LEN 1 +長さ
flags flag bits used between client and server to negotiate who performs which updates
交渉するためにクライアントとサーバの間で使用されるフラグのフラグビットは、誰がどの更新を行います
domain-name the partial or fully qualified domain name (with length option-len - 1)
部分的または完全修飾ドメイン名をドメイン名（長さオプション-LENに - 1）
The Client FQDN option MUST only appear in a message's options field and applies to all addresses for all IA_NA bindings in the transaction.
クライアントFQDNオプションは、メッセージのオプションフィールドに表示され、トランザクション内のすべてのIA_NAバインディングのためのすべてのアドレスに適用されなければなりません。
The format of the Flags field is:
Flagsフィールドの形式は次のとおりです。
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| MBZ |N|O|S|
+-+-+-+-+-+-+-+-+
The "S" bit indicates whether the server SHOULD or SHOULD NOT perform the AAAA RR (FQDN-to-address) DNS updates. A client sets the bit to 0 to indicate that the server SHOULD NOT perform the updates and 1 to indicate that the server SHOULD perform the updates. The state of the bit in the reply from the server indicates the action to be taken by the server; if it is 1, the server has taken responsibility for AAAA RR updates for the FQDN.
「S」ビットは、サーバがまたはAAAA RR（FQDNとアドレス）DNS更新を実行すべきでないかどうかを示します。クライアントは、サーバは、サーバが更新を実行すべきであることを示すために、更新および1を行うべきではないことを示すために、ビットを0に設定します。サーバからの応答内のビットの状態はサーバがとるべきアクションを示します。それが1である場合、サーバはFQDNのためのAAAA RRアップデートの責任を取りました。
The "O" bit indicates whether the server has overridden the client's preference for the "S" bit. A client MUST set this bit to 0. A server MUST set this bit to 1 if the "S" bit in its reply to the client does not match the "S" bit received from the client.
「O」ビットは、サーバが「S」ビットのクライアントの好みをオーバーライドしているかどうかを示します。クライアントは、クライアントへの返信に「S」ビットがクライアントから受信した「S」ビットが一致しない場合は、サーバーがこのビットを1に設定しなければならない0にこのビットを設定しなければなりません。
The "N" bit indicates whether the server SHOULD NOT perform any DNS updates. A client sets this bit to 0 to request that the server SHOULD perform updates (the PTR RR and possibly the AAAA RR based on the "S" bit) or to 1 to request that the server SHOULD NOT perform any DNS updates. A server sets the "N" bit to indicate whether the server SHALL (0) or SHALL NOT (1) perform DNS updates. If the "N" bit is 1, the "S" bit MUST be 0.
「N」ビットは、サーバがDNSアップデートを実行するべきではありませんかどうかを示します。クライアントは、サーバがアップデート（PTR RRおよび「S」ビットに基づいて、可能性のAAAA RR）またはサーバがDNS更新を実行しないことを要求する1を実行すべきことを要求するこのビットを0に設定します。サーバは、サーバが（0）または（1）DNS更新を行うものとないものかどうかを示すために「N」ビットをセットします。 「N」ビットが1である場合、「S」ビットは0でなければなりません。
The remaining bits in the Flags field are reserved for future assignment. DHCPv6 clients and servers that send the Client FQDN option MUST clear the MBZ bits, and they MUST ignore these bits.
フラグフィールドの残りのビットは将来の割り当てのために予約されています。クライアントFQDNオプションを送信するDHCPv6クライアントとサーバは、MBZビットをクリアしなければならない、と彼らはこれらのビットを無視しなければなりません。
The Domain Name part of the option carries all or part of the FQDN of a DHCPv6 client. The data in the Domain Name field MUST be encoded as described in Section 8 of [5]. In order to determine whether the FQDN has changed between message exchanges, the client and server MUST NOT alter the Domain Name field contents unless the FQDN has actually changed.
オプションのドメイン名部分には、DHCPv6クライアントのFQDNの全部または一部を運びます。 [5]のセクション8で説明したようにDomain Nameフィールドのデータが符号化されなければなりません。 FQDNが実際に変更されていない限り、FQDNは、メッセージ交換の間で変化しているかどうかを判断するためには、クライアントとサーバーは、ドメイン名のフィールドの内容を変更してはなりません。
A client MAY be configured with a fully qualified domain name or with a partial name that is not fully qualified. If a client knows only part of its name, it MAY send a name that is not fully qualified, indicating that it knows part of the name but does not necessarily know the zone in which the name is to be embedded.
クライアントは、完全修飾ドメイン名または完全に修飾されていない名前の一部を用いて構成することができます。クライアントは、その名の一部だけを知っていれば、それは名前の一部を知っているが、必ずしも名前を埋め込もうとするゾーンを知らないことを示す、完全に修飾されていない名前を送信することができます。
To send a fully qualified domain name, the Domain Name field is set to the DNS-encoded domain name including the terminating zero-length label. To send a partial name, the Domain Name field is set to the DNS-encoded domain name without the terminating zero-length label.
完全修飾ドメイン名を送信するには、ドメイン名のフィールドは終了長さゼロのラベルを含めDNSでエンコードされたドメイン名に設定されています。名前の一部を送信するには、ドメイン名のフィールドは終了長さゼロのラベルなしDNSでエンコードされたドメイン名に設定されています。
A client MAY also leave the Domain Name field empty if it desires the server to provide a name.
それは名前を提供するために、サーバーを希望する場合、クライアントはまた、空のドメイン名フィールドを離れることができます。
Servers SHOULD send the complete fully qualified domain name in Client FQDN options.
サーバーは、クライアントFQDNオプションに完全な完全修飾ドメイン名を送るべきです。
The following describes the behavior of a DHCPv6 client that implements the Client FQDN option.
以下は、クライアントFQDNオプションを実装DHCPv6クライアントの動作について説明します。
A client MUST only include the Client FQDN option in SOLICIT, REQUEST, RENEW, or REBIND messages.
クライアントは、SOLICIT、REQUESTでクライアントFQDNオプションを含めるRENEW、またはメッセージを再バインドする必要があります。
A client that sends the Client FQDN option MUST also include the option in the Option Request option if it expects the server to include the Client FQDN option in any responses.
それはサーバが応答におけるクライアントFQDNオプションを含めるように想定している場合、クライアントFQDNオプションを送信するクライアントも、オプション要求オプションでオプションを含まなければなりません。
If a client that owns/maintains its own FQDN wants to be responsible for updating the FQDN-to-IPv6-address mapping for the FQDN and address(es) used by the client, the client MUST include the Client FQDN option in the SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND message originated by the client. A client MAY choose to include the Client FQDN option in its SOLICIT messages. The "S", "O", and "N" bits in the Flags field in the option MUST be 0.
/を所有しているクライアントは、自身のFQDNは、クライアントが使用するFQDNとアドレス（複数可）のためのFQDNからIPv6アドレスのマッピングを更新するための責任になりたい維持した場合、クライアントはSOLICITのクライアントFQDNオプションとを含まなければなりません迅速に、コミット要求、RENEW、およびクライアントによって発信メッセージを再バインドします。クライアントは、SOLICITメッセージにおけるクライアントFQDNオプションを含めることを選択するかもしれません。 「S」、「O」、およびオプションのフラグフィールドに「N」ビットは0でなければなりません。
Once the client's DHCPv6 configuration is completed (the client receives a REPLY message and successfully completes a final check on the parameters passed in the message), the client MAY originate an update for the AAAA RRs (associated with the client's FQDN) unless the server has set the "S" bit to 1. If the "S" is 1, the DHCPv6 client SHOULD NOT initiate an update for the name in the server's returned Client FQDN option Domain Name field. However, a DHCPv6 client that is explicitly configured with a FQDN MAY ignore the state of the "S" bit if the server's returned name matches the client's configured name.
クライアントのDHCPv6設定が完了すると（クライアントが応答メッセージを受信して、成功したメッセージで渡されたパラメータの最終チェックを完了した）サーバは持っていない限り、クライアントが（クライアントのFQDNに関連付けられている）AAAA RRのためのアップデートを生じ得ます「S」は1である場合は1に、「S」ビットを設定し、DHCPv6クライアントがサーバの返されたクライアントFQDNオプションドメイン名]フィールドに名前のための更新を開始すべきではありません。サーバの返された名前は、クライアントの構成名と一致する場合は、明示的にFQDNで構成されたDHCPv6クライアントは、「S」ビットの状態を無視するかもしれません。
A client can choose to delegate the responsibility for updating the FQDN-to-IPv6-address mapping for the FQDN and address(es) used by the client to the server. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its SOLICIT with Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the Client FQDN option in its SOLICIT. The "S" bit in the Flags field in the option MUST be 1, and the "O" and "N" bits MUST be 0.
クライアントは、サーバーへのクライアントが使用するFQDNとアドレス（複数可）のためのFQDNからIPv6アドレスのマッピングを更新する責任を委任することを選択できます。この選択のサーバに通知するために、クライアントは、急速なとのSOLICITのクライアントFQDNオプションは、コミット要求、RENEW、およびメッセージを再バインドし、そのSOLICITのクライアントFQDNオプションを含んでもよい（MAY）含むべきです。オプションのフラグフィールドに「S」ビットは1でなければなりません、そして「O」および「N」ビットは0でなければなりません。
A client can choose to request that the server perform no DNS updates on its behalf. In order to inform the server of this choice, the client SHOULD include the Client FQDN option in its SOLICIT with
クライアントは、サーバがその代わりに、何のDNSアップデートを実行しないことを要求するために選択することができます。この選択のサーバに通知するために、クライアントはSOLICITのクライアントFQDNオプションとを含むべきです
Rapid Commit, REQUEST, RENEW, and REBIND messages and MAY include the Client FQDN option in its SOLICIT. The "N" bit in the Flags field in the option MUST be 1, and the "S" and "O" bits MUST be 0.
迅速に、コミット要求、RENEW、およびメッセージを再バインドし、そのSOLICITのクライアントFQDNオプションを含むかもしれません。オプションのフラグフィールドに「N」ビットは1でなければなりません、そして「S」と「O」のビットは0でなければなりません。
Once the client's DHCPv6 configuration is completed (the client receives a REPLY message and successfully completes a final check on the parameters passed in the message), the client MAY originate its DNS updates provided the server's "N" bit is 1. If the server's "N" bit is 0, the server MAY perform the PTR RR updates; it MAY also perform the AAAA RR updates if the "S" bit is 1.
クライアントのDHCPv6設定が完了すると、「（クライアントが応答メッセージを受信して、成功したメッセージで渡されたパラメータの最終チェック完了）サーバーの「N」ビットは、サーバの場合は1です提供、クライアントはそのDNSの更新を生じてもよいしN」ビットが0である、PTR RRアップデートを実行するかもしれサーバー。 「S」ビットが1であれば、それはまた、AAAA RRアップデートを実行してもよいです。
As there is a possibility that the DHCPv6 server is configured to complete or replace a domain name that the client sends, the client MAY find it useful to send the Client FQDN option in its SOLICIT messages. If the DHCPv6 server returns different Domain Name data in its ADVERTISE message, the client could use that data in performing its own eventual AAAA RR update, or in forming the Client FQDN option that it sends in its subsequent messages. There is no requirement that the client send identical Client FQDN option data in its SOLICIT, REQUEST, RENEW, or REBIND messages. In particular, if a client has sent the Client FQDN option to its server, and the configuration of the client changes so that its notion of its domain name changes, it MAY send the new name data in a Client FQDN option when it communicates with the server again. This MAY cause the DHCPv6 server to update the name associated with the PTR records and, if the server updated the AAAA record representing the client, to delete that record and attempt an update for the client's current domain name.
DHCPv6サーバは、クライアントが送信したドメイン名を補完または交換するように設定されている可能性があるため、クライアントは、それが役に立つのSOLICITメッセージにおけるクライアントFQDNオプションを送信するかもしれません。 DHCPv6サーバは、そのADVERTISEメッセージで異なるドメイン名のデータを返した場合、クライアントは自身の最終的なAAAA RRの更新を実行中、またはそれはその後続のメッセージで送信するクライアントFQDNオプションを形成する際にそのデータを使用することができます。クライアントは、そのSOLICITに同じクライアントFQDNオプションデータを送信REQUEST、RENEW、またはメッセージをREBIND必要はありません。クライアントがサーバーへのクライアントFQDNオプション、およびクライアントの設定が変更を送信した場合、それが通信する際に、特に、そのドメイン名の変更のその概念は、それがクライアントFQDNオプションに新しい名前のデータを送信できるように、サーバーを再び。これは、DHCPv6サーバがそのレコードを削除して、クライアントの現在のドメイン名の更新を試行すると、サーバーがクライアントを表すAAAAレコードを更新した場合、PTRレコードに関連付けられている名前を更新し、することがあります。
A client that delegates the responsibility for updating the FQDN-to-IPv6-address mapping to a server will not receive any indication (either positive or negative) from the server as to whether the server was able to perform the update. The client MAY use a DNS query to check whether the mapping is up to date. However, depending on the load on the DHCPv6 and DNS servers and the DNS propagation delays, the client can only infer success. If the information is not found to be up to date in DNS, the authoritative servers might not have completed the updates or zone transfers, or caching resolvers may yet have updated their caches.
クライアントその委任サーバが更新を実行することができたかどうかのサーバから（正または負）を任意の指示を受信しませんサーバーにFQDNからIPv6アドレスのマッピングを更新する責任。クライアントは、マッピングが最新であるかどうかを確認するためにDNSクエリを使用するかもしれません。しかし、DHCPv6のとDNSサーバやDNSの伝播遅延の負荷に応じて、クライアントは成功を推測することができます。情報がDNSに最新の状態にあることが判明していない場合は、権限サーバは、更新やゾーン転送を完了していない可能性があります、またはキャッシュリゾルバは、まだそれらのキャッシュを更新している可能性があります。
If a client releases an address prior to the expiration of the valid lifetime and the client is responsible for updating its AAAA RR, the client SHOULD delete the AAAA RR associated with the address before sending a RELEASE message. Similarly, if a client is responsible for updating its AAAA RRs, but is unable to renew the lifetimes for an address, the client SHOULD attempt to delete the AAAA RR before the lifetime on the address is no longer valid. A DHCPv6 client that has not been able to delete an AAAA RR that it added SHOULD attempt to notify its administrator, perhaps by emitting a log message.
クライアントは、有効期間の満了前にアドレスを解放し、クライアントがそのAAAA RRを更新する責任がある場合、クライアントは、RELEASEメッセージを送信する前に、アドレスに関連付けられたAAAA RRを削除する必要があります。クライアントはそのAAAAのRRを更新する責任があるが、アドレスの寿命を更新することができない場合は同様に、クライアントはアドレスの寿命がもはや有効ではありません前にAAAA RRを削除しようとすべきです。それは追加のAAAA RRを削除することができなかったDHCPv6クライアントは、おそらくログメッセージを発することで、その管理者に通知することを試みるべきです。
A client SHOULD NOT perform DNS updates to AAAA RRs for its non-Global Unicast addresses [7] or temporary addresses [6].
クライアントは、[6] [7]または一時アドレスその非グローバルユニキャストアドレスのためのAAAA RRのにDNSアップデートを実行しないでください。
The following describes the behavior of a DHCPv6 server that implements the Client FQDN option when the client's message includes the Client FQDN option.
以下は、クライアントのメッセージは、クライアントFQDNオプションを含んでいるクライアントFQDNオプションを実装DHCPv6サーバの動作について説明します。
Servers MUST only include a Client FQDN option in ADVERTISE and REPLY messages if the client included a Client FQDN option and the Client FQDN option is requested by the Option Request option in the client's message to which the server is responding.
サーバーのみADVERTISEのクライアントFQDNオプションを含めると、クライアントは、クライアントFQDNオプションを含めるとクライアントFQDNオプションは、サーバーが応答していると、クライアントのメッセージにオプション要求オプションによって要求された場合、メッセージに返信しなければなりません。
The server examines its configuration and the Flag bits in the client's Client FQDN option to determine how to respond:
サーバが応答する方法を決定するために、その構成やクライアントのクライアントFQDNオプションのフラグビットを調べます。
o The server sets to 0 the "S", "O", and "N" bits in its copy of the option it will return to the client.
0へのサーバー・セット「S」、「O」、およびオプションのコピーで「N」ビットoをそれがクライアントに戻ります。
o If the client's "N" bit is 1 and the server's configuration allows it to honor the client's request for no server-initiated DNS updates, the server sets the "N" bit to 1.
クライアントの「N」ビットが1で、サーバの設定は、それが無いサーバー開始DNSの更新のためのクライアントの要求を尊重することを可能にする場合は、O、サーバが1に「N」ビットをセットします。
o Otherwise, if the client's "S" bit is 1 and the server's configuration allows it to honor the client's request for the server to initiate AAAA RR DNS updates, the server sets the "S" to 1. If the server's "S" bit does not match the client's "S" bit, the server sets the "O" bit to 1.
クライアントの「S」ビットが1であり、サーバの設定は、それがAAAA RR DNSアップデートを開始するサーバーのクライアントの要求を尊重することを可能にする場合は、サーバーの「S」ビット場合はOそれ以外の場合は、サーバが1に「S」を設定しますクライアントの「S」ビットが一致しない、サーバが1に「O」ビットをセットします。
The server MAY be configured to use the name supplied in the client's Client FQDN option, or it MAY be configured to modify the supplied name or to substitute a different name. The server SHOULD send its notion of the complete FQDN for the client in the Domain Name field. The server MAY simply copy the Domain Name field from the Client FQDN option that the client sent to the server.
サーバーは、クライアントのクライアントFQDNオプションで指定された名前を使用するように設定してもよいし、指定された名前を変更するか、別の名前に置き換えるように構成することができます。サーバーは、ドメイン名]フィールドに、クライアントのための完全なFQDNのその概念を送るべきです。サーバは単に、クライアントがサーバに送信することをクライアントFQDNオプションからドメイン名フィールドをコピーすることができます。
The server SHOULD NOT perform any DNS updates if the "N" bit is 1 in the Flags field of the Client FQDN option in the REPLY messages (to be) sent to the client. However, the server SHOULD delete any RRs that it previously added via DNS updates for the client.
「N」ビットがREPLYメッセージでクライアントFQDNオプションのフラグ欄に1であれば、サーバーは任意のDNSアップデートを実行するべきではありませんクライアントに送信される（べき）。ただし、サーバーは、クライアントのためにDNSアップデートを経由して、それが以前に追加された任意のRRを削除する必要があります。
The server MAY perform the PTR RR DNS update (unless the "N" bit is 1).
（「N」ビットが1である場合を除く）サーバはPTR RR DNSアップデートを実行することができます。
The server MAY perform the AAAA RR DNS update if the "S" bit is 1 in the Flags field of the Client FQDN option in the REPLY message (to be) sent to the client.
「S」ビットがREPLYメッセージでクライアントFQDNオプションのフラグ欄に1であれば、サーバがAAAAのRRのDNSの更新を実行することが可能クライアントに送信される（べき）。
The server MAY perform these updates even if the client's message did not carry the Client FQDN option. The server MUST NOT initiate DNS updates when responding with an ADVERTISE message to the client.
サーバは、クライアントのメッセージは、クライアントFQDNオプションを運ぶなかった場合でも、これらの更新を行うことができます。クライアントにADVERTISEメッセージで応答する場合、サーバはDNSのアップデートを開始してはなりません。
The server MAY complete its DNS updates (PTR RR or PTR and AAAA RR) before or after sending the REPLY message to the client.
サーバーは、前またはクライアントに応答メッセージを送信した後にそのDNSアップデート（PTR RRかPTRとのAAAA RR）を完了することができます。
If the server's AAAA RR DNS update does not complete until after the server has replied to the DHCPv6 client, the server's interaction with the DNS server MAY cause the DHCPv6 server to change the domain name that it associates with the client. This can occur, for example, if the server detects and resolves a domain-name conflict [8]. In such cases, the domain name that the server returns to the DHCPv6 client would change between two DHCPv6 exchanges.
サーバーのAAAAのRRのDNSの更新はサーバがDHCPv6クライアントに答えた後までに完了しない場合、DNSサーバーとサーバーの相互作用は、DHCPv6サーバは、クライアントに関連付けられているドメイン名を変更することがあります。サーバは、ドメイン名の競合を検出し解決する場合、これは、[8]、例えば、起こり得ます。このような場合には、サーバはDHCPv6クライアントに返すことにドメイン名が2つのDHCPv6交換機間変化するであろう。
If the server previously performed DNS updates for the client and the client's information has not changed, the server MAY skip performing additional DNS updates.
サーバーが以前のクライアント用のDNSアップデートを実行し、クライアントの情報が変更されていない場合、サーバーは、追加のDNS更新を実行スキップすることができます。
When a server receives a RELEASE or DECLINE for an address, detects that the valid lifetime on an address that the server bound to a client has expired, or terminates a binding on an address prior to the binding's expiration time (for instance, by sending a REPLY with a zero valid lifetime for an address), the server SHOULD delete any PTR RR that it associated with the address via DNS update. In addition, if the server took responsibility for AAAA RRs, the server SHOULD also delete the AAAA RR.
サーバがアドレスのRELEASEまたはDECLINEを受信すると、クライアントにバインドされたサーバーが期限切れ、または終了したアドレスの有効期間が送信することにより、例えば（バインディングの有効期限前にアドレスにバインドすることを検出し、アドレスのゼロ有効寿命）で応答し、サーバはDNSのアップデート経由アドレスに関連付けられたすべてのPTR RRを削除する必要があります。サーバはAAAA RRのための責任を取った場合また、サーバーは、AAAA RRを削除する必要があります。
RRs associated with DHCP clients may be more volatile than statically configured RRs. DHCP clients and servers that perform dynamic updates should attempt to specify resource record TTLs that reflect this volatility, in order to minimize the possibility that answers to DNS queries will return records that refer to DHCP IP address assignments that have expired or been released.
DHCPクライアントに関連したRRは静的に設定されたRRよりも揮発性であってもよいです。動的更新を実行するDHCPクライアントとサーバは、DNSクエリに対する回答の期限が切れているか、解放され、DHCP IPアドレスの割り当てを参照して、レコードを返すこと可能性を最小限に抑えるために、この変動性を反映したリソースレコードのTTLを指定しようとすべきです。
The coupling among primary, secondary, and caching DNS servers is 'loose'; that is a fundamental part of the design of the DNS. This looseness makes it impossible to prevent all possible situations in which a resolver may return a record reflecting a DHCP-assigned IP address that has expired or been released. In deployment, this rarely, if ever, represents a significant problem. Most DHCP-managed clients are infrequently looked up by name in the DNS, and the deployment of IXFR [13] and NOTIFY [14] can reduce the latency between updates and their visibility at secondary servers.
第一、第二、およびキャッシングDNSサーバ間の結合は「緩い」です。それはDNSの設計の基本的な部分です。この緩みは不可能リゾルバの有効期限が切れているか解放され、DHCPによって割り当てられたIPアドレスを反映したレコードを返す可能性のあるすべての可能な状況を防止することができます。展開では、これはほとんど、これまでならば、重大な問題を表していません。ほとんどのDHCP管理クライアントは、まれにDNSで名前でルックアップ、およびIXFR [13]の展開とNOTIFYされている[14]アップデートサーバとセカンダリサーバでの視認性との間の待ち時間を減らすことができます。
We suggest these basic guidelines for implementers. In general, the TTLs for RRs added as a result of DHCP IP address assignment activity SHOULD be less than the initial lifetime. The RR TTL on a DNS record added SHOULD NOT exceed 1/3 of the lifetime, but SHOULD NOT be less than 10 minutes. We recognize that individual administrators will have varying requirements: DHCP servers and clients SHOULD allow administrators to configure TTLs and upper and lower bounds on the TTL values, either as an absolute time interval or as a percentage of the lease lifetime.
私たちは、実装のための基本的なガイドラインを示唆しています。一般的に、DHCP IPアドレス割り当て活性の結果として追加のRRのためのTTLは、初期寿命未満であるべきです。追加のDNSレコードにRRのTTLは、寿命の1/3を超えてはならないが、10分未満であるべきではありません。 DHCPサーバとクライアントは、絶対時間間隔として、あるいはリース寿命の割合としてのいずれか、管理者がTTL値にTTLをし、上限と下限を設定できるようにする必要があります：私たちは、個々の管理者は、様々な要件を持っていることを認識しています。
While clients and servers MAY update the TTL of the records as the lifetime is about to expire, there is no requirement that they do so as this puts additional load on the DNS system with likely little benefit.
寿命が期限切れになると、クライアントとサーバは、レコードのTTLを更新するかもしれないが、これはおそらくほとんど利点を持つDNSシステムに追加の負荷をかけるよう、彼らはそうする必要はありません。
This document does not resolve how a DHCPv6 client or server prevent name conflicts. This document addresses only how a DHCPv6 client and server negotiate the fully qualified domain name and who will perform the DNS updates.
この文書では、DHCPv6クライアントまたはサーバが名前の競合を防ぐ方法を解決しません。この文書では、DHCPv6クライアントとサーバーの完全修飾ドメイン名と誰がDNSの更新を行いますが交渉するだけでどのように対処しています。
Implementers of this work will need to consider how name conflicts will be prevented. If a DNS updater needs a security token in order to successfully perform DNS updates on a specific name, name conflicts can only occur if multiple updaters are given a security token for that name. Or, if the fully qualified domains are based on the specific address bound to a client, conflicts will not occur. Or, a name conflict resolution technique as described in "Resolving Name Conflicts" [8]) SHOULD be used.
この作品の実装者は、名前の衝突を防止する方法を検討する必要があります。 DNSアップデータが正常に特定の名前の上にDNS更新を実行するために、セキュリティトークンを必要とする場合、複数のアップデータは、その名のセキュリティ・トークンを与えられている場合は、名前の衝突にのみ発生する可能性があります。完全修飾ドメインがクライアントにバインドされた特定のアドレスに基づいている場合や、競合は発生しません。または、名前競合解決技法「名前解決の競合」に記載されているように[8]）を使用してください。
The IANA has assigned DHCPv6 option code 39 for the Client FQDN option.
IANAは、クライアントFQDNオプションのためのDHCPv6オプションコード39が割り当てられています。
Unauthenticated updates to the DNS can lead to tremendous confusion, through malicious attack or through inadvertent misconfiguration. Administrators need to be wary of permitting unsecured DNS updates to zones that are exposed to the global Internet. Both DHCPv6 clients and servers SHOULD use some form of update request origin authentication procedure (e.g., Secure DNS Dynamic Update [11]) when performing DNS updates.
DNSへの非認証の更新は、悪意のある攻撃を介して、または不注意による設定ミスにより、多大な混乱を招くことができます。管理者は、グローバルなインターネットに公開されているゾーンにセキュリティ保護されていないDNSの更新を許可するのを警戒する必要があります。 DNS更新を実行するときにDHCPv6クライアントとサーバの両方が更新要求元の認証手順のいくつかの形態（例えば、セキュアDNS動的更新[11]）を使用してください。
Whether a DHCPv6 client is responsible for updating an FQDN-to-IPv6- address mapping or whether this is the responsibility of the DHCPv6 server is a site-local matter. The choice between the two alternatives is likely based on the security model that is used with the DNS update protocol (e.g., only a client may have sufficient credentials to perform updates to the FQDN-to-IPv6-address mapping for its FQDN).
DHCPv6クライアントがFQDNツーIPv6-アドレスマッピングを更新するか、これはDHCPv6サーバの責任であるかどうか責任があるかどうか、サイトローカルの問題です。二つの選択肢間の選択は、おそらくDNS更新プロトコル（例えば、唯一のクライアントがFQDNのためのFQDNからIPv6アドレスへのマッピングの更新を実行するための十分な資格情報を有していてもよい）で使用されるセキュリティモデルに基づいています。
Whether a DHCPv6 server is always responsible for updating the FQDN-to-IPv6-address mapping (in addition to updating the IPv6-to-FQDN mapping), regardless of the wishes of an individual DHCPv6 client, is also a site-local matter. The choice between the two alternatives is likely based on the security model that is being used with DNS updates. In cases where a DHCPv6 server is performing DNS updates on behalf of a client, the DHCPv6 server SHOULD be sure of the DNS name to use for the client, and of the identity of the client.
DHCPv6サーバは常に（IPv6のツーFQDNのマッピングの更新に加えて）FQDNからIPv6アドレスのマッピングを更新する責任があるかどうかにかかわらず、個々のDHCPv6クライアントの希望の、また、サイトローカルの問題です。二つの選択肢間の選択は、おそらくDNSの更新に使用されているセキュリティモデルに基づいています。 DHCPv6サーバは、クライアントに代わってDNSアップデートを実行している場合には、DHCPv6サーバは、クライアントに使用するDNS名の、およびクライアントの身元を確認する必要があります。
Depending on the presence of or type of authentication used with the Authentication option, a DHCPv6 server may not have much confidence in the identities of its clients. There are many ways for a DHCPv6 server to develop a DNS name to use for a client, but only in certain circumstances will the DHCPv6 server know for certain the identity of the client.
存在または認証オプションと一緒に使用する認証の種類に応じて、DHCPv6サーバは、クライアントのアイデンティティで自信を持っていないかもしれません。そこクライアントに使用するDNS名を開発するために、DHCPv6サーバのための多くの方法があるが、唯一の特定の状況でDHCPv6サーバは、クライアントの特定のアイデンティティのために知っているだろう。
It is critical to implement proper conflict resolution, and the security considerations of conflict resolution apply [8].
適切な紛争解決を実装するために重要であり、そして紛争解決のセキュリティの考慮事項は、[8]適用されます。
Many thanks to Mark Stapp and Yakov Rekhter, as this document is based on the DHCPv4 Client FQDN option [9], and to Ralph Droms, Ted Lemon, Josh Littlefield, Kim Kinnear, Pekka Savola, and Mark Stapp for their review and comments.
マーク・スタップとヤコフ・レックターに感謝し、この文書は彼らのレビューとコメントのための[9]、およびラルフDroms、テッド・レモン、ジョッシュリトルフィールド、キム・キニア、ペッカSavola、およびマーク・スタップへのDHCPv4クライアントFQDNオプションに基づいています。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, November 1987.
[2] Mockapetris、P.、 "ドメイン名 - 概念と設備"、STD 13、RFC 1034、1987年11月。
[3] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987.
[3] Mockapetris、P.、 "ドメイン名 - 実装及び仕様"、STD 13、RFC 1035、1987年11月。
[4] Vixie, P., Thomson, S., Rekhter, Y., and J. Bound, "Dynamic Updates in the Domain Name System (DNS UPDATE)", RFC 2136, April 1997.
[4] RFC 2136 "ドメインネームシステム（DNS更新）における動的更新" いるVixie、P.、トムソン、S.、Rekhter、Y.、およびJ.はバウンド、4月1997。
[5] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003.
[5] Droms、R.、バウンド、J.、フォルツ、B.、レモン、T.、パーキンス、C.、およびM.カーニーを、 "IPv6のための動的ホスト構成プロトコル（DHCPv6）"、RFC 3315、2003年7月。
[6] Narten, T. and R. Draves, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 3041, January 2001.
[6] Narten氏、T.およびR. Draves、 "IPv6におけるステートレスアドレス自動設定のための個人情報保護の拡張"、RFC 3041、2001年1月。
[7] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[7] HindenとR.とS.デアリング、 "IPバージョン6アドレッシング体系"、RFC 4291、2006年2月。
[8] Stapp, M. and B. Volz, "Resolution of Fully Qualified Domain Name (FQDN) Conflicts among Dynamic Host Configuration Protocol (DHCP) Clients", RFC 4703, October 2006.
[8]、RFC 4703、2006年10月スタップ、M.とB.フォルツ、 "動的ホスト構成プロトコル（DHCP）クライアントの間で完全修飾ドメイン名（FQDN）競合の解決を"。
[9] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host Configuration Protocol (DHCP) Client Fully Qualified Domain Name (FQDN) Option", RFC 4702, October 2006.
[9]スタップ、M.、フォルツ、B.、およびY. Rekhter、 "動的ホスト構成プロトコル（DHCP）クライアント完全修飾ドメイン名（FQDN）オプション"、RFC 4702、2006年10月。
[10] Marine, A., Reynolds, J., and G. Malkin, "FYI on Questions and Answers - Answers to Commonly asked "New Internet User" Questions", FYI 4, RFC 1594, March 1994.
"FYI質問と回答について - 回答よく寄せられるために "[10]マリン、A.、レイノルズ、J.、およびG.マルキン、新しいインターネットユーザー" 質問"、FYI 4、RFC 1594、1994年3月。
[11] Wellington, B., "Secure Domain Name System (DNS) Dynamic Update", RFC 3007, November 2000.
[11]ウェリントン、B.、RFC 3007、2000年11月 "ドメインネームシステム（DNS）動的更新をセキュア"。
[12] Thomson, S., Huitema, C., Ksinant, V., and M. Souissi, "DNS Extensions to Support IP Version 6", RFC 3596, October 2003.
[12]トムソン、S.、のHuitema、C.、Ksinant、V.、およびM. Souissi、 "DNSの拡張機能IPバージョン6のサポートする"、RFC 3596を、2003年10月。
[13] Ohta, M., "Incremental Zone Transfer in DNS", RFC 1995, August 1996.
[13]太田、M.、 "DNSにおける増分ゾーン転送"、RFC 1995、1996年8月。
[14] Vixie, P., "A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)", RFC 1996, August 1996.
[14]いるVixie、P.、RFC 1996、1996年8月 "ゾーンの変更（DNSがNOTIFY）のプロンプト通知のメカニズム"。
Author's Address
著者のアドレス
Bernard Volz Cisco Systems, Inc. 1414 Massachusetts Ave. Boxborough, MA 01719 USA
バーナード・フォルツシスコシステムズ株式会社1414年マサチューセッツアベニュー。ボックスボロー、MA 01719 USA
Phone: +1 978 936 0382 EMail: volz@cisco.com
電話：+1 978 936 0382 Eメール：volz@cisco.com
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2006).
著作権（C）インターネット協会（2006）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFCエディタ機能のための資金は、IETF管理サポート活動（IASA）によって提供されます。