Internet Engineering Task Force (IETF) W. Cheng, Ed.
Request for Comments: 10038 R. Han
Category: Standards Track China Mobile
ISSN: 2070-1721 C. Lin, Ed.
New H3C Technologies
D. Voyer
Cisco Systems
G. Zhang
China Mobile
August 2026
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and segment identifiers (SIDs) are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
SRv6 ネットワークでは、各 SRv6 セグメント エンドポイント ノードに SRv6 ロケーターを割り当てる必要があり、セグメント識別子 (SID) はこの SRv6 ロケーターのアドレス空間内で生成されます。このドキュメントでは、IPv6 用動的ホスト構成プロトコル (DHCPv6) を介して SRv6 ロケーターを SRv6 セグメント エンドポイント ノードに割り当てる方法について説明します。
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.
このドキュメントは Internet Engineering Task Force (IETF) の成果物です。これは IETF コミュニティのコンセンサスを表しています。この文書は公開レビューを受け、Internet Engineering Steering Group (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/rfc10038.
この文書の現在のステータス、正誤表、およびそれに対するフィードバックの提供方法に関する情報は、https://www.rfc-editor.org/info/rfc10038 で入手できます。
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright (c) 2026 IETF Trust および文書の著者として特定された人物。無断転載を禁じます。
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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.
この文書は、BCP 78 およびこの文書の発行日に有効な IETF 文書に関する IETF トラストの法的規定 (https://trustee.ietf.org/license-info) の対象となります。これらの文書には、この文書に関するお客様の権利と制限が記載されているため、注意深くお読みください。このドキュメントから抽出されたコード コンポーネントには、トラスト法的規定のセクション 4.e に記載されている改訂 BSD ライセンス テキストが含まれている必要があり、改訂 BSD ライセンスに記載されているように保証なしで提供されます。
1. Introduction
1.1. Requirements Language
2. Terminology
3. Motivation
4. DHCPv6 Extensions
4.1. Identity Association for SRv6 Locator Option
4.2. IA Locator Option
5. Process of Assigning the SRv6 Locator
5.1. Procedure of the SRv6 Locator
5.2. DHCPv6 Client Behavior
5.3. DHCPv6 Server Behavior
5.4. DHCPv6 Relay Agent Behavior
5.5. Advertisement of the SRv6 Locator Route
6. Operational Considerations
7. IANA Considerations
8. Security Considerations
9. References
9.1. Normative References
9.2. Informative References
Acknowledgements
Contributors
Authors' Addresses
The Segment Routing (SR) architecture [RFC8402] specifies how a node can steer a packet using an ordered list of instructions called "segments". These segments are identified using segment identifiers (SIDs).
セグメント ルーティング (SR) アーキテクチャ [RFC8402] は、「セグメント」と呼ばれる命令の順序付きリストを使用してノードがパケットを操作する方法を指定します。これらのセグメントは、セグメント識別子 (SID) を使用して識別されます。
SR can be instantiated on the IPv6 data plane using either the Segment Routing Header (SRH) defined in [RFC8754] or compressed segment lists defined in [RFC9800]. SR instantiation on the IPv6 data plane is referred to as SRv6.
SR は、[RFC8754] で定義されたセグメント ルーティング ヘッダー (SRH) または [RFC9800] で定義された圧縮セグメント リストを使用して、IPv6 データ プレーン上でインスタンス化できます。IPv6 データ プレーンでの SR インスタンス化は SRv6 と呼ばれます。
[RFC8986] introduces the SRv6 Network Programming concept and specifies the base set of SRv6 behaviors.
[RFC8986] は SRv6 ネットワーク プログラミングの概念を導入し、SRv6 の動作の基本セットを指定します。
In an SRv6 network, each SRv6 Segment Endpoint Node must be assigned an SRv6 Locator, and SIDs are generated within the address space of this SRv6 Locator. This document describes a method for assigning SRv6 Locators to SRv6 Segment Endpoint Nodes through the Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
SRv6 ネットワークでは、各 SRv6 セグメント エンドポイント ノードに SRv6 ロケーターを割り当てる必要があり、SID はこの SRv6 ロケーターのアドレス空間内で生成されます。このドキュメントでは、IPv6 用動的ホスト構成プロトコル (DHCPv6) を介して SRv6 ロケーターを SRv6 セグメント エンドポイント ノードに割り当てる方法について説明します。
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] で説明されているように解釈されます。
This document leverages the terms defined in [RFC9915] and [RFC8986]. The reader is assumed to be familiar with this terminology.
この文書では、[RFC9915] および [RFC8986] で定義されている用語を利用します。読者はこの用語に精通しているものと想定されています。
As shown in Figure 1, in the IP backbone network, access network devices are deployed for access users in different regions. This deployment assumes that all of the relevant components in Figure 1 are part of a single trusted SR domain. The Customer Premises Equipment (CPE) must be managed by the operator providing services or by a trusted partner. If the CPE is located within the customer premises, it must ensure that the device itself and its ports are under the same operator's administrative domain; otherwise, security risks may arise.
図 1 に示すように、IP バックボーン ネットワークでは、さまざまな地域のアクセス ユーザーに対してアクセス ネットワーク デバイスが展開されます。この展開では、図 1 のすべての関連コンポーネントが単一の信頼された SR ドメインの一部であることを前提としています。Customer Premises Equipment (CPE) は、サービスを提供するオペレーターまたは信頼できるパートナーによって管理される必要があります。CPE が顧客の敷地内にある場合は、デバイス自体とそのポートが同じ通信事業者の管理ドメインの下にあることを確認する必要があります。そうしないと、セキュリティ上のリスクが発生する可能性があります。
CPEs for access users are connected to the local metropolitan area network (MAN) in various ways. CPEs are responsible for assigning addresses to access users by requesting DHCPv6 Prefix Delegation (PD) from a DHCPv6 server, as specified in Section 6.3 of [RFC9915]. [RFC7084] and [RFC7368] describe such use in detail. The DHCPv6 server is usually enabled on or relayed by the Broadband Remote Access Server (BRAS).
アクセス ユーザーの CPE は、さまざまな方法でローカル メトロポリタン エリア ネットワーク (MAN) に接続されます。CPE は、[RFC9915] のセクション 6.3 で規定されているように、DHCPv6 サーバーから DHCPv6 プレフィックス委任 (PD) を要求することによって、アクセスユーザーにアドレスを割り当てる責任があります。[RFC7084] および [RFC7368] では、そのような使用方法が詳細に説明されています。DHCPv6 サーバーは通常、ブロードバンド リモート アクセス サーバー (BRAS) 上で有効になるか、ブロードバンド リモート アクセス サーバー (BRAS) によって中継されます。
After the DHCPv6 server allocates any delegated prefix, the BRAS will add a network route corresponding to the delegated prefix to a local routing table and distribute the network route to the upstream routers.
DHCPv6 サーバが委任されたプレフィックスを割り当てた後、BRAS は委任されたプレフィックスに対応するネットワーク ルートをローカル ルーティング テーブルに追加し、そのネットワーク ルートを上流ルータに配布します。
Metropolitan Area Network
+---------------------------+
| |
+------+ +------+ | +-----+ +-------+ |
|Host1 +-----+ CPE1 +----+--+BRAS1+--------+Router1| |
+------+ +------+ | +-----+ +---+---+ |
| | |
+---------------------+-----+
|
+--------+-------------+
| |
| Backbone Network |
| |
+--------+-------------+
|
+---------------------+-----+
| | |
+------+ +------+ | +-----+ +--+----+|
|Host2 +-----+ CPE2 +----+--+BRAS2+---------+Router2||
+------+ +------+ | +-----+ +-------+|
+---------------------------+
Figure 1: Telecom IPv6 Network
図 1: 通信 IPv6 ネットワーク
In this network, operators hope to achieve interconnection between access users through CPE-to-CPE SRv6 tunnels. Taking the service traffic from Host1 to Host2 as an example, CPE1 is the SRv6 ingress node and CPE2 is the SRv6 egress node. The SRv6 Locator should be configured on the CPEs. Other devices within the operator's network learn the SRv6 Locator routes of the CPEs.
このネットワークでは、通信事業者は、CPE 間の SRv6 トンネルを介してアクセス ユーザー間の相互接続を実現したいと考えています。ホスト 1 からホスト 2 へのサービス トラフィックを例にとると、CPE1 は SRv6 入力ノードであり、CPE2 は SRv6 出力ノードです。SRv6 ロケーターは CPE 上で設定する必要があります。事業者のネットワーク内の他のデバイスは、CPE の SRv6 ロケーター ルートを学習します。
At the same time, SRv6 policies need to be configured on CPEs to steer the service traffic between CPEs to the specified SRv6 forwarding path. The SRv6 policy can be manually configured statically (via command-line interface (CLI), the Network Configuration Protocol (NETCONF), YANG, APIs, etc.).
同時に、CPE 間のサービス トラフィックを指定された SRv6 転送パスに誘導するために、CPE 上で SRv6 ポリシーを構成する必要があります。SRv6 ポリシーは、(コマンドライン インターフェイス (CLI)、ネットワーク構成プロトコル (NETCONF)、YANG、API などを介して) 手動で静的に構成できます。
This document proposes a method for allocating SRv6 Locators to CPE via DHCPv6 and distributing SRv6 Locator routes using the DHCPv6 workflow. This approach simplifies network operation and maintains consistency with existing IPv6 address allocation mechanisms already deployed in such networks.
この文書では、DHCPv6 経由で SRv6 ロケーターを CPE に割り当て、DHCPv6 ワークフローを使用して SRv6 ロケーター ルートを配布する方法を提案します。このアプローチにより、ネットワーク運用が簡素化され、そのようなネットワークに既に展開されている既存の IPv6 アドレス割り当てメカニズムとの一貫性が維持されます。
The Identity Association for SRv6 Locator (IA_SRV6_LOCATOR) option is used to carry an IA_SRV6_LOCATOR, the parameters associated with the IA_SRV6_LOCATOR, and the SRv6 Locator associated with the IA_SRV6_LOCATOR.
SRv6 ロケーターの ID アソシエーション (IA_SRV6_LOCATOR) オプションは、IA_SRV6_LOCATOR、IA_SRV6_LOCATOR に関連付けられたパラメーター、および IA_SRV6_LOCATOR に関連付けられた SRv6 ロケーターを伝送するために使用されます。
The IA_SRV6_LOCATOR option can be carried in DHCPv6 Solicit, Advertise, Request, Reply, Renew, Release, and Rebind messages.
IA_SRV6_LOCATOR オプションは、DHCPv6 の要請、アドバタイズ、要求、応答、更新、リリース、および再バインド メッセージで伝送できます。
The format of the IA_SRV6_LOCATOR option is:
IA_SRV6_LOCATOR オプションの形式は次のとおりです。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IA_SRV6_LOCATOR | Option-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IAID (4 octets) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| T2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IA_SRV6_LOCATOR-Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: Identity Association for SRv6 Locator Option Format
図 2: SRv6 ロケーター オプションの形式の ID アソシエーション
Where:
ただし：
Option-Code:
オプションコード:
OPTION_IA_SRV6_LOCATOR (149), the option code for the Identity Association for SRv6 Locator option.
OPTION_IA_SRV6_LOCATOR (149)、SRv6 ロケーター オプションの ID アソシエーションのオプション コード。
Option-Len:
オプション-Len:
12 + the length of the IA_SRV6_LOCATOR-Options field in octets.
12 + IA_SRV6_LOCATOR-Options フィールドの長さ (オクテット単位)。
IAID:
IAID:
The unique identifier for this IA_SRV6_LOCATOR. The IAID MUST be unique among the identifiers for all of this client's IA_SRV6_LOCATORs. The number space for IA_SRV6_LOCATOR IAIDs is separate from the number space for other IA option types. A 4-octet field containing an unsigned integer.
この IA_SRV6_LOCATOR の一意の識別子。IAID は、このクライアントのすべての IA_SRV6_LOCATOR の識別子の中で一意である必要があります。IA_SRV6_LOCATOR IAID の数値スペースは、他の IA オプション タイプの数値スペースとは別のものです。符号なし整数を含む 4 オクテットのフィールド。
T1:
T1:
The time interval after which the client should contact the server from which the SRv6 Locators in the IA_SRV6_LOCATOR were obtained to extend the lifetimes of the SRv6 Locators to the IA_SRV6_LOCATOR. T1 is a time duration relative to the message reception time expressed in units of seconds. A 4-octet field containing an unsigned integer.
SRv6 ロケーターの有効期間を IA_SRV6_LOCATOR まで延長するために、クライアントが IA_SRV6_LOCATOR 内の SRv6 ロケーターの取得元サーバーに接続するまでの時間間隔。T1 は、メッセージ受信時刻に対する継続時間を秒単位で表します。符号なし整数を含む 4 オクテットのフィールド。
T2:
T2:
The time interval after which the client should contact any available server to extend the lifetimes of the SRv6 Locators assigned to the IA_SRV6_LOCATOR. T2 is a time duration relative to the message reception time expressed in units of seconds. A 4-octet field containing an unsigned integer.
IA_SRV6_LOCATOR に割り当てられた SRv6 ロケーターの有効期間を延長するために、クライアントが利用可能なサーバーに接続するまでの時間間隔。T2 は、メッセージ受信時刻に対する継続時間を秒単位で表します。符号なし整数を含む 4 オクテットのフィールド。
IA_SRV6_LOCATOR-Options:
IA_SRV6_LOCATOR-オプション:
Options associated with this IA_SRV6_LOCATOR. A variable-length field (12 octets less than the value in the Option-Len field).
この IA_SRV6_LOCATOR に関連付けられたオプション。可変長フィールド (Option-Len フィールドの値より 12 オクテット小さい)。
The IA_SRV6_LOCATOR-Options field encapsulates those options that are specific to this IA_SRV6_LOCATOR. For example, all of the IA Locator options (see Section 4.2) carrying the SRv6 Locators associated with this IA_SRV6_LOCATOR are in the IA_SRV6_LOCATOR-Options field.
IA_SRV6_LOCATOR-Options フィールドは、この IA_SRV6_LOCATOR に固有のオプションをカプセル化します。たとえば、この IA_SRV6_LOCATOR に関連付けられた SRv6 ロケーターを運ぶすべての IA ロケーター オプション (セクション 4.2 を参照) は、IA_SRV6_LOCATOR-Options フィールドにあります。
An IA_SRV6_LOCATOR option may only appear in the options area of a DHCP message. A DHCP message may contain multiple IA_SRV6_LOCATOR options (though each must have a unique IAID).
IA_SRV6_LOCATOR オプションは、DHCP メッセージのオプション領域にのみ表示されます。DHCP メッセージには複数の IA_SRV6_LOCATOR オプションが含まれる場合があります (ただし、それぞれに一意の IAID が必要です)。
The status of any operations involving this IA_SRV6_LOCATOR is indicated in a Status Code option (see Section 21.13 of [RFC9915]) in the IA_SRV6_LOCATOR-Options field.
この IA_SRV6_LOCATOR に関係する操作のステータスは、IA_SRV6_LOCATOR-Options フィールドのステータス コード オプション ([RFC9915] のセクション 21.13 を参照) に示されます。
Note that an IA_SRV6_LOCATOR has no explicit "lifetime" or "lease length" of its own. When the valid lifetimes of all of the SRv6 Locators in an IA_SRV6_LOCATOR have expired, the IA_SRV6_LOCATOR can be considered as having expired. The T1 and T2 fields are included to give the server explicit control over when a client should contact the server about a specific IA_SRV6_LOCATOR.
IA_SRV6_LOCATOR には、それ自体の明示的な「存続期間」や「リース期間」がないことに注意してください。IA_SRV6_LOCATOR 内のすべての SRv6 ロケーターの有効期限が切れると、IA_SRV6_LOCATOR は期限切れと見なされます。T1 フィールドと T2 フィールドは、クライアントが特定の IA_SRV6_LOCATOR に関してサーバーにいつ連絡するかをサーバーに明示的に制御するために含まれています。
In a message sent by a client to a server, the T1 and T2 fields SHOULD be set to 0. The server MUST ignore any values in these fields in messages received from a client.
クライアントからサーバーに送信されるメッセージでは、T1 および T2 フィールドは 0 に設定されるべきです (SHOULD)。サーバーは、クライアントから受信したメッセージ内のこれらのフィールドの値を無視しなければなりません (MUST)。
In a message sent by a server to a client, the client MUST use the values in the T1 and T2 fields for the T1 and T2 timers, unless values in those fields are 0. The values in the T1 and T2 fields are the number of seconds until T1 and T2.
サーバーからクライアントに送信されるメッセージでは、クライアントは、フィールドの値が 0 でない限り、T1 および T2 タイマーの T1 フィールドと T2 フィールドの値を使用しなければなりません (MUST)。 T1 フィールドと T2 フィールドの値は、T1 と T2 までの秒数です。
The server selects the T1 and T2 times to allow the client to extend the lifetimes of any SRv6 Locators in the IA_SRV6_LOCATOR before the lifetimes expire, even if the server is unavailable for some short period of time. Recommended values for T1 and T2 are 0.5 and 0.8 times the shortest preferred lifetime of the SRv6 Locators in the IA_SRV6_LOCATOR that the server is willing to extend, respectively. If the time at which the SRv6 Locators in an IA_SRV6_LOCATOR are to be renewed is to be left to the discretion of the client, the server sets T1 and T2 to 0. The client MUST follow the rules defined in Section 14.2 of [RFC9915].
サーバーは、サーバーが短期間利用できない場合でも、クライアントが IA_SRV6_LOCATOR 内の SRv6 ロケーターの有効期間を期限切れになる前に延長できるように、T1 および T2 時間を選択します。T1 と T2 の推奨値は、それぞれ、サーバーが延長を希望する IA_SRV6_LOCATOR 内の SRv6 ロケーターの最短の推奨ライフタイムの 0.5 倍と 0.8 倍です。IA_SRV6_LOCATOR 内の SRv6 ロケーターが更新される時刻がクライアントの裁量に任される場合、サーバーは T1 と T2 を 0 に設定します。クライアントは、[RFC9915] のセクション 14.2 で定義されている規則に従わなければなりません (MUST)。
If a client receives an IA_SRV6_LOCATOR with T1 greater than T2 and both T1 and T2 are greater than 0, the client discards the IA_SRV6_LOCATOR option and processes the remainder of the message as though the server had not included the IA_SRV6_LOCATOR option.
クライアントが T1 が T2 より大きく、T1 と T2 の両方が 0 より大きい IA_SRV6_LOCATOR を受信した場合、クライアントは IA_SRV6_LOCATOR オプションを破棄し、サーバーに IA_SRV6_LOCATOR オプションが含まれていないかのようにメッセージの残りの部分を処理します。
The IA Locator option is used to specify an SRv6 Locator associated with an IA_SRV6_LOCATOR. The IA Locator option MUST be encapsulated in the IA_SRV6_LOCATOR-Options field of an IA_SRV6_LOCATOR option (see Section 4.1). The terms "Locator Block" and "Locator Node" correspond to the B and N parts, respectively, of the SRv6 Locator that is defined in Section 3.1 of [RFC8986].
IA ロケーター オプションは、IA_SRV6_LOCATOR に関連付けられた SRv6 ロケーターを指定するために使用されます。IA ロケーター オプションは、IA_SRV6_LOCATOR オプションの IA_SRV6_LOCATOR-Options フィールドにカプセル化されなければなりません (セクション 4.1 を参照)。「ロケータ ブロック」および「ロケータ ノード」という用語は、[RFC8986] のセクション 3.1 で定義されている SRv6 ロケータの B 部分と N 部分にそれぞれ対応します。
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_IALOCATOR | Option-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Preferred-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Valid-lifetime |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Algorithm | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
| LB-Len | LN-Len | Fun-Len | Arg-Len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|
. SRv6-Locator .
. (up to 16 octets) .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. IALocator-Options .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: IA Locator Option Format
図 3: IA ロケーター オプションの形式
Where:
ただし：
Option-Code:
オプションコード:
OPTION_IALOCATOR (150), the option code for the IA Locator option.
OPTION_IALOCATOR (150)、IA ロケーター オプションのオプション コード。
Option-Len:
オプション-Len:
16 + the length of SRv6-Locator + the length of the IALocator-Options field in octets.
16 + SRv6-Locator の長さ + IALocator-Options フィールドの長さ (オクテット単位)。
Preferred-lifetime:
推奨存続期間:
The preferred lifetime for the SRv6 Locator in the option, expressed in units of seconds. A value of 0xffffffff represents "infinity" (see Section 7.7 of [RFC9915]). A 4-octet field containing an unsigned integer.
オプションの SRv6 ロケーターの推奨有効期間 (秒単位で表されます)。値 0xffffffff は「無限大」を表します ([RFC9915] のセクション 7.7 を参照)。符号なし整数を含む 4 オクテットのフィールド。
Valid-lifetime:
有効期間:
The valid lifetime for the SRv6 Locator in the option, expressed in units of seconds. A value of 0xffffffff represents "infinity". A 4-octet field containing an unsigned integer.
オプションの SRv6 ロケーターの有効な有効期間 (秒単位で表されます)。値 0xffffffff は「無限大」を表します。符号なし整数を含む 4 オクテットのフィールド。
Algorithm:
アルゴリズム：
A 1-octet unsigned integer. The algorithm associated with the SRv6 Locator from which the SID is allocated. Algorithm values are defined in the "IGP Algorithm Types" registry [RFC8665]. See also [RFC9350].
1 オクテットの符号なし整数。SID の割り当て元となる SRv6 ロケーターに関連付けられたアルゴリズム。アルゴリズム値は、「IGP Algorithm Types」レジストリ [RFC8665] で定義されています。[RFC9350]も参照してください。
Reserved:
予約済み：
A 3-octet unsigned integer. MUST be set to zero and ignored when received.
3 オクテットの符号なし整数。ゼロに設定し、受信時に無視する必要があります。
LB-Len:
LB-レン:
SRv6 SID Locator Block (LB) length in bits. A 1-octet unsigned integer.
SRv6 SID ロケーター ブロック (LB) の長さ (ビット単位)。1 オクテットの符号なし整数。
LN-Len:
LN-レン:
SRv6 SID Locator Node (LN) length in bits. A 1-octet unsigned integer.
SRv6 SID ロケーター ノード (LN) の長さ (ビット単位)。1 オクテットの符号なし整数。
Fun-Len:
ファンレン：
SRv6 SID function (FUNCT) length in bits. A 1-octet unsigned integer.
SRv6 SID 関数 (FUNCT) の長さ (ビット単位)。1 オクテットの符号なし整数。
Arg-Len:
引数-レン:
SRv6 SID arguments (ARG) length in bits. A 1-octet unsigned integer.
SRv6 SID 引数 (ARG) の長さ (ビット単位)。1 オクテットの符号なし整数。
SRv6-Locator:
SRv6 ロケーター:
0-16 octets. This field encodes the SRv6 Locator. The SRv6 Locator is encoded in the minimal number of octets for the SRv6 SID Locator length that is LB-Len plus LN-Len. Trailing bits MUST be set to zero and ignored when received.
0～16オクテット。このフィールドは SRv6 ロケーターをエンコードします。SRv6 ロケーターは、LB-Len に LN-Len を加えた SRv6 SID ロケーターの長さの最小オクテット数でエンコードされます。後続ビットはゼロに設定し、受信時に無視しなければなりません (MUST)。
IALocator-Options:
IALocator オプション:
Options associated with this SRv6 Locator. A variable-length field (determined by subtracting the length of SRv6-Locator from Option-Len minus 12). The status code NoSRv6LocatorAvail indicates the server has no locators available to assign to the IA_SRV6_LOCATOR(s).
この SRv6 ロケーターに関連付けられたオプション。可変長フィールド (Option-Len から 12 を引いた値から SRv6-Locator の長さを減算することによって決定されます)。ステータス コード NoSRv6LocatorAvail は、サーバーに IA_SRV6_LOCATOR に割り当てられるロケーターがないことを示します。
The SRv6 SID Locator length (LOC-Len) is LB-Len plus LN-Len.
SRv6 SID ロケーターの長さ (LOC-Len) は、LB-Len に LN-Len を加えたものです。
The sum of LB-Len, LN-Len, Fun-Len, and Arg-Len MUST NOT exceed 128 bits. The sum of LB-Len and LN-Len MUST NOT be zero. If either of these conditions are violated, the IA_SRV6_LOCATOR option MUST be marked as invalid, and the remainder of the message SHOULD be processed as if the packet did not include this option.
LB-Len、LN-Len、Fun-Len、Arg-Len の合計は 128 ビットを超えてはなりません。LB-Len と LN-Len の合計はゼロであってはなりません。これらの条件のいずれかに違反した場合、IA_SRV6_LOCATOR オプションは無効としてマークされなければならず (MUST)、メッセージの残りの部分はパケットにこのオプションが含まれていないかのように処理されるべきです (SHOULD)。
The values in the Preferred-lifetime and Valid-lifetime fields are the number of seconds remaining in each lifetime. The value of 0xffffffff for the preferred lifetime or the valid lifetime is taken to mean "infinity" and should be used carefully. The details about the use of lifetime values for assigned SRv6 Locators are the same as the ones specified for PD in Section 18.2.10.1 of [RFC9915].
Preferred-lifetime フィールドと Valid-lifetime フィールドの値は、各ライフタイムの残り秒数です。推奨ライフタイムまたは有効ライフタイムの値 0xffffffff は「無限」を意味するため、慎重に使用する必要があります。割り当てられた SRv6 ロケーターのライフタイム値の使用に関する詳細は、[RFC9915] のセクション 18.2.10.1 で PD に指定されているものと同じです。
An IA Locator option may appear only in an IA_SRV6_LOCATOR option. More than one IA Locator option can appear in a single IA_SRV6_LOCATOR option.
IA ロケーター オプションは、IA_SRV6_LOCATOR オプションにのみ表示されます。1 つの IA_SRV6_LOCATOR オプションに複数の IA ロケーター オプションを含めることができます。
The status of any operations involving this IA_SRV6_LOCATOR option is indicated in a Status Code option (see Section 21.13 of [RFC9915]) in the IALocator-Options field.
この IA_SRV6_LOCATOR オプションに関係する操作のステータスは、IALocator-Options フィールドのステータス コード オプション ([RFC9915] のセクション 21.13 を参照) に示されます。
Consistent with the PD mechanism [RFC9915], the DHCPv6 client obtains an SRv6 Locator via DHCPv6. The key message exchanges involved are Solicit, Request, Advertise, and Reply. Once the DHCPv6 server assigns an SRv6 Locator to the DHCPv6 client, it automatically adds the associated SRv6 Locator routes.
PD メカニズム [RFC9915] に従って、DHCPv6 クライアントは DHCPv6 経由で SRv6 ロケーターを取得します。関係する主なメッセージ交換は、要請、要求、アドバタイズ、および返信です。DHCPv6 サーバーが SRv6 ロケーターを DHCPv6 クライアントに割り当てると、関連付けられた SRv6 ロケーター ルートが自動的に追加されます。
Figure 4 illustrates the process of SRv6 Locator allocation through DHCPv6.
図 4 は、DHCPv6 を介した SRv6 ロケーター割り当てのプロセスを示しています。
DHCPv6 Client DHCPv6 Server
v v
| |
| |
____________ |\ |
____________ | +-----------+ |
| Solicit \|
| EmptyIALocator|
| |
| /|
| +----------+ |
| / Advertise |
|/ IALocator |
| |
|\ |
| +-----------+ |
| Request \|
| IALocator |
| /|
| +----------+ |
| / Reply |
|/ IALocator |
End of | |
4-message | |
exchange | | Issue Locator route locally
Use Locator to | | Distribute Locator route
alloc SRv6 SID | |
Figure 4: SRv6 Locator Exchange
図 4: SRv6 ロケーター交換
As specified in Section 18.2.1 of [RFC9915], the DHCPv6 client sends a Solicit message containing an IA_SRV6_LOCATOR option to request a locator. The client may include its preferred locator value within the IA_SRV6_LOCATOR option.
[RFC9915] のセクション 18.2.1 に規定されているように、DHCPv6 クライアントは、ロケーターを要求する IA_SRV6_LOCATOR オプションを含む要請メッセージを送信します。クライアントは、IA_SRV6_LOCATOR オプション内に優先ロケーター値を含めることができます。
The DHCPv6 server processes the Solicit message, assigns a locator to the client, and returns the allocated locator in an Advertise message with the IA_SRV6_LOCATOR option.
DHCPv6 サーバーは、要請メッセージを処理し、ロケーターをクライアントに割り当て、割り当てられたロケーターを IA_SRV6_LOCATOR オプションを使用したアドバタイズ メッセージで返します。
As specified in Section 18.2.2 of [RFC9915], upon receiving the Advertise message, the client accepts the assigned locator and sends a Request message with the IA_SRV6_LOCATOR option to confirm the requested locator.
[RFC9915] のセクション 18.2.2 に規定されているように、クライアントは Advertise メッセージを受信すると、割り当てられたロケータを受け入れ、要求されたロケータを確認するために IA_SRV6_LOCATOR オプションを指定した Request メッセージを送信します。
The server processes the Request message, confirms the locator assignment, and responds with a Reply message containing the IA_SRV6_LOCATOR option with the allocated locator.
サーバーは、要求メッセージを処理し、ロケーターの割り当てを確認し、割り当てられたロケーターを含む IA_SRV6_LOCATOR オプションを含む応答メッセージで応答します。
As described in Section 18.2.4 of [RFC9915], the client periodically sends a Renew message with the IA_SRV6_LOCATOR option to refresh the lease. The server processes the Renew message, updates the lease, and replies with a Reply message containing the IA_SRV6_LOCATOR option.
[RFC9915] のセクション 18.2.4 で説明されているように、クライアントはリースを更新するために IA_SRV6_LOCATOR オプションを指定した Renew メッセージを定期的に送信します。サーバーは Renew メッセージを処理し、リースを更新し、IA_SRV6_LOCATOR オプションを含む Reply メッセージで応答します。
As described in Section 18.2.5 of [RFC9915], if the client does not receive a Reply message before the T2 timer expires, it sends a Rebind message with the IA_SRV6_LOCATOR option to attempt lease renewal.
[RFC9915] のセクション 18.2.5 で説明されているように、クライアントは、T2 タイマーが期限切れになる前に応答メッセージを受信しなかった場合、IA_SRV6_LOCATOR オプションを指定した Rebind メッセージを送信して、リースの更新を試みます。
If the server responds with a Reply message, the client retains its allocated locator.
サーバーが Reply メッセージで応答すると、クライアントは割り当てられたロケーターを保持します。
If no response is received, the client considers the lease expired and restarts the process by sending a new Solicit message.
応答が受信されない場合、クライアントはリースの有効期限が切れたとみなし、新しい要請メッセージを送信してプロセスを再開します。
As described in Section 18.2.7 of [RFC9915], if the client is about to go offline, it sends a Release message with the IA_SRV6_LOCATOR option to relinquish the locator.
[RFC9915] のセクション 18.2.7 で説明されているように、クライアントがオフラインになろうとしている場合、ロケーターを放棄するために IA_SRV6_LOCATOR オプションを指定した Release メッセージを送信します。
Upon receiving a valid Release message, and when the SRv6 Locator in the message is valid, the server MUST remove the lease and free the locator, making it available for allocation to other clients. For detailed processing procedures, refer to Section 18.3.7 of [RFC9915].
有効な Release メッセージを受信し、メッセージ内の SRv6 ロケーターが有効な場合、サーバーはリースを削除してロケーターを解放し、他のクライアントに割り当てられるようにしなければなりません (MUST)。詳細な処理手順については、[RFC9915] のセクション 18.3.7 を参照してください。
A client uses the Solicit message to discover DHCPv6 servers configured to assign leases or return other configuration parameters on the link to which the client is attached.
クライアントは、要請メッセージを使用して、リースを割り当てるように構成された DHCPv6 サーバーを検出したり、クライアントが接続されているリンク上の他の構成パラメーターを返したりします。
A client uses Request, Renew, Rebind, Release, and Decline messages during the normal lifecycle of SRv6 Locator assignment.
クライアントは、SRv6 ロケーター割り当ての通常のライフサイクル中に、Request、Renew、Rebind、Release、および Decline メッセージを使用します。
In a message sent by a client to a server, the Preferred-lifetime and Valid-lifetime fields SHOULD be set to 0. The server MUST ignore any received values in these lifetime fields.
クライアントからサーバーに送信されるメッセージでは、Preferred-lifetime フィールドと Valid-lifetime フィールドを 0 に設定する必要があります (SHOULD)。サーバーは、これらのライフタイム フィールドで受信した値を無視しなければなりません (MUST)。
The client MUST NOT send an IA_SRV6_LOCATOR option with 0 in the LB-Len or LN-Len fields. The client MAY send non-zero values in the LB-Len and LN-Len fields and the unspecified value (::) in the SRv6-Locator field to indicate a preference for the size of the SRv6 Locator to be assigned. The LOC-Len (LB-Len + LN-Len) hint provided by a client is similar to the prefix-length hint in an IA_PD. Clients and servers are expected to follow the guidance provided in [RFC8168].
クライアントは、LB-Len フィールドまたは LN-Len フィールドに 0 を指定した IA_SRV6_LOCATOR オプションを送信してはなりません。クライアントは、割り当てられる SRv6 ロケーターのサイズの優先順位を示すために、LB-Len および LN-Len フィールドにゼロ以外の値を送信し、SRv6-Locator フィールドに未指定の値 (::) を送信してもよい(MAY)。クライアントによって提供される LOC-Len (LB-Len + LN-Len) ヒントは、IA_PD のプレフィックス長ヒントに似ています。クライアントとサーバーは、[RFC8168] で提供されるガイダンスに従うことが期待されます。
The client MUST discard any SRv6 Locators for which the preferred lifetime is greater than the valid lifetime.
クライアントは、優先ライフタイムが有効ライフタイムより長い SRv6 ロケーターを破棄しなければなりません (MUST)。
The process of requesting an SRv6 Locator is the same as that of requesting prefixes. When requesting an SRv6 Locator, the DHCPv6 client sends a Request message carrying the IA_SRV6_LOCATOR option to the DHCPv6 server.
SRv6 ロケーターを要求するプロセスは、プレフィックスを要求するプロセスと同じです。SRv6 ロケーターを要求する場合、DHCPv6 クライアントは IA_SRV6_LOCATOR オプションを含む要求メッセージを DHCPv6 サーバーに送信します。
Upon the receipt of a valid Reply message with the IA_SRV6_LOCATOR option in response to a Solicit with a Rapid Commit option, Request, Renew, or Rebind message, the client MUST process the Reply message according to the requirements of Section 18.2.10 of [RFC9915] and configure the assigned SRv6 Locator in the client device automatically.
Rapid Commit オプション付きの Solicit、Request、Renew、または Rebind メッセージに対する IA_SRV6_LOCATOR オプション付きの有効な Reply メッセージを受信した場合、クライアントは [RFC9915] のセクション 18.2.10 の要件に従ってその Reply メッセージを処理し、割り当てられた SRv6 Locator をクライアントデバイスに自動的に設定しなければなりません (MUST)。
DHCP allows a client to obtain multiple addresses as specified in Section 6.5 of [RFC9915]. The same principle applies to SRv6 Locator assignment. In scenarios requiring multiple allocations (e.g., when multiple SRv6 Locators are needed for distinct services, such as best-effort and low-latency traffic, each with a different algorithm), the allocation policy between the DHCPv6 client and DHCPv6 server MUST remain consistent. After obtaining the SRv6 Locator assigned by the DHCPv6 server, how to assign local SRv6 SIDs based on this SRv6 Locator, how to use multiple assigned SRv6 Locators, and how to advertise these SRv6 SIDs to the rest of the network are not within the scope of this document. However, and consistent with the guidance in Section 16 of [RFC7227], the client MUST NOT make any assumption about the ordering of locators or infer any service logic from these locators.
DHCP を使用すると、[RFC9915] のセクション 6.5 で指定されているように、クライアントは複数のアドレスを取得できます。同じ原則が SRv6 ロケーターの割り当てにも当てはまります。複数の割り当てが必要なシナリオ（たとえば、ベストエフォートトラフィックや低遅延トラフィックなど、それぞれ異なるアルゴリズムを持つ個別のサービスに複数の SRv6 ロケーターが必要な場合）では、DHCPv6 クライアントと DHCPv6 サーバー間の割り当てポリシーは一貫性を保たなければなりません（MUST）。DHCPv6 サーバーによって割り当てられた SRv6 ロケーターを取得した後、この SRv6 ロケーターに基づいてローカル SRv6 SID を割り当てる方法、割り当てられた複数の SRv6 ロケーターを使用する方法、およびこれらの SRv6 SID をネットワークの残りの部分にアドバタイズする方法は、このドキュメントの範囲外です。ただし、[RFC7227] のセクション 16 のガイダンスに従って、クライアントはロケーターの順序についていかなる仮定を行ったり、これらのロケーターからサービス ロジックを推測したりしてはなりません (MUST NOT)。
The client uses the SRv6 Locators and associated information from any IAs that do not contain a Status Code option with the NoSRv6LocatorAvail status code. The client MAY include the IAs for which it received the NoSRv6LocatorAvail status code, with no SRv6 Locators, in subsequent Renew and Rebind messages sent to the server, to retry obtaining the SRv6 Locators for these IAs.
クライアントは、NoSRv6LocatorAvail ステータス コードを持つステータス コード オプションを含まない IA からの SRv6 ロケーターと関連情報を使用します。クライアントは、SRv6 ロケーターなしで NoSRv6LocatorAvail ステータス コードを受信した IA を、サーバーに送信される後続の Renew および Rebind メッセージに含めて、これらの IA の SRv6 ロケーターの取得を再試行してもよい(MAY)。
To extend the preferred and valid lifetimes for the assigned SRv6 Locators or obtain new assigned SRv6 Locators, the client sends a Renew/Rebind message to the server with the IA_SRV6_LOCATOR option as specified in Sections 18.2.4 and 18.2.5 of [RFC9915].
割り当てられた SRv6 ロケータの優先有効期間を延長するか、新しく割り当てられた SRv6 ロケータを取得するには、[RFC9915] のセクション 18.2.4 および 18.2.5 で指定されているように、クライアントは IA_SRV6_LOCATOR オプションを指定して Renew/Rebind メッセージをサーバーに送信します。
If the client no longer uses the SRv6 Locator, the client can actively send a Release message to notify the server to reclaim the SRv6 Locator and delete the corresponding SRv6 Locator. The client MUST include options containing the IAs for the SRv6 Locators it is releasing in the IA_SRV6_LOCATOR-Options field of the IA_SRV6_LOCATOR option.
クライアントが SRv6 ロケーターを使用しなくなった場合、クライアントは積極的にリリース メッセージを送信して、SRv6 ロケーターを再利用し、対応する SRv6 ロケーターを削除するようにサーバーに通知できます。クライアントは、IA_SRV6_LOCATOR オプションの IA_SRV6_LOCATOR-Options フィールドに、リリースする SRv6 ロケーターの IA を含むオプションを含めなければなりません (MUST)。
A client can explicitly request multiple SRv6 Locator prefixes by sending multiple IA_SRV6_LOCATOR options. A client can send multiple IA_SRV6_LOCATOR options in its initial transmissions. Alternatively, it can send an extra Request message with additional new IA_SRV6_LOCATOR options (or include them in a Renew message).
クライアントは、複数の IA_SRV6_LOCATOR オプションを送信することで、複数の SRv6 ロケーター プレフィックスを明示的に要求できます。クライアントは、最初の送信で複数の IA_SRV6_LOCATOR オプションを送信できます。あるいは、追加の新しい IA_SRV6_LOCATOR オプションを含む追加の Request メッセージを送信することもできます (または、それらを Renew メッセージに含めます)。
DHCP allows a client to request new SRv6 Locators to be assigned by sending additional new IA_SRV6_LOCATOR options. However, a typical operator usually prefers to assign a single, larger prefix. In most deployments, it is RECOMMENDED that the client request a larger SRv6 Locator in its initial transmissions rather than request additional SRv6 Locators later on.
DHCP では、クライアントが追加の新しい IA_SRV6_LOCATOR オプションを送信することで、新しい SRv6 ロケーターの割り当てを要求できます。ただし、一般的なオペレータは通常、単一のより大きなプレフィックスを割り当てることを好みます。ほとんどの展開では、クライアントは後で追加の SRv6 ロケーターを要求するのではなく、最初の送信でより大きな SRv6 ロケーターを要求することが推奨されます。
When the server receives a valid Request message or a valid Solicit message with a Rapid Commit option, the server creates the bindings for that client according to the server's policy and configuration information and records the IAs and other information requested by the client.
サーバーが有効な要求メッセージまたは高速コミット オプションを含む有効な要請メッセージを受信すると、サーバーはサーバーのポリシーおよび構成情報に従ってそのクライアントのバインディングを作成し、クライアントによって要求された IA およびその他の情報を記録します。
The DHCPv6 server treats the SRv6 Locator as the prefix of the prefix pool. Upon the receipt of the IA_SRV6_LOCATOR option, the server searches the SRv6 Locator prefix pool and allocates appropriate SRv6 Locators for the client.
DHCPv6 サーバーは、SRv6 ロケーターをプレフィックス プールのプレフィックスとして扱います。IA_SRV6_LOCATOR オプションを受信すると、サーバーは SRv6 ロケーター プレフィックス プールを検索し、クライアントに適切な SRv6 ロケーターを割り当てます。
If there is an assignable SRv6 Locator, the server creates the SRv6 Locator binding entry for that client according to the server's policy and configuration information and constructs a Reply message that includes an IA_SRV6_LOCATOR option with the SRv6 Locator information (including LB-Len, LN-Len, Fun-Len, and Arg-Len) assigned to the client.
割り当て可能な SRv6 ロケーターがある場合、サーバーは、サーバーのポリシーおよび構成情報に従って、そのクライアントの SRv6 ロケーター バインディング エントリを作成し、クライアントに割り当てられた SRv6 ロケーター情報 (LB-Len、LN-Len、Fun-Len、および Arg-Len を含む) を含む IA_SRV6_LOCATOR オプションを含む応答メッセージを構築します。
The IA_SRV6_LOCATOR option is filled with the SRv6 Locator information assigned to the client. The IA_SRV6_LOCATOR option populates the LB-Len, LN-Len, Fun-Len, and Arg-Len fields.
IA_SRV6_LOCATOR オプションには、クライアントに割り当てられた SRv6 ロケーター情報が入力されます。IA_SRV6_LOCATOR オプションは、LB-Len、LN-Len、Fun-Len、および Arg-Len フィールドに値を入力します。
Upon receiving a Release message from the client or when the SRv6 Locator lease expires, the server reclaims the SRv6 Locator prefix resource and deletes the corresponding binding entry.
クライアントからリリース メッセージを受信するか、SRv6 ロケーターのリース期限が切れると、サーバーは SRv6 ロケーター プレフィックス リソースを再利用し、対応するバインディング エントリを削除します。
For any IA_SRV6_LOCATOR option in the Request message to which the server cannot assign any SRv6 Locators, the server MUST return the IA_SRV6_LOCATOR option in the Reply message with no SRv6 Locator prefixes in the IA_SRV6_LOCATOR and with a Status Code option containing status code NoSRv6LocatorAvail in the IA_SRV6_LOCATOR.
サーバーが SRv6 ロケーターを割り当てることができない要求メッセージ内の IA_SRV6_LOCATOR オプションについては、サーバーは、IA_SRV6_LOCATOR に SRv6 ロケーター プレフィックスを持たず、IA_SRV6_LOCATOR にステータス コード NoSRv6LocatorAvail を含むステータス コード オプションを付けて、応答メッセージ内の IA_SRV6_LOCATOR オプションを返さなければなりません。
After receiving a DHCP message with multiple IA_SRV6_LOCATOR options at the same time, whether the server can assign multiple SRv6 Locators to the client depends on the server policy, which is out of scope for this document. Note that the configuration behavior of the server and client SHOULD be consistent (e.g., "clients and servers assign a single locator unless explicitly configured").
複数の IA_SRV6_LOCATOR オプションを含む DHCP メッセージを同時に受信した後、サーバーが複数の SRv6 ロケーターをクライアントに割り当てられるかどうかは、サーバー ポリシーによって異なりますが、このドキュメントの範囲外です。サーバーとクライアントの設定動作は一貫している必要があることに注意してください (たとえば、「明示的に設定されていない限り、クライアントとサーバーは単一のロケーターを割り当てる」)。
The allocation of SRv6 Locators to clients that reside on a different link from the server requires a DHCPv6 relay agent. A DHCPv6 relay agent forwards messages containing IA_SRV6_LOCATOR options in the same way as it would relay addresses (i.e., per Sections 19.1.1 and 19.1.2 of [RFC9915]).
サーバーとは異なるリンク上に存在するクライアントに SRv6 ロケーターを割り当てるには、DHCPv6 リレー エージェントが必要です。DHCPv6 リレー エージェントは、アドレスを中継する場合と同じ方法で (つまり、[RFC9915] のセクション 19.1.1 および 19.1.2 に従って) IA_SRV6_LOCATOR オプションを含むメッセージを転送します。
+-------------+ +------------+ +-------------+
+DHCPv6 Client+-------+DHCPv6 Relay+-------+DHCPv6 Server|
+-------------+ +------+-----+ +-------------+
|
|
+------+-----+
| Backbone |
| Network |
+------------+
Figure 5: SRv6 Locator Exchange Through DHCPv6 Relay
図 5: DHCPv6 リレーを介した SRv6 ロケーター交換
This section describes the processing of SRv6 Locator routes.
このセクションでは、SRv6 ロケーター ルートの処理について説明します。
As shown in Figure 5, when a DHCPv6 Relay or DHCPv6 server receives an SRv6 Locator allocation request from a client, it MAY assign an SRv6 Locator to the client and install a corresponding SRv6 Locator route locally. The next hop of this route SHOULD point to the requesting client. Through this route, the DHCPv6 Relay or DHCPv6 server can access the Host under the DHCPv6 client, while the DHCPv6 Relay or DHCPv6 server MAY then advertise this route via traditional routing protocols (e.g., an IGP) to allow other routers to learn it.
図 5 に示すように、DHCPv6 リレーまたは DHCPv6 サーバーがクライアントから SRv6 ロケーター割り当て要求を受信すると、SRv6 ロケーターをクライアントに割り当て、対応する SRv6 ロケーター ルートをローカルにインストールしてもよい(MAY)。このルートの次のホップは、要求元のクライアントを指す必要があります (SHOULD)。このルートを通じて、DHCPv6 リレーまたは DHCPv6 サーバーは DHCPv6 クライアントの下のホストにアクセスできますが、DHCPv6 リレーまたは DHCPv6 サーバーは、他のルーターがそれを学習できるように、従来のルーティング プロトコル (例: IGP) を介してこのルートをアドバタイズしてもよい(MAY)。
SRv6 Locators with an Algorithm value of zero can be advertised as normal IP prefix reachability information. Conversely, SRv6 Locators with a non-zero Algorithm value MUST be advertised using the Locators TLV as defined in [RFC9352] and [RFC9513].
アルゴリズム値が 0 の SRv6 ロケーターは、通常の IP プレフィックス到達可能性情報としてアドバタイズできます。逆に、ゼロ以外のアルゴリズム値を持つ SRv6 ロケーターは、[RFC9352] および [RFC9513] で定義されているロケーター TLV を使用してアドバタイズしなければなりません (MUST)。
Upon receiving an SRv6 Locator release request from the client, the DHCPv6 Relay or DHCPv6 server MUST release the allocated SRv6 Locator, remove the local SRv6 Locator route, and withdraw the previously advertised SRv6 Locator route via traditional routing protocols.
クライアントから SRv6 ロケーター解放要求を受信すると、DHCPv6 リレーまたは DHCPv6 サーバーは、割り当てられた SRv6 ロケーターを解放し、ローカル SRv6 ロケーター ルートを削除し、従来のルーティング プロトコル経由で以前にアドバタイズされた SRv6 ロケーター ルートを取り消さなければなりません (MUST)。
DHCPv6 Client-------(DHCPv6 Relay/DHCPv6 Server)-------------Router
Alloc Locator --> Add SRv6 Locator route
Advertise SRv6 Locator route -->
Release Locator--> Del SRv6 Locator route
Withdraw SRv6 Locator route -->
Figure 6: Advertisement of the SRv6 Locator Route
図 6: SRv6 ロケーター ルートのアドバタイズメント
This section outlines some operational considerations for assigning SRv6 Locators through DHCPv6.
このセクションでは、DHCPv6 を介して SRv6 ロケーターを割り当てるための運用上の考慮事項について概説します。
The SRv6 Locator can be used to allocate SIDs with SR Endpoint Behaviors as defined in [RFC8986] and also to allocate SIDs with the NEXT and REPLACE flavors defined in [RFC9800]. Operators can allocate corresponding SIDs based on the LB and LN lengths of the SRv6 Locator, as well as local policies.
SRv6 ロケーターを使用すると、[RFC8986] で定義されている SR エンドポイント動作で SID を割り当てることができ、また、[RFC9800] で定義されている NEXT および REPLACE フレーバーで SID を割り当てることもできます。オペレータは、SRv6 ロケーターの LB および LN 長、およびローカル ポリシーに基づいて、対応する SID を割り当てることができます。
When processing the SRv6 Locator defined in this document, if an error occurs in packet processing, SRv6 Locator allocation fails, or lease aging is handled, the DHCPv6 client and DHCPv6 server SHOULD log or record these SRv6 Locators as required by local policy.
この文書で定義されている SRv6 ロケータを処理する際、パケット処理でエラーが発生した場合、SRv6 ロケータの割り当てが失敗した場合、またはリースのエージングが処理された場合、DHCPv6 クライアントと DHCPv6 サーバーはローカル ポリシーの要求に応じてこれらの SRv6 ロケータをログまたは記録する必要があります (SHOULD)。
Section 4.4 of [RFC8987] provides necessary functional requirements for operating DHCPv6 relays with PD. These requirements also apply to the allocation of SRv6 Locators in DHCPv6 Relay scenarios.
[RFC8987] のセクション 4.4 では、PD で DHCPv6 リレーを動作させるために必要な機能要件が規定されています。これらの要件は、DHCPv6 リレー シナリオでの SRv6 ロケーターの割り当てにも適用されます。
Routing Stability is an additional operational consideration. Network operators may advertise an aggregated route rather than individual prefixes in certain deployments to optimize Routing Information Base (RIB) performance. The withdrawal of specific routes triggered by address releases may lead to a reduction in advertised routes. An alternative approach is to implement a policy that governs this behavior. In such cases, delegating routers will discard packets destined for specific prefixes that are not "delegated" on the customer-facing interface.
ルーティングの安定性も運用上の追加の考慮事項です。ネットワーク オペレータは、ルーティング情報ベース (RIB) のパフォーマンスを最適化するために、特定の展開において個々のプレフィックスではなく集約されたルートをアドバタイズする場合があります。アドレス解放を契機とした特定経路の廃止は、広告経路の減少につながる可能性があります。別のアプローチは、この動作を管理するポリシーを実装することです。このような場合、委任ルーターは、顧客側インターフェイスで「委任」されていない特定のプレフィックス宛てのパケットを破棄します。
IANA has assigned the following DHCPv6 option codes in the "Option Codes" registry at <https://www.iana.org/assignments/ dhcpv6-parameters>:
IANA は、<https://www.iana.org/assignments/dhcpv6-parameters> の「オプション コード」レジストリで次の DHCPv6 オプション コードを割り当てました。
+=======+========================+========+===========+===========+
| Value | Description | Client | Singleton | Reference |
| | | ORO | Option | |
+=======+========================+========+===========+===========+
| 149 | OPTION_IA_SRV6_LOCATOR | No | No | RFC 10038 |
+-------+------------------------+--------+-----------+-----------+
| 150 | OPTION_IALOCATOR | No | No | RFC 10038 |
+-------+------------------------+--------+-----------+-----------+
Table 1
IANA has also assigned the following DHCPv6 status code in the "Status Codes" registry at <http://www.iana.org/assignments/ dhcpv6-parameters>:
IANA は、<http://www.iana.org/assignments/dhcpv6-parameters> の「ステータス コード」レジストリで次の DHCPv6 ステータス コードも割り当てています。
+======+====================+===========+
| Code | Name | Reference |
+======+====================+===========+
| 23 | NoSRv6LocatorAvail | RFC 10038 |
+------+--------------------+-----------+
Table 2
See Section 22 of [RFC9915] and Section 23 of [RFC7227] for the DHCP security considerations. See [RFC8200] for the IPv6 security considerations.
DHCP のセキュリティに関する考慮事項については、[RFC9915] のセクション 22 および [RFC7227] のセクション 23 を参照してください。IPv6 のセキュリティに関する考慮事項については、[RFC8200] を参照してください。
As discussed in Section 22 of [RFC9915], "DHCP lacks end-to-end encryption between clients and servers; thus, hijacking, tampering, and eavesdropping attacks are all possible as a result."
[RFC9915] のセクション 22 で説明されているように、「DHCP にはクライアントとサーバー間のエンドツーエンド暗号化が欠如しているため、結果としてハイジャック、改ざん、および盗聴攻撃がすべて可能になります。」
In some network environments, it is possible to secure the communication between clients and servers, as discussed in Section 22 of [RFC9915].
一部のネットワーク環境では、[RFC9915] のセクション 22 で説明されているように、クライアントとサーバー間の通信を保護することが可能です。
If not all parties use this mechanism to obtain an SRv6 Locator from the DHCPv6 server, there is the possibility of the same SRv6 Locator being used by more than one device. Note that this issue could exist on these networks even if DHCP were not used to obtain the SRv6 Locator. A potential mitigation is to partition the available address prefixes, ensuring that different allocation mechanisms draw from non-overlapping pools.
すべての当事者がこのメカニズムを使用して DHCPv6 サーバーから SRv6 ロケーターを取得しない場合、同じ SRv6 ロケーターが複数のデバイスで使用される可能性があります。SRv6 ロケーターの取得に DHCP が使用されなかった場合でも、この問題はこれらのネットワークに存在する可能性があることに注意してください。潜在的な軽減策は、使用可能なアドレス プレフィックスを分割し、異なる割り当てメカニズムが重複しないプールから確実に取得されるようにすることです。
Server implementations SHOULD consider configuration options to limit the maximum number of SRv6 Locators to allocate (both in a single request and in total) to a client. However, note that this does not prevent a bad client actor from pretending to be many different clients and consuming all available SRv6 Locators.
サーバー実装は、クライアントに割り当てる SRv6 ロケーターの最大数 (単一のリクエストと合計の両方) を制限するための構成オプションを考慮する必要があります (SHOULD)。ただし、これによって、悪意のあるクライアント アクターがさまざまなクライアントになりすまして、利用可能なすべての SRv6 ロケーターを消費することを防ぐことはできないことに注意してください。
The SR domain is a trusted domain, as defined in Sections 2 and 8.2 of [RFC8402]. Having such a well-defined trust boundary is necessary in order to operate SRv6-based services for internal traffic while preventing any external traffic from accessing or exploiting the SRv6-based services. Care and rigor in IPv6 address allocation for use for SRv6 SID allocations and network infrastructure addresses, as distinct from IPv6 addresses allocated for end users and systems (as illustrated in Section 5.1 of [RFC8754]), can provide the clear distinction between internal and external address space that is required to maintain the integrity and security of the SRv6 domain.
SR ドメインは、[RFC8402] のセクション 2 および 8.2 で定義されている信頼できるドメインです。このように明確に定義された信頼境界は、外部トラフィックによる SRv6 ベースのサービスへのアクセスや悪用を防ぎながら、内部トラフィックに対して SRv6 ベースのサービスを運用するために必要です。エンドユーザーやシステムに割り当てられる IPv6 アドレス ([RFC8754] のセクション 5.1 に示されているように) とは異なり、SRv6 SID 割り当ておよびネットワーク インフラストラクチャ アドレスに使用する IPv6 アドレス割り当てを注意深く厳密に行うことにより、SRv6 ドメインの整合性とセキュリティを維持するために必要な内部アドレス空間と外部アドレス空間を明確に区別できます。
When assigning SRv6 Locators to SRv6 Segment Endpoint Nodes using DHCPv6 as specified in this document, DHCPv6 clients and DHCPv6 servers MUST operate within a single trusted SR domain. As a border node device, a DHCPv6 client may reside in customer premises, while the DHCPv6 server is located within the provider network. Although they belong to the same trusted SR domain, the DHCPv6 client MUST implement appropriate traffic filtering capabilities on both its internal and external interfaces, as required by Section 5.1 of [RFC8754].
このドキュメントで指定されているように、DHCPv6 を使用して SRv6 ロケーターを SRv6 セグメント エンドポイント ノードに割り当てる場合、DHCPv6 クライアントと DHCPv6 サーバーは、単一の信頼された SR ドメイン内で動作しなければなりません。DHCPv6 クライアントはボーダー ノード デバイスとして顧客の敷地内に常駐し、DHCPv6 サーバーはプロバイダー ネットワーク内に配置されます。それらは同じ信頼された SR ドメインに属していますが、DHCPv6 クライアントは [RFC8754] のセクション 5.1 で要求されているように、内部インターフェースと外部インターフェースの両方に適切なトラフィック フィルタリング機能を実装しなければなりません (MUST)。
[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>.
[RFC7227] Hankins, D., Mrugalski, T., Siodelski, M., Jiang, S., and
S. Krishnan, "Guidelines for Creating New DHCPv6 Options",
BCP 187, RFC 7227, DOI 10.17487/RFC7227, May 2014,
<https://www.rfc-editor.org/info/rfc7227>.
[RFC8168] Li, T., Liu, C., and Y. Cui, "DHCPv6 Prefix-Length Hint
Issues", RFC 8168, DOI 10.17487/RFC8168, May 2017,
<https://www.rfc-editor.org/info/rfc8168>.
[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>.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", STD 86, RFC 8200,
DOI 10.17487/RFC8200, July 2017,
<https://www.rfc-editor.org/info/rfc8200>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>.
[RFC8665] Psenak, P., Ed., Previdi, S., Ed., Filsfils, C., Gredler,
H., Shakir, R., Henderickx, W., and J. Tantsura, "OSPF
Extensions for Segment Routing", RFC 8665,
DOI 10.17487/RFC8665, December 2019,
<https://www.rfc-editor.org/info/rfc8665>.
[RFC8754] Filsfils, C., Ed., Dukes, D., Ed., Previdi, S., Leddy, J.,
Matsushima, S., and D. Voyer, "IPv6 Segment Routing Header
(SRH)", RFC 8754, DOI 10.17487/RFC8754, March 2020,
<https://www.rfc-editor.org/info/rfc8754>.
[RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer,
D., Matsushima, S., and Z. Li, "Segment Routing over IPv6
(SRv6) Network Programming", RFC 8986,
DOI 10.17487/RFC8986, February 2021,
<https://www.rfc-editor.org/info/rfc8986>.
[RFC8987] Farrer, I., Kottapalli, N., Hunek, M., and R. Patterson,
"DHCPv6 Prefix Delegating Relay Requirements", RFC 8987,
DOI 10.17487/RFC8987, February 2021,
<https://www.rfc-editor.org/info/rfc8987>.
[RFC9350] Psenak, P., Ed., Hegde, S., Filsfils, C., Talaulikar, K.,
and A. Gulko, "IGP Flexible Algorithm", RFC 9350,
DOI 10.17487/RFC9350, February 2023,
<https://www.rfc-editor.org/info/rfc9350>.
[RFC9352] Psenak, P., Ed., Filsfils, C., Bashandy, A., Decraene, B.,
and Z. Hu, "IS-IS Extensions to Support Segment Routing
over the IPv6 Data Plane", RFC 9352, DOI 10.17487/RFC9352,
February 2023, <https://www.rfc-editor.org/info/rfc9352>.
[RFC9513] Li, Z., Hu, Z., Talaulikar, K., Ed., and P. Psenak,
"OSPFv3 Extensions for Segment Routing over IPv6 (SRv6)",
RFC 9513, DOI 10.17487/RFC9513, December 2023,
<https://www.rfc-editor.org/info/rfc9513>.
[RFC9800] Cheng, W., Ed., Filsfils, C., Li, Z., Decraene, B., and F.
Clad, Ed., "Compressed SRv6 Segment List Encoding",
RFC 9800, DOI 10.17487/RFC9800, June 2025,
<https://www.rfc-editor.org/info/rfc9800>.
[RFC9915] Mrugalski, T., Volz, B., Richardson, M., Jiang, S., and T.
Winters, "Dynamic Host Configuration Protocol for IPv6
(DHCPv6)", STD 102, RFC 9915, DOI 10.17487/RFC9915,
January 2026, <https://www.rfc-editor.org/info/rfc9915>.
[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>.
[RFC7368] Chown, T., Ed., Arkko, J., Brandt, A., Troan, O., and J.
Weil, "IPv6 Home Networking Architecture Principles",
RFC 7368, DOI 10.17487/RFC7368, October 2014,
<https://www.rfc-editor.org/info/rfc7368>.
The authors would like to thank Gunter Van de Velde, Ketan Talaulikar, Mohamed Boucadair, Chongfeng Xie, Joel Halpern, Robert Raszuk, Aihua Liu, Cheng Li, Xuewei Wang, Hao Li, Junjie Wang, Mengxiao Chen, Fang Gao, Aijun Wang, Xinxin Yi, Shenchao Xu, Yisong Liu, Xueshun Wang, Min Xiao, Liyan Gong, Linda Dunbar, Quan Xiong, Adrian Farrel, and Bernie Volz for their comments on this document.
著者らは、Gunter Van de Velde、Ketan Talaulikar、Mohamed Boucadair、Chongfeng Xie、Joel Halpern、Robert Raszuk、Aihua Liu、Cheng Li、Xuewei Wang、Hao Li、Junjie Wang、Mengxiao Chen、Fang Gao、Aijun Wang、Xinxin Yi、Shenchao Xu、Yisong Liu、Xueshun に感謝します。この文書に関してコメントを寄せてくださった Wang、Min Xiao、Liyan Gong、Linda Dunbar、Quan Xiong、Adrian Farrel、Bernie Volz 氏。
Yuanxiang Qiu
New H3C Technologies
Email: qiuyuanxiang@h3c.com
Weiqiang Cheng (editor)
China Mobile
Beijing
China
Email: chengweiqiang@chinamobile.com
Ruibo Han
China Mobile
Beijing
China
Email: hanruibo@chinamobile.com
Changwang Lin (editor)
New H3C Technologies
Beijing
China
Email: linchangwang.04414@h3c.com
Daniel Voyer
Cisco Systems
Montreal
Canada
Email: davoyer@cisco.com
Geng Zhang
China Mobile
Beijing
China
Email: zhanggeng@chinamobile.com