SD-WAN Edge and Underlay Tunnel Discovery Using BGP

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

where:¶

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

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

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

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

• 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                           ~
 |                                                               |
 +---------------------------------------------------------------+

¶

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

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

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

• 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:¶

 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                   ~
|                                                               |
+---------------------------------------------------------------+

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

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

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

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

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¶

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

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):¶

    • If set to 0, the Local IP Address field contains a 4-octet IPv4 address.¶

    • If set to 1, the Local IP Address field contains a 16-octet IPv6 address.¶

  • O bit (Outer address scheme):¶

    • If set to 0, the Public IP Address field contains a 4-octet IPv4 address.¶

    • 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;¶

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

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

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

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

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

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

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

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

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

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

    • 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)¶

    • type: ENCR¶

    • Transform ID: 1¶

    • Tranform attributes = trans 1 [from RFC7296]¶

  • 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 198.51.100.10.¶

C-PE2 needs to advertise the following attributes for establishing the IPsec SA:¶

Next Hop:

192.0.2.1¶

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