Why does my home ISP route RFC 1918 addresses?

RouterOS General
1

My ISP appears to be using a RFC 1918 address for the first hop router, as well as responding to pings to another RFC 1918 address. Why? Maybe they consider the space between me and them “not the internet”?

For example:

[me@MikroTik] > tool traceroute 8.8.4.4
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST
 1 10.34.32.1                         0%    5  23.7ms    16.8     8.2    27.7
 2 100.127.77.32                      0%    5    11ms    17.3      11    27.6
 3 100.120.100.36                     0%    5  28.9ms    22.3    14.7    30.2
 4 68.1.1.14                          0%    5  27.8ms    34.5    27.2      59
 5 72.14.215.221                      0%    5    39ms    31.9      29      39
 6 108.170.247.225                    0%    5  36.8ms      32    27.7    36.8
 7 108.170.237.155                    0%    4    49ms      32      25      49
 8 8.8.4.4                            0%    4  32.8ms    29.3    23.5    32.8

And:

[me@MikroTik] > ping 10.98.0.2
  SEQ HOST                                     SIZE TTL TIME  STATUS           
    0 10.98.0.2                                  56 252 27ms 
    1 10.98.0.2                                  56 252 25ms 
    sent=2 received=2 packet-loss=0% min-rtt=25ms avg-rtt=26ms max-rtt=27ms 

[me@MikroTik] > tool traceroute 10.98.0.2
 # ADDRESS                          LOSS SENT    LAST     AVG    BEST   WORST
 1 10.34.32.1                         0%    2  14.5ms    11.9     9.2    14.5
 2 100.127.77.32                      0%    2   8.4ms       9     8.4     9.6
 3 100.127.66.129                     0%    2  17.1ms    17.4    17.1    17.7
 4 100.127.66.129                     0%    2  15.4ms    15.3    15.1    15.4
 5 10.98.0.2                          0%    2  23.7ms    23.4    23.1    23.7

I found this second one when I was trying to set up a GRE tunnel on the internet and could ping 10.98.0.2 but the GRE tunnel wasn’t working. Took me a while to figure out that the other end of the GRE tunnel wasn’t responding to 10.98.0.2, my ISP was. This seems shady as to me. They should be dropping RFC1918 traffic that leaks into their network but instead they are responding to it (and possibly dumping it in case there is anything of value in there?).

2

I don’t think there’s anything sinister behind it. They clearly use non-public adresses in their network (not just 10., but also those 100. are from cgnat range). And they probably forgot or simply don’t care about filtering. That’s the most simple explanation. :slight_smile:

3

100.64/10 (a.k.a shared address space, RFC6598) is not a “private” RFC1918 address range.
it was explicitly designed to provide assist to NAT44/NAT444 situations, where you receive a “non public” IPv4 address for your WAN as subscriber, just to give your ISP the possibility to server more concurrent subscribers with depleted IPv4 address resource. since IPv4 addresses are gone, and we can still expect the number of customers to rise, this might become more common. Indeed your ISP can provide IPv6 access to the internet in_addition to the existing NAT44 based IPv4 access, so you can have full visibility of your CPE, or even your devices located in your home network from any part of the v6 internet.

sadly mikrotik’s ip cloud implementation does not support v6 yet.

4

I think it’s mainly about 10.98.0.2, which most likely belongs to some other customer’s router. That’s what happends by default if ISP uses these addresses. Whether they should block it or not, that’s a question. Maybe yes, but I wouldn’t say it’s a big deal if they don’t. If all customers had public addresses, they would be able to access each other too. If you’re affraid of your private traffic leaking (e.g. when you want to access remote site while VPN link is down), filter it at your router.

5

Yeah. I am filtering it in the outbound direction on the WAN interface after I learned about this 10.98.0.2 thing. It’s quite interesting to see what tries to get out. I’ve learned a lot from that.

Such as:

WhatsApp will try to connect to the RFC1918 address on the “other” side of your conversation in case it’s actually somewhat local.

Disabling the BGP instance on MikroTik does not stop it from trying to contact BGP peers. You have to disable the BGP peer as well.

My MikroTik router is trying to connect to some 172.16.x.x address for whatever reason. I have no idea what service or program on the router is doing this.

Some host or device on a family member’s network is trying to contact all kinds of crazy stuff, including APIPA, RFC1918 not defined locally, and lots of different multicast addresses. It’s either a hacked device or some device unconcerned with the owner’s privacy. I haven’t been over there to find it yet.

I suppose the next step is to find out if this is happening on IPv6 as well. Fun.