Active cooperative perception based ipv6 network asset multi-dimensional feature detection system and method

Abstract

This invention discloses a multi-dimensional feature detection system and method for IPv6 network assets based on proactive collaborative sensing, belonging to the field of digital information transmission technology. The system includes: dividing the IPv6 prefix space based on consistent hashing; nodes mutually recognizing each other through a member discovery protocol and independently calculating their responsibility range; synchronizing a historical seed database after startup; learning address patterns to generate a candidate target set; performing deep sampling after deduplication and synchronization of live addresses; and using idle nodes to steal high-priority tasks to achieve load balancing. This invention possesses good scalability and fault tolerance, avoids duplicate scanning and task conflicts, balances detection efficiency and network friendliness, ensures data consistency and the reliability of detection results, and shortens the overall scanning cycle by having idle nodes steal high-priority tasks. It also dynamically plans rescan time based on historical hit rates, forming a long-term, self-optimizing continuous detection cycle, thereby improving the asset discovery capability and resource utilization in the IPv6 space.

Description

Technical Field

[0001] This invention relates to the field of digital information transmission technology, and in particular to a multi-dimensional feature detection system and method for IPv6 network assets based on proactive collaborative sensing. Background Technology

[0002] With the large-scale deployment of IPv6 (Internet Protocol version 6), while its 128-bit address length solves the address exhaustion problem, it also leads to extremely sparse address distribution. Furthermore, IPv6's stateless address autoconfiguration and privacy extension mechanisms allow devices to autonomously generate and frequently change addresses without a central record, resulting in highly dynamic, short-lived, and difficult-to-associate IPv6 addresses for the same physical asset. Existing intelligent address prediction technologies based on target generation algorithms collect known active IPv6 addresses as seeds and use statistical, machine learning, or pattern mining methods to learn the distribution patterns of high-order prefixes and low-order interface identifiers in these seed addresses, automatically generating more likely candidate addresses to improve detection efficiency. These methods primarily focus on address viability assessment, while the collaborative collection of multi-dimensional features... In terms of asset detection, existing technologies combine link utilization measurement with asset detection. For example, by sending probe packets with timestamp extension headers, the link queuing latency is measured by using the current timestamp written by each hop router, thus providing a reference for the scheduling of probe nodes. Simultaneously, for high-speed route lookup, a method of independently constructing a multi-bit trie for each VPN and introducing hash calculations can improve packet forwarding efficiency during large-scale address detection. Furthermore, in IPv6 hybrid network environments, by receiving log packets through a dual-stack protocol stack and normalizing the source and destination addresses, address changes during tunnel transmission can be reconstructed, thereby enabling the association between logs and assets. These technologies provide support for IPv6 network asset detection from the perspectives of link performance awareness, route forwarding optimization, and address normalization.

[0003] For example, Chinese invention patent CN102724068B discloses a method for identifying audit log assets in an IPv6 hybrid network, which includes: receiving log packets based on an external IPv6-IPv4 dual-stack protocol stack; obtaining the log source address from the log packet and parsing out the source address and destination address; normalizing the log source address, source address, and destination address to restore the changes that occur during various tunnel transmission processes; and identifying the corresponding log source asset, source asset, and destination asset from the normalized log source address, source address, and destination address.

[0004] For example, the Chinese invention patent with announcement number CN101192951B discloses an IPv6 network link utilization measurement method, measurement device, and IPv6 network router, which includes: a probe source sending multiple probe packets with timestamp extension headers to the network; each hop router through which the probe packets pass writes the current timestamp into the probe packets; and the probe source and / or destination obtaining the link utilization based on the timestamp sequence of the multiple probe packets.

[0005] The above-mentioned technology has at least the following technical problems: In existing large-scale IPv6 distributed probing deployments, each probing node typically operates independently, lacking a real-time task negotiation and information sharing mechanism. This inevitably leads to repeated scanning of the same prefix or omission of less common prefixes, resulting in wasted probing resources and asset blind spots. Repeated scanning of the same prefix may trigger the target network's security protection mechanisms due to a large number of probes in a short period, causing normal probing to fail or even harming legitimate services. Furthermore, the inability to synchronize and deduplicate live addresses discovered by each node in real time leads to the same address being repeatedly probed by multiple nodes, further exacerbating resource waste and the risk of protection triggering. All of these factors together restrict the coverage efficiency and scalability of the distributed probing system. Summary of the Invention

[0006] On the one hand, a multi-dimensional feature detection system for IPv6 network assets based on proactive collaborative awareness is provided. This system includes: The target detection and generation module is used to detect nodes to learn from each other through the member discovery protocol, and to map the IPv6 prefix space to the virtual ring using consistent hashing. Each detection node generates a virtual detection node based on its own identifier to independently calculate the prefix range it is responsible for. At the same time, it synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the candidate detection target set.

[0007] The detection execution module is used by each detection node to first check the distributed atomic lease lock for candidate prefixes. During the scanning process, each detection node dynamically adjusts the packet sending rate based on real-time feedback, switches the mode for prefixes that have triggered protection and introduces random jitter, and newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table.

[0008] The feature acquisition module is used to perform deep feature acquisition on the live addresses after deduplication and synchronization, analyze the hit rate and determine the verification request sending requirements, and adjust the virtual probe node strategy of the prefix on the hash ring based on the verification feedback.

[0009] The collaborative scheduling module is used to detect conflicts before and after scanning by probe nodes via broadcast, resolve conflicts with the latest timestamp, and enable idle probe nodes to actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

[0010] On the other hand, a method for detecting multi-dimensional features of IPv6 network assets based on proactive collaborative sensing is provided, which includes: The probe nodes learn from each other through the member discovery protocol, use consistent hashing to map the IPv6 prefix space to the virtual ring, and each probe node generates a virtual probe node based on its own identifier to independently calculate the prefix range it is responsible for. At the same time, it synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the candidate probe target set.

[0011] Each probe node first checks the distributed atomic lease lock for candidate prefixes. During the scanning process, each probe node dynamically adjusts the packet sending rate based on real-time feedback. For prefixes that have triggered protection, the mode is switched and random jitter is introduced. Newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table.

[0012] Deep feature collection is performed on the live addresses after deduplication and synchronization. The hit rate is analyzed and the verification request sending requirements are determined. Based on the verification feedback, the virtual probe node strategy of this prefix on the hash ring is adjusted.

[0013] The probe nodes perform conflict detection before and after scanning via broadcast, and resolve conflicts with the latest timestamp. Idle probe nodes actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

[0014] The beneficial effects of the technical solutions provided by the embodiments of the present invention include at least the following: 1. The IPv6 network asset multi-dimensional feature detection system based on proactive collaborative perception provided by this invention adopts a decentralized consistent hashing and member discovery protocol, enabling the detection nodes to dynamically expand and shrink without central coordination, thus possessing good scalability and fault tolerance. Through a dual mechanism of distributed atomic lease locks and broadcast declarations, it avoids duplicate scanning and task conflicts. Based on feedback adjustments of real-time response rate and hit rate, it achieves adaptive optimization of packet sending rate, number of virtual nodes, and detection depth, balancing detection efficiency and network friendliness. It automatically introduces random jitter into the prefix that triggers protection, reducing the risk of being identified as an attack. Through the distributed hash table to synchronize new addresses and the verification mechanism, it ensures data consistency and the credibility of detection results. Idle nodes actively steal high-priority tasks to achieve load balancing and shorten the overall scanning cycle. Combined with historical hit rate, it dynamically plans the rescan time, forming a long-term, self-optimizing continuous detection cycle, significantly improving the asset discovery capability and resource utilization of massive IPv6 space.

[0015] 2. This invention enables all probe nodes to know each other through a lightweight member discovery protocol. It uses a consistent hashing algorithm to map the IPv6 prefix space to a virtual ring. Each node generates multiple virtual nodes based on its unique identifier and independently calculates the prefix range it is responsible for. The ring automatically adjusts when a node joins or leaves, eliminating the need for a central coordinating node, thus eliminating single points of failure and performance bottlenecks. The virtual node mechanism makes the load distribution more even. Differences in node computing power can be adapted by adjusting the number of virtual nodes. When a node changes dynamically, only local recalculation of its affiliation is required. It has a fast convergence speed, strong scalability, and can support probe nodes to collaboratively cover the entire IPv6 address space.

[0016] 3. This invention effectively distinguishes between real sparse asset regions and single-point random errors through cross-node verification, avoiding incorrect penalties for asset-containing prefixes due to temporary network jitter. The dynamic adjustment of the number of virtual nodes automatically tilts scanning resources towards high-value prefixes, improving overall detection efficiency. At the same time, high-hit-rate prefixes automatically increase detection depth, enabling refined feature collection of asset-dense regions, while reducing resource input in low-value regions, thus maximizing detection benefits.

[0017] 4. This invention ensures high mutual exclusion of scanning tasks in a distributed environment through dual conflict detection, namely broadcast declaration and timestamp arbitration. Even if there is a brief inconsistency in the distributed cache, it can eventually converge through timestamps, avoiding repeated scanning and resource waste. The task stealing mechanism enables idle nodes to actively share the unfinished tasks of other nodes, achieving dynamic load balancing without destroying the stability of the consistent hash ring, shortening the overall scanning cycle. The timestamp-based conflict resolution avoids long lock waiting times, improving the concurrency and robustness of the system. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 A framework diagram of a multi-dimensional feature detection system for IPv6 network assets based on proactive collaborative sensing provided in this application embodiment; Figure 2 Flowchart of the method for multi-dimensional feature detection of IPv6 network assets based on proactive collaborative sensing provided in the embodiments of this application; Figure 3 This is a flowchart illustrating the active detection and multi-dimensional feature acquisition process involved in the embodiments of this application; Figure 4 This is a timing diagram of the collaborative detection mission involved in this embodiment. Detailed Implementation

[0020] Embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of the present disclosure are shown in the drawings, it should be understood that embodiments of the present disclosure may be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of the present disclosure.

[0021] To make the technical problems, technical solutions and advantages of the present invention clearer, a detailed description will be given below in conjunction with the accompanying drawings and specific embodiments.

[0022] Embodiment 1 of the present invention Figure 1 The diagram shown is a framework diagram of a multi-dimensional feature detection system for IPv6 network assets based on proactive collaborative perception provided in an embodiment of this application. The system includes: a target perception and generation module, a detection execution module, a feature acquisition module, and a collaborative scheduling module.

[0023] The target detection and generation module is used to detect nodes to learn from each other through the member discovery protocol, use consistent hashing to map the IPv6 prefix space to the virtual ring, and generate virtual detect nodes according to their own identifiers to independently calculate the prefix range they are responsible for. At the same time, it synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the candidate target set.

[0024] like Figure 2 The flowchart of the active detection and multi-dimensional feature collection involved in the embodiments of this application includes: dividing the IPv6 prefix space into each detection node based on consistent hashing, and the nodes mutually know each other through the member discovery protocol and independently calculate the scope of responsibility; after startup, the historical seed library is synchronized to generate a candidate detection target set, the prefix is ​​extracted from each address in the candidate detection target set, the packet sending rate is dynamically adjusted through distributed atomic lease lock and based on real-time feedback, if the continuous low response rate triggers protection, random jitter is introduced, and deep feature collection is performed on the collected live addresses.

[0025] After each probe node starts up, it periodically sends heartbeat messages to other nodes in the cluster through a lightweight member discovery protocol and listens for announcements from other nodes, thereby dynamically discovering and maintaining a list of currently active probe nodes. At the same time, each probe node obtains its own unique identifier and determines the preset number of virtual nodes. For each virtual node sequence number, the unique identifier and sequence number are concatenated into a string, and this string is input into a hash function to calculate a fixed-length hash value. This hash value is then scaled proportionally according to the size of the ring space to obtain an integer position that falls on the ring. By repeating this process, each probe node can generate its own position on the hash ring, thus completely mapping the entire IPv6 prefix space to the hash ring.

[0026] The probe node is an independent software unit that serves as the main execution entity of the entire probe system. Multiple probe nodes are interconnected through a lightweight member discovery protocol to form an internal collaborative network. In this network, nodes share state, synchronize historical seed databases, and coordinate scanning tasks. Each probe node simultaneously faces the target IPv6 network, i.e., the Internet to be probed, and independently generates probe targets, sends probe packets, receives responses, and analyzes live assets based on the prefix range assigned by the consistent hashing algorithm. The probe nodes synchronize newly discovered IPv6 addresses and scan results in the internal collaborative network through a distributed hash table, thereby achieving large-scale, collaborative, and adaptive probing of the target IPv6 network.

[0027] Lightweight member discovery protocols are decentralized, low-overhead distributed communication mechanisms used to automatically detect each other's presence and maintain real-time membership status among probe nodes. Typically implemented based on the Gossip algorithm, each probe node periodically and randomly selects a small number of other probe nodes to exchange heartbeats, probe node lists, and status updates. Through multiple propagations, all probe nodes in the cluster eventually obtain a consistent membership view. Compared to traditional centralized registries or strongly consistent protocols, lightweight member discovery protocols offer advantages such as lower network bandwidth consumption, faster response to dynamic node additions and removals, and stronger fault tolerance, making them suitable for large-scale, highly dynamic IPv6 asset probe clusters.

