Dealiasing

The dealias crate keeps alias detection modular by defining a single trait:

pub trait Dealiaser: Send {
    fn generate(&mut self, target: IpAddr) -> Vec<IpAddr>;
    fn observe_reply(&mut self, addr: IpAddr) -> bool;
    fn poll_timeouts(&mut self, now: Instant) -> Vec<(IpAddr, AliasStatus)>;
}

• generate receives the original target and returns a set of fan-out addresses to probe (for example, HistList’s 16 nibble variations or your own adaptive scheme).
• observe_reply processes every response observed by the probe loop. Return true if the address belongs to an active analysis so the caller knows to keep forwarding replies.
• poll_timeouts is invoked periodically (100ms by default) to flush completed analyses. Emit an (IpAddr, AliasStatus) tuple for each finished decision.

Integrating with the scan engine

scan/src/probe/mod.rs wires the default Ipv6HistlistDealiaser into the response handler. To use a different engine:

1. Implement your type and expose a constructor—consider accepting configuration knobs such as timeout duration, fan-out width, or heuristic thresholds.
2. Replace the instantiation inside spawn_response_handler with your engine, or expose a selector so the CLI can choose between multiple implementations.
3. Map your outcome to ScanResultTag::alias (the helper used today) so CSV exports and the Python bindings continue to see alias / alias_prefix columns.
4. Document the new behaviour under site/content/docs/dealiasing.md and update the CLI help text if you add flags.

Advanced patterns

• Combine multiple engines by spawning separate tasks and merging their outputs before the results channel; this is useful when you want both IPv4- and IPv6-specific logic.
• Persist intermediate state (for example, learnt prefix lengths) in a struct that implements Default + Clone so it can be reused across workers.
• When integrating with distributed scanners, serialize your engine configuration alongside ScanConfig so remote workers reach identical conclusions.