Bidirectional Cloud Routing with IPv6-Encoded Private-IP VNet Addresses
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing cloud computing platforms face challenges in facilitating bidirectional communications between virtual networks (VNets) with overlapping private IP addresses, leading to inefficiencies such as increased overhead, resource waste, and latency due to the use of service-controlled jumpbox VMs or customer-side configurations.
Innovation Solution
A cloud compute platform employs platform-level assignment of unique IPv6 addresses to VMs with private IPv4 addresses and stateful address translation, enabling service-initiated communications without the need for jumpbox VMs, by encoding VNet identifiers and IPv4 addresses within IPv6 addresses.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If service-controlled jumpbox VMs are used to facilitate communication between VNets with overlapping private IP addresses, then bidirectional communication is enabled, but resource consumption and system overhead increase
Solution Approach 1:
The patent extracts the routing logic from customer-managed jumpbox VMs and relocates it to the cloud provider's platform routing components. This eliminates the need for customer VMs to perform routing functions, reducing resource consumption while maintaining bidirectional communication capability between VNets with overlapping private IP addresses.
Solution Approach 2:
The patent introduces platform routing components as an intermediary between customer VNets and multi-tenant services. These components handle the complex routing and address translation operations, enabling communication between VNets with overlapping private IP addresses without requiring customer-managed jumpbox VMs.
2Reliability
If jumpbox VMs are deployed within customer VNets to enable service-initiated communications, then bidirectional communication is achieved, but latency increases due to additional routing hops
Solution Approach 1:
The patent removes the jumpbox VM intermediary from the communication path and replaces it with platform routing components that operate at the network infrastructure level. This eliminates additional routing hops and reduces communication latency while maintaining service-initiated communication capability.
Solution Approach 2:
The patent transitions from application-layer routing (using jumpbox VMs) to network-layer routing (using platform routing components). This dimensional shift in the routing architecture reduces the number of processing steps and decreases communication latency.
3Ease of operation
If customer-side configurations are used to enable communication with multi-tenant services, then communication is facilitated, but device complexity and configuration overhead increase
Solution Approach 1:
The patent implements self-service routing where the platform automatically manages address translation and routing configurations. The system automatically extracts VNet identifiers from IPv6 addresses and performs address translation without requiring customer configuration, reducing both configuration complexity and operational overhead.
Solution Approach 2:
The patent creates a universal platform routing component that handles multiple functions: routing decisions, address translation, and VNet identification. This multi-functional approach simplifies the overall system architecture and reduces configuration complexity compared to customer-specific jumpbox VM configurations.
4Ease of operation
If public IP addresses are assigned to customer VMs to communicate with multi-tenant services, then communication is enabled, but cost and overhead increase
Solution Approach 1:
The patent changes the IP address parameter from public IPv4 addresses to private IPv4 addresses embedded within IPv6 addresses. This allows customers to use private IP addresses for communication with multi-tenant services, reducing the need for public IP address allocation while maintaining communication capability.
Solution Approach 2:
The patent embeds private IPv4 addresses and VNet identifiers within IPv6 addresses, creating a nested address structure. This allows the system to maintain unique address identification while using private IP address spaces, reducing the consumption of public IP address resources.
Data Source
Figure 1
Figure 2A
Figure 2B
AI summary
A disclosed method facilitates bidirectional traffic flows between a multi-tenant service and endpoints with private customer internet protocol (IP) addresses. The method provides for receiving a data packet having a data packet header identifying a first IPv6 address as a destination. The first IPv6 address embeds a first IPv4 address and a virtual network (VNet) identifier uniquely identifying a VNet of a cloud compute platform. The method further provides for routing the data packet to a host node within the cloud compute platform that hosts a virtual machine (VM) within the VNet identified by the VNet identifier and assigned to the first IPv4 address.