Reverse-path forwarding: Difference between revisions

Revision as of 09:30, 23 April 2019

Revision as of 14:35, 20 May 2019

Line 1:

{{No footnotes}}

{{Unreferenced|date=November 2009}}

'''Reverse path forwarding (RPF)''' is a technique used in modern [[router (computing)|router]]s for the purposes of ensuring loop-free forwarding of [[multicast]] packets in multicast [[routing]] and to help prevent [[IP address spoofing]] in [[unicast]] routing.

'''Reverse -path forwarding (RPF)''' is a technique used in modern [[router (computing)|router]]s for the purposes of ensuring loop-free forwarding of [[multicast]] packets in multicast [[multicast routing]] and to help prevent [[IP address spoofing]] in [[unicast]] routing.

In standard unicast IP routing, the router forwards the packet away from the source to make progress along the distribution tree and prevent routing loops. In contrast, the router's multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree at the source of the multicast. This process is known as reverse-path forwarding (RPF).

In standard unicast IP routing, the router forwards the packet away from the source to make progress along the distribution tree and prevent routing loops. In contrast, the router's multicast forwarding state runs more logically by organizing tables based on the reverse path, from the receiver back to the root of the distribution tree at the source of the multicast. This processapproach is known as reverse-path forwarding (RPF).<!--[[User:Kvng/RTH]]-->

== Multicast RPF ==

Line 15 ⟶ 16:

* the path used from a sender to a router and the reverse path from the router back to the sender are symmetric.

If the first assumption is not true, the RPF check will fail because it depends upon the router's unicast routing table as a fallback. If the second assumption is not true, the RPF check would reject multicast traffic on all but the shortest path from the sender to the router and would eventually lead to non-optimal multicast tree. In cases where the links are unidirectional, the reverse -path approach can fail altogether.

== Unicast RPF (uRPF) ==

Line 28 ⟶ 29:

Unfortunately, it is often the case on the larger Internet backbone that routing is asymmetric and the routing tables cannot be relied upon to point to the best route for a source to get to a router. Routing tables specify the best forward path and only in the symmetric case does that equate to the best reverse path. Because of this asymmetry it is important when implementing uRPF to be aware of the potential for asymmetry to exist to prevent accidental filtering of legitimate traffic.

RFC 3704 gives more details on how to extend the most basic "this source address must be seen in the routing table for the input interface" concept known as '''strict reverse -path forwarding''' to include some more relaxed cases that can still be of benefit while allowing for at least some asymmetry.

===Strict mode===

Line 41 ⟶ 42:

== {{anchor|Filtering}}Unicast RPF confusion ==

RPF is often incorrectly defined as Reversereverse-path Path Filteringfiltering, particularly when it comes to unicast routing. This is an understandable misinterpretation of the acronym in that when RPF is used with unicast routing as in RFC 3704 traffic is either permitted or denied based upon the RPF check passing or failing. The thought being that traffic is denied if it fails the RPF check and is therefore filtered, however as per RFC 3704 the correct interpretation is that traffic is '''forwarded''' if it passes the RPF check. Several examples of the proper usage can be seen in documents by [http://www.juniper.net/techpubs/software/junos/junos56/swconfig56-interfaces/html/interfaces-family-config15.html Juniper], [http://www.cisco.com/web/about/security/intelligence/unicast-rpf.html Cisco], [http://www.openbsd.org/faq/pf/filter.html#urpf OpenBSD], and most importantly RFC 3704 which defines the use of RPF with unicast.

While uRPF is used as an ingress '''filtering''' mechanism, it is affected by reverse -path '''forwarding'''.

== See also ==