IPv6 single stack IPv4 cross-network access gateway configuration method

Abstract

The application discloses a kind of IPv6 single stack IPv4 cross-network access gateway configuration method, including obtaining the traffic characteristics of each service, calculating IPv6 migration priority, each service is divided into at least two migration batches, and the switching of traffic to IPv6 single stack is executed in batches;During the switching process of each batch, gradually expand the effective range of NAT64 mapping prefix and adjust the AAAA record synthesis strategy of DNS64, the traffic corresponding to the batch is migrated from IPv4 forwarding path to IPv6-to-IPv4 translation forwarding path, and the session mapping table is updated synchronously;After each batch switching is completed, the service traffic state is monitored;When abnormal, the ongoing session state and port mapping relationship are extracted from the current session mapping table;Forwarding engine is rolled back to the state before switching, and the session state and port mapping relationship are injected into the forwarding engine after rollback. The present application is based on resource consumption batch migration, prefix linkage analysis is gradually expanded, session injection rollback when abnormal, IPv6 smooth evolution and service lossless are realized.

Description

Technical Field

[0001] This invention relates to the field of gateway technology, and in particular to a method for configuring a gateway for IPv6 single-stack IPv4 cross-network access. Background Technology

[0002] With the depletion of global IPv4 addresses, the IPv6 protocol has become the core of next-generation internet construction. However, due to the incompatibility between IPv4 and IPv6 addressing and routing, the transition to IPv6 will take a considerable amount of time. During this transition, ensuring that existing IPv4 applications and services can continue to be used in an IPv6 network environment has become a key technical issue that the industry is continuously researching. Currently, the technical solutions for enabling single-stack IPv6 networks to access IPv4 resources mainly fall into the following three categories:

[0003] One approach is tunneling technology, which enables interoperability by carrying IPv4 traffic over an IPv6 network. Representative solutions include 4over6 tunneling and DS-Lite. The 4over6 tunneling solution establishes a tunnel using a CPE as the tunnel initiation point, allowing IPv4 terminals to access IPv4 resources across IPv6 networks. The DS-Lite solution combines an IPv6 encapsulation of IPv4 tunneling mechanism with IPv4 address translation. However, tunneling technology requires large-scale modifications to traditional NAT devices, resulting in complex forwarding processes and high NAT entry maintenance overhead. Furthermore, tunnel encapsulation introduces additional protocol overhead, and all traffic must pass through a carrier-grade gateway, increasing network latency.

[0004] Secondly, translation technology enables interoperability by performing IPv6 and IPv4 address and protocol conversion at the gateway. Representative solutions include NAT64 / DNS64. The DNS64 server synthesizes IPv4 addresses into IPv6 addresses and returns them to the IPv6 client, while the NAT64 gateway performs address translation and packet conversion. However, NAT64 requires maintaining state information for each connection, which can easily become a performance bottleneck in high-concurrency scenarios; the stateful conversion method increases operational complexity; and support for some application layer protocols, such as FTP, is still incomplete.

[0005] Thirdly, there is dual-stack technology, which enables network devices to support both IPv4 and IPv6 protocol stacks simultaneously, with the two protocols running independently. Its drawback is the need to maintain two sets of network configurations, two sets of routing tables, and two sets of security policies, leading to hardware resource redundancy and a significant increase in maintenance costs.

[0006] In summary, existing technologies primarily focus on "how to achieve interoperability between IPv6 single-stack and IPv4 networks," i.e., solving the "can it work?" problem, but fail to address the "how to smoothly evolve from a dual-stack network to an IPv6 single-stack network" problem. In actual deployments, most enterprises currently operate a dual-stack architecture, and converting it to IPv6 single-stack is a high-risk operation. Once the IPv4 protocol stack is removed, all existing services relying on IPv4 may be immediately interrupted, and rollback is extremely difficult. Therefore, there is an urgent need to provide a configuration method for an IPv6 single-stack IPv4 cross-network access gateway that supports phased, controllable, and smooth migration. Summary of the Invention

[0007] To address at least one of the aforementioned technical problems, this invention provides a method for configuring an IPv6 single-stack IPv4 cross-network access gateway.

[0008] In a first aspect, the present invention provides a method for configuring an IPv6 single-stack IPv4 cross-network access gateway, the method comprising:

[0009] Obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources of each service, and divide each service into at least two migration batches according to the migration priority.

[0010] The traffic is switched to IPv6 single stack in batches according to the migration priority from low to high. During the switching process of each batch, the effective scope of NAT64 mapping prefix is ​​gradually expanded and the DNS64 AAAA record synthesis strategy is adjusted. The service traffic of the corresponding batch is migrated from IPv4 forwarding path to IPv6-to-IPv4 translated forwarding path, and the session mapping table is updated synchronously.

[0011] After each batch switch is completed, monitor the service traffic status; when the service traffic status is detected to be abnormal, extract the ongoing session status and port mapping relationship from the current session mapping table; roll back the forwarding engine to the state before the switch, and inject the session status and port mapping relationship into the rolled-back forwarding engine.

[0012] Preferably, the step of calculating the IPv6 migration priority of each service based on the degree of consumption of NAT64 session resources and DNS64 resolution resources by each service includes:

[0013] Obtain traffic 5-tuple information and DNS64 synthesized record logs for each service within a preset statistical period;

[0014] Based on the traffic quintuple information, identify the address and port translation type triggered by each service traffic in the NAT64 translation engine; if the translation type is stateful translation, count the number of dynamic session entries occupied, and calculate the first resource utilization rate of the number of dynamic session entries relative to the total capacity of the gateway's underlying TCAM.

