Why can I send 127.0.0.1 to 127.0.0.0 on my network?

Question

We have a product that runs over IP. This product comes in two halves that are supposed to be connected directly to each other over Cat 5e. All this works fine.

For reasons that are not important, we have a customer that wants to ensure that it can not work on an actual IP network and only direct. So, we changed our firmware so that the fixed IP addresses are 127.0.0.0 and 127.0.0.1. They work directly connected, great!

But, when I connect them through our corporate network, through multiple switches, managed and unmanaged (and possibly a router, I didn't check with IT), they still link together and function normally.

So, I assumed the firmware is broken, and not really sending over that IP, so I mirrored a switch port, grabbed Wireshark and:

What is the explanation for this?

Are there any IP addresses that will not flow through a switch?

---

To JFL: We do not run an OS of any kind. It is an embedded system of which we control the code, so we can set the IP address to whatever we want. It can be fixed, or DHCP, so we just set it to a fixed address.

To Zac67: Generally, it's a really bad idea. It is in violation of RFC 1122. Yes, I know. That is exactly why I did it. We are in control of our own code, so no worry about it breaking. On a network I wanted it to break, which to my surprise it did not.

If you don't want those packets to cross routers link-local aka zeroconf aka APIPA addresses are what you need.

Thank you. I am aware of those addresses, but they are only 'un-routable'. I was actually hoping to do something that even a modern switch would puke on and not forward to anywhere. I was surprised (shocked actually) that a switch would forward loopback.

Answer 1

we changed our FW so that the fixed IP addresses are 127.0.0.0 and 127.0.0.1.

Generally, that's a really bad idea. It is in violation of RFC 1122:

  (g)  { 127, <any> }
 
                  Internal host loopback address.  Addresses of this form
                  MUST NOT appear outside a host.

If it works: fine for now, but may break any time. If it doesn't work, just do it correctly.

Basically, if you see those packets on your network, it's the source host (its implementation) that's violating RFC 1122. There's no bouncer on each network port that filters that traffic. It's the network admin's or architect's job to categorize whatever traffic as unwanted and take measures against it.

we have a customer that wants to ensure that it can NOT work on an actual IP network and only direct.

As @FrameHowitzer has pointed out, making a product use IP and not work over an IP network at the same time isn't possible. You'll have to actively configure that network to inhibit unwanted communication.

If you don't want those packets to cross routers, link-local aka zeroconf aka APIPA addresses are what you need. Simply use addresses from 169.254.0.0/16 which are defined to be not routable. I've explicitly blackholed those addresses on all our routers, just to make sure.

On the switches, you'd need to segregate that traffic using a dedicated VLAN. Switches don't care about higher-layer addresses like IP, so they'd forward frames containing link-local or even local loopback addresses just fine - but only within a VLAN.

If the switches support L3 ACLs you could filter the exact IP addresses that you don't want on your network, e.g.

 deny ip 169.254.0.0/16 any
 deny ip any 169.254.0.0/16
 (permit any any)

In a more complex configuration you could also choose to explicitly permit wanted traffic and filter all the rest.

Answer 2

The way I understand the question is: "How can I make it so our thingamajig DOESN'T work over a network of any kind and only works over a direct cable connection?"

Since that is specifically the antithesis of this kind of environment, I have to imagine it is off-topic. As for an answer, you would have to figure out how to make your software use interface hardware that is not used for normal networking, perhaps over a dedicated USB connection or other local direct connection. Anything that uses a standard network interface adapter has the chance to be intercepted and run over an extended network, assuming the person doing it has enough brains and experience to make it appear to be a Local Area Network.

Alternately, you could accept that it can be run over a network but encrypt it with a proprietary method so that only your desired 2 endpoints can participate in the connection.

Answer 3

If you don't want your product to work on an IP network, then don't use IP.

IPv4 is transmitted using Ethernet packets with an EtherType of 0x800.

Wikipedia has a (probably non-exhaustive) list of EtherTypes.

Choose an EtherType that isn't 0x800 and, even better, doesn't collide with anything on this list (or anything else you happen to know is used) and IP hardware (such as routers) won't route your packets. Switches may still forward them though, because switches forward Ethernet packets, not IP packets.

Other good answers:

• Karatekid430's answer: don't even use EtherType at all, just put your own non-Ethernet frames on the Ethernet PHY. I would imagine switches should drop these (but please correct me if I'm wrong here).
• Zac67's answer: use IP addresses from 169.254.0.0/16 in the hope that they won't be routed. Switches will still forward these - and it's possible that routers that have badly programmed firmware on them could forward them too, as you'd be relying on devices to handle this range appropriately.

Answer 4

Switches don't look at the IP address when forwarding frames. You can use whatever IP address you want, as long as the MAC addresses are correct your switch will happily forward it. It doesn't matter whether the IP adresses are 127.0.0.1, 255.255.255.0, 0.0.0.0, or anything else. Even identical IP adresses work. It's only the endpoint host (or next hop router) that will read the IPs and get confused.

If you want a switch to drop the traffic in stead of forwarding it, you might try to use a MAC address in the range "IEEE 802.1D MAC Bridge Filtered MAC Group Addresses" (01-80-C2-00-00-0x). These MAC addresses are reserved for protocols that should never be forwarded by switches, such as STP (01-80-C2-00-00-00), LLDP (01-80-C2-00-00-0E), etc.

Note that I would not recommend this in any production environment... these MAC addresses are reserved for a reason. But this might be fun to test in a lab.

Read more in the IEEE documentation or my blogpost on the topic.

Answer 5

Here are some ideas. None guaranteed. You didn't specify how important it is that someone can't deliberately access the packets.

• Use a weird connector and don't sell adapter cables compatible with RJ45.

• Use normal RJ45 connectors but mix up the pins. Only your special cable will work. Make sure to wire it differently at both ends.

• Use normal Ethernet cables, but interchange the 4 twisted pairs so they don't match up if plugged into a normal receiver. E.g. swap lanes A and D so what is normally transmitted on A is actually transmitted on D and vice versa. Some network cards can compensate for certain rearrangements so make sure to use a different one.

• Use normal cables, but deliberately overclock or underclock your PHY so it runs way out of spec (might only need a difference of 5% or so) and normal PHYs won't sync up. You run the risk of malfunction, of course.

• Add an extra lock-and-key physical signal. For example a certain small current must be present and must change polarity at a certain frequency, or a certain bit sequence. As long as the frequency is low, this can be superimposed on top of the data signal with no issues. If the signal isn't present, don't communicate.

• Deliberately break the Ethernet CRCs. For example, flip the last bit. You still have a checksum but it's incompatible with normal MACs. This is totally impossible with a standard MAC so it will only work if you're using some kind of software MAC or FPGA.

Anything higher-level than that - any kind of scrambled frame or scrambled header etc - will result in a frame that can pass through switches. Switches don't really look at a frame's contents a whole lot, before deciding how to forward it. Although since they do look at the Ethernet header a little bit, here are some Ethernet header ideas that might confuse some switches enough to make them not forward your frames:

• Send frames addressed to your own MAC address. The switch will try to send them back to you, or send them nowhere at all, instead of forwarding them to the other device because it knows that device is not their destination.

• Send frames with invalid VLAN tag 4095 (valid VLAN numbers are 1 to 4094)

• Send frames with the source address being the broadcast address FF:FF:FF:FF:FF:FF

Answer 6

Change your product's firmware to not use Ethernet frames over the Ethernet PHY. You can use an Ethernet PHY and place PCIe packets or something else on it.

Answer 7

So from your edit, those packets with IP addresses 127.0.0.0 / 127.0.0.1 are sent by embedded systems which implement their own IP stacks.

Those systems are not compliant with the RFC and do send those packets on the network, which normally should not occur. Any address within 127.0.0.0/8 must be treated as a loopback address and not go lower than layer 3 of the network stack.

Switches don't care about IP addresses, they only handle frames and whatever is inside the frame (like an IP packet) is of no concern to them. So a switch will happily forward a frame that contains an invalid IP packet, with a 127.0.0.X IP address or any other one.

Answer 8

If you have full control of the details of the network stack software (like in many embedded environments), you could do the following.

Change the Ethertype field in the Ethernet packets to 0x88B5 "EEE Std 802 - Local Experimental Ethertype".

https://www.iana.org/assignments/ieee-802-numbers/ieee-802-numbers.xml

In that case other hardware won't know you are sending IP packets and won't make assumptions about what's inside. Ethernet switches would probably still forward the raw Ethernet packets, but PCs would not be able to process them without custom software telling them what's in the packets.

Next do something like add in a 128-bit magic number between the 802.3 Ethertype field and the IP header. When receiving packets, throw out any that don't have that exact magic number as the first 16 bytes. All the other IPV4 or IPV6 processing is done identically, except that you started parsing it at a memory address that is 16 bytes further into the Ethernet frame.

Make sure to use a good random number generator to avoid collisions with other people who might also be doing custom stuff.

With those changes no regular IP nodes will know what to do with your packets, but it shouldn't be hard to modify your stuff to process them. This all assumes that you can modify the low-level Ethernet and IP processing firmware.

Answer 9

The IP address 127.0.0.1 is a special address known as the localhost or loopback address. This means that it always refers to the local computer, so you can always send a message to it from your local computer.