[0028] The list of locations of all virtual probe nodes in the world is obtained through a lightweight member discovery protocol and sorted by hash value from smallest to largest. For each virtual node belonging to this probe node, the interval between it and the next virtual node in a clockwise direction is taken, and all such intervals are mapped back to the IPv6 prefix range, thereby obtaining the set of prefixes that this probe node is responsible for.

[0029] When a new probe node joins or an existing probe node leaves, the new probe node broadcasts its state change to all other nodes via a lightweight member discovery protocol. Upon receiving the update, each probe node concatenates the new probe node's unique identifier with its virtual node sequence number and calculates a hash value. It then inserts the new probe node into the existing global virtual node position list or removes all virtual nodes from the departing node. The list is then reordered, and each node recalculates the interval between its own virtual node and the next virtual node clockwise based on the new order. This interval is then mapped back to the IPv6 prefix range, resulting in an adjusted set of responsible prefixes. This achieves automatic adjustment of the hash ring and redistribution of ownership.

[0030] After each probe node starts, it first generates a DHT (Distributed Hash Table) node ID based on its own identifier and joins the distributed hash table network. Then, it uses the DHT lookup primitive to send a query request to the network with a predefined seed key to obtain complete or incremental data of the historical seed database from other online probe nodes. After receiving the response, it stores the seed database in the local cache for subsequent target generation algorithm learning.

[0031] In a distributed hash table, the DHT node ID is a fixed-length binary string calculated by each probe node when it joins the distributed hash table by inputting its own unique identifier into a hash function. This node ID serves as both a unique identifier for the node in the DHT identifier space and a key-value pair to be stored in the DHT routing tree. In this way, probe nodes can discover and locate each other's data without the need for a central server.

[0032] Each probe node independently runs a target generation algorithm. First, it extracts all known live IPv6 addresses from its locally cached historical seed database. By statistically analyzing the network prefix portion of all seed addresses, addresses with the same prefix are grouped together, and the number of addresses in each group is counted. Then, the number of addresses in each prefix group is divided by the total number of live addresses in the seed database to obtain the frequency of each prefix. If the frequency of a prefix is ​​higher than the prefix frequency threshold preset by the experts, it is marked as a high-weight prefix, which is more likely to continue to exist as active assets in the future. The last 64 bits of the seed address corresponding to the high-weight prefix are extracted, and their common generation patterns are analyzed, including but not limited to sequential increment and embedded timestamps. The algorithm combines the time characteristics of the current period with a preset Markov chain model to generate several lists of IPv6 addresses that are most likely to exist as live assets. Finally, the IPv6 address list serves as the candidate probe target set for this probe node in the current probe period for subsequent scan scheduling.

[0033] The specific implementation of the target generation algorithm for generating an IPv6 address list is as follows: The target generation algorithm counts the frequency of network prefixes of all surviving IPv6 addresses in the historical seed database. Sampling weights are assigned based on the frequency of network prefixes of all surviving IPv6 addresses in the historical seed database. Then, the last 64 bits of the interface identifier of each surviving IPv6 address are extracted. Common patterns are analyzed, including but not limited to sequential increment, embedded timestamps, and random low-entropy values. The byte transition probability of the interface identifier is modeled based on a second-order Markov chain. During Markov chain model initialization, the transition matrix is ​​set to a uniform distribution, meaning that the probability of all 256 next bytes in each state is equal. During runtime, the transition count is dynamically updated using the actual interface sequences in the local historical seed database, adapting the model to the actual generation patterns of the target network. The algorithm randomly samples a prefix based on the prefix probability distribution, and then, starting from the current byte state, predicts and generates a 64-bit interface identifier byte by byte based on the transition probability of the Markov chain. Finally, the prefix and interface identifier are concatenated to form a complete IPv6 address. The above sampling and generation process is repeated until a preset number of candidate addresses is reached, thus forming a detection target list most likely to contain surviving assets.

[0034] A Markov chain is a mathematical model that describes a sequence of random states. Its core characteristic is memorylessness, meaning that the probability distribution of future states depends only on the current state and is independent of past historical states. In IPv6 address generation, a second-order Markov chain is typically used, which considers the current and previous bytes as two bytes as the state to predict the value of the next byte. By statistically analyzing the byte transition probabilities in historical data, a sequence of interface identifiers that conforms to a certain pattern is generated.

[0035] The detection execution module is used by each detection node to first check the distributed atomic lease lock for candidate prefixes. During the scanning process, each detection node dynamically adjusts the packet sending rate based on real-time feedback, switches the mode for prefixes that have triggered protection and introduces random jitter, and newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table.

[0036] For a specific IPv6 address contained in the candidate probe target set, the probe node first extracts the network segment prefix to which each address belongs, converting the address level to the prefix level. Because distributed coordination at the subnet granularity can more efficiently avoid scanning conflicts, the probe node then sends an atomic query to the distributed cache with the string representation of the prefix as the key for each extracted prefix, and the probe node attempts to acquire the request. This utilizes the aggregation property of the prefix and ensures that multiple probe nodes do not scan the same subnet repeatedly.

[0037] Distributed atomic lease locks refer to the use of atomic operations provided by distributed caching in distributed systems. A resource is written as a key and its state as a value to the cache, thereby achieving mutual exclusion locking among multiple nodes. The atomic write ensures that the two steps of checking existence and setting the lock are completed indivisibly in a concurrent environment, preventing multiple nodes from acquiring the lock for the same resource at the same time. The lease lock means that the lock has a validity period, i.e., the lease time, and is automatically released after the timeout, preventing the lock from being permanently occupied due to node failure. In this way, probing nodes can safely preempt scanning tasks, realizing task coordination and mutual exclusion in a distributed environment.

[0038] When a probe node sends an atomic query to the distributed cache with a certain prefix as the key and attempts to acquire it, if the string key corresponding to the prefix does not exist in the cache (meaning the prefix is ​​not currently locked by any probe node), the probe node will atomically set the value of the key to be the unique identifier of the current probe node and simultaneously set a lease time, indicating that it has successfully acquired the prefix. During the lease validity period, other probe nodes will automatically skip scanning if they find that the key already exists, while the current probe node can safely perform probe tasks on the addresses under the prefix, thus achieving mutual exclusion and coordination of scan tasks in a distributed environment.

[0039] The probe node uses the historical average scan time in the database as the lease time. After determining the lease time, when the probe node performs an atomic query and occupancy operation, it adds the current timestamp and the lease time to obtain the absolute expiration timestamp, and writes it together with the node's unique identifier as a key-value pair into the distributed cache. The key is automatically deleted after the absolute expiration timestamp, so that the lease expires automatically. Other nodes will see that the key exists and has not expired when querying, and thus skip this prefix.