[0015] Based on the DNS64 synthetic record log, extract the lifetime distribution characteristics of the synthetic AAAA records corresponding to each service, calculate the number of gateway cache refreshes within a preset time period, and determine the second resource utilization rate based on the number of refreshes;

[0016] Based on the first resource utilization rate and the second resource utilization rate, a migration priority score is constructed for each business; among them, the weight coefficient of the first resource utilization rate is greater than the weight coefficient of the second resource utilization rate.

[0017] Preferably, the process of constructing migration priority scores for each service includes:

[0018] Obtain the hardware water level warning threshold of the gateway's underlying TCAM, and determine whether the first resource utilization rate of each service exceeds the hardware water level warning threshold;

[0019] If it does not exceed the limit, then the product of the first resource utilization rate and the first linear coefficient, and the product of the second resource utilization rate and the second linear coefficient are added together to obtain the basic priority score;

[0020] If it exceeds the limit, calculate the overflow ratio of the first resource utilization rate exceeding the hardware water level warning threshold. Using a preset base as the base and the product of the overflow ratio and the preset exponential amplification factor as the exponent, calculate the hardware overload penalty factor.

[0021] Multiply the hardware overload penalty factor by the base priority score to obtain the final migration priority score for each service.

[0022] Preferably, the step of constructing migration priority scores for each service further includes:

[0023] If the transition type is stateless transition, then detect the proportion of packets in each service traffic whose packet length exceeds the IPv6 minimum MTU threshold;

[0024] Based on the message ratio, the number of times each service triggers IPv6 fragmentation reassembly and IPv4 fragmentation generation within a preset statistical period is counted.

[0025] The third resource utilization rate of each service is calculated based on the number of processing times and the upper limit of the gateway CPU sharding processing queue capacity; the third resource utilization rate is multiplied by the preset CPU calculation weight coefficient to obtain the correction factor.

[0026] Update the final migration priority score for each business using the correction factor.

[0027] Preferably, the step of dividing each service into at least two migration batches according to migration priority includes:

[0028] Obtain the IPv6 migration priority score for each service;

[0029] The services are sorted in order of IPv6 migration priority score from low to high.

[0030] Calculate the priority score difference between adjacent services sequentially;

[0031] The positions between adjacent services whose priority score difference is greater than a preset threshold are determined as batch split points;

[0032] Each business is divided into several migration batches based on the batch split points.

[0033] Preferably, the step of gradually expanding the scope of the NAT64 mapping prefix and adjusting the DNS64 AAAA record synthesis strategy to migrate the corresponding batch of service traffic from the IPv4 forwarding path to the IPv6-to-IPv4 translation forwarding path includes:

[0034] Get the set of target domain names corresponding to each business in the current migration batch;

[0035] Generate a DNS64 composite whitelist for the current batch based on the target domain name set;

[0036] The DNS64 synthesized whitelist is sent to the DNS64 server, which is instructed to perform AAAA record synthesis operations on the domains included in the whitelist. The IPv6 prefix used in the AAAA record synthesis operation is the NAT64 mapping prefix.

[0037] Preferably, the synchronous update of the session mapping table includes:

[0038] When adding the address prefix of the current batch to the NAT64 prefix policy routing table, the mapping entries corresponding to each service in the current batch are inserted into the session mapping table. The mapping entries contain the IPv6 source address of the service, the converted IPv4 source address, and the NAT64 mapping prefix identifier used.

[0039] Whenever a subsequent batch is switched, a corresponding mapping entry is added to the session mapping table based on the address prefix of the new batch, while the mapping entries corresponding to the switched batches remain unchanged.

[0040] Secondly, the present invention also provides an IPv6 single-stack IPv4 cross-network access gateway configuration system, the system comprising:

[0041] The batch division unit is used to obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources of each service, and divide each service into at least two migration batches according to the migration priority.

[0042] The segmented migration unit is used to perform the switchover of traffic to IPv6 single stack in batches according to the migration priority from low to high. During the switchover of each batch, the effective scope of NAT64 mapping prefix is ​​gradually expanded and the DNS64 AAAA record synthesis strategy is adjusted to migrate the service traffic of the corresponding batch from the IPv4 forwarding path to the IPv6-to-IPv4 translated forwarding path, and the session mapping table is updated synchronously.

[0043] The traffic monitoring unit is used to monitor the service traffic status after each batch switch is completed. When the service traffic status is detected to be abnormal, it extracts the ongoing session status and port mapping relationship from the current session mapping table, rolls back the forwarding engine to the state before the switch, and injects the session status and port mapping relationship into the rolled-back forwarding engine.

[0044] Thirdly, the present invention also provides an electronic device including a processor and a memory, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor executes the computer instructions, the electronic device performs the method as described in the first aspect above and any possible implementation thereof.

[0045] Fourthly, the present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor of an electronic device, cause the processor to perform a method as described in the first aspect above and any possible implementation thereof.

[0046] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0047] 1) Based on the actual consumption of NAT64 session resources and DNS64 resolution resources by each service, a migration priority score is calculated. Services are then divided into multiple batches according to their scores, from low to high, prioritizing the migration of services with low resource consumption and low migration risk. Simultaneously, each batch is linked with the DNS64 synthesis whitelist and the NAT64 prefix policy routing table. Only during the DNS resolution phase are AAAA records synthesized for the domain names of the selected services, precisely directing the corresponding traffic to the IPv6-to-IPv4 translation and forwarding path. This design allows high-resource-consuming services to be migrated in later batches, avoiding instantaneous gateway overload caused by simultaneous switching. Furthermore, service-level traffic redirection replaces a full switch, significantly reducing the risk of large-scale network evolution.

