Don't pick weird subnets for embedded networks, use VRFs

Summary

So what is an embedded network? I found it pretty hard to find a good name for this but I've come across them many times and created some myself. A good example here is a portable video rack. You drag a rack case around with video and network equipment and you need to connect it to the network of the venue to stream to the internet. The devices in the rack need to communicate with each other but you don't want to reconfigure their addresses every time you move to another venue because it happens to use another subnet. The solution to this is easy! Just add a small router in the rack so you have a consistent subnet inside the rack and the NAT isolates you from the changing IP addresses outside your small network. Your rack has 10.0.0.0/24 addresses because they are easy to remember and the router gets an IP from the venue using DHCP. This works perfectly fine until the public network in the venue also is on a 10.0.0.0/24 network. The router suddenly has the same subnet on both interfaces and addresses in your rack start conflicting with other hardware in the venue. This is the point where I see people often picking weird subnets for portable equipment. "What are the chances the venue has 172.16.42.0/24?, or 10.11.12.0/24"? And sure this works, until you get a conflict on those because humans are simply not that great at picking random numbers. It is not actually neccesary to have network seperation by random chance, you just need router features beyond common consumer routers. The IPv6 solution The most official solution for this is IPv6 of course. If your private network has IPv6 internally you can just address every device by it's link local address. Due to having a router splitting the network segment between your rack and the public network you know that all the link local addresses are always your own devices. You don't even need to have a DHCP server in your local net anymore. Every IPv6 device just gets it's own fe80:: address and you'd use network discovery p...