[0040] When a probe node sends an atomic query to the distributed cache with a certain prefix as the key and attempts to acquire it, if the string key corresponding to the prefix already exists in the cache, it means that the prefix has been locked by a probe node. Furthermore, if the node identifier stored in the key is inconsistent with the current probe node's own identifier, the current probe node determines that the prefix has been successfully acquired by another probe node. In this case, the current probe node will not attempt to overwrite or modify the key, but will directly skip the scan task for this prefix to avoid duplicate scans or conflicts with other probe nodes.

[0041] Once a prefix is ​​successfully acquired, i.e., the node identifier is written into the distributed cache and a lease is set through atomic operations, the probe node immediately begins sending probe packets to the locked prefix. During the sending process, the probe node will count the number of valid response packets received in the current probe period and divide it by the total number of packets sent to obtain the probe packet response rate. This rate is used to dynamically adjust the packet sending rate based on network conditions or to determine whether the target network has enabled protection mechanisms.

[0042] When a probe node calculates that the response rate of probe packets within the current probe cycle is less than or equal to the system's preset response rate threshold, it means that the target network may be experiencing congestion, packet loss, or triggering a protection mechanism. At this time, the probe node uses an exponential backoff algorithm to reduce the packet sending rate. The probe node multiplies the current packet sending rate by (1 - the preset backoff factor) and uses the result as the new packet sending rate, while recording the number of backoffs. If the response rate of probe packets continues to be lower than the threshold in subsequent cycles, the packet sending rate will continue to be reduced exponentially. In this way, the probe node can quickly reduce the impact on the target network, avoid being misjudged as attack traffic, and wait for the network condition to recover before gradually increasing the probe speed.

[0043] The core mechanism of exponentially reducing packet transmission rate is to progressively increase the waiting time for each retry by a preset multiple of 2. That is, after the first failure, wait for a preset baseline time; after the second failure, wait for twice the baseline time; after the third failure, wait for four times; after the fourth failure, wait for eight times, and so on. This exponential increase in waiting time causes the number of packets sent per unit time to drop sharply at the same exponential rate, thereby causing the scanning traffic to decay from a high level to an extremely low level in a very short time. This avoids being rate-limited, blocked, or black-hole routed. Once subsequent probe packets begin to receive normal responses, the probe node gradually recovers by linearly and slowly increasing the rate, thus achieving adaptive control that is both fast backoff and gentle recovery.

[0044] The response rate threshold in the database is preset by technicians at the start as an initial fixed value based on experience. All probe nodes send probe packets at the lowest safe rate in the first three probe cycles without slowing down or backing off. The average response rate of these three cycles is statistically calculated as the baseline response rate. The baseline response rate is multiplied by a safety factor to obtain the dynamic threshold, and the larger of this and the initial fixed value is taken as the actual response rate threshold. Technicians perform baseline acquisition and threshold update.

[0045] In this embodiment, the preset logic of the tolerance threshold, hit rate threshold, and priority threshold is similar to that of the response rate threshold. The specific values ​​can be flexibly set by professional technicians in combination with business scenarios, equipment characteristics and control requirements. This embodiment will not be elaborated on further.

[0046] When the current period's probe packet response rate, as calculated by the probe node, is greater than the preset response rate threshold, it indicates that the target network is responding well and there is no significant congestion or protective intervention. At this time, the probe node can dynamically increase the packet sending rate based on the deviation between the probe packet response rate and the threshold. The response deviation value is obtained by subtracting the response rate threshold from the probe packet response rate. The packet sending rate increase value is determined based on the response deviation value. Then, the packet sending rate increase value is added to the current packet sending rate to obtain the new packet sending rate, which is applied to the next probe cycle. Through this positive adjustment based on the deviation value, the probe node can gradually improve the probe efficiency when network conditions permit, while avoiding the impact caused by sudden rate changes.

[0047] The packet transmission rate improvement value is determined based on the response deviation value. The specific steps are as follows: first, calculate the response deviation value, then multiply it by the rate gain coefficient based on the current packet transmission rate to obtain the packet transmission rate improvement value. The rate gain coefficient is the ratio of the response deviation value to the response rate threshold. The final new packet transmission rate is the sum of the current packet transmission rate and the packet transmission rate improvement value, and the new packet transmission rate must not exceed the set maximum packet transmission rate limit. In this way, the larger the response deviation value, the larger the improvement value, thereby realizing positive proportional speed regulation based on the response rate deviation.

[0048] When a probe node detects that the cumulative number of times the probe packet response rate of a certain prefix is ​​less than or equal to the preset response rate threshold exceeds the system's preset tolerance threshold within multiple consecutive probe cycles, it indicates that the target network area corresponding to that prefix may experience continuous network congestion, severe packet loss, or more likely, the target network's protection mechanism has been triggered, resulting in a large number of probe packets being dropped or rejected. In this case, the probe node should determine that this prefix is ​​in an unhealthy state and introduce random jitter to reduce the risk of further blocking and avoid wasting resources on ineffective probes. This involves adding a random offset to the originally fixed probe packet sending interval, randomly selecting the source port of each probe packet, and making the time delay between adjacent probe packets follow a uniform distribution, i.e., uniformly and randomly taking values ​​between a specified minimum and maximum value. This transforms the probe traffic characteristics to be closer to normal background traffic, thereby reducing the risk of further identification or blocking.

[0049] When a probe node discovers a new live IPv6 address, it immediately packages the address, discovery timestamp, and the probe node's unique identifier into a message and broadcasts it to all other probe nodes in the cluster via a distributed hash table routing mechanism. Upon receiving the message, other probe nodes first check their local cache of probed addresses. If the new live IPv6 address already exists in the cache and the timestamp in the message is less than the timestamp of the local record, the message is discarded and the cache is not updated; the record for that address is saved. Otherwise, the new live IPv6 address, its timestamp, and the source node ID are stored in or updated in the local cache. This ensures that all nodes in the network retain only the latest discovery record for the same live address, avoiding subsequent repeated deep probing.

[0050] The feature acquisition module is used to perform deep feature acquisition on the live addresses after deduplication and synchronization, analyze the hit rate and determine the verification request sending requirements, and adjust the virtual probe node strategy of the prefix on the hash ring based on the verification feedback.

[0051] After completing the deduplication and synchronization of live addresses, the probe node performs deep feature collection on each confirmed live IPv6 address, conducts port scanning, and detects the open status of service ports. For the detected open ports, it further obtains service version information by sending specific protocol probes. Utilizing the fingerprinting technology of the TCP / IP protocol stack, it sends carefully constructed TCP packets and analyzes the characteristics of the response packets, comparing them with the operating system fingerprint database to infer the operating system type and version number of the target host. Through multi-dimensional feature collection, a comprehensive profile of IPv6 assets is achieved.