[0048] 2) During each switchover, incrementally insert the corresponding mapping entries (including IPv6 source address, converted IPv4 source address, and NAT64 prefix identifier) ​​for each service in the current batch into the session mapping table. The mapping entries for batches that have already been switched remain unchanged. This incremental update mechanism ensures that when services from different batches share the same gateway, their respective session mapping relationships do not interfere with each other. Services that have completed migration earlier are not affected by subsequent batch switches, achieving long-term stability and seamless connection of cross-batch forwarding.

[0049] 3) After each batch of switchovers is completed, the service traffic status is continuously monitored. When an anomaly is detected, the ongoing session status and port mapping relationship are extracted from the current session mapping table. The forwarding engine is then rolled back to its pre-switchover state, and the extracted session status is injected into the rolled-back engine. This mechanism ensures that active sessions established after the rollback can be correctly identified and continue to be processed, avoiding the connection interruption and client reconnection issues in traditional solutions. This achieves lossless and rapid self-healing of services in abnormal switchover scenarios.

[0050] 4) When calculating priorities, a TCAM hardware water level warning threshold is introduced. When the first resource utilization rate of a service exceeds the threshold, the overflow ratio is calculated and a hardware overload penalty factor is generated to correct the priority, scheduling high-resource-consuming services for migration in later batches. Simultaneously, for stateless transition scenarios, the solution detects the proportion of excessively long packets, counts the number of IPv6 fragmentation reassembly and IPv4 fragmentation generation processes triggered by this, and calculates the third resource utilization rate based on the CPU fragmentation processing queue capacity, generating a correction factor to update the priority. This design balances the resource consumption of stateful entries and the computational resource consumption of stateless processes, ensuring the safe operation of both TCAM and CPU underlying hardware resources.

[0051] It should be understood that the above general description and the following detailed description are exemplary and explanatory only, and are not intended to limit this disclosure. Attached Figure Description

[0052] To more clearly illustrate the technical solutions in the embodiments of the present invention or the background art, the accompanying drawings used in the embodiments of the present invention or the background art will be described below.

[0053] Figure 1 A flowchart illustrating a method for configuring an IPv6 single-stack IPv4 cross-network access gateway according to an embodiment of the present invention;

[0054] Figure 2 This is a schematic diagram of the structure of an IPv6 single-stack IPv4 cross-network access gateway configuration system provided in an embodiment of the present invention. Detailed Implementation

[0055] To enable those skilled in the art to better understand the present invention, the technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0056] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of the invention. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0057] Existing IPv4 to IPv6 single-stack migration solutions often employ full handover or extensive migration based on network segments, lacking awareness of the actual resource consumption of each service and the ability to schedule differentiated services. This leads to the NAT64 gateway's TCAM entries and CPU fragmentation processing resources being prone to instantaneous overload during the migration process. Furthermore, the rollback mechanism in case of handover anomalies is often simplistic and crude, interrupting established sessions and making it difficult to guarantee service continuity. To address these issues, this invention collects traffic characteristics and DNS resolution logs for each service to quantify its occupancy of NAT64 session entries and DNS64 cache resources. Based on this, migration priorities are calculated and divided into multiple batches. The effective scope of NAT64 mapping prefixes is gradually expanded from low to high priority, and a DNS64 whitelist synthesis strategy is used to achieve precise traffic redirection at the service level. Simultaneously, the session mapping table is incrementally maintained to ensure cross-batch forwarding continuity. When anomalies are detected after a batch handover, the active session state and port mapping relationship are extracted from the session mapping table and injected into the rollback forwarding engine. This achieves smooth IPv6 evolution and lossless self-healing of services in case of handover anomalies while ensuring secure utilization of gateway resources.

[0058] Please see Figure 1 , Figure 1 This is a flowchart illustrating a method for configuring an IPv6 single-stack IPv4 cross-network access gateway according to an embodiment of the present invention. Figure 1 As shown, the method includes:

[0059] S10. Obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources by each service, and divide each service into at least two migration batches according to the migration priority.

[0060] The gateway controller collects five-tuple information and DNS64 synthetic record logs of traffic from each service within a preset statistical period (e.g., 24 hours). Based on the five-tuple information, it identifies the address and port translation types triggered by each service in the NAT64 translation engine: if it is a stateful translation, it counts the number of dynamic session entries used and calculates its first resource utilization rate relative to the total capacity of the gateway TCAM; if it is a stateless translation, it counts the number of fragment reassemblies and generation triggered by oversized packets (exceeding the IPv6 minimum MTU of 1280 bytes) and calculates the CPU resource utilization rate. Simultaneously, based on the DNS64 synthetic record logs, it extracts the TTL distribution characteristics of the synthetic AAAA records for each service and calculates the number of cache refreshes per unit time as the second resource utilization rate. Subsequently, it weights and sums the first resource utilization rate (weighted by a coefficient of 0.7) and the second resource utilization rate (weighted by a coefficient of 0.3), and introduces the TCAM hardware water level warning threshold as a penalty factor to calculate the final migration priority score for each service. After sorting each service according to its priority score from low to high, the difference between adjacent services is calculated in turn. The position where the difference is greater than the preset threshold is used as the dividing point to divide the service into at least two migration batches.

[0061] S20. Perform the switchover of traffic to IPv6 single stack in batches according to the migration priority from low to high. During the switchover process of each batch, gradually expand the effective scope of NAT64 mapping prefix and adjust the DNS64 AAAA record synthesis strategy to migrate the service traffic of the corresponding batch from the IPv4 forwarding path to the IPv6-to-IPv4 translation forwarding path, and update the session mapping table synchronously.

