VMware SD-WAN supports IPv6 addresses to configure the Edge Interfaces and Edge WAN Overlay settings.

The VCMP tunnel can be setup in the following environments: IPv4 only, IPv6 only, and dual stack.

Mixed Environment

An IPv4 only Interface can establish overlay only with either IPv4 or dual stack regardless of the overlay initiator and the preference value is ignored. The same rule applies to IPv6 only Interface as well. You cannot establish overlay between an IPv4 only and IPv6 only Interfaces.

In the above example, the Edge B1 has dual stack Interface. The Edge B1 can build IPv4 VCMP to the IPv4 only Interface on Edge B2 (unpreferred tunnel) and IPv6 VCMP to the IPv6 only Interface on Edge B3 (preferred tunnel) .

Dual Stack Environment

When all the Edges and Gateways are on dual stack, the tunnel preference is selected as follows:

  • Edge to Gateway – The initiator, Edge, always chooses the tunnel type based on the tunnel preference.
  • Edge to Hub – The initiator, Spoke Edge, always chooses the tunnel type based on the tunnel preference.
  • Dynamic Branch to Branch – When there is a mismatch in the tunnel preference, the connection uses IPv4 addresses to ensure consistent and predictable behavior.

For Edge to Edge connections, the preference is chosen as follows:

  • When the Interfaces of Edge peers are set with same preference, the preferred address type is used.
  • When the Interfaces of Edge peers are set with different preferences, then the preference of the initiator is used.
Note: When both the ends are on dual stack, with IPv4 as the preference and the overlay established with IPv4, the IPv6 overlay will not be established.

In the above Illustration, all the Edges are on dual stack with the following preferences:

  • Edge B1: IPv6
  • Edge B2: IPv6
  • Edge B3: IPv4

In the above example, a dynamic Edge to Edge tunnel is built over IPv4 between the Edges B2 and B3, regardless of the site that initiates the connection.

Impact of IPv6 Tunnel on MTU

When a branch has at least one IPv6 tunnel, DMPO uses this tunnel seamlessly along with other IPv4 tunnels. The packets for any specific flow can take any tunnel, IPv4 or IPv6, based on the real time health of the tunnel. An example for specific flow is path selection score for load balanced traffic. In such cases, the increased size for IPv6 header (additional 20 bytes) should be taken into account and as a result, the effective path MTU will be less by 20 bytes. In addition, this reduced effective MTU will be propagated to the other remote branches through Gateway so that the incoming routes into this local branch from other remote branches reflect the reduced MTU.

Limitations of IPv6 Address Configuration
  • SD-WAN Edge does not support configuring private overlay on one address family and public overlay on the other address family in the same routed Interface. If configured, the SD-WAN Edge would initiate the tunnel using the preferred address family configured on the routed Interface.
  • When there are multiple sub Interfaces available, the Route Advertisement MTU is not updated properly in sub Interface. The sub Interfaces inherit the MTU value from the Parent Interface. The MTU values received on sub interfaces are ignored and only the parent interface MTU is honored. When an Edge has multiple sub Interfaces, you must disable the MTU option in the Route Advertisement of the peer Router.
  • If all the WAN Interfaces are migrated to IPv6 only, the Edge loses its direct path to Orchestrator communication as fallback, as the Orchestrator does not support IPv6 communication from an Edge. In this environment, the Orchestrator services require at least one routed interface with IPv4 address and a default Gateway to forward the Orchestrator communication through multi-path routes.
  • The tunnel preference change can be disruptive for the PMTU overhead. When there is a change in the configuration to setup all Interfaces with IPv4 tunnel preference, the Edge to Edge or Hub to Spoke tunnels may be torn down and re-established to use the IPv4 overhead to ensure that the tunnel bandwidth is used optimally.
  • In an Interface with different IP links, the bandwidth measured by the preferred tunnel or link is inherited by other links. Whenever the tunnel preference is changed for a link from IPv6 to IPv4 or vice versa, the link bandwidth is not measured again.
  • When there is a change in the tunnel address or change in the preference of the tunnel from IPv6 to IPv4 address or vice versa, the existing flows are dropped in a Hub or Spoke. You should flush the flows in the Hub or Spoke to recover the bi-directional traffic.
Note: When Edge sends Duplicate Address Detection packet, Nonce option is sent in addition. However, this does not affect the functionality of the Edge.

To configure IPv6 addresses, see: