Network Working Group L. Dunbar
Internet-Draft Futurewei
Intended status: Standards Track S. Hares
Expires: 5 March 2027 Huawei
K. Majumdar
Upscale AI
R. Raszuk
Arrcus
V. Kasiviswanathan
Arista
1 September 2026
SD-WAN Edge and Underlay Tunnel Discovery Using BGP
draft-ietf-idr-sdwan-edge-discovery-30
Abstract
This document specifies BGP mechanisms for SD-WAN (Software-Defined
Wide Area Network) edge node attribute discovery. These mechanisms
comprise a new tunnel type and associated Sub-TLVs for the BGP Tunnel
Encapsulation Attribute, and a new Subsequent Address Family
Identifier (SAFI) carrying a typed NLRI for advertising SD-WAN
underlay tunnel information.
Requirements Language
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
Dunbar, et al. Expires 5 March 2027 [Page 1]
Internet-Draft SD-WAN Edge Discovery September 2026
This Internet-Draft will expire on 5 March 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Secure L3VPN Services over SD-WAN . . . . . . . . . . . . 4
1.2. SD-WAN Secure Links . . . . . . . . . . . . . . . . . . . 5
1.3. Conventions used in this document . . . . . . . . . . . . 5
2. BGP SD-WAN Mechanisms . . . . . . . . . . . . . . . . . . . . 6
2.1. SD-WAN Hybrid Tunnel TLV Encoding . . . . . . . . . . . . 7
2.1.1. Summary of Validation Procedure . . . . . . . . . . . 10
2.1.2. Processing Considerations for SD-Wan Hybrid Tunnel
Encoding . . . . . . . . . . . . . . . . . . . . . . 10
2.2. SD-WAN Underlay Route Advertisement . . . . . . . . . . . 10
2.2.1. NLRI for SD-WAN Underlay Route . . . . . . . . . . . 11
2.2.2. Validation of SD-WAN NLRI . . . . . . . . . . . . . . 13
2.2.3. BGP Path Attributes attached to SD-WAN NLRI . . . . . 14
2.3. IPsec SA Property Sub-TLVs . . . . . . . . . . . . . . . 14
2.3.1. IPsec SA ID Sub-TLV . . . . . . . . . . . . . . . . . 15
2.3.2. IPsec SA Rekey Counter Sub-TLV . . . . . . . . . . . 16
2.3.3. IPsec Public Key Sub-TLV . . . . . . . . . . . . . . 18
2.3.4. IPsec SA Proposal Sub-TLV . . . . . . . . . . . . . . 19
2.3.5. Simplified IPsec SA Sub-TLV . . . . . . . . . . . . . 21
2.3.6. Extended Port Attribute Sub-TLV . . . . . . . . . . . 24
2.4. Procedure for Client Route Advertisements with SD-WAN
Hybrid Tunnel . . . . . . . . . . . . . . . . . . . . . . 30
2.4.1. SD-WAN Hybrid Tunnel Type in Encapsulation Extended
Community . . . . . . . . . . . . . . . . . . . . . . 31
2.4.2. SD-WAN Hybrid Type in Tunnel Attributes via Tunnel
Encapsulation Attribute . . . . . . . . . . . . . . . 31
2.4.3. Client Routes Carried Over Multiple SD-WAN Hybrid
Tunnels . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.4. SD-WAN VPN ID in Control Plane . . . . . . . . . . . 33
2.4.5. SD-WAN VPN ID in Data Plane . . . . . . . . . . . . . 33
Dunbar, et al. Expires 5 March 2027 [Page 2]
Internet-Draft SD-WAN Edge Discovery September 2026
2.5. Procedure for SD-WAN Underlay Routes with SD-WAN Hybrid
Tunnel TLV . . . . . . . . . . . . . . . . . . . . . . . 34
2.5.1. SD-WAN Underlay Route without Encapsulation Extended
Community . . . . . . . . . . . . . . . . . . . . . . 34
2.5.2. Underlay Route with a Tunnel Encapsulation
Attribute . . . . . . . . . . . . . . . . . . . . . . 34
2.5.3. Underlay Routes with Port-Local-ID of Zero . . . . . 35
2.5.4. Multiple Tunnels Associated with One SD-WAN Underlay
Route . . . . . . . . . . . . . . . . . . . . . . . . 36
2.6. Error handling . . . . . . . . . . . . . . . . . . . . . 36
2.6.1. Error handling for Tunnel Encapsulation Signaling . . 36
2.6.2. Error Handling for NLRI . . . . . . . . . . . . . . . 37
2.6.3. SD-WAN NLRI and Tunnel Encapsulation Attribute . . . 38
3. Operational Consistency and Tunnel Validation . . . . . . . . 38
3.1. Detecting Misaligned Tunnels . . . . . . . . . . . . . . 38
3.2. IPsec Attributes Mismatch . . . . . . . . . . . . . . . . 39
3.2.1. Example creation of IPsec SA over SD-WAN Hybrid
Tunnel . . . . . . . . . . . . . . . . . . . . . . . 40
4. Manageability Considerations . . . . . . . . . . . . . . . . 41
5. Security Considerations . . . . . . . . . . . . . . . . . . . 42
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 43
6.1. SD-WAN SAFI . . . . . . . . . . . . . . . . . . . . . . . 43
6.2. Tunnel Encapsulation Attribute Tunnel Type . . . . . . . 43
6.3. Tunnel Encapsulation Attribute Sub-TLV Types . . . . . . 43
6.4. SD-WAN Edge Discovery NLRI Route Types . . . . . . . . . 44
6.5. SD-WAN Extended Port Encapsulation Types . . . . . . . . 44
6.6. SD-WAN Extended Port Connection Types . . . . . . . . . . 44
6.7. SD-WAN Extended Port Physical Port Types . . . . . . . . 45
6.8. SD-WAN Extended Port Sub-Sub-TLV Types . . . . . . . . . 45
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 45
7.1. Normative References . . . . . . . . . . . . . . . . . . 45
7.2. Informative References . . . . . . . . . . . . . . . . . 47
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . 48
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 48
1. Introduction
This document describes the BGP [RFC4271] signaling extensions that
enable SD-WAN edge nodes to advertise client route reachability,
underlay tunnel properties, and security related attributes required
to establish and maintain SD-WAN overlay tunnels. The SD-WAN Hybrid
Tunnel forms a logical overlay between edge nodes across
heterogeneous underlay networks (e.g., MPLS VPNs, direct Layer 2
links, or public Internet).
The mechanisms defined in this document apply to both:
Dunbar, et al. Expires 5 March 2027 [Page 3]
Internet-Draft SD-WAN Edge Discovery September 2026
1) SD-WAN Secure L3VPN deployments, where L3VPN services are
delivered over SD-WAN Hybrid tunnels, and
2) SD-WAN Secure Links deployments, where encrypted logical links
are formed between SD-WAN edge nodes without using L3VPN address
families.
BGP [RFC4271] serves as the control plane for these SD-WAN
deployments. BGP sessions used to exchange the SD-WAN information
defined in this document MUST provide peer authentication, integrity
protection, and confidentiality. The specific mechanism used to
provide these security properties is deployment dependent. The BGP
speaker can be an IBGP peer or an RR.
This document defines a new SD-WAN Hybrid Tunnel type and associated
sub-TLVs for the BGP Tunnel Encapsulation Attribute [RFC9012], as
well as new NLRIs for advertising SD-WAN underlay information. These
extensions enable SD-WAN edge nodes to exchange the information
necessary to establish and update secure SD-WAN overlay tunnels, as
described in [Net2Cloud].
In the context of this document, BGP Route Reflector (RR) is the
component of the SD-WAN Controller system that receives the BGP
UPDATE from SD-WAN edges and in turn propagates the information to
the intended peers that are authorized to communicate via the SD-WAN
overlay network. The mechanisms specified in this document are
intended for a controlled SD-WAN environment in which the
participating SD-WAN edge nodes and RRs operate under a common
administrative authority and are constrained by policy to an
authorized set of participants. They are not specified for use
between mutually distrusting administrative domains.
The deployment model specified in this document is based on a BGP
Route Reflector that is part of the SD-WAN Controller. The RR
provides the central point for applying authorization and policy and
for propagating SD-WAN route and tunnel information to authorized
peers.
1.1. Secure L3VPN Services over SD-WAN
An SD-WAN network defined in [MEF70.1] and [MEF70.2] refers to a
policy-driven network over multiple heterogeneous underlay networks
tailored to get better WAN bandwidth management, visibility, and
control. In many deployments, L3VPN services are offered over SD-WAN
overlays to provide site-to-site connectivity with traffic
segmentation, security, and performance guarantees. These L3VPN
services leverage SD-WAN Secure Links, i.e. encrypted data plane
tunnels established between SD-WAN edge nodes using mechanisms such
Dunbar, et al. Expires 5 March 2027 [Page 4]
Internet-Draft SD-WAN Edge Discovery September 2026
as IPsec, to carry user traffic between endpoints.
This document describes the BGP mechanisms used to support such L3VPN
deployments by enabling SD-WAN edge nodes to advertise underlay
attributes, tunnel characteristics, and security association related
attributes. These mechanisms enable dynamic tunnel selection,
service-level steering, and secure endpoint discovery.
The SD-WAN usage model, including its deployment scenarios and BGP
requirements, is detailed in [SD-WAN-BGP-USAGE] and not repeated
here. This document focuses solely on the signaling extensions and
encapsulation mechanisms required to support those scenarios in BGP.
1.2. SD-WAN Secure Links
[RFC9012] defines a BGP mechanism that links routes to a specific
tunnels using a specific encapsulation. The SD-WAN Secure Links
Topology uses a single hybrid logical link on a SD-WAN Peer to
represent multiple underlay topology links. The SD-WAN peer
distributes IPsec security association (IPsec SA) [RFC4301] related
information regarding the hybrid link or individual underlay links.
The traffic is routed via normal IPv4/IPv6 forwarding without any VPN
addition. The SD-WAN Secure Links provides some link security for
some simple cases of the three scenarios from [SD-WAN-BGP-USAGE] that
do not require L3VPN addresses (Route Distinguisher (RD), prefix).
1.3. Conventions used in this document
The following terms are used as defined in other documents:
[MEF 70.1] [MEF 70.2]: SD-WAN (Software-Defined Wide Area Network)
[RFC4301]: IPsec SA (IPsec Security Association)
[RFC4760]: MP_REACH_NLRI
[RFC9012]: Tunnel Enapsulation Attribute
[SD-WAN-BGP-USAGE]: C-PE, Controller, and SD-WAN Edge
For clarity, this document uses the following terms from [SD-WAN-BGP-
USAGE]:
C-PE (Customer Premises Equipment): A specific type of SD-WAN Edge
Dunbar, et al. Expires 5 March 2027 [Page 5]
Internet-Draft SD-WAN Edge Discovery September 2026
deployed at the customer's edge. In this document, the terms C-PE
and SD-WAN Edge are used interchangeably when referring to SD-WAN
nodes that handle client route advertisement and secure tunnel
establishment.
Controller: Refers to the SD-WAN Controller as defined in [SD-WAN-
BGP-USAGE].
SD-WAN Edge: A network element that participates in the SD-WAN
overlay as defined in [SD-WAN-BGP-USAGE].
The following new terms are defined for this document:
Client Route: A route advertised using AFI/SAFI 1/1, 2/1, 1/128, or
2/128 that is associated with an SD-WAN Hybrid Tunnel.
CPE-Based VPN: Virtual Private Secure network formed among C-PEs.
This is to differentiate such VPNs from most commonly used PE-
based VPNs discussed in [RFC4364].
CPN: Customer Premises Network
SD-WAN Hybrid Tunnel: A single logical tunnel that combines several
links of different encapsulation into a single tunnel. This
logical tunnel MAY exist as part of a SD-WAN Secure L3VPN or
simply be a SD-WAN secure link for a flat network.
SD-WAN Underlay Route: A route advertised using AFI/SAFI 1/74 or
2/74 whose SD-WAN NLRI identifies a WAN port or ports and whose
associated Tunnel Encapsulation Attribute advertises tunnel-
related properties.
Secure Transport Connection: A transport layer security mechanism
that provides authentication, integrity, and confidentiality of
routing updates over untrusted networks.
Walled Garden: A controlled SD-WAN deployment in which participating
SD-WAN edge nodes and RRs are authorized and managed under a
common administrative authority, and BGP sessions and SD-WAN
tunnel advertisements are constrained by local policy to those
authorized participants.
2. BGP SD-WAN Mechanisms
The BGP mechanisms defined in this document support two types of
advertisements:
Advertise Client routes with SD-WAN Hybrid Tunnel: A BGP speaker
Dunbar, et al. Expires 5 March 2027 [Page 6]
Internet-Draft SD-WAN Edge Discovery September 2026
supporting SD-WAN re-advertises routes received from client
routers with the Next_HOP address set to its own IP address (due
to the SD-WAN feature configuration) and includes a BGP attribute
indicating the SD-WAN Hybrid Tunnel. Client routes MAY be
advertised using the following AFI/SAFIs: Unicast IPv4/IPv6 (1/1,
2/1) and L3VPN IPv4/IPv6 (1/128, 2/128). The SD-WAN tunnel
indication can be conveyed using either the Encapsulation Extended
Community or the Tunnel Encapsulation Attribute.
Advertise SD-WAN Underlay Routes: A BGP speaker advertises SD-WAN
Underlay Routes using AFI/SAFI 1/74 or 2/74. The NEXT_HOP is set
to a reachable address of the advertising SD-WAN edge node,
typically its loopback address, and the UPDATE includes a Tunnel
Encapsulation Attribute containing an SD-WAN Hybrid Tunnel TLV.
The SD-WAN NLRI identifies the WAN port or ports, SD-WAN Color,
and SD-WAN Node ID to which the advertised tunnel properties
apply. The associated SD-WAN Hybrid Tunnel TLV carries the
corresponding tunnel-related information, including IPsec SA
properties and, optionally, NAT-related information.
In this document, "Client Route" refers to the first type of
advertisement, and "SD-WAN Underlay Route" refers to the second. The
term "SD-WAN NLRI" refers specifically to the NLRI encoding used for
an SD-WAN Underlay Route. For Client Routes, the Tunnel
Encapsulation Attribute procedures of [RFC9012] apply. For SD-WAN
Underlay Routes using SAFI 74, which is outside the applicability
scope defined by [RFC9012], the use and processing of the Tunnel
Encapsulation Attribute are defined by this document. This document
does not update [RFC9012].
This section describes the SD-WAN Hybrid Tunnel, the SD-WAN NLRIs,
the new sub-TLVs for SD-WAN Tunnel IPsec SA, sub-TLVs for Port
attributes, the procedures for the client routes, the procedures for
underlay routes, error handling, and considerations for managing SD-
WAN technologies.
2.1. SD-WAN Hybrid Tunnel TLV Encoding
Name: SD-WAN Hybrid Tunnel
Code: 25 (IANA assigned)
Description: The SD-WAN Hybrid Tunnel identifies a virtual tunnel
that overlays a path across a set of underlay links between two
BGP peers. These underlay links may use various technologies
(e.g., MPLS, Layer 2 direct connections, or Layer 3 public
Internet). The term hybrid reflects that different types of
underlay links can be used simultaneously.
Dunbar, et al. Expires 5 March 2027 [Page 7]
Internet-Draft SD-WAN Edge Discovery September 2026
Encoding: Per [RFC9012], the following two BGP attributes that MAY
encode a Tunnel Encapsulation attribute information: the Tunnel
Encapsulation Attribute, and the Encapsulation Extended Community
as a "barebones" tunnel identification. The encoding for the SD-
WAN Hybrid Tunnel is described for both BGP attributes.
SD-WAN Hybrid tunnel Encoded in Encapsulation Extended
Community: The SD-WAN encoding uses the Encapsulation Extended
Community defined in [RFC9012] with the tunnel type set to 25
(IANA assigned). The NextHop Field in the BGP update indicates
the tunnel egress endpoint and this field SHOULD be set to the
BGP Peer Address for the SD-WAN Peer.
SD-WAN Hybrid tunnel Encoded in Tunnel Encapsulation Attribute:
The tunnel TLV has a type set to 25 (IANA assigned). The valid
Sub-TLVs for client routes are the Color Sub-TLV (defined in
[RFC9012]), and the following Sub-TLVs defined in sections 2.2
and 2.3 of this document: IPSec SEC ID, IPsec SA Rekey Cnt,
IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.
The valid Sub-TLVs for underlay tunnels are the Tunnel Egress
End Point defined in [RFC9012] and the following Sub-TLVs
defined in sections 2.2 and 2.3 of this document: IPSec SEC ID,
IPsec SA Rekey Cnt, Extended Port Attr, Underlay Type, IPsec
Public Key, IPsec SA Proposal, and Simplified IPsec SA. For
SD-WAN Underlay Routes using SAFI 74, if a Tunnel Egress
Endpoint Sub-TLV is not included in the SD-WAN Hybrid Tunnel
TLV, it is treated as if a Tunnel Egress Endpoint Sub-TLV with
an Address Family value of 0 were included. For Client Routes,
Tunnel Egress Endpoint processing follows [RFC9012]. Figure 1
summarizes this Sub-TLV support in a tabular format.
Dunbar, et al. Expires 5 March 2027 [Page 8]
Internet-Draft SD-WAN Edge Discovery September 2026
Client Routes AFI/SAFI = 1/1, 2/1, 1/128, 2/128
Underlay Routes AFI/SAFI = 1/74 and 2/74
sub-TLV Code Client Routes Underlay Routes
------ ---- ------------- ---------------
Encapsulation 1 not valid not valid
Protocol 2 not valid not valid
Color 4 not valid not valid
Load-Balancing Block 5 not valid not valid
Tunnel Egress EP 6 required required *1
DS Field 7 not valid not valid
UDP Dest. Port 8 not valid not valid
Embedded Label H. 9 not valid not valid
MPLS label Stack 10 not valid not valid
Prefix-SID 11 not valid not valid
Preference 12 not valid not valid
Binding SID 13 not valid not valid
ENLP 14 not valid not valid
Priority 15 not valid not valid
SPI/SI 16 not valid not valid
SRv6 Binding SID 20 not valid not valid
IPsec SA ID 64 valid valid
Extended Port Attr 65 not valid valid
IPsec SA Rekey Cnt 67 valid valid
IPsec Public Key 68 valid valid
IPsec SA Proposal 69 valid valid
Simplified IPsec SA 70 valid valid
*1 - For SD-WAN Underlay Routes, if a Tunnel Egress Endpoint Sub-TLV
is not included, it is treated as if a Tunnel Egress Endpoint
Sub-TLV with AFI 0 were included.
Figure 1: Sub-TLV Support for Client and Underlay Routes
The Color Sub-TLV defined in [RFC9012] is not used by the SD-WAN
procedures defined in this document. Client Routes carry the Color
Extended Community, while SD-WAN Underlay Routes carry the SD-WAN-
Color field in the SAFI-74 NLRI. The receiving BGP speaker
correlates these values as described in Sections 2.4.1, 2.4.3, and
3.1.
Dunbar, et al. Expires 5 March 2027 [Page 9]
Internet-Draft SD-WAN Edge Discovery September 2026
2.1.1. Summary of Validation Procedure
The SD-WAN Hybrid Tunnel TLV and its Sub-TLVs MUST first be validated
for correct encoding and applicability as specified in this section
and Section 2.3. Route-specific validation procedures are specified
in Section 2.4.2 for Client Routes and Section 2.5.2 for SD-WAN
Underlay Routes. Error handling is specified in Section 2.6. After
the SD-WAN Hybrid Tunnel TLV has been validated, the receiving BGP
speaker processes it according to the applicable route procedure.
2.1.2. Processing Considerations for SD-Wan Hybrid Tunnel Encoding
When Encapsulation Extended Community with a SD-WAN Hybrid Tunnel
Type is attached to a client route, the detailed SD-WAN tunnel
attributes are not included in the same BGP UPDATE message, but are
advertised separately using the SD-WAN NLRI. Section 2.2 and 2.3
describe the processing. The SD-WAN NLRI is originated by the C-PE,
and the BGP Next Hop is set to a reachable address of the C-PE,
typically its loopback address. The remote BGP speaker uses this
loopback address to associate the client route with the corresponding
logical SD-WAN Hybrid Tunnel, and the SD-WAN NLRI SD-WAN Node ID and
port to the underlay tunnel within the logial SD-WAN Hybrid Tunnel.
This separation allows for independent advertisement rates and avoids
bloating BGP UPDATE messages with the large amount of data required
for IPsec SA, cryptographic keys, and related parameters.
When the Tunnel Encapsulation Attribute with SD-WAN Hybrid Tunnel TLV
is attached to the client route, the detailed underlay tunnel
attributes, such as IPsec-related parameters, are included directly
in the same BGP UPDATE as the client route. As a result, there is no
need for a separate UPDATE message associated with the C-PE loopback
address. However, this approach means that any changes to underlay
attributes (e.g., IPsec keys or cryptographic parameters) necessitate
re-advertising the client route with an updated Tunnel Encapsulation
Attribute, which can increase both the frequency and size of BGP
UPDATE messages.
2.2. SD-WAN Underlay Route Advertisement
An Edge BGP Peer using BGP SD-WAN discovery advertises an SD-WAN
Underlay Route whose NLRI is encoded as specified in Section 2.2.1.
The route carries a Tunnel Encapsulation Attribute containing an SD-
WAN Hybrid Tunnel TLV to advertise the detailed properties associated
with the public-facing WAN port or ports and their associated IPsec
tunnels. The SD-WAN Underlay Route carries control-plane information
describing an SD-WAN WAN port and its tunnel properties; the SD-WAN
NLRI is not itself installed as a route for forwarding user traffic.
The Edge BGP Peer sends this information to its designated RR via a
Dunbar, et al. Expires 5 March 2027 [Page 10]
Internet-Draft SD-WAN Edge Discovery September 2026
secure transport connection. Each BGP UPDATE containing an SD-WAN
Underlay Route MUST include a Tunnel Encapsulation Attribute with an
SD-WAN Hybrid Tunnel TLV. If an SD-WAN Underlay Route is received
without the required Tunnel Encapsulation Attribute and SD-WAN Hybrid
Tunnel TLV, the route MUST be handled as Treat-as-withdraw as
specified in Section 2.6.3.
The SD-WAN Hybrid tunnel TLV within the Tunnel Encapsulation
Attribute can include sub-TLVs for Extended Port attribute (see
Section 2.3.6) or IPsec information (see Section 2.3). The IPsec
information sub-TLVs include: IPsec SA ID, IPsec SA Rekey Counter,
IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.
2.2.1. NLRI for SD-WAN Underlay Route
A new NLRI SAFI (SD-WAN SAFI=74) is introduced within the
MP_REACH_NLRI Path Attribute of [RFC4760] for advertising the
detailed properties of SD-WAN tunnels terminated at the WAN ports of
the edge nodes. The SD-WAN SAFI uses the Tunnel Encapsulation
Attribute and Tunnel TLV/sub-TLV encodings defined in [RFC9012].
Because SAFI 74 is outside the AFI/SAFIs for which [RFC9012] defines
applicability procedures, this document defines the use of the Tunnel
Encapsulation Attribute with SAFI 74, including the associated next-
hop, propagation, and validation procedures. This is a "typed" NLRI
(similar to other "typed" NLRIs as described in [RFC7606]). The
format is shown in figure 2.
For AFI/SAFI 1/74, the MP_REACH_NLRI Next Hop Network Address field
MUST contain a 4-octet IPv4 address. For AFI/SAFI 2/74, it MUST
contain a 16-octet IPv6 address. The Next Hop MUST contain a
reachable address of the advertising SD-WAN edge node, typically its
loopback address or SD-WAN Node ID.
+------------------+
| Route Type | 2 octets
+------------------+
| Length | 2 octets
+------------------+
| Type Specific |
~ Value (Variable) ~
| |
+------------------+
Figure 2: SD-WAN NLRI Encoding
where:
Dunbar, et al. Expires 5 March 2027 [Page 11]
Internet-Draft SD-WAN Edge Discovery September 2026
Route Type: A 2-octet value that defines the encoding of the
reminder of the SD-WAN the NLRI.
Length: 2 octets indicating the length of the value field in octets.
This document defines the following SD-WAN Route type:
Route-Type = 1 (SD-WAN Tunnel Endpoint NLRI): For advertising the
detailed properties of the SD-WAN tunnels terminated at the edge,
where the transport network port can be uniquely identified by a
tuple of three values (Port-Local-ID, SD-WAN-Color, SD-WAN Node
ID). The SD-WAN NLRI Route Type =1 has the following encoding:
+------------------+
| Route-Type = 1 | 2 octets
+------------------+
| Length | 2 octets
+------------------+
| Port-Local-ID | 4 octets
+------------------+
| SD-WAN-Color | 4 octets
+------------------+
| SD-WAN Node ID | 4 or 16 octets
+------------------+
Figure 3: SD-WAN NLRI Route Type 1
Length: The value of the Length field for Route-Type 1 MUST be
either 12 octets (when the SD-WAN Node ID is an IPv4 address) or
24 octets (when the SD-WAN Node ID is an IPv6 address). Any other
value is invalid. Error handling for an invalid Length field is
specified in Section 2.6.2..
Port-local-ID: SD-WAN edge node Port identifier, which is locally
significant. If the SD-WAN NLRI applies to multiple WAN ports,
this field is zero.
SD-WAN-Color: identifies a group of Hybrid SD-WAN tunnels that may
Dunbar, et al. Expires 5 March 2027 [Page 12]
Internet-Draft SD-WAN Edge Discovery September 2026
span multiple SD-WAN logical tunnels co-located at the same site.
The BGP Peer supporting SD-WAN uses this SD-WAN-Color value to
allow local policy to correlate client routes identified by the
Color Extended Community to a specific group of Hybrid SD-WAN
tunnels or a specific set of underlay tunnels within the Hybrid
SD-WAN tunnel. If the SD-WAN-Color represents all tunnels at a
site, it effectively serves as a site-level identifier. If no
matching SD-WAN-Color is found, the client route is not be
forwarded over any SD-WAN tunnels. However, local configuration
MAY remove this restriction.
SD-WAN Node ID: This field carries the IPv4 or IPv6 address of the
SD-WAN edge node (C-PE). For IPv4 SD-WAN NLRI (AFI/SAFI 1/74),
this field contains a 4-octet IPv4 address representing a /32 host
address. For IPv6 SD-WAN NLRI (AFI/SAFI 2/74), this field
contains a 16-octet IPv6 address representing a /128 host address.
The SD-WAN Node ID identifies the IP address (usually the loopback
address) used by the SD-WAN edge node to advertise its tunnel
attributes of a tunnel underlay route within the logical SD-WAN
Hybrid logical tunnel.
2.2.2. Validation of SD-WAN NLRI
Upon receiving an SD-WAN NLRI, the following validation steps are
performed:
- Route Type Validation: The Route Type field MUST be equal to 1.
An SD-WAN NLRI with an unrecognized Route Type MUST be discarded
and MUST NOT be propagated, as specified for typed NLRIs in
Section 5.4 of [RFC7606].
- Length Field Validation: For Route type1, the Length field MUST
contain a value of either 12 or 24 octets, as defined in
Section 2.2.1. Any other value renders the SD-WAN NLRI malformed.
Error handling is specified in Section 2.6.2.
- SD-WAN Node ID: If Length = 12, the SD-WAN Node-ID field contains
an IPv4 Unicast address. If Length = 24, the SD-WAN Node-ID field
contains an IPv6 Unicast address. The SD-WAN Node-ID MUST be a
valid unicast address. Otherwise, the NLRI must be discarded.
Dunbar, et al. Expires 5 March 2027 [Page 13]
Internet-Draft SD-WAN Edge Discovery September 2026
2.2.3. BGP Path Attributes attached to SD-WAN NLRI
The Path Attributes attached to the SD-WAN NLRIs apply to the WAN-
facing tunnel endpoints being advertised, not to client routes.
These attributes describe properties of the WAN ports (e.g.,
encapsulation, transport role, or color) that may be used in
establishing SD-WAN underlay tunnels between edge nodes. Client
routes, which represent customer prefixes, are propagated using
separate BGP NLRIs (e.g., IPv4/IPv6 unicast or L3VPN), with their own
associated Path Attributes. The SD-WAN NLRI and client route NLRI
are independent but may be correlated by the receiving BGP speaker
for tunnel selection and service mapping.
2.3. IPsec SA Property Sub-TLVs
The IPsec SA Property Sub-TLVs defined in this section specify
encodings that allow BGP UPDATE messages to carry IPsec-related
parameters associated with SD-WAN Hybrid Tunnels to authorized peers.
BGP does not establish, negotiate, derive, or maintain IPsec SAs.
BGP validation of these Sub-TLVs is limited to their encoding and
syntactic validity. The creation and operation of an IPsec SA,
including algorithm validation, key derivation, SA state management,
rekeying, and packet protection, are performed by the IPsec
implementation according to [RFC4301] and, when IKEv2 is used,
[RFC7296], together with local policy. While these Sub-TLV formats
could potentially be reused in other applications that require IPsec
SA signaling over BGP, this document defines their semantics and
behavior specifically within the SD-WAN Edge Discovery framework.
If any sub-TLV is malformed, error handling MUST follow the procedure
in Section 13 of [RFC9012].
To support key rotation (e.g., updating IPsec keys or parameters),
the SD-WAN NLRI (identified by Port-Local-ID, SD-WAN-Color, and SD-
WAN Node ID) can be re-advertised via a BGP UPDATE message containing
updated IPsec SA information. In the centrally controlled SD-WAN
model described in this document, IPsec SA parameters and keying
material can be distributed to authorized SD-WAN edge nodes through
the RR/Controller. Therefore, peer-to-peer key negotiation between
SD-WAN edge nodes is not required by this mechanism. A deployment
MAY use IKEv2 or another key-management mechanism instead.
Dunbar, et al. Expires 5 March 2027 [Page 14]
Internet-Draft SD-WAN Edge Discovery September 2026
2.3.1. IPsec SA ID Sub-TLV
The IPsec SA ID Sub-TLV is used to reference one or more previously
established IPsec SAs between SD-WAN nodes. This Sub-TLV carries one
or more 32-bit Security Parameter Index (SPI) values assigned at the
receiving node (i.e., the inbound SPI). When combined with the SD-
WAN Node-ID (which identifies the underlay tunnel endpoint address),
each SPI uniquely identifies an existing IPsec SA, consistent with
the SA identification described in [RFC4301].
Multiple SPIs MAY be included within the Sub-TLV to reference
multiple pre-established IPsec SAs available for the SD-WAN overlay.
This enables advertisement of SA updates, key rotations, or
operational state changes without resending full SA parameter sets,
and allowing pairwise IPsec rekeying to proceed independently for
each SA.
Sub-TLV Name: IPsec SA ID
Sub-TLV Code: 64 (IANA assigned)
Sub-TLV Encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPsec SA ID Sub| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPsec SA Identifier #n |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 4: IPsec SA ID Sub-TLV
where:
* IPsec SA ID (8 bits): 64(IANA Assigned).
* Length (8 bits): Specifies the total length in octets of the
value field (not including the Type and Length fields). For
the IPsec SA ID Sub-Type, the Length field MUST be equal to 2 +
4 *(number of IPsec SA Identifier fields).
Dunbar, et al. Expires 5 March 2027 [Page 15]
Internet-Draft SD-WAN Edge Discovery September 2026
* Reserved: Reserved for future use. MUST be set to zero on
transmission and MUST be ignored on receipt.
* A sequence of IPsec SA Identifier fields follows the reserved
field. Each IPsec SA Identifier field is 4 octets long, and
identifies a pre-established IP security association.
Sub-TLV Error Handling: An IPsec SA ID Sub-TLV whose Length field is
not equal to 2 + 4 x (number of IPsec SA Identifier fields) is
malformed and is handled according to [RFC9012].
2.3.2. IPsec SA Rekey Counter Sub-TLV
The IPsec SA Rekey Counter Sub-TLV carries rekey-related information
associated with a specific IPsec Security Association (SA). The SA
is identified by the 32-bit Security Parameter Index (SPI) carried in
this Sub-TLV. Together with the IPsec protocol and destination
address associated with the advertised tunnel endpoint, the SPI
identifies the inbound IPsec SA as described in [RFC4301].
The Rekey Counter and Nonce Data defined in this Sub-TLV are SD-WAN-
specific fields. They are not IKEv2 protocol fields and do not
require IKEv2 signaling. BGP carries these fields as part of the SD-
WAN tunnel information but does not interpret them for route
selection or BGP processing.
Sub-TLV Name: IPsec SA Rekey Counter
Sub-TLV Code: 67 (IANA assigned)
Sub-TLV Encoding:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|SA-RekeyCounter| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved2 | Nonce Length |I| Flags |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey |
| Counter |
+---------------------------------------------------------------+
| IPsec SPI |
+---------------------------------------------------------------+
| |
~ Nonce Data ~
| |
+---------------------------------------------------------------+
Dunbar, et al. Expires 5 March 2027 [Page 16]
Internet-Draft SD-WAN Edge Discovery September 2026
where:
* IP SA-Rekey Counter (8 bits): IPsec SA Rekey Counter Sub-TLV
Type = 67 (IANA assigned).
* length (8 bits): Specifies the total length, in octets, of the
Sub-TLV value field, excluding the Type and Length fields. The
Length MUST equal 18 + Nonce Length.
* Reserved (16 bits): Reserved for future use. The Reserved
field MUST be set to zero and MUST be ignored upon receipt.
* Reserved2 (8 bits): Reserved for future use. The Reserved
field MUST be set to zero and MUST be ignored upon receipt.
* Nonce Length (16 bits): Indicates the length, in octets, of the
Nonce Data. The Nonce Length MUST be between 8 and 237 octets,
inclusive. A Nonce Length of at least 16 octets is
RECOMMENDED. The upper bound ensures that the complete Sub-TLV
value fits within the 255-octet limit imposed by the one-octet
Sub-TLV Length field.
* I Flag: When set to 1, the I Flag indicates that the advertised
information is associated with a new SA instance. When set to
0, it indicates an update associated with an existing SA
instance.
* Flags (7 bits): Reserved for future use. These bits MUST be
set to zero and MUST be ignored upon receipt.
* Rekey Counter (64 bits): Carries an unsigned counter associated
with rekeying of the identified IPsec SA. The Rekey Counter is
opaque to BGP and is passed unchanged to the SD-WAN/IPsec
implementation. BGP does not use this value for route
selection, freshness determination, or replay detection.
* SPI: Carries the 32-bit Security Parameter Index of the IPsec
SA. Together with the IPsec protocol and destination address
associated with the advertised tunnel endpoint, the SPI
identifies the inbound IPsec SA as described in [RFC4301].
* Nonce Data: Carries an SD-WAN-specific nonce associated with
the advertised IPsec SA information. The nonce can be used by
the receiving SD-WAN/IPsec implementation as a freshness value
when processing SA information. Generation, storage,
comparison, and replay handling of the nonce are outside the
scope of BGP.
Dunbar, et al. Expires 5 March 2027 [Page 17]
Internet-Draft SD-WAN Edge Discovery September 2026
Sub-TLV Error Handling: The Sub-TLV is malformed if the Length field
is not equal to 18 + Nonce Length, or if the Nonce Length is less
than 8 or greater than 237 octets.
A malformed IPsec SA Rekey Counter Sub-TLV is handled according to
the procedures specified in [RFC9012].
2.3.3. IPsec Public Key Sub-TLV
The IPsec Public Key Sub-TLV provides the Public Key exchange
information and the life span for the Diffie-Hellman Key. The
encoding is shown in the figure below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|IPsec-PublicKey| Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Key Exchange Method Group Num | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Key Exchange Data ~
| |
+---------------------------------------------------------------+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 5: IPsec SA Public Key Sub-TLV diagram
where:
IPSec-PublicKey (8 bits): Type value for Sub-TLV is 68 (IANA
assigned).
length (8 bits): The Length field MUST equal 10 + the Key Exchange
Data length. Because the fixed fields occupy 10 octets, the Key
Exchange Data MUST NOT exceed 245 octets.
Key Exchange Method Group Num (16 bits): identifies the key
exchange method used to compute the Key Exchange Data. Values are
taken from the IANA IKEv2 "Transform Type 4 - Key Exchange Method
Transform IDs" registry. Additional information on the key
exchange groups is provided in Appendix B of IKEv2 [RFC7296],
[RFC5114], and [RFC5903] for elliptic-curve groups.
Dunbar, et al. Expires 5 March 2027 [Page 18]
Internet-Draft SD-WAN Edge Discovery September 2026
Key Exchange data: This field contains a copy of the sender's
Diffie-Hellman public value. Because the RFC 9012 sub-TLV Length
field is one octet, the total value carried in this IPsec Public
Key Sub-TLV is limited to 255 octets. Therefore, the encoded
public value, together with the other fields in this Sub-TLV, MUST
fit within this limit. Elliptic-curve Diffie-Hellman groups are
RECOMMENDED because their public values are smaller; for example,
Groups 19, 20, and 21 use public values of 64, 96, and 132 octets,
respectively, as defined in [RFC5903]. If the selected Diffie-
Hellman public value cannot fit within this Sub-TLV, the public
key MUST be distributed by another mechanism, such as the SD-WAN
controller or management system.
Duration (32 bits): a 4-octet value specifying the life span of
the Diffie-Hellman key in seconds.
An IPsec Public Key Sub-TLV is considered malformed if any of its
fields do not conform to the encoding rules specified above.
Malformed Sub-TLVs are handled according to [RFC9012].
2.3.4. IPsec SA Proposal Sub-TLV
The IPsec SA Proposal Sub-TLV is used to advertise a set of
cryptographic parameters that define the proposal for establishing an
IPsec SA. In the centrally controlled SD-WAN model described in this
document, the participating SD-WAN edge nodes operate under
coordinated administrative policy, reducing the need to advertise
multiple alternative proposals for negotiation. Therefore, only one
IPsec SA Proposal Sub-TLV is processed for a given SD-WAN Hybrid
Tunnel TLV.
Sub-TLV Name: IPsec SA Proposal - Indicates IPsec Transform
Attributes
Sub-TLV Code: 69 (IANA assigned)
Each transform includes:
- A Transform Type, which identifies the function being specified
(e.g., encryption, integrity).
- A Transform ID, which specifies the algorithm for that function.
- Optional Transform Attributes, which provide additional algorithm-
specific parameters when necessary.
The encoding is shown below:
Dunbar, et al. Expires 5 March 2027 [Page 19]
Internet-Draft SD-WAN Edge Discovery September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA Proposal | Length | Reserved (16 bits) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform Attr Length |Transform Type | Reserved-2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Transform ID | Reserved-3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ Transform Attributes ~
| |
+---------------------------------------------------------------+
Figure 6: IPsec SA Proposal Sub-TLV diagram
where:
IPsec SA Proposal Sub-Type (8 bits): 69 (IANA assigned)
length (8 bits): Total length of the value field in octets (not
including Type and Length fields). This equals 10 + the Transform
attribute length.
Reserved (16 bits): reserved for future use. MUST be set to zero
on transmission and MUST be ignored on receipt.
Transform Attr Length (16 bits): length of the Transform
Attributes field in octets.
Transform Type (8 bits): The function being specified. Transform
Type values are defined in [RFC7296] and IANA IKEv2 Transform Type
registry. Valid types include: ENCR (1), PRF (2), INTEG (3), DH
(4), and ESN (5).
Reserved-2 (8 bits): Reserved for future use. MUST be set to zero
when transmitted and ignored upon receipt. Received values MUST
be propagated without change.
Transform ID (16 bits): Identifies the algorithm for the
corresponding Transform Type, as defined in [RFC7296].
Reserved-3 (16 bits): Reserved for future use. MUST be set to
zero when transmitted and ignored upon receipt. Received values
MUST be propagated without change.
Dunbar, et al. Expires 5 March 2027 [Page 20]
Internet-Draft SD-WAN Edge Discovery September 2026
Transform Attributes: This is a sequence of Transform attribute
TLVs. Each transform attribute TLV is encoded as defined in
[RFC7296] Section 3.3.5.
The Transform Attributes field may be omitted if no additional
parameters are required for the selected algorithm.
2.3.4.1. Sub-TLV Error Handling:
An IPsec SA Proposal Sub-TLV is considered malformed if:
- The Length field value does not match the actual length (Transform
Attr Length + 10).
- The Transform Attr Length field does not total length of all
Transform attributes parsed.
- Any Transform Attribute TLV whose type, length or value field
falls outside its valid range as specified in [RFC7296].
Malformed Sub-TLVs MUST be handled according to [RFC9012].
Additional content checks for the IPsec SA Proposal Sub-TLV are
described in Section 2.4 (for client routes) and Section 2.5 (for
underlay routes).
2.3.5. Simplified IPsec SA Sub-TLV
The Simplified IPsec SA Sub-TLV provides a compact way to signal
IPsec SA parameters in a centrally controlled SD-WAN environment
where the SD-WAN Controller or management system pre-configures the
participating SD-WAN nodes with the required IPsec algorithms, keying
methods, and other security parameters. Because these parameters are
configured consistently across the SD-WAN domain, this Sub-TLV does
not carry all of the information required for IPsec negotiation. It
carries the parameters and keying material needed to install and
operate the applicable SA instance.
Sub-TLV Name: Simplified IPsec SA
Sub-TLV Code: 70 (IANA assigned)
Sub-TLV Encoding:
Dunbar, et al. Expires 5 March 2027 [Page 21]
Internet-Draft SD-WAN Edge Discovery September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Sub-TLV type | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SA-Type | IPsec Mode | algorithms |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rekey Counter |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key1 length | Key 1 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| key2 length | Key 2 ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| nonce-length | Nonce ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Duration |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 7: Simplified IPsec SA Sub-TLV diagram
where:
Sub-TLV type (8 bits): Simplified IPsec SA Sub-TLV type (70)[IANA
assigned]
Length (8 bits): Specifies the total length, in octets, of the Sub-
TLV value field, excluding the Type and Length fields. The Length
MUST equal 18 + Key 1 Length + Key 2 Length + Nonce Length.
Therefore, the combined lengths of Key 1, Key 2, and Nonce MUST
NOT exceed 237 octets.
Reserved (16 bits): Reserved for future use. MUST be set to zero on
transmission and MUST be ignored on receipt.
SA-Type(8 bits):
* SA-Type = 1 means AH,
* SA-Type = 2 means ESP
All other SA-Type values are invalid.
IPsec Mode (8 bits):
* Mode = 1 indicates that the Tunnel mode is used.
* Mode = 2 indicates that the Transport mode is used.
Only Mode values 1 and 2 are valid. All other modes are invalid.
Algorithms (16 bits): Identifies the cryptographic algorithm used by
Dunbar, et al. Expires 5 March 2027 [Page 22]
Internet-Draft SD-WAN Edge Discovery September 2026
the advertised SA. When SA-Type = 1 (AH), the Algorithm field
identifies the AH integrity algorithm using the corresponding
value from the IANA Integrity Algorithm registry. When SA-Type =
2 (ESP), the Algorithm field identifies the ESP encryption
algorithm using the corresponding value from the IANA Encryption
Algorithm registry.
Rekey Counter (4 octet): Carries an unsigned counter associated with
key rotation for the advertised IPsec SA. The Rekey Counter
identifies the key generation associated with the advertised
keying material. Interpretation of the counter and selection of
the active key are performed by the SD-WAN/IPsec implementation.
The Rekey Counter is opaque to BGP.
key1 length (8 bits): Specifies the length, in octets, of the Key 1
field. The required key length is determined by the selected
Algorithm and the configured IPsec security profile.
Public Key 1: Carries one generation of keying material for the
advertised IPsec SA. The encoding and required length of the
keying material are determined by the selected Algorithm and the
configured IPsec security profile.
key2 length (8 bits): Specifies the length, in octets, of the Key 2
field. The required key length is determined by the selected
Algorithm and the configured IPsec security profile.
Public Key 2: Carries an alternate generation of keying material for
the advertised IPsec SA. Key 1 and Key 2 allow keying material
for a new generation to be distributed while the previous
generation remains available during rekeying. Selection and
retirement of the active key generation are performed by the SD-
WAN/IPsec implementation and are outside the scope of BGP.
nonce-length (8 bits): Specifies the length, in octets, of the Nonce
field. The Nonce is an SD-WAN-specific value. The Nonce Length
MUST be at least 8 octets. A Nonce Length of at least 16 octets
is RECOMMENDED. The combined Key 1, Key 2, and Nonce lengths MUST
satisfy the Sub-TLV Length constraint specified above.
Nonce: Carries an SD-WAN-specific nonce associated with the
advertised IPsec SA information. Generation and processing of the
nonce are performed by the SD-WAN/IPsec implementation and are
outside the scope of BGP.
Duration (32 bits): Specifies the lifetime of the advertised IPsec
SA in seconds.
Dunbar, et al. Expires 5 March 2027 [Page 23]
Internet-Draft SD-WAN Edge Discovery September 2026
A Simplified IPsec SA Sub-TLV is considered MALFORMED if any of its
fields are not properly encoded, do not conform to the specified
value ranges above, or contain invalid field lengths. Any MALFORMED
Sub-TLV is processed according to [RFC9012].
2.3.6. Extended Port Attribute Sub-TLV
The Extended Port Attribute Sub-TLV advertises NAT-related properties
associated with a public Internet-facing WAN port on an SD-WAN edge
node. This information enables peer SD-WAN nodes to establish secure
tunnels even when one or both peers are behind NAT devices. An SD-
WAN edge node may query a STUN server (Session Traversal Utilities
for NAT [RFC8489]) to determine its NAT properties, including its
public IP address and public port number. These properties are then
advertised to peer nodes using the Extended Port Attribute Sub-TLV.
In SD-WAN deployments, NAT devices may exist at one or both ends of
the tunnel path. The possible deployment scenarios include:
* Only one SD-WAN edge node is located behind a NAT device, while
its peer is directly reachable.
* Both SD-WAN edge nodes are behind NAT devices (symmetric or
independent NATs).
* The external address and port assigned to an edge node may change
dynamically, either due to ISP address allocation or when
traversing NAT devices that use dynamic address pools.
Because an SD-WAN edge node may have multiple WAN ports with
independent NAT characteristics, the NAT properties are associated
with individual WAN ports and are advertised independently for each
port using this Sub-TLV. This per-port advertisement allows remote
peers to construct appropriate NAT traversal parameters for each
potential tunnel endpoint.
Unlike pairwise NAT traversal mechanisms such as IKEv2 [RFC7296], in
which NAT-related information is discovered between peers during
tunnel establishment, the BGP-controlled SD-WAN architecture enables
an SD-WAN edge node to advertise its NAT properties through the RR to
authorized SD-WAN peers before individual tunnels are established.
This avoids requiring the same NAT-related information to be
discovered independently during the establishment of each SD-WAN
tunnel and can reduce repeated parameter exchange in deployments
where an SD-WAN edge establishes tunnels with many peers.
Sub-TLV Name: Extended Port Attribute
Dunbar, et al. Expires 5 March 2027 [Page 24]
Internet-Draft SD-WAN Edge Discovery September 2026
Sub-TLV Code: 65 (IANA assigned)
Sub-TLV Encoding: The encoding is shown in the figure below:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Type (65) | Length |Flags |I|O|R|R|R|R|R|R|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NAT Type | Encap-Type |Trans networkID| RD ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local IP Address |
| 32-bits for IPv4, 128-bits for Ipv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Local Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public IP |
| 32-bits for IPv4, 128-bits for Ipv6 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Public Port |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Extended Sub-Sub-TLV |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 8: Extended Port Attribute Sub-TLV
where:
* Length: Specifies the total length, in octets, of the Sub-TLV
value field, excluding the Type and Length fields. The Length
MUST equal: 10 + Local-IP-Length + Public-IP-Length + the total
encoded length of all included Extended Sub-Sub-TLVs. The Local-
IP-Length is 4 octets when the I bit is 0 and 16 octets when the I
bit is 1. The Public-IP-Length is 4 octets when the O bit is 0
and 16 octets when the O bit is 1.
* Flags (16 bits):
- Flags field starts with 8 bits which are reserved for future
use. MUST be set to 0, and ignored upon reception.
- I bit (C-PE port address or Inner address scheme):
o If set to 0, the Local IP Address field contains a 4-octet
IPv4 address.
o If set to 1, the Local IP Address field contains a 16-octet
IPv6 address.
Dunbar, et al. Expires 5 March 2027 [Page 25]
Internet-Draft SD-WAN Edge Discovery September 2026
- O bit (Outer address scheme):
o If set to 0, the Public IP Address field contains a 4-octet
IPv4 address.
o If set to 1, the Public IP Address field contains a 16-octet
IPv6 address.
- R bits: reserved for future use. MUST be set to 0, and ignored
upon reception.
* NAT Type (8 bits): an unsigned integer indicating the NAT behavior
observed for this WAN port. The values are derived from the
legacy NAT classification model described in RFC 8489 Section 5.
The assigned values are:
- 1: without NAT ;
- 2: 1-to-1 static NAT;
- 3: Full Cone;
- 4: Restricted Cone;
- 5: Port Restricted Cone;
- 6: Symmetric; or
- 7: Unknown (e.g. no response from the STUN server).
The NAT Type value is determined by the sender using NAT discovery
procedures (e.g., STUN [RFC8489] with legacy tests [RFC8489]) or
local administrative configuration. The receiver is not required
to verify NAT behavior but MUST validate that the received NAT
Type field is within the range 1-7. Values outside this range are
considered invalid and result in the Sub-TLV being treated as
malformed.
* Encap-Type (8 bits): An unsigned integer indicating the
encapsulation type supported for this WAN port. The Encap-Type
identifies the encapsulation protocol used within the IPsec
payload when IPsec SA Sub-TLVs (IPsec SA ID, IPsec SA Rekey
Counter, IPsec Public Key, IPsec SA Proposal, or Simplified IPsec
SA) are present in the SD-WAN Hybrid Tunnel. This field is
distinct from the Tunnel Type field in the BGP Tunnel
Encapsulation Attribute [RFC9012]. The encapsulation types are:
- Encap-Type=1: GRE;
Dunbar, et al. Expires 5 March 2027 [Page 26]
Internet-Draft SD-WAN Edge Discovery September 2026
- Encap-Type=2: VxLAN;
Notes:
- This document defines Encap-Type values 1 (GRE) and 2 (VXLAN).
Additional values may be assigned in the future through the
IANA registry. An unrecognized Encap-Type value does not by
itself make the Sub-TLV malformed; however, an implementation
MUST NOT use an encapsulation type that it does not support.
The Encap-Type identifies the encapsulation protocol used
within the IPsec payload when IPsec SA Sub-TLVs (IPsec SA ID,
IPsec SA Rekey Counter, IPsec Public Key, IPsec SA Proposal, or
Simplified IPsec SA) are present in the SD-WAN Hybrid Tunnel.
- The Extended Port Attribute Sub-TLV does not support NAT
traversal scenarios involving IPv4/IPv6 translation (e.g.,
NAT64 or 6to4).
* Trans NetworkID (Transport Network ID) (8 bits): An identifier
assigned by the SD-WAN Controller to indicate the transport
network that this WAN port belongs to. All values from 0 to 255
are valid.
* RD ID: The Routing Domain ID is a globally unique identifier
assigned to the routing domain associated with this WAN port. All
values from 0 to 255 are valid.
- Some SD-WAN deployments may define multiple levels, zones, or
regions that are represented as logical routing domains or
transport networks. Operational policies may govern whether
SD-WAN Hybrid tunnels or underlay tunnels are allowed between
nodes in different logical routing domains. The definition,
distribution, and enforcement of such policies are outside the
scope of this document.
* Local IP: The local or private IP address of the WAN port. The
address family and field length are determined by the I bit. If I
= 0, this field contains a 4-octet IPv4 address. If I = 1, this
field contains a 16-octet IPv6 address.
* Local Port: The port number associated with the local IP address
of the WAN endpoint. Together with the Local IP address, it
identifies the local endpoint of the NAT mapping. A value of 0
indicates that no port number is specified or applicable. Valid
values: 0x00 - 0xFFFFFFFF.
Dunbar, et al. Expires 5 March 2027 [Page 27]
Internet-Draft SD-WAN Edge Discovery September 2026
* Public IP: The public IP address of the WAN port after NAT
processing. The address family and field length are determined by
the O bit. If O = 0, this field contains a 4-octet IPv4 address.
If O = 1, this field contains a 16-octet IPv6 address. If NAT is
not used, this field MUST be set to all zeros.
* Public Port: The port number associated with the Public IP address
after NAT processing. Together with the Public IP address, it
identifies the public endpoint of the NAT mapping. If NAT is not
used, this field MUST be set to zero. Otherwise, the value can be
0x01 to 0xFFFFFFFF.
* If NAT is not used for the WAN port, both the Public IP and Public
Port fields MUST be set to zero. If one field is set to zero and
the other is non-zero, the Sub-TLV is considered malformed.
* Extended Sub-Sub-TLV: Carries additional information about the
underlay networks.
Sub-TLV Error Handling: If the Extended Port Attribute Sub-TLV is
malformed (e.g., incorrect length, invalid address format, or
unrecognized NAT type), it MUST be ignored per the procedures
described in [RFC9012].
Multiple Sub-TLVs: Multiple Extended Port Attribute Sub-TLVs are
allowed. If the informsation from multiple Extended Port
Attribute Sub-TLVs is the same, the first one is processed, the
rest is ignored.
2.3.6.1. Extended Port Sub-Sub-TLV
One Extended Sub-Sub-TLVs is specified in this document: Underlay
Network Type Sub-Sub-TLV.
The Underlay Network Type Sub-Sub-TLV is an optional Sub-Sub-TLV used
to advertise additional transport characteristics for the WAN port,
including connection type, physical port type, and port bandwidth
(e.g., LTE, DSL, Ethernet, and others). This information assists
remote peers or controllers in selecting optimal underlay paths when
multiple WAN ports are available. The Underlay Network Type Sub-Sub-
TLV is only valid for the Tunnel SD-WAN Hybrid Tunnel TLV within the
Extended Port Attribute Sub-TLV.
Underlay Network Type.
1 (IANA Assigned).
The encoding is shown in the figure below:
Dunbar, et al. Expires 5 March 2027 [Page 28]
Internet-Draft SD-WAN Edge Discovery September 2026
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UnderlayType | Length | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|Connection Type| Port Type | Port Speed |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 9: Underlay Network Type Sub-Sub-TLV
Where:
UnderlayType: Underlay Network Type (1 assigned by IANA)
Length: always 6 bytes
Reserved: 2-octet of reserved bits. It SHOULD be set to zero on
transmission and MUST be ignored on receipt.
Connection Type: An unsigned integer indicating the connection type
for this WAN port. Only a single value is carried per instance.
The following values are defined:
* 1 = Wired
* 2 = WIFI
* 3 = LTE
* 4 = 5G
* Values outside the range 1-4 are invalid and render the Sub-TLV
malformed.
Port Type: An unsigned integer indicating the physical port type of
the WAN interface. Only a single value is carried per instance.
The following values are defined:
* 1 = Ethernet
* 2 = Fiber Cable
* 3 = Coax Cable
* 4 = Cellular
* This document defines Connection Type values 1 through 4.
Additional values may be defined by future specifications and
assigned through the IANA registry. Until then, values other
Dunbar, et al. Expires 5 March 2027 [Page 29]
Internet-Draft SD-WAN Edge Discovery September 2026
than those defined by this document are unsupported. An
implementation receiving an unsupported Connection Type value
MUST NOT use that value for tunnel selection or establishment.
Port Speed: An unsigned 16-bit integer representing the port speed
in megabits per second (Mbps). For example, a value of 1000
represents a port speed of 1000 Mbps (1 Gbps). The valid range is
1-65535. A Port Speed value of 0 is invalid and renders the Sub-
TLV malformed.
The Underlay Network Type Sub-Sub-TLV is MALFORMED if its encoding or
length is invalid. This document defines the valid Connection Type
and Port Type values listed above. Additional values may be defined
by future specifications and assigned through the corresponding IANA
registries. Until such values are defined, other values are invalid.
If a MALFORMED Sub-Sub-TLV is contained in the Extended Port
Attribute Sub-TLV, then the Extended Port Attribute Sub-TLV is also
MALFORMED. Per [RFC9012], a MALFORMED Sub-TLV is ignored.
2.4. Procedure for Client Route Advertisements with SD-WAN Hybrid
Tunnel
Client routes with NLRI of AFI/SAFI IPv4 Unicast (1/1), IPv6 (2/1),
L3VPN v4 Unicast (1/128), and IPv6 L3VPN (2/128) that use the SD-WAN
Hybrid Tunnel Type can be advertised using one of two mechanisms:
Encapsulation Extended Community with SD-WAN SAFI: In this approach,
the client route is advertised using Encapsulation Extended
Community with the SD-WAN Hybrid tunnel type. The detailed tunnel
properties, such as IPsec SAs, WAN port attributes, NAT
properties, and other parameters, are advertised separately via
BGP UPDATE messages using the SD-WAN SAFI. The SD-WAN Node ID,
carried as the NextHop in client route advertisements and as the
SD-WAN Node ID in SD-WAN SAFI underlay route advertisements,
enables receiving BGP nodes to associate client routes with the
correct underlay tunnels.
Tunnel Encapsulation Attribute: Alternatively, client routes UPDATEs
can include all tunnel-related information directly in the same
BGP UPDATE using the Tunnel Encapsulation Attribute. The SD-WAN
Hybrid Tunnel TLV specifies the outer tunnel through which the
underlay tunnel identified by SD-WAN Node ID passes. This outer
tunnel is identified by the Tunnel Egress Endpoint Sub-TLV. When
the BGP Next Hop is used as the tunnel endpoint, the Tunnel Egress
Endpoint Sub-TLV is encoded with Address Family 0 as specified in
[RFC9012].
Dunbar, et al. Expires 5 March 2027 [Page 30]
Internet-Draft SD-WAN Edge Discovery September 2026
The Tunnel Encapsulation Attribute based approach, which includes all
tunnel attributes within route advertisement, can simplify the
processing at the receiving nodes. However, it may lead to
significant BGP attribute overhead, particularly when multiple IPsec
SAs are eligible to carry the same client route. In contrast, the
Encapsulation Extended Community approach (the "barebones" method
defined in [RFC9012]) combined with SD-WAN SAFI separates tunnel
attributes from route Updates, allows tunnel properties to be reused
across multiple client routes.
The SD-WAN Secure Links topology is supported using unicast IPv4 and
IPv6 routes. L3VPN topologies, on the other hand, support the
formation of Secure SD-WAN L3VPNs as described in [SD-WAN-BGP-USAGE]
and MEF specifications [MEF 70.1] and [MEF 70.2].
2.4.1. SD-WAN Hybrid Tunnel Type in Encapsulation Extended Community
When client routes are advertised using the Encapsulation Extended
Community with the SD-WAN Hybrid Tunnel Type, as specified in
[RFC9012], the Encapsulation Extended Community identifies the tunnel
type, and the NextHop field in the BGP UPDATE serves as the Tunnel
Egress Endpoint. Validation of the Tunnel Egress Endpoint follows
the procedures defined in Sections 13 of [RFC9012], as applied to the
NextHop.
The Color Extended Community is used to associate a client route with
its eligible underlay tunnels. The Color value in the client route
identifies the set of underlay tunnels, previously advertised with
the same Color via SD-WAN SAFI, that may be used to transport the
traffic. This enables SD-WAN ingress nodes or controllers to apply
path selection policies based on performance, cost, or service
requirements.
2.4.2. SD-WAN Hybrid Type in Tunnel Attributes via Tunnel Encapsulation
Attribute
When client routes are advertised using the Tunnel Encapsulation
Attribute with the SD-WAN Hybrid Tunnel Type, the following
procedures apply for validating the BGP UPDATE message:
1. Check for Well-formed SD-WAN Hybrid Tunnel TLV: For Client
Dunbar, et al. Expires 5 March 2027 [Page 31]
Internet-Draft SD-WAN Edge Discovery September 2026
Routes, the SD-WAN Hybrid Tunnel TLV and its Tunnel Egress
Endpoint Sub-TLV are validated and handled according to [RFC9012].
MALFORMED and unrecognized Sub-TLVs are handled according to
[RFC9012]. The SD-WAN Hybrid Tunnel TLV processes only the first
instance of each Sub-TLV, except for the IPsec SA ID Sub-TLV.
Multiple IPsec SA ID Sub-TLVs MAY be processed if their IPsec SA
Identifiers are unique. If a subsequent IPsec SA ID Sub-TLV
contains an identifier already advertised in an earlier instance,
that Sub-TLV is ignored and not propagated.
2. Validate Tunnel Egress Endpoint: Per [RFC9012] validation
procedures for a Tunnel Egress Endpoint. Note: The Tunnel Egress
Endpoint represents the outer tunnel through which the underlay
tunnels specified by the SD-WAN NLRI operate. The tunnel link MAY
be active or inactive.
3. Check for Multiple SD-WAN Hybrid Tunnel TLVs Multiple unique SD-
WAN Hybrid Tunnel TLVs MAY be included in the Tunnel Encapsulation
Attribute, but duplicate SD-WAN Hybrid Tunnel TLVs should be
ignored silently. Optionally, duplicate SD-WAN Hybrid Tunnel TLVs
MAY be logged.
4. Validate each NLRI: Local policy is run to validate routes.
5. Validate Next Hop: The Next Hop MUST be be reachable via the
tunnel.
2.4.3. Client Routes Carried Over Multiple SD-WAN Hybrid Tunnels
When a client route is advertised with the Encapsulation Extended
Community that identifies the SD-WAN Hybrid Tunnel Type, the route
may also include a Color Extended Community (Color-EC). This
combination allows the route to be carried over multiple underlay
tunnels that were previously advertised, each with the same Color
value.
The Color-EC serves as a correlation mechanism: all underlay tunnels
that have been advertised (via SD-WAN SAFI) with the same Color value
are considered eligible to carry the traffic for the client route.
This approach supports flexible path selection and tunnel diversity
while avoiding the need to enumerate each tunnel per route.
This model is especially useful when:
* A site has multiple available IPsec tunnels or WAN links.
Dunbar, et al. Expires 5 March 2027 [Page 32]
Internet-Draft SD-WAN Edge Discovery September 2026
* A centralized controller or ingress SD-WAN edge node must select
the optimal tunnel for forwarding based on performance, policy, or
service constraints.
The tunnel attributes, including IPsec parameters, NAT traversal
info, and WAN port properties, are conveyed separately via SD-WAN
SAFI updates. This keeps client route updates minimal, allowing
multiple routes to reference the same tunnel attributes by using the
Color-EC.
2.4.4. SD-WAN VPN ID in Control Plane
In a BGP-controlled SD-WAN network, the VPN ID distinguishes client
VPNs and ensures route separation. It is conveyed in client route
UPDATEs as follows:
* For IPv4/IPv6 Unicast (AFI/SAFI = 1/1 or 2/1), client routes
received from different client-facing ports may be configured to
belong to different VPNs when traversing the SD-WAN network. The
Route Target Extended Community [RFC4360] SHOULD be included in
the BGP advertisement to identify the VPN associated with each
client route. Remote SD-WAN edge nodes use the Route Target to
associate the received client route with the corresponding VPN
forwarding context. If all client routes belong to a single VPN,
the Route Target MAY be omitted.
* For VPN-IPv4/VPN-IPv6 routes (AFI/SAFI = 1/128 or 2/128), the
Route Distinguisher is part of the BGP NLRI and distinguishes
otherwise identical prefixes belonging to different VPNs. The
Route Target controls VPN membership and route import/export
policy. Overlapping prefixes belonging to different VPNs
therefore use VPN-IPv4/VPN-IPv6 routes with distinct Route
Distinguishers.
2.4.5. SD-WAN VPN ID in Data Plane
In the data plane, client traffic belonging to different VPNs MUST
remain distinguishable while traversing the SD-WAN network. The
method used to carry the VPN identifier depends on the encapsulation:
* For MPLS segments, an MPLS label is used to distinguish traffic
belonging to different VPNs according to the applicable MPLS VPN
procedures.
* For IPsec segments, the VPN identifier is carried within the
encapsulation protected by IPsec. For GRE encapsulation, the GRE
Key field is used to identify the VPN. For VXLAN encapsulation,
the VNI (Virtual Network Identifier) is used to identify the VPN.
Dunbar, et al. Expires 5 March 2027 [Page 33]
Internet-Draft SD-WAN Edge Discovery September 2026
2.5. Procedure for SD-WAN Underlay Routes with SD-WAN Hybrid Tunnel TLV
Underlay tunnel routes in a BGP-controlled SD-WAN network are
advertised using the SD-WAN SAFI, with the Tunnel Encapsulation
Attribute carrying a SD-WAN Hybrid Tunnel TLV. The Tunnel Egress End
Point Sub-TLV (assumed or sent) indicates the other tunnel through
which these underlay tunnels operate.
Remote nodes use the SD-WAN information carried in the SD-WAN SAFI,
together with the applicable Color and local SD-WAN policy, to
associate Client Routes with the tunnel attributes advertised by the
corresponding SD-WAN edge nodes. The SD-WAN Node ID identifies an
individual SD-WAN edge node, while the SD-WAN-Color identifies a
group of eligible SD-WAN tunnels. Tunnels associated with the same
SD-WAN-Color MAY terminate on different WAN ports or different SD-WAN
edge nodes. This enables multiple SD-WAN edge nodes to provide
connectivity for the same Color group, subject to local policy. The
BGP Next Hop identifies a reachable address of the advertising SD-WAN
edge node and is not required to equal the SD-WAN Node ID.
Normal BGP best-path selection applies when multiple paths for the
same SD-WAN NLRI are received; the SD-WAN Hybrid Tunnel TLV and its
Sub-TLVs do not participate in best-path selection. The RR reflects
authorized SD-WAN Underlay Routes within the SD-WAN administrative
domain according to [RFC4456].
2.5.1. SD-WAN Underlay Route without Encapsulation Extended Community
The SD-WAN Hybrid NLRI MUST be accompanied by the Tunnel
Encapsulation Attribute, and MUST NOT be accompanied by an
Encapsulation Extended Community.
2.5.2. Underlay Route with a Tunnel Encapsulation Attribute
The procedure for processing underlay routes follows the following
steps:
1. Check for Well-Formed SD-WAN Hybrid Tunnel TLV: A SD-WAN Hybrid
Tunnel TLV is well-formed using only Sub-TLVs valid for
association with the underlay Route (see section 2.1). The IPsec
SA ID sub-TLVs MAY have multiple instances of the sub-TLV if the
IPsec SA Identifiers are unique, but if the IPsec SA Identifiers
are not unique the second sub-TLV is ignored and not propagated.
If multiple Extended Port Sub-TLVs exist, the TLVs must be
validated in step 4. For all other valid Sub-TLVs (see section
2.1), only the first instance of a Sub-TLV is processed;
subsequent ones are ignored.
Dunbar, et al. Expires 5 March 2027 [Page 34]
Internet-Draft SD-WAN Edge Discovery September 2026
2. Validate Tunnel Egress Endpoint: The Tunnel Egress Endpoint
validation is done per [RFC9012] rules either on the Tunnel Egress
Endpoint Sub-TLV received in the UPDATE or an "assumed" Tunnel
Egress Endpoint if no Tunnel Egress Endpoint Sub-TLV exists in the
TLV (see section 2.1). Practically, the outer tunnel group either
identifies a specific WAN interface or (in the case of the
"assumed" Tunnel Egerss Endpoint) the remote SD-WAN edge node at
which the outer SD-WAN Hybrid Tunnel terminates.
3. Validate Extended Port Attribute Sub-TLV(s): As described in
Section 2.3.6, each Extended Port Attribute sub-TLV describes the
properties of a single WAN port. Therefore, multiple Extended
Port sub-TLVs may be present when the SD-WAN edge node has
multiple WAN ports. Each Sub-TLV MUST be validated for correct
encoding and field values according to Section 2.3.6. If an
Extended Port Attribute Sub-TLV is malformed, it MUST be handled
according to Section 13 of [RFC9012] and Section 2.6.1 of this
document.
4. Validate each NLRI: Each typed NLRI in the SD-WAN Underlay MUST
be well-formed, meaning it conforms to the structure defined in
Section 2.2.1, including correct field lengths and ordering. A
MALFORMED NLRI MUST be discarded; implementations MAY log an
error.
5. Validate Next Hop: The MP_REACH_NLRI Next Hop MUST satisfy the
encoding requirements specified in Section 2.2.1 and identify a
reachable address of the advertising SD-WAN edge node. The SD-WAN
Underlay Route carries tunnel-control information and is not
installed as a forwarding route for user traffic.
2.5.3. Underlay Routes with Port-Local-ID of Zero
As specified in Section 2.2.1, a Route Type 1 NLRI includes the tuple
(Port-Local-ID, SD-WAN-Color, SD-WAN Node ID). The Port-Local-ID
field MAY be set to zero to indicate that the NLRI applies to all WAN
ports on the identified SD-WAN node, effectively representing tunnel
attributes at the node level rather than a specific port.
When Port-Local-ID = 0, the receiving BGP speaker SHOULD apply local
policy to determine how to associate client routes with underlay
tunnels. This local policy may prefer tunnels from specific SD-WAN
nodes, or choose among SD-WAN Colors based on administrative
preference, link type, path performance, or service-level objectives.
The exact selection logic is implementation-specific.
Dunbar, et al. Expires 5 March 2027 [Page 35]
Internet-Draft SD-WAN Edge Discovery September 2026
It is valid for multiple such node-level NLRIs to be received, each
advertising different SD-WAN Colors for the same node. For example,
the following three NLRIs may be received (within one or more UPDATE
messages):
Port-Local-ID (0), SD-WAN-Color (10), SD-WAN Node ID (192.0.2.2),
Port-Local-ID (0), SD-WAN-Color (20), SD-WAN Node ID (192.0.2.2),
and
Port-Local-ID (0), SD-WAN-Color (30), SD-WAN Node ID (192.0.2.2).
These indicate that node 192.0.2.2 supports multiple tunnel groups,
each classified by a different SD-WAN Color. For example, these
Colors may correspond to service tiers such as gold, silver, and
bronze. The SD-WAN-Color field is used to correlate underlay tunnels
with client routes that carry a matching Color Extended Community.
If no match is found, the client route may not be forwarded over any
SD-WAN tunnel.
2.5.4. Multiple Tunnels Associated with One SD-WAN Underlay Route
An underlay tunnel passes through only one SD-WAN Hybrid Tunnel.
Therefore, if there are more than one SD-WAN Hybrid Tunnel TLV within
a single Tunnel Encapsulation Attribute, the first is processed and
the subsequent SD-WAN Hybrid Tunnel TLVs are ignored.
2.6. Error handling
This section specifies the error-handling procedures for validation
failures identified by the procedures in Sections 2.4 and 2.5. It
covers Tunnel Encapsulation signaling and SD-WAN Underlay Route
errors.
Section 2.4 specifies the procedures for Client Routes, and
Section 2.5 specifies the procedures for SD-WAN Underlay Routes.
2.6.1. Error handling for Tunnel Encapsulation Signaling
For Client Routes, error handling for the Tunnel Encapsulation
Attribute follows Section 13 of [RFC9012]. For SD-WAN Underlay
Routes using SAFI 74, error handling for the Tunnel Encapsulation
Attribute and its Sub-TLVs is defined by this document. Sub-TLVs
that are not applicable to SAFI 74 MUST be ignored and MAY be removed
when the route is propagated.
Dunbar, et al. Expires 5 March 2027 [Page 36]
Internet-Draft SD-WAN Edge Discovery September 2026
A malformed Sub-TLV within an SD-WAN Hybrid Tunnel TLV MUST be
handled according to Section 13 of [RFC9012]. Unless explicitly
specified otherwise in this document, the malformed Sub-TLV is
treated as an unrecognized Sub-TLV and ignored; it does not cause the
entire SD-WAN Hybrid Tunnel TLV or the associated route to be
withdrawn.
For Client Routes carrying a Tunnel Encapsulation Attribute with an
SD-WAN Hybrid Tunnel TLV, the IPsec Sub-TLVs (IPsec SA ID, IPsec SA
Rekey Counter, IPsec Public Key, IPsec SA Proposal, and Simplified
IPsec SA) MAY be included. Malformed Sub-TLVs are handled according
to [RFC9012].
If multiple instances of the IPsec Rekey Counter, IPsec Public Key,
IPsec Proposal, and Simplified IPsec are received within a SD-WAN
Hybrid Tunnel TLV , only the first is processed. The second instance
is ignored and not propagated. The IPsec SA ID MAY have multiple
copies, but the IPsec SA Identifiers sent in the second sub-TLV MUST
be different than any in the first IPsec SA ID sub-TLV.
If multiple instances of the Extended Port sub-TLV are received, the
local policy MUST determine which is to be used.
2.6.2. Error Handling for NLRI
The SD-WAN NLRI [AFI/SAFI = 1/74 or 2/74] utilizes a Route Type field
to describe the format of the NLRI. This specification defines Route
Type 1. An NLRI with an unsupported Route Type MUST be discarded and
MUST NOT be propagated to other peers. The implementation MAY log an
error upon reception of an unsupported Route Type.
If a recognized SD-WAN NLRI is malformed but its Length field still
allows the receiver to determine where that NLRI ends and the next
NLRI begins, the affected NLRI MUST be handled as Treat-as-withdraw
according to [RFC7606]. Error handling for other malformed SD-WAN
NLRIs follows the BGP UPDATE error-handling procedures specified in
[RFC7606].
If the MP_REACH_NLRI Next Hop field for an SD-WAN Underlay Route has
an invalid encoding or length such that the NLRI field cannot be
reliably located, the error MUST be handled according to the
applicable session-reset or AFI/SAFI-disable procedures specified in
[RFC7606].
Local configuration and policy MUST carefully constrain the SD-WAN-
NLRI, tunnels, and IPsec security associations to create a "walled
garden".
Dunbar, et al. Expires 5 March 2027 [Page 37]
Internet-Draft SD-WAN Edge Discovery September 2026
2.6.3. SD-WAN NLRI and Tunnel Encapsulation Attribute
The SD-WAN NLRI (AFI/SAFI=1/74 or 2/74) MUST be paired with a Tunnel
Encapsulation Attribute containing an SD-WAN Hybrid Tunnel TLV. If
the SD-WAN NLRI exists in a BGP UPDATE without a Tunnel Encapsulation
Attribute containing an SD-WAN Hybrid Tunnel TLV, the NLRI is
considered malformed and the Treat-as-withdraw approach specified in
[RFC7606] MUST be used.
TThe SD-WAN NLRI MUST NOT be paired with an Encapsulation Extended
Community. If an SD-WAN NLRI is paired with an Encapsulation
Extended Community rather than a Tunnel Encapsulation Attribute, the
SD-WAN NLRI is considered malformed and the Treat-as-withdraw
approach specified in [RFC7606] MUST be used.
3. Operational Consistency and Tunnel Validation
Unlike MPLS VPN whose PE nodes are all controlled by the network
operators, SD-WAN edge nodes can be installed anywhere, in shopping
malls, in 3rd party Cloud DCs [Net2Cloud], etc.
It is essential to ensure that advertisements from an SD-WAN edge
node are legitimate. The RR, which maintains policy information
about which SD-WAN nodes are authorized to communicate, MUST verify
that the advertising BGP speaker is permitted to originate SD-WAN
Hybrid Tunnel information before reflecting such routes to other
peers.
3.1. Detecting Misaligned Tunnels
It is critical that a SD-WAN Hybrid Tunnel forwards traffic in
accordance with local policy, taking into account the client route
attributes, tunnel ingress and egress endpoints, and the associated
security parameters.
To maintain correctness and security, both the RR and BGP speakers
SHOULD validate that the client routes and associated tunnel
information are consistent with expected configurations. This
includes verifying that:
* The NextHop in the client route update matches a known SD-WAN Node
ID.
* The tunnel's egress endpoints are reachable and authorized.
* The advertised SD-WAN Color in the underlay NLRI matches the Color
Extended Community attached to the client route.
Dunbar, et al. Expires 5 March 2027 [Page 38]
Internet-Draft SD-WAN Edge Discovery September 2026
3.2. IPsec Attributes Mismatch
Each SD-WAN node (e.g., a C-PE) can advertise its IPsec-related
attributes to remote peers using Sub-TLVs within the Tunnel
Encapsulation Attribute, in one of the following three forms, to
support the establishment of IPsec SAs:
* Identifiers of a pre-established IPsec SA, carried in IPsec SA ID
Sub-TLV.
* a simplified set of security parameters for setting up a IPsec SA,
such as Transform type, IPsec Mode, AH/ESP Algorithms, rekey
counter, 2 public keys, nonce, and duration, carried in the
Simplified IPsec SA Sub-TLV.
* A flexible representation of IPsec parameters, where the Nonce,
Public Key, and SA Proposal are individually specified and carried
in the IPsec SA Rekey Counter Sub-TLV, IPsec Public Key Sub-TLV,
and IPsec SA Proposal Sub-TLV, respectively.
For existing IPsec SAs, an SD-WAN node that receives the
advertisement can simply use one of the existing SAs to forward
traffic for the associated client routes. If multiple SAs are
available for a given client route, local policy on the receiving SD-
WAN node MAY determine which SA is selected.
When parameters carried in these Sub-TLVs are used to establish a new
IPsec SA, the receiving SD-WAN node passes the advertised parameters
to its IPsec function. The IPsec implementation determines whether
the advertised transforms and algorithms are compatible with local
configuration and performs SA establishment according to [RFC4301]
and, when IKEv2 is used, [RFC7296]. These attributes, received via
the Tunnel Encapsulation Attribute, provide the parameters associated
with establishing the IPsec tunnel between local and remote WAN
ports. BGP itself does not perform IPsec negotiation, compatibility
checking, or SA establishment. If the IPsec implementation cannot
use the advertised parameters, this does not by itself make the BGP
advertisement malformed.
The C-PE devices do not attempt to negotiate IPsec SA parameters or
transform sets with remote peers. Instead, the configurations must
match as advertised. If there is a mismatch, either in the simple
IPsec SA identifiers or in the detailed transform parameters, no
tunnel is established. Implementations MAY discard incompatible
proposals or log them for operational visibility.
Dunbar, et al. Expires 5 March 2027 [Page 39]
Internet-Draft SD-WAN Edge Discovery September 2026
3.2.1. Example creation of IPsec SA over SD-WAN Hybrid Tunnel
This section provides an example illustrating how an IPsec SA is
established over an SD-WAN Hybrid Tunnel. Assume an IPsec tunnel is
to be created between port P2 (198.51.100.10) on C-PE1 and port P2
(192.0.2.1) on C-PE2.
To establish this tunnel, C-PE1 must advertise the following
attributes required for setting up the IPsec SA:
* NextHop: 198.51.100.10
* SD-WAN Node ID: 192.0.2.1
* SD-WAN-Color: 1502
* Tunnel Encap Attr (Type = SD-WAN Hybrid Tunnel) -
- Extended Port Attribute Sub-TLV containing
o Transport Sub-Sub-TLV - with information on ISP.
- IPsec information for detailed information about the ISP
- IPsec SA Rekey Counter Sub-TLV,
- IPsec SA Public Key Sub-TLV,
- Proposal Sub-TLV (type = ENCR, transform ID = 1)
o type: ENCR
o Transform ID: 1
o Tranform attributes = trans 1 [from RFC7296]
- No Tunnel Egress EndPoint Sub-TLV
o Without a Tunnel Egress EndPoint Sub-TLV, the SD-WAN Hybrid
Tunnel processing treats this as though a Tunnel Egress
EndPoint Sub-TLV with an AFI of 0 has been received. Per
[RFC9012] this assumes a tunnel egress endpoint of the
NextHop value of 198.51.100.10.
C-PE2 needs to advertise the following attributes for establishing
the IPsec SA:
Next Hop: 192.0.2.1
Dunbar, et al. Expires 5 March 2027 [Page 40]
Internet-Draft SD-WAN Edge Discovery September 2026
SD-WAN Node ID: 192.0.2.2
SD-WAN-Color: 1500
Tunnel Encap Attr (Type=SD-WAN)
* Extended Port Attribute Sub-TLV
- Transport Sub-Sub-TLV - with information on ISP.
* IPsec SA Rekey Counter Sub-TLV,
* IPsec SA Public Key Sub-TLV,
* IPSec Proposal Sub-TLV with
- transform type: ENCR
- Transform ID = 1
- Transform attributes = trans 2
* No Tunnel Egress EndPoint Sub-TLV
- Without a Tunnel Egress EndPoint Sub-TLV, the SD-WAN Hybrid
Tunnel processing treats this as though a Tunnel Egress
EndPoint Sub-TLV with an AFI of 0 has been received. Per
[RFC9012] this assumes a tunnel egress endpoint of the
NextHop value of 192.0.2.1.
As there is no matching transform between the WAN ports P2 and P2 in
C-PE1 and C-PE2, respectively, no IPsec Tunnel will be established.
4. Manageability Considerations
The BGP-based signaling mechanisms described in this document are
primarily intended to enable SD-WAN edge nodes to advertise underlay
transport and tunnel parameters to their RR. These parameters, once
received, can be monitored and validated using existing BGP
monitoring tools such as BMP or route policy inspection frameworks.
Operators SHOULD implement logging and alerting mechanisms for cases
where inconsistent or malformed Sub-TLVs are received, as specified
in Section 2.6. Misaligned parameters, such as mismatched IPsec SA
IDs or invalid NAT indicators, should trigger operational alerts to
aid troubleshooting.
No new MIB modules or YANG models are introduced in this document,
but implementations are expected to expose relevant state (e.g.,
tunnel type, advertised properties) via standard operational
Dunbar, et al. Expires 5 March 2027 [Page 41]
Internet-Draft SD-WAN Edge Discovery September 2026
interfaces. The secure-transport requirements for BGP sessions
carrying the SD-WAN information defined in this document are
specified in Section 1.
5. Security Considerations
This document defines BGP extensions for SD-WAN edge nodes to
advertise their attributes for establishing IPsec SAs and underlay
tunnel attributes, typically via a RR that is part of the SD-WAN
Controller, which then propagates them to authorized SD-WAN peers.
As described in Sections 1 and 3, the RR/Controller maintains the
authorization policy for the SD-WAN domain and verifies that an
advertising SD-WAN edge is authorized to originate the corresponding
SD-WAN tunnel information before reflecting it to other peers. These
BGP UPDATEs may contain sensitive information such as public keys,
IPsec proposals, and nonces. In deployments where SD-WAN edge nodes
communicate with the RR over public or untrusted networks, BGP SHOULD
be run over TCP-AO secure transport that provides authentication and
integrity for this data.
Some network operators running SD-WAN edge over public or untrusted
networks may require confidentiality in addition to authentication
and integrity. In such deployments, a mechanism providing
confidentiality, such as IPsec [RFC4301], can be used to protect the
path between the SD-WAN edge and the RR.
These two sets of secure transport technologies for BGP provide
different levels of protection against tampering or interception.
These secure transport connections are needed to protect all fields,
including cryptographic attributes, from tampering or interception.
Without such protection, the system maybe vulnerable to spoofed
tunnel attributes, unauthorized route injections, or replayed IPsec
setup information.
As specified in Section 2.3, BGP only distributes IPsec-related
parameters; IPsec SA establishment and operation are performed by the
IPsec implementation according to [RFC4301] and, when IKEv2 is used,
[RFC7296].
In closed or "walled garden" deployments, where SD-WAN edge nodes and
the RR are within a trusted and secured environment, the risk of
interception or tampering may be reduced. However, the peer-
authentication and integrity requirements specified in Section 1
still apply.
Regardless of the transport used, BGP policy enforcement remains
critical. The RR SHOULD apply strict filtering and policy controls
to validate that only authorized SD-WAN edge nodes advertise specific
Dunbar, et al. Expires 5 March 2027 [Page 42]
Internet-Draft SD-WAN Edge Discovery September 2026
Node IDs, Route Targets, or VPN identifiers. While route origin
validation via RPKI helps, it does not cover SD-WAN-specific fields
like Tunnel attributes or SA proposals. Local policies, when
misconfigured, may introduce vulnerabilities; therefore, policy
application points SHOULD be carefully audited.
Many of the general BGP security risks discussed here are also
covered in [RFC4271], [RFC4272], and [RFC9012]. This document
inherits those considerations and introduces no new cryptographic
requirements beyond what is described for securing BGP transport and
validating the correctness of SD-WAN tunnel attribute exchanges.
This specification does not define deployments across fully untrusted
networks, but if such environments are used, strong transport
security becomes a MUST, and additional validation mechanisms may be
required to maintain SD-WAN tunnel and routing integrity. This
document does not analyze the consequences of compromise or
misconfiguration of the RR/Controller, the forward-secrecy properties
of IPsec SAs established using parameters distributed by BGP, the
control-plane impact of large-scale IPsec rekeying, or provide a
general comparison with alternative mechanisms for SD-WAN discovery
or IPsec SA establishment.
6. IANA Considerations
6.1. SD-WAN SAFI
IANA has assigned SAFI = 74 as the SD-WAN SAFI.
6.2. Tunnel Encapsulation Attribute Tunnel Type
IANA is requested to assign a type from the BGP Tunnel Encapsulation
Attribute Tunnel Types registry in the Border Gateway Protocol Tunnel
Encapsulation Group as follows [RFC8126]:
Value Description Reference
----- ------------ ---------
25 SD-WAN-Hybrid (this document)
6.3. Tunnel Encapsulation Attribute Sub-TLV Types
IANA has previously assigned the following Sub-TLV Types in the BGP
Tunnel Encapsulation Attribute Sub-TLVs registry in the Border
Gateway Protocol Tunnel Encapsulation Group. IANA is requested to
update the descriptions and references for these existing assignments
as follows:
Dunbar, et al. Expires 5 March 2027 [Page 43]
Internet-Draft SD-WAN Edge Discovery September 2026
Value Type Description Reference Section
----- ----------------------- ------------- -------
64 IPsec SA ID This document 2.3.1
65 Extended Port Attribute This document 2.3.6
67 IPsec SA Rekey Counter This document 2.3.2
68 IPsec Public Key This document 2.3.3
69 IPsec SA Proposal This document 2.3.4
70 Simplified IPsec This document 2.3.5
IANA is requested to return the existing value 66 assignment in the
BGP Tunnel Encapsulation Attribute Sub-TLVs registry to the
unassigned pool.
6.4. SD-WAN Edge Discovery NLRI Route Types
IANA is requested to create a new registry titled "SD-WAN Edge
Discovery NLRI Route Types" under the "Border Gateway Protocol (BGP)
Parameters" group. The allocation policy for this registry shall be
IETF Review (as defined in RFC 8126):
Value Description Reference
----- ------------ ---------
1 SD-WAN Tunnel Endpoint NLRI Route Type (this document)
Values 2-65535 are Unassigned.
6.5. SD-WAN Extended Port Encapsulation Types
IANA is requested to create a new registry titled "SD-WAN Extended
Port Encapsulation Types" under the BGP Tunnel Encapsulation Group.
Value Type Description Reference
----- ----------------------- -------------
0 Reserved This document
1 GRE This document
2 VXLAN This document
3~255 Unassigned
6.6. SD-WAN Extended Port Connection Types
IANA is requested to create a new registry titled "SD-WAN Extended
Port Connection Types" under the BGP Tunnel Encapsulation Group.
Dunbar, et al. Expires 5 March 2027 [Page 44]
Internet-Draft SD-WAN Edge Discovery September 2026
Value Type Description Reference
----- ----------------------- -------------
0 Reserved This document
1 Wired This document
2 WIFI This document
3 LTE This document
4 5G This document
5~254 Unassigned
255 Reserved for Experimental Use
6.7. SD-WAN Extended Port Physical Port Types
IANA is requested to create a new registry titled "SD-WAN Extended
Port Physical Port Types" under the BGP Tunnel Encapsulation group.
Value Type Description Reference
----- ----------------------- -------------
0 Reserved This document
1 Ethernet This document
2 Fiber Cable This document
3 Coax Cable This document
4 Cellular This document
5~254 Unassigned
255 Reserved for Experimental Use
6.8. SD-WAN Extended Port Sub-Sub-TLV Types
IANA is requested to create a new registry titled "SD-WAN Extended
Port Sub-Sub-TLV Types" under the BGP Tunnel Encapsulation Group.
The registration policy is IETF Review [RFC8126].
Value Type Description Reference
----- ----------------------- -------------
0 Reserved This document
1 Underlay Network Type This document
2~255 Unassigned
7. References
7.1. Normative References
[MEF70.1] MEF, "SD-WAN Service Attributes and Service Framework",
November 2021, .
Dunbar, et al. Expires 5 March 2027 [Page 45]
Internet-Draft SD-WAN Edge Discovery September 2026
[MEF70.2] MEF, "SD-WAN Service Attributes and Service Framework",
October 2023, .
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006,
.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, DOI 10.17487/RFC4301,
December 2005, .
[RFC4360] Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
February 2006, .
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
.
[RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
"Multiprotocol Extensions for BGP-4", RFC 4760,
DOI 10.17487/RFC4760, January 2007,
.
[RFC7296] Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T.
Kivinen, "Internet Key Exchange Protocol Version 2
(IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, October
2014, .
[RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
Patel, "Revised Error Handling for BGP UPDATE Messages",
RFC 7606, DOI 10.17487/RFC7606, August 2015,
.
[RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for
Writing an IANA Considerations Section in RFCs", BCP 26,
RFC 8126, DOI 10.17487/RFC8126, June 2017,
.
Dunbar, et al. Expires 5 March 2027 [Page 46]
Internet-Draft SD-WAN Edge Discovery September 2026
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, .
[RFC8489] Petit-Huguenin, M., Salgueiro, G., Rosenberg, J., Wing,
D., Mahy, R., and P. Matthews, "Session Traversal
Utilities for NAT (STUN)", RFC 8489, DOI 10.17487/RFC8489,
February 2020, .
[RFC9012] Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
"The BGP Tunnel Encapsulation Attribute", RFC 9012,
DOI 10.17487/RFC9012, April 2021,
.
7.2. Informative References
[Net2Cloud]
L. Dunbar, A Malis, C. Jacquenet, M. Toy and K. Majumdar,
"Dynamic Networks to Hybrid Cloud DCs: Problem Statement
and Mitigation Practice", September 2023,
.
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis",
RFC 4272, DOI 10.17487/RFC4272, January 2006,
.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
2006, .
[RFC5114] Lepinski, M. and S. Kent, "Additional Diffie-Hellman
Groups for Use with IETF Standards", RFC 5114,
DOI 10.17487/RFC5114, January 2008,
.
[RFC5903] Fu, D. and J. Solinas, "Elliptic Curve Groups modulo a
Prime (ECP Groups) for IKE and IKEv2", RFC 5903,
DOI 10.17487/RFC5903, June 2010,
.
[SD-WAN-BGP-USAGE]
L. Dunbar, A Sajassi, J Drake, and B. Najem, "BGP Usage
for SD-WAN Overlay Networks", June 2026,
.
Dunbar, et al. Expires 5 March 2027 [Page 47]
Internet-Draft SD-WAN Edge Discovery September 2026
Appendix A. Acknowledgments
Acknowledgements to Wang Haibo, Shunwan Zhuang, Hao Weiguo, and
ShengCheng for implementation contribution. Many thanks to Yoav Nir,
Graham Bartlett, Jim Guichard, John Scudder, and Donald Eastlake for
their review and suggestions.
Contributors
Below is a list of other contributing authors:
* Gyan Mishra,
* Shunwan Zhuang,
* Sheng Cheng, and
* Donald Eastlake.
Authors' Addresses
Linda Dunbar
Futurewei
Dallas, TX,
United States of America
Email: ldunbar@futurewei.com
Susan Hares
Huawei
United States of America
Email: shares@ndzh.com
Kausik Majumdar
Upscale AI
California,
United States of America
Email: kmajumdar@upscaleai.com
Robert Raszuk
Arrcus
United States of America
Email: robert@raszuk.net
Dunbar, et al. Expires 5 March 2027 [Page 48]
Internet-Draft SD-WAN Edge Discovery September 2026
Venkit Kasiviswanathan
Arista
United States of America
Email: venkit@arista.com
Dunbar, et al. Expires 5 March 2027 [Page 49]