[要約] RFC 8168は、DHCPv6プレフィックス長ヒントの問題に関するガイドラインです。このRFCの目的は、DHCPv6クライアントが正確なプレフィックス長情報を取得できるようにすることです。
Internet Engineering Task Force (IETF) T. Li
Request for Comments: 8168 C. Liu
Category: Standards Track Y. Cui
ISSN: 2070-1721 Tsinghua University
May 2017
DHCPv6 Prefix-Length Hint Issues
DHCPv6プレフィックス長のヒントの問題
Abstract
概要
DHCPv6 Prefix Delegation allows a client to include a prefix-length hint value in the IA_PD option to indicate a preference for the size of the prefix to be delegated, but it is unclear about how the client and server should act in different situations involving the prefix-length hint. This document provides a summary of the existing problems with the prefix-length hint and guidance on what the client and server could do in different situations.
DHCPv6接頭辞委任により、クライアントはIA_PDオプションに接頭辞長のヒント値を含めて、委任する接頭辞のサイズの優先順位を示すことができますが、クライアントとサーバーが接頭辞を含むさまざまな状況でどのように動作するかは不明確です長さのヒント。このドキュメントでは、プレフィックス長のヒントに関する既存の問題の概要と、さまざまな状況でクライアントとサーバーが実行できることについてのガイダンスを提供します。
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 7841.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 7841のセクション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/rfc8168.
このドキュメントの現在のステータス、エラータ、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc8168で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2017 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に記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 3
3. Problem Description and Proposed Solutions . . . . . . . . . 3
3.1. Creation of Solicit Message . . . . . . . . . . . . . . . 3
3.2. Receipt of Solicit Message . . . . . . . . . . . . . . . 4
3.3. Receipt of Advertise Message . . . . . . . . . . . . . . 5
3.4. Creation of Renew/Rebind Message . . . . . . . . . . . . 6
3.5. Receipt of Renew/Rebind Message . . . . . . . . . . . . . 6
3.6. General Recommendation . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
6. Normative References . . . . . . . . . . . . . . . . . . . . 8
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
DHCPv6 Prefix Delegation [RFC3633] allows a client to include a prefix-length hint value in the message sent to the server to indicate a preference for the size of the prefix to be delegated. A prefix-length hint is communicated by a client to the server by including an IA_PD Prefix Option (IAPREFIX option), encapsulated in an IA_PD option, with the "IPv6 prefix" field set to zero and the "prefix-length" field set to a non-zero value. The servers are free to ignore the prefix-length hint values depending on server policy. However, some clients may not be able to function (or only in a degraded state) when they're provided with a prefix whose length is different from what they requested. For example, if the client is asking for a /56 and the server returns a /64, the functionality of the client might be limited because it might not be able to split the prefix for all its interfaces. For other hints, such as requesting for an explicit address, this might be less critical, as it just helps a client that wishes to continue using what it used last time. The prefix-length hint directly impacts the operational capability of the client; thus, it should be given more consideration.
DHCPv6プレフィックス委任[RFC3633]を使用すると、クライアントは、サーバーに送信されるメッセージにプレフィックス長のヒント値を含めて、委任するプレフィックスのサイズの優先順位を示すことができます。プレフィックス長のヒントは、IA_PDプレフィックスオプション（IAPREFIXオプション）を含めることにより、クライアントからサーバーに通信されます。IA_PDオプションにカプセル化され、「IPv6プレフィックス」フィールドはゼロに設定され、「プレフィックス長」フィールドはゼロ以外の値。サーバーは、サーバーポリシーに応じて、プレフィックス長のヒント値を自由に無視できます。ただし、一部のクライアントは、要求されたものとは異なる長さのプレフィックスが提供されている場合、機能できない（または機能低下状態でのみ）可能性があります。たとえば、クライアントが/ 56を要求し、サーバーが/ 64を返す場合、クライアントのすべてのインターフェイスのプレフィックスを分割できないため、クライアントの機能が制限される可能性があります。明示的なアドレスの要求など、他のヒントについては、前回使用したものを引き続き使用したいクライアントに役立つため、これはそれほど重要ではない場合があります。プレフィックス長のヒントは、クライアントの操作機能に直接影響します。したがって、より多くの考慮が必要です。
[RFC3633] is unclear about how the client and server should act in different situations involving the prefix-length hint. From the client perspective, it should be able to use the prefix-length hint to signal to the server its real-time need and should be able to handle prefixes with lengths different from the prefix-length hint. This document provides guidance on what a client should do in different situations to help it operate properly. From the server perspective, the server is free to ignore the prefix-length hints depending on server policy; however, in cases where the server has a policy for considering the hint, this document provides guidance on how the prefix-length hint should be handled by the server in different situations.
[RFC3633]は、プレフィックス長のヒントを含むさまざまな状況でクライアントとサーバーがどのように動作するかについては不明です。クライアントの観点からは、プレフィックス長のヒントを使用してリアルタイムの必要性をサーバーに通知でき、プレフィックス長のヒントとは異なる長さのプレフィックスを処理できる必要があります。このドキュメントでは、クライアントが適切に動作するために、さまざまな状況でクライアントが何をすべきかについてのガイダンスを提供します。サーバーの観点からは、サーバーはサーバーのポリシーに応じてプレフィックス長のヒントを自由に無視できます。ただし、サーバーにヒントを検討するポリシーがある場合、このドキュメントでは、さまざまな状況でサーバーが接頭辞長のヒントを処理する方法についてのガイダンスを提供します。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.
キーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONALこのドキュメントの「」は、BCP 14 [RFC2119] [RFC8174]で説明されているように解釈されます。
Problem:
問題：
The Solicit message allows a client to ask servers for prefixes and other configuration parameters. The client might want a different prefix length due to configuration changes, or it might just want the same prefix again after reboot. The client might also prefer a prefix of a specific length in case the requested prefix is not available. The server could decide whether to provide the client with the preferred prefix depending on server policy, but the client should be able to signal to the server its real-time need.
Solicitメッセージにより、クライアントはサーバーに接頭辞およびその他の構成パラメーターを要求できます。クライアントは、構成の変更のために別のプレフィックス長が必要な場合や、再起動後に同じプレフィックス長が必要な場合があります。要求されたプレフィックスが使用できない場合、クライアントは特定の長さのプレフィックスを優先する場合もあります。サーバーは、サーバーポリシーに応じて優先プレフィックスをクライアントに提供するかどうかを決定できますが、クライアントはリアルタイムの必要性をサーバーに通知できる必要があります。
The server usually has a record of the prefix it gave to the client during its most recent interaction. The best way to assure a completely new delegated prefix is to send a new IAID (Identity Association IDentifier) in the IA_PD (Identity Association for Prefix Delegation). However, this would require the client device to have persistent storage, because rebooting the device would cause the client to use the original IAID in the IA_PD.
サーバーには通常、最新の対話中にクライアントに与えた接頭辞の記録があります。完全に新しい委任されたプレフィックスを保証する最善の方法は、IA_PD（プレフィックス委任のIDアソシエーション）で新しいIAID（IDアソシエーションID識別子）を送信することです。ただし、デバイスを再起動するとクライアントがIA_PDの元のIAIDを使用するため、クライアントデバイスに永続的なストレージが必要になります。
Solution:
解決：
When the client prefers a prefix of a specific length from the server, the client MUST send a Solicit message using the same IAID in the IA_PD, include the preferred prefix-length value in the "prefix-length" field of the IAPREFIX option, and set the "IPv6 prefix" field to zero. This is an indication to the server that the client prefers a prefix of the specified length, regardless of what it received before.
クライアントがサーバーから特定の長さのプレフィックスを優先する場合、クライアントは、IA_PDの同じIAIDを使用して要請メッセージを送信し、IAPREFIXオプションの "prefix-length"フィールドに優先プレフィックス長の値を含める必要があります。 「IPv6プレフィックス」フィールドをゼロに設定します。これは、クライアントが以前に受信したものに関係なく、クライアントが指定された長さのプレフィックスを優先することをサーバーに示しています。
When the client wants the same prefix back from the server, it MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix value in the "IPv6 prefix" field of the IAPREFIX option, and include the length of the prefix in the "prefix-length" field. This is an indication to the server that the client wants the same prefix back.
クライアントがサーバーから同じプレフィックスを要求する場合、IA_PDの同じIAIDを使用して要請メッセージを送信し、IAPREFIXオプションの「IPv6プレフィックス」フィールドに以前に委任されたプレフィックス値を含め、 「prefix-length」フィールドのプレフィックス。これは、クライアントが同じプレフィックスを戻してほしいことをサーバーに示しています。
When the client wants the same prefix back from the server and would prefer to accept a prefix of a specified length in case the requested prefix is not available, the client MUST send a Solicit message using the same IAID in the IA_PD, include the previously delegated prefix in one IAPREFIX option, and include the prefix-length hint in another IAPREFIX option. There is no requirement regarding the order of the two IAPREFIX options.
クライアントが同じ接頭辞をサーバーから返して欲しい場合、要求された接頭辞が利用できない場合に指定された長さの接頭辞を受け入れることを好むとき、クライアントはIA_PDの同じIAIDを使用して要請メッセージを送信しなければなりません。 1つのIAPREFIXオプションにプレフィックスを付け、別のIAPREFIXオプションにプレフィックス長のヒントを含めます。 2つのIAPREFIXオプションの順序に関する要件はありません。
Problem:
問題：
[RFC3633] allows a client to include a prefix-length hint in the Solicit message to signal its preference to the server. How the prefix-length hint should be handled by the server is unclear. The client might want a different prefix length due to configuration changes or it might just want the same prefix again after reboot. The server should interpret these cases differently.
[RFC3633]により、クライアントはSolicitメッセージにプレフィックス長のヒントを含めて、サーバーに優先順位を知らせることができます。接頭辞長のヒントがサーバーでどのように処理されるかは不明です。クライアントは、構成の変更のために別のプレフィックス長が必要な場合や、再起動後に同じプレフィックスが再度必要な場合があります。サーバーは、これらのケースを異なる方法で解釈する必要があります。
Many servers are configured to provide only prefixes of specific lengths to the client, for example, if the client requested for a /54 but the server could only provide /30, /48, and /56. How should these servers decide which prefix to give to the client based on the prefix-length hint?
多くのサーバーは、クライアントに特定の長さのプレフィックスのみを提供するように構成されています。たとえば、クライアントが/ 54を要求した場合、サーバーは/ 30、/ 48、および/ 56しか提供できません。これらのサーバーは、プレフィックス長のヒントに基づいて、クライアントに与えるプレフィックスをどのように決定すべきですか？
Solution:
解決：
Upon the receipt of Solicit message, if the client included only a prefix-length hint in the message, the server SHOULD first check its prefix pool for a prefix with a length matching the prefix-length hint value, regardless of the prefix record from previous interactions with the client. If the server does not have a prefix with a length matching the prefix-length hint value, then the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value.
要請メッセージの受信時に、クライアントがメッセージにプレフィックス長のヒントのみを含めた場合、サーバーは、前のプレフィックスレコードに関係なく、プレフィックスプールをチェックして、プレフィックス長のヒント値に一致する長さのプレフィックスを最初に確認する必要があります。クライアントとの対話。サーバーにprefix-lengthヒント値と一致する長さのプレフィックスがない場合、サーバーは、長さが短く、prefix-lengthヒント値に最も近いプレフィックスを提供する必要があります（SHOULD）。
If the client included a specific prefix value in the Solicit message, the server SHOULD check its prefix pool for a prefix matching the requested prefix value. If the requested prefix is not available in the server's prefix pool, and the client also included a prefix-length hint in the same IA_PD option, then the server SHOULD check its prefix pool for a prefix with a length matching the prefix-length hint value. If the server does not have a prefix with a length matching the prefix-length hint value, the server SHOULD provide the prefix whose length is shorter and closest to the prefix-length hint value.
クライアントが要請メッセージに特定のプレフィックス値を含めた場合、サーバーは、そのプレフィックスプールをチェックして、要求されたプレフィックス値と一致するプレフィックスがないかを確認する必要があります。要求されたプレフィックスがサーバーのプレフィックスプールで利用できず、クライアントも同じIA_PDオプションにプレフィックス長のヒントを含めた場合、サーバーは、プレフィックスプールをチェックして、プレフィックス長のヒント値と一致する長さのプレフィックスを探す必要があります。 。サーバーにprefix-lengthヒント値と一致する長さのプレフィックスがない場合、サーバーは、長さが短く、prefix-lengthヒント値に最も近いプレフィックスを提供する必要があります（SHOULD）。
If the server will not assign any prefixes to any IA_PDs in a subsequent Request from the client, the server MUST send an Advertise message to the client as described in Section 11.2 of [RFC3633].
サーバーがクライアントからの後続のリクエストでIA_PDにプレフィックスを割り当てない場合、サーバーは[RFC3633]のセクション11.2で説明されているように、アドバタイズメッセージをクライアントに送信する必要があります。
Problem:
問題：
The server might not be able to honor the prefix-length hint due to server policy or lack of resources in its prefix pool. If the prefix length provided by the server in the Advertise message is different from what the client requested in the Solicit message, the question would be whether the client should use the provided prefix length or continue to ask for its preferred prefix length. There are certain situations in which the client could not operate properly if it used a prefix whose length is different from what it requested in the prefix-length hint. However, if the client ignores the Advertise messages and continues to solicit for the preferred prefix length, the client might be stuck in the DHCP process. Another question is whether the client should ignore other configuration parameters such as available addresses.
サーバーポリシーまたはプレフィックスプール内のリソースの不足により、サーバーはプレフィックス長のヒントを受け入れることができない場合があります。サーバーがアドバタイズメッセージで提供したプレフィックス長がクライアントが要請メッセージで要求したものと異なる場合、問題は、クライアントが提供されたプレフィックス長を使用するか、それとも優先プレフィックス長を要求し続けるかです。プレフィックス長のヒントで要求したものとは異なる長さのプレフィックスを使用した場合、クライアントが正常に動作しない特定の状況があります。ただし、クライアントがアドバタイズメッセージを無視し、優先プレフィックス長を要求し続けると、クライアントがDHCPプロセスでスタックする可能性があります。別の質問は、クライアントが使用可能なアドレスなどの他の構成パラメーターを無視するかどうかです。
Solution:
解決：
If the client could use the prefixes included in the Advertise messages despite being different from the prefix-length hint, the client SHOULD choose the shortest prefix length that is closest to the prefix-length hint. The client SHOULD continue requesting the preferred prefix in the subsequent DHCPv6 messages as defined in Section 3.4 of this document.
プレフィックス長のヒントとは異なるにもかかわらず、クライアントがアドバタイズメッセージに含まれるプレフィックスを使用できる場合、クライアントは、プレフィックス長のヒントに最も近い最短のプレフィックス長を選択する必要があります（SHOULD）。クライアントは、このドキュメントのセクション3.4で定義されているように、後続のDHCPv6メッセージで優先プレフィックスを要求し続ける必要があります（SHOULD）。
If the client sent a Solicit with only IA_PDs and cannot use the prefixes included in the Advertise messages, it MUST ignore the Advertise messages and continue to send Solicit messages until it gets the preferred prefix. To avoid traffic congestion, the client MUST send Solicit messages at defined intervals, as specified in [RFC7083].
クライアントがIA_PDのみでSolicitを送信し、アドバタイズメッセージに含まれるプレフィックスを使用できない場合、クライアントはアドバタイズメッセージを無視し、優先プレフィックスを取得するまでSolicitメッセージを送信し続ける必要があります。トラフィックの輻輳を回避するために、クライアントは、[RFC7083]で指定されているように、定義された間隔で要請メッセージを送信する必要があります。
If the client also solicited for other stateful configuration options such as IA_NAs and the client cannot use the prefixes included in the Advertise messages, the client SHOULD accept the other stateful configuration options and continue to request the desired IA_PD prefix in subsequent DHCPv6 messages as specified in [RFC7550].
クライアントがIA_NAなどの他のステートフル構成オプションも要請し、クライアントがアドバタイズメッセージに含まれているプレフィックスを使用できない場合、クライアントは他のステートフル構成オプションを受け入れて、次のDHCPv6メッセージで必要なIA_PDプレフィックスを要求し続ける必要があります。 [RFC7550]。
Problem:
問題：
Servers might not be able to provide a prefix with the length equal to or shorter than the prefix-length hint. If the client decided to use the prefix provided by the server despite it being longer than the prefix-length hint but would still prefer the prefix-length hint originally requested in the Solicit message, there should be some way for the client to express this preference during Renew/Rebind. For example, if the client requested for a /60 but got a /64, the client should be able to signal to the server during Renew/Rebind that it would still prefer a /60. This is to see whether the server has the prefix preferred by the client available in its prefix pool during Renew/Rebind. [RFC3633] is not completely clear on whether the client is allowed to include a prefix-length hint in the Renew/Rebind message.
サーバーは、プレフィックス長のヒント以下の長さのプレフィックスを提供できない場合があります。プレフィックス長のヒントよりも長いにもかかわらず、クライアントがサーバーから提供されたプレフィックスを使用することに決めたが、それでも要請メッセージで最初に要求されたプレフィックス長のヒントを好む場合、クライアントがこの設定を表現する方法がいくつかあるはずです。更新/再バインド中。たとえば、クライアントが/ 60を要求したが/ 64を取得した場合、クライアントは更新/再バインド中にサーバーに/ 60を優先することを通知できる必要があります。これは、サーバーが、クライアントが優先するプレフィックスが、更新/再バインド中にそのプレフィックスプールで使用できるかどうかを確認するためです。 [RFC3633]は、クライアントがRenew / Rebindメッセージにプレフィックス長のヒントを含めることが許可されているかどうかについて完全に明確ではありません。
Solution:
解決：
During Renew/Rebind, if the client prefers a prefix length that is different from the prefix it is currently using, then the client SHOULD send the Renew/Rebind message with the same IA_PD, and include two IAPREFIX options, one containing the currently delegated prefix and the other containing the prefix-length hint. This is to extend the lifetime of the prefix the client is currently using, get the prefix the client prefers, and go through a graceful switch over.
Renew / Rebind中に、クライアントが現在使用しているプレフィックスとは異なるプレフィックス長を好む場合、クライアントは同じIA_PDでRenew / Rebindメッセージを送信し、現在委任されているプレフィックスを含む2つのIAPREFIXオプションを含める必要があります（SHOULD）。もう1つには、プレフィックス長のヒントが含まれています。これは、クライアントが現在使用しているプレフィックスの有効期間を延長し、クライアントが優先するプレフィックスを取得して、適切な切り替えを行うためです。
If the server is unable to provide the client with the newly requested prefix, but is able to extend lifetime of the old prefix, the client SHOULD continue using the old prefix.
サーバーが新しく要求された接頭辞をクライアントに提供できないが、古い接頭辞の存続期間を延長できる場合、クライアントは古い接頭辞を引き続き使用する必要があります（SHOULD）。
Problem:
問題：
The prefix preferred by the client might become available in the server's prefix pool during Renew/Rebind, even though it was unavailable during Solicit. This might be due to a server configuration change or because some other client stopped using the prefix.
クライアントが優先するプレフィックスは、要請時に使用できなかった場合でも、更新/再バインド中にサーバーのプレフィックスプールで使用できるようになる可能性があります。これは、サーバー構成の変更が原因であるか、他のクライアントがプレフィックスの使用を停止したことが原因である可能性があります。
The question is whether the server should remember the prefix-length hint the client originally included in the Solicit message and check it during Renew/Rebind to see if it has the prefix length the client preferred. This would require the server to keep extra information about the client. There is also the possibility that the client's preference for the prefix length might have changed during this time interval, so the prefix-length hint remembered by the server might not be what the client prefers during Renew/Rebind.
問題は、サーバーがクライアントから要請メッセージに最初に含まれていた接頭辞長のヒントを記憶し、更新/再バインド中にそれをチェックして、クライアントが希望する接頭辞長であるかどうかを確認するかどうかです。これには、サーバーがクライアントに関する追加情報を保持する必要があります。この時間間隔中にクライアントのプレフィックス長の設定が変更された可能性もあります。そのため、サーバーが記憶しているプレフィックス長のヒントは、更新/再バインド中にクライアントが優先するものとは異なる場合があります。
Instead of having the server remember the prefix-length hint of the client, another option is for the client to include the prefix-length hint in the Renew/Rebind message. [RFC3633] is unclear about what the server should do if the client also included a prefix-length hint value in the Renew/Rebind message and whether the server could provide a different prefix to the client during Renew/Rebind.
サーバーにクライアントの接頭辞長のヒントを記憶させる代わりに、クライアントが接頭辞長のヒントを更新/再バインドメッセージに含めることもできます。 [RFC3633]は、クライアントがRenew / Rebindメッセージにプレフィックス長のヒント値を含めた場合のサーバーの動作、およびサーバーがRenew / Rebind中に別のプレフィックスをクライアントに提供できるかどうかが不明確です。
Solution:
解決：
Upon the receipt of a Renew/Rebind message, if the client included in the IA_PD both an IAPREFIX option with the delegated prefix value and an IAPREFIX option with a prefix-length hint value, the server SHOULD check whether it could extend the lifetime of the original delegated prefix and whether it has any available prefix matching the prefix-length hint (or determine the closest possible to the prefix-length hint) within its limit.
Renew / Rebindメッセージの受信時に、クライアントがIA_PDに、委任されたプレフィックス値を持つIAPREFIXオプションと、プレフィックス長のヒント値を持つIAPREFIXオプションの両方が含まれている場合、サーバーは、元の委任されたプレフィックスと、プレフィックス長のヒントに一致する使用可能なプレフィックスがあるかどうか（またはプレフィックス長のヒントに最も近いものを決定するかどうか）。
If the server assigned the prefix included in IA_PD to the client, the server SHOULD do one of the following, depending on its policy:
サーバーがIA_PDに含まれるプレフィックスをクライアントに割り当てた場合、サーバーはそのポリシーに応じて、次のいずれかを実行する必要があります（SHOULD）。
1. Extend the lifetime of the original delegated prefix.
1. 元の委任されたプレフィックスの有効期間を延長します。
2. Extend the lifetime of the original delegated prefix and assign a new prefix of the requested length.
2. 元の委任されたプレフィックスの有効期間を延長し、要求された長さの新しいプレフィックスを割り当てます。
3. Mark the original delegated prefix as invalid by giving it 0 lifetimes, and assign a new prefix of the requested length. This avoids the complexity of handling multiple delegated prefixes but may break all the existing connections of the client.
3. 有効期間を0にして、元の委任されたプレフィックスを無効としてマークし、要求された長さの新しいプレフィックスを割り当てます。これにより、複数の委任されたプレフィックスの処理の複雑さが回避されますが、クライアントの既存の接続がすべて切断される可能性があります。
4. Assign the original delegated prefix with 0 preferred-lifetime, a specific non-zero valid-lifetime depending on actual requirement, and assign a new prefix of the requested length. This allows the client to finish up existing connections with the original prefix and use the new prefix to establish new connections.
4. 元の委任されたプレフィックスに、preferred-lifetime 0、実際の要件に応じてゼロ以外の特定のvalid-lifetimeを割り当て、要求された長さの新しいプレフィックスを割り当てます。これにより、クライアントは既存の接続を元の接頭辞で完了し、新しい接頭辞を使用して新しい接続を確立できます。
5. Do not include the original delegated prefix in the Reply message, and assign a new prefix of the requested length. The original prefix would be valid until its lifetime expires. This avoids sudden renumbering on the client.
5. 元の委任されたプレフィックスを返信メッセージに含めず、要求された長さの新しいプレフィックスを割り当てます。元のプレフィックスは、その有効期限が切れるまで有効です。これにより、クライアントでの突然の再番号付けが回避されます。
If the server does not know the client's bindings (e.g., a different server receiving the message during Rebind), then the server SHOULD ignore the original delegated prefix and try to assign a new prefix of the requested length.
サーバーがクライアントのバインディングを知らない場合（たとえば、再バインド中にメッセージを受信する別のサーバー）、サーバーは元の委任されたプレフィックスを無視して、要求された長さの新しいプレフィックスを割り当てようとする必要があります（SHOULD）。
It's unnecessary for the server to remember the prefix-length hint the client requested during Solicit. It is possible that the client's preference for the prefix length might have changed during this time interval, so the prefix-length hint in the Renew message is reflecting what the client prefers at the time.
サーバーが要請時にクライアントが要求したプレフィックス長のヒントを覚えておく必要はありません。この時間間隔の間にクライアントのプレフィックス長の設定が変更された可能性があるため、更新メッセージのプレフィックス長のヒントは、クライアントがその時点で好むものを反映しています。
The recommendation to address the issues discussed in this document is for a client that wants (at least) to have a delegated prefix of a specific prefix length to always include an IAPREFIX option with just the prefix-length hint in addition to any IAPREFIX options it has included for each IA_PD in any Solicit, Request, Renew, and Rebind messages it sends. While a server is free to ignore the hint, servers that do not choose to ignore the hint should attempt to assign a prefix of the hint length (or assign the next closest length that does not exceed the hint) if one is available. Whether a server favors the hint or avoiding a renumbering event is a matter of server policy.
このドキュメントで説明されている問題に対処するための推奨事項は、特定のプレフィックス長の委任されたプレフィックスに、IAPREFIXオプションに加えて、プレフィックス長のヒントだけを含むIAPREFIXオプションを常に含めることを望むクライアント向けです。送信するSolicit、Request、Renew、Rebindメッセージの各IA_PDに含まれています。サーバーはヒントを自由に無視できますが、ヒントを無視しないことを選択したサーバーは、使用可能な場合、ヒントの長さのプレフィックスを割り当てる（またはヒントを超えない次の最も近い長さを割り当てる）ようにする必要があります。サーバーがヒントを優先するか、再番号付けイベントを回避するかは、サーバーポリシーの問題です。
This document provides guidance on how the clients and servers interact with regard to the DHCPv6 prefix-length hint. Security considerations in DHCP are described in Section 23 of [RFC3315]. Security considerations regarding DHCPv6 prefix delegation are described in Section 15 of [RFC3633].
このドキュメントでは、DHCPv6プレフィックス長のヒントに関して、クライアントとサーバーがどのように相互作用するかについてのガイダンスを提供します。 DHCPのセキュリティに関する考慮事項は、[RFC3315]のセクション23で説明されています。 DHCPv6プレフィックス委任に関するセキュリティの考慮事項は、[RFC3633]のセクション15で説明されています。
This document does not require any IANA actions.
このドキュメントでは、IANAアクションは必要ありません。
[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>。
[RFC7550] Troan, O., Volz, B., and M. Siodelski, "Issues and Recommendations with Multiple Stateful DHCPv6 Options", RFC 7550, DOI 10.17487/RFC7550, May 2015, <http://www.rfc-editor.org/info/rfc7550>.
[RFC7550] Troan、O.、Volz、B。、およびM. Siodelski、「複数のステートフルDHCPv6オプションに関する問題と推奨事項」、RFC 7550、DOI 10.17487 / RFC7550、2015年5月、<http：//www.rfc-editor .org / info / rfc7550>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <http://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B。、「あいまいな大文字と小文字のRFC 2119キーワード」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<http://www.rfc-editor.org/info/ rfc8174>。
Acknowledgements
謝辞
Many thanks to Qi Sun, Bernie Volz, Ole Troan, Sunil Gandhewar, Marcin Siodelski, Ted Lemon, Roni Even, Benoit Claise, Mirja Kuehlewind, Kathleen Moriarty, Eric Rescorla, Alvaro Retana, Susan Hares, and Hilarie Orman for their review and comments.
Qi Sun、Bernie Volz、Ole Troan、Sunil Gandhewar、Marcin Siodelski、Ted Lemon、Roni Even、Benoit Claise、Mirja Kuehlewind、Kathleen Moriarty、Eric Rescorla、Alvaro Retana、Susan Hares、およびHilarie Ormanのレビューとコメントに感謝します。 。
Authors' Addresses
著者のアドレス
Tianxiang Li Tsinghua University Beijing 100084 China
TI Security l ITS inghua大学北京100084中国
Phone: +86-18301185866
Email: peter416733@gmail.com
Cong Liu Tsinghua University Beijing 100084 China
con GL IU ts inghua大学北京100084中国
Phone: +86-10-6278-5822
Email: gnocuil@gmail.com
Yong Cui Tsinghua University Beijing 100084 China
Yong Cu ITS inghuauniversity北京100084中国
Phone: +86-10-6260-3059
Email: yong.cui.thu@gmail.com