BGP UPDATE for SD-WAN Edge Discovery

The BGP mechanisms defined in this document serve two functions: A BGP speaker 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. A BGP speaker advertises SD-WAN NLRI for IPv4/IPv6 (AFI/SAFI 1/74 or 2/74) with the NEXT_HOP attribute set to the local address of the advertising speaker, and includes a BGP Tunnel Encapsulation Attribute with a SD-WAN Hybrid Tunnel TLV. The SD-WAN NLRI identifies the port (or ports) that an underlay tunnel (identified by SD-WAN Node ID) within the logical SD-WAN Hybrid Tunnel (identified by Tunnel Egress End point) for which the BGP speaker is advertising encapsulation or IPsec SA related information via the SD-WAN Hybrid Tunnel Encapsulation Attribute. The SD-WAN Hybrid Tunnel Encapsulation Attribute contains IPsec SA and, optionally, NAT-related information. 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.

SD-WAN Hybrid Tunnel 25 (IANA assigned) 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. 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. The SD-WAN encoding uses the Encapsulation Extended Community defined in 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. 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 ), 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. If a Tunnel Egress End Point is not included in SD-WAN Hybrid Tunnel TLV, it is treated as if a Tunnel Egress End Point SubTLV is included with an address family identifer of 0. Table 1 summarizes this Sub-TLV support in a tabular format. Summary table

The validation procedure for the SD-WAN Hybrid tunnel TLV has the following steps 1) Validate tunnel TLV encoding and Sub-TLV encoding (per [RFC9012] and sections 2.2 and 2.3 of this draft) 2) Check that Sub-TLVs are valid for NLRI type in route (see above summarized in Table 1) and ignore invalid Sub-TLVs (per ) 3) Validate that the tunnel egress endpoint is a reachable IP address based on the BGP next-hop resolution rules. 4) Check if both the Color Sub-TLV and Extended Community for Color exist, if so prefer the Extended Community for Color. After the SD-WAN Hybrid Tunnel TLV has been validated, the SD-WAN Peer processes based on the NLRI as (underlay route or client route) as described in sections 2.4 and 2.5. Prior to installing a route with a SD-WAN tunnel as an active route, the BGP peer installing the route MUST also validate that the SD-WAN tunnel and underlay links are active.

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 using the loopback address of the C-PE. 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.

The Edge BGP Peer using BGP SD-WAN discovery sends the SD-WAN NLRI with a Tunnel Encapsulation Tunnel attribute with a SD-WAN Hybrid tunnel TLV to advertise the detailed properties associated with the public facing WAN ports and IPsec tunnels. The Edge BGP Peer sends this information to its designated RR via a secure transport connection. Each BGP UPDATE message with a SD-WAN Underlay NLRI MUST contains a Tunnel Encapsulation Attribute with a SD-WAN Hybrid Tunnel TLV. If an SD-WAN Underlay NLRI is received without a Tunnel Encapsulation Attribute with a SD-WAN Hybrid tunnel TLV, the NLRI is treated as "Treat-as-withdraw". 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 Nonce, IPsec Public Key, IPsec SA Proposal, and Simplified IPsec SA.

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 the SD-WAN tunnels terminated at the edge node. This is a "typed" NLRI (similar to other "typed" NLRIs as described in [RFC7606]). The format is shown in figure 2.

where: A 2-octet value that defines the encoding of the reminder of the SD-WAN the NLRI. 2 octets indicating the length of the value field in octets. This document defines the following SD-WAN Route type: 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:

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, and the NLRI MUST be treated as malformed and discarded. SD-WAN edge node Port identifier, which is locally significant. If the SD-WAN NLRI applies to multiple WAN ports, this field is zero. identifies a group of Hybrid SD-WAN tunnels that may 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. 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.

