PLAT IPv4 Payload Translation via PCP Prefix Management

Resolve Bottlenecks,
Find Innovative SolutionsGenerate Solutions

Solution Overview

Problem

Current 464XLAT architecture struggles to translate private IPv4 addresses in the payload of packets across IPv6 networks, leading to incomplete address translation and scalability issues due to manual configuration of CLAT prefixes, especially in large ISP networks.

Innovation Solution

Implementing a network device with a PLAT that uses Port Control Protocol (PCP) requests to automatically obtain and manage CLAT prefixes, enabling translation of private IPv4 addresses to public IPv4 addresses within packet payloads, and vice versa, through a NAT mapping table for efficient address conversion.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If manual configuration of CLAT prefixes is used in 464XLAT architecture, then address translation can be performed, but scalability deteriorates in large ISP networks requiring manual configuration of millions of prefixes

Engineering Contradiction:

Improveaddress translation capabilityVSAvoidmanual configuration complexity

Core Design Contradiction:

Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system enables self-service by allowing the network device to automatically obtain CLAT prefixes through PCP requests without manual configuration. The PLAT on the network device autonomously manages prefix assignment and updates the NAT mapping table, eliminating the need for administrators to manually configure millions of prefixes in large ISP networks.

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The solution implements preliminary action by pre-obtaining CLAT prefixes through PCP requests before actual address translation is needed. The network device proactively manages prefix allocation and stores mappings in advance, enabling rapid address translation when packets arrive without requiring manual setup for each translation task.

Inventive Principle:

Principle #10Preliminary action

2Reliability

If CLAT prefix manual configuration is implemented, then address translation works for small networks, but processing efficiency deteriorates due to the need to manage millions of prefixes in large ISP networks

Engineering Contradiction:

Improveaddress translation reliabilityVSAvoidprefix management efficiency

Core Design Contradiction:

ReliabilityVSProductivity

Solution Approach 1:

Inventive Principle:

Principle #25Self-service

Solution Approach 2:

The solution implements feedback through the PCP (Port Control Protocol) mechanism, where the network device sends requests to obtain CLAT prefixes and receives automated responses with assigned prefixes. This feedback loop enables dynamic prefix allocation based on actual network conditions and translation needs, improving efficiency over static manual configuration.

Inventive Principle:

Principle #23Feedback

3Adaptability or versatility

If 464XLAT architecture is used for IPv4 over IPv6 translation, then limited IPv4 connectivity is achieved, but translation completeness deteriorates when ALG is involved and private IPv4 addresses in payload cannot be translated

Engineering Contradiction:

ImproveIPv4 connectivity over IPv6VSAvoidaddress translation completeness

Core Design Contradiction:

Adaptability or versatilityVSManufacturing precision

Solution Approach 1:

The solution applies segmentation by separating the translation of IP addresses in packet headers from those in payloads. The NAT mapping table specifically tracks private IPv4 addresses embedded in payload data separately from standard header translation, enabling independent management and translation of each segment with appropriate handling for ALG-involved applications.

Inventive Principle:

Principle #1Segmentation

Solution Approach 2:

The invention introduces an intermediary mechanism through the NAT mapping table that mediates between the CLAT prefix translation and the actual private IPv4 addresses in payloads. This intermediary structure allows the system to track and translate payload addresses that would otherwise be inaccessible to standard stateless translation, completing the translation process even when ALG is involved.

Inventive Principle:

Principle #24Intermediary (Mediator)

Data Source

PatentEP3843365B1Translation between a first version of internet protocol and a second version of internet protocol when an application layer gateway (ALG) is involved

Publication Date: 2023.08.09 JUNIPER NETWORKS INC

Figure 1A
Figure 1B
Figure 1C

AI summary

A device may receive, from a first device, a port control protocol (PCP) request that includes a customer side translator (CLAT) prefix and one or more private internet protocol version X (IPvX) addresses. The PCP request may be received via an internet protocol version Y (IPvY) network. The device may store the CLAT prefix and the one or more private IPvX addresses using a data structure. The device may receive a packet that includes a private IPvX of the one or more private IPvX addresses and a private IPvY address that includes the CLAT prefix and a second instance of the private IPvX address. The device may use an application layer gateway (ALG). The device may translate the private IPvX address to a public IPvX address using the CLAT prefix. The device may provide the packet that includes the public IPvX address to a second device that supports IPvX.