[要約] RFC 9096は、IPv6の再番号付けイベントに対するカスタマーエッジルーターの反応を改善することを目的としています。この文書は、再番号付けが発生した際にネットワークのダウンタイムを最小限に抑えるためのガイドラインを提供します。主に、ISPがIPアドレスの割り当てを変更する場面で利用されます。
Internet Engineering Task Force (IETF) F. Gont
Request for Comments: 9096 SI6 Networks
BCP: 234 J. Žorž
Updates: 7084 6connect
Category: Best Current Practice R. Patterson
ISSN: 2070-1721 Sky UK
B. Volz
Individual Contributor
August 2021
Improving the Reaction of Customer Edge Routers to IPv6 Renumbering Events
顧客エッジルータのIPv6の戻りイベントへの反応の改善
Abstract
概要
This document specifies improvements to Customer Edge routers that help mitigate the problems that may arise when network configuration information becomes invalid without any explicit signaling of that condition to the local nodes. This document updates RFC 7084.
このドキュメントは、ローカルノードへの明示的なシグナリングなしにネットワーク構成情報が無効になると発生する可能性がある問題を軽減するのに役立つ、カスタマーエッジルーターの改善を示しています。この文書はRFC 7084を更新します。
Status of This Memo
本文書の位置付け
This memo documents an Internet Best Current Practice.
このメモはインターネットの最高の現在の練習を文書化しています。
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 BCPs is available in Section 2 of RFC 7841.
この文書は、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表します。それは公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による出版の承認を受けました。BCPの詳細情報はRFC 7841のセクション2で入手できます。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9096.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法は、https://www.rfc-editor.org/info/rfc9096で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2021 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2021 IETF信頼と文書著者として識別された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://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トラストの法的規定（https://trustee.ietf.org/license-info）の対象となります。 これらのドキュメントは、このドキュメントに関するお客様の権利と制限について説明しているため、注意深く確認してください。 このドキュメントから抽出されたコードコンポーネントには、Trust LegalProvisionsのセクション4.eで説明されているSimplifiedBSD Licenseテキストが含まれている必要があり、Simplified BSDLicenseで説明されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction
2. Requirements Language
3. Improved Customer Edge Router Behavior
3.1. Automatic DHCPv6 RELEASEs
3.2. Stability of IAIDs
3.3. Interface between the WAN Side and LAN Side
3.4. LAN-Side Option Lifetimes
3.5. Signaling Stale Configuration Information
4. Recommended Option Lifetimes Configuration Values
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgments
Authors' Addresses
In scenarios where network configuration information becomes invalid without any explicit signaling of that condition (such as when a Customer Edge (CE) router crashes and reboots without knowledge of the previously employed configuration information), hosts on the local network will continue using stale information for an unacceptably long period of time, thus resulting in connectivity problems. This problem is documented in detail in [RFC8978].
その条件の明示的なシグナリングなしにネットワーク構成情報が無効になるシナリオでは、（カスタマエッジ（CE）ルータが以前に採用されている構成情報の知識なしにクラッシュして再起動したときなど）、ローカルネットワーク上のホストは古い情報を使用していきます。許容できないほど長期間、したがって接続性の問題が生じる。この問題は[RFC8978]に詳しく説明されています。
This document specifies improvements to CE routers that help mitigate the aforementioned problem for residential and small office scenarios. It specifies recommendations for the default behavior of CE routers but does not preclude the availability of configuration knobs that might allow an operator or user to manually configure the CE router to deviate from these recommendations. This document updates RFC 7084.
このドキュメントは、住宅および小規模オフィスのシナリオに対する前述の問題を軽減するのに役立つCEルーターの改善を規定しています。これは、CEルータのデフォルトの動作に関する推奨事項を指定しますが、オペレータまたはユーザーがこれらの推奨事項から逸脱するようにCEルータを手動で設定できるようにすることができる構成ノブの可用性を排除しません。この文書はRFC 7084を更新します。
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", "MAY", および "OPTIONAL" はBCP 14 [RFC2119] [RFC8174]で説明されているように、すべて大文字の場合にのみ解釈されます。
This section specifies and clarifies requirements for CE routers that can help mitigate the problem discussed in Section 1, particularly when they employ prefixes learned via DHCPv6 Prefix Delegation (DHCPv6-PD) [RFC8415] on the WAN side with Stateless Address Autoconfiguration (SLAAC) [RFC4862] or DHCPv6 [RFC8415] on the LAN side. The recommendations in this document help improve robustness at the CE router (on which the user or ISP may have no control) and do not preclude implementation of host-side improvements such as those specified in [6MAN-SLAAC-RENUM].
このセクションは、特にDHCPv6プレフィックスの委任（DHCPv6-PD）[RFC8415]でステートレスアドレス自動設定（SLAAC）を介してDHCPv6プレフィックス委任（DHCPV6-PD）[RFC8415]を使用して、セクション1で説明している問題を軽減するのに役立つCEルータの要件を指定して説明します。LAN側のRFC4862またはDHCPv6 [RFC8415]。この文書の推奨事項は、CEルータ（ユーザーまたはISPがコントロールを持たない可能性がある場合）での堅牢性を向上させ、[6man-slaac-ranum]で指定されたもののようなホスト側の改善の実装を排除しません。
This document specifies additional WAN-side prefix-delegation (WPD) requirements to those specified in [RFC7084]:
このドキュメントでは、[RFC7084]で指定されたものへの追加のWANサイドプレフィックス委任（WPD）要件を指定します。
WPD-9: CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon restart events. See Section 3.1 for further details.
WPD-9：CEルータは、再起動イベント時にDHCPv6-PDリリースメッセージを自動的に送信しないでください。詳細についてはセクション3.1を参照してください。
WPD-10: CE routers MUST by default use a WAN-side Identity Association IDentifier (IAID) value that is stable between CE router restarts, DHCPv6 client restarts, or interface state changes (e.g., transient PPP interfaces), unless the CE router employs the IAID techniques discussed in Section 4.5 of [RFC7844]. See Section 3.2 for further details.
WPD-10：CEルータがCEルータが採用していない限り、CEルータのデフォルトでは、CEルータの再起動、DHCPv6クライアントの再起動、またはインターフェイス状態の変更（たとえば、トランジェントPPPインターフェイス）のWAN側IDアソシエーション識別子（IAID）を使用してください。[RFC7844]の4.5節で議論されたIAIDテクニック。詳細についてはセクション3.2を参照してください。
This document also replaces LAN-side requirement L-13 from [RFC7084] with:
この文書は、[RFC7084]から[RFC7084]からLAN側要件L-13も置き換えます。
L-13: CE routers MUST signal stale configuration information as specified in Section 3.5.
L-13：CEルータはセクション3.5で指定されているように古い設定情報を信号にする必要があります。
Finally, this document specifies the following additional LAN-side requirements to those from [RFC7084]:
最後に、このドキュメントでは、[RFC7084]から次の追加のLAN側の要件を指定します。
L-15: CE routers MUST NOT advertise prefixes via SLAAC or assign addresses or delegate prefixes via DHCPv6 on the LAN side using lifetimes that exceed the remaining lifetimes of the corresponding prefixes learned on the WAN side via DHCPv6-PD. For more details, see Section 3.3.
L-15：CEルータはSLAACを介してプレフィックスをアドバタイズしたり、DHCPV6-PDを介してWAN側で学習されている対応するプレフィックスの残りの寿命を超える寿命を使用して、LAN側のDHCPv6を介してアドレスを割り当ててはいけません。詳しくはセクション3.3を参照してください。
L-16: CE routers SHOULD advertise capped SLAAC option lifetimes, capped DHCPv6 IA Address option lifetimes, and capped IA Prefix option lifetimes, as specified in Section 3.4.
L-16：CEルータは、3.4項で指定されているように、CAPPED SLAACオプションのライフタイム、キャップされたDHCPv6 IAアドレスオプションの寿命を宣伝し、キャップされたIAプレフィックスオプションの寿命を宣伝する必要があります。
Some CE routers are known to automatically send DHCPv6-PD RELEASE messages upon restart events. However, this may inadvertently trigger a flash-renumbering scenario, along with the associated problems discussed in [RFC8978], that this document attempts to mitigate.
イベントの再起動時に自動的にDHCPv6-PDリリースメッセージを送信することが知られています。ただし、このドキュメントは軽減を試みる[RFC8978]で説明されている関連する問題とともに、これは誤ってフラッシュ番号を付けていないシナリオを引き起こす可能性があります。
As a result, requirement WPD-9 from Section 3 specifies that CE routers SHOULD NOT automatically send DHCPv6-PD RELEASE messages upon restart events.
その結果、セクション3の要件WPD-9は、イベントの再起動時にCEルータがDHCPv6-PDリリースメッセージを自動的に送信しないように指定します。
[RFC8415] requires that the IAID for an IA MUST be consistent across restarts of the DHCP client. However, some popular CE routers are known to select new random IAIDs, e.g., every time the underlying PPP session is established or when the device is rebooted. This could be the result of extrapolating the behavior described in [RFC7844] or simply a consequence of not storing IAIDs on stable storage along with failure to employ an algorithm that consistently generates the same IAID upon reboots. Thus, requirement WPD-10 from Section 3 prevents CE routers from inadvertently triggering flash-renumbering events on the local network.
[RFC8415] IAのIADのIAがDHCPクライアントの再起動にわたって一貫している必要があります。しかしながら、いくつかの一般的なCEルータは、基礎となるPPPセッションが確立されるたびに、または装置が再起動されるたびに、新しいランダムIADSを選択することが知られている。これは、[RFC7844]に記載されている挙動を推定することができ、または単に安定したストレージにIAIDを安定したストレージに保存しないことの結果である可能性があります。これは、再起動時に常に同じIAIDを発生させるアルゴリズムを使用しています。したがって、セクション3からの要件WPD-10は、CEルータが誤ってローカルネットワーク上のイベントを解きます。
The "Preferred Lifetime" and "Valid Lifetime" of Prefix Information Options (PIOs) [RFC4861] corresponding to prefixes learned via DHCPv6-PD on the WAN side MUST NOT span past the remaining preferred and valid lifetimes of the corresponding DHCPv6-PD prefixes. This means that the "Preferred Lifetime" and the "Valid Lifetime" advertised in PIOs by the CE router MUST be dynamically adjusted such that they never span past the remaining preferred and valid lifetimes of the corresponding prefixes delegated via DHCPv6-PD on the WAN side.
WAN側でDHCPv6-PDを介して学んだプレフィックスに対応するプレフィックス情報オプション（PIOS）[RFC4861]の「優先寿命」（PIOS）[RFC4861]は、対応するDHCPv6-PDプレフィックスの残りの優先順位と有効な寿命を過ぎてはいけません。これは、CEルータによるPIOSでアドバタイズされた「優先寿命」と「有効な有効期間」が、WAN側でDHCPv6-PDを介して委任された対応する接頭辞の残りの優先寿命を過ぎることはないように動的に調整されなければならないことを意味します。。
Similarly, the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Address options and DHCPv6 IA Prefix options employed with DHCPv6 on the LAN side MUST NOT span past the remaining preferred and valid lifetimes of the corresponding prefixes learned via DHCPv6-PD on the WAN side. This means that the "preferred-lifetime" and "valid-lifetime" of DHCPv6 IA Address options and DHCPv6 IA Prefix options employed with DHCPv6 on the LAN side MUST be dynamically adjusted such that they never span past the remaining preferred and valid lifetimes of the corresponding prefixes delegated to the CE router on the WAN side via DHCPv6-PD.
同様に、LAN側のDHCPv6とDHCPv6と共に使用されるDHCPv6 IAプレフィックスオプションの「優先寿命」およびDHCPv6 IAプレフィックスオプションの「優先寿命」および「有効寿命」は、DHCPv6-PDを介して学習された対応する接頭辞の残りの優先寿命を超えてはいけません。WAN側で。これは、LAN側のDHCPv6で採用されているDHCPv6 IAアドレスオプションとDHCPv6 IAプレフィックスオプションの「優先寿命」および「有効寿命」が、それらが残りの好ましく、有効な寿命を越えてもずらないように動的に調整されなければならないことを意味します。DHCPv6-PDを介してWAN側のCEルータに委任された対応するプレフィックス。
RATIONALE:
根拠：
* The lifetime values employed for the "Preferred Lifetime" (AdvPreferredLifetime) and "Valid Lifetime" (AdvValidLifetime) of SLAAC Prefix Information Options must never be larger than the remaining lifetimes of the corresponding prefixes (as learned via DHCPv6-PD on the WAN side). This is in line with the requirement from Section 6.3 of [RFC8415], which states:
* SLAACプレフィックス情報オプションの「優先寿命」（AdmpreferredLifetime）および「有効な有効期間」（AdvValidLifetime）に使用される有効期間は、（WAN側でDHCPv6-PDを介して学習された）対応するプレフィックスの残りの寿命よりも大きくなければならない。。これは[RFC8415]のセクション6.3からの要件に沿っています。
| In particular, if the delegated prefix or a prefix derived from it
| is advertised for stateless address autoconfiguration [RFC4862],
| the advertised preferred and valid lifetimes MUST NOT exceed the
| corresponding remaining lifetimes of the delegated prefix.
* The lifetime values of prefixes advertised on the LAN side via SLAAC must be dynamically updated (rather than static values); otherwise, the advertised lifetimes would eventually span past the DHCPv6-PD lifetimes.
* LAN側でSLAACを介して広告されているプレフィックスの有効期限は、（静的値ではなく）動的に更新されなければなりません。そうでなければ、宣伝された寿命は最終的にはDHCPv6-PDの寿命を過ぎて及ぶであろう。
* The same considerations apply for the "valid-lifetime" and "preferred-lifetime" of IA Address options and IA Prefix options employed with DHCPv6 on the LAN side.
* 同じ考慮事項は、LAN側でDHCPv6で採用されているIAアドレスオプションの「有効寿命」および「優先寿命」にも当てはまります。
CE routers SHOULD override the default lifetime values of Neighbor Discovery options that depend in any way on changes in the prefix employed for address configuration on the LAN side, and employ shorter lifetime values to improve the robustness to renumbering events, while complying with the requirements from Section 3.3 of this document and the recommendations in [RFC7772].
CEルータは、LAN側のアドレス設定に使用されているプレフィックスの変更点に依存する近隣探索オプションのデフォルトの有効期間の値を上書きし、短期間の値を短くしてイベントの参照を改善し、その要件に準拠しています。この文書の3.3節と[RFC7772]の推奨事項。
CE routers SHOULD set the "Router Lifetime" of Router Advertisement (RA) messages to ND_PREFERRED_LIMIT.
CEルータは、Router Advertisement（RA）メッセージの「ルータの有効期間」をND_PREFERRED_LIMITに設定する必要があります。
CE routers SHOULD also set the PIO "Preferred Lifetime" to the lesser of the remaining preferred lifetime of the corresponding prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the PIO "Valid Lifetime" to the lesser of the remaining valid lifetime of the corresponding prefix and ND_VALID_LIMIT. Additionally, the "Route Lifetime" of Route Information Options (RIOs) [RFC4191], the "Lifetime" of Recursive DNS Server (RDNSS) options [RFC8106], and the "Lifetime" of DNS Search List (DNSSL) options [RFC8106] SHOULD be set to the lesser of the longest remaining valid lifetime of a prefix (leased via DHCPv6 on the WAN side) and ND_VALID_LIMIT, if any of these options are included in Router Advertisement messages.
CEルータは、対応するプレフィックスの残りの優先寿命（セクション3.3）およびND_PREFERRED_LIMITの残りの優先寿命のより少ないPIO "推奨寿命"を設定し、対応する有効な有効な有効期間のより少ない値に設定する必要があります。プレフィックスとND_VALID_LIMIT。また、経路情報オプション（RIOS）[RFC4191]の「Route Lifetime」、Recursive DNSサーバーの「Lifetime」（RFC8106]、およびDNS検索リストの「Lifetime」（DNSSL）オプション[RFC8106]これらのオプションのいずれかがルータ広告メッセージに含まれている場合、Prefixの最長の有効な有効期間（WAN側のDHCPv6を介してリース）およびND_VALID_LIMITのうちのより少ないものに設定する必要があります。
NOTE: In scenarios where the valid lifetime and the preferred lifetime of prefixes learned via DHCPv6 on the WAN side are always larger than ND_VALID_LIMIT and ND_PREFERRED_LIMIT, respectively, the lifetime values advertised on the LAN side will not experience actual changes.
注：WAN側のDHCPv6を介して学んだプレフィックスの有効な有効期間と優先寿命がそれぞれND_VALID_LIMITおよびND_PREFERRED_LIMITよりも大きいシナリオでは、LAN側でアドバタイズされたLifetime値は実際の変更を経験しません。
The above text refers to the Neighbor Discovery options that are typically employed by CE routers. A CE router may need to apply the same policy for setting the lifetime of other Neighbor Discovery options it employs, if and where applicable.
上記のテキストは、CEルータによって通常使用される近隣探索オプションを指します。CEルータは、該当する場合、および該当する場合は、採用した他の隣接発見オプションの有効期間を設定するために同じポリシーを適用する必要があるかもしれません。
CE routers providing stateful address configuration via DHCPv6 SHOULD set the "preferred-lifetime" of a DHCPv6 IA Address option to the lesser of the remaining preferred lifetime of the corresponding prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-lifetime" of the same option to the lesser of the remaining valid lifetime of the corresponding prefix and ND_VALID_LIMIT.
DHCPv6を介してステートフルアドレス設定を提供するCEルータは、DHCPv6 IA Addressオプションの「優先寿命」を対応する接頭辞の残りの優先寿命（セクション3.3）およびND_PREFERRED_LIMITを参照して、「有効寿命」を設定する必要があります。対応する接頭辞およびND_VALID_LIMITの残りの有効な有効期間のより少ないオプションの場合。
CE routers providing DHCPv6-PD on the LAN side SHOULD set the "preferred-lifetime" of a DHCPv6 IA Prefix option to the lesser of the remaining preferred lifetime of the corresponding prefix (see Section 3.3) and ND_PREFERRED_LIMIT, and set the "valid-lifetime" of the same option to the lesser of the remaining valid lifetime of the corresponding prefix and ND_VALID_LIMIT.
LAN側のDHCPv6-PDを提供するCEルータは対応するプレフィックスの残りの好適寿命の少ないへのDHCPv6IAPrefixオプションの「好ましい寿命」を設定し（セクション3.3を参照）とND_PREFERRED_LIMIT、および「valid-を設定すべきです対応する接頭辞とND_VALID_LIMITの残りの有効寿命の少ない方に同じオプションの生涯」。
RATIONALE:
根拠：
* The "Valid Lifetime" and "Preferred Lifetime" of PIOs have a direct impact on three different aspects:
* PIOの「有効な有効期間」と「優先寿命」は、3つの異なる側面に直接影響を与えます。
- The amount of time hosts may end up employing stale network configuration information (see [RFC8978]).
- ホストが古いネットワーク構成情報を採用することができる時間が終わる可能性があります（[RFC8978]参照）。
- The amount of time CE routers need to persist trying to deprecate stale network configuration information (e.g., to handle cases where hosts miss Router Advertisement messages and thus still consider the stale information as valid).
- CEルータの量は、古いネットワーク構成情報を非推奨を推奨しようとしている必要があります（たとえば、ホストがルータ広告メッセージをMiss Miss Miss Miss Miss Miss Miss Stale情報を有効な場合とみなす）。
- The amount of information that CE routers need to maintain when, e.g., multiple crash-and-reboot events occur in the time span represented by the option lifetimes employed on the LAN side.
- CEルータが、例えばLAN側で採用されているオプションの寿命によって表される時間スパンで複数のクラッシュおよび再起動イベントが発生するときに維持する必要がある情報の量。
* CE routers need not employ the (possibly long) WAN-side DHCPv6-PD lifetimes for the "Valid Lifetime" and "Preferred Lifetime" of PIOs sent in Router Advertisement messages to advertise sub-prefixes of the leased prefix. Instead, CE routers SHOULD use shorter values for the "Valid Lifetime" and "Preferred Lifetime" of PIOs, since subsequent Router Advertisement messages will nevertheless refresh the associated lifetimes, leading to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes.
* CEルータは、ルータ広告メッセージで送信されたPIOの「有効な有効期間」および「優先寿命」について（おそらく長い）WAN側のDHCPv6-PDの寿命を採用して、リースプレフィックスのサブプレフィックスをアドバタイズします。代わりに、CEルータは、後続のルータ広告メッセージが関連する寿命をリフレッシュし、WAN側DHCPv6-PDによって指定された同じ有効な寿命をリードするため、CEルータはPIOの「有効な有効期間」と「優先寿命」を使用する必要があります。寿命。
* Similarly, CE routers need not employ the (possibly long) WAN-side DHCPv6-PD lifetimes for the "valid-lifetime" and "preferred-lifetime" of IA Address options and IA Prefix options employed by DHCPv6 on the LAN side, since the renewal of bindings by DHCPv6 clients will lead to the same effective lifetimes as specified by the WAN-side DHCPv6-PD lifetimes.
* 同様に、CEルータは、IAアドレスオプションの「有効寿命」および「優先寿命」およびLAN側のDHCPv6によって採用されているIAプレフィックスオプションのために（おそらく長い）WAN側のDHCPv6-PDの寿命を使用する必要はない。DHCPV6顧客によるバインディングの更新は、WAN側DHCPV6-PDの寿命によって指定されているのと同じ効果的な寿命をもたらすでしょう。
When a CE router provides LAN-side address-configuration information via SLAAC:
CEルータがSLAACを介してLAN側アドレス設定情報を提供する場合
* A CE router sending RAs that advertise prefixes belonging to a dynamically learned prefix (e.g., via DHCPv6-PD) SHOULD record, on stable storage, the list of prefixes being advertised via PIOs on each network segment and the state of the "A" and "L" flags of the corresponding PIOs.
* 動的に学習されたプレフィックスに属する接頭辞をアドバタイズしたCEルータは、（例えば、DHCPv6-PD経由で）各ネットワークセグメントのPIOSでアドバタイズされているプレフィックスのリストと「A」の状態を記録する必要があります。対応するPIOの「L」フラグ。
* Upon changes to the advertised prefixes, and after bootstrapping, the CE router advertising prefix information via SLAAC proceeds as follows:
* アドバタイズされたプレフィックスに変更され、ブートストラップ後、SLAACを介したCEルータのプレフィックス情報は次のように進みます。
- Any prefixes that were previously advertised by the CE router via PIOs in RA messages, but that have now become stale, MUST be advertised with PIOs that have the "Valid Lifetime" and the "Preferred Lifetime" set to 0 and the "A" and "L" bits unchanged.
- RAメッセージのPIOSを介してCEルータによって以前にアドバタイズされたプレフィックスは、現在古くなっているが、「有効な有効期間」を持つPIOSでアドバタイズする必要があります。「有効な有効期間」と「推奨有効期間」が0と「A」変更されずに "L"ビット。
- The aforementioned advertisements MUST be performed for at least the "Valid Lifetime" previously employed for such prefixes. The CE router MUST advertise this information with unsolicited Router Advertisement messages, as described in Section 6.2.4 of [RFC4861], and MAY advertise this information via unicast Router Advertisement messages when possible and applicable.
- 前述の広告は、そのような接頭辞に以前に採用されている「有効な有効期間」に対して実行されなければならない。CEルータは、[RFC4861]のセクション6.2.4で説明されているように、この情報を迷惑なルータ広告メッセージで宣伝する必要があり、可能であればユニキャストルータ広告メッセージを介してこの情報を宣伝することができます。
NOTE: If requirement L-16 (Section 3) is followed, the "Valid Lifetime" need not be saved, and the stale prefix can simply be advertised for a period of ND_VALID_LIMIT.
注：要件L-16（セクション3）に従っている場合は、「有効な有効期間」を保存する必要はなく、古いプレフィックスは単にND_VALID_LIMITの期間アドバタイズできます。
* CE routers receiving DHCPv6 IA Prefix options with a 0 "valid-lifetime" MUST advertise the corresponding sub-prefixes (as they would be generated for the same leased prefix with a non-zero lifetime) with PIOs with both the "Preferred Lifetime" and the "Valid Lifetime" set to 0, for at least the WAN-side DHCPv6-PD "valid-lifetime", or for a period of ND_VALID_LIMIT if the recommended lifetimes from Section 3.4 are employed.
* 0 "有効なライフタイム"でDHCPv6 iaプレフィックスオプションを受信するCEルータは、対応するサブプレフィックスを宣伝しなければなりません（ゼロ以外のプレフィックスで生成される可能性があるため、ゼロ以外のプレフィックス）と「優先寿命」の両方のPIOSを持つ。「有効な有効期間」は、少なくともWAN側DHCPv6-PD「有効寿命」、またはセクション3.4からの推奨寿命が採用されている場合は、0に設定されていますが、ND_VALID_LIMITの期間。
When a CE router provides LAN-side DHCPv6 (address assignment or prefix delegation), then:
CEルータがLAN側DHCPv6（アドレス割り当てまたはプレフィックスの委任）を提供するとき、
* The CE router SHOULD record, on stable storage, the DHCPv6 address and delegated-prefix bindings corresponding to the LAN side.
* CEルータは、安定したストレージ、LAN側に対応するDHCPv6アドレスと委任プレフィックスのバインディングを記録する必要があります。
* If the CE router finds that the prefix to be employed for address assignment and/or prefix delegation has changed (e.g., upon a crash-and-reboot event) or the CE router receives DHCPv6 IA Prefix options with 0 lifetimes, the CE router MUST:
* CEルータが、アドレス割り当ておよび/またはプレフィックスの委任に採用されるプレフィックスが変更されたことを検索した場合（たとえば、クラッシュおよび再起動イベントが発生した場合）、またはCEルータが0の寿命を持つDHCPv6 IAプレフィックスオプションを受信する必要がある場合は、CEルーターが必要です。：
- In Replies to DHCPv6 Request, Renew, and Rebind messages, send IA Address options or IA Prefix options (as appropriate) for any address assignments or prefix delegations for the stale prefixes. The aforementioned options MUST be sent with both the "valid-lifetime" and the "preferred-lifetime" set to 0, for at least the "valid-lifetime" originally employed for them, or for a period of ND_VALID_LIMIT if the recommended lifetimes from Section 3.4 are employed.
- DHCPv6の要求への返信、メッセージの更新、および再バインド、リンテーション、またはStaleプレフィックスのためのアドレス割り当てまたはプレフィックスの委任のために、IAアドレスオプションまたはIAプレフィックスオプションを（必要に応じて）送信します。前述のオプションは、少なくともそれらに採用されている「有効寿命」、または推奨される寿命が推奨されている場合には、「有効寿命」と「優先寿命」の両方を0に設定する必要があります。セクション3.4が採用されています。
- Initiate sending Reconfigure messages, if possible (i.e., client requests Reconfigure support and the CE router offers it), to those clients with address assignments or prefix delegations for the stale prefixes.
- 可能であれば（すなわち、クライアントリクエストを再設定し、CEルータを提供する）クライアントに、アドレス割り当てまたは古いプレフィックスのプレフィックスの委任を開始します。
RATIONALE:
根拠：
* IPv6 network renumbering is expected to take place in a planned manner with old/stale prefixes being phased out via reduced prefix lifetimes while new prefixes (with normal lifetimes) are introduced. However, a number of scenarios may lead to the so-called "flash-renumbering" events, where a prefix being employed on a network suddenly becomes invalid and replaced by a new prefix [RFC8978]. One such scenario is when an Internet Service Provider (ISP) employs dynamic prefixes and the CE router crashes and reboots. The requirements in this section are meant to allow CE routers to deprecate stale information in such scenarios.
* IPv6ネットワークの番号は、古い/古いプレフィックスが廃棄された古い/古いプレフィックスを使用して、（通常の寿命を備えた）プレフィックスが導入されている間に、古い/古いプレフィックスを使用して計画された方法で行われると予想されます。ただし、多数のシナリオが、ネットワーク上で採用されているプレフィックスが突然無効になり、新しいプレフィックス[RFC8978]に置き換えられた場合、いわゆる「Flash-Nerdunding」イベントが発生する可能性があります。そのようなシナリオの1つは、インターネットサービスプロバイダ（ISP）が動的プレフィックスを使用し、CEルータがクラッシュして再起動するときです。このセクションの要件は、CEルーターがそのようなシナリオで古い情報を廃止できるようにするためのものです。
* The recommendations in this section expand from requirement L-13 in Section 4.3 of [RFC7084] and Section 6.3 of [RFC8415].
* このセクションの推奨事項は、[RFC7084]および[RFC8415]の[RFC7084]およびセクション6.3の要件L-13から展開されています。
* Hosts configuring addresses via SLAAC on the local network may employ addresses configured for the previously advertised prefixes for at most the "Valid Lifetime" of the corresponding PIOs of the last received Router Advertisement messages. Since Router Advertisement messages may be lost or fail to be received for various reasons, CE routers need to try to deprecate stale prefixes for a period of time equal to the "Valid Lifetime" of the PIO employed when originally advertising the prefix.
* ローカルネットワーク上のSLAACを介してアドレスを設定するホストは、最後に受信されたルータ広告メッセージの対応するPIオスの「有効な有効期間」に対して、前回アドバタイズされたプレフィックス用に設定されているアドレスを使用することができます。さまざまな理由でルーターの広告メッセージが失われたり受信できなくなる可能性があるため、CEルーターは、当初のプレフィックスを広告するときに使用されるPIOの「有効な有効期間」に等しい期間にわたって古いプレフィックスを非推奨する必要があります。
* The requirements in this section to store information on stable storage are conveyed as "SHOULD" (as opposed to "MUST"), since they may represent a challenge for some implementations.
* 安定したストレージに関する情報を保存するこのセクションの要件は、いくつかの実装のための課題を表すことができるので、（「必須」とは対照的に、「必須」として伝えられる。
* Advertising DHCPv6-leased prefixes with zero lifetimes on the LAN side would handle the case where a CE router has no stable storage but receives the prefixes via DHCPv6 with 0 lifetimes.
* 広告DHCPv6リースプレフィックスがLAN側にゼロの寿命を持つプレフィックスをゼロにすると、CEルータが安定したストレージを持たずに、DHCPv6を介してプレフィックスを0の寿命に受け取ります。
* The above text does not include DHCPv6 Advertise messages sent in response to DHCPv6 Solicit messages, since Section 18.3.9 of [RFC8415] requires that a DHCPv6 server that is not going to assign an address or delegated prefix received as a hint in the Solicit message MUST NOT include that address or delegated prefix in the Advertise message. Additionally, any subsequent Request messages will trigger the response specified in this section and therefore cause the address or prefix to be deprecated.
* [RFC8415]のセクション18.3.9のセクション18.3.9であるため、DHCPv6の募集メッセージに応答して送信されたDHCPv6アドバタイズメッセージは含まれていません。アドバタイズメッセージにそのアドレスまたは委任プレフィックスを含めないでください。さらに、後続のリクエストメッセージは、このセクションで指定された応答をトリガーし、それによってアドレスまたはプレフィックスを非推奨にすることができます。
* ND_PREFERRED_LIMIT: 2700 seconds (45 minutes)
* ND_PREFERRED_LIMIT：2700秒（45分）
* ND_VALID_LIMIT: 5400 seconds (90 minutes)
* ND_VALID_LIMIT：5400秒（90分）
RATIONALE:
根拠：
* These values represent a trade-off among a number of factors, including responsiveness and possible impact on the battery life of connected devices [RFC7772].
* これらの値は、応答性を含むいくつかの要因と、接続された機器の電池寿命への影響の可能性のある影響を表しています[RFC7772]。
* ND_PREFERRED_LIMIT is set according to the recommendations in [RFC7772] for the "Router Lifetime", following the rationale from Section 3.2 of [RFC8978].
* [RFC8978]のセクション3.2からの根拠の後に、[RFC7772]の[RFC7772]の[RFC7772]の推奨事項に従ってND_PREFERRED_LIMITが設定されています。
* ND_VALID_LIMIT is set to 2 * ND_PREFERRED_LIMIT to provide some additional leeway before configuration information is finally discarded by the hosts.
* ND_VALID_LIMITは、構成情報がついにホストによって破棄される前に、追加のLeewayを2 * ND_PREFERRED_LIMITに設定します。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document discusses a problem that may arise, e.g., in scenarios where dynamic IPv6 prefixes are employed, and it proposes improvements to CE routers [RFC7084] to mitigate the problem for residential or small office scenarios. It does not introduce new security issues; thus, the same security considerations as for [RFC4861], [RFC4862], [RFC7084], and [RFC8415] apply.
この文書では、例えば動的IPv6プレフィックスが採用されているシナリオで発生する可能性がある問題を説明し、それは住宅または小規模オフィスのシナリオの問題を軽減するためにCEルーター[RFC7084]の改善を提案します。それは新しいセキュリティ問題を導入しません。したがって、[RFC4861]、[RFC4862]、[RFC7084]、[RFC8415]は同じセキュリティ上の考慮事項を考慮しています。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.
[RFC2119] BRADNER、S、「RFCSで使用するためのキーワード」、BCP 14、RFC 2119、DOI 10.17487 / RFC2119、1997年3月、<https：//www.rfc-editor.org/info/RFC2119>。
[RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and More-Specific Routes", RFC 4191, DOI 10.17487/RFC4191, November 2005, <https://www.rfc-editor.org/info/rfc4191>.
[RFC4191] Draves、R.およびD. Thaler、「デフォルトルータ設定およびその他のルート」、RFC 4191、DOI 10.17487 / RFC4191、2005年11月、<https：//www.rfc-editor.org/info/rfc4191>。
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, DOI 10.17487/RFC4861, September 2007, <https://www.rfc-editor.org/info/rfc4861>.
[RFC4861] Narten、T.、Nordmark、E.、Simpson、W.、およびH. Soliman、「IPバージョン6（IPv6）の隣接発見（IPv6）」、RFC 4861、DOI 10.17487 / RFC4861、2007年9月、<https：//www.rfc-editor.org/info/rfc4861>。
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, DOI 10.17487/RFC4862, September 2007, <https://www.rfc-editor.org/info/rfc4862>.
[RFC4862] Thomson、S.、Narten、T.、T. Jinmei、「IPv6ステートレスアドレス自動設定」、RFC 4862、DOI 10.17487 / RFC4862、2007年9月、<https：//www.rfc-editor.org/info/ RFC4862>。
[RFC7772] Yourtchenko, A. and L. Colitti, "Reducing Energy Consumption of Router Advertisements", BCP 202, RFC 7772, DOI 10.17487/RFC7772, February 2016, <https://www.rfc-editor.org/info/rfc7772>.
[RFC7772] yourtchenko、A.およびL. Colitti、「ルータ広告のエネルギー消費量の削減」、BCP 202、RFC 7772、DOI 10.17487 / RFC7772、2016年2月、<https：//www.rfc-editor.org/info/RFC7772>。
[RFC7844] Huitema, C., Mrugalski, T., and S. Krishnan, "Anonymity Profiles for DHCP Clients", RFC 7844, DOI 10.17487/RFC7844, May 2016, <https://www.rfc-editor.org/info/rfc7844>.
[RFC7844] Huitema、C.、Mrugalski、T.、およびKrishnan、「DHCPクライアントの匿名性プロファイル」、RFC 7844、DOI 10.17487 / RFC7844、2016年5月、<https：//www.rfc-editor.org/情報/ RFC7844>。
[RFC8106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 8106, DOI 10.17487/RFC8106, March 2017, <https://www.rfc-editor.org/info/rfc8106>.
[RFC8106] Jeong、J.、Park、S.、Beloeil、L.、およびS. Madanapalli、「DNS構成のためのIPv6ルータ広告オプション」、RFC 8106、DOI 10.17487 / RFC8106、2017年3月、<HTTPS：// WWW.rfc-editor.org / info / rfc8106>。
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8174] Leiba、B、「RFC 2119キーワードの大文字の曖昧さ」、BCP 14、RFC 8174、DOI 10.17487 / RFC8174、2017年5月、<https：//www.rfc-editor.org/info/RFC8174>。
[RFC8415] Mrugalski, T., Siodelski, M., Volz, B., Yourtchenko, A., Richardson, M., Jiang, S., Lemon, T., and T. Winters, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 8415, DOI 10.17487/RFC8415, November 2018, <https://www.rfc-editor.org/info/rfc8415>.
[RFC8415] Mrugalski、T.、Sodelski、M.、Volz、B.、Yourtchenko、A.、Richardson、M.、Jiang、S.、Lemon、T.、T.Winters、「IPv6用動的ホスト構成プロトコル」（DHCPv6） "、RFC 8415、DOI 10.17487 / RFC8415、2018年11月、<https：//www.rfc-editor.org/info/rfc8415>。
[6MAN-SLAAC-RENUM] Gont, F., Zorz, J., and R. Patterson, "Improving the Robustness of Stateless Address Autoconfiguration (SLAAC) to Flash Renumbering Events", Work in Progress, Internet-Draft, draft-ietf-6man-slaac-renum-02, 19 January 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum-02>.
[6man-slaac-ranum]ゴント、F.、Zorz、J.、およびR.Patterson、「ステートレスアドレスの自動設定の堅牢性（SLAAC）への堅牢性（SLAAC）へのフラッシュ番号の変更の改善、進行中の作業、インターネットドラフト、ドラフトIETF-6man-slaac-renum-02、2021年1月19日、<https://datatracker.ietf.org/doc/html/draft-ietf-6man-slaac-renum-02>
[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, <https://www.rfc-editor.org/info/rfc7084>.
[RFC7084] Singh、H.、Beebee、W.、Donley、C.、およびB. Stark、「IPv6カスタマーエッジルータの基本要件」、RFC 7084、DOI 10.17487 / RFC7084、2013年11月、<https：// www.rfc-editor.org / info / rfc7084>。
[RFC8978] Gont, F., Žorž, J., and R. Patterson, "Reaction of IPv6 Stateless Address Autoconfiguration (SLAAC) to Flash-Renumbering Events", RFC 8978, DOI 10.17487/RFC8978, March 2021, <https://www.rfc-editor.org/info/rfc8978>.
[RFC8978] Gont、F.、ŁoRž、J。、およびR. Patterson、「IPv6ステートレスアドレスの自動設定（SLAAC）の反応（SLAAC）からフラッシュ番号を変更します。」、RFC 8978、DOI 10.17487 / RFC8978、2021年3月、<https：//www.rfc-editor.org/info/rfc8978>。
Acknowledgments
謝辞
The authors would like to thank Owen DeLong, Philip Homburg, Erik Kline, and Ted Lemon for their valuable help in improving this document via successive detailed reviews.
著者らは、著しい詳細なレビューを介してこの文書の改善において、Philip Homburg、Erik Kline、そしてTEDレモンに感謝します。
The authors would like to thank Mikael Abrahamsson, Luis Balbinot, Brian Carpenter, Tim Chown, Lorenzo Colitti, Alejandro D'Egidio, Gert Doering, Fernando Frediani, Guillermo Gont, Steinar Haug, Nick Hilliard, Lee Howard, Christian Huitema, Sheng Jiang, Benjamin Kaduk, Suresh Krishnan, Warren Kumari, Albert Manfredi, Olorunloba Olopade, Jordi Palet Martinez, Pete Resnick, Michael Richardson, Mark Smith, Job Snijders, Sander Steffann, Tarko Tikan, Ole Trøan, Loganaden Velvindron, Éric Vyncke, Robert Wilton, Timothy Winters, Christopher Wood, and Chongfeng Xie for providing valuable comments on earlier draft versions of this document.
著者らは、Mikael Abrahamsson、Luis Balbinot、Brian Carpenter、Tim Chownot、Lorenzo Colitti、Alejandro D'Egidio、Gert dadoi、Fernando Frediani、Guillermo Gue、Nick Hillarard、リー・ハワード、Sheng Jiang、Benjamin Kaduk、Suresh Krishnan、ウォーレンクマリ、Albert Manfredi、Olbert Manfredi、Olbert Manfredi、Jordi Palet Martinez、Pete Resnick、Michael Richardson、Mark Smith、Sander Steffann、Tarko Tikan、OleTrøan、Loganaden Velvincke、Robert Wilton、Timothyこの文書の以前のドラフトバージョンについて貴重なコメントを提供するための冬、クリストファーウッド、そしてChongfeng XIE。
Fernando would also like to thank Brian Carpenter who, over the years, has answered many questions and provided valuable comments that have benefited his protocol-related work.
また、Fernandoはまた、長年にわたり多くの質問に答えて、彼のプロトコル関連の仕事に恩恵を受けた貴重なコメントを提供したBrian Carpenterに感謝します。
Authors' Addresses
著者の住所
Fernando Gont SI6 Networks Segurola y Habana 4310, 7mo Piso Villa Devoto Ciudad Autonoma de Buenos Aires Argentina
Fernando Gont Si 6 Networks Segurola y Habana 4310,7mo Piso Villa Devoto Ciudad Autoloma de Buenos Airesアルゼンチン
Email: fgont@si6networks.com
URI: https://www.si6networks.com
Jan Žorž 6connect
1月1日6connect.
Email: jan@6connect.com
Richard Patterson Sky UK
Richard Patterson Sky UK.
Email: richard.patterson@sky.uk
Bernie Volz Individual Contributor 116 Hawkins Pond Road Center Harbor, NH 03226 United States of America
Bernie Volz個人の貢献メンバー116 Hawkins Pond Road Center Harbour、NH 03226アメリカ
Email: bevolz@gmail.com