Summary

  • RFC 2267 put a source-prefix check on the provider interface facing a downstream customer, where the permitted prefixes could be known locally.
  • BCP 38 made the recommendation a Best Current Practice in 2000, but a passing prefix check still identified a network boundary, not the host or person behind a packet.

The victim saw an address, not a sender

A server receives connection attempts that claim to come from unreachable addresses. It sends replies into paths that lead nowhere, while the attacker keeps changing the source field. A different packet may name a real address belonging to an uninvolved network. If the victim blocks that apparent source, it can cut off legitimate traffic from the innocent network as well.

That was the operational blind spot described in RFC 2267. The destination sees the source address written into the packet, but it has no direct way to know who wrote it. Host hardening can make a server withstand more connection attempts; it cannot tell a distant victim whether an incoming source address was forged. The memo treated those as complementary defenses, while pointing to a check nearer the network that emitted the packet.

The provider already knew the customer-facing edge

Imagine an Internet provider aggregating routes for several downstream networks. At the router interface connected to one customer, the provider has a practical question it can answer locally: which source prefixes are legitimate on this link? The RFC’s example allows packets using the customer’s prefix and drops packets that claim to originate elsewhere. It recommends logging the dropped traffic so administrators can investigate suspicious activity.

This is not a global lookup of who owns every address. The proposed rule uses a relationship held at the edge: this customer link, this permitted source-prefix set. The source field is checked against that relationship before the packet enters the provider’s wider network. A packet with an outside prefix can be stopped close to where it entered, before it becomes one more ambiguous signal at a victim’s perimeter.

The change in location matters. Without an upstream check, a target has to infer origin from an untrusted field and may burden an innocent address holder with defensive filtering. With a provider-edge check, the network carrying the customer’s traffic can reject source prefixes that do not belong on that customer’s connection. If an attack still uses an allowed prefix, the provider can at least begin with a smaller network boundary than the entire Internet.

A prefix test is not a return-route test

RFC 2267 also draws a distinction that is easy to miss. The authors considered checking whether the route back to a packet’s source would leave through the same interface on which the packet arrived. They rejected that as a general requirement because asymmetric routes were common enough to make it problematic. Their customer-edge proposal instead asks whether the source prefix is legitimate for the downstream network on that interface.

The two checks can sound alike because both inspect a packet at an ingress point. They answer different questions. A same-interface return-path test depends on routing-table direction; a customer-prefix filter depends on the source ranges permitted for the attached network. RFC 3704 later addressed ingress-filtering mechanisms for multihomed networks and updated RFC 2827. Its detailed strict, feasible and loose reverse-path modes are a separate story; they are not what this article is commissioning.

Legitimate mobility exposed the policy edge

A source address can be legitimate for a mobile node and still be unexpected on the network where the node is currently attached. RFC 2267 called out Mobile IP: traffic sent from a visited network could carry the node’s home address, so a simple customer-prefix rule might reject it. The memo pointed to reverse tunneling, later specified in RFC 2344, as a way to carry the outgoing packet to the home agent before sending it onward.

That example is revealing because the filter is not judging intent. It is enforcing a local statement about which prefixes may cross a particular customer interface. A legitimate service that needs another source prefix must have a path or an explicit policy that makes the packet valid at that boundary. The RFCs do not say that all mobile traffic fails, or that filtering should erase every exception. They show that an exception has to be reconciled with the edge rule.

A recommendation became BCP 38

RFC 2267 appeared in January 1998 as an Informational memo. In May 2000, RFC 2827 obsoleted it and carried the same “Network Ingress Filtering” title as BCP 38, a Best Current Practice. The core proposal remained recognizable: providers should filter customer traffic at the ingress edge so a customer cannot send packets with source prefixes that are not legitimately in use on that network.

The change in document status matters, but it is not a deployment receipt. RFC 2827 is a practice recommendation; its publication does not show which routers, customers or provider links had a filter installed. RFC 2267 said some providers had begun implementing the technique, but it supplied no census or measurement of coverage. A document, a provider policy, an installed interface rule, a dropped packet and a successful investigation are separate facts.

The filter’s promise was deliberately bounded. It could prevent a customer from emitting traffic with forged source prefixes outside the permitted set. It could not stop an attacker from naming another host inside that set, defeat attacks sent from valid addresses, identify a device or person, or prove motive. A drop log could help locate a suspicious packet at a network edge; it was evidence about an interface decision, not a confession from the sender.

The durable historical shift was therefore modest and concrete. Instead of asking only the victim to make sense of a forged address, RFC 2267 placed a verifiable check at the customer’s provider boundary, where the relevant prefix relationship could be maintained and applied. BCP 38 made that operating practice easier to name and discuss. Whether it worked on a particular connection still depended on the local rule being accurate, installed and active.

Sources

  1. RFC 2267 — Network Ingress Filtering
  2. RFC 2827 — Network Ingress Filtering (BCP 38)
  3. RFC 1812 — Requirements for IP Version 4 Routers
  4. RFC 2002 — IP Mobility Support
  5. RFC 2344 — Reverse Tunneling for Mobile IP
  6. RFC 3704 — Ingress Filtering for Multihomed Networks (BCP 84)