[0062] The switchover is performed in batches according to migration priority, from low to high. During the switchover, the gateway controller first obtains the target domain name set for each service in the current batch, generates a DNS64 composite whitelist based on this, and sends it to the DNS64 server. The DNS64 server only performs AAAA record synthesis on the domain names in the whitelist, and the IPv6 prefix used for synthesis is the NAT64 mapping prefix. At the same time, the gateway controller adds the NAT64 mapping prefix of the current batch to the policy routing table, gradually expanding the scope of the prefix's effectiveness. Concurrently, the gateway controller inserts the mapping entries corresponding to each service in the current batch into the session mapping table. Each entry contains the IPv6 source address, the converted IPv4 source address, and the NAT64 mapping prefix identifier; the mapping entries of the switched batches remain unchanged, and only the entries of the current batch are added.

[0063] S30. After each batch switch is completed, monitor the service traffic status; when the service traffic status is detected to be abnormal, extract the ongoing session status and port mapping relationship from the current session mapping table; roll back the forwarding engine to the state before the switch, and inject the session status and port mapping relationship into the rolled-back forwarding engine.

[0064] After each batch of switchovers is completed, the gateway controller continuously monitors the service traffic status through the health check module, including metrics such as packet loss rate and response latency. When an anomaly is detected, the controller extracts the ongoing session 5-tuple information and port mapping relationship from the current session mapping table, rolls the forwarding engine back to the configuration state before the switchover, and then writes the extracted session state and port mapping relationship into the rolled-back forwarding engine through the session injection interface to ensure that established connections do not need to be interrupted or reconnected.

[0065] This embodiment quantifies the resource consumption of each service on TCAM entries and DNS cache and divides the migration into batches according to the score. High resource consumption services are arranged to subsequent batches to avoid network instability caused by instantaneous overload. Secondly, the collaborative mechanism of DNS64 whitelist and NAT64 prefix policy routing realizes on-demand traffic guidance at the service level. AAAA records are synthesized only for selected services during the resolution stage, and the effective scope of the corresponding prefix is ​​only expanded at the routing level. The two-dimensional linkage accurately locks the traffic to be migrated. At the same time, the incremental update of the session mapping table ensures that services across batches do not interfere with each other, and the forwarding continuity of migrated services is not affected by subsequent operations. Finally, the anomaly monitoring and session injection rollback mechanism retains the active session state when the switch fails. After rollback, the state is written to the engine through the session injection interface. Established TCP connections do not need to be reconnected, realizing lossless self-healing of services in configuration change scenarios and avoiding large-scale session interruptions caused by rollback.

[0066] In one embodiment, calculating the IPv6 migration priority of each service based on its consumption of NAT64 session resources and DNS64 resolution resources includes:

[0067] Obtain traffic 5-tuple information and DNS64 synthesized record logs for each service within a preset statistical period;

[0068] Based on the traffic quintuple information, identify the address and port translation type triggered by each service traffic in the NAT64 translation engine; if the translation type is stateful translation, count the number of dynamic session entries occupied, and calculate the first resource utilization rate of the number of dynamic session entries relative to the total capacity of the gateway's underlying TCAM.

[0069] Based on the DNS64 synthetic record log, extract the lifetime distribution characteristics of the synthetic AAAA records corresponding to each service, calculate the number of gateway cache refreshes within a preset time period, and determine the second resource utilization rate based on the number of refreshes;

[0070] Based on the first resource utilization rate and the second resource utilization rate, a migration priority score is constructed for each business; among them, the weight coefficient of the first resource utilization rate is greater than the weight coefficient of the second resource utilization rate.

[0071] During the data collection phase, the gateway controller pre-sets a statistical period (e.g., 24 hours) and continuously collects the five-tuple information of each service traffic within this period, including source IP, destination IP, source port, destination port, protocol type, and DNS64 synthesized record logs. The five-tuple information is obtained from the NAT64 translation engine's session logs, and the DNS64 synthesized record logs are extracted from the DNS64 server's resolution cache logs.

[0072] Based on traffic 5-tuple information, the controller identifies the address and port translation types triggered by each service traffic in the NAT64 translation engine. Specifically, it checks whether the same 5-tuple maintains state association across multiple packets; if so, it's considered a stateful translation (e.g., TCP or UDP sessions); if it's a stateless translation (e.g., ICMP or some UDP query-response scenarios), this step is skipped. For services with stateful translations, the controller counts the number of dynamic session entries used by that service within the statistical period, i.e., the peak number of active sessions, and then calculates the percentage of this number relative to the total capacity of the gateway's underlying TCAM to obtain the first resource utilization rate.

[0073] The controller extracts the Time-to-Live (TTL) distribution characteristics of the synthetic AAAA records corresponding to each service based on the DNS64 synthetic record log. Specifically, for each synthetic record, its TTL value is extracted, and the number of gateway cache refreshes triggered by TTL expiration within a preset time period for that service is counted. The higher the refresh count, the more frequent the DNS resolution requests for that service, and the greater the consumption of DNS64 cache resources. A second resource utilization rate is determined based on the refresh count, which is the ratio of the number of service refreshes to the total number of refreshes for all services within the statistical period.

[0074] After obtaining the first and second resource utilization rates, a weighted summation method can be used to construct the migration priority score for each service. The weighting coefficient for the first resource utilization rate is typically greater than that for the second resource utilization rate, reflecting the fact that NAT64 session table resources are scarcer than DNS64 resolution cache resources and have a greater impact on gateway stability. A higher score indicates a greater consumption of critical gateway resources and should be migrated in a later batch.

