You do not have permission to edit this page, for the following reasons:

This IP address has been blocked from editing Wikipedia.
This does not affect your ability to read Wikipedia pages.
Most people who see this message have done nothing wrong. Some kinds of blocks restrict editing from specific service providers or telecom companies in response to recent abuse or vandalism, and can sometimes affect other users who are unrelated to that abuse. Review the information below for assistance if you do not believe that you have done anything wrong.

The IP address or range 44.200.0.0/16 has been blocked (disabled) by ‪Blablubbs‬ for the following reason(s):

The IP address that you are currently using has been blocked because it is believed to be a web host provider or colocation provider. To prevent abuse, web hosts and colocation providers may be blocked from editing Wikipedia.
You will not be able to edit Wikipedia using a web host or colocation provider because it hides your IP address, much like a proxy or VPN.
We recommend that you attempt to use another connection to edit. For example, if you use a proxy or VPN to connect to the internet, turn it off when editing Wikipedia. If you edit using a mobile connection, try using a Wi-Fi connection, and vice versa. If you are using a corporate internet connection, switch to a different Wi-Fi network. If you have a Wikipedia account, please log in.
If you do not have any other way to edit Wikipedia, you will need to request an IP block exemption.

How to appeal if you are confident that your connection does not use a colocation provider's IP address:
If you are confident that you are not using a web host, you may appeal this block by adding the following text on your talk page: ((unblock|reason=Caught by a colocation web host block but this host or IP is not a web host. My IP address is _______. Place any further information here. ~~~~)). You must fill in the blank with your IP address for this block to be investigated. Your IP address can be determined here. Alternatively, if you wish to keep your IP address private you can use the unblock ticket request system. There are several reasons you might be editing using the IP address of a web host or colocation provider (such as if you are using VPN software or a business network); please use this method of appeal only if you think your IP address is in fact not a web host or colocation provider.

Administrators: The IP block exemption user right should only be applied to allow users to edit using web host in exceptional circumstances, and requests should usually be directed to the functionaries team via email. If you intend to give the IPBE user right, a CheckUser needs to take a look at the account. This can be requested most easily at SPI Quick Checkuser Requests. Unblocking an IP or IP range with this template is highly discouraged without at least contacting the blocking administrator.

This block will expire on 16:45, 10 February 2025.

Even when blocked, you will usually still be able to edit your user talk page, as well as email administrators and other editors.

For information on how to proceed, please read the FAQ for blocked users and the guideline on block appeals. The guide to appealing blocks may also be helpful.

Other useful links: Blocking policy · Help:I have been blocked
Your IP address is in a range that has been blocked on all Wikimedia Foundation wikis. The block was made by ‪AntiCompositeNumber‬. The reason given is Open proxy/Webhost: Visit the FAQ if you are affected .
- Start of block: 13:55, 18 August 2022
- Expiry of block: 13:55, 18 March 2025
Your current IP address is 44.200.254.7. The blocked range is 44.200.0.0/16. Please include all above details in any queries you make. If you believe you were blocked by mistake, you can find additional information and instructions in the No open proxies global policy. Otherwise, to discuss the block please post a request for review on Meta-Wiki. You could also send an email to the stewards VRT queue at stewards@wikimedia.org including all above details.

You can view and copy the source of this page:

((short description|Multicast routing technique to minimize loops and enhance security))
((No footnotes|date=May 2019))

