How does the ISP filter private IP addresses?

[Mitrixsen]

Hello, everyone.

I am studying for my ENCOR exam and my current topic is NAT. From my CCNA studies, I understand that private IP addresses aren't routable. The ISP will drop traffic destined to these addresses and also traffic that is sourced from these addresses.

My question is, how exactly is this implemented from the ISP's side? I would like just a quick high-level overview if possible. The routers must have some sort of filtering applied, correct? And whatever is filtering this traffic also  has to read the source.

Thank you

David

//Edit: Does this filtering only check whether the destination IP is a private IP address (thus it should be dropped) or does it also check the source? That's something that I am unsure about.

[Flavio Miranda · Accepted solution]

@Mitrixsen 

 There might be more than one approch depending on the ISP but you can use Access-list, firewall rules or prefix-list (in case of dynamic routing) and deny below ip address ranges.

10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16

Considering dynamic router with BGP, for example, ISP can put on the Edge router a prefix-list with thouse IP address range and refusing anything that matches those ip address ranges.

[Joseph W. Doherty · Accepted solution]

As @Flavio Miranda already noted, there are several approaches, not necessarily mutually exclusive and some which may work best used together.

However, I just want to add, ISP (external to ISP) private IP address filtering is a subset of Bogon filtering .

Also BTW, an ISP can route/use private IP addressing, within its own network, including being an underlay for public IP transit traffic.

[M02@rt37 · Accepted solution]

Hello @Mitrixsen 

Peering with the Cymru Bogon Project is a common and effective practice for ISPs to ensure they are filtering not only private IP ranges but also other bogon IP ranges. 

The team Cymru Bogon Project provides a list of IP address ranges that are considered "bogons." Bogons include:

Private IP Ranges (RFC 1918): These are non-routable IP ranges meant for internal networks.

Reserved IP Ranges: Allocated but not yet assigned by IANA or the RIRs.

Unallocated IP Ranges: Ranges not assigned to any entity and shouldn't be used on the Internet.

Martian IPs: Certain IPs that are invalid or nonsensical in routing (0.0.0.0/0, 127.0.0.0/8).

--

Cymru provides BGP feeds that you can peer with. These feeds dynamically update your router with bogon prefixes, so you don't have to manage the lists manually.

Request Peering:

• Reach out to Team Cymru at peering@cymru.com with details about your network and your Autonomous System (AS).
• Provide information like your AS number, peering router IPs, and a brief description of your network.

Receive BGP Feeds:

• Team Cymru will provide you with details for setting up a BGP session.
• They typically advertise a list of bogon prefixes via a private BGP session. These are tagged with community values for easier filtering.

Apply Filters: Once the prefixes are learned via BGP, you configure your edge routers to block or drop traffic sourced from or destined to these bogon ranges.

Example: Apply the bogon routes in an inbound filter on your edge interfaces.

So, you don’t need to manually maintain a list of bogon ranges; the BGP feed ensures the list is always up-to-date.

--

https://www.team-cymru.com/

[Joseph W. Doherty]

M02@rt37 , just wondering, from many of your recent excellent and comprehensive replies, are they being provided, in whole or in part, by an AI?

If so, what AIs are being used?

[M02@rt37]

Hello @Joseph W. Doherty 

Thanks.

Just my brain lol 

Google traductor in order to convert into english ; that's all.

[Joseph W. Doherty]

It's translated?!  What was original language, as when I've used Google translations, they often don't appear to provide such fine English.

[MHM Cisco World]

Any one use AI is laughing on himself.

We all can use it' but we must make us strong on IT not copy paste issue.

This my message to all.

MHM

[Joseph W. Doherty]

IMO, nothing wrong using AI if you treat it like any other reference materia.  I.e. proper attribution and vetting.

[MHM Cisco World]

I dont talking about this I talk about copy paste.

What will he learn? Nothing believe me.

In large company interview he will failed and in that time two things he will do 

Start study hard but this time really 

Or continue use AI and blame his luck.

Me as good friend must show him way and in end it his decision.

MHM

[Joseph W. Doherty]

"I dont talking about this I talk about copy paste."

For the purposes of answering a question, on these forums, for the benefit of others learning, I really don't see that it matters whether its something I personally describe, provide a reference link, copy and paste from other material however sourced.

I agree, someone trying to past themselves off with expertise, using any copy and paste approach is pointless, unless they can explain the material and its application.

Again, though, don't believe that applies to these forums.

[Karsten Iwen · Accepted solution]

As @Joseph W. Doherty states, it is important to note that these adresses are indeed routable. It's al about "policy" that these are adresses that are generally unwanted in certain networks.

As part of your studies, you should also look into BCP84:

https://www.rfc-editor.org/rfc/rfc3704.html

https://www.rfc-editor.org/rfc/rfc8704.html

[M02@rt37]

Other interesting source:

https://www.ripe.net/media/documents/BGP_Filtering-Webinar-Slides.pdf

[Mitrixsen]

Fantastic responses from everyone, thank you guys

[Devaa]

I don't see uRPF (Unicast Reverse Path Forwarding) mentioned here. Most ISPs use uRPF for this case.

uRPF is configured in PE (Provider Edge) Router interfaces pointing towards Customers to drop the packets for which the ISPs don't learn the return route via the same interface (reachable-via rx). All the non-NATed IPs, unknown Private IPs, source spoofed IPs will get dropped in PE router in this case. 

uRPF (in ISP router)

R1#conf t
Enter configuration commands, one per line.  End with CNTL/Z.
R1(config)#int e0/0
R1(config-if)#R1(config-if)#ip verify unicast source reachable-via ?
  any  Source is reachable via any interface
  rx   Source is reachable via interface on which packet was received