[0052] like Figure 3 The timing diagram for the collaborative detection task involved in this embodiment includes: after the acquisition is completed, the node calculates the prefix hit rate. If the hit rate is lower than the hit rate threshold, a review is initiated. The number of virtual nodes is adjusted according to the review feedback. If the hit rate is higher than or equal to the threshold, the detection depth is increased. Conflicts are resolved before and after scanning by broadcasting the intended scan declaration and timestamp. In case of conflict, the latest timestamp is used and the scan is rolled back and re-scanned. Idle nodes broadcast their idle status. The source node transfers the prefix to the idle node. Task theft is achieved through atomic occupancy and conflict notification.

[0053] After the data collection is completed, the probe node calculates the hit rate of the live addresses in this scan, counts the number of newly discovered live IPv6 addresses under this prefix during this scan, and the total number of probe packets sent to this prefix. The hit rate of this scan prefix is ​​obtained by dividing the number of newly discovered live IPv6 addresses by the total number of probe packets. The hit rate reflects the activity level of the addresses under this prefix and is used for subsequent evaluation to determine whether a review, adjustment of scan weight, or change of probe depth is needed.

[0054] When a probe node calculates a hit rate for a prefix that is lower than the system's preset hit rate threshold, it indicates that the number of actually active IPv6 addresses under that prefix is ​​very small relative to the total number of addresses probed. In other words, the assets under that prefix are relatively sparse, and continuing to invest a large amount of probe resources may yield low returns. At this time, the hit rate calculated by a single probe node may be low due to its own network jitter, temporary congestion, accidental dropping of probe packets, or instantaneous fluctuations in the target network. However, this does not confirm whether there are active assets under that prefix. By having another probe node sample and rescan the prefix to obtain a verified hit rate, if the verified hit rate is lower than the preset hit rate threshold, it is confirmed that the prefix is ​​indeed sparse in assets. Otherwise, it indicates that the original probe results are abnormal, and the verified results should be accepted to avoid mistakenly classifying a prefix with actual assets as a low-value area, thereby protecting the reasonable allocation of probe resources.

[0055] If the hit rate obtained by another probe node after sampling and rescanning the prefix is ​​also lower than the preset hit rate threshold, it indicates that the prefix exhibits asset sparsity characteristics under different times and different network paths, ruling out false negatives caused by network jitter or temporary failures of the original node. Therefore, the reliability is high. The deviation between the two hit rates and the threshold is calculated separately, and the average of the two deviations is recorded as the average hit rate deviation. The reduction value of the number of virtual probe nodes on the consistent hash ring is determined based on the average hit rate deviation value. If the hit rate of another probe node is higher than or equal to the preset hit rate threshold, it indicates that the low hit result of the original node is likely a false negative caused by accidental factors. In reality, the prefix still has a certain amount of active assets. If the weight is rashly reduced in this case, valuable areas will be missed. Therefore, the hit rate of the verification node is used as the standard, and the current number of virtual probe nodes for the prefix is ​​maintained without reduction, thereby avoiding wrongly penalizing prefixes with actual assets.

[0056] The specific steps for determining the reduction value of the number of virtual probe nodes on the consistent hash ring based on the average deviation value of the hit rate are as follows: First, divide the average value by the hit rate threshold to obtain the normalized deviation ratio. Then, subtract the difference between the current number of virtual probe nodes and the minimum number of virtual nodes preset by the professional technicians, multiply the difference by the normalized deviation ratio, and round down the result to obtain the number of virtual nodes to be reduced. At the same time, it must be ensured that the number of virtual nodes after reduction is not lower than the minimum value preset by the system. Thus, the larger the average deviation value, that is, the lower the hit rate is than the hit rate threshold, the more virtual nodes will be reduced. This realizes resource penalty and recovery based on the deviation ratio. By introducing a configurable reduction coefficient and the minimum number of virtual nodes, the penalty sensitivity can be flexibly adjusted according to different network environments, and ensure that each prefix retains at least basic scanning capability. When the deviation is small, the calculation result may be rounded down to zero, reflecting the tolerance of probe nodes to short-term fluctuations.

[0057] When a probe node calculates that the hit rate of a certain prefix is ​​higher than or equal to the preset hit rate threshold, it indicates that the assets under this prefix are dense and of high value. At this time, the probe node subtracts the hit rate threshold from the live address hit rate to obtain the hit rate deviation value, and determines the probe depth increase value based on the hit rate deviation value, thereby obtaining richer multi-dimensional asset feature information for high-value prefixes.

[0058] The increase in detection depth is determined by dividing the hit rate deviation by the hit rate threshold to obtain a normalized deviation ratio. This ratio is then applied to three dimensions: port scanning range, service version identification detail, and operating system fingerprint acquisition depth. In actual detection, service version identification is accomplished by sending a series of preset probes to the target port and analyzing the responses. The more probes there are, the richer the service features that can be triggered, and the higher the identification detail. The base values ​​(base port count, base probe count, and base fingerprint packet count) are multiplied by this normalized deviation ratio, and then multiplied by the corresponding expansion coefficient to obtain the increase value for each dimension. Finally, the increase values ​​for each dimension are added to the base values ​​to form a new detection depth configuration, which is applied to the next cycle of depth acquisition. Simultaneously, it is ensured that the final values ​​for each dimension do not exceed the system's preset upper limit. By expanding the scan port list, adding service identification probes, and expanding the fingerprint packet combination, more comprehensive and in-depth port scanning, service version identification, and operating system fingerprint acquisition can be performed on prefix assets, thereby achieving refined detection of prefixes.

[0059] The collaborative scheduling module is used to detect conflicts before and after scanning by probe nodes via broadcast, resolve conflicts with the latest timestamp, and enable idle probe nodes to actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

[0060] Each probe node performs a conflict detection step before and after scanning. Before scanning, the probe node broadcasts a scan declaration to all other probe nodes. This declaration includes the prefix information and task priority that it is about to scan. The probe node then listens for responses from other nodes. If it receives a "prefix already occupied" response from any other node, it indicates that the prefix has been locked or is being scanned by that node. The current probe node then abandons scanning that prefix to avoid duplicate scanning and wasted resources. If no conflict response is received, the probe node confirms that it has acquired the scanning right and continues the subsequent probe process. This conflict detection mechanism, using broadcast responses, further coordinates the scanning tasks of each node in a distributed environment.

[0061] When other probe nodes receive the broadcast scan results, they use the IPv6 address as the unique key to compare the probe results corresponding to that key in their local cache with the corresponding fields in the newly received broadcast message. If any field value is found to be different, the comparison results are considered to have a conflict; otherwise, the comparison results are considered not to have a conflict. If a conflict is found between the comparison results for the same address or the same prefix, the result with the latest timestamp is used, that is, the data obtained from the most recently completed scan is retained. At the same time, the probe nodes that previously reported the old results will automatically roll back the corresponding old data in their local cache and re-mark this prefix as pending scan status. The scan task will be re-executed for this prefix in subsequent cycles to ensure the consistency and accuracy of the final network-wide data.

[0062] If no conflict is found in the comparison results, that is, no higher priority declaration is received from other nodes, and no occupied record is found in the distributed cache, then the current probe node confirms that it has the right to scan the prefix, and then immediately begins to send probe packets to the target address under the prefix to officially execute the scanning task.

[0063] Once any probe node has completed scanning all the candidate targets it is responsible for, it broadcasts an idle status message to all other probe nodes in the cluster through the member discovery protocol. At the same time, it actively requests to share the prefix tasks that other probe nodes have not yet completed. After that, the node is marked as an idle node locally, waiting for other nodes to assign prefixes to scan, thereby achieving load balancing among nodes.

[0064] Upon receiving a request broadcast by an idle node, other probe nodes first check their own unscanned task pools and select several prefixes that meet the following conditions: the local priority of the current node is higher than or equal to the preset priority threshold, and the prefix is ​​not locked by other nodes, i.e., the corresponding key does not exist or has expired in the distributed cache. Then, these prefixes are transferred to the idle node, and the probe node is recorded as the source node.

[0065] During the task transfer process, the source node encapsulates the identifier of each selected prefix, such as the prefix string, the current scanning progress including but not limited to the number of probe packets sent, the remaining target address range, the scanning phase marker, and the timestamp generated locally by the source node, into a task transfer message, and sends it to the idle node through the member discovery protocol or point-to-point communication so that the idle node can seamlessly take over the subsequent scanning work of that prefix.

[0066] After receiving a task transfer message, an idle node performs an atomic query to the distributed cache using the prefix in the message as the key and attempts to acquire the task. If the key does not exist, meaning that the prefix is ​​not currently locked by any node, the idle node successfully acquires the prefix, adds it to its own task pool, and immediately begins scanning the target address under the prefix according to the scan progress in the message.

[0067] If an idle node attempts to perform an atomic query on the distributed cache using the prefix as the key and finds that the key already exists (meaning the prefix has been locked or occupied by another node), the attempt fails. In this case, the idle node discards the transfer task and does not add the prefix to its own task pool. At the same time, it sends a conflict notification to the source node, informing it that the prefix has been occupied by another node, so that the source node can decide whether to re-transfer or scan itself based on timestamps and other rules.

[0068] After receiving a conflict notification, the source node extracts the timestamp of the conflicting occupant from the notification and compares it with the transfer timestamp of the prefix previously sent by this node. If the timestamp of the conflicting occupant is later than the transfer timestamp of this node, it indicates that the prefix has been occupied by other nodes later during the transfer. At this time, the source node abandons the transfer operation of the prefix and re-marks it as pending scanning, leaving it for later processing by this node or other nodes.

[0069] When the source node receives a conflict notification, if it finds that the timestamp of the conflicting occupant is earlier than the transfer timestamp previously sent by this node, meaning the other party's occupancy time is older, and this node updates its transfer request, it indicates that this node's transfer operation has higher timeliness. In this case, the source node abandons the transfer, and this node completes the scanning task of that prefix on its own.

[0070] Once a probe node completes all probe tasks for a given prefix, including liveness detection and deep feature acquisition, the node proactively deletes the corresponding lock record in the distributed cache, i.e., releases the lease lock, and updates the scan status of the prefix to "completed". At the same time, the probe node records the timestamp, hit rate, and number of live addresses found in the scan in local or shared storage, as the basis for subsequent rescan scheduling and priority adjustment.

[0071] If a probe node fails to complete the probe task for a certain prefix before the lease expires, the lock record corresponding to that prefix in the distributed cache will automatically expire due to the lease time being exhausted. At this time, other probe nodes can re-execute atomic queries on the prefix and attempt to occupy it, thereby claiming the prefix and continuing to scan. When the entire probe round, that is, after all nodes have completed one round of scanning of their respective candidate probe target sets, all probe nodes enter the waiting phase, waiting for the preset rescan time to trigger the next round of probe process.

[0072] Each probe node maintains a local rescan schedule. This schedule, set by technical personnel based on historical probe data, includes a base rescan interval and a dynamic adjustment factor for each scanned prefix. After each scan, the probe node updates the next rescan time for that prefix based on the hit rate of the scan, a preset hit rate threshold, and whether a new live IPv6 address was found. If the hit rate is higher than or equal to the hit rate threshold and a new live IPv6 address is found, the rescan interval is halved. If the hit rate is higher than or equal to the hit rate threshold but no new live IPv6 address is found, the base rescan interval is maintained. If the hit rate is below the threshold and no new live IPv6 addresses are found, the rescan interval is doubled. If the hit rate is below the threshold but a new live IPv6 address is found, the basic rescan interval is restored. Then, the current scan completion timestamp is added to the adjusted rescan interval to obtain the next rescan time. When the system clock reaches the predetermined rescan time for a certain prefix, the probe node automatically remarks the prefix as pending scan and re-executes a new round of processes such as atomic occupancy and scanning from the distributed cache. This process is repeated continuously to achieve long-term, dynamic, and self-optimizing continuous probing of IPv6 network assets.

[0073] like Figure 4 The flowchart shown is a multi-dimensional feature detection method for IPv6 network assets based on active collaborative perception provided in an embodiment of this application. It includes: detection nodes mutually recognize each other through the member discovery protocol, use consistent hashing to map the IPv6 prefix space to a virtual ring, each detection node generates a virtual detection node according to its own identifier to independently calculate the prefix range it is responsible for, and at the same time synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the candidate detection target set.

[0074] Each probe node first checks the distributed atomic lease lock for candidate prefixes. During the scanning process, each probe node dynamically adjusts the packet sending rate based on real-time feedback. For prefixes that have triggered protection, the mode is switched and random jitter is introduced. Newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table.

[0075] Deep feature collection is performed on the live addresses after deduplication and synchronization. The hit rate is analyzed and the verification request sending requirements are determined. Based on the verification feedback, the virtual probe node strategy of this prefix on the hash ring is adjusted.

[0076] The probe nodes perform conflict detection before and after scanning via broadcast, and resolve conflicts with the latest timestamp. Idle probe nodes actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

[0077] In Embodiment 2 of the present invention, while remaining otherwise unchanged from Embodiment 1, stealing high-priority tasks can also be achieved through optimal allocation based on the minimum number of connections. The specific analysis method is as follows: The connection count refers to the total number of prefix tasks that a probe node has currently accepted but not yet completed. Specifically, it includes prefixes that have been successfully occupied from the distributed cache and have a lease set, but have not yet started sending probe messages (i.e., assigned to be scanned and in the process of scanning), and prefixes that have not yet released their locks (i.e., currently being scanned). It does not include prefixes that have been scanned and whose locks have been released. In the minimum connection count allocation strategy, idle nodes broadcast their current connection count. After receiving the broadcasts from all idle nodes, the source node compares the connection counts of each idle node and selects the node with the smallest connection count as the task transfer target, thereby prioritizing the allocation of new tasks to the node with the lightest current load and balancing the cluster load.

[0078] Once a probe node has completed scanning all its candidate targets, it broadcasts an idle status message to all other nodes in the cluster via the member discovery protocol. The message includes the number of prefix tasks that the node has currently accepted but not yet completed, i.e., the number of connections.

[0079] Other probe nodes that receive the idle broadcast, i.e. the source node, first check the task pool that they have not yet scanned, and filter out the prefixes that meet the following conditions: the local priority of the prefix is ​​higher than or equal to the preset priority threshold, and the prefix is ​​not locked by other nodes. These prefixes are used as the transferable candidate set.

[0080] Each source node collects the connection counts broadcast by all idle nodes, compares the connection values ​​of each idle node, and selects the idle node with the smallest connection count as the transfer target. If multiple idle nodes have the same connection count, one is randomly selected from them. The source node selects the highest priority prefix from its own transferable candidate set, encapsulates the prefix's identifier, current scanning progress, and locally generated timestamp into a task transfer message, and sends it to the selected idle node through the member discovery protocol or point-to-point communication.

[0081] After receiving a task transfer message, the idle node performs an atomic query to the distributed cache using the prefix in the message as the key and attempts to acquire the prefix. If the key does not exist in the cache, the idle node successfully acquires the prefix, sets the value of the key to its own node identifier and sets the lease time, then adds the prefix to its own task pool, and immediately starts scanning according to the scanning progress in the message. At the same time, the idle node's connection count is incremented by 1.

[0082] If the atomic occupancy operation fails, the idle node discards the transfer task and returns a conflict notification to the source node, which includes the node identifier of the conflicting occupant and its timestamp.

[0083] After receiving a conflict notification, the source node extracts the timestamp of the conflicting occupant and compares it with the transfer timestamp previously sent by the same node. If the timestamp of the conflicting occupant is later than the transfer timestamp of the same node, the transfer of that prefix is ​​abandoned and the occupant is remarked as pending scanning. If the timestamp of the conflicting occupant is earlier, the source node scans it itself.

[0084] After a successful transfer, the source node removes the prefix from its own task pool, decreases its own connection count by 1, and increases the connection count of idle nodes by 1. Through this dynamic adjustment, the connection count of each node is kept relatively balanced, avoiding some nodes from being overloaded while others are idle.

[0085] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the above functions can be divided into different functional modules to complete all or part of the functions described above.

[0086] In the embodiments provided in this application, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the embodiments described above are merely illustrative; for instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another device, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between devices or units, and may be electrical, mechanical, or other forms.

[0087] The above content is only a specific implementation of this application, but the protection scope of this application is not limited thereto. Any changes or substitutions within the technical scope disclosed in this application should be covered within the protection scope of this application.

Claims

1. A multi-dimensional feature detection system for IPv6 network assets based on proactive collaborative sensing, characterized in that, The system includes: a target perception and generation module, a detection execution module, a feature acquisition module, and a collaborative scheduling module; The target detection and generation module is used to detect nodes to know each other through the member discovery protocol, use consistent hashing to map the IPv6 prefix space to the virtual ring, generate virtual detect nodes according to their own identifiers to independently calculate the prefix range they are responsible for, synchronize the historical seed database through a distributed hash table, and run a target generation algorithm to predict the candidate target set. The detection execution module is used for each detection node to first check the distributed atomic lease lock for candidate prefixes, and for each detection node to dynamically adjust the packet sending rate according to real-time feedback during the scanning process. For prefixes that have triggered protection, the mode is switched and random jitter is introduced. Newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table. The feature acquisition module is used to perform deep feature acquisition on the live addresses after deduplication and synchronization, analyze the hit rate and determine the verification request sending requirements, and adjust the virtual probe node strategy of the prefix on the hash ring according to the verification feedback. The collaborative scheduling module is used to detect conflicts before and after scanning by the probe node via broadcast, resolve conflicts with the latest timestamp, and enable idle probe nodes to actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

2. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The probe nodes learn from each other through a member discovery protocol, use consistent hashing to map the IPv6 prefix space to a virtual ring, and each probe node generates a virtual probe node based on its own identifier to independently calculate the prefix range it is responsible for. At the same time, it synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the candidate probe target set. The specific analysis method is as follows: All probe nodes become aware of each other’s presence through a lightweight member discovery protocol and use a consistent hashing algorithm to map the entire IPv6 prefix space onto a virtual hash ring. Each probe node concatenates its own unique identifier with the virtual node sequence number and calculates a hash value to obtain the positions of multiple virtual nodes on the ring. It obtains and sorts the position list of all virtual nodes globally through the member discovery protocol, and then finds the interval between each virtual node belonging to this probe node and its next clockwise virtual node. It maps these intervals back to the IPv6 prefix range, thus obtaining the prefix set that this probe node is responsible for. When a probe node joins or leaves, the hash ring is automatically adjusted, and other probe nodes recalculate their affiliation. After each probe node is started, it first synchronizes the historical seed database from other probe nodes through a distributed hash table; Each probe node independently runs a target generation algorithm, learns the distribution pattern of the high-order prefix and the low-order interface identifier pattern of IPv6 addresses from the historical seed database, predicts the list of specific IPv6 addresses most likely to exist as live assets in the current period, and forms the candidate probe target set of this probe node.

3. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The probe node first checks the distributed atomic lease lock for candidate prefixes. The specific analysis method is as follows: For each specific IPv6 address in the candidate probe target set, the probe node first extracts its prefix. For each prefix in the candidate probe target set, the prefix sends an atomic query to the distributed cache with the key and attempts to acquire the request. If the string key for the prefix does not exist in the cache, the identifier of the current probe node is written to the string key through an atomic operation and the lease time is set, allowing the current probe node to perform a scan on the prefix; If the string key already exists in the cache and the corresponding node identifier is not the current probe node, it is determined that the prefix has been occupied by another probe node, and the scan of the prefix is ​​skipped.

4. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The detection node dynamically adjusts its packet transmission rate based on real-time feedback during the scanning process. The specific analysis method is as follows: Once a probe node successfully acquires the string key of a prefix, it immediately begins scanning. The probe node sends probe packets to the locked prefix and analyzes the probe packet response rate within the analysis period. If the probe packet response rate is less than or equal to the preset response rate threshold, the exponential backoff algorithm is used to reduce the packet sending rate. If the probe packet response rate is greater than the response rate threshold, the packet transmission rate increase value is determined based on the deviation between the probe packet response rate and the response rate threshold.

5. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The prefix switching mode that previously triggered protection was modified and random jitter was introduced. Newly discovered live addresses were deduplicated and synchronized in real time using a distributed hash table. The specific analysis method is as follows: If the number of times the response rate of the probe packet is less than or equal to the response rate threshold within a continuous probe period exceeds the preset tolerance threshold, the prefix is ​​determined to trigger the protection mechanism. The probe node automatically introduces random jitter, adds a random offset to the originally fixed transmission interval, randomizes the source port of each probe packet, and makes the inter-packet delay follow a uniform distribution. When a probe node detects a new live IPv6 address, it immediately sends the address, along with the discovery timestamp and the probe node's ID, to all other probe nodes via a distributed hash table. Upon receiving the address, the other probe nodes compare it with their local cache of detected addresses. If the address already exists and the received timestamp is updated, the probe node discards the live IPv6 address; otherwise, it updates its local cache.

6. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The process involves deep feature collection of the live addresses after deduplication and synchronization, analysis of the hit rate, determination of the need to send verification requests, and adjustment of the virtual probe node strategy for the prefix on the hash ring based on the verification feedback. The specific analysis method is as follows: The detection nodes perform in-depth feature collection on the deduplicated live addresses, including port scanning, service version identification, and operating system fingerprinting. After the data collection is completed, the probe node calculates the hit rate of the live addresses in this scan; If the hit rate of a certain prefix is ​​lower than the preset hit rate threshold, the probe node can actively initiate a verification request to other probe nodes, and another probe node will resample and rescan the prefix to verify the result. Meanwhile, the detection node will use the verification result as feedback. If the hit rate of another detection node is lower than the preset hit rate threshold, the deviation between the two hit rates and the hit rate threshold will be obtained. After averaging, the reduction value of the number of virtual detection nodes for that prefix will be determined based on the average value. If the hit rate of another detection node is higher than or equal to the preset hit rate threshold, the hit rate of the other detection node will be used to maintain the number of virtual detection nodes for that prefix. If the hit rate of a certain prefix is ​​higher than or equal to a preset hit rate threshold, the detection depth increase value of the prefix is ​​determined based on the deviation between the hit rate of the prefix and the hit rate threshold.

7. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The detection node performs conflict detection before and after scanning via broadcast, and resolves conflicts using the latest timestamp. The specific analysis method is as follows: Each probe node performs a collision detection step before and after scanning. Before scanning, the probe node broadcasts a declaration of its intention to scan to other probe nodes. If it receives a response from other probe nodes that the area is occupied, it abandons the scan. After scanning, the probe node broadcasts the results, along with a timestamp and the probe node ID, to the network. Other probe nodes then compare the results with their local results. If a conflict is found in the comparison results, the result with the latest timestamp shall prevail, and the conflict detection node shall automatically roll back and rescan the prefix; If no conflict is found in the comparison results, the current probe node confirms that it has the right to scan the prefix and begins to send probe packets to the target address under the prefix.

8. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: The idle probe node actively steals high-priority tasks to achieve load balancing. The specific analysis method is as follows: Once any probe node has completed scanning all the candidate targets it is responsible for, it broadcasts an idle status message to all other probe nodes through the member discovery protocol, and actively requests to share the prefix tasks that other probe nodes have not yet completed, and marks them as idle nodes. Upon receiving the request, the probe node checks its own unscanned task pool, transfers several prefixes in the probe node's task pool that have the prefix and whose local priority is higher than or equal to the preset priority threshold and whose prefix is ​​not locked by other probe nodes to the idle node, and records the probe node as the source node. During the transfer, the source node encapsulates the identifier of the selected prefix, the current scan progress, and the timestamp generated by the source node into a task transfer message and sends it to the idle node; Once the idle node receives the prefix, it performs an atomic query to the distributed cache using the prefix as the key and attempts to acquire it. If the acquisition is successful, the idle node adds the prefix to its own task pool and begins scanning. If the attempt to acquire the task fails, the task transfer message is discarded and a conflict notification is returned to the source node. After receiving a conflict notification, if the source node finds that the timestamp of the conflicting occupant is later than the transfer timestamp of the source node, it will abandon the transfer of that prefix and remark it as pending scanning. If the timestamp of the conflicting occupant is earlier, the source node can choose to re-transfer or scan itself.

9. The IPv6 network asset multi-dimensional feature detection system based on active collaborative sensing as described in claim 1, characterized in that: After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets. The specific analysis method is as follows: After the probe node completes all tasks including liveness detection and deep acquisition, it deletes the lock record of the corresponding prefix in the distributed cache, updates the scan status of the prefix to completed, and records the timestamp, hit rate and number of discovered addresses of this scan. If a probe node fails to complete its task before the lease expires, the lock record will automatically expire, and other probe nodes can reclaim the prefix. After a round of probes is completed, it will enter the waiting phase. Each probe node maintains a local rescan schedule, dynamically calculating the next rescan time based on the historical hit rate and asset changes of each prefix. When the clock reaches the scheduled rescan time, the probe node remarks the prefix as to be scanned and starts a new round of the process, which continues to run in a loop.

10. A method for multi-dimensional feature detection of IPv6 network assets based on proactive collaborative sensing, characterized in that, include: The probe nodes learn from each other through the member discovery protocol, use consistent hashing to map the IPv6 prefix space to the virtual ring, and each probe node generates a virtual probe node based on its own identifier to independently calculate the prefix range it is responsible for. At the same time, it synchronizes the historical seed database through a distributed hash table and runs a target generation algorithm to predict the set of candidate probe targets. Each probe node first checks the distributed atomic lease lock for candidate prefixes. During the scanning process, each probe node dynamically adjusts the packet sending rate based on real-time feedback. For prefixes that have triggered protection, the mode is switched and random jitter is introduced. Newly discovered live addresses are deduplicated and synchronized in real time through a distributed hash table. Deep feature collection is performed on the live addresses after deduplication and synchronization. The hit rate is analyzed and the verification request sending requirements are determined. The virtual probe node strategy of the prefix on the hash ring is adjusted according to the verification feedback. The probe nodes perform conflict detection before and after scanning via broadcast, and resolve conflicts with the latest timestamp. Idle probe nodes actively steal high-priority tasks to achieve load balancing. After the task is completed, the lock is released and statistical information is recorded. The rescan cycle is dynamically planned based on the historical hit rate to achieve multi-dimensional feature detection of IPv6 network assets.

Images