This pull request introduces the APAR algorithm without an active probing component to analytically resolve possible IP alias pairs.
The algorithm is executed when specifying the --resolve-aliases under the following conditions:
IPv4 is used
The probing direction is specified as two-way (both forward- and reverse)
The possible alias pairs found in the traces are written to a file in the format {output}.aliases,
where the placeholder {output} is determined by an argument passed to the client.
Reducing the needed amount of NAT state on the client side
To reduce the amount of state that must be maintained by a client-sided NAT,
the client now reuses request identifiers of previously answered requests.
This allows NAT boxes to use an already existing NAT mapping instead of creating a new one.
Two-way IP Alias Resolution
This pull request introduces the APAR algorithm without an active probing component to analytically resolve possible IP alias pairs. The algorithm is executed when specifying the
--resolve-aliasesunder the following conditions:The possible alias pairs found in the traces are written to a file in the format
{output}.aliases, where the placeholder{output}is determined by an argument passed to the client.Reducing the needed amount of NAT state on the client side
Reverse traceroute probes use the ICMP identifier field to encode a unique query identifier, which is then used to match possible responses. This field is also used by NAT middleboxes to maintain NAT mappings for ICMP sessions, which means that each probe leads to an individual mapping in the presence of such a middlebox.
To reduce the amount of state that must be maintained by a client-sided NAT, the client now reuses request identifiers of previously answered requests. This allows NAT boxes to use an already existing NAT mapping instead of creating a new one.
Other Changes
33434, which is reserved for traceroute use.