Upon receiving an SD-WAN NLRI, the following validation steps are performed: The Route Type field MUST be equal to 1. Any other value is not supported and the NLRI MUST be ignored, but distributed to other BGP peers. 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 NLRI malformed, and the NLRI MUST be discarded. 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.

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.

The IPsec SA Property Sub-TLVs defined in this section are used to signal IPsec SA parameters for SD-WAN Hybrid Tunnels as defined in this document. 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 . 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. This mechanism enables rapid distribution of new keys without requiring separate key negotiation protocols.

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, thereby significantly reducing the size of BGP UPDATE messages and allowing pairwise IPsec rekeying to proceed independently for each SA. IPsec SA ID 64 (IANA assigned)

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 SHOULD be equal to 2 + 4 *(number of IPsec SA Identifier fields). Reserved: The Reserved field SHOULD be set to zero and ignored upon receipt. Received values MUST be propagated without change. 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. If the length value is invalid, (that is 2+ 4*number of IPsec SA IDs), then the IPsec SA ID SubTLV is Malformed. Sub-TLV Error handling for Malformed Sub-TLVs adheres to [RFC9012].

The IPsec SA Rekey Counter Sub-TLV provides the rekey counter for a security association (identified by IPsec SA Identifier). IPsec SA Rekey Counter 67 (IANA assigned)

where: IP SA-Rekey Counter (8 bits): 67 (IANA assigned) length (8 bits): Specifies the total length in octets of the value field of the SubTLV. The total length is variable with the value equal to 18 plus Nonce Length. Reserved: Reserved for future use. The Reserved field MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change. ID Length (8 bits): indicates the length in octets of IPsec SA Identifer. This length SHOULD be 4 octets. Nonce Length (16 bits): indicates the length, in octets, of the Nonce Data. The value MUST be a non-zero multiple of 4 (i.e., the Nonce Data length MUST be a multiple of 32 bits)[RFC7296]. I Flag: When set to 1, the I-flag indicates that the communication being established is new. When set to 0, it signals that the communication is a continuation of an existing session. Flags (7 bits): Reserved for future use. These bits MUST be set to zero and MUST be ignored upon receipt. Received values MUST be propagated without change. Rekey Counter (64 bits): the number of key updates or rekeys that have occurred. Each time a key is rotated or replaced, the Rekey Counter is incremented. IPsec SA Identifier: Identifies the IPsec SA for a specific IPsec SA terminated at the SD-WAN edge node. The length of this field is specified in ID Length. Nonce Data: a random or pseudo-random number for preventing replay attacks. The IPsec SA Rekey Counter Sub-TLV is considered malformed under any of the following conditions: The total Sub-TLV Length is less than the sum of ID Length, Nonce Length, and 4 octets for the Rekey Counter. The Nonce Length field is zero or not a multiple of 4. Malformed Sub-TLVs are handled according to [RFC9012]. Contextual Note 1: The ID Length is set to 4 octets, but ID in [draft-ietf-bess-secure-evpn-02] under development in the IETF is defined as " Originator ID + (Tenant ID) + (Subnet ID) + (Tenant Address) in bytes. To provide the future ability to allow the Secure EVPN functions to use this IPSec SA Rekey Counter Sub-TL the length has been defined as "SHOULD".

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:

where: IPSec-PublicKey (8 bits): Type value for Sub-TLV is 68 (IANA assigned). length (8 bits): Specifies the total length in octets of SubTLV value field. The total length is variable with the length being 10 + the Key Exchange Data length. Diffie-Hellman Group Num (16-bits): identifies the Diffie-Hellman group used to compute the Key Exchange Data. Details on Diffie-Hellman group numbers can be found in Appendix B of IKEv2 [RFC7296] and [RFC5114]. The Key Exchange data: This refers to a copy of the sender's Diffie-Hellman public value. The length of the Diffie-Hellman public value is defined for MODP groups in [RFC7296] and for ECP groups in [RFC5903]. 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].