[0075] This embodiment distinguishes between stateful and stateless transition types, only calculating TCAM session entry usage for stateful services, avoiding invalid statistics on stateless traffic and improving the accuracy and efficiency of resource assessment. Simultaneously, it calculates DNS cache refresh counts based on the TTL distribution characteristics of AAAA records, rather than simply counting total DNS queries, more accurately reflecting the actual pressure of each service on DNS64 resolution resources: services with shorter TTLs refresh more frequently, resulting in higher continuous resource consumption. This metric complements the NAT64 TCAM entry usage, comprehensively characterizing the impact of services on the gateway from both "forwarding plane hardware resources" and "control plane resolution resources" dimensions. By setting the weighting coefficient of TCAM usage to be greater than that of DNS cache usage, the migration priority ranking prioritizes reflecting the hardware entry resource pressure that has the greatest impact on gateway stability, ensuring that high TCAM consumption services are migrated later, effectively avoiding the risk of session establishment failure due to insufficient TCAM capacity during the migration process.

[0076] In one embodiment, the process of constructing migration priority scores for each service includes:

[0077] Obtain the hardware water level warning threshold of the gateway's underlying TCAM, and determine whether the first resource utilization rate of each service exceeds the hardware water level warning threshold;

[0078] If it does not exceed the limit, then the product of the first resource utilization rate and the first linear coefficient, and the product of the second resource utilization rate and the second linear coefficient are added together to obtain the basic priority score;

[0079] If it exceeds the limit, calculate the overflow ratio of the first resource utilization rate exceeding the hardware water level warning threshold. Using a preset base as the base and the product of the overflow ratio and the preset exponential amplification factor as the exponent, calculate the hardware overload penalty factor.

[0080] Multiply the hardware overload penalty factor by the base priority score to obtain the final migration priority score for each service.

[0081] The gateway controller pre-reads the hardware water level warning threshold of the underlying TCAM chip. This threshold represents the safe operating limit of TCAM entry utilization, for example, set to 70%. For each service, the controller determines whether its first resource utilization exceeds this warning threshold.

[0082] If the first resource utilization rate does not exceed the warning threshold, the basic priority score is calculated using a linear weighting method: the first resource utilization rate is multiplied by the first linear coefficient to obtain the first weighted value, and the second resource utilization rate is multiplied by the second linear coefficient to obtain the second weighted value. The sum of the two is the basic priority score. The first linear coefficient is greater than the second linear coefficient, for example, 1.0 and 0.5 respectively, to reflect that TCAM hardware resources have a greater impact on gateway stability than DNS cache resources.

[0083] If the first resource utilization rate exceeds the warning threshold, the overflow degree exceeding the warning threshold is first calculated, which is the first resource utilization rate minus the warning threshold. Then, the hardware overload penalty factor is calculated: using a preset base (e.g., 10) as the base, and the product of the overflow degree and a preset exponential amplification factor (e.g., 2) as the exponent, an exponential calculation is performed. The greater the first resource utilization rate exceeds the threshold, the greater the overflow degree, and the penalty factor grows exponentially, achieving a rapid increase in penalties for high-load services.

[0084] The hardware overload penalty factor is multiplied by the base priority score to obtain the final migration priority score for this service. This score will be significantly higher than the score for services that have not exceeded the threshold, thus scheduling this service for migration in a later batch.

[0085] This embodiment achieves a segmented processing mechanism by setting a TCAM hardware water level warning threshold. This mechanism combines linear bonuses in low-load areas with exponential penalties in high-load areas, better reflecting the actual physical characteristics of TCAM hardware resources experiencing a sharp performance decline when they approach saturation. When a service's occupancy rate on the TCAM exceeds the warning threshold, the exponential penalty factor dramatically amplifies the service's migration priority score, ensuring it is scheduled for migration in subsequent batches. This avoids hardware stability issues such as hash collisions and frequent entry replacements caused by further increasing session pressure on already heavily loaded TCAMs. Simultaneously, the base and exponential amplification coefficient are adjustable parameters, allowing network operators to flexibly adjust the penalty intensity based on actual hardware characteristics and risk tolerance, balancing the solution's adaptability across different hardware platforms and operational flexibility.

[0086] In one embodiment, the step of constructing migration priority scores for each service further includes:

[0087] If the transition type is stateless transition, then detect the proportion of packets in each service traffic whose packet length exceeds the IPv6 minimum MTU threshold;

[0088] Based on the message ratio, the number of times each service triggers IPv6 fragmentation reassembly and IPv4 fragmentation generation within a preset statistical period is counted.

[0089] The third resource utilization rate of each service is calculated based on the number of processing times and the upper limit of the gateway CPU sharding processing queue capacity; the third resource utilization rate is multiplied by the preset CPU calculation weight coefficient to obtain the correction factor.

[0090] Update the final migration priority score for each business using the correction factor.

[0091] This embodiment, based on the established migration priority score, further introduces a correction mechanism for CPU resource consumption for services without state transitions. The specific steps are as follows:

[0092] When the gateway controller identifies that a certain service traffic triggers a stateless address and port translation in the NAT64 translation engine (e.g., ICMP packets or some UDP query response scenarios), the controller further detects the proportion of packets in that service traffic whose length exceeds the IPv6 minimum MTU threshold. The IPv6 minimum MTU threshold is 1280 bytes; packets exceeding this length require fragmentation when forwarded from the IPv6 network to the IPv4 network. Based on the detected proportion of oversized packets, the controller counts the total number of IPv6 fragmentation reassembly and IPv4 fragmentation generation processes triggered by this service within a preset statistical period. Specifically, when an oversized IPv6 packet arrives at the gateway, it must first be reassembled into a complete packet before protocol translation. Subsequently, the translated IPv4 packet is re-fragmented to adapt to the MTU limitations of the IPv4 network. Each reassembly and each fragmentation generation in this process is counted in the processing count.

