[要約] RFC 8987は、DHCPv6プレフィックス委任リレーの要件を定義しています。この文書の目的は、ネットワーク上でのIPv6プレフィックスの効率的な配布を促進するための標準を確立することです。主にISPや大規模ネットワーク環境での利用が想定されています。
Internet Engineering Task Force (IETF) I. Farrer
Request for Comments: 8987 Deutsche Telekom AG
Category: Standards Track N. Kottapalli
ISSN: 2070-1721 Benu Networks
M. Hunek
Technical University of Liberec
R. Patterson
Sky UK Ltd.
February 2021
DHCPv6 Prefix Delegating Relay Requirements
DHCPv6プレフィックス委任中継リレー要件
Abstract
概要
This document describes operational problems that are known to occur when using DHCPv6 relays with prefix delegation. These problems can prevent successful delegation and result in routing failures. To address these problems, this document provides necessary functional requirements for operating DHCPv6 relays with prefix delegation.
このドキュメントでは、Prefix Delegationを使用してDHCPv6リレーを使用するときに発生することが知られている動作上の問題について説明します。これらの問題は、委任の成功を防ぎ、ルーティングの失敗をもたらす可能性があります。これらの問題に対処するために、このドキュメントはプレフィックス委任を伴うDHCPv6リレーを操作するための必要な機能要件を提供します。
It is recommended that any network operator using DHCPv6 prefix delegation with relays ensure that these requirements are followed on their networks.
リレーを使用してDHCPv6プレフィックスの委任を使用しているネットワーク事業者は、これらの要件に従ってネットワーク上に従うことを確認することをお勧めします。
Status of This Memo
本文書の位置付け
This is an Internet Standards Track document.
これはインターネット規格のトラック文書です。
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）の製品です。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 https://www.rfc-editor.org/info/rfc8987.
この文書の現在のステータス、任意のエラータ、およびフィードバックを提供する方法については、https://www.rfc-editor.org/info/rfc8987で入手できます。
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. Terminology
2.1. General
2.2. Topology
2.3. Requirements Language
3. Problems Observed with Existing Delegating Relay
Implementations
3.1. DHCP Messages Not Being Forwarded by the Delegating Relay
3.2. Delegating Relay Loss of State on Reboot
3.3. Multiple Delegated Prefixes for a Single Client
3.4. Dropping Messages from Devices with Duplicate MAC Addresses
and DUIDs
3.5. Forwarding Loops between Client and Relay
4. Requirements for Delegating Relays
4.1. General Requirements
4.2. Routing Requirements
4.3. Service Continuity Requirements
4.4. Operational Requirements
5. IANA Considerations
6. Security Considerations
7. References
7.1. Normative References
7.2. Informative References
Acknowledgements
Authors' Addresses
For Internet service providers that offer native IPv6 access with prefix delegation to their customers, a common deployment architecture is to have a DHCPv6 relay agent function located in the ISP's Layer 3 customer edge device and a separate, centralized DHCPv6 server infrastructure. [RFC8415] describes the functionality of a DHCPv6 relay, and Section 19.1.3 of [RFC8415] mentions this deployment scenario, but it does not provide details for all of the functional requirements that the relay needs to fulfill to operate deterministically in this deployment scenario.
プレフィックスの委任を備えたネイティブIPv6アクセスを提供するインターネットサービスプロバイダの場合、一般的な展開アーキテクチャは、ISPのレイヤ3のカスタマーエッジデバイスと個別の集中型のDHCPv6サーバーインフラストラクチャにあるDHCPv6リレーエージェント機能を持つことです。[RFC8415] DHCPv6リレーの機能を説明し、[RFC8415]のセクション19.1.3はこの展開シナリオで説明しますが、この展開シナリオで決定的に動作するためにリレーが実行する必要があるすべての機能要件の詳細はありません。。
A DHCPv6 relay agent for prefix delegation is a function commonly implemented in routing devices, but implementations vary in their functionality and client/server interworking. This can result in operational problems such as messages not being forwarded by the relay or unreachability of the delegated prefixes. This document provides a set of requirements for devices implementing a relay function for use with prefix delegation.
プレフィックス委任のためのDHCPv6リレーエージェントは、ルーティングデバイスで一般的に実装されている関数ですが、実装はその機能とクライアント/サーバーのインターワーキングによって異なります。これにより、委任プレフィックスのリレーまたは到達不能によって転送されないメッセージなどの動作上の問題が発生する可能性があります。このドキュメントは、プレフィックス委任で使用するために中継機能を実装するデバイスの要件のセットを提供します。
The mechanisms for a relay to inject routes (including aggregated ones) on its network-facing interface based on prefixes learned from a server via DHCP prefix delegation (DHCP-PD) are out of scope of the document.
DHCPプレフィックス委任（DHCP-PD）を介してサーバーから学習されたプレフィックスに基づいて、ネットワーク対立インターフェイスでルート（集約されたものを含む）へのリレーのメカニズム（DHCP-PD）は文書の範囲外です。
Multi-hop DHCPv6 relaying is not affected. The requirements in this document are solely applicable to the DHCP relay agent co-located with the first-hop router to which the DHCPv6 client requesting the prefix is connected, so no changes to any subsequent relays in the path are needed.
マルチホップDHCPv6中継は影響を受けません。この文書の要件は、Prefixを要求するDHCPv6クライアントが接続されている最初のホップルータと同じ場所にあるDHCPリレーエージェントにのみ適用されます。そのため、パス内の後続の中継に変更は必要ありません。
This document uses the terminology defined in [RFC8415]. However, when defining the functional elements for prefix delegation, [RFC8415], Section 4.2 defines the term "delegating router" as:
この文書は[RFC8415]で定義されている用語を使用しています。ただし、接頭辞委任の機能要素を定義するとき、[RFC8415]、セクション4.2は「委任ルータ」という用語を次のように定義します。
| The router that acts as a DHCP server and responds to requests for | delegated prefixes.
| ..DHCPサーバーとして機能し、それらの要求に応答するルーター委任されたプレフィックス
This document is concerned with deployment scenarios in which the DHCPv6 relay and DHCPv6 server functions are separated, so the term "delegating router" is not used. Instead, a new term is introduced to describe the relaying function:
この文書は、DHCPv6リレーおよびDHCPv6サーバー機能が分離されている展開シナリオに関するものです。そのため、「委任ルータ」という用語は使用されていません。代わりに、中継機能を説明するために新しい用語が導入されました。
Delegating relay: A delegating relay acts as an intermediate device, forwarding DHCPv6 messages containing IA_PD and IAPREFIX options between the client and server. The delegating relay does not implement a DHCPv6 server function. The delegating relay is also responsible for routing traffic for the delegated prefixes.
委任中継リレー：委任中継リレーは中間機器として機能し、クライアントとサーバーの間のIA_PDとIAPREFIXオプションを含むDHCPv6メッセージを転送します。委任中継はDHCPv6サーバー機能を実装しません。委任中継委員会は、委任されたプレフィックスのトラフィックをルーティングする責任もあります。
Where the term "relay" is used on its own within this document, it should be understood to be a delegating relay unless specifically stated otherwise.
この文書内で「リレー」という用語がそれ自体で使用されている場合、特に述べられていない限り、委任中継委員会であると理解されるべきである。
In CableLabs DOCSIS environments, the Cable Modem Termination System (CMTS) would be considered a delegating relay with respect to Customer Premises Devices (CPEs) ([DOCSIS_3.1], Section 5.2.7.2). A Broadband Network Gateway (BNG) in a DSL-based access network may be a delegating relay if it does not implement a local DHCPv6 server function ([TR-092], Section 4.10).
CableLabs DOCSIS環境では、ケーブルモデム終端システム（CMTS）は、顧客宅内機器（CPES）に関して委任中継（[DOCSIS_3.1]、5.2.7.2）と見なされます。DSLベースのアクセスネットワーク内のブロードバンドネットワークゲートウェイ（BNG）は、ローカルDHCPv6サーバ機能を実装していない場合（[TR-092]、セクション4.10）、委任中継委員会である可能性があります。
[RFC8415] defines the "DHCP server" (or "server") as:
[RFC8415]「DHCPサーバー」（または「サーバー」）を次のように定義します。
| A node that responds to requests from clients. It may or may not
| be on the same link as the client(s). Depending on its
| capabilities, if it supports prefix delegation it may also feature
| the functionality of a delegating router.
This document serves the deployment cases where a DHCPv6 server is not located on the same link as the client (necessitating the delegating relay). The server supports prefix delegation and is capable of leasing prefixes to clients, but it is not responsible for other functions required of a delegating router, such as managing routes for the delegated prefixes.
このドキュメントでは、DHCPv6サーバーがクライアントと同じリンク上に配置されていない展開ケース（委任リレーを必要）します。サーバーはプレフィックスの委任をサポートし、プレフィックスをクライアントにリースすることができますが、委任されたプレフィックスのルートの管理など、委任ルータに必要な他の機能については責任を負いません。
The term "requesting router" has previously been used to describe the DHCP client requesting prefixes for use. This document adopts the terminology of [RFC8415] and uses "DHCP client" or "client" interchangeably for this element.
「Requive Router」という用語は、使用のためのプレフィックスを要求するDHCPクライアントを記述するために以前に使用されていました。この文書は[RFC8415]の用語を採用し、この要素に対して「DHCPクライアント」または「クライアント」を互換的に使用します。
The following diagram shows the deployment topology relevant to this document.
次の図は、この文書に関連する展開トポロジを示しています。
+
| ------- uplink ------>
| _ ,--,_
| +--------+ +------------+ _( `' )_ +--------+
+---+ PD |-------| Delegating |--( Operator )---| DHCPv6 |
| | Client | | relay | `(_ Network_)' | server |
| +--------+ +----------- + `--'`---' +--------+
|
| <----- downlink ------
+ (client facing)
Client
Network
Figure 1: Topology Overview
図1：トポロジの概要
The client requests prefixes via the downlink interface of the delegating relay. The resulting prefixes will be used for addressing the client network. The delegating relay is responsible for forwarding DHCP messages, including prefix delegation requests and responses between the client and server. Messages are forwarded from the delegating relay to the server using multicast or unicast via the operator uplink interface.
クライアントは、委任中継のダウンリンクインターフェイスを介してプレフィックスを要求します。結果のプレフィックスはクライアントネットワークのアドレス指定に使用されます。委任中継は、プレフィックスの委任要求とクライアントとサーバー間の応答を含むDHCPメッセージを転送する責任があります。メッセージは、オペレータアップリンクインタフェースを介してマルチキャストまたはユニキャストを使用して、委任中継委員会からサーバに転送されます。
The delegating relay provides the operator's Layer 3 edge towards the client and is responsible for routing traffic to and from clients connected to the client network using addresses from the delegated prefixes.
代行リレーは、オペレータのレイヤ3エッジをクライアントに向けて提供し、委任されたプレフィックスからアドレスを使用してクライアントネットワークに接続されているクライアントとの間でトラフィックをルーティングする責任があります。
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]で説明されているように、すべて大文字の場合にのみ解釈されます。
The following sections of the document describe problems that have been observed with delegating relay implementations in commercially available devices.
以下の文書のセクションでは、市販のデバイスにおける中継実装を委任して観察された問題が説明されています。
Delegating relay implementations have been observed not to forward messages between the client and server. This generally occurs if a client sends a message that is unexpected by the delegating relay. For example, the delegating relay already has an active PD lease entry for an existing client on a port. A new client is connected to this port and sends a Solicit message. The delegating relay then drops the Solicit messages until either it receives a DHCP Release message from the original client or the existing lease times out. This causes a particular problem when a client device needs to be replaced due to a failure.
クライアントとサーバー間でメッセージを転送しないように委任されています。これは一般に、クライアントが委任中継のリレーによって予期しないメッセージを送信した場合に発生します。たとえば、委任中継リレーには、既存のクライアントがポート上の既存のクライアントのアクティブPDリースエントリがあります。新しいクライアントがこのポートに接続されており、募集メッセージを送信します。その後、委任中のリレーは、元のクライアントまたは既存のリースタイムアウトからDHCPリリースメッセージを受信するまでの致命的なメッセージを削除します。これにより、障害のためにクライアントデバイスを置き換える必要がある場合に特定の問題が発生します。
In addition to dropping messages, in some cases, the delegating relay will generate error messages and send them to the client, e.g., "NoBinding" messages being sent in the event that the delegating relay does not have an active delegated prefix lease.
メッセージを削除することに加えて、場合によっては、委任中継委員会はエラーメッセージを生成し、それらをクライアントに送信し、委任中継委員会が有効な委任されたプレフィックスリースを持たない場合には、送信されたメッセージをクライアントに送信します。
For proper routing of client traffic, the delegating relay requires a corresponding routing table entry for each active prefix delegated to a connected client. A delegating relay that does not store this state persistently across reboots will not be able to forward traffic to the client's delegated leases until the state is reestablished through new DHCP messages.
クライアントトラフィックを適切にルーティングするために、委任中継リレーには、接続されているクライアントに委任された各アクティブプレフィックスの対応するルーティングテーブルエントリが必要です。この状態を保存しない委任中継委任中のリレーは、再起動後にトラフィックを新しいDHCPメッセージを介して再確立されるまで、クライアントの委任されたリースにトラフィックを転送することはできません。
DHCPv6 [RFC8415] allows a client to include more than one instance of OPTION_IA_PD in messages in order to request multiple prefix delegations by the server. If configured for this, the server supplies one (or more) instance of OPTION_IAPREFIX for each received instance of OPTION_IA_PD, each containing information for a different delegated prefix.
DHCPv6 [RFC8415]サーバーによって複数のプレフィックスの委任を要求するために、クライアントにメッセージ内のOption_ia_PDの複数のインスタンスを含めることができます。これに設定されている場合、サーバーは、option_ia_pdの各インスタンスごとにOption_iapRefixの1つの（またはそれ以上）インスタンスを1つ供給し、それぞれ異なる委任プレフィックスの情報を含みます。
In some delegating relay implementations, only a single delegated prefix per DHCP Unique Identifier (DUID) is supported. In those cases, only one IPv6 route for one of the delegated prefixes is installed, meaning that other prefixes delegated to a client are unreachable.
いくつかの委任中継実装では、DHCP固有ID（DUID）ごとの単一の委任プレフィックスだけがサポートされています。そのような場合は、委任されたプレフィックスの1つのIPv6ルートがインストールされています。つまり、クライアントに委任されている他のプレフィックスが到達できません。
3.4. Dropping Messages from Devices with Duplicate MAC Addresses and DUIDs
3.4. 重複したMACアドレスとDUIDを持つデバイスからメッセージを削除する
It is an operational reality that client devices with duplicate Media Access Control (MAC) addresses and/or DUIDs exist and have been deployed. In some networks, the operational costs of locating and swapping out such devices are prohibitive.
複製されたメディアアクセス制御（MAC）アドレスおよび/またはDUIDを持つクライアントデバイスが存在し、展開されている操作現実です。いくつかのネットワークでは、そのようなデバイスを見つけて交換するための運用コストは法外なものです。
Delegating relays have been observed to restrict forwarding client messages originating from one client DUID to a single interface. In this case, if the same client DUID appears from a second client on another interface while there is already an active lease, messages originating from the second client are dropped, causing the second client to be unable to obtain a prefix delegation.
1つのクライアントDUIDから発信されたクライアントメッセージを単一のインタフェースに制限するために、委任リレーが観察されています。この場合、既にアクティブリースがある間に同じクライアントDUIDが別のインターフェイス上の2番目のクライアントから表示されている場合、2番目のクライアントから発信されたメッセージが削除され、2番目のクライアントはプレフィックス委任を取得できなくなります。
It should be noted that in some access networks, the MAC address and/ or DUID are used as part of device identification and authentication. In such networks, enforcing uniqueness of the MAC address and/or DUID is a necessary function and is not considered a problem.
いくつかのアクセスネットワークでは、MACアドレスおよび/またはDUIDは、装置識別および認証の一部として使用されることに留意されたい。そのようなネットワークでは、MACアドレスおよび/またはDUIDの一意性を強制することは必要な機能であり、問題とは見なされない。
If the client loses information about an active prefix lease it has been delegated while the lease entry and associated route are still active in the delegating relay, then the relay will forward traffic to the client. The client will return this traffic to the relay, which is the client's default gateway (learned via a Router Advertisement (RA)). The loop will continue until either the client is successfully reprovisioned via DHCP or the lease ages out in the relay.
クライアントがアクティブなプレフィックスリースに関する情報を失う場合、リースエントリと関連ルートが委任中継リレーで依然としてアクティブになっている間に委任されている場合、リレーはトラフィックをクライアントに転送します。クライアントはこのトラフィックをリレーに戻ります。これはクライアントのデフォルトゲートウェイです（Router Advertisement（RA）を介して学習）。このループは、クライアントがDHCPまたはリアーのリースを介して正常に再プロビジョニングされるまで続きます。
To resolve the problems described in Section 3 and to preempt other undesirable behavior, the following section of the document describes a set of functional requirements for the delegating relay.
セクション3で説明されている問題を解決し、他の望ましくない動作を先取りするために、この文書の次のセクションでは、委任中継の一連の機能要件について説明します。
In addition, relay implementers are reminded that [RFC8415] makes it clear that relays MUST forward packets that either contain message codes it may not understand (Section 19 of [RFC8415]) or options that it does not understand (Section 16 of [RFC8415]).
さらに、リレー実装者は、[RFC8415]がリレーを含めることができるパケットを理解できない（[RFC8415]のセクション19）、または理解できないオプションを転送しなければならないことを思い出させます（[RFC8415]のセクション16）。）。
G-1: The delegating relay MUST forward messages bidirectionally between the client and server without changing the contents of the message.
G-1：委任中継は、メッセージの内容を変更せずに、クライアントとサーバーの間で双方向にメッセージを転送する必要があります。
G-2: The relay MUST allow for multiple prefixes to be delegated for the same client IA_PD. These delegations may have different lifetimes.
G-2：リレーは、同じクライアントIA_PDに対して複数のプレフィックスを委任できるようにする必要があります。これらの代表団は寿命が異なる場合があります。
G-3: The relay MUST allow for multiple prefixes (with or without separate IA_PDs) to be delegated to a single client connected to a single interface, identified by its DHCPv6 Client Identifier (DUID).
G-3：リレーは、そのDHCPv6クライアント識別子（DUID）によって識別される単一のインターフェイスに接続された単一のクライアントに複数のプレフィックスを委任することを許可する必要があります。
G-4: A delegating relay may have one or more interfaces on which it acts as a relay, as well as one or more interfaces on which it does not (for example, in an ISP, it might act as a relay on all southbound interfaces but not on the northbound interfaces). The relay SHOULD allow the same client identifier (DUID) to have active delegated prefix leases on more than one interface simultaneously unless client DUID uniqueness is necessary for the functioning or security of the network. This is to allow client devices with duplicate DUIDs to function on separate broadcast domains.
G-4：委任中継委員会は、それがリレーとして機能する1つ以上のインタフェース、ならびにそれがそうでない1つ以上のインターフェース（例えば、ISPでは、それはすべての南バウンドでリレーとして機能する可能性がある）を有することができる。Northboundインターフェイスではなくインタフェースがありません。リレーは、ネットワークの機能やセキュリティにクライアントのDUIDの一意性が必要な場合を除き、同じクライアント識別子（DUID）が複数のインタフェース上の有効な委任プレフィックスが同時にリースされていることを許可する必要があります。これは、複製されたDUIDを持つクライアントデバイスを別々のブロードキャストドメインで機能させることを許可することです。
G-5: The maximum number of simultaneous prefixes delegated to a single client MUST be configurable.
G-5：単一のクライアントに委任された同時プレフィックスの最大数は設定可能でなければなりません。
G-6: The relay MUST implement a mechanism to limit the maximum number of active prefix delegations on a single port for all client identifiers and IA_PDs. This value MUST be configurable.
G-6：リレーは、すべてのクライアント識別子およびIA_PDSの単一のポートでアクティブなプレフィックスの最大数を制限するためのメカニズムを実装する必要があります。この値は設定可能でなければなりません。
G-7: It is RECOMMENDED that delegating relays support at least 8 active delegated leases per client device and use this as the default limit.
G-7：リレーの委任をクライアントデバイスあたり少なくとも8つのアクティブな委任的なリースをサポートし、これをデフォルトの制限として使用することをお勧めします。
G-8: The delegating relay MUST update the lease lifetimes based on the client's reply messages it forwards to the client and only expire the delegated prefixes when the valid lifetime has elapsed.
G-8：委任中継は、クライアントの返信メッセージに基づいてリース寿命を更新し、有効なライフタイムが経過したときに委任されたプレフィックスを期限切れにしか満了しなければなりません。
G-9: On receipt of a Release message from the client, the delegating relay MUST expire the active leases for each of the IA_PDs in the message.
G-9：クライアントからのリリースメッセージを受信すると、委任中継はメッセージ内の各IA_PDSのアクティブリースを期限切れにする必要があります。
R-1: The relay MUST maintain a local routing table that is dynamically updated with leases and the associated next hops as they are delegated to clients. When a delegated prefix is released or expires, the associated route MUST be removed from the relay's routing table.
R-1：リレーは、リースで動的に更新されているローカルルーティングテーブルと、クライアントに委任されるように関連付けられている次のホップを維持する必要があります。委任されたプレフィックスが解放されるか、または期限切れになると、関連するルートはリレーのルーティングテーブルから削除されなければなりません。
R-2: The delegating relay's routing entry MUST use the same prefix length for the delegated prefix as given in the IA_PD.
R-2：委任中のリレーのルーティングエントリは、IA_PDに指定されているように、委任されたプレフィックスに同じプレフィックス長を使用する必要があります。
R-3: The relay MUST provide a mechanism to dynamically update ingress filters permitting ingress traffic sourced from client delegated leases and blocking packets from invalid source prefixes. This is to implement anti-spoofing as described in [BCP38]. The delegating relay's ingress filter entry MUST use the same prefix length for the delegated prefix as given in the IA_PD.
R-3：リレーは、クライアントの委任されたリースから供給された入力トラフィックと無効なソースプレフィックスからパケットをブロックすることを許可する入力フィルタを動的に更新するためのメカニズムを提供する必要があります。これは[BCP38]に記載されているようにスプーフィング防止を実現することです。委任中のリレーのInGress Filterエントリは、IA_PDで指定されている委任プレフィックスに同じプレフィックス長を使用する必要があります。
R-4: The relay MAY provide a mechanism to dynamically advertise delegated leases into a routing protocol as they are learned. If such a mechanism is implemented, when a delegated lease is released or expires, the delegated route MUST be withdrawn from the routing protocol. The mechanism by which the routes are inserted and deleted is out of the scope of this document.
R - 4：リレーは、委任されたリースを学習されたときに動的にルーティングプロトコルにアドバタイズするためのメカニズムを提供することができる。そのようなメカニズムが実装されている場合、委任されたリースが解放されたとき、または期限切れになると、委任された経路はルーティングプロトコルから引き出されなければなりません。ルートが挿入され削除されるメカニズムはこの文書の範囲外です。
R-5: To prevent routing loops, the relay SHOULD implement a configurable policy to drop potential looping packets received on any DHCP-PD client-facing interfaces.
R-5：ルーティングループを防ぐために、リレーは、DHCP-PDクライアント向けインターフェイスで受信された潜在的なループパケットをドロップするための設定可能なポリシーを実装する必要があります。
The policy SHOULD be configurable on a per-client or per-destination basis.
ポリシーは、クライアントごとまたは宛先ごとに設定できます。
Looping packets are those with a destination address in a prefix delegated to a client connected to that interface, as follows:
ループパケットは、次のように、そのインタフェースに接続されているクライアントに委任されたプレフィックス内の宛先アドレスを持つものです。
* For point-to-point links, when the packet's ingress and egress interfaces match.
* パケットの入力と出力インタフェースが一致すると、ポイントツーポイントリンクの場合。
* For multi-access links, when the packet's ingress and egress interface match, and the source link-layer and next-hop link-layer addresses match.
* マルチアクセスリンクの場合、パケットの入力と出力インタフェースが一致し、ソースリンク層とネクストホップのリンクレイヤアドレスが一致します。
An ICMPv6 Type 1, Code 6 (Destination Unreachable, reject route to destination) error message MAY be sent as per [RFC4443], Section 3.1. The ICMP policy SHOULD be configurable.
ICMPv6タイプ1、コード6（宛先到達不能、宛先への拒否）エラーメッセージは[RFC4443]、セクション3.1に従って送信されることがあります。ICMPポリシーは設定可能である必要があります。
S-1: To preserve active client prefix delegations across relay restarts, the relay SHOULD implement at least one of the following:
S-1：リレーの再起動を絶えずアクティブなクライアントのプレフィックスの代理区を保持するために、リレーは次のいずれかを実装する必要があります。
* Implement DHCPv6 Bulk Leasequery as defined in [RFC5460].
* [RFC5460]で定義されているようにDHCPv6バルクリース照度を実装してください。
* Store active prefix delegations in persistent storage so they can be reread after the reboot.
* アクティブなプレフィックスの代理区を永続ストレージに保存して、再起動後に再読み込みできるようにします。
S-2: If a client's next-hop link-local address becomes unreachable (e.g., due to a link-down event on the relevant physical interface), routes for the client's delegated prefixes MUST be retained by the delegating relay unless they are released or removed due to expiring DHCP timers. This is to reestablish routing for the delegated prefix if the client next hop becomes reachable without the delegated prefixes needing to be relearned.
S-2：クライアントのネクストホップリンクローカルアドレスが到達不能になると（例えば、関連する物理インターフェイスのリンクダウンイベントのため）、クライアントの委任プレフィックスのルートはリリースされない限り、委任中継によって保持されなければなりません。または期限切れのDHCPタイマーのために削除されました。これは、委任されたプレフィックスを再認証する必要なしにクライアントのネクストホップが到達可能になると、委任されたプレフィックスのルーティングを再確立することです。
S-3: The relay SHOULD implement DHCPv6 Active Leasequery as defined in [RFC7653] to keep the local lease database in sync with the DHCPv6 server.
S-3：リレーは[RFC7653]で定義されているDHCPv6アクティブリースクリーを実装して、ローカルリースデータベースをDHCPv6サーバーと同期してください。
O-1: The relay SHOULD implement an interface allowing the operator to view the active delegated prefixes. This SHOULD provide information about the delegated lease and client details such as the client identifier, next-hop address, connected interface, and remaining lifetimes.
O-1：リレーは、オペレータがアクティブな委任プレフィックスを表示できるようにするインタフェースを実装する必要があります。これにより、クライアント識別子、ネクストホップアドレス、接続インターフェイス、および残りの寿命などの委任されたリースとクライアントの詳細に関する情報を提供する必要があります。
O-2: The relay SHOULD provide a method for the operator to clear active bindings for an individual lease, client, or all bindings on a port.
O-2：リレーは、ポート上の個々のリース、クライアント、またはすべてのバインディングのアクティブなバインディングをクリアするためのメソッドを提供する必要があります。
O-3: To facilitate troubleshooting of operational problems between the delegating relay and other elements, it is RECOMMENDED that a time synchronization protocol be used by the delegating relays and DHCP servers.
O-3：委任中継リレーと他の要素間の運用上の問題のトラブルシューティングを容易にするために、委任中継プロトコルとDHCPサーバーによって時間同期プロトコルを使用することをお勧めします。
This document has no IANA actions.
この文書にはIANAの行動がありません。
This document does not add any new security considerations beyond those mentioned in Section 4 of [RFC8213] and Section 22 of [RFC8415].
この文書では、[RFC8213]のセクション4と[RFC8415]のセクション4で述べたものを超えて新しいセキュリティ上の考慮事項を追加しません。
If the delegating relay implements [BCP38] filtering, then the filtering rules will need to be dynamically updated as delegated prefixes are leased.
委任中継が[BCP38]フィルタリングを実装している場合、委任されたプレフィックスがリースされているため、フィルタリングルールは動的に更新される必要があります。
[RFC8213] describes a method for securing traffic between the relay agent and server by sending DHCP messages over an IPsec tunnel. It is RECOMMENDED that this be implemented by the delegating relay.
[RFC8213] IPSecトンネルを介してDHCPメッセージを送信することで、リレーエージェントとサーバー間のトラフィックを保護する方法について説明します。これは委任中継によって実装されることをお勧めします。
Failure to implement requirement G-6 may have specific security implications, such as a resource depletion attack on the relay.
要件を実装しなかったG-6は、リレーのリソースの枯渇攻撃など、特定のセキュリティの影響を持つことができます。
The operational requirements in Section 4.4 may introduce additional security considerations. It is RECOMMENDED that the operational security practices described in [RFC4778] be implemented.
セクション4.4の運用要件は、追加のセキュリティ上の考慮事項を導入する可能性があります。[RFC4778]に記載されている運用セキュリティ慣行を実装することをお勧めします。
[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>。
[RFC4443] Conta, A., Deering, S., and M. Gupta, Ed., "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", STD 89, RFC 4443, DOI 10.17487/RFC4443, March 2006, <https://www.rfc-editor.org/info/rfc4443>.
[RFC4443] Conta、A.、Theering、S.およびM.Gupta、Internet Protocol Version 6（IPv6）仕様のICMPv6（ICMPv6）、STD 89、RFC 4443、DOI 10.17487 /RFC4443、2006年3月、<https://www.rfc-editor.org/info/rfc4443>。
[RFC4778] Kaeo, M., "Operational Security Current Practices in Internet Service Provider Environments", RFC 4778, DOI 10.17487/RFC4778, January 2007, <https://www.rfc-editor.org/info/rfc4778>.
[RFC4778] KAEO、M、「インターネットサービスプロバイダー環境における運用セキュリティの現在の実践」、RFC 4778、DOI 10.17487 / RFC4778、2007年1月、<https：//www.rfc-editor.org/info/rfc4778>。
[RFC5460] Stapp, M., "DHCPv6 Bulk Leasequery", RFC 5460, DOI 10.17487/RFC5460, February 2009, <https://www.rfc-editor.org/info/rfc5460>.
[RFC5460] Stapp、M.、 "DHCPV6 Bulk LeaseQuery"、RFC 5460、DOI 10.17487 / RFC5460、2009年2月、<https：//www.rfc-editor.org/info/rfc5460>。
[RFC7653] Raghuvanshi, D., Kinnear, K., and D. Kukrety, "DHCPv6 Active Leasequery", RFC 7653, DOI 10.17487/RFC7653, October 2015, <https://www.rfc-editor.org/info/rfc7653>.
[RFC7653] Raghuvanshi、D.、Kinnear、K.、およびD.Kukrety、 "DHCPV6 Active LeaseQuery"、RFC 7653、DOI 10.17487 / RFC7653、2015年10月、<https：//www.rfc-editor.org/info/RFC7653>。
[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>。
[RFC8213] Volz, B. and Y. Pal, "Security of Messages Exchanged between Servers and Relay Agents", RFC 8213, DOI 10.17487/RFC8213, August 2017, <https://www.rfc-editor.org/info/rfc8213>.
[RFC8213] volz、B.およびY PAL、「サーバーとリレーエージェント間で交換されるメッセージのセキュリティ」、RFC 8213、DOI 10.17487 / RFC8213、<https://www.rfc-editor.org/info/RFC8213>。
[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>。
[BCP38] Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000.
[BCP38] Ferguson、P.およびD. Senie、「ネットワーク入力フィルタリング：IP送信元アドレスのなりすましを採用するサービス拒否拒否」、BCP 38、RFC 2827、2000年5月。
<https://www.rfc-editor.org/info/bcp38>
[DOCSIS_3.1] CableLabs, "MAC and Upper Layer Protocols Interface Specification", Version 10, DOCSIS 3.1, January 2017, <https://www.cablelabs.com/specification/CM-SP-MULPIv3.1>.
[DOCSIS_3.1] CableLabs、 "MacおよびUpper Layer Interface Specification"、バージョン10、docsis 3.1、2017年1月、<https：//www.cablelabs.com/specification/cm-sp-mulpiv3.1>。
[TR-092] Broadband Forum, "Broadband Remote Access Server (BRAS) Requirements Document", Technical Report TR-092, August 2004, <https://www.broadband-forum.org/download/TR-092.pdf>.
[TR-092]ブロードバンドフォーラム、「ブロードバンドリモートアクセスサーバー（BRAS）要件文書」、テクニカルレポートTR-092、2004年8月、<https://www.broadband-forum.org/download/tr-092.pdf>。
Acknowledgements
謝辞
The authors of this document would like to thank Bernie Volz, Ted Lemon, and Michael Richardson for their valuable comments.
この文書の著者は、Bernie Volz、Ted Lemon、およびMichael Richardsonに貴重なコメントに感謝します。
Authors' Addresses
著者の住所
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 53227 Bonn Germany
Ian Farrer Deutsche Telekom AG Landgrabenweg 151 53227ボンドイツ
Email: ian.farrer@telekom.de
Naveen Kottapalli Benu Networks WeWork Galaxy, 43 Residency Road Bangalore 560025 Karnataka India
Naveen Cottapalli Benu Networks Wekengalaxy、43 Residency Road Bangalore 560025 Karnataka India
Email: nkottapalli@benunets.com
Martin Hunek Technical University of Liberec Studentska 1402/2 46017 Liberec Czech Republic
Liberec StudentykaのMartin Hunek Technical University Ka 1402/2 46017 Liberecチェコ共和国
Email: martin.hunek@tul.cz
Richard Patterson Sky UK Ltd. 1 Brick Lane London E1 6PU United Kingdom
Richard Patterson Sky UK Ltd. 1 Brick Lane London E1 6PUイギリス
Email: richard.patterson@sky.uk