The IPsec SA Proposal Sub-TLV is used to advertise a set of cryptographic parameters that define the proposal for establishing an IPsec SA. A proposal consists of one or more transform types, where each transform specifies a particular cryptographic function (such as encryption or integrity) and the corresponding algorithm to be used. This structure follows the same model as IKEv2 Proposals defined in [RFC7296]. IPsec SA Proposal - Indicates IPsec Transform Attributes 69 (IANA assigned) 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:

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. These bits are ignored upon receipt and set to zero when transmitted. Received values MUST be propagated without change. 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. 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. Multiple IPsec SA Proposal Sub-TLVs MAY be included to describe multiple transform types for the same SA proposal. Collectively, these Sub-TLVs define the full proposal for an IPsec SA between SD-WAN edge nodes.

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).

The Simplified IPsec SA Sub-TLV provides a compact way to signal pre-configured IPsec SA parameters for deployments where full transform negotiation (e.g., via IKEv2) is not supported or not necessary. In such deployments, SD-WAN edge nodes are provisioned (e.g., via SD-WAN controller or management system) with a common set of agreed security profiles, including allowed transforms and algorithms. This Sub-TLV signals which profile entry is to be used for a given SA instance. Simplified IPsec SA 70 (IANA assigned)

where: Simplified IPsec SA Sub-TLV type (70)[IANA assigned] the length of Sub-TLV in octets (based on key length). Length is variable, and calculated by 17 + key1 length + key2 length + nonce length. Reserved for future use. These bits SHOULD be set to zero on transmission and MUST be ignored on receipt. Received values MUST be propagated without change. Transform = 1 means AH, Transform = 2 means ESP, or Transform = 3 means AH+ESP. All other transform values are invalid. 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. Specifies the AH authentication algorithm to be used. The values are defined in [RFC4835] and its updates (e.g., [RFC8221]). While an SD-WAN edge node may be capable of supporting multiple AH algorithms, this field carries only a single algorithm value for the specific SA instance. The selection of which algorithms are supported across peers is determined via SD-WAN controller provisioning or management policy. No in-band negotiation of multiple algorithms is performed using this field. Specifies the ESP encryption algorithm, as defined in [RFC4835], [RFC8221], and their updates. Like AH Algorithm, only a single algorithm value is carried per SA instance, with acceptable algorithms coordinated by provisioning or policy. indicates the count for rekeying. indicates the IPsec public key 1 length. The length has a valid range of 32 octets to 512 octets [RFC8247] IPsec public key 1 indicates the IPsec public key 2 length. The length has a valid range of 32 octets to 512 octets [RFC8247] IPsec public key 2 indicates the Nonce key length. Per [RFC7296], the minimum length for nonce is 16 octets. [RFC7296] doesn't specify the maximum length for nonce. Therefore, the maxmimum length for nonce MUST be small enough so that the entire length of the BGP UPDATE is less than the BGP UPDATE maximum. IPsec Nonce specifying the security association (SA) life span in seconds. 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 .

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], which require peers to dynamically discover NAT properties during tunnel setup, the BGP-controlled SD-WAN architecture enables each SD-WAN edge node to proactively advertise its NAT properties to all peers through BGP signaling. This approach simplifies NAT traversal in large-scale SD-WAN deployments where each edge node may need to establish tunnels with many peers. Extended Port Attribute 65 (IANA assigned) The encoding is shown in the figure below:

where: Length: the length of the value field in octets excluding the Type and the Length fields. If IPv4, the length is 32 (8 header, 32 address, 8 for 1 Sub-Sub-TLV). If IPv6, the length is 64 (8 header, 48 addresses, 8 for 1 subSubTLV). 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): If set to 0, indicate the inner (private) address is IPv4. If set to 1, indicates the inner address is IPv6. O bit (Outer address scheme): If set to 0, indicate the inner (private) address is IPv4. If set to 1, indicates the inner address is IPv6. 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 Nonce, 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; Encap-Type=2: VxLAN; Notes: Those are the only two valid values for this field. The Encap-Type identifies the encapsulation protocol used within the IPsec payload when IPsec SA Sub-TLVs (IPsec SA ID, IPsec SA Nonce, 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. If the Sub-TLV Length field is 32, the Local IP is a 32 bit IPv4 address. If the Sub-TLV Length field is 64, the Local IP is a 64 bit IPv6 address. This MUST be a valid IP address. Local Port: used by Remote SD-WAN edge node for establishing IPsec to this specific port. Valid values: 0x00 - 0xFFFFFFFF. Public IP: The IP address after the NAT. If NAT is not used, this field is set to all-zeros. If not, this is a valid IP addres. If the Sub-TLV Length field is 32, the Local IP is a 32 bit IPv4 address. If the Sub-TLV Length field is 64, the Local IP is a 64 bit IPv6 address. Public Port: The Port after the NAT. If NAT is not used, this field is set to all-zeros. 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. 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 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.

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. 66 (IANA Assigned). The encoding is shown in the figure below:

Where: Underlay Network Type (66 assigned by IANA) always 6 bytes 2-octet of reserved bits. It SHOULD be set to zero on transmission and MUST be ignored on receipt. 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. 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 Values outside the range 1-4 are invalid and render the Sub-TLV malformed. 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. Underlay Network Type Sub-Sub-TLV is a MALFORMED Sub-Sub-TLV if the fields do not fit the limits specified above. If a MALFORMED Sub-Sub-TLV is contained in the Extended Port Attribute Sub-TLV, then the Extended Port Attribute Sub-TLV is MALFORMED. Per , a MALFORMED Sub-TLV is ignored.

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: 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. 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. Recall as stated earlier, if a Tunnel Egress Endpoint Sub-TLV does not exist, the SD-WAN Hybrid Tunnel processing treats it as a Tunnel Egress Endpoint Sub-TLV with AFI equal to zero. 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].

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.

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: If the SD-WAN Hybrid Tunnel TLV does not have a Tunnel Egress Endpoint SubTLV, the tunnel validation process treats it as if a Tunnel Egress SubTLV exists with an AFI of 0(Per [RFC9012], a Tunnel Egress SubTLV exists with an AFI of 0 uses the packet Next Hop as the tunnel endpoint). Also, per [RFC9012], MALFORMED Sub-TLVs are ignored and a Sub-TLV with an unknown type is ignored. The SD-WAN Hybrid Tunnel TLV only processes the first instance of a Sub-TLV except for the IPsec SA ID Sub-TLV. For the IPsec SA ID Sub-TLV, if the IPsec SA Identifiers are unique are multiple IPsec SA ID sub-TLVs are processed. If all the IPsec SA Identifies are not unique, the second IPsec SA ID Sub-TLV is ignored and not propagated 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. 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. Local policy is run to validate routes. The Next Hop MUST be be reachable via the tunnel.

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. 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.

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), the Route Target Extended Community [RFC4360] SHOULD be included. The Route Target value is interpreted as the VPN ID. The Route Target is especially necessary when the SD-WAN edge node serves multiple VPNs on its client-facing interfaces. If all client routes belong to a single VPN and the association is unambiguous, the Route Target MAY be omitted. For VPN-IPv4/VPN-IPv6 (AFI/SAFI = 1/128 or 2/128), the RD in the NLRI serves as the VPN ID.

In the data plane, SD-WAN traffic can traverse either an MPLS or IPsec segment within a SD-WAN Hybrid Tunnel. The method for conveying the VPN ID depends on the encapsulation: MPLS Segments: When the SD-WAN Hybrid Tunnel uses MPLS transport, the MPLS label stack is used to identify the VPN per [RFC8277]. Security is assumed to be provided by the MPLS transport. IPsec Segments: When traversing a public network with IPsec encryption: For GRE encapsulation within IPsec, the GRE Key field can carry the SD-WAN VPN ID; For VXLAN network virtualization overlays within IPsec, the VNI (Virtual Network Identifier) field is used to carry the VPN ID.

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 Node ID carried in the SD-WAN SAFI to correlate client routes whose NextHop address matches the SD-WAN Node ID. This allows the receiving node to associate each client route with the appropriate set of tunnel attributes advertised by the corresponding SD-WAN edge node.

