[要約] RFC 7550は、複数の状態を持つDHCPv6オプションに関する問題と推奨事項を提供しています。このRFCの目的は、DHCPv6オプションの設計と実装に関する問題を特定し、改善策を提案することです。
Internet Engineering Task Force (IETF) O. Troan
Request for Comments: 7550 B. Volz
Updates: 3315, 3633 Cisco Systems, Inc.
Category: Standards Track M. Siodelski
ISSN: 2070-1721 ISC
May 2015
Issues and Recommendations with Multiple Stateful DHCPv6 Options
複数のステートフルDHCPv6オプションに関する問題と推奨事項
Abstract
概要
The Dynamic Host Configuration Protocol for IPv6 (DHCPv6) specification defined two stateful options, IA_NA and IA_TA, but did not anticipate the development of additional stateful options. DHCPv6 Prefix Delegation added the IA_PD option, which is stateful. Applications that use IA_NA and IA_PD together have revealed issues that need to be addressed. This document updates RFCs 3315 and 3633 to address these issues.
IPv6の動的ホスト構成プロトコル（DHCPv6）仕様では、IA_NAとIA_TAの2つのステートフルオプションが定義されていますが、追加のステートフルオプションの開発は予期されていませんでした。 DHCPv6プレフィックス委任は、IA_PDオプションを追加しました。これはステートフルです。 IA_NAとIA_PDを一緒に使用するアプリケーションは、対処する必要がある問題を明らかにしました。このドキュメントは、これらの問題に対処するためにRFC 3315および3633を更新します。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7550.
このドキュメントの現在のステータス、エラッタ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc7550で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2015 IETF Trustおよびドキュメントの作成者として識別された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象であり、この文書の発行日に有効です。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English.
このドキュメントには、2008年11月10日より前に公開または公開されたIETFドキュメントまたはIETFコントリビューションの素材が含まれている場合があります。 IETF標準プロセス外。このような資料の著作権を管理する人から適切なライセンスを取得せずに、このドキュメントをIETF標準プロセス外で変更したり、その派生物をIETF標準プロセス外で作成したりすることはできません。 RFCとして、またはそれを英語以外の言語に翻訳するための出版物。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Handling of Multiple IA Option Types . . . . . . . . . . . . 4
4.1. Placement of Status Codes in an Advertise Message . . . . 6
4.2. Advertise Message Processing by a Client . . . . . . . . 8
4.3. T1/T2 Timers . . . . . . . . . . . . . . . . . . . . . . 9
4.4. Renew and Rebind Messages . . . . . . . . . . . . . . . . 10
4.4.1. Renew Message . . . . . . . . . . . . . . . . . . . . 10
4.4.2. Rebind Message . . . . . . . . . . . . . . . . . . . 11
4.4.3. Updates to Section 18.1.3 of RFC 3315 . . . . . . . . 11
4.4.4. Updates to Section 18.1.4 of RFC 3315 . . . . . . . . 13
4.4.5. Updates to Section 18.1.8 of RFC 3315 . . . . . . . . 14
4.4.6. Updates to Section 18.2.3 of RFC 3315 . . . . . . . . 16
4.4.7. Updates to Section 18.2.4 of RFC 3315 . . . . . . . . 18
4.4.8. Updates to RFC 3633 . . . . . . . . . . . . . . . . . 20
4.5. Confirm Message . . . . . . . . . . . . . . . . . . . . . 21
4.6. Decline Should Not Necessarily Trigger a Release . . . . 22
4.7. Multiple Provisioning Domains . . . . . . . . . . . . . . 22
5. Security Considerations . . . . . . . . . . . . . . . . . . . 22
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 22
6.1. Normative References . . . . . . . . . . . . . . . . . . 22
6.2. Informative References . . . . . . . . . . . . . . . . . 23
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
DHCPv6 [RFC3315] was written without the expectation that additional stateful DHCPv6 options would be developed. DHCPv6 Prefix Delegation [RFC3633] since added a new stateful option for Prefix Delegation to DHCPv6. Implementation experience of the Customer Edge (CE) router model described in [RFC7084] has shown issues with the DHCPv6 protocol in supporting multiple stateful option types, in particular IA_NA (non-temporary addresses) and IA_PD (delegated prefixes).
DHCPv6 [RFC3315]は、追加のステートフルDHCPv6オプションが開発されることを期待せずに作成されました。 DHCPv6プレフィックス委任[RFC3633]以降、DHCPv6にプレフィックス委任用の新しいステートフルオプションが追加されました。 [RFC7084]で説明されているカスタマーエッジ（CE）ルーターモデルの実装経験は、複数のステートフルオプションタイプ、特にIA_NA（非一時アドレス）とIA_PD（委任されたプレフィックス）のサポートにおけるDHCPv6プロトコルの問題を示しています。
This document describes a number of problems encountered with coexistence of the IA_NA and IA_PD option types and specifies changes to the DHCPv6 protocol to address these problems.
このドキュメントでは、IA_NAおよびIA_PDオプションタイプの共存で発生するいくつかの問題について説明し、これらの問題に対処するためのDHCPv6プロトコルへの変更を示します。
The intention of this work is to clarify and, where needed, modify the DHCPv6 protocol specification to support IA_NA and IA_PD option types within a single DHCPv6 session.
この作業の目的は、DHCPv6プロトコル仕様を明確にし、必要に応じて変更して、単一のDHCPv6セッション内でIA_NAおよびIA_PDオプションタイプをサポートすることです。
Note that while IA_TA (temporary addresses) options may be included with other IA option type requests, these generally are not renewed (there are no T1/T2 times) and have a separate life cycle from IA_NA and IA_PD option types. Therefore, the IA_TA option type is mostly out of scope for this document.
IA_TA（一時アドレス）オプションは他のIAオプションタイプのリクエストに含まれる場合がありますが、これらは通常更新されず（T1 / T2時間はありません）、IA_NAおよびIA_PDオプションタイプとは別のライフサイクルがあります。したがって、IA_TAオプションタイプは、このドキュメントの範囲外です。
The changes described in this document are intended to be incorporated in a new revision of the DHCPv6 protocol specification [DHCPv6].
このドキュメントで説明されている変更は、DHCPv6プロトコル仕様の新しいリビジョン[DHCPv6]に組み込まれることを目的としています。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
In addition to the terminology defined in [RFC3315], [RFC3633], and [RFC7227], the following terminology is used in this document:
このドキュメントでは、[RFC3315]、[RFC3633]、および[RFC7227]で定義されている用語に加えて、次の用語が使用されています。
Identity Association (IA): Throughout this document, "IA" is used to refer to the Identity Association containing addresses or prefixes assigned to a client and carried in the IA_NA or IA_PD options, respectively.
IDアソシエーション（IA）：このドキュメント全体で、「IA」は、クライアントに割り当てられ、IA_NAまたはIA_PDオプションでそれぞれ運ばれるアドレスまたはプレフィックスを含むIDアソシエーションを指すために使用されます。
IA option types: This is used to generally mean an IA_NA and/or IA_PD option.
IAオプションタイプ：これは、一般的にIA_NAまたはIA_PDオプション、あるいはその両方を意味するために使用されます。
Stateful options: Options that require a dynamic binding state per client on the server.
ステートフルオプション：サーバー上のクライアントごとに動的バインディング状態を必要とするオプション。
Top-level options: Top-level options are DHCPv6 options that are not encapsulated within other options, excluding the Relay Message option. Options encapsulated by Relay Message options, but not by any other option, are still top-level options, whether they appear in a relay agent message or a server message; see [RFC7227].
トップレベルオプション：トップレベルオプションは、リレーメッセージオプションを除く、他のオプション内にカプセル化されていないDHCPv6オプションです。リレーメッセージオプションでカプセル化されたオプションはカプセル化されますが、他のオプションではカプセル化されませんが、リレーエージェントメッセージまたはサーバーメッセージのどちらに表示されても、トップレベルのオプションです。 [RFC7227]を参照してください。
The DHCPv6 specification [RFC3315] was written with the assumption that the only stateful options were for assigning addresses. DHCPv6 Prefix Delegation [RFC3633] describes how to extend the DHCPv6 protocol to handle prefix delegation, but does not clearly specify how the DHCP address assignment and prefix delegation coexist.
DHCPv6仕様[RFC3315]は、ステートフルオプションはアドレスを割り当てるためのものであるという前提で記述されています。 DHCPv6プレフィックス委任[RFC3633]は、DHCPv6プロトコルを拡張してプレフィックス委任を処理する方法を説明していますが、DHCPアドレス割り当てとプレフィックス委任の共存方法を明確に指定していません。
If a client requests multiple IA option types, but the server is configured to only offer a subset of them, the client could react in several ways:
クライアントが複数のIAオプションタイプを要求しても、サーバーがそれらのサブセットのみを提供するように構成されている場合、クライアントはいくつかの方法で反応する可能性があります。
1. Reset the state machine and continue to send Solicit messages,
1. ステートマシンをリセットし、送信請求メッセージを送信し続けます。
2. Create separate DHCP sessions for each IA option type and continue to Solicit for the unfulfilled IA options, or
2. IAオプションタイプごとに個別のDHCPセッションを作成し、満たされていないIAオプションについて要請を続ける、または
3. The client could continue with the single session and include the unfulfilled IA options in subsequent messages to the server.
3. クライアントは単一のセッションを続行し、サーバーへの後続のメッセージに満たされていないIAオプションを含めることができます。
Resetting the state machine and continuing to send Solicit messages may result in the client never completing DHCP and is generally not considered a good solution. It can also result in a packet storm if the client does not appropriately rate limit its sending of Solicit messages or if there are many clients on the network. Client implementors that follow this approach SHOULD implement the updates to RFC 3315 specified in [RFC7083].
ステートマシンをリセットして送信請求メッセージを送信し続けると、クライアントがDHCPを完了できなくなる可能性があり、通常は適切なソリューションとは見なされません。また、クライアントが要請メッセージの送信を適切にレート制限しない場合、またはネットワーク上に多数のクライアントが存在する場合にも、パケットストームが発生する可能性があります。このアプローチに従うクライアント実装者は、[RFC7083]で指定されているRFC 3315への更新を実装する必要があります（SHOULD）。
Creating a separate DHCP session (separate instances of the client state machine) per IA option type, while conceptually simple, causes a number of issues: additional host resources required to create and maintain multiple instances of the state machine in clients, additional DHCP protocol traffic, unnecessary duplication of other configuration options and the potential for conflict, and divergence in that each IA option type specification specifies its 'own' version of the DHCP protocol.
IAオプションタイプごとに個別のDHCPセッション（クライアントステートマシンの個別のインスタンス）を作成すると、概念的には単純ですが、いくつかの問題が発生します。クライアントでステートマシンの複数のインスタンスを作成および維持するために必要な追加のホストリソース、追加のDHCPプロトコルトラフィック、他の構成オプションの不必要な重複と競合の可能性、および各IAオプションタイプの指定がDHCPプロトコルの「独自の」バージョンを指定する点での相違。
The single session and state machine allows the client to use the best configuration it is able to obtain from a single DHCP server during the configuration exchange. Note, however, that the server may not be configured to deliver the entire configuration requested by the client. In that case, the client could continue to operate only using the configuration received, even if other servers can provide the missing configuration. In practice, especially in the case of handling IA_NA and IA_PD, this situation should be rare or a temporary operational error. So, it is more likely for the client to get all configuration if it continues, in each subsequent configuration exchange, to request all the configuration information it is programmed to try to obtain, including any stateful configuration options for which no results were returned in previous exchanges.
単一のセッションと状態マシンにより、クライアントは、構成の交換中に単一のDHCPサーバーから取得できる最適な構成を使用できます。ただし、サーバーは、クライアントから要求された構成全体を配信するように構成されていない場合があることに注意してください。その場合、他のサーバーが不足している構成を提供できる場合でも、クライアントは受信した構成のみを使用して動作を継続できます。実際には、特にIA_NAおよびIA_PDを処理する場合、この状況はまれであるか、または一時的な操作エラーです。したがって、後続の各構成交換で、クライアントがすべての構成を取得する可能性が高くなり、その後の各構成交換では、以前に結果が返されなかったステートフル構成オプションを含む、取得しようとするすべての構成情報を要求します交換。
One major issue of this last approach is that it is difficult to allow it with the current DHCPv6 specifications; in some cases they are not clear enough, and in other cases existing restrictions can make it impossible. This document introduces some clarifications and small modifications to the current specifications to address these concerns.
この最後のアプローチの1つの主要な問題は、現在のDHCPv6仕様でそれを許可することが難しいことです。十分に明確でない場合もあれば、既存の制限により不可能になる場合もあります。このドキュメントでは、これらの懸念に対処するために、現在の仕様に対するいくつかの説明と小さな変更を紹介します。
While all approaches have their own pros and cons, approach number 3 above SHOULD be used and is the focus of this document because it is deemed to work best for common cases of the mixed use of IA_NA and IA_PD. But this document does not exclude other approaches. Also, in some corner cases it may not be feasible to maintain a single DHCPv6 session for both IA_NA and IA_PD. These corner cases are beyond the scope of this document and may depend on the network in which the client (CE router) is designed to operate and on the functions the client is required to perform.
すべてのアプローチには独自の長所と短所がありますが、上記のアプローチ番号3を使用する必要があり（SHOULD）、IA_NAとIA_PDの混合使用の一般的なケースに最適であると見なされるため、このドキュメントの焦点です。ただし、このドキュメントでは他のアプローチを除外していません。また、状況によっては、IA_NAとIA_PDの両方に対して単一のDHCPv6セッションを維持することができない場合があります。これらのまれなケースは、このドキュメントの範囲外であり、クライアント（CEルーター）が動作するように設計されているネットワークと、クライアントが実行する必要のある機能によって異なる場合があります。
The sections that follow update RFCs 3315 and 3633 to accommodate the recommendation, though many of the changes are also applicable even if other approaches are used.
以下のセクションでは、RFC 3315および3633を更新して推奨事項に対応していますが、他のアプローチを使用した場合でも、多くの変更が適用されます。
In Reply messages, IA-specific status codes (i.e., NoAddrsAvail, NotOnLink, NoBinding, and NoPrefixAvail) are encapsulated in the IA option. In Advertise messages though, the NoAddrsAvail code is returned at the top level. This makes sense if the client is only interested in the assignment of the addresses and the failure case is fatal. However, if the client sends both IA_NA and IA_PD options in a Solicit message, it is possible that the server will offer some prefixes but no addresses, and the client may choose to send a Request message to obtain the offered prefixes. In this case, it is better if the Status Code option for IA-specific status codes is encapsulated in the IA option to indicate that the failure occurred for the specific IA. This also makes the NoAddrsAvail and NoPrefixAvail Status Code option placement for Advertise messages identical to Reply messages.
返信メッセージでは、IA固有のステータスコード（つまり、NoAddrsAvail、NotOnLink、NoBinding、およびNoPrefixAvail）がIAオプションにカプセル化されます。ただし、アドバタイズメッセージでは、NoAddrsAvailコードがトップレベルで返されます。これは、クライアントがアドレスの割り当てのみに関心があり、失敗のケースが致命的である場合に意味があります。ただし、クライアントが要請メッセージでIA_NAオプションとIA_PDオプションの両方を送信する場合、サーバーが一部のプレフィックスを提供するがアドレスを提供しない可能性があり、クライアントは提供されたプレフィックスを取得するために要求メッセージを送信することを選択できます。この場合、IA固有のステータスコードのステータスコードオプションをIAオプションにカプセル化して、特定のIAで障害が発生したことを示すとよいでしょう。これにより、アドバタイズメッセージのNoAddrsAvailおよびNoPrefixAvailステータスコードオプションの配置も、返信メッセージと同じになります。
In addition, how a server formats the Advertise message when addresses are not available has been a point of some confusion and implementations seem to vary (some strictly follow RFC 3315 while others assumed it was encapsulated in the IA option as for Reply messages).
さらに、アドレスが利用できない場合にサーバーがアドバタイズメッセージをフォーマットする方法は、混乱のポイントであり、実装はさまざまです（RFC 3315に厳密に従うものもあれば、返信メッセージのようにIAオプションにカプセル化されていると想定するものもあります）。
We have chosen the following solution:
次のソリューションを選択しました。
Clients MUST handle each of the following Advertise message formats when there are no addresses available (even when no other IA option types were in the Solicit):
クライアントは、使用可能なアドレスがない場合（他のIAオプションタイプが要請に含まれていない場合でも）、次の各アドバタイズメッセージフォーマットを処理する必要があります。
1. Advertise containing the IA_NAs and/or IA_TAs with an encapsulated Status Code option of NoAddrsAvail and no top-level Status Code option.
1. NoAddrsAvailのカプセル化されたステータスコードオプションと最上位のステータスコードオプションのないIA_NAまたはIA_TAを含むアドバタイズ。
2. Advertise containing just a top-level Status Code option of NoAddrsAvail and no IA_NAs/IA_TAs.
2. NoAddrsAvailの最上位のステータスコードオプションのみを含み、IA_NAs / IA_TAsを含まないアドバタイズ。
3. Advertise containing a top-level Status Code option of NoAddrsAvail and IA_NAs and/or IA_TAs with a Status Code option of NoAddrsAvail.
3. NoAddrsAvailのトップレベルのステータスコードオプションとIA_NAおよび/またはIA_TAを含み、ステータスコードオプションがNoAddrsAvailであるアドバタイズ。
Note: Clients MUST handle the last two formats listed above to facilitate backward compatibility with the servers that have not been updated to this specification.
注：クライアントは上記の最後の2つの形式を処理して、この仕様に更新されていないサーバーとの下位互換性を促進する必要があります。
See Section 4.2 for updated text for Section 17.1.3 of RFC 3315 and Section 11.1 of RFC 3633.
RFC 3315のセクション17.1.3およびRFC 3633のセクション11.1の更新されたテキストについては、セクション4.2を参照してください。
Servers MUST return the Status Code option of NoAddrsAvail encapsulated in IA_NA/IA_TA options and MUST NOT return a top-level Status Code option of NoAddrsAvail when no addresses will be assigned (number 1 in the above list). This means that the Advertise response matches the Reply response with respect to the handling of the NoAddrsAvail status.
サーバーは、IA_NA / IA_TAオプションにカプセル化されたNoAddrsAvailのステータスコードオプションを返さなければならず、アドレスが割り当てられない場合（上記のリストの番号1）には、NoAddrsAvailのトップレベルのステータスコードオプションを返してはなりません。これは、Advertise応答がNoAddrsAvailステータスの処理に関してReply応答と一致することを意味します。
Replace the following paragraph in RFC 3315, Section 17.2.2:
RFC 3315のセクション17.2.2の次の段落を置き換えます。
If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server MUST send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail and a status message for the user, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID.
サーバーがクライアントからの後続のリクエストでどのIAにもアドレスを割り当てない場合、サーバーはコードNoAddrsAvailのステータスコードオプションとユーザーのステータスメッセージ、サーバー識別子のみを含むアドバタイズメッセージをクライアントに送信する必要がありますサーバーのDUIDを持つオプション、およびクライアントのDUIDを持つクライアント識別子オプション。
With the following text (which addresses the existing erratum [Err2472]):
次のテキスト（既存のエラータ[Err2472]に対処）を使用：
If the server will not assign any addresses to an IA in a subsequent Request from the client, the server MUST include the IA in the Advertise message with no addresses in the IA and a Status Code option encapsulated in the IA containing status code NoAddrsAvail.
サーバーがクライアントからの後続のリクエストでIAにアドレスを割り当てない場合、サーバーはIAにアドレスなしでIAをアドバタイズメッセージに含め、ステータスコードNoAddrsAvailを含むIAにカプセル化されたステータスコードオプションを含める必要があります。
[RFC3315] specifies that a client must ignore an Advertise message if a server will not assign any addresses to a client, and [RFC3633] specifies that a client must ignore an Advertise message if a server returns the NoPrefixAvail status to a requesting router. Thus, a client requesting both IA_NA and IA_PD, with a server that only offers either addresses or delegated prefixes, is not supported by the current protocol specifications.
[RFC3315]は、サーバーがクライアントにアドレスを割り当てない場合、クライアントがアドバタイズメッセージを無視する必要があることを指定し、[RFC3633]は、サーバーが要求側ルーターにNoPrefixAvailステータスを返す場合、クライアントがアドバタイズメッセージを無視する必要があることを指定します。したがって、アドレスまたはデリゲートされたプレフィックスのみを提供するサーバーでIA_NAとIA_PDの両方を要求するクライアントは、現在のプロトコル仕様ではサポートされていません。
Solution: a client SHOULD accept Advertise messages, even when not all IA option types are being offered. And, in this case, the client SHOULD include the not offered IA option types in its Request. A client SHOULD only ignore an Advertise message when none of the requested IA options include offered addresses or delegated prefixes. Note that ignored messages MUST still be processed for SOL_MAX_RT and INF_MAX_RT options as specified in [RFC7083].
解決策：すべてのIAオプションタイプが提供されていない場合でも、クライアントはアドバタイズメッセージを受け入れる必要があります（SHOULD）。そして、この場合、クライアントはリクエストに提供されていないIAオプションタイプを含める必要があります。クライアントは、要求されたIAオプションに提供されたアドレスまたは委任されたプレフィックスが含まれていない場合にのみ、アドバタイズメッセージを無視する必要があります（SHOULD）。 [RFC7083]で指定されているように、無視されたメッセージは引き続きSOL_MAX_RTおよびINF_MAX_RTオプションで処理する必要があることに注意してください。
Replace Section 17.1.3 of RFC 3315: (existing errata)
RFC 3315のセクション17.1.3を置き換えます：（既存のエラッタ）
The client MUST ignore any Advertise message that includes a Status Code option containing the value NoAddrsAvail, with the exception that the client MAY display the associated status message(s) to the user.
クライアントは、値NoAddrsAvailを含むステータスコードオプションを含むアドバタイズメッセージを無視する必要があります。ただし、クライアントは関連するステータスメッセージをユーザーに表示してもよい（MAY）。
With the following text (which addresses the existing erratum [Err2471] and includes the changes made by [RFC7083]):
次のテキスト（既存のエラッタ[Err2471]に対処し、[RFC7083]によって行われた変更を含む）を使用します。
The client MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the client:
クライアントは、アドレス（IA_NAまたはIA_TAオプションにカプセル化されたIAADDRオプション）および委任されたプレフィックス（IA_PDオプションにカプセル化されたIAPREFIXオプション; RFC 3633を参照）を含まないアドバタイズメッセージを無視する必要があります。
- MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083).
- 含まれているSOL_MAX_RTオプション（RFC 7083）を処理する必要があり、-含まれているINF_MAX_RTオプション（RFC 7083）を処理する必要があります。
A client can display any associated status message(s) to the user or activity log.
クライアントは、関連するステータスメッセージをユーザーまたはアクティビティログに表示できます。
The client ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
このアドバタイズメッセージを無視するクライアントは、要請再送信タイマーを再開してはなりません。
And, replace:
そして、置き換えます：
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available addresses advertised in IAs.
- IAでアドバタイズされる使用可能なアドレスなど、アドバタイズされたパラメーターのセットがサーバーにある場合、クライアントは優先度の低いサーバーを選択できます（MAY）。
With:
と：
- The client MAY choose a less-preferred server if that server has a better set of advertised parameters, such as the available set of IAs, as well as the set of other configuration options advertised.
- 利用可能なIAのセットやアドバタイズされた他の構成オプションのセットなど、アドバタイズされたパラメーターのセットがサーバーにある場合、クライアントは優先度の低いサーバーを選択できます（MAY）。
And, replace the last paragraph of Section 11.1 of RFC 3633 with the following text (which addresses the existing erratum [Err2469]):
また、RFC 3633のセクション11.1の最後の段落を次のテキストに置き換えます（既存のエラータ[Err2469]に対応しています）：
The requesting router MUST ignore any Advertise message that contains no addresses (IAADDR options encapsulated in IA_NA or IA_TA options) and no delegated prefixes (IAPREFIX options encapsulated in IA_PD options; see RFC 3633) with the exception that the requesting router:
要求側ルーターは、アドレス（IA_NAまたはIA_TAオプションにカプセル化されたIAADDRオプション）および委任されたプレフィックス（IA_PDオプションにカプセル化されたIAPREFIXオプション。RFC3633を参照）を含まないアドバタイズメッセージを無視する必要があります。
- MUST process an included SOL_MAX_RT option (RFC 7083) and - MUST process an included INF_MAX_RT option (RFC 7083).
- 含まれているSOL_MAX_RTオプション（RFC 7083）を処理する必要があり、-含まれているINF_MAX_RTオプション（RFC 7083）を処理する必要があります。
A client can display any associated status message(s) to the user or activity log.
クライアントは、関連するステータスメッセージをユーザーまたはアクティビティログに表示できます。
The requesting router ignoring this Advertise message MUST NOT restart the Solicit retransmission timer.
このアドバタイズメッセージを無視する要求側ルーターは、要請再送信タイマーを再開してはなりません。
The T1 and T2 times determine when the client will contact the server to extend lifetimes of information received in an IA. How should a client handle the case where multiple IA options have different T1 and T2 times?
T1とT2の時間は、クライアントがサーバーに接続して、IAで受信した情報の有効期間を延長する時期を決定します。複数のIAオプションのT1とT2の時間が異なる場合、クライアントはどのように処理する必要がありますか？
In a multiple IA option type model, the T1/T2 times are protocol timers that should be independent of the IA options themselves. If we were to redo the DHCP protocol from scratch, the T1/T2 times should be carried in a separate DHCP option.
複数のIAオプションタイプのモデルでは、T1 / T2時間はプロトコルタイマーであり、IAオプション自体から独立している必要があります。 DHCPプロトコルを最初からやり直す場合、T1 / T2時間は別のDHCPオプションで実行する必要があります。
Solution: The server MUST set the T1/T2 times in all IA options in a Reply or Advertise message to the same value. To deal with the case where servers have not yet been updated to do that, the client MUST select a T1 and T2 time from all IA options, which will guarantee that the client will send Renew/Rebind messages not later than at the T1/T2 times associated with any of the client's bindings.
解決策：サーバーは、返信またはアドバタイズメッセージのすべてのIAオプションでT1 / T2時間を同じ値に設定する必要があります。サーバーがそれを行うようにまだ更新されていない場合に対処するには、クライアントはすべてのIAオプションからT1およびT2時間を選択する必要があります。これにより、クライアントは遅くともT1 / T2で更新/再バインドメッセージを送信することが保証されます。クライアントのバインディングのいずれかに関連付けられた時間。
As an example, if the client receives a Reply with T1_NA of 3600 / T2_NA of 5760 and T1_PD of 0 / T2_PD of 1800, the client SHOULD use the T1_PD of 0 / T2_PD of 1800. The reason for this is that a T1 of 0 means that the Renew time is at the client's discretion, but this value cannot be greater than the T2 value (1800).
例として、クライアントがT1_NAが3600 / T2_NAが5760でT1_PDが0 / T2_PDが1800の応答を受信した場合、クライアントはT1_PDが0 / T2_PDが1800を使用する必要があります。これは、T1が0であるためです。更新時間はクライアントの裁量によるが、この値はT2値（1800）を超えることはできないことを意味します。
The following paragraph should be added to Sections 18.2.1, 18.2.3, and 18.2.4 of RFC 3315:
次の段落をRFC 3315のセクション18.2.1、18.2.3、および18.2.4に追加する必要があります。
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
Replyの該当する各IAオプションで設定されるT1 / T2時間は、すべてのIAで同じ値でなければなりません。サーバーは、応答内の該当するクライアントのすべてのバインディングでT1 / T2時間を決定する必要があります。これにより、クライアントはすべてのバインディングを同時に更新できます。
Note: This additional paragraph has also been included in the revised text later in this document for Sections 18.2.3 and 18.2.4 of RFC 3315.
注：この追加の段落は、RFC 3315のセクション18.2.3および18.2.4に関するこのドキュメントの後半の改訂テキストにも含まれています。
Changes for client T1/T2 handling are included in Sections 4.4.3 and 4.4.4.
クライアントT1 / T2処理の変更は、セクション4.4.3および4.4.4に含まれています。
This section presents issues with handling multiple IA option types in the context of creation and processing the Renew and Rebind messages. It also introduces relevant updates to [RFC3315] and [RFC3633].
このセクションでは、更新および再バインドメッセージの作成と処理のコンテキストで複数のIAオプションタイプを処理する際の問題について説明します。また、[RFC3315]と[RFC3633]の関連する更新も紹介しています。
In multiple IA option type models, the client may include multiple IA options in the Request message, and the server may create bindings only for a subset of the IA options included by the client. For the IA options in the Request message for which the server does not create the bindings, the server sends the IA options in the Reply message with the NoAddrsAvail or NoPrefixAvail status codes.
複数のIAオプションタイプモデルでは、クライアントは要求メッセージに複数のIAオプションを含めることができ、サーバーはクライアントが含むIAオプションのサブセットに対してのみバインディングを作成できます。サーバーがバインディングを作成しない要求メッセージのIAオプションの場合、サーバーは、応答メッセージのIAオプションをNoAddrsAvailまたはNoPrefixAvailステータスコードとともに送信します。
The client may accept the bindings created by the server, but may desire the other bindings to be created once they become available, e.g., when the server configuration is changed. The client that accepted the bindings created by the server will periodically send a Renew message to extend their lifetimes. However, the Renew message, as described in [RFC3315], does not support the ability for the client to extend the lifetimes of the bindings for some IAs, while requesting bindings for other IAs.
クライアントは、サーバーによって作成されたバインディングを受け入れることができますが、他のバインディングが使用可能になったとき（たとえば、サーバー構成が変更されたとき）に、他のバインディングを作成することを望む場合があります。サーバーによって作成されたバインディングを受け入れたクライアントは、定期的に更新メッセージを送信して、その存続期間を延長します。ただし、[RFC3315]で説明されているように、更新メッセージは、他のIAのバインディングを要求しているときに、クライアントが一部のIAのバインディングのライフタイムを延長する機能をサポートしていません。
Solution: The client, which sends a Renew message to extend the lifetimes of the bindings assigned to the client, SHOULD include IA options for these bindings as well as IA options for all other bindings that the client desires but has been unable to obtain. The client and server processing need to be modified. Note that this change makes the server's IA processing of Renew similar to the Request processing.
解決策：クライアントは、クライアントに割り当てられたバインディングの有効期間を延長するためにRenewメッセージを送信し、これらのバインディングのIAオプションと、クライアントが希望するが取得できなかった他のすべてのバインディングのIAオプションを含める必要があります。クライアントとサーバーの処理を変更する必要があります。この変更により、サーバーの更新のIA処理が要求処理と同様になることに注意してください。
According to Section 4.4.1, the client includes IA options in a Renew message for the bindings it desires but has been unable to obtain by sending a Request message, apart from the IA options for the existing bindings.
セクション4.4.1によると、クライアントは、必要なバインディングの更新メッセージにIAオプションを含めますが、既存のバインディングのIAオプションとは別に、要求メッセージを送信しても取得できませんでした。
At time T2, the client stops sending Renew messages to the server and initiates the Rebind/Reply message exchange with any available server. In this case, it should be possible to continue trying to obtain new bindings using the Rebind message if the client failed to get the response from the server to the Renew message.
時間T2で、クライアントはサーバーへの更新メッセージの送信を停止し、使用可能なサーバーとの再バインド/返信メッセージ交換を開始します。この場合、クライアントがサーバーからRenewメッセージへの応答を取得できなかった場合、Rebindメッセージを使用して新しいバインディングの取得を続行できる可能性があります。
Solution: The client SHOULD continue to include the IA options received from the server, and it MAY include additional IA options to request creation of the additional bindings.
解決策：クライアントは、サーバーから受信したIAオプションを引き続き含めるべきであり（SHOULD）、追加のバインディングの作成を要求する追加のIAオプションを含めることができます（MAY）。
Replace Section 18.1.3 of RFC 3315 with the following text:
RFC 3315のセクション18.1.3を次のテキストに置き換えます。
To extend the valid and preferred lifetimes for the addresses assigned to an IA, the client sends a Renew message to the server from which the addresses were obtained, which includes an IA option for the IA whose address lifetimes are to be extended. The client includes IA Address options within the IA option for the addresses assigned to the IA. The server determines new lifetimes for these addresses according to the administrative configuration of the server. The server may also add new addresses to the IA. The server can remove addresses from the IA by returning IA Address options for such addresses with preferred and valid lifetimes set to 0.
IAに割り当てられたアドレスの有効な優先ライフタイムを延長するために、クライアントはアドレスの取得元のサーバーに更新メッセージを送信します。これには、アドレスライフタイムを延長するIAのIAオプションが含まれます。クライアントには、IAに割り当てられたアドレスのIAオプション内にIAアドレスオプションが含まれています。サーバーは、サーバーの管理構成に従って、これらのアドレスの新しい有効期間を決定します。サーバーは、IAに新しいアドレスを追加することもできます。サーバーは、優先および有効期間が0に設定されたアドレスのIAアドレスオプションを返すことにより、IAからアドレスを削除できます。
The server controls the time at which the client contacts the server to extend the lifetimes on assigned addresses through the T1 and T2 parameters assigned to an IA. However, as the client Renews/Rebinds all IAs from the server at the same time, the client MUST select a T1 and T2 time from all IA options, which will guarantee that the client will send Renew/Rebind messages not later than at the T1/T2 times associated with any of the client's bindings.
サーバーは、クライアントがサーバーに接続して、IAに割り当てられたT1およびT2パラメーターを通じて割り当てられたアドレスの有効期間を延長する時間を制御します。ただし、クライアントはサーバーからすべてのIAを同時に更新/再バインドするため、クライアントはすべてのIAオプションからT1とT2の時間を選択する必要があります。これにより、クライアントは遅くともT1で更新/再バインドメッセージを送信できます。 / T2時間は、クライアントのバインディングのいずれかに関連付けられています。
At time T1, the client initiates a Renew/Reply message exchange to extend the lifetimes on any addresses in the IA.
時間T1で、クライアントは更新/応答メッセージ交換を開始して、IA内の任意のアドレスのライフタイムを延長します。
If T1 or T2 had been set to 0 by the server (for an IA_NA) or there are no T1 or T2 times (for an IA_TA) in a previous Reply, the client may send a Renew or Rebind message, respectively, at the client's discretion.
T1またはT2がサーバーによって0に設定されている場合（IA_NAの場合）、または以前のReplyにT1またはT2時間がない場合（IA_TAの場合）、クライアントは、クライアントの更新メッセージをそれぞれ更新または再バインドします。裁量。
The client sets the "msg-type" field to RENEW. The client generates a transaction ID and inserts this value in the "transaction-id" field.
クライアントは、「msg-type」フィールドをRENEWに設定します。クライアントはトランザクションIDを生成し、この値を「transaction-id」フィールドに挿入します。
The client places the identifier of the destination server in a Server Identifier option.
クライアントは、宛先サーバーの識別子をサーバー識別子オプションに配置します。
The client MUST include a Client Identifier option to identify itself to the server. The client adds any appropriate options, including one or more IA options.
クライアントは、サーバーに対して自身を識別するためのクライアント識別子オプションを含まなければなりません（MUST）。クライアントは、1つ以上のIAオプションを含む、適切なオプションを追加します。
For IAs to which addresses have been assigned, the client includes a corresponding IA option containing an IA Address option for each address assigned to the IA. The client MUST NOT include addresses in any IA option that the client did not obtain from the server or that are no longer valid (that have a valid lifetime of 0).
アドレスが割り当てられたIAの場合、クライアントには、IAに割り当てられた各アドレスのIAアドレスオプションを含む対応するIAオプションが含まれます。クライアントは、クライアントがサーバーから取得しなかった、または有効でなくなった（有効な有効期間が0である）IAオプションにアドレスを含めてはなりません（MUST NOT）。
The client MAY include an IA option for each binding it desires but has been unable to obtain. This IA option MUST NOT contain any addresses. However, it MAY contain the IA Address option with the "IPv6 address" field set to 0 to indicate the client's preference for the preferred and valid lifetimes for any newly assigned addresses.
クライアントは、希望する各バインディングのIAオプションを含めることができますが（MAY）、取得できませんでした。このIAオプションはアドレスを含んではいけません。ただし、「IPv6アドレス」フィールドが0に設定されたIAアドレスオプションを含めて、新しく割り当てられたアドレスの有効な有効期間に対するクライアントの優先順位を示すことができます。
The client MUST include an Option Request option (see section 22.7) to indicate the options the client is interested in receiving. The client MAY include options with data values as hints to the server about parameter values the client would like to have returned.
クライアントは、オプションリクエストオプション（セクション22.7を参照）を含めて、クライアントが受信したいオプションを示す必要があります。クライアントは、クライアントが返したいパラメータ値に関するサーバーへのヒントとして、データ値を持つオプションを含めることができます。
The client transmits the message according to section 14, using the following parameters:
クライアントは、セクション14に従って、次のパラメータを使用してメッセージを送信します。
IRT REN_TIMEOUT
IRT REN_TIMEOUT
MRT REN_MAX_RT
MRT REN_MAX_RT
MRC 0
MRC 0
MRD Remaining time until T2
MRD T2までの残り時間
The message exchange is terminated when time T2 is reached (see section 18.1.4), at which time the client begins a Rebind message exchange.
メッセージ交換は、クライアントが再バインドメッセージ交換を開始する時間T2（セクション18.1.4を参照）に達すると終了します。
Replace Section 18.1.4 of RFC 3315 with the following text:
RFC 3315のセクション18.1.4を次のテキストに置き換えます。
At time T2 (which will only be reached if the server to which the Renew message was sent at time T1 has not responded), the client initiates a Rebind/Reply message exchange with any available server.
時刻T2に（時刻T1に更新メッセージが送信されたサーバーが応答しない場合にのみ到達する）、クライアントは、使用可能なサーバーとの再バインド/応答メッセージ交換を開始します。
The client constructs the Rebind message as described in section 18.1.3 with the following differences:
クライアントは、セクション18.1.3で説明されているようにRebindメッセージを作成しますが、次の違いがあります。
- The client sets the "msg-type" field to REBIND.
- クライアントは、「msg-type」フィールドをREBINDに設定します。
- The client does not include the Server Identifier option in the Rebind message.
- クライアントは、サーバー識別子オプションを再バインドメッセージに含めません。
The client transmits the message according to section 14, using the following parameters:
クライアントは、セクション14に従って、次のパラメータを使用してメッセージを送信します。
IRT REB_TIMEOUT
IRT REB_TIMEOUT
MRT REB_MAX_RT
MRT REB_MAX_RT
MRC 0
MRC 0
MRD Remaining time until valid lifetimes of all addresses in all IAs have expired
MRDすべてのIAのすべてのアドレスの有効な有効期限が切れるまでの残り時間
If all addresses for an IA have expired, the client may choose to include this IA without any addresses (or with only a hint for lifetimes) in subsequent Rebind messages to indicate that the client is interested in assignment of the addresses to this IA.
IAのすべてのアドレスの有効期限が切れている場合、クライアントは、このIAをアドレスなしで（またはライフタイムのヒントのみを使用して）後続のRebindメッセージに含めることを選択して、クライアントがこのIAへのアドレスの割り当てに関心があることを示します。
The message exchange is terminated when the valid lifetimes of all addresses across all IAs have expired, at which time the client uses the Solicit message to locate a new DHCP server and sends a Request for the expired IAs to the new server.
メッセージ交換は、すべてのIAにまたがるすべてのアドレスの有効な有効期限が切れると終了します。このとき、クライアントは要請メッセージを使用して新しいDHCPサーバーを見つけ、期限切れのIAのリクエストを新しいサーバーに送信します。
Replace Section 18.1.8 of RFC 3315 with the following text:
RFC 3315のセクション18.1.8を次のテキストに置き換えます。
Upon the receipt of a valid Reply message in response to a Solicit (with a Rapid Commit option), Request, Confirm, Renew, Rebind, or Information-request message, the client extracts the configuration information contained in the Reply. The client MAY choose to report any status code or message from the Status Code option in the Reply message.
クライアントは、（Rapid Commitオプションを使用した）Solicit、Request、Confirm、Renew、Rebind、またはInformation-requestメッセージへの応答として有効なReplyメッセージを受信すると、Replyに含まれている構成情報を抽出します。クライアントは、返信メッセージのステータスコードオプションから、ステータスコードまたはメッセージを報告することを選択できます。
If the client receives a Reply message with a status code containing UnspecFail, the server is indicating that it was unable to process the message due to an unspecified failure condition. If the client retransmits the original message to the same server to retry the desired operation, the client MUST limit the rate at which it retransmits the message and limit the duration of the time during which it retransmits the message.
クライアントがUnspecFailを含むステータスコードを含むReplyメッセージを受信した場合、サーバーは、不特定の障害条件のためにメッセージを処理できなかったことを示しています。クライアントが元のメッセージを同じサーバーに再送信して目的の操作を再試行する場合、クライアントはメッセージを再送信する速度を制限し、メッセージを再送信する時間の長さを制限する必要があります。
When the client receives a Reply message with a Status Code option with the value UseMulticast, the client records the receipt of the message and sends subsequent messages to the server through the interface on which the message was received using multicast. The client resends the original message using multicast.
クライアントが値UseMulticastのステータスコードオプションを含む返信メッセージを受信すると、クライアントはメッセージの受信を記録し、マルチキャストを使用してメッセージが受信されたインターフェイスを介して後続のメッセージをサーバーに送信します。クライアントはマルチキャストを使用して元のメッセージを再送信します。
When the client receives a NotOnLink status from the server in response to a Confirm message, the client performs DHCP server solicitation, as described in section 17, and client-initiated configuration, as described in section 18. If the client receives any Reply messages that do not indicate a NotOnLink status, the client can use the addresses in the IA and ignore any messages that indicate a NotOnLink status.
クライアントが確認メッセージに応答してサーバーからNotOnLinkステータスを受信すると、クライアントは、セクション17で説明されているようにDHCPサーバー要請を実行し、セクション18で説明されているように、クライアントが開始した構成を実行します。 NotOnLinkステータスを示さない場合、クライアントはIAのアドレスを使用して、NotOnLinkステータスを示すメッセージを無視できます。
When the client receives a NotOnLink status from the server in response to a Request, the client can either reissue the Request without specifying any addresses or restart the DHCP server discovery process (see section 17).
クライアントがリクエストへの応答としてサーバーからNotOnLinkステータスを受信すると、クライアントはアドレスを指定せずにリクエストを再発行するか、DHCPサーバー検出プロセスを再起動できます（セクション17を参照）。
The client SHOULD perform duplicate address detection [17] on each of the received addresses in any IAs, on which it has not performed duplicate address detection during processing of any of the previous Reply messages from the server. The client performs the duplicate address detection before using the received addresses for the traffic. If any of the addresses are found to be in use on the link, the client sends a Decline message to the server for those addresses as described in section 18.1.7.
クライアントは、サーバーからの以前の応答メッセージの処理中に重複アドレス検出を実行していないIAで、受信した各アドレスに対して重複アドレス検出[17]を実行する必要があります（SHOULD）。クライアントは、受信したアドレスをトラフィックに使用する前に、重複アドレス検出を実行します。リンクで使用されているアドレスが見つかった場合、クライアントは、セクション18.1.7で説明されているように、それらのアドレスのDeclineメッセージをサーバーに送信します。
If the Reply was received in response to a Solicit (with a Rapid Commit option), Request, Renew, or Rebind message, the client updates the information it has recorded about IAs from the IA options contained in the Reply message:
Solicit（Rapid Commitオプション付き）、Request、Renew、またはRebindメッセージへの応答としてReplyが受信された場合、クライアントはReplyメッセージに含まれるIAオプションからIAについて記録した情報を更新します。
- Record T1 and T2 times.
- T1およびT2時間を記録します。
- Add any new addresses in the IA option to the IA as recorded by the client.
- クライアントが記録したIAオプションの新しいアドレスをIAに追加します。
- Update lifetimes for any addresses in the IA option that the client already has recorded in the IA.
- クライアントがすでにIAに記録しているIAオプションのアドレスのライフタイムを更新します。
- Discard any addresses from the IA, as recorded by the client, that have a valid lifetime of 0 in the IA Address option.
- IAアドレスオプションで有効期間が0である、クライアントによって記録されたIAからのアドレスを破棄します。
- Leave unchanged any information about addresses the client has recorded in the IA but that were not included in the IA from the server.
- クライアントがIAに記録したが、サーバーからのIAに含まれていなかったアドレスに関する情報は変更しないでください。
Management of the specific configuration information is detailed in the definition of each option in section 22.
特定の構成情報の管理については、セクション22の各オプションの定義で詳しく説明しています。
The client examines the status code in each IA individually. If the client receives a NoAddrsAvail status code, the client has received no usable addresses in the IA.
クライアントは、各IAのステータスコードを個別に調べます。クライアントがNoAddrsAvailステータスコードを受け取った場合、クライアントはIAで使用可能なアドレスを受け取っていません。
If the client can operate with the addresses obtained from the server, the client uses addresses and other information from any IAs that do not contain a Status Code option with the NoAddrsAvail status code. The client MAY include the IAs for which it received the NoAddrsAvail status code, with no addresses, in subsequent Renew and Rebind messages sent to the server, to retry obtaining the addresses for these IAs.
クライアントがサーバーから取得したアドレスで動作できる場合、クライアントは、NoAddrsAvailステータスコードを持つステータスコードオプションを含まないIAからのアドレスおよびその他の情報を使用します。クライアントは、サーバーに送信される後続のRenewおよびRebindメッセージに、アドレスなしでNoAddrsAvailステータスコードを受け取ったIAを含めて、これらのIAのアドレスの取得を再試行してもよい（MAY）。
If the client cannot operate without the addresses for the IAs for which it received the NoAddrsAvail status code, the client may try another server (perhaps by restarting the DHCP server discovery process).
クライアントがNoAddrsAvailステータスコードを受け取ったIAのアドレスなしで動作できない場合、クライアントは別のサーバーを試行する可能性があります（おそらくDHCPサーバーの検出プロセスを再起動することにより）。
If the client finds no usable addresses in any of the IAs, it may either try another server (perhaps restarting the DHCP server discovery process) or use the Information-request message to obtain other configuration information only.
クライアントがどのIAでも使用可能なアドレスを見つけられない場合、別のサーバーを試すか（おそらくDHCPサーバーの検出プロセスを再起動する）、情報要求メッセージを使用して他の構成情報のみを取得します。
When the client receives a Reply message in response to a Renew or Rebind message, the client:
クライアントがRenewまたはRebindメッセージへの応答としてReplyメッセージを受信すると、クライアントは次のことを行います。
- sends a Request message if any of the IAs in the Reply message contains the NoBinding status code. The client places IA options in this message for only those IAs for which the server returned the NoBinding status code in the Reply message. The client continues to use other bindings for which the server did not return an error.
- Replyメッセージ内のIAのいずれかにNoBindingステータスコードが含まれている場合、Requestメッセージを送信します。クライアントは、サーバーが応答メッセージでNoBindingステータスコードを返したIAに対してのみ、このメッセージにIAオプションを配置します。クライアントは、サーバーがエラーを返さなかった他のバインディングを引き続き使用します。
- sends a Renew/Rebind if any of the IAs are not in the Reply message, but in this case the client MUST limit the rate at which it sends these messages, to avoid the Renew/Rebind storm.
- いずれかのIAがReplyメッセージにない場合は、Renew / Rebindを送信しますが、この場合、クライアントは、Renew / Rebindストームを回避するために、これらのメッセージを送信するレートを制限する必要があります。
- otherwise accepts the information in the IA.
- それ以外の場合、IAの情報を受け入れます。
When the client receives a valid Reply message in response to a Release message, the client considers the Release event completed, regardless of the Status Code option(s) returned by the server.
クライアントは、Releaseメッセージに応答して有効なReplyメッセージを受信すると、サーバーから返されたステータスコードオプションに関係なく、Releaseイベントが完了したと見なします。
When the client receives a valid Reply message in response to a Decline message, the client considers the Decline event completed, regardless of the Status Code option(s) returned by the server.
クライアントがDeclineメッセージに応答して有効なReplyメッセージを受信すると、サーバーから返されたステータスコードオプションに関係なく、クライアントはDeclineイベントが完了したと見なします。
Replace Section 18.2.3 of RFC 3315 with the following text:
RFC 3315のセクション18.2.3を次のテキストに置き換えます。
When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast, a Server Identifier option containing the server's DUID, the Client Identifier option from the client message, and no other options.
サーバーがユニキャストオプションを送信していないクライアントからユニキャスト経由でRenewメッセージを受信すると、サーバーはRenewメッセージを破棄し、値UseMulticastを含むステータスコードオプションを含む返信メッセージで応答します。サーバーのDUID、クライアントメッセージのクライアント識別子オプション、その他のオプションはありません。
For each IA in the Renew message from a client, the server locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
サーバーは、クライアントからの更新メッセージ内の各IAについて、クライアントのバインディングを特定し、クライアントからのIA内の情報がそのクライアント用に保存されている情報と一致することを確認します。
If the server finds the client entry for the IA, the server sends back the IA to the client with new lifetimes and, if applicable, T1/T2 times. If the server is unable to extend the lifetimes of an address in the IA, the server MAY choose not to include the IA Address option for this address.
サーバーがIAのクライアントエントリを見つけた場合、サーバーはIAを新しい有効期間と、該当する場合はT1 / T2回、クライアントに送り返します。サーバーがIAのアドレスの有効期間を延長できない場合、サーバーはこのアドレスにIAアドレスオプションを含めないことを選択できます（MAY）。
The server may choose to change the list of addresses and the lifetimes of addresses in IAs that are returned to the client.
サーバーは、クライアントに返されるIAのアドレスのリストとアドレスの有効期間を変更することを選択できます。
If the server finds that any of the addresses in the IA are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0.
サーバーが、IA内のいずれかのアドレスがクライアントが接続されているリンクに適切でないことを検出した場合、サーバーはライフタイム0のアドレスをクライアントに返します。
For each IA for which the server cannot find a client entry, the server has the following choices depending on the server's policy and configuration information:
サーバーがクライアントエントリを見つけられないIAごとに、サーバーのポリシーと構成情報に応じて、サーバーには次の選択肢があります。
- If the server is configured to create new bindings as a result of processing Renew messages, the server SHOULD create a binding and return the IA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in the IA Address option (if included) as a hint.
- サーバーがRenewメッセージの処理の結果として新しいバインディングを作成するように構成されている場合、サーバーはバインディングを作成し、ライフタイムと、該当する場合はT1 / T2時間とクライアントから要求されたその他の情報を割り当てられたアドレスとともにIAを返す必要があります。サーバーは、IAアドレスオプション（含まれている場合）の値をヒントとして使用できます（MAY）。
- If the server is configured to create new bindings as a result of processing Renew messages, but the server will not assign any addresses to an IA, the server returns the IA option containing a Status Code option with the NoAddrsAvail status code and a status message for a user.
- サーバーが更新メッセージの処理の結果として新しいバインディングを作成するように構成されているが、サーバーがIAにアドレスを割り当てない場合、サーバーはNoAddrsAvailステータスコードとステータスメッセージを含むステータスコードオプションを含むIAオプションを返します。ユーザー。
- If the server does not support creation of new bindings for the client sending a Renew message, or if this behavior is disabled according to the server's policy or configuration information, the server returns the IA option containing a Status Code option with the NoBinding status code and a status message for a user.
- サーバーがRenewメッセージを送信するクライアントの新しいバインディングの作成をサポートしていない場合、またはサーバーのポリシーまたは構成情報に従ってこの動作が無効になっている場合、サーバーはNoBindingステータスコードとステータスコードオプションを含むIAオプションを返します。ユーザーのステータスメッセージ。
The server constructs a Reply message by setting the "msg-type" field to REPLY and copying the transaction ID from the Renew message into the "transaction-id" field.
サーバーは、「msg-type」フィールドをREPLYに設定し、トランザクションIDをRenewメッセージから「transaction-id」フィールドにコピーすることにより、応答メッセージを作成します。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message.
サーバーは、サーバーのDUIDを含むサーバー識別子オプションと、返信メッセージの更新メッセージからのクライアント識別子オプションを含める必要があります。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
サーバーには、セクション18.2で説明されているように、クライアントに返される構成情報を含む他のオプションが含まれています。
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
Replyの該当する各IAオプションで設定されるT1 / T2時間は、すべてのIAで同じ値でなければなりません。サーバーは、応答内の該当するクライアントのすべてのバインディングでT1 / T2時間を決定する必要があります。これにより、クライアントはすべてのバインディングを同時に更新できます。
Replace Section 18.2.4 of RFC 3315 with the following text:
RFC 3315のセクション18.2.4を次のテキストに置き換えます。
When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client.
サーバーは、クライアントからIAオプションを含む再バインドメッセージを受信すると、クライアントのバインディングを特定し、クライアントからのIA内の情報がそのクライアント用に保存されている情報と一致することを確認します。
If the server finds the client entry for the IA and the server determines that the addresses in the IA are appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server SHOULD send back the IA to the client with new lifetimes and, if applicable, T1/T2 times. If the server is unable to extend the lifetimes of an address in the IA, the server MAY choose not to include the IA Address option for this address.
サーバーがIAのクライアントエントリを見つけ、サーバーのIA内のアドレスが、サーバーの明示的な構成情報に従ってクライアントのインターフェイスが接続されているリンクに適切であると判断した場合、サーバーはIAをクライアントに返信する必要があります（SHOULD）。新しい有効期間、および該当する場合はT1 / T2倍。サーバーがIAのアドレスの有効期間を延長できない場合、サーバーはこのアドレスにIAアドレスオプションを含めないことを選択できます（MAY）。
If the server finds that the client entry for the IA and any of the addresses are no longer appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server returns the address to the client with lifetimes of 0.
サーバーは、IAのクライアントエントリとアドレスのいずれかがサーバーの明示的な構成情報に従ってクライアントのインターフェイスが接続されているリンクに適切ではなくなっていることを検出すると、ライフタイム0のアドレスをクライアントに返します。 。
If the server cannot find a client entry for the IA, the IA contains addresses and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to 0. This Reply constitutes an explicit notification to the client that the addresses in the IA are no longer valid. In this situation, if the server does not send a Reply message, it silently discards the Rebind message.
サーバーがIAのクライアントエントリを見つけられない場合、IAにはアドレスが含まれ、サーバーのIA内のアドレスは、サーバーの明示的な構成情報に従ってクライアントのインターフェイスが接続されているリンクに適切ではないと判断し、サーバーはクライアントのIAを含むクライアントに、IAのアドレスの有効期間を0に設定して返信メッセージを送信します。この返信は、IAのアドレスが無効になったことをクライアントに明示的に通知します。この状況で、サーバーが返信メッセージを送信しない場合、サーバーは再バインドメッセージを通知せずに破棄します。
Otherwise, for each IA for which the server cannot find a client entry, the server has the following choices depending on the server's policy and configuration information:
それ以外の場合、サーバーがクライアントエントリを見つけられないIAごとに、サーバーのポリシーと構成情報に応じて、サーバーは次の選択肢を持ちます。
- If the server is configured to create new bindings as a result of processing Rebind messages (also see the note about the Rapid Commit option below), the server SHOULD create a binding and return the IA with allocated addresses with lifetimes and, if applicable, T1/T2 times and other information requested by the client. The server MAY use values in the IA Address option (if included) as a hint.
- サーバーが再バインドメッセージの処理の結果として新しいバインディングを作成するように構成されている場合（以下のラピッドコミットオプションに関する注意も参照）、サーバーはバインディングを作成し、ライフタイムと、該当する場合はT1で割り当てられたアドレスを持つIAを返す必要があります（SHOULD）。 / T2回およびクライアントから要求されたその他の情報。サーバーは、IAアドレスオプション（含まれている場合）の値をヒントとして使用できます（MAY）。
- If the server is configured to create new bindings as a result of processing Rebind messages, but the server will not assign any addresses to an IA, the server returns the IA option containing a Status Code option with the NoAddrsAvail status code and a status message for a user.
- サーバーが再バインドメッセージの処理の結果として新しいバインディングを作成するように構成されているが、サーバーがIAにアドレスを割り当てない場合、サーバーはNoAddrsAvailステータスコードとステータスメッセージを含むステータスコードオプションを含むIAオプションを返します。ユーザー。
- If the server does not support creation of new bindings for the client sending a Rebind message, or if this behavior is disabled according to the server's policy or configuration information, the server returns the IA option containing a Status Code option with the NoBinding status code and a status message for a user.
- サーバーがRebindメッセージを送信するクライアントの新しいバインディングの作成をサポートしていない場合、またはサーバーのポリシーまたは構成情報に従ってこの動作が無効になっている場合、サーバーはNoBindingステータスコードとステータスコードオプションを含むIAオプションを返します。ユーザーのステータスメッセージ。
When the server creates new bindings for the IA, it is possible that other servers also create bindings as a result of receiving the same Rebind message. This is the same issue as in the Discussion under "Rapid Commit Option"; see section 22.14. Therefore, the server SHOULD only create new bindings during processing of a Rebind message if the server is configured to respond with a Reply message to a Solicit message containing the Rapid Commit option.
サーバーがIAの新しいバインディングを作成するときに、同じRebindメッセージを受信した結果、他のサーバーもバインディングを作成する可能性があります。これは、「Rapid Commit Option」の説明と同じ問題です。セクション22.14を参照してください。したがって、サーバーは、Rapid Commitオプションを含むSolicitメッセージに返信メッセージで応答するようにサーバーが構成されている場合、再バインドメッセージの処理中にのみ新しいバインディングを作成する必要があります（SHOULD）。
The server constructs a Reply message by setting the "msg-type" field to REPLY and copying the transaction ID from the Rebind message into the "transaction-id" field.
サーバーは、「msg-type」フィールドをREPLYに設定し、トランザクションIDをRebindメッセージから「transaction-id」フィールドにコピーすることにより、応答メッセージを作成します。
The server MUST include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message.
サーバーは、サーバーのDUIDを含むサーバー識別子オプションと、返信メッセージの再バインドメッセージからのクライアント識別子オプションを含める必要があります。
The server includes other options containing configuration information to be returned to the client as described in section 18.2.
サーバーには、セクション18.2で説明されているように、クライアントに返される構成情報を含む他のオプションが含まれています。
The T1/T2 times set in each applicable IA option for a Reply MUST be the same values across all IAs. The server MUST determine the T1/T2 times across all of the applicable client's bindings in the Reply. This facilitates the client being able to renew all of the bindings at the same time.
Replyの該当する各IAオプションで設定されるT1 / T2時間は、すべてのIAで同じ値でなければなりません。サーバーは、応答内の該当するクライアントのすべてのバインディングでT1 / T2時間を決定する必要があります。これにより、クライアントはすべてのバインディングを同時に更新できます。
Replace the following text in Section 12.1 of RFC 3633:
RFC 3633のセクション12.1の次のテキストを置き換えます。
Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.
各プレフィックスには有効期間と優先ライフタイムがあり、その期間はそのプレフィックスのIA_PDプレフィックスオプションで指定されます。要求側ルーターは、更新メッセージと再バインドメッセージを使用して、委任されたプレフィックスの有効期間の延長を要求します。
With:
と：
Each prefix has valid and preferred lifetimes whose durations are specified in the IA_PD Prefix option for that prefix. The requesting router uses Renew and Rebind messages to request the extension of the lifetimes of a delegated prefix.
各プレフィックスには有効期間と優先ライフタイムがあり、その期間はそのプレフィックスのIA_PDプレフィックスオプションで指定されます。要求側ルーターは、更新メッセージと再バインドメッセージを使用して、委任されたプレフィックスの有効期間の延長を要求します。
The requesting router MAY include IA_PD options without any prefixes, i.e., without an IA Prefix option or with the IPv6 prefix field of the IA Prefix option set to 0, in a Renew or Rebind message to obtain bindings it desires but has been unable to obtain. The requesting router MAY set the "prefix-length" field of the IA Prefix option as a hint to the server. As in [RFC3315], the requesting router MAY also provide lifetime hints in the IA Prefix option.
要求しているルーターは、プレフィックスなしで、つまりIAプレフィックスオプションなしで、またはIAプレフィックスオプションのIPv6プレフィックスフィールドを0に設定して、希望するバインディングを取得するために更新メッセージまたは再バインドメッセージにIA_PDオプションを含めることができます（MAY）。 。要求側ルーターは、サーバーへのヒントとして、IAプレフィックスオプションの「プレフィックス長」フィールドを設定してもよい（MAY）。 [RFC3315]と同様に、要求側ルーターもIAプレフィックスオプションで有効期間のヒントを提供できます（MAY）。
Replace the following text in Section 12.2 of RFC 3633:
RFC 3633のセクション12.2の次のテキストを置き換えます。
The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD:
委任ルーターは、要求元ルーターのIA_PDのバインディングが見つからない場合、次のように動作します。
With:
と：
For the Renew or Rebind, if the IA_PD contains no IA Prefix option or it contains an IA Prefix option with the IPv6 prefix field set to 0, the delegating router SHOULD assign prefixes to the IA_PD according to the delegating router's explicit configuration information. In this case, if the IA_PD contains an IA Prefix option with the IPv6 prefix field set to 0, the delegating router MAY use the value in the "prefix-length" field of the IA Prefix option as a hint for the length of the prefixes to be assigned. The delegating router MAY also respect lifetime hints provided by the requesting router in the IA Prefix option.
更新または再バインドの場合、IA_PDにIAプレフィックスオプションが含まれていないか、IPv6プレフィックスフィールドが0に設定されたIAプレフィックスオプションが含まれている場合、委任ルーターは、委任ルーターの明示的な構成情報に従ってプレフィックスをIA_PDに割り当てる必要があります。この場合、IA_PDに、IPv6プレフィックスフィールドが0に設定されたIAプレフィックスオプションが含まれている場合、委任ルーターは、プレフィックスの長さのヒントとしてIAプレフィックスオプションの「プレフィックス長」フィールドの値を使用できます（MAY）。割り当てられる。委任ルーターは、要求側ルーターがIAプレフィックスオプションで提供するライフタイムヒントも尊重してもよい（MAY）。
The delegating router behaves as follows when it cannot find a binding for the requesting router's IA_PD containing prefixes:
委任ルーターは、プレフィックスを含む要求側ルーターのIA_PDのバインディングが見つからない場合、次のように動作します。
The Confirm message, as described in [RFC3315], is specific to address assignment. It allows a server without a binding to reply to the message, under the assumption that the server only needs knowledge about the prefix(es) on the link, to inform the client that the address is likely valid or not. This message is sent when, e.g., the client has moved and needs to validate its addresses. Not all bindings can be validated by servers and the Confirm message provides for this by specifying that a server that is unable to determine the on-link status MUST NOT send a Reply.
[RFC3315]で説明されているように、確認メッセージはアドレス割り当てに固有です。これにより、サーバーはリンクのプレフィックスに関する知識しか必要としないという前提の下で、バインディングのないサーバーがメッセージに返信できるようになり、アドレスが有効であるかどうかをクライアントに通知します。このメッセージは、たとえばクライアントが移動し、そのアドレスを検証する必要がある場合に送信されます。サーバーによってすべてのバインディングを検証できるわけではありません。確認メッセージは、オンリンクステータスを判別できないサーバーが応答を送信してはならないことを指定することによってこれを提供します。
Note: Confirm has a specific meaning and does not overload Renew/ Rebind. It also has a lower processing cost as the server does NOT need to extend lease times or otherwise send back other configuration options.
注：確認には特定の意味があり、更新/再バインドの過負荷にはなりません。また、サーバーがリース時間を延長したり、他の構成オプションを送信したりする必要がないため、処理コストも低くなります。
The Confirm message is used by the client to verify that it has not moved to a different link. For IAs with addresses, the mechanism used to verify if a client has moved or not is by matching the link's on-link prefix(es) (typically a /64) against the prefix-length first bits of the addresses provided by the client in the IA_NA or IA_TA IA-types. As a consequence, Confirm can only be used when the client has an IA with an address(es) (IA_NA or IA_TA).
クライアントは確認メッセージを使用して、別のリンクに移動していないことを確認します。アドレスを持つIAの場合、クライアントが移動したかどうかを確認するために使用されるメカニズムは、リンクのオンリンクプレフィックス（通常は/ 64）を、クライアントが提供するアドレスのプレフィックス長の最初のビットと照合することです。 IA_NAまたはIA_TA IAタイプ。結果として、確認は、クライアントにアドレス（IA_NAまたはIA_TA）を持つIAがある場合にのみ使用できます。
A client MUST have a binding including an IA with addresses to use the Confirm message. A client with IAs with addresses as well as other IA-types MAY, depending on the IA-type, use the Confirm message to detect if the client has moved to a different link. A client that does not have a binding with an IA with addresses MUST use the Rebind message instead.
クライアントは、確認メッセージを使用するためのアドレスを持つIAを含むバインディングを持つ必要があります。他のIAタイプと同様にアドレスを持つIAを持つクライアントは、IAタイプに応じて、クライアントが別のリンクに移動したかどうかを確認するために確認メッセージを使用できます。アドレスを持つIAとのバインディングがないクライアントは、代わりにRebindメッセージを使用する必要があります。
IA_PD requires verification that the delegating router (server) has the binding for the IAs. In that case, a requesting router (client) MUST use the Rebind message in place of the Confirm message and it MUST include all of its bindings, even address IAs.
IA_PDは、委任ルーター（サーバー）がIAのバインディングを持っていることの確認を必要とします。その場合、要求側ルーター（クライアント）は、確認メッセージの代わりに再バインドメッセージを使用する必要があり、IAのアドレスも含めて、すべてのバインディングを含める必要があります。
Note that Section 18.1.2 of RFC 3315 states that a client MUST initiate a Confirm when it may have moved to a new link. This is relaxed to a SHOULD as a client may have determined whether it has or has not moved using other techniques, such as described in [RFC6059]. And, as stated above, a client with delegated prefixes MUST send a Rebind instead of a Confirm.
RFC 3315のセクション18.1.2は、クライアントが新しいリンクに移動した可能性がある場合は確認を開始する必要があると述べていることに注意してください。 [RFC6059]で説明されているように、クライアントが他の手法を使用して移動したかどうかを判断している可能性があるため、これはSHOULDに緩和されています。また、前述のように、デリゲートされたプレフィックスを持つクライアントは、確認ではなく再バインドを送信する必要があります。
Some client implementations have been found to send a Release message for other bindings they may have received after they determine a conflict and have correctly sent a Decline message for the conflicting address(es).
一部のクライアント実装は、競合を判別し、競合するアドレスに対してDeclineメッセージを正しく送信した後で、受信した他のバインディングに対してReleaseメッセージを送信することが判明しています。
A client SHOULD NOT send a Release message for other bindings it may have received just because it sent a Decline message. The client SHOULD retain the non-conflicting bindings. The client SHOULD treat the failure to acquire a binding as a result of the conflict, to be equivalent to not having received the binding, insofar as it behaves when sending Renew and Rebind messages.
クライアントは、拒否メッセージを送信したという理由だけで受信した他のバインディングのリリースメッセージを送信してはなりません（SHOULD NOT）。クライアントは、競合しないバインディングを保持する必要があります（SHOULD）。クライアントは、競合の結果としてのバインディングの取得の失敗を、RenewおよびRebindメッセージを送信するときに動作する限り、バインディングを受信していないことと同等に扱う必要があります（SHOULD）。
This document has assumed that all DHCP servers on a network are in a single provisioning domain and thus should be "equal" in the service that they offer. This was also assumed by [RFC3315] and [RFC3633].
このドキュメントでは、ネットワーク上のすべてのDHCPサーバーが単一のプロビジョニングドメイン内にあるため、それらのDHCPサーバーが提供するサービスは「同等」であると想定しています。これは、[RFC3315]と[RFC3633]でも想定されていました。
One could envision a network where the DHCP servers are in multiple provisioning domains, and it may be desirable to have the DHCP client obtain different IA-types from different provisioning domains. How a client detects the multiple provisioning domains and how it would interact with the multiple servers in these different domains is outside the scope of this document (see [MPVD-ARCH] and [DHCPv6-SUPPORT]).
DHCPサーバーが複数のプロビジョニングドメインにあるネットワークを想定できます。DHCPクライアントに、異なるプロビジョニングドメインから異なるIAタイプを取得させることが望ましい場合があります。クライアントが複数のプロビジョニングドメインを検出する方法、およびクライアントがこれらの異なるドメイン内の複数のサーバーと対話する方法は、このドキュメントの範囲外です（[MPVD-ARCH]および[DHCPv6-SUPPORT]を参照）。
There are no new security considerations pertaining to this document.
このドキュメントに関連する新しいセキュリティ上の考慮事項はありません。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<http://www.rfc-editor.org/info/ rfc2119>。
[RFC3315] Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, DOI 10.17487/RFC3315, July 2003, <http://www.rfc-editor.org/info/rfc3315>.
[RFC3315] Droms、R.、Ed。、Bound、J.、Volz、B.、Lemon、T.、Perkins、C.、and M. Carney、 "Dynamic Host Configuration Protocol for IPv6（DHCPv6）"、RFC 3315 、DOI 10.17487 / RFC3315、2003年7月、<http://www.rfc-editor.org/info/rfc3315>。
[RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) version 6", RFC 3633, DOI 10.17487/RFC3633, December 2003, <http://www.rfc-editor.org/info/rfc3633>.
[RFC3633] Troan、O。およびR. Droms、「動的ホスト構成プロトコル（DHCP）バージョン6のIPv6プレフィックスオプション」、RFC 3633、DOI 10.17487 / RFC3633、2003年12月、<http：//www.rfc-editor。 org / info / rfc3633>。
[RFC7083] Droms, R., "Modification to Default Values of SOL_MAX_RT and INF_MAX_RT", RFC 7083, DOI 10.17487/RFC7083, November 2013, <http://www.rfc-editor.org/info/rfc7083>.
[RFC7083] Droms、R。、「SOL_MAX_RTおよびINF_MAX_RTのデフォルト値への変更」、RFC 7083、DOI 10.17487 / RFC7083、2013年11月、<http://www.rfc-editor.org/info/rfc7083>。
[DHCPv6] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., and T. Lemon, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6) bis", Work in Progress, draft-ietf-dhc-rfc3315bis-00, March 2015.
[DHCPv6] Mrugalski、T.、Siodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S。、およびT. Lemon、「IPv6の動的ホスト構成プロトコル（DHCPv6）bis」 、Work in Progress、draft-ietf-dhc-rfc3315bis-00、2015年3月。
[DHCPv6-SUPPORT] Krishnan, S., Korhonen, J., and S. Bhandari, "Support for multiple provisioning domains in DHCPv6", Work in Progress, draft-ietf-mif-mpvd-dhcp-support-01, March 2015.
[DHCPv6-SUPPORT]クリシュナン、S.、Korhonen、J。、およびS. Bhandari、「DHCPv6での複数のプロビジョニングドメインのサポート」、作業中、draft-ietf-mif-mpvd-dhcp-support-01、2015年3月。
[Err2469] RFC Errata, Errata ID 2469, RFC 3633, <http://www.rfc-editor.org>.
[Err2469] RFC Errata、Errata ID 2469、RFC 3633、<http://www.rfc-editor.org>。
[Err2471] RFC Errata, Errata ID 2471, RFC 3315, <http://www.rfc-editor.org>.
[Err2471] RFC Errata、Errata ID 2471、RFC 3315、<http://www.rfc-editor.org>。
[Err2472] RFC Errata, Errata ID 2472, RFC 3315, <http://www.rfc-editor.org>.
[Err2472] RFC Errata、Errata ID 2472、RFC 3315、<http://www.rfc-editor.org>。
[MPVD-ARCH] Anipko, D., "Multiple Provisioning Domain Architecture", Work in Progress, draft-ietf-mif-mpvd-arch-11, March 2015.
[MPVD-ARCH] Anipko、D。、「Multiple Provisioning Domain Architecture」、Work in Progress、draft-ietf-mif-mpvd-arch-11、2015年3月。
[RFC6059] Krishnan, S. and G. Daley, "Simple Procedures for Detecting Network Attachment in IPv6", RFC 6059, DOI 10.17487/RFC6059, November 2010, <http://www.rfc-editor.org/info/rfc6059>.
[RFC6059] Krishnan、S。およびG. Daley、「IPv6でネットワーク接続を検出するための簡単な手順」、RFC 6059、DOI 10.17487 / RFC6059、2010年11月、<http://www.rfc-editor.org/info/rfc6059 >。
[RFC7084] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, DOI 10.17487/RFC7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C。、およびB. Stark、「IPv6カスタマーエッジルーターの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<http：// www .rfc-editor.org / info / rfc7084>。
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and S. Krishnan, "Guidelines for Creating New DHCPv6 Options", BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014, <http://www.rfc-editor.org/info/rfc7227>.
[RFC7227] Hankins、D.、Mrugalski、T.、Siodelski、M.、Jiang、S。、およびS. Krishnan、「新しいDHCPv6オプションを作成するためのガイドライン」、BCP 187、RFC 7227、DOI 10.17487 / RFC7227、2014年5月、<http://www.rfc-editor.org/info/rfc7227>。
Acknowledgements
謝辞
Thanks to the many people that contributed to identify the stateful issues addressed by this document and for reviewing drafts of this document, including Ralph Droms, John Brzozowski, Ted Lemon, Hemant Singh, Wes Beebee, Gaurau Halwasia, Bud Millword, Tim Winters, Rob Shakir, Jinmei Tatuya, Andrew Yourtchenko, Fred Templin, Tomek Mrugalski, Suresh Krishnan, and Ian Farrer.
このドキュメントで取り上げられているステートフルな問題を特定し、このドキュメントのドラフトをレビューするために貢献してくれた多くの人々に感謝します。 Shakir、Jinmei Tatuya、Andrew Yourtchenko、Fred Templin、Tomek Mrugalski、Suresh Krishnan、Ian Farrer。
Authors' Addresses
著者のアドレス
Ole Troan Cisco Systems, Inc. Philip Pedersens vei 20 N-1324 Lysaker Norway
Ole Troan Cisco Systems、Inc. Philip Pedersens vei 20 N-1324 Lysaker Norway
EMail: ot@cisco.com
Bernie Volz Cisco Systems, Inc. 1414 Massachusetts Ave Boxborough, MA 01719 United States
Bernie Volz Cisco Systems、Inc. 1414 Massachusetts Ave Boxborough、MA 01719アメリカ合衆国
EMail: volz@cisco.com
Marcin Siodelski ISC 950 Charter Street Redwood City, CA 94063 United States
Marcin Siodelski ISC 950 Charter Street Redwood City、CA 94063アメリカ合衆国
EMail: msiodelski@gmail.com