Internet Engineering Task Force (IETF) R. Bonica
Request for Comments: 9837 Juniper Networks
Category: Experimental X. Li
ISSN: 2070-1721 CERNET Center/Tsinghua University
A. Farrel
Old Dog Consulting
Y. Kamite
NTT DOCOMO BUSINESS
L. Jalil
Verizon
August 2025
This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option. The experimental IPv6 Destination Option is called the VPN Service Option.
このドキュメントでは、VPNサービス情報が実験的なIPv6宛先オプションでエンコードされる実験について説明します。実験的なIPv6宛先オプションは、VPNサービスオプションと呼ばれます。
One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment.
この実験の目的の1つは、VPNサービスオプションを生産ネットワークに展開できることを実証することです。別の目的は、このドキュメントで説明されているセキュリティ対策がVPNを保護するのに十分であることを実証することです。最後に、この文書は実験の複製を奨励しています。
This document is not an Internet Standards Track specification; it is published for examination, experimental implementation, and evaluation.
このドキュメントは、インターネット標準の追跡仕様ではありません。試験、実験的実装、および評価のために公開されています。
This document defines an Experimental Protocol for the Internet community. 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). Not all documents approved by the IESG are candidates for any level of Internet Standard; see Section 2 of RFC 7841.
このドキュメントでは、インターネットコミュニティ向けの実験プロトコルを定義しています。このドキュメントは、インターネットエンジニアリングタスクフォース（IETF）の製品です。IETFコミュニティのコンセンサスを表しています。公開レビューを受けており、インターネットエンジニアリングステアリンググループ（IESG）からの出版が承認されています。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/rfc9837.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、https://www.rfc-editor.org/info/rfc9837で取得できます。
Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（c）2025 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ドキュメント（https://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション4.Eで説明されており、改訂されたBSDライセンスで説明されている保証なしで提供されるように、改訂されたBSDライセンステキストを含める必要があります。
1. Introduction
2. Conventions and Definitions
3. The VPN Service Option
4. Forwarding Plane Considerations
5. Control Plane Considerations
6. IANA Considerations
7. Security Considerations
8. Deployment Considerations
9. Experimental Results
10. References
10.1. Normative References
10.2. Informative References
Acknowledgements
Authors' Addresses
Generic Packet Tunneling [RFC2473] allows a router in one network to encapsulate a packet in an IP header and send it to a router in another network. The receiving router removes the outer IP header and forwards the original packet into its own network. This facilitates connectivity between networks that share a private addressing [RFC1918] [RFC4193] plan but are not connected by a direct link.
一般的なパケットトンネリング[RFC2473]により、あるネットワーク内のルーターがIPヘッダーのパケットをカプセル化し、別のネットワークのルーターに送信できます。受信ルーターは外側のIPヘッダーを取り外し、元のパケットを独自のネットワークに転送します。これにより、プライベートアドレス指定[RFC1918] [RFC4193]計画を共有するネットワーク間の接続性が容易になりますが、直接リンクで接続されていません。
The IETF refined this concept in the Framework for VPN [RFC2764]. The IETF also standardized the following VPN technologies:
IETFは、VPN [RFC2764]のフレームワークでこの概念を改良しました。IETFは、次のVPNテクノロジーも標準化しました。
* IPsec VPN [RFC3884]
* IPSEC VPN [RFC3884]
* Layer 3 VPN (L3VPN) [RFC4364]
* レイヤー3 VPN（L3VPN）[RFC4364]
* Virtual Private LAN Service (VPLS) [RFC4761][RFC4762]
* 仮想プライベートLANサービス（VPLS）[RFC4761] [RFC4762]
* Layer 2 VPN (L2VPN) [RFC6624]
* レイヤー2 VPN（L2VPN）[RFC6624]
* Ethernet VPN (EVPN) [RFC7432]
* イーサネットVPN（EVPN）[RFC7432]
* Pseudowires [RFC8077]
* Pseudowires [RFC8077]
* Segment Routing over IPv6 (SRv6) [RFC8986]
* IPv6（SRV6）を介したセグメントルーティング[RFC8986]
* EVPN / Network Virtualization over Layer 3 (NVO3) [RFC9469]
* レイヤー3（NVO3）を介したEVPN /ネットワーク仮想化[RFC9469]
IPsec VPNs cryptographically protect all traffic from customer endpoint to customer endpoint. All of the other VPN technologies mentioned above share the following characteristics:
IPSEC VPNSは、すべてのトラフィックをカスタマーエンドポイントから顧客エンドポイントまで暗号化します。上記の他のすべてのVPNテクノロジーは、次の特性を共有しています。
* An ingress Provider Edge (PE) router encapsulates customer data in a tunnel header. The tunnel header includes service information. Service information identifies a Forwarding Information Base (FIB) entry on an egress PE router.
* Ingress Provider Edge（PE）ルーターは、トンネルヘッダーの顧客データをカプセル化します。トンネルヘッダーにはサービス情報が含まれています。サービス情報は、出力PEルーターの転送情報ベース（FIB）エントリを識別します。
* The ingress PE router sends the encapsulated packet to the egress PE router.
* Ingress PEルーターは、カプセル化されたパケットを出力PEルーターに送信します。
* The egress PE router receives the encapsulated packet.
* 出力PEルーターは、カプセル化されたパケットを受け取ります。
* The egress PE router searches its FIB for an entry that matches the incoming service information. If it finds one, it removes the tunnel header and forwards the customer data to a Customer Edge (CE) device, as per the FIB entry. If it does not find a matching FIB entry, it discards the packet.
* 出力PEルーターは、着信サービス情報と一致するエントリをFIBで検索します。見つかった場合、Tunnelヘッダーを削除し、FIBエントリに従って顧客データを顧客エッジ（CE）デバイスに転送します。一致するFIBエントリが見つからない場合、パケットを破棄します。
This document describes an experiment in which VPN service information is encoded in an experimental IPv6 Destination Option [RFC8200]. The experimental IPv6 Destination Option is called the VPN Service Option.
このドキュメントでは、VPNサービス情報が実験的なIPv6宛先オプション[RFC8200]でエンコードされる実験について説明します。実験的なIPv6宛先オプションは、VPNサービスオプションと呼ばれます。
The solution described in this document offers the following benefits:
このドキュメントで説明されているソリューションは、次の利点を提供します。
* It does not require configuration on CE devices.
* CEデバイスでの構成は必要ありません。
* It encodes service information in the IPv6 extension header. Therefore, it does not require any non-IPv6 headers (e.g., MPLS headers) to carry service information.
* IPv6拡張ヘッダーのサービス情報をエンコードします。したがって、サービス情報を伝達するために非IPV6ヘッダー（MPLSヘッダーなど）は必要ありません。
* It supports many VPNs on a single egress PE router.
* 単一の出口PEルーターで多くのVPNをサポートします。
* When a single egress PE router supports many VPNs, it does not require an IP address per VPN.
* 単一の出口PEルーターが多くのVPNをサポートする場合、VPNごとにIPアドレスは必要ありません。
* It does not rely on any particular control plane.
* 特定のコントロールプレーンに依存しません。
One purpose of this experiment is to demonstrate that the VPN Service Option can be deployed in a production network. Another purpose is to demonstrate that the security measures described in Section 7 of this document are sufficient to protect a VPN. Finally, this document encourages replication of the experiment, so that operational issues can be discovered.
この実験の目的の1つは、VPNサービスオプションを生産ネットワークに展開できることを実証することです。別の目的は、このドキュメントのセクション7で説明されているセキュリティ対策がVPNを保護するのに十分であることを実証することです。最後に、この文書は実験の複製を促進し、運用上の問題を発見できるようにします。
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] で説明されているように解釈されます。
The VPN Service Option is an IPv6 Destination Option encoded according to rules defined in [RFC8200].
VPNサービスオプションは、[RFC8200]で定義されているルールに従ってエンコードされたIPv6宛先オプションです。
As described in Section 4.2 of [RFC8200], an IPv6 Destination Option contains three fields: Option Type, Opt Data Len, and Option Data. In the VPN Service Option, these fields are used as follows:
[RFC8200]のセクション4.2で説明されているように、IPv6宛先オプションには、オプションタイプ、OPTデータレン、およびオプションデータの3つのフィールドが含まれています。VPNサービスオプションでは、これらのフィールドは次のように使用されます。
* Option Type: 8-bit selector. VPN Service Option. This field MUST be set to 0x5E (RFC3692-style Experiment) [V6MSG]. See NOTE below.
* オプションタイプ：8ビットセレクター。VPNサービスオプション。このフィールドは、0x5E（RFC3692スタイルの実験）[V6MSG]に設定する必要があります。以下のメモを参照してください。
* Opt Data Len: 8-bit unsigned integer. Length of the option, in bytes, excluding the Option Type and Option Length fields. This field MUST be set to 4.
* Opt Data Len: 8-bit unsigned integer.オプションの長さは、オプションタイプとオプションの長さフィールドを除くバイト単位です。このフィールドは4に設定する必要があります。
* Option Data: 32 bits. VPN service information that identifies a FIB entry on the egress PE. The FIB entry determines how the egress PE will forward customer data to a CE device.
* オプションデータ：32ビット。出力PEのFIBエントリを識別するVPNサービス情報。FIBエントリは、出力PEが顧客データをCEデバイスにどのように転送するかを決定します。
A single VPN Service Option MAY appear in a Destination Options header that immediately precedes an upper-layer header. It MUST NOT appear in any other extension header. If a receiver finds the VPN Service Option in any other extension header, it MUST NOT recognize the option. The packet MUST be processed according to the setting of the two highest-order bits of the Option Type (see NOTE below).
単一のVPNサービスオプションは、上層ヘッダーの直前の宛先オプションヘッダーに表示される場合があります。他の拡張ヘッダーに表示されてはなりません。受信者が他の拡張ヘッダーでVPNサービスオプションを見つけた場合、オプションを認識してはなりません。パケットは、オプションタイプの2つの最高級ビットの設定に従って処理する必要があります（以下の注を参照）。
NOTE: For this experiment, the Option Type is set to '01011110', i.e., 0x5E. The highest-order two bits are set to 01, indicating that the required action by a destination node that does not recognize the option is to discard the packet. The third highest-order bit is set to 0, indicating that Option Data cannot be modified along the path between the packet's source and its destination. The remaining low-order bits are set to '11110' to indicate the single IPv6 Destination Option Type code point available in the "Destination Options and Hop-by-Hop Options" registry [V6MSG] for experimentation.
注：この実験では、オプションタイプは「01011110」、つまり0x5eに設定されています。最高級の2ビットは01に設定されており、オプションを認識していない宛先ノードによる必要なアクションがパケットを破棄することであることを示しています。3番目に高いオーダービットは0に設定されており、パケットのソースと宛先の間のパスに沿ってオプションデータを変更できないことを示します。残りの低次ビットは「11110」に設定されており、実験のために「宛先オプションとホップバイホップオプション」レジストリ[V6MSG]で使用可能な単一のIPv6宛先オプションタイプコードポイントを示します。
The ingress PE encapsulates the customer data in a tunnel header. The tunnel header MUST contain an IPv6 header and a Destination Options header that immediately precedes the customer data. It MAY also include any legal combination of IPv6 extension headers.
Ingress PEは、トンネルヘッダーの顧客データをカプセル化します。トンネルヘッダーには、顧客データの直前のIPv6ヘッダーと宛先オプションヘッダーが含まれている必要があります。また、IPv6拡張ヘッダーの合法的な組み合わせも含まれる場合があります。
The IPv6 Header contains the following (all defined in [RFC8200]):
IPv6ヘッダーには、次のものが含まれています（すべて[RFC8200]で定義されています）：
* Version - MUST be equal to 6.
* バージョン - 6に等しくなければなりません。
* Traffic Class
* トラフィッククラス
* Flow Label
* フローラベル
* Payload Length
* ペイロード長
* Next Header
* 次のヘッダー
* Hop Limit
* ホップ制限
* Source Address - Represents an interface on the ingress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724].
* ソースアドレス - イングレスPEルーターのインターフェイスを表します。このアドレスは、[RFC6724]で提供されるガイダンスに従って選択する必要があります。
* Destination Address - Represents an interface on the egress PE router. This address SHOULD be chosen according to guidance provided in [RFC6724].
* 宛先アドレス - 出口PEルーターのインターフェイスを表します。このアドレスは、[RFC6724]で提供されるガイダンスに従って選択する必要があります。
The IPv6 Destination Options Extension Header contains the following (all defined in [RFC8200]):
IPv6宛先オプションエクステンションヘッダーには、次のものが含まれています（すべて[RFC8200]で定義されています）：
* Next Header - MUST identify the protocol of the customer data.
* 次のヘッダー - 顧客データのプロトコルを特定する必要があります。
* Hdr Ext Len
* HDR ext len
* Options - In this experiment, the Options field MUST contain exactly one VPN Service Option as defined in Section 3 of this document. It MAY also contain any legal combination of other Destination Options.
* オプション - この実験では、オプションフィールドには、このドキュメントのセクション3で定義されているように、正確に1つのVPNサービスオプションを含める必要があります。また、他の目的地オプションの合法的な組み合わせが含まれる場合があります。
The FIB can be populated by:
FIBには次のように入力できます。
* An operator, using a Command-Line Interface (CLI)
* コマンドラインインターフェイス（CLI）を使用するオペレーター
* A controller, using the Path Computation Element Communication Protocol (PCEP) [RFC5440] or the Network Configuration Protocol (NETCONF) [RFC6241]
* パス計算要素通信プロトコル（PCEP）[RFC5440]またはネットワーク構成プロトコル（NetConf）[RFC6241]を使用したコントローラー
* A routing protocol
* ルーティングプロトコル
Routing protocol extensions that support the VPN Service Option are beyond the scope of this document.
VPNサービスオプションをサポートするルーティングプロトコル拡張機能は、このドキュメントの範囲を超えています。
This document has no IANA actions.
このドキュメントにはIANAアクションがありません。
A VPN is characterized by the following security policy:
VPNは、次のセキュリティポリシーによって特徴付けられます。
* Nodes outside of a VPN cannot inject traffic into the VPN.
* VPN以外のノードは、VPNにトラフィックを注入できません。
* Nodes inside a VPN cannot send traffic outside of the VPN.
* VPN内のノードは、VPN以外のトラフィックを送信できません。
A set of PE routers cooperate to enforce this security policy. If a device outside of that set could impersonate a device inside of the set, it would be possible for that device to subvert security policy. Therefore, impersonation must not be possible. The following paragraphs describe procedures that prevent impersonation.
一連のPEルーターが協力して、このセキュリティポリシーを実施します。そのセットの外側のデバイスがセットの内部にデバイスになりすましている場合、そのデバイスがセキュリティポリシーを破壊することが可能です。したがって、なりすましは不可能です。次の段落では、なりすましを防ぐ手順について説明しています。
The VPN Service Option can be deployed:
VPNサービスオプションは展開できます。
* On the global Internet
* グローバルインターネットで
* Inside of a limited domain
* 限られたドメインの内部
When the VPN Service Option is deployed on the global Internet, the tunnel that connects the ingress PE to the egress PE MUST be cryptographically protected by one of the following:
VPNサービスオプションがグローバルインターネットに展開されている場合、侵入PEを出力PEに接続するトンネルは、次のいずれかによって暗号化されている必要があります。
* The IPv6 Authentication Header (AH) [RFC4302]
* IPv6認証ヘッダー（AH）[RFC4302]
* The IPv6 Encapsulating Security Payload (ESP) Header [RFC4303]
* セキュリティペイロードをカプセル化するIPv6（ESP）ヘッダー[RFC4303]
When the VPN Service Option is deployed in a limited domain, all nodes at the edge of limited domain MUST maintain Access Control Lists (ACLs). These ACLs MUST discard packets that satisfy the following criteria:
VPNサービスオプションが限られたドメインに展開される場合、限られたドメインの端にあるすべてのノードは、アクセス制御リスト（ACL）を維持する必要があります。これらのACLは、次の基準を満たすパケットを破棄する必要があります。
* Contain a VPN Service Option
* VPNサービスオプションが含まれています
* Contain an IPv6 Destination Address that represents an interface inside of the limited domain
* 限られたドメイン内のインターフェイスを表すIPv6宛先アドレスを含む
The mitigation techniques mentioned above operate in fail-open mode. That is, they require explicit configuration in order to ensure that packets using the approach described in this document do not leak out of a domain. See [SAFE-LIM-DOMAINS] for a discussion of fail-open and fail-closed modes.
上記の緩和手法は、フェイルオープンモードで動作します。つまり、このドキュメントで説明されているアプローチを使用してパケットがドメインから漏れないようにするために、明示的な構成が必要です。フェールオープンおよびフェイルクロップモードの議論については、[Safe-Lim-Domains]を参照してください。
For further information on the security concerns related to IP tunnels and the recommended mitigation techniques, please see [RFC6169].
IPトンネルに関連するセキュリティの懸念と推奨される緩和手法の詳細については、[RFC6169]を参照してください。
The VPN Service Option is imposed by an ingress PE and processed by an egress PE. It is not processed by any other nodes along the delivery path between the ingress PE and egress PE.
VPNサービスオプションは、侵入PEによって課され、出力PEで処理されます。イングレスPEと出口PEの間の配信パスに沿った他のノードによって処理されません。
However, some networks discard packets that include IPv6 Destination Options. This is an impediment to deployment.
ただし、一部のネットワークでは、IPv6宛先オプションを含むパケットを破棄します。これは展開の障害です。
Because the VPN Service Option uses an experimental code point, there is a risk of collisions with other experiments. Specifically, the egress PE may process packets from another experiment that uses the same code point.
VPNサービスオプションは実験コードポイントを使用するため、他の実験と衝突するリスクがあります。具体的には、出力PEは、同じコードポイントを使用する別の実験からパケットを処理する場合があります。
As with all experiments with IETF protocols, it is expected that care is taken by the operator to ensure that all nodes participating in an experiment are carefully configured.
IETFプロトコルを使用したすべての実験と同様に、実験に参加するすべてのノードが慎重に構成されるように、オペレーターが注意を払うことが予想されます。
Because the VPN Service Destination Option uses an experimental code point, processing of this option MUST be disabled by default. Explicit configuration is required to enable processing of the option.
VPNサービス宛先オプションは実験コードポイントを使用するため、このオプションの処理はデフォルトで無効にする必要があります。オプションの処理を有効にするには、明示的な構成が必要です。
Parties participating in this experiment should publish experimental results within one year of the publication of this document. Experimental results should address the following:
この実験に参加している当事者は、この文書の公開から1年以内に実験結果を公開する必要があります。実験結果は次のとおりです。
* Effort required to deploy
* 展開するために必要な努力
- Was deployment incremental or network-wide?
- 展開は増加しましたか、それともネットワーク全体でしたか？
- Was there a need to synchronize configurations at each node, or could nodes be configured independently?
- 各ノードで構成を同期する必要がありましたか、それともノードを個別に構成できますか？
- Did the deployment require a hardware upgrade?
- 展開にはハードウェアのアップグレードが必要でしたか？
* Effort required to secure
* 確保するために必要な努力
- Performance impact
- パフォーマンスの影響
- Effectiveness of risk mitigation with ACLs
- ACLSによるリスク軽減の有効性
- Cost of risk mitigation with ACLs
- ACLSによるリスク軽減のコスト
* Mechanism used to populate the FIB
* FIBの設定に使用されるメカニズム
* Scale of deployment
* 展開の規模
* Interoperability
* 相互運用性
- Did you deploy two interoperable implementations?
- 相互運用可能な2つの実装を展開しましたか？
- Did you experience interoperability problems?
- 相互運用性の問題を経験しましたか？
* Effectiveness and sufficiency of Operations, Administration, and Maintenance (OAM) mechanisms
* 運用、管理、およびメンテナンス（OAM）メカニズムの有効性と十分性
- Did PING work?
- pingは機能しましたか？
- Did TRACEROUTE work?
- Tracerouteは機能しましたか？
- Did Wireshark work?
- Wiresharkは機能しましたか？
- Did TCPDUMP work?
- tcpdumpは機能しましたか？
[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>.
[RFC6169] Krishnan, S., Thaler, D., and J. Hoagland, "Security
Concerns with IP Tunneling", RFC 6169,
DOI 10.17487/RFC6169, April 2011,
<https://www.rfc-editor.org/info/rfc6169>.
[RFC6724] Thaler, D., Ed., Draves, R., Matsumoto, A., and T. Chown,
"Default Address Selection for Internet Protocol Version 6
(IPv6)", RFC 6724, DOI 10.17487/RFC6724, September 2012,
<https://www.rfc-editor.org/info/rfc6724>.
[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>.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
J., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918,
February 1996, <https://www.rfc-editor.org/info/rfc1918>.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, DOI 10.17487/RFC2473,
December 1998, <https://www.rfc-editor.org/info/rfc2473>.
[RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A.
Malis, "A Framework for IP Based Virtual Private
Networks", RFC 2764, DOI 10.17487/RFC2764, February 2000,
<https://www.rfc-editor.org/info/rfc2764>.
[RFC3884] Touch, J., Eggert, L., and Y. Wang, "Use of IPsec
Transport Mode for Dynamic Routing", RFC 3884,
DOI 10.17487/RFC3884, September 2004,
<https://www.rfc-editor.org/info/rfc3884>.
[RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
Addresses", RFC 4193, DOI 10.17487/RFC4193, October 2005,
<https://www.rfc-editor.org/info/rfc4193>.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
DOI 10.17487/RFC4302, December 2005,
<https://www.rfc-editor.org/info/rfc4302>.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, DOI 10.17487/RFC4303, December 2005,
<https://www.rfc-editor.org/info/rfc4303>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, <https://www.rfc-editor.org/info/rfc4364>.
[RFC4761] Kompella, K., Ed. and Y. Rekhter, Ed., "Virtual Private
LAN Service (VPLS) Using BGP for Auto-Discovery and
Signaling", RFC 4761, DOI 10.17487/RFC4761, January 2007,
<https://www.rfc-editor.org/info/rfc4761>.
[RFC4762] Lasserre, M., Ed. and V. Kompella, Ed., "Virtual Private
LAN Service (VPLS) Using Label Distribution Protocol (LDP)
Signaling", RFC 4762, DOI 10.17487/RFC4762, January 2007,
<https://www.rfc-editor.org/info/rfc4762>.
[RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation
Element (PCE) Communication Protocol (PCEP)", RFC 5440,
DOI 10.17487/RFC5440, March 2009,
<https://www.rfc-editor.org/info/rfc5440>.
[RFC6241] Enns, R., Ed., Bjorklund, M., Ed., Schoenwaelder, J., Ed.,
and A. Bierman, Ed., "Network Configuration Protocol
(NETCONF)", RFC 6241, DOI 10.17487/RFC6241, June 2011,
<https://www.rfc-editor.org/info/rfc6241>.
[RFC6624] Kompella, K., Kothari, B., and R. Cherukuri, "Layer 2
Virtual Private Networks Using BGP for Auto-Discovery and
Signaling", RFC 6624, DOI 10.17487/RFC6624, May 2012,
<https://www.rfc-editor.org/info/rfc6624>.
[RFC7432] Sajassi, A., Ed., Aggarwal, R., Bitar, N., Isaac, A.,
Uttaro, J., Drake, J., and W. Henderickx, "BGP MPLS-Based
Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February
2015, <https://www.rfc-editor.org/info/rfc7432>.
[RFC8077] Martini, L., Ed. and G. Heron, Ed., "Pseudowire Setup and
Maintenance Using the Label Distribution Protocol (LDP)",
STD 84, RFC 8077, DOI 10.17487/RFC8077, February 2017,
<https://www.rfc-editor.org/info/rfc8077>.
[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>.
[RFC9469] Rabadan, J., Ed., Bocci, M., Boutros, S., and A. Sajassi,
"Applicability of Ethernet Virtual Private Network (EVPN)
to Network Virtualization over Layer 3 (NVO3) Networks",
RFC 9469, DOI 10.17487/RFC9469, September 2023,
<https://www.rfc-editor.org/info/rfc9469>.
[SAFE-LIM-DOMAINS]
Kumari, W., Alston, A., Vyncke, É., Krishnan, S., and D.
Eastlake, "Safe(r) Limited Domains", Work in Progress,
Internet-Draft, draft-wkumari-intarea-safe-limited-
domains-04, 3 March 2025,
<https://datatracker.ietf.org/doc/html/draft-wkumari-
intarea-safe-limited-domains-04>.
[V6MSG] IANA, "Destination Options and Hop-by-Hop Options",
<https://www.iana.org/assignments/ipv6-parameters>.
Thanks to Gorry Fairhurst, Antoine Fressancourt, Eliot Lear, and Mark Smith for their reviews and contributions to this document.
Gorry Fairhurst、Antoine Fressancourt、Eliot Lear、Mark Smithのレビューとこの文書への貢献に感謝します。
Ron Bonica
Juniper Networks
Herndon, Virginia
United States of America
Email: rbonica@juniper.net
Xing Li
CERNET Center/Tsinghua University
Beijing
China
Email: xing@cernet.edu.cn
Adrian Farrel
Old Dog Consulting
United Kingdom
Email: adrian@olddog.co.uk
Yuji Kamite
NTT DOCOMO BUSINESS
Chiyoda-ku, Tokyo
Japan
Email: y.kamite@ntt.com
Luay Jalil
Verizon
Richardson, Texas
United States of America
Email: luay.jalil@one.verizon.com