The SD-WAN Hybrid NLRI MUST be accompanied by the Tunnel Encapsulation Attribute, and MUST NOT be accompanied by an Encapsulation Extended Community.

The procedure for processing underlay routes follows the following steps: 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. 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. 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 to ensure that the port information it contains is sufficient to support the establishment of a tunnel to the remote peer. If any Extended Port Attribute Sub-TLV is determined to be invalid, the entire SD-WAN Hybrid Tunnel TLV MUST be considered invalid. 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. The IP address specified in the Next Hop field MUST be reachable by the Tunnels.

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. 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 (2.2.2.2), Port-Local-ID (0), SD-WAN-Color (20), SD-WAN Node ID (2.2.2.2), and Port-Local-ID (0), SD-WAN-Color (30), SD-WAN Node ID (2.2.2.2). These indicate that node 2.2.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.

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.

The Error handling for SD-WAN VPN support has two components: error handling for Tunnel Encapsulation signaling (Encapsulation Extended Community and Tunnel Encapsulation Attribute) and the SD-WAN NLRI. An SD-WAN NLRI, a Tunnel Encapsulation attribute MUST always accompany the SD-WAN NLRI. The previous sections (2.4 and 2.5) provide the procedures for handling client routes and undelay routes.

The error handling for the tunnel encapsulation signaling (Encapsulation Extended Community and Tunnel Encapsulation Attribute) in this document follows the procedures specified in Section 13 of [RFC9012]. Unless otherwise stated, malformed or unrecognized Sub-TLVs MUST be handled as specified in [RFC9012]. This document defines new Sub-TLVs for Tunnel Type 25 (SD-WAN-Hybrid), but does not alter the validation behavior established in RFC 9012. For SD-WAN client routes with a Tunnel Encapsulation Attribute with a SD-WAN Hybrid Tunnel type TLV, the IPsec Sub-TLVs (IPsec SA ID, IPsec nonce, IPsec Public Key, IPsec Proposal, and Simplified IPsec SA) are meaningful, but MAY be rarely sent. Incorrect fields within any of these 5 TLVs. Per [RFC9012], a malformed sub-TLV is treated as an unrecognized sub-TLV. If multiple instances of the IPsec nonce, 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.

The SD-WAN NLRI [AFI 1/SAFI = 74] utilizes a route type field to describe the format of the NLRI. This specification only allows an NLRI with a type value of 1. An NLRI with a type of field of another value is ignored, but distributed to other peers. The implementation MAY log an error upon the reception of a type value outside of Route Type 1. Error handling for the SD-WAN NLRI also adheres to the BGP UPDATE error handling specified in [RFC7606]. Local configuration and policy MUST carefully constrain the SD-WAN-NLRI, tunnels, and IPsec security associations to create a "walled garden".

The SD-WAN NLRI (AFI=1/SAFI=74) MUST be paired with Tunnel Encapsulation attribute with a SD-WAN Hybrid tunnel TLV, If the SD-WAN NLRI exist in an BGP UPDATE without a Tunnel Encapsulation Attribute with a SD-WAN Hybrid tunnel TLV, the NLRI is considered malformed and Treat-as-withdraw approach (per RFC7606). The SD-WAN NLRI SHOULD not be paired with an Encapsulation Extended Community. If an SD-WAN NLRI is paried with an Encapsulation Extended Community rather than a Tunnel Encapsulation Attribute, the SD-WAN NLRI is considered malformed and the Treat-as-withdraw approach (per ) SHOULD be used.