[0093] The gateway controller obtains the maximum capacity of the gateway CPU sharding processing queue, compares the processing count obtained in the previous step with this maximum capacity, and calculates the proportion of CPU sharding processing resources occupied by the service, as the third resource utilization rate. This utilization rate reflects the degree of consumption of gateway CPU computing resources by the service. Subsequently, the third resource utilization rate is multiplied by a preset CPU computing weight coefficient to obtain a correction factor. This weight coefficient is preset by the operations and maintenance personnel based on the gateway CPU performance and the sensitivity of each service to CPU resources.

[0094] The correction factor is combined with the previously calculated final migration priority score to obtain the updated migration priority score. This updated score reflects the comprehensive consumption of TCAM hardware resources, DNS cache resources, and CPU sharding computing resources by the business.

[0095] Therefore, this embodiment effectively addresses the CPU fragmentation processing overhead that is often overlooked in traditional evaluations of stateless transition services. Fragmentation, reassembly, and re-fragmentation operations triggered by excessively long packets consume significant CPU computing resources. If multiple high-CPU-consuming services are migrated in adjacent batches without differentiation, it can lead to gateway CPU fragmentation processing queue overflow and a sharp increase in packet drop rate. This embodiment calculates the third resource utilization rate by statistically analyzing the relationship between fragmentation processing times and CPU queue capacity, incorporating CPU computing burden into migration priority ranking. This ensures that high-CPU-consuming services receive higher migration priority scores and are scheduled for later migrations, thereby balancing the CPU load during the migration process. Furthermore, the CPU computing weight coefficient can be flexibly adjusted by operations personnel based on actual hardware performance, allowing the solution to adapt to gateway devices with different performance levels.

[0096] In one embodiment, dividing each service into at least two migration batches based on migration priority includes:

[0097] Obtain the IPv6 migration priority score for each service;

[0098] The services are sorted in order of IPv6 migration priority score from low to high.

[0099] Calculate the priority score difference between adjacent services sequentially;

[0100] The positions between adjacent services whose priority score difference is greater than a preset threshold are determined as batch split points;

[0101] Each business is divided into several migration batches based on the batch split points.

[0102] In this embodiment, after calculating the migration priority score for each service, the gateway controller obtains the final score for all services and sorts them in ascending order of score to form a service sequence. Services with lower scores consume less gateway resources and have lower migration risk, and should be migrated in earlier batches.

[0103] In the sorted business sequence, the controller sequentially calculates the priority score difference between every two adjacent businesses. Then, each difference is compared to a preset threshold. When the difference between adjacent businesses exceeds the preset threshold, it indicates a significant difference in resource consumption characteristics between the two businesses, and the controller designates this location as a batch split point. After traversing all adjacent businesses, all batch split points are obtained.

[0104] Based on all determined batch split points, the sorted service sequence is divided into several consecutive intervals, each corresponding to a migration batch. Services within the same batch have relatively similar priority scores, resulting in a relatively balanced impact on gateway resources during migration. It should be noted that this preset threshold can be flexibly adjusted by operations personnel based on the actual network scale, total number of services, and acceptable batch size: a smaller threshold results in more split points, finer batches, and more granular migration; a larger threshold results in fewer split points, coarser batches, and higher migration efficiency.

[0105] This embodiment automatically determines the batch split point by calculating the difference in priority scores between adjacent services and comparing it with a preset threshold. This achieves objective quantification of batch division, avoiding the arbitrariness and uncertainty introduced by subjective grouping based on human experience. Simultaneously, the scores of services within the same batch are similar, ensuring a relatively uniform impact on gateway resources during migration and preventing instantaneous resource fluctuations caused by mixing high- and low-consumption services within the same batch. Furthermore, the preset threshold can be flexibly adjusted according to actual operational needs, allowing maintenance personnel to strike a balance between migration precision and execution efficiency, while also considering the solution's adaptability to network environments of different scales and risk appetites.

[0106] In one embodiment, the step of gradually expanding the scope of the NAT64 mapping prefix and adjusting the DNS64 AAAA record synthesis policy to migrate the corresponding batch of service traffic from the IPv4 forwarding path to the IPv6-to-IPv4 translation forwarding path includes:

[0107] Get the set of target domain names corresponding to each business in the current migration batch;

[0108] Generate a DNS64 composite whitelist for the current batch based on the target domain name set;

[0109] The DNS64 synthesized whitelist is sent to the DNS64 server, which is instructed to perform AAAA record synthesis operations on the domains included in the whitelist. The IPv6 prefix used in the AAAA record synthesis operation is the NAT64 mapping prefix.

[0110] This embodiment provides a specific method for achieving service-level traffic redirection through the coordinated operation of DNS64 whitelist and NAT64 mapping prefix during each batch switchover process. Specifically, before each batch switchover begins, the gateway controller first obtains the set of target domain names corresponding to each service included in the current migration batch. This set originates from service registration information or a configuration management database and records the domain names corresponding to the IPv4 services accessed by each service. Based on the obtained set of target domain names, the controller generates a DNS64 composite whitelist for the current batch. This whitelist only includes domain names accessed by the services to be migrated in the current batch and does not include domain names of services from already migrated batches or those not yet migrated. The controller distributes the generated DNS64 composite whitelist to the DNS64 server, instructing the DNS64 server to perform AAAA record synthesis operations only on domain names included in the whitelist. For domain names not in the whitelist, the DNS64 server processes them according to the standard DNS resolution process and does not perform IPv6 synthesis. When the DNS64 server performs AAAA record synthesis, the IPv6 prefix used is the pre-configured NAT64 mapping prefix, enabling the synthesized IPv6 address to be routed by the gateway to the NAT64 translation and forwarding path. Through the above mechanism, the domain names related to the current batch of services are assigned IPv6 addresses pointing to the NAT64 translation path during the DNS resolution stage. The service traffic is accurately directed to the IPv6-to-IPv4 translation forwarding path, while the domain name resolution of other services that have not been migrated is not affected in any way, and their traffic continues to be transmitted along the original IPv4 forwarding path.

