Ingress filtering are a class of standard network security measures used in Internet Protocol networks. They are all based on the assumption that if a packet attempts to enter the network, but the network has no reverse route: a means to send a reply back to the source address in the packet header, the packet must be forged (i.e., an example of IP spoofing) or in error. Packets with invalid addresses are sometimes called bogons.
When the idea was first standardized, it was generally implemented on a per-interface basis. In early routers, this was done with explicit access control lists (ACL) on the interface, which was a benefit if the interface had some autonomous hardware that could filter. Filtering was often computationally expensive if done in a general-purpose interface processor, and improvements were sought. One approach was the use of ternary content addressable memory, which could do hardware-based ACLs, but TCAM was too expensive for large routing tables. Per-interface ACLs could also be labor-intensive to keep current.
A performance-boosting technique for routing was distributing the forwarding information base (FIB) to the forwarding cards. The technique of unicast reverse path filtering came into play when it was realized that the source, as well as the destination, address could be looked up in the FIB. If there were no route to the source address, the packet could be deemed a bogon and silently discarded.  The FIB-based method is called reverse unicast path filtering (rUPF).
unicast reverse path forwarding
There are, however, legitimate network engineering techniques in which the router as a whole may have a reverse route, but the interface does not. One reason for not having a return path active on an ingress interface is that the nature of the application is such that it is known much more traffic will be returned to the source address, so an interface connected to a faster transmission medium might be used for the return path. A distinction, therefore, was made between strict rUPF, where the return path must be on the FIB in the ingress card, and loose rUPF, in which the packet is legitimate if some FIB contains the reverse route.
Loose uRPF can be quite complex to implement, if, for example, only traffic from certain source-destination address pairs are intended to take the asymmetrical reverse path. There also are various fault-tolerance schemes in which after the failure of a medium or interface that has the reverse route, another interface needs to be selected.
Yet another variant is useful on routers that can forward faster to an internal null destination than they can drop packets. This may seem counterintuitive, but there are good reasons, in the detailed design of routers, when this may be the case.
Blackhole routing has applications besides rejecting bogons. If the network is under denial of service attack, and, for example, some hosted server address is the target, that server is effectively useless. It would be overwhelmed by the attack traffic, so unless the attack can be characterized and stopped, especially difficult in distributed denial of service, network security monitoring software or personnel can create a blackhole route to the destination, and use various mechanisms to distribute that route to the FIBs. Blackhole routing is a very fast way to throw away undesired packets.
Alternatively, some or all of the attack traffic may be given a sinkhole route, which still diverts it away from the target but sends it to a security analysis center.  Hardware and software at the sinkhole, or multiple sinkholes when the traffic demands it, may be able to characterize the attack and give better methods of stopping it. Routes to sinkholes often use anycasting as a form of balancing the load across multiple sinkholes.
- P. Ferguson & D. Senie (May 2000), Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing, RFC 2827, IETF BCP (Best Current Practice) 34
- F. Baker & P. Savola (March 2004), Ingress Filtering for Multihomed Networks, RFC 3704, IETF BCP (Best Current Practice) 84
- Barry Raveendren Greene & Danny McPherson (NANOG 28, June 2003), Tutorial: ISP Security: Deploying and Using Sinkholes, North American Network Operators Group