'''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.<ref>((cite web
| url=https://www.juniper.net/documentation/software/erx/erx50x/swconfig-routing-vol1/html/ip-multicast-config7.html
| title=Reverse Path Forwarding
| date=2010
| publisher=[[Juniper Networks]]
| access-date=2021-05-12))</ref>

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 approach is known as reverse-path forwarding.

== Multicast RPF ==
Multicast RPF, typically denoted simply as RPF, is used in conjunction with a multicast routing protocol such as [[Multicast Source Discovery Protocol]] or [[Protocol Independent Multicast]] to ensure loop-free forwarding of multicast packets. In multicast routing, the decision to forward traffic is based upon source address and not on destination address as in unicast routing. It does this by utilizing either a dedicated multicast routing table or, alternatively, the router's unicast routing table.

When a multicast packet enters a router's interface, the router looks up the list of networks that are reachable via that interface (i.e., it checks the paths by which the packet could have arrived). If the router finds a matching routing entry for the source IP address of the multicast packet, the RPF check passes and the packet is forwarded to all other interfaces that are participating in that multicast group. If the RPF check fails, the packet is dropped. As a result, the forwarding of the packet is decided based upon the reverse path of the packet rather than the forward path. By only forwarding packets that come into the interface that also holds the routing entry for the source of the packet, loops are prevented.

This is critically important in redundant multicast topologies. Because the same multicast packet could reach the same router via multiple interfaces, RPF checking is integral in the decision to forward packets or not. If the router forwarded all packets that come in interface A to interface B and it also forwarded all packets coming in interface B to interface A and both interfaces receive the same packet, this will create a [[routing loop]] where packets will be forwarded in both directions until their IP [[Time to live|TTL]]s expire. Routing loops are best avoided as they unnecessarily consume network resources.

The underlying assumptions of an RPF check are that,
# the unicast routing table is correct and stable and,
# 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 false, the RPF check will fail because it depends upon the router's unicast routing table as a fallback. If the second assumption is false, the RPF check would reject multicast traffic on all but the shortest path from the sender to the router which would lead to a non-optimal multicast tree. In cases where the links are unidirectional, the reverse-path approach can fail altogether.

== Unicast RPF ==
'''Unicast RPF''' (uRPF), as defined in RFC 3704, is an evolution of the concept that traffic from known invalid networks should not be accepted on interfaces from which it should never have originated. The original idea as seen in RFC 2827 was to block traffic on an interface if it is sourced from forged IP addresses. It is a reasonable assumption for many organizations to simply disallow propagation of private addresses on their networks unless they are explicitly in use. This is a great benefit to the Internet backbone as blocking packets from obviously bogus source addresses helps to cut down on IP address spoofing which is commonly used in [[denial of service|DoS]], [[distributed denial of service|DDoS]], and network scanning to obfuscate the source of the scan.<ref>((cite web
| url=https://tools.cisco.com/security/center/resources/unicast_reverse_path_forwarding
| title=Understanding Unicast Reverse Path Forwarding
| publisher=[[Cisco Systems]]
| access-date=2021-05-12))</ref>

uRPF extends this idea by utilizing the knowledge all routers must have in their [[routing information base]] (RIB) or [[forwarding information base]] (FIB) to do their primary job, to help further restrict the possible source addresses that should be seen on an interface. Packets are only forwarded if they come from a router's best route to the source of a packet. Packets coming into an interface come from valid subnetworks, as indicated by the corresponding entry in the routing table are forwarded. Packets with source addresses that could ''not'' be reached via the input interface can be dropped without disruption to normal use, as they are probably from a misconfigured or malicious source.

In cases of symmetric routing, routing where packets flow both directions through the same path, and terminal networks connected via a single link, this is a safe assumption and uRPF can be implemented without many anticipated problems. Using uRPF as close as possible to the real source of traffic also stops spoofed traffic before it has any chance of using bandwidth or reaching a router that is not configured for RPF and thus inappropriately forwarded.

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. It is important when implementing uRPF to be aware of the potential for asymmetry to prevent accidental filtering of legitimate traffic.

RFC 3704 gives more details on how to extend 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===
In strict mode, each incoming packet is tested against the FIB and, if the ''incoming'' interface is not the best reverse path, the packet check will fail. By default failed packets are discarded.((efn|name=command|Example command on Cisco devices: ip verify unicast source reachable-via {rx} - Strict mode, {any} - loose mode))

===Feasible mode===
In feasible mode, the FIB maintains alternate routes to a given IP address. If the ''incoming'' interface matches with any of the routes associated with the IP address, then the packet is forwarded. Otherwise, the packet is dropped.

===Loose mode===
In loose mode each incoming packet's source address is tested against the FIB. The packet is dropped only if the source address is not reachable via ''any'' interface on that router.((efn|name=command))

== ((anchor|Filtering))Filtering vs. forwarding  ==
RPF is often interpreted as reverse-path ''filtering'', particularly when it comes to unicast routing. This is an understandable alternate interpretation 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. While uRPF is used as an ingress ''filtering'' mechanism, it is affected by reverse-path ''forwarding''.

Reverse path filters are typically used to disable asymmetric routing where an IP application has a different incoming and outgoing routing path. Its intent is to prevent a packet entering one interface from leaving via the other interfaces. Reverse-path Filtering is a feature of the [[Linux Kernel]].<ref>((cite web
| url=https://www.theurbanpenguin.com/rp_filter-and-lpic-3-linux-security/
| title=rp_filter and LPIC-3 Linux Security
| date=2020-08-27
| website=theurbanpenguin.com
| access-date=2021-05-12))</ref>

== See also ==
* [[Flooding (computer networking)]]

==Notes==
((Notelist))

==References==
((Reflist))

== External links ==
* ((cite IETF |RFC=2827 |title=Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing))
* ((cite IETF |RFC=3704 |title=Ingress Filtering for Multihomed Networks))

[[Category:Routing]]

Pages transcluded onto the current version of this page (help):

Reverse-path forwarding (edit)
Template:Ambox (view source) (template editor protected)
Template:Anchor (view source) (template editor protected)
Template:Citation (view source) (protected)
Template:Cite IETF (view source) (semi-protected)
Template:Cite IETF/doctypes (view source) (semi-protected)
Template:Cite IETF/makelink (view source) (semi-protected)
Template:Cite web (view source) (protected)
Template:Efn (view source) (template editor protected)
Template:Main other (view source) (protected)
Template:No footnotes (view source) (template editor protected)
Template:Notelist (view source) (template editor protected)
Template:Pagetype (view source) (protected)
Template:Reflist (view source) (protected)
Template:Reflist/styles.css (view source) (protected)
Template:SDcat (view source) (protected)
Template:Short description (view source) (protected)
Template:Short description/lowercasecheck (view source) (protected)
Template:Yesno (view source) (protected)
Template:Yesno-no (view source) (template editor protected)
Module:Anchor (view source) (template editor protected)
Module:Arguments (view source) (protected)
Module:Category handler (view source) (protected)
Module:Category handler/blacklist (view source) (protected)
Module:Category handler/config (view source) (protected)
Module:Category handler/data (view source) (protected)
Module:Category handler/shared (view source) (protected)
Module:Check for unknown parameters (view source) (protected)
Module:Citation/CS1 (view source) (protected)
Module:Citation/CS1/COinS (view source) (protected)
Module:Citation/CS1/Configuration (view source) (protected)
Module:Citation/CS1/Date validation (view source) (protected)
Module:Citation/CS1/Identifiers (view source) (protected)
Module:Citation/CS1/Utilities (view source) (protected)
Module:Citation/CS1/Whitelist (view source) (protected)
Module:Citation/CS1/styles.css (view source) (protected)
Module:Disambiguation/templates (view source) (protected)
Module:Message box (view source) (protected)
Module:Message box/ambox.css (view source) (protected)
Module:Message box/configuration (view source) (protected)
Module:Namespace detect/config (view source) (protected)
Module:Namespace detect/data (view source) (protected)
Module:Pagetype (view source) (protected)
Module:Pagetype/config (view source) (protected)
Module:Pagetype/disambiguation (view source) (protected)
Module:Pagetype/setindex (view source) (protected)
Module:Pagetype/softredirect (view source) (protected)
Module:SDcat (view source) (protected)
Module:String (view source) (protected)
Module:TableTools (view source) (protected)
Module:Template wrapper (view source) (template editor protected)
Module:Unsubst (view source) (protected)
Module:Wikitext Parsing (view source) (protected)
Module:Yesno (view source) (protected)

Return to Reverse-path forwarding.

Retrieved from "https://en.wikipedia.org/wiki/Reverse-path_forwarding"