icmpredirectsend is a product of Network Switching and Routing at Princeton University’s Office of Information Technology, and is available from https://www.net.princeton.edu/software/icmpredirectsend/
Presently the product builds and runs on Solaris 9 and 10 on SPARC with gcc.
The program relies on the libnet(3) library.
icmpredirectsend checks for the most-common values that could cause problems, but by no means can catch all such combinations of values. When it believes the values you specify could cause a problem, it will display a warning, and ask you if you still wish to send the packet. You can skip these checks (and the associated prompt) with the -w option; your packet will be sent without comment.
A number of the fields in the ICMP Redirect packet are fixed. The ICMP type and code fields are always 0x05 and 0x01 (indicating that the ICMP message is Redirect, and that the redirect is of the Host Redirect variety.) Since the ICMP Redirect packet must contain the IP header and (at least) the first 8 bytes of the packet that triggered the redirect, but no such triggering packet exists, the program bases these fields on the fiction that the triggering packet was a UDP packet from orig_ip_src_address port 0 to orig_ip_dest_address port 0, containing no UDP payload, with no UDP checksum calculated.
As described in RFC 1122, the receiver of an ICMP Redirect message should apply a number of sanity checks before updating its routing table. For example, an ICMP Redirect message should be ignored if it is destined to an IP broadcast or multicast address, or a link-layer broadcast address. An ICMP message is ignored if its IP source address is not that of a single host (e.g. a zero address, loopback address, broadcast address, multicast address, or Class E address). An ICMP Redirect message should be ignored if the source of the redirect message is not the current first-hop gateway for the specified destination. An ICMP Redirect message should be ignored if it specifies a new gateway address that is not on the same (sub-)net as the IP interface through which the redirect arrived. Hosts should always consider an ICMP Redirect message to be a Host Redirect, as opposed to a Network Redirect.
Beyond the sanity requirements that should cause a receiver to ignore inappropriate ICMP Redirect messages, the receiver’s implementation may apply additional heuristics. For example, some hosts may have a mechanism to timeout a routing table entry that was caused by an ICMP Redirect. Some hosts may have a mechanism to detect and timeout a routing table entry that specifies a gateway which is not functioning (e.g. TCP may discover this as a result of repeated timeouts for the same segment, and inform the OS). Some hosts will timeout any route created as a result of an ICMP Redirect after several minutes. Some hosts may have a mechanism to configure static routes that may not be modified by an ICMP Redirect. Some hosts may discard ICMP Redirect messages that specify a gateway address equal to one of the host’s own IP addresses.
There are additional issues when the receiver of an ICMP Redirect is an IP router. As described in RFC 1812: "a router may ignore an ICMP Redirect message when choosing a path for a packet originated by the router if the router is running a routing protocol, or if forwarding is enabled on the router and on the interface over which the packet is being sent." Also, "a router using a routing protocol (other than static routes) MUST NOT consider paths learned from ICMP Redirects when forwarding a packet. If a router is not using a routing protocol, a router MAY have a configuration that, if set, allows the router to consider routes learned through ICMP Redirects when forwarding packets."
Host 0:0:1:1:1:1 is configured with IP address 192.168.1.1 and netmask 255.255.255.0. Its routing table presently specifies that to reach destination 10.1.1.1, the next-hop gateway is 192.168.1.5. The host is reachable via our le0 interface. To send an ICMP Redirect to this host, specifying that to reach destination 10.1.1.1, the host should use gateway 192.168.1.8:
icmpredirectsend -i le0 -S 192.168.1.5 -s 192.168.1.1 -e 0:0:1:1:1:1 -o 10.1.1.1 -g 192.168.1.8
Note we specified that the ip_src_address of the ICMP Redirect message be an address that the host will consider to be on the same network as the host’s receiving interface (192.168.1.1/24); moreover, the ip_src_address is the address of the first-hop router recorded by the host as its present route to the destination. (To obtain this value, we must have some prior knowledge of the present state of the host’s routing table.) Furthermore, we specified a gateway_address that the host will consider to be on the same network as the host’s receiving interface. We select these values to ensure the host does not discard the ICMP Redirect message when it performs sanity checks on it.