Skip to main content
Back to timeline
发表出处待核验Source publication:

Punching Bag local testbed shows six IPv6 target generation algorithms differ on scan budgets, aliased-prefix recognition, and response-rate adaptation

Synopsis

The authors present and release the IPv6 Punching Bag, a single-machine, low-memory local environment that answers ICMPv6 echo requests with per-prefix configurable response rates and address types, and use it to evaluate six dynamic target generation algorithms (6Hit, 6Sense, 6Scan, 6Tree, AddrMiner-S, and DET), finding that they only partially adhere to scanning budgets while generally respecting rate limits, that all but 6Sense fail to recognize aliased prefixes, and that 6Scan does not adapt to differing response behavior within prefixes.

AI-generated editorial illustration: Punching Bag: A Tool for Testing IPv6 Scans and Target Generation Algorithms

Interpretation

The authors developed and released the Punching Bag: a C++ tool that captures packets with libpcap, sends replies with libnet, and performs longest prefix matching through a custom Patricia-style trie in a multithreaded design, with per-prefix response rates that can differ by address type such as lower-byte addresses, EUI-64 addresses, or a default rate, enabling emulation of aliased prefixes and different address assignment patterns. Prior work offered no comparable, scalable local environment for IPv6 scans: LDPlayer targets DNS and Zirngibl et al. target QUIC, and those environments emphasize protocol correctness by running complete servers, which limits their scalability for emulating millions of responsive IPv6 targets. The design is described in detail (capture queue, worker threads, trie structure, JSON configuration, ip netns isolation), and the performance evaluation reports up to 60 k P/s with one response thread and 70 k P/s with two, 233 MB of RAM for a 255 k-prefix BGP configuration, and RTTs of 15 to 40 ms at 50 k P/s.

In the budget and rate adherence experiment, 6Tree and 6Hit massively and consistently exceed the configured 10 M budget (188.00 M and 24.11 M probes respectively) while the remaining algorithms adhere closely; 6Tree, DET, and AddrMiner-S adhere well to the maximum scanning rate because they call ZMapv6, whereas the custom scanning mechanisms of 6Sense, 6Scan, and 6Hit can exceed scanning rates by up to 39%. Earlier TGA comparisons relied on live Internet measurements that can be affected by network changes and loss and that impose load on the network; this experiment quantifies budget and rate adherence directly in a local setting. Each algorithm and configuration was run 10 times with means and standard deviations reported; Table 1 gives total probes, maximum rate, average rate, and maximum rate per prefix, and Figure 3 shows the peak-rate distribution per BGP prefix.

In the aliased prefix experiment, all algorithms except 6Sense report addresses from the aliased prefix as active, with close to 100% aliased addresses among reported active addresses (6Hit 99.40%, 6Scan 98.53%, 6Tree 99.29%, AddrMiner-S 99.98%, DET 99.70%) versus 0% for 6Sense; 6Tree, DET, and AddrMiner-S allocate more budget to the prefix as its response rate rises without recognizing it as aliased, while 6Scan splits budget nearly evenly between prefixes. The experiment separates known from unknown aliased prefixes and observes budget allocation per scanning iteration, which distinguishes whether an algorithm recognizes aliasing from how it reacts to a high response rate. The input consists of 100 k randomly generated addresses from two subnets each, with prefix one at 100% and prefix two at 1% response probability, a 10 M budget, and 10 repetitions with standard deviation below 10⁻⁴; the authors also inspected the APD implementations in the algorithms' code.

In the response-rate and consistency experiments, all algorithms except 6Scan spend increasingly more budget on the higher-response prefix as its rate rises (AddrMiner-S spends more than 96% of its budget in the 1-30 case), while 6Scan shows no reaction to any response-rate difference; under deterministic responses, DET, AddrMiner-S, and 6Sense produce differing probed address sets across repetitions due to intrinsic randomization, whereas 6Hit, 6Scan, and 6Tree probe nearly identical sets. The deterministic response design of the Punching Bag separates an algorithm's own randomness from its adaptation to response changes, which is difficult to achieve with live Internet measurements. Response-rate pairs of 1% versus 1%, 2%, 5%, 10%, 30%, and 100%, plus 10% versus 30%, were each repeated 10 times with standard deviations reported; a random-response variant of the Punching Bag produced results consistent with the deterministic version.

Perspective

The tool targets researchers and algorithm developers who want local evaluation before real Internet measurements, and it applies to single-machine, low-memory, reproducible ICMPv6 response scenarios: response rates and address types can be configured per prefix to emulate aliased prefixes, different address assignment patterns, and different response rates, and the packet log allows checking scanning budgets, maximum scanning rates, peak rates per prefix, and whether blocked networks were scanned. The authors recommend setting a scanning budget, a maximum scanning rate, and a blocklist when running a new or existing TGA, using a large diverse address collection such as the IPv6 Hitlist as input, and reviewing the log after the run.

The Punching Bag currently generates responses only to ICMPv6 echo requests, and the authors leave extension to further protocols such as reacting with a TCP SYN-ACK and to address patterns such as wildcards or wordy addresses to future work; the evaluation covers six dynamic TGAs with available source code, while static TGAs, 6Vision, and HMap are not included in this round of tests; 6Tree's APD mechanism segfaults after the second iteration when an aliased prefix is configured, so the true budget distribution for that case is unknown; and 6Sense's input was randomly sampled to 1 M addresses due to hardware limitations. In addition, this is a full-text parse, so the exact values behind Figures 3 through 8 can only be understood from the prose descriptions, and the original figures should be consulted for precise curve shapes.

Sources