[0111] This embodiment achieves precise control over the service granularity of the DNS64 compositing policy through a whitelist mechanism. AAAA record compositing is performed only on domains in the selected batch during the resolution phase, leaving unmigrated domains unaffected. This avoids the waste of gateway resources caused by unmigrated services being pulled to the translation path under the full compositing method. Simultaneously, the whitelist generation works in conjunction with the NAT64 mapping prefix, assigning routing attributes pointing to the translation path to the compositing address at the DNS resolution level. This locks traffic at the source resolution stage, eliminating the need for complex policy configurations at the routing level. Furthermore, the whitelist granularity perfectly corresponds to the migration batch, ensuring that each batch only switches traffic for the specified service, and that the resolution of migrated and unmigrated services does not interfere with each other, achieving precise and controllable control over the scope of traffic compositing.

[0112] In one embodiment, the synchronous update of the session mapping table includes:

[0113] When adding the address prefix of the current batch to the NAT64 prefix policy routing table, the mapping entries corresponding to each service in the current batch are inserted into the session mapping table. The mapping entries contain the IPv6 source address of the service, the converted IPv4 source address, and the NAT64 mapping prefix identifier used.

[0114] Whenever a subsequent batch is switched, a corresponding mapping entry is added to the session mapping table based on the address prefix of the new batch, while the mapping entries corresponding to the switched batches remain unchanged.

[0115] While adding the NAT64 mapping prefixes for the current batch to the NAT64 prefix policy routing table, the gateway controller inserts mapping entries corresponding to each service in the current batch into the session mapping table. Each mapping entry contains at least three elements: the IPv6 source address initiating the access by the service, the corresponding IPv4 source address after NAT64 translation, and the NAT64 mapping prefix identifier used in this handover. Through this mapping entry, the gateway can track the correspondence between the address translation before and after each service session and the migration batch to which it belongs.

[0116] Each time a new batch of services is switched over, the gateway controller adds a mapping entry for the new batch of services to the session mapping table based solely on the NAT64 mapping prefix of the new batch. For mapping entries corresponding to already switched batches, the original content remains unchanged regardless of subsequent switching operations. The lifecycle of the mapping entries is consistent with the session lifecycle of the services and will not be overwritten or invalidated by the addition of a new batch.

[0117] This embodiment achieves mutual isolation and independent maintenance of session mapping relationships between services in different migration batches through an incremental mapping entry insertion mechanism. Each service session's mapping entry remains unchanged after being generated during switching; subsequent batch switching operations do not overwrite or clear existing entries. This ensures that active sessions of services that have completed migration earlier can always be correctly identified and forwarded by the gateway, completely avoiding cross-batch service interruptions caused by a complete refresh of the mapping table. Simultaneously, the address translation relationships stored in the mapping entries provide necessary data support for the abnormal rollback scenario in step S30. When a switching anomaly requires a rollback of the forwarding engine, the complete session state and port mapping relationships can be directly extracted from the session mapping table for injection, ensuring rapid service recovery after rollback. Furthermore, the NAT64 mapping prefix identifier included in the mapping entries allows the gateway to distinguish the source of traffic from different batches, facilitating problem tracing and traffic statistical analysis during subsequent operation and maintenance.

[0118] See Figure 2 In one embodiment, the present invention also provides an IPv6 single-stack IPv4 cross-network access gateway configuration system, the system comprising:

[0119] Batch partitioning unit 100 is used to obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources of each service, and divide each service into at least two migration batches according to the migration priority.

[0120] The segmented migration unit 200 is used to perform the switchover of traffic to IPv6 single stack in batches according to the migration priority from low to high. During the switchover of each batch, the effective scope of NAT64 mapping prefix is ​​gradually expanded and the DNS64 AAAA record synthesis strategy is adjusted to migrate the service traffic of the corresponding batch from the IPv4 forwarding path to the IPv6-to-IPv4 translated forwarding path, and the session mapping table is updated synchronously.

[0121] The traffic monitoring unit 300 is used to monitor the service traffic status after each batch switch is completed. When the service traffic status is detected to be abnormal, it extracts the ongoing session status and port mapping relationship from the current session mapping table. It then rolls back the forwarding engine to the state before the switch and injects the session status and port mapping relationship into the rolled-back forwarding engine.

[0122] It is understood that the system provided in this embodiment has functions or includes modules that can be used to execute the methods described in the above method embodiments. The specific implementation can be referred to the description of the above method embodiments, and for the sake of brevity, it will not be repeated here.

[0123] The present invention also provides an electronic device including a processor and a memory, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor executes the computer instructions, the electronic device performs a method as described in any of the above possible implementations.

[0124] The present invention also provides a computer-readable storage medium storing a computer program, the computer program including program instructions that, when executed by a processor of an electronic device, cause the processor to perform a method as described in any of the above possible implementations.

[0125] Those skilled in the art will recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementations should not be considered beyond the scope of this invention.

Claims

1. A method for configuring an IPv6 single-stack IPv4 cross-network access gateway, characterized in that, The method includes: Obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources of each service, and divide each service into at least two migration batches according to the migration priority. The traffic is switched to IPv6 single stack in batches according to the migration priority from low to high. During the switching process of each batch, the effective scope of NAT64 mapping prefix is ​​gradually expanded and the DNS64 AAAA record synthesis strategy is adjusted. The service traffic of the corresponding batch is migrated from IPv4 forwarding path to IPv6-to-IPv4 translated forwarding path, and the session mapping table is updated synchronously. After each batch switch is completed, monitor the service traffic status; when the service traffic status is detected to be abnormal, extract the ongoing session status and port mapping relationship from the current session mapping table; roll back the forwarding engine to the state before the switch, and inject the session status and port mapping relationship into the rolled-back forwarding engine.

2. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 1, characterized in that, The calculation of IPv6 migration priority for each service based on its consumption of NAT64 session resources and DNS64 resolution resources includes: Obtain traffic 5-tuple information and DNS64 synthesized record logs for each service within a preset statistical period; Based on the traffic quintuple information, identify the address and port translation type triggered by each service traffic in the NAT64 translation engine; if the translation type is stateful translation, count the number of dynamic session entries occupied, and calculate the first resource utilization rate of the number of dynamic session entries relative to the total capacity of the gateway's underlying TCAM. Based on the DNS64 synthetic record log, extract the lifetime distribution characteristics of the synthetic AAAA records corresponding to each service, calculate the number of gateway cache refreshes within a preset time period, and determine the second resource utilization rate based on the number of refreshes; Based on the first resource utilization rate and the second resource utilization rate, a migration priority score is constructed for each business; among them, the weight coefficient of the first resource utilization rate is greater than the weight coefficient of the second resource utilization rate.

3. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 2, characterized in that, The process of constructing migration priority scores for each service includes: Obtain the hardware water level warning threshold of the gateway's underlying TCAM, and determine whether the first resource utilization rate of each service exceeds the hardware water level warning threshold; If the limit is not exceeded, the product of the first resource utilization rate and the first linear coefficient, and the product of the second resource utilization rate and the second linear coefficient are added together to obtain the basic priority score. If it exceeds the limit, calculate the overflow ratio of the first resource utilization rate exceeding the hardware water level warning threshold. Using a preset base as the base and the product of the overflow ratio and the preset exponential amplification factor as the exponent, calculate the hardware overload penalty factor. Multiply the hardware overload penalty factor by the base priority score to obtain the final migration priority score for each service.

4. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 3, characterized in that, The process of constructing migration priority scores for each service also includes: If the transition type is stateless transition, then detect the proportion of packets in each service traffic whose packet length exceeds the IPv6 minimum MTU threshold; Based on the message ratio, the number of times each service triggers IPv6 fragmentation reassembly and IPv4 fragmentation generation within a preset statistical period is counted. The third resource utilization rate of each service is calculated based on the number of processing times and the upper limit of the gateway CPU sharding processing queue; the third resource utilization rate is multiplied by the preset CPU calculation weight coefficient to obtain the correction factor. Update the final migration priority score for each business using the correction factor.

5. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 1, characterized in that, The process of dividing each service into at least two migration batches based on migration priority includes: Obtain the IPv6 migration priority score for each service; The services are sorted in order of IPv6 migration priority score from low to high. Calculate the priority score difference between adjacent services sequentially; The positions between adjacent services whose priority score difference is greater than a preset threshold are determined as batch split points; Each business is divided into several migration batches based on the batch split points.

6. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 1, characterized in that, The gradual expansion of the NAT64 mapping prefix's effective scope and adjustment of the DNS64 AAAA record synthesis strategy will migrate the corresponding batch of service traffic from the IPv4 forwarding path to the IPv6-to-IPv4 translated forwarding path, including: Get the set of target domain names corresponding to each business in the current migration batch; Generate a DNS64 composite whitelist for the current batch based on the target domain name set; The DNS64 synthesized whitelist is sent to the DNS64 server, which is instructed to perform AAAA record synthesis operations on the domains included in the whitelist. The IPv6 prefix used in the AAAA record synthesis operation is the NAT64 mapping prefix.

7. The IPv6 single-stack IPv4 cross-network access gateway configuration method according to claim 1, characterized in that, The synchronous update session mapping table includes: When adding the address prefix of the current batch to the NAT64 prefix policy routing table, the mapping entries corresponding to each service in the current batch are inserted into the session mapping table. The mapping entries contain the IPv6 source address of the service, the converted IPv4 source address, and the NAT64 mapping prefix identifier used. Whenever a subsequent batch is switched, a corresponding mapping entry is added to the session mapping table based on the address prefix of the new batch, while the mapping entries corresponding to the switched batches remain unchanged.

8. A configuration system for an IPv6 single-stack IPv4 cross-network access gateway, characterized in that, The system includes: The batch division unit is used to obtain the traffic characteristics of each service, calculate the IPv6 migration priority of each service based on the consumption of NAT64 session resources and DNS64 resolution resources of each service, and divide each service into at least two migration batches according to the migration priority. The segmented migration unit is used to perform the switchover of traffic to IPv6 single stack in batches according to the migration priority from low to high. During the switchover of each batch, the effective scope of NAT64 mapping prefix is ​​gradually expanded and the DNS64 AAAA record synthesis strategy is adjusted to migrate the service traffic of the corresponding batch from the IPv4 forwarding path to the IPv6-to-IPv4 translated forwarding path, and the session mapping table is updated synchronously. The traffic monitoring unit is used to monitor the service traffic status after each batch switch is completed. When the service traffic status is detected to be abnormal, it extracts the ongoing session status and port mapping relationship from the current session mapping table, rolls back the forwarding engine to the state before the switch, and injects the session status and port mapping relationship into the rolled-back forwarding engine.

9. An electronic device, characterized in that, include: A processor and a memory, the memory being used to store computer program code, the computer program code including computer instructions, wherein when the processor executes the computer instructions, the electronic device performs the IPv6 single-stack IPv4 cross-network access gateway configuration method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, which includes program instructions that, when executed by a processor of an electronic device, cause the processor to perform the IPv6 single-stack IPv4 cross-network access gateway configuration method according to any one of claims 1 to 7.

Images