NAT Gateway Bidirectional IPv4-IPv6 Routing via Token

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

The depletion of IPv4 addresses necessitates a transition to IPv6, but existing network address translation (NAT) technologies restrict devices behind NATs to only initiate outbound communications, preventing them from hosting servers or receiving incoming connections, and previous solutions like SIPNAT face ambiguities due to DNS server variations.

Innovation Solution

The method employs deep packet inspection and resource identifier association to enable bidirectional communication between IPv4 and IPv6 networks, allowing devices behind NATs to initiate and maintain connections without requiring static global network interfaces or dual-stack implementations, using flow management and DNS-based setups to disambiguate traffic and allocate resources.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Quantity of substance

If traditional NAT is used to conserve IPv4 addresses, then the number of available IPv4 addresses is extended, but devices behind NAT can only initiate outbound communications and cannot host servers or receive incoming connections

Engineering Contradiction:
Improvenumber of available IPv4 addressesVSAvoidbidirectional communication capability
Core Design Contradiction:
Quantity of substanceVSAdaptability or versatility

Solution Approach 1:

The system performs preliminary actions by establishing outbound connections from internal devices to external servers before incoming connections are needed. The internal device initiates an outbound connection to an external server, and the external server returns an incoming connection token that enables subsequent incoming connections to be properly routed to the internal device through the NAT gateway.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The external server acts as an intermediary that facilitates bidirectional communication between internal devices and external networks. The external server receives the outbound connection from the internal device, generates an incoming connection token, and uses this token to enable incoming connections to be properly directed to the internal device through the NAT gateway.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Adaptability or versatility

If SIPNAT is used to enable incoming connections, then bidirectional communication is possible, but ambiguities arise due to DNS server variations

Engineering Contradiction:
Improveincoming connection capabilityVSAvoidcommunication reliability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system implements feedback mechanisms where the external server responds to outbound connections by returning incoming connection tokens that contain routing information. This feedback loop ensures that the NAT gateway receives accurate routing information directly from the external server, eliminating ambiguities that would otherwise arise from DNS server variations.

Inventive Principle:
Principle #23Feedback

Solution Approach 2:

The system segments the communication process into distinct phases: outbound connection establishment, token generation by external server, and incoming connection routing. By separating these functions and using tokens as discrete routing identifiers, the system avoids the ambiguities associated with DNS-based approaches where multiple servers may provide conflicting information.

Inventive Principle:
Principle #1Segmentation

3Adaptability or versatility

If devices behind NAT host servers or receive incoming connections, then service hosting capability is enabled, but complex configurations like tunneling protocols or dual-stack implementations are required

Engineering Contradiction:
Improveservice hosting capabilityVSAvoidconfiguration complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system enables self-service by allowing internal devices to automatically initiate outbound connections and receive incoming connection tokens from external servers. The NAT gateway automatically processes these tokens and configures routing rules without requiring manual configuration of tunneling protocols or dual-stack implementations. The entire process is transparent to the internal device, which simply needs to initiate the outbound connection.

Inventive Principle:
Principle #25Self-service

4Reliability

If flow management and resource identifier association are used to disambiguate traffic, then reliable packet delivery is achieved, but deep packet inspection is required

Engineering Contradiction:
Improvepacket delivery reliabilityVSAvoidprocessing complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The system performs preliminary actions by inspecting and recording flow management information and resource identifiers from outbound traffic before incoming connections are established. The NAT gateway maintains records of these identifiers and uses them to disambiguate and properly route incoming connections, ensuring reliable packet delivery without requiring complex real-time analysis during incoming connection handling.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS8990424B2Network address translation based on recorded application state
Publication Date: 2015.03.24 WICHORUS LLC
  • US8990424B2 patent drawing
  • US8990424B2 patent drawing
  • US8990424B2 patent drawing

AI summary

A method and system for improved NAT operation enable efficient translation for packets destined for communication systems within a domain utilizing network addresses that are incompatible with source and destination addresses indicated in packets delivered from the global Internet. Since the addresses are not compatible with global Internet addresses, delivery cannot be accomplished except by some method of address translation. Traditional systems have not been constructed to enable such inbound translations, providing, instead, only communication outbound from the incompatibly addressed domain towards the global Internet. Embodiments may employ application-specific knowledge for peer-to-peer based applications, associated over time with specific destinations. Embodiments may further employ an application-specific state machine in the NAT function to trace the development of the application protocol so that the